要約

  • RFC 2372 は、PREPARED を送る前に prepared-recovery record を、Prepared 状態で COMMIT を送る前に commit-recovery record を作り、指定された解決証拠が届くまで保持するよう勧告した。
  • この順序はプロトコル上の発言をローカルな永続記憶に結び付けたが、安定媒体への書込み、障害後の再生、正しいトランザクション識別、アプリケーションが知る最終結果まで証明したわけではない。

分散トランザクションで最も危うい語は、COMMIT ではなく PREPARED かもしれない。

COMMIT は終着点に聞こえるため、その意味は吟味されやすい。PREPARED は途中の応答として受け流されやすい。参加者は準備を終え、調整者が後で決め、処理は続く。しかし従属側が PREPARED を発した瞬間、自分だけの都合では戻れない境界を越える。ソケットが切れ、プロセスが再起動しても、トランザクションを無かったことにはできない。将来の決定に従える状態を保存すると、相手に約束したからだ。

1998 年 7 月の RFC 2372 は、その約束を回復記録の順序として見える形にした。これは Informational RFC であり、インターネット標準ではない。プロトコル動作とログ動作の対応も決定版ではなく助言だと明記する。この慎重な位置付けは重要である。製品導入、特定のストレージ、クラッシュ試験、回復成功を報告した文書ではない。それでも、故障後まで効力を持つ状態をソフトウェアが宣言するなら、その状態を再構成する証拠を先に管理下へ置く、という基盤設計の原則が読み取れる。

PREPARED が選択権を変えた

TIP は presumed-abort 型の二相コミットを使う。参加者が prepare する前なら、障害後に abort へ解決できる。prepare した後は一方的に退けない。上位側は全投票を集め、すでに commit を決めているかもしれない。したがって従属側は、会話を消した障害そのものを越えてトランザクションを覚えていなければならない。

RFC 2372 の順序は具体的だ。従属側は PREPARED を送る前に prepared-recovery record を作成し、ABORT、COMMIT、QUERIEDNOTFOUND のいずれかを受けるまで保持する。その記録が存在する間に COMMITTED や NOTRECONNECTED を送ってはならない。これはメッセージのキャッシュではなく、まだ解かれていない義務の保管である。

上位側にも別の負担がある。まず PREPARED を受け、Prepared 状態から COMMIT を送る前に commit-recovery record を作る。COMMITTED または NOTRECONNECTED が戻るまで保持する。障害後に再送するかもしれない決定は、外へ出る前にローカルで再現可能でなければならない。

これは単なる「重要な出来事をログに書く」以上の規則である。PREPARED は参加者をローカルな自由から外部に拘束された責務へ移す。COMMIT は上位側を熟慮から、後で反復しなければならない決定へ移す。記録の削除も掃除ではない。指定された証拠が責務を閉じた、という主張なのである。

接続は記憶ではなかった

TIP はアプリケーションの会話とトランザクション調整を別の経路に分けた。業務要求は HTTP のような仕組みを通り、トランザクション・マネージャは別の接続で命令を交換できる。この二本立てはプロトコルを再利用しやすくしたが、接続だけでは履歴を持てなくした。

障害後、上位側は従属側のトランザクション識別子を使って RECONNECT を送る。必要なら識別子をトランザクション・ログから回復する。従属側がまだ Prepared 状態なら RECONNECTED、すでに COMMIT を受け、COMMITTED を返して忘れていれば NOTRECONNECTED と答える。否定形は必ずしも失敗ではない。規定の履歴の中では、処理を終えて状態を解放済みだという証拠にもなる。

従属側から QUERY することもできる。QUERIEDEXISTS は上位側がまだ知っており、後で再接続することを意味する。QUERIEDNOTFOUND なら従属側は abort できる。上位側は ABORT を送り、ABORTED を受け取れないまま presumed-abort のトランザクションを忘れた可能性があるからだ。同じ「見つからない」でも、役割、状態、メッセージ履歴がなければ意味は決まらない。

だから TCP 接続の復旧はトランザクションの回復ではない。転送層は端点を再び話せるようにするが、正しい識別子、未解決の義務を持つ側、欠けた記録が「安全に完了」「推定中止」「喪失」のどれかを再構成しない。回復にはローカルな永続識別と遠隔のプロトコル証拠の接合が必要だった。

削除を許す受領証は左右で違う

prepared record と commit record を閉じる万能の信号はない。従属側は ABORT、COMMIT、QUERIEDNOTFOUND のいずれかまで待つ。上位側は COMMITTED または NOTRECONNECTED まで待つ。この違いは両者の知識の位置が異なることを表す。

従属側にとっては権威ある決定、または上位側がもはやトランザクションを知らないと示す照会結果が prepare の義務を解く。上位側にとっては参加者の確認、あるいは完了して忘れた参加者へ再接続できないという特定結果が COMMIT 再送の必要を閉じる。時間切れ、プロセス復帰、ディスク逼迫、「たぶん終わった」という運用者の推測は削除許可に含まれない。

タイムアウトは別の役割を持つ。RFC 2372 は、ローカルなトランザクション・タイムアウトで資源の利用不能を制限し、デッドロックを解くことを見込んだ。しかし経過時間は正しい結果の証明にはならない。資源の解放、プロトコルの解決、回復後に何を知るかは別々である。

書かれた順序は永続化の順序を証明しない

「回復記録を作る」はストレージ層へ降りると曖昧になる。ユーザー空間のバッファ、カーネルのページキャッシュ、ジャーナル、媒体への flush、別障害領域への複製、永続性を持つ acknowledgement のどれを create と呼ぶのか。部分書込みは起きないか。揮発性インデックスを失っても識別子から記録を探せるか。非同期送信がログの安定化より先に PREPARED を出さないか。

RFC 2372 はそれらを解かず、解いたとも主張しない。要求と補足情報を示したのであり、データベース、適合試験、電源断注入、回復時間を提示した文書ではない。回復記録は実装し検証すべき義務であって、実装済みであることの証明ではない。

Heng Lu の running-code を優先する視点を当てると、文章は正しいソフトウェアが守る順序を規定できる。運用証拠はその先にある。永続書込みを観察し、最も不利な瞬間にプロセスを止め、再起動し、識別子を再構築し、相手と照合し、ローカル資源の結果を確かめる。RFC は試験の形を与えるが、合格印までは与えない。

削除も同じである。指定メッセージの後だけ記録を消しても、削除が資源マネージャの対応状態より先に永続化すれば誤る。反対に、古い記録を安全だが永久に残せば、資源と運用の負担になる。正しさはもっともらしい名前のファイルではなく、プロトコル状態、ログ状態、資源状態の検証可能な関係に宿る。

委任は責任を移し、消しはしない

RFC 2372 は軽量クライアントと、より完全なサーバーを区別した。クライアントは調整をサーバーへ委任し、自前のトランザクション・ログを持たずに済む。永続機構は減るが、回復責任は消えず、その役割を受けたシステムへ移る。

「クライアントのログは不要」を「永続証拠は不要」と読んではならない。クライアントがその証拠の保管者ではない、という意味だ。監査は義務をサーバーまで追い、どの識別子で何を記録し、どの発言より前に保存し、どの受領証の後に消したかを問わなければならない。

委任しても、呼出し側の知識は自動的には確定しない。クライアント・アプリケーションが commit を呼び、最後の応答を受け損ねても、トランザクションは完了していることがある。RFC 2372 は結果確認をアプリケーションの責任とし、実装固有のユーザー・ログが役立つと述べる。トランザクション・マネージャは回復に成功しても、仕事を始めた人やサービスは業務上の結末を知らないままになり得る。

ここに、既存の RFC 2371 記事との違いがある。プロトコル定義の記事は COMMIT が業務受領証ではないという広い境界を扱った。本稿が RFC 2372 から取り出すのは、回復を支えるローカル証拠の連鎖である。参加者の prepared record、上位側の commit record、故障後に戻る識別子、そして各記録を消してよいとする特定の遠隔信号だ。

二本の経路はアプリケーションに順序を要求した

アプリケーション通信と TIP 命令が別経路なので、トランザクション・マネージャはアプリケーション要求がまだ飛行中かを必ずしも見られない。RFC 2372 はアプリケーションに規律を求めた。関連要求が未完了の間に commit を呼ばず、ローカルのトランザクション・マネージャが登録する前に相手のトランザクション要求へ肯定応答しない。

この直列化に違反したアプリケーションを、どれほど丈夫なログでも直せない。完全に永続な commit record が、不完全な業務操作集合への決定を保存しているだけかもしれない。完全に再構成した TIP 状態が、早すぎたアプリケーション応答と結び付いているかもしれない。各層は同時に調べる必要があるが、同じ層として扱ってはならない。

これは現実の層を分ける問題である。要求、ローカル資源動作、TIP 状態、ログ記録、ストレージ確認、ネットワーク・メッセージ、回復識別子、相手の応答、最終資源結果、クライアントの理解は連なるが同一ではない。一つが真でも、次は未知であり得る。すべてを「コミット済み」という一語へ畳むと、証拠より速く確信だけが生まれる。

セキュリティは相手を認証しても全体を証明しない

RFC 2372 はアプリケーションの認証と認可を TIP の外に置いた。TIP 自身の懸念は、無権限の命令や信頼するトランザクション・マネージャのなりすましである。TLS は端点を認証し命令を暗号化できるが、使用は交渉事項だった。

正しく認証された TLS 接続も、相手が回復記録を永続化したこと、アプリケーション要求が認可されたこと、資源マネージャが正しい操作をしたこと、後続の業務システムが結果を認めたことまでは証明しない。端点の身元は証拠連鎖の一辺を守るが、ローカル永続性や業務権限の代わりではない。

回復では信頼された経路と正しい識別子の両方が要る。認証済みでも間違ったトランザクションなら誤りであり、なりすましから正しい識別子が届けば危険である。セキュリティ、状態、業務認可の証拠は互いを補う。

最小仕様は将来の実装判断をローカルに残した

RFC 2372 は共通ログ形式、ストレージ、API、運用画面を規定しなかった。相互運用に必要なのは命令、役割、識別子、回復の意味の共有であり、同じデータベースではない。

Heng Lu の minimum initial specification の視点では、これは将来の判断を局所化した境界である。RFC は会話が切れた二つのシステムが和解するための共通部分を示した。各実装は、記録をどう永続化し、資源状態とどう結び、曖昧さをどう利用者へ見せ、障害経路をどう試すかを選べる。その自由には立証責任が付く。

仕様を指すだけでは回復能力の答えにならない。問うべきは観察可能な事実だ。メッセージ前に記録は永続化したか。電源断を越えるか。揮発性インデックスなしで識別子を再構成できるか。どの受領証が削除を許すか。削除とローカル完了の順序は正しいか。最終応答を失ったクライアントは結果を知れるか。

現代の分散システムも、故障の前に「受理」「複製済み」「ready」「認可済み」と語る。各語は何が後に残るかという期待を作る。RFC 2372 の教訓は、ログがあれば言葉が真になるということではない。故障後まで結果を持つ状態語には、検査でき、永続し、正しく先行する証拠オブジェクトが必要なのである。

出典