MySQL中的日志主要分为以下几种:
查询日志
慢查询日志
错误日志
二进制日志
中继日志
事务日志
说明:
支持本文实验使用的linux系统是CentOS7版本,使用的数据库是base源自带的MariaDB,数据库使用的存储引擎使用默认的InnoDB
1、查询日志
记录查询语句、日志存储位置
日志的存放位置有两个地方:一是存储在指定文件中,一是存储在指定的表中。考虑到I/O压力,一般二者不会同时记录
从上述代码可以看出,查询日志具有两个变量;
下面来查看general_log表的详细信息:
事件时间
用户主机
事件的进程id
服务id
命令类型
参数
以上这些信息构成了general_log的主要内容,即记录的查询日志的操作内容可以通过上述信息显示
开启查询日志后,接着我们进行一些查询操作如:
这些查询操作就会被记录到日志文件centos7.log文件中,此文件是默认文件可以修改。而此文件的存放路径是相对路径即/var/lib/mysql/
以上演示的是日志信息记录在文件中,日志还可以记录在指定表中,只要修改一个变量即可:
关于表的日志记录与文件记录类似,不再演示
2、慢查询日志
慢查询:一条查询指令运行时间超出一定时长的操作,这种操作会对用户的体验大打折扣,应该尽量避免
一般建议启动此慢查询日志功能
默认的慢查询时间是10秒钟
并不是所有的指令执行时间超过10秒钟都会记录,其是有一个过滤器的
慢查询日志的用法与general_log的基本相同,不再赘述
3、错误日志
顾名思义,记录错误信息,主要记录如下几类信息:
(1) mysqld启动和关闭过程中输出的信息;
(2) mysqld运行中产生的错误信息;
(3) event scheduler运行时产生的信息;
(4) 主从复制架构中,从服务器复制线程启动时产生的日志;
错误日志是否开启,可以使用下述命令查看
4、二进制日志
用于记录引起数据改变或存在引起数据改变的潜在可能性的语句(STATEMENT)或改变后的结果(ROW),也可能是二者混合;
作用:
重放 (replay),即发生故障时可以使用二进制日志重新操作一遍故障发生前的指令
试想一下,在进行了全量备份数据库后,过了一天主数据库设备突然出现故障,这时我们虽然能够使用全量备份来恢复数据库,但是前一天的数据还未来得及备份,也就是说
少了一天的数据,这种情况下就可以使用二进制日志恢复缺失的一天的信息;
下面举个例子说明二进制日志在数据恢复中的重要作用:
创建数据库、表,插入数据
检查信息
修改mysql的服务配置文件,开启二进制日志功能
查看二进制日志信息
将当前数据库进行全量备份
当在全新的备份服务器上就行恢复时
按上述方式恢复即可
在/app/logs/下的二进制文件是无法直接使用cat或less查看的,所以需要使用mysqlbinlog专用工具
查看的内容包含以下信息:
事件的起始位置# at 553
事件发生的日期时间:#160831 9:56:08
事件发生的服务器id:server id 1
事件的结束位置:end_log_pos 624
事件的类型:Query
事件发生时所在服务器执行此事件的线程的ID: thread_id=2
语句的时间戳与将其写入二进制日志文件中的时间差:exec_time=0
错误代码:error_code=0
设定事件发生时的时间戳:SET TIMESTAMP=1472608568/*!*/;
事件内容:BEGIN
以上就是关于mysql日志的简单介绍
本文转自 a_pan 51CTO博客,原文链接:/panpangao/1980875