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

# MySQL 端點疑難排解
<a name="CHAP_Troubleshooting_Latency_Source_MySQL"></a>

本節包含 MySQL. AWS DMS scans MySQL 二進位日誌特定的複寫案例，以定期複寫變更。此程序可能會在下列情況下增加延時：

**Topics**
+ [在來源上長時間執行的交易](#CHAP_Troubleshooting_Latency_Source_MySQL_Longrunning)
+ [來源工作負載很大](#CHAP_Troubleshooting_Latency_Source_MySQL_Highworkload)
+ [二進位日誌爭用](#CHAP_Troubleshooting_Latency_Source_MySQL_Binarylog)

## 在來源上長時間執行的交易
<a name="CHAP_Troubleshooting_Latency_Source_MySQL_Longrunning"></a>

由於 MySQL 只會將遞交的交易寫入二進位日誌，因此長時間執行的交易會導致與查詢執行時間成正比的延時峰值。

若要找出長時間執行的交易，請使用下列查詢，或使用慢速查詢日誌：

```
SHOW FULL PROCESSLIST;
```

如需使用慢速查詢日誌的相關資訊，請參閱 [MySQL 文件](https://dev.mysql.com/doc/)中的[慢速查詢日誌](https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)。

若要避免長時間執行交易造成延時峰值，請重新建構來源交易，以減少查詢執行時間或增加遞交頻率。

## 來源工作負載很大
<a name="CHAP_Troubleshooting_Latency_Source_MySQL_Highworkload"></a>

由於 DMS CDC 是單一執行緒，因此大量交易可能會增加來源延時。若要識別來源延時是否是因工作負載繁重，請將延時期間產生的二進位日誌數目和大小與延時之前產生的日誌進行比較。若要檢查二進位日誌和 DMS CDC 執行緒狀態，請使用下列查詢：

```
SHOW BINARY LOGS;
SHOW PROCESSLIST;
```

如需 CDC 二進位日誌傾印執行緒狀態的相關資訊，請參閱[複寫來源執行緒狀態](https://dev.mysql.com/doc/refman/8.0/en/source-thread-states.html)。

您可以將來源上產生的最新二進位日誌位置與目前正在處理的事件 DMS 進行比較，以判斷延時。若要識別來源上的最新二進位日誌，請執行下列操作：
+ 啟動 SOURCE\_CAPTURE 元件上的偵錯日誌。
+ 從任務偵錯日誌擷取 DMS 處理二進位日誌和位置詳細資訊。
+ 使用下列查詢，來識別此來源上的最新二進位日誌：

  ```
  SHOW MASTER STATUS;
  ```

若要進一步最佳化效能，請調整 `EventsPollInterval`。根據預設，DMS 會每 5 秒輪詢二進位日誌，但是您可以藉由降低此值來改善效能。如需 `EventsPollInterval` 設定的詳細資訊，請參閱[使用 MySQL 做為 來源時的端點設定 AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.ConnectionAttrib)。

## 二進位日誌爭用
<a name="CHAP_Troubleshooting_Latency_Source_MySQL_Binarylog"></a>

遷移含有大量資料的多個資料表時，我們建議您將資料表分割為 MySQL 5.7.2 或更新版本的不同任務。在 MySQL 5.7.2 版及更高版本中，主傾印執行緒產生的鎖定爭用更少並輸送量更高。因此，每當傾印執行緒讀取事件時，就不會再鎖定二進位日誌。這表示多個傾印執行緒可以同時讀取二進位日誌檔。這也意味著傾印執行緒可以在用戶端寫入二進制日誌時讀取該日誌。如需傾印執行緒的詳細資訊，請參閱[複寫執行緒](https://dev.mysql.com/doc/refman/8.0/en/replication-threads.html)和 [MySQL 5.7.2 版本備註](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-2.html)。

若要改善 5.7.2 之前 MySQL 來源版本的複寫效能，請嘗試使用 CDC 元件合併任務。