[pgcluster: 223] Re: 障害によるスタンドアローン構成への切替検証

[TANIDA Yutaka]

谷田です。

# 酔ってますが

On Tue, 30 Mar 2004 19:46:03 +0900
mitani <mitani ＠ sraw.co.jp> wrote:

> 実は，この問題は起こるであろうことは以前から予測されていたのですが，
> 2相コミットを使っても解決できないし，解決方法も思いつかず，後回しにして
> きました．
> 
> どういう問題かというと，
> データ更新クエリーのレプリケーション中に，レプリケーションサーバに障害が
> 発生した場合，レプリケーションされたクラスタDBと，されなかったクラスタDB
> が出来てしまい，データの整合性が崩れる可能性がある
> というものです．
> 
> レプリケーションサーバが1台だけであれば，レプリケーションサーバの障害以
> 降はレプリケーションされなくなりますので，あまり問題が無いのですが，
> レプリケーションサーバが2台以上ある場合，予備のレプリケーションサーバに
> 自動的に切り替わってしまいますので，データの整合性が崩れても，そのまま動
> いてしまい，どんどんデータの整合性が崩れていく可能性があります．

トランザクション中にレプリケーションサーバーが切り替わる->トランザクショ
ンabortが、最善の解決法だと思います。この場合なら、レプリケーションサー
バーが理由でトランザクションがabortしても、全トランザクションを投げ直す
という選択肢を考える余地があります。これなら、2-phase commitとあわせて整
合性を維持可能と思います。


> １．レプリケーションサーバがレプリケーションする前に，予備（下位）のレプ
> リケーションサーバにクエリーを投げる．
> ２．予備（下位）のレプリケーションサーバはクエリー(トランザクション）を
> 保存する．
> ３．マスタ(上位）のレプリケーションサーバに障害が発生した場合，
> 予備（下位）のレプリケーションサーバは保存しているクエリー（トランザクショ
> ン）を使って再レプリケーションを行う．
> ４．クラスタDBは再レプリケーションされたクエリーを判定し，既に処理したも
> のは無視し，未処理のクエリーのみ処理する．

リカバリ用に、下位のレプリケーションサーバーにログとして本番に投げるデー
タを準備するところがWALっぽいですが、下位のレプリケーションサーバーの処
理中、しかもcommit中に落ちてしまったらいずれにしても整合性は維持出来ない
と思うのですがいかがでしょう？

# このあたりは、専門家の見解が聞きたいところですが。

-- 
TANIDA Yutaka <tanida ＠ sra.co.jp>