web-dev-qa-db-ja.com

Mongosバージョン3.0.1シャーディングでの分割チャンクエラー

3つの構成サーバーと2つのシャードがあります。各シャードには、プライマリ、セカンダリ、アービターがあります。

これは、以下のmongod設定で実行されています。

_storageEngine=wiredTiger

wiredTigerJournalCompressor=zlib

wiredTigerCollectionBlockCompressor=zlib
_

Mongosインスタンスは、シャーディングバランシング中にロックを取得できないことについて、以下のログエントリを作成しました。ただし、すべてのデータは問題なくクエリできます。

また、sh.status()コマンドを使用すると、すべてが正常に見えます。

破片：

_{  "_id" : "ib3_prod_rs0",  "Host" : "ib3_prod_rs0/ip-10-0-13-119.ec2.internal:27017,ip-10-0-21-50:27017" }

{  "_id" : "ib3_prod_rs1",  "Host" : "ib3_prod_rs1/ip-10-0-6-138:27017,ip-10-0-8-202.ec2.internal:27017" }
_

バランサー：

_Currently enabled:  yes

Currently running:  yes

    Balancer lock taken at Wed Apr 01 2015 00:00:49 GMT+0000 (UTC) by 54.163.248.60:27017:1427843620:1804289383:Balancer:1681692777

Failed balancer rounds in last 5 attempts:  0

Migration Results for the last 24 hours: 

    No recent migrations
_

どうすればデバッグできますか？

2015-03-31T23：41：06.542 + 0000 I SHARDING [Balancer] moveChunk result：{ok：0.0、errmsg： "could not collect collection lock for cubes_prod.pushqueues to migrate chunk [{：MinKey}、{：MaxKey}） ::によって引き起こされました::サーバーからステータスを取得できませんでした... "、$ gleStats：{lastOpTime：Timestamp 0 | 0、electionId：ObjectId（ '551b29f564e83f84e725241e'）}} 2015-03-31T23：41：06.543 + 0000 I SHARDING [バランサー]バランサーの移動に失敗しました：{ok：0.0、errmsg： "cubes_prod.pushqueuesのコレクションロックを取得してチャンクを移行できませんでした[{：MinKey}、{：MaxKey}）::原因：::からステータスを取得できませんでしたser ... "、$ gleStats：{lastOpTime：Timestamp 0 | 0、electionId：ObjectId（ '551b29f564e83f84e725241e'）}} from：ib3_prod_rs1 to：ib3_prod_rs0 chunk：min：{UserKey：MinKey} max：{UserKey：0}

mongodbsharding
2
klall

あなたが自分で見つけたもの によると、私は詳細な説明を提供できると思います。

チャンクの移行の仕組み（簡略化）

チャンクの移行の仕組みを次に示します（簡潔にするために簡略化しています）。

  1. チャンクが configured chunkSize （デフォルトでは64MB）を超えると、サイズの増加を引き起こしたmongosがチャンクを分割します。
  2. そのチャンクは、元のチャンクが存在していたシャードで分割されます。構成サーバーはレプリカセットを形成しないため、3つの構成サーバーすべてを更新する必要があります。
  3. チャンク数の差が チャンク移行しきい値 に達すると、 クラスターバランサー が移行プロセスを開始します。
  4. バランサーはバランスロックを取得しようとします。このため、どの時点でもチャンクの移行は1つしか存在しないことに注意してください。 （これは何が起こったかの説明で重要になります。）
  5. バランシングロックを取得するには、バランサーがつすべて構成サーバーの構成を更新する必要があります。
  6. バランスロックが取得されると、データはチャンクが最も少ないシャードにコピーされます。
  7. データが宛先に正常にコピーされた後、バランサーは3つの構成サーバーすべてのキー範囲をシャードマッピングに更新します
  8. 最後のステップとして、バランサーはソースシャードに、移行されたチャンクを削除するよう通知します。

あなたの事件で何が起こったのか

データは、チャンクを分割する必要があるポイントまで増加していました。この時点で、3つの構成サーバーがすべて使用可能であり、それに応じてメタデータが更新されました。チャンクの分割は、チャンクの移行に比べて比較的安価な操作であり、頻繁に発生する可能性があるため、負荷がかかると、通常、移行よりも多くのチャンクの分割が行われます。前に述べたように、任意の時点で発生できるチャンクの移行は1つだけです。

何らかの問題により、チャンクが分割された後、チャンク移行しきい値を下回るように十分なチャンクが移行される前に、1つ以上の構成サーバーに到達できなくなりました。時間。結論：移行する必要のあるすべてのチャンクが実際に移行される少し前に、1つ以上の構成サーバーが使用できなくなりました。

現在、バランサーはチャンクを移行したいが、すべての構成サーバーに到達してグローバル移行ロックを取得することができませんでした。したがって、エラーメッセージ。

そのような状況への対処方法

設定サーバーが同期していない可能性があります。この状況に対処するには、-mongodb config servers not in syncに対するAdam Comerfordsの回答を読んでください。手紙に従ってください。

防止する方法

プレーンでシンプル： [〜＃〜] mms [〜＃〜] を使用します。これは無料で、正常性とパフォーマンスに関する多くの情報を提供し、自動化エージェントを使用すると、MongoDBクラスターの管理を大幅に高速化できます。

少なくとも3つのモニタリングエージェントをインストールすることをお勧めします。これにより、他のエージェントとの冗長性を維持しながら、1つのスケジュールされたダウンタイムを確保できます。

MMSにはアラート機能があるため、いずれかの構成サーバーが使用できなくなった場合に通知されます。これは深刻な状況です。

2
Markus W Mahlberg

この問題は、ネットワークの問題であることが判明しました。

すべてのmongo環境をVPCで操作します。バランスをとるときに設定サーバーに接続の問題があったようです。すべてのトラフィックをインバウンド/アウトバウンドで許可すると、mongosから別のエラー「データ転送エラー」が発生しました。

すべての構成サーバーのデータ全体を一掃し、すべてのトラフィックのインバウンド/アウトバウンドを許可して再開するまで、私はまだ行き詰まっていました。

それでも当惑するのは、シャードバランシングに使用されるポートです。エラーなしでモンゴスを介して問題なくシャードを追加できたので、それで十分だと思いました。

誰かがより良い答えを提供できればそれは素晴らしいでしょう。

0
klall