如何有效防止數(shù)據(jù)中心系統(tǒng)宕機

這篇文章主要介紹了防止服務器宕機時MySQL數(shù)據(jù)丟失的幾種方案,結(jié)合實踐介紹了Replication和Monitor以及Failover這三個項目的應用,需要的朋友可以參考下對于多數(shù)應用來說，MySQL都是作為最關鍵的數(shù)據(jù)存儲中心的，所以，如何讓MySQL提供HA服務，是我們不得不面對的一個問題。當master當機的時候，我們?nèi)绾伪ＷC數(shù)據(jù)盡可能的不丟失，如何保證快速的獲知master當機并進行相應的故障轉(zhuǎn)移處理，都是需要我們好好思考的。這里，筆者將結(jié)合這段時間做的MySQL proxy以及toolsets相關工作，說說我們現(xiàn)階段以及后續(xù)會在項目中采用的MySQL HA方案。Replication要保證MySQL數(shù)據(jù)不丟失，replication是一個很好的解決方案，而MySQL也提供了一套強大的replication機制。只是我們需要知道，為了性能考量，replication是采用的asynchronous模式，也就是寫入的數(shù)據(jù)并不會同步更新到slave上面，如果這時候master當機，我們?nèi)匀豢赡軙媾R數(shù)據(jù)丟失的風險。為了解決這個問題，我們可以使用semi-synchronous replication，semi-synchronous replication的原理很簡單，當master處理完一個事務，它會等待至少一個支持semi-synchronous的slave確認收到了該事件并將其寫入relay-log之后，才會返回。這樣即使master當機，最少也有一個slave獲取到了完整的數(shù)據(jù)。但是，semi-synchronous并不是100%的保證數(shù)據(jù)不會丟失，如果master在完成事務并將其發(fā)送給slave的時候崩潰，仍然可能造成數(shù)據(jù)丟失。只是相比于傳統(tǒng)的異步復制，semi-synchronous replication能極大地提升數(shù)據(jù)安全。更為重要的是，它并不慢，MHA的作者都說他們在facebook的生產(chǎn)環(huán)境中使用了semi-synchronous(這里)，所以我覺得真心沒必要擔心它的性能問題，除非你的業(yè)務量級已經(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)境中，性能應該也不是問題。但gelera對MySQL代碼侵入性較強，可能對某些有代碼潔癖的同學來說不合適了:-)我們還可以使用drbd來實現(xiàn)MySQL數(shù)據(jù)復制，MySQL官方文檔有一篇文檔有詳細介紹，但筆者并未采用這套方案，MHA的作者寫了一些采用drdb的問題，在這里，僅供參考。在后續(xù)的項目中，筆者會優(yōu)先使用semi-synchronous replication的解決方案，如果數(shù)據(jù)真的非常重要，則會考慮使用gelera。Monitor前面我們說了使用replication機制來保證master當機之后盡可能的數(shù)據(jù)不丟失，但是我們不能等到master當了幾分鐘才知道出現(xiàn)問題了。所以一套好的監(jiān)控工具是必不可少的。當master當?shù)糁螅琺onitor能快速的檢測到并做后續(xù)處理，譬如郵件通知管理員，或者通知守護程序快速進行failover。通常，對于一個服務的監(jiān)控，我們采用keepalived或者heartbeat的方式，這樣當master當機之后，我們能很方便的切換到備機上面。但他們?nèi)匀徊荒芎芗磿r的檢測到服務不可用。筆者的公司現(xiàn)階段使用的是keepalived的方式，但后續(xù)筆者更傾向于使用zookeeper來解決整個MySQL集群的monitor以及failover。對于任何一個MySQL實例，我們都有一個對應的agent程序，agent跟該MySQL實例放到同一臺機器上面，并且定時的對MySQL實例發(fā)送ping命令檢測其可用性，同時該agent通過ephemeral的方式掛載到zookeeper上面。這樣，我們可以就能知道MySQL是否當機，主要有以下幾種情況：機器當機，這樣MySQL以及agent都會當?shù)簦琣gent與zookeeper連接自然斷開MySQL當?shù)簦琣gent發(fā)現(xiàn)ping不通，主動斷開與zookeeper的連接Agent當?shù)簦玀ySQL未當上面三種情況，我們都可以認為MySQL機器出現(xiàn)了問題，并且zookeeper能夠立即感知。agent與zookeeper斷開了連接，zookeeper觸發(fā)相應的children changed事件，監(jiān)控到該事件的管控服務就可以做相應的處理。譬如如果是上面前兩種情況，管控服務就能自動進行failover，但如果是第三種，則可能不做處理，等待機器上面crontab或者supersivord等相關服務自動重啟agent。使用zookeeper的好處在于它能很方便的對整個集群進行監(jiān)控，并能即時的獲取整個集群的變化信息并觸發(fā)相應的事件通知感興趣的服務，同時協(xié)調(diào)多個服務進行相關處理。而這些是keepalived或者heartbeat做不到或者做起來太麻煩的。使用zookeeper的問題在于部署起來較為復雜，同時如果進行了failover，如何讓應用程序獲取到最新的數(shù)據(jù)庫地址也是一個比較麻煩的問題。對于部署問題，我們要保證一個MySQL搭配一個agent，幸好這年頭有了docker，所以真心很簡單。而對于第二個數(shù)據(jù)庫地址更改的問題，其實并不是使用了zookeeper才會有的，我們可以通知應用動態(tài)更新配置信息，VIP，或者使用proxy來解決。雖然zookeeper的好處很多，但如果你的業(yè)務不復雜，譬如只有一個master，一個slave，zookeeper可能并不是最好的選擇，沒準keepalived就夠了。Failover通過monitor，我們可以很方便的進行MySQL監(jiān)控，同時在MySQL當機之后通知相應的服務做failover處理，假設現(xiàn)在有這樣的一個MySQL集群，a為master，b，c為其slave，當a當?shù)糁螅覀冃枰鰂ailover，那么我們選擇b，c中的哪一個作為新的master呢?原則很簡單，哪一個slave擁有最近最多的原master數(shù)據(jù)，就選哪一個作為新的master。我們可以通過show slave status這個命令來獲知哪一個slave擁有最新的數(shù)據(jù)。我們只需要比較兩個關鍵字段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，要方便太多了。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 GTIDGTID雖然是一個好東西，但是僅限于MySQL 5.6+，當前仍然有大部分的業(yè)務使用的是5.6之前的版本，筆者的公司就是5.5的，而這些數(shù)據(jù)庫至少長時間也不會升級到5.6的。所以我們?nèi)匀恍枰惶缀玫臋C制來選擇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 existsmeta.create_pseudo_gtid_view_eventon schedule every 10 second starts current_timestampon completion preserveenabledobeginset @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)匀皇褂米钤嫉耐椒绞剑皇褂胹emi-sync replication。然后我們通過MHA監(jiān)控整個集群以及進行故障轉(zhuǎn)移處理。以前我總認為MHA不好理解，但其實這是一個非常強大的工具，而且真正看perl，發(fā)現(xiàn)也還是看的懂得。MHA已經(jīng)被很多公司用于生產(chǎn)環(huán)境，經(jīng)受了檢驗，直接使用絕對比自己寫一個要劃算。所以后續(xù)我也不會考慮zookeeper，考慮自己寫agent了。

南溪網(wǎng)站建設公司創(chuàng)新互聯(lián)建站,南溪網(wǎng)站設計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為南溪上1000+提供企業(yè)網(wǎng)站建設服務。企業(yè)網(wǎng)站搭建\外貿(mào)營銷網(wǎng)站建設要多少錢，請找那個售后服務好的南溪做網(wǎng)站的公司定做！

MySQL一主多從的環(huán)境下，如果主宕機了怎么辦？如何把損失降到最小？

1、需要對MYSQL定時備份

2、應用中交換數(shù)據(jù)時，要判斷是否聯(lián)網(wǎng)，如果不聯(lián)網(wǎng)就把信息先保存在本地，等聯(lián)網(wǎng)后再

與MYSQL數(shù)據(jù)同步。

3、應用中注意使用事務

五大常見的MySQL高可用方案(最全)

1. 概述

我們在考慮MySQL數(shù)據(jù)庫的高可用的架構(gòu)時，主要要考慮如下幾方面：

如果數(shù)據(jù)庫發(fā)生了宕機或者意外中斷等故障，能盡快恢復數(shù)據(jù)庫的可用性，盡可能的減少停機時間，保證業(yè)務不會因為數(shù)據(jù)庫的故障而中斷。

用作備份、只讀副本等功能的非主節(jié)點的數(shù)據(jù)應該和主節(jié)點的數(shù)據(jù)實時或者最終保持一致。

當業(yè)務發(fā)生數(shù)據(jù)庫切換時，切換前后的數(shù)據(jù)庫內(nèi)容應當一致，不會因為數(shù)據(jù)缺失或者數(shù)據(jù)不一致而影響業(yè)務。

關于對高可用的分級在這里我們不做詳細的討論，這里只討論常用高可用方案的優(yōu)缺點以及高可用方案的選型。

2. 高可用方案

2.1. 主從或主主半同步復制

使用雙節(jié)點數(shù)據(jù)庫，搭建單向或者雙向的半同步復制。在5.7以后的版本中，由于lossless replication、logical多線程復制等一些列新特性的引入，使得MySQL原生半同步復制更加可靠。

常見架構(gòu)如下：

通常會和proxy、keepalived等第三方軟件同時使用，即可以用來監(jiān)控數(shù)據(jù)庫的 健康 ，又可以執(zhí)行一系列管理命令。如果主庫發(fā)生故障，切換到備庫后仍然可以繼續(xù)使用數(shù)據(jù)庫。

優(yōu)點：

架構(gòu)比較簡單，使用原生半同步復制作為數(shù)據(jù)同步的依據(jù)；

雙節(jié)點，沒有主機宕機后的選主問題，直接切換即可；

雙節(jié)點，需求資源少，部署簡單；

缺點：

完全依賴于半同步復制，如果半同步復制退化為異步復制，數(shù)據(jù)一致性無法得到保證；

需要額外考慮haproxy、keepalived的高可用機制。

2.2. 半同步復制優(yōu)化

半同步復制機制是可靠的。如果半同步復制一直是生效的，那么便可以認為數(shù)據(jù)是一致的。但是由于網(wǎng)絡波動等一些客觀原因，導致半同步復制發(fā)生超時而切換為異步復制，那么這時便不能保證數(shù)據(jù)的一致性。所以盡可能的保證半同步復制，便可提高數(shù)據(jù)的一致性。

該方案同樣使用雙節(jié)點架構(gòu)，但是在原有半同復制的基礎上做了功能上的優(yōu)化，使半同步復制的機制變得更加可靠。

可參考的優(yōu)化方案如下：

2.2.1. 雙通道復制

半同步復制由于發(fā)生超時后，復制斷開，當再次建立起復制時，同時建立兩條通道，其中一條半同步復制通道從當前位置開始復制，保證從機知道當前主機執(zhí)行的進度。另外一條異步復制通道開始追補從機落后的數(shù)據(jù)。當異步復制通道追趕到半同步復制的起始位置時，恢復半同步復制。

2.2.2. binlog文件服務器

搭建兩條半同步復制通道，其中連接文件服務器的半同步通道正常情況下不啟用，當主從的半同步復制發(fā)生網(wǎng)絡問題退化后，啟動與文件服務器的半同步復制通道。當主從半同步復制恢復后，關閉與文件服務器的半同步復制通道。

優(yōu)點：

雙節(jié)點，需求資源少，部署簡單；

架構(gòu)簡單，沒有選主的問題，直接切換即可;

相比于原生復制，優(yōu)化后的半同步復制更能保證數(shù)據(jù)的一致性。

缺點：

需要修改內(nèi)核源碼或者使用mysql通信協(xié)議。需要對源碼有一定的了解，并能做一定程度的二次開發(fā)。

依舊依賴于半同步復制，沒有從根本上解決數(shù)據(jù)一致性問題。

2.3. 高可用架構(gòu)優(yōu)化

將雙節(jié)點數(shù)據(jù)庫擴展到多節(jié)點數(shù)據(jù)庫，或者多節(jié)點數(shù)據(jù)庫集群。可以根據(jù)自己的需要選擇一主兩從、一主多從或者多主多從的集群。

由于半同步復制，存在接收到一個從機的成功應答即認為半同步復制成功的特性，所以多從半同步復制的可靠性要優(yōu)于單從半同步復制的可靠性。并且多節(jié)點同時宕機的幾率也要小于單節(jié)點宕機的幾率，所以多節(jié)點架構(gòu)在一定程度上可以認為高可用性是好于雙節(jié)點架構(gòu)。

但是由于數(shù)據(jù)庫數(shù)量較多，所以需要數(shù)據(jù)庫管理軟件來保證數(shù)據(jù)庫的可維護性。可以選擇MMM、MHA或者各個版本的proxy等等。常見方案如下：

2.3.1. MHA+多節(jié)點集群

MHA Manager會定時探測集群中的master節(jié)點，當master出現(xiàn)故障時，它可以自動將最新數(shù)據(jù)的slave提升為新的master，然后將所有其他的slave重新指向新的master，整個故障轉(zhuǎn)移過程對應用程序完全透明。

MHA Node運行在每臺MySQL服務器上，主要作用是切換時處理二進制日志，確保切換盡量少丟數(shù)據(jù)。

MHA也可以擴展到如下的多節(jié)點集群：

優(yōu)點：

可以進行故障的自動檢測和轉(zhuǎn)移;

可擴展性較好，可以根據(jù)需要擴展MySQL的節(jié)點數(shù)量和結(jié)構(gòu);

相比于雙節(jié)點的MySQL復制，三節(jié)點/多節(jié)點的MySQL發(fā)生不可用的概率更低

缺點：

至少需要三節(jié)點，相對于雙節(jié)點需要更多的資源;

邏輯較為復雜，發(fā)生故障后排查問題，定位問題更加困難;

數(shù)據(jù)一致性仍然靠原生半同步復制保證，仍然存在數(shù)據(jù)不一致的風險;

可能因為網(wǎng)絡分區(qū)發(fā)生腦裂現(xiàn)象;

2.3.2. zookeeper+proxy

Zookeeper使用分布式算法保證集群數(shù)據(jù)的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網(wǎng)絡分區(qū)現(xiàn)象的產(chǎn)生。

優(yōu)點：

較好的保證了整個系統(tǒng)的高可用性，包括proxy、MySQL;

擴展性較好，可以擴展為大規(guī)模集群;

缺點：

數(shù)據(jù)一致性仍然依賴于原生的mysql半同步復制;

引入zk，整個系統(tǒng)的邏輯變得更加復雜;

2.4. 共享存儲

共享存儲實現(xiàn)了數(shù)據(jù)庫服務器和存儲設備的解耦，不同數(shù)據(jù)庫之間的數(shù)據(jù)同步不再依賴于MySQL的原生復制功能，而是通過磁盤數(shù)據(jù)同步的手段，來保證數(shù)據(jù)的一致性。

2.4.1. SAN共享儲存

SAN的概念是允許存儲設備和處理器（服務器）之間建立直接的高速網(wǎng)絡（與LAN相比）連接，通過這種連接實現(xiàn)數(shù)據(jù)的集中式存儲。常用架構(gòu)如下：

使用共享存儲時，MySQL服務器能夠正常掛載文件系統(tǒng)并操作，如果主庫發(fā)生宕機，備庫可以掛載相同的文件系統(tǒng)，保證主庫和備庫使用相同的數(shù)據(jù)。

優(yōu)點：

兩節(jié)點即可，部署簡單，切換邏輯簡單；

很好的保證數(shù)據(jù)的強一致性；

不會因為MySQL的邏輯錯誤發(fā)生數(shù)據(jù)不一致的情況；

缺點：

需要考慮共享存儲的高可用；

價格昂貴；

2.4.2. DRBD磁盤復制

DRBD是一種基于軟件、基于網(wǎng)絡的塊復制存儲解決方案，主要用于對服務器之間的磁盤、分區(qū)、邏輯卷等進行數(shù)據(jù)鏡像，當用戶將數(shù)據(jù)寫入本地磁盤時，還會將數(shù)據(jù)發(fā)送到網(wǎng)絡中另一臺主機的磁盤上，這樣的本地主機(主節(jié)點)與遠程主機(備節(jié)點)的數(shù)據(jù)就可以保證實時同步。常用架構(gòu)如下：

當本地主機出現(xiàn)問題，遠程主機上還保留著一份相同的數(shù)據(jù)，可以繼續(xù)使用，保證了數(shù)據(jù)的安全。

DRBD是linux內(nèi)核模塊實現(xiàn)的快級別的同步復制技術(shù)，可以與SAN達到相同的共享存儲效果。

優(yōu)點：

兩節(jié)點即可，部署簡單，切換邏輯簡單；

相比于SAN儲存網(wǎng)絡，價格低廉；

保證數(shù)據(jù)的強一致性；

缺點：

對io性能影響較大；

從庫不提供讀操作；

2.5. 分布式協(xié)議

分布式協(xié)議可以很好解決數(shù)據(jù)一致性問題。比較常見的方案如下：

2.5.1. MySQL cluster

MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗余數(shù)據(jù)，實現(xiàn)數(shù)據(jù)庫的高可用性和數(shù)據(jù)一致性。

優(yōu)點：

全部使用官方組件，不依賴于第三方軟件；

可以實現(xiàn)數(shù)據(jù)的強一致性；

缺點：

國內(nèi)使用的較少；

配置較復雜，需要使用NDB儲存引擎，與MySQL常規(guī)引擎存在一定差異；

至少三節(jié)點；

2.5.2. Galera

基于Galera的MySQL高可用集群， 是多主數(shù)據(jù)同步的MySQL集群解決方案，使用簡單，沒有單點故障，可用性高。常見架構(gòu)如下：

優(yōu)點：

多主寫入，無延遲復制，能保證數(shù)據(jù)強一致性；

有成熟的社區(qū)，有互聯(lián)網(wǎng)公司在大規(guī)模的使用；

自動故障轉(zhuǎn)移，自動添加、剔除節(jié)點；

缺點：

需要為原生MySQL節(jié)點打wsrep補丁

只支持innodb儲存引擎

至少三節(jié)點；

2.5.3. POAXS

Paxos 算法解決的問題是一個分布式系統(tǒng)如何就某個值（決議）達成一致。這個算法被認為是同類算法中最有效的。Paxos與MySQL相結(jié)合可以實現(xiàn)在分布式的MySQL數(shù)據(jù)的強一致性。常見架構(gòu)如下：

優(yōu)點：

多主寫入，無延遲復制，能保證數(shù)據(jù)強一致性；

有成熟理論基礎；

自動故障轉(zhuǎn)移，自動添加、剔除節(jié)點；

缺點：

只支持innodb儲存引擎

至少三節(jié)點；

3. 總結(jié)

隨著人們對數(shù)據(jù)一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數(shù)據(jù)一致性的問題，如MySQL自身的優(yōu)化、MySQL集群架構(gòu)的優(yōu)化、Paxos、Raft、2PC算法的引入等等。

而使用分布式算法用來解決MySQL數(shù)據(jù)庫數(shù)據(jù)一致性的問題的方法，也越來越被人們所接受，一系列成熟的產(chǎn)品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規(guī)模使用。

隨著官方MySQL Group Replication的GA，使用分布式協(xié)議來解決數(shù)據(jù)一致性問題已經(jīng)成為了主流的方向。期望越來越多優(yōu)秀的解決方案被提出，MySQL高可用問題可以被更好的解決。

新聞標題：怎么保證mysql不宕機 mysql主從宕機恢復
網(wǎng)頁鏈接：http://chinadenli.net/article2/hgdoic.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供關鍵詞優(yōu)化、動態(tài)網(wǎng)站、企業(yè)網(wǎng)站制作、網(wǎng)站設計公司、小程序開發(fā)、網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)