# 単一リーダーレプリケーション ## 定義 単一リーダーレプリケーション(single-leader replication、primary-backup / active-passive replication とも呼ばれる)とは、複数のレプリカのうち1台を「リーダー(またはプライマリ/ソース)」に指定し、書き込みは必ずリーダーが受け付けて残りの「フォロワー(read replica, secondary, hot standby)」へ変更ストリーム(レプリケーションログ)を配布する方式である。読み取りはリーダー・フォロワーいずれからも行えるが、書き込みを受け付けるのはリーダーのみである。PostgreSQL・MySQL・MongoDB・DynamoDB・Kafka・DRBDなど広範な製品で標準的に使われ、Raft・Multi-Paxosのような合意アルゴリズムに基づくシステム(CockroachDB, TiDB, etcd等)も単一リーダー構成を自動フェイルオーバー付きで実装したものと位置づけられる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Single-Leader Replication") ## 同期・非同期レプリケーション レプリケーションが同期か非同期かは、システム挙動に大きく影響する重要な設計軸である。同期レプリケーションでは、リーダーはフォロワーからの確認を待ってから書き込み成功をクライアントへ返す。フォロワーが最新のコピーを持つことが保証される代わりに、そのフォロワーが応答しない間は書き込み全体がブロックされる。そのため全フォロワーを同期にするのは非現実的で、実運用では1台のみ同期にする semisynchronous 構成、または過半数クォーラムを同期にする構成が一般的である。完全非同期構成では、リーダー障害時に未複製の書き込みが失われうる代わりに、フォロワーの遅延に関わらずリーダーが書き込みを継続できる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Synchronous Versus Asynchronous Replication") ## フェイルオーバーとレプリケーションログの実装 リーダー障害時のフェイルオーバーは、(1) 障害検知(多くはタイムアウト方式)、(2) 新リーダー選出(投票による選出、または既存のコントローラノードによる指名)、(3) クライアント・フォロワーの再設定、の3段階からなる。非同期構成では未複製書き込みの破棄によるデータ損失、split brain(2ノードが同時にリーダーを自認する状態)、タイムアウト調整の難しさなど落とし穴が多く、GitHubでは自動昇格したフォロワーの主キーカウンタが古かったため、後続の挿入がRedis側と不整合を起こし私的データが漏洩した実例がある。この理由から、自動フェイルオーバーに対応していても手動フェイルオーバーを選ぶ運用チームは多い。レプリケーションログの実装方式には、非決定的関数(NOW, RAND)で破綻しうる statement-based、WALをそのまま転送しストレージエンジンに密結合する write-ahead log shipping、ストレージエンジンから分離されゼロダウンタイムアップグレードやCDCの基盤になる logical(row-based) log の3系統がある。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Handling Node Outages", "Implementation of Replication Logs") ## レプリケーションラグと読み取り整合性 非同期フォロワーからの読み取りは stale(古い)値を返しうる。この現象を結果整合性(eventual consistency)と呼ぶ。この用語はNoSQLに限らず、非同期レプリケーションを使うリレーショナルデータベースのフォロワーにも等しく当てはまる。レプリケーションラグが引き起こす3種の異常とその対策は [[レプリケーションラグと読み取り整合性]] に詳しい。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Problems with Replication Lag") ## 横断的知見 - **「フォロワーの最新性で新リーダーを選ぶ」原則は、Raftのログベース選出とAmazon MemoryDBの実装の双方に共通する一般パターンである**: DDIAはフェイルオーバー時「最も新しいデータ変更を持つフォロワーが最良の候補」「非同期レプリケーションではログシーケンス番号が最大のフォロワーを選ぶ」ことを一般原則として述べる。これは[[リーダー選出]]ページで既に確認されているRaftの「候補者のログが有権者のログよりup-to-dateでなければ票を与えない」という投票制限や、Amazon MemoryDBの「マルチAZトランザクションログの最新書き込みを持つノードを選択する」ログベースリーダー選出と同じ設計原理であり、コンセンサスアルゴリズムに基づかない単純な単一リーダーレプリケーションでも、合意ベースのシステムでも、リーダー選出の核心は同一の「最新ログを持つ者を選ぶ」原則に帰着することを示す。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Leader failure: Failover") - **DDIAが一般化する「フェイルオーバーの3段階(障害検知→新リーダー選出→再設定)」のうち、(2)新リーダー選出の内部実装として、単独のリーダー選出アルゴリズムはスプリットブレインを回避できない**: 『詳説 データベース』10章は、ブリーアルゴリズム・招待アルゴリズム・リングアルゴリズムのいずれもネットワーク分断下でスプリットブレイン(独立したサブセットでそれぞれリーダーが選出される状態)を起こしうると明記する。これは、本ページが既に記録しているGitHubの実例(自動昇格したフォロワーの主キーカウンタが古く不整合が生じた事故)や「split brain(2ノードが同時にリーダーを自認する状態)」という落とし穴と同じ問題であり、DDIAが一般論として警告する落とし穴が、10章が扱う具体的な選出アルゴリズムのレベルでも構造的に不可避であることを裏づける。10章は、この落とし穴を回避するには合意アルゴリズム内蔵型のリーダー選出(過半数クォーラムを要求するRaft・Paxos・ZAB等)を使う必要があると示唆する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Handling Node Outages", [[@2021__OReillyJapan__詳説 データベース - Chapter 10 リーダー選出]] §10.1, §10.4, §10.5) - **DDIAが実装レベルで説明する「プライマリで書き込みを受け、ワーカーへレプリケートする」構成は、詳説 データベース11章の共有メモリレジスタ理論における「レギュラーレジスタ」の挙動と正確に対応する**: 詳説 データベース11章は、レギュラーレジスタを「読み取り操作が、最後に完了した書き込みの値か、現在の読み取りとオーバーラップしている書き込みの値のどちらかだけを返す」レジスタと定義し、その具体例として「プライマリで書き込みを受け入れ、読み取りを行うワーカーに対してそれらをレプリケートするデータベース」を明示的に挙げる。これは本ページが説明する単一リーダーレプリケーションの基本構造そのものであり、DDIAが実装・運用の言葉(同期/非同期・レプリケーションログ)で論じる単一リーダーレプリケーションを、詳説 データベースは並行システム理論の言葉(レジスタの並行アクセス挙動の3分類)で再定式化していることになる。アトミックレジスタ(線形化可能性相当)に対して単一リーダーレプリケーションが到達しない理由は、[[線形化可能性]]ページが示すレプリケーション方式別の線形化可能性の表(単一リーダーは「概ね可能」だが「リーダーの誤認や非同期フェイルオーバー時のデータ損失に注意」)とも整合する。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]] §11.3, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Single-Leader Replication") - **「古いレプリカのプロモーションは永続的なデータ損失を招く」という警告は、DDIAのフェイルオーバー3段階論と『SREの探求』17章の耐久性エンジニアリング論で独立に強調される**: [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] は、単一リーダーレプリケーションを前提としつつ「非同期レプリケーション方式の場合には、陳腐化したデータがレプリカデータベースから誤って読み込まれることのないように保証しなければならない。内容が古いレプリカをデータベースのマスターにプロモートする(昇格させる)ことも、データが永久に失われる原因となる」と警告する。これは本ページが既に記録するDDIAの「フェイルオーバー3段階(障害検知→新リーダー選出→再設定)」のうち(2)新リーダー選出における「最も新しいデータ変更を持つフォロワーを選ぶ」原則と同一の懸念を、耐久性(データ損失)という切り口から再確認するものであり、単一リーダーレプリケーションの設計原理が「レプリケーション/データベース実装の教科書」と「SREの実務ノウハウ」という異なる文献ジャンルで独立に到達する共通の結論であることを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] §17.1.2, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Leader failure: Failover") ## 未解決の問い - Raft等の合意アルゴリズムに基づく単一リーダー(CockroachDB, TiDB, etcd)と、伝統的な単一リーダーDB(PostgreSQL, MySQL)は、フェイルオーバー時のデータ損失リスクと運用複雑性でどの程度異なるか。合意ベースの自動フェイルオーバーは本当に手動フェイルオーバーより安全と言えるか。 - WAL shippingとlogical replicationの選択は、ゼロダウンタイムアップグレードの必要性以外にどのような実運用上のトレードオフ(性能・実装コスト)を伴うか。 - 『SREの探求』17章は「陳腐化したレプリカのプロモーションによるデータ損失」を警告するが、これを防ぐための具体的な選出アルゴリズム(ログシーケンス番号比較等)には踏み込んでいない。DDIAが述べる「最新のフォロワーを選ぶ」原則と、実際のプロモーション判定の実装(タイムアウト・投票・エポック管理)がどこまで組み合わされるべきかは未確認。 ## 関連 - [[マルチリーダーレプリケーション]] — 単一リーダーの「書き込みは1ノードのみ」という制約を緩和する代替アーキテクチャ - [[リーダーレスレプリケーション]] — リーダーという概念自体を排除する第三のアーキテクチャ - [[レプリケーションラグと読み取り整合性]] — 非同期フォロワー読み取りが生む異常とその対策 - [[結果整合性]] — レプリケーションラグが引き起こす整合性モデル - [[クォーラムベースレプリケーション]] — semisynchronous構成における過半数クォーラム同期 - [[リーダー選出]] — フェイルオーバー時の新リーダー選出メカニズム - [[PostgreSQL]] — WAL shipping・logical replicationの実装例 - [[線形化可能性]] — 単一リーダーレプリケーションが到達しうる一貫性の上限 - [[データ耐久性]] — 古いレプリカのプロモーションによるデータ損失という耐久性リスクの上位概念 ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]](単一リーダーレプリケーションの定義・同期/非同期・フェイルオーバー・レプリケーションログ実装の詳細) - [[@2021__OReillyJapan__詳説 データベース - Chapter 10 リーダー選出]]（ブリー系・招待・リングアルゴリズムがスプリットブレインを回避できない理由） - [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]] §11.3 共有メモリ(レギュラーレジスタとしての単一リーダーレプリケーション) - [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] §17.1.2(古いレプリカのプロモーションによる永続的データ損失の警告)