MySQL主從復(fù)制的原理分析

本篇文章為大家展示了MySQL主從復(fù)制的原理分析，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

十余年專注成都網(wǎng)站制作，成都定制網(wǎng)站，個人網(wǎng)站制作服務(wù)，為大家分享網(wǎng)站制作知識、方案，網(wǎng)站設(shè)計流程、步驟,成功服務(wù)上千家企業(yè)。為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計及定制高端網(wǎng)站建設(shè)服務(wù),專注于成都定制網(wǎng)站,高端網(wǎng)頁制作,對成都發(fā)電機維修等多個方面，擁有豐富的營銷推廣經(jīng)驗。

主從復(fù)制是怎么實現(xiàn)的呢?更新語句會記錄 binlog，它是一種邏輯日志。有了這個 binlog，從服務(wù)器會獲取主服務(wù)器的 binlog  文件，然后解析里面的 SQL 語句，在從服務(wù)器上面執(zhí)行一遍，保持主從的數(shù)據(jù)一致。

這里面涉及到三個線程，連接到 master 獲取 binlog，并且解析 binlog 寫入中繼日 志，這個線程叫做 I/O 線程。Master  節(jié)點上有一個 log dump 線程，是用來發(fā)送 binlog 給 slave 的。從庫的 SQL 線程，是用來讀取 relay  log，把數(shù)據(jù)寫入到數(shù)據(jù)庫的。

做了主從復(fù)制的方案之后，我們只把數(shù)據(jù)寫入 master 節(jié)點，而讀的請求可以分擔(dān)到 slave 節(jié)點。我們把這種方案叫做讀寫分離。

讀寫分離可以一定程度地減輕數(shù)據(jù)庫服務(wù)器的訪問壓力，但是需要特別注意主從數(shù) 據(jù)一致性的問題。如果我們在 master 寫入了，馬上到 slave  查詢，而這個時候 slave 的 數(shù)據(jù)還沒有同步過來，怎么辦? 所以，基于主從復(fù)制的原理，我們需要弄明白，主從復(fù)制到底慢在哪里?

單線程

在早期的 MySQL 中，slave 的 SQL 線程是單線程。master 可以支持 SQL 語句的并 行執(zhí)行，配置了多少的最大連接數(shù)就是最多同時多少個  SQL 并行執(zhí)行。而 slave 的 SQL 卻只能單線程排隊執(zhí)行，在主庫并發(fā)量很大的情況下，同步數(shù)據(jù)肯 定會出現(xiàn)延遲為什么從庫上的 SQL Thread  不能并行執(zhí)行呢?舉個例子，主庫執(zhí)行了多條 SQL 語 句，首先用戶發(fā)表了一條評論，然后修改了內(nèi)容，最后把這條評論刪除了。這三條語句  在從庫上的執(zhí)行順序肯定是不能顛倒的

insert into user_comments (10000009,'nice');  update user_comments set content ='very good' where id =10000009;  delete from user_comments where id =10000009;

怎么解決這個問題呢?怎么減少主從復(fù)制的延遲?

異步與全同步

首先我們需要知道，在主從復(fù)制的過程中，MySQL 默認是異步復(fù)制的。也就是說， 對于主節(jié)點來說，寫入 binlog，事務(wù)結(jié)束，就返回給客戶端了。對于  slave 來說，接收 到 binlog，就完事兒了，master 不關(guān)心 slave 的數(shù)據(jù)有沒有寫入成功。

如果要減少延遲，是不是可以等待全部從庫的事務(wù)執(zhí)行完畢，才返回給客戶端呢? 這樣的方式叫做全同步復(fù)制。從庫寫完數(shù)據(jù)，主庫才返會給客戶端。

這種方式雖然可以保證在讀之前，數(shù)據(jù)已經(jīng)同步成功了，但是帶來的副作用大家應(yīng) 該能想到，事務(wù)執(zhí)行的時間會變長，它會導(dǎo)致 master  節(jié)點性能下降。有沒有更好的辦法呢?既減少 slave 寫入的延遲，又不會明顯增加 master 返回給客 戶端的時間?

半同步復(fù)制

介于異步復(fù)制和全同步復(fù)制之間，還有一種半同步復(fù)制的方式。主庫在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個從庫 接收到 binlog  并寫到 relay log 中才返回給客戶端。master 不會等待很長的時間，但是 返回給客戶端的時候，數(shù)據(jù)就即將寫入成功了，因為它只剩最后一步了：就是讀取  relay log，寫入從庫。

如果我們要在數(shù)據(jù)庫里面用半同步復(fù)制，必須安裝一個插件，這個是谷歌的一位工 程師貢獻的。這個插件在 mysql 的插件目錄下已經(jīng)有提供：cd  /usr/lib64/mysql/plugin/主庫和從庫是不同的插件，安裝之后需要啟用：

-- 主庫執(zhí)行  INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; set global rpl_semi_sync_master_enabled=1;  show variables like '%semi_sync%';    -- 從庫執(zhí)行  INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';  set global rpl_semi_sync_slave_enabled=1;  show global variables like '%semi%';

相對于異步復(fù)制，半同步復(fù)制提高了數(shù)據(jù)的安全性，同時它也造成了一定程度的延 遲，它需要等待一個 slave  寫入中繼日志，這里多了一個網(wǎng)絡(luò)交互的過程，所以，半同步 復(fù)制最好在低延時的網(wǎng)絡(luò)中使用。

這個是從主庫和從庫連接的角度，來保證 slave 數(shù)據(jù)的寫入。

另一個思路，如果要減少主從同步的延遲，減少 SQL 執(zhí)行造成的等待的時間，那有 沒有辦法在從庫上，讓多個 SQL  語句可以并行執(zhí)行，而不是排隊執(zhí)行呢?

多庫并行復(fù)制

怎么實現(xiàn)并行復(fù)制呢?設(shè)想一下，如果 3 條語句是在三個數(shù)據(jù)庫執(zhí)行，操作各自的 數(shù)據(jù)庫，是不是肯定不會產(chǎn)生并發(fā)的問題呢?執(zhí)行的順序也沒有要求。當(dāng)然是，所以如  果是操作三個數(shù)據(jù)庫，這三個數(shù)據(jù)庫的從庫的 SQL 線程可以并發(fā)執(zhí)行。這是 MySQL 5.6 版本里面支持的多庫并行復(fù)制。

但是在大部分的情況下，我們都是單庫多表的情況，在一個數(shù)據(jù)庫里面怎么實現(xiàn)并 行復(fù)制呢?或者說，我們知道，數(shù)據(jù)庫本身就是支持多個事務(wù)同時操作的;為什么這些  事務(wù)在主庫上面可以并行執(zhí)行，卻不會出現(xiàn)問題呢?

因為他們本身就是互相不干擾的，比如這些事務(wù)是操作不同的表，或者操作不同的 行，不存在資源的競爭和數(shù)據(jù)的干擾。那在主庫上并行執(zhí)行的事務(wù)，在從庫上肯定也是  可以并行執(zhí)行，是不是?比如在 master 上有三個事務(wù)同時分別操作三張表，這三個事務(wù) 是不是在 slave 上面也可以并行執(zhí)行呢?

5 異步復(fù)制之 GTID 復(fù)制

https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html所以，我們可以把那些在主庫上并行執(zhí)行的事務(wù)，分為一個組，并且給他們編號，  這一個組的事務(wù)在從庫上面也可以并行執(zhí)行。這個編號，我們把它叫做 GTID(Global Transaction  Identifiers)，這種主從復(fù)制的方式，我們把它叫做基于 GTID 的復(fù)制。

如果我們要使用 GTID 復(fù)制，我們可以通過修改配置參數(shù)打開它，默認是關(guān)閉的：

show global variables like 'gtid_mode';

無論是優(yōu)化 master 和 slave 的連接方式，還是讓從庫可以并行執(zhí)行 SQL，都是從數(shù) 據(jù)庫的層面去解決主從復(fù)制延遲的問題。

上述內(nèi)容就是MySQL主從復(fù)制的原理分析，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)站題目：MySQL主從復(fù)制的原理分析
分享網(wǎng)址：http://muchs.cn/article40/jojieo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、做網(wǎng)站、軟件開發(fā)、微信小程序、網(wǎng)站導(dǎo)航、動態(tài)網(wǎng)站

廣告

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