[TcaplusDB知識庫]TcaplusDB的高可用性和數據安全性介紹

隨着信息化的發展，數據庫已是企業正常運營必不可少的工具，企業的全部數據都存儲在數據庫上，所以能夠說數據庫的可靠與否關係着企業的生死存亡。

所以，數據的保護和備份是數據庫業務的重中之重，系統的可用性以及數據的可靠性對數據庫來講都是相當重要的。

數據庫的可用性是指數據庫在規定的條件下使用時維持其正常功能的能力。其量化參數爲可用度，表示數據庫產品在規定的條件下使用時，在某時刻維持其正常業務功能的機率。高可用性的數據庫提供自動快速地轉移到備份的全自動故障轉移，這樣，用戶和應用程序能夠繼續工做，而不會中斷。

而數據一致性指數據庫的關聯數據之間的邏輯關係是否正確和完整，數據一致性能夠確保用戶所取的數據結果的一致。

而對於TcaplusDB而言，設計數據庫系統的可用性和數據一致性，最重要的是知足用戶的需求，從用戶的須要出發，纔可以設計出最好的數據庫。

下面TcaplusDB君將介紹TcaplusDB的高可用性和數據安全性以及災備機制。

高可用

TcaplusDB組件默認採用高可用部署：

• 管理節點tcapcenter採用Master/Slave模式部署，當Master故障時自動切換到Slave。
• 管理節點tcapdir會部署多個進程。
• 接入層tcaproxy採用冗餘方式，單個接入層節點故障不會致使用戶請求處理異常。
• 存儲層tcapsvr，採用Master/Slave模式，主從切換無損。 存儲層tcapsvr Master/Slave和接入層tcaproxy部署優先採用同城跨機房部署，也支持跨機架、跨交換機、跨樓層等部署方式。

數據一致性保障

對於TcaplusDB來講，有完善的數據一致性保障措施，具體以下所示:

• 正常讀寫場景：主備經過binlog來保證數據一致性，主備會按嚴格一致的時間順序執行binlog；主備時間差約10ms； 業務讀寫請求均在主節點執行。
• 主備切換： 系統主動切換會先等待數據徹底同步後，再進行切換。故障切換若因master進程已不存在， 可能丟失10ms左右數據，此時因老請求還連在原master上，TcaplusDB主備同步目前採用的是異步寫的機制，當數據寫主過程當中故障，有可能數據還將來得及同步備機鏈接就斷了，此時數據就可能會丟失，目前所使用的內外客戶對這種損失程度還處於可接受範圍，不會對業務形成太大影響。目前針對這個狀況，項目組也在計劃設計強同步機制，確保數據不會丟，不過帶來的就是會犧牲必定的吞吐量。
• 週期性主備數據一致性全量對比: 根據用戶須要，在低峯期對全量數據作一致性對比。對比過程因前端讀寫產品的不一致會根據記錄修改時間自動判斷並重覆校驗, 以發現系統潛在的不一致風險。 一般作法是抽查一些核心表的部分數據分片來進行全量比對，以保障比對效率。
• 冷備數據一致性保障: 備節點在作全量冷備時，冷備開始時間點全量數據文件處於徹底靜止狀態，此時全量數據採用字節copy來進行備份, 徹底無一致性問題。 且在冷備期間，前端讀寫徹底不受影響，新請求會寫入小的修改集，請求會合並全量數據和小修改集。
• 數據落地安全保障: 業務數據在存儲節點落地時有CRC校驗， 若因數據被篡改， CRC校驗會失敗， 不會所以返回給用戶錯誤的數據。

災難恢復

TcaplusDB API維護了一致性Hash環，當增長或者減小接入層節點時，TcaplusDB API會自動調整接入層tcaproxy的信息。

• 接入層異常：TcaplusDB每秒會向接入層tcaproxy發送心跳，若接入層節點在10s內沒有返回響應，則TcaplusDB API會主動標註該節點不可用，使用其餘節點。
• 存儲層異常：tcapsvr Slave發生異常時會被一個新的Slave節點替換。若是tcapsvr master發生異常， Slave會切換成Master，切換過程當中的用戶請求失敗，建議開發者增長重試邏輯代碼。Master/Slave支持亞健康切換，讀寫錯誤率達到閾值時（默認80%）即進行主從切換，以下圖：

災難恢復示意圖

接入層tcaproxy和存儲層tcapsvr均有過載保護功能，超過預留讀寫的請求會觸發錯誤碼返回。

最後

咱們已經瞭解了 TcaplusDB 的高可用性和數據安全性以及災備機制，後續咱們將揭開更多TcaplusDB設計的特殊奧祕。