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).
