1. ホーム /
  2. データベース /
  3. PostgreSQL Streaming Replicationの運用を一段階引き上げる方法
  • 2019.03.28

PostgreSQL Streaming Replicationの運用を一段階引き上げる方法

    こんにちは、LifeKeeperのプリセールスを担当しております國政です。
    いつも当ブログをご覧頂きましてありがとうございます。 

    先月のデータベースの可用性の考え方のブログで少し触れましたが、今回はPostgreSQLのもつ機能であるStreaming Replicationをより良く使う為にHAクラスターと連携する事で得られるメリットを中心に考えてみましょう。

     

    Contents hide

    Streaming Replicationとは

    Streaming ReplicationとはPostgreSQL9.0以降で利用できる本体に内蔵された機能で、レプリケーション(複製)の機能を持ちます。動作としては、DBの参照/更新が可能なプライマリ担当のホストと、参照のみが可能なセカンダリホストで構成されます。

    アーキテクチャについては検索エンジンで多くの文献がヒットしますので詳細はそちで確認して頂く事がよいのですが概要としては、プライマリ機からスタンバイ機へWAL(Write Ahead Logging)を送り続けセカンダリホストでは受けったWALを元にリカバリ作業をし続けるような感じでディスクへ書き込みプライマリ機とセカンダリ機の差をなくす動作をします。ちょっと分かりにくいかも知れませんが、WALはディスクへ書き込む前に更新されるトランザクションログと考えてください。この仕組みには障害時における運用に一つ注意が必要です。

    20190328_002

    注意点:プライマリサーバーダウン時は手動でスタンバイサーバーを昇格させる必要があるクライアントは接続先サーバーを意識しなければならない。

     

    Streaming Replicationの良い所とイマイチな所

    Streaming Replicationの良い所は製品内包の機能ですので、レプリケーションなどの仕組みを別途用意しなくでも利用できる点や多彩なレピュテーション設定ができ、設定方法もそう難しくはありません。イマイチな所としては障害時にプライマリ機からスタンバイ機への切り替えが自動で行えず、PgPool-ⅡやHAクラスターなどの仕組みを併用しないと可用性を高めたとは言いにくい構成となる所でしょうか。

     

    HAクラスターソフトウェアのLifeKeeperと組み合わせるとどうなるか

    上の章で記述しましたが、Streaming Replicationを利用する為には何かしらの「障害検知の仕組み」、「セカンダリからプライマリへの昇格」もしくはフェイルオーバーなどの自動切り替えの仕組みを入れて置く事が必須です。もちろんPgPoolⅡで構成する事も可能ですが、HAクラスターで実績のあるLifeKeeperではこのStreaming Replicationの構成を活かしつつ自動切り替えの仕組みを提供します。 

    20190328_003

    LifeKeeperで実現できる事

    • 仮想IPを提供しクライアントからの接続の一本化
    • プライマリ、スタンバイサーバーの状態を監視し、異常時にはスタンバイサーバーをプライマリ相当へ自動的に昇格させ仮想IPに紐づく情報を更新し切り替える
    • LifeKeeperならこの構成を行う為のスクリプトを別途準備する必要なし！

     

    LifeKeeper配下でのStreaming Replicationはどう動く?

    通常HAクラスター配下に何かのプリケーションやプログラムを置く場合は制御用のスクリプトを準備する事が多いです。具体的には以下の内容で4つ準備する事が多いですが、今回の場合はプログラムの再起動より切り替えた方が早く復帰する為(4)の提供はありません。

    　　　(1)プログラムを起動させるスクリプト　(restore)
    　　　(2)プログラムを停止させるスクリプト  (remove)
    　　　(3)プログラムを監視させるスクリプト  (quick Check)
    　　　(4)プログラムを再起動させるスクリプト(recover)

    続いて動作の方ですが、(1)の起動スクリプトはその名の通りPostgreSQLを起動させます。すでにプライマリとなっているマシンで実行された場合は何もしません、PostgreSQLが起動していない場合は起動を掛けます。マスタ異常により昇格した場合は旧マスタを参照しているスレーブを全て停止させます。ここで停止したスレーブは監視スクリプト(quick Check)で復帰させます。

    (2)のremoveはマスタ、スレーブの状態を確認し、スレーブノードのremoveスクリプトを実行し全てのスレーブノードを停止させます。

    (3)はマスタ、スレーブの動作状態(status)を確認し、エラー処理、restore処理を適切に行い正しい状態へと持っていきます。これらのスクリプトの動作を調整(待ち時間、試行回数など)する事も可能です。

    ここで既にLifeKeeperの事を少しご存知の方はお気づきになられたかも知れませんが、Streaming Replication構成に対応する為のスクリプトはLifeKeeperのARKのラインナップにありません。ARKの提供が無いものは汎用のGeneric ARKを利用しユーザ様において実装して頂く必要がありますが、今回ご紹介するこのスクリプト集はGeneric ARKをベースに当社で設計した物をLifeKeeper + Streaming Replication構成で利用できるように構成してみました。もちろんGeneric ARKベースですのでお客様ご要件によって内容を改変し利用頂く事は問題ありません。なお、当スクリプト集は今回の試験的な取り組みで作成した「サンプル」として提供させていただきますため、製品サポートの対象にならないことを予めご了承願います。

    なお、このGeneric ARKは一般的には公開しておらず、当ブログをご覧頂いた方のみにご案内をしております。試しに使ってみたい、事前確認をしてみたいなどのご要望などございましたら、評価版のご提供も可能ですので以下より注意事項をご一読の上お申し込み下さい。

    評価版ダウンロード

    LifeKeeper/DataKeeper/Single Server Protectionの機能を30日間無料でご利用いただくことができます。要件に対応できるかなど、基本的な機能確認にぜひご利用ください。

    →[評価版のお申込み] https://mk.sios.jp/BC_DL_Evaluation.html

    ※評価版の申請項目内の「評価されたい具体的な機能」にPostgreSQL Streaming Replication対応のGeneric ARKも提供希望と記載下さい。

    お問い合わせ

    LifeKeeper/DataKeeper「見積を依頼したい」「もっと詳しい話を聞いてみたい。」といった場合は、下記よりお気軽にお問い合わせください。

    →[お問い合わせ窓口] https://mk.sios.jp/BC_Web_Free-entry_Inquiry.html