实验环境: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).