はじめに
こんにちは、TIMELINE 開発部 Service Development をしているほんだです！
つい最近 Aurora MySQL バージョン 3 対応したな...。というのはさておき。
今回は Cloud SQL for MySQL のデータベースバージョンを 5.7 から 8.0 に移行する際に行った方法について紹介します！
前提
皆さんご存知かと思いますが、2025年2月1日からCloud SQLではMySQL 5.7, 5.6の拡張サポートが開始し、2028年2月1日はサポートが終了します。そこでTIMELINE が提供しているサービスの一つで、Cloud SQL for MySQL 5.7を使用しているため8.0への移行を行うことになりました。
今回のシステムでは月に1回程度メンテナンスでサービスが停止するため、そのタイミングでインプレイスアップグレードを行うことにしました。以下では5.7から8.0へ移行する際の事前準備、インプレイスアップグレードの手順、切り戻し方法について説明します。
事前準備
5.7と8.0の差分を確認
MySQLの公式を参考に8.0での差分を確認しました。
今回はデフォルト認証プラグインがcaching_sha2_password, character_set_serverのデフォルト値がutf8mb4に変わったことやcollation_serverのデフォルト値がutf8mb4_0900_ai_ciに変更されたことが差分として上がりました。
Cloud SQLの設定の確認
Cloud SQLはデータベースフラグというものを用いてMySQLパラメータの調整を行っているので、その確認も必要です。データベースフラグのデフォルトやどの値が設定できるかはこちらのサイトで確認ができます。
今回のデータベースでは上述5.7と8.0の差分で上がったdefault_authentication_plugin, character_set_serverとcollation_serverをデータベースフラグを用いて設定することになりました。
手順
手順は下記の通りになります。
| 順番 | 手順 |
|---|---|
| 1 | インスタンスのクローン |
| 2 | インプレイスアップグレード |
| 3 | MySQL versionの確認 |
| 4 | データベースフラグの設定 |
ここからは実際に実行するコマンドも踏まえて説明していきます。
1. インスタンスのクローン
インプレイスアップグレードを実行する際に、バックアップが作成されますが、こちらはあくまでデータのみのため別途手動でインスタンスのクローンを行います。 Cloud SQLインスタンスの名前は変更することはできないので、アップグレードに失敗した際に切り替えて問題ない名前にしとく事をお勧めします。
$ gcloud sql instances clone <SOURCE_INSTANCE_NAME> <DESTINATION_INSTANCE_NAME> --project=<PROJECT_ID>
2. インプレイスアップグレード
下記コマンドを用いて既存のインスタンスに対してインプレイスアップグレードを実行します。上述のように、インプレイスアップグレード開始時と終了時にデータのバックアップが作成されます。
今回は8.0.33にアップグレードするためdatabase-versionにMYSQL_8_0_33を指定します。
$ gcloud sql instances patch <INSTANCE_NAME> --database-version=MYSQL_8_0_33
インスタンスのバックアップについては下記コマンドで確認することができます。
$ gcloud sql backups list --instance=<INSTANCE_NAME>
インスタンスのアップグレード状況は下記コマンドで確認することができます。
$ gcloud sql operations list --instance=<INSTANCE_NAME> $ gcloud sql operations describe OPERATION
3. MySQL versionの確認
Cloud SQL Auth Proxyを用いてCloud SQLに接続しMySQLのversionを確認します。8.0系になっていることが確認できたらOKです。
$ cloud-sql-proxy --port <PORT_NUMBER> <INSTANCE_CONNECTION_NAME> $ mysql -u <USER_NAME> 127.0.0.1 -P <PORT_NUMBER> -p mysql> select version();
4. データベースフラグの設定
上述の通り、MySQLのdefault設定と異なる部分があるので、Cloud SQLのデータベースフラグを更新を行います。
$ gcloud sql instances describe <INSTANCE_NAME> $ gcloud sql instances patch <INSTANCE_NAME> --database-flags=character_set_server=utf8,collation_server=utf8_general_ci,default_authentication_plugin=mysql_native_password
下記コマンドにてデータベースフラグが更新されていることを確認します。
$ gcloud sql instances describe <INSTANCE_NAME>
念の為インスタンスに接続しMySQL commandでも確認すると良いです。
mysql> show variables like '%char%';
切り戻し方法
インスタンス名が変わっていることに注意して、手順1. で作成した既存のインスタンのクローンにそれぞれのサーバーの向き先を変更します。
まとめ
以前Aurora3への移行を行った際はconsoleベースで、アップグレードを行ったのですが今回gcloud commandを用いて行うことで、以前rymiyamotoの記事でもあった通りメンテナンスの再現性や、レビューが格段に容易になったと感じました。
また、今回の手順に記したものを実際の値に変えた手順書を作成しているため、当日はコピペするだけで作業が完了するので実行者の負荷やヒューマンエラーも軽減することができました！(筆者はタイポが多いです)
今回Cloud SQLのアップグレードを行うにあたって、明確な原因は追求できていませんがsidecar containerとして実行している、Cloud SQL Auth Proxyのimage versionが古すぎて、インスタンスに接続できないという事象が発生したので、定期的にメンテナンスを行うことは大切だと実感しました。
Cloud SQL for MySQLのインプレイスアップグレードを行おうとしてる人や今後本システムの開発に携わる人の参考になれば幸いです。
