1煤禽、復制過程：
主庫執(zhí)行sql時液样，將事務日志存儲到二進制日志文件（binlog）中振亮，
并將binlog發(fā)送給從庫，從庫將會開啟兩個線程鞭莽，一個線程將獲取
到的binlog轉(zhuǎn)存為中繼日志（relaylog）坊秸，另一個線程對relaylog中
的事件進行重放。
2澎怒、主從同步的類型：
（1）全同步復制（Fully synchronous replication）
主庫執(zhí)行完一個事務妇斤，且所有從庫都執(zhí)行了該事務才返回給客戶端。因為需要等待所有從庫才能返回丹拯，所以事務的時間會被拉長站超，從而性能必然會受到較大影響。
全同步是在 MySQL NDB Cluster 上采用的復制方式乖酬。NDB 是分布式存儲引擎死相，無共享架構(gòu)，嚴格來說 NDB 節(jié)點不是復制咬像，而是 2PC算撮，確保事務提交的強一致。該集群在國內(nèi)使用極少县昂，且存在較多問題肮柜，不建議采用。全復制會嚴重影響主庫的事務提交性能倒彰，對網(wǎng)絡要求非常嚴格审洞，不適合同城、異地的架構(gòu)場景待讳。
（2）半同步復制（Semisynchronous replication）
主庫需要等待至少一個從庫節(jié)點收到日志事件芒澜，并刷新 Binlog 到 Relay Log 文件中的 ACK 確認消息后仰剿，才能提交并返回，主庫一般不需要等待所有從庫的 ACK痴晦。注意 ：該 ACK 是確保日志傳送到從庫并寫入到中繼日志南吮，而不是從庫已經(jīng)完成重放、將數(shù)據(jù)寫入完成誊酌。
（3）異步復制（Asynchronous replication）
主庫在執(zhí)行完客戶端提交的事務后會立即提交并返回部凑，不關(guān)心從庫是否已經(jīng)接收到日志并處理。如果此時主庫上已經(jīng)提交的事務因為某些原因未傳送到從庫碧浊，同時主庫發(fā)生宕機砚尽，且在此時從庫提升為主庫，就會導致新主庫數(shù)據(jù)缺失辉词，從而造成主從數(shù)據(jù)不一致的情況發(fā)生必孤。該復制模式下必然存在此問題。
主庫將事務寫入到 Binlog 文件中瑞躺，并通知 dump 線程發(fā)送這些新的 Binlog敷搪，然后主庫就會繼續(xù)處理提交操作，所以此時無法保證這些 Binlog 已經(jīng)成功傳到任何一個從庫節(jié)點上幢哨。
轉(zhuǎn)載自：http://www.reibang.com/p/380e7b4c4584
