PostgreSQL DBのバックアップを一元化しよう
4 likes3,473 views
PostgreSQL Conference Japan 2017での発表資料です。
](https://image.slidesharecdn.com/db-171103011818/85/PostgreSQL-DB-5-320.jpg)
![BaRMan導入後
DBから見るとBaRManはSRのスタンバイDB
に見える
# ps auxf ※一部省略
postgres … postgres: wal sender process postgres
192.168.11.12(41372) streaming 1/92A23BC0
postgres=# SELECT * FROM pg_stat_replication; ※一部省略
-[ RECORD 1 ]----+------------------------------
pid | 12518
usesysid | 10
usename | postgres
application_name | barman_receive_wal
client_addr | 192.168.11.12
state | streaming
sync_state | async](https://image.slidesharecdn.com/db-171103011818/85/PostgreSQL-DB-28-320.jpg)
![BaRMan導入後
レプリケーションスロットを利用することで、
無駄の無いwalローテーションが行われる
postgres=# select * from pg_replication_slots;
-[ RECORD 1 ]+-----------
slot_name | barman
plugin |
slot_type | physical
datoid |
database |
active | t
active_pid | 12521
xmin |
catalog_xmin |
restart_lsn | 1/92000000](https://image.slidesharecdn.com/db-171103011818/85/PostgreSQL-DB-29-320.jpg)
![DBのF/O後のフォローが必要
【対策】監視ツールでpg_replication_slotsの
active列を定期監視
postgres=# select * from pg_replication_slots;
-[ RECORD 1 ]+-----------
slot_name | barman
plugin |
slot_type | physical
datoid |
database |
active | t
active_pid | 12521
xmin |
catalog_xmin |
restart_lsn | 1/92000000
active = t でなければ警告を上げる](https://image.slidesharecdn.com/db-171103011818/85/PostgreSQL-DB-42-320.jpg)
![BaRMan導入方法
設定もシンプル
• 全体設定(/etc/barman.conf)
[barman]
barman_user = barman
configuration_files_directory = /etc/barman.d
barman_home = /var/backup/barman
log_file = /var/log/barman/barman.log
log_level = INFO
bandwidth_limit = 0](https://image.slidesharecdn.com/db-171103011818/85/PostgreSQL-DB-49-320.jpg)
![BaRMan導入方法
設定もシンプル
• サーバ単位設定(/etc/barman.d/xxx.conf)
[db001.slave-5432]
description = "db001.slave port 5432 (Streaming-Only)"
conninfo = host=db001.slave user=barman dbname=postgres
port=5432
streaming_conninfo = host=db001.slave user=barman port=5432
backup_method = postgres
streaming_backup_name = barman_streaming_backup
streaming_archiver = on
slot_name = barman_slot
path_prefix = "/usr/local/postgres/bin"
backup_options = concurrent_backup](https://image.slidesharecdn.com/db-171103011818/85/PostgreSQL-DB-50-320.jpg)
PostgreSQL DBのバックアップを一元化しよう
- 1. DBのバックアップを一元化しよう ～BaRManによる”スタイリッシュ”バックアップのススメ～ 林 如弥 （はやし ゆきや） @morihaya55 CC0 https://pixabay.com/en/restaurant-bar-stools-lights-2618315/ PostgreSQL PostgreSQL Conference Japan 2017
- 2. アジェンダ • 本セッションのゴール • バックアップについておさらい • BaRMan導入前 • 何故BaRManを選択したか • BaRMan導入後 • 運用していて注意するところ • BaRMan導入方法 • まとめ
- 3. 本セッションのゴール • BaRManというツールの魅力を知って頂く – どんな機能があり – どう運用が楽になるのか – もちろんデメリット(注意点)もあるよ BaRMan - Backup and Recovery Manager
- 5. バックアップについておさらい • 論理バックアップ – > pg_dumpやpg_dumpallでSQLファイル保存 • 物理バックアップ – オフライン・バックアップ -> DBを停止した状態で$PGDATAをバックアップ – オンライン・バックアップ -> DBを起動した状態で$PGDATAとWALログをバックアッ プ [Let‘s Postgres](https://lets.postgresql.jp/documents/technical/backup/1)
- 6. バックアップについておさらい • 論理バックアップ – >規模が大きいとバックアップもリストアも時間が かかる • 物理バックアップ – オフライン・バックアップ -> DBを停止しなくてはならない – オンライン・バックアップ -> 手順がちょっと複雑。PITRができる。(アーカイブ出力 設定、取得時のpg_start_backup()実行 ※v9.1からは pg_basebackupで簡単に)
- 7. バックアップについておさらい • 論理バックアップ – >難易度：簡単 • 物理バックアップ – オフライン・バックアップ -> 難易度：簡単 – オンライン・バックアップ -> 難易度：ちょっと難しい
- 8. バックアップについておさらい • 論理バックアップ – RPO：バックアップ取得時 – RTO：データ量に比例して長くなる • 物理バックアップ – オフライン・バックアップ • RPO：バックアップ取得時 • RTO：仕組み次第で一瞬（ローカルに2世代持つ等) – オンライン・バックアップ • RPO：直近。WALファイルでロールフォワード • RTO：データ量に比例して長くなる
- 9. バックアップについておさらい 本番用途のDBの場合、RPOを重視して物理オ ンライン・バックアップを採用するのが一般的(と 思います) ※BaRManで行うのも物理オンライン・バック アップです
- 10. BaRMan導入前
- 16. BaRMan導入前 用途に合わせた柔軟なバックアップと いえば聞こえが良いけど、管理者とし ては「このDBの場合は、このバック アップ方法」という状態は嬉しくない そんな課題を抱えていましたが….
- 18. BaRMan導入のチャンス到来 サーバ筐体の保守期限切れが近づき、 リプレースが必要になった（IT式年遷宮） もろもろ見直す！ ・バックアップツールにBaRMan ・PostgreSQL 8系 -> 9.5へVUP ・PG-REX構成(SRでHot standby) https://unsplash.com/photos/cjOWoz4iq7k
- 20. 何故BaRManを選択したか • 複数DBのリモートバックアップ • pgコマンドによるSR+ベースバックアップ • バックアップカタログ • 世代管理（リテンションポリシー） • Pythonで書かれている
- 21. 何故BaRManを選択したか • 複数DBのリモートバックアップ – > 一元管理したい • pgコマンドによるSR+ベースバックアップ – > SRの設定だけすれば良い。OS意識しない • バックアップカタログ – > どのベースから、どこまでリストアするか • 世代管理（リテンションポリシー） – > “find -mtime +180 | xargs rm” はもう嫌だ • Pythonで書かれている – > いざとなったら読める
- 22. 何故BaRManを選択したか 他の方法も検討したが、”複数DBをリ モートで管理”できるBaRManにした • 自分で開発 -> 車輪の再発明ツライ • pg_rman -> 単体DB用。リモートできない (NFSとかはできれば避けたい…) • wal-e -> 単体DB用。GitHubスター2K超とダ ントツ。クラウド時代のツールな印象
- 23. BaRMan導入後 ばーまん→
- 24. DB BaRMan導入後 BK Hot-Std-DB SR DB Hot-Std-DB SR DB Hot-Std-DB SR DB Hot-Std-DB SR BaRMan Pacemaker/Corosync Pacemaker/Corosync Pacemaker/CorosyncPacemaker/Corosync DB SR SR
- 27. BaRMan導入後 動作としてはBaRManから ”pg_receivexlog”コマンドを利用して常に walを受信 # ps auxf ※一部省略 barman … /usr/bin/python /usr/bin/barman -c /etc/barman.conf -q receive-wal db009-6535 barman … ¥_ /usr/local/postgres/bin/pg_receivexlog -- dbname=dbname=replication host=db009 port=6535 replication=true user=postgres application_name=barman_receive_wal -
- 28. BaRMan導入後 DBから見るとBaRManはSRのスタンバイDB に見える # ps auxf ※一部省略 postgres … postgres: wal sender process postgres 192.168.11.12(41372) streaming 1/92A23BC0 postgres=# SELECT * FROM pg_stat_replication; ※一部省略 -[ RECORD 1 ]----+------------------------------ pid | 12518 usesysid | 10 usename | postgres application_name | barman_receive_wal client_addr | 192.168.11.12 state | streaming sync_state | async
- 29. BaRMan導入後 レプリケーションスロットを利用することで、 無駄の無いwalローテーションが行われる postgres=# select * from pg_replication_slots; -[ RECORD 1 ]+----------- slot_name | barman plugin | slot_type | physical datoid | database | active | t active_pid | 12521 xmin | catalog_xmin | restart_lsn | 1/92000000
- 30. BaRMan導入後 バックアップのカタログ機能で複数サーバ の取得状況を確認できる # barman list-backup all ※一部省略 db003-5432 20171025...- Size: 1.1 GiB - WAL Size: 688.0 MiB db003-5432 20171018...- Size: 984.2 MiB - WAL Size: 1.7 GiB db004-5432 20171025...- Size: 98.2 MiB - WAL Size: 0 B db004-5432 20171018...- Size: 108.5 MiB - WAL Size: 48.0 MiB db005-5432 20171025...- Size: 339.3 MiB - WAL Size: 0 B -> 「このDBのバックアップいつ取得し た？」問題の解消
- 34. BaRManサーバがボトルネックになる • ディスク容量 • ネットワーク帯域 • バックアップデータの可用性 https://unsplash.com/photos/0zBJmvRpYMM
- 35. BaRManサーバがボトルネックになる • ディスク容量 –> DB数×保存世代数＋各DBのWAL • ネットワーク帯域 –> 複数DBを並列リストアするには辛い • バックアップデータの可用性 –> バックアップデータのバックアップ？ https://unsplash.com/photos/0zBJmvRpYMM
- 37. DBのF/O後のフォローが必要 PG-REX構成でF/Oした場合、以下のフォ ロー作業が必要 1. F/O後のDBへスロット作成 2. ベースバックアップ取得 3. 旧プライマリDBのスロット削除 ※さらにF/B後も同じ作業が必要
- 38. DBのF/O後のフォローが必要 1. 正常時 DB Hot-Std-DB SR Pacemaker/Corosync BK BaRMan SR 2. 障害->マスタDBの切り替わり DB DB(NEW!) Pacemaker/Corosync BK BaRMan
- 39. DBのF/O後のフォローが必要 3. 旧マスタの障害復旧 DB DB(NEW!) Pacemaker/Corosync BK BaRMan 4. SR再構成 Hot-Std-DB DB(NEW!) Pacemaker/Corosync BK BaRMan SR
- 40. DBのF/O後のフォローが必要 5. BaRMan用レプリケーションスロット作成 6. ベースバックアップ再取得&walストリーム Hot-Std-DB DB(NEW!) Pacemaker/Corosync BK BaRMan SR Hot-Std-DB DB(NEW!) Pacemaker/Corosync BK BaRMan SR receive-wal --create-slot SR
- 41. DBのF/O後のフォローが必要 7. 新マスタ側のレプリケーションスロット削除 Hot-Std-DB DB(NEW!) Pacemaker/Corosync BK BaRMan SR SR 削除 この未使用になったスロットの削除を行わないと、walが 削除されない -> ディスクが溢れるコンボが発動する
- 42. DBのF/O後のフォローが必要 【対策】監視ツールでpg_replication_slotsの active列を定期監視 postgres=# select * from pg_replication_slots; -[ RECORD 1 ]+----------- slot_name | barman plugin | slot_type | physical datoid | database | active | t active_pid | 12521 xmin | catalog_xmin | restart_lsn | 1/92000000 active = t でなければ警告を上げる
- 45. bandwidth_limitオプション しかしリストア時に変に効いた 例：100GBデータのリカバリ時間 + bandwidth_limit=3000 -> 12時間 + bandwidth_limit=0 -> 1時間 BaRManというより、内部的に呼ばれるrsyncが 悪さをしていそう…(?) ※あくまで個人事例ですのでご参考程度に 他要因の可能性があります
- 47. BaRMan導入方法 ばーまん→
- 48. BaRMan導入方法 インストール方法は極めて簡単 • PIP ※OSパッケージ依存しないのでｵｽｽﾒ • RHEL7, RHEL6 and RHEL5 （CentOSも) • Debian and Ubuntu yum install barman ※EPELとPGDGレポジトリが必要 apt-get install barman ※PGDGレポジトリが必要 export PATH=/xxxx/postgres/bin/:$PATH pip install barman http://docs.pgbarman.org/release/2.3/#installation
- 49. BaRMan導入方法 設定もシンプル • 全体設定(/etc/barman.conf) [barman] barman_user = barman configuration_files_directory = /etc/barman.d barman_home = /var/backup/barman log_file = /var/log/barman/barman.log log_level = INFO bandwidth_limit = 0
- 50. BaRMan導入方法 設定もシンプル • サーバ単位設定(/etc/barman.d/xxx.conf) [db001.slave-5432] description = "db001.slave port 5432 (Streaming-Only)" conninfo = host=db001.slave user=barman dbname=postgres port=5432 streaming_conninfo = host=db001.slave user=barman port=5432 backup_method = postgres streaming_backup_name = barman_streaming_backup streaming_archiver = on slot_name = barman_slot path_prefix = "/usr/local/postgres/bin" backup_options = concurrent_backup
- 51. BaRMan導入方法 DB側はSRを許可する • postgresql.conf • pg_hba.conf • リストア用にOS上でsshログインを許可 wal_level = ‘hot_standby’or ‘replica’ max_wal_senders = 1以上 max_replication_slots = 1以上 host replication barman 192.168.xx.xx/xx xxxx
- 52. BaRMan導入方法 バックアップ取得、リストアは全てBaRMan 導入サーバから行う • Walストリーミング開始 • ベースバックアップ取得 barman receive-wal --create-slot <サーバ名> barman cron barman check ←確認コマンド barman backup <サーバ名>
- 53. BaRMan導入方法 • バックアップのカタログ機能で複数サー バの取得状況を確認 # barman list-backup all ※一部省略 db003-5432 20171025...- Size: 1.1 GiB - WAL Size: 688.0 MiB db003-5432 20171018...- Size: 984.2 MiB - WAL Size: 1.7 GiB db004-5432 20171025...- Size: 98.2 MiB - WAL Size: 0 B db004-5432 20171018...- Size: 108.5 MiB - WAL Size: 48.0 MiB db005-5432 20171025...- Size: 339.3 MiB - WAL Size: 0 B ※再掲
- 54. BaRMan導入方法 • ローカルリストア • リモートリストア barman recover --target-time '2017-10-25 12:30:00+09:00' db001.slave-5432 20171025T010002 /var/pgsql/data-20171025 barman recover --remote-ssh-command 'ssh postgres@db001' -- target-time '2017-10-25 12:30:00+09:00' db001.slave-5432 20171025T010002 /var/pgsql/data-20171025 ※ローカルとリモートの違いは”—remote-ssh-command”の有無
- 55. まとめ ばーまん→
- 56. まとめ BaRManを導入するとこれが嬉しい • 複数のDBを一元的に管理できる • PostgreSQLのプロトコルでバックアップできる • DB側はSRの設定をしておくだけ • PostgreSQL9.4以降ならレプリケーションスロッ トと組み合わせてwal管理からも解放される 以上、ご清聴ありがとうございました。 m( _ _ )m