欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

關(guān)于MySQL主從復(fù)制的幾種復(fù)制方式總結(jié)

 更新時(shí)間:2020年08月16日 16:08:44   作者:itbsl  
這篇文章主要給大家介紹了關(guān)于MySQL主從復(fù)制的幾種復(fù)制方式,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家學(xué)習(xí)或者使用MySQL具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧

異步復(fù)制

MySQL的復(fù)制默認(rèn)是異步的,主從復(fù)制至少需要兩個(gè)MYSQL服務(wù),這些MySQL服務(wù)可以分布在不同的服務(wù)器上,也可以在同一臺(tái)服務(wù)器上。

MySQL主從異步復(fù)制是最常見的復(fù)制場(chǎng)景。數(shù)據(jù)的完整性依賴于主庫BINLOG的不丟失,只要主庫的BINLOG不丟失,那么就算主庫宕機(jī)了,我們還可以通過BINLOG把丟失的部分?jǐn)?shù)據(jù)通過手工同步到從庫上去。

注意:主庫宕機(jī)的情況下,DBA可以通過mysqlbinlog工具手工訪問主庫binlog,抽取缺失的日志并同步到從庫上去;也可以通過配置高可用MHA架構(gòu)來自動(dòng)抽取缺失的數(shù)據(jù)補(bǔ)全從庫,或者啟用Global Transaction Identifiers(GTID)來自動(dòng)抽取缺失binlog到從庫。

MySQL在BINLOG中記錄事務(wù)(或SQL語句),也就是說對(duì)于支持事務(wù)的的引擎(例如InnoDB)來說,每個(gè)事務(wù)提交時(shí)都需要寫B(tài)INLOG;對(duì)于不支持事務(wù)的引擎(例如MyISAM)來說,每個(gè)SQL語句執(zhí)行完成時(shí),都需要些BINLOG。為了保證Binlog的安全,MySQL引入sync_binlog參數(shù)來控制BINLOG刷新到磁盤的頻率。

show variables like 'sync_binlog';

  • 在默認(rèn)情況下,sync_binlog=1,表示事務(wù)提交之前,MySQL都需要先把BINLOG刷新到磁盤,這樣的話,即使出現(xiàn)數(shù)據(jù)庫主機(jī)操作系統(tǒng)崩潰或者主機(jī)突然掉電的情況,系統(tǒng)最多損失prepared狀態(tài)的事務(wù);設(shè)置sync_binlog=1,盡可能保證數(shù)據(jù)安全。
  • sync_binlog=0,表示MySQL不控制binlog的刷新,由文件系統(tǒng)自己控制文件緩存的刷新。
  • sync_binlog=N,如果N不等于0或者1,刷新方式同sync_binlog=1類似,只不過此時(shí)會(huì)延長刷新頻率至N次binlog提交組之后。

以上是傳統(tǒng)的異步復(fù)制,在MySQL5.7的并行復(fù)制技術(shù)(也稱多線程復(fù)制)到來之前,為人詬病最多的還是效率問題,slave延遲是一個(gè)頑疾,雖然之前已經(jīng)出現(xiàn)了schema級(jí)別的并行復(fù)制,但實(shí)際效果并不好。

多線程復(fù)制

在MySQL5.7中,帶來了全新的多線程復(fù)制技術(shù),解決了當(dāng)master同一個(gè)schema下的數(shù)據(jù)發(fā)生了變更,從庫不能并發(fā)應(yīng)用的問題,同時(shí)也真正將binlog組提交的優(yōu)勢(shì)充分發(fā)揮出來,保障了從庫并發(fā)應(yīng)用Relay Log的能力。

在MySQL8.0中,多線程復(fù)制又進(jìn)行了技術(shù)更新,引入了writeset的概念,而在之前的版本中,如果主庫的同一個(gè)會(huì)話順序執(zhí)行多個(gè)不同相關(guān)對(duì)象的事務(wù),例如,先執(zhí)行了Update A表的數(shù)據(jù),又執(zhí)行了Update B表的數(shù)據(jù),那么BINLOG在復(fù)制到從庫后,這兩個(gè)事務(wù)是不能并行執(zhí)行的,writeset的到來,突破了這個(gè)限制。

增強(qiáng)半同步復(fù)制

前面介紹的復(fù)制是異步操作,主庫和從庫的數(shù)據(jù)之間難免會(huì)存在一定的延遲,這樣存在一個(gè)隱患:當(dāng)在主庫上寫入一個(gè)事務(wù)并提交成功,而從庫尚未得到主庫的BINLOG日志時(shí),主庫由于磁盤損壞、內(nèi)存故障、斷電等原因意外宕機(jī),導(dǎo)致主庫上該事務(wù)BINLOG丟失,此時(shí)從庫就會(huì)損失這個(gè)事務(wù),從而造成主從不一致。

為了解決這個(gè)問題,從MySQL5.5開始,引入了半同步復(fù)制,此時(shí)的技術(shù)暫且稱之為傳統(tǒng)的半同步復(fù)制,因該技術(shù)發(fā)展到MySQL5.7后,已經(jīng)演變?yōu)樵鰪?qiáng)半同步復(fù)制(也成為無損復(fù)制)。在異步復(fù)制時(shí),主庫執(zhí)行Commit提交操作并寫入BINLOG日志后即可成功返回客戶端,無需等待BINLOG日志傳送給從庫,如圖所示。

而半同步復(fù)制時(shí),為了保證主庫上的每一個(gè)BINLOG事務(wù)都能夠被可靠地復(fù)制到從庫上,主庫在每次事務(wù)成功提交時(shí),并不及時(shí)反饋給前端應(yīng)用用戶,而是等待至少一個(gè)從庫(詳見參數(shù)rpl_semi_sync_master_wait_for_slave_count)也接收到BINLOG事務(wù)并成功寫入中繼日志后,主庫才返回Commit操作成功給客戶端(不管是傳統(tǒng)的半同步復(fù)制,還是增強(qiáng)的半同步復(fù)制,目的都是一樣的,只不過兩種方式有一個(gè)席位地方不同,將在下面說明)

半同步復(fù)制保證了事務(wù)成功提交后,至少有兩份日志記錄,一份在主庫的BINLOG日志上,另一份在至少一個(gè)從庫的中繼日志Relay Log上,從而更進(jìn)一步保證了數(shù)據(jù)的完整性。

在傳統(tǒng)的半同步復(fù)制中,主庫寫數(shù)據(jù)到BINLOG,且執(zhí)行Commit操作后,會(huì)一直等待從庫的ACK,即從庫寫入Relay Log后,并將數(shù)據(jù)落盤,返回給主庫消息,通知主庫可以返回前端應(yīng)用操作成功,這樣會(huì)出現(xiàn)一個(gè)問題,就是實(shí)際上主庫已經(jīng)將該事務(wù)Commit到了事務(wù)引擎層,應(yīng)用已經(jīng)可以可以看到數(shù)據(jù)發(fā)生了變化,只是在等待返回而已,如果此時(shí)主庫宕機(jī),有可能從庫還沒能寫入Relay Log,就會(huì)發(fā)生主從庫不一致。增強(qiáng)半同步復(fù)制就是為了解決這個(gè)問題,做了微調(diào),即主庫寫數(shù)據(jù)到BINLOG后,就開始等待從庫的應(yīng)答ACK,直到至少一個(gè)從庫寫入Relay Log后,并將數(shù)據(jù)落盤,然后返回給主庫消息,通知主庫可以執(zhí)行Commit操作,然后主庫開始提交到事務(wù)引擎層,應(yīng)用此時(shí)可以看到數(shù)據(jù)發(fā)生了變化。增強(qiáng)半同步復(fù)制的大致流程如下圖所示。

半同步復(fù)制模式下,假如在傳送BINLOG日志到從庫時(shí),從庫宕機(jī)或者網(wǎng)絡(luò)延遲,導(dǎo)致BINLOG并沒有即使地傳送到從庫上,此時(shí)主庫上的事務(wù)會(huì)等待一段時(shí)間(時(shí)間長短由參數(shù)rpl_semi_sync_master_timeout設(shè)置的毫秒數(shù)決定),如果BINLOG在這段時(shí)間內(nèi)都無法成功發(fā)送到從庫上,則MySQL自動(dòng)調(diào)整復(fù)制為異步模式,事務(wù)正常返回提交結(jié)果給客戶端。

半同步復(fù)制很大程度上取決于主從庫之間的網(wǎng)絡(luò)情況,往返時(shí)延RTT越小決定了從庫的實(shí)時(shí)性越好。通俗地說,主從庫之間的網(wǎng)絡(luò)越快,從庫約實(shí)時(shí)。

注意:往返時(shí)延RTT(Round-Trip Time)在計(jì)算機(jī)網(wǎng)絡(luò)中是一個(gè)重要的性能指標(biāo),它表示從發(fā)送端發(fā)送數(shù)據(jù)開始到發(fā)送端接收到接收端的確認(rèn),總共經(jīng)歷的時(shí)長(這里可能有點(diǎn)拗口,我們可以理解為TCP三次握手的前兩次握手)。

總結(jié)

到此這篇關(guān)于關(guān)于MySQL主從復(fù)制的文章就介紹到這了,更多相關(guān)MySQL主從復(fù)制方式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • mysql主從基于docker和django實(shí)現(xiàn)讀寫分離

    mysql主從基于docker和django實(shí)現(xiàn)讀寫分離

    這篇文章主要介紹了mysql主從基于docker和django實(shí)現(xiàn)讀寫分離,文章圍繞主題展開詳細(xì)的內(nèi)容介紹,具有一定的參考價(jià)值,感興趣的小伙伴可以參考一下
    2022-08-08
  • SQL字符串以及數(shù)字常用操作匯總

    SQL字符串以及數(shù)字常用操作匯總

    本篇文章是對(duì)SQL字符串以及數(shù)字的常用操作進(jìn)行了詳細(xì)的總結(jié)與分析,需要的朋友參考下
    2013-06-06
  • 一文分析SQL?Server中事務(wù)使用的鎖

    一文分析SQL?Server中事務(wù)使用的鎖

    這篇文章主要介紹了一文分析SQL?Server中事務(wù)使用的鎖,數(shù)據(jù)庫引擎使用不同的鎖模式鎖定資源,通過不同鎖的組合使用達(dá)到不同的數(shù)據(jù)庫事務(wù)隔離級(jí)別,需要的朋友可以參考一下
    2022-09-09
  • mysql having用法解析

    mysql having用法解析

    having字句可以讓我們篩選成組后的各種數(shù)據(jù),where字句在聚合前先篩選記錄,也就是說作用在group by和having字句前,下面通過實(shí)例給大家介紹mysql having用法,一起看看吧
    2017-10-10
  • Mysql數(shù)據(jù)庫性能優(yōu)化一

    Mysql數(shù)據(jù)庫性能優(yōu)化一

    今天,數(shù)據(jù)庫的操作越來越成為整個(gè)應(yīng)用的性能瓶頸了,這點(diǎn)對(duì)于Web應(yīng)用尤其明顯。關(guān)于數(shù)據(jù)庫的性能,這并不只是DBA才需要擔(dān)心的事,而這更是我們程序員需要去關(guān)注的事情
    2016-04-04
  • MySQL中事務(wù)概念的簡潔學(xué)習(xí)教程

    MySQL中事務(wù)概念的簡潔學(xué)習(xí)教程

    這篇文章主要介紹了MySQL中的事務(wù)概念,是MySQL入門學(xué)習(xí)中的基礎(chǔ)知識(shí),需要的朋友可以參考下
    2015-11-11
  • Linux下mysql5.6.24(二進(jìn)制)自動(dòng)安裝腳本

    Linux下mysql5.6.24(二進(jìn)制)自動(dòng)安裝腳本

    這篇文章主要為大家詳細(xì)介紹了Linux環(huán)境下mysql5.6.24二進(jìn)制自動(dòng)安裝腳本,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下
    2018-03-03
  • mysql mycat 中間件安裝與使用

    mysql mycat 中間件安裝與使用

    MyCAT是MySQL中間件,前身是阿里大名鼎鼎的Cobar,Cobar在開源了一段時(shí)間后,不了了之。于是MyCAT扛起了這面大旗,在大數(shù)據(jù)時(shí)代,其重要性愈發(fā)彰顯。這篇文章主要是MyCAT的入門部署。
    2017-05-05
  • Prometheus 監(jiān)控MySQL使用grafana展示

    Prometheus 監(jiān)控MySQL使用grafana展示

    這篇文章主要介紹prometheus通過mysql exporter+node exporter監(jiān)控mysql,并使用grafana進(jìn)行圖表展示的相關(guān)內(nèi)容,感興趣的效果版可以參考下文
    2021-08-08
  • MySql官方手冊(cè)學(xué)習(xí)筆記1 MySql簡單上手

    MySql官方手冊(cè)學(xué)習(xí)筆記1 MySql簡單上手

    這是我學(xué)習(xí)MySql 5.1時(shí)做的一些整理與筆記,希望能理一理自己學(xué)到的東西,如果能有助于各位同道學(xué)習(xí)MySql那就更是意外之喜了,呵呵
    2012-10-10

最新評(píng)論