Aurora MySQL データベースエンジンの更新 2021-05-25 (バージョン 2.10.0) (廃止) - Amazon Aurora
改良点MySQL Community Edition バグ修正の統合Aurora MySQL バージョン 1 との比較MySQL 5.7 の互換性

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

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

バージョン: 2.10.0

Aurora MySQL 2.10.0 は一般公開されています。Aurora MySQL 2.x バージョンは MySQL 5.7 と互換性があり、Aurora MySQL 1.x バージョンは MySQL 5.6 と互換性があります。

現在サポートされている Aurora MySQL リリースは、1.19.5、1.19.6、1.22.*、1.23.*、2.04.*、2.07.*、2.08.*、2.09.*、2.10.*、3.01.*、3.02.* です。

既存の Aurora MySQL 2.* データベースクラスタを Aurora MySQL 2.10.0 にアップグレードできます。Aurora MySQL バージョン 1 を実行しているクラスターの場合、既存の Aurora MySQL 1.23 以降のクラスターを 2.10.0 に直接アップグレードできます。現在サポートされている Aurora MySQL リリースから取得したスナップショットを Aurora MySQL 2.10.0 で復元することもできます。

ご質問やご不明点がございましたら、コミュニティフォーラムや AWS Support AWS から サポートにお問い合わせください。詳細については、「Amazon Aurora ユーザーガイド」の「Amazon Aurora DB クラスターのメンテナンス」を参照してください。

注記

Aurora MySQL データベースクラスターをアップグレードする方法については、「Amazon Aurora ユーザーガイド」の「Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード」を参照してください。

改良点

以下のセキュリティの問題と CVE の修正:

マネージド型の環境での処理を微調整するための修正およびその他の機能強化。以下の CVE の追加の修正:

新機能:

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

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

    • ライタースレッドとダンプスレッド間の競合を減らすことによって、バイナリログのパフォーマンスを向上させるために、バイナリログ I/O キャッシュを導入しました。詳細については、「Amazon Aurora ユーザーガイド」の「バイナリログのレプリケーションの最適化」を参照してください。

    • Aurora MySQL バージョン 2.08 では、バイナリログ (binlog) 処理が改善され、非常に大きなトランザクションが関与している場合に、クラッシュリカバリ時間とコミット時間のレイテンシーが短縮されました。GTID が有効になっているクラスターでは、これらの改善がサポートされるようになりました。

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

    • これまでは、ライターインスタンスが再起動すると、Aurora MySQL クラスター内のすべてのリーダーインスタンスも再起動していました。本日のリリースにより、リージョン内のリーダーインスタンスはライターインスタンスの再起動中も引き続き読み取りリクエストを処理するようになります。これにより、クラスターでの読み取りの可用性が向上します。詳細については、「Amazon Aurora ユーザーガイド」の「Rebooting an Aurora MySQL cluster (version 2.10 and higher)」を参照してください。

      重要

      Aurora MySQL 2.10 にアップグレードした後、ライターインスタンスを再起動してもクラスター全体の再起動は実行されません。クラスター全体を再起動する場合は、ライターインスタンスを再起動した後に、クラスター内のリーダーインスタンスを再起動します。

  • 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 リーダーインスタンスでユーザーレベルのロック機能を使用できない状態を引き起こす問題を修正しました。

MySQL Community Edition バグ修正の統合

  • トランザクション分離レベルが 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() に提供されると、サーバーは予期しない動作をしました。この修正によりもたらされる結果は次のとおりです。

    • 小数のタイムアウト値はそのまま読み込まれ、丸められることはありません。

    • サーバーが厳密な SQL モードの場合、負のタイムアウト値はエラーで拒否されます。サーバーが厳密な SQL モードでない場合、この値は、関数が待機せずに、即時に NULL を返し、その後に警告を発行するようにします。(バグ #24976304、バグ #83537)

  • レプリケーション: 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)

Aurora MySQL バージョン 1 との比較

以下の Amazon Aurora MySQL 機能は Aurora MySQL バージョン 1 (MySQL 5.6 互換) でサポートされていますが、Aurora MySQL バージョン 2 (MySQL 5.7 互換) では現在サポートされていません。

MySQL 5.7 の互換性

この Aurora MySQL バージョンは MySQL 5.7 とワイヤ互換性があり、JSON のサポート、空間インデックス、列生成などの機能が含まれています。Aurora MySQL は、z オーダーカーブを使用した空間インデックス作成のネイティブ実装を使用して、空間データセットにおいて、MySQL 5.7 と比較して 20 倍以上の書き込みパフォーマンスと 10 倍以上の読み取りパフォーマンスを実現します。

この Aurora MySQL バージョンでは、現在、MySQL 5.7 の以下の機能はサポートされていません。

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

  • ページサイズの増加

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

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

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

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

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

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

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

  • CREATE TABLESPACE SQL ステートメント