最佳化 Aurora MySQL 的二進位日誌複寫 - Amazon Aurora
多執行緒二進位日誌複寫最佳化 binlog 複寫

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

最佳化 Aurora MySQL 的二進位日誌複寫

接下來，您可以學習如何最佳化二進位日誌複寫效能，並對 Aurora MySQL 中的相關問題進行疑難排解。

提示

本討論假設您熟悉 MySQL 二進位日誌複寫機制及其運作方式。如需背景資訊，請參閱 MySQL 文件中的複寫實作。

多執行緒二進位日誌複寫

使用多執行緒二進位日誌複寫，SQL 執行緒會從轉送日誌讀取事件，並將它們排入佇列，以供 SQL 工作者執行緒套用。SQL 工作者執行緒由協調器執行緒管理。可能的話，會平行套用二進位日誌事件。平行處理的程度取決於包括版本、參數、結構描述設計和工作負載特性等因素。

Aurora MySQL 第 3 版和 Aurora MySQL 2.12.1 版及更新版本支援多執行緒二進位日誌複寫。若要讓多執行緒複本有效平行處理二進位日誌事件，您必須設定多執行緒二進位日誌複寫的來源，而來源必須使用包含其二進位日誌檔案上平行處理資訊的版本。

當 Aurora MySQL 資料庫執行個體設定為使用二進位日誌複寫時，複本執行個體預設會針對低於 3.04 的 Aurora MySQL 版本使用單執行緒複寫。若要啟用多執行緒複寫，請將 replica_parallel_workers 參數更新為大於自訂參數群組1中的值。

對於 Aurora MySQL 3.04 版和更新版本，複寫預設為多執行緒，並將 replica_parallel_workers設定為 4。您可以在自訂參數群組中修改此參數。

為了提高資料庫的彈性，防止意外停止，我們建議您在來源上啟用 GTID 複寫，並允許複本上的 GTIDs。若要允許 GTID 複寫，請在來源和複本ON_PERMISSIVE上gtid_mode將 設定為 。如需 GTID 式複寫的詳細資訊，請參閱使用 GTID型複寫。

下列組態選項可協助您微調多執行緒複寫。如需用法資訊，請參閱《MySQL 參考手冊》中的複寫和二進位記錄選項和變數。如需多執行緒複寫的詳細資訊，請參閱 MySQL 部落格改善具有寫入集型相依性追蹤的平行置放器。

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

  • binlog_format recommended value – 設定為 ROW

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking – 建議值為 WRITESET

  • replica_preserve_commit_order

  • replica_parallel_type – 建議值為 LOGICAL_CLOCK

  • replica_parallel_workers

  • replica_pending_jobs_size_max

  • transaction_write_set_extraction – 建議值為 XXHASH64

您的結構描述和工作負載特性是影響平行複寫的因素。最常見的因素如下。

  • 沒有主索引鍵 – RDS 無法為沒有主索引鍵的資料表建立寫入集相依性。使用 ROW 格式時，單一多列陳述式可以透過來源上的單一完整資料表掃描完成，但會導致複本上修改的每一列進行一次完整資料表掃描。缺少主索引鍵可大幅降低複寫輸送量。

  • 存在外部金鑰 – 如果存在外部金鑰，Amazon RDS 就無法使用寫入集相依性來平行處理具有 FK 關係的資料表。

  • 交易大小 – 如果單一交易跨越數十或數百MB 或 GB，協調器執行緒和其中一個工作者執行緒可能會花費很長的時間處理該交易。在此期間，所有其他工作者執行緒在處理其先前交易後可能會保持閒置。

在 Aurora MySQL 3.06 版及更高版本中，當複寫具有多個次要索引的大型資料表的交易時，您可以改善二進位日誌複本的效能。此功能引入執行緒集區，以在 binlog 複本上平行套用次要索引變更。此功能由aurora_binlog_replication_sec_index_parallel_workers資料庫叢集參數控制，該參數控制可用於套用次要索引變更的平行執行緒總數。參數預設為 0（停用）。啟用此功能不需要重新啟動執行個體。若要啟用此功能，請停止持續複寫、設定所需的平行工作者執行緒數量，然後再次開始複寫。

最佳化 binlog 複寫

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

注意

此功能所使用的記憶體與 MySQL binlog_cache 設定無關。

此功能不適用於使用 db.t2 和 db.t3 執行個體類別的 Aurora 資料庫執行個體。

您不需要調整任何組態參數，即可開啟此最佳化。特別是，如果您已在舊版 Aurora MySQL 中將組態參數調整aurora_binlog_replication_max_yield_seconds為非零值，請針對目前可用的版本將其設回零。

狀態變數aurora_binlog_io_cache_reads，aurora_binlog_io_cache_read_requests可協助您監控從 binlog I/O 快取讀取資料的頻率。

  • aurora_binlog_io_cache_read_requests 顯示對快取發起的 binlog 輸入/輸出讀取要求的次數。

  • aurora_binlog_io_cache_reads 顯示從快取擷取資訊的 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 複本是趕上還是落後於來源。