はじめに

こんにちは。株式会社DIVXのエンジニア、大久保です。
Amazon Aurora MySQL2(MySQL 5.7互換)は、2024年10月31日に標準サポートが終了予定です。延長サポートは有料サービスとなりますので、サポートが切れる前にアップグレードを実施しました。18のクラスターをアップグレードし、それぞれのエラー解消方法や発生した現象が異なることを経験しました。そこで、今回のアップグレード時に詰まった点や移行手順について記事にまとめることにしました。

アップグレード準備

アップグレードするときにまず先に下記の調査から行いました。

• アップグレード方法の選定

• MySQL5.7と8.0の違いの把握
• パラメータグループの設定
• インスタンスタイプの変更
• アップグレードの事前チェック
• ダウンタイムの計測スクリプトの作成

アップグレード方法の選定

Aurora MySQL 5.7から8.0へのアップグレードには、以下の3つの手法があります。

1. インプレースアップグレード
2. ブルー/グリーンデプロイメント
3. スナップショットの復元

それぞれの手法には独自の利点があり、実際の環境や要件に応じて最適な方法を選定することが重要です。事前に十分な計画を行い、アップグレード後には必ずテストを実施することで、安全に新しいバージョンを利用できるようになります。正しい選択と準備により、スムーズな移行が実現できるでしょう。
※具体的なダウンタイムの時間は環境によって異なりますので、ご注意ください。

インプレースアップグレード

MySQL 5.7互換のクラスターからMySQL 8.0互換のクラスターへアップグレードする場合、クラスター内でアップグレードプロセスを実行することが可能です。この方法は、新しいクラスターを作成することなく実施するインプレースアップグレードです。すべてのデータを新しいクラスターにコピーする必要がなく、アップグレードプロセスは比較的迅速に完了します。
この安定性のおかげで、アプリケーションの構成変更が最小限に抑えられるだけでなく、アップグレード後のクラスターのテストも軽減されます。これは、DBインスタンスの数やインスタンスクラスが変更されないため、既存の設定をそのまま利用できるからです。

◎ダウンタイム

• シャットダウンが必要でダウンタイムが発生する。数分〜数時間。

◎メリット

• 新しい環境を構築してデータを移行する手間が省けるため、運用コストや時間を削減できます。

• アップグレード後も同じインスタンスで動作するため、アプリケーションのテストが行いやすく、変更点を把握しやすいです。

◎デメリット

• アップグレード中にエラーや問題が発生すると、システム全体に影響を及ぼす可能性があります。インプレースアップグレードは、途中で失敗した場合、元の状態に戻すのが難しいことがあります。

• クラスターがビジーな状態（トランザクションが多発する等）でのアップグレードは、時間がかかる可能性が高く、監視が必要です。特に、長時間実行されるトランザクションがある場合は注意が必要です。

• インプレース アップグレード メカニズムでは、場合によっては DB クラスターをシャットダウンする必要があることがありますが、システムによってはシャットダウンなしにアップグレード可能な場合もあります。

スナップショットの復元

スナップショットの復元とは、特定の時点で保存したデータベースやストレージのスナップショットを利用して、新しいインスタンスを作成し、そのインスタンスを新しいバージョンにアップグレードする方法です。このプロセスは、データのバックアップを取得した後に新しい環境を構築するための一般的かつ効果的な手法となります。スナップショットを利用することで、迅速に以前の状態を復元でき、新しいバージョンへの移行を安全に行うことが可能です。

◎ダウンタイム

• エンドポイントの手動切り替え時に数分発生する。

◎メリット

• スナップショットから復元することで、元のデータやシステムに影響を与えず、新しい環境で自由にテストや試行ができます。万が一、アップグレードに失敗した場合でも、元のデータを保持しているため、安全性が高くなります。

• 新しいインスタンスを別途作成できるため、開発環境やテスト環境と本番環境を分離できます。これにより、システム全体の安定性を保ちながら、改修やテストが可能です。

• アップグレード作業中に元のインスタンスに影響を与えないため、トラブルが発生しても迅速に元の状態に戻ることができます。これにより、リスクが大幅に低減されます。

◎デメリット

• 新しいインスタンスを作成するため、追加のAWSリソースやストレージコストが発生します。資源の確保や管理が必要になります。

• スナップショットから復元した後、環境の設定やアプリケーションの接続設定を行う必要があるため、手間がかかる場合があります。

• スナップショットは特定の時点でのデータを保存するため、その後のデータ変更が反映されません。復元のタイミングによっては、古いデータに基づいたテストを行うことになるため、実時間での使用に対しての適合性が損なわれる可能性があります。

ブルー/グリーンデプロイメント

ブルー/グリーンデプロイメントは、アプリケーションのデプロイメント手法の一つで、異なる環境「ブルー」と「グリーン」を利用して新しい変更をリリースする方法です。この手法では、二つの環境が同時に存在し、片方（ブルー）が現在の本番環境、もう片方（グリーン）が新しいバージョンのテスト環境として機能します。
新しいバージョンをグリーン環境にデプロイした後、十分なテストを実施し、問題がなければトラフィックをグリーン環境に切り替えます。これにより、リリース作業中のダウンタイムを最小限に抑えることができ、万が一問題が発生した際には、簡単にブルー環境に戻すことが可能です。このアプローチは、安全で柔軟なリリース管理を実現します。

◎ダウンタイム

• ダウンタイムはほとんど発生しませんが、切り替えのタイミングによってはわずかな遅延が発生する可能性があります。

◎メリット

• 新しい環境が準備できてからトラフィックを切り替えるため、ダウンタイムがほとんどなく、ユーザー体験に影響を与えにくい。

• 新しいバージョンで問題が発生した場合、短時間で元の環境（ブルー）に戻すことができます。

• グリーン環境で本番データを使用してテストができるため、実際の使用感に近い状況でテストが行えます。
• 本番環境には影響を与えずに新バージョンを確認することができるため、リリースによるリスクを減少させることができます。

◎デメリット

• 二つの環境を同時に運用するため、リソースのコストが増加します。特に、インフラがクラウドベースの場合、リソースの二重管理が必要になることがあります。

• 切り替えに伴うデータの整合性を維持するためには、適切な戦略が必要です。特に、データベースのマイグレーションや状態管理に注意が必要です。

• 新しい環境を構築してテストを行うための準備が必要であり、開発チームに追加的な手間がかかることがあります。

今回は、ダウンタイムを最小限に抑え、切り替え時の設定ミスを防ぐためにブルー/グリーンデプロイメントを採用しました。このアプローチは、システムの可用性を高めるだけでなく、新バージョンのテストを本番環境に影響を与えることなく実施できる点が大きな利点です。
ブルー/グリーンデプロイメントを選択することで、リリース後の問題発生時にも迅速に元の環境に戻ることができ、ユーザー体験への影響を最小限に抑えることが可能となります。また、新しいバージョンのテストを実際の本番データで行うことで、より現実に即した状況での検証ができ、品質向上に寄与します。
ただし、この手法は二つの環境を同時に運用するため、リソースのコストが増加する点には留意が必要です。それでも、長期的に見れば、ダウンタイムやリスクを低減することで、企業の信頼性やユーザー満足度を向上させることができると考えています。このように、ブルー/グリーンデプロイメントは、現代のデプロイメント戦略において非常に効果的な手法と言えるでしょう。

MySQL5.7と8.0の違いの把握

主な変更点は以下の通りです。非推奨項目が多く、アップグレードの影響を考慮した結果、優先順位をつける必要があります。

• データディクショナリの変更
• 優先認証プラグインとしての caching_sha2_password
• 構成の変更
• サーバーの変更
• InnoDB の変更点

データディクショナリの変更

MySQL 8.0では、システムデータベースのデータディクショナリが改善され、パフォーマンスが向上しました。これにより、メタデータの操作が効率的になり、データベース設計がより柔軟になります。

認証プラグイン caching_sha2_password

MySQL 8.0では、デフォルトの認証プラグインがcaching_sha2_passwordに変更されました。これにより、セキュリティが強化され、特にクラウド環境での安全な接続が促進されます。ただし、アプリケーションによってはこの変更に対する対応が必要になる場合があります。
構成の変更: 一部の構成オプションが変更されたり、削除されたりしています。これにより、システムのパフォーマンス設定がより直感的になった一方で、古い設定を用いたシステムには影響を与える場合があります。

サーバーの変更

サーバーの内部実装が大幅に見直され、効率性や安定性が向上しました。特に、トランザクションの処理や並列クエリの実行が改善されており、大規模なデータベースでのパフォーマンス向上が期待されます。

InnoDB の変更点

InnoDBストレージエンジンの機能が強化され、新しいデータ型や、テーブルパーティショニングの改善が実施されました。これにより、データの管理やクエリの応答性が向上します。
SQL の変更: SQL文法や機能に関するいくつかの変更が行われ、より強力なクエリが作成できるようになっています。また、一部の古い構文が非推奨となっているため、既存のアプリケーションに影響を与える可能性があります。

ダウンタイムの計測スクリプトの作成

このスクリプトを実行するには、mysqlパッケージがインストールされており、mysqladmin pingコマンドが使用できる必要があります。まず、以下のコマンドでmysqladminが利用可能か確認してください。

which mysqladmin

upgrade-rds-downtime.sh

#! /bin/bash

## sleepTime は、mysqladmin ping コマンドを実行する間隔を指定します。
sleepTime=1

## DB の接続情報
endpoint=$1
dbUser=$2
password=$3

dbStatus=""

## mysql に ping を送信する処理（初回）
mysqladmin ping -h ${endpoint} -u ${dbUser} -p${password} 2>&1 | grep alive > /dev/null 2>&1
if [ $? = 0 ]; then
    echo "DB status is alive"
    date
    echo "---------"
    dbStatus="alive"
    sleep ${sleepTime}
else
    echo "DB status is dead"
    date
    echo "---------"
    dbStatus="dead"
    sleep ${sleepTime}
fi

## mysql に ping を送信する処理（2回目以降）
while true; do
    mysqladmin ping -h ${endpoint} -u ${dbUser} -p${password} 2>&1 | grep alive > /dev/null 2>&1
    if [ $? = 0 ]; then
        if [ ${dbStatus} = "alive" ]; then
            sleep ${sleepTime}
        elif [ ${dbStatus} = "dead" ]; then
            echo "DB status has become alive"
            date
            echo "---------"
            dbStatus="alive"
            sleep ${sleepTime}
        fi
    else
        if [ ${dbStatus} = "alive" ]; then
            echo "DB status has become dead"
            date
            echo "---------"
            dbStatus="dead"
            sleep ${sleepTime}
        else
            sleep ${sleepTime}
        fi
    fi
done

以下の引数を指定して、スクリプトを実行します。

$ bash upgrade-rds-downtime.sh {{endpoint}} {{dbUser}} {{dbPassword}}

引数には下記の内容を含めます。

◎処理ロジックについて

本スクリプトでは、定期的にmysqladmin pingコマンドを実行し、RDS for MySQLとの疎通確認を行います。処理は主に2つのステップに分かれます。

◎初期接続確認

スクリプト実行時にデータベースとの通信が開始され、疎通が成功した場合は「DB status is alive」、失敗した場合は「DB status is dead」と表示されます。

◎疎通状況の監視

疎通ができなくなる、または再度疎通ができるたびに、ログ出力が行われます。ダウンタイムは、データベースとの疎通が失われた瞬間（dbStatus = dead）から、再度疎通確認ができた瞬間（dbStatus = alive）までの時間となります。
以下はログ出力の例です。

このスクリプトを使用して、適宜ダウンタイムを計測していきます。

パラメータグループの設定

パラメータグループの比較

コンソールを使用してパラメータグループの比較を行います。このプロセスでは、MySQL 5.7から8.0へのアップグレードに伴う設定の違いや推奨される変更点を詳しく確認します。特に、リミットやサイズに関するパラメータについては、アプリケーションの要件やパフォーマンスに影響を与えるため、慎重に設定を見直す必要があります。

インスタンスパラメータグループとクラスターパラメータグループは、Amazon RDSやAmazon Auroraにおけるデータベースの設定を管理するための重要なコンセプトですが、以下のように異なる役割を持っています。

インスタンスパラメータグループ

◎適用範囲

インスタンスパラメータグループは、特定のデータベースインスタンスに対して設定されるパラメータの集まりです。

◎設定の対象

各インスタンスは固有の動作やパフォーマンス特性を持つため、インスタンスごとに異なるパラメータグループを設定することが可能です。この機能は、主インスタンスとリードレプリカインスタンスなど、異なる役割を持つインスタンスに対してそれぞれ最適な設定を行う際に非常に役立ちます。具体的なパラメータの例としては、max_connections（同時接続数）やinnodb_buffer_pool_size（InnoDBのバッファプールのサイズ）などがあり、これらはデータベースのリソース管理や動作特性に直接関連しています。

• インスタンスパラメータグループは、特定のインスタンスに適用され、個々のインスタンス設定を効率的に管理します。

クラスターパラメータグループ

◎適用範囲

クラスターパラメータグループは、データベースクラスター全体に適用されるパラメータの集まりです。

◎設定の対象

クラスターパラメータグループは、クラスター内のすべてのインスタンスに共通の設定を提供します。この仕組みにより、複数のインスタンスを持つクラスター内での設定の整合性が保たれ、運用管理が容易になります。例えば、binlog_format（バイナリログの形式）やdefault_time_zone（デフォルトのタイムゾーン）など、クラスター全体に影響を与える重要なパラメータが含まれます。
ただし、クラスターパラメータグループはクラスター全体に適用される設定を管理するものであり、インスタンスパラメータグループが優先される場合があるため、全インスタンスに共通の設定を提供するが、特定のインスタンスには個別の設定が適用されます。

• クラスターパラメータグループは、クラスター全体に適用される設定を管理し、すべてのインスタンスで共有される設定の整合性を確保します。

パラメータグループの作成

MySQL 8.0に対応するカスタムDBクラスターパラメータグループを作成します。以下のコマンドを使用して、パラメータグループを設定します。

aws rds create-db-cluster-parameter-group \
    --db-cluster-parameter-group-name test-parameter-group \
    --db-parameter-group-family aurora-mysql8.0 \
    --description "instance Parameter Group"

次に、作成したクラスターパラメータグループの設定を変更し、MySQL 5.7のクラスターパラメータにおけるbinlog_formatを「ROW」に設定します。この設定は、ブルーグリーンデプロイメントを実行するために不可欠なバイナリログの管理に必要です。これにより、データの整合性を保ちながら、シームレスな更新プロセスを実現できます。
以下のコマンドを使用して、binlog_formatの変更を行います。

aws rds modify-db-cluster-parameter-group \
    --db-cluster-parameter-group-name test-parameter-group \
    --parameters "ParameterName=binlog_format,ParameterValue=ROW,ApplyMethod=immediate"

binlog_formatとは

binlog_format は、MySQLおよびその派生データベース管理システム（DBMS）で使用されるバイナリログの形式を指定する設定です。このログファイルは、データベース内での変更（データの挿入、更新、削除など）の履歴を記録し、データベースの障害復旧やレプリケーションに重要な役割を果たします。
バイナリログは、マスターデータベースからスレーブデータベースへの変更伝播に使用されます。マスターサーバーが生成するバイナリログをスレーブサーバーが読み込むことで、同様の変更がスレーブに適用され、データベース間の同期が保たれます。

binlog_formatの変更

バイナリログの形式には複数の選択肢がありますが、ここでは行レベルの変更を記録するROW形式を使用しています。ROW形式では、変更された行の具体的なデータがログに記録されるため、マスターとスレーブ間のデータの整合性が確保されます。このアプローチは、特に複雑なSQLクエリが実行される環境において、行ごとの変更を追跡しやすくするため、整合性の維持に非常に有効です。
binlog_formatを設定していない場合、Green環境にMySQL 8.0のエンジンバージョンを選択することはできません。もし選択した場合、以下の画像のようにブルーグリーンデプロイメントの作成が失敗します。

DBインスタンスの再起動

binlog_formatを有効にした後、変更を反映させるためにはDBインスタンスの再起動が必要です。これは、ライターインスタンスがDBクラスターパラメータグループと同期している必要があるためです。以下のコマンドでインスタンスを再起動します。

aws rds reboot-db-instance \
    --db-instance-identifier your-instance-identifier

パラメータグループの適用タイプには、ダイナミックとスタティックの2種類があります。
ダイナミックパラメータは、データベースが稼働中に変更可能な設定です。これらのパラメータを変更すると、即座にまたは次のクエリに適用され、データベースの挙動に影響を与えます。
一方、スタティックパラメータは、変更内容を有効にするためにはデータベースの再起動が必要な場合があります。binlog_formatはスタティックタイプに該当するため、その変更を適用するにはインスタンスの再起動をしました。
インスタンスの再起動を行わない場合、パラメータグループの同期ができずに以下のようにブルーグリーンデプロイメントの作成が失敗します。このため、今回の変更内容を確実に反映させるためには、インスタンスを再起動する必要があります。

再起動時のダウンタイム

RDSインスタンスが再起動される際には、通常数分のダウンタイムが発生しますが、具体的な時間はインスタンスのサイズやデータベースの状況、アプリケーションの負荷によって異なります。一般的には再起動は数分以内に完了しますが、特に大規模なインスタンスや大容量データベースの場合、再起動に数分以上かかることもあります。今回の再起動ではおおよそ5秒から10秒で完了しましたが、ダウンタイムを許容できない場合や大規模な組織での開発を行う場合は、フェイルオーバー設定を検討することをお勧めします。

インスタンスタイプの変更

Aurora MySQL 5.7ではインスタンスタイプとしてdb.t3.smallを使用できましたが、Aurora MySQL 8.0ではその使用ができなくなり、db.t3.medium以上への変更が必要です。このため、インスタンスタイプがdb.t3.smallのままでブルーグリーンデプロイメントを作成しようとすると、以下のように失敗します。

インスタンスタイプの変更に伴い、ステージング環境で約5分のダウンタイムが発生しました。このダウンタイムはインスタンスの再起動よりも長いため、ブルーグリーンデプロイメントを使用してインスタンスタイプの変更を行いました。この方法では、現在のエンジンバージョンと同じものを選択して設定します。

アップグレードの事前チェック

MySQL 8.0には、MySQL 5.7との非互換性がいくつか存在します。これらの非互換性は、Aurora MySQL 5.7からAurora MySQL 8.0へのアップグレード中に問題を引き起こす可能性があります。そのため、アップグレードを成功させるためには、データベースに対して何らかの準備が必要になることがあります。
Aurora MySQL 5.7からAurora MySQL 8.0へのアップグレードを開始すると、Amazon Auroraはこれらの非互換性を検出するために自動的に事前チェックを実行します。

アップグレードチェッカーユーティリティ

mysqlshコマンドインターフェイスを使用すると、コマンドラインからアップグレードチェッカーユーティリティを起動できます。このユーティリティは、MySQLサーバーのアップグレード前に互換性の問題を検出するためのツールです。
以下は、MySQLサーバーをバージョン8.0.27にアップグレードするかどうかをチェックするためのコマンドの例です。実行すると、JSON形式で結果を返します。

mysqlsh -- util checkForServerUpgrade user@localhost:3306 
                   --target-version=8.0.27 --output-format=JSON --config-path=/etc/mysql/my.cnf

このコマンドを実行すると、指定したMySQLサーバーのバージョンと互換性のある構成について、情報を提供します。出力には、以下のような内容が含まれます。

• 非互換性の警告
• 既存のデータベースオブジェクトが新しい予約語と競合している場合の注意点
• 文字セットの使用に関する推奨事項
  これにより、アップグレードの前に潜在的な問題を把握し、必要な対策を講じることができます。出力結果にはエラーや警告に関する詳細情報が含まれており、それに基づいて修正作業を進めることが重要です。

The MySQL server at example.com:3306, version
5.7.33-enterprise-commercial-advanced - MySQL Enterprise Server - Advanced Edition (Commercial),
will now be checked for compatibility issues for upgrade to MySQL 8.0.37...

1) Usage of old temporal type
  No issues found

2) Usage of db objects with names conflicting with new reserved keywords
  Warning: The following objects have names that conflict with new reserved keywords. 
  Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.
  More information: https://dev.mysql.com/doc/refman/en/keywords.html

  dbtest.System - Table name
  dbtest.System.JSON_TABLE - Column name
  dbtest.System.cube - Column name

3) Usage of utf8mb3 charset
  Warning: The following objects use the utf8mb3 character set. It is recommended to convert them to use 
  utf8mb4 instead, for improved Unicode support.
  More information: https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html 
 
  dbtest.view1.col1 - column's default character set: utf8 

4) Table names in the mysql schema conflicting with new tables in 8.0
  No issues found

  dbtest.part1_hash - MyISAM engine does not support native partitioning

..... 

Errors:   7
Warnings: 36
Notices:  0

7 errors were found. Please correct these issues before upgrading to avoid compatibility issues.

実際に表示されたエラーを一つ一つ解決していきます。トラブルシューティングに関しては、詳細を後述します。

アップグレード手順

ここからは、ブルーグリーンデプロイメントの手順について説明いたします。事前準備が整っていれば、あとはスムーズに進めることができます。
ブルーグリーンデプロイメントを実行した後のイメージとしては、同じクラスタとインスタンスが作成され、その後に自動的にアップグレードが行われる流れになります。

1. ブルー/グリーンデプロイの作成 - 新規
コンソール画面からアクションを選択して、ブルーグリーンデプロイの作成を行います。

2. デプロイ識別子やグリーンデータベースのエンジンバージョン、パラメータグループの選択をします。

3. ステージング環境の作成を押すと、プロビジョニング中になります。まずMySQL5.7のエンジンバージョンでグリーン環境が作成されます。

4. MySQL 8.0のエンジンバージョンに自動的にアップグレードされました。

5. ブルー/グリーンデプロイメントが完了しました。
おおよそ30分ほどで環境が作成されました。
アプリケーションのエンドポイントをグリーン環境に変更し、または直接データベースクライアントで接続することで、動作確認ができます。検証が完了したら、ブルー/グリーンデプロイロールのアクションから切り替えを実施します。

6. スイッチオーバーの概要を確認し問題なければ切り替えを行います。

7. ブルー環境とグリーン環境の切り替え中です。

切り替えが行われると、ブルー環境のデータベース識別子の末尾に「old1」が追加されました。この切り替えは迅速に完了し、実質的なダウンタイムはわずか1秒ほどでした。

8. 新しいブルー環境に切り替え完了しました。

9. 最後に不要なクラスター、インスタンス、ロールを削除します。

10. 古いブルー環境の削除中です。

11. 削除も完了して、アップグレードが完了しました。

トラブルシューティング

実際に発生したトラブルシューティングの内容について説明いたします。

①一時テーブルの容量制限

◎解決方法: temptable_max_mmapの変更

[ERROR] [MY-013132] [Server] The table '/rdsdbdata/tmp/#sql12e_edad_0' is full! (handler.cc:4465)

一時テーブルの容量制限: MySQLでは、クエリ処理中に一時テーブルを使用します。これらのテーブルは一時的にストレージを使用し、デフォルトのストレージエンジン（通常はInnoDBやMyISAM）に基づいて作成されます。一時テーブルが設定されたサイズ制限を超えると、「テーブルが満杯」となるエラーが発生します。

上記の画像に示されているように、MySQL 8.0のパラメータグループでは、temptable_max_mmapのデフォルト値が1GiBに設定されています。(環境により異なります)このため、大きなサイズのテーブルを扱うクエリを処理する際にエラーが発生する可能性があります。
temptable_max_mmapは、MySQLがメモリマッピング（mmap）を使用して一時テーブルのサイズを決定するためのパラメータです。この設定は、ファイルをメモリにマッピングすることによってディスクI/Oのコストを削減し、一時テーブルのパフォーマンスを向上させるために重要です。また、シチュエーションによっては、temptable_max_ramの値を変更することも検討する必要があります。

②Usage of old temporal type (oldTemporal)

アップグレードの際、内部データ保存形式が古いMySQL 5.5互換のバイナリ形式から、新しいMySQL 8.0互換の形式に変更されるポイントが重要です。

1) Usage of old temporal type (oldTemporal)
  Error: Following table columns use a deprecated and no longer supported
    temporal disk storage format. They must be converted to the new format before
    upgrading. It can by done by rebuilding the table using 'ALTER TABLE
    <table_name> FORCE' command
  More information:

https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/

  db_name.tables.created_at - datetime /* 5.5
    binary format */
  db_name.tables.updated_at - datetime /* 5.5
    binary format */

上記のエラーメッセージに記載されている通り、ALTER TABLE <table_name> FORCEコマンドを使用して、テーブルを再構築する必要があります。このコマンドはテンポラルデータ型を新しい形式に変換するためのものです。

ALTER TABLE tables FORCE;

現在の設定状態を確認するためのコマンドは以下の通りです。通常はOFFに設定されているため、SET show_old_temporals = ON;に変更しておきます。

SHOW VARIABLES LIKE 'show_old_temporals';

ALTER TABLE <table_name> FORCEコマンドを実行する際には、一時的なロックが発生する可能性があります。このため、他のセッションがそのテーブルに対してINSERT、UPDATE、DELETEなどの操作を行えなくなることがあります。テーブルのサイズやロックの種類によっては、ロックの影響が広がることもあるため、運用中のテーブルに対してこの操作を行う際は慎重に行う必要があります。
GitHubのMySQL用オンラインスキーマ移行ツールgh-ostも検討しましたが、テーブルごとにghost_tableを作成して移行する手間がかかるため、今回はブルーグリーンデプロイメントを利用して同じグリーン環境でALTER TABLE <table_name> FORCEコマンドを実行しました。

③Schema inconsistencies resulting from file removal or corruption

◎解決方法: 
このエラーは修正しなくても問題ありませんでした。

19) Schema inconsistencies resulting from file removal or corruption
(schemaInconsistency)
  Error: Following tables show signs that either table datadir directory or frm
    file was removed/corrupted. Please check server logs, examine datadir to
    detect the issue and fix it before upgrade

  mysql.general_log_template - present in INFORMATION_SCHEMA's
    INNODB_SYS_TABLES table but missing from TABLES table
  mysql.rds_heartbeat2 - present in INFORMATION_SCHEMA's INNODB_SYS_TABLES
    table but missing from TABLES table
  mysql.slow_log_template - present in INFORMATION_SCHEMA's INNODB_SYS_TABLES
    table but missing from TABLES table

④Amazon RDS プロキシ

◎RDS Proxyの関連を解除する
本課題は、一時的にRDS Proxyとの関連付けを解除するか、RDS Proxy自体を削除することで解決できます。ただし、関連付けを解除したり、RDS Proxyを削除すると、そのエンドポイントが変更されるため、注意が必要です。

⑤Aurora Serverless v1 DB クラスター

◎ 解決策: Engine ModeをServerlessからProvisionedに変更する
Aurora Serverless v1クラスターの場合、ブルーグリーンデプロイメントは実施できません。このため、Engine ModeをServerlessからProvisionedに変更する必要があります。
現在、コンソール上での変更はサポートされていないため、コマンドラインを使用して変更を行います。以下のコマンドを実行します。

aws rds modify-db-cluster \
    --db-cluster-identifier upgrade-test \
    --engine-mode provisioned \
    --db-cluster-instance-class db.t3.medium \
    --allow-engine-mode-change

おわりに

本記事では、Amazon Aurora MySQLのバージョン5.7から8.0へのアップグレードプロセスについて詳しく説明しました。アップグレードに伴う課題やエラー、特にブルーグリーンデプロイメントの手法を利用した移行について、多くの発見や学びがありました。この経験を通じて、システムの可用性を高めるためには、事前の計画やテストがいかに重要であるかを再認識しました。
私自身、これらの課題に取り組む中で、デプロイメント戦略の重要性や、アップグレードの計画における柔軟な対応がどれほど有益であるかを深く理解しました。特に、ブルーグリーンデプロイメントは大きなリスクを伴うアップグレード作業でも、ほとんどダウンタイムなしで実施できる点が非常に印象的でした。

お悩みご相談ください

参考記事

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Sequence
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/ams3-temptable-behavior.html
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.upgrade-prechecks.html
https://dev.mysql.com/doc/refman/8.0/ja/upgrading-from-previous-series.html
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-considerations.html