公式手順でsqaleからHerokuに移行する

国産PaaSのsqaleさんが、サービスシャットダウン。

ということで、移行せよとのメールがきた。

後日、Herokuの移行手順公開したよ。とのメールがきたので、いざやってみた。

1. sqaleからDBをエクスポート

公式サイトに手順があるが、sshでログインして、mysqldumpコマンドでダンプを取得せよとのこと。

ただ、sqaleの環境からファイルをダウンロードする手段は提供されてない ので、なぜかawsのs3に転送しなければならないという鬼仕様。 そんな手順知らね。っていう人は、Heroku側のDBへのインポートも、sqaleのサーバからmysqlコマンドを実行することになると思われ。

俺の場合は、以前からawsにバックアップとるようにしてたので、aws経由でローカルにダンプファイルを持ってきてやった。

2. Herokuにアプリ作成・DBインポート

アカウントはすでに作ってたので、新規にアプリ作って、git push。なんかエラー出とるが、とりあえず無視。

mysqlコマンドで、ダンプしたファイルを食わせる。手順上、ClearDB MySQLの環境情報を調べるとこがわかりにくかった。
移行手順の画面上の「ClearDB MySQL」のリンクを押すと、ダッシュボードに飛ぶので、そこに自分のDB名が表示されており、それをクリックして、「ENDPOINT INFORMATION」というタブに遷移すると、userとpasswordが記載されている。

なお、ホスト名は、手順書通り、「us-cdbr-iron-east-04.cleardb.net」でOKである。

で、いざ食わすところで手順は終わりなのだが、直後にメールが飛んできた。

subject: [CRITICAL] ClearDB database size is near quota limit

Current database storage allocated: 91.88% (8.12% remaining)

これは、予期してたが、無料プランのDBの容量はいきなりギリギリ。追加するための有料プランは、$9.99で、Herokuのdynosの$7と合わせると、月額$16.99 とsqaleの940円の倍以上の金額に。

むむむ、EC2借りた方が安いやんけ。DigitalOceanやったら、$5やぞ。

まぁ、そこはさておき、とにかく、アプリケーションに接続や！

ですよね。

薄々知ってたけど、deproy時に、rubyのバージョンが古いから、2.2.6に上げてデプロイするぜ。（sqale上は、2.1.0で動かしてた）って言われてたから、そこらへんか。

ローカルで、rubyのバージョン上げてbundle update したら、エラー吐きまくり。がおー。

gemの依存関係を修正したあとには、Heroku用に、Procfileを作成したり、database.ymlを修正したりして、２日間かけてようやく移行完了となりました。

あとは、DNSとか切り替えなきゃ。

結論：

手順は確かに簡単だが、Herokuになると、課金が２倍になる。（940円 → 1,916円（$16.99））

また、CleaDBの無料枠だと、使えるDBのプロセス数の関係で、重たい処理を流すと、DBがプロセス周りのエラーを吐き、Internal Serverエラーとなってしまう。なので、容量の問題以外にも、有料枠を使わざる得ない状況となってしまった。やはり、Herokuは、初めて使うPaaSとしてはハードルが若干高めな気がするなぁ。

後日発生した問題１ 処理時間が長いクエリが強制的にタイムアウトしちゃう

Herokuは、Webのリクエストタイムが30秒を超えるとタイムアウトで処理が落ちる。

で、ちょうど30秒超こえるかどうかのくらいのバッチ的な処理をWebからキックする処理があったのだが、見事にタイムアウトに引っかかってしまった。

そういうケースは、Herokuの場合、非同期処理として対応する必要があるようだ。

が、なんか処理結果見てみるとギリギリ処理は終わってたらしいので、まぁ、ほっとく。

後日発生した問題２ ：MySQLのauto_increment の値が変わる。

登録したレコードのIDがやたら飛ぶので、調べてみたら移行時に変わってた。

mysql> show variables like ‘%auto_inc%’;
+————————–+——-+
| Variable_name | Value |
+————————–+——-+
| auto_increment_increment | 10 |
| auto_increment_offset | 2 |
+————————–+——-+
2 rows in set (0.18 sec)

なので設定を変更する。

mysql> set @@auto_increment_increment=1;
mysql> set @@auto_increment_increment=1;

あとは、各テーブルについても、alter tableで、次の auto_increment 値を変更していった。

なぜかは不明。 → 設定変えてもまた同じ減少が発生するので調べたら、clerdbの仕様でした。レプリケーション時にIDが衝突しないための仕様だそうだ。 http://qiita.com/nsatohiro/items/0458e63c47c3d6ff37d0