1、mysql主從同步（復制）概念
-
將Mysql某一台主機數據復制到其它主機（slaves）上，並重新執行一遍來實現的。
-
復制過程中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。
-
主服務器將更新寫入二進制日志文件，並維護文件的一個索引以跟蹤日志循環。
-
當一個從服務器連接主服務器時，它通知主服務器從服務器在日志中讀取的最后一次成功更新的位置。
-
從服務器接收從那時起發生的任何更新，然后封鎖並等待主服務器通知新的更新。
·binlog：**是二進制日志文件，用於記錄mysql的數據更新或者潛在更新(比如DELETE語句執行刪除而實際並沒有符合條件的數據)
2、Mysql支持哪些復制
1. 基於語句的復制: 在主服務器執行SQL語句，在從服務器執行同樣語句。
注：MySQL默認采用基於語句的復制，效率較高。一旦發現沒法精確復制時, 會自動選基於行的復制。
2. 基於行的復制: 把改變的內容復制過去，而不是把命令在從服務器上執行一遍. 從mysql5.0開始支持
-
混合類型的復制: 默認采用基於語句的復制，一旦發現基於語句的無法精確的復制時，就會采用基於行的復制。
3、Mysql主從復制原理
-
master服務器將數據的改變都記錄到二進制binlog日志中，只要master上的數據發生改變，則將其改變寫入二進制日志；
-
salve服務器會在一定時間間隔內對master二進制日志進行探測其是否發生改變，如果發生改變，則開始一個I/O Thread請求master二進制事件
-
同時主節點為每個I/O線程啟動一個dump線程，用於向其發送二進制事件，並保存至從節點本地的中繼日志中
-
從節點將啟動SQL線程從中繼日志中讀取二進制日志，在本地重放，使得其數據和主節點的保持一致
-
最后I/O Thread和SQL Thread將進入睡眠狀態，等待下一次被喚醒.
需要理解：
1）從庫會生成兩個線程,一個I/O線程,一個SQL線程;
2）I/O線程會去請求主庫的binlog,並將得到的binlog寫到本地的relay-log(中繼日志)文件中;*
3）主庫會生成一個log dump線程,用來給從庫I/O線程傳binlog;
4）SQL線程,會讀取relay log文件中的日志,並解析成sql語句逐一執行;
4、Mysql復制流程圖
-
master將操作語句記錄到binlog日志中
-
salve服務器會在一定時間間隔內對master二進制日志進行探測其是否發生改變，如果發生改變
-
salave開啟兩個線程：IO線程和SQL線程
1）*IO線程：*負責讀取master的binlog內容到中繼日志relay log里；
2）*SQL線程：*負責從relay log日志里讀出binlog內容，並更新到slave的數據庫里（保證數據一致）
1.2 MySQL同步延遲問題
1、造成mysql同步延遲常見原因
1）網絡：如主機或者從機的帶寬打滿、主從之間網絡延遲很大，導致主上的binlog沒有全量傳輸到從機，造成延遲。
2）機器性能：*從機使用了爛機器？比如主機使用SSD而從機還是使用的SATA*
3）從機高負載：有很多業務會在從機上做統計，把從機服務器搞成高負載，從而造成從機延遲很大的情況
4）大事務：比如在RBR模式下，執行帶有大量的delete操作，這種通過查看processlist相關信息以及使用mysqlbinlog查看binlog中的SQL就能快速進行確認
5）鎖: 鎖沖突問題也可能導致從機的SQL線程執行慢，比如從機上有一些select .... for update的SQL，或者使用了MyISAM引擎等。
2、硬件方面（優化）
1.采用好服務器，比如4u比2u性能明顯好，2u比1u性能明顯好。
2.存儲用ssd或者盤陣或者san，提升隨機寫的性能。
3.主從間保證處在同一個交換機下面，並且是萬兆環境。
總結**：硬件強勁，延遲自然會變小。一句話，縮小延遲的解決方案就是花錢和花時間。
3、mysql主從同步加速
1）sync_binlog在slave端設置為0
當事務提交后，Mysql僅僅是將binlog_cache中的數據寫入Binlog文件，但不執行fsync之類的磁盤 同步指令 通知文件系統將緩存刷新到磁盤
而讓Filesystem自行決定什么時候來做同步，這個是性能最好的。
2）slave端 innodb_flush_log_at_trx_commit = 2
每次事務提交時MySQL都會把log buffer的數據寫入log file，但是flush(刷到磁盤)操作並不會同時進行。
該模式下，MySQL會每秒執行一次 flush(刷到磁盤)操作。
3）–logs-slave-updates 從服務器從主服務器接收到的更新不記入它的二進制日志。
4）直接禁用slave端的binlog