原文出自老男孩博文,这篇博文写的很是好,如此转载。
http://blog.51cto.com/oldboy/1240412
互联网公司从初期到后期的数据库架构拓展
Heartbeat介绍
官方站点:http://linux-ha.org/wiki/Main_Page
heartbeat可以资源(VIP地址及程序服务)从一台有故障的服务器快速的转移到另一台正常的服务器提供服务,heartbeat和keepalived相似,heartbeat可以实现failover功能,但不能实现对后端的健康检查
DRBD介绍
官方站点:http://www.drbd.org/
DRBD(DistributedReplicatedBlockDevice)是一个基于块设备级别在远程服务器直接同步和镜像数据的软件,用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。它可以实现在网络中两台服务器之间基于块设备级别的实时镜像或同步复制(两台服务器都写入成功)/异步复制(本地服务器写入成功),相当于网络的RAID1,由于是基于块设备(磁盘,LVM逻辑卷),在文件系统的底层,所以数据复制要比cp命令更快
DRBD已经被MySQL官方写入文档手册作为推荐的高可用的方案之一
MySQL介绍
官方站点:http://www.mysql.com/
MySQL是一个开放源码的小型关联式数据库管理系统。目前MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低,尤其是开放源码这一特点,许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。
heartbeat和keepalived应用场景及区别
很多网友说为什么不使用keepalived而使用长期不更新的heartbeat,下面说一下它们之间的应用场景及区别
1、对于web,db,负载均衡(lvs,haproxy,nginx)等,heartbeat和keepalived都可以实现
2、lvs最好和keepalived结合,因为keepalived最初就是为lvs产生的,(heartbeat没有对RS的健康检查功能,heartbeat可以通过ldircetord来进行健康检查的功能)
3、mysql双主多从,NFS/MFS存储,他们的特点是需要数据同步,这样的业务最好使用heartbeat,因为heartbeat有自带的drbd脚本
总结:无数据同步的应用程序高可用可选择keepalived,有数据同步的应用程序高可用可选择heartbeat
架构说明:
一主多从最常用的架构,多个从库可以使用lvs来提供读的负载均衡
解决一主单点的问题,当主库宕机后,可以实现主库宕机后备节点自动接管,所有的从库会自动和新的主库进行同步,实现了mysql主库的热备方案
系统环境 |
|
系统 |
CentOSrelease5.8 |
系统位数 |
X86 |
内核版本 |
2.6.18 |
软件环境 |
|
heartbeat |
heartbeat-2.1.3-3 |
drbd |
drbd83-8.3.13-2 |
mysql |
5.5.27 |
角色 |
IP |
VIP |
192.168.4.1(内网提供服务的地址) |
master1 |
eth0:(数据库无公网地址) eth1:192.168.4.2/16(内网) eth2:172.16.4.2/16(心跳线) eth3:172.168.4.2/16(DRBD千兆数据传输) |
master2 |
eth0:(数据库无公网地址) eth1:192.168.4.3/16(内网) eth2:172.16.4.3/16(心跳线) eth3:172.168.4.3/16(DRBD千兆数据传输) |
slave1 |
eth1:192.168.4.4/16(外网) |
说明:从库通过主库的VIP进行主从同步replication |
|
需求: 1、主库master1宕机后master2自动接管VIP以及所有从库 2、在master2接管时,不影响从库的主从同步replication |
磁盘 |
容量 |
分区 |
挂载点 |
说明 |
/dev/sdb |
1G |
/dev/sdb1 |
/data/ |
存放数据 |
/dev/sdb2 |
存放drbd同步的状态信息 |
|||
注意 1、metadata分区一定不能格式化建立文件系统(sdb2存放drbd同步的状态信息) 2、分好的分区不要进行挂载 3、生产环境DRBDmetadata分区一般可设置为1-2G,数据分区看需求给最大 4、在生产环境中两块硬盘一样大 |
主节点
1 2 |
|
备节点
1 2 |
|
1 2 3 |
|
主备节点两端的配置文件(ha.cfauthkeysharesources)完全相同
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
1 2 3 |
|
1 2 3 4 5 6 7 |
|
1 2 3 |
|
正常状态
1 2 3 4 5 6 7 8 |
|
模拟主节点宕机后的状态
1 2 3 4 5 6 |
|
模拟主节点故障恢复后的状态
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 |
|
1 2 3 |
|
主备节点两端配置文件完全一致
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
|
1 2 3 4 5 |
|
1 |
|
1 2 |
|
1 2 3 |
|
正常状态
1 2 3 4 5 6 7 8 9 10 11 |
|
模拟master1宕机
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
注意:三台数据库都安装mysql服务,master2只安装到makeinstall即可,mysqld服务不要设置为开机自启动
1 2 |
|
1 2 3 4 5 6 |
|
1 2 |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 |
|
1 2 3 4 |
|
1 2 3 4 5 |
|
1 2 3 4 5 6 7 8 |
|
master1主节点正常状态
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
master2备节点正常状态
1 2 3 4 5 6 7 8 9 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
|
启动的顺序是:先启动VIP--启动drbd资源--挂载drbd分区--启动mysqld服务,日志如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
|
备节点释放资源顺序:停止mysqld服务--卸载drbd1分区--设置drbd为备节点--关闭VIP地址,日志如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
|
1 2 3 4 5 |
|
1 2 |
|
1 2 3 4 5 |
|
1 2 3 4 5 6 7 8 |
|
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1、高可用服务器之间心跳链路故障,导致无法相互检查心跳
2、高可用服务器上开启了防火墙,阻挡了心跳检测
3、高可用服务器上网卡地址等信息配置不正常,导致发送心跳失败
4、其他服务配置不当等原因,如心跳方式不同,心跳广播冲突,软件BUG等
1、加冗余线路
2、检测到裂脑时,强行关闭心跳检测(远程关闭主节点,控制电源的电路fence)
3、做好脑裂的监控报警
4、报警后,备节点在接管时设置比较长的时间去接管,给运维人员足够的时间去处理(人为处理)
5、启动磁盘锁,正在服务的一方锁住磁盘,裂脑发生时,让对方完全抢不走"共享磁盘资源"
磁盘锁存在的问题:
使用锁磁盘会有死锁的问题,如果占用共享磁盘的一方不主动"解锁"另一方就永远得不到共享磁盘,假如服务器节点突然死机或崩溃,就不可能执行解锁命令,备节点也就无法接管资源和服务了,有人在HA中设计了智能锁,正在提供服务的一方只在发现心跳全部断开时才会启用磁盘锁,平时就不上锁