マイグレーション — 流した瞬間に、書き込みが全部待つ

What — 流した瞬間に何が起きるか

ALTER TABLE は、実行したその瞬間から終わるまでの間、テーブルの形を触ります。読み書きと完全に同時にはできないので、どこかで必ずロックが要ります。

DDL

Data Definition Language。テーブルの形を変える操作。CREATE / ALTER / DROP。

メタデータロック

テーブルの定義を守るためのロック。クエリの実行中はずっと保持される。

オンライン DDL

処理中も読み書きを通す方式。開始と終了の一瞬だけはロックが要ることが多い。

バックフィル

既存の行に値を埋める処理。行数に比例して時間がかかる。

変更の種類で、危険度がまったく違う

「スキーマ変更」とひとまとめにできません。

ALTER TABLE members ADD COLUMN plan varchar(20)

Why — なぜ止まるのか

テーブルの定義は、実行中のクエリが前提にしているものです。SELECT の途中で列が消えたら、その SELECT は自分が何を読んでいるのか分からなくなる。だから DB は、クエリが走っている間そのテーブルの定義を固定します。これがメタデータロックです。

ALTER は定義を変えるので、誰も定義を握っていない瞬間を待つ必要があります。

「オンライン DDL」が解決したもの、していないもの

昔は ALTER の間ずっとテーブル全体が止まりました。いまは多くの DB が、処理の本体を読み書きと並行して進められます。これがオンライン DDL です。

ただし**「一瞬もロックしない」ではありません。** 開始時に定義を確定し、終了時に差し替えるので、その前後に短い排他ロックが要ります。

短ければ問題ない、と思えます。問題はその短いロックが取れないときです。

12:00:00  集計バッチがトランザクションを開始（12分かかる）
12:00:30  ALTER が短いロックを要求 → バッチ待ちで待機
12:00:31  注文の INSERT → ALTER の後ろで待機   ← ここから事故
12:00:32  ログインの SELECT → その後ろで待機
   ...    以降すべて待機
12:12:00  バッチ終了 → ALTER 実行（3秒）→ 溜まった分が一斉に流れる

ロック待ちは先着順です。 ALTER が待たされている間、そのテーブルに触るすべてのクエリが ALTER の後ろに並びます。読み取りも止まります。

つまり、止めたのは ALTER ではありません。ALTER が待たされたことで、その後ろが詰まったのです。

レプリカでもう一度走る

プライマリで終わっても、変更はレプリカに伝わってそこでも実行されます。構成によっては、レプリカがその間ずっと遅れます。

読み取りをレプリカに逃がしている場合、プライマリは無事なのに読み取りだけ古いという状態になります。「マイグレーションは終わったのに、画面に反映されない」の正体はこれであることが多い。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。