云原生多模數據庫 Lindorm支持創建多可用區的實例。該方案將一個Lindorm實例部署在多個可用區,多可用區實例具備更高的容災能力,同時Lindorm實例可以實現多個可用區之間數據的強一致,也可以在數據最終一致下發出請求返回最快的結果,從而提高在線業務的服務質量。
與傳統架構對比
傳統的主備容災架構
傳統的主備容災為了實現高可用性,通常的原理是分別在兩個不同的可用區(可用區A和可用區B)中購買一個Lindorm實例(主實例1和備實例2),使用數據通道服務(簡稱LTS)實現Lindorm實例間的雙向同步。當主實例1發生故障或者可用區A不可用時,用戶將訪問的連接切換至備實例2或者可用區B,從而實現高可用,主備容災的高可用架構圖如下所示。
主備容災的方案雖然能夠滿足大部分用戶的高可用需求,但是這種主備容災方案并不適用所有的業務,存在以下不足之處:
主備實例的數據同步存在延遲,無法滿足強一致需求。
主備實例的數據同步鏈路為異步鏈路,也就是當業務數據寫入主實例1后,數據在備實例2不是立即可見的,存在一定的延遲。當發生主備切換操作時,業務并不能立刻讀到最新的數據,這是一些業務無法接受的。如果業務使用了Increment、CheckAndPut等先讀后寫的原子語義接口,并且沒有讀到最新數據,那么就會導致數據錯亂或者回退。如果可用區A的網絡存在故障,由于同步延遲問題,在可用區A網絡恢復之前的時間段內可用區B的數據會一直處于缺失的狀態。
備實例資源利用率不高。
在主備容災下,大部分時間備實例的資源不會被使用,只有在主備切換操作的時候才會被訪問。
主備切換需要數據庫管理員實施。
目前主備容災完全由業務自行完成,業務的DBA需要時刻注意主實例的運行情況。在主實例發生故障時,DBA決定是否需要切換為備實例。并且切換的邏輯和方案都需要用戶自行去定制,對業務不透明。
總的來說,傳統的主備容災存在以上問題,但云原生多模數據庫Lindorm多可用區部署可以完全解決這些不足之處。
Lindorm多可用區架構
云原生多模數據庫 Lindorm支持多可用區部署,Lindorm實例寬表的Partition會在每個可用區中存在一個獨立的副本,同時日志WAL會存儲至底層的可用區C云原生分布式存儲Lindorm DFS中。如果可用區A完全不可用,可用區B通過可用區C的數據完成數據的恢復。副本間的數據同步由Lindorm內置的Replica Consensus協議完成,Replica Consensus協議只需要存儲至少兩個副本的數據就可以完成數據同步。在多可用區部署模式下,Lindorm支持設置表的一致性級別來實現不同的業務需求,包括強一致和最終一致。
強一致:如果將表設置為強一致,那么只有表的主Partition可以讀寫,備Partition只能通過Replica Consensus協議接收數據。當主可用區的地域所有機器都終止工作或者可用區不可用時,Lindorm會自動觸發選擇主可用區操作,備可用區需要一定的時間恢復才能切換為主可用區。強一致模式下,用戶可以讀取最新寫入的數據。
最終一致:如果將表設置為最終一致(也稱為弱一致),那么表的主備Partition都可以讀寫,Replica Consensus協議是將可用區A寫入的數據同步至可用區B中,由于數據同步是異步的,所以兩個副本之間的數據會存在不一致(通常在100ms量級)。最終一致模式下,由于表的主備Partition都可以讀寫,當可用區A不可用、表讀寫出現毛刺和機器終止工作等故障時,超過一定的時間不會返回訪問結果,無需等待和系統切換主可用區的過程,Lindorm會自動選擇可用區B發送請求,達到高可用和降低讀寫毛刺的效果。
功能特性
雖然云原生多模數據庫 Lindorm是分布式架構,本身具有高可用性,但是一些對可用性要求高的業務,會有更高的要求。業務不但需要Lindorm能應對部分機器故障的問題,還必須能夠應對網絡不可用以及城市災難等極端問題。為了保障數據庫在各種意外情況下都能持續提供服務,云原生多模數據庫 Lindorm多可用區部署支持以下功能特性:
具備機房級或者城市級容災能力。
滿足Lindorm實例的數據強一致或者最終一致需求。
故障識別和切換操作都是由Lindorm自動觸發,易用性高。
Lindorm多可用區方案與傳統主備容災方案、基于Paxos/Raft一致性協議的高可用方案的功能特性對比,如下表所示:
功能特性 | 多可用區 | 主備容災 | 基于Paxos/Raft一致性協議 | |
強一致 | 最終一致 | |||
數據丟失(RPO) | 0 | <100ms | <1s | 0 |
服務恢復(RTO) | 1分鐘 | 10~30s | 由主備切換的時間決定。 | 30s~3分鐘 |
訪問RT | 主可用區訪問,可能存在跨多可用區讀寫。 | 就近訪問,支持多區域讀寫可降低毛刺。 | 主可用區訪問,可能存在跨多可用區讀寫。 | 主可用區訪問,可能存在跨多可用區讀寫。 |
易用性 | 對業務透明。 | 對業務透明。 | 業務需改造,外置同步鏈路,用戶自行切換。 | 對業務透明。 |
最小需要存儲日志和數據的可用區數目 |
|
|
|
|
可以看出相較于傳統主備容災方案、基于Paxos/Raft一致性協議的方案而言,Lindorm多可用區架構數據訪問更靈活,服務恢復耗時更短且易用性更高。
無論是強一致還是弱一致,在Lindorm多可用區部署下,Lindorm實例寬表的故障識別,切換都由Lindorm實例自行決定,整個過程對用戶透明,并且用戶一直訪問一個Lindorm實例,無需再開發中間件來連接多個實例和實例間的切換。
如果業務沒有強一致的需求,建議選擇Lindorm多可用區實例,并設置表為最終一致。
如果業務有強一致的需求,建議選擇Lindorm多可用區實例,并設置表為強一致。
使用限制
多可用區部署僅適用于寬表引擎,因此不支持同時依賴其他引擎能力的功能,即搜索索引和列存索引。寬表引擎自身支持的其他功能如二級索引、動態列、通配符列可正常使用。
多可用區實例不支持冷存儲、冷熱分離功能。
購買多可用區實例
您可以通過控制臺購買云原生多模數據庫 Lindorm多可用區實例,具體操作請參見創建實例。
使用多可用區實例
一致性選擇
一般情況下,云原生多模數據庫 Lindorm實例新建的表都會默認設置為最終一致,最終一致可以滿足大部分用戶的需求,達到高可用和降低毛刺的效果。因此推薦使用最終一致性模型。事實上,絕大部分的業務都能接受讀取100 ms前的數據,而且Lindorm的客戶端支持就近讀寫,如果用戶的讀寫客戶端在同一可用區,大部分情況下客戶端讀到的都是最新數據(沒有因為毛刺或者機器終止工作導致當前可用區的partition不可用或者超時等情況)。如果您的業務有以下需求,需要將表設置為強一致。
必須要讀到最新數據。
使用Increment、CheckAndPut等先讀后寫的原子語義接口。
需要為表建立二級索引。
強一致模式下,Lindorm無法通過讀取多副本的方式來減少抖動和毛刺,如果主可用區出現故障,備可用區需要一定的時間恢復才能切換為主可用區。
建表并設置表的一致性
由于HBase API和HBase Shell不支持一致性概念,如果您使用HBase API訪問Lindorm寬表引擎,請使用HBase API和HBase Shell創建表(創建的表默認設置為最終一致性)后,再使用以下步驟對表屬性進行修改。
通過Lindorm-cli連接并使用寬表引擎,使用SQL訪問Lindorm寬表引擎。
設置表一致性。
創建表格時,通過以下語句設置表為強一致。
CREATE TABLE dt ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='strong');
創建表格時,通過以下語句設置表為最終一致。
CREATE TABLE dt2 ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='eventual');
創建表格后,通過以下語句修改表屬性為最終一致。
ALTER TABLE dt SET CONSISTENCY='enventual';
創建表格后,通過以下語句修改表屬性為強一致。
ALTER TABLE dt2 SET CONSISTENCY='strong';
數據寫入
Lindorm多可用區版本與單可用區版本的使用方式完全一樣。連接Lindorm寬表引擎并寫入數據,具體操作請參見通過Lindorm-cli連接并使用寬表引擎。
數據導入
使用API方式將數據導入Lindorm多可用區版本與單可用區方法相同,使用控制臺上提供的連接地址即可。
使用bulkload方式導入Lindorm多可用區版本,需要在兩個可用區都導入一份數據,相關使用咨詢方法請參見技術支持。