MySQL 複製滯後與延時複製
1：MySQL 複製滯後解決
MySQL複製被普遍認為是十分有效的，主伺服器進行更改後，從伺服器可在幾秒內做出相應的改動。但如果發生兩者之間同步緩慢的問題， 那麼主要有以下兩個原因：
從結點磁碟問題： 複製操作對每個資料庫都是由一個執行緒來完成，通常執行變更時的滯後是由磁碟延遲引起的。在這種情況下，您應該考慮使用SSD加速這個過程。
頻寬低/網路延遲高： 如果兩個伺服器位於遠端位置（高延遲的情況下）或伺服器之間的存在頻寬較低的問題，我們應使用下面的方法之一或者兩者結合使用，以最大限度地減少伺服器間通訊量。
使用基於語句的複製：基於行的複製會為資料庫中每一行的變更建立一個SQL 語句。基於語句的複製是應用程式傳送的實際SQL語句的記錄。通常基於語句的複製在記錄大小方面更為有效。然而，你應該意識到，當你使用UPDATE … LIMIT1時，基於語句的複製可能並不十分有效
壓縮通訊量： MySQL支援使用 slave_compressed_protocol引數進行日誌壓縮複製。這種方法將減少高達80%的伺服器之間的通訊。然而，壓縮是計算密集型的，所以你應該意識到這樣會產生一些額外的CPU利用率（這通常不屬於資料庫中的問題）。這個引數應該在兩個伺服器上都啟用：
動態的從MySQL命令列輸入：SET GLOBALslave_compressed_protocol = 1;
在MySQL配置檔案中進行配置：
compress master-slave communication
slave_compressed_protocol = 1
最起碼，要理解你的複製行為為何滯後，然後瞭解如何使用正確的方法來解決滯後問題。是的，它就是這麼容易，且十分有效。
來自：http://www.searchdatabase.com.cn/showcontent_87714.htm
2：MySQL 延時複製設定
Mysql （需5.6以上版本）延遲複製配置，通過設定Slave上的MASTER TO MASTER_DELAY引數實現：
CHANGE MASTER TO MASTER_DELAY = N；
N為多少秒，該語句設定從資料庫延時N秒後，再與主資料庫進行資料同步複製
具體操作：
登陸到Slave資料庫伺服器
mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 600；
mysql>start slave;
mysql>show slave status \G;
檢視SQL_Delay的值為600，表示設定成功。
註釋：
SQL_Delay：一個非負整數，表示秒數，Slave滯後多少秒於master。
SQL_Remaining_Delay：當 Slave_SQL_Running_State 等待，直到MASTER_DELAY秒後，Master執行的事件，
此欄位包含一個整數，表示有多少秒左右的延遲。在其他時候，這個欄位是0。
來自：
3：可以檢視mysql的官網
MySQL 5.6 supports delayed replication such that a slave server deliberately lags behind the master by at least a specified amount of time. The default delay is 0 seconds. Use the MASTER_DELAY option for CHANGE MASTER TO to set the delay to N seconds:
CHANGE MASTER TO MASTER_DELAY = N;
An event received from the master is not executed until at least N seconds later than its execution on the master. The exceptions are that there is no delay for format description events or log file rotation events, which affect only the internal state of the SQL thread.
Delayed replication can be used for several purposes:
重點：To protect against user mistakes on the master. A DBA can roll back a delayed slave to the time just before the disaster.
To test how the system behaves when there is a lag. For example, in an application, a lag might be caused by a heavy load on the slave. However, it can be difficult to generate this load level. Delayed replication can simulate the lag without having to simulate the load. It can also be used to debug conditions related to a lagging slave.
To inspect what the database looked like long ago, without having to reload a backup. For example, if the delay is one week and the DBA needs to see what the database looked like before the last few days’ worth of development, the delayed slave can be inspected.
START SLAVE and STOP SLAVE take effect immediately and ignore any delay. RESET SLAVE resets the delay to 0.
SHOW SLAVE STATUS has three fields that provide information about the delay:
SQL_Delay: A nonnegative integer indicating the number of seconds that the slave must lag the master.
SQL_Remaining_Delay: When Slave_SQL_Running_State is Waiting until MASTER_DELAY seconds after master executed event, this field contains an integer indicating the number of seconds left of the delay. At other times, this field is NULL.
Slave_SQL_Running_State: A string indicating the state of the SQL thread (analogous to Slave_IO_State). The value is identical to the State value of the SQL thread as displayed by SHOW PROCESSLIST.
When the slave SQL thread is waiting for the delay to elapse before executing an event, SHOW PROCESSLIST displays its State value as Waiting until MASTER_DELAY seconds after master executed event.
The relay-log.info file now contains the delay value, so the file format has changed. See Section 17.2.2.2, “Slave Status Logs”. In particular, the first line of the file now indicates how many lines are in the file. If you downgrade a slave server to a version older than MySQL 5.6, the older server will not read the file correctly. To address this, modify the file in a text editor to delete the initial line containing the number of lines.
from：http://dev.mysql.com/doc/refman/5.6/en/replication-delayed.html