數據一致性-分區可用性-性能——多副本強同步數據庫系統實現之我見

轉載：http://hedengcheng.com/?p=892

1    背景    1

2    問題一：數據一致性    3

3    問題二：分區可用性    6

4    問題三：性能    8

5    總結    10

6    問題四：一個極端場景的分析    10

 

1. 背景

 

最近，@阿里正祥（陽老師）發了上面的一條微博，誰知一石激起千層浪，國內各路數據庫領域的朋友在此條微博上發散出無數新的話題，爭吵有之，激辯有之，抨擊有之，不一而足。整體來講，你們重點關注其中的一點：

在不使用共享存儲的狀況下，傳統RDBMS（例如：Oracle/MySQL/PostgreSQL等），可否作到在主庫出問題時的數據零丟失。

這個話題被引爆以後，咱們團隊內部也通過了激烈的辯論，多方各執一詞。辯論的過程當中，差點就重現了烏克蘭議會時場景…

慶幸的是，在個人鐵腕統治之下，同窗們仍是保持着只關注技術，就事論事的撕逼氛圍，沒有上升到相互人身***的層次。激辯的結果，確實是收穫滿滿，當時我就當即發了一條微博，宣泄一下本身愉悅的心情J

微博發出以後，也有一些朋友回覆是否能夠將激辯的內容寫出來，獨樂樂不如衆樂樂。我一想也對，強數據同步，數據一致性，性能，分區可用性，Paxos，Raft，CAP等一系列知識，我也是第一次可以較好的組織起來，寫下來，一來能夠加深本身的印象，二來也能夠再多混一點虛名，何樂而不爲J

這篇博客文章接下來的部分，將跳出任何一種數據庫，從原理的角度上來分析下面的幾個問題：

• 問題一：數據一致性。在不使用共享存儲的狀況下，傳統RDBMS（例如：Oracle/MySQL/PostgreSQL等），可否作到在主庫出問題時的數據零丟失。
  

• 問題二：分區可用性。有多個副本的數據庫，怎麼在出現各類問題時保證系統的持續可用？
  

• 問題三：性能。不使用共享存儲的RDBMS，爲了保證多個副本間的數據一致性，是否會損失性能？如何將性能的損失降到最低？
  

• 問題四：一個極端場景的分析。

• 
  

1. 問題一：數據一致性

 

問：脫離了共享存儲，傳統關係型數據庫就沒法作到主備強一致嗎？

答：個人答案，是No。哪怕不用共享存儲，任何數據庫，也均可以作到主備數據的強一致。Oracle如此，MySQL如此，PostgreSQL如此，OceanBase也如此。

如何實現主備強一致？你們都知道數據庫中最重要的一個技術：WAL（Write-Ahead-Logging）。更新操做寫日誌（Oracle Redo Log，MySQL Binlog等），事務提交時，保證將事務產生的日誌先刷到磁盤上，保證整個事務的更新操做數據不丟失。那實現數據庫主備數據強一致的方法也很簡單：

1. 事務提交的時候，同時發起兩個寫日誌操做，一個是將日誌寫到本地磁盤的操做，另外一個是將日誌同步到備庫而且確保落盤的操做；
   

2. 主庫此時等待兩個操做所有成功返回以後，才返回給應用方，事務提交成功；
   

整個事務提交操做的邏輯，以下圖所示：

上圖所示，因爲事務提交操做返回給應用時，事務產生的日誌在主備兩個數據庫上都已經存在了，強同步。所以，此時主庫Crash的話，備庫提供服務，其數據與主庫是一致的，沒有任何事務的數據丟失問題。主備數據強一致實現。用過Oracle的朋友，應該都知道Oracle的Data Guard，可工做在 最大性能，最大可用，最大保護 三種模式下，其中第三種 最大保護 模式，採用的就是上圖中的基本思路。

實現數據的強同步實現以後，接下來到了考慮可用性問題。如今已經有主備兩個數據徹底一致的數據庫，備庫存在的主要意義，就是在主庫出故障時，可以接管應用的請求，確保整個數據庫可以持續的提供服務：主庫Crash，備庫提高爲主庫，對外提供服務。此時，又涉及到一個決策的問題，主備切換這個操做誰來作？人固然能夠作，接收到主庫崩潰的報警，手動將備庫切換爲主庫。可是，手動的效率是低下的，更別提數據庫可能會隨時崩潰，所有讓人來處理，也不夠厚道。一個HA（High Availability）檢測工具應運而生：HA工具通常部署在第三臺服務器上，同時鏈接主備，當其檢測到主庫沒法鏈接，就切換備庫，很簡單的處理邏輯，以下圖所示：

HA軟件與主備同時鏈接，而且有定時的心跳檢測。主庫Crash後，HA探測到，發起一個將備庫提高爲主庫的操做（修改備庫的VIP或者是DNS，可能還須要將備庫激活等一系列操做），新的主庫提供對外服務。此時，因爲主備的數據是經過日誌強同步的，所以並無數據丟失，數據一致性獲得了保障。

有了基於日誌的數據強同步，有了主備自動切換的HA軟件，是否是就一切萬事大吉了？我很想說是，確實這個架構已經可以解決90%以上的問題，可是這個架構在某些狀況下，也埋下了幾個比較大的問題。

首先，一個一目瞭然的問題，主庫Crash，備庫提高爲主庫以後，此時的數據庫是一個單點，原主庫重啓的這段時間，單點問題一直存在。若是這個時候，新的存儲再次Crash，整個系統就處於不可用狀態。此問題，能夠經過增長更多副本，更多備庫的方式解決，例如3副本（一主兩備），此處略過不表。

其次，在主備環境下，處理主庫掛的問題，算是比較簡單的，決策簡單：主庫Crash，切換備庫。可是，若是不是主庫Crash，而是網絡發生了一些問題，以下圖所示：

若Master與Slave之間的網絡出現問題，例如：斷網，網絡抖動等。此時數據庫應該怎麼辦？Master繼續提供服務？Slave沒有同步日誌，會數據丟失。Master不提供服務？應用不可用。在Oracle中，若是設置爲 最大可用 模式，則此時仍舊提供服務，容許數據不一致；若是設置爲 最大保護 模式，則Master不提供服務。所以，在Oracle中，若是設置爲 最大保護 模式，通常建議設置兩個或以上的Slave，任何一個Slave日誌同步成功，Master就繼續提供服務，提供系統的可用性。

網絡問題不只僅出如今Master和Slave之間，一樣也可能出如今HA與Master，HA與Slave之間。考慮下面的這種狀況：

HA與Master之間的網絡出現問題，此時HA面臨兩個抉擇：

1. HA到Master之間的鏈接不通，認爲主庫Crash。選擇將備庫提高爲主庫。但實際上，只是HA到Master間的網絡有問題，原主庫是好的（沒有被降級爲備庫，或者是關閉），仍舊可以對外提供服務。新的主庫也能夠對外提供服務。兩個主庫，產生雙寫問題，最爲嚴重的問題。
   

2. HA到Master之間的鏈接不通，認爲是網絡問題，主庫未Crash。HA選擇不作任何操做。可是，若是這時確實是主庫Crash了，HA不作操做，數據庫不對外提供服務。雙寫問題避免了，可是應用的可用性受到了影響。
   

最後，數據庫會出現問題，數據庫之間的網絡會出現問題，那麼再考慮一層，HA軟件自己也有可能出現問題。以下圖所示：

若是是HA軟件自己出現了問題，怎麼辦？咱們經過部署HA，來保證數據庫系統在各類場景下的持續可用，可是HA自己的持續可用誰來保證？難道咱們須要爲HA作主備，而後再HA之上再作另外一層HA？一層層加上去，子子孫孫無窮盡也 … …

其實，上面提到的這些問題，其實就是經典的分佈式環境下的一致性問題（Consensus），近幾年比較火熱的Lamport老爺子的Paxos協議，Stanford大學最近發表的Raft協議，都是爲了解決這一類問題。（對Raft協議感興趣的朋友，能夠再看一篇Raft的動態演示PPT：Understandable Distributed Consensus）

 

 

1. 問題二：分區可用性

 

前面，咱們回答了第一個問題，數據庫若是不使用共享存儲，可否保證主備數據的強一致？答案是確定的：能夠。可是，經過前面的分析，咱們又引出了第二個問題：如何保證數據庫在各類狀況下的持續可用？至少前面提到的HA機制沒法保證。那麼是否能夠引入相似於Paxos，Raft這樣的分佈式一致性協議，來解決上面提到的各類問題呢？

答案是能夠的，咱們能夠經過引入類Paxos，Raft協議，來解決上面提到的各種問題，保證整個數據庫系統的持續可用。考慮仍舊是兩個數據庫組成的主備強一致系統，仍舊使用HA進行主備監控和切換，再回顧一下上一節新引入的兩個問題：

1. HA軟件自身的可用性如何保證？
   

2. 若是HA軟件沒法訪問主庫，那麼這時究竟是主庫Crash了呢？仍是HA軟件到主庫間的網絡出現問題了呢？如何確保不會同時出現兩個主庫，不會出現雙寫問題？
   

3. 如何在解決上面兩個問題的同時，保證數據庫的持續可用？
   

爲了解決這些問題，新的系統以下所示：

相對於以前的系統，能夠看到這個系統的複雜性明顯增高，並且不止一成。數據庫仍舊是一主一備，數據強同步。可是除此以外，多了不少變化，這些變化包括：

1. 數據庫上面分別部署了HA Client；
   

2. 原來的一臺HA主機，擴展到了3臺HA主機。一臺是HA Master，其他的爲HA Participant；
   

3. HA主機與HA Client進行雙向通信。HA主機須要探測HA Client所在的DB是否可以提供服務，這個跟原有一致。可是，新增了一條HA Client到HA主機的Master Lease通信。
   

這些變化，可以解決上面的兩個問題嗎？讓咱們一個一個來分析。首先是：HA軟件自身的可用性如何保證？

從一臺HA主機，增長到3臺HA主機，正是爲了解決這個問題。HA服務，自己是無狀態的，3臺HA主機，能夠經過Paxos/Raft進行自動選主。選主的邏輯，我這裏就不作贅述，不是本文的重點，想詳細瞭解其實現的，能夠參考互聯網上洋洋灑灑的關於Paxos/Raft的相關文章。總之，經過部署3臺HA主機，而且引入Paxos/Raft協議，HA服務的高可用能夠解決。HA軟件的可用性獲得了保障。

第一個問題解決，再來看第二個問題：如何識別出當前是網絡故障，仍是主庫Crash？如何保證任何狀況下，數據庫有且只有一個主庫提供對外服務？

經過在數據庫服務器上部署HA Client，而且引入HA Client到HA Master的租約（Lease）機制，這第二個問題一樣能夠獲得完美的解決。所謂HA Client到HA Master的租約機制，就是說圖中的數據庫實例，不是永遠持有主庫（或者是備庫）的權利。當前主庫，處於主庫狀態的時間是有限制的，例如：10秒。每隔10秒，HA Client必須向HA Master發起一個新的租約，續租它所在的數據庫的主庫狀態，只要保證每10秒收到一個來自HA Master贊成續租的確認，當前主庫一直不會被降級爲備庫。

第二個問題，能夠細分爲三個場景：

• 場景一：主庫Crash，可是主庫所在的服務器正常運行，HA Client運行正常
  

  主庫Crash，HA Client正常運行。這種場景下，HA Client向HA Master發送一個放棄主庫租約的請求，HA Master收到請求，直接將備庫提高爲主庫便可。原主庫起來以後，做爲備庫運行。
  

• 場景二：主庫所在的主機Crash。（主庫和HA Client同時Crash）
  

  此時，因爲HA Client和主庫同時Crash，HA Master到HA Client間的通信失敗。這個時候，HA Master還不能當即將備庫提高爲主庫，由於區分不出場景二和接下來的場景三（網絡問題）。所以，HA Master會等待超過租約的時間（例如：12秒），若是租約時間以內仍舊沒有續租的消息。那麼HA Master將備庫提高爲主庫，對外提供服務。原主庫所在的主機重啓以後，以備庫的狀態運行。
  

• 場景三：主庫正常，可是主庫到HA Master間的網絡出現問題
  

  對於HA Master來講，是區分不出場景二和場景三的。所以，HA Master會以處理場景二一樣的邏輯處理場景三。等待超過租約的時間，沒有收到續租的消息，提高原備庫爲主庫。可是在提高備庫以前，原主庫所在的HA Client須要作額外的一點事。原主庫HA Client發送給HA Master的續租請求，因爲網絡問題，一直沒有獲得響應，超過租約時間，主動將本地的主庫降級爲備庫。如此一來，待HA Master將原備庫提高爲主庫時，原來的主庫已經被HA Client降級爲備庫。雙主的狀況被杜絕，應用不可能產生雙寫。

經過以上三個場景的分析，問題二一樣在這個架構下被解決了。而解決問題二的過程當中，系統最多須要等待租約設定的時間，若是租約設定爲10秒，那麼出各類問題，數據庫停服的時間最多爲10秒，基本上作到了持續可用。這個停服的時間，徹底取決於租約的時間設置。

到這兒基本能夠說，要實現一個持續可用（分區可用性保證），而且保證主備數據強一致的數據庫系統，是徹底沒問題的。在現有數據庫系統上作改造，也是能夠的。可是，若是考慮到實際的實現，這個複雜度是很是高的。數據庫的主備切換，是數據庫內部實現的，此處經過HA Master來提高主庫；經過HA Client來降級備庫；保證數據庫崩潰恢復後，恢復爲備庫；經過HA Client實現主庫的租約機制；實現HA主機的可用性；全部的這些，在現有數據庫的基礎上實現，都有着至關的難度。可以看到這兒，並且有興趣的朋友，能夠針對此問題進行探討J

 

1. 問題三：性能

 

數據一致性，經過日誌的強同步，能夠解決。分區可用性，在出現任何異常狀況時仍舊保證系統的持續可用，能夠在數據強同步的基礎上引入Paxos/Raft等分佈式一致性協議來解決，雖然這個目前沒有成熟的實現。接下來再讓咱們來看看一個不少朋友都很感興趣的問題：如何在保證強同步的基礎上，同時保證高性能？回到咱們本文的第一幅圖：

爲了保證數據強同步，應用發起提交事務的請求時，必須將事務日誌同步到Slave，而且落盤。相對於異步寫Slave，同步方式多了一次Master到Slave的網絡交互，同時多了一次Slave上的磁盤sync操做。反應到應用層面，一次Commit的時間必定是增長了，具體增長了多少，要看主庫到備庫的網絡延時和備庫的磁盤性能。

爲了提升性能，第一個很簡單的想法，就是部署多個Slave，只要有一個Slave的日誌同步完成返回，加上本地的Master日誌也已經落盤，提交操做就能夠返回了。多個Slave的部署，對於消除瞬時的網絡抖動，很是有效果。在Oracle的官方建議中，若是使用最大保護模式，也建議部署多個Slave，來最大限度的消除網絡抖動帶來的影響。若是部署兩個Slave，新的部署架構圖以下所示：

新增一個Slave，數據三副本。兩個Slave，只要有一個Slave日誌同步完成，事務就能夠提交，極大地減小了某一個網絡抖動形成的影響。增長了一個副本以後，還可以解決當主庫Crash以後的數據安全性問題，哪怕主庫Crash，仍舊有兩個副本能夠提供服務，不會造成單點。

可是，在引入數據三副本以後，也新引入了一個問題：主庫Crash的時候，到底選擇哪個備庫做爲新的主庫？固然，選主的權利仍舊是HA Master來行使，可是HA Master該如何選擇？這個問題的簡單解決可使用下面的幾個判斷標準：

1. 日誌優先。兩個Slave，哪一個Slave擁有最新的日誌，則選擇這個Slave做爲新的主庫。
   

2. 主機層面排定優先級。若是兩個Slave同時擁有最新的日誌，那麼該如何選擇？此時，選擇任何一個都是能夠的。例如：能夠根據Slave主機IP的大小進行選擇，選擇IP小的Slave做爲新的主庫。一樣可以解決問題。
   

新的主庫選擇出來以後，第一件須要作的事，就是將新的Master和剩餘的一個Slave，進行日誌的同步，保證兩者日誌達到一致狀態後，對應用提供服務。此時，三副本問題就退化爲了兩副本問題，三副本帶來的防止網絡抖動的紅利消失，可是因爲兩副本強同步，數據的可靠性以及一致性仍舊可以獲得保障。

固然，除了這一個簡單的三副本優化以外，還能夠作其餘更多的優化。優化的思路通常就是同步轉異步處理，例如事務提交寫日誌操做；使用更細粒度的鎖；關鍵路徑能夠採用無鎖編程等。

多副本強同步，作到極致，並不必定會致使系統的性能損失。極致應該是什麼樣子的？個人想法是：

• 對於單個事務來講，RT增長。其響應延時必定會增長（至少多一個網絡RT，多一次磁盤Sync）；
  

• 對整個數據庫系統來講，吞吐量不變。遠程的網絡RT和磁盤Sync並不會消耗本地的CPU資源，本地CPU的開銷並未增大。只要是異步化作得好，整個系統的吞吐量，並不會因爲引入強同步而下降。
  

• 
  

1. 總結

 

洋洋灑灑寫了一堆廢話，最後作一個小小的總結：

• 可以看到這裏的朋友，絕逼都是真愛，謝謝大家！！
  

• 各類主流關係型數據庫系統是否能夠實現主備的強一致，是否能夠保證不依賴於存儲的數據一致性？
  

      能夠。Oracle有，MySQL 5.7，阿里雲RDS，網易RDS都有相似的功能。
  

• 目前各類關係型數據庫系統，可否在保證主備數據強一致的基礎上，提供系統的持續可用和高性能？
  

      能夠作，可是難度較大，目前主流關係型數據庫缺少這個能力。
  

• 
  

1. 問題四：一個極端場景的分析

 

意猶未盡，給仍舊在堅持看的朋友預留一個小小的做業。考慮下面這幅圖：若是用戶的提交操做，在圖中的第4步完成前，或者是第4步完成後第5步完成前，主庫崩潰。此時，備庫有最新的事務提交記錄，崩潰的主庫，可能有最新的提交記錄（第4步完成，第5步前崩潰），也可能沒有最新的記錄（第4步前崩潰），系統應該如何處理？

文章在博客上放出來以後，發現你們尤爲對這最後一個問題最感興趣。我選擇了一些朋友針對這個問題發表的意見，僅供參考。

@淘寶丁奇

最後那個問題其實本質上跟主備無關。簡化一下是，在單庫場景下，db本地事務提交完成了，回覆ack前crash，或者ack包到達前客戶端已經斷定超時…因此客戶端只要沒有收到明確成功或失敗，臨界事務兩種狀態都是能夠接受的。主備環境下只須要保證系統自己一致。

將丁奇意見用圖形化的方式表示出來，就是下面這幅圖：

此圖，相對於問題四簡化了不少，數據庫沒有主備，只有一個單庫。應用發起Commit，在數據庫上執行日誌落盤操做，可是在返回應用消息時失敗（網絡緣由？超時？）。雖然架構簡化了，可是問題大同小異，此時應用並不能判斷出本次Commit是成功仍是失敗，這個狀態，須要應用程序的出錯處理邏輯處理。

@ArthurHG

最後一個問題，關鍵是解決服務器端一致性的問題，可讓master從slave同步，也可讓slave回滾，由於客戶端沒有收到成功消息，因此怎麼處理都行。服務器端達成一致後，客戶端能夠從新提交，爲了實現冪等，每一個transaction都分配惟一的ID；或者客戶端先查詢，而後根據結果再決定是否從新提交。

其實，最終的這個問題，更應該由作應用的同窗來幫助解答：

若是應用程序在提交Commit操做，可是最後Catch到網絡或者是超時的異常時，是怎麼處理的？

標籤: 分佈式, 數據庫, 架構

阿里數據庫技術團隊，多個挑戰性崗位期待您的×××！一個最難以想象的MySQL死鎖分析

1. 
   

   pi1ot

   三 27th, 201520:24

   回覆 | 引用 | #1

   第一個強一致話題，若是slave寫入完成，master失敗或者crash，client未收到ok結果，又重發起一次更新，豈不是slave就重複操做了？再若是sql不是冪等的，不就出錯了？

allwmh

• 三 28th, 201506:49

  回覆 | 引用 | #3

  若是說提交超時候 應用進行retry操做的話 會如何呢

• hedengcheng

  三 29th, 201516:15

  引用 | #5

  這個方案是可行的。

• Ternence

  三 28th, 201513:02

  回覆 | 引用 | #4

  感受和【問題四：一個極端場景的分析】很像啊。個人理解只能經過應用層來處理，由於這個跟DB沒有關係了。一、要求事物具備冪等性 二、非冪等性事物經過事物日誌記錄的方式，防止事物重複提交。
  不知道可不可行 ？

• hedengcheng

  三 27th, 201522:17

  回覆 | 引用 | #2

  master失敗或者是crash，數據庫這邊必定會完成新的選主，而應用服務器這邊，必定是一個請求超時，提交超時。有這些前提，後續應用服務器應該怎麼作？

helix三 27th, 201521:42回覆 | 引用 | #6好文啊，最後的解決方法是什麼？限制一個commit完成成功返回，才能繼續commit?detailyang三 27th, 201522:13回覆 | 引用 | #7講解的很是詳細,感觸很深。zhaoxin三 27th, 201523:01回覆 | 引用 | #8感謝分享。感受問題4是對問題1中WAL方案的反駁，要實現分佈式系統強一致，WAL是不夠的，須要一致性協議的應用。Superwood三 27th, 201523:20回覆 | 引用 | #9每次提交都帶惟一ID,相同的事務即便兩次提交也不會重複執行hedengcheng三 28th, 201508:47回覆 | 引用 | #10微博上，@淘寶丁奇 丁總的回覆，對理解最後預留的問題，很是有幫助：@淘寶丁奇: 最後那個問題其實本質上跟主備無關。簡化一下是，在單庫場景下，db本地事務提交完成了，回覆ack前crash，或者ack包到達前客戶端已經斷定超時…因此客戶端只要沒有收到明確成功或失敗，臨界事務兩種狀態都是能夠接受的。主備環境下只須要保證系統自己一致。

hedengcheng

三 29th, 201516:12

回覆 | 引用 | #13

贊！就是這個意思。

lili

三 28th, 201514:22

回覆 | 引用 | #11

客戶端沒有接收到成功，而後主備切換，客戶端在備機上確能讀取到未提交成功的事務，整個主備系統豈不是連順序一致性都沒有知足…..

yaoyaminaco

三 28th, 201516:42

回覆 | 引用 | #12

我也是這麼認爲的，不存在主備那麼一說，就當作一個雙副本+DFS存儲的分佈式數據庫。 客戶端提交的transcation失敗了，客戶端捕捉異常，從新提交便可。從新提交的時候是必然成功的（由於備庫被提爲主庫，原主庫crash了）。 後續怎麼樣追上日誌，那是系統自己或者是運維人員須要去幹預的事情。

erpeng三 28th, 201511:35回覆 | 引用 | #14最後一個問題，能夠在應用層面作超時處理。處理邏輯應該是先判斷上次操做是否成功，不成功則再次執行。登博，若是HA到master網絡有問題，我記得keepalived應該會把master切成slave,爲何會產生雙寫的問題。

iambowen

四 7th, 201511:36

回覆 | 引用 | #16

咱們用的是NetScaler，若是HA到Master的訪問有問題，那麼它會切換到Backup的服務器，也就是另外一個數據中心的RDS，兩個數據中心之間的是Master-Master關係，不會有雙寫的問題。

erpeng

四 9th, 201516:21

回覆 | 引用 | #17

keepalived在主備機器上都會部署。經過虛擬一個ip而且配置指定主備來進行服務，是服務器層面的HA。博文裏提的HA應該是數據庫的吧。

hedengcheng

三 30th, 201507:51

回覆 | 引用 | #15

keepalived行使的是ha client的功能？這個你肯定嗎？咱們目前集羣中自動切換的HA軟件，好像都沒有配置這個功能。

wptree三 28th, 201511:40回覆 | 引用 | #18登博，問題二的場景二中原主庫主機重啓之後，是由該主機上的HAClient來直接將原主庫降級仍是還須要和HAMaster作一次協商來作降級？問題四，只要保證SQL的冪等性就基本沒什麼問題了；若是不是冪等的，能夠作數據惟一性驗證；涉及到累加運算的，可能須要特殊處理，commit以前先query一把，這些都是在應用層面作手腳去確保了。這套多HAClient－HAMaster高可用機制，目前是各大有技術實力公司在RDBMS上本身作實現呢，仍是已經有開源實現呢？

alex

四 1st, 201514:38

回覆 | 引用 | #20

HAClient-HAMaster高可用機制, 騰訊微衆銀行這邊作了。 不過master拆成了了zookeeper+schedule

hedengcheng

四 2nd, 201515:11

回覆 | 引用 | #21

贊！期待分享。

hedengcheng

三 30th, 201507:55

回覆 | 引用 | #19

最後一個問題，HAClient-HAMaster高可用機制，只是一個事例，目前據我所知，沒有人在RDBMS上這樣作。

問題二：這個時候不須要協商的。或者是協商也能夠，重啓後仍舊發起租約請求，可是因爲已經存在新的Master，這一次的協商請求，會收到降級的反饋。

問題四：謝謝你的建議，這個問題，其實數據庫內部是沒法搞定的，確實須要應用來配合處理。

KryptosX三 28th, 201512:49回覆 | 引用 | #22這個流程不該該備庫先落盤，應該主庫先落盤纔對。Ternence三 28th, 201512:50回覆 | 引用 | #23我有一個問題，3副本模式下，二選一日誌強同步怎麼理解（好像沒有特別寫這塊） ：個人理解是若是選擇其中一個Slave1,那麼每次強同步都應該選擇同步到Slave1。不然將會出現Slave1和Slave2數據不一致，而且無法選舉出Master的狀況。是這樣嗎？Chenhj三 28th, 201520:34回覆 | 引用 | #24有不少疑問。爲何ha做爲單獨的節點而不是放在db上？白白多了幾個節點。還有這個方案爲何沒有考慮ha client可能會掛？最後我以爲現有的成熟ha軟件結合fence機制是徹底能夠作到一致性和高可用的，沒做者講得那麼悲觀.否則你讓那些已經上線的ha方案情何以堪。至於性能隕失，無論哪一個方案都會有，多少不一樣而已。

Chenhj

三 30th, 201521:30

回覆 | 引用 | #26

分區可用，說白了就是網絡故障後該聽誰的問題。最簡單的辦法就是投票看誰拿到多數票。Raft的核心也就是這個吧。我知道至少Pacemaker是能夠支持法定投票的，雖然我不知道內部協商的細節，和raft有什麼差別，但有了這個投票可靠性就很高,不會發生腦裂了。

chuan

四 17th, 201516:58

回覆 | 引用 | #27

去除ha集羣，僅部署client在db上，會致使ha client處須要存儲本集羣其它機器的信息，不方便整個集羣的管理維護。

hedengcheng

三 29th, 201516:14

回覆 | 引用 | #25

能夠探討下，你也能夠普及一下，哪個HA方案能夠解決分區可用性的問題？處理的問題也就是文中提到的這些問題。

張小賤三 28th, 201523:55回覆 | 引用 | #28好文！ 有個問題：事務的強一致每次commit都保證落盤，這樣性能會比較差，可是若是先把日誌寫到內存中，一旦主庫crash，好比斷電，即便有自帶電源的內存也只能保證數據不丟失，不能保證主備同步。這種異步的優化和性能該如何抉擇。 問題四以爲能夠交給應用端去作，若是沒有獲得明確的成功或失敗，就執行一次查詢，看看剛纔提交的事務是否成功，若是屢次都沒有結果極可能是鏈接斷掉了。 ~~kamushin三 29th, 201518:14回覆 | 引用 | #29http://feed.feedsky.com/hedengcheng 彷佛掛了

hedengcheng

三 30th, 201507:50

回覆 | 引用 | #30

謝謝提醒，我看下。

xiaosuo三 30th, 201512:07回覆 | 引用 | #31最後的不會是2pc吧。

hedengcheng

三 30th, 201512:53

回覆 | 引用 | #32

這個地方，不須要使用2pc。2pc解決的是分佈式事務問題，這裏使用2pc，過重了。

zxhdaniel三 31st, 201510:13回覆 | 引用 | #33若是應用程序在提交Commit操做，可是最後Catch到網絡或者是超時的異常時，是怎麼處理的？我的以爲，應用層如今也很難處理好這種狀況。一、回滾。catch到網絡超時以後，作一個回滾操做；固然回滾操做是否成功徹底沒辦法保證(可能仍然是網絡問題，可能恰好發生主從切換等)；而後無論回滾成功與否，都回復操做失敗；二、從新提交。從新提交或者查詢後再提交，由於若是是網絡問題，去查詢也有可能超時…或者查詢成功了，但再次發起操做又超時了…怎麼處理，可能還得看這個應用是什麼場景，若是commit操做自己是人觸發的，那可能得作fail-fast的處理，趕忙提示用戶操做失敗，讓用戶本身判斷操做成功與否再作相應的操做；若是是程序觸發的commit，那能夠直接嘗試或者將該事務放到隊列裏面再離線去處理…我的拙見，其實更像是提出問題…期待好的方案出現..mdkii三 31st, 201520:44回覆 | 引用 | #34最後一個問題應該是個廣泛問題吧，只要發生跨系統調用就會有此問題發生。當A系統調用B系統服務時，B內部成功了，可是A殊不知道。這個時候只能A去從新發起交易了。對於查詢，從新發起便可，對於修改動做，要先去確認以前的調用是否成功了。但有沒有這種狀況：就是A去查詢某條記錄，B事務成功，可是通知A的時候信息丟失了，此時因爲事務成功鎖釋放了，正好別人把這個記錄給修改了，那A這個事務永遠不能成功了？paladin_pan四 1st, 201511:03回覆 | 引用 | #35問題二的場景三中的疑問，原文「可是在提高備庫以前，原主庫所在的HA Client須要作額外的一點事。原主庫HA Client發送給HA Master的續租請求，因爲網絡問題，一直沒有獲得響應，超過租約時間，主動將本地的主庫降級爲備庫。如此一來，待HA Master將原備庫提高爲主庫時，原來的主庫已經被HA Client降級爲備庫。」，如何保證主庫->備庫以及備庫->主庫的切換順序？仍是不須要保證？

paladin_pan

四 8th, 201510:58

回覆 | 引用 | #37

其實這也是不安全的，timeout機制不是頗有效，可是分佈式系統很難作到絕對，有一些時候只能相對保證，要看總體系統的訴求

hedengcheng

四 2nd, 201515:11

回覆 | 引用 | #36

須要保證，保證主庫降級在備庫提高以前。也就是備庫提高要比租約時間更大。

vicehunter四 1st, 201513:53回覆 | 引用 | #38在客戶端 設置一個seqid，每次submit 成功後加1，當出現錯誤時，submit 沒有+1，重複提交wcting163四 1st, 201519:13回覆 | 引用 | #39mysql.pg.日誌都是先寫主機，再傳備機吧，

hedengcheng

四 2nd, 201515:13

回覆 | 引用 | #40

我這裏是假設數據庫若是實現主備強一致，該如何作。MySQL一些版本都支持將binlog落在備庫再提交主庫的分支。

yeshiquan四 2nd, 201511:36回覆 | 引用 | #41博主我有一個問題，「若是租約設定爲10秒，那麼出各類問題，數據庫停服的時間最多爲10秒，基本上作到了持續可用」若是數據庫停服10秒，還叫持續可用嗎？這種狀況Avaliability不行吧，對線上應用也是災難的。

hedengcheng

四 2nd, 201515:17

回覆 | 引用 | #42

任何一種分佈式數據庫，哪怕是依賴於共享存儲的數據庫，如Oracle RAC，都不能作到節點宕機後對應用徹底的無影響。所謂的持續可用，不是永遠處於可用狀態，全部的系統都不能達到這個理想狀態，而是在一個極短的時間以內從崩潰中恢復可用。

psjay四 10th, 201500:01回覆 | 引用 | #43有一點疑問：問題二中，HA Client 掛了怎麼辦？HA Master 不能和 Client 通訊，Client 也不能續租，前者形成 Master 回去嘗試提高 Slave 爲主，後者形成原來的主不能被順利降級。

psjay

四 11th, 201516:14

回覆 | 引用 | #45

降級操做是誰發起的？

hedengcheng

四 13th, 201520:42

回覆 | 引用 | #46

租約到期內，若是沒能續租成功，自動降級。我文章寫了。

hedengcheng

四 11th, 201509:09

回覆 | 引用 | #44

不能續租，超過租期後，原主會自動降級

zhujzhuo四 15th, 201521:35回覆 | 引用 | #47openstack trove中就有相似的agent，上報信息給監控端，監控發現主庫不可訪問會超時重試，重試不成功便會切換貯備關係，飄vip。zhujzhuo四 15th, 201521:36回覆 | 引用 | #48整個架構都是很是棒的，都須要對MySQL 進行二次開發吧

hedengcheng

四 16th, 201522:37

回覆 | 引用 | #49

今天的數據庫大會，騰訊雷海林同窗分享的架構，基本上就是按照文章中的架構思路實現了他們不丟數據的MySQL集羣。

xgzeng四 18th, 201519:04回覆 | 引用 | #50請教。問題二的圖提出的架構，有沒有單點故障？ Master在接收同步確認超時的狀況下，應怎麼處理？