RedoLog和Binlog区别
1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎
都可以使用。
2. redo log 是逻辑物理日志，页面内的操作记录的是逻辑日志，页间的操作记录的是物理日志；binlog 是逻辑日志，相当于是Mysql server层的日志，适用于所有引擎，且可以通过参数控制写入。
3. redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指
binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
备注：
数据库的日志类型大概可以分为以下三种：
逻辑日志：记录的是sql语句的原始逻辑，面向对象是逻辑结构如表、列等
物理日志：记录的是文件记录的改变，面向对象是表空间、数据文件、数据页、偏移量等
逻辑物理日志：页面内的操作记录的是逻辑日志，页间的操作记录的是物理日志，physical to a page，logical within a page
一条更新语句的执行流程为：
数据页到内存中——>修改数据——>更新数据页——>写入redolog（状态为prepare）——>写binlog-->提交事务（redolog状态修改为commit）；
使用两阶段提交的优势就是如果数据库发生了意外情况，宕机、断点、重启等等，可以保证使用BinLog恢复数据和当时数据状态一致；
具体情况下的策略如下：
binlog有记录，redolog状态commit：正常完成的事务，不需要恢复
binlog有记录，redolog状态prepare：在binlog写完提交事务之前的crash，恢复操作：提交事务
binlog无记录，redolog状态prepare：在binlog写完之前的crash，恢复操作：回滚事务
binlog无记录，redolog无记录：在redolog写之前crash，恢复操作：回滚事务
小结：
redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。
