Group Commit of Binary Log
160222 09:19:26 mysqld_safe Starting mysqld daemon with databases from /data01/mysql
2016-02-22 09:19:32 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use –explicit_defaults_for_timestamp server option (see documentation for more details).
2016-02-22 09:19:34 1589 [Note] Plugin ‘FEDERATED’ is disabled.
2016-02-22 09:19:34 1589 [Note] InnoDB: Using atomics to ref count buffer pool pages
2016-02-22 09:19:34 1589 [Note] InnoDB: The InnoDB memory heap is disabled
2016-02-22 09:19:34 1589 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-02-22 09:19:34 1589 [Note] InnoDB: Memory barrier is not used
2016-02-22 09:19:34 1589 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-02-22 09:19:34 1589 [Note] InnoDB: Using CPU crc32 instructions
2016-02-22 09:19:34 1589 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2016-02-22 09:19:34 1589 [Note] InnoDB: Completed initialization of buffer pool
2016-02-22 09:19:35 1589 [Note] InnoDB: Highest supported file format is Barracuda.
2016-02-22 09:19:35 1589 [Note] InnoDB: The log sequence numbers 1625997 and 1625997 in ibdata files do not match the log sequence number 14714403811 in the ib_logfiles!
2016-02-22 09:19:35 1589 [Note] InnoDB: Database was not shutdown normally!
2016-02-22 09:19:35 1589 [Note] InnoDB: Starting crash recovery.
2016-02-22 09:19:35 1589 [Note] InnoDB: Reading tablespace information from the .ibd files…
2016-02-22 09:19:36 1589 [Note] InnoDB: Restoring possible half-written data pages
2016-02-22 09:19:36 1589 [Note] InnoDB: from the doublewrite buffer…
InnoDB: Last MySQL binlog file position 0 196060496, file name mysql-bin.000005
2016-02-22 09:19:38 1589 [Note] InnoDB: 128 rollback segment(s) are active.
2016-02-22 09:19:38 1589 [Note] InnoDB: Waiting for purge to start
2016-02-22 09:19:38 1589 [Note] InnoDB: 5.6.22 started; log sequence number 14714403811
^G/usr/local/mysql/bin/mysqld: File ‘/data01/mysqllog/binlog/mysql-bin.000005’ not found (Errcode: 2 - No such file or directory)
2016-02-22 09:19:39 1589 [ERROR] Failed to open log (file ‘/data01/mysqllog/binlog/mysql-bin.000005’, errno 2)
2016-02-22 09:19:39 1589 [ERROR] Could not open log file
2016-02-22 09:19:39 1589 [ERROR] Can’t init tc log
2016-02-22 09:19:39 1589 [ERROR] Aborting
其实他是先查看redo log，找出prepared但没有commited或aborted的事务列表，然后检查binlog，binlog没记录就commit，否则rollback
Group Commit of Binary Log
问题汇总:
当binlog 被启用, 会有一个急剧的性能下降 由于下面的原因:
1.binary log 不利用 组提交技术
2.有几个访问磁盘 即 写和flush
MySQL 使用预写记录来提供耐久性和一致性。
具体而言, 它们写redo和很少的undo 更改到日志
确保当提交事务的改变会被写入和刷新到磁盘
但注意的是,每秒事务提交的数量越多 越高的速度写和flush logs.
如果什么都没做 log会最终变成性能瓶颈。
绕过这个问题,一个延期的当 任何访问存储为搜集在内尽可能多的提交
这样一次写和刷新对于一组事务
这个技术被命名为group commit 是广泛用于数据库系统 来改善性能
建议的解决方案(总结):
我们要:
使用该组提交技术来减少写入和flush
问题详情:
看下面看到会发生什么, 当你提交一个事务 和启用binary log.
这个描述是基于Harrison分析当前实现的性能问题相关和使用InnoDB 作为存储引擎
因为唯一的真正的事务性引擎
- Prepare Innodb:
a) 写 prepare record 到InnoDB的log buffer
b) 同步log file 到磁盘
c) Take prepare_commit_mutex
- “Prepare” binary log:
a) 写事务到binary log
b) 同步binary log 基于sync_binlog
如果sync_binlog值大于0, MYSQL server 同步它的binary log 到磁盘(使用fdatasync()）
在每次sync_binlog 写到binary log.如果自动提交启用,会把每个语句写到binary log里
默认值是0,不是同步写到磁盘的 在这种情况下, server 依赖操作系统来flush binary log的内存
值设为1 是安全的选择,由于crash 你最多丢失一个语句或者事务。然而,那也是最慢的选择
- Commit Innodb:
a) 写commit 记录到log
b) 释放 prepare_commit_mutex
c) 同步log file 到磁盘
d) 释放InnoDB 锁
- 提交 binary log
这种模型有5个问题:
- Prepare_commit_mutex 阻止binary log 和Innodb 进行group commit
prepare_commit_mutex 是用于确保事务是被提交到binary log 通过相同的顺序 它们被提交到InnoDB logs.
这是 Innodb Hot Backup的需要 我们没有意图改变
2.binary log 没有准备group commiting
由于这个互斥锁一次只有一个事务执行步骤2 ,这样binary log 不能group 一组事务
来降低写和flush的数量。
此外, 这个代码是不准备利用group 提交。
3.锁是持有用于 fsync的周期
MySQL 使用锁来实现它的一致性读模式,显然, 更高的锁级别 会更低的并发级别
一般来说, 它是安全的释放事务的锁 当已经提交记录到磁盘。
锁被分为两个不同的组,共享和独占锁。 共享锁会在找出一个事务已经进行它的事务后释放
并很愿意到提交。
- 不必要的磁盘访问，比如 太多的fsync
事务被写入磁盘3次,当binary log 被启用。
这个可以被改善作为Binary log 是作为来源和用于恢复
目前, 当恢复的时候,InnoDB 变异一个事务的列表 是prepared和不是提交也不是aborted
检查binary log 来决定。如果一个事务是被写入到binary log，它是提交的 否则它是回滚的
很显然, 不需要写和flush 提交的事务因为 最终会被其他的事务写入 在 prepare 阶段
或者 Innodb的后台进程 每秒写和刷新 innnodb buffer logs.
作用：事务在内存中的缓冲。
分配原则：控制在2-8M.这个值不用太多的。他里面的内存一般一秒钟写到磁盘一次。具体写入方式和你的事务提交方式有关。在Ｏｒａｃｌｅ等数据库了解这个，一般最大指定为３Ｍ比较合适。
我们推迟写和flush 在提交阶段, 为了改善性能和周期性的写和flushed 配置。
周期设置越大,会增加恢复的时间。
在功能上, 我们应该改善这种情况通过避免写和flush 在prepare阶段和
依赖binary log 来重现 丢失的事务。
5.
binary log 工作在存储引擎和一个事务协调 让它很难维护和发展。
binary log 注册为一个handler 和得到回调 当preparing,
committing, and aborting.
这个允许它写cached 数据到binary log 或者操作 事务装态以另外一种方式。
此外, binary log 表现为一个事务协调器事实上是唯一的事务协调器。
事实上它注册作为一个handler 导致一些问题 在维护方面(和潜在的性能)
建议的解决方案（细节）
启用binary log 来提高性能 可以产分下面的任务:
- 消除 prepare_commit_mutex, 或者需要它。
这与处理binary log 事务的顺序 相比innodb logs的事务的顺序
- Flush the binary log properly.
prepareing和 提交一个事务到一个binary log 不会自动的 意味着 binary log 是被刷新了。
事实上,执行一个group 提交的整个点 是不需要 每次事务都flush binary log
代替的是改善性能通过降低每个事务的flush次数
- 处理读锁的释放 以便进一步提高性能
更早的释放锁 是改善性能特别是对于有大量读的应用
4.延迟写和flush 在提交阶段
这将改善性能通过减少写和flush的数量 当binary log 启用时
5.让binary log 只是一个事务协调器:
