は、過去の時点のデータを参照・復元できる機能です。誤った削除や更新の直後に、その場で戻せます。運用上の安心感は大きい。
一方で、保持期間は保管費用に直結します。この回は、戻せる範囲をどう設計するかを扱います。
1. 何ができるのか
できることは大きく3つです。過去の時点を参照する、その時点の内容で複製を作る、削除したものを復元する。
-- 5分前の状態を参照する（現在のデータには影響しない）SELECT * FROM orders AT (OFFSET => -60 * 5);
-- 特定の時刻の状態を参照するSELECT * FROM orders AT (TIMESTAMP => '2026-10-06 09:00:00'::TIMESTAMP_LTZ);
-- 問題のあった更新の「直前」を参照する（その処理を除いた状態）SELECT * FROM orders BEFORE (STATEMENT => '01a2b3c4-...');
-- その時点の内容で別テーブルを作る（比較や検証に使う）CREATE TABLE orders_before_incident CLONE orders AT (TIMESTAMP => '2026-10-06 09:00:00'::TIMESTAMP_LTZ);
-- 削除したテーブルを復元するUNDROP TABLE orders;実務で最も使うのは3番目です。特定の処理の直前を指定できるため、「あのバッチが壊した」と分かっている場合に、その処理を除いた状態を正確に取り出せます。
事故の直後に元テーブルへ直接書き戻すのは危険です。まず過去の時点で複製を作り、現在と比較して、何が変わったのかを確認してください。原因を把握しないまま戻すと、正当な更新まで巻き戻すことになります。
2. 保持期間と費用の関係
費用は、保持期間 × 変更量でおおよそ決まります。ここで効くのは期間ではなく変更量のほうです。
| 表の性質 | 過去の版の量 | 保持期間の考え方 |
|---|---|---|
| 追記のみ（ログなど） | 少ない | 長めでも費用への影響は小さい |
| 一部を更新 | 中程度 | 業務上の必要期間で決める |
| 毎回全件を入れ替え | 非常に多い | 短くする。日数分の複製が積み上がる |
| 一時的な作業用 | 不要 | 最短にする、または一時テーブルにする |
3行目が費用の主犯になりやすい形です。毎日全件を入れ替えると、保持日数ぶんの複製がそのまま積み上がります。EP.3 で「現在の量より過去の版のほうが大きい表」を探しましたが、そこで見つかるのはたいていこの形です。逆に言えば、全件入れ替えを差分更新に変えると、性能と保管費用の両方が同時に改善します。この構造は パフォーマンスチューニング実践 EP.07 で扱ったバッチの差分化と同じ話です。
-- 一時的な作業用テーブルは保持しないALTER TABLE staging_orders SET DATA_RETENTION_TIME_IN_DAYS = 0;
-- 重要な業務データは長めにALTER TABLE contracts SET DATA_RETENTION_TIME_IN_DAYS = 30;
-- 現在の設定を確認するSHOW TABLES LIKE 'orders%';
-- データベース単位の既定値も設定できるALTER DATABASE staging SET DATA_RETENTION_TIME_IN_DAYS = 1;一時テーブルや作業用の中間データに、本番と同じ保持期間を設定しているのは非常によく見る形です。ここを見直すだけで保管費用が下がることがあります。設定できる上限は契約する版によって異なるため、手元の環境で確認してください。
3. Fail-safe を当てにしない
Time Travel の期間が切れたあと、 という期間があります。ただしこれは利用者が自分で参照できません。提供元への依頼が必要で、時間もかかります。
したがって、自分で戻せる範囲は Time Travel の期間内までと考えてください。Fail-safe は最後の保険であって、運用手順に組み込むものではありません。
利用者が使えないにもかかわらず、その期間の保管費用は発生します。EP.3 の集計で「保険GB」として出てくるのがこれです。変更量が多い表ほど、この分も積み上がります。
4. Time Travel でカバーできないもの
万能ではありません。何をカバーしないかを理解しておく必要があります。
- 保持期間を超えた過去 — 気づくのが遅れた事故には効かない
- 削除して作り直したテーブル — 同名でも別の実体になる場合がある
- 間違ったデータを取り込み続けた場合 — どの時点も正しくない
- 上流のデータそのものが失われた場合 — 取り込み元が消えていれば復元できない
1番目が実務では効いてきます。集計値の誤りは、気づくのが遅れるという性質を持ちます。誰も見ていない出力が壊れていた、月次で初めて気づいた ── こうしたケースでは保持期間を超えていることがあります。
したがって、Time Travel は「気づける仕組み」とセットでなければ機能しません。壊れたことに早く気づけるなら短い保持期間で足りますし、気づくのが遅い領域は長く持つか、別の手段が要ります。データ基盤トラブル事件簿 EP.06「数字が合わない」 に、気づくのが遅れる構造の例があります。
5. 復旧の手順を決めておく
機能があることと、事故のときに使えることは別です。手順を決めておかないと、慌てて余計な変更を加えることになります。
- 1まず止める — 壊し続けている処理があれば止める。これが最優先
- 2現状を保全する — 現在の状態も複製しておく。戻したあとの比較に要る
- 3過去の時点を複製する — 元テーブルには触らない
- 4差分を確認する — 何が変わったのかを把握してから判断
- 5戻す範囲を決めて適用する — 全件か、一部か
- 6記録する — 原因と、戻した範囲
2番目を飛ばしがちです。戻したあとで「やっぱり一部は残すべきだった」となったとき、現状を保全していないと取り返せません。複製は なら瞬時に作れて保管費用もほとんどかからないので、必ず作ってから作業してください（EP.7 で詳しく扱います）。事故対応の最中は判断が急ぎがちですが、この1手だけは省かないと決めておくと、後で選択肢が残ります。
6. 設計としてどう決めるか
保持期間は、気づくまでの時間から逆算します。
| データの性質 | 壊れたら気づくまで | 保持期間の目安 |
|---|---|---|
| 画面に出る、人が毎日見る | その日のうち | 短くてよい |
| 週次で確認する集計 | 1週間程度 | それを超える期間 |
| 月次でしか見ない | 1か月 | 長めに必要、または別の検知手段 |
| 誰も見ていない | 気づかない | 保持期間では解決しない。検知を作る |
最下行が本質的な指摘です。誰も見ていないデータは、保持期間をいくら長くしても救えません。ここに必要なのは復旧手段ではなく、壊れたことに気づく仕組みです。保持期間の議論をしていて最下行に当たったら、それは別の問題を扱うべきというサインです。
実務で最も使うのは特定の処理の直前を指定する参照。費用は期間よりも変更量で決まり、毎回全件入れ替えが主犯になりやすい。一時テーブルの保持期間は見直す価値がある。Fail-safe は自分で使えないので当てにしない。保持期間は気づくまでの時間から逆算し、「誰も見ていない」なら検知の仕組みを先に作る。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。