MySQL主從原理

系統(tǒng)優(yōu)化：假如現(xiàn)在用戶反映系統(tǒng)太卡

海港網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)建站從2013年成立到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。

1：如果是請(qǐng)求太多，判斷web服務(wù)器壓力過大，增加前端的web服務(wù)器，做負(fù)載均衡

2：如果請(qǐng)求靜態(tài)頁(yè)面不卡了，但是請(qǐng)求動(dòng)態(tài)數(shù)據(jù)還是卡，說(shuō)明MySQL處理的請(qǐng)求太多了，在應(yīng)用層增加緩存

3：如果請(qǐng)求激增，還是有大量的查詢到MySQL,想辦法處理MySQL ,在一個(gè)應(yīng)用中，大量的消耗MySQL的還是查詢，就可以把MySQL拆開，就像公路分道 公交車道，小轎車道，把MySQL做成主從

1,就算MYSQL拆成了多個(gè),也必須分出主和從,所有的寫操作都必須要在主MYSQL 上完成;

2,所有的從MYSQL的數(shù)據(jù)都來(lái)自于(同步于)主MYSQL;

3,既然涉及到同步,那一定有延遲;有延遲,就一定可能在讀的時(shí)候產(chǎn)生臟數(shù)據(jù);所以,能夠在從MYSQL上進(jìn)行的讀操作,一定對(duì)實(shí)時(shí)性和臟數(shù)據(jù)有一定容忍度的數(shù)據(jù);比如,登陸日志,后臺(tái)報(bào)表,首頁(yè)統(tǒng)計(jì)信息來(lái)源;文章;資訊;SNS消息;

4,[注意]:在MYSQL主從時(shí),如果一個(gè)業(yè)務(wù)(service中的一個(gè)方法)中,如果既有R操作,又有W操作,因?yàn)閃操作一定要在主MYSQL上,所以在一個(gè)事務(wù)中所有的數(shù)據(jù)來(lái)源都只能來(lái)自于一個(gè)MYSQL

1,要完成主從同步,就必須讓在Master上執(zhí)行的所有的DML和DDL能夠正確的在Salve上再執(zhí)行一遍;MYSQL選擇使用文件來(lái)記錄SQL;

2,要完成主從同步,第一個(gè)事情就是把在主服務(wù)器上的bin-log(二進(jìn)制文件)打開,bin-log文件就可以記錄在MYSQL上執(zhí)行的所有的DML+DDL+TCL;

3,MYSQL使用被動(dòng)注冊(cè)的方式來(lái)讓從MYSQL請(qǐng)求同步主MYSQL的binlog;原因:被動(dòng)請(qǐng)求的方式,主的MYSQL不需要知道有哪些從的MYSQL,我額外添加/去掉從MYSQL服務(wù)器,對(duì)主MYSQL服務(wù)器的正常運(yùn)行沒有任何影響;

4,第二步,從MYSQL后臺(tái)一個(gè)線程發(fā)送一個(gè)請(qǐng)求,到主服務(wù)器請(qǐng)求更新數(shù)據(jù);最重要的數(shù)據(jù)(我這次請(qǐng)求,請(qǐng)求你bin-log的哪一行數(shù)據(jù)之后的數(shù)據(jù))

5,第三步,主MYSQL后臺(tái)一個(gè)線程接收到從MYSQL發(fā)送的請(qǐng)求,然后讀取bin-log文件中指定的內(nèi)容,并放在從MYSQL的請(qǐng)求響應(yīng)中;

6,第四步,從MYSQL的請(qǐng)求帶回同步的數(shù)據(jù),然后寫在從MYSQL中的relay-log(重做日志)中;relay-log中記錄的就是從主MYSQL中請(qǐng)求回來(lái)的哪些SQL數(shù)據(jù);

7,第五步,從MYSQL后臺(tái)一個(gè)線程專門用于從relay-log中讀取同步回來(lái)的SQL,并寫入到從MYSQL中,完成同步;

8,MYSQL的主從同步是經(jīng)過高度優(yōu)化的,性能非常高;

mysql主從配置

主從同步原理圖

mysql復(fù)制的模式

具體配置

master_log_file是第四步中File的值

master_log_pos是第四步中Postion的值

Slave_IO_Running等于yes代表已經(jīng)連接到主庫(kù)

Slave_SQL_Running等于yes 可執(zhí)行主庫(kù)binlog

這四個(gè)記錄了 IO或者SQL連接或者執(zhí)行出現(xiàn)的錯(cuò)誤

MySQL 主從，5 分鐘帶你掌握

MySQL 主從一直是面試?？?，里面的知識(shí)點(diǎn)雖然基礎(chǔ)，但是能回答全的同學(xué)不多。

比如樓哥之前面試小米，就被問到過主從復(fù)制的原理，以及主從延遲的解決方案，因?yàn)榛卮鸬姆浅２诲e(cuò)，給面試官留下非常好的印象。你之前面試，有遇到過哪些 MySQL 主從的問題呢？

所謂 MySQL 主從，就是建立兩個(gè)完全一樣的數(shù)據(jù)庫(kù)，一個(gè)是主庫(kù)，一個(gè)是從庫(kù)， 主庫(kù)對(duì)外提供讀寫的操作，從庫(kù)對(duì)外提供讀的操作 ，下面是一主一從模式：

對(duì)于數(shù)據(jù)庫(kù)單機(jī)部署，在 4 核 8G 的機(jī)器上運(yùn)行 MySQL 5.7 時(shí)，大概可以支撐 500 的 TPS 和 10000 的 QPS， 當(dāng)遇到一些活動(dòng)時(shí)，查詢流量驟然，就需要進(jìn)行主從分離。

大部分系統(tǒng)的訪問模型是讀多寫少，讀寫請(qǐng)求量的差距可能達(dá)到幾個(gè)數(shù)量級(jí)，所以我們可以通過一主多從的方式， 主庫(kù)只負(fù)責(zé)寫入和部分核心邏輯的查詢，多個(gè)從庫(kù)只負(fù)責(zé)查詢，提升查詢性能，降低主庫(kù)壓力。

MySQL 主從還能做到服務(wù)高可用，當(dāng)主庫(kù)宕機(jī)時(shí)，從庫(kù)可以切成主庫(kù)，保證服務(wù)的高可用，然后主庫(kù)也可以做數(shù)據(jù)的容災(zāi)備份。

整體場(chǎng)景總結(jié)如下：

MySQL 的主從復(fù)制是依賴于 binlog 的，也就是記錄 MySQL 上的所有變化并以二進(jìn)制形式保存在磁盤上二進(jìn)制日志文件。

主從復(fù)制就是將 binlog 中的數(shù)據(jù)從主庫(kù)傳輸?shù)綇膸?kù)上，一般這個(gè)過程是異步的，即主庫(kù)上的操作不會(huì)等待 binlog 同步的完成。

詳細(xì)流程如下：

當(dāng)主庫(kù)和從庫(kù)數(shù)據(jù)同步時(shí)，突然中斷怎么辦？因?yàn)橹鲙?kù)與從庫(kù)之間維持了一個(gè)長(zhǎng)鏈接，主庫(kù)內(nèi)部有一個(gè)線程，專門服務(wù)于從庫(kù)的這個(gè)長(zhǎng)鏈接的。

對(duì)于下面的情況，假如主庫(kù)執(zhí)行如下 SQL，其中 a 和 create_time 都是索引：

我們知道，數(shù)據(jù)選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來(lái)的數(shù)據(jù)一般是不一樣的。

所以就會(huì)存在這種情況：在 binlog = statement 格式時(shí)，主庫(kù)在執(zhí)行這條 SQL 時(shí)，使用的是索引 a，而從庫(kù)在執(zhí)行這條 SQL 時(shí)，使用了索引 create_time，最后主從數(shù)據(jù)不一致了。

那么我們改如何解決呢？

可以把 binlog 格式修改為 row，row 格式的 binlog 日志記錄的不是 SQL 原文，而是兩個(gè) event:Table_map 和 Delete_rows。

Table_map event 說(shuō)明要操作的表，Delete_rows event用于定義要?jiǎng)h除的行為，記錄刪除的具體行數(shù)。 row 格式的 binlog 記錄的就是要?jiǎng)h除的主鍵 ID 信息，因此不會(huì)出現(xiàn)主從不一致的問題。

但是如果 SQL 刪除 10 萬(wàn)行數(shù)據(jù)，使用 row 格式就會(huì)很占空間的，10 萬(wàn)條數(shù)據(jù)都在 binlog 里面，寫 binlog 的時(shí)候也很耗 IO。但是 statement 格式的 binlog 可能會(huì)導(dǎo)致數(shù)據(jù)不一致。

設(shè)計(jì) MySQL 的大叔想了一個(gè)折中的方案，mixed 格式的 binlog，其實(shí)就是 row 和 statement 格式混合使用， 當(dāng) MySQL 判斷可能數(shù)據(jù)不一致時(shí)，就用 row 格式，否則使用就用 statement 格式。

有時(shí)候我們遇到從數(shù)據(jù)庫(kù)中獲取不到信息的詭異問題時(shí)，會(huì)糾結(jié)于代碼中是否有一些邏輯會(huì)把之前寫入的內(nèi)容刪除，但是你又會(huì)發(fā)現(xiàn)，過了一段時(shí)間再去查詢時(shí)又可以讀到數(shù)據(jù)了，這基本上就是主從延遲在作怪。

主從延遲，其實(shí)就是“從庫(kù)回放” 完成的時(shí)間，與 “主庫(kù)寫 binlog” 完成時(shí)間的差值， 會(huì)導(dǎo)致從庫(kù)查詢的數(shù)據(jù)，和主庫(kù)的不一致 。

談到 MySQL 數(shù)據(jù)庫(kù)主從同步延遲原理，得從 MySQL 的主從復(fù)制原理說(shuō)起：

總結(jié)一下主從延遲的主要原因 ：主從延遲主要是出現(xiàn)在 “relay log 回放” 這一步，當(dāng)主庫(kù)的 TPS 并發(fā)較高，產(chǎn)生的 DDL 數(shù)量超過從庫(kù)一個(gè) SQL 線程所能承受的范圍，那么延時(shí)就產(chǎn)生了，當(dāng)然還有就是可能與從庫(kù)的大型 query 語(yǔ)句產(chǎn)生了鎖等待。

我們一般會(huì)把從庫(kù)落后的時(shí)間作為一個(gè)重點(diǎn)的數(shù)據(jù)庫(kù)指標(biāo)做監(jiān)控和報(bào)警，正常的時(shí)間是在毫秒級(jí)別，一旦落后的時(shí)間達(dá)到了秒級(jí)別就需要告警了。

解決該問題的方法，除了縮短主從延遲的時(shí)間，還有一些其它的方法，基本原理都是盡量不查詢從庫(kù)。

具體解決方案如下：

在實(shí)際應(yīng)用場(chǎng)景中，對(duì)于一些非常核心的場(chǎng)景，比如庫(kù)存，支付訂單等，需要直接查詢從庫(kù)，其它非核心場(chǎng)景，就不要去查主庫(kù)了。

兩臺(tái)機(jī)器 A 和 B，A 為主庫(kù)，負(fù)責(zé)讀寫，B 為從庫(kù)，負(fù)責(zé)讀數(shù)據(jù)。

如果 A 庫(kù)發(fā)生故障，B 庫(kù)成為主庫(kù)負(fù)責(zé)讀寫，修復(fù)故障后，A 成為從庫(kù)，主庫(kù) B 同步數(shù)據(jù)到從庫(kù) A。

一臺(tái)主庫(kù)多臺(tái)從庫(kù)，A 為主庫(kù)，負(fù)責(zé)讀寫，B、C、D為從庫(kù)，負(fù)責(zé)讀數(shù)據(jù)。

如果 A 庫(kù)發(fā)生故障，B 庫(kù)成為主庫(kù)負(fù)責(zé)讀寫，C、D負(fù)責(zé)讀，修復(fù)故障后，A 也成為從庫(kù)，主庫(kù) B 同步數(shù)據(jù)到從庫(kù) A。

當(dāng)前題目：mysql主從模式怎么做 mysql設(shè)置主從
URL鏈接：http://m.rwnh.cn/article46/doopoeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)、營(yíng)銷型網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、服務(wù)器托管、域名注冊(cè)、網(wǎng)站營(yíng)銷

廣告

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