PostgreSQLにおける高可用性実現方法
SRA OSS, Inc. 日本支社

可用性とは？
システムの信頼度を評価する観点の一つ
信頼性(Reliability)
MTBF(Mean Time Between Failure)

可用性(Availability)
稼働率

保守性(Serviceability)
MTTR(Mean Time To Repair)

保全性(Integrity)
安全性(Security)2•高可用性 = High Availability (HA)
可用性の尺度
稼働率 = MTBF/(MTBF+MTTR)「可用性が高い = 高可用性」とは，稼働率が100%に近
いこと稼働率を上げるためには，MTTRを小さくする
年間あたりの故障時間
３日
１日
１時間
５分

3

稼働率
99.2%
99.7%
99.98%
99.99996%

システムの可用性が高いことによるメリット
ビジネスの機会損失の防止
インターネット経由での無人販売

顧客離れの防止
ダウンしているサイトには２度と行かない

顧客からの信頼感
管理や技術力の高いことの証し

保守費用の低減
緊急対応要員不要
データ保全

4高可用性戦略
バックアップとリストア
可用性は低いがローコスト

基本は冗長化
ハードウェアの冗長化
ソフトウェアの冗長化

SPF(Single Point of Failure)をなくす
稼働率は，システム構成要素の中のもっとも弱い部分に足を引張られる
ただし，故障するか/しないかで評価するのは無意味．
稼働率が問題5

DBサーバ冗長化の難しさ

6

負荷分散装置

負荷分散装置WebサーバWebサーバ

DBサーバ

DBサーバ

DB

DB

どうやって
冗長化する？

1) バックアップ/リストア方式
PostgreSQLの機能だけで実現可能
ローコスト
バックアップした時点までしか戻れない
リストアに時間がかかるので，稼働率は下がる
データ容量にもよるが，30分から数時間は見ておく必要がある
参考: OSS iPedia(http://ossipedia.ipa.go.jp/)

代替用のハードウェアリソースが必要
用意しておかないと悲惨なことに...
代替用ハードウェアリソースは有効活用できない
71-2)PITRによるバックアップ/リストア
ファイルシステムバックアップ(tar, rsyncなど)＋アーカイブログによる差分バックアップ
最新の状態までリカバリ出来る(任意の時点までリカバリすることも可能)
ログを保存しておく必要がある
操作が煩雑

8

PITR STEP 1

事前準備
GUIよりオンラインバッ
クアップを有効にする
バックアップファイル格
納場所の指定postgresの再起動

9

PITR STEP 2
事前準備
ベースバックアップの取得

10

PITR STEP 3
リカバリの実行
最新の状態までリカバリするか日時を指定するか
選択する

11

2) ウォームスタンバイ
2台のマシンと，PITRを使う
アクティブ側から，スタンバイ側に連続してアーカイ
ブログを転送する
スタンバイ側は，リカバリをし続ける

12

ウォームスタンバイのシステム
イメージ
アクティブ側
アーカイブ
ログ
差分
DB

13

スタンバイ側
転送

アーカイブ
ログ
適用
DB

ウォームスタンバイの評価
メリット
アプリケーションやDB設定に変更不要
DBの性能にあまり影響を与えない
コストが安いデメリット
スタンバイ側のDBにはアクセスできない
転送されなかったログの分のデータは失われる
設定が煩雑アクティブ側がダウンしたことの検知と，IPの切り替え，
ウォームスタンバイ側のオンライン状態への移行など
は作り込みの必要あり
14

3) 共有ディスク型HAシステム
HA監視ソフト＋2台のDBサーバ
2台のシステムがお互いにディスクを共有することにより，DBデータのコピーの必要性をなくす

15

共有ディスク型HAシステムのシステムイメージ16共有ディスク型HAシステムの評価
メリット
アプリケーションやDB設定に変更不要，性能にも影響なし
稼働率が高い(ダウンタイム数分)
アクティブ/アクティブ構成にすれば待機側のリソースも
有効活用
実績がある

デメリット
共有ディスク装置が必要なので，コストが高い
共有ディスク装置が故障するとデータが失われる
17

4) ハードウェアによる高可用性実現
フォールトトレラント(無停止)構成Stratus ftServer 6200

CPU，メモリ，ディスク，
電源など，すべてがハード的に二重化
ソフトからは1台のコンピュータに見える18

ハードウェアによる高可用性システ
ムの評価
メリット
ソフトウェアの互換性が高い
Red Hat Linux，PostgreSQL，PowerGresでSRAOSSで性能評価済

フェイルオーバがないので極めて可用性が高い(ソフトからは停止時間がないように見える)

デメリット
専用ハードウェアが必要
ソフト障害には対応できない
負荷分散やパラレルクエリなどの性能向上を提供する
ものではない19

レプリケーションソリューション
ソフト的にDBの同期を取る
可用性だけでなく，性能向上も狙えることがある
もっともホットな分野
今回紹介するもの
Slony-I
PostgresForest
PGCluster
pgpool-II205) Slony-I
PostgreSQLの開発メンバーが開発，維持
BSDライセンスで配布
トリガベースの非同期レプリケーション
マスタ，スレーブ間の更新遅延が問題になる場合は要注意

一つのマスタ，複数のスレーブ．マスタのみが更新を受け付ける21

Slony-I
マスタ

スレーブ

クライアント
更新

ユーザDB

ユーザDB

トリガ
更新ログ

22

更新ログ

Slony-Iの評価
メリット
ノードを柔軟に追加できる
実績がある

デメリット
ノード間でデータの一時的なずれがある
負荷分散ができない
設定が面倒
レプリケーション出来ないデータがある
ノード障害に自動対応できない
パラレルクエリに対応していない
23

6) PostgresForest
NTTデータが開発
BSDライセンスで配布
JDBCドライバを拡張することにより，以下の機能を実現
レプリケーション，負荷分散，パラレルクエリ

使用できる言語はJavaのみ

24

PostgresForestのアーキテクチャ
問合わせ
DBノード1Javaアプリ
問合わせ

PostgresForest(実体は特別版の
JDBCドライバ)

DBノード2

DBノード325

PostgresForestの評価
メリット
負荷分散，パラレルクエリによる検索系の性能向上が期待できる
ノード障害に自動対応できる

デメリット
APIはJavaのみ
更新系の性能向上は期待できない
パラレルクエリで対応できない問合わせがある

26

7) PGCluster
三谷氏が個人的に開発
BSDライセンスで配布
PostgreSQLをベースに改造
コネクションプーリング，負荷分散，レプリケーショ
ン
使用言語を選ばない

27

PGClusterのアーキテクチャ
問合わせ
DBノード1

クライアントロード
バランサ

DBノード2

問合わせ
DBノード3

28

レプリ
ケーション
サーバ

PGClusterの評価
メリット
負荷分散による検索系の性能向上が期待できるノード障害に自動対応できる

デメリット
設定がやや面倒
PostgreSQLにパッチを当ているので，最新バージョンへの追随が遅れる
更新系の性能が非常に低い
パラレルクエリには対応していない
フル機能を利用するためには5ノード必要
29

8) pgpool-II
pgpool Global Development Groupが開発
BSDライセンスで配布される
多彩な機能
コネクションプーリング，レプリケーション，負荷分散，
パラレルクエリ設定が容易．GUI管理ツールも附属
PostgreSQLに手を入れていないので，バージョン
追従が容易
使用言語を選ばない30

pgpool-IIのアーキテクチャ

DBノード1
問合わせ
問合わせ
クライアント

pgpool-II

pgpool-HAを使うと，pgpool-II自体の二重化も可能
31

DBノード2

DBノード3

pgpool-IIの機能
コネクションプーリング
データベースへの接続
オーバヘッドを軽減
PostgreSQLへのコネク
ションを保持しておき，再利用する
Webシステムのように，頻繁に接続/切断を繰り返すシステムで効果あり32

アプリケーション

pgpool-II

PostgreSQL

pgpool-IIの機能
レプリケーション
SQL文を複製してデータ
ベースのコピーをリアルタイムに作る
片方のDBが障害を起しても自動的に切り離して運用を継続
障害復旧後は運用を停めずにDBを同期，復帰させることが可能（オンラインリカバリ）33

アプリケーション

pgpool-II

PostgreSQL

PostgreSQL

pgpool-IIの機能
負荷分散
検索問合わせをランダムに決めたPostgreSQLに振り向ける
負荷をPostgreSQL間で分かち合うので，検索性能が向上

アプリケーション

pgpool-II

PostgreSQL

34

PostgreSQL

pgpool-IIの機能
パラレルクエリ
データを分割してPostgreSQL間で分担
検索問合わせを複数のPostgreSQLで一斉に実行，結果をpgpool-IIでまとめる
問合わせを並列に処理するので高速アプリケーション

pgpool-II

PostgreSQL

35

PostgreSQL

pgpool-IIの評価
メリット
負荷分散，パラレルクエリによる検索系の性能向上が期待できる
ノード障害に自動対応できる
APIを選ばない
GUI管理ツールがあるので設定，管理が容易

デメリット
パラレルクエリで対応できない問合わせがある
更新系の性能向上は期待できない36

レプリケーションの総合比較
pgpool - I I PGCl uster Postgres
Forest Sl ony- I
対応PostgreSQLバージョン 7. 3以降
対応プラットフォーム△
対応言語○
コネクションプーリング○
同期レプリケーション○
自動縮退○
オンラインリカバリ○
負荷分散○
パラレルクエリ
○
検索性能
○
更新性能
△
DDL対応
○
ラージオブジェクト対応○
シーケンス対応○
SERI AL型対応△
拡張問合わせ△注１：各ソフトの最新バージョンの対応状況
注２：Slony-IのみWindowsでも動作可能
注３：PostgresForestのみJava限定37

7. 3以降
△
○
○
○
○
○
○
×
○
×
○
○
○
○
△

7. 4- 8. 1 7. 4以降
△
○
△
○
×
×
○
×
○
×
○
×
○
×
○
×
○
△
△
△
○
×
○
×
○
○
×
○
○
○

注1
注2
注3

注4
注5

注４：pgpoolはロックを併用することで対応可能
注５：pgpoolはパラレルクエリが拡張と問合わせに対応していない
PGClusterは無名PREPAREのSELECTだけが負荷分散されるどのソリューションを使うべきか？
コストをかけられない，可用性はほどほどでよい
バックアップ/リストア，ウォームスタンバイ，Slony-I

コストをかけても可用性を高めたい
ftServer, PowerGres HA

可用性だけでなく，検索性能も高めたい
pgpool-II, PostgresForest(Javaのみ)

DBが遠隔地にある，あるいは接続が保証されていない
Slony-I38