常见MySQl高可用架构概述
背景
在MySQL高可用架构中，目前使用比较多的是MHA ，Percona的PXC，以及MySQL 5.7之后的MGR，以及Orchestrator（orc）等，现对几个常用的高可用架构做简介，
一、MHA（Master HA）
MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。
MHA 是由日本人 yoshinorim（原就职于DeNA现就职于FaceBook）开发的比较成熟的 MySQL 高可用方案。MHA 能够在30秒内实现故障切换，并能在故障切换中，最大可能的保证数据一致性。目前淘宝也正在开发相似产品 TMHA， 目前已支持一主一从。
服务角色
MHA 服务有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)：
MHA Manager：
通常单独部署在一台独立机器上管理多个 master/slave 集群(组)，每个 master/slave 集群称作一个 application，用来管理统筹整个集群。
MHA node：
运行在每台 MySQL 服务器上(master/slave/manager)，它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。
主要是接收管理节点所发出指令的代理，代理需要运行在每一个 mysql 节点上。简单讲 node 就是用来收集从节点服务器上所生成的 bin-log 。对比打算提升为新的主节点之上的从节点的是否拥有并完成操作，如果没有发给新主节点在本地应用后提升为主节点。
MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，
由上图我们可以看出，每个复制组内部和 Manager 之间都需要ssh实现无密码互连，只有这样，在 Master 出故障时， Manager 才能顺利的连接进去，实现主从切换功能。
MHA工作原理总结为以下几条：
（1） 从宕机崩溃的 master 保存二进制日志事件（binlog events）；
（2） 识别含有最新更新的 slave ；
（3） 应用差异的中继日志(relay log) 到其他 slave ；
（4） 应用从 master 保存的二进制日志事件(binlog events)；
（5） 提升一个 slave 为新 master ；
（6） 使用其他的 slave 连接新的 master 进行复制。
优点：
由perl语言开发的开源工具
可以支持基于GTID的复制模式
MHA提供了主从切换和故障转移功能，在进行故障转移时不易产生数据丢失
当主DB不可用时，从多个从服务器中选举出新的主DB服务器
同一个监控节点可以监控多个集群
缺点：
需要编写脚本或者利用第三方工具(例如keepalived)来实现VIP的配置
MHA启动只会对主数据库进行监控
需要基于SSH免认证配置，存在安全隐患
没有提供从服务器的读负载均衡功能
只能监控主服务器是否可用，不能监控从服务器
二、Percona XtraDB Cluster简介
Percona XtraDB Cluster是MySQL高可用性和可扩展性的解决方案，Percona XtraDB Cluster提供的特性如下：
1).同步复制，事务要么在所有节点提交或不提交。
2).多主复制，可以在任意节点进行写操作。
3).在从服务器上并行应用事件，真正意义上的并行复制。
4).节点自动配置。
5).数据一致性，不再是异步复制。
Percona XtraDB Cluster完全兼容MySQL和Percona Server，表现在：
1).数据的兼容性
2).应用程序的兼容性：无需更改应用程序
1).集群是有节点组成的，推荐配置至少3个节点，但是也可以运行在2个节点上
2).每个节点都是普通的mysql/percona服务器，可以将现有的数据库服务器组成集群，反之，也可以将集群拆分成单独的服务器。
3).每个节点都包含完整的数据副本
PXC集群主要由两部分组成：Percona Server with XtraDB和Write Set Replication patches（使用了Galera library，一个通用的用于事务型应用的同步、多主复制插件）
原理分析：
1、当client端执行dml操作时，将操作发给server，server的native进程处理请求2、client端收到ok,执行commit，server将复制写数据集发给group(cluster)，cluster
中每个动作对应一个GTID
3、其它server接收到并通过验证(合并数据)后，执行appyl_cb动作和commit_cb动作，若验证没通过，则会退出处理
4、当前server节点验证通过后，执行commit_cb，并返回，若没通过，执行rollback_cb
5、只要当前节点执行了commit_cb和其它节点验证通过后就可返回
局限性
1.默认工作在InnoDB引擎表上，对其他的引擎的表支持的很差，甚至是根本不支持，所以不要考虑在PXC上使用MyISAM或其他存储引擎
2.所有的表都必须有主键，否则创建表会报错
3.不支持Lock/Unlock tables、lock functions等锁操作
4.query log日志只能存放在文件里保存
5.集群是基于乐观的并发控制(optimistic concurrency control),事务冲突的情况可能会在commit提交阶段发生
6.不支持分布式事务XA
7.整个集群的吞吐量和性能取决于最慢的那个节点
8.建议集群的最小节点数为3,否则容易出现脑裂问题
9.加入新节点开销大，需要同步所有数据
10.不能有效的解决写缩放问题，所有的写操作都发生在所有节点
优点如下：
1).当执行一个查询时，在本地节点上执行。因为所有数据都在本地，无需 远程访问
2).无需集中管理。可以在任何时间点失去任何节点，但是集群将照常工作， 不受影响
3).良好的读负载扩展，任意节点都可以查询
缺点如下：
1).加入新节点，开销大。需要复制完整的数据
2).不能有效的解决写缩放问题，所有的写操作都将发生在所有节点上
3).有多少个节点就有多少重复的数据
三、MySQL Group Replication（MGR）
MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引进的一个数据库高可用与高扩展的解决方案，以插件形式提供。MGR基于分布式paxos协议，实现组复制，保证数据一致性。内置故障检测和自动选主功能，只要不是集群中的大多数节点都宕机，就可以继续正常工作。提供单主模式与多主模式，多主模式支持多点写入。
Group Replication原理
MySQL Group Replication有两种模式，单主模式single-primary mode和多主模式multi-primary mode，在同一个group内，不允许两种模式同时存在，并且若要切换到不同模式，必须修改配置后重新启动集群。
1、单主模式
在单主模式下，只有一个节点可以读写，其他节点提供只读服务。单主模式下，该参数 _ 必须被设置为 FALSE ，当主节点宕掉，自动会根据服务器的server_uuid变量和group_replication_member_weight变量值，选择下一个slave谁作为主节点，group_replication_member_weight的值最高的成员被选为新的主节点，该参数默认为50，建议可以在节点上设置不同值；在group_replication_member_weight值相同的情况下，group根据数据字典中 server_uuid排序，排序在最前的被选择为主节点。
2、多主模式
在mysql多主模式下,在组复制中通过Group Replication Protocol协议及Paxos协议，形成的整体高可用解决方案 同时增加了certify的概念，负责检查事务是否允许提交，是否与其它事务存在冲突,Group Replication是由多个节点共同组成一个数据库集群，每个节点都可以单独执行事务，但是read-write（rw）的操作只有在组内验证后才可以commit，Read-only (RO)事务是不需要验证可以立即执行，当一个事务在一个节点上提交之前，会在组内自动进行原子性的广播，告知其他节点变更了什么内容/执行了什么事务，然后为该事物建立一个全局的排序，最终，这意味着所有的服务器都以相同的顺序接收相同的事务集。因此，所有服务器都按照相同的顺序应用相同的变更集，因此它们在组中保持一致。 在多主模式下，该组的所有成员都设置为读写模式，在多主模式下，不支持SERIALIZABLE事务隔离级别，且不能完全支持级联外键约束。
MGR使用限制
仅支持innodb存储引擎 ：MGR集群中，只支持innodb存储引擎，能够创建非innodb引擎的表，但是无法写入数据，向非innodb表写数据直接报错。
表必须有主键，或者非Null的唯一键 ：MGR集群中，只支持innodb引擎的表，并且该表必须有显式的主键，或者非Null的唯一键，否则即使能够创建表，也无法向表中写入数据。
网络限制：MGR 组通信引擎目前仅支持IPv4网络，并且对节点间的网络性能要求较高，低延迟、高带宽的网络是部署MGR集群的基础。
MGR忽略表锁和命名锁，在MGR中lock tables、unlock tables、get_lock、release_lock等这些表锁和命名锁将被忽略。
MGR多主模式中，默认不支持 SERIALIZABLE 隔离级别。
多主模式下，对同一个对象进行并发的有冲突的ddl和dml操作导致这种冲突在部分成员节点中无法检测到，最终可能导致数据不一致。
多主模式下，不支持级联约束的外键，可能造成有冲突的操作无法检测。
不支持超大事务。
多主模式下可能导致死锁，比如select …for update在不同节点执行，由于多节点锁无法共享，很容易导致死锁。
不支持复制过滤，如果有节点设置了复制过滤，将影响节点间决议的达成。
MGR最多支持9个节点，大于9个节点，将拒绝新节点的加入。
四、Orchestrator
Orchestrator是一款开源的MySQL复制拓扑管理工具，采用go语言编写，支持MySQL主从复制拓扑关系的调整、支持MySQL主库故障自动切换、手动主从切换等功能。
Orchestrator后台依赖于MySQL或者SQLite存储元数据，能够提供Web界面展示MySQL集群的拓扑关系及实例状态，通过Web界面可更改MySQL实例的部分配置信息，同时也提供命令行和api接口，以便更加灵活的自动化运维管理。
相比于MHA，Orchestrator更加偏重于复制拓扑关系的管理，能够实现MySQL任一复制拓扑关系的调整，并在此基础上，实现MySQL高可用，另外Orchestrator自身可以部署多个节点，通过raft分布式一致性协议，保证自身的高可用。
主要有以下几个特征
1.自动监测数据库复制的结构及其状态
2.提供了GUI，CLI，API等接口来检查复制拓扑的状态以及做一些调整的操作
3.支持自动的master failover，当复制结构的server挂掉以后（不管手动还是自动的），能够重新形成复制的拓扑结构
4.不依赖于特定的server版本或分支(MySQL, Percona Server, MariaDB or even MaxScale binlog servers)
5.支持多种类型的拓扑结构，不管是单个的主从还是成百上千个server组成的多级复制都不在话下
6.他的GUI不只是做向你report拓扑状态而已，你可以在Orchestrator web页面通过拖拽或者删除节点来改变复制拓扑（CLI和API也能做）
Orchestrator主要功能：
1、发现(discover)
orchestrator主动搜寻MySQL拓扑并进行映射。它能读取基本的MySQL信息，例如复制状态和配置。即使遇到故障，也可以为MySQL环境的拓扑提供流畅的可视化效果，包括复制问题。
2、重构(Refactoring)
orchestrator了解复制规则。它知道binlog文件：位置，GTID，伪GTID，Binlog服务器。
重构复制拓扑可以是将副本拖放到另一个主副本下的问题。移动副本是安全的：orchestrator将拒绝非法的重构尝试。通过各种命令行选项可以实现细粒度的控制。
3、恢复(recover)
orchestrator使用全面方法来检测主库故障和级联中间主库的故障。根据从拓扑本身获得的信息，它可以识别各种故障情况。
可通过配置，orchestrator可以选择执行自动恢复（或允许用户选择手动恢复的类型）。在内部实现中间主库的恢复。orchestrator通过Hooks进行自定义脚本支持故障切换。
功能限制
orchestrator提供给我们丰富的功能，同时，我们也应该意识到他说存在的限制于不足
关键一点是一个简单的方式来让我们将一个slave提升为master，这在master需要升级的时候会用到这一功能，还有就是计划好的failover
1.slave不能手动提升为master
2.不支持多源复制
3.不支持所有类型的并行复制
4.不支持与PXC联合使用
简单总结：
MGR
PXC
MHA
ORC
优点
原生高可用、数据一致性保证、支持多主
类似MGR
成熟稳定、对MySQL侵入小、 宕机后保证数据一致
支持可视化操作，自动 重构复制关系， 集群拓扑探测
缺点
太新有BUG（如新加入集群宕机,并行复制有不一致bug）、管理不方便（需配合mysql-shell）
性能损耗大（降低为1/3）、 大事务会卡住整个集群、需要用第三方发行版MySQL
选主方式过时、需要配合第三方脚本进行自动切换
环境部署步骤比MHA复杂，
没有binlog补全功能，依赖半同步保证数据一致性
业界里面用MHA最多，PXC、ORC其次，MGR由于比较新还挺少
其他的高可用方案还有共享存储、MMM（淘汰了），Heartbeat+DRBD+MySQL等
个人认为中间件（mysql router 或者 proxysql）+MGR的架构是发展的趋势
