序章

定期的なデータベースのバックアップは、意図しないデータ損失イベントを防ぐための重要なステップです。 一般に、バックアップには、ファイルシステムレベル(「物理」)バックアップと論理バックアップの2つの大きなカテゴリがあります。 ファイルシステムレベルのバックアップには、ある時点で基になるデータファイルのスナップショットを作成し、スナップショットされたファイルにキャプチャされた状態を使用してデータベースがそれ自体をクリーンに復元できるようにすることが含まれます。 論理バックアップには、ツールの使用が含まれます(例: mongodumpまたはpg_dump)を使用して、データベースからバックアップファイルにデータをエクスポートします。バックアップファイルは、対応する復元ツール(例: mongorestoreまたはpsql <)。

このガイドでは、ドロップレットスナップショットを使用して、実行中のMongoDBインストールのファイルシステムレベルのバックアップを実行する方法を示します。 さらに、スナップショットイメージから復元を実行する方法についても説明します。

注: DigitalOceanバックアップガイドで詳しく説明されているように、Dropletスナップショットを使用すると、特に負荷の高いデータベースでパフォーマンスに影響があります。 最初に、シミュレートされた負荷のある非本番データベースを使用してこの手順をテストし、この方法が本番デプロイメントで機能することを確認する必要があります。

前提条件

このガイドを開始する前に、次の前提条件の手順を完了していることを確認してください。

このガイドでは、ジャーナリングが有効になっているデフォルトのWiredTigerストレージエンジンを使用して、MongoDB3.2以降がインストールされていることを前提としています。 さらに、このガイドを使用するには、dbpathディレクトリ(データファイルを含むディレクトリ、デフォルトでは/var/lib/mongodb)が単一のボリュームにマップされていることが重要です。 ドロップレットに追加のブロックストレージボリュームを接続していない場合は、このガイドに従うことができます。

Dropletにログインし、MongoDBを起動して実行すると、開始する準備が整います。

ステップ1—MongoDBセットアップを確認します

まず、ジャーナリングが有効になっていることを確認します。

ジャーナリングはMongoDBの機能であり、ジャーナルファイルに操作を書き込むことで、データベースに障害が発生した場合の耐久性を提供します。 MongoDBジャーナリングの詳細については、MongoDBマニュアルを参照してください。

上記のガイドに従った場合、ジャーナルはデフォルトで有効になります。 これが事実であることを確認するために、MongoDB構成ファイルを調べることができます。

たとえば、nanoなどのお気に入りのテキストエディタを使用して/etc/mongod.confを開きます。

  1. nano /etc/mongod.conf

次のブロックが表示されます。

/etc/mongod.conf
  1. # Where and how to store data.
  2. storage:
  3. dbPath: /var/lib/mongodb
  4. journal:
  5. enabled: true
  6. # engine:
  7. # mmapv1:
  8. # wiredTiger:

これは、ジャーナリングが有効になっていることを示しています。 MongoDB 3.2以降を使用している場合、デフォルトのストレージエンジンはWiredTigerです(MMAPv1はMongoDBの元のストレージエンジンでした)。

次に、バックアップと復元の手順をテストするために、いくつかのダミーデータを挿入します。

ステップ2—テストデータを挿入する

クリーンなサーバーを使用して開始し、まだデータがない場合は、デモ用にサンプルデータをダミーのレストランコレクションに挿入できます。 データベースにすでにいくつかのコレクションとドキュメントが保存されている場合は、この手順をスキップしてください。

まず、MongoDBシェルを使用して実行中のデータベースに接続します。

mongo

次のMongoシェルプロンプトが表示されます。

MongoDB shell version: 3.2.19
connecting to: test
Server has startup warnings:
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten]
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten]
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten]
>

シェルが使用するデフォルトのデータベースは、testデータベースです。

testデータベースに存在するコレクションをリストしてみましょう。

  1. show collections

データベースにはまだ何も挿入していないため、コレクションはなく、出力なしでプロンプトに戻ります。

同時に作成するダミーのrestaurantsコレクションにドキュメントを挿入しましょう。

  1. db.restaurants.insert({'name': 'Sammy's Pizzeria'})

次の出力が表示されます。

  1. WriteResult({ "nInserted" : 1 })

これは、挿入操作が成功したことを示しています。 レストランコレクションは以前は存在していなかったため、同時に作成されました。

コレクションをもう一度リストしましょう:

show collections

新しく作成されたレストランコレクションが表示されます。

restaurants

データベースにサンプルデータを保存したので、バックアップする準備が整いました。

##ステップ3—MongoDBドロップレットのスナップショット

バックアップを実行するために、DigitalOceanドロップレットスナップショットを利用します。 ドロップレットスナップショットを使用すると、スナップショットが開始された時点でのドロップレットのイメージを作成できます。 その後、このイメージを新しいドロップレットに復元して、さらにリカバリ操作を実行できます。

MongoDB 3.2以降(WiredTigerとジャーナリングが有効になっている)を使用している場合、スナップショットの作成中にファイルシステムへの書き込みを一時停止する必要はありません。 イメージを復元してデータベースを起動すると、MongoDBはチェックポイントから自身を復元し、スナップショットが発生した時点に達するまでジャーナルファイルから操作を再生します。 ジャーナリングについてさらに詳しく知りたい場合は、 MongoDBマニュアル)を参照してください。

スナップショットプロセスを開始するには、 DigitalOceanアカウントにログインし、MongoDBドロップレットに移動して、サイドバーのスナップショットリンクをクリックします。

次のプロンプトが表示されます。

Take Snapshot

注:スナップショットを作成する前にドロップレットの電源を切ることをお勧めしますが、実稼働環境ではこれが常に可能であるとは限りません。 MongoDBのジャーナリング機能により、データベースとDropletが実行されている間でも、一貫性のある有効なスナップショットが可能になります。

スナップショットにわかりやすい名前を付け、ライブスナップショットを取得ボタンをクリックしてスナップショットプロセスを開始します。

次のスナップショットの進行状況インジケーターが表示されます。

Snapshot Progress

スナップショットが完了すると、イメージから新しいドロップレットを作成したり、実行中のドロップレットをスナップショットイメージでキャプチャされた状態に復元したりできます。

これで、バックアップ手順の復元と検証を実行する準備が整いました。

ステップ4—MongoDBドロップレットを復元する

次に、作成したイメージから復元される新しいドロップレットを作成します。 MongoDBデータベースで利用可能なデータは、スナップショットが作成されたときに利用可能なデータと同じになります。

サイドバーを使用してスナップショットに戻り、完成したドロップレットスナップショットを見つけます。

Completed Snapshot

その他をクリックし、ドロップレットの作成を選択します。

ドロップレットの作成メニューが表示され、スナップショットから新しいドロップレットを起動できます。

以前に撮影したスナップショットに対応する画像を選択します。 この場合、mongo-backup-testイメージを使用します。

Choose Image

復元ドロップレットの構成を完了し、作成をクリックします。 復元ドロップレットが起動して実行されたら、ログインします。

Dropletの起動時に起動するようにMongoDBを構成した場合は、MongoDBが実行されているはずです。 これは、systemctlを使用して確認できます。

  1. sudo systemctl status mongod

次の出力が表示されます。

Output
● mongod.service - High-performance, schema-free document-oriented database Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2018-02-14 21:14:40 UTC; 4min 53s ago Docs: https://docs.mongodb.org/manual Main PID: 1302 (mongod) Tasks: 19 Memory: 87.2M CPU: 1.802s CGroup: /system.slice/mongod.service └─1302 /usr/bin/mongod --quiet --config /etc/mongod.conf

すべてが順調で、MongoDBが正しく起動したことを示します。

MongoDBが実行されていない場合は、最初にロックファイルを削除してから、サービスを開始する必要があります。

  1. rm /var/lib/mongodb/mongod.lock
  2. sudo systemctl start mongod

systemctl statusを使用してMongoDBが正しく起動したことを確認します。

MongoDBが起動して実行されると、MongoDBはそれ自体をクリーンアップし始め、スナップショットが発生した時点に状態を復元します。 これには数分かかる場合があり、mongoシェルはこれが完了するまで使用できない場合があります。

サーバーが利用可能になったら、mongoコマンドを使用してログインできます。

  1. mongo

これで、mongoシェルプロンプトが表示されます。

Output
MongoDB shell version: 3.2.19 connecting to: test Server has startup warnings: 2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] 2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. 2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never' 2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] 2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'. 2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never' 2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] >

ここまで進んだら、おめでとうございます! これで、MongoDBデータベースのバックアップと復元が正常に実行されました。

追加の予防措置として、コレクションの整合性を確認できます。

ステップ5—データの整合性を確認する

このバックアップデータを本番環境で使用する前に、復元されたコレクションに無効なBSONオブジェクトがないかどうかを確認すると便利です。

注: validateコマンドは、非常に大きなコレクションでは遅くなる可能性があります。 さらに、validateコマンドが戻るまで、コレクションですべての読み取りと書き込みがブロックされます。

この例では、validateコマンドを実行するrestaurantsというコレクションがあります。

mongoシェルから、validateコマンドを実行します。

  1. db.restaurants.validate({full:true})

次のような出力が表示されます。

  1. {
  2. "ns" : "test.restaurants",
  3. "nrecords" : 1,
  4. "nIndexes" : 1,
  5. "keysPerIndex" : {
  6. "test.restaurants.$_id_" : 1
  7. },
  8. "indexDetails" : {
  9. "test.restaurants.$_id_" : {
  10. "valid" : true
  11. }
  12. },
  13. "valid" : true,
  14. "errors" : [ ],
  15. "ok" : 1
  16. }

valid: trueが表示されている場合は、コレクションのすべての側面が有効であり、このコレクションのデータを本番環境で安全に使用できます。

結論

このチュートリアルでは、実行中のMongoDBデータベースサーバーの物理ファイルシステムレベルのバックアップを完了する方法を学習しました。

MongoDBデータベースをバックアップするさまざまな方法の詳細については、MongoDBマニュアルを参照してください。

この特定のバックアップ手法は、DigitalOceanの便利なドロップレットスナップショット機能によって可能になりました。 ドロップレットスナップショットの詳細については、スナップショットドキュメントを参照してください。

さらに、バックアップ機能を使用して、これらのスナップショットが自動的に発生するようにスケジュールできます。 ドロップレットバックアップの詳細については、バックアップの概要を参照してください。