如何监听mysql数据变化,并导出到其他数据库?

工具介紹

了解Canal
超详细的Canal入门,看这篇就够了!

Canal github

数据迁移同步模型

来源MySQL到Elasticsearch实时同步构建数据检索服务的选型与思考

订阅消费

Mysql(基于主从协议binlog)->Canal->消息队列->其他数据源

优点

  • 堆积能力:由于引入了消息队列,所以整个链路是具备变更数据的堆积能力的。假设变更数据消费的比较慢,MySQL 本地较老的 binlog 文件由于磁盘空间的不足而被删除时,消息队列中的数据仍然存在,数据同步仍然可以正常进行
  • 数据分发能力:引入消息队列后可以支持多方订阅。如果下游多个应用都依赖源端的变更数据,可以订阅同一份 topic 即可
  • 数据加工能力:由于变更数据是由下游消费者订阅,因此订阅后可以灵活的做一些数据加工。例如从外部调用微服务接口或者反查一些数据来做数据加工都是比较方便的
    缺点
  • 运维成本相对较高:包含了较多的组件和应用,运维保障相对复杂。
  • 稳定性风险较高:一环出问题会导致整个数据同步链路的稳定性受到影响。而且排查和定位问题也会比较困难。

直连

Mysql(基于主从协议binlog)->Canal->其他数据源

优点

  • 低延迟:端到端的直接同步,链路较短,延迟低
  • 稳定性好:链路组件少,出问题概率较低,定位排查均比较容易。适合对数据精确性高的严苛场景。
  • 功能拓展性强:对端写入消息系统,模拟订阅模式,可扩展性强
  • 运维部署简单:链路组件少,部署运维更简单

猜你喜欢

转载自blog.csdn.net/litterfrog/article/details/115182600