MySQL 日志管理

一、 错误日志

  没做特殊说明，所有配置都在my.cnf文件下的 [mysqld] 域下
  包含了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。如果没有配置此选项，mysqld 使用错误日志名{host_name}.err并在数据目录写入日志文件。

log-error                      = /var/lib/mysql/mysql-error.log

二、二进制日志

  二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“ 事件” 的形式保存，它描述数据更改文件位置和格式。如果配置文件未配置long-bin的值， 默认名为{hostname}-bin.log。如果给出了文件名，但没有包含路径，则文件被写入数据目录。

server_id                       = 1 # server_id 唯一
log-bin                         = /var/lib/mysql/mysql-bin
expire-logs-days                = 14 # 日志过期时间

  二进制日志相关操作

RESET MASTER;//删除所有binlog日志，新日志编号从头开始

PURGE MASTER LOGS TO 'mysql-bin.010';//删除mysql-bin.010之前所有日志

PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26';// 删除2003-04-02 22:46:26之前产生的所有日志

  相关选项

binlog-do-db                    = db_name1 # 指定要保存二进制日志的数据库，要保存多个的话写多条
binlog-do-db                    = db_name2

sync-binlog                     = 1 # 每写多少次日志同步磁盘

expire-logs-days                = 14 # 二进制日志保留14天，过期自动删除

max_binlog_size                 = 100M # 每个二进制日志文件的大小

三、二进制日志记录模式

 1. ROW 模式

  日志文件会记录成每一行数据被修改的形式，然后在Slave端再对相同的数据进行修改。如果修改了表的结构，那么binlog日志记录的是重新创建表，在插入字段、update等操作语句，而不是的alter的动作。

  优点：日志文件可以不记录执行的Query语句的上下文相关信息，只要记录哪一行修改了，修改成什么样子。Row 模式会详细的记录下每一行数据的修改细节，而且不会出现某个特定情况下的存储过程，或函数，以及Trigger的调用和触发无法被正确复制问题。

  缺点：所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。

 2. Statment 模式

  每一条修改的SQL语句都会记录到Master的Binnary中。Slave端在复制的时候，SQL线程会解析成和原来Master端执行过相同的SQL语句，并再次执行。

  优点：不须要记录每一行的数据变化，减少了Binnary Log日志量，节约了IO成本，提高了性能。

  缺点：由于它是记录的执行语句，为了让这些语句在Slave端也能正确执行。那么它还必须记录每条语句在执行时的一些相关信息，即上下文信息，以保证所有语句在Slave端被执行的时候能够得到和在Master端执行时相同的结果。另外，由于MySQL发展比较快，很多新功能不断加入，使得MySQL复制遇到了不小的挑战，复制时设计的内容越复杂，越容易出bug。在Statement 模式下，目前已发现不少的情况下会造成MySQL的复制问题。主要是在修改数据使用了某些特定的函数货功能后，出现，比如：Sleep()函数在有些版本中就不能正确的复制，在存储过程中使用了last_insert_id()函数，可能会使Slave和Master的到不一致的ID，等等。

使用以下函数的语句也无法被复制：
　　* LOAD_FILE()
　　* UUID()
　　* USER()
　　* FOUND_ROWS()
　　* SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
　　同时在INSERT ...SELECT 会产生比 RBR 更多的行级锁

 3. mixed 模式（以上两种模式混合使用）

  一般的语句修改使用 Statment 格式保存 binlog，如一些函数，Statement 无法完成主从复制的操作，则采用 Row 格式保存 binlog，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 Statement 和 Row 之间选择一种.新版本的 MySQL 中队 Row 模式也被做了优化，并不是所有的修改都会以 Row 模式来记录，像遇到表结构变更的时候就会以 Statement 模式来记录。至于 Update 或者 Delete 等修改数据的语句，还是会记录所有行的变更。除了 MySQL 认为通过 Statement 方式可能造成复制过程中 Master 和 Slave 之间产生不一致数据。(如特殊 Procedure 和 Funtion 的使用，UUID() 函数的使用等特殊情况)时，它会选择 Row 的模式来记录变更之外，都会使用Statement方式。

binlog_format                    = MIXED 

四、慢查询日志

  记录包含所有执行时间超过long_query_time秒的SQL语句的日志文件。获得初使表锁定的时间不算作执行时间。

log-queries-not-using-indexes    = 1 # 把没有使用索引的查询语句也记录到慢查询日志中
slow-query-log                   = 1  # 记录慢查询日志
long_query_time                  = 2  # 设定慢查询时间（秒）
slow-query-log-file              = /var/lib/mysql/mysql-slow.log # 慢查询日志位置