Manual:Maxlag parameter/es

Si está ejecutando MediaWiki en un clúster de base de datos replicado (como lo es Wikimedia), las altas tasas de edición pueden hacer que los servidores de réplica se retrasen. Una forma de mitigar el retraso de la replicación es hacer que todos los bots y tareas de mantenimiento se detengan automáticamente cada vez que el retraso supere un cierto valor. En MediaWiki 1.10, se introdujo el parámetro maxlag para permitir que se haga esto mismo en scripts del lado del cliente. En 1.27, se actualizó para que solo funcionase para peticiones a api.php.

El parámetro maxlag se puede pasar a api.php a través de un parámetro en la URL o de datos POST. Es un número entero de segundos. Por ejemplo, esto muestra metadatos sobre la página «MediaWiki» a menos que el retraso sea mayor de 1 segundo mientras esto (con -1 al final) muestra el retraso real sin metadatos.

Si se supera el retraso especificado en el momento de la solicitud, se devuelve un código de estado 503 (o 200 durante las solicitudes API, consulte <translate> task <tvar name=1>T33156</tvar></translate>), con un cuerpo de respuesta con el siguiente formato:

{
    "error": {
        "code": "maxlag",
        "info": "Waiting for $host: $lag seconds lagged",
        "host": $host,
        "lag": $lag,
        "*": "See https://www.mediawiki.org/w/api.php for API usage"
    }
}

Se establecen las siguientes cabeceras HTTP:

Retry-After: un número mínimo recomendado de segundos que el cliente debería esperar antes de volver a intentar
X-Database-Lag: El número de segundos de retraso de la réplica más retrasada

El uso recomendado para wikis de Wikimedia es el siguiente:

Usa maxlag=5 (5 segundos). Este es un valor adecuado y no agresivo, fijado como predeterminado en Pywikibot. Valores más altos indican un comportamiento más agresivo, valores más bajos son más amables.

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 <span class="plainlinks" style="font-family: monospace,Courier; white-space: pre-wrap !important; word-wrap: break-word; max-width: 1200px; overflow: auto;" title="<translate nowrap> <tvar name=1>#wikimedia-tech</tvar> on Libera.Chat IRC</translate>">#wikimedia-tech ^{<translate> connect</translate>} on IRC.

Interactive tasks (where a user is waiting for the result) may omit the maxlag parameter. Noninteractive tasks should always use it.

Nota que el caching capa (Barniz o calamar) también puede generar mensajes de error con un 503 código de estado, debido a timeout de un río arriba servidor. 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 /Waiting for [^ ]*: [0-9.-]+ seconds? lagged/

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