MySQL日志详解(未完待续)

向右看齐 2023-06-26 10:56 38阅读 0赞

## 前言 ##

MySQL日志记录了MySQL数据库日常操作和错误信息。MySQL有不同类型的日志文件（各自存储了不同类型的日志），从日志当中可以查询到MySQL数据库的运行情况、用户的操作、错误的信息等。

> MySQL的日志分为以下四大类：
> 
>  *  错误日志：记录mysql服务的启动，运行或停止mysql服务时出现的问题；
>  *  查询日志：记录建立的客户端的连接和执行的语句；
>  *  二进制日志：记录所有更改数据的语句，可以用于数据的复制；
>  *  慢查询日志：记录所有执行的时间超过long\_query\_time的所有查询或不使用索引的查询。

默认情况下，所有日志创建于MySQL数据目录中，通过刷新日志，可以强制MySQL关闭和重新打开日志文件，Flush logs刷新日志或者执行mysqladmin flush-logs 如果正使用MySQL复制功能，在复制服务器上可以维护更多日志文件，这种日志我们称为接替日志。启动日志功能会降低MySQL数据库的性能。

#### 1）查看系统设置 ####

mysql> show global variables\G
    mysql> show global variables like '%log%';
    
    mysql> show session variables\G
    mysql> show session variables like '%log%';

若要修改上面查看出来的参数，可以在MySQL的主配置文件中的mysqld字段中写入即可，如：binlog\_cache\_size = 1M。又或者可以在MySQL数据库中进行临时修改：set global binlog\_cache\_size = 1048576，这种临时修改在MySQL重启后就会失效。

#### 2）查看运行状态 ####

mysql> show global status\G
    
    mysql> show session status;
    
    [root@mysql ~]# mysql -V
    mysql> status;
    mysql> select version();

### 1、错误日志 ###

在mysql数据库中，错误日志功能是默认开启的。默认情况下，错误日志存储在mysql数据库的数据目录中。错误日志文件通常的名称为hostname.err。其中，hostname表示服务器主机名。 错误日志信息可以自己进行配置的，错误日志所记录的信息是可以通过log-error和log-warnings来定义的，其中log-error是定义是否启用错误日志的功能和错误日志的存储位置，log-warnings是定义是否将警告信息也定义至错误日志中。默认情况下错误日志大概记录以下几个方面的信息：服务器启动和关闭过程中的信息（未必是错误信息，如mysql如何启动InnoDB的表空间文件的、如何初始化自己的存储引擎的等等）、服务器运行过程中的错误信息、事件调度器运行一个事件时产生的信息、在从服务器上启动服务器进程时产生的信息，MySQL有很多系统变量可以设置，系统变量设置不同，会导致系统运行状态的不同。因此mysql提供两组命令，分别查看系统设置和运行状态。

一般而言，日志级别的定义没有会话变量都只是在全局级别下定义错误日志的状态：

其中 log\_error定义为错误日志文件路径 ，log\_error\_verbosity值得含义如下:

<table> 
 <thead> 
  <tr> 
   <th>Verbosity</th> 
   <th>Message</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>Error only</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>Error and warnings</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>Errors, warnings,and notes(default)</td> 
  </tr> 
 </tbody> 
</table>

错误日志的存放路径在my.cnf的主配置文件中指定，如下：

![MySQL日志详解(未完待续)][MySQL]

为了方便维护需要，有时候会希望将错误日志中的内容做备份并重新开始记录，这时候就可以利用MySQL 的FLUSH LOGS 命令来告诉MySQL 备份旧日志文件并生成新的日志文件。备份文件名以“.old”结尾。

**删除错误日志**  
在mysql5.5.7之前：数据库管理员可以删除很长时间之前的错误日志，以保证mysql服务器上的硬盘空间。mysql数据库中，可以使用mysqladmin命令开启新的错误日志。mysqladmin命令的语法如下：mysqladmin –u root –p flush-logs也可以登录mysql数据库中使用FLUSH LOGS语句来开启新的错误日志。 在mysql5.5.7之后：服务器将关闭此项功能。只能使用重命名原来的错误日志文件，手动冲洗日志创建一个新的，方式如下：

[root@mysql ~]# cd /usr/local/mysql/data/
    [root@mysql data]# mv mysqld.err{,.old}
    [root@mysql data]# mysqladmin -uroot -p flush-logs
    Enter password:

### 2、二进制日志 ###

二进制日志主要记录MySQL数据库的变化，二进制日志以一种有效的格式，并且是事务安全的方式包含更新日志中可用的信息。二进制日志包含了所有更新了数据或者已经潜在更新了数据。还包含关于每个更新数据库的语句的执行时间，它不包含没有修改任何数据的语句。使用二进制日志的主要目的是最大可能地恢复数据库。

#### 1）启动二进制日志（默认情况下二进制日志是关闭的） ####

[root@mysql data]# vim /etc/my.cnf      #编辑主配置文件
    
    [mysqld]
    basedir=/usr/local/mysql
    datadir=/usr/local/mysql/data
    port=3306
    server_id=1
    socket=/usr/local/mysql/mysql.sock
    log-error=/usr/local/mysql/data/mysqld.err
    log-bin=/usr/local/mysql/data/binary_log      #指定二进制日志的路径及名称
    expire_logs_days=10         #清除日志的天数
    max_binlog_size=100M      #单个日志文件的大小限制，超出会新建一个日志文件
    [root@mysql data]# systemctl restart mysqld      #重启MySQL使配置生效
    [root@mysql data]# ll | grep binary         #会在指定的路径下生成以下两个文件
    -rw-r----- 1 mysql mysql      154 12月 30 20:59 binary_log.000001
    -rw-r----- 1 mysql mysql       40 12月 30 20:59 binary_log.index

登录到数据库中也可以查看到，如下：

![MySQL日志详解(未完待续)][MySQL 1]

#### 2）查看二进制日志 ####

MySQL二进制日志存储了所有的变更信息，MySQL二进制日志经常使用。当MySQL创建二进制日志文件时，首先创建一个以’filename’为名称，以’.index’为后缀的文件；在创建一个以’filename’为名称，以’.000001’为后缀的文件。当MySQL服务重启一次，以’.000001’为后缀的文件会增加一个，并且后缀名加1  
递增。如果日志长度超过max\_binlog\_size的上限，也会创建一个新的日志。 Show binary logs;可以查看当前的二进制日志文件个数及其文件名。二进制日志并不能直接查看，如果想要查看日志内容，

**可以通过mysqlbinlog命令查看：**

也可以退出MySQL在命令行使用mysqlbinlog命令查看：

[root@mysql data]# mysqlbinlog binary_log.000001

#### 3）删除二进制日志 ####

MySQL的二进制文件可以配置自动删除，同时MySQL提供了手动删除二进制文件的方法：  
RESET MASTER：删除所有的二进制日志文件；  
PURGE MASTER LOGS：只删除部分二进制日志文件；  
Reset master：删除所有二进制日志 ；  
Purge master logs to ‘二进制名’ ：删除单个二进制日志之前的。

mysql> purge master logs to "binary_log.000003";   
    mysql> purge master logs before '20180101';

#### 4）通过二进制日志还原MySQL数据 ####

关于通过二进制日志还原的具体过程，还是参考我之前的博文吧！如下：  
[MySQL的备份与恢复详解][MySQL 2]

### 3、事务日志 ###

事务日志（InnoDB特有的日志，因为只有Innodb支持事务）可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢的刷回到磁盘。目前大多数的存储引擎都是这样实现的。 如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具有的恢复方式则视存储引擎而定。

#### 1）查看事务日志的定义 ####

mysql> show global variables like 'innodb_lo%';

**在上述指令输出的部分内容解释如下：**

| innodb\_flush\_log\_at\_trx\_commit | 1 \#在事务提交时innodb是否同步日志从缓冲区到文件  
中，当这个值为1（默认值）之时，在每个事务提交时，日志缓冲被写到日志文件，对日志文件做到磁盘操作的刷新，性能会很差造成大量的磁盘I/O但这种方式最安全；如果设为2,每次提交事务都会写日志，但并不会执行刷的操作。每秒定时会刷到日志文件。要注意的是，并不能保证100%每秒一定都会刷到磁盘，这要取决于进程的调度。每次事务提交的时候将数据写入事务日志，而这里的写入仅是调用了文件系统的写入操作，而文件系统是有缓存的，所以这个写入并不能保证数据已经写入到物理磁盘。设置为0，日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事务提交不做任何操作。  
**注：刷写的概念**  
刷写其实是两个操作，刷（flush）和写（write），区分这两个概念是很重要的。在大多数的操作系统中，把Innodb的log buffer（内存）写入日志（调用系统调用write），只是简单的把数据移到操作系统缓存中，操作系统缓存同样指的是内存。并没有实际的持久化数据。

<table> 
 <thead> 
  <tr> 
   <th>所以，通常设为0和2的时候，在崩溃或断电的时候会丢失最后一秒的数据，因为这个时候数据只是存在于操作系统缓存。之所以说“通常”，可能会有丢失不只1秒的数据的情况，比如说执行flush操作的时候阻塞了。<br><strong>总结</strong><br><strong>设为1当然是最安全的，但性能页是最差的（相对其他两个参数而言，但不是不能接受）。如果对数据一致性和完整性要求不高，完全可以设为2,如果只最求性能，例如高并发写的日志服务器，设为0来获得更高性能。</strong><br></th> 
   <th><br></th> 
   <th>innodb_locks_unsafe_for_binlog</th> 
   <th>OFF</th> 
   <th><br></th> 
   <th>innodb_log_buffer_size</th> 
   <th>16777216</th> 
   <th><br></th> 
   <th>innodb_log_checksums</th> 
   <th>ON</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>innodb_log_compressed_pages</td> 
   <td>ON</td> 
  </tr> 
  <tr> 
   <td>innodb_log_file_size</td> 
   <td>50331648 #日志文件大小</td> 
  </tr> 
  <tr> 
   <td>innodb_log_files_in_group</td> 
   <td>2 # DB中设置几组事务日志，默认是2</td> 
  </tr> 
  <tr> 
   <td>innodb_log_group_home_dir</td> 
   <td>./ #定义innodb事务日志组的位置,此位置设置默认为MySQL的datadir 。</td> 
  </tr> 
 </tbody> 
</table>

每个事务日志都是大小为50兆的文件（不同版本的mysql有差异）： 在mysql中默认以ib\_logfile0,ib\_logfile1名称存在。

[MySQL]: https://s1.51cto.com/images/blog/201912/30/495c1f7bceb85b368f56ce44236205cd.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[MySQL 1]: https://s1.51cto.com/images/blog/201912/30/98f2741fa343b00ccac044661860df74.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[MySQL 2]: https://blog.51cto.com/14154700/2395340