More Related Content Similar to PostgreSQL9.1同期レプリケーションとPacemakerによる高可用クラスタ化の紹介 (20) More from Masao Fujii (10) PostgreSQL9.1同期レプリケーションとPacemakerによる高可用クラスタ化の紹介2. 目次
PostgreSQL9.1同期レプリケーション
同期レプリケーションのHAクラスタ化
■ レプリケーション構成のHAクラスタ化 3大機能
■ 基本動作
■ 運用
■ HAクラスタ化まとめ
Copyright(c)2012 NTT, Inc. All Rights Reserved. 2
3. PostgreSQL9.1同期レプリケーション
藤井 雅雄
NTT OSSセンタ
Copyright(c)2012 NTT, Inc. All Rights Reserved. PostgreSQL Conference 2012 @ Japan
4. 自己紹介
藤井 雅雄 (@fujii_masao)
NTT OSSセンタ(NTTグループ各社に対してOSS製品のサポー
トを提供している組織)でPostgreSQLのサポート
PostgreSQL本体の開発
■ v9.0: ストリーミング・レプリケーション
■ v9.1: 同期レプリケーション(Simonさんと共同開発)
■ v9.2: カスケードレプリケーション
Copyright(c)2012 NTT, Inc. All Rights Reserved. 4
5. レプリケーションとは?
複数のサーバにデータベースを自動的に複製する機能
用途1: 高可用・データ保護
■ 1台が故障しても、データを失うことなく別サーバが処理を引き継げる
■ システム全体としてデータベースサービスが停止するのを回避できる
用途2: 負荷分散
■ SQL実行の負荷を複数のサーバに分散できる
■ 負荷が一箇所に集中しないので、システム全体として性能向上できる
高可用・ 負荷分散
クライアント クライアント
データ保護
SQL SQL SQL
DBサーバ DBサーバ
Copyright(c)2012 NTT, Inc. All Rights Reserved. 5
6. PostgreSQL本体のレプリケーション機能
バージョン9.0からPostgreSQL本体組み込みのレプリケー
ション機能を利用可能
以降、PG9.0レプリケーションの特徴の復習
■ シングルマスタ/マルチスレーブ構成
■ ログシッピング
■ 非同期レプリケーション
Copyright(c)2012 NTT, Inc. All Rights Reserved. 6
7. 【特徴1】シングルマスタ/マルチスレーブ構成
マスタは、更新SQLと参照SQLを実行可能
スレーブは、参照SQLのみ実行可能
参照系処理のスケールアウトに利用可能
クライアント
マルチスレーブ
参照SQL
更新/参照SQL
変更
シングルマスタ
Copyright(c)2012 NTT, Inc. All Rights Reserved. 7
8. 【特徴2】ログシッピング
データベースの変更情報としてWALをマスタからスレーブに
転送
転送されたWALをリカバリすることで、スレーブはデータ
ベースを複製
クライアント
更新SQL
マスタ スレーブ
WAL リカバリ
WAL WAL
Copyright(c)2012 NTT, Inc. All Rights Reserved. 8
9. 【特徴3】非同期レプリケーション
トランザクションは、WALがマスタに書き込まれた時点で完了
■ スレーブへのWALの転送やリカバリは、トランザクションの完了とは非同期的
に実行
レプリケーションの性能オーバーヘッドは小さい
■ トランザクションは、レプリケーションの完了を待つ必要がないため
クライアント
1. COMMIT
3. 成功
マスタ スレーブ
6. リカバリ
4. WALの転送
2. WALの同期書き込み 5. WALの同期書き込み
Copyright(c)2012 NTT, Inc. All Rights Reserved. 9
10. 【特徴3】非同期レプリケーション
フェイルオーバ時にCOMMIT済のデータを失う可能性がある
■ COMMIT成功時、そのトランザクションのWALがスレーブに届いている保証はないため
高可用・データ保護の用途には利用しにくい
スレーブで参照SQLを実行したとき、古いデータが見える可能性がある
■ COMMIT成功時、そのトランザクションのWALがリカバリされている保証はないため
最新データをすぐに見る必要のないバッチなどの負荷分散に有効
クライアント
1. COMMIT
3. 成功
マスタ スレーブ
6. リカバリ
4. WALの転送
2. WALの同期書き込み 5. WALの同期書き込み
Copyright(c)2012 NTT, Inc. All Rights Reserved. 10
11. 同期レプリケーション
バージョン9.1からレプリケーションのモードを非同期、同期
から選択可能
トランザクションは、WALがマスタとスレーブの両方に書き
込まれた時点で完了
■ スレーブへのWAL転送は同期的だが、リカバリは非同期的に実行
クライアント
1. COMMIT
6. 成功
マスタ スレーブ
7. リカバリ
3. WALの転送
5. 応答
2. WALの同期書き込み 4. WALの同期書き込み
Copyright(c)2012 NTT, Inc. All Rights Reserved. 11
12. 同期レプリケーションの性能
レプリケーションの性能オーバーヘッドは大きい
■ トランザクションは、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. 応答
2. WALの同期書き込み 4. WALの同期書き込み
Copyright(c)2012 NTT, Inc. All Rights Reserved. 12
13. 同期レプリケーションのデータ保護レベル
フェイルオーバ時にCOMMIT済のデータが失われることはない
■ COMMIT成功時、そのトランザクションのWALがマスタとスレーブ両方のディスクに存
在することが保証されるため
■ COMMIT済のデータが失われるのは、両系のディスクが破壊されたという稀な場合のみ
高可用・データ保護の用途に利用しやすい
スレーブで参照SQLを実行したとき、古いデータが見える可能性がある
■ 「同期レプリケーション = COMMIT済のデータがすぐにスレーブで参照できる」ではない
ことに注意!
クライアント
1. COMMIT
6. 成功
マスタ スレーブ
7. リカバリ
3. WALの転送
5. 応答
2. WALの同期書き込み 4. WALの同期書き込み
Copyright(c)2012 NTT, Inc. All Rights Reserved. 13
14. 同期レプリケーションの設定
スレーブごとにレプリケーションのモードを設定
■ 同期レプリケーションを行うスレーブの名前をsynchronous_standby_namesに設定
■ 同期レプリケーションを実行できるスレーブは同時に1台のみ
■ より先頭に設定されている名前のスレーブが優先的に同期レプリケーションを行う
postgresql.conf
synchronous_standby_names = ‘tokyo, osaka’
マスタ 非同期
同期のtokyoが故障したら自動的に
同期に昇格
その後、tokyoが復活したら自動的に
同期 非同期 非同期に降格。tokyoが同期になる
スレーブ
tokyo nagoya osaka
recovery.conf
primary_conninfo = ‘application_name=“tokyo”’
Copyright(c)2012 NTT, Inc. All Rights Reserved. 14
15. 同期レプリケーションの監視
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: 非同期だが、同期に昇格するかも
Copyright(c)2012 NTT, Inc. All Rights Reserved. 15
16. トランザクション単位のデータ保護レベルの設定
トランザクションごとにデータ保護レベルを細かく制御
■ SET synchronous_commit TO xxx
トランザクションが
スレーブの synchronous_commit WAL書き込みを待つか?
モード の設定値
マスタ スレーブ
on 待つ 待つ
同期 local 待つ
off
on 待つ
非同期 local 待つ
off
トランザクションの重要度に応じてデータ保護レベルを変更
■ 同期レプリケーションのスレーブに対して、
■ お金を扱うトランザクションでは設定値 on で、COMMIT時に両系にWALが存
在することを保証し、データ損失を確実に防ぐ
■ 故障時に一部更新結果が消えてもよいトランザクションでは local / off に設
定して性能向上
Copyright(c)2012 NTT, Inc. All Rights Reserved. 16
17. レプリケーションを継続できないときの挙動
レプリケーションを継続できないのは、マスタとスレーブの2台構成で、以
下の場合
■ スレーブの故障時
■ マスタ/スレーブ間のN/W故障時
■ マスタ故障によるフェイルオーバ発生後
非同期レプリケーション
■ マスタは、単独でトランザクションを処理
■ 故障によってトランザクションが停止することはない
スレーブ故障時 フェイルオーバ後
マスタ スレーブ 新マスタ
旧マスタ
レプリケーション レプリケーション
できない できない
Copyright(c)2012 NTT, Inc. All Rights Reserved. 17
18. レプリケーションを継続できないときの挙動
同期レプリケーション
■ マスタは、スレーブからの届くことのないレプリケーション完了の応答を待ち
続ける
■ トランザクションは停止する!!
スレーブを故障から復旧させるなどして、再びレプリケーションを行える
ようになったらトランザクション再開
■ 復旧にかかる時間だけシステムが停止する
データ保護を最優先するための措置
■ マスタ単独でのトランザクション処理を許すと、そのトランザクションはマス
タのディスクにしか記録されていないため、マスタのディスク故障時に
COMMIT済のデータが消える
■ トランザクションを停止することで、マスタにだけ存在するようなCOMMIT済
データが発生するのを回避
トランザクションを停止させたくないなら、同期レプリケーションのス
レーブを複数台用意
■ 別のスレーブが「同期」に自動的に昇格し、そのスレーブにレプリケーションで
きるとトランザクション再開
Copyright(c)2012 NTT, Inc. All Rights Reserved. 18
19. レプリケーションを継続できないときの挙動
スレーブを複数台用意できない場合は、手動でスレーブを切
り離し
■ レプリケーションのモードを非同期に設定変更
■ synchronous_standby_namesの設定値を空にして設定ファイルをリ
ロード(pg_ctl reload)
■ 注意: synchronous_commitによる非同期への設定変更では、故障発生
当時に実行中だったトランザクションを再開できないことがあるため、
synchronous_standby_namesを設定変更すること
■ データ損失のリスクがあるため注意すること
■ スレーブ復旧時は、レプリケーションのモードを同期に戻すこと
レプリケーションを継続できないときに、自動的にマスタを
単独稼働させる機能はPostgreSQLにはない
Pacemakerで自動的にそれをやってくれる機能については第
2部で
Copyright(c)2012 NTT, Inc. All Rights Reserved. 19
20. 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の設定である程度検知できたが、完璧でなかった
Copyright(c)2012 NTT, Inc. All Rights Reserved. 20
21. PG9.2のレプリケーション新機能
より高速な同期レプリケーション
■ スレーブがWALを受信した(正確にはwrite(2)で書き込んだ)時点で、レプリ
ケーション完了の応答をマスタに返却するモード
■ 重い処理である「スレーブでのWALの同期書き込み(fsync)」をマスタは待つ必
要がなくなり、レプリケーションのオーバーヘッドが小さくなる
カスケードレプリケーション
■ スレーブからスレーブにレプリケーション
■ マスタに接続するスレーブ台数を減らし、マスタの負荷を小さくできる
■ 非同期のみ
スレーブからのオンライン物理バックアップ
■ pg_basebackupでマスタからだけでなくスレーブからバックアップを取得
■ マスタに集中していたバックアップの負荷をスレーブに負荷分散できる
pg_receivexlog
■ マスタからWALを受信しディスクに書き続けるツール
■ オペミス対策でWALの二重化などの用途
Copyright(c)2012 NTT, Inc. All Rights Reserved. 21
22. まとめ
バージョン9.1からレプリケーションのモードを「非同期」と
「同期」から選択可能
レプリケーションのモードはスレーブ単位、トランザクショ
ン単位で設定
レプリケーションの様子はpg_stat_replicationで確認できる
同期レプリケーションはデータ保護を最優先し、レプリケー
ションを継続できないときはトランザクションを停止させる
Copyright(c)2012 NTT, Inc. All Rights Reserved. 22
23. PostgreSQL同期レプリケーション
+
Pacemaker
による高可用クラスタ化
松尾 隆利
Copyright(c)2012 NTT, Inc. All Rights Reserved.
24. 高可用(HA)クラスタ? Pacemaker?
複数台のサーバーを用意し、壊れた時に他のサーバーでサービスを
引き継ぐことでシステムの可用性(Availability)を高める手段
■ 今までのPostgreSQLのHAクラスタ化はActive-Standby (Cold Standby)方式が
主流
■ Pacemakerは"Linux-HA Japan"コミュニティ提供のオープンソースソフトウェア
■ 市販製品では、ClusterPro, LifeKeeper, Red Hat High Availabilityアドオン 等
Active Standby フェイルオーバ Active
故障
故障発生
マウント マウント
DBデータ DBデータ
Copyright(c)2012 NTT, Inc. All Rights Reserved. 24
25. レプリケーション構成のHAクラスタ化 3大機能
①フェイルオーバ
Master フェイルオーバ
Master
故障発生
故障
③
同期
Master レプリケーション Slave
古
DBデータ DBデータ
デ
ー
タ
②同期・非同期の切替 の
状
DBデータ DBデータ
態
管
非同期 理
Slave Master レプリケーション
故障発生
故障
DBデータ 古
DBデータ
Copyright(c)2012 NTT, Inc. All Rights Reserved. 25
26. 想定している適用箇所
クラスタ化に費用を割けられない
■ NAS, 共有ディスク, NFSサーバ等が不要
参照クエリを負荷分散したいがSlaveの故障にも備えたい
■ Slave故障時にMasterで参照クエリを処理させる
• アプリケーションは接続先を意識しなくてよくなる
高負荷時のフェイルオーバ時間を出来る限り短くしたい
■ フェイルオーバ後のクラッシュリカバリが(ほぼ)必要なくなる
某高速ストレージを使いたい
■ PCI Express接続ストレージではデータを共有できない
■ 性能を求めるにはレプリケーション用のネットワークもそれなりの
性能の物を揃える必要あり?
Copyright(c)2012 NTT, Inc. All Rights Reserved. 26
27. 基本構成
サービス提供用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の記述は省略(使用推奨)
Copyright(c)2012 NTT, Inc. All Rights Reserved. 27
28. リソースエージェント(RA)
Pacemakerと制御対象のアプリケーション間を
仲介するプログラムで、主にシェルスクリプトで記述。
既存のPostgreSQL用RAは、
Active-Standby構成に必要な関数
PostgreSQL
(起動(start)・監視(monitor)・停止(stop))を実装
起動 監視 停止
レプリケーション構成を制御するために
この pgsql RA の機能を拡張 pgsql RA
Pacemaker
Copyright(c)2012 NTT, Inc. All Rights Reserved. 28
29. 基本動作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
サーバ#1 サーバ#2
サーバ#2
④
古
① #1のPostgreSQLの故障を検知 ② #1のPostgreSQLを停止
③ #1の仮想IPを#2に付け替え
④ #1のデータが古いことを記録
⑤ #2のPostgreSQLをMasterに昇格
Copyright(c)2012 NTT, Inc. All Rights Reserved. 29
30. 基本動作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 → トランザクション再開
Copyright(c)2012 NTT, Inc. All Rights Reserved. 30
31. TimelineID
PostgreSQLがSlaveからMasterへ昇格した際インクリメントされる数値
TimelineIDが異なるとレプリケーション接続ができない
フェイルオーバ時
フェイルオーバ
Slave→Master
Master レプリケーション Slave
故障
5 5 5 5 6
異なる
TimelineIDをそろえるには
手動でのデータ同期(推奨) or WALアーカイブの共有が必要
Copyright(c)2012 NTT, Inc. All Rights Reserved. 31
32. 運用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
サーバ#1 サーバ#2
サーバ#2
サーバ#2 サーバ#1 サーバ#2
② データ同期
古 新
① 故障の復旧 ④ #1のPostgreSQLを起動
② #1のデータを#2と同期 ⑤ レプリケーション開始
→ TimelineIDがそろう (手動) ⑥ #2の仮想IP(Slave用)を#1に付け替え
③ #1のPacemaker上の故障
フラグをクリア
Copyright(c)2012 NTT, Inc. All Rights Reserved. 32
33. 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がインクリメントされる
Copyright(c)2012 NTT, Inc. All Rights Reserved. 33
34. 運用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用)が移動
Copyright(c)2012 NTT, Inc. All Rights Reserved. 34
35. HAクラスタ化まとめ
3大機能
■ Masterのフェイルオーバ
■ レプリケーションの同期・非同期の切替
■ データの状態管理
Master起動時やフェイルオーバ時にTimelineIDの
ずれが発生
■ ずれが発生するとレプリケーション接続ができないため、
手動でのデータの同期(推奨) or WALアーカイブの共有が必要
Copyright(c)2012 NTT, Inc. All Rights Reserved. 35
36. 参考
開発中のソースコード (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/
Copyright(c)2012 NTT, Inc. All Rights Reserved. 36