MySQL中 slave_compressed_protocol=ON 的压缩效果实验

实验环境：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线程

image.png

image.png

slave2上，不设置压缩（默认情况下MySQL就是不压缩的）:

image.png

image.png

下图，是主库在2种情况下的网卡流量情况

开启压缩的时候，最大约7.14MB/s

image.png

不开启压缩的情况下，最高约23.76MB/s

image.png

可以看到，开启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).