MySQL 日志管理

一 日志分类

二 错误日志

错误日志使用log_error以及log_warnings等参数进行定义

首次启动会提示错误日志位置，后期查询错误日志存放路径的命令如下

[root@db01 ~]# mysqladmin -uroot -pEgon@123 variables | grep -w log_error
 
或者
[root@db01t ~]# mysql -uroot -pEgon@123
mysql> show variables like '%log_error%';

log_error变量用于设置错误日志的存放位置（默认就是启用的）

[root@localhost ~]# vim /etc/my.cnf
[mysqld]
#绝对路径
log_error=/var/log/mysql.errlog
#相对路径
#log_error=mysql.errlog
 
[root@localhost ~]# touch /var/log/mysql.errlog
[root@localhost ~]# chmod 640 /var/log/mysql.errlog 
[root@localhost ~]# chown mysql.mysql /var/log/mysql.errlog 
[root@localhost ~]# systemctl restart mysqld

log_warnings用于标识警告信息是否一并记录到错误日志中

在MySQL 5.6中用log_warnings参数

log_warnings的值为0，表示不记录警告信息。
log_warnings的值为1，表示警告信息一并记录到错误日志中。
log_warnings的值大于1，表示"失败的连接"的信息和创建新连接时"拒绝访问"类的错误信息也会被记录到错误日志中。
 
mysql5.5中log_warnings参数的默认值为1
mysql5.7中log_warnings参数的默认值为2
mysql> show variables like "%log_warnings%";

mysql5.7新增的log_error_verbosity参数

# 它有三个可选值， 分别对应：
# log_error_verbosity=1：错误信息；
# log_error_verbosity=2：错误信息和告警信息；(推荐)
# log_error_verbosity=3（默认值就是3）：错误信息、告警信息和通知信息。

三 事务的日志

redo与undo详见《day10 MySQL事务中的redo与undo》

四 一般查询日志

1.默认是关闭的
一般不会开启，因为哪怕你开启事务一顿操作，最后不提交也会记录，生产上程序跑sql很多，会非常非常占地方，从来都不启动，要看操作去binlog
 
2.开启
[root@db01 ~]# vim /etc/my.cnf
general_log=on
general_log_file=/var/log/select.log
#可以使用set global general_log=on;设置
 
[root@localhost ~]# touch /var/log/select.log
[root@localhost ~]# chmod 640 /var/log/select.log
[root@localhost ~]# chown mysql.mysql /var/log/select.log
[root@localhost ~]# systemctl restart mysqld
3.查看一般查询日志
[root@db01 ~]# mysqladmin -uroot -pEgon@123 variables|grep general_log
	
或者
[root@db01 ~]# mysql -uroot -pEgon@123
mysql> show variables like '%gen%';

五 慢查询日志

5.1 慢日志作用

1）将mysql服务器中影响数据库性能的相关SQL语句(不论是什么语句，增删改查)记录到日志文件
2）通过对这些特殊的SQL语句分析并改进，提高数据库性能

5.2 配置慢日志

#默认慢日志是不开启的
 
[root@db01 ~]# vim /etc/my.cnf
[mysqld]
#指定是否开启慢查询日志
slow_query_log = 1
#指定慢日志文件存放位置（默认在data）
slow_query_log_file=/var/log/slow.log
#设定慢查询的阀值(默认10s)
long_query_time=0.05
#不使用索引的慢查询日志是否记录到日志
log_queries_not_using_indexes=ON
#查询检查返回少于该参数指定行的SQL不被记录到慢查询日志，少于100行的sql语句查询慢的话不记录，一般不使用
#min_examined_row_limit=100  # 鸡肋
 
执行下述命令
touch /var/log/slow.log
chmod 640 /var/log/slow.log
chown mysql.mysql /var/log/slow.log
systemctl restart mysqld

5.3 测试慢日志

测试方式一

测试:BENCHMARK(count,expr)
SELECT BENCHMARK(50000000,2*3);
 
#执行卡死，查看执行的sql执行时间，如果停不下来 可以 kill id
show processlist;
kill 3;

测试方式二

insert city_new select * from city;
insert city_new select * from city_new;
insert city_new select * from city_new;
insert city_new select * from city_new;

查看方式一

查看慢日志可以使用
cat /service/mysql/data/slow.log
看起来太费劲，我们使用方式二

查看方式二

mysqldumpslow -s r -t 10 /var/log/slow.log
 
得到按照时间排序的前10条里面含有左连接的查询语句
参数说明:
-s:指定排序方式
	c、t、l、r分别是按照记录次数、时间、查询时间、
	返回的记录数来排序，ac、at、al、ar，表示相应的倒叙
 
-t:是top n的意思，即为返回前面多少条的数据；
 
-g:后边可以写一个正则匹配模式，大小写不敏感的；

查看方式三

yum provides pt-query-digest

六 二进制日志

6.1 二进制日志简介

二进制日志即binlog日志，记录了mysql数据库所有的dml,ddl语句事件（不包含select）。记录增删改，也可以记录SQL语句及行记录变化，还可以记录这些操作事件；总之会记录所有修改操作的SQL语句。

　　不要混淆以下三种日志：

　　（1）general log：记录数据库里的所有SQL操作记录

　　（2）redo log：只记录innodb存储引擎的修改日志

　　（3）binlog：只记录server层面内部的修改情况。--select /show 不记录

6.2 开启binlog日志的好处

（1）数据恢复：可以基于时间点恢复，以及根据其进行增量与差异备份
（2）mysql主从复制，通过binlog实现数据复制

6.3 二进制日志的工作模式

（1）语句模式：binlog_format=statement（Mysql5.7.6之前的默认级别）

# 语句模式介绍
记录对数据库做出修改的sql语句,不记录该sql的上下文信息
 
例如
1、开启binlog日志后，我们在某个库下自定义函数，若想定义成功需要先设置配置项
set global log_bin_trust_function_creators=TRUE;  
 
2、然后自定义函数
delimiter //
create function f1(
    i1 int,
    i2 int)
returns int
BEGIN
    declare num int;
    set num = i1 + i2;
    return(num);
END //
delimiter ;
 
3、最后执行一条插入语句
insert into t1(name) values(concat("jason",f1(1,2)));
 
如果使用statement模式，那么这条insert语句将会被记录到二进制日志中,而sql语句中依赖的f1的定义是不会记录下来的，f1只存在于当前库。
 
# 优点
不需要记录细到每一行数据的更改变化，因此，binlog日志量小，IO压力小，性能较高
 
例如:
    一条语句修改了100万行，该模式下只需要记录下该条语句即可
 
# 缺点
日志中记录的sql语句可能有上下文依赖，此时脱离了当前数据库环就无法运行了，因此该模式下容易出现主从不一致的问题。
 
例如：
	主库记录的某条sql语句引用了主库中的函数、触发器、存储过程等特殊功能
    在从库上接收了该sql之后，可能就无法正确运行，从而主从库数据不一致的问题。
 
ps：row模式是基于每一行来记录变化的，所以不会出现类似的问题。
 
# 应用场景
sql语句对mysql内置功能依赖比较少：不使用存储过程/触发器/函数，可以使用该模式，否则还是推荐行级模式

（2）行级模式：binlog_format=row，（mysql5.7.6之后+8.0的默认级别）

# 行级模式介绍
记录每一行数据修改的细节，即哪一条记录被修改了，修改成什么样了
 
例如：执行语句（f1参照上例，此处略）
insert into t1(name) values(concat("jason",f1(1,2)));
 
如果使用row模式，那么日志中会记录插入了一条新记录，记录中的name字段值为'jason3'
 
# 优点
相当于把上下文依赖都记录了下来，可以更方便查看每一条数据修改的细节，并且不会出现某些特定情况下的存储过程或function以及trigger的调用和触发无法被正确复制的问题，即该模式下主从复制强一致，数据最安全。
 
# 缺点
日志量大
 
例如
    一条语句修改了100万行，语句模式下只需要记录一条语句即可
	而行级模式却修改记录下100万行的修改记录，binlog日志的量可能会大得惊人。
    
# 应用
sql语句对mysql内置功能依赖比较多，希望数据最安全，复制强一致的场景推荐行级模式

（3）混合模式：binlog_format=mixed，一般不用

# 混合模式介绍
结合 row level 与statement level的优点
混合（mixed-based）模式默认采用语句模式记录日志，在一些特定的情况下会将记录模式切换为行级模式记录，这些特殊情况包含但不限于以下情况。
•当函数中包含UUID()时。
•当表中有自增列（AUTO_INCREMENT）被更新时。
•当执行触发器（trigger）或者存储过程（stored function）等特殊功能时。
•当FOUND_ROWS()、ROW_COUNT()、USER()、CURRENT_USER()、CURRENT_USER等执行时。
 
# 应用场景
看上去这种方式似乎比较美好，但是在生产环境中，为了保险起见，一般会使用row模式。

6.4 binlog日志相关概念

二进制日志文件，顾名思义，它是二进制的，所以我们不能直接使用cat命令进行查看，而是需要通过一些别的命令查看其内容，而且，二进制日志文件，有”事件”和”位置”的概念，什么是事件呢？

(1) 事件events

通俗的讲，我们可以把binlog中的每一条记录当做一个”事件”，因为binlog记录了所有对数据库进行的修改，所以，我们可以认为，数据库的修改被记录到二进制日志中，这些记录每一条都可以理解为一个”事件”。

(2) 位置position

由于二进制日志文件是二进制的，所以，我们可以把整个二进制文件想象成一个字节序列。假设，二进制日志文件刚开始是空的，从第1个字节开始记录，假设记录第一个”事件”（第一条记录），需要15个字节，那么第一个事件的开始”位置”就是1，结束”位置”就是15，由于前15个字节已经被第一个事件占用，那么当我们想要通过二进制日志记录第二个事件时，则需要从第15个字节向后开始记录，假设记录第二个”事件”需要20个字节，那么第二个事件在binlog中的起始”位置”就是15，结束”位置”就是35，以此类推。

6.5 二进制日志相关参数

(1) server_id

服务ID,主从库必须不一样，建议数字为:ip+端口，5.7.3以后版本,必须指定

(2) log-bin

此变量用于控制是否开启二进制日志，而且这是一个只读变量，默认值为OFF
 
当我们启动数据库以后，在当前数据库连接中查看此变量的值，此变量值可能为OFF，表示不记录二进制日志，如果想要记录二进制日志，只需将此值设置为二进制日志的文件名即可，但是需要注意的是，我们无法在当前会话中使用set命令设置log_bin的值，因为它是一个只读变量，我们只能通过修改my.cnf的方式，设置log_bin的值，假设，我们编辑my.cnf文件，设置log_bin的值为mybinlog，那么，在mysql的数据目录中，将会自动生成一个以mybinlog为文件名前缀的二进制日志文件，如果想要再次禁用binlog，只需要将log_bin这一行配置从my.cnf文件中注释即可，或者将其删除，重启mysql服务后，再次查看log_bin的值，其值为OFF，注意，不要直接在my.cnf文件中将log_bin的值设置为ON或者OFF，如果这样做，你将会看到以ON或者OFF为文件名前缀的二进制日志文件。换句话说，如果my.cnf配置文件中没有log_bin的配置，则表示未开启二进制日志，如果my.cnf中存在log_bin的配置，那么则表示开启了二进制日志，同时二进制日志文件的名称将会以log_bin对应的值为文件名前缀，同时，二进制日志文件的后缀名会进行自动编号，每次日志滚动后，后缀名编号自动加1。
 
示例：
log-bin=/var/lib/mysql/mybinlog #绝对路径
# log-bin=mybinlog #也可以用相对路径， 会在$datadir下产生mysqlbinlog-00000N

(3) log_bin_index

不设置的话，会根据log_bin值名称自动生成mybinlog.index
log_bin_index=var/lib/mysql/mybinlog.index 

(4) sql_log_bin

默认为ON
此变量用于标识当前会话中的操作是否会被记录于二进制日志，此变量值设置为ON，则表示在当前数据库连接中，对数据库进行修改的语句将会被记录到binlog中，此变量值设置为OFF，则表示在当前数据库连接中，对数据库进行的修改的语句将不会被记录到binlog中，在主从复制结构中，这些语句由于没有被binlog记录，所以也不会同步到从节点中。换句话说，即使在my.cnf配置文件中设置了log_bin的值，当前会话中，如果sql_log_bin的值设置为OFF，当前会话的操作也不会记录在二进制日志中。而且需要注意的是，sql_log_bin是一个会话界别的变量，只能在当前会话中使用set sql_log_bin命令进行设置，不能使用set global sql_log_bin命令进行设置，因为它是会话级别的变量，而且，sql_log_bin也不能配置在my.cnf文件中，否则可能会无法启动mysql。

(5) binlog_format

此变量值得含义上文已经解释过，此变量的值决定了二进制日志的记录方式，此变量的值可以设置为statement、row、mixed，分别表示以语句的形式记录二进制日志，以数据修改的形式记录二进制日志，以混合的方式记录二进制日志，安全保险起见，推荐使用row的方式记录。

(6) max_binlog_size

设置单个二进制日志文件的最大大小，以字节为单位，超过此值大小，则二进制日志文件会自动滚动，比如设置为500M为524288000。

(7) sync_binlog

在存储引擎章节中我们提过：
innodb_flush_log_at_trx_commit控制redo日志的刷盘策略，建议值为1
sync_binlog控制binlog日志的刷盘策略，建议值为1
 
当我们把innodb_flush_log_at_trx_commit设置为1的时候，表示事务提交时，事务日志立马从内存刷写到磁盘中的事务日志文件中，而sync_binlog对于二进制日志的作用，就像innodb_flush_log_at_trx_commit对于事务日志的作用，由于二进制日志一开始存在于内存（binlog_cache）中，如果将sync_binlog设置为1，则表示每1次事务提交之后，都会立即将内存中的二进制日志立即同步到磁盘中的二进制日志文件中，如果将sync_binlog设置为0，则表示当事务提交之后，mysql不会立即将内存中的binlog刷写到磁盘中的binlog日志文件中，而是由文件系统决定什么时候刷写，这可能取决于文件系统的缓存机制，当此值设置为0时，一旦操作系统宕机，那么将丢失未从内存中同步到磁盘中的binlog，所以，当此值设置为0时，安全性最差，但是性能最高，当此值设置为1时，安全性最高，性能最差，除了将此值设置为0或1，还能设置为N，假设将此值设置为3，则表示每3次事务提交后，将binlog从内存刷写到磁盘一次，值设置的越大，有可能丢失的日志数据将会越多，当然，性能会越好，在追求安全的情况下，推荐设置为1，但是听说，此值设置为0和设置为1时在性能上的差距还是比较明显的，如果设置为0或N，最好为操作系统准备带有备用电源的缓存。

(8) 其他参数

#打开才能查看详细记录，默认为off
binlog_rows_query_log_events=on 
 
#表示自动删除10天以前的日志
expire_logs_days=10 
 
# full,minimal,noblob分别表示binlog中内容全记录，只记录被操作的，和不记录二进制
binlog_row_image=full #（full,minimal,noblob），

6.5 查看binlog配置项

show variables like '%log_bin%';
show variables like '%binlog%';
show variables like '%binlog_format%';
show variables like '%server%';
show variables like 'expire_logs_days'; -- 过期日志天数
 
# 或者
[root@db01 ~]# mysqladmin -uroot -pEgon@123 variables |grep -w log_bin

6.6 开启binlog

1.默认是关闭的
 
2.配置开启binlog
vim /etc/my.cnf
[mysqld]
server_id=1
log-bin=/var/lib/mysql/mybinlog 
binlog_format='row' #(row,statement,mixed)，不建议随意去修改binlog工作模式    
binlog_rows_query_log_events=on 
max_binlog_size=100M 

6.7 查看binlog日志

查看日志日志名、状态、事件
[rml_read_more]：

show binary logs;
show master logs;
show master status;
show binlog events in 'mybinlog.000002';
show binlog events in 'mybinlog.000002' limit 3;

查看日志内容

# 1、执行下述sql
create database if not exists test;
use test;
create table user(name varchar(10));
begin;
insert into user values("jason1"),("jason2"),("jason3");
update user set name="EGON" where name="jason1";
commit;
show master status; -- binlog的当前position
 
# 查看binlog，看看有没有记录，二进制文件我们看不了，有专门的命令
查看全部：
# mysqlbinlog mybinlog.000002
 
按时间：
# mysqlbinlog mybinlog.000002 --start-datetime="2022-11-05 10:02:56"
# mysqlbinlog mybinlog.000002 --stop-datetime="2022-11-05 11:02:54"
# mysqlbinlog mybinlog.000002 --start-datetime="2022-11-05 10:02:56" --stop-datetime="2022-11-05 11:02:54" 
 
按字节数：
# mysqlbinlog mybinlog.000002 --start-position=337
# mysqlbinlog mybinlog.000002 --stop-position=662
# mysqlbinlog mybinlog.000002 --start-position=337 --stop-position=662
 
如果是行级模式，想要看懂详细内容则需要加上额外参数，但是仅用于看懂内容，如果要用于还原数据，还是应该去掉额外的参数并将内容定位到文件中
#mysqlbinlog --base64-output=decode-rows -vvv mybinlog.000002  # 仅用于查看，不能用于日后的数据恢复
 
#mysqlbinlog mybinlog.000002  --start-position=100 > /tmp/1.sql # /tmp/1.sql可用于日后的数据恢复
 
如果查看过程报错
unknown variable 'default-character-set=utf8mb4' 
原因是mysql5.6中，mysqlbinlog这个工具无法识别binlog中的配置中的default-character-set=utf8mb4这个配置项目。
 
两个方法可以解决这个问题
一是在MySQL的配置/etc/my.cnf中
将default-character-set=utf8mb4 修改为 character-set-server = utf8mb4，但是这需要重启MySQL服务，如果你的MySQL服务正在忙，那这样的代价会比较大。
 
二是用mysqlbinlog --no-defaults mysql-bin.000001 命令打开

6.8 binlolg可以用来恢复数据

#修改数据
begin;
update user set name="XXX" where name="jason2";
commit;
#发现自己修改错了
select * from user;
#回滚，回滚不了，已经提交了
rollback;
select * from user;
#一怒之下删表
drop table user;
 
#恢复数据:查看binlog数据的起始点与要恢复到的位置点，导出成SQL
mysqlbinlog mybinlog.000002 --stop-position=772 > /tmp/binlog.sql
 
mysql -uroot -pEgon@123 < /tmp/binlog.sql

6.9 刷新与清除二进制日志

(1) 刷新binlog

#刷新binlog：关闭当前的二进制日志文件并创建一个新文件
1）手动执行命令刷新
flush logs;  
或者
mysqladmin -uroot -p flush-logs;
或者
mysql -uroot -pEgon@123 -e 'flush logs'
 
2）重启数据库时会刷新
3）二进制日志上限（max_binlog_size）;当binlog达到1G,自动刷新

(2) 清除binlog

# 清除二进制日志原则
在存储能力范围内，能多保留则多保留
基于上一次全备前的可以选择删除
 
1) 删除所有binlog，相当于重置
reset master;
 
2) 删除指定binlog名之前的所有binlog(保留指定的binlog)
purge binary logs to 'mybinlog.00003'; -- mybinlog.00003之前的都删除掉
 
3）删除日期之前的日志：手动执行
PURGE {MASTER | BINARY} LOGS BEFORE 'date' --用于删除日期之前的日志，BEFORE变量的date自变量可以为'YYYY-MM-DD hh:mm:ss'格式
 
如：（MASTER 和BINARY 在这里都是等效的）
PURGE MASTER LOGS TO 'mybinlog.00003';
purge binary logs before '2021-07-13 19:11:00';
 
还可以做减法：如只保留3天的
PURGE BINARY LOGS BEFORE now() - INTERVAL 3 day;
 
4）删除日期之前的日志：修改配置参数，让mysql自动执行
删除7天前的binlog
#临时生效
SET GLOBAL expire_logs_days = 7;
 
#永久生效
[root@db01 data]# vim /etc/my.cnf
[mysqld]
expire_logs_days = 7