前段时间一位同事收到某开发部门一位同事求助，希望帮忙优化一条Mysql的sql语句，大体如下：
select n.id ,nc.content
from news n force index (category1_status,category2_status,category3_status),news_content nc
where n.id=nc.id
and n.status=2 and (n.category_id_1 in (5003107,5003108)
or n.category_id_2 in (5003107,5003108)
or n.category_id_3 in (5003107,5003108)
调试的时候发现怎么都不能走index_merge的执行计划（我们所期望的），后来临时给他们一个union的解决方案。后来下班吃完晚饭后一起找问题，发现即使只有单个表，也没办法走到index_merge的执行计划，不管是加提示还是不加提示，调试过程如下：
mysql> explain select n.id ,nc.content
-> from news n force index (category1_status,category2_status,category3_status),news_content nc
-> where n.id=nc.id
-> and n.status=2 and (n.category_id_1 in (5003107,5003108)
-> or n.category_id_2 in (5003107,5003108)
-> or n.category_id_3 in (5003107,5003108)
-> ) ;
+—-+————-+——-+——–+—————————————————-+———+———+————–+——–+————-+
| id | select_type | table [...]
MySQL, tuning
在V2的Heartbeat中，为了将资源的监控和切换结合起来，同时支持多节点集群，Heartbeat提供了一种积分策略来控制各个资源在集群中各节点之间的切换策略。通过该积分机制，计算出各节点的的总分数，得分最高者将成为active状态来管理某个（或某组）资源。
如果在CIB的配置文件中不做出任何配置的话，那么每一个资源的初始分数（resource-stickiness）都会是默认的0，而且每一个资源在每次失败之后所减掉的分数（resource-failure-stickiness）也是0。如此的话，一个资源不论他失败多少次，heartbeat都只是执行restart操作，不会进行节点切换。一般来说，resource-stickiness的值都是正数，resource-failure-stickiness的值都是负数。另外还有一个特殊值那就是正无穷大（INFINITY）和负无穷大（-INFINITY）。如果节点的分数为负分，那么不管什么情况发生，该节点都不会接管资源（冷备节点）。随着资源的各种状态的发生，在各节点上面的分数就会发生变化，随着分数的变化，一旦某节点的分数大于当前运行该资源的节点的分数之后，heartbeat就会做出切换动作，现在运行该资源的节点将释放资源，分数高出的节点将接管该资源。
在CIB的配置中，可以给每个资源定义一个分数，通过resource-stickiness来设置，同样也可以设置一个失败后丢失的分数，通过resource-failure-stickiness来设置。如下：
…
上面的配置就是给mysql_db这个resource配置了两个分数，成功运行的时候所得到的分数（resource_stickiness）和运行失败会丢失的分数（resource_failure_stickiness），两项分数值一样多，成功则得100分，失败则-100分。
除了可以通过给每个资源单独设置两项的分数之外，也可以将所有的resource设置成相同的分数，如下：
…
…
…
在这个配置中，就是给所有资源设置了两个默认的分数，省去单独每个资源都设置的麻烦。当然，如果在设置了这个default分数之后，同时也给部分或者全部资源也设置了这两个分数的话，将取单独设置的各个资源设置的分数而不取默认分数。
除了资源的分数之外，节点自身同样也有分数。节点分数可以如下设置：
…
…
注意这里节点分数的设置是放在configuration配置项里面的constraints配置项下的，通过rule来设置。这里是通过节点主机名来匹配的（实际上heartbeat的很多配置中对主机名都是很敏感的）。这里的value值就是节点的主机名，rule里面的score就是一个节点的分数。
通过上面的配置，我们可以作出如下计算：
a、在最开始，两边同时启动heartbeat的话，两边都没有开始运行这个resource，resource本身没有分数，那么仅仅计算节点的分数：
mysql1的分数：node+resource+failcount*failure=200+0+(0*(-100))=200
mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
heartbeat会做出选择在mysql1上面运行mysql_db这个资源，然后mysql1的分数发生变化了，因为有资源自身的分数加入了：
mysql1的分数：node+resource+failcount*failure=200+100+(0*(-100))=300
mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
b、过了一段时间，heartbeat的monitor发现mysql_db这个资源crash（或者其他问题）了，分数马上会发生变化，如下：
mysql1的分数：node+resource+failcount*failure=200+100+(1*(-100))=200
mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
heartbeat发现mysql1节点的分数还是比mysql2的高，那么资源不发生迁移，将执行restart类操作。
c、继续运行一段时间发现又有问题（或者是b后面restart没有起来）了，分数又发生变化了：
mysql1的分数：node+resource+failcount*failure=200+100+(2*(-100))=100
mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
这时候heartbeat发现mysql2节点比mysql1节点的分数高了，资源将发生迁移切换，mysql1释 mysql_db相关资源，mysql2接管相关资源，并在mysql2上运行mysql_db这个资源。这时候，节点的分数又会发生变化如下：
mysql1的分数：node+resource+failcount*failure=200+0+(2*(-100))=0
mysql2的分数：node+resource+failcount*failure=150+100+(0*(-100))=250
这时候如果在mysql2上面三次出现问题，那么mysql2的分数将变成-50，又比mysql1少了，资源将迁移回 mysql1，mysql1的分数将变成100，而mysql2的分数将变成-150，因为又少了资源所有者的那100分。到这里，mysql2节点的分数已经是负数了。heartbeat还有一个规则，就是资源永远都不会迁移到一个分数分数是负数的节点上面去。也就是说从这以后，mysql1节点上面不管mysql_db这个资源失败多少次，不管这个资源出现什么问题，都不会迁移回mysql2节点了。一个节点的分数会在该节点的heartbeat重启之后被重置为初始状态。或者通过相关命令来对集群中某个节点的某个资源或者资源组来重置或者查看其failcount，如下：
crm_failcount -G -U mysql1 -r mysql_db #将查看mysql1节点上面的mysql_db这个资源的failcount
crm_failcount -D -U mysql1 -r mysql_db #将重置mysql1节点上面的mysql_db这个资源的failcount
当然，在实际应用中，我们一般都是将某一些互相关联的资源放到一起组成一个资源组，一旦资源组中某资源有问题的时候，需要迁移整个资源组的资源。这个和上面针对单个资源的情况实际上没有太多区别，只需要将上面mysql_db的设置换到资源组即可，如下：
…
… …
…
这样，在该资源组中任何一个资源出现问题之后，都会被认为该资源组有问题，当分数低于其他节点出现切换的时候就是整个资源组的切换。
另外，对于INFINITY和-INFINITY这两个值，实际上主要用途就是为了控制永远不切换和只要失败必须切换用的。因为代表的意思就是拥有正无穷大的分数和失败就到负无穷大，主要用来满足极端规则的简单配置项。
总的来说，一项资源（或者资源组）在一个节点运行迁移到另一个节点之前，可以失败的次数的计算公式可以如下表示：
(nodeA score – nodeB score + stickiness)/abs(failure stickiness)，即为A节点分数减去B节点分数，再加上资源运行分数后得到的总分数，除以资源失败分数的绝对值。
HeartBeat, MySQL
1、下载对应版本的heartbeat包
由于安装beartbeat的rpm包需要其他一些包为前提条件，所以可能还需要下载对应版本的其他的几个rpm包，像如下：
[root@mysql1 heartbeat]# rpm -ivh heartbeat-2.1.3-3.el4.centos.i386.rpm
warning: heartbeat-2.1.3-3.el4.centos.i386.rpm: V3 DSA signature: NOKEY, key ID 443e1821
error: Failed dependencies:
heartbeat-pils = 2.1.3-3.el4.centos is needed by heartbeat-2.1.3-3.el4.centos.i386
heartbeat-stonith = 2.1.3-3.el4.centos is needed by heartbeat-2.1.3-3.el4.centos.i386
libpils.so.1 is needed by heartbeat-2.1.3-3.el4.centos.i386
libstonith.so.1 is needed by heartbeat-2.1.3-3.el4.centos.i386
然后下载heartbeat-pils-2.1.3-3.el4.centos.i386.rpm和heartbeat-stonith-2.1.3-3.el4.centos.i386.rpm，
在安装这两个包之后，即可正常安装heartbeat了。
2、配置相关文件
1) 找到安装后heartbeat的文档目录，将三个需要的配置文件样例copy到/etc/ha.d目录下准备后面的配置设
置（这样会更方便，而且有较为详细的配置说明）：
[root@mysql1 ha.d]# rpm -q heartbeat -d
…
/usr/share/doc/heartbeat-2.1.3/AUTHORS
…
[root@mysql1 ha.d]# cp /usr/share/doc/heartbeat-2.1.3/ha.cf .
[root@mysql1 ha.d]# cp /usr/share/doc/heartbeat-2.1.3/authkeys .
[root@mysql1 ha.d]# cp /usr/share/doc/heartbeat-2.1.3/haresources .
2) 配置ha.cf（ha主要配置文件）：
logfacility [...]
DRBD, HeartBeat, MySQL
测试环境：rhel3.5，drbd 8.0.7，mysql5.0.51-rc-log
1、首先从www.drbd.org下载了源代码包（我下载的8.0.7版本的包）
2、检查主机上面有没有linux的内核源代码，如果没有，需要找到相对应版本的源代码包安装上去。
3、开始安装drbd：
1) 解压：tar -zxvf drbd-8.0.7.tar.gz
2) 进入drbd源码目录，根据kernel源码位置来编译drbd：
make KDIR=/usr/src/kernel/ (如果没有更改过内核，可以直接运行make，编译程序会到/lib/module里面去自己根据相关配置寻找到kernel源码)
make install
如果没有报错，应该基本install好了，检查是否生成了相应的文件：/etc/drbd.conf ; /etc/init.d/drbd ; 以及./drbd/drbd.ko
同时系统应该至少多了以下两个命令：drbdadm和drbdsetup
不要删除此源码目录，后面还会用到里面的./scripts/drbd.conf 和 ./drbd/drbd.ko
4、现在可以加载安装drbd模块了
insmod drbd.ko 或者 modprobe drbd
通过lsmod检查是否已经成功
#lsmod |grep drbd
如果有，则表示成功了
5、更改drbd配置文件：
/etc/drbd.conf
[root@mysql1 ha.d]# cat /etc/drbd.conf
…
on mysql1 {
device /dev/drbd0;
disk /dev/i2o/hda9;
address 10.0.65.45:8888;
flexible-meta-disk internal;
}
on mysql2 {
device /dev/drbd0;
disk [...]
DRBD, MySQL
测试环境：
Type OS Mysql
Master rhel3.5 5.1.22-rc-log
Slave1 rhel3.5 [...]
Master, MySQL, Slave
