データベースレプリケーションと高可用性設計（アクティブ/スタンバイ）

レプリケーションは更新を別のノードへ複製する仕組みです。高可用性には複製だけでなく、障害判定、昇格、旧主系の隔離、接続先切替、復旧後の再構成が必要です。複製先にログが届いたことと、利用者のSELECTに更新が見えることも別です。

コミットを何の確認まで待つか

PostgreSQLの同期レプリケーションには、副系への書込みや永続化、remote_applyによる適用完了など、確認する段階の違いがあります。MySQL 8.4の半同期は、少なくとも設定台数の副系がイベントをリレーログへ書き、ディスクへフラッシュした確認を待ちます。適用完了を待つ意味ではなく、メモリに届くだけの方式でもありません。

RPO=0を、障害範囲と設定で判断する

RPOは許容するデータ損失の時点・幅、RTOはサービスを復旧させるまでの目標時間です。同期している副系が生き残り、確認済みの更新を持つその副系を昇格させる前提なら、主系障害に対する損失を0にできます。しかし全系の同時損失や非同期への縮退、確認先とは別の古い副系の昇格では、その前提が崩れます。

同期確認にはネットワーク往復と副系の処理・永続化の待ちが発生します。通信とローカル処理が重なる実装もあるため、RTTが常にそのまま全処理時間に加算されるとは限りません。この教材の単純な逐次モデルで、ローカル処理20ms、RTT15ms、副系の永続化5msなら、合計40msです。ピーク時には待ち行列も含めて測定します。

読取り負荷分散とRead-Your-Writes

非同期レプリカを更新直後の参照先にすると、複製遅延により以前の値が返ることがあります。副系でログが永続化されていても、まだ適用されていなければSELECTには見えません。一定秒数だけ主系へ向ける対策は経験的な軽減にはなりますが、遅延がそれ以上なら保証にはなりません。

自己更新の直後は主系を読む、または副系が自分のコミット位置まで適用したことを確認して読む方法を検討します。確認は受信位置ではなく、必要な可視性を満たす適用位置に基づきます。待機の上限と、追い付かないときに主系へ戻すか失敗を返すかも決めます。

スプリットブレインを防ぐ仕組み

通信断だけでは、相手が停止したのか、回線だけが切れたのか分かりません。旧主系が動いたまま副系を昇格させると、両側の更新が分岐する危険があります。投票メンバーの過半数を得る側に権限を与えるクォーラムや、第三の監視・投票ノードが調停に役立ちます。

奇数台を置くだけで安全が自動保証されるわけではありません。過半数を失った側の書込み停止と、旧主系が更新できないことを保証するフェンシングを設計します。フェンシングには電源遮断、ストレージアクセス遮断などがあります。昇格先のログ位置、アプリの接続先、旧主系の再参加も確認します。

演習1：同期の単純な所要時間

条件：ローカル20msの後にRTT15msと副系の永続化5msを待つ。重なりや待ち行列はない。

問い：コミット応答までの時間と、50ms要件との差を求めよう。

解答例：40ms、要件まで10msの余裕。

根拠：20+15+5。実環境では分位値やピーク負荷で確認する必要がある。

演習2：更新直後の読取り

条件：副系はコミットログを受信したが、まだ適用していない。

問い：自己更新を読めることの確認境界を説明しよう。（35字以内）

解答例：副系が自分のコミット位置まで適用したことを確認する。（26字）

根拠：ログ受信・永続化だけでは、SELECTに見える状態まで進んだとは限らない。

復習で確かめること

例の数値や業務条件を変えて同じ結論になるか確認してください。用語の定義だけでなく、問題文のどの条件から、どの制約・SQL・対策を選んだのかを自分の言葉で説明できれば、次の過去問に進みます。

出典と仕様を確認する

IPA：DBシラバス Ver.4.1

PostgreSQL 18：スタンバイと同期レプリケーション

MySQL 8.4：半同期レプリケーション

関連するテーマ

ログ先行書き込み（WAL）と障害回復（REDO/UNDO・チェックポイント）

分散データベースと2相コミット（2PC）・CAP定理