MySQL高可用架构-MMM、MHA、MGR、分库分表

总结

MMM是是Perl语言开发的用于管理MySQL主主同步架构的工具包。主要作用：管理MySQL的主主复制拓扑，在主服务器失效时，进行主备切换和故障转移。

MMM缺点：故障切换可能会丢事务(主备使用半同步复制解决)。不支持GTID。社区不活跃。MMM无法完全的保证数据一致性，所以适用于对数据的一致性要求不是很高的场景。（因为主备上的数据不一定是最新的，可能还没

从库的新。解决方法：开启半同步）。

MHA是开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了故障转移功能。MHA提供了一个虚拟IP暴露给应用，这个虚拟IP在故障转移发生时可以进行飘移。还有一个MHA管理者可以管理MHA中的node节点，他的作用是在发生故障时可以指挥故障转移，可以对主节点进行健康检查。

MHA优点：可以支持GTID复制，可以选举最合适的slave成为master。

MHA缺点：需要自行开发实现VIP的配置，只监控了主节点是否可用，没有监控从节点。

主从复制如何工作

在主库把数据记录到binlog（二进制日志）。
备库开IO线程把binlog复制到自己的relaylog（中继日志）。
备库读取中继日志，重放到备库上。

半同步复制

半同步复制可以确保备库拥有主库数据的拷贝，减少了数据丢失的危险。

半同步复制指的就是主库写入 binlog 日志之后，就会将数据同步到从库的 relay log 之后，会返回一个 ack 给主

库，主库接收到至少一个从库的 ack 之后才会认为写操作完成了。如果一直没有响应，会超时转化为异步复制。

半同步和异步复制区别是：半同步会延迟通知客户端。

半同步复制的潜在问题

客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时，事务还没发送到从库上，此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。针对潜在问题，MySQL 5.7引入了一种新的半同步方案：将“Waiting Slave dump”被调整到“Storage Commit”之前。

半同步不会阻塞主库上的事务提交，只有通知客户端被延迟了。
备库在接收到事务后发送ack而不是完成事务后发送。
如果备库一直没有回应，会超时转化为异步复制模式。

配置步骤

在master服务器上

开启binlog开启gtid。

建立同步所用的数据库账号。

使用master_data参数备份数据库。

把备份文件传输到slave。

在slave上操作

开启binlog开启gtid。

恢复master上的备份数据库。

使用change master配置链路。

使用start slave启动复制。

GTID和日志点

日志点复制

slave请求master的增量日志依赖于日志偏移量。
配置链路时需要指定参数。
支持MMM和MHA。

GTID复制

全局事务ID唯一，GTID=source_id:transaction_id。
slave增量同步master的数据依赖于其未同步的事务ID。
配置链路时，slave根据已经同步的事务ID继续自动同步。
支持MHA。

复制方式选择

兼容老版本和MMM选择日志点复制。
其他选择GTID复制。

‌MMM架构和MHA架构

MMM和MHA架构的作用

对主从复制集群中的master的健康监控。
当master宕机后把写VIP迁移到新的master。
重新配置集群中的其他slave对新的master同步。

MMM的主从复制架构

MMM是perl语言开发的用于管理MySQL主主同步架构的工具包。

主要作用：管理MySQL的主主复制拓扑，在主服务器失效时，进行主备切换和故障转移。

MMM无法完全的保证数据一致性，所以适用于对数据的一致性要求不是很高的场景。（因为主备上的数据不一定是最新的，可能还没从库的新。解决方法：开启半同步）。

VIP是基于ARP协议，因此所有节点必须处于同一局域网。

MMM架构的故障转移步骤

SLAVE：
- 已复制日志的恢复。
- 使用Change Master命令配置新主。
主备：
- 关掉read_only。
- 迁移写VIP到新主。

MMM架构的配置步骤

配置主主复制的集群架构。

安装centos的yum扩展包。

安装所需的perl支持包。

安装mmm工具包。

配置并启用mmm服务。

MMM优点

提供了读写VIP的配置。

MMM缺点

故障切换会丢事务(主备使用半同步复制解决)。
不支持GTID。
社区不活跃。

MHA故障转移步骤

选出最新更新的slave。
尝试从宕机的master保存二进制日志。
应用差异的中继日志给到其他slave。
应用从master保存的二进制日志。
提升选举的slave为新的master。
配置其他slave向新的master同步。

MHA需要的资源

1主DB。

2-N从DB。

n+2IP地址。

监控用户。

复制用户。

MHA配置步骤

配置一主多从的复制架构。

安装centos的yum扩展源和依赖包。

配置集群内各主机的ssh免认证。

各节点安装mha_node软件。

管理节点安装mha_manager。

配置并启动mha管理进程。

MHA优点

基于gtid和日志点。
选举最合适的slave成为master。

MHA缺点

需要自行开发写vip脚本。
只监控master。

适用场景

使用gtid。
一主多从。
更少的数据丢失场景。

‌如何减小主从复制的延迟

主从复制延迟的原因

执行了大事务(解决：化为多个小事务)。

解决方法

多线程复制。
使用MGR复制架构(类似PXC)。

MGR架构

MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用解决方案，以插件形式提供。

MGR基于分布式Paxos协议，实现组复制，保证数据一致性。有故障检测和自动选主功能。

提供单主模式与多主模式，多主模式支持多点写入。

基于ROW格式的二进制日志文件和GTID特性。

实现原理

MGR由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。

引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案（迫真）。

单主模式

MGR优缺点:

组内成员基本无延迟。
支持多写，读写服务高可用。
数据强一致，不丢事务。

MGR缺点:

单主模式很难确认下一个primary。
只能gtid，日志格式必须为row。

场景

主从延迟敏感。
数据强一致。
读写高可用。

‌如何解决读写负载大的问题

读负载大

读写分离加slave。
数据库中间层做负载均衡。

写负载大

Mycat分库分表。

分库分表相关知识

切分方式

垂直切分：是按照业务对数据表分类，比如用户表，商品表可以分成多个表，作用是可以分散数据库的访问压力，这样做并不能减少单表的数据量。
水平切分：是按照某个字段的某种规则，把数据切分到多张数据表。

分片集群的两种算法

分库分表集群模式适用于十亿级数据总量大型应用

范围法，例如有三个节点，第一个节点存放1-2亿数据，第二个节点存放2-3亿数据，第三个节点存放3-4亿数据。优点是加节点比较方便，缺点是数据可能存放的不均匀。
hash法，用id取模的方法均匀的存到节点中，好处是数据分配均衡，缺点是节点不容易扩展，需要提前部署足够的节点。

互联网主流MySQL集群架构

读写分离和分片的组合运用。在中间件下挂载三个主库的分片，为了读写分离和高可用，主库下有两个从库可以备份数据和查询数据。再配合MHA、MGR进行一个故障转移。

扩展知识：VIP与脑裂

VIP的工作原理是，

为当期主机配置一个虚拟网卡，如eth0:0，该网卡绑定了唯一的MAC地址和虚拟IP地址VIP

局域网内的主机欲与该VIP通信时，先通过ARP协议取到该VIP对应的MAC地址，再将VIP与MAC地址的对应关系缓存在其主机上

后续通信时，使用上一步骤取到的MAC作为报文的MAC地址

VIP切换的原理是，

将旧master绑定的虚拟网卡注销掉

在新的master注册新的虚拟网卡（产生了新的MAC地址）

通知局域网节点更新VIP与MAC的对应关系，后续通信采用新MAC地址

脑裂的原因，在于旧master节点没有正常将VIP摘掉，这时局域网机器通过ARP获取VIP的MAC时，就可能取到旧的MAC地址，导致与旧master通信。什么情况会出现这种情况呢？旧master由于上层交换机故障，未与manager节点正常通信，此时VIP是没有摘除掉的，过了一段时间上层交换机恢复了就会导致此问题。

https://zhangjunjia.github.io/2019/03/16/mysql-mmm-mha/

https://www.pianshen.com/article/13731481649/

Reference

MySQL相关视频