2013-03-16 6 views
43

MongoDBのoplogを変更して再生することは可能ですか?MongoDBのoplogの変更と再生

バグにより、アップデートされたドキュメントが、想定されていたよりも多くのドキュメントに適用され、一部のデータが上書きされていました。データがバックアップから復元され、再統合されたため、実際には何も失われませんでしたが、誤った更新を削除または修正して再生する方法があるかどうかは疑問でした。

私はMongoDBの内部について深い知識を持っていないので、 "それがどのように動作するか分かりません"というような有益な答えが受け入れられると考えられます。

+0

技術的には、それは 'local'データベース内の上限のあるコレクションなので、技術的には行を変更して再生することができます。 – Sammaye

+0

普通のコレクションにはできるだけ多くのことを行うことができませんたとえば、レコードを削除してサイズを変更することはできません。しかし、ユーティリティを再生するために利用可能なoplogです。 –

答えて

91

アプリケーションまたは人為的エラーのデータ破損の大きな問題の1つは、プライマリへの問題のある書き込みがすぐにセカンダリに複製されることです。

これは、ユーザが固定遅延時間を使用してセカンダリノードの1つを実行するオプションである「slaveDelay」を利用する理由の1つです(当然のことながら、時間内にエラーやバグを発見した場合にのみ役立ちます)そのセカンダリの遅延よりも短い期間)。

このような設定がない場合は、バグ前の状態に復元する必要があるレコードの状態を再作成するために、バックアップに頼らざるを得ません。

データの独立したスタンドアロンコピーですべての操作を実行します。修正されたデータを運用システムに移すだけで、すべてが正しく再作成されたことが確認されます。

これを実行するために必要なのは、バックアップの最近のコピー(バックアップがX時間経過しているとします)で、クラスタのoplogはX時間分以上のデータを保持する必要があります。私はどのノードのoplogを指定しなかったのですか?(a)レプリカセットのすべてのメンバーがoplogで同じ内容を持っていて、(b)である可能性があります。あなたのoplogサイズは異なるノードメンバー「最大」のものをチェックする。

最新のバックアップは52時間ですが、幸いなことに、75時間分のデータ(yay)を保有しているのはうれしいことです。

すべてのノード(プライマリとセカンダリ)に「不良」データがあることに気が付いたので、この最新のバックアップを新しいmongodに復元します。ここでは、これらのレコードを問題のあるアップデートの直前の状態に復元します。次に、それらをセカンダリに複製する場所から現在のプライマリに移動できます。あなたのバックアップを復元しながら

、このコマンドを経由してあなたのoplogコレクションのmongodumpを作成します。

mongodump -d local -c oplog.rs -o oplogD

それはoplog.bsonするリネーム独自のディレクトリにoplogを移動:

mkdir oplogR 
mv oplogD/local/oplog.rs.bson oplogR/oplog.bson 

今、あなたは "怒っている"操作を見つける必要があります。 oplogR/oplog.bsonファイルのbsondumpコマンドを使用して、oplogを人間が読める形式にダンプすることができます(grepまたはwhat-notを使って "bad"アップデートを見つけることができます)。あるいは、シェル内のuse localおよびdb.oplog.rs.find()コマンドを使用して、レプリカセット内の元のoplogに対して照会することもできます。

あなたの目標は、このエントリを見つけ、そのtsフィールドに注意することです。

それは次のようになります。mongorestoreコマンドは二つのオプション、--oplogReplayと呼ばれる1とoplogLimitと呼ばれる他のを持っていることを

"ts" : Timestamp(1361497305, 2789)

注意。復元されたスタンドアロンサーバーでこのoplogを再生しますが、この問題を引き起こす更新操作の前に停止します。

コマンドは(新しく復元されたバックアップがどこにあるホストとポートがある)のようになります。

mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR

これは、とのエントリーの前に右停止oplogRディレクトリ内oplog.bsonファイルから各操作を復元しますts値タイムスタンプ(1361497305,2789)。

これを別のインスタンスで実行した理由は、復元したデータを検証して正しいデータを作成できたということです。確認したら、復元したレコードを実際のプライマリの適切な場所に書き込むことができます複製が訂正されたレコードをセカンダリに伝播できるようにする)。

+0

ありがとう、これは私が探していたものです。状況はあなたが説明したのと同じように、悪い更新をすでに複製していたノードが遅延していました。 – michaeltwofish

+0

こんにちは。私はMongoを初めて使っているので、このローカルデータベースがすべてのDBとコレクションのoplogを保存しているのか疑問に思っていたのですか?単一のデータベースまたはコレクションを復元する必要がある場合は、どのようにoplogのエントリをフィルタリングしますか? – gansbrest

+0

mongodプロセスごとに1つのoplogしかありません。 –

関連する問題