详细介绍Mysql中的4种日志

我这里是配置了日志输出文件：/tmp/mysql_query.log，并且日志功能关闭

mysql> set global general_log = on;
Query OK, 0 rows affected (0.01 sec)

mysql> set global general_log = off;
Query OK, 0 rows affected (0.01 sec)

chown mysql:mysql /tmp/mysql_query.log

三、Binary Log

二进制日志，包含一些事件，这些事件描述了数据库的改动，如建表、数据改动等，主要用于备份恢复、回滚操作等

1. 作用：

• 包含了所有更新了数据或者已经潜在更新了数据(比如没有匹配任何行的一个DELETE)

• 包含关于每个更新数据库(DML)的语句的执行时间信息

• 不包含没有修改任何数据的语句，如果需要启用该选项，需要开启通用日志功能

• 主要目的是尽可能的将数据库恢复到数据库故障点，因为二进制日志包含备份后进行的所有更新

• 用于在主复制服务器上记录所有将发送给从服务器的语句

• 启用该选项数据库性能降低1%，但保障数据库完整性，对于重要数据库值得以性能换完整

2. 格式

Binlog有3种格式

• STATMENT：每一条会修改数据的sql都会记录到master的binlog中，slave在复制的时候sql进程会解析成和原来master端执行多相同的sql再执行。
  有点：在statement模式下首先就是解决了row模式的缺点，不需要记录每一行数据的变化减少了binlog日志量，节省了I/O以及存储资源，提高性能。因为他只需要激励在master上所执行的语句的细节一届执行语句时候的上下的信息。
  缺点：在statement模式下，由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master端执行时候相同的结果。另外就是，由于mysql现在发展比较快，很多的新功能不断的加入，使mysql的复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在statement中，目前已经发现不少情况会造成Mysql的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比如：sleep()函数在有些版本中就不能被正确复制，在存储过程中使用了last_insert_id()函数，可能会使slave和master上得到不一致的id等等。

• ROW：日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改，只记录要修改的数据，只有value，不会有sql多表关联的情况。
  优点：在row模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了，所以row的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程和function，以及trigger的调用和出发无法被正确复制问题。
  缺点：在row模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。

• MIXED：MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种

3. 配置

• 查看mysql中二进制文件的配置情况：show variables like "%log_bin%";

  mysql> show variables like "%log_bin%";
  +---------------------------------+-------+
  

关键词：详细介绍Mysql中的4种日志