mysql binlog最大是多少

之前有做过一个 binlog 压缩能节约多少空间的测试，效果上看还是比较理想的，可以节约一半以上的空间。但是这个又引出了一个新的问题，那就是这个功能对性能有多大影响呢？于是我又在测试环境试了一下，测试环境的物理配置如下。

根据之前的经验这套测试环境在 120 个表 + 240 个并发的情况，可以取得一个性能上的极大值；所以在这里就直接使用这个作为测试压力。

8.0.19 场景

第一步：安装。

dbma-cli-single-instance --port=3306 --max-mem=131072 \--pkg=mysql-8.0.19-linux-glibc2.12-x86_64.tar.xz install

第二步：创建测试用户。

create user sysbench@'%' identified by 'sysbench'create database tempdbgrant all on tempdb.* to sysbench@'%'

第三步：填充数据并进行压力测试。

sysbench --mysql-host=192.168.100.10  --mysql-port=3306 --mysql-user=sysbench \--mysql-password=sysbench --tables=120 --table_size=100000 --mysql-db=tempdb \--time=3600 --threads=240 oltp_point_select prepare

sysbench --mysql-host=192.168.100.10  --mysql-port=3306 --mysql-user=sysbench \--mysql-password=sysbench --tables=120 --table_size=100000 --mysql-db=tempdb \--time=3600 --threads=240 oltp_point_select run

性能表现。

资源消耗情况。

8.0.20 + binlog 压缩

第一步：安装。

dbma-cli-single-instance --port=3306 --max-mem=131072 \--pkg=mysql-8.0.20-linux-glibc2.12-x86_64.tar.xz install

第二步：创建测试用户。

create user sysbench@'%' identified by 'sysbench'create database tempdbgrant all on tempdb.* to sysbench@'%'

-- dbm-agent 默认会开启 binlog 压缩show global variables like 'binlog_transaction_compression%'+-------------------------------------------+-------+| Variable_name                             | Value |+-------------------------------------------+-------+| binlog_transaction_compression            | ON    || binlog_transaction_compression_level_zstd | 3     |+-------------------------------------------+-------+2 rows in set (0.00 sec)

第三步：填充数据并进行压力测试。

sysbench --mysql-host=192.168.100.10  --mysql-port=3306 --mysql-user=sysbench \--mysql-password=sysbench --tables=120 --table_size=100000 --mysql-db=tempdb \--time=3600 --threads=240 oltp_point_select prepare

sysbench --mysql-host=192.168.100.10  --mysql-port=3306 --mysql-user=sysbench \--mysql-password=sysbench --tables=120 --table_size=100000 --mysql-db=tempdb \--time=3600 --threads=240 oltp_point_select run

性能表现。

资源消耗情况。

8.0.20 + binlog 不压缩

第一步: 关闭 binlog 压缩功能。

set @@global.binlog_transaction_compression='OFF'

show global variables like 'binlog_transaction_compression%'+-------------------------------------------+-------+| Variable_name                             | Value |+-------------------------------------------+-------+| binlog_transaction_compression            | OFF   || binlog_transaction_compression_level_zstd | 3     |+-------------------------------------------+-------+2 rows in set (0.01 sec)

第二步：进行压力测试。

sysbench --mysql-host=192.168.100.10  --mysql-port=3306 --mysql-user=sysbench \--mysql-password=sysbench --tables=120 --table_size=100000 --mysql-db=tempdb \--time=3600 --threads=240 oltp_point_select run

性能表现。

资源消耗情况。

结论

开启 binlog 压缩会对性能有影响，大概会让性能下降 1%，cpu 多消耗 1%。

Binlog基本配制与格式设定

1.基本配制

Mysql BInlog日志格式可以通过mysql的my.cnf文件的属性binlog_format指定。如以下：

binlog_format = MIXED //binlog日志格式

log_bin =目录/mysql-bin.log//binlog日志名

expire_logs_days = 7//binlog过期清理时间

max_binlog_size 100m//binlog每个日志文件大小

2.Binlog日志格式选择

Mysql默认是使用Statement日志格式，推荐使用MIXED.

由于一些特殊使用，可以考虑使用ROWED，如自己通过binlog日志来同步数据的修改，这样会节省很多相关 *** 作。对于binlog数据处理会变得非常轻松,相对mixed，解析也会很轻松(当然前提是增加的日志量所带来的IO开销在容忍的范围内即可)。

3.mysqlbinlog格式选择

mysql对于日志格式的选定原则:如果是采用 INSERT，UPDATE，DELETE 等直接 *** 作表的情况，则日志格式根据 binlog_format 的设定而记录,如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何 都采用 SBR 模式记录 《Linux就该这么学》一起学习linux

4.Mixed日志说明：

在slave日志同步过程中，对于使用now这样的时间函数，MIXED日志格式，会在日志中产生对应的unix_timestamp()*1000的时间字符串，slave在完成同步时，取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步，而对于上面指定的一些类似于UDF函数，导致Slave无法知晓的情况，则会采用ROW格式存储这些Binlog，以保证产生的Binlog可以供Slave完成数据同步。

本来的log_file多大，查出来就多大。

shell>mysqlbinlog log_file

...

# at 218

#080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F

BINLOG '

fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=

fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==

'/*!*/

...

# at 302

#080828 15:03:08 server id 1 end_log_pos 356 Update_rows: table id 17 flags: STMT_END_F

BINLOG '

fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=

fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP

'/*!*/

...

# at 400

#080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: table id 17 flags: STMT_END_F

BINLOG '

fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=

fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP

'/*!*/

---