サービスを止めずに DB のスキーマを変えるには、どうしますか

なぜ段階に分けるか

アプリを止めずに出し直すと、しばらくの間、古い版と新しい版が同時に動きます。たとえば、列の名前を name から full_name に一度に変えると、まだ動いている古い版が name を探して落ちます。

だから、スキーマはいつも「古い版も新しい版も動ける形」を保ちながら、少しずつ変えます。この進め方は、広げてから縮める (expand と contract) と呼ばれることもあります。

列の名前を変える例

1. 列を足す新しい列を、空 (NULL) を許す形で足します。古い版は新しい列を知らないので、そのまま動きます
2. 両方に書くアプリを直して、書くときは古い列と新しい列の両方に書きます。読むのは、まだ古い列です
3. 古いデータを移す前からある行の値を、新しい列へ少しずつ写します
4. 読む先を切り替えるアプリが新しい列を読むようにします。様子を見て、問題が無ければ次へ進みます
5. 古い列を消す古い列を書くのをやめ、古い版がどこにも残っていないのを確かめてから、列を消します

-- 1 列を足す (空を許す)
ALTER TABLE users ADD COLUMN full_name TEXT;

-- 3 古いデータを少しずつ写す (1 回に写す行を絞る)
UPDATE users SET full_name = name
WHERE full_name IS NULL AND id BETWEEN 1 AND 10000;

-- 5 古い版が残っていないのを確かめてから消す
ALTER TABLE users DROP COLUMN name;

どの段階でも、アプリを 1 つ前の版に戻しても動きます。列を消す最後の段階だけは戻せないので、いちばん後に回し、控え (バックアップ) を取ってから行います。

大きな表で気をつけること

行の多い表にいきなり NOT NULL の列を足す、型を変える、インデックスを作る、といった変更は、DB や変更の種類によっては、長い間表をロックしたり、全部の行を書き直したりします。その間は読み書きが止まり、実質的にサービスが止まります。

DB ごとに、ロックを短くする方法 (インデックスを作りながら読み書きを止めない指定など) があるので、使う DB の文書で確かめ、本番に近い量のデータで先に試します。データを写すときも、1 回で全部写さず、少しずつ分けて写します。

トレードオフ

段階に分けると安全ですが、配備の回数が増え、しばらく両方に書くコードが残り、終わるまで期間がかかります。途中で止めてしまうと、使われない古い列や両方に書くコードが残り、かえって分かりにくくなります。

利用者がまだ少ない、夜間に止めてよいと決めている、といった場合は、お知らせを出して短く止め、一度に変えるほうが早く確実なこともあります。止めてよいかどうかを先に決めてから、進め方を選びます。

話すときは、自分が関わったサービスでスキーマを変えた例を 1 つ用意し、何段階に分けたか、途中で戻せるようにしたかを話します。