Diverse developer blog

株式会社Diverse(ダイバース) 開発者ブログです。

Aurora MySQL version2 から version3にアップグレードした話

こんにちは、Diverse Developer Blogです。

今回は、2024年10月31日でEOLを迎えるAurora MySQL v2からAurora MySQL v3のアップグレードの話をします。 Blue/Green deploymentを利用してアップグレードを行ったので、その前提での内容となります。

Blue/Green deploymentを利用することで発生した問題

Blue/Green作成時に「mysql.flush_rewrite_rules」のエラーが発生する

Blue/Greenの作成ボタンを押した段階で、エラーが発生しprecheckログには「mysql.flush_rewrite_rules」に関するエラー内容がありました。

        {
            "id": "routinesSyntaxCheck",
            "title": "MySQL 8.0 syntax check for routine-like objects",
            "status": "OK",
            "description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
            "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
            "detectedProblems": [
                {
                    "level": "Error",
                    "dbObject": "mysql.flush_rewrite_rules",
                    "description": "at line 5,8: unexpected token 'QUERY'"
                }
            ]
        },

解決策

AWSに連絡してプロシージャをDROPしてもらうことで解決しました。

本問題は RDS for MySQL DB インスタンスから移行した DB クラスターにおいて発生する場合があることを確認しております

ということで、RDS for MySQLからAuroraに移行したデータベースでは発生することがあるそうです。

Blue/Green切替ができない

Blue環境とGreen環境の切り替えが失敗してしまう

Message : Switchover from DB cluster dev-aurora to dev-aurora-green was canceled due to external replication on dev-aurora. 
Stop replication from an external database to dev-aurora before you switch over.

解決策

元々オンプレミスからRDSに移行した際に、ライターインスタンスのSlave解除をせずに運用していたため発生していました。 ライターインスタンスのリセットを行うことで解決しました。

SELECT * FROM mysql.rds_history;

もしリセットされてなかったら

CALL mysql.rds_reset_external_master;

でリセットする

MySQL5.7 → MySQL8.0 になったことによる問題

Rankが予約語になった

選択肢として、

  1. アプリケーション側でのエスケープ対応

  2. カラム名の変更

となると思いますが、エスケープ忘れなどミスが起きる可能性があるため 2. カラム名の変更 で対応しました。

移行後に特定クエリのパフォーマンスが劣化した

巨大なテーブルをJOINするクエリにおいてパフォーマンスが劣化してしまう

解決策

MySQL8.0から一時テーブルの動作が変更されていたことが原因でした。

公式ドキュメントには

一時テーブルの累積サイズが 20 GiB になることがわかっています。インメモリ一時テーブルを 2 GiB に設定し、ディスク上で最大 20 GiB に拡張します。 temptable_max_ram を 2,147,483,648 に、temptable_max_mmap を 21,474,836,480 に設定します。これらの値はバイト単位です。 これらのパラメータ設定により、一時テーブルが累積合計 22 GiB に拡張できます。

と記載がありましたが、JOINするテーブルサイズから半分程度の値でストレージエンジンパラメータ(temptable_max_ram、temptable_max_mmap)を調整する対応を行いました。 この対応によりパフォーマンスがAurora MySQL version2と同等のパフォーマンスに改善しました。

まとめ

MySQL8.0に上げて良かったこと

  • MySQL 8系統にアップグレードしたことで、以前は使用できなかったWith句など、利用したかった機能が利用可能になり分析チームの効率が上がりました。

Blue/Green deploymentを利用して良かったこと

  • 大変なDBのアップグレード作業をコンソール上の簡単な操作で実行できました。
  • 開発環境での検証中でエラー時にも正常に元の状態にリバートすることを確認できていたので、本番でも安心して作業を進めることができました。

AWS公式の記事以外で参考にした記事