PR

 構成7はマスターから2台(2方向)のスタンバイにストリーミングレプリケーションを行う。スタンバイはメインサイトに1台、遠隔地サイトに1台配置する。

 構成9はスタンバイがメインサイトと遠隔地の1台ずつあるのは構成7と同じだが、マスターがストリーミングレプリケーションを行う先はメインサイトのスタンバイのみ。ここからさらに遠隔地にあるスタンバイへストリーミングレプリケーションを行う。つまりカスケード型のストリーミングレプリケーション構成とする(図2)。

図2●構成7と構成9の詳細
[画像のクリックで拡大表示]
図2●構成7と構成9の詳細
[画像のクリックで拡大表示]
図2●構成7と構成9の詳細

 まずは災害対策としての有効性を考える。構成7と構成9は平常時からスタンバイでPostgreSQLサービスが起動しており、メインサイトで障害が発生すればスタンバイをマスターに切り替えるため復旧までの時間は短くて済む。

 またストリーミングレプリケーションで常にデータを同期しているため、データの鮮度は高い。平常時には遠隔地のサイトで参照系クエリーを処理することで、マスター側の負荷を下げることができる。PostgreSQLで災害対策するなら試してみたい構成だ。

 今回は実機で環境を構築し、障害からの復旧を検証した。障害が発生するサーバーはマスタとメインサイトにあるスタンバイの2パターンだ。

 マスターに障害が発生するパターンでは構成7も構成9もpromoteコマンドでスタンバイからマスターに昇格させることと、クライアントの更新先を変更する作業が生じるところまでは同じ。しかし構成7だと遠隔地のスタンバイを設定変更して再起動が必要になる一方で、構成9はカスケード型のストリーミングレプリケーションを行うため遠隔地サイトでは操作しなくてもよい。

 メインサイトにあるスタンバイに障害が発生するパターンではどうなるか。構成7だと、障害発生はスタンバイであり、マスターから遠隔地のスタンバイに直接ストリーミングレプリケーションが行われているため、実運用上は大きな問題にならない。