InnoDB 存储引擎（7）——日志文件

1. 错误日志

• 错误日志文件对mysql 的启动、运行、关闭过程进行了记录
• 不仅记录了所有错误信息，也记录了一些警告信息或正确的信息
• 如果MySQL 数据库不能正常启动时，第一个必须查找的文件就是该文件

2. 慢查询日志

• 记录执行超过设定阈值的SQL 语句
• 能够定位存在问题的SQL 语句，从而进行SQL 语句层面的优化

3. 查询日志

• 记录所有对MySQL 数据库请求的信息（无论是否得到了正确的执行）

4. 二进制日志（binary log，BIN LOG）

• 记录对MySQL 数据库执行更改的所有操作，但是不包括SELECT 和 SHOW 这类操作
• binlog 还包括了执行数据库更改操作的时间等其他额外信息
• binlog 主要作用
  • 恢复：某些数据的恢复需要二进制日志，如：在一个数据库全备文件恢复后，用户可以通过二进制日志进行point-in-time 的恢复
  • 复制：使一台远程的MySQL数据库（一般称为slave）与一台MySQL数据库（一般称为master）进行实时同步。
  • 审计：通过二进制日志中的信息来进行审计，判断是否有对数据库进行注入攻击
• binlog 文件的大小
  • 通过参数max_binlog_size 指定，如果超过该值，则产生新的二进制日志文件，后缀名+1，并记录到.index文件中
• binlog_format参数
  • STATEMENT：表示binlog 记录的是日志的逻辑SQL 语句
  • ROW：表示binlog 记录的是表的行更改情况（比STATEMENT更耗空间）
  • MIXED：MySQL 默认采用STATEMENT格式进行binlog文件的记录，但是在以下的情况会使用ROW格式
    • 使用了UUID() 、USER()、CURRENT_USER()、FOUND_ROWS()、ROW_COUNT()等不确定函数
    • 使用了INSERT DELAY语句
    • 使用了用户定义函数（UDF）
    • 使用了临时表
• binlog 的写入
  • 当使用事务时，在事务commit 之前，会将所有未提交的binlog 数据记录到一个缓存中
  • 当commit 时，直接将缓存中的binlog 数据写入binlog 文件中（这一步对细节没有展开）
  • 该缓存的大小由参数binlog_cache_size 决定，默认为32K。该参数是基于会话的，当开启事务时，会自动分配大小为binlog_cache_size 的缓存
• binlog 写入时的问题（需要补个图来帮助理解）
  • 在未commit 时，发生宕机，此时binlog的缓存中还存在一部分binlog 数据未写入binlog 文件中，这会给恢复和复制带来问题
  • 可以使用sync_binlog=1 来解决这个问题，即不使用binlog 缓存。但是一般都设置为0，除非是进行复制，且想要得到最大的高可用性，才会建议设置为1。
  • 该值设置为1，又会带来另一个问题
    • 在一个事务发出commit 动作之前，由于sync_binlog=1，因此会将二进制日志立即写入磁盘，如果这时已经写入了binlog文件，但是提交还没有发生，并且此时发生宕机，那么在MySQL 下次启动时，由于commit 操作并没有发生，这个事务会被回滚，但是二进制日志以及记录了该事务信息，不能被回滚。
    • 这个问题可以通过将参数innodb_support_xa=1来解决，虽然innodb_support_xa与XA事务有关，但它同时也确保了二进制日志和InnoDB 存储引擎数据文件的同步

redo log 文件