# マルチリーダーレプリケーション ## 定義 マルチリーダーレプリケーション(multi-leader replication、active/active または bidirectional replication とも呼ばれる)とは、複数のノードが同時に書き込みを受け付け、各リーダーが他の全リーダーに対してフォロワーとして振る舞う方式である。単一リーダー構成の「書き込みは1ノードのみ」という制約(リーダーへ到達できないと書き込み不能)を緩和する目的で導入される。同期マルチリーダーは実質的に単一リーダーと等価になるため、通常「マルチリーダーレプリケーション」は非同期構成を指す。MySQL・Oracle・SQL Server・YugabyteDBが組み込みでサポートし、Redis Enterprise・EDB Postgres Distributed・pglogicalは外部アドオンとして提供する。合意アルゴリズム前提の多くのDBに後付けされた機能であるため、自動増分キーやトリガー、整合性制約との相互作用に落とし穴が多く、「可能な限り避けるべき危険地帯」と評されることもある。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Multi-Leader Replication") ## 地理分散運用とトポロジー 単一リージョン内でマルチリーダーを使う理由は乏しいが、リージョンをまたぐ地理分散運用(geo-distributed / geo-replicated)では有用である。各リージョンにリーダーを置くことで、書き込みはローカルリージョンで完結しリージョン間ネットワーク遅延をユーザーから隠せる。一方、強い整合性制約(残高非負・ユーザー名一意等)は複数リーダーが独立に検証可能な書き込みを許すため保証できない。3ノード以上では circular・star・all-to-allのトポロジーが可能で、all-to-allは単一障害点を避けられる代わりに、ネットワーク遅延差により書き込みが「追い越し」て因果順序が乱れる問題(挿入より先に更新が到着する等)を持つ。この因果性の乱れは version vectors で検出できる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Geographically Distributed Operation", "Multi-leader replication topologies", "Problems with different topologies") ## 同期エンジンとローカルファーストソフトウェア 同期エンジン(sync engine)は、オフライン編集とリアルタイムコラボレーション(Google Docs/Sheets, Figma, Linear等)を支えるソフトウェア基盤であり、各デバイス・各ブラウザタブがリーダーとして振る舞う極端なマルチリーダー構成である。ローカルにデータを持つことでUIが即応(次フレーム16ms以内の応答を目指す実装もある)し、オフラインは「ネットワーク遅延が非常に大きい状態」として扱えるため特別なオフラインモードが不要になり、明示的なサービス呼び出し・エラー処理より宣言的なプログラミングモデルになる利点がある。ただし全データをクライアントへ事前ダウンロードする前提のため、大量データには不向きである。オフラインでも編集を継続できるアプリを offline-first、開発者がサービスを停止しても動作し続けるよう設計されたコラボレーションアプリを local-first software と呼ぶ(Gitはリアルタイムコラボレーションこそ持たないがlocal-firstの一種)。起源はLotus Notes(1980年代)に遡り、今日はFirestore・Realm・Dittoのようなプロプライエタリ実装と、PouchDB/CouchDB・Automerge・YjsのようなOSS実装がある。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Sync Engines and Local-First Software") ## 書き込み衝突の解決 マルチリーダー(および[[リーダーレスレプリケーション]])最大の課題は並行書き込みの衝突である。解決アプローチは段階的に強力になる。(1) 衝突回避: 同一レコードの書き込みを常に同じリーダーへルーティングする(担当リーダーの変更時に破綻する)。(2) LWW(last write wins): タイムスタンプが最大の書き込みを勝者とするが、実態は「並行書き込みの一方をランダムに選んでサイレントに破棄する」ことでありデータ損失を伴う。実時間クロックを使う場合はクロック同期精度に強く依存する。(3) 手動解決: 全ての並行値(siblings)を保存し、次回読み取り時に全て返してアプリ/ユーザーにマージさせる。CouchDB等が採用するが、API複雑化・ユーザー負担・マージ処理自体が新たな衝突を生みうる問題がある(Amazonのショッピングカートで削除済み商品が復活する異常が実例)。(4) 自動解決: テキスト・コレクション・カウンタ・キーバリューマップ向けの型別マージアルゴリズムで、全レプリカが同一状態へ収束することを保証する。これを「強い結果整合性(strong eventual consistency)」と呼ぶ。CRDT(conflict-free replicated datatypes)とOperational Transformation(OT)がその2大アルゴリズム系列であり、前者は文字/要素へ不変IDを付与して順序を決定的に定める(Redis Enterprise, Riak, Azure Cosmos DBが採用)、後者は挿入位置のインデックスを並行操作に応じて変換する(Google Docsが採用)。両者は性能・機能のトレードオフを持つが1つのアルゴリズムに統合することも可能とされる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Dealing with Conflicting Writes", "Automatic conflict resolution", "Conflict-free replicated datatypes and operational transformation") ## 横断的知見 - 未収載(2ソース目以降で充実させる)。 ## 未解決の問い - 地理分散マルチリーダーとリーダーレスレプリケーションはいずれも「リージョン間ネットワーク問題への耐性」を主目的とするが、実運用ではどのような判断基準(書き込み衝突の許容度・整合性要求)で選択されるか。既存の [[地理分散SQLデータベース]] concept との突き合わせが必要。 - CRDTとOTの性能・実装複雑性トレードオフは、具体的にどのようなワークロード(文書共同編集 vs リストの並行更新等)でどちらが有利になるか。 - ローカルファーストソフトウェアのsync engineが要求する「オープンな同期プロトコル」は、実際にどの程度の相互運用性(複数サービスプロバイダ間でのデータ移行可能性)を実現しているか。 ## 関連 - [[単一リーダーレプリケーション]] — マルチリーダーが緩和する制約の起点となる方式 - [[リーダーレスレプリケーション]] — 書き込み衝突という同じ課題を持つもう一つのアーキテクチャ - [[地理分散SQLデータベース]] — マルチリーダー地理分散運用と対比される分散SQLアプローチ - [[結果整合性]] — 自動衝突解決が達成する「強い結果整合性」の上位概念 ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]](マルチリーダーレプリケーションの定義・地理分散運用・トポロジー・同期エンジン/ローカルファースト・衝突解決の詳細)