1. 参数文件

  MySQL实例启动时,数据库会先读取参数文件,用来寻找数据库的各种文件所在位置以及指定某些初始化参数。与Oracle数据库不同的是,如果没有配置参数文件,MySQL启动时,会加载默认值。

  静态参数是只读的,动态参数可以在MySQL实例运行中进行更改,其修改范围可以参考MySQL官方手册中 Dynamics System Variables相关内容。

  2. 日志文件

  2.1 错误日志(error log)

  该文件记录了所有的错误信息,也记录了一些警告信息和正确信息。可以通过命令 SHOW VARIABLES LIKE 'log_error' 来定位该文件

  2.2 慢查询日志(slow query log)

  可以在MySQL启动时设一个阈值(long_query_time = 10000ms),将运行时间超过该值的所有SQL语句都记录到慢查询日志中。如果运行的SQL语句没有使用索引(log_throttle_queries_not_using_indexes,每分钟未使用索引的SQL语句多少次后加入慢查询日志),也会被加入到慢查询日志中。

  2.3 二进制日志(binlog)

  二进制日志记录了对MySQL数据库执行更改的所有操作(不包括SELECT SHOW等操作)。主要有以下几种作用:

  • 恢复(recovery)  通过二进制日志进行point-in-time 的恢复 (第八章介绍)
  • 复制(replication)通过复制和执行二进制日志使一台远程的MySQL数据库(一般为slave)与一台MySQL数据库(master)进行实时同步。
  • 审计(audit)  用户可以通过二进制日志中的信息来进行审计,判断是否有对数据库进行注入的攻击。

  参数sync_binlog = [N]表示每写缓冲多少次就同步到磁盘(所有未提交的二进制日志会被记录到一个缓存中去,等事务提交时,直接将缓存中的二进制日志写入二进制日志文件)。若N为1,表示采用同步写磁盘的方式来写二进制日志(如果不是同步写的,数据库宕机时,可能最后一部分数据没有写入二进制日志文件中)。但是设为1,还是有一种情况导致问题发生。当使用InnoDB存储引擎时,在一个事务发出COMMIT动作之前,由于sync_binlog为1,因此将二进制日志立即写入磁盘中。如果这时写入了二进制日志,但是还未提交日志,发生了宕机。那么在MySQL数据库下次启动时,由于COMMIT操作并没有发生,这个事务应该被回滚掉。但是二进制日志已经记录了该事务信息,所以不能被回滚。通过设置参数innodb_support_xa为1来解决,该参数确保二进制日志和InnoDB存储引擎数据文件的同步。

  binlog_format 参数设置二进制文件的格式:

  • STATEMENT  二进制日志文件记录的是逻辑SQL语句
  • ROW   二进制日志文件记录的是表中行的更改情况(文件相应更大)
  • MIXED

  2.4 查询日志(log)

  记录了所有对MySQL数据库请求的信息,无论这些信息是否得到了正确的执行。

  3. InnoDB存储引擎文件

  3.1 表空间文件

  InnoDB将存储的数据按表空间(tablespace)进行存放。

  3.2 重做日志文件(redo log)

  每个InnoDB存储引擎至少有1个重做日志文件组,每个文件组下至少有两个重做日志文件,如默认的ib_logfile0和ib_logfile1。为了获得更高的可靠性,用户可以设置多个镜像日志组,将不同的文件组放在不同的磁盘上,以此提高重做日志的高可用性。在日志组中,每个重做日志文件的大小一致,并以循环写入的方式运行。从重做日志缓冲往磁盘写入时,是按512字节,也就是一个扇区的大小进行写入。因为扇区是写入的最小单位,所以重做日志的写入过程不需要doublewrite。

  重做日志和二进制日志的区别?

            第三章 文件(学习笔记)_mysql数据库

  由binlog 和redo log的区别可知:binlog日志只用于归档,只依靠 binlog 是没有crash-safe 能力的。但只有 redo log 也不行,因为 redo log 是 InnoDB特有的,且日志上的记录写入磁盘后会被覆盖掉。因此需要 binlog 和 redo log 二者同时记录,才能保证当数据库发生宕机重启时,数据不会丢失。