MongoDBのバックアップとリカバリー

    データベースの安全性を確保するためには、日々のバックアップとリストアが欠かせません。MongoDBのバックアップとリストアは、一般的に独自のツールを使って実行されます。

     バックアップの話を始める前に、リカバリーポイントターゲットとリカバリータイムターゲットという2つの概念を理解する必要がありますが、これについては別々に見ていくことにします。

• リカバリーポイントのターゲット。

(RPO、リカバリーポイントオブジェクティブとも呼ばれる)

つまり、どの時点までならデータを復旧できるか、どの程度の損失まで耐えられるか、ということ。

• 回復時間の目標値。

(RTO、recover time objectiveとも呼ばれる）、障害発生時にデータベースが停止していることに耐えられる時間。

この2つの概念を念頭に置くことで、異なるバックアップ・リカバリ手法によってRPOとRTOをどの程度満たすことができるかを理解することができるのです。

バックアップツールに目を向けること。

Mongodumpツール

MongoDBでは、通常バックアップのためにmongodumpツールを使用します。以下のような特徴があります。

1. mongosとmongodの両方に対して操作できる

2、バックアップはデータとデータ構造で、bsonデータ形式で保存されます

3. インデックスはバックアップされず、インデックスのメタデータのみがバックアップされ、リカバリ時にのみインデックスの再構築が行われます。

4、バックアップ中、mongodumpはデータをメモリに一括ロードします。この方法は、データ量が比較的大きい場合、メモリリソースを占有し続けることになり、IO負荷の圧迫を増加させることになるのです。

5. データベース全体、コレクション全体、コレクションの一部をバックアップすることができます

ツールのデメリット

1. 小規模な、または単一のデータベースのバックアップにのみ適しています。

2, データ容量が大きい場合、バックアップ時間が長くなる

Mongodumpコマンドの使い方の詳細は、mongodump --helpで、以下の共通オプションで確認することができます。

-p, --port: ポート

-h, --host: IP アドレス

-d, --db: データベース

-c, --collection: バックアップするコレクション名

-q, --query: バックアップされたデータに対する条件式

-o, --out: バックアップファイルの場所

-u, --username: ユーザー名

-p, --password: パスワード

--authenticationDataBase: 認証データベース

以下に使用例があります。

Mongorestoreツール

   データのバックアップとデータ復旧は切っても切れない関係にあります。なぜなら、データはバックアップされ、本来は復旧のために準備されるものであり、バックアップされたデータが復旧できなければ、バックアップの意味がないからです。

    MongoDBでは、データ復旧にはMongorestoreというツールを使用しますが、データ復旧コマンドの共通パラメータは以下の通りです。

mongodumpで複製された部分は繰り返しません

-p, --port

-h, --host

-d, --db

-c, --collection

-dirを指定します。リカバリーファイルが保存される場所です。データベースフォルダまたはコレクションファイルが指定された場合、現在のデータベースまたは現在のコレクションのみが復旧され、指定されなかった場合は、現在のディレクトリにあるすべてのバックアップデータが復旧されます。

-drop。既存のデータベースを削除してからリストアする

-u, --user

-p, --password

--authenticationDatabase

以下はサンプル例です。

データのバックアップ例

Back up all databases
mongodump --port=27017 -h 127.0.0.1 -o /data/mongodb_backup -u root -p 123456 
2020-11-23T23:40:41.599+0800 writing admin.system.users to 
2020-11-23T23:40:41.626+0800 done dumping admin.system.users (3 documents)
2020-11-23T23:40:41.626+0800 writing admin.system.roles to 
2020-11-23T23:40:41.651+0800 done dumping admin.system.roles (1 document)
2020-11-23T23:40:41.651+0800 writing admin.system.version to 
2020-11-23T23:40:41.680+0800 done dumping admin.system.version (2 documents)
2020-11-23T23:40:41.680+0800 writing test.yeyz to 
2020-11-23T23:40:41.680+0800 writing yeyz.test to 
2020-11-23T23:40:41.726+0800 done dumping yeyz.test (2 documents)
2020-11-23T23:40:41.727+0800 done dumping test.yeyz (3 documents)

Back up the yeyz database
[root@VM-0-14-centos ~]# mongodump -d yeyz --port=27017 -h 127.0.0.1 -o /data/mongodb_backup -u root -p 123456 --authenticationDatabase admin   
2020-11-23T23:41:58.991+0800 writing yeyz.test to 
2020-11-23T23:41:59.050+0800 done dumping yeyz.test (2 documents)

Back up the records with name=ccc in the test collection in the yeyz database
[root@VM-0-14-centos ~]# mongodump -d yeyz -c test -q '{name:{$eq:"ccc"}}' --port=27017 -h 127.0.0.1 -o /data/mongodb_backup -u root -p 123456 --authenticationDatabase admin
2020-11-23T23:43:24.473+0800 writing yeyz.test to 
2020-11-23T23:43:24.501+0800 done dumping yeyz.test (1 document)

データ復旧例

Before recovery
> use yeyz
switched to db yeyz
> show tables;
test
> db.test.find()
{ "_id" : ObjectId("5fa7eae2515b814f18f2d474"), "name" : "ccc" }
{ "_id" : ObjectId("5fa7f00e523d80402cdfa326"), "name" : "bbb" }

After recovery
> show tables;
test
test_recover
> db.test_recover.find()
{ "_id" : ObjectId("5fa7eae2515b814f18f2d474"), "name" : "ccc" }

上記のyeyzデータベースのtestコレクションからtest_recoverコレクションにname=cccのレコードを回収することに成功しました。

物理的なバックアップ

    物理的なバックアップの概念は誰もが理解しているはずで、一般的な方法は、物理的なハードディスクにデータベースファイルをコピーすることです。

    複製された物理ファイルが実際のデータベースファイルと一致するようにするためには、現在のデータベースへの書き込みがないことを確認する必要があります。もしデータベースへの書き込みがあれば、複製されたデータは不正確なものになります。そのため、物理レプリケーションは MongoDB インスタンスが停止しているかロックされている間に行う必要があります。一般にMongoDBクラスタでは、ロックされたスレーブをバックアップに使います。

    通常、使用する。

db.fsyncLock()でデータベースからロックします。

db.fsyncUnlock() は、データベースのロックを解除します。

    スレーブノードでデータベースをロックした後は、スレーブノードの物理ファイルコピーでバックアップを取るだけです。

    バックアップが完了したら、データベースのロックを解除することができます。

最後に、データをバックアップする際、書き込みがあった場合、バックアップされたデータは不正確なものになるのでしょうか？例えば、以下のようなものです。

バックアップの進捗が中途半端な場合、すなわち

    ライブラリAのバックアップが完了した時点で、ライブラリBのバックアップが開始されていない場合

この時点では、A文書とB文書が別々に書き込まれているため、最終的なバックアップ結果には、Aデータベースには新しいデータがなく、Bデータベースには新しいデータがあり、データの不整合が発生する。この問題を解決するために、バックアップは通常、データベースをロックするか、インスタンスを停止することで解決されます。

    MongoDBでは、スレーブライブラリでロックやインスタンス停止などのバックアップ操作を行うことができます。オンライン環境でMongoDBのシングルライブラリを使うのはおすすめしません。この場合、バックアップのリカバリーがボトルネックになってしまうからです。

以上、MongoDBのバックアップとリカバリーについて詳しく説明しましたが、MongoDBのバックアップとリカバリーについては、Scripting Houseの他の関連記事にも目を通してください