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

# 最佳化 Aurora MySQL 的二進位日誌複寫
<a name="binlog-optimization"></a>

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

**提示**  
 本討論假設您熟悉 MySQL 二進位日誌複寫機制及其運作方式。如需背景資訊，請參閱 MySQL 文件中的[複寫實作](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html)。

## 多執行緒二進位日誌複寫
<a name="binlog-optimization-multithreading"></a>

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

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

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

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

若要提高資料庫的彈性，以防止意外停止，建議您在來源啟用 GTID 複寫，然後允許在複本的 GTID。若要允許 GTID 複寫，請在來源和複本將 `gtid_mode` 設為 `ON_PERMISSIVE`。如需 GTID 式複寫的詳細資訊，請參閱[使用 GTID 式複寫](mysql-replication-gtid.md)。

下列組態選項可協助您微調多執行緒複寫。如需用法資訊，請參閱《MySQL 參考手冊》**中的[複寫和二進位記錄選項和變數](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html)。如需多執行緒複寫的詳細資訊，請參閱 MySQL 部落格[使用寫入集型相依性追蹤改善平行套用者**](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/)。

最佳參數值取決於幾個因素。例如，二進位日誌複寫的效能會受到資料庫工作負載特性和複本執行所在的資料庫執行個體類別影響。因此，建議您在將新參數設定套用至生產執行個體之前，先徹底測試這些組態參數的所有變更：
+ `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 複寫
<a name="binlog-optimization-binlog-io-cache"></a><a name="binlog_boost"></a><a name="binlog_io_cache"></a>

 在 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 輸入/輸出快取讀取資料的頻率。
+  `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 複本是趕上還是落後於來源。

## 記憶體中轉送日誌
<a name="binlog-optimization-in-memory-relay-log"></a>

在 Aurora MySQL 第 3.10 版及更新版本中，Aurora 推出名為記憶體中轉送日誌的最佳化，以改善複寫輸送量。此最佳化透過快取記憶體中所有中繼轉送日誌內容，來增強轉送日誌 I/O 效能。因此，其透過盡可能減少儲存體 I/O 操作來減少遞交延遲，因為轉送日誌內容仍可在記憶體中輕鬆存取。

根據預設，當複本符合下列任何組態時，系統會自動為 Aurora 受管複寫案例 (包括藍/綠部署、Aurora-Aurora 複寫和跨區域複本) 啟用記憶體中轉送日誌功能：
+ 單執行緒複寫模式 (replica\$1parallel\$1workers = 0)
+ 啟用 GTID 模式的多執行緒複寫：
  + 自動定位已啟用
  + 複本的 GTID 模式設為 ON
+ 以檔案為基礎的複寫搭配 replica\$1preserve\$1commit\$1order = ON

大於 t3.large 的執行個體類別支援記憶體中轉送日誌功能，但無法在 Aurora Serverless 執行個體上使用。轉送日誌循環緩衝區的固定大小為 128 MB。若要監控此功能的記憶體使用量，您可以執行下列查詢：

```
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';
```

記憶體中轉送日誌功能是由 aurora\$1in\$1memory\$1relaylog 參數控制，您可在資料庫叢集或執行個體層級設定該參數。您可以動態啟用或停用此功能，而無需重新啟動執行個體：

1. 停止持續複寫

1. 在參數群組中將 aurora\$1in\$1memory\$1relaylog 設定為 ON (啟用) 或 OFF (停用)

1. 重新啟動複寫

範例：

```
CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;
```

即使將 aurora\$1in\$1memory\$1relaylog 設定為 ON，在特定情況下，記憶體中轉送日誌功能仍可能遭停用。若要驗證功能的目前狀態，您可以使用下列命令：

```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';
```

如果此功能意外停用，您可以透過執行下列動作來識別原因：

```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';
```

此命令會傳回訊息，說明此功能目前停用的原因。