データベース移行を失敗させない進め方
計画がきれいにまとまるほど、一度本気で否定する人が必要です。データ事故は、スクリプトの打ち間違いよりも、途中で失敗したときの想定漏れから起きます。
進め方
移行が触る範囲を先に洗い出す
スキーマ変更、依存関係、トラフィック量を「変更の影響範囲を見積もる」に渡します。影響を受ける読み書き、定期処理、レポート、下流を挙げ、影響人数と復旧の難しさで上位三件を並べ、切り戻しのしきい値を出させます。この一覧は公開時に見る付録ではなく、次の計画レビューへの入力です。
計画を一度、本気で否定してもらう
計画にデータ量、停止可能な時間、切り戻し方法、関係チームの協力体制を添えて「このマイグレーション計画を否決する」に渡します。失敗する具体的な条件、「そのとき考える」と先送りされている論点、一部だけ移行する・二重書きする・読み取りだけ移すといった小さな代替案を出させます。最後に、どの二点を補えば通せるかを見ます。
移行・切り戻し・検証を一式で書く
スキーマと変更目的を「戻せるデータ移行スクリプトを書く」に渡します。バッチ分割、再実行できること、1 バッチあたりの上限を必須にし、長いトランザクションによるロックを避けます。不可逆な操作と切り戻し後の突合方法を明示させ、検証 SQL をバックフィル後・切り替え前・切り戻し前に実行し、期待値としきい値を持たせます。最初に、最もデータを失いやすい手順を指摘させます。
インデックスは項目ではなくクエリに合わせる
スキーマ、データ量、スロークエリを「データベースのインデックス設計をレビューする」に渡します。各インデックスがどのクエリの WHERE や ORDER BY に対応するかを書かせ、冗長なもの、使われないもの、無効になる書き方を指摘させ、書き込みと保存への影響を見積もらせます。最後に残す・消す・足すの三欄で結論を出させます。新しいインデックスは移行後に作り、書き込み負荷の増加を避けます。
行数ではなく実際のクエリで確認する
移行後にシャドウ DB か読み取りレプリカで、主要なクエリを「SQLのパフォーマンス改善」に渡します。テーブル名、行数、実行時間、実行計画を添え、ボトルネック、書き換え後の SQL、必要なインデックス、書き込みが遅くなる副作用を出させます。本番で試さず、行数が合ったことを検証の代わりにしません。
使うプロンプト
よくある質問
データベース移行は必ず停止が必要ですか
変更の種類によります。NULL 可の項目追加や同時実行でのインデックス作成は、多くの場合オンラインでできます。型変更、テーブル分割、主キー変更は二重書きや段階的なバックフィルが必要になり、停止は最後の切り替えの短い区間だけになります。まず変更を分類し、それから時間帯を決めます。
移行スクリプトに切り戻しは必要ですか
必要ですし、移行スクリプトと一緒にレビューします。項目の削除やデータの上書きは本質的に不可逆で、切り戻しスクリプトで戻せるのは構造だけです。だからこそステップ3で、不可逆な手順を先に示し、バックアップか二重書きを用意します。
数百万行のテーブルはどう移行しますか
バッチに分け、1 バッチあたりの上限と進捗記録を持たせ、再実行できるようにします。少量のデータかシャドウ DB で通してから、バッチごとに進めます。一つの大きなトランザクションで変えると、ロック時間も失敗時のコストも読めなくなります。