mysql 日志机制
1. redoLog（重做日志） 日志 （InnoDB 级别）
redoLog 主要的思想是MySQL 里经常说到的 WAL 技术，WAL 的全称是 Write-Ahead Logging
当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉
板）里面，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时
候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做，这就
像打烊以后掌柜做的事。
InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文
件的大小是 1GB，从头开始写，写到末尾就又回到开头循环写， 当write pos到 check point 时就开始刷盘，将check point 推前。有了redo Log 后 mysql 就具备了 crash-safe 能力，保证了数据库发生异常重启时之前提交的数据不会丢。 如下面这个图所示。
2. binlog（归档日志） 日志模块 （mysql server层 特有的日志）
最开始 MySQL 里并没有 InnoDB 引擎。MySQL 自带的引擎是 MyISAM，但是MyISAM 没有 crash-safe 的能力，binlog 日志只能用于归档。而 InnoDB 是另一个公司以插件形式引入 MySQL 的，既然只依靠 binlog 是没有 crash-safe 能力的，所以InnoDB 使用另外一套日志系统——也就是 redo log 来实现 crash-safe 能力。
3. redoLog 和 binlog 的不同
1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
2. redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。
3. redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
4. 两个日志的配合实现流程
1.当执行一个update 语句时 先会找到 引擎的 ID= 2 这行，ID 是主键，引擎直接用树搜索找到这一行。如果ID=2 这一行所在的数据页本来就在内存中，就直接返回执行器，否则 需要在磁盘中读入到内存中。然后再返回
2. 执行器拿到引擎给的行数据，再把这个值加一，比如原来是N，现在是N+1 得到一条新的数据调用引擎接口写入这行数据。
3. 引擎将这行数据更新到内存中。同时将这个操作记录到redokog 中，此时 redo log 处于 prepare 状态中，而后告知执行器执行完成了，随时可以提交事务
4.执行器生成操作的binlog ,并把binlog 写入到磁盘中
5. 执行器调用引擎的提交事务接口 ，引擎把刚写入的redo log 改写成commit 状态 更新完成
5. 两阶段提交
两阶段提交的目的让两个日志保持逻辑上的一致性，不是redo log 先完成还是 binlog先完成都会导致数据与源库数据不一致。redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。
redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成
1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1，
这样可以保证 MySQL 异常重启之后数据不丢失。
sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个
参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。