本番のALTER TABLE A ADDに関して

Question

■ 環境

• AWS RDS Aurora MySQL 5.7.12

本番環境でalter table a addを行う予定です。
alterは、実行中に本番環境に影響が出るため、メンテナンスにしてSQLを走らせると聞きました。

メンテナンスの都合がつかない場合は、addするカラム用に別テーブルとして作成して、対象のテーブルにjoinさせて運用して、
メンテナンスの都合がついたら、その時にalter table addしてカラムとして追加するのでしょうか。

本番環境でalter table a addする場合の運用サンプルを教えて頂けると助かります。
よろしくお願いいたします。

Answer 1

メンテナンスの都合がつかない場合は、addするカラム用に別テーブルとして作成して、対象のテーブルにjoinさせて運用して、

メンテナンスの都合がついたら、その時にalter table addしてカラムとして追加するのでしょうか。

よほど特殊な状況を除いて、そんなことは行いません。「JOINする場合」と「しない場合」の違いが別なバグを呼び込んでしまいます。

Comments

[yookoko]

ご回答ありがとうございます。

Answer 2

メンテナンスの都合がつかない場合は、addするカラム用に別テーブルとして作成して、対象のテーブルにjoinさせて運用して、
メンテナンスの都合がついたら、その時にalter table addしてカラムとして追加するのでしょうか。

やってやれなくは無いですが、普通はリスクとコストが大きくなりすぎるのでやらないです。

本番環境でalter table a addする場合の運用サンプルを教えて頂けると助かります。
よろしくお願いいたします。

状況によって異なるので、上記のお話をしている人しかわかりません。
（メンテナンスが必要　と言っている人に聞くのがベストです）

メンテナンスのタイミングを決定できる人に「メンテナンス出来ないとリリースが遅れますけど責任取ってくださいね」という交渉をするのが一般的じゃないでしょうか。

技術的には
想定されている様な方法や、例えば以下のような方法が考えられます。

1. あるタイミングでスナップショットを取ってコピーを作成する
2. コピーにALTER TABLEする
3. バイナリログなどからメンテナンス中に発生した差分をコピーに適用する
4. 参照先をコピー側に切り替える

とかでしょうか。
これも4のタイミングで完全にデータ齟齬が無いように出来るかどうかはアプリケーションやインフラのアーキテクチャがそれを想定している形になっていないと難しいです。
（そもそもそういう形になっているなら「メンテナンスウィンドウが必要」という状態にならないので。今回のケースだと無理だと思います）

Comments

[yookoko]

ご回答ありがとうございます。運用サンプル助かります。

Answer 3

テスト環境で実施し、検証して問題ない事を確認して、本番環境に同じ手順で実施する。

いきなり本番に適用なんて普通しないです。

そもそも、カラム追加するのは目的があるはずですし、対応するプログラムを作成してテスト行うなどの手順を抜きに項目を追加するだけなど意味がありません。