PostgreSQL Conference Japan 2017（2017年11月3日） チュートリアルトラック4コマ目の発表資料です。

1. PostgreSQL
レプリケーション
【T1】 SQLの基本
【T2】 PostgreSQLチューニング
【T3】 データベース監視の基本
【T4】 PostgreSQLレプリケーション解説
PostgreSQL Conference Japan 2017 2017.11.3
株式会社アシスト データベース技術本部
日本PostgreSQLユーザ会
喜田 紘介

2. 【T4】PostgreSQLレプリケーション
Japan PostgreSQL User's Group 2
 セッションテーマ
安定稼働を使命とするデータベースでは、障害が発生した場合もすぐに再稼働で
きるよう様々な工夫を凝らして設計されます。このような高可用システムを実現
する機能としてPostgreSQLではレプリケーションが用いられます。
 内容、対象者
PostgreSQLのレプリケーション機能の解説と、実機でレプリケーションを構築
するデモをご覧いただきます。インフラ担当や高可用システムの設計を担当する
方を対象に、PostgreSQLで何ができるかを解説します。
株式会社アシスト
日本PostgreSQLユーザ会 理事 喜田 紘介氏
入社時よりOracle Databaseの構築、運用、サポート等を経験。
2011年よりPostgreSQLチームに所属し「EDB Postgres」担当と
してユーザー自身で活用できるデータベースを目指して技術支援
や情報発信に務めています。
日本PostgreSQLユーザ会にも所属し、PostgreSQLやデータベー
ス技術の普及に向けて積極的な活動を心がけています。

3. アジェンダ
データベースの安定稼働について考える
データベースをとりまくいろいろな「可用性」
複製（レプリケーション）でDBの障害に備えよう
PostgreSQLのレプリケーション機能解説
レプリケーション構築実践（デモ）
Japan PostgreSQL User's Group 3

4. DBに期待する「安定稼働」
アプリケーションの要求に対して結果を返す
Japan PostgreSQL User's Group 4
データベースに期待する機能とは？
Click！
DBへの問合せ

5. DBに期待する「安定稼働」
アプリケーションの要求に対して結果を返す
Japan PostgreSQL User's Group 5
データベースに期待する機能とは？
Click！
DBへの問合せ
応答が
ありません
サービスは年間●●時間しか停止できないという要件があり、
データベースにアクセスできない状態（＝DBの障害）は
その時間にさらに余裕を持たせ、対策されなければいけません。

6. DBに期待する「安定稼働」
アプリケーションの要求に対して結果を返す
Japan PostgreSQL User's Group 6
データベースに期待する機能とは？
Click！
DBへの問合せ
応答が
ありません
サービスは年間●●時間しか停止できないという要件があり、
データベースにアクセスできない状態（＝DBの障害）は
その時間にさらに余裕を持たせ、対策されなければいけません。
可用性とは
・年間で1日停止して良いシステム
364日/365日=99.7%の稼働率
・1時間しか停止を許さないシステム
8759時間/8760時間=99.998%
（99.999%なら約50分）

7. DBに期待する「安定稼働」
複数のアプリケーションが共通のデータを利用
Japan PostgreSQL User's Group 7
もうひとつの可用性
DBへの問合せ

8. DBに期待する「安定稼働」
複数のアプリケーションが共通のデータを利用
Japan PostgreSQL User's Group 8
もうひとつの可用性
DBへの問合せ
一部分の障害に対して、
他のサービスは継続して
動き続けるように保つ。

9. 複製（レプリケーション）
システムの構成要素は必ず故障しうるものとして対策
機器の二重化など
ではデータは？
Japan PostgreSQL User's Group 9
データベースの障害に備えるには
Click！
DBへの問合せ
?

10. 複製（レプリケーション）
システムの構成要素は必ず故障しうるものとして対策
機器の二重化など
ではデータは？
Japan PostgreSQL User's Group 10
データベースの障害に備えるには
Click！
DBへの問合せ
? 複数のユーザーが
リアルタイムに更新を
かけ続けるDBは、
完全に同じ状態の複製を
用意することが難しい

11. 複製（レプリケーション）
システムの構成要素は必ず故障しうるものとして対策
機器の二重化など
ではデータは？
Japan PostgreSQL User's Group 11
データベースの障害に備えるには
Click！
DBへの問合せ
全ての更新を担当する
プライマリ（マスター）
ノード
プライマリから更新を
受け取るスタンバイ
（スレーブ）ノード
PostgreSQLでは
「ストリーミングレプリケーション」
で実現

12. 複製（レプリケーション）
平常時の参照負荷分散
数秒遅れでも構わないRead Onlyな処理
アプリ側でスタンバイノードに問合せ
障害時に新マスターに昇格
データベースに対し
「昇格」を指示
アプリの向き先を変更
仮想IP
DNSの書き換え
アプリの接続先修正
Japan PostgreSQL User's Group 12
「よくある」レプリケーションで実現できる機能
参照・更新が可能
参照のみ可能
数秒のタイムラグを許容

13. アジェンダ
データベースの安定稼働について考える
PostgreSQLのレプリケーション機能解説
バックアップと変更履歴（WAL）について
変更履歴を伝播するレプリケーション
レプリケーションスロット
レプリケーション構築実践（デモ）
Japan PostgreSQL User's Group 13

14. 前提知識
リアルタイムなバックアップは難しい
常に更新されるDBは「ある時点」のバックアップが前提
バックアップ以降の更新を「変更履歴」として保持
変更履歴を適用するリカバリの考え方
Japan PostgreSQL User's Group 14
バックアップと変更履歴（WAL）の役割を知っておく
時間
表
表
表
UPDATE
表 表
バックアップ領域
・・・
ある時点のバックアップ バックアップ以降の連続したWALファイル
表

15. レプリケーションの仕組み
ある時点のバックアップに変更履歴をリアルタイムに適用
基本的な考え方はリカバリと同じ
WAL送受信用のプロセスが起動(≠ファイル単位のコピー)
Japan PostgreSQL User's Group 15
変更履歴を順次適用するレプリケーション
startup
WALを送信
WALを要求
recovery.conf
ーーーーーーーー
※起動時に存在すると
startupプロセスによる
リカバリモードで起動
・standby_mode = on
・primary_conninfo
= マスターへの接続情報
参照・更新 参照のみ
WAL適用
（リカバリ）
wal sender wal reciever

16. レプリケーションの仕組み
スタンバイが停止した場合の問題
受信者がいない変更履歴をいつまで貯める？
無限に持つ ：ディスク容量を消費
一定量で削除：復旧後に変更履歴が繋がらない
レプリケーションスロットで、適用済みの（不要な）
WALを判断し、自動で削除することができる
Japan PostgreSQL User's Group 16
レプリケーションスロットを使ったスタンバイの状態管理
startup
WALを送信
WALを要求
参照・更新 参照のみ
wal sender wal reciever
slot
xxx番まで
適用完了したよ

17. アジェンダ
データベースの安定稼働について考える
PostgreSQLのレプリケーション機能解説
レプリケーション構築実践（デモ）
レプリケーションの作成自体はとても簡単
実機でレプリケーションの動作を見てみましょう
Japan PostgreSQL User's Group 17

18. デモ環境
PostgreSQLのインストール（両ノードで実施）
データベース作成（プライマリのみ）
Japan PostgreSQL User's Group 18
2台のCentOSにyumでPostgreSQL 10.0を導入済み
$ sudo yum install wget
$ wget https://download.postgresql.org/pub/repos/yum/testing/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm
$ sudo rpm -ivh pgdg-centos10-10-2.noarch.rpm
$ sudo yum install postgresql10 postgresql10-server postgresql10-contrib postgresql10-devel
$ sudo vi /usr/lib/systemd/system/postgresql-10.service
$ su - postgres
$ vi .bash_profile
$ sudo systemctl start postgresql-10.service
$ sudo systemctl status postgresql-10.service
$ su – postgres
$ createuser -d -r -l -P demo
$ createdb -O demo demodb
# Location of database directory
# Environment=PGDATA=/var/lib/pgsql/10/data/
Environment=PGDATA=/home/postgres/data/
### edit for PostgreSQL10
export PGDATA=/home/postgres/data
export PATH=/usr/pgsql-10/bin:.:$PATH
サンプルテーブルも作成
$ psql -U demo demodb
demodb=> create table sample (a int,b text);
demodb=> insert into sample values (1,'test1');

19. プライマリ側の設定
ユーザー作成
$PGDATA/pg_hba.confの編集
Japan PostgreSQL User's Group 19
①レプリケーション用のユーザーを作成
$ createuser --replication rep_user
$ vi $PGDATA/pg_hba.conf
TYPE DB USER CIDR-ADDRESS METHOD
host replication rep_user 192.168.10.0/24 trust
host all rep_user 0.0.0.0/0 reject

20. プライマリ側の設定
$PGDATA/postgresql.confの編集
Japan PostgreSQL User's Group 20
②レプリケーション用のパラメータ設定
$ vi $PGDATA/postgresql.conf
パラメータ 設定 説明
listen_addresses * （通常はDB作成後にほぼ必須で実施）
wal_level replica レプリケーションに必要なWAL情報を生成
max_wal_senders 10 起動可能なwal senderプロセスの上限
max_replication_slots 10 作成可能なレプリケーションスロットの上限
synchronous_standby_names 任意 同期スタンバイの名前を指定
synchronous_commit on 同期レベルを指定
hot_standby on 自身がスタンバイの時に参照可能とする
hot_standby_feedback on 自身の情報をプライマリに送信
wal sender
slot ※ここまで進んだら再起動しておく
$ sudo systemctl start postgresql-10.service

21. プライマリ側の設定
$PGDATA/recovery.conf.node1の作成
Japan PostgreSQL User's Group 21
③自身がスタンバイになる際のrecovery.confを作成
$ vi $PGDATA/recovery.conf.node1
パラメータ 設定 説明
standby_mode on 起動時にスタンバイモードになる
primary_conninfo プライマリへの接続情報
primary_slot_name slot2 プライマリのレプリケーションスロット名
recovery_target_timeline latest 最新のマスターに追従する設定
wal reciever
host port user application_name
node2 5432 rep_user node1
wal sender
slot2
recovery.conf
自身がスタンバイになる際の
相手への接続情報

22. スタンバイの作成
pg_basebackupで＄PGDATA配下を一括取得
Japan PostgreSQL User's Group 22
①プライマリのバックアップを取得
$ pg_basebackup -U rep_user -h <node1_ip> -p 5432 -D /home/postgres/data
$ ls -ltr $PGDATA
drwx------. 3 postgres postgres 60 Oct 28 15:44 pg_wal
drwx------. 6 postgres postgres 54 Oct 28 15:44 base
drwx------. 2 postgres postgres 4096 Oct 28 15:44 global
drwx------. 2 postgres postgres 32 Oct 28 15:44 log
-rw-------. 1 postgres postgres 22844 Oct 28 15:44 postgresql.conf
-rw-------. 1 postgres postgres 88 Oct 28 15:44 postgresql.auto.conf
-rw-rw-r--. 1 postgres postgres 169 Oct 28 15:44 recovery.conf.node1
-rw-------. 1 postgres postgres 4760 Oct 28 15:44 pg_hba.conf
pg_hba.conf
postgresql.conf
recovery.conf.node1
pg_basebackup pg_hba.conf
postgresql.conf
recovery.conf.node1 ※slot以外をコピー

23. スタンバイの作成
$PGDATA/recovery.confを作成
Japan PostgreSQL User's Group 23
②recovery.confを作成（コピーしたものを編集）
$ cp $PGDATA/recovery.conf.node1 $PGDATA/recovery.conf.node2
$ vi $PGDATA/recovery.conf.node2
$ cp $PGDATA/recovery.conf.node2 $PGDATA/recovery.conf
wal reciever
pg_hba.conf
postgresql.conf
recovery.conf.node1
パラメータ 設定 説明
standby_mode on 起動時にスタンバイモードになる
primary_conninfo プライマリへの接続情報
primary_slot_name slot1 プライマリのレプリケーションスロット名
recovery_target_timeline latest 最新のマスターに追従する設定
host port user application_name
node1 5432 rep_user node2

24. スタンバイ側の設定
プライマリでレプリケーションスロットを作成
systemctlでスタンバイを起動
Japan PostgreSQL User's Group 24
③スタンバイを起動
$ sudo systemctl start postgresql-10.service
$ su - postgres
$ ps x
11089 ? Ss 0:00 /usr/pgsql-10/bin/postmaster -D /home/postgres/data/
11093 ? Ss 0:00 postgres: startup process recovering 000000010000000000000005
11097 ? Ss 0:00 postgres: wal receiver process streaming 0/5000140
:
wal reciever
recovery.conf
wal sender
slot1
WALを送信
WALを要求
$ su - postgres
$ psql -h <node1_ip> -U postgres postgres
postgres=# select pg_create_physical_replication_slot('slot1');

25. デモ
プライマリを正常停止
スタンバイを新プライマリに昇格
旧プライマリを新スタンバイとしてクラスタに参加
Japan PostgreSQL User's Group 25
スイッチオーバー
$ su - postgres
$ pg_ctl promote
$ psql -U postgres postgres
postgres=# select pg_create_physical_replication_slot('slot2');
$ sudo systemctl stop postgresql-10.service
$ su - postgres
$ cp $PGDATA/recovery.conf.node1 $PGDATA/recovery.conf
$ exit
$ sudo systemctl start postgresql-10.service
$ su - postgres
$ psql -U postgres postgres
postgres=# select pg_drop_replication_slot('slot1'); -- 旧スロットを削除

26. デモ
スタンバイを強制的に新プライマリに昇格
旧プライマリを停止、削除
「スタンバイの作成」からやり直し
新プライマリのバックアップ取得
recovery.confは上記でコピーしておいたものを再利用
新スタンバイを起動
Japan PostgreSQL User's Group 26
フェイルオーバー
$ su - postgres
$ pg_ctl promote
$ psql -U postgres postgres
postgres=# select pg_create_physical_replication_slot('slot1');
$ sudo systemctl stop postgresql-10.service
$ su - postgres
$ cp $PGDATA/recovery.conf.node2 /home/postgres/recovery.conf.node2
$ rm -rf $PGDATA

27. 想定Q&A
Japan PostgreSQL User's Group 27
今日のデモ＋どこまでやれば実用レベルになる？
Question Answer
基本の作り方はわかったけど、
この後どうしたら実用レベルになるの？
・レプリ関連パラメータを全部ちゃんと読みこむ
・pg_hba.confやpostgresql.confはちゃんと設定する
（レプリ関連では本資料で紹介したものでOK）
・フェイルオーバー/スイッチオーバーをたくさん練習する
フェイルオーバー後はバックアップから
取り直し？
その通り。バックアップの取り直しが必要
上記の「練習」でリアルな所要時間まで把握すること
pg_rewindを使えると救えるケースもある（要事前設定）
完全同期レプリケーションが出来るって
聞いたんだけど
※完全同期=スタンバイで参照した
結果がマスターと完全に同じ
完全同期、準同期（2段階）、非同期が選択可能
以下の2つのパラメーターの組合せで指定する
・synchronous_commit
・synchronous_standby_names
フェイルオーバーの自動化はできる？ Pgpool-IIやpacemakerなどのツールと組み合わせて実現
主に「死活監視」「マスター昇格or障害ノード切り離し」
「仮想IPなどを制御しアプリの向き先変更」の要素が必要
ロジカルレプリケーションが出来るって
聞いたんだけど
PostgreSQL10からロジカルレプリケーションが可能
WALベースであることは同じだが、設定方法や用途は異なる
テーブル単位で作成する

28. 【T4】PostgreSQLレプリケーション
Japan PostgreSQL User's Group 28
 セッションテーマ
安定稼働を使命とするデータベースでは、障害が発生した場合もすぐに再稼働で
きるよう様々な工夫を凝らして設計されます。このような高可用システムを実現
する機能としてPostgreSQLではレプリケーションが用いられます。
 まとめ
システムを構成する機器は故障しうることを前提に対策をするべき。
常に更新されているデータベース層を守るには、リアルタイムに
変更履歴を伝播する「レプリケーション」が簡単・確実
startup
WALを送信
WALを要求
参照・更新 参照のみ
WAL適用
（リカバリ）
wal sender wal reciever