PostgreSQL9.1同期レプリケーションとPacemakerによる高可用クラスタ化の紹介

PostgreSQL9.1 同期レプリケーションと
Pacemaker による高可用クラスタ化の紹介

PostgreSQL Conference 2012

藤井雅雄 / 松尾隆利

目次
PostgreSQL9.1同期レプリケーション

同期レプリケーションのHAクラスタ化
￭レプリケーション構成のHAクラスタ化３大機能
￭基本動作
￭運用
￭ HAクラスタ化まとめ

Copyright(c)2012 NTT, Inc. All Rights Reserved. 2

PostgreSQL9.1同期レプリケーション

藤井雅雄
NTT OSSセンタ

Copyright(c)2012 NTT, Inc. All Rights Reserved. PostgreSQL Conference 2012 @ Japan

自己紹介
藤井雅雄 (@fujii_masao)

NTT OSSセンタ(NTTグループ各社に対してOSS製品のサポー
トを提供している組織)でPostgreSQLのサポート

PostgreSQL本体の開発
￭ v9.0: ストリーミング・レプリケーション
￭ v9.1: 同期レプリケーション(Simonさんと共同開発)
￭ v9.2: カスケードレプリケーション


レプリケーションとは?
複数のサーバにデータベースを自動的に複製する機能

用途1: 高可用・データ保護
￭ 1台が故障しても、データを失うことなく別サーバが処理を引き継げる
￭システム全体としてデータベースサービスが停止するのを回避できる

用途2: 負荷分散
￭ SQL実行の負荷を複数のサーバに分散できる
￭負荷が一箇所に集中しないので、システム全体として性能向上できる

高可用・負荷分散
クライアントクライアント
データ保護

SQL SQL SQL

DBサーバ DBサーバ


PostgreSQL本体のレプリケーション機能
バージョン9.0からPostgreSQL本体組み込みのレプリケー
ション機能を利用可能

以降、PG9.0レプリケーションの特徴の復習
￭シングルマスタ/マルチスレーブ構成
￭ログシッピング
￭非同期レプリケーション


【特徴1】シングルマスタ/マルチスレーブ構成
マスタは、更新SQLと参照SQLを実行可能
スレーブは、参照SQLのみ実行可能

参照系処理のスケールアウトに利用可能

クライアント
マルチスレーブ
参照SQL
更新/参照SQL

変更
シングルマスタ


【特徴2】ログシッピング
データベースの変更情報としてWALをマスタからスレーブに
転送
転送されたWALをリカバリすることで、スレーブはデータ
ベースを複製

クライアント
更新SQL

マスタスレーブ
WAL リカバリ

WAL WAL


【特徴3】非同期レプリケーション
トランザクションは、WALがマスタに書き込まれた時点で完了
￭スレーブへのWALの転送やリカバリは、トランザクションの完了とは非同期的
に実行

レプリケーションの性能オーバーヘッドは小さい
￭トランザクションは、レプリケーションの完了を待つ必要がないため

クライアント
1. COMMIT
3. 成功
6. リカバリ
4. WALの転送

2. WALの同期書き込み 5. WALの同期書き込み


【特徴3】非同期レプリケーション
フェイルオーバ時にCOMMIT済のデータを失う可能性がある
￭ COMMIT成功時、そのトランザクションのWALがスレーブに届いている保証はないため
高可用・データ保護の用途には利用しにくい

スレーブで参照SQLを実行したとき、古いデータが見える可能性がある
￭ COMMIT成功時、そのトランザクションのWALがリカバリされている保証はないため
最新データをすぐに見る必要のないバッチなどの負荷分散に有効

クライアント
1. COMMIT
3. 成功
6. リカバリ
4. WALの転送



同期レプリケーション
バージョン9.1からレプリケーションのモードを非同期、同期
から選択可能

トランザクションは、WALがマスタとスレーブの両方に書き
込まれた時点で完了
￭スレーブへのWAL転送は同期的だが、リカバリは非同期的に実行

クライアント
1. COMMIT

6. 成功
7. リカバリ
3. WALの転送

5. 応答


同期レプリケーションの性能
レプリケーションの性能オーバーヘッドは大きい
￭トランザクションは、WALの転送、スレーブによるWALの同期書き込みを待たなければ
ならないため
￭両系間のN/W性能やスレーブのディスク性能が低いとオーバーヘッドは増大
￭ N/Wに1000BASE-T(125MB/s)を使えば基本的には十分。他のN/Wと混ぜないこと
￭スレーブのディスクI/Oの方がボトルネックになりやすい
￭スレーブだけ、仮想環境上に配置したり、スペックが低いH/Wを使ったりしないこと
￭基本的には、投資するならN/Wよりストレージ

クライアント
1. COMMIT

6. 成功
7. リカバリ
3. WALの転送

5. 応答


同期レプリケーションのデータ保護レベル
フェイルオーバ時にCOMMIT済のデータが失われることはない
￭ COMMIT成功時、そのトランザクションのWALがマスタとスレーブ両方のディスクに存
在することが保証されるため
￭ COMMIT済のデータが失われるのは、両系のディスクが破壊されたという稀な場合のみ
高可用・データ保護の用途に利用しやすい

スレーブで参照SQLを実行したとき、古いデータが見える可能性がある
￭「同期レプリケーション = COMMIT済のデータがすぐにスレーブで参照できる」ではない
ことに注意!

クライアント
1. COMMIT

6. 成功
7. リカバリ
3. WALの転送

5. 応答


同期レプリケーションの設定
スレーブごとにレプリケーションのモードを設定
￭同期レプリケーションを行うスレーブの名前をsynchronous_standby_namesに設定
￭同期レプリケーションを実行できるスレーブは同時に1台のみ
￭より先頭に設定されている名前のスレーブが優先的に同期レプリケーションを行う

postgresql.conf
synchronous_standby_names = ‘tokyo, osaka’

マスタ非同期
同期のtokyoが故障したら自動的に
同期に昇格
その後、tokyoが復活したら自動的に
同期非同期非同期に降格。tokyoが同期になる

スレーブ

tokyo nagoya osaka

recovery.conf
primary_conninfo = ‘application_name=“tokyo”’


同期レプリケーションの監視
pg_stat_replicationビューからスレーブごとにレプリケーション情報を取得可能
￭ビューを確認できるのはマスタのみ。スレーブではこのビューは常に空

=# SELECT * FROM pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
procpid | 26531
usesysid | 10
usename | postgres ←スレーブがレプリケーション接続に使ったユーザの名前
application_name | tokyo ←スレーブの名前
client_addr | 192.168.1.2 ←スレーブのIPアドレス
client_hostname |
client_port | 39654 ←スレーブのポート番号
backend_start | 2012-02-01 18:54:49.429459+09 ←レプリケーションの開始時刻
state | streaming ←レプリケーションの状態
startup: 接続中、catchup: スレーブ追いつき途中、
streaming: スレーブ追いつき済
sent_location | 0/406E7CC ←マスタがどこまでWALを送信したかの位置
write_location | 0/406E7CC ←スレーブがどこまでWALを受信したかの位置
flush_location | 0/406E7CC ←スレーブがどこまでWALを同期書き込みしたかの位置
replay_location | 0/406E1B0 ←スレーブがどこまでWALをリカバリしたかの位置
sync_priority |1 ←同期レプリケーションの優先度
0: 非同期、1～?: 同期(値が小さいほど優先度高)
sync_state | sync ←スレーブのレプリケーションモード
async: 非同期、sync: 同期、
potential: 非同期だが、同期に昇格するかも


トランザクション単位のデータ保護レベルの設定
トランザクションごとにデータ保護レベルを細かく制御
￭ SET synchronous_commit TO xxx

トランザクションが
スレーブの synchronous_commit WAL書き込みを待つか?
モードの設定値
on 待つ待つ
同期 local 待つ
off
on 待つ
非同期 local 待つ
off

トランザクションの重要度に応じてデータ保護レベルを変更
￭同期レプリケーションのスレーブに対して、
￭お金を扱うトランザクションでは設定値 on で、COMMIT時に両系にWALが存
在することを保証し、データ損失を確実に防ぐ
￭故障時に一部更新結果が消えてもよいトランザクションでは local / off に設
定して性能向上


レプリケーションを継続できないときの挙動
レプリケーションを継続できないのは、マスタとスレーブの2台構成で、以
下の場合
￭スレーブの故障時
￭マスタ/スレーブ間のN/W故障時
￭マスタ故障によるフェイルオーバ発生後

非同期レプリケーション
￭マスタは、単独でトランザクションを処理
￭故障によってトランザクションが停止することはない

スレーブ故障時フェイルオーバ後

マスタスレーブ新マスタ
旧マスタ
レプリケーションレプリケーション
できないできない


同期レプリケーション
￭マスタは、スレーブからの届くことのないレプリケーション完了の応答を待ち
続ける
￭トランザクションは停止する!!

スレーブを故障から復旧させるなどして、再びレプリケーションを行える
ようになったらトランザクション再開
￭復旧にかかる時間だけシステムが停止する

データ保護を最優先するための措置
￭マスタ単独でのトランザクション処理を許すと、そのトランザクションはマス
タのディスクにしか記録されていないため、マスタのディスク故障時に
COMMIT済のデータが消える
￭トランザクションを停止することで、マスタにだけ存在するようなCOMMIT済
データが発生するのを回避

トランザクションを停止させたくないなら、同期レプリケーションのス
レーブを複数台用意
￭別のスレーブが「同期」に自動的に昇格し、そのスレーブにレプリケーションで
きるとトランザクション再開


スレーブを複数台用意できない場合は、手動でスレーブを切
り離し
￭レプリケーションのモードを非同期に設定変更
￭ synchronous_standby_namesの設定値を空にして設定ファイルをリ
ロード(pg_ctl reload)
￭注意: synchronous_commitによる非同期への設定変更では、故障発生
当時に実行中だったトランザクションを再開できないことがあるため、
synchronous_standby_namesを設定変更すること
￭データ損失のリスクがあるため注意すること
￭スレーブ復旧時は、レプリケーションのモードを同期に戻すこと

レプリケーションを継続できないときに、自動的にマスタを
単独稼働させる機能はPostgreSQLにはない
Pacemakerで自動的にそれをやってくれる機能については第
2部で


9.1のレプリケーション関連の機能(同期レプリケーション以外)

pg_basebackup
￭オンライン物理バックアップを取得するコマンド
￭ 9.0以前は、pg_start_backup → rsyncやtarでコピー → pg_stop_backupと面倒

pg_ctl promote
￭スレーブをマスタに昇格させるコマンド
￭ 9.0まではtrigger_fileを作成する必要があったが、9.1からはコマンド1発

リカバリの停止・再開
￭ SELECT pg_xlog_replay_pause() : リカバリを一時停止
￭ SELECT pg_xlog_replay_resume() : リカバリを再開
￭停止するのはスレーブのリカバリであり、WALの転送は停止しないことに注意

hot_standby_feedback
￭スレーブで実行された参照SQLはリカバリと競合する可能性がある
￭例えば、参照SQLがまだ見ているデータをリカバリが削除しようとする場合など
￭競合が発生すると、参照SQLがキャンセルされたり、リカバリが停止したりする
￭最も発生確率の高い競合を発生させなくするパラメータ。onに設定するだけ
￭ただし、スレーブのトランザクション実行状況がマスタでのVACUUMやHOTに影響する

replication_timeout
￭マスタがスレーブの故障を検知するためのタイムアウト
￭ 9.0ではkeepaliveの設定である程度検知できたが、完璧でなかった


PG9.2のレプリケーション新機能
より高速な同期レプリケーション
￭スレーブがWALを受信した(正確にはwrite(2)で書き込んだ)時点で、レプリ
ケーション完了の応答をマスタに返却するモード
￭重い処理である「スレーブでのWALの同期書き込み(fsync)」をマスタは待つ必
要がなくなり、レプリケーションのオーバーヘッドが小さくなる

カスケードレプリケーション
￭スレーブからスレーブにレプリケーション
￭マスタに接続するスレーブ台数を減らし、マスタの負荷を小さくできる
￭非同期のみ

スレーブからのオンライン物理バックアップ
￭ pg_basebackupでマスタからだけでなくスレーブからバックアップを取得
￭マスタに集中していたバックアップの負荷をスレーブに負荷分散できる

pg_receivexlog
￭マスタからWALを受信しディスクに書き続けるツール
￭オペミス対策でWALの二重化などの用途


まとめ
バージョン9.1からレプリケーションのモードを「非同期」と
「同期」から選択可能

レプリケーションのモードはスレーブ単位、トランザクショ
ン単位で設定

レプリケーションの様子はpg_stat_replicationで確認できる

同期レプリケーションはデータ保護を最優先し、レプリケー
ションを継続できないときはトランザクションを停止させる


PostgreSQL同期レプリケーション
+
Pacemaker
による高可用クラスタ化

松尾隆利

Copyright(c)2012 NTT, Inc. All Rights Reserved.

高可用(HA)クラスタ？ Pacemaker?
複数台のサーバーを用意し、壊れた時に他のサーバーでサービスを
引き継ぐことでシステムの可用性(Availability)を高める手段
￭今までのPostgreSQLのHAクラスタ化はActive-Standby (Cold Standby)方式が
主流
￭ Pacemakerは"Linux-HA Japan"コミュニティ提供のオープンソースソフトウェア
￭市販製品では、ClusterPro, LifeKeeper, Red Hat High Availabilityアドオン等

Active Standby フェイルオーバ Active
故障
故障発生
マウントマウント
DBデータ DBデータ


レプリケーション構成のHAクラスタ化３大機能
①フェイルオーバ

Master フェイルオーバ
Master
故障発生
故障
③
同期
Master レプリケーション Slave
古
デ
ー
タ
②同期・非同期の切替の
状
態
管
非同期理
Slave Master レプリケーション
故障発生

故障

DBデータ古
DBデータ


想定している適用箇所
クラスタ化に費用を割けられない
￭ NAS, 共有ディスク, NFSサーバ等が不要

参照クエリを負荷分散したいがSlaveの故障にも備えたい
￭ Slave故障時にMasterで参照クエリを処理させる
• アプリケーションは接続先を意識しなくてよくなる

高負荷時のフェイルオーバ時間を出来る限り短くしたい
￭フェイルオーバ後のクラッシュリカバリが(ほぼ)必要なくなる

某高速ストレージを使いたい
￭ PCI Express接続ストレージではデータを共有できない
￭性能を求めるにはレプリケーション用のネットワークもそれなりの
性能の物を揃える必要あり?


基本構成
サービス提供用LAN

Read/Write Read Only

仮想IP1 仮想IP3
(vip-master) (vip-slave)

レプリケーション用 LAN
PostgreSQL 仮想IP2 PostgreSQL
(Master) (vip-rep)
(Slave)
制御制御

pgsql RA pgsql RA

Pacemaker Pacemaker用LAN
Pacemaker

サーバ#1 サーバ#2

※STONITH用LANの記述は省略(使用推奨)


リソースエージェント(RA)

Pacemakerと制御対象のアプリケーション間を
仲介するプログラムで、主にシェルスクリプトで記述。

既存のPostgreSQL用RAは、
Active-Standby構成に必要な関数
PostgreSQL
(起動(start)・監視(monitor)・停止(stop))を実装

起動監視停止
レプリケーション構成を制御するために
この pgsql RA の機能を拡張 pgsql RA
Pacemaker


基本動作1 : Masterのフェイルオーバ

vip-master

vip-master vip-slave vip-master
vip-master
③ vip-slave
vip-slave

PostgreSQL PostgreSQL 故障
PostgreSQL PostgreSQL
①故障
(Master)
vip-rep
(Slave)
②停止
(Master)
vip-rep vip-rep
(Slave)
⑤ (Master)

pgsql RA pgsql RA pgsql RA pgsql RA
pgsql RA

Pacemaker Pacemaker Pacemaker Pacemaker
Pacemaker

サーバ#1 サーバ#2 サーバ#1
サーバ#2

④
古

① #1のPostgreSQLの故障を検知 ② #1のPostgreSQLを停止
③ #1の仮想IPを#2に付け替え
④ #1のデータが古いことを記録
⑤ #2のPostgreSQLをMasterに昇格


基本動作2 : 同期・非同期の切替

②

vip-slave
③検知 ⑤
vip-master vip-slave vip-master vip-slave

⑦ 非同期
PostgreSQL 同期 PostgreSQL PostgreSQL 故障
PostgreSQL
(Master)
vip-rep
①故障
(Slave) (Master)
vip-rep ④停止
(Slave)

pgsql RA pgsql RA pgsql RA pgsql RA
pgsql RA

Pacemaker Pacemaker Pacemaker Pacemaker

サーバ#1 サーバ#2 サーバ#1 サーバ#2
サーバ#2

⑥
古
古

① Slaveの故障発生 ④ #2のPostgreSQLを停止
② Masterのトランザクション停止 ⑤ #2の仮想IPを#1に付け替え
～レプリケーションのタイムアウト待ち～ ⑥ #2のデータが古いことを記録
③ #1でレプリケーション切断を検知 ⑦ #1のPostgreSQLを非同期に変更
SELECT * from pg_stat_replication → トランザクション再開


TimelineID
PostgreSQLがSlaveからMasterへ昇格した際インクリメントされる数値
TimelineIDが異なるとレプリケーション接続ができない

フェイルオーバ時

フェイルオーバ
Slave→Master
Master レプリケーション Slave

故障

5 5 5 5 6

異なる

TimelineIDをそろえるには
手動でのデータ同期(推奨) or WALアーカイブの共有が必要


運用1: フェイルオーバ後の復旧

vip-master
vip-master
⑥ vip-master

vip-slave vip-slave
vip-slave
vip-slave
vip-slave
vip-slave
⑤ レプリケーション
故障
PostgreSQL PostgreSQL
PostgreSQL PostgreSQL PostgreSQL
①故障復旧 vip-rep
vip-rep vip-rep
(Master) (Master)
(Master)
(Slave) ④ (Slave)
④(Slave) (Master)
③ フラグクリア
pgsql RA
pgsql RA
pgsql RA 故
故 pgsql RA
pgsql RA pgsql RA pgsql RA

Pacemaker
Pacemaker Pacemaker
Pacemaker Pacemaker Pacemaker
サーバ#1
サーバ#1
サーバ#2
サーバ#2 サーバ#1 サーバ#2

② データ同期
古新

① 故障の復旧 ④ #1のPostgreSQLを起動
② #1のデータを#2と同期 ⑤ レプリケーション開始
→ TimelineIDがそろう (手動) ⑥ #2の仮想IP(Slave用)を#1に付け替え
③ #1のPacemaker上の故障
フラグをクリア


PostgreSQLとPacemakerの状態遷移

recovery.conf なしで起動

recovery.conf ありで起動 pg_ctl promote

STOP Slave Master
停止

停止

×
start promote
STOP Slave Master
stop demote

PostgreSQLのMasterは必ずSlaveを経由して起動される
PostgreSQLのMasterは必ずSlaveを経由して起動される
→ Master起動時もTimelineIDがインクリメントされる
→ Master起動時もTimelineIDがインクリメントされる

運用2 : 起動

⑥
③起動 vip-slave vip-slave
vip-slave
vip-master vip-master

PostgreSQL PostgreSQL PostgreSQL
停止 vip-rep 停止停止 vip-rep 停止
(Slave)
(Master) (Master)

②起動 pgsql RA pgsql RA pgsql RA ⑤起動
Pacemaker Pacemaker Pacemaker

サーバ#1 サーバ#2 サーバ#1 サーバ#2

① ④ データ同期
新古新新

① データが新しい方のサーバーを選択 ④ #2のデータを#1と同期
(手動)
② 選択したサーバのPacemakerを起動 → TimelineIDがそろう (手動)
→ Slaveで起動 → Masterに遷移 ⑤ Pacemaker起動
→ TimelineIDがずれる → レプリケーション開始
③ 仮想IPが#1で起動 ⑥ 仮想IP(Slave用)が移動


HAクラスタ化まとめ
３大機能
￭ Masterのフェイルオーバ
￭レプリケーションの同期・非同期の切替
￭データの状態管理

Master起動時やフェイルオーバ時にTimelineIDの
ずれが発生
￭ずれが発生するとレプリケーション接続ができないため、
手動でのデータの同期(推奨) or WALアーカイブの共有が必要


参考
開発中のソースコード (GitHub上)
￭ URL : https://github.com/t-matsuo/resource-agents/
ブランチ : pgsql91 or pg-rex
pgsql91ブランチは今後仕様変更あり
pg-rexブランチのRAをPG-REXプロジェクトからリリース予定
動作確認環境
– CentOS 5.7
– Pacemaker 1.0.11 (Linux-HA Japan提供)
– PostgreSQL 9.1.1

ドキュメントおよび設定例 (GitHubのWiki)
￭ https://github.com/t-matsuo/resource-agents/wiki/

Pacemakerダウンロード・インストール
￭ Linux-HA Japan http://linux-ha.sourceforge.jp/


Question？


PostgreSQL9.1同期レプリケーションとPacemakerによる高可用クラスタ化の紹介

More Related Content

What's hot

Viewers also liked

Similar to PostgreSQL9.1同期レプリケーションとPacemakerによる高可用クラスタ化の紹介

More from Masao Fujii

PostgreSQL9.1同期レプリケーションとPacemakerによる高可用クラスタ化の紹介