pg_dumpはPostgreSQLデータベースをバックアップするユーティリティです。
データベースを使用中であっても、他のユーザによるデータベースへのアクセスをブロックしませんし、運用に欠かせないツールです。
それでも濫用はいけません。運用の巨大DBなら極力回避したいものです。
ページキャッシュ総入れ替え
データベース全体をひとなめするので、サービス実需ではアクセスしなくなったような古いデータまで、一度読み込んでしまいます。それによって、実需側のキャッシュヒット率が下がるリスクがあります。検索範囲の局所化効果で、サービスのスループットを保っていたなら、一時的にスループットが低下します。
データ量比例の処理
データベース全体を、ポータブルな形式で外部出力するので、データ量に比例してIO/CPUに負荷がかかります。
アクセスピークと重なったりすると、DBServerの過負荷でパンクのリスクがあります。
回避策
AWS の EBS snapshot がおいしい回避策です。
- 運用DBを停止する必要がない
- pg_dump は PostgreSQL の提供する標準のマイグレーション手段でもあるので当然できます。
- file IOレベルの処理になる EBS snapshot でもちゃんと整合性のある PostgreSQL DB になります。
- AWSだけが偉いわけではなく、PostgreSQLが、運用中のどの時点でOSクラッシュを食らっても、データベースを守り抜くという、DBMSの「ど根性要件」を満たしているからです。
- PostgreSQL Documents:信頼性とログ先行書き込み
- AWS側は任意の一時点のストレージを再現できる snapshot を作るので、PostgreSQL は次回起動時に WAL：先行書き込みログを使って、整合性のあるDBに自動リカバリします。
- 運用DBServer に負荷がかからない
- AWS の backyard 側で処理してくれるので、顧客向けサービスを担当している正面側には全く負荷がかかりません。
- snapshot作成コマンドも、ストレージサイズによらず、すぐに終了する非同期コマンドです。backyard側で処理は続きます。
- EBS snapshot は差分だけ記録
- Backup は定期的に繰り返すものです。そしてDBには一度書き込まれたらほとんど書き換えのない部分がかなりあります。
- 差分だけ S3 に保存するので保管コストが安い。
- 差分だけなので、2回目以降は snapshot 作成完了までが早い。
- 更新量1GBにつき1分が目安らしい。
- 差分だけど、古いものはどんどん削除できる
- 「ボリュームの過去のスナップショットを削除しても、それ以降のスナップショットからボリュームを復元する機能に影響することはありません。」 Amazon EBS スナップショットの削除 から引用。
- AWSのbackyardでどうやってるんでしょうね？ 「充分に発達した科学技術は、魔法と見分けが付かない。」 by アーサー・C・クラーク
適用できないケース
- PostgreSQL のメジャー・バージョンアップをするときは、DBバイナリの互換性がなくなるので、ポータブルな pg_dump 形式が必要になります。
- EBS volumeを複数使って SoftRAID を組んでいると、「任意の一時点」のストレージを再現できません。そうなると WAL での自動リカバリが成功する保証がありません。
- PostgreSQLじゃなくてMySQLの場合は、lock して flushする必要があるので、実質的にはDB停止が必要です。