隨著連線到來源的複本數量增加,負載(雖然很小)也會增加,因為每個複本都會使用與來源的用戶端連線。此外,由於每個複本都必須接收來源二進位日誌的完整副本,因此來源上的網路負載也可能會增加並產生瓶頸。
如果您使用大量連線到一個來源的複本,且該來源也忙於處理請求(例如,作為擴充解決方案的一部分),那麼您可能需要提升複製程序的效能。
提升複製程序效能的一種方法是建立更深層的複製結構,使來源僅複製到一個複本,而其餘複本則連線到此主要複本以滿足其各自的複製需求。此結構的範例顯示在圖 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 停滯。請注意,會為每個從二進位日誌和中繼日誌檔讀取的執行緒 (包括來源上的傾印執行緒和複本上的協調器執行緒) 分配大小為此值的緩衝區。因此,設定較大的值可能會影響伺服器的記憶體消耗。如果複本的速度明顯慢於來源,您可能需要將複製不同資料庫的責任分配給不同的複本。請參閱第 19.4.6 節「將不同的資料庫複製到不同的複本」。
如果您的來源使用交易,並且您不關心複本上的交易支援,請在複本上使用
MyISAM
或其他非交易引擎。請參閱第 19.4.4 節「搭配不同來源和複本儲存引擎使用複製」。如果您的複本不是作為來源,並且您有適當的潛在解決方案可確保在發生故障時可以啟動來源,則您可以停用
log_replica_updates
。這可防止「笨」複本也將它們已執行的事件記錄到自己的二進位日誌中。