http://dwchaoyue.blog.51cto.com/2826417/1784509
mysql如何保证redolog和binlog的一致性,安全性,效率。
和数据安转相关的参数
sync_binlog:控制binlog的刷新方式(写入到磁盘)
innodb_flush_log_at_trx_commit:在innodb下控制着redo的写入方式
innodb_support_xa:外部事务,用来保证binlog和redo一致性的,俗称两段式提交
binlog_order_commits:按照binlog的写入顺序提交事务,保证redo和binlog的已执行
binlog_max_flush_queue_time: leader线程搜集binlog的超时时间
2pc提交(官方支持)
(redo日志在prepare阶段就已经sync),绝大部分都比较支持这种说法
http://dev.mysql.com/doc/refman/5.6/en/binary-log.html
http://blog.itpub.net/15480802/viewspace-1411356
http://www.linuxidc.com/Linux/2015-11/124942.htm
http://www.2cto.com/database/201306/221413.html
2pc流程:(sync_binlog = 1,innodb_flush_log_at_trx_commit = 1 )
1.prepare阶段:sync redo 日志(未sync的redo存放于innodb_log_buffer_size中),系统自动完成
获取prepare_commit_mutex(一个全局锁,一次只能被一个事务获取)
2.生成binlog,将binlog写入文件系统(未提交之前binlog存放在binlog_cache_size中),sync binlog,这一步受sync_binlog控制
3.提交commit 将commit标志sync ,释放prepare_commit_mutex(这一步应该受innodb_flush_log_at_trx_commit的控制)
违背了这个参数的定义:innodb_flush_log_at_trx_commit
观点二:redo日志在最后的commit的时候才sync
http://blog.itpub.net/28218939/viewspace-1975809
2pc流程:(官方没有明显的支持这种说法)
1.prepare阶段:获取prepare_commit_mutex
2.生成binlog,将binlog写入文件系统(未提交之前binlog存放在binlog_cache_size中),sync binlog
3.提交commit 将redo log sync ,释放prepare_commit_mutex
这种方式会造成binlog的日志记录多余redo日志记录,在恢复的时候是如何恢复? 难道是以binlog为准,
不管这个事务的redo有没有提交 ,只要写binlog就认为该事务以提交(现阶段还没有找到有关该说法).
innodb数据恢复流程
1.查找未提交的redo日志(找xid)
2.用xid去binlog查找对应的日志记录
3.如果有就认为这个事务是提交的,并补充commit。如果没有就认为是没有提交的,在恢复的时候就rollback事务
###################################################################################################
以上2pc日志写入方式是在 mysql5.6之前的方式,当sync_binlog=1的时候 系统的性能非常糟糕。
从5.6 之后就开始采用BLGC方式写2pc日志,来提升性能
BLGC具体流程如下：(每一个阶段只有一个活跃的线程)
flush stage:已完成perpare阶段的线程队列
sync stage:flush队列超时(binlog_max_flush_queue_time)或者没有线程产生binlog了 ,flush队列开始sync队列,将binlog写入磁盘(合并io)
commit stage:队列进入提交阶段(这里只做提交操作,redo日志的写入已经在prepare写入)
个人理解：
flush stage:队列中的第一个线程为leader线程,后面的线程为follower线程,leader线程主要负责收集待提交binlog的线程(线程准备阶段之后自动进入flush阶段)，直到队列为空,或者超时(binlog_max_flush_queue_time),才进入sync stage
sync stage:如果flush stage队列为空,则之前leader线程依然为leader线程,负责binlog的sync,否则变成follower线程(合并执行sync)
commit stage:sync完binlog的线程被放入commit队列的末尾,等待提交
5.7 的组提交：
Step1. InnoDB Prepare，记录当前的LSN到thd中。
Step2. 进入 Group Commit 的flush stage；Leader搜集队列，同时算出队列中最大的LSN。
Step3. 将InnoDB的redo log write/fsync到指定的LSN
Step4. 写Binlog并进行随后的工作(sync Binlog, InnoDB commit
也就是将 redo log的write/sync延迟到了 binlog group commit的 flush stage 之后，sync binlog之前。
通过延迟写redo log的方式，显式的为redo log做了一次组写入(redo log group write)，并减少了(redo log) log_sys->mutex的竞争。
组提交
http://www.tuicool.com/articles/rEZr2q
http://www.csdn.net/article/2015-01-16/2823591(淘宝内部mysql交流)
innodb数据丢失的问题：
http://www.360doc.com/content/14/1019/00/12904276_418041635.shtml
组提交的理解：
