Percona Backup for MongoDBを試す
技術本部 サービスリライアビリティグループ（SRG）の小原（@No_oLimits）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、Percona社のMongoDBのバックアップツール について解説します。
はじめにPercona Backup for MongoDB(PBM)についてPBMでできることMongoDB CommunityでPBMを試すPBMのセットアップバックアップ関連の操作フルバックアップ・リストアしてみるPoint-in-Time Recoveryしてみる終わりに
はじめに
Percona社といえばMySQLをイメージしますが、ありがたいことにMongoDBについても有用な情報を提供してくれています。
弊社ではMySQL以外にも、いくつかのプロダクトでデータストアにMongoDBを採用しています。
MongoDBのバックアップ運用（他にもデプロイ管理や監視）を考えたときに一番に候補に上がるのがAtlas / Cloud Managerで、サーバのデプロイ管理の自動化の観点ではメリットが多いので利用していたりするのですが、バックアップは利用にかかるコストがまぁまぁ大きかったりして負担になることがあり、そういったところではバックアップ機能は利用せずに別の手段（Diskスナップショット）でバックアップを取ったりしています。
そこでPercona Backup for MongoDBがどれだけ使えるか、調査して試していきたいと思います。
Percona Backup for MongoDB(PBM)について
PBMのアーキテクチャ図です。
各mongodサーバに が同居していて、PBM CLI経由でバックアップを管理します。
バックアップ管理に関わるConfigurationはconfig serverに格納していて、バックアップを格納するストレージはAWS S3などを利用する前提となっています。
基本的に各レプリカセット内のセカンダリがバックアップのターゲットとなるため、本番のワークロードとバックアップ中の負荷が分離され軽減されるメリットがあります。
また監視製品のPMM（Percona Monitoring and Management）にあるバックアップ機能は内部的にPBMを利用しているようです。
PBMでできること
MongoDB CommunityとPercona Server for MongoDBで利用できるバックアップタイプに差があるようです。
今回はCommunity版MongoDBで検証しようと思っていたので、Community版だと使える機能が論理バックアップ+PITRくらいになりそうです。
論理バックアップだとやはりバックアップ時間が長くなりがちなのがネックではありますが、一貫性を保持しつつオンラインバックアップが可能であるため、非常に有用なツールではあります。
MongoDB CommunityでPBMを試す
PBMのセットアップ
まずはsharded clusterをk8s上(minikube)にデプロイします（一番面倒な作業）
mongodのpodにはpbm-agentをサイドカーで同居させています。
また、バックアップの保存先としてMinIOを使用します。
ここでは触れませんが、レプリカセットの設定、シャードの追加などは完了している前提で話します。
pbm-agentのコンテナには環境変数 でmongodへの接続文字列を設定しておきます。manifestに定義してもいいですし、起動時に指定しても良いです。
次にバックアップストレージの設定を行います。pbm-agentコンテナで作業します。
MinIOについても適切なアクセスキーやバケットをあらかじめ準備してください。
各mongodサーバでpbm-agentを起動します。
起動後に を実行し、各agentが起動しているのが確認できれば準備完了です。
バックアップ関連の操作
フルバックアップ（論理）の一貫性保持の仕組みとして、すべてのレプリカセットのバックアップが完了するまでの間、各レプリカセットではoplogをキャプチャしているようです。
ですので、リストアするターゲットはバックアップが完了した時刻になります。
PBM CLIの主なコマンドは以下の通りです。バックアップの操作は非常に簡単でシンプル、わかりやすいです。
フルバックアップ・リストアしてみる
リストア検証に進みます。
リストアのシナリオは、 コレクションにデータが０件の状態でフルバックアップを取得し、何件かドキュメントを追加後にリストアを実行して０件に戻っていることを確認します。
0件の状態でバックアップを取得します。
データを追加します。
リストア前に確認する点が何点かあります。
PBMの主な注意点は以下。
- リストア前にPITRを無効にする。
- バックアップ時点に存在したコレクションがリストア対象
- バックアップ後に新しく作成したコレクションはリストア時に削除されない（ので、つじつまを合わせる場合はコレクションを削除しておく）
また、shard clusterのリストア時にはバランサーの停止やmongosからの不要な更新を停止することも従来通り必要です。
リストアします。0件に戻っていることを確認します。
Point-in-Time Recoveryしてみる
PITRのシナリオは、0→1000件データを追加した後、特定の時刻に戻せることを確認します。ここではリカバリ後に雑に 0 ~ 1000件の間のいずれかの件数になっていればOKとします
まずPITRを有効にし、ベースのバックアップを取得します。
0 → 1000件まで段階的にデータを追加します。
フルバックアップ後にDBに更新が発生すると、PITRのためのリカバリポイントが記録されていくのが確認できます。
下の例では から までの時刻にリカバリ可能であることを示しています。
特定の時刻にリカバリできることを確認します。
これで特定の時刻にリカバリできました。
作業後は再度PITRを有効にし、ベースバックアップを取得します。
終わりに
PBMの機能について調べてみました。
Community版だと論理バックアップしか選択肢がなく、本番環境で長時間バックアップが実行されるのはなるべく避けたいので現状のプロダクトに採用するのはちょっと難しいかなと感じました。
が、バックアップ運用に求める要件次第では十分使えるツールなんじゃないかなと思いました。
Percona Server for MongoDBを利用して物理バックアップを使えるようにするとしても、Cloud Managerによる管理から外れてしまうなどの懸念があるので、ぜひCommunity版で使える機能が増えると良いなと思いました。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
SRG では最近出たホットなIT技術や書籍などについてワイワイ雑談するポッドキャストを運営しています。ぜひ、作業のお供に聞いていただければ幸いです。
