0. MySql的3种日志
MySQL数据库为什么可以实现主从复制，持久化，回滚的呢？
其实关键在于MySQL里的三种log，分别是：
- binlog - redo log - undo log
1. 什么是binlog
binlog是用于记录数据库表结构和表数据变更的二进制日志
eg:
insert、update、delete、create、truncate等等操作。
不会记录select、show操作，因为没有对数据本身发生变更。
-----------------------------------------------------------------------------------
binlog会记录下每条变更的sql语句，还有执行开始时间，结束时间，事务id等等信息。
binlog是通过追加的方式进行写入的，可以通过max_binlog_size参数设置每个binlog文件的大小，
当文件大小达到给定值之后，会生成新的文件来保存日志。
2. binlog详细介绍
- 查看binlog是否打开
使用命令show variables like ‘%log_bin%‘
- 开启binlog
找到my.cnf配置文件，增加下面配置(mysql版本5.7.31):
# 打开binlog log-bin=mysql-bin # 选择ROW(行)模式 binlog-format=ROW
修改后，重启mysql，配置生效。
执行SHOW MASTER STATUS;可以查看当前写入的binlog文件名。
- binlog使用场景
主从复制和数据恢复。
1. 主从复制: 在Master端开启binlog, 从机订阅binlog日志的信息。 然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。 ----------------------------------------------------------------------------------- 2. 数据恢复: 通过使用mysqlbinlog工具来恢复数据。 指定--start-position和--stop-position，或者指定--start-datetime和--stop-datetime，那么就可以恢复指定区间的数据。
binlog主从复制(见下图)
- binlog刷盘时机
对于InnoDB存储引擎而言，只有在事务提交时才会记录biglog，此时记录还在内存中。 mysql通过sync_binlog参数控制biglog的刷盘时机， 取值范围是0-N： 0：不去强制要求，由系统自行判断何时写入磁盘； 1：每次commit的时候都要将binlog写入磁盘； N：每N个事务，才会将binlog写入磁盘。 从上面可以看出，sync_binlog最安全的是设置是1，这也是MySQL 5.7.7之后版本的默认值。 但是设置一个大一些的值可以提升数据库性能， 因此实际情况下也可以将值适当调大，牺牲一定的一致性来获取更好的性能。
- binlog日志格式
binlog日志有三种格式，分别为STATMENT、ROW和MIXED。
在 MySQL 5.7.7之前，默认的格式是STATEMENT， MySQL 5.7.7之后，默认值是ROW。 ----------------------------------------------------------------------------------- 日志格式通过binlog-format指定。 STATMENT 基于SQL语句的复制(statement-based replication, SBR)。 每一条会修改数据的sql语句会记录到binlog中。 优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO, 从而提高了性能； 缺点：在某些情况下会导致主从数据不一致，比如执行sysdate()、slepp()等。 ----------------------------------------------------------------------------------- ROW 基于行的复制(row-based replication, RBR)。 不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了。 优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题； 缺点：会产生大量的日志，尤其是alter table的时候会让日志暴涨 ----------------------------------------------------------------------------------- MIXED 基于STATMENT和ROW两种模式的混合复制(mixed-based replication, MBR)。 一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog。
3. redo log
为什么需要redo log?
事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了， 不可能因为任何原因再回到原来的状态。 那么mysql是如何保证一致性的呢？最简单的做法是在每次事务提交的时候， 将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题， 主要体现在两个方面： 1. 因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节， 这个时候将完整的数据页刷到磁盘的话，太浪费资源了！ 2. 一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差！ 因此mysql设计了redo log， 具体来说就是只记录事务对数据页做了哪些修改， 这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。
redo log结构(见下图)
redo log与binlog区别
4. undo log
undo log的作用主要用于回滚，mysql数据库的事务的原子性就是通过undo log实现的。
我们都知道原子性是指对数据库的一系列操作，要么全部成功，要么全部失败。
undo log主要存储的是数据的逻辑变化日志，比如说我们要insert一条数据，
那么undo log就会生成一条对应的delete日志。
简单点说，undo log记录的是数据修改之前的数据，因为需要支持回滚。
那么当需要回滚时，只需要利用undo log的日志就可以恢复到修改前的数据。
undo log另一个作用是实现多版本控制(MVCC)，undo记录中包含了记录更改前的镜像，
如果更改数据的事务未提交，对于隔离级别大于等于read commit的事务而言，
不应该返回更改后数据，而应该返回老版本的数据。
MySQL三种日志之binlog/redo log/undo log
原文：https://www.cnblogs.com/davidgu/p/14678555.html