崩溃恢复与组提交

Ⅰ、binlog与redo的一致性(原子)

由内部分布式事务保证

咱们先来了解下,当一个commit敲下后,内部会发生什么？

步骤	操做
step1	InnoDB作prepare redo log(fsync)
step2	Sever层写binlog(fsync)
step3	InnoDB层commit redo log(fsync)

第一步写的redo file,写入的是trxid而不是page的变化(show binlog events in 'xxx'),准确的说写在undo页上

第三步写的也是redo file

以上说的写入指的的成功落盘

这里的原理是一个内部的分布式事务,相关参数：innodb_support_xa=on

tips：

5.6默认开启分布式事务(binlog和redo log同步),5.7你设置off也没用,保证强一致性

Ⅱ、crash分析

服务crash,一个事务可能面对的状态以下：

• 1成功,2失败,那3确定失败,重启则rollback(利用undo,一个事务的undo在active list(活跃事务列表)中就表示没提交,redo完后从active list中找没提交的事务去回滚)
• 1成功,2成功,3失败,重启则commit
• 1,2,3都成功,重启commit(将这个事务对应的undo从active list中移走,移到history list中,不能直接清理,其余事务可能还须要引用,mvcc机制要看,真正清理是后台purge thread作)

tips：

①不谈高可用的状况下,若是两个日志都写成功,其实commit和rollback都没有问题,用户并不知道他commit会不会成功,他只知道数据库断了,这种事务叫partial transaction,可提交可不提交

②mysql这里作commit是为了复制数据同步

③写重作日志oracle一次fsync,mysql要三次？

第一步或者第二步失败,天然没有第三次,前两步成功的话,其实第三步不用写到磁盘持久化,只要写到操做系统缓存就能够,不论是否有没有commit的日志,都会提交,因此实际上是两次,可是有组提交加持,可能2次fsync提交了10个事务都有可能

Ⅲ、怎么个恢复法子？

3.1 面对crash部分怎么处理？

在innodb层,prepare redo log中会记录一个trxid,宕机从新起来恢复时

• step1

  先scan binlog,把全部的trxid拿出来作一个hash table(扫最后一个binlog文件,一个事务的日志是不能跨文件的)

• step2

  去scan innodb redo log,扫cp开始日后的部分,也会产生trxid list

• step3

  这时候去上面那个hash table中search,若是这个trxid在上面的hash表中,就是两个步骤都没问题,就commit,若是不在里面(第二步写binlog没成功)就rollback

tips：

上面说的已是在数据库层面了,也就是说用户commit以后数据库里面作的东西,用户是不能够rollback的,也就是说应用层表现为失败,并不表明是真正的失败

以上讨论是crash临界点地方处理

3.2 整个恢复过程是怎样的呢？

先回顾一下lsn

LSN
    log sequenct number
    重作日志写入的字节量
LSN存在于：
    page
    redo log block
    checkpoint

看图说恢复

• 先scan redo log,从cp开始扫描,扫到最后一个日志块
• 接着就redo,将全部的page重作(看page中的lsn来判断到底要不要重作,若是page lsn已经比redo log lsn来的大,就说明先刷了,不用重作了)
• 最后接到前面的扫两个hash table,将没有提交的事务用undo进行rollback

Ⅳ、组提交

背景：commit的本质就是每次提交后执行下面的操做

由innodb_flush_log_at_trx_commit参数决定

• 1 fsync 写盘
• 2 fwrite 写缓存

hdd盘的iops是100,那一秒钟只能执行100次fsync,增删改的qps的最大就是100(每作一个增删改就提交一次)

因此咱们常常批量导入数据

批量导数据,begin;插10条;commit  这样就只fsync了一次,这样qps就提高了10倍

就这样组提交诞生来了——一次fsync刷新一组事务(多线程)

性能提升10~100+倍,innodb存储引擎原生支持,事务响应不会变慢的,不用担忧

看两个相关参数(5.7才有)

binlog_group_commit_sync_delay 组提交必定要等待多少微秒,时间越长一次性提交的事务越多,fsync次数越少,性能越好
binlog_group_commit_sync_no_delay_count 累积到多少个才组提交

千万不要调,你是调很差的呢,好比你调成5个事务,那你业务没五个线程,那你就被hang住了,数据库自身已经作的很好了

5.5有个bug,开启binlog,组提交就会失效,设置双1的话,性能会不好,那时候为了缓解这个问题把innodb_flush_log_at_trx_commit设置为2,crash可能最后一段事务丢失

tips：

• 5.6和5.5一块儿跑纯更新操做的sysbench测试,前者性能会比后者好8到10倍
• 5.6中设置为2,性能基本上没什么差异,在3%到5%之间
• 因此说5.6以前的版本就不要用了,就这么一个缘由就够了

• 另一个提高性能的参数
  sync_binlog参数 5.7默认为1,以前默认为0

  0表示事务提交后,binlog写到操做系统缓存,操做系统控制怎么写到文件
    1表示事务提交时binlog写到磁盘
    100表示100次事务提交刷一次磁盘

  5.5中设置为0是有提高,5.6以后就不会有这个问题了,并且0可能会有丢数据的风险

到这里传说中的innodb事务系统中的双1到这里就解释清楚了,到如今为止咱们就不用把这两个值设为其余值了

附：官网的一句话：分布式事务就要用serializable,这时候串行才有意义,想不通

Ⅴ、补充redo和binlog区别

• binlog是server层的逻辑日志
• redo是innodb层的物理逻辑日志
• 二者写入的时间点不同,binlog只有在事务提交时写入,redo会在好几种状况下写入,以前分析过

binlog 直接按事务提交顺序

redo log 按带星号的顺序提交,只要page发生修改就会记录到日志中,因此T2修改的日志能够和T1是对同一个page修改

虽然都是T1 T2 T3,可是binlog记录的是数据库的操做,相似sql语句的

redo log记录的是对page的修改,一个事务能够对多个page进行修改,事务是并行在运行的,因此能够有多个事务对多个不一样的page在修改,因此提交顺序比较特殊

redo log里面一个事务的日志能够有不少,但binlog只有一个

redo log在事务提交过程当中就开始写,binlog在事务提交最后才开始写

千万记住redo log里面没记录sql的

协助理解：

一个update操做,提交后写了一个binlog,可是可能update修改了不少page进而产生了不少redo log,而后根据事务提交顺序来写盘,好比T1事务先操做了page A没提交,T2事务跟着对page A作了修改提交了,这时候就会写redo,此时T1事务还没提交呢

tips：

• oracle中没有binlog,无论事务大小,提交的时间都是平均的,由于在事务执行的过程当中日志就在刷盘了
• 在mysql中因为binlog是事务提交后才开始写,因此大事务提交时间很长,小事务提交时间比较短
• 大事务提交会影响到后面事务提交,会排队,不过排队是好事,后面排一块儿组提交