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

一.binlog的写入机制

   执行逻辑：

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

  binlog cache

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

事务提交时：

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

二.Redo log的写入机制

redo log的三种状态：

     

• 存在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）机制