应用容灾中，MySQL数据表是否需要跨云同步？
Posted 阿里技术
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了应用容灾中，MySQL数据表是否需要跨云同步？相关的知识，希望对你有一定的参考价值。
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自动给新的链路配置过滤表。
基于云容灾的设计思路。考虑应用未来会部署在两朵云或多朵云，有可能是不同厂商的云平台上。因此早期基于IOE架构的容灾架构，由专业存储硬件完成的数据层同步在多云场景下将不适用，而Oracle昂贵的license也是很多企业难以接受的。
考虑为每朵云和每个中心预留标识参数，用于表示当前配置适用于哪朵云上。由配置中心统一管理当前运行环境上是哪朵云的参数生效，应用代码无需关注自己运行在哪朵云上。
识别哪些场景的功能只能在其中一朵云上运行的，并为这些功能安排开关。通过配置中心并将开关设置为可动态配置和生效。重点关注定时任务。
记录过滤表清单，并及时更新。
如果暂时无法使用配置中心，必须要用RDS MySQL来管理配置。建议将记录不同云环境参数的配置放在独立的数据表中，单独提供功能开关的配置也放在独立的数据表中，不要和业务表耦合在一起。好处是降低了管理过滤表的难度。重点关注云产品的域名、IP、账号密码、AK/SK。
运维人员和开发人员，确认清楚每个过滤表的被选中的原因，背后的业务依据是什么？重点关注是否多配了过滤表。
登陆每个数据库，检查容灾切换平台ASR-DR是否按照预期来设置过滤表。当过滤表有上百个的时候，容易出现遗漏或错误。
创造条件在备中心上提前验证业务功能，重点关注过滤表场景是否符合预期，关注定时任务是否只在一个中心上运行。
配置变更在两朵云上的过滤表同时执行。当在主中心上对过滤步表进行了变更后，如增加字段或调整字段类型，备中心无法感知到，需要手工在备中心上做同样的修改。否则容灾切换到备中心后会因为表未更新导致应用错误。
过滤表恢复为同步表。早期梳理过滤表清单有误，多配置了过滤表，后来验证需要同步。需要重新对数据表做全量数据同步，并在容灾管理平台ASR-DR上修改这个表是否同步的标志。
同步表改为过滤表。早期同步的表，由于业务做了调整，后续无需再同步，需要在容灾管理平台ASR-DR并在容灾管理平台ASR-DR上修改这个表是否同步的标志。
确认冲突的字段值为交易流水号ID。检查业务数据表，确认这个ID的交易信息已经存在。
分析是否接入层流量调度异常导致的双写。在异地容灾的主备架构中，通过接入层的全局负载均衡设备GSLB控制，保证只有主中心有业务请求流量，备中心没有业务请求流量。因此双中心业务双写导致的主键冲突的嫌疑可以排除掉。
分析是否为主中心应用层缓存在主备切换后延迟写入数据。在主备架构中，容灾平台ASR-DR平台会保证主中心的RDS MySQL数据库权限设置为只读后，才会对备中心的应用开放对RDS MySQL的读写权限。即使主中心的应用层有缓存延迟写入，在容灾切换后，主中心应用没有权限写入数据，不会出现双写场景。排除此嫌疑。
分析是否为容灾切换前已使用了该序列号。登陆主中心的数据库，检查序列号字段当前可用范围是[90000000000, 18446744073709551615]，说明小于90000000000的序列号已经被使用。而当前提示主键冲突的序列号80000000000已经在业务表中有对应的交易记录。因此确认这个交易记录号是在主中心使用过了。
分析备中心应用获取序列号的记录。从应用日志看到，备中心应用在首次启动时，获取了一次最新的序列号，后面没有再从数据库获取最新的序列号。同时检查应用的内存值，发现备中心当前正在使用序列号范围[80000000000, 80000009999]。显然这是过期的序列号。
分析应用获取序列号的流程：应用首次启动时，从数据库中获取1万个可用的序列号，并更新数据库和应用的内存值。
分析主备中心上的数据同步机制：作为管理全局唯一性序列号的数据表xx_table，通过数据同步工具DTS能够保证数据实时在双中心之间同步，且应用在更新数据库序列号时，对数据库加锁防止不一致。理论上不会出现主备中心上获取到相同的序列号。
分析主备中心上数据表xx_table内容是否一致：发现主中心上的序列号可用范围是[90000000000, 18446744073709551615]，而备中心的序列号可用范围是[80000010000, 18446744073709551615]。两者并不一致，说明数据表并没有同步。
检查数据同步工具DTS：工作正常，未发现任何错误或故障。
检查过滤表清单：管理全局唯一性序列号的数据表xx_table应该跨云同步，但是却被配置为过滤表，导致了数据无法同步。
检查过滤表的梳理过程：在容灾演练前的准备阶段，运维人员在备中心部署应用后，业务人员验证功能交易失败。失败原因是应用启动时获取序列号后写数据库失败，提示无写权限，因此交易功能初始化失败。在主备架构下，默认主中心应用对RDS MySQL有读写权限，备中心对RDS MySQL有只读权限。而备中心启动时需要些权限，因此业务人员将管理全局唯一性序列号的数据表xx_table加入到了不同步的过滤表清单中，导致这张表没有从主中心同步到备中心。
手动将备中心的数据表xx_table中的序列号有效范围，修正为正确的[90000000000, 18446744073709551615]。
重启备中心的应用软件，触发应用重新获取序列号。
同步数据：管理全局唯一性序列号的数据表xx_table需要同步，从过滤表清单中移除xx_table，确保主备中心的有效序列号范围一致。
应用改造：当备中心对RDS MySQL有只读权限时，允许更新序列号失败，应用初始化成功。当容灾切换后，备中心获得RDS MySQ读写权限后，由业务请求触发重新按需获取最新的序列号。
测试效果：
主中心和备中心同步数据完成后，断开同步链路，手动设置备中心数据库为只读。
重新部署改造后的应用，在只读模式下，验证应用启动成功，并且业务请求失败（符合预期）。
手动设置备中心数据库为读写，业务请求成功，检查应用是否成功重新获取到有效序列号。
重新配置主中心和备中心数据同步链路。
容灾演练：再次进行演练来验证全业务场景。
容灾演练是发现系统性问题的起点，不是终点，需要定期开展演练来保障系统的容灾能力。
云平台容灾不等于应用容灾，应用级容灾是系统性工程。
通过演练来检查工程能力，技术上包括云平台、应用和网络；流程上包括故障判断、容灾决策、切换操作、应急预案等。
从实战角度出发，以企业应用环境为主线，深入介绍MYSQL的使用技巧和调优策略，最大限度发挥MySQL的性能优势，适合MySQL DBA或者运维相关开发者。
点击“阅读原文”开始学习吧~
以上是关于应用容灾中，MySQL数据表是否需要跨云同步？的主要内容，如果未能解决你的问题，请参考以下文章