Mongodumpがアプリのパフォーマンスに本当に悪い影響を与える
シャーディングのない非常に大きなmongoインスタンス（150 GB）があり、定期的なバックアップ（mongodump）はアプリのパフォーマンスに非常に大きな影響を与えます。さらに悪いことに、アプリはmongoを頻繁に使用するため、バックアップは10時間以上かかります。
シャーディングが必要であることはわかっています。ElasticSearchに移行する計画があるので、短期的な解決策を探しています。
Mongodumpなどの1秒あたりのクエリ数を制限するなど、これを改善するために何かできることはありますか？
32コアの190 GBにスタンドアロンのmongoがありますRAM nginx、rabbitmqなどの小さなものと共有するサーバーです。これまでで最もクリーンなセットアップではありません。
mongodumpを介してダンプされたすべてのデータは、MongoDBサーバーによってメモリに読み込まれる必要があります。 mongodumpがデータとインデックスの定義をバックアップすることにも注意してください。 mongorestoreはデータのロード後にセカンダリインデックスを再作成する必要があるため、他のアプローチと比較して、復元にかかる時間も大幅に長くなる可能性があります。
MongoDBのドキュメントに記載されています のように、mongodumpは小規模なデプロイメントのバックアップと復元には役立ちますが、大規模なシステムの完全バックアップのキャプチャには理想的ではありません。
MongoDBインスタンスに接続すると、mongodumpはmongodのパフォーマンスに悪影響を与える可能性があります。データがシステムメモリよりも大きい場合、クエリによってワーキングセットがメモリからプッシュされ、ページ違反が発生します。
スタンドアロンサーバーでは、バックアップを取得している間も展開を利用できるようにしたい場合、 バックアップオプション を制限します。
推奨されるアプローチのいくつかを、推奨されるものから推奨されるものの順に示します。
アプローチ＃1：クラウドバックアップサービスを使用する
最も簡単な短期解決策として、 MongoDB Cloud Manager のような商用クラウドバックアップサービスの使用を検討します。 MongoDB Cloud Managerは、スケジュールされたスナップショットと保持ポリシーを使用して継続的なバックアップを提供します（詳細については バックアップの準備 を参照してください）。クラウドサービスでは、追加のサーバー/インフラストラクチャを展開する必要もないため、将来的に展開する予定がある場合でも、これは役立つ短期的なソリューションです。
一般的なアプローチは次のとおりです。
- スタンドアロンサーバーを単一ノードのレプリカセットに変換する （つまり、
replSetパラメーターで再起動し、rs.initiate()を実行します）。 - MongoDB Cloud Manager にサインアップします。
- Cloud Manager Backup Agentをダウンロードしてインストールします。
追加の利点として、Cloud Managerには、デプロイメントから metrics history をキャプチャしてアラートを設定できるモニタリングエージェントも含まれています。
アプローチ2：展開をレプリカセットに変換し、非表示のセカンダリからバックアップする
この方法では、追加のインフラストラクチャをプロビジョニングする必要がありますが、バックアップの影響をプライマリサーバーからオフロードします。通常、レプリカセットは高可用性と自動フェイルオーバーのために少なくとも3つのメンバーでプロビジョニングされますが、唯一の目標がバックアップである場合は、理想的ではない2サーバー構成を使用できます。
一般的なアプローチは次のとおりです。
- バックアップに使用される2番目のサーバーをプロビジョニングする
- スタンドアロンサーバーをレプリカセットに変換 。
- バックアップサーバーを hidden secondary として追加し、優先度は0（プライマリにはなりません）、投票数は0にします。
- サポートされているバックアップ方法 のいずれかを使用して、非表示のセカンダリでバックアップを作成します。バックアップ方法は、推奨の一般的な順序でリストされています。ファイルシステムスナップショット（構成でサポートされている場合）またはファイルコピー（
mongodを停止した場合）は、mongodumpよりも望ましいです。 - （理想的には）レプリカセット構成の高可用性とフェイルオーバーの利点が必要な場合は、別のデータベアリングセカンダリを追加します。
アプローチ＃3：ファイルシステムのスナップショットを使用する（利用可能で適切な場合）
現在のmongodumpよりも影響の少ないバックアップ戦略は、スナップショットをサポートするファイルシステムがあることを前提として filesystem snapshots を使用することです（すべてのデータとジャーナルファイルが単一のボリューム上にあるため、実行中のmongod）の一貫したスナップショットを取得できます。ファイルシステムのスナップショットの利点は、mongodによってすべてのデータをメモリに読み込む必要がないことですが、スナップショットは引き続き影響を与える可能性があります（特に、ビジーなシステムで初期スナップショットを作成する場合）。連続したスナップショットはより効率的で影響が少なくなりますが、スナップショットはサーバーに対してローカルであるため、完全なバックアップソリューションではありません（現時点ではスタンドアロンのみです）。
注意事項
アプローチ＃1と＃2はどちらも、レプリケーションを有効にしてバックアップを容易にすることを含みます。 oplog（操作ログ） と呼ばれる特別な制限付きコレクションにすべての書き込み操作が記録されるため、レプリケーションにより、プライマリサーバーにローカルI/Oが追加されます。
将来シャーディングが必要になる可能性が高いとおっしゃっていましたが、そうする前に、MongoDBのワークロードを同じサーバーを共有する他のプロセスから分離します。バックアップ戦略を
mongodumpよりも効率的なものに変更し、リソースの競合を取り除き、ベースラインメトリックの履歴をキャプチャして確認することができる場合...シャーディングはまだ必要ない場合があります。
私はパーティーに遅れましたが、比較的少量のRAM（4 GB RAM、50 GB HD、5 GBデータ）のVMで最近同じ問題に遭遇しました。）私たちの回避策はmongodumpのオプション--forceTableScanおよび、セカンダリを使用する必要がある場合は、--readPreference secondary。これにより、ダンプが10倍から30倍にスピードアップしました。