MySQL復(fù)制被普遍認(rèn)為是十分有效的，主服務(wù)器進(jìn)行更改后，從服務(wù)器可在幾秒內(nèi)做出相應(yīng)的改動(dòng)。但如果發(fā)生兩者之間同步緩慢的問(wèn)題， 那么主要有以下兩個(gè)原因：

從結(jié)點(diǎn)磁盤(pán)問(wèn)題： 復(fù)制操作對(duì)每個(gè)數(shù)據(jù)庫(kù)都是由一個(gè)線程來(lái)完成，通常執(zhí)行變更時(shí)的滯后是由磁盤(pán)延遲引起的。在這種情況下，您應(yīng)該考慮使用SSD加速這個(gè)過(guò)程。

帶寬低/網(wǎng)絡(luò)延遲高： 如果兩個(gè)服務(wù)器位于遠(yuǎn)程位置（高延遲的情況下）或服務(wù)器之間的存在帶寬較低的問(wèn)題，我們應(yīng)使用下面的方法之一或者兩者結(jié)合使用，以最大限度地減少服務(wù)器間通信量。

使用基于語(yǔ)句的復(fù)制：基于行的復(fù)制會(huì)為數(shù)據(jù)庫(kù)中每一行的變更創(chuàng)建一個(gè)SQL 語(yǔ)句?；谡Z(yǔ)句的復(fù)制是應(yīng)用程序發(fā)送的實(shí)際SQL語(yǔ)句的記錄。通常基于語(yǔ)句的復(fù)制在記錄大小方面更為有效。然而，你應(yīng)該意識(shí)到，當(dāng)你使用UPDATE ... LIMIT1時(shí)，基于語(yǔ)句的復(fù)制可能并不十分有效

壓縮通信量： MySQL支持使用 slave_compressed_protocol參數(shù)進(jìn)行日志壓縮復(fù)制。這種方法將減少高達(dá)80%的服務(wù)器之間的通信。然而，壓縮是計(jì)算密集型的，所以你應(yīng)該意識(shí)到這樣會(huì)產(chǎn)生一些額外的CPU利用率（這通常不屬于數(shù)據(jù)庫(kù)中的問(wèn)題）。這個(gè)參數(shù)應(yīng)該在兩個(gè)服務(wù)器上都啟用：

動(dòng)態(tài)的從MySQL命令行輸入：SET GLOBALslave_compressed_protocol = 1;

在MySQL配置文件中進(jìn)行配置：

#compress master-slave communication
slave_compressed_protocol = 1

最起碼，要理解你的復(fù)制行為為何滯后，然后了解如何使用正確的方法來(lái)解決滯后問(wèn)題。是的，它就是這么容易，且十分有效。