4.3.1.1. 調査の目的¶

SR構成のサーバログ監視について有益な情報を提示する事を目的としています。 以下の挙動時にサーバログに出力されるメッセージを確認しました。

• マスタの起動/停止
• スレーブの起動/停止
• マスター側のWAL再利用によるロスト(スロット不使用）

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

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

4.3.1.2. 調査結果¶

マスタ側またはスレーブ側のサーバログに出力されるレプリケーション情報についてまとめます。 ホスト名、IPアドレス、ポート番号、ユーザ名、データベース名は例です。

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

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

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

4.3.1.3. 調査結果¶

• エラーについては、デフォルト設定で出力があります。

  エラーの監視という意味では、デフォルトで問題ないと言えます。
• 表の太字の文字が監視キーワード候補です。
• マスターまたはスレーブを停止すると、反対側にエラー出力があります。
• log_replication_command による出力はそれほど多くなく、監視に対する影響は限定的です。

  ただリロードで反映できることと合わせて、気軽に有効化できるとも言えます。
• log_min_message = debug とすることでもレプリケーション関連のメッセージが出力されます。

  ただし影響が大きいため、通常はlog_replication_commandを使用します。
• log_replication_commandによる出力は、スレーブのwal receiverプロセスからフィードバックされた情報です。

  log_line_prefixにapplication_name(%a)を設定する事で確認できます。

4.3.2.1. 同期遅延監視¶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#!/bin/sh
HOST=localhost
LIMIT=1
SLEEPTIME=2
ALERT="echo"

function send_alert(){
    ${ALERT} $1
}

while :
do
    val1=$(psql -h $HOST -p 5432 -U postgres -q -t -c "select current_time;")
    val2=$(psql -h $HOST -p 5432 -U postgres -q -t -c "select client_addr,
           pg_xlog_location_diff(master,replay_location)as
           replaydiff from (select pg_current_xlog_insert_location() master)as m,
           pg_stat_replication;")

    if [ ! -n "${val2}" ]; then
        send_alert "Slave Down |${val1}"
    else
        byte=`echo ${val2} |awk  '{print $NF}'`
        if [ ${byte} -gt ${LIMIT} ]; then
            send_alert "Replication Delay |${val1},${val2}"
        fi
    fi
    sleep ${SLEEPTIME}
done

$ ./kanshi_No8.sh
Replication Delay | 03:03:39.701249+09, ***.***.***.*** | 104
Replication Delay | 03:03:41.725377+09, ***.***.***.*** | 104
Replication Delay | 03:03:43.745755+09, ***.***.***.*** | 104
Replication Delay | 03:03:47.790622+09, ***.***.***.*** | 56
Replication Delay | 03:03:49.813697+09, ***.***.***.*** | 56
Replication Delay | 03:03:51.834757+09, ***.***.***.*** | 56

4.3.3.1. 更新・読取監視¶

[postgres@test_pg02 ~]$ 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

testdb=# select * from pg_stat_replication;
  pid  | usesysid | usename | application_name |  client_addr   | client_hostnam
e | client_port |         backend_start         | backend_xmin |   state   | sen
t_location | write_location | flush_location | replay_location | sync_priority |
 sync_state
-------+----------+---------+------------------+----------------+---------------
--+-------------+-------------------------------+--------------+-----------+----
-----------+----------------+----------------+-----------------+---------------+
------------
(0 行)

$ 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.
時間: 4995.329 ms

$ echo $?
124

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

SR構成においては、通常はマスターの障害を検知した場合にスレーブを昇格させます。つまりマスターは常に1台のみです。 ただしオペレーションミスにより、マスターが正常な状態にもかかわらずスレーブを昇格させてしまうという事も有り得ます。 稼働中のマスター（シングル）が2台という危険な状態になります。その状態をスプリットブレインと定義します。

その場合でも全てのアプリケーションが元のマスターにのみ接続していれば問題ありませんが、 2台目のマスターにも接続が発生するとデータの整合性が損なわれてしまいます。 それを避けるため、スプリットブレイン状態になっていないかの監視の方法を検討します。

4.3.4.2. 監視方法¶

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

• サーバログの監視
• pg_controldataコマンドによる監視
• pg_control_recovery関数による監視
• pg_is_in_recovery関数による監視

4.3.4.3. サーバログの監視¶

received promote request
selected new timeline ID: XX

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

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

4.3.4.4. pg_controldataコマンドによる監視¶

$ export LANG=C
$ pg_controldata
pg_control version number:     960
Catalog version number:        201608131
Database system identifier:    6356464040634181169
Database cluster state:        in archive recovery
pg_control last modified:      Tue Dec 13 14:39:49 2016
～以下略～

多数の項目がありますが、ここでは”Database cluster state”に着目します。 必要な項目のみ抽出する例です。

$ pg_controldata | grep "Database cluster state"
Database cluster state:        in archive recovery

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

• マスター/スレーブ
• 稼働中/停止中

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

$ ssh <remote> $PGHOME/bin/pg_controldata $PGDATA | \
>  grep "Database cluster state"
Database cluster state:               in production

4.3.4.5. pg_control_recoveryコマンドによる監視¶

=# SELECT pg_control_recovery();
pg_control_recovery
-----------------------------
 (0/E0EAFB50,5,0/0,0/0,f)
 (1 行)

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

min_recovery_end_locationおよび min_recovery_end_timelineにマスターとスレーブの違いが表れます。

4.3.4.6. pg_is_in_recovery関数による監視¶

リカバリ中かどうかを示します。 マスターであれば false 、スレーブであれば true を表示します。

=# SELECT pg_is_in_recovery();
pg_is_in_recovery
-------------------
 t
(1 行)

4.4.1.1. フェイルオーバ¶

4.4.1.2. フェイルバック¶

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

4.4.1.3. スイッチオーバ¶

4.4.1.4. スイッチバック¶

4.4.2.1. フェイルオーバ¶

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

$ pg_ctl -w -m immediate stop

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

$ pg_isready -h server2 -U postgres -d postgres
server2:5432 - no response

$ pg_ctl promote

ただしこの時点ではsynchronous_standby_namesパラメータに値が設定されているため、新マスタで更新処理ができない状態です。

$ vi $PGDATA/postgresql.conf

[編集前]
synchronous_standby_names = '*'

[編集後]
synchronous_standby_names = ''

$ pg_ctl reload

$ pg_isready -h server2 -U postgres -d postgres
server2:5432 - accepting connections

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

4.4.2.2. フェイルバック¶

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

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

■パラメータ

pg_basebackupに必要な設定を記載します。

■pg_basebackupコマンド

pg_basebackupコマンドの主なオプションは次の通りです。

表 4.18 pg_basebackupのオプション¶

オプション	内容
-D <directory>	出力を書き出すディレクトリを指定。
-X <method> –xlog-method=<method>	必要なWALファイルをバックアップに含める。method(収集方式)は以下から選択。 fetch ：WALファイルは最後に収集 stream：バックアップ作成中に同時にWALをストリームで収集 運用中にpg_basebackupを実行する場合には stream を指定する。 fetch （最後に収集）では、必要なWALファイルが削除される可能性があるため。
-S <slot_name> –slot=<slot_name>	WALストリーミングの収集に指定したレプリケーションスロットを使用。 -X stream とセットで指定。 必要なWALファイルが削除されるのを防ぐ事を目的とする。 運用中にpg_basebackupを実行する場合に使用を検討する。 以下に注意する。 事前にレプリケーションスロットを作成する必要がある マスタのWAL領域の空きが十分である事を確認する
-R –write-recovery-conf	最低限のrecovery.confを作成。必要に応じてrecovery.confを加筆修正。
-r <rate> –max-rate=<rate>	サーバから転送されるデータの最大転送速度を指定。 運用中にpg_basebackupを実行する場合に使用を検討する。 転送速度を抑える事で、マスタに対する影響を制限する事を目的とする。
-P	進行状況報告を有効化。 pg_basebackup処理中におおよその進行状況を報告する。 運用中に実行した場合、データベースクラスタのサイズが増加して進行状況が100%を超える場合がある。
-v	冗長モードを有効化。 進行状況報告も有効な場合、現在処理中のファイル名を出力。

pg_basebackupでレプリケーションスロットが使用できます。 WAL収集方式に stream を指定する事でWALをほぼ確保できますが、スロットを指定する事でより確実になります。 スロットを使用する運用であれば、この段階で作成するのが有力です。

■フェイルバック手順

pg_basebackupにスロットを指定する場合を記載します。

$ rm -rf $PGDATA/*

$ 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 |

$ 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

• recovery_target_timelineパラメータ
• primary_conninfパラメータにapplication_nameを追加（任意／デフォルトはwalreceiver）

$ 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

• synchronous_standby_namesパラメータの無効化
• pg_statsinfoの無効化(有効化されている場合）

$ vi $PGDATA/postgresql.conf

[編集前]
synchronous_standby_names = '*'
shared_preload_libraries = 'pg_stat_statements,pg_statsinfo'

[編集後]
synchronous_standby_names = ''
shared_preload_libraries = ''

$ pg_ctl start

$ 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                --- アクティブ

$ vi $PGDATA/postgresql.conf

[編集前]
synchronous_standby_names = ''

[編集後]
synchronous_standby_names = '*'

$ pg_ctl reload

$ 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                 --- 同期

これにて、以下の構成に復旧しました。

• レプリケーションスロット使用
• 同期式レプリケーション構成

4.4.2.3. スイッチオーバ¶

スイッチオーバについて記載します。

■スイッチオーバ手順

計画停止におけるマスタ/スレーブの切り替え手順です。 pg_basebackupやpg_rewindが不要であるためシンプルな手順です。

$ pg_ctl stop -m fast

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

$ pg_ctl promote

以降の手順はフェイルオーバの場合と同様であるため省略します。

• 3. レプリケーションスロットの作成
• 4. recovery.confの作成
• 5. 旧マスタのpostgresql.confの修正
• 6. 新スレーブの起動
• 7. 新マスタでのレプリケーション確認
• 8. レプリケーション方式を同期式に変更

$ psql

=# SELECT pg_drop_replication_slot('slot_server2');
pg_create_physical_replication_slot
-------------------------------------

(1 row)

=# SELECT slot_name FROM pg_replication_slots ;
(0 rows)

以上でスイッチオーバが完了しました。

4.4.2.4. スイッチバック¶

pg_rewindを使用したスイッチバックについて記載します。

pg_rewindはタイムラインのずれたレプリケーションを再同期させる機能です。 実行後、ターゲットクラスタはソースクラスタと置き換えられた状態になります。 そのためpg_rewind後の操作は、通常のフェイルオーバ時と同じです。 タイムラインの分岐点からソースクラスタのWALを適用するため、更新量が少なければpg_basebackによる複製より高速です。 これによりフェイルオーバ時、旧マスタを容易に新スレーブとして起動させることができます。

■関連パラメータ

pg_rewindに必要な設定を記載します。

■pg_rewindコマンド

pg_rewindコマンドのの主なオプションは次の通りです。

表 4.20 pg_rewindのオプション¶

オプション	内容
D <ターゲットクラスタ>	pg_rewindを実行し、ソースクラスタの内容に置き換えるクラスタを指定する。
source-server=”<ソースクラスタ>”	同期対象であるソースクラスタを指定します。主に次の接続文字列を使用します。 host：ソースクラスタのホスト名またはIPアドレス port：ソースクラスタのポート番号 dbname：ソースクラスタの接続先データベース名 user：ソースクラスタの接続先ユーザ
P	進行状況をレポートとして表示する。

■スイッチバック手順

※事前にマスタ/スレーブで(1) 関連パラメータの設定がされていることを前提とします。

$ pg_ctl start -w
$ pg_ctl stop -m fast -w

$ 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!

$ vi $PGDATA/recovery.conf

[編集後]
standby_mode = 'on'
primary_conninfo = 'host=server2 port=5432 user=rep_user'
recovery_target_timeline = 'latest'

[新マスタ]

$ 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

■pg_rewind使用時の注意点

• 正常停止が必要

  pg_rewindを実行するデータベースクラスタは正常終了しなければいけません。

  物理障害等により正常停止できない場合、pg_rewindは使用できません。pg_basebackupを使用します。

• 同一タイムラインの場合は実施不可

  pg_promoteを実行せずに旧スレーブを新マスタにした場合、新マスタのタイムラインIDは変わらないため、

  新マスタと旧マスタのタイムラインIDは同じ状態です。

  この場合は、pg_rewindは実行できません。

• 実行時期と所要時間の関係

  pg_rewindによるフェイルバックの所要時間は２つの要素から構成されます。

  
  

  Step1.　pg_rewindによる巻き戻し （旧マスタのWALを使用）

  Step2.　WAL適用による追い付き （新マスタのWALを使用）

  
  

  新マスタで大量更新がある場合は、Step1は短時間で終了してもStep2で時間がかかります。

  結果として、pg_basebackupの方が効率が良い場合もあり得ます。

  また新マスタ昇格時のWALが削除されている場合は、後述するようにStep2でエラーとなる可能性もあります。その場合はpg_basebackupが必要となります。

  pg_rewindはフェイルオーバー後、あまり時間を置かずに実行する事がポイントです。

• 旧マスタのWAL削除

  旧マスタの巻き戻しに必要な旧マスタのWALが削除されているいる場合、pg_rewindは失敗します。

  例えば旧マスタが障害により大量更新の途中で異常終了した場合などに発生します。

  pg_rewind実行時に次のようなエラーが発生します。

  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_rewindが成功するかどうかは検証(dry-runオプション)にて事前に確認する事ができます。

$ 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削除）は検知できません。
| 検証の仕様について認識下さい。

• 新マスタのWAL削除

  pg_rewind後、新スレーブは新マスタのWALを適用することで、新マスタと同期します。

  新マスタに昇格時のWALファイルが残っていない場合、新スレーブは追い付きができず、次のエラーがサーバログに出力され続けます。

  対策としてレプリケーションスロットの有効化が有力ですが、新マスタのWAL領域の枯渇にご注意下さい。

  ERROR:  requested WAL segment 0000000D00000000000000F3 has already been removed
  

• タイムラインの巻き戻し

  pg_rewindはPostgreSQL9.6からタイムラインの巻き戻しができるよになっています。

  これによりスプリットブレインが発生しても、新マスタをスレーブに戻すことが可能です。

• pg_rewindが不要な場合

  pg_rewindはターゲットとソースクラスタのタイムラインIDが分岐した場合に実行が必要です。

  そのためタイムラインが枝分かれしなかった場合、pg_rewindを実行する必要はありません。

  例えばpg_rewind実行時に次のようなメッセージが出た場合、pg_rewindは実行せずに、以降の操作を継続します。

  servers diverged at WAL position 0/503A428 on timeline 2
  no rewind required
  

4.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をキーインする等、意図的にキャンセルしない限り、応答が返ってきません。

$ pg_ctl -w -m immediate stop

$ pg_isready -h server2 -U postgres -d postgres
    server2:5432 - no response

$ vi $PGDATA/postgresql.conf

[変更前]
synchronous_standby_names = '*'

[変更後]
synchronous_standby_names = ''

$ pg_ctl reload

$ psql -At -c "SELECT sync_state FROM pg_stat_replication;"
async

これでマスタが更新処理が可能な状態に復旧しました。 ただしシングル状態であるため、フェイルオーバと同様の作業を行います。

5.1.1.1. BDRとは¶

BDR(Bi-Directional Replication)は2ndQuadrant社によって開発された、オープンソース（PostgreSQL License）のマルチマスタ・レプリケーションシステムです。 双方向の非同期論理レプリケーションを使用し、地理的に分散したクラスタで使用するために設計されています。

5.1.1.2. ユースケース¶

BDRは以下のようなケースで有用です。

1. 遠隔地や高レイテンシ環境でクラスタを構成している場合。
2. 各ノードが書き込み処理を実施する場合。
3. クラスタ間でデータが非同期であることを許容できる場合。

例としては以下のようにレスポンスを向上させるために各地でアプリケーション及びDBを動作させるようなケースが考えられます。

図 5.1 BDRユースケース

5.1.1.3. メカニズム¶

BDRでは「Logical Decoding」により、WALから論理的な変更点を抽出し、 各ノードで適用することで双方向レプリケーションを実現しています。 （Logical Decoding及びWALの送受信はバックグラウンドワーカープロセスが実施します）

従来のトリガーを用いた双方向レプリケーションの場合、 下図のように書き込みが余分に発生（変更記録、変更反映）してしまいます。

図 5.2 トリガベースメカニズム

一方、BDRでは余分な書き込みが発生せずパフォーマンス的に有利となっています。

図 5.3 BDRメカニズム

利用されているPostgreSQLのメカニズムの一覧です。

5.1.1.4. 整合性¶

マルチマスタ構成を取る場合、各ノードが持つ情報に不整合が発生しないように管理する仕組みが必要となります。 BDRでは結果整合性（eventually consistent）と呼ばれる一貫性モデルを採用し、整合性を確保します。

• デフォルトでは競合が発生した場合、最後の更新処理が適用されます。（last_update_wins）
• 競合結果はテーブル「bdr.bdr_conflict_history」で確認可能です。

図 5.4 結果整合性

5.1.1.5. シーケンス¶

BDRでは一意な値を払い出すために、「グローバルシーケンス」、 「ステップ/オフセットシーケンス」という2つの手法を紹介しています。

1. グローバルシーケンス

グローバルシーケンスでは、各ノードに予め値の塊（chunk）を一定数ずつ割り振ることで値の重複を回避しています。

• chunkを消費するとvoting処理（下記参照）を行い、新たにchunkを割り振ります。
• グローバルシーケンスは廃止予定です。（下記のステップ/オフセットシーケンスを推奨）

voting処理

“chunk”と呼ばれるシーケンス番号のまとまりをノードに割り当てる処理をvoting処理と呼びます。 “chunk”が複数のノードに割り当てられないことを確認するため、ノード間で投票処理が行われており、正常に機能させるためには奇数台のノードが必要です。 過半数のノードが停止している場合は、投票処理にて過半数に到達しなくなるため、新しい”chunk”がノードに割り当てられません。 そして、”chunk”が枯渇した場合、nextvalの実行に失敗してしまいます。

図 5.5 グローバルシーケンス

2. ステップ/オフセットシーケンス

ステップ/オフセットシーケンスでは、各ノードで通常のPostgreSQLシーケンスを使用します。 各シーケンスを同じ量だけ増分されるようにし、値が重複しないように設定します。

• 設計時には注意が必要です。
• 増分する値をある程度大きく取らないとノードの追加に対応できません。（例： 10の増分であればノード数の追加は10台まで）

図 5.6 ステップ/オフセットシーケンス

5.1.1.6. 比較表¶

類似機能及び製品との机上比較の結果です。

https://2ndquadrant.com/en/resources/bdr/

5.1.1.7. サポート¶

サポートについては以下が存在します。

5.4.1.1. 概要¶

PostgreSQL BDR (Bi-Directional Replication)を利用したマルチマスタ環境の構築手順について確認します。

また、マルチマスタ環境構築後、各ノードに対して更新が実行可能かを確認します。

http://bdr-project.org/docs/next/installation-packages.html#INSTALLATION-PACKAGES-REDHAT

こちらの環境 で検証を実施しました。

5.4.1.2. 対象試験サーバ¶

5.4.1.3. 事前確認¶

1. yumが利用可能な状態であること

• パッケージを入手する際にyumを使用

設定手順

指定がない部分は、node1・node2両方で実施します。

1. 検証環境準備

BDR検証を実施するための環境を準備します。

ssh接続を用いて、該当環境へ接続
ユーザ: root
パスワード: xxxxxxx

2. hostsの設定

DNSの名前解決のために各サーバのホスト名を設定します。

# vi /etc/hosts
[下記をファイル末尾に追加]
192.168.0.10 node1
192.168.0.12 node2

3. 関連ポートの開放

PostgreSQL間のBDR接続のために5432ポートの開放をします。

# firewall-cmd --permanent --add-port=5432/tcp
# firewall-cmd --reload

以下のコマンドで確認します。

# firewall-cmd --list-ports
5432/tcp

4. BDRレポジトリの登録

BDRレポジトリ用のRPMをインストールします。

# RHEL/CentOS users only:
# yum install http://packages.2ndquadrant.com/postgresql-bdr94-2ndquadrant/yum-repo-rpms/postgresql-bdr94-2ndquadrant-redhat-latest.noarch.rpm

以下のコマンドでインストール済み一覧を確認します。

# yum list installed postgresql-bdr94-2ndquadrant-redhat.noarch 0:1.0-3
[省略]
インストール済みパッケージ
  postgresql-bdr94-2ndquadrant-redhat.noarch            1.0-3            installed

5. BDRインストール

登録したBDRレポジトリからBDRをインストールします。

# 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. データベースクラスタ作成

BDR検証用に新規でデータベースクラスタを作成します。

$ mkdir -p $HOME/2ndquadrant_bdr/
$ initdb -D $HOME/2ndquadrant_bdr/data -A trust -U postgres --no-locale

8. BDRのパラメータ設定(postgresql.conf)

BDRのパラメータ設定(postgresql.conf)をします。

$ 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. BDRのクライアント認証設定(pg_hba.conf)

BDRのクライアント認証設定(pg_hba.conf)をします。

$ 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. PostgreSQL起動

設定が環境しましたらPostgreSQLを起動します。

起動時にBDRのバックグランドワーカの登録メッセージが出力される事を確認します。

$ 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"に現れます。

以下のコマンドでPostgreSQLの起動状況を確認します。

$ pg_ctl status
pg_ctl: サーバが動作中です(PID: 10948)
/usr/pgsql-9.4/bin/postgres

11. データベース作成

BDRの動作確認用のデータベースを作成します。

$ createdb bdrtest

以下のコマンドで作成したデータベースへの接続を確認します。

$ psql bdrtest
psql (9.4.9)
"help" でヘルプを表示します.

bdrtest=# \q
-bash-4.2$

12. BDRモジュール登録

BDRに必要な拡張モジュールを登録します。

$ 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. BDRグループ作成

node1でBDRグループを作成するため、「bdr.bdr_group_create」関数を実行します。

$ psql -U postgres bdrtest
=# SELECT bdr.bdr_group_create(
     local_node_name := 'node1',
     node_external_dsn := 'host=node1 port=5432 dbname=bdrtest');

グループが作成されたことを確認するため、「bdr.bdr_node_join_wait_for_ready」関数を実行します。

=# SELECT bdr.bdr_node_join_wait_for_ready();
 bdr_node_join_wait_for_ready
------------------------------

(1 行)

14. ノード登録

node2でノード登録するために、「bdr.bdr_group_join」関数を実行します。

$ 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'
   );

ノードが登録されたことを確認するため、「bdr.bdr_node_join_wait_for_ready」関数を実行します。

=# SELECT bdr.bdr_node_join_wait_for_ready();
  bdr_node_join_wait_for_ready
 ------------------------------

 (1 行)

15. ノード状態の確認

ノードの状態を「bdr.bdr_nodes」テーブルの情報から確認します。

$ 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. 簡易動作検証(node1)

node1でBDRの簡易動作検証を実施します。

node1で作成されたテーブルとデータがnode2にレプリケーションされていることを確認します。

$ psql -U postgres bdrtest
=# CREATE TABLE t1bdr (c1 INT, PRIMARY KEY (c1));
=# INSERT INTO t1bdr VALUES (1);
=# INSERT INTO t1bdr VALUES (2);

17. 簡易動作検証(node2)

node2でBDRの簡易動作検証の結果を確認します。

node1と同じテーブルとデータが表示できていれば、構築したBDR環境に問題はありません。

node1と同様の簡易動作検証をnode2からも実施して下さい。

$ psql -U postgres bdrtest
=# SELECT * FROM t1bdr;
 c1
----
  1
  2
(2 行)
=# INSERT INTO t1bdr VALUES (3);

5.5.1.1. 検証の目的¶

ノードの追加/切り離しをオンライン(DB停止)なしで実行できるか否かを確認します。

5.5.1.2. 検証内容¶

本検証では、2台で構成されたBDRクラスタに対して、下記を実施しました。

1. ノード切り離し
2. ノード追加

「ノード切り離し」および「ノード追加」時に他ノード(上図のnode1)にトランザクションを実行し、トランザクションにエラーが発生するか否かを確認しました。

5.5.1.3. 検証環境¶

こちらの環境 で検証を実施しました。

5.5.1.4. 検証手順¶

5.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で終了しました

ノード追加にはプロセスの再起動は必要ありませんが、トランザクションの停止が必要でした。

5.5.2.1. 検証の目的¶

BDRに実装されたグローバルシーケンスの利用方法について確認します。 グルーバルシーケンスを利用することでノード毎に払い出されるシーケンス番号を独立させ、ノード間のシーケンス番号の競合を防ぐことができるか否かを確認します。

5.5.2.2. 検証環境¶

こちらの環境 で検証を実施しました。

5.5.2.3. 検証手順¶

1. 初期状態

BDRの各ノード間のレプリケーションが正常に動作していることを「bdr.bdr_nodes」テーブルを用いて確認します。

(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. グローバルシーケンス動作確認

node1のデータベースに接続し、serial型を列に持つgstestテーブルを作成します。 serial型を持つテーブルを作成すると、自動的にシーケンスが作成されます。 グローバルシーケンス作成のため、テーブル作成時に「SET LOCAL default_sequenceam = ‘bdr’;」を指定する必要があります。

(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. グルーバルシーケンス作成確認

node1およびnode2のデータベースに接続し、グローバルシーケンスが作成されたことを確認します。

(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

※ 下記のSQLで詳細情報(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. グローバルシーケンス利用

node1のデータベースに接続し、1件のデータを投入します。

(node1のデータベースに接続)
=# INSERT INTO gstest(hogehoge) VALUES ('test1');
INSERT 0 1

node2のデータベースに接続し、1件のデータを投入します。

(node2のデータベースに接続)
=# INSERT INTO gstest(hogehoge) VALUES ('test2');
INSERT 0 1

5. シーケンス値の競合有無確認

node1およびnode2のシーケンスの値に競合が発生していないことを確認します。 本検証では、node1に2が割り当てられ、node2には100001が割り当てられました。

(node1のデータベースに接続)
=# SELECT * FROM gstest;
   id   | hogehoge
--------+----------
      2 | test1                                    <-- node1には2のシーケンスが割り当てられる
 100001 | test2                                    <-- node2には100001のシーケンスが割り当てられる
(2 rows)

6. グローバルシーケンス利用

node1に200,000件のデータを投入し、シーケンスの値が100,000を超えた場合、node2の100,001と競合しないか否かを確認しました。

(node1において実施)
$ cat /tmp/gs.sh
#!/bin/sh

for i in `seq 1 200000`
  do
      psql -d bdrtest -c "INSERT into gstest(hogehoge) VALUES ('test${i}');"
      done
$ sh /tmp/gs.sh
INSERT 0 1
[省略]

7. グローバルの状態確認

node1のシーケンスが100,000を利用したのち、node1に割り振られた値を確認しました。

(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

5.5.2.4. 検証結果¶

グローバルシーケンスを用いることでノード間のシーケンス番号の競合を抑止できることが確認できました。 グルーバルシーケンスについてはいくつかの制限事項がマニュアルに記載されておりますので、注意して下さい。

1. 1（デフォルト値）のINCREMENTだけがサポートされています。
2. MINVALUEとMAXVALUEはデフォルトでロックされており、変更することはできません。
3. CACHE指令はサポートされていません。

• http://bdr-project.org/docs/1.0/global-sequence-limitations.html

5.5.3.1. 検証目的¶

テーブル単位での選択的レプリケーションの可否を確認します。 選択的レプリケーションの可否は互いのデータベース間での任意のテーブルのデータ状態を元に判断します。 また、選択的レプリケーションを実現する際の変更手順を明確にする事を目的とします。

5.5.3.2. 検証内容¶

• Replication Set : レプリケーション対象とするテーブルの論理集合を表し、ノード毎に設定可能
• http://bdr-project.org/docs/stable/replication-sets.html

選択的レプリケーション検証内容

• 双方向レプリケーションの動作確認
• 選択的レプリケーション(node1)の動作確認
• 選択的レプリケーション(node2)の動作確認

5.5.3.3. 検証環境¶

こちらの環境 で検証を実施しました。

5.5.3.4. 検証手順¶

1. 選択的レプリケーション環境構築

選択的レプリケーションの動作確認の為に、下記の検証環境を構築します。

(1)データベース作成

テストを実施する為のデータベースを作成します。

(node1,node2において実施)
=# CREATE DATABASE rep_test;

(2)BDRの有効化

作成したデータベース上でBDR機能の有効化を実施します。

(node1,node2のデータベースにおいて実施)
=# CREATE EXTENSION btree_gist;
=# CREATE EXTENSION bdr;

(3)BDRグループの作成

BDRノードのクラスタに「bdr.bdr_group_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)ノード登録(node2)

既存のBDRノードのクラスタに「bdr.bdr_group_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)ノードの状態確認

BDRグループ内のノードのメンバシップを「bdr.bdr_nodes」を利用して確認します。

(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)レプリケーションセットの確認

指定したノードのレプリケーションセットを「bdr.connection_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)作成

テストを実施する為のテーブル(all_rep)を作成します。

(node1のデータベースに接続)
=# CREATE TABLE all_rep(id int, PRIMARY KEY(id));
CREATE TABLE

(2)レプリケーションセット確認

指定したテーブルのレプリケーションセットを「bdr.connection_get_replication_sets」を利用して確認します。

(node1のデータベースに接続)
=# SELECT bdr.table_get_replication_sets('all_rep');
-[ RECORD 1 ]--------------+--------------
table_get_replication_sets | {default,all}    <-- defaultが含まれていること

(3)データ追加

node1のテーブルにデータを挿入します。

(node1のデータベースに接続)
=# INSERT INTO all_rep VALUES (1);
INSERT 0 1

(4)レプリケーション確認

node2のテーブルにもデータがレプリケーションされている事を確認します。

(node2のデータベースに接続)
=# SELECT id FROM all_rep;
 id
----
1                                             <-- データがレプリケーションされていること
(1 row)

3. レプリケーション対象外テーブルの作成(node1のみ)

次に、選択的レプリケーション動作を確認します。 指定したテーブルではレプリケーション動作が行われなくなりますので、任意のテーブルのみレプリケーションさせる事が出来ます。

(1)テーブル(node1_only)の作成

テストを実施する為のテーブル(node1_only)を作成します。

(node1のデータベースに接続)
=# CREATE TABLE node1_only(id int, PRIMARY KEY(id));
CREATE TABLE

(2)レプリケーションセット変更

指定したテーブルのレプリケーションセットを「bdr.table_set_replication_sets」を利用して’node1’に設定し、レプリケーション対象を’node1’のみにします。 設定したレプリケーションセットを確認するには、「bdr.table_get_replication_sets」を利用します。

(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)データ追加

node1のテーブルにデータを挿入します。

(node1のデータベースに接続)
=# INSERT INTO node1_only VALUES (1);
INSERT 0 1

(4)レプリケーション確認

node2のテーブルにはデータがレプリケーションされていない事を確認します。

(node2のデータベースに接続)
=# SELECT id FROM node1_only;
 id
----                                          <-- レプリケーションされていないこと
(0 行)

4. レプリケーション対象外テーブルの作成(node2のみ)

同様に、もう一方からの選択的レプリケーション動作も確認します。

(1)テーブル(node2_only)の作成

テストを実施する為のテーブル(node2_only)を作成します。

(node2のデータベースに接続)
=# CREATE TABLE node2_only(id int, PRIMARY KEY(id));
CREATE TABLE

(2)レプリケーションセット変更

指定したテーブルのレプリケーションセットを「bdr.table_set_replication_sets」を利用して’node2’に設定し、レプリケーション対象を’node2’のみにします。 設定したレプリケーションセットを確認するには、「bdr.table_get_replication_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)データ追加

node2のテーブルにデータを挿入します。

(node2のデータベースに接続)
=# INSERT INTO node2_only VALUES (1);
INSERT 0 1

(4)レプリケーション確認

node1のテーブルにはデータがレプリケーションされていない事を確認します。

(node1のデータベースに接続)
=# SELECT id FROM node2_only;
 id
----                                          <-- レプリケーションされていないこと
(0 行)

5.5.3.5. 検証結果¶

今回の検証結果では、レプリケーションセットに任意のノードを指定する事で選択的レプリケーションが実現される事が確認出来ました。 また、選択的レプリケーション実現の為の設定変更手順についても確認出来ました。

ただし、レプリケーションセットにテーブルを追加する場合は、過去のデータまで反映しないので、手動で同期が必要です。

選択的レプリケーションの主な注意事項は下記になります。

• http://bdr-project.org/docs/1.0/replication-sets-concepts.html
• http://bdr-project.org/docs/1.0/replication-sets-tables.html

1. DDLはレプリケーションセットの設定に関係なく常にすべてのノードに影響します。
2. TRUNCATEは常にレプリケートされます。望ましくない場合は、DELETEを利用する必要があります。
3. レプリケーションセットの設定は、初期ノード追加(結合時)にはテーブルデータのコピーに影響を与えません。
4. レプリケーションセットにテーブルを追加した場合も以前のデータ内容はノードに同期されません。 通常、管理者は、テーブルをレプリケーションセットに追加した後、手動で同期する必要があります。

5.5.4.1. 検証目的¶

BDRはマルチマスタ構成する各ノードに対して、参照処理と更新処理を実行することが可能です。 複数ノードに対して同時に更新処理が実施された場合、各ノードに対して実行された更新処理が競合する事象が発生する場合があります。

BDR競合が発生した場合、最後の更新処理が適用されます(last_update_wins)。また、競合結果はテーブル「bdr.bdr_conflict_history」で確認可能です。

• 「bdr.bdr_conflict_history」に格納される情報については下記をご参照下さい。
• http://bdr-project.org/docs/stable/conflicts-types.html

下記を明らかにするため検証を実施しました。

1. 更新処理が競合した場合の挙動
2. 競合発生時にシステムカタログに記録される情報

5.5.4.2. 検証内容¶

BDR動作検証概要図

下表の競合発生時の動作を検証しました。

5.5.4.3. 検証環境¶

こちらの環境 で検証を実施しました。

5.5.4.4. 検証手順¶

1. 競合ログオプションの有効化確認

競合発生時にテーブル「bdr.bdr_conflict_history」に情報を記録するため、bdr.log_conflicts_to_tableパラメータがonに設定されていることを確認します。

※ offになっていたら、postgresql.confに「bdr.log_conflicts_to_table=on」を追記し、再読み込みを実行して下さい。

node1/node2のデータベースに接続し、パラメータを確認するために下記コマンドを実行します。

(node1にて実施)
=# SHOW bdr.log_conflicts_to_table;
bdr.log_conflicts_to_table
----------------------------
on
(1 行)

(node2にて実施)
=# SHOW bdr.log_conflicts_to_table;
bdr.log_conflicts_to_table
----------------------------
on
(1 行)

2. レプリケーション反映時間の設定

ネットワーク遅延などの実際の環境を想定して検証を行うため、bdr.default_apply_delayパラメータを設定します。 このパラメータを設定する事でレプリケーションの反映を設定した時間(ミリ秒)遅らせる事が出来ます。

※ 今回の検証では、競合の発生を確認しやすくするために”2s”を設定しています。

node1/node2のデータベースに接続し、パラメータを確認するために下記コマンドを実行します。

(node1にて実施)
=# SHOW bdr.default_apply_delay;
bdr.default_apply_delay
----------------------------
2s
(1 行)

(node2にて実施)
=# SHOW bdr.default_apply_delay;
bdr.default_apply_delay
----------------------------
2s
(1 行)

3. BDRの各ノード状態確認

BDRの各ノード間のレプリケーションが正常に動作していることを「bdr.bdr_nodes」を利用して確認します。

(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. 検証用テーブルとデータの作成

pgbebchを利用して、検証時に利用するテーブルとデータを作成します。

(node1にて実施)
$ pgbench -i -s 10 bdrtest
$ psql -h node1 -d bdrtest

=# INSERT INTO pgbench_accounts (aid, bid, abalance) VALUES (1000001, 1, 0);