はじめに
今回は、本番稼働中のサービスのデータベースを MySQL5.7 から MySQL8.0 にアップグレードする機会があったので、その軌跡をまとめます。
庵野さんはエヴァンゲリオンを完結するまでに、約 25 年かかったと言われていますが、MySQL5.7 から MySQL8.0 へのアップグレードも、なかなか大変でした...！
弊社では、MySQL 互換の Aurora MySQL を利用しております。なので Aurora MySQL バージョン 2 から Aurora MySQL バージョン 3 へのアップグレードとなります。厳密には、Aurora MySQL 2.11.2 (5.7) から Aurora MySQL 3.05.2 (8.0) へのアップグレードです。
方針
データベースのアップグレードは、大きく分けて以下の 2 つの選択肢があります。
1. In Place Upgrade
データディレクトリはそのままで、MySQL のバイナリを新しいバージョンに更新して起動することで、データベースをアップグレードする手法です。
2. Blue/Green Deployment
稼働中の本番環境のデータベースとは別に、新しいデータベース(Green 環境)を作成し、データをコピーしてから、切り替える手法です。
ダウンタイムは Blue 環境から Green 環境への切り替え時のみ発生し、弊社検証時における切り替え時間は 1 分以内でした。
弊社では、今回は 2 の Blue/Green Deployment を選択しました。理由としては、1 の In Place Upgradeよりも、ダウンタイムを最小限に抑えることができるためです。また、移行時間のトータル作業時間も短くなるため、ユーザに対して影響を与える時間を最小限に抑えることができると判断しました。
事前に調べたことなど
アップグレードにあたっては、主に、上記のそーだいさんの記事を中心に参考させていたきました。また、Blue/Green Deployment を利用するに当たっての制限事項もあるので、こちらで確認しました。
弊社では、ステージング環境でアップグレード後のバージョンで約 1 ヶ月運用、検証し問題がないことを確認した上で、本番環境への適用を行いました。
Blue/Green Deployment では、Green 環境作成前にアップデート可能かどうか事前チェックが実行されます。事前チェックが成功した場合、Green 環境の作成が開始されます。失敗するとログが出力されるため、その内容を確認し、問題を解決する必要があります。
事前チェックを含めたステージング環境での検証において、弊社では主に以下の問題が発生しました。
RDS proxy 利用による「Blue/Green Deployment」の制約
RDS proxy を利用している場合、Blue/Green Deployment が利用できません。
弊社が提供するサービスの一部は、RDS Proxy を利用しております。今回のアップグレードでは、RDS Proxy を使用する該当サービスを対象に、メンテナンス画面を提供し、その間は RDS Proxy 一時的に削除し、その後再作成することで対応いたしました。
The following tables contain dangling FULLTEXT index which is not supported in major version 8.0.
事前チェック時のエラーログにて、特定のテーブルで以下のようなエラーが出力されました。
The following tables contain dangling FULLTEXT index which is not supported in major version 8.0.
このメッセージは、バージョン 8 でサポートされていない FULLTEXT インデックスが含まれているテーブルがあることを示しています（非互換）。以下のコマンドを実行し index 再構築することで解決しました。
ALTER TABLE table_name ENGINE=InnoDB;
予約語「rank」
MySQL8.0 から予約語として登録されたため、テーブル名やカラム名に「rank」を使用している場合は、注意が必要です。弊社では、テーブル名に「ranks」という名前を使用していたため、問題にはなりませんでした。調べたところそもそも不要なテーブルであったため、削除することにしました。
本番環境への適用
アップグレードに関する手順書を作成、メンバのレビューを経て、本番環境への適用を行いました。ステージング環境で素振りを行なってましたので、本番環境への適用はスムーズに行うことができました。また、作業自体は、ユーザへの影響を最小限に抑えるため、深夜に行いました。
アップグレード完了までの時間は、現行データベースのスナップショット作成から、大体 2.5 時間程度で完了しました。本来であればダウンタイムは Green 環境への切り替え時のみ発生しますが、弊社では、RDS Proxy を利用していたため、今回はアップグレード作業中、一時的にサービスを停止する必要がありました（RDS Proxy 利用時の良い回避方法があればいいのですが...）。
アップグレード後の問題
アップグレード作業自体は問題なく完了しましたが、アップグレード後に、以下の問題が発生しました。
クエリの遅延
アップグレード後に、一部のクエリが遅くなるという問題が発生しました。原因は、アップグレード後に、クエリプランが変わり、適切なインデックスが選択されていなかったためでした。この問題については、アップグレード後に、クエリプランの変更を確認し、適切なインデックスが選択されるようにアプリケーション側のクエリを修正することで解決しました。
Redash の SSL 接続エラー
また、弊社では BI ツールとして Redash を利用しており、Redash から Aurora MySQL への SSL 接続ができなくなるという問題が発生しました。原因は、Redash が利用している MySQL Client のバージョンが古く、アップグレード後の MySQL 8.0 に対応していなかったためでした。この問題については、Redash の MySQL Client のパッケージのバージョンをアップグレードすることで解決しました。
BI ツールは本番環境でしか利用されていないため、ステージング環境での検証が不十分でした。今後は、BI ツールも含めたステージング環境での検証を徹底することが必要だと感じました。
終わりに
今回は、MySQL5.7 から MySQL8.0 へのアップグレードについてまとめました。アップグレード作業自体は、ステージング環境での検証を通して、本番環境への適用を行うことで、スムーズに完了することができました。アップグレード後に発生した問題についても、ステージング環境での検証、特に周辺ツール含めて、不十分だったことが原因であると感じました。今後は、ステージング環境での検証を徹底することが必要だと感じました。
日頃から Datadog や Slow Query Log を利用し、クエリの遅延を検知することで、アップグレード後の問題を早期に発見することができました。今後も、監視ツールを活用し、問題を早期に発見することができるようにしていきたいと思います。
この記事を通して、みなさんの さようなら、全ての MySQL5.7 の手助けになれば...！
助太刀について
「建設現場を魅力ある職場に。」というビジョン・ミッションを基に、事業者間マッチングサービス「助太刀」、正社員採用「助太刀社員」を開発、運営しています。
助太刀では一緒に開発してくれるメンバを募集してます！
少しでもご興味を持っていただけたら下記よりお気軽にご連絡ください！
Discussion