如何對 Amazon Aurora MySQL 中的「等待從屬 SQL 執行緒釋放足夠的轉送日誌空間」錯誤進行疑難排解？

簡短描述

當 Aurora MySQL 是二進位日誌複寫的複本時，它會以與 MySQL 相同的方式執行 I/O 執行緒和 SQL 執行緒。I/O 執行緒會從主節點讀取二進位日誌，然後將它們儲存為複本資料庫執行個體中的轉送日誌。SQL 執行緒會處理轉送日誌中的事件，然後在處理轉送日誌中的事件後刪除轉送日誌。

如果 SQL 執行緒處理事件的速度不足以趕上產生轉送日誌的速度，則轉送日誌的數量就會增加。

當全域變數 relay_log_space_limit 設定為大於 0 且所有轉送日誌的總大小達到限制時，不會儲存新的轉送日誌。在轉送日誌空間再次可用之前，SHOW SLAVE STATUS 的輸出將在 Slave_IO_State 字段中顯示訊息「等待從屬 SQL 執行緒釋放足夠的轉送日誌空間」。

在 Aurora MySQL 中，relay_log_space_limit 設定為 1000000000 (953.6 MiB) 且無法修改。這樣可以防止叢集磁碟區非必要增大。當所有轉送日誌的總大小達到 1000000000 位元組 (953.6 MiB) 時，I/O 執行緒會停止儲存轉送日誌。它會等待 SQL 執行緒處理事件並刪除現有日誌。然後 Slave_IO_State 會顯示消息「等待從屬 SQL 執行緒釋放足夠的轉送日誌空間」。如果 SQL 執行緒未停止，轉送日誌最後會被刪除，而 I/O 執行緒會繼續儲存新的轉送日誌。

這也意味著存在複寫延遲的原因是 SQL 速度不夠快，無法趕上 I/O 執行緒產生的轉送日誌。即使 relay_log_space_limit 已修改為更大的值，轉送日誌仍會進一步累積，直到 SQL 執行緒趕上才能解決問題。

您可以在 SHOW SLAVE STATUS 命令的輸出中檢視目前的轉送日誌空間、I/O 執行緒的狀態，以及 SQL 執行緒的狀態。

Slave_IO_State: Waiting for the slave SQL thread to free enough relay log space
Master_Log_File: mysql-bin-changelog.237029
Read_Master_Log_Pos: 55356151
Relay_Master_Log_File: mysql-bin-changelog.237023
Exec_Master_Log_Pos: 120
Relay_Log_Space: 1000002403

Master_Log_File 和 Read_Master_Log_Pos 顯示二進位日誌檔案名稱，以及 I/O 執行緒完成讀取和儲存的位置。Relay_Master_Log_File 和 Exec_Master_Log_Pos 顯示二進位日誌檔案名稱，以及 SQL 執行緒正在處理的位置。雖然 SQL 執行緒實際讀取的內容是轉送日誌，但會顯示主要資料庫執行個體中對應的二進位日誌名稱和位置。

當 Master_Log_File 與Relay_Master_Log_File 不同時，SQL 執行緒速度不夠快。如果 Master_Log_File 和 Relay_Master_Log_File 相同，則 I/O 執行緒可能會導致延遲。

下列因素可能會導致 SQL 執行緒的效能不足：

• 主要資料庫執行個體上的長時間執行的查詢
• 資料庫執行個體類別大小或儲存空間不足
• 在主要資料庫執行個體上執行的平行查詢
• 同步至複本資料庫執行個體上磁碟的二進位日誌
• 複本資料庫執行個體上的 Binlog_format 設定為 ROW

如需解決這些問題的詳細資訊，請參閱如何使用 Amazon RDS for MySQL 對高複本延遲進行疑難排解

此外，下列因素也會影響 SQL 執行緒的效能：

• 複本資料庫執行個體上非常大的交易歷史記錄清單長度 (HLL)
• 複本資料庫執行個體上效率低的 I/O 操作
• 複本資料庫執行個體上具備大量次要索引的資料表

解決方法

只要複本中有寫入操作，您就無需擔心轉送日誌空間。您可以使用增強型監控中中的寫入輸送量指標來監控此情況。

相反，重點是對該複本的效能進行疑難排解。如需詳細資訊，請參閱如何使用 Amazon RDS for MySQL 對高複本延遲進行疑難排解，以及為什麼我的 Amazon Aurora 讀取複本落後並重新啟動？

---

相關資訊

複本伺服器選項和變數的 MySQL 文件