MySQL中怎么實(shí)現(xiàn)半同步復(fù)制，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

成都創(chuàng)新互聯(lián)專(zhuān)注于崇陽(yáng)企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站,成都商城網(wǎng)站開(kāi)發(fā)。崇陽(yáng)網(wǎng)站建設(shè)公司,為崇陽(yáng)等地區(qū)提供建站服務(wù)。全流程按需網(wǎng)站設(shè)計(jì)，專(zhuān)業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，成都創(chuàng)新互聯(lián)專(zhuān)業(yè)和態(tài)度為您提供的服務(wù)

半同步復(fù)制：

什么是半同步復(fù)制?我們知道在默認(rèn)情況下，MySQL的復(fù)制是異步的，這意味著主服務(wù)器及其從服務(wù)器是獨(dú)立的。異步復(fù)制可以提供***的性能，因?yàn)橹鞣?wù)器在將更新的數(shù)據(jù)寫(xiě)入它的二進(jìn)制日志(Binlog)文件中后，無(wú)需等待驗(yàn)證更新數(shù)據(jù)是否已經(jīng)復(fù)制到從服務(wù)器中，就可以自由處理其它進(jìn)入的事務(wù)處理請(qǐng)求。但這也同時(shí)帶來(lái)了很高的風(fēng)險(xiǎn)，如果在主服務(wù)器或從服務(wù)器端發(fā)生故障，會(huì)造成主從數(shù)據(jù)的不一致，甚至在恢復(fù)時(shí)造成數(shù)據(jù)丟失。

半同步復(fù)制是從MySQL5.5開(kāi)始引入了一種半同步復(fù)制功能，該功能可以確保主服務(wù)器和訪問(wèn)鏈中至少一臺(tái)從服務(wù)器之間的數(shù)據(jù)一致性和冗余。在這種配置結(jié)構(gòu)中，一臺(tái)主服務(wù)器和其許多從服務(wù)器都進(jìn)行了配置，這樣在復(fù)制拓?fù)渲?，至少有一臺(tái)從服務(wù)器在父主服務(wù)器進(jìn)行事務(wù)處理前，必須確認(rèn)更新已經(jīng)收到并寫(xiě)入了其中繼日志(Relay  Log)。當(dāng)出現(xiàn)超時(shí)，源主服務(wù)器必須暫時(shí)切換到異步復(fù)制模式重新復(fù)制，直到至少有一臺(tái)設(shè)置為半同步復(fù)制模式的從服務(wù)器及時(shí)收到信息。

下面我們看一下怎么從普通復(fù)制轉(zhuǎn)化為半同步復(fù)制。假設(shè)我們已經(jīng)搭建完成一主兩從的GTID復(fù)制環(huán)境：

• MySQL1：172.16.16.35:3306

• MySQL2：172.16.16.35:3307

• MySQL3：172.16.16.34:3306

這個(gè)環(huán)境因?yàn)槲抑皽y(cè)試MHA的時(shí)候已經(jīng)是搭建好了，就不在強(qiáng)調(diào)怎么去搭建一個(gè)普通的GTID復(fù)制環(huán)境了，下面我們看一下怎么安裝

(1)安裝插件，三臺(tái)MySQL服務(wù)器都要執(zhí)行：

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

我們可以通過(guò)以下語(yǔ)句查看是否安裝成功：

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%'; +----------------------+---------------+ | PLUGIN_NAME | PLUGIN_STATUS | +----------------------+---------------+ | rpl_semi_sync_master | ACTIVE | | rpl_semi_sync_slave | ACTIVE | +----------------------+---------------+ 2 rows in set (0.00 sec)

在三臺(tái)MySQL的配置文件當(dāng)中添加如下的參數(shù)：

rpl_semi_sync_master_enabled=1 #開(kāi)啟半同步復(fù)制

rpl_semi_sync_slave_enabled=on; #打開(kāi)半同步復(fù)制

然后重啟數(shù)據(jù)庫(kù)，不安裝semisync_master.so的話是不能識(shí)別這個(gè)參數(shù)的，所以說(shuō)這個(gè)參數(shù)要等安裝完以后在重啟。

(2)重啟完成后，默認(rèn)就是半同步復(fù)制了，開(kāi)始看一下半同步相關(guān)的參數(shù)：

mysql> show variables like 'rpl_se%'; +-------------------------------------------+------------+ | Variable_name | Value | +-------------------------------------------+------------+ | rpl_semi_sync_master_enabled | ON | | rpl_semi_sync_master_timeout | 10000 | | rpl_semi_sync_master_trace_level | 32 | | rpl_semi_sync_master_wait_for_slave_count | 1 | | rpl_semi_sync_master_wait_no_slave | ON | | rpl_semi_sync_master_wait_point | AFTER_SYNC | | rpl_semi_sync_slave_enabled | ON | | rpl_semi_sync_slave_trace_level | 32 | +-------------------------------------------+------------+ 8 rows in set (0.00 sec)

下面我們看一下這些參數(shù)具體是有什么含義：

rpl_semi_sync_master_enabled ：主庫(kù)是否打開(kāi)半同步復(fù)制

rpl_semi_sync_master_timeout ：毫秒為單位，當(dāng)主庫(kù)等待從庫(kù)ACK的實(shí)踐超過(guò)這個(gè)值，就會(huì)自動(dòng)轉(zhuǎn)化為異步復(fù)制

rpl_semi_sync_master_trace_level ：master的trace  級(jí)別，分為四個(gè)(1,16,32,64)，分別記錄不同的信息，32能夠輸出更詳細(xì)的網(wǎng)絡(luò)延遲等信息，也是默認(rèn)值

rpl_semi_sync_master_wait_for_slave_count  ：至少有N個(gè)slave接收到日志，一主多從的情況下只要有一個(gè)slave的ACK返回給了主庫(kù)，就會(huì)進(jìn)行commit

rpl_semi_sync_master_wait_no_slave：默認(rèn)為ON，當(dāng)半同步復(fù)制轉(zhuǎn)換為異步復(fù)制后，如果從庫(kù)的日志追趕上了主庫(kù)，會(huì)自動(dòng)轉(zhuǎn)換為半同步復(fù)制，設(shè)置為OFF的話就不會(huì)再進(jìn)行轉(zhuǎn)換。

rpl_semi_sync_slave_enabled ：從庫(kù)是否打開(kāi)半同步復(fù)制功能

rpl_semi_sync_slave_trace_level ：trace 級(jí)別

rpl_semi_sync_master_wait_point ：這是MySQL5.7新增的功能，可以設(shè)置兩個(gè)值A(chǔ)FTER_SYNC  和AFTER_COMMIT，AFTER_COMMIT的模式下master將每個(gè)事務(wù)寫(xiě)入binlog ,傳遞到slave 刷新到磁盤(pán)(relay  log)，同時(shí)主庫(kù)提交事務(wù)。master等待slave 反饋收到relay log，只有收到ACK后master才將commit  OK結(jié)果反饋給客戶端。AFTER_SYNC 情況下master 將每個(gè)事務(wù)寫(xiě)入binlog , 傳遞到slave 刷新到磁盤(pán)(relay  log)。master等待slave 反饋接收到relay log的ack之后，再提交事務(wù)并且返回commit OK結(jié)果給客戶端。  即使主庫(kù)crash，所有在主庫(kù)上已經(jīng)提交的事務(wù)都能保證已經(jīng)同步到slave的relay log中。我們推薦使用默認(rèn)AFTER_SYNC  的情況，這樣可以提高性能，減少等待時(shí)間。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。