当前位置：首页 > news >正文

binlog 介绍

news 2025/1/15 17:43:38

公司使用的数据库是 glodendb

https://www.zte.com.cn/china/solutions_latest/goldendb.html#idpart01

最近自动化投产对一张 28w 的表进行全表 update、投产前已经是知道这个数据量的、认为没有问题、也没有在测试环境进行测试。

结果投产那天直接报错

在这里插入图片描述
这个 transaction_max_binlog_size 是 glodendb 自己价的保护机制、而非 mysql 所属。

那什么是 binlog 呢？

binlog即binary log，二进制日志文件。它记录了数据库所有执行的DDL和DML语句（除了数据查询语句select、show等），以事件形式记录并保存在二进制文件中。

binlog 的使用场景

主从同步
数据恢复
下游抽数(这个场景不知道使用广不广、反正我公司有用。前两天程序逻辑问题、一下子更新 200w数据、导致下游抽数队列堆积)

binlog日志可以选择三种模式，分别是 STATEMENT、 ROW、 MIXED，下面简单介绍下这三种模式：

STATEMENT：基于SQL语句的复制，每一条会修改数据的sql语句会记录到binlog中。该模式下产生的binlog日志量会比较少，但可能导致主从数据不一致。
ROW：基于行的复制，不记录每一条具体执行的SQL语句，仅需记录哪条数据被修改了，以及修改前后的样子。该模式下产生的binlog日志量会比较大，但优点是会非常清楚的记录下每一行数据修改的细节，主从复制不会出错。
Mixed：混合模式复制，以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。

在这里插入图片描述
mysql 8.0 默认就是 ROW

相关配置

show variables like '%log_bin%';

在这里插入图片描述
看到 log_bin 是 ON 的

show master logs;

在这里插入图片描述
可以看到当前又多少的 binlog 文件、那么前是哪一个？

show master status;

在这里插入图片描述

flush logs;

产生一个新的binlog日志文件

purge master logs before '2012-03-30 17:20:00';

删除某个时间点之前到 binlog

binlog_expire_logs_seconds 多久后自动清理 binlog 文件。mysql8.0 默认是 30 天
max_binlog_size 单个 binlog 的大小、默认是 1G （该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束）
sync_binlog （设置为0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新；
设置为1，表示每次事务提交，MySQL都会把binlog刷下去，这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响；
设置为n，其中n为0或1以外的值，在进行n次事务提交以后，Mysql将执行一次fsync之类的磁盘同步指令，将Binlog文件缓存刷新到磁盘。
推荐设置为1，出于性能考虑也可酌情调整。）

解释 binlog 内容
所有对数据库的修改都会记录在binglog中。但binlog是二进制文件，无法直接查看，想要更直观的观测它就要借助 mysqlbinlog 命令工具了

mysqlbinlog  --no-defaults --base64-output=decode-rows -vv binlog.000013

mysqlbinlog --no-defaults --base64-output=decode-rows -vv binlog.000013 > /tmp/bin13.sql
将解析到的SQL导入文件中
mysqlbinlog --no-defaults --base64-output=decode-rows -vv --database=testdb binlog.000013
只解析某个库的操作
mysqlbinlog --no-defaults --base64-output=decode-rows -vv --start-datetime=“2020-01-11 01:00:00” --stop-datetime=“2020-01-11 23:59:00” binlog.000008
解析指定时间段内的操作
mysqlbinlog --no-defaults --base64-output=decode-rows -vv --start-position=204136360 --stop-position=204136499 binlog.000008
解析指定pos位点内的操作
mysqlbinlog --no-defaults --start-position=204136360 --stop-position=204136499 binlog.000008 | mysql -uroot -pxxxx testdb
在指定库中恢复指定位点间的操作

大事务带来的坏处 https://cloud.tencent.com/developer/article/1595282