High Availability 雙機儲存架構
當我們在做軟體的架構設計時，資料庫的 Non-Functional Requirements 絕對是必要考慮的一環。例如 Performance（如回應時間）、Data Integrity（如資料一致性）、Availability（每年的 Uptime 比例） 等等。
如果要將資料庫設計成 HA（High Availability，高可用）的話，可能至少要讓每年的 Uptime 大於 4 個 9，也就是 99.99% 的時間都能正常使用（大約每年小於 50 分鐘的 Downtime）。
而單機的資料庫一旦發生什麼故障，由於需要人工介入修復，停機的時間超過 50 分鐘基本上是不可避免的。因此增加冗餘、增加機器的數量基本上是要達成高可用的唯一途徑。
這篇文章來看看如果要達成高可用的儲存架構，如何用雙機，也就是多一台機器的冗餘要增加資料庫的可用性。
三種架構
常見的三種雙機架構有「主備 Master-Standby」、「主從 Master-Slave」和「主主 Master-Master」，每種架構都有其優缺點，分析的因素大致可以從易用性、資料一致性、故障修復來看。
主備架構
先來看「主備 Master-Standby」，這是三者當中最簡單的架構。Client 不論讀或寫都只對上一台的機器，也就是主機 Master，而備機 Standby 只做備份的工作。
由於資料讀寫都只在 Master 上，就不會有分散在多節點而產生不一致的問題。然而備機因為平常沒有在用，就顯得有些浪費，而且當 Master 故障時如果沒有特別設計，人工處理切換便會讓可用性大幅降低。
主從架構
而「主從 Master-Slave」的 Slave 和「主備」的差異就是 Slave 需要承擔部分的責任，也就是提供 Client 讀取。
由於現在有兩台機器可以被 Client 所感知，易用性，或是反過來説複雜度就會增加，我們要多考慮 Client 的讀取動作究竟要往 Master 還是 Slave 執行。
相較「主備」來說，優點是就是能夠比較有效的利用硬體，讓整體讀取的 Performance 提升，但需要犧牲的就會是資料一致性可能產生的問題。例如 Master 寫入資料後尚未複製到 Slave，但是 Slave 卻被 Client 所讀取就會導致不一致。
而故障發生時也和「主備」架構類似，為了避免人工處理而增加 Downtime，需要額外設計的機制才能增加資料庫的可用性。
主備及主從架構的故障修復：雙機切換
我們接著來看幾種自動的故障修復機制，主要針對的點都是「主備」和「主從」架構下，Master 故障的情形，需要把原本 Master 的責任轉交給另外一台機器來保持服務繼續可用，我們就簡稱這樣自動的機制為雙機切換。
問題來了，怎麼讓故障的機器自動切換呢？我們需要知道雙機的狀態，當 Master 出現如關機、回應速度過慢、程式 Crash 等情形能讓另一台機器知道。
於是乎有以下三種不同的常見方式來達成狀態傳遞的目的。
互連式：主機傳遞狀態和數據給備機，主機壞掉時能被偵測到而後切換。但缺點是中間的連線如果失效，但是對 Client 的連線都在，就可能有兩台主機
中介式：主機傳遞數據給備機，但兩方都把狀態傳給第三台中介機。雖然多了一台中介機，但管理狀態更容易，不過缺點也就是又多了一台機器，難道這台機器也要達成高可用嗎？
模擬式：不傳遞狀態，而由備機對主機模擬讀寫來判斷狀態（也就是走數據傳送通道）。實作起來會相較互連式簡單，但相對的能得到的狀態就比較少，例如 CPU、I/O 等資訊就無法透過此方式獲取
主主架構
最後說到「主主 Master-Master」架構，Client 可以對兩台資料庫進行讀取以及寫入，而這兩台主機再把收到的資料互相同步。
這樣就沒有所謂一台壞掉切換的問題了，Client 可以任選一台進行讀寫，此時最大缺點就是資料的同步問題。
由於資料需要雙向複製，有些資料是無法做到的。例如 incremental 的 id 在還沒被複製到另一台主機時也被產生，就會有同樣 id 的情形發生了。
參考資料
版本記錄
- 2023-12-28 初版