1、Mysql的主從同步就是當(dāng)master（主庫）發(fā)生數(shù)據(jù)變化的時候嚎货，會實時同步到slave（從庫）橘霎。
2、主從復(fù)制可以水平擴展數(shù)據(jù)庫的負(fù)載能力殖属，容錯姐叁，高可用，數(shù)據(jù)備份洗显。
3外潜、不管是delete、update挠唆、insert处窥，還是創(chuàng)建函數(shù)、存儲過程玄组，都是在master上滔驾，當(dāng)master有操作的時候，slave會快速的接收到這些操作俄讹，從而做同步哆致。
主要的實現(xiàn)原理：
1、在master機器上患膛，主從同步時間會被寫道特殊的log文件中（binary-log）摊阀；
2、在slave機器上，slave讀取主從同步事件胞此，并根據(jù)讀取的事件變化臣咖，在slave庫上做相應(yīng)的更改。
詳細(xì)的主從同步主要有三種形式：statement漱牵、row夺蛇、mixed
1、statement：會將對數(shù)據(jù)庫操作的sql語句寫道binlog中
2酣胀、row：會將每一條數(shù)據(jù)的變化寫道binlog中蚊惯。
3、mixed：statement與row的混合灵临。Mysql決定什么時候?qū)憇tatement格式的，什么時候?qū)憆ow格式的binlog趴荸。
在master機器上的操作：
當(dāng)master上的數(shù)據(jù)發(fā)生變化的時候儒溉，該事件變化會按照順序?qū)懭隻inlog中。當(dāng)slave連接到master的時候发钝，master機器會為slave開啟binlog dump線程顿涣。當(dāng)master的binlog發(fā)生變化的時候，binlog dump線程會通知slave酝豪，并將相應(yīng)的binlog內(nèi)容發(fā)送給slave涛碑。
在slave機器上操作：
當(dāng)主從同步開啟的時候，slave上會創(chuàng)建兩個線程：
? ? ? ? ? ? ? I\O線程：該線程連接到master機器孵淘，master機器上的binlog dump 線程會將binlog的內(nèi)容發(fā)送給該I\O線程蒲障。該I/O線程接收到binlog內(nèi)容后，再將內(nèi)容寫入到本地的relay log瘫证。
? ? ? ? ? ? ? sql線程：該線程讀取到I/O線程寫入的ralay log揉阎。并且根據(jù)relay log。并且根據(jù)relay log 的內(nèi)容對slave數(shù)據(jù)庫做相應(yīng)的操作背捌。
4毙籽、mysql數(shù)據(jù)庫從庫同步的延遲問題
首先在服務(wù)器上執(zhí)行show slave satus;可以看到很多同步的參數(shù)：
????????????Master_Log_File：SLAVE中的I/O線程當(dāng)前正在讀取的主服務(wù)器二進(jìn)制日志文件的名稱
????????????Read_Master_Log_Pos：在當(dāng)前的主服務(wù)器二進(jìn)制日志中，SLAVE中的I/O線程已經(jīng)讀取的位置
????????????Relay_Log_File：SQL線程當(dāng)前正在讀取和執(zhí)行的中繼日志文件的名稱
????????????Relay_Log_Pos：在當(dāng)前的中繼日志中毡庆，SQL線程已讀取和執(zhí)行的位置
????????????Relay_Master_Log_File：由SQL線程執(zhí)行的包含多數(shù)近期事件的主服務(wù)器二進(jìn)制日志文件的名稱
????????????Slave_IO_Running：I/O線程是否被啟動并成功地連接到主服務(wù)器上
????????????Slave_SQL_Running：SQL線程是否被啟動
????????????Seconds_Behind_Master：從屬服務(wù)器SQL線程和從屬服務(wù)器I/O線程之間的時間差距坑赡，單位以秒計。
從庫同步延遲情況出現(xiàn)的
1么抗、show slave status顯示參數(shù)Seconds_Behind_Master不為0毅否，這個數(shù)值可能會很大
2、show slave status顯示參數(shù)Relay_Master_Log_File和Master_Log_File顯示bin-log的編號相差很大乖坠，說明bin-log在從庫上沒有及時同步搀突，所以近期執(zhí)行的bin-log和當(dāng)前IO線程所讀的bin-log相差很大
3、mysql的從庫數(shù)據(jù)目錄下存在大量mysql-relay-log日志，該日志同步完成之后就會被系統(tǒng)自動刪除仰迁，存在大量日志甸昏，說明主從同步延遲很厲害
a、MySQL數(shù)據(jù)庫主從同步延遲原理
mysql主從同步原理：
主庫針對寫操作徐许，順序?qū)慴inlog施蜜，從庫單線程去主庫順序讀”寫操作的binlog”，從庫取到binlog在本地原樣執(zhí)行（隨機寫）雌隅，來保證主從數(shù)據(jù)邏輯上一致翻默。
mysql的主從復(fù)制都是單線程的操作，主庫對所有DDL和DML產(chǎn)生binlog恰起，binlog是順序?qū)懶扌担孕屎芨撸瑂lave的Slave_IO_Running線程到主庫取日志检盼，效率比較高肯污，下一步，問題來了吨枉，slave的Slave_SQL_Running線程將主庫的DDL和DML操作在slave實施蹦渣。DML和DDL的IO操作是隨即的，不是順序的貌亭，成本高很多柬唯，還可能可slave上的其他查詢產(chǎn)生lock爭用，由于Slave_SQL_Running也是單線程的圃庭，所以一個DDL卡主了锄奢，需要執(zhí)行10分鐘剧腻，那么所有之后的DDL會等待這個DDL執(zhí)行完才會繼續(xù)執(zhí)行斟薇，這就導(dǎo)致了延時。
有朋友會問：“主庫上那個相同的DDL也需要執(zhí)行10分恕酸，為什么slave會延時堪滨？”，答案是master可以并發(fā)蕊温，Slave_SQL_Running線程卻不可以袱箱。
b、 MySQL數(shù)據(jù)庫主從同步延遲是怎么產(chǎn)生的义矛？
當(dāng)主庫的TPS并發(fā)較高時发笔，產(chǎn)生的DDL數(shù)量超過slave一個sql線程所能承受的范圍，那么延時就產(chǎn)生了凉翻，當(dāng)然還有就是可能與slave的大型query語句產(chǎn)生了鎖等待了讨。
首要原因：數(shù)據(jù)庫在業(yè)務(wù)上讀寫壓力太大，CPU計算負(fù)荷大，網(wǎng)卡負(fù)荷大前计，硬盤隨機IO太高
次要原因：讀寫binlog帶來的性能影響胞谭，網(wǎng)絡(luò)傳輸延遲。
c男杈、 MySQL數(shù)據(jù)庫主從同步延遲解決方案丈屹。
架構(gòu)方面
1.業(yè)務(wù)的持久化層的實現(xiàn)采用分庫架構(gòu)，mysql服務(wù)可平行擴展伶棒，分散壓力旺垒。
2.單個庫讀寫分離，一主多從肤无，主寫從讀先蒋，分散壓力。這樣從庫壓力比主庫高宛渐，保護(hù)主庫鞭达。
3.服務(wù)的基礎(chǔ)架構(gòu)在業(yè)務(wù)和mysql之間加入memcache或者redis的cache層。降低mysql的讀壓力皇忿。
4.不同業(yè)務(wù)的mysql物理上放在不同機器，分散壓力坦仍。
5.使用比主庫更好的硬件設(shè)備作為slave
總結(jié)鳍烁，mysql壓力小，延遲自然會變小繁扎。
硬件方面
1.采用好服務(wù)器幔荒，比如4u比2u性能明顯好，2u比1u性能明顯好梳玫。
2.存儲用ssd或者盤陣或者san爹梁，提升隨機寫的性能。
3.主從間保證處在同一個交換機下面提澎，并且是萬兆環(huán)境姚垃。
總結(jié)，硬件強勁盼忌，延遲自然會變小积糯。一句話，縮小延遲的解決方案就是花錢和花時間谦纱。
mysql主從同步加速
1看成、sync_binlog在slave端設(shè)置為0
2、–logs-slave-updates 從服務(wù)器從主服務(wù)器接收到的更新不記入它的二進(jìn)制日志跨嘉。
3川慌、直接禁用slave端的binlog
4、slave端，如果使用的存儲引擎是innodb梦重，innodb_flush_log_at_trx_commit =2
從文件系統(tǒng)本身屬性角度優(yōu)化
master端
修改linux兑燥、Unix文件系統(tǒng)中文件的etime屬性， 由于每當(dāng)讀文件時OS都會將讀取操作發(fā)生的時間回寫到磁盤上忍饰，對于讀操作頻繁的數(shù)據(jù)庫文件來說這是沒必要的贪嫂，只會增加磁盤系統(tǒng)的負(fù)擔(dān)影響I/O性能“叮可以通過設(shè)置文件系統(tǒng)的mount屬性力崇，組織操作系統(tǒng)寫atime信息，在linux上的操作為：
打開/etc/fstab赢织，加上noatime參數(shù)
/dev/sdb1 /data reiserfs noatime 1 2
然后重新mount文件系統(tǒng)
#mount -oremount /data
PS：
主庫是寫亮靴，對數(shù)據(jù)安全性較高，比如sync_binlog=1于置，innodb_flush_log_at_trx_commit = 1 之類的設(shè)置是需要的
而slave則不需要這么高的數(shù)據(jù)安全茧吊，完全可以講sync_binlog設(shè)置為0或者關(guān)閉binlog，innodb_flushlog也可以設(shè)置為0來提高sql的執(zhí)行效率
1八毯、sync_binlog=1 o
MySQL提供一個sync_binlog參數(shù)來控制數(shù)據(jù)庫的binlog刷到磁盤上去搓侄。
默認(rèn)，sync_binlog=0话速，表示MySQL不控制binlog的刷新讶踪，由文件系統(tǒng)自己控制它的緩存的刷新。這時候的性能是最好的泊交，但是風(fēng)險也是最大的乳讥。一旦系統(tǒng)Crash，在binlog_cache中的所有binlog信息都會被丟失廓俭。
如果sync_binlog>0云石，表示每sync_binlog次事務(wù)提交，MySQL調(diào)用文件系統(tǒng)的刷新操作將緩存刷下去研乒。最安全的就是sync_binlog=1了汹忠，表示每次事務(wù)提交，MySQL都會把binlog刷下去雹熬，是最安全但是性能損耗最大的設(shè)置错维。這樣的話，在數(shù)據(jù)庫所在的主機操作系統(tǒng)損壞或者突然掉電的情況下橄唬，系統(tǒng)才有可能丟失1個事務(wù)的數(shù)據(jù)赋焕。
但是binlog雖然是順序IO，但是設(shè)置sync_binlog=1仰楚，多個事務(wù)同時提交隆判，同樣很大的影響MySQL和IO性能犬庇。
雖然可以通過group commit的補丁緩解，但是刷新的頻率過高對IO的影響也非常大侨嘀。對于高并發(fā)事務(wù)的系統(tǒng)來說臭挽，
“sync_binlog”設(shè)置為0和設(shè)置為1的系統(tǒng)寫入性能差距可能高達(dá)5倍甚至更多。
所以很多MySQL DBA設(shè)置的sync_binlog并不是最安全的1咬腕，而是2或者是0欢峰。這樣犧牲一定的一致性，可以獲得更高的并發(fā)和性能涨共。
默認(rèn)情況下纽帖，并不是每次寫入時都將binlog與硬盤同步。因此如果操作系統(tǒng)或機器(不僅僅是MySQL服務(wù)器)崩潰举反，有可能binlog中最后的語句丟失了懊直。要想防止這種情況，你可以使用sync_binlog全局變量(1是最安全的值火鼻，但也是最慢的)室囊，使binlog在每N次binlog寫入后與硬盤同步。即使sync_binlog設(shè)置為1,出現(xiàn)崩潰時魁索，也有可能表內(nèi)容和binlog內(nèi)容之間存在不一致性融撞。
2、innodb_flush_log_at_trx_commit （這個很管用）
抱怨Innodb比MyISAM慢 100倍粗蔚？那么你大概是忘了調(diào)整這個值尝偎。默認(rèn)值1的意思是每一次事務(wù)提交或事務(wù)外的指令都需要把日志寫入（flush）硬盤，這是很費時的支鸡。特別是使用電池供電緩存（Battery backed up cache）時。設(shè)成2對于很多運用趁窃，特別是從MyISAM表轉(zhuǎn)過來的是可以的牧挣，它的意思是不寫入硬盤而是寫入系統(tǒng)緩存。
日志仍然會每秒flush到硬盤醒陆，所以你一般不會丟失超過1-2秒的更新瀑构。設(shè)成0會更快一點，但安全方面比較差刨摩，即使MySQL掛了也可能會丟失事務(wù)的數(shù)據(jù)寺晌。而值2只會在整個操作系統(tǒng)掛了時才可能丟數(shù)據(jù)。
3澡刹、ls(1) 命令可用來列出文件的 atime呻征、ctime 和 mtime。
atime 文件的access time 在讀取文件或者執(zhí)行文件時更改的
ctime 文件的create time 在寫入文件罢浇，更改所有者陆赋，權(quán)限或鏈接設(shè)置時隨inode的內(nèi)容更改而更改
mtime 文件的modified time 在寫入文件時隨文件內(nèi)容的更改而更改
ls -lc filename 列出文件的 ctime
ls -lu filename 列出文件的 atime
ls -l filename 列出文件的 mtime
stat filename 列出atime沐祷，mtime，ctime
atime不一定在訪問文件之后被修改
因為：使用ext3文件系統(tǒng)的時候攒岛，如果在mount的時候使用了noatime參數(shù)那么就不會更新atime信息赖临。
這三個time stamp都放在 inode 中.如果mtime,atime 修改,inode 就一定會改, 既然 inode 改了,那ctime也就跟著改了.
之所以在 mount option 中使用 noatime, 就是不想file system 做太多的修改, 而改善讀取效能
