Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
DBのバックアップを一元化しよう
~BaRManによる”スタイリッシュ”バックアップのススメ~
林 如弥
(はやし ゆきや)
@morihaya55
CC0 https://pixabay.com/en/restaurant-bar-stool...
アジェンダ
• 本セッションのゴール
• バックアップについておさらい
• BaRMan導入前
• 何故BaRManを選択したか
• BaRMan導入後
• 運用していて注意するところ
• BaRMan導入方法
• まとめ
本セッションのゴール
• BaRManというツールの魅力を知って頂く
– どんな機能があり
– どう運用が楽になるのか
– もちろんデメリット(注意点)もあるよ
BaRMan - Backup and Recovery Manager
バックアップについておさらい
はじめに
バックアップについておさらい
• 論理バックアップ
– > pg_dumpやpg_dumpallでSQLファイル保存
• 物理バックアップ
– オフライン・バックアップ
-> DBを停止した状態で$PGDATAをバックアップ
– オンライン・バ...
バックアップについておさらい
• 論理バックアップ
– >規模が大きいとバックアップもリストアも時間が
かかる
• 物理バックアップ
– オフライン・バックアップ
-> DBを停止しなくてはならない
– オンライン・バックアップ
-> 手順がち...
バックアップについておさらい
• 論理バックアップ
– >難易度:簡単
• 物理バックアップ
– オフライン・バックアップ
-> 難易度:簡単
– オンライン・バックアップ
-> 難易度:ちょっと難しい
バックアップについておさらい
• 論理バックアップ
– RPO:バックアップ取得時
– RTO:データ量に比例して長くなる
• 物理バックアップ
– オフライン・バックアップ
• RPO:バックアップ取得時
• RTO:仕組み次第で一瞬(ローカ...
バックアップについておさらい
本番用途のDBの場合、RPOを重視して物理オ
ンライン・バックアップを採用するのが一般的(と
思います)
※BaRManで行うのも物理オンライン・バック
アップです
BaRMan導入前
BaRMan導入前
環境、サーバによって異なるバック
アップ方式が混在していた
BaRMan導入前
パターンA
手動定期作業としてpg_dumpで週次で論理
バックアップを取得し、ダンプ集積用のサーバ
へ保管
DB BK
SQL
pg_dump
BaRMan導入前
パターンB
cronで独自シェルで以下を取得
・日次でオンラインバックアップ
・30分単位でwalアーカイブ
コールドスタンバイDBサーバと、ダンプ集積用
のサーバへ保管
DB BK
rsync
WAL
Cold-Std-D...
BaRMan導入前
パターンC
cronでpg_rmanを使用し以下を取得
・日次でFullバックアップ
・30分単位でArchバックアップ
DB
WAL
Hot-Std-DB
$PGDATA
SR
WAL
$PGDATA
pg_rman
BaRMan導入前
パターンD
不定期で取得した
物理オフラインバックアップが散在
DB BK
$PGDATA
rsync
$PGDATA
_bk1
$PGDATA
_bk2
cp -Rp
※オンライン・バックアップと見分けがつかないorz
BaRMan導入前
用途に合わせた柔軟なバックアップと
いえば聞こえが良いけど、管理者とし
ては「このDBの場合は、このバック
アップ方法」という状態は嬉しくない
そんな課題を抱えていましたが….
https://unsplash.com/photos/cjOWoz4iq7k
BaRMan導入のチャンス到来
サーバ筐体の保守期限切れが近づき、
リプレースが必要になった(IT式年遷宮)
もろもろ見直す!
・バックアップツールにBaRMan
・PostgreSQL 8系 -> 9.5へVUP
・PG-REX構成(SRでH...
何故BaRManを選択したか
ばーまん→
何故BaRManを選択したか
• 複数DBのリモートバックアップ
• pgコマンドによるSR+ベースバックアップ
• バックアップカタログ
• 世代管理(リテンションポリシー)
• Pythonで書かれている
何故BaRManを選択したか
• 複数DBのリモートバックアップ
– > 一元管理したい
• pgコマンドによるSR+ベースバックアップ
– > SRの設定だけすれば良い。OS意識しない
• バックアップカタログ
– > どのベースから、どこま...
何故BaRManを選択したか
他の方法も検討したが、”複数DBをリ
モートで管理”できるBaRManにした
• 自分で開発 -> 車輪の再発明ツライ
• pg_rman -> 単体DB用。リモートできない
(NFSとかはできれば避けたい…)
•...
BaRMan導入後
ばーまん→
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/Coros...
BaRMan導入後
全てのDBのバックアップデータは、
BaRManによってBKサーバへ集約される
ー>「このDBのバックアップデータ、ローカ
ルだっけ?リモートだっけ?」問題の解消
BaRMan導入後
全てのDBからBKサーバへSR(ストリーミン
グ・レプリケーション)で更新データ(wal)を
常に送信
さらにPostgreSQL 9.4からのレプリケーショ
ンスロットを利用
ー>「walの管理めんどい」問題の解消
BaRMan導入後
動作としてはBaRManから
”pg_receivexlog”コマンドを利用して常に
walを受信
# ps auxf ※一部省略
barman … /usr/bin/python /usr/bin/barman -c /e...
BaRMan導入後
DBから見るとBaRManはSRのスタンバイDB
に見える
# ps auxf ※一部省略
postgres … postgres: wal sender process postgres
192.168.11.12(413...
BaRMan導入後
レプリケーションスロットを利用することで、
無駄の無いwalローテーションが行われる
postgres=# select * from pg_replication_slots;
-[ RECORD 1 ]+--------...
BaRMan導入後
バックアップのカタログ機能で複数サーバ
の取得状況を確認できる
# barman list-backup all ※一部省略
db003-5432 20171025...- Size: 1.1 GiB - WAL Size:...
BaRMan導入後
ベースバックアップの取得は内部的
に”pg_basebackup”を利用するため、
PostgreSQLのプロトコルだけで完結する。
「DBがコンテナ/Windows上だから
ssh/rsyncできない」問題の解消
※リスト...
運用していて注意するところ
良いことばかり
じゃない!
https://unsplash.com/photos/0zBJmvRpYMM
BaRManサーバがボトルネックになる
• ディスク容量
• ネットワーク帯域
• バックアップデータの可用性
https://unsplash.com/photos/0zBJmvRpYMM
BaRManサーバがボトルネックになる
• ディスク容量
–> DB数×保存世代数+各DBのWAL
• ネットワーク帯域
–> 複数DBを並列リストアするには辛い
• バックアップデータの可用性
–> バックアップデータのバックアップ?
htt...
BaRManサーバがボトルネックになる
【対策】 rsyncで待機サーバにBaRMan管理
ディレクトリを定期コピーし、可用性向上と
2並列でのリストアを可能とした
https://unsplash.com/photos/0zBJmvRpYMM...
DBのF/O後のフォローが必要
PG-REX構成でF/Oした場合、以下のフォ
ロー作業が必要
1. F/O後のDBへスロット作成
2. ベースバックアップ取得
3. 旧プライマリDBのスロット削除
※さらにF/B後も同じ作業が必要
DBのF/O後のフォローが必要
1. 正常時
DB Hot-Std-DB
SR
Pacemaker/Corosync
BK
BaRMan
SR
2. 障害->マスタDBの切り替わり
DB DB(NEW!)
Pacemaker/Corosync
...
DBのF/O後のフォローが必要
3. 旧マスタの障害復旧
DB DB(NEW!)
Pacemaker/Corosync
BK
BaRMan
4. SR再構成
Hot-Std-DB DB(NEW!)
Pacemaker/Corosync
BK
B...
DBのF/O後のフォローが必要
5. BaRMan用レプリケーションスロット作成
6. ベースバックアップ再取得&walストリーム
Hot-Std-DB DB(NEW!)
Pacemaker/Corosync
BK
BaRMan
SR
Hot-...
DBのF/O後のフォローが必要
7. 新マスタ側のレプリケーションスロット削除
Hot-Std-DB DB(NEW!)
Pacemaker/Corosync
BK
BaRMan
SR
SR
削除
この未使用になったスロットの削除を行わないと、w...
DBのF/O後のフォローが必要
【対策】監視ツールでpg_replication_slotsの
active列を定期監視
postgres=# select * from pg_replication_slots;
-[ RECORD 1 ]+...
bandwidth_limitオプション
ドキュメントにpg_basebackupを使用する場合は
帯域制限サポートしないとあるが、効く。
PostgreSQL 9.4から”-r rate”オプションが追加。
http://docs.pgbar...
bandwidth_limitオプション
ソース上ではちゃんと対応している
https://github.com/2ndquadrant-it/barman/blob/master/barman/backup_executor.py
bandwidth_limitオプション
しかしリストア時に変に効いた
例:100GBデータのリカバリ時間
+ bandwidth_limit=3000 -> 12時間
+ bandwidth_limit=0 -> 1時間
BaRManというよ...
bandwidth_limitオプション
【対策】リストアする場合、定義を
bandwidth_limit=0に変更してから
”barman recover”を実行する
(手動運用でカバー)
BaRMan導入方法
ばーまん→
BaRMan導入方法
インストール方法は極めて簡単
• PIP ※OSパッケージ依存しないのでオススメ
• RHEL7, RHEL6 and RHEL5 (CentOSも)
• Debian and Ubuntu
yum install bar...
BaRMan導入方法
設定もシンプル
• 全体設定(/etc/barman.conf)
[barman]
barman_user = barman
configuration_files_directory = /etc/barman.d
ba...
BaRMan導入方法
設定もシンプル
• サーバ単位設定(/etc/barman.d/xxx.conf)
[db001.slave-5432]
description = "db001.slave port 5432 (Streaming-On...
BaRMan導入方法
DB側はSRを許可する
• postgresql.conf
• pg_hba.conf
• リストア用にOS上でsshログインを許可
wal_level = ‘hot_standby’or ‘replica’
max_wa...
BaRMan導入方法
バックアップ取得、リストアは全てBaRMan
導入サーバから行う
• Walストリーミング開始
• ベースバックアップ取得
barman receive-wal --create-slot <サーバ名>
barman cr...
BaRMan導入方法
• バックアップのカタログ機能で複数サー
バの取得状況を確認
# barman list-backup all ※一部省略
db003-5432 20171025...- Size: 1.1 GiB - WAL Size:...
BaRMan導入方法
• ローカルリストア
• リモートリストア
barman recover --target-time '2017-10-25 12:30:00+09:00'
db001.slave-5432 20171025T010002...
まとめ
ばーまん→
まとめ
BaRManを導入するとこれが嬉しい
• 複数のDBを一元的に管理できる
• PostgreSQLのプロトコルでバックアップできる
• DB側はSRの設定をしておくだけ
• PostgreSQL9.4以降ならレプリケーションスロッ
トと...
Upcoming SlideShare
Loading in …5
×

PostgreSQL DBのバックアップを一元化しよう

871 views

Published on

PostgreSQL Conference Japan 2017での発表資料です。

Published in: Engineering
  • Be the first to comment

PostgreSQL DBのバックアップを一元化しよう

  1. 1. DBのバックアップを一元化しよう ~BaRManによる”スタイリッシュ”バックアップのススメ~ 林 如弥 (はやし ゆきや) @morihaya55 CC0 https://pixabay.com/en/restaurant-bar-stools-lights-2618315/ PostgreSQL PostgreSQL Conference Japan 2017
  2. 2. アジェンダ • 本セッションのゴール • バックアップについておさらい • BaRMan導入前 • 何故BaRManを選択したか • BaRMan導入後 • 運用していて注意するところ • BaRMan導入方法 • まとめ
  3. 3. 本セッションのゴール • BaRManというツールの魅力を知って頂く – どんな機能があり – どう運用が楽になるのか – もちろんデメリット(注意点)もあるよ BaRMan - Backup and Recovery Manager
  4. 4. バックアップについておさらい はじめに
  5. 5. バックアップについておさらい • 論理バックアップ – > pg_dumpやpg_dumpallでSQLファイル保存 • 物理バックアップ – オフライン・バックアップ -> DBを停止した状態で$PGDATAをバックアップ – オンライン・バックアップ -> DBを起動した状態で$PGDATAとWALログをバックアッ プ [Let‘s Postgres](https://lets.postgresql.jp/documents/technical/backup/1)
  6. 6. バックアップについておさらい • 論理バックアップ – >規模が大きいとバックアップもリストアも時間が かかる • 物理バックアップ – オフライン・バックアップ -> DBを停止しなくてはならない – オンライン・バックアップ -> 手順がちょっと複雑。PITRができる。(アーカイブ出力 設定、取得時のpg_start_backup()実行 ※v9.1からは pg_basebackupで簡単に)
  7. 7. バックアップについておさらい • 論理バックアップ – >難易度:簡単 • 物理バックアップ – オフライン・バックアップ -> 難易度:簡単 – オンライン・バックアップ -> 難易度:ちょっと難しい
  8. 8. バックアップについておさらい • 論理バックアップ – RPO:バックアップ取得時 – RTO:データ量に比例して長くなる • 物理バックアップ – オフライン・バックアップ • RPO:バックアップ取得時 • RTO:仕組み次第で一瞬(ローカルに2世代持つ等) – オンライン・バックアップ • RPO:直近。WALファイルでロールフォワード • RTO:データ量に比例して長くなる
  9. 9. バックアップについておさらい 本番用途のDBの場合、RPOを重視して物理オ ンライン・バックアップを採用するのが一般的(と 思います) ※BaRManで行うのも物理オンライン・バック アップです
  10. 10. BaRMan導入前
  11. 11. BaRMan導入前 環境、サーバによって異なるバック アップ方式が混在していた
  12. 12. BaRMan導入前 パターンA 手動定期作業としてpg_dumpで週次で論理 バックアップを取得し、ダンプ集積用のサーバ へ保管 DB BK SQL pg_dump
  13. 13. BaRMan導入前 パターンB cronで独自シェルで以下を取得 ・日次でオンラインバックアップ ・30分単位でwalアーカイブ コールドスタンバイDBサーバと、ダンプ集積用 のサーバへ保管 DB BK rsync WAL Cold-Std-DB WAL rsync rsync rsync WAL $PGDATA $PGDATA $PGDATA
  14. 14. BaRMan導入前 パターンC cronでpg_rmanを使用し以下を取得 ・日次でFullバックアップ ・30分単位でArchバックアップ DB WAL Hot-Std-DB $PGDATA SR WAL $PGDATA pg_rman
  15. 15. BaRMan導入前 パターンD 不定期で取得した 物理オフラインバックアップが散在 DB BK $PGDATA rsync $PGDATA _bk1 $PGDATA _bk2 cp -Rp ※オンライン・バックアップと見分けがつかないorz
  16. 16. BaRMan導入前 用途に合わせた柔軟なバックアップと いえば聞こえが良いけど、管理者とし ては「このDBの場合は、このバック アップ方法」という状態は嬉しくない そんな課題を抱えていましたが….
  17. 17. https://unsplash.com/photos/cjOWoz4iq7k
  18. 18. BaRMan導入のチャンス到来 サーバ筐体の保守期限切れが近づき、 リプレースが必要になった(IT式年遷宮) もろもろ見直す! ・バックアップツールにBaRMan ・PostgreSQL 8系 -> 9.5へVUP ・PG-REX構成(SRでHot standby) https://unsplash.com/photos/cjOWoz4iq7k
  19. 19. 何故BaRManを選択したか ばーまん→
  20. 20. 何故BaRManを選択したか • 複数DBのリモートバックアップ • pgコマンドによるSR+ベースバックアップ • バックアップカタログ • 世代管理(リテンションポリシー) • Pythonで書かれている
  21. 21. 何故BaRManを選択したか • 複数DBのリモートバックアップ – > 一元管理したい • pgコマンドによるSR+ベースバックアップ – > SRの設定だけすれば良い。OS意識しない • バックアップカタログ – > どのベースから、どこまでリストアするか • 世代管理(リテンションポリシー) – > “find -mtime +180 | xargs rm” はもう嫌だ • Pythonで書かれている – > いざとなったら読める
  22. 22. 何故BaRManを選択したか 他の方法も検討したが、”複数DBをリ モートで管理”できるBaRManにした • 自分で開発 -> 車輪の再発明ツライ • pg_rman -> 単体DB用。リモートできない (NFSとかはできれば避けたい…) • wal-e -> 単体DB用。GitHubスター2K超とダ ントツ。クラウド時代のツールな印象
  23. 23. BaRMan導入後 ばーまん→
  24. 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
  25. 25. BaRMan導入後 全てのDBのバックアップデータは、 BaRManによってBKサーバへ集約される ー>「このDBのバックアップデータ、ローカ ルだっけ?リモートだっけ?」問題の解消
  26. 26. BaRMan導入後 全てのDBからBKサーバへSR(ストリーミン グ・レプリケーション)で更新データ(wal)を 常に送信 さらにPostgreSQL 9.4からのレプリケーショ ンスロットを利用 ー>「walの管理めんどい」問題の解消
  27. 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. 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. 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. 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のバックアップいつ取得し た?」問題の解消
  31. 31. BaRMan導入後 ベースバックアップの取得は内部的 に”pg_basebackup”を利用するため、 PostgreSQLのプロトコルだけで完結する。 「DBがコンテナ/Windows上だから ssh/rsyncできない」問題の解消 ※リストアは別のお話…
  32. 32. 運用していて注意するところ 良いことばかり じゃない!
  33. 33. https://unsplash.com/photos/0zBJmvRpYMM
  34. 34. BaRManサーバがボトルネックになる • ディスク容量 • ネットワーク帯域 • バックアップデータの可用性 https://unsplash.com/photos/0zBJmvRpYMM
  35. 35. BaRManサーバがボトルネックになる • ディスク容量 –> DB数×保存世代数+各DBのWAL • ネットワーク帯域 –> 複数DBを並列リストアするには辛い • バックアップデータの可用性 –> バックアップデータのバックアップ? https://unsplash.com/photos/0zBJmvRpYMM
  36. 36. BaRManサーバがボトルネックになる 【対策】 rsyncで待機サーバにBaRMan管理 ディレクトリを定期コピーし、可用性向上と 2並列でのリストアを可能とした https://unsplash.com/photos/0zBJmvRpYMM BK BaRMan $barman _home BK_2 $barman _home rsync BaRMan SR ※超大規模環境のグループ化して分散するなどの方法を考える必要がありそう
  37. 37. DBのF/O後のフォローが必要 PG-REX構成でF/Oした場合、以下のフォ ロー作業が必要 1. F/O後のDBへスロット作成 2. ベースバックアップ取得 3. 旧プライマリDBのスロット削除 ※さらにF/B後も同じ作業が必要
  38. 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. 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. 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. 41. DBのF/O後のフォローが必要 7. 新マスタ側のレプリケーションスロット削除 Hot-Std-DB DB(NEW!) Pacemaker/Corosync BK BaRMan SR SR 削除 この未使用になったスロットの削除を行わないと、walが 削除されない -> ディスクが溢れるコンボが発動する
  42. 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 でなければ警告を上げる
  43. 43. bandwidth_limitオプション ドキュメントにpg_basebackupを使用する場合は 帯域制限サポートしないとあるが、効く。 PostgreSQL 9.4から”-r rate”オプションが追加。 http://docs.pgbarman.org/release/2.3/ “not supported”
  44. 44. bandwidth_limitオプション ソース上ではちゃんと対応している https://github.com/2ndquadrant-it/barman/blob/master/barman/backup_executor.py
  45. 45. bandwidth_limitオプション しかしリストア時に変に効いた 例:100GBデータのリカバリ時間 + bandwidth_limit=3000 -> 12時間 + bandwidth_limit=0 -> 1時間 BaRManというより、内部的に呼ばれるrsyncが 悪さをしていそう…(?) ※あくまで個人事例ですのでご参考程度に 他要因の可能性があります
  46. 46. bandwidth_limitオプション 【対策】リストアする場合、定義を bandwidth_limit=0に変更してから ”barman recover”を実行する (手動運用でカバー)
  47. 47. BaRMan導入方法 ばーまん→
  48. 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. 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. 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. 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. 52. BaRMan導入方法 バックアップ取得、リストアは全てBaRMan 導入サーバから行う • Walストリーミング開始 • ベースバックアップ取得 barman receive-wal --create-slot <サーバ名> barman cron barman check ←確認コマンド barman backup <サーバ名>
  53. 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. 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. 55. まとめ ばーまん→
  56. 56. まとめ BaRManを導入するとこれが嬉しい • 複数のDBを一元的に管理できる • PostgreSQLのプロトコルでバックアップできる • DB側はSRの設定をしておくだけ • PostgreSQL9.4以降ならレプリケーションスロッ トと組み合わせてwal管理からも解放される 以上、ご清聴ありがとうございました。 m( _ _ )m

×