MySQL日志管理
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQL日志管理相关的知识，希望对你有一定的参考价值。
mysql日志管理
第1章 mysql日志类型
1.1 mysql日志类型简介:
1.2 错误日志:
1.2.1 作用:
记录mysql数据库的一般状态信息及报错信息,是对数据库报错处理常用的日志
1.2.2 配置方法:
[mysqld]
log-error=/var/log/mysql.log
1.2.3 配置查看方式:
mysql> show variables like '%log_error%';
+---------------------+--------------------+
| Variable_name | Value |
+---------------------+--------------------+
| binlog_error_action | IGNORE_ERROR |
| log_error | /var/log/mysql.log |
+---------------------+--------------------+
1.3 常规查询日志:
1.3.1 作用:
记录mysql所有执行成功的sql语句信息,可以做审计使用,但是很少开启此项
因为执行过的成功的语句都会记录,会浪费磁盘io
1.3.2 配置方法:
[mysqld]
general_log=1
general_log_file=/ application/mysql/data/db01.log
1.3.3 配置查看方法:
mysql> show variables like '%general%';
+------------------+----------------------------------+
| Variable_name | Value |
+------------------+----------------------------------+
| general_log | OFF |
| general_log_file | /application/mysql/data/db01.log |
+------------------+----------------------------------+
第2章 二进制日志:
2.1 二进制日志基本配置
2.1.1 作用:
1. 提供备份功能
2. 进行主从复制
3. 基于时间点的任意恢复
4. 记录在sql层已经执行完成的语句,如果是事务,则记录已经完成的事务
2.1.2 配置文件开启方法:
[mysqld]
log_bin=/data/mysql/mysql-bin 默认就是开启状态,这样设置是为了指定存放路径
2.1.3 查看二进制文件的类型:
[[email protected] mysql]# file mysql-bin.*
mysql-bin.000001: MySQL replication log
mysql-bin.index: ASCII text
2.1.4 查看二进制日志配置:
mysql> show variables like '%log_bin%';
+---------------------------------+-----------------------------+
| Variable_name | Value |
+---------------------------------+-----------------------------+
| log_bin | ON |
| log_bin_basename | /data/mysql/mysql-bin |
| log_bin_index | /data/mysql/mysql-bin.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+-----------------------------+
2.1.5 二进制日志记录格式:
statement:
SBR,语句模式记录二进制日志
SBR在数据恢复角度来讲不够好,如果操作时带有函数的操作,会导致恢复备份数据时,改变数据
row:
RBR,行模式记录二进制日志
mixed:
MBR,混合模式记录二进制日志
2.1.5.1 配置文件修改二进制日志格式:
[mysqld]
binlog_format=row
2.1.5.2 命令行修改二进制日志格式方法:
mysql> set global binlog_format='row';
mysql> set global binlog_format='mixed';
mysql> set global binlog_format='statement';
2.1.5.3 查看当前二进制文件定义的格式:
mysql> show variables like '%format%';
+--------------------------+-------------------+
| Variable_name | Value |
+--------------------------+-------------------+
| binlog_format | ROW |
| date_format | %Y-%m-%d |
| datetime_format | %Y-%m-%d %H:%i:%s |
| default_week_format | 0 |
| innodb_file_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| time_format | %H:%i:%s |
+--------------------------+-------------------+
2.2 二进制文件的操作:
2.2.1 操作系统层面查看:
[[email protected] mysql]# pwd
/data/mysql
[[email protected] mysql]# ll
total 76
-rw-rw---- 1 mysql mysql 143 Apr 9 15:24 mysql-bin.000001
-rw-rw---- 1 mysql mysql 657 Apr 9 17:02 mysql-bin.000002
2.2.2 刷新日志:
mysql> flush logs;
Query OK, 0 rows affected (0.32 sec)
2.2.3 查看当前使用的二进制日志文件:
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000012 | 120 | | | |
+------------------+----------+--------------+------------------+-------------------+
2.2.4 查看所有的二进制日志文件:
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 143 |
| mysql-bin.000002 | 657 |
| mysql-bin.000003 | 143 |
| mysql-bin.000004 | 143 |
| mysql-bin.000005 | 143 |
+------------------+-----------+
5 rows in set (0.00 sec)
名次说明:
1. 事件 events
a) 命令发生的最小单元,一个事务,是由多个事件组成
2. position
a) 每个事件在整个二进制文件中对应的位置号就是position号
2.2.5 导出二进制日志文件中的信息:
mysqlbinlog mysql-bin.000012 >/tmp/bin.txt
2.2.6 binlog日志的查看方式:
1. 查看binlog日志原始信息:
mysqlbinlog mysql-bin.000012
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#180409 21:10:05 server id 3306 end_log_pos 120 CRC32 0xf967602d Start: binlog v 4, server v 5.6.36-log created 180409 21:10:05
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
LWbLWg/qDAAAdAAAAHgAAAABAAQANS42LjM2LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAS1g
Z/k=
'/*!*/;
DELIMITER ;
# End of log file
2. 在row(行模式)下,翻译成sql语句
mysqlbinlog --base64-output=decode-rows -v /data/mysql/mysql-bin.000001
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#180409 13:52:02 server id 3306 end_log_pos 120 CRC32 0x1e347f1c Start: binlog v 4, server v 5.6.36-log created 180409 13:52:02 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET [email protected]_COMPLETION_TYPE*/;
3. 查看binlog事件:
mysql> show binlog events in 'mysql-bin.000010';
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
| mysql-bin.000010 | 4 | Format_desc | 3306 | 120 | Server ver: 5.6.36-log, Binlog ver: 4 |
| mysql-bin.000010 | 120 | Query | 3306 | 193 | BEGIN |
| mysql-bin.000010 | 193 | Table_map | 3306 | 239 | table_id: 70 (jiang.t1) |
| mysql-bin.000010 | 239 | Write_rows | 3306 | 289 | table_id: 70 flags: STMT_END_F |
| mysql-bin.000010 | 289 | Xid | 3306 | 320 | COMMIT /* xid=11 */ |
| mysql-bin.000010 | 320 | Query | 3306 | 393 | BEGIN |
| mysql-bin.000010 | 393 | Table_map | 3306 | 439 | table_id: 71 (jiang.t1) |
| mysql-bin.000010 | 439 | Write_rows | 3306 | 484 | table_id: 71 flags: STMT_END_F |
| mysql-bin.000010 | 484 | Xid | 3306 | 515 | COMMIT /* xid=35 */ |
| mysql-bin.000010 | 515 | Stop | 3306 | 538 | |
+------------------+-----+-------------+-----------+-------------+---------------------------------------+
2.2.7 删除二进制日志文件:
重置二进制日志,从1开始计数:
mysql> reset master;
Query OK, 0 rows affected (0.35 sec)
[[email protected] mysql]# ll
total 24
-rw-rw---- 1 mysql mysql 120 Apr 9 13:52 mysql-bin.000001
-rw-rw---- 1 mysql mysql 29 Apr 9 13:52 mysql-bin.index
-rw-rw---- 1 mysql mysql 16360 Apr 9 13:52 slow.log
根据存在时间删除:
mysql> set global_logs_days=7;
mysql> purge binary logs before now() - interval 3 day;
2.2.8 二进制日志在何时滚动:
1. 重启mysql服务
2. mysqldump –F 参数
3. 命令行执行flush
2.3 如何截取你需要的事务?
1. show binary logs; show master status;
2. show binlog events in ‘日志名’;从后往前看,找到误操作事务,判断事务开始和结束的position
3. 把误操作的剔除掉,留下正常操作到2个sql文件中
4. 先在测试库恢复,把误操作数据导出,然后在生产库恢复
2.3.1 上述方法存在的缺点:
1. 恢复时间较长
2. 对生产数据有一定的影响,有可能会出现冗余数据
2.3.2 较好的解决办法:
1. flashback闪回功能
2. 通过备份,延时从库
2.3.3 mysqlbinlog命令截取二进制日志常用参数:
参数 | 参数说明 |
--start-datetime | 从二进制日志中读取指定等于时间戳或者晚于本地计算机的时间 |
--stop-datetime | 从二进制日志中读取指定小于时间戳或者等于本地计算机的时间取值和上述一样 |
--start-position | 从二进制日志中读取指定position 事件位置作为开始。 |
--stop-position | 从二进制日志中读取指定position 事件位置作为事件截至 |
第3章 慢日志管理:
3.1 作用:
1. slow-log 记录所有条件内的慢的sql语句
2. 优化的一种工具日志,可以帮助我们定位问题
3.2 开启慢日志
vim /etc/my.cnf
slow_query_log 指定是否开启慢日志
slow_query_log_file=/data/mysql/slow.log 指定慢日志位置,可以为空,系统默认为host_name-slow.log
long_query_time=0.01 设定阈值,超出设定值的sql语句会被记录到慢日志中,缺省为10s
log_queries_not_using_indexes 不使用索引的sql语句是否记录到慢日志
3.3 查看慢日志相关配置:
mysql> show variables like '%slow%';
+---------------------------+----------------------+
| Variable_name | Value |
+---------------------------+----------------------+
| log_slow_admin_statements | OFF |
| log_slow_slave_statements | OFF |
| slow_launch_time | 2 |
| slow_query_log | ON |
| slow_query_log_file | /data/mysql/slow.log |
+---------------------------+----------------------+
3.4 判断慢语句的条件:
1. 按照时间长短
2. 不走索引的慢查询日志是否记录到索引
3. 查询检查返回少于该参数指定行的sql不被记录到慢查询日志
3.4.1 分析慢日志的角度:
1. 按照执行时间
2. 按照执行次数
3.4.2 例子:
mysqldumpslow -s c -t 10 /data/mysql/slow.log
Reading mysql slow query log from /data/mysql/slow.log
Count: 19 Time=0.02s (0s) Lock=0.00s (0s) Rows=0.0 (0), root[root]@localhost
INSERT INTO `city` VALUES (N,'S','S','S',N)
Count: 11 Time=0.00s (0s) Lock=0.00s (0s) Rows=4.6 (51), root[root]@localhost
select * from t1
3.5 mysqldumpslow 命令的参数
数 | 说明 |
-s | 是表示按照何种方式排序，c、t、l、r分别是按照记录次数、时间、查询 时间、返回的记录数来排序，ac、at、al、ar，表示相应的倒叙； |
-t | 是top n的意思，即为返回前面多少条的数据； |
-g | 后边可以写一个正则匹配模式，大小写不敏感的； |
3.6 怎么保证binlog和redolog已提交事务的一致性:
在没有开启binlog的时候,执行commit,就认为redo日志持久化到磁盘中,即落地成功,commit命令就成功
3.6.1 查看写binlog的参数:
sync_binlog 确保每个提交的事务都写到binlog中
mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 0 | #控制binlog commit阶段
+---------------+-------+
1 row in set (0.00 sec)
参数意义说明:
sync_binlog=1
默认值是0,像操作系统刷新其他文件的机制一样,mysql不会同步到磁盘中去而是依赖操作系统来刷新binary log
当sync_binlog=N(N>0),mysql在没写N次二进制日志binarylog时,会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去
如果启动了autocommit 那么每一个语句statement就会有一次写操作,否则每个事务对应一个写操作
企业案例:
业务人员反映,每天10-11点时间段,业务特别慢,其他时间都没有问题
解决思路:
1. 排除系统层面问题,确认是数据库方面问题
2. 慢日志自带时间戳,可以根据时间段,利用awk截取出日志中慢的sql语句
3. 使用pt-分析slowlog,找到top sql
4. 使用explain逐个分析top sql,最终发现,在排序条件上,未建立索引
5. 对问题SQL进行优化处理
结果:
经过处理,原SQL
以上是关于MySQL日志管理的主要内容，如果未能解决你的问题，请参考以下文章