問題タブ [mongodump]

3 メンバーのレプリカ セットがあります。それぞれが Linux で mongod 2.4.8 を実行しています。MMS エージェントを使用してレプリカセット/ホストの状態を監視していますが、すべて正常に表示されます。

私は mongodump を使用してデータベースをバックアップしていますが、次のように --oplog スイッチを使用しない場合はダンプを成功させることができます。

mongodump -v --db "mydb" --out /backups

ただし、ライブ データベースをバックアップしているので、 --oplog スイッチを使用したいと考えています。そのため、コマンドを変更して --oplog スイッチを含め、--hosts スイッチでレプリカ セットを指定しました。

mongodump -v --oplog --host myrepset/m1:27017,m2:27017,m3:27017 --db "mydb" --out /backup

ただし、このコマンドは次のエラーで失敗します: oplog モードはフル ダンプでのみサポートされます。

これは明らかに、単一のインスタンスで --oplog スイッチを使用しようとしたときにスローされるエラーと同じです。

mongo のチュートリアルとリファレンス ページを読みましたが、何が間違っているのかわかりません。http://docs.mongodb.org/manual/reference/program/mongodump/

どんな助けでも大歓迎です。

mongorestore を使用してデータベースを復元しましたが、アプリケーションを実行しようとすると、インデックスが既に存在するというエラーが表示されます。

関数 db.collection.dropIndex() は知っていますが、これを自動化し、データベース内のすべてのコレクションからすべてのインデックスを一度に削除する方法はありますか?

私はもう試した

しかし、それではうまくいきません。何か案は？

Ubuntu 10.04 で MongoDB 2.2 を実行する 3 サーバーのレプリカセットがあり、最近、特定のデータベースが存在する各サーバーのハード ドライブをアップグレードする必要がありました。このデータベースには、Web サービス要求のログ情報が含まれており、現在のタイムスタンプを使用して 1 時間ごとのバケット内のコレクションに書き込み、名前を特定します (例: log_yyyymmddhh )。

私はこのプロセスを実行しました：

• mongodump --db log_dbを使用して、プライマリ サーバー上のデータベースをバックアップします。
• セカンダリ サーバーをオフラインにし、ディスクを交換する
• セカンダリ サーバーをスタンドアロン モードで起動します (つまり、サービスを開始する前に、/etc/mongodb.conf の replSet エントリをコメント アウトします)。
• mongorestore --drop --db log_dbを使用してセカンダリ サーバーにデータベースを復元します。
• セカンダリ サーバーをレプリカセットに追加してオンラインにし、レプリケーションがオフラインの間に更新/作成された 1 時間ごとのバケットに追いつくようにします。

バックアップ時に現在のバケットであったコレクションがレプリケーションによって最新のものにならなかったことを除いて、すべてが期待どおりに進んでいるように見えました。最新の状態にするには、そのコレクションを手動でコピーする必要がありました。バックアップ後に作成されたコレクションは問題なく同期されていることに注意してください。

MongoDB がその 1 つのコレクションの同期を取り戻せなかった原因は、このプロセスで何が欠けていたのでしょうか? 私は、oplogに関して何かがうまくいかなかったと思いますか?

編集1：

プライマリの oplog は、最初のタイムスタンプが数日さかのぼったことを示していたため、数時間 (セカンダリがオフラインだった時間) トランザクションを維持するための十分なスペースがあったはずです。

編集2：

MongoDB のインストールでは、/dev/sda1 と /dev/sdb1 の 2 つのディスク パーティションを使用します。プライマリ MongoDB ディレクトリ /var/lib/mongodb/ は /dev/sda1 にあり、いくつかのデータベースを保持しますが、ログ データベースは /dev/sdb1 に単独で存在します。/dev/sdb1 のディレクトリを指すシンボリックリンク/var/lib/mongodb/log_dbがあります。ログ データベースがいっぱいになったため、/dev/sdb1 のディスクをアップグレードする必要がありました。

私の最初のサーバーでは、次のようになります。

このデータベースを mongodump/mongorestore で移行した後、2 番目のサーバーで次のようになります。

数時間待った後、mongo はインデックス作成を終了しました。

データベースをテストしましたが、破損したデータや欠落したデータはありません。

移行前と移行後にサイズに大きな違いがあるのはなぜですか?

大量のデータを持つ mongodb インスタンスがあり、データなしで同じ構造を持つ新しいインスタンスを起動する必要があります。

それを成し遂げる方法は？

私はMongo GridFSを使用しており、かなり大きなMongoデータベースを使用しており、db.stats()コマンドを使用すると、現在dataSizeは89GBです。

mongo ダンプを作成すると、ファイル システムのディレクトリ サイズは 86 GB になり、データベースを別のマシンに復元して実行するdb.stats()と、122 GB になります。

ダンプ/復元後に dataSize が 33GB 増加する理由を知っている人はいますか?

編集 これが初期データベースの統計です

そして、ここに復元されたデータベースからの統計があります

考えられる原因のいくつかの考えを次に示します。

1. どういうわけか、復元されたバージョンにはさらに 40 個のオブジェクトがあります。
2. 異なる mongo バージョンは、インデックス作成アルゴリズムがどのように変更されたかの原因である可能性がありますか?
3. 初期データベースはレプリカセットにありました
4. 最初のデータベースは 320 GB でしたが、すべての画像を圧縮して、しばらく前に 75 GB に減らしました。そのため、初期データベースのストレージ サイズが大幅に大きくなっています

mongodump コマンド:

結果:

壊れたドキュメントでデータベースを復元するのに問題があります。mongorestore壊れた文書が出てきたときに復元を停止します。ここにエラーがあります。

実際、バックアップ前に同じエラーが発生しました。ドキュメントが破損した理由はまだ不明です (予期しないシャットダウンである可能性があります)。サーバーとジャーナリングが有効になっている場合、レプリカ セットは使用されません。壊れたドキュメントを取得する.find()コマンドは常に失敗しました。壊れたドキュメント.valid()もコマンドで識別されます。しかし、mongodb はdb.repairDatabase()andでそれを回復できませんでしたmongod --repair。私の一時的な対策は、を使用してデータをバックアップし、コマンドmongodumpを使用して壊れたドキュメントを削除しました。.remove()

問題は、バックアップから完全なデータベースを復元する方法と、それを適切に修復する方法です。壊れたドキュメントがある (またはない) データベースを復元する方法はありますか?

MongoDB バージョン: 2.6.1