質問
2つのMongoDBの破片のセットアップがあります。各シャードには、マスター、奴隷、24時間の奴隷遅延奴隷、アービターが含まれています。しかし、バランサーは、遅延した奴隷が移動するのを待っているシャードを移動することに失敗します。 Balancer Configで_SecondaryThrottleをFalseに設定しようとしましたが、まだ問題があります。
移行は1日続くように見え、その後失敗します（ログ内の奴隷メッセージを待っています）。最終的にはあきらめて、新しい移行を開始します。メッセージには3人の奴隷が待っていると書かれていますが、遅延奴隷は隠されており、Prio 0なので、それを待つ必要があります。そして、_secondarythrottleが機能した場合、奴隷を待ってはいけませんか？
これは数ヶ月間このようなものだったので、すべてのモンゴスで構成がリロードされるべきでした。バランサーを実行しているモンゴスのいくつかは最近復活者になっています。
誰かが問題を解決する方法を知っていますか？遅延奴隷を始める前にこれらの問題はありませんでしたが、それは私たちの理論です。
構成：
https://stackoverflow.com/questions/20353263
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian{ "_id" : "balancer", "_secondaryThrottle" : false, "stopped" : false }
SHARD1マスタープロセスからログ：
MigrateThread]警告：「XXX.XXX」の3人の奴隷を待っているコミットを移動：objectID（ '4FD2025AE087C37D32039A9E'）} - > {objectID（ '4FD2035AE087C37F04014A79'）重要なセクションを入力する前に追いつくための複製
SHARD2マスタープロセスからログ：
TUE DEC 3 14：52：25.302 [conn1369472] MoveChunkデータ転送進行：{Active：true、ns： "xxx.xxx"、from： "shard2/mongo2：27018、mongob2：27018"、min：{shardkey：objectid（ '4fd2025ae087c37d32039a9e'）}、max：{shardkey：objectid（ '4fd2035ae087c37f04014a79'）}、shardkeypattern：{shardkey：1.0}、 "calcup：{cloned：cloned：cloned： 0}、OK：1.0}私のMEMを使用：0
更新：Slavedelayを削除することで、Balancerが再び動作したことを確認しました。彼らがスピードチャンクを移動するために立ち上がるとすぐに。したがって、問題はスレーブレイに関連しているようです。また、バランサーが「SecondaryThrottle」：Falseで実行されることを確認しました。とにかく奴隷を待っているようです。
shard2：
TUE DEC 10 11：44：25.423 [MigrateThread]警告： 'xxx.xxx' {shardkey：objectid（ '4ff1213ee087c3516b2ff703f'）}}の3人の奴隷を待っているコミットを移動します52A6F089：81
12月10日火曜日11：44：26.423 [Migratethread]クリティカルセクションに入る前にレプリケーションが追いつくのを待っています
12月10日火曜日11：44：27.423 [Migratethread]クリティカルセクションに入る前にレプリケーションが追いつくのを待っています
12月10日火曜日11：44：28.423 [MigrateThread]批判的セクションに入る前にレプリケーションが追いつくのを待っています
12月10日火曜日11：44：29.424 [MigrateThread]クリティカルセクションに入る前にレプリケーションが追いつくのを待っています
12月10日火曜日11：44：30.424 [MigrateThread]クリティカルセクションに入る前にレプリケーションが追いつくのを待っています
12月10日火曜日11：44：31.424 [Migratethread]批判的セクションに入る前に複製が追いつくのを待っています
Tue Dec 10 11:44:31.424 [migrateThread] migrate commit succeeded flushing to secondaries for 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }
TUE DEC 10 11：44：31.425 [Migratethread]移行コミット 'xxx.xxx' {shardkey：objectid（ '4ff1213ee087c3516b2f703f'）
Tue Dec 10 11:44:31.647 [migrateThread] migrate commit succeeded flushing to secondaries for 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }
TUE DEC 10 11：44：31.667 [MigrateThread]移行コミット 'xxx.xxx' {shardkey：objectid（ '4ff1213ee087c3516b2f703f'）
解決
バランサーは、宛先シャードのレプリカセットの大部分が、ソースシャード上のこれらのドキュメントの削除を開始する前にドキュメントを移行するように適切に待っています。
問題は、レプリカセットに4人のメンバー（マスター、奴隷、24時間の奴隷遅延奴隷、仲裁人）がいることです。つまり、3つが過半数であることを意味します。なぜアービターを追加したのかはわかりませんが、削除すると、2つが大多数であり、バランサーは遅延奴隷を待つ必要はありません。
同じ結果を達成する別の方法は、遅延した奴隷をでセットアップすることです votes:0 プロパティとアービターを3番目の投票ノードとして残します。
他のヒント
どのバージョンを実行していますか？ 2.4.2以下には既知のバグがあり、2.2.4以下には、セット内の二次数の数が誤ってカウントされます（したがって、デフォルトを満たすことができなくなります。 W：過半数 移行のために書く）。これはバグです（2.4.3+および2.2.5+で固定）：
https://jira.mongodb.org/browse/server-8420
セカンダリスロットルをオフにすることは有効な回避策である必要がありますが、 flushrouterconfig いずれか mongos プロセス（またはすべてを再起動します mongos プロセス）特に時間をかけている場合は、設定が移行に有効になっていることを確認します。アップグレードする前に別の潜在的な修正として、 local.slavesコレクションをドロップします （再作成されます）。
