數據庫作爲信息系統重要的基礎設施，一直承擔着壓艙石的角色。互聯網應用的高併發、海量數據使得數據庫的負載越來越重，這在數據大集中的情況下愈發明顯。而數據庫作爲信息系統唯一的“單點”，穩定性、可用性是首先要保證的目標。這裏的單點並不是指數據庫沒有高可用方案，而是因爲數據庫只要涉及到數據的複製就一定是有狀態的，有狀態的應用更加難以運維，並且在遭遇異常時並不能做到真正意義上的無縫切換。
傳統關係型數據庫經過幾十年的發展，目前高可用方案都已經非常成熟，目前數據庫常用的高可用方案主要包括：主機HA、數據庫主備和數據庫集羣方案。主機HA由於其適用範圍廣、切換時間短被廣泛應用於生產環境的各類數據庫上，主機層面的高可用這裏不再討論。
主備方案
主備方案是目前數據庫最常用的高可用方案。主備模式主要涉及到兩個問題：①數據同步問題；②主備切換問題。
數據同步涉及到不同同步模式的選擇，如果採用同步模式備機宕機可能影響主機業務，同時影響性能，如果採用異步模式可能造成數據的丟失。由於銀行業務的特殊性，信息系統的rpo要求等於0，即不允許數據的丟失，所以銀行業一般採用同步模式，同時現在的數據庫產品爲了保證性能和可用性會在同步和異步之間有一個折中方案。下面就以DB2 HADR、ORACLE ADG、MYSQL半同步爲例介紹一下主備方案。
HADR
上圖是hadr的架構圖，可以看到hadr總共有四種同步模式：
SYNC：主備數據庫都將日誌成功落盤，應用才能提交。這是最大數據保護模式，但性能損耗較大。
NEARSYNC：日誌只要寫到主機磁盤和備機的緩衝區，就可以提交。這種模式類似半同步，也是生產環境一般採用的方式。
ASYNC：日誌只要寫到主機磁盤同時發送到主機的TCP層，就可以進行提交，可能造成數據丟失。
SUPERASYNC：主庫只要成功落盤，就可以提交。性能最好，可能造成數據丟失。
如果因爲網絡問題造成複製延遲過大，不能及時同步日誌信息的話，DB2數據庫會自動切換爲異步模式，來保證主庫的可用性。DB2 V9.7開始，HADR 開始支持ROS(Read On Standby)，備機可以接收連接，執行讀操作。Db2數據庫執行”db2pd -hadr”命令可以查看hadr當前的狀態，包括 Local Catchup、Remote Catchup、Remote Catchup Pending、Peer、Disconnect Peer、Disconnected幾種。
Local Catchup：備機正在從本地磁盤讀取日誌並進行重放。
Remote Catchup：主機正在將日誌發送給備機，備機正在接收日誌，寫到磁盤並且應用日誌。
Remote Catchup Pending：備機讀取完本機的日誌後會進入該狀態。
Peer：日誌不是從磁盤中讀取，而是直接通過網絡傳輸到備機，進行應用。
Disconnect Peer：主備之間網絡有延遲，但是延遲的窗口還在hadr_peer_window參數值以內，這部分事務是無法提交的，當網絡恢復後變爲peer狀態。這樣保證了數據不丟失的同時有一定的網絡波動容忍性。
Disconnected：主備之間網絡中斷，如果設置了hadr_peer_window延遲緩衝窗口，超過了hadr_peer_wait_limit設置的值就認爲主備連接中斷，如果未設置hadr_peer_window窗口，則超過hadr_timeout參數值就認爲連接中斷。
ADG
Oracle從11g開始推出active data guard功能，支持備庫以read only的方式打開，同時應用日誌，這樣就從另一個層面支持了讀寫分離。
最大保護模式：該模式提供了最大級別的數據保護，redo日誌在至少一個物理備庫成功應用後主庫纔可以提交，如果備庫發生宕機，主庫找不到可以寫入的備庫時，主庫的業務會中斷。該模式對性能影響較大。
最大可用模式：redo日誌在至少一個物理備庫成功應用後主庫纔可以提交，如果備庫發生宕機，主庫找不到可以寫入的備庫時，會自動降級爲最大性能模式，這種模式是一種折中方式，在提供數據保護的情況下保證了主庫的可用性，是生產環境中一般採用的方案。
最大性能模式：主庫的提交不受備庫的影響，保證了主庫的可用性和性能，但是可能造成數據丟失。
下圖爲adg架構圖：
主庫向備庫發送日誌有兩種方式，一是通過歸檔進程arch發送，這樣的話就需要等待redo日誌切換歸檔日誌生成後才能進行發送，這個明顯是異步的。另一種方式是通過lgwr進程進行發送，lgwr在寫redo的同時將redo通過lns進程發送到備庫，備庫通過rfs進程進行redo日誌接收，mrp進程進行日誌apply。另外，adg支持備庫的實時應用（real_time_apply），使用該功能需要在備庫創建standby redo log，srl只在備庫是活動的，srl大小必須和orl的大小一致，個數一版按照每個日誌線程N+1的數量來配置，使用srl的好處除了支持實時應用外還能提高性能。通過alter database recover managed standbydatabase using current logfile;命令啓動實時應用。
MySQL semi-replication
Mysql從5.7開始支持半同步，下圖是mysql半同步的原理圖，與db2和oracle不同的是，mysql半同步不是基於物理redo的同步，而是基於binlog的偏邏輯的複製。主庫將數據改變記錄到binlog日誌中，dump線程不斷讀取binlog中的內容，從庫的io線程負責接收binlog並寫入中繼日誌relay log中，同時io線程會更新master.info文件中的位置信息。從庫的sql線程負責對relay log中的信息進行apply，已經應用過得relay log會進行清理。
Mysql5.7之前的版本，主庫先提交事務，然後將binlog傳遞到備庫並刷到relay log中，然後備庫會返回給主庫ack表示已經收到relay log，這時主庫纔給應用返回提交ok。這種方式如果在發送binlog的時候主庫宕機則會有數據丟失的風險。5.7之後支持after_sync模式，主庫必須等到備庫的relay log落盤後返回的ack才能進行提交，這樣就保證所有改變都寫入到了備庫的relay log，解決了數據丟失的問題。半同步通過rpl_semi_sync_master_timeout參數控制窗口大小，如果超過該窗口未收到反饋，就會變成異步模式。
總結
對於數據庫來說，其實任何主備方案都涉及到幾個問題：
一是同步方案的選擇，如果要做到rpo=0一定要支持同步，同時要支持同步模式的智能切換，在備庫宕機時不能一直影響主庫的業務；
二是考量同步對性能的影響，以及業務讀寫分離對一致性的要求，像db2、postgresql都提供了三種以上的同步模式，根據性能要求選擇合適的同步模式，例如數據是發送到備庫的緩存，還是落盤，亦或是落盤後apply成功主庫才能提交？
三是關於切換方案怎麼做，可能現在數據庫都只會提供主從複製，但是很少有直接提供切換方案的，這個時候就需要考慮是否有開源的主流切換方案，如果沒有是否可以使用虛擬機或者主機層面的集羣軟件，亦或是自行開發網關，進行探活、切換、註冊等。
歡迎關注我的公衆號
