

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Aurora MySQL データベースエンジンの更新 2023-11-13 (バージョン 3.04.1、MySQL 8.0.28 互換)
<a name="AuroraMySQL.Updates.3041"></a><a name="3.04.1"></a><a name="3.04.1"></a>

**バージョン:** 3.04.1

Aurora MySQL 3.04.1 は一般利用可能です。Aurora MySQL 3.04 バージョンは MySQL 8.0.28 と互換性があります。これまでのコミュニティ版の変更点の詳細については、「[MySQL 8.0 Release Notes](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/)」を参照してください。

**注記**  <a name="lts_notice_3041"></a>
このバージョンは、長期サポート (LTS) リリースとして指定されています。詳細については、「**Amazon Aurora ユーザーガイド」の「[Aurora MySQL 長期サポート (LTS) リリース](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Update.SpecialVersions.html#AuroraMySQL.Updates.LTS)」を参照してください。  
LTS バージョンの `AutoMinorVersionUpgrade`パラメータを に設定しない `true` (または **で自動マイナーバージョンアップグレード**を有効にする AWS マネジメントコンソール) ことをお勧めします。これにより、DB クラスターが自動マイナーバージョンアップグレードキャンペーンの次のターゲットバージョンにアップグレードされる可能性があり、それは LTS バージョンではない場合があります。

Aurora MySQL バージョン 3 の新機能の詳細については、「[Aurora MySQL バージョン 3 は MySQL 8.0 との互換性があります](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html)」を参照してください。Aurora MySQL バージョン 3 と Aurora MySQL バージョン 2 の違いについての詳細は、「[Aurora MySQL バージョン 2 と Aurora MySQL バージョン 3 の比較](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-v2-v3.html)」を参照してください。Aurora MySQL バージョン 3 と MySQL 8.0 Community Edition の比較については、「[Aurora MySQL バージョン 3 と MySQL 8.0 コミュニティエディションの比較](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Compare-80-v3.html)」を参照してください。

現在サポートされている Aurora MySQL リリースは、2.07.9、2.7.10、2.11.\$1、2.12.\$1、3.01.\$1、3.02.\$1、3.03.\$1、3.04.\$1、3.05.\$1 です。

Amazon [RDS ブルー/グリーンデプロイを使用して、現在利用可能な Aurora MySQL バージョン 2 クラスターから Aurora MySQL バージョン 3.04.1 クラスターへのインプレースアップグレード、スナップショットの復元、マネージドブルー/グリーン](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html)アップグレードの開始を実行できます。 MySQL 

Aurora MySQL バージョン 3 へのアップグレードの計画については、「**Amazon Aurora ユーザーガイド」の「[Upgrade planning for Aurora MySQL version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.mysql80-upgrade-procedure.html#AuroraMySQL.mysql80-planning)」を参照してください。Aurora MySQL のアップグレードに関する一般的な情報については、「**Amazon Aurora ユーザーガイド」の「[Amazon Aurora MySQL DB クラスターのアップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Upgrading.html)」を参照してください。

トラブルシューティング情報については、「[Aurora MySQL バージョン 3 のアップグレードに関する問題のトラブルシューティング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.mysql80-upgrade-procedure.html#AuroraMySQL.mysql80-upgrade-troubleshooting)」を参照してください。

ご質問やご不明点がございましたら、コミュニティフォーラムおよび AWS Support から[AWS サポート](https://aws.amazon.com/support)を受けることができます。詳細については、「**Amazon Aurora ユーザーガイド」の「[Amazon Aurora DB クラスターのメンテナンス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html)」を参照してください。

## 改良点
<a name="AuroraMySQL.Updates.3041.Improvements"></a>

 **可用性の向上:** 
+ パラレルクエリを使用する Aurora MySQL データベースインスタンスで、多数のパラレルクエリを同時に実行すると、データベースが再起動する問題を修正しました。
+ 拡張バイナリログ (binlog) が有効になっているバイナリログレプリカクラスターで、いずれかのバイナリログソースで `gtid_mode` が `ON` または `ON_PERMISSIVE` に設定されている場合に、実行された GTID セットが誤って復元されることがある問題を修正しました。この問題が原因で、レプリカクラスターのライターインスタンスが復元中にさらに再起動したり、実行された GTID セットを照会したときに誤った結果が返されたりする可能性があります。
+ 拡張バイナリログが有効になっている場合に解放可能なメモリが減少し、Aurora MySQL データベースインスタンスが再起動またはフェイルオーバーする原因となる、メモリ管理の問題を修正しました。
+ ライターインスタンスがデータベースボリュームを拡大させ、160 GB の倍数に達すると、リーダーインスタンスが再起動する問題を修正しました。
+ 拡張バイナリログ機能が有効になっている Aurora MySQL データベースインスタンスが、バイナリログの復旧プロセスが実行されている場合に、起動中に停止してしまう問題を修正しました。
+ [https://dev.mysql.com/doc/refman/8.0/en/show-status.html](https://dev.mysql.com/doc/refman/8.0/en/show-status.html) ステートメントと [https://dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html](https://dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html) ステートメントを同時に実行すると、デッドラッチが原因でデータベースインスタンスが再起動する可能性がある問題を修正しました。purge binary logs は、ユーザーが設定したバイナリログの保持期間に従って実行されるマネージドステートメントです。
+ データベースが内部システムテーブルでトリガーを作成または削除しているときにライターインスタンスが再起動すると、データベースクラスターが使用できない状態になる問題を修正しました。
+ Aurora レプリカのあるクラスターで拡張バイナリログ機能を使用する場合、セマフォの待機時間が長くなり、データベースインスタンスが再起動する可能性がある問題を修正しました。

 **全般的な機能強化:** 
+ Aurora MySQL 3.04.0 で実行されている Aurora Serverless v2 データベースクラスターで拡張バイナリログが有効になっている場合に、データベースが使用できなくなることがある問題を修正しました。
+ 拡張バイナリログ機能が有効になっている場合は、Aurora ストレージへの書き込み前に、未使用のストレージメタデータが削除されます。その結果、ネットワーク上で転送されるバイト数が増えて書き込み遅延が長くなり、データベースの再起動やフェイルオーバーが発生する特定のシナリオを回避できます。
+ アップグレード時または移行時に Aurora 固有のパフォーマンススキーマテーブルが作成されない問題を修正しました。
+ 拡張バイナリログが有効になっている場合に、CloudWatch の `NumBinaryLogFiles` メトリクスに誤った結果が表示されることがある問題を修正しました。

 **アップグレードと移行:** 
+ MySQL 5.7 から MySQL 8.0 にアップグレードする際に、1 つのデータベースに多数のテーブルがある場合、サーバーがメモリを過剰に消費していました。テーブルをアップグレードできるかどうかを確認する過程で、データディクショナリ `Table` オブジェクトをすべて事前に取得し、それぞれを処理して名前を取得してから、リストに対して [https://dev.mysql.com/doc/refman/8.0/en/check-table.html#check-table-version-compatibility](https://dev.mysql.com/doc/refman/8.0/en/check-table.html#check-table-version-compatibility) を実行していたことが判明しました。この場合、すべてのオブジェクトを事前に取得する必要はなく、そのせいでメモリ消費量に大きな影響が出ていました。この問題を解決するために、このような場合には、一度に 1 つずつ `Table` オブジェクトを取得し、必要なチェックをすべて実行して名前を取得し、オブジェクトを解放してから、次のオブジェクトに進むことにしました。(バグ \$134526001)

## MySQL Community Edition でのバグ修正の統合
<a name="AuroraMySQL.Updates.3041.Patches"></a>

このリリースには、以下を含め、8.0.28 までのコミュニティ版のバグ修正がすべて反映されています。詳細については、「[MySQL 3.x データベースエンジンの更新で修正された MySQL のバグ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.MySQLBugs.html#AuroraMySQL.Updates.MySQLBugs.v3)」を参照してください。
+ バックグラウンドの TLS 証明書のローテーションが原因で CPU 使用率が高くなる問題を修正しました (コミュニティのバグ修正 \$134284186)。