mysql怎么实现高可用 consul mysql高可用( 三 )


keepalived+双主复制: 两台MySQL互为主从关系,即双主模式,通过Keepalived配置虚拟IP,实现当其中的一台数据库故障时,自动切换VIP到另外一台MySQL数据库,备机快速接管业务来保证数据库的高可用 。
MHA:MHA部署在每台mysql服务器上,定时探测集群中的master节点,当master出现故障时,它可以自动将最新的slave提升为新的master , 然后将所有其他的slave重新指向新的master , 优点在最大程度保证数据的一致性的前提下实现快速切换,最少需要3台服务器,存在数据丢失的可能性 。
PXC:Percona eXtra Cluster是Percona基于galera cluster封装的集群方案 。不同于普通多主复制,PXC保障强一致性和实时同步,故障切换更快 。但是也需要3个节点,配置相对复杂,对性能也稍有影响 。
除了上述方案外 , 还有MMM、Heartbeat+DRBD等高可用方案,此处不做详细介绍 。
综合评估下,本次实施采用了 keepalived+mysql双主实现数据库同城双机房的高可用 。MySQL版本为: 5.7.21 。操作系统:Red Hat Enterprise Linux Server 7.3 。
配置过程如下:
Mysql-master1: IP地址1 --以下简称master1
Mysql-master2: IP地址2 --以下简称master2
Mysql-vip : VIP地址 --应用连接使用
Mysql复制相关概念描述:
1、 Mysql主从复制图示:
2、 Mysql主从复制过程描述:
(1)master记录二进制日志:在每个事务更新数据完成之前,master在二进制日志记录这些改变 。MySQL将事务写入二进制日志 。在事务写入二进制日志完成后,master通知存储引擎提交事务 。
(2)slave将master的binarylog拷贝到自己的中继日志:首先,slave开始一个工作线程——I/O线程 。I/O线程在master上打开一个普通的连接 , 然后开始binlog dump process 。Binlog dump process从master的二进制日志中读取事务,如果已经同步了master,它会睡眠并等待master产生新的事件 。I/O线程将这些事务写入中继日志 。
(3)SQL slave thread处理该过程的最后一步:SQL线程从中继日志读取事务 , 并重放其中的事务而更新slave的数据,使其与master中的数据一致 。只要该线程与I/O线程保持一致,中继日志通常会位于OS的缓存中,所以中继日志的开销很小 。
主主同步就是两台机器互为主的关系,在任何一台机器上写入都会同步至备端 。
为了便于后续数据库服务器的扩展,且在整个复制环境中能够自动地切换,降低运维成本,引入了当前主流的基于Mysql GTID的复制特性,工作原理及优缺点简介如下 。
3、 GTID工作原理简介:
(1) master更新数据时,会在事务前产生GTID,一同记录到Binlog日志中 。
(2) slave的I/O线程将变更的binlog写入到本地的relay log中 。
(3) slave的sql线程从relay log中获取GTID,然后对比slave端的binlog是否有记录 。
(4) 如果有记录说明该GTID的事务已经执行,slave会忽略 。
(5) 如果没有记录,slave就会从relay log中执行该GTID的事务 , 并记录到binlog 。
(6) 在解析的过程中会判断是否有主键 , 如果有就用索引,如果没有就用全部扫描 。
4、 GTID优点:
(1) 一个事务对应一个唯一的ID,一个GTID在一个服务器上 只会执行一次 。(2) GTID是用来替代传统复制的方法 , GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置 。
(3) 减少手工干预和降低服务故障时间,当主机宕机之后会通过软件从众多的备机中提升一台备机为新的master 。
5、 GTID也存在一些限制:
(1) 不支持非事务引擎 。

推荐阅读