分布式微服务改造,到底怎么做数据迁移?(上)

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 设计新系统容易,但是我们处理的都是老系统和历史诗句。怎么能更平滑的迁移旧数据到新的数据库和系统,特别是在异构的数据库结构情况下,达到数据准确,迁移速度快,减少停机,对业务影响小

迁移是最容易出故障的一个点

那么如何做数据迁移呢?

1 解决方案

1.1 全量

最直观的一把梭方案,即全量数据的导入/出:

  • 业务系统需要停机
  • DB 迁移,校验一致性(数据、关系、约束等)
  • 升级业务系统,接入新 DB

如果直接复制,可以 dump 后全量导入,如果是异构数据,需要用程序处理。

优点:简单

缺点:停机时间过长,数据量不太大时适合这种方案

1.2 全量+增量

大部分开发采用的方案,依赖数据本身的时间戳,即版本号:


  • 先同步数据到最近的某时间戳
  • 然后在发布升级时停机维护
  • 再同步最后一段事件(通常是一天)的变化数据
  • 最后升级业务系统,接入新数据库


优点:极大缩短停机时间

看来已经满足绝大部分需求了,还有更流弊的方案吗?

1.3 binlog+全量+增量(推荐)

当你的公司数据库和中间件比较完善时,推荐使用。


通过主库或从库的binlog解析和重新构造数据,利用主从复制实现扩展迁移,这需要中间件的支持。可实现多线程,断点续传,全量历史和增量数据同步。


可以达到:

  • 实现自定义复杂异构数据结构
  • 实现自动扩容和缩容,比如分库分表到单库单表,单库单表到分库分表,分4个库表到分64个库表


当然了,既然这种需求很常见,社区肯定也有支持的框架:

1.4 shardingSphere-scaling

  • 支持数据全量和增量同步
  • 支持断点续传和多线程数据同步
  • 支持数据库异构复制和动态扩容
  • UI界面,可视化配置

1.png

MySQL不像MongoDB支持数据Auto Sharding(自动分片),当:

  • MySQL单库拆成多库
  • 还是由于数据存储的瓶颈,不得不将多库拆成更多库


你都要考虑如何数据迁移。不只是对DB拆分时会做数据迁移,很多场景都要给出数据迁移方案。

比如领导突然想将应用从自建机房上云,你要考虑将所有自建机房中的数据,包括MySQL、Redis、MQ等组件中的数据全部上云!

如何平滑迁移DB数据

数据迁移无非是将数据从一个DB拷到另一个DB,可通过:

  • MySQL 主从同步做到准实时数据拷贝
  • mysqldump工具将源库的数据导出再导入到新库


这有啥复杂的呢?注意了!这两种方式只支持:单库=》单库,不支持单库=》多库多表。

即便是单库=》单库,迁移过程也需满足:

  • 迁移应该是在线的迁移,也就是在迁移的同时还会有数据的写入
    数据应该保证完整性,也就是说在迁移之后需要保证新的库和旧的库的数据是一致的
  • 迁移过程要做到可回滚,一旦迁移过程异常,可立刻回滚到源库,不影响系统可用性


若使用Binlog同步,在同步完成后再修改代码,将主库修改为新库,这就不满足可回滚!

一旦迁移后异常,由于已经有增量数据写入新库,未写入旧库,不可能再将DB改成旧库了。

数据库迁移方案

双写

步骤

将新库配置为源库的从库用来同步数据;若需要将数据同步到多库多表,可使用第三方工具获取Binlog的增量日志(如Canal),获取后即可按分库分表写入到新库表

1、2 之间切换为双写前是不是应该停掉新旧库的同步关系。主从延迟是可以监控的,可以看主从没有延迟了就可以断掉同步了。

同时需改造业务代码,在数据写入时,旧库新库都要写。考虑到性能,可异步写新库,只要保证旧库写成功即可。但注意,要将写新库失败的数据记录在单独日志,方便后续补数据,保证新、旧库数据一致性

然后开始校验数据

由于DB数据量很大,全量数据校验不现实。可抽取部分数据,具体数据量依总体数据量而定,只要保证这些数据一致即可。推荐你在未开始迁移数据前,先写好数据校验工具或脚本,在测试环境上测试后,再正式迁移。

若一切顺利,即可将读流量切到新

采用灰度切换,比如开始切换10%流量,没有问题再切50%流量,最后再切到100%。

由于双写,所以在切换过程中出现任何的问题,都可将读写流量随时切到旧库,保障系统性能

观察几天,发现数据迁移没问题后,即可将DB双写改造成只写新库,数据迁移就完成了。

  1. 将新库配置为源库的从库用来同步数据;若需要将数据同步到多库多表,可使用第三方工具获取Binlog的增量日志(如Canal),获取后即可按分库分表写入到新库表
    1、2 之间切换为双写前是不是应该停掉新旧库的同步关系。主从延迟是可以监控的,可以看主从没有延迟了就可以断掉同步了。
  2. 同时需改造业务代码,在数据写入时,旧库新库都要写。考虑到性能,可异步写新库,只要保证旧库写成功即可。但注意,要将写新库失败的数据记录在单独日志,方便后续补数据,保证新、旧库数据一致性
  3. 然后开始校验数据
    由于DB数据量很大,全量数据校验不现实。可抽取部分数据,具体数据量依总体数据量而定,只要保证这些数据一致即可。推荐你在未开始迁移数据前,先写好数据校验工具或脚本,在测试环境上测试后,再正式迁移。
  4. 若一切顺利,即可将读流量切到新
    采用灰度切换,比如开始切换10%流量,没有问题再切50%流量,最后再切到100%。
  5. 由于双写,所以在切换过程中出现任何的问题,都可将读写流量随时切到旧库,保障系统性能
  6. 观察几天,发现数据迁移没问题后,即可将DB双写改造成只写新库,数据迁移就完成了。


若将数据从自建机房上云,也可用该方案,只是要考虑:自建机房到云上的专线的带宽和延迟,需尽量减少跨专线的读操作,所以在切换读流量的时候你需要保证自建机房的应用服务器读取本机房的数据库,云上的应用服务器读取云上的数据库。这样在完成迁移之前,只要将自建机房的应用服务器停掉并且将写入流量都切到新库就可以了。


  • 从机房上云的数据迁移方案

1.png

这是种通用方案,无论迁移MySQL还是Redis甚至MQ的数据,都可使用该方案。

FAQ

“双写”方案中主从同步和双写冲突的问题,方案是双写前要将同步断掉。

假设在夜间操作,不考虑主从延迟过高。

  • 断掉同步
  • 有双写代码的应用,被部署上线能正常执行双写


这两个操作之间:

  • 先断掉同步,就意味着可能从库丢掉部分数据
  • 先上线新代码,就意味着短时间内数据要么冲突,要么对于不幂等的操作,数据变成双份了


双写方案的一种隐患是新旧二库在遇到同一资源的并发操作时,执行顺序有可能不一样,进而结果就不一样。


现代的应用部署都是基于灰度的,在写操作的代码发生切换时(从双写到写新库,或者从写旧库到写新库),做灰度发布都会带来问题吧?


双写时加开关,默认关闭双写。

上线完成后关闭同步,同时打开开关,在低峰期,数据丢失的概率不高。

再配合数据校验的工作,即可保证一致性。


“双写之前要将同步断掉”, 什么时候将同步断掉呢? 数据在不断的写入, 在将同步断掉之后和开启双写之前如果有数据写入如何处理?

所以要做数据的校验和补写,一般双写会加开关,在断掉同步时马上打开双写开关,时间窗口短,数据丢失的不会很多。


1.数据同时写入两个数据库怎么做对代码的改动比较小呢?有成熟的工具或中间件来做吗?

2.新库在同步追上旧库的binlog后,在开始双写时需要断开吗?不然对于新库会有重复的数据。如果新库需要停止对旧库的binlog同步,和双写的开启时机这里怎么做协调呢?

  1. 还真没有,其实改动代码也简单
  2. 需要断开的,可以在双写的时候加开关,断开同步时立刻打开开关

好处

迁移的过程可以随时回滚,将迁移的风险降到了最低

缺陷

时间周期比较长,应用有改造的成本。


基于双写的方案我总结了2种实现:

1、基于同步写新库和旧库方案

在写入数据的时候,同步写入旧库数据,异步写入新库数据。

数据校验,对部分数据进行校验(最容易出问题的地方,需要提前准备好脚本)。

使用灰度发布方式将读流量切换到新库。

观察几天没问题后,可以改成只写新库。

2、基于Canal的迁移方案

将新库配置为源库的从库,同步数据。比如使用Canal同步数据。

数据校验,对部分数据进行校验(最容易出问题的地方,需要提前准备好脚本)。

使用灰度发布方式将读流量切换到新库。

暂停应用,将新库作为主库写入,使用Canal同步到旧库。

观察几天没问题后,撤销Canal的同步。

级联同步

也简单,适合数据从自建机房向云上迁移。迁移上云最担心云上环境和自建机房环境不一。

所以我们会在自建机房准备一个备库,在云上环境上准备一个新库,通过级联同步,在自建机房留下一个可回滚DB

步骤

  1. 先将新库配置为旧库的从库,用作数据同步
  2. 再将一个备库配置为新库的从库,用作数据的备份
  3. 等到三个库的写入一致后,将数据库的读流量切换到新库
  4. 然后暂停应用的写入,将业务的写入流量切换到新库(由于这里需要暂停应用的写入,所以需要安排在业务的低峰期)

1.png

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
2月前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
2月前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1
|
23天前
|
消息中间件 存储 负载均衡
微服务与分布式系统设计看这篇就够了!
【10月更文挑战第12天】 在现代软件架构中,微服务和分布式系统设计已经成为构建可扩展、灵活和可靠应用程序的主流方法。本文将深入探讨微服务架构的核心概念、设计原则和挑战,并提供一些关于如何在分布式系统中实现微服务的实用指导。
43 2
|
23天前
|
人工智能 文字识别 Java
SpringCloud+Python 混合微服务,如何打造AI分布式业务应用的技术底层?
尼恩,一位拥有20年架构经验的老架构师,通过其深厚的架构功力,成功指导了一位9年经验的网易工程师转型为大模型架构师,薪资逆涨50%,年薪近80W。尼恩的指导不仅帮助这位工程师在一年内成为大模型架构师,还让他管理起了10人团队,产品成功应用于多家大中型企业。尼恩因此决定编写《LLM大模型学习圣经》系列,帮助更多人掌握大模型架构,实现职业跃迁。该系列包括《从0到1吃透Transformer技术底座》、《从0到1精通RAG架构》等,旨在系统化、体系化地讲解大模型技术,助力读者实现“offer直提”。此外,尼恩还分享了多个技术圣经,如《NIO圣经》、《Docker圣经》等,帮助读者深入理解核心技术。
SpringCloud+Python 混合微服务,如何打造AI分布式业务应用的技术底层?
|
3月前
|
监控 Go API
带你十天轻松搞定 Go 微服务之大结局(分布式事务)
带你十天轻松搞定 Go 微服务之大结局(分布式事务)
|
3月前
|
监控 Java 开发者
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流。本文探讨Java微服务架构的设计原则与实践。核心思想是将应用拆分为独立服务单元,增强模块化与扩展性。Java开发者可利用Spring Boot等框架简化开发流程。设计时需遵循单一职责、自治性和面向接口编程的原则。以电商系统为例,将订单处理、商品管理和用户认证等拆分为独立服务,提高可维护性和容错能力。还需考虑服务间通信、数据一致性及监控等高级话题。掌握这些原则和工具,开发者能构建高效、可维护的微服务应用,更好地应对未来挑战。
86 1
|
3月前
|
Java 微服务 Spring
SpringBoot+Vue+Spring Cloud Alibaba 实现大型电商系统【分布式微服务实现】
文章介绍了如何利用Spring Cloud Alibaba快速构建大型电商系统的分布式微服务,包括服务限流降级等主要功能的实现,并通过注解和配置简化了Spring Cloud应用的接入和搭建过程。
SpringBoot+Vue+Spring Cloud Alibaba 实现大型电商系统【分布式微服务实现】
|
3月前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
123 6
|
3月前
|
Java 数据库连接 微服务
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
64 0
|
3月前
|
消息中间件 SQL 关系型数据库
go-zero微服务实战系列(十、分布式事务如何实现)
go-zero微服务实战系列(十、分布式事务如何实现)
下一篇
无影云桌面