MySQL这种关系型数据库，讲究日志先行策略，就是一条DML语句进入数据库之后，先写日志，再写数据文件 # redo log redo log 又称重做日志文件，用来记录事务操作的变化，记录数据修改之后的值，不管事务是否被提交，都会被记录下来 在实例和介质失败时，如数据库掉电，这时候InnoDB存储引擎会使用重做日志，恢复到掉电前的时刻 默认情况至少有两个redo log文件，在磁盘用ib_logfile（0-N）来命名 redo log 写的方式是顺序写、循环写 顺序写、循环写是什么意思呢？ - 也就是说，第一个文件写满之后，写第二个文件，这样依次写到最后一个文件，直至最后一个文件写满之后，又重新写第一个文件，就这样循环 - 写满日志文件会产生切换操作，并执行checkpoint，触发脏页的刷新 - 数据库重启过程中，如果参数文件中的redo log值大小和当前redo log值大小不一致，那就删除当前redo log文件，按照参数文件中的redo log值大小，生成新的redo log文件在生成redo log之前，数据写在redo log buffer中  redo log buffer 刷新到磁盘的条件： 1. 通过innodb_flush_log_at_trx_commit 参数来控制 - 0：redo log thread 每隔 1s 会将 redo log buffer 中的数据写入 redo log 中，同时进行刷盘操作 每次事务提交并不会触发 redo log thread 将日志缓冲中的数据写入 redo log 中去 - 1：每次事务提交时，都会触发redo log thread 将日志缓冲中的数据写入redo log，并flush到磁盘 - 2：每次事务提交时，把redo log buffer的数据写入redo log中，不刷到磁盘 这三种模式：0 的性能最好，但不安全，有丢失 1s 的数据的风险。1 的安全性最高，不会丢失任何已经提交的事务，但就是数据库的性能最慢。2 介于两者之间 2. master thread ：每秒进行刷新 3. redo log buffer：使用超过一半的时候就触发刷新 # binlog MySQL的二进制文件，用于备份恢复和主从复制 从 binlog cache 刷新到磁盘 binlog 文件中所需条件： - sync_binlog=0 时，当事务提交后，MySQL 不做 fsync 之类的磁盘同步指令、将binlog_cache 中的信息刷新到磁盘，而是让 Filesystem 自行决定什么时候来做同步，或 cache 满了之后，才同步到磁盘 - sync_binlog=n 时，每进行 n 次事务提交后，MySQL 进行一次 fsync 之类的磁盘同步指令、将 binlog_cache 中的信息刷新到磁盘 sync_binlog 设置为 1，更安全 sync_binlog设置为 0，性能最好 # redo log 和 binlog 的区别 redo log 和 binlog都记录了数据真实修改的语句，那他们为何要并存呢？ 1. 记录内容不同 binlog 是逻辑日志，记录所有数据的改变信息 redo log 是物理日志，记录所有 InnoDB 表数据的变化 2. 记录内容的时间不同 binlog 记录 commit 完毕之后的 DML 和 DDL SQL 语句 redo log 记录事务发起之后的 DML 和 DDL SQL 语句 3. 文件使用方式不同 binlog 不是循环使用，在写满或者实例重启之后，会生成新的 binlog 文件 redo log 是循环使用，最后一个文件写满之后，会重新写第一个文件 4. 作用不同 binlog 可以作为恢复数据使用，主从复制搭建 redo log 作为异常宕机或者介质故障后的数据恢复使用 # 脏页刷新条件 1. 重做日志ib_logfile文件写满之后，在切换的过程中会执行checkpoint，会触发脏页的刷新 2. innodb_max_dirty_pages_pct参数控制,其含义是在 buffer pool 中 dirty page 所占百分比，达到设置的值，会触发脏页的刷新 3. innodb_adaptive_flushing 参数控制，其影响每秒刷新脏页的数目，默认开启 ### 组提交 看看如何保证 binlog 写入顺序和存储引擎提交顺序是一致的，并且能够进行 binlog 的组提交？5.6 引入了组提交，并将提交过程分成 Flush stage、Sync stage、Commit stage 三个阶段。 这样，事务提交时分为了如下的阶段： 1. InnoDB——Prepare SQL 已经成功执行并生成了相应的 redo 和 undo 内存日志； 2. Binlog——Flush Stage 所有已经注册线程都将写入 binlog 缓存； 3. Binlog——Sync Stage binlog 缓存将 sync 到磁盘，sync_binlog=1 时该队列中所有事务的 binlog 将写入磁盘； 4. InnoDB——Commit stage leader 根据顺序调用存储引擎提交事务； 每个 Stage 阶段都有各自的队列，从而使每个会话的事务进行排队，提高并发性能。 如果当一个线程注册到一个空队列时，该线程就做为该队列的 leader，后注册到该队列的线程均为 follower，后续的操作，都由 leader 控制队列中 follower 行为。 leader 同时会带领当前队列的所有 follower 到下一个 stage 去执行，当遇到下一个 stage 为非空队列时，leader 会变成 follower 注册到此队列中；注意：follower 线程绝不可能变成 leader 。 - binlog_group_commit_sync_delay 参数，表示延迟多少微秒后才调用 fsync; - binlog_group_commit_sync_no_delay_count 参数，表示累积多少次以后才调用 fsync。 这两个参数是用于故意拉长 binlog 从 write 到 fsync 的时间，以此减少 binlog 的写盘次数。在 MySQL 5.7 的并行复制策略里，它们可以用来制造更多的“同时处于 prepare 阶段的事务”。这样就增加了备库复制的并行度 也就是说，这两个参数，既可以“故意”让主库提交得慢些，又可以让备库执行得快些。在 MySQL 5.7 处理备库延迟的时候，可以考虑调整这两个参数值，来达到提升备库复制并发度的目的。 ### undo log 在 InnoDB 存储引擎层面主要分为两种日志，一种是 redo log 一种是 undo log。InnoDB 支持事物、支持 MVCC 多版本并发控制。InnoDB 的多版本是通过undo 和回滚段来实现的。InnoDB 是索引组织表，每行记录都包含DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR 和 DELETE_BIT 几个隐藏字段。 - DB_TRX_ID：用来标识最近一次对本行记录做修改的事务的标识符，即最后一次修改本行记录的事务id。delete 操作在内部来看是一次 update 操作，更新行中的删除标识位 DELELE_BIT。 - DB_ROLL_PTR：指向当前数据的 undo log 记录，回滚数据通过这个指针来寻找记录被更新之前的内容信息。DB_ROW_ID：包含一个随着新行插入而单调递增的行 ID, 当由 innodb 自动产生聚集索引时，聚集索引会包括这个行 ID 的值，否则这个行 ID 不会出现在任何索引中。DELELE_BIT：用于标识该记录是否被删除。 对记录做变更操作时不仅会产生 redo log，也会产生 undo log 记录(insert、update、delete)。但undo只记录变更之前的旧数据，undo 记录默认被记录到系统表空间（ibdata1）中，但是从 MySQL5.6 起，就可以使用独立的 undo 表空间了。采用独立 undo 表空间，再也不用担心 undo 会把 ibdata1 文件弄大；也给我们部署不同 I/O 类型的文件位置带来便利，对于并发写入型负载，我们可以把 undo 文件部署到单独的高速存储设备上。 redo log，又称重做日志，用于记录事物操作变化，记录的是事物被修改后的值，不管事物是否提交都会记录下来，在实例和介质失败时，如数据库掉电，就可以利用 redo log 恢复到掉电前的时刻，以此来保证数据的完整性。 undo log，对记录的变更操作时不仅会产生 redo 记录，也会产生 undo 记录（insert、update、delete）。但 undo 只记录变更前的旧数据。通常可以使用undo 日志来实现回滚操作，保证事务的一致性。