Amazon Aurora MySQL バージョン 3（MySQL 8.0 互換）へのアップグレード
InnoDB では、SQL ステートメントを使用して行を削除しても、データベースからすぐには行が物理的に削除されません。 行とそのインデックスレコードは、削除のために書き込まれた undo ログレコードが InnoDB によって破棄された場合にのみ物理的に削除されます。 この削除操作は、行がマルチバージョン同時実行性制御 (MVCC) またはロールバックに不要になった後にのみ実行され、パージと呼ばれます。
パージは定期的に実行されます。 履歴リストから undo ログページを解析して処理します。これは、InnoDB トランザクションシステムによってメンテナンスされるコミット済トランザクションの undo ログページのリストです。 パージすると、undo ログページは処理後に履歴リストから解放されます。
データベースとアプリケーションの機能が期待どおりであることを確認するための一連のテストと検証ステップを定義することから始める
本ブログ執筆時点で、最新の Amazon Aurora MySQL バージョンは MySQL 8.0.32 と互換性のある Amazon Aurora MySQL 3.05 です。 Aurora MySQL 3 は長期サポート(LTS) バージョンもサポートしています。これは MySQL 8.0.28 と互換性のある Aurora MySQL 3.04 マイナーバージョンです。 LTS リリースを利用しているデータベースクラスタは、そのリリースが利用可能になってから少なくとも 3 年間は同じマイナーバージョンのままでいられるため、クラスタのアップグレードサイクルを少なくすることができます。 Aurora MySQL 3 へのアップグレード時にはLTS リリースを使用するのではなく、最新のデフォルトマイナーバージョンにアップグレードして、最新の機能とバグ修正を利用することをおすすめします。
「最新のデフォルトマイナーバージョンにアップグレードして、最新の機能とバグ修正を利用することをおすすめします。」
ref. Amazon Aurora MySQL バージョン 3 のデータベースエンジンの更新
ベストプラクティスとして、MySQL 8.0 の新機能を詳しく調べ、すべての変更を参照し、それらがワークロードに適用されるかどうかを確認することをおすすめします。
特に Amazon Aurora MySQL の場合は、「Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較」を参照して、アップグレード時の変更点を確認することもできます。
ref.
AWS Management Console や AWS Command Line Interface(AWS CLI) から Aurora MySQL 2 から Aurora MySQL 3 へのアップグレードを開始すると、Aurora はバックグラウンドで自動的に事前チェックを実行して、非互換性を検出します。 これらの事前チェックは必須で、スキップできません。 コミュニティ版 MySQL に含まれるものと、Aurora が導入したものの両方のチェックが含まれます。 詳細については、Aurora MySQL のメジャーバージョンアップグレードの事前チェック を参照してください。
ref. Aurora MySQL のメジャーバージョンアップグレードの事前チェック
upgrade-prechecks.log は、Amazon RDS コンソールのログとイベントセクションで見つけることができます。 また、aws rds describe-db-log-files に続けて aws rds download-db-log-file-portion を使用することで、AWS CLI を使用することもできます。
アップグレードを開始する前に、コミュニティエディションの MySQL プリチェッカーツールを使用して既存の Aurora MySQL データベースを分析し、潜在的なアップグレードの問題の大部分を特定するためのアドホックテストを実行することもできます。
ベストプラクティスとして、本番環境でアップグレードする前に、アップグレードプロセスのテストを行うことをおすすめします。 テスト方法については、アップグレード前に新しい Aurora バージョンで DB クラスターをテストする を参照してください。 これらのテストを実行することで、Aurora の事前チェックログファイルを使用して、アップグレードの非互換性 (存在する場合) を把握できるだけでなく、事前チェックの実行にかかる時間とアップグレード全体の期間の見積もりが得られます。 アップグレードにかかる期間は、ワークロードとデータベースオブジェクトの数によって異なります。
ref.
最後に、Aurora の事前チェックは、プロシージャ定義内の予約語など、データベースオブジェクトの非互換性をチェックします。 アプリケーション側のロジックは検証しないため、予約語やサポート外の構文がアプリケーションにどのような影響を与えるかを確認する必要があります。 アップグレードする前に、すべての機能が新しいバージョンで正しく動作することを確認するために、アプリケーションのテストを十分に行うことを強くおすすめします。
これは Playground で試すしかなさそう。
ベストプラクティスとして、アップグレードを開始する前に手動スナップショットを作成して、ロールバック計画を立てることができます。
データベースのアップグレード中のダウンタイムを最小限に抑えることが最優先事項である場合は、古いクラスタとアップグレードされた新しいクラスタを並行して実行するマネージドプロセスを使用できます。 Amazon RDS のブルー/グリーンデプロイメントを使用すると、新しいクラスタを引き継ぐ準備が整うまで、古いクラスタから新しいクラスタへデータをレプリケートできます。 この機能を使用して、データベースクラスタをアップグレードし、ダウンタイムを最小限に抑え、リスクの低いアップグレードを実現できます。
Aurora MySQL DB クラスタのブルー/グリーンデプロイメントを作成する前に、クラスタは バイナリロギング(binlog_format) が有効になっているカスタム DB クラスタパラメータグループに関連付ける必要があります。
ブルー/グリーンデプロイメントの作成手順については、ブルー/グリーンデプロイメントの作成を参照してください。
ref. ブルー/グリーンデプロイの作成
グリーン環境でメジャーまたはマイナー DB エンジンバージョンのアップグレードなどの変更を、ブルー環境に影響を与えることなく行うことができます。グリーン環境でアップグレードをテストした後、スイッチオーバーを実行して、グリーン環境をプロモートできます。スイッチオーバーのタイムアウトは 30-3,600 秒(1 時間)を指定できます。スイッチオーバーが成功すると、Amazon RDS はグリーン環境のエンドポイントの名前をブルー環境の対応するエンドポイントと一致するようにリネームするため、アプリケーションの変更は必要ありません。スイッチオーバーが成功したことを確認するには、ブルー/グリーンデプロイのベストプラクティスを参照してください。詳細な手順を含むデモを見るには、RDS ブルー/グリーンデプロイを使用した Amazon Aurora MySQL バージョン 3 へのアップグレードを参照してください。
ref.
まだ有効になっていない場合、再起動を必要とする バイナリロギングを有効にする必要があります。 さらに、新しいグリーン環境を作成するため、追加コストが発生します。 スイッチオーバーが実行された後、前のブルー クラスタを 削除 してコストを節約できます。
テスト環境をアップグレードした後、本番環境でアップグレードを実施する前に、データベースのパフォーマンスを監視およびテストすることが重要です。
Aurora クラスタの過去のパフォーマンスデータを保存し、ベースラインを確立することをおすすめします。このデータを使用して、現在のパフォーマンスを過去の傾向と比較できます。また、通常のパフォーマンスパターンと異常を区別し、問題に対処する手法を考案できます。
Amazon RDS Performance Insights を使用して、データベースの負荷、上位 SQL クエリ、ユーザー、待機イベントを評価します。データベース負荷が Amazon Aurora MySQL 待機イベント にどのように影響しているかを監視します。これは、パフォーマンスのボトルネックを特定するための最も重要なツールの 1 つになります。
実行に長時間かかるクエリを見つけて、最適化の対象とするために、Aurora MySQL スロークエリログ を有効にすることを検討してください。
Aurora アップグレードでは、初期ステップには Aurora によるクリーンシャットダウンと、トランザクションロールバックや UNDO パージなどの未完了操作の完了が含まれます。したがって、本番環境でアップグレードを開始する準備をする際には、アップグレード期間に影響を与える可能性のある長時間実行されるトランザクションがデータベースにないことを確認してください。同様に、高いロールバックセグメント履歴の長さは、Aurora がターゲットバージョンへのアップグレード前に UNDO ログをパージするため、アップグレードプロセスが遅くなる可能性があります。確認するには、次のコマンドを使用できます: SHOW ENGINE INNODB STATUS SQL SHOW FULL PROCESSLIST SQL SELECT NAME,COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME="trx_rseg_history_len";
メジャーバージョンアップグレード時にカスタムパラメータグループが指定されていない場合、Aurora はターゲットのアップグレードバージョン用に自動的に新しいパラメータグループを作成します。カスタムパラメータグループを使用している Amazon Aurora MySQL インスタンスの場合は、アップグレード時に、現在のバージョンパラメータグループと同様のパラメータを持つターゲットバージョンのパラメータグループを常に選択してください。パラメータの変更については、Aurora MySQL バージョン 3 のパラメータ変更 を参照してください。
lower_case_table_names パラメータにカスタム値を使用している場合は、この設定をあらかじめカスタムパラメータグループで設定する必要があります。Amazon Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード時には、lower_case_table_names に同じ設定を使用することをおすすめします。MySQL 5.7 とは異なり、MySQL 8.0 はアップグレード後に lower_case_table_names の値を変更することが制限されます。アプリケーションの要件を確認し、設定する値を決定してください。これを後から変更することはできません。
Aurora Serverless v1 を使用している場合は、ダウンタイムを最小限に抑えて Aurora Serverless v1 から v2 へアップグレードする を参照してください。 -> Aurora クラスタに大量のデータベースオブジェクト(テーブル、データベース、イベント、トリガー、ストアドプロシージャなど)が含まれている場合は、インスタンスクラス を大きくすることで、アップグレードをより高速に完了できるように CPU 容量とメモリリソースを増やすことを検討してください。