MySql Study之--MySql日志管理

灰太狼 2022-08-07 10:58 206阅读 0赞

**MySql Study之--MySql日志管理**

## **一、日志文件类型** ##

MySQL有几个不同的日志文件，可以帮助你找出**mysqld**内部发生的事情：

<table> 
 <tbody> 
 <tr> 
 <td> 日志文件 </td> 
 <td> 日志文件信息内容 </td> 
 </tr> 
 <tr> 
 <td> 错误日志 </td> 
 <td> 记录启动、运行或停止mysqld时出现的问题。（log_err) </td> 
 </tr> 
 <tr> 
 <td> 查询日志 </td> 
 <td> 记录建立的客户端连接和执行的语句。 </td> 
 </tr> 
 <tr> 
 <td> 更新日志 </td> 
 <td> 记录更改数据的语句，不赞成使用该日志。 </td> 
 </tr> 
 <tr> 
 <td> 二进制日志 </td> 
 <td> 记录所有更改数据的语句。还用于复制。（bin_log） </td> 
 </tr> 
 <tr> 
 <td> 慢日志 </td> 
 <td> 记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。（slow_query_log） </td> 
 </tr> 
 </tbody> 
</table>

**二、查询日志存放位置**

**1、错误日志（log\_err指定了错误日志的位置）**

**      ** 错误日志文件包含了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。

如果mysqld莫名其妙地死掉并且mysqld\_safe需要重新启动它，mysqld\_safe在错误日志中写入一条restarted mysqld消息。如果mysqld注意到需要自动检查或着修复一个表，则错误日志中写入一条消息。

在一些操作系统中，如果mysqld服务终止，错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld终止的地方。

可以用--log-error\[=*file\_name*\]选项来指定mysqld保存错误日志文件的位置。如果没有给定*file\_name*值，mysqld使用错误日志名*host\_name.err *并在数据目录中写入日志文件。如果你执行FLUSH LOGS，错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。

如果不指定--log-error，或者(在Windows中)如果你使用--console选项，错误被写入标准错误输出stderr。通常标准输出为你的终端。

[root@rh6 ~]# more /var/log/mysqld.log 
 150402 10:26:07 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
 150402 10:26:08 InnoDB: The InnoDB memory heap is disabled
 150402 10:26:08 InnoDB: Mutexes and rw_locks use GCC atomic builtins
 150402 10:26:08 InnoDB: Compressed tables use zlib 1.2.3
 150402 10:26:08 InnoDB: Using Linux native AIO
 150402 10:26:08 InnoDB: CPU does not support crc32 instructions
 150402 10:26:08 InnoDB: Initializing buffer pool, size = 128.0M
 150402 10:26:08 InnoDB: Completed initialization of buffer pool
 150402 10:26:08 InnoDB: highest supported file format is Barracuda.
 InnoDB: The log sequence number in ibdata files does not match
 InnoDB: the log sequence number in the ib_logfiles!
 150402 10:26:08 InnoDB: Database was not shut down normally!
 InnoDB: Starting crash recovery.
 InnoDB: Reading tablespace information from the .ibd files...
 InnoDB: Restoring possible half-written data pages from the doublewrite
 InnoDB: buffer...
 150402 10:26:10 InnoDB: 128 rollback segment(s) are active.
 150402 10:26:10 InnoDB: Waiting for the background threads to start
 150402 10:26:11 InnoDB: 1.2.4 started; log sequence number 1602901
 150402 10:26:11 [Note] Recovering after a crash using mysql-bin
 150402 10:26:11 [Note] Starting crash recovery...
 150402 10:26:11 [Note] Crash recovery finished.
 150402 10:26:11 [Note] Event Scheduler: Loaded 0 events
 150402 10:26:11 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
 Version: '5.6.4-m7-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution

## **2、慢速查询日志（slow\_query\_log）** ##

用--log-slow-queries[=file_name]选项启动时，mysqld写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。获得初使表锁定的时间不算作执行时间。

如果没有给出file_name值， 默认未主机名，后缀为-slow.log。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。

语句执行完并且所有锁释放后记入慢查询日志。记录顺序可以与执行顺序不相同。

慢查询日志可以用来找到执行时间长的查询，可以用于优化。但是，检查又长又慢的查询日志会很困难。要想容易些，你可以使用mysqldumpslow命令获得日志中显示的查询摘要来处理慢查询日志。

在MySQL 5.1的慢查询日志中，不使用索引的慢查询同使用索引的查询一样记录。要想防止不使用索引的慢查询记入慢查询日志，使用--log-short-format选项。

在MySQL 5.1中,通过--log-slow-admin-statements服务器选项，你可以请求将慢管理语句，例如OPTIMIZE TABLE、ANALYZE TABLE和 ALTER TABLE写入慢查询日志。

用查询缓存处理的查询不加到慢查询日志中，因为表有零行或一行而不能从索引中受益的查询也不写入慢查询日志。

默认情况下MySql没有开启慢查询日志，开启慢查询日志：

**查看慢查询日志：**

[root@rh6 mysql]# cat /var/lib/mysql/rh6-slow.log
    /usr/local/mysql/bin/mysqld, Version: 5.6.4-m7 (Source distribution). started with:
    Tcp port: 3306  Unix socket: /tmp/mysql.sock
    Time                 Id Command    Argument

## **3、二进制日志（log\_bin）** ##

### **1）二进制文件介绍** ###

二进制日志以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。

二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。

备注：二进制日志已经代替了老的更新日志，更新日志在MySQL 5.1中不再使用。

### **2）二进制文件的功能** ###

二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。如果你想要记录所有语句（例如，为了识别有问题的查询），你应使用一般查询日志。

二进制日志的主要目的是在恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。

二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。

运行服务器时若启用二进制日志则性能大约慢1%。但是，二进制日志的好处，即用于恢复并允许设置复制超过了这个小小的性能损失。

### **3）二进制文件的存储路径** ###

当用--log-bin\[=*file\_name*\]选项启动时，**mysqld**写入包含所有更新数据的SQL命令的日志文件。如果未给出*file\_name*值， 默认名为-bin后面所跟的主机名。如果给出了文件名，但没有包含路径，则文件被写入数据目录。建议指定一个文件名.

如果你在日志名中提供了扩展名(例如，--log-bin=*file\_name.extension*)，则扩展名被悄悄除掉并忽略。

**mysqld**在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max\_binlog\_size，还会自动创建新的二进制日志。如果你正使用大的事务，二进制日志还会超过max\_binlog\_size：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。

为了能够知道还使用了哪个不同的二进制日志文件，**mysqld**还创建一个二进制日志索引文件，包含所有使用的二进制日志文件的文件名。默认情况下与二进制日志文件的文件名相同，扩展名为'.index'。你可以用--log-bin-index\[=*file\_name*\]选项更改二进制日志索引文件的文件名。当**mysqld**在运行时，不应手动编辑该文件；如果这样做将会使**mysqld**变得混乱。

开启二进制日志：
 [root@rh6 mysql]# cat /etc/my.cnf
 [mysqld]
 datadir=/var/lib/mysql
 socket=/tmp/mysql.sock
 #socket=/var/lib/mysql/mysql.sock
 user=mysql
 # Disabling symbolic-links is recommended to prevent assorted security risks
 symbolic-links=0
 
 log-bin=mysql-bin
 binlog_format=mixed
 
 [mysqld_safe]
 log-error=/var/log/mysqld.log
 pid-file=/var/run/mysqld/mysqld.pid

**开启二进制日志后：**

[root@rh6 ~]# ls -l /var/lib/mysql/
    total 28704
    -rw-rw---- 1 mysql mysql       56 Jan 28 17:25 auto.cnf
    -rw-rw---- 1 mysql mysql 18874368 Apr  2 10:26 ibdata1
    -rw-rw---- 1 mysql mysql  5242880 Apr  2 10:26 ib_logfile0
    -rw-rw---- 1 mysql mysql  5242880 Jan 28 17:21 ib_logfile1
    drwx------ 2 mysql root      4096 Jan 28 17:21 mysql
    -rw-rw---- 1 mysql mysql      114 Apr  2 10:26 mysql-bin.000001
    -rw-rw---- 1 mysql mysql      114 Apr  2 10:26 mysql-bin.000002
    -rw-rw---- 1 mysql mysql       38 Apr  2 10:26 mysql-bin.index
    drwx------ 2 mysql mysql     4096 Jan 28 17:21 performance_schema
    -rw-rw---- 1 mysql mysql      173 Mar 31 11:05 rh6-slow.log
    drwx------ 2 mysql root      4096 Jan 28 17:21 test

**查看二进制文件内容：**

**mysql-bin.index 是二进制文件的索引，一般不能更改**

\[root@rh6 mysql\]\# cat mysql-bin.index

./mysql-bin.000001

./mysql-bin.000002

**通过mysqlbinlog工具读取二进制文件内容：**

[root@rh6 mysql]# mysqlbinlog mysql-bin.000002
 /*!40019 SET @@session.max_insert_delayed_threads=0*/;
 /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
 DELIMITER /*!*/;
 # at 4
 #150402 10:26:11 server id 1 end_log_pos 114 Start: binlog v 4, server v 5.6.4-m7-log created 150402 10:26:11 at startup
 # Warning: this binlog is either in use or was not closed properly.
 ROLLBACK/*!*/;
 BINLOG '
 w6gcVQ8BAAAAbgAAAHIAAAABAAQANS42LjQtbTctbG9nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAADDqBxVEzgNAAgAEgAEBAQEEgAAVgAEGggAAAAICAgCAAAAAJLUw68=
 '/*!*/;
 DELIMITER ;
 # End of log file
 ROLLBACK /* added by mysqlbinlog */;
 /*!50003 SET <a target=_blank href="mailto:COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;">COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
 </a>

[root@rh6 mysql]# mysqlbinlog mysql-bin.000001
 /*!40019 SET @@session.max_insert_delayed_threads=0*/;
 /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
 DELIMITER /*!*/;
 # at 4
 #150331 11:11:39 server id 1 end_log_pos 114 Start: binlog v 4, server v 5.6.4-m7-log created 150331 11:11:39 at startup
 ROLLBACK/*!*/;
 BINLOG '
 axAaVQ8BAAAAbgAAAHIAAAAAAAQANS42LjQtbTctbG9nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAABrEBpVEzgNAAgAEgAEBAQEEgAAVgAEGggAAAAICAgCAAAAALen85c=
 '/*!*/;
 DELIMITER ;
 # End of log file
 ROLLBACK /* added by mysqlbinlog */;
 /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
 [root@rh6 mysql]#

**清理二进制日志文件**  
  
     如果每天都会生成大量的二进制日志，这些日志长时间不清理的话，将会对磁盘空间带来很大的浪费，所以定期清理日志是DBA维护mysql的一个重要工作  
  
1)**RESET MASTER**  
     在上面查看日志存放的文件夹中，二进制日志命名的格式是以mysql-bin.\*，\*代表日志的序号,序号是递增的,其中还有mysql-bin.index是日志的索引文件,记录了日志的最大序号

mysql> reset master;
 Query OK, 0 rows affected (0.08 sec)
 
 [root@rh6 mysql]# ls -l
 total 28700
 -rw-rw---- 1 mysql mysql 56 Jan 28 17:25 auto.cnf
 -rw-rw---- 1 mysql mysql 18874368 Apr 2 10:26 ibdata1
 -rw-rw---- 1 mysql mysql 5242880 Apr 2 10:26 ib_logfile0
 -rw-rw---- 1 mysql mysql 5242880 Jan 28 17:21 ib_logfile1
 drwx------ 2 mysql root 4096 Jan 28 17:21 mysql
 -rw-rw---- 1 mysql mysql 114 Apr 2 11:20 mysql-bin.000001
 -rw-rw---- 1 mysql mysql 19 Apr 2 11:20 mysql-bin.index
 drwx------ 2 mysql mysql 4096 Jan 28 17:21 performance_schema
 -rw-rw---- 1 mysql mysql 173 Mar 31 11:05 rh6-slow.log
 drwx------ 2 mysql root 4096 Jan 28 17:21 test

\--可以看到日志又重新从000001开始

2)**PURGE MASTER LOGS TO** & **PURGE MASTER LOGS BEFORE**  
      执行PURGE MASTER LOGS TO 'mysql-bin.\*\*\*\*\*\*'命令，是将'\*\*\*\*\*\*'编号之前的所有日志进行删除  
     执行PURGE MASTER LOGS BEFORE 'yyyy-mm-dd hh:mm:ss'命令，是将在'yyyy-mm-dd hh:mm:ss'时间之前的所有日志进行删除  
  
3)**EXPIRE\_LOGS\_DAYS**  
    此参数是设置日志的过期天数，过期的日志将会被自动删除，这有利于减少我们管理日志的工作量，需要修改my.cnf

expire\_logs\_days=3

这里我们设定保存日志为3天，3天之后过期的日志将被自动删除

**通过二进制日志恢复数据**  
  
       bin-log是记录着mysql所有事件的操作，当mysql发生灾难性错误时，可以通过bin-log做完整恢复，基于时间点的恢复，和基于位置的恢复  
  
**完整恢复：**

**       ** 假定我们每天凌晨2点都会使用mysqldump备份数据库，但在第二天早上9点由于数据库出现了故障，数据无法访问，需要恢复数据，先使用昨天凌晨备份的文件进行恢复到凌晨2点的状态，在使用mysqlbinlog恢复自mysqldump备份以来的binlog  
          **mysql localhost mysql-bin.000001 | mysql -uroot -p**  
这样数据库就可以完全的恢复到崩溃前的完全状态  
  
**基于时间点的恢复：**

**       ** 由于误操作，比如说删除了一张表，这时使用上面讲的完全恢复是没有用的，因为日志里面还存在误操作的语句，，我们需要的是恢复到误操作前的状态，然后跳过误操作的语句，再恢复后面操作的语句，假定我们删除了一张表的误操作发生在10:00这个时间点，我们可以使用下面的语句用备份和binlog将数据恢复到故障前

**基于位置恢复：**

**      ** 由于上面提到的，使用基于时间点的恢复可能出现，在一个时间点里面可能存在误操作和其他正确的操作，所以我们需要一种更为精确的恢复方式

**主从复制**  
       mysql的复制是指将主数据库的DDL和DML操作通过二进制日志传到从服务器上，然后在从服务器上对这些日志做重新执行的操作，从而使得从服务器和主服务器保持数据的同步