本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 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 Support 提供 [AWS Support](https://aws.amazon.com/support)。如需詳細資訊，請參閱《Amazon Aurora 使用者指南》**中的[維護 Amazon Aurora 資料庫叢集](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html)。
**注意**
如需如何升級 Aurora MySQL 資料庫叢集的詳細資訊，請參閱《Amazon Aurora 使用者指南》**中的[升級 Aurora MySQL 資料庫叢集的次要版本或修補程式層級](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)
**新功能：**
+ 現在支援 Aurora MySQL 的 `db.t3.large` 執行個體類別。
+ *二進位日誌複寫：*
+ 推出 binlog 輸入/輸出快取，藉由減少寫入器執行緒與傾印執行緒之間的爭用來改善 binlog 效能。如需詳細資訊，請參閱《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 使用者指南》**中的[重新啟動 Aurora MySQL 叢集 (2.10 版及更高版本)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_RebootCluster.html#aurora-mysql-survivable-replicas)。
**重要**
升級至 Aurora MySQL 2.10 後，重新啟動寫入器執行個體不會執行整個叢集的重新啟動。如果您想要重新啟動整個叢集，請在重新啟動寫入器執行個體後，重新啟動叢集中的任何讀取器執行個體。
+ 改善邏輯提前讀取 (LRA) 技術所要求的提前讀取頁面讀取的效能。這是透過批次處理在 Aurora 儲存中傳送之單個請求中的多個頁面讀取來完成。因此，使用 LRA 最佳化的查詢執行速度高達 3 倍。
+ *零停機重新啟動和修補：*
+ 改善零停機重新啟動 (ZDR) 和零停機修補 (ZDP)，以便在更廣泛的案例中 (包括在啟用二進位記錄時增加的支援) 啟用 ZDR 和 ZDP。此外，也改善了對 ZDR 和 ZDP 事件的可見性。請參閱文件以取得詳細資訊：《Amazon Aurora 使用者指南》**中的[Amazon Aurora MySQL 的零停機重新啟動 (ZDR)](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`。
+ 已修正資料庫活動串流 (DAS) 日誌處理期間，可能導致伺服器重新啟動的問題。
+ 已修正在處理系統表格上的 `ALTER` 查詢時，列印錯誤訊息的問題。
**一般改進：**
+ 已修正查詢快取可能會在讀取器執行個體上傳回過時結果的問題。
+ 已修正當系統變數 `innodb_flush_log_at_trx_commit` 設定為 0 或 2 時，某些 Aurora 遞交指標未更新的問題。
+ 已修正多陳述式交易未重新整理查詢快取中儲存之查詢結果的問題。
+ 已修正可能導致二進位日誌檔的上次修改時間戳記無法正確更新的問題。這可能會導致二進位日誌檔在達到客戶設定的保留期間之前提早遭到清除。
+ 已修正毀損復原後，InnoDB 未正確回報 binlog 檔案名稱和位置的問題。
+ 已修正如果 `binlog_checksum` 參數設為 `NONE` 可能導致大型交易產生不正確的二進位日誌事件的問題。
+ 已修正如果複寫的交易包含 DDL 陳述式和大量資料列變更，則會導致二進位日誌複本因錯誤而停止的問題。
+ 已修正捨棄表格時，讀取器執行個體中會重新啟動的問題。
+ 已修正在嘗試使用具有大型交易的二進位日誌檔案時，導致開源連接器失敗的問題。
+ 已修正在具有大型幾何圖形值的表格上建立空間索引後，可能導致大型幾何圖形資料行的查詢結果不正確的問題。
+ 此資料庫現在會在重新啟動期間重新建立暫時表格空間，以釋放並回收相關聯的儲存空間。
+ 已修正在 Aurora 讀取器執行個體上無法將 `performance_schema` 表格截斷的問題。
+ 已修正會導致二進位日誌複本因 `HA_ERR_KEY_NOT_FOUND` 錯誤而停止的問題。
+ 已修正在執行 `FLUSH TABLES WITH READ LOCK` 陳述式時，導致資料庫重新啟動的問題。
+ 已修正無法在 Aurora 讀取器執行個體上使用使用者層級鎖定功能的問題。
## MySQL 社群版錯誤修正整合
+ 在交易隔離層級設定為 [REPEATABLE READ](https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read) 時，交錯交易有時可能會死鎖複本套用者。(錯誤編號 25040331)
+ 當儲存程序中包含參照視圖的陳述句，而該視圖又參照另一個視圖時，則順利叫用該程序的次數不得超過一次。(錯誤編號 87858、錯誤編號 26864199)
+ 對於有許多 `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。(錯誤編號 79450、錯誤編號 22283790)
+ *複寫：*在 `next_event()` 函數中，複本 SQL 執行緒會呼叫此複寫以從中繼日誌讀取下一個事件，SQL 執行緒並未釋放它在遭遇錯誤 (例如，由於中繼日誌關閉) 時取得的 `relaylog.log_lock`，從而造成等待取得中繼日誌上之鎖定的所有其他執行緒當掉。借助此修正程式，會在 SQL 執行緒在該情況下離開函數的情況前釋放鎖定。(錯誤編號 21697821)
+ 已修正具有虛擬資料行 `ALTER TABLE` 的記憶體損毀。(錯誤編號 24961167、錯誤編號 24960450)
+ *複寫：*如果多執行緒複本曾經需要處理大於該大小的交易，則無法使用 [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) 的任何封包被拒絕，發生錯誤：`ER_MTS_EVENT_BIGGER_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) 設定的限制也是如此。借助此修正程式，[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)，就會保留此交易，在所有複本工作者都有空的佇列後才會加以處理。在大型交易完成前，所有後續交易都會保留。因此，複本工作者的佇列大小可能會受到限制，但仍然允許偶爾進行較大的交易。(錯誤編號 21280753、錯誤編號 77406)
+ *複寫：*使用多執行緒複本時，套用者錯誤會顯示與效能架構複寫表格中外部化資料不一致的工作者 ID 資料。(錯誤編號 25231367)
+ *複寫：*在使用 [-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 狀態。`Exec_Master_Log_Pos` 不會更新，因為即使交易已完成，也會以其他方式顯示其 GTID 狀態。修正程式會移除 GTID 狀態的更新限制，只有在指定 `GTID_NEXT` 時，才會復原交易。(錯誤編號 22268777)
+ *複寫：*停用二進位日誌時，部分失敗的陳述式無法正確地使用自動產生或指定的 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` 表格中。(錯誤編號 21686749)
+ *複寫：*執行 MySQL 5.7 的複本無法連線至 MySQL 5.5 來源，因為擷取不屬於 MySQL 5.5 的 [ server\$1uuid](https://dev.mysql.com/doc/refman/5.7/en/replication-options.html#sysvar_server_uuid) 時發生錯誤。這是由擷取 `server_uuid` 方法的變更所造成。(錯誤編號 22748612)
+ *複寫*：以無訊息方式略過先前執行的 GTID 交易的 GTID 交易略過機制無法針對 XA 交易正常運作。(錯誤編號 25041920)
+ [">XA ROLLBACK](https://dev.mysql.com/doc/refman/5.7/en/xa.html) 陳述式因為指定不正確的交易 ID 而失敗，可以使用正確的交易 ID 將其記錄在二進位日誌中，因而由複寫複本採取行動。現在會檢查二進位記錄發生之前的錯誤情況，並且不會記錄失敗的 XA `ROLLBACK` 陳述式。(錯誤編號 26618925)
+ *複寫：*如果複本是使用未指定來源日誌名稱和來源日誌位置的 [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)) 集重新啟動，則複寫並不會啟動。發生這種情況是因為在嘗試轉送日誌復原之前未啟動接收者執行緒，因此轉送日誌中沒有日誌輪替事件可用來提供來源日誌檔名稱和來源日誌位置。在此情況下，複本現在會略過轉送日誌復原，並記錄警告，然後繼續開始複寫。(錯誤編號 28996606、錯誤編號 93397)
+ *複寫：*在以資料列為基礎的複寫中，當從具有 `utf8mb3` 資料行的表格複寫至到相同定義的表格 (其中該資料欄是透過 `utf8mb4` 字元集定義的) 時，會傳回不正確顯示欄位長度的訊息。(錯誤編號 25135304、錯誤編號 83918)
+ *複寫：*在使用 GTID 的複寫複本上發出 [RESET SLAVE](https://dev.mysql.com/doc/refman/5.7/en/reset-slave.html) 陳述式時，會清除現有的轉送日誌檔，但是在清除通道接收的 GTID 集之前，會產生取代新的轉送日誌檔。因此，先前的 GTID 集會作為 `PREVIOUS_GTIDS` 事件寫入新的轉送日誌檔，造成複寫的嚴重錯誤，該錯誤指出複本的 GTID 比來源還多 (即使兩部伺服器的 gtid\$1executed 都是空的)。現在， 發出 `RESET SLAVE` 時，會在產生新的轉送日誌檔之前清除接收的 GTID 集，這樣就不會發生這種情況。(錯誤編號 27411175)
+ *複寫：*使用 GTID 進行複寫時，無法依照以相同的 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 已在使用中，複寫套用者執行緒現在就會忽略剖析錯誤。請注意，這種行為變更並不適用於由 `mysqlbinlog` 產生的二進位日誌輸出所組成的工作負載。在這種情況下，會有這樣的風險：即具有緊接在略過交易之剖析錯誤的交易也會以無提示的方式遭到略過，而此狀況本應引發錯誤。(錯誤編號 27638268)
+ *複寫：*啟用 SQL 執行緒以 GTID 略過部分交易。(錯誤編號 25800025)
+ *複寫：*將負值或分數逾時參數提供給 `WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()` 時，伺服器會出現非預期的行為。借助此修正程式：
+ 分數逾時值會按原樣讀取，而不會四捨五入。
+ 如果伺服器處於嚴格 SQL 模式，則會拒絕負逾時值，並顯示錯誤；如果伺服器不處於嚴格 SQL 模式，則該值會讓函數 `NULL` 立即傳回，而不需等待，之後會發出警告。(錯誤編號 24976304、錯誤編號 83537)
+ *複寫*：如果 `WAIT_FOR_EXECUTED_GTID_SET()` 函數與包括分數部分（例如 1.5）的逾時值一起使用，則轉換邏輯中的錯誤意味著逾時被四捨五入到最接近的整秒，若是小於 1 秒的值 (例如，0.1)，則為零。現在已更正轉換邏輯，以便按照最初指定的方式套用逾時值，而且沒有四捨五入。感謝 Dirkjan Bussink 的貢獻 (錯誤編號 29324564、錯誤編號 94247)
+ 啟用 GTID 後，在多陳述句交易內中斷連接的 XA 交易上的 [XA COMMIT](https://dev.mysql.com/doc/refman/5.7/en/xa.html) 會引發聲明。(錯誤編號 22173903)
+ *複寫：*當 [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 狀態。(錯誤編號 27928837、錯誤編號 90640)
+ 修正在 `CASE` 子句 (錯誤編號 22810883) 中使用多個 `ORDER BY` 函數時排序順序錯誤的問題。
+ 某些使用排序的查詢可能會在最佳化期間存取未初始化的欄，並造成伺服器結束。(錯誤 \$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 支援、空間索引和產生欄位等功能。相較於 MySQL 5.7，Aurora MySQL 採用的空間索引原生實作主要利用 Z 階曲線，可為空間資料集提供超過 20 倍的寫入效能和超過 10 倍的讀取效能。
此 Aurora MySQL 版本目前不支援下列 MySQL 5.7 功能：
+ 群組複寫外掛程式
+ 已增加的頁面大小
+ 啟動時載入 InnoDB 緩衝集區
+ InnoDB 全文剖析器外掛程式
+ 多來源複寫
+ 線上緩衝集區大小調整
+ 密碼驗證外掛程式
+ 查詢重寫外掛程式
+ 複寫篩選
+ `CREATE TABLESPACE` SQL 陳述式