SlideShare a Scribd company logo
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全文検索モジュール
3Copyright©2018 NTT Corp. All Rights Reserved.
• PostgreSQLのアーキテクチャについて簡単におさらい
• Replicationについて
• Streaming Replicationを理解する
• 設定、構築、運用など
• Logical Replicationを理解する
• 設定、構築、運用など
Index
4Copyright©2018 NTT Corp. All Rights Reserved.
PostgreSQLのアーキテクチャ
5Copyright©2018 NTT Corp. All Rights Reserved.
• プロセスモデル
• 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
6Copyright©2018 NTT Corp. All Rights Reserved.
Replicationについて
7Copyright©2018 NTT Corp. All Rights Reserved.
• データを複数のマシンにコピーすること
• 一つに障害が起きても動き続けられる
• データのコピーを各ユーザに近い場所に配置することも可能
• データのコピーに対して読み込みクエリを発行することも可能
• マスタとスタンバイ
• プライマリとスレーブ、リーダーとフォロワーなど呼び方は色々
• レプリケーショントポロジー
データベース・レプリケーションとは?
8Copyright©2018 NTT Corp. All Rights Reserved.
何を複製(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
はこれ↓
9Copyright©2018 NTT Corp. All Rights Reserved.
Streaming Replicationを理解する
10Copyright©2018 NTT Corp. All Rights Reserved.
Streaming Replicationの基本的なアーキテクチャ
WAL WAL
Write WAL
Send WAL
COMMIT
Write WAL
OK
Apply WAL
• マスタはWALを送り続ける
• スタンバイはリカバリをし続ける
• 物理的に同じデータベースを複製する
一台のときの
処理
レプリケーショ
ン構成での処理
11Copyright©2018 NTT Corp. All Rights Reserved.
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
12Copyright©2018 NTT Corp. All Rights Reserved.
• WALを複製+スタンバイでリカバリすることでDBを複製する
• 物理的に全く同じDBが出来上がる
• スタンバイではDBを変更するような操作はできない(Read-Only)
• メジャーバージョンを跨いだレプリケーションはできない
• 1:Nのレプリケーションのみ可能
• トランザクションの途中でも、生成されたWALは随時複製される
(”Streaming” Replication)
• ロールバックされた変更情報も複製される
• スタンバイはマスタに昇格(Promote)可能
• プロセス間のデータ連携は共有メモリやWALファイルで行う
Streaming Replication - 特徴まとめ
13Copyright©2018 NTT Corp. All Rights Reserved.
使い方(設定、設計編)
14Copyright©2018 NTT Corp. All Rights Reserved.
• 最低限必要なパラメータ(マスタ側)
• 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
など(たくさんある)
使い方(設定編)
15Copyright©2018 NTT Corp. All Rights Reserved.
• 非同期レプリケーション
• スタンバイでのWAL書き込みを待たない
• 同期レプリケーション
• スタンバイでのWAL書き込みを待つ
同期、非同期の選択
性
能
信
頼
性
16Copyright©2018 NTT Corp. All Rights Reserved.
非同期レプリケーション
• スタンバイにWALを非同期的に送る
• COMMITはスタンバイでのWAL書き込みを待たない
• マスタでCOMMIT済みデータは、スタンバイには存在しないかもしれない
data change OK
Time
Client
Master
Standby
OKdata change
17Copyright©2018 NTT Corp. All Rights Reserved.
非同期レプリケーション
OK
Time
Client
Master
Standby
old
value
data change
read data
Become a new master
• スタンバイにWALを非同期的に送る
• COMMITはスタンバイでのWAL書き込みを待たない
• マスタでCOMMIT済みデータは、スタンバイには存在しないかもしれない
18Copyright©2018 NTT Corp. All Rights Reserved.
同期レプリケーション
• COMMITはスタンバイでのWAL書き込みを待つ
• マスタでCOMMIT済み(COMMIT OKとなったデータ)は、マスタ、スタンバ
イの両方に存在することを保証する
data change
OK
OK
Time
Client
Master
Standby
waiting for standby
flush
data change
19Copyright©2018 NTT Corp. All Rights Reserved.
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
20Copyright©2018 NTT Corp. All Rights Reserved.
• スタンバイがスタンバイを持てる
• カスケード・スタンバイは非同期レプリケーションのみ使用可能
カスケード構成
Master
Standby (sync)
Standbys (async)
Cascading
Standbys (async)
Cascading
Standbys (async)
21Copyright©2018 NTT Corp. All Rights Reserved.
• 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)
22Copyright©2018 NTT Corp. All Rights Reserved.
• スタンバイでのリカバリを”あえて”遅らせる
• オペミス起因のデータ損失等に対応できる
• recovery_min_apply_delayで遅延時間を指定可能
• 「WALは受け取っているがリカバリはしてない」という状態になる
• synchronous_commit = remote_applyを使用しているときは要注意
• 遅らせた分がそのままトランザクション処理の遅延に影響する
遅延レプリケーション
23Copyright©2018 NTT Corp. All Rights Reserved.
使い方(構築編)
24Copyright©2018 NTT Corp. All Rights Reserved.
必要なのは以下の3ステップ
1. マスタサーバから物理バックアップを取得
• DB停止 → 物理コピー → DB起動
• pg_start_backup関数 → 物理コピー → pg_stop_backup関数
• pg_basebackup
• ※論理バックアップは利用できない
2. スタンバイサーバの設定
3. スタンバイサーバを起動
使い方(構築編)
25Copyright©2018 NTT Corp. All Rights Reserved.
• 設定必須なパラメータ
• standby_mode = on
• primary_conninfo = ‘マスタサーバへの接続情報’
• primary_conninfo = ‘host=xxx port=yyy dbname=zzz user=xxx’
• 必要に応じて
• primary_sloname
• recovery_target_timeline
• trigger_file
スタンバイサーバの設定
26Copyright©2018 NTT Corp. All Rights Reserved.
使い方(監視編)
27Copyright©2018 NTT Corp. All Rights Reserved.
=# SELECT application_name,
sent_lsn, write_lsn, flush_lsn, replay_lsn,
write_lag, flush_lag, replay_lag,
sync_state, state
FROM pg_stat_replication ;
-[ RECORD 1 ]----+----------------
application_name | node1
sent_lsn | 0/46349B8
write_lsn | 0/46349B8
flush_lsn | 0/46349B8
replay_lsn | 0/46349B8
write_lag | 00:00:00.010832
flush_lag | 00:00:00.017551
replay_lag | 00:00:00.21462
sync_state | sync
state | streaming
-[ RECORD 2 ]----+----------------
application_name | node2
sent_lsn | 0/46349B8
write_lsn | 0/46349B8
flush_lsn | 0/46349B8
replay_lsn | 0/46349B8
:
マスタ側からの監視
LSNで送信状況、受信状況を
確認(バイト数でラグが確認でき
る)
レプリケーション遅延を時間で表
示(v10~)
28Copyright©2018 NTT Corp. All Rights Reserved.
=# 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
スタンバイ側からの監視
29Copyright©2018 NTT Corp. All Rights Reserved.
使い方(参照負荷分散)
30Copyright©2018 NTT Corp. All Rights Reserved.
• Streaming Replicationで参照負荷分散は可能
• pgpool-IIやPgBouncerを利用して振り分ける事が多い
• ホットスタンバイで使用する際に注意すべき点は、以下の3つ
• 参照結果の整合性
• レプリケーション競合
• マスタでのデータ肥大化
ホットスタンバイ(参照負荷分散)
31Copyright©2018 NTT Corp. All Rights Reserved.
• 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
32Copyright©2018 NTT Corp. All Rights Reserved.
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が書き込み+リカバリされる
(=ユーザに変更結果が見えるようになるまで)まで待つ
33Copyright©2018 NTT Corp. All Rights Reserved.
• 何が競合するか?
• クエリ処理とリカバリ
• スタンバイでの参照 vs その参照しているデータの物理削除
(をするWALのリカバリ)
• スタンバイでの参照 vs その参照しているテーブルへの排他ロック
(を取得するWALのリカバリ)
• スタンバイでの参照 vs その参照しているデータベースの削除
(をするWALのリカバリ)
レプリケーション競合
34Copyright©2018 NTT Corp. All Rights Reserved.
• マスタでパラメータを設定することで、物理削除起因のレプリケーション競合を防ぐ
ことができる
• マスタ側で設定
• vacuum_defer_cleanup_age
• 物理削除のタイミングを遅らせる
• スタンバイ側で設定
• hot_standby_feedback
• スタンバイの活動状況をマスタに通知する
• スタンバイが参照してる可能性のあるデータの物理削除をしないようにする
• スタンバイでのロングトランザクションに注意
レプリケーション競合を防ぐ
35Copyright©2018 NTT Corp. All Rights Reserved.
• リカバリを優先したい!
• レプリケーション遅延をなるべく起こしたくない
• スタンバイのWAL領域溢れを防ぎたい
• クエリ処理を優先したい!
• スタンバイで分析系SQLを実行したい
• スタンバイで論理バックアップを取得したい
• max_standby_streaming_delayで設定する
• -1 : クエリが完了するまで待つ(クエリ優先)
• >= 0 : 設定値以上たったらクエリをキャンセル(リカバリ優先)
クエリ処理を優先する?リカバリを優先する?
36Copyright©2018 NTT Corp. All Rights Reserved.
• 遅延するとスタンバイで見えるデータが古い
• かつ、レプリケーションが継続できなくなる
レプリケーション遅延
-- 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)
37Copyright©2018 NTT Corp. All Rights Reserved.
• 必要な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が生成されたらどうする?
レプリケーション遅延の影響
38Copyright©2018 NTT Corp. All Rights Reserved.
• スタンバイが必要としてるWALを”絶対に”削除しない
• 設定方法
• マスタ側でレプリケーションスロット作成
• pg_physical_replication_slot関数
• スタンバイ側でレプリケーションスロットを使うように設定
• primary_slot_name(recovery.conf内)
• スタンバイが受信するまでWALを持ち続けるので、ディスクフルに
注意
• うっかり消し忘れる事が多い
レプリケーションスロット
39Copyright©2018 NTT Corp. All Rights Reserved.
• コミュニティ提供の自動昇格機能がない!
• PG-REX、pgpool-II、repmgr、PAF等を使う事が多い
• マスタサーバを復旧し、起動。または、スタンバイサーバを昇格
• 昇格(Promote)方法は2つ
• pg_ctl promote
• trigger_file
マスタサーバがダウン・・・どうする?
40Copyright©2018 NTT Corp. All Rights Reserved.
• マスタサーバ回復後、新しいスタンバイとして利用したい
• 更にその後、マスタとスタンバイを元の関係に戻したい(スイッチバック)と
きもある
• 旧マスタはそのままは使えない事に注意
• 同期レプリケーションの場合でも使えないことに注意
旧マスタサーバの再利用
マスタ
スタンバイ
最初の
マスタサーバ
最初の
スタンバイサーバ
ここからは
新しいマスタサーバ
サーバ間で物理的に異
なる可能性がある部分
41Copyright©2018 NTT Corp. All Rights Reserved.
• 旧マスタサーバ再利用のための方法は2つ
1. 新しいマスタサーバのバックアップを取り直して、スタンバ
イを再構築
2. pg_rewindを使う
ではどうするか?
42Copyright©2018 NTT Corp. All Rights Reserved.
• 新しいマスタから物理バックアップを再取得する
• 再取得したバックアップを使ってスタンバイとして起動
• スイッチバック(マスタ正常終了の後に切り替え)する時は、バックアップは必要ない
• データベースが大きいと時間が掛かる
1. バックアップを取り直す
Master Standby
New
Master
Replication Replication
full backup
Master
MasterStandby
43Copyright©2018 NTT Corp. All Rights Reserved.
• 旧マスタの状態を巻き戻して(rewind)して、再利用する
• サーバ間の差分を転送するだけで良いので短い時間で済む
• wal_log_hintsもしくはchecksumの設定が必要
2. pg_rewindを使う(v9.5 ~)
Master Standby
New
Master
Replication Replication
send only deltas
Master
MasterStandby
pg_rewind
44Copyright©2018 NTT Corp. All Rights Reserved.
• 同期レプリケーションの場合、マスタサーバでの更新系トランザ
クションは止まる
• タイムアウト等は用意されていない
• クエリのキャンセルは可能
• 同期待ちで止まっているプロセスは、ps コマンドでプロセスを見ると「XXX waiint for
XXX/XXX」となっている
• 外部ツールで検知して、非同期レプリケーションに変更する必要がある
• synchronous_standby_namesを空にして、設定ファイルの再読込
スタンバイサーバがダウンしたらどうなる?
45Copyright©2018 NTT Corp. All Rights Reserved.
Logical Replicationを理解する
46Copyright©2018 NTT Corp. All Rights Reserved.
• データベースの一部を複製する
• 複数ソースからの受信
• メジャーバージョンが異なるPostgreSQL間でのレプリケ
ーション
• Row-based
• 初期データコピー
• Publication / Subscription
Logical Replication
47Copyright©2018 NTT Corp. All Rights Reserved.
• 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
ユースケース
48Copyright©2018 NTT Corp. All Rights Reserved.
• 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)
49Copyright©2018 NTT Corp. All Rights Reserved.
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がデータを受信して、テーブルに反映
50Copyright©2018 NTT Corp. All Rights Reserved.
より詳細に
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
:
51Copyright©2018 NTT Corp. All Rights Reserved.
• Logical Decoding(WALをデコードする機能)がベース
• プラグインの書き方次第では、PostgreSQL→他DBMSというレプリケーションも可能
• Logical Replicationもプラグインの一つ
• 論理的な変更情報(行単位)を送信している
• RAND()とかCURRENT_TIMESTAMPとかも上流、下流で結果が異なる心配はない
• 1:N、N:1、カスケードの構成が可能
• 双方向レプリケーションはテーブルが異なれば可能
• COMMITレコードをデコードした時に変更情報を送信する
• COMMITされたトランザクション情報しか複製されない
• テーブルのフィルタリングは上流で行う
• 上流、下流で必ずしも同じテーブル定義である必要はない
• 列数が異なっていてもOK
• 下流のテーブルの列が足りないのはNG
• 列のデータ型が異なっていてもOK
• 変更データの転送はテキスト形式
アーキテクチャ特徴まとめ
52Copyright©2018 NTT Corp. All Rights Reserved.
使い方(設定、設計編)
53Copyright©2018 NTT Corp. All Rights Reserved.
• 設定必須パラメータ
• 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
使い方(設定編)
54Copyright©2018 NTT Corp. All Rights Reserved.
• 基本的にはStreaming Replicationと同じ様に設定できる
• Publisherのsynchronous_standby_namesにSubscriberのSubscription名
を入れる
• synchronous_commitも同じように利用可能
• 同期レプリケーションを使うときの注意
• 同期、非同期の選択はサーバ単位
• テーブルの変更情報を受け取らないSubscriberからのACKも待つ
• Publisherの同期COMMIT設定はONにしておく
• クエリのレイテンシが大きくなりやすい
• PostgreSQL 11で改善するかも
同期、非同期の選択
55Copyright©2018 NTT Corp. All Rights Reserved.
使い方(構築編)
56Copyright©2018 NTT Corp. All Rights Reserved.
• Publicationに複数テーブルを設定する
• Subscriber(受信側)は受信するPublicationを選択する
Publication / Subscription
Table
A
Table
B
Table
C
Table
D
Subscriber
Subscriber
pubA
pubBPublisher
57Copyright©2018 NTT Corp. All Rights Reserved.
-- 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)
58Copyright©2018 NTT Corp. All Rights Reserved.
-- 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);
59Copyright©2018 NTT Corp. All Rights Reserved.
• Streaming Replicationと同じ!!
マスタ側からの監視方法
60Copyright©2018 NTT Corp. All Rights Reserved.
使い方(監視編)
61Copyright©2018 NTT Corp. All Rights Reserved.
# SELECT * FROM pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid | 16387
subname | hoge_sub
pid | 57387
relid |
received_lsn | 0/164A120
last_msg_send_time | 2018-01-23 10:40:56.95926+09
last_msg_receipt_time | 2018-01-23 10:40:56.959331+09
latest_end_lsn | 0/164A120
latest_end_time | 2018-01-23 10:40:56.95926+09
スタンバイ側からの監視方法
62Copyright©2018 NTT Corp. All Rights Reserved.
• 同一データに対する変更は「後勝ち方式」
• エラーが発生した場合は、成功するまでずっと繰り返す
• 手動で解決する方法はある(pg_replication_origin_advance関数)
• 競合をモニタリングする方法がない…
レプリケーション競合
63Copyright©2018 NTT Corp. All Rights Reserved.
• INSERT/DELETE/UPDATEのみ対応
• DDL、シーケンス等は未対応
• レプリケーション・ラグが発生しやすい
• 大きな変更を1トランザクションで実行する時は注意
• 同期レプリケーションの場合は特に注意
• 同期レプリケーションは使えるがDBインスタンス単位
• テーブル、Subscription、Publication単位での指定はできない
• ハングするケースがいくつかある
• 同時にCREATE SUBSCRIPTION ... WITH (create_slot = true)
• 同時にALTER SUBSCRIPTION REFRESH PUBLICATION WITH (copy_data =
ture)
• など
現在(v10)の制約のまとめ
64Copyright©2018 NTT Corp. All Rights Reserved.
まとめ
65Copyright©2018 NTT Corp. All Rights Reserved.
• Streaming Replicationは10歳
• 利用事例多数
• 機能、周辺ツールが揃っている
• Logical Replicationは0歳
• ポテンシャルは非常に高い
• まだいくつか制約、使いづらい点がある
• Streaming Replicationで使っている機能を利用することで、ユー
ザにも使いやすい+コードを再利用できる
まとめ
66Copyright©2018 NTT Corp. All Rights Reserved.
THANK YOU !!
67Copyright©2018 NTT Corp. All Rights Reserved.
参考資料
68Copyright©2018 NTT Corp. All Rights Reserved.
Logical Replication開発の歴史
https://blog.2ndquadrant.com/bdr-history-and-future/
69Copyright©2018 NTT Corp. All Rights Reserved.
• データベースのベースバックアップ+WALを使って、任意の時点(~障害
直前の状態)にデータを復旧することが可能
PITR (Point In Time Recovery)
WAL
②
サーバダウンDB
バッ
クア
ップ
WAL
①
CHECKPOINT ②
WAL
①
①まで復旧:バックアップ+WAL①
②まで復旧:現在のDB+WAL②
または、
バックアップ+WAL①、②

More Related Content

What's hot

Vacuum徹底解説
Vacuum徹底解説Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
 
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
NTT DATA Technology & Innovation
 
PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説
Masahiko Sawada
 
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラPostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
NTT DATA OSS Professional Services
 
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
NTT DATA Technology & Innovation
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
 
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
NTT DATA Technology & Innovation
 
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
Yoshinori Nakanishi
 
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
NTT DATA Technology & Innovation
 
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
NTT DATA Technology & Innovation
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?takezoe
 
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウト
Masahiko Sawada
 
[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用
Kosuke Kida
 
TIME_WAITに関する話
TIME_WAITに関する話TIME_WAITに関する話
TIME_WAITに関する話
Takanori Sejima
 
Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会Masahiko Sawada
 
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
 

What's hot (20)

Vacuum徹底解説
Vacuum徹底解説Vacuum徹底解説
Vacuum徹底解説
 
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
 
PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説
 
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラPostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
 
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
 
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajpAt least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
 
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
 
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのpg_basebackupの改善について(第13回PostgreSQLアンカンファレンス@オンライン)
 
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
 
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
 
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
 
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウト
 
[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用
 
TIME_WAITに関する話
TIME_WAITに関する話TIME_WAITに関する話
TIME_WAITに関する話
 
Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会Inside vacuum - 第一回PostgreSQLプレ勉強会
Inside vacuum - 第一回PostgreSQLプレ勉強会
 
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
 

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

[db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle D...
[db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle D...[db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle D...
[db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle D...
Insight Technology, Inc.
 
drecomにおけるwinning the metrics battle
drecomにおけるwinning the metrics battledrecomにおけるwinning the metrics battle
drecomにおけるwinning the metrics battleMitsuki Kenichi
 
Spring I/O 2015 報告
Spring I/O 2015 報告Spring I/O 2015 報告
Spring I/O 2015 報告
Takuya Iwatsuka
 
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
Insight Technology, Inc.
 
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
Tomoya Hibi
 
20211209 lt runtime_field
20211209 lt runtime_field20211209 lt runtime_field
20211209 lt runtime_field
Nomura Yuta
 
YJTC18 A-1 データセンタネットワークの取り組み
YJTC18 A-1 データセンタネットワークの取り組みYJTC18 A-1 データセンタネットワークの取り組み
YJTC18 A-1 データセンタネットワークの取り組み
Yahoo!デベロッパーネットワーク
 
Spring I/O 2016 報告 Test / Cloud / Other Popular Sessions
Spring I/O 2016 報告 Test / Cloud / Other Popular SessionsSpring I/O 2016 報告 Test / Cloud / Other Popular Sessions
Spring I/O 2016 報告 Test / Cloud / Other Popular Sessions
Takuya Iwatsuka
 
PostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめPostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめ
Ohyama Masanori
 
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo!デベロッパーネットワーク
 
Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側
Cloudera Japan
 
200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6
200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6
200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6
Hironobu Isoda
 
Autonomous を支える技術、Oracle Database 18c デモンストレーション
Autonomous を支える技術、Oracle Database 18c デモンストレーションAutonomous を支える技術、Oracle Database 18c デモンストレーション
Autonomous を支える技術、Oracle Database 18c デモンストレーション
オラクルエンジニア通信
 
DeNAでのVertica運用
DeNAでのVertica運用DeNAでのVertica運用
DeNAでのVertica運用
Shota Suzuki
 
OSSで作るOpenStack監視システム
OSSで作るOpenStack監視システムOSSで作るOpenStack監視システム
OSSで作るOpenStack監視システム
satsuki fukazu
 
20180220 AWS Black Belt Online Seminar - Amazon Container Services
20180220 AWS Black Belt Online Seminar - Amazon Container Services20180220 AWS Black Belt Online Seminar - Amazon Container Services
20180220 AWS Black Belt Online Seminar - Amazon Container Services
Amazon Web Services Japan
 
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化
Kazunori Sato
 
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
Insight Technology, Inc.
 
Spring I/O 2019 報告 Spring Frameworkのロードマップと5.2の新機能
Spring I/O 2019 報告 Spring Frameworkのロードマップと5.2の新機能Spring I/O 2019 報告 Spring Frameworkのロードマップと5.2の新機能
Spring I/O 2019 報告 Spring Frameworkのロードマップと5.2の新機能
Takuya Iwatsuka
 

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

[db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle D...
[db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle D...[db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle D...
[db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle D...
 
drecomにおけるwinning the metrics battle
drecomにおけるwinning the metrics battledrecomにおけるwinning the metrics battle
drecomにおけるwinning the metrics battle
 
Spring I/O 2015 報告
Spring I/O 2015 報告Spring I/O 2015 報告
Spring I/O 2015 報告
 
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
 
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
[D20] 高速Software Switch/Router 開発から得られた高性能ソフトウェアルータ・スイッチ活用の知見 (July Tech Fest...
 
20211209 lt runtime_field
20211209 lt runtime_field20211209 lt runtime_field
20211209 lt runtime_field
 
YJTC18 A-1 データセンタネットワークの取り組み
YJTC18 A-1 データセンタネットワークの取り組みYJTC18 A-1 データセンタネットワークの取り組み
YJTC18 A-1 データセンタネットワークの取り組み
 
Spring I/O 2016 報告 Test / Cloud / Other Popular Sessions
Spring I/O 2016 報告 Test / Cloud / Other Popular SessionsSpring I/O 2016 報告 Test / Cloud / Other Popular Sessions
Spring I/O 2016 報告 Test / Cloud / Other Popular Sessions
 
僕とヤフーと時々Teradata #prestodb
僕とヤフーと時々Teradata #prestodb僕とヤフーと時々Teradata #prestodb
僕とヤフーと時々Teradata #prestodb
 
PostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめPostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめ
 
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
 
Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側Apache Kuduを使った分析システムの裏側
Apache Kuduを使った分析システムの裏側
 
200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6
200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6
200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術 #jjug_ccc #ccc_g6
 
Autonomous を支える技術、Oracle Database 18c デモンストレーション
Autonomous を支える技術、Oracle Database 18c デモンストレーションAutonomous を支える技術、Oracle Database 18c デモンストレーション
Autonomous を支える技術、Oracle Database 18c デモンストレーション
 
DeNAでのVertica運用
DeNAでのVertica運用DeNAでのVertica運用
DeNAでのVertica運用
 
OSSで作るOpenStack監視システム
OSSで作るOpenStack監視システムOSSで作るOpenStack監視システム
OSSで作るOpenStack監視システム
 
20180220 AWS Black Belt Online Seminar - Amazon Container Services
20180220 AWS Black Belt Online Seminar - Amazon Container Services20180220 AWS Black Belt Online Seminar - Amazon Container Services
20180220 AWS Black Belt Online Seminar - Amazon Container Services
 
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化
 
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
コモディティサーバー3台で作る高速処理 “ハイパー・コンバージド・データベース・インフラストラクチャー(HCDI)” システム『Insight Qube』...
 
Spring I/O 2019 報告 Spring Frameworkのロードマップと5.2の新機能
Spring I/O 2019 報告 Spring Frameworkのロードマップと5.2の新機能Spring I/O 2019 報告 Spring Frameworkのロードマップと5.2の新機能
Spring I/O 2019 報告 Spring Frameworkのロードマップと5.2の新機能
 

More from Masahiko Sawada

行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
Masahiko Sawada
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
Masahiko Sawada
 
Transparent Data Encryption in PostgreSQL
Transparent Data Encryption in PostgreSQLTransparent Data Encryption in PostgreSQL
Transparent Data Encryption in PostgreSQL
Masahiko Sawada
 
PostgreSQL 12の話
PostgreSQL 12の話PostgreSQL 12の話
PostgreSQL 12の話
Masahiko Sawada
 
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
Masahiko Sawada
 
Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Transparent Data Encryption in PostgreSQL and Integration with Key Management...Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Masahiko Sawada
 
Bloat and Fragmentation in PostgreSQL
Bloat and Fragmentation in PostgreSQLBloat and Fragmentation in PostgreSQL
Bloat and Fragmentation in PostgreSQL
Masahiko Sawada
 
Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Database Encryption and Key Management for PostgreSQL - Principles and Consid...Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Masahiko Sawada
 
今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説
Masahiko Sawada
 
Vacuum more efficient than ever
Vacuum more efficient than everVacuum more efficient than ever
Vacuum more efficient than ever
Masahiko Sawada
 
Vacuumとzheap
VacuumとzheapVacuumとzheap
Vacuumとzheap
Masahiko Sawada
 
Parallel Vacuum
Parallel VacuumParallel Vacuum
Parallel Vacuum
Masahiko Sawada
 
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
Masahiko Sawada
 
PostgreSQL10徹底解説
PostgreSQL10徹底解説PostgreSQL10徹底解説
PostgreSQL10徹底解説
Masahiko Sawada
 
FDW-based Sharding Update and Future
FDW-based Sharding Update and FutureFDW-based Sharding Update and Future
FDW-based Sharding Update and Future
Masahiko Sawada
 
What’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributorWhat’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributor
Masahiko Sawada
 
PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介
Masahiko Sawada
 
pg_bigmと類似度検索
pg_bigmと類似度検索pg_bigmと類似度検索
pg_bigmと類似度検索
Masahiko Sawada
 
pg_bigmを触り始めた人に伝えたいこと
pg_bigmを触り始めた人に伝えたいことpg_bigmを触り始めた人に伝えたいこと
pg_bigmを触り始めた人に伝えたいこと
Masahiko Sawada
 
Introduction VAUUM, Freezing, XID wraparound
Introduction VAUUM, Freezing, XID wraparoundIntroduction VAUUM, Freezing, XID wraparound
Introduction VAUUM, Freezing, XID wraparound
Masahiko Sawada
 

More from Masahiko Sawada (20)

行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
 
Transparent Data Encryption in PostgreSQL
Transparent Data Encryption in PostgreSQLTransparent Data Encryption in PostgreSQL
Transparent Data Encryption in PostgreSQL
 
PostgreSQL 12の話
PostgreSQL 12の話PostgreSQL 12の話
PostgreSQL 12の話
 
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
OSS活動のやりがいとそれから得たもの - PostgreSQLコミュニティにて -
 
Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Transparent Data Encryption in PostgreSQL and Integration with Key Management...Transparent Data Encryption in PostgreSQL and Integration with Key Management...
Transparent Data Encryption in PostgreSQL and Integration with Key Management...
 
Bloat and Fragmentation in PostgreSQL
Bloat and Fragmentation in PostgreSQLBloat and Fragmentation in PostgreSQL
Bloat and Fragmentation in PostgreSQL
 
Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Database Encryption and Key Management for PostgreSQL - Principles and Consid...Database Encryption and Key Management for PostgreSQL - Principles and Consid...
Database Encryption and Key Management for PostgreSQL - Principles and Consid...
 
今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説
 
Vacuum more efficient than ever
Vacuum more efficient than everVacuum more efficient than ever
Vacuum more efficient than ever
 
Vacuumとzheap
VacuumとzheapVacuumとzheap
Vacuumとzheap
 
Parallel Vacuum
Parallel VacuumParallel Vacuum
Parallel Vacuum
 
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
OSS 開発ってどうやっているの? ~ PostgreSQL の現場から~
 
PostgreSQL10徹底解説
PostgreSQL10徹底解説PostgreSQL10徹底解説
PostgreSQL10徹底解説
 
FDW-based Sharding Update and Future
FDW-based Sharding Update and FutureFDW-based Sharding Update and Future
FDW-based Sharding Update and Future
 
What’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributorWhat’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributor
 
PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介
 
pg_bigmと類似度検索
pg_bigmと類似度検索pg_bigmと類似度検索
pg_bigmと類似度検索
 
pg_bigmを触り始めた人に伝えたいこと
pg_bigmを触り始めた人に伝えたいことpg_bigmを触り始めた人に伝えたいこと
pg_bigmを触り始めた人に伝えたいこと
 
Introduction VAUUM, Freezing, XID wraparound
Introduction VAUUM, Freezing, XID wraparoundIntroduction VAUUM, Freezing, XID wraparound
Introduction VAUUM, Freezing, XID wraparound
 

Recently uploaded

論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
Toru Tamaki
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
Takayuki Nakayama
 
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさJSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
0207sukipio
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
harmonylab
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
Matsushita Laboratory
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
chiefujita1
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
CRI Japan, Inc.
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
t m
 

Recently uploaded (8)

論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
 
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさJSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
JSAI_類似画像マッチングによる器への印象付与手法の妥当性検証_ver.3_高橋りさ
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
 

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

  • 1. Copyright©2018 NTT Corp. All Rights Reserved. アーキテクチャから理解する PostgreSQLのレプリケーション NTT OSSセンタ 澤田 雅彦
  • 2. 2Copyright©2018 NTT Corp. All Rights Reserved. 自己紹介 澤田 雅彦 @sawada_masahiko NTT OSSセンタ PostgreSQLの技術サポート PostgreSQLの本体開発 PostgreSQLの周辺ツール開発  pg_repack – オンラインメンテナンスツール  pg_bigm – 2-gram全文検索モジュール
  • 3. 3Copyright©2018 NTT Corp. All Rights Reserved. • PostgreSQLのアーキテクチャについて簡単におさらい • Replicationについて • Streaming Replicationを理解する • 設定、構築、運用など • Logical Replicationを理解する • 設定、構築、運用など Index
  • 4. 4Copyright©2018 NTT Corp. All Rights Reserved. PostgreSQLのアーキテクチャ
  • 5. 5Copyright©2018 NTT Corp. All Rights Reserved. • プロセスモデル • 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
  • 6. 6Copyright©2018 NTT Corp. All Rights Reserved. Replicationについて
  • 7. 7Copyright©2018 NTT Corp. All Rights Reserved. • データを複数のマシンにコピーすること • 一つに障害が起きても動き続けられる • データのコピーを各ユーザに近い場所に配置することも可能 • データのコピーに対して読み込みクエリを発行することも可能 • マスタとスタンバイ • プライマリとスレーブ、リーダーとフォロワーなど呼び方は色々 • レプリケーショントポロジー データベース・レプリケーションとは?
  • 8. 8Copyright©2018 NTT Corp. All Rights Reserved. 何を複製(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 はこれ↓
  • 9. 9Copyright©2018 NTT Corp. All Rights Reserved. Streaming Replicationを理解する
  • 10. 10Copyright©2018 NTT Corp. All Rights Reserved. Streaming Replicationの基本的なアーキテクチャ WAL WAL Write WAL Send WAL COMMIT Write WAL OK Apply WAL • マスタはWALを送り続ける • スタンバイはリカバリをし続ける • 物理的に同じデータベースを複製する 一台のときの 処理 レプリケーショ ン構成での処理
  • 11. 11Copyright©2018 NTT Corp. All Rights Reserved. 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
  • 12. 12Copyright©2018 NTT Corp. All Rights Reserved. • WALを複製+スタンバイでリカバリすることでDBを複製する • 物理的に全く同じDBが出来上がる • スタンバイではDBを変更するような操作はできない(Read-Only) • メジャーバージョンを跨いだレプリケーションはできない • 1:Nのレプリケーションのみ可能 • トランザクションの途中でも、生成されたWALは随時複製される (”Streaming” Replication) • ロールバックされた変更情報も複製される • スタンバイはマスタに昇格(Promote)可能 • プロセス間のデータ連携は共有メモリやWALファイルで行う Streaming Replication - 特徴まとめ
  • 13. 13Copyright©2018 NTT Corp. All Rights Reserved. 使い方(設定、設計編)
  • 14. 14Copyright©2018 NTT Corp. All Rights Reserved. • 最低限必要なパラメータ(マスタ側) • 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 など(たくさんある) 使い方(設定編)
  • 15. 15Copyright©2018 NTT Corp. All Rights Reserved. • 非同期レプリケーション • スタンバイでのWAL書き込みを待たない • 同期レプリケーション • スタンバイでのWAL書き込みを待つ 同期、非同期の選択 性 能 信 頼 性
  • 16. 16Copyright©2018 NTT Corp. All Rights Reserved. 非同期レプリケーション • スタンバイにWALを非同期的に送る • COMMITはスタンバイでのWAL書き込みを待たない • マスタでCOMMIT済みデータは、スタンバイには存在しないかもしれない data change OK Time Client Master Standby OKdata change
  • 17. 17Copyright©2018 NTT Corp. All Rights Reserved. 非同期レプリケーション OK Time Client Master Standby old value data change read data Become a new master • スタンバイにWALを非同期的に送る • COMMITはスタンバイでのWAL書き込みを待たない • マスタでCOMMIT済みデータは、スタンバイには存在しないかもしれない
  • 18. 18Copyright©2018 NTT Corp. All Rights Reserved. 同期レプリケーション • COMMITはスタンバイでのWAL書き込みを待つ • マスタでCOMMIT済み(COMMIT OKとなったデータ)は、マスタ、スタンバ イの両方に存在することを保証する data change OK OK Time Client Master Standby waiting for standby flush data change
  • 19. 19Copyright©2018 NTT Corp. All Rights Reserved. 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
  • 20. 20Copyright©2018 NTT Corp. All Rights Reserved. • スタンバイがスタンバイを持てる • カスケード・スタンバイは非同期レプリケーションのみ使用可能 カスケード構成 Master Standby (sync) Standbys (async) Cascading Standbys (async) Cascading Standbys (async)
  • 21. 21Copyright©2018 NTT Corp. All Rights Reserved. • 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)
  • 22. 22Copyright©2018 NTT Corp. All Rights Reserved. • スタンバイでのリカバリを”あえて”遅らせる • オペミス起因のデータ損失等に対応できる • recovery_min_apply_delayで遅延時間を指定可能 • 「WALは受け取っているがリカバリはしてない」という状態になる • synchronous_commit = remote_applyを使用しているときは要注意 • 遅らせた分がそのままトランザクション処理の遅延に影響する 遅延レプリケーション
  • 23. 23Copyright©2018 NTT Corp. All Rights Reserved. 使い方(構築編)
  • 24. 24Copyright©2018 NTT Corp. All Rights Reserved. 必要なのは以下の3ステップ 1. マスタサーバから物理バックアップを取得 • DB停止 → 物理コピー → DB起動 • pg_start_backup関数 → 物理コピー → pg_stop_backup関数 • pg_basebackup • ※論理バックアップは利用できない 2. スタンバイサーバの設定 3. スタンバイサーバを起動 使い方(構築編)
  • 25. 25Copyright©2018 NTT Corp. All Rights Reserved. • 設定必須なパラメータ • standby_mode = on • primary_conninfo = ‘マスタサーバへの接続情報’ • primary_conninfo = ‘host=xxx port=yyy dbname=zzz user=xxx’ • 必要に応じて • primary_sloname • recovery_target_timeline • trigger_file スタンバイサーバの設定
  • 26. 26Copyright©2018 NTT Corp. All Rights Reserved. 使い方(監視編)
  • 27. 27Copyright©2018 NTT Corp. All Rights Reserved. =# SELECT application_name, sent_lsn, write_lsn, flush_lsn, replay_lsn, write_lag, flush_lag, replay_lag, sync_state, state FROM pg_stat_replication ; -[ RECORD 1 ]----+---------------- application_name | node1 sent_lsn | 0/46349B8 write_lsn | 0/46349B8 flush_lsn | 0/46349B8 replay_lsn | 0/46349B8 write_lag | 00:00:00.010832 flush_lag | 00:00:00.017551 replay_lag | 00:00:00.21462 sync_state | sync state | streaming -[ RECORD 2 ]----+---------------- application_name | node2 sent_lsn | 0/46349B8 write_lsn | 0/46349B8 flush_lsn | 0/46349B8 replay_lsn | 0/46349B8 : マスタ側からの監視 LSNで送信状況、受信状況を 確認(バイト数でラグが確認でき る) レプリケーション遅延を時間で表 示(v10~)
  • 28. 28Copyright©2018 NTT Corp. All Rights Reserved. =# 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 スタンバイ側からの監視
  • 29. 29Copyright©2018 NTT Corp. All Rights Reserved. 使い方(参照負荷分散)
  • 30. 30Copyright©2018 NTT Corp. All Rights Reserved. • Streaming Replicationで参照負荷分散は可能 • pgpool-IIやPgBouncerを利用して振り分ける事が多い • ホットスタンバイで使用する際に注意すべき点は、以下の3つ • 参照結果の整合性 • レプリケーション競合 • マスタでのデータ肥大化 ホットスタンバイ(参照負荷分散)
  • 31. 31Copyright©2018 NTT Corp. All Rights Reserved. • 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
  • 32. 32Copyright©2018 NTT Corp. All Rights Reserved. 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が書き込み+リカバリされる (=ユーザに変更結果が見えるようになるまで)まで待つ
  • 33. 33Copyright©2018 NTT Corp. All Rights Reserved. • 何が競合するか? • クエリ処理とリカバリ • スタンバイでの参照 vs その参照しているデータの物理削除 (をするWALのリカバリ) • スタンバイでの参照 vs その参照しているテーブルへの排他ロック (を取得するWALのリカバリ) • スタンバイでの参照 vs その参照しているデータベースの削除 (をするWALのリカバリ) レプリケーション競合
  • 34. 34Copyright©2018 NTT Corp. All Rights Reserved. • マスタでパラメータを設定することで、物理削除起因のレプリケーション競合を防ぐ ことができる • マスタ側で設定 • vacuum_defer_cleanup_age • 物理削除のタイミングを遅らせる • スタンバイ側で設定 • hot_standby_feedback • スタンバイの活動状況をマスタに通知する • スタンバイが参照してる可能性のあるデータの物理削除をしないようにする • スタンバイでのロングトランザクションに注意 レプリケーション競合を防ぐ
  • 35. 35Copyright©2018 NTT Corp. All Rights Reserved. • リカバリを優先したい! • レプリケーション遅延をなるべく起こしたくない • スタンバイのWAL領域溢れを防ぎたい • クエリ処理を優先したい! • スタンバイで分析系SQLを実行したい • スタンバイで論理バックアップを取得したい • max_standby_streaming_delayで設定する • -1 : クエリが完了するまで待つ(クエリ優先) • >= 0 : 設定値以上たったらクエリをキャンセル(リカバリ優先) クエリ処理を優先する?リカバリを優先する?
  • 36. 36Copyright©2018 NTT Corp. All Rights Reserved. • 遅延するとスタンバイで見えるデータが古い • かつ、レプリケーションが継続できなくなる レプリケーション遅延 -- 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)
  • 37. 37Copyright©2018 NTT Corp. All Rights Reserved. • 必要な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が生成されたらどうする? レプリケーション遅延の影響
  • 38. 38Copyright©2018 NTT Corp. All Rights Reserved. • スタンバイが必要としてるWALを”絶対に”削除しない • 設定方法 • マスタ側でレプリケーションスロット作成 • pg_physical_replication_slot関数 • スタンバイ側でレプリケーションスロットを使うように設定 • primary_slot_name(recovery.conf内) • スタンバイが受信するまでWALを持ち続けるので、ディスクフルに 注意 • うっかり消し忘れる事が多い レプリケーションスロット
  • 39. 39Copyright©2018 NTT Corp. All Rights Reserved. • コミュニティ提供の自動昇格機能がない! • PG-REX、pgpool-II、repmgr、PAF等を使う事が多い • マスタサーバを復旧し、起動。または、スタンバイサーバを昇格 • 昇格(Promote)方法は2つ • pg_ctl promote • trigger_file マスタサーバがダウン・・・どうする?
  • 40. 40Copyright©2018 NTT Corp. All Rights Reserved. • マスタサーバ回復後、新しいスタンバイとして利用したい • 更にその後、マスタとスタンバイを元の関係に戻したい(スイッチバック)と きもある • 旧マスタはそのままは使えない事に注意 • 同期レプリケーションの場合でも使えないことに注意 旧マスタサーバの再利用 マスタ スタンバイ 最初の マスタサーバ 最初の スタンバイサーバ ここからは 新しいマスタサーバ サーバ間で物理的に異 なる可能性がある部分
  • 41. 41Copyright©2018 NTT Corp. All Rights Reserved. • 旧マスタサーバ再利用のための方法は2つ 1. 新しいマスタサーバのバックアップを取り直して、スタンバ イを再構築 2. pg_rewindを使う ではどうするか?
  • 42. 42Copyright©2018 NTT Corp. All Rights Reserved. • 新しいマスタから物理バックアップを再取得する • 再取得したバックアップを使ってスタンバイとして起動 • スイッチバック(マスタ正常終了の後に切り替え)する時は、バックアップは必要ない • データベースが大きいと時間が掛かる 1. バックアップを取り直す Master Standby New Master Replication Replication full backup Master MasterStandby
  • 43. 43Copyright©2018 NTT Corp. All Rights Reserved. • 旧マスタの状態を巻き戻して(rewind)して、再利用する • サーバ間の差分を転送するだけで良いので短い時間で済む • wal_log_hintsもしくはchecksumの設定が必要 2. pg_rewindを使う(v9.5 ~) Master Standby New Master Replication Replication send only deltas Master MasterStandby pg_rewind
  • 44. 44Copyright©2018 NTT Corp. All Rights Reserved. • 同期レプリケーションの場合、マスタサーバでの更新系トランザ クションは止まる • タイムアウト等は用意されていない • クエリのキャンセルは可能 • 同期待ちで止まっているプロセスは、ps コマンドでプロセスを見ると「XXX waiint for XXX/XXX」となっている • 外部ツールで検知して、非同期レプリケーションに変更する必要がある • synchronous_standby_namesを空にして、設定ファイルの再読込 スタンバイサーバがダウンしたらどうなる?
  • 45. 45Copyright©2018 NTT Corp. All Rights Reserved. Logical Replicationを理解する
  • 46. 46Copyright©2018 NTT Corp. All Rights Reserved. • データベースの一部を複製する • 複数ソースからの受信 • メジャーバージョンが異なるPostgreSQL間でのレプリケ ーション • Row-based • 初期データコピー • Publication / Subscription Logical Replication
  • 47. 47Copyright©2018 NTT Corp. All Rights Reserved. • 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 ユースケース
  • 48. 48Copyright©2018 NTT Corp. All Rights Reserved. • 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)
  • 49. 49Copyright©2018 NTT Corp. All Rights Reserved. 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がデータを受信して、テーブルに反映
  • 50. 50Copyright©2018 NTT Corp. All Rights Reserved. より詳細に 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 :
  • 51. 51Copyright©2018 NTT Corp. All Rights Reserved. • Logical Decoding(WALをデコードする機能)がベース • プラグインの書き方次第では、PostgreSQL→他DBMSというレプリケーションも可能 • Logical Replicationもプラグインの一つ • 論理的な変更情報(行単位)を送信している • RAND()とかCURRENT_TIMESTAMPとかも上流、下流で結果が異なる心配はない • 1:N、N:1、カスケードの構成が可能 • 双方向レプリケーションはテーブルが異なれば可能 • COMMITレコードをデコードした時に変更情報を送信する • COMMITされたトランザクション情報しか複製されない • テーブルのフィルタリングは上流で行う • 上流、下流で必ずしも同じテーブル定義である必要はない • 列数が異なっていてもOK • 下流のテーブルの列が足りないのはNG • 列のデータ型が異なっていてもOK • 変更データの転送はテキスト形式 アーキテクチャ特徴まとめ
  • 52. 52Copyright©2018 NTT Corp. All Rights Reserved. 使い方(設定、設計編)
  • 53. 53Copyright©2018 NTT Corp. All Rights Reserved. • 設定必須パラメータ • 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 使い方(設定編)
  • 54. 54Copyright©2018 NTT Corp. All Rights Reserved. • 基本的にはStreaming Replicationと同じ様に設定できる • Publisherのsynchronous_standby_namesにSubscriberのSubscription名 を入れる • synchronous_commitも同じように利用可能 • 同期レプリケーションを使うときの注意 • 同期、非同期の選択はサーバ単位 • テーブルの変更情報を受け取らないSubscriberからのACKも待つ • Publisherの同期COMMIT設定はONにしておく • クエリのレイテンシが大きくなりやすい • PostgreSQL 11で改善するかも 同期、非同期の選択
  • 55. 55Copyright©2018 NTT Corp. All Rights Reserved. 使い方(構築編)
  • 56. 56Copyright©2018 NTT Corp. All Rights Reserved. • Publicationに複数テーブルを設定する • Subscriber(受信側)は受信するPublicationを選択する Publication / Subscription Table A Table B Table C Table D Subscriber Subscriber pubA pubBPublisher
  • 57. 57Copyright©2018 NTT Corp. All Rights Reserved. -- 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)
  • 58. 58Copyright©2018 NTT Corp. All Rights Reserved. -- 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);
  • 59. 59Copyright©2018 NTT Corp. All Rights Reserved. • Streaming Replicationと同じ!! マスタ側からの監視方法
  • 60. 60Copyright©2018 NTT Corp. All Rights Reserved. 使い方(監視編)
  • 61. 61Copyright©2018 NTT Corp. All Rights Reserved. # SELECT * FROM pg_stat_subscription ; -[ RECORD 1 ]---------+------------------------------ subid | 16387 subname | hoge_sub pid | 57387 relid | received_lsn | 0/164A120 last_msg_send_time | 2018-01-23 10:40:56.95926+09 last_msg_receipt_time | 2018-01-23 10:40:56.959331+09 latest_end_lsn | 0/164A120 latest_end_time | 2018-01-23 10:40:56.95926+09 スタンバイ側からの監視方法
  • 62. 62Copyright©2018 NTT Corp. All Rights Reserved. • 同一データに対する変更は「後勝ち方式」 • エラーが発生した場合は、成功するまでずっと繰り返す • 手動で解決する方法はある(pg_replication_origin_advance関数) • 競合をモニタリングする方法がない… レプリケーション競合
  • 63. 63Copyright©2018 NTT Corp. All Rights Reserved. • INSERT/DELETE/UPDATEのみ対応 • DDL、シーケンス等は未対応 • レプリケーション・ラグが発生しやすい • 大きな変更を1トランザクションで実行する時は注意 • 同期レプリケーションの場合は特に注意 • 同期レプリケーションは使えるがDBインスタンス単位 • テーブル、Subscription、Publication単位での指定はできない • ハングするケースがいくつかある • 同時にCREATE SUBSCRIPTION ... WITH (create_slot = true) • 同時にALTER SUBSCRIPTION REFRESH PUBLICATION WITH (copy_data = ture) • など 現在(v10)の制約のまとめ
  • 64. 64Copyright©2018 NTT Corp. All Rights Reserved. まとめ
  • 65. 65Copyright©2018 NTT Corp. All Rights Reserved. • Streaming Replicationは10歳 • 利用事例多数 • 機能、周辺ツールが揃っている • Logical Replicationは0歳 • ポテンシャルは非常に高い • まだいくつか制約、使いづらい点がある • Streaming Replicationで使っている機能を利用することで、ユー ザにも使いやすい+コードを再利用できる まとめ
  • 66. 66Copyright©2018 NTT Corp. All Rights Reserved. THANK YOU !!
  • 67. 67Copyright©2018 NTT Corp. All Rights Reserved. 参考資料
  • 68. 68Copyright©2018 NTT Corp. All Rights Reserved. Logical Replication開発の歴史 https://blog.2ndquadrant.com/bdr-history-and-future/
  • 69. 69Copyright©2018 NTT Corp. All Rights Reserved. • データベースのベースバックアップ+WALを使って、任意の時点(~障害 直前の状態)にデータを復旧することが可能 PITR (Point In Time Recovery) WAL ② サーバダウンDB バッ クア ップ WAL ① CHECKPOINT ② WAL ① ①まで復旧:バックアップ+WAL① ②まで復旧:現在のDB+WAL② または、 バックアップ+WAL①、②