柔中带刚，刚中带柔，淫荡中富含柔和，刚猛中荡漾风骚，无坚不摧，无孔不入！
全部博文（1669）
分类：
2012-10-25 09:36:19
2012-10-24 11:01:57| 分类： my优化 | 标签： |字号大中小
在MySQL服务器出现短暂(5~30秒)的性能波动的时候，一般的性能监控工具都很难抓住故障现场，也就很难收集对应较细粒度的诊断信息。另外，如果这种波动出现的频率很低，例如几天才一次，我们也很难人为的抓住现场，收集数据。这正是pt-stalk所解决的问题。
pt-stalk是的一部分(其前身是的一部分)。安装Percona-Toolkit后，可以通过man pt-stalk了解如何使用该工具，本文的介绍是man pt-stalk的一个子集，强烈建议直接阅读man pt-stalk。额外的，本文将提供pt-stalk示例命令可供参考。
上面的命令表示，让pt-stalk后台运行(--daemonize)，并监视SHOW GLOBAL STATUS中的Threads_connected状态值，如果该值超过2500，则触发收集主机和MySQL的性能、状态信息。pt-stalk会每隔一秒检查一次状态值，如果连续5次满足触发条件，则开始收集。
--collect-tcpdump表示除了收集基本信息外，还将额外使用tcpdump收集当时的网络包，类似的还可以使用--collect-gdb等。
[......]
今天发现Percona Release的Percona-Server-5-5-18-23-0已经完成了Group Commit工作，而且是用最优雅的方式（移植了MariaDB的实现，而不是workaround），心里难掩激动。
这篇文章接继续介绍一下问题的背景：什么是Group Commit，现在的官方版本Group Commit做到了什么程度？
MySQL/InnoDB在做事务的时候使用的日志先行（）的方式保证事务的快速和持久，所以每次事务完成都要求日志必须持久化到磁盘，在Linux上对应的操作就是“”，write速度是很快的，一般对应的写Page Cache，而fsync则要求文件系统把对应文件的哦Page Cache必须持久化到磁盘上，而对于传统磁盘一次写操作大约需要1~3ms（不说BBU），这意味着对于传统磁盘1秒钟最多最多做333～1000个事务，这是不理想的，对硬件的利用率（吞吐量）也是非常低。
所以，这里就有了Group操作的概念，即当好几个线程都要fsync同一个日志文件时，我们将这些fsync合并到一次来做。简单举例：我们让系统每2ms做一次fsync，这样如果这2ms内有100个线程都需要做fsync，那就赚到了，原本100个fsync都独立来做那耗时会非常多的。
你肯定会说，难道这不是很简单的想法吗？是的，这就是原本是很简单、也很自然的想法。
但对MySQL来说却变成了一种奢求（看看这个）。
MySQL是不是太弱了，这么简单的事情都搞不定？不是的。
MySQL从开源到现在，成功的一个非常重要的原因，就是MySQL的插件式架构。如果MySQL只是MyISAM估计不会有现在的流行程度，插件式的架构让诸如Heikki Tuuri有了发挥空间，在InnoDB和MySQL一起时，MySQL才能算是一个真正的DBMS。再到后来，有Infobright、 FEDERATED、PBXT等等。
插件式的架构给MySQL带来了活力，做出牺牲便是在上层(MySQL)和下层(存储引擎)交互时带来的额外消耗，有时甚至上层和下层需要做一些重复工作。无法做Group Commit就是这其中的牺牲之一。
[......]
这里介绍一个最近用得很多的一个小工具：。
主要有两个功能：
(1) 尽可能快的从一个非常大的mysqldump文件的分离出某个单表的备份文件
(2) 可以帮你把一个大的mysqldump文件，切割成非常小的单表备份文件（可继续做并行恢复）
(1) 如果把MySQL中某一个表数据弄丢了，需要从很大的mysqldump备份文件中恢复这个表
(2) 如果你想并行恢复整个mysqldump备份文件时，这个脚本可以帮你把大文件切割成多个小的单表备份文件，然后就可以方便并行恢复多个文件了
这里以实例的方式介绍如何使用该脚本：
(1) 从backup.sql文件中获取表process的备份：
tbdba-restore-mysqldump.pl -t process -f backup.sql
(2) 从backup.sql文件中获取数据库monitor中的表process的备份：
tbdba-restore-mysqldump.pl -t process -s monitor -f backup.sql
[......]
