Taobao监控系统之改进——文件传输

在早些的时候,也包括我的书《构建Oracle高可用环境》中的16章,关于监控体系的介绍中,所有的案例都是采用scp从被监控的客户端上拷贝文 件到集中分析的Monitor上,类似这样的动作,如

scp $SOURCE_FILE $MONITOR:$TARGET_FILE

当客户端不多的情况下,这么做也是没有什么问题的,而且书写简单,一直在这么用。但是,当客户端的数量上去以后,在大量并发的情况下,有的时候就会 出现这样的错误:

ssh_exchange_identification: Connection closed by remote host
lost connection

查看crontab的日志,也可以看到有部分crontab调度失败:

Cron Job with pid: 2859224 Successful
Cron Job with pid: 3154900 Failed
Cron Job with pid: 3027512 Successful

Continue reading

用Perl的hash数组实现个性化监控

对于DBA来说,一个准确稳定的监控系统,不啻于一柄尚方宝剑。几十上百套系统,如果每天都靠人工来检查,工作量之大无法想象,而且人工也无法做到 实时捕获错误。

但是这么多数据库系统,每个库承载的压力不一样,对于整个系统的重要度也不一样,负责的DBA也不可能是同一个人。如果都按同样的KPI同样的门限 来做监控,则有些重要的系统可能无法准确的告警,有些不重要的系统却又会频繁误报。

比如系统的load,有些核心库由于采用了比较高端的硬件,即使一直在20~30左右都是正常的,而一些边缘的库则可能超过5就比较危险了,所以对 于load,不同的库必须设置不同的检查门限。 Continue reading

淘宝网DBA团队成功组织举办首届中国互联网数据库技术论坛(华东站)

2010年6月19号, 淘宝网DBA团队组织举办的首届中国互联网数据库技术论坛(华东站)在杭州市文二路391号西湖国际科技大厦裙楼2层淘宝网百花谷会议室如期举行。本次技 术论坛我们邀请了华东地区具有代表性的互联网企业包括eBay、盛大、网易、斯凯网络、前程无忧网、久游游戏及阿里巴巴集团旗下各子公司(阿里巴巴 B2B、淘宝网、支付宝、阿里云)的嘉宾, 一起讨论分享互联网行业数据库技术架构的发展变化历程和经验。 Continue reading

LVS & MySQL NDB Cluster

章文嵩博士(LVS开源项目创始人)进入淘宝好几个月了,今天是他第一次讲解LVS的实现原理。作为DBA的一员,终于近距离膜拜了大牛。
讲解的内容就不具体介绍了,在LVS 官方网站上面可以找到。PPT的内容和网站上基本上一样,只是讲解人是章博士本人。我在这整理一下自己的理解,不对请大家指正。 ^_^

组成LVS最重要的部分有三个:请求分发服务器、处理服务器、共享存储。 Continue reading

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

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错误呢? Continue reading

MySQL Timeout解析

“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 the server waits for activity on a noninteractive connection before closing it.
net_read_timeout
The number of seconds to wait for more data from a connection before aborting the read.
net_write_timeout
The number of seconds to wait for a block to be written to a connection before aborting the write. Continue reading

详解MyISAM Key Cache(后篇)

在前两篇(前篇中篇) 中,分别介绍了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的大小可以动态的改变 Continue reading

详解MyISAM Key Cache(中篇)

前篇中 介绍了Key Cache的基本机制,并且介绍了Key Cache的LRU算法。作为对LRU算法的改进,MyISAM还提供了另一个缓存算法:“Midpoint Insertion Strategy”。本文将重点介绍该算法的原理和配置。

1. 相关参数

该策略涉及的参数有:key_cache_division_limitkey_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值) Continue reading

详解MyISAM Key Cache(前篇)

本文将分为前、中、后三篇,分别介绍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队列的头部。 Continue reading

InnoDB之Dirty Page、Redo log

在InnoDB中,buffer pool里面的dirty page一方面可以加快数据处理速度,同时也会造成数据的不一致(RAM vs DISK)。本文介绍了dirty page是如何产生,以及InnoDB如何利用redo log如何消除dirty page产生的数据不一致。

  1. 当事务(Transaction)需要修改某条记录(row)时,InnoDB需要将该数据所在的page从 disk读到buffer pool中,事务提交后,InnoDB修改page中的记录(row)。这时buffer pool中的page就已经和disk中的不一样了,我们称buffer pool中的page为dirty page。Dirty page等待flush到disk上。
    dirty_pages Continue reading