避免辦事器宕機時MySQL數據喪失的幾種計劃。本站提示廣大學習愛好者：（避免辦事器宕機時MySQL數據喪失的幾種計劃）文章只能為提供參考，不一定能成為您想要的結果。以下是避免辦事器宕機時MySQL數據喪失的幾種計劃正文
關於多半運用來講，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或許谷歌。在這篇文章外面曾經提到，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就夠了。
Failover
經由過程monitor，我們可以很便利的停止MySQL監控，同時在MySQL當機以後告訴響應的辦事做failover處置，假定如今有如許的一個MySQL集群，a為master，b，c為其slave，當a當失落以後，我們須要做failover，那末我們選擇b，c中的哪個作為新的master呢？
准繩很簡略，哪個slave具有比來最多的原master數據，就選哪個作為新的master。我們可以經由過程show slave status這個敕令來獲知哪個slave具有最新的數據。我們只須要比擬兩個症結字段Master_Log_File和Read_Master_Log_Pos，這兩個值代表了slave讀取到master哪個binlog文件的哪個地位，binlog的索引值越年夜，同時pos越年夜，則那一個slave就是能被晉升為master。這裡我們不評論辯論多個slave能夠會被晉升為master的情形。
在後面的例子中，假定b被晉升為master了，我們須要將c從新指向新的master b來開端復制。我們經由過程CHANGE MASTER TO來從新設置c的master，然則我們怎樣曉得要從b的binlog的哪個文件，哪個position開端復制呢？
GTID
為懂得決這一個成績，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，要便利太多了。
谷歌很早也有了一個Global Transaction ID的補釘，不外只是應用的一個遞增的整形，LedisDB就自創了它的思緒來完成failover，只不外谷歌貌似如今也開端慢慢遷徙到MariaDB下面去了。
MariaDB的GTID完成跟MySQL 5.6是紛歧樣的，這點其實比擬費事，關於我的MySQL對象集go-mysql來講，意味著要寫兩套分歧的代碼來處置GTID的情形了。後續能否支撐MariaDB再看情形吧。
Pseudo GTID
GTID固然是一個好器械，然則僅限於MySQL 5.6+，以後依然有年夜部門的營業應用的是5.6之前的版本，筆者的公司就是5.5的，而這些數據庫至多長時光也不會進級到5.6的。所以我們依然須要一套好的機制來選擇master binlog的filename和position。
最後，筆者盤算研討MHA的完成，它采取的是起首復制relay log來補足缺掉的event的方法，但筆者不怎樣信賴relay log，同時加上MHA采取的是perl，一個讓我完整看不懂的說話，所以廢棄了持續研討。
榮幸的是，筆者碰到了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下面創立了一個事宜，每隔10s，就將一個uuid寫入到一個view外面，而這個是會記載到binlog中的，固然我們依然不克不及像GTID那樣直接定位到一個event，但也能定位到一個10s的區間了，如許我們就可以在很小的一個區間外面比較兩個MySQL的binlog了。
持續下面的例子，假定c最初一次湧現uuid的地位為s1，我們在b外面找到該uuid，地位為s2，然後順次比較後續的event，假如紛歧致，則能夠湧現了成績，停滯復制。當遍歷到c最初一個binlog event以後，我們就可以獲得此時b下一個event對應的filename和position了，然後讓c指向這個地位開端復制。
應用Pseudo GTID須要slave翻開log-slave-update的選項，斟酌到GTID也必需翻開該選項，所以小我感到完整可以接收。
後續，筆者本身完成的failover對象，將會采取這類Pseudo GTID的方法完成。
在《MySQL High Availability》這本書中，作者應用了另外一種GTID的做法，每次commit的時刻，須要在一個內外面記載gtid，然後就經由過程這個gtid來找到對應的地位信息，只是這類方法須要營業MySQL客戶真個支撐，筆者不很愛好，就不采取了。
跋文
MySQL HA一向是一個水比擬深的范疇，筆者僅僅列出了一些比來研討的器械，有些相干對象會盡可能在go-mysql中完成。
更新
經由一段時光的思慮與研討，筆者又有了許多心得與收成，設計的MySQL HA跟先前有了許多紛歧樣的處所。後來發明，本身設計的這套HA計劃，跟facebook這篇文章簡直一樣，加上比來跟facebook的人聊天聽到他們也正在年夜力實行，所以感到本身偏向是對了。
新的HA，我會完整擁抱GTID，比擬這玩意的湧現就是為懂得決本來replication那一堆成績的，所以我不會斟酌非GTID的低版本MySQL了。榮幸的是，我們項目曾經將MySQL全體進級到5.6，完整支撐GTID了。
分歧於fb那篇文章將mysqlbinlog改革支撐semi-sync replication協定，我是將go-mysql的replication庫支撐semi-sync replication協定，如許就可以及時的將MySQL的binlog同步到一台機械下面。這能夠就是我和fb計劃的獨一差別了。
只同步binlog速度鐵定比原生slave要快，究竟少了履行binlog外面event的進程了，而別的真實的slaves，我們依然應用最原始的同步方法，不應用semi-sync replication。然後我們經由過程MHA監控全部集群和停止毛病轉移處置。
之前我總以為MHA欠好懂得，但其實這是一個異常壯大的對象，並且真正看perl，發明也照樣看的理解。MHA曾經被許多公司用於臨盆情況，禁受了磨練，直接應用相對比本身寫一個要劃算。所今後續我也不會斟酌zookeeper，斟酌本身寫agent了。
