翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Aurora MySQL 8.4.8、2026 年 9 月 3 日
バージョン: 8.4.8
Aurora MySQL のこのリリースは、MySQL 8.4.8 と互換性があります。コミュニティで発生した変更の詳細については、MySQL ウェブサイトの「MySQL 8.4 リリースノート
Aurora MySQL バージョン 8.4 の新機能の詳細については、「MySQL 8.4 と互換性のある Aurora MySQL バージョン 8.4」を参照してください。Aurora MySQL バージョン 8.4 とバージョン 3 の違いについては、「Aurora MySQL バージョン 3 と Aurora MySQL バージョン 8.4 の比較」を参照してください。MySQL 8.4 Community Edition との比較については、Amazon Aurora ユーザーガイドの「Aurora MySQL バージョン 8.4 と MySQL 8.4 Community Edition の比較」を参照してください。
Amazon RDS ブルー/グリーンデプロイを使用して、インプレースメジャーバージョンアップグレードの実行、アップグレードによるスナップショットの復元、またはマネージドブルー/グリーンアップグレードの開始を行うことができます。現在サポートされている Aurora MySQL バージョン 3 クラスターから Aurora MySQL バージョン 8.4.8 にアップグレードできます。
Aurora MySQL バージョン 8.4 へのアップグレードの計画については、「Aurora MySQL クラスターのメジャーバージョンアップグレードの計画」を参照してください。Aurora MySQL のアップグレードに関する一般的な情報については、「Amazon Aurora ユーザーガイド」の「Amazon Aurora MySQL DB クラスターのアップグレード」を参照してください。
トラブルシューティングの詳細については、「Amazon Aurora ユーザーガイド」の「Aurora MySQL インプレースアップグレードのトラブルシューティング」を参照してください。
ご質問やご不明点がございましたら、コミュニティフォーラムおよび AWS Support からAWS サポート
新機能
-
マルチソースバイナリログ (binlog) レプリケーションのサポートが追加されました。この機能を使用すると、Aurora MySQL DB クラスターは複数の MySQL 互換ソースデータベースから同時にデータをレプリケートできます。各ソース接続は、独自のレシーバースレッド、アプリケーションスレッド、リレーログを持つ専用のレプリケーションチャネルを介して管理されます。チャネルごとの新しいストアドプロシージャを使用して、チャネルを設定および管理できます。詳細については、「Amazon Aurora ユーザーガイド」の「Aurora MySQL でのマルチソースレプリケーションの使用」を参照してください。
-
遅延バイナリログ (binlog) レプリケーションのサポートが追加されました。バイナリログレプリカとして機能する Aurora MySQL DB クラスターは、ソースから受信したトランザクションを適用する前に、指定された秒数だけ待機するように設定できます。遅延レプリケーションは、意図しない
DROP TABLEやDELETEステートメントなどの偶発的なデータ変更から保護するために使用できます。これにより、レプリカに伝達される前にエラーを特定して修正するための復旧ウィンドウが提供されます。詳細については、「Amazon Aurora ユーザーガイド」の「レプリケーションの遅延間隔の設定」を参照してください。 -
aurora_transaction_timeoutパラメータを導入しました。このパラメータは、InnoDB トランザクションの最大時間を秒単位で設定します。このパラメータを使用すると、長時間実行されるトランザクション (アクティブまたはアイドル) が InnoDB パージをブロックし、パフォーマンスの問題が発生するのを防ぐことができます。詳細については、「Amazon Aurora ユーザーガイド」の「Aurora MySQL トランザクションタイムアウト」を参照してください。 -
TLS 1.3 接続用のポスト量子ハイブリッドキー交換 (X25519MLKEM768 および SecP256r1MLKEM768) のサポートが追加されました。ポスト量子キー交換をサポートするクライアントは、量子耐性の共有シークレットを自動的にネゴシエートします。現在のセッションがネゴシエートされたグループを確認するには、
Aurora_ssl_named_groupステータス変数をクエリします。例:SHOW STATUS LIKE 'Aurora_ssl_named_group';。
改良点
以下は、Aurora MySQL 8.4.7 と比較して行われた改善点です。「Aurora MySQL 8.4.7 リリースノート」を参照してください。
セキュリティの修正内容
-
SQL SECURITY DEFINER ルーチン (ストアドプロシージャ、関数、またはトリガー) 内で実行された SQL ステートメントに対して、アドバンスト監査ログに誤ったユーザーとホストが記録される問題を修正しました。これらのレコードは、ルーチンを呼び出した SQL クライアントではなく、ルーチンの定義者のユーザーとホスト ( など
'user'@'%') を示しました。この修正後、レコードには呼び出し元の SQL クライアントのユーザーとホストが表示されます。 -
準備済みステートメントを介してクエリを実行すると、アドバンスト監査ログに重複エントリが生成される問題を修正しました。
-
SET ROLE NONEが書き込み転送を使用してセッションで以前にアクティブだったロールの権限を正しくクリアしない問題を修正しました。これにより、ロールの非アクティブ化後に拒否すべきオペレーションが許可される可能性があります。
このリリースには、次の重要度の高い CVEs の修正が含まれています。
このリリースには、次の重要度が中CVEs の修正が含まれています。
このリリースには、以下の重要度の低い CVEs の修正が含まれています。
可用性の向上
-
ALTER TABLE ... REORGANIZE PARTITION、、または の同時オペレーション (パフォーマンススキーマクエリDROP PARTITION、全文検索の最適化、統計収集など) が同じテーブルにアクセスADD PARTITIONしているときに、データベースインスタンスが再起動する問題を修正しました。 -
を使用して列が追加された
ALTER TABLE ... REORGANIZE PARTITIONテーブルでクエリperformance_schema.data_lock_waitsを実行したり、 と同時にperformance_schema.data_locks実行したりすると、データベースインスタンスが再起動する問題を修正しましたALGORITHM=INSTANT。 -
サブパーティションの順序を変更する
ALTER TABLE ... REORGANIZE PARTITIONSQL ステートメントの処理中にライターインスタンスが再起動する問題を修正しました。 -
ライターインスタンスの DDL オペレーションがリーダーインスタンスの特定の SQL ステートメントをブロックまたは強制終了する問題を修正しました。影響を受けるステートメントには、
performance_schemaテーブルTRUNCATEに対するUPDATEや などの書き込みオペレーションと、一時テーブルとオペレーションに対する書き込みJOINオペレーションが含まれていました。 -
SQL ステートメント処理後の一時テーブルのクリーンアップ中に、グローバルデータベーススイッチオーバーオペレーション中にデータベースライターインスタンスが予期せず再起動する問題を修正しました。この再起動により、スイッチオーバーの完了時間が長くなる可能性があります。
-
リーダー DB インスタンスでの書き込み転送が機能しなくなり、書き込み転送を復元するためにリーダーを再起動する必要がある問題を修正しました。これは、グローバル書き込み転送またはローカル書き込み転送の使用中に転送されたクエリがキャンセルまたはタイムアウトした場合に発生する可能性があります。
-
Aurora serverless スケーリングオペレーション中に重要なデータ構造のサイズ変更が遅れると、RDS ヘルスモニタリングがデータベースインスタンスを再起動する可能性がある問題を修正しました。
-
同時実行性の高い書き込みオペレーション中に内部タイミングの競合が発生すると、ライターインスタンスが再起動する問題を修正しました。
-
拡張バイナリログが有効になっている場合にデータベースインスタンスが再起動する問題を修正しました。
-
レプリカを一時的に切断してライターに再接続し、レプリケーションラグ () が一時的に急増するバグを修正しました
AuroraReplicaLag。 -
Aurora ストレージデーモンで、まれに予期しないデータベースの再起動が発生する可能性がある問題を修正しました。
全般的な改善点:
-
書き込み転送が有効になっている場合、 が
aurora_replica_read_consistencyに設定されているリーダーセッションが最新のコミットされた変更の読み取りに失敗globalする可能性がある問題を修正しました。 -
空間 GIS クエリが明示的な SRID 注釈で宣言された列で Z 順序の空間インデックスを使用する場合にエンジンが再起動する可能性がある問題を修正しました。
-
書き込み転送が有効になっている場合に、正常なリーダーの切断がライターインスタンス
Aborted_clientsで誤って増加する可能性がある問題を修正しました。 -
ダウンタイムのないアップグレード後に接続状態が保持されないことがある問題を修正しました。これにより、予期しない動作が発生する可能性があります。
-
書き込み転送中にリーダーインスタンスを再起動すると、ライターインスタンスに孤立した転送セッションが残り、そのセッションを強制終了するとライターが再起動することがある問題を修正しました。
-
パッチ適用後のデータベースインスタンスとストレージレイヤー間の通信を最適化することで、ダウンタイムのないパッチ適用 (ZDP) 中のダウンタイムを削減しました。
-
DB
aurora_oom_responseパラメータ値に同時に変更があった場合、内部タイムアウト期間後にout-of-memory (OOM) レスポンスアクションを確実に無効にできなかった Aurora MySQL メモリ管理の問題を修正しました。 -
スナップショットの復元後に誤ったバイナリログ座標が報告された拡張ブログの問題を修正しました。以前は、拡張バイナリログがソースクラスターで実行されており、一部のトランザクションがロールバックされている場合、これによりバイナリログレプリケーション設定が無効になる可能性があります。
-
自動増分復旧機能で、パーティション分割されたテーブルの自動増分値が正しく復旧されず、DUPLICATE KEY エラーが発生する可能性がある問題を修正しました。
-
ライターインスタンスの内部および外部の InnoDB 一時テーブルスペースの両方で使用されるクラスターボリュームの合計バイト数をレポート
AuroraTempTableVolumeTotalBytesする新しい CloudWatch メトリクス を追加しました。このメトリクスは、すべてのアクティブなセッションにおける一時的なテーブルスペースストレージの消費量を報告します。これを使用して、成長傾向のモニタリング、ストレージ負荷の高いワークロードの特定、CloudWatch アラームの設定を行うことができます。このメトリクスの詳細については、「Amazon Aurora ユーザーガイド」の「Amazon Aurora の Amazon CloudWatch メトリクス」を参照してください。 一時テーブルの詳細については、MySQL ウェブサイトの「外部一時テーブル」と「内部一時テーブル 」を参照してください。 -
書き込み転送が有効になっているクラスターでフェイルオーバーイベントが発生した後、書き込み転送スループットとレイテンシーメトリクスが誤って 0 と報告される問題を修正しました。これらのメトリクスは、フェイルオーバー後の書き込み転送アクティビティを正確に反映するようになりました。
ForwardingReplicaDMLLatency、ForwardingReplicaDMLThroughput、ForwardingReplicaSelectLatency、およびForwardingReplicaSelectThroughput。 -
INおよびパラメータ化された値を使用して、オプティマイザがプリペアドステートメントを含む最適ではないクエリ実行プランを選択するパフォーマンスの問題を修正しました。 -
並列クエリが有効で、ハッシュ結合に必要なメモリが制限を超えた場合に、ハッシュ結合を使用するクエリが誤った結果を返す問題を修正しました。
アップグレードと移行
-
データベースクラスターのクローン操作が完了するまでに時間がかかる問題を修正しました。
MySQL Community Edition でのバグ修正の統合
このバージョンは MySQL 8.4.8 に基づいています。詳細については、MySQL ウェブサイトの「MySQL 8.4 リリースノート
-
MySQL 8.0.42 で導入されたリグレッションを修正しました。準備済みステートメントまたはストアドプロシージャを使用してパーティションテーブルに挿入すると
ERROR 1748、 (「指定されたパーティションセットと一致しない行を見つけました」) で失敗する可能性があります。これは、パーティションキー列が を使用する場合に発生しますDEFAULT CURRENT_TIMESTAMP。準備時のパーティションプルーニングは、現在のタイムスタンプに基づいてパーティションをロックしましたが、その後の再実行では、タイムスタンプが別のパーティションにマッピングされる可能性があります。この修正の詳細については、MySQL Bugs ウェブサイトの「MySQL アップストリームのバグ #119784」を参照してください。 MySQL