mysql commit过程详述

MySQL通过内部两阶段提交协议来提交事务，如下图

具体实现如下图：

第一阶段 ：InnoDB prepare，持有prepare_commit_mutex，并且write/sync redo log；将rollback设置为Prepared状态，binlog prepare不作任何 *** 作；

第二阶段 ：包含两步，write/sync Binlog及 InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex)；

考虑mysql以binlog的写入与否作为事务提交成功与否的标志，如果 在写入innodb commit标志时崩溃(binglog已经写文件但是还没有提交) ，则恢复时，会重新对commit标志进行写入；此时的事务崩溃恢复过程如下：

1)扫描最后一个Binlog文件，提取其中的xid；

2)InnoDB维持了状态为Prepare的事务链表，将这些事务的xid和Binlog中记录的xid做比较，如果在Binlog中存在，则提交，否则回滚事务。

但其中也会存在2个问题：

并发危机:全局大锁prepare_commit_mutex

Mysql5.6.5前的做法，加锁，串行化

无锁方案：如果能保证binlog write 和  Innodb commit的顺序一致性就可以解决该问题。

性能问题：参数sync_binlog =1 ,innodb_flush_log_at_trx_commit =1时，fsync *** 作频繁

数据持久化到磁盘:调用fsync将缓存中的数据刷新到磁盘（普通硬盘150次/s和SSD 1200次/S），影响TPS；Group Commit *** 作，在多个事务并发时，将等待fsync的多个事务合并为仅调用一次fsync *** 作，以解决innodb fsync的问题，对binlog 的fsync也适用

对上述两个问题的解决：

针对并发问题

Group *** 作，三个阶段都在维护一个队列。第一个进队列的线程称为leader线程，负责对队列里所有线程进行 *** 作；之后进入队列的线程称作follower线程，follower 线程进入队列后睡眠，等待leader完成 *** 作后将他们唤醒。注意：前一个队列leader进入后一个队列时，会把自己原队列的follower全加入进去。

针对一致性问题 

Group commit 分为三个阶段，每个阶段有一个线程在执行。分阶段的目的在于各个阶段可以并发执行，提升效率。

涉及参数说明：

sync_binlog =1 :启用group commit之后，其实已经不是一个事务去刷一次磁盘了，而是一组事务刷一次磁盘。图中1、2分别代表sync_binlog 不同配置下，通知其他线程（如dump线程）binlog 已经更新了，当配置为1时，要严格等到sync完毕之后才会发送广播通知, 如果sync_binlog配的是别的值，MySQL会把通知提前到1的位置

binlog_group_commit_sync_no_delay_count(组提交sync无延迟时间最大event数)及binlog_group_commit_sync_delay(组提交sync延迟时间，单位：毫秒)：一般来说我们认为group commit 中最耗时的 *** 作是sync阶段，于是我们可以在sync阶段在leader真正sync之前进行一个等待，以便让fsync一次性刷新更多的事务。这对需要等待sync 完之后才能进行的 *** 作(比如dump线程）可能有性能提升。

两阶段提交：

MYSQL_BIN_LOG作为协调者

CPU占用过高诊断思路

mpstat -P ALL 1，查看cpu使用情况，主要消耗在sys即os系统调用上

perf top，cpu主要消耗在_spin_lock

生成perf report查看详细情况

CPU主要消耗在mutex争用上，说明有锁热点。

采用pt-pmp跟踪mysqld执行情况，热点主要集中在mem_heap_alloc和mem_heap_free上。

Pstack提供更详细的API调用栈

Innodb在读取数据记录时的API路径为

row_search_for_mysql --》row_vers_build_for_consistent_read --》mem_heap_create_block_func --》mem_area_alloc --》malloc --》  _L_unlock_10151 --》__lll_unlock_wait_private

row_vers_build_for_consistent_read会陷入一个死循环，跳出条件是该条记录不需要快照读或者已经从undo中找出对应的快照版本，每次循环都会调用mem_heap_alloc/free。

而该表的记录更改很频繁，导致其undo history list比较长，搜索快照版本的代价更大，就会频繁的申请和释放堆内存。

Linux原生的内存库函数为ptmalloc，malloc/free调用过多时很容易产生锁热点。

当多条 SQL 并发执行时，会最终触发os层面的spinlock，导致上述情形。

解决方案

将mysqld的内存库函数替换成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高并发调用。

修改my.cnf，添加如下参数并重启

[mysqld_safe]malloc-lib=tcmalloc

上周五早上7点执行的 *** 作，到现在超过72小时，期间该实例没有再出现cpu长期飙高的情形。

以下是修改前后cpu使用率对比

---