redo log重做日志文件，用于记录事务操作的变化，记录的是
数据修改之后的值，不管事务是否提交都会记录下来。实例和介质失败，可以用redo恢复。
从Innodb引擎中整体来看，Redo的位置是图中黑色圈起来部分
1. DML操作导致的页面变化，均需要记录Redo日志（物理日志）
2. 在页面修改完成之后，在脏页刷出磁盘之前，写入Redo日志;
3. 日志先行（WAL），日志一定比数据页先写回磁盘;
4. 聚簇索引/二级索引/Undo页面修改，均需要记录Redo日志;
为了管理脏页，在 Buffer Pool 的每个instance上都维持了一个flush list，flush list 上的 page 按照修改这些 page 的LSN号进行排序。因
此定期做redo checkpoint点时，选择的 LSN 总是所有 bp instance 的 flush list 上最老的那个page（拥有最小的LSN）。由于采用WAL的
策略，每次事务提交时需要持久化 redo log 才能保证事务不丢。而延迟刷脏页则起到了合并多次修改的效果，避免频繁写数据文件造成的性能
问题
Redo原理：
当提交一个事务的时候，比如insert操作
ACID原则，提交之后，不管发生什么，数据不能丢，也不能直接落盘脏块，如何处理呢？就用redo日志来记录。直接持久化redo
写满日志文件会产生切换操作，并执行checkpoint，触发脏页的刷新。
参数介绍
innodb_log_files_in_group
innodb每个redo log file的成员数量,默认2
innodb_log_file_size
日志文件的小大 默认值:5242880 (5M)，太小了，一般设置为buffer pool的十分之一大小
innodb_log_buffer_size
log bffer的大小，就是日志缓冲的大小，重做日志缓冲，一般情况下8MB足够使用，如果不够放心，可以使用16MB
innodb日志文件大小
-rw-r-----. 1 mysql mysql 268435456 Mar 7 20:09 ib_logfile0
-rw-r-----. 1 mysql mysql 268435456 Jul 12 2018 ib_logfile1
innodb_lock_wait_timeout
事务等待获取资源等待的最长时间，超过这个时间还未分配到资源则会返回应用失败
innodb_flush_log_at_trx_commit
这个参数有三个值可以设置（从内存载入到磁盘）
redo log buffer刷新到磁盘的条件
0 ：redo log thread 每隔1秒将redo log buffer写入redo log 文件，同时进行刷盘操作，保证数据确实已经写入磁盘（数据库），这种情况下，log buffer仅仅在master thread的每秒循环中执行
--数据库性能最好，但是数据库如果宕机，就会丢失1S的数据
1 ：每次事务提交都会进行log buffer的写入log file（数据库），并且flush到磁盘中（系统）
--数据库的安全性最好，但是性能最差，如果数据库宕机，不会丢数据
2 ：每次事务提交都会将log buffer的数据写入到log file（数据库），但是flush操作是每秒进行一次（系统）
--如果是数据库宕机，服务器没有事情，这时候，不会丢书数据
如果服务器本身宕机，此时丢失一秒数据
当设置为0的时候，速度最快，但是不安全。mysqld进程崩溃后,导致上一秒的数据全部丢失。
当设置为1的时候，会造成一个事务的丢失。
当设置为2的时候，速度较快，数据库崩溃会造成某个事务丢失，但是不会丢失一秒的数据，只有当服务器宕机或者断电才会造成1s的数据丢失。
该参数的设置，要结合业务进行分析，如果是对于数据要求较大的OLTP系统，应该采用1.如果是OLAP系统，该类系统大多数存储各类日志，
数据库的日志插入压力如果比较大的话，可以考虑改成0或者2
这个参数配合sync_binlog（使binlog在每N次binlog写入后与硬盘同步），共同组成了innodb的日志刷盘策略和数据安全性。相当重要
当两个参数都为1的时候，速度最慢，但是数据最安全。
