這篇文章主要介紹了防止服務器宕機時MySQL數據丟失的幾種方案,結合實踐介紹了Replication和Monitor以及Failover這三個項目的應用,需要的朋友可以參考下。
對於多數應用來說，MySQL都是作為最關鍵的數據存儲中心的，所以，如何讓MySQL提供HA服務，是我們不得不面對的一個問題。當master 當機的時候，我們如何保證數據盡可能的不丟失，如何保證快速的獲知master當機並進行相應的故障轉移處理，都是需要我們好好思考的。這裡，筆者將結合這段時間做的MySQL proxy以及toolsets相關工作，說說我們現階段以及後續會在項目中采用的MySQL HA方案。
Replication
要保證MySQL數據不丟失，replication是一個很好的解決方案，而MySQL也提供了一套強大的replication機制。只是我們需要知道，為了性能考量，replication是采用的asynchronous模式，也就是寫入的數據並不會同步更新到slave上面，如果這時候master當機，我們仍然可能會面臨數據丟失的風險。
為了解決這個問題，我們可以使用semi-synchronous replication，semi-synchronous replication的原理很簡單，當master處理完一個事務，它會等待至少一個支持semi-synchronous的slave確認收到了該事件並將其寫入relay-log之後，才會返回。這樣即使master當機，最少也有一個slave獲取到了完整的數據。
但是，semi-synchronous並不是100%的保證數據不會丟失，如果master在完成事務並將其發送給slave的時候崩潰，仍然可能造成數據丟失。只是相比於傳統的異步復制，semi-synchronous replication能極大地提升數據安全。更為重要的是，它並不慢，MHA的作者都說他們在facebook的生產環境中使用了semi- synchronous這裡），所以我覺得真心沒必要擔心它的性能問題，除非你的業務量級已經完全超越了facebook或者google。在這篇文章裡面已經提到，MySQL 5.7之後已經使用了Loss-Less Semi-Synchronous replication，所以丟數據的概率已經很小了。
如果真的想完全保證數據不會丟失，現階段一個比較好的辦法就是使用gelera，一個MySQL集群解決方案，它通過同時寫三份的策略來保證數據不會丟失。筆者沒有任何使用gelera的經驗，只是知道業界已經有公司將其用於生產環境中，性能應該也不是問題。但gelera對MySQL代碼侵入性較強，可能對某些有代碼潔癖的同學來說不合適了:-)
我們還可以使用drbd來實現MySQL數據復制，MySQL官方文檔有一篇文檔有詳細介紹，但筆者並未采用這套方案，MHA的作者寫了一些采用drdb的問題，在這裡，僅供參考。
在後續的項目中，筆者會優先使用semi-synchronous replication的解決方案，如果數據真的非常重要，則會考慮使用gelera。
Monitor
前面我們說了使用replication機制來保證master當機之後盡可能的數據不丟失，但是我們不能等到master當了幾分鐘才知道出現問題了。所以一套好的監控工具是必不可少的。
當master當掉之後，monitor能快速的檢測到並做後續處理，譬如郵件通知管理員，或者通知守護程序快速進行failover。
通常，對於一個服務的監控，我們采用keepalived或者heartbeat的方式，這樣當master當機之後，我們能很方便的切換到備機上面。但他們仍然不能很即時的檢測到服務不可用。筆者的公司現階段使用的是keepalived的方式，但後續筆者更傾向於使用zookeeper來解決整個MySQL集群的monitor以及failover。
對於任何一個MySQL實例，我們都有一個對應的agent程序，agent跟該MySQL實例放到同一台機器上面，並且定時的對MySQL實例發送ping命令檢測其可用性，同時該agent通過ephemeral的方式掛載到zookeeper上面。這樣，我們可以就能知道MySQL是否當機，主要有以下幾種情況：
上面三種情況，我們都可以認為MySQL機器出現了問題，並且zookeeper能夠立即感知。agent與zookeeper斷開了連接，zookeeper觸發相應的children changed事件，監控到該事件的管控服務就可以做相應的處理。譬如如果是上面前兩種情況，管控服務就能自動進行failover，但如果是第三種，則可能不做處理，等待機器上面crontab或者supersivord等相關服務自動重啟agent。
使用zookeeper的好處在於它能很方便的對整個集群進行監控，並能即時的獲取整個集群的變化信息並觸發相應的事件通知感興趣的服務，同時協調多個服務進行相關處理。而這些是keepalived或者heartbeat做不到或者做起來太麻煩的。
使用zookeeper的問題在於部署起來較為復雜，同時如果進行了failover，如何讓應用程序獲取到最新的數據庫地址也是一個比較麻煩的問題。
對於部署問題，我們要保證一個MySQL搭配一個agent，幸好這年頭有了docker，所以真心很簡單。而對於第二個數據庫地址更改的問題，其實並不是使用了zookeeper才會有的，我們可以通知應用動態更新配置信息，VIP，或者使用proxy來解決。
雖然zookeeper的好處很多，但如果你的業務不復雜，譬如只有一個master，一個slave，zookeeper可能並不是最好的選擇，沒准keepalived就夠了。
