Lindorm支持创建多可用区部署_云原生多模数据库 Lindorm(Lindorm)-阿里云帮助中心

云原生多模数据库 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多可用区版本，需要在两个可用区都导入一份数据，相关使用咨询方法请参见技术支持。