https://www.cnblogs.com/whgk/p/11066798.html

redolog记录内容

redolog记录的是页修改后的结果，write-ahead-log，替代脏页落盘（顺序IO替代随机IO）。实际是事务T改变了元素X，而X原来的值是v，这样一个T、X、v的三元组。

• type：redolog的类型，8.0有65种。
• spaceID： 表空间
• page number： 页号
• data：把页中哪个位置修改了哪些值。
  对于一个更新操作，

1. 如果这行数据的字符数发生了变化，就不能就地更新，而应该删除旧记录，插入修改后的纪录。
2. 数据页中的记录会按照索引顺序连成一个单向链表，在1产生的变化后，还要对上一条记录的next_record属性进行修改

恢复过程

1. 从checkpoint_lsn位置开始读取redolog，来回复脏页和undo log,

mysql是怎么保证数据不丢失的？

redolog和binlog保证持久化到磁盘，就能确保mysql异常重启后数据可以恢复。

binlog写入机制

事务执行过程中，先把日志写到binlog cache中，事务提交的时候再把binlog cache写入binlog文件中。
一个binlog的事务是不能拆开的，不管多大也要确保一次性写入。这就涉及binlog cache的保存。

binlog cache写入有两个过程：
1.write：多线程将binlog cache写入文件系统的page cache，但是并没有写入到磁盘，因此速度较快。
2.fsync：才是数据持久化过程。
write和fsync的时机是由参数sync_binlog控制
1.sync_binlog=0的时候，表示每次提交事务都只write，不fsync
2.sync_binlog=1时，表示每次提交都会fsync
3.sync_binlog=N(N>1)，表示每次提交都write，但是积累n个后才fsync
一般都设置为100-1000，提升性能。对应的风险是，如果主机发生异常重启，会丢失这N个事务的binlog日志。

redolog写入机制

事务执行过程中，先把redolog写入redolog buffer，再将buffer写入到文件系统的page cache，还有没有持久化，最后一步是持久化到磁盘。
为了控制redolog的写入策略，innoDB提供了innoDb_flash_log_at_trx_commit参数来控制，三种可能：
1.=0，每次提交只是把redolog留在buffer
2.=1，每次都持久化到磁盘，
3.=2，每次都写到page cache

innoDB后台线程，每隔1秒会把redolog buffer中的日志，调用write写到page cache，再调用fsync写入磁盘。

注意，事务在执行过程中，redolog也是直接写到redolog buffer中的，这些redo log会被线程写入到page cache。也就是说，一个没有提交的事务的redo log也是可能被持久化到磁盘的。
除了这种情况，还有两个场景会造成没提交的事务持久化到磁盘：
1.redo log buffer占用的空间即将达到innodb_log_buffer_size的一半时，后台线程会主动写盘。但是只写到page cache。
2.并行事务提交的时候，顺带将这个事务的redo log buffer 持久化到磁盘。

问题1：为什么bin log cache是每个线程自己维护，而redo log buffer是全局共享的？
这么设计的原因是：binlog 是不能被打断的，一个事务的binlog必须连续写。因此要整个事务完成后，再一起写到文件。
而redo log没有这个要求，有日志可以写到redo log buffer，还可以搭便车，由其他事务提交时一起写到文件。