1. MySQL高可用的背景
数据库的主从复制是一个很实用的功能 , 但如何保证它的高可用却是一件难事。实现MySQL主从复制高可用的工具 , 常见的有 :
MMM: 淘汰了 , 在一致性和高并发稳定性等方面有些问题。MHA: 有些人还在用 , 但也有些问题 , 也是趋于淘汰的MySQL主从高可用方案。Galera: 引领时代的主从复制高可用技术。MariaDB Galera Cluster:MariaDB对Galera的实现。PXC:Percona XtraDB Cluster, 是Percona对Galera的自我实现 , 用的人似乎很多。
GR:Group Replication,MySQL官方提供的组复制技术(MySQL 5.7.17引入的技术) , 基于Paxos算法。
MariaDB Galera Cluster、PXC、GR是类似的 , 都各有优点。但GR是革命性的 , 基于原生复制技术 , 据传很多方面都优于PXC。
但是 , 上面每个高可用实现方法 , 都有这样那样的缺点 , 甚至mmm还是通过perl脚本来自动化模拟高可用环境的。到了Galera , 这是一个引领潮流的高可用技术 , 它主要针对具有事务特性的Innodb存储引擎 , Percona和MariaDB都分别实现了自己的Galera技术 : MariaDB Galera Cluster和Percona XtraDB Cluster。MySQL没有推出自己的Galera , 但却在2016年的MySQL 5.7.17版本中推出了Group Replication , 即组复制技术。
网上对组复制和Galera的对比很多 , 特别是2016年组复制出生后大火的"Galera将死"的言论 , 但实际上 , 仍然有很多人在用着pxc , 毕竟它已经扬帆航行多年 , 而GR才出没多久 , 前几个版本也一直在修修补补。那么 , GR or Galera, that's a question。
2. MGR
MGR(MySQL Group Replication)是MySQL官方在MySQL 5.7.17版本中以插件形式推出的主从复制高可用技术 , 它基于原生的主从复制 , 将各节点归入到一个组中 , 通过组内节点的通信协商(组通信协议基于Paxos算法) , 实现数据的强一致性、故障探测、冲突检测、节点加组、节点离组等等功能。
例如,具有3个节点的组:
这3个节点互相通信 , 每当有事件发生 , 都会向其他节点传播该事件 , 然后协商 , 如果大多数节点都同意这次的事件 , 那么该事件将通过 , 否则该事件将失败或回滚。
这些节点可以是单主模型的(single-primary) , 也可以是多主模型的(multi-primary)。单主模型只有一个主节点可以接受写操作 , 主节点故障时可以自动选举主节点。多主模型下 , 所有节点都可以接受写操作 , 所以没有master-slave的概念。
就这样 , 完了。
3. MHA
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案 , 它由日本DeNA公司youshimaton ( 现就职于Facebook公司 ) 开发 , 是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具 , 该工具仅适用于MySQLReplication ( 二层 ) 环境 , 目的在于维持Master主库的高可用性。是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中 , MHA能做到在0~30秒之内自动完成数据库的故障切换操作 , 并且在进行故障切换的过程中 , MHA能在最大程度上 保证数据的一致性 , 以达到真正意义上的高可用。
MHA是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步).该软件由两部分组成 : MHA Manager ( 管理节点 ) 和MHA Node ( 数据节点 ) 。
MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群 , 也可以部署在一台slave节点上。MHA Manager会定时探测集群中的node节点,当发现master出现故障的时候,它可以自动将具有最新数据的slave提升为新的master,然后将所有其它的slave导向新的master上.整个故障转移过程对应用程序是透明的。MHA Node运行在每台MySQL服务器上 , 它通过监控具备解析和清理logs功能的脚本来加快故障转移的。
在MHA自动故障切换过程中 , MHA试图从宕机的主服务器上保存二进制日志 , 最大程度的保证数据的不丢失 , 但这并不总是可行的。例如 , 如果主服务器硬件故障或无法通过ssh访问 , MHA没法保存二进制日志 , 只进行故障转移而丢失了最新的数据。使用MySQL 5.5或者以后的版本的半同步复制 , 可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志 , MHA可以将最新的二进制日志应用于其他所有的slave服务器上 , 因此可以保证所有节点的数据一致性。
目前MHA主要支持一主多从的架构 , 要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器 , 一主二从 , 即一台充当master , 一台充当备用master , 另外一台充当从库 , 因为至少需要三台服务器 , 出于机器成本的考虑 , 淘宝也在该基础上进行了改造 , 目前淘宝TMHA已经支持一主一从。
4. galera
Galera Cluster是由Codership开发的MySQL多主集群 , 包含在MariaDB中 , 同时支持Percona xtradb、MySQL , 是一个易于使用的高可用解决方案 , 在数据完整性、可扩展性及高性能方面都有可接受的表现。三个MySQL实例是对等的 , 互为主从 , 这被称为多主(multi-master)架构。当客户端读写数据时 , 可连接任一MySQL实例。对于读操作 , 从每个节点读取到的数据都是相同的。对于写操作 , 当数据写入某一节点后 , 集群会将其同步到其它节点。这种架构不共享任何数据 , 是一种高冗余架构。
Galera集群具有以下特点:
多主架构 : 真正的多主多活群集 , 可随时对任何节点进行读写。
同步复制 : 集群不同节点之间数据同步 , 某节点崩溃时没有数据丢失。
数据一致 : 所有节点保持相同状态 , 节点之间无数据分歧。
并行复制 : 重放支持多线程并行执行以获得更好的性能。
故障转移 : 故障节点本身对集群的影响非常小 , 某节点出现问题时无需切换操作 , 因此不需要使用
VIP, 也不会中断服务。自动克隆 : 新增节点会自动拉取在线节点的数据 , 最终集群所有节点数据一致 , 而不需要手动备份恢复。
应用透明 : 提供透明的客户端访问 , 不需要对应用程序进行更改。
Galera集群复制要求数据库系统支持事务 , 因此仅支持MySQL的Innodb存储引擎 , 并且多主模式下只能使用可重复读隔离级别。
不同于MySQL原生的主从异步复制 , Galera采用的是多主同步复制
基于验证的复制使用组通信和事务排序技术实现同步复制。它通过广播并发事务之间建立的全局总序来协调事务提交。简单说就是事务必须以相同的顺序应用于所有实例。事务在本节点乐观执行 , 然后在提交时运行一个验证过程以保证全局数据一致性。所谓乐观执行是指 , 事务在一个节点提交时 , 被认为与其它节点上的事务没有冲突 , 首先在本地执行 , 然后再发送到所有节点做冲突检测 , 无冲突时在所有节点提交 , 否则在所有节点回滚。
当客户端发出commit命令时 , 在实际提交之前 , 对数据库所做的更改都将被收集到一个写集中 , 写集中包含事务信息和所更改行的主键。然后 , 数据库将此写集发送到所有其它节点。节点用写集中的主键与当前节点中未完成事务的所有写集( 不仅包括当前节点其它事务产生的写集 , 还包括其它节点传送过来的写集) 的主键相比较 , 确定节点是否可以提交事务。同时满足以下三个条件则验证失败( 存在冲突) ：
两个事务来源于不同节点。
两个事务包含相同的主键。
老事务对新事务不可见 , 即老事务未提交完成。新老事务的划定依赖于全局事务总序 , 即
GTID。
验证失败后 , 节点将删除写集 , 集群将回滚原始事务。对于所有的节点都是如此 , 每个节点单独进行验证。因为所有节点都以相同的顺序接收事务 , 它们对事务的结果都会做出相同的决定 , 要么全成功 , 要么都失败。成功后自然就提交了 , 所有的节点又会重新达到数据一致的状态。节点之间不交换“是否冲突”的信息 , 各个节点独立异步处理事务。由此可见 , Galera本身的数据也不是严格同步的 , 很明显在每个节点上的验证是异步的 , 这也就是前面提到的“虚拟同步”。
最后 , 启动事务的节点可以通知客户端应用程序是否提交了事务。
参考链接
MySQL高可用之组复制(1) : 组复制技术简介 - 骏马金龙 - 博客园