Aurora MySQL データベースエンジンの更新 2021-05-25 (バージョン 2.10.0) (廃止)

CVE-2021-23841

CVE-2021-3449

CVE-2020-28196

CVE-2020-14790

CVE-2020-14776

CVE-2020-14567

CVE-2020-14559

CVE-2020-14553

CVE-2020-14547

CVE-2020-14540

CVE-2020-14539

CVE-2018-3251

CVE-2018-3156

CVE-2018-3143

CVE-2016-5440

db.t3.large インスタンスクラスが Aurora MySQL のためにサポートされるようになりました。

バイナリログレプリケーション:

リーダーインスタンスの可用性の向上:

Logical read ahead (LRA) 技術によってリクエストされた事前読み取りページの読み取りのパフォーマンスが改善されました。これは、Aurora ストレージに送信された単一のリクエストで複数のページ読み取りをバッチ処理することによって行われました。その結果、LRA 最適化を使用するクエリは、最大 3 倍速く実行されます。

ダウンタイムのない再起動とパッチ適用:

以前に中断された DDL アクティビティ中に作成されたテンポラリインデックスおよびテーブルが多数データベースに存在する場合に、起動を高速化するための改善。

中断された DDL オペレーションのクラッシュリカバリ中に再起動を繰り返すことに関連する複数の問題を修正しました。これには、DROP TRIGGER や ALTER TABLE が含まれるほか、特に、テーブル内のパーティショニングのタイプまたはパーティションの数を変更する ALTER TABLE が含まれます。

Database Activity Streams (DAS) のログ処理中にサーバーが再起動される状態を引き起こし得る問題を修正しました。

システムテーブルでの ALTER クエリの処理中にエラーメッセージが出力される問題を修正しました。

クエリキャッシュがリーダーインスタンスで古い結果を返す状態を引き起こし得る問題を修正しました。

システム可変 innodb_flush_log_at_trx_commit が 0 または 2 に設定されているときに、一部の Aurora コミットメトリクスが更新されない問題を修正しました。

クエリキャッシュに格納されたクエリ結果がマルチステートメントトランザクションによって更新されない問題を修正しました。

バイナリログファイルの最終変更タイムスタンプが正しく更新されない状態を引き起こし得る問題を修正しました。これにより、お客様が設定した保存期間に達する前に、バイナリログファイルが早期に消去される可能性があります。

クラッシュリカバリ後に InnoDB から不正確に報告されたバイナリログファイル名と位置を修正しました。

binlog_checksum パラメータが NONE に設定されている場合、大規模なトランザクションが誤ったバイナリログイベントを生成する可能性がある問題を修正しました。

レプリケートされたトランザクションに DDL ステートメントと多数の行変更が含まれている場合に、バイナリログレプリカがエラーで停止する問題を修正しました。

テーブルをドロップするときにリーダーインスタンスで再起動する問題を修正しました。

大きなトランザクションでバイナリログファイルを消費しようとする場合に、オープンソースのコネクタが失敗する状況を引き起こす問題を修正しました。

大きなジオメトリの値を持つテーブル上で空間インデックスを作成した後に、大きなジオメトリ列で誤ったクエリ結果を発生させ得る問題を修正しました。

データベースは再起動中にテンポラリテーブルスペースを再作成し、関連付けられたストレージ領域の解放と再利用を可能にすることができるようになりました。

Aurora リーダーインスタンスで performance_schema テーブルが切り捨てられない問題を修正しました。

バイナリログレプリカが HA_ERR_KEY_NOT_FOUND エラーで停止する問題を修正しました。

FLUSH TABLES WITH READ LOCK ステートメントの実行時にデータベースが再起動する問題を修正しました。

Aurora リーダーインスタンスでユーザーレベルのロック機能を使用できない状態を引き起こす問題を修正しました。

トランザクション分離レベルが REPEATABLE READ に設定されている場合、インターリーブトランザクションがレプリカアプライヤをデッドロックすることがありました。(バグ #25040331)

ストアドプロシージャに、あるビューを参照するステートメントであって、代わりに別のビューを参照したものが含まれていた場合、プロシージャを複数回正常に呼び出すことができませんでした。(バグ #87858、バグ #26864199)

多くの OR 条件を持つクエリでは、オプティマイザのメモリ効率がより高くなり、システム可変 range_optimizer_max_mem_size によって課されるメモリ制限を超える可能性が低くなりました。さらに、その可変のデフォルト値は 1,536,000 から 8,388,608 に引き上げられました。(バグ #79450、バグ #22283790)

レプリケーション: リレーログから次のイベントを読み込むためにレプリカの SQL スレッドによって呼び出される next_event() 関数では、(例えば、クローズされたリレーログを原因として) SQL スレッドが実行されてエラーになったときに取得した relaylog.log_lock を解放しなかったため、他のすべてのスレッドが、終了するためにリレーログのロックを取得するまで待機する状態を生じさせました。この修正により、SQL スレッドがその状況下で関数を離れる前にロックが解放されます。(バグ #21697821)

仮想列を使用した ALTER TABLE のメモリ破損を修正しました。(バグ #24961167、バグ #24960450)

レプリケーション: マルチスレッドレプリカは、そのサイズより大きいトランザクションを処理する必要があった場合、slave_pending_jobs_size_max を使用してより小さなキューサイズで設定できませんでした。slave_pending_jobs_size_max より大きいパケットは、slave_max_allowed_packet で設定された制限よりもパケットが小さい場合でも、エラー ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX で拒否されました。今回の修正により、slave_pending_jobs_size_max がハード制限ではなくソフト制限になります。パケットのサイズが slave_pending_jobs_size_max を超えるが、slave_max_allowed_packet より小さい場合、すべてのレプリカワーカーが空のキューを持つまでトランザクションが保持されてから処理されます。後続のすべてのトランザクションは、大規模なトランザクションが完了するまで保持されます。したがって、レプリカワーカーのキューサイズは制限されますが、時折発生するより大きなトランザクションは引き続き許可されます。(バグ #21280753、バグ #77406)

レプリケーション: マルチスレッドレプリカを使用する場合、適用元エラーで、Performance Schemaのレプリケーションテーブルで外部化されたデータと一致しないワーカー ID データが表示されました。(バグ #25231367)

レプリケーション: -gtid-mode=ON、-log-bin=OFF、そして-slave-skip-errors を使用して実行されている GTID ベースのレプリケーションレプリカで、無視すべきエラーが検出された際に Exec_Master_Log_Pos は正しく更新されず、Exec_Master_Log_Pos の Read_master_log_pos との同期が損なわれました。GTID_NEXT が指定されていない場合、レプリカは、単一のステートメントトランザクションからロールバックするときに GTID 状態を更新しません。トランザクションが終了しても、GTID 状態は別途表示されるので、Exec_Master_Log_Pos は更新されません。この修正により、GTID_NEXT が指定された場合にのみトランザクションがロールバックされるときに GTID 状態の更新の制約がなくなります。(バグ #22268777)

レプリケーション: バイナリログ記録が無効になっているときに、部分的に失敗したステートメントが、自動生成または指定された GTID を正しく消費しませんでした。この修正により、部分的に失敗した DROP TABLE、部分的に失敗した DROP USER、または部分的に失敗した DROP VIEW がそれぞれ関連する GTID を消費することと、バイナリログ記録が無効である場合は、それを @@GLOBAL.GTID_EXECUTED および mysql.gtid_executed テーブルに保存することが保証されます。(バグ #21686749)

レプリケーション: MySQL 5.7 を実行しているレプリカは、MySQL 5.5 の一部ではない server_uuid の取得エラーにより、MySQL 5.5 ソースに接続できませんでした。これは、server_uuid の取得方法が変更されたことが原因となって生じました。(バグ #22748612)

レプリケーション: 以前に実行された GTID トランザクションをサイレントにスキップする GTID トランザクションのスキップメカニズムは、XA トランザクションで正常に動作しませんでした。(バグ #25041920)

渡されたトランザクション ID が正しくないせいで失敗した ">XA ROLLBACK ステートメントが、正しいトランザクション ID でバイナリログに記録され、レプリケーションレプリカによって処理される可能性があります。バイナリログ記録が実行される前にエラー状況をチェックし、失敗した XA ROLLBACK ステートメントはログに記録されなくなりました。(バグ #26618925)

レプリケーション: ソースログファイル名とソースログの位置を指定しない CHANGE MASTER TO ステートメントを使用してレプリカが設定された場合、START SLAVE が発行される前にシャットダウンされ、-relay-log-recovery セットのオプションで再起動され、レプリケーションはスタートされません。これは、リレーログの復旧が試行される前にレシーバースレッドがスタートされておらず、ソースログファイル名とソースログの位置を提供するログローテーションイベントがリレーログで使用できないために発生しました。この場合、レプリカはリレーログの復旧をスキップし、警告をログに記録し、レプリケーションをスタートします。(バグ #28996606、バグ #93397)

レプリケーション: 行ベースのレプリケーションでは、utf8mb3 列を持つテーブルから、列が utf8mb4 文字セットで定義されている同じ定義のテーブルにレプリケートするときに、フィールド文字数を誤って表示するメッセージが返されました。(バグ #25135304、バグ #83918)

レプリケーション: GTID が使用中のレプリケーションレプリカで RESET SLAVE ステートメントが発行されると、既存のリレーログファイルは消去されましたが、チャネル用の受信した GTID のセットがクリアされる前に、代わりの新しいリレーログファイルが生成されました。したがって、以前の GTID セットは PREVIOUS_GTIDS イベントとして新しいリレーログファイルに書き込まれ、両方のサーバーの gtid_executed セットが空であっても、レプリカがソースよりも多くの GTID を持つことを示す致命的なエラーがレプリケーションで発生しました。ここで、RESET SLAVE が発行されると、新しいリレーログファイルが生成される前に受信した GTID のセットがクリアされるため、この状況は発生しません。(バグ #27411175)

レプリケーション: レプリケーションのために GTID が使用されているときに、分析エラー (ER_PARSE_ERROR) を引き起こしたステートメントを含むトランザクションを、同じ GTID で空のトランザクションまたは代替トランザクションの挿入のための推奨される方法によって、手動でスキップできませんでした。このアクションにより、レプリカは既に使用されている GTID を識別し、GTID を共有した不要なトランザクションをスキップします。ただし、分析エラーの場合、GTID をスキップする必要があるかどうかを確認する前にステートメントが分析されたため、いかなる場合でもトランザクションをスキップする意図があったにもかかわらず、分析エラーによりレプリケーション適用元スレッドが停止しました。この修正により、GTID が既に使用されていたため、関連するトランザクションをスキップする必要がある場合に、レプリケーションの適用元スレッドが分析エラーを無視するようになりました。この動作の変更は、mysqlbinlog によって生成されるバイナリログ出力で構成されるワークロードの場合には適用されないことに注意してください。そのような状況では、スキップされたトランザクションの直後に実行される、分析エラーがあるトランザクションも、エラーを発生させるべきときに警告なしでスキップされるリスクがあります。(バグ #27638268)

レプリケーション: GTID に対する SQL スレッドが部分的なトランザクションをスキップできるようにします。(バグ #25800025)

レプリケーション: 負のタイムアウトパラメータまたは小数のタイムアウトパラメータが WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() に提供されると、サーバーは予期しない動作をしました。この修正によりもたらされる結果は次のとおりです。

レプリケーション: WAIT_FOR_EXECUTED_GTID_SET() 関数が小数部 (1.5 など) を含むタイムアウト値とともに使用された場合、キャストロジックのエラーは、タイムアウトが最も近い 1 秒に切り捨てられ、1 秒未満の値 (0.1 など) はゼロに切り捨てられたことを意味していました。キャストロジックが修正され、タイムアウト値が当初指定されたとおりに、丸められることなく、適用されるようになりました。Dirkjan Bussink の貢献に感謝の意を表します。(バグ #29324564、バグ #94247)

GTID を有効にすると、複数ステートメントトランザクション内の切断された XA トランザクションで XA COMMIT がアサーションを発生させました。(バグ #22173903)

レプリケーション: gtid_next 値が手動で設定されたときに、不明なトランザクション識別子に対して XA ROLLBACK ステートメントが発行された場合、デバッグ構築でアサーションが発生しました。XA ROLLBACK ステートメントがエラーで失敗した場合、サーバーは GTID 状態の更新を試行しなくなりました。(バグ #27928837、バグ #90640)

複数の CASE 関数が ORDER BY 句で使用されている際に発生する誤ったソート順の問題を修正しました (Bug#22810883)。

順序付けを使用する一部のクエリが、初期化されていない列に最適化中にアクセスし、サーバーを終了させる可能性があります。(バグ #27389294)

ハッシュ結合｡ 詳細については、「Amazon Aurora ユーザーガイド」の「ハッシュ結合を使用した大規模な Aurora MySQL 結合クエリの最適化」を参照してください。

AWS Lambda 関数を同期的に呼び出すためのネイティブ関数。詳細については、「Amazon Aurora ユーザーガイド」の「Aurora MySQL ネイティブ関数を使用した Lambda 関数の呼び出し」を参照してください。

スキャンバッチ処理｡ 詳細については、「Aurora MySQL データベースエンジンの更新 2017-12-11 (バージョン 1.16) (廃止)」を参照してください。

Amazon S3 バケットを使用した MySQL からのデータ移行｡ 詳細については、「Amazon Aurora ユーザーガイド」の「Amazon S3 バケットを使用した MySQL からのデータ移行」を参照してください。

グループのレプリケーションプラグイン

ページサイズの増加

起動時の InnoDB バッファープールのロード

InnoDB フルテキストパーサープラグイン

マルチソースレプリケーション

オンラインバッファープールのサイズ変更

パスワード検証プラグイン

クエリ書き換えプラグイン

レプリケーションフィルタリング

CREATE TABLESPACE SQL ステートメント