公司使用的数据库是 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
https://developer.aliyun.com/article/939915
https://www.cnblogs.com/wuchangsoft/p/14121314.html