技术干货 | 数据中间件如何与GreatSQL数据同步？

最新推荐文章于 2025-11-02 18:48:21 发布

原创

最新推荐文章于 2025-11-02 18:48:21 发布 · 349 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#大数据

本文探讨了如何确保GreatSQL数据库与ElasticSearch之间的数据同步。传统方案包括直接同步更新和异步更新，但存在耦合度高、性能下降等问题。通过监控MySQL的binlog，结合Canal实现数据同步，能降低耦合度，提高系统性能。Canal伪装成Slave从库，监听binlog事件，将变更推送给ES，实现无侵入式的同步。这种方式在生产环境中更优，但也需要正确配置binlog和Canal。

1.引入2.传统方案介绍3.监控binlog实现"同步"更新4.总结

1.引入

先前介绍了ElasticSearch，以及ES配合MySQL的问题，这种方案是让ES上的数据根据MySQL的数据做对照从而形成对应的索引，再将数据通过处理和封装存放在ES当中。（可回顾：技术分析 | 浅析MySQL与ElasticSearch的组合使用）

回到生产环境，比如，我们如何保证MySQL系开源数据库GreatSQL中与ES对照的数据，发生更新的时候ES也进行更新呢？下面以ES为例进行分析。

2.传统方案介绍

2.1直接的"同步"更新

第一种方式十分直接，当发生对GreatSQL数据的更新操作时，由服务器对GreatSQL和ES同时进行更新操作，如图：

这种方式实现起来十分“简单粗暴”，容易理解，显然可以解决问题，但绝不是最优解，原因如下：

首先，这种方法使得我们进行数据库的数据写入、修改、删除等操作，后面都要跟上ES的同步操作，代码书写也过于冗长，且大大加大了业务的耦合度；
其次，这种方法不能很好解决“同步”的问题，如果在执行对应操作的时候发生了断电等情况，就可能导致数据不同步的问题；
最后，为了保证两者的更新要么同时完成要么都不完成，需要开启事务来处理，系统的性能有所降低。并且，在高并发情况下，有可能造成服务的“雪崩”。

2.2异步的"同步"更新

针对前面的方案，可以考虑加入消息队列的中间件来优化，与第一种方法不同的是，当发生对GreatSQL数据的更新操作时，服务器会完成GreatSQL数据的更新，并通过MQ的队列设置好的交换机发送更新ES的消息，给对应的接收更新消息的队列，进而完成对应ES数据更新的实现。如图：

这种方案将直接的更新方式转换为异步的更新方式，性能显然提高了，同时降低了业务耦合度，也优化了数据“同步”的问题。但是，这种方案会出现MQ的消费者在消费时可能因为网络等原因导致用户数据有延时。同时，从编码角度看，每次系统要进行同步时都要编写MQ代码，仍然存在业务的耦合，且系统架构的设计也因为加入新的中间件要重新考虑维护的问题。

3.监控binlog实现"同步"更新

上面两种方案中都存在硬编码问题，同时存在强的业务耦合，以至于实现GreatSQL数据更新后的数据同步问题的代价要么是植入ES更新代码，要么替换为MQ代码，代码的侵入性太强，且性能降低。因此可以通过监控GreatSQL的binlog来实现数据的同步。

3.1问题分析

binlog，该日志存在于Server层次中，是使用存储引擎都可以使用的日志模块，binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给test表id=5这一行的col1字段值加1”。binlog的日志文件是可以追加写入的。“追加写入”是指binlog日志文件写到一定大小后会切换到下一个文件进行写入，可以设置sync_binlog