其他数据库日志
文章目录
- 其他数据库日志
- 1. 概述
- 1.1 日志类型
- 1.2 日志的弊端
- 2. 慢查询日志(slow query log)
- 3. 通用查询日志(general query log)
- 4. 错误日志(error log)
- 5. 二进制日志(bin log)
- 5.1 参数
- 5.2 查看日志
- 5.3 格式
- 5.3.1 STATEMENT模式 (基于SQL语句的复制(statement-based replication, SBR))
- 5.3.2 ROW模式(基于行的复制(row-based replication, RBR))
- 5.3.3 MIXED模式(混合模式复制(mixed-based replication, MBR))
- 5.4 使用日志恢复数据
- 5.5 删除二进制日志
- 5.6 其它场景
- 6. 再谈二进制日志(binlog)
- 6.1 写入机制
- 6.2 binlog与redolog对比
- 6.3 两阶段提交
- 7. 中继日志(relay log)
- 7.1 介绍
- 7.2 查看中继日志
- 7.3 恢复的典型错误
1. 概述
1.1 日志类型
MySQL有不同类型的日志文件,用来存储不同类型的日志,分为 二进制日志
、 错误日志
、 通用查询日志
和 慢查询日志
,这也是常用的4种。MySQL 8又新增两种支持的日志: 中继日志
和 数据定义语句日志
。使用这些日志文件,可以查看MySQL内部发生的事情。
这6类日志分别为:
- 慢查询日志:记录所有执行时间超过long_query_time的所有查询,方便我们对查询进行优化。
- 通用查询日志:记录所有连接的起始时间和终止时间,以及连接发送给数据库服务器的所有指令,对我们复原操作的实际场景、发现问题,甚至是对数据库操作的审计都有很大的帮助。
- 错误日志:记录MySQL服务的启动、运行或停止MySQL服务时出现的问题,方便我们了解服务器的状态,从而对服务器进行维护。
- 二进制日志:记录所有更改数据的语句,可以用于主从服务器之间的数据同步,以及服务器遇到故障时数据的无损失恢复。
- 中继日志:用于主从服务器架构中,从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容,来同步主服务器上的操作。
- 数据定义语句日志:记录数据定义语句执行的元数据操作。
除 二进制日志
外,其他日志都是 文本文件
。默认情况下,所有日志创建于 MySQL数据目录
中。
1.2 日志的弊端
- 日志功能会
降低MySQL数据库的性能
- 日志会
占用大量的磁盘空间
2. 慢查询日志(slow query log)
慢查询日志开关:slow_query_log
,默认关闭
慢查询日志阈值:long_query_time
,默认10,单位秒
查看慢SQL条数:
SHOW GLOBAL STATUS LIKE '%Slow_queries%';
慢查询日志分析工具:mysqldumpslow
工作常用参考:
#得到返回记录集最多的10个SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/slow.log
#得到访问次数最多的10个SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/slow.log
#得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/slow.log
#另外建议在使用这些命令时结合 | 和more 使用 ,否则有可能出现爆屏情况
mysqldumpslow -s r -t 10 /var/lib/mysql/slow.log | more
[mysqld]
slow_query_log=OFF
3. 通用查询日志(general query log)
通用查询日志用来 记录用户的所有操作
,包括启动和关闭MySQL服务、所有用户的连接开始时间和截止时间、发给 MySQL 数据库服务器的所有 SQL 指令等。当我们的数据发生异常时,查看通用查询日志,还原操作时的具体场景,可以帮助我们准确定位问题。
SHOW VARIABLES LIKE '%general%';
默认关闭
[mysqld]
general_log=ON
general_log_file=[path[filename]] #日志文件所在目录路径,filename为日志文件名
4. 错误日志(error log)
在MySQL数据库中,错误日志功能是 默认开启
的。而且,错误日志 无法被禁止
。
默认情况下,错误日志存储在MySQL数据库的数据文件夹下,名称默认为 mysqld.log
(Linux系统)或 hostname.err
(mac系统)。如果需要制定文件名,则需要在my.cnf或者my.ini中做如下配置:
[mysqld]
log-error=[path/[filename]] #path为日志文件所在的目录路径,filename为日志文件名
5. 二进制日志(bin log)
binlog即binary log,二进制日志文件,也叫作变更日志(update log)。它记录了数据库所有执行的 DDL
和 DML
等数据库更新事件的语句,但是不包含没有修改任何数据的语句(如数据查询语句select、show等)。
binlog主要应用场景:
数据恢复
数据复制
5.1 参数
在MySQL8中默认情况下,二进制文件是开启的。
show variables like '%log_bin%';
[mysqld]
#启用二进制日志
log-bin=log-bin
binlog_expire_logs_seconds=60000 # 二进制日志文件保留的时长,单位秒,默认2592000 30天
max_binlog_size=100M # 单个二进制文件大小,最大和默认值是1GB,该参数不能严格控制大小,为保证事务完整性,会继续记录到事务结束;一般用默认值即可
设置带文件夹的bin-log日志存放目录
[mysqld]
log-bin="/var/lib/mysql/binlog/log-bin"
数据库文件最好不要与日志文件放在同一个磁盘上!这样,当数据库文件所在的磁盘发生故障时,可以使用日志文件恢复数据
5.2 查看日志
当MySQL创建二进制日志文件时,先创建一个以“filename”为名称、以“.index”为后缀的文件,再创建一个以“filename”为名称、以“.000001”为后缀的文件。
MySQL服务 重新启动一次 ,以“.000001”为后缀的文件就会增加一个,并且后缀名按1递增。即日志文件的个数与MySQL服务启动的次数相同;如果日志长度超过了 max_binlog_size
的上限(默认是1GB),就会创建一个新的日志文件。
查看当前的二进制日志文件列表及大小。指令如下:
SHOW BINARY LOGS;
查看日志
mysqlbinlog -v --base64-output=DECODE-ROWS "/var/lib/mysql/binlog/log-bin.000002"
更方便的语句
show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
5.3 格式
MySQL 5.7.7 之前,binlog 的默认格式都是 STATEMENT,在 5.7.7 及更高版本中,binlog_format 的默认值才是 ROW,从数据准确性考虑,推荐使用 ROW 格式
- Statement:每一条会修改数据的sql都会记录在binlog中
- 优点:不需要记录每一行的变化,减少了binlog日志量,节约了IO,提高性能
- Row:它不记录sql语句上下文相关信息,仅保存哪条记录被修改
- 优点:row level 的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程,或function,以及trigger的调用和触发无法被正确复制的问题。
- Mixed:是Statement与Row的结合
5.3.1 STATEMENT模式 (基于SQL语句的复制(statement-based replication, SBR))
每一条会修改数据的sql语句会记录到binlog中。
重大缺点:
- 不是所有的UPDATE语句都能被复制,尤其是包含不确定操作的时候
- 数据表必须几乎和主服务器保持一致才行,否则可能会导致复制出错
- INSERT … SELECT 会产生比 RBR 更多的行级锁
5.3.2 ROW模式(基于行的复制(row-based replication, RBR))
不记录每条sql语句的上下文信息,仅记录哪条数据被修改了,修改成什么样了。
优点:
- 任何情况都可以被复制,这对复制来说是最
安全可靠
的。 - 从服务器上采用
多线程
来执行复制成为可能 - 执行 INSERT,UPDATE,DELETE 语句时锁更少
缺点:
- binlog 大了很多
- 主服务器上执行 UPDATE 语句时,所有发生变化的记录都会写到 binlog 中,而 SBR 只会写一次,这会导致频繁发生 binlog 的并发写问题
- 无法从 binlog 中看到都复制了些什么语句
5.3.3 MIXED模式(混合模式复制(mixed-based replication, MBR))
实际上就是Statement与Row的结合。
在Mixed模式下,一般的语句修改使用statment格式保存binlog。如一些函数,statement无法完成主从复制的操作,则采用row格式保存binlog。
MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。
该模式并非是只综合了上面两种方式的优点,上面两者的很多缺点也存在,从效果上看显然解决了SBR模式下的不确定操作问题
5.4 使用日志恢复数据
mysqlbinlog恢复数据的语法如下:
mysqlbinlog [option] filename|mysql –uuser -ppass;
这个命令可以这样理解:使用mysqlbinlog命令来读取filename中的内容,然后使用mysql命令将这些内容恢复到数据库中。
- filename :是日志文件名
- option :可选项,比较重要的两对option参数是–start-date、–stop-date 和 --start-position、–stop-position
- –start-date 和 --stop-date :可以指定恢复数据库的起始时间点和结束时间点
- –start-position和–stop-position :可以指定恢复数据的开始位置和结束位置
数据恢复前记得执行 flush log
,让后续新的操作记录到新的bin log日志文件
注意:使用mysqlbinlog命令进行恢复操作时,必须是编号小的先恢复,例如 log-bin.000001 必须在 log-bin.000002之前恢复。
5.5 删除二进制日志
删除指定日志文件
PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名’
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期’
删除所有二进制日志文件,MySQL会重新创建二进制文件,新的日志文件扩展名将重新从000001开始编号,慎用:
RESET MASTER;
5.6 其它场景
二进制日志可以通过数据库的 全量备份
和二进制日志中保存的 增量信息
,完成数据库的 无损失恢复
。但是,如果遇到数据量大、数据库和数据表很多(比如分库分表的应用)的场景,用二进制日志进行数据恢复,是很有挑战性的,因为起止位置不容易管理。
在这种情况下,一个有效的解决办法是 配置主从数据库服务器
,甚至是 一主多从
的架构,把二进制日志文件的内容通过中继日志,同步到从数据库服务器中,这样就可以有效避免数据库故障导致的数据异常等问题。
6. 再谈二进制日志(binlog)
6.1 写入机制
binlog的写入时机也非常简单,事务执行过程中,先把日志写到 binlog cache ,事务提交的时候,再把binlog cache写到binlog文件中。因为一个事务的binlog不能被拆开,无论这个事务多大,也要确保一次性写入,所以系统会给每个线程分配一个块内存作为binlog cache。
可以通过 binlog_cache_size
参数控制单个线程 binlog cache的大小,如果存储内容超过了这个参数,就要暂存到磁盘。binlog日志刷盘流程如下:
write和fsync的时机,可以由参数 sync_binlog
控制,默认是 0 。
- 0:表示每次提交事务都只write,由系统自行判断什么时候执行fsync。虽然性能得到提升,但是机器宕机,page cache里面的binglog 会丢失。
- 1:表示每次提交事务都会执行fsync,就如同
redo log 刷盘流程
一样。安全起见可以设置为1。 - N(N>1):表示每次提交事务都write,但累积N个事务后才fsync。在出现IO瓶颈的场景里,将sync_binlog设置成一个比较大的值,可以提升性能。但有丢失最近N个事务的binlog日志的风险。
6.2 binlog与redolog对比
- redo log
物理日志
,记录内容是“在某个数据页上做了什么修改”,属于 InnoDB 存储引擎层产生的 - binlog 是
逻辑日志
,记录内容是语句的原始逻辑,类似于“给 ID=2 这一行的 c 字段加 1”,属于MySQL Server 层
6.3 两阶段提交
在执行更新语句过程,会记录redo log与binlog两块日志,以基本的事务为单位,redo log在事务执行过程中可以不断写入,而binlog只有在提交事务时才写入,所以redo log与binlog的 写入时机
不一样。
因为有了两份日志,两份日志之间可能会产生不一致的情况,比如redo log写完后,bin log还未写入时服务器宕机,bin log中就没法记录redo log写完后的数据了,主从复制将会存在问题。
为了解决两份日志之间的逻辑一致问题,InnoDB存储引擎使用两阶段提交方案。原理很简单,将redo log的写入拆成了两个步骤prepare和commit。
使用两阶段提交后,写入binlog时发生异常也不会有影响。因为MySQL根据redo log日志恢复数据时,发现redo log还处于prepare阶段,并且没有对应bin log,就会回滚该事务。
即使redo log在commit期间发生异常也不会回滚事务,它会先判断是否commit,没有commit,但通过事务id能找到对应的bin log,所以MySQL认为是完整的,就会提交事务恢复数据。
7. 中继日志(relay log)
7.1 介绍
中继日志只在主从服务器架构的从服务器上存在。从服务器为了与主服务器保持一致,要从主服务器读取二进制日志的内容,并且把读取到的信息写入 本地的日志文件
中,这个从服务器本地的日志文件就叫中继日志 。然后,从服务器读取中继日志,并根据中继日志的内容对从服务器的数据进行更新,完成主从服务器的 数据同步
。
搭建好主从服务器之后,中继日志默认会保存在从服务器的数据目录下。
文件名的格式是: 从服务器名 -relay-bin.序号
。中继日志还有一个索引文件: 从服务器名-relay-bin.index
,用来定位当前正在使用的中继日志。
7.2 查看中继日志
中继日志与二进制日志的格式相同,可以用 mysqlbinlog
工具进行查看。
7.3 恢复的典型错误
如果从服务器宕机,有的时候为了系统恢复,要重装操作系统,这样就可能会导致你的 服务器名称
与之前 不同
。而中继日志里是 包含从服务器名
的。在这种情况下,就可能导致你恢复从服务器的时候,无法从宕机前的中继日志里读取数据,以为是日志文件损坏了,其实是名称不对了。
解决的方法也很简单,把从服务器的名称改回之前的名称。