1、Mysql的主從同步就是當master（主庫）發生數據變化的時候，會實時同步到slave（從庫）。
2、主從復制可以水平擴展數據庫的負載能力，容錯，高可用，數據備份。
3、不管是delete、update、insert，還是創建函數、存儲過程，都是在master上，當master有操作的時候，slave會快速的接收到這些操作，從而做同步。
主要的實現原理：
1、在master機器上，主從同步時間會被寫道特殊的log文件中（binary-log）；
2、在slave機器上，slave讀取主從同步事件，并根據讀取的事件變化，在slave庫上做相應的更改。
詳細的主從同步主要有三種形式：statement、row、mixed
1、statement：會將對數據庫操作的sql語句寫道binlog中
2、row：會將每一條數據的變化寫道binlog中。
3、mixed：statement與row的混合。Mysql決定什么時候寫statement格式的，什么時候寫row格式的binlog。
在master機器上的操作：
當master上的數據發生變化的時候，該事件變化會按照順序寫入binlog中。當slave連接到master的時候，master機器會為slave開啟binlog dump線程。當master的binlog發生變化的時候，binlog dump線程會通知slave，并將相應的binlog內容發送給slave。
在slave機器上操作：
當主從同步開啟的時候，slave上會創建兩個線程：
? ? ? ? ? ? ? I\O線程：該線程連接到master機器，master機器上的binlog dump 線程會將binlog的內容發送給該I\O線程。該I/O線程接收到binlog內容后，再將內容寫入到本地的relay log。
? ? ? ? ? ? ? sql線程：該線程讀取到I/O線程寫入的ralay log。并且根據relay log。并且根據relay log 的內容對slave數據庫做相應的操作。
4、mysql數據庫從庫同步的延遲問題
首先在服務器上執行show slave satus;可以看到很多同步的參數：
????????????Master_Log_File：SLAVE中的I/O線程當前正在讀取的主服務器二進制日志文件的名稱
????????????Read_Master_Log_Pos：在當前的主服務器二進制日志中，SLAVE中的I/O線程已經讀取的位置
????????????Relay_Log_File：SQL線程當前正在讀取和執行的中繼日志文件的名稱
????????????Relay_Log_Pos：在當前的中繼日志中，SQL線程已讀取和執行的位置
????????????Relay_Master_Log_File：由SQL線程執行的包含多數近期事件的主服務器二進制日志文件的名稱
????????????Slave_IO_Running：I/O線程是否被啟動并成功地連接到主服務器上
????????????Slave_SQL_Running：SQL線程是否被啟動
????????????Seconds_Behind_Master：從屬服務器SQL線程和從屬服務器I/O線程之間的時間差距，單位以秒計。
從庫同步延遲情況出現的
1、show slave status顯示參數Seconds_Behind_Master不為0，這個數值可能會很大
2、show slave status顯示參數Relay_Master_Log_File和Master_Log_File顯示bin-log的編號相差很大，說明bin-log在從庫上沒有及時同步，所以近期執行的bin-log和當前IO線程所讀的bin-log相差很大
3、mysql的從庫數據目錄下存在大量mysql-relay-log日志，該日志同步完成之后就會被系統自動刪除，存在大量日志，說明主從同步延遲很厲害
a、MySQL數據庫主從同步延遲原理
mysql主從同步原理：
主庫針對寫操作，順序寫binlog，從庫單線程去主庫順序讀”寫操作的binlog”，從庫取到binlog在本地原樣執行（隨機寫），來保證主從數據邏輯上一致。
mysql的主從復制都是單線程的操作，主庫對所有DDL和DML產生binlog，binlog是順序寫，所以效率很高，slave的Slave_IO_Running線程到主庫取日志，效率比較高，下一步，問題來了，slave的Slave_SQL_Running線程將主庫的DDL和DML操作在slave實施。DML和DDL的IO操作是隨即的，不是順序的，成本高很多，還可能可slave上的其他查詢產生lock爭用，由于Slave_SQL_Running也是單線程的，所以一個DDL卡主了，需要執行10分鐘，那么所有之后的DDL會等待這個DDL執行完才會繼續執行，這就導致了延時。
有朋友會問：“主庫上那個相同的DDL也需要執行10分，為什么slave會延時？”，答案是master可以并發，Slave_SQL_Running線程卻不可以。
b、 MySQL數據庫主從同步延遲是怎么產生的？
當主庫的TPS并發較高時，產生的DDL數量超過slave一個sql線程所能承受的范圍，那么延時就產生了，當然還有就是可能與slave的大型query語句產生了鎖等待。
首要原因：數據庫在業務上讀寫壓力太大，CPU計算負荷大，網卡負荷大，硬盤隨機IO太高
次要原因：讀寫binlog帶來的性能影響，網絡傳輸延遲。
c、 MySQL數據庫主從同步延遲解決方案。
架構方面
1.業務的持久化層的實現采用分庫架構，mysql服務可平行擴展，分散壓力。
2.單個庫讀寫分離，一主多從，主寫從讀，分散壓力。這樣從庫壓力比主庫高，保護主庫。
3.服務的基礎架構在業務和mysql之間加入memcache或者redis的cache層。降低mysql的讀壓力。
4.不同業務的mysql物理上放在不同機器，分散壓力。
5.使用比主庫更好的硬件設備作為slave
總結，mysql壓力小，延遲自然會變小。
硬件方面
1.采用好服務器，比如4u比2u性能明顯好，2u比1u性能明顯好。
2.存儲用ssd或者盤陣或者san，提升隨機寫的性能。
3.主從間保證處在同一個交換機下面，并且是萬兆環境。
總結，硬件強勁，延遲自然會變小。一句話，縮小延遲的解決方案就是花錢和花時間。
mysql主從同步加速
1、sync_binlog在slave端設置為0
2、–logs-slave-updates 從服務器從主服務器接收到的更新不記入它的二進制日志。
3、直接禁用slave端的binlog
4、slave端，如果使用的存儲引擎是innodb，innodb_flush_log_at_trx_commit =2
從文件系統本身屬性角度優化
master端
修改linux、Unix文件系統中文件的etime屬性， 由于每當讀文件時OS都會將讀取操作發生的時間回寫到磁盤上，對于讀操作頻繁的數據庫文件來說這是沒必要的，只會增加磁盤系統的負擔影響I/O性能?？梢酝ㄟ^設置文件系統的mount屬性，組織操作系統寫atime信息，在linux上的操作為：
打開/etc/fstab，加上noatime參數
/dev/sdb1 /data reiserfs noatime 1 2
然后重新mount文件系統
#mount -oremount /data
PS：
主庫是寫，對數據安全性較高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置是需要的
而slave則不需要這么高的數據安全，完全可以講sync_binlog設置為0或者關閉binlog，innodb_flushlog也可以設置為0來提高sql的執行效率
1、sync_binlog=1 o
MySQL提供一個sync_binlog參數來控制數據庫的binlog刷到磁盤上去。
默認，sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系統自己控制它的緩存的刷新。這時候的性能是最好的，但是風險也是最大的。一旦系統Crash，在binlog_cache中的所有binlog信息都會被丟失。
如果sync_binlog>0，表示每sync_binlog次事務提交，MySQL調用文件系統的刷新操作將緩存刷下去。最安全的就是sync_binlog=1了，表示每次事務提交，MySQL都會把binlog刷下去，是最安全但是性能損耗最大的設置。這樣的話，在數據庫所在的主機操作系統損壞或者突然掉電的情況下，系統才有可能丟失1個事務的數據。
但是binlog雖然是順序IO，但是設置sync_binlog=1，多個事務同時提交，同樣很大的影響MySQL和IO性能。
雖然可以通過group commit的補丁緩解，但是刷新的頻率過高對IO的影響也非常大。對于高并發事務的系統來說，
“sync_binlog”設置為0和設置為1的系統寫入性能差距可能高達5倍甚至更多。
所以很多MySQL DBA設置的sync_binlog并不是最安全的1，而是2或者是0。這樣犧牲一定的一致性，可以獲得更高的并發和性能。
默認情況下，并不是每次寫入時都將binlog與硬盤同步。因此如果操作系統或機器(不僅僅是MySQL服務器)崩潰，有可能binlog中最后的語句丟失了。要想防止這種情況，你可以使用sync_binlog全局變量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog寫入后與硬盤同步。即使sync_binlog設置為1,出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。
2、innodb_flush_log_at_trx_commit （這個很管用）
抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了調整這個值。默認值1的意思是每一次事務提交或事務外的指令都需要把日志寫入（flush）硬盤，這是很費時的。特別是使用電池供電緩存（Battery backed up cache）時。設成2對于很多運用，特別是從MyISAM表轉過來的是可以的，它的意思是不寫入硬盤而是寫入系統緩存。
日志仍然會每秒flush到硬盤，所以你一般不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即使MySQL掛了也可能會丟失事務的數據。而值2只會在整個操作系統掛了時才可能丟數據。
3、ls(1) 命令可用來列出文件的 atime、ctime 和 mtime。
atime 文件的access time 在讀取文件或者執行文件時更改的
ctime 文件的create time 在寫入文件，更改所有者，權限或鏈接設置時隨inode的內容更改而更改
mtime 文件的modified time 在寫入文件時隨文件內容的更改而更改
ls -lc filename 列出文件的 ctime
ls -lu filename 列出文件的 atime
ls -l filename 列出文件的 mtime
stat filename 列出atime，mtime，ctime
atime不一定在訪問文件之后被修改
因為：使用ext3文件系統的時候，如果在mount的時候使用了noatime參數那么就不會更新atime信息。
這三個time stamp都放在 inode 中.如果mtime,atime 修改,inode 就一定會改, 既然 inode 改了,那ctime也就跟著改了.
之所以在 mount option 中使用 noatime, 就是不想file system 做太多的修改, 而改善讀取效能
