binlog数据库不写入binlog_mysql 为什么不能仅仅用 binlog 保证不丢数据

最新推荐文章于 2024-04-19 19:51:03 发布

The Operator

最新推荐文章于 2024-04-19 19:51:03 发布

阅读量147

点赞数

文章标签： binlog数据库不写入binlog

本文链接：https://blog.csdn.net/weixin_31691749/article/details/112808493

版权

本文探讨了MySQL中binlog的写入顺序对数据一致性的影响。先写redo log后写binlog，在进程异常重启时可能导致binlog丢失，从而在恢复时造成数据丢失。相反，先写binlog后写redo log，若发生crash，虽然事务无效，但在binlog恢复过程中可能出现额外事务，导致数据不一致。

摘要由CSDN通过智能技术生成

2018-11-26 12:39:36 +08:00 via Android

先写 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 来恢复的时候就多了一个事务出来，恢复出来的这先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。

但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。

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