主从数据库延时同步问题

背景

在一些大数据业务，比如实时股票、实时日志、实时...等，需要大数据支撑的同时也需要数据的时效性。

当数据量愈来愈大，且请求、业务等体量的增大，在分配主从数据库读写问题上，很容易出现数据的延时复制的问题。

为此，针对如何主从复制的延时问题的方案策对上，有很多很多有意思或深奥的策略；

以下 针对 主从数据库复制延时 进行讨论

问题

主从数据库有延时，说到延时很容易想到造成他的几种原因：

• 网络延时
• 主数据库服务器卡顿
• 从数据库服务器卡顿
• 服务器故障问题
• 文件解析问题：包括但不限于，主从时间不同步、文件编码、传输丢失等等
• ......

可以发现，除去比较客观的因素，最能影响到主从数据库复制的因素主要是两点：

1. CPU、IO性能的最低保证
2. 针对binlog传输、解析、存储技术的优化

而对于网络延时这一主体问题，最常用的是考虑下面几步走：

1. 机器不好，加钱加带宽
2. 没钱，减少两者服务器中的宽带占用
3. 没有空余空间保留，那么就只能尽可能的将两这服务器部署在同一中心、宽带近点上
4. 这也不行，那就等有钱吧

另外，以上问题多针对服务器性能，另一类则是来自开发者或维护人员即：长且大事务的提交、数据库配置、缓存技术...

主从设计

以上为一个简单的主从数据库写入、读取、使用的架构图，大多主从设计上八九不离十是：一主x从、多主x从，主主互从。

而延时问题一般在这几个分支上：

1. 主传输binlog速度慢
2. 从接收binlog速度慢
3. 并发时，IO过载，解析和传输都慢
4. 写数据库时，执行了大事务

其中，关于Mysql主从复制延时的八股文本篇中就不赘述，本文重点是介绍一种比较冷门但很起效的延时问题解决方案

解决方案

首先，对于开发者本身的代码或设计导致的SQl事务堆积，以及设计上的解决方案：

1. 多加从机，分摊从机压力
2. show slave status从库查询延时时间，分业务走主库查询或阻塞
3. 并行复制
4. ...

可以在网络上看到各种各样的讨论与答案，在里面我推荐一个很陌生且冷门的名词 BLCKHOLE，Mysql的黑洞引擎

BlockHole（黑洞）存储引擎会丢弃所有写入的数据，所以尝试从BlockHole表中读取数据只能得到空结果

当数据库选用 BlockHole引擎时，执行 插入语句，会发现 SELECt 操作查询不出任何数据，使用数据库工具也看不到数据；

这是因为 BLCKHOLE 的特性：不会将数据写入数据库的data目录下，只会存储其语句的二进制文件

即黑洞引擎只会生成对应的数据binlog日志；

那么我们可以将主库中的binlog推到使用黑洞引擎的数据库上，由于不会进行数据库sql执行引擎，不写入数据；

所以说该库的磁盘IO消耗的会非常少，随后可以以该数据库为从机的主机节点，往后进行正常数据库的binlog复制；

其中，需要注意，开启黑洞引擎的数据库，一定是在一个从机的服务器中，即一个服务两个数据库；因为同一网络下的IO传输，几乎不存在损耗；

关于黑洞引擎的文档可见官方： https://dev.mysql.com/doc/refman/8.0/en/blackhole-storage-engine.html

最后总结：

搭建一台专属blockhole黑洞引擎的从库，利用blockhole黑洞引擎的特性：只接收binlog但却并不保存数据（减少从库的IO压力，缩短同步延迟），相当于一个binlog接收器，然后以该库为binlog仓库进行从机的数据同步，或者另一个监听从库读的binlog日志的平台直接监听黑洞数据库；