翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Aurora MySQL データベースエンジンの更新 2023-11-13 (バージョン 3.04.1、MySQL 8.0.28 互換)
バージョン: 3.04.1
Aurora MySQL 3.04.1 は一般利用可能です。Aurora MySQL 3.04 バージョンは MySQL 8.0.28 と互換性があります。コミュニティで発生した変更の詳細については、MySQL 8.0 リリースノート
注記
このバージョンは、長期サポート (LTS) リリースとして指定されています。詳細については、「Amazon Aurora ユーザーガイド」の「Aurora MySQL 長期サポート (LTS) リリース」を参照してください。
LTS バージョンの AutoMinorVersionUpgrade
パラメータを true
に設定しない (または AWS Management Consoleの [マイナーバージョン自動アップグレード] を有効にしない) ことをお勧めします。このような設定を行うと、DB クラスターが 3.05.2 などの非 LTS バージョンにアップグレードされる可能性があります。
Aurora MySQL バージョン 3 の新機能の詳細については、「Aurora MySQL バージョン 3 は MySQL 8.0 との互換性があります」を参照してください。Aurora MySQL バージョン 3 と Aurora MySQL バージョン 2 の違いについては、「Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較」を参照してください。Aurora MySQL バージョン 3 と MySQL 8.0 コミュニティエディションの比較については、「Aurora MySQL バージョン 3 と MySQL 8.0 コミュニティエディションの比較」を参照してください。
現在サポートされている Aurora MySQL リリースは、2.07.9、2.7.10、2.11.*、2.12.*、3.01.*、3.02.*、3.03.*、3.04.*、および 3.05.* です。
Amazon RDS ブルー/グリーンデプロイを使用して、現在利用可能な Aurora MySQL バージョン 2 クラスターから Aurora MySQL バージョン 3.04.1 クラスターへのインプレースアップグレード、スナップショットの復元、またはマネージドブルー/グリーンアップグレードの開始を実行できます。 MySQL MySQL
Aurora MySQL バージョン 3 へのアップグレードの計画については、「Amazon Aurora ユーザーガイド」の「Upgrade planning for Aurora MySQL version 3」を参照してください。Aurora MySQL のアップグレードに関する一般的な情報については、「Amazon Aurora ユーザーガイド」の「Amazon Aurora MySQL DB クラスターのアップグレード」を参照してください。
トラブルシューティング情報については、「Aurora MySQL バージョン 3 のアップグレードに関する問題のトラブルシューティング」を参照してください。
ご質問やご不明点がございましたら、 コミュニティフォーラムおよび AWS Support からAWS サポート
改良点
可用性の向上:
-
パラレルクエリを使用する Aurora MySQL データベースインスタンスで、多数のパラレルクエリを同時に実行すると、データベースが再起動する問題を修正しました。
-
バイナリログソースが
gtid_mode
ON
または に設定されている場合に、拡張バイナリログが有効になっているバイナリログ (binlog) レプリカクラスターで実行された GTID セットが誤って復元される問題を修正しましたON_PERMISSIVE
。この問題が原因で、レプリカクラスターのライターインスタンスが復元中にさらに再起動したり、実行された GTID セットを照会したときに誤った結果が返されたりする可能性があります。 -
拡張バイナリログが有効になっている場合に解放可能なメモリが減少し、Aurora MySQL データベースインスタンスが再起動またはフェイルオーバーする原因となる、メモリ管理の問題を修正しました。
-
ライターインスタンスがデータベースボリュームを拡大させ、160 GB の倍数に達すると、リーダーインスタンスが再起動する問題を修正しました。
-
拡張バイナリログ機能が有効になっている Aurora MySQL データベースインスタンスが、バイナリログの復旧プロセスが実行されている場合に、起動中に停止してしまう問題を修正しました。
-
SHOW STATUS
ステートメントと PURGE BINARY LOGS
ステートメントを同時に実行すると、デッドラッチが原因でデータベースインスタンスが再起動する可能性がある問題を修正しました。purge binary logs は、ユーザーが設定したバイナリログの保持期間に従って実行されるマネージドステートメントです。 -
データベースが内部システムテーブルでトリガーを作成または削除しているときにライターインスタンスが再起動すると、データベースクラスターが使用できない状態になる問題を修正しました。
-
Aurora レプリカのあるクラスターで拡張バイナリログ機能を使用する場合、セマフォの待機時間が長くなり、データベースインスタンスが再起動する可能性がある問題を修正しました。
全般的な機能強化:
-
Aurora MySQL 3.04.0 で実行されている Aurora Serverless v2 データベースクラスターで拡張バイナリログが有効になっている場合に、データベースが使用できなくなることがある問題を修正しました。
-
拡張バイナリログ機能が有効になっている場合に Aurora Storage に書き込む前に、未使用のストレージメタデータを削除しました。その結果、ネットワーク上で転送されるバイト数が増えて書き込み遅延が長くなり、データベースの再起動やフェイルオーバーが発生する特定のシナリオを回避できます。
-
アップグレード時または移行時に Aurora 固有のパフォーマンススキーマテーブルが作成されない問題を修正しました。
-
拡張バイナリログが有効になっている場合に、CloudWatch の
NumBinaryLogFiles
メトリクスに誤った結果が表示されることがある問題を修正しました。
アップグレードと移行:
-
MySQL 5.7 から MySQL 8.0 にアップグレードする際に、1 つのデータベースに多数のテーブルがある場合、サーバーがメモリを過剰に消費していました。テーブルをアップグレードできるかどうかをチェックするプロセス中に、すべてのデータディクショナリ
Table
オブジェクトを事前に取得し、それぞれを処理して名前を取得し、リストCHECK TABLE ... FOR UPGRADE
で実行しました。この場合、すべてのオブジェクトを事前に取得する必要はなく、そのせいでメモリ消費量に大きな影響が出ていました。この問題を解決するために、このような場合には、一度に 1 つずつ Table
オブジェクトを取得し、必要なチェックをすべて実行して名前を取得し、オブジェクトを解放してから、次のオブジェクトに進むことにしました。(バグ #34526001)
MySQL Community Edition でのバグ修正の統合
このリリースには、以下を含め、8.0.28 までのコミュニティ版のバグ修正がすべて反映されています。詳細については、「MySQL 3.x データベースエンジンの更新で修正された MySQL のバグ」を参照してください。
-
バックグラウンドの TLS 証明書のローテーションが原因で CPU 使用率が高くなる問題を修正しました (コミュニティのバグ修正 #34284186)。