MySQL的主從如何配置
瀏覽量: 次 發(fā)布日期:2023-09-11 09:47:50
MySQL的主從如何配置
大家好,我是撿田螺的小男孩。金三銀四面試的時候,面試官經(jīng)常會問MySQL主從。今天就跟大家聊聊MySQL的主從。數(shù)據(jù)庫主從概念、優(yōu)點、用途數(shù)據(jù)庫主從復(fù)制原理主主、主從、主備的區(qū)別MySQL是怎么保證主從一致的數(shù)據(jù)庫主從延遲的原因與解決方案聊聊數(shù)據(jù)庫的高可用方案
主從數(shù)據(jù)庫是什么意思呢,主是主庫的意思,從是從庫的意思。數(shù)據(jù)庫主庫對外提供讀寫的操作,從庫對外提供讀的操作。
數(shù)據(jù)庫為什么需要主從架構(gòu)呢?高可用,實時災(zāi)備,用于故障切換。比如主庫掛了,可以切從庫。讀寫分離,提供查詢服務(wù),減少主庫壓力,提升性能備份數(shù)據(jù),避免影響業(yè)務(wù)。
主從復(fù)制原理,簡言之,分三步曲進行:主數(shù)據(jù)庫有個二進制文件,紀(jì)錄了所有增刪改語句。(binlog線程)從數(shù)據(jù)庫把主數(shù)據(jù)庫的文件的 語句復(fù)制到自己的中繼日志 (io線程)從數(shù)據(jù)庫的重做日志文件,再執(zhí)行一次這些sql語句。(Sql執(zhí)行線程)
詳細(xì)的主從復(fù)制過程如圖:
上圖主從復(fù)制過程分了五個步驟進行:主庫的更新SQL(update、insert、delete)被寫到binlog從庫發(fā)起連接,連接到主庫。此時主庫創(chuàng)建一個,把的內(nèi)容發(fā)送到從庫。從庫啟動之后,創(chuàng)建一個線程,讀取主庫傳過來的內(nèi)容并寫入到從庫還會創(chuàng)建一個SQL線程,從里面讀取內(nèi)容,從位置開始執(zhí)行讀取到的更新事件,將更新內(nèi)容寫入到的db
數(shù)據(jù)庫主主:兩臺都是主數(shù)據(jù)庫,同時對外提供讀寫操作。客戶端訪問任意一臺。數(shù)據(jù)存在雙向同步。
數(shù)據(jù)庫主從:一臺是主數(shù)據(jù)庫,同時對外提供讀寫操作。一臺是從數(shù)據(jù)庫,對外提供讀的操作。數(shù)據(jù)從主庫同步到從庫。
數(shù)據(jù)庫主備:一臺是主數(shù)據(jù)庫,同時對外提供讀寫操作。一臺是備庫,只作為備份作用,不對外提供讀寫,主機掛了它就取而代之。數(shù)據(jù)從主庫同步到備庫。
從庫和備庫,就是slave庫功能不同因此叫法才不一樣而已。一般slave庫都會對外提供讀的功能的,因此,大家日常聽得比較多就是主從。
我們學(xué)習(xí)數(shù)據(jù)庫的主從復(fù)制原理后,了解到從庫拿到并執(zhí)行主庫的binlog日志,就可以保持?jǐn)?shù)據(jù)與主庫一致了。這是為什么呢?哪些情況會導(dǎo)致不一致呢?
主庫和從庫在同步數(shù)據(jù)的過程中斷怎么辦呢,數(shù)據(jù)不就會丟失了嘛。因此主庫與從庫之間維持了一個長鏈接,主庫內(nèi)部有一個線程,專門服務(wù)于從庫的這個長鏈接的。
binlog 日志有三種格式,分別是。
如果是格式,binlog記錄的是SQL的原文,如果主庫和從庫選的索引不一致,可能會導(dǎo)致主庫不一致。我們來分析一下。假設(shè)主庫執(zhí)行刪除這個SQL(其中都有索引)如下:
我們知道,數(shù)據(jù)庫選擇了索引和選擇索引,最后出來的數(shù)據(jù)一般是不一樣的。所以就會存在這種情況:在binlog = 格式時,主庫在執(zhí)行這條SQL時,使用的是索引a,而從庫在執(zhí)行這條SQL時,使用了索引。最后主從數(shù)據(jù)不一致了。
如何解決這個問題呢?
可以把binlog格式修改為。格式的日志,記錄的不是SQL原文,而是兩個。Table_map event說明要操作的表,Delete_rows event用于定義要刪除的行為,記錄刪除的具體行數(shù)。格式的binlog記錄的就是要刪除的主鍵ID信息,因此不會出現(xiàn)主從不一致的問題。
但是如果SQL刪除10萬行數(shù)據(jù),使用row格式就會很占空間的,10萬條數(shù)據(jù)都在binlog里面,寫binlog的時候也很耗IO。但是格式的binlog可能會導(dǎo)致數(shù)據(jù)不一致,因此設(shè)計MySQL的大叔想了一個折中的方案,格式的binlog。所謂的mixed格式其實就是和格式混合使用,當(dāng)MySQL判斷可能數(shù)據(jù)不一致時,就用格式,否則使用就用格式。
主從延遲是怎么定義的呢?與主從數(shù)據(jù)同步相關(guān)的時間點有三個主庫執(zhí)行完一個事務(wù),寫入binlog,我們把這個時刻記為;主庫同步數(shù)據(jù)給從庫,從庫接收完這個binlog的時刻,記錄為;從庫執(zhí)行完這個事務(wù),這個時刻記錄為。
所謂主從延遲,其實就是指同一個事務(wù),在從庫執(zhí)行完的時間和在主庫執(zhí)行完的時間差值,即。
哪些情況會導(dǎo)致主從延遲呢?如果從庫所在的機器比主庫的機器性能差,會導(dǎo)致主從延遲,這種情況比較好解決,只需選擇主從庫一樣規(guī)格的機器就好。如果從庫的壓力大,也會導(dǎo)致主從延遲。比如主庫直接影響業(yè)務(wù)的,大家可能使用會比較克制,因此一般查詢都打到從庫了,結(jié)果導(dǎo)致從庫查詢消耗大量CPU,影響同步速度,最后導(dǎo)致主從延遲。這種情況的話,可以搞了一主多從的架構(gòu),即多接幾個從庫分?jǐn)傋x的壓力。另外,還可以把binlog接入到Hadoop這類系統(tǒng),讓它們提供查詢的能力。大事務(wù)也會導(dǎo)致主從延遲。如果一個事務(wù)執(zhí)行就要10分鐘,那么主庫執(zhí)行完后,給到從庫執(zhí)行,最后這個事務(wù)可能就會導(dǎo)致從庫延遲10分鐘啦。日常開發(fā)中,我們?yōu)槭裁刺貏e強調(diào),不要一次性delete太多SQL,需要分批進行,其實也是為了避免大事務(wù)。另外,大表的DDL語句,也會導(dǎo)致大事務(wù),大家日常開發(fā)關(guān)注一下哈。網(wǎng)絡(luò)延遲也會導(dǎo)致主從延遲,這種情況你只能優(yōu)化你的網(wǎng)絡(luò)啦,比如帶寬20M升級到100M類似意思等。如果從數(shù)據(jù)庫過多也會導(dǎo)致主從延遲,因此要避免復(fù)制的從節(jié)點數(shù)量過多。從庫數(shù)據(jù)一般以3-5個為宜。低版本的MySQL只支持單線程復(fù)制,如果主庫并發(fā)高,來不及傳送到從庫,就會導(dǎo)致延遲。可以換用更高版本的Mysql,可以支持多線程復(fù)制。雙機主備一主一從一主多從MariaDB同步多主機數(shù)據(jù)庫中間件架構(gòu)描述:兩臺機器A和B,A為主庫,負(fù)責(zé)讀寫,B為備庫,只備份數(shù)據(jù)。如果A庫發(fā)生故障,B庫成為主庫負(fù)責(zé)讀寫。修復(fù)故障后,A成為備庫,主庫B同步數(shù)據(jù)到備庫A優(yōu)點:一個機器故障了可以自動切換,操作比較簡單。缺點:只有一個庫在工作,讀寫壓力大,未能實現(xiàn)讀寫分離,并發(fā)也有一定限制架構(gòu)描述: 兩臺機器A和B,A為主庫,負(fù)責(zé)讀寫,B為從庫,負(fù)責(zé)讀數(shù)據(jù)。如果A庫發(fā)生故障,B庫成為主庫負(fù)責(zé)讀寫。修復(fù)故障后,A成為從庫,主庫B同步數(shù)據(jù)到從庫A。優(yōu)點:從庫支持讀,分擔(dān)了主庫的壓力,提升了并發(fā)度。一個機器故障了可以自動切換,操作比較簡單。缺點:一臺從庫,并發(fā)支持還是不夠,并且一共兩臺機器,還是存在同時故障的機率,不夠高可用。架構(gòu)描述: 一臺主庫多臺從庫,A為主庫,負(fù)責(zé)讀寫,B、C、D為從庫,負(fù)責(zé)讀數(shù)據(jù)。如果A庫發(fā)生故障,B庫成為主庫負(fù)責(zé)讀寫,C、D負(fù)責(zé)讀。修復(fù)故障后,A也成為從庫,主庫B同步數(shù)據(jù)到從庫A。優(yōu)點:多個從庫支持讀,分擔(dān)了主庫的壓力,明顯提升了讀的并發(fā)度。缺點:只有臺主機寫,因此寫的并發(fā)度不高架構(gòu)描述:有代理層實現(xiàn)負(fù)載均衡,多個數(shù)據(jù)庫可以同時進行讀寫操作;各個數(shù)據(jù)庫之間可以通過方法進行數(shù)據(jù)同步,每個庫理論上數(shù)據(jù)是完全一致的。優(yōu)點:讀寫的并發(fā)度都明顯提升,可以任意節(jié)點讀寫,可以自動剔除故障節(jié)點,具有較高的可靠性。缺點:數(shù)據(jù)量不支持特別大。要避免大事務(wù)卡死,如果集群節(jié)點一個變慢,其他節(jié)點也會跟著變慢。架構(gòu)描述:mycat分片存儲,每個分片配置一主多從的集群。優(yōu)點:解決高并發(fā)高數(shù)據(jù)量的高可用方案缺點:維護成本比較大。極客時間《MySQL45講》數(shù)據(jù)庫高可用方案[1][1]
數(shù)據(jù)庫高可用方案: https://www.cnblogs.com/devinzhang/p/7001424.html熱門內(nèi)容:
新來了個技術(shù)總監(jiān):誰再用 @Async 創(chuàng)建線程以后就不用來了!!
最新 955 不加班的公司名單(2022版)
我媽今年 70 歲,受不了Windows藍(lán)屏,用了 21 年的 Linux!YYDS!京東一面:Spring 為何需要三級緩存解決循環(huán)依賴,而不是二級緩存?我懵了。。牛啊,又一份牛逼筆記面世了
最近面試BAT,整理一份面試資料《Java面試BAT通關(guān)手冊》,覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。獲取方式:點“在看”,關(guān)注公眾號并回復(fù) 666 領(lǐng)取,更多內(nèi)容陸續(xù)奉上。明天見(??ω??)??
. 六安移動硬盤數(shù)據(jù)恢復(fù),專業(yè)技術(shù),守護您的數(shù)據(jù)安全
. deep sequence,揭秘高效內(nèi)容生成的秘密武器
. 深圳數(shù)據(jù)恢復(fù)公司排名,揭秘排名前三的數(shù)據(jù)恢復(fù)公司”
. 怎樣恢復(fù)刪除的硬盤數(shù)據(jù),詳解硬盤刪除數(shù)據(jù)恢復(fù)全攻略
. 硬盤數(shù)據(jù)恢復(fù)圖書,從原理到實踐的技術(shù)解析
. 數(shù)據(jù) 恢復(fù),揭秘數(shù)據(jù)丟失背后的原因與高效解決方案
. 沈河區(qū)硬盤數(shù)據(jù)恢復(fù)中心,專業(yè)服務(wù),守護您的數(shù)據(jù)安全”
. 硬盤數(shù)據(jù)恢復(fù)從哪學(xué),從原理到實踐的技術(shù)解析
. emc存儲怎么用,高效數(shù)據(jù)管理的核心策略
. 全免費的數(shù)據(jù)恢復(fù)工具,助您輕松找回丟失文件
. 病毒 移動硬盤數(shù)據(jù)恢復(fù),病毒侵襲下的移動硬盤數(shù)據(jù)恢復(fù)攻略
. 移動硬盤數(shù)據(jù)恢復(fù)正常,從誤刪到恢復(fù)的全方位指導(dǎo)
. 硬盤內(nèi)部儲存器,存儲技術(shù)的核心與未來趨勢
. 硬盤數(shù)據(jù)恢復(fù)流程圖片,從診斷到恢復(fù)的全方位指南
. deepzengo,Deepzengo的突破與創(chuàng)新
. 惠普系統(tǒng)恢復(fù)工具,一鍵還原,輕松守護您的電腦健康
. deepke源碼,揭秘知識圖譜嵌入技術(shù)的核心原理與實踐