シャードされたクラスタを3.2から3.4にアップグレードする際の懸念の度合いを読む

Question

3.2から3.4に2つのレプリカセットを持つMongodDBシャードクラスタをアップグレードしました。現在のストレージエンジンはMMAPv1です。次のコマンドを使用してconfig serverを実行すると、セカンダリ、プライマリ、設定サーバーおよびmongosをすべて3.4に正常にアップグレードした後。

はsudoのmongodは

--configsvr私は次のエラーを得続けます。

SHARDING [シャードレジストリのリロード]シャードレジストリの定期的なリロードが失敗しました:: :: 115が原因で設定サーバーからシャードリストを更新できませんでした。現在のストレージエンジンは多数のreadConcernsをサポートしていません。 30秒後に再試行します

また、設定サーバーとmongosを接続できません。私は、次のコマンドを

を使用して接続しようとするとsudoのmongos --configdb [IP-の-私-config設定 - サーバー]：27019

それは私に、次のエラーが発生します。

BadValueを：てConfigDB私はmongosが原因コンフィグサーバ上の大多数のreadConcernsエラーに設定サーバーに接続できないと仮定のみレプリカセットの接続文字列

をサポートしています。

MongoDBマニュアルには と記載されています。「MongoDB 3.4は、レプリカセットの設定サーバーから読み取ると、「大多数」という読解レベルを使用します。

そして、WiredTiger must be used as storage engine.

を「過半数」の読み取り懸念レベルを使用するので、私はそれを動作させるためにWiredTigerストレージエンジンに切り替える必要がありそうです。私は、二次レプリカセットメンバーのWiredTigerストレージエンジンへの切り替えを行っていたときには、手動

"This procedure completely removes a secondary replica set member’s data"

に応じだから私はこだわって中途半端です。状況は

1. 大多数のreadConcernsに関してエラーを出しています。
2. 私はそれを取り除くためにWiredTigerに切り替える必要があります。
3. WiredTigerに切り替えると、セカンダリメンバーからデータが削除されます。
4. 設定サーバーのエラーのためにこのWiredTiger手順に切り替える際に、データがセカンダリメンバにレプリケートされず、最終的にすべてのデータが失われてしまいます（間違っている場合は修正してください）。

質問は以下のとおりです。

1. 私は、レプリカセットの設定サーバからの読み取り時のMongoDB 3.4は、「ローカル」の読み取り懸念レベルを使用することはできますか？
2. シナリオでデータを失うことなくWiredTigerエンジンに切り替えるにはどうすればよいですか？

Answer 1

あなたはレプリカで、各ノードに移行することができ、新しいデータベースを作成するmongorestoreを使用して、その後、WiredTigerとブランクデータディレクトリと再起動、データをバックアップするmongodumpを使用することにより、as if it was a standaloneを設定します。

通常、レプリカセットノードでは推奨されませんが、セカンダリでデータを消去して他のノードから再同期するほうが簡単なためです。このようにするとうまくいくでしょうが、ダンプと復元ツールを使って少しばかりの作業が必要になります。