Weboo! Returns.

一昨日ですが、SRA主催で開催された「PostgreSQL 高可用性セミナー」というのに行ってきましたので、そのメモを公開します。pgpool-IIがかなり良さげです。アプリケーションからは単一のDBに見えて、クエリの負荷分散を自動でやってくれる上にコネクション・プーリングの機能もある。新規ノードの追加や障害時リカバリもDBを停止することなく、オンラインのまま実行可能だそうです。

PostgreSQLにおける高可用性実現方法 〜 石井達夫さん

1. バックアップ/リストア方式
   • ローコスト
   • リストアに時間がかかる
   • 代替用のハードウェアリソースが必要
2. PITRによるバックアップ/リストア
   • アーカイブログによる差分バックアップ
   • 最新の状態までの任意の時点に界幅可能
3. ウォームスタンバイ
   • 2台のマシンと、PITRを使う
   • スタンバイ側でアーカイブログを連続的に適用
   • ○DB側に設定変更不要、オーバーヘッドなし、低コスト
   • ×スタンバイ側は利用不可、設定が繁雑、ダウン検知機構が必要
4. 共有ディスク型HAシステム
   • ○稼働率が高い、待機側のリソースも有効活用
   • ×共有ディスク装置が必要、そこが故障すると終わり
5. ハードウェアによる高可用性実現
   • CPU,メモリ,ディスク,電源などを二重化
   • ソフトからは1台に見える
6. レプリケーション
   可用性だけでなく、性能向上も狙える

   Slony-I

   • PostgreSQLの開発メンバが開発/メンテ
   • トリガベースの非同期レプリケーション
   • マスタ/スレーブ方式
   • ノード間でのデータの一時的なずれがある
   • パラレルクエリに対応していない

   PostgresForest

   • NTTデータが開発
   • JDBCドライバを拡張しているのでJavaのみ
   • 負荷分散、パラレルクエリによる性能向上
   • ノード障害を自動検知
   • 更新系の性能向上は期待できない

   PGCluster

   • 三谷氏が個人的に開発
   • PostgreSQL本体を改良
   • コネクションプーリング、負荷分散、レプリケーション
   • ノード障害を自動検知
   • 使用言語を選ばない
   • 更新系の性能が非常に低い
   • パラレルクエリに対応していない
   • 5台のノードが必要

   pgpool-II

   • コネクションプーリング、レプリケーション、負荷分散、パラレルクエリ
   • 設定が容易、GUI管理ツールも付属
   • 使用言語を選ばない
   • 障害時にオンラインリカバリが可能
   • DBが2ノードあればオンライン状態での復帰が可能
   • 更新系の性能向上は期待できない

pgpool-II新バージョンの紹介 〜 浅羽さん

• レプリケーションの高信頼化
  • 内部的にトランザクションを実行、マスタを最後にコミット
  • 更新件数の確認を追加 → トランザクションをアボート
  • マスタのクエリ完了後にその他のノードに並列にクエリ送信(単体の約2倍で終了)
  • 検索が60%を超えると負荷分散の効果大(4ノード)
• オンラインリカバリ
  • リカバリのためのC言語関数をインストールする必要がある
  • 実際は、セカンドステージの実行中、接続がブロックされる
    (アーカイブログ適用の時間分)
  • 稼働中にノードを動的に追加可能
    (ただし、pgpoolを複数運用している場合は、一時的に1台にする必要あり)
  • リカバリ用のスクリプトを用意しておくことで、ブラウザ上からリカバリ可能
• パラレルクエリ
  • レプリケーションとパーティショニングテーブルを混在可能
  • 最大で6倍のパフォーマンス改善
  • しかし、パーティショニング同士の結合は遅い
• その他
  • ノードの切断/復帰時にコマンド実行可能(メール通知とか)
  • ノード間のPostgreSQLバージョンは合わせたほうが良い

関連リンク：
セミナー資料 - SRA OSS, Inc. 日本支社