踩坑 | 数据库主从同步延迟的问题

20

2023-08

踩坑 | 数据库主从同步延迟的问题

因为最近踩了太多坑了，所以准备开一个新的系列，分享一些最近新学（cai）到（keng）的东西，更新不定期~

LEARN MORE

图片由海艺AI绘制

最近被各种延迟的问题搞得比较惨，被迫加班好几次。非要说的话，还是因为数据流程本身比较复杂，涉及的技术细节太多了，有很多都是我知识的盲区或者我曾经以为应该是XX结果经过踩坑之后发现实际根本不是这样的。

比如说数据同步延迟，我曾经天真地认为“实时同步”是不会出现问题的，但是经过了一堆事件之后，深刻地认识到了实时同步的延迟问题。我下意识里认为数据库的主从同步延迟问题，最多就是延迟几分钟而已，近期遇到的问题算是刷新了我的认知。

一些东西不好说太细，简单来说，我面对的技术背景是这样的：

此处特别感谢群友安利的工具，太帅了

但是呢，最近刚好在做数仓的升级，于是我真实面对的情况是这样的：

（其他的技术细节背景可以在参考上周日的分享，最下面的合集这中可以放回翻上一篇文章的内容。）

因为数仓也在过渡期间，数仓2.0的数据是从数仓1.0通过airflow job做得增量刷新同步。通常来说，增量同步大概需要耗时40分钟左右，但是这天遇到了一个奇怪的问题，airflow任务2分钟就执行完毕了。并且检查校验确认数据并没有入库。

向回反查之后发现，数仓1.0的主库已经有数据了，但是数仓1.0的从库还没有数据。数仓2.0执行同步拉取得是数仓1.0从库的数据，由于同步的逻辑是增量刷新，因此任务执行得异常快——没有增量，扫描一遍就完事了。

最终，从库数据同步延迟约4小时左右。是我目前遇到的主从同步延迟最长的一次。这一点确实触及了我知识的盲区，因此我去学习了一下相关的知识，总结在这里。

首先，什么是主从同步：

主从同步是一种数据复制机制，用于将一个数据库的更改同步到其他从属数据库。它通常用于构建高可用性和故障转移解决方案，以确保数据的一致性和持久性。

一个数据库被指定为主数据库（主服务器），负责处理所有写操作。

一个或多个从属数据库（从服务器）通过复制主数据库的更改来保持数据同步。

当主数据库接收到写操作时，它会将更改记录到二进制日志（binlog）中。

从属数据库连接到主数据库，并通过读取主数据库的二进制日志来获取更改。

从属数据库将这些更改应用到自己的数据库，使其与主数据库保持同步。

为什么要区分主库和从库：

读操作和写操作分离，减少锁表等问题，提升数据库性能；

备份备灾，万一出现问题可以切换&恢复数据；

基于这个理论来思考我们的架构。对于一个和MDM主数据一体的数仓来说，同步数据和dashboard抽取数据，逻辑上来说从这个同步的任务确实应该从库抽取数据而不是从主库来抽取数据。

然后是主从同步为什么会延迟：

一个服务器开放Ｎ个链接给客户端来连接的这样，有会有大并发的更新操作, 但是从服务器的里面读取binlog 的线程仅有一个， 当某个SQL在从服务器上执行的时间稍长 或者由于某个SQL要进行锁表就会导致，主服务器的SQL大量积压，未被同步到从服务器里。这就导致了主从不一致， 也就是主从延迟。

除此之外，还有一个点，当出现主从同步延迟的问题的时候，人工干预比较费劲。不管是开发小哥告诉我的信息还是我自己在网上搜的，还是chatgpt，似乎都没有什么办法能够强制人工干预主从同步延迟的问题。唯一能做的是kill掉一些对主库的访问，降低主库的负荷，然后慢慢等待。

至于主从同步延迟问题的优化，我翻了一些文章，解决思路就是三种，第一提升硬件性能，第二是减少并发，第三是从库做多几个备份。看来看去，感觉加钱升级服务器提升硬件性能才能唯一解法。