MySQL管理员珍藏：十大必备工具盘点

tongy

http://tech.it168.com/a2011/0808/1229/000001229492_2.shtml

MySQL必备工具第一位: mk-query-digest
　　没有什么比低下的MySQL性能表现更让人抓狂的了。尽管大家常常下意识地认为是硬件配置滞后导致此类问题，但事实上在大多数情况中真正的症结并不在这里。性能表现不佳往往由以下原因造成，即某些执行缓慢的查询阻塞了其它查询指令的顺畅进行，并由此产生了一个响应时间迟缓的恶性循环。由于优化查询指令比起升级硬件来说能够节约大量成本，因此合乎逻辑的优化方式应该从分析查询指令日志文件入手。
　　数据库管理员们应该经常分析查询日志，进而把握运行环境的各类波动。而如果大家从来没有进行过该项分析，请立即着手进行吧。如果对此缺乏经验，依靠第三方软件的帮助也是不错的选择;尽管很多人认为那些软件只会在瞎忙一气之后给出一个虚构的漂亮结果，但我得说，实际上它们通常情况下还是确切有效的。
　　在当前的诸多选择中，mk-query-digest是查询日志分析工具中最棒的一款。它由Baron Schwartz和我本人联合编写，功能成熟性、记录充分性以及测试彻底性都做得相当到位。MySQL本身包含了一款名为mysqldumpslow的查询日志分析器，但该工具不仅陈旧过时、验证规范不准确，而且缺乏广泛的实际应用加以支持。而其它几款较为著名的查询日志分析器，包括我前几年编写的mysqlsla，都与mysqldumpslow具备相同的缺点。
　　mk-query-digest能够分析查询日志内容并根据汇总得出的执行时间及其它各项指标的统计信息自动生成报告。由于查询日志中的信息量极为巨大，有时甚至包含数以百万计的条目，因此此类分析工作必须依靠特定工具来完成。
　　mk-query-digest可以帮助大家找出那些与其它查询指令相比耗时最长的条目。对这些低速查询加以优化将使整套MySQL体系的运行速度大幅提高，最大响应延迟也将相应下降。查询指令的优化工作本身堪称艺术，其中包含诸多细致入微的技巧，但整个流程的基本原则总是共通的：寻获低速查询指令、进行优化、提高查询响应时间。
　　该工具使用起来非常简便，执行mk-query-digest slow-query.log，那些运行速度迟缓的查询指令将被输出至slow-query.log文件。工具中还提供了“查询指令复核”功能，意在列出那些我们尚未加以核对或批准的查询指令。如此一来，我们就可以仅仅对那些新出现的查询指令进行有针对性的处理，繁琐枯燥的日志分析工作也随之变得更加快速、高效。
　　下载地址: http://maatkit.org/get/mk-query-digest
　　维护负责人: Daniel Nichter and Baron Schwartz
　　更多信息: http://maatkit.org/ | http://code.google.com/p/maatkit/

MySQL必备工具第二位: mydumper
　　能够快速生成数据转储在服务器及备份信息克隆工作中至关重要。遗憾的是，MySQL自身包含的mysqldump组件只支持单线程工作，这就使得它无法迅速解决数据密集型用户所面临的实际问题。不过好消息还是有的，mydumper作为新生代实用工具，能够良好支持多线程工作，这使得它在处理速度方面十倍于传统的mysqldump。
　　另一款知名的同类工具是MySQL Data Dumper，它的问题是无法单独管理备份集合、差异点或是一套完整备份计划中的其它组成部分。该工具只是单纯将MySQL中的数据以尽可能快的速度进行转储，这在完成限时任务方面倒是具备一定价值，例如趁员工没有在线操作的时段抓紧时间进行备份。另外，如果大家在实际使用中需要异常频繁地执行备份，那么MySQL Data Dumper是比较理想的选择。
　　从技术角度分析mydumper的话，其特征之一是在处理过程中需要对列表加以锁定，因此如果我们需要在工作时段执行备份工作，那么它恐怕没什么用武之地。但话说回来，专业级数据恢复的费用是每小时数百美元，而且即使数据没能得到恢复，我们收到的也不可能是道歉信而仍然是一纸账单。相比之下，mydumper完全免费，并且在基本备份工作中表现颇佳。
　　mydumper在克隆整体服务器方面也比较方便。其它工具往往会对硬盘内容进行整体复制，但大家需要的往往只是MySQL中的数据，这个时候mydumper就能迅速准确地完成任务。设置于云平台上的服务器特别适合使用mydumper进行克隆，只需将MySQL中的数据从现有服务器复制到新的实例中即可。
　　在创建从属服务器、基准确定及模板应用方面采用克隆方案确实行之有效，但克隆真正能够发挥作用的领域无疑还是在开发及测试环节当中。对于动态MySQL环境来说，在将软件推至台面之前迅速对其进行复制并加以测试可说是至关重要的步骤。有了mydumper，大家能够快速创建一套几乎与母体完全相同的服务器来模拟生产服务器，运行于其上的测试结果也将更接近于实际运行结果。
　　下载地址: https://launchpad.net/mydumper/+download
　　维护负责人: Domas Mituzas, Andrew Hutchings, Mark Leith
　　更多信息: http://www.mydumper.org/ | https://launchpad.net/mydumper/

MySQL必备工具第三位: xtrabackup 以及 xtrabackup-manager
　　如果大家每天都要用到自己的数据库，也就是说全天侯使用(晚间也需要运行)，那么锁定列表以进行备份的方案就无法奏效。这种情况之下，xtrabackup是我们的上上之选。这款工具又被称为Percona XtraBackup，它在备份过程中无需锁定列表，且是此类工具中惟一的免费开源产品。相比之下，那些专用的无锁定备份软件就显得相当昂贵，其使用成本达到每台服务器五千美元以上。
　　xtrabackup 还具备增量备份功能，允许大家在新一轮备份工作中只对那些相对上次备份结果有所变更的内容进行处理。增量备份功能非常贴心，能够在那些基础数据量庞大但变动相对较小的备份工作中发挥极佳的功效。
　　此外，另一款衍生于xtrabackup的工具也日趋成熟，它就是用于简化完整备份计划管理工作的xtrabackup-manager。尽管这款工具面世时间不长，且仍处于开发阶段，但其潜在能力不容忽视。它所提供的功能极为先进，包括集群备份整合及备份集合期限管理。综合来看，xtrabackup与xtrabackup-manager是一套强大且免费的备份工作解决方案。
　　下载地址: http://www.percona.com/software/percona-xtrabackup/downloads/
　　维护负责人: Percona
　　更多信息：
　　http://www.percona.com/docs/wiki/percona-xtrabackup:start |https://launchpad.net/percona-xtrabackup
　　下载地址: http://code.google.com/p/xtrabackup-manager/
　　维护负责人: Lachlan Mulcahy
　　更多信息: http://code.google.com/p/xtrabackup-manager/ | http://mysqlsoapbox.blogspot.com/

MySQL必备工具第四位: tcprstat
　　tcprstat可能是此次推荐的十款工具中最为艰深的项目。该工具用于监视TCP请求，并对低级别的响应时间进行统计及打印输出。当大家习惯于以响应时间来衡量性能表现，tcprstat的作用是相当可观的。
　　整套原则在Cary Millsap及Jeff Holt联合撰写的“甲骨文产品性能优化”一书中有详细阐述，而且该原则同样适用于MySQL。从基本思路上来说，MySQL也不例外，服务项目的运作遵循接收请求(即查询过程)、满足该请求(即执行时间)以及回馈响应结果(即结果集)。服务项目的实际响应时间指的正是从接收请求开始到发送响应之间的时间跨度。响应时间超短，相同时段内允许提交的请求数量就越多。
　　并行处理效能及其它低级别因素也在这一过程中扮演着重要角色，但我们应该将整个过程化繁为简，即把每个八小时工作日的实际运行时间按28800秒计算。因此如果能将每条请求的响应时间在原有基础上缩短400毫秒(即从原有的500毫秒缩短至100毫秒)，那么就意味着我们每天可以多处理230，400条请求。Tcprstat正是帮我们达成这一目标的利器。
　　由于篇幅所限，我在本文中只能在功能性方面略加描述(即讲解MySQL响应时间优化工作的第一步)以激起诸位读者的兴趣。如果大家在惊鸿一瞥之后决定加深了解，请在阅读“甲骨文产品性能优化”一书之后尝试使用tcprstat。
　　下载地址: (source) https://launchpad.net/tcprstat | (binary)http://www.percona.com/docs/wiki/tcprstat:start
　　维护负责人: Percona
　　更多信息: http://www.percona.com/docs/wiki/tcprstat:start | https://launchpad.net/tcprstat


MySQL必备工具第五位: mk-table-checksum
　　“数据偏差”是广泛存在于动态MySQL环境之中的一项重大问题。其实际含义为：从属数据未能与主体数据正确同步，发生的原因主要是从属数据端出现写入操作或者主体数据端执行了具备不确定性的查询指令。更糟糕的是，数据偏差情况很可能会被管理人员所忽视，直到爆发严重后果。Mk-table-checksum该登场了，这款工具的作用是在执行复杂、敏感的计算时，并行验证两个或多个列表中相关数据内容的一致性。
　　mk-table-checksum 能够分别为独立服务器及同步架构中的服务器提供帮助，这也是该工具最大的亮点所在。主体服务器与从属服务器之间的数据一致性在同步时必须得到充分的重视。由于主体数据变更在向从属数据同步的过程中存在一定程度的滞后(即延迟)，因此直接读取服务器数据的方式无法严格保证信息的一致性，因为数据在同步完全结束之前，一直处于不断变化且并不完整的状态下。锁定列表、等等所有数据同步结束之后再进行验证当然行之有效，但这种方案意味着我们不得不同时中止服务器服务的正常响应。mk-table-checksum允许大家在不锁定列表的前提下，对主体及从属数据间的差异性进行验证(至于该技术的具体实现方法，请单击此处参阅工具文档)。http://www.maatkit.org/doc/mk-table-checksum.html
　　除了同步过程中的一致性，数据验证在其它一些方面也颇具意义，例如列表尺寸问题。MySQL的CHECKSUM TABLE指令对于小型列表来说完全够用，但规模庞大的列表往往需要“分块”处理，以避免在校验及计算的过程中CPU或内存发生长期锁死或超载的状况。
　　分块处理能够应付的第二个大问题是对数据一致性定期检查的要求。虽然数据偏差可能只是一次偶然的意外，但事实上遇到脸丑手黑的管理员，这类问题也许会反复发作。mk-table-checksum的设计初衷正是对列表进行定期检查，且整个验证过程分步分块、循序渐进，直到整套大规模列表处理完毕。这种持续性处理方式有助于管理员对数据偏差进行经常性校对。
　　下载地址: http://maatkit.org/get/mk-table-checksum
　　维护负责人: Daniel Nichter & Baron Schwartz
　　更多信息: http://maatkit.org/ | http://code.google.com/p/maatkit/MySQL必备工具第六位: stalk 及collect
　　有时候，问题会在我们疏于监控或回家睡觉的时间段内发生，大家都知道在问题发生之后才对MySQL及服务器运行状态进行诊断往往很难甚至不可能得出正确结论。这时大家普遍的做法往往是亲自编写一套脚本然后静待检测结果，或者是对额外数据进行记录，毕竟没人比自己更了解自己所使用的系统。但问题是，系统正常工作时大家当然对其分外熟悉，如果系统当前的工作状态可能存在各类隐患，我们也往往会试图简单地将其解决掉而非进行深入的探索及分析。
　　值得庆幸的是，有人对MySQL崩溃状态下的状况非常了解，并针对那些常见多发的问题编写了两款分别名为stalk及 collect的故障排查工具。前一款工具的作用是在第二款真正运行实例之前等待设备状态符合故障发生时的情形。尽管粗看起来这一点似乎无关紧要，但事实上该工具确实简单高效地收集了各类可能引发问题的细节变化。
　　首先，stalk根据配置内容的要求每隔一段时间运行一次collect，该步骤能够消除记录中那些繁杂无用的冗余数据，使对此前故障的分析更有条理。接下来，collect会将MySQL对自身运行情况的报告及其它各类我们可能想都没想过的数据进行汇总，其中包括：曾经打开的文件夹、应用程序接受及调用的系统信息、网络通信量以及其它种种。如此一来，如果最终大家不得不求助于解决MySQL故障的专业咨询团队，那么他们在询问中所要涉及到的各类信息我们就都已经掌握了。
　　stalk 与collect能够根据需要进行配置，因此它们能够应付几乎所有故障情况。惟一的要求是为stalk的触发建立一项可定义的条件。如果有多项条件都是引发故障的嫌疑对象，那么大家可能需要与自己的MySQL运行环境专家进行磋商，以部署更广泛的审查工作。事实上，导致MySQL崩溃的根本原因也可能潜伏于该系统之外。
　　stalk 与 collect也可以用于主动防御。举例来说，如果大家了解到相同时间段内不应该同时存在50个以上的活跃MySQL连接，那么stalk可以主动监控这一问题。换句话说，这两款工具能够帮你解决许多初显端倪以及尚不明朗的麻烦。
　　下载地址:
　　http://aspersa.googlecode.com/svn/trunk/stalk |http://aspersa.googlecode.com/svn/trunk/collect
　　维护负责人: Baron Schwartz
　　更多信息: http://aspersa.googlecode.com/svn/html/index.html |http://code.google.com/p/aspersa/

MySQL必备工具第七位: mycheckpoint
　　没人希望问题确切发生之后才忙着想办法补救，因此通过可视化仪表对MySQL运行环境进行实时监控是防患于未燃的一项重要途径。
　　MySQL相关的免费或商业化监控应用程序很多，有些是专门服务于MySQL的、有些则是具备MySQL插件或模板的通用型工具。Mycheckpoint值得关注的原因是：它不仅免费开源，而且只针对MySQL，同时各类功能一应俱全。
　　跟当下大多数监控解决方案一样， mycheckpoint基于见面运行。以下图为例：

　　mycheckpoint可以经由设置对MySQL及服务器各项指示同时进行监控，例如InnoDB缓冲池刷新、临时列表创建、操作系统负载、内存使用情况等等。如果大家不喜欢阅读图表，mycheckpoint还能够生成文字报告。
　　正如 stalk的功能，警报条件可以定义为电子邮件通知，但不必运行collect这类收集额外故障排查数据的工具。Mycheckpoint的另一项实用功能是通过监控MySQL中的变量揪出可能导致问题的隐患，或者是阻止那些本不该存在的对MySQL的修改。
　　监控MySQL不仅仅对数据中心或者庞大的设备部署生效。即使大家只拥有一台MySQL服务器，监控措施仍然是不可或缺的;经由此类媒介，我们能够确切了解自己系统的相关运行情况，进而有效地预见或规避可能发生的故障。
　　下载地址: http://code.google.com/p/mycheckpoint/downloads/list
　　维护负责人: Shlomi Noach
　　更多信息: http://code.openark.org/forge/mycheckpoint

MySQL必备工具第八位: shard-query
　　还在为针对诸多分区或是数据碎片集合的查询速率低下而烦恼?其实只需使用shard-query，整个处理速度会大大加快。那些基于下列架构的查询指令能够从shard-query工具中得到最大的提升：
　　　　　　　　　　复合函数 SUM, COUNT, MIN, and MAX 等也能够使用上述架构。举例来说，下面这条查询指令即可由shard-query并行执行:

SELECT DayOfWeek, COUNT(*) AS c
FROM ontime_fact
JOIN dim_date USING(date_id)
WHERE Year
BETWEEN 2000 AND 2008
GROUP BY DayOfWeek
ORDER BY c DESC;　　根据基准测试的结果显示，通过并行处理的方式，该查询指令的响应时间缩短了85%左右，从原先的21秒降低至3秒。
　　Shard-query并不是一款能够独立运行的工具;它需要诸如Gearman之类的其它程序提供支持，而且设置过程也相对比较复杂。但如果大家的数据分区及查询指令符合上面列出的构造，那么付出一些努力也是值得的，毕竟优化效果非常明显。
　　下载地址: (svn checkout) http://code.google.com/p/shard-query/source/checkout
　　维护负责人: Justin Swanhart
　　更多信息: http://code.google.com/p/shard-query/
MySQL必备工具第九位: mk-archiver
　　随着列表体积的日益增大，查询指令生效时间也每况愈“长”。响应时间不理想的干扰因素当然很多，但如果我们已经对各个角度实施了优化，那么最后仍然制约性能表现的瓶颈所在就是列表的规模了。将庞大列表中的各行内容进行归档操作能够有效缩短查询指令的响应时间。
　　除非列表内容并不重要，否则大家千万不能贸然删除其中的内容行。归档也需要技巧，因为首先数据不能缺失、列表也不能过分锁定以免影响访问，还要注意归档操作不能导致MySQL及服务器的超载。我们的目标是让整个归档过程稳定可靠，除了缩短查询响应时间外不产生任何负面效果。mk-archiver 能够帮我们达到愿望。
　　mk-archiver有两条基本工作要求，第一是归档对象必须能够被识别。举例来说，如果列表中存在日期列，而且一般来说只有几年之内的数据有实际价值，那么在这几年之前的数据行可以进行归档。另外，必须具备一套惟一的索引系统以帮助mk-archiver 工具进行定位，而不必扫描整个列表中的内容行。扫描一套巨型列表在时间及经济方面的成本都相当高昂，因此关键指数及特定的SELECT语句在避免整体扫描方面至关重要。
　　在实际应用当中，mk-archiver 会自动处理各类技术细节。大家需要做的只是告知该工具哪个列表需要归档、如何识别可归档的内容行以及将这些行归至何处。如果需要的话，也可以将这些行剪切至另一个新列表中，或者是以书面的形式生成一个转储文件，方便日后需要的时候另行导入。一旦熟悉了这款工具的用法，其中的大量细微调节选项能够帮我们实现各种特殊的归档要求。此外，mk-archiver 具备嵌入式端口，因此它可以在未经代码修正的情况下解决诸多复杂的归档需求。
　　下载地址: http://maatkit.org/get/mk-archiver
　　维护负责人: Daniel Nichter and Baron Schwartz
　　更多信息: http://maatkit.org/ | http://code.google.com/p/maatkit/


MySQL必备工具第十位: oak-security-audit
　　大家最后一次全面审核自己MySQL服务器安全性是在什么时候?如果答案是“从来没有”，其实也不必担心，因为从不搞安全检查的群体相当庞大。许多企业提供安全审核服务，但除非在审计之后不存在任何大规模变更，否则我们MySQL环境的安全性应该得到定期的检查。
　　外部威胁是执行MySQL安全审核的一大重要原因，但内部威胁，尤其是来自现任或前任雇员的因素往往更加危险，因为他们目前(或曾经)具备信任和权限。安全性在隐私性信息的保障(例如医疗及健康保险方面)方面同样不容忽视，必须尽力阻止意外访问(例如登录至生产服务器而非开发服务器)或者第三方程序与系统之间的交互。
　　对于那些希望增进安全性的用户来说，oak-security-audit大有可为，它是一款免费的开源工具，能够应对基本的MySQL安全审核。它不需要进行任何设置，将其运行于自己的MySQL服务器之上，它就会打印出一份关于账户、账户权限、密码、一般改进方案以及潜在风险的建议报告，例如推荐暂时禁用网络访问。以下是报告中的部分内容：
　　-- Looking for anonymous user accounts(寻找匿名用户账户)
　　-- -----------------------------------
　　-- Passed(未发现问题)
　　--
　　-- Looking for accounts accessible from any host(寻找能够从任何主机实施访问的账号)
　　-- ---------------------------------------------
　　-- Found 1 accounts accessible from any host.
　　Recommended actions:
　　RENAME USER 'msandbox'@'%' TO 'msandbox'@'';
　　(找到1个此类账户。建议操作:
　　将用户名 'msandbox'@'%' 重命名为 'msandbox'@'';)
　　oak-security-audit的工作重点在于MySQL的安全性方面，因此它并不能代替一套完整的、由技术人员提出的安全审核方案，但它作为第一道防线能够起到相当了不起的防护作用，而且操作简单。大家可以将其固化进cron指令，每周按时运行，并将生成的报告通过电子邮件发送给自己并加以审阅。
　　下载地址: http://openarkkit.googlecode.com/svn/trunk/openarkkit/src/oak/oak-security-audit.py
　　维护负责人: Shlomi Noach
　　更多信息:
　　http://openarkkit.googlecode.com/svn/trunk/openarkkit/doc/html/oak-security-audit.html
　　原文链接：
　　http://www.infoworld.com/d/data-management/10-essential-mysql-tools-admins-168018?page=0,0