アプリケーションまたは人為的エラーデータの破損における大きな問題の1つは、プライマリへの問題のある書き込みがすぐにセカンダリに複製されることです。
これは、ユーザーが「slaveDelay」を利用する理由の1つです。これは、固定時間遅延でセカンダリノードの1つを実行するオプションです（もちろん、これは、より短い期間中にエラーまたはバグを発見した場合にのみ役立ちます）。そのセカンダリの遅延）。
このような設定がない場合は、バックアップを使用して、バグ前の状態に復元する必要のあるレコードの状態を再作成する必要があります。
データの個別のスタンドアロンコピーですべての操作を実行します。すべてが適切に再作成されたことを確認した後でのみ、修正したデータを本番システムに移動する必要があります。
これを実行できるようにするために必要なのは、バックアップの最新のコピー（たとえば、バックアップがX時間前のものである）であり、クラスター上のoplogはX時間以上のデータを保持する必要があります。 （a）レプリカセットのすべてのメンバーがoplogの内容が同じであり、（b） であるため、どのノードのoplogを指定しませんでした。 ノードメンバーごとにoplogサイズが異なる可能性があります。その場合は、「最大」のメンバーを確認する必要があります。
つまり、最新のバックアップが52時間前のものであるとしましょう。しかし、幸いなことに、75時間分のデータを保持するoplogがあります（イェーイ）。
すべてのノード（プライマリとセカンダリ）に「不良」データがあることにすでに気付いているので、この最新のバックアップを新しいmongodに復元します。ここで、これらのレコードを問題のある更新の直前の状態に復元します。次に、それらを現在のプライマリに移動して、そこからすべてのセカンダリに複製することができます。
バックアップを復元するときに、次のコマンドを使用してoplogコレクションのmongodumpを作成します。
mongodump -d local -c oplog.rs -o oplogD
oplogを独自のディレクトリに移動し、名前をoplog.bsonに変更します：
mkdir oplogR
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson
次に、「問題のある」操作を見つける必要があります。 bsondumpを使用して、人間が読める形式にoplogをダンプできます。 oplogR / oplog.bsonファイルに対するコマンド（次に、grepまたはwhat-notを使用して「不良」アップデートを見つけます）。または、use localを使用して、レプリカセット内の元のoplogに対してクエリを実行することもできます。 およびdb.oplog.rs.find() シェル内のコマンド。
あなたの目標は、このエントリを見つけて、そのtsに注意することです。 フィールド。
次のようになります：
"ts" : Timestamp( 1361497305, 2789 )
mongorestoreに注意してください コマンドには2つのオプションがあります。1つは--oplogReplayと呼ばれます もう1つはoplogLimitと呼ばれます 。復元されたスタンドアロンサーバーでこのoplogを再生しますが、この問題のある更新操作の前に停止します。
コマンドは次のようになります（ホストとポートは新しく復元されたバックアップがある場所です）：
mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
これにより、oplogRディレクトリのoplog.bsonファイルから各操作が復元され、ts値Timestamp（1361497305、2789）のエントリの直前で停止します。
別のインスタンスでこれを行った理由は、復元と再生で作成された正しいデータを確認できるようにするためです。確認したら、復元されたレコードを実際のプライマリの適切な場所に書き込むことができます（複製の伝播を許可します）。修正されたレコードをセカンダリに送信します。