2017年度WG3活動報告書レプリケーション調査編

PostgreSQLエンタープライズ・コンソーシアム技術部会 WG#3

WG3活動報告書

レプリケーション調査編

2
8
9
10
10
10
10
10
11
12
12
12
12
12
12
12
12
13
13
13
13
13
14
14
14
14
15
15
15
17
18
18
18
23
23
25
26
27
30
30
30
30
31
31
31
32
34
34
36
36
36
36
37
37
38
38
38
目次目次
目次
1. 改訂履歴
2. ライセンス
3. はじめに
3.1. PostgreSQLエンタープライズコンソーシアムとWG3について
3.2. 本資料の概要と目的
3.3. 本資料の構成
3.4. 想定読者
3.5. 参考文献
4. PostgreSQLにおけるレプリケーション
4.1. レプリケーションの目的
4.1.1. 可用性の向上
4.1.2. 性能向上
4.1.2.1. 参照の同期
4.1.2.2. 更新による一貫性の維持
4.2. 代表的なレプリケーションの手法
4.2.1. シングルマスタ
4.2.1.1. ストレージレプリケーション
4.2.1.2. トリガベースレプリケーション
4.2.1.3. クエリベースレプリケーション
4.2.1.4. ストリーミングレプリケーション
4.2.1.5. ロジカルレプリケーション
4.2.2. マルチマスタ
4.2.2.1. Bi-Directional Replication
4.2.2.2. Bucardo
4.3. 参考文献
5. ストリーミングレプリケーション
5.1. はじめに
5.1.1. PostgreSQLのストリーミングレプリケーションの特徴
5.1.2. 検証を実施したSR構成
5.2. SR環境構築時の設定項目、推奨値
5.2.1. SRにおける目的別の設定
5.2.2. SRの基本設定手順（2ノード）
5.2.3. スレーブの追加
5.2.4. アーカイブモード運用
5.2.5. レプリケーションスロット
5.2.6. 【参考情報】同期モードにおけるパフォーマンスへの影響
5.2.7. 遅延レプリケーション
5.2.8. WAL圧縮
5.3. SR環境の監視
5.3.1. レプリケーション操作ログの監視
5.3.1.1. 調査の目的
5.3.1.2. 調査結果
5.3.1.3. 調査結果
5.3.2. 同期状況の監視
5.3.2.1. 同期遅延監視
5.3.3. 更新、読み取りの監視
5.3.3.1. 更新・読取監視
5.3.4. スプリットブレインの監視
5.3.4.1. スプリットブレインの定義と調査の目的
5.3.4.2. 監視方法
5.3.4.3. サーバログの監視
5.3.4.4. pg_controldataコマンドによる監視
5.3.4.5. pg_control_recoveryコマンドによる監視
5.3.4.6. pg_is_in_recovery関数による監視
5.4. SR環境の障害時運用
5.4.1. 本文書における用語の定義
PostgreSQL Enterprise Consortium
Page 2 of 285

38
38
39
39
40
41
42
46
47
50
51
52
54
59
60
63
65
65
65
66
67
67
72
76
83
83
87
91
91
94
97
104
106
106
109
109
109
109
109
110
110
111
111
111
111
112
112
117
117
117
117
117
119
119
119
119
120
123
123
5.4.1.1. フェイルオーバ
5.4.1.2. フェイルバック
5.4.1.3. スイッチオーバ
5.4.1.4. スイッチバック
5.4.2. 障害時運用手順（2ノード構成）
5.4.2.1. フェイルオーバ
5.4.2.2. フェイルバック
5.4.2.3. スイッチオーバ
5.4.2.4. スイッチバック
5.4.2.5. スレーブ障害による対処
5.4.3. 障害時運用手順（複数スレーブ）
5.4.3.1. フェイルオーバ(複数スレーブ)
5.4.3.2. フェイルバック(複数スレーブ)
5.4.3.3. スイッチオーバ(複数スレーブ)
5.4.3.4. スイッチバック(複数スレーブ)
5.4.3.5. スレーブ障害による対処(複数スレーブ)
5.4.4. 障害時運用手順（カスケード構成）
5.4.4.1. フェイルオーバ
5.4.4.2. 同期スレーブへのフェイルオーバ
5.4.4.3. 非同期スレーブへのフェイルオーバ
5.4.4.4. フェイルバック
5.4.4.5. 旧マスタを同期モードスレーブとしてフェイルバック
5.4.4.6. 旧マスタをインスタンス障害からフェイルバック
5.4.4.7. 旧マスタ/旧スレーブ1をフェイルバック
5.4.4.8. スイッチオーバ
5.4.4.9. 同期スレーブへのスイッチオーバ
5.4.4.10. 非同期スレーブへのスイッチオーバ
5.4.4.11. スイッチバック
5.4.4.12. 同期モードスレーブからマスタへのスイッチバック
5.4.4.13. 非同期モードスレーブからマスタへのスイッチバック
5.4.4.14. pg_rewindを使用したスイッチバック
5.4.4.15. スレーブ障害による対処
5.5. まとめ
5.5.1. SR機能拡張の歴史
6. ロジカルレプリケーション
6.1. ロジカルレプリケーションの概要
6.1.1. 概要
6.1.2. 特徴
6.1.3. アーキテクチャ
6.1.4. ユースケース
6.1.5. 制限事項
6.2. ロジカルレプリケーションの設定
6.2.1. データベース単位の設定
6.2.1.1. 検証目的
6.2.1.2. 検証内容
6.2.1.3. 検証環境
6.2.1.4. 検証手順
6.2.2. テーブル単位の設定
6.2.2.1. 検証目的
6.2.2.2. 検証内容
6.2.2.3. 検証環境
6.2.2.4. 検証手順
6.2.3. レプリケーション対象とする更新処理の限定
6.2.3.1. 検証目的
6.2.3.2. 検証内容
6.2.3.3. 検証環境
6.2.3.4. 検証手順
6.2.4. 設定するパラメータ
6.2.4.1. 実行時パラメータ
PostgreSQL Enterprise Consortium
Page 3 of 285

124
129
130
130
130
130
130
131
134
134
135
135
135
141
141
141
141
142
150
150
150
150
151
156
156
156
156
156
169
169
169
170
170
172
174
174
177
178
178
179
185
187
189
191
191
192
194
195
197
198
199
200
201
202
203
204
204
205
206
6.2.4.2. 実行時パラメータと起動プロセスの関係
6.2.4.3. 考察
6.3. ロジカルレプリケーションの応用
6.3.1. primary keyが定義されていないテーブルのレプリケーション設定
6.3.1.1. 検証目的
6.3.1.2. 検証内容
6.3.1.3. 検証環境
6.3.1.4. 検証手順
6.3.2. 同期レプリケーション
6.3.2.1. 検証目的
6.3.2.2. 検証内容
6.3.2.3. 検証環境
6.3.2.4. 検証手順
6.3.3. 複数サブスクリプション
6.3.3.1. 検証目的
6.3.3.2. 検証内容
6.3.3.3. 検証環境
6.3.3.4. 検証手順
6.3.4. カスケード構成
6.3.4.1. 検証目的
6.3.4.2. 検証内容
6.3.4.3. 検証環境
6.3.4.4. 検証手順
6.3.5. パーティショニングとの組み合わせ
6.3.5.1. 検証構成
6.3.5.2. 組み合わせた場合の利点
6.3.5.3. 検証内容
6.3.5.4. 検証結果
6.4. ロジカルレプリケーションの運用
6.4.1. 監視
6.4.1.1. 前提とする環境
6.4.1.2. ロジカルレプリケーションの設定
6.4.1.2.1. Publisherで確認できる情報
6.4.1.2.2. Subscriberで確認できる情報
6.4.1.3. ロジカルレプリケーションの稼働状態
6.4.1.3.1. Publisherで確認できる情報
6.4.1.3.2. Subscriberで確認できる情報
6.4.2. 障害時の動作確認
6.4.2.1. 前提とする環境
6.4.2.2. 障害ケース1 ロジカルレプリケーション関連プロセスの異常終了
6.4.2.3. 障害ケース2 Publisherのノード停止
6.4.2.4. 障害ケース3 Subscriberのノード停止
6.4.2.5. 障害ケース4 Publisher/Subscriber間のネットワーク断絶
6.4.3. レプリケーション対象テーブルの追加/削除
6.4.3.1. 前提とする環境
6.4.3.2. レプリケーション対象のテーブルを追加する手順(データベース単位のPublication)
6.4.3.3. レプリケーション対象のテーブルを追加する手順(テーブル単位のPublication)
6.4.3.4. レプリケーション対象のテーブルを変更する手順
6.4.3.5. レプリケーション対象のテーブルにインデックスを追加する手順
6.4.4. レプリケーション対象外となる操作、オブジェクト
6.4.4.1. 前提とする環境
6.4.4.2. TRUNCATE
6.4.4.3. シーケンス
6.4.5. 更新競合時の動作
6.4.5.1. 前提とする環境
6.4.5.2. 更新時の競合発生と解消
6.4.5.2.1. 主キー違反/一意キー違反
6.4.5.2.2. CHECK制約違反
6.4.5.2.3. 更新データが存在しない
PostgreSQL Enterprise Consortium
Page 4 of 285

207
207
209
211
212
213
214
214
215
215
215
215
216
217
217
218
218
221
221
222
222
230
231
232
232
232
232
232
232
233
233
234
234
234
235
235
235
235
235
236
241
241
241
241
241
241
241
243
247
247
247
247
247
249
250
250
250
250
250
6.4.5.2.4. 削除データが存在しない
6.4.5.2.5. テーブルが存在しない
6.4.5.2.6. 一部の列が存在しない
6.4.5.2.7. データ型変換エラー
6.4.5.2.8. テーブルのロック
6.4.5.2.9. 更新対象レコードのロック
6.4.5.3. 初期データ同期時の競合発生と解消
6.4.5.3.1. 主キー違反/一意キー違反
6.4.5.3.2. CHECK制約違反
6.4.5.3.3. 更新データが存在しない
6.4.5.3.4. 削除データが存在しない
6.4.5.3.5. テーブルが存在しない
6.4.5.3.6. 一部の列が存在しない
6.4.5.3.7. データ型変換エラー
6.4.5.3.8. テーブルのロック
6.4.5.3.9. 更新対象レコードのロック
6.4.5.4. WALのスキップによる競合の解消
6.4.6. ストリーミングレプリケーションとの併用
6.4.6.1. 前提とする環境
6.4.6.2. ストリーミングレプリケーションを併用する環境の構築手順
6.4.6.3. ストリーミングレプリケーションを併用する環境で障害が発生した場合の運用手順
6.4.6.4. 考察
6.5. まとめ
7. Bi-Directional Replication (BDR)
7.1. はじめに
7.1.1. BDRの特徴
7.1.1.1. BDRとは
7.1.1.2. ユースケース
7.1.1.3. メカニズム
7.1.1.4. 整合性
7.1.1.5. シーケンス
7.1.1.6. 比較表
7.1.1.7. サポート
7.2. 調査、検証の目的
7.3. 調査、検証の前提
7.4. BDR環境構築時の設定と設定手順
7.4.1. BDR環境の設定手順
7.4.1.1. 概要
7.4.1.2. 対象試験サーバ
7.4.1.3. 事前確認
7.5. BDR動作検証
7.5.1. ノードの追加・切り離し
7.5.1.1. 検証の目的
7.5.1.2. 検証内容
7.5.1.3. 検証環境
7.5.1.4. 検証手順
7.5.1.4.1. ノード切り離し
7.5.1.4.2. ノード追加
7.5.1.5. 検証結果
7.5.2. グローバルシーケンス設定
7.5.2.1. 検証の目的
7.5.2.2. 検証環境
7.5.2.3. 検証手順
7.5.2.4. 検証結果
7.5.3. 選択的レプリケーション
7.5.3.1. 検証目的
7.5.3.2. 検証内容
7.5.3.3. 検証環境
7.5.3.4. 検証手順
PostgreSQL Enterprise Consortium
Page 5 of 285

254
254
254
254
255
255
256
264
265
268
269
270
272
272
272
272
272
272
272
275
278
278
278
278
278
278
279
279
281
282
282
282
282
283
284
285
7.5.3.5. 検証結果
7.5.4. 更新処理競合時の動作
7.5.4.1. 検証目的
7.5.4.2. 検証内容
7.5.4.3. 検証環境
7.5.4.4. 検証手順
7.5.4.4.1. PRIMARY KEYまたはUNIQUE制約
7.5.4.4.2. 外部キー制約
7.5.4.4.3. 排他制約
7.5.4.4.4. グローバルなデータ
7.5.4.4.5. ロックの競合とデッドロックの中断
7.5.4.4.6. その他
7.5.4.5. 検証結果
7.5.5. ノード障害と復旧
7.5.5.1. 検証の目的
7.5.5.2. 検証内容
7.5.5.3. 検証環境
7.5.5.4. 検証手順
7.5.5.4.1. ノード障害
7.5.5.4.2. ノード復旧
7.5.5.5. 検証結果
7.5.5.6. 備考
7.6. BDR性能検証
7.6.1. 更新性能検証結果
7.6.1.1. 検証目的
7.6.1.1.1. 検証内容
7.6.1.1.2. 検証環境
7.6.1.1.3. 検証手順
7.6.1.1.4. 検証結果
7.7. まとめ
7.7.1. BDR検証まとめ
7.8. 参考文献
7.8.1. 関数一覧
7.8.2. システムカタログ一覧
8. まとめ
9. 著者
PostgreSQL Enterprise Consortium
Page 6 of 285

PostgreSQL Enterprise Consortium

Page 7 of 285

1. 改訂履歴改訂履歴

版版改訂日改訂日変更内容変更内容

1.0 2017/06/20 2016年度版として新規作成

- Postg reSQ L 9.6 を対象バージョンとする

2.0 2018/04/11 2017年度版として主に以下の章を加筆修正

- 5章　ストリーミングレプリケーション

　　　　　Po stgreSQ L 10 に対応

　　　　　複数スレーブ対応 (1.0版では2ノードに限定していた)

- 6章　ロジカルレプリケーションの追加

　　　　　Po stgreSQ L 10 の新機能として追加

PostgreSQL Enterprise Consortium

Page 8 of 285

2. ライセンスライセンス

本作品はCC-BYライセンスによって許諾されています。ライセンスの内容を知りたい方はこちらでご確認ください。文書の内容、表記に関する誤り、ご要望、感想等につ

きましては、PGEConsのサイトを通じてお寄せいただきますようお願いいたします。

Eclip seは、Eclip se Fo u n d atio n Incの米国、およびその他の国における商標もしくは登録商標です。

IBM およびDB 2は、世界の多くの国で登録されたIn tern ation al B u sin ess Mach in es Corp oration の商標です。

In tel、インテルおよびXeo n は、米国およびその他の国における In tel Corp ora tion の商標です。

Javaは、O racle Corp o ration 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登

録商標である場合があります。

Lin u x は、Linu s To rvald s 氏の日本およびその他の国における登録商標または商標です。

Red H atおよびSh ad ow man log o は、米国およびその他の国におけるRed Hat,In c.の商標または登録商標です。

Microso ft、W ind o w s Server、SQ L Server、米国 M icro soft Co rp oration の米国及びその他の国における登録商標または商標です。

MySQ Lは、O racle Corp o ration 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または

登録商標である場合があります。

O racleは、O racle Corp o ration 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または

登録商標である場合があります。

Po stg reSQ Lは、PostgreSQ L Commu n ity Association o f Can ad aのカナダにおける登録商標およびその他の国における商標です。

W in d o w s は米国 Micro soft Co rporation の米国およびその他の国における登録商標です。

TPC, TPC B en ch mark, TPC-B, TPC-C, TPC-E, tp mC, TPC-H, TPC-DS, Q p h H は米国Tran saction Pro cessin g Performan ce Cou n cilの商標です。

その他、本資料に記載されている社名及び商品名はそれぞれ各社が商標または登録商標として使用している場合があります。

PostgreSQL Enterprise Consortium

Page 9 of 285

3. はじめにはじめに

3.1. PostgreSQLエンタープライズコンソーシアムとWG3について

Po stg reSQ Lエンタープライズコンソーシアム(略称 PG ECon s)は、Po stg reSQ L本体および各種ツールの情報収集と提供、整備などの活動を通じて、ミッションクリティカル

性の高いエンタープライズ領域へのPo stgreSQ Lの普及を推進することを目的として設立された団体です。

PG ECon s 技術部会ではPostgreSQ Lの普及に資する課題を活動テーマとし、3つのワーキンググループで具体的な活動を行っています。

W G1（新技術検証ワーキンググループ）

W G2（移行ワーキンググループ）

W G3（課題検討ワーキンググループ）

これら3つのワーキンググループのうち、W G1、W G 3については 2015 年度まではそれぞれ、「性能ワーキンググループ」、「設計運用ワーキンググループ」という名称で活動し

てきました。2016年度は、従来の活動領域を広げる意図のもとでそれらを再定義し、上記のような名称に改めました。

これに伴い、W G3ではPostgreSQ Lの設計運用を中心としたさまざまな課題の解決のための調査検証を行い、Postg reSQ Lが広く活用される事を推進していくこととしま

した。

3.2. 本資料の概要と目的

本資料はW G3の2017年度の活動としてPo stgreSQ Lにおけるレプリケーション機能について、調査検討した結果をまとめたものです。

これまでにも、W G3では3度にわたってレプリケーションについて取り上げています。

2013年では、PostgreSQ Lをエンタープライズ領域で活用するにあたって、業務要件とコストとのバランスを考えて可能な限り業務を継続できるように、システムの運用や保

守サービスをPostgreSQ Lで実現する手法についてまとめました [PG ECon s_W G 3_2013] 。報告書では、可用性を向上させるための手段としてレプリケーションを取り上

げています。今年度の報告書では取り上げなかった、ストレージレプリケーション(DRBD)、トリガベースレプリケーション(Slon y-I)についても紹介しています。

2014年度では、可用性のうち「災害対策」に焦点を当て、ITサービス継続を可能とする Po stgreSQ L の構成について調査検討しています [PG ECon s_W G3_2014] 。

ストリーミングレプリケーションを含む代表的な Po stgreSQ L のシステム構成を挙げて、データベースのデータ保全性、サービス継続性の観点から各構成の得失を示しまし

た。

2016年度では、ストリーミングレプリケーションの2ノードにおける運用ノウハウの整理や Postg reSQ L をベースとして双方向レプリケーションがリリースされています。

これらの開発動向と過去の検討結果とを踏まえて、2017年度は PostgreSQ L 10にて機能拡充が進むストリーミングレプリケーションの3ノードにおける運用ノウハウの整

理と、新機能のロジカルレプリケーションの調査を実施しました。

3.3. 本資料の構成

はじめに

Po stg reSQ Lにおけるレプリケーション

レプリケーションの目的

代表的なレプリケーションの手法

ストリーミングレプリケーション

はじめに

SR環境構築時の設定項目、推奨値

SR環境の監視

SR環境の障害時運用

スレーブのアーカイブ保存

まとめ

ロジカルレプリケーション（仮）

はじめに

ロジカルレプリケーション環境構築時の設定項目、推奨値

ロジカルレプリケーション動作検証

ロジカルレプリケーション性能検証

まとめ

B i-Directio n al Replication (B DR )

はじめに

B D R 環境構築時の設定項目、推奨値

B D R 動作検証

B D R 性能検証

まとめ

おわりに

3.4. 想定読者

PostgreSQL Enterprise Consortium

Page 10 of 285

本資料の読者は以下のような知識を有していることを想定しています。

DB M Sを操作してデータベースの構築、保守、運用を行うDB Aの知識

Po stg reSQ Lを利用する上での基礎的な知識

3.5. 参考文献

[PG E Co n s_W G 3_2013] Po stg reSQ L E n terprise Con sortium. 2013年度W G 3活動成果報告書. 2014. h ttps://w w w .pg eco n s.org/w p -

con ten t/u plo ads/PG E Co n s/2013/W G3/pg eco n s-w g3-2013-report.p d f

[PG E Co n s_W G 3_2014] Po stg reSQ L E n terprise Con sortium. 2014年度W G 3活動成果報告書 (可用性編). 2014. h ttps://w w w .pg eco n s.o rg /w p -

con ten t/u plo ads/PG E Co n s/2014/W G3/PG ECon s_2014_W G3_Availab ility.pdf

[Po stg resB D R ] 2n d Q u ad ran t. Po stg res-B D R. Version Po stg res-B DR94 1.0.2, Novemb er 14, 2016. h ttps://2n d qu adra n t.co m/en -

u s/reso u rces/bd r/

PostgreSQL Enterprise Consortium

Page 11 of 285

4. PostgreSQLにおけるレプリケーションにおけるレプリケーション

データベースにおいて、レプリケーションとは複数のデータベースサーバの間で、何らかの一貫性を保ちながら、その内容を複製する手法を指します。Po stg reSQ Lにおいて

は、 9.0 以降の各バージョンの基本機能として、レプリケーションが実現されています。また、PostgreSQ Lに付加するツールによってもレプリケーションが実現されています。

この章では、各種のレプリケーション機能を目的に応じて使い分けるために、機能と特性について簡単に紹介します。

4.1. レプリケーションの目的

レプリケーションによって複数のデータベースサーバの複製を作ることによって、シングルサーバでは対応が難しい要件にも対応できるようになります。それらは、データの冗長性

(複製があること)と複数サーバによる処理の分散の結果です。

4.1.1. 可用性の向上可用性の向上

可用性はITシステムの非機能要件の一つで、システムを継続的に利用可能とすることです [IPA] 。可用性は「継続性」「耐障害性」「災害対策」「回復性」という4つの

要素から構成されますが、レプリケーションによってデータベースサーバを冗長化することで、1つのサーバで故障や災害が生じたときにもレプリカが格納されている残りのサーバ

でサービスを継続することができるるようになります。また、運用上の停止が必要な場合であっても、各サーバを順次停止して作業することで、サービス全体としては停止させ

ないようにできます。

先に挙げた可用性の4つの要素をどの程度満足するかはデータベースの構成によって変わってきます。詳しくは『2013年度W G3活動成果報告書』

[PG E Co n s_W G 3_2013] を参考にしてください。

4.1.2. 性能向上性能向上

レプリケーションによって、同じ情報を格納しているデータベースサーバが複数存在することになります。それらのサーバでアプリケーションからの要求にこたえることが出来れ

ば、システム全体としての性能状況が期待できます(スケールアウト)。アプリケーションからの要求を複数のサーバに分散させる際には、更新(削除・挿入を含む)クエリを特定

の1サーバに集約する「シングルマスタ」構成と、複数のサーバに分散する「マルチマスタ」構成があります。また、参照クエリを複数のサーバに分散させることを参照負荷分散

と呼びます。

レプリケーションクラスタを性能向上に用いる場合、複数のデータをベースを同時に運用することから生じる特有の課題があります。レプリケーション方式を選択する際には、

それらの課題をどの程度解決しているのかについても考慮する必要があります。

4.1.2.1. 参照の同期参照の同期

ある瞬間に同一の参照クエリを異なるサーバに送った時に、まったく同じ結果が返ってくるものと、そうでないものとがあります。同じ結果が得られる場合、サーバは同期してい

る、同期レプリケーションであると言います。

4.1.2.2. 更新による一貫性の維持更新による一貫性の維持

マルチマスタ構成の場合には同期の問題に加えて、更新の衝突と一貫性の維持が問題となります。

更新の衝突

複数のアプリケーションプログラムから同一の更新操作を実行しようとした場合、単一のDB サーバであればどちらかの操作が遅延され、場合によってはエラーとなり

ます。マルチマスタ構成では、レプリケーションの送信側でなされた更新と、そのサーバに直接要求された更新とが衝突した場合に、どちらが優先するのかが問題と

なります。

一貫性の維持

更新が衝突した結果、レプリケーションの送信側と受信側でデータベースの内容が異なってしまうと、レプリケーションによって構成されるクラスタ全体でデータベース

の一貫性が維持されなくなります。この問題を適切に対処する必要があります。

4.2. 代表的なレプリケーションの手法

ここでは、本報告書で取り上げるレプリケーション手法を中心に、PostgreSQ L で利用できる代表的なレプリケーション手法を紹介します。レプリケーションを利用する立場

からは、シングルマスタとマルチマスタに二分することができます。その上で、レプリカを生成する方法に着目して代表例を挙げ、そのメリット・デメリットを説明します。

なお、『2013年度W G3活動成果報告書』 [PG ECon s_W G 3_2013] では可用性向上の観点から、レプリケーションを含めて様々な Po stgreSQ L の構成を取り上げて

いますので、併せてご覧ください。

コミュニティのW ikiページには、Po stg reSQ L上で動作するクラスタソフトウェアについての解説があり、その中にレプリケーションも含まれています [PGW iki_replica] 。ここで

紹介する紹介するレプリケーションソフトウェアについても紹介されています。

4.2.1. シングルマスタシングルマスタ

シングルマスタ構成の場合、レプリカを生成する手法には以下のようなものがあります。

ストレージレプリケーション

トリガベースレプリケーション

クエリベースレプリケーション

ストリーミングレプリケーション

PostgreSQL Enterprise Consortium

Page 12 of 285

ロジカルレプリケーション

4.2.1.1. ストレージレプリケーションストレージレプリケーション

Po stg reSQ Lやその上で動作するツールを介することなく、データを格納するストレージのレベルでデータを複製します。ストレージ装置自体がレプリカを生成するものや、

DRB D [DRB D ] のようにLin u x上で動作するソフトウェアによる実現があります。

メリット

Po stg reSQ Lからは単一のサーバに見えるので、単一サーバと同じように運用できます

デメリット

受信側のサーバはデータベースとしては動作していないので、負荷分散に利用することができません

4.2.1.2. トリガベースレプリケーショントリガベースレプリケーション

Po stg reSQ Lのデータベース内に更新によって起動されるトリガを設定しておき、更新による変分を受信側のサーバに送り出すもの。代表的な製品に Slony-I があります。

以下では Slo n y-I での主なメリット・デメリットを紹介します。

メリット

Po stg reSQ Lのデータベースクラスタに含まれる表全体だけでなく、任意のテーブルについてだけ複製を作成することができる

更新される表については参照負荷分散、それ以外の表については更新負荷分散が可能です

デメリット

比較的オーバヘッドが大きいため、後述のストリーミングレプリケーション方式に比べて、性能が低い傾向があります [pg logical]

4.2.1.3. クエリベースレプリケーションクエリベースレプリケーション

アプリケーションプログラムとD B サーバ(Po stgreSQ L)の間に入るミドルウェアによって、発行されたクエリを複製して複数のDB サーバに送信することで、データベースを複製し

ます。代表的な製品に Pg p o o l-II [Pg p oo l-II] があります。

メリット

複数のD B サーバを用いて負荷分散を実現する際に、参照クエリ・更新クエリともに適切なサーバにクエリが自動的に振り分けられるため、アプリケーショ

ンから見ると単一のDB サーバを利用しているように見える

デメリット

一部のSQ L文に対する挙動が単一のDB サーバとは異なる

4.2.1.4. ストリーミングレプリケーションストリーミングレプリケーション

Po stg reSQ L データベースでは、更新をコミットした際にその結果をクラッシュ等で失わないように更新情報をファイルに書きこむログ先行書込み(W rite Ah ead Logg ing ;

W AL)を用いています。このW ALファイルにはデータベースに対する更新を全て復元することができる情報が含まれていますから、これを他のDB サーバに転送することでデータ

ベースを複製することができる --- これがストリーミングレプリケーションの基本的な考え方です。

ストリーミングレプリケーションは、W ALファイルに書かれた内容をほぼそのまま受信側(スレーブサーバ)に送り出すことで、送信側(マスタサーバ)と物理的に一致するD B を複製

します。

メリット

受信側サーバに送信側サーバと物理的に一致したデータベースを複製することができる

送信側サーバでコミット済みのデータを受信側で確実に書き込み済みにすることができるため、高信頼化に適している

参照負荷分散ができる

デメリット

特定のデータベース、表だけを複製することはできない

メジャーバージョンが異なるPo stgreSQ Lの間では利用できない

受信側サーバのデータベースは更新できない

4.2.1.5. ロジカルレプリケーションロジカルレプリケーション

ロジカルレプリケーションは、PostgreSQ Lバージョン10から標準採用された機能です。ストリーミングレプリケーションが送信側のW ALをそのまま受信側に転送するのに対し

て、ロジカルレプリケーションは送信側でW ALファイルをデコードし、必要な変更内容のみを受信側に送ります。

メリット

送信側サーバの一部の表に対する更新だけを受信側に送ることができる

複数の送信側サーバの出力を1つの受信側サーバで受け取ることができる

PostgreSQL Enterprise Consortium

Page 13 of 285

メジャーバージョンが異なるPo stgreSQ Lの間でも利用できる

受信側サーバのデータベースを更新することができる

デメリット

レプリケーションできないSQ Lやオブジェクトがあり、送信側と受信側で不整合が発生しないよう注意して運用する必要がある

受信側サーバのデータベースを更新した場合、送信側サーバでの更新内容と競合する可能性がある

4.2.2. マルチマスタマルチマスタ

マルチマスタ構成の場合、レプリカを生成する手法には以下のようなものがあります。

B i-Directio n al Replication

B u card o

4.2.2.1. Bi-Directional Replication

2n d Q u adran t社が公開している B i-D irection al Replication は、先に紹介した論理レプリケーションを用いてデータを複製しつつ、複数のサーバでデータの更新を可

能としたものです。主な用途としては地理的に離れた場所にある複数のサーバ間で、データを共有する利用形態を想定しています [Po stg resB D R ] 。

メリット

論理レプリケーションを利用しているため、他の方式によるマルチマスタに比べてオーバヘッドが小さい

デメリット

レプリケーション自体は非同期に行われるため、複数サーバに同時に発行した参照クエリの結果が異なることがあります。

4.2.2.2. Bucardo

B u card o は、トリガベースレプリケーションを使ってデータを複製します [B u card o ] 。そのため、メリット、デメリットはシングルマスタのトリガベースレプリケーションと同じです。

4.3. 参考文献

[IPA] 独立行政法人情報処理推進機構. 非機能要求グレード利用ガイド[活用編]. 2010. h ttp://w w w .ip a.go.jp/files/000026853.p df

[PG W ik i_rep lica] Smith , G .; Grittn er, K.; Pin o , Con rad T.; R ing er, C.; Simon , R . et al. R ep licatio n , Clusterin g , a n d Co n n ectio n Pooling . 2017.

h ttps://w iki.postgresql.org /w iki/R eplication ,_Clu sterin g ,_an d _Con n ectio n _Po oling

[DRB D] LINB IT, In c. h ttp://w w w .d rbd.org /en/

[p g lo g ical] 2n d Q u adra n t. pg logical. h ttps://2n d qu adran t.co m/en/resou rces/pg logical/

[Pg p oo l-II] Pg Po o l G lobal Develop men t G rou p . h ttp://w w w .p g po ol.n et/med iaw ik i/in d ex.ph p /M ain _Page

[B u cardo ] Jensen, G .; Sabin o, G . M . et al. h ttps://b u cardo .o rg/w iki/Main _Page

PostgreSQL Enterprise Consortium

Page 14 of 285

5. ストリーミングレプリケーションストリーミングレプリケーション

5.1. はじめに

5.1.1. PostgreSQLのストリーミングレプリケーションの特徴のストリーミングレプリケーションの特徴

Po stg reSQ Lのストリーミングレプリケーション(以下、SR構成）は以下を目的とした構成です。

可用性の向上

性能向上

以下の特徴があります。

変更履歴が格納されたW ALを操作単位でマスタ側からスレーブ側へ転送することでデータを同期

SR基本構成図（スレーブ１台）

Po stg reSQ L 10 における主な機能を示します。

完全同期方式完全同期方式により、スレーブ活用度の向上が期待できる

同期式はW ALの転送までの保証であり、データ保護が目的。

完全同期式はW ALの適用までの保証であり、データ同期が保証されるため、リアルタイムのデータ参照に期待。

syn ch ro n o u s_co mmitには以下の設定が可能であり、要件に応じて選択。

remote_apply :完全同期。W AL適用まで保証。昇格時の時間短縮と参照負荷分散の拡充が目的。

on 　　　　　:同期。W AL転送（ディスク書き込み）まで保証。データ保護が目的。

remote_w rite :準同期。W AL転送（メモリ書き込み）まで保証。データ保護とパフォーマンスのバランスが目的。

lo ca l　　　　:非同期。ローカルのW AL書き込みまで保証。パフォーマンス優先が目的。

off　　　　　:完全非同期。ローカルのW AL書き込みすら保証しない。最も高パフォーマンスだが非現実的。

以下の図はsyn ch ro n o u s_co mmitの設定による保証時点を示す。

レプリケーションスロットレプリケーションスロットにより、スレーブに必要なW ALをマスタが確保し続ける

スレーブの障害時（ネットワーク不調含む）等にマスタでW ALを保持し切れず、W ALファイルの再利用によりロストする懸念がある。

レプリケーションスロットの登場前はw al_keep _segmen tsパラメータによる調整、またはアーカイブモード運用が必要であった - w al_keep_seg men ts

はW AL数を指定するものであるため、見積もりが困難である。 - アーカイブモードも複数スレーブ構成における不要W ALファイルの判断はやはり困難。

レプリケーションスロットによりW ALファイルの要・不要の判断をシステムに任せる事ができる。

SR構成のW ALファイル管理のためにアーカイブモード運用は必要はなく、過去の時点に復旧する(PITR )要件がある場合に設定する。

PostgreSQL Enterprise Consortium

Page 15 of 285

複数スレーブの場合は、スレーブ毎に専用のレプリケーションスロットを作成する。

複数同期スレーブ構成複数同期スレーブ構成が可能

従来も複数スレーブ構成は可能であったが、同期スレーブはその内の1台までという制限があったがそれが取り払われた。

同期スレーブを任意(ANY)に選択するQ uo rum-based 同期レプリケーションが実装された。

遅延レプリケーション機能遅延レプリケーション機能により、オペレーションミスを反映させない事が可能に

スレーブでの適用を一定時間待機する機能である。マスタでのオペミスが即座にスレーブに伝搬されるのを防ぐのが主な目的。

W ALファイルの転送は遅延なく処理されるため、データ保全(RPO )の観点では問題ない。同期モードで設定する事もできる。

recovery.con f のreco very_min _apply_delayパラメータに遅延時間を設定。

従来からの手法として、PITRを使用してオペミス直前時点を指定してリカバリすることで障害回復を図る方法もある。

巻き戻し機能巻き戻し機能 (p g_rew ind )により、効率の良いSR 再構成が可能に

旧マスタを分岐時点へ巻き戻す事で、新マスタに追い付く事が可能な状態とする機能である。

巻き戻し後、旧マスタに新マスタのW ALを適用（追い付き）する事で旧マスタを新スレーブとして構成。

従来はpg_baseb acku p 等による再作成が必要であった。

大規模データベースでは、大幅な時間短縮が期待できる。

下図に巻き戻し機能のイメージを示す。

PostgreSQL Enterprise Consortium

Page 16 of 285

WAL圧縮機能圧縮機能により、W AL転送の効率を改善

W AL圧縮でサイズを縮小することにより、W AL転送の効率改善が目的。

スレーブを遠隔地に配置する場合に特に有効。

注意点としては、圧縮（マスタ）や解凍（スレーブ）の負荷が発生する。

SR構成の運用上の注意点

死活監視と障害発生時のフェイルオーバはPo stgreSQ Lの機能ではできないため、クラスタソフトを利用する必要があります。商用クラスタソフトが使用される場

合もありますが、オープンソースソフトウェアのPgpo o l-II と呼ばれるクラスタソフトを使用した例も多く報告されています。特に参照負荷分散を行う場合は、

Pgp oo l-IIを使用します。

5.1.2. 検証を実施した検証を実施したSR構成構成

以下のSR構成にて検証を実施しています。

対象バージョンは Po stgreSQ L 10

2017年11月時点の最新版

3ノード構成

1. 複数スレーブ方式（親 - 子1 , 子2）スレーブ2はマスタと繋がっている。

2. カスケード方式（親 - 子 - 孫）スレーブ2はスレーブ1と繋がっている

Po stg reSQ Lの機能に限定

Pgp oo l-II等のクラスタソフトに関するテーマは対象外

PostgreSQL Enterprise Consortium

Page 17 of 285

5.2. SR環境構築時の設定項目、推奨値

5.2.1. SRにおける目的別の設定における目的別の設定

Po stg reSQ LのSR構成には様々な機能があり、対処する障害に応じて適切に設定する必要があります。また各機能は組み合わせることが可能です。

"ストリーミングレプリケーション"を"SR"と表記します。

"レプリケーションスロット"を"スロット"と表記します。

表 5.1 SRの機能

機能機能内容・目的内容・目的注意点・補足注意点・補足

アーカイブW AL

必要なW ALファイルの保持。以下の2種類。

物理バックアップ(PITR )に必要な（フルバックアップ以降

の）W AL。障害発生直前まで復旧や操作ミス時に過去

に戻す機能がある。

SR構成において未転送のW ALを保持する。

アーカイブW ALがディスク領域を圧迫しないように、不要となった

アーカイブW ALの明示的な削除が必要。

SR用途の場合、W ALファイルの要不要の判断が困難であるた

め、現在では後述のレプリケーションスロットの使用が一般的。

SR構成には物理バックアップという側面もあるため、過去に戻す

要件がなければ物理バックアップを取得する必要性は低い。

これらを考慮し、一般的には非アーカイブモード運用でも十分と

考えられる。

レプリケーションスロッ

ト

スレーブに必要なW ALファイルを保持する事によるSR構成の維持。

対応する各スレーブの未転送のW ALを保持する。

スレーブへW ALファイルの転送ができない状態が続くと、W ALファ

イルが溜まり領域を圧迫する。

複数スレーブ構成では、スレーブ毎にスロットの使用/未使用を

選択できる。

スレーブ毎にスロットを作成する必要がある。

遅延レプリケーションスレーブ側のW AL適用を意図して遅らせることで、スレーブを一定

の過去の状態に維持する。操作ミス対策に任意の時点まで巻き

戻せるようにする。

スレーブは常に過去の状態であるため、参照活用には一定の制

限がある。

フェイルオーバ時には遅延分の適用が必要になるため、RTO の

点で難がある。そのため複数スレーブ構成の場合に1スレーブで

構成するのが一般的。

W AL圧縮 Fu ll Page W rite時(チェックポイント後の最初の更新時)に、W AL

ファイルに書き出すフルページイメージを圧縮する。圧縮された

W ALは適用時に解凍される。 W ALサイズを大幅に圧縮できる可

能性があり、転送負荷の低減が期待される。特にディザスタ・リカバ

リ構成で有効と考えられる。

マスタの圧縮時とスレーブの解凍時に通常より余分にCPU 負荷

と時間がかる。

5.2.2. SRの基本設定手順（の基本設定手順（ 2ノード）ノード）

基本的なSR 環境の設定手順を紹介します。尚、マスタとスレーブの両サーバにPo stg reSQ Lはインストール済みであり、マスタ側ではデータベースクラスタを構築しているこ

とを前提としています。

1. 関連パラメータ

SR構成に最低限必要な設定は以下の通りです。スレーブはマスタのベースバックアップから作成されるため、マスタに設定したパラメータは全てスレーブも

同様の値に設定されます。

"ストリーミングレプリケーション"を"SR"と表記します。

"レプリケーションスロット"を"スロット"と表記します。

　　説明の便宜上、以下の設定とします。

表 5.2 構成データ

項目項目内容内容

マスタのIPアドレスおよびサーバ名 192.168.100.101/24　server1

スレーブのIPアドレスおよびサーバ名 192.168.100.102/24　server2

ポート番号 5432

レプリケーション用ユーザ/パスワード repu ser/passw ord

PostgreSQL Enterprise Consortium

Page 18 of 285

表 5.3 SR構成の設定(マスタのp g_h b a.co n f)

設定値設定値内容内容

h ost replication repu ser 192.168.100.101/32 tru st

h ost replication repu ser 192.168.100.102/32 tru st

またはCIDR指定にて

h ost replication repu ser 192.168.102.0/24 trust

SR用ユーザの接続を許可する。

・pg _h b a.con fは両ノード共通の設定となる事から、

　どちらがマスタになっても使用できる設定とする。

・IPアドレスはW AL転送を行うネットワークLANを指定。

　パブリックLAN以外に、ハートビート系LANも有力。

・認証方式は任意だが、passw ord やmd 5ではパスワードファイルにより入力を求

められないようにする。

表 5.4 SRの設定(マスタのpo stg resq l.con f)

パラメータパラメータ設定値設定値内容内容

listen _add resses '0.0.0.0' 接続を受け入れるIPを指定。

再起動で反映。

w al_level replica W ALに書かれる情報量を指定。

SR構成の場合は rep lica に設定。

デフォルトがrep licaであるため変更不要。

再起動で反映。

w al_keep_segmen ts 64 暫定値として、ma x_w al_size/16MBの値を設定。

スロットを使用する場合は設定不要。

リロードで反映。

syn ch ro n o u s_co mmit on 目的に応じて設定する。

remote_apply : 完全同期。W AL適用までを保証。

on : 同期。W AL転送後のディスクへの書き込みまで保証。

remote_w rite : 準同期。W AL転送後のメモリ書き込みまで保証。

lo ca l : 非同期。ローカルへの書き込みまで保証（リモートは保証しない）。

off : 完全非同期。ローカルへの書き込みも保証しない。

同期式におけるスレーブ障害時および復旧時の同期/非同期の切り替えは

syn ch ro n o u s_stan d b y_n amesにて行う。本パラメータは固定。

リロードで反映。

syn ch ro n o u s_stan d b y_n ames ''（非同期） SRの非同期と同期を切り替えに使用。

非同期の場合 : ''

同期の場合 : '*' あるいは特定スレーブのapp licatio n _n ame

リロードで反映。

max_w al_send ers 10 起動するw al sen ders数を指定。

pg _b aseb acku pでW ALストリーミングを指定する場合はその分も考慮

通常はデフォルトの10で問題ない。

再起動で反映。

max_replication _slot 10 レプリケーションスロットを作成可能な最大数

通常はデフォルトの10で問題ない。

再起動で反映。

restart_after_crash off on の場合、インスタンス障害(po stg resプロセスは残存)の場合に、自動的に再起動を行

う。

シングル構成では便利な機能であるが、SR構成では管理が複雑化するため、offに設定

するのが一般的。

リロードで反映。

PostgreSQL Enterprise Consortium

Page 19 of 285

表 5.5 SRの設定(スレーブのpo stg resql.con f)

パラメータパラメータ設定値設定値内容内容

h ot_stan db y on ホットスタンバイとして参照可能な状態で起動する。

スレーブに対しても監視SQ Lを実行できるように通常は有効化する。

デフォルトでon であるため、変更は不要。

h ot_stan db y_feedback on o n の場合、スレーブが現在処理している問い合わせについて、マスタへフィー

ドバックを送る。

通常は有効化する。特にスロットを作成する場合には有効化が必須。

デフォルトはoffであるため、変更が必要。

表 5.6 SRの設定(スレーブのrecovery.co n f)

パラメータパラメータ設定値設定値内容内容

stand b y_mode on スレーブとして起動か、PITRのリカバリ処理かを区別をする設定。

on の場合は、スレーブとして起動する。W ALファイルの最後に達してもリカバリ

を終了せず、マスタへ接続して新W ALセグメント取得を継続。

primary_co n n info 'h o st=server1 po rt= 5432

u ser= repu ser

passw ord = p assw ord

applicatio n _n ame=server2'

マスタへの接続文字列を指定。

h ostはW AL転送を行うLANを指定。2サーバ間の転送のみである事から、

ハートビートLANでも良い。

po rtはPo stg reSQ Lがリスニングしているポート番号(p o rtパラメータ)。

u serはreplication 仮想データベースへ接続できるユーザを指定(ユーザの

replica tion 属性およびpg _h b a.con fの設定)。

passw ord はパスワードが必要な場合に設定。パスワードの記載を避けたい

場合は、~ /.pgpassを使用。

applicatio n _n ameは視認性を高めるのが目的であり必須ではない。ここで

はスレーブ名を指定。

デフォルトで'w al_receiver'。

recovery_targ et_timelin e latest リカバリが作成する個別のタイムラインを指定。

SR構成ではlatestを指定して最新タイムラインを追従。

primary_slot_n ame <スロット名> 当該スレーブ用のスロットを作成している場合は、スロット名を設定。

最新バージョンではスロットを作成するのが一般的。

restore_co mman d アーカイブW ALファイルのリストア（コ

ピー）方法を指定

スロットを使用している場合は設定不要

2. 構築手順

ここでは基本的な2ノード構成における手順を記載します。

表 5.7 SR構成条件

項目項目内容内容

同期方式非同期(syn ch ro n o u s_stan d b y_n ames = '')

レプリケーションスロット使用しない

(1)レプリケーションユーザ作成

マスタサーバでレプリケーション用のユーザを作成します。

postgres=# CREATE ROLE repuser LOGIN REPLICATION PASSWORD 'password';

(2)設定ファイルの変更

マスタで$PGDATA配下のp g_h b a.co n fとpo stg resql.con fを変更します。

pg _h b a.con f

PostgreSQL Enterprise Consortium

Page 20 of 285

レプリケーションユーザがデータベース接続できるようpg _h ba.co n fを次のように設定します。ここでは便宜上、trust認証を

指定しています。 md5認証を指定する場合はパスワードファイル(~ /.p g p ass)を使用して、パスワードの入力が不要となるよ

うに設定します。

$ vi $PGDATA/pg_hba.conf

[pg_hba.conf]

# デフォルトで以下の設定が登録されています。

local replication all trust

host replication all 127.0.0.1/32 trust

host replication all ::1/128 trust

# 以下の様に変更します。

host replication repuser 192.168.100.100/32 trust

host replication repuser 192.168.100.101/32 trust

host replication repuser 192.168.100.102/32 trust

po stg resq l.con f

マスタとして稼働させるため、po stgresq l.con fを次のように設定します。スレーブ側の設定も含めておきます。スレーブ側の

設定は、マスタ側では無視されます。

$ vi $PGDATA/postgresql.conf

[postgresql.conf]

port = 5432 (デフォルト)

listen_addresses = '*'

wal_level = replica (デフォルト)

synchronous_commit = on (デフォルト)

synchronous_standby_names = '' (デフォルト)

max_wal_senders = 10 (デフォルト)

max_replication_slots = 10 (デフォルト)

restart_after_crash = off

hot_standby = on (デフォルト)

hot_standby_feedback = on

パラメータの記述後、設定ファイルの変更を反映するためにPostg reSQ Lを再起動します。

$ pg_ctl restart

(3)pg_basebacku p による物理ファイルのコピー (スレーブ）

スレーブ側でpg_baseb acku p を実行し、スレーブデータベースを構築します。

$ pg_basebackup -h <マスタIP> -p 5432 -U repuser -D $PGDATA --progress --

verbose

なおパスワードファイルはpg_baseb acku p ではコピーされないため、必要に応じてコピーします。

$ scp <マスタIP>:~/.pgpass ~/

(4)reco very.con fの設定（スレーブ）

pg _b aseb acku pで取得したデータベースクラスタの設定を変更し、スレーブとして稼働するようにします。取得先($PGDATA)配下

でrecovery.con fを作成します。なおスレーブに必要なパラメータ設定は(po stg resql.con f)は、マスタ側で設定済みのファイルがコ

ピーされているため、変更不要です。

PostgreSQL Enterprise Consortium

Page 21 of 285

recovery.con f

＄PG D ATA配下にreco very.con fを作成し、以下を記述します。

$ vi $PGDATA/recovery.conf

[recovery.conf]

standby_mode = 'on'

primary_conninfo = 'host=server1 port=5432 user=repuser

password=repuser'

recovery_target_timeline = latest

(5)Po stgreSQ Lの起動（スレーブ）

スレーブのPostgreSQ Lを起動します。

$ pg_ctl start

(6)状況確認（マスタ）

SRが構築されていることを確認します。

[マスタ側で確認]

postgres=# \x

Expanded display is on.

postgres=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 40724

usesysid | 16385

usename | repuser

application_name | walreceiver

client_addr | <スレーブのIP>

client_hostname |

client_port | 48077

backend_start | 2018-01-04 01:30:54.01041+09

backend_xmin |

state | streaming

sent_lsn | 0/3000060

write_lsn | 0/3000060

flush_lsn | 0/3000060

replay_lsn | 0/3000060

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

(7)状況確認（スレーブ）

PostgreSQL Enterprise Consortium

Page 22 of 285

[スレーブ側で確認]

postgres=# \x

Expanded display is on.

postgres=# SELECT * FROM pg_stat_wal_receiver;

-[ RECORD 1 ]---------+--------------------------------------------------

pid | 52484

status | streaming

receive_start_lsn | 0/3000000

receive_start_tli | 1

received_lsn | 0/3000140

received_tli | 1

last_msg_send_time | 2018-01-04 01:35:50.514256+09

last_msg_receipt_time | 2018-01-04 01:18:46.923761+09

latest_end_lsn | 0/3000140

latest_end_time | 2018-01-04 01:33:20.23195+09

slot_name |

conninfo | user=repuser password=******** dbname=replication

host=<マスタのIP> port=<マスタのポート番号>

fallback_application_name=walreceiver

sslmode=disable sslcompression=1

target_session_attrs=any

con n in fo 列は実際には1行で表示されますが、便宜上改行しています。

5.2.3. スレーブの追加スレーブの追加

2ノード構成からスレーブ(server3)を追加する方法は、基本的には前述の手順と同様です。複数スレーブ方式とカスケード方式の違いはserver3側でpg_baseb ack u p

を実行するのは同様で、マスタの指定の違いだけです。カスケード方式では、マスタに負荷をかけないというメリットがあります。

1. pg _b aseb acku pの実行（server3)

（複数スレーブ構成:マスタはsever1）

$ pg_basebackup -h server1 -p 5432 -U repuser -D $PGDATA --progress --

verbose

（カスケード構成　:マスタはserver2）

$ pg_basebackup -h server2 -p 5432 -U repuser -D $PGDATA --progress --

verbose

2. recovery.con fの設定（server3)

recovery.con f

＄PG D ATA配下にreco very.con fを作成します。カスケード方式の場合にはserver2からコピーされたファイルが存在する

ので、それを修正します。 server2の設定とほぼ同様で、異なるのはマスタの指定です。

$ vi $PGDATA/recovery.conf

[recovery.conf]

（複数スレーブ構成:マスタはsever1）

primary_conninfo = 'host=server1 port=5432 user=repuser

password=repuser'

（カスケード構成　:マスタはserver2）

primary_conninfo = 'host=server1 port=5432 user=repuser

password=repuser'

5.2.4. アーカイブモード運用アーカイブモード運用

SR構成においてもアーカイブモード運用は有力です。スレーブが物理バックアップとも言えますのでアーカイブモード運用は必須ではありませんが、以下を目的として構成する

事もあります。

PostgreSQL Enterprise Consortium

Page 23 of 285

・ PITR (Po in t In Time Recovery)にて一定の過去に戻す

　アーカイブモード運用の最大のメリットと言えます。

　類似機能として「遅延レプリケーション」もありますが、PITRの方がより汎用的です。

・アーカイブW ALの保持

　フルバックアップを1日1回取得する場合、アーカイブW ALも1日分（あるいはそれ以上）保持することになります。

　SRの伝搬の遅れが保持時間以内に収まっていれば、SRを継続できます。

　W ALを保持する機能としては、レプリケーションスロットがあります。

　SRを意識してW ALを確保するため、必要なW ALが欠落するリスクはありません。

　ただし伝搬遅延が大きくなりすぎた場合、W AL領域がディスクフルになるリスクがあります。

　アーカイブモード運用の場合は定期的に削除するため、そのリスクは低いと言えます。

1. 関連パラメータ

既存のレプリケーションスロットの設定に加え、次のパラメータを指定します。

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値内容内容

マスタ po stg resq l.con f arch ive_mode o n アーカイブを有効化する。

マスタ po stg resq l.con f arch ive_co mman d cp %p <アーカイブの保存先>/% f アーカイブの実行コマンドを指定する。スクリ

プトを指定する事も可能であるため、複雑な

処理を組み込む事が可能。

スレー

ブ

recovery.con f restore_co mman d 'scp <マスタのユーザ名> @ <マスタのホスト

名> :< マスタのアーカイブ・ディレクトリ> % f

%p'

マスタのアーカイブを取得するコマンドを指定

する。 W AL同期を保証する場合に必要とな

る。ただしレプリケーションスロットを使用する

場合は不要である。

注釈

restore_co mman d にてscpコマンドを使用する場合、スレーブはマスタのPo stgreSQ LのO Sユーザに ssh にてパスワードなしで接続できるよう

になる必要があります。またはアーカイブ・ディレクトリをNFSマウント等、マスタ/スレーブ間で共有可能なパスにする事で、アーカイブの扱いが容

易になります。

障害時スレーブをマスタにする場合に備え、マスタに設定したパラメータはスレーブ側でも事前に有効化することを推奨します。

2. 設定手順

(1)マスタ側のp ostg resql.con fのパラメータを以下のように設定する。

$ vi $PGDATA/postgresql.conf

[postgresql.conf]

archive_mode = on

archive_command = 'cp %p <アーカイブの保存先>/%f'

(2)必要ならばスレーブ側のrecovery.con fのパラメータに以下を追加する。

$ vi $PGDATA/recovery.conf

[recovery.conf]

restore_command = 'scp <マスタのユーザ名>@<マスタのホスト名>:<マスタのアーカイブ・ディレクトリ>%f %p'

(3)マスタ側を再起動し、その後スレーブ側を再起動する。

[マスタ/スレーブの両方で実施]

$ pg_ctl restart

(4)マスタ側で強制的にW ALファイルを切り替え、アーカイブW ALファイルが出力されることを確認する。

PostgreSQL Enterprise Consortium

Page 24 of 285

postgres=# SELECT pg_switch_xlog();

pg_switch_xlog

----------------

0/7017008

(1 row)

$ <アーカイブ・ディレクトリ>

000000010000000000000007

5.2.5. レプリケーションスロットレプリケーションスロット

スレーブに未転送のW ALを保持することで、SRの維持を保証します。アーカイブ運用でも同期の保証は可能ですが、アーカイブログの管理などが問題となり、ノーアーカイ

ブ運用をしている環境も多くあります。そのような環境において、レプリケーションの維持を保証するためには、レプリケーションスロットの設定が必要です。またアーカイブ運用

においても、アーカイブW ALファイルの削除にSRの考慮が不要になるため、有用な設定です。

1. 関連パラメータ

既存のレプリケーションスロットの設定に加え、次のパラメータを指定します。

基本的なSR の構築手順にて設定済みのパラメータも、改めて記載しています。

表 5.8 レプリケーションスロットの設定

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値内容内容

マスタ po stg resq l.con f max_replication _slots スレーブ数以上（設定済み）作成可能なレプリケーションスロット数を指

定する。

スレー

ブ

po stg resq l.con f h o t_stan d b y_feedback o n （設定済み）スレーブの状態をマスタにフィードバックす

る。

スレー

ブ

recovery.con f primary_slot_n ame レプリケーションスロット名使用するレプリケーションスロット名を指定

する。

注釈

障害時スレーブをマスタにする場合に備え、マスタに設定したパラメータはスレーブ側でも事前に有効化することを推奨します。

2. レプリケーションスロットの作成方法

レプリケーションスロットに関連する関数は以下の通りです。

表 5.9 レプリケーションスロットの関数

関数名関数名説明説明

pg _create_p h ysical_replicatio n _slot(スロット名[,

tru e/false])

レプリケーションスロットを作成する。

スロット名：作成するレプリケーションスロット名を指定する。

tru e/false：tru eの場合、レプリケーションスロットは即座にW ALを保持する。

falseの場合従来通り、スレーブがレプリケーションスロットに繋いだ時点から

W ALを保持する。

pg _d rop_replication _slot(スロット名)

レプリケーションスロットを削除する。

スロット名：削除するレプリケーションスロット名を指定する。

3. 検証

(1)マスタにてpo stg resql.con fにmax_replication _slotsを加え、設定反映のため再起動。

$ vi $PGDATA/postgresql.conf

[postgresql.conf]

max_replication_slots = 10 <--- デフォルト

$ pg_ctl restart

PostgreSQL Enterprise Consortium

Page 25 of 285

(2)マスタにてレプリケーションスロットを作成。

postgres=# SELECT pg_create_physical_replication_slot('slot1', true);

pg_create_physical_replication_slot

-------------------------------------

(slot1,0/B000220)

(1 row)

(3)マスタにてレプリケーションスロットの作成を確認。

postgres=# SELECT slot_name, restart_lsn, active FROM pg_replication_slots;

slot_name | restart_lsn | active

-----------+-------------+--------

slot1 | 0/B000220 | f

(1 row)

・active列が'f'であることから、まだ使用されていない。

・restart_lsn列に値があることから、使用されていなくてもW ALの保持は開始している。

(4)スレーブにてreco very.co n fにp rimary_slot_n ameを加え、設定反映のため再起動。

$ vi $PGDATA/postgresql.conf

[recovery.conf]

primary_slot_name = 'slot1'

$ pg_ctl restart

(5)マスタ側でレプリケーションスロットが使用されていることを確認。

postgres=# SELECT slot_name, restart_lsn, active FROM pg_replication_slots;

slot_name | restart_lsn | active

-----------+-------------+--------

slot1 | 0/B0002C8 | t

(1 row)

・active列が't'であることから、使用されている。

5.2.6. 【参考情報】同期モードにおけるパフォーマンスへの影響【参考情報】同期モードにおけるパフォーマンスへの影響

同期モードの懸念として、W AL転送の待機によるパフォーマンスへの影響があります。以下の図はsyn ch ro n o u s_co mmitの各設定によるパフォーマンス比較です。(on の

値を1.00とした相対値）。

サーバススペック

CPU　 :　In tel(R ) Xeon (R ) CPU E5-2640 v2 @ 2.00GHz 16Core

メモリ　:　64GB

O S　　: Red Hat En terp rise Lin u x Server release 6.5 (Santiago)

Po stg reSQ Lのバージョン : Po stg reSQ L 9.6.1

パラメータ設定

キャッシュヒット率の影響を受けないようほぼ100%となるように調整

shared_bu ffers　: 8G B

処理中に自動VACUUM が発生しないように無効化

au tova cu u m　：off

処理中にチェックポイントが発生しないように調整

ch eck p o int_timeou t　：1h

max_w al_size　：10G B

処理前に毎回手動でチェックポイント実行

トランザクションツールはpgben ch を使用。

初期化スケール 100

100セッション、25ワーカスレッドのトランザクションを実施(p g ben ch -c 100 -j 25)

PostgreSQL Enterprise Consortium

Page 26 of 285

通常のO LTPアプリケーションではこれほど激しいトランザクションではないため、低下は限定的と考えられます。

同期モードの実装にあたっては、実際のアプリケーションで検証してご確認ください。

5.2.7. 遅延レプリケーション遅延レプリケーション

スレーブの適用を一時的に遅延させます。マスタの操作ミスが即座に伝搬されるのを防ぐのが目的です。 W AL転送までは遅延なく処理されるため、データ保全には影響

ありません。同期転送(syn ch rono u s_co mmit=o n )との組み合わせができます。

注意点

・マスタへの切り替わり時に遅延分の適用が発生するため切り替わりに時間がかかります。

　高可用性用途には向いていません。

　複数スレーブ構成にて、1台目位は同期、で2台目を遅延とするする構成が考えられます。

・以下の操作を行うと、遅延レプリケーションの設定(reco very_min _app ly_delay)は無視され、最新の状態まで適用されます。ご注意下さい。

　- 再起動 (pg_ctl restart)

　- 昇格 (p g _ctl p romote)

・完全同期(syn ch ro n ou s_co mmit= remo te_apply)ではDML(自動コミットがオフの場合はCO M M IT）を待機するため、遅延レプリケーションは使用できませ

ん。

以下の検証を行います。

検証1:　遅延レプリケーションの設定および動作確認

　　　スレーブへの適用が指定した時間分、遅延する事。およびマスタでの遅延確認。

検証2:　問題発生前の状態まで適用

　　　オペレーションミス発生を想定し、発生前の状態まで適用し、昇格。

1. 関連パラメータ

既存のレプリケーションスロットの設定に加え、次のパラメータを指定します。

表 5.10 遅延レプリケーションの設定

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値

スレーブ po stg resq l.con f h ot_stan db y_feedback o n （フィードバックを有効化）

スレーブ recovery.con f reco very_min _app ly_delay 遅延させる時間を指定

2. 検証1：遅延レプリケーションの設定および動作確認

(1)マスタにてテストに使用するテーブルを作成。

（マスタ）

postgres=# CREATE TABLE delay_test(id integer, time1 timestamp);

postgres=# \d delay_test

Table "public.delay_test"

Column | Type | Modifiers

--------+-----------------------------+-----------

id | integer |

time1 | timestamp without time zone |

(2)スレーブで遅延レプリケーションの設定を行い、再起動。

PostgreSQL Enterprise Consortium

Page 27 of 285

（スレーブ）

$ vi $PGDATA/postgresql.conf

[postgresql.conf]

hot_standby_feedback = on

$ vi $PGDATA/recovery.conf

[recovery.conf]

recovery_min_apply_delay = '60min'

$ pg_ctl restart

(3)マスタにてテストテーブルにデータを追加。

（マスタ）

postgres=# INSERT INTO delay_test VALUES (1, localtimestamp);

postgres=# SELECT * FROM delay_test;

id | time1

----+----------------------------

1 | 2018-03-10 18:05:46.29221

(1 rows)

(4)スレーブにて即座に反映されない事を確認。

（スレーブ）

postgres=# SELECT * FROM delay_test;

id | time1

----+-------

(0 rows) <--- INSERTが反映されていない

(5)マスタにて適用の遅延を確認。

pg _stat_replication ビューのrep lay_lag列で確認

（マスタ）

postgres=# SELECT write_lag,flush_lag,replay_lag FROM pg_stat_replication ;

-[ RECORD 1 ]---------------

write_lag | 00:00:00.000323

flush_lag | 00:00:00.00048

replay_lag | 00:00:38.354572 <--- recovery_min_apply_delayに達するまで適用を待機

(6)１時間経過後、スレーブにて適用された事を確認。

（スレーブ）

postgres=# SELECT *,localtimestamp FROM delay_test;

id | time1 | localtimestamp

----+----------------------------+----------------------------

1 | 2018-03-10 18:05:46.29221 | 2018-03-10 19:06:10.521195

(q rows)

(7)マスタにて適用の遅延がクリアされた事を確認。

PostgreSQL Enterprise Consortium

Page 28 of 285

（マスタ）

postgres=# SELECT write_lag,flush_lag,replay_lag FROM pg_stat_replication ;

-[ RECORD 1 ]---------------

write_lag |

flush_lag |

replay_lag |

3. 検証2：問題発生前の状態まで適用

(1)マスタにてテストテーブルにデータを追加。

（マスタ）

postgres=# INSERT INTO delay_test VALUES (2, localtimestamp);

postgres=# SELECT * FROM delay_test;

id | time1

----+----------------------------

1 | 2018-03-10 18:05:46.29221

2 | 2018-03-10 19:30:11.23870

(1 rows)

id = 2の更新(INSERT)をオペレーションミスとみなし、スレーブを更新前の時点まで適用

(2)マスタを停止。

$ pg_ctl stop

(3)スレーブにて1件も反映されない事を確認。

（スレーブ）

postgres=# SELECT * FROM delay_test;

id | time1

----+-------

(0 rows) <--- INSERTが反映されていない

(4)スレーブを停止。

$ pg_ctl stop

(5)スレーブにてreco very.co n fを修正。

$ vi $PGDATA/recovery.conf

[recovery.conf]

restore_command = 'cp <$PGDATAパス>/pg_wal/%f %p' <--- WALのパスを指定

recovery_target_time = '2018-03-10 19:30:00' <--- id=2のCOMMIT直前の時刻

recovery_target_timeline = latest <--- 最新のタイムライン

recovery_target_action = 'promote' <--- 適用中断後、昇格

(6)スレーブにて指定時間までのリカバリおよび昇格(スレーブ→新マスタ）

PostgreSQL Enterprise Consortium

Page 29 of 285

$ pg_ctl start

$ pg_controldata | grep state <--- マスタ/スレーブの確認

Database cluster state: in production <--- マスタ

表 5.11 遅延レプリケーションのPITRログ

メッセージメッセージ時間時間

LO G : startin g po int-in -time recovery to 2018-03-10 19:30:00+09 recovery_targ et_time

LO G : reco very stopp in g b efore co mmit of tra n sactio n 578, time 2018-03-10 19:30:11.423701 id = 2のCO MMIT時間

LO G : last co mp leted transaction w as at lo g time 2018-03-10 18:05:46.314276 id = 1のCO MMIT時間

(8)新マスタにてid = 1のみ適用されていることを確認。

postgres=# SELECT * FROM delay_test ;

id | time1

----+---------------------------

1 | 2018-03-10 18:05:46.29221

(1 row)

5.2.8. WAL圧縮圧縮

Fu ll Page W rite時(チェックポイント後の最初の更新時)に、W ALに書き出すフルページイメージを圧縮します。圧縮されたW ALは適用時に解凍されます。 W ALファイル

のサイズが小さくなるため、書き込みや転送の時間短縮書き込みや転送の時間短縮が期待されます。注意点として、圧縮処理および解凍処理が発生するため、通常より余分にCPUを使用しま

す。適用についてはそれらを総合的に判断します。一般的な適用場面として、SR構成において効果的と考えられます。特に以下の構成で有力です。

同期モード（転送まで）または完全同期モード（適用まで）

W AL転送の遅延を懸念して同期モード設定を躊躇する場面でW AL圧縮を検討します。

非同期モードでもW AL圧縮は有力ですが、一定のW AL転送の遅延は許容されるため、

マスタのCPU 負荷を優先してW AL圧縮を適用しないという判断も考えられます。

スレーブの遠隔地配置（ディザスタ・リカバリ）

スレーブを遠隔地に配置する構成において、非同期モードでもW AL転送の遅延が

許容範囲を超える場合にW AL圧縮の適用を検討します。

1. 関連パラメータ

既存のレプリケーションスロットの設定に加え、次のパラメータを指定します。

表 5.12 W AL圧縮の設定

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値

マスタ po stg resq l.con f w al_co mp ressio n 'o n '

5.3. SR環境の監視

5.3.1. レプリケーション操作ログの監視レプリケーション操作ログの監視

5.3.1.1. 調査の目的調査の目的

SR構成のサーバログ監視について有益な情報を提示する事を目的としています。

以下の挙動時にサーバログに出力されるメッセージを確認しました。

マスタの起動/停止

スレーブの起動/停止

カスケードスレーブの起動/停止

マスタ側のW AL再利用によるロスト(スロット不使用）

カスケードスレーブ構成時のスレーブ側のW AL再利用によるロスト(スロット不使用）

以下のパターンで検証しました。

レプリケーション操作ログ出力無効時（デフォルト）

PostgreSQL Enterprise Consortium

Page 30 of 285

lo g _replication _co mmand = off

レプリケーション操作ログ出力有効時

lo g _replication _co mmand = on

5.3.1.2. 調査結果調査結果

マスタ側またはスレーブ側のサーバログに出力されるレプリケーション情報についてまとめます。

ホスト名、IPアドレス、ポート番号、ユーザ名、データベース名は例です。

レプリケーション操作ログ出力無効時（デフォルト）

表 5.13 デフォルトで出力される情報

タイミングタイミングサイトサイトメッセージメッセージ

スレーブ停止時マスタスレーブが複数台存在し、Q u o rum-based 同期レプリケーションを設定していない場合に、

片系スレーブの起動または停止を行うことで同期優先順位が変化した場合のみされます。

STAR T_REPLICATIO N 0/57000000 TIM ELINE 1

マスタ停止時スレーブエラーメッセージが繰り返し出力されます。

LO G : in valid record len gth at 132/EF 8AD7F0: w an ted 24, go t 0

FATAL: could not connect to th e primary server: cou ld n o t co n n ect to server: Con n ectio n refu sed

　　　　Is th e server run n in g o n h o st "master" (192.168.100.100) and acceptin g

　　　　TCP/IP co n n ectio n s o n po rt 5432?

W AL再利用による

ロスト

マスタエラーメッセージが繰り返し出力されます。

ERRO R : req u ested W AL seg men t 0000001100000132000000EF h as already been removed

W AL再利用による

ロスト

スレーブエラーメッセージが繰り返し出力されます。

LO G : started streamin g W AL fro m p rimary at 132/EF000000 o n timelin e 17

FATAL: could not receive data from W A L stream: ERRO R : requ ested W AL seg men t

0000001100000132000000EF has already been removed

レプリケーション操作ログ出力有効時

　　デフォルトで出力される情報に加えて、以下が出力されます。

表 5.14 監視強化時に出力される情報

タイミングタイミングサイトサイトメッセージメッセージ

スレーブ起動ま

たは停止時

マスタスレーブが複数台存在し、Q u o ru m-based 同期レプリケーションを設定していない場合に、

片系スレーブの起動または停止を行うことで同期優先順位が変化した場合のみ出力されます。

LO G : received rep licatio n comman d: IDENTIFY_SYSTEM

LO G : received rep licatio n comman d:

STAR T_REPLICATIO N 0/57000000 TIM ELINE 1

W AL再利用に

よるロスト

マスタ、スレーブ(ス

レーブ出力はカス

ケード・レプリケー

ション時のみ)

エラーメッセージが繰り返し出力されます。

LO G : received rep licatio n comman d: IDENTIFY_SYSTEM

LO G : received rep licatio n comman d: START_REPLICATIO N 134/4A000000 TIM ELINE 17

5.3.1.3. 調査結果調査結果

SR関連のエラーが発生した場合は、デフォルトの設定(log_min _messages= 'w arn ing ')でサーバログに出力されます。

表の太字の文字が監視キーワード候補です。

マスタが停止するとスレーブに出力がありますが、スレーブが単一の構成時にはスレーブが停止してもマスタに出力はありませんでした。

lo g _replication _co mmand による出力はそれほど多くなく、監視に対する影響は限定的です。

ただリロードで反映できることと合わせて、気軽に有効化できるとも言えます。

lo g _min _message = D EB U G [1-5] (例)DEBU G1、DEB U G 2 とすることでもレプリケーション関連のメッセージが出力されます。

ただし影響が大きいため、通常はlo g_replication _comman d を使用します。

lo g _replication _co mmand による出力は、スレーブのw al receiverプロセスからフィードバックされた情報です。

lo g _lin e_prefixにap p lication _name(%a)を設定する事で確認できます。

SQ LSTATEの値をキーワードに監視を行うために、lo g_lin e_prefixパラメータにSQ LSTATE (%e)を設定します。

5.3.2. 同期状況の監視同期状況の監視

非同期レプリケーションを構成した場合、ハードやNW 構成、利用状況によって

マスタとスレーブの同期状況が変化します。

この状態を監視し、同期の遅延が許容範囲内であるかを確認します。

■前提前提

PostgreSQL Enterprise Consortium

Page 31 of 285

構成：

マスタ下に1台または2台のスレーブ構成

マスタ、スレーブに加えカスケードスレーブをスレーブ下に構成する計3台構成

（カスケード・レプリケーション）

バージョン：Po stgreSQ L 10

同期モード：問わない

5.3.2.1. 同期遅延監視同期遅延監視

(1)W ALの書き込み位置による同期遅延量を用いて監視することは可能か

「2014年度W G3活動報告書- 可用性編 -」での検証結果をベースに実施します。

マスタのW ALとスタンバイが適応したW ALの2つの差分は、

マスタの最新W ALの書き込み位置(LSN：Log Seq u en ce Numb er)と

スタンバイが適用したW ALの位置(LSN)との差分より算出します。

マスタのLSNは、pg _cu rren t_w al_in sert_lsn ()関数が返す現在のW ALの挿入位置とみなします。

スタンバイのLSNは、統計情報pg _stat_replicatio n ビューのreplay_lsn を使用します。

この2つのLSNの差分をバイト単位で表示するために、pg_w al_lsn _diff関数の引数にそれぞれを格納し

その結果が許容値を超過するかどうかで、監視を行います。

検証には、以下シェルスクリプトで実施しました。

監視通知部については、テストの為、標準出力のみとしています。

PostgreSQL Enterprise Consortium

Page 32 of 285

#!/bin/sh

HOST=localhost

LIMIT=1

SLEEPTIME=2

ALERT="echo"

SLAVENUM=2

function send_alert(){

${ALERT} $1

}

IFS_DEFAULT=$IFS

while :

val1=$(psql -h $HOST -p 5432 -U postgres -q -t -c "select current_time;")

case $(psql -p 5432 -U postgres -q -t -c "SELECT pg_is_in_recovery();"

|awk '{print $NF}') in

val2=$(psql --no-align -h $HOST -p 5432 -U postgres -q -t -c

"select client_addr,pg_wal_lsn_diff(master,replay_lsn)

as replaydiff from (select pg_last_wal_replay_lsn() master)

as m,pg_stat_replication;")

;;

val2=$(psql --no-align -h $HOST -p 5432 -U postgres -q -t -c

"select client_addr,pg_wal_lsn_diff(master,replay_lsn)

as replaydiff from (select pg_current_wal_insert_lsn() master)

as m,pg_stat_replication;")

;;

esac

rownum=$(psql --no-align -h $HOST -p 5432 -U postgres -q -t -c

"select client_addr,pg_wal_lsn_diff(master,replay_lsn)

as replaydiff from (select pg_current_wal_insert_lsn() master)

as m,pg_stat_replication;" |wc -l)

for slave_lsn in ${val2};

if [ ${rownum} -ne ${SLAVENUM} ]; then

send_alert "Slave Down |${val1}"

IFS=$'|'

byte=`echo ${slave_lsn} | awk '{print $NF}'`

if [ ${byte} -gt ${LIMIT} ]; then

send_alert "Replication Delay ${val1},${slave_lsn}"

IFS=${IFS_DEFAULT}

sleep ${SLEEPTIME}

done

今回の検証でスレーブが複数存在する場合も、それぞれのスレーブの遅延状況を検知することが可能であることがわかりました。

監視シェルを実行中にinsert文を実行した結果を記載します。

以下の通り、遅延状況を検知でき、メールサーバ等に連携することで監視することが可能です。

また間接的に更新待ち監視も行うことができます。詳細は、更新・読取監視の項に記載します。

PostgreSQL Enterprise Consortium

Page 33 of 285

$ ./delay_test.sh

Replication Delay 20:58:18.451839+09,192.168.100.101 11880

Replication Delay 20:58:18.451839+09,192.168.100.102 11880

Replication Delay 20:58:22.484532+09,192.168.100.101 11880

Replication Delay 20:58:22.484532+09,192.168.100.102 11880

Replication Delay 20:58:26.512656+09,192.168.100.101 12048

Replication Delay 20:58:26.512656+09,192.168.100.102 12048

Replication Delay 20:58:30.538009+09,192.168.100.102 12048

尚、カスケードスレーブ構成の場合にはスレーブ上で同シェルスクリプトを実行することで、

カスケードスレーブとの同期の遅延状況を検知することが可能です。

5.3.3. 更新、読み取りの監視更新、読み取りの監視

非同期レプリケーションを構成した場合、ハードやNW 構成、利用状況によってマスタとスレーブの同期状況が変化します。

この状態を監視し、同期の遅延が許容範囲内であるかを確認します。

■前提構成前提構成

3ノード構成

1. 複数スレーブ方式（親 - 子1 , 子2）スレーブ2はマスタと繋がっている。

2. カスケード方式（親 - 子 - 孫）スレーブ2はスレーブ1と繋がっている

同期モード：同期または完全同期 (syn ch ro n ou s_co mmit = on / remote_apply)

5.3.3.1. 更新・読取監視更新・読取監視

(1)Po stgreSQ Lの機能により監視することは可能か

- 検証方法

　Po stgreSQ Lの内部パラメータ(statemen t_timeou t)により、マスタへの更新処理に対して

　スレーブ停止によって一定時間応答がない場合に接続を切断し、アラート通知することは可能かを検証を行いました。

　statemen t_timeou tは、po stgresql.co n f内での設定は推奨されていない為、SQ L発行時に設定しました。

　また、pg_stat_rep licatio n ビューにより間接的に、検知できないかについて検証を行いました。

- 検証結果

statement_timeoutを設定しSQ Lを発行しましたが、有効に機能せず

Ctrl+ Cをキーインするまで停止しないという結果となりました。

複数台のスレーブのうち１つでも稼働している場合には設定時間を待たずに

PostgreSQL Enterprise Consortium

Page 34 of 285

一方のスレーブの応答をもって処理が完了してしまうため、他のスレーブの同期遅延の検知ができないという結果となりました。

全てのスレーブが応答不可能である場合全てのスレーブが応答不可能である場合

$ psql -U postgres -d testdb -q -t << EOF

> \timing on

> SET statement_timeout TO 5000;

> insert into test(id) values(1);

> delete from test where id=1;

> EOF

時間: 0.192 ms

^CCancel request sent

WARNING: canceling wait for synchronous replication due to user request

DETAIL: The transaction has already committed locally, but might not have been

replicated to the standby.

時間: 13626.496 ms

一方のスレーブのみ応答が可能である場合一方のスレーブのみ応答が可能である場合

$ psql -U postgres -d testdb -q -t << EOF

> \timing on

> SET statement_timeout TO 5000;

> insert into test(id) values(1);

> delete from test where id=1;

> EOF

Time: 0.147 ms

Time: 1.899 ms

Time: 1.277 ms

　pg_stat_rep licatio n ビューについては、スレーブサーバ停止時にレコードが取得できなくなる為

　この点を利用することで間接的に、同期待ちを検知することが可能であることがわかります。

testdb=# select * from pg_stat_replication;

sync_priority | sync_state

-------+----------+---------+------------------+----------------+---------------

--+-------------+-------------------------------+--------------+-----------+----

-----------+----------------+----------------+-----------------+---------------+

------------

(0 行)

(2)O Sコマンドなどの外部機能により、更新処理に対して一定時間応答がない場合を監視する

　スレーブが単一であればtimeou tコマンドにより、指定秒数で強制切断に成功し、

　スタンバイと同期が取れていないメッセージが出力されます。

　また終了値として、124が返却されている為、全てのスレーブが応答できない場合に限り、

　メッセージ内容または、終了値を制御することでスレーブサーバ障害による同期待ちを検知することが可能です。

スレーブが単一である場合スレーブが単一である場合

PostgreSQL Enterprise Consortium

Page 35 of 285

$ timeout -sINT 5 psql -U postgres -d testdb -q -t << EOF

> \timing on

> insert into test(id) values(1);

> delete from test where id=1;

> EOF

Cancel request sent

WARNING: canceling wait for synchronous replication due to user request

DETAIL: The transaction has already committed locally, but might not have been

replicated to the standby.

Time: 4994.166 ms (00:04.994)

[postgres@test_pg01 data]$ echo $?

124

　しかし statemen t_timeou t設定による検証のケースと同様に、複数台のスレーブのうち１つでも稼働している場合には

　設定時間を待たずに一方のスレーブの応答をもって処理が完了してしまうため、

　他のスレーブの同期遅延の検知ができないという結果となりました。

一方のスレーブのみ応答が可能である場合一方のスレーブのみ応答が可能である場合

$ timeout -sINT 5 psql -U postgres -d testdb -q -t << EOF

> \timing on

> insert into test(id) values(1);

> delete from test where id=1;

> EOF

Time: 2.382 ms

Time: 1.246 ms

[postgres@test_pg01 data]$ echo $?

5.3.4. スプリットブレインの監視スプリットブレインの監視

5.3.4.1. スプリットブレインの定義と調査の目的スプリットブレインの定義と調査の目的

SR構成においては、通常はマスタの障害を検知した場合にスレーブを昇格させます。つまりマスタは常に1台のみです。ただしオペレーションミスにより、マスタが正常な状態

にもかかわらずスレーブを昇格させてしまうという事も有り得ます。稼働中のマスタ（シングル）が2台という危険な状態になります。その状態をスプリットブレインと定義します。

その場合でも全てのアプリケーションが元のマスタにのみ接続していれば問題ありませんが、 2台目のマスタにも接続が発生するとデータの整合性が損なわれてしまいます。

それを避けるため、スプリットブレイン状態になっていないかの監視の方法を検討します。

5.3.4.2. 監視方法監視方法

以下の監視についてまとめます。

サーバログの監視

pg _co n trold ataコマンドによる監視

pg _co n trol_recovery関数による監視

pg _is_in _recovery関数による監視

5.3.4.3. サーバログの監視サーバログの監視

pg _ctl p romo te コマンドにより昇格した場合は、昇格したノードのサーバログに以下のメッセージが出力されます。 timelin e IDが変化が変化した事が分かります。

received promote request

selected new timeline ID: XX

マスタ稼働中にスレーブ側にこのようなメッセージが出力されていないかを監視します。

注意点

recovery.con fを削除（または改名）した後に再起動する事でマスタ（シングル）として起動する方法もあります。

ただし timelin e ID の変化がなく、特徴的なメッセージは出力されません。状態変更の捕捉が困難です。

5.3.4.4. pg_controldataコマンドによる監視コマンドによる監視

PostgreSQL Enterprise Consortium

Page 36 of 285

5.3.4.4. pg_controldataコマンドによる監視コマンドによる監視

pg _co n trold ataコマンドは制御ファイル($PG DATA/g lobal/p g _co n trol)の状態を表示します。

以下に実行例を示します。ここでは環境変数LANGの設定により英語で表示しています。

(実行例)

$ export LANG=C

$ pg_controldata

pg_control version number: 1002

Catalog version number: 201707211

Database system identifier: 6514575400714084610

Database cluster state: in archive recovery

～以下略～

多数の項目がありますが、ここでは"Datab ase clu ster state"に着目します。必要な項目のみ抽出する例です。

(スレーブでの実行例)

$ pg_controldata | grep "Database cluster state"

Database cluster state: in archive recovery

4種類の状態があります。

マスタ/スレーブ

稼働中/停止中

表 5.15 Datab ase clu ster stateで表示される値

表示される値表示される値 (英語）英語）表示される値表示される値 (日本語）日本語）意味意味

in pro du ction 運用中マスタとして稼働中

in arch ive recovery アーカイブリカバリ中スレーブとして稼働中

shu t d o w n シャットダウンマスタとして停止中

shu t d o w n in recovery リカバリしながらシャットダウン中スレーブとして停止中

"in arch ive reco very"はPITRとしてのリカバリ中の場合も含みますが、ここではスレーブ状態の意味です。

カスケード・レプリケーション構成の場合は、スレーブもリカバリ中との取り扱いになるため

カスケードスレーブと同様にスレーブ状態に準じた状態が表示されます。

両ノードとも"in pro d u ction "状態でない事を確認します。

ssh コマンドでリモートの状態を容易に取得できます。

注意点としては、リモート側の環境変数を認識しないため、明示的に指定する必要があります。

以下はローカルとリモートで同一設定の前提です。

(スプリットブレインの状態下での実行例)

$ ssh <remote> $PGHOME/bin/pg_controldata $PGDATA | \

> grep "Database cluster state"

Database cluster state: in production

5.3.4.5. pg_control_recoveryコマンドによる監視コマンドによる監視

pg _co n trol_recoveryは制御ファイルの情報をpg _co n trold ataコマンドに代わり取得する方法です。

取得できる項目は限られていますが、SELECT文で取得できるという特徴があります。

状態監視の選択肢の一つとしてご認識下さい。

(スレーブでの実行例)

PostgreSQL Enterprise Consortium

Page 37 of 285

=# SELECT pg_control_recovery();

pg_control_recovery

-----------------------------

(0/5E0001B0,1,0/0,0/0,f)

(1 行)

カンマ区切りにより5項目から構成されています。何れもpg_co n troldataコマンドでも取得できます。

表 5.16 p g _con trol_reco very関数の表示内容例

項目項目マスタマスタスレーブスレーブ

min _recovery_end _lsn 0/0 0/15000178

min _recovery_end _timelin e 0 1

backu p _start_lsn 0/0 0/0

backu p _end _lsn 0/0 0/0

end _o f_backu p _reco rd _required f f

min _recovery_end _lo catio n および min_recovery_en d _timelineにマスタとスレーブの違いが表れます。

ただしpg _co n trold a taコマンドによる監視と同様、カスケード・レプリケーション構成の場合は

スレーブもリカバリ中との取り扱いになるため、例外的にカスケードスレーブとの違いが表れません。

5.3.4.6. pg_is_in_recovery関数による監視関数による監視

リカバリ中かどうかを示します。マスタであれば f (false) 、スレーブであれば t (tru e) を表示します。

(スレーブでの実行例)

=# SELECT pg_is_in_recovery();

pg_is_in_recovery

-------------------

(1 行)

両ノードとも f (false) 状態でない事を確認します。

5.4. SR環境の障害時運用

5.4.1. 本文書における用語の定義本文書における用語の定義

5.4.1.1. フェイルオーバフェイルオーバ

マスタへの障害発生時やアクセス不能時に、スレーブをマスタへ昇格させる処理を指します。

新マスタはシングル構成であり、レプリケーションされていない片系運用の状態です。

レプリケーション構成への復旧には後述の「フェイルバック」を実行しますが、

マスタの障害がインスタンス障害など、データファイルの障害でない場合は、「スイッチオーバ」が可能な場合もあります。

5.4.1.2. フェイルバックフェイルバック

フェイルオーバにより片系運用になった後、再度レプリケーション構成に復帰させる処理を指します。

シングル構成となった新マスタに、新スレーブを追加します。

新マスタと新スレーブを交代させてフェイルオーバ前に戻すことまでは含まない事とします。

複数スレーブ構成では、不要な処理となります。

PostgreSQL Enterprise Consortium

Page 38 of 285

5.4.1.3. スイッチオーバスイッチオーバ

マスタとスレーブを入れ替える処理を指します。

マスタを停止し、スレーブを新マスタへ昇格させ旧マスタを新スレーブとして再追加します。

マスタのメンテナンスのための一時的な入れ替えなどが目的です。

フェイルオーバーとの違いは、マスタ停止が障害による停止か計画停止かであり、スレーブに対する処理は同様です。

5.4.1.4. スイッチバックスイッチバック

スイッチオーバ後に、マスタ/スレーブを入れ替えることを指します。

マスタ/スレーブとの関係性を除き処理内容は、「スイッチオーバ」と同様です。

PostgreSQL Enterprise Consortium

Page 39 of 285

5.4.2. 障害時運用手順（障害時運用手順（ 2ノード構成）ノード構成）

■前提以降の手順では次の前提とします。

Po stg reSQ L 10.1

マスタ、スレーブの2台構成（ホスト名をそれぞれ server1,server2と表記する）

同期モードは同期（syn ch ro n o u s_co mmit = on または remo te_apply)

スレーブはホットスタンバイ機能により参照可能 (ho t_stand b y = on )

レプリケーション用のユーザは rep _user

マスタ/スレーブとも、portは5432を使用

レプリケーションスロット使用

マスタ/スレーブとも、環境変数PG D ATA,PG PO R Tは設定済み

死活監視は実際の運用ではクラスタソフトを使用するのが一般的ですが、ここでは便宜上手動で実施

サーバのNICはパブリックのみ

仮想IPについては考慮しない

■対処一覧大別すると3種類の対処方法が考えられます。

PostgreSQL Enterprise Consortium

Page 40 of 285

表 5.17 障害別の対処

障害箇障害箇

所所障害状況障害状況 pg_basebackupとと pg_rew indの使い分けの使い分け

1 マスタマスタとスレーブの関係が崩れており再構成が必要

物理障害

pro mo teを伴わないスレーブのマスタ化(reco very.con f削除）

pg _b aseb acku pコマンドを使用してフェイルバック

2 マスタマスタとスレーブの関係は巻き戻しで復旧可能

非同期レプリケーションのインスタンス障害（差異がある状態で昇格）

スプリットブレイン状態での旧マスタへの更新

pg _rew in dコマンドを使用してスイッチバック

3 マスタマスタとスレーブの切り替え可能

計画停止

同期レプリケーションのインスタンス障害(物理障害なし）

pg _rew in dコマンドを使用しないでスイッチバック

4 スレーブマスタとスレーブの連携再開可能

スレーブの障害

同期式の場合は非同期式に切り替え

5.4.2.1. フェイルオーバフェイルオーバ

フェイルオーバについて記載します。

マスタにて、障害が発生した場合のスレーブを新マスタへ昇格したシングル構成図

(1) マスタの疑似障害発生

immed iateオプションにて停止、またはpo stg resプロセスのkillする事で擬似障害を発生させます。

マスタにて実行します。

$ pg_ctl -w -m immediate stop

$ kill -9 `head -1 $PGDATA/postmaster.pid`

(2) マスタの死活監視にて異常を検知

死活監視の方法には多数ありますが、ここではpg_isread yコマンドを使用します。

pg _isreadyコマンドはクライアントツールですので、任意のノードから実行できます。

$ pg_isready -h server2 -U postgres -d postgres

server2:5432 - no response

(3) スレーブを新マスタへ昇格

旧スレーブで実行します。

$ pg_ctl promote

※サーバログに下記内容が記載されること

"d a tab ase system is ready to accept co n n ection s"

ただしこの時点ではsyn ch ro n ou s_stan d b y_namesパラメータに値が設定されているため、新マスタで更新処理ができない状態です。

PostgreSQL Enterprise Consortium

Page 41 of 285

(4) 新マスタを非同期に切り替え

syn ch ro n o u s_stan d b y_n amesパラメータの設定を''に設定し、リロードで反映します。

新マスタで実行します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_standby_names = '*'

[編集後]

synchronous_standby_names = ''

$ pg_ctl reload

これで更新処理ができる状態になりました。

(5) 新マスタの死活監視にて正常を確認

$ pg_isready -h server2 -U postgres -d postgres

server2:5432 - accepting connections

以上でファイルオーバーは完了です。

5.4.2.2. フェイルバックフェイルバック

pg _b aseb acku pを使用したフェイルバックについて記載します。初期構築手順とほぼ同じです。

マスタ障害発生によるフェイルオーバ後、旧マスタを新スレーブとしたレプリケーション構成図

■パラメータ

pg _b aseb acku pに必要な設定を記載します。

表 5.18 p g _baseb acku p に必要な設定

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値内容内容

マスタ po stg resq l.con f listen _add ress 0.0.0.0 全てのIPアドレス(v4)からの接続を受け付ける

マスタ po stg resq l.con f max_w al_send ers 2 W ALストリームオプションを付与する場合は、2以上を設定

■p g _baseb acku p コマンド

pg _b aseb acku pコマンドの主なオプションは次の通りです。

PostgreSQL Enterprise Consortium

Page 42 of 285

表 5.19 p g _baseb acku p のオプション

オプションオプション内容内容

-D < d irecto ry> 出力を書き出すディレクトリを指定。

-X < meth o d>

--w al-metho d = < meth o d>

必要なW ALファイルをバックアップに含める。metho d (収集方式)は以下から選択。

fetch ：W ALファイルは最後に収集

stream：バックアップ作成中に同時にW ALをストリームで収集

運用中にp g _baseb acku p を実行する場合には stream を指定する。

fetch （最後に収集）では、必要なW ALファイルが削除される可能性があるため。

-S < slot_n ame>

--slo t=< slo t_n ame>

W ALストリーミングの収集に指定したレプリケーションスロットを使用。

-X stream とセットで指定。

必要なW ALファイルが削除されるのを防ぐ事を目的とする。

運用中にp g _baseb acku p を実行する場合に使用を検討する。

以下に注意する。

事前にレプリケーションスロットを作成する必要がある

マスタのW AL領域の空きが十分である事を確認する

-R

--w rite-reco very-co n f

最低限のreco very.con fを作成。必要に応じてreco very.co n fを加筆修正。

-r < rate>

--max-rate=< rate>

サーバから転送されるデータの最大転送速度を指定。

運用中にp g _baseb acku p を実行する場合に使用を検討する。

転送速度を抑える事で、マスタに対する影響を制限する事を目的とする。

-P 進行状況報告を有効化。

pg _b aseb acku p処理中におおよその進行状況を報告する。

運用中に実行した場合、データベースクラスタのサイズが増加して進行状況が100%を超える場合があ

る。

-v 冗長モードを有効化。

進行状況報告も有効な場合、現在処理中のファイル名を出力。

pg _b aseb acku pでレプリケーションスロットが使用できます。 W AL収集方式に stream を指定する事でW ALをほぼ確保できますが、スロットを指定する事でより確実にな

ります。スロットを使用する運用であれば、この段階で作成するのが有力です。

■フェイルバック手順

pg _b aseb acku pにスロットを指定する場合を記載します。

(1) 旧マスタのデータベースクラスタを削除

旧マスタにて実行します。

$ rm -rf $PGDATA/*

※$PG DATA以外に表領域を作成している場合、そのファイルも削除します。

※$PG DATAディレクトリを削除する場合は、postgresユーザで$PGDATAディレクトリを作成できるよう

　親ディレクトリのオーナーまたはパーミッションを設定します。

(2) レプリケーションスロットの作成

新マスタにて実行します。

PostgreSQL Enterprise Consortium

Page 43 of 285

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server1',true);　　-- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server1,144/EEFC8940)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots ;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

plugin |

slot_type | physical

datoid |

database |

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 144/EEFC8940 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(3) p g _basebacku p コマンドにて、新マスタからデータベースクラスタをコピー

旧マスタにて実行します。

$ pg_basebackup -h server2 -U rep_user -D $PGDATA -X stream -S slot_server1 -P -v -R

transaction log start point: 144/F3000028 on timeline 17

pg_basebackup: starting background WAL receiver

10503022/10503022 kB (100%), 1/1 tablespace

transaction log end point: 144/F3000130

pg_basebackup: waiting for background process to finish streaming ...

pg_basebackup: base backup completed

(4) recovery.con fの修正

旧マスタにて実行します。

pg _b aseb acku pにて-Rオプションを指定した事で、reco very.con fが作成されます。

スロットを指定している事から、primary_slot_n ameの指定があります。以下を追記します。

recovery_targ et_timelin eパラメータ

primary_co n n infパラメータにapp licatio n _nameを追加（任意／デフォルトはw alreceiver）

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=rep_user host=server2 port=5432 sslmode=prefer sslcompression=1'

primary_slot_name = 'slot_server1'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=rep_user host=server2 port=5432 application_name=slave_server1

asslmode=prefer sslcompression=1'

primary_slot_name = 'slot_server1'

recovery_target_timeline = latest

(5) 旧マスタのp o stgresql.co n fの修正

旧マスタにて、パラメータの調整を行います。

syn ch ro n o u s_stan d b y_n amesパラメータの無効化

pg _statsin foの無効化(有効化されている場合）

同期レプリケーションの設定を無効化します。

PostgreSQL Enterprise Consortium

Page 44 of 285

新スレーブのsh ared _prelo ad_lib rariesパラメータに p g _statsinfoが設定されている場合は、書き込みができずにエラーが発生します。

pg _statsin foの指定を削除します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_standby_names = '*'

shared_preload_libraries = 'pg_stat_statements,pg_statsinfo'

[編集後]

synchronous_standby_names = ''

shared_preload_libraries = ''

(6) 新スレーブの起動

新スレーブを起動します。

$ pg_ctl start

(7) 新マスタでのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 11262

usesysid | 16384

usename | rep_user

application_name | slave_server1

client_addr | <新スレーブIP>

client_hostname |

client_port | 44548

backend_start | 2017-03-22 06:36:06.362576+09

backend_xmin | 1781

state | streaming --- ストリーミング中

sent_location | 0/10000060

write_location | 0/10000060

flush_location | 0/10000060

replay_location | 0/10000000

sync_priority | 2

sync_state | async --- 非同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

active | t --- アクティブ

(8) レプリケーション方式を同期式に変更

新マスタにて、syn ch ro n ou s_stan d b y_n amesパラメータを設定し、リロードで反映します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_standby_names = ''

[編集後]

synchronous_standby_names = '*'

$ pg_ctl reload

PostgreSQL Enterprise Consortium

Page 45 of 285

$ psql -h server2 -U postgres postgres -c "SELECT * FROM pg_stat_replication" -x

-[ RECORD 1 ]----+------------------------------

pid | 11262

usesysid | 16384

usename | rep_user

application_name | s1

client_addr | <新スレーブIP>

client_hostname |

client_port | 44548

backend_start | 2017-03-22 06:36:06.362576+09

backend_xmin | 1781

state | streaming --- ストリーミング中

sent_location | 0/10000060

write_location | 0/10000060

flush_location | 0/10000060

replay_location | 0/10000000

sync_priority | 2

sync_state | sync --- 同期

これにて、以下の構成に復旧しました。

レプリケーションスロット使用

同期式レプリケーション構成

5.4.2.3. スイッチオーバスイッチオーバ

スイッチオーバについて記載します。

■スイッチオーバ手順

計画停止におけるマスタ/スレーブの切り替え手順です。 p g _baseb acku p やpg_rew ind が不要であるためシンプルな手順です。

計画停止にてマスタとスレーブの役割を切り替えたレプリケーション構成図

(1) マスタの正常停止

マスタにて実行します。

$ pg_ctl stop -m fast

(2) スレーブの昇格

スレーブにて実行します。

以下の場合にはpg _rew in d 不要です。

計画停止

同期レプリケーションのインスタンス障害(物理障害なし）

$ pg_ctl promote

以降の手順はフェイルオーバの場合と同様であるため省略します。

3. レプリケーションスロットの作成

4. recovery.con fの作成

PostgreSQL Enterprise Consortium

Page 46 of 285

5. 旧マスタのpo stg resq l.con fの修正

6. 新スレーブの起動

7. 新マスタでのレプリケーション確認

8. レプリケーション方式を同期式に変更

(9) レプリケーションスロットの削除(スレーブ）

フェイルオーバとの違いとしては、新スレーブに旧マスタ時代のスロットが残る事があります。

restart_lsn列に値が残っている状態では、マスタのVACUU M 処理を阻害するなどの

悪影響の可能性があるため、削除します。

スロットの削除は関数で行うため、スレーブでも実行可能です。

$ psql

=# SELECT pg_drop_replication_slot('slot_server2');

pg_create_physical_replication_slot

-------------------------------------

(1 row)

=# SELECT slot_name FROM pg_replication_slots ;

(0 rows)

以上でスイッチオーバが完了しました。

5.4.2.4. スイッチバックスイッチバック

pg _rew in dを使用したスイッチバックについて記載します。

pg _rew in dはタイムラインのずれたレプリケーションを再同期させる機能です。実行後、ターゲットクラスタはソースクラスタと置き換えられた状態になります。そのため

pg _rew in d後の操作は、通常のフェイルオーバ時と同じです。タイムラインの分岐点からソースクラスタのW ALを適用するため、更新量が少なければpg_basebackによる

複製より高速です。これによりフェイルオーバ時、旧マスタを容易に新スレーブとして起動させることができます。

スイッチオーバー後に役割を元に戻したレプリケーション構成図

■関連パラメータ

pg _rew in dに必要な設定を記載します。

表 5.20 p g _rew ind に必要な設定

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値内容内容

マスタ postgresq l.con f full_p age_w rites on チェックポイント後の更新時、ディスクページの全内容をW ALに書き込

む。

マスタ postgresq l.con f w al_log_h ints on ヒントビット更新時もfu ll_p age_w ritesを実行する。

■p g _rew indコマンド

PostgreSQL Enterprise Consortium

Page 47 of 285

pg _rew in dコマンドのの主なオプションは次の通りです。

表 5.21 p g _rew ind のオプション

オプションオプション内容内容

D <ターゲットクラスタ> pg _rew in dを実行し、ソースクラスタの内容に置き換えるクラスタを指定する。

sou rce-server= "<ソースクラスタ> "

同期対象であるソースクラスタを指定します。主に次の接続文字列を使用します。

h ost：ソースクラスタのホスト名またはIPアドレス

po rt：ソースクラスタのポート番号

db n ame：ソースクラスタの接続先データベース名

u ser：ソースクラスタの接続先ユーザ

P 進行状況をレポートとして表示する。

■スイッチバック手順

※事前にマスタ/スレーブで(1) 関連パラメータの設定がされていることを前提とします。

(1) 旧マスタの正常停止

pg _rew in dを使用するには正常停止する必要があります。

停止した旧マスタを一旦起動した後、正常停止させます。

障害により正常に起動や停止ができない状態ではp g _rew indは使用できません。

その場合は、pg _b aseb acku pを使用します。

$ pg_ctl start -w

$ pg_ctl stop -m fast -w

(2) p g _rew indの実行

　旧マスタでp g_rew in d を実行する。

$ pg_rewind -D $PGDATA --source-server="host=server2 port=5432"

servers diverged at WAL position 0/5015B70 on timeline 1

rewinding from last common checkpoint at 0/5015B00 on timeline 1

Done!

(3) スレーブのrecovery.con fを編集

旧マスタの＄PG DATA配下にreco very.con fを作成し、以下を設定します。

$ vi $PGDATA/recovery.conf

[編集後]

standby_mode = 'on'

primary_conninfo = 'host=server2 port=5432 user=rep_user'

recovery_target_timeline = 'latest'

(4) 新スレーブを起動し、新マスタとタイムラインID が揃っていることを確認する。

タイムラインIDの取得には、p g _con tro ld ataコマンドを使用する。

厳密には最新チェックポイント実行時のタイムラインIDであるため、

タイムラインIDが揃っていないときは、マスタにてチェックポイント実行後、再確認します。

ssh 経由で実行する事で任意のノードから全データベースクラスタの情報が取得できる。

PostgreSQL Enterprise Consortium

Page 48 of 285

[新マスタ]

$ export LANG=C

$ pg_controldata | grep " TimeLineID"

Latest checkpoint's TimeLineID: 2

$ ssh server1 $PGHOME/bin/pg_controldata $PGDATA | grep " TimeLineID"

Latest checkpoint's TimeLineID: 2

■p g _rew ind使用時の注意点

正常停止が必要

pg _rew in dを実行するデータベースクラスタは正常終了しなければいけません。

物理障害等により正常停止できない場合、p g _rew in d は使用できません。p g _basebacku p を使用します。

同一タイムラインの場合は実施不可

pg _p romoteを実行せずに旧スレーブを新マスタにした場合、新マスタのタイムラインID は変わらないため、

新マスタと旧マスタのタイムラインIDは同じ状態です。

この場合は、p g _rew in d は実行できません。

実行時期と所要時間の関係

pg _rew in dによるフェイルバックの所要時間は２つの要素から構成されます。

Step 1.　pg_rew ind による巻き戻し（旧マスタのW ALを使用）

Step 2.　W AL適用による追い付き（新マスタのW ALを使用）

新マスタで大量更新がある場合は、Step1は短時間で終了してもStep2で時間がかかります。

結果として、p g _basebacku pの方が効率が良い場合もあり得ます。

また新マスタ昇格時のW ALが削除されている場合は、後述するようにStep2でエラーとなる可能性もあります。その場合はpg_basebacku p

が必要となります。

pg _rew in dはフェイルオーバー後、あまり時間を置かずに実行する事がポイントです。

旧マスタのW AL削除

旧マスタの巻き戻しに必要な旧マスタのW ALが削除されているいる場合、pg_rew in d は失敗します。

例えば旧マスタが障害により大量更新の途中で異常終了した場合などに発生します。

pg _rew in d実行時に次のようなエラーが発生します。

could not open file "/home/pg96/pg96_data/pg_xlog/0000000D00000002000000CF": No

such file or directory

could not find previous WAL record at 2/CF000140

Failure, exiting

pg _rew in dが成功するかどうかは検証(d ry-ru n オプション)にて事前に確認する事ができます。

$ pg_rewind -D $PGDATA --source-server="host=server2 port=5432" --dry-run

servers diverged at WAL position 0/5015B70 on timeline 1

rewinding from last common checkpoint at 0/5015B00 on timeline 1

Done!

| メッセージはdry-runオプションが無い場合と同じです。

| pg_rewindでエラーが発生する場合(スレーブのWAL削除）は、この検証にて確認できますが、

| pg_rewindでエラーが発生しないで、後から発生する場合（マスタのWAL削除）は検知できません。

| 検証の仕様について認識下さい。

新マスタのW AL削除

pg _rew in d後、新スレーブは新マスタのW ALを適用することで、新マスタと同期します。

新マスタに昇格時のW ALファイルが残っていない場合、新スレーブは追い付きができず、次のエラーがサーバログに出力され続けます。

PostgreSQL Enterprise Consortium

Page 49 of 285

対策としてレプリケーションスロットの有効化が有力ですが、新マスタのW AL領域の枯渇にご注意下さい。

ERROR: requested WAL segment 0000000D00000000000000F3 has already been removed

タイムラインの巻き戻し

pg _rew in dはPostgreSQ L9.6からタイムラインの巻き戻しができるよになっています。

これによりスプリットブレインが発生しても、新マスタをスレーブに戻すことが可能です。

pg _rew in dが不要な場合

pg _rew in dはターゲットとソースクラスタのタイムラインIDが分岐した場合に実行が必要です。

そのためタイムラインが枝分かれしなかった場合、pg_rew ind を実行する必要はありません。

例えばpg_rew in d 実行時に次のようなメッセージが出た場合、pg _rew in d は実行せずに、以降の操作を継続します。

servers diverged at WAL position 0/503A428 on timeline 2

no rewind required

5.4.2.5. スレーブ障害による対処スレーブ障害による対処

スレーブ障害時の緊急対応の必要性は、非同期モードが同期モードかによって異なります。

非同期モードの場合は、スレーブ障害がマスタの更新処理を阻害しないため、緊急対応は必要ありません。

とはいえ、シングル状態であるため早期にレプリケーション構成に復旧します。

同期モードの場合は、スレーブ障害によりマスタの更新処理が阻害されハング状態となりますスレーブ障害によりマスタの更新処理が阻害されハング状態となります。

$ psql -h server1 -U postgres postgres -c "INSERT INTO test1_t VALUES ( 1 )"

Cancel request sent

WARNING: canceling wait for synchronous replication due to user request

DETAIL: ** The transaction has already committed locally, but might not have been replicated to

the standby. **

INSERT 0 1

※Ctrl+Cをキーインする等、意図的にキャンセルしない限り、応答が返ってきません。

そのため、直ちに非同期に設定する必要があります。

非同期への切り替え処理は以降に示す様に再起動不要であるため、即時対応が可能です。

非同期への切り替えではなく、スレーブの再起動を試みる方法も考えられます。その方が効率的のようにも考えられます。

即座に起動できればその通りですが、起動に時間がかかる、あるいは物理的な障害で起動できない状態である事も考えられます。

そのような試行錯誤より、まずは確実にマスタのハング状態解消を優先します。

マスタの復旧後は、スレーブの復旧を試みます。

物理障害により起動できない場合は、フェイルバック処理と同様の作業を行います。

(1) スレーブの疑似障害発生

immed iateオプションにて停止、またはpo stg resプロセスのkillする事で擬似障害を発生させます。

スレーブにて実行します。

$ pg_ctl -w -m immediate stop

(2) スレーブの死活監視にて異常を検知

死活監視の方法には多数ありますが、ここではpg_isread yコマンドを使用します。

PostgreSQL Enterprise Consortium

Page 50 of 285

pg _isreadyコマンドはクライアントツールですので、任意のノードから実行できます。

$ pg_isready -h server2 -U postgres -d postgres

server2:5432 - no response

(3) 非同期モードに切り替え

syn ch ro n o u s_stan d b y_n amesパラメータを''に設定する事で、非同期の設定となります。

$ vi $PGDATA/postgresql.conf

[変更前]

synchronous_standby_names = '*'

[変更後]

synchronous_standby_names = ''

$ pg_ctl reload

(4) 非同期モードの確認

レプリケーションモードが非同期(asyn c)に変更された事を確認します。

$ psql -At -c "SELECT sync_state FROM pg_stat_replication;"

async

これでマスタが更新処理が可能な状態に復旧しました。ただしシングル状態であるため、フェイルオーバと同様の作業を行います。

5.4.3. 障害時運用手順（複数スレーブ）障害時運用手順（複数スレーブ）

■同期モードについて

スレーブが複数ある場合、障害時にどのスレーブを新マスタに昇格するかが重要になります。基本的には同期運用しているスレーブを昇格すべきですが、同期対象も複数

選べるため、どの同期スレーブを優先するかが問題です。

これに対しPostgreSQ Lは、通常の同期運用では、同期優先度を明確にすることで、昇格すべきスレーブを絞っています。しかし同期優先度が明確な場合、同期対象ス

レーブの性能に、マスタ側も大きく影響を受けます。そのため複数同期においても、最も処理が進んでいるスレーブを同期対象とすることでスレーブの影響を抑えるクォーラム

コミットという機能が用意されています。

ただしクォーラムコミットの場合、最も同期が進んでいるスレーブがその時によって異なるため、運用に工夫が必要です。性能面と運用面のトレードオフを考慮した上で、同

期モードを選択する必要があります。

通常の同期

synchronous_standby_names = 'FIRST X (standby_name1, standby_name2, ...)'

通常の同期モードで運用する場合、上記のようにsyn ch ro n ou s_stan d b y_namesを設定します。 FIRSTは通常の同期モードの選択であり、省略可能です。数字Xは

同期対象のスレーブ数であり、カッコ内の左から順に優先して同期対象になります。カッコ内のスレーブ名は、同期候補のスレーブです。

以下のような設定の場合、slave1～3が同期運用、slave4～5は潜在的な同期運用がされます。潜在的な同期運用は、普段は非同期として運用され、必要な場合

は同期へ昇格されます。例えばslave2の環境がマスタから切断された場合、残ったスレーブで優先度が高いslave1,slave3,sla ve4が同期運用されます。 (つまり非同期

運用であったslave4が同期運用へ昇格されます)

synchronous_standby_names = 'FIRST 3 (slave1, slave2, slave3, slave4, slave5)'

障害発生時は、同期の優先度が高いスレーブを新マスタへ昇格させます。通常の同期モードではカッコ内の左側が優先度が高く、右に行くほど優先度が低くなります。

クォーラムコミット

synchronous_standby_names = 'ANY X (standby_name1, standby_name2, ...)'

クォーラムコミットで運用する場合、上記のようにsyn ch ro n o u s_stan d by_namesを設定します。 ANYはクォーラムコミットの選択であり、こちらは省略できません。数字X

は同期対象のスレーブ数であり、カッコ内のうちX台のスレーブの同期を待ちます。カッコ内のスレーブ名は、同期候補のスレーブです。

以下のような設定の場合、slave1～5の全てがクォーラムコミットで運用されます。マスタ側で更新があった場合、slave1～5のうちいずれか計3台でマスタからの更新反映

PostgreSQL Enterprise Consortium

Page 51 of 285

が完了すれば、同期したとみなします。

synchronous_standby_names = 'ANY 3 (slave1, slave2, slave3, slave4, slave5)'

障害発生時、新マスタへ昇格させるスレーブを選択するのには注意が必要です。確認方法は「SELECT p g_con trol_reco very();」コマンドにより現在のW AL位置を比

較することです。同期が進んでいる側はW ALも進んでいます。これにより判断が可能です。

■前提

以降の手順では次の前提とします。

Po stg reSQ L 10

マスタ、2台スレーブの計3台構成（ホスト名をそれぞれ server1,server2,slave3と表記する）

同期モードは同期（syn ch ro n o u s_co mmit = on または remo te_apply)

同期にはクォーラムコミットを使用（syn ch ro n o u s_stan d b y_n ames = 'ANY 1 (slave_server2, slave_server3)'）

スレーブはホットスタンバイ機能により参照可能 (ho t_stand b y = on )

レプリケーション用のユーザは rep _user

マスタ/スレーブとも、portは5432を使用

レプリケーションスロット使用

マスタ/スレーブとも、環境変数PG D ATA,PG PO R Tは設定済み

死活監視は実際の運用ではクラスタソフトを使用するのが一般的だが、ここでは便宜上手動で実施

サーバのNICはパブリックのみ

仮想IPについては考慮しない

■対処一覧大別すると4種類の対処方法が考えられます。

表 5.22 状況別の対処

障害箇障害箇

所所障害状況障害状況対処対処

1 マスタマスタとスレーブの関係が崩れており再構成が必要

物理障害

pro mo teを伴わないスレーブのマスタ化(reco very.con f削除）

pg _b aseb acku pコマンドを使用してフェイルバック

2 マスタマスタとスレーブの関係は巻き戻しで復旧可能

非同期レプリケーションのインスタンス障害（差異がある状態で昇格）

スプリットブレイン状態での旧マスタへの更新

pg _rew in dコマンドを使用してスイッチバック

3 マスタマスタとスレーブの切り替え可能

計画停止

同期レプリケーションのインスタンス障害(物理障害なし）

pg _rew in dコマンドを使用しないでスイッチバック

4 スレーブマスタとスレーブの連携再開可能

スレーブの障害

同期式の場合、残ったスレーブを非同期式に切り替え

5.4.3.1. フェイルオーバフェイルオーバ(複数スレーブ複数スレーブ )

フェイルオーバについて記載します。

次のような状況を想定しています。

server1:マスタ　 → 障害により停止

server2:スレーブ → 新マスタへ昇格

server3:スレーブ → マスタからのW AL転送が途絶えたたえめ、更新が停止

マスタにて、障害が発生した場合のスレーブを新マスタへ昇格したシングル構成図

PostgreSQL Enterprise Consortium

Page 52 of 285

(1) マスタの疑似障害発生

immed iateオプションにて停止、またはpo stg resプロセスのkillする事で擬似障害を発生させます。

マスタ(server1)にて実行します。

$ pg_ctl -w -m immediate stop

$ kill -9 `head -1 $PGDATA/postmaster.pid`

(2) マスタの死活監視にて異常を検知

死活監視の方法には多数ありますが、ここではpg_isread yコマンドを使用します。

pg _isreadyコマンドはクライアントツールですので、任意のノードから実行できます。

$ pg_isready -h server1 -U postgres -d postgres

server1:5432 - no response

(3) 昇格対象のスレーブ決定

クォーラムコミットの場合、現在のW AL位置を確認し、新マスタへ昇格すべきスレーブを特定します。

両方のスレーブ(server1,slave2)にて実行し、結果を比較します。

※通常の同期モードでは、優先度の高いスレーブが昇格対象なため、本操作は必要ありません。

[server2]

=# SELECT pg_control_recovery();

pg_control_recovery

--------------------------

(0/1301F348,1,0/0,0/0,f)

(1 row)

[server3]

=# SELECT pg_control_recovery();

pg_control_recovery

--------------------------

(0/1301F170,1,0/0,0/0,f)

(1 row)

※WALはserver2が進んでいるため、server2を昇格させる。

server1:1301F348

server2:1301F170

(4) スレーブを新マスタへ昇格

旧スレーブ(server2)で実行します。

$ pg_ctl promote

※サーバログに下記内容が記載されること

"d a tab ase system is ready to accept co n n ection s"

ただしこの時点ではsyn ch ro n ou s_stan d b y_namesパラメータに値が設定されている場合、新マスタで更新処理ができない状態です。

(5) 新マスタを非同期に切り替え

syn ch ro n o u s_stan d b y_n amesパラメータの設定を''に設定し、リロードで反映します。

新マスタ(server2)で実行します。

PostgreSQL Enterprise Consortium

Page 53 of 285

$ vi $PGDATA/postgresql.conf

[編集後]

synchronous_standby_names = ''

$ pg_ctl reload

これで更新処理ができる状態になりました。

(6) 新マスタの死活監視にて正常を確認

$ pg_isready -h server2 -U postgres -d postgres

server2:5432 - accepting connections

以上でファイルオーバーは完了です。

5.4.3.2. フェイルバックフェイルバック (複数スレーブ複数スレーブ )

pg _b aseb acku pを使用したフェイルバックについて記載します。昇格されなかったスレーブは、新マスタのスレーブとして運用するために再設定が必要です。旧マスタから

新スレーブへの構築は初期構築手順とほぼ同じです。

マスタ障害発生によるフェイルオーバ後、旧マスタを新スレーブとしたレプリケーション構成図

■パラメータ

pg _b aseb acku pに必要な設定を記載します。

表 5.23 p g _baseb acku p に必要な設定

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値内容内容

マスタ po stg resq l.con f listen _add ress 0.0.0.0 全てのIPアドレス(v4)からの接続を受け付ける

マスタ po stg resq l.con f max_w al_send ers 2 W ALストリームオプションを付与する場合は、2以上を設定

■p g _baseb acku p コマンド

pg _b aseb acku pコマンドの主なオプションは次の通りです。

PostgreSQL Enterprise Consortium

Page 54 of 285

表 5.24 p g _baseb acku p のオプション

オプションオプション内容内容

-D < d irecto ry> 出力を書き出すディレクトリを指定。

-X < meth o d>

--xlog-meth o d = < metho d >

必要なW ALファイルをバックアップに含める。metho d (収集方式)は以下から選択。

fetch ：W ALファイルは最後に収集

stream：バックアップ作成中に同時にW ALをストリームで収集

運用中にp g _baseb acku p を実行する場合には stream を指定する。

fetch （最後に収集）では、必要なW ALファイルが削除される可能性があるため。

-S < slot_n ame>

--slo t=< slo t_n ame>

W ALストリーミングの収集に指定したレプリケーションスロットを使用。

-X stream とセットで指定。

必要なW ALファイルが削除されるのを防ぐ事を目的とする。

運用中にp g _baseb acku p を実行する場合に使用を検討する。

以下に注意する。

事前にレプリケーションスロットを作成する必要がある

マスタのW AL領域の空きが十分である事を確認する

-R

--w rite-reco very-co n f

最低限のreco very.con fを作成。必要に応じてreco very.co n fを加筆修正。

-r < rate>

--max-rate=< rate>

サーバから転送されるデータの最大転送速度を指定。

運用中にp g _baseb acku p を実行する場合に使用を検討する。

転送速度を抑える事で、マスタに対する影響を制限する事を目的とする。

-P 進行状況報告を有効化。

pg _b aseb acku p処理中におおよその進行状況を報告する。

運用中に実行した場合、データベースクラスタのサイズが増加して進行状況が100%を超える場合があ

る。

-v 冗長モードを有効化。

進行状況報告も有効な場合、現在処理中のファイル名を出力。

ります。スロットを使用する運用であれば、この段階で作成するのが有力です。

■フェイルバック手順

次のような状況を想定しています。

server1:旧マスタ　 → 新スレーブ

server2:旧スレーブ → 新マスタ

server3:旧スレーブ → 新スレーブ

pg _b aseb acku pにスロットを指定する場合を記載します。

(1) レプリケーションスロットの作成

新マスタ(server2)にて実行します。

$ psql

[server1:旧マスタ→新スレーブ用のレプリケーションスロット]

=# SELECT pg_create_physical_replication_slot('slot_server1',true);　　-- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server1,144/EEFC8940)

(1 行)

[server3:旧スレーブ→新スレーブ用のレプリケーションスロット]

=# SELECT pg_create_physical_replication_slot('slot_server3',true);　　-- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server3,144/EEFC8940)

(1 行)

PostgreSQL Enterprise Consortium

Page 55 of 285

(2) recovery.con fの修正

旧スレーブ(server3)にて実行します。p rimary_co n n in foに記載する接続先マスタの情報を新マスタ(server2)に書き換えます。

またレプリケーションスロット名が変更されている場合、変更後の名前に合わせます。

$ vi $PGDATA/recovery.conf

[編集前]

primary_conninfo = 'user=rep_user host=server1 port=5432 application_name=slave_server3

asslmode=prefer sslcompression=1'

[編集前]

primary_conninfo = 'user=rep_user host=server2 port=5432 application_name=slave_server3

asslmode=prefer sslcompression=1'

(3) 新スレーブの起動

旧スレーブ(server3)にて実行します。recovery.con f修正反映し、新スレーブとして再起動します。

$ pg_ctl restart

(4) 旧マスタのデータベースクラスタを削除

旧マスタ(server1)にて実行します。

$ rm -rf $PGDATA/*

※$PG DATA以外に表領域を作成している場合、そのファイルも削除します。

※$PG DATAディレクトリを削除する場合は、postgresユーザで$PGDATAディレクトリを作成できるよう

　親ディレクトリのオーナーまたはパーミッションを設定します。

(5) p g _basebacku p コマンドにて、新マスタからデータベースクラスタをコピー

旧マスタ(server1)にて実行します。

$ pg_basebackup -h server2 -U rep_user -D $PGDATA -X stream -S slot_server1 -P -v -R

transaction log start point: 144/F3000028 on timeline 17

pg_basebackup: starting background WAL receiver

10503022/10503022 kB (100%), 1/1 tablespace

transaction log end point: 144/F3000130

pg_basebackup: waiting for background process to finish streaming ...

pg_basebackup: base backup completed

(6) recovery.con fの修正

旧マスタ(server1)にて実行します。

pg _b aseb acku pにて-Rオプションを指定した事で、reco very.con fが作成されます。

スロットを指定している事から、primary_slot_n ameの指定があります。以下を追記します。

recovery_targ et_timelin eパラメータ

primary_co n n infパラメータにapp licatio n _nameを追加（任意／デフォルトはw alreceiver）

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=rep_user host=server2 port=5432 sslmode=prefer sslcompression=1'

primary_slot_name = 'slot_server1'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=rep_user host=server2 port=5432 application_name=slave_server1

asslmode=prefer sslcompression=1'

primary_slot_name = 'slot_server1'

recovery_target_timeline = latest

(7) 旧マスタのp o stgresql.co n fの修正

PostgreSQL Enterprise Consortium

Page 56 of 285

旧マスタ(server1)にて、パラメータの調整を行います。

syn ch ro n o u s_stan d b y_n amesパラメータの無効化

pg _statsin foの無効化(有効化されている場合）

同期レプリケーションの設定を無効化します。

新スレーブのsh ared _prelo ad_lib rariesパラメータに p g _statsinfoが設定されている場合は、書き込みができずにエラーが発生します。

pg _statsin foの指定を削除します。

$ vi $PGDATA/postgresql.conf

[編集後]

synchronous_standby_names = ''

shared_preload_libraries = ''

(6) 新スレーブの起動

新スレーブを起動します。

$ pg_ctl start

(7) 新マスタでのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

PostgreSQL Enterprise Consortium

Page 57 of 285

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 1866

usesysid | 16384

usename | rep_user

application_name | slave_server3

client_addr | ::1

client_hostname |

client_port | 46840

backend_start | 2018-02-13 14:06:04.475996+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/B067570

write_lsn | 0/B067570

flush_lsn | 0/B067570

replay_lsn | 0/B067570

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

-[ RECORD 2 ]----+------------------------------

pid | 1776

usesysid | 16384

usename | rep_user

application_name | slave_server1

client_addr | ::1

client_hostname |

client_port | 46838

backend_start | 2018-02-13 14:05:53.580727+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/B067570

write_lsn | 0/B067570

flush_lsn | 0/B067570

replay_lsn | 0/B067570

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]----

slot_name | slot1

active | t --- アクティブ

-[ RECORD 2 ]----

slot_name | slot2

active | t --- アクティブ

(8) レプリケーション方式を同期式に変更

新マスタにて、syn ch ro n ou s_stan d b y_n amesパラメータを設定し、リロードで反映します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_standby_names = ''

[編集後]

synchronous_standby_names = 'ANY 1 (slave_server1, slave_server3)'

$ pg_ctl reload

PostgreSQL Enterprise Consortium

Page 58 of 285

$ psql -h server2 -U postgres postgres -c "SELECT * FROM pg_stat_replication" -x

-[ RECORD 1 ]----+------------------------------

pid | 1866

usesysid | 16384

usename | rep_user

application_name | slave2

client_addr | ::1

client_hostname |

client_port | 46840

backend_start | 2018-02-13 14:06:04.475996+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/B067570

write_lsn | 0/B067570

flush_lsn | 0/B067570

replay_lsn | 0/B067570

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | quorum --- クォーラムコミット

-[ RECORD 2 ]----+------------------------------

pid | 1776

usesysid | 16384

usename | rep_user

application_name | slave1

client_addr | ::1

client_hostname |

client_port | 46838

backend_start | 2018-02-13 14:05:53.580727+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/B067570

write_lsn | 0/B067570

flush_lsn | 0/B067570

replay_lsn | 0/B067570

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | quorum --- クォーラムコミット

これにて、以下の構成に復旧しました。

レプリケーションスロット使用

同期式レプリケーション構成

5.4.3.3. スイッチオーバスイッチオーバ (複数スレーブ複数スレーブ )

スイッチオーバについて記載します。

■スイッチオーバ手順

計画停止におけるマスタ/スレーブの切り替え手順です。 p g _baseb acku p やpg_rew ind が不要であるためシンプルな手順です。

次のような状況を想定しています。

server1:マスタ　 → 新スレーブ

server2:スレーブ → 新マスタ

server3:スレーブ → 新スレーブ

計画停止にてマスタとスレーブの役割を切り替えたレプリケーション構成図

PostgreSQL Enterprise Consortium

Page 59 of 285

(1) マスタの正常停止

マスタ(server1)にて実行します。

$ pg_ctl stop -m fast

(2) スレーブの昇格

スレーブ(server2)にて実行します。

以下の場合にはpg _rew in d 不要です。

計画停止

同期レプリケーションのインスタンス障害(物理障害なし）

$ pg_ctl promote

以降の手順はフェイルオーバの場合と同様であるため省略します。

3. レプリケーションスロットの作成

4. recovery.con fの作成

5. 旧マスタのpo stg resq l.con fの修正

6. 新スレーブの起動

7. 新マスタでのレプリケーション確認

8. レプリケーション方式を同期式に変更

(9) レプリケーションスロットの削除(スレーブ）

フェイルオーバとの違いとしては、新スレーブ(server1)に旧マスタ時代のスロットが残る事があります。

restart_lsn列に値が残っている状態では、マスタのVACUU M 処理を阻害するなどの

悪影響の可能性があるため、削除します。

スロットの削除は関数で行うため、スレーブでも実行可能です。

$ psql

=# SELECT pg_drop_replication_slot('slot_server2');

pg_create_physical_replication_slot

-------------------------------------

(1 row)

=# SELECT pg_drop_replication_slot('slot_server3');

pg_create_physical_replication_slot

-------------------------------------

(1 row)

=# SELECT slot_name FROM pg_replication_slots ;

(0 rows)

以上でスイッチオーバが完了しました。

5.4.3.4. スイッチバックスイッチバック (複数スレーブ複数スレーブ )

PostgreSQL Enterprise Consortium

Page 60 of 285

pg _rew in dを使用したスイッチバックについて記載します。

pg _rew in d後の操作は、通常のフェイルオーバ時と同じです。タイムラインの分岐点からソースクラスタのW ALを適用するため、更新量が少なければpg_basebacku p に

よる複製より高速です。これによりフェイルオーバ時、旧マスタを容易に新スレーブとして起動させることができます。

スイッチオーバー後に役割を元に戻したレプリケーション構成図

■関連パラメータ

pg _rew in dに必要な設定を記載します。

表 5.25 p g _rew ind に必要な設定

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値内容内容

マスタ postgresq l.con f full_p age_w rites on チェックポイント後の更新時、ディスクページの全内容をW ALに書き込

む。

マスタ postgresq l.con f w al_log_h ints on ヒントビット更新時もfu ll_p age_w ritesを実行する。

■p g _rew indコマンド

pg _rew in dコマンドのの主なオプションは次の通りです。

表 5.26 p g _rew ind のオプション

オプションオプション内容内容

D <ターゲットクラスタ> pg _rew in dを実行し、ソースクラスタの内容に置き換えるクラスタを指定する。

sou rce-server= "<ソースクラスタ> "

同期対象であるソースクラスタを指定します。主に次の接続文字列を使用します。

h ost：ソースクラスタのホスト名またはIPアドレス

po rt：ソースクラスタのポート番号

db n ame：ソースクラスタの接続先データベース名

u ser：ソースクラスタの接続先ユーザ

P 進行状況をレポートとして表示する。

■スイッチバック手順

※事前にマスタ/スレーブで(1) 関連パラメータの設定がされていることを前提とします。

(1) 旧マスタの正常停止

pg _rew in dを使用するには正常停止する必要があります。

停止した旧マスタを一旦起動した後、正常停止させます。

障害により正常に起動や停止ができない状態ではp g _rew indは使用できません。

その場合は、pg _b aseb acku pを使用します。

PostgreSQL Enterprise Consortium

Page 61 of 285

$ pg_ctl start -w

$ pg_ctl stop -m fast -w

(2) p g _rew indの実行

　旧マスタでp g_rew in d を実行する。

$ pg_rewind -D $PGDATA --source-server="host=server2 port=5432"

servers diverged at WAL position 0/5015B70 on timeline 1

rewinding from last common checkpoint at 0/5015B00 on timeline 1

Done!

(3) スレーブのrecovery.con fを編集

旧マスタの＄PG DATA配下にreco very.con fを作成し、以下を設定します。

$ vi $PGDATA/recovery.conf

[編集後]

standby_mode = 'on'

primary_conninfo = 'host=server2 port=5432 user=rep_user'

recovery_target_timeline = 'latest'

(4) 新スレーブを起動し、新マスタとタイムラインID が揃っていることを確認する。

タイムラインIDの取得には、p g _con tro ld ataコマンドを使用する。

厳密には最新チェックポイント実行時のタイムラインIDであるため、

タイムラインIDが揃っていないときは、マスタにてチェックポイント実行後、再確認します。

ssh 経由で実行する事で任意のノードから全データベースクラスタの情報が取得できる。

[新マスタ]

$ export LANG=C

$ pg_controldata | grep " TimeLineID"

Latest checkpoint's TimeLineID: 2

$ ssh server1 $PGHOME/bin/pg_controldata $PGDATA | grep " TimeLineID"

Latest checkpoint's TimeLineID: 2

■p g _rew ind使用時の注意点

正常停止が必要

pg _rew in dを実行するデータベースクラスタは正常終了しなければいけません。

物理障害等により正常停止できない場合、p g _rew in d は使用できません。p g _basebacku p を使用します。

同一タイムラインの場合は実施不可

pg _p romoteを実行せずに旧スレーブを新マスタにした場合、新マスタのタイムラインID は変わらないため、

新マスタと旧マスタのタイムラインIDは同じ状態です。

この場合は、p g _rew in d は実行できません。

実行時期と所要時間の関係

pg _rew in dによるフェイルバックの所要時間は２つの要素から構成されます。

Step 1.　pg_rew ind による巻き戻し（旧マスタのW ALを使用）

Step 2.　W AL適用による追い付き（新マスタのW ALを使用）

PostgreSQL Enterprise Consortium

Page 62 of 285

新マスタで大量更新がある場合は、Step1は短時間で終了してもStep2で時間がかかります。

結果として、p g _basebacku pの方が効率が良い場合もあり得ます。

また新マスタ昇格時のW ALが削除されている場合は、後述するようにStep2でエラーとなる可能性もあります。その場合はpg_basebacku p

が必要となります。

pg _rew in dはフェイルオーバー後、あまり時間を置かずに実行する事がポイントです。

旧マスタのW AL削除

旧マスタの巻き戻しに必要な旧マスタのW ALが削除されているいる場合、pg_rew in d は失敗します。

例えば旧マスタが障害により大量更新の途中で異常終了した場合などに発生します。

pg _rew in d実行時に次のようなエラーが発生します。

could not open file "/home/pg96/pg96_data/pg_xlog/0000000D00000002000000CF": No

such file or directory

could not find previous WAL record at 2/CF000140

Failure, exiting

pg _rew in dが成功するかどうかは検証(d ry-ru n オプション)にて事前に確認する事ができます。

$ pg_rewind -D $PGDATA --source-server="host=server2 port=5432" --dry-run

servers diverged at WAL position 0/5015B70 on timeline 1

rewinding from last common checkpoint at 0/5015B00 on timeline 1

Done!

| メッセージはdry-runオプションが無い場合と同じです。

| pg_rewindでエラーが発生する場合(スレーブのWAL削除）は、この検証にて確認できますが、

| pg_rewindでエラーが発生しないで、後から発生する場合（マスタのWAL削除）は検知できません。

| 検証の仕様について認識下さい。

新マスタのW AL削除

pg _rew in d後、新スレーブは新マスタのW ALを適用することで、新マスタと同期します。

新マスタに昇格時のW ALファイルが残っていない場合、新スレーブは追い付きができず、次のエラーがサーバログに出力され続けます。

対策としてレプリケーションスロットの有効化が有力ですが、新マスタのW AL領域の枯渇にご注意下さい。

ERROR: requested WAL segment 0000000D00000000000000F3 has already been removed

タイムラインの巻き戻し

pg _rew in dはPostgreSQ L9.6からタイムラインの巻き戻しができるよになっています。

これによりスプリットブレインが発生しても、新マスタをスレーブに戻すことが可能です。

pg _rew in dが不要な場合

pg _rew in dはターゲットとソースクラスタのタイムラインIDが分岐した場合に実行が必要です。

そのためタイムラインが枝分かれしなかった場合、pg_rew ind を実行する必要はありません。

例えばpg_rew in d 実行時に次のようなメッセージが出た場合、pg _rew in d は実行せずに、以降の操作を継続します。

servers diverged at WAL position 0/503A428 on timeline 2

no rewind required

5.4.3.5. スレーブ障害による対処スレーブ障害による対処 (複数スレーブ複数スレーブ )

スレーブ障害時の緊急対応の必要性は、非同期モードが同期モードかによって異なります。

非同期モードの場合は、スレーブ障害がマスタの更新処理を阻害しないため、緊急対応は必要ありません。

とはいえ、シングル状態であるため早期にレプリケーション構成に復旧します。

同期モードの場合、稼働しているスレーブ数が、同期対象のスレーブ数より下回った場合、スレーブ障害によりマスタの更新処理が阻害されハング状態となりますスレーブ障害によりマスタの更新処理が阻害されハング状態となります。

PostgreSQL Enterprise Consortium

Page 63 of 285

$ psql -h server1 -U postgres postgres -c "INSERT INTO test1_t VALUES ( 1 )"

Cancel request sent

WARNING: canceling wait for synchronous replication due to user request

DETAIL: ** The transaction has already committed locally, but might not have been replicated to

the standby. **

INSERT 0 1

※Ctrl+Cをキーインする等、意図的にキャンセルしない限り、応答が返ってきません。

そのため、直ちに非同期に設定する、または同期対象のスレーブ数設定を減らす必要があります。

非同期への切り替え処理は以降に示す様に再起動不要であるため、即時対応が可能です。

非同期への切り替えではなく、スレーブの再起動を試みる方法も考えられます。その方が効率的のようにも考えられます。

即座に起動できればその通りですが、起動に時間がかかる、あるいは物理的な障害で起動できない状態である事も考えられます。

そのような試行錯誤より、まずは確実にマスタのハング状態解消を優先します。

マスタの復旧後は、スレーブの復旧を試みます。

物理障害により起動できない場合は、フェイルバック処理と同様の作業を行います。

(1) スレーブの疑似障害発生

immed iateオプションにて停止、またはpo stg resプロセスのkillする事で擬似障害を発生させます。

スレーブにて実行します。

$ pg_ctl -w -m immediate stop

(2) スレーブの死活監視にて異常を検知

死活監視の方法には多数ありますが、ここではpg_isread yコマンドを使用します。

pg _isreadyコマンドはクライアントツールですので、任意のノードから実行できます。

$ pg_isready -h server2 -U postgres -d postgres

server2:5432 - no response

(3) 非同期モードに切り替え

syn ch ro n o u s_stan d b y_n amesパラメータを''に設定する事で、非同期の設定となります。

$ vi $PGDATA/postgresql.conf

[変更前]

synchronous_standby_names = 'FIRST X (standby_name1, standby_name2, ...)'

[変更後]

synchronous_standby_names = ''

$ pg_ctl reload

(4) 非同期モードの確認

レプリケーションモードが非同期(asyn c)に変更された事を確認します。

$ psql -At -c "SELECT sync_state FROM pg_stat_replication;"

async

これでマスタが更新処理が可能な状態に復旧しました。ただしシングル状態であるため、フェイルオーバと同様の作業を行います。

PostgreSQL Enterprise Consortium

Page 64 of 285

5.4.4. 障害時運用手順（カスケード構成）障害時運用手順（カスケード構成）

■前提以降の手順では次の前提とします。

Po stg reSQ L 10.1

マスタ、スレーブ1、スレーブ2の3台のカスケード構成（ホスト名をそれぞれ server1,server2,server3と表記する）

スレーブ1が同期モード（syn ch ro n o u s_co mmit= o n , syn ch ro n o u s_stan d by_names= 'server2')

スレーブ2が非同期モード（syn ch ron o u s_co mmit= o ff, syn ch ro n o u s_stan d b y_n ames= ''）

スレーブはホットスタンバイ機能により参照可能 (ho t_stand b y = on )

レプリケーション用のユーザは rep u ser

マスタ/スレーブとも、portは5432を使用

レプリケーションスロット使用

マスタ/スレーブとも、環境変数PG D ATA,PG PO R Tは設定済み

死活監視は実際の運用ではクラスタソフトを使用するのが一般的ですが、ここでは便宜上手動で実施

サーバのNICはパブリックのみ

仮想IPについては考慮しない

■対処一覧大別すると3種類の対処方法が考えられます。

表 5.27 障害別の対処

障害箇障害箇

所所障害状況障害状況 pg_basebackupとと pg_rew indの使い分けの使い分け

1 マスタマスタとスレーブの関係が崩れており再構成が必要

物理障害

pro mo teを伴わないスレーブのマスタ化(reco very.con f削除）

pg _b aseb acku pコマンドを使用してフェイルバック

2 マスタマスタとスレーブの関係は巻き戻しで復旧可能

非同期レプリケーションのインスタンス障害（差異がある状態で昇格）

スプリットブレイン状態での旧マスタへの更新

pg _rew in dコマンドを使用してスイッチバック

3 マスタマスタとスレーブの切り替え可能

計画停止

同期レプリケーションのインスタンス障害(物理障害なし）

pg _rew in dコマンドを使用しないでスイッチバック

4 スレーブ1 マスタとスレーブの連携再開可能

スレーブの障害

同期式の場合は非同期式に切り替え

5 スレーブ1 マスタとスレーブの連携再開不可能

スレーブの障害

pg _b aseb acku pコマンドを使用してフェイルバック

6 スレーブ2 マスタとスレーブの連携再開可能

スレーブの障害

pg _rew in dコマンドを使用しないでフェイルバック

7 スレーブ2 マスタとスレーブの連携再開不可能

スレーブの障害

pg _b aseb acku pコマンドを使用してフェイルバック

8 マスタ、ス

レーブ1

マスタとスレーブ2の連携再開可能

マスタ、スレーブ1の障害

pg _rew in dコマンドを使用しないでフェイルバック

9 マスタ、ス

レーブ1

マスタとスレーブ2の連携再開不可能

スレーブの障害

pg _b aseb acku pコマンドを使用してフェイルバック

5.4.4.1. フェイルオーバフェイルオーバ

フェイルオーバについて記載します。

5.4.4.2. 同期スレーブへのフェイルオーバ同期スレーブへのフェイルオーバ

PostgreSQL Enterprise Consortium

Page 65 of 285

マスタ(server1)にて、障害が発生した場合にスレーブ1(server2)を新マスタへ昇格した構成図

(1) マスタ(server1)の疑似障害発生

immed iateオプションにて停止、またはpo stg resプロセスのkillする事で擬似障害を発生させます。

マスタ(server1)にて実行します。

$ pg_ctl -w -m immediate stop

$ kill -9 `head -1 $PGDATA/postmaster.pid`

(2) マスタ(server1)の死活監視にて異常を検知

死活監視の方法には多数ありますが、ここではpg_isread yコマンドを使用します。

pg _isreadyコマンドはクライアントツールですので、任意のノードから実行できます。

$ pg_isready -h server1 -U postgres -d postgres

server1:5432 - no response

(3) スレーブ1(server2)を新マスタへ昇格

スレーブ1(server2)で実行します。

$ pg_ctl promote

※サーバログに下記内容が記載されること

"d a tab ase system is ready to accept co n n ection s"

(4) 新マスタ(server2)の死活監視にて正常を確認

$ pg_isready -h server2 -U postgres -d postgres

server2:5432 - accepting connections

(5) スレーブ2(server3)の死活監視を確認

$ pg_isready -h server3 -U postgres -d postgres

server3:5432 - accepting connections

(6) 新マスタ(server2)にてデータ更新が行えることを確認

(7) スレーブ2(server3)にてデータが伝播されていることを確認

以上でファイルオーバーは完了です。

5.4.4.3. 非同期スレーブへのフェイルオーバ非同期スレーブへのフェイルオーバ

マスタ(server1)/スレーブ1(server2)サイトに障害が発生した場合のスレーブ2(server3)を新マスタへ昇格した構成図

PostgreSQL Enterprise Consortium

Page 66 of 285

(1) マスタ(server1)の疑似障害発生

immed iateオプションにて停止、またはpo stg resプロセスのkillする事で擬似障害を発生させます。

マスタ(server1)にて実行します。

$ pg_ctl -w -m immediate stop

$ kill -9 `head -1 $PGDATA/postmaster.pid`

(2) スレーブ1(server2)の疑似障害発生

immed iateオプションにて停止、またはpo stg resプロセスのkillする事で擬似障害を発生させます。

スレーブ1(server2)にて実行します。

$ pg_ctl -w -m immediate stop

$ kill -9 `head -1 $PGDATA/postmaster.pid`

(3) マスタ(server1)、スレーブ1(server2)の死活監視にて異常を検知

死活監視の方法には多数ありますが、ここではpg_isread yコマンドを使用します。

pg _isreadyコマンドはクライアントツールですので、任意のノードから実行できます。

$ pg_isready -h server1 -U postgres -d postgres

server1:5432 - no response

$ pg_isready -h server2 -U postgres -d postgres

server2:5432 - no response

(4) スレーブ2(server3)を新マスタへ昇格

スレーブ2(server3)で実行します。

$ pg_ctl promote

※サーバログに下記内容が記載されること

"d a tab ase system is ready to accept co n n ection s"

(5) 新マスタ(server3)の死活監視にて正常を確認

$ pg_isready -h server3 -U postgres -d postgres

server3:5432 - accepting connections

(6) 新マスタ(server3)にてデータ更新が行えることを確認

以上でファイルオーバーは完了です。

5.4.4.4. フェイルバックフェイルバック

フェイルバックについて記載します。

5.4.4.5. 旧マスタを同期モードスレーブとしてフェイルバック旧マスタを同期モードスレーブとしてフェイルバック

pg _b aseb acku pを使用したフェイルバックについて記載します。初期構築手順とほぼ同じです。

PostgreSQL Enterprise Consortium

Page 67 of 285

マスタ障害発生によるフェイルオーバ後、旧マスタを同期モード新スレーブとしたレプリケーション構成図

■関連パラメータ

pg _b aseb acku pに必要な設定を記載します。

表 5.28 p g _baseb acku p に必要な設定

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値内容内容

マスタ po stg resq l.con f listen _add ress 0.0.0.0 全てのIPアドレス(v4)からの接続を受け付ける

マスタ po stg resq l.con f max_w al_send ers 2 W ALストリームオプションを付与する場合は、2以上を設定

■p g _baseb acku p コマンド

pg _b aseb acku pコマンドの主なオプションは次の通りです。

表 5.29 p g _baseb acku p のオプション

オプションオプション内容内容

-D < d irecto ry> 出力を書き出すディレクトリを指定。

-X < meth o d>

--w al-metho d = < meth o d>

必要なW ALファイルをバックアップに含める。metho d (収集方式)は以下から選択。

fetch ：W ALファイルは最後に収集

stream：バックアップ作成中に同時にW ALをストリームで収集

運用中にp g _baseb acku p を実行する場合には stream を指定する。

fetch （最後に収集）では、必要なW ALファイルが削除される可能性があるため。

-S < slot_n ame>

--slo t=< slo t_n ame>

W ALストリーミングの収集に指定したレプリケーションスロットを使用。

-X stream とセットで指定。

必要なW ALファイルが削除されるのを防ぐ事を目的とする。

運用中にp g _baseb acku p を実行する場合に使用を検討する。

以下に注意する。

事前にレプリケーションスロットを作成する必要がある

マスタのW AL領域の空きが十分である事を確認する

-R

--w rite-reco very-co n f

最低限のreco very.con fを作成。必要に応じてreco very.co n fを加筆修正。

-r < rate>

--max-rate=< rate>

サーバから転送されるデータの最大転送速度を指定。

運用中にp g _baseb acku p を実行する場合に使用を検討する。

転送速度を抑える事で、マスタに対する影響を制限する事を目的とする。

-P 進行状況報告を有効化。

pg _b aseb acku p処理中におおよその進行状況を報告する。

運用中に実行した場合、データベースクラスタのサイズが増加して進行状況が100%を超える場合があ

る。

-v 冗長モードを有効化。

進行状況報告も有効な場合、現在処理中のファイル名を出力。

ります。スロットを使用する運用であれば、この段階で作成するのが有力です。

■フェイルバック手順

pg _b aseb acku pにスロットを指定する場合を記載します。

(1) 旧マスタ(server1)のデータベースクラスタを削除

PostgreSQL Enterprise Consortium

Page 68 of 285

旧マスタ(server1)にて実行します。

$ rm -rf $PGDATA/*

※$PG DATA以外に表領域を作成している場合、そのファイルも削除します。

※$PG DATAディレクトリを削除する場合は、postgresユーザで$PGDATAディレクトリを作成できるよう

親ディレクトリのオーナーまたはパーミッションを設定します。

(2) レプリケーションスロットの作成

新マスタ(server2)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server2',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server2,0/96000090)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server2

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/96000090 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(3) p g _basebacku p コマンドにて、新マスタ(server2)からデータベースクラスタをコピー

旧マスタ(server1)にて実行します。

$ pg_basebackup -h server2 -U repuser -D $PGDATA -X stream -S slot_server2 -P -v -R

pg_basebackup: initiating base backup, waiting for checkpoint to complete

pg_basebackup: checkpoint completed

pg_basebackup: write-ahead log start point: 0/99000028 on timeline 32

pg_basebackup: starting background WAL receiver

138336/138336 kB (100%), 1/1 tablespace

pg_basebackup: write-ahead log end point: 0/99000130

pg_basebackup: waiting for background process to finish streaming ...

pg_basebackup: base backup completed

(4) recovery.con fの修正

旧マスタ(server1)にて実行します。

pg _b aseb acku pにて-Rオプションを指定した事で、reco very.con fが作成されます。

スロットを指定している事から、primary_slot_n ameの指定があります。以下を追記します。

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

recovery_targ et_timelin eパラメータ追加

PostgreSQL Enterprise Consortium

Page 69 of 285

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server2'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

application_name=server1 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server2'

recovery_target_timeline = 'latest'

起動

$ pg_ctl start

(5) 新マスタ(server2)のpostg resql.con fの修正

新マスタ(server2)にて実行します。

syn ch ro n o u s_co mmitパラメータの有効化

syn ch ro n o u s_stan d b y_n amesパラメータの有効化

同期レプリケーションの設定を有効化します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = off

synchronous_standby_names = ''

[編集後]

synchronous_commit = on

synchronous_standby_names = 'server1'

設定を反映

$ pg_ctl reload

(6) レプリケーションスロットの作成

新スレーブ1(server1)にて実行します。

PostgreSQL Enterprise Consortium

Page 70 of 285

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server1',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server1,0/9A000060)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/9A000060 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(7) スレーブ2(server3)にてrecovery.con f修正

スレーブ2(server3)にて実行します。

primary_co n n infoパラメータの｢h o st= ｣部分を修正

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ追加

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

sslmode=disable sslcompression=1 target_session_attrs=any'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=5432

application_name=server3 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

recovery_target_timeline = 'latest'

再起動

$ pg_ctl restart

(8) 新マスタ(server2)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

PostgreSQL Enterprise Consortium

Page 71 of 285

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 46558

usesysid | 16384

usename | repuser

application_name | server1

client_addr | <server1IP>

client_hostname |

client_port | 64897

backend_start | 2018-02-09 11:22:23.535181+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/9A000140

write_lsn | 0/9A000140

flush_lsn | 0/9A000140

replay_lsn | 0/9A000140

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | sync --- 同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server2

active | t --- アクティブ

(9) 新スレーブ(server1)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 97277

usesysid | 16384

usename | repuser

application_name | server3

client_addr | <server3IP>

client_hostname |

client_port | 52882

backend_start | 2018-02-09 11:55:20.971553+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/9A000140

write_lsn | 0/9A000140

flush_lsn | 0/9A000140

replay_lsn | 0/9A000140

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

これにて、以下の構成に復旧しました。

レプリケーションスロット使用

server2(マスタ) = 同期=> server1(スレーブ1) = 非同期= > server3(スレーブ2) のカスケードレプリケーション構成

5.4.4.6. 旧マスタをインスタンス障害からフェイルバック旧マスタをインスタンス障害からフェイルバック

PostgreSQL Enterprise Consortium

Page 72 of 285

pg _b aseb acku pを使用したフェイルバックについて記載します。初期構築手順とほぼ同じです。

マスタインスタンス障害発生によるフェイルオーバ後、旧マスタを同期モード新スレーブとしたレプリケーション構成図

■フェイルバック手順

(1) スレーブ2(server3)を一旦停止

スレーブ2(server3)にて実行します。

$ pg_ctl stop

(2) レプリケーションスロットの作成

新マスタ(server2)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server2',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server2,0/96000090)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server2

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/96000090 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(3) recovery.con fの作成

旧マスタ(server1)にて実行します。

以下を設定します。

$ vi $PGDATA/recovery.conf

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

application_name=server1 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server2'

recovery_target_timeline = 'latest'

(4) 旧マスタ(server1)のpostg resql.con fの修正

PostgreSQL Enterprise Consortium

Page 73 of 285

旧マスタ(server1)にて、パラメータの調整を行います。

syn ch ro n o u s_co mmitパラメータの無効化

syn ch ro n o u s_stan d b y_n amesパラメータの無効化

pg _statsin foの無効化(有効化されている場合）

同期レプリケーションの設定を無効化します。

新スレーブのsh ared _prelo ad_lib rariesパラメータに p g _statsinfoが設定されている場合は、書き込みができずにエラーが発生します。

pg _statsin foの指定を削除します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = on

synchronous_standby_names = '*'

shared_preload_libraries = 'pg_stat_statements,pg_statsinfo'

[編集後]

synchronous_commit = off

synchronous_standby_names = ''

shared_preload_libraries = ''

(5) 新スレーブ(server1)の起動

新スレーブ(server1)を起動します。

$ pg_ctl start

(6) 新マスタ(server2)のpostg resql.con fの修正

新マスタ(server2)にて実行します。

syn ch ro n o u s_co mmitパラメータの有効化

syn ch ro n o u s_stan d b y_n amesパラメータの有効化

同期レプリケーションの設定を有効化します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = off

synchronous_standby_names = ''

[編集後]

synchronous_commit = on

synchronous_standby_names = 'server1'

設定を反映

$ pg_ctl reload

(7) レプリケーションスロットの作成

新スレーブ1(server1)にて実行します。

PostgreSQL Enterprise Consortium

Page 74 of 285

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server1',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server1,0/9A000060)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/9A000060 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(8) スレーブ2(server3)にてrecovery.con f修正

スレーブ2(server3)にて実行します。

primary_co n n infoパラメータの｢h o st= ｣部分を修正

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ追加

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

sslmode=disable sslcompression=1 target_session_attrs=any'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=5432

application_name=server3 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

recovery_target_timeline = 'latest'

再起動

$ pg_ctl restart

(9) 新マスタ(server2)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

PostgreSQL Enterprise Consortium

Page 75 of 285

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 12505

usesysid | 16384

usename | repuser

application_name | server1

client_addr | <server1IP>

client_hostname |

client_port | 58195

backend_start | 2018-02-07 21:55:00.722782+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | sync --- 同期

(10) 新スレーブ(server1)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 86651

usesysid | 16384

usename | repuser

application_name | server3

client_addr | <server3IP>

client_hostname |

client_port | 18206

backend_start | 2018-02-07 22:13:40.199786+09

backend_xmin | 606

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

これにて、以下の構成に復旧しました。

レプリケーションスロット使用

server2(マスタ) = 同期=> server1(スレーブ1) -非同期-> server3(スレーブ2) のカスケードレプリケーション構成

5.4.4.7. 旧マスタ旧マスタ /旧スレーブ旧スレーブ 1をフェイルバックをフェイルバック

pg _b aseb acku pを使用したフェイルバックについて記載します。初期構築手順とほぼ同じです。

マスタ(server1)/スレーブ1(server2)サイトに障害が発生し、フェイルオーバ後、マスタ(server1)/スレーブ1(server2)を元の状態に復旧したレプリケーション構成図

PostgreSQL Enterprise Consortium

Page 76 of 285

pg _b aseb acku pに必要な設定については、以下と同様であるため省略します。

｢旧マスタを同期モードスレーブとしてフェイルバック｣

ります。スロットを使用する運用であれば、この段階で作成するのが有力です。

■フェイルバック手順

pg _b aseb acku pにスロットを指定する場合を記載します。

(1) 旧マスタ(server1)のデータベースクラスタを削除

旧マスタ(server1)にて実行します。

$ rm -rf $PGDATA/*

※$PG DATA以外に表領域を作成している場合、そのファイルも削除します。

※$PG DATAディレクトリを削除する場合は、postgresユーザで$PGDATAディレクトリを作成できるよう

親ディレクトリのオーナーまたはパーミッションを設定します。

(2) 旧スレーブ1(server2)のデータベースクラスタを削除

旧スレーブ1(server2)にて実行します。

$ rm -rf $PGDATA/*

※$PG DATA以外に表領域を作成している場合、そのファイルも削除します。

※$PG DATAディレクトリを削除する場合は、postgresユーザで$PGDATAディレクトリを作成できるよう

親ディレクトリのオーナーまたはパーミッションを設定します。

(3) レプリケーションスロットの作成

新マスタ(server3)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server3',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server3,0/AD000090)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server3

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/AD000090 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

PostgreSQL Enterprise Consortium

Page 77 of 285

(4) p g _basebacku p コマンドにて、新マスタ(server3)からデータベースクラスタをコピー

旧マスタ(server1)にて実行します。

$ pg_basebackup -h server3 -U repuser -D $PGDATA -X stream -S slot_server3 -P -v -R

pg_basebackup: initiating base backup, waiting for checkpoint to complete

pg_basebackup: checkpoint completed

pg_basebackup: write-ahead log start point: 0/3B000028 on timeline 2

pg_basebackup: starting background WAL receiver

203852/203852 kB (100%), 1/1 tablespace

pg_basebackup: write-ahead log end point: 0/3B000130

pg_basebackup: waiting for background process to finish streaming ...

pg_basebackup: base backup completed

(5) recovery.con fの修正

旧マスタ(server1)にて実行します。

pg _b aseb acku pにて-Rオプションを指定した事で、reco very.con fが作成されます。

スロットを指定している事から、primary_slot_n ameの指定があります。以下を追記します。

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ追加

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server3 port=5432

sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server3'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server3 port=5432

application_name=server1 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server3'

recovery_target_timeline = 'latest'

(6) 新スレーブ1(server1)の起動

新スレーブ1(server1)を起動します。

$ pg_ctl start

(7) レプリケーションスロットの作成

新スレーブ1(server1)にて実行します。

PostgreSQL Enterprise Consortium

Page 78 of 285

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server1',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server1,0/AE000028)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/AE000028 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(8) p g _basebacku p コマンドにて、新スレーブ1(server1)からデータベースクラスタをコピー

スレーブ2(server2)にて実行します。

$ pg_basebackup -h server1 -U repuser -D $PGDATA -X stream -S slot_server1 -P -v -R

pg_basebackup: initiating base backup, waiting for checkpoint to complete

pg_basebackup: checkpoint completed

pg_basebackup: write-ahead log start point: 0/3B000028 on timeline 2

pg_basebackup: starting background WAL receiver

203852/203852 kB (100%), 1/1 tablespace

pg_basebackup: write-ahead log end point: 0/3B000130

pg_basebackup: waiting for background process to finish streaming ...

pg_basebackup: base backup completed

(9) recovery.con fの修正

スレーブ2(server2)にて実行します。

pg _b aseb acku pにて-Rオプションを指定した事で、reco very.con fが作成されます。

スロットを指定している事から、primary_slot_n ameの指定があります。以下を追記します。

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ追加

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=5432

sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=5432

application_name=server2 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

recovery_target_timeline = 'latest'

(10) 新スレーブ2(server2)の起動

PostgreSQL Enterprise Consortium

Page 79 of 285

新スレーブ2(server2)を起動します。

$ pg_ctl start

(11) マスタ(server3)の停止

マスタ(server3)を停止します。

$ pg_ctl stop

(12) スレーブ1(server1)を新マスタへ昇格

スレーブ1(server1)で実行します。

$ pg_ctl promote

※サーバログに下記内容が記載されること

"d a tab ase system is ready to accept co n n ection s"

(13) レプリケーションスロットの作成

新スレーブ1(server2)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server2',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server2,0/AE000028)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server2

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/AE000028 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(14) 新スレーブ2(server3)にてreco very.co n f作成

新スレーブ2(server3)にてreco very.co n fを作成します。

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータの追加

recovery_targ et_timelin eパラメータの追加

PostgreSQL Enterprise Consortium

Page 80 of 285

$ mv $PGDATA/recovery.done $PGDATA/recovery.conf

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

sslmode=disable sslcompression=1 target_session_attrs=any'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

application_name=server3 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server2'

recovery_target_timeline = 'latest'

起動

$ pg_ctl start

(15) 新マスタ(server1)のpostg resql.con fの修正

新マスタ(server1)にて実行します。

syn ch ro n o u s_co mmitパラメータの有効化

syn ch ro n o u s_stan d b y_n amesパラメータの有効化

同期レプリケーションの設定を有効化します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = off

synchronous_standby_names = ''

[編集後]

synchronous_commit = on

synchronous_standby_names = 'server2'

設定を反映

$ pg_ctl reload

(16) 新マスタ(server1)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

PostgreSQL Enterprise Consortium

Page 81 of 285

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 12505

usesysid | 16384

usename | repuser

application_name | server2

client_addr | <server2IP>

client_hostname |

client_port | 58195

backend_start | 2018-02-07 21:55:00.722782+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | sync --- 同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

active | t --- アクティブ

(17) 新スレーブ1(server2)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 86651

usesysid | 16384

usename | repuser

application_name | server3

client_addr | <server3IP>

client_hostname |

client_port | 18206

backend_start | 2018-02-07 22:13:40.199786+09

backend_xmin | 606

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

=# SELECT slot_name,active FROM pg_replication_slots;

slot_name | active

--------------+--------

slot_server2 | t

(1 row)

(18) レプリケーションスロットの削除(スレーブ）

PostgreSQL Enterprise Consortium

Page 82 of 285

新スレーブに旧マスタ時代のスロットが残る事があります。

restart_lsn列に値が残っている状態では、マスタのVACUU M 処理を阻害するなどの

悪影響の可能性があるため、削除します。

スロットの削除は関数で行うため、スレーブでも実行可能です。

スレーブ2(server3)にて実行します。

$ psql

=# SELECT slot_name,active FROM pg_replication_slots;

slot_name | active

--------------+--------

slot_server3 | f

(1 row)

=# SELECT pg_drop_replication_slot('slot_server3');

pg_create_physical_replication_slot

-------------------------------------

(1 row)

=# SELECT slot_name FROM pg_replication_slots;

(0 rows)

これにて、以下の構成に復旧しました。

レプリケーションスロット使用

server1(マスタ) = 同期=> server2(スレーブ1) = 非同期= > server3(スレーブ2) のカスケードレプリケーション構成

5.4.4.8. スイッチオーバスイッチオーバ

スイッチオーバについて記載します。

5.4.4.9. 同期スレーブへのスイッチオーバ同期スレーブへのスイッチオーバ

■スイッチオーバ手順

計画停止におけるマスタ/スレーブの切り替え手順です。 p g _baseb acku p やpg_rew ind が不要であるためシンプルな手順です。

計画停止にてマスタとスレーブ1の役割を切り替えたレプリケーション構成図

(1) マスタ(server1)の正常停止

マスタ(server1)にて実行します。

$ pg_ctl stop -m fast

(2) スレーブ(server2)の昇格

スレーブ(server2)にて実行します。

以下の場合にはpg _rew in d 不要です。

計画停止

同期レプリケーションのインスタンス障害(物理障害なし）

PostgreSQL Enterprise Consortium

Page 83 of 285

$ pg_ctl promote

(3) レプリケーションスロットの作成

新マスタ(server2)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server2',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server2,0/B40000C8)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server2

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/B40000C8 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(4) 旧マスタ(server1)のreco very.con fの作成

以下を記載します。

$ vi $PGDATA/recovery.conf

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

application_name=server1 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server2'

recovery_target_timeline = 'latest'

(5) 旧マスタ(server1)のpostg resql.con fの修正

旧マスタ(server1)にて、パラメータの調整を行います。

syn ch ro n o u s_co mmitパラメータの無効化

syn ch ro n o u s_stan d b y_n amesパラメータの無効化

pg _statsin foの無効化(有効化されている場合）

同期レプリケーションの設定を無効化します。

新スレーブのsh ared _prelo ad_lib rariesパラメータに p g _statsinfoが設定されている場合は、書き込みができずにエラーが発生します。

pg _statsin foの指定を削除します。

PostgreSQL Enterprise Consortium

Page 84 of 285

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = on

synchronous_standby_names = '*'

shared_preload_libraries = 'pg_stat_statements,pg_statsinfo'

[編集後]

synchronous_commit = off

synchronous_standby_names = ''

shared_preload_libraries = ''

再起動

$ pg_ctl restart

(6) レプリケーションスロットの作成

新スレーブ(server1)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server1',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server1,0/B4000028)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/B4000028 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(7) 新マスタ(server2)のpostg resql.con fの修正

新マスタ(server2)にて実行します。

syn ch ro n o u s_co mmitパラメータの有効化

syn ch ro n o u s_stan d b y_n amesパラメータの有効化

同期レプリケーションの設定を有効化します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = off

synchronous_standby_names = ''

[編集後]

synchronous_commit = on

synchronous_standby_names = 'server1'

設定を反映

$ pg_ctl reload

PostgreSQL Enterprise Consortium

Page 85 of 285

(8) スレーブ2(server3)にてrecovery.con f修正

スレーブ2(server3)にて実行します。

primary_co n n infoパラメータの｢h o st= ｣部分を修正

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ追加

$ vi $PGDATA/recovery.conf

[編集前]

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=12079

sslmode=disable sslcompression=1 target_session_attrs=any'

[編集後]

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=12079

application_name=server3 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

recovery_target_timeline = 'latest'

再起動

$ pg_ctl restart

(9) 新マスタ(server2)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 12505

usesysid | 16384

usename | repuser

application_name | server1

client_addr | <server1IP>

client_hostname |

client_port | 58195

backend_start | 2018-02-07 21:55:00.722782+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | sync --- 同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server2

active | t --- アクティブ

(10) 新スレーブ(server1)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

PostgreSQL Enterprise Consortium

Page 86 of 285

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 86651

usesysid | 16384

usename | repuser

application_name | server3

client_addr | <server3IP>

client_hostname |

client_port | 18206

backend_start | 2018-02-07 22:13:40.199786+09

backend_xmin | 606

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]-----------

slot_name | slot_server1

active | f

以上でスイッチオーバが完了しました。

5.4.4.10. 非同期スレーブへのスイッチオーバ非同期スレーブへのスイッチオーバ

■スイッチオーバ手順

計画停止におけるマスタ/スレーブの切り替え手順です。 p g _baseb acku p やpg_rew ind が不要であるためシンプルな手順です。

計画停止にてマスタとスレーブ2の役割を切り替えたレプリケーション構成図

(1) マスタ(server1)の正常停止

マスタ(server1)にて実行します。

$ pg_ctl stop -m fast

(2) スレーブ(server3)の昇格

スレーブ(server3)にて実行します。

以下の場合にはpg _rew in d 不要です。

計画停止

レプリケーションのインスタンス障害(物理障害なし）

PostgreSQL Enterprise Consortium

Page 87 of 285

$ pg_ctl promote

(3) レプリケーションスロットの作成

新マスタ(server3)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server3',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server3,0/BA0000C8)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server3

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/BA0000C8 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(4) 旧マスタ(server1)のreco very.con fの作成

以下を記載します。

$ vi $PGDATA/recovery.conf

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server3 port=5432

application_name=server1 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server3'

recovery_target_timeline = 'latest'

(5) 旧マスタ(server1)のpostg resql.con fの修正

旧マスタ(server1)にて、パラメータの調整を行います。

syn ch ro n o u s_co mmitパラメータの無効化

syn ch ro n o u s_stan d b y_n amesパラメータの無効化

pg _statsin foの無効化(有効化されている場合）

同期レプリケーションの設定を無効化します。

新スレーブのsh ared _prelo ad_lib rariesパラメータに p g _statsinfoが設定されている場合は、書き込みができずにエラーが発生します。

pg _statsin foの指定を削除します。

PostgreSQL Enterprise Consortium

Page 88 of 285

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = on

synchronous_standby_names = '*'

shared_preload_libraries = 'pg_stat_statements,pg_statsinfo'

[編集後]

synchronous_commit = off

synchronous_standby_names = ''

shared_preload_libraries = ''

(6) 新スレーブ1(server1)の起動

新スレーブ1(server1)を起動します。

$ pg_ctl start

(7) レプリケーションスロットの作成

新スレーブ1(server1)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server1',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server1,0/BA000028)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/BA000028 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(8) スレーブ2(server2)にてrecovery.con f修正

スレーブ2(server2)にて実行します。

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ

PostgreSQL Enterprise Consortium

Page 89 of 285

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=5432

sslmode=disable sslcompression=1 target_session_attrs=any'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=5432

application_name=server1 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

recovery_target_timeline = 'latest'

再起動

$ pg_ctl restart

(9) 新マスタ(server3)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 12505

usesysid | 16384

usename | repuser

application_name | server1

client_addr | <server1IP>

client_hostname |

client_port | 58195

backend_start | 2018-02-07 21:55:00.722782+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | async --- 非同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server3

active | t --- アクティブ

(10) 新スレーブ1(server1)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

PostgreSQL Enterprise Consortium

Page 90 of 285

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 86651

usesysid | 16384

usename | repuser

application_name | server2

client_addr | <server2IP>

client_hostname |

client_port | 18206

backend_start | 2018-02-07 22:13:40.199786+09

backend_xmin | 606

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

active | t --- アクティブ

以上でスイッチオーバが完了しました。

5.4.4.11. スイッチバックスイッチバック

スイッチバックについて記載します。

5.4.4.12. 同期モードスレーブからマスタへのスイッチバック同期モードスレーブからマスタへのスイッチバック

同期モードスレーブになっていた旧マスタをマスタに復帰させるスイッチバックついて記載します。

同期モードスレーブになっていた旧マスタをマスタとして復帰させたレプリケーション構成図

■スイッチバック手順

(1) マスタ(server2)の停止

$ pg_ctl stop

(2) スレーブ1(server1)の昇格

スレーブ1(server1)にて実行します。

PostgreSQL Enterprise Consortium

Page 91 of 285

$ pg_ctl promote

(3) 旧マスタ(server2)のreco very.con fの作成

以下を記載します。

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ追加

$ cp $PGDATA/recovery.done $PGDATA/recovery.conf

$ vi $PGDATA/recovery.conf

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=5432

application_name=server2 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

recovery_target_timeline = 'latest'

(4) 新マスタ(server1)のpostg resql.con fの修正

新マスタ(server1)にて実行します。

syn ch ro n o u s_co mmitパラメータの有効化

syn ch ro n o u s_stan d b y_n amesパラメータの有効化

同期レプリケーションの設定を有効化します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = off

synchronous_standby_names = ''

[編集後]

synchronous_commit = on

synchronous_standby_names = 'server2'

設定を反映

$ pg_ctl reload

(5) 新スレーブ1(server2)の起動

$ pg_ctl start

(6) スレーブ2(server3)のreco very.con fの作成

以下を記載します。

primary_co n n infoパラメータの｢h o st= ｣部分を修正

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ修正

recovery_targ et_timelin eパラメータ追加

PostgreSQL Enterprise Consortium

Page 92 of 285

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=5432

sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

application_name=server3 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server2'

recovery_target_timeline = 'latest'

(7) スレーブ2(server3)の再起動

$ pg_ctl restart

(8) 新マスタ(server1)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 12505

usesysid | 16384

usename | repuser

application_name | server2

client_addr | <server2IP>

client_hostname |

client_port | 58195

backend_start | 2018-02-07 21:55:00.722782+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | sync --- 同期

(9) スレーブ1(server2)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

PostgreSQL Enterprise Consortium

Page 93 of 285

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 86651

usesysid | 16384

usename | repuser

application_name | server3

client_addr | <serrver3IP>

client_hostname |

client_port | 18206

backend_start | 2018-02-07 22:13:40.199786+09

backend_xmin | 606

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

以上でスイッチバックが完了しました。

5.4.4.13. 非同期モードスレーブからマスタへのスイッチバック非同期モードスレーブからマスタへのスイッチバック

非同期モードスレーブからマスタへスイッチバックついて記載します。

非同期モードスレーブになっていた旧マスタをマスタとして復帰させたレプリケーション構成図

■スイッチバック手順

(1) マスタ(server3)の停止

$ pg_ctl stop

(2) スレーブ1(server1)の昇格

スレーブ1(server1)にて実行します。

$ pg_ctl promote

(3) レプリケーションスロットの作成

新スレーブ1(server2)にて実行します。

PostgreSQL Enterprise Consortium

Page 94 of 285

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server2',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server2,0/BB0000C8)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server2

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/BB0000C8 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(4) 旧マスタ(server3)のreco very.con fの作成

以下を記載します。

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ追加

$ cp $PGDATA/recovery.done $PGDATA/recovery.conf

$ vi $PGDATA/recovery.conf

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

application_name=server3 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server2'

recovery_target_timeline = 'latest'

再起動

$ pg_ctl restart

(5) 新マスタ(server1)のpostg resql.con fの修正

新マスタ(server1)にて実行します。

syn ch ro n o u s_co mmitパラメータの有効化

syn ch ro n o u s_stan d b y_n amesパラメータの有効化

同期レプリケーションの設定を有効化します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = off

synchronous_standby_names = ''

[編集後]

synchronous_commit = on

synchronous_standby_names = 'server2'

$ pg_ctl reload

PostgreSQL Enterprise Consortium

Page 95 of 285

(6) 新マスタ(server1)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 12505

usesysid | 16384

usename | repuser

application_name | server2

client_addr | <server2IP>

client_hostname |

client_port | 58195

backend_start | 2018-02-07 21:55:00.722782+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | sync --- 同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

active | t --- アクティブ

(7) スレーブ1(server2)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

PostgreSQL Enterprise Consortium

Page 96 of 285

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 86651

usesysid | 16384

usename | repuser

application_name | server3

client_addr | <server3IP>

client_hostname |

client_port | 18206

backend_start | 2018-02-07 22:13:40.199786+09

backend_xmin | 606

state | streaming --- ストリーミング中

sent_lsn | 0/6A000818

write_lsn | 0/6A000818

flush_lsn | 0/6A000818

replay_lsn | 0/6A000818

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

=# SELECT slot_name,active FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server2

active | t --- アクティブ

(8) レプリケーションスロットの削除(スレーブ）

フェイルオーバとの違いとしては、新スレーブに旧マスタ時代のスロットが残る事があります。

restart_lsn列に値が残っている状態では、マスタのVACUU M 処理を阻害するなどの

悪影響の可能性があるため、削除します。

スロットの削除は関数で行うため、スレーブでも実行可能です。

スレーブ2(server3)にて実施します。

$ psql

=# SELECT slot_name FROM pg_replication_slots;

slot_name

--------------

slot_server3

(1 row)

=# SELECT pg_drop_replication_slot('slot_server3');

pg_create_physical_replication_slot

-------------------------------------

(1 row)

=# SELECT slot_name FROM pg_replication_slots;

(0 rows)

以上でスイッチバックが完了しました。

5.4.4.14. pg_rewindを使用したスイッチバックを使用したスイッチバック

pg _rew in dを使用したスイッチバックについて記載します。

pg _rew in d後の操作は、通常のスイッチオーバ時と同じです。タイムラインの分岐点からソースクラスタのW ALを適用するため、更新量が少なければpg_baseb ack による

複製より高速です。これによりスイッチオーバ時、旧マスタを容易に新スレーブとして起動させることができます。

スイッチオーバー後、pg_rew in d で旧マスタを新スレーブとして戻したレプリケーション構成図

PostgreSQL Enterprise Consortium

Page 97 of 285

■関連パラメータ

pg _rew in dに必要な設定を記載します。

表 5.30 p g _rew ind に必要な設定

サーバサーバ設定ファイル設定ファイルパラメータパラメータ設定値設定値内容内容

pg _rew in d

実行サーバ

po stg resq l.con f fu ll_p age_w rites on チェックポイント後の更新時、ディスクページの全内容をW ALに書き込

む。

pg _rew in d

実行サーバ

po stg resq l.con f w al_lo g _h ints on ヒントビット更新時もfu ll_p age_w ritesを実行する。

■p g _rew indコマンド

pg _rew in dコマンドの主なオプションは次の通りです。

表 5.31 p g _rew ind のオプション

オプションオプション内容内容

D <ターゲットクラスタ> pg _rew in dを実行し、ソースクラスタの内容に置き換えるクラスタを指定する。

sou rce-server= "<ソースクラスタ> "

同期対象であるソースクラスタを指定します。主に次の接続文字列を使用します。

h ost：ソースクラスタのホスト名またはIPアドレス

po rt：ソースクラスタのポート番号

db n ame：ソースクラスタの接続先データベース名

u ser：ソースクラスタの接続先ユーザ

P 進行状況をレポートとして表示する。

■フェイルバック手順

※事前にマスタで関連パラメータの設定がされていることを前提とします。

PostgreSQL Enterprise Consortium

Page 98 of 285

(1) マスタの正常停止

pg _rew in dを使用するには正常停止する必要があります。

停止した旧マスタを一旦起動した後、正常停止させます。

障害により正常に起動や停止ができない状態ではp g _rew indは使用できません。

その場合は、pg _b aseb acku pを使用します。

$ pg_ctl stop -m fast

(2) スレーブ(server2)の昇格

スレーブ(server2)にて実行します。

計画停止

同期レプリケーションのインスタンス障害(物理障害なし）

$ pg_ctl promote

(3) 旧マスタ(server1)のpostg resql.con fの修正

旧マスタ(server1)にて、パラメータの調整を行います。

syn ch ro n o u s_co mmitパラメータの無効化

syn ch ro n o u s_stan d b y_n amesパラメータの無効化

pg _statsin foの無効化(有効化されている場合）

同期レプリケーションの設定を無効化します。

新スレーブのsh ared _prelo ad_lib rariesパラメータに p g _statsinfoが設定されている場合は、書き込みができずにエラーが発生します。

pg _statsin foの指定を削除します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = on

synchronous_standby_names = '*'

shared_preload_libraries = 'pg_stat_statements,pg_statsinfo'

[編集後]

synchronous_commit = off

synchronous_standby_names = ''

shared_preload_libraries = ''

(4) スプリットブレイン状態状態を作るため、旧マスタ(server1)を再度起動し、

データを更新する

$ pg_ctl start

$ psql

=# select * from test;

col1

------

(3 rows)

=# insert into test values(4);

INSERT 0 1

=# select * from test;

col1

------

(4 rows)

(5) p g _rew indの実行のため、旧マスタ(server1)を正常停止する。

PostgreSQL Enterprise Consortium

Page 99 of 285

$ pg_ctl stop -m fast

(6) 旧マスタ(server1)にてp g _rew ind の実行

$ pg_rewind -D $PGDATA --source-server="host=server2 port=5432"

servers diverged at WAL location 0/D0000098 on timeline 45

rewinding from last common checkpoint at 0/D0000028 on timeline 45

Done!

(7) レプリケーションスロットの作成

新マスタ(server2)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server2',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server2,0/D00000C8)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server2

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/D00000C8 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(8) recovery.con fの作成

旧マスタ(server1)にて実行します。

以下を設定します。

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ追加

$ cp $PGDATA/recovery.done $PGDATA/recovery.conf

$ vi $PGDATA/recovery.conf

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

application_name=server1 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server2'

recovery_target_timeline = 'latest'

(9) 新スレーブ(server1)の起動

新スレーブ(server1)を起動します。

$ pg_ctl start

(10) 新スレーブ(server1)にてデータ確認

pg _rew in dにより、データが正常に巻き戻されていることを確認します。

PostgreSQL Enterprise Consortium

Page 100 of 285

$ psql

=# select * from test;

col1

------

(3 rows)

(11) 新マスタ(server2)のpostg resql.con fの修正

新マスタ(server2)にて実行します。

syn ch ro n o u s_co mmitパラメータの有効化

syn ch ro n o u s_stan d b y_n amesパラメータの有効化

同期レプリケーションの設定を有効化します。

$ vi $PGDATA/postgresql.conf

[編集前]

synchronous_commit = off

synchronous_standby_names = ''

[編集後]

synchronous_commit = on

synchronous_standby_names = 'server1'

設定を反映

$ pg_ctl reload

(12) レプリケーションスロットの作成

新スレーブ1(server1)にて実行します。

$ psql

=# SELECT pg_create_physical_replication_slot('slot_server1',true); -- 第2パラメータにtrueを指定

pg_create_physical_replication_slot

-------------------------------------

(slot_server1,0/D0000028)

(1 行)

=# \x on

拡張表示は on です。

=# SELECT * FROM pg_replication_slots;

-[ RECORD 1 ]-------+-------------

slot_name | slot_server1

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | f -- まだスロットは使用されてないため false

active_pid |

xmin |

catalog_xmin |

restart_lsn | 0/D0000028 -- trueの指定により、作成直後からrestat_lsnを認識

confirmed_flush_lsn |

(13) スレーブ2(server3)にてrecovery.con f修正

スレーブ2(server3)にて実行します。

primary_co n n infoパラメータの｢h o st= ｣部分を修正

primary_co n n infoパラメータにap p lication _nameを追加（任意／デフォルトはw alreceiver）

PostgreSQL Enterprise Consortium

Page 101 of 285

primary_slot_n ameパラメータ追加

recovery_targ et_timelin eパラメータ追加

$ vi $PGDATA/recovery.conf

[編集前]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=5432

sslmode=disable sslcompression=1 target_session_attrs=any'

[編集後]

standby_mode = 'on'

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=5432

application_name=server3 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

recovery_target_timeline = 'latest'

再起動

$ pg_ctl restart

(14) 新マスタ(server2)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 82328

usesysid | 16384

usename | repuser

application_name | server1

client_addr | 172.16.25.111

client_hostname |

client_port | 63206

backend_start | 2018-02-28 22:40:16.337761+09

backend_xmin |

state | streaming --- ストリーミング中

sent_lsn | 0/D0019538

write_lsn | 0/D0019538

flush_lsn | 0/D0019538

replay_lsn | 0/D0019538

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | sync --- 同期

(15) 新スレーブ(server1)でのレプリケーション確認

pg _stat_replication sビューを参照して、レプリケーション構成である事を確認します。

pg _replication _slotsビューを参照して、スロットがアクティブである事を確認します。

PostgreSQL Enterprise Consortium

Page 102 of 285

$ psql

=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 51369

usesysid | 16384

usename | repuser

application_name | server3

client_addr | 172.16.25.143

client_hostname |

client_port | 47281

backend_start | 2018-02-28 23:02:39.56715+09

backend_xmin |

sent_lsn | 0/D0019538

write_lsn | 0/D0019538

flush_lsn | 0/D0019538

replay_lsn | 0/D0019538

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async --- 非同期

(16) マスタ、スレーブとタイムラインID が揃っていることを確認する。

タイムラインIDの取得には、p g _con tro ld ataコマンドを使用する。

厳密には最新チェックポイント実行時のタイムラインIDであるため、

タイムラインIDが揃っていないときは、マスタにてチェックポイント実行後、再確認します。

[マスタ(server2)]

$ export LANG=C

$ pg_controldata | grep " TimeLineID"

Latest checkpoint's TimeLineID: 46

[スレーブ1(server1)]

$ export LANG=C

$ pg_controldata | grep " TimeLineID"

Latest checkpoint's TimeLineID: 46

[スレーブ2(server3)]

$ export LANG=C

$ pg_controldata | grep " TimeLineID"

Latest checkpoint's TimeLineID: 46

■p g _rew ind使用時の注意点

正常停止が必要

pg _rew in dを実行するデータベースクラスタは正常終了しなければいけません。

物理障害等により正常停止できない場合、p g _rew in d は使用できません。p g _basebacku p を使用します。

同一タイムラインの場合は実施不可

pg _p romoteを実行せずに旧スレーブを新マスタにした場合、新マスタのタイムラインID は変わらないため、

新マスタと旧マスタのタイムラインIDは同じ状態です。

この場合は、p g _rew in d は実行できません。

実行時期と所要時間の関係

pg _rew in dによるフェイルバックの所要時間は２つの要素から構成されます。

Step 1.　pg_rew ind による巻き戻し（旧マスタのW ALを使用）

Step 2.　W AL適用による追い付き（新マスタのW ALを使用）

新マスタで大量更新がある場合は、Step1は短時間で終了してもStep2で時間がかかります。

結果として、p g _basebacku pの方が効率が良い場合もあり得ます。

PostgreSQL Enterprise Consortium

Page 103 of 285

また新マスタ昇格時のW ALが削除されている場合は、後述するようにStep2でエラーとなる可能性もあります。その場合はpg_basebacku p

が必要となります。

pg _rew in dはフェイルオーバー後、あまり時間を置かずに実行する事がポイントです。

旧マスタのW AL保管

旧マスタの巻き戻しに必要な旧マスタのW ALが削除されている場合、pg_rew in d は失敗します。

例えば旧マスタが障害により大量更新の途中で異常終了した場合などに発生します。

pg _rew in d実行時に次のようなエラーが発生します。

could not open file "/home/pg96/pg96_data/pg_xlog/0000000D00000002000000CF": No

such file or directory

could not find previous WAL record at 2/CF000140

Failure, exiting

pg _rew in dが成功するかどうかは検証(d ry-ru n オプション)にて事前に確認する事ができます。

$ pg_rewind -D $PGDATA --source-server="host=server2 port=5432" --dry-run

servers diverged at WAL position 0/5015B70 on timeline 1

rewinding from last common checkpoint at 0/5015B00 on timeline 1

Done!

| メッセージはdry-runオプションが無い場合と同じです。

| pg_rewindでエラーが発生する場合(スレーブのWAL削除）は、この検証にて確認できますが、

| pg_rewindでエラーが発生しないで、後から発生する場合（マスタのWAL削除）は検知できません。

| 検証の仕様について認識下さい。

新マスタのW AL保管

pg _rew in d後、新スレーブは新マスタのW ALを適用することで、新マスタと同期します。

新マスタに昇格時のW ALファイルが残っていない場合、新スレーブは追い付きができず、次のエラーがサーバログに出力され続けます。

対策としてレプリケーションスロットの有効化が有力ですが、新マスタのW AL領域の枯渇にご注意下さい。

ERROR: requested WAL segment 0000000D00000000000000F3 has already been removed

タイムラインの巻き戻し

pg _rew in dはPostgreSQ L9.6からタイムラインの巻き戻しができるよになっています。

これによりスプリットブレインが発生しても、新マスタをスレーブに戻すことが可能です。

pg _rew in dが不要な場合

pg _rew in dはターゲットとソースクラスタのタイムラインIDが分岐した場合に実行が必要です。

そのためタイムラインが枝分かれしなかった場合、pg_rew ind を実行する必要はありません。

例えばpg_rew in d 実行時に次のようなメッセージが出た場合、pg _rew in d は実行せずに、以降の操作を継続します。

servers diverged at WAL position 0/503A428 on timeline 2

no rewind required

5.4.4.15. スレーブ障害による対処スレーブ障害による対処

スレーブ障害時の緊急対応の必要性は、非同期モードが同期モードかによって異なります。

非同期モードの場合は、スレーブ障害がマスタの更新処理を阻害しないため、緊急対応は必要ありません。

とはいえ、シングル状態であるため早期にレプリケーション構成に復旧します。

PostgreSQL Enterprise Consortium

Page 104 of 285

$ psql -h server1 -U postgres postgres -c "INSERT INTO test1_t VALUES ( 1 )"

Cancel request sent

WARNING: canceling wait for synchronous replication due to user request

DETAIL: ** The transaction has already committed locally, but might not have been replicated to

the standby. **

INSERT 0 1

※Ctrl+Cをキーインする等、意図的にキャンセルしない限り、応答が返ってきません。

そのため、直ちに非同期に設定する必要があります。

非同期への切り替え処理は以降に示す様に再起動不要であるため、即時対応が可能です。

非同期への切り替えではなく、スレーブの再起動を試みる方法も考えられます。その方が効率的のようにも考えられます。

即座に起動できればその通りですが、起動に時間がかかる、あるいは物理的な障害で起動できない状態である事も考えられます。

そのような試行錯誤より、まずは確実にマスタのハング状態解消を優先します。

マスタの復旧後は、スレーブの復旧を試みます。

物理障害により起動できない場合は、フェイルバック処理と同様の作業を行います。

(1) スレーブの疑似障害発生

immed iateオプションにて停止、またはpo stg resプロセスのkillする事で擬似障害を発生させます。

スレーブ1(server2)にて実行します。

$ pg_ctl -w -m immediate stop

(2) スレーブ1(server2)の死活監視にて異常を検知

死活監視の方法には多数ありますが、ここではpg_isread yコマンドを使用します。

pg _isreadyコマンドはクライアントツールですので、任意のノードから実行できます。

$ pg_isready -h server2 -U postgres -d postgres

server2:5432 - no response

(3) 非同期モードに切り替え

syn ch ro n o u s_stan d b y_n amesパラメータを''に設定する事で、非同期の設定となります。

マスタ(server1)にて実行します。

PostgreSQL Enterprise Consortium

Page 105 of 285

$ vi $PGDATA/postgresql.conf

[変更前]

synchronous_standby_names = '*'

[変更後]

synchronous_standby_names = ''

$ pg_ctl reload

これでマスタが更新処理が可能な状態に復旧しました。

(4) スレーブ2(server3)を非同期モードで復活

recovery.con fファイルを修正します。

primary_co n n infoパラメータの｢h o st= ｣部分を修正

primary_slot_n ameパラメータが設定されている場合は、修正

$ vi $PGDATA/recovery.conf

[変更前]

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server2 port=12079

application_name=server3 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server2'

[変更後]

primary_conninfo = 'user=repuser passfile=''/home/p101/.pgpass'' host=server1 port=12079

application_name=server3 sslmode=disable sslcompression=1 target_session_attrs=any'

primary_slot_name = 'slot_server1'

$ pg_ctl restart

(5) スレーブ2(server3)にてデータが伝播されることを確認

同期モードのスレーブも復活させたい場合は、フェイルバックと同様の作業を行います。

5.5. まとめ

5.5.1. SR機能拡張の歴史機能拡張の歴史

Po stg reSQ L 9.0でSR機能が実装されて以降、メジャーバージョン毎にSR 関連の新機能を実装しています。

"ミスオペレーション"を"ミスオペ"と略記する場合があります。

"レプリケーションスロット"と表記した場合は物理型を指します。論理型の場合は明記します。

"レプリケーションスロット"を"スロット"と略記する場合があります。

表 5.32 SR機能拡張の歴史

バーバー

ジョンジョン分野または目的分野または目的概要概要関連パラメータ関連パラメータ

9.1 管理性の向上

データ保護

同期モードの実装同期モードの実装

CO MM IT時にW ALの転送完了までを保証する。

データ保護とパフォーマンスとのトレードオフ

[マスタのpo stg resq l.con f]

syn ch ro n o u s_stan d b y_n ames

9.1 管理性向上

昇格処理の明瞭化

pg_ctl promote コマンドによる昇格コマンドによる昇格

明確なコマンドとなり分かり易くなった。

従来はtrig ger_fileで設定したパスにto u ch コマンド等でファイルを作成する方

式であった。

9.1 管理性向上

SR状況把握の簡易化

pg_stat_replicationビューの追加ビューの追加

マスタでの、スレーブへのW AL転送および適用の状況把握方法が簡易になっ

た。w al_receiver_statu s_in terval間隔で反映。

[スレーブのpo stg resql.con f]

w al_receiver_sta tus_interval

PostgreSQL Enterprise Consortium

Page 106 of 285

9.1 管理性向上

SR状況把握の簡易化

pg_last_xact_replay_tim estamp関数の追加関数の追加

スレーブにて最終適用された時間を取得する

9.2 データ保護とパフォーマンス

の調整

同期方式に同期方式に remote_writeの追加の追加

syn ch ro n o u s_co mmitの選択肢として、on /o ff/lo calに加え、

remote_w riteが追加された。

スレーブのメモリに書き込むまでを保証する。その時点でO Sがハングした場合、

W ALは損失する。

[マスタのpo stg resq l.con f]

　syn ch ron o u s_co mmit

9.2 高可用性の向上カスケードレプリケーションの実装カスケードレプリケーションの実装

スレーブにぶら下がる2段目のSR 構成が可能となった。

マスタの負荷を限定。

9.2 管理性の向上

SR状況把握の簡易化

pg_xlog_location_diff関数の追加関数の追加

スレーブの転送や適用がどの程度遅れているかを取得するのが容易になった。

従来は p g _stat_rep lication ビューを参照していたが、ログの位置をバイト数

に換算する計算が必要だった。

本関数により16進の差分をバイト数として取得できる。

9.3 管理性の向上

役割交換の効率化

スイッチバックの実装スイッチバックの実装

h isto ryファイルの転送により実装

9.3 管理性の向上カスケードレプリケーションの管理性向上カスケードレプリケーションの管理性向上

カスケードのSR構成において、スレーブの新マスタ昇格後に、スレーブとSR の継

続が可能に

9.3 障害時間の短縮昇格処理の高速化昇格処理の高速化

昇格処理にて、リカバリのみ実行し、チェックポイントを省略する事で時間短縮

を実現。

従来はチェックポイントも昇格処理にて実行していた。

9.4 管理性の向上

ミスオペ対策

遅延レプリケーションの実装遅延レプリケーションの実装

スレーブでの適用を一定時間(reco very_min _apply_delay)遅らせる事で、

マスタで発生したミスオペの伝搬を防ぐ。以下の事項に注意。

一定時間内にマスタでのミスオペを検知して対応が必要

昇格時には遅延分の適用が必要であるため時間を要する

[スレーブのrecovery.co n f]

　reco very_min _app ly_delay

9.4 管理性の向上

W AL保持の保証

レプリケーションスロットの実装レプリケーションスロットの実装

スレーブに必要なW ALをマスタで保持し続ける事を保証。

特に複数スレーブ構成にて効果的。以下の事項に注意。

マスタのW AL領域が溢れないように監視を検討

不要スロットは削除（残存しているとW ALを保持）

[マスタのpo stg resq l.con f]

　max_rep lication _slo ts

[スレーブのpo stg resql.con f]

　ho t_stan d b y_feed b ack

9.4 論理レプリケーション論理レプリケーションの関数の実装論理レプリケーションの関数の実装

行レベルの変更内容を出力する関数が実装された。

pg _lo gical_slot_g et_ch an ges関数

pg _lo gical_slot_p eek_ch an g es関数

必要な設定

w al_levelをlog icalに設定

論理レプリケーションスロットを作成

[マスタのpo stg resq l.con f]

w al_level

　max_rep lication _slo t

9.5 W AL転送効率の向上 WAL圧縮機能の実装圧縮機能の実装

W ALを圧縮する事で、転送効率の向上する。

圧縮／解凍によるオーバーヘッドとのトレードオフだが、通常はメリットの方が大

きい。

SRに特化した機能では無いが、特に次のSR構成での適用が効果的と考えら

れる。

同期モードまたは完全同期モード

スレーブを遠隔地に配置（ディザスタ・リカバリ）

[マスタのpo stg resq l.con f]

　w al_co mpression

9.5 管理性の向上

SR構築の効率化

pg_rewindコマンドの実装コマンドの実装

昇格した新マスタと旧マスタを再同期する事で、SR構成を実装。物理的な障

害でない場合は、pg _rew in dにて対応可能な可能性がある。

新マスタから旧マスタへ差分バックアップを転送および旧マスタのW ALを適用。

差分バックアップの転送はpg_basebacku pと同様であるため、同様の設定が

必要。

[マスタのpo stg resq l.con f]

　w al_lo g_h ints

　fu ll_p age_w rites

　max_w al_sen d ers

[マスタのpg _h b a.con f]

　rep lication 疑似データベースと

の認証設定

9.5 管理性の向上レプリケーション関連メッセージの出力レプリケーション関連メッセージの出力

ログ監視の利便性が向上。ただしあまり多くは出力されない。

[マスタのpo stg resq l.con f]

　log_replica tion _comma n d s

バーバー

ジョンジョン分野または目的分野または目的概要概要関連パラメータ関連パラメータ

PostgreSQL Enterprise Consortium

Page 107 of 285

9.5 管理性の向上

継続的アーカイブ

スレーブでのアーカイブ出力機能スレーブでのアーカイブ出力機能

スレーブにおいて自分のW ALを出力する事で、昇格時に途切れること無く継

続的なアーカイブが可能。

[スレーブのpo stg resql.con f]

　arch ive_mode

9.6 スケールアウト

参照負荷分散

完全同期レプリケーション機能の実装完全同期レプリケーション機能の実装

スレーブへの適用完了までを保証。

スレーブ参照時にマスタと同一データが保証される事で、参照負荷分散による

スケールアウトが期待される。

[マスタのpo stg resq l.con f]

　syn ch ron o u s_co mmit

9.6 データ保護の多重化複数同期スレーブ構成機能複数同期スレーブ構成機能

従来は複数スレーブの内、同期モードが設定できるのは１台のみであったが、そ

の制限が無くなった。

同時に複数スレーブに対して同期モードが設定できる。

[マスタのpo stg resq l.con f]

syn ch ro n o u s_stan d b y_n ames

9.6 管理性の向上

SR状況把握の簡易化

pg_stat_wal_receiverビューの追加ビューの追加

従来はマスタにてpg _stat_replication ビューが参照できたが、スレーブにて

pg _stat_w al_receiverビューが参照できる。

スレーブからレプリケーションの状況が把握が容易に。

9.6 管理性の向上

監視手法の多様化

pg_control_recovery関数の追加関数の追加

制御ファイル情報の内、リカバリに関する情報を取得。

従来はpg_con troldataコマンドで制御ファイルの情報を取得したが、

SELECT文で取得できる事で管理手法の選択肢が増えた。

9.6 管理性の向上

役割交換の簡易化

pg_rewindの機能拡張の機能拡張

タイムラインIDの変更後にも対応できるようになった。

マスタに適用する事でスレーブに戻す事が可能。

10.0 管理性の向上一時レプリケーションスロット一時レプリケーションスロット

レプリケーションスロットを一時的に作成できるようになった。

pg _b aseb acku pコマンド実行時のみ使用する場合に有効。

一時的なスロットかどうかはpg_replication _slotsカタログのtempora ry列で

判断する。

10.0 管理性の向上 Quorum-based同期レプリケーション同期レプリケーション

syn ch ro n o u s_stan d b y_n amesにてスレーブのリストに対してANYを指定す

る事で、同期レプリケーションとなるスレーブが定足数に応じて任意に選択され

る。

[マスタのpo stg resq l.con f]

syn ch ro n o u s_stan d b y_n ames

10.0 W AL対象の拡充ハッシュインデックスのハッシュインデックスの W A L出力出力

従来は非推奨だったハッシュインデックスの活用が増える可能性あり。

SRの機能ではないが、関連事項として掲載。

[マスタのpo stg resq l.con f]

syn ch ro n o u s_stan d b y_n ames

バーバー

ジョンジョン分野または目的分野または目的概要概要関連パラメータ関連パラメータ

PostgreSQL Enterprise Consortium

Page 108 of 285

6. ロジカルレプリケーションロジカルレプリケーション

6.1. ロジカルレプリケーションの概要

6.1.1. 概要概要

Po stg reSQ L 10.0よりロジカルレプリケーション機能がサポートされました。ロジカルレプリケーションでは、テーブルデータに対する論理的な変更内容を用いて、サーバ間の

データレプリケーションを実現します。 Po stgreSQ L 9.0よりサポートされているストリーミングレプリケーションでは、データベースを構成するファイルの変更内容を物理的に複

製することで、サーバ間のデータレプリケーションを実現します。従来のストリーミングレプリケーションの物理的なレプリケーションと対比する形で、ロジカルレプリケーションと呼

称されています。

6.1.2. 特徴特徴

ロジカルレプリケーションは、PostgreSQ L 9.0よりサポートされているストリーミングレプリケーションと比較すると以下の特徴を持ちます。

任意のテーブルのみをレプリケーション可能

特定の処理(例えばINSERTのみ)のみをレプリケーション可能

異なるPostgreSQ Lバージョン間でのレプリケーション可能

レプリケーション先でテーブルデータの更新やインデックス定義が可能

ただし、レプリケーション先のテーブルデータを更新した場合や、特定の処理のみをレプリケーションする場合は、レプリケーション元とレプリケーション先でデータが異なる状態

になります。上記のような場合にデータの整合性はユーザが保証する必要があります。

6.1.3. アーキテクチャアーキテクチャ

ロジカルレプリケーションでは、Pu b lish er(パブリッシャ)/Sub scrib er(サブスクライバ)モデルを採用しており、レプリケーション元のサーバはPu b lish er、レプリケーション先のサー

バはSu b scrib erと呼称されます。 Pub lish er上には、レプリケーション対象とするテーブルの論理集合であるPu blica tion (パブリケーション)を定義し、 Su b scriber上に

は、レプリケーション対象するパブリケーションとその接続情報であるSu b scription (サブスクリプション)を定義します。ロジカルレプリケーションにおける各用語の説明を下表に

記載します。

表 6.1 用語説明

No. 用語用語説明説明

1 Pub lish er(パブリッシャ) レプリケーション元となるサーバ

2 Su b scrib er(サブスクライバ) レプリケーション先となるサーバ

3 Pub lication (パブリケーション) レプリケーション対象とするテーブルの定義。CR EATE PU B LICATIO Nコマンドで作成。

4 Su b scrip tion (サブスクリプション) レプリケーション対象するパブリケーションとその接続定義。CR E ATE SUB SCRIPTIO Nコマンドで作成。

5 Rep lica tion Slot(レプリケーションス

ロット)

レプリケーションの状態を保持するオブジェクト。Su b scriptio n 作成時に、Pu b lish er上に作成される。

デフォルトでは作成されるRep licatio n Slo tの名前は、Sub scrip tionの名前と同じに設定される。

ロジカルレプリケーションは、下記の2段階でレプリケーションが実施されます。

1. 初期データのスナップショット取得

2. データ変更内容の送受信によるデータ同期

動作は下図のイメージとなります。

PostgreSQL Enterprise Consortium

Page 109 of 285

Pu blish erからSub scrib erへの「2. データ変更内容の送受信によるデータ同期」は下図の処理で実施されます。

①. Pu b lish erのディスクにW ALが書き込まれる

②. Pu b lish erのw alsen derプロセスが更新内容を論理的な変更内容(論理変更)に変換

③. Su b scriberのlo g ical replication w o rk erプロセスに論理変更を送信

④. Su b scriberのlo g ical replication w o rk erプロセスは論理変更をテーブルに適用

6.1.4. ユースケースユースケース

ロジカルレプリケーションは以下のようなケースで有用と考えます。

1. 複数のD B サーバ上のデータを1台のDB サーバに統合したいケース(データ分析用途など)

2. 任意のテーブルデータのみをレプリケーションさせたいケース(システム間のデータの連携など)

3. 異なるバージョン間でレプリケーションさせたいケース(バージョンアップ時のデータ移行など)

ロジカルレプリケーションの典型的な利用例がPo stg reSQ Lの文書 [1] に記載されていますので、ご参照下さい。

[1] PostgreSQ L 10.0文書 - 第31章論理レプリケーション

6.1.5. 制限事項制限事項

ロジカルレプリケーションの制限事項は以下の通りです。(Po stg reSQ L 10時点)

PostgreSQL Enterprise Consortium

Page 110 of 285

表 6.2 ロジカルレプリケーション制限事項

No. 制限事項制限事項補足補足

1 データベーススキーマおよびDDLコマンドはレプリケー

ションされない

データベーススキーマは、p g_du mp --sch ema-o n lyを利用して移行可能

2 シーケンスはレプリケーションされないシーケンスはレプリケーションされないが、

シーケンスによって裏付けされたSERIAL型や識別列のデータは、テーブルデータの一部としてレプリケーショ

ン可能

3 TRUNCATEコマンドはレプリケーションされない D ELETEコマンドで回避することは可能

4 ラージオブジェクトはレプリケーションされない通常のテーブルにデータを格納する以外の回避方法なし

5 テーブル以外のオブジェクトはレプリケーションできな

い

ビュー、マテリアライズドビュー、パーティションのルートテーブル(親テーブル)、外部テーブルはレプリケーションし

ようとするとエラーになる

制限事項の詳細は、Po stg reSQ Lの文書 [2] に記載されていますので、ご参照下さい。

[2] PostgreSQ L 10.0文書 - 第31章論理レプリケーション 31.4. 制限事項

6.2. ロジカルレプリケーションの設定

ロジカルレプリケーションの設定手順について確認します。

ロジカルレプリケーションでは、レプリケーション対象とするテーブルを以下から選択することが可能です。

1. データベース内の全てのテーブルをレプリケーション(本書では「データベース単位の設定」と呼称)

2. データベースの任意のテーブルのみをレプリケーション(本書では「テーブル単位の設定」と呼称)

レプリケーション対象とするテーブルは、Pu b licatio n 作成時に指定します。

Pu blicatio n の作成コマンドであるCREATE PU B LICATIO Nコマンドの構文は以下の通りです。

CREATE PUBLICATION name

[ FOR TABLE [ ONLY ] table_name [ * ] [, ...]

| FOR ALL TABLES ]

[ WITH ( publication_parameter [= value] [, ... ] ) ]

CREATE PU B LICATIO Nコマンド実行時に「FO R ALL TAB LES」を指定した場合は、

データベース内の全てのテーブルがレプリケーション対象になり、

「FO R TAB LE」では、レプリケーション対象とするテーブルを指定します。

「CREATE PUBLICATIO N」コマンドの仕様は、Po stgreSQ Lの文書 [1] に記載されていますので、ご参照下さい。

[1] PostgreSQ L 10.0文書 - SQ Lコマンド CREATE PU B LICATIO N

■ 環境情報

手順は以下環境を前提に記載しております。

表 6.3 環境情報

項目項目説明説明

Po stg reSQ Lバージョン 10.1

O Sバージョン Cen tO S 7.4

サーバ構成(各ホスト名) 2サーバ(no d e1,no d e2)

6.2.1. データベース単位の設定データベース単位の設定

6.2.1.1. 検証目的検証目的

データベース内の全てのテーブルをレプリケーションする際の設定手順について確認します。

6.2.1.2. 検証内容検証内容

本検証では、下記のレプリケーション設定においてデータベース単位での、

柔軟なデータ連携(データレプリケーション)が実現可能かの検証を実施しました。

PostgreSQL Enterprise Consortium

Page 111 of 285

6.2.1.3. 検証環境検証環境

6.2.1.4. 検証手順検証手順

■ 事前準備

ロジカルレプリケーションの環境を設定するためn od e1およびn o d e2において、

Po stg reSQ L10のインストールやデータベースクラスタ初期化・設定を実施します。

1. 環境準備

該当サーバにssh にて接続します。

(node1,node2のサーバにおいて実施)

ssh接続を用いて、

該当環境へ接続

ユーザ: root

パスワード: xxxxxxx

2. ホスト名の設定

名前解決のために各サーバのホスト名を設定します。

(node1,node2のサーバにおいて実施)

# vi /etc/hosts

[下記をファイル末尾に追加]

192.168.56.101 node1

192.168.56.102 node2

3. 5432ポートの解放

Po stg reSQ L間の通信のため、5432ポートを解放します。

(node1,node2のサーバにおいて実施)

# firewall-cmd --permanent --add-port=5432/tcp

# firewall-cmd --reload

以下のコマンド5432でポートが解放されていることを確認します。

PostgreSQL Enterprise Consortium

Page 112 of 285

(node1,node2のサーバにおいて実施)

# firewall-cmd --list-ports

5432/tcp

4. Po stg reSQ L10のyu mレポジトリ追加

Po stg reSQ L10のyu mレポジトリ用のパッケージをインストールします。

(node1,node2のサーバにおいて実施)

# yum install -y https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-

x86_64/pgdg-centos10-10-1.noarch.rpm

以下のコマンドで該当のパッケージがインストールされたことを確認します。

(node1,node2のサーバにおいて実施)

# yum list installed pgdg-centos10.noarch

[省略]

インストール済みパッケージ

pgdg-centos10.noarch 10-1 installed

5. Po stg reSQ Lのインストール

yu mコマンドを用いて、Po stg reSQ Lをインストールします。

(node1,node2のサーバにおいて実施)

# yum install postgresql10 postgresql10-server postgresql10-libs postgresql10-contrib

以下のコマンドでパッケージをインストールされたことを確認します。

(node1,node2のサーバにおいて実施)

# yum list installed postgresql10 postgresql10-server postgresql10-libs postgresql10-

contrib

[省略]

インストール済みパッケージ

postgresql10.x86_64 10.1-1PGDG.rhel7

@pgdg10-updates-testing

postgresql10-contrib.x86_64 10.1-1PGDG.rhel7

@pgdg10-updates-testing

postgresql10-libs.x86_64 10.1-1PGDG.rhel7

@pgdg10-updates-testing

postgresql10-server.x86_64 10.1-1PGDG.rhel7

@pgdg10-updates-testing

6. 環境変数の設定

po stg resユーザの環境変数の設定を行います。

PostgreSQL Enterprise Consortium

Page 113 of 285

(node1,node2のサーバにおいて実施)

# su - postgres

$ vi ~/.bash_profile

[下記をファイル末尾に追加]

export PATH=${PATH}:/usr/pgsql-10/bin

export PGHOME=/usr/pgsql-10

export PGDATA=/var/lib/pgsql/10/data

export PGDATABASE=postgres

export PGPORT=5432

export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/pgsql-10/lib

以下のコマンドで環境変数の設定を確認します。($PGDATAの確認を例示しています。)

(node1,node2のサーバにおいて実施)

$ exit

ログアウト

# su - postgres

$ echo $PATH

/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/usr/pgsql-10/bin

$ echo $PGDATA

/var/lib/pgsql/10/data

7. データベースクラスタの作成

データベースクラスタの作成を実施します。

(node1,node2のサーバにおいて実施)

$ initdb -D $PGDATA -A trust -U postgres --no-locale --encoding UTF8

8. po stg resq l.con f修正

po stg resq l.con fに以下を設定します。

(node1,node2のサーバにおいて実施)

$ vi $PGDATA/postgresql.conf

[下記の修正を加える]

listen_addresses = '*'　 # 全てのネットワークインターフェースへの接続を受け付ける設定

wal_level = 'logical' # ロジカルレプリケーションに必要なWAL出力設定

max_wal_senders = 10 # wal senderプロセス数の最大数を10に設定(デフォルト値)

max_replication_slots = 10 # レプリケーションスロットの最大数を10に設定(デフォルト値)

log_line_prefix = '[%m][%d][%h][%u][%e][%p] ' # ログメッセージの解析時に必要な情報を付与

9. pg _h b a.con f

n od e1,n od e2間でのデータベース接続を許可します。

(node1,node2のサーバにおいて実施)

$ vi $PGDATA/pg_hba.conf

[下記の修正を加える]

host all all 192.168.56.0/24 trust

※ 上記の設定は、SubscriberがPublisherのデータベースに接続する際に利用されます。

そのため、Publisherにのみ上記設定が必要となります。

10. Po stgreSQ L起動

Po stg reSQ Lを起動します。

PostgreSQL Enterprise Consortium

Page 114 of 285

(node1,node2のサーバにおいて実施)

$ pg_ctl start

以下のコマンドでPo stg reSQ Lの起動を確認します。

(node1,node2のサーバにおいて実施)

$ pg_ctl status

pg_ctl: サーバが動作中です(PID: 3517)

/usr/pgsql-10/bin/postgres

■ ロジカルレプリケーションの動作確認(データベース単位)

1. 動作確認用のデータベース作成

本検証で利用するデータベースを作成します。

(node1,node2のサーバにおいて実施)

$ createdb logicalreptest

以下のコマンドでデータベースが作成されたことを確認します。

(node1,node2のサーバにおいて実施)

$ psql -U postgres -l

List of databases

----------------+----------+----------+---------+-------+-----------------------

logicalreptest | postgres | UTF8 | C | C |

[省略]

2. 動作確認用のテーブル作成

作成したデータベースにテスト用のテーブルを作成します。

(node1,node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE TABLE t1logical (c1 INT, PRIMARY KEY (c1));

=# CREATE TABLE t2logical (c1 INT, PRIMARY KEY (c1));

以下のコマンドで作成したテーブルを確認します。

=# \d

List of relations

Schema | Name | Type | Owner

--------+-----------+-------+----------

public | t1logical | table | postgres

public | t2logical | table | postgres

(2 rows)

3. Pu blicatio n 作成

n od e1上にデータベース内の全テーブル(作成したlog ica lとt2logicalテーブル)をレプリケーション対象とするPu b lication を作成します。

PostgreSQL Enterprise Consortium

Page 115 of 285

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE PUBLICATION pub_node1_logicaldb FOR ALL TABLES;

以下のコマンドでPu b licatio n が作成されたことを確認します。

作成したp u blication ではデータベース内の全テーブルをレプリケーション対象としているため、

All tab les列がtru eであることを確認します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# \dRp

List of publications

---------------------+----------+------------+---------+---------+---------

pub_node1_logicaldb | postgres | t | t | t | t

(1 row)

4. Subscrip tio n 作成

n od e2上にn o d e1上に作成したPu blica tion とレプリケーションするSub scrip tion を作成します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node2_logicaldb CONNECTION 'host=node1 dbname=logicalreptest

port=5432 user=postgres' PUBLICATION pub_node1_logicaldb;

以下のコマンドでSub scrip tion が作成されたことを確認します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node2_logicaldb | postgres | t | {pub_node1_logicaldb}

(1 row)

5. ロジカルレプリケーション簡易動作検証

テスト用に作成した2つのテーブルにレコードをそれぞれINSERTします。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# INSERT INTO t1logical VALUES (1);

=# INSERT INTO t2logical VALUES (2);

=# SELECT * FROM t1logical;

----

(1 rows)

=# SELECT * FROM t2logical;

----

(1 rows)

Subscrip tio n 側のテーブルにレコードがINSERTされていることを確認します。(レプリケーションされていることを確認)

PostgreSQL Enterprise Consortium

Page 116 of 285

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# SELECT * FROM t1logical;

----

1 <-- node1と同じ結果がレプリケーションされていること

(1 rows)

----

2 <-- node1と同じ結果がレプリケーションされていること

(1 rows)

6.2.2. テーブル単位の設定テーブル単位の設定

6.2.2.1. 検証目的検証目的

データベース内の任意のテーブルのみをレプリケーションする際の設定手順について確認します。

6.2.2.2. 検証内容検証内容

本検証では、下記のレプリケーション設定においてテーブル単位での

柔軟なデータ連携(データレプリケーション)が実現可能かの検証を実施しました。

6.2.2.3. 検証環境検証環境

6.2.2.4. 検証手順検証手順

データベース単位でレプリケーションの構築手順について確認します。

■ ロジカルレプリケーションの動作確認(テーブル単位)

1. 動作確認用のデータベース作成

本検証で利用するデータベースを作成します。

(node1,node2のサーバにおいて実施)

$ createdb logicalreptest2

以下のコマンドでデータベースが作成されたことを確認します。

PostgreSQL Enterprise Consortium

Page 117 of 285

(node1,node2のサーバにおいて実施)

$ psql -U postgres -l

List of databases

-----------------+----------+----------+---------+-------+-----------------------

logicalreptest2 | postgres | UTF8 | C | C |

[省略]

2. 動作確認用のテーブル作成

作成したデータベースに検証用のテーブルを作成します。

(node1,node2のサーバにおいて実施)

$ psql -U postgres logicalreptest2

=# CREATE TABLE t3logical (c1 INT, PRIMARY KEY (c1));

以下のコマンドでテーブルが作成されたことを確認します。

(node1,node2のサーバにおいて実施)

=# \d

List of relations

Schema | Name | Type | Owner

--------+-----------+-------+----------

public | t3logical | table | postgres

(1 row)

3. Pu blicatio n 作成

n od e1上にt3lo gicalテーブルのみをレプリケーション対象とするPu b lication を作成します。 (F O R TAB LEにt3logicalを指定)

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest2

=# CREATE PUBLICATION pub_node1_t3logical FOR TABLE t3logical;

以下のコマンドでPu b licatio n が作成されたことを確認します。作成したPu b lica tion では、All tables列がfalseであることを確認します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest2

=# \dRp

List of publications

---------------------+----------+------------+---------+---------+---------

pub_node1_t3logical | postgres | f | t | t | t

(1 row)

4. Subscrip tio n 作成

n od e2上にPub licatio n とレプリケーションするSu b scription を作成します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest2

=# CREATE SUBSCRIPTION sub_node2_t3logical CONNECTION 'host=node1 dbname=logicalreptest2

port=5432 user=postgres' PUBLICATION pub_node1_t3logical;

PostgreSQL Enterprise Consortium

Page 118 of 285

以下のコマンドでSub scrip tion が作成されたことを確認します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest2

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node2_t3logical | postgres | t | {pub_node1_t3logical}

(1 row)

5. ロジカルレプリケーション簡易動作検証

テスト用に作成したテーブルにレコードをINSERTします。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest2

=# INSERT INTO t3logical VALUES (1);

=# INSERT INTO t3logical VALUES (2);

=# SELECT * FROM t3logical;

----

(2 rows)

Subscrip tio n 側のテーブルにもレコードがINSERTされていることを確認します。(レプリケーションされていることを確認)

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest2

=# SELECT * FROM t3logical;

----

1 <-- node1と同じ結果がレプリケーションされていること

(2 rows)

6.2.3. レプリケーション対象とする更新処理の限定レプリケーション対象とする更新処理の限定

6.2.3.1. 検証目的検証目的

任意のテーブルをロジカルレプリケーションの対象とした状態で特定の更新処理のみを

レプリケーション対象とする際の手順を確認します。

6.2.3.2. 検証内容検証内容

本検証では、下記のレプリケーション設定において更新処理の限定が実現可能かの検証を実施しました。

6.2.3.3. 検証環境検証環境

PostgreSQL Enterprise Consortium

Page 119 of 285

6.2.3.4. 検証手順検証手順

■ 初期状態

1. レプリケーション状態の確認

現在のレプリケーション状態を確認します。

(node1,node2のサーバにおいて実施)

$ psql -x -U postgres -c "SELECT * FROM pg_stat_replication"

(0 rows)

2. テスト用データベース作成

本検証で利用するデータベースを作成します。

(node1,node2のサーバにおいて実施)

$ createdb testlogicalre

以下のコマンドでデータベースが作成された事を確認します。

(node1,node2のサーバにおいて実施)

$ psql -U postgres -l

List of databases

---------------+----------+----------+---------+-------+-----------------------

testlogicalre | postgres | UTF8 | C | C | <-- 作成したDB

を確認

[省略]

3. テスト用テーブル作成

作成したデータベースにテスト用のテーブルを作成します。

(node1,node2のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# CREATE TABLE t1logical (c1_no integer PRIMARY KEY, c2_date date);

=# SELECT * FROM t1logical;

c1_no | c2_date

-------+---------

(0 rows)

PostgreSQL Enterprise Consortium

Page 120 of 285

以下のコマンドで作成したテーブルを確認します。

(node1,node2のサーバにおいて実施)

=# \dt

List of relations

Schema | Name | Type | Owner

--------+-----------+-------+----------

public | t1logical | table | postgres

(1 row)

■ ロジカルレプリケーションでのレプリケーション内容の変更

1. Pu blicatio n とSu b scriptio n を作成

n od e1に作成したt1logicalテーブルに対し、in sertとu p d ateをレプリケーション対象とするPu b lication を作成します。

(node1のサーバにおいて実施)

=# CREATE PUBLICATION pub_test_node1 FOR TABLE t1logical WITH (publish='insert,

update'); <-- 指定した更新処理のみをレプリケーション

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

----------------+------------+-----------

pub_test_node1 | public | t1logical

(1 row)

以下のコマンドでPu b licatio n が作成された事を確認します。

作成したp u blication では対象のテーブルのin sertとu p dateをレプリケーション対象としているため、

In sertsとUp d ates列がtru eであることを確認します。

(node1のサーバにおいて実施)

=# \dRp

List of publications

----------------+----------+------------+---------+---------+---------

pub_test_node1 | postgres | f | t | t | f

<-- DELETEはレプリケーション対象に含めない

(1 row)

n od e2にn o de1に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node2のサーバにおいて実施)

=# CREATE SUBSCRIPTION sub_test_node2 CONNECTION 'host=node1 dbname=testlogicalre

port=5432 user=postgres' PUBLICATION pub_test_node1;

=# SELECT * FROM pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+-----------

16435 | 16430 | r | 0/181A380

(1 row)

以下のコマンドでSub scrip tion が作成された事を確認します。

PostgreSQL Enterprise Consortium

Page 121 of 285

(node2のサーバにおいて実施)

# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

----------------+----------+---------+------------------

sub_test_node2 | postgres | t | {pub_test_node1}

(1 row)

2. レプリケーション状態確認

現在のレプリケーション状態を確認します。

作成したPu b lica tion とSu b scription が正常にレプリケーションされているかを

applicatio n _n ame、state、syn c_state項目で確認します。

(node1のサーバにおいて実施)

$ psql -x -U postgres -c "SELECT * FROM pg_stat_replication"

-[ RECORD 1 ]----+------------------------------

pid | 1264

usesysid | 10

usename | postgres

application_name | sub_test_node2

<-- subscription_nameが表示される

client_addr | 192.168.56.102

client_hostname |

client_port | 53076

backend_start | 2017-12-20 10:44:04.503952+09

backend_xmin |

state | streaming

<-- streaming が表示される

sent_lsn | 0/181A380

write_lsn | 0/181A380

flush_lsn | 0/181A380

replay_lsn | 0/181A380

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

<-- async(非同期)

■ ロジカルレプリケーション動作確認

1. テーブルにデータを追加

テスト用に作成したPu b lication 側のテーブルにレコードをINSERTします。

(node1のサーバにおいて実施)

=# INSERT INTO t1logical VALUES (1,'2017/12/20');

=# SELECT * FROM t1logical;

c1_no | c2_date

-------+------------

1 | 2017-12-20

(1 row)

Subscrip tio n 側のテーブルにもレコードがINSERTされている事を確認します。(レプリケーションされている事を確認)

PostgreSQL Enterprise Consortium

Page 122 of 285

(node2のサーバにおいて実施)

=# SELECT * FROM t1logical;

c1_no | c2_date

-------+------------

1 | 2017-12-20

(1 row)

2. テーブルのデータを更新

Pu blicatio n 側のテーブルのレコードをUPDATEします。

(node1のサーバにおいて実施)

=# UPDATE t1logical SET c2_date = '2017/12/25' WHERE c1_no = 1;

=# SELECT * FROM t1logical;

c1_no | c2_date

-------+------------

1 | 2017-12-25

(1 row)

Subscrip tio n 側のテーブルでもレコードがUPD ATEされている事を確認します。(レプリケーションされている事を確認)

(node2のサーバにおいて実施)

=# SELECT * FROM t1logical;

c1_no | c2_date

-------+------------

1 | 2017-12-25

(1 row)

3. テーブルのデータを削除

Pu blicatio n 側のテーブルのレコードをDELETEします。

(node1のサーバにおいて実施)

=# DELETE FROM t1logical WHERE c1_no = 1;

=# SELECT * FROM t1logical;

c1_no | c2_date

-------+---------

(0 rows)

<-- 指定のデータが削除される

Subscrip tio n 側のテーブルではレコードがDELETEされていない事を確認します。(レプリケーションされていない事を確認)

(node2のサーバにおいて実施)

=# SELECT * FROM t1logical;

c1_no | c2_date

-------+------------

1 | 2017-12-25

<-- DELETEはレプリケーションされていない

(1 row)

6.2.4. 設定するパラメータ設定するパラメータ

ロジカルレプリケーションの構築に必要な設定について説明します。

6.2.4.1. 実行時パラメータ実行時パラメータ

PostgreSQL Enterprise Consortium

Page 123 of 285

ロジカルレプリケーションに関係する実行時パラメータは以下のとおりです。

表 6.4 ロジカルレプリケーションに関係する実行時パラメータ

パラメータ名パラメータ名パラメータの説明パラメータの説明設定するサーバ設定するサーバ

w al_level W ALに書かれる情報量。ロジカルレプリケーションでは

「lo g ical」を設定する。

ロジカルレプリケーションのPu blish er、

ストリーミングレプリケーションのマスタ

max_w al_send ers w al sen d erプロセスの最大数ロジカルレプリケーションのPu blish er、

ストリーミングレプリケーションのマスタ

max_log ical_rep lication _w o rk ers lo g ical replication w o rk erプロセスの最大数ロジカルレプリケーションのSu b scrib er

max_w orker_processes バックグラウンドプロセスの最大数ロジカルレプリケーションのPu blish er、Su b scrib er

max_syn c_w orkers_p er_sub scrip tion Su b scrip tion あたりのワーカープロセスの並列度ロジカルレプリケーションのSu b scrib er

max_replication _slots レプリケーションスロットの最大数ロジカルレプリケーションのPu blish er

ストリーミングレプリケーションのマスタ

6.2.4.2. 実行時パラメータと起動プロセスの関係実行時パラメータと起動プロセスの関係

いくつかの実行時パラメータはロジカルレプリケーション稼働時に起動されるプロセス数との関係を理解して設定値を決める必要があります。ここでは以下の実行時パラメー

タについて考察します。

max_w al_send ers

max_log ical_rep lication _w o rk ers

max_w orker_processes

max_syn c_w orkers_p er_sub scrip tion

max_replication _slots

■初期状態初期状態

本章は以下の環境を利用した検証結果を元に解説します。

PostgreSQL Enterprise Consortium

Page 124 of 285

ロジカルレプリケーションは、Pu b lish er1台、Su b scrib er1台で構成

ロジカルレプリケーションのPu blish er（サーバ1。IPアドレス 192｡168｡127｡31）では、データベースクラスタ内に1つのデータベースを作成

pu b d b: レプリケーション対象のテーブルを個別定義するPu b licatio n p u b 1を作成

pu b 1のレプリケーション対象としてテーブルdata1を設定

ロジカルレプリケーションのSubscrib er（サーバ2。IPアドレス 192.168.127.32）では、データベースクラスタ内に1つのデータベースを作成

sub d b: Pu b lish erのpu b d b データベースに定義したPub licatio n から変更データを受け取るSu b scrip tion sub 1およびテーブルd a ta1を作成

ここでPu blish er、Su b scrib erのプロセスを確認すると、以下のプロセスが起動していることがわかります。

lo g ical replication lau n ch er: Pu b lish er, Sub scriberに1つずつ

w al send er: Pu b lish erに1つ

lo g ical replication w o rk er: は Su b scrib erに1つ

(サーバ1において実施)

$ ps aux | grep postgres

postgres 2503 0.0 0.8 389296 16492 pts/0 S 15:15 0:00 /usr/pgsql-10/bin/postgres

postgres 2504 0.0 0.1 242108 1936 ? Ss 15:15 0:00 postgres: logger process

postgres 2506 0.0 0.1 389448 3664 ? Ss 15:15 0:00 postgres: checkpointer process

postgres 2507 0.0 0.1 389296 3428 ? Ss 15:15 0:00 postgres: writer process

postgres 2508 0.0 0.3 389296 6324 ? Ss 15:15 0:00 postgres: wal writer process

postgres 2509 0.0 0.1 389752 3048 ? Ss 15:15 0:00 postgres: autovacuum launcher

process

postgres 2510 0.0 0.1 244360 2204 ? Ss 15:15 0:00 postgres: stats collector process

postgres 2511 0.0 0.1 389588 2492 ? Ss 15:15 0:00 postgres: bgworker: logical

replication launcher

postgres 2513 0.0 0.3 392428 5788 ? Ss 15:15 0:00 postgres: wal sender process

repusr1 192.168.127.32(40906) idle

(サーバ2において実施)

$ ps aux | grep postgres

postgres 2387 0.0 0.8 389296 16492 pts/0 S 15:15 0:00 /usr/pgsql-10/bin/postgres

postgres 2388 0.0 0.1 242108 1932 ? Ss 15:15 0:00 postgres: logger process

postgres 2390 0.0 0.2 389448 3928 ? Ss 15:15 0:00 postgres: checkpointer process

postgres 2391 0.0 0.1 389296 3428 ? Ss 15:15 0:00 postgres: writer process

postgres 2392 0.0 0.3 389296 6324 ? Ss 15:15 0:00 postgres: wal writer process

postgres 2393 0.0 0.1 389752 3076 ? Ss 15:15 0:00 postgres: autovacuum launcher

process

postgres 2394 0.0 0.1 244360 2200 ? Ss 15:15 0:00 postgres: stats collector process

postgres 2395 0.0 0.1 389588 2756 ? Ss 15:15 0:00 postgres: bgworker: logical

replication launcher

postgres 2398 0.0 0.3 397072 6320 ? Ss 15:15 0:00 postgres: bgworker: logical

replication worker for subscription 16394

■Publication,Subscriptionを追加した時の起動プロセスを追加した時の起動プロセス

Pu blish er,Su b scrib erにそれぞれテーブルdata2を追加し、テーブルdata2を複製するPu b lication ,Su b scrip tion を作成します。

(サーバ1において実施)

pubdb=> CREATE TABLE data2 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

pubdb=> CREATE PUBLICATION pub2 FOR TABLE data2;

(サーバ2において実施)

subdb=> CREATE TABLE data2 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

subdb=# CREATE SUBSCRIPTION sub2 CONNECTION 'host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub2;

NOTICE: created replication slot "sub2" on publisher

CREATE SUBSCRIPTION

Pu blish erの動的統計情報ビューpg_stat_rep lication を見ると、今回追加したレプリケーション(RECO RD 1)元々設定済のレプリケーション(RECO RD 2)の情報が確認

できます。

PostgreSQL Enterprise Consortium

Page 125 of 285

(サーバ1において実施)

pubdb=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 2692

usesysid | 16385

usename | repusr1

application_name | sub2

client_addr | 192.168.127.32

client_hostname |

client_port | 40909

backend_start | 2017-12-14 16:22:28.821828+09

backend_xmin |

state | streaming

sent_lsn | 0/16D7B60

write_lsn | 0/16D7B60

flush_lsn | 0/16D7B60

replay_lsn | 0/16D7B60

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 2 ]----+------------------------------

pid | 2513

usesysid | 16385

usename | repusr1

application_name | sub1

client_addr | 192.168.127.32

client_hostname |

client_port | 40906

backend_start | 2017-12-14 15:15:46.183256+09

backend_xmin |

state | streaming

sent_lsn | 0/16D7B60

write_lsn | 0/16D7B60

flush_lsn | 0/16D7B60

replay_lsn | 0/16D7B60

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

ここでPu blish er、Su b scrib erのプロセスを確認すると以下のプロセスが起動しており、w al sen d er, lo g ical replication w orkerがそれぞれSub scription単位に起

動していることがわかります。

lo g ical replication lau n ch er: Pu b lish er, Sub scriberに1つずつで変化なし

w al send er: Pu b lish erに2つ

lo g ical replication w o rk er: Su b scriberに2つ

PostgreSQL Enterprise Consortium

Page 126 of 285

(サーバ1において実施)

$ ps aux | grep postgres

postgres 2503 0.0 0.8 389296 16492 pts/0 S 15:15 0:00 /usr/pgsql-10/bin/postgres

postgres 2504 0.0 0.1 242108 1936 ? Ss 15:15 0:00 postgres: logger process

postgres 2506 0.0 0.2 389448 4188 ? Ss 15:15 0:00 postgres: checkpointer process

postgres 2507 0.0 0.1 389296 3428 ? Ss 15:15 0:00 postgres: writer process

postgres 2508 0.0 0.3 389296 6324 ? Ss 15:15 0:00 postgres: wal writer process

postgres 2509 0.0 0.1 389752 3048 ? Ss 15:15 0:00 postgres: autovacuum launcher

process

postgres 2510 0.0 0.1 244360 2204 ? Ss 15:15 0:00 postgres: stats collector process

postgres 2511 0.0 0.1 389588 2492 ? Ss 15:15 0:00 postgres: bgworker: logical

replication launcher

postgres 2513 0.0 0.3 392428 5788 ? Ss 15:15 0:00 postgres: wal sender process

repusr1 192.168.127.32(40906) idle

postgres 2692 0.0 0.2 392292 5252 ? Ss 16:22 0:00 postgres: wal sender process

repusr1 192.168.127.32(40909) idle

(サーバ2において実施)

$ ps aux | grep postgres

postgres 2387 0.0 0.8 389296 16492 pts/0 S 15:15 0:00 /usr/pgsql-10/bin/postgres

postgres 2388 0.0 0.1 242108 1932 ? Ss 15:15 0:00 postgres: logger process

postgres 2390 0.0 0.2 389448 4192 ? Ss 15:15 0:00 postgres: checkpointer process

postgres 2391 0.0 0.1 389296 3428 ? Ss 15:15 0:00 postgres: writer process

postgres 2392 0.0 0.3 389296 6324 ? Ss 15:15 0:00 postgres: wal writer process

postgres 2393 0.0 0.1 389752 3076 ? Ss 15:15 0:00 postgres: autovacuum launcher

process

postgres 2394 0.0 0.1 244360 2200 ? Ss 15:15 0:00 postgres: stats collector process

postgres 2395 0.0 0.1 389588 2756 ? Ss 15:15 0:00 postgres: bgworker: logical

replication launcher

postgres 2398 0.0 0.3 397072 6320 ? Ss 15:15 0:00 postgres: bgworker: logical

replication worker for subscription 16394

postgres 2571 0.0 0.3 397072 5992 ? Ss 16:22 0:00 postgres: bgworker: logical

replication worker for subscription 16400

■初期データコピー実行中の起動プロセス初期データコピー実行中の起動プロセス

次にロジカルレプリケーションのSu b scriptio n 作成時に実行される初期データのコピー処理による起動プロセスの増減を確認します。ここではベンチマークツールp g b ench

を使ってあらかじめデータベースpub d b に1000万件の初期データを持つテーブルpgb en ch _acco u n tsを作成します。

(サーバ1において実施)

$ pgbench -i -s 10 -U pubusr1 pubdb

Pu blish erのデータベースp u b db に接続し、新たなPu b lication pu b 3を作成します。

(サーバ1において実施)

pubdb=> CREATE PUBLICATION pub3 FOR TABLE pgbench_accounts;

Subscrib erのデータベースsu b db に接続し、レプリケーション対象テーブルを作成します。

(サーバ2において実施)

subdb=> CREATE TABLE pgbench_accounts (aid INT PRIMARY KEY, bid INT, abalance INT, filler

character(84));

データベースsu b d b にSu b scription sub 3を作成し、ロジカルレプリケーションを開始します。

(サーバ2において実施)

subdb=# CREATE SUBSCRIPTION sub3 CONNECTION 'host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub3;

Subscrip tio n su b 3を作成した直後にPu b lish er,Su bscrib erの起動プロセスを確認すると、w al send er, logical replication w orkerがそれぞれSu b scription に

加えて初期データコピーを実行するプロセス分増えていることがわかります。

lo g ical replication lau n ch er: Pu b lish er, Sub scriberに1つずつで変化なし

PostgreSQL Enterprise Consortium

Page 127 of 285

w al send er: Pu b lish erに4つ。うち1つは初期データコピー用のプロセス

lo g ical replication w o rk er: Su b scriberに4つ。うち1つは初期データコピー用のプロセス

(サーバ1において実施)

$ ps aux | grep postgres

postgres 2503 0.0 0.6 389296 12532 ? S 12月14 0:01 /usr/pgsql-10/bin/postgres

postgres 2504 0.0 0.0 242108 1576 ? Ss 12月14 0:00 postgres: logger process

postgres 2506 0.0 2.2 389612 42160 ? Ss 12月14 0:00 postgres: checkpointer process

postgres 2507 0.0 0.1 389296 2892 ? Ss 12月14 0:00 postgres: writer process

postgres 2508 0.0 0.3 389296 5836 ? Ss 12月14 0:02 postgres: wal writer process

postgres 2509 0.0 0.1 389752 2564 ? Ss 12月14 0:00 postgres: autovacuum launcher

process

postgres 2510 0.0 0.0 244360 1816 ? Ss 12月14 0:02 postgres: stats collector process

postgres 2511 0.0 0.1 389588 2120 ? Ss 12月14 0:00 postgres: bgworker: logical

replication launcher

postgres 2513 0.0 1.9 425924 36336 ? Ss 12月14 0:24 postgres: wal sender process

repusr1 192.168.127.32(40906) idle

postgres 2692 0.0 1.9 425852 35920 ? Ss 12月14 0:24 postgres: wal sender process

repusr1 192.168.127.32(40909) idle

postgres 5731 0.0 0.2 392292 5248 ? Ss 10:15 0:00 postgres: wal sender process

repusr1 192.168.127.32(40958) idle

postgres 5732 19.8 0.4 392592 8788 ? Ss 10:15 0:01 postgres: wal sender process

repusr1 192.168.127.32(40959) COPY

(サーバ2において実施)

$ ps aux | grep postgres

postgres 2387 0.0 0.8 389296 16492 ? S 12月14 0:01 /usr/pgsql-10/bin/postgres

postgres 2388 0.0 0.1 242108 2000 ? Ss 12月14 0:00 postgres: logger process

postgres 2390 0.0 2.3 389612 43740 ? Ss 12月14 0:00 postgres: checkpointer process

postgres 2391 0.0 0.1 389296 3428 ? Ss 12月14 0:00 postgres: writer process

postgres 2392 0.0 0.3 389296 6324 ? Ss 12月14 0:01 postgres: wal writer process

postgres 2393 0.0 0.1 389752 3092 ? Ss 12月14 0:00 postgres: autovacuum launcher

process

postgres 2394 0.0 0.1 244360 2200 ? Ss 12月14 0:02 postgres: stats collector process

postgres 2395 0.0 0.1 389588 2756 ? Ss 12月14 0:00 postgres: bgworker: logical

replication launcher

postgres 2398 0.0 0.3 397072 6320 ? Ss 12月14 0:03 postgres: bgworker: logical

replication worker for subscription 16394

postgres 2571 0.0 0.3 397072 5992 ? Ss 12月14 0:03 postgres: bgworker: logical

replication worker for subscription 16400

postgres 5597 0.0 0.3 397072 5728 ? Ss 10:15 0:00 postgres: bgworker: logical

replication worker for subscription 16418

postgres 5598 83.0 3.5 397536 67052 ? Rs 10:15 0:06 postgres: bgworker: logical

replication worker for subscription 16418 sync 16413

なお、初期データのコピーが完了するとコピー用のプロセス(上記のPID 5732,5598)が終了し、w al sen d er,logical replication w orkerの数がSu b scrip tion と同じ3

つに変化することも確認できました。

■max_w orker_processesと起動プロセスの関係と起動プロセスの関係

max_w orker_processesはバックグラウンドプロセスの最大数を定義する実行時パラメータでデフォルト値は8です。ロジカルレプリケーションに関係するプロセスもバックグラ

ウンドプロセスとして起動するため、このパラメータとの関係を検証します。

まず、Su b scrib erのmax_w orker_processesを3に変更して再起動すると、サーバログに以下の様なエラーメッセージが出力されます。

(サーバ2のサーバログ)

2017-12-15 11:00:44.951 JST [5755] LOG: logical replication apply worker for subscription "sub1"

has started

2017-12-15 11:00:44.963 JST [5756] LOG: logical replication apply worker for subscription "sub2"

has started

2017-12-15 11:00:44.966 JST [5754] WARNING: out of background worker slots

2017-12-15 11:00:44.966 JST [5754] HINT: You might need to increase max_worker_processes.

この時、Su b scriberの動的統計情報ビューp g _stat_activityでバックグラウンドプロセスの情報を表示すると、lo g ical replication lau n ch er と log ical rep licatio n

w orker がそれぞれバックグラウンドプロセスとして起動していることがわかります。

PostgreSQL Enterprise Consortium

Page 128 of 285

(サーバ2において実施)

postgres=# select datname,pid,usename,backend_start,wait_event_type,wait_event,state,backend_type

from pg_stat_activity where backend_type = 'background worker';

| state | backend_type

---------+------+----------+-------------------------------+-----------------+---------------------

+-------+-------------------

| | background worker

| idle | background worker

| idle | background worker

| idle | background worker

一方でPu b lish erのmax_w orker_pro cessesを3に変更して再起動してもサーバログにエラーメッセージは出力されません。この時のPublish erのバックグラウンドプロセス

の情報を表示すると、lo g ical replication lau n ch er だけがカウントされ、w al sen d erはカウントされていません。

(サーバ1において実施)

pubdb=# select datname,pid,usename,backend_start,wait_event_type,wait_event,state,backend_type

from pg_stat_activity where backend_type = 'background worker';

| state | backend_type

---------+------+----------+-------------------------------+-----------------+---------------------

+-------+-------------------

| | background worker

このように、Pu blish erのw al sen derとSu b scriberのlo g ical replication w o rk erはともにSub scrip tion の数に合わせて増加しますが、Pu b lish erのw al send erは

max_w orker_processesで管理するバックグラウンドプロセスとは異なる扱いであることがわかりました。

6.2.4.3. 考察考察

検証結果を踏まえて以下の実行時パラメータの決め方について考察します。

■max_w al_senders

ロジカルレプリケーションでの起動数とストリーミングレプリケーションのスレーブ数を考慮して以下の数が必要です。

必要数 = (ストリーミングレプリケーションのスレーブ数) + (ロジカルレプリケーションのSub scrip tion 数 ✕ 2)

ロジカルレプリケーションの初期データ同期プロセスが起動する分を考慮して2倍する。

初期データ同期プロセスは max_syn c_w o rk ers_p er_su b scrip tion （デフォルト2）に応じて変化するため、ここを増やす場合は✕2の部分も変化す

る。

Po stg reSQ L10.1のデフォルト値は10。上記必要数で不足しそうなら変更しておく。

■max_logical_replication_workers

ロジカルレプリケーションでの起動数を考慮して以下の数が必要です。

必要数 = このサーバに作成するSub scrip tion の数 ✕ 2

ロジカルレプリケーションの初期データ同期時に増えるプロセス数を考慮して2倍する。

初期データ同期プロセスは max_syn c_w o rk ers_p er_su b scrip tion （デフォルト2）に応じて変化するため、ここを増やす場合は✕2の部分も変化す

る。

Po stg reSQ L10.1のデフォルト値は4。上記必要数で不足しそうなら変更しておく。

■max_w orker_processes

ロジカルレプリケーションでの起動数を考慮して以下の数が必要です。

必要数 = このサーバに作成するSub scrip tion の数 ✕ 2 + 1(= lo gical replica tion lau n ch erの分) + その他のバックグラウンドプロセス(任意)

初期データ同期プロセスは max_syn c_w o rk ers_p er_su b scrip tion （デフォルト2）に応じて変化するため、ここを増やす場合は✕2の部分も変化す

る。

Po stg reSQ L10.1のデフォルト値は8。上記必要数で不足しそうなら変更しておく。

■max_sync_workers_per_subscription

Po stg reSQ L10.1のデフォルト値は2で、この場合1つがレプリケーション用に確保されるため初期データ同期の並列度は1で固定されます。

初期データ同期の並列度は1テーブルにつき1までです。複数テーブルに対する同期処理の並列度は上がりますが、同じテーブルに対する並列度は上がりません。

■max_replication_slots

PostgreSQL Enterprise Consortium

Page 129 of 285

ロジカルレプリケーションでの作成数と合わせて以下の数が必要です。

必要数 = ロジカルレプリケーションで作成するSu bscrip tionの数 ✕ 2 + ストリーミングレプリケーションで作成するレプリケーションスロットの数(任意)

初期データ同期プロセスは一時的にレプリケーションスロットを作成するため、ここを増やす場合は✕2の部分も変化する。

Po stg reSQ L10.1のデフォルト値は10。上記必要数で不足しそうなら変更しておく。

6.3. ロジカルレプリケーションの応用

6.3.1. primary keyが定義されていないテーブルのレプリケーション設定が定義されていないテーブルのレプリケーション設定

6.3.1.1. 検証目的検証目的

primary keyが定義されていないテーブルにおけるロジカルレプリケーションの設定方法を確認します。

ロジカルレプリケーションでは、UPDATEもしくはDELTEをレプリケーションさせるために、変更したレコードを特定するための情報であるREPLICA IDENTITYをPu b lication 側

のテーブルに設定する必要があります。 REPLICA ID ENTITYが指定されていないテーブルがPu b licatio n に追加された場合、UPD ATEもしくはDELETEが行われるとエラー

が発生します。

デフォルトではp rimary keyが定義されたテーブルの場合、p rimary keyがR EPLICA IDENTITYとして自動設定されます。また、REPLICA ID E NTITYにユニークインデックス

(NO T NULLかつ部分インデックスや遅延可能インデックスではない)を設定することで、UPDATEとDELE TEのレプリケーションが可能です。テーブルに上記のキーが存在しな

い場合は、REPLICA IDENTITYにF ULLを設定することで、UPDATEとD ELETEのレプリケーションが可能です。[1]

REPLICA ID ENTITYは、ロジカルレプリケーション利用時において、W ALファイルに書き込む情報量に影響します。 REPLICA IDENTITYに指定された列では、変更前の古

いレコードがW ALファイルに書き込まれます。 FULLを指定した場合には、古いレコードを全てW ALファイルに書き込みため、非効率です。

REPLICA ID ENTITYの設定方法の詳細は、Po stgreSQ L 文書をご確認下さい。[2]

[1] PostgreSQ L 10.0文書 - 第31章論理レプリケーション 31.1. パブリケーション

[2] PostgreSQ L 10.0文書 - SQ Lコマンド ALTER TAB LE

6.3.1.2. 検証内容検証内容

primary keyが定義されていないテーブルにおけるレプリケーションが可能な否かを確認するため、下表のパターンでロジカルレプリケーションの設定を実施しました。パター

ンと動作確認結果は下表の通りです。(○:レプリケーション可能、× :レプリケーション不可)

表 6.5 primary keyが定義されていないテーブルの動作確認

テーブル構成テーブル構成 IN SERT UPDATE DELETE 備考備考

primary keyが定義されたテーブル ○ ○ ○ -

u n iq u e制約(n o t n u ll制約)とreplica

id en tityにu n iq u eインデックスを指定

○ ○ ○ -

上記に該当しないテーブル ○ × × Pu b lication 側のテーブルにDELETEお

よびUPDATEを実施した場合、エラーに

なる

上記に該当しないテーブルにreplica

id en tityにfu llを指定

○ ○ ○ -

6.3.1.3. 検証環境検証環境

PostgreSQL Enterprise Consortium

Page 130 of 285

6.3.1.4. 検証手順検証手順

1. 動作確認用のテーブル作成

テスト用のテーブルを作成します。

(node1,node2のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# CREATE TABLE t8logical (c1 INT, c2 TEXT, PRIMARY KEY (c1));

=# CREATE TABLE t9logical (c1 INT NOT NULL, c2 TEXT);

=# CREATE UNIQUE INDEX t9logical_ukey ON t9logical (c1);

=# ALTER TABLE t9logical REPLICA IDENTITY USING INDEX t9logical_ukey;

=# CREATE TABLE t10logical (c1 INT, c2 TEXT);

=# CREATE TABLE t11logical (c1 INT, c2 TEXT);

=# ALTER TABLE t11logical REPLICA IDENTITY FULL;

以下のコマンドでテーブルが作成されたことを確認します。

(node1,node2のサーバにおいて実施)

=# \d

List of relations

Schema | Name | Type | Owner

--------+------------+-------+----------

public | t10logical | table | postgres

public | t11logical | table | postgres

public | t8logical | table | postgres

public | t9logical | table | postgres

(4 rows)

2. Pu blicatio n 作成

n od e1上の各テーブルをレプリケーション対象とするPu b licatio n を作成します。

PostgreSQL Enterprise Consortium

Page 131 of 285

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# CREATE PUBLICATION pub_node1_t8logical FOR TABLE t8logical;

=# CREATE PUBLICATION pub_node1_t9logical FOR TABLE t9logical;

=# CREATE PUBLICATION pub_node1_t10logical FOR TABLE t10logical;

=# CREATE PUBLICATION pub_node1_t11logical FOR TABLE t11logical;

以下のコマンドでPu b licatio n が作成されたことを確認します。

(node1のサーバにおいて実施)

=# \dRp

List of publications

----------------------+----------+------------+---------+---------+---------

pub_node1_t10logical | postgres | f | t | t | t

pub_node1_t11logical | postgres | f | t | t | t

pub_node1_t8logical | postgres | f | t | t | t

pub_node1_t9logical | postgres | f | t | t | t

(5 rows)

3. Subscrip tio n 作成

n od e2上にn o d e1に作成したPu b lication とレプリケーションするSu b scrip tion を作成します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# CREATE SUBSCRIPTION sub_node2_t8logical CONNECTION 'host=node1 dbname=logicalreptest3

port=5432 user=postgres' PUBLICATION pub_node1_t8logical;

=# CREATE SUBSCRIPTION sub_node2_t9logical CONNECTION 'host=node1 dbname=logicalreptest3

port=5432 user=postgres' PUBLICATION pub_node1_t9logical;

=# CREATE SUBSCRIPTION sub_node2_t10logical CONNECTION 'host=node1

dbname=logicalreptest3 port=5432 user=postgres' PUBLICATION pub_node1_t10logical;

=# CREATE SUBSCRIPTION sub_node2_t11logical CONNECTION 'host=node1

dbname=logicalreptest3 port=5432 user=postgres' PUBLICATION pub_node1_t11logical;

以下のコマンドでSub scrip tion が作成されたことを確認します。

(node2のサーバにおいて実施)

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

----------------------+----------+---------+------------------------

sub_node2_t10logical | postgres | t | {pub_node1_t10logical}

sub_node2_t11logical | postgres | t | {pub_node1_t11logical}

sub_node2_t8logical | postgres | t | {pub_node1_t8logical}

sub_node2_t9logical | postgres | t | {pub_node1_t9logical}

(4 rows)

4. ロジカルレプリケーション動作検証確認

primary keyが定義されたテーブルに対して、INSERT,UPDATE,DELE TEを実施します。

PostgreSQL Enterprise Consortium

Page 132 of 285

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# INSERT INTO t8logical VALUES (1, 'MERRY CHRISTMAS');

=# INSERT INTO t8logical VALUES (2, 'CHRISTMAS DAY');

=# UPDATE t8logical SET c2 = 'HAPPY NEW YEAR' WHERE c1 = 2;

=# DELETE FROM t8logical WHERE c1 = 1;

=# SELECT * FROM t8logical;

c1 | c2

----+----------------

2 | HAPPY NEW YEAR

(1 row)

Subscrip tio n 側にデータが反映されていることを確認します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# SELECT * FROM t8logical;

c1 | c2

----+----------------

2 | HAPPY NEW YEAR

(1 row)

u n iq u e制約(n o t n u ll制約)とreplica id en tityにu n iq u eインデックスが定義されたテーブルに対して、INSERT,UPDATE,DELETEを実施します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# INSERT INTO t9logical VALUES (1, 'MERRY CHRISTMAS');

=# INSERT INTO t9logical VALUES (2, 'CHRISTMAS DAY');

=# UPDATE t9logical SET c2 = 'HAPPY NEW YEAR' WHERE c1 = 2;

=# DELETE FROM t9logical WHERE c1 = 1;

=# SELECT * FROM t9logical;

c1 | c2

----+----------------

2 | HAPPY NEW YEAR

(1 row)

Subscrip tio n 側にデータが反映されていることを確認します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# SELECT * FROM t9logical;

c1 | c2

----+----------------

2 | HAPPY NEW YEAR

(1 row)

上記に該当しないテーブルに対して、INSERT,U PD ATE,DELETEを実施します。

PostgreSQL Enterprise Consortium

Page 133 of 285

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# INSERT INTO t10logical VALUES (1, 'MERRY CHRISTMAS');

=# INSERT INTO t10logical VALUES (2, 'CHRISTMAS DAY');

=# UPDATE t10logical SET c2 = 'HAPPY NEW YEAR' WHERE c1 = 2;

ERROR: cannot update table "t10logical" because it does not have a replica identity and

publishes updates

HINT: To enable updating the table, set REPLICA IDENTITY using ALTER TABLE.

※ REPLICA IDENTITYが指定されていない場合は、UPDATEできない旨がメッセージとして出力される。

=# DELETE FROM t10logical WHERE c1 = 1;

ERROR: cannot delete from table "t10logical" because it does not have a replica

identity and publishes deletes

HINT: To enable deleting from the table, set REPLICA IDENTITY using ALTER TABLE.

=# SELECT * FROM t10logical;

c1 | c2

----+-----------------

1 | MERRY CHRISTMAS

2 | CHRISTMAS DAY

(2 rows)

Subscrip tio n 側にデータが反映されないことを確認します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# SELECT * FROM t10logical;

c1 | c2

----+-----------------

1 | MERRY CHRISTMAS

2 | CHRISTMAS DAY

(2 rows)

上記に該当しないテーブルにreplica id en tityにfu llを指定したテーブルに対して、INSERT,U PDATE,DELETEを実施します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# INSERT INTO t11logical VALUES (1, 'MERRY CHRISTMAS');

=# INSERT INTO t11logical VALUES (2, 'CHRISTMAS DAY');

=# UPDATE t11logical SET c2 = 'HAPPY NEW YEAR' WHERE c1 = 2;

=# DELETE FROM t11logical WHERE c1 = 1;

=# SELECT * FROM t11logical;

c1 | c2

----+----------------

2 | HAPPY NEW YEAR

(1 row)

Subscrip tio n 側にデータが反映されていることを確認します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest3

=# SELECT * FROM t11logical;

c1 | c2

----+----------------

2 | HAPPY NEW YEAR

(1 row)

6.3.2. 同期レプリケーション同期レプリケーション

6.3.2.1. 検証目的検証目的

PostgreSQL Enterprise Consortium

Page 134 of 285

6.3.2.1. 検証目的検証目的

ロジカルレプリケーションにおいて同期レプリケーションを設定する手順を確認します。

6.3.2.2. 検証内容検証内容

本検証では、下記のレプリケーション設定において同期モードが実現可能かの検証を実施しました。

6.3.2.3. 検証環境検証環境

6.3.2.4. 検証手順検証手順

■ 初期状態

1. レプリケーション状態の確認

現在のレプリケーション状態を確認します。

(node1,node2のサーバにおいて実施)

$ psql -x -U postgres -c "SELECT * FROM pg_stat_replication"

(0 rows)

2. テスト用データベース作成

本検証で利用するデータベースを作成します。

(node1,node2のサーバにおいて実施)

$ createdb testlogicaldb

以下のコマンドでデータベースが作成された事を確認します。

(node1,node2のサーバにおいて実施)

$ psql -U postgres -l

List of databases

---------------+----------+----------+---------+-------+-----------------------

testlogicaldb | postgres | UTF8 | C | C | <-- 作成したDB

を確認

[省略]

3. テスト用テーブル作成

作成したデータベースにテスト用のテーブルを作成します。

PostgreSQL Enterprise Consortium

Page 135 of 285

(node1,node2のサーバにおいて実施)

$ psql -U postgres testlogicaldb

=# CREATE TABLE t1logical (c1_no integer PRIMARY KEY, c2_date_time timestamp);

=# SELECT * FROM t1logical;

c1_no | c2_date_time

-------+--------------

(0 rows)

以下のコマンドで作成したテーブルを確認します。

(node1,node2のサーバにおいて実施)

=# \dt

List of relations

Schema | Name | Type | Owner

--------+-----------+-------+----------

public | t1logical | table | postgres

(1 row)

■ ロジカルレプリケーションでの作成

1. Pu blicatio n とSu b scriptio n を作成

n od e1に作成したt1logicalテーブルをレプリケーション対象とするPu b lication を作成します。

(node1のサーバにおいて実施)

=# CREATE PUBLICATION test_slot1 FOR TABLE t1logical;

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

------------+------------+-----------

test_slot1 | public | t1logical

(1 row)

以下のコマンドでPu b licatio n が作成された事を確認します。

=# \dRp

List of publications

------------+----------+------------+---------+---------+---------

test_slot1 | postgres | f | t | t | t <-- オールテーブ

ルではない

(1 row)

n od e2にn o de1に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node2のサーバにおいて実施)

=# CREATE SUBSCRIPTION test_slot1 CONNECTION 'host=node1 dbname=testlogicaldb port=5432

user=postgres' PUBLICATION test_slot1;

=# SELECT * FROM pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+------------

24755 | 24750 | r | 2/912A8A10

(1 row)

以下のコマンドでSub scrip tion が作成された事を確認します。

PostgreSQL Enterprise Consortium

Page 136 of 285

# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

------------+----------+---------+--------------

test_slot1 | postgres | t | {test_slot1}

(1 row)

2. レプリケーション状態確認

現在のレプリケーション状態を確認します。

作成したPu b lica tion とSu b scription が正常にレプリケーションされているかを

applicatio n _n ame、state、syn c_state項目で確認します。(syn c_stateは現時点ではasyn cとなります。)

(node1のサーバにおいて実施)

$ psql -x -U postgres -c "SELECT * FROM pg_stat_replication"

-[ RECORD 1 ]----+------------------------------

pid | 1667

usesysid | 10

usename | postgres

application_name | test_slot1

<-- subscription_nameが表示される

client_addr | 192.168.43.11

client_hostname |

client_port | 35564

backend_start | 2018-01-05 10:39:02.914132+09

backend_xmin |

state | streaming

<-- streaming が表示される

sent_lsn | 2/912A8A10

write_lsn | 2/912A8A10

flush_lsn | 2/912A8A10

replay_lsn | 2/912A8A10

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

<-- async(現時点では非同期)

■ 同期レプリケーションの設定

1. コマンドラインで設定

コマンドラインからレプリケーションの設定を同期レプリケーションにします。

(node1のサーバにおいて実施)

$ psql -U postgres testlogicaldb

=# ALTER SYSTEM SET synchronous_standby_names = 'test_slot1'; <--

application_nameを指定する

設定ファイルで同期レプリケーションに変更された事を確認します。

(node1のサーバにおいて実施)

$ cat /var/lib/pgsql/10/data/postgresql.auto.conf

# Do not edit this file manually!

# It will be overwritten by ALTER SYSTEM command.

synchronous_standby_names = 'test_slot1'

<-- 同期設定にapplication_nameが設定されている

PostgreSQL Enterprise Consortium

Page 137 of 285

設定ファイルの内容を反映します。

(node1のサーバにおいて実施)

$ pg_ctl reload

Po stg reSQ L起動時にsyn ch ro n o u s_stan d by_namesパラメータが読み込まれている事を確認します。

(nodeのサーバにおいてサーバ実施)

$ tail /var/lib/pgsql/10/data/log/postgresql-2018-01-05.log <-- ログで設定が

読み込まれていることを確認

LOG: received SIGHUP, reloading configuration files

LOG: parameter "synchronous_standby_names" changed to "test_slot1"

LOG: standby "test_slot1" is now a synchronous standby with priority 1

現在のレプリケーション状態を確認します。

syn c_stateがsyn cとなっている事を確認します。

(node1のサーバにおいて実施)

$ psql -x -U postgres -c "SELECT * FROM pg_stat_replication"

-[ RECORD 1 ]----+------------------------------

pid | 1667

usesysid | 10

usename | postgres

application_name | test_slot1

client_addr | 192.168.43.11

client_hostname |

client_port | 35564

backend_start | 2018-01-05 10:39:02.914132+09

backend_xmin |

state | streaming

sent_lsn | 2/912A8A10

write_lsn | 2/912A8A10

flush_lsn | 2/912A8A10

replay_lsn | 2/912A8A10

write_lag |

flush_lag |

replay_lag |

sync_priority | 1

sync_state | sync

<-- sync(同期)になる

■ ロジカルレプリケーション動作確認

1. テーブルにデータを追加

テスト用に作成したPu b lication 側のテーブルにレコードをINSERTします。

(node1のサーバにおいて実施)

$ psql -U postgres testlogicaldb

=# INSERT INTO t1logical VALUES (1,localtimestamp);

=# SELECT * FROM t1logical;

c1_no | c2_date_time

-------+----------------------------

1 | 2018-01-05 11:07:36.590471

(1 row)

Subscrip tio n 側のテーブルにもレコードがINSERTされている事を確認します。(レプリケーションされている事を確認)

PostgreSQL Enterprise Consortium

Page 138 of 285

(node2のサーバにおいて実施)

=# SELECT * FROM t1logical;

c1_no | c2_date_time

-------+----------------------------

1 | 2018-01-05 11:07:36.590471

(1 row)

2. テーブルのデータを更新

Pu blicatio n 側のテーブルのレコードをUPDATEします。

(node1のサーバにおいて実施)

=# UPDATE t1logical SET c2_date_time = localtimestamp WHERE c1_no = 1;

=# SELECT * FROM t1logical;

c1_no | c2_date_time

-------+----------------------------

1 | 2018-01-05 11:10:14.419084

(1 row)

Subscrip tio n 側のテーブルでもレコードがUPD ATEされている事を確認します。(レプリケーションされている事を確認)

(node2のサーバにおいて実施)

=# SELECT * FROM t1logical;

c1_no | c2_date_time

-------+----------------------------

1 | 2018-01-05 11:10:14.419084

(1 row)

3. テーブルのデータを削除

Pu blicatio n 側のテーブルのレコードをDELETEします。

(node1のサーバにおいて実施)

=# DELETE FROM t1logical WHERE c1_no = 1;

=# SELECT * FROM t1logical;

c1_no | c2_date_time

-------+--------------

(0 rows)

<-- 指定のデータが削除される

Subscrip tio n 側のテーブルでもレコードがDELETEされている事を確認します。(レプリケーションされている事を確認)

(node2のサーバにおいて実施)

=# SELECT * FROM t1logical;

c1_no | c2_date_time

-------+--------------

(0 rows)

<-- 指定のデータが削除される

4. テーブルロックを実施し同期レプリケーションを確認

Subscrip tio n 側のデータベース、テーブルのoid を確認します。

PostgreSQL Enterprise Consortium

Page 139 of 285

(node2のサーバにおいて実施)

=# SELECT oid, datname FROM pg_database;

oid | datname

-------+---------------

24748 | testlogicaldb

[省略]

=# SELECT oid, datname FROM pg_database;

relid | relname

-------+-----------------

24750 | t1logical

[省略]

Subscrip tio n 側のロック情報を確認します。

(node2のサーバにおいて実施)

=# SELECT locktype, database, relation, mode FROM pg_locks;

locktype | database | relation | mode

------------+----------+----------+-----------------

relation | 24748 | 11577 | AccessShareLock <--

ロックされていない

virtualxid | | | ExclusiveLock

(2 rows)

Subscrip tio n 側のテーブルをトランザクション内でロック状態のままにします。(ロックモード : EXCLU SIVE M O DE)

(node2のサーバにおいて実施)

=# BEGIN;

=# LOCK t1logical IN ACCESS EXCLUSIVE MODE ;

<-- テーブルをロック

Subscrip tio n 側のロック情報を確認します。

(node2のサーバにおいて実施)

=# SELECT locktype, database, relation, mode FROM pg_locks;

locktype | database | relation | mode

---------------+----------+----------+---------------------

relation | 24748 | 11577 | AccessShareLock

virtualxid | | | ExclusiveLock

transactionid | | | ExclusiveLock

relation | 24748 | 24750 | AccessExclusiveLock <-- テーブルをロッ

ク

[省略]

Subscrip tio n 側のテーブルがロック状態のまま、Pu b licatio n 側のテーブルにレコードをINSERTします。

Subscrip tio n 側(スタンバイ)からCommitの応答があるまで待機状態となります。

(ただし、60秒以上応答がない場合は、タイムアウトのログが出力されます。)

(node1のサーバにおいて実施)

=# INSERT INTO t1logical VALUES (1,localtimestamp); <--

セカンダリから commit 応答がないためプロンプトが止まる

PostgreSQL Enterprise Consortium

Page 140 of 285

(node1のサーバにおいて実施)

$ tail /var/lib/pgsql/10/data/log/postgresql-2018-01-05.log

LOG: terminating walsender process due to replication timeout <-- 設定値

wal_sender_timeout (default 60s)待ってログが出力される

[Ctrl+c]

Cancel request sent

WARNING: canceling wait for synchronous replication due to user request

DETAIL: The transaction has already committed locally, but might not have been

replicated to the standby.

INSERT 0 1

Subscrip tio n 側のテーブルロックを解除するとレプリケーションが動作します。

Subscrip tio n 側のテーブルでもレコードがINSERTされている事を確認します。

(node2のサーバにおいて実施)

=# COMMIT; <-- ロック解除

=# SELECT locktype, database, relation, mode FROM pg_locks;

locktype | database | relation | mode

------------+----------+----------+-----------------

relation | 24748 | 11577 | AccessShareLock <--

ロックされていない

virtualxid | | | ExclusiveLock

(2 rows)

=# SELECT * FROM t1logical ;

c1_no | c2_date_time

-------+----------------------------

1 | 2018-01-05 13:44:52.134441

<-- レプリケーションされている

(1 row)

6.3.3. 複数サブスクリプション複数サブスクリプション

6.3.3.1. 検証目的検証目的

ロジカルレプリケーションで複数のSu b scrip tion にレプリケーションが可能か確認します。

6.3.3.2. 検証内容検証内容

本検証では、3ノードで下記構成のレプリケーションが実現可能かの検証を実施しました。

6.3.3.3. 検証環境検証環境

PostgreSQL Enterprise Consortium

Page 141 of 285

6.3.3.4. 検証手順検証手順

■ ロジカルレプリケーションの動作確認(テーブル単位)

1. 動作確認用のデータベース作成

本検証で利用するデータベースを作成します。

(node1,node2,node3のサーバにおいて実施)

$ createdb logicalreptest

以下のコマンドでデータベースが作成された事を確認します。

(node1,node2,node3のサーバにおいて実施)

$ psql -U postgres -l

List of databases

----------------+----------+----------+---------+-------+-----------------------

logicalreptest | postgres | UTF8 | C | C |

[省略]

2. 動作確認用のテーブル作成

作成したデータベースにテスト用のテーブルを作成します。

(node1,node2,node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE TABLE t1logical (c1 INT, PRIMARY KEY (c1));

=# CREATE TABLE t2logical (c1 INT, PRIMARY KEY (c1));

=# CREATE TABLE t3logical (c1 INT, PRIMARY KEY (c1));

以下のコマンドで作成したテーブルを確認します。

PostgreSQL Enterprise Consortium

Page 142 of 285

(node1,node2,node3のサーバにおいて実施)

=# \dt

List of relations

Schema | Name | Type | Owner

--------+-----------+-------+----------

public | t1logical | table | postgres

public | t2logical | table | postgres

public | t3logical | table | postgres

(3 rows)

3. 1セット目Pu b lication 、Sub scrip tion 作成

n od e1に作成したt1logicalテーブルをレプリケーション対象とするPu b lication を作成します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE PUBLICATION pub_node1_t1logical FOR TABLE t1logical;

以下のコマンドでPu b licatio n が作成された事を確認します。

(node1のサーバにおいて実施)

=# \dRp

List of publications

---------------------+----------+------------+---------+---------+---------

pub_node1_t1logical | postgres | f | t | t | t

(1 row)

n od e2にn o de1に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node2_t1logical CONNECTION 'host=node1 dbname=logicalreptest

port=5432 user=postgres password=postgres' PUBLICATION pub_node1_t1logical;

以下のコマンドでSub scrip tion が作成された事を確認します。

(node2のサーバにおいて実施)

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node2_t1logical | postgres | t | {pub_node1_t1logical}

(1 row)

n od e3にn o de1に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node3_t1logical CONNECTION 'host=node1 dbname=logicalreptest

port=5432 user=postgres password=postgres' PUBLICATION pub_node1_t1logical;

以下のコマンドでSub scrip tion が作成された事を確認します。

PostgreSQL Enterprise Consortium

Page 143 of 285

(node3のサーバにおいて実施)

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node3_t1logical | postgres | t | {pub_node1_t1logical}

(1 row)

4. 2セット目Pu b lication 、Sub scrip tion 作成

n od e2に作成したt2logicalテーブルをレプリケーション対象とするPu b lication を作成します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE PUBLICATION pub_node2_t2logical FOR TABLE t2logical;

以下のコマンドでPu b licatio n が作成された事を確認します。

(node2のサーバにおいて実施)

=# \dRp

List of publications

---------------------+----------+------------+---------+---------+---------

pub_node2_t2logical | postgres | f | t | t | t

(1 row)

n od e3にn o de2に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node3_t2logical CONNECTION 'host=node2 dbname=logicalreptest

port=5432 user=postgres password=postgres' PUBLICATION pub_node2_t2logical;

以下のコマンドでSub scrip tion が作成された事を確認します。

(node3のサーバにおいて実施)

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node3_t1logical | postgres | t | {pub_node1_t1logical}

sub_node3_t2logical | postgres | t | {pub_node2_t2logical}

(2 rows)

n od e1にn o de2に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node1_t2logical CONNECTION 'host=node2 dbname=logicalreptest

port=5432 user=postgres password=postgres' PUBLICATION pub_node2_t2logical;

以下のコマンドでSub scrip tion が作成された事を確認します。

PostgreSQL Enterprise Consortium

Page 144 of 285

(node1のサーバにおいて実施)

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node1_t2logical | postgres | t | {pub_node2_t2logical}

(1 row)

5. 3セット目Pu b lication 、Sub scrip tion 作成

n od e3に作成したt3logicalテーブルをレプリケーション対象とするPu b lication を作成します。

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE PUBLICATION pub_node3_t3logical FOR TABLE t3logical;

以下のコマンドでPu b licatio n が作成された事を確認します。

=# \dRp

List of publications

---------------------+----------+------------+---------+---------+---------

pub_node3_t3logical | postgres | f | t | t | t

(1 row)

n od e3に作成したPu blication とレプリケーションするSub scrip tionを作成します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node2_t3logical CONNECTION 'host=node3 dbname=logicalreptest

port=5432 user=postgres password=postgres' PUBLICATION pub_node3_t3logical;

以下のコマンドでSub scrip tion が作成された事を確認します。

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node2_t1logical | postgres | t | {pub_node1_t1logical}

sub_node2_t3logical | postgres | t | {pub_node3_t3logical}

(2 rows)

n od e3に作成したPu blication とレプリケーションするSub scrip tionを作成します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node1_t3logical CONNECTION 'host=node3 dbname=logicalreptest

port=5432 user=postgres password=postgres' PUBLICATION pub_node3_t3logical;

以下のコマンドでSub scrip tion が作成された事を確認します。

PostgreSQL Enterprise Consortium

Page 145 of 285

(node1のサーバにおいて実施)

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node1_t2logical | postgres | t | {pub_node2_t2logical}

sub_node1_t3logical | postgres | t | {pub_node3_t3logical}

(2 rows)

6. 1セット目ロジカルレプリケーション動作検証

n od e1のPu b lication 側のテーブル(t1lo gical)にレコードをINSER Tします。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# INSERT INTO t1logical VALUES (1);

=# INSERT INTO t1logical VALUES (2);

=# SELECT * FROM t1logical;

----

(2 rows)

n od e2のSu b scription 側のテーブルにもレコードがINSER Tされている事を確認します。(レプリケーションされている事を確認)

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# SELECT * FROM t1logical;

----

1 <-- node1と同じ結果がレプリケーションされていること

(2 rows)

n od e3のSu b scription 側のテーブルにもレコードがINSER Tされている事を確認します。(レプリケーションされている事を確認)

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# SELECT * FROM t1logical;

----

1 <-- node1と同じ結果がレプリケーションされていること

(2 rows)

7. 2セット目ロジカルレプリケーション動作検証

n od e2のPu b lication 側のテーブル(t2lo gical)にレコードをINSER Tします。

PostgreSQL Enterprise Consortium

Page 146 of 285

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# INSERT INTO t2logical VALUES (3);

=# INSERT INTO t2logical VALUES (4);

=# SELECT * FROM t2logical;

----

(2 rows)

n od e3のSu b scription 側のテーブルにもレコードがINSER Tされている事を確認します。(レプリケーションされている事を確認)

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# SELECT * FROM t2logical;

----

3 <-- node2と同じ結果がレプリケーションされていること

(2 rows)

n od e1のSu b scription 側のテーブルにもレコードがINSER Tされている事を確認します。(レプリケーションされている事を確認)

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# SELECT * FROM t2logical;

----

3 <-- node2と同じ結果がレプリケーションされていること

(2 rows)

8. 3セット目ロジカルレプリケーション動作検証

n od e3のPu b lication 側のテーブル(t3lo gical)にレコードをINSER Tします。

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# INSERT INTO t3logical VALUES (5);

=# INSERT INTO t3logical VALUES (6);

=# SELECT * FROM t3logical;

----

(2 rows)

n od e2のSu b scription 側のテーブルにもレコードがINSER Tされている事を確認します。(レプリケーションされている事を確認)

PostgreSQL Enterprise Consortium

Page 147 of 285

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# SELECT * FROM t3logical;

----

5 <-- node3同じ結果がレプリケーションされていること

(2 rows)

n od e1のSu b scription 側のテーブルにもレコードがINSER Tされている事を確認します。(レプリケーションされている事を確認)

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# SELECT * FROM t3logical;

----

5 <-- node3と同じ結果がレプリケーションされていること

(2 rows)

■ 動作確認

1. VIEW でのステータス確認

n od e1での各Pu b licatio n /Subscrip tio n の定義を確認します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

・Publicationに設定したテーブルを確認

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

---------------------+------------+-----------

pub_node1_t1logical | public | t1logical

(1 row)

・レプリケーションしている状態の確認

=# SELECT pid, application_name, client_addr, state, sync_state FROM

pg_stat_replication;

pid | application_name | client_addr | state | sync_state

------+---------------------+---------------+-----------+------------

1291 | sub_node2_t1logical | node2 | streaming | async

1298 | sub_node3_t1logical | node3 | streaming | async

(2 rows)

・Subscriptionの設定情報

=# SELECT subslotname, subpublications, subconninfo FROM pg_subscription;

subslotname | subpublications |

subconninfo

---------------------+-----------------------+------------------------------------------

-----------------------------------

sub_node1_t2logical | {pub_node2_t2logical} | host=node2 dbname=logicalreptest

port=5432 user=postgres password=postgres

sub_node1_t3logical | {pub_node3_t3logical} | host=node3 dbname=logicalreptest

port=5432 user=postgres password=postgres

(2 rows)

n od e2での各Pu b licatio n /Subscrip tio n の定義を確認します。

PostgreSQL Enterprise Consortium

Page 148 of 285

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

・Publicationに設定したテーブルを確認

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

---------------------+------------+-----------

pub_node2_t2logical | public | t2logical

(1 row)

・レプリケーションしている状態の確認

=# SELECT pid, application_name, client_addr, state, sync_state FROM

pg_stat_replication;

pid | application_name | client_addr | state | sync_state

------+---------------------+---------------+-----------+------------

1323 | sub_node1_t2logical | node1 | streaming | async

1344 | sub_node3_t2logical | node3 | streaming | async

(2 rows)

・Subscriptionの設定情報

=# SELECT subslotname, subpublications, subconninfo FROM pg_subscription;

subslotname | subpublications |

subconninfo

---------------------+-----------------------+------------------------------------------

-----------------------------------

sub_node2_t3logical | {pub_node3_t3logical} | host=node3 dbname=logicalreptest

port=5432 user=postgres password=postgres

sub_node2_t1logical | {pub_node1_t1logical} | host=node1 dbname=logicalreptest

port=5432 user=postgres password=postgres

(2 rows)

n od e3での各Pu b licatio n /Subscrip tio n の定義を確認します。

PostgreSQL Enterprise Consortium

Page 149 of 285

(node3において実施)

$ psql -U postgres logicalreptest

・Publicationに設定したテーブルを確認

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

---------------------+------------+-----------

pub_node3_t3logical | public | t3logical

(1 row)

・レプリケーションしている状態の確認

=# SELECT pid, application_name, client_addr, state, sync_state FROM

pg_stat_replication;

pid | application_name | client_addr | state | sync_state

------+---------------------+---------------+-----------+------------

1346 | sub_node1_t3logical | node1 | streaming | async

1348 | sub_node2_t3logical | node2 | streaming | async

(2 rows)

・Subscriptionの設定情報

=# SELECT subslotname, subpublications, subconninfo FROM pg_subscription;

subslotname | subpublications |

subconninfo

---------------------+-----------------------+------------------------------------------

----------------------------------

sub_node3_t1logical | {pub_node1_t1logical} | host=node1 dbname=logicalreptest

port=5432 user=postgres password=postgres

sub_node3_t2logical | {pub_node2_t2logical} | host=node2 dbname=logicalreptest

port=5432 user=postgres password=postgres

(2 rows)

6.3.4. カスケード構成カスケード構成

6.3.4.1. 検証目的検証目的

ロジカルレプリケーションを利用したカスケード構成の挙動を確認します。

6.3.4.2. 検証内容検証内容

本検証では、下記構成のレプリケーションが実現可能かの検証を実施しました。

6.3.4.3. 検証環境検証環境

PostgreSQL Enterprise Consortium

Page 150 of 285

6.3.4.4. 検証手順検証手順

■ ロジカルレプリケーションの動作確認(テーブル単位)

1. 動作確認用のデータベース作成

本検証で利用するデータベースを作成します。

(node1,node2,node3のサーバにおいて実施)

$ createdb logicalreptest

以下のコマンドでデータベースが作成された事を確認します。

(node1,node2,node3のサーバにおいて実施)

$ psql -U postgres -l

List of databases

----------------+----------+----------+---------+-------+-----------------------

logicalreptest | postgres | UTF8 | C | C |

[省略]

2. 動作確認用のテーブル作成

作成したデータベースにテスト用のテーブルを作成します。

(node1,node2,node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE TABLE t1logical (c1 INT, PRIMARY KEY (c1));

以下のコマンドで作成したテーブルを確認します。

(node1,node2,node3のサーバにおいて実施)

=# \d

List of relations

Schema | Name | Type | Owner

--------+-----------+-------+----------

public | t1logical | table | postgres

(1 row)

3. Pu blicatio n 作成

n od e1に作成したt1logicalテーブルをレプリケーション対象とするPu b lication を作成します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE PUBLICATION pub_node1_t1logical FOR TABLE t1logical;

以下のコマンドでPu b licatio n が作成された事を確認します。

PostgreSQL Enterprise Consortium

Page 151 of 285

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# \dRp

List of publications

---------------------+----------+------------+---------+---------+---------

pub_node1_t1logical | postgres | f | t | t | t

(1 row)

4. Subscrip tio n 作成

n od e2にn o de1に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node2_t1logical CONNECTION 'host=node1 dbname=logicalreptest

port=5432 user=postgres password=postgres' PUBLICATION pub_node1_t1logical;

以下のコマンドでSub scrip tion が作成された事を確認します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node2_t1logical | postgres | t | {pub_node1_t1logical}

(1 row)

5. Pu blicatio n 作成

n od e1に作成したPu blication とレプリケーションする対象となっていたテーブル(t1lo g ical)を

新たにレプリケーション対象としたPu b lication をn o d e2に作成します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE PUBLICATION pub_node2_t1logical FOR TABLE t1logical;

以下のコマンドでPu b licatio n が作成された事を確認します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# \dRp

List of publications

---------------------+----------+------------+---------+---------+---------

pub_node2_t1logical | postgres | f | t | t | t

(1 row)

6. Subscrip tio n 作成

n od e3にn o de2に作成したPub licatio n とレプリケーションするSu b scription を作成します。

PostgreSQL Enterprise Consortium

Page 152 of 285

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node3_t1logical CONNECTION 'host=node2 dbname=logicalreptest

port=5432 user=postgres password=postgres' PUBLICATION pub_node2_t1logical;

以下のコマンドでSub scrip tion が作成された事を確認します。

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

---------------------+----------+---------+-----------------------

sub_node3_t1logical | postgres | t | {pub_node2_t1logical}

(1 row)

7. ロジカルレプリケーション簡易動作検証

n od e1のPu b lication 側のテーブルにレコードをINSERTします。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# INSERT INTO t1logical VALUES (1);

=# INSERT INTO t1logical VALUES (2);

=# SELECT * FROM t1logical;

----

(2 rows)

8. ロジカルレプリケーション簡易動作検証確認

n od e2のSu b scription 側のテーブルにもレコードがINSER Tされている事を確認します。(n od e1からレプリケーションされている事を確認)

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# SELECT * FROM t1logical;

----

1 <-- node1と同じ結果がレプリケーションされていること

(2 rows)

n od e3のSu b scription 側のテーブルにもレコードがINSER Tされている事を確認します。(n od e2からレプリケーションされている事を確認)

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# SELECT * FROM t1logical;

----

1 <-- node1と同じ結果がレプリケーションされていること

(2 rows)

■ 動作確認

PostgreSQL Enterprise Consortium

Page 153 of 285

1. VIEW でのステータス確認

n od e1でPu b lication の定義を確認します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

・Publicationに設定したテーブルを確認

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

---------------------+------------+-----------

pub_node1_t1logical | public | t1logical

(1 row)

・レプリケーションしている状態の確認

=# SELECT pid, application_name, client_addr, state, sync_state FROM

pg_stat_replication;

pid | application_name | client_addr | state | sync_state

------+---------------------+---------------+-----------+------------

31121| sub_node2_t1logical | node2 | streaming | async

(1 rows)

n od e2でのPu blica tion /Su b scrip tion の定義を確認します。

(node2のサーバにおいて実施)

$ psql -U postgres logicalreptest

・Publicationに設定したテーブルを確認

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

---------------------+------------+-----------

pub_node2_t1logical | public | t1logical

(1 row)

・レプリケーションしている状態の確認

=# SELECT pid, application_name, client_addr, state, sync_state FROM

pg_stat_replication;

pid | application_name | client_addr | state | sync_state

------+---------------------+---------------+-----------+------------

9185 | sub_node3_t1logical | node3 | streaming | async

(1 rows)

・Subscriptionの設定情報

=# SELECT subslotname, subpublications, subconninfo FROM pg_subscription;

subslotname | subpublications |

subconninfo

---------------------+-----------------------+------------------------------------------

-----------------------------------

sub_node2_t1logical | {pub_node1_t1logical} | host=node1 dbname=logicalreptest

port=5432 user=postgres password=postgres

(1 rows)

n od e3のSu b scription の定義を確認します。

PostgreSQL Enterprise Consortium

Page 154 of 285

(node3において実施)

$ psql -U postgres logicalreptest

・レプリケーションしている状態の確認

=# SELECT pid, application_name, client_addr, state, sync_state FROM

pg_stat_replication;

(0 rows)

・Subscriptionの設定情報

=# SELECT subslotname, subpublications, subconninfo FROM pg_subscription;

subslotname | subpublications |

subconninfo

---------------------+-----------------------+------------------------------------------

----------------------------------

sub_node3_t1logical | {pub_node2_t1logical} | host=node2 dbname=logicalreptest

port=5432 user=postgres password=postgres

(1 row)

■ 追加検証(Pu b lication とSub scrip tion の関係をループさせた場合の挙動)

1. Pu blicatio n 作成

n od e2に作成したPu blication とレプリケーションする対象となっていたテーブル(t1lo g ical)を

新たにレプリケーション対象としたPu b lication をn o d e3に作成します。

(node3のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE PUBLICATION pub_node3_t1logical FOR TABLE t1logical;

以下のコマンドでPu b licatio n が作成された事を確認します。

$ psql -U postgres logicalreptest

=# \dRp

List of publications

---------------------+----------+------------+---------+---------+---------

pub_node3_t1logical | postgres | f | t | t | t

(1 row)

2. Subscrip tio n 作成

n od e1にn o de3に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# CREATE SUBSCRIPTION sub_node1_t1logical CONNECTION 'host=node3 dbname=logicalreptest

port=5432 user=postgres password=postgres' PUBLICATION pub_node3_t1logical;

3. ロジカルレプリケーション簡易動作検証(ループ時)

レプリケーション元とレプリケーション先がループしているため、

初期データのコピー時に一意制約違反が発生し、5秒毎にエラーメッセージが出力されます。

PostgreSQL Enterprise Consortium

Page 155 of 285

(node1のサーバにおいて実施)

$ psql -U postgres logicalreptest

=# INSERT INTO t1logical VALUES (1);

(PostgreSQLログのエラーメッセージ)

[2018-01-31 17:18:03.060 JST][][][00000][444] LOG: logical replication table

synchronization worker for subscription "sub_node1_t1logical", table "t1logical" has

started

[2018-01-31 17:18:03.072 JST][][][23505][444] ERROR: duplicate key value violates

unique constraint "t1logical_pkey"

[2018-01-31 17:18:03.072 JST][][][23505][444] DETAIL: Key (c1)=(1) already exists.

[2018-01-31 17:18:03.072 JST][][][23505][444] CONTEXT: COPY t1logical, line 1

[2018-01-31 17:18:03.073 JST][][][00000][227] LOG: worker process: logical replication

worker for subscription 16393 sync 16385 (PID 444) exited with exit code 1

6.3.5. パーティショニングとの組み合わせパーティショニングとの組み合わせ

6.3.5.1. 検証構成検証構成

6.3.5.2. 組み合わせた場合の利点組み合わせた場合の利点

パーティショニングは大規模なテーブルに対し、データを複数テーブルに分割して格納する事で性能や運用性を向上させることができます。

また、ロジカルレプリケーションは論理的な変更内容を伝播させてレプリケーションさせる事で、複数サーバからデータを複製先のデータベースに集約させる事ができます。

これらを組み合わせる事で、複数サーバのデータを1つの集約サーバ上でパーティションテーブルとして管理する事が可能となります。

6.3.5.3. 検証内容検証内容

■ レプリケーション対象としたパーティショニングテーブルがSub scrib erに反映されることを確認する。

■ Pu blish erと同等の処理がSub scrib erのパーティショニングテーブルに行われる事を確認する。

■ 複数サーバの子テーブルを1つのサーバのパーティショニングテーブルに統合する構成が組めるか確認する。

6.3.5.4. 検証結果検証結果

■ 環境構築

1. レプリケーション状態の確認

現在のレプリケーション状態を確認します。

(node1,node2のサーバにおいて実施)

$ psql -x -U postgres -c "SELECT * FROM pg_stat_replication;"

(0 rows)

PostgreSQL Enterprise Consortium

Page 156 of 285

2. 試験用データベース作成

本検証で利用するデータベースを作成します。

(node1,node2のサーバにおいて実施)

$ createdb testlogicalre

以下のコマンドでデータベースが作成された事を確認します。

(node1,node2のサーバにおいて実施)

$ psql -U postgres -l

List of databases

---------------+----------+----------+---------+-------+-----------------------

testlogicalre | postgres | UTF8 | C | C |

[省略]

3. 試験用テーブル作成(p g ben ch )

作成したデータベースにpg b en ch を使用してテスト用のテーブルを作成します。

その後に、対象のテーブル(p g ben ch _h isto ry)をパーティション構文を用いてパーティショニング化します。

(node1,node2のサーバにおいて実施)

$ pgbench -i -U postgres testlogicalre

$ psql -U postgres testlogicalre

=# DROP TABLE pgbench_history;

=# CREATE TABLE pgbench_history(tid integer, bid integer, aid integer, delta integer,

mtime timestamp without time zone, filler character(22)) PARTITION BY RANGE (mtime);

=# CREATE TABLE pgbench_history_201801 PARTITION OF pgbench_history FOR VALUES FROM

('2018-01-01') TO ('2018-02-01');

=# CREATE TABLE pgbench_history_201712 PARTITION OF pgbench_history FOR VALUES FROM

('2017-12-01') TO ('2018-01-01');

=# CREATE TABLE pgbench_history_201711 PARTITION OF pgbench_history FOR VALUES FROM

('2017-11-01') TO ('2017-12-01');

=# ALTER TABLE pgbench_history_201801 ADD CONSTRAINT pgbench_history_201801_pkey PRIMARY

KEY(tid, aid);

=# ALTER TABLE pgbench_history_201712 ADD CONSTRAINT pgbench_history_201712_pkey PRIMARY

KEY(tid, aid);

=# ALTER TABLE pgbench_history_201711 ADD CONSTRAINT pgbench_history_201711_pkey PRIMARY

KEY(tid, aid);

=# SELECT relname, n_live_tup AS rowcount FROM pg_stat_all_tables WHERE relname LIKE

'pgbench_history%' ORDER BY relname;

relname | rowcount

------------------------+----------

pgbench_history_201711 | 0

pgbench_history_201712 | 0

pgbench_history_201801 | 0

(3 rows)

4. Pu blicatio n とSu b scriptio n を作成

n od e1に作成したパーティションの子テーブルをレプリケーション対象とするPu b licatio n を作成します。

PostgreSQL Enterprise Consortium

Page 157 of 285

(node1のサーバにおいて実施)

=# CREATE PUBLICATION pub_node1_parttables FOR TABLE pgbench_history_201711;

=# ALTER PUBLICATION pub_node1_parttables ADD TABLE pgbench_history_201712;

=# ALTER PUBLICATION pub_node1_parttables ADD TABLE pgbench_history_201801;

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

----------------------+------------+------------------------

pub_node1_parttables | public | pgbench_history_201801

pub_node1_parttables | public | pgbench_history_201712

pub_node1_parttables | public | pgbench_history_201711

(3 rows)

以下のコマンドでPu b licatio n が作成された事を確認します。

(node1のサーバにおいて実施)

=# \dRp

List of publications

----------------------+----------+------------+---------+---------+---------

pub_node1_parttables | postgres | f | t | t | t

(1 row)

n od e2にn o de1に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node2のサーバにおいて実施)

=# CREATE SUBSCRIPTION sub_node2_parttables CONNECTION 'host=node1 dbname=testlogicalre

port=5432 user=postgres' PUBLICATION pub_node1_parttables;

=# SELECT * FROM pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+------------

18381 | 18372 | r | 0/109C2570

18381 | 18369 | r | 0/109C2570

18381 | 18366 | r | 0/109C25A8

(3 rows)

以下のコマンドでSub scrip tion が作成された事を確認します。

(node2のサーバにおいて実施)

=# \dRs

List of subscriptions

Name | Owner | Enabled | Publication

----------------------+----------+---------+------------------------

sub_node2_parttables | postgres | t | {pub_node1_parttables}

(1 row)

■ ロジカルレプリケーション簡易動作確認

1. テーブルデータ追加

pg b ench で動作させるスクリプトを作成します。

PostgreSQL Enterprise Consortium

Page 158 of 285

(node1のサーバにおいて実施)

$ vi part_test.sql

-----

\set aid random(1, 90 * :scale)

\set bid random(1, 1 * :scale)

\set tid random(1, 10000 * :scale)

\set delta random(-5000, 5000)

BEGIN;

INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid,

:delta, CAST('2018-01-31' AS date) - CAST(:aid AS integer));

UPDATE pgbench_history SET filler = to_char(:bid + :delta, '9999') WHERE tid = :tid AND

aid = :aid;

END;

-----

n od e1のPu b lication 側のテーブルに対して、pg b ench でスクリプトを実行します。

(node1のサーバにおいて実施)

$ pgbench -U postgres -c 1 -t 1000 -f part_test.sql testlogicalre

レコードがパーティショニングテーブルに振り分けられている事を確認します。

(node1のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# ANALYZE;

=# SELECT relname, n_live_tup AS rowcount FROM pg_stat_all_tables WHERE relname LIKE

'pgbench_history%' ORDER BY relname;

relname | rowcount

------------------------+----------

pgbench_history_201711 | 348

pgbench_history_201712 | 332

pgbench_history_201801 | 320

(3 rows)

Pu blicatio n 側のパーティショニングテーブルのレコード情報を確認します。

PostgreSQL Enterprise Consortium

Page 159 of 285

(node1のサーバにおいて実施)

=# SELECT * FROM pgbench_history_201711 ORDER BY tid LIMIT 3;

tid | bid | aid | delta | mtime | filler

-----+-----+-----+-------+---------------------+------------------------

27 | 1 | 75 | 2772 | 2017-11-17 00:00:00 | 2773

125 | 1 | 90 | 1513 | 2017-11-02 00:00:00 | 1514

146 | 1 | 81 | -3348 | 2017-11-11 00:00:00 | -3347

(3 rows)

(node1のサーバにおいて実施)

=# SELECT * FROM pgbench_history_201712 ORDER BY tid LIMIT 3;

tid | bid | aid | delta | mtime | filler

-----+-----+-----+-------+---------------------+------------------------

66 | 1 | 35 | -4563 | 2017-12-27 00:00:00 | -4562

156 | 1 | 55 | 1206 | 2017-12-07 00:00:00 | 1207

231 | 1 | 51 | -894 | 2017-12-11 00:00:00 | -893

(3 rows)

(node1のサーバにおいて実施)

=# SELECT * FROM pgbench_history_201801 ORDER BY tid LIMIT 3;

tid | bid | aid | delta | mtime | filler

-----+-----+-----+-------+---------------------+------------------------

13 | 1 | 22 | 339 | 2018-01-09 00:00:00 | 340

22 | 1 | 29 | -1540 | 2018-01-02 00:00:00 | -1539

41 | 1 | 13 | -4569 | 2018-01-18 00:00:00 | -4568

(3 rows)

パーティショニングテーブルの予測行数がn o d e1と一致しているか否かを確認します。

(node2のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# ANALYZE;

=# SELECT relname, n_live_tup AS rowcount FROM pg_stat_all_tables WHERE relname LIKE

'pgbench_history%' ORDER BY relname;

relname | rowcount

------------------------+----------

pgbench_history_201711 | 348

pgbench_history_201712 | 332

pgbench_history_201801 | 320

(3 rows)

Subscrip tio n 側のパーティショニングテーブルでn o de1とレコードが一致している事を確認します。(レプリケーションされている事を確認)

PostgreSQL Enterprise Consortium

Page 160 of 285

(node2のサーバにおいて実施)

=# SELECT * FROM pgbench_history_201711 ORDER BY tid LIMIT 3;

tid | bid | aid | delta | mtime | filler

-----+-----+-----+-------+---------------------+------------------------

27 | 1 | 75 | 2772 | 2017-11-17 00:00:00 | 2773

125 | 1 | 90 | 1513 | 2017-11-02 00:00:00 | 1514

146 | 1 | 81 | -3348 | 2017-11-11 00:00:00 | -3347

(3 rows)

=# SELECT * FROM pgbench_history_201712 ORDER BY tid LIMIT 3;

tid | bid | aid | delta | mtime | filler

-----+-----+-----+-------+---------------------+------------------------

66 | 1 | 35 | -4563 | 2017-12-27 00:00:00 | -4562

156 | 1 | 55 | 1206 | 2017-12-07 00:00:00 | 1207

231 | 1 | 51 | -894 | 2017-12-11 00:00:00 | -893

(3 rows)

=# SELECT * FROM pgbench_history_201801 ORDER BY tid LIMIT 3;

tid | bid | aid | delta | mtime | filler

-----+-----+-----+-------+---------------------+------------------------

13 | 1 | 22 | 339 | 2018-01-09 00:00:00 | 340

22 | 1 | 29 | -1540 | 2018-01-02 00:00:00 | -1539

41 | 1 | 13 | -4569 | 2018-01-18 00:00:00 | -4568

(3 rows)

2. レプリケーション状態確認

現在のレプリケーション状態を確認します。

作成したPu b lica tion とSu b scription が正常にレプリケーションされているかを

applicatio n _n ame、state、syn c_state項目で確認します。

(node1のサーバにおいて実施)

$ psql -x -U postgres -c "SELECT * FROM pg_stat_replication;"

-[ RECORD 1 ]----+------------------------------

pid | 1446

usesysid | 10

usename | postgres

application_name | sub_node2_parttables <-- subscriptionの名前が表示される

client_addr | 192.168.56.102

client_hostname |

client_port | 52428

backend_start | 2018-02-05 10:21:33.710471+09

backend_xmin |

state | streaming <-- streaming が表示される

sent_lsn | 0/10A29160

write_lsn | 0/10A29160

flush_lsn | 0/10A29160

replay_lsn | 0/10A29160

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async <-- async(非同期)

■ テーブル追加

1. テーブル作成

新たにパーティショニングテーブルを作成します。

PostgreSQL Enterprise Consortium

Page 161 of 285

(node1,node2のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# CREATE TABLE pgbench_history_201802 PARTITION OF pgbench_history FOR VALUES FROM

('2018-02-01') TO ('2018-03-01');

=# ALTER TABLE pgbench_history_201802 ADD CONSTRAINT pgbench_history_201802_pkey PRIMARY

KEY(tid, aid);

以下のコマンドで作成したテーブルを確認します。

=# \dt

List of relations

Schema | Name | Type | Owner

--------+------------------------+-------+----------

public | pgbench_accounts | table | postgres

public | pgbench_branches | table | postgres

public | pgbench_history | table | postgres

public | pgbench_history_201711 | table | postgres

public | pgbench_history_201712 | table | postgres

public | pgbench_history_201801 | table | postgres

public | pgbench_history_201802 | table | postgres

public | pgbench_tellers | table | postgres

(8 rows)

2. 既存のロジカルレプリケーションにテーブルを追加

作成したパーティショニングテーブルを既存のPu b lication に追加します。

(node1のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# ALTER PUBLICATION pub_node1_parttables ADD TABLE pgbench_history_201802;

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

----------------------+------------+------------------------

pub_node1_parttables | public | pgbench_history_201801

pub_node1_parttables | public | pgbench_history_201712

pub_node1_parttables | public | pgbench_history_201711

pub_node1_parttables | public | pgbench_history_201802

(4 rows)

更新したPu b lica tion の情報をSub scrip tion に反映させます。

PostgreSQL Enterprise Consortium

Page 162 of 285

(node2のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# SELECT * FROM pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+------------

18381 | 18372 | r | 0/109C2570

18381 | 18369 | r | 0/109C2570

18381 | 18366 | r | 0/109C25A8

(3 rows)

=# ALTER SUBSCRIPTION sub_node2_parttables REFRESH PUBLICATION;

=# SELECT * FROM pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+------------

18381 | 18382 | r | 0/10A3EB98

18381 | 18372 | r | 0/109C2570

18381 | 18369 | r | 0/109C2570

18381 | 18366 | r | 0/109C25A8

(4 rows)

■ ロジカルレプリケーション動作確認

1. 新規テーブルにデータ追加

新たに作成したPu b licatio n 側のパーティショニングテーブルにレコードをINSERTします。

(node1のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# SELECT * FROM pgbench_history_201802;

tid | bid | aid | delta | mtime | filler

-----+-----+-----+-------+-------+--------

(0 rows)

=# INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (7777, 1, 12, 4321,

'2018-02-11 00:00:00');

=# SELECT * FROM pgbench_history_201802;

tid | bid | aid | delta | mtime | filler

------+-----+-----+-------+---------------------+--------

7777 | 1 | 12 | 4321 | 2018-02-11 00:00:00 |

(1 row)

Subscrip tio n 側のパーティショニングテーブルにもレコードがINSERTされている事を確認します。(レプリケーションされている事を確認)

(node2のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# SELECT * FROM pgbench_history_201802;

tid | bid | aid | delta | mtime | filler

------+-----+-----+-------+---------------------+--------

7777 | 1 | 12 | 4321 | 2018-02-11 00:00:00 |

(1 row)

■ 子テーブルの取り外し/取り付け

1. パーティションからテーブルを取り外し

n od e1のパーティショニングテーブルの取り外しとPub licatio n からの削除を行います。

PostgreSQL Enterprise Consortium

Page 163 of 285

(node1のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# SELECT * FROM pgbench_history WHERE tid = 7777;

tid | bid | aid | delta | mtime | filler

------+-----+-----+-------+---------------------+--------

7777 | 1 | 24 | 4321 | 2018-02-11 00:00:00 |

(1 row)

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

----------------------+------------+------------------------

pub_node1_parttables | public | pgbench_history_201801

pub_node1_parttables | public | pgbench_history_201712

pub_node1_parttables | public | pgbench_history_201711

pub_node1_parttables | public | pgbench_history_201802

(4 rows)

=# ALTER TABLE pgbench_history DETACH PARTITION pgbench_history_201802;

=# ALTER PUBLICATION pub_node1_parttables DROP TABLE pgbench_history_201802;

=# SELECT * FROM pgbench_history WHERE tid = 7777;

tid | bid | aid | delta | mtime | filler

-----+-----+-----+-------+-------+--------

(0 rows)

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

----------------------+------------+------------------------

pub_node1_parttables | public | pgbench_history_201801

pub_node1_parttables | public | pgbench_history_201712

pub_node1_parttables | public | pgbench_history_201711

(3 rows)

n od e2のパーティショニングテーブルの取り外しと更新したPu b licatio n の情報のSub scrip tion への反映を行います。

PostgreSQL Enterprise Consortium

Page 164 of 285

(node2のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# SELECT * FROM pgbench_history WHERE tid = 7777;

tid | bid | aid | delta | mtime | filler

------+-----+-----+-------+---------------------+--------

7777 | 1 | 24 | 4321 | 2018-02-11 00:00:00 |

(1 row)

=# SELECT * FROM pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+------------

18381 | 18382 | r | 0/10A3EB98

18381 | 18372 | r | 0/109C2570

18381 | 18369 | r | 0/109C2570

18381 | 18366 | r | 0/109C25A8

(4 rows)

=# ALTER TABLE pgbench_history DETACH PARTITION pgbench_history_201802;

=# ALTER SUBSCRIPTION sub_node2_parttables REFRESH PUBLICATION;

=# SELECT * FROM pgbench_history WHERE tid = 7777;

tid | bid | aid | delta | mtime | filler

-----+-----+-----+-------+-------+--------

(0 rows)

=# SELECT * FROM pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+------------

18381 | 18372 | r | 0/109C2570

18381 | 18369 | r | 0/109C2570

18381 | 18366 | r | 0/109C25A8

(3 rows)

2. パーティションにテーブルを取り付け

n od e1のパーティショニングテーブルの取り付けとPublicatio n への追加を行います。

(node1のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# TRUNCATE TABLE pgbench_history_201802;

=# ALTER TABLE pgbench_history ATTACH PARTITION pgbench_history_201802 FOR VALUES FROM

('2018-02-01') TO ('2018-03-01');

=# ALTER PUBLICATION pub_node1_parttables ADD TABLE pgbench_history_201802;

=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

----------------------+------------+------------------------

pub_node1_parttables | public | pgbench_history_201801

pub_node1_parttables | public | pgbench_history_201712

pub_node1_parttables | public | pgbench_history_201711

pub_node1_parttables | public | pgbench_history_201802

(4 rows)

n od e2のパーティショニングテーブルの取り付けと更新したPu blicatio n の情報のSub scrip tion への反映を行います。

PostgreSQL Enterprise Consortium

Page 165 of 285

(node2のサーバにおいて実施)

$ psql -U postgres testlogicalre

=# TRUNCATE TABLE pgbench_history_201802;

=# ALTER TABLE pgbench_history ATTACH PARTITION pgbench_history_201802 FOR VALUES FROM

('2018-02-01') TO ('2018-03-01');

=# ALTER SUBSCRIPTION sub_node2_parttables REFRESH PUBLICATION;

=# SELECT * FROM pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+------------

18381 | 18382 | r | 0/10A523F8

18381 | 18372 | r | 0/109C2570

18381 | 18369 | r | 0/109C2570

18381 | 18366 | r | 0/109C25A8

(4 rows)

■ 子テーブルをレプリケーションし、パーティショニングを構成

1. 試験用データベース作成

本検証で利用するデータベースを作成します。

(node1のサーバにおいて実施)

$ createdb testlogicalre2

(node2のサーバにおいて実施)

$ createdb testlogicalre2_c1

$ createdb testlogicalre2_c2

$ createdb testlogicalre2_c3

以下のコマンドでデータベースが作成された事を確認します。

PostgreSQL Enterprise Consortium

Page 166 of 285

(node1のサーバにおいて実施)

$ psql -U postgres -p 5432 -l

List of databases

----------------+----------+----------+---------+-------+-----------------------

testlogicalre2 | postgres | UTF8 | C | C |

[省略]

(node2のサーバにおいて実施)

$ psql -U postgres -p 5432 -l

List of databases

-------------------+----------+----------+---------+-------+-----------------------

testlogicalre2_c1 | postgres | UTF8 | C | C |

testlogicalre2_c2 | postgres | UTF8 | C | C |

testlogicalre2_c3 | postgres | UTF8 | C | C |

[省略]

2. 試験用テーブル作成(p g ben ch )

n od e1で作成したデータベースにpg b ench を使用してテスト用のテーブルを作成します。

その後に、対象のテーブル(p g ben ch _h isto ry)をパーティション構文を用いてパーティショニング化します。

(node1のサーバにおいて実施)

$ pgbench -i -U postgres testlogicalre2

$ psql -U postgres testlogicalre2

=# DROP TABLE pgbench_history;

=# CREATE TABLE pgbench_history(tid integer, bid integer, aid integer, delta integer,

mtime timestamp without time zone, filler character(22)) PARTITION BY RANGE (mtime);

=# CREATE TABLE pgbench_history_201711 PARTITION OF pgbench_history FOR VALUES FROM

('2017-11-01') TO ('2017-12-01');

=# CREATE TABLE pgbench_history_201712 PARTITION OF pgbench_history FOR VALUES FROM

('2017-12-01') TO ('2018-01-01');

=# CREATE TABLE pgbench_history_201801 PARTITION OF pgbench_history FOR VALUES FROM

('2018-01-01') TO ('2018-02-01');

=# ALTER TABLE pgbench_history_201711 ADD CONSTRAINT pgbench_history_201711_pkey PRIMARY

KEY(tid, aid);

=# ALTER TABLE pgbench_history_201712 ADD CONSTRAINT pgbench_history_201712_pkey PRIMARY

KEY(tid, aid);

=# ALTER TABLE pgbench_history_201801 ADD CONSTRAINT pgbench_history_201801_pkey PRIMARY

KEY(tid, aid);

=# SELECT relname, n_live_tup AS rowcount FROM pg_stat_all_tables WHERE relname LIKE

'pgbench_history%' ORDER BY relname;

relname | rowcount

------------------------+----------

pgbench_history_201711 | 0

pgbench_history_201712 | 0

pgbench_history_201801 | 0

(3 rows)

n od e2で作成した各データベースにテーブルを作成します。

PostgreSQL Enterprise Consortium

Page 167 of 285

(node2のサーバにおいて実施)

$ psql -U postgres -p 5432 testlogicalre2_c1

=# CREATE TABLE pgbench_history_201711(tid integer, bid integer, aid integer, delta

integer, mtime timestamp without time zone, filler character(22));

=# ALTER TABLE pgbench_history_201711 ADD CONSTRAINT pgbench_history_201711_pkey PRIMARY

KEY(tid, aid);

$ psql -U postgres -p 5432 testlogicalre2_c2

=# CREATE TABLE pgbench_history_201712(tid integer, bid integer, aid integer, delta

integer, mtime timestamp without time zone, filler character(22));

=# ALTER TABLE pgbench_history_201712 ADD CONSTRAINT pgbench_history_201712_pkey PRIMARY

KEY(tid, aid);

$ psql -U postgres -p 5432 testlogicalre2_c3

=# CREATE TABLE pgbench_history_201801(tid integer, bid integer, aid integer, delta

integer, mtime timestamp without time zone, filler character(22));

=# ALTER TABLE pgbench_history_201801 ADD CONSTRAINT pgbench_history_201801_pkey PRIMARY

KEY(tid, aid);

3. Pu blicatio n とSu b scriptio n を作成

n od e2の各データベースに作成したテーブルをレプリケーション対象とするPu b licatio n をそれぞれ作成します。

(node2のサーバにおいて実施)

$ psql -U postgres -p 5432 testlogicalre2_c1

=# CREATE PUBLICATION pub_node2_parttables1 FOR TABLE pgbench_history_201711;

$ psql -U postgres -p 5432 testlogicalre2_c2

=# CREATE PUBLICATION pub_node2_parttables2 FOR TABLE pgbench_history_201712;

$ psql -U postgres -p 5432 testlogicalre2_c3

=# CREATE PUBLICATION pub_node2_parttables3 FOR TABLE pgbench_history_201801;

n od e1にn o de2に作成したPub licatio n とレプリケーションするSu b scription を作成します。

(node1のサーバにおいて実施)

$ psql -U postgres -p 5432 testlogicalre2

=# CREATE SUBSCRIPTION sub_node1_parttables1 CONNECTION 'host=node2

dbname=testlogicalre2_c1 port=5432 user=postgres' PUBLICATION pub_node2_parttables1;

=# CREATE SUBSCRIPTION sub_node1_parttables2 CONNECTION 'host=node2

dbname=testlogicalre2_c2 port=5432 user=postgres' PUBLICATION pub_node2_parttables2;

=# CREATE SUBSCRIPTION sub_node1_parttables3 CONNECTION 'host=node2

dbname=testlogicalre2_c3 port=5432 user=postgres' PUBLICATION pub_node2_parttables3;

4. ロジカルレプリケーション簡易動作確認

n od e2の各データベースのPu blicatio n 側のテーブルにレコードをINSERTします。

PostgreSQL Enterprise Consortium

Page 168 of 285

(node2のサーバにおいて実施)

$ psql -U postgres -p 5432 testlogicalre2_c1

=# INSERT INTO pgbench_history_201711 (tid, bid, aid, delta, mtime) VALUES (1111, 1, 12,

4321, '2017-11-11 00:00:00');

=# SELECT * FROM pgbench_history_201711;

tid | bid | aid | delta | mtime | filler

------+-----+-----+-------+---------------------+--------

1111 | 1 | 12 | 4321 | 2017-11-11 00:00:00 |

(1 row)

$ psql -U postgres -p 5432 testlogicalre2_c2

=# INSERT INTO pgbench_history_201712 (tid, bid, aid, delta, mtime) VALUES (2222, 2, 34,

8765, '2017-12-11 00:00:00');

=# SELECT * FROM pgbench_history_201712;

tid | bid | aid | delta | mtime | filler

------+-----+-----+-------+---------------------+--------

2222 | 2 | 34 | 8765 | 2017-12-11 00:00:00 |

(1 row)

$ psql -U postgres -p 5432 testlogicalre2_c3

=# INSERT INTO pgbench_history_201801 (tid, bid, aid, delta, mtime) VALUES (3333, 3, 56,

2109, '2018-01-11 00:00:00');

=# SELECT * FROM pgbench_history_201801;

tid | bid | aid | delta | mtime | filler

------+-----+-----+-------+---------------------+--------

3333 | 3 | 56 | 2109 | 2018-01-11 00:00:00 |

(1 row)

Subscrip tio n 側のテーブルにもレコードがINSERTされている事を確認します。(レプリケーションされている事を確認)

(node1のサーバにおいて実施)

$ psql -U postgres -p 5432 testlogicalre2

=# SELECT * FROM pgbench_history;

tid | bid | aid | delta | mtime | filler

------+-----+-----+-------+---------------------+--------

3333 | 3 | 56 | 2109 | 2018-01-11 00:00:00 |

2222 | 2 | 34 | 8765 | 2017-12-11 00:00:00 |

1111 | 1 | 12 | 4321 | 2017-11-11 00:00:00 |

(3 rows)

6.4. ロジカルレプリケーションの運用

6.4.1. 監視監視

ロジカルレプリケーションが稼働する環境を監視する際に利用する情報について説明します。

6.4.1.1. 前提とする環境前提とする環境

本章は以下の環境を利用した検証結果を元に解説します。なお、ストリーミングレプリケーションと共用する情報(動的統計情報ビュー pg _stat_replication 等)もあるた

め、それぞれの表示形式の違いが比較できるようにロジカルレプリケーションとストリーミングレプリケーションを両方利用する環境を利用します。

PostgreSQL Enterprise Consortium

Page 169 of 285

Po stg reSQ Lサーバは3台構成

ロジカルレプリケーションは、Pu b lish er1台（サーバ1。IPアドレス 192｡168｡127｡31）、Sub scrib er1台（サーバ2。IPアドレス 192｡168｡127｡32）で構成

ストリーミングレプリケーションは、マスタ1台（Pu b lish erと同一）、スタンバイ1台（サーバ3。IPアドレス 192｡168｡127｡33）で構成

ロジカルレプリケーションのPu blish erでは、データベースクラスタ内に2つのデータベースを作成

pu b d b: レプリケーション対象のテーブルを個別定義するPu b licatio n を作成

pu b d b_all_tab le: データベース内に存在する全テーブルをレプリケーション対象とするPu b lication を作成

ロジカルレプリケーションのSubscrib erでは、データベースクラスタ内に2つのデータベースを作成

sub d b: Pu b lish erのpu b d b データベースに定義したPub licatio n から変更データを受け取るSu b scrip tion を作成

sub d b_all_table: Pu b lish erのpu b d b_all_tab leデータベースに定義したPu b lication から変更データを受け取るSub scrip tionを作成

6.4.1.2. ロジカルレプリケーションの設定ロジカルレプリケーションの設定

6.4.1.2.1. Publisherで確認できる情報で確認できる情報

Pu blish erのサーバにおいて、Pu b lica tion が作成されたデータベースに接続して確認できる情報は以下のとおりです。

■システムカタログシステムカタログ pg_pu blication [1]

接続中のデータベースに定義されているPu b lica tion の情報を確認できます。 Pu b lica tion の名前、所有者に加えて、レプリケーションが行われる更新処理の種別がわ

かります。また、FO R ALL TAB LES句を指定して作成したPu b licatio n は、pu balltables = t となります。

(サーバ1において実施)

pubdb=# select oid, * from pg_publication;

-------+---------+----------+--------------+-----------+-----------+-----------

16392 | pub1 | 16386 | f | t | t | t

16399 | pub2 | 16386 | f | t | t | t

16471 | pub3 | 10 | f | t | t | t

pubdb_all_table=# select oid, * from pg_publication;

-------+---------------+----------+--------------+-----------+-----------+-----------

16475 | pub_all_table | 10 | t | t | t | t

[1] PostgreSQ L 10.0文書 - 51.40. p g _pu b lication

■システムカタログシステムカタログ pg_pu blication_rel [2]

接続中のデータベースに定義されているPu b lica tion がレプリケーション対象とするテーブルを確認できます。

PostgreSQL Enterprise Consortium

Page 170 of 285

(サーバ1において実施)

pubdb=# select * from pg_publication_rel;

prpubid | prrelid

---------+---------

16392 | 16387

16399 | 16394

16471 | 16465

16392 | 16496

pubdb_all_table=# select * from pg_publication_rel;

prpubid | prrelid

---------+---------

ただし、Pu b lication 、テーブルのO IDしか保有しないため、実際に利用するには pg _p u b lication , pg_class と結合して、それぞれの名称を取得する必要があるでしょ

う。また、F O R ALL TAB LES句を指定して作成したPu blica tion ではレプリケーション対象となっているテーブルが表示されません。

[2] PostgreSQ L 10.0文書 - 51.41. p g _pu b lication _rel

■システムカタログシステムカタログ pg_pu blication_tables [3]

接続中のデータベースに定義されているPu b lica tion がレプリケーション対象とするテーブルを確認できます。

(サーバ1において実施)

pubdb=# select * from pg_publication_tables;

pubname | schemaname | tablename

---------+------------+-----------

pub1 | public | data1

pub1 | public | data1_1

pub2 | public | data2

pub3 | public | data3

pubdb_all_table=# select * from pg_publication_tables;

pubname | schemaname | tablename

---------------+------------+-----------

pub_all_table | public | data1

pub_all_table | public | data2

前述のp g_pu b licatio n _relと比較して、Pu b lication 、テーブルの名前が直接確認できること、 FO R ALL TAB LES句を指定して作成したPu blicatio n でもレプリケー

ション対象のテーブルが確認できることから実際の運用ではこちらを活用するとよいでしょう。

[3] PostgreSQ L 10.0文書 - 51.78. p g _pu b lication _tables

■psqlのメタコマンドのメタコマンド

psqlコマンドのメタコマンド「dR p + 」でもPu blicatio n の情報を確認できます。

PostgreSQL Enterprise Consortium

Page 171 of 285

(サーバ1において実施)

pubdb=# \dRp+

Publication pub1

Owner | All tables | Inserts | Updates | Deletes

---------+------------+---------+---------+---------

pubusr1 | f | t | t | t

Tables:

"public.data1"

"public.data1_1"

Publication pub2

Owner | All tables | Inserts | Updates | Deletes

---------+------------+---------+---------+---------

pubusr1 | f | t | t | t

Tables:

"public.data2"

Publication pub3

Owner | All tables | Inserts | Updates | Deletes

----------+------------+---------+---------+---------

postgres | f | t | t | t

Tables:

"public.data3"

pubdb_all_table=# \dRp+

Publication pub_all_table

Owner | All tables | Inserts | Updates | Deletes

----------+------------+---------+---------+---------

postgres | t | t | t | t

システムカタログpg_pu b lication , p g _pu blica tion _relの情報がまとめて表示されますが、 F O R ALL TAB LES句を指定して作成したPu blication のテーブルは表示さ

れません。

■システムカタログシステムカタログpg_replication_slots [4]

Pu blish erに自動作成されるロジカルレプリケーションスロットの情報を確認できます。

(サーバ1において実施)

pubdb=# select * from pg_replication_slots;

| xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn

---------------+----------+-----------+--------+-----------------+-----------+--------+------------

+------+--------------+-------------+---------------------

sub3 | pgoutput | logical | 16384 | pubdb | f | t | 31511

| | 684 | 0/56083970 | 0/560839A8

sub2 | pgoutput | logical | 16384 | pubdb | f | t | 31509

| | 684 | 0/56083970 | 0/560839A8

sub1 | pgoutput | logical | 16384 | pubdb | f | t | 32366

| | 684 | 0/56083970 | 0/560839A8

sub_all_table | pgoutput | logical | 16474 | pubdb_all_table | f | t | 31512

| | 684 | 0/56083970 | 0/560839A8

Pu blicatio n の情報は接続するデータベースに存在するものしか見えませんが、レプリケーションスロットはデータベースクラスタ内に存在するものが全て表示されます。なお、

slot_type はロジカルレプリケーションスロットでは log ical 、ストリーミングレプリケーションスロットは p h ysical と表示されます。

[4] PostgreSQ L 10.0文書 - 51.80. p g _replication _slots

6.4.1.2.2. Subscriberで確認できる情報で確認できる情報

Subscrib erのサーバにおいて、Su bscrip tion が作成されたデータベースに接続して確認できる情報は以下のとおりです。

■システムカタログシステムカタログ pg_subscription [5]

データベースに存在するSu bscrip tion の情報を確認できます。 Sub scriptionの名前、所有者に加えて、接続先のデータベース、Pu b licatio n の名前等がわかります。

なお、pg _p u b lication では接続したデータベース内のPu b licatio n のみが見えましたが、p g _su b scriptionでは接続したデータベースに関わらず、全ての

Subscrip tio n が表示されます。

PostgreSQL Enterprise Consortium

Page 172 of 285

(サーバ2において実施)

subdb=# select * from pg_subscription;

subdbid | subname | subowner | subenabled | subconninfo

| subslotname | subsynccommit | subpublications

---------+---------------+----------+------------+-------------------------------------------------

-------------------------+---------------+---------------+-----------------

16384 | sub2 | 10 | t | host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1 | sub2 | off | {pub2}

16384 | sub3 | 10 | t | host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1 | sub3 | off | {pub3}

16477 | sub_all_table | 10 | t | host=192.168.127.31 dbname=pubdb_all_table

user=repusr1 password=repusr1 | sub_all_table | off | {pub_all_table}

16384 | sub1 | 10 | t | host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1 | sub1 | off | {pub1}

[5] PostgreSQ L 10.0文書 - 51.52. p g _su b scriptio n

■システムカタログシステムカタログ pg_subscription_rel [6]

接続中のデータベースに定義されているSu b scrip tion がレプリケーション対象とするテーブルを確認できます。また、対象テーブルの他に、レプリケーションのステータス(i =

in itialize, d = d ata is b ein g cop ied , s = syn ch ro n ized , r = read y (n o rma l replication ))やLSNが表示されます。

(サーバ2において実施)

subdb=# select * from pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+------------

16463 | 16455 | r | 0/55FB63D0

16400 | 16395 | r | 0/16D7B60

16476 | 16470 | r | 0/55FDE4A0

16463 | 16490 | r | 0/56068D38

subdb_all_table=# select * from pg_subscription_rel;

srsubid | srrelid | srsubstate | srsublsn

---------+---------+------------+------------

16484 | 16479 | r | 0/5602B818

16484 | 16485 | r | 0/56048B00

ただし、Su bscrip tio n 、テーブルのO IDしか保有しないため、実際に利用するには p g_su b scrip tion , p g _class と結合して、それぞれの名称を取得する必要があるで

しょう。

[6] PostgreSQ L 10.0文書 - 51.53. p g _su b scriptio n _rel

■psqlのメタコマンドのメタコマンド

psqlコマンドのメタコマンド「dR s+」でもSu b scrip tion の情報を確認できます。システムカタログpg _sub scrip tion と同様の情報が見やすく整形されて表示されます。

PostgreSQL Enterprise Consortium

Page 173 of 285

(サーバ2において実施)

subdb=# \dRs+

List of subscriptions

------+----------+---------+-------------+--------------------+------------------------------------

----------------------------

sub1 | postgres | t | {pub1} | off | host=192.168.127.31 dbname=pubdb

user=repusr1 password=repusr1

sub2 | postgres | t | {pub2} | off | host=192.168.127.31 dbname=pubdb

user=repusr1 password=repusr1

sub3 | postgres | t | {pub3} | off | host=192.168.127.31 dbname=pubdb

user=repusr1 password=repusr1

subdb_all_table=# \dRs+

List of subscriptions

Conninfo

---------------+----------+---------+-----------------+--------------------+-----------------------

---------------------------------------------------

sub_all_table | postgres | t | {pub_all_table} | off | host=192.168.127.31

dbname=pubdb_all_table user=repusr1 password=repusr1

なお、pg _sub scrip tion ではデータベースクラスタ内のSUB SCRIPTIO Nが全て表示されたのに対し、メタコマンド「d R s+」では接続中のデータベース内のSub scriptio n

しか表示されません。

6.4.1.3. ロジカルレプリケーションの稼働状態ロジカルレプリケーションの稼働状態

6.4.1.3.1. Publisherで確認できる情報で確認できる情報

Pu blish erのサーバにおいて確認できる情報は以下のとおりです。

■サーバログサーバログ

CREATE PU B LICATIO N文を実行した時点ではPu b lish erのサーバログには何も表示されません。 Su bscrib erでCREATE SU B SCRIPTIO N文を実行した時点で以下

のログが出力されます。

(サーバ1のサーバログ)

2018-02-06 11:24:40.990 JST [20086] LOG: starting logical decoding for slot "sub_all_table"

2018-02-06 11:24:40.990 JST [20086] DETAIL: streaming transactions committing after 0/56084A90,

reading WAL from 0/56084A58

■動的統計情報ビュー動的統計情報ビュー pg_stat_replication [7]

ストリーミングレプリケーションと同様に、ロジカルレプリケーションの稼働状況を確認できます。接続中のデータベースに関わらず、データベースクラスタ全体の情報が表示さ

れます。

(サーバ1において実施)

postgres=# \x

postgres=# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 20086

usesysid | 16385

usename | repusr1

application_name | sub_all_table

client_addr | 192.168.127.32

client_hostname |

client_port | 46452

backend_start | 2018-02-06 11:24:40.988512+09

backend_xmin |

state | streaming

sent_lsn | 0/58000140

write_lsn | 0/58000140

flush_lsn | 0/58000140

replay_lsn | 0/58000140

write_lag |

flush_lag |

PostgreSQL Enterprise Consortium

Page 174 of 285

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 2 ]----+------------------------------

pid | 31511

usesysid | 16385

usename | repusr1

application_name | sub3

client_addr | 192.168.127.32

client_hostname |

client_port | 46353

backend_start | 2018-01-17 11:07:07.204636+09

backend_xmin |

state | streaming

sent_lsn | 0/58000140

write_lsn | 0/58000140

flush_lsn | 0/58000140

replay_lsn | 0/58000140

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 3 ]----+------------------------------

pid | 32366

usesysid | 16385

usename | repusr1

application_name | sub1

client_addr | 192.168.127.32

client_hostname |

client_port | 46411

backend_start | 2018-01-17 15:01:47.434102+09

backend_xmin |

state | streaming

sent_lsn | 0/58000140

write_lsn | 0/58000140

flush_lsn | 0/58000140

replay_lsn | 0/58000140

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 4 ]----+------------------------------

pid | 31509

usesysid | 16385

usename | repusr1

application_name | sub2

client_addr | 192.168.127.32

client_hostname |

client_port | 46351

backend_start | 2018-01-17 11:07:07.188398+09

backend_xmin |

state | streaming

sent_lsn | 0/58000140

write_lsn | 0/58000140

flush_lsn | 0/58000140

replay_lsn | 0/58000140

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 5 ]----+------------------------------

pid | 21625

usesysid | 16385

usename | repusr1

PostgreSQL Enterprise Consortium

Page 175 of 285

application_name | nk_PGECons3

client_addr | 192.168.127.33

client_hostname |

client_port | 55519

backend_start | 2018-02-06 16:00:40.749454+09

backend_xmin |

state | streaming

sent_lsn | 0/58000140

write_lsn | 0/58000140

flush_lsn | 0/58000140

replay_lsn | 0/58000140

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

ここでは RECO R D 1〜4 でサーバ1-2間のロジカルレプリケーション、RECO R D 5 でサーバ1-3間のストリーミングレプリケーションの情報が表示されています。ロジカルレプリ

ケーションとストリーミングレプリケーションはほぼ同じ形式で見えますが、app licatio n _nameはそれぞれ以下の情報が表示されています。

ロジカルレプリケーション：Su b scription の名前

ストリーミングレプリケーション：スレーブのreco very.con fに記載したapplicatio n _n ame

なお、Su b scrip tion を停止させると、p g _stat_rep licatio n から該当するレプリケージョンの情報が表示されなくなります。

(サーバ2において実施)

subdb=# ALTER SUBSCRIPTION sub1 DISABLE;

ALTER SUBSCRIPTION

pubdb=# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 20086

usesysid | 16385

usename | repusr1

application_name | sub_all_table

client_addr | 192.168.127.32

client_hostname |

client_port | 46452

backend_start | 2018-02-06 11:24:40.988512+09

backend_xmin |

state | streaming

sent_lsn | 0/580074E0

write_lsn | 0/580074E0

flush_lsn | 0/580074E0

replay_lsn | 0/580074E0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 2 ]----+------------------------------

pid | 31511

usesysid | 16385

usename | repusr1

application_name | sub3

client_addr | 192.168.127.32

client_hostname |

client_port | 46353

backend_start | 2018-01-17 11:07:07.204636+09

backend_xmin |

state | streaming

sent_lsn | 0/580074E0

write_lsn | 0/580074E0

flush_lsn | 0/580074E0

replay_lsn | 0/580074E0

write_lag |

flush_lag |

replay_lag |

PostgreSQL Enterprise Consortium

Page 176 of 285

sync_priority | 0

sync_state | async

-[ RECORD 3 ]----+------------------------------

pid | 31509

usesysid | 16385

usename | repusr1

application_name | sub2

client_addr | 192.168.127.32

client_hostname |

client_port | 46351

backend_start | 2018-01-17 11:07:07.188398+09

backend_xmin |

state | streaming

sent_lsn | 0/580074E0

write_lsn | 0/580074E0

flush_lsn | 0/580074E0

replay_lsn | 0/580074E0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 4 ]----+------------------------------

pid | 21625

usesysid | 16385

usename | repusr1

application_name | nk_PGECons3

client_addr | 192.168.127.33

client_hostname |

client_port | 55519

backend_start | 2018-02-06 16:00:40.749454+09

backend_xmin |

state | streaming

sent_lsn | 0/580074E0

write_lsn | 0/580074E0

flush_lsn | 0/580074E0

replay_lsn | 0/580074E0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

ロジカルレプリケーションもストリーミングレプリケーションも、p g _stat_rep lication の件数を定期的に確認することで稼働状況を監視するとよいでしょう。

[7] PostgreSQ L 10.0文書 - 表28.5 p g _stat_rep lication ビュー

6.4.1.3.2. Subscriberで確認できる情報で確認できる情報

Subscrib erのサーバにおいて確認できる情報は以下のとおりです。

■サーバログサーバログ

CREATE SUB SCR IPTIO N文を実行した時点で以下のログが出力されます。

(サーバ2のサーバログ)

2018-02-06 11:20:29.883 JST [4245] LOG: logical replication apply worker for subscription

"sub_all_table" has started

2018-02-06 11:20:29.888 JST [4246] LOG: logical replication table synchronization worker for

subscription "sub_all_table", table "data1" has started

2018-02-06 11:20:29.899 JST [4247] LOG: logical replication table synchronization worker for

subscription "sub_all_table", table "data2" has started

2018-02-06 11:20:29.901 JST [4246] LOG: logical replication table synchronization worker for

subscription "sub_all_table", table "data1" has finished

2018-02-06 11:20:29.912 JST [4247] LOG: logical replication table synchronization worker for

subscription "sub_all_table", table "data2" has finished

PostgreSQL Enterprise Consortium

Page 177 of 285

「lo g ical replica tion table syn ch ro n ization w ork er for sub scrip tion (Sub scrip tion 名), tab le (テーブル名) h as fin ish ed 」と出力されていれば、レプリケー

ション対象のテーブルに対する初期データの転送が完了しており正常にロジカルレプリケーションが開始したことが確認できます。

■動的統計情報ビュー動的統計情報ビュー pg_stat_subscription [8]

Subscrip tio n 単位にロジカルレプリケーションの稼働状況を確認できます。接続中のデータベースに関わらず、データベースクラスタ全体の情報が表示されます。

(サーバ2において実施)

subdb_all_table=# select * from pg_stat_subscription;

last_msg_receipt_time | latest_end_lsn | latest_end_time

-------+---------------+-------+-------+--------------+-------------------------------+------------

-------------------+----------------+-------------------------------

16400 | sub2 | 31707 | | 0/58000140 | 2018-02-06 16:00:07.649126+09 | 2018-02-06

16:00:07.482495+09 | 0/58000140 | 2018-02-06 16:00:07.649126+09

16476 | sub3 | 31709 | | 0/58000140 | 2018-02-06 16:00:07.649515+09 | 2018-02-06

16:00:07.482694+09 | 0/58000140 | 2018-02-06 16:00:07.649515+09

16463 | sub1 | 32626 | | 0/58000140 | 2018-02-06 16:00:07.649203+09 | 2018-02-06

16:00:07.482386+09 | 0/58000140 | 2018-02-06 16:00:07.649203+09

16508 | sub_all_table | 4267 | | 0/58000140 | 2018-02-06 16:00:07.649259+09 | 2018-02-06

16:00:07.482608+09 | 0/58000140 | 2018-02-06 16:00:07.649259+09

[8] PostgreSQ L 10.0文書 - 表28.7 p g _stat_su b scrip tion View

6.4.2. 障害時の動作確認障害時の動作確認

ロジカルレプリケーションが稼働する環境で障害が発生した場合の挙動を確認します。

6.4.2.1. 前提とする環境前提とする環境

本章は以下の環境を利用した検証結果を元に解説します。

PostgreSQL Enterprise Consortium

Page 178 of 285

ロジカルレプリケーションは、Pu b lish er1台、Su b scrib er1台で構成

ロジカルレプリケーションのPu blish er（サーバ1。IPアドレス 192｡168｡127｡31）では、データベースクラスタ内に1つのデータベースを作成

pu b d b: レプリケーション対象のテーブルを個別定義するPu b licatio n p u b 1を作成

ロジカルレプリケーションのSubscrib er（サーバ2。IPアドレス 192｡168｡127｡32）では、データベースクラスタ内に1つのデータベースを作成

sub d b: Pu b lish erのpu b d b データベースに定義したPub licatio n から変更データを受け取るSu b scrip tion sub 1を作成

6.4.2.2. 障害ケース障害ケース1 ロジカルレプリケーション関連プロセスの異常終了ロジカルレプリケーション関連プロセスの異常終了

ロジカルレプリケーションに関連する以下のプロセスが異常終了した時の挙動を確認します。

lo g ical replication lau n ch er

w al send er

lo g ical replication w o rk er

■初期状態初期状態

Pu blish erでは lo g ical replica tion lau n ch er と w al send er のプロセスが起動しています。また、pg_stat_replication でロジカルレプリケーションが稼働中であるこ

とが確認できます。

PostgreSQL Enterprise Consortium

Page 179 of 285

(サーバ1において実施)

-bash-4.2$ ps aux | grep postgres

postgres 2179 0.0 0.8 389356 16552 ? S 1月09 0:56 /usr/pgsql-10/bin/postgres

postgres 2180 0.0 0.1 242164 2404 ? Ss 1月09 0:00 postgres: logger process

postgres 2182 0.0 0.3 389496 5716 ? Ss 1月09 0:01 postgres: checkpointer process

postgres 2183 0.0 0.2 389356 4092 ? Ss 1月09 0:20 postgres: writer process

postgres 2184 0.0 0.3 389356 6744 ? Ss 1月09 0:23 postgres: wal writer process

postgres 2185 0.0 0.1 389812 3352 ? Ss 1月09 0:38 postgres: autovacuum launcher

process

postgres 2186 0.0 0.1 244420 2620 ? Ss 1月09 1:09 postgres: stats collector process

postgres 2187 0.0 0.1 389648 3060 ? Ss 1月09 0:01 postgres: bgworker: logical

replication launcher

postgres 21882 0.0 0.3 392540 5780 ? Ss 2月06 0:00 postgres: wal sender process

repusr1 192.168.127.32(46474) idle

pubdb=# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 21882

usesysid | 16385

usename | repusr1

application_name | sub1

client_addr | 192.168.127.32

client_hostname |

client_port | 46474

backend_start | 2018-02-06 16:40:08.541313+09

backend_xmin |

state | streaming

sent_lsn | 0/5800DBB0

write_lsn | 0/5800DBB0

flush_lsn | 0/5800DBB0

replay_lsn | 0/5800DBB0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

また、Su b scriberでは lo gical replicatio n lau n ch er と logical replica tion w orker のプロセスが起動しており、 pg_stat_su b scriptio n からもロジカルレプリケー

ションが稼働中であることが確認できます。

PostgreSQL Enterprise Consortium

Page 180 of 285

(サーバ2において実施)

-bash-4.2$ ps aux | grep postgres

postgres 5405 0.0 0.3 397072 6264 ? Ss 2月06 0:02 postgres: bgworker: logical

replication worker for subscription 16463

postgres 31698 0.0 0.8 389296 16496 ? S 1月17 0:47 /usr/pgsql-10/bin/postgres

postgres 31699 0.0 0.1 242108 2008 ? Ss 1月17 0:00 postgres: logger process

postgres 31701 0.0 0.2 389448 4724 ? Ss 1月17 0:00 postgres: checkpointer process

postgres 31702 0.0 0.1 389296 3436 ? Ss 1月17 0:15 postgres: writer process

postgres 31703 0.0 0.3 389296 6332 ? Ss 1月17 0:18 postgres: wal writer process

postgres 31704 0.0 0.1 389752 3132 ? Ss 1月17 0:32 postgres: autovacuum launcher

process

postgres 31705 0.0 0.1 244360 2264 ? Ss 1月17 1:07 postgres: stats collector process

postgres 31706 0.0 0.1 389588 2760 ? Ss 1月17 0:01 postgres: bgworker: logical

replication launcher

subdb=# select * from pg_stat_subscription;

-[ RECORD 1 ]---------+------------------------------

subid | 16463

subname | sub1

pid | 5405

relid |

received_lsn | 0/5800DBB0

last_msg_send_time | 2018-02-07 13:45:31.222443+09

last_msg_receipt_time | 2018-02-07 13:45:31.05565+09

latest_end_lsn | 0/5800DBB0

latest_end_time | 2018-02-07 13:45:31.222443+09

■logical replication launcherの停止の停止

Pu blish erのlo g ical replica tion lau n ch er をKillコマンドで強制終了すると再度別のプロセスID で起動されていることがわかります。

(サーバ1において実施)

-bash-4.2$ kill -9 2187

-bash-4.2$ ps aux | grep postgres

postgres 2179 0.0 0.8 389356 16552 ? S 1月09 0:56 /usr/pgsql-10/bin/postgres

postgres 2180 0.0 0.1 242168 2404 ? Ss 1月09 0:00 postgres: logger process

postgres 28990 0.0 0.1 389356 2152 ? Ss 13:56 0:00 postgres: checkpointer process

postgres 28991 0.0 0.1 389356 2156 ? Ss 13:56 0:00 postgres: writer process

postgres 28992 0.0 0.1 389356 2116 ? Ss 13:56 0:00 postgres: wal writer process

postgres 28993 0.0 0.1 389784 3004 ? Ss 13:56 0:00 postgres: autovacuum launcher

process

postgres 28994 0.0 0.1 244288 1988 ? Ss 13:56 0:00 postgres: stats collector process

postgres 28995 0.0 0.1 389656 2520 ? Ss 13:56 0:00 postgres: bgworker: logical

replication launcher

この時Pu b lish er、Su b scriberのログにはそれぞれ以下のメッセージが出力されています。

PostgreSQL Enterprise Consortium

Page 181 of 285

(サーバ1のサーバログ)

2018-02-07 13:56:05.609 JST [2179] LOG: worker process: logical replication launcher (PID 2187)

was terminated by signal 9: Killed

2018-02-07 13:56:05.609 JST [2179] LOG: terminating any other active server processes

2018-02-07 13:56:05.609 JST [21882] WARNING: terminating connection because of crash of another

server process

2018-02-07 13:56:05.609 JST [21882] DETAIL: The postmaster has commanded this server process to

roll back the current transaction and exit, because another server process exited abnormally and

possibly corrupted shared memory.

2018-02-07 13:56:05.609 JST [21882] HINT: In a moment you should be able to reconnect to the

database and repeat your command.

2018-02-07 13:56:05.614 JST [2185] WARNING: terminating connection because of crash of another

server process

2018-02-07 13:56:05.614 JST [2185] DETAIL: The postmaster has commanded this server process to

roll back the current transaction and exit, because another server process exited abnormally and

possibly corrupted shared memory.

2018-02-07 13:56:05.614 JST [2185] HINT: In a moment you should be able to reconnect to the

database and repeat your command.

2018-02-07 13:56:05.620 JST [28988] FATAL: the database system is in recovery mode

2018-02-07 13:56:05.621 JST [2179] LOG: all server processes terminated; reinitializing

2018-02-07 13:56:05.652 JST [28989] LOG: database system was interrupted; last known up at 2018-

02-07 13:45:23 JST

2018-02-07 13:56:05.692 JST [28989] LOG: database system was not properly shut down; automatic

recovery in progress

2018-02-07 13:56:05.693 JST [28989] LOG: redo starts at 0/5800DAD0

2018-02-07 13:56:05.693 JST [28989] LOG: invalid record length at 0/5800DBB0: wanted 24, got 0

2018-02-07 13:56:05.693 JST [28989] LOG: redo done at 0/5800DB78

2018-02-07 13:56:05.698 JST [2179] LOG: database system is ready to accept connections

2018-02-07 13:56:10.640 JST [28998] LOG: starting logical decoding for slot "sub1"

2018-02-07 13:56:10.640 JST [28998] DETAIL: streaming transactions committing after 0/5800DB78,

reading WAL from 0/5800DB78

2018-02-07 13:56:10.640 JST [28998] LOG: logical decoding found consistent point at 0/5800DB78

2018-02-07 13:56:10.640 JST [28998] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

WARNING: terminating connection because of crash of another server process

DETAIL: The postmaster has commanded this server process to roll back the current transaction and

exit, because another server process exited abnormally and possibly corrupted shared memory.

HINT: In a moment you should be able to reconnect to the database and repeat your command.

2018-02-07 13:56:05.444 JST [5405] ERROR: could not receive data from WAL stream: server closed

the connection unexpectedly

This probably means the server terminated abnormally

before or while processing the request.

2018-02-07 13:56:05.446 JST [31698] LOG: worker process: logical replication worker for

subscription 16463 (PID 5405) exited with exit code 1

2018-02-07 13:56:05.450 JST [9938] LOG: logical replication apply worker for subscription "sub1"

has started

2018-02-07 13:56:05.453 JST [9938] ERROR: could not connect to the publisher: FATAL: the database

system is in recovery mode

2018-02-07 13:56:05.454 JST [31698] LOG: worker process: logical replication worker for

subscription 16463 (PID 9938) exited with exit code 1

2018-02-07 13:56:10.463 JST [9939] LOG: logical replication apply worker for subscription "sub1"

has started

上記より、Pu b lish erのlo g ical replication lau n ch erが停止した場合、Pu b lish erのインスタンス再起動、リカバリ処理が行われた後にレプリケーションが再開されること

がわかりました。

同様に、Su b scriberのlog ical replica tion lau n ch er をKillコマンドで強制終了した場合も、再度別のプロセスIDで起動されていることがわかります。また、この時

Subscrib erのインスタンス再起動、リカバリ処理が行われてからレプリケーションが再開されています。

PostgreSQL Enterprise Consortium

Page 182 of 285

(サーバ2において実施)

-bash-4.2$ kill -9 31706

-bash-4.2$ ps aux | grep postgres

postgres 9947 0.0 0.1 389296 2124 ? Ss 13:57 0:00 postgres: checkpointer process

postgres 9948 0.0 0.1 389296 2128 ? Rs 13:57 0:00 postgres: writer process

postgres 9949 0.0 0.1 389296 2108 ? Rs 13:57 0:00 postgres: wal writer process

postgres 9950 0.0 0.1 389616 2980 ? Ss 13:57 0:00 postgres: autovacuum launcher

process

postgres 9951 0.0 0.1 244228 2008 ? Ss 13:57 0:00 postgres: stats collector process

postgres 9952 0.0 0.1 389588 2760 ? Ss 13:57 0:00 postgres: bgworker: logical

replication launcher

postgres 9953 0.0 0.3 397084 6240 ? Ss 13:57 0:00 postgres: bgworker: logical

replication worker for subscription 16463

postgres 31698 0.0 0.8 389296 16500 ? S 1月17 0:47 /usr/pgsql-10/bin/postgres

postgres 31699 0.0 0.1 242108 2008 ? Ss 1月17 0:00 postgres: logger process

(サーバ1のサーバログ)

2018-02-07 13:57:43.391 JST [28998] LOG: unexpected EOF on standby connection

2018-02-07 13:57:43.498 JST [29004] LOG: starting logical decoding for slot "sub1"

2018-02-07 13:57:43.498 JST [29004] DETAIL: streaming transactions committing after 0/5800DC58,

reading WAL from 0/5800DC20

2018-02-07 13:57:43.498 JST [29004] LOG: logical decoding found consistent point at 0/5800DC20

2018-02-07 13:57:43.498 JST [29004] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-02-07 13:57:43.216 JST [31698] LOG: worker process: logical replication launcher (PID 31706)

was terminated by signal 9: Killed

2018-02-07 13:57:43.216 JST [31698] LOG: terminating any other active server processes

2018-02-07 13:57:43.218 JST [31704] WARNING: terminating connection because of crash of another

server process

2018-02-07 13:57:43.218 JST [31704] DETAIL: The postmaster has commanded this server process to

roll back the current transaction and exit, because another server process exited abnormally and

possibly corrupted shared memory.

2018-02-07 13:57:43.218 JST [31704] HINT: In a moment you should be able to reconnect to the

database and repeat your command.

2018-02-07 13:57:43.226 JST [31698] LOG: all server processes terminated; reinitializing

2018-02-07 13:57:43.250 JST [9946] LOG: database system was interrupted; last known up at 2018-02-

07 13:46:06 JST

2018-02-07 13:57:43.309 JST [9946] LOG: recovered replication state of node 1 to 0/5800DA98

2018-02-07 13:57:43.309 JST [9946] LOG: database system was not properly shut down; automatic

recovery in progress

2018-02-07 13:57:43.310 JST [9946] LOG: redo starts at 0/73706380

2018-02-07 13:57:43.310 JST [9946] LOG: invalid record length at 0/73706460: wanted 24, got 0

2018-02-07 13:57:43.310 JST [9946] LOG: redo done at 0/73706428

2018-02-07 13:57:43.315 JST [31698] LOG: database system is ready to accept connections

2018-02-07 13:57:43.327 JST [9953] LOG: logical replication apply worker for subscription "sub1"

has started

■w al senderの停止の停止

Pu blish erのw al sen derをKillコマンドで強制終了します。

PostgreSQL Enterprise Consortium

Page 183 of 285

(サーバ1において実施)

-bash-4.2$ kill -9 29004

-bash-4.2$ ps aux | grep postgres

postgres 2179 0.0 0.8 389356 16552 ? S 1月09 0:56 /usr/pgsql-10/bin/postgres

postgres 2180 0.0 0.1 242168 2404 ? Ss 1月09 0:00 postgres: logger process

postgres 29085 0.0 0.1 389356 2156 ? Ss 14:12 0:00 postgres: checkpointer process

postgres 29086 0.0 0.1 389356 2160 ? Ss 14:12 0:00 postgres: writer process

postgres 29087 0.0 0.1 389356 2120 ? Ss 14:12 0:00 postgres: wal writer process

postgres 29088 0.0 0.1 389784 3004 ? Ss 14:12 0:00 postgres: autovacuum launcher

process

postgres 29089 0.0 0.1 244288 1992 ? Ss 14:12 0:00 postgres: stats collector process

postgres 29090 0.0 0.1 389656 2520 ? Ss 14:12 0:00 postgres: bgworker: logical

replication launcher

postgres 29093 0.0 0.3 392476 5952 ? Ss 14:12 0:00 postgres: wal sender process

repusr1 192.168.127.32(46482) idle

(サーバ1のサーバログ)

2018-02-07 14:12:19.446 JST [2179] LOG: server process (PID 29004) was terminated by signal 9:

Killed

2018-02-07 14:12:19.447 JST [2179] LOG: terminating any other active server processes

2018-02-07 14:12:19.450 JST [28993] WARNING: terminating connection because of crash of another

server process

2018-02-07 14:12:19.450 JST [28993] DETAIL: The postmaster has commanded this server process to

roll back the current transaction and exit, because another server process exited abnormally and

possibly corrupted shared memory.

2018-02-07 14:12:19.450 JST [28993] HINT: In a moment you should be able to reconnect to the

database and repeat your command.

2018-02-07 14:12:19.456 JST [2179] LOG: all server processes terminated; reinitializing

2018-02-07 14:12:19.485 JST [29083] LOG: database system was interrupted; last known up at 2018-

02-07 14:11:06 JST

2018-02-07 14:12:19.511 JST [29084] FATAL: the database system is in recovery mode

2018-02-07 14:12:19.519 JST [29083] LOG: database system was not properly shut down; automatic

recovery in progress

2018-02-07 14:12:19.519 JST [29083] LOG: redo starts at 0/5800DEE8

2018-02-07 14:12:19.519 JST [29083] LOG: invalid record length at 0/5800DFC8: wanted 24, got 0

2018-02-07 14:12:19.519 JST [29083] LOG: redo done at 0/5800DF90

2018-02-07 14:12:19.524 JST [2179] LOG: database system is ready to accept connections

2018-02-07 14:12:24.529 JST [29093] LOG: starting logical decoding for slot "sub1"

2018-02-07 14:12:24.529 JST [29093] DETAIL: streaming transactions committing after 0/5800DF90,

reading WAL from 0/5800DF90

2018-02-07 14:12:24.529 JST [29093] LOG: logical decoding found consistent point at 0/5800DF90

2018-02-07 14:12:24.529 JST [29093] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-02-07 14:12:19.280 JST [9953] ERROR: could not receive data from WAL stream: server closed

the connection unexpectedly

This probably means the server terminated abnormally

before or while processing the request.

2018-02-07 14:12:19.281 JST [31698] LOG: worker process: logical replication worker for

subscription 16463 (PID 9953) exited with exit code 1

2018-02-07 14:12:19.285 JST [9998] LOG: logical replication apply worker for subscription "sub1"

has started

2018-02-07 14:12:19.344 JST [9998] ERROR: could not connect to the publisher: FATAL: the database

system is in recovery mode

2018-02-07 14:12:19.345 JST [31698] LOG: worker process: logical replication worker for

subscription 16463 (PID 9998) exited with exit code 1

2018-02-07 14:12:24.354 JST [9999] LOG: logical replication apply worker for subscription "sub1"

has started

上記よりPu b lish erのw al sen d erが停止した場合も、Pu b lish erインスタンスの再起動、リカバリ処理が行われた後にレプリケーションが再開されることがわかりました。

■logical replication workerの停止の停止

Subscrib erのlo g ical replication w o rk erをKillコマンドで強制終了します。

PostgreSQL Enterprise Consortium

Page 184 of 285

(サーバ2において実施)

-bash-4.2$ kill -9 9999

-bash-4.2$ ps aux | grep postgres

postgres 10013 0.0 0.1 389296 2124 ? Ss 14:16 0:00 postgres: checkpointer process

postgres 10014 0.0 0.1 389296 2128 ? Ss 14:16 0:00 postgres: writer process

postgres 10015 0.0 0.1 389296 2104 ? Ss 14:16 0:00 postgres: wal writer process

postgres 10016 0.0 0.1 389616 2980 ? Ss 14:16 0:00 postgres: autovacuum launcher

process

postgres 10017 0.0 0.1 244228 1968 ? Ss 14:16 0:00 postgres: stats collector process

postgres 10018 0.0 0.1 389588 2760 ? Ss 14:16 0:00 postgres: bgworker: logical

replication launcher

postgres 10019 0.0 0.3 397052 6340 ? Ss 14:16 0:00 postgres: bgworker: logical

replication worker for subscription 16463

postgres 31698 0.0 0.8 389296 16500 ? S 1月17 0:47 /usr/pgsql-10/bin/postgres

postgres 31699 0.0 0.1 242108 2008 ? Ss 1月17 0:00 postgres: logger process

(サーバ1のサーバログ)

2018-02-07 14:16:13.087 JST [29093] LOG: unexpected EOF on standby connection

2018-02-07 14:16:13.161 JST [29139] LOG: starting logical decoding for slot "sub1"

2018-02-07 14:16:13.161 JST [29139] DETAIL: streaming transactions committing after 0/5800E360,

reading WAL from 0/5800E328

2018-02-07 14:16:13.161 JST [29139] LOG: logical decoding found consistent point at 0/5800E328

2018-02-07 14:16:13.161 JST [29139] DETAIL: Logical decoding will begin using saved snapshot.

(サーバ2のサーバログ)

2018-02-07 14:16:12.920 JST [31698] LOG: worker process: logical replication worker for

subscription 16463 (PID 9999) was terminated by signal 9: Killed

2018-02-07 14:16:12.920 JST [31698] LOG: terminating any other active server processes

2018-02-07 14:16:12.924 JST [9950] WARNING: terminating connection because of crash of another

server process

2018-02-07 14:16:12.924 JST [9950] DETAIL: The postmaster has commanded this server process to

roll back the current transaction and exit, because another server process exited abnormally and

possibly corrupted shared memory.

2018-02-07 14:16:12.924 JST [9950] HINT: In a moment you should be able to reconnect to the

database and repeat your command.

2018-02-07 14:16:12.930 JST [31698] LOG: all server processes terminated; reinitializing

2018-02-07 14:16:12.957 JST [10012] LOG: database system was interrupted; last known up at 2018-

02-07 14:12:43 JST

2018-02-07 14:16:12.973 JST [10012] LOG: recovered replication state of node 1 to 0/5800DEB0

2018-02-07 14:16:12.973 JST [10012] LOG: database system was not properly shut down; automatic

recovery in progress

2018-02-07 14:16:12.974 JST [10012] LOG: redo starts at 0/73706710

2018-02-07 14:16:12.974 JST [10012] LOG: invalid record length at 0/73706A30: wanted 24, got 0

2018-02-07 14:16:12.974 JST [10012] LOG: redo done at 0/737069F8

2018-02-07 14:16:12.974 JST [10012] LOG: last completed transaction was at log time 2018-02-07

14:15:21.893165+09

2018-02-07 14:16:12.980 JST [31698] LOG: database system is ready to accept connections

2018-02-07 14:16:12.990 JST [10019] LOG: logical replication apply worker for subscription "sub1"

has started

上記より、Su b scrib erのlo gical replicatio n lau n ch erが停止した場合もSu b scriberインスタンスの再起動、リカバリ処理が行われた後にレプリケーションが再開される

ことがわかりました。

6.4.2.3. 障害ケース障害ケース2 Publisherのノード停止のノード停止

ロジカルレプリケーションのPu blish erが停止した時の挙動を確認します。

■初期状態初期状態

Subscrib erのpg _stat_su b scription よりレプリケーションが稼働中であることを確認しました。

PostgreSQL Enterprise Consortium

Page 185 of 285

(サーバ2において実施)

subdb=# select * from pg_stat_subscription;

-[ RECORD 1 ]---------+------------------------------

subid | 16463

subname | sub1

pid | 10084

relid |

received_lsn | 0/5800ECB8

last_msg_send_time | 2018-02-07 14:37:30.310381+09

last_msg_receipt_time | 2018-02-07 14:37:30.143584+09

latest_end_lsn | 0/5800ECB8

latest_end_time | 2018-02-07 14:37:30.310381+09

■Publisherのノードを停止のノードを停止

Pu blish erで起動中のPo stg reSQ Lサーバを強制終了します。

(サーバ1において実施)

-bash-4.2$ pg_ctl -m f stop

サーバ停止処理の完了を待っています....完了

サーバは停止しました

次にSubscrib erのpg _stat_su b scription を確認すると、レコードは消えないもののp id, LSN等の情報が表示されなくなりました。

(サーバ2において実施)

subdb=# select * from pg_stat_subscription;

-[ RECORD 1 ]---------+------

subid | 16463

subname | sub1

pid |

relid |

received_lsn |

last_msg_send_time |

last_msg_receipt_time |

latest_end_lsn |

latest_end_time |

また、この時のSu b scriberのサーバログを確認すると、5秒毎に接続を試行してlog ical replicatio n w ork erプロセスがエラー終了する事象が繰り返されていました。

(サーバ2のサーバログ)

2018-02-07 14:55:44.067 JST [10084] LOG: data stream from publisher has ended

2018-02-07 14:55:44.067 JST [10084] ERROR: could not send end-of-streaming message to primary: no

COPY in progress

2018-02-07 14:55:44.069 JST [10075] LOG: worker process: logical replication worker for

subscription 16463 (PID 10084) exited with exit code 1

2018-02-07 14:55:44.072 JST [10118] LOG: logical replication apply worker for subscription "sub1"

has started

2018-02-07 14:55:44.073 JST [10118] ERROR: could not connect to the publisher: FATAL: the

database system is shutting down

2018-02-07 14:55:44.074 JST [10075] LOG: worker process: logical replication worker for

subscription 16463 (PID 10118) exited with exit code 1

2018-02-07 14:55:49.083 JST [10119] LOG: logical replication apply worker for subscription "sub1"

has started

2018-02-07 14:55:49.084 JST [10119] ERROR: could not connect to the publisher: could not connect

to server: Connection refused

Is the server running on host "192.168.127.31" and accepting

TCP/IP connections on port 5432?

2018-02-07 14:55:49.085 JST [10075] LOG: worker process: logical replication worker for

subscription 16463 (PID 10119) exited with exit code 1

この状態から、Pu blish erのPo stgreSQ Lサーバを再度起動します。

PostgreSQL Enterprise Consortium

Page 186 of 285

(サーバ1において実施)

-bash-4.2$ pg_ctl start

サーバの起動完了を待っています....2018-02-07 14:58:44.785 JST [29300] LOG: listening on IPv4 address

"0.0.0.0", port 5432

2018-02-07 14:58:44.785 JST [29300] LOG: listening on IPv6 address "::", port 5432

2018-02-07 14:58:44.785 JST [29300] LOG: listening on Unix socket

"/var/run/postgresql/.s.PGSQL.5432"

2018-02-07 14:58:44.790 JST [29300] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"

2018-02-07 14:58:44.807 JST [29300] LOG: redirecting log output to logging collector process

2018-02-07 14:58:44.807 JST [29300] HINT: Future log output will appear in directory "log".

完了

サーバ起動完了

この時、Su b scriberのpg _stat_su b scription を見ると初期状態の様にレプリケーションが稼働中であることが確認できました。

(サーバ2において実施)

subdb=# select * from pg_stat_subscription;

-[ RECORD 1 ]---------+------------------------------

subid | 16463

subname | sub1

pid | 10161

relid |

received_lsn | 0/5800ED60

last_msg_send_time | 2018-02-07 14:58:59.837546+09

last_msg_receipt_time | 2018-02-07 14:58:59.670736+09

latest_end_lsn | 0/5800ED60

latest_end_time | 2018-02-07 14:58:59.837546+09

この時Pu b lish er、Su b scriberのログにはそれぞれ以下のメッセージが出力されています。

(サーバ2のサーバログ)

2018-02-07 14:58:49.397 JST [10161] LOG: logical replication apply worker for subscription "sub1"

has started

(サーバ1のサーバログ)

2018-02-07 14:55:44.215 JST [2179] LOG: received fast shutdown request

2018-02-07 14:55:44.226 JST [2179] LOG: aborting any active transactions

2018-02-07 14:55:44.232 JST [2179] LOG: worker process: logical replication launcher (PID 29090)

exited with exit code 1

2018-02-07 14:55:44.232 JST [29085] LOG: shutting down

2018-02-07 14:55:44.240 JST [29290] FATAL: the database system is shutting down

2018-02-07 14:55:44.252 JST [2179] LOG: database system is shut down

2018-02-07 14:58:44.809 JST [29302] LOG: database system was shut down at 2018-02-07 14:55:44 JST

2018-02-07 14:58:44.813 JST [29300] LOG: database system is ready to accept connections

2018-02-07 14:58:49.572 JST [29310] LOG: starting logical decoding for slot "sub1"

2018-02-07 14:58:49.572 JST [29310] DETAIL: streaming transactions committing after 0/5800EC80,

reading WAL from 0/5800EC80

2018-02-07 14:58:49.572 JST [29310] LOG: logical decoding found consistent point at 0/5800EC80

2018-02-07 14:58:49.572 JST [29310] DETAIL: There are no running transactions.

この結果より、Pu b lish erが停止した場合はレプリケーションが停止するが、再度起動すればレプリケーションも再開されることがわかりました。

6.4.2.4. 障害ケース障害ケース3 Su bscriberのノード停止のノード停止

ロジカルレプリケーションのSubscrib erが停止した時の挙動を確認します。

■初期状態初期状態

Pu blish erのp g _stat_rep lication よりレプリケーションが稼働中であることを確認しました。

PostgreSQL Enterprise Consortium

Page 187 of 285

(サーバ1において実施)

pubdb=# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 29213

usesysid | 16385

usename | repusr1

application_name | sub1

client_addr | 192.168.127.32

client_hostname |

client_port | 46484

backend_start | 2018-02-07 14:33:55.842956+09

backend_xmin |

state | catchup

sent_lsn | 0/5800EBD8

write_lsn | 0/5800EBD8

flush_lsn | 0/5800EBD8

replay_lsn | 0/5800EBD8

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

■Subscriberのノードを停止のノードを停止

Subscrib erで起動中のPostgreSQ Lサーバを強制終了します。

(サーバ2において実施)

-bash-4.2$ pg_ctl -m f stop

サーバ停止処理の完了を待っています....完了

サーバは停止しました

次にPu blish erのp g _stat_rep lication を確認すると、レプリケーションの情報が表示されなくなりました。また、この時Pu b lish erのサーバログには何も出力されていませ

んでした。

(サーバ1において実施)

pubdb=# select * from pg_stat_replication;

(0 rows)

なお、この状態のままPu b lish erで1件データをINSERTしても特に問題なく処理は完了します。

(サーバ1において実施)

pubdb=# insert into data1 values (6, 'pub6');

INSERT 0 1

この状態から、Subscrib erのPostg reSQ Lサーバを再度起動します。

(サーバ2において実施)

-bash-4.2$ pg_ctl start

サーバの起動完了を待っています....2018-02-07 14:33:55.641 JST [10075] LOG: listening on IPv4 address

"0.0.0.0", port 5432

2018-02-07 14:33:55.641 JST [10075] LOG: listening on IPv6 address "::", port 5432

2018-02-07 14:33:55.642 JST [10075] LOG: listening on Unix socket

"/var/run/postgresql/.s.PGSQL.5432"

2018-02-07 14:33:55.642 JST [10075] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"

2018-02-07 14:33:55.656 JST [10075] LOG: redirecting log output to logging collector process

2018-02-07 14:33:55.656 JST [10075] HINT: Future log output will appear in directory "log".

完了

サーバ起動完了

ここで、Pu b lish er側のp g _stat_rep lica tion を見ると初期状態の様にレプリケーションが復旧していることが確認できました。

PostgreSQL Enterprise Consortium

Page 188 of 285

(サーバ1において実施)

pubdb=# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 29213

usesysid | 16385

usename | repusr1

application_name | sub1

client_addr | 192.168.127.32

client_hostname |

client_port | 46484

backend_start | 2018-02-07 14:33:55.842956+09

backend_xmin |

state | catchup

sent_lsn | 0/5800EBD8

write_lsn | 0/5800EBD8

flush_lsn | 0/5800EBD8

replay_lsn | 0/5800EBD8

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

また、Pu blish erでINSERTしたレコードがSu b scriberのテーブルにも転送されています。

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2 | c3

----+------+----

1 | pub1 |

2 | pub2 |

3 | pub3 |

4 | pub4 |

5 | pub5 |

6 | pub6 |

この時Pu b lish er、Su b scriberのログにはそれぞれ以下のメッセージが出力されています。

(サーバ1のサーバログ)

2018-02-07 14:33:55.845 JST [29213] LOG: starting logical decoding for slot "sub1"

2018-02-07 14:33:55.845 JST [29213] DETAIL: streaming transactions committing after 0/5800E858,

reading WAL from 0/5800E820

2018-02-07 14:33:55.845 JST [29213] LOG: logical decoding found consistent point at 0/5800E820

2018-02-07 14:33:55.845 JST [29213] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-02-07 14:33:55.658 JST [10077] LOG: database system was shut down at 2018-02-07 14:29:59 JST

2018-02-07 14:33:55.659 JST [10077] LOG: recovered replication state of node 1 to 0/5800E740

2018-02-07 14:33:55.662 JST [10075] LOG: database system is ready to accept connections

2018-02-07 14:33:55.674 JST [10084] LOG: logical replication apply worker for subscription "sub1"

has started

この結果より、Su b scriberが停止した場合はレプリケーションが停止するが、再度起動すればレプリケーションも再開されることがわかりました。

6.4.2.5. 障害ケース障害ケース4 Publisher/Subscriber間のネットワーク断絶間のネットワーク断絶

ロジカルレプリケーションで利用するネットワークが断絶した時の挙動を確認します。

■初期状態初期状態

Pu blish erのp g _stat_rep lication よりレプリケーションが稼働中であることを確認しました。

PostgreSQL Enterprise Consortium

Page 189 of 285

(サーバ1において実施)

pubdb=# select * from pg_stat_replication;

-[ RECORD 1 ]----+-----------------------------

pid | 29310

usesysid | 16385

usename | repusr1

application_name | sub1

client_addr | 192.168.127.32

client_hostname |

client_port | 46522

backend_start | 2018-02-07 14:58:49.56556+09

backend_xmin |

state | streaming

sent_lsn | 0/5800EE40

write_lsn | 0/5800EE40

flush_lsn | 0/5800EE40

replay_lsn | 0/5800EE40

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

■ネットワークの断絶ネットワークの断絶

Pu blish erでレプリケーションに使用するネットワークを停止します。ここではO S(Cen tO S7.2)のNetw o rkManagerを利用して対象インタフェース(ens192)を停止しまし

た。

(サーバ1において実施)

[root@nk_PGECons_1 ~]# nmcli connection down ens192

Connection 'ens192' successfully deactivated (D-Bus active path:

/org/freedesktop/NetworkManager/ActiveConnection/0)

[root@nk_PGECons_1 ~]# nmcli connection show

名前 UUID タイプデバイス

ens192 fa64b28e-a7db-45f0-b7b1-0b2b298b20d2 802-3-ethernet --

ens160 c0791a7a-43be-4254-847d-2b793b583bba 802-3-ethernet ens160

しばらくの間はPu b lish erのp g_stat_rep lication が初期状態のままですが、 1分ほど経過するとレプリケーションの情報が表示されなくなりました。

(サーバ1において実施)

pubdb=# select * from pg_stat_replication;

(0 rows)

この時のPu b lish erのログには以下のメッセージが出力されました。ここではw al_send er_timeo u tパラメータをデフォルトの60秒で設定していたため、タイムアウトを検知

して非活動のレプリケーション接続を停止しています。

(サーバ1のサーバログ)

2018-02-07 15:41:12.504 JST [29310] LOG: terminating walsender process due to replication timeout

■ネットワークの復旧ネットワークの復旧

Pu blish erで停止したネットワークのインタフェースを復旧します。

(サーバ1において実施)

[root@nk_PGECons_1 ~]# nmcli connection up ens192

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/2)

[root@nk_PGECons_1 ~]# nmcli connection show

名前 UUID タイプデバイス

ens192 fa64b28e-a7db-45f0-b7b1-0b2b298b20d2 802-3-ethernet ens192

ens160 c0791a7a-43be-4254-847d-2b793b583bba 802-3-ethernet ens160

Pu blish er側のp g_stat_replication を確認すると、レプリケーションの情報が再び表示されるようになりました。

PostgreSQL Enterprise Consortium

Page 190 of 285

(サーバ1において実施)

pubdb=# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 29665

usesysid | 16385

usename | repusr1

application_name | sub1

client_addr | 192.168.127.32

client_hostname |

client_port | 46523

backend_start | 2018-02-07 15:44:40.511419+09

backend_xmin |

state | catchup

sent_lsn | 0/5800F300

write_lsn | 0/5800F300

flush_lsn | 0/5800F300

replay_lsn | 0/5800F300

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

Pu blish erのログには以下のメッセージが出力され、レプリケーションが再開されたことがわかります。

(サーバ1のサーバログ)

2018-02-07 15:44:40.514 JST [29665] LOG: starting logical decoding for slot "sub1"

2018-02-07 15:44:40.514 JST [29665] DETAIL: streaming transactions committing after 0/5800EE40,

reading WAL from 0/5800EE08

2018-02-07 15:44:40.514 JST [29665] LOG: logical decoding found consistent point at 0/5800EE08

2018-02-07 15:44:40.514 JST [29665] DETAIL: There are no running transactions.

また、Su b scriberのログは以下のメッセージが出力されており、ネットワークの復旧に伴って lo gica l replication w orker が再起動したことがわかります。

(サーバ2のサーバログ)

2018-02-07 15:44:40.338 JST [10161] ERROR: could not receive data from WAL stream: server closed

the connection unexpectedly

This probably means the server terminated abnormally

before or while processing the request.

2018-02-07 15:44:40.339 JST [10075] LOG: worker process: logical replication worker for

subscription 16463 (PID 10161) exited with exit code 1

2018-02-07 15:44:40.343 JST [10247] LOG: logical replication apply worker for subscription "sub1"

has started

これらの結果より、ネットワークの断絶により一時的にレプリケーションが停止した場合でも、ネットワークが復旧すればレプリケーションも自動的に再開されることがわかりまし

た。

6.4.3. レプリケーション対象テーブルの追加レプリケーション対象テーブルの追加 /削除削除

ロジカルレプリケーションが稼働している環境で新たに作成したテーブルをレプリケーション対象として追加したり、テーブル定義を変更する手順を確認します。

6.4.3.1. 前提とする環境前提とする環境

本章は以下の環境を利用した検証結果を元に解説します。

PostgreSQL Enterprise Consortium

Page 191 of 285

Po stg reSQ LサーバはロジカルレプリケーションのPu blish er1台、Subscrib er1台で構成

ロジカルレプリケーションのPu blish er（サーバ1。IPアドレス 192｡168｡127｡31）では、新規に作成したデータベースp u b db ,pu b d b_all_tab leのみを作成

ロジカルレプリケーションのSubscrib er（サーバ2。IPアドレス 192｡168｡127｡32）では、新規に作成したデータベースsu b d b ,su b d b_all_tableのみを作成

6.4.3.2. レプリケーション対象のテーブルを追加する手順レプリケーション対象のテーブルを追加する手順 (データベース単位のデータベース単位の Publication)

データベース単位のPu b lica tion が作成されたデータベースに対して、テーブルを追加する手順を説明します。

■初期状態初期状態

Pu blish erのデータベースp u b db _all_tab leに接続し、データベース単位のPu b lication pu b_all_tab leを作成します。

(サーバ1において実施)

pubdb_all_table=# CREATE PUBLICATION pub_all_table FOR ALL TABLES;

CREATE PUBLICATION

pubdb_all_table=# \dRp+

Publication pub_all_table

Owner | All tables | Inserts | Updates | Deletes

----------+------------+---------+---------+---------

postgres | t | t | t | t

Pu lish erのデータベースpu b d b_all_tableにテーブルdata1を作成します。システムカタログpg_pu blication _tablesでテーブルd ata1がPu b lication

pu b _all_tab leのレプリケーション対象として認識されたことが確認できます。

PostgreSQL Enterprise Consortium

Page 192 of 285

(サーバ1において実施)

pubdb_all_table=# CREATE TABLE data1 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

pubdb_all_table=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

---------------+------------+-----------

pub_all_table | public | data1

Subscrib erのデータベースsu b db _all_tableに接続し、Su b scription を作成します。なお、Subscrip tio n 作成時点で接続先のPu b lication の対象テーブルが存在し

ないとエラーになるため、あらかじめSu b scrib erのデータベースに同一名称のテーブルを作成しておいてください。

(サーバ2において実施)

subdb_all_table=# CREATE SUBSCRIPTION sub_all_table CONNECTION 'host=192.168.127.31

dbname=pubdb_all_table user=repusr1 password=repusr1' PUBLICATION pub_all_table;

ERROR: relation "public.data1" does not exist ★data1テーブルが存在しないとエラーとなる

subdb_all_table=# CREATE TABLE data1 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

subdb_all_table=# CREATE SUBSCRIPTION sub_all_table CONNECTION 'host=192.168.127.31

dbname=pubdb_all_table user=repusr1 password=repusr1' PUBLICATION pub_all_table;

NOTICE: created replication slot "sub_all_table" on publisher

CREATE SUBSCRIPTION

Subscrip tio n を作成するとSub scrib erのログに初期データ転送のメッセージが出力され、ロジカルレプリケーションが開始されたことが確認できます。

(サーバ2のサーバログ)

2018-01-17 11:09:23.050 JST [31749] LOG: logical replication table synchronization worker for

subscription "sub_all_table", table "data1" has started

2018-01-17 11:09:23.062 JST [31749] LOG: logical replication table synchronization worker for

subscription "sub_all_table", table "data1" has finished

■テーブルの追加手順テーブルの追加手順

初期状態から、Pu lish erのデータベースpu b d b _all_tab leにテーブルdata2を作成します。FO R ALL TAB LES句を付けてCRATEしたPu b lication のため、作成した

テーブルdata2が自動的にレプリケーション対象として認識されていることがわかります。

(サーバ1において実施)

pubdb_all_table=# CREATE TABLE data2 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

pubdb_all_table=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

---------------+------------+-----------

pub_all_table | public | data1

pub_all_table | public | data2

次に、Su b scrib erのデータベースsubd b _all_tableにもテーブルd ata2を作成します。この時点ではSu b scrip tion su b _all_tableにテーブルdata2は認識されておら

ず、テーブルdata2のレプリケーションが開始されていないことがわかります。

(サーバ2において実施)

subdb_all_table=# CREATE TABLE data2 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

subdb_all_table=# select a3.subname, a2.relname, a1.srsubstate, a1.srsublsn from

pg_subscription_rel as a1 left outer join pg_class as a2 on a1.srrelid = a2.oid left outer join

pg_stat_subscription as a3 on a1.srsubid = a3.subid;

subname | relname | srsubstate | srsublsn

---------------+---------+------------+------------

sub_all_table | data1 | r | 0/5602B818

既存のSu b scrip tion に新たなレプリケーション対象テーブルを認識させるために、ALTER SU B SCRIPTIO N文を実行します。再びpg_su b scription _relを確認するとテー

ブルdata2が新たに認識されていることが確認できます。

PostgreSQL Enterprise Consortium

Page 193 of 285

(サーバ2において実施)

subdb_all_table=# ALTER SUBSCRIPTION sub_all_table REFRESH PUBLICATION;

ALTER SUBSCRIPTION

subdb_all_table=# select a3.subname, a2.relname, a1.srsubstate, a1.srsublsn from

pg_subscription_rel as a1 left outer join pg_class as a2 on a1.srrelid = a2.oid left outer join

pg_stat_subscription as a3 on a1.srsubid = a3.subid;

subname | relname | srsubstate | srsublsn

---------------+---------+------------+------------

sub_all_table | data1 | r | 0/5602B818

sub_all_table | data2 | d |

6.4.3.3. レプリケーション対象のテーブルを追加する手順レプリケーション対象のテーブルを追加する手順 (テーブル単位のテーブル単位の Publication)

テーブル単位のPu b lication が作成されたデータベースに対して、テーブルを追加する手順を説明します。

■初期状態初期状態

Pu blish erのデータベースp u b db にテーブルdata1をCREATEした後、レプリケーション対象とするPu b lication pu b 1を作成します。

(サーバ1において実施)

pubdb=# CREATE TABLE data1 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

pubdb=> CREATE PUBLICATION pub1 FOR TABLE data1;

CREATE PUBLICATION

pubdb=# \dRp+

Publication pub1

Owner | All tables | Inserts | Updates | Deletes

---------+------------+---------+---------+---------

pubusr1 | f | t | t | t

Tables:

"public.data1"

Subscrib erのデータベースsu b db にSu b scription を作成し、レプリケーションを開始します。

(サーバ2において実施)

subdb=# CREATE TABLE data1 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

subdb=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub1;

NOTICE: created replication slot "sub1" on publisher

CREATE SUBSCRIPTION

■テーブルの追加手順テーブルの追加手順

初期状態から、Pu lish erのデータベースpu b d b にテーブルd ata1_1を作成します。FO R ALL TAB LES句を付けずにCRATEしたPu b licatio n のため、作成したテーブル

data1_1がレプリケーション対象と認識されていないことがわかります。

(サーバ1において実施)

pubdb=# CREATE TABLE data1_1 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

pubdb=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

----------+------------+-----------

pub1 | public | data1

テーブルdata1_1を既存のPu b lication p u b 1にレプリケーション対象として追加するには、ALTER PUB LICATIO N文を実行します。

PostgreSQL Enterprise Consortium

Page 194 of 285

(サーバ1において実施)

pubdb=# ALTER PUBLICATION pub1 ADD TABLE data1_1;

ALTER PUBLICATION

pubdb=# SELECT * FROM pg_publication_tables;

pubname | schemaname | tablename

---------+------------+-----------

pub1 | public | data1

pub1 | public | data1_1

次に、Su b scrib erのデータベースsubd b にテーブルd ata 1_1を作成します。この時点ではSu bscrip tion sub 1にテーブルdata1_1は認識されません。

(サーバ2において実施)

subdb=# CREATE TABLE data1_1 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

subdb=# select a3.subname, a2.relname, a1.srsubstate, a1.srsublsn from pg_subscription_rel as a1

left outer join pg_class as a2 on a1.srrelid = a2.oid left outer join pg_stat_subscription as a3 on

a1.srsubid = a3.subid;

subname | relname | srsubstate | srsublsn

---------+---------+------------+------------

sub1 | data1 | r | 0/55FB63D0

既存のSu b scrip tion に新たなレプリケーション対象テーブルを認識させるために、ALTER SU B SCRIPTIO N文を実行します。pg_su b scription _relを確認するとテーブル

data1_1が新たに認識されていることが確認できます。

(サーバ2において実施)

subdb=# ALTER SUBSCRIPTION sub1 REFRESH PUBLICATION;

ALTER SUBSCRIPTION

subdb=# select a3.subname, a2.relname, a1.srsubstate, a1.srsublsn from pg_subscription_rel as a1

left outer join pg_class as a2 on a1.srrelid = a2.oid left outer join pg_stat_subscription as a3 on

a1.srsubid = a3.subid;

subname | relname | srsubstate | srsublsn

---------+---------+------------+------------

sub1 | data1_1 | r | 0/56068D38

sub1 | data1 | r | 0/55FB63D0

6.4.3.4. レプリケーション対象のテーブルを変更する手順レプリケーション対象のテーブルを変更する手順

レプリケーションが実行されているテーブルに新たな列を追加する手順を説明します。

■初期状態初期状態

前述のPu b lication p u b 1, Sub scrip tion sub 1を利用し、テーブルd ata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。また、テーブ

ルd ata 1にはそれぞれ1件のデータが存在する状態とします。

(サーバ1において実施)

pubdb=# SELECT * FROM data1;

c1 | c2

----+------

1 | pub1

(サーバ2において実施)

subdb=# SELECT * FROM data1;

c1 | c2

----+------

1 | pub1

■列の追加手順列の追加手順

レプリケーション対象のテーブル定義に不一致があると更新競合が発生し、ロジカルレプリケーションの停止につながります。意図しないエラーを起こさぬようあらかじめALTER

SUBSCR IPTIO N文でSu b scrip tion を一時停止しておくとよいでしょう。

PostgreSQL Enterprise Consortium

Page 195 of 285

(サーバ2において実施)

subdb=# ALTER SUBSCRIPTION sub1 DISABLE;

ALTER SUBSCRIPTION

subdb=# SELECT * FROM pg_stat_subscription;

last_msg_receipt_time | latest_end_lsn | latest_end_time

-------+---------------+-------+-------+--------------+-------------------------------+------------

-------------------+----------------+-------------------------------

16463 | sub1 | | | | |

| |

この時、Su b scriberのログには以下の様なメッセージが出力されます。

(サーバ2のサーバログ)

2018-01-17 14:51:52.437 JST [31708] LOG: logical replication apply worker for subscription "sub1"

will stop because the subscription was disabled

ロジカルレプリケーションを停止した後、Pu b lish erのテーブルd ata1にALTER TAB LE文で列を追加します。また、ここで確認のため1件レコードを挿入しておきます。

(サーバ1において実施)

pubdb=# ALTER TABLE data1 ADD COLUMN c3 VARCHAR(5);

ALTER TABLE

pubdb=# INSERT INTO data1 VALUES (2, 'pub2', 'pub2');

INSERT 0 1

pubdb=# SELECT * FROM data1;

c1 | c2 | c3

----+------+------

1 | pub1 |

2 | pub2 | pub2

次にSubscrib erのテーブルdata1にもALTER TABLE文で同じ定義の列を追加します。Subscrip tio n を停止しているため2件目のレコードはまだ転送されていません。

(サーバ2において実施)

subdb=# ALTER TABLE data1 ADD COLUMN c3 VARCHAR(5);

ALTER TABLE

subdb=# SELECT * FROM data1;

c1 | c2 | c3

----+------+----

1 | pub1 |

Subscrib erでSu b scrip tion を再度有効化し、ロジカルレプリケーションを再開すると、この時点で2件目のレコードが転送されます。

(サーバ2において実施)

subdb=# ALTER SUBSCRIPTION sub1 ENABLE;

ALTER SUBSCRIPTION

subdb=# SELECT * FROM data1;

c1 | c2 | c3

----+------+------

1 | pub1 |

2 | pub2 | pub2

Subscrib erのpg _stat_su b scritp ion とログを再度確認すると、正常にレプリケーションが再開されていることがわかります。

PostgreSQL Enterprise Consortium

Page 196 of 285

(サーバ2において実施)

subdb=# SELECT * FROM pg_stat_subscription;

last_msg_receipt_time | latest_end_lsn | latest_end_time

-------+---------------+-------+-------+--------------+-------------------------------+------------

-------------------+----------------+-------------------------------

16463 | sub1 | 32626 | | 0/56073298 | 2018-01-17 15:02:10.817291+09 | 2018-01-17

15:02:10.650377+09 | 0/56073298 | 2018-01-17 15:02:10.817291+09

(サーバ2のサーバログ)

2018-01-17 15:01:47.266 JST [32626] LOG: logical replication apply worker for subscription "sub1"

has started

6.4.3.5. レプリケーション対象のテーブルにインデックスを追加する手順レプリケーション対象のテーブルにインデックスを追加する手順

レプリケーションが実行されているテーブルにインデックスを追加する手順を説明します。

■初期状態初期状態

前述のPu b lication p u b 1, Sub scrip tion sub 1およびテーブルd ata 1をそのまま利用します。初期状態でPu blish er,Su bscrib erのテーブルdata1は以下の定義となっ

ています。

(サーバ1において実施)

pubdb=# \d data1

Table "public.data1"

Column | Type | Collation | Nullable | Default

--------+----------------------+-----------+----------+---------

c1 | integer | | not null |

c2 | character varying(5) | | |

c3 | character varying(5) | | |

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

Publications:

"pub1"

(サーバ2において実施)

subdb=# \d data1;

Table "public.data1"

Column | Type | Collation | Nullable | Default

--------+----------------------+-----------+----------+---------

c1 | integer | | not null |

c2 | character varying(5) | | |

c3 | character varying(5) | | |

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

■Publisherのテーブルにインデックスを追加のテーブルにインデックスを追加

初期状態からPu b lish erのテーブルd ata1にのみインデックスをCR E ATEすると、Su b scriberのテーブルdata1にはインデックスが追加されないことがわかります。

PostgreSQL Enterprise Consortium

Page 197 of 285

(サーバ1において実施)

pubdb=# CREATE INDEX data1_c2_idx ON data1 (c2);

CREATE INDEX

pubdb=# \d data1

Table "public.data1"

Column | Type | Collation | Nullable | Default

--------+----------------------+-----------+----------+---------

c1 | integer | | not null |

c2 | character varying(5) | | |

c3 | character varying(5) | | |

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

"data1_c2_idx" btree (c2)

Publications:

"pub1"

(サーバ2において実施)

subdb=# \d data1;

Table "public.data1"

Column | Type | Collation | Nullable | Default

--------+----------------------+-----------+----------+---------

c1 | integer | | not null |

c2 | character varying(5) | | |

c3 | character varying(5) | | |

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

■Subscriberのテーブルにインデックスを追加のテーブルにインデックスを追加

次にSubscrib erのテーブルdata1にのみインデックスをCR EATEすると、Sub scrib erのテーブルd ata1にのみインデックスが追加されていることがわかります。

(サーバ2において実施)

subdb=# CREATE INDEX data1_c3_idx ON data1 (c3);

CREATE INDEX

subdb=# \d data1;

Table "public.data1"

Column | Type | Collation | Nullable | Default

--------+----------------------+-----------+----------+---------

c1 | integer | | not null |

c2 | character varying(5) | | |

c3 | character varying(5) | | |

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

"data1_c3_idx" btree (c3)

(サーバ1において実施)

pubdb=# \d data1

Table "public.data1"

Column | Type | Collation | Nullable | Default

--------+----------------------+-----------+----------+---------

c1 | integer | | not null |

c2 | character varying(5) | | |

c3 | character varying(5) | | |

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

"data1_c2_idx" btree (c2)

Publications:

"pub1"

ロジカルレプリケーションにおいてインデックスはレプリケーション対象とならないため、インデックスの追加、削除が既存のレプリケーションに影響を及ぼすことはありませんが、

Pu blish erで作成したインデックスがSub scrib erでも必要であれば同じCREATE INDEX文を発行する必要があります。

6.4.4. レプリケーション対象外となる操作、オブジェクトレプリケーション対象外となる操作、オブジェクト

ストリーミングレプリケーションがデータベースクラスタへの操作、オブジェクトを全て複製するのと違い、PostgreSQ L10のロジカルレプリケーションでは以下の様な操作、オブ

PostgreSQL Enterprise Consortium

Page 198 of 285

ジェクトが複製されません。そのためこれらは必要に応じてPu b lish erとSub scrib erで同じ操作を行う等の対処を求められます。

表 6.6 ロジカルレプリケーションで複製されない操作、オブジェクト

操作、オブジェクト操作、オブジェクト動作検証動作検証

CREATE TABLE, ALTER TAB LE, CREATE INDEX等のDDL

シーケンスの定義、データ ■

TRUNCATE ■

Large O bject

VIEW , MATER IALIZED VIEW

FO R E IG N TAB LE

UNLO GGED TAB LE

パーティショニングの親テーブル

ここでは、TRUNCATEとシーケンスに対するロジカルレプリケーションの挙動を確認します。

6.4.4.1. 前提とする環境前提とする環境

本章は以下の環境を利用した検証結果を元に解説します。

Po stg reSQ LサーバはロジカルレプリケーションのPu blish er1台、Subscrib er1台で構成

ロジカルレプリケーションのPu blish er（サーバ1。IPアドレス 192｡168｡127｡31）では、新規に作成したデータベースp u b db を作成

データベースpu b d bには、レプリケーション対象のテーブルを個別定義するPub licatio n pu b 1,p u b 3を作成

pu b 1,p u b3のレプリケーション対象として、それぞれテーブルdata1,data3を設定

ロジカルレプリケーションのSubscrib er（サーバ2。IPアドレス 192｡168｡127｡32）では、新規に作成したデータベースsu b d b を作成

データベースsu b d b には、Pu b lish erのpu b d bデータベースに定義したPu b lication から変更データを受け取るSu b scriptio n sub1,su b 3およびテー

ブルdata1,data3を作成

PostgreSQL Enterprise Consortium

Page 199 of 285

6.4.4.2. TRUN CATE

■初期状態初期状態

初期状態でテーブルdata1のデータがPu b lish er,Su bscrib er間でレプリケーションされている状態とします。また、テーブルd a ta1にはそれぞれ5件のデータが存在する状態

とします。

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

Pu blish erでテーブルdata1に対してTRU NCATE TAB LEを実行します。

(サーバ1において実施)

pubdb=# TRUNCATE TABLE data1;

TRUNCATE TABLE

pubdb=# select * from data1;

c1 | c2

----+----

この状態でSu bscrib erのテーブルdata1は変化していないことが確認できます。

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

Subscrib erでもテーブルd a ta1に対してTRUNCATE TAB LEを実行することで、Pu b lish erと一致します。

(サーバ2において実施)

subdb=# TRUNCATE TABLE data1;

TRUNCATE TABLE

subdb=# select * from data1;

c1 | c2

----+----

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+----

TRUNCATE TAB LEはW ALにも記録されるデータ更新操作であり、ストリーミングレプリケーションで複製される操作ですが、ロジカルレプリケーションでは複製されないため注

意が必要です。

PostgreSQL Enterprise Consortium

Page 200 of 285

6.4.4.3. シーケンスシーケンス

ここではSERIAL列を含むテーブルをロジカルレプリケーションで複製した場合の挙動を確認します。

■初期状態初期状態

Pu blish erのデータベースp u b db 、Sub scrib erのデータベースsu b d b にそれぞれテーブルdata3を作成し、ロジカルレプリケーションで複製される状態にします。また、テー

ブルdata3にはSERIAL列を定義します。

(サーバ1において実施)

pubdb=# CREATE TABLE data3 (c1 SERIAL PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

pubdb=# CREATE PUBLICATION pub3 FOR TABLE data3;

CREATE PUBLICATION

(サーバ2において実施)

subdb=# CREATE TABLE data3 (c1 SERIAL PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

subdb=# CREATE SUBSCRIPTION sub3 CONNECTION 'host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub3;

NOTICE: created replication slot "sub3" on publisher

CREATE SUBSCRIPTION

■SERIAL列のレプリケーション列のレプリケーション

Pu blish erのテーブルdata3にレコードを挿入します。挿入したレコードがSu b scriberのテーブルdata3にも転送されます。

(サーバ1において実施)

pubdb=# INSERT INTO data3 (c2) VALUES ('pub1');

INSERT 0 1

pubdb=# SELECT * FROM data3;

c1 | c2

----+------

1 | pub1

(サーバ2において実施)

subdb=# SELECT * FROM data3;

c1 | c2

----+------

1 | pub1

この時点でPublish erに存在するシーケンスは現在値が1になっていますが、Sub scrib erに存在するシーケンスからは現在値が取得できません。つまり、SERIAL列の値自

体は複製されたものの、内部的に作成されたシーケンスのデータは複製されていません。

(サーバ1において実施)

pubdb=# SELECT currval('data3_c1_seq');

currval

---------

(サーバ2において実施)

subdb=# SELECT currval('data3_c1_seq');

ERROR: currval of sequence "data3_c1_seq" is not yet defined in this session

ここでSu b scrib erのテーブルdata3に対してレコードを挿入するとキー重複でエラーになります。これはSub scrib erのシーケンスにPu b lish erのシーケンスデータと関係なく

1を発行したためです。

PostgreSQL Enterprise Consortium

Page 201 of 285

(サーバ2において実施)

subdb=# INSERT INTO data3 (c2) VALUES ('pub1');

ERROR: duplicate key value violates unique constraint "data3_pkey"

DETAIL: Key (c1)=(1) already exists.

subdb=# SELECT currval('data3_c1_seq');

currval

---------

この状態で再度Su b scrib erのテーブルdata3にレコードを挿入すると成功します。これは先ほどINSER Tに失敗した際にSu bscrib erのシーケンスは1にカウントアップされて

おり、今回のINSERTで2を発行したためキー重複が発生せず挿入できたためです。

(サーバ2において実施)

subdb=# INSERT INTO data3 (c2) VALUES ('pub1');

INSERT 0 1

subdb=# SELECT * FROM data3;

c1 | c2

----+------

1 | pub1

2 | pub1

subdb=# SELECT currval('data3_c1_seq');

currval

---------

この時点でPublish erのシーケンスは現在値が1のため、このままPu b lish erのテーブルdata3にINSERTするとSu b scriberのテーブルでキー重複が発生します。そこで、

Pu blish erのシーケンスの現在値を2に進めてからレコード挿入するとPu b lish erで挿入したレコードがSub scrib erに複製されました。

(サーバ1において実施)

pubdb=# SELECT * FROM data3;

c1 | c2

----+------

1 | pub1

pubdb=# SELECT currval('data3_c1_seq');

currval

---------

pubdb=# SELECT nextval('data3_c1_seq');

nextval

---------

pubdb=# INSERT INTO data3 (c2) VALUES ('pub1');

INSERT 0 1

pubdb=# SELECT * FROM data3;

c1 | c2

----+------

1 | pub1

3 | pub1

(サーバ1において実施)

subdb=# SELECT * FROM data3;

c1 | c2

----+------

1 | pub1

2 | pub1

3 | pub1

このように、Pu blish erでSERIAL列に付与された値はSu b scrib erのテーブルに転送されますが、内部的に使用するシーケンスのデータは複製されないため、Su b scrib er

で独自にレコードを挿入するとシーケンスのデータに不整合が生じます。そのため、SERIAL列を含むテーブルでロジカルレプリケーションを行う場合はSu b scriberでのレコード

更新は抑制した方がよいでしょう。

6.4.5. 更新競合時の動作更新競合時の動作

マスタしか更新できないストリーミングレプリケーションに対し、ロジカルレプリケーションはSub scrib erも更新することができます。ただし、Pu b lish erとSu b scrib erのテーブル

PostgreSQL Enterprise Consortium

Page 202 of 285

間で以下の様な更新処理の競合が発生する可能性があります。
表 6.7 ロジカルレプリケーションで発生する更新処理の競合パターン
競合パタ ーン競合パタ ーン 動作検証動作検証  (更新時更新時 ) 動作 検証動 作 検証  (初期データ 同期時初期データ同期時 )
主キー違反/一意キー違反 ■ ■
CHECK制約違反 ■ ■
更新データが存在しない ■ ■
削除データが存在しない ■ ■
テーブルが存在しない ■ ■
一部の列が存在しない ■ ■
データ型変換エラー ■ ■
テーブルのロック ■ ■
更新対象レコードのロック ■ ■
ここでは競合が発生した時の挙動と対応方法について検証します。
6.4.5.1. 前提とする環境前提 と する環境
本章は以下の環境を利用した検証結果を元に解説します。
Po stg reSQ LサーバはロジカルレプリケーションのPu blish er1台、Subscrib er1台で構成
ロジカルレプリケーションのPu blish er（サーバ1。IPアドレス 192｡168｡127｡31）では、新規に作成したデータベースp u b db を作成
データベースpu b d bには、レプリケーション対象のテーブルを個別定義するPub licatio n  pu b 1を作成
pu b 1のレプリケーション対象として、それぞれテーブルdata1を設定
ロジカルレプリケーションのSubscrib er（サーバ2。IPアドレス 192｡168｡127｡32）では、新規に作成したデータベースsu b d b を作成
PostgreSQL Enterprise Consortium
Page 203 of 285

データベースsu b d b には、Pu b lish erのpu b d bデータベースに定義したPu b lication から変更データを受け取るSu b scriptio n sub1およびテーブル

data1を作成

6.4.5.2. 更新時の競合発生と解消更新時の競合発生と解消

前述の環境において実際に競合が発生した時の挙動と競合を解消させるための方法を競合発生のパターン毎に紹介します。

6.4.5.2.1. 主キー違反主キー違反 /一意キー違反一意キー違反

■初期状態初期状態

テーブルdata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。また、テーブルd ata1にはc1列をPRIM ARY KEYとし、それぞれ以下のデータ

が存在する状態とします。

(サーバ1において実施)

pubdb=# \d data1

Table "public.data1"

Column | Type | Collation | Nullable | Default

--------+----------------------+-----------+----------+---------

c1 | integer | | not null |

c2 | character varying(5) | | |

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

Publications:

"pub1"

pubdb=# select * from data1;

c1 | c2

----+-------

1 | aaaaa

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+-------

1 | aaaaa

2 | sub

■競合の発生競合の発生

Pu blish erのテーブルdata1にc1=2のレコードを挿入するとPu b lish erのINSERTは成功します。

(サーバ1において実施)

pubdb=# insert into data1 values (2, 'pub');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+-------

1 | aaaaa

2 | pub

この時Sub scrib erでは主キー違反による競合が発生し、レプリケーションが停止します。 Pu b lish er、Su b scrib erのログには競合が解消するまで5秒毎に以下のメッセー

ジが繰り返し出力されます。

PostgreSQL Enterprise Consortium

Page 204 of 285

(サーバ1のサーバログ)

2018-01-10 13:37:55.149 JST [5859] LOG: starting logical decoding for slot "sub1"

2018-01-10 13:37:55.149 JST [5859] DETAIL: streaming transactions committing after 0/55F82E30,

reading WAL from 0/55F82DF8

2018-01-10 13:37:55.149 JST [5859] LOG: logical decoding found consistent point at 0/55F82DF8

2018-01-10 13:37:55.149 JST [5859] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-01-10 13:37:49.965 JST [2132] ERROR: duplicate key value violates unique constraint

"data1_pkey"

2018-01-10 13:37:49.965 JST [2132] DETAIL: Key (c1)=(2) already exists.

2018-01-10 13:37:49.968 JST [2131] WARNING: out of background worker slots

2018-01-10 13:37:49.968 JST [2131] HINT: You might need to increase max_worker_processes.

2018-01-10 13:37:49.968 JST [2123] LOG: worker process: logical replication worker for

subscription 16394 (PID 2132) exited with exit code 1

■競合の解消競合の解消

Subscrib erのテーブルでキーが重複するレコードを削除すると競合が解消し、レプリケーションが再開されます。また、Pu b lish er、Sub scrib erへのエラーメッセージも出力

されなくなります。

(サーバ2において実施)

subdb=# delete from data1 where c1 = 2;

DELETE 1

subdb=# select * from data1;

c1 | c2

----+-------

1 | aaaaa

2 | pub

6.4.5.2.2. CHECK制約違反制約違反

■初期状態初期状態

テーブルdata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。また、Su bscrib erのテーブルdata1のc1列にCHECK制約を付与します。

(サーバ2において実施)

subdb=# ALTER TABLE data1 ADD CONSTRAINT data1_c1_check CHECK (c1 < 10);

ALTER TABLE

subdb=# \d+ data1

Table "public.data1"

Description

--------+----------------------+-----------+----------+---------+----------+--------------+--------

-----

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

Check constraints:

"data1_c1_check" CHECK (c1 < 10)

■競合の発生競合の発生

Pu blish erのテーブルdata1に、Su b scrib erのみに追加したCHECK制約に違反するレコードを挿入すると、Pu blish erのINSERTは成功します。

PostgreSQL Enterprise Consortium

Page 205 of 285

(サーバ1において実施)

pubdb=# insert into data1 values (10, 'pub10');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+-------

1 | aaaaa

2 | pub

10 | pub10

この時Sub scrib erではCHECK制約違反による競合が発生し、レプリケーションが停止します。 Pu b lish er、Su b scrib erのログには競合が解消するまで5秒毎に以下の

メッセージが繰り返し出力されます。

(サーバ1のサーバログ)

2018-01-10 14:05:32.268 JST [6057] LOG: starting logical decoding for slot "sub1"

2018-01-10 14:05:32.268 JST [6057] DETAIL: streaming transactions committing after 0/55F833E8,

reading WAL from 0/55F833B0

2018-01-10 14:05:32.268 JST [6057] LOG: logical decoding found consistent point at 0/55F833B0

2018-01-10 14:05:32.268 JST [6057] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-01-10 14:05:32.097 JST [6020] LOG: logical replication apply worker for subscription "sub1"

has started

2018-01-10 14:05:32.102 JST [6020] ERROR: new row for relation "data1" violates check constraint

"data1_c1_check"

2018-01-10 14:05:32.102 JST [6020] DETAIL: Failing row contains (10, pub10).

2018-01-10 14:05:32.103 JST [2123] LOG: worker process: logical replication worker for

subscription 16394 (PID 6020) exited with exit code 1

■競合の解消競合の解消

Subscrib erのテーブルdata1のCHE CK制約をDRO Pすると競合が解消し、レプリケーションが再開されます。また、Pu b lish er、Su bscrib erへのエラーメッセージも出力さ

れなくなります。

(サーバ2において実施)

subdb=# ALTER TABLE data1 DROP CONSTRAINT data1_c1_check;

ALTER TABLE

6.4.5.2.3. 更新データが存在しない更新データが存在しない

■初期状態初期状態

テーブルdata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。また、Pu b lish er,Su bscrib erのテーブルdata1はそれぞれ以下のレコード

が存在する状態とします。

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+----

■競合の発生競合の発生

Pu blish erでレコードを更新するとPu blish erのU PDATEは成功しますが、Su bscrib erのレコードには変化がありません。また、Pu b lish er,Su b scrib erのログにエラーメッ

セージも出力されていません。

PostgreSQL Enterprise Consortium

Page 206 of 285

(サーバ1において実施)

pubdb=# update data1 set c2 = 'pub1a';

UPDATE 1

pubdb=# select * from data1;

c1 | c2

----+-------

1 | pub1a

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+----

キーが一致するレコードが存在しない場合の競合は無視され、レプリケーションも停止しないことがわかります。

6.4.5.2.4. 削除データが存在しない削除データが存在しない

■初期状態初期状態

が存在する状態とします。

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+----

■競合の発生競合の発生

Pu blish erでレコードを削除するとPu blish erのDELETEは成功しますが、Su bscrib erのレコードには変化がありません。また、Pu b lish er,Su bscrib erのログにエラーメッ

セージも出力されていません。

(サーバ2において実施)

subdb=# delete from data1 where c1 = 1;

DELETE 1

subdb=# select * from data1;

c1 | c2

----+----

subdb=# select * from data1;

c1 | c2

----+----

キーが一致するレコードが存在しない場合の競合は無視され、レプリケーションも停止しないことがわかります。

6.4.5.2.5. テーブルが存在しないテーブルが存在しない

■初期状態初期状態

テーブルdata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。

■競合の発生競合の発生

Subscrib erでテーブルdata1をDRO Pした後、Pu b lish erでテーブルdata1にレコードを挿入すると、Pu b lish erのINSERTは成功します。

PostgreSQL Enterprise Consortium

Page 207 of 285

(サーバ2において実施)

subdb=# DROP TABLE data1;

DROP TABLE

(サーバ1において実施)

pubdb=# insert into data1 values (1, 'pub1');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

この時Sub scrib erではテーブル不一致による競合が発生し、レプリケーションが停止します。 Pu b lish er、Sub scriberのログには競合が解消するまで5秒毎に以下のメッ

セージが繰り返し出力されます。

(サーバ1のサーバログ)

2018-01-10 15:09:10.872 JST [6331] LOG: starting logical decoding for slot "sub1"

2018-01-10 15:09:10.872 JST [6331] DETAIL: streaming transactions committing after 0/55F8B9E8,

reading WAL from 0/55F8B9B0

2018-01-10 15:09:10.872 JST [6331] LOG: logical decoding found consistent point at 0/55F8B9B0

2018-01-10 15:09:10.872 JST [6331] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-01-10 15:09:10.700 JST [6297] LOG: logical replication apply worker for subscription "sub1"

has started

2018-01-10 15:09:10.706 JST [6297] ERROR: logical replication target relation "public.data1" does

not exist

2018-01-10 15:09:10.708 JST [2123] LOG: worker process: logical replication worker for

subscription 16394 (PID 6297) exited with exit code 1

■競合の解消競合の解消

Subscrib erでテーブルdata1を再作成するとログにエラーは出力されなくなりますが、レプリケーションは再開されません。

(サーバ2において実施)

subdb=# CREATE TABLE data1 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

subdb=# select * from data1;

c1 | c2

----+----

これは、再作成したテーブルdata1がSu bscrip tio n su b 1からレプリケーション対象として認識されていないためと考えられます。

(サーバ2において実施)

subdb=# \dRs+

List of subscriptions

------+----------+---------+-------------+--------------------+------------------------------------

----------------------------

sub1 | postgres | t | {pub1} | off | host=192.168.127.31 dbname=pubdb

user=repusr1 password=repusr1

subdb=# select a3.subname, a2.relname, a1.srsubstate, a1.srsublsn from pg_subscription_rel as a1

left outer join pg_class as a2 on a1.srrelid = a2.oid left outer join pg_stat_subscription as a3 on

a1.srsubid = a3.subid;

subname | relname | srsubstate | srsublsn

---------+------------------+------------+------------

Subscrip tio n su b 1に対してALTER SUBSCRIPTIO N文を実行して、sub 1にレプリケーション対象テーブルを再認識させると、テーブルd a ta1のレプリケーションが再開さ

れます。

PostgreSQL Enterprise Consortium

Page 208 of 285

(サーバ2において実施)

subdb=# ALTER SUBSCRIPTION sub1 REFRESH PUBLICATION;

ALTER SUBSCRIPTION

subdb=# select a3.subname, a2.relname, a1.srsubstate, a1.srsublsn from pg_subscription_rel as a1

left outer join pg_class as a2 on a1.srrelid = a2.oid left outer join pg_stat_subscription as a3 on

a1.srsubid = a3.subid;

subname | relname | srsubstate | srsublsn

---------+------------------+------------+------------

sub1 | data1 | r | 0/55F8C298

6.4.5.2.6. 一部の列が存在しない一部の列が存在しない

■初期状態初期状態

テーブルdata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。また、Su bscrib erでテーブルdata1のc2列をDRO Pします。

(サーバ2において実施)

subdb=# ALTER TABLE data1 DROP COLUMN c2;

ALTER TABLE

subdb=# \d+ data1;

Table "public.data1"

--------+---------+-----------+----------+---------+---------+--------------+-------------

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

■競合の発生競合の発生

Pu blish erでテーブルdata1に対してレコードを挿入すると、Pu b lish erのINSERTは成功します。

(サーバ1において実施)

pubdb=# insert into data1 values (1, 'pub1');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

この時Sub scrib erでは列の不一致による競合が発生し、レプリケーションが停止します。 Pu b lish er、Su b scrib erのログには競合が解消するまで5秒毎に以下のメッセー

ジが繰り返し出力されます。

(サーバ1のサーバログ)

2018-01-10 15:53:11.464 JST [6480] LOG: starting logical decoding for slot "sub1"

2018-01-10 15:53:11.464 JST [6480] DETAIL: streaming transactions committing after 0/55F900C0,

reading WAL from 0/55F90088

2018-01-10 15:53:11.464 JST [6480] LOG: logical decoding found consistent point at 0/55F90088

2018-01-10 15:53:11.464 JST [6480] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-01-10 15:53:11.284 JST [6472] LOG: logical replication apply worker for subscription "sub1"

has started

2018-01-10 15:53:11.298 JST [6472] ERROR: logical replication target relation "public.data1" is

missing some replicated columns

2018-01-10 15:53:11.299 JST [6420] LOG: worker process: logical replication worker for

subscription 16394 (PID 6472) exited with exit code 1

■競合の解消競合の解消

Subscrib erでテーブルdata1のc2列を再度追加するとレプリケーションが再開されます。また、Pub lisher、Su bscrib erへのエラーメッセージも出力されなくなります。

PostgreSQL Enterprise Consortium

Page 209 of 285

(サーバ2において実施)

subdb=# ALTER TABLE data1 ADD COLUMN c2 VARCHAR(5);

ALTER TABLE

subdb=# \d+ data1;

Table "public.data1"

Description

--------+----------------------+-----------+----------+---------+----------+--------------+--------

-----

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

■Subscriberのテーブルに列が多く定義されている場合のテーブルに列が多く定義されている場合

前述のとおりSub scrib erのテーブルにPu b lish erのテーブルの列が存在しない場合は競合が発生します。逆にPub lish erのテーブルに存在しない列がSu b scriberのテー

ブルに存在した場合、以下のとおり競合は発生しません。この時Su b scrib erのテーブルのみに定義された列にはNULLが設定されます。

(サーバ1において実施)

pubdb=# \d data1

Table "public.data1"

Column | Type | Collation | Nullable | Default

--------+----------------------+-----------+----------+---------

c1 | integer | | not null |

c2 | character varying(5) | | |

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

Publications:

"pub1"

(サーバ2において実施)

subdb=# ALTER TABLE data1 ADD COLUMN c3 VARCHAR(5);　<-- Publisherに存在しないc3列を追加する

ALTER TABLE

subdb=# \d+ data1;

Table "public.data1"

Description

--------+----------------------+-----------+----------+---------+----------+--------------+--------

-----

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

(サーバ1において実施)

pubdb=# insert into data1 values (1, 'pub1');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2 | c3

----+------+------

1 | pub1 | NULL <-- c3列(Publisher未定義列)にはNULLが格納される

PostgreSQL Enterprise Consortium

Page 210 of 285

6.4.5.2.7. データ型変換エラーデータ型変換エラー

■初期状態初期状態

テーブルdata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。また、Su bscrib erでテーブルdata1のc2列を異なるデータ型に変更します。

(サーバ2において実施)

subdb=# ALTER TABLE data1 ALTER COLUMN c2 TYPE integer USING c2::integer;

ALTER TABLE

subdb=# \d+ data1;

Table "public.data1"

--------+---------+-----------+----------+---------+---------+--------------+-------------

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

■競合の発生競合の発生

Pu blish erでテーブルdata1に対してレコードを挿入すると、Pu b lish erのINSERTは成功します。

(サーバ1において実施)

pubdb=# insert into data1 values (1, 'pub1');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

この時Sub scrib erでは型の不一致による競合が発生し、レプリケーションが停止します。 Pu b lish er、Su b scrib erのログには競合が解消するまで5秒毎に以下のメッセー

ジが繰り返し出力されます。

(サーバ1のサーバログ)

2018-01-10 16:08:13.308 JST [6602] LOG: starting logical decoding for slot "sub1"

2018-01-10 16:08:13.308 JST [6602] DETAIL: streaming transactions committing after 0/55F943E8,

reading WAL from 0/55F943B0

2018-01-10 16:08:13.308 JST [6602] LOG: logical decoding found consistent point at 0/55F943B0

2018-01-10 16:08:13.308 JST [6602] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-01-10 16:08:13.136 JST [6597] LOG: logical replication apply worker for subscription "sub1"

has started

2018-01-10 16:08:13.142 JST [6597] ERROR: invalid input syntax for integer: "pub1"

2018-01-10 16:08:13.142 JST [6597] CONTEXT: processing remote data for replication target relation

"public.data1" column "c2", remote type character varying

, local type character varying

2018-01-10 16:08:13.143 JST [6420] LOG: worker process: logical replication worker for

subscription 16394 (PID 6597) exited with exit code 1

■競合の解消競合の解消

Subscrib erでc2列のデータ型を元に戻すとレプリケーションが再開されます。また、Pu b lish er、Su bscrib erへのエラーメッセージも出力されなくなります。

PostgreSQL Enterprise Consortium

Page 211 of 285

(サーバ2において実施)

subdb=# ALTER TABLE data1 ALTER COLUMN c2 TYPE VARCHAR(5);

ALTER TABLE

subdb=# \d+ data1;

Table "public.data1"

Description

--------+----------------------+-----------+----------+---------+----------+--------------+--------

-----

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

■データ型の暗黙的変換が可能な場合データ型の暗黙的変換が可能な場合

Pu blish erとSu b scriberのテーブルで列のデータ型が相違する場合でも暗黙的な変換が可能であれば以下のとおり競合は発生しません。

(サーバ2において実施)

subdb=# ALTER TABLE data1 ALTER COLUMN c2 TYPE date;

ALTER TABLE

subdb=# \d+ data1;

Table "public.data1"

--------+---------+-----------+----------+---------+---------+--------------+-------------

Indexes:

"data1_pkey" PRIMARY KEY, btree (c1)

(サーバ1において実施)

pubdb=# insert into data1 values (1, '2018/1/1');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+----------

1 | 2018/1/1

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+------------

1 | 2018-01-01 <-- 暗黙的な型変換が可能なレコードはレプリケーションされる(TEXT型 -> DATE型)

6.4.5.2.8. テーブルのロックテーブルのロック

■初期状態初期状態

テーブルdata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。

■競合の発生競合の発生

Subscrib erでレプリケーション対象のテーブルdata1を明示的にロックします。

(サーバ2において実施)

subdb=# BEGIN;

BEGIN

subdb=# LOCK TABLE data1 IN EXCLUSIVE MODE;

LOCK TABLE

PostgreSQL Enterprise Consortium

Page 212 of 285

Pu blish erでテーブルdata1に対してレコードを挿入すると、Pu b lish erのINSERTは成功しますが、Su b scrib erのテーブルdata1には反映されません。この時

Pu blish er、Su b scrib erのログにはエラーメッセージは出力されておらず、レプリケーションがロック解放を待機した状態となっています。

(サーバ1において実施)

pubdb=# insert into data1 values (1, 'pub1');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+----

■競合の解消競合の解消

Subscrib erでトランザクションを終了し、ロックを解放すると、レプリケーションが再開され、データが転送されます。

(サーバ2において実施)

subdb=# COMMIT;

COMMIT

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

6.4.5.2.9. 更新対象レコードのロック更新対象レコードのロック

■初期状態初期状態

テーブルdata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。

■競合の発生競合の発生

Subscrib erでテーブルdata1のレコードをSELECT F O R U PD ATEで明示的にロックします。

(サーバ2において実施)

subdb=# BEGIN;

BEGIN

subdb=# SELECT * FROM data1 WHERE c1 = 1 FOR UPDATE;

LOCK TABLE

Pu blish erで同一のレコードを更新すると、Pu b lish erのU PDATEは成功しますが、Su bscrib erのテーブルdata1には反映されません。この時Pu b lisher、Su bscrib erの

ログにはエラーメッセージは出力されておらず、レプリケーションがロック解放を待機した状態となっています。

(サーバ1において実施)

pubdb=# update data1 SET c2 = 'pub11' where c1 = 1;

UPDATE 1

pubdb=# select * from data1;

c1 | c2

----+-------

1 | pub11

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

■競合の解消競合の解消

PostgreSQL Enterprise Consortium

Page 213 of 285

Subscrib erでトランザクションを終了し、ロックを解放すると、レプリケーションが再開され、データが転送されます。

(サーバ2において実施)

subdb=# COMMIT;

COMMIT

subdb=# select * from data1;

c1 | c2

----+-------

1 | pub11

6.4.5.3. 初期データ同期時の競合発生と解消初期データ同期時の競合発生と解消

ロジカルレプリケーションの開始時に実行される初期データ同期処理においても更新時と同様の競合が発生する可能があります。以下で初期データ同期時に競合が発

生した時の挙動と競合を解消させるための方法をパターン毎に紹介します。

6.4.5.3.1. 主キー違反主キー違反 /一意キー違反一意キー違反

■初期状態初期状態

Pu blish er,Su b scrib erのテーブルd ata1にはc1列をPRIM ARY KEYとし、それぞれ以下のデータが存在する状態とします。

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+------

2 | pub2

■競合の発生競合の発生

Subscrib erでSu b scrip tion su b 1を作成し、ロジカルレプリケーションを開始します。この時Su b scriberでは主キー違反による競合が発生し、レプリケーションが停止しま

す。

(サーバ2において実施)

subdb=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub1;

NOTICE: created replication slot "sub1" on publisher

CREATE SUBSCRIPTION

Pu blish er、Su b scrib erのログには競合が解消するまで5秒毎に以下のメッセージが繰り返し出力されます。

PostgreSQL Enterprise Consortium

Page 214 of 285

(サーバ1のサーバログ)

2018-01-11 15:53:32.764 JST [10254] LOG: logical decoding found consistent point at 0/55FB4C50

2018-01-11 15:53:32.764 JST [10254] DETAIL: There are no running transactions.

2018-01-11 15:53:32.772 JST [10255] LOG: starting logical decoding for slot "sub1"

2018-01-11 15:53:32.772 JST [10255] DETAIL: streaming transactions committing after 0/55FB4C88,

reading WAL from 0/55FB4C50

2018-01-11 15:53:32.772 JST [10255] LOG: logical decoding found consistent point at 0/55FB4C50

2018-01-11 15:53:32.772 JST [10255] DETAIL: There are no running transactions.

2018-01-11 15:53:32.792 JST [10256] LOG: logical decoding found consistent point at 0/55FB4C88

2018-01-11 15:53:32.792 JST [10256] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-01-11 15:53:32.602 JST [10275] LOG: logical replication apply worker for subscription "sub1"

has started

2018-01-11 15:53:32.608 JST [10276] LOG: logical replication table synchronization worker for

subscription "sub1", table "data1" has started

2018-01-11 15:53:32.630 JST [10276] ERROR: duplicate key value violates unique constraint

"data1_pkey"

2018-01-11 15:53:32.630 JST [10276] DETAIL: Key (c1)=(2) already exists.

2018-01-11 15:53:32.630 JST [10276] CONTEXT: COPY data1, line 2

2018-01-11 15:53:32.631 JST [6420] LOG: worker process: logical replication worker for

subscription 16447 sync 16424 (PID 10276) exited with exit code 1

■競合の解消競合の解消

されなくなります。

(サーバ2において実施)

subdb=# delete from data1 where c1 = 2;

DELETE 1

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

6.4.5.3.2. CHECK制約違反制約違反

主キー違反/一意キー違反による競合と同じ挙動になると推測されるため割愛します。

6.4.5.3.3. 更新データが存在しない更新データが存在しない

初期データ同期では発生しないケースのため割愛します。

6.4.5.3.4. 削除データが存在しない削除データが存在しない

初期データ同期では発生しないケースのため割愛します。

6.4.5.3.5. テーブルが存在しないテーブルが存在しない

Pu blish er,Su b scrib erのテーブルd ata1にはc1列をPRIM ARY KEYとし、それぞれ以下のデータが存在する状態とします。

PostgreSQL Enterprise Consortium

Page 215 of 285

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+------

2 | pub2

Subscrib erでテーブルをDRO Pしてから、Su b scription を作成するとエラーとなります。Su b scrib erのデータベースにテーブルが存在しない状態ではSu b scrip tion を作成

できないため、初期データ同期時には発生しないケースとなります。

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

(サーバ2において実施)

subdb=# drop table data1;

DROP TABLE

subdb=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub1;

ERROR: relation "public.data1" does not exist

6.4.5.3.6. 一部の列が存在しない一部の列が存在しない

■初期状態初期状態

Pu blish erにはテーブルd ata1を作成し、レコードが3件存在する状態にします。Sub scrib erには列が少ないテーブルdata1を作成します。

(サーバ1において実施)

pubdb=# CREATE TABLE data1 (c1 INT PRIMARY KEY, c2 VARCHAR(5));

CREATE TABLE

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

(サーバ2において実施)

subdb=# CREATE TABLE data1 (c1 INT PRIMARY KEY);

CREATE TABLE

■競合の発生競合の発生

Subscrib erでSu b scrip tion su b 1を作成し、ロジカルレプリケーションを開始します。この時Su b scriberでは列定義の相違による競合が発生し、レプリケーションが停止

します。

(サーバ2において実施)

subdb=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub1;

NOTICE: created replication slot "sub1" on publisher

CREATE SUBSCRIPTION

PostgreSQL Enterprise Consortium

Page 216 of 285

Pu blish er、Su b scrib erのログには5秒毎に以下のメッセージが繰り返し出力されます。

(サーバ1のサーバログ)

2018-01-11 16:04:15.836 JST [10365] LOG: starting logical decoding for slot "sub1"

2018-01-11 16:04:15.836 JST [10365] DETAIL: streaming transactions committing after 0/55FB5AC0,

reading WAL from 0/55FB5A88

2018-01-11 16:04:15.836 JST [10365] LOG: logical decoding found consistent point at 0/55FB5A88

2018-01-11 16:04:15.836 JST [10365] DETAIL: There are no running transactions.

2018-01-11 16:04:15.849 JST [10366] LOG: logical decoding found consistent point at 0/55FB5AC0

2018-01-11 16:04:15.849 JST [10366] DETAIL: There are no running transactions.

(サーバ2のサーバログ)

2018-01-11 16:04:15.666 JST [10385] LOG: logical replication apply worker for subscription "sub1"

has started

2018-01-11 16:04:15.673 JST [10386] LOG: logical replication table synchronization worker for

subscription "sub1", table "data1" has started

2018-01-11 16:04:15.686 JST [10386] ERROR: logical replication target relation "public.data1" is

missing some replicated columns

2018-01-11 16:04:15.688 JST [6420] LOG: worker process: logical replication worker for

subscription 16454 sync 16449 (PID 10386) exited with exit code 1

Subscrib erでテーブルdata1を参照しても、初期データは同期されていません。

(サーバ2において実施)

subdb=# select * from data1;

----

■競合の解消競合の解消

更新時の競合発生と同じく、Su b scrib erでテーブルd ata 1のc2列を追加するとレプリケーションが再開されます。

6.4.5.3.7. データ型変換エラーデータ型変換エラー

一部の列が存在しないパターンと同じ挙動になると推測されるため割愛します。

6.4.5.3.8. テーブルのロックテーブルのロック

■初期状態初期状態

Pu blish er,Su b scrib erのテーブルd ata1にはそれぞれ以下のデータが存在する状態とします。

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+----

■競合の発生競合の発生

Subscrib erでテーブルdata1をLO CK TAB LE 〜 IN EXCLU SIVE M O DEで明示的にロックします。

PostgreSQL Enterprise Consortium

Page 217 of 285

(サーバ2において実施)

subdb=# BEGIN;

BEGIN

subdb=# LOCK TABLE data1 IN EXCLUSIVE MODE;

LOCK TABLE

Subscrib erで上記のトランザクションを実行したまま、別のコンソールでSu b scription を作成します。この時レプリケーションはロックを待機するため、テーブルdata1には初

期データが同期されていないことがわかります。

(サーバ2において実施)

subdb=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=192.168.127.31 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub1;

NOTICE: created replication slot "sub1" on publisher

CREATE SUBSCRIPTION

subdb=# select * from data1;

c1 | c2

----+----

■競合の解消競合の解消

Subscrib erでトランザクションを終了するとロックが解放されて、レプリケーションの初期データ同期が開始されます。

(サーバ2において実施)

subdb=# COMMIT;

COMMIT

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

6.4.5.3.9. 更新対象レコードのロック更新対象レコードのロック

初期データ同期では発生しないケースのため割愛します。

6.4.5.4. WALのスキップによる競合の解消のスキップによる競合の解消

前述の様にSu b scrib erで競合の原因となる要素を取り除く方法とは別に、競合が発生するW ALのSu bscrib erへの適用をスキップする方法について以下に紹介します。

■初期状態初期状態

テーブルdata1のデータがPu blish er,Su b scrib er間でレプリケーションされている状態とします。また、テーブルd ata1にはレコードが5件存在し、Pu b lish erのW ALのLSN

は「0/55FB 6948」となっています。

PostgreSQL Enterprise Consortium

Page 218 of 285

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

pubdb=# SELECT pg_current_wal_lsn() ;

pg_current_wal_lsn

--------------------

0/55FB6948

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

subdb=# SELECT oid, subname FROM pg_subscription ;

oid | subname

-------+---------

16463 | sub1

subdb=# SELECT * FROM pg_replication_origin_status;

local_id | external_id | remote_lsn | local_lsn

----------+-------------+------------+------------

1 | pg_16463 | 0/55FB6948 | 0/7360A120

■競合の発生競合の発生

Subscrib erでテーブルdata1に6件目のレコードを挿入した後、Pu b lish erで同一キーのレコードを挿入し、競合を発生させます。

(サーバ2において実施)

subdb=# insert into data1 values (6, 'sub6');

INSERT 0 1

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

6 | sub6

(サーバ1において実施)

pubdb=# insert into data1 values (6, 'pub6');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

6 | pub6

競合が発生しているため、Pu b lish erのLSNまでSu b scriberのLSN(remote_lsn)が到達していません。

PostgreSQL Enterprise Consortium

Page 219 of 285

(サーバ1において実施)

pubdb=# SELECT pg_current_wal_lsn() ;

pg_current_wal_lsn

--------------------

0/55FB6DB0

・SUBSCRIPTION側でremote_lsnを確認

(サーバ2において実施)

subdb=# SELECT * FROM pg_replication_origin_status;

local_id | external_id | remote_lsn | local_lsn

----------+-------------+------------+------------

1 | pg_16463 | 0/55FB6910 | 0/7360A120

■競合の解消競合の解消

Subscrib erでpg _replication _orig in _adva n ce関数を実行しLSNを進めることで、競合が発生しているW ALをスキップさせます。この時点でSu b scrib erのサーバログ

にはレプリケーションが停止した際のエラーメッセージが出力されなくなります。

(サーバ2において実施)

subdb=# SELECT pg_replication_origin_advance ('pg_16463', '0/55FB6DB0');

pg_replication_origin_advance

-------------------------------

Subscrib erでLSNを再度確認するとPu blish erのLSNと一致していることがわかります。なお、競合発生直前に挿入したレコード(c1=6, c2= sub 6)はそのまま残されてい

ます。

(サーバ2において実施)

subdb=# SELECT * FROM pg_replication_origin_status;

local_id | external_id | remote_lsn | local_lsn

----------+-------------+------------+------------

1 | pg_16463 | 0/55FB6DB0 | 0/7360A120

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

6 | sub6

この状態でPublish erに新しいレコードを挿入すると、Su b scrib erのc1=6のレコードは残されたままレプリケーションは再開されており、Pu b lish erでレコード

(c1=6,c2= pu b 6)を挿入したW ALのみがスキップされたことがわかります。

PostgreSQL Enterprise Consortium

Page 220 of 285

(サーバ1において実施)

pubdb=# insert into data1 values (7, 'pub7');

INSERT 0 1

pubdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

6 | pub6

7 | pub7

(サーバ2において実施)

subdb=# select * from data1;

c1 | c2

----+------

1 | pub1

2 | pub2

3 | pub3

4 | pub4

5 | pub5

6 | sub6

7 | pub7

6.4.6. ストリーミングレプリケーションとの併用ストリーミングレプリケーションとの併用

ここでは、ロジカルレプリケーションとストリーミングレプリケーションを併用する環境を想定し、以下の観点を確認します。

ストリーミングレプリケーションを併用する環境の構築手順

ストリーミングレプリケーションを併用する環境で障害が発生した場合の運用手順

6.4.6.1. 前提とする環境前提とする環境

本章は以下の環境を利用した検証結果を元に解説します。

Po stg reSQ Lサーバは3台構成

ロジカルレプリケーションは、Pu b lish er1台（サーバ1。IPアドレス 192｡168｡127｡31）、Sub scrib er1台（サーバ2。IPアドレス 192｡168｡127｡32）で構成

PostgreSQL Enterprise Consortium

Page 221 of 285

ストリーミングレプリケーションは、マスタ1台（Pu b lish erと同一）、スタンバイ1台（サーバ3。IPアドレス 192｡168｡127｡33）で構成

ロジカルレプリケーションのPu blish erでは、データベースクラスタ内に2つのデータベースを作成

pu b d b: レプリケーション対象のテーブルを個別定義するPu b licatio n を作成

pu b d b_all_tab le: データベース内に存在する全テーブルをレプリケーション対象とするPu b lication を作成

ロジカルレプリケーションのSubscrib erでは、データベースクラスタ内に2つのデータベースを作成

sub d b: Pu b lish erのpu b d b データベースに定義したPub licatio n から変更データを受け取るSu b scrip tion を作成

sub d b_all_table: Pu b lish erのpu b d b_all_tab leデータベースに定義したPu b lication から変更データを受け取るSub scrip tionを作成

6.4.6.2. ストリーミングレプリケーションを併用する環境の構築手順ストリーミングレプリケーションを併用する環境の構築手順

既にロジカルレプリケーションが稼働している環境に対してストリーミングレプリケーションを稼働させる手順は、新規でストリーミングレプリケーションを稼働させる手順と変わり

ません。(後で「SR環境の設定手順」への相互参照リンクを貼る)の手順にしたがってストリーミングレプリケーションのマスタ、スレーブを構築して下さい。

6.4.6.3. ストリーミングレプリケーションを併用する環境で障害が発生した場合の運用手順ストリーミングレプリケーションを併用する環境で障害が発生した場合の運用手順

■初期状態初期状態

Pu blish erにはデータベースpu b db とpu bd b _all_tableが存在します。また、pu b d bデータベース、pu b d b _all_tableデータベースには、Pu b lication がそれぞれ2つ、1

つ存在します。

(サーバ1において実施)

pubdb=# \dRp+

Publication pub1

-[ RECORD 1 ]-------

Owner | pubusr1

All tables | f

Inserts | t

Updates | t

Deletes | t

Tables:

"public.data1"

"public.data1_1"

Publication pub2

-[ RECORD 1 ]-------

Owner | pubusr1

All tables | f

Inserts | t

Updates | t

Deletes | t

Tables:

"public.data2"

pubdb_all_table=# \dRp+

Publication pub_all_table

-[ RECORD 1 ]--------

Owner | postgres

All tables | t

Inserts | t

Updates | t

Deletes | t

ロジカルレプリケーションのPu blish erとストリーミングレプリケーションのマスタを兼ねるサーバ1の動的統計情報ビューpg _stat_replication には、ロジカルレプリケーションの

情報(R E CO R D 1〜3)、ストリーミングレプリケーションの情報(RECO R D 4)が確認できます。

(サーバ1において実施)

pubdb=# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 2054

usesysid | 16385

usename | repusr1

application_name | sub_all_table

client_addr | 192.168.127.32

client_hostname |

PostgreSQL Enterprise Consortium

Page 222 of 285

client_port | 46604

backend_start | 2018-02-08 13:42:42.520503+09

backend_xmin |

state | streaming

sent_lsn | 0/580126B0

write_lsn | 0/580126B0

flush_lsn | 0/580126B0

replay_lsn | 0/580126B0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 2 ]----+------------------------------

pid | 1948

usesysid | 16385

usename | repusr1

application_name | sub2

client_addr | 192.168.127.32

client_hostname |

client_port | 46526

backend_start | 2018-02-08 13:36:25.199985+09

backend_xmin |

state | streaming

sent_lsn | 0/580126B0

write_lsn | 0/580126B0

flush_lsn | 0/580126B0

replay_lsn | 0/580126B0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 3 ]----+------------------------------

pid | 1850

usesysid | 16385

usename | repusr1

application_name | sub1

client_addr | 192.168.127.32

client_hostname |

client_port | 46524

backend_start | 2018-02-08 13:15:08.479523+09

backend_xmin |

state | streaming

sent_lsn | 0/580126B0

write_lsn | 0/580126B0

flush_lsn | 0/580126B0

replay_lsn | 0/580126B0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 4 ]----+------------------------------

pid | 1846

usesysid | 16385

usename | repusr1

application_name | nk_PGECons3

client_addr | 192.168.127.33

client_hostname |

client_port | 55520

backend_start | 2018-02-08 13:14:36.673678+09

backend_xmin |

state | streaming

sent_lsn | 0/580126B0

write_lsn | 0/580126B0

flush_lsn | 0/580126B0

PostgreSQL Enterprise Consortium

Page 223 of 285

replay_lsn | 0/580126B0

write_lag | 00:00:00.00054

flush_lag | 00:00:00.000541

replay_lag | 00:00:00.000541

sync_priority | 0

sync_state | async

サーバ1のシステムカタログpg _replication _slotsでは、ロジカルレプリケーションのSu b scrip tion と合わせて自動作成されたレプリケーションスロットの情報が確認できま

す。

(サーバ1において実施)

pubdb=# select * from pg_replication_slots;

-[ RECORD 1 ]-------+----------------

slot_name | sub2

plugin | pgoutput

slot_type | logical

datoid | 16384

database | pubdb

temporary | f

active | t

active_pid | 1948

xmin |

catalog_xmin | 701

restart_lsn | 0/58017AA8

confirmed_flush_lsn | 0/58017AE0

-[ RECORD 2 ]-------+----------------

slot_name | sub1

plugin | pgoutput

slot_type | logical

datoid | 16384

database | pubdb

temporary | f

active | t

active_pid | 1850

xmin |

catalog_xmin | 701

restart_lsn | 0/58017AA8

confirmed_flush_lsn | 0/58017AE0

-[ RECORD 3 ]-------+----------------

slot_name | sub_all_table

plugin | pgoutput

slot_type | logical

datoid | 16474

database | pubdb_all_table

temporary | f

active | t

active_pid | 2054

xmin |

catalog_xmin | 701

restart_lsn | 0/58017AA8

confirmed_flush_lsn | 0/58017AE0

pu b d bデータベース、pu bd b _all_tableデータベースそれぞれのd ata1テーブルにはあらかじめ1件データをINSERTしておきます。

(サーバ1において実施)

pubdb=# select * from data1;

c1 | c2

----+-------

1 | pub1

pubdb_all_table=# select * from data1;

c1 | c2

----+------

1 | pub1

Subscrib erのsubd b データベース、su b d b_all_tab leデータベースには、Su b scription がそれぞれ2つ、1つ存在します。

PostgreSQL Enterprise Consortium

Page 224 of 285

(サーバ2において実施)

subdb=# \dRs+

List of subscriptions

------+----------+---------+-------------+--------------------+------------------------------------

----------------------------

sub1 | postgres | t | {pub1} | off | host=192.168.127.31 dbname=pubdb

user=repusr1 password=repusr1

sub2 | postgres | t | {pub2} | off | host=192.168.127.31 dbname=pubdb

user=repusr1 password=repusr1

subdb_all_table=# \dRs+

List of subscriptions

Conninfo

---------------+----------+---------+-----------------+--------------------+-----------------------

---------------------------------------------------

sub_all_table | postgres | t | {pub_all_table} | off | host=192.168.127.31

dbname=pubdb_all_table user=repusr1 password=repusr1

ロジカルレプリケーションのSubscrib erであるサーバ2の動的統計情報ビューp g_stat_su b scrip tion には、ロジカルレプリケーションの情報が3件確認できます。

(サーバ2において実施)

subdb_all_table=# select * from pg_stat_subscription;

last_msg_receipt_time | latest_end_lsn | latest_end_time

-------+---------------+-------+-------+--------------+-------------------------------+------------

-------------------+----------------+-------------------------------

16463 | sub1 | 11038 | | 0/58011F60 | 2018-02-08 13:42:47.590367+09 | 2018-02-08

13:42:47.423435+09 | 0/58011F60 | 2018-02-08 13:42:47.590367+09

24677 | sub2 | 11072 | | 0/58011F60 | 2018-02-08 13:42:47.59058+09 | 2018-02-08

13:42:47.42367+09 | 0/58011F60 | 2018-02-08 13:42:47.59058+09

24678 | sub_all_table | 11158 | | 0/58011F60 | 2018-02-08 13:42:47.590534+09 | 2018-02-08

13:42:47.423605+09 | 0/58011F60 | 2018-02-08 13:42:47.590534+09

ストリーミングレプリケーションのスレーブであるサーバ3では動的統計情報ビューpg_stat_w al_receiverでストリーミングレプリケーションの情報が確認できます。

(サーバ3において実施)

pubdb=# select * from pg_stat_wal_receiver;

-[ RECORD 1 ]---------+----------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------

-------------------------------------------------

pid | 26152

status | streaming

receive_start_lsn | 0/58000000

receive_start_tli | 1

received_lsn | 0/58016A78

received_tli | 1

last_msg_send_time | 2018-02-08 13:52:22.063552+09

last_msg_receipt_time | 2018-02-08 13:52:21.953994+09

latest_end_lsn | 0/58016A78

latest_end_time | 2018-02-08 13:52:22.063552+09

slot_name |

conninfo | user=repusr1 password=******** dbname=replication host=192.168.127.31

port=5432 application_name=nk_PGECons3 fallback_application_name=walreceiver sslmode=prefer

sslcompression=1 krbsrvname=postgres target_session_attrs=any

また、サーバ3にはマスタであるサーバ1で定義されているPu b lication がストリーミングレプリケーションで複製されています。

PostgreSQL Enterprise Consortium

Page 225 of 285

(サーバ3において実施)

pubdb=# \dRp+

Publication pub1

-[ RECORD 1 ]-------

Owner | pubusr1

All tables | f

Inserts | t

Updates | t

Deletes | t

Tables:

"public.data1"

"public.data1_1"

Publication pub2

-[ RECORD 1 ]-------

Owner | pubusr1

All tables | f

Inserts | t

Updates | t

Deletes | t

Tables:

"public.data2"

pubdb_all_table=# \dRp+

Publication pub_all_table

-[ RECORD 1 ]--------

Owner | postgres

All tables | t

Inserts | t

Updates | t

Deletes | t

ただし、サーバ3はサーバ2とのロジカルレプリケーションは確立していないため、サーバ3の動的統計情報ビューpg _stat_replication ,pg_replication _slotsを見ても、

サーバ1と同じ情報は存在しません。

(サーバ3において実施)

pubdb_all_table=# select * from pg_replication_slots;

(0 rows)

pubdb_all_table=# select * from pg_stat_replication;

(0 rows)

■ストリーミングレプリケーションのマスタを切り替える手順ストリーミングレプリケーションのマスタを切り替える手順

初期状態の構成でストリーミングレプリケーションのマスタに障害が発生した状態を想定し、昇格したスレーブへロジカルレプリケーションを切り替える手順を説明します。切

替後の環境は以下の様になります。

PostgreSQL Enterprise Consortium

Page 226 of 285

まず、ストリーミングレプリケーションのマスタ(サーバ1)のPostgreSQ Lサーバを強制終了します。

(サーバ1において実施)

-bash-4.2$ pg_ctl -m f stop

サーバ停止処理の完了を待っています....完了

サーバは停止しました

ストリーミングレプリケーションのスレーブ(サーバ3)でp g _ctl p romoteコマンドを実行し、マスタに昇格します。

(サーバ3において実施)

-bash-4.2$ pg_ctl promote

waiting for server to promote....完了

server promoted

サーバ3のログでマスタとして接続を受け付け始めたことが確認でき、ストリーミングレプリケーションのマスタ切替は完了します。

(サーバ3のサーバログ)

2018-02-08 15:16:34.693 JST [26148] LOG: received promote request

2018-02-08 15:16:34.693 JST [26148] LOG: redo done at 0/58020F38

2018-02-08 15:16:34.693 JST [26148] LOG: last completed transaction was at log time 2018-02-08

14:24:19.546571+09

2018-02-08 15:16:34.694 JST [26148] LOG: selected new timeline ID: 2

2018-02-08 15:16:34.734 JST [26148] LOG: archive recovery complete

2018-02-08 15:16:34.738 JST [26146] LOG: database system is ready to accept connections

次に、サーバ3を新たなPu b lish erとしたロジカルレプリケーションを開始させてみます。

まず、サーバ2でALTER SU B SCR IPTIO N文を実行して既存のSub scrip tion の接続先を変更してみました。

(サーバ2において実施)

subdb=# ALTER SUBSCRIPTION sub1 CONNECTION 'host=192.168.127.33 dbname=pubdb user=repusr1

password=repusr1';

ALTER SUBSCRIPTION

Subscrib erのログを見るとサーバ3にレプリケーションスロット su b 1 が存在しないことが原因で失敗しています。

PostgreSQL Enterprise Consortium

Page 227 of 285

(サーバ2のサーバログ)

2018-02-08 15:27:04.296 JST [11029] LOG: worker process: logical replication worker for

subscription 24678 (PID 12728) exited with exit code 1

2018-02-08 15:27:04.299 JST [12729] LOG: logical replication apply worker for subscription "sub1"

has started

2018-02-08 15:27:04.302 JST [12729] ERROR: could not start WAL streaming: ERROR: replication slot

"sub1" does not exist

また、既存のSu b scription を再作成しようとしても、レプリケーションスロット sub 1 が存在しないことで削除も拒否されます。

(サーバ2において実施)

subdb=# DROP SUBSCRIPTION sub1;

ERROR: could not drop the replication slot "sub1" on publisher

DETAIL: The error was: ERROR: replication slot "sub1" does not exist

Subscrip tio n のD R O P時にはレプリケーションスロットも合わせてDRO Pしようとします。今回の様にレプリケーションスロットが存在しないSub scrip tion が残存する場合は、

Subscrip tio n を一時停止(D ISABLE)し、レプリケーションスロットとの対応を無効化(slot_n ame = NO NE)してからDRO Pする必要があります。

(サーバ2において実施)

subdb=# ALTER SUBSCRIPTION sub1 DISABLE;

ALTER SUBSCRIPTION

subdb=# ALTER SUBSCRIPTION sub1 SET (slot_name = NONE);

ALTER SUBSCRIPTION

subdb=# DROP SUBSCRIPTION sub1;

DROP SUBSCRIPTION

subdb_all_table=# ALTER SUBSCRIPTION sub_all_table DISABLE;

ALTER SUBSCRIPTION

subdb_all_table=# ALTER SUBSCRIPTION sub_all_table SET (slot_name = NONE);

ALTER SUBSCRIPTION

subdb_all_table=# DROP SUBSCRIPTION sub_all_table;

DROP SUBSCRIPTION

Subscrip tio n をDRO Pした後、新たにSu b scrip tion を作り直すと、LR が開始されます。

(サーバ2において実施)

subdb=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=192.168.127.33 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub1 WITH (copy_data = false);

NOTICE: created replication slot "sub1" on publisher

CREATE SUBSCRIPTION

subdb=# CREATE SUBSCRIPTION sub2 CONNECTION 'host=192.168.127.33 dbname=pubdb user=repusr1

password=repusr1' PUBLICATION pub2 WITH (copy_data = false);

NOTICE: created replication slot "sub2" on publisher

CREATE SUBSCRIPTION

(サーバ2のサーバログ)

2018-02-08 15:53:08.879 JST [13210] LOG: logical replication apply worker for subscription "sub1"

has started

2018-02-08 15:57:37.386 JST [13231] LOG: logical replication apply worker for subscription "sub2"

has started

2018-02-08 15:57:37.393 JST [13232] LOG: logical replication table synchronization worker for

subscription "sub2", table "data2" has started

2018-02-08 15:57:37.405 JST [13232] LOG: logical replication table synchronization worker for

subscription "sub2", table "data2" has finished

なお、CREATE SUB SCR IPTIO N文にW ITH (copy_d ata = false)を付与すると、ロジカルレプリケーション開始時の初期データコピーがスキップされます。試しにW ITH

(co p y_d ata = false) を付けずに実行すると、初期データのコピー時に残存するデータとキー重複を起こし、ロジカルレプリケーションが開始されません。

PostgreSQL Enterprise Consortium

Page 228 of 285

(サーバ2において実施)

subdb_all_table=# CREATE SUBSCRIPTION sub_all_table CONNECTION 'host=192.168.127.33

dbname=pubdb_all_table user=repusr1 password=repusr1' PUBLICATION pub_all_table;

NOTICE: created replication slot "sub_all_table" on publisher

CREATE SUBSCRIPTION

(サーバ2のサーバログ)

2018-02-08 16:00:04.913 JST [13245] LOG: logical replication table synchronization worker for

subscription "sub_all_table", table "data1" has started

2018-02-08 16:00:04.923 JST [13246] LOG: logical replication table synchronization worker for

subscription "sub_all_table", table "data2" has started

2018-02-08 16:00:04.928 JST [13245] ERROR: duplicate key value violates unique constraint

"data1_pkey"

2018-02-08 16:00:04.928 JST [13245] DETAIL: Key (c1)=(1) already exists.

2018-02-08 16:00:04.928 JST [13245] CONTEXT: COPY data1, line 1

2018-02-08 16:00:04.929 JST [11029] LOG: worker process: logical replication worker for

subscription 24685 sync 16479 (PID 13245) exited with exit code 1

2018-02-08 16:00:04.939 JST [13246] ERROR: duplicate key value violates unique constraint

"data2_pkey"

2018-02-08 16:00:04.939 JST [13246] DETAIL: Key (c1)=(1) already exists.

2018-02-08 16:00:04.939 JST [13246] CONTEXT: COPY data2, line 1

SRの新マスタとなったサーバ3の動的統計情報ビューpg _stat_replication を確認すると、サーバ3⇒サーバ2のロジカルレプリケーションが確立していることがわかります。

PostgreSQL Enterprise Consortium

Page 229 of 285

(サーバ3において実施)

pubdb_all_table=# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid | 26661

usesysid | 16385

usename | repusr1

application_name | sub_all_table

client_addr | 192.168.127.32

client_hostname |

client_port | 53059

backend_start | 2018-02-08 16:07:25.52522+09

backend_xmin |

state | catchup

sent_lsn | 0/58022DA0

write_lsn | 0/58022DA0

flush_lsn | 0/58022DA0

replay_lsn | 0/58022DA0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 2 ]----+------------------------------

pid | 26503

usesysid | 16385

usename | repusr1

application_name | sub2

client_addr | 192.168.127.32

client_hostname |

client_port | 52951

backend_start | 2018-02-08 15:57:37.444994+09

backend_xmin |

state | streaming

sent_lsn | 0/58022DA0

write_lsn | 0/58022DA0

flush_lsn | 0/58022DA0

replay_lsn | 0/58022DA0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

-[ RECORD 3 ]----+------------------------------

pid | 26486

usesysid | 16385

usename | repusr1

application_name | sub1

client_addr | 192.168.127.32

client_hostname |

client_port | 52949

backend_start | 2018-02-08 15:53:08.937385+09

backend_xmin |

state | streaming

sent_lsn | 0/58022DA0

write_lsn | 0/58022DA0

flush_lsn | 0/58022DA0

replay_lsn | 0/58022DA0

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

6.4.6.4. 考察考察

ロジカルレプリケーションとストリーミングレプリケーションを併用する場合、更新対象を一元化してデータの整合性を担保しやすくするため、ストリーミングレプリケーションのマス

PostgreSQL Enterprise Consortium

Page 230 of 285

タとロジカルレプリケーションのPu blish erは同じサーバにした方がよいと考えます。

この場合、ストリーミングレプリケーションのマスタがスレーブに切り替わってもPu blica tion を再定義する必要はありません。

一方でSu b scrip tion は再作成が必要で、古いSub scriptio n はレプリケーションスロットとの対応を無効化してから削除する必要があります。また、新たなSu b scrib erを

作成する際は以下のいずれかの方法が選択できます。

CREATE SUB SCR IPTIO N文にW ITH (copy_data = false)を付けて初期データコピーを回避する。

Subscrib erのテーブルをあらかじめTRU NCATE TAB LEで空にしてからCREATE SU B SCR IPTIO Nを実行し、初期データコピーをやり直す。

前者は初期データコピーの処理が不要でロジカルレプリケーションを再開するまでの時間を短縮できますが、マスタの切替えからSu b scription の再作成までに発生する更

新を複製できないデメリットがありますので、運用形態によって選択する必要がありそうです。

6.5. まとめ

本章ではまずPostgreSQ Lのロジカルレプリケーションの特徴、アーキテクチャ、ユースケース、制限事項を整理し、実際の構築例を交えてロジカルレプリケーションを設定す

る具体的な手順を説明しました。ストリーミングレプリケーションではマスタのベースバックアップからデータベースクラスタ単位で一致するスレーブを作成したのに対し、ロジカル

レプリケーションではPu b lication /Su b scrip tion といったオブジェクトによって、テーブル単位や更新種別単位での柔軟な複製形態でのレプリケーションを構成できることが

わかりました。

また、実行時パラメータについては稼働するプロセス数との関係を検証した結果を踏まえて妥当な値を算出する方法を提示しました。アーキテクチャがストリーミングレプリ

ケーションと共通な部分があるため一部の実行時パラメータはストリーミングレプリケーションで使用するプロセス数を考慮した設定が必要であることがわかりました。

次に同期レプリケーション、複数Sub scrip tion へのレプリケーション、カスケード構成といった応用的な使い方を検証し、ロジカルレプリケーションでもストリーミングレプリケー

ションと同様の構成がとれることが確認できました。また、パーティショニングを組み合わせることで複数サーバのデータを1つのサーバに集約するデータ統合の用途にも応用で

きることが確認できました。

さらにロジカルレプリケーションを実際に運用するシーンを想定し、監視方法や障害発生時の挙動、レプリケーション開始後のテーブル追加、定義変更の手順について検

証しました。ストリーミングレプリケーションと違いロジカルレプリケーションではSubscrib erを更新できる代わりに整合性をユーザが担保しなければならないため、更新時の競

合が発生した場合もユーザ側で検知、解消する必要があります。ただし、現状では競合が発生した際の対応方法は限られており、運用も容易ではないため、基本的に

競合が発生しない設計、運用を心がけるべきです。つまり、Su b scrib erには検索用のインデックスを付与する程度に留めてデータの更新は行わないのが望ましいと考えま

す。また、ストリーミングレプリケーションとロジカルレプリケーションを併用する環境での障害を想定した検証では、Su bscrip tio n を新しいPu b lication につなぎ直してロジカ

ルレプリケーションを再開するまでの具体的な手順を確認できました。

ロジカルレプリケーションは、アーキテクチャの面でストリーミングレプリケーションと共通する部分がありますが、データベースクラスタ単位で複製されるストリーミングレプリケーショ

ンよりも柔軟にテーブル単位、更新種別単位で複製できるようになり、レプリケーションの活用範囲が広がったといえます。その一方で、運用面ではロジカルレプリケーションの

対象とならない操作やオブジェクトが存在することや、更新時の競合が発生した時の運用が全てユーザに任されている点など現状では制約事項も多く、運用面の負荷が

軽減される機能強化が今後求められます。

PostgreSQL Enterprise Consortium

Page 231 of 285

7. Bi-Directional Replication (BDR)

7.1. はじめに

7.1.1. BDRの特徴の特徴

7.1.1.1. BDRとはとは

B D R (B i-D irection al Replication )は2n dQ u a d ran t社によって開発された、オープンソース（Po stgreSQ L Licen se）のマルチマスタ・レプリケーションシステムです。双

方向の非同期論理レプリケーションを使用し、地理的に分散したクラスタで使用するために設計されています。

マルチマスタについて

一般的なRDB M Sの冗長化構成（マスタスレーブ構成）においては、更新処理を実行可能なサーバをマスタと呼称します。マルチマスタとは、同一のデータを保持している

複数のD B 間（クラスタ）において、更新処理を実施可能なサーバが複数台存在する構成を指します。 BD R では双方向にレプリケーションを実施することで、複数のサーバ

への更新を可能にしています。

7.1.1.2. ユースケースユースケース

B D R は以下のようなケースで有用です。

1. 遠隔地や高レイテンシ環境でクラスタを構成している場合。

2. 各ノードが書き込み処理を実施する場合。

3. クラスタ間でデータが非同期であることを許容できる場合。

例としては以下のようにレスポンスを向上させるために各地でアプリケーション及びDB を動作させるようなケースが考えられます。

図 7.1 B D Rユースケース

7.1.1.3. メカニズムメカニズム

B D R では「Lo gical Decodin g 」により、W ALから論理的な変更点を抽出し、各ノードで適用することで双方向レプリケーションを実現しています。（Lo g ical Decodin g

及びW ALの送受信はバックグラウンドワーカープロセスが実施します）

従来のトリガーを用いた双方向レプリケーションの場合、下図のように書き込みが余分に発生（変更記録、変更反映）してしまいます。

図 7.2 トリガベースメカニズム

一方、BD R では余分な書き込みが発生せずパフォーマンス的に有利となっています。

図 7.3 B D Rメカニズム

利用されているPo stg reSQ Lのメカニズムの一覧です。

PostgreSQL Enterprise Consortium

Page 232 of 285

表 7.1 利用メカニズムの一覧

No. 機能機能概要概要

1 Event Trig gers 一つのテーブルに接続され、DMLイベントのみを補足する通常のトリガとは異なり、特定データベースのDDLイベントを捕

捉可能。

2 Lo gical Decodin g SQ Lを介して実行された更新処理を外部コンシューマへストリーミングするための機能。更新結果はロジカルレプリケー

ションスロットで識別され、ストリームに送出される。

3 Rep lica tion Slots マスタのデータベースの変更をスレーブ側に同じ順序で適用するための機能。

4 Backgro u n d W orkers ユーザ提供のコードを別プロセスで実行するように拡張する機能。Backgro u n d W o rk erプロセスはp o stg resプロセス

によって起動、終了、監視される。

5 Co mmit Timestamps トランザクションがいつコミットされたかを確認するための機能。

6 Rep lica tion O rig in s レプリケーションの進行状況を追跡するための機能。双方向レプリケーションにてループの防止などが可能。

7 DDL even t captu re 実行されるDDLコマンドを返す機能。

8 generic W AL messag es for

lo g ical d ecod ing

テキストあるいはバイナリのメッセージをW ALに挿入できる仕組み（API）。Logical Decod ing 機能によって読み出され

ることを想定している。

7.1.1.4. 整合性整合性

マルチマスタ構成を取る場合、各ノードが持つ情報に不整合が発生しないように管理する仕組みが必要となります。 BDR では結果整合性（eventually con sisten t）と

呼ばれる一貫性モデルを採用し、整合性を確保します。

デフォルトでは競合が発生した場合、最後の更新処理が適用されます。（last_up date_w ins）

競合結果はテーブル「b d r.bdr_co n flict_histo ry」で確認可能です。

図 7.4 結果整合性

7.1.1.5. シーケンスシーケンス

B D R では一意な値を払い出すために、「グローバルシーケンス」、「ステップ/オフセットシーケンス」という2つの手法を紹介しています。

1. グローバルシーケンス

グローバルシーケンスでは、各ノードに予め値の塊（ch u n k）を一定数ずつ割り振ることで値の重複を回避しています。

ch u n kを消費するとvo ting処理（下記参照）を行い、新たにch u n k を割り振ります。

グローバルシーケンスは廃止予定です。（下記のステップ/オフセットシーケンスを推奨）

voting処理

"ch u n k"と呼ばれるシーケンス番号のまとまりをノードに割り当てる処理をvo tin g 処理と呼びます。 "ch u n k"が複数のノードに割り当てられないことを確認するため、ノード

間で投票処理が行われており、正常に機能させるためには奇数台のノードが必要です。過半数のノードが停止している場合は、投票処理にて過半数に到達しなくなる

ため、新しい"ch u n k "がノードに割り当てられません。そして、"ch u n k "が枯渇した場合、n extvalの実行に失敗してしまいます。

図 7.5 グローバルシーケンス

2. ステップ/オフセットシーケンス

ステップ/オフセットシーケンスでは、各ノードで通常のPostg reSQ Lシーケンスを使用します。各シーケンスを同じ量だけ増分されるようにし、値が重複し

ないように設定します。

PostgreSQL Enterprise Consortium

Page 233 of 285

設計時には注意が必要です。

増分する値をある程度大きく取らないとノードの追加に対応できません。（例： 10の増分であればノード数の追加は10台まで）

図 7.6 ステップ/オフセットシーケンス

7.1.1.6. 比較表比較表

類似機能及び製品との机上比較の結果です。

表 7.2 類似機能及び製品との机上比較

No. 比較項目比較項目 BDR SR(Hot Standby) Slo ny

ロジカルレプリケーショロジカルレプリケーショ

ンン

1 マルチマスタ ○ × × ×

2 選択的レプリケーション ○ × ○ ○

3 競合検知 ○ × × ○

4 カスケーディング × ○ ○ ○

5 W ALベースレプリケーション ○ ○ × ○

6 DDLレプリケーション ○ ○ × ×

7 自動レプリカ新テーブル ○ ○ × ×

8 シーケンスレプリケーション ○ ○ ○ ×

9 プライマリキー更新 ○ ○ × ○

10 同期コミット ○ ○ × ○

11 外部デーモン不使用 ○ ○ × ○

12 レプリカへの書き込み ○ × ○ ○

h ttps://2n d q u adran t.co m/en/resou rces/bdr/

7.1.1.7. サポートサポート

サポートについては以下が存在します。

表 7.3 サポート

No. サポートサポート概要概要

1 無償サポート B D R コミュニティへのメール、B D RのG o o g leグループが存在。

email: b d r-list@ 2nd Q u adran t.co m

Go og leグループ: h ttp s://g ro u p s.g o o g le.co m/a/2n d Q u adra n t.co m/foru m/#!fo rum/bd r-list

2 有償サポート 2n d Q u ad ran t社によるサポートを受けることが可能です。

※ 2n d Q u ad ran t社について

B D R の製造元で、Po stgreSQ Lの専門家（コミッター等）が多数在籍する企業です。

Po stg reSQ Lのコンサルティングサービス等を提供しています。

h ttps://2n d q u adran t.co m/en/

7.2. 調査、検証の目的

机上の情報整理および検証について、以下を主な目的としています。

情報整理

B D R を使用したマルチマスタ環境を構築、運用するにあたり、各種機能やパラメータの理解に必要な情報の提供

検証

B D R の動作（競合時等）や障害発生時の対処法を調査

更新性能の検証

PostgreSQL Enterprise Consortium

Page 234 of 285

7.3. 調査、検証の前提

表 7.4 調査、検証の前提

項目項目説明説明

Po stg reSQ Lバージョン 9.4.10

※ 調査時点ではB D R は9.6に対応していなかったため

B D R バージョン 1.0.2

ソースコード：h ttps://g ith u b .co m/2n d Q u ad ran t/b d r

O S Cen tO S 7.1

構成 2ノード構成

ダウンロードモジュールは以下になります。

po stg resq l-b d r94-bdr.x86_64 0:1.0.2-1_2n d Q uad ran t.el7.cen tos

po stg resq l-b d r94.x86_64 0:9.4.10_bdr1-1_2n d Q u adran t.el7.centos

po stg resq l-b d r94-con trib.x86_64 0:9.4.10_bdr1-1_2ndQ uadran t.el7.cento s

po stg resq l-b d r94-lib s.x86_64 0:9.4.10_bdr1-1_2ndQ uadran t.el7.centos

po stg resq l-b d r94-server.x86_64 0:9.4.10_bdr1-1_2ndQ uadran t.el7.centos

以下は構成図になります。

図 7.7 調査、検証環境構成図

7.4. BDR環境構築時の設定と設定手順

7.4.1. BDR環境の設定手順環境の設定手順

7.4.1.1. 概要概要

Po stg reSQ L B D R (B i-Directio n al Replication )を利用したマルチマスタ環境の構築手順について確認します。

また、マルチマスタ環境構築後、各ノードに対して更新が実行可能かを確認します。

h ttp://b dr-pro ject.o rg/d o cs/n ext/in stalla tion -p ackages.html#INSTALLATIO N-PACKAG E S-REDHAT

こちらの環境で検証を実施しました。

7.4.1.2. 対象試験サーバ対象試験サーバ

PostgreSQL Enterprise Consortium

Page 235 of 285

表 7.5 対象試験サーバ

サーバ名サーバ名 IPアドレスアドレス

n od e1 192.168.0.10

n od e2 192.168.0.12

7.4.1.3. 事前確認事前確認

1. yu mが利用可能な状態であること

パッケージを入手する際にyu mを使用

設定手順

指定がない部分は、n o d e1・n o de2両方で実施します。

1. 検証環境準備

B D R 検証を実施するための環境を準備します。

ssh接続を用いて、該当環境へ接続

ユーザ: root

パスワード: xxxxxxx

2. h ostsの設定

DNSの名前解決のために各サーバのホスト名を設定します。

# vi /etc/hosts

[下記をファイル末尾に追加]

192.168.0.10 node1

192.168.0.12 node2

3. 関連ポートの開放

Po stg reSQ L間のB DR接続のために5432ポートの開放をします。

# firewall-cmd --permanent --add-port=5432/tcp

# firewall-cmd --reload

以下のコマンドで確認します。

# firewall-cmd --list-ports

5432/tcp

4. B D R レポジトリの登録

B D R レポジトリ用のRPMをインストールします。

# RHEL/CentOS users only:

# yum install http://packages.2ndquadrant.com/postgresql-bdr94-2ndquadrant/yum-repo-

rpms/postgresql-bdr94-2ndquadrant-redhat-latest.noarch.rpm

以下のコマンドでインストール済み一覧を確認します。

PostgreSQL Enterprise Consortium

Page 236 of 285

# yum list installed postgresql-bdr94-2ndquadrant-redhat.noarch 0:1.0-3

[省略]

インストール済みパッケージ

postgresql-bdr94-2ndquadrant-redhat.noarch 1.0-3 installed

5. B D R インストール

登録したB DRレポジトリからBD R をインストールします。

# yum install postgresql-bdr94-bdr

[省略]

インストール:

postgresql-bdr94-bdr.x86_64 0:1.0.2-1_2ndQuadrant.el7.centos

依存性関連をインストールしました:

postgresql-bdr94.x86_64 0:9.4.10_bdr1-1_2ndQuadrant.el7.centos

postgresql-bdr94-contrib.x86_64 0:9.4.10_bdr1-1_2ndQuadrant.el7.centos

postgresql-bdr94-libs.x86_64 0:9.4.10_bdr1-1_2ndQuadrant.el7.centos

postgresql-bdr94-server.x86_64 0:9.4.10_bdr1-1_2ndQuadrant.el7.centos

完了しました!

以下のコマンドでインストール済み一覧を確認します。

# yum list installed postgresql-bdr94-bdr.x86_64 0:1.0.2-1_2ndQuadrant.el7.centos

[省略]

インストール済みパッケージ

postgresql-bdr94-bdr.x86_64 1.0.2-1_2ndQuadrant.el7.centos

@postgresql-bdr94-2ndquadrant-redhat

6. 環境変数設定

データベースクラスタとコマンド実行ファイルに環境変数の設定をします。

$ vi ~/.bash_profile

[下記の修正を加える]

#PGDATA=/var/lib/pgsql/9.4-bdr/data

PGDATA=/var/lib/pgsql/2ndquadrant_bdr/data/

[下記をファイル末尾に追加]

export PATH=/usr/pgsql-9.4/bin:$PATH

以下のコマンドで設定した環境変数を確認します。

$ exit

ログアウト

# su - postgres

$ echo $PATH

/usr/pgsql-9.4/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin

$ echo $PGDATA

/var/lib/pgsql/2ndquadrant_bdr/data/

7. データベースクラスタ作成

B D R 検証用に新規でデータベースクラスタを作成します。

PostgreSQL Enterprise Consortium

Page 237 of 285

$ mkdir -p $HOME/2ndquadrant_bdr/

$ initdb -D $HOME/2ndquadrant_bdr/data -A trust -U postgres --no-locale

8. B D R のパラメータ設定(p o stgresql.con f)

B D R のパラメータ設定(p o stgresql.con f)をします。

$ vi /var/lib/pgsql/2ndquadrant_bdr/data/postgresql.conf

[下記の修正を加える]

listen_addresses = '*'

shared_preload_libraries = 'bdr'

wal_level = 'logical'

track_commit_timestamp = on

max_connections = 100

max_wal_senders = 10

max_replication_slots = 10

# Make sure there are enough background worker slots for BDR to run

max_worker_processes = 10

log_line_prefix = '%m d=%d p=%p a=%a%q '

# These aren't required, but are useful for diagnosing problems

#log_error_verbosity = verbose

#log_min_messages = debug1

# Useful options for playing with conflicts

#bdr.default_apply_delay=2000 # milliseconds

#bdr.log_conflicts_to_table=on

9. B D R のクライアント認証設定(pg_h ba.co n f)

B D R のクライアント認証設定(pg_h ba.co n f)をします。

$ vi /var/lib/pgsql/2ndquadrant_bdr/data/pg_hba.conf

[下記の修正を加える]

host all all 192.168.0.10/32 trust

host all all 192.168.0.12/32 trust

local replication postgres trust

host replication postgres 0.0.0.0/0 trust

host replication postgres ::1/128 trust

10. Po stgreSQ L起動

設定が環境しましたらPo stg reSQ Lを起動します。

起動時にB DRのバックグランドワーカの登録メッセージが出力される事を確認します。

$ pg_ctl start

サーバは起動中です。

-bash-4.2$ < 2016-10-19 01:47:01.891 JST >LOG: バックグラウンドワーカ"bdr supervisor"を登録しています

< 2016-10-19 01:47:02.041 JST >LOG: ログ出力をログ収集プロセスにリダイレクトしています

< 2016-10-19 01:47:02.041 JST >ヒント: ここからのログ出力はディレクトリ"pg_log"に現れます。

以下のコマンドでPo stg reSQ Lの起動状況を確認します。

$ pg_ctl status

pg_ctl: サーバが動作中です(PID: 10948)

/usr/pgsql-9.4/bin/postgres

11. データベース作成

PostgreSQL Enterprise Consortium

Page 238 of 285

B D R の動作確認用のデータベースを作成します。

$ createdb bdrtest

以下のコマンドで作成したデータベースへの接続を確認します。

$ psql bdrtest

psql (9.4.9)

"help" でヘルプを表示します.

bdrtest=# \q

-bash-4.2$

12. B D R モジュール登録

B D R に必要な拡張モジュールを登録します。

$ psql -U postgres bdrtest

=# CREATE EXTENSION btree_gist;

=# CREATE EXTENSION bdr;

以下のコマンドでインストール済みの拡張モジュールを確認します。

=# \dx

インストール済みの拡張の一覧

名前 | バージョン | スキーマ | 説明

------------+------------+------------+-----------------------------------------------

bdr | 1.0.1.0 | pg_catalog | Bi-directional replication for PostgreSQL

btree_gist | 1.0 | public | support for indexing common datatypes in GiST

plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language

(3 行)

13. B D R グループ作成

n od e1でBD R グループを作成するため、「bd r.b d r_gro u p_create」関数を実行します。

$ psql -U postgres bdrtest

=# SELECT bdr.bdr_group_create(

local_node_name := 'node1',

node_external_dsn := 'host=node1 port=5432 dbname=bdrtest');

グループが作成されたことを確認するため、「bd r.bdr_n od e_join_w a it_fo r_ready」関数を実行します。

=# SELECT bdr.bdr_node_join_wait_for_ready();

bdr_node_join_wait_for_ready

------------------------------

(1 行)

14. ノード登録

n od e2でノード登録するために、「b d r.bd r_g rou p _join 」関数を実行します。

PostgreSQL Enterprise Consortium

Page 239 of 285

$ psql -U postgres bdrtest

=# SELECT bdr.bdr_group_join(

local_node_name := 'node2',

node_external_dsn := 'host=node2 port=5432 dbname=bdrtest',

join_using_dsn := 'host=node1 port=5432 dbname=bdrtest'

);

ノードが登録されたことを確認するため、「bd r.b d r_n od e_join _w ait_for_ready」関数を実行します。

=# SELECT bdr.bdr_node_join_wait_for_ready();

bdr_node_join_wait_for_ready

------------------------------

(1 行)

15. ノード状態の確認

ノードの状態を「b d r.bdr_n od es」テーブルの情報から確認します。

$ psql -U postgres bdrtest

=# \x

=# SELECT * FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_sysid | 6369044607312522907

node_timeline | 1

node_dboid | 16385

node_status | r

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_init_from_dsn |

node_read_only | f

-[ RECORD 2 ]------+------------------------------------

node_sysid | 6369045470046586386

node_timeline | 1

node_dboid | 16385

node_status | r

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest

node_read_only | f

16. 簡易動作検証(no de1)

n od e1でBD R の簡易動作検証を実施します。

n od e1で作成されたテーブルとデータがn od e2にレプリケーションされていることを確認します。

$ psql -U postgres bdrtest

=# CREATE TABLE t1bdr (c1 INT, PRIMARY KEY (c1));

=# INSERT INTO t1bdr VALUES (1);

=# INSERT INTO t1bdr VALUES (2);

17. 簡易動作検証(no de2)

n od e2でBD R の簡易動作検証の結果を確認します。

n od e1と同じテーブルとデータが表示できていれば、構築したBDR 環境に問題はありません。

n od e1と同様の簡易動作検証をn od e2からも実施して下さい。

PostgreSQL Enterprise Consortium

Page 240 of 285

$ psql -U postgres bdrtest

=# SELECT * FROM t1bdr;

----

(2 行)

=# INSERT INTO t1bdr VALUES (3);

7.5. BDR動作検証

7.5.1. ノードの追加・切り離しノードの追加・切り離し

7.5.1.1. 検証の目的検証の目的

ノードの追加/切り離しをオンライン(DB 停止)なしで実行できるか否かを確認します。

7.5.1.2. 検証内容検証内容

本検証では、2台で構成されたB D Rクラスタに対して、下記を実施しました。

1. ノード切り離し

2. ノード追加

「ノード切り離し」および「ノード追加」時に他ノード(上図のn o d e1)にトランザクションを実行し、トランザクションにエラーが発生するか否かを確認しました。

7.5.1.3. 検証環境検証環境

こちらの環境で検証を実施しました。

7.5.1.4. 検証手順検証手順

7.5.1.4.1. ノード切り離しノード切り離し

1. B D R の各ノード状態確認

B D R の各ノード間のレプリケーションが正常に動作していることを「b d r.bdr_n o d es」テーブルを用いて確認します。

PostgreSQL Enterprise Consortium

Page 241 of 285

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest <-- node1から作成されていることを確認

2. 検証用テーブルとデータの作成

pg b ebch を利用して、検証時に利用するテーブルとデータを作成します。

(node1にて実施)

$ pgbench -i -s 10 bdrtest

3. トランザクション実行

pg b ench を利用して、ノード1にトランザクションを継続的に実行します。ノード2を切り離した発生した場合に、ノード1に対して実行したトランザクショ

ンにエラーが発生するか否かを確認します。

$ pgbench -h node1 -c 10 -t 100000 bdrtest

starting vacuum...end.

4. ノード切り離し

ノード2を切り離しするため、「bd r.b d r_part_b y_n o d e_n ames」関数を実行します。

(node1のデータベースに接続)

=# SELECT bdr.bdr_part_by_node_names(ARRAY['node2']);

bdr_part_by_node_names

------------------------

(1 row)

5. ノードの切り離し結果確認

ノードの切り離し結果を「bd r.b d r_n o d es」テーブルを用いて確認します。

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | k <-- k(削除)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest

6. システムカタログの残データ削除

PostgreSQL Enterprise Consortium

Page 242 of 285

本手順は推奨される手順ではありませんが、削除状態のノードが「b dr.bd r_n o des」テーブルに残っていると削除したノードの追加が実行できないため

暫定的な対処です。 B D RのIssu esで「bdr.bd r_co n n ectio n s」のデータも削除する事が提案されていたので、こちらも暫定的な手順ですが実行しま

す。詳細は下記をご参照下さい。

h ttps://githu b .com/2n d Q u ad ran t/bd r/issu es/97

h ttps://githu b .com/2n d Q u ad ran t/bd r/issu es/126

(node1のデータベースに接続)

=# DELETE FROM bdr.bdr_connections USING bdr.bdr_nodes WHERE node_status = 'k' AND

(node_sysid, node_timeline, node_dboid) = (conn_sysid, conn_timeline, conn_dboid);

=# DELETE FROM bdr.bdr_nodes where node_status = 'k';

7. ノードの切り離し結果確認

ノードの切り離し結果を「bd r.b d r_n o d es」テーブルを用いて確認します。

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r

node_init_from_dsn |

8. B D R の無効化

ノード2のデータベースから「bdr.remove_b d r_from_lo cal_n o d e」関数を用いてB D R を削除し、B DR拡張機能を削除します。

(node2のデータベースに接続)

=# SELECT bdr.remove_bdr_from_local_node(true);

WARNING: forcing deletion of possibly active BDR node

NOTICE: removing BDR from node

NOTICE: BDR removed from this node. You can now DROP EXTENSION bdr and,

if this is the last BDR node on this PostgreSQL instance, remove bdr from

shared_preload_libraries.

remove_bdr_from_local_node

----------------------------

=# DROP EXTENSION bdr;

DROP EXTENSION

9. トランザクション状態実行状態確認

手順1で実行したp g ben ch にエラーが発生してないことを確認します。本検証ではエラーは発生しませんでした。

7.5.1.4.2. ノード追加ノード追加

切り離したBDRノードを再度追加する場合、既存ノードのデータベースと追加するノードのデータベースのスキーマおよびデータを同期させる必要があります。ノード間のデー

タコピーには、論理コピーと物理コピーの2つの手法があります。

h ttp://b dr-pro ject.o rg/d o cs/stable/fu n ction s-n od e-mg mt.h tml#FU NCTIO N-BD R -GRO U P-JO IN

表 7.6 コピー取得方法

項番項番コピー取得コピー取得説明説明備考備考

1 bd r.b d r_gro u p_jo in 関

数実行

ユーザが指定したノード内データベースのスキーマとデータダンプを取得 pg _d u mpコマンドに相当

2 bd r_init_co pyコマンドユーザが指定したノード上の全てのデータベースのコピーを取得 pg _b aseb acku pコマンド

に相当

■論理コピーによるノード追加

PostgreSQL Enterprise Consortium

Page 243 of 285

1. トランザクション実行

pg b ench を利用して、ノード1にトランザクションを継続的に実行します。ノード2に復旧する際に、ノード1に対して実行したトランザクションの停止が必

要か否かを確認します。

$ pgbench -h node1 -c 10 -t 100000 bdrtest

starting vacuum...end.

2. ノード2のPostgreSQ L起動

ノード2上で動作するPo stg reSQ Lを起動させます。

$ pg_ctl start

3. データベース削除

B D R で利用したデータベースを削除します。

(node2のデータベースに接続)

=# DROP DATABASE bdrtest ; ※ 接続が残っており、削除できない場合はPostgreSQLを再起動

DROP DATABASE

4. データベースの再作成

B D R で利用するデータべースを再度作成します。

(node2のデータベースに接続)

=# CREATE DATABASE bdrtest;

5. B D R 有効化

無効化したB D R を再度有効化します。

(node2のデータベースに接続)

=# CREATE EXTENSION btree_gist;

CREATE EXTENSION

=# CREATE EXTENSION bdr;

CREATE EXTENSION

6. ノードの追加

ノードを追加(復旧)させるため、「bdr.bd r_gro u p _join」関数を実行します。

(node2のデータベースに接続)

=# SELECT bdr.bdr_group_join(

local_node_name := 'node2',

node_external_dsn := 'host=node2 port=5432 dbname=bdrtest',

join_using_dsn := 'host=node1 port=5432 dbname=bdrtest'

);

bdr_group_join

----------------

(1 行)

PostgreSQL Enterprise Consortium

Page 244 of 285

7. ノード追加の確認待ち

ノードが追加されたことを確認するため、「bd r.b d r_n od e_join _w ait_for_ready」関数を実行します。

(node2のデータベースに接続)

=# SELECT bdr.bdr_node_join_wait_for_ready();

※ トランザクションが実行中の場合、上記関数の結果が戻りません。

n od e1のPostgreSQ Lログファイルに下記メッセージが出力された後、復旧の処理が開始されません。

(node1のログメッセージ抜粋)

LOG: logical decoding found initial starting point at 0/BB399BF0

DETAIL: 10 transactions need to finish.

pg b ench コマンドで実行中のトランザクションを停止すると、下記ログメッセージが出力され、復旧処理が開始されます。

(node1のログメッセージ抜粋)

LOG: logical decoding found consistent point at 0/B2895648

DETAIL: There are no running transactions.

LOG: exported logical decoding snapshot: "00046FE0-1" with 0 transaction IDs

8. B D R の各ノード状態確認

ノード2が追加されたことを「bdr.bd r_n o des」テーブルの情報から確認します。

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest <-- node1から作

成されていることを確認

■ 物理コピーによるノード追加

1. トランザクション実行

pg b ench を利用して、ノード1にトランザクションを継続的に実行します。ノード2に追加する際に、ノード1に対して実行したトランザクションの停止が必

要か否かを確認します。

$ pgbench -h node1 -c 10 -t 100000 bdrtest

starting vacuum...end.

2. ノード2のPostgreSQ L停止確認

ノード2上で動作するPo stg reSQ Lが停止していることを確認します。

PostgreSQL Enterprise Consortium

Page 245 of 285

(node2にて実施)

$ pg_ctl status

pg_ctl: no server running

3. 物理コピーの取得

ノード2上で「bd r_in it_co p y」コマンドを実行し、ノード1上のコピーを取得します。

(node2にて実施)

$ rm -rf $PGDATA/*

$ bdr_init_copy -D $PGDATA -n node2 -h node1 -p 5432 -d bdrtest

--local-host=node2 --local-port=5432 --local-dbname=bdrtest

bdr_init_copy: starting ...

Getting remote server identification ...

Detected 1 BDR database(s) on remote server

Updating BDR configuration on the remote node:

bdrtest: creating replication slot ...

bdrtest: creating node entry for local node ...

Creating base backup of the remote node...

50357/50357 kB (100%), 1/1 tablespace

Creating restore point on remote node ...

Bringing local node to the restore point ...

トランザクションログをリセットします。

Initializing BDR on the local node:

bdrtest: adding the database to BDR cluster ...

All done

n od e1のPostgreSQ Lログファイルに下記メッセージが出力された後、追加の処理が開始されません。

(node1のログメッセージ抜粋）

LOG: logical decoding found initial starting point at 0/BB399BF0

DETAIL: 10 transactions need to finish.

pg b ench コマンドで実行中のトランザクションを停止すると、下記ログメッセージが出力され、復旧処理が開始されます。

(node1のログメッセージ抜粋

LOG: logical decoding found consistent point at 0/B2895648

DETAIL: There are no running transactions.

STATEMENT: SELECT

pg_create_logical_replication_slot('bdr_25434_6369931070716042622_2_25434__', 'bdr');

4. B D R の各ノード状態確認

ノード2が追加されたことを「bdr.bd r_n o des」テーブルの情報から確認します。

PostgreSQL Enterprise Consortium

Page 246 of 285

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest <-- node1から作

成されていることを確認

7.5.1.5. 検証結果検証結果

切り離したノードの情報がシステムカタログに残ってしまうため、データ操作が禁止されているシステムカタログのデータ削除が必要でした。

システムカタログのデータ操作は禁止されていますが、切り離したノードの情報がシステムカタログに残っている場合、ノード追加時に下記のメッセージが出力され、ノードが

追加が実施できないため、本検証では暫定対処としてシステムカタログのデータ削除を実施しております。

ERROR: System identification mismatch between connection and slot

詳細: Connection for bdr (6369029438929838565,1,16385,) resulted in slot on node bdr

(6369034270871134883,2,16385,) instead of expected node

LOG: ワーカプロセス: bdr db: bdrtest (PID 17232)は終了コード1で終了しました

ノード追加にはプロセスの再起動は必要ありませんが、トランザクションの停止が必要でした。

7.5.2. グローバルシーケンス設定グローバルシーケンス設定

7.5.2.1. 検証の目的検証の目的

B D R に実装されたグローバルシーケンスの利用方法について確認します。グルーバルシーケンスを利用することでノード毎に払い出されるシーケンス番号を独立させ、ノード

間のシーケンス番号の競合を防ぐことができるか否かを確認します。

7.5.2.2. 検証環境検証環境

こちらの環境で検証を実施しました。

7.5.2.3. 検証手順検証手順

1. 初期状態

B D R の各ノード間のレプリケーションが正常に動作していることを「b d r.bdr_n o d es」テーブルを用いて確認します。

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest <-- node1から作成されていることを確認

2. グローバルシーケンス動作確認

n od e1のデータベースに接続し、serial型を列に持つg stestテーブルを作成します。 serial型を持つテーブルを作成すると、自動的にシーケンスが作成

PostgreSQL Enterprise Consortium

Page 247 of 285

されます。グローバルシーケンス作成のため、テーブル作成時に「SE T LO CAL defa u lt_sequ enceam = 'b dr';」を指定する必要があります。

(node1のデータベースに接続)

BEGIN;

SET LOCAL default_sequenceam = 'bdr'; <-- グローバルシーケンス作成用の設定

CREATE TABLE gstest (

id serial primary key,

hogehoge text

);

COMMIT;

参考. 上記DDL実行時にnode1に出力されるログメッセージ

LOG: DDL LOCK TRACE: attempting to acquire in mode <ddl_lock> for (bdr (xxxxxxxx))

--------

STATEMENT: CREATE TABLE gstest (

id serial primary key,

hogehoge text

);

LOG: DDL LOCK TRACE: attempting to acquire in mode <write_lock> (upgrading from

<ddl_lock>) for (bdr (xxxxxxxxx,))

>STATEMENT: CREATE TABLE gstest (

id serial primary key,

hogehoge text

);

--------

3. グルーバルシーケンス作成確認

n od e1およびn o d e2のデータベースに接続し、グローバルシーケンスが作成されたことを確認します。

(node1のデータベースに接続)

=# \ds

List of relations

-[ RECORD 1 ]---------

Schema | public

Name | gstest_id_seq

Type | sequence

Owner | postgres

(node2のデータベースに接続)

=# \ds

List of relations

-[ RECORD 1 ]---------

Schema | public

Name | gstest_id_seq

Type | sequence

Owner | postgres

※ 下記のSQ Lで詳細情報(pg _classの情報)を確認可能です。

=# SELECT * FROM pg_class

INNER JOIN pg_seqam ON (pg_class.relam = pg_seqam.oid)

WHERE pg_seqam.seqamname = 'bdr' AND relkind = 'S';

4. グローバルシーケンス利用

n od e1のデータベースに接続し、1件のデータを投入します。

(node1のデータベースに接続)

=# INSERT INTO gstest(hogehoge) VALUES ('test1');

INSERT 0 1

n od e2のデータベースに接続し、1件のデータを投入します。

PostgreSQL Enterprise Consortium

Page 248 of 285

(node2のデータベースに接続)

=# INSERT INTO gstest(hogehoge) VALUES ('test2');

INSERT 0 1

5. シーケンス値の競合有無確認

n od e1およびn o d e2のシーケンスの値に競合が発生していないことを確認します。本検証では、n o d e1に2が割り当てられ、n o d e2には100001が割

り当てられました。

(node1のデータベースに接続)

=# SELECT * FROM gstest;

id | hogehoge

--------+----------

2 | test1 <-- node1には2のシーケンスが割り当てられる

100001 | test2 <-- node2には100001のシーケンスが割り当てられる

(2 rows)

6. グローバルシーケンス利用

n od e1に200,000件のデータを投入し、シーケンスの値が100,000を超えた場合、n o d e2の100,001と競合しないか否かを確認しました。

(node1において実施)

$ cat /tmp/gs.sh

#!/bin/sh

for i in `seq 1 200000`

psql -d bdrtest -c "INSERT into gstest(hogehoge) VALUES ('test${i}');"

done

$ sh /tmp/gs.sh

INSERT 0 1

[省略]

7. グローバルの状態確認

n od e1のシーケンスが100,000を利用したのち、n o de1に割り振られた値を確認しました。

(node1のデータベースに接続)

=# SELECT * FROM gstest WHERE 99999 <= id;

id | hogehoge

--------+------------

99999 | test99997

100000 | test99998

100001 | test2

150001 | test99999 -< 100,000を超えると、node1のシーケンスが150,001に割り振られる。

150002 | test100000

150003 | test100001

150004 | test100002

150005 | test100003

150006 | test100004

7.5.2.4. 検証結果検証結果

グローバルシーケンスを用いることでノード間のシーケンス番号の競合を抑止できることが確認できました。グルーバルシーケンスについてはいくつかの制限事項がマニュアルに

記載されておりますので、注意して下さい。

1. 1（デフォルト値）のINCREM ENTだけがサポートされています。

PostgreSQL Enterprise Consortium

Page 249 of 285

2. MINVALU EとM AXVALU E はデフォルトでロックされており、変更することはできません。

3. CACHE指令はサポートされていません。

h ttp://b dr-pro ject.o rg/d o cs/1.0/glo bal-sequ en ce-limitation s.h tml

7.5.3. 選択的レプリケーション選択的レプリケーション

選択的レプリケーションについて記載します。

7.5.3.1. 検証目的検証目的

テーブル単位での選択的レプリケーションの可否を確認します。選択的レプリケーションの可否は互いのデータベース間での任意のテーブルのデータ状態を元に判断します。

また、選択的レプリケーションを実現する際の変更手順を明確にする事を目的とします。

7.5.3.2. 検証内容検証内容

Replication Set : レプリケーション対象とするテーブルの論理集合を表し、ノード毎に設定可能

h ttp://b dr-pro ject.o rg/d o cs/stable/replication -sets.h tml

選択的レプリケーション検証内容

双方向レプリケーションの動作確認

選択的レプリケーション(no d e1)の動作確認

選択的レプリケーション(no d e2)の動作確認

7.5.3.3. 検証環境検証環境

こちらの環境で検証を実施しました。

7.5.3.4. 検証手順検証手順

1. 選択的レプリケーション環境構築

選択的レプリケーションの動作確認の為に、下記の検証環境を構築します。

(1)データベース作成

テストを実施する為のデータベースを作成します。

(node1,node2において実施)

=# CREATE DATABASE rep_test;

(2)BDRの有効化

作成したデータベース上でB D R 機能の有効化を実施します。

(node1,node2のデータベースにおいて実施)

=# CREATE EXTENSION btree_gist;

=# CREATE EXTENSION bdr;

PostgreSQL Enterprise Consortium

Page 250 of 285

(3)BDRグループの作成

B D R ノードのクラスタに「bd r.b d r_gro u p_create」を利用して最初のノードを作成します。

(node1のデータベースに接続)

=# SELECT bdr.bdr_group_create(

local_node_name := 'node1',

node_external_dsn := 'host=node1 port=5432 dbname=rep_test',

replication_sets:= ARRAY['default','node1']); ※ replications_ret

にnode1を追加

(4)ノード登録(n od e2)

既存のB D R ノードのクラスタに「b dr.bd r_gro u p _join」を利用してノードを登録します。これにより、全てのノード間でレプリケーションが開始されます。

(node2のデータベースに接続)

=# SELECT bdr.bdr_group_join(

local_node_name := 'node2',

node_external_dsn := 'host=node2 port=5432 dbname=rep_test',

join_using_dsn := 'host=node1 port=5432 dbname=rep_test',

replication_sets:= ARRAY['default','node2']); ※ replications_ret

にnode2を追加

(5)ノードの状態確認

B D R グループ内のノードのメンバシップを「b d r.bd r_n o d es」を利用して確認します。

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+-------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=rep_test

node_status | r <-- r(正常)であることを確認

node_init_from_dsn |

-[ RECORD 2 ]------+-------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=rep_test

node_status | r <-- r(正常)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=rep_test <-- node1から作成されていることを確

認

(6)レプリケーションセットの確認

指定したノードのレプリケーションセットを「b d r.con n ection _get_replication _sets」を利用して確認します。

(node1のデータベースに接続)

=# SELECT bdr.connection_get_replication_sets('node1');

-[ RECORD 1 ]-------------------+----------------

connection_get_replication_sets | {default,node1} <-- node1が追加されていること

=# SELECT bdr.connection_get_replication_sets('node2');

-[ RECORD 1 ]-------------------+----------------

connection_get_replication_sets | {default,node2} <-- node2が追加されていること

2. 双方向レプリケーション対象テーブルの動作確認

まずは、通常の双方向レプリケーション動作を確認します。片方のテーブルにデータを挿入した時にもう一方のテーブルにもデータが挿入されています。

(1)テーブル(all_rep )作成

PostgreSQL Enterprise Consortium

Page 251 of 285

テストを実施する為のテーブル(all_rep)を作成します。

(node1のデータベースに接続)

=# CREATE TABLE all_rep(id int, PRIMARY KEY(id));

CREATE TABLE

(2)レプリケーションセット確認

指定したテーブルのレプリケーションセットを「b d r.co n n ection _get_replication _sets」を利用して確認します。

(node1のデータベースに接続)

=# SELECT bdr.table_get_replication_sets('all_rep');

-[ RECORD 1 ]--------------+--------------

table_get_replication_sets | {default,all} <-- defaultが含まれていること

(3)データ追加

n od e1のテーブルにデータを挿入します。

(node1のデータベースに接続)

=# INSERT INTO all_rep VALUES (1);

INSERT 0 1

(4)レプリケーション確認

n od e2のテーブルにもデータがレプリケーションされている事を確認します。

(node2のデータベースに接続)

=# SELECT id FROM all_rep;

----

1 <-- データがレプリケーションされていること

(1 row)

3. レプリケーション対象外テーブルの作成(n o de1のみ)

次に、選択的レプリケーション動作を確認します。指定したテーブルではレプリケーション動作が行われなくなりますので、任意のテーブルのみレプリケーショ

ンさせる事が出来ます。

(1)テーブル(n o de1_on ly)の作成

テストを実施する為のテーブル(n o d e1_on ly)を作成します。

(node1のデータベースに接続)

=# CREATE TABLE node1_only(id int, PRIMARY KEY(id));

CREATE TABLE

(2)レプリケーションセット変更

指定したテーブルのレプリケーションセットを「b d r.tab le_set_replication _sets」を利用して'no de1'に設定し、レプリケーション対象を'nod e1'のみに

します。設定したレプリケーションセットを確認するには、「b d r.table_get_rep lication _sets」を利用します。

PostgreSQL Enterprise Consortium

Page 252 of 285

(node1のデータベースに接続)

=# SELECT bdr.table_set_replication_sets('node1_only', ARRAY['node1']);

-[ RECORD 1 ]--------------+-

table_set_replication_sets |

=# SELECT bdr.table_get_replication_sets('node1_only');

-[ RECORD 1 ]--------------+------------

table_get_replication_sets | {node1,all} <-- node1が追加されていること

(3)データ追加

n od e1のテーブルにデータを挿入します。

(node1のデータベースに接続)

=# INSERT INTO node1_only VALUES (1);

INSERT 0 1

(4)レプリケーション確認

n od e2のテーブルにはデータがレプリケーションされていない事を確認します。

(node2のデータベースに接続)

=# SELECT id FROM node1_only;

---- <-- レプリケーションされていないこと

(0 行)

4. レプリケーション対象外テーブルの作成(n o de2のみ)

同様に、もう一方からの選択的レプリケーション動作も確認します。

(1)テーブル(n o de2_on ly)の作成

テストを実施する為のテーブル(n o d e2_on ly)を作成します。

(node2のデータベースに接続)

=# CREATE TABLE node2_only(id int, PRIMARY KEY(id));

CREATE TABLE

(2)レプリケーションセット変更

指定したテーブルのレプリケーションセットを「b d r.tab le_set_replication _sets」を利用して'no de2'に設定し、レプリケーション対象を'nod e2'のみに

します。設定したレプリケーションセットを確認するには、「b d r.table_get_rep lication _sets」を利用します。

(node2のデータベースに接続)

=# SELECT bdr.table_set_replication_sets('node2_only', ARRAY['node2']);

-[ RECORD 1 ]--------------+-

table_set_replication_sets |

=# SELECT bdr.table_get_replication_sets('node2_only');

-[ RECORD 1 ]--------------+------------

table_get_replication_sets | {node2,all} <-- node2が追加されていること

(3)データ追加

n od e2のテーブルにデータを挿入します。

PostgreSQL Enterprise Consortium

Page 253 of 285

(node2のデータベースに接続)

=# INSERT INTO node2_only VALUES (1);

INSERT 0 1

(4)レプリケーション確認

n od e1のテーブルにはデータがレプリケーションされていない事を確認します。

(node1のデータベースに接続)

=# SELECT id FROM node2_only;

---- <-- レプリケーションされていないこと

(0 行)

7.5.3.5. 検証結果検証結果

今回の検証結果では、レプリケーションセットに任意のノードを指定する事で選択的レプリケーションが実現される事が確認出来ました。また、選択的レプリケーション実現

の為の設定変更手順についても確認出来ました。

ただし、レプリケーションセットにテーブルを追加する場合は、過去のデータまで反映しないので、手動で同期が必要です。

選択的レプリケーションの主な注意事項は下記になります。

h ttp://b dr-pro ject.o rg/d o cs/1.0/replica tion -sets-con cepts.h tml

h ttp://b dr-pro ject.o rg/d o cs/1.0/replica tion -sets-tables.h tml

1. DDLはレプリケーションセットの設定に関係なく常にすべてのノードに影響します。

2. TRUNCATEは常にレプリケートされます。望ましくない場合は、DELETEを利用する必要があります。

3. レプリケーションセットの設定は、初期ノード追加(結合時)にはテーブルデータのコピーに影響を与えません。

4. レプリケーションセットにテーブルを追加した場合も以前のデータ内容はノードに同期されません。通常、管理者は、テーブルをレプリケーションセットに追加した後、

手動で同期する必要があります。

7.5.4. 更新処理競合時の動作更新処理競合時の動作

7.5.4.1. 検証目的検証目的

B D R はマルチマスタ構成する各ノードに対して、参照処理と更新処理を実行することが可能です。複数ノードに対して同時に更新処理が実施された場合、各ノードに対

して実行された更新処理が競合する事象が発生する場合があります。

B D R 競合が発生した場合、最後の更新処理が適用されます(last_u p date_w ins)。また、競合結果はテーブル「b d r.bdr_co n flict_histo ry」で確認可能です。

「bd r.b d r_con flict_h istory」に格納される情報については下記をご参照下さい。

h ttp://b dr-pro ject.o rg/d o cs/stable/co n flicts-typ es.h tml

下記を明らかにするため検証を実施しました。

1. 更新処理が競合した場合の挙動

2. 競合発生時にシステムカタログに記録される情報

7.5.4.2. 検証内容検証内容

B D R 動作検証概要図

PostgreSQL Enterprise Consortium

Page 254 of 285

下表の競合発生時の動作を検証しました。

表 7.7 検証した競合のパターン

項番項番分類分類説明説明

1 PRIMARY KEYまたはUNIQ UE制約 2つの操作が同じU NIQ U E KEYを持つ行に影響を及ぼす

行の競合を検証します。

2 外部キー制約外部キー制約が定義されたテーブルにおいて、

制約に違反するデータ削除によって引き起こされる競合を検証します。

3 排他制約 B D R では排他制約をサポートしていないために、

排他制約において競合が発生した場合を検証します。

4 グローバルなデータノードのグローバル(PostgreSQ Lシステム全体)の

データ(ロールなど)が異なる場合での競合を検証します。

5 ロックの競合とデッドロックの中断 BDR適用プロセスとロックの競合について検証します。

6 その他自動的に解決出来ないデータの相違が発生した場合に

手動で調整を行う方法を検証します。

7.5.4.3. 検証環境検証環境

こちらの環境で検証を実施しました。

7.5.4.4. 検証手順検証手順

1. 競合ログオプションの有効化確認

競合発生時にテーブル「bd r.b d r_con flict_h isto ry」に情報を記録するため、bdr.log _co n flicts_to _tableパラメータがo n に設定されていることを

確認します。

※ offになっていたら、p o stgresql.co n fに「b d r.lo g_con flicts_to _ta b le=o n 」を追記し、再読み込みを実行して下さい。

n od e1/n od e2のデータベースに接続し、パラメータを確認するために下記コマンドを実行します。

(node1にて実施)

=# SHOW bdr.log_conflicts_to_table;

bdr.log_conflicts_to_table

----------------------------

(1 行)

(node2にて実施)

=# SHOW bdr.log_conflicts_to_table;

bdr.log_conflicts_to_table

----------------------------

(1 行)

2. レプリケーション反映時間の設定

ネットワーク遅延などの実際の環境を想定して検証を行うため、bdr.defau lt_apply_delayパラメータを設定します。このパラメータを設定する事でレ

プリケーションの反映を設定した時間(ミリ秒)遅らせる事が出来ます。

※ 今回の検証では、競合の発生を確認しやすくするために"2s"を設定しています。

n od e1/n od e2のデータベースに接続し、パラメータを確認するために下記コマンドを実行します。

(node1にて実施)

=# SHOW bdr.default_apply_delay;

bdr.default_apply_delay

----------------------------

(1 行)

(node2にて実施)

=# SHOW bdr.default_apply_delay;

bdr.default_apply_delay

----------------------------

(1 行)

3. B D R の各ノード状態確認

B D R の各ノード間のレプリケーションが正常に動作していることを「b d r.bdr_n o d es」を利用して確認します。

PostgreSQL Enterprise Consortium

Page 255 of 285

(node1にて実施)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest <-- node1から作成されていることを確認

4. 検証用テーブルとデータの作成

pg b ebch を利用して、検証時に利用するテーブルとデータを作成します。

(node1にて実施)

$ pgbench -i -s 10 bdrtest

$ psql -h node1 -d bdrtest

=# INSERT INTO pgbench_accounts (aid, bid, abalance) VALUES (1000001, 1, 0);

7.5.4.4.1. PRIMARY KEYまたはまたは UNIQUE制約制約

1. INSERT vs INSERT

■ 競合概要

最も一般的な競合として、2つの異なるノードのINSERTが同じPRIMAR Y KEYの値(または、単一のUNIQ E制約の値)を持つデータを挿入するケースを

検証しました。

■ 検証結果

タイムスタンプに従い、最後にデータが作成された方が保持されました。

■ 競合発生手順

各ノードからそれぞれINSER Tを実行し、INSERT vs INSERT の競合を発生させます。

(node1のデータベースへSQLを投入)

=# INSERT INTO pgbench_accounts (aid, bid, abalance) VALUES (1000002, 2, 0);

(node2のデータベースへSQLを投入)

=# INSERT INTO pgbench_accounts (aid, bid, abalance) VALUES (1000002, 3, 0);

競合ログを「b dr.bd r_co n flict_h isto ry」を利用して確認し、競合の発生を確認します。

※ 競合履歴テーブルでは競合ログが出力されている側のサーバをローカル、反対側をリモートとして表示します。よって、それぞれのサーバで実行された

トランザクションをローカルトランザクション、リモートトランザクションとして説明します。

PostgreSQL Enterprise Consortium

Page 256 of 285

(node1またはnode2の競合履歴テーブルに競合ログが出力)

=# \x

=# SELECT * FROM bdr.bdr_conflict_history ORDER BY conflict_id DESC LIMIT 1;

-[ RECORD 1 ]------------+---------------------------------------------------

conflict_id | 48

local_node_sysid | 6371561413984311673

local_conflict_xid | 3944663

local_conflict_lsn | 3/765949B8

local_conflict_time | 2017-01-25 10:36:03.787698+09

object_schema | public

object_name | pgbench_accounts

remote_node_sysid | 6371553825031594764

remote_txid | 3960113

remote_commit_time | 2017-01-25 10:32:48.772254+09

remote_commit_lsn | 2/CA1AD950

conflict_type | insert_insert

conflict_resolution | last_update_wins_keep_local

local_tuple | {"aid":1000002,"bid":3,"abalance":0,"filler":null}

remote_tuple | {"aid":1000002,"bid":2,"abalance":0,"filler":null}

local_tuple_xmin | 3944662

local_tuple_origin_sysid |

error_message |

error_sqlstate |

error_querystring |

error_cursorpos |

error_detail |

error_hint |

error_context |

error_columnname |

error_typename |

error_constraintname |

error_filename |

error_lineno |

error_funcname |

それぞれのテーブルの状態を確認し、競合発生時の処理を確認します。

※ 後にデータが作成されたローカルトランザクションが保持されています。

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

--------+-----+----------+--------

1000001 | 1 | 0 |

1000002 | 3 | 0 |

(2 行)

(node2のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

--------+-----+----------+--------

1000001 | 1 | 0 |

1000002 | 3 | 0 |

(2 行)

※ last_update_wins_keep_local : 最新のタイムスタンプであるローカル側の更新が適用

2. INSERT vs U PDATE

■ 競合概要

一つのノードでINSERTしたデータともう片方のノードでU PDATEしたデータが同じPRIMAR Y KEYの値を持つケースを検証しました。

PostgreSQL Enterprise Consortium

Page 257 of 285

■ 検証結果

INSERT/UPD ATEの競合が発生した場合、競合を解消するためオペレータ側でのデータ操作が必要となり、注意が必要です。

■ 競合発生手順

下記テーブルを初期状態とします。

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

--------+-----+----------+--------

1000001 | 1 | 0 |

(1 行)

(node2のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

--------+-----+----------+--------

1000001 | 1 | 0 |

(1 行)

各ノードからそれぞれINSER T/UPDATEを実行し、INSERT vs UPDATE の競合を発生させます。

(node1のデータベースへSQLを投入)

=# INSERT INTO pgbench_accounts (aid, bid, abalance) VALUES (1000002, 4, 0);

(node2のデータベースへSQLを投入)

=# UPDATE pgbench_accounts SET aid = 1000002 WHERE aid = 1000001;

競合ログを「b dr.bd r_co n flict_h isto ry」を利用して確認し、競合の発生を確認します。

PostgreSQL Enterprise Consortium

Page 258 of 285

(node1またはnode2の競合履歴テーブルに競合ログが出力)

=# \x

=# SELECT * FROM bdr.bdr_conflict_history ORDER BY conflict_id DESC LIMIT 1;

-[ RECORD 1 ]------------+---------------------------------------------------

conflict_id | 49

local_node_sysid | 6371561413984311673

local_conflict_xid | 3944715

local_conflict_lsn | 3/81295CF8

local_conflict_time | 2017-01-25 10:36:46.780822+09

object_schema | public

object_name | pgbench_accounts

remote_node_sysid | 6371553825031594764

remote_txid | 3960133

remote_commit_time | 2017-01-25 10:33:31.640126+09

remote_commit_lsn | 2/D1CE6F00

conflict_type | insert_insert

conflict_resolution | last_update_wins_keep_local

local_tuple | {"aid":1000002,"bid":1,"abalance":0,"filler":null}

remote_tuple | {"aid":1000002,"bid":4,"abalance":0,"filler":null}

local_tuple_xmin | 3944714

local_tuple_origin_sysid |

error_message |

error_sqlstate |

error_querystring |

error_cursorpos |

error_detail |

error_hint |

error_context |

error_columnname |

error_typename |

error_constraintname |

error_filename |

error_lineno |

error_funcname |

それぞれのテーブルの状態を確認し、競合発生時の処理を確認します。

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

1000002 | 4 | 0 |

(2 行)

(node2のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000002 | 1 | 0 |

(1 行)

PRIMARY KEYのU PDATEで発生した競合でリモート側では一意制約違反のために適用プロセスがデータ反映できず、ローカル側では論理レプリケー

ション中に接続が切断され、データの整合性がとれなくなる状態が確認されました。

PostgreSQL Enterprise Consortium

Page 259 of 285

(node1のデータベースログ)

LOG: starting background worker process "bdr (6371553825031594764,1,43905,)->bdr

(6371561413984311673,2,"

ERROR: duplicate key value violates unique constraint "pgbench_accounts_pkey"

DETAIL: Key (aid)=(1000002) already exists.

CONTEXT: apply UPDATE from remote relation public.pgbench_accounts in commit

1/2F279190, xid 3941360 commited at 2017-01-10 11:00:22.736985+09 (action #2) from node

(6371561413984311673,2,43865)

LOG: worker process: bdr (6371553825031594764,1,43905,)->bdr (6371561413984311673,2,

(PID 21287) exited with exit code 1

(node2のデータベースログ)

bdr (6371553825031594764,1,43905,):receive LOG: starting logical decoding for slot

"bdr_43865_6371553825031594764_1_43905__"

bdr (6371553825031594764,1,43905,):receive DETAIL: streaming transactions committing

after 1/2F279190, reading WAL from 1/2F279068

bdr (6371553825031594764,1,43905,):receive LOG: logical decoding found consistent point

at 1/2F279068

bdr (6371553825031594764,1,43905,):receive DETAIL: There are no running transactions.

bdr (6371553825031594764,1,43905,):receive LOG: could not receive data from client:

Connection reset by peer

bdr (6371553825031594764,1,43905,):receive LOG: unexpected EOF on standby connection

※ 競合するタプルをローカル側から手動で削除するか、新しいリモートタプルと競合しなくなるようにUPDATEする必要がある

上記状態では、ローカル側からのレプリケーションが実施されない状態が続くため、解消するために、ローカル側のデータをUPD ATEします。

(node1のデータベースへSQLを投入)

=# UPDATE pgbench_accounts SET aid = 1000003 WHERE aid = 1000002;

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

1000003 | 4 | 0 |

(2 行)

(node2のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000002 | 1 | 0 |

(1 行)

※ 競合は解消され、次のデータからレプリケーションが始まるがデータの整合性で問題あり

3. UPD ATE vs DELETE

■ 競合概要

一つのノードでU PDATEしたデータともう片方のノードでD ELETEしたデータが同じPRIM ARY KEYの値を持つケースを検証しました。

■ 検証結果

UPD ATE/DELETEが競合した場合、UPDATEが破棄されました。

■ 競合発生手順

下記テーブルを初期状態とします。

PostgreSQL Enterprise Consortium

Page 260 of 285

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

(1 行)

(node2のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

(1 行)

各ノードからそれぞれUPDATE/DELETEを実行し、U PDATE vs DELETE の競合を発生させます。

(node1のデータベースにSQLを投入)

=# UPDATE pgbench_accounts SET bid = 4 WHERE aid = 1000001;

(node2のデータベースにSQLを投入)

=# DELETE FROM pgbench_accounts WHERE aid = 1000001;

競合ログを「b dr.bd r_co n flict_h isto ry」を利用して確認し、競合の発生を確認します。

(node1またはnode2の競合履歴テーブルに競合ログが出力)

=# \x

=# SELECT * FROM bdr.bdr_conflict_history ORDER BY conflict_id DESC LIMIT 1;

-[ RECORD 1 ]------------+---------------------------------------------------

conflict_id | 51

local_node_sysid | 6371561413984311673

local_conflict_xid | 0

local_conflict_lsn | 3/8BF7BA38

local_conflict_time | 2017-01-25 10:37:45.561678+09

object_schema | public

object_name | pgbench_accounts

remote_node_sysid | 6371553825031594764

remote_txid | 3960157

remote_commit_time | 2017-01-25 10:34:30.564936+09

remote_commit_lsn | 2/D9831CC0

conflict_type | update_delete

conflict_resolution | skip_change

local_tuple |

remote_tuple | {"aid":1000001,"bid":4,"abalance":0,"filler":null}

local_tuple_xmin |

local_tuple_origin_sysid |

error_message |

error_sqlstate |

error_querystring |

error_cursorpos |

error_detail |

error_hint |

error_context |

error_columnname |

error_typename |

error_constraintname |

error_filename |

error_lineno |

error_funcname |

PostgreSQL Enterprise Consortium

Page 261 of 285

それぞれのテーブルの状態を確認し、競合発生時の処理を確認します。

※ DELETE後のUPD ATEが破棄されています。

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

-----+-----+----------+--------

(0 行)

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

-----+-----+----------+--------

(0 行)

※ skip_change : 変更を無視し、破棄された

4. INSERT vs DELETE

■ 競合概要

一つのノードでINSERTしたデータがもう片方のノードでDELETEされたデータと同じPRIMAR Y KEYの値を持つケースを検証しました。

■ 検証結果

DELETEの処理が破棄されました。競合発生の状態についてはシステムカタログから確認することができませんでした。

■ 競合発生手順

下記テーブルを初期状態とします。

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

(1 行)

(node2のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

(1 行)

各ノードからそれぞれINSER T/DELETEを実行し、INSERT vs DELE TE の競合を発生させます。

(node1のデータベースにSQLを投入)

=# INSERT INTO pgbench_accounts (aid, bid, abalance) VALUES (1000002, 5, 0);

(node2のデータベースにSQLを投入)

=# DELETE FROM pgbench_accounts WHERE aid = 1000002;

競合ログを「b dr.bd r_co n flict_h isto ry」を利用して確認し、競合の発生を確認します。

※ 競合は確認出来ませんでした。

PostgreSQL Enterprise Consortium

Page 262 of 285

(node1またはnode2の競合履歴テーブルに競合ログが出力されない)

=# \x

=# SELECT * FROM bdr.bdr_conflict_history ORDER BY conflict_id DESC LIMIT 1;

それぞれのテーブルの状態を確認します。

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

1000002 | 5 | 0 |

(2 行)

(node2のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

1000002 | 5 | 0 |

(2 行)

5. DELETE vs DELETE

■ 競合概要

2つの異なるノードで実行されたDELETEが同じPRIMAR Y KE Yの値を持つデータを削除するケースを検証しました。

■ 検証結果

DELETE/DELETEが競合した場合、片方のDELETEが無視され処理を完了しました。

■ 競合発生手順

下記テーブルを初期状態とします。

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

(1 行)

(node2のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

---------+-----+----------+--------

1000001 | 1 | 0 |

(1 行)

各ノードからそれぞれDELE TEを実行し、DELETE vs DELETE の競合を発生させます。

(node1のデータベースにSQLを投入)

=# DELETE FROM pgbench_accounts WHERE aid = 1000001;

(node2のデータベースにSQLを投入)

=# DELETE FROM pgbench_accounts WHERE aid = 1000001;

競合ログを「b dr.bd r_co n flict_h isto ry」を利用して確認し、競合の発生を確認します。

PostgreSQL Enterprise Consortium

Page 263 of 285

(node1またはnode2の競合履歴テーブルに競合ログが出力)

=# \x

=# SELECT * FROM bdr.bdr_conflict_history ORDER BY conflict_id DESC LIMIT 1;

-[ RECORD 1 ]------------+---------------------------------------------------------

conflict_id | 52

local_node_sysid | 6371561413984311673

local_conflict_xid | 0

local_conflict_lsn | 3/A193CA88

local_conflict_time | 2017-01-25 10:39:07.794699+09

object_schema | public

object_name | pgbench_accounts

remote_node_sysid | 6371553825031594764

remote_txid | 3960197

remote_commit_time | 2017-01-25 10:35:52.78243+09

remote_commit_lsn | 2/E8E9A388

conflict_type | delete_delete

conflict_resolution | skip_change

local_tuple |

remote_tuple | {"aid":1000001,"bid":null,"abalance":null,"filler":null}

local_tuple_xmin |

local_tuple_origin_sysid |

error_message |

error_sqlstate |

error_querystring |

error_cursorpos |

error_detail |

error_hint |

error_context |

error_columnname |

error_typename |

error_constraintname |

error_filename |

error_lineno |

error_funcname |

それぞれのテーブルの状態を確認し、競合発生時の処理を確認します。

※ ローカル側のノードからのD ELETEが無視されています。

(node1のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

-----+-----+----------+--------

(0 行)

(node2のデータベースを確認)

=# SELECT * FROM pgbench_accounts WHERE aid >= 1000001;

aid | bid | abalance | filler

-----+-----+----------+--------

(0 行)

※ skip_change : 変更を無視し、破棄された

7.5.4.4.2. 外部キー制約外部キー制約

1. 外部キー制約の競合

■ 競合概要

1つのノードで外部キー制約が定義されたテーブルに対してデータを挿入し、上記データ挿入がもう片方のノードに反映される前に、もう片方のノードに

おいて外部キーの参照先であるテーブルのデータを削除することで、外部キー制約が定義されたテーブルへのデータ挿入と、外部キー参照先テーブルに

対するデータ削除を競合させます。

PostgreSQL Enterprise Consortium

Page 264 of 285

■ 検証結果

外部キー制約に違反する処理が実施された場合でもBD R ではエラーにならず、データが外部キー制約違反の状態になりました。

■ 競合発生手順

下記の親子関係を持つテーブルを作成します。

(node1のデータベースに接続)

=# CREATE TABLE parent(id integer primary key);

=# CREATE TABLE child(id integer primary key, parent_id integer not null references

parent(id));

=# INSERT INTO parent(id) VALUES (1), (2);

=# INSERT INTO child(id, parent_id) VALUES (11, 1), (12, 2);

各ノードからそれぞれINSER T/DELETEを実行し、外部キー制約の競合を発生させます。

※ n o de1からのINSERTはno d e2では、子テーブルで参照されている親が存在せず、 n o de2のD E LETEはn o d e1で参照している親データを削除しよ

うとしているので、それぞれ適用出来なくなります。

(node1のデータベースにSQLを投入)

=# INSERT INTO child(id, parent_id) VALUES (21, 2);

(node2のデータベースにSQLを投入)

=# DELETE FROM child WHERE parent_id = 2;

=# DELETE FROM parent WHERE id = 2;

それぞれのテーブルの状態を確認し、競合発生時の処理を確認します。

(node1のデータベースを確認)

=# SELECT * FROM child;

id | parent_id

----+-----------

11 | 1

21 | 2

(2 行)

=# SELECT * FROM parent;

----

(1 行)

(node2のデータベースを確認)

=# SELECT * FROM child;

id | parent_id

----+-----------

11 | 1

21 | 2

(2 行)

=# SELECT * FROM parent;

----

(1 行)

※ 外部キー制約違反のデータがchildテーブルに存在する。

7.5.4.4.3. 排他制約排他制約

1. 排他制約の競合

■ 競合概要

排他な関係である2つのデータを異なるノードから同時にテーブルにINSERTし、ノード間のデータに競合が発生するケースを検証します。

■ 検証結果

一つのノードでINSERTされたデータをもう片方のノードに反映させる際に排他制約違反が発生し、ノード間の接続が切断されます。競合を解消するた

めにはオペレータでのデータ操作が必要となるため注意が必要です。

■ 競合発生手順

下記の排他制約を持つテーブルを作成します。

PostgreSQL Enterprise Consortium

Page 265 of 285

(node1のデータベースにSQLを投入)

=# CREATE TABLE sample (aid integer primary key, range daterange, price integer);

=# ALTER TABLE sample ADD EXCLUDE USING gist (price WITH =, range WITH &&);

各ノードからそれぞれINSER Tを実行し、排他制約の競合を発生させます。

※ [2012-04-18 ～ 2012-04/20]の期間が競合しているために排他制約違反を起こしています。

(node1のデータベースにSQLを投入)

=# INSERT INTO sample VALUES(1, '[2012-04-16, 2012-04-20]', 10000);

(node2のデータベースにSQLを投入)

=# INSERT INTO sample VALUES(2, '[2012-04-18, 2012-04-23]', 10000);

(node1またはnode2の競合履歴テーブルに競合ログが出力されない)

=# \x

=# SELECT * FROM bdr.bdr_conflict_history ORDER BY conflict_id DESC LIMIT 1;

それぞれのテーブルの状態を確認し、競合発生時の処理を確認します。

※ 他のノードで実行されたデータ更新を反映する際に、制約違反が発生し、BDRによるノード間の接続が切断されます。

(node1のデータベースを確認)

=# SELECT * FROM sample;

aid | range | price

-----+-------------------------+-------

1 | [2012-04-16,2012-04-21) | 10000

(1 行)

(node2のデータベースを確認)

=# SELECT * FROM sample;

aid | range | price

-----+-------------------------+-------

2 | [2012-04-18,2012-04-24) | 10000

(1 行)

PostgreSQL Enterprise Consortium

Page 266 of 285

(node1のデータベースログ)

bdr (6371561413984311673,2,42879,):receive LOG: starting logical decoding for slot

"bdr_42892_6371561413984311673_2_42879__"

bdr (6371561413984311673,2,42879,):receive DETAIL: streaming transactions committing

after 1/15D41640, reading WAL from 1/15D413B0

bdr (6371561413984311673,2,42879,):receive LOG: logical decoding found consistent point

at 1/15D413B0

bdr (6371561413984311673,2,42879,):receive DETAIL: There are no running transactions.

bdr (6371561413984311673,2,42879,):receive LOG: unexpected EOF on standby connection

LOG: starting background worker process "bdr (6371553825031594764,1,42892,)->bdr

(6371561413984311673,2,"

ERROR: conflicting key value violates exclusion constraint "sample_price_range_excl"

DETAIL: Key (price, range)=(10000, [2012-04-18,2012-04-24)) conflicts with existing key

(price, range)=(10000, [2012-04-16,2012-04-21)).

CONTEXT: apply INSERT from remote relation public.sample in commit 1/194FBC20, xid

3940666 commited at 2017-01-06 16:12:28.275376+09 (action #2) from node

(6371561413984311673,2,42879)

LOG: worker process: bdr (6371553825031594764,1,42892,)->bdr (6371561413984311673,2,

(PID 27843) exited with exit code 1

(node2のデータベースログ)

LOG: starting background worker process "bdr (6371561413984311673,2,42879,)->bdr

(6371553825031594764,1,"

ERROR: conflicting key value violates exclusion constraint "sample_price_range_excl"

DETAIL: Key (price, range)=(10000, [2012-04-16,2012-04-21)) conflicts with existing key

(price, range)=(10000, [2012-04-18,2012-04-24)).

CONTEXT: apply INSERT from remote relation public.sample in commit 1/15D41640, xid

3957701 commited at 2017-01-06 16:09:10.299493+09 (action #2) from node

(6371553825031594764,1,42892)

LOG: worker process: bdr (6371561413984311673,2,42879,)->bdr (6371553825031594764,1,

(PID 29311) exited with exit code 1

bdr (6371553825031594764,1,42892,):receive LOG: starting logical decoding for slot

"bdr_42879_6371553825031594764_1_42892__"

bdr (6371553825031594764,1,42892,):receive DETAIL: streaming transactions committing

after 1/194FB9D0, reading WAL from 1/194FB700

bdr (6371553825031594764,1,42892,):receive LOG: logical decoding found consistent point

at 1/194FB700

bdr (6371553825031594764,1,42892,):receive DETAIL: There are no running transactions.

bdr (6371553825031594764,1,42892,):receive LOG: unexpected EOF on standby connection

※ 各ノードで制約違反が発生し、BDRによる接続が切断されてしまう。解消のためリモートタプルが競合するローカルタプルを削除または変更する

制約違反の状態を解消するために、両側のデータをUPDATEします。

(node1のデータベースにSQLを投入)

=# UPDATE sample SET range = '[2012-04-11,2012-04-16]' WHERE aid = 1;

(node2のデータベースにSQLを投入)

=# UPDATE sample SET range = '[2012-04-23,2012-04-29]' WHERE aid = 2;

PostgreSQL Enterprise Consortium

Page 267 of 285

(node1のデータベースを確認)

=# SELECT * FROM sample;

aid | range | price

-----+-------------------------+-------

1 | [2012-04-11,2012-04-17) | 10000

2 | [2012-04-23,2012-04-30) | 10000

(2 行)

(node2のデータベースを確認)

=# SELECT * FROM sample;

aid | range | price

-----+-------------------------+-------

2 | [2012-04-23,2012-04-30) | 10000

1 | [2012-04-11,2012-04-17) | 10000

(2 行)

7.5.4.4.4. グローバルなデータグローバルなデータ

1. グローバルなデータの競合

■ 競合概要

ロール(グローバルデータ)の情報がノード間で異なる状態で、他のノードに存在しないロールを利用した場合に発生する競合のケースを検証しました。

■ 検証結果

レプリケーション先のノードに同名のロールが存在しない場合、エラーになります。エラーを解消するには、オペレータ側での操作が必要となるため注意が

必要です。

■ 競合発生手順

新規に作成したロールでテーブルを作成します。

(node1のデータベースにSQLを投入)

=# CREATE ROLE testuser SUPERUSER LOGIN;

=# \c testuser

=# CREATE TABLE test01 (id integer primary key);

=# \d

リレーションの一覧

スキーマ | 名前 | 型 | 所有者

----------+--------+----------+----------

public | test01 | テーブル | testuser

(1 行)

(node2のデータベースにSQLを投入)

=# \d

リレーションがありません。

※ ロールなどはレプリケーション対象とならないので、そのロールで作成されたテーブルもレプリケーション対象とならない

データベースログを確認し、ERRO Rが継続して出力されていれば競合が発生しています。

PostgreSQL Enterprise Consortium

Page 268 of 285

(node2のデータベースログ)

LOG: starting background worker process "bdr (6371561413984311673,2,42879,)->bdr

(6371553825031594764,1,"

ERROR: role "testuser" does not exist

CONTEXT: during DDL replay of ddl statement: CREATE TABLE public.test01 (id

pg_catalog.int4 , CONSTRAINT test01_pkey PRIMARY KEY (id) ) WITH (oids=OFF)

apply QUEUED_DDL in commit 1/15DD2278, xid 3958054 commited at 2017-01-06

17:37:58.608995+09 (action #2) from node (6371553825031594764,1,42892)

LOG: worker process: bdr (6371561413984311673,2,42879,)->bdr (6371553825031594764,1,

(PID 30136) exited with exit code 1

※ 権限は関係なく、同名のロールが作成されれば、競合は解決する

レプリケーションを再開させるためにロールなどのグローバルデータを作成します。

(node2のデータベースにSQLを投入)

=# CREATE ROLE testuser LOGIN;

=# \d

リレーションの一覧

スキーマ | 名前 | 型 | 所有者

----------+--------+----------+----------

public | test01 | テーブル | testuser

(1 行)

7.5.4.4.5. ロックの競合とデッドロックの中断ロックの競合とデッドロックの中断

1. ロックの競合とデッドロックの中断

■ 競合概要

一つのノードで取得したロックともう片方のノードで取得したロックが、デッドロック状態となるケースを検証しました。

■ 検証結果

異なるノードで実行されたトランザクションでデッドロック状態が発生した場合、ロックが解除されるまでロック待ちが発生します。 Postg reSQ Lにおいて

デッドロックが発生した場合、デッドロックを引き起こすトランザクションが自動でロールバックされますが、異なるノード間で発生したデッドロックについては

検出できないため、ロック待ち状態が続きます。

■ 競合発生手順

下記テーブルを初期状態とします。

(node1のデータベースにSQLを投入)

=# CREATE TABLE sample (aid integer primary key, range daterange, price integer);

=# ALTER TABLE sample ADD EXCLUDE USING gist (price WITH =, range WITH &&);

=# INSERT INTO sample VALUES(1, '[2012-04-16, 2012-04-20]', 10000);

=# INSERT INTO sample VALUES(2, '[2012-04-21, 2012-04-30]', 12000);

PostgreSQL Enterprise Consortium

Page 269 of 285

(node1のデータベースを確認)

=# SELECT * FROM sample;

aid | range | price

-----+-------------------------+-------

1 | [2012-04-16,2012-04-21) | 10000

2 | [2012-04-21,2012-05-01) | 12000

(2 行)

(node2のデータベースを確認)

=# SELECT * FROM sample;

aid | range | price

-----+-------------------------+-------

1 | [2012-04-16,2012-04-21) | 10000

2 | [2012-04-21,2012-05-01) | 12000

(2 行)

1つのノードからテーブルをロックし、もう片方のノードからはUPDATEを実行し、ロック待ちの影響を受ける事を確認します。ロックが解除されるまで、B D R

適用プロセスはロック待ちが発生します。

(node1のデータベースにSQLを投入)

=# BEGIN;

=# LOCK TABLE sample IN ACCESS EXCLUSIVE MODE;

=# SELECT pg_sleep(10);

=# END;

(node2のデータベースにSQLを投入)

=# UPDATE sample SET price = 14000 WHERE aid = 2;

(ロック待ちなので競合ログが出力されない)

=# \x

=# SELECT * FROM bdr.bdr_conflict_history ORDER BY conflict_id DESC LIMIT 1;

7.5.4.4.6. その他その他

自動的には解決出来ないデータの相違が発生した場合は、以下設定を使用して手動で調整する必要があります。

※ レプリケーション環境を破壊することが可能であるため使用する際には注意が必要です。

項番項番パラメータパラメータ説明説明

1 b dr.do _n o t_rep licate(bo o lean) このパラメータセットを持つトランザクションで行われた変更は、

他ノードへのレプリケーションのためにキューに格納されない。

=# CREATE TABLE test (id int primary key, name text);

=# \q

PostgreSQL Enterprise Consortium

Page 270 of 285

(node1に対してのみレコード追加を実行）

$ export PGOPTIONS='-c bdr.do_not_replicate=on'

$ psql -h node1 bdrtest

=# INSERT INTO test values(1, 'test');

=# SELECT * from test;

id | name

----+------

1 | test

(1 行)

(node2には反映されていないことを確認)

=# SELECT * from test;

id | name

----+------

(0 行)

項番項番パラメータパラメータ説明説明

2 b d r.sk ip_ddl_replica tion (b o o lean ) D D Lによる変更のレプリケーションをスキップする。

一部のノードのみにDDLを実行したい場合に有効。

スーパーユーザのみが設定可能。

(node1にのみテーブルを作成）

=# BEGIN;

=# SET LOCAL bdr.skip_ddl_replication = true;

=# CREATE TABLE skip (id int primary key, name text);

=# END;

=# \d

リレーションの一覧

スキーマ | 名前 | 型 | 所有者

----------+--------+----------+----------

public | sample | テーブル | postgres

public | skip | テーブル | postgres

public | test | テーブル | postgres

(3 行)

(node2には反映されていないことを確認)

=# \d

リレーションの一覧

スキーマ | 名前 | 型 | 所有者

----------+--------+----------+----------

public | sample | テーブル | postgres

public | test | テーブル | postgres

(2 行)

項番項番パラメータパラメータ説明説明

3 b d r.permit_u n safe_ddl_co mman d s(boo lean ) 安全にレプリケーションできないスキーマの変更を許可する。

スーパーユーザのみが設定可能。

以下のようなデフォルトでは実行が許可されていないクエリを実行可能。

* CREATE TAB LE AS

* ALTER TAB LE ... ADD CO LUM N ... DEFAU LT

* CREATE MATERIALIZED VIEW

* REF R E SH M ATERIALIZED VIEW

PostgreSQL Enterprise Consortium

Page 271 of 285

(デフォルトではエラーとなる)

=# CREATE TABLE test2 AS SELECT * from test;

ERROR: CREATE TABLE AS is not supported when bdr is active

(エラーが出ないことを確認)

=# BEGIN;

=# SET LOCAL bdr.permit_unsafe_ddl_commands = true;

=# CREATE TABLE test2 AS SELECT * from test;

=# END;

7.5.4.5. 検証結果検証結果

一部の競合パターンにて、意図しない動作が発生するため、現段階では競合が発生しないパターンで利用すべきと考えます。

7.5.5. ノード障害と復旧ノード障害と復旧

7.5.5.1. 検証の目的検証の目的

複数ノードで構成されるクラスタ環境内の1ノードに障害が発生した場合でも、他ノードで継続利用可能か否かを確認します。また、障害が発生したノードをクラスタ環境

に復旧させる手順を確認します。

7.5.5.2. 検証内容検証内容

本検証では2台で構成されたB D R クラスタに対して、下記を実施しました。

1. ノード障害

2. ノード復旧

7.5.5.3. 検証環境検証環境

こちらの環境で検証を実施しました。

7.5.5.4. 検証手順検証手順

7.5.5.4.1. ノード障害ノード障害

1. B D R の各ノード状態確認

B D R の各ノード間のレプリケーションが正常に動作していることを「b d r.bdr_n o d es」テーブルを用いて確認します。

PostgreSQL Enterprise Consortium

Page 272 of 285

(node1にて実施)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r

<-- r(正常)であることを確認

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | r

<-- r(正常)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest

<-- node1から作成されていることを確認

2. 検証用テーブルとデータの作成

pg b ebch を利用して、検証時に利用するテーブルとデータを作成します。

(node1にて実施)

$ pgbench -i -s 10 bdrtest

3. トランザクション実行

pg b ench を利用して、ノード1にトランザクションを継続的に実行します。ノード2に障害が発生した場合に、ノード1に対して実行したトランザクションに

エラーが発生するか否かを確認します。

$ pgbench -h node1 -c 10 -t 100000 bdrtest

starting vacuum...end.

4. ノード障害

ノード2で動作するPostgreSQ Lを停止させます。

(node2にて実施)

$ pg_ctl stop -m i

waiting for server to shut down..... done

server stopped

5. ノード1のログ確認

ノード2障害時に出力されるログメッセージを確認します。下記メッセージは出力されますが、pgb en ch のトランザクションは継続して実行可能です。

$ tail -f [PostgreSQLのログファイル]

LOG: starting background worker process "bdr (6367633348875313343,1,34478,)->bdr

(6369931070716042622,2,"

ERROR: establish BDR: could not connect to server: Connection refused

Is the server running on host "node2" (192.168.1.3) and accepting

TCP/IP connections on port 5432?

6. B D R の各ノード状態確認

ノード2障害後、ノード状態が変化するか否かを「bdr.bd r_n o des」テーブルを用いて確認します。

PostgreSQL Enterprise Consortium

Page 273 of 285

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | r <-- r(正常)の状態のまま

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest

※ 状態変化は確認できませんでした。

7. ノードの切り離し

障害が発生したノード2を切り離しするため、「bdr.bd r_p a rt_by_n o d e_names」関数を実行します。

(node1のデータベースに接続)

=# SELECT bdr.bdr_part_by_node_names(ARRAY['node2']);

bdr_part_by_node_names

------------------------

(1 row)

8. ノードの切り離し結果確認

ノードの切り離し結果を「bd r.b d r_n o d es」テーブルを用いて確認します。

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn , node_status, node_init_from_dsn FROM

bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | k <-- k(削除)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest

9. システムカタログの残データ削除

本手順は推奨される手順ではありませんが、削除状態のノードが「b dr.bd r_n o des」テーブルに残っているとノード復旧が実行できないため暫定的な

対処です。 B DRのIssu esで「bdr.bd r_co n n ection s」のデータも削除する事が提案されていたので、こちらも暫定的な手順ですが実行します。詳細

は下記をご参照下さい。

h ttps://githu b .com/2n d Q u ad ran t/bd r/issu es/97

h ttps://githu b .com/2n d Q u ad ran t/bd r/issu es/126

(node1のデータベースに接続)

=# DELETE FROM bdr.bdr_connections USING bdr.bdr_nodes WHERE node_status = 'k' AND"

(node_sysid, node_timeline, node_dboid) = (conn_sysid, conn_timeline, conn_dboid);

=# DELETE FROM bdr.bdr_nodes where node_status = 'k';

10. トランザクション状態実行状態確認

PostgreSQL Enterprise Consortium

Page 274 of 285

手順1で実行したp g ben ch にエラーが発生してないことを確認します。本検証ではエラーは発生しませんでした。

7.5.5.4.2. ノード復旧ノード復旧

B D R ノードの復旧方法(ノード追加)する場合、既存ノードのデータベースと復旧させるノードのデータベースのスキーマおよびデータを同期させる必要があります。ノード間の

データコピーには、論理コピーと物理コピーの2つの手法があります。

h ttp://b dr-pro ject.o rg/d o cs/stable/fu n ction s-n od e-mg mt.h tml#FU NCTIO N-BD R -GRO U P-JO IN

表 7.8 コピー取得方法

項番項番コピー取得コピー取得説明説明備考備考

1 bd r.b d r_gro u p_jo in 関

数実行

ユーザが指定したノード内データベースのスキーマとデータダンプを取得 pg _d u mpコマンドに相当

2 bd r_init_co pyコマンドユーザが指定したノード上の全てのデータベースのコピーを取得 pg _b aseb acku pコマンド

に相当

■ 論理コピーによる復旧

1. トランザクション実行

要か否かを確認します。

$ pgbench -h node1 -c 10 -t 100000 bdrtest

starting vacuum...end.

2. ノード2のPostgreSQ L起動

ノード2上で動作するPo stg reSQ Lを起動させます。

$ pg_ctl start

3. B D R の無効化

ノード2のデータベースからB D R を削除し、B DR拡張機能を削除します。

(node2のデータベースに接続)

=# SELECT bdr.remove_bdr_from_local_node(true);

WARNING: forcing deletion of possibly active BDR node

NOTICE: removing BDR from node

NOTICE: BDR removed from this node. You can now DROP EXTENSION bdr and,

if this is the last BDR node on this PostgreSQL instance, remove bdr from

shared_preload_libraries.

remove_bdr_from_local_node

----------------------------

=# DROP EXTENSION bdr;

DROP EXTENSION

4. データベース削除

B D R で利用したデータベースを削除します。

(node2のデータベースに接続)

=# DROP DATABASE bdrtest ; ※ 接続が残っており、削除できない場合はPostgreSQLを再起動

DROP DATABASE

5. データベースの再作成

PostgreSQL Enterprise Consortium

Page 275 of 285

B D R で利用するデータべースを再度作成します。

(node2のデータベースに接続)

=# CREATE DATABASE bdrtest;

6. B D R 有効化

無効化したB D R を再度有効化します。

(node2のデータベースに接続)

=# CREATE EXTENSION btree_gist;

CREATE EXTENSION

=# CREATE EXTENSION bdr;

CREATE EXTENSION

7. ノードの追加

ノードを追加(復旧)させるため、「bdr.bd r_gro u p _join」関数を実行します。

(node2のデータベースに接続)

=# SELECT bdr.bdr_group_join(

local_node_name := 'node2',

node_external_dsn := 'host=node2 port=5432 dbname=bdrtest',

join_using_dsn := 'host=node1 port=5432 dbname=bdrtest'

);

bdr_group_join

----------------

(1 行)

8. ノード追加の確認待ち

ノードが追加されたことを確認するため、「bd r.b d r_n od e_join _w ait_for_ready」関数を実行します。

(node2のデータベースに接続)

=# SELECT bdr.bdr_node_join_wait_for_ready();

※ トランザクションが実行中の場合、上記関数の結果が戻りません。

n od e1のPostgreSQ Lログファイルに下記メッセージが出力された後、復旧の処理が開始されません。

(node1のログメッセージ抜粋)

LOG: logical decoding found initial starting point at 0/BB399BF0

DETAIL: 10 transactions need to finish.

pg b ench コマンドで実行中のトランザクションを停止すると、下記ログメッセージが出力され、復旧処理が開始されます。

(node1のログメッセージ抜粋)

LOG: logical decoding found consistent point at 0/B2895648

DETAIL: There are no running transactions.

LOG: exported logical decoding snapshot: "00046FE0-1" with 0 transaction IDs

9. B D R の各ノード状態確認

ノード2が追加されたことを「bdr.bd r_n o des」テーブルの情報から確認します。

PostgreSQL Enterprise Consortium

Page 276 of 285

(node1のデータベースに接続)

=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest <-- node1から作

成されていることを確認

■ 物理コピーによる復旧

1. トランザクション実行

要か否かを確認します。

$ pgbench -h node1 -c 10 -t 100000 bdrtest

starting vacuum...end.

2. ノード2のPostgreSQ L停止確認

ノード2上で動作するPo stg reSQ Lが停止していることを確認します。

(node2にて実施)

$ pg_ctl status

pg_ctl: no server running

3. 物理コピーの取得

ノード2上で「bd r_in it_co p y」コマンドを実行し、n o d e1上のコピーを取得します。

(node2にて実施)

$ rm -rf $PGDATA/*

$ bdr_init_copy -D $PGDATA -n node2 -h node1 -p 5432 -d bdrtest

--local-host=node2 --local-port=5432 --local-dbname=bdrtest

bdr_init_copy: starting ...

Getting remote server identification ...

Detected 1 BDR database(s) on remote server

Updating BDR configuration on the remote node:

bdrtest: creating replication slot ...

bdrtest: creating node entry for local node ...

Creating base backup of the remote node...

50357/50357 kB (100%), 1/1 tablespace

Creating restore point on remote node ...

Bringing local node to the restore point ...

トランザクションログをリセットします。

Initializing BDR on the local node:

bdrtest: adding the database to BDR cluster ...

All done

n od e1のPostgreSQ Lログファイルに下記メッセージが出力された後、復旧の処理が開始されません。

PostgreSQL Enterprise Consortium

Page 277 of 285

(node1のログメッセージ抜粋）

LOG: logical decoding found initial starting point at 0/BB399BF0

DETAIL: 10 transactions need to finish.

pg b ench コマンドで実行中のトランザクションを停止すると、下記ログメッセージが出力され、復旧処理が開始されます。

(node1のログメッセージ抜粋

LOG: logical decoding found consistent point at 0/B2895648

DETAIL: There are no running transactions.

STATEMENT: SELECT

pg_create_logical_replication_slot('bdr_25434_6369931070716042622_2_25434__', 'bdr');

4. B D R の各ノード状態確認

ノード2が追加されたことを「bdr.bd r_n o des」テーブルの情報から確認します。

(node1のデータベースに接続)

bdrtest=# SELECT node_name, node_local_dsn, node_status, node_init_from_dsn FROM

bdr.bdr_nodes;

-[ RECORD 1 ]------+------------------------------------

node_name | node1

node_local_dsn | host=node1 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn |

-[ RECORD 2 ]------+------------------------------------

node_name | node2

node_local_dsn | host=node2 port=5432 dbname=bdrtest

node_status | r <-- r(正常)であることを確認

node_init_from_dsn | host=node1 port=5432 dbname=bdrtest <-- node1から作

成されていることを確認

7.5.5.5. 検証結果検証結果

ノード障害が発生した際にも、他のノードではトランザクションを継続実行することが可能でした。障害ノードを復旧させるためにはデータ操作が禁止されているシステムカタ

ログのデータ削除が必要でした。

7.5.5.6. 備考備考

ノード障害後および復旧中にD D Lを実行すると下記のエラーが出力されます。

=# CREATE TABLE test2(id int);

ERROR: No peer nodes or peer node count unknown, cannot acquire global lock

HINT: BDR is probably still starting up, wait a while

7.6. BDR性能検証

7.6.1. 更新性能検証結果更新性能検証結果

7.6.1.1. 検証目的検証目的

本試験はBD R の本来のユースケースである、高レイテンシ環境との双方向レプリケーション環境における更新クエリのレスポンス改善とそれに伴う性能改善を確認したもの

です。

7.6.1.1.1. 検証内容検証内容

PostgreSQL Enterprise Consortium

Page 278 of 285

今回は 2014年度検証報告書（可用性編）に記載された東京-シンガポール間の回線情報（応答速度76.95ms、帯域幅0.16Gb its/s）をもとに、以下のような環境

を構築しpg ben ch を実行しました。

通常のストリーミングレプリケーションであれば、更新クエリを実行したい場合はシンガポールのマスタノードに更新要求を実施する必要がありますが、 BDRでは最寄りのノー

ドに対して更新要求を実施することが可能です。

7.6.1.1.2. 検証環境検証環境

こちらの環境で検証を実施しました。

7.6.1.1.3. 検証手順検証手順

1. 環境構築

pg b ench を実行する準備を行います。（BDR, SR環境両方）

# pgbench -i test -U postgres -s 10

NOTICE: table "pgbench_history" does not exist, skipping

NOTICE: table "pgbench_tellers" does not exist, skipping

NOTICE: table "pgbench_accounts" does not exist, skipping

NOTICE: table "pgbench_branches" does not exist, skipping

creating tables...

100000 of 100000 tuples (100%) done (elapsed 0.25 s, remaining 0.00 s).

vacuum...

set primary keys...

done.

n od e1, n o de2ともにテーブルが作成されていることを確認します。

# psql -U postgres test -c "\d"

リレーションの一覧

スキーマ | 名前 | 型 | 所有者

----------+------------------+----------+----------

public | pgbench_accounts | テーブル | postgres

public | pgbench_branches | テーブル | postgres

public | pgbench_history | テーブル | postgres

public | pgbench_tellers | テーブル | postgres

(4 行)

# /usr/pgsql-9.4/bin/psql -U postgres -h node2 test -c "\d"

リレーションの一覧

スキーマ | 名前 | 型 | 所有者

----------+------------------+----------+----------

public | pgbench_accounts | テーブル | postgres

public | pgbench_branches | テーブル | postgres

public | pgbench_history | テーブル | postgres

public | pgbench_tellers | テーブル | postgres

(4 行)

帯域制限及び遅延設定を行います。

PostgreSQL Enterprise Consortium

Page 279 of 285

（clientはnode2向け通信のみ制限)

tc qdisc add dev eth0 root handle 1:0 htb

tc class add dev eth0 parent 1:0 classid 1:10 htb rate 160Mbit

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.12/32

flowid 1:10

tc qdisc add dev eth0 parent 1:10 handle 10:1 netem delay 38ms 1ms

（node1はnode2向け通信のみ制限）

tc qdisc add dev enp0s25 root handle 1:0 htb

tc class add dev enp0s25 parent 1:0 classid 1:10 htb rate 160Mbit

tc filter add dev enp0s25 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.12/32

flowid 1:10

tc qdisc add dev enp0s25 parent 1:10 handle 10:1 netem delay 38ms 1ms

（node2は両ノード向け通信とも制限）

tc qdisc add dev enp0s25 root handle 1:0 htb

tc class add dev enp0s25 parent 1:0 classid 1:0 htb rate 160Mbit

tc qdisc add dev enp0s25 parent 1:0 handle 10:1 netem delay 38ms 1ms

帯域制限の結果以下のような環境になります。

表 7.9 帯域制限後のネットワーク情報

Client/Server client node1 n ode2

clien t －遅延：0.5 ms

帯域幅：934 M b its/s

遅延：76ms

帯域幅：160 M b its/s

n od e1 遅延：0.5 ms

帯域幅：934 M b its/s

－遅延：76ms

帯域幅：160 M b its/s

n od e2 遅延：76ms

帯域幅：160 M b its/s

遅延：76ms

帯域幅：160 M b its/s

－

2. レスポンスタイム確認

更新クエリの応答速度を確認します。

# time psql -h node1 -x -c "UPDATE pgbench_branches SET bbalance = bbalance + 100 WHERE

bid = 1" test

UPDATE 1

real 0m0.025s

user 0m0.001s

sys 0m0.001s

# time psql -h node2 -x -c "UPDATE pgbench_branches SET bbalance = bbalance + 100 WHERE

bid = 1" test

UPDATE 1

real 0m0.259s

user 0m0.001s

sys 0m0.000s

（ネットワーク遅延に伴いレスポンスが低下していることを確認）

3. SR環境の性能試験

非同期SR構成のマスターに対してp gb en ch を実施します。

PostgreSQL Enterprise Consortium

Page 280 of 285

# pgbench -U postgres -p 5433 -h node2 -s 10 -c 10 test -T 180

scale option ignored, using count from pgbench_branches table (10)

starting vacuum...end.

transaction type: TPC-B (sort of)

scaling factor: 10

query mode: simple

number of clients: 10

number of threads: 1

duration: 180 s

number of transactions actually processed: 3078

latency average: 584.795 ms

tps = 17.042442 (including connections establishing)

tps = 17.057455 (excluding connections establishing)

4. B D R 環境の性能試験

競合が発生しているか確認するために、「bd r.b d r_con flict_h isto ry」を参照し競合履歴数を確認します。

# psql -h node1 -x -c "SELECT count(*) FROM bdr.bdr_conflict_history;" test

-[ RECORD 1 ]

count | 52265

# psql -h node2 -x -c "SELECT count(*) FROM bdr.bdr_conflict_history;" test

-[ RECORD 1 ]-

count | 132935

B D R 環境のノードにp g b en ch を実施します。

# pgbench -U postgres -h node1 -s 10 -c 10 test -T 180

scale option ignored, using count from pgbench_branches table (10)

starting vacuum...end.

transaction type: TPC-B (sort of)

scaling factor: 10

query mode: simple

number of clients: 10

number of threads: 1

duration: 180 s

number of transactions actually processed: 16677

latency average: 107.933 ms

tps = 92.598796 (including connections establishing)

tps = 92.602290 (excluding connections establishing)

競合が発生していないことを確認します。

# psql -h node1 -x -c "SELECT count(*) FROM bdr.bdr_conflict_history;" test

-[ RECORD 1 ]

count | 52265

# psql -h node2 -x -c "SELECT count(*) FROM bdr.bdr_conflict_history;" test

-[ RECORD 1 ]-

count | 132935

7.6.1.1.4. 検証結果検証結果

本検証では以下を確認することが出来ました。

レスポンスタイムの低減

PostgreSQL Enterprise Consortium

Page 281 of 285

低レイテンシのサーバに更新クエリを実行可能であるため、レスポンスタイムを低減することが出来ました。

TPSの向上

レスポンスタイムが低減されたため、TPSの向上が見られました。

"17.057455" -> "92.602290"（約5.4倍）

ただし、本検証では片系のみに変更を実施し競合が発生しないようにした試験だったため、このような結果になったものと思われます。

本検証で使用しているpgb en ch （TCP-B ライク）のような、現在の値に対して加算していくような処理の場合、結果整合で競合を解決することができないため、絶対に競

合が発生しない構成が必要です。

例）更新するテーブルを拠点ごとに分ける等

7.7. まとめ

7.7.1. BDR検証まとめ検証まとめ

本検証では、BDRの機能や特徴および主なユースケースを机上調査を実施した上で、B D Rの動作検証および性能検証を実施しました。本検証で実施したB DRの動

作検証の結果は下表の通りです。

表 7.10 結果評価基準

記号記号意味意味

○ 問題なし。

△ 利用時に問題になるケースがある。

× 対応していない。事実上使えない。

表 7.11 B DR検証結果

項番項番検証概要検証概要結果結果補足補足

1 ノード追加/削除 △ ノード削除はオンラインで実行可能。ノード追加時にトランザクションの停止が必要。また、削除したノード

を追加する場合にはシステムカタログの操作が必要。

2 グローバルシーケンス ○ シーケンスの競合を防ぐことが可能。ただし、マニュアルに記載された制限事項については確認が必要。

3 選択的レプリケーション ○ B DRを利用して任意のテーブルのデータ集約等を実現可能

4 更新処理競合時の動作 △ 更新が競合するパターンで意図しない動作が発生し、競合解消のため手動での操作が必要。

5 ノード障害と復旧 △ ノード復旧時にはトランザクションの停止が必要。また、障害が発生したノードを復旧させる際にシステムカ

タログの操作が必要。

本検証で利用したバージョン(1.0.2)では更新が競合するパターンで意図しない動作が発生するため、B D R を適用する場合、競合が発生しないようなアプリケーション設計

やテーブル設計が必要になります。

例) 更新するテーブルを拠点ごとに分ける等

ノード障害時の運用においても、一般的でないシステムカタログの操作を必要とするといった今後の改善が必要と思われる結果が確認されました。

また、B D R の選択的レプリケーションを用いることで、Po stgreSQ Lのストリーミング・レプリケーションでは実現できない、テーブル単位のレプリケーションが実現可能なことを確

認できました。上記機能を用いて、システム間のデータ連携(データ集約等)を柔軟に実現できると考えております。

性能検証の結果より、ユースケースで想定している「遠距離拠点間で双方向に更新する」場合に、レスポンスタイムの低減と処理向上につながることが確認できました。

机上で調査した通り、B D R を適用することで「遠距離拠点間のトランザクション性能改善」や選択的レプリケーション機能を利用した「柔軟なデータ連携」を実現できると

考えます。

7.8. 参考文献

[B DR] Po stgres-BD R ドキュメント h ttp://b dr-pro ject.o rg/d o cs/stable/

7.8.1. 関数一覧関数一覧

PostgreSQL Enterprise Consortium

Page 282 of 285

表 7.12 関数一覧

項番項番関数関数参照ドキュメント参照ドキュメント

1 b dr.bd r_g ro u p _create fun ction s-n o de-mg mt.html

2 b dr.bd r_g ro u p _join fu n ction s-n o d e-mg mt.html

3 b dr.bd r_p art_by_no d e_n ames fu n ction s-n o d e-mg mt.h tml

4 b dr.remove_b dr_from_lo cal_n o d e fun ction s-n o de-mg mt.html

5 b dr.bd r_n o de_join _w ait_fo r_ready fun ction s-n o de-mg mt.html

6 b dr.tab le_set_replica tion _sets fun ction s-replicatio n -sets.h tml

7 b dr.tab le_get_replication _sets fu n ction s-replication -sets.h tml

8 b dr.con n ectio n _get_rep lication _sets fun ction s-rep licatio n -sets.html

7.8.2. システムカタログ一覧システムカタログ一覧

表 7.13 システムカタログ一覧

項番項番システムカタログシステムカタログ参照ドキュメント参照ドキュメント

1 bd r.b d r_con flict_h isto ry catalo g -b dr-con flict-histo ry.html

2 bd r.b d r_n od es catalo g -b dr-n o des.h tml

3 bd r.b d r_con n ectio n s catalo g -b d r-co n n ectio n s.h tml

PostgreSQL Enterprise Consortium

Page 283 of 285

8. まとめまとめ

本文書ではPostg reSQ Lにおけるレプリケーション技術として標準機能として組み込まれているストリーミングレプリケーションとロジカルレプリケーションについて取り上げまし

た。さらに、マルチマスタ構成に対応したB i-Directio n al Replication (B D R)についても取り上げました。

ストリーミングレプリケーションは、2010年9月にリリースされたPostgreSQ L9.0で標準機能として組み込まれ、徐々に実運用での利用される機会が増えるとともに、実運

用で必要となる機能改善がその後のバージョンアップで継続的に行われています。

本文書ではストリーミングレプリケーション構成を構築する基本的な手順を確認した上で、レプリケーションスロット、遅延レプリケーション、W AL圧縮といった新しい機能に対

しても、設定から実際の動作を確認するまでの具体的な手順を整理することができました。障害発生時の運用についてはPostgreSQ L9.5から提供されるようになった

pg _rew in dコマンドを使うことで、これまで必要とされていたフルバックアップ取得を不要とする運用が可能になっていることを確認できました。さらに、複数台のスレーブが存

在するあるいはカスケードレプリケーションといったより複雑な構成で障害が発生した場合の運用手順についても確認しました。

ロジカルレプリケーションは、2017年10月にリリースされたPo stg reSQ L10.0で標準機能として組み込まれました。ストリーミングレプリケーションと類似したアーキテクチャを持

ちながら、テーブル単位や更新種別単位で柔軟なレプリケーション形態を取ったり、複製先を更新することができる等の特徴を有しています。

本文書ではロジカルレプリケーション構成を構築する基本的な手順、同期レプリケーション、複数Sub scriptionへのレプリケーション、カスケード構成といった応用的な使い

方、監視方法や障害発生時の挙動、レプリケーション開始後のテーブル追加、定義変更の手順について検証しました。検証結果より、現状のロジカルレプリケーションは

柔軟にテーブル単位、更新種別単位で複製できることによりレプリケーションの活用範囲が広がった一方で、更新競合を解消する機能が貧弱なことやレプリケーションされ

ないSQ L、オブジェクトが多数あるといった制約事項もあるため、現状では更新競合が発生しないよう複製先を参照用途に限定して利用するのが現実的と考えます。

B D R は、現状のストリーミングレプリケーションでは不可能なマルチマスタ構成に対応することから、シングルマスタ構成に起因する課題解消が期待されます。今回の検証で

は、BDR の特徴、ユースケース、メカニズムを類似機能、製品と机上比較した上で、更新処理競合時の動作、ノード障害時の動作、更新性能についてそれぞれ検証し

ました。更新性能の検証結果より、ユースケースで想定している「遠距離拠点間で双方向に更新する」場合に、レスポンスタイムの低減とTPS向上につながることがわかり

ました。

一方で、現時点のバージョンでは更新が競合するパターンで意図しない動作が発生するため、現段階では競合が発生しないパターンで利用すべきと考えます。そこで、

B D R の利用時は競合が発生しにくいテーブル設計にすることが望ましいです。また、ノード障害時の運用においても、一般的でないシステムカタログの操作を必要とすると

いった今後の改善が必要と思われる結果が確認されました。

これらの結果から、BDRについてはユースケースと実際の利用用途が合致しているかを見極めた上で利用するかどうかを判断する必要があるといえます。

今回の検証結果がストリーミングレプリケーション構成を実際に利用している方々の運用改善につながること、またロジカルレプリケーションやBD R を利用すべきかどうかを判

断する際の参考情報として活用いただけることを期待しています。

PostgreSQL Enterprise Consortium

Page 284 of 285

9. 著者著者

（企業・団体名順）

版版所属企業・団体名所属企業・団体名部署名部署名氏名氏名

第1.0版

(2016年度W G3)

株式会社アシストデータベース技術本部竹内尚也

株式会社アシストデータベース技術本部柘植丈彦

株式会社オージス総研プラットフォームサービス本部 IT基盤技術部大西斉

TIS株式会社 IT基盤技術本部 IT基盤技術推進部中西剛紀

日本電信電話株式会社オープンソースソフトウェアセンタ坂田哲夫

株式会社富士通ソーシアルサイエンスラボラトリプラットフォームインテグレーション本部　第四システム部小山田政紀

株式会社富士通ソーシアルサイエンスラボラトリプラットフォームインテグレーション本部　第四システム部高橋勝平

株式会社富士通ソーシアルサイエンスラボラトリプラットフォームインテグレーション本部　第四システム部香田紗希

第2.0版

(2017年度W G3)

株式会社アシストサービス事業部サポートセンター神谷美恵子

株式会社アシストデータベース技術本部技術統括部竹内尚也

株式会社アシストデータベース技術本部技術統括部柘植丈彦

株式会社オージス総研プラットフォームサービス本部 IT基盤技術部大西斉

TIS株式会社 IT基盤技術本部中西剛紀

株式会社富士通ソーシアルサイエンスラボラトリソリューション開発センターソリューションビジネス部小山田政紀

株式会社富士通ソーシアルサイエンスラボラトリ第二システム事業本部　第三システム部香田紗希

PostgreSQL Enterprise Consortium

Page 285 of 285