進まない、マイグレーション - Qiita

Railsで運用していた本番環境を、マイグレーションの加減で止めてしまいました。 経緯 AWS上にRailsで作ったプロジェクトがありまして、環境管理をElastic Beanstalkで行っていました。毎週1回、人の少ないタイミングに更新を行っていたのですが、あるときに反映したところで、マイグレーションが全く進まなくなってしまいました。 原因 もちろん、開発環境で同じマイグレーションは回していたので、マイグレーションの記載ミスではなかったのですが、本番環境にアクセスがあった中でマイグレーションを動かしてしまったこと、そして作成するマイグレーションが新しいテーブルを作るようなものではなく、既存のテーブルの定義を書き換えるものだったがために、ロックが絡み合って一向に進まなくなってしまったのでした。 その場での対応 ひとまず、強引にデータベースサーバを再起動して元の状態に戻して、古いバージョン

[catalog360]

分かりはじめた、マイレボリューション

[takumikabu]

まさにEBで検証環境リリース時にこれ起きて焦ったことある。一時的な停止は許容されるシステムだったので、本番リリース時は一般ユーザーからのDBアクセスがないようにロードバランサーで503を返す対応した。

[jacoby]

DB使ったシステム詳しくないんだけど、本番リリース前にDBアクセスの競合・追い越し時にデッドロックしないかという観点で設計・レビュー・検証はするもんでもないの？

[new3]

メンテ許さるならメンテを…許されない奴は経験ほぼないけど、MySQLのAlterは pt-online-schema-change かなと思う。

[rryu]

MySQLのALTER TABLEはコピー&リネームなので常時書き込みのあるテーブルに対して行うのはちょっと怖い。

[u1tnk]

あるあるー

[otihateten3510]

マイグレーション怖いから人生レベルで全力回避してる（逃げ技術者）

[send]

本番にalter流すときはpt-osc使ってる

[Kil]

Elastic Beanstalk使ってるなら、更新かけるときもBlue-Greenくらいすればいいと思う。本番環境なんだから。

[programmablekinoko]

スキーマ定義の変更を含むマイグレーションを本番環境にかけたら該当のテーブルが使用中でロックされててマイグレーションされなかったとな、そりゃまあ・・・（覚えはある）

[koogawa]

第8話「進まない、マイグレーション」