Mysql集群方案大致有三种类型：

• mysql官方提供的集群方案
  • MySQL Replication【一主多从，异步复制】
  • MySQL Fabric【一主多从，异步复制】
  • MySQL NDB Cluster【多主多从，原生复制及组复制】
  • MGR（MySQL Group Replication）【多主多从，原生复制及组复制】
• 基于硬件的mysql集群方案
  • 心跳检测+SAN共享存储（heartbeat + SAN）
  • 心跳检测+DRDB磁盘复制（heartbeat + DRBD）
• 基于第三方的mysql集群方案
  • MMM（Master Replication Manager for MySQL）【双主多从，主主复制】
  • MHA（Master High Availability）【多个一主多从，异步/半同步复制】
  • Lvs （Linux Virtual Servevr） + Keepalived + MySQL 【双主多从，主主复制】
  • HaProxy + Keepalived + MySQL【双主多从，主主复制】
  • Galera Cluster（MariaDB Galera Cluster / Mysql Galera Cluster/Percona XtraDB Cluster 简称PXC）【多主多从】
  • RadonDB

1.MySQL Replication

主要目的是实现数据的多点备份，没有故障自动转移和负载均衡。

特点如下：

• 一主多从，异步复制。
• 主从复制是通过重放binlog实现主库数据的异步复制。即当主库执行了一条sql命令，那么从库要从binlog获取数据并重放，从而达到主从复制的效果。
• 对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。
• 热备时：可以在某个从数据库中暂时中断复制进程，来备份数据，从而不影响主数据的对外服务（如果在master上执行backup，需要让master处于readonly状态，这也意味这所有的write请求需要阻塞）。
• 数据被删除，可以从binlog日志中恢复。
• 单点故障问题：单一的主节点挂了，将不能对外提供写服务。
  • 单节点故障 / 单故障节点

2.MySQL Fabric

在MySQL Replication的基础上，增加了故障检测与转移，自动【数据分片】功能。不过依旧是一主多从的结构

MySQL Fabric只有一个主节点，区别是当该主节点挂了以后，会从从节点中选择一个来当主节点。

特点如下：

• 一主多从，异步复制。
• 主从复制是通过重放binlog实现主库数据的异步复制。即当主库执行了一条sql命令，那么从库要从binlog获取数据并重放，从而达到主从复制的效果。
• 对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。
• 事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。
  • 分区：分区则是把一张表的数据分成 N 多个区块，这些区块可以在同一个磁盘上，也可以在不同的磁盘上。
  • 分片：分片可以简单定义为将大数据库分布到多个物理节点上的一个分区方案。每一个分区包含数据库的某一部分，称为一个片。
• 数据被删除，可以从binlog日志中恢复。
• 单点故障问题：主节点挂了以后，能够自动从从节点中选择一个来当主节点，不影响持续对外提供写服务。节点故障恢复30秒或更长（采用InnoDB存储引擎的都这样）。

3.MySQL NDB Cluster

通过使用 NDB 存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。

优点如下：

• 多主多从。
• 负载均衡优秀，可同时用于读操作、写操作都都密集的应用，也可以使用SQL和NOSQL接口访问数据。
• 多个主节点，没有单点故障的问题，节点故障恢复通常小于1秒。
• 高可用性和可伸缩性。
  • 可以自动切分数据，方便数据库的水平拓展。
  • 能跨节点冗余数据：其数据集并不是存储某个特定的MySQL实例上，而是被分布在多个Data Nodes中，即一个table的数据可能被分散在多个物理节点上，任何数据都会在多个Data
    Nodes上冗余备份。任何一个数据变更操作，都将在一组Data Nodes上同步，以保证数据的一致性。

缺点如下：

• 只能使用存储引擎 NDB ，与平常使用的InnoDB 有很多明显的差距，可能会导致日常开发出现意外。
  • 事务：其事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改。
  • 外键：虽然最新的NDB 存储引擎已经支持外键，但性能有问题，因为外键所关联的记录可能在别的分片节点。
  • 表限制。
• 对节点之间的内部互联网络带宽要求高。
• 对内存要求大：Data Node数据会被尽量放在内存中，对内存要求大，而且重启的时候，数据节点将数据load到内存需要很长时间。

总结：

• 由于 MySQL Cluster 架构复杂，部署费时，通常需要 DBA 几个小时的时间才能完成搭建，而依靠 MySQL Cluster Manager 只需一个命令即可完成，但 MySQL Cluster Manager 是 收费的。
• 并且业内资深人士认为 NDB 不适合大多数业务场景，而且有安全问题。因此，使用的人数较少。

4.MGR（MySQL Group Replication）

基于Mysql原生复制及 paxos 协议的组复制技术，并以插件的方式提供，提供一致数据安全保证。
MGR提供了single-primary（单个主节点）和 multi-primary（多个主节点）两种模式。

• single-primary模式下，组内只有一个节点负责写入，读可以从任意一个节点读取，组内数据保持最终一致。
  

• multi-primary模式即为多写方案，即写操作会下发到组内所有节点，组内所有节点同时可读可写，该模式也是能够保证组内数据最终一致性。
• 多主模式，即多写，没有选择新 primary 的概念（无需进行选举），group 内的所有机器 都是 primary 节点，同时可以进行读写操作，并且数据是最终一致的。
  

5.心跳检测+SAN共享存储（heartbeat + SAN）

SAN（Storage Area Network）：共享存储，主库从库用的一个存储。
SAN的概念是允许存储设施和解决器（服务器）之间建立直接的高速连接，通过这种连接实现数据的集中式存储。

特点：

• 可以保证数据的强一致性；
• 与mysql解耦，不会由于mysql的逻辑错误发生数据不一致的情况；
• 需要考虑共享存储的高可用；
• SAN价格昂贵；

6.心跳检测+DRBD磁盘复制（heartbeat + DRBD）

DRBD（Distributed Replicated Block Device）：是一个用软件实现的、无共享的、服务器之间镜像块设备内容的存储复制解决方案。
DRDB磁盘复制：这是linux内核板块实现的块级别的同步复制技术。 通过各主机之间的网络，复制对方磁盘的内容

• 该集群方式采用 Heartbeat 双机热备软件来保证数据库的高稳定性和连续性，数据的一致性 由 DRBD 这个工具来保证。
• 默认情况下只有一台 mysql 在工作，当主 mysql 服务器出现问题 后，系统将自动切换到备机上继续提供服务，当主数据库修复完毕，又将服务切回继续由主 mysql 提供服务。
  
  特点：
• 相比于SAN储存网络，价格低廉；
• 保证数据的强一致性；
• 与mysql解耦，不会由于mysql的逻辑错误发生数据不一致的情况；
• 对io性能影响较大；
• 从库不提供读操作；

7.MMM（Master Replication Manager for MySQL）

MMM是在MySQL Replication的基础上，对其进行优化。
MMM是一套支持双主故障切换和双主日常管理的脚本程序，主要用来监控mysql主主复制并做失败转移。
这里的双主节点，虽然叫做双主复制，但是业务上同一时刻【只允许对一个】主进行写入，另一台备选主上提供部分读服务，其他的 slave 提供读服务，以加速在主主切换时刻备选主的预热。


特点：

• 双主多从结构，主主复制，双主复制。
• 多个从节点读的负载均衡。
• 自动的主主故障转移切换，一般3s以内切换备机。
• 无法完全保证数据的一致性。如主1挂了，MMM monitor已经切换到主2上来了，而若此时双主复制中，主2数据落后于主1（即还未完全复制完毕），那么此时的主2已经成为主节点，对外提供写服务，从而导致数据不一。
• 由于是使用虚拟IP浮动技术，类似Keepalived，故RIP（真实IP）要和VIP（虚拟IP）在同一网段。如果是在不同网段也可以，需要用到虚拟路由技术。但是绝对要在同一个IDC机房，不可跨IDC机房组建集群。

MMM 是 Google 技术团队开发的一款比较老的高可用产品，在业内使用的并不多，社区也不活跃， Google 很早就不再维护 MMM 的代码分支。

8.MHA（Master High Availability）

• MHA是在MySQL Replication的基础上，对其进行优化。
• MHA（Master High Availability）在 MySQL 高可用方面是一个相对成熟的解决方案，是一 套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。
• 在 MySQL 故障切 换过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
• 提供更多的主节点，但是缺少VIP（虚拟IP），需要配合keepalived等一起使用。
• 要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。
  
  
  特点如下：
• 多主多从
• 可以进行故障的自动检测和转移。
• 具备自动数据补偿能力，在主库异常崩溃时能够最大程度的保证数据的一致性。
• 需要在各个节点间打通ssh信任。
• 高可用依赖于vip的方案，譬如采用keepalive来达到vip的切换，但是keepalive会限制切换的主机必须在一个网段，对于跨机房不在一个网段的服务器来说，就无法支持了。
• 在大规模为每个MySQL集群安排一个vip也是难以实现的。keepalive在一个网段内，部署多套也会互相影响。
• MHA架构实现读写分离，最佳实践是在应用开发设计时提前规划读写分离事宜，在使用时设置两个连接池，即读连接池与写连接池，也可以选择折中方案即引入SQL Proxy。但无论如何都需要改动代码；
• 关于读负载均衡可以使用F5、LVS、HAPROXY或者SQL Proxy等工具，只要能实现负载均衡、故障检查及备升级为主后的读写剥离功能即可。

9.Lvs+Keepalived+ MySQL

MySQL 主主复制是集群的基础，每个节点都是 Master，均可对外提供服务。
Lvs服务器提供了负载均衡的作用，将用户请求分发到Real Server，一台 Real Server故障并不会影响整个集群的。Keepalived搭建主备Lvs服务器，避免了Lvs服务器的单点故障，出现故障时可以自动切换到正常的节点。


LVS在企业应用中抗负载能力很强，但存在不足，LVS不支持正则处理，不能实现动静分离；对于大型网站，LVS的实施配置复杂，维护成本相对较高；

10.HaProxy+Keepalived+ MySQL

Haproxy是一款可提供高可用性、负载均衡、及基于TCP和HTTP应用的代理的软件，适用于负载大的Web站点；运行在硬件上可支持数以万计的并发连接的连接请求；

haproxy+keepalived优点：

• 可靠性和稳定性非常好，可以和硬件级的负载均衡设备F5相媲美。
• 最高可同时维护40000-50000个并发连接，单位时间内处理的最大请求数为20000个。
• 支持8种负载均衡算法，支持回话保持；支持虚拟主机功能；支持连接拒绝，全透明代理并且有一个功能强大的服务器状态监控界面。
• 拥有功能强大的ACL支持。
• 用haproxy构建群集的时候，比如后方代理两个http，如果haproxy宕机，后方的http正常运行网站也是瘫痪状态，这就造成了单点故障。
• 这时keepalived就登场了，keepalived基于vrrp协议，两台主机之间生成一个虚拟的ip，我们称漂移ip，漂移ip由主服务器承担，一但主服务器宕机，备份服务器就会抢占漂移ip，继续工作，有效的解决了群集中的单点故障。两者相结合，可靠稳定。

11.Galera Cluster

• Galera Cluster是集成了Galera插件的 MySQL 集群，是一种新型的，数据不共享的，高度冗余的高可用方案。Galera 本身具有多主特性，所以 Galera Cluster 也就是 Multi-Master 的 集群结构。
• 基于Galera的高可用方案主要有MariaDB Galera Cluster， Mysql Galera Cluster 和 Percona XtraDB Cluster（简称PXC），目前PXC用的会比较多一些。
  

• 图中有三个实例，组成了一个集群，而这三个节点与普通主从架构不同，都可作为主节点，三个节点对等，这种一般称为 Multi-Master 架构，当有客户端要写入或读取数据时，随便连接哪个实例都一样，读到的数据相同，写入某一节点后，集群自己会将新数据同步到其他节点上，这种架构不共享任何数据，是一种高冗余架构。
  
  PXC优点：

• 服务高可用。
• 数据同步复制（并发复制），几乎无延迟。
• 多个可同时读写节点，可实现写扩展，不过最好事先进行分库分表，让各个节点分别写不同的表或者库，避免让galera解决数据冲突。
• 新节点可以自动部署，部署操作简单。
• 数据严格一致性，尤其适合电商类应用。
• 完全兼容MySQL。

PXC缺点：

• 只支持InnoDB引擎。
• 所有表都要有主键。
• 不支持LOCK TABLE等显式锁操作。
• 加入新节点，开销大。需要复制完整的数据。
• 所有的写操作都将发生在所有节点上。
• 有多少个节点就有多少重复的数据。
• 不支持XA分布式事务协议。

12.如何选择对的集群方案？

在选择适合的MySQL集群方案时，需要考虑多个因素，包括可用性要求、性能需求、数据一致性要求、部署复杂度、维护成本等。每个方案都有其适用的场景和特点，下面对每种方案进行简要描述：

• MySQL Replication：这是最常见的 MySQL 高可用性和负载均衡解决方案。它允许一个主数据库服务器处理写操作，而一个或多个从数据库服务器可以处理读操作。这种方案适用于读操作比写操作多的应用。
• MySQL Fabric：这是一个官方的、集成的框架，用于管理冗余和分片。它可以动态管理主从复制，并为应用程序提供了一个智能代理来路由查询。适用于需要动态扩展和高可用性的企业级应用。
• MySQL NDB Cluster：这是一个高性能，分布式，高可用性的 MySQL 存储引擎。它特别适用于需要实时响应和 99.999% 可用性的任务关键应用。
• MGR （MySQL Group Replication）：这是一个插件，提供了一种无主（multi-master）复制方案，可以实现高可用性和可扩展性。适用于需要高可用性和写入负载均衡的应用。
• Heartbeat + SAN：这是一个基于共享存储的高可用性解决方案。适用于需要极高数据一致性的环境，但可能需要更复杂的设备和管理。
• Heartbeat + DRBD：这是一个基于网络的冗余存储解决方案。适用于需要极高数据一致性的环境，并且可以在更广泛的网络环境中工作。
• MMM （Multi-Master Replication Manager for MySQL）：这是一个用于管理多主复制和故障转移的工具。适用于需要多主复制和高可用性的环境，但可能需要更多的管理和监控。
• MHA （Master High Availability Manager and tools for MySQL）：这是一个用于自动故障转移和主服务器切换的工具。适用于需要高可用性和自动故障恢复的环境。
• Lvs+Keepalived + MySQL：这是一个结合了负载均衡和高可用性的解决方案。适用于需要高可用性和负载均衡的环境。
• HaProxy+Keepalived + MySQL：这是一个结合了代理、负载均衡和高可用性的解决方案。适用于需要高可用性、负载均衡和灵活的查询路由的环境。
• Galera Cluster：这是一个同步多主复制的解决方案，它提供了真正的多主复制，自动节点成员管理，故障恢复和高性能。适用于需要高可用性、多主复制和高性能的环境。

在选择适合的方案时，需要综合考虑业务需求和环境特点，例如对于高可用性的要求、数据一致性的需求、部署复杂度、性能需求以及团队的熟悉程度等。建议进行实际的测试和评估，根据具体场景选择最适合的方案。同时，也可以考虑咨询专业的数据库管理员或咨询公司以获取更详细的建议和帮助。