国产亚洲日韩av在线,中国熟妇牲交视频,日韩一卡二卡三卡四卡无卡免费视频

云原生多模數據庫 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一致性協議
功能特性	強一致	最終一致	主備容災	基于Paxos/Raft一致性協議
數據丟失（RPO）	0	<100ms	<1s	0
服務恢復（RTO）	1分鐘	10~30s	由主備切換的時間決定。	30s~3分鐘
訪問RT	主可用區訪問，可能存在跨多可用區讀寫。	就近訪問，支持多區域讀寫可降低毛刺。	主可用區訪問，可能存在跨多可用區讀寫。	主可用區訪問，可能存在跨多可用區讀寫。
易用性	對業務透明。	對業務透明。	業務需改造，外置同步鏈路，用戶自行切換。	對業務透明。
最小需要存儲日志和數據的可用區數目	存儲日志：3個存儲數據：2個	存儲日志：2個存儲數據：2個	存儲日志：2個存儲數據：2個	存儲日志：3個存儲數據：3個

可以看出相較于傳統主備容災方案、基于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多可用區版本，需要在兩個可用區都導入一份數據，相關使用咨詢方法請參見技術支持。

日本熟妇hd丰满老熟妇,中文字幕一区二区三区在线不卡 ,亚洲成片在线观看,免费女同在线一区二区