一.binlog的写入机制

   执行逻辑：

  • 事务执行过程中，先把日志写到binlog cache，
  • 事务提交的时候再把binlog cache写到binlog文件中

  binlog cache

  • 系统binlog cache分配了一片内存，每个线程一个
  • 参数binlog_cache_size用于控制单个线程内binlog cache所占内存的大小
  • 如果超过了这个参数规定的大小，就要暂存到磁盘

事务提交时：

  • 执行器把binlog cache里的完整事务写入binlog中，并清空binlog cache

二.Redo log的写入机制

redo log的三种状态：

     

Mysql 45讲学习笔记（二十三）MYSQL怎么保证数据不丢_java

  • 存在redo log buffer中，物理上是在MySQL进程内存中
  • 写在磁盘（write），但没有持久化（fsync），物理上是在文件系统的page cache里面
  • 持久化到磁盘，对应的是hard disk

存在问题：

     日志写到redo log buffer 是很快的，write到page cache也差不多，但是持久化到磁盘的速度很慢

   innodb_flush_log_at_trx_commit 参数

0

表示每次提交事务都把redo log留在redo log buffer中

1

表示每次事务提交时都将redo log 直接持久化到磁盘

2

表示每次事务提交时都只把redo log写到page cache

  • InnoDB有一个后台 线程，每隔1秒，就会把redo log buffer中的日志，调用write写到文件系统的page cache，然后调fsync 持久化到磁盘
  • 事务执行中间过程的redo log也是直接写在redo log buffer中的
  • 也可能被后台线程一起持久化到磁盘中。
  • 一个没有提交的事务的redo log可能已经持久化到磁盘。

三.没提交的redo log写入磁盘的两个场景：

  1. redo log buffer占用的空间即将达到innodb_log_buffer_size一半的时候，后台线程会主动写盘
  2. 并行事务提交的时候，顺带将这个事务的redo log buffer 持久化到磁盘

两阶段提交：

redo log先prepare再写binlog最后再把redo log commit

组提交（group commit）机制