想要做网站,wordpress下载tar.gz,做网站的整体风格确定方式,天眼查登录入口http://blog.csdn.net/woqutechteam/article/details/51178803 MySQL Binary log在MySQL 5.1版本后推出主要用于主备复制的搭建#xff0c;我们回顾下MySQL 在开启/关闭 Binary Log功能时是如何工作的 。 MySQL没有开启Binary log的情况下#xff1a; InnoDB存储引擎通过re…http://blog.csdn.net/woqutechteam/article/details/51178803 MySQL Binary log在MySQL 5.1版本后推出主要用于主备复制的搭建我们回顾下MySQL 在开启/关闭 Binary Log功能时是如何工作的 。 MySQL没有开启Binary log的情况下 InnoDB存储引擎通过redo和undo日志可以safe crash recovery数据库当数据crash recovery时通过redo日志将所有已经在存储引擎内部提交的事务应用redo log恢复所有已经prepared但是没有commit的transactions将会应用undo log做roll back。然后客户端连接时就能看到已经提交的数据存在数据库内未提交被回滚地数据需要重新执行。MySQL开启Binary log 的情况下 为了保证存储引擎和MySQL数据库上层的二进制日志保持一致因为备库通过二进制日志重放主库提交的事务假设主库存储引擎已经提交而二进制日志没有保持一致则会使备库数据丢失造成主备数据不一致引入二阶段提交two phase commit or 2pc 图1 二阶段提交 MySQL二阶段提交流程 Storage EngineInnoDB transaction prepare阶段即sql语句已经成功执行并生成redo和undo的内存日志 Binary log日志提提交 write()将binary log内存日志数据写入文件系统缓存fsync()将binary log 文件系统缓存日志数据永久写入磁盘 Storage Engine(InnoDB)内部提交 commit阶段在存储引擎内提交( innodb_flush_log_at_trx_commit控制)使undo和redo永久写入磁盘 开启Binary log的MySQL在crash recovery时 当事务在prepare阶段crash数据库recovery的时候该事务未写入Binary log并且存储引擎未提交将该事务roll back。当事务在Binary log日志已经fsync()永久写入二进制日志时crash但是存储引擎未来得及commit,此时MySQL数据库recovery的时候将会从二进制日志的XidMySQL数据库内部分布式事务XA中获取提交的信息重新将该事务重做并commit使存储引擎和二进制日志始终保持一致。 以上提到单个事务的二阶段提交过程能够保证存储引擎和binary log日志保持一致但是在并发的情况下怎么保证存储引擎和Binary Log提交的顺序一致当多个事务并发提交的情况如果Binary Log和存储引擎顺序不一致会造成什么影响 图2 InnoDB存储引擎提交的顺序与MySQL上层的二进制日志顺序不同 如上图事务按照T1、T2、T3顺序开始执行将二进制日志按照T1、T2、T3顺序写入日志文件系统缓存调用fsync()进行一次group commit将日志文件永久写入磁盘但是存储引擎提交的顺序为T2、T3、T1。当T2、T3提交事务之后做了一个On-line的backup程序新建一个slave来做replication那么事务T1在slave机器restore MySQL数据库的时候发现未在存储引擎内提交T1事务被roll back此时主备数据不一致(搭建Slave时change master to的日志偏移量记录T3在事务位置之后)。 结论MySQL数据库上层二进制日志的写入顺序和存储引擎InnoDB层的事务提交顺序一致用于备份及恢复需要如xtrabackup和innobackpex工具。 为了解决以上问题在早期的MySQL版本通过prepare_commit_mutex 锁保证MySQ数据库上层二进制日志和Innodb存储引擎层的事务提交顺序一致。 图3 通过prepare_commit_mutex保证存储引擎和二进制日志顺序提交顺序一致 图3可以看出在prepare_commit_mutex只有当上一个事务commit后释放锁下一个事务才可以进行prepara操作并且在每个transaction过程中Binary log没有fsync()的调用。由于内存数据写入磁盘的开销很大如果频繁fsync()把日志数据永久写入磁盘数据库的性能将会急剧下降。此时MySQL 数据库提供sync_binlog参数来设置多少个binlog日志产生的时候调用一次fsync()把二进制日志刷入磁盘来提高整体性能该参数的设置作用 sync_binlog0二进制日志fsync()的操作基于操作系统。sync_binlog1每一个transaction commit都会调用一次fsync()此时能保证数据最安全但是性能影响较大。sync_binlogN当数据库crash的时候至少会丢失N-1个transactions。图3 所示MySQL开启Binary log时使用prepare_commit_mutex和sync_log保证二进制日志和存储引擎顺序保持一致通过sync_binlog来控制日志的刷新频率prepare_commit_mutex的锁机制造成高并发提交事务的时候性能非常差而且二进制日志也无法group commit。 那么如何保证MySQL开启Binary Log日志后使二进制日志写入顺序和存储引擎提交顺序保持一致并且能够进行二进制日志的Group Commit MySQL 5.6 引入BLGCBinary Log Group Commit,二进制日志的提交过程分成三个阶段Flush stage、Sync stage、Commit stage。 那么事务提交过程简化为 存储引擎InnoDB) Prepare ---- 数据库上层(Binary Log) Flush Stage ---- Sync Stage ---- 调存储引擎InnoDBCommit stage. 每个stage阶段都有各自的队列使每个session的事务进行排队。当一个线程注册了一个空队列该线程就视为该队列的leader后注册到该队列的线程为followerleader控制队列中follower的行为。leader同时带领当前队列的所有follower到下一个stage去执行当遇到下一个stage并非空队列此时leader可以变成follower到此队列中注follower的线程不可能变成leader 图4: 二进制日志三阶段提交过程 在 Flush stage所有已经注册线程都将写入binary log缓存 在Sync stage binary log缓存的数据将会sync到磁盘当sync_binlog1时所有该队列事务的二进制日志缓存永久写入磁盘 在 Commit stage:leader根据顺序调用存储引擎提交事务。 当一组事务在进行Commit阶段时其他新的事务可以进行Flush阶段从而使group commit不断生效。那么为了提高group commit中一组队列的事务数量MySQL用binlog_max_flush_queue_time来控制在Flush stage中的等待时间让Flush队列在此阶段多等待一些时间来增加这一组事务队列的数量使该队列到Sync阶段可以一次fysn()更多的事务。 MySQL 5.7 Parallel replication实现主备多线程复制基于主库Binary Log Group Commit, 并在Binary log日志中标识同一组事务的last_commitedN和该组事务内所有的事务提交顺序。为了增加一组事务内的事务数量提高备库组提交时的并发量引入了binlog_group_commit_sync_delayN 和binlog_group_commit_sync_no_delay_countN (注binlog_max_flush_queue_time 在MySQL的5.7.9及之后版本不再生效)参数MySQL等待binlog_group_commit_sync_delay毫秒直到达到binlog_group_commit_sync_no_delay_count事务个数时将进行一次组提交。 Reference:http://mysqlmusings.blogspot.kr/2012/06/binary-log-group-commit-in-mysql-56.html转载于:https://www.cnblogs.com/devilwind/p/8058248.html
