2010-02-05 Fri
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 ...
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控制。
（未完待续）
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被移除的机制（参照前文介绍）。
（未完待续）
SemiSyncReplication是Google提供的一个MySQL patch，作用在于保证至少有一个slave完成了数据同步。
安装的过程很简单，但是要找对路。这里提供一个传送门，看完就会编译安装了：
http://www.realzyy.com/?p=178
SemiSyncReplication需要的MySQL源码包为mysql-5.0.37.tar.gz；需要的patch为mysql-5.0.37_semisync.patch。其他的patch可以不打，但是如果选择mysql-5.0.37-patches来打补丁的话，那么记得要再打上http://www.realzyy.com/?p=178最后提到的那个小补丁。
配置也很简单，主要是三个参数：
master：
rpl_semi_sync_enabled = 1 #configures a master to use semi-sync replication.
rpl_semi_sync_timeout = 10000000 #the timeout in milliseconds for the master.
slave：
rpl_semi_sync_slave_enabled = 1 #configures a slave to use semi-sync replication. The IO thread must be restarted for this to take effect.
要特别注意rpl_semi_sync_timeout这个参数，官网推荐的设置10太短了。我测试了一下，将slave上的replication线程停掉，master上面执行更新操作并不会出现明显的block现象。如果想让master和slave时时刻刻保证一致，那么rpl_semi_sync_timeout就需要设置得很大，至少在DBA能察觉异常之前，不允许master单方面进行更新操作。
在经历了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的外延与内涵，来适应这种变化，是我们共同努力的方向.
在这篇文章里，给大家简单介绍一下本人对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开源项目创始人）进入淘宝好几个月了，今天是他第一次讲解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终于让我觉得不那么鸡肋了。
InnoDB在接受MySQL线程调用时，有一个并发线程的检查机制，通过innodb_thread_concurrency参数进行控制。如果参数设置大于0，则表示检查机制开启，允许进入的线程数就是参数的值。等于0则禁用并发检查。
在新的MySQL线程调用Innodb接口前，Innodb会检查已经接受的请求线程数，如已经超过innodb_thread_concurrency设置的限制，则该请求线程会等待innodb_thread_sleep_delay微秒后尝试重新请求，如果第二次请求还是无法获得，则该线程会进入线程队列休眠。重试两次的机制是为了减少CPU的上下文切换的次数，以降低CPU消耗，这和Oracle中latch的spin机制是同样的道理。如果请求被Innodb接受，则会获得一个次数为innodb_concurrency_tickets(默认500次)的通行证，在次数用完之前，该线程重新请求时无须再进行前面所说innodb_thread_concurrency的检查。
上述检查逻辑在源码storage/innobase/srv/srv0srv.c(Innodb很多参数都可以在该文件中找到定义)的srv_conc_enter_innodb函数中，有兴趣的可以仔细阅读一下，代码比较浅显，不难理解。另外，如果是一个已经持有lock的线程，则通过调用srv_conc_force_enter_innodb函数可以无视该检查，这是为了避免线程长时间持有锁影响性能，且可能增加死锁的机率。除此之外，slave线程也是有无视检查直接通行的权限。
简单思考一下上述机制，可以得出一个初步的推论：在数据库并发请求较小的情况下，从性能上来说禁用检查机制应该是更好的，毕竟执行检查机制本身也需要加锁(Mutex)。当并发线程很高的情况下，则开启检查机制对性能更有利。至于具体innodb_thread_concurrency设置为多少，可能就需要在不同的条件下实际的做一下测试了，不同的硬件环境，不同的MySQL版本和Innodb版本，应该都会有一些区别。
源代码中对于innodb_thread_concurrency参数的注释如下：
/* The following controls how many threads we let inside InnoDB concurrently:
threads waiting for locks are not counted into the number because otherwise
we could get a deadlock. MySQL creates a thread for each user session, and
semaphore contention and convoy problems can occur withput this restriction.
Value 10 should be good if ...
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 ...
开发DBA周会中，丁原提出的问题：
DML语句中where子句中添加rownum alter session set nls_language=american;
SQL> create table test as select 1 as id from dba_objects where rownum < 10;
n 把表中的数据块dump出来
SQL> select distinct dbms_rowid.rowid_relative_fno(rowid) as file#,
2 dbms_rowid.rowid_block_number(rowid) as block#
3 from test;
FILE# BLOCK#
---------- ----------
4 988
SQL> alter system dump datafile 4 block 988;
System altered.
n 查看trace文件，其中的部分数据如下：
Block header dump: ...
热爱挑战，是我的简历里的必列项目， 也是我们的共同点
她喜欢Challenge我们，我们喜欢被她Challenge，忙碌的工作中被挑战是很刺激的事，活血 
有时候血都上头顶了
作者：Fenng 发布在 dbanotes.net. 
前几天从 Sourceforge 上的一篇文章了解到 Complemento 这个工具包，其中的 LetDown 用来做网站网络的压力测试，预防 DoS (拒绝服务)攻击还是不错的，起码可以熟悉一些常见的场景。另外，这个工具可以比较方便的嵌入到 Python 脚本中，用来做更大规模的压力测试(注意随意测试是有风险的)。
Complemento 的 HowTo 文档比较完备，可以用作参考。这个工具包现在也已经内置到 BackTrack 这个用作安全渗透的 Linux 发行版中了。
最近一两年，DDoS 攻击在国内现在更加"流行"而且商业目的明显，经常用做打击竞争对手的武器。当然现在也不只是打Web服务器，也可能会打打 DNS 什么的...
其实我非常好奇各个公司的技术人如何应对 DDoS 的，除了拼硬件，拼带宽，或许饭桌和钱是最好的防御手段。
--EOF--
BTW，Nessus 仍然是扫描系统漏洞的最佳工具，居家旅行...必备...
最近文章|Recent Articles
本站赞助商：豆瓣网
评论数(0)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/security/complemento_denial-of-service.html
DBA Notes 理念: 用简约的技术取得最大的收益...
最近一直在看中医，主要么，是调理肠胃兼气血。
发现自从吃了中药以后，每天吃饭都会比以前多很多，以前吃饭都不会添第二碗的，现在一般米饭要吃两碗了，而且，第一次哟，体重称的时候，超过60kg（当然是毛重了），以前都是56-58的。
看来中医还是很牛逼的，就是中药有点贵，基本上，一副中药分两次喝，每杯都和两岸的卡布奇诺价格差不多了。
继续中医。
推荐一本书，著名语言学家周有光先生的新作《朝闻道集》。包括梁文道在内，最近有很多人都在推荐这本书。
推荐这本书，不是因为周先生已经是一位105岁的老人，也不是因为他敢讲，这年头敢讲的人其实也少，网络上就有很多，我有的时候也很敢讲，关键在于，他讲的很有道理，都是些真知灼见，特别是他针对中国社会的批评具有难得的世界精神。
我以前曾推荐他的《语文闲谈》，还有《周有光百岁口述》：http://mumu6.blog.sohu.com/113361585.html
当当网关于《朝闻道集》的介绍: http://product.dangdang.com/product.aspx?product_id=20732729
梁文道的推荐：http://book.ifeng.com/psl/kjbfz/201002/0202_3554_1534072.shtml
http://book.ifeng.com/psl/kjbfz/201002/0203_3554_1535641.shtml
《南方人物周刊》采访：http://news.sina.com.cn/c/sd/2010-02-05/103219635742.shtml
《南方都市报》采访：http://epaper.nddaily.com/C/html/2010-01/24/content_999668.htm
凤凰卫视许戈辉名人面对面20100110周有光A
http://www.letv.com/ptv/vplay/501067.html
凤凰卫视许戈辉名人面对面20100110周有光B
http://www.letv.com/ptv/vplay/501070.html
凤凰卫视许戈辉名人面对面20100117周有光c
http://www.letv.com/ptv/vplay/512329.html
《凤凰大视野》生命的光芒.周有光http://www.56.com/u50/v_MjU4NzM3MTE.html
《小崔说事》：http://vsearch.cctv.com/plgs_play-CCTVNEWSprog_20071217_2587930_0.html?
Author:NinGoo posted on NinGoo.net
在oschina上闲逛，发现一款不错的os实时监控工具dstat，整合了vmstat, iostat, ifstat, netstat等常见os监控工具的优点，输出的结果简单直观，并且结果可以保存到csv文件，这样再写一个简单的perl脚本，就能将os的主要监控信息一次性全部抓取出来，保存到监控数据库中用于分析展示。试用了一下觉得非常不错，因此在这里分享一下这个用python写的工具。
$dstat ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 2 0 98 0 0 0| 80k 54k| 0 0 | 335B 381B|1297 1301 22 2 74 0 0 2| 0 416k| 621k 219k| 0 0 |1158 26k 23 3 72 0 0 2| 64k 484k| 11k 11k| 0 0 |1109 30k 21 3 75 0 0 2|4096B 416k| 77k 77k| 0 0 |2104 25k 29 4 66 0 0 2| 0 1240k| 996k 425k| 0 0 |1350 28k
$dstat -ta --output osstat.csv -----time----- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- date/time |usr sys idl wai hiq siq| read writ| recv send| in out | int csw 05-02 11:37:08| 2 0 98 0 0 0| 80k 54k| 0 0 | 335B 381B|1297 1301 05-02 11:37:09| 16 4 78 0 0 3| 0 1404k|1478k 939k| 0 0 |4316 33k 05-02 11:37:10| 20 2 76 0 0 2| 0 1144k|1109k 828k| 0 0 |5653 28k 05-02 11:37:11| 13 2 83 0 0 2| 0 588k|2590k 1684k| 0 0 |4256 23k
$dstat -h
Usage: dstat [-afv] [options..] [delay [count]]
Versatile tool for generating system resource statistics
Dstat options:
-c, --cpu enable cpu stats
-C 0,3,total include cpu0, cpu3 and total
-d, --disk enable disk stats
-D total,hda include hda and total
-g, --page enable page stats
-i, --int enable interrupt stats
-I 5,eth2 include int5 and interrupt used by eth2
-l, --load enable load stats
-m, --mem enable memory stats
-n, --net enable network stats
-N eth1,total include eth1 and total
-p, --proc enable process stats
-s, --swap enable swap stats
-S swap1,total include swap1 and total
-t, --time enable time/date output
-T, --epoch enable time counter (seconds since epoch)
-y, --sys enable system stats
--ipc enable ipc stats
--lock enable lock stats
--raw enable raw stats
--tcp enable tcp stats
--udp enable udp stats
--unix enable unix stats
-M stat1,stat2 enable external stats
--mods stat1,stat2
-a, --all equals -cdngy (default)
-f, --full expand -C, -D, -I, -N and -S discovery lists
-v, --vmstat equals -pmgdsc -D total
--integer show integer values
--nocolor disable colors (implies --noupdate)
--noheaders disable repetitive headers
--noupdate disable intermediate updates
--output file write CSV output to file
delay is the delay in seconds between each update
count is the number of updates to display before exiting
The default delay is 1 and count is unspecified (unlimited)
Related Articles
PermLink: http://www.ningoo.net/html/2010/dstat_os_monitor_tool.html
Add Comments(0) | Follow NinGoo@Twitter | Google Reader
