DBA@Taobao

北京团队mysql DBA招聘

Mon, 08 Feb 2010 16:26:00 +0800

岗位描述：mysql DBA开发支持，负责跟进北京团队的各产品开发项目招聘人数：1人工作地点：北京技能要求：精通/熟悉MySQL数据库的运行机制和体系架构精通mysql SQL优化熟练掌握数据库设计理论熟悉linux操作系统的使用 ...

mysqldump意外终止的原因以及解决方法

Mon, 08 Feb 2010 16:26:00 +0800

mysqldump是非常重要的MySQL备份工具。然而在长年累月的使用过程中，TAOBAO多次出现了因mysqldump意外终止而导致备份失败的情况。以下是我们经常遇到的问题： 1、Lost connection to MySQL server at 'reading initial communication packet'：这个主要是因为DNS不稳定导致的。如果做了网络隔离，MySQL处于一个相对安全的网络环境，那么开启skip-name-resolve选项将会最大程度避免这个问题。 2、Lost connection to MySQL server at 'reading authorization packet'：从MySQL获取一个可用的连接是多次握手的结果。在多次握手的过程中，网络波动会导致握手失败。增加connect_timeout可以解决这个问题；然而增加connect_timeout并不能防止网络故障的发生，反而会引起MySQL线程占用。最好的解决办法是让mysqldump重新发起连接请求。 3、Lost connection to MySQL server during query：这个问题具备随机性，而淘宝MySQL的应用场景决定了我们无法多次备份数据以便重现问题。然而我们注意到这个问题一般会在两种情况下会发生。一种是mysqldump **** | gzip ****；另外一种是mysqldump **** > /nfs-file 注意，不管是gzip还是nfs都有一种特点，那就是它们影响了mysqldump的速度。从这个角度思考，是不是mysqldump从MySQL接受数据包的速度不够快导致Lost connection to MySQL server during query错误呢？为了定位到问题，我搭建了一个测试环境： test@192.168.0.1：3306 CREATE TABLE `test` ( `id` bigint(20) NOT NULL auto_increment, `b` varchar(2000) default NULL, `c` varchar(2000) default NULL, `d` ...

MySQL Timeout解析

Mon, 08 Feb 2010 16:26:00 +0800

"And God said, Let there be network: and there was timeout" 在使用MySQL的过程中，你是否遇到了众多让人百思不得其解的Timeout？那么这些Timeout之后，到底是代码问题，还是不为人知的匠心独具？本期Out-man，讲述咱们MySQL DBA自己的Timeout。先看一下比较常见的Timeout参数和相关解释： connect_timeout The number of seconds that the mysqld server waits for a connect packet before responding with Bad handshake. interactive_timeout The number of seconds the server waits for activity on an interactive connection before closing it. wait_timeout The number of seconds ...

InnoDB Double write

Mon, 08 Feb 2010 16:26:00 +0800

p { text-indent:28px; } 记得刚开始看InnoDB文档的时候，Double Write一节（其实只有一小段）就让我很困惑。无奈当时内力太浅，纠缠了很久也没弄明白。时隔几个月，重新来整理一下。涉及到的概念：Buffer Pool简称BP，Dirty Page，Log file，Flush，innodb tablespace。 1. 什么是Double Write 在InnoDB将BP中的Dirty Page刷（flush）到磁盘上时，首先会将Page刷到InnoDB tablespace的一个区域中，我们称该区域为Double write Buffer。在向Double write Buffer写入成功后，再择机将数据拷贝到正在的数据文件对应的位置。咋一看，这个过程有些多余 2. 为什么需要Double Write InnoDB中有记录（Row）被更新时，先将其在Buffer Pool（简称BP）中的page更新，并将这次更新记录到Log file中，这时候BP中的该page就是被标记为Dirty。在适当的时候（BP不够、系统闲置等），这些Dirty Page会被flush到磁盘上。试想，在某个Dirty Page（一般是16K）flush的过程中，发生了系统断电（或者OS崩溃），16K的数据只有8K被写到磁盘上，这种现象被称为（partial page writes、torn pages、fractured writes）。一旦partial page writes发生，那么在InnoDB恢复时就很尴尬：在InnoDB的Log file中虽然知道这个数据页被修改了，但是却无法知道这个页被修改到什么程度，和这个页面相关的redo也就无法应用了。举个例子：在InnoDB的log file中有如下Log： Log sequence number 0 4285149977 Log sequence number 0 4287355447 Log sequence number 0 4289260680 Log sequence number 0 4291279900 Log sequence number 0 4293359020 其中第1、3个Log修改了该page，但是在断电时，BP中该page只被flush了一部分。那么InnoDB是无法决定上面的Log是否应该被应用的。这时，数据就出现了不一致。所以，Log file的有效应用，前提是InnoDB的数据文件中的Page是一致的。简而言之，Double ...

分布式之后的变化

Mon, 08 Feb 2010 16:26:00 +0800

在经历了2009年的分布式启步之后，经过改造的数据库系统性能得到极大的提升，但这个变化仍然不构成今天这篇文章的主题，我想要说的是另外一方面的变化，这个变化在某种程度上影响着当前DBA的角色变化问题。在分布式数据库时代，开发DBA的开发支持工作相比于以前，会有更多的系统思考问题的机会，会结合应用来设计量身定做的分布式数据库系统，如果一个DBA对业务有着深刻的理解，深刻理解数据库原理，既具有整体性的架构思维，又有一些关键细节把握能力的时候，设计一套分布式系统是水到渠成的事。对于开发支持的一些工作，比如SQL审核，表结构变更，数据订正，历史迁移，如果没有工具的支持，那做起来还是比较吃力的。这些方面，我们还有许多的道路要走，怎么样改变目前的现状。在分布式数据库时代，系统DBA的运维要求难度在某方面有所降低，整个应用因为在容错性方面做了比较多的努力，比如down掉一个数据库时，对于整个应用系统的健康运行影响较小,运维的压力相对减少。相比于集中式的数据库环境下的运维，在另外一个层面运维难度又有所增加，第一，运维的机器数量呈几何指数的增长，由于大量采用低端机器，集群中某个机器出问题的概率大增，可能每天都会处理好几次down机的事故;第二，对监控系统的要求增加，对10台数据库的监控与对1000台数据库的监控方法肯定会有许多差异的,我们的监控系统也应该具有分布式的能力,避免单点；第三，系统精细化运维能力需要提升，采用大量低端pc server,在机房的设计上要尽可能的下功夫，可以参考一下google的机房建设的论文，pc server的硬件在不同应用上的定制化以尽量节能，CPU个数是否存在严重过多的情况,pc server上装的linux os是否有优化过，不同版本的os是否存在稳定性问题，os上跑的mysql是否已经足够的优化。另外一个方面的变化，是来自于我们的分布式数据层的开发人员。他们开发的数据层是前端应用与底层数据库集群的中间纽带,是整个分布式数据库系统最重要的组成部份。而开发分布式数据层的开发人员自然会成为核心的核心，他们对于许多底层技术的理解相当的深入。与他们讨论问题时，倍感知识的匮乏。大部份DBA由于缺乏长期的开发经验的积累，双方沟通时，有时会比较吃力。从长远的方向来讲，分布式数据库系统将会越来越依重于分布式中间件产品，整个应用系统的健康也会更依赖于开发人员的能力。在某种程度上，分布式数据库时代的DBA的重要性，会低于集中式数据库时代的DBA重要性。但对于公司而言，整个公司的技术实力有了质的飞跃,大大节约了成本,也掌握了未来的主动权。如何扩大DBA的外延与内涵，来适应这种变化，是我们共同努力的方向.

详解MyISAM Key Cache(后篇)

Mon, 08 Feb 2010 16:26:00 +0800

p { text-indent:28px; } 在前两篇（前篇、中篇）中，分别介绍了Key Cache的基本原理（LRU和Midpoint Insertion Strategy）。最后，将介绍一些相关的参数、状态参数和命令。 Key Cache的配置很灵活，可以针对全局配置，还可以针对某个单独数据表分配Key Cache的大小；如果一个数据表某部分的索引块被访问的非常频繁（较之其他索引块），那么可以配置Midpoint Insertion Strategy达到最大的利用率(参考)。 1. 如何配置Key Cache的大小 #配置文件my.cnf key_buffer_size=50*1024*1024 另外，Key Cache的大小可以动态的改变 2. 给数据表划分单独的Key Cache 例如：划分一块128K的Key buffer空间，指定数据表t1的Key cache放在里面。最后演示了如何删除这个特定的Key buffer空间。 SET GLOBAL hot_cache.key_buffer_size=128*1024; CACHE INDEX t1 IN hot_cache; SET GLOBAL hot_cache.key_buffer_size=0; 3. 预先载入某些数据表的索引 LOAD INDEX INTO CACHE t1, t2 4. 关于Key Cache的使用情况观察 Flush现象 mysql> show status like "key%"; +------------------------+----------+ | Variable_name ...

详解MyISAM Key Cache(中篇)

Mon, 08 Feb 2010 16:26:00 +0800

p { text-indent:28px; } 在前篇中介绍了Key Cache的基本机制，并且介绍了Key Cache的LRU算法。作为对LRU算法的改进，MyISAM还提供了另一个缓存算法：“Midpoint Insertion Strategy”。本文将重点介绍该算法的原理和配置。 1. 相关参数该策略涉及的参数有：key_cache_division_limit、key_cache_age_threshold 2. 原理介绍 (1) 该策略将前面的LRU队列（LRU Chain）分成两部分，hot sub-chain和warm sub-chain。并根据参数key_cache_division_limit划分，总保持warm sub-chain在这个百分比以上。默认情况key_cache_division_limit是100，所以默认时候只有warm sub-chain,即LRU Chain。 (注：Multiple Key cache情况，每个key cache都有对应的key_cache_division_limit值) (2) 在warm sub-chain中的某个block如果被访问（Access）次数超过某个值时候，就将该block放到hot sub-chain的底部。 (3) 在hot sub-chain中的block会随着每一次的hit调整位置，hit越多，越接近底部。在顶部停留时间过长就会被降级到warm sub-chain中，而且是warm sub-chain的顶部（很可能很快就会被移出key cache）。 (4) Hot sub-chain中的顶部的block停留时间超过一个阈值后就会被降级到warm sub-chain。这个阈值由参数key_cache_age_threshold决定。具体的计算方法是：设N为key cache中的block个数，如果在最近的（N*key_cache_age_threshold/100）次访问中，key cache顶部的block仍然没有被访问到，那么就会被移到warm sub-chain的顶部。 (5) 默认情况key_cache_division_limit = 100，这时只有只有一个Chain，所以不使用该策略。即退化的Midpoint Insertion Strategy是LRU算法。 3. 如何使用Midpoint Insertion Strategy 我们可以通过配置key_cache_division_limit、key_cache_age_threshold的值来控制。参数key_cache_division_limit控制了Key Cache Chain中warm sub-chain的百分比，如果你的Index Block中明显有30%是非常Hot（较之其他的Block更加被常常访问），那么你可以设置你的warm sub-chain长度为70%，剩余30%作为hot sub-chain。参数key_cache_age_threshold定义了warm sub-chain中的block被移除的机制（参照前文介绍）。（未完待续）

详解MyISAM Key Cache(前篇)

Mon, 08 Feb 2010 16:26:00 +0800

p { text-indent:28px; } 本文将分为前、中、后三篇，分别介绍MyISAM Key Cache的一般机制、Mid-point strategy、状态、参数和命令。 “Cache为王”，无所不在。为了最小化磁盘I/O，MyISAM将最频繁访问的索引块（“index block”）都放在内存中，这样的内存缓冲区我们称之为Key Cache，它的大小可以通过参数key_buffer_size来控制。在MyISAM的索引文件中（MYI），连续的单元（contiguous unit）组成一个Block，Index block的大小等于该BTree索引节点的大小。Key Cache就是以Block为单位的。 1. MyISAM如何使用Key Cache 当MySQL请求(读或写)MyISAM索引文件中某个Index Block时，首先会看Key Cache队列中是否已经缓存了对应block。如果有，就直接在Key Cache队列中进行读写了，不再需要请求磁盘。如果是写请求，那么Key Cache中的对应Block就会被标记为Dirty（和磁盘不一致）。在MyISAM在Key Cache成功请求（读写）某个Block后，会将该Block放到Key Cache队列的头部。如果Key Cache中没有待请求（读或写）的Block，MyISAM会向磁盘请求对应的Block，并将其放到Key Cache的队列头部。队列如果满了，会将队列尾部的Block删除，该Block如果是Dirty的，会将其Flush到磁盘上。我们看到MyISAM维护了一个LRU（Least Recently Used）的Key Cache队列。队列中的Dirty Block会在Block被踢出队列时Flush到磁盘上。 2. 图解下图展示了访问Index Block的过程：（黑色部分为磁盘中的Index文件） 3. 并发访问 Key Cache中的index Block是可以被并发访问的（Shared access ），下面是一些规则：多个没有更新操作的session可以并发同一个block buffer 多个session同时访问某一个block buffer，如果某个session是update操作，则优先访问多个session如果都需要进行block replacement，是可以并发操作。（从index file中读取block更新到key cache，但是key cache已满，需要删除一些block buffer的操作叫做block replacement） 4. 补充说明 Key cache中的Block大小可能和索引文件中的Index Block大小不同，可能是大于、小于、等于中的任何一种，但是一般都是成倍数关系的。Key Cache的block大小由参数Key_cache_block_size控制。（未完待续）

Oracle索引abc

Mon, 08 Feb 2010 16:26:00 +0800

在这篇文章里，给大家简单介绍一下本人对Oracle索引的理解，如有不妥的地方，请不吝指教。本文只讲最最平常最最简单的索引，就是以create index ix on tx(a,b,c);形式创建的索引，而不讲位图索引、反向键索引、倒序索引、基于函数的索引等等。其实呢，只要是基于B树的索引，不管是在Oracle, Mysql，还是其它数据库中，原理应当都是一样的。索引最重要的一个性质应该就是有序，索引中的每一项，是从左到右，从小到大，以严格的顺序排列好的。下面的讨论都以上面的索引ix(a,b,c)为例。把这棵索引的叶子节点画到纸上，大概是这样的： a1 a2 a3 ...... an b1 b2 b3 ...... bn c1 c2 c3 ...... cn 上面这个3×n的矩阵，每一列代表了一条记录，同时这一列记录，也对应了表里的唯一一条记录。当然，在Oracle里，对于non-unique索引，需要补上rowid，才是真正唯一的。上面的索引相当于create unique index ix on tx(a,b,c,rowid); 我们把这个细节忽略掉。把每一列看作一个向量,vi = (ai, bi, ci)，有序的含义就是： vi < vj iff i ＜ j; vi < vj这么定义： (ai ＜ aj) or (ai = aj and bi ＜ bj) or (ai = aj ...

LVS & MySQL NDB Cluster

Mon, 08 Feb 2010 16:26:00 +0800

章文嵩博士（LVS开源项目创始人）进入淘宝好几个月了，今天是他第一次讲解LVS的实现原理。作为DBA的一员，终于近距离膜拜了大牛。讲解的内容就不具体介绍了，在LVS官方网站上面可以找到。PPT的内容和网站上基本上一样，只是讲解人是章博士本人。我在这整理一下自己的理解，不对请大家指正。 ^_^ 组成LVS最重要的部分有三个：请求分发服务器、处理服务器、共享存储。典型的Web集群并不需要共享存储，只有请求分发服务器和处理服务器，如下图所示：如果完成请求需要基于数据，那么共享存储就是LVS必须的组件了。LVS邮件服务器集群如下所示：目前能应用于LVS的MySQL集群只能是NDB Cluster，因为MySQL众多的存储引擎中，只有NDB Cluster实现了共享存储的功能。在NDB Cluster中，SQL Node相当于处理服务器，Data Node相当于共享存储。LVS可以让应用程序的开发更加简单，开发人员并不需要知道执行SQL的数据库服务器到底是哪一个，但是可以获得自己想要的数据。而NDB Cluster提供的数据拆分和扩容功能，保证了数据库的可扩展性。美中不足的是，NDB Cluster的性能实在太差。即使LVS负载均衡做得很好很强大，NDB Cluster也会成为瓶颈。根据我的观察发现，LVS的架构非常适用于CPU-bound的应用场景。虽然共享存储的引入使得LVS能够支持有状态的连接，但是LVS并不适用于IO-bound的应用。因为不管负载如何均衡，最终瓶颈在于共享存储之上。而共享存储如何拓展，LVS并不关心。也许只有NDB Cluster提升了IO性能之后，LVS才能真正在MySQL方面应用起来。非常感谢章博士的分享，NDB Cluster终于让我觉得不那么鸡肋了。