MySQL的Replication（英文為復(fù)制）是一個多MySQL數(shù)據(jù)庫做主從同步的方案，特點是異步復(fù)制，廣泛用在各種對MySQL有更高性能、更高可靠性要求的場合。與之對應(yīng)的是另一個同步技術(shù)是MySQL Cluster，但因為MySQL Cluster配置比較復(fù)雜，所以使用者較少。
MySQL的Replication是一個異步復(fù)制的過程（mysql5.1.7以上版本分為異步復(fù)制和半同步兩種模式），它是從一個Mysql instance（instance英文為實例）(我們稱之為Master)復(fù)制到另一個Mysql instance(我們稱之slave)。在master與slave之間實現(xiàn)整個復(fù)制過程主要由三個線程來完成，其中兩個線程(SQL線程和IO線程)在slave端，另外一個線程(IO線程)在master端。
要實現(xiàn)MySQL的Replication，首先必須打開master端的binlog (mysql-bin.xxxxxx)日志功能，否則無法實現(xiàn)mysql的主從復(fù)制。因為mysql的整個主從復(fù)制過程實際上就是：slave端從master端獲取binlog日志，然后再在自己身上完全順序的執(zhí)行該日志中所記錄的各種SQL操作。
有關(guān)具體如何開啟mysql的binlog日志功能，請大家自己在網(wǎng)上搜。
MySQL主從復(fù)制的基本交互過程，如下：
1、slave端的IO線程連接上master端，并請求從指定binlog日志文件的指定pos節(jié)點位置(或者從最開始的日志)開始復(fù)制之后的日志內(nèi)容。
2、master端在接收到來自slave端的IO線程請求后，通知負(fù)責(zé)復(fù)制進程的IO線程，根據(jù)slave端IO線程的請求信息，讀取指定binlog日志指定pos節(jié)點位置之后的日志信息，然后返回給slave端的IO線程。該返回信息中除了binlog日志所包含的信息之外，還包括本次返回的信息在master端的binlog文件名以及在該binlog日志中的pos節(jié)點位置。
3、slave端的IO線程在接收到master端IO返回的信息后，將接收到的binlog日志內(nèi)容依次寫入到slave端的relaylog文件(mysql-relay-bin.xxxxxx)的最末端，并將讀取到的master端的binlog文件名和pos節(jié)點位置記錄到master-info（該文件存在slave端）文件中，以便在下一次讀取的時候能夠清楚的告訴master“我需要從哪個binlog文件的哪個pos節(jié)點位置開始，請把此節(jié)點以后的日志內(nèi)容發(fā)給我”。
4、slave端的SQL線程在檢測到relaylog文件中新增內(nèi)容后，會馬上解析該log文件中的內(nèi)容。然后還原成在master端真實執(zhí)行的那些SQL語句，并在自身按順豐依次執(zhí)行這些SQL語句。這樣，實際上就是在master端和slave端執(zhí)行了同樣的SQL語句，所以master端和slave端的數(shù)據(jù)是完全一樣的。
以上mysql主從復(fù)制交互過程比較拗口，理解起來也比較麻煩，我簡化了該交互過程。如下：
1、master在執(zhí)行sql之后，記錄二進制log文件（bin-log）。
2、slave連接master，并從master獲取binlog，存于本地relay-log中，然后從上次記住的位置起執(zhí)行SQL語句，一旦遇到錯誤則停止同步。
從以上mysql的Replication原理可以看出：
* 主從間的數(shù)據(jù)庫不是實時同步，就算網(wǎng)絡(luò)連接正常，也存在瞬間主從數(shù)據(jù)不一致的情況。
* 如果主從的網(wǎng)絡(luò)斷開，則從庫會在網(wǎng)絡(luò)恢復(fù)正常后，批量進行同步。
* 如果對從庫進行修改數(shù)據(jù)，那么如果此時從庫正在在執(zhí)行主庫的bin-log時，則會出現(xiàn)錯誤而停止同步，這個是很危險的操作。所以一般情況下，我們要非常小心的修改從庫上的數(shù)據(jù)。
* 一個衍生的配置是雙主、互為主從配置，只要雙方的修改不沖突，則可以工作良好。
* 如果需要多主庫的話，可以用環(huán)形配置，這樣任意一個節(jié)點的修改都可以同步到所有節(jié)點
