良いあそなすちゃん

良い方のあそなすちゃんです!

先週やったMySQL5.5から5.6にアップグレードした話をします。

先週の金曜日の20時に tmix.jp のメンテナンスをやっていて、MySQL5.5を5.6にアップグレードするなどをしていました。
その時の具体的な手順や経緯などを書き記す。会社のブログでもよかったんだけど、そんなに大したことはやってないので個人の日記レベルでよさそう。

そもそもなんでアップグレードしたのか

ぶっちゃけ5.5だったらまだ5.6にも近いし、そこまでアップグレードに急を要する感じではなかったのですが、そこに至るまでには結構思慮があったんです。

該当のDBサーバはRDSを使っていて、RDS使っている人は知ってると思うけど、インスタンスに割り当てるParameter GroupがそのインスタンスだけAWSが提供するデフォルトのものになっていた(と書けば多分みんな微妙な顔になると思う)
まぁ、それを自前で用意したParameter Groupにする必要があって、Parameter Groupを変更するにはRDSの再起動が必要なわけで、あー、ついでだからインスタンスタイプも変えちゃう?さらに5.6にしちゃおう。みたいな流れでした。

用意されていたゴールとそれまでの道

いくらなんでもサービスインしていて日に幾ばくも稼いでいるサービスを止めるんだからもう少し慎重になるべきというのはわかる。

しかしまぁ、開発側の話をすれば、実のところ、MySQL5.6は開発環境と確認環境ではすでに動いていて、両環境に流し込んでいるデータは本番データをマスクしたものが入っていて、実のところデータのマイグレートというのは去年のうちに終わっている状態なのでした。各環境とのDB同期も毎月ぐらいの頻度でやっていたのでそれなりに実績が積まれていました。
なので、「いつやるのか?」というのが半年ぐらい続いていました。

あと、これは少し微妙な話でもあるんだけど、このサービスでは昔からデータベースはただの容れ物として使っている様子があって、データを保護する制約がほとんどない状態です。最悪の場合でもデータ移行もmysqldumpしたものを突っ込めばものの10分から30分程度で終わるような体制になっていました

実際の手順

メンテナンス時間を最小にしたいという気持ちがあったので、現行のインスタンスを動かしつつ、裏で新しいインスタンスを立ち上げておいて、

1. メンテナンスモードに入る
2. アクセスがなくなったことを確認して、データのマイグレートを行う
3. 接続先のDBサーバを変更(database.ymlを更新してデプロイ)
4. 会社のIPを背負ってメンテナンスモードをパスしてひと通り動作確認
5. メンテナンスモード解除

という感じでした。メンテナンス時間は多分30分から40分ぐらいでした。
少し余裕を持って行動していたのでもう少しタイトにすることも出来ましたが、金曜夜のメンテナンスだったので。(まぁ一家言あるけど)

メンテナンスに入るときの注意

今回の場合だとRailsがDBサーバに繋がらなくなるので、前で受けているNginxで503をだしつつメンテナンス画面を表示させていました。
雑につくったメンテナンス画面だったので少し難ありだったけど...

まとめ

事前に準備をしていたり、いつでもサービスインできるような状態をつくっておいたため、大きな問題がおきることなくMySQLのアップグレードを行うことができました。
弊社のWebサービスで使われているDBはこれですべて5.6になりました。これからもカジュアルにMySQLのアップデートを行えるように日々頑張っていこうと思います。

メンテナンス開けの様子です

f:id:asonas:20150323172102p:plain