翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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、1.23.\$1、2.04.\$1、2.07.\$1、2.08.\$1、2.09.\$1、2.10.\$1、3.01.\$1、3.02.\$1 です。
既存の Aurora MySQL 2.\$1 データベースクラスタを Aurora MySQL 2.10.0 にアップグレードできます。Aurora MySQL バージョン 1 を実行しているクラスターの場合、既存の Aurora MySQL 1.23 以降のクラスターを 2.10.0 に直接アップグレードできます。現在サポートされている Aurora MySQL リリースから取得したスナップショットを Aurora MySQL 2.10.0 で復元することもできます。
ご質問やご不明点がございましたら、コミュニティフォーラムや [AWS サポート](https://aws.amazon.com/support)から AWS サポートにお問い合わせください。詳細については、「**Amazon Aurora ユーザーガイド」の「[Amazon Aurora DB クラスターのメンテナンス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html)」を参照してください。
**注記**
Aurora MySQL データベースクラスターをアップグレードする方法については、「**Amazon Aurora ユーザーガイド」の「[Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html)」を参照してください。
## 改善点
**以下のセキュリティの問題と CVE の修正:**
マネージド型の環境での処理を微調整するための修正およびその他の機能強化。以下の CVE の追加の修正:
+ [CVE-2021-23841](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23841)
+ [CVE-2021-3449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3449)
+ [CVE-2020-28196](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28196)
+ [CVE-2020-14790](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14790)
+ [CVE-2020-14776](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14776)
+ [CVE-2020-14567](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14567)
+ [CVE-2020-14559](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14559)
+ [CVE-2020-14553](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14553)
+ [CVE-2020-14547](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14547)
+ [CVE-2020-14540](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14540)
+ [CVE-2020-14539](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14539)
+ [CVE-2018-3251](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3251)
+ [CVE-2018-3156](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3156)
+ [CVE-2018-3143](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3143)
+ [CVE-2016-5440](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5440)
**新機能:**
+ `db.t3.large` インスタンスクラスが Aurora MySQL のためにサポートされるようになりました。
+ *バイナリログレプリケーション:*
+ ライタースレッドとダンプスレッド間の競合を減らすことによって、バイナリログのパフォーマンスを向上させるために、バイナリログ I/O キャッシュを導入しました。詳細については、「**Amazon Aurora ユーザーガイド」の「[バイナリログのレプリケーションの最適化](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.html#binlog-optimization)」を参照してください。
+ [Aurora MySQL バージョン 2.08](AuroraMySQL.Updates.2080.md) では、バイナリログ (binlog) 処理が改善され、非常に大きなトランザクションが関与している場合に、クラッシュリカバリ時間とコミット時間のレイテンシーが短縮されました。GTID が有効になっているクラスターでは、これらの改善がサポートされるようになりました。
+ *リーダーインスタンスの可用性の向上:*
+ これまでは、ライターインスタンスが再起動すると、Aurora MySQL クラスター内のすべてのリーダーインスタンスも再起動していました。本日のリリースにより、リージョン内のリーダーインスタンスはライターインスタンスの再起動中も引き続き読み取りリクエストを処理するようになります。これにより、クラスターでの読み取りの可用性が向上します。詳細については、「**Amazon Aurora ユーザーガイド」の「[Rebooting an Aurora MySQL cluster (version 2.10 and higher)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_RebootCluster.html#aurora-mysql-survivable-replicas)」を参照してください。
**重要**
Aurora MySQL 2.10 にアップグレードした後、ライターインスタンスを再起動してもクラスター全体の再起動は実行されません。クラスター全体を再起動する場合は、ライターインスタンスを再起動した後に、クラスター内のリーダーインスタンスを再起動します。
+ Logical read ahead (LRA) 技術によってリクエストされた事前読み取りページの読み取りのパフォーマンスが改善されました。これは、Aurora ストレージに送信された単一のリクエストで複数のページ読み取りをバッチ処理することによって行われました。その結果、LRA 最適化を使用するクエリは、最大 3 倍速く実行されます。
+ *ダウンタイムのない再起動とパッチ適用:*
+ ダウンタイムのない再起動 (ZDR) とダウンタイムのないパッチ適用 (ZDP) が改善され、バイナリログ記録が有効になっている場合の追加サポートなど、幅広いシナリオで ZDR および ZDP が有効になりました。また、ZDR および ZDP イベントの可視性が向上しました。詳細については、「**Amazon Aurora ユーザーガイド」の「[ダウンタイムのない再起動 (ZDR) (Amazon Aurora MySQL 用)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.html#AuroraMySQL.Replication.Availability)」および「[ダウンタイムのないパッチ適用の使用](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP)」を参照してください。
**可用性の向上:**
+ 以前に中断された 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read) に設定されている場合、インターリーブトランザクションがレプリカアプライヤをデッドロックすることがありました。(バグ \$125040331)
+ ストアドプロシージャに、あるビューを参照するステートメントであって、代わりに別のビューを参照したものが含まれていた場合、プロシージャを複数回正常に呼び出すことができませんでした。(バグ \$187858、バグ \$126864199)
+ 多くの `OR` 条件を持つクエリでは、オプティマイザのメモリ効率がより高くなり、システム可変 [range\$1optimizer\$1max\$1mem\$1size](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_range_optimizer_max_mem_size) によって課されるメモリ制限を超える可能性が低くなりました。さらに、その可変のデフォルト値は 1,536,000 から 8,388,608 に引き上げられました。(バグ \$179450、バグ \$122283790)
+ *レプリケーション:* リレーログから次のイベントを読み込むためにレプリカの SQL スレッドによって呼び出される `next_event()` 関数では、(例えば、クローズされたリレーログを原因として) SQL スレッドが実行されてエラーになったときに取得した `relaylog.log_lock` を解放しなかったため、他のすべてのスレッドが、終了するためにリレーログのロックを取得するまで待機する状態を生じさせました。この修正により、SQL スレッドがその状況下で関数を離れる前にロックが解放されます。(バグ \$121697821)
+ 仮想列を使用した `ALTER TABLE` のメモリ破損を修正しました。(バグ \$124961167、バグ \$124960450)
+ *レプリケーション:* マルチスレッドレプリカは、そのサイズより大きいトランザクションを処理する必要があった場合、[slave\$1pending\$1jobs\$1size\$1max](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_pending_jobs_size_max) を使用してより小さなキューサイズで設定できませんでした。[slave\$1pending\$1jobs\$1size\$1max](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_pending_jobs_size_max) より大きいパケットは、[slave\$1max\$1allowed\$1packet](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_max_allowed_packet) で設定された制限よりもパケットが小さい場合でも、エラー `ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX` で拒否されました。今回の修正により、[slave\$1pending\$1jobs\$1size\$1max](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_pending_jobs_size_max) がハード制限ではなくソフト制限になります。パケットのサイズが [slave\$1pending\$1jobs\$1size\$1max](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_pending_jobs_size_max) を超えるが、[slave\$1max\$1allowed\$1packet](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_max_allowed_packet) より小さい場合、すべてのレプリカワーカーが空のキューを持つまでトランザクションが保持されてから処理されます。後続のすべてのトランザクションは、大規模なトランザクションが完了するまで保持されます。したがって、レプリカワーカーのキューサイズは制限されますが、時折発生するより大きなトランザクションは引き続き許可されます。(バグ \$121280753、バグ \$177406)
+ *レプリケーション:* マルチスレッドレプリカを使用する場合、適用元エラーで、Performance Schemaのレプリケーションテーブルで外部化されたデータと一致しないワーカー ID データが表示されました。(バグ \$125231367)
+ *レプリケーション:* [-gtid-mode=ON](https://dev.mysql.com/doc/refman/5.7/en/replication-options-gtids.html#sysvar_gtid_mode)、[-log-bin=OFF](https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_log_bin)、そして[-slave-skip-errors](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_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 状態の更新の制約がなくなります。(バグ \$122268777)
+ *レプリケーション:* バイナリログ記録が無効になっているときに、部分的に失敗したステートメントが、自動生成または指定された GTID を正しく消費しませんでした。この修正により、部分的に失敗した [DROP TABLE](https://dev.mysql.com/doc/refman/5.7/en/drop-table.html)、部分的に失敗した [DROP USER](https://dev.mysql.com/doc/refman/5.7/en/drop-user.html)、または部分的に失敗した [DROP VIEW](https://dev.mysql.com/doc/refman/5.7/en/drop-view.html) がそれぞれ関連する GTID を消費することと、バイナリログ記録が無効である場合は、それを `@@GLOBAL.GTID_EXECUTED` および `mysql.gtid_executed` テーブルに保存することが保証されます。(バグ \$121686749)
+ *レプリケーション:* MySQL 5.7 を実行しているレプリカは、MySQL 5.5 の一部ではない [server\$1uuid](https://dev.mysql.com/doc/refman/5.7/en/replication-options.html#sysvar_server_uuid) の取得エラーにより、MySQL 5.5 ソースに接続できませんでした。これは、`server_uuid` の取得方法が変更されたことが原因となって生じました。(バグ \$122748612)
+ *レプリケーション*: 以前に実行された GTID トランザクションをサイレントにスキップする GTID トランザクションのスキップメカニズムは、XA トランザクションで正常に動作しませんでした。(バグ \$125041920)
+ 渡されたトランザクション ID が正しくないせいで失敗した [">XA ROLLBACK](https://dev.mysql.com/doc/refman/5.7/en/xa.html) ステートメントが、正しいトランザクション ID でバイナリログに記録され、レプリケーションレプリカによって処理される可能性があります。バイナリログ記録が実行される前にエラー状況をチェックし、失敗した XA `ROLLBACK` ステートメントはログに記録されなくなりました。(バグ \$126618925)
+ *レプリケーション:* ソースログファイル名とソースログの位置を指定しない [CHANGE MASTER TO](https://dev.mysql.com/doc/refman/5.7/en/change-master-to.html) ステートメントを使用してレプリカが設定された場合、[START SLAVE](https://dev.mysql.com/doc/refman/5.7/en/start-slave.html) が発行される前にシャットダウンされ、[-relay-log-recovery](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_relay_log_recovery)) セットのオプションで再起動され、レプリケーションはスタートされません。これは、リレーログの復旧が試行される前にレシーバースレッドがスタートされておらず、ソースログファイル名とソースログの位置を提供するログローテーションイベントがリレーログで使用できないために発生しました。この場合、レプリカはリレーログの復旧をスキップし、警告をログに記録し、レプリケーションをスタートします。(バグ \$128996606、バグ \$193397)
+ *レプリケーション:* 行ベースのレプリケーションでは、`utf8mb3` 列を持つテーブルから、列が `utf8mb4` 文字セットで定義されている同じ定義のテーブルにレプリケートするときに、フィールド文字数を誤って表示するメッセージが返されました。(バグ \$125135304、バグ \$183918)
+ *レプリケーション:* GTID が使用中のレプリケーションレプリカで [RESET SLAVE](https://dev.mysql.com/doc/refman/5.7/en/reset-slave.html) ステートメントが発行されると、既存のリレーログファイルは消去されましたが、チャネル用の受信した GTID のセットがクリアされる前に、代わりの新しいリレーログファイルが生成されました。したがって、以前の GTID セットは `PREVIOUS_GTIDS` イベントとして新しいリレーログファイルに書き込まれ、両方のサーバーの gtid\$1executed セットが空であっても、レプリカがソースよりも多くの GTID を持つことを示す致命的なエラーがレプリケーションで発生しました。ここで、`RESET SLAVE` が発行されると、新しいリレーログファイルが生成される前に受信した GTID のセットがクリアされるため、この状況は発生しません。(バグ \$127411175)
+ *レプリケーション:* レプリケーションのために GTID が使用されているときに、分析エラー ([ER\$1PARSE\$1ERROR](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html#error_er_parse_error)) を引き起こしたステートメントを含むトランザクションを、同じ GTID で空のトランザクションまたは代替トランザクションの挿入のための推奨される方法によって、手動でスキップできませんでした。このアクションにより、レプリカは既に使用されている GTID を識別し、GTID を共有した不要なトランザクションをスキップします。ただし、分析エラーの場合、GTID をスキップする必要があるかどうかを確認する前にステートメントが分析されたため、いかなる場合でもトランザクションをスキップする意図があったにもかかわらず、分析エラーによりレプリケーション適用元スレッドが停止しました。この修正により、GTID が既に使用されていたため、関連するトランザクションをスキップする必要がある場合に、レプリケーションの適用元スレッドが分析エラーを無視するようになりました。この動作の変更は、`mysqlbinlog` によって生成されるバイナリログ出力で構成されるワークロードの場合には適用されないことに注意してください。そのような状況では、スキップされたトランザクションの直後に実行される、分析エラーがあるトランザクションも、エラーを発生させるべきときに警告なしでスキップされるリスクがあります。(バグ \$127638268)
+ *レプリケーション:* GTID に対する SQL スレッドが部分的なトランザクションをスキップできるようにします。(バグ \$125800025)
+ *レプリケーション:* 負のタイムアウトパラメータまたは小数のタイムアウトパラメータが `WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()` に提供されると、サーバーは予期しない動作をしました。この修正によりもたらされる結果は次のとおりです。
+ 小数のタイムアウト値はそのまま読み込まれ、丸められることはありません。
+ サーバーが厳密な SQL モードの場合、負のタイムアウト値はエラーで拒否されます。サーバーが厳密な SQL モードでない場合、この値は、関数が待機せずに、即時に `NULL` を返し、その後に警告を発行するようにします。(バグ \$124976304、バグ \$183537)
+ *レプリケーション*: `WAIT_FOR_EXECUTED_GTID_SET()` 関数が小数部 (1.5 など) を含むタイムアウト値とともに使用された場合、キャストロジックのエラーは、タイムアウトが最も近い 1 秒に切り捨てられ、1 秒未満の値 (0.1 など) はゼロに切り捨てられたことを意味していました。キャストロジックが修正され、タイムアウト値が当初指定されたとおりに、丸められることなく、適用されるようになりました。Dirkjan Bussink の貢献に感謝の意を表します。(バグ \$129324564、バグ \$194247)
+ GTID を有効にすると、複数ステートメントトランザクション内の切断された XA トランザクションで [XA COMMIT](https://dev.mysql.com/doc/refman/5.7/en/xa.html) がアサーションを発生させました。(バグ \$122173903)
+ *レプリケーション:* [gtid\$1next](https://dev.mysql.com/doc/refman/5.7/en/replication-options-gtids.html#sysvar_gtid_next) 値が手動で設定されたときに、不明なトランザクション識別子に対して [XA ROLLBACK](https://dev.mysql.com/doc/refman/5.7/en/xa.html) ステートメントが発行された場合、デバッグ構築でアサーションが発生しました。XA `ROLLBACK` ステートメントがエラーで失敗した場合、サーバーは GTID 状態の更新を試行しなくなりました。(バグ \$127928837、バグ \$190640)
+ 複数の `CASE` 関数が `ORDER BY` 句で使用されている際に発生する誤ったソート順の問題を修正しました (Bug\$122810883)。
+ 順序付けを使用する一部のクエリが、初期化されていない列に最適化中にアクセスし、サーバーを終了させる可能性があります。(バグ \$127389294)
## Aurora MySQL バージョン 1 との比較
以下の Amazon Aurora MySQL 機能は Aurora MySQL バージョン 1 (MySQL 5.6 互換) でサポートされていますが、Aurora MySQL バージョン 2 (MySQL 5.7 互換) では現在サポートされていません。
+ ハッシュ結合｡ 詳細については、「**Amazon Aurora ユーザーガイド」の「[ハッシュ結合を使用した大規模な Aurora MySQL 結合クエリの最適化](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html#Aurora.BestPractices.HashJoin)」を参照してください。
+ AWS Lambda 関数を同期的に呼び出すためのネイティブ関数。詳細については、「**Amazon Aurora ユーザーガイド」の「[Aurora MySQL ネイティブ関数を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html#AuroraMySQL.Integrating.NativeLambda)」を参照してください。
+ スキャンバッチ処理｡ 詳細については、「[Aurora MySQL データベースエンジンの更新 2017-12-11 (バージョン 1.16) (廃止)](AuroraMySQL.Updates.20171211.md)」を参照してください。
+ Amazon S3 バケットを使用した MySQL からのデータ移行｡ 詳細については、「**Amazon Aurora ユーザーガイド」の「[Amazon S3 バケットを使用した MySQL からのデータ移行](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3)」を参照してください。
## 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 ステートメント