1 Mysql中的日志文件
- redo log
重做日志 - undo log
回滚日志 - binlog
二进制日志 - slow query log
慢查询日志 - error log
错误日志 - general log
一般查询日志 - relay log
中继日志
1.1 redo log
1.1.1 用途
事物持久性
重做日志：保证事物的持久性 Consistence
节点故障时，可能有脏页未写入磁盘，mysql服务重启时，根据redo log重做，保证持久性
1.1.2 系统变量
innodb_log_buffer_size
innodb日志缓冲区大小
innodb_log_group_home_dir
日志文件组路径 默认./ 表示数据库data目录下
innodb_log_files_in_group
文件数量 默认2
物理文件位于数据库的data目录下的ib_logfile1&ib_logfile2
1.1.3 写盘
事物开始后，redo log就开始写入日志文件，而不是在事物提交时才开始，这也就很好地解释再大的事务提交（commit）也是很快的
InnoDB有buffer pool（简称bp）。bp是数据库页面的缓存，对InnoDB的任何修改操作都会首先在bp的page上进行，然后这样的页面将被标记为dirty并被放到专门的flush list上，后续将由master thread或专门的刷脏线程阶段性的将这些页面写入磁盘（disk or ssd）。这样的好处是避免每次写操作都操作磁盘导致大量的随机IO，阶段性的刷脏可以将多次对页面的修改merge成一次IO操作，同时异步写入也降低了访问的时延。然而，如果在dirty page还未刷入磁盘时，server非正常关闭，这些修改操作将会丢失，如果写入操作正在进行，甚至会由于损坏数据文件导致数据库不可用。为了避免上述问题的发生，Innodb将所有对页面的修改操作写入一个专门的文件，并在数据库启动时从此文件进行恢复操作，这个文件就是redo log file。这样的技术推迟了bp页面的刷新，从而提升了数据库的吞吐，有效的降低了访问时延。带来的问题是额外的写redo log操作的开销（顺序IO，当然很快），以及数据库启动时恢复操作所需的时间
1.2 undo log
1.2.1 用途
MVCC + 回滚
1.2.2 undo log 事务开始之前生成，也会产生 redo 来保证undo log的可靠性
MySQL5.6之前，undo log存储在共享表空间ibdata的回滚段中，MySQL5.7之后可以指定uodo表空间 innodb_undo_directory undo独立表空间的存放目录
1.2.3 逻辑日志
undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。
当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制的时候，也是通过undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。
undo log是采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个undo log segment。
另外，undo log也会产生redo log，因为undo log也要实现持久性保护。
1.3 binlog
1.3.1 用途
主从复制
数据库基于时间点还原
1.3.2 数据库层面的日志
和innodb无关
事物提交的时候产生，是逻辑日志
expire_logs_days 配置删除时间
log_bin_basename 配置binlog文件路径
参考资料
https://www.cnblogs.com/wy123/p/8365234.html
https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html#auto_id_13
https://blog.csdn.net/qq_36652619/article/details/89715191
