Manual:Maxlag parameter/zh

如果您的MediaWiki是部署在並行式數據庫叢集中（例如维基媒体），頻繁的编辑可能导致副本伺服器出現延誤. 其中一種解決辦法，就是當副本延誤超過某一臨界值之後，中止所有機器人和維護工作. MediaWiki 1.10 引進了 maxlag 參數，讓客戶端的程式可以處理這種情況. 在 1.27 版，maxlag 參數的機制有所改變，只有 請求會使用到它.

使用 時，可以透過 URL 查詢字串或 POST 內文指明以秒為單位的整數作為maxlag 參數. 例如，[/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=1 此链接]显示页面"MediaWiki"的信息，除非延时大于1秒，而[/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 此链接](在结尾加-1)显示了真正的延时但没有页面信息.

If the specified lag is exceeded at the time of the request, a 503 status code is returned (or 200 during API requests, see ), with a response body with the following format:

以下HTTP标头已设置：


 * Retry-After: 建议客户端在重试前等待的最小秒数
 * X-Database-Lag: 最延后的从数据库延时的秒数

在维基媒体项目的建议用法如下：

如果你收到一个延迟错误提示，将你的脚本暂停至少5秒再进行尝试. 当心不要进入负载循环.
 * 使用 maxlag=5 (5秒). 这是个合适的不过分的值，已设为Pywikibot的默认值. 使用更高的值会带来更激进的行为，而更低的值更好.
 * 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.
 * 异常高或持久的延时应当反馈至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. 客户端应当区别对待这些错误，因为它们可能在你尝试运行一个长时间的费时操作时总是发生. 在超时后不断重复操作会占用过多服务器资源并使你的客户端陷入无限循环. 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 标头会在squid错误中出现
 * The response body in replication lag errors will match the regex

为了测试目的，你可以设置一个负值故意让软件拒绝一个请求，例如下列URL：[/w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1 /w/api.php?action=query&titles=MediaWiki&format=json&maxlag=-1].

会检查maxlag参数，action API也会.