MySQL-高可用架构探索

最新推荐文章于 2024-09-19 01:00:00 发布

小小工匠

最新推荐文章于 2024-09-19 01:00:00 发布

阅读量1.2w

点赞数 3

分类专栏：【MySQL基础篇】文章标签： mysql高可用 mmm mha

本文链接：https://blog.csdn.net/yangshangwei/article/details/104130677

版权

【MySQL基础篇】专栏收录该内容

26 篇文章 4 订阅

订阅专栏

生猛干货

带你搞定MySQL实战，轻松对应海量业务处理及高并发需求，从容应对大场面试

官方文档

https://dev.mysql.com/doc/

在这里插入图片描述

如果英文不好的话，可以参考 searchdoc 翻译的中文版本

http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html
在这里插入图片描述

前置学习

要掌握高可用架构，必须先了解主从架构： MySQL-主从架构探索

什么是高可用( HA - High Availability )

通过尽量缩短因日常维护操作（计划内）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统的可用性，这就是高可用。

举个例子：主从同步延时太厉害、主从中断、锁表造成大量的阻塞等等因素都造成了应用的不可用，这些都是影响高可用的因素

其实真正做到100%的可用还是比较困难的，我们经常说到的 5个9 （99.999%）的可用是啥意思呢？

做到 5个9的可用性，那允许停服多长时间呢？我们来算下

（365 * 24 * 60） * （1 - 0.99999） = 5.256 分钟，一年停服时长小于5分钟。

4个9呢？

（365 * 24 * 60） * （1 - 0.9999） = 52. 56 分钟 (1个小时左右)

3个9呢？

（365 * 24 * 60） * （1 - 0.999） = 525.6 分钟 (9个小时左右)

可用性越高，实现的成本相对就高，实际情况根据我们的业务和项目成本来考量。

实现高可用的几点原则

避免系统不可用的因素减少系统不可用的时间

比如服务器磁盘空间不足、表结构和索引没有优化、主从不一致、性能糟糕的SQL、人为操作失误等等

主要的措施：

建立完善的监控和告警系统

1）备份！！！并对备份数据定期进行恢复测试，以便备份数据在紧急情况恢复数据时可用
2）正确的配置数据库环境，特别是从库环境，read_only一定要开启。
3）对不需要的数据进行归档和清理
增加系统冗余，确保发生故障时可以尽快的切到另外的节点恢复

主要的措施有：
1. 避免存在单点故障
2. 主从切换及故障转移
这里我们主要如何解决探讨MySQL的单点故障

避免MySQL单点故障的几种方案

使用SUN共享存储

在这里插入图片描述

共享存储也有单点问题，而且共享存储的随机I/O不是很理想，虽然能实现，但不是一种好的解决MySQL单点故障的方案。

使用DRDB磁盘复制

在这里插入图片描述

提供远程镜像磁盘，数据是由冗余的，没有单点问题，但成本较高。

使用用多写集群（PXC方案）

在这里插入图片描述

集群中的节点全部提交才提交。集群的性能取决于集群中机器配置最低的那台主机的性能。

写入性能比单节点的写入性能差，而且 PXC仅支持Innodb储存引擎。

这个玩意很强大，需要深入学习，淘宝等很多大厂有基于这个的定制，很好用，但得学会。

使用NDB集群

这玩意所有的数据存在内存中，如果内存不足，NDB集群的性能就会非常差。很少在生产环境中使用。

使用MySQL的主从复制

说到使用MySQL主从复制来解决MySQL的单点问题，其核心在于如何解决主节点的单点问题。

要保证主节点高可用，有几点需要解决

主服务器切换后，如何通知应用新的主服务器的IP地址
如何检查MySQL主服务器是否可用
如何处理从服务器和新主服务器之间的那种复制关系

通常都会使用第三方的复制管理组件，主流的MMM 和 MHA ，接下来我们就重点来看下这两种复制管理组件。

MMM （Multi-Master Replication Manager ）

学习这个之前，需要知道，这个玩意很少有人用了，这个项目好多年都不维护了，了解即可。有精力可以重点掌握MHA这种架构。

多主复制器， perl语言开发的

MMM的主要作用

监控和管理MySQL的主主复制拓扑，并在当前的主服务器失效的时候，进行主和主备服务器之间的主从切换和故障转移。

MMM提供的功能

主主复制分为两种模式

主动-主动模式的主主复制（两个主节点都对外提供读写服务）
主动-被动模式的主主复制（仅一个节点对外提供读写服务）

MMM是主动-被动模式的主主复制的模式

MMM监控MySQL主从复制的健康状况
在主库宕机时进行故障转移并自动配置其他从对新主的复制

这里的内容就比较多了：比如如何找到从库对应的新主库日之巅的日志同步点，如何存在多个从库出现数据不一致的情况如何处理 —> MMM采取的方案：找到当前主库的同步点进行同步，所以有数据丢失的可能。

提供了主、写虚拟IO，在主从服务器出现问题的时候可以自动迁移虚拟IP

MMM架构图

在这里插入图片描述

因为同一时间点只能有一个主节点提供读写服务，所以第二个主节点画成了虚线。

MMM监控各个服务器的状态，需要在每台服务器上安装监控服务器。

MMM部署需要的资源

在这里插入图片描述

MMM架构安装和部署

这一部分暂时留空，因为MMM架构使用较少，暂不整理。

MMM架构的优缺点

优点：

开源，使用perl语言开发
提供了读写VIP（虚拟IP），使得服务器交涉的变更对前端应用透明。应用访问DB都是访问的虚拟IP，而非真实的物理IP。在从服务器出现大量的主从延迟，主从链路中断时可以把这台从服务器上的读的虚拟IP，漂移到集群中其他正常的服务器上。
MMM提供了从服务器的延迟监控。监控后，有故障可以自动漂移VIP
MMM提供了主服务器故障转移后从服务器对新主的重新同步功能
很容易对发生故障的主数据库重新上线
监控服务器可以监控多个MMM集群

缺点：