1

私は最近 Web アプリを立ち上げましたが、まだあまり生産規模が拡大していませんが、近い将来にはそうなることを期待しています (願っています ;)。

現在の実稼働システムのスナップショットを開発環境にコピーする機能が非常に便利であることがわかりましたdb.copyDatabase()。実稼働データベースが大きくなったり、負荷が高くなったりすると、どのような問題が発生する可能性があるのか​​疑問に思っています。

ドキュメントは、コマンドがブロックされていることを示しているようには見えません (具体的には、コマンドの実行中にいずれかのデータベースにデータが追加された場合、データセットが同期しなくなるという参照があります)。

データベースは開発（またはステージング）サーバーにコピーされているため、インデックスなどの再構築にかかる時間は（少なくともしばらくの間）大きな問題にはなりません。

この場合、ドキュメントはガイドラインに少し軽いので、次のアドバイスを得たいと思っています。

  • 運用中のライブ データベースからコピーするために db.copyDatabase を実行することは適切ですか?
  • ソース データベースにパフォーマンス ヒットはありますか?
  • 実行可能でなくなるサイズに実際的な制限はありますか? (この質問 hereに基づいて、その制限は非常に大きいように見えます)

参考までに、アプリとデータベースは別々にホストされています ( heroku / mongolab )。db.dropDatabase()コマンドの前にローカルで実行copyDatabase()して、完全に新しいデータベースを取得しています。

4

2 に答える 2

7

知っているかどうかはわかりませんが、MongoLabのWebインターフェイスを介して1回限りのバックアップまたは定期的なバックアップをスケジュールできます。これらのバックアップは、独自のカスタムクラウドストレージコンテナー（Amazon S3など）に保存することも、MongoLabにクラウドストレージコンテナーの1つに保存させることもできます。

これらのバックアップはバイナリダンプ（MongoDBのmongodumpツールを介して取得）であり、MongoLabのUIから直接ダウンロードできます。

すべてのデータベースを共有インスタンスに複製し、プライマリの負荷を最小限に抑えるためにセカンダリからバックアップを削除するようにあらゆる努力をします（バックアップはかなりのリソースを消費する可能性があります）。

お役に立てば幸いです。

于 2013-01-22T00:39:33.707 に答える
3

私たちはあなたのハードウェアなどに乗っていないので、この答えは少し主観的になります.

運用中のライブ データベースからコピーするために db.copyDatabase を実行することは適切ですか?

ここでは、バイナリ バックアップの方が適切なオプションである可能性があります: docs.mongodb.org/manual/tutorial/backup-databases-with-binary-database-dumps/

これは基本的に全テーブル スキャンを使用したデータベースの「コピー」であることを考えると、実際にアプリケーションからまったく同じことを行うのと同じ効果があります。一時的に過剰なワーキング セットが発生する可能性があり、データが必ずしも RAM に収まらない場合、コンピューターの LRU 内でスワップが発生する可能性さえあります。

実際にすべてのデータを取り出すのにどれだけのコストがかかるかを作業セットが表していないことがよくあります。仮想メモリ (mmap が移動する) は RAM ではないため、収まらない場合があります。

RAM の問題は別として、非常に多くの要因によって読み取りロックの問題が発生する可能性があります。基本的には、そこで心に留めておくべきことがあります。

私がリストしていない問題が他にもあると確信しています。

ただし、これらの問題のほとんどは非常に大きなデータセットに存在することに注意してください。

実行可能でなくなるサイズに実際的な制限はありますか?

それはすべて、データを待つ準備ができている時間と、サーバーが処理できるワーキングセットの量に依存しますが、リンクされた質問のシナリオを使用して、100GB が適切な制限であると言うでしょう。 .

于 2013-01-17T14:13:31.563 に答える