大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说redo log 与 binlog – G,希望您对编程的造诣更进一步.
redo log 与 binlog
redo log
-
redo log （重做日志）是处于
存储引擎层的，是InnoDB引擎特有的 -
redo log 存储的是物理日志 — 即，“在某个数据页上改动了什么”
-
redo log是循环写，空间是一定的，会用完。
-
MySQL使用WAL技术 — Write-Ahead-Logging，
具体到redo log就是：当有一条记录需要更新的时候，InnoDB引擎会先先把记录写在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阶段）
使用“两阶段提交”是为了避免恢复时恢复出来的数据库与原有状态不一致的现象。
避免MySQL crash时数据丢失的设置
我们知道发生crash时丢失的肯定都是内存中的数据，通过以下设置进行持久化
innodb_flush_log_at_trx_commit = 1— 每次事务的 redo log 直接持久化到磁盘sync_binlog = 1— 每次事务的binlog都持久化到磁盘
恢复与扩容
- 最近的全量备份+到相应时间点的归档日志（binlog）
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/7729.html
