mysql的系统日志

1.数据mysql的日志类型(前提：Innodb存储引擎)

MySQL中有七种日志文件，分别是：重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slow query log）、一般查询日志（general log），中继日志（relay log）。

---

• 重做日志（redo log） （确保事务的持久性）
  • 功能 [防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。]
  • 事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中
  • 当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）

---

• 回滚日志（undo log）
  • 功能[事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性]
  • 事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性
  • 当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。

---

• 二进制日志（binary log）
  • 用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步；用于数据库的基于时间点的还原；
  • 逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。但又不完全是sql语句这么简单，而是包括了执行的sql语句（增删改）反向的信息，也就意味着delete对应着delete本身和其反向的insert；update对应着update执行前后的版本的信息；insert对应着delete和insert本身的信息。 注意：binlog是二进制的，不能使用txt形式直接阅读，需要通过mysqlbinlog解析后才能打开阅读
  • 事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。
    这里与redo log很明显的差异就是binlog并不一定是在事务提交的时候刷新到磁盘，redo log是在事务开始之后就开始逐步写入磁盘。
    因此对于事务的提交，即便是较大的事务，提交（commit）都是很快的，但是在开启了bin_log的情况下，对于较大事务的提交，可能会变得比较慢一些。
    这是因为binlog是在事务提交的时候一次性写入的造成的，这些可以通过测试验证。
    清除机制：binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。

---

• 错误日志（errorlog）
  • 错误日志记录了MySQL Server每次启动和关闭的详细信息以及运行过程中所有较为严重的警告和错误信息

---

• 慢查询日志（slow query log）
  • 慢查询的sql的记录

---

• 一般查询日志（general log）
  • 通用查询日志能够存放到一个文本文件或者表中。全部连接和语句被记录到该日志文件或表，初始化时未开启该日志。

---

• 中继日志（relay log）
  • relay log很多方面都跟binary log差不多， 从服务器I/O线程将主服务器的二进制日志读取过来记录到从服务器本地文件，然后SQL线程会读取relay-log日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致

---

2.二进制日志（binary log）参数详解

log_bin = /var/lib/mysql/bin-log
开启 Binlog 并写明存放日志的位置；默认使用的设置是“log-bin=mysql-bin”，这样日志是存放在默认的位置上的，一般是放在data目录中。

log_bin_index = /var/lib/mysql/mysql-bin.index
指定索引文件的位置。

expire_logs_days = 7
删除超出这个变量保留期之前的全部日志被删除

server_id = 0002
指定一个集群内的 MySQL 服务器 ID，如果做数据库集群那么必须全局唯一，一般来说不推荐 指定 server_id 等于 1。

binlog_format = ROW
设置方面提到过的三种Bin-log日志模式。

max_binlog_size = 50M
binary log 最大的大小

binlog_cache_size = 1M
当前的多少事务cache在内存中

binlog_cache_disk_use
当前有多少事务暂存在磁盘上的，如果这个值有数值的话，就应该要注意调优了。

max_binlog_cache_size
最大能有多少事务cache在内存中

binlog_do_db和binlog_ingore_db
是一对控制对哪些数据库进行收集的选项。示例：

binlog_do_db=txp
binlog_do_db=txp_12

sync_binlog = 0
这个值控制cache的数据commit多少次才刷到磁盘上。默认是0，也就是让数据库自己决定同步的频率。如设置成1的话，则每commit一次就会将cache的数据同步到磁盘上，这样做最安全，但是性能最差。

3.Bin-log二进制日志三种模式的日志格式介绍及区别

• Statement Level模式

  • 每一条修改数据的sql都会记录到master的bin_log中，slave在复制的时候sql进程会解析成master端执行过的相同的sql在slave库上再次执行。
  • Statement level优点：1、解决了row level的缺点，不需要记录每一行的变化；2、日志量少，节约IO，从库应用日志块。Statement level缺点：一些新功能同步可能会有障碍,比如函数、触发器等。

• Row Level模式

  • 日志中会记录成每一行数据修改的形式，然后在slave端再对相同的数据进行修改。
  • 总结：
    row level的优点：
    1、记录详细；2、解决statement level模式无法解决的复制问题。row level的缺点：日志量大，因为是按行来拆分。

• Mixed模式（混合模式）:

  • 新版本中的mysql中对row level模式也做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更