binlog
简介
binlog属于MySQL Server 层。不管用什么存储引擎，只要发生了表数据更新，都会产生 binlog 日志。
两个重要使用场景:
- 主从复制/数据备份：在主服务器开启binlog，Master将binlog传递给slaves(从服务器)来达到主从数据一致的目的。
- 数据恢复：数据库出错，通过使用mysqlbinlog工具来恢复数据
二进制日志包括两类文件：
- 二进制日志索引文件：（文件名后缀为.index）用于记录所有的二进制文件
- 二进制日志文件：（文件名后缀为.00000*）记录数据库中的所有DDL、DML语句
binlog的三种格式
binlog三种格式的实践操作
mysqlbinlog解析binlog
binlog写入机制
binlog日志刷盘流程
- 上图的 write，是指把日志写入到文件系统的 page cache，并没有把数据持久化到磁盘，所以速度比较快
- 上图的 fsync，将数据持久化到磁盘的操作
日志刷盘过程优化参数(sync_binlog)
write和fsync的时机，可以由参数sync_binlog控制，默认是1。
- 为0的时候，表示每次提交事务都只write，由系统自行判断什么时候执行fsync。性能得到提升，但是机器宕机，page cache里面的 binlog 会丢失。
- 设置为1，表示每次提交事务都会执行fsync。
- 设置为N(N>1)，表示每次提交事务都write，但累积N个事务后才fsync。出现IO瓶颈的场景里，将sync_binlog设置成一个比较大的值，可以提升性能。如果机器宕机，会丢失最近N个事务的binlog日志。
binlog可以保证crash-safe吗？
binlog不保证crash safe，因为crash之前，bin log可能没有写入完全MySQL就挂了。所以需要配合redo log才可以进行crash safe。
binlog-redolog-undolog-区别
| binlog | redolog | undolog | |
|---|---|---|---|
| 作用 | 用于主从复制和数据恢复，保证了MySQL集群架构的数据一致性 | 用于崩溃恢复，保证事务的持久性 | 用于事务回滚，保证事务的原子性和一致性 |
| 实现方式 | Server 层实现的，所有引擎都可以使用 | InnoDb存储引擎实现 | InnoDb存储引擎实现 |
| 记录方式 | 通过追加的方式记录，当文件尺寸大于配置值后，后续日志会记录到新的文件上 | 循环写的方式记录，写到结尾时，会回到开头循环写日志 | |
| 记录内容 | 事务的所有数据更改 | 事务执行前的内容 | |
| 写入时机 | 提交事务时才写入 | 事务执行过程中可以不断写入 | |
| 文件大小 | 通过配置参数max_binlog_size 设置每个binlog文件大小 | 文件大小是固定的 | |
| crash-safe能力 | 没有 | 具有 | |
| 日志类型 | 逻辑日志 记录的是这个语句的原始逻辑 | 物理日志 记录的是“在某个数据页上做了什么修改” |
崩溃恢复
崩溃恢复是指在数据库系统因为某种原因而发生崩溃或非正常关闭后，通过一系列机制和步骤来恢复数据库到一个一致性和可用的状态。崩溃恢复是数据库管理系统的重要功能，它确保数据库在出现异常情况后能够自动恢复，避免数据丢失或数据库状态不一致的问题。
执行器-InnoDB-执行update语句的流程
- 执行器在优化器选择了索引后，会调用InnoDB读接口，读取要更新的行到内存中
- 执行SQL操作后，更新到内存，然后写redo log，写bin log，此时即为完成。
- 后续InnoDB会在合适的时候把此次操作的结果写回到磁盘。