14 数据库高可用

MHA工作原理

MHA的组成

MHA由node和manager组成；

MHA Node(数据节点)：

相当于监控客户端,所有数据库机器都需要部署node

MHA Manager(管理节点)

Manager相当于服务端，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master(如果原主库恢复，只能当从库)。

通常单独部署在一台独立机器上管理多个 master/slave 集群(组)，每个 master/slave 集群称作一个 application，用来管理统筹整个集群。

Manager应该尽量避免部署在主库上，否则主机一挂则全挂，不仅主库完蛋了，负责自动迁移的Manager也完蛋了，也没人负责自动故障迁移了，导致架构不可用了。

可以考虑部署在某一个slave上，此时这台主机挂掉了，只是挂了一个slave，以及Manager，如果此时你不是倒了霉，(主库也挂了)，那还不至于架构不可用。但有一点需要注意的是：如果Manager部署在slave上，那么该slave就无法被升级为主库；

　由上图我们可以看出，每个复制组内部和 Manager 之间都需要ssh实现无密码互连，只有这样，在 Master 出故障时， Manager 才能顺利的连接进去，实现主从切换功能。

MHA自动故障切换的步骤

(1)， Manager会每隔3秒钟探测一次MASTER主库； (Hi, 主库你还活着吗？)

ping_interval 控制间隔时间；ping_type 控制探测方式，SELECT(执行SELECT 1)和CONNECT(创建连接/断开连接)

(2)，如果Manager探测到MASTER主库故障、无法访问，Manager会执行下面操作：

1、从其他node发起ssh连接，检查主库是否能够SSH上去；2、从其他node发起mysql连接，检查MASTER库是否能够登陆；

(3)，如果所有Node节点ssh连接、msyql主库连接均连接失败，则开始故障转移，

简单地说

1.找到数据最新的从库(通过对比relay-log，查看show slave status即可)
2.将最新的从库上的新数据同步到其他从库
3.提升一个从库为主库(一般情况提升数据最新的，二般情况提升我们指定的从库为主库)
4.通过原来主库的binlog补全新的主库数据
5.其他从库以新的主库为主做主从复制

详细步骤如下：

Phase 1	Configuration Check Phase..	检查数据库版本检查是否启用GTID检查从库是否存活检查配置文件的candidate
Phase 2	Dead Master Shutdown Phase.	该阶段会调用master_ip_failover脚本；去关闭所有Node的IO Thread调用shutdown_script 强制关闭MASTER实例，防止应用程序来连接；
Phase 3	Master Recovery Phase..
Phase 3.1	Getting Latest Slaves Phase.	检查所有节点，从show slave status中对比获取最新的binlog/position
Phase 3.2	Saving Dead Master's Binlog Phase..	如果老的Master可以SSH，上去获取BINLOG，从position到END位置，获取这段BINLOG(MASETER产生这段BINLOG，还未来得及发送给SLAVE)将这部分日志发送给Manager节点(manager_workdir位置)；如果故障Master无法SSH，则无法获取这段日志
Phase 3.3	Determining New Master Phase..	对比所有SLAVE，从最新SALVE中同步差异realy log给其他slave;最终确保所有SLAVE数据一致
Phase 3.3	New Master Diff Log Generation Phase..	确认新master 是否为最新slave，如果不是，则从最新slave获取差异日志；将manager上获取的BINLOG日志发送给new master；
Phase 3.4	Master Log Apply Phase..	对比新master的Exec_Master_Log_Pos和Read_Master_Log_Pos，判断恢复的位置；在本地回放 3.3 Phase的差异日志；获取新master的binlog和position；
Phase 4	Slaves Recovery Phase..
Phase 4.1	Starting Parallel Slave Diff Log Generation Phase.	对每个SLAVE恢复：所有SLAVE和最新Slave做对比，如果position不一致，则生产差异日志
Phase 4.2	Starting Parallel Slave Log Apply Phase.	每个SLAVE 应用差异日志；执行CHANGE MASTER 挂在到新Master
Phase 5	New master cleanup phase..	reset slave all;

### MHA的优点总结

1、自动的故障检测与转移，通常在10-30秒以内;

2、MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内即可完成。

3、很好地解决了主库崩溃数据的一致性问题

4、不需要对当前的mysql环境做重大修改

5、不需要在现有的复制框架中添加额外的服务器，仅需要一个manager节点，而一个Manager能管理多套复制，所以能大大地节约服务器的数量;

6、性能优秀，可以工作在半同步和异步复制框架，支持gtid，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。

7、只要replication支持的存储引擎都支持MHA，不会局限于innodb

8、对于一般的keepalived高可用，当vip在一台机器上的时候，另一台机器是闲置的，而MHA中并无闲置主机。

GTID主从复制

介绍

从MySQL 5.6.2 开始新增了一种基于 GTID 的复制方式，用以替代以前传统的复制方式，到MySQL5.6.10后逐渐完善。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性，故障恢复以及容错能力，那么它如何做到的呢？要想在分布式集群环境中不丢失事务，就必须为每个事务定制一个全局唯一的ID号，并且该ID是趋势递增的，以此我们便可以方便地顺序读取、不丢事务，其实GTID就是一种很好的分布式ID实践方案，它满足分布ID的两个基本要求
1)全局唯一性
2)趋势递增GTID (Global Transaction ID全局事务ID)是如何做到全局唯一且趋势递增的呢，它是由UUID+TID两部分组成UUID是数据库实例的标识符TID表示事务提交的数量，会随着事务的提交递增#具体形式：5426a3c1-ade1-11e9-90b3-000c29bb4490:23
因此他与主库上提交的每个事务相关联,GTID不仅对其发起的服务器是唯一的，而且在给定复制设置中的所有服务器都是唯一的，即所有的事务和所有的GTID都是1对1的映射。当在主库上提交事务或者被从库应用时，可以定位和追踪每一个事务，对DBA来说意义就很大了，我们可以适当的解放出来，不用手工去可以找偏移量的值了，而是通过CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION=1的即可方便的搭建从库，在故障修复中也可以采用MASTER_AUTO_POSITION=‘X’的方式。5.7版本GTID做了增强，不手工开启也自动维护匿名的GTID信息

一个GTID的生命周期

1.事务在主库上执行并提交给事务分配一个gtid(由主库的uuid和该服务器上未使用的最小事务序列号)，该GTID被写入到binlog中。2.备库读取relaylog中的gtid，并设置session级别的gtid_next的值，以告诉备库下一个事务必须使用这个值3.备库检查该gtid是否已经被其使用并记录到他自己的binlog中。slave需要担保之前的事务没有使用这个gtid，也要担保此时已分读取gtid，但未提交的事务也不恩呢过使用这个gtid.4.由于gtid_next非空，slave不会去生成一个新的gtid，而是使用从主库获得的gtid。这可以保证在一个复制拓扑中的同一个事务gtid不变。由于GTID在全局的唯一性，通过GTID，我们可以在自动切换时对一些复杂的复制拓扑很方便的提升新主库及新备库，例如通过指向特定的GTID来确定新备库复制坐标。

基于GTID部署主从复制

注意：

14 数据库高可用相关推荐

美团数据库高可用架构的演进与设想
本文介绍最近几年美团MySQL数据库高可用架构的演进过程,以及我们在开源技术基础上做的一些创新.同时,也和业界其它方案进行综合对比,了解业界在高可用方面的进展,和未来我们的一些规划和展望. 在2015 ...
基于Consul的数据库高可用架构【转】
几个月没有更新博客了,已经长草了,特意来除草.本次主要分享如何利用consul来实现redis以及mysql的高可用.以前的公司mysql是单机单实例,高可用MHA加vip就能搞定,新公司mysql是 ...
14、高可用keepalived搭建及切换
14.高可用keepalived搭建及切换 keepalived主从切换试验: 1.先搭建192.168.1.20与192.168.1.21的主主架构 192.168.1.76为VIP 2.在 ...
数据库高可用实战案例-------架构优化之清爽一夏
说到高可用,看官们会想到很多方案,也许是自亲身经历过系统从单机变成高可用的痛苦过程,也许有的看官只是在自己的虚机上搭建过测试的玩具.今天本篇用我自己的真实经历给大家讲述,不管怎么样实战和测试玩耍还是很 ...
Windows2008管理---第14章高可用群集和QoS
第14章高可用群集和QoS 目录第1章高可用群集和QoS. 1<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com ...
(转)Oracle与DB2在数据库高可用技术上的相同与差异探讨
原文:http://www.talkwithtrend.com/Article/178339 数据库建设过程中,高可用是每一个企业数据中心数据库建设过程中至关重要的一个关注点,直接关系到业务连续性和稳 ...
数据库高可用(HA)技术有哪些？
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取数据库高可用是一个复杂的系统工程,本文主要介绍了几种数据库高可用的基本技术 ...
数据库高可用架构转载
数据库高可用架构对于我们这些应用端开发的人来说是一个比较陌生的领域,是在具体的数据库产品之上搭建的环境,需要像DBA这样对数据库产品有足够的了解才能有所涉及,虽然不能深入其中,但可以通过一些经典的高可 ...
mysql datahost ha_mysql MySQL数据库高可用HA实现
起因:在工作中常常要用到mysql,平常只是对数据库crud,并没有认真的了解过她,sql语句也只是会一些最基本的,和常用的,一些不常用的都要去网上百度,即决定学习一下mysql,来了解她,虽然开发很 ...