Manual:Maxlag parameter/ja

(Wikimediaのように)複製データベースクラスター上でMediaWikiを稼働させている場合、高い編集率によってスレイブサーバが遅延することがあります. スレーブの遅延を和らげる一つの方法は遅延がある値を超えたときはすべてのボットとメンテナンスタスクを自動的に停止させることです. MediaWiki 1.10において、導入されたmaxlagパラメーターはクライアントサイドで同じことを行うことを可能にします.

maxlag パラメーターは、URL パラメーター、POST データ、 Cookie を通して index.php に渡せます. 秒数の整数値です. For example, [ this link] edits this page unless the lag is greater than 1 second while [ this one] (with -1 at the end) shows you the actual lag without editing.

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



次のようなHTTPヘッダーが設定されます:


 * Content-Type: text/plain
 * Retry-After: 再試行をする前にクライアントが待つ推奨の最小秒数.
 * X-Database-Lag: もっとも遅延したスレーブの遅延秒数

Wikimediaのwiki群に対する推奨される使い方は次の通りです:


 * 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.
 * 遅延エラーを受け取る場合、再び試す前に少なくとも5秒間はスクリプトを停止させて下さい. ビジーループに陥らないように注意して下さい.
 * この値によって、データベースの負荷が高いときに低いデューティサイクルを得る可能性があります. それはOKで、負荷が高い状態が終わるのを待ってください. 編集を拒否することで利用者の時間を無駄にしたくないため、負荷が高いときは人間を優先します.
 * 普通ではない高いもしくは持続する遅延はirc.freenode.net上のに報告されます.

アップストリームサーバーのタイムアウトが原因で、Squidが503ステータスコードを持つエラーメッセージを生成することもあります. 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. 次の内容によってsquidエラーとMediaWikiの遅延条件を区別出来ます:


 * X-Database-Lag header is distinctive to slave lag errors in MediaWiki
 * squildエラーではRetry-Afterは存在しません
 * X-Squid-Errorヘッダーはsquidエラーで表示されます
 * スレーブ遅延エラーでのリスポンスボディは正規表現の  にマッチします

テストの目的のために、負の値を渡すことで故意にソフトウェアにリクエストを拒否さ競ることが出来ます. 例えば次のURLです: []

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