June 29, 2010
分享FreeBSD 8.0的十四条优化策略
"【51CTO独家特稿】笔者目前是一位外企linux/unix系统工程师与项目实施工程师,而FreeBSD一直作为我们企业内部的开发服务器,具有稳定和高效的特点。本文根据笔者经验总结了十四条FreeBSD的优化策略。如无其它,以下所指FreeBSD均指FreeBSD 8.0_release。\n一、提高ports安装速度\nFreeBSD中的ports安装工具默认工具是用fetch,下载时经常出现龟速现象。为了提高ports安装速度,我推荐axel工具。相关make.conf文件配置步骤如下:\ncd /usr/ports/ftp/axel make install #修改/et/make.conf vi /etc/make.conf #加入以下内容 FETCH_CMD=axel FETCH_BEFORE_ARGS= -n 10 -a FETCH_AFTER_ARGS= DISABLE_SIZE=yes MASTER_SITE_OVERRIDE?=\\ http://ports.hshh.org/${DIST_SUBDIR}/\\ …"
June 27, 2010
MySQL 备份(推荐方法)
"一般来说,你有两种可供选择的备份MySQL的方式—-mysqldump 或者mysqlhotcopy。\nmysqldump可以备份各种类型的数据表,但是mysqlhotcopy 只适合 备份MyISAM和ISAM的数据表。所以使用mysqlhotcopy之前,你必须确认你的数据表是不 是有其他的存储引擎(storage engines)的。\nHow To:\nmysqldump -u root -p*** DBNAME | gzip -f\u0026gt;/backup/dbname.’date +%w’.dump.gz\nmysqlhotcopy DBNAME -u root -p *** /backup\n**两者速度:**因为 mysqlhotcopy会直接拷贝存储数据的文件,所以其速度是依赖于磁盘操作的速度,较之mysqldump要快些。下面是两种方式备份同一个数据的 时候的时间消耗比较:\nmysqldump 耗时22分39秒(gzip 压缩后文件大小为747M.) mysqlhotcopy 耗时6分07秒(tar gzip打包压缩后文件大小为1014M.) 参考: …"
June 27, 2010
图解”How MySQL Replication Works”
"replication by orczhou, on Flickr\n在使用MySQL的应用中,如果你的MySQL Server压力逐渐增大,在应用层优化已经到了一定瓶颈时,那么你应该首先考虑 MySQL Replication。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。\n如何同步\n主库将所有的更新操作,写入二进制日志。\n从库运行”IO线程”(Slave IO Thread)读取主库的二进制日志。\n从库运行”SQL线程”(Slave SQL Thread)执行IO线程(Slave IO Thread)读取的日志中的SQL,从而保持和主库的一致。\n如何分配请求\n目前,这部分需要在应用层实现。\n执行更新SQL(UPDATE,INSERT,DELETE)时,请求主库。\n执行查询SQL(SELECT)时,请求从库。\n所以,当你的应用(Application)SELECT请求所占的比率越大,那么Relication就会越有效。"
June 27, 2010
关于MySQL explain 中的ID(推荐)
"Explain ID详解\n含义:select查询的序列号,是一组数字,表示的是查询中执行select子句或者是操作表的顺序。\nid的情况有三种,分别是:\nid相同表示加载表的顺序是从上到下。 id不同id值越大,优先级越高,越先被执行。 id有相同,也有不同,同时存在。id相同的可以认为是一组,从上往下顺序执行;在所有的组中,id的值越大,优先级越高,越先执行。 再看一个查询计划的例子:\n执行顺序依次为 4 -\u0026gt; 3 -\u0026gt; 2 \u0026gt; 1 \u0026gt; NULL\n第一行:id列为1,表示第一个select,select_type列的primary表示该查询为外层查询,table列被标记为,表示查询结果来自一个衍生表,其中3代表该查询衍生自第三个select查询,即id为3的select。[select d1.name……]\n第二行:id为3,表示该查询的执行次序为2(4→3),是整个查询中第三个select的一部分。因查询包含在from中,所以为derived。[select id,name from t1 where other_column=”]\n第三行:select列表 …"
June 26, 2010
LVS & MySQL NDB Cluster
"章文嵩博士(LVS开源项目创始人)进入淘宝好几个月了,今天是他第一次讲解LVS的实现原理。作为DBA的一员,终于近距离膜拜了大牛。 讲解的内容就不具体介绍了,在LVS 官方网站上面可以找到。PPT的内容和网站上基本上一样,只是讲解人是章博士本人。我在这整理一下自己的理解,不对请大家指正。 ^_^\n组成LVS最重要的部分有三个:请求分发服务器、处理服务器、共享存储。\n典型的Web集群并不需要共享存储,只有请求分发服务器和处理服务器,如下图所示: [][2] 如果完成请求需要基于数据,那么共享存储就是LVS必须的组件了。LVS邮件服务器集群如下所示: [][3] 目前能应用于LVS的MySQL集群只能是NDB Cluster,因为MySQL众多的存储引擎中,只有NDB Cluster实现了共享存储的功能。 在NDB Cluster中,SQL Node相当于处理服务器,Data Node相当于共享存储。LVS可以让应用程序的开发更加简单,开发人员并不需要知道执行SQL的数据库服务器到底是哪一个,但是可以获得自己想要的数 据。而NDB Cluster提供的数据拆分和扩容功能,保证了数据库的可扩 …"
June 26, 2010
mysqldump意外终止的原因以及解决方法
"mysqldump是非常重要的MySQL备份工具。然而在长年累月的使用过程中,TAOBAO多次出现了因mysqldump意外终止而导致备份 失败的情况。 以下是我们经常遇到的问题:\n1、Lost connection to MySQL server at ‘reading initial communication packet’: 这个主要是因为DNS不稳定导致的。如果做了网络隔离,MySQL处于一个相对安全的网络环境,那么开启skip-name-resolve选项将会最大 程度避免这个问题。\n2、Lost connection to MySQL server at ‘reading authorization packet’: 从MySQL获取一个可用的连接是多次握手的结果。在多次握手的过程中,网络波动会导致握手失败。增加connect_timeout可以解决这个问题; 然而增加connect_timeout并不能防止网络故障的发生,反而会引起MySQL线程占用。最好的解决办法是让mysqldump重新发起连接请 求。\n3、Lost connection to MySQL …"
June 26, 2010
MySQL Timeout解析
"“And God said, Let there be network: and there was timeout” 在使用MySQL的过程中,你是否遇到了众多让人百思不得其解的Timeout? 那么这些Timeout之后,到底是代码问题,还是不为人知的匠心独具? 本期Out-man,讲述咱们MySQL DBA自己的Timeout。\n先看一下比较常见的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 …"
June 26, 2010
分布式之后的变化
"在经历了2009年的分布式启步之后,经过改造的数据库系统性能得到极大的提升,但这个变化仍然不构成今天这篇文章的主题,我想要说的是另外一方面的变 化,这个变化在某种程度上影响着当前DBA的角色变化问题。\n在分布式数据库时代,开发DBA的开发支持工作相比于以前,会有更多的系统思考问题的机会,会结合应用来设计量身定做的分布式数据库系统,如果一个DBA 对业务有着深刻的理解,深刻理解数据库原理,既具有整体性的架构思维,又有一些关键细节把握能力的时候,设计一套分布式系统是水到渠成的事。对于开发支持 的一些工作,比如SQL审核,表结构变更,数据订正,历史迁移,如果没有工具的支持,那做起来还是比较吃力的。这些方面,我们还有许多的道路要走,怎么样 改变目前的现状。\n在分布式数据库时代,系统DBA的运维要求难度在某方面有所降低,整个应用因为在容错性方面做了比较多的努力,比如down掉一个数据库时,对于整个应用 系统的健康运行影响较小,运维的压力相对减少。相比于集中式的数据库环境下的运维,在另外一个层面运维难度又有所增加,第一,运维的机器数量呈几何指数的 增长,由于大量采用低端机器,集群中某个机器出问题的 …"
June 26, 2010
框架设计规范的新方向
"微软的框架设计规范{#h.u8}是 设计的准则,它期望所有的微软类库和独立开发者都能够遵循这一准则。随着每个.NET框架版本的发布,以及在行业内的测试,它们的版本也得到了精化。通过 Cwalina与Abram所著的《框 架设计规范》第二版{#t.q.}的发布,我们可以看到微软在今后几年的发展方向。\n或许最令人惊讶的事实是日渐增长的对于测试驱动开发和依赖注入的重视。在可重用框架的场景下,通过测试驱动开发设计出的框架是真实可用的,而不是简 单地推理。他们希望这样可以反过来杜绝某种趋势,那就是过度复杂地设计一些根本不会用到的功能。\n谈到这一问题,就不得不指出的是微软当前正在推动的一个活动,即针对所有库的第1个版本进行最低限度设计。这不同于在第一次就要试图将所有事情做 对,微软推荐在最开始只需要满足需求中绝对需要的特性。Abrams和Cwalina建议在最初并不需要考虑扩展性,只有到需求变得非常清晰的时候,才在 后一个版本中考虑。从某个方面来讲,这是微软旧有传统的回归,它只会在第三个版本中提供真正完成的应用程序。\n在其它领域,微软则完全没有改变。他们仍然强调所谓的“基坑成功(Pit of …"
June 26, 2010
牺牲一致性来换取分布式架构的可伸缩性
"统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案,常常要牺牲一个方面来换取另一个方面。随着系统变得越来越大、越来越复杂,越来越多关于 如何构建应用的传统智慧正在受到挑战。比如说,去年3月在伦敦召开的QCon会议上,Dan Pritchard谈论了eBay的架构。他的介绍随后得到了很多的报道,其中一个主要的结论就是eBay不使用事务,用数据一致性上的损失来换取系统整 体伸缩性和性能上相当大的改进。\nInfoQ接着Dan Pritchard在QCon会议上的谈话与他继续讨论,以获得更多信息:\n为什么eBay不使用事务,或者为什么可以决定不采取应用级事务?\n我们并非一概不使用事务。我们只是不使用跨物理资源的事务,因为它会造成多个组件之间出现依赖。组件可以是应用服务器和数据库。(例如在客户端控制 的事务中,)一个客户端的失败会长久地阻塞数据库资源、超出我们的忍受程度。我们也不使用分布式事务,因为让应用依赖于多个数据库会降低客户端实际的可用 性。相反,我们选择缺少事务的设计,并加入失效模式,失效模式可以使客户端甚至在发生数据库可用性问题的时候也能继续进行。\n应用级事务总是有些问题。只 …"