heartbeat+drbd+mysql高可用架构
Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节互联网公司从初期到后期的数据库架构拓展
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
1、Heartbeat+DRBD+MySQL安装部署
(1)、架构拓扑
架构说明：
一主多从最常用的架构，多个从库可以使用lvs来提供读的负载均衡
解决一主单点的问题，当主库宕机后，可以实现主库宕机后备节点自动接管，所有的从库会自动和新的主库进行同步，实现了mysql主库的热备方案
(2)、系统环境
系统环境系统CentOSrelease5.8系统位数X86内核版本2.6.18软件环境heartbeatheartbeat-2.1.3-3drbddrbd83-8.3.13-2mysql5.5.27 (3)、部署环境
角色IPVIP192.168.4.1(内网提供服务的地址)master1eth0:(数据库无公网地址) eth1:192.168.4.2/16(内网)
eth2:172.16.4.2/16(心跳线)
eth3:172.168.4.2/16(DRBD千兆数据传输)
master2eth0:(数据库无公网地址) eth1:192.168.4.3/16(内网)
eth2:172.16.4.3/16(心跳线)
eth3:172.168.4.3/16(DRBD千兆数据传输)
slave1eth1:192.168.4.4/16(外网)说明：从库通过主库的VIP进行主从同步replication需求： 1、主库master1宕机后master2自动接管VIP以及所有从库
2、在master2接管时，不影响从库的主从同步replication
(4)、主库服务器数据分区信息
磁盘容量分区挂载点说明/dev/sdb1G/dev/sdb1/data/存放数据/dev/sdb2存放drbd同步的状态信息注意 1、metadata分区一定不能格式化建立文件系统(sdb2存放drbd同步的状态信息)
2、格式化分好的分区现在不要进行挂载
3、生产环境DRBDmetadata分区一般可设置为1-2G，数据分区看需求给最大
4、在生产环境中两块硬盘一样大
2、heartbeat安装部署
(1)、配置服务器间心跳连接路由
主节点
1 2
# route add -host 172.16.4.3 dev eth2 heartbeat: 2013/01/23_04:26:58 info: Local standby process completed .
heartbeat: 2013/01/23_04:27:02 WARN: 1 lost packet(s) for
heartbeat: 2013/01/23_04:27:02 info: remote resource transition completed.
heartbeat: 2013/01/23_04:27:02 info: No pkts missing from master1!
heartbeat: 2013/01/23_04:27:02 info: Other node completed standby takeover of foreign resources.
6、从库同VIP同步
(1)、master配置
1)、设置server-id值并开启Binlog参数
1 2
3
4
5
# vim /etc/my.cnf log-bin=/usr/local/mysql/mysql-bin
server-id = 3
# /etc/init.d/mysqld restart
注意：只有master1有重启操作，master2无需重启操作，因为备节点的mysql是未启动状态，备节点只有heartbeat才能启动mysql
2)、授权并建立同步账户rep
1 2
# mysql -uroot -p
mysql> GRANT REPLICATION SLAVE ON *.* TO 'rep'@'192.168.4.%'> (2)、slave配置
1)、设置server-id值并关闭binlog设置
1 2
3
4
5
# vim /etc/my.cnf #log-bin=mysql-bin
server-id= 4
# /etc/init.d/mysqld restart
说明：从库无需开启binlog日志功能，除非有需求做级联复制架构或对mysql增量备份操作才开启
2)、配置同步参数
1 2
3
4
5
6
7
8
# mysql -uroot CHANGE MASTER TO
MASTER_HOST='192.168.4.1',
MASTER_PORT=3306,
MASTER_USER='rep',
MASTER_PASSWORD='rep',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=0;
3)、检查是否主从同步
1 2
3
4
5
6
# mysql -uroot mysql> show slave status\G
...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...
(3)、模拟高可用宕机切换是否影响从库同步
1)、主从正常状态
1 2
3
4
5
6
7
8
9
10
11
12
# mysql -uroot mysql> create database coral1;
Query OK, 1 row affected (0.02 sec)
# mysql -uroot -e "show slave status\G"|egrep "Slave_IO_Running|Slave_SQL_Running"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
# mysql -uroot -e "show databases like 'coral%';"
+-------------------+
| Database (coral%) |
+-------------------+
| coral1 |
+-------------------+
2)、模拟高可用主节点宕机
1 2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# /etc/init.d/heartbeat stop 说明：模拟主节点宕机
# ip addr|grep eth1
3: eth1:mtu 1500 qdisc pfifo_fast qlen 1000
inet 192.168.4.3/16 brd 192.168.255.255 scope global eth1
inet 192.168.4.1/16 brd 192.168.255.255 scope global secondary eth1:0
# mysql -uroot
mysql> create database coral2;
Query OK, 1 row affected (0.08 sec)
说明：VIP地址已经漂移到master2上面
# mysql -uroot -e "show slave status\G"|egrep "Slave_IO_Running|Slave_SQL_Running"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
# mysql -uroot -e "show databases like 'coral%'"
+-------------------+
| Database (coral%) |
+-------------------+
| coral1 |
| coral2 |
+-------------------+
注意：高可用主备节点切换过程中，会有一段时间从库才能连接上，大于在60秒内
说明：此时主从同步是正常的
3)、模拟高可用主节点宕机恢复
1 2
3
4
5
6
7
8
9
10
11
12
13
14
15
# /etc/init.d/heartbeat start # mysql -uroot
mysql> create database coral3;
# mysql -uroot -e "show slave status\G"|egrep "Slave_IO_Running|Slave_SQL_Running"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
# mysql -uroot -e "show databases like 'coral%'"
+-------------------+
| Database (coral%) |
+-------------------+
| coral1 |
| coral2 |
| coral3 |
+-------------------+
说明：高可用主节点故障恢复后也不影响主从库的同步
6、高可用脑裂问题及解决方案
(1)、导致裂脑发生的原因
1、高可用服务器之间心跳链路故障，导致无法相互检查心跳
2、高可用服务器上开启了防火墙，阻挡了心跳检测
3、高可用服务器上网卡地址等信息配置不正常，导致发送心跳失败
4、其他服务配置不当等原因，如心跳方式不同，心跳广播冲突，软件BUG等
(2)、防止裂脑一些方案
1、加冗余线路
2、检测到裂脑时，强行关闭心跳检测(远程关闭主节点，控制电源的电路fence)
3、做好脑裂的监控报警
4、报警后，备节点在接管时设置比较长的时间去接管，给运维人员足够的时间去处理(人为处理)
5、启动磁盘锁，正在服务的一方锁住磁盘，裂脑发生时，让对方完全抢不走"共享磁盘资源"
磁盘锁存在的问题：
使用锁磁盘会有死锁的问题，如果占用共享磁盘的一方不主动"解锁"另一方就永远得不到共享磁盘，假如服务器节点突然死机或崩溃，就不可能执行解锁命令，备节点也就无法接管资源和服务了，有人在HA中设计了智能锁，正在提供服务的一方只在发现心跳全部断开时才会启用磁盘锁，平时就不上锁
页:
[1]