高可用資料庫是由一系列資料庫構成的總體系統，在任何時刻，至少有乙個節點可以接受使用者的請求並提供資料庫服務。
高可用資料庫的優點：
第一，方便讀寫分離。
高可用資料庫可以通過將寫操作放在主資料庫節點上進行，將讀操作分擔到若干從庫上，來提公升讀操作吞吐量，進而提公升讀寫效率。
1.讀寫分離其實就是將資料庫分為了主從庫，乙個主庫用於寫資料，多個從庫完成讀資料的操作，主從庫之間通過某種機制進行資料的同步，是一種常見的資料庫架構。
2資料庫分組架構解決什麼問題？
大多數網際網路業務，往往讀多寫少，這時候，資料庫的讀會首先稱為資料庫的瓶頸，這時，如果我們希望能夠線性的提公升資料庫的讀效能，消除讀寫鎖衝突從而提公升資料庫的寫效能，那麼就可以使用「分組架構」（讀寫分離架構）。
用一句話概括，讀寫分離是用來解決資料庫的讀效能瓶頸的。
3.為什麼不使用快取呢？
快取的使用成本要比從庫少非常多；快取的開發比較容易，大部分的讀操作都可以先去快取，找不到的再滲透到資料庫。當然，如果我們已經運用了快取，但是讀依舊還是瓶頸時，就可以選擇「讀寫分離」架構了。簡單來說，我們可以將讀寫分離看做是快取都解決不了時的一種解決方案。
當然，快取也不是沒有缺點的
對於快取，我們必須要考慮的就是高可用，不然，如果快取一旦掛了，所有的流量都同時聚集到了資料庫上，那麼資料庫是肯定會掛掉的。
4.讀寫分離不使用的瓶頸
對於常見的資料庫瓶頸是什麼呢？
其實是資料容量的瓶頸。例如訂單表，資料量只增不減，歷史資料又必須要留存，非常容易成為效能的瓶頸，而要解決這樣的資料庫瓶頸問題，「讀寫分離」和快取往往都不合適。
大部分的網際網路業務，資料量都非常大，單庫容量最容易成為瓶頸，當單庫的容量成為了瓶頸，我們希望提高資料庫的寫效能，降低單庫容量的話，就可以採用水平切分了。
而有少部分程式設計師，會沒有分析資料庫的效能瓶頸是什麼，就貿貿然的使用「讀寫分離」，殊不知「水平切分」才是正道。
第二，變更不停服。
當整個高可用資料庫架構或主節點公升級時，可以讓高可用資料庫先進行主庫切換，備用節點替換原主節點提供資料庫服務，當主節點公升級完畢後，再將主從庫服務切換回來，這樣能有效避免系統公升級或變更時對使用者服務質量產生影響。
第三，備份不影響服務效能。
高可用資料庫架構包含多個從庫，在不影響主節點服務效能的情況下，能非常方便地實現資料的容災備份。
典型高可用資料庫架構
按照資料同步方式，可以將業界主流高可用架構分為四種：共享儲存方案、作業系統實時資料塊複製、資料庫級別的主從複製、高可用資料庫集群。每一種資料同步方式可以衍生出不同架構。
方案一：共享儲存
共享儲存指若干db服務使用同乙份儲存，乙個為主db，其它為備用db。若主服務崩潰，則系統啟動備用db，成為新的主db，繼續提供服務。一般共享儲存採用比較多的是san/nas方案。
（圖：共享儲存）
雖然該方案的優點是沒有資料同步的問題，但也有一些限制，如對於共享儲存的實時性和網路效能有較高要求。而隨著硬體效能的不斷提公升，將計算儲存分離、和db深度結合的共享儲存亦是高可用資料庫未來發展趨勢之一。
方案二：作業系統實時資料塊複製
這一方案的典型場景是drbd，可以理解為遠端的raid1。如下圖所示，左側資料庫寫入資料以後，立即同步到右側的儲存裝置當中。如果左邊資料庫崩潰，系統可以直接啟用右邊的資料庫儲存裝置，啟動新的資料庫服務，實現容災切換。
（圖：作業系統實時資料塊複製）
這個方案的缺點也比較明顯，如系統只能有乙個資料副本提供服務，無法實現讀寫分離；另外，如果系統崩潰，主庫程序中斷，容災切換後需要在掛掉的資料庫上做資料庫崩潰恢復，系統需要的容災恢復時間較長。
方案三：資料庫主從複製
這種方案是最經典的資料同步模式，系統採用乙個主庫和多個從庫方式，實現原理主要是基於日誌的主從複製，主庫操作以日誌的形式傳送給各個從庫，從庫接收到日誌後進行資料備份。
優點是乙個主庫可以連線多個從庫，能很方便地實現讀寫分離，同時因為每個備庫都在執行中，所以備庫里的資料基本都是熱資料，容災切換也非常快。
不過，這個方案也並非完美無缺，如容災切換時，從庫一定要同步完最新資料以後才能公升級為主庫，否則極有可能導致資料丟失。針對這些問題，業界也正在研發對應的改進技術。
方案四：資料庫高可用集群
前三種方案主要通過日誌的複製模式實現高可用，第四種方案則基於一致性演算法來做資料同步，資料庫提供多節點一致性同步機制，利用該機制構建多節點同步集群。這種方式比較經典的案例包括mgr（mysql group replication）和galera等，近期業內也有一些類似嘗試，如使用一致性協議演算法，自研高可用資料庫架構等。
（圖：資料庫高可用集群）
如上圖所示，五個節點構建成了乙個一致性的同步集群，客戶端可以讀寫其中的任一節點，其它節點都能進行資料同步，因此理論上每個節點都可以進行讀寫操作。這種方式的容災實現也比較簡單，假設第二個節點出現故障，系統只需要斷開客戶端對第二個節點的訪問路徑，其它節點照常訪問即可，這也是業界近年來比較流行的高可用集群方案。
參考：
資料庫專案之mongodb高可用方案
本次專案中，我們mongodb採用兩個集群，乙個集群3個例項，兩個集群分別存錯日誌資料和做日誌的分布式儲存。採用replica set sharding 方式 shard server 用於儲存實際的資料塊，shard server角色由乙個主節點和兩個relica set 副本集 承擔，防止主機單...
高可用性資料庫方案DataGuard部署
dataguard是甲骨文推出的一種高可用性資料庫方案，是一種資料庫級別的ha方案，最主要功能是容災 資料保護 故障恢復等。1，伺服器資源 相同作業系統，硬體資源，安裝oracle 主伺服器 xx.xx.xx.70 備伺服器 xx.xx.xx.71 2，db unique name區分主備庫標識 d...
資料庫集群和高可用解決方案
概述 盡可能的讓資料庫處於可用狀態。提供高可用解決方案要考慮的因素 1 rto recovery time objective 允許的離線時間，2 rpo recovery point objective 允許的資料丟失量 rto和pro統稱為 sla service level agrement ...