文档

多可用区部署

更新时间:

云原生多模数据库 Lindorm支持创建多可用区的实例。该方案将一个Lindorm实例部署在多个可用区,多可用区实例具备更高的容灾能力,同时Lindorm实例可以实现多个可用区之间数据的强一致,也可以在数据最终一致下发出请求返回最快的结果,从而提高在线业务的服务质量。

传统的主备容灾概述

传统的主备容灾为了实现高可用性,通常的原理是分别在两个不同的可用区(可用区A和可用区B)中购买一个Lindorm实例(主实例1和备实例2),使用数据通道服务(简称LTS)实现Lindorm实例间的双向同步。当主实例1发生故障或者可用区A不可用时,用户将访问的连接切换至备实例2或者可用区B,从而实现高可用,主备容灾的高可用架构图如下所示。

image

主备容灾的方案虽然能够满足大部分用户的高可用需求,但是这种主备容灾方案并不适用所有的业务,存在以下不足之处:

  • 主备实例的数据同步存在延迟,无法满足强一致需求。

    主备实例的数据同步链路为异步链路,也就是当业务数据写入主实例1后,数据在备实例2不是立即可见的,存在一定的延迟。当发生主备切换操作时,业务并不能立刻读到最新的数据,这是一些业务无法接受的。如果业务使用了Increment、CheckAndPut等先读后写的原子语义接口,并且没有读到最新数据,那么就会导致数据错乱或者回退。如果可用区A的网络存在故障,由于同步延迟问题,在可用区A网络恢复之前的时间段内可用区B的数据会一直处于缺失的状态。

  • 备实例资源利用率不高。

    在主备容灾下,大部分时间备实例的资源不会被使用,只有在主备切换操作的时候才会被访问。

  • 主备切换需要数据库管理员实施。

    目前主备容灾完全由业务自行完成,业务的DBA需要时刻注意主实例的运行情况。在主实例发生故障时,DBA决定是否需要切换为备实例。并且切换的逻辑和方案都需要用户自行去定制,对业务不透明。

总的来说,传统的主备容灾存在以上问题,但云原生多模数据库Lindorm多可用区部署可以完全解决这些不足之处。

多可用区架构

image

云原生多模数据库 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

主可用区访问,可能存在跨多可用区读写。

就近访问,支持多区域读写可降低毛刺。

主可用区访问,可能存在跨多可用区读写。

主可用区访问,可能存在跨多可用区读写。

易用性

对业务透明。

对业务透明。

业务需改造,外置同步链路,用户自行切换。

对业务透明。

最小需要存储日志和数据的可用区数目

  • 存储日志:3个

  • 存储数据:2个

  • 存储日志:2个

  • 存储数据:2个

  • 存储日志:2个

  • 存储数据:2个

  • 存储日志:3个

  • 存储数据:3个

说明

无论是强一致还是弱一致,在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创建表(创建的表默认设置为最终一致性)后,再使用以下步骤对表属性进行修改。

  1. 通过Lindorm-cli连接并使用宽表引擎,使用SQL访问Lindorm宽表引擎。

  2. 设置表一致性。

    • 创建表格时,通过以下语句设置表为强一致。

      CREATE TABLE dt (p1 integer, p2 integer, c1 varchar, c2 bigint,
        constraint pk primary key(p1 desc))'CONSISTENCY'='strong'; 

      创建表格时,通过以下语句设置表为最终一致。

      CREATE TABLE dt2 (p1 integer, p2 integer, c1 varchar, c2 bigint,
        constraint pk primary key(p1 desc))'CONSISTENCY'='eventual';
    • 创建表格后,通过以下语句修改表属性为最终一致。

      ALTER TABLE dt SET 'CONSISTENCY'='eventual'; 

      创建表格后,通过以下语句修改表属性为强一致。

      ALTER TABLE dt2 SET 'CONSISTENCY'='strong';

数据写入

Lindorm多可用区版本与单可用区版本的使用方式完全一样。连接Lindorm宽表引擎并写入数据,具体操作请参见通过Lindorm-cli连接并使用宽表引擎

数据导入

  • 使用API方式将数据导入Lindorm多可用区版本与单可用区方法相同,使用控制台上提供的连接地址即可。

  • 使用bulkload方式导入Lindorm多可用区版本,需要在两个可用区都导入一份数据,相关使用咨询方法请参见技术支持