MongoDBで大規模なデータセットをバックアップする推奨方法は何ですか？10TBのオーダーのデータサイズがあるとします-どのようにバックアップしますか？

私たちは、隠された、おそらく遅延した、レプリカセットノードを検討しています。遅延は、データベース全体の偶発的なドロップから私たちを保護します。これは実行可能なソリューションですか？調査することをお勧めする他のオプションは何ですか？

ありがとう！

10TBをバックアップする必要があるため、これは少し複雑になります。

レプリカは適切なバックアップの代わりにはなりません

遅延レプリカセットメンバーは、偶発的な操作を支援する比較的簡単な方法を提供できますが、RAIDがファイルシステムベースのバックアップの代わりではないように、適切なバックアップの代わりはありません。

推奨事項

それはセットアップがどのように見えるかに大きく依存します。

SANスナップショット

10TBでは、何らかのSANが接続されていると思います。これらの環境でMongoDBをバックアップする最も簡単な方法は、ファイルシステムとMongoDBの両方でジャーナリングがアクティブになっていることを確認し、セカンダリの1つ（できれば操作を確実にするために隠しボリューム）のSANボリュームのスナップショットを取得することです中断されません。通常、これには数秒しかかかりませんが、レプリケーションoplogウィンドウが十分であることを_確認_してください。それ以外の場合は、セカンダリを再同期する必要があります。

mongodumpを使用しないでください

mongodumpの使用についてRolandoMySQLDBAに反対する必要があります。まず、サーバーにロックを課します。それらは比較的高速に解除されますが、隠されたノードで実行したり、セカンダリにヒットする読み取り設定がない場合を除き、ロックの数が増えて操作に干渉する可能性があります。さらに、それは正確に高速ではありません。少なくとも数時間は実行されると思いますが、おそらく、バックアップウィンドウよりも時間がかかるでしょう。サイドノート：常に--oplogオプションでmongodumpを実行します。また、mongodumpはインデックスをバックアップするのではなく、インデックスを作成する操作をバックアップすることに注意してください。これらのインデックスは、復元中に再作成する必要があり、必要な時間が大幅に増加する場合があります。私の経験から、データベースを復元する必要がある場合は、できるだけ早くデータベースを復元する必要があります。mongodumpが10TBのバックアップに適していないもう1つのポイント。

LVMスナップショットに関する注意

mongodでジャーナリングが有効になっている場合は、実行中のmongodインスタンスでLVMスナップショットを実行できます（私の経験から、FSレベルで有効にしても問題はありません）。ただし、LVMスナップショットにはいくつかの意味があります。まず、バックアップ操作中に変更を反映できる十分なディスク容量が必要であることは明らかです。それを明確にしましょう。

500GBの1時間ごとの変更率があると仮定しましょう。また、ストレージにアップロードする前にバックアップをblipにしたいということです。並列bzip2を使用している場合でも、大容量ストレージスループットが最も可能性が高いという事実が制限要因になるため、10TBの圧縮が完了するまでに数時間かかることがあります。データを2TBに圧縮するのに2時間かかると仮定しましょう。そのため、今では合計2TB + 2 * 500GBの空きディスク領域が必要になり、LVMスナップショットには1TBが必要になります。これにより、少なくともファイルシステムをオーバープロビジョニングする必要が生じます。30％。適切な安全マージンを確保したい場合、これは簡単に60-70％（元のファイルシステムの使用率0.8で20％、スナップショットサイズとbzipされたバックアップ自体に必要なスペースで同じ）に簡単に増加する可能性があります）。ほとんどの実稼働環境では、オーバープロビジョニングは静的であるため、これは受け入れられません（バックアップスクリプトでLVMを動的に変更したくないでしょうか？）。

MMSバックアップ

MMSバックアップにはいくつかの素晴らしい機能（連続バックアップ、簡単なポイントインタイムリカバリ）がありますが、いくつかの重大な欠点があります。大規模な展開のための価格は数千になります。これらの10TBで500GBの1時間ごとの変化率を想定すると、クラウドバックアップでは 6桁の中程度の合計になります。毎月。

バックアップを含め、オンプレミスのMMSインスタンスを持つ資格を得るために、サーバーのエンタープライズサブスクリプションを取得することをお勧めします。

概要

以下に、優先度の高い順に選択するオプションを示します。

1. SANスナップショット：実装が簡単で、比較的安価
2. エンタープライズサブスクリプション：最高の機能。インストールし、構成し、忘れて、必要なときにそこにある
3. LVMスナップショット：簡単に実装できますが、必要なオーバープロビジョニングのコストは時間の経過とともに増加する可能性があります。

2つのオプションがあります

物理的なバックアップ

ダウンタイムを気にしない場合、最も簡単なことは

service mongod stop

LVMスナップショットを実行するかcp、Mongoデータフォルダーを別のディスクにブルートフォースします。

service mongod start

もちろん、10TBのデータがスタンドアロンマシン上にある場合、ダウンタイムは必要ありません。

遅延レプリカセット

3つのノードを持つレプリカセットがある場合は、バックアップにいずれかのノードを使用します

{
        "_id" : "myreplica",
        "version" : 1,
        "members" : [
                {
                        "_id" : 1,
                        "host" : "10.20.30.40:27017",
                        "priority" : 2
                },
                {
                        "_id" : 2,
                        "host" : "10.20.30.41:27017"
                },
                {
                        "_id" : 3,
                        "host" : "10.20.30.42:27017",
                        "priority" : 0,
                        "slaveDelay" : 3600
                }
        ]
}

"_id' : 3すべての物理バックアップでノードを使用します。したがって、ダウンタイムはありません。真夜中のスナップショットを取得するには、隠しノードが1時間遅れているため、午前1時にバックアップを起動できます。

もちろん、欠点は、それぞれ10 TBのサーバーが2つ以上あり、システム管理者の健全性が危険にさらされることです。

モンゴダンプ

スタンドアロンマシンに対してmongodumpを使用できますが、mongodumpは他の接続と同様の接続を使用するクライアントプログラムであるため、パフォーマンスの低下を予期する必要があります。

ポイントインタイムバックアップが必要な場合は、使用する必要があります

mongodump --oplog 

論理BSONバックアップは、物理バックアップよりも小さくなります（特にgzipまたはbzipで圧縮されます）。

使用mongodump --oplogは、非表示ノードに対して行うのが最適です。そうすれば、マスターのパフォーマンスが低下することはありません。

免責事項

私はMongoDB（偶発的/偶発的なMongoDBA）に比較的慣れていません。私の答えがお役に立てば幸いです。