設定サーバーの発行後にMongoDBのタイムアウトが発生する

Question

私は非常に奇妙な問題があります。昨日、私のConfig Server Replica Setは基本的に動作を停止しました。私はそれを元に戻すことができる唯一の方法は、バックアップでレプリカセットの内容を復元し、レプリカセットを再作成することでした。

これまでのところ、すべてのシャーディングデータが見えていたので、設定サーバのsh.status（）で見ることができます。また、2つのレプリカセットでは、データを照会できます。

しかし、シャードのステータスを取得しようとしたとき、私はtimoutsを取得していますmongosインスタンス上：

mongos> sh.status() 
2016-09-05T09:49:15.645+0000 E QUERY [thread1] Error: error: { "code" : 50, "ok" : 0, "errmsg" : "Operation timed out" } : 
_getErrorWithCode@src/mongo/shell/utils.js:25:13 
DBCommandCursor@src/mongo/shell/query.js:689:1 
DBQuery.prototype._exec@src/mongo/shell/query.js:118:28 
DBQuery.prototype.hasNext@src/mongo/shell/query.js:276:5 
DBCollection.prototype.findOne@src/mongo/shell/collection.js:289:10 
printShardingStatus@src/mongo/shell/utils_sh.js:540:19 
sh.status@src/mongo/shell/utils_sh.js:78:5 
@(shell):1:1 

私はmongosを実行しているサーバーからのmongoを経由してコンフィグサーバに接続することができます。 Mongoのバージョン3.2.7を使用して、私は正しい方向に私を指しているすべてのログが表示されていないとして、この問題を解決する方法が分からない...

コンフィグサーバ上のログに唯一のものはこれです：

2016-09-05T10:09:35.549+0000 I COMMAND [conn1243] Command on database config timed out waiting for read concern to be satisfied. Command: { find: "shards", readConcern: { level: "majority", afterOpTime: { ts: Timestamp 1472281864000|2, t: 30 } }, maxTimeMS: 30000 } 
2016-09-05T10:09:35.551+0000 I COMMAND [conn1243] command config.$cmd command: find { find: "shards", readConcern: { level: "majority", afterOpTime: { ts: Timestamp 1472281864000|2, t: 30 } }, maxTimeMS: 30000 } keyUpdates:0 writeConflicts:0 numYields:0 reslen:92 locks:{} protocol:op_command 30409ms 

Answer 1

あなたの操作は危険です。設定サーバーを復元するだけではいけません。これにより、クラスタメタデータが矛盾する可能性があります。

replset configサーバーを使用している間、mongosは設定サーバーの最新のコミットされたOpTimeであるConfigOpTimeを維持します。これは、設定サーバに送られたリクエスト引数（ReadConcernのAfterOpTime）の値として使用され、mongosは後でロールバックされる可能性のあるデータを読み取らないようにします。 Mongosは、configサーバーまたは他のシャードの応答を通じてこのConfigOpTimeを取得します。

あなたのケースでは、あなたの設定サーバーを復元し、新しい選挙をリードし、OpTimeの新しい用語を導きます。しかし、他の断片はまだ古い設定サーバのOpTimeをキャッシュしていました。そして、通常、それはより高い用語を持っています。 Mongosはこれより高いConfigOpTimeを使用して、これ以降にconfigサーバにデータを要求します。この時点までにconfigサーバが達するまで待たなければなりません（新しい選挙が起こらなければ不可能です）。

クラスタメタデータが正常であれば、mongosを再起動する前にすべてのmongodbファイルを再起動してみてください。