We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
更新语句的执行流程和查询语句的执行流程类似,区别在于更新语句会使查询语句的查询缓存失效,同时还会涉及到两个日志模块:redo log (重做日志)和 bin log (归档日志)
当有一条记录需要更新时,InnoDB 引擎就会先把记录写到 redo log 中,并更新内存,此时更新算是完成了,之后,InnoDB 引擎会在适当的时候将记录写入磁盘中。
这里涉及到 WAL 技术(Write-Ahead Logging),先写日志,再写磁盘
redo log 的大小是固定的,比如可以配置为一组 4 个文件,每个文件的大小是 1 GB,那么 redo log 可以记录 4 GB 的操作。从头开始写,写到末尾就又回到开头循环写,如下图:
write pos 是当前记录位置,一边写一边后移;checkpoint 是当前要擦除的位置,也是往后推移并循环的,擦除记录前要把记录更新到数据文件;write pos 和 checkpoint 之间的部分用来记录新的操作。如果 write pos 追上了 checkpoint 就需要停下先擦除一些记录,把 checkpoint 推进下
redo log 可以让 InnoDB 保证即使数据库发生异常重启,之前提交的记录也不会丢失,这个能力称为 crash-safe
bin log 是 MySQL 的 Server 层维护的一种二进制日志,主要是用来记录对mysql数据更新或潜在发生更新的SQL语句,并以"事务"的形式保存在磁盘中
update T set c=c+1 where ID=2;
两阶段提交主要是为了保证 redo log 和 binlog 保持一致
假设当前 ID=2 的行,字段 c 为 0,语句写完第一个日志后,第二个日志还没写完期间发生了 crash:
redo log 和 binlog 都可以用于表示事务的提交状态,而两阶段提交就是让这两个状态保持逻辑上的一致
当需要恢复到指定的某一秒时,比如某天下午两点发现中午十二点有一次误删表,需要找回数据,那你可以这么做:
The text was updated successfully, but these errors were encountered:
redo log是顺序写,并且可以组提交,还有别的一些优化,收益最大是这两个因素
Sorry, something went wrong.
逻辑日志可以给别的数据库,别的引擎使用,已经大家都讲得通这个“逻辑”; 物理日志就只有“我”自己能用,别人没有共享我的“物理格式”
redo log 记录数据页做了什么改动 binlog 的 statement 格式记录 sql 语句,row 格式记录行的内容,记录更新前和更新后两条信息
git-zjx
No branches or pull requests
更新语句的执行流程
更新语句的执行流程和查询语句的执行流程类似,区别在于更新语句会使查询语句的查询缓存失效,同时还会涉及到两个日志模块:redo log (重做日志)和 bin log (归档日志)
redo log(重做日志)
当有一条记录需要更新时,InnoDB 引擎就会先把记录写到 redo log 中,并更新内存,此时更新算是完成了,之后,InnoDB 引擎会在适当的时候将记录写入磁盘中。
这里涉及到 WAL 技术(Write-Ahead Logging),先写日志,再写磁盘
redo log 的大小是固定的,比如可以配置为一组 4 个文件,每个文件的大小是 1 GB,那么 redo log 可以记录 4 GB 的操作。从头开始写,写到末尾就又回到开头循环写,如下图:
write pos 是当前记录位置,一边写一边后移;checkpoint 是当前要擦除的位置,也是往后推移并循环的,擦除记录前要把记录更新到数据文件;write pos 和 checkpoint 之间的部分用来记录新的操作。如果 write pos 追上了 checkpoint 就需要停下先擦除一些记录,把 checkpoint 推进下
redo log 可以让 InnoDB 保证即使数据库发生异常重启,之前提交的记录也不会丢失,这个能力称为 crash-safe
bin log(归档日志)
bin log 是 MySQL 的 Server 层维护的一种二进制日志,主要是用来记录对mysql数据更新或潜在发生更新的SQL语句,并以"事务"的形式保存在磁盘中
redo log 和 binlog 的区别
update 语句执行流程
两阶段提交
两阶段提交主要是为了保证 redo log 和 binlog 保持一致
假设当前 ID=2 的行,字段 c 为 0,语句写完第一个日志后,第二个日志还没写完期间发生了 crash:
由于 redo log 写完之后,系统即使 crash,仍可以恢复数据,这时 c=1。但由于 binlog 没有写完,之后需要使用这个 binlog 恢复临时库时,恢复出来的 c=0,与原库不同
由于 redo log 还没写完,系统恢复后 c=0,但 binlog 里已经记录了,之后用 binlog 恢复时,恢复出来的 c=1,与原库不同
redo log 和 binlog 都可以用于表示事务的提交状态,而两阶段提交就是让这两个状态保持逻辑上的一致
数据恢复
当需要恢复到指定的某一秒时,比如某天下午两点发现中午十二点有一次误删表,需要找回数据,那你可以这么做:
The text was updated successfully, but these errors were encountered: