マスター・スレーブ構成ではマスター障害時、保持しているバイナリログが最も進んでいるスレーブから新マスターを選出する。
MySQLでは、どのスレーブが最新のログを持っているかはコントロールできない。 準同期レプリケーションを利用していたとしても、非同期スレーブのほうが先に進んでいるということがあり得る。
複数のデータセンターを利用する場合に、プライマリ側のデータセンターにマスターを固定する運用をするとしたら、 どのような構成パターンが良さそうか考えてみる。セカンダリ側のデータセンターのスレーブが最も進んでしまっている場合にどのように対処するか。
前提条件
- プライマリデータセンター内にロスレス準同期スレーブが最低一台は存在している前提
- サーバ障害でのデータロストは許容できない
1. 中間マスターなし
1-1. DC間フェイルオーバー有り
セカンダリのデータセンターが新マスターになる可能性がある。
マスターをプライマリのデータセンターに固定したい場合は、２段回でのフェイルオーバー動作が必要になる。 一旦、セカンダリDCのマスターにフェイルオーバーした後、プライマリDC内のスレーブをマスターに昇格しなおす。
1-2. DC間フェイルオーバー無し
プライマリのデータセンター内から必ず新マスターを選出するパターン。 プライマリ側に最新のログを持ったスレーブが存在する場合は何も問題はない。 運悪く、セカンダリDC側が先に進んでいた場合は、先に進んでしまったセカンダリDC側は破棄する必要がある。そうしないと、プライマリDC側に存在しないデータがセカンダリDC側に存在してしまう。
ここで破棄されるデータは、プライマリDC側で「まだ準同期スレーブがログを受け取っていないデータ」である。そのため、クライアントにはOKが返っていない段階。 まだ、クライアントがコミットできたことを認識してないので、破棄しても問題ない。
セカンダリDC側のスレーブが破棄される可能性があるため、セカンダリDCのスレーブを参照するような構成は取れなくなる。
2. セカンダリのデータセンターに中間マスターを配置
中間マスターを配置することで、構成が対象になり、わかりやすい。。。ように思えるが、 実際は、中間マスター死んだときのことも考えないといけないので面倒である。
2-1. DC間フェイルオーバー有り
セカンダリの中間マスターが先に進んでいた場合、中間マスターが新マスターになる。 中間マスターより、セカンダリDCのスレーブが先に進むということはあり得ないため、セカンダリDCのスレーブが新マスターとして選出されないようにすることが可能。 1-1 同様、マスターをプライマリのデータセンターに固定したい場合は、２段回でのフェイルオーバー動作が必要になる。
2-2. DC間フェイルオーバー無し
1-2 と同じ。セカンダリDC側が先に進んでしまっていた場合、セカンダリDC側は破棄する必要がある。
3. プライマリのデータセンターに中間マスターを配置
3-1. DC間フェイルオーバー有り
セカンダリDCのスレーブが、プライマリDCより先に進むことはあり得ないため、必ず、プライマリDCから新マスターが選出される。 この時、中間マスターが選出されるとは限らない。 セカンダリDC側にフェイルオーバーすることがないのがメリットだが、2 同様に、中間マスターのフェイルオーバーも考える必要がある。
3-2. DC間フェイルオーバー無し
セカンダリDCのスレーブが新マスターとなることはないため、3-1 と同じ。
まとめ
マスター・スレーブで冗長化するのむずかしい・・・考えることが多い
DC間フェイルオーバーを無しとした場合、ロストスレーブが発生しうるため、DC間F/Oは有り＋2段回F/O としたほうが運用上は楽な気がする
- 1-1 が良さそう
