MYSQL binlog compression 来自MYSQL 8.020的声音

MYSQL 的新版本一直不断的发，其实这样有一个问题，到底我们要选择哪个版本的8 ，不断的升级导致“贪心不足” 的人们，总是在等待一个更好的版本，而还在继续使用5.X ，另外一个原因是MYSQL 5.x 一堆的工具，如果换到8 ，则不少的作废了。所以 MYSQL 8 使用的 cyber or internet 的公司不多。当然另外一个原因是，一个系统上线后，想要升级数据库系统，那也是不容易的事情，

每个数据库都会面对一个重要解决的问题，磁盘的性能，其实数据库不少的优化和想法以及设计都是针对 磁盘的I/0, cache buffer 预读， 其实数据库的技术和原理部分都是基于硬件的原理，而硬件的变化也会影响数据库的发展。

那么mysql 8.020 对于MYSQL的BINLOG 一个消耗磁盘的性能的killer, 做出了改变，原理就是压缩。

这个改变在MYSQL 的8.020这个版本，降低磁盘的占用和写入的量对数据库是一个永恒的话题。

下面的话题就的从这几个参数来了。

默认binlog 的 binlog_transaction_compression 是关闭的， 这两个参数属于全局参数，是无法在系统运行中事务通过session级别来进行设置的。

但可以在session 中进行设置

压缩并不是对类似gtid 信息， 非事务的基于行的信息进行压缩.

压缩的方法是通过zstd逻辑的方式进行,将日志进行压缩,通过压缩事务将日志通过流的方式传送给复制端,或者组复制的成员或者mysqlbinlog 这样的程序等等.在这个过程中并不会对信息进行解压缩,二进制日志事务压缩因此既节省了事务发起者的存储空间，也节省了事务接收者(及其备份)的存储空间，还节省了事务在服务器实例之间发送时的网络带宽。

当对其中的事务的时间进行重放的时候,会将这些信息解压缩,或者在使用mysqlbinlog ,show binlog events show relaylog events 等命令的时候会对他们进行解压.

binlog_transaction_compression_level_zstd系统变量，用于设置用于压缩的zstd算法的级别。值对于压缩工作量进行控制，从1到22,随着压缩级别的增加，压缩比也会增加，来减少事务有效负载需要的存储空间以及网络带宽。

select * from performance_schema.binary_log_transaction_compression_stats\G

在打开相关功能后, 并且在打开事务后有相关的事务运行后binary_log_transaction_compression 才有相关的信息.

另外在performance_schema 中对于相关的压缩的也有相关的监控

performance-schema-instrument = "stage/sql/%Compressing transaction changes.=ON"

performance-schema-consumer-events-stages-current = ON

上图是一个对binlog 进行压缩和不进行压缩,以及通过最终压缩的方式相关对比,可以看到通过这个功能进行压缩与原有的不压缩对于存储的尺寸有较大的不同.

从压缩的比率来看,通过MYSQL进行BINLOG 压缩.要比通过外部的压缩方法,损耗的CPU 等要低的多.