目录
Mysql主从复制的基本原理与配置,这里就不进行解释了,请参考文档:mysql 主从复制(mysql双机热备的实现)
1、主从复制延迟出现的原因?
MySQL默认的复制即是异步的,主库在执行完客户端提交的事务后会立即将结果返给给客户端,并不关心从库是否已经接收并处理。这时主如果crash掉了,主上已经提交的事务可能并没有传到从上
如果此时,强行将从提升为主,可能导致新主上的数据不完整。正是因为Mysql主从复制是异步复制,所以天然存在主从复制延迟的问题。
2、常用的解决方案
2.1 半同步复制
介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制,半同步复制提高了数据的安全性,
同时它也造成了一定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。所以,推荐半同步复制在小事务,低延时的网络中使用,可以实现在性能很小损失的情况下的零数据丢失。
从MySQL5.5开始,MySQL以插件的形式支持半同步复制。Mysql半同步复制插件使用
2.2 客户端双读
在一些对数据实时性要求比较高的场景,查询数据,如果从读数据源Slave DataSource未查询到数据记录,则再从Master DataSource进行数据查询,这可以解决新增数据场景未及时复制,但是更新的场景可能读到的
数据不是最新的情况。
2.3 客户端强制走主库
在一些对数据实时性要求比较高的场景,查询数据,直接访问Master DataSource,相比“客户端双读”方案,这个可以解决插件、更新场景复制延迟问题,但是对主库的压力会大了一点。
NetLog早期采用这种方式,Netlog 的数据库及 LAMP 架构
2.4 Galery Cluster
Galera Cluster是由Codership开发的MySQL多主集群,包含在MariaDB中,同时支持Percona xtradb、MySQL,是一个易于使用的高可用解决方案,在数据完整性、可扩展性及高性能方面都有可接受的表现。
图1所示为一个三节点Galera 集群,三个MySQL实例是对等的,互为主从,这被称为多主(multi-master)架构。当客户端读写数据时,可连接任一MySQL实例。对于读操作,从每个节点读取到的数据都是相同的。
对于写操作,当数据写入某一节点后,集群会将其同步到其它节点。这种架构不共享任何数据,是一种高冗余架构。
Galera集群具有以下特点:
- 多主架构:真正的多主多活群集,可随时对任何节点进行读写。
- 同步复制:集群不同节点之间数据同步,某节点崩溃时没有数据丢失。
- 数据一致:所有节点保持相同状态,节点之间无数据分歧。
- 并行复制:重放支持多线程并行执行以获得更好的性能。
- 故障转移:故障节点本身对集群的影响非常小,某节点出现问题时无需切换操作,因此不需要使用VIP,也不会中断服务。
- 自动克隆:新增节点会自动拉取在线节点的数据,最终集群所有节点数据一致,而不需要手动备份恢复。
- 应用透明:提供透明的客户端访问,不需要对应用程序进行更改。
2.5 MyCat故障切换功能
MyCat会监控从机的IO Running State、Sql Running State、Senonds_Behind_Master,设置一个阈值,如果超过阈值可以认为从库异常,该从库不会参与load balance。