常用
mysql中所有的相关命令查询:
mysql> show variables like '%关键字%';
查询当前binlog文件模式:
mysql> show variables like '%binlog_format%';
临时修改模式:
mysql> set global binlog_format ='ROW';
永久修改:/etc/my.cnf配置文件
log-bin = /data/3306/mysql-bin
binlog_format="STATEMENT"
查询row模式的日志数据:
mysqlbinlog --base64-output="decode-rows"--verbose mysql-bin.00020
MySQL binlog的三种模式
ROW Level
记录的方式是行,即如果批量修改数据,记录的不是批量修改的SQL语句事件,而是每条记录被更改的SQL语句,因此,ROW模式的binlog日志文件会变得很“重”。
优点:row level的binlog日志内容会非常清楚的记录下每一行数据被修改的细节。而且不会出现某些特定情况下存储过程或function,以及trigger的调用和触发器无法被正确复制的问题。
缺点:row level下,所有执行的语句当记录到日志中的时候,都以每行记录的修改来记录,这样可能会产生大量的日志内容,产生的binlog日志量是惊人的。批量修改几百万条数据,那么记录几百万行……
Statement level(默认)
记录每一条修改数据的SQL语句(批量修改时,记录的不是单条SQL语句,而是批量修改的SQL语句事件)。看上面的图解可以很好的理解row level和statement level两种模式的区别。
优点:statement模式记录的更改的SQ语句事件,并非每条更改记录,所以大大减少了binlog日志量,节约磁盘IO,提高性能。
缺点:statement level下对一些特殊功能的复制效果不是很好,比如:函数、存储过程的复制。由于row level是基于每一行的变化来记录的,所以不会出现类似问题
Mixed
前两种模式的结合。在Mixed模式下,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。
模式选择
1、 如果生产中使用MySQL的特殊功能相对少(存储过程、触发器、函数)。选择默认的语句模式,Statement Level。
2、 如果生产中使用MySQL的特殊功能较多的,可以选择Mixed模式。
3、 如果生产中使用MySQL的特殊功能较多,又希望数据最大化一致,此时最好Row level模式;但是要注意,该模式的binlog非常“沉重”。
RBR和SBR的区别
执行一条update多数据行的更新为例: RBR 每一行的修改记录一条语句 SBR 记录这条批量更新语句 SBR有可能会记录错误语句
查看binlog文件
show master status;
show binlog events in '';
截取日志非GTID:
mysqlbinlog --start-position --stop-position
--base64-output=decode-rows (--help可以查到)
截取日志GTID:
GTID是5.6出现的,5.7推荐使用
biglog日志的清理
自动:
expire_logs_days=x (x为至少一个全备周期+1的天数)
手动:
mysql> help purge
PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';
binlog日志如何滚动
flush logs;
数据库重启
max_binlog_size=1073741824
slow慢查询
开关和文件位置:
mysql> show variables like "slow_query_log%";
配置参数:
mysql> show variables like "long%";
mysql> show variables like "%using_indexes%";
分析:
mysqldumpslow -s -c -t 10 /xxxx