mysql 更新 log bin_MySQL 更新语句执行过程 WAL redolog binlog

MySQL 更新语句执行过程 WAL redolog binlog

WAL

全称Write-Ahead Logging --- 先写日志再写磁盘

当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log 里，并更新内存，这个时候更新就算完成了。并在适当的时候将该操作记录更新到磁盘中。

redo log

redo log (重做日志)是处于存储引擎层的，是InnoDB引擎特有的

redo log 存储的是物理日志 --- 即，“在某个数据页上改动了什么”

redo log是循环写，空间是一定的，会用完。

InnoDB 引擎的 redo log 的空间是有限的，一组4个文件，每个文件1GB，总共4GB。当这块“临时记录板”写满后再次从开头的地方循环写入。

redo log 的写入分为两个步骤 --- perpare 和 commit阶段 --- ”两阶段提交“

有了redo log，就可以保证即使数据库发生异常重启也不会丢失记录，称为 crash-safe

binlog

binlog (归档日志) 处于server层，是Mysql自带的日志模块

binlog 是存储的是逻辑日志 --- 即，“记录原始语句”。因此可用来恢复数据库 --- 相当于在某个时间的基础上重新运行了一遍相关语句。

binlog 是可追加写入的 --- binlog文件写到 一定大小后就会在下一个文件中继续写，而不覆盖之前的文件。

两种日志的使用流程

(执行器)读取表中需要update的那一行

(InnoDB)查询该行信息是否在内存中。若没有则从磁盘读取到内存。然后都返回行数据

(执行器)更改行数据、写入新行

(InnoDB)新行更新到内存，写入redo log (此时处于prepare阶段)

(执行器)写入binlog

(InnoDB)提交事务 (此时处于commit阶段)

使用“两阶段提交”是为了避免恢复时恢复出来的数据库与原有状态不一致的现象。

小结一下就是会有一下几种情况：

prepare阶段crash：数据库恢复后因为内存中的redolog丢失且未写入binlog，因此事务rollback(就是说该事务的DML会失效)

binlog阶段crash：crash时日志还没写入磁盘，启动时此事务会rollback

commit阶段，未commit成功就crash：此时虽然未完成两段式提交中的commit，但是mysql数据库恢复的时候会读出binlog的xid(prepare阶段生成xid)，然后告诉InnoDB提交xid的事务，InnoDB提交完之后会回滚其他事务，使得redolog和binlog保持一致。(也就是说有xid的事务就可以恢复)

避免MySQL crash时数据丢失的设置

我们知道发生crash时丢失的肯定都是内存中的数据，通过以下设置进行持久化

redo log 用于保证 crash-safe 能力，将innodb_flush_log_at_trx_commit = 1 --- 每次事务的 redo log 直接持久化到磁盘

sync_binlog = 1 --- 每次事务的binlog都持久化到磁盘

恢复与扩容

最近的全量备份+到相应时间点的归档日志(binlog)