标签:
MySQL迁移到Azure上后,由于云的特性,在自建数据中心的MySQL的HA的方法在云上很多都不能部署。
这主要是因为,目前Public Cloud不支持:1. 共享存储;2. Multicast;3. VIP。
本方案中通过DRBD、Corosync、Pacemaker、Azure ILB几个软件解决了上面3个HA部署中的问题,实现MySQL在Azure上的HA部署。
?
整体架构如上图,
正常情况下,Pacemaker把编排好的各种服务在Master上启动后,在Master上MySQL进行任何的数据插入,都会通过DRBD更新到Slave服务器的DRBD Secondary磁盘上。由于在Slave服务器上的MySQL服务不启动,其3306端口不对外提供服务。Azure ILB认为这台服务器是没有提供服务的,负载均衡集中不包含这台服务器。因此Aure ILB只把MySQL的请求发送到Master上。其结构如下:
当10.1.1.6服务器出现故障或重启的动作时,Corosync和Pacemaker会把Master迁移到10.1.1.7上。Pacemaker在10.1.1.7上启动之前编排的各种服务。MySQL在10.1.1.7上启动。由于10.1.1.7提供了3306端口的服务,Azure ILB会把10.1.1.7加入到负载均衡集中,前端MySQL的请求都会发到这台服务器上。具体如下:
10.1.1.6和10.1.1.7两台机器任意一台机器出现故障,整个系统都不需要人工参与,系统会自动迁移到available的服务器上,对外提供服务。
二、防止脑裂问题
由于Cluster中最需要避免的问题是脑裂问题,脑裂甚至比Out-of-service带来的危害更大。因此,需要最大程度的防止脑裂的发生。
在前面提到的方案中,防止脑裂的方式只通过DRBD、Corosync和Pacemaker软件自身实现的。
由于采用了Azure的ILB,可以采用对ILB进行配置的方式实现防止脑裂的方案。
当Pacemaker选择一台服务器作为Master时,在Pacemaker服务的编排中,加入对Azure ILB的控制,把另外一台服务器从ILB中移除,把自己加入到ILB中。结构如下:
极端情况,两台服务器都自认为是Master的情况,后一台启动Pacemaker的服务器会把另外一台服务器从ILB中移除。从而在ILB中只有一台VM,保证前端服务器通过ILB只能访问到一台MySQL服务器。
MySQL on Azure高可用性设计 DRBD - Corosync - Pacemaker - CRM (一)
标签:
原文地址:http://www.cnblogs.com/hengwei/p/5021195.html