redo log 与 binlog

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 的写入分为两个步骤 --- perparecommit阶段 --- ”两阶段提交“

 

有了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)

 

你可能感兴趣的:(redo log 与 binlog)