PostgreSQL

前言 在我的个人项目中很多地方都使用到了 meilisearch，之前也写了一篇博客介绍了一下 meilisearch 的使用，可以参考一下：MeiliSearch，一个轻量级搜索引擎。 之前的话就简单粗暴地其了一个定时任务，每隔一段时间就从数据库中同步一次数据到 meilisearch，这样的话就会有一些问题： 数据不实时。 每次都是全量同步，效率很低。 所以希望能有一个能实时增量同步数据库，类似 MySQL 的，到 meilisearch 的工具。在 GitHub 上搜了一圈，发现没有什么好用的，于是打算自己写一个。 项目地址 https://github.com/long2ice/meilisync, 命令行版本。 https://github.com/long2ice/meilisync-admin，在命令行版本的基础上，增加了一个 web 管理界面，可以动态添加同步任务，查看同步状态等。 预览 技术栈 前端：React + daisyui 后端：FastAPI + TortoiseORM + MySQL 架构 目前支持三种数据库： MySQL，使用 binlog 来实现。 PostgreSQL，使用 logical replication 来实现。 MongoDB，使用 change stream 来实现。 最初的版本只是实现了命令行的功能，通过加载配置文件，然后启动一个进程，然后通过 binlog 类似的技术来实现实时地增量同步。 更进一步 命令行版本可以满足基本的需求，但是还是有一些不足的地方： 修改配置需要重启。 无法动态添加同步任务。 只支持单实例。 于是在命令行版本的基础上，增加了一个 web 管理界面，可以动态添加同步任务，查看同步状态，以及增加了登录功能。 遇到的问题 遇到错误如实例连不上，重启进程之类的会丢失数据。 全量刷新数据的实时不能影响线上业务。 MySQL binlog 连接长时间后丢失。 以及一些其他的问题。

项目地址 https://github.com/long2ice/synch mysql2ch mysql2ch 从二月份开始到现在已经接近四个月，项目起初是源于公司的需求，同步 MySQL 的数据到 ClickHouse 进行分析与统计。当时调研了一圈，发现并没有符合需求的项目，只找到一个勉强可用的，于是在该项目之上进行开发与完善。 synch mysql2ch 项目改名为 synch，其主要原因在于 mysql2ch 支持了 postgres 的同步，再取名为 mysql2ch 就有些不合适了，遂改名为 synch，意思是同步到 ClickHouse，其项目目标是同步其它类型的数据库到 ClickHouse 中。 当前架构 设计与实现 最开始的版本非常简陋，只是实现了监听 mysql binlog 然后直接插入到 ClickHouse。在后续的开发与迭代中，逐渐实现了以下功能，以及引入了中间件。 命令行 命令行对于一个独立程序是有必要的。命令行程序可以接受自定义的参数，通过在程序指定不同的参数，可以使用其不同的功能，对于那些需要每次启动都可能会不同的参数，将其放在命令行参数中是有必要的。 配置文件 丰富的配置项可以将程序的自定义配置暴露出来，以满足个性化的运行需求，增强程序的自定义性。 模块分离 该项目分为三个模块，除了源数据库与目标数据库，也就是 ClickHouse 之外，包含生产端、消息队列、消费端。模块的分离是为了解耦，各个模块专注于自身的功能实现以及可靠性。以及借助于消息队列，实现分布式消费。 消息队列 消息队列的引入是为了增加程序的健壮性以及增加生产与消费的性能。通过引入消息队列，将 binlog 先缓冲到消息队列中而不是直接插入到 ClickHouse，避免了当程序崩溃时内存数据的丢失。并且借助于消息队列的 ack 机制，可以保证消息的可靠消费；以及借助消息队列的高吞吐量，将消费者与生产者分离，生产者与消费者之间互不影响，异步工作。 另外一点考虑到 binlog 的有序性，消息队列的选型也是需要考虑的，目前选择了 kafka 和 redis。redis5.0 提供了原生的消息队列并且具有所有消息队列该有的功能，并且消息是有序的，其轻量的特性在并发量不那么大的时候是一个很好的选择；而选择 kafka 是因为其强大的吞吐量，并且单个 topic 的单个分区也是有序的，可以很好的对应需要同步的数据库与数据库表。 redis redis 的引入其一是为了缓存 MySQL 的 binlog，因为 MySQL 的 binlog 是不断在变化的，当程序崩溃或重启时，需要记录当前的 binlog，然后下次启动时需要从上次的位置继续监听；其二是作为消息队列，相比 kafka 而且因为本身既作为缓存组件也作为消息队列，组件依赖较少。 ...