testing-04
在上上周给下厨房做过一次数据恢复(故障回顾：故障发生的技术总结 致歉信)，恢复使用了开源工具Percona Data Recovery Tool for InnoDB(后面简称PDRTI)，这里分享一下期间的注意事项，和遇到MySQL数据丢失的一些应对。
本文主要介绍在使用Percona Data Recovery Tool for InnoDB时候的一些注意事项，并不包括具体的step by step的使用步骤，使用文档可以参考：Reference Manual and Documentation。 (more…)
今天发现Percona Release的Percona-Server-5-5-18-23-0已经完成了Group Commit工作，而且是用最优雅的方式（移植了MariaDB的实现，而不是workaround），心里难掩激动。
这篇文章接前篇继续介绍一下问题的背景：什么是Group Commit，现在的官方版本Group Commit做到了什么程度？
MySQL/InnoDB在做事务的时候使用的日志先行（Write-ahead logging）的方式保证事务的快速和持久，所以每次事务完成都要求日志必须持久化到磁盘，在Linux上对应的操作就是“write and fsync”，write速度是很快的，一般对应的写Page Cache，而fsync则要求文件系统把对应文件的哦Page Cache必须持久化到磁盘上，而对于传统磁盘一次写操作大约需要1~3ms（不说BBU），这意味着对于传统磁盘1秒钟最多最多做333～1000个事务，这是不理想的，对硬件的利用率（吞吐量）也是非常低。
所以，这里就有了Group操作的概念，即当好几个线程都要fsync同一个日志文件时，我们将这些fsync合并到一次来做。简单举例：我们让系统每2ms做一次fsync，这样如果这2ms内有100个线程都需要做fsync，那就赚到了，原本100个fsync都独立来做那耗时会非常多的。
你肯定会说，难道这不是很简单的想法吗？是的，这就是原本是很简单、也很自然的想法。
但对MySQL来说却变成了一种奢求（看看这个Bug讨论）。
MySQL是不是太弱了，这么简单的事情都搞不定？不是的。
MySQL从开源到现在，成功的一个非常重要的原因，就是MySQL的插件式架构。如果MySQL只是MyISAM估计不会有现在的流行程度，插件式的架构让诸如Heikki Tuuri有了发挥空间，在InnoDB和MySQL一起时，MySQL才能算是一个真正的DBMS。再到后来，有Infobright、 FEDERATED、PBXT等等。
插件式的架构给MySQL带来了活力，做出牺牲便是在上层(MySQL)和下层(存储引擎)交互时带来的额外消耗，有时甚至上层和下层需要做一些重复工作。无法做Group Commit就是这其中的牺牲之一。
如果用的引擎是InnoDB，每次敲下mysqladmin -uroot -p shutdown关闭数据库的时候，总是很难预测这个命令会执行多久，实际经验表明，短则五秒，长则三十分钟一小时都有可能。也分享一下我的经验吧。
事实上，并不是每次关闭InnoDB都很慢的。Why？InnoDB较之MyISAM，一个重要特性是InnoDB会在内存中开辟一个Buffer Pool来存储最近访问的数据块/索引块，使得下次再次访问这个块时速度能够很快。当InnoDB对需要修改数据块的时候，会先记录修改日志，然后直接对Buffer_Pool中的数据块的操作。记录日志是顺序写，对数据块的操作是内存操作，这让InnoDB在很多场景下有这很好的速度优势。 (more…)
很多人都讨论了这个问题，参数innodb_thread_concurrency限制了InnoDB内部线程的数量。例如当有query需要InnoDB处理时，InnoDB首先会检查一下当前的内部线程数是不是超过了innodb_thread_concurrency的限制，如果超出则会让当前线程sleep一会儿，再试，如果还是受限，则会进入一个FIFO的队列。如果innodb_thread_concurrency设置成0表示，内部线程数量将不受限制（注：innodb_thread_concurrency值在不同的版本意义略有不同）。
我不知道多大合适。我的经验值设置成64就够了，正常情况，应用并发不会超过这个值。
如果设置成0，会让InnoDB的内部线程不受限制，如果你高并发的IO-bound的应用，很可能在InnoDB内部累计很多的并发等待IO的线程，主机的Load会很高，但是数据库依然会正常运行。
从5.1.11开始这个值的默认值是8，意味着，InnoDB会限制内部线程数不超过8。如果是高并发的应用，你的MySQL能力可能会受到这个参数的限制。对于很多情况这个值有偏小的，并发量可能会比8大，这时参数innodb_thread_concurrency就会成为InnoDB的瓶颈。对于一个16核的系统，处理的并发很多时候都会大于8，而受cpu核数限制，太多的线程会在CPU切换上消耗过多资源。
但是如果你系统并发量始终都是小于8的，那么设置成一个大于8的值并没有意义。
通过supersmack模拟了128个线程并发，做了5组对比测试：
最后，提一下，没事不要在生产环境动态更改innodb_thread_concurrency，很危险：Bug 40760。
参考：
1. MySQL Manual
2. MySQL: innodb_thread_concurrency beast
3. do we still need innodb_thread_concurrency
4. Mess with innodb_thread_concurrency
6. MySQL Bugs