はじめに
現在担当しているプロジェクトではmigrateにGitDDLを使っております。 先日本番環境でそれなりにデータが入ったテーブルに対してALTERをかけました。 その際に起こったちょっとドキッとする話を今後の自分のためにも書いてこうと思います。
GitDDLについての記事はこちら: #5「GitDDLまじイノベーティブ」 tech.kayac.com Advent Calendar 2012
起こったこと
下記の用な変更を本番のDBに対して適用することになりました
CREATE TABLE atarashi_table ( id integer(10) unsigned NOT NULL auto_increment, nanka text NULL, iroiro text NULL, PRIMARY KEY (id), ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; ALTER TABLE oki_table ADD COLUMN tsuika_column integer(10) unsigned NOT NULL DEFAULT 0;
migrate自体はこの様なコマンドを用意して実行しています
./env-exec perl script/db/migrate
それなりに大きいテーブルだったので、stgでの確認も十分行い大丈夫だろうと実行
しかし現実は甘くはなかった
Connection Time Out…
とmigrate中にmysqlとのconnectionが切断された。 dbの設定で
mysql_connect_timeout=15 mysql_write_timeout=15 mysql_read_timeout=10
と設定していたので実行中にその時間を経過してしまったようである。 非常に焦る。
恐る恐る show tables をしてみると atarashi_table
はできている
ただ、この段階では oki_table
には まだ tuika_column
が追加されていない。
とりあえず落ち着いて現状を他のPGに共有。 すると先輩エンジニアから mysql のプロセスを見てみる。
mysql> SHOW PROCESSLIST;
するとcolumnを追加していると思われるプロセスが。
少し待つと oki_table
に tsuika_column
が追加されている事を確認。
とりあえずは一安心。
ただ migrate コマンド自体は途中で失敗したため git_ddl_version
が更新されず
./env-exec perl script/db/migrate
を再度行おうとすると
CREATE TABLE atarashi_table ( id integer(10) unsigned NOT NULL auto_increment, nanka text NULL, iroiro text NULL, PRIMARY KEY (id), ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; ALTER TABLE oki_table ADD COLUMN tsuika_column integer(10) unsigned NOT NULL DEFAULT 0;
の差分がでて実行すると
atarashi_table already exists
と言われ もちろんだけれど実行できない。
なので無事migrateが終わっているstaging環境のgit_ddl_version
のversionでupdateすることに
UPDATE git_ddl_version SET version = ‘hogehogeversion’
なんとか問題なく終了
今後の対策
migrateの実行ファイル内で connection time を長めに設定し直すか、migrateを実行する環境の設定ファイルで長めにするかのどちらかかと思っています。
まとめ
- migrationの実行はいつもドキドキする
- 何かあっても大丈夫なようにメンテナンスは余裕のある見積もりを。
- それでも何か合った時はまず共有しましょう
- やばいと思ったら深呼吸
- mysql> SHOW PROCESSLIST;
今回はconnectionが切られたけどプロセスは生きていて大事には至らなくて本当によかった事案。 今後も起こりえる可能性があるので、未来の自分のためのエントリになります。