Posts tagged ‘heartbeat’

heartbeat替换集群中的一台主机

今天完成了替换双master其中一台主机的任务。特将具体过程记录下来以供以后参考。
背景描述:
a,b互为主备,a提供应用访问。c是a的备机,画一个最挫的图如下
a<->b
|
c
现在,我想用c替换掉b。
a和b是用heartbeat来做HA的,要求在替换主机过程中,应用不能停,对应用必须要透明。
方案:
我们采用修改b的IP,并停掉b。然后把c的hostname,IP修改为b的方法,顶替b来避免对应用的影响
1、停止主机a的slave。这个是为了避免c替换掉b的IP起来的时候,a从错误的位置开始复制binlog。因为b和c的binlog不可能为同一个位置
2、b修改Ip并停机。修改/etc/sysconfig/network-scripts/ifcfg-bond0中的IP;/etc/init.d/network restart重启网络;poweroff关机
3、用c顶替b。
a)修改主机名。利用hostname命令设置主机名;修改/etc/hosts中的节点名称;修改/etc/sysconfig/network中的主机名
b)修改IP.同2.
c)修改heartbeat。这里是比较关键的地方,经过详细测试得出:
一:如果是全新安装的机器,需要从主机a中拷贝ha.cf,authkey,cib.xml以及通过crm_uuid -w 生成正确的uuid
二:如果是从a拷贝过来的heartbeat,那么需要删除(我的安装目录为/usr/heartbeat):
/usr/heartbeat/var/lib/heartbeat/hostcache
/usr/heartbeat/var/lib/heartbeat/hb_uuid
/usr/heartbeat/var/lib/heartbeat/hb_generation
hostcache为缓存主备机节点以及uuid的地方,
hb_uuid为本节点的uuid,
hb_generation为主备机协商时握手的数值。
hb_uuid和hb_generation如果顶替的时候跟之前的节点不一样,那么主机就会报:heartbeat[11165]: 2011/03/21_18:19:40 ERROR: should_drop_message: attempted replay attack [jyl-idle-db3b]? [gen = 1245825415, curgen = 1245825416]错误。
hb_uuid需要用crm_uuid -w 来生成,不能由heartbeat默认生成。从主机a的/usr/heartbeat/var/lib/heartbeat/hostcache获得b机器的uuid,然后crm_uuid -w uuid生成。
具体的信息可以参照下面的介绍:
4.5.2. Heartbeat
The seven-step guide to replacing an existing cluster node:
Make sure the old node is completely stopped
Give the new machine the same hostname as the old one
Go to an active cluster node and look up the UUID for the old node in /var/lib/heartbeat/hostcache
Install the cluster software
Copy ha.cf and authkeys to the new node
On the new node, populate it’s UUID using crm_uuid -w and the UUID from step 2
Start the new cluster node
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-replace-heartbeat.html
4、主机a,change master 搭建c到a的复制(这里可以随意的在c上show master status获得位置,因为c是备机,它自己没有应用访问生成binlog)
5、启用c机器的heartbeat和MySQL。检查crm_resource的输出
may your success

MySQL数据库机器搬迁checklist

itbu的数据库机器从老机房搬迁到新机房的项目已经接近尾声了,这次的搬迁是我经历的一个比较大的项目,虽然整体的调控不是我主导的,但是MySQL数据库的搬迁都是我在主导进行,期间出现了一些问题,还好没有出现非常重大的错误。从中相信搬迁的大部分同学都成长了很多。我自己感觉我学到了很多,也成长了很多,虽然加班加点的,累的够呛,还是很值得的。为了避免以后大家再走弯路,也避免自己忘记搬迁的重要事项,特别记录下来,做为一个搬迁工程的checklist。方便大家搬迁过程中检查,不要遗漏了一些东西。
1、确认方案。尽早和应用方沟通,确认采用平滑搬迁或者停机搬迁的方案。
平滑搬迁是指MySQL数据库停止备机,然后搬迁过去,在新环境搭好以后,配置MySQL的双master复制,调试通过,应用服务正常。然后直接刷dns(或者其他方式)使应用的真实用户访问新的服务。
停机搬迁的方式是指,应用发布停机公告,在适当的时机,将应用服务器和数据库服务器等搬迁到新机房,部署上线。
上面的两种方案,第一种风险较小,对用户影响也非常小。万一刷过去以后,真实用户访问有问题,还可以切回来。第二种风险比较大,甚至可能出现有些配置修改修改不及时,造成停机时间已经过了,应用无法访问的问题。
2、确认机架位置。正常的话,sa负责人会将搬迁的机器列表和机柜,机架位置发给大家一份。以方便现场工程师以及对应人员确认搬迁的就是这批机器。我们需要注意一下,并提醒现场工程师机柜和机架号。eshop搬迁的时候,我们的一个现场工程师就看错了机柜号,拔掉了一台正在提供应用服务的机器,还好立刻意识到了,大家一起快速修复了这个问题。
3、确认搬迁的机器IP和搬迁到新机房的机器IP。老机房需要搬迁的机器IP在上一步就需要确认好了,新机房的机器IP需要跟sa和网络部门的同事沟通,我们提供具体的分配策略,网段划分,新老机器IP对应关系。
4、确认时间。及早跟各应用方沟通搬迁时间,如果有变化,及时相互通知。
5、搬迁前准备工作。eshop这边搬迁前需要重新同步主机数据到备机。其他应用需要注意主备机的复制延迟,尽量保证复制延迟较低。
6、通知所有相关人员。包括数据仓库,应用开发人员,网络,sa。告知他们新的数据库IP地址和连接方式。另外还需要检查MySQL里面的所有账户,看这些用户是否都通知到了。pm就没有及时通知数据仓库人员,导致第二天他们取不到数据的问题。
7、修改搬迁以后的配置。包括MySQL账户的修改,heartbeat的修改,cobar的修改,脚本的修改,脚本的配置文件修改,带外登录等。
a)MySQL帐号的修改。检查MySQL的账户,看是否还有依赖于老的IP地址段的账户。比如:eshop的复制帐号replicator@172.18.%搬迁到新的机房就肯定需要修改掉。
b)heartbeat的修改;cobar的修改。机器搬迁到新的机房,需要修改heartbeat和cobar的配置。这样才能让应用访问新的VIP地址。
c)脚本的修改。目前MySQL的管理有许多脚本,这些脚本有些是对IP有依赖关系的,需要及时修改掉。当然,最好修改掉这样的脚本,去掉对IP的依赖。
d)脚本配置文件的修改。有些脚本通过读取配置文件来依赖IP,同样需要修改配置文件。如果可能的话,修改脚本,去掉对IP的依赖。
e)带外登录。带外登录地址随着机器IP的更换也会变化。搬迁过去以后,需要再次验证一下带外登录的方式是否还正常。

该checklist可能还不是很完全,需要补充和优化。

may you success.