MySQL 9.0 版本注意事項
隨著連線到來源的複本數量增加，負載（即使很小）也會增加，因為每個複本都使用用戶端連線到來源。此外，由於每個複本都必須接收來源二進位日誌的完整副本，因此來源上的網路負載也可能會增加並產生瓶頸。
如果您使用大量連線到一個來源的複本，而且該來源也忙於處理請求（例如，作為橫向擴展解決方案的一部分），則您可能需要提升複製程序的效能。
提升複製程序效能的一種方法是建立更深層的複製結構，使來源僅複製到一個複本，而其餘複本則連線到此主要複本以滿足其各自的複製需求。此結構的範例顯示在圖 19.3，「使用額外的複製來源來提升效能」中。
為了使此運作，您必須如下設定 MySQL 執行個體
來源 1 是主要來源，所有變更和更新都會寫入資料庫。預設情況下，會在來源伺服器上啟用二進位日誌記錄。
來源 2 是伺服器來源 1 的複本，它為複製結構中的其他複本提供複製功能。來源 2 是唯一允許連線到來源 1 的機器。來源 2 啟用了
--log-replica-updates選項（預設值）。啟用此選項後，來自來源 1 的複製指令也會寫入來源 2 的二進位日誌中，以便它們可以接著被複製到真正的複本。複本 1、複本 2 和複本 3 作為來源 2 的複本，並複製來自來源 2 的資訊，而這些資訊實際上包含在來源 1 上記錄的更新。
上述解決方案減少了主要來源上的用戶端負載和網路介面負載，這應有助於在使用主要來源作為直接資料庫解決方案時，提高其整體效能。
如果您的複本在複製來源上的複製程序時遇到困難，可以使用許多選項。
如果可以，請將中繼日誌和資料檔案放在不同的實體磁碟機上。若要執行此操作，請設定
relay_log系統變數來指定中繼日誌的位置。如果二進位日誌檔案和中繼日誌檔案的讀取造成大量的磁碟 I/O 活動，請考慮增加
rpl_read_size系統變數的值。此系統變數控制從日誌檔案讀取的最小資料量，增加它可能會減少檔案讀取和 I/O 停滯的情況，尤其是在作業系統目前未快取檔案資料時。請注意，會為每個從二進位日誌和中繼日誌檔案讀取的執行緒配置一個此值大小的緩衝區，包括來源上的 dump 執行緒和複本上的協調器執行緒。因此，設定較大的值可能會影響伺服器的記憶體消耗。如果複本明顯比來源慢，您可能需要將複製不同資料庫的責任分配給不同的複本。請參閱 第 19.4.6 節，「將不同的資料庫複製到不同的複本」。
如果您的來源使用交易，並且您不關心複本上的交易支援，請在複本上使用
MyISAM或其他非交易引擎。請參閱 第 19.4.4 節，「在不同的來源和複本儲存引擎中使用複製」。如果您的複本不是作為來源，而且您有一個潛在的解決方案來確保在發生故障時可以啟動來源，則可以停用
log_replica_updates。這可防止 「啞巴」複本也將它們已執行的事件記錄到它們自己的二進位日誌中。