简介：容灾零碎的重要指标在于保证系统数据和服务的“连续性”。当零碎产生故障时，容灾零碎可能疾速复原服务和保证数据的有效性。为了避免天下大乱、不可抗力，在同城或异地建设对应的 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
原文链接
本文为阿里云原创内容，未经容许不得转载