从数据库视角,谈多云容灾系统构建
在《火山引擎多云容灾架构下的流量调度实践》一文中,我们介绍了接入层和应用层的容灾实现,下一步就需要考虑如何实现数据库的跨云容灾方案,以期在极端场景下,确保业务稳定可靠持续性运转。
在当今数字化时代,数据库跨云容灾至关重要。数据库跨云容灾的主要目标是确保在面临各种灾难场景(如自然灾害、硬件故障、网络攻击等)时,数据库能够保持可用性和数据完整性,最大程度减少业务中断时间,保障企业业务的连续性。具体目标包括:
数据零丢失:在灾难发生时,确保数据库中的所有数据都能得到完整保护,不会出现数据丢失的情况;
快速恢复:能够在最短的时间内将数据库恢复到正常运行状态,减少业务停机时间,降低对业务的影响;
业务连续性:保证在容灾切换过程中,业务能够持续运行,不出现明显的中断或服务降级。
在应用容灾的基础上,实现数据库跨云容灾并非易事,目前业内在面对数据库同步上,需要注意以下问题:
数据一致性:由于数据在不同云环境之间传输和同步,可能会出现数据一致性问题,如数据延迟、重复或丢失;
网络延迟和带宽限制:跨云的数据传输可能受到网络延迟和带宽的限制,影响数据同步的效率和实时性;
成本控制:构建跨云容灾架构需要投入大量的资源,包括硬件、软件、网络等,如何在满足容灾需求的前提下控制成本是一个关键问题;
测试和演练难度:由于跨云环境的复杂性,进行全面的容灾测试和演练难度较大,难以确保在实际灾难发生时能够顺利切换。
在此基础上,目前业内常见的数据库容灾方案主要包括以下几个阶段,从业务改造范围视角逐步扩大容灾范围,主要包括了业务多云拆分、多云应用双活、单元化业务双活到最终实现单元化多云多活。
假设企业同时使用 A 云与火山引擎云服务,整体数据库跨云容灾将分为以下几个阶段:
正常情况下:源端数据库承担生产流量,提供读写能力,火山引擎侧只提供灾备能力;
灾难发生时:
方案 1:按照最小故障半径,仅切换故障数据库
方案 2:按照全局稳定性状态考虑,直接从流量入口处切换到火山引擎
灾难恢复后:
先进行数据回溯,确保源端数据与火山引擎对齐
再进行流量切换,切换后整体流量回切回源端云
在上面的例子中,数据库传输服务 DTS(Database Transmission Service)是一种集数据迁移、同步和订阅于一体的数据流服务,支持关系型数据库、非关系型数据库等数据源间的数据交互,降低数据库之间数据流通的复杂性。
它可以帮助用户在业务不停服的情况下轻松完成数据库迁移上云,通过实时同步通道轻松构建高可用数据库容灾架构,同时可以根据自身需求自由消费数据订阅提供的云数据库实时增量数据。
◇2.2.1 产品优势
数据库传输服务 DTS 支持关系型数据库、非关系型数据库的数据传输。相较于第三方迁移工具,数据库传输服务 DTS 可以更方便地创建和管理丰富多样、高性能、高安全可靠的传输链路。
场景丰富多样:
支持多种数据库引擎迁移,将迁移过程引起的业务中断时间窗口缩短至分钟级;
支持通过公网网络和 VPC 私有网络环境下的数据传输;
支持迁移任务配置仅增量迁移,实现源库至目标库纯增量同步。
操作简便可视:
提供可视化管理界面,提供向导式任务配置,客户可以轻松完成数据迁移;
迁移进度量化展示,控制台显示全量迁移百分比和增量迁移数据延迟时间;
图形化展示全量和增量迁移的迁移速率,支持实时调整链路规格,最大化链路资源利用。
数据安全可靠:
实例高可用,节点具备高度的恢复和治愈能力,秒级恢复;
支持断点续传,链路异常中断恢复正常后,能够自动追加中断时间段的数据。
◇2.2.2 容灾场景下需要使用的产品能力
在容灾场景下,为了保障企业数据的可用和完整,我们需要利用数据库传输服务,实现源库到目标库到结构、全量、增量数据同步,同时动态进行同步对象选择,实现数据自由流动。
数据库传输服务主要会在以下几个容灾场景使用:
正常情况下:帮助容灾链路实现源库到目标库到不停服数据库同步,确保目标端数据库的数据和源端对齐;
灾难恢复时:在灾难恢复后,需要通过数据库传输服务,实现目标端新写入数据的回传。利用 DTS 按时间点增量同步能力,快速定位到需要同步的 binlog 文件并实现增量数据回传。确保源端和目标端数据完全一致。
很多企业在进行业务容灾时,常常会考虑冷备数据库额外的成本问题。在常规容灾基础上,火山引擎数据库团队综合提供了冷热分离、HTAP 轻分析等增值功能,可以帮助业务在实现容灾的基础上,进一步达成业务增值。
在容灾场景下,大部分企业会降低计算节点资源,但存储资源因需全量容灾,需全量备份,因此存储空间的容灾会产生额外的费用。通过使用火山引擎云冷热分离架构,我们可以帮助业务保存高频查询数据,在灾难发生时,切换到火山引擎集群(冷热均可访问),在灾难发生后尽快实现冷数据转热,满足业务读数据需求。
在数据转冷后,整体读写性能会有一定降低,具体的性能参数可以参考如下逻辑:
450GB 表大小,冷热互转,耗时 20min;
冷数据的查询性能:
点查 P99 耗时 15ms 左右
范围查询且索引包含返回字段 P99 耗时 50ms
范围查询且索引不包含返回字段 P99 耗时 15s
如果业务可以接受冷存的查询性能,无需数据回热即可直接对外提供服务;如果业务需要更高查询性能,可以通过数据回热到分布式存储,继续提供高性能数据查询能力。
在容灾前提下,企业可以将部分对时延不敏感的业务部署在火山引擎侧,满足分析型业务部署在容灾实例侧的云端。分析型业务对数据时效性不敏感,且仅有读业务,通过复用容灾实例的计算及存储资源,高效实现分析类业务查询。
这样操作的优势有:
TP/AP 在内核侧自动分流,用户无需在业务侧手动分流;如需分流,可通过 Proxy 进行分发;
基于内核的自动分流能力,用户在单业务口可以同时享受 索引执行 以及 向量化执行的查询加速能力;
HTAP 执行节点采用 MPP 架构,可实现弹性扩缩容;
支持 Insert into 事务表 Select from AP 表。
不同云之间的 API、服务协议和基础架构存在差异,这给数据库跨云容灾带来了巨大挑战。通过使用标准的开源产品以及 terrform 等第三方平台,将跨云的数据库产品统一纳管到企业自身的多云管理平台上是较好的处理方式。
在完成应用云原生改造后,如果企业能在继续实现数据层的容灾基础上,充分利用容灾端存储计算资源,搭配数据库等冷热分离、HTAP 等能力,在保障高安全的同时实现分析提效,可以将“降本增效”做到极致。
例如,某企业在使用了火山引擎提供的容灾服务后,通过建设容灾+分析服务的融合场景,实现了容灾场景下的极致性价比,帮助该企业在获得高安全业务使用的同事,提升了整体业务处理性能。该企业的整体改造和业务逻辑如下:
正常情况下:
业务层:双边的应用对源端数据库实现单边读写
数据传输层:通过 DTS 实现单向同步,通过 DTS 实现多表合并,实现大表融合查询
火山引擎数据库实例状态实例:
数据库实例除 DTS 账号外,其他账号只拥有只读权限,数据库仅提供 AP 分析服务
仅保留分析服务节点,计算资源量缩容
其他部分的存储资源转冷
在发生灾难时:TP 业务承载 + AP 分析服务
对火山引擎的计算资源进行扩容相关操作
将存储资源转热,提升数据读性能
AP 分析服务继续使用
通过火山引擎容灾分析整体方案的改造,该企业在原来容灾场景需要费用翻倍的情况下,仅通过增加 30% 的成本预算,就实现了业务鲁棒性和可用性的改造。未来该企业预期进一步缩减源端分析服务的使用费用,力争在整体不增加预算的前提下,实现容灾方案的建设。
火山引擎云基础团队背靠字节跳动大规模技术实践,致力于为用户提供安全可靠、高性价比的云服务。在多云容灾架构方面,云基础团队基于云上多款产品,构建多云资源分发、智能 DNS 切换、跨云流量调度、多云容灾观测、双向数据同步的一站式解决方案,致力于帮助客户构建多云应用发布、数据层同城高可用、中间件同城高可用、容灾平台构建、应用单元化改造最佳实践,在满足资源弹性伸缩的同时保障业务连续稳定。欢迎感兴趣的用户咨询: