本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

最佳化 Aurora 我的二進位記錄複寫 SQL

接下來，您可以了解如何最佳化二進位記錄複寫效能，並疑難排解 Aurora My 中的相關問題SQL。

多執行緒二進位記錄複寫

使用多執行緒二進位記錄複寫時，執行SQL緒會從轉送記錄檔讀取事件，並將事件排入佇列以供 SQL Worker 執行緒套用。SQL工作線程由協調器線程管理。可能的話，會平行套用二進位日誌事件。

Aurora 我的SQL版本 3 和 Aurora 我的版本 2.12.1 及更高版本中支援多執行緒二進位記錄複寫。SQL

當 Aurora My SQL 資料庫執行個體設定為使用二進位記錄複寫時，複本執行個體預設會針對低於 3.04 版的 Aurora My SQL 版本使用單執行緒複寫。若要啟用多執行緒複寫，您可以在自訂參數群組中將 replica_parallel_workers 參數更新為大於零的值。

對於 Aurora 我的SQL版本 3.04 及更高版本，複寫預設為多執行緒，且replica_parallel_workers設定為。4您可以在自訂參數群組中修改此參數。

下列組態選項可協助您微調多執行緒複寫。如需使用資訊，請參閱《我的SQL參考手冊》中的 ＜ 複寫和二進位記錄選項與變數 ＞。

最佳組態取決於數個因素。例如，二進位日誌複寫的效能會受到資料庫工作負載特性和複本執行所在的資料庫執行個體類別影響。因此，建議您在將新參數設定套用至生產執行個體之前，徹底測試這些組態參數的所有變更：

在 Aurora My 3.06 SQL 版及更高版本中，在為具有多個次要索引的大型資料表複寫交易時，可以改善二進位記錄複本的效能。此功能引入執行緒集區，以便在 binlog 複本上 parallel 套用次要索引變更。此功能由 aurora_binlog_replication_sec_index_parallel_workers DB 叢集參數控制，該參數控制可用於套用次要索引變更的 parallel 執行緒總數。依預設，參數設定為 0 (停用)。啟用此功能不需要重新啟動執行個體。若要啟用此功能，請停止進行中的複寫、設定所需的 parallel 工作者執行緒數目，然後重新啟動複寫。

您也可以使用這個參數作為一個全局變量，其中 n 是 parallel 工作者執行緒的數量：

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

最佳化 binlog 複寫 (Aurora 我的 SQL 2.10 及更高版本)

在 Aurora My SQL 2.10 及更高版本中，Aurora 會自動將稱為 binlog I/O 快取的最佳化套用至二進位記錄複寫。藉由快取最近遞交的 binlog 事件，此最佳化旨在改善 binlog 傾印執行緒效能，同時限制 binlog 來源執行個體上對前景交易的影響。

您不需要調整任何組態參數，即可開啟此最佳化。特別是，如果您在較早的 Aurora My 版本中aurora_binlog_replication_max_yield_seconds將組態參數調整為非零值，請將 Aurora My SQL 2.10 及更高SQL版本的組態參數設定回零。

狀態變數aurora_binlog_io_cache_reads和可aurora_binlog_io_cache_read_requests在 Aurora My SQL 2.10 及更高版本中使用。這些狀態變數可協助您監控從 binlog 輸入/輸出快取讀取資料的頻率。

下列SQL查詢會計算利用快取資訊之 binlog 讀取要求的百分比。在這種情況下，比例越接近 100 越好。

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

binlog 輸入/輸出快取功能也包含與 binlog 傾印執行緒相關的新指標。「傾印執行緒」是新的 binlog 複本連線到 binlog 來源執行個體時所建立的執行緒。

傾印執行緒指標會每隔 60 秒列印至資料庫日誌，字首為 [Dump thread metrics]。此指標包括每個 binlog 複本的資訊，例如 Secondary_id、Secondary_uuid、binlog 檔案名稱，以及每個複本正在讀取的位置。此指標也包括 Bytes_behind_primary，表示複寫來源與複本之間的距離 (以位元組為單位)。此指標會測量複本輸入/輸出執行緒的延遲。該數字與複本SQL應用程序線程的滯後不同，該線程由 binlog 副本上的seconds_behind_master度量表示。您可以透過檢查距離是否減少或增加，判斷 binlog 複本是趕上還是落後於來源。

最佳化 binlog 複寫 (Aurora 我的SQL版本 2 到 2.09)

若要最佳化 Aurora My 的二進位記錄複寫SQL，請調整下列叢集層級最佳化參數。這些參數可協助您指定 binlog 來源執行個體上的延遲與複寫延遲之間的適當平衡。

大型讀取緩衝區和最大產出最佳化的概觀

當二進位日誌傾印執行緒存取 Aurora 叢集磁碟區，且叢集在處理大量交易時，可能會出現二進位日誌複寫效能降低。您可以使用參數 aurora_binlog_use_large_read_buffer、aurora_binlog_replication_max_yield_seconds 和 aurora_binlog_read_buffer_size 協助最小化這種類型的爭用。

假設您有一個情況，其中 aurora_binlog_replication_max_yield_seconds 設定為大於 0，且傾印執行緒的目前 binlog 檔案作用中。在此情況下，二進位日誌傾印執行緒會等待指定的最大秒數，以讓交易填滿目前的 binlog 檔案。此等待期可避免因個別複寫每個 binlog 事件而產生的爭用。不過，這樣做會增加二進位日誌複本的複本延遲。這些複本可能會落後於來源，落後的秒數與 aurora_binlog_replication_max_yield_seconds 設定相同。

目前的 binlog 檔案表示傾印執行緒目前正在讀取以執行複寫的 binlog 檔案。我們認為 binlog 檔案在更新，或開啟以根據未來交易進行更新時，binlog 檔案將處於作用中狀態。當 Aurora 我SQL填滿使用中的 binlog 檔案之後，我SQL會建立並切換至新的 binlog 檔案。舊的 binlog 檔案會變為非作用中狀態。其不再根據未來交易進行更新。

Aurora My 會立即SQL識別aurora_binlog_replication_max_yield_seconds參數值的任何變更。您不需要重新啟動資料庫執行個體。不過，當您開啟此設定時，傾印執行緒只會在目前的 binlog 檔案達到其 128 MB 的大小上限，並輪詢至新的檔案時，才會開始產生。

相關參數

使用下列資料庫叢集參數，來開啟 binlog 最佳化。

啟用二進位日誌複寫的最大產出機制

您可以如下所示開啟二進位日誌複寫，實現最大產出最佳化。這樣做可將 binlog 來源執行個體上交易延遲降到最低。不過，您可能會遇到複寫延遲增加。

關閉二進位日誌複寫最大產出最佳化

您可以如下所示關閉二進位日誌複寫，實現最大產出最佳化。這樣做可將複寫延遲降至最低。不過，您可能會遇到 binlog 來源執行個體上的交易延遲增加。

關閉大型讀取緩衝區

您可以關閉整個大型讀取緩衝區功能，如下所示。