<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>SQL部落 &#124;MySQL文档、MySQL资料、MySQL下载&#124;MySQL优化&#124;MySQL培训、解决方案 &#124; MySQL 技巧&#124;MySQL资源 &#124;opensolaris 资料 &#124; Oracle 资料&#124;Oracle 优化</title>
	<atom:link href="http://www.mysqlsystems.com/feed" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlsystems.com</link>
	<description>国内领先的 MySQL 技术网站 &#124; MySQL中国用户组成员</description>
	<lastBuildDate>Thu, 19 Apr 2012 10:42:56 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
		<item>
		<title>Oracle 用户组Leader大会</title>
		<link>http://www.mysqlsystems.com/2012/04/oracle-leaders-summit.html</link>
		<comments>http://www.mysqlsystems.com/2012/04/oracle-leaders-summit.html#comments</comments>
		<pubDate>Wed, 18 Apr 2012 03:19:42 +0000</pubDate>
		<dc:creator>hironics</dc:creator>
				<category><![CDATA[业界动态]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2195</guid>
		<description><![CDATA[年初时，有幸代表MySQL中国用户组参加了在Oracle全球总部举行的用户组Leader大会。 下面是大会对参加此会议的中国Leader的采访。]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2012/04/oracle-leaders-summit.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>MHA自动Failover过程解析</title>
		<link>http://www.mysqlsystems.com/2012/03/figure-out-process-of-autofailover-on-mha.html</link>
		<comments>http://www.mysqlsystems.com/2012/03/figure-out-process-of-autofailover-on-mha.html#comments</comments>
		<pubDate>Sat, 31 Mar 2012 06:42:54 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[failover]]></category>
		<category><![CDATA[MHA]]></category>
		<category><![CDATA[Replication]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2172</guid>
		<description><![CDATA[MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用。近期，在田老师的推动下，开始一步步深入了解这个HA方案，并也计划在公司线上尝试部署。下面的东西是这段时间的学习笔记和个人理解，没有具体的实战经验，只是人为测试模拟故障的发生，通过日志来分析MHA背后的自动切换过程。 首先，介绍下它的一些特点，以及为什么用它，在哪种场合更适合用它。 1. 10-30s实现master failover（9-12s可以检测到主机故障，7-10s可以关闭主机避免SB，在用很短的时间应用差异日志） 2. 部署简单，无需对现有M-S结构做任何改动（至少3台，保证切换后仍保持M-S结构） 3. 支持手动在线切换（主机硬件维护），downtime几乎很短0.5-2s 4. 保证故障切换后多从库数据的一致性 5. 完全自动化的failover及快速复制架构恢复方案（一主多从） 6. 恢复过程包括：选择新主库、确认从库间relay log差异、新主库应用必要语句、其他从库同步差异语句、重新建立复制链接 上面是我对wiki里面信息的剪辑归纳。在实际测试中，手动切换与自动切换所需时间都能控制在他所描述的范围呢。在一主多从的情况下，当主库故障，需要提升一台从库作为新的主库，其余从库则需要重新指向新的主库建立复制，亲身过这个恢复过程的同志，应该记忆深刻，又费时又费事的（想想有3-4个从库在哪儿等着你0_0&#8230;）。可能你会说不是有这样的结构吗：M-m-S(n)，大M掉了，可以马上指向小m，但是这个结构也存在致命的问题，如果是小m遇到点什么意外，后面拖家带口的S可就瞎眼了，这也是为什么大家都很渴望的一个特性（global transaction ID）出现的原因。MHA可以很好的帮我们解决从库数据的一致性问题，同时最大化挽回故障发生后的数据。 接下，我们了解下MHA方案里的两个角色。 node host：原有的MySQL复制结构中的主机，至少3台，即1主2从，当master failover后，还能保证主从结构；只需安装node包。 manager server：运行监控脚本，负责monitoring 和 auto-failover；需要安装node包和manager包。 MHA manager server可以是专门的一台机器，这样所有的业务线上的MHA都可以由其统一监控，配置文件也便于统一管理；或者为了节省机器，可以从现有复制架构中选一台“闲置”从库作为manager server，比如：某台从库不对外提供读的服务，只是作为候选主库，或是专门用于备份。 下面有价值的部分开始了，我将带着大家一步一步的分析整个failover的过程，使大家对MHA有个清晰了解，如果是我们自己的脚本又是如何去实现的呢。 背景介绍 主从结构： 10.0.1.48(master) &#124; &#8212;&#8212;&#8212;&#8211; 10.0.1.37(slave1) &#8212;&#8212;&#8212;&#8211; 10.0.1.38(slave2) Sysbench主机：10.0.1.49:: master manager monitor 在sysbench压测机上持续对主库发起更新，通过关闭其中一个主库的IO_THREAD，造成个从库之间的跟新差异，最后暴力kill掉mysqld进程，引起自动master failover发生。 模拟故障 Step1: 10.0.1.49 # sysbench &#8211;mysql-host=10.0.1.48 Step2: 10.0.1.37 (1min [...]]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2012/03/figure-out-process-of-autofailover-on-mha.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>DRBD使MooseFS跑得更安全</title>
		<link>http://www.mysqlsystems.com/2012/02/drbd-makes-moosefs-really-be-ha.html</link>
		<comments>http://www.mysqlsystems.com/2012/02/drbd-makes-moosefs-really-be-ha.html#comments</comments>
		<pubDate>Tue, 07 Feb 2012 06:45:58 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[DRBD]]></category>
		<category><![CDATA[HA]]></category>
		<category><![CDATA[heartbeat]]></category>
		<category><![CDATA[moosefs]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2168</guid>
		<description><![CDATA[之前写过两篇关于MooseFS的相关概念以及操作管理的BLOG，我们可以看到MFS一些好的地方，比如：通过copy数来保证数据的可靠存，当MFS系统中有个别chunkserver宕机发生，也不会影响应用的正常使用；同时，相比ext3它还能节省存储空间。这里说到，“可靠”，并非这个系统就真的如想象一样，和NFS相比的确，多份copy确实可靠了不少，但是它们都有一个共同的问题，那就是主控server的单点问题。MFS系统中，即便有metalogger server的这个作为master的角色，但问题依然存在。下面就说说使用中的体会。 问题：当mfsmaster主机发生问题，按照MFS系统的提供的故障切换方法，mfsmetalogger主机会被提升为mfsmaster，继续提供服务，服务是能够提供，但是，如果你真的实际操作过，就知道后续你要做多少动作。当你的mfsmaster发生变化，意味着你的主机IP已经改变，那么相应所有挂载的client端，必须要重新连接新的master_host重新挂载一次。你可能会认为以下方法可行。 理想中的方法： 1. 将mfsmount命令中的选项-H的参数采用DNS域名的方式，这样域名始终不变而是IP发生变化，这对于使用者来说是透明的，是这样吧？ 2. 有的人可能会说，不用这么麻烦，我们可以调换原mfsmaster与mfsmetalogger的IP不就行了吗？但是，实际工作中，你没权这么改，也不能这么做，公司中这些资源都是由专属部分统一管理，你方便了但是给别的同事带来了麻烦。 下面说说目前我们采用的方法，这个方法在我们看来，所使用的技术都是熟悉的而且是可控的；在和田老师商量之后，采用DRBD来做mfsmaster端的高可用。 先来说说上面提到的方法1为什么不行，原因很简单，因为在client端，mfsmount命令执行挂载后，它cache住的是mfsmaster主机的IP地址，这是根源所以在，导致你不能简单靠域名来解决这个变的问题。既然，知道了根源，那么我们的解决办法应该，放到mfsmaster端来思考方法。要求提供mfsmaster服务的主机IP不变，那么自然我们想到采用虚IP这种方式，VIP在两台真实主机间随时准备故障切换，但整个服务对外始终呈现的是一个IP。能够实现这个的需求的，目前市面上流行的方法也不少，比如：keepalive、heartbeat。keepalive从来没接触过，听不少人说keepalive的使用相比heartbeat要简单很多，计划现学又需要时间弄的差多吧又需要一定的精力，有点懒了也不想弄那么多了，把眼前这点东西看住了就不小了。加之之前，所有的MySQL高可用都是用DRBD搭建的，对heartbeat还是比较熟悉的，经过测试之后，最后选择了DRBD+Heartbeat+MFS来实现MooseFS系统的完全高可用。目前DRBD这个方案，也有点我不太特别舒服的地方，就是heartbeat故障切换使用style 1的，并不是基于服务监控，而是通过主机整体网络环境状况判断故障切换，细想想这其中还是有一些不妥的问题。搭过DRBD+Heartbeat+MySQL的，对于记下来要所的MFS的DRBD应用就没什么难度，下面就一些个人觉得有必须提的一些配置。 DRBD 将原有MFS系统中的mfsmetalogger角色去掉，而是将原mfsmetalogger变成现有mfsmaster的备机。 Heartbeat # cat /etc/ha.d/haresources mfsmaster-a drbddisk::r0 Filesystem::/dev/drbd0::/mfsconf  VIP MFSMaster #cat /etc/ha.d/resource.d/MFSMaster /usr/sbin/mfsmaster -c /mfsconf/mfsmaster.cfg $1 MooseFS 将原来/etc目录下的mfsmaster.cfg、mfsexports.cfg配置文件，以及/var/lib/mfs目录下的数据文件，存储到drbd分区上；至于lock文件，在1.7以后将被废除使用，目前我们是1.6的版本，我没有将LOCK_FILE存到drbd分区上，之前在测试的时候，有试过的，当启动mfsmaster服务时，提示不能找到lock文件。其实，当你去查看默认的LOCK_FILE的存放位置时，并不存在的（一个服务启动时，需要创建的这个socket文件，有什么用途呢？除了通信意外，&#8230;）。 #vi mfsmaster.cfg EXPORTS_FILENAME = /mfsconf/mfsexports.cfg DATA_PATH = /mfsconf 目前，我们的MooseFS主要提供内部备份使用，并没有任何线上使用，这套MFS的HA方案完全符合我们的需要，虽说仅用于备份的MFS，也无需多么高的可靠性，但是这最大的方便是当mfsmaster故障后可以减少很多后续人为的操作，减少了我们你的工作量。:)]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2012/02/drbd-makes-moosefs-really-be-ha.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>MySQL为什么要引入Thread Pool的线程处理模式</title>
		<link>http://www.mysqlsystems.com/2011/10/why-oracle-introduces-thread-pool-into-mysql.html</link>
		<comments>http://www.mysqlsystems.com/2011/10/why-oracle-introduces-thread-pool-into-mysql.html#comments</comments>
		<pubDate>Sat, 29 Oct 2011 06:29:28 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[connection pool]]></category>
		<category><![CDATA[thread mode]]></category>
		<category><![CDATA[thread pool]]></category>
		<category><![CDATA[thread_cache_size]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2155</guid>
		<description><![CDATA[从5.5.16开始，在MySQL的商业化版本中将Thread Pool作为plugin提供官方功能支持。在之前的版本中，线程处理模式包括两种：no-threads(单线程处理，多用于debug)、one-thread-per-connection（每个请求对应一个线程，目前被作为默认值）；在支持thread pool功能的版本中，thread_handling则需设置为dynamically-loaded。 最初当我看到说MySQL会支持Thread Pool这个功能的时候，我很疑惑，心想不是已经有thread_cache_size来提高线程的重复利用率，为嘛还要弄个专门的池子呢。之前，有听过connection pool，是在一些应用服务器端来支持类似的功能。我们都知道，当应用发起一个对数据库的操作时，在整个应用中是一个不小的开销，从建立连接之初，CPU要给它划分一定的thread stack，然后进行用户身份认证，建立上下文信息，最后请求完成，关闭连接，同时释放资源，可以称的上是秒级的过程，在高并发的情况下，将给系统带来巨大的压力更不能保证性能。所以，采用线程重用，减小这部分的消耗。MySQL通过thread_cache_size这参数，来设置可以重用线程的个数，在生产过程中，通过一些状态参数来把握合适的重用线程数，比如：threads_cached可以知道目前有还有多少线程可用，通过threads_created参数的增长趋势可以判断是否需要加大需要cache住线程的个数。需要清楚的是目前，线程处理的模式是，每个请求就对应一个线程的模式，这就意味着当有成千上万的请求时，对应的也就需要成千上万的线程来相应这些请求，那么此刻问题就很明显了，系统的资源是有限的，必须要保证thread_number*thread_stack不能超过可以使用的内存资源，还要考虑CPU的调度能力，I/O的处理能力，这是一种很粗放的资源使用方式，不是吗？同时，这种不加控制的处理方式，也会带来资源使用的冲突，大量互斥锁的出现，性能的急剧下降。通过Thread Pool来控制确保不会超过服务器的最大负载能力，避免出现服务无响应，导致宕机的惨状。（既然在应用服务器端有connection pool，为什么还需要在数据库服务器端实现thread pool呢？） 在看了一些相关的资料和对于Thread Pool实现方式讨论之后，我目前最深刻的体会就是，控制，一个平衡的控制。没错，你可以说thread pool是为了提升性能，难道不是吗？我们所做的一切都是为了性能。但，如何让性能维持在一个稳定的状态，这才是当我们得到一个好的预期之后，我们更需要关心的重点。更多时候，系统的性能会随着并发的升高而随着或急或慢的下降，其实，我们更需要采用一种方式去做的时刻动态调整来为维持系统的稳定性能，减少波动，这对于我们的应用来说才会获得一个理想的性能。 我觉得，这更像是在跑马拉松，在整个过程中，不会因为你某一端跑的比别人快，最后一定就会第一个通过终点，而是取决于你以一个合理的速度在不断超越每一个身边的人，当你发现落后太多时适当提高速度，当体力透支时适当减慢速度，合理分担体能，保持稳定高效的前进。 关于Thread Pool的功能细节，大家可以去看手册5.5中相关章节的内容在7.11.6 The Thread Pool Plugin。本来想写一下，因为自己并没有亲自用过，就是放个中文在这里也没有多大用，想想还是算了，浪费大家时间（p.s.: Blog不应该是单纯的翻译，而且更不应该翻译的内容可能自己都没有用过的，只是可怜的how to install &#38; configure ）。 至于自己的体会上面说出来，还有没有说出来的都来自于Mikael Ronström的Blog，他是Thread Pool的开发人员，为了方便大家他近期又将之前一周的7/8篇文章整理到了一起供大家阅读和讨论，Here。]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/10/why-oracle-introduces-thread-pool-into-mysql.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>MySQL Tuning之浅析I/O优化</title>
		<link>http://www.mysqlsystems.com/2011/10/mysql-tuning-for-io.html</link>
		<comments>http://www.mysqlsystems.com/2011/10/mysql-tuning-for-io.html#comments</comments>
		<pubDate>Mon, 24 Oct 2011 09:22:04 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[IO]]></category>
		<category><![CDATA[scheduler]]></category>
		<category><![CDATA[tuning]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2149</guid>
		<description><![CDATA[目前web的应用大多都以I/O密集型为主，而存储技术的发展远没有计算机中其他系统发展迅速，尽管也有不少高端存储设备，但是价格的昂贵，不是一般大众能享受的起的。而基于现状更多是我们使用一般SAS盘结合应用使用不同的RAID组合，来实现我们平民化存储，为了得到更好的性能，那么和I/O相关的调整优化是必不可少的。 对于我们数据库调优来说，磁盘io优化是首屈一指的调优重点，我们都知道木桶原理，短板绝对整体的好坏，而数据库系统中这个短板正是由于我们使用的硬件设备里最弱的磁盘所导致。很多时候，我们会发现系统中io累得要死，而CPU却在那里空闲等待，主要是由于io执行响应时间太长，处理读写的速度远远赶落后于CPU的处理速度，这时我们会尽可能的让操作放到内存中进行，由磁盘与CPU的关系，转变成内存与CPU的关系。但是，我们始终不能回避磁盘io的弱点，优化是必须的。 对于数据库在日常应用中的特点，我们可以有很多想法。 1. 随机读写的负载可以通过增加硬盘的个数实现扩展。 2. 对于顺序读写带来的压力，可以通过选择带宽相对高一些的磁盘来解决。 3. RAID 5和RAID 10都是不错的原则对于数据库应用来说。 4. 当然，基于自身业务的关键程度与成本双重考虑，Fusion-io卡（读与写的性能俱佳）和SSD（优秀的随机读），都未尝不是一个理想的选择。 5. 在操作系统中，I/O Scheduler的调度模式选择deadline对于数据库应用是有利的。命令：echo deadline &#62; /sys/block/&#60;dev&#62;/queue/scheduler 6. 操作系统中nr_requests参数，可以提高系统的吞吐量，似乎越大越好，但是该请求队列的也不能过大，因为这样会消耗大量的内存空间。该值的调整需要综合多处因素，比如： 文件系统、sheduler类型、io的特点。命令： echo xxx &#62; /sys/block/&#60;dev&#62;/queue/nr_requests，nr_requests的大小设置至少是/sys/block/&#60;dev&#62;/device/queue_depth的两倍，所以，修改nr_requtests的时候要注意。 7. 系统目录/sys/block/&#60;dev&#62;/queue下还有一个预读的参数read_ahead_kb，这个参数增大只会对顺序读的操作有提升，而数据库这类应用中多数是随机读；通过命令hdparm -t /dev/sda{,,}可以测试修改后预读的效果。]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/10/mysql-tuning-for-io.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>MTU值的调整导致MySQL复制异常</title>
		<link>http://www.mysqlsystems.com/2011/10/mtu-result-in-mysql-replication-issue.html</link>
		<comments>http://www.mysqlsystems.com/2011/10/mtu-result-in-mysql-replication-issue.html#comments</comments>
		<pubDate>Fri, 21 Oct 2011 13:26:01 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[mtu]]></category>
		<category><![CDATA[Replication]]></category>
		<category><![CDATA[scp]]></category>
		<category><![CDATA[stalled]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2147</guid>
		<description><![CDATA[今天的故事简单有趣，你绝对没有遇到过。当我们把网卡的MTU值从默认的1500，调整为3000/6000/9000后，复制十分诡异，搞得我云里来雾里去的，先记录下： 以下命令可以动态修改MTU值及时生效，和查看状态的一些命令： shell&#62; ifconfig eth1 mtu 3000 up (永久生效可以增加MTU=XXXX到配置文件ifcfg-ethN中) shell&#62; ip link list eth1 shell&#62; ethtool shell&#62; ping -s xxxx IP (当增大MTU后，-s值大于1500的ping都会失败) 增大MTU后，复制正常，但scp发生stalled. 增大MTU后，复制异常，scp发生stalled. 异常表现为： 1. 从库只复制过去了一条建库与语句； 2. show processlist和show slave status查看主从状态均正常，但是，当停止主库，show slave status时从库没有异常反应，只有当stop slave,再start slave，从库io_thread_running变为No; 3. 主库show processlist时观察到有Writing to net状态出现，然后该线程被关闭，从库各状态无任何异常。 4. 其中一次在6000复制失败后，将MTU值恢复为1500，突然发现从库有语句被复制过来并执行。 &#8212;- MTU (Maximum Transfer Unit) &#8212; 最大传输单元，之所以调整，是考虑到当有大数据量传输时，减少数据包的分段操作，以提高传输速度。后来发现，不能单方面调整，还需要考虑整个网络环境中各个interface的MTU，都需要保持一致才行，否则丢包是难免的。]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/10/mtu-result-in-mysql-replication-issue.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>&#8220;ERROR 1235 (42000): skip-innodb is defined&#8221;的误导</title>
		<link>http://www.mysqlsystems.com/2011/07/skip_innodb-mislead-for-troubleshooting.html</link>
		<comments>http://www.mysqlsystems.com/2011/07/skip_innodb-mislead-for-troubleshooting.html#comments</comments>
		<pubDate>Wed, 20 Jul 2011 12:15:57 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[error-1235]]></category>
		<category><![CDATA[Innodb]]></category>
		<category><![CDATA[skip-innodb]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2139</guid>
		<description><![CDATA[ERROR 1235 (42000): Cannot call SHOW INNODB STATUS because skip-innodb is defined 以上这个醒目错误提示，如果你是一个细心专业的DBA的话，可能这辈子你也遇到这样的问题，而我不是，毛躁马虎加上不专业，已经成了我的标签，所以，“幸运的”本人才遭遇到这个Error。究竟怎么一个动作导致出现这样的错误呢，下面简单描述下。 发现监控数据库的my.cnf中的关于Innodb的配置都保持默认状态，而之前只运行cacti倒是没有什么影响，它的表都是MyISAM的。因为前段采用了zabbix监控，而它的表都采用Innodb的表结构。其实，很多参数都可以在线调整，之后将变化的添加到my.cnf即可，无需修改my.cnf再重启mysqld，因为zabbix的信息收集量不小，导致binlog增长很快，磁盘容量报警，之前expire_log_days又设置为0。我觉得监控系统没必要开启binlog日志功能，所以想将log-bin注释掉不记录二进制日志，所以，必须要重启mysqld。在改动的这些参数里面，我调整了redo log的大小，将默认的10M增大到256M，也就是这么一改，重启后，扑哧让我惆怅了好一会。 当我执行show engine innodb status\G（现在我很喜欢看它的输出信息:-）之后，Error 1235就出现了，突然有点惊慌。刚开始我并没去查看error-log（这是一个非常不好的习惯，重启关闭mysqld是必须要tail -f error-log，确定正常关闭正常启动，是否有异常发生），而是跟着上面那个错误提示去找问题。风风火火的就去查看my.cnf里面是否有加skip-innodb，但是不可能呀，如果有那么之前zabbix的表也不会被创建为innodb类型的呀，后来查看error log才发现，是下面的原因导致的错误： InnoDB: Error: log file /data/db/mysql/ib_logfile0 is of different size 0 10485760 bytes InnoDB: than specified in the .cnf file 0 134217728 bytes! 这下明白了吧，接着我又执行show engines，发现Innodb的选项是disable的。怎么回事呢？我认为，当mysqld启动时，Innodb检查发现当前iblogfileX大小和配置文件中设置的不一致时，就会报错，但是mysqld仍然能够正常启动，但是Innodb会被自动skip掉。正常的操作应该是，首先正常关闭mysqld，然后将之前的iblogfile文件移走，最后在启动mysqld，初始化期间，如果发现iblogfile不存在会按照配置文件中指定大小重新创建一组新的。有时，以上这个错误的发生，不iblogfile的大小导致的，还可能是你的ibdata的大小问题导致的，Baron也遇到过上面的错误提示，就因为ibdata大小的设置问题。Innodb的加载是一个十分细致的过程，我们必须要谨慎小心。 这些都是不细心和操作不规范造成的；先想，记录，测试，线上，这才是一个专业负责任的做法，其实，这些田老师一开始就这么教给我，可我&#8230;都快一年了，还是没有养成这个良好的工作方式。 继续努力吧，我以不再年轻，差距还是很大。]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/07/skip_innodb-mislead-for-troubleshooting.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Heartbeat+DRBD+MySQL Replication故障处理</title>
		<link>http://www.mysqlsystems.com/2011/07/heartbeat-drbd-mysql-replication-troubleshooting.html</link>
		<comments>http://www.mysqlsystems.com/2011/07/heartbeat-drbd-mysql-replication-troubleshooting.html#comments</comments>
		<pubDate>Mon, 18 Jul 2011 14:33:02 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[DRBD]]></category>
		<category><![CDATA[heartbeat]]></category>
		<category><![CDATA[Replication]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2127</guid>
		<description><![CDATA[不久前的一次机房网络故障，再一次对我们在Heartbeat+DRBD+MySQL数据库架构运维水平的一个考验，之前不止一次的测试与线上部署，还有之后大言不惭的关于该架构组件的所谓深入理解，在这一次不经意的意外面前又是“很囧”的收场，慌张呀！这次断网导致H-D-M全线异常，真是千载难逢，都让我们赶上啦lol: 下面就把这次的小幸运小幸福和大家分享下，以下是按照问题处理的先后顺序依次讲述。 - MySQL Replication同步异常 当发生网络故障一个小时后，从库io_thread和主库的连接被中断，抛出错误提示：[ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)，没想到竟遇到了一个古董级的Bug，有点喜出望外了（心想，我也能遇到bug）。最后解决办法，只能拿备份重新做一遍主从。后来，好奇想查查，究竟是怎么导致这个问题，竟发现，从库relay log中的记录比主库binlog中的记录多了2条insert和1条update（0_0!!!&#8230;不合逻辑呀？！！）。 - DRBD状态异常 处理完数据库同步问题后，当时并没有去查看DRBD的状态，直到周一才发现出问题了，简单地通过命令cat /proc/drbd就可以查看，DRBD的状态是否正常。查看/var/log/messages知道网络故障导致DRBD发生脑裂，彼此都认为对方已经死了，然后自己都将角色作为Primary，并积极获取资源，当时的两端的连接状态都为StandAlone，角色都为Primary。在发生脑裂不久后原active node被heartbeat强制将系统重启，最后，原active node角色变为Secondary/Unknown，原standby node角色依然是脑裂时的Primary/Unknown，两端的连接状态，分别为WFConnection和StandAlone。解决方法如下： Step 1 - On New Secondary: # service heartbeat stop # service drbd stop # drbdadm create-md r0 # service drbd start # service heartbeat start [...]]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/07/heartbeat-drbd-mysql-replication-troubleshooting.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Innodb Crash Recovery恢复时间的飞跃</title>
		<link>http://www.mysqlsystems.com/2011/07/innodb-crash-recovery-jump-from-slow-to-fast.html</link>
		<comments>http://www.mysqlsystems.com/2011/07/innodb-crash-recovery-jump-from-slow-to-fast.html#comments</comments>
		<pubDate>Wed, 13 Jul 2011 04:24:18 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[crash]]></category>
		<category><![CDATA[Innodb]]></category>
		<category><![CDATA[performance]]></category>
		<category><![CDATA[recovery]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2103</guid>
		<description><![CDATA[之前没经历过漫长的crash recovery恢复过程，一是本身库中的数据量就不大，平时的业务量就不是很高，二是innodb_buffer_pool_size和innodb_log_file_size的大小平时设置的也不大。所以，对于意外导致innodb自动恢复时，经历的等待时间的长短没有什么深刻的体会。在浏览peter很早以前的文章时，看到当时大家是多么的无奈和痛苦，同时，在InnoDB没有对其作出改进之前，大家都在开动脑筋，配合各种参数尽可能的缩短故障恢复的时间。先来了解下，什么是Crash Recovery，它究竟都帮我们做了什么。 Innodb Crash Recovery 这也是InnoDB引擎的一个特点，当故障发生，重新启服务后，会自动完成恢复操作，将数据库恢复到之前一个正常状态。恢复进程会完成两步，第一步：检查redo日志，将之前完成并提交的事务全部重做；第二步：将undo日志中，未完成提交的事务，全部取消。那么，就仅仅做了这么两步为什么恢复过程会变得如此漫长呢？在InnoDB未对恢复速度做提升之前，MySQL的bug列表中，曾被提出了两个改进请求：Bug #29847和Bug #49535。 “民间办法”&#8212; 治标不治本 方法1：重启mysqld之前，暂时减小innodb_buffer_pool_size的大小，将innodb_flush_method=O_DIRECT临时注释掉，会缩短故障恢复的时间。 方法2：一开始就把my.cnf中参数innodb_log_file_size的大小设置的小些，该选项与恢复时间的长短有直接关系，但太小也会对性能造成影响。 “专业解决” &#8212; 改进代码 Bug #49535提到，在恢复期间重做redo日志时，检查可用内存的大小将消耗超过90%的CPU。恢复redo日志时，会在buffer pool中开辟一块空间，用来的将redo log从磁盘中读到内存当中，放到一个hash table里面，随着读出redo log的增加，这个hash table会不断增大，为了保证该空间不超过buffer pool的大小，所以，每读入一次redo log都要去遍历一遍hash table来获得其大小，显然效率低下而且很耗资源。解决办法是在hash table的结构中加入一个头字段来单独记录总的大小。 Bug #29847是由flush list过大导致。当每执行一条日志后，都会被插入到一个叫作flush list的列表中，也就是我们说的dirty page列表，正常情况下有跟新完成，那么新的跟新会被放到列表的前面，而当发生恢复时，每次跟新的记录都会按照之前LRU的顺序放到原来的位置，同时，不幸的是这个flush list又是一个古老的链表结构，每次插入的遍历痛苦，你懂得！flush list变的越长将消耗的时间就越久，所以，为什么之前提到，减小innodb_log_file_size的大小，能有效的缩短恢复时间，其实，是为了减少flush list的大小。解决办法是采用一种叫做红黑树（red-black tree）的数据结构，这个我还没有看明白:) 在pluin 1.0.7以后就没有恢复太久的问题了，为了提高性能完全可以尽可能的加大redo log的设置，InnoDB也保证了不会再有超长恢复等待的发生。 p.s.:除了peter，又发现一个很猛的人domas，有思想有深度。【此外，有种幻觉就是，MySQL圈里似乎日本技术要比中国技术强好多，Yasufumi Kinoshita、Yoshinori.Matsunobu、TokuDB(updated on 11/05/: 惭愧呀，一直以为这个牛x的引擎是日货，IT技术还是老美领先，这里是一个最近的pdf演讲稿关于TokuDB采用的Fractal Tree的详细介绍)；当然，国货里面，姜承尧也很不错哦。Just joking here 】]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/07/innodb-crash-recovery-jump-from-slow-to-fast.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>快速预热Innodb Buffer Pool的方法</title>
		<link>http://www.mysqlsystems.com/2011/07/quickly-warm-up-innodb-buffer-pool.html</link>
		<comments>http://www.mysqlsystems.com/2011/07/quickly-warm-up-innodb-buffer-pool.html#comments</comments>
		<pubDate>Mon, 11 Jul 2011 03:12:22 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[innodb_buffer_pool]]></category>
		<category><![CDATA[performance]]></category>
		<category><![CDATA[warmup]]></category>
		<category><![CDATA[XtraDB]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2093</guid>
		<description><![CDATA[当innodb_buffer_pool_size大到几十GB或是百GB的时候，因为某些日常升级更新或是意外宕机，而必须要重新启动mysqld服务的之后，就面临一个问题，如何将之前频繁访问的数据重新加载回buffer中，也就是说，如何对innodb buffer pool进行预热，以便于快速恢复到之前的性能状态。如果是光靠Innodb本身去预热buffer，将会是一个不短的时间周期，业务高峰时，数据库将面临相当大的考验，I/O的瓶颈会带来糟糕的性能。那么，该怎么办呢？于是大家便想出一些办法，最后Percona把这个需求，在XtraDB中最为一个新特性实现这个功能。 早期，Peter在实际的工作中总结了一些预热buffer pool的SQL语句，也就是通过人为模拟一些请求，尽可能地将我们所需的数据块和索引加载到内存中。 1. 加载主键索引 select count(*) from tbl where no_index_col=0; 2. 加载非主键索引 select count(*) from tbl where index_col like &#8220;%0%&#8221;; 3. 加载BLOB/TEXT列 select count(*) from tbl where blob_col like &#8220;%0%&#8221;； 4. 分段加载大表数据 select count(*) from tbl where id between 1 and 10000000 and no_index_col=0; 还有人使用blackhole引擎来进行预热操作，通过替换不同的索引字段进行排序查询，将所需数据加载。 create table temp_blackhole like tbl; alter table [...]]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/07/quickly-warm-up-innodb-buffer-pool.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>如何监控主从之间的延时:seconds_behind_master OR mk-heartbeat</title>
		<link>http://www.mysqlsystems.com/2011/06/two-methods-of-monitoring-slavelag-seconds_behind_master-or-mk-heartbeat.html</link>
		<comments>http://www.mysqlsystems.com/2011/06/two-methods-of-monitoring-slavelag-seconds_behind_master-or-mk-heartbeat.html#comments</comments>
		<pubDate>Tue, 28 Jun 2011 05:21:58 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[lag]]></category>
		<category><![CDATA[mk-heartbeat]]></category>
		<category><![CDATA[Replication]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2089</guid>
		<description><![CDATA[日常工作中，对于MySQL主从复制检查，一方面我们要保证复制的整体结构是否正常，另一方面需要检查主从数据是否保持一致。对于前者我们可以通过监控复制线程是否工作正常以及主从延时是否在容忍范围内，对于后者则可以通过分别校验主从表中数据的md5码是否一致，来保证数据一致，可以使用Maatkit工具包中的mk-table-checksum工具去检查。在这里，我只想讨论下关于如何检查主从延时的问题。 判断主从延时，通常有两个方法：1. Seconds_Behind_Master  vs  2. mk-heartbeat，下面具体说下两者在实现功能的差别。 方法1. 通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断，是否有发生主从延时。其值有这么几种： NULL &#8212; 表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No，而非Yes。 0 &#8212; 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。 正值 &#8212; 表示主从已经出现延时，数字越大表示从库落后主库越多。 负值 &#8212; 几乎很少见，我只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。 show slave status\G，该命令的输出结果非常丰厚，给我们的监控提供了很多有意义的参数，比如：Slave_IO_Running该参数可作为io_thread的监控项，Yes表示io_thread的和主库连接正常并能实施复制工作，No则说明与主库通讯异常，多数情况是由主从间网络引起的问题；Slave_SQL_Running该参数代表sql_thread是否正常，具体就是语句是否执行通过，常会遇到主键重复或是某个表不存在。下面就说到今天的重点Seconds_Behind_Master，该值作为判断主从延时的指标，那么它又是怎么得到这个值的呢，同时，它为什么又受到很多人的质疑？ Seconds_Behind_Master是通过比较sql_thread执行的event的timestamp和io_thread复制好的event的timestamp(简写为ts)进行比较，而得到的这么一个差值。我们都知道的relay-log和主库的bin-log里面的内容完全一样，在记录sql语句的同时会被记录上当时的ts，所以比较参考的值来自于binlog，其实主从没有必要与NTP进行同步，也就是说无需保证主从时钟的一致。你也会发现，其实比较真正是发生在io_thread与sql_thread之间，而io_thread才真正与主库有关联，于是，问题就出来了，当主库I/O负载很大或是网络阻塞，io_thread不能及时复制binlog（没有中断，也在复制），而sql_thread一直都能跟上io_thread的脚本，这时Seconds_Behind_Master的值是0，也就是我们认为的无延时，但是，实际上不是，你懂得。这也就是为什么大家要批判用这个参数来监控数据库是否发生延时不准的原因，但是这个值并不是总是不准，如果当io_thread与master网络很好的情况下，那么该值也是很有价值的。（就好比：妈&#8211;儿子&#8211;媳妇的关系，妈与儿子亲人，媳妇和儿子也亲人，不见得媳妇与妈就很亲。开个玩笑:-）之前，提到Seconds_Behind_Master这个参数会有负值出现，我们已经知道该值是io_thread的最近跟新的ts与sql_thread执行到的ts差值，前者始终是大于后者的，唯一的肯能就是某个event的ts发生了错误，比之前的小了，那么当这种情况发生时，负值出现就成为可能。 方法2. mk-heartbeat，Maatkit万能工具包中的一个工具，被认为可以准确判断复制延时的方法。 mk-heartbeat的实现也是借助timestmp的比较实现的，它首先需要保证主从服务器必须要保持一致，通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表，里面至少有id与ts两个字段，id为server_id，ts就是当前的时间戳now()，该结构也会被复制到从库上，表建好以后，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这个周期默认为1秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期去比较，复制过来记录的ts值与主库上的同一条ts值，差值为0表示无延时，差值越大表示延时的秒数越多。我们都知道复制是异步的ts不肯完全一致，所以该工具允许半秒的差距，在这之内的差异都可忽略认为无延时。这个工具就是通过实打实的复制，巧妙的借用timestamp来检查延时，赞一个！ 以上就是本人对这两个方法的理解，在这之前也和部落的lulu还有公司的田老师交流过，也希望大家来说说你们的理解。]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/06/two-methods-of-monitoring-slavelag-seconds_behind_master-or-mk-heartbeat.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>xtrabackup知多少</title>
		<link>http://www.mysqlsystems.com/2011/06/how-much-do-you-understand-xtrabackup.html</link>
		<comments>http://www.mysqlsystems.com/2011/06/how-much-do-you-understand-xtrabackup.html#comments</comments>
		<pubDate>Fri, 17 Jun 2011 14:10:28 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[hot backup]]></category>
		<category><![CDATA[innobackupex]]></category>
		<category><![CDATA[xtrabackup]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2080</guid>
		<description><![CDATA[最近小弄下Percona Xtrabackup，写脚本做测试，对这个世界唯一的开源免费（the world’s only open-source free）MySQL（the world’s most popular open source databases这句我也很喜欢 lol:）热备工具有了一些懵懂的认识，对于付费的InnoDB Hot Backup我们有了更欢乐的选择。Percona Xtrabackup工具主要有两部分构成，一个就是c写的xtrabackup命令，它又有多个版本，分别对应不同版本（5.0及以上）的MySQL/XtraDB以及InnoDB的差别（build-in or plugin），该命令只能备份InnoDB/XtraDB的数据文件；另一个是perl写的innobackupex的脚本，将xtrabackup命令包裹起来，让备份的过程更透明化更轻松，它会自行判断选择合适的xtrabackup工具，同时，它还能备份InnoDB对应的.frm文件以及MyISAM类型的库表；至于tar4ibd这个命令，未曾研究，看它的解释应该是一个打包InnoDB数据文件的工具。下面就具体说说这美妙的工作是如何高效工作的。 使用xtrabackup命令去备份和恢复一个数据库，一般会经历以下三步：1.备份；2.准备；3.恢复。 备份阶段（Backup Process） 大家之所喜欢这个工具，主要因为一是备份速度快，二是备份期间不影响业务的正常访问。那么它是如何做到的呢？备份开始后，会有两个线程，日志拷贝线程在后台运行，去拷贝iblogfile里面发生改变的文件块（changed block）将其拷贝到一个叫做xtrabackup_logfile的二进制文件中，一次以1MB大小进行拷贝，这在工具在是不可以调的，这时会有另一个数据拷贝的线程在前台去拷贝所有的数据文件（ibdata/ibd），它是以512byte为一页，作为每次拷贝的大小。当数据文件拷贝完成，则会关闭日志拷贝线程，同时生成一个xtrabackup_checkpoints的文件，来记录在数据拷贝期间，事务日志的更新状态，通过LSN(log sequence number)号去记录，当一次全备结束，from_lsn从0开始，last_lsn记录备份结束时刻完成的那点；当进行增量备份时，每次增量备份结束后，该文件的from_lsn的点因该对应于前一次备份结束后的last_lsn。 xtrabackup拷贝数据块是物理性的拷贝，而不像mysqldump是将数据逻辑性以sql语句的形式导出，显然前者要迅速很多；通过时刻扑捉事务日志的变化，而不是靠单纯加锁来保持数据的一致性，自然就不会对外来请求带来任何影响。 准备阶段（Prepare Process） 这个阶段其实，就是对备份的数据文件应用备份期间收集来的日志文件，使得所有的数据文件保持在一个状态，因为不同的文件在该文件拷贝结束后，都有可能被修改，而且同一个文件在拷贝期间，不同的块也会存在先后的更新。应用日志巧妙的使用了InnoDB引擎crash-reovery的的特性，通过命令本身加载一个小巧的embedded InnoDB开启一个小引擎，除去了一些复杂的检查，让Innodb自己去将改变的日志应用到备份好的哦数据文件上。一般会建议–prepare两次，原因是第一次的作用是应用日志，第二次的作用是产生一个和当前配置保持一致大小的日志文件，以便恢复时能够迅速启动数据库实例。 恢复阶段（Restore Process） 该阶段只需将我们备份好的目录考到指定的位置，作为新的数据目录，同时保证数据库启动后又权限访问该目录下的所有文件即可。 操作时，需要注意的小细节: 1.–backup时，需要有能够连接当前数据库的权限的用户，指定当前数据库的datadir的位置，或命令行指定–datadir，或配置文件my.cnf的[mysqld]组中指定datadir=，以及备份目录targetdir，也同样有两种方式–targetdir或my.cnf的[xtrabackup]组中加入targetdir=。 2.–prepare时，如果准备就发生在当前备份的机器上进行，那么–defaults-file可以直接使用targetdir下的backup-my.cnf文件中配置；如果是在另一台机器去做应用日志操作，那么需要将–defaults-file指定的文件中所有目录相关的配置设置成当前的targetdir。 我目前主要使用innobackupex去做备份，一个是操作简单，另一个是考虑到目前还存在InnoDB和MyISAM混合的数据库。在测试期间，也遇到了一些问题和脚本自身的一些限制，下面抖露几句。 1. 当备份有大量的myisam表时，该perl脚本会出现Error，需要调整脚本中对应的超时时间（还没有找到），但经测试后发现，此状态的备份仍可用。 2. 当使用–databases参数（该值为包含指定库名并用空格隔开的文件）指定备份的数据库时，除了备份指定库后，还会将为指定的库中的ibd文件也备份出来，但是，只有指定的库会将.ibd和.frm文件都备份齐，其他库只有.ibd文件。 下面是我接触到几个命令行选项： –suspend-at-end 这个选项被innobackupex的在脚本中用到，默认xtrabackup不加这选项，当数据文件拷贝结束后，会立即关闭日志拷贝线程停止对跟新日志的拷贝，当加上这个参数，是通过自动生成的xtrabackup_suspened文件存在与否，来决定是否结束log-copying thread，这样当拷贝.frm文件和mysiam表，仍可记录跟新的日志。 –use-memory 该选项可以提高应用日志速度的速度，因为它的值会作为embedded innodb的innodb_buffer_pool_size的大小。 –redo-only 该选项是当作增量恢复的时候使用，依次去应用增量日志的时候，除了–apply-log以外，还要加上–redo-only，只有当所有增量应用完毕，需要自动生成iblogfile的时候，才不需要加–redo-only。该选项是为了保证只应用redo-log，也就是iblogfile的更新。（其实，这里关于redo-log，undo-log的细节我还有点迷糊0_0） xtrabackup还有很多带劲的选项，稍后细致研究后，再和大家分享。 - UPDATED - The [...]]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/06/how-much-do-you-understand-xtrabackup.html/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>MySQL临时表:Internal和Used-defined</title>
		<link>http://www.mysqlsystems.com/2011/06/mysql-temparory-table-including-internal-and-user_defined.html</link>
		<comments>http://www.mysqlsystems.com/2011/06/mysql-temparory-table-including-internal-and-user_defined.html#comments</comments>
		<pubDate>Fri, 10 Jun 2011 13:11:51 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[temporary table]]></category>
		<category><![CDATA[view]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2075</guid>
		<description><![CDATA[为什么突然想说说临时表呢，之前都没有太过多的留意这些知识，是昨天以前的一个同事问了我一句关于临时表的疑问，我也顺便加深写认识。其实，我对于MySQL临时表的应用可以说是一无所知，说的最多听得最多的也都是，查询语句时用到临时表的情况，就是说的internal temporary table，是MySQL自己因为执行某个操作需要额外使用的，而另一种就是user-defined，用户自己定义的(create temporary table)； 之前在798game的时候，公司的手游数据库的设计用到了大量临时表。下面是一些可能在某种意义上，你会觉得很不靠谱的认识，因为这些只是看了一些文字后的皮毛理解。 Internal Temporary Table 当我们的SQL语句相对“复杂”，需要MySQL思考更多时，就会出发自身使用internal temp table，比如：语句中有order by或是group by，还有当我们要修改表的一些属性，比如增加加索引或是添加字段，这些都有可能使用到临时表，我们通过explain这个命令输出的extra列可以看到这样的提示using temporary。这类临时表多数都是内存表也就是MEMORY的存在于内存中，当临时表使用的空间大于tmp_table_size参数设置的值时，该临时表的类型就会自动变成MyISAM的表，那么会被存储到磁盘上，很显然当存取数据从内存转变到磁盘上，这个性能的落差将是我们无法容忍的，所以我们要通过观察Created_tmp_disk_tables参数增长的程度来调整tmp_table_size的到小，该参数仅对于memory类型的internal临时表有效。 User-defined Temporary Table 通过语句CREATE TEMPORARY TABLE XXX 来创建应用所需的临时表。我们自定义的临时表有以下一些特点： 1. 临时表的存在的周期是当前登录的session有效，断开连接将会被立即删除，也可手动将其drop table，无论以任何类型创建的表，在对应的数据库目录下都没有具体的文件生成，但是所有的DML语句都会被记录（后面会说复制的问题）；既然是session有效，那么不同的session间是不能访问别人定义的临时表的，不同session定义的临时表名就可以相同。 2. 支持多种类型的表：MYISAM、MEMORY、MERGE、INNODB，其中对于内存表，通过max_heap_table_size参数值来控制表的大小；peter曾经测试基于memory的临时表的查询速度要比mysiam的快10到100倍，还发现key_buffer_size对于查询有相当重要的影响，即便应用所有的表都是innodb类型的，设置该参数对于提高查询性能有很大帮助； 3. 为什么要用它呢？临时表可以将我们之后可能频繁使用到的中间数据集临时保存下来，这样就会提高业务的处理速度，再有就是可以减少程序代码量，将一定的逻辑处理放到数据库上去完成，这之间的代价需要实际去评估；到了5.0以后出现了视图，对于开发人员有多了一种可选择的方法，而视图的定义是可以永久保存到磁盘上的，视图是不能重名的。 4. 对于临时表的DML操作都会被记录到binlog中，但是前提是binlog的日志格式需要设置为statement模式；主从间对于临时表的操作复制，由于从库slave线程的不恰当关闭，将会导致临时表的复制失败，关闭前需要保证所有的临时表都不处在打开更新的状态，这样再次恢复主从是从库对于临时表的复制才能继续正常进行（想不明白？？？）。 关于临时表的复制，问题是： 既然临时表的存在是session级的，那么从库的sql_thread是不可以中断的，但在生产中从库是不可能完全保持正常，当复制的sql线程临时中断，再次恢复以后，之前的临时表也就不存在了，那么之后有依赖于临时表中数据跟新的语句不都会面临找不到该临时表的问题吗？]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/06/mysql-temparory-table-including-internal-and-user_defined.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Moosefs管理中的小技巧</title>
		<link>http://www.mysqlsystems.com/2011/05/moosefs_tips.html</link>
		<comments>http://www.mysqlsystems.com/2011/05/moosefs_tips.html#comments</comments>
		<pubDate>Mon, 30 May 2011 09:17:52 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[技  巧]]></category>
		<category><![CDATA[新手上路]]></category>
		<category><![CDATA[FUSE]]></category>
		<category><![CDATA[moosefs]]></category>
		<category><![CDATA[subdirectory]]></category>
		<category><![CDATA[分布式]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2069</guid>
		<description><![CDATA[之前写过一个初步介绍Moosefs基本概念的文章，仅是简单测试之后，对mfs的一些理解和认识。最近在实际环境中部署了一套MooseFS系统，用于备份和其他之用，在这个过程中又遇到了些问题，于是又重新找来文档复习理解了一遍，又加深了对MFS的了解，下面是这次学习的点点收获和大家分享下。 1. 挂载目录管理 Moosefs系统支持客户端根据需要挂载对应子目录；默认不指定-S的话会挂载到根目录（\）下，当通过df –sh查看空间使用used显示的是当前整个mfs系统的硬盘使用情况；而挂载子目录则只会看到目录的使用情况。具体操作如下： Shell&#62; mfsmount /mnt –H mfsmaster &#8212; 挂载到根目录（/）下 Shell&#62; mkdir –p /mnt/subdir Shell&#62; umount /mnt Shell&#62; mfsmount /mnt –H mfsmaster –S /subdir &#8212; 挂载到子目录（/subdir）下 在Moosefs的管理中，可以找一台机器作为管理型的client端，在配置文件mfsexports.cfg中限制只有该台机器可以挂载到根目录下，同时也可限制只有该台机器可以挂载metadata目录（恢复误删除时可用到），而其他普通client端，则根据不同业务的需要让管理client端为其创建独立用途的目录，分别挂载到对应的子目录下，这样就可以细化管理控制权限。Mfsexports.cfg的配置如下： # managing client 192.168.0.2 / rw,alldirs,maproot=0 192.168.0.2 . rw # for db backup sub-folder 192.168.0.20 /backup/db rw.maproot=0 # for image sub-folder 192.168.0.30 /app/image rw.maproot=0 2. 客户端重启后自动挂载mfs目录 [...]]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/05/moosefs_tips.html/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>sql_slave_skip_counter参数</title>
		<link>http://www.mysqlsystems.com/2011/05/mysql-variable-sql_slave_skip_counter.html</link>
		<comments>http://www.mysqlsystems.com/2011/05/mysql-variable-sql_slave_skip_counter.html#comments</comments>
		<pubDate>Mon, 23 May 2011 12:59:13 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[sql_slave_skip_counter]]></category>
		<category><![CDATA[variable]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2061</guid>
		<description><![CDATA[sql_slave_skip_counter这个全局参数，维护过主从架构的DBA一定都不陌生，当从库的sql_thread被意外中断，你又想尽快恢复主从间的正常复制，就会用到这个参数；这个跳过的后果就是，你的业务要能容忍这个跳过所带来的丢失，也就是主库和从库上的数据将会不再一致，尽管之后你的主从同步又正常，其实严格意义上，这个从库已经没有意义了，无论是去备份还是对外提供读的服务，也就是说“她”已经不在纯净。那么，这个参数具体是什么含义呢？我相信有些同学一定知道它的真确含义，而有些人自以为知道它的含义，但其实是一个错误的概念（腾讯内部的MySQL培训讲师即便如此，那么，我想你懂得），所以，我觉得还是有必要作为一个Blog写出来，为了自己的巩固，也帮大家理解。 在MySQL的官方手册有对它的有一些轻描淡写的解释，一个小节不是很多，如果，你看过之后不去具体实践一下，自认为明白了，那么，往往你会被自己骗了。说实话，之前我也理解错了，以为skip counter这个值是我们具体执行的一条一条的SQL语句，也就是今天早上需要调整一个主从结构，我就顺带的测试了一下，在和田老师不断交流后，才明白了它的正确含义。这里有两个关键的地方，第一：EVENT也就是事件，通过命令show binlog events in &#8216;mysql-bin.xxxxxx&#8217;;你看到的每一行输出，这就是一个事件；第二：事务，大家耳熟能详的术语，一系列有序SQL语句的集合，可能就只有一条也可能有N条，这语句要么全部执行提交要么全部回滚保持不变，在binlog里面以Begin开始，Commit结束的这么一个group。 set global sql_slave_skip_counter = N;  这个N就是事件的个数，这个参数的含义就是，告诉从库的sql线程跳过多少个relog-log里面的事件数。通过上面提高到show binlog events这个命令，你会发现，create这样的语句被记成一个事件，Insert/Update这类的语句，因为事务与非事务引擎的差异，而有所不同，对事务型表的修改，则由3个事件组成，Begin开始，具体 SQL语句，最后 Commit结束；非事务型表就是你所执行的那条SQL语句。下面简要举例说明下： - Case 1 - 主库： mysql&#62; insert into myisam_tb values (1); mysql&#62; insert into myisam_tb values(2); mysql&#62; show binlog events; use test;  insert into myisam_tb values (1) use test;  insert into myisam_tb values (2) 从库： mysql&#62; stop slave; mysql&#62; set [...]]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/05/mysql-variable-sql_slave_skip_counter.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>批量添加主机到cacti+nagios的监控报警系统中</title>
		<link>http://www.mysqlsystems.com/2011/03/howto-easy-bulk-add-hosts-into-cactinagios.html</link>
		<comments>http://www.mysqlsystems.com/2011/03/howto-easy-bulk-add-hosts-into-cactinagios.html#comments</comments>
		<pubDate>Thu, 31 Mar 2011 12:21:07 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[bulk-add]]></category>
		<category><![CDATA[cacti]]></category>
		<category><![CDATA[nagios]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2036</guid>
		<description><![CDATA[年前很长时间都在鼓弄cacti+nagios，完善我们的监控报警系统，并在在田老师的指导下，对监控系统又有了跟多的认识，其实，监控系统不单单仅仅为了发现故障，它还可以为我们的许多项目实施提供资源，运维的很多事情都可以围绕它来展开，可谓ALL IN ONE。目前，还是主要采用cacti+nagios的组合，cacti提供历史记录和趋势走势，nagios主机和服务的故障报警，当随着主机的增多，各应用监控项的不断增加，cacti和nagios都将会面临性能问题，由于指定时间内扫描率的下降，cacti就会出现超时断图的问题，nagios的报警将被延迟甚至漏发。在经历的诸多问题之后，在田老师的推动下，我们决定重新选择一款适合大规模监控报警的系统，经过综合比较之后，未来的时间里我们将把主要精力放在zabbix的学习和研究上。 在cacti和nagios的使用中，我们都有一种体会，那就是添加监控主机的问题，当机器数据很多时，其实超过10台，我们就会很无聊了，不想让这样重复的体力劳动耗费我们大量的时间。cacti添加有界面的看似和蔼了许多，但是加一台机器进去你也要点大概7-8下，还不算你要手敲的；nagios多数我们都要手动编辑我们的监控主机和应用服务的cfg文件，更是可怕的事情，应该还记得members那行吧。在被折磨了一段时间后，在田老师的鼓励下，我不能再懒了，必须要通过脚本实现自动批量化，于是就产生了下面两个关于如何批量向cacti和nagios添加主机的脚本，肯能你会觉得，这些脚本还是不是很灵活，多数都是基于我工作的需求写的。 Cacti批量添加脚本 脚本描述：使用cacti目录cli下自带的php脚本，再通过shell脚本将其组合模拟我们手动添加主机的过程。监控模板使用google上提供的一个非常丰富的模版better-cacti-templates，包括mysql、apache、nginx等。当你在使用我的脚本前，请先阅读README，有些提示你还是需要注意的:) P.S: Cacti的安装文件比较多，所以之前希望通过YUM都可以搞定，但是安装好以后，添加的主机也可以出图，但是log里面总会有一片一片的红色区域，烦人的“Duplicate entry”，其实这是一个BUG，折腾了我很久很久，几乎要崩溃了，尝试去改spine源码里面的东西，始终得不到解决，最后放弃0.8.7g的这个最新的版本，测试过程中还发现新版的cacti在图的展示上没有以前的版流畅。 下载地址 Nagios批量添加脚本 脚本描述：该脚本其实就是一个根据自己平时添加报警主机和服务的需要定制的一个模板；一共有两个，一个是host相关的，另一个是service相关的。 同时，也请大家仔细阅读README里面的提示，以便顺利运行该脚本。 下载地址 - updated by 5-13 - 之前默认的报警短信/邮件，当出现故障如果没有及时处理的话，会每间隔一定时间不停的发送报警的信息到邮箱/手机中，这样的方式很不友好。其实，我们可以通过定义Escalation来控制报警短信/邮件的次数，具体配置可以参考这里。 Tips：1. 使用hostgroup_name可以不必再去配置host_name选项，整个组中的主机都会被包括，同时可以设置多个组，需要用逗号隔开；2. service_description的值一次只能设置一个服务；3. first_notification、last_notification、notification_interval都设置为0时，如果出现故障，在恢复前只会发一次报警邮件/短信。]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/03/howto-easy-bulk-add-hosts-into-cactinagios.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MooseFS知多少</title>
		<link>http://www.mysqlsystems.com/2011/02/how-much-do-you-understand-moosefs.html</link>
		<comments>http://www.mysqlsystems.com/2011/02/how-much-do-you-understand-moosefs.html#comments</comments>
		<pubDate>Thu, 24 Feb 2011 03:50:01 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[moosefs]]></category>
		<category><![CDATA[nfs]]></category>
		<category><![CDATA[分布式]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2030</guid>
		<description><![CDATA[最近了解了一个分布式文件系统——MooseFS，之前对分布式的东西知道的很少，分布式文件系统、分布式数据库都是近而远之，觉得太复杂了离我还很遥远。在各位老师的推动下我用6台机器实践了一下moosefs，moosefs的部署还是很简单的，和配置NFS很像，就是多了两种角色的机器，正是有了它们，才使得moosefs在可扩展性和稳定性上都要远好于NFS，在读写的性能方面，通过dd进行的简单测试来看，moosefs也就是写入的速度稍微好于NFS，读上没有差别。下面是对于MFS知识点的一些总结。 MFS系统由4个部分构成，master、metalogger、chunkserver、client。 Master —— mfs的大脑，记录着管理信息，比如：文件大小，存储的位置，份数等，和innodb中共享空间（ibdata）中存储的信息类似，这些信息被记录到metadata.mfs中，当该文件被载入内存后，该文件会重命名为metadata.mfs.back，当chunkserver上有更新时，master会定期将获得的新的信息回写到metadata.mfs.back中，保证元数据的可靠。   硬件推荐：大内存，因为内存中需要将metadata.mfs加载进来，这个文件的大小取决于你chunkserver上存储的数据量，内存的大小会成为之后的问题，要ECC的可以进行错误校验，当内存中数据量达到一定程度，如果没有个容错的机制，会很可怕；冗余电池，和磁盘配置RAID1/RAID5/RAID10，都是为了保证高可靠。   Metalogger —— mfs的备份，好比mysql中的m-s结构，metalogger会定期重master上将的metadata、changelog、session类型的文件下载同步到本地目录下，并加后缀”_ml”将其重命名。   硬件推荐：与master机器配置一致，metalogger本身就是master的一个备机，当master宕机后，可以直接将metalogger提升为master。   Chunkserver —— 数据存储地，文件以chunk大小存储，每chunk最大为64M，小于64M的，该chunk的大小即为该文件大小，超过64M的文件将被均分，每一份（chunk）的大小以不超过64M为原则；文件可以有多份copy，即除了原始文件以外，该文件还存储的份数，当goal为1时，表示只有一份copy，这份copy会被随机存到一台chunkserver上，当goal的数大于1时，每一份copy会被分别保存到每一个chunkserver上，goal的大小不要超过chunkserver的数量，否则多出的copy，不会有chunkserver去存，goal设置再多实际上也就没有意义的。Copy的份数，一般设为大于1份，这样如果有一台chukserver坏掉后，至少还有一份copy，当这台又被加进来后，会将失去的那份copy补回来，始终保持原有的copy数，而如果goal设为1copy，那么当存储该copy的chunkserver坏掉，之后又重新加入回来，copy数将始终是0，不会恢复到之前的1个copy。 Chunkserver上的剩余存储空间要大于1GB（Reference Guide有提到），新的数据才会被允许写入，否则，你会看到No space left on device的提示，实际中，测试发现当磁盘使用率达到95%左右的时候，就已经不能写入了，当时可用空间为1.9GB。   硬件建议：普通的机器就行，就是要来存几份数据，只要磁盘够大就好。   Client —— 客户端通过内核加载的FUSE模块，再通过和master的沟通，将chunkserver共享的分区挂载到本地，然后进行读写操作。由于FUSE模块是外加的模块，当系统重启后，需要执行modprobe fuse，将其加载到内核中。  ]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2011/02/how-much-do-you-understand-moosefs.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>mysqld服务器CPU/IOWAIT瞬间出现峰值的问题</title>
		<link>http://www.mysqlsystems.com/2010/12/howto-optimize-high-cpu-and-iowait-on-mysql-server.html</link>
		<comments>http://www.mysqlsystems.com/2010/12/howto-optimize-high-cpu-and-iowait-on-mysql-server.html#comments</comments>
		<pubDate>Sat, 11 Dec 2010 05:27:07 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[cpu]]></category>
		<category><![CDATA[index]]></category>
		<category><![CDATA[iowait]]></category>
		<category><![CDATA[optimize]]></category>
		<category><![CDATA[profile]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=2001</guid>
		<description><![CDATA[自从nagios报警服务配置完善以后,潜伏在DB上的问题变得愈加凸显，这期间还经历了三番五次的机器故障，于是就更加紧绷了我们对于目前DB状态的关注度，通过cacti看每组机器资源的使用情况，通过nagios的alert提示会知道哪些异常在频繁出现，尽管没有发出报警通知（报警策略：所有服务检测每个5分钟扫描一次，发现故障第一次提示开始，每隔1分钟再去尝试，一共4次，当确认该服务失败或者超过阀值后，将状态从之前的Soft更新为Hard，然后便会发出邮件触发139邮箱短信报警，报警邮件的周期为每30钟一次）。观察每个时段nagois的alert提示，同时比对该事件点在cacti上的资源使用情况，给我们一步步排查异常提供了线索。 先说下这次优化过程中的体会，对于自己很不满意，一个字“差”！调整的参数都知道，为什么没有去具体调整看看效果；也同样发现是sql语句的问题，也同样去expain过，但为什么没有做出任何建设性的改进，每天喊着合理有效的去加索引，无奈的是自己找不到那个很需要索引的语句，在slow-log里面抛呀抛的，人家田老师show processlist，一眼就将那个需要索引字段的语句抓了出来，差距呀！田老师还通过show profile让我们清楚的知道一条语句消耗时间的地方在哪个过程上。什么是学以致用呀，这就是，突然又让我想起考大学，同样是各种公式和技巧方法，别人学了就能考上大学，而自己呢。那会跟Hiro在一起学习mysql的时候，我就曾经感叹道，什么是一好百好，真是这样的，一个人之前学习好，那么他工作后如果上心的话也一样是优秀的，为什么google喜欢要清华的，真的就是这样。下面就说说这次优化的诸多尝试。 这边一个业务的其中一组服务器，一个6台机器，主库为drbd的两台，一台对外提供写，从库有四台，均对外提供读的服务。最近一段时间频繁出现某一刻CPU使用率突然彪生80%&#8211;&#62;90%&#8211;&#62;100%，以致前端程序无法响应不断抛出异常，iowait在这期间也是从之前20%-30%，到最后突破60%，随着数据量的增加还有增长的趋势。田老师告诉我，这次优化的大致思路就是先将CPU将下来，这样db可以有时间去处理其他请求，再将iowait将下来，i/o等待过长，自然会降低sql执行的效率。 CPU: 通过调整tmp_table_size、max_heap_table_size、sort_buffer_size、thread_cache_size。为什么要调整这些参数呢？当然是事出有因，通过show processlist可以看到thread的当前状态，我们发现会有频繁的copying tmp table，比较理想说明还在使用内存表，尽管没有出现copying tmp table on disk，但是适当调整tmp_table_size还是能起到未雨绸缪的作用；还发现有converting HEAP to MyISAM，很有理由需要调整max_heap_table_size（其上线为tmp_table_size的大小）。我们的大部分sql都是含有order by和group by，sort_buffer_size可以提供这种语句的执行效率，但是它的设置要格外小心，它并不是全局的参数，而是每个线程所有能获得，怎么能够适可而止呢，通过sort_merge_passes这个状态参数每秒钟变化的幅度来评估你sort_buffer_size设置是否已经够用了。thread_cache_size这个参数也是为了减小cpu的消耗，我们都知道new一个线程是重操作。其实，更加理想的状态是，避免创建临时表，而是完全通过索引就能实现排序分组的目的，这样就大大减轻了cpu的负载。filesort有两中算法：低效率算法需要读两次表，升级版的算法一次就能将最后的结果取出，而它的代价是要缓存跟多点的信息，一般情况下MySQL都会选择效率高的升级版的算法，除非你的筛选字段中有blob或text这样的大字段，同时还可以通过调整max_length_for_sort_data的大小提高升级算法的效率。 iowait: 通过在高峰期抓到的sql语句，将其加上必要的索引（单列索引、复合索引），减少扫描表中记录的数量，由于视图建立的过于庞大，几乎调整的可能性很小牵扯的改动很大，这次的优化主要还是单表语句的优化。在通过explain分析语句的时候，惊奇的发现了一个颠覆复合索引理论的结果，我们都知道复合索引的leftmost原则，我的测试语句where后面的条件顺序并不是之前田老师定义的复合索引中的顺序，但是它依然使用了那个复合索引o_o!&#8230;.通过观察田老师show profile的执行结果，可以清楚看到语句消耗主要集中在sending data和removing tmp table这两项操作上。 slave lag: 主从落后也是时有发生，通过前两个指标的调整，落后的秒数会有所改善，发生落后的频率也会降低，同时在田老师的建议下，所有的slave db计划全部改用innodb puglin的引擎，希望通过利用MySQL自身性能的改进也能对目前问题的缓解有一定帮助。 此外，最近的几次故障中，也充分暴露了MySQL Proxy的一些问题，比如：后台slave db中如果有一台机器故障宕机后，便会影响整个业务，并不像手册里面说的会将故障机标注，同时从之前的配置中将其移除，又加上MySQL Proxy请求分布不均，我们通过netstat的监控脚本可以清楚看到转发到各个后端slave db的请求数，而又碰掉某一段时间proxy将所有的请求都发到故障机上，那么业务就杯具了。MySQL Proxy还有个问题就是，当master db某地时间因为负载或是真的宕机，那么proxy便会认为all backends down，这样的提示你会在php抛出的异常日志中发现，即便你的所有slave db都是正常的。 经过一系列的调整之后，目前这组DB趋于稳定，大家可以暂时消停一段时间，但随着业务量的增加问题还会逐渐出现，因为关于视图语句的改善，索引的调整，表结的合理性，这些都没有根本性的解决，所以问题仍在，只是暂时弱化，PK的道路还很漫长。]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2010/12/howto-optimize-high-cpu-and-iowait-on-mysql-server.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>关于DRBD与Heartbeat的一些思考</title>
		<link>http://www.mysqlsystems.com/2010/11/thinking-on-drbd-heartbeat-faq.html</link>
		<comments>http://www.mysqlsystems.com/2010/11/thinking-on-drbd-heartbeat-faq.html#comments</comments>
		<pubDate>Fri, 26 Nov 2010 17:09:53 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[DRBD]]></category>
		<category><![CDATA[heartbeat]]></category>
		<category><![CDATA[ipfail]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=1985</guid>
		<description><![CDATA[DRBD和Heartbeat这两个用于实现高可用的组合,折腾了有一周了，从开始的新鲜到配置成功的兴奋再到遇到问题的苦闷最后还是在其中一点点的被纠结着，似懂非懂中迷茫着，似乎从小到大没有一件事能做得明白的，稀里糊涂得就奔着三十去了。下面就把这一周里遇到的疑惑，抖露抖露，大家也给点力，说说你们的理解。 DRBD是个什么东西——Distributed Replicated Block Device，这4个英文单词说的很明白，BD说明要实现这个功能首先要是块设备，我们常用的磁盘就是块设备，R就是通过复制来保证两个块设备上的数据一致，通过网络（TCP/IP）传输，所以又被称为网络版的RAID1，D体现在数据同时被存放到主与备这两种角色的主机上，每个主机都是独立的，没有共享的部分，被称为share-nothing，MySQL都是share-nothing的东西（话说，我们的MySQL Cluster），和其相对的就是share-everything，Oracle的高可用策略，共享存储，想做RAID几您随便，再想想我们的DRBD又是网络又是一会你现身了一会我又消失了一顿折腾，再一不小心变成SB（Splite Brain）了,突然感觉到还是人家花钱的东西好呀。DRBD中有好些个名词，需要我们好好去品味，下面这些是通过实际操作和文档学习个人的一些理解，可能有些不完全正确，请大家理性的分辨。 virtual block device &#8212; 对应配置drbd.conf中的device的配置/dev/drbdN(N从0开始到147止)，其实，这就是一个指向真是设备的路径名称。 lower-level device  &#8212; 这个就是真实的物理设备，就是drbd.conf中disk对应的行。 resource &#8212; DRBD把配置的块设备称为自己的资源，它可以配置多个资源，Heartbeat中也有资源这个概念，DRBD被看作其中的一种资源。 metadata &#8212; 记录着DRBD相关的一些信息，就像MySQL中INFORMATION_SCHEMA的作用。 role &#8212; 角色，在DRBD中分为Primary（主）和Secondary（备）两个角色，主上的资源可读可写，而备上的资源“不可见”，你会想了，难道只读都不行吗？在DRBD的文档中给了如下的解释:(The reason for disallowing even read-only access to the device is the necessity to maintain cache coherency, which would be impossible if a secondary resource were made accessible in any way.)。其中，cache [...]]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2010/11/thinking-on-drbd-heartbeat-faq.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>DRBD+Heartbeat让MySQL提供的服务更加稳定</title>
		<link>http://www.mysqlsystems.com/2010/11/drbd-heartbeat-make-mysql-ha.html</link>
		<comments>http://www.mysqlsystems.com/2010/11/drbd-heartbeat-make-mysql-ha.html#comments</comments>
		<pubDate>Tue, 23 Nov 2010 04:07:39 +0000</pubDate>
		<dc:creator>zhang</dc:creator>
				<category><![CDATA[新手上路]]></category>
		<category><![CDATA[drdb]]></category>
		<category><![CDATA[HA]]></category>
		<category><![CDATA[heartbeat]]></category>
		<category><![CDATA[ipfail]]></category>
		<category><![CDATA[MySQL]]></category>

		<guid isPermaLink="false">http://www.mysqlsystems.com/?p=1969</guid>
		<description><![CDATA[这段时间对DRBD和Heartbeat有了一个初步的了解，因为公司目前也在用，所以要好好搞一下，今天就在虚拟机打个了环境，亲自动手学习一下。这两个软件的安装都不复杂，如果你能用yum，那就是瞬间搞定的事情，没有的话用rpm包安装也是很轻松的事情，个人觉得，如果不是说地球上真的找不到和你平台对应的rpm包/tar包的话，那你就用源码包好了，自己享受编译带给你的“成就感”吧。不知道为什么很多时候大家都喜欢源码编来编去的，其实，你编译出来的东西不一定比人家专门的开发人员编出的软件效果要好，也可能你会说了，自己编译自由想放哪儿就放哪儿（难道就这么点追求），如果你习惯了rpm，其实，它的安装目录就那么几个位置，况且rpm也有命名选项帮你找出来。 实验环境： centos 5.5 32位 + drbd-8.0.16 + heartbeat-2.1.3 node1:  drbd-one  192.168.209.12 (primary) node2: drbd-two 192.168.209.11 (secondary) vip: 192.168.209.13 ( for heartbeat ) NOTE: drdb和heartbeat的安装配置都需要在两台机器上，做相应的操作，大家需要注意操作步骤上的不同。 &#8211; Primary Node : drdb-one &#8211; 1.安装drbd和heartbeat 从这个链接下载http://mirror.centos.org/centos/5/extras/i386/RPMS/， 里面drbd和heartbeat的包都有了，找到和自己系统对应的包下好了，下面是我需要的包： drbd-8.0.16-5.el5.centos.i386.rpm，kmod-drbd-8.0.16-5.el5_3.i686.rpm，heartbeat-2.1.3-3.el5.centos.i386.rpm，heartbeat-pils-2.1.3-3.el5.centos.i386.rpm，heartbeat-stonith-2.1.3-3.el5.centos.i386.rpm，libnet-1.1.2.1-2.rf.i386.rpm。但是有点小意外，heartbeat-2.1.3-3这个包就是安装不上。于是，没办法我就到这里下了一个heartbeat的源码包，不过我还是想rpm安的省心，就额外做了下面一步操作，rpmbuilt -ta heartbeat-2.1.3.tar.gz，作成rpm包再来安装，生成的rpm包放在了/usr/src/redhat/RPMS/i386下面了，一共生成7个rpm包，只需要这3个就行：heartbeat-2.1.3-1.i386.rpm，pils-2.1.3-1.i386.rpm，stonith-2.1.3-1.i386.rpm。 Trip: 安装命令：rpm -ivh heartbeat-2.1.3-1.i386.rpm；卸载命令：rpm -e heartbeat-pils-2.1.3-3.el5.centos.i386；查找路径：rpm -q drbd -d。这些都是大家在熟悉不过的了，其实我就是弄明白了两组短语的意思：package file和package name，所以很开心lol.. 另外，安装完heartbeat后，会提示你需要对一些drbd的命令进行权限修改，如下： SHELL&#62; chgrp haclient /sbin/drbdsetup; chmod o-x /sbin/drbdsetup; [...]]]></description>
		<wfw:commentRss>http://www.mysqlsystems.com/2010/11/drbd-heartbeat-make-mysql-ha.html/feed</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
	</channel>
</rss>

