持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第4天，点击查看活动详情
MySQL系列文章
背景
为了避免单台数据库意外宕机引发单点故障导致生产环境瘫痪，一般都会在数据库层做相应的集群处理。网上对MySQL集群方案的整理都比较凌乱，今天来整理一下高可用方案。
高可用方案
主要分成主从复制（一主多从）；MMM架构（双主多从）；MHA架构（多主多从）三种解决方案。
主从复制
主从复制原理
Master 数据库只要发生变化，立马记录到Binlog 日志文件中，Slave数据库启动一个I/O thread连接Master数据库，请求Master变化的二进制日志。Slave I/O获取到的二进制日志，保存到自己的Relay log 日志文件中。Slave 有一个 SQL thread定时检查Realy log是否变化，变化那么就更新数据
半同步复制
异步同步binlog复制数据会产生主从数据不一致的情况 。 MySQL在5.6版本中推出半同步复制，在同步数据协议中添加了一个同步操作，这样意味主节点在commit操作，需要确认最少一个从节点确认接收到并且返回ACK，只有这样主节点才能正确提交数据。
组复制
MySQL于2016年12月发布MySQL 5.7.17推出的一个全新高可用和高扩展的解决方案。组复制， MySQL MGR 集群最少3个server节点共同组成的分布式集群，一种share-nothing复制方案(每个节点之间仅有网络通信，不存在数据交互)，每个server节点都有完整的副本
- 故障检测
组复制不需要依赖外部工具，自带提供一种故障检测机制，这个机制能报告哪个组成员是无响应的，并且如何判断该成员是否排除集群组。
假设服务器A在预定时间段内未收到来自服务器B的消息，如果组内其他成员也同样未收到来自服务器B的消息，那么确认判断B发生故障，这样由其他成员判定将失联组成员从集群中剔除。
此时服务器B与其他服务节点都无法联系，处于游离状态，不能对外提供服务。
- 容错
MySQL组复制构建在Paxos分布式算法基础上实现的，需要节点数量半数以上server处于活动状态以防止脑裂。
实践中组里必须有三个server，如果出现一个故障，仍然有两个服务器形成半数以上原则继续提供服务。如果第二个server意外地宕掉则整个集群done掉。
MMM架构
两主多从架构，还是基于主从复制，增加了master备用机制
-
工作流程
- 主备服务器切换为备用主服务器
- 主备服务器迁移写VIP到自己
- 从服务器切换指向新的主服务器
- 完成原主服务器上已复制日志的恢复。
- 使用Change Master to命令连接指向新的主服务器。
-
缺点
-
无法完全保证数据的一致性。如主1挂了，MMM monitor已经切换到主2上来了，而若此时双主复制中，主2数据落后于主1（即还未完全复制完毕），那么此时的主2已经成为主节点，对外提供写服务，从而导致数据不一。
-
MHA架构
开源的 MySQL 高可用程序，当下比较成熟的解决方案，基于标准的主从复制提供了故障转换功能。但是缺少虚拟ip，需要配合keepalived等一起使用。
MHA节点分为管理节点(类似哨兵) 和数据节点。管理节点会定时探测集群中的master节点，当 master节点出现故障时，它可以自动将拥有最新数据的 slave 节点提升为新的master节点。
并且一个MHA Manager可以管理多个集群，组成MHA集群最少需要4个节点。manager管理节点一台，数据节点三台（一主两从）
-
工作流程
- MAH 的目的在于维护 MySQL复制中master库的高可用性。
- 从宕机崩溃的 master 保存二进制日志事件（bin log events）。
- 识别含有最新更新的slave。
- 应用差异的中继日志（relay log）到其他的 slave。
- 把 master 保存的二进制日志事件（bin log events）应用到要提升为 master 节点的 slave。
- 解除这个 slave 的只读模式，并提升为新 master。
- 让其他的 slave 连接到新的 master 进行复制。
-
缺点
- MHA架构实现读写分离，最佳实践是在应用开发设计时提前规划读写分离事宜，在使用时设置读连接池与写连接池，或选择折中方案即引入SQL Proxy。
- 手动处理负载均衡
