PostgreSQL Replication (3) 確認

こんにちは。
グローバルソリューション事業部の後野です。

前回で同期ストリーミングレプリケーションの設定まで完了しましたので、今回は master 、slvae 障害発生時の動作について確認していきたいと思います。

 

pgsql-image

 

 

 

 

 

 

 

 

 

 

切替方法について

  • クライアント側を変更はしたくない
  • pacemaker 等のHAソフトを利用していないこと
  • 障害発生時にDBの状態をみて切替をしたいこと

という3点を踏まえ、IPエイリアスを作成し起動OFFでそこで切り替えられるようにします。

以下ファイルを各サーバで用意しておき、障害検知をトリガーにIPを自動で切り替えてもOKかと。

 

レプリケーション構成後のデータ反映

前回投入したデータ(千葉県郵便番号)は削除します。

そして今回投入するのは、なんと!!!
全都道府県のデータをchibaテーブルへ入れちゃいます。
CSVでのデータサイズ 18MByte

以下 slave側の vmstat 1 結果です。

参考になるかわからないですけど、この程度の量であれば、早いですね。

 

障害テスト

1. master 障害

master(pgrm)を停止します。
※冒頭でIPの件に触れてますが、レプリケーションの動作にあまり関係無いのでその辺は割愛します。
各テストでクライアント側からの接続は問題有りませんでした。

slave(pgrs)を昇格させます

コマンド叩いたら全く待たずに終わりますね、データも少ないですが

 

レコード確認

 

OK

 

データ削除→追加

 

これもOK

master 障害→slave昇格は問題無いですね、個人的にはここら辺は MySQL よりいい気がする

 

2. master 障害復旧

ここで復旧までについては問題が無さそうでしたので、旧master(pgrm) を 新slave(pgrs) へslave として構成しましょう!

新master(pgrs) ですが、recovery.conf は recovery.done になっているのでこのままとします。

postgresql.conf についても synchronous_standby_names を入れて同期モードになると、書き込みに影響出ると思うので、こちらもこのままにします。

 

新slave(pgrm)の設定へ移ります。

PGDATA は削除しましょう

# ここは消す対象を間違えないように気をつけましょう。

削除後にbasebackupを実施します

 

無事、完了です。
recovery.conf には忘れずに、application_name つけましょう!
postgresql.conf も synchronous_standby_names は空なので 新slave(pgrm) 起動しましょう。

無事、非同期でつながりました。

master 側を同期へ変えて reload。

reload なのでそのまま同期へ変わりました。

 

3. master slave 入替

slave障害の確認に移る前に、master slave を戻したいと思います。
ここで気になる部分は basebackup を取り直す必要があるか。
※pgrm → master pgrs → slave へ戻します。

同じ様な内容は省略します。

  1. pgrs postgresql停止
  2. pgrm 昇格
  3. pgrsで recovery.done -> recovery.conf 、同期OFF

では、ここで pgrs を起動します。

おっ!!!sync_stateはちゃんと非同期で見えてる。
けど state が startup …

同期にしてみましょうか。駄目そうなのが目に見えてるけど…。

はい、駄目でした~。

basebackup で戻します。

 

マスタ、スレーブの切り戻しを行う場合は、basebackup し直しが必要ですかね。
本番環境へ入りホスト障害があるとこんなに丁寧に切り替わらないしその方が安全そうですね。

 

4. slave障害

同期状態で slave を停止します。

消えました。

 

この状態でデータ投入します。

止まりますね、idle状態という表現が適切では無い気がしますが、idle状態とします。

 

数分待ちましたが、特にエラー等になるわけでもない為、キャンセル。

※replication_timeout のデフォルト値(60s)を経過してもきれなかったため、対象パラメータはトランザクションとは関係が無いようですね。

キャンセル後ですが、slave 側へ replication は出来なかったが、ローカルへはコミットしています。

この段階で以下の2点が気になりました。

① slave 再開で replication されるか?
② idle 中に非同期へ変更すれば、セッションはそのままのはずなのでコミット可能か?

まず①から確認
slave を起動

master側で同期していることを確認

 

slave側でも同期されていることを確認

ちゃんと同期されてますね、ちょっとしたNW障害等での断は影響無さそうですね。

 

次に②
一旦 東京データを削除、
slave 停止→ 同期対象外で有ることを確認
データを投入し、idle状態になることを確認

このタイミングでmasterを同期モードでリロード

問題無くコミットされますね。
そして非同期のまま slave 起動

ちゃんと slave 側でも東京都データがchibaの中に有りました。

 

 

5. slave障害 非同期モード

同期時の様な idle は無くすぐに書き込めました。

 

雑感

監視については、1対1 replication でも 同期方法により、master slave それぞれ考慮する必要がありますね。
その辺については、クララが誇る安定感抜群の運用チームが適切な運用監視をおこなうので安心です。

ここまで書いたタイミングで 9.4 のリリースはされていませんでした。
ちょっと勝った気持ちの状態で、一旦はこれで気持ちよく postgreSQL replication は完了とします。

 

ここまで読んでいただきありがとうございました。また会える日までさようなら 😉

 

Share on LinkedIn
LINEで送る
Pocket

claraer

claraer