アーキテクチャから理解するPostgreSQLのレプリケーション

Copyright©2018 NTT Corp. All Rights Reserved.
アーキテクチャから理解する
PostgreSQLのレプリケーション
NTT OSSセンタ
澤田雅彦

2Copyright©2018 NTT Corp. All Rights Reserved.
自己紹介
澤田雅彦
@sawada_masahiko
NTT OSSセンタ
PostgreSQLの技術サポート
PostgreSQLの本体開発
PostgreSQLの周辺ツール開発
 pg_repack – オンラインメンテナンスツール
 pg_bigm – 2-gram全文検索モジュール

• PostgreSQLのアーキテクチャについて簡単におさらい
• Replicationについて
• Streaming Replicationを理解する
• 設定、構築、運用など
• Logical Replicationを理解する
• 設定、構築、運用など
Index

PostgreSQLのアーキテクチャ

• プロセスモデル
• Postmasterプロセス：接続の受付、Backendプロセスのforkなどを行う
• Backendプロセス : SQLを処理するプロセス
• Background Worker (bg worker)プロセス : 任意の処理を定義できるプロセス
PostgreSQLのアーキテクチャ
DBデータ
（テーブル、インデックスなど）
共有バッファ WALバッファ
WAL
（トランザクションログ）
backendbackendbackend
(postgres)
postmaster wal writer
bg writer
auto
vacuum
stat
collector
logger
archiver
wal
receiver
wal
sender
wal
sender
wal
sender
wal
sender
wal
senderbg worker
その他
制御情報
startup

Replicationについて

• データを複数のマシンにコピーすること
• 一つに障害が起きても動き続けられる
• データのコピーを各ユーザに近い場所に配置することも可能
• データのコピーに対して読み込みクエリを発行することも可能
• マスタとスタンバイ
• プライマリとスレーブ、リーダーとフォロワーなど呼び方は色々
• レプリケーショントポロジー
データベース・レプリケーションとは？

何を複製(Replication)するか？
UPDATE tbl
SET price = 100
WHERE id = ‘ABC000’;
Log shipping
97d0 0700 1800 ef12
0300 55b1 0300 54b1
0300 0000 0000 0000 ...
Statement-based
“UPDATE tbl
SET price = 100
WHERE id = ‘ABC000’;”
Row-based
Table : tbl
Row : id = ‘ABC000’,
price = 100
Master
Standby
Client
Logical Replication
はこれ↓
Streaming Replication
はこれ↓

Streaming Replicationを理解する

Streaming Replicationの基本的なアーキテクチャ
WAL WAL
Write WAL
Send WAL
COMMIT
Write WAL
OK
Apply WAL
• マスタはWALを送り続ける
• スタンバイはリカバリをし続ける
• 物理的に同じデータベースを複製する
一台のときの
処理
レプリケーショ
ン構成での処理

backend
より詳細に
WAL WAL
backend wal sender wal receiver startup
Table Table
1. Write
1. Modify
3. Read
4. Send
OK
(LSNs)
6. Notify
5. Write 7. Read
8. Apply
• 処理の順番
1. backendプロセスがWALを書き、wal senderプロセスに通知
2. wal senderプロセスはwal receiverプロセスにWALを送る
3. wal receiverプロセスはWALを受信後、startupプロセスに通知
• スタンバイではリカバリをし続けている状態(startupプロセス)
• スタンバイはマスタにLSN（どこまでWALを受信したか）を返す
2. Notify

• WALを複製＋スタンバイでリカバリすることでDBを複製する
• 物理的に全く同じDBが出来上がる
• スタンバイではDBを変更するような操作はできない(Read-Only)
• メジャーバージョンを跨いだレプリケーションはできない
• 1：Nのレプリケーションのみ可能
• トランザクションの途中でも、生成されたWALは随時複製される
（”Streaming” Replication)
• ロールバックされた変更情報も複製される
• スタンバイはマスタに昇格(Promote)可能
• プロセス間のデータ連携は共有メモリやWALファイルで行う
Streaming Replication - 特徴まとめ

使い方（設定、設計編）

• 最低限必要なパラメータ（マスタ側）
• wal_level = replica(デフォルト) or logical
• max_wal_senders > 0
• レプリケーション接続を許可(pg_hba.conf)
• その他関連するパラメータ
• max_replication_slots
• wal_keep_segments
• hot_standby
• hot_standby_feedback
• synchronous_standby_names
• wal_sender_timeout
• wal_receiver_timeout
• wal_log_hints
など（たくさんある）
使い方（設定編）

• 非同期レプリケーション
• スタンバイでのWAL書き込みを待たない
• 同期レプリケーション
• スタンバイでのWAL書き込みを待つ
同期、非同期の選択
性
能
信
頼
性

非同期レプリケーション
• スタンバイにWALを非同期的に送る
• COMMITはスタンバイでのWAL書き込みを待たない
• マスタでCOMMIT済みデータは、スタンバイには存在しないかもしれない
data change OK
Time
Client
Master
Standby
OKdata change

非同期レプリケーション
OK
Time
Client
Master
Standby
old
value
data change
read data
Become a new master
• スタンバイにWALを非同期的に送る
• COMMITはスタンバイでのWAL書き込みを待たない
• マスタでCOMMIT済みデータは、スタンバイには存在しないかもしれない

同期レプリケーション
• COMMITはスタンバイでのWAL書き込みを待つ
• マスタでCOMMIT済み（COMMIT OKとなったデータ）は、マスタ、スタンバ
イの両方に存在することを保証する
data change
OK
OK
Time
Client
Master
Standby
waiting for standby
flush
data change

synchronous_commit =
[ off | local | remote_write | on | remote_apply ]
• remote_writeは、WALのメモリ書き込みまで待つ
• 「MySQLでの準同期」＝「PostgreSQLの同期(synchronous_commit = on)」
トランザクション単位での設定
data change
OK
OK
Time
Client
Master
Standby
waiting for standby...
write applyflush
OK OK

• スタンバイがスタンバイを持てる
• カスケード・スタンバイは非同期レプリケーションのみ使用可能
カスケード構成
Master
Standby (sync)
Standbys (async)
Cascading
Standbys (async)
Cascading
Standbys (async)

• synchronous_standby_namesパラメータをマスタ側で設定
• 複数のスタンバイに対して同期レプリケーションを利用できる
• 2つの方法を用意
• Priority-based (9.6~)
• Quorum-based (10~)
複数の同期スタンバイ構成
Master
Standby (sync)
Master
Standbys (quorum)
Priority-based Quorum-based
予め指定した2つの
同期スタンバイ
からのOKを待つよ
5つの内どれか
2つからのOKを
待つよ
Standby (async)

• スタンバイでのリカバリを”あえて”遅らせる
• オペミス起因のデータ損失等に対応できる
• recovery_min_apply_delayで遅延時間を指定可能
• 「WALは受け取っているがリカバリはしてない」という状態になる
• synchronous_commit = remote_applyを使用しているときは要注意
• 遅らせた分がそのままトランザクション処理の遅延に影響する
遅延レプリケーション

使い方（構築編）

必要なのは以下の３ステップ
1. マスタサーバから物理バックアップを取得
• DB停止 → 物理コピー → DB起動
• pg_start_backup関数 → 物理コピー → pg_stop_backup関数
• pg_basebackup
• ※論理バックアップは利用できない
2. スタンバイサーバの設定
3. スタンバイサーバを起動

• 設定必須なパラメータ
• standby_mode = on
• primary_conninfo = ‘マスタサーバへの接続情報’
• primary_conninfo = ‘host=xxx port=yyy dbname=zzz user=xxx’
• 必要に応じて
• primary_sloname
• recovery_target_timeline
• trigger_file
スタンバイサーバの設定

使い方（監視編）

=# SELECT received_lsn,
last_msg_send_time,
last_msg_receipt_time,
latest_end_time
FROM pg_stat_wal_receiver;
-[ RECORD 1 ]---------+------------------------------
received_lsn | 0/46381F8
last_msg_send_time | 2018-01-18 10:39:30.151872+09
last_msg_receipt_time | 2018-01-18 10:39:30.15193+09
latest_end_time | 2018-01-18 10:39:30.151872+09
スタンバイ側からの監視

使い方（参照負荷分散）

• Streaming Replicationで参照負荷分散は可能
• pgpool-IIやPgBouncerを利用して振り分ける事が多い
• ホットスタンバイで使用する際に注意すべき点は、以下の3つ
• 参照結果の整合性
• レプリケーション競合
• マスタでのデータ肥大化
ホットスタンバイ（参照負荷分散）

• synchronous_commit = ‘remote_apply’
• COMMITは、スタンバイでWALが書き込み＋リカバリされる
（＝ユーザに変更結果が見えるようになるまで）まで待つ
Reading Your Own Writes
OK
Time
Client
Master
Standby
write & flush apply
OK
INSERT INTO tbl ...
Read
previous writes
No result!
data change

Reading Your Own Writes
OK
Time
Client
Master
Standby
write & flush apply
OK
INSERT INTO tbl ... Read
Found!
data change
wait for data to be applied
• synchronous_commit = ‘remote_apply’
• COMMITは、スタンバイでWALが書き込み＋リカバリされる
（＝ユーザに変更結果が見えるようになるまで）まで待つ

• 何が競合するか？
• クエリ処理とリカバリ
• スタンバイでの参照 vs その参照しているデータの物理削除
（をするWALのリカバリ）
• スタンバイでの参照 vs その参照しているテーブルへの排他ロック
（を取得するWALのリカバリ）
• スタンバイでの参照 vs その参照しているデータベースの削除
（をするWALのリカバリ）
レプリケーション競合

• マスタでパラメータを設定することで、物理削除起因のレプリケーション競合を防ぐ
ことができる
• マスタ側で設定
• vacuum_defer_cleanup_age
• 物理削除のタイミングを遅らせる
• スタンバイ側で設定
• hot_standby_feedback
• スタンバイの活動状況をマスタに通知する
• スタンバイが参照してる可能性のあるデータの物理削除をしないようにする
• スタンバイでのロングトランザクションに注意
レプリケーション競合を防ぐ

• リカバリを優先したい！
• レプリケーション遅延をなるべく起こしたくない
• スタンバイのWAL領域溢れを防ぎたい
• クエリ処理を優先したい！
• スタンバイで分析系SQLを実行したい
• スタンバイで論理バックアップを取得したい
• max_standby_streaming_delayで設定する
• -1 : クエリが完了するまで待つ（クエリ優先）
• >= 0 : 設定値以上たったらクエリをキャンセル（リカバリ優先）
クエリ処理を優先する？リカバリを優先する？

• 遅延するとスタンバイで見えるデータが古い
• かつ、レプリケーションが継続できなくなる
レプリケーション遅延
-- WAL受信自体が遅れている
sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag
-----------+-----------+-----------+------------+-----------------+-----------------+-----------------
0/A060000 | 0/A000000 | 0/A000000 | 0/9F90968 | 00:00:21.729059 | 00:00:21.729059 | 00:00:23.218801
(1 row)
-- 受信はできているがリカバリが遅れている
sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag
-----------+-----------+-----------+------------+-----------------+-----------------+----------------
0/799CCC0 | 0/799CCC0 | 0/799CCC0 | 0/78F76C8 | 00:00:00.000149 | 00:00:00.000475 | 00:00:21.75451
(1 row)

• 必要なWALがマスタ上でリサイクル（アーカイブ）されてしまう
• “FATAL: could not receive data from WAL stream ERROR: requested
WAL segment 000000010000000000000007 has already been removed”
• スタンバイを一時的に停止していた場合にもよく発生する
• 解決策
• restore_command = ‘scp hostname:/path/to/%f %p’
• アーカイブWALから必要なWALを持ってくる
• ただし、アーカイブされたWALも削除された場合はどうする？
• wal_keep_segments
• マスタ側で余分にWALを持っておく
• ただし、想定以上のWALが生成されたらどうする？
レプリケーション遅延の影響

• スタンバイが必要としてるWALを”絶対に”削除しない
• 設定方法
• マスタ側でレプリケーションスロット作成
• pg_physical_replication_slot関数
• スタンバイ側でレプリケーションスロットを使うように設定
• primary_slot_name(recovery.conf内)
• スタンバイが受信するまでWALを持ち続けるので、ディスクフルに
注意
• うっかり消し忘れる事が多い
レプリケーションスロット

• コミュニティ提供の自動昇格機能がない！
• PG-REX、pgpool-II、repmgr、PAF等を使う事が多い
• マスタサーバを復旧し、起動。または、スタンバイサーバを昇格
• 昇格(Promote)方法は２つ
• pg_ctl promote
• trigger_file
マスタサーバがダウン・・・どうする？

• マスタサーバ回復後、新しいスタンバイとして利用したい
• 更にその後、マスタとスタンバイを元の関係に戻したい（スイッチバック）と
きもある
• 旧マスタはそのままは使えない事に注意
• 同期レプリケーションの場合でも使えないことに注意
旧マスタサーバの再利用
マスタ
スタンバイ
最初の
マスタサーバ
最初の
スタンバイサーバ
ここからは
新しいマスタサーバ
サーバ間で物理的に異
なる可能性がある部分

• 旧マスタサーバ再利用のための方法は２つ
1. 新しいマスタサーバのバックアップを取り直して、スタンバ
イを再構築
2. pg_rewindを使う
ではどうするか？

• 新しいマスタから物理バックアップを再取得する
• 再取得したバックアップを使ってスタンバイとして起動
• スイッチバック(マスタ正常終了の後に切り替え)する時は、バックアップは必要ない
• データベースが大きいと時間が掛かる
1. バックアップを取り直す
Master Standby
New
Master
Replication Replication
full backup
Master
MasterStandby

• 旧マスタの状態を巻き戻して(rewind)して、再利用する
• サーバ間の差分を転送するだけで良いので短い時間で済む
• wal_log_hintsもしくはchecksumの設定が必要
2. pg_rewindを使う(v9.5 ~)
Master Standby
New
Master
Replication Replication
send only deltas
Master
MasterStandby
pg_rewind

• 同期レプリケーションの場合、マスタサーバでの更新系トランザ
クションは止まる
• タイムアウト等は用意されていない
• クエリのキャンセルは可能
• 同期待ちで止まっているプロセスは、ps コマンドでプロセスを見ると「XXX waiint for
XXX/XXX」となっている
• 外部ツールで検知して、非同期レプリケーションに変更する必要がある
• synchronous_standby_namesを空にして、設定ファイルの再読込
スタンバイサーバがダウンしたらどうなる？

Logical Replicationを理解する

• データベースの一部を複製する
• 複数ソースからの受信
• メジャーバージョンが異なるPostgreSQL間でのレプリケ
ーション
• Row-based
• 初期データコピー
• Publication / Subscription
Logical Replication

• Partial replication (sending a subset of a database)
• Consolidating multiple database into a single one
• On-line major version updating
• Sharing a subset of the database
• Multi-master replication
ユースケース

• Logical Replicationのインフラとなる機能
• WALを任意の形式にデコードする
Logical Decoding
BEGIN;
CREATE TABLE tbl (c int primary key);
INSERT INTO tbl VALUES (1), (2), (3);
COMMIT;
SELECT lsn, data FROM pg_logical_slot_get_changes('slot',
pg_current_wal_lsn(), 10);
lsn | data
------------+----------------------------------------
1/331723E8 | BEGIN 242422
1/3317A778 | table public.tbl: INSERT: c[integer]:1
1/3317A848 | table public.tbl: INSERT: c[integer]:2
1/3317A8C8 | table public.tbl: INSERT: c[integer]:3
1/3317ABC0 | COMMIT 242422
(5 rows)

Logical Replicationの基本的なアーキテクチャ
backend
WAL WAL
backend wal sender apply worker
Table Table
1. Write
1. Modify
3. Read
4. Decode and Send
OK
(LSNs)
5. Write
5. Apply
2. Notify
• Streaming Replicationと似ている
• 違うところは、
• wal senderがWALをデコード、デコードしたデータを送信する
• apply workerがデータを受信して、テーブルに反映

より詳細に
WAL
INSERT
Write
Read
Decode
COMMIT
UPDATE
UPDATE
DELETE
INSERTDELETE
INSERT
INSERT
Reorder Buffer
COMMIT
Decode
change_cb
begin_cb
commit_cb
origin_cb
pgoutput
backendbackendbackend wal sender
apply worker
Logical Decoding
Replication Slot
slot_name = ‘slot’
plugin = ‘pgoutput’
restart_lsn = X/ABC000
:

• Logical Decoding(WALをデコードする機能)がベース
• プラグインの書き方次第では、PostgreSQL→他DBMSというレプリケーションも可能
• Logical Replicationもプラグインの一つ
• 論理的な変更情報(行単位)を送信している
• RAND()とかCURRENT_TIMESTAMPとかも上流、下流で結果が異なる心配はない
• 1:N、N:1、カスケードの構成が可能
• 双方向レプリケーションはテーブルが異なれば可能
• COMMITレコードをデコードした時に変更情報を送信する
• COMMITされたトランザクション情報しか複製されない
• テーブルのフィルタリングは上流で行う
• 上流、下流で必ずしも同じテーブル定義である必要はない
• 列数が異なっていてもOK
• 下流のテーブルの列が足りないのはNG
• 列のデータ型が異なっていてもOK
• 変更データの転送はテキスト形式
アーキテクチャ特徴まとめ

使い方（設定、設計編）

• 設定必須パラメータ
• wal_level = logical
• max_wal_senders > 0
• max_replication_slots > 0
• max_worker_processes > 0
• max_logical_replication_workers > 0
• 設定推奨パラメータ
• max_sync_workers_per_subscriptions > 0
使い方（設定編）

• 基本的にはStreaming Replicationと同じ様に設定できる
• Publisherのsynchronous_standby_namesにSubscriberのSubscription名
を入れる
• synchronous_commitも同じように利用可能
• 同期レプリケーションを使うときの注意
• 同期、非同期の選択はサーバ単位
• テーブルの変更情報を受け取らないSubscriberからのACKも待つ
• Publisherの同期COMMIT設定はONにしておく
• クエリのレイテンシが大きくなりやすい
• PostgreSQL 11で改善するかも
同期、非同期の選択

• Publicationに複数テーブルを設定する
• Subscriber(受信側)は受信するPublicationを選択する
Publication / Subscription
Table
A
Table
B
Table
C
Table
D
Subscriber
Subscriber
pubA
pubBPublisher

-- On publisher
-- テーブル作成
CREATE TABLE tbl (k int primary key, v int);
-- PUBLICATION作成し、tblを登録
CREATE PUBLICATION tbl_pub FOR TABLE tbl;
-- データを入れる
INSERT INTO tbl VALUES (1), (2), (3);
使い方（構築）
-- On subscriber
-- テーブルを作成（Subscriber側でも）
CREATE TABLE tbl (k int primary key, v int);
-- SUBSCRIPTIONを作成し、レプリケーション開始。
CREATE SUBSCRIPTION tbl_sub CONNECTION ‘...’ PUBLICATION tbl_pub;
-- デフォルトで初期データコピーが有効なのでデータが非同期的にコピーされる
SELECT * FROM tbl;
c
---
1
2
3
(3 rows)

-- On publisher
-- 対象テーブルを追加
ALTER PUBLICATION tbl_pub ADD TABLE tbl2;
-- INSERTとUPDATEだけ複製するように変更
ALTER PUBLICATION tbl_pub SET (publish = ‘insert, update’);
使い方（対象テーブルを変更する）
-- On subscriber
-- テーブルを作成
CREATE TABLE tbl2 (id int primary key, name text);
-- SUBSCRIPTIONを更新し、PUBLICATIONの変更を反映
ALTER SUBSCRIPTION tbl_sub REFRESH PUBLICATION tbl_pub WITH
(copy_data = false);

• Streaming Replicationと同じ！！
マスタ側からの監視方法

使い方（監視編）

• 同一データに対する変更は「後勝ち方式」
• エラーが発生した場合は、成功するまでずっと繰り返す
• 手動で解決する方法はある(pg_replication_origin_advance関数)
• 競合をモニタリングする方法がない…
レプリケーション競合

• INSERT/DELETE/UPDATEのみ対応
• DDL、シーケンス等は未対応
• レプリケーション・ラグが発生しやすい
• 大きな変更を1トランザクションで実行する時は注意
• 同期レプリケーションの場合は特に注意
• 同期レプリケーションは使えるがDBインスタンス単位
• テーブル、Subscription、Publication単位での指定はできない
• ハングするケースがいくつかある
• 同時にCREATE SUBSCRIPTION ... WITH (create_slot = true)
• 同時にALTER SUBSCRIPTION REFRESH PUBLICATION WITH (copy_data =
ture)
• など
現在(v10)の制約のまとめ

まとめ

• Streaming Replicationは10歳
• 利用事例多数
• 機能、周辺ツールが揃っている
• Logical Replicationは0歳
• ポテンシャルは非常に高い
• まだいくつか制約、使いづらい点がある
• Streaming Replicationで使っている機能を利用することで、ユー
ザにも使いやすい＋コードを再利用できる
まとめ

THANK YOU !!

参考資料

Logical Replication開発の歴史
https://blog.2ndquadrant.com/bdr-history-and-future/

• データベースのベースバックアップ＋WALを使って、任意の時点（～障害
直前の状態）にデータを復旧することが可能
PITR (Point In Time Recovery)
WAL
②
サーバダウンDB
バッ
クア
ップ
WAL
①
CHECKPOINT ②
WAL
①
①まで復旧：バックアップ＋WAL①
②まで復旧：現在のDB＋WAL②
または、
バックアップ+WAL①、②

アーキテクチャから理解するPostgreSQLのレプリケーション

More Related Content

アーキテクチャから理解するPostgreSQLのレプリケーション