技术日志挑战——第17天：0809

技术总结：

今天是周五，天气是在太热了，就没有去上班，在家办公了一天，不过好像也没做什么工作方面的事情。明天打算去公司一趟，把进度补一补。

学习笔记：

**bin log用于备份恢复、主从复制；

redo log用于掉电等故障恢复。**

(1) 如果不小心整个数据库的数据被删除了，能使用redo log文件恢复数据吗？

不可以使用redo log文件恢复，只能使用binlog文件恢复。

因为redo log文件是循环写，是会边写边擦除日志的，只记录未被刷入磁盘的数据的物理日志，已经刷入磁盘的数据都会从redo log文件里擦除。

binlog文件保存的是全量的日志，也就是保存了所有数据变更的情况，理论上只要记录在binlog上的数据，都可以恢复，所以如果不小心整个数据库的数据被删除了，得用binlog文件恢复数据。

(2) MySQL在完成一条更新操作后，Server.层会生成一条binlog,Bin Log也是采用WL模式，先写日志，再写磁盘。

事务执行过程中，先把日志写到binlog cache,事务提交的时候，再把binlogcache写到binlog文件中。

因为一个事务的binlog?不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一块内存作为binlog cache。

至于什么时候刷新到磁盘，可以sync_binlog配置参数指定。

• 0(延迟写)每次提交事务都不会刷盘，由系统自己决定什么时候刷盘，可能会丢失数据。
• 1(实时写)每次提交事务，都会刷盘，性能较差。
• N(延迟写)提交N个事务后，才会刷盘。

加入写Bin Log.之后的事务流程，先写处于prepare状态的Redo Log,事务提交后，再写处于commit状态的Redo Log,这就是二阶段提交的概念。