【MySQL日志与备份篇】其他数据库日志

其他数据库日志

文章目录

  • 其他数据库日志
    • 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)。它记录了数据库所有执行的 DDLDML 等数据库更新事件的语句,但是不包含没有修改任何数据的语句(如数据查询语句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日志刷盘流程如下:

【MySQL日志与备份篇】其他数据库日志_第1张图片

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。

【MySQL日志与备份篇】其他数据库日志_第2张图片

使用两阶段提交后,写入binlog时发生异常也不会有影响。因为MySQL根据redo log日志恢复数据时,发现redo log还处于prepare阶段,并且没有对应bin log,就会回滚该事务。

【MySQL日志与备份篇】其他数据库日志_第3张图片

即使redo log在commit期间发生异常也不会回滚事务,它会先判断是否commit,没有commit,但通过事务id能找到对应的bin log,所以MySQL认为是完整的,就会提交事务恢复数据。

7. 中继日志(relay log)

7.1 介绍

中继日志只在主从服务器架构的从服务器上存在。从服务器为了与主服务器保持一致,要从主服务器读取二进制日志的内容,并且把读取到的信息写入 本地的日志文件 中,这个从服务器本地的日志文件就叫中继日志 。然后,从服务器读取中继日志,并根据中继日志的内容对从服务器的数据进行更新,完成主从服务器的 数据同步

搭建好主从服务器之后,中继日志默认会保存在从服务器的数据目录下。

文件名的格式是: 从服务器名 -relay-bin.序号 。中继日志还有一个索引文件: 从服务器名-relay-bin.index ,用来定位当前正在使用的中继日志。

【MySQL日志与备份篇】其他数据库日志_第4张图片

7.2 查看中继日志

中继日志与二进制日志的格式相同,可以用 mysqlbinlog 工具进行查看。

7.3 恢复的典型错误

如果从服务器宕机,有的时候为了系统恢复,要重装操作系统,这样就可能会导致你的 服务器名称 与之前 不同 。而中继日志里是 包含从服务器名 的。在这种情况下,就可能导致你恢复从服务器的时候,无法从宕机前的中继日志里读取数据,以为是日志文件损坏了,其实是名称不对了。

解决的方法也很简单,把从服务器的名称改回之前的名称。

你可能感兴趣的:(MySQL,数据库,mysql)