2

MongoDBレプリカセットのサイズを縮小しようとしています（コレクションは同じサイズですが、ディスク容量が増え続けています）。MongoDBのWebサイトによると、すべてのコレクションを圧縮するには、マスターノードでmongod--repairを実行する必要があります。問題は、Webサイトのダウンタイムです。したがって、2つのオプションがあります（私が知っていること）：

  1. レプリカセットからセカンダリノードを削除し、mongod --repairを実行して、レプリカセットで再起動します。私はこれを試しましたが、「ローカル」コレクションで過去の許可エラーを取得できませんでした。

  2. セカンダリノードをシャットダウンし、データディレクトリ内のすべてのファイルを削除します。mongoを再起動し、マスターから回復させます。これは実際にはうまくいきましたが、私の唯一の懸念は、ジャーナルコレクションがいっぱいで、上限のあるコレクションであるため、ジャーナルにあるデータのみを受け取るのか、それともマスターのすべてのデータを実際にコピーするのかということです。

他の誰かがこのシナリオに遭遇しましたか？これを検索しようとすると、情報が不足していることに驚いています。

4

1 に答える 1

1

レプリカセットからセカンダリノードを削除し、mongod --repairを実行して、レプリカセットで再起動します。

これは通常「ローリング修理」と呼ばれる一般的な方法です。レプリカセットから各セカンダリを取り出して修復し、最終的には最後のステップとしてプライマリをステップダウンして修復します。レプリカセットノードの大部分が常に利用可能である限り、このアプローチは潜在的なダウンタイムを最小限に抑えます。

データを頻繁に削除する場合は、MongoDB2.2の新しいPowerOf2Sizesコレクションオプションの使用を検討する必要があります。これにより、割り当て方法が2の累乗でドキュメントスペースを割り当てるように変更され（たとえば、500バイトのドキュメントには512バイトが割り当てられます）、削除されたドキュメントからスペースをより効果的に再利用できます（資料）。

私はこれを試しましたが、「ローカル」コレクションで過去の許可エラーを取得できませんでした。

'local'コレクションのパーミッションエラーは、ファイルシステムのパーミッションのように聞こえます（つまり、実行していたユーザーに基づいていますmongod）。同じユーザーで修復プロセスを実行する必要があります。

セカンダリノードをシャットダウンし、データディレクトリ内のすべてのファイルを削除します。mongoを再起動し、マスターから回復させます。これは実際にはうまくいきましたが、私の唯一の懸念は、ジャーナルコレクションがいっぱいで、上限のあるコレクションであるため、ジャーナルにあるデータのみを受け取るのか、それともマスターのすべてのデータを実際にコピーするのかということです。

Journal耐久性とクラッシュリカバリにOplog使用されるものとレプリケーションに使用されるものを混同しているようです。

プライマリからノードを再同期すると、すべてのデータがコピーされます。この初期期間中、ノードはRECOVERING状態になり、「正常な」ノードとは見なされません（つまり、クエリに使用できます）。

ノードが追いつくと、通常のSECONDARY状態に変わり、その時点oplogで継続的な同期に使用されます。

さらに読む：

于 2012-12-04T01:12:32.800 に答える