MySQL--update备份逻辑

相关词语：

　　redo log：日志模块（临时记录，类似于便签），InnoDB 引擎特有日志

　　WAL（Write-Ahead Logging）：写入方式

　　binlog：日志模块（归档日志），Server 层的日志

　　crash-safe：redo log带来的好处（MySQL 可以恢复到固定时间内任意一秒的状态）

 

WAL执行过程（redo log日志的存储方式）：

　

 

write pos 是当前记录的位置，checkpoint 是当前要擦除的位置，它们之间的是“便签”上还空着的部分。如果 write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。

redo log 与binlog的不同点：

　　redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。

　　redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。

　　redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

首先update语句会把查询语句的流程先走一遍，区别就在与涉及到的两个日志模块：

　　update T set c=c+1 where ID=2;

　　1.连接数据库（连接器工作）

　　2.清空查询缓存（查询缓存工作）--》更新语句会清空更新表的查询缓存

　　3.分析词法和语法（分析器工作）--》得到这是一条更新语句

　　4.优化器决定使用ID这个索引（优化器工作）--》决定执行方案

　　5.执行器开始执行（执行器工作）--》找到这一行，进行更新

　　更新过程中，执行器与引擎的交互：

　　　　

　　　　　　此处将redo log 的写入拆成了两个步骤：prepare 和 commit，这就是"两阶段提交"。

为什么需要“两阶段提交“呢？

是为了让两份日志之间的逻辑保持一致。

　　这里就可以说说crash-safe功能是怎么实行的了。

　　crash-safe（例如）：怎样让数据库恢复到半个月内任意一秒的状态？

　　binlog 会记录所有的逻辑操作，并且是采用“追加写”的形式。如果需要半个月内可以恢复，那么备份系统中一定会保存最近半个月的所有 binlog，同时系统会定期做整库备份。这里的“定期”取决于系统的重要性，可以是一天一备，也可以是一周一备。

 　　　　当需要恢复到指定的某一秒时，比如某天下午两点发现中午十二点有一次误删表，需要找回数据，那你可以这么做：

　　　　　　1.找到最近的一次全量备份

　　　　　　2.从这个备份恢复到临时库

　　　　　　3.从备份的时间点开始，将备份的 binlog 依次取出来，重放到中午误删表之前的那个时刻。

　　而redo log 和 binlog 是两个独立的逻辑，如果不用两阶段提交，要么就是先写完 redo log 再写 binlog，或者采用反过来的顺序。我们看看这两种方式会有什么问题。

　　　　①，先写 redo log 后写 binlog。

　　　　　　假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。

　　　　②，先写 binlog 后写 redo log。

　　　　　　如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。

　　简单说，redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

总结：

　　redo log 用于保证 crash-safe 能力。

　　nnodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。（可以保证 MySQL 异常重启之后数据不丢失）

　　sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。（可以保证 MySQL 异常重启之后 binlog 不丢失）

　　两阶段提交是跨系统维持数据逻辑一致性时常用的一个方案，即使你不做数据库内核开发，日常开发中也有可能会用到。　　　

【附加问题】

　　定期全量备份的周期“取决于系统重要性，有的是一天一备，有的是一周一备”。那么在什么场景下，一天一备会比一周一备更有优势呢？或者说，它影响了这个数据库系统的哪个指标？

【个人理解】

　　首先我理解的数据备份是为了恢复数据，假如需要恢复的是上周的数据，那么一周一备份就需要整周全备+需要恢复的数据时间点binlog来恢复，一天一备的话只需要当天的全备+这天某个时间段的binlog来恢复，那么一天已备份的优势就在于恢复丢失数据时的工作量。

　　其次就是数据丢失时的确认时间，天备只需要确认当天的binlog完好无损，而周备需要确认一整周的binlog完好。