web-dev-qa-db-ja.com

大規模なMongoDBデータベースをバックアップする方法

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

非表示の、おそらく遅延したレプリカセットノードを検討しています。この遅延により、データベース全体が誤ってドロップされるのを防ぐことができます。これは実行可能なソリューションですか、他にどのようなオプションを調査することをお勧めしますか？

よろしくお願いします！

replicationbackupmongodb
15
Malakim

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

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

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

推奨事項

これは、セットアップの状態に大きく依存します。

SANスナップショット

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

Mongodumpを使用しない

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

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

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

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

MMSバックアップ

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

私の提案では、バックアップを含め、オンプレミスのMMSインスタンスを使用する資格を得るためにサーバーに エンタープライズサブスクリプション を適用することをお勧めします。

概要

以下は、優先順位の高い順に取るオプションです。

  1. SANスナップショット：実装が簡単で、比較的安価
  2. エンタープライズサブスクリプション：最高の機能。インストールして、設定して、忘れてください。必要なときにそこにあります
  3. LVMスナップショット：実装は簡単ですが、必要以上のプロビジョニングのコストは時間の経過とともに合計される場合があります。
21
Markus W Mahlberg

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

物理的バックアップ

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

service mongod stop

LVMスナップショットまたは別のディスクへのMongoデータフォルダーのブルートフォースcpを実行します

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のすべての物理バックアップがあるノードを使用します。したがって、ダウンタイムはありません。午前0時のスナップショットを取得するには、非表示のノードが1時間遅れているため、午前1時にバックアップを起動できます。

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

[〜＃〜] mongodump [〜＃〜]

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

ポイントインタイムバックアップが必要な場合は、

mongodump --oplog

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

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

免責事項

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

5
RolandoMySQLDBA