Manual:Maxlag parameter/de

Wenn du MediaWiki auf einem replizierten Datenbankcluster (wie Wikimedia) betreibst, können hohe Bearbeitungsraten zu Verzögerungen beim Replikatserver führen. Eine Möglichkeit, um dies zu minimieren, ist alle Bots und Wartungstätigkeiten automatisch zu stoppen, wenn die Verzögerung einen bestimmten Wert übersteigt. In MediaWiki 1.10 wurde der Maxlag-Parameter eingeführt, der dies für Client-seitige Skripte ermöglicht. In 1.27 wurde es aktualisiert und funktioniert nur für -Abfragen.

Der Maxlag-Parameter kann über einen URL-Parameter oder über POST-Daten an api.php übergeben werden. Er ist eine ganze Zahl in Sekunden. Beispielsweise zeigt [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=1 dieser Link] Metadaten über die Seite "MediaWiki", es sei denn die Verzögerung ist größer als 1 Sekunde, während [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 dieser] (mit -1 am Ende) dir die aktuelle Verzögerung ohne Metadaten anzeigt.

Wenn die angegebene Verzögerung zum Zeitpunkt deiner Abfrage überstiegen wird, wird ein Statuscode 503 ausgegeben (oder 200 während API-Abfragen, siehe ), der das folgende Format besitzt:

Die folgenden HTTP-Header sind gesetzt:


 * Retry-After: eine empfohlene minimale Anzahl von Sekunden, die der Client abwarten soll, bevor er erneut versucht, die Abfrage auszuführen
 * X-Database-Lag: Die Verzögerung in Sekunden des am stärksten verzögerten Replikats

Die folgende Nutzung wird für Wikimedia-Wikis empfohlen:


 * Use maxlag=5 (5 seconds). This is an appropriate non-aggressive value, set as default value on Pywikibot. Higher values mean more aggressive behaviour, lower values are nicer.
 * If you get a lag error, pause your script for at least 5 seconds before trying again. Be careful not to go into a busy loop.
 * It's possible that with this value, you may get a low duty cycle at times of high database load. That's OK, just let it wait for off-peak. We give humans priority at times of high load because we don't want to waste their time by rejecting their edits.
 * Unusually high or persistent lag should be reported to on irc.freenode.net.
 * Interactive tasks (where a user is waiting for the result) may omit the maxlag parameter. Noninteractive tasks should always use it. See also API:Etiquette.

Note that the caching layer (Varnish or squid) may also generate error messages with a 503 status code, due to timeout of an upstream server. Clients should treat these errors differently, because they may occur consistently when you try to perform a long-running expensive operation. Repeating the operation on timeout would use excessive server resources and may leave your client in an infinite loop. You can distinguish between cache-layer errors and MediaWiki lag conditions using any of the following:


 * X-Database-Lag header is distinctive to replication lag errors in MediaWiki
 * No Retry-After in Varnish errors
 * X-Squid-Error header should be present in squid errors
 * The response body in replication lag errors will match the regex

For testing purposes, you may intentionally make the software refuse a request by passing a negative value, such as in the following URL: [/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 /w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1].

The maxlag parameter is checked in, and also applies to the action API.