PostgreSQL DBのバックアップを一元化しよう
•
4 likes•3,403 views
PostgreSQL Conference Japan 2017での発表資料です。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to PostgreSQL DBのバックアップを一元化しよう
Similar to PostgreSQL DBのバックアップを一元化しよう (20)
More from Yukiya Hayashi
More from Yukiya Hayashi (20)
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