MySQL 默認(rèn)的復(fù)制就是異步的，主庫再執(zhí)行完客戶端提交的事務(wù)后會立即將結(jié)果返回給客戶端，并不關(guān)系從庫是否已經(jīng)接收和處理。
創(chuàng)新互聯(lián)長期為近1000家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為武威企業(yè)提供專業(yè)的網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作，武威網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。
MySQL主庫將Binlog事件寫入到Binlog文件中，此時主庫只通知一下Dump線程發(fā)送這些新的Binlog，然后主庫繼續(xù)處理提交操作，不會保證這些Binlog傳到任何一個從庫節(jié)點(diǎn)上。
因?yàn)楫惒綇?fù)制，主節(jié)點(diǎn)不關(guān)從節(jié)點(diǎn)是否收到Binlog，如果主crash掉了，此時主節(jié)點(diǎn)上已提交的事務(wù)可能并沒有傳到從庫上，如果此時，強(qiáng)行將從節(jié)點(diǎn)提升為主節(jié)點(diǎn)，可能導(dǎo)致新的主節(jié)點(diǎn)上數(shù)據(jù)不完整。
全同步是指當(dāng)主庫接收到客戶端的一個事務(wù)請求，所有的從庫都執(zhí)行了該事務(wù)才返回給客戶端。
當(dāng)主庫收到客戶端提交的事務(wù)后，所有的從庫必須收到并且執(zhí)行事務(wù)，然后主庫才會執(zhí)行后續(xù)操作。
因?yàn)橐却袕膸靾?zhí)行完事務(wù)，主庫才將結(jié)果返回給客戶端，所以全同步復(fù)制的性能必然受到嚴(yán)重影響，即完成一個事務(wù)的時間被拉長，性能降低。
半同步復(fù)制是介于全同步復(fù)制和全異步復(fù)制之間的一種，主庫只需要等待至少一個從庫節(jié)點(diǎn)收到并Flush Binlog到Relay log文件即可，主庫不需要等待所有從庫給主庫反饋。（注意只要收到一個從庫的反饋即可）
介于異步復(fù)制和全同步復(fù)制之間，主庫再執(zhí)行完客戶端提交的食物后不是立刻返回給客戶端，而是等待至少一個從庫接收到并寫到relay log中才返回給客戶端。
相對于異步復(fù)制，半同步復(fù)制提交了數(shù)據(jù)的安全性，同時它也造成了一定程序的延遲，這個延遲至少是一個TCP/IP往返時間，因此，半同步復(fù)制雖好在低延時的網(wǎng)絡(luò)中使用。
XMind - Trial Version
在MySQL5.5之前，MySQL 的復(fù)制是異步操作，主庫和從庫的數(shù)據(jù)之間存在一定的延遲，這樣存在一個隱患:當(dāng)在主庫上寫入一個事務(wù)并提交成功，而從庫尚未得到主庫推送的Binlog日志時，主庫宕機(jī)了，例如主庫可能因磁盤損壞、內(nèi)存故障等造成主庫上該事務(wù)Binlog丟失，此時從庫就可能損失這個事務(wù)，從而造成主從不一致。
為了解決這個問題, MySQL5.5引人了半同步復(fù)制機(jī)制。
在MySQL 5.5之前的異步復(fù)制時，主庫執(zhí)行完 Commit提交操作后，在主庫寫入 Binlog日志后即可成功返回客戶端，無需等待Binlog日志傳送給從庫，如圖31-7所示。
而半同步復(fù)制時，為了保證主庫上的每一個 Binlog 事務(wù)都能夠被可靠的復(fù)制到從庫上，主庫在每次事務(wù)成功提交時，并不及時反饋給前端應(yīng)用用戶，而是等待其中一個從庫也接收到 Binlog事務(wù)并成功寫入中繼日志后，主庫才返回Commit操作成功給客戶端。 半同步復(fù)制保證了事務(wù)成功提交后，至少有兩份日志記錄 ，一份在主庫的 Binlog日志上，另一份在至少一個從庫的中繼日志Relay Log 上，從而更進(jìn)一步保證了數(shù)據(jù)的完整性。半同步復(fù)制的大致流程如圖31-8所示。
半同步復(fù)制模式下，假如在圖31-8的步驟1、2、3中的任何一個步驟中主庫宕機(jī)，則事務(wù)并未提交成功，從庫上也沒有收到事務(wù)對應(yīng)的 Binlog日志，所以主從數(shù)據(jù)是一致的;
假如在步驟4傳送 Binlog日志到從庫時，從庫宕機(jī)或者網(wǎng)絡(luò)故障，導(dǎo)致 Binlog并沒有及時地傳送到從庫上，此時主庫上的事務(wù)會等待一段時間(時間長短由參數(shù)rpl_semi_sync_master_timeout設(shè)置的毫秒數(shù)決定)，如果 Binlog 在這段時間內(nèi)都無法成功推送到從庫上，則 MySQL自動調(diào)整復(fù)制為異步模式，事務(wù)正常返回提交結(jié)果給客戶端。
半同步復(fù)制很大程度上取決于主從庫之間的網(wǎng)絡(luò)情況，往返時延RTT 越小決定了從庫的實(shí)時性越好。通俗地說，主從庫之間網(wǎng)絡(luò)越快，從庫越實(shí)時。
半同步模式是作為MySQL5.5的一個插件來實(shí)現(xiàn)的，主庫和從庫使用不同的插件。安裝比較簡單，在上一小節(jié)異步復(fù)制的環(huán)境上，安裝半同步復(fù)制插件即可。
1、首先,判斷MySQL服務(wù)器是否支持動態(tài)增加插件:
2、安裝插件
3、可以查看到已安裝的插件
4、在安裝完插件后，半同步復(fù)制默認(rèn)是關(guān)閉的，這時需設(shè)置參數(shù)來開啟半同步
主：
從：
以上的啟動方式是在命令行操作，也可寫在配置文件中。
主：
從：
4、重啟從上的IO線程
從：
如果沒有重啟，則默認(rèn)還是異步復(fù)制，重啟后，slave會在master上注冊為半同步復(fù)制的slave角色。這時候，主的error.log中會打印如下信息：
查看半同步是否在運(yùn)行
主：
從：
這兩個變量常用來監(jiān)控主從是否運(yùn)行在半同步復(fù)制模式下。至此，MySQL半同步復(fù)制搭建完畢~
來做個實(shí)驗(yàn)，觀察半同步狀態(tài)參數(shù)的變化。
1、在主庫上insert一條記錄，觀察下變化；
Rpl_semi_sync_master_net_waits加1，說明剛才的insert已經(jīng)發(fā)送到從機(jī)并且主機(jī)還接收到從機(jī)的反饋響應(yīng)；
2、我們將從機(jī)mysql停止，再次在主機(jī)上進(jìn)行insert后查看狀態(tài)
可以看到，主機(jī)進(jìn)行insert阻塞了10秒才返回結(jié)果。Rpl_semi_sync_master_status變?yōu)镺FF，Rpl_semi_sync_master_no_tx加1，說明這條insert沒有同步到從機(jī)。后面再一次執(zhí)行了insert立馬返回了結(jié)果，說明此時已經(jīng)降級為異步復(fù)制；Rpl_semi_sync_master_no_tx也是增加了1；
3、現(xiàn)在恢復(fù)啟動從機(jī)，再次在主機(jī)上進(jìn)行insert后查看狀態(tài)
Rpl_semi_sync_master_status還是OFF，Rpl_semi_sync_master_no_tx又增加了1。說明從庫重啟并不會自動恢復(fù)為原來的半同步復(fù)制，需要手動操作：
主 SET GLOBAL rpl_semi_sync_master_enabled = 1;
從 SET GLOBAL rpl_semi_sync_slave_enabled = 1; STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
上面是從機(jī)重啟后的變化，那么主到從之間的網(wǎng)絡(luò)問題呢，我們可以利用防火墻來模擬。
對于全同步復(fù)制，當(dāng)主庫提交事務(wù)之后，所有的從庫節(jié)點(diǎn)必須收到，APPLY并且提交這些事務(wù)，然后主庫線程才能繼續(xù)做后續(xù)操作。這里面有一個很明顯的缺點(diǎn)就是，主庫完成一個事務(wù)的時間被拉長，性能降低。
MySQL 主從一直是面試?？停锩娴闹R點(diǎn)雖然基礎(chǔ)，但是能回答全的同學(xué)不多。
比如樓哥之前面試小米，就被問到過主從復(fù)制的原理，以及主從延遲的解決方案，因?yàn)榛卮鸬姆浅２诲e，給面試官留下非常好的印象。你之前面試，有遇到過哪些 MySQL 主從的問題呢？
所謂 MySQL 主從，就是建立兩個完全一樣的數(shù)據(jù)庫，一個是主庫，一個是從庫， 主庫對外提供讀寫的操作，從庫對外提供讀的操作 ，下面是一主一從模式：
對于數(shù)據(jù)庫單機(jī)部署，在 4 核 8G 的機(jī)器上運(yùn)行 MySQL 5.7 時，大概可以支撐 500 的 TPS 和 10000 的 QPS， 當(dāng)遇到一些活動時，查詢流量驟然，就需要進(jìn)行主從分離。
大部分系統(tǒng)的訪問模型是讀多寫少，讀寫請求量的差距可能達(dá)到幾個數(shù)量級，所以我們可以通過一主多從的方式， 主庫只負(fù)責(zé)寫入和部分核心邏輯的查詢，多個從庫只負(fù)責(zé)查詢，提升查詢性能，降低主庫壓力。
MySQL 主從還能做到服務(wù)高可用，當(dāng)主庫宕機(jī)時，從庫可以切成主庫，保證服務(wù)的高可用，然后主庫也可以做數(shù)據(jù)的容災(zāi)備份。
整體場景總結(jié)如下：
MySQL 的主從復(fù)制是依賴于 binlog 的，也就是記錄 MySQL 上的所有變化并以二進(jìn)制形式保存在磁盤上二進(jìn)制日志文件。
主從復(fù)制就是將 binlog 中的數(shù)據(jù)從主庫傳輸?shù)綇膸焐?，一般這個過程是異步的，即主庫上的操作不會等待 binlog 同步的完成。
詳細(xì)流程如下：
當(dāng)主庫和從庫數(shù)據(jù)同步時，突然中斷怎么辦？因?yàn)橹鲙炫c從庫之間維持了一個長鏈接，主庫內(nèi)部有一個線程，專門服務(wù)于從庫的這個長鏈接的。
對于下面的情況，假如主庫執(zhí)行如下 SQL，其中 a 和 create_time 都是索引：
我們知道，數(shù)據(jù)選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來的數(shù)據(jù)一般是不一樣的。
所以就會存在這種情況：在 binlog = statement 格式時，主庫在執(zhí)行這條 SQL 時，使用的是索引 a，而從庫在執(zhí)行這條 SQL 時，使用了索引 create_time，最后主從數(shù)據(jù)不一致了。
那么我們改如何解決呢？
可以把 binlog 格式修改為 row，row 格式的 binlog 日志記錄的不是 SQL 原文，而是兩個 event:Table_map 和 Delete_rows。
Table_map event 說明要操作的表，Delete_rows event用于定義要刪除的行為，記錄刪除的具體行數(shù)。 row 格式的 binlog 記錄的就是要刪除的主鍵 ID 信息，因此不會出現(xiàn)主從不一致的問題。
但是如果 SQL 刪除 10 萬行數(shù)據(jù)，使用 row 格式就會很占空間的，10 萬條數(shù)據(jù)都在 binlog 里面，寫 binlog 的時候也很耗 IO。但是 statement 格式的 binlog 可能會導(dǎo)致數(shù)據(jù)不一致。
設(shè)計(jì) MySQL 的大叔想了一個折中的方案，mixed 格式的 binlog，其實(shí)就是 row 和 statement 格式混合使用， 當(dāng) MySQL 判斷可能數(shù)據(jù)不一致時，就用 row 格式，否則使用就用 statement 格式。
有時候我們遇到從數(shù)據(jù)庫中獲取不到信息的詭異問題時，會糾結(jié)于代碼中是否有一些邏輯會把之前寫入的內(nèi)容刪除，但是你又會發(fā)現(xiàn)，過了一段時間再去查詢時又可以讀到數(shù)據(jù)了，這基本上就是主從延遲在作怪。
主從延遲，其實(shí)就是“從庫回放” 完成的時間，與 “主庫寫 binlog” 完成時間的差值， 會導(dǎo)致從庫查詢的數(shù)據(jù)，和主庫的不一致 。
談到 MySQL 數(shù)據(jù)庫主從同步延遲原理，得從 MySQL 的主從復(fù)制原理說起：
總結(jié)一下主從延遲的主要原因 ：主從延遲主要是出現(xiàn)在 “relay log 回放” 這一步，當(dāng)主庫的 TPS 并發(fā)較高，產(chǎn)生的 DDL 數(shù)量超過從庫一個 SQL 線程所能承受的范圍，那么延時就產(chǎn)生了，當(dāng)然還有就是可能與從庫的大型 query 語句產(chǎn)生了鎖等待。
我們一般會把從庫落后的時間作為一個重點(diǎn)的數(shù)據(jù)庫指標(biāo)做監(jiān)控和報(bào)警，正常的時間是在毫秒級別，一旦落后的時間達(dá)到了秒級別就需要告警了。
解決該問題的方法，除了縮短主從延遲的時間，還有一些其它的方法，基本原理都是盡量不查詢從庫。
具體解決方案如下：
在實(shí)際應(yīng)用場景中，對于一些非常核心的場景，比如庫存，支付訂單等，需要直接查詢從庫，其它非核心場景，就不要去查主庫了。
兩臺機(jī)器 A 和 B，A 為主庫，負(fù)責(zé)讀寫，B 為從庫，負(fù)責(zé)讀數(shù)據(jù)。
如果 A 庫發(fā)生故障，B 庫成為主庫負(fù)責(zé)讀寫，修復(fù)故障后，A 成為從庫，主庫 B 同步數(shù)據(jù)到從庫 A。
一臺主庫多臺從庫，A 為主庫，負(fù)責(zé)讀寫，B、C、D為從庫，負(fù)責(zé)讀數(shù)據(jù)。
如果 A 庫發(fā)生故障，B 庫成為主庫負(fù)責(zé)讀寫，C、D負(fù)責(zé)讀，修復(fù)故障后，A 也成為從庫，主庫 B 同步數(shù)據(jù)到從庫 A。
對于變化頻率非?？斓臄?shù)據(jù)來說，如果還選擇傳統(tǒng)的靜態(tài)緩存方式（Memocached、File System等）展示數(shù)據(jù)，可能在緩存的存取上會有很大的開銷，并不能很好的滿足需要，而Redis這樣基于內(nèi)存的NoSQL數(shù)據(jù)庫，就非常適合擔(dān)任實(shí)時數(shù)據(jù)的容器。
但是往往又有數(shù)據(jù)可靠性的需求，采用MySQL作為數(shù)據(jù)存儲，不會因?yàn)閮?nèi)存問題而引起數(shù)據(jù)丟失，同時也可以利用關(guān)系數(shù)據(jù)庫的特性實(shí)現(xiàn)很多功能。
所以就會很自然的想到是否可以采用MySQL作為數(shù)據(jù)存儲引擎，Redis則作為Cache。而這種需求目前還沒有看到有特別成熟的解決方案或工具，因此采用Gearman+PHP+MySQL UDF的組合異步實(shí)現(xiàn)MySQL到Redis的數(shù)據(jù)復(fù)制。
MySQL到Redis數(shù)據(jù)復(fù)制方案
無論MySQL還是Redis，自身都帶有數(shù)據(jù)同步的機(jī)制，比較常用的MySQL的Master/Slave模式，就是由Slave端分析Master的binlog來實(shí)現(xiàn)的，這樣的數(shù)據(jù)復(fù)制其實(shí)還是一個異步過程，只不過當(dāng)服務(wù)器都在同一內(nèi)網(wǎng)時，異步的延遲幾乎可以忽略。
那么理論上也可以用同樣方式，分析MySQL的binlog文件并將數(shù)據(jù)插入Redis。但是這需要對binlog文件以及MySQL有非常深入的理解，同時由于binlog存在Statement/Row/Mixedlevel多種形式，分析binlog實(shí)現(xiàn)同步的工作量是非常大的。
因此這里選擇了一種開發(fā)成本更加低廉的方式，借用已經(jīng)比較成熟的MySQL UDF，將MySQL數(shù)據(jù)首先放入Gearman中，然后通過一個自己編寫的PHP Gearman Worker，將數(shù)據(jù)同步到Redis。比分析binlog的方式增加了不少流程，但是實(shí)現(xiàn)成本更低，更容易操作。
Gearman的安裝與使用
Gearman是一個支持分布式的任務(wù)分發(fā)框架。設(shè)計(jì)簡潔，獲得了非常廣泛的支持。一個典型的Gearman應(yīng)用包括以下這些部分：
Gearman Job Server：Gearman核心程序，需要編譯安裝并以守護(hù)進(jìn)程形式運(yùn)行在后臺
Gearman Client：可以理解為任務(wù)的收件員，比如在后臺執(zhí)行一個發(fā)送郵件的任務(wù)，可以在程序中調(diào)用一個Gearman Client并傳入郵件的信息，然后就可以將執(zhí)行結(jié)果立即展示給用戶，而任務(wù)本身會慢慢在后臺運(yùn)行。
Gearman Worker：任務(wù)的真正執(zhí)行者，一般需要自己編寫具體邏輯并通過守護(hù)進(jìn)程方式運(yùn)行，Gearman Worker接收到Gearman Client傳遞的任務(wù)內(nèi)容后，會按順序處理。
以前曾經(jīng)介紹過類似的后臺任務(wù)處理項(xiàng)目Resque。兩者的設(shè)計(jì)其實(shí)非常接近，簡單可以類比為：
Gearman Job Server：對應(yīng)Resque的Redis部分
Gearman Client：對應(yīng)Resque的Queue操作
Gearman Worker：對應(yīng)Resque的Worker和Job
這里之所以選擇Gearman而不是Resque是因?yàn)镚earman提供了比較好用的MySQL UDF，工作量更小。
安裝Gearman及PHP Gearman擴(kuò)展
以下均以Ubuntu12.04為例。
apt-get install gearman gearman-server libgearman-dev
檢查Gearman的運(yùn)行狀況：
/etc/init.d/gearman-job-server status
* gearmand is running
說明Gearman已經(jīng)安裝成功。
PHP的Gearman擴(kuò)展可以通過pecl直接安裝
pecl install gearman
echo "extension=gearman.so"/etc/php5/conf.d/gearman.ini
service php5-fpm restart
但是實(shí)測發(fā)現(xiàn)ubuntu默認(rèn)安裝的gearman版本過低，直接運(yùn)行pecl install gearman會報(bào)錯
configure: error: libgearman version 1.1.0or later required
因此Gearman + PHP擴(kuò)展建議通過編譯方式安裝，這里為了簡單說明，選擇安裝舊版本擴(kuò)展：
pecl install gearman-1.0.3
Gearman + PHP實(shí)例
為了更容易理解后文Gearman的運(yùn)行流程，這里不妨從一個最簡單的Gearman實(shí)例來說明，比如要進(jìn)行一個文件處理的操作，首先編寫一個Gearman Client并命名為client.php：
?php
$client =newGearmanClient();
$client-addServer();
$client-doBackground('writeLog','Log content');
echo '文件已經(jīng)在后臺操作';
運(yùn)行這個文件，相當(dāng)于模擬用戶請求一個Web頁面后，將處理結(jié)束的信息返回用戶：
php client.php
查看一下Gearman的狀況：
(echo status ; sleep 0.1)| netcat127.0.0.14730
可以看到輸出為
writeLog ? ? ? ?100.
說明已經(jīng)在Gearman中建立了一個名為writeLog的任務(wù)，并且有1個任務(wù)在隊(duì)列等待中。
而上面的4列分別代表當(dāng)前的Gearman的運(yùn)行狀態(tài)：
任務(wù)名稱
在等待隊(duì)列中的任務(wù)
正在運(yùn)行的任務(wù)
正在運(yùn)行的Worker進(jìn)程
可以使用watch進(jìn)行實(shí)時監(jiān)控：
watch -n 1"(echo status; sleep 0.1) | nc 127.0.0.1 4730"
然后我們需要編寫一個Gearman Worker命名為worker.php：
?php
$worker =newGearmanWorker();
$worker-addServer();
$worker-addFunction('writeLog','writeLog');while($worker-work());function writeLog($job){
$log = $job-workload();file_put_contents(__DIR__ .'/gearman.log', $log ."\n", FILE_APPEND | LOCK_EX);}
Worker使用一個while死循環(huán)實(shí)現(xiàn)守護(hù)進(jìn)程，運(yùn)行
php worker.php
可以看到Gearman狀態(tài)變?yōu)椋?/p>
writeLog ? ? ? ?001
同時查看同目錄下gearman.log，內(nèi)容應(yīng)為從Client傳入的值Log content。
通過MySQL UDF + Trigger同步數(shù)據(jù)到Gearman
MySQL要實(shí)現(xiàn)與外部程序互通的最好方式還是通過MySQL UDF（MySQL user defined functions）來實(shí)現(xiàn)。為了讓MySQL能將數(shù)據(jù)傳入Gearman，這里使用了lib_mysqludf_json和gearman-mysql-udf的組合。
安裝lib_mysqludf_json
使用lib_mysqludf_json的原因是因?yàn)镚earman只接受字符串作為入口參數(shù)，可以通過lib_mysqludf_json將MySQL中的數(shù)據(jù)編碼為JSON字符串
apt-get install libmysqlclient-dev
wget
unzip master.zip
cd lib_mysqludf_json-master/
rm lib_mysqludf_json.so
gcc $(mysql_config --cflags)-shared -fPIC -o lib_mysqludf_json.so lib_mysqludf_json.c
可以看到重新編譯生成了 lib_mysqludf_json.so 文件，此時需要查看MySQL的插件安裝路徑：
mysql -u root -pPASSWORD --execute="show variables like '%plugin%';"+---------------+------------------------+|Variable_name|Value|+---------------+------------------------+| plugin_dir ? ?|/usr/lib/mysql/plugin/|+---------------+------------------------+
然后將 lib_mysqludf_json.so 文件復(fù)制到對應(yīng)位置：
cp lib_mysqludf_json.so /usr/lib/mysql/plugin/
最后登入MySQL運(yùn)行語句注冊UDF函數(shù)：
CREATE FUNCTION json_object RETURNS STRING SONAME 'lib_mysqludf_json.so';
安裝gearman-mysql-udf
方法幾乎一樣：
apt-get install libgearman-dev
wget
tar -xzf gearman-mysql-udf-0.6.tar.gz
cd gearman-mysql-udf-0.6./configure --with-mysql=/usr/bin/mysql_config
-libdir=/usr/lib/mysql/plugin/
make make install
登入MySQL運(yùn)行語句注冊UDF函數(shù)：
CREATE FUNCTION gman_do_background RETURNS STRING SONAME 'libgearman_mysql_udf.so';
CREATE FUNCTION gman_servers_set RETURNS STRING SONAME 'libgearman_mysql_udf.so';
最后指定Gearman服務(wù)器的信息：
SELECT gman_servers_set('127.0.0.1:4730');
通過MySQL觸發(fā)器實(shí)現(xiàn)數(shù)據(jù)同步
最終同步哪些數(shù)據(jù)，同步的條件，還是需要根據(jù)實(shí)際情況決定，比如將數(shù)據(jù)表data的數(shù)據(jù)在每次更新時同步，那么編寫Trigger如下：
DELIMITER $$
CREATE TRIGGER datatoredis AFTER UPDATE ON data
FOR EACH ROW BEGIN
SET @ret=gman_do_background('syncToRedis', json_object(NEW.id as`id`, NEW.volume as`volume`));END$$
DELIMITER ;
嘗試在數(shù)據(jù)庫中更新一條數(shù)據(jù)查看Gearman是否生效。
Gearman PHP Worker將MySQL數(shù)據(jù)異步復(fù)制到Redis
Redis作為時下當(dāng)熱的NoSQL緩存解決方案無需過多介紹，其安裝及使用也非常簡單：
apt-get install redis-server
pecl install redis
echo "extension=redis.so"/etc/php5/conf.d/redis.ini
然后編寫一個Gearman Worker：redis_worker.php
#!/usr/bin/env php?
$worker =newGearmanWorker();
$worker-addServer();
$worker-addFunction('syncToRedis','syncToRedis');
$redis =newRedis();
$redis-connect('127.0.0.1',6379);while($worker-work());function syncToRedis($job){global $redis;
$workString = $job-workload();
$work = json_decode($workString);if(!isset($work-id)){returnfalse;}
$redis-set($work-id, $workString);}
最后需要將Worker在后臺運(yùn)行：
nohup php redis_worker.php
通過這種方式將MySQL數(shù)據(jù)復(fù)制到Redis，經(jīng)測試單Worker基本可以瞬時完成。
研發(fā)的同事反饋，mysql的半同步怎么變異步了？開始覺得不足為奇，超時之后，自然變成異步了。但同步binlog的速度變得正常之后，就會自動變成同步了。但抱著嚴(yán)謹(jǐn)負(fù)責(zé)的態(tài)度，馬上去檢查了一
下數(shù)據(jù)庫的日志跟半同步的狀態(tài)。
看了一下從庫的錯誤日志，被圖片中所示的sem-sync slave net_flush() reply failed 刷屏。。。。。。，汗了，這又是哪一出？? 主庫卻沒有任何日志。
雖然此時的主從同步的延遲時間是正常的，維持在0s的延遲，但此時同步狀態(tài)卻是異步的。
好奇怪呢？
查看一下代碼，該Semi-sync slave net_flush() reply failed 信息來自函數(shù)
ReplSemiSyncSlave::slaveReply，函數(shù)如下
該錯誤發(fā)生的條件就是執(zhí)行net_flush(net)函數(shù)，沒有收到正常的返回，報(bào)錯了，所以有上面的錯誤發(fā)生，該函數(shù)的作用是將從庫收到的binlog file 跟binlog pos的信息發(fā)送給主庫。
網(wǎng)絡(luò)有問題？ 即使網(wǎng)路抖動性的問題，網(wǎng)路恢復(fù)之后應(yīng)該正常才是。
為什么這個錯誤持續(xù)刷屏？ 而主從同步目前是正常的，只是由半同步變成了異步。
當(dāng)我將slave重啟之后，錯誤信息也很快就出現(xiàn)。
因?yàn)樵摵瘮?shù)是向主庫發(fā)送同步binlog的確認(rèn)信息的，也就是ack信息，難道是主庫的ack的接收線程出了問題？ 而主庫沒有任何的報(bào)錯信息 。
關(guān)鍵時刻，自己搞不定的時候，嘗試找?guī)褪?。我將錯誤信息，發(fā)給oracle公司的mysql開發(fā)者宋老師，宋老師是負(fù)責(zé)replication模塊的開發(fā)者，對replication相當(dāng)熟悉，說我可能遇上一個mysql的Bug，讓我查看一下Bug?79865?.?? 在此，非常感謝宋老師的熱情的無償援助。
bug 詳情鏈接：?
我們來看看采用了select()多路復(fù)用io模型的ack_reciver 線程的代碼：
bug的關(guān)鍵點(diǎn)是因?yàn)?ret= select(max_fd+1, fds, NULL, NULL, tv);? select()函數(shù)的入?yún)ax_fd+1有1024的限制，且這個限制無法通過修改nproc來突破？
（ulimit -n 命令可以修改nproc參數(shù)）。
貌似所有的疑問都揭開，但請繼續(xù)。
作者采用的環(huán)境是5.7.15,同時，作者采用的操作系統(tǒng)是centOS 7,? 根據(jù)上面?后半部分，Meiji Kimura 的描述信息，該bug在centos 6上復(fù)現(xiàn)了, 而在centOS7上沒有復(fù)現(xiàn)。而作者正是采用了centos 7.
Asynchronous?Replication?Automatic failover
其原理是在一條異步復(fù)制通道上配置多個可用復(fù)制源，當(dāng)某個復(fù)制源不可用時（宕機(jī)、復(fù)制鏈路中斷），且 slave 的 IO 線程嘗試重連無效，自動根據(jù)權(quán)重選擇新的源繼續(xù)同步。
準(zhǔn)備一個 MGR 集群和單實(shí)例，模擬復(fù)制鏈路切換，當(dāng) primary 故障，slave 自動切換到其他節(jié)點(diǎn)。dbdeployer?deploy?replication?--topology=group?8.0.22?--single-primarydbdeployer deploy single 8.0.22
2. 在從機(jī)上建立指向 MGR 主節(jié)點(diǎn)的復(fù)制通道，
change master to master_user='msandbox',master_password='msandbox', master_host='127.0.0.1',master_auto_position=1,source_connection_auto_failover=1,master_port=23223,master_retry_count=6,master_connect_retry=10 for channel 'mgr-single';
在 master_retry_count 和 master_connect_retry 的設(shè)置上要考慮嘗試重連多久才切換復(fù)制源。
3. 在從機(jī)上配置 asynchronous connection auto failover
配置 asynchronous connection auto failover 的兩個函數(shù)：
asynchronous_connection_failover_add_source(channel-name,host,port,network-namespace,weight)
asynchronous_connection_failover_delete_source(channel-name,host,port,network-namespace)
權(quán)重值大的被優(yōu)先級選擇，可以配合MGR的選舉權(quán)重配置 asynchronous_connection_failover 的權(quán)重。當(dāng) MGR 節(jié)點(diǎn)切換，異步復(fù)制也能切換到新的主節(jié)點(diǎn)。
SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23223,null,100); SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23224,null,80); SELECT asynchronous_connection_failover_add_source('mgr-single','127.0.0.1',23225,null,50);start?slave?for?channel?'mgr-single';
4. 檢查異步復(fù)制通道是否啟用 failover。
mysql SELECT CHANNEL_NAME, SOURCE_CONNECTION_AUTO_FAILOVER FROM performance_schema.replication_connection_configuration; +--------------+---------------------------------+| CHANNEL_NAME | SOURCE_CONNECTION_AUTO_FAILOVER |+--------------+---------------------------------+|?mgr-single?? |??1??????????????????????????????|+--------------+---------------------------------+1 row in set (0.01 sec
5. 把 MGR 的 primary 節(jié)點(diǎn) kill 掉，這個從節(jié)點(diǎn)會在嘗試幾輪重連失敗后自動切換到次權(quán)重的復(fù)制源，其日志中會輸出切換信息。
注意：當(dāng)主節(jié)點(diǎn)故障，一旦復(fù)制鏈路成功 failover 后，在新的復(fù)制鏈路沒有故障時，如果原主節(jié)點(diǎn)恢復(fù)，是不會回切的。如果當(dāng)前復(fù)制鏈路發(fā)生故障，會再次選擇權(quán)重高的進(jìn)行切換
重慶分公司
重慶分公司
