后端一个疑问
全部评论

也可以做,但是binlog保存的是全量的数据。他不知道哪些页属于脏页(写入物理页但没写回磁盘),使用binlog恢复我的理解是需要使用所有binlog数据恢复。而redolog记录了哪些页为脏页。重做的时候只需要重做这些数据就行。效率会高很多

binlog是记录的是sql级别的日志,redolog是物理级别的日志,重做肯定是redolog快
binlog是一条一条的增删改的记录,redolog记录的是物理页面的修改。如果使用binlog的话,需要一条一条执行sql,redolog的话基于物理页要快一些。你也可以拓展一下,就好像redis中两个持久化机制,一个rdb一个aof,rdb一般记录的是全量的物理数据,aof记录的一条一条的增删改,redis里面使用rdb恢复或者是备份也是很快的。
一般都是redolog搭配binlog进行恢复的 属于二阶段提交 分成Prepare 阶段,首先数据修改写入缓冲区,生成 redo log 并刷盘,状态标记为 prepare,此时 bin log 还没写入,事务未提交。Commit 阶段:将事务的 SQL 操作写入 bin log 并刷盘。将 redo log 状态更新为 commit,标志事务提交完成 所以在恢复的时候 ,会按顺序扫描 redo log 并检查 binlog如果检查redo log 状态为 commit 就直接不用管binlog了因为事务肯定是提交了直接重做数据业 如果 redo log 状态为 prepare,那么就要再去检查binlog 如果binlog 完整,那么就提交事务,重做数据 如果binlog不完整 就回滚事务
binlog不能给脏页刷盘
binlog并不是一个原子的操作,一条binlog可能对应多条redo log,如果只使用binlog,那么需要先落盘binlog,再落盘数据,如果此时数据只落盘了一部分就挂了,恢复时无法通过binlog进行重做。
但是主从不也是用的binlog吗
用binlog也行,满足两个前提,1,MySQL一开始使用的时候就开启binlog,且中途无异常,2,先把数据库中的数据清空
个人理解,binlog慢
redo log:解决事务持久性 & crash recovery(快,物理级别)。
binlog:用于主从复制、备份恢复(逻辑级别,跨存储引擎)。
再了解一下两阶段提交你就懂了
相关推荐

点赞 评论 收藏
分享