关于MySQL的commit非规律性失败案例的深刻分析

案例描述：

　　一个普通的事务提交，在应用里面会提示commit超时，失败。

1、理论知识

一、关于commit原理，事务提交过程

　　一、寻找修改的数据页：

　　　　一、若是该数据页在内存中，则直接是内存读；

　　　　二、若是该数据页内存中没有，物理读，就从磁盘调入内存；

　　二、磁盘中的undo页调入内存；

　　三、先将原来的数据存入undo，而后修改数据(数据页成脏页)；

　　四、修改数据的信息生成redo数据存入log_buffer(内存buffer_pool的一个空间，默认16M)中；

mysql> show variables like '%log_buffer%';+------------------------+----------+| Variable_name          | Value    |+------------------------+----------+| innodb_log_buffer_size | 16777216 |+------------------------+----------+1 row in set (0.01 sec)

　　五、log_buffer经过log线程(后台线程，很是勤快)，持续不断的将redo信息写入disk的innodb_log_file中；

mysql> show variables like 'innodb_log_file%';+---------------------------+----------+| Variable_name             | Value    |+---------------------------+----------+| innodb_log_file_size      | 50331648 || innodb_log_files_in_group | 2        |+---------------------------+----------+2 rows in set (0.01 sec)

　　六、事务提交，刻意触发log线程，将剩余的log_buffer中的redo数据信息写入磁盘中，数据量已剩很少，写完提交成功。

注意：

　　一、修改记录前，必定要先写日志；

　　　　“日志先行”，这是数据库最基本的原则。

　　二、事务提交过程当中，必定要保证日志先落盘，才能算事务提交完成。

　　三、意外掉电，内存脏页丢失，可是磁盘的innodb_log_file中存放了redo日志信息，待重启服务器，MySQL经过读取磁盘的log_files数据，自动将数据的修改从新跑一边。

Q：为何mysql commit速度老是很快，尽管事务修改的数据量可能很大？

A：

　　由于事务提交，并非对磁盘数据进行修改，而是将修改数据的redo信息经过后台log线程写入磁盘的redo logfile中，完成mysql commit，不管事务修改的数据量有多大，这个过程速度是很快的。

　　而内存中的脏块，也就是修改后的数据页，正常状况下是由后台相关write线程周期性的将脏页数据刷入磁盘中，保证innodb buffer pool有足够的干净块、可用块。

二、关于rollback原理，回滚过程

　　一、MySQL读取内存中undo页信息

　　二、经过undo信息找到脏页，反着对数据进行修改

　　三、do、undo的时间相同，且都会产成redo信息

　　四、事务提交

MySQL回滚处理机制：

　　若是线程中断，事务没有提交，undo会将记录此信息，待另外一会话进程连上，查看该块数据信息，MySQL自动回滚进行数据页修改，而后被读取。也就是说为了不系统由于rollback被hang住，经过直接杀死进程的方式，中断事务，等待后来者要读取该数据信息时进行回滚，再返回结果。

Q：rollback为何有时候很慢，rollback的风险和风险避免方式？

A：

　　rollback的时间取决于回滚前事务修改数据的时间，处理量大回滚时间长，处理量小回滚时间短。

　　一、rollback风险：容易致使系统被hang住；

　　二、风险避免方式：直接杀死会话进程或是mysql进程。

三、存储写入性能分析

Q：mysql commit，存储为何写速度可以保持在0ms，极少出现1ms状况？

A：

　　对于存储来讲，写性能至关高：假设存储cache总有空闲空间的状况下，事务提交，将log buffer中剩余的不多的redo数据写入存储cache，即为完成mysql commit，这个过程是至关快的(可以保持在0ms，极少出现1ms状况)，后续redo数据由cache写入磁盘的过程是后台进行。

四、存储级别的灾备(同城灾备)

　　一、灾备同步过程：commit

　　　　一、redo、binlog写入本地存储cache；

　　　　二、经过网络同步binlog写入远端同步的服务器的存储cache中；

　　　　三、响应本地数据库；

　　　　四、事务提交成功；

　　二、风险：

　　　　网络出现问题(信号断续，缆线断了)，致使写hang住，commit超时失败。

　　三、解决：

　　　　经过超时设置，网络中断超过限制，自动将同步改成灾备异步，尽量少的影响业务commit超时失败。

 

2、分析与处理

　　存储写性能比较差，不少时段会达到5ms，甚至于10ms以上

　　　　备注：灾备同步已经中止的状况下。

一、存储中BBU问题，出现监控BBU的bug；

　　解决：重启BBU，不行就更新BBU。

二、cache被占满

　　一、海量数据写入，commit数据占满cache；

　　二、硬盘I/O异常，异常SQL致使的海量物理读；

　　解决：索引优化。

三、存储性能差

　　解决：找老板掏钱，更换优质设备。