夏のドキッとしたmigrateの話

はじめに

現在担当しているプロジェクトでは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が切られたけどプロセスは生きていて大事には至らなくて本当によかった事案｡今後も起こりえる可能性があるので､未来の自分のためのエントリになります｡

@Konboi memo

主に技術に関してつらつらと。

夏のドキッとしたmigrateの話

はじめに

起こったこと

今後の対策

まとめ