分散データベースと2相コミット(2PC)・CAP定理
複数DBへの更新では、確定の足並み、同時実行の干渉、通信断時の応答を別々に設計します。2相コミット(2PC)は主に分散更新の原子性を扱う確定手順で、2相ロック(2PL)は同時実行制御です。名前が似ていても役割は異なり、2PCだけで分散処理全体の直列化が自動保証されるわけではありません。
第1相:準備して投票する
調整者は参加DBへPREPAREを求めます。参加者は制約や更新を検査し、確定できる状態を永続化してYESを返すか、確定できなければNOを返します。YESを返した参加者は、調整者の最終決定に従って後で確定できる状態と必要なロックを保持します。
全参加者のYESを得る前、NOやタイムアウトを受けた調整者はABORTを決定できます。一方、すでにCOMMITを永続的に決定した後で応答が来ない場合は、決定をABORTへ変更せず、同じ決定を再送して完了させます。すべてのタイムアウトを一律のROLLBACK条件としてはいけません。
第2相:決定を記録して伝える
全員YESなら調整者はCOMMIT決定を永続化して通知します。参加者は通知された確定・取消を行い、状態やロックを解放します。障害復旧後も同じ決定に従えるよう、決定ログと参加者の準備ログが必要です。
正常系の概要です。参加者と調整者は、応答前の永続化や障害復旧時の再送も扱います。
ブロッキング:準備後に決定が分からない
YESを返した参加者が最終決定を知らないまま調整者との通信を失うと、他で確定した可能性があるため勝手に取消できず、取消決定の可能性もあるため勝手に確定できません。他参加者が決定を知る場合などには情報を得て進められますが、全員が不明状態なら復旧を待つことがあります。
準備済み状態が長く残ると、ロックや管理資源を保持して他処理を待たせます。監視と復旧手順、調整者の決定ログ、再送・重複通知の扱いを設計します。「必ず永久に待つ」という意味ではなく、安全な決定が得られない間に待機し得るという問題です。
CAPでいう一貫性と可用性
CAPのCは、操作が単一の最新の読書きオブジェクトとして説明できる線形化可能性の意味です。ACIDのCでいう制約整合性や、単に全ノードの値がいつか等しくなることとは区別します。Aは、障害のないノードへの各要求が処理を完了できることを要求します。単にHTTPエラーを即座に返せばAを満たす、という意味ではありません。
通信が分断された際、双方が他方の更新を知らずに要求を処理し続けると、すべての操作を単一の最新状態として見せることはできません。一貫性を守るために片側の要求を待機・拒否すれば、その要求に対する可用性を失います。通常時も含めて「3つのうち好きな2つを選ぶだけ」の説明で済ませず、分断中の操作ごとの振る舞いを決めます。
Sagaの補償は、通常のROLLBACKとは違う
Sagaは、各サービスがローカルトランザクションを確定し、後の処理が失敗したときに業務上の補償を別トランザクションとして実行する設計です。注文登録後に在庫確保が失敗したら、注文を取消状態へ変えるなどの処理を行います。確定済みの変更を元のDBトランザクションのROLLBACKで取り消すことはできません。
補償は過去の履歴を完全に消すとは限らず、配送済みなど取り消せない操作もあります。再送に備える冪等性、処理状態の保存、メッセージの欠落防止、補償自体の失敗時の再試行・手動処理が必要です。2PCと同じ原子性や独立性を提供する方式ではないため、途中状態を利用者へどう見せるかも設計します。
演習1:調整者の障害
条件:参加者はYESを返した。調整者の最終決定は不明で、決定を知る他参加者もない。
問い:タイムアウトだけで取消してはいけない理由を答えよう。
解答例:他で確定済みの可能性があり、独自に取消すると原子性を破るため。
根拠:決定が不明の準備済み参加者と、決定前の調整者では判断可能な範囲が違う。
演習2:在庫不足の補償
条件:注文DBは登録を確定済み。後続の在庫DBで引当が失敗した。
問い:注文側で必要な処理を説明しよう。(35字以内)
解答例:確定済み注文を取り消す補償トランザクションを実行する。(27字)
根拠:元のROLLBACKではなく、新しい業務操作として確定する。
復習で確かめること
例の数値や業務条件を変えて同じ結論になるか確認してください。用語の定義だけでなく、問題文のどの条件から、どの制約・SQL・対策を選んだのかを自分の言葉で説明できれば、次の過去問に進みます。
出典と仕様を確認する
PostgreSQL 18:PREPARE TRANSACTION
関連するテーマ
次におすすめの学習
編集・検証について
編集・検証:IT資格ラボ編集部
IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。
編集方針・情報源・訂正方針を見る