[大数据]mysql的binlog，undo log，redo log

1. binlog 二进制日志

binlog用于mysql记录写入性操作信息，以二进制的形式保存到磁盘中。
binlog日志的使用场景主要有三个：
1. 主从复制：
在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
2. 数据恢复
通过使用mysqlbinlog工具来恢复数据。
3. 增量备份
MySQL->Elasticsearch需要有对应的同步程序(一般就是监听MySQL的binlog，解析binlog后导入到Elasticsearch) JAVA实现mysql的binlog监听

mysql操作binlog日志语句：
	 查看是否开启binlog日志：show variables like 'log_bin'
	 查看所有binlog的日志列表：show master logs
	 刷新binlog：flush logs
	 清空所有的binlog日志：reset master
	 查看第一个binlog日志：show binlog events
	 根据binlog日志名称查询：show binlog events in '[Log_name]'

2. undo log 回滚日志

数据库有四大特性：一致性、原子性、隔离性、持久性
其中，原子性是指一个事务里的对数据库一系列操作，要么全部成功，要么全部失败，不可能出现部分成功部分失败的情况。

而原子性就是依靠undo log来实现的，undo log记录了数据的逻辑变化。

比如一条插入(INSERT)操作，就会对应一条删除(DELETE)的undo log记录。对于每个修改(UPDATE)操作，就会对应一条相反的修改(UPDATE)的undo log记录。这样在发生异常时，就能依靠undo log来进行回滚。

在innodb中，每条数据都有两个隐藏字段，事务id(trx_id)和回滚指针(roll_pointer)。

• 每次修改某行记录时，都会把该事务的事务id赋值给trx_id隐藏列。
• 每次修改某行记录时，都会把undo日志地址赋值给roll_pointer隐藏列。

由于每次变动都会先把undo日志记录下来，并用回滚指针(roll_pointer)指向undo日志地址。因此可以认为，对该条记录的修改日志串联起来就形成了一个版本链，版本链的头节点就是当前记录最新的值。

3. redo log 前滚日志

redo log是InnoDB存储引擎独有的，它让MySQL拥有了崩溃恢复能力。

比如MySQL实例挂了或宕机了，重启时，InnoDB存储引擎会使用redo log恢复数据，保证数据的持久性与完整性。

redo log包含两个部分：一个是内存中的日志缓冲(redo log buffer)，另一个是磁盘上的日志文件(redo log file)。

由于每次写数据都会和磁盘发生一次IO操作，很影响性能，所以mysql每执行一条写操作语句，就会先将记录写入redo log buffer(日志缓冲区)，然后后续某个时间点再一次性将多个操作记录写到redo log file。
但是在操作系统中，是无法直接将用户的缓冲区的数据直接写入到磁盘中的，所以会经过内核的缓冲区(os buffer)，通过调用缓冲区的fsync()再将redo log buffer写入到redo log file中。

innode引擎记录一条数据一般是这样的流程：写操作 -->redo Log操作–>写入redo log buffer -->通过缓冲区，写入redo log file(记录到磁盘中)。

mysql支持三种将redo log buffer写入redo log file的时机，可以通过innodb_flush_log_at_trx_commit参数配置，各参数值含义如下：

• innodb_flush_log_at_trx_commit=0
  设置为0时是(大约)每秒刷新写入到磁盘中的，当系统崩溃，会丢失1秒钟的数据。
• innodb_flush_log_at_trx_commit=1(默认)
  每次提交事务，都会将redolog buffer里的写入到redolog file里，这种方式即使系统崩溃也不会丢失任何数据，但是因为每次提交都写入磁盘，IO的性能较差。
• innodb_flush_log_at_trx_commit=2
  事务每次提交，将数据写入到内核的缓冲区(os buffer)中，然后每秒调用缓冲区的fsync()再将redo log buffer写入到redo log file中。

redo log实际上记录数据页的变更，而这种变更记录是没必要全部保存，因此redo log实现上采用了大小固定，循环写入的方式，当写到结尾时，会回到开头循环写日志。

启动innodb的时候，不管上次是正常关闭还是异常关闭，总是会进行恢复操作。因为redo log记录的是数据页的物理变化，因此恢复的时候速度比逻辑日志(如binlog)要快很多。

前滚：事务提交之后，部分数据写入了磁盘，但是还有部分数据存在脏页上，并没有写入磁盘。此时设备宕机，没有写入磁盘的数据丢失。就要依赖redolog来恢复这部分数据。

回滚：事务还未提交，改动并没有完全生效，但是记录已经被修改。此时设备宕机，数据是有问题的，就要依赖undolog回滚改动。

二进制日志(binlog)是由数据库层面实现的，undo log和redo log是事务日志，undo log和redo log只存在于innodb中，myisam引擎是不存在undo log和redo log这两个日志文件的，所以myisam引擎是不支持事务的。