どうも、すなです。
現在Serverless Frameworkでバックエンドを構成しているんだが、エンドポイントごとにLambda関数作ってて辛くなってきたのでExpressを導入してルーティングさせようと思っている。
それに先立って、これまでdev環境用のRDSに接続して開発していたのだが、そろそろつらくなってきたので開発環境用にローカルにMySQLサーバー立てようと思ったら色々ハマったのでメモ。
目指すゴール
まず何をやろうとしたかというと、開発環境用のRDSからdumpファイルを取得して、それをローカルのMySQLのデータベースのに反映させようとした。
dumpファイルはその時点でのDBの情報をファイルにエクスポートしたもの。
なのでこれを反映させて一件落着でしょと思ってた。。。
実際に実行した手順
まずRDSからdumpファイルを取得するのだが、踏み台のEC2からssh接続でしかアクセスできないようになっている。
なので手順としては以下の3段階
1. 踏み台サーバーでdumpファイルを取得
2. リモートの踏み台サーバーのdumpファイルをローカルに転送
3. ローカルのdumpファイルをローカルのMySQLのデータベースに反映
1. 踏み台サーバーでdumpファイルを取得
まずssh接続でEC2サーバーにログインする。
その後、以下のコマンドでEC2サーバー上にdumpファイルを取得する
mysqldump -h rds.host.name -u remote_user_name -p remote_db_name > /var/tmp/dump.sqlmysqldumpコマンドを使って取得したいRDSの接続情報を書き、EC2上にdumpファイルを取得する。
EC2上ならどこでもいいが、一時ファイルだし/var/tmpで良さそう。
これを実行したところ以下のようなWarningが。。。
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don’t want to restore GTIDs, pass –set-gtid-purged=OFF. To make a complete dump, pass –all-databases –triggers –routines –events.
なるほど！！
わからん！！！
わからないけどdumpファイルは無事に作成されたしいいかと思ったんだけど、最後にlocalのMySQLに反映させる時にGTIDsがなんやかんやでエラーはいたからやっぱよくないっぽい。
この辺軽く調べたけど結局よくわからなかった。。
わからなかったんだけど結論ここに書いてる通り、--set-gtid-purged=OFFオプションを付与するとエラーなくdumpファイルが作成できた。
mysqldump -h rds.host.name -u remote_user_name -p remote_db_name --set-gtid-purged=OFF > /var/tmp/dump.sqlこの辺は別の機会でちゃんと調べるべき宿題。
ハード関係はむずいわ。。。
2. リモートの踏み台サーバーのdumpファイルをローカルに転送
dumpファイルが取得できたのでEC2サーバーからはexitする。
ローカルで以下のコマンドを叩いてリモートのdumpファイルをローカルに転送
scp -i EC2にssh接続する際のpemキー EC2のusername@ipアドレス:/var/tmp/dump.sql dump.sqlscp ファイル元のパス ファイルを送る先のパス って感じで書く。
今回はリモートのEC2上のファイルなのでそこへの接続情報が必要なため-iオプションでssh接続情報を渡す必要がある。
ファイル元の書き方は 接続先の情報:ファイルのパス
usernameはデフォルトだとec2-userとかになってるはず。
ローカルのパスは好きなところへ。
ここは普通にクリア。
3. ローカルのdumpファイルをローカルのMySQLのデータベースに反映
さて、いよいよローカルにdumpファイルを落としてこれたので、後はローカルのMySQLに反映させればいいだけ。
以下のコマンドを叩く。
mysql -u local_user_name -p local_db < dump.sqlそしたらこんなエラーが。。。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘json DEFAULT NULL COMMENT…
実際にローカルのデータベースを見ると途中まではdumpファイルから復元できているようだが、あるテーブル以降全く反映されていない。
どうやらカラムにJSONタイプのあるテーブルがうまく読み込まれなかったらしい。
調べてみるとカラムのタイプにJSONをサポートしたのはMySQL5.7以降とのこと。
https://dev.mysql.com/doc/refman/5.7/en/json.html
RDSのMySQLは5.7、ローカルは5.6。。。
そういうことか、、、どうやらバージョンアップが必要らしい。
こういう系でハマりたくないから8.0じゃなくて5.7にしたんだけど結局ハマるなら8.0にしてもよかったかもしれない。笑
MySQLのバージョンアップ
とりあえずバージョンアップが必要なことがわかったのでバージョンアップする。
いくつか方法があるっぽいが、5.6は確かbrewコマンドでインストールしたなーって思って今回もbrewコマンドでインストールすることにした。
まずはMySQLのサーバーを止める
mysql.server stopそんでもって5.7をインストールする
brew install mysql@5.7しばらーーーく待った後にインストールされるのでPATHを通す。
.zshrcファイルに以下を記述。
export PATH="/usr/local/opt/mysql@5.7/bin:$PATH"mysql@5.6が書いてあったのでこれをコメントアウト(多分これが間違いだった)
アップグレードした後には既に動いているシステムが5.6になっているため、これを5.7に対応させる必要がある。
https://dev.mysql.com/doc/refman/5.7/en/mysql-upgrade.html
なので以下のコマンドを打った。
mysql_upgrade -u root -p見事にエラー。。
Checking if update is needed.
Checking server version.
Error: Server version (5.6.51) does not match with the version of the server (5.7.32) with which this program was built/distributed.
You can use –skip-version-check to skip this check.
なんかバージョン違うよとか言われてる。。いや、バージョン違うからアップグレードしたいんだけど。。。
とりあえず言われた通りに--skip-version-checkオプションを付与してみると別のエラー。
Checking if update is needed.
Running queries to upgrade MySQL server.
mysql_upgrade: [ERROR] 1726: Storage engine ‘InnoDB’ does not support system tables. [mysql.plugin]
この辺ググってみたんだけどよくわからず。
バージョン違うよって言われてる原因を考えてみたんだけど、5.7のMySQLのパスを通したけど、今動いてるMySQLは5.6だからってこと？と思って、一旦5.6のMySQLのパスを通してもう一度mysql_upgradeしたら通った！！
仮説があっていたかはわからないけどとりあえずアップグレードはできた。
でもmysql --versionでバージョンを確認すると5.6.51と出る
バージョンアップはできたけど今動いてるMySQLサーバーは5.6のままってこと？ってことでパスを5.7に修正後、mysql --version で5.7.32になっていることを確認。mysql.server stopとかしてみて立ち上げ直したりするも5.7系で立ち上がってない様子。
色々苦闘の末、この記事を参考にして下記コマンドで立ち上げると5.7で立ち上がった!!
https://weblabo.oscasierra.net/mysql-57-homebrew-install/
brew services start mysql@5.7なんかインストールした時に表示されてたらしいんだけど、全然見てなかった。。。
何かをインストール後は手順とか色々書いてること多いからちゃんと見るべきだね反省
5.7で立ち上げた後にdumpファイルを流し込むとローカルのサーバーにデータが反映された。
mysql -u local_user_name -p local_db < dump.sqlめでたしめでたし。
おわりに
めちゃくちゃハマった。。。
けどちゃんと解決できたからよかったしちょっと自信につながった。
途中わからないところもあったので今後の課題。
普段コード書いててもこういうスキル身につかないしハード関連が絡んでくるとめちゃくちゃ苦戦する。。ハードむずい
いい勉強になった！
参考
https://www.javaer101.com/ja/article/7530533.html
https://blog.masterka.net/archives/1245