容灾系统的主要目标在于担保系统数据和做事的“连续性”。当系统发生故障时，容灾系统能够快速规复做事和担保数据的有效性。为了防止天灾人祸、不可抗力，在同城或异地建立对应的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
本文为阿里云原创内容，未经许可不得转载
