在現代數據管理中,企業對于可靠性、可用性和成本的平衡有著多樣化的需求。為此,TDengine 在 3.3.0.0 版本中推出了兩種不同的企業級解決方案:雙活方案和基于仲裁者的雙副本方案,以滿足不同應用場景下的特殊需求。本文將詳細探討這兩種方案的適用場景、技術特點及其最佳實踐,讓大家深入了解這兩大方案如何幫助企業在高效可靠的數據存儲和管理中取得成功。
TDengine 雙副本(+仲裁者)
為了滿足部分客戶在保證可靠性和可用性條件下盡可能壓縮部署成本的需求,TDengine 提出了基于仲裁者的雙副本方案。該方案通過提供“只有單個服務故障且不出現連續故障”的容錯能力,成為客戶降低成本和提高效率的有效選擇。
相較于傳統的三副本數據庫,雙副本數據庫具有顯著的優勢。它在減少硬件成本的同時,依然能夠保證一定的高可用性。具體來說,雙副本數據庫中每個 Vgroup 僅有兩個 Vnode。當其中一個 Vnode 發生故障時,Mnode 可根據數據同步狀態,裁定另一 Vnode 是否可以獨自對外提供服務。這種機制確保了在某個副本節點故障時,數據不會丟失,并且系統能夠持續進行寫入和查詢操作。
這一方案的適用場景廣泛,面向有降低存儲成本需求的、希望減少物理節點需求的客戶,以及對高可用性要求稍低的客戶。
從技術角度看,雙副本方案具有以下幾個顯著特點:
– 副本數目:時序數據的副本數目為 2,但集群內節點數目必須大于等于 3。
– 自動切主:當時序數據的某個副本所在的物理節點宕機時,可以自動切換主節點,確保數據不丟失,并且能夠持續寫入和查詢。
– 選主機制:雙副本選主由高可用的 Mnode 提供仲裁服務,而不是由 Raft 組內決定。
仲裁者 (Arbitrator) 在雙副本方案中發揮關鍵作用。它提供仲裁服務但不存儲數據。當 Vgroup 因某一 Vnode 故障而無法提供服務時,Arbitrator 可以根據同步情況指定同組另一 Vnode 成為 Assigned Leader,無論其他副本 Vnode 是否存活,均可一直響應用戶請求。這一機制確保了即使在某個副本節點故障的情況下,Assigned Leader 仍然能夠一直響應用戶請求,從而提高系統的可靠性和可用性。
TDengine 雙活
部分用戶由于部署環境的特殊性,只能部署兩臺服務器,同時希望實現一定的服務高可用和數據高可靠。針對這些需求,TDengine 提出了雙活方案。雙活方案不僅適用于一些資源受限的環境,也能在兩套 TDengine 集群之間的災備場景中發揮重要作用。
在業務系統中,雙活架構通常包括兩臺服務器,各自部署一套服務。在業務層看來,這兩臺機器和兩套服務組成了一個完整的系統。雙活中的兩個節點通常被稱為 Master-Slave,即“主從”或“主備”。
雙活方案在多個場景中都有廣泛應用。首先,對于因部署環境特殊性只能部署兩臺服務器的客戶,雙活方案是理想選擇。這些客戶希望在有限的硬件資源下,仍然能夠實現服務高可用和數據高可靠。其次,雙活方案在工業控制領域中尤為適用。由于這些領域對系統可靠性和數據準確性有著極高的要求,雙活架構能夠很好地滿足這些需求。此外,雙活方案還適用于災備場景,無論是資源受限的環境還是不限節點數目的兩套 TDengine 集群之間的災備場景,都能提供有效的解決方案。雙活方案通過一系列技術機制實現高可用性和數據可靠性:
- 首先,系統通過 Client Driver 實現雙系統的 Failover,即在主節點發生故障時,能夠自動切換到從節點,確保服務不中斷。
- 其次,taosX 實現了主節點到從節點的數據復制,通過數據訂閱的寫接口在寫入復制過來的數據時,在 WAL 中加入特殊標記。
- 第三,數據訂閱的讀接口在讀取數據時,會自動過濾掉帶有特殊標記的數據,從而避免數據重復復制和無限循環。
當前,雙活方案僅支持 JDBC 連接器和 WebSocket 連接方式,不支持 Native 連接。雙活兩端集群必須同構,即數據庫的命名和所有配置參數必須完全相同,以確保系統的正確運行。
雙副本 VS 雙活,區別與實踐
在 TDengine 的雙副本和雙活方案中,雖然它們都旨在提升數據可靠性和服務可用性,但兩者在架構設計和實際應用中有著顯著的區別。了解這些差異,對于選擇合適的方案并實現最佳實踐至關重要。
雙活方案和雙副本方案在集群架構上有明顯的差異。雙活方案需要部署兩個獨立的集群,每個集群內部的節點數可以任意多,而雙副本方案只需部署一個集群,但集群內的節點數目必須大于等于三。這樣一來,雙活方案在集群內部節點數目上的靈活性更大,但同時也增加了部署和管理的復雜性。雙活系統內的最小節點數為兩個,也就是說每個集群至少有一個節點;相比之下,雙副本系統的最小節點數為三個,以確保數據的可靠性和高可用性。
在同步原理上,雙活方案通過 taosX 實現數據同步,依賴于 taosX 的同步速度,通常在秒級別。雙副本方案則通過 Arbitrator 仲裁選主,由 Raft 協議保證數據的一致性,因此在同步延遲上表現更好,沒有延遲。數據安全性方面,雙活方案依賴于 WAL 的保存時長,而雙副本方案則能確保無數據丟失。高可用性上,雙活方案只要有一個節點存活即可提供服務,而雙副本方案在連續宕機后,只有一個節點存活時,可能無法提供服務。
雙副本最佳實踐
- 全新部署
雙副本的主要價值在于節省存儲成本的同時能夠有一定的高可用和高可靠能力。在實踐中,推薦配置為:
- N 節點集群 (其中 N>=3)
- 其中 N-1 個 dnode 負責存儲時序數據
- 第 N 個 dnode 不參與時序數據的存儲和讀取,即其上不保存副本;可以通過?
supportVnodes
?這個參數為 0 來實現這個目標 - 不存儲數據副本的 dnode 對 CPU/Memory 資源的占用也較低,可以使用較低配置服務器
- 從單副本升級
假定已經有一個單副本集群,其節點數為 N (N>=1)。將集群的節點數目擴展至 3 個以上,修改 Mnode 的副本數目為 3,在使用?alter database replica 2
?的命令修改某個特定數據庫的副本數。
雙活最佳實踐
雙活系統通過數據復制實現雙系統之間的數據同步,但這種同步只能保證最終一致性,無法確保實時一致性。主節點可能在任意時刻宕機,宕機時可能會有數據差集,尤其是元數據差集。在完成主備切換后,業務層可能會發起重復的建表請求,但 schema 可能不相同,導致元數據不一致。因此,建議在系統啟動后集中完成所有建庫建表操作,后續只寫入時序數據,盡量避免再進行元數據操作。
結語
無論是雙副本還是雙活方案,TDengine 都為用戶提供了強大的數據存儲和管理解決方案。雙副本方案在節省存儲成本的同時,保證了一定的高可用性和數據可靠性,非常適合資源有限且需要高效數據管理的企業。雙活方案則通過其靈活的架構和強大的災備能力,為特殊部署環境和高可靠性需求的應用場景提供了理想的解決途徑。通過理解這兩種方案的區別和最佳實踐,用戶可以根據自身需求選擇最適合的方案,充分利用 TDengine 的技術優勢,打造穩定、高效的數據庫系統。這不僅提升了業務連續性和數據安全性,更為企業的數字化轉型提供了堅實的基礎。
關于 TDengine
TDengine 核心是一款高性能、集群開源、云原生的時序數據庫(Time Series Database,TSDB),專為物聯網IoT平臺、工業互聯網、電力、IT 運維等場景設計并優化,具有極強的彈性伸縮能力。同時它還帶有內建的緩存、流式計算、數據訂閱等系統功能,能大幅減少系統設計的復雜度,降低研發和運營成本,是一個高性能、分布式的物聯網IoT、工業大數據平臺。