ロールバック

🐾 猫で例えると？

ケージで並ぶ2匹へのごはんを想像しましょう。2つの皿へ配る途中で量を間違え、いったん両方を計量容器へ戻してやり直すイメージです。配り終えたことにする前に途中の変更を取り消します。失敗した事実まで消すわけではなく、DBの監査ログなどは別に残り得ます。

💻 データ・データベースにおける「ロールバック」とは？

実務におけるデータベース運用において、データの整合性（矛盾がない状態）を保つためのトランザクション管理は極めて重要な概念です。最も分かりやすい例が「銀行の口座振り込みシステム」です。Aさんの口座から1万円を引き落とし、Bさんの口座に1万円を入金するという処理は、必ず2つで1つのセットとして完結しなければなりません。

もし、Aさんからの引き落としが完了した直後に、通信障害やサーバーダウンが発生して入金処理が途中でストップしてしまったら、その1万円は世界のどこからも消えてしまい、データに致命的な矛盾が生じてしまいます。このような事態を防ぐために、一連の処理がすべて完全に成功（コミット）しなかった場合は、途中の変更をすべて破棄して、まるで最初から何も始まっていなかったかのようにデータを巻き戻します。この強力な安全弁がロールバックです。

⚠️ ロールバックの仕組みと注意点

変更前の情報や行のバージョンをどう扱うかは、DBの実装によって異なります。利用者がまず押さえるのは、BEGINで開始し、COMMITで確定、ROLLBACKで未確定の変更を取り消すという境界です。

ロールバックを伴うトランザクション処理のSQLイメージ

以下はトランザクション対応のDBで、更新結果を確定せず取り消す例です。既存のaccountsテーブルを想定しています。

BEGIN;
UPDATE accounts
SET balance = balance - 10000
WHERE user_id = 'A';
-- 確定しないと判断したため取り消す
ROLLBACK;

この更新はCOMMIT前なので取り消せます。通信断が起きた場合は、その接続でROLLBACKを送れるとは限りません。特にCOMMITの応答が届かなかったときは、確定したか不明な場合があり、再接続後の確認や二重実行を防ぐ設計が必要です。

🛠️ ロールバックを賢く使うためのポイント

アプリケーション開発やインフラ設計においてロールバックを適切に機能させるには、エラーハンドリングの厳密な設計とリソース管理の考慮が必要です。

• トランザクションを放置しない：長時間の未確定処理はロックを保持し、他の処理を待たせる場合があります。ただし、待ちが発生しただけでデッドロックとは限りません。
• 取り消しにもコストがある：大量更新はDBによって取り消しや後処理に時間と資源を使います。処理を小さく区切れるか、事前に検討します。
• DB外の操作は別扱い：トランザクションを戻しても、送信済みメールや外部APIへの依頼まで自動で取り消されません。必要に応じて補償処理を設計します。

ごはんを計量容器へ戻しても、配り間違えた出来事まで消えるわけではないように、ロールバックも何でも巻き戻す機能ではありません。未確定のDB更新と、すでに送ったメールなどを分けて考えましょう。失敗時に何を取り消せるかを、処理を始める前に決めておくことが大切です。