共计 7083 个字符,预计需要花费 18 分钟才能阅读完成。
简介:容灾零碎的重要指标在于保证系统数据和服务的“连续性”。当零碎产生故障时,容灾零碎可能疾速复原服务和保证数据的有效性。为了避免天下大乱、不可抗力,在同城或异地建设对应的 IT 零碎,其中最外围的工作是数据同步。本文选取应用层容灾的场景中,对于哪些数据表须要跨云同步,哪些数据表不须要跨云同步的问题进行探讨。通过一个具体的案例,帮忙读者更好地梳理同步表和过滤表的办法,以满足应用层的业务容灾需要。
一 背景
容灾零碎的重要指标在于保证系统数据和服务的“连续性”。当零碎产生故障时,容灾零碎可能疾速复原服务和保证数据的有效性。为了避免天下大乱、不可抗力,在同城或异地建设对应的 IT 零碎,其中最外围的工作是数据同步。
本文选取应用层容灾的场景中,对于哪些数据表须要跨云同步,哪些数据表不须要跨云同步的问题进行探讨。通过一个具体的案例,帮忙读者更好地梳理同步表和过滤表的办法,以满足应用层的业务容灾需要。
二 相干术语
本文探讨的场景是基于阿里云构建的应用层容灾,波及到以下要害术语:
RDS MySQL:MySQL 版是寰球最受欢迎的开源数据库之一,作为开源软件组合 LAMP(Linux + Apache + MySQL + Perl/PHP/Python)中的重要一环,广泛应用于各类利用场景。阿里云 RDS MySQL 版,通过深度的内核优化和独享实例提供稳固极致的数据库性能,同时灵便的部署架构及产品状态,可满足不同场景下的数据库需要。
DTS:数据传输服务 (Data Transmission Service) 反对关系型数据库(MySQL 等)、NoSQL、大数据(OLAP) 等数据源间的数据传输。它是一种集数据迁徙、数据订阅及数据实时同步于一体的数据传输服务。数据传输致力于在公共云、混合云场景下,解决远距离、毫秒级异步数据传输难题。应用数据传输轻松构建平安、可扩大、高可用(容灾)的数据架构。
ASR:ASR-DR(Apsara Stack Resilience Disaster Recovery)是一款提供容灾性能的云产品,反对 RDS MySQL 的容灾治理。ASR 是为了在劫难产生时,疾速地实现容灾切换,尽可能地升高 RTO,而开发的基于图形交互的切换工具。
同步表:本文特指 RDS MySQL 的数据库和数据表中,哪些表必须从一朵云备份到另外一朵云,即跨云同步。
过滤表:本文特指 RDS MySQL 的数据库和数据表中,哪些表不能或不须要,从一朵云备份到另外一朵云。
利用配置表:本文特指应用层在 RDS MySQL 中的数据表,这个表记录应用层的相干配置信息,比方 IP、域名、定时工作的开关状态等等。
Sequence:全局惟一序列号 ID,在分布式系统外面利用宽泛,可用于交易流水号,用户 ID 等。在搜寻, 存储数据, 放慢检索速度等等很多方面都有着重要的意义。这个 ID 经常是数据库的主键,要求全局惟一、反对高并发、容错单点故障。为了进步性能,应用层通常每次从数据库中获取一批序列号(比方 1 万个),寄存到利用内存中应用,防止频繁拜访数据库。内存中的序列号应用实现后,再次从数据库中进行获取新的一批序列号。
三 利用容灾中对于过滤表的关键技术问题
为什么须要梳理不做跨云同步的过滤表?
非容灾利用
- 备核心资源限度:理论我的项目中,受限于备核心的资源限度,无奈在备核心内部署利用零碎,因而非容灾的利用对应的数据库和数据表无需同步。
- 运维长期备份库和备份表无需同步:在日常运维中,DBA 在对数据库进行变更时,通常会做临时性备份。长期备份的数据库或数据表,因为阿里云 RDS MySQL 集群自身曾经在后盾进行了备份,无需用户再做一次跨云同步。这样能够缩小同步链路的带宽和容灾切换的治理工作量。
- 不反对容灾的利用:云产品的容灾能力建设是一个继续过程,某些云产品在我的项目交付阶段临时还不具备容灾能力,然而用户的利用依赖了这些指定的云产品。因而这部分的利用临时无奈做容灾演练,对应的数据库和数据表也能够临时不做同步。待利用的全流程依赖的云产品都反对容灾后,再进行数据同步即可。
有差别的配置表
- 利用配置的形式:利用零碎为了将代码和配置离开治理,通常将配置参数独自寄存和治理。常见的配置模式有配置文件、RDS MySQL 数据库、专用的配置核心,其中专用配置核心后盾也用了 RDS MySQL 来存储数据。比拟禁忌的形式是在代码中硬编码配置参数,如 IP、域名等。
- 环境参数:应用软件在应用云产品如 RDS MySQL、OSS、SLB 等产品时,须要通过 IP、域名、账号密码、AK/SK 进行连贯。
- 利用参数:某些性能只能在一个核心内的利用执行,这些性能开关在数据表外面的某些字段值进行管制。比方某些定时工作,会定期和内部机构产生批处理的调用。如果双核心的定时工作同时运行,可能会导致内部机构的批处理反复执行,这依赖于内部机构是否反对反复执行雷同的批处理工作。这些定时工作的配置表须要在双核心别离配置。
- 同城容灾的配置形式:第 2 点的环境参数默认是雷同的。同城一朵云的双核心间隔较近(小于 100 公里),利用部署在一朵云的两个可用区,云产品连贯信息是雷同的。因而应用软件在部署时,拜访的是雷同的环境参数。此场景中,须要梳理有差别的环境参数是比拟少的。
- 异地容灾的配置形式:第 2 点的环境参数存在差别。同城两朵云的双核心间隔较远(大于 100 公里),利用部署在两朵云的两个可用区,云产品连贯信息是不同的。因而应用软件在部署时,拜访的是不同的环境参数。此场景中,须要每个利用别离梳理差别的环境参数。差别的环境参数所在的数据表不能跨云同步,否则会导致利用零碎部署失败。
须要双写的业务表
- 双写的场景:a)业务流量在双核心同时解决,称为应用层双活,须要同时向双核心写入数据表。b)利用运行期记录微服务的调用日志等。现实状况下,应该是有业务流量在解决时,利用才会向数据库中记录数据。理论我的项目中,业务也会呈现非凡状况,在备核心的利用,即便没有流量申请,也会定期写入一些日志,比方微服务调用日志、定时工作日志、利用启动时更新全局惟一序列号 Sequence 等等。双写的场景,要求主核心和备核心的 RDS MySQL 都具备读和写权限。
- 同城双活场景:同城一朵云的双活架构中,主核心和备核心对应用层提供对立的云产品连贯信息,利用都具备向 RDS MySQL 的写入权限。
- 异地主备场景:异地两朵云的主备架构中,主核心 RDS MySQL 对应用层提供读写权限,而备核心 RDS MySQL 向应用层提供只读权限。这种权限策略无奈满足第 1 点中的双写要求。因而对于双写的表,须要依照利用维度梳理过滤表。
如何梳理不做跨云同步的数据表?
在我的项目中会发现,应用软件开发商更关注业务逻辑的实现,对于云产品应用的最佳实际以及容灾能力的理解水平,可能和咱们的预期存在肯定的差别。而梳理过滤表,次要由利用开发商来执行,在梳理过程中有几个常见的问题。
- 设计和开发期间,开发人员应该如何做来缩小容灾时候不同步的过滤表?
- 部署和运维期间,运维人员应该从哪些角度来确保过滤表的完整性和正确性?
如果梳理谬误,对应用层容灾演练有什么影响?
在我的项目中,往往受限于工期和生产零碎稳定性运行的束缚,利用开发商和云平台厂商即使分明设计和开发的最佳实际,也比拟难限时实现革新。因而部署和运维期的时候,梳理过滤表和筹备应急预案,是容灾演练的重点工作项。
咱们来剖析一下,如果梳理过滤表谬误,可能对应用层容灾有什么影响?
对非容灾利用的影响:
- 简直没影响。后面剖析过,倡议非容灾的利用能够不做数据备份,或者备核心利用在备份数据上不做为生产用处。
对容灾利用的影响:
- 备核心部署利用后,启动利用失败,此时可能辨认出谬误的环境参数。应答措施是进行对应数据表的同步,修改读写权限后持续部署。
- 备核心利用在测试性能时,重点关注后盾定时工作和非业务申请写 RDS MySQL 的场景,在测试阶段修改过滤表的清单。
- 对生产零碎运行期做容灾切换演练,在异地容灾架构中,谬误的过滤表清单可能会导致数据库主键写抵触的谬误,进而呈现写业务失败问题。此时可通过应急预案,紧急进行或减少同步性能或修改数据表字段值,重启利用形式的伎俩来复原。在下次演练前修改过滤表清单。本文前面将对此场景用一个案例简略阐明。
四 在利用容灾中设计不同步的数据表
后面咱们曾经介绍了利用容灾中哪些表不同步的必要性,本节咱们来探讨如何梳理和设置过滤表。以下剖析是比拟现实的状况,理论我的项目中会有一些差异。
云平台角度
- 理解云平台的能力:目前支流的云平台厂商都有 RDS MySQL 产品,然而每家厂商的 RDS MySQL 在同城多可用区和异地多 Region 中的容灾能力是有区别的。用户须要理解,每家云厂商的数据同步能力,在同城和异地两种状况下,是后盾主动实现?还是利用工具(如阿里云的 DTS)?还是人工写脚本实现?
- 配置过滤表的形式:阿里云 DTS 产品反对在创立 RDS MySQL 实例同步链路时,配置哪些数据库和数据表不同步。
- 主动配置过滤表性能:在容灾演练过程中,会波及主切备、备切主,因而对应数据同步方向产生反转,咱们称成为正向同步和反向同步。当产生同步方向反转时,须要容灾切换平台反对主动配置过滤表。阿里云 ASR-DR 反对第一次创立同步链路时,保留过滤表的清单,后续每次同步方向切换时,由 ASR-DR 主动给新的链路配置过滤表。
如下是阿里云数据数据传输服务 DTS 产品公开的材料文档。
应用层角度
接下来咱们从利用开发商比拟关注点几个阶段,剖析如何有效性地基于云容灾来交付应用软件。
1. 设计阶段:
- 基于云容灾的设计思路。思考利用将来会部署在两朵云或多朵云,有可能是不同厂商的云平台上。因而晚期基于 IOE 架构的容灾架构,由业余存储硬件实现的数据层同步在多云场景下将不实用,而 Oracle 低廉的 license 也是很多企业难以承受的。
- 思考为每朵云和每个核心预留标识参数,用于示意以后配置实用于哪朵云上。由配置核心对立治理以后运行环境上是哪朵云的参数失效,利用代码无需关注本人运行在哪朵云上。
- 辨认哪些场景的性能只能在其中一朵云上运行的,并为这些性能安顿开关。通过配置核心并将开关设置为可动静配置和失效。重点关注定时工作。
- 倡议将这些性能开关的操作放在白屏界面,便于在容灾切换无限而紧迫的工夫内,容许运维人员疾速操作,而不是打电话到处问人,敞开某个定时工作是在哪个库、哪个表的哪个字段来管制开关。
- 记录过滤表清单,并及时更新。
2. 开发阶段:
- 优先应用配置核心来保留参数。理论我的项目中,保留配置的形式有多种形式,包含配置核心、配置文件、RDS MySQL、甚至还有在代码中间接编码某个地址、账号密码。阿里云 EDAS 产品提供配置核心性能,反对动静配置、动态配置,以及配置变更后动静推送,而不须要利用重启能力失效。
- 配置核心自身的地址,能够记录在利用的配置文件中,将配置文件和应用程序一起打包公布。因为配置核心服务在部署后,很少会发生变化。
- 如果临时无奈应用配置核心,必须要用 RDS MySQL 来治理配置。倡议将记录不同云环境参数的配置放在独立的数据表中,独自提供性能开关的配置也放在独立的数据表中,不要和业务表耦合在一起。益处是升高了治理过滤表的难度。重点关注云产品的域名、IP、账号密码、AK/SK。
3. 部署阶段:
- 运维人员和开发人员,确认分明每个过滤表的被选中的起因,背地的业务根据是什么?重点关注是否多配了过滤表。
- 登陆每个数据库,查看容灾切换平台 ASR-DR 是否依照预期来设置过滤表。当过滤表有上百个的时候,容易呈现脱漏或谬误。
- 创造条件在备核心上提前验证业务性能,重点关注过滤表场景是否合乎预期,关注定时工作是否只在一个核心上运行。
4. 运维阶段:
- 配置变更在两朵云上的过滤表同时执行。当在主核心上对过滤步表进行了变更后,如减少字段或调整字段类型,备核心无奈感知到,须要手工在备核心上做同样的批改。否则容灾切换到备核心后会因为表未更新导致利用谬误。
- 过滤表复原为同步表。晚期梳理过滤表清单有误,多配置了过滤表,起初验证须要同步。须要从新对数据表做全量数据同步,并在容灾治理平台 ASR-DR 上批改这个表是否同步的标记。
- 同步表改为过滤表。晚期同步的表,因为业务做了调整,后续无需再同步,须要在容灾治理平台 ASR-DR 并在容灾治理平台 ASR-DR 上批改这个表是否同步的标记。
下图为异地容灾主备架构下,同步表和过滤表的配置逻辑阐明。
五 案例
上面剖析一个异地容灾的我的项目中,因为过滤表清单梳理谬误,导致业务异样问题及解决教训,便于读者对数据表是否须要跨云同步更有体感。
(1)问题形容
在阿里云容灾平台 ASR-DR 对某个利用执行容灾切换(RDS MySQL 读写权限从 Cloud A 切换至 Cloud B)后,业务申请在备核心(Cloud B)时,业务报错,数据库提醒“主键抵触”。
(2)问题剖析
咱们依据问题解决的先后顺序,对问题定位过程进行剖析。
1. 剖析数据库报错“主键抵触”:
- 确认抵触的字段值为交易流水号 ID。查看业务数据表,确认这个 ID 的交易信息曾经存在。
2. 剖析业务申请门路:
- 剖析是否接入层流量调度异样导致的双写。在异地容灾的主备架构中,通过接入层的全局负载平衡设施 GSLB 管制,保障只有主核心有业务申请流量,备核心没有业务申请流量。因而双核心业务双写导致的主键抵触的嫌疑能够排除掉。
- 剖析是否为主核心应用层缓存在主备切换后提早写入数据。在主备架构中,容灾平台 ASR-DR 平台会保障主核心的 RDS MySQL 数据库权限设置为只读后,才会对备核心的利用凋谢对 RDS MySQL 的读写权限。即便主核心的应用层有缓存提早写入,在容灾切换后,主核心利用没有权限写入数据,不会呈现双写场景。排除此嫌疑。
- 剖析是否为容灾切换前已应用了该序列号。登陆主核心的数据库,查看序列号字段以后可用范畴是[90000000000, 18446744073709551615],阐明小于 90000000000 的序列号曾经被应用。而以后提醒主键抵触的序列号 80000000000 曾经在业务表中有对应的交易记录。因而确认这个交易记录号是在主核心应用过了。
- 剖析备核心利用获取序列号的记录。从利用日志看到,备核心利用在首次启动时,获取了一次最新的序列号,前面没有再从数据库获取最新的序列号。同时查看利用的内存值,发现备核心以后正在应用序列号范畴[80000000000, 80000009999]。显然这是过期的序列号。
问题论断:备核心利用应用了过期的交易流水号 ID,导致的写数据库呈现“主键抵触”。
3. 剖析问题引入过程:
- 剖析利用获取序列号的流程:利用首次启动时,从数据库中获取 1 万个可用的序列号,并更新数据库和利用的内存值。
- 剖析主备核心上的数据同步机制:作为治理全局唯一性序列号的数据表 xx_table,通过数据同步工具 DTS 可能保证数据实时在双核心之间同步,且利用在更新数据库序列号时,对数据库加锁避免不统一。实践上不会呈现主备核心上获取到雷同的序列号。
- 剖析主备核心上数据表 xx_table 内容是否统一:发现主核心上的序列号可用范畴是[90000000000, 18446744073709551615],而备核心的序列号可用范畴是[80000010000, 18446744073709551615]。两者并不统一,阐明数据表并没有同步。
- 检查数据同步工具 DTS:工作失常,未发现任何谬误或故障。
- 查看过滤表清单:治理全局唯一性序列号的数据表 xx_table 应该跨云同步,然而却被配置为过滤表,导致了数据无奈同步。
- 查看过滤表的梳理过程:在容灾演练前的筹备阶段,运维人员在备核心部署利用后,业务人员验证性能交易失败。失败起因是利用启动时获取序列号后写数据库失败,提醒无写权限,因而交易性能初始化失败。在主备架构下,默认主核心利用对 RDS MySQL 有读写权限,备核心对 RDS MySQL 有只读权限。而备核心启动时须要些权限,因而业务人员将治理全局唯一性序列号的数据表 xx_table 退出到了不同步的过滤表清单中,导致这张表没有从主核心同步到备核心。
问题论断:治理全局唯一性序列号的数据表 xx_table 被谬误地退出到了不做跨云同步的过滤表清单
应急措施
- 手动将备核心的数据表 xx_table 中的序列号无效范畴,修改为正确的[90000000000, 18446744073709551615]。
- 重启备核心的应用软件,触发利用从新获取序列号。
改良措施
- 同步数据:治理全局唯一性序列号的数据表 xx_table 须要同步,从过滤表清单中移除 xx_table,确保主备核心的无效序列号范畴统一。
- 利用革新:当备核心对 RDS MySQL 有只读权限时,容许更新序列号失败,利用初始化胜利。当容灾切换后,备核心取得 RDS MySQ 读写权限后,由业务申请触发从新按需获取最新的序列号。
- 测试成果:主核心和备核心同步数据实现后,断开同步链路,手动设置备核心数据库为只读。重新部署革新后的利用,在只读模式下,验证利用启动胜利,并且业务申请失败(合乎预期)。手动设置备核心数据库为读写,业务申请胜利,查看利用是否胜利从新获取到无效序列号。重新配置主核心和备核心数据同步链路。
- 容灾演练:再次进行演练来验证全业务场景。
改良前
改良后
六 小结
- 容灾演练是发现系统性问题的终点,不是起点,须要定期发展演练来保鲜零碎的容灾能力。
- 云平台容灾不等于利用容灾,利用级容灾是系统性工程。
- 通过演练来查看工程能力,技术上包含云平台、利用和网络;流程上包含故障判断、容灾决策、切换操作、应急预案等。
作者:开发者小助手_LS
原文链接
本文为阿里云原创内容,未经容许不得转载