複製戦略

複製により、論理的に同一のデータが複数の場所に存在するようになる。フォロワーは、フェイルオーバーの受け皿、ローカルからの読み取り、負荷分散の役割を担うことができるが、データを複数保持するだけでは自動的に強い一貫性が得られるわけではない。誰が書き込みの順序を決定し、成功とみなすにはどの程度を待機し、読み取りでどのような状態を許容し、障害発生後に誰が書き込みを継続する権利を持つかを定義する必要がある。

4つの独立した次元に分解する

「同期複製」は主に確認待ちの条件を記述するものであり、「シングルリーダー」は主に書き込みの組織化方法を記述するものである。これらの用語のいずれかだけで、システム全体の保証を推測してはならない。

シングルリーダー：複製グループ内で順序を集中管理する

クライアントは書き込みをリーダーに渡し、リーダーはログの順序を形成し、変更内容をフォロワーに複製する。フォロワーはプロトコルに従ってログを適用し、クエリ可能な状態を形成する。ここで言うリーダーは、通常、シャードまたは複製グループのリーダーであり、必ずしもクラスタ全体で唯一の書き込みノードであるとは限らない。異なるシャードは、異なるマシンがリーダーを務めることができる。

同期と非同期：成功レスポンスはどの境界で発生するか

非同期複製では、リーダーはリモートフォロワーからの待機なしに成功を返すことができる。その後、リーダーが恒久的に失われ、かつ代替者がこれらの更新をまだ受信していない場合、⁠クライアントがすでに成功した書き込みを受け取っていても、データが消失する可能性がある⁠。単なる一時的なダウンでローカルの永続化ログが残っている場合は、データは後に復旧する可能性があるため、障害モデルを区別する必要がある。

同期複製では、指定されたリモート確認条件を満たすまで成功とみなさないが、「同期」が必ずしも「少なくとも1つのフォロワーがディスクに書き込んだこと」を意味するわけではない。プロトコルは、指定された数のノード、特定のメンバー、またはクォラムの待機を要求する場合もあれば、異なる進捗段階の待機を要求する場合もある。書き込みの遅延には、ログ処理、ネットワーク往復、キュー待ち、ストレージのオーバーヘッドが含まれ、fsyncの最大値2つだけで概括することはできない。

例えば、PostgreSQLはリモート受信、永続化、適用などの待機セマンティクスを区別しており、remote_applyを選択して初めて、待機がスタンバイ側の適用段階まで進められる。具体的な動作は設定と組み合わせて判断すべきであり、「同期」という言葉だけで任意のスタンバイ側が読み取り可能であると仮定してはならない。PostgreSQL 複製ドキュメント

1つのコミットレコードに対して、3つのフォロワーがそれぞれ異なる段階に達する可能性がある

ログ位置を簡略化した整数で表し、確認待ちのコミットレコードを108とする。現在のスタンバイ側の進捗は以下の通りであり、writeはOSファイル層への書き込み、flushは永続化、applyはリプレイ済みを示す：

progress = {
    "A": {"write": 110, "flush": 108, "apply": 104},
    "B": {"write": 110, "flush": 106, "apply": 106},
    "C": {"write": 107, "flush": 107, "apply": 107},
}

def reached(stage, position):
    return {node for node, stages in progress.items() if stages[stage] >= position}

assert reached("write", 108) == {"A", "B"}
assert reached("flush", 108) == {"A"}
assert reached("apply", 108) == set()
progress["A"]["apply"] = 108
assert reached("apply", 108) == {"A"}
assert "B" not in reached("apply", 108)

PostgreSQLにおいて、有効な同期スタンバイが設定されている場合、remote_writeは遠端のファイルシステムへの書き込みを待機するものであり、単にネットワークパケットが届いたことだけを意味するものではない。onは対応するスタンバイ側の永続化を待機し、remote_applyはさらに適用段階まで進める。remote_writeは、スタンバイデータベースプロセスのクラッシュとスタンバイ側のOSクラッシュに対して異なる保護を提供する。後者の場合、まだ永続化されていないデータが消失する可能性がある。synchronous_commit の定義

このモデルは、各段階でどのフォロワーに到達したかのみを示しており、FIRST/ANYのスタンバイ選択や完全なコミット条件の実装は含まれていない。実際に返却できるかどうかは、どのスタンバイがカウント対象となるか、いくつの確認が必要か、そしてローカルでの永続化が完了しているかどうかに依存する。Aの適用確認が現在の設定を満たす場合でも、それに基づいてまだ遅れているBへの即時読み取りをルーティングしてはならない。

フェイルオーバーは、任意のフォロワーをリネームしてリーダーにするものではない

安全なフェイルオーバーでは、プロトコルが要求するコミット済み履歴を保持し、資格のある候補者を選択し、旧リーダーが回復した後に成功した書き込みを継続しないようにする。確認済みのデータを持つフォロワーが存在する場合でも、遅れているフォロワーを代替として選択すれば、単に「以前は同期複製を使用していた」というだけでは、データが消失しないことを証明できない。

コンセンサスプロトコルは、選挙の資格、ログの整合性、コミットルールを組み合わせる。通常のマスター-スタンバイ複製では、フェイルオーバーメカニズムがこれらの保証を提供しているかどうかを確認する必要がある。旧リーダーの喪失を疑うことと、新しい書き込み権限を得ることは別の問題であり、詳細は障害検出を参照のこと。

フォロワーでの読み取りがライト・ユア・ライツを破綻させる理由

ユーザーがニックネームを変更してすぐにページを更新した場合、新しい読み取りがまだそのログを適用していないフォロワーに割り当てられると、古いニックネームが表示される可能性がある。関連する読み取りを、十分な新鮮さを保証するエントリポイントを経由させるか、書き込みレスポンスでバージョントークンを返し、読み取り側が自身の進捗を少なくともそのトークンまで待機させることができる。

トークンには、明確なスコープと順序関係が必要である。1つのシャードのログ位置を、他のシャードと無関係に比較することはできない。また、リーダーの任期を跨ぐ場合も、有効な履歴識別子が必要である。「書き込み後5秒間はメインノードを読む」という固定の戦略は、経験則として機能するかもしれないが、すべての遅延ケースにおいてライト・ユア・ライツを証明するものではない。

新鮮さトークンは、位置、履歴、読み取りスナップショットのすべてを制約しなければならない

ある書き込みが (orders, history-1, 108) を返すと仮定する。これは注文シャードの特定のログ履歴に属し、読み取りでは少なくとも位置108を含める必要がある。在庫シャードが999まで進んでいても、注文の読み取りを引き受けることはできない。また、互換性のない履歴の位置200を、108と直接比較することもできない。

from dataclasses import dataclass

@dataclass(frozen=True)
class Token:
    shard: str
    history: str
    position: int

def can_read(applied, required, snapshot_position=None):
    if (applied.shard, applied.history) != (required.shard, required.history):
        return False
    visible = applied.position
    if snapshot_position is not None:
        visible = min(visible, snapshot_position)
    return visible >= required.position

required = Token("orders", "history-1", 108)
assert not can_read(Token("orders", "history-1", 106), required)
assert can_read(Token("orders", "history-1", 108), required)
assert not can_read(Token("inventory", "history-1", 999), required)
assert not can_read(Token("orders", "other-history", 200), required)
assert not can_read(Token("orders", "history-1", 110), required, 100)

最後の assert は見落としがちな境界条件である。フォロワーは110まで適用済みだが、現在のトランザクションは100の履歴スナップショットに固定されており、適用を待ってもこのスナップショットは自動的に更新されない。読み取りで先ほどの書き込みを反映させる必要がある場合、許容される分離セマンティクス内で、十分に新しい読み取りビューを構築する必要がある。

これは「読み取りビューがログのプレフィックスに対応する」という抽象モデルであり、PostgreSQLの実際のMVCCスナップショット形式ではない。実際のシステムでは、トークンから読み取り条件への信頼できるマッピングを実装する必要がある。異なる履歴間でプロトコルによって継承関係が証明できる場合は、変換して検証できるが、例のようにすべて拒否してはならない。クライアントがトークンを独自に作成して認証資格として使用することもできない。

特定の書き込みが適用されるのを待つことは、その依存関係が要求する新鮮さのみを提供するものであり、すべてのクライアントの最新の書き込みを読み取れることを意味しない。線形一貫性読み取りを保証するには、現在のリーダー権限または対応する読み取りプロトコルが必要である。ライト・ユア・ライツとグローバルなリアルタイム順序は、異なる保証である。

受信、永続化、適用は、3つの異なる線である

待機戦略を比較する際は、まず「どのフォロワーを待っているのか」を固定し、次にその段階を比較する。ここでは同期スタンバイを1つだけ選び、ローカルの条件が満たされていると仮定する。write、flush、applyの3つの境界は順序を保つ。待機条件をflushからapplyに変更しても、それは今回の成功の約束を変更するだけであり、フォロワーに対してリプレイを強制的に実行するものではない。

$$\mathrm{apply}\le \mathrm{flush}\le \mathrm{write}$$

マルチリーダー：複数の場所で独立した変更を許可する

地理的に分散した独立した書き込みは、ローカルの書き込みレイテンシを低減し、一部のネットワーク分断時にもリクエストの処理を継続できる。その代償として、異なる場所では、お互いの更新をまだ見ていない状態で同一オブジェクトを変更する可能性がある。例えば、AとBが同時に連絡先住所を変更した場合、同期が回復した後に、これらのバージョンの保持、選択、またはマージを行う必要がある。

これは「2つのノードが書き込み可能である」というだけでは必ずしも衝突が発生するわけではない。テナントごとに書き込みサイトを固定するか、操作をマージ可能なタイプに制限することで、衝突を減らすことができる。ただし、サイト間で書き込み権限を移行する場合、オフライン編集、および並列作成については、明確なルールが必要である。成功前にサイト間で一意性を調整する必要がある場合、すべての書き込みを完全に独立したローカル操作として扱うことはできない。

リーダーレス：プロトコルがないのではなく、複数のフォロワーを調整する

Dynamoスタイルの複製では、リクエストコーディネーターがキーの複数のフォロワーと連携することを許可する。コーディネーターは必ずしもそのキーのフォロワーを持っているわけではなく、実際に確認条件を満たすフォロワーのみがWにカウントされる。機械的に「W-1の返信を受け取ったら、自身を加える」という処理をしてはならない。

固定されたフォロワー集合のサイズをNとし、1回の書き込みでW個のフォロワーの確認を得、1回の読み取りでR個のフォロワーを待機するとする。R+W>Nの場合、2つの集合は必ず交差する。しかし、交差することは、読み取りが確認済みの書き込みが残した情報に接触する可能性があることを示すだけであり、バージョンの選択、並行処理、未完成の書き込み、読み取り修復の処理は、依然としてプロトコルの一部である。

例えば、N=3、W=2、R=2の場合、書き込み1がAにしか到達せず、書き込みリクエストがタイムアウトしたとする。1回目の読み取りでAとBは1を見るが、2回目の読み取りでBとCは0を見る。プロトコルが「今回の最大バージョンを選択して返す」だけの場合、必要な伝播や読み取りによる書き込みの完了が行われていなければ、読み取られる値が後退する可能性がある。クォラムの数だけでは、線形一貫性を証明できない。

一部のリーダーレスのレジスタアルゴリズムでは、クォラムにバージョン情報と読み取りによる書き込みを組み合わせることで、線形一貫性を実現できる。したがって、リーダーレストポロジが弱い一貫性しか提供できないわけではない。完全なアルゴリズムを判断する必要がある。

障害時の一時保存と修復

Hinted handoffは、本来あるべきフォロワーに送信されるはずだった更新を一時保存し、復旧後に補送するために使用される。これは、ヒントの永続性、保持期限、および後続の修復に依存しており、任意のフォロワーが恒久的に失われた後でも必ず復旧可能であるという保証ではない。

Sloppy quorumは、一時的な代替ノードを受信に参加させることを許可し、書き込み可能性を向上させる可能性がある。しかし、読み書きで使用する候補集合が異なる場合、同じN上の交差証明をそのまま適用することはできない。詳細なパスは分散読み書きパスを参照のこと。

選択時にはまずビジネス要件を明確にする

次の読み取り：競合解決と分散トランザクション。

参考文献

• PostgreSQL：ログ複製と同期複製。
• Dynamo 原論文。
• Raft 原論文。

Keywords: replication, leader, follower, quorum, synchronous replication, read-your-writes, failover