推薦：MySQL延遲關(guān)聯(lián)性能優(yōu)化方法
這篇文章主要介紹了MySQL延遲關(guān)聯(lián)性能優(yōu)化方法,本文講解了延遲關(guān)聯(lián)的背景、延遲關(guān)聯(lián)的分析、延遲關(guān)聯(lián)的解決等內(nèi)容,需要的朋友可以參考下 【背景】 某業(yè)務(wù)數(shù)據(jù)庫(kù)load 報(bào)警異常，cpu usr 達(dá)到30-40 ，居高不下。使用工具查看數(shù)據(jù)庫(kù)正在執(zhí)行的sql ，排在前面的大部分是：

 　　這篇文章主要介紹了MySQL Semisynchronous Replication介紹,本文講解了Semisynchronous Replication 定義、,需要的朋友可以參考下

　　前言

　　MySQL 5.5版本之前默認(rèn)的復(fù)制是異步(Asynchronous )模式的, MySQL 5.5 以plugins的方式提供了Semisynchronous Replication 模式。在介紹 semi sync 之前,我們先了解：半同步 Asynchronous 和 同步 Synchronous 。

　　異步復(fù)制模式

　　主庫(kù)將已經(jīng)提交的事務(wù)event 寫(xiě)入binlog后，即返回成功給app，該模式下并不保證任何已經(jīng)提交的事務(wù)會(huì)傳遞到任何slave并被成功應(yīng)用。

　　全同步復(fù)制模式。

　　當(dāng)主庫(kù)提交一個(gè)事務(wù) event，主庫(kù)會(huì)等待該事務(wù)被傳遞到所有的slave上，且所有slave applay 該事務(wù)/event 通知主庫(kù)之后，才會(huì)返回回話，事務(wù)已經(jīng)成功。

　　從定義中可以看出 異步模式不能保證數(shù)據(jù)的安全性，因?yàn)樗�不等待主�?kù)提交的事務(wù)在slave 上落盤(pán)，而全同步模式 由于要等待所有的slave 確認(rèn)已提交事務(wù)成功被應(yīng)用，如此則會(huì)帶來(lái)事務(wù)處理上的延時(shí)。semi sync 則取了一個(gè)比較折中的方式，確保已提交的事務(wù)必須存在于至少兩個(gè)機(jī)器(主庫(kù)和任一備庫(kù))，立即返回給客戶(hù)端 事務(wù)成功。

　　一、Semisynchronous Replication 定義

　　Semisynchronous Replication模式下,在主庫(kù)上提交一個(gè)事務(wù)/event，它會(huì)等待至少一個(gè)slave通知主庫(kù)，slave 已經(jīng)接收到傳遞過(guò)來(lái)的events并寫(xiě)入relay log，才返回給回話層 寫(xiě)入成功，或者直到傳送日志發(fā)生超時(shí)。

　　二、優(yōu)缺點(diǎn)

　　優(yōu)點(diǎn)：當(dāng)事務(wù)返回成功給客戶(hù)端時(shí)，則事務(wù)至少在兩臺(tái)機(jī)器上存在，增強(qiáng)數(shù)據(jù)安全性。相比異步模式和全同步模式，是一種折中。

　　缺點(diǎn)：半同步的確會(huì)對(duì)數(shù)據(jù)庫(kù)性能有一定影響，因?yàn)槭聞?wù)的提交必須等待slave 反饋。性能損耗取決于tcp/IP 網(wǎng)絡(luò)傳輸時(shí)間，也即傳輸已提交事務(wù)和等待slave 反饋已經(jīng)接收事務(wù)的時(shí)間。

　　三、MySQL 半同步的特性

　　1 當(dāng)slave 連接主庫(kù)時(shí)，它會(huì)告知主庫(kù)它是不是semi sync 模式。

　　2 如果主庫(kù)啟用了semi sync模式，且至少一個(gè)slave 也啟用了semi sync模式，一個(gè)在主庫(kù)操作事務(wù)的進(jìn)程在事務(wù)提交之后，且至少一個(gè)slave 通知主庫(kù)成功接收所有事務(wù)之前，該進(jìn)程會(huì)處于blocks 等待狀態(tài)或者直到超時(shí)發(fā)生。

　　3 當(dāng)且僅當(dāng)傳遞過(guò)來(lái)的events 傳遞到slave，被寫(xiě)入relay log，刷新到磁盤(pán)才會(huì)通知主庫(kù)完成。

　　4 Semisynchronous replication 必須在主備兩端都同時(shí)啟用，否則任何一個(gè)未設(shè)置，主備之間的復(fù)制模式將轉(zhuǎn)變?yōu)楫惒綇?fù)制模式。

　　5 當(dāng)所有slave 在(rpl_semi_sync_master_timeout的默認(rèn)值)時(shí)間內(nèi)未返回給主庫(kù)成功接收event，主備之間就會(huì)變回原來(lái)的異步狀態(tài)。

　　其中關(guān)于第二點(diǎn) MySQL 5.7 已經(jīng)做了優(yōu)化，由ack Collector (Col) thread 等待備庫(kù)的成功接收事務(wù)的通知,這點(diǎn)后續(xù)會(huì)做詳細(xì)介紹--《5.7 Semisync replication 增強(qiáng)》。

　　四、異常處理

　　當(dāng)備庫(kù)Crash時(shí)，主庫(kù)會(huì)在某次等待超時(shí)后，關(guān)閉Semi-sync的特性，降級(jí)為普通的異步復(fù)制，這種情況比較簡(jiǎn)單。

　　MySQL的 error.log 會(huì)提示：

　　 代碼如下:

　　140523 22:26:00 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000002, pos: 465893519), semi-sync up to file , position 0.

　　140523 22:26:00 [Note] Semi-sync replication switched OFF.

　　比較難以處理的情況是:當(dāng)主機(jī)/主庫(kù)Crash時(shí)，可能存在一些事務(wù)已經(jīng)在主庫(kù)提交，但是還沒(méi)有來(lái)的及傳給任何備庫(kù)，也即這些事務(wù)都是沒(méi)有返回給客戶(hù)端的，所以發(fā)起事務(wù)的客戶(hù)端并不知道這個(gè)事務(wù)是否已經(jīng)完成--"墻頭事務(wù)"。這時(shí)，如果客戶(hù)端不做切換，只是等Crash的主庫(kù)恢復(fù)后，繼續(xù)在主庫(kù)進(jìn)行操作，客戶(hù)端會(huì)發(fā)現(xiàn)前面的"墻頭事務(wù)"都已經(jīng)完成，可以繼續(xù)進(jìn)行后續(xù)的業(yè)務(wù)處理;另一種情況，如果客戶(hù)端Failover到備庫(kù)上，客戶(hù)端會(huì)發(fā)現(xiàn)前面的“墻頭事務(wù)”都沒(méi)有成功，則需要重新做這些事務(wù)，然后繼續(xù)進(jìn)行后續(xù)的業(yè)務(wù)處理，其實(shí)此時(shí)主備是不一致的，需要通過(guò)主備數(shù)據(jù)校驗(yàn)來(lái)檢查哪一個(gè)庫(kù)是正確的，然后進(jìn)行修復(fù)。

　　五、小結(jié)

　　總之相比于MySQL 5.5 版本之前的異步復(fù)制模式 semi sync 已經(jīng)有了很大的進(jìn)步，增強(qiáng)了數(shù)據(jù)的安全性，以安全換一定的性能損耗還是可以接受的。后續(xù)會(huì)介紹如何安裝和使用semi sync。

分享：MySQL 5.7增強(qiáng)版Semisync Replication性能優(yōu)化
這篇文章主要介紹了MySQL 5.7增強(qiáng)版Semisync Replication性能優(yōu)化,本文著重講解支持發(fā)送binlog和接受ack的異步化、支持在事務(wù)commit前等待ACK兩項(xiàng)內(nèi)容,需要的朋友可以參考下 一 前言 前文 介紹了5.5/5.6 版本的MySQL semi sync 基礎(chǔ)原理和配置，隨著MySQL 5.7 的發(fā)布，