「PostgreSQLで実現する高可用性セミナー」に参加する // Kwappa研究開発室

SRAOSSで開催された「PostgreSQLで実現する高可用性セミナー」に参加してきた。お茶は出るし席はゆったりしてるし、環境は大変よかった。

スライドは後日webで配布されるとのことなので楽しみに待とう。重複する部分もあるが、当日のメモを再構築してみた。ずいぶん長くなっちゃったのはご愛嬌。

【2008-07-25追記】　「PostgreSQLにおける高可用性実現方法」スライド公開

http://www.sraoss.co.jp/event_seminar/2008/pgsql_high_availability.pdf

ごあいさつ * SRAOSSのコンサル事業についての紹介 * チューニングにまで踏み込んだトレーニング * 実際に動いているものについてのコンサルティング * PostgreSQLについては10年ほどキャリアがある
＞何かしら役に立てますよ * 最近の話題 * 日本支社は今月３周年 * 導入トレーニングが8.3対応 * DB Magazine8月号にPostgreSQLの記事あり * ThinkIT 7月の特集「データベース夏の陣」
木曜日pgpool-IIについて連載中(入門向け) * OBCIの理事長に支社長が就任 * DB Magazineの記事より * 7.4～8.3にかけてのベンチマークを同じマシンで実施＞8.3はアーキテクチャが大きく変わったため、とくにupdateがよくなってる * 単純な性能ならハード / ソフトのアップグレードでスケールできる
- PostgreSQLにおける高可用性実現方法
  - 可用性について
    - 可用性とはシステムの信頼度を評価する観点の一つ
    - 稼働率 = MTBF / (MTBF + MTTR)
      - 全時間に対する稼働している時間の割合
      - MTBF(Mean Time Between Failure)
        ＞平均故障間隔
      - MTTR(Mean Time To Repair)
        ＞平均修理時間
    - 稼働率が高い = 高可用性 = High Availability(HA)
```
<th>
  稼働率
</th>
```
```
<td>
  99.2%
</td>
```
```
<td>
  99.7%
</td>
```
```
<td>
  99.98%
</td>
```
```
<td>
  99.99996%
</td>
```
      年間あたりの故障時間
      3日
      1日
      1時間
      5分
      ＞99.7%はすごく高い数値に見えるけど、実は年間丸１日ダウンしてる
  - pgpool-II,Slony-Iを中心とした高可用性構成例のご紹介
    - ソフトウェアレプリケーションによるクラスタリング
      ＞レプリケーションでスタンバイ機にデータを同期、トラブル時は切り替える
      - pgpool-II
        pgpool-IIによるレプリケーションにはnow(),random(),serial,sequenceの扱いについて制限がある
        ＞適切に書けば対応可能→SQLのチェックと対応についてのコストと比較検討する
        「唯一」で「可用性が高い」pgpool-IIが必要
        複数のpgpoolでレプリケーションを行うとデータ不整合リスクがある
        フェイルオーバ / リカバリは「唯一の」pgpool-IIで行う必要がある
        pgpool-HA
        HeartBeat向けpgpool-II用スクリプト
        メリット
        pgpool-IIの可用性があがる
        デメリット
        最新バージョンのHeartBeat / pgpool-IIに対応できていない
        ＞古めのバージョンでは実績あり
      - Slony-I
        非同期レプリケーションである
        遅延は通常長くて数秒程度
        ＞それが許されるかどうか要件を検討する
        更新が大量に発生するとその分遅延が発生する
        パラメータでチューニングする
        マスタには高スペックハードを使う
        Slony-I 2.0
        6/27 RC公開
        PostgreSQL 8.3以降専用に
        ＞今までSlonyで行っていた処理がPostgresに取り込まれた
        プログラムがシンプルに
        パフォーマンスアップ（するかも）
    - PostgreSQLをHAクラスタリング
      ＞DBサーバを冗長化し、データは共有 / 同期する
      - ファイルシステムによる同期
        ＞DRDB(ファイルシステムレベルのミラーリング)など
        I/Oがボトルネックになって速度が出ない
        更新が激しい場合信頼性に疑問が
        商用ソフトウェアも存在する
        ＞LifeKeeperのレプリケーション機能とか
      - ウォームスタンバイ
        ＞トランザクションログを流し続ける
        ログがまとまって流れるので速度は出る
        非同期になってしまう
        HAソフトの「標準的な」使い方とはずれる
        ＞事前/事後処理のスクリプトを自前で書く必要がある
      - 共有ストレージ構成
        ファイルシステム同期より速い
        ＞ストレージの冗長化は必須
        実績豊富
        ＞昔はこれしかなかった
        HAクラスタソフトは商用を推奨
        ＞ハードウェア検証してくれる
        当然高コスト
    - ところでそこまで高可用性が必要？
      - レプリケーション / 自動フェイルオーバの目的
        ＞停止時間を短く / 復旧点をできるだけ障害直前に
      - それならPITRだけで復旧点 / 復旧時間を改善できる
        ＞pg_dumpによるデイリーバックアップからはずいぶん改善できるが、意外と使われてない
      - クラスタリングの複雑さはリスクである
        ＞要求されるコストと技術レベルは高くなるのでシンプルに越したことはない

年間あたりの故障時間
3日
1日
1時間
5分