推薦：MySQL延遲關聯性能優化方法
這篇文章主要介紹了MySQL延遲關聯性能優化方法,本文講解了延遲關聯的背景、延遲關聯的分析、延遲關聯的解決等內容,需要的朋友可以參考下 【背景】 某業務數據庫load 報警異常，cpu usr 達到30-40 ，居高不下。使用工具查看數據庫正在執行的sql ，排在前面的大部分是：

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

　　前言

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

　　異步復制模式

　　主庫將已經提交的事務event 寫入binlog后，即返回成功給app，該模式下并不保證任何已經提交的事務會傳遞到任何slave并被成功應用。

　　全同步復制模式。

　　當主庫提交一個事務 event，主庫會等待該事務被傳遞到所有的slave上，且所有slave applay 該事務/event 通知主庫之后，才會返回回話，事務已經成功。

　　從定義中可以看出 異步模式不能保證數據的安全性，因為它不等待主庫提交的事務在slave 上落盤，而全同步模式 由于要等待所有的slave 確認已提交事務成功被應用，如此則會帶來事務處理上的延時。semi sync 則取了一個比較折中的方式，確保已提交的事務必須存在于至少兩個機器(主庫和任一備庫)，立即返回給客戶端 事務成功。

　　一、Semisynchronous Replication 定義

　　Semisynchronous Replication模式下,在主庫上提交一個事務/event，它會等待至少一個slave通知主庫，slave 已經接收到傳遞過來的events并寫入relay log，才返回給回話層 寫入成功，或者直到傳送日志發生超時。

　　二、優缺點

　　優點：當事務返回成功給客戶端時，則事務至少在兩臺機器上存在，增強數據安全性。相比異步模式和全同步模式，是一種折中。

　　缺點：半同步的確會對數據庫性能有一定影響，因為事務的提交必須等待slave 反饋。性能損耗取決于tcp/IP 網絡傳輸時間，也即傳輸已提交事務和等待slave 反饋已經接收事務的時間。

　　三、MySQL 半同步的特性

　　1 當slave 連接主庫時，它會告知主庫它是不是semi sync 模式。

　　2 如果主庫啟用了semi sync模式，且至少一個slave 也啟用了semi sync模式，一個在主庫操作事務的進程在事務提交之后，且至少一個slave 通知主庫成功接收所有事務之前，該進程會處于blocks 等待狀態或者直到超時發生。

　　3 當且僅當傳遞過來的events 傳遞到slave，被寫入relay log，刷新到磁盤才會通知主庫完成。

　　4 Semisynchronous replication 必須在主備兩端都同時啟用，否則任何一個未設置，主備之間的復制模式將轉變為異步復制模式。

　　5 當所有slave 在(rpl_semi_sync_master_timeout的默認值)時間內未返回給主庫成功接收event，主備之間就會變回原來的異步狀態。

　　其中關于第二點 MySQL 5.7 已經做了優化，由ack Collector (Col) thread 等待備庫的成功接收事務的通知,這點后續會做詳細介紹--《5.7 Semisync replication 增強》。

　　四、異常處理

　　當備庫Crash時，主庫會在某次等待超時后，關閉Semi-sync的特性，降級為普通的異步復制，這種情況比較簡單。

　　MySQL的 error.log 會提示：

　　 代碼如下:

　　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.

　　比較難以處理的情況是:當主機/主庫Crash時，可能存在一些事務已經在主庫提交，但是還沒有來的及傳給任何備庫，也即這些事務都是沒有返回給客戶端的，所以發起事務的客戶端并不知道這個事務是否已經完成--"墻頭事務"。這時，如果客戶端不做切換，只是等Crash的主庫恢復后，繼續在主庫進行操作，客戶端會發現前面的"墻頭事務"都已經完成，可以繼續進行后續的業務處理;另一種情況，如果客戶端Failover到備庫上，客戶端會發現前面的“墻頭事務”都沒有成功，則需要重新做這些事務，然后繼續進行后續的業務處理，其實此時主備是不一致的，需要通過主備數據校驗來檢查哪一個庫是正確的，然后進行修復。

　　五、小結

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

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