Cloud SQL / RDSで起きるMySQLバージョン問題
マネージドサービスなら安心。
そう思ってMySQLをCloud SQLやRDSに移行したのに、突然アプリが動かなくなる。
実はこれ、珍しい話ではありません。
MySQLを自分でインストールしている場合、バージョンアップは「自分の判断」で行います。
しかしCloud SQLやRDSでは、自分が何もしなくても環境が変わります。
そしてMySQLのトラブルの多くは、SQLの書き方ではなくバージョンの違いから発生します。
マネージドサービスは「固定」ではない
オンプレミスのMySQLは、何もしなければ変わりません。
5.7は5.7のままです。
一方、Cloud SQL / RDSは違います。
- マイナーバージョン更新
- セキュリティパッチ
- 推奨バージョン変更
- EOL対応
が定期的に行われます。
つまり、同じインスタンスを使い続けていても、内部のMySQLは変わります。
アプリケーションから見ると「同じDBのはず」ですが、MySQLの挙動は変わっています。
よく起きる症状
代表的なものを挙げます。
- ログインできなくなる
- INSERTが失敗する
- GROUP BYの結果が変わる
- ORDER BYの順序が変わる
- インデックスが使われなくなる
どれもアプリは変えていません。
変わったのはMySQLです。
認証方式の変更
8.0系で大きな変更がありました。
デフォルト認証方式です。
5.7までは mysql_native_password
8.0からは caching_sha2_password
古いドライバはこれに対応していません。
結果:
アプリの接続エラー
これはパスワードミスではありません。
クライアントとサーバの仕様差です。
SQLの挙動が変わる問題
次に多いのがSQLモードです。
特に ONLY_FULL_GROUP_BY です。
SELECT id, name FROM users GROUP BY id;
古いMySQLでは動きました。
新しいMySQLではエラーになります。
理由は、SQL標準に近づいたためです。
つまり、Cloud SQL / RDSでのトラブルは「壊れた」のではなく、
今まで許されていた書き方が許されなくなったケースです。
インデックスが急に効かなくなる
性能問題も発生します。
オプティマイザが変わると、実行計画が変わります。
結果として、急にフルスキャンになります。
アプリからは
「突然遅くなった」
と見えますが、内部では別のプランが選ばれています。
特にデータ量が多いテーブルで顕著です。
なぜ気づきにくいのか
一番の問題は、原因がアプリに見えることです。
- エラーはアプリログに出る
- SQLが失敗する
- レスポンスが遅くなる
そのためアプリ改修を始めてしまいます。
しかし本当の原因はDBの仕様変化です。
さらに、マネージドサービスではOSや設定に直接触れないため、
MySQLが変わったことに気づきにくいです。
事前にやるべきこと
重要なのは「アップグレードを止める」ではありません。
止め続けると、今度はサポート終了が来ます。
必要なのは準備です。
最低限確認します。
- 使用中のMySQLバージョン
- サポート終了日
- ドライバの対応状況
- SQLモード
そしてステージング環境で同じバージョンを動かします。
ここを省略すると、本番で初めて挙動の違いに気づきます。
マネージドサービスの誤解
Cloud SQLやRDSは「運用を減らす」サービスです。
しかし「挙動の変化をなくす」サービスではありません。
むしろ逆です。
セキュリティと保守のため、定期的に変化します。
MySQLはデータベースソフトウェアです。
そしてソフトウェアは更新されます。
マネージドサービスで重要なのは、管理を任せることではなく「変化を前提にすること」です。
アプリが壊れたように見えたとき、まずDBのバージョンを見る習慣が、トラブル対応を大きく短縮します。