drbd+pacemaker实现数据库高可用的问题总结

标签: drbd pacemaker 数据库 | 发表时间:2014-07-24 11:49 | 作者:xmarker
出处:http://xmarker.blog.163.com
前面的一篇文章记录下drbd+pacemaker+corosync实现postgresql数据库的高可用(参考 这里),经过一段时间的测试和测试环境使用,总结下遇到的问题。

1.drbd的脑裂问题。
drbd脑裂是指当两个节点(假设只有两个节点)因为网络问题或某一个节点的主机故障等问题,造成数据不能实时同步,就会产生脑裂,drbd脑裂在drbd配置文件的net部分有三个场景,并分别有相应的自动处理策略:

after-sb-0pri:这个场景是因为网络故障等原因,现在有0个primary节点,即两个节点都处于从状态,此时两个节点可能都有了新数据(这时候是很糟糕的,两个节点都有数据了,但又不能合并,必须确定一个主节点,并让另一个节点以此为准同步数据),那以谁的数据为准呢?必须要有所取舍了,此时的处理策略有如下几种:
disconnect:直接退出集群,即两个节点均不再参与数据同步,成为孤立节点
discard-younger-primary:丢弃最先的主节点数据,也即是最后成为主节点的节点为新的主节点
discard-least-changes:谁的数据改变最少则谁被抛弃,也即是谁的改变多以谁为主节点
discard-zero-changes:没有改变数据的节点被抛弃,也就是说如果某个节点没有改变数据,说明这个节点发生了故障,要作为从节点。

after-sb-1pri:这个场景是发生脑裂后,现在有1个主节点,另一个节点要么丢弃现有的数据,并以另一个节点为主进行数据同步,要么采用别的办法,如disconnect,策略有如下几种:
disconnect:和上面的解释相同,直接退出drbd集群,不再参与数据同步
consensus:和after-sb-0pri的处理策略相同
call-pri-lost-after-sb:也和after-sb-0pri的处理策略相同,但如果有配置handler脚本的话执行脚本进行处理
discard-secondary:把此节点直接当做脑裂受害者,把另一个节点当做主节点进行数据同步,注意,如果此节点有新数据的话也直接丢弃了。

after-sb-2pri:这个场景是有两个节点都是主节点的情况,处理策略和上面的一个差不多,只是没用了discard-secondary 和 consensus策略,因为两个都是主节点了,就没用所谓的丢弃从节点的策略。

介绍完上面的三种策略,我们就要根据场景来选择了,比如数据库同步场景,我们想让数据最安全,当发生网络故障、某一个节点主机故障等情况,要做到不丢数据,最保险的做法是三个节点都采用disconnect,即直接退出集群不再同步,不丢弃任何数据,但集群切换后,需要手工修复,即要dba人工确定哪个节点的数据时主节点,并把另一个节点作为从节点进行数据同步(方法见 这里)。配置如下:
net {
after-sb-0pri discard-zero-changes;
        after-sb-1pri disconnect;
        after-sb-2pri disconnect;
}
如果数据不是很重要,不涉及金融数据,想让某台节点故障后自动进行数据同步,可以采用如下策略:
net {
after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
}
这样当一台机器挂掉后另一台启动后可以自动以另一台为主节点进行数据同步而不需要手工数据同步。

2.和pacemaker配合时的问题
使用pacemaker来做集群故障切换时,会遇到另一个问题,当两个节点发生脑裂后,如现在两个都是从节点,且两个从节点的数据目前不处于同步状态,pacemaker也会切换的,这时候会因为pacemaker启动了陈旧的数据而造成数据不一致,这个场景可能发生在这种情况:
1.两台主备节点正常运行,数据处于drbd同步状态
2.一台主节点挂掉了,从节点接替了主节点,然后有新数据进来了,这时主节点处于离线状态,新数据现在只在一个节点上有,这时就出现不一致数据状态
3.这时从节点也挂掉了
4.这时原来的主节点修复好了,这时pacemaker会启动主节点的资源,这时又一部分新数据进来,到了原来的主节点上
5.这时原来的从节点修复好了,这时候就两个节点都有一部分新数据,造成了数据不一致
为了避免这种情况,需要采用如下办法:
在drbd的disk配置部分,加入如下配置:
disk { 
on-io-error detach; 
fencing resource-only;
}
handler部分要加入如下配置:
handlers { 
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-
trigger ; reboot -f"; 
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-
trigger ; reboot -f"; 
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; 
halt -f"; 
fence-peer "/usr/lib/drbd/crm-fence-peer.sh"; 
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
 其中红色部分就是当脑裂发生时,pacemaker要调用的脚本和节点恢复后的数据恢复脚本。
加上这段后,如果某一个节点处于离线,另一个节点再发生离线,先前的节点即使修复了也不会让他作为主节点启动的,因为pacemaker认为此节点数据是outdate(过时的)数据,pacemaker会一直等待直到有最新数据的节点修复后才能启动资源,这样是最安全的。

3.drbd的空间扩展。
drbd资源扩展起来有如下几个方法:
1.新建一个drbd资源,然后加入pacemaker集群管理器中进行资源管理,不过数据库要用这个新盘的话就要用表空间之类的方式了,原来的磁盘是多大就多大。
2.创建lvm作为底层drbd磁盘,如果有空间扩展需要,在主备节点均新增同样大小的磁盘并加入lvm中。但要注意的是drbd资源需要手工调整下才能重新认识到新加的磁盘:
 #drbdadm resize datatest
这样drbd能认到新的底层lvm磁盘
但正在挂载使用的文件系统不会立即更改大小的,可以用如下办法在线扩展文件系统大小:
[[email protected] ~]# resize2fs /dev/drbd3 
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/drbd3 is mounted on /test; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/drbd3 to 786399 (4k) blocks.
The filesystem on /dev/drbd3 is now 786399 blocks long.

其他方案如德哥的github的高可用方案也很好( https://github.com/digoal/sky_postgresql_cluster),不过需要外部硬件如戴尔的idrac的ipmi远程关机功能支持,而解决了drbd脑裂问题,就可以放心使用这种方案了。

相关 [drbd pacemaker 数据库] 推荐:

drbd+pacemaker实现数据库高可用的问题总结

- - x-marker的博客
前面的一篇文章记录下drbd+pacemaker+corosync实现postgresql数据库的高可用(参考 这里),经过一段时间的测试和测试环境使用,总结下遇到的问题. drbd脑裂是指当两个节点(假设只有两个节点)因为网络问题或某一个节点的主机故障等问题,造成数据不能实时同步,就会产生脑裂,drbd脑裂在drbd配置文件的net部分有三个场景,并分别有相应的自动处理策略:.

pacemaker+corosync+drbd实现postgresql高可用

- - x-marker的博客
这种防守的优点是配置较为简单,流复制的备库还能提供一些查询服务,但备库提升为主库后,原来的主库需要使用regmgr重新生成主库,还要开启regmgr监控进程,因此故障只能切换一次,然后进行人工干预(虽然此步骤也可以写成脚本实现自动切换,但我感觉最好还是手工提升,避免来回切换造成数据丢失). 这两天实验了下centos6.4 x-64下的pacemaker+corosync+drbd来实现postgresql的高可用.

[转]DRBD 介绍

- - 小鸥的博客
Distributed Replicated Block Device(DRBD)是一个用软件实现的、无共享的、服务器之间 镜像 块设备内容的存储复制解决方案. 数据 镜像:实时、透明、同步(所有服务器都成功后返回)、异步(本地服务器成功后返回). DRBD的核心功能通过Linux的 内核实现,最接近系统的IO栈,但它不能神奇地添加上层的功能比如检测到EXT3文件系统的崩溃.

Linux下DRBD配置

- - CSDN博客系统运维推荐文章
一、Drbd 工作原理. DRBD是一种块设备,可以被用于高可用(HA)之中.它类似于一个网络RAID-1功能.(可以比较一下Linux的NFS)当你将数据写入本地 文件系统时,数据还将会被发送到网络中另一台主机上.以相同的形式记录在一个文件系统中. 本地(主节点)与远程主机(备节点)的数据可以保证实时同步.当本地系统出现故障时,远程主机上还会 保留有一份相同的数据,可以继续使用.在高可用(HA)中使用DRBD功能,可以代替使用一个共享盘阵.因为数据同时存在于本地主机和远程主机上,切换时,远程主机只要使用它上面的那份备份数据,就可以继续进行服务了.

drbd脑裂处理

- - x-marker的博客
前面写过一篇关于使用drbd+corosync+pacemaker实现postgresql高可用的博客,其实drbd的对等节点如果不在线的话,即主节点的数据更改如果无法及时传送到备节点达到一定时间,会造成数据不一致,即使故障节点在长时间离线后恢复,drbd可能也不能正常同步了. 或者另外一种情况,主备都在线,但心跳网络断了而出现脑裂,两个节点都认为自己是主节点,也会造成两个节点的数据不一致,这样需要人工干预,告诉drbd以哪个节点为主节点,或者在drbd配置脑裂的行为.

drbd+xfs+heartbeat+mysql实现高可用

- - C1G军火库
DRBD是一种块设备,可以被用于高可用(HA)之中.它类似于一个网络RAID-1功能.当你将数据写入本地 文件系统时,数据还将会被发送到网络中另一台主机上.以相同的形式记录在一个文件系统中. 本地(主节点)与远程主机(备节点)的数据可以保证实时同步.当本地系统出现故障时,远程主机上还会保留有一份相同的数据,可以继续使用.

drbd性能测试及调优

- - x-marker的博客
今天在qq群里,有个哥们说千万不要用drbd做mysql的HA,说对性能影响非常大,drbd对性能有影响是肯定的,把数据通过网络发送给对端备库必定有性能损耗,而我正好有一套drbd,借此测试一把,看看drbd对性能的影响到底有多大,也给网友一个参考. 我测试的是一套两节点的drbd+pacemaker+corosync的mysqlHA高可用集群,主机都是普通的过时的pc机,内存2g,cpu 2核.

基于DRBD的高可用NFS解决方案分析

- - 忘我的追寻
之前对DRBD分析比较多,但是一直没有找到该怎么用他. 最近又在看NFS协议( RFC3530). 分析了NFS4对于的迁移、复制和服务端重启等场景的定义. DRBD提供块设备,其上是文件系统,而NFS在文件系统上层,二者结合可以构建一个高可用的文件共享解决方案. 关于DRBD,在之前的博客中有一些分析(tag: DRBD).

数据库sharding

- - 数据库 - ITeye博客
当团队决定自行实现sharding的时候,DAO层可能是嵌入sharding逻辑的首选位置,因为在这个层面上,每一个DAO的方法都明确地知道需要访问的数据表以及查询参数,借助这些信息可以直接定位到目标shard上,而不必像框架那样需要对SQL进行解析然后再依据配置的规则进行路由. 另一个优势是不会受ORM框架的制约.

数据库索引

- - CSDN博客推荐文章
索引是由用户创建的、能够被修改和删除的、实际存储于数据库中的物理存在;创建索引的目的是使用户能够从整体内容直接查找到某个特定部分的内容. 一般来说,索引能够提高查询,但是会增加额外的空间消耗,并且降低删除、插入和修改速度. 1.聚集索引:表数据按照索引的顺序来存储的. 2.非聚集索引:表数据存储顺序与索引顺序无关.