1. MySQL數(shù)據(jù)庫(kù)主從同步延遲原理？

創(chuàng)新互聯(lián)-專(zhuān)業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比鐵門(mén)關(guān)網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式鐵門(mén)關(guān)網(wǎng)站制作公司更省心,省錢(qián),快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋鐵門(mén)關(guān)地區(qū)。費(fèi)用合理售后完善，10余年實(shí)體公司更值得信賴(lài)。

2. MySQL數(shù)據(jù)庫(kù)主從同步延遲是怎么產(chǎn)生的？

3. MySQL數(shù)據(jù)庫(kù)主從同步延遲解決方案？

---------------------------------------------------------------------------------------------------

1. MySQL數(shù)據(jù)庫(kù)主從同步延遲原理

答：談到MySQL數(shù)據(jù)庫(kù)主從同步延遲原理，得從mysql的數(shù)據(jù)庫(kù)主從復(fù)制原理說(shuō)起，mysql的主從復(fù)制都是單線程的操作，主庫(kù)對(duì)所有DDL(數(shù)據(jù)庫(kù)定義語(yǔ)言)和DML(數(shù)據(jù)庫(kù)操作語(yǔ)言)產(chǎn)生binlog，binlog是順序?qū)懀孕屎芨?，slave的Slave_IO_Running線程到主庫(kù)取日志，效率很比較高，下一步，問(wèn)題來(lái)了，slave的Slave_SQL_Running線程將主庫(kù)的DDL和DML操作在slave實(shí)施。DML和DDL的IO操作是隨即的，不是順序的，成本高很多，還可能可slave上的其他查詢產(chǎn)生lock爭(zhēng)用，由于Slave_SQL_Running也是單線程的，所以一個(gè)DDL卡主了，需要執(zhí)行10分鐘，那么所有之后的DDL會(huì)等待這個(gè)DDL執(zhí)行完才會(huì)繼續(xù)執(zhí)行，這就導(dǎo)致了延時(shí)。有朋友會(huì)問(wèn)：“主庫(kù)上那個(gè)相同的DDL也需要執(zhí)行10分，為什么slave會(huì)延時(shí)？”，答案是master可以并發(fā)，Slave_SQL_Running線程卻不可以。

2. MySQL數(shù)據(jù)庫(kù)主從同步延遲是怎么產(chǎn)生的。

答：當(dāng)主庫(kù)的TPS并發(fā)較高時(shí)，產(chǎn)生的DDL數(shù)量超過(guò)slave一個(gè)sql線程所能承受的范圍，那么延時(shí)就產(chǎn)生了，當(dāng)然還有就是可能與slave的大型query語(yǔ)句產(chǎn)生了鎖等待。

3. MySQL數(shù)據(jù)庫(kù)主從同步延遲解決方案。

問(wèn)題一：主庫(kù)的從庫(kù)太多，導(dǎo)致復(fù)制延遲

從庫(kù)數(shù)據(jù)以3-5個(gè)為宜，要復(fù)制的從節(jié)點(diǎn)數(shù)量過(guò)多，會(huì)導(dǎo)致復(fù)制延遲

問(wèn)題二：從庫(kù)硬件比主庫(kù)差，導(dǎo)致復(fù)制延遲

查看Master和Slave的系統(tǒng)配置，可能會(huì)因?yàn)闄C(jī)器配置不當(dāng)，包括磁盤(pán)I/O、CPU、內(nèi)存等各方面因素造成復(fù)制的延遲。一般發(fā)生在高并發(fā)大數(shù)據(jù)量寫(xiě)入場(chǎng)景中

問(wèn)題三：慢SQL語(yǔ)句過(guò)多

假如一條SQL語(yǔ)句執(zhí)行時(shí)間是20秒，那么從執(zhí)行完畢到從庫(kù)上能查到數(shù)據(jù)至少需要20秒，這樣就延遲20秒了。

一般要把SQL語(yǔ)句的優(yōu)化作為常規(guī)工作不斷地進(jìn)行監(jiān)控和優(yōu)化，如果單個(gè)SQL的寫(xiě)入時(shí)間長(zhǎng)，可以修改后分多次寫(xiě)入。通過(guò)查看慢查詢?nèi)罩净騭how full processlist命令，找出執(zhí)行時(shí)間長(zhǎng)的查詢語(yǔ)句或大的事務(wù)

問(wèn)題四：主從復(fù)制的設(shè)計(jì)問(wèn)題

例如主從復(fù)制單線程，如果主庫(kù)寫(xiě)并發(fā)太大，來(lái)不及傳送到從庫(kù)，就會(huì)導(dǎo)致延遲。更高版本的Mysql可以支持多線程復(fù)制，門(mén)戶網(wǎng)站則會(huì)開(kāi)發(fā)自己的多線程同步功能。

問(wèn)題五：主從庫(kù)之間的網(wǎng)絡(luò)延遲

主從庫(kù)的網(wǎng)卡、網(wǎng)線、交換機(jī)等網(wǎng)絡(luò)設(shè)備都可能成為復(fù)制的瓶頸，導(dǎo)致復(fù)制延遲。另外，跨公網(wǎng)的主從復(fù)制很容易導(dǎo)致主從復(fù)制延遲

問(wèn)題六：主庫(kù)讀寫(xiě)壓力大，導(dǎo)致復(fù)制延遲

架構(gòu)的前端要加buffer及緩存層

門(mén)戶網(wǎng)站的解決方案：

優(yōu)酷的解決方案：數(shù)據(jù)庫(kù)分片技術(shù)，而拋棄了由于數(shù)據(jù)量的越來(lái)越多導(dǎo)致復(fù)制延遲的問(wèn)題。按照user_id進(jìn)行分片，這樣必須有一個(gè)全局的表來(lái)管理用戶與shard的關(guān)系,根據(jù)user_id可以得到share_id，然后根據(jù)share_id去指定的分片查詢指定的數(shù)據(jù)

淘寶的解決方案：修改源碼，對(duì)應(yīng)的機(jī)制是Transfer機(jī)制，此處通過(guò)對(duì)Binlog日志重做采用多線程實(shí)現(xiàn)，從而提高slave的QPS