MySQL中 slave_compressed_protocol=ON 的压缩效果实验
- 2019 年 10 月 4 日
- 笔记
实验环境：CentOS7.5、MySQL5.7
主库：
set global slave_compressed_protocol = ON ;
slave1上，设置压缩:
set global slave_compressed_protocol = ON ;
stop slave io_thread ;
start slave io_thread ; — 注意，这个修改后，需要重启下 io线程
slave2上，不设置压缩（默认情况下MySQL就是不压缩的）:
下图，是主库在2种情况下的网卡流量情况
开启压缩的时候，最大约7.14MB/s
不开启压缩的情况下，最高约23.76MB/s
可以看到，开启slave_compressed_protocol=ON 后，带宽得到了很大的压缩（节省了2/3的带宽），在跨机房同步的时候，可以避免专线的过高占用。
注意： 开启压缩，在一定程度上是会消耗CPU资源，因此，如果数据库机器的CPU负载已经很高了，就不太建议再开压缩了。
这篇文档的图片更直观些：https://blog.pythian.com/masterslave-replication-in-limited-bandwidth-scenarios/
官方文档：
https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html
Whether to use compression of the slave/master protocol if both the slave and the master support it. The default is that compression is not used. Changes to this variable take effect on subsequent connection attempts; this includes after issuing a START SLAVE statement, as well as reconnections made by a running I/O thread (for example after issuing a CHANGE MASTER TO MASTER_RETRY_COUNT statement).
