在從服務(wù)器上執(zhí)行show slave status;可以查看到很多同步的參數(shù)徘熔，我們需要特別注意的參數(shù)如下：

Master_Log_File：????????????????????? SLAVE中的I/O線程當(dāng)前正在讀取的主服務(wù)器二進制日志文件的名稱

Read_Master_Log_Pos：??????? 在當(dāng)前的主服務(wù)器二進制日志中鲫懒，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ù)器二進制日志文件的名稱

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計算負荷大滞造，網(wǎng)卡負荷大，硬盤隨機IO太高

次要原因：讀寫binlog帶來的性能影響楚里，網(wǎng)絡(luò)傳輸延遲断部。

c猎贴、 MySQL數(shù)據(jù)庫主從同步延遲解決方案班缎。

架構(gòu)方面

1.業(yè)務(wù)的持久化層的實現(xiàn)采用分庫架構(gòu)，mysql服務(wù)可平行擴展她渴，分散壓力达址。

2.單個庫讀寫分離，一主多從趁耗，主寫從讀沉唠，分散壓力。這樣從庫壓力比主庫高苛败，保護主庫满葛。

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ù)器接收到的更新不記入它的二進制日志嘉冒。

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)的負擔(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刷到磁盤上去剃诅。

默認巷送，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)寫入性能差距可能高達5倍甚至更多哥攘。

所以很多MySQL DBA設(shè)置的sync_binlog并不是最安全的1，而是2或者是0材鹦。這樣犧牲一定的一致性逝淹，可以獲得更高的并發(fā)和性能。

默認情況下侠姑，并不是每次寫入時都將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)整這個值妇智。默認值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 做太多的修改, 而改善讀取效能