258资源分享网

 一、当前高可用方案

1、Heartbeat+DRBD

2、MySQL Cluster

3、全局事务ID

4、PXC

5、MHA的优势

1）故障切换快

2）master故障不会导致数据不一致

3）无需修改当前的MySQL设置

4）无需增加大量的服务器

5）无性能下降

6）适用于任何存储引擎

二、MHA简介：

1、MHA结构

1）MHA Manager

1.Manager工具包主要工具

2）MHA Node

1.Node工具包

3）注意

2、MAH工作原理

三、部署MHA

1、环境准备

2、安装epel源

3、环境初始化

1）修改每台主机名

2）主机名解析

3）ssh无密码登录

四、规划mysql

1）安装mysql

2）配置master、slave01和slave02之间的主从复制

3）在master、slave01上创建主从同步的账号。

4）在master上执行命令，查看master状态信息

5）在slave01和slave02上执行主从同步

五、规划mha

1）创建mha管理用的复制账号

2）在3台主机上(master、slave01和slave02)上分别安装mha4mysql-node包

3）在manager上安装mha4mysql-manager和mha4mysql-node包

4）修改manager端mha的配置文件

5）检查ssh是否畅通

6）masterha_check_repl工具检查mysql主从复制是否成功

六、mha实验模拟

1）在每次做mha实验的时候，我们都最好先执行如下命令做检测

2）在manager端启动mha服务并时刻监控日志文件的输出变化

3）测试master宕机后会自动切换

4）恢复master服务

5）再次启动MHA的manager服务，并停止slave01

6）恢复slave01服务

7）重启MHA的manager服务

七、通过vip实现mysql的高可用

1）修改/usr/local/mha/mha.cnf

2）修改脚本/usr/local/mha/scripts/master_ip_failover

3）模拟故障进行切换

八、MHA日常维护命令

1、查看ssh登陆是否成功

2、查看复制是否建立好

3、启动mha

4、检查启动的状态

5、停止mha

6、failover后下次重启

九、FAQ（常见问题解答）

1、可能报错1

2、可能报错2

3、可能报错3

4、可能报错4

5、可能报错5

6、小知识

一、当前高可用方案 1、Heartbeat+DRBD

开销：需要额外添加处于被动状态的master server（并不处理应用流量） 性能：为了实现DRBD复制环境的高可用，innodb-flush-log-at-trx-commit和sync-binlog必须设置为1，这样会导致写性能下降。

一致性：在master上必要的binlog时间可能会丢失，这样slave就无法进行复制，导致产生数据一致性问题。

2、MySQL Cluster

MySQL Cluster真正实现了高可用，但是使用的是NDB存储引擎，并且SQL节点有单点故障问题。

半同步复制(5.5+) 半同步复制大大减少了“binlog events只存在故障master上”的问题。

在提交时，保证至少一个slave（并不是所有的）接收到binlog，因此一些slave可能没有接收到binlog。

3、全局事务ID

在二进制文件中添加全局事务ID（global transaction id）需要更改binlog格式，在5.1/5.5版本中不支持。

在应用方面有很多方法可以直线全局事务ID，但是仍避免不了复杂度、性能、数据丢失或者一致性的问题。

4、PXC

PXC实现了服务高可用，数据同步时是并发复制。但是仅支持InnoDB引擎，所有的表都要有主键。锁冲突、死锁问题相对较多等等问题。

5、MHA的优势 1）故障切换快

在主从复制集群中，只要从库在复制上没有延迟，MHA通常可以在数秒内实现故障切换。9-10秒内检查到master故障，可以选择在7-10秒关闭master以避免出现裂脑，几秒钟内，将差异中继日志（relay log）应用到新的master上，因此总的宕机时间通常为10-30秒。恢复新的master后，MHA并行的恢复其余的slave。即使在有数万台slave，也不会影响master的恢复时间。

2）master故障不会导致数据不一致

当目前的master出现故障是，MHA自动识别slave之间中继日志（relay log）的不同，并应用到所有的slave中。这样所有的salve能够保持同步，只要所有的slave处于存活状态。和Semi-Synchronous Replication一起使用，（几乎）可以保证没有数据丢失。

3）无需修改当前的MySQL设置

MHA的设计的重要原则之一就是尽可能地简单易用。MHA工作在传统的MySQL版本5.0和之后版本的主从复制环境中。和其它高可用解决方法比，MHA并不需要改变MySQL的部署环境。MHA适用于异步和半同步的主从复制。

启动/停止/升级/降级/安装/卸载MHA不需要改变（包扩启动/停止）MySQL复制。当需要升级MHA到新的版本，不需要停止MySQL，仅仅替换到新版本的MHA，然后重启MHA　Manager就好了。

MHA运行在MySQL 5.0开始的原生版本上。一些其它的MySQL高可用解决方案需要特定的版本（比如MySQL集群、带全局事务ID的MySQL等等），但并不仅仅为了master的高可用才迁移应用的。在大多数情况下，已经部署了比较旧MySQL应用，并且不想仅仅为了实现Master的高可用，花太多的时间迁移到不同的存储引擎或更新的前沿发行版。MHA工作的包括5.0/5.1/5.5的原生版本的MySQL上，所以并不需要迁移。

4）无需增加大量的服务器

MHA由MHA Manager和MHA Node组成。

MHA Node运行在需要故障切换/恢复的MySQL服务器上，因此并不需要额外增加服务器。

MHA Manager运行在特定的服务器上，因此需要增加一台（实现高可用需要2台），但是MHA Manager可以监控大量（甚至上百台）单独的master，因此，并不需要增加大量的服务器。即使在一台slave上运行MHA Manager也是可以的。综上，实现MHA并没用额外增加大量的服务。

5）无性能下降

MHA适用与异步或半同步的MySQL复制。监控master时，MHA仅仅是每隔几秒（默认是3秒）发送一个ping包，并不发送重查询。可以得到像原生MySQL复制一样快的性能。

6）适用于任何存储引擎

MHA可以运行在只要MySQL复制运行的存储引擎上，并不仅限制于InnoDB，即使在不易迁移的传统的MyISAM引擎环境，一样可以使用MHA。