技术细节

  • 前篇介绍了MySQL如何从SQL语句转换成一个内部对象。本文是前篇的延续,将更加详细的介绍WHERE语句对应的Item对象。

    1. Item对象@MySQL Internal

    (建议阅读:The Item Class@MySQL Internals Manual,忽略本小结)

    MySQL Internals Manual较为详细的介绍了Item对象。Item对象经常被称作”thingamabob”( A thingamabob is a noun used to describe items that either you can’t remember the name of or that don’t actually exist.)。Item是一个类,每一个Item实例都:(1)代表一个SQL语句里的对象;(2)有取值;(3)有数据类型指针。

    下面列出的的SQL相关的对象都是一个Item对象,或者继承至Item:(1)一段字符; (2)数据表的某列; (3)一个局部或全局变量; (4)一个存储过程的变量; (5) 一个用户参数; (6)一个函数/存储过程(这包括运算符+、||、=、like等) 。例如下面的SQL语句: (more…)

  • 使用pt-stalk诊断MySQL问题

    ·

    在MySQL服务器出现短暂(5~30秒)的性能波动的时候,一般的性能监控工具都很难抓住故障现场,也就很难收集对应较细粒度的诊断信息。另外,如果这种波动出现的频率很低,例如几天才一次,我们也很难人为的抓住现场,收集数据。这正是pt-stalk所解决的问题。

    pt-stalk是Percona-Toolkit的一部分(其前身是Aspersa的一部分)。安装Percona-Toolkit后,可以通过man pt-stalk了解如何使用该工具,本文的介绍是man pt-stalk的一个子集,强烈建议直接阅读man pt-stalk。额外的,本文将提供pt-stalk示例命令可供参考。

    1. 使用pt-stalk

    pt-stalk --collect-tcpdump --function status \
    --variable Threads_connected --threshold 2500 \
    --daemonize -- --user=root --password=YOURPASSWORD

    上面的命令表示,让pt-stalk后台运行(–daemonize),并监视SHOW GLOBAL STATUS中的Threads_connected状态值,如果该值超过2500,则触发收集主机和MySQL的性能、状态信息。pt-stalk会每隔一秒检查一次状态值,如果连续5次满足触发条件,则开始收集。

    –collect-tcpdump表示除了收集基本信息外,还将额外使用tcpdump收集当时的网络包,类似的还可以使用–collect-gdb等。

    (more…)
  • 在使用和配置过程中,还是遇到了一些波折,这里分享、记录一下。

    1. 模块mod_proxy_html可以做些什么

    使用Apache内置的mod_proxy的Proxypass可以帮助我们实现基本的反向代理功能。但是,代理返回的结果页面包含的链接并不会被重写,所以如果被代理的Server返回的是绝对地址,用户则无法正确访问这些链接。例如:

    我们有反向代理服务器http://myproxy.taobao.org/,而内网有需要代理的服务器http://internalserver.taobao.org/,通过基本的反向代理指令Proxypass

    ProxyPass ^/proxy_internal/(.*)$ http://internalserver.taobao.org/$1

    可以完成基本的反向代理任务,但是如果internalserver.taobao.org返回的HTML代码中有如下链接,则客户端则无法正常链接到目标页面了:

    <a href=”/test/index.html”>Sample Link</a>

    因为,客户端点击该链接时会定向到http://myproxy.taobao.org/test/index.html,而资源实际是在http://internalserver.taobao.org/test/index.html上。

    Apache自带的mod_proxy无法解决这个问题,开源的第三方模块mod_proxy_html为此而生。经过代理服务器的HTML可以通过该模块做一次替换,从而变成可以正常访问的URL(上例中会把/oninternal/index.html替换成/proxy_internal/test/index.html)。
    (more…)

  • TCP/IP重传超时–RTO

    ·

    概述:本文讨论主机在发送一个TCP数据包后,如果迟迟没有收到ACK,主机多久后会重传这个数据包。主机从发出数据包到第一次TCP重传开始,RFC中这段时间间隔称为retransmission timeout,缩写做RTO。本文会先看看RFC中如何定义RTO,然后看看Linux中如何实现。本文旨在分享:当遇到了TCP层问题改如何去查找、阅读文档,该如何去在Linux源码中寻求答案。

    1. 起源

    在分析MySQL Semi-sync故障时,我们用Tcpdump+Wireshark(感谢淘宝雕梁)抓住当时的网络包传送细节,观察到了一次TCP重传最终导致了Semi-sync超时:

    第一次传输 13:55:11.893291 master => slave Binlog pos:319890197 重传: 13:55:12.094596 master => slave Binlog pos:319890197

    看到两次传送间隔约201毫秒,即第一次传输201毫秒后,还没有收到ACK响应,TCP认为传输超时,开始重传。

    疑问:host和host之间的RTT大约是0.5毫秒,为什么第一次重传需要等200毫秒?(我希望是<20ms)socket程序可以配置吗RTO吗?TCP有参数可配置RTO吗?

    2. Google/书籍/RFC

    翻开TCP/IP详解找到关于TCP Retransmission章节,较详细的介绍TCP的超时机制,书中是个概述,于是又找到RFC1122。

    RFC1122的4.2.2.15和4.2.3.1都介绍了Retransmission Timeout的处理(说来惭愧,这是第一次阅读TCP相关RFC)。

    RFC中搜索Retransmission发现RFC 793 1122 2988 6298都有对重传算法、和初次重传超时的描述。于是开始阅读这个四个RFC,耗时约2小时,了解了大致的重传超时算法。 (more…)

  • 也说快速关闭MySQL/InnoDB

    ·

    如果用的引擎是InnoDB,每次敲下mysqladmin -uroot -p shutdown关闭数据库的时候,总是很难预测这个命令会执行多久,实际经验表明,短则五秒,长则三十分钟一小时都有可能。也分享一下我的经验吧。

    1. 为什么InnoDB关闭会慢?

    事实上,并不是每次关闭InnoDB都很慢的。Why?InnoDB较之MyISAM,一个重要特性是InnoDB会在内存中开辟一个Buffer Pool来存储最近访问的数据块/索引块,使得下次再次访问这个块时速度能够很快。当InnoDB对需要修改数据块的时候,会先记录修改日志,然后直接对Buffer_Pool中的数据块的操作。记录日志是顺序写,对数据块的操作是内存操作,这让InnoDB在很多场景下有这很好的速度优势。 (more…)

  • 编写一个shell脚本,做一些事;改进这个脚本,更好做这件事;再改进这个脚本,帮自己做些其他的事情;再改进这个脚本帮助其他人做一些事……

    简单的脚本处理,一般使用变量$0 $1 $2 …就可以依次获得全部参数,还可以通过$#获得这个脚本一共有多少个参数。如果你需要处理的情况(或者分支)更多的时候,这个方法就不凑效了,这时候,就可以考虑使用getopts了(man getopts)。

    (more…)