随着互联网普及,5G、云计算、大数据等新型技术不断发展,普通用户能够接触到的资讯、服务越来越广泛,使得原本只需要服务特定区域的信息系统需要服务的客户群体越来越大,需要处理的数据量也越来越多。与此同时,数字化时代也使得数据变成了企业核心资产,数据成为新的生产要素。
一、异地多活是摆在企业面前的迫切问题
对于数据资产安全、持续访问、灾备等方面的刚性需求,也使得中小企业将目光从传统单节点应用模型上移开,寻找分布式的可替代方案。
本文主要讨论两个问题:
1、如何保证数据量不断增大的情况下,信息系统的响应速度不变
2、如何更好的对数据进行容灾
信息系统中的软件部分,主要分为应用程序和数据库。
应用程序本身可以是无状态的,其可用性和横向扩展都很好实现,只需要部署多套应用程序,使用负载均衡的软件或者硬件将请求进行转发,就能实现性能的线性提升。针对单节点故障,也只需要在转发层屏蔽掉故障节点。
二、常见数据库架构
分布式中的最大难点还是在于数据库,无论是针对性能的线性扩展,还是单点故障的容灾,都比较复杂。针对数据量增大,性能需求的问题,业界比较常见的数据库架构主要分为下述几类,以下逐个优劣进行分析:
共享存储集群
读写分离机群
MPP数据库
分库分表
1、 共享存储集群
共享存储集群的典型代表为 Oracle RAC。使用共享的存储硬件,多个数据库实例一般部署在同一个机房内,可以横向扩展数据库的并发性能,由于受制于共享存储的性能,一般最大可以扩展到4 - 6节点。其灾备能力仅限于单节点故障,如果不同节点部署在不同的机架,还可以抵抗机架故障。但由于本身数据仅有一套,为了保证数据可靠性,一般要配备硬件或者软件的数据同步组件进行数据的实时灾备。
2、读写分离机群
此种方案以金仓Kingbase ES V8读写分离机群为代表,主库负责读和写操作,备库仅负责针对读操作的负载分离。其优点是在同一时刻,数据有多个副本,发生故障时,只需要将其中一个备库升级到主库,不用担心数据丢失的风险。
当应用于读多写少的应用场景时,会有很大的性能提升;受制于主库写能力的限制,当应用中写多读少时,性能则会受到一定限制。此类数据库集群一般部署在单机房内,可以抵抗单点故障和机架故障。
3、MPP集群
MPP数据库集群以金仓KADB为代表,在大规模数据分析(OLAP)领域优势明显,但在OLTP场景中表现不如读写分离机群和共享存储集群。横向扩展能力强,可以支撑规模更大的应用查询场景、支持单机房内的单点故障转移。
4、异地多活
异地多活方案常见于大型互联网企业,不同的用户访问被定向到不同的数据中心。比如针对用户表的访问,阿里会根据user ID做hash,将主数据存储在不同机房;饿了么会将同一区域的user存储在距离较近机房。
应用访问数据时,路由层会根据访问的数据分片信息,将请求路由到主数据所在的机房,针对横向扩展,只要尽可能多的对应用逻辑进行分解,将不同的应用逻辑分片到不同的数据节点甚至数据中心。
采用数据同步的方式让每个数据节点或者数据中心都存储全量数据,当某个节点或者数据中心发生故障失效时,其灾备节点或者中心即可接管。同时,对于每份数据的灾备数据,还可以承担查询的负载,进一步增加系统的整体吞吐量。此方案无论从大规模应用的并发访问,还是数据异地容灾,都有比较明显的优势。
三、异地多活面的难点和金仓解决方案
异地多活场景中,数据库主要面临以下问题:
数据同步的时效性保证
数据同步正确性保证
数据回环的处理技术
数据重复和数据冲突的解决
下面,以金仓异构数据同步软件 Kingbase FlySync(以下或称KFS) 为例,逐一攻克异地多活中的重重障碍,助力企业实现数据访问的性能提升和数据容灾。
1、高性能同步方案解决数据延迟困扰
金仓数据库同步软件KFS基于数据库日志硬解析,使用流水线技术最大限度释放多核服务器的CPU性能。同时,Kingbase FS 还支持并行多通道数据解析。实际测试场景中,数据同步速度可以到亚秒级,每日分析增量数据库日志最大3.5 TB。
2、增量数据落盘,保证同步内容可追溯
针对数据同步正确性保证,Kingbase FlySync会将增量数据存储到中间文件,以中间文件的记录为单位进行数据传输,保证性能的同时,让同步内容可追溯,免去用户面对黑盒的焦虑感。
同时,Kingbase FlySync还提供图形化的数据比对工具,让用户对数据同步的效果一目了然,支持丢失数据的手动同步。
3、切断数据同步回环,保证数据不重复
针对多主场景数据同步场景下的数据回环问题,Kingbase FlySync 和金仓数据库 Kingbase ES 深度结合,在Kingbase FlySync写往数据库的日志记录中,增加特殊标识,避免Kingbase FlySync应用到数据库的数据被重复解析,打断数据回环。
4、基于事务的增量数据解析和应用机制
基于深厚的数据库背景和技术沉淀、Kingbase FlySync在设计时,无论是数据的解析、还是传输和数据加载,都以事务为单位。基于此,Kingbase FlySync在数据加载时,在事务内记录检查点,如果目的端数据在应用数据时事务回滚,也可以保证 Kingbase FlySync 在合适的点进行数据重放。
三、金仓异地多活方案的实际部署方式
本节以某实际项目为例,介绍Kingbase FlySync 异地多活的部署方案。
1、整体架构
KingbaseFlysSync使用独立服务的形式,将本地数据传输至其他数据库节点以完成同步的目的。多主集群的原理,即使用多个服务,分别从每个数据库节点向集群中其余数据库节点分发数据,保证了数据库集群中所有数据节点数据保持一致。
2、部署方式
根据下面的配置信息,填写各个节点的 flysync.ini 文件后,在各个节点执行。
命令完成本地的部署
(1)Host1配置
配置文件
配置文件说明:
a. 绿色字体内容,集群中所有服务都一致,代表本地数据库的链接信息。
b. 蓝色字体中,源端使用了过滤器,只同步集群中需要同步的数据表(避免元信息表同步)
c. 红色字体中标记的端口号,为了避免冲突,除了本地master节点外(默认3112),其他的slave都需要配置成不一样的,并且不能是3112
d. 其他参数含义参见KingbaseFlySync部署手册
(2)Host2配置
配置文件
和host1配置文件,不同的点参见红色和绿色字体标识:
a. members全部改为 host2
b. replication-host 全部改为 host2
c. master 根据服务本身,填写正确的master信息
(3)Host3配置
配置文件
和host1配置文件,不同的点参见红色和绿色字体标识:
a. members全部改为 host3
b. replication-host 全部改为 host3
c. master 根据服务本身,填写正确的master信息
(4)Host4配置
配置文件
和host1配置文件,不同的点参见红色和绿色字体标识:
a. members全部改为 host4
b. replication-host 全部改为 host4
c. master 根据服务本身,填写正确的master信息
3、集群扩容
假设集群中需要加入主机名为 host5的节点,扩容步骤如下:
(1)新节点配置
配置文件
和已经存在的4个节点的配置文件区别:
a、增加了关于host5作为主节点的信息 host5master
b、其他参数含义和之前相同
完成flysync.ini文件配置后,在新节点执行如下命令:
(2)旧节点配置
在所有其他已经存在的节点 flysync.ini 文件中,加入以下配置:
除了红色字体中标记的和本地节点相关的配置参数,需要改成本机主机名外,其他参数保持不变。完成flysync.ini文件配置后,在旧节点执行如下命令:
4、集群缩容
假设要去掉已经存在的节点host4,操作步骤如下:
(1)被缩容节点操作
a. 在host4上执行如下命令:
b. 手动删除 ~/fskingbase 目录
c. 手动删除 flysync.ini 文件
(2)其他节点操作
a. 在其他节点上执行如下命令:
b. 手动删除掉本地 flysync.ini 文件中,关于 host4master 的服务信息
四、结语
突破业务瓶颈,摆脱单点故障,基于 Kingbase FlySync构建异地多活数据库集群,助力企业轻松应对数字化背景下海量数据进行存储计算、分析处理、同步更新等需求。