redolog vs binlog

然后我们扩展一下，因为日志主要是记录的修改日志，分别加深分析一下：

redolog

redolog是innodb存储引擎特有的物理日志，记录的是数据页做了什么改动。

它的存储空间是固定的，类似一个圆环。日志空间写完，需要把相关的操作执行，数据刷到磁盘上释放空间。

redolog可以有效保证mysql的crash-safe; 即mysql系统故障重启，也可以从redolog中恢复；

一般把innodb_flush_log_at_trx_commit=1,即设置redolog每次事务提交日志落盘，可以更有效的保证crash-safe

是一种mysql-server层的逻辑修改日志，有两种格式：

1，statement格式，记录的是sql;

2, row格式，记录了两行，更新前和更新后的结果；

为了保证系统可以从奔溃状态恢复，设置参数 sync_binlog=1,即事务提交，binlog落盘；

如何快速恢复mysql:

1,找到最近的备份，恢复到临时库；

2，找到备份的binlog,重放到你需要的时刻。

比如有一张表：

user(id int primarykey auto_increment , age int default 0 )engin=innodb ;

执行一条sql语句：

update user set age=age+1 where id=2 ;

那么，这条update语句是如何经过mysql的体系结构和日志文件呢？

1，执行器首先通过存储引擎读接口得到这行数据；（如果内存有则返回，不存在从硬盘中取出放入内存再返回）

2，执行器把这行数据的age+1,然后调用存储引擎的写接口，写入数据到内存；

3，存储引擎把更新操作写入redolog，日志状态为prepare ，告诉执行器事务完成更新操作；

4, 执行器把这个操作写入binlog，日志落盘；

5，执行器提交事务，调用存储日志写到redolog，日志状态为commit,

binlog,redolog都可以表示事务的状态；

两阶段提交：保证了binlog,redolog在系统奔溃重启之后的事务状态的一致；

本篇分析了redolog和binlog的区别。

然后分别介绍了binlog,redolog所处的mysql的体系结构位置，实际运维过程中的配置参数。

最后追踪了一条update语句的执行历程，以及两种日志的写入过程，然后点明两阶段提交是为了保证两种日志的事务一致性。

原创不易，转载请注明出处。