MySQL中怎樣實(shí)現(xiàn)主從同步

這篇文章將為大家詳細(xì)講解有關(guān)MySQL中怎樣實(shí)現(xiàn)主從同步，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

宣化ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書(shū)未來(lái)市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)的ssl證書(shū)銷(xiāo)售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話(huà)聯(lián)系或者加微信：18982081108（備注：SSL證書(shū)合作）期待與您的合作！

(1) statement ： 記錄每一條更改數(shù)據(jù)的sql;

• 優(yōu)點(diǎn)：binlog文件較小，節(jié)約I/O，性能較高。

• 缺點(diǎn)：不是所有的數(shù)據(jù)更改都會(huì)寫(xiě)入binlog文件中，尤其是使用MySQL中的一些特殊函數(shù)(如LOAD_FILE()、UUID()等)和一些不確定的語(yǔ)句操作，從而導(dǎo)致主從數(shù)據(jù)無(wú)法復(fù)制的問(wèn)題。

(2) row ： 不記錄sql，只記錄每行數(shù)據(jù)的更改細(xì)節(jié)

• 優(yōu)點(diǎn)：詳細(xì)的記錄了每一行數(shù)據(jù)的更改細(xì)節(jié)，這也意味著不會(huì)由于使用一些特殊函數(shù)或其他情況導(dǎo)致不能復(fù)制的問(wèn)題。

• 缺點(diǎn)：由于row格式記錄了每一行數(shù)據(jù)的更改細(xì)節(jié)，會(huì)產(chǎn)生大量的binlog日志內(nèi)容，性能不佳，并且會(huì)增大主從同步延遲出現(xiàn)的幾率。

(3)  mixed：一般的語(yǔ)句修改使用statment格式保存binlog，如一些函數(shù)，statement無(wú)法完成主從復(fù)制的操作，則采用row格式保存binlog，MySQL會(huì)根據(jù)執(zhí)行的每一條具體的sql語(yǔ)句來(lái)區(qū)分對(duì)待記錄的日志形式，也就是在Statement和Row之間選擇一種。

(二)binlog日志內(nèi)容

mysqlbinlog命令查看的內(nèi)容如下：

根據(jù)事件類(lèi)型查看的binlog內(nèi)容：

(三)binlog事件類(lèi)型

MySQL  binlog記錄的所有操作實(shí)際上都有對(duì)應(yīng)的事件類(lèi)型的，譬如STATEMENT格式中的DML操作對(duì)應(yīng)的是QUERY_EVENT類(lèi)型，ROW格式下的DML操作對(duì)應(yīng)的是ROWS_EVENT類(lèi)型，如果想了解更多請(qǐng)參考官方文檔，有關(guān)binlog日志內(nèi)容不在這里過(guò)多贅述，簡(jiǎn)單介紹一下是為了更好的理解主從復(fù)制的細(xì)節(jié)，下面我們進(jìn)入正題。

四、MySQL主從復(fù)制原理

mysql主從復(fù)制需要三個(gè)線程，master(binlog dump thread)、slave(I/O thread 、SQL thread)。

master

(1)binlog  dump線程：當(dāng)主庫(kù)中有數(shù)據(jù)更新時(shí)，那么主庫(kù)就會(huì)根據(jù)按照設(shè)置的binlog格式，將此次更新的事件類(lèi)型寫(xiě)入到主庫(kù)的binlog文件中，此時(shí)主庫(kù)會(huì)創(chuàng)建log  dump線程通知slave有數(shù)據(jù)更新，當(dāng)I/O線程請(qǐng)求日志內(nèi)容時(shí)，會(huì)將此時(shí)的binlog名稱(chēng)和當(dāng)前更新的位置同時(shí)傳給slave的I/O線程。

slave

(2)I/O線程：該線程會(huì)連接到master，向log dump線程請(qǐng)求一份指定binlog文件位置的副本，并將請(qǐng)求回來(lái)的binlog存到本地的relay  log中，relay log和binlog日志一樣也是記錄了數(shù)據(jù)更新的事件，它也是按照遞增后綴名的方式，產(chǎn)生多個(gè)relay log(  host_name-relay-bin.000001)文件，slave會(huì)使用一個(gè)index文件(  host_name-relay-bin.index)來(lái)追蹤當(dāng)前正在使用的relay log文件。

(3)SQL線程：該線程檢測(cè)到relay  log有更新后，會(huì)讀取并在本地做redo操作，將發(fā)生在主庫(kù)的事件在本地重新執(zhí)行一遍，來(lái)保證主從數(shù)據(jù)同步。此外，如果一個(gè)relay  log文件中的全部事件都執(zhí)行完畢，那么SQL線程會(huì)自動(dòng)將該relay log 文件刪除掉。

下面是整個(gè)復(fù)制過(guò)程的原理圖：

四、主從同步延遲

mysql的主從復(fù)制都是單線程的操作，主庫(kù)對(duì)所有DDL和DML產(chǎn)生binlog，binlog是順序?qū)?，所以效率很高，slave的I/O線程到主庫(kù)取日志，效率也比較高，但是，slave的SQL線程將主庫(kù)的DDL和DML操作在slave實(shí)施。DML和DDL的IO操作是隨即的，不是順序的，成本高很多，還可能存在slave上的其他查詢(xún)產(chǎn)生lock爭(zhēng)用的情況，由于SQL也是單線程的，所以一個(gè)DDL卡住了，需要執(zhí)行很長(zhǎng)一段事件，后續(xù)的DDL線程會(huì)等待這個(gè)DDL執(zhí)行完畢之后才執(zhí)行，這就導(dǎo)致了延時(shí)。當(dāng)主庫(kù)的TPS并發(fā)較高時(shí)，產(chǎn)生的DDL數(shù)量超過(guò)slave一個(gè)sql線程所能承受的范圍，延時(shí)就產(chǎn)生了，除此之外，還有可能與slave的大型query語(yǔ)句產(chǎn)生了鎖等待導(dǎo)致。

由于主從同步延遲是客觀存在的，我們只能從我們自己的架構(gòu)上進(jìn)行設(shè)計(jì)， 盡量讓主庫(kù)的DDL快速執(zhí)行。下面列出幾種常見(jiàn)的解決方案：

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

2. 服務(wù)的基礎(chǔ)架構(gòu)在業(yè)務(wù)和mysql之間加入memcache或者redis的cache層。降低mysql的讀壓力;

3. 使用比主庫(kù)更好的硬件設(shè)備作為slave;

4. sync_binlog在slave端設(shè)置為0;

5. –logs-slave-updates 從服務(wù)器從主服務(wù)器接收到的更新不記入它的二進(jìn)制日志。

6. 禁用slave的binlog

關(guān)于MySQL中怎樣實(shí)現(xiàn)主從同步就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

當(dāng)前名稱(chēng)：MySQL中怎樣實(shí)現(xiàn)主從同步
網(wǎng)址分享：http://bm7419.com/article48/goicep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、商城網(wǎng)站、微信小程序、網(wǎng)站內(nèi)鏈、ChatGPT、動(dòng)態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)