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

MySQL中 slave_compressed_protocol=ON 的压缩效果实验_第1张图片  MySQL中 slave_compressed_protocol=ON 的压缩效果实验_第2张图片


slave2上,不设置压缩(默认情况下MySQL就是不压缩的):

MySQL中 slave_compressed_protocol=ON 的压缩效果实验_第3张图片  MySQL中 slave_compressed_protocol=ON 的压缩效果实验_第4张图片



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

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

MySQL中 slave_compressed_protocol=ON 的压缩效果实验_第5张图片


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

MySQL中 slave_compressed_protocol=ON 的压缩效果实验_第6张图片


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