其他数据库日志

文章目录

  • 其他数据库日志
    • 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个SQLmysqldumpslow -s r -t 10 /var/lib/mysql/slow.log#得到访问次数最多的10个SQLmysqldumpslow -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=ONgeneral_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-binbinlog_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 恢复的典型错误

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

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