本文主要总结MYSQL高可用相关的介绍和总结
MYSQL采用主从架构来支持高可用。主从架构中必须有一个主节点,以及一个或多个从节点,所有的数据都会先写入到主,接着其他从节点会复制主节点上的增量数据,从而保证数据的最终一致性,使用主从复制方案,可以进一步提升数据库的可用性和性能:
- 在主节点宕机或故障的情况下,从节点能自动切换成主节点的身份,从而继续对外提供服务。
- 提供数据备份的功能,当主节点的数据发生损坏时,从节点中依旧保存着完整数据。
- 可以基于主从实现读写分离,主节点负责处理写请求,从节点处理读请求,进一步提升性能。
但无论任何技术栈的主从架构,都会存在致命硬伤,同时也会存在些许问题需要解决:
- 硬伤:木桶效应,一个主从集群中所有节点的容量,受限于存储容量最低的哪台服务器。
- 数据一致性问题:由于同步复制数据的过程是基于网络传输完成的,所以存储延迟性。
- 脑裂问题:从节点会通过心跳机制,发送网络包来判断主机是否存活,网络故障情况下会产生多主。
上述提到的三个问题中,第一个问题只能靠加大服务器的硬件配置解决,第二个问题相对来说已经有了很好的解决方案(后续讲解),第三个问题则是部署方式决定的,如果将所有节点都部署在同一网段,基本上不会出现集群脑裂问题。
主从复制
采用Binlog来进行主从复制
上述即是主从同步数据的原理图,但在讲解之前先来了解一下两种数据同步的方式:
- 主节点推送:当主节点出现数据变更时,主动向自身注册的所有从节点推送新数据写入。
- 从节点拉取:从节点定期去询问一次主节点是否有数据更新,有则拉取新数据写入。
那MySQL究竟采用的是什么方式呢?其实是从拉的方案,但对其稍微做了一些优化,传统的从拉方案是需要从节点一直与主节点保持长连接,从节点定时或持续性的对主节点做轮询,查看主机的数据是否发生了变更,而MySQL的数据同步原理如下:
- 客户端将写入数据的需求交给主节点,主节点先向自身写入数据。
- 数据写入完成后,紧接着会再去记录一份Bin-log二进制日志。
- 配置主从架构后,主节点上会创建一条专门监听Bin-log日志的log dump线程。
- 当log dump线程监听到日志发生变更时,会通知从节点来拉取数据。
- 从节点会有专门的I/O线程用于等待主节点的通知,当收到通知时会去请求一定范围的数据。
- 当从节点在主节点上请求到一定数据后,接着会将得到的数据写入到relay-log中继日志。
- 从节点上也会有专门负责监听relay-log变更的SQL线程,当日志出现变更时会开始工作。
- 中继日志出现变更后,接着会从中读取日志记录,然后解析日志并将数据写入到自身磁盘中。
Bin-log日志格式:
- Statment:记录每一条会对数据库产生变更操作的SQL语句(默认格式)。
- Row:记录具体出现变更的数据(也会包含数据所在的分区以及所位于的数据页)。
- Mixed:Statment、Row的结合版,可复制的记录SQL语句,不可复制的记录具体数据。
现网一般使用Mixed格式
主从模型不同架构
一主多从架构
读多于写,读写分离,读操作从节点查