2日志系统

Posted on Edited on
2日志系统

binlog、redolog

redo log

InnoDB引擎特有的物理日志，固定容量，环形结构，会覆盖，记录数据页改动
WAL（Write-Ahead Logging）更新内存，先写日志，再刷盘
先跟新内存，记录redolog，等到空闲再刷盘（更新磁盘redolog和数据页）
redo log 保证数据库异常重启，之前的记录不会丢失（crash-safe）
write pos记录当前写入位置，check point 记录将擦除位置（之后的数据还未刷盘）

redo log buffer：事务提交前redo log记录在内存，事务提交时记录到文件
刷盘时机：redo log空间不足；内存不足；空闲时间；mysql正常关闭；

用途：崩溃恢复

设置为多个文件的好处：并发处理，扩展不需要修改单个文件

binlog

server层逻辑日志，不覆盖，记录sql语句或某行的修改

两种日志模式

  • statement 记录sql语句
  • row 记录行内容（两条，更新前和更新后）

用途：数据复制（主从复制），数据恢复（恢复到某时间节点）

更新语句执行流程

  1. 执行器从引擎获取id=1的行，引擎根据索引找到数据所在数据页，加载到内存，返回给执行器
  2. 执行器执行++操作，调用引擎写入接口
  3. 引擎将数据跟新到内存（若内存没有该数据，记录到change buffer），记录更新操作到redo log，此时redo log处于prepare状态。返回执行器执行完成了，可随时提交事务
    • redo log写入
      innodb_flush_log_at_trx_commit：0 每次事务提交 redo log 写入buffer
      innodb_flush_log_at_trx_commit：1 每次事务提交 redo log 写入磁盘，prepare阶段就写入磁盘，commit不再fsync，只写入pagechache
      innodb_flush_log_at_trx_commit：2 每次事务提交 redo log 写入page cache
  4. 执行器生成binlog写入磁盘
    sync_binlog：0 Filesystem决定同步时机或cache满后写入磁盘
    sync_binlog：1 每次事务提交写（fsync）入磁盘
    sync_binlog：大于1 多次事务提交后写（fsync）入磁盘
  5. 执行器调用引擎事务提交接口
  6. 引擎把redo log状态改为commit，更新完成。
  7. 空闲后将redo log flush到磁盘（数据页更新）

总结

两阶段提交保证redo log / bin log 一致性

redo log、bin log如何关联

XID 崩溃恢复的时候，会按顺序扫描redo log：
如果碰到既有prepare、又有commit的redo log，就直接提交；
如果碰到只有parepare、而没有commit的redo log，就拿着XID去binlog找对应的事务。

问题

一天一备份和一周已备份的优势？影响数据库系统什么指标？
一天已备份恢复需要应用一天的binlog，一周已备份则需要应用一周的binlog
对恢复时间敏感的系统需缩短备份时间
频发的全量备份成本：占用存储空间