数据同步

本文探讨了数据同步的应用场景,如数据库迁移、报表查询等,并详细分析了数据同步的各种方式,包括Canal、Maxwell、debezium和DataX。文章还讨论了数据同步时需要考虑的因素,如实时性、一致性、高可用性和数据完整性。各种实现方式各有优缺点,如Canal延迟低但源端支持有限,Maxwell将binlog解析成JSON,debezium支持多源,而DataX则适用于异构数据源的交换。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. 应用场景

  • 业务数据发展到一定水平,需要将大部分冷热数据从熟悉的DB迁移到其他存储进行复杂查询和分析
  • 分库分表后,某些报表类查询无法工作,需要汇总到单库表进行操作
  • 分库分表有多个维度,需要拷贝多份数据达成冗余
  • 通过伪数据共享(没办法引入MQ、无法共享库表)进行业务改造
  • 慢存储–>Cache之间的同步
  • 不停服数据迁移/scheme变更
  • 导数据导数据

很多时候,DataBus提供的仅仅是一个工具集。要完成最终的功能,大多数需要引入其他组件,如MQ、JOB等进行配合。同时,大部分数据同步工具需要有规范的数据库支持。所以,在忙着进行数据同步之前,需要对遗留数据进行一次集中数据治理。

一般数据同步,可以应用驱动双写:应用层同时向数据库或者多个存储写数据。因为代码在自己手中,这种方式在直觉上是简单可控的。但它引入的一致性问题将会是非常大的减分,因为没有复杂的协调协议(比如两阶段提交协议或者paxos算法),当出现问题时,很难保证多个存储处于相同的锁定状态。两个系统需要精确完成同样的写操作,并以同样的顺序完成序列化。如果写操作是有条件的或是有部分更新的语义,那么事情就会变得更麻烦。

基于数据库日志:将数据库作为唯一真实数据来源,并将变更从事务或提交日志中提取出来。这可以解决一致性问题,但是很难实现,MySQL这样的数据库有私有的交易日志格式和复制冗余解决方案,难以保证版本升级之后

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值