目录
binlog 和 redo log之间,如何保持数据一致性?
binlog(逻辑日志)
定义
binlog是MySQL 服务层 的二进制日志,记录了所有对数据库所做的修改操作,包括创建和删除表(DDL)以及插入、更新和删除数据(DML)的操作,INSERT、UPDATE、DELETE等。
binlog有三种记录格式:ROW模式、STATEMENT模式和MIXED模式。ROW模式记录每一行数据的修改情况,适用于数据恢复和复制;STATEMENT模式记录逻辑SQL语句,适用于数据恢复但可能导致主从数据不一致;MIXED模式是两者的混合使用,适用于大多数场景
作用
数据复制和同步:binlog主要用于主从复制(replication),使得从库可以通过重放binlog来跟上主库的变化。
数据恢复:在数据丢失时,通过binlog可以将数据库恢复到某个时间点。
特点
binlog以二进制格式记录,使得其体积较小,并且可以高效地重放。
binlog文件会根据配置进行轮转,生成多个日志文件,以便于管理和恢复。通常会在一定时间后被删除,具体时间依据数据库配置而定。
Redo Log(重做日志)
redo log是 InnoDB 存储引擎的日志文件,记录了事务对数据库做的修改。
当事务执行时,数据的修改会先写入 redo log,而不是直接写入磁盘,这样做的目的是为了保证服务崩溃重启后任然能保证数据的正常恢复和一致性,具体逻辑后面解释。
特点
循环写:InnoDB使用的是固定大小的redo log文件,它们组成一个循环日志(circular log)。当写满后,会回头覆盖最早的日志。
持久性保证:通过redo log机制,即使数据库出现崩溃,已提交的事务也能在重启时得到恢复。
效率提升:因为redo log是顺序写入的操作,相比随机写磁盘效率更高。
binlog 和 redo log之间,如何保持数据一致性?
如上图所示,两个服务器,不管先写哪个服务器,一旦发生崩溃重启服务后,两个服务器的数据都有可能不一致。
而二阶段提交(2PC)则是一种可以解决上述问题的的方案之一,原理大概如下图所示:
如上图所示,看红色文字1,2这2步,不管在那个步骤崩溃后重启,都能保证 binlog 和redo log 数据的一致性。