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

 　　這篇文章主要介紹了防止服務(wù)器宕機時MySQL數(shù)據(jù)丟失的幾種方案,結(jié)合實踐介紹了Replication和Monitor以及Failover這三個項目的應(yīng)用,需要的朋友可以參考下

　　對于多數(shù)應(yīng)用來說，MySQL都是作為最關(guān)鍵的數(shù)據(jù)存儲中心的，所以，如何讓MySQL提供HA服務(wù)，是我們不得不面對的一個問題。當master當機的時候，我們?nèi)绾伪ＷC數(shù)據(jù)盡可能的不丟失，如何保證快速的獲知master當機并進行相應(yīng)的故障轉(zhuǎn)移處理，都是需要我們好好思考的。這里，筆者將結(jié)合這段時間做的MySQL proxy以及toolsets相關(guān)工作，說說我們現(xiàn)階段以及后續(xù)會在項目中采用的MySQL HA方案。

　　Replication

　　要保證MySQL數(shù)據(jù)不丟失，replication是一個很好的解決方案，而MySQL也提供了一套強大的replication機制。只是我們需要知道，為了性能考量，replication是采用的asynchronous模式，也就是寫入的數(shù)據(jù)并不會同步更新到slave上面，如果這時候master當機，我們?nèi)匀豢赡軙�面臨數(shù)據(jù)丟失的風險。

　　為了解決這個問題，我們可以使用semi-synchronous replication，semi-synchronous replication的原理很簡單，當master處理完一個事務(wù)，它會等待至少一個支持semi-synchronous的slave確認收到了該事件并將其寫入relay-log之后，才會返回。這樣即使master當機，最少也有一個slave獲取到了完整的數(shù)據(jù)。

　　但是，semi-synchronous并不是100%的保證數(shù)據(jù)不會丟失，如果master在完成事務(wù)并將其發(fā)送給slave的時候崩潰，仍然可能造成數(shù)據(jù)丟失。只是相比于傳統(tǒng)的異步復(fù)制，semi-synchronous replication能極大地提升數(shù)據(jù)安全。更為重要的是，它并不慢，MHA的作者都說他們在facebook的生產(chǎn)環(huán)境中使用了semi-synchronous(這里)，所以我覺得真心沒必要擔心它的性能問題，除非你的業(yè)務(wù)量級已經(jīng)完全超越了facebook或者google。在這篇文章里面已經(jīng)提到，MySQL 5.7之后已經(jīng)使用了Loss-Less Semi-Synchronous replication，所以丟數(shù)據(jù)的概率已經(jīng)很小了。

　　如果真的想完全保證數(shù)據(jù)不會丟失，現(xiàn)階段一個比較好的辦法就是使用gelera，一個MySQL集群解決方案，它通過同時寫三份的策略來保證數(shù)據(jù)不會丟失。筆者沒有任何使用gelera的經(jīng)驗，只是知道業(yè)界已經(jīng)有公司將其用于生產(chǎn)環(huán)境中，性能應(yīng)該也不是問題。但gelera對MySQL代碼侵入性較強，可能對某些有代碼潔癖的同學(xué)來說不合適了:-)

　　我們還可以使用drbd來實現(xiàn)MySQL數(shù)據(jù)復(fù)制，MySQL官方文檔有一篇文檔有詳細介紹，但筆者并未采用這套方案，MHA的作者寫了一些采用drdb的問題，在這里，僅供參考。

　　在后續(xù)的項目中，筆者會優(yōu)先使用semi-synchronous replication的解決方案，如果數(shù)據(jù)真的非常重要，則會考慮使用gelera。

　　Monitor

　　前面我們說了使用replication機制來保證master當機之后盡可能的數(shù)據(jù)不丟失，但是我們不能等到master當了幾分鐘才知道出現(xiàn)問題了。所以一套好的監(jiān)控工具是必不可少的。

　　當master當?shù)糁���，monitor能快速的檢測到并做后續(xù)處理，譬如郵件通知管理員，或者通知守護程序快速進行failover。

　　通常，對于一個服務(wù)的監(jiān)控，我們采用keepalived或者heartbeat的方式，這樣當master當機之后，我們能很方便的切換到備機上面。但他們?nèi)匀徊荒芎芗磿r的檢測到服務(wù)不可用。筆者的公司現(xiàn)階段使用的是keepalived的方式，但后續(xù)筆者更傾向于使用zookeeper來解決整個MySQL集群的monitor以及failover。

　　對于任何一個MySQL實例，我們都有一個對應(yīng)的agent程序，agent跟該MySQL實例放到同一臺機器上面，并且定時的對MySQL實例發(fā)送ping命令檢測其可用性，同時該agent通過ephemeral的方式掛載到zookeeper上面。這樣，我們可以就能知道MySQL是否當機，主要有以下幾種情況：

　　機器當機，這樣MySQL以及agent都會當?shù)�，agent與zookeeper連接自然斷開

　　MySQL當?shù)�，agent發(fā)現(xiàn)ping不通，主動斷開與zookeeper的連接

　　Agent當?shù)�，但MySQL未當

　　上面三種情況，我們都可以認為MySQL機器出現(xiàn)了問題，并且zookeeper能夠立即感知。agent與zookeeper斷開了連接，zookeeper觸發(fā)相應(yīng)的children changed事件，監(jiān)控到該事件的管控服務(wù)就可以做相應(yīng)的處理。譬如如果是上面前兩種情況，管控服務(wù)就能自動進行failover，但如果是第三種，則可能不做處理，等待機器上面crontab或者supersivord等相關(guān)服務(wù)自動重啟agent。

　　使用zookeeper的好處在于它能很方便的對整個集群進行監(jiān)控，并能即時的獲取整個集群的變化信息并觸發(fā)相應(yīng)的事件通知感興趣的服務(wù)，同時協(xié)調(diào)多個服務(wù)進行相關(guān)處理。而這些是keepalived或者heartbeat做不到或者做起來太麻煩的。

　　使用zookeeper的問題在于部署起來較為復(fù)雜，同時如果進行了failover，如何讓應(yīng)用程序獲取到最新的數(shù)據(jù)庫地址也是一個比較麻煩的問題。

　　對于部署問題，我們要保證一個MySQL搭配一個agent，幸好這年頭有了docker，所以真心很簡單。而對于第二個數(shù)據(jù)庫地址更改的問題，其實并不是使用了zookeeper才會有的，我們可以通知應(yīng)用動態(tài)更新配置信息，VIP，或者使用proxy來解決。

　　雖然zookeeper的好處很多，但如果你的業(yè)務(wù)不復(fù)雜，譬如只有一個master，一個slave，zookeeper可能并不是最好的選擇，沒準keepalived就夠了。

　　Failover

　　通過monitor，我們可以很方便的進行MySQL監(jiān)控，同時在MySQL當機之后通知相應(yīng)的服務(wù)做failover處理，假設(shè)現(xiàn)在有這樣的一個MySQL集群，a為master，b，c為其slave，當a當?shù)糁���，我們需要做failover，那么我們選擇b，c中的哪一個作為新的master呢?

　　原則很簡單，哪一個slave擁有最近最多的原master數(shù)據(jù)，就選哪一個作為新的master。我們可以通過show slave status這個命令來獲知哪一個slave擁有最新的數(shù)據(jù)。我們只需要比較兩個關(guān)鍵字段Master_Log_File以及Read_Master_Log_Pos，這兩個值代表了slave讀取到master哪一個binlog文件的哪一個位置，binlog的索引值越大，同時pos越大，則那一個slave就是能被提升為master。這里我們不討論多個slave可能會被提升為master的情況。

　　在前面的例子中，假設(shè)b被提升為master了，我們需要將c重新指向新的master b來開始復(fù)制。我們通過CHANGE MASTER TO來重新設(shè)置c的master，但是我們怎么知道要從b的binlog的哪一個文件，哪一個position開始復(fù)制呢?

　　GTID

分享：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ù)庫load 報警異常，cpu usr 達到30-40 ，居高不下。使用工具查看數(shù)據(jù)庫正在執(zhí)行的sql ，排在前面的大部分是：