mysql有很多日志文件，这些日志文件用于一些关键性的功能，例如主从同步的实现需要binglog和relaylog，redolog帮助mysql解决了大量IO问题以及事务未提交时候服务器异常导致数据丢失的问题，undolog用于事务回滚。学习mysql的重要机制的时候需要了解当中诸如日志文件等细节。
数据库log文件
bin log与relay log
bin log
记录数据库上所有变更，以二进制的形式保存在磁盘中。语句以“事件”的形式保存，它描述数据更改。主要用于查看数据库变更历史、数据库增量备份和恢复、数据库的主从同步。
每个事务提交之前，数据的变更会记录到bin log中（串行地写入），记录日志完成之后会通知存储引擎提交事务。
relay log
与bin log一样，是一系列包含数据库变更记录的文件，以及一个索引文件（记录当前使用的relay log 文件）。主库的bing log传到从库的relay log中，然后从库从relay log执行备份，实现主从同步。
主从同步
salve打开一个IO线程，IO线程在master打开一个普通连接，开始binlog dump process。
Binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。中继日志通常会位于OS的缓存中，所以中继日志的开销很小。
SQL线程从中继日志读取事件，更新slave的数据，使其与master中的数据一致。
Redo log
buffer pool
InnoDB有buffer pool（简称bp）。bp是数据库页面的缓存，对InnoDB的任何修改操作都会首先在bp的page上进行，然后这样的页面将被标记为dirty并被放到专门的flush list上，后续将由master thread或专门的刷脏线程阶段性的将这些页面写入磁盘（disk or ssd）。这样的好处是避免每次写操作都操作磁盘导致大量的随机IO，阶段性的刷脏可以将多次对页面的修改merge成一次IO操作，同时异步写入也降低了访问的时延。
Redo log作用
如果在dirty page还未刷入磁盘时，server非正常关闭，这些修改操作将会丢失，如果写入操作正在进行，甚至会由于损坏数据文件导致数据库不可用。为了避免上述问题的发生，Innodb将所有对页面的修改操作写入一个专门的文件，并在数据库启动时从此文件进行恢复操作，这个文件就是redo log file。
这样的技术推迟了bp页面的刷新，从而提升了数据库的吞吐，有效的降低了访问时延。带来的问题是额外的写redo log操作的开销，以及数据库启动时恢复操作所需的时间。
Redo log和Binlog的区别
- Redo log是在INNODB存储引擎层产生的，而Bin log则是在Mysql层产生的（Mysql下任何存储引擎都可以生成Bin log）。
- 两种日志的写入时间不一样。Redo log是在事务中（事务没提交）会不停写入，而Bin log则是在事务提交之后才被写入。
Undo Log
Undo log是一种日志，日志中记录对于数据库的反向操作。
由于事务的原子性，事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在执行的过程中发了错误，要回滚(Rollback)。回滚的时候就需要借助Undo log。
转载：