推薦：MySQL Semisynchronous Replication介紹
這篇文章主要介紹了MySQL Semisynchronous Replication介紹,本文講解了Semisynchronous Replication 定義、,需要的朋友可以參考下 前言 MySQL 5.5版本之前默認的復制是異步(Asynchronous )模式的, MySQL 5.5 以plugins的方式提供了Semisynchronous Replication 模式。

　　為了解決這一個問題，MySQL 5.6之后引入了GTID的概念，即uuid:gid，uuid為MySQL server的uuid，是全局唯一的，而gid則是一個遞增的事務id，通過這兩個東西，我們就能唯一標示一個記錄到binlog中的事務。使用GTID，我們就能非常方便的進行failover的處理。

　　仍然是前面的例子，假設b此時讀取到的a最后一個GTID為3E11FA47-71CA-11E1-9E33-C80AA9429562:23，而c的為3E11FA47-71CA-11E1-9E33-C80AA9429562:15，當c指向新的master b的時候，我們通過GTID就可以知道，只要在b中的binlog中找到GTID為3E11FA47-71CA-11E1-9E33-C80AA9429562:15這個event，那么c就可以從它的下一個event的位置開始復制了。雖然查找binlog的方式仍然是順序查找，稍顯低效暴力，但比起我們自己去猜測哪一個filename和position，要方便太多了。

　　google很早也有了一個Global Transaction ID的補丁，不過只是使用的一個遞增的整形，LedisDB就借鑒了它的思路來實現(xiàn)failover，只不過google貌似現(xiàn)在也開始逐步遷移到MariaDB上面去了。

　　MariaDB的GTID實現(xiàn)跟MySQL 5.6是不一樣的，這點其實比較麻煩，對于我的MySQL工具集go-mysql來說，意味著要寫兩套不同的代碼來處理GTID的情況了。后續(xù)是否支持MariaDB再看情況吧。

　　Pseudo GTID

　　GTID雖然是一個好東西，但是僅限于MySQL 5.6+，當前仍然有大部分的業(yè)務使用的是5.6之前的版本，筆者的公司就是5.5的，而這些數(shù)據(jù)庫至少長時間也不會升級到5.6的。所以我們?nèi)匀恍枰�一套好的機制來選擇master binlog的filename以及position。

　　最初，筆者打算研究MHA的實現(xiàn)，它采用的是首先復制relay log來補足缺失的event的方式，但筆者不怎么信任relay log，同時加之MHA采用的是perl，一個讓我完全看不懂的語言，所以放棄了繼續(xù)研究。

　　幸運的是，筆者遇到了orchestrator這個項目，這真的是一個非常神奇的項目，它采用了一種Pseudo GTID的方式，核心代碼就是這個

　　復制代碼 代碼如下:

　　create database if not exists meta;

　　drop event if exists meta.create_pseudo_gtid_view_event;

　　delimiter ;;

　　create event if not exists

　　meta.create_pseudo_gtid_view_event

　　on schedule every 10 second starts current_timestamp

　　on completion preserve

　　enable

　　do

　　begin

　　set @pseudo_gtid := uuid();

　　set @_create_statement := concat('create or replace view meta.pseudo_gtid_view as select \'', @pseudo_gtid, '\' as pseudo_gtid_unique_val from dual');

　　PREPARE st FROM @_create_statement;

　　EXECUTE st;

　　DEALLOCATE PREPARE st;

　　end

　　;;

　　delimiter ;

　　set global event_scheduler := 1;

　　它在MySQL上面創(chuàng)建了一個事件，每隔10s，就將一個uuid寫入到一個view里面，而這個是會記錄到binlog中的，雖然我們?nèi)匀徊荒芟馟TID那樣直接定位到一個event，但也能定位到一個10s的區(qū)間了，這樣我們就能在很小的一個區(qū)間里面對比兩個MySQL的binlog了。

　　繼續(xù)上面的例子，假設c最后一次出現(xiàn)uuid的位置為s1，我們在b里面找到該uuid，位置為s2，然后依次對比后續(xù)的event，如果不一致，則可能出現(xiàn)了問題，停止復制。當遍歷到c最后一個binlog event之后，我們就能得到此時b下一個event對應的filename以及position了，然后讓c指向這個位置開始復制。

　　使用Pseudo GTID需要slave打開log-slave-update的選項，考慮到GTID也必須打開該選項，所以個人感覺完全可以接受。

　　后續(xù)，筆者自己實現(xiàn)的failover工具，將會采用這種Pseudo GTID的方式實現(xiàn)。

　　在《MySQL High Availability》這本書中，作者使用了另一種GTID的做法，每次commit的時候，需要在一個表里面記錄gtid，然后就通過這個gtid來找到對應的位置信息，只是這種方式需要業(yè)務MySQL客戶端的支持，筆者不很喜歡，就不采用了。

　　后記

　　MySQL HA一直是一個水比較深的領域，筆者僅僅列出了一些最近研究的東西，有些相關工具會盡量在go-mysql中實現(xiàn)。

　　更新

　　經(jīng)過一段時間的思考與研究，筆者又有了很多心得與收獲，設計的MySQL HA跟先前有了很多不一樣的地方。后來發(fā)現(xiàn)，自己設計的這套HA方案，跟facebook這篇文章幾乎一樣，加之最近跟facebook的人聊天聽到他們也正在大力實施，所以感覺自己方向是對了。

　　新的HA，我會完全擁抱GTID，比較這玩意的出現(xiàn)就是為了解決原先replication那一堆問題的，所以我不會考慮非GTID的低版本MySQL了。幸運的是，我們項目已經(jīng)將MySQL全部升級到5.6，完全支持GTID了。

　　不同于fb那篇文章將mysqlbinlog改造支持semi-sync replication協(xié)議，我是將go-mysql的replication庫支持semi-sync replication協(xié)議，這樣就能實時的將MySQL的binlog同步到一臺機器上面。這可能就是我和fb方案的唯一區(qū)別了。

　　只同步binlog速度鐵定比原生slave要快，畢竟少了執(zhí)行binlog里面event的過程了，而另外真正的slaves，我們?nèi)匀皇褂米钤�始的同步方��，不使用semi-sync replication。然后我們通過MHA監(jiān)控整個集群以及進行故障轉移處理。

　　以前我總認為MHA不好理解，但其實這是一個非常強大的工具，而且真正看perl，發(fā)現(xiàn)也還是看的懂得。MHA已經(jīng)被很多公司用于生產(chǎn)環(huán)境，經(jīng)受了檢驗，直接使用絕對比自己寫一個要劃算。所以后續(xù)我也不會考慮zookeeper，考慮自己寫agent了。

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