MYSQL系列-高可用部署和异常恢复

本文主要总结MYSQL高可用相关的介绍和总结
MYSQL采用主从架构来支持高可用。主从架构中必须有一个主节点，以及一个或多个从节点，所有的数据都会先写入到主，接着其他从节点会复制主节点上的增量数据，从而保证数据的最终一致性，使用主从复制方案，可以进一步提升数据库的可用性和性能：

• 在主节点宕机或故障的情况下，从节点能自动切换成主节点的身份，从而继续对外提供服务。
• 提供数据备份的功能，当主节点的数据发生损坏时，从节点中依旧保存着完整数据。
• 可以基于主从实现读写分离，主节点负责处理写请求，从节点处理读请求，进一步提升性能。

但无论任何技术栈的主从架构，都会存在致命硬伤，同时也会存在些许问题需要解决：

• 硬伤：木桶效应，一个主从集群中所有节点的容量，受限于存储容量最低的哪台服务器。
• 数据一致性问题：由于同步复制数据的过程是基于网络传输完成的，所以存储延迟性。
• 脑裂问题：从节点会通过心跳机制，发送网络包来判断主机是否存活，网络故障情况下会产生多主。

上述提到的三个问题中，第一个问题只能靠加大服务器的硬件配置解决，第二个问题相对来说已经有了很好的解决方案（后续讲解），第三个问题则是部署方式决定的，如果将所有节点都部署在同一网段，基本上不会出现集群脑裂问题。

主从复制

采用Binlog来进行主从复制

 

上述即是主从同步数据的原理图，但在讲解之前先来了解一下两种数据同步的方式：

• 主节点推送：当主节点出现数据变更时，主动向自身注册的所有从节点推送新数据写入。
• 从节点拉取：从节点定期去询问一次主节点是否有数据更新，有则拉取新数据写入。

那MySQL究竟采用的是什么方式呢？其实是从拉的方案，但对其稍微做了一些优化，传统的从拉方案是需要从节点一直与主节点保持长连接，从节点定时或持续性的对主节点做轮询，查看主机的数据是否发生了变更，而MySQL的数据同步原理如下：

1. 客户端将写入数据的需求交给主节点，主节点先向自身写入数据。
2. 数据写入完成后，紧接着会再去记录一份Bin-log二进制日志。
3. 配置主从架构后，主节点上会创建一条专门监听Bin-log日志的log dump线程。
4. 当log dump线程监听到日志发生变更时，会通知从节点来拉取数据。
5. 从节点会有专门的I/O线程用于等待主节点的通知，当收到通知时会去请求一定范围的数据。
6. 当从节点在主节点上请求到一定数据后，接着会将得到的数据写入到relay-log中继日志。
7. 从节点上也会有专门负责监听relay-log变更的SQL线程，当日志出现变更时会开始工作。
8. 中继日志出现变更后，接着会从中读取日志记录，然后解析日志并将数据写入到自身磁盘中。

Bin-log日志格式：

• Statment：记录每一条会对数据库产生变更操作的SQL语句（默认格式）。
• Row：记录具体出现变更的数据（也会包含数据所在的分区以及所位于的数据页）。
• Mixed：Statment、Row的结合版，可复制的记录SQL语句，不可复制的记录具体数据。

现网一般使用Mixed格式

主从模型不同架构

一主多从架构

 

读多于写，读写分离，读操作从节点查