作者:王向
爱可生 DBA 团队成员,负责公司 DMP 产品的运维和客户 MySQL 问题的处理。擅长数据库故障处理。对数据库技术和 python 有着浓厚的兴趣。
前言
现在使用 MySQL 时 binlog 格式都是基于 ROW ,binlog 文件大小一直是一个比较大的问题。在传输到从库时会耗费一定量的网络资源,假如有大事务把一个 binlog 搞到10个G复制到从库,几乎让主库网络累的嗷嗷叫。下面我们介绍一个开启 binlog 压缩参数来缓解这个问题!
如何开启binlog压缩
slave_compressed_protocol 参数用于控制 MySQL 主从复制是否使用压缩协议,开启 binlog 复制压缩对于缓解 binlog 数据量大导致的网络带宽问题有一定的帮助。
binlog压缩的压缩效果
压缩到底有没有效果呢?不废话直接压测看结果。
创建压缩表灌入数据
关闭状态
主库监控
从库监控
开启状态
主库监控
从库监控
结论
主库 cpu | 从库 cpu | 主库 send | 主库 recv | 从库 send | 从库 recv | |
未压缩 | 4.24% | 2.7% | 14.50MB/s | 7.31MB | 35KB/s | 14.60MB/s |
压缩 | 8.50% | 3.18% | 6.68MB/s | 7.27MB/s | 35KB/s | 6.610MB/s |
1、开启 slave_compressed_protocol 参数,压缩效果明显,网络数据传输量约为未开启一半,压缩率 50%。
2、开启 slave_compressed_protocol 参数,在一定程度上是会消耗 CPU 资源;如果 CPU 负载已经很高就不太建议再开压缩了。
注意事项
在MySQL 在 5.7.21 以下,或者 8.0.4 以下的版本在 slave_compressed_protocol=ON 与半同步复制一起使用时,会触发 Bug 导致主库写入卡住。这里就不多说了,以免偏离主题太多,见地址:https://bugs.mysql.com/bug.php?id=86230