Mariadb/mysql提供了4中不同的日志,分别是错误日志(error.log)、普通日志(general log)、慢日志(slow log)以及二进制日志(binlog)。
错误日志记录了系统启动、运行以及停止过程中遇到的一些问题;
普通日志记录了Mariadb执行的所有语句以及语句开始执行的时间等信息,用户可以选择性的打开它;
慢日志记录了Mariadb所有慢查询的相关信息;
二进制日志则以事件的形式记录了mariadb的库表结构以及表数据的所有变更信息。
二进制日志
binlog作用
复制:在Mariadb/mysql的主从结构中,主库的binlog记录了主库的所有更改操作,从库通过读取主库的binlog,在本地重放获取的binlog,这样从库就拥有和主库相同的数据,达到复制目的。
备份恢复:binlog记录了数据库的所有更改信息,所以当Mariadb/mysql发生崩溃的时候,能够以最近备份点作为起点,然后执行在备份点之后产生的binlog中所有事件,实现数据库最大可能的恢复。
index文件按照书序记录了Mariadb/Mysql使用的所有binlog文件,管理binlog文件。
binlog三种格式
1、STATEMENT模式(SBR)
每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化,减少了binlog日志量,节约IO,提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数, last_insert_id(),以及user-defined functions(udf)等会出现问题)
2、ROW模式(RBR)
不记录每条sql语句的上下文信息,仅需记录哪条数据被修改了,修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志,尤其是alter table的时候会让日志暴涨。
3、MIXED模式(MBR)
以上两种模式的混合使用,一般的复制使用STATEMENT模式保存binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存binlog,MySQL会根据执行的SQL语句选择日志保存方式。
binlog配置参数
log_bin = mysql-bin #是否开启了二进制日志 binlog_format = ROW #二进制日志记录的模式 expire_logs_days = 30 #二进制日志自动删除的天数。默认值为0,表示"没有自动删除"
清理binlog
1、使用Mariadb提供的purge命令
进入数据库执行以下命令:
purge {binary | master } logs to "binlog-file-name" #binlog—file-name之前的所有binlog文件清理掉
purge {binary | master } logs before "datetime-expi" #将最后修改时间早于datetime-expi的binlog文件清理掉
2、使用rm命令手动清理binlog。
(1)确保你的mysql处于停止状态
(2)使用rm命令按顺序删除binlog文件
(3)修改index文件,把已经删除的binlog文件从index文件中删除
自动清理binlog
expire_log_days=N参数(0≤N≤99),过期的binlog会被自动清理掉。
mysqlbinlog工具
mysqlbinlog工具可以将binlog中事件包含的信息以文本的形式打印出来。
mysqlbinlog [options] <binlog-file> ...
通过mysqlbinlog进行恢复主要有一下两步,
1:使你的数据库恢复到最近备份点的状态
2:执行mysqlbinlog your-bin-log | mysql -u root -p ,将binlog中记录的修改,反映到数据库中。(如果有多个binlog文件,本步需要执行多次)
如果报错:mysqlbinlog: unknown variable ‘default-character-set=utf8’
原因是mysqlbinlog这个工具无法识别binlog中的配置中的default-character-set=utf8这个指令。
可以添加--no-defaults 解决。
binlog常用sql
#查看是否已经成功启用 show global variables like 'log_bin'; #显示当前日志文件 show binary logs; #刷新log,生成新的 flush logs; #清空log,重新开始 reset master; #查询binlog内容 show binlog events in 'mysql-bin.000001'G;