MySQL cluster主要由三种类型的服务组成：- NDB Management Server：管理服务器主要用于管理cluster中的其他类型节点（Data Node和SQL Node），通过它可以配置Node信息，启动和停止Node。- SQL Node：在MySQL Cluster中，一个SQL Node就是一个使用NDB引擎的mysql server进程，用于核嫌供外部应用提供集群数据的...
实战体验几种MySQLCluster方案_MySQL
1. 背景
MySQL的cluster方案有多种官方和第三方的选择，选择多就是一种烦恼。因此，我们考虑MySQL数据库满足下三点需求，考察市面上可行的解决方案：高可用性、可伸缩性和负载均衡。需要选用一种方案满足以上需求。在MySQL官方网站上参考了几种解决方案的优缺点，综合考虑，决定采用MySQL Fabric和MySQL Cluster方案，以及另外一种较成熟的集群方案Galera Cluster进行预研。
2. MySQL Cluster简介：
MySQL Cluster是MySQL官方集群部署方案，它的历史较久。支持通过自动分片支持读写扩展，通过实时备份冗余数据，是可用性最高的方案，声称可做到99.999%的可用性。
- 架构及实现原理：
MySQL cluster主要由三种类型的服务组成：
- NDB Management Server：管理服务器主要用于管理cluster中的其他类型节点（Data Node和SQL Node），通过它可以配置Node信息，启动和停止Node。
- SQL Node：在MySQL Cluster中，一个SQL Node就是一个使用NDB引擎的mysql server进程，用于核嫌供外部应用提供集群数据的访问入口。
- Data Node：用于存储集群数据；系统会尽量将数据放在内存中。
- 缺点及限制：
- 对需要进行分片的表需要修改引擎Innodb为NDB，不需要分片的可以不修改。
- NDB的事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改；而Innodb支持所有的事务隔离级别，默认使用Repeatable Read，不存在这个问题。
- 外键支持：虽然最新的Cluster版本已经支持外键，但性能有问题（因为外键所关联的记录可能在别旦氏亏的分片节点中），所以建议去掉所有外键。
- Data Node节点数据会被尽量放在内存中，对内存要求大。
3. MySQL Fabric简介：
为了实现和方便管理MySQL 分片以及实现高可用部署，Oracle在2014年5月推出了一套为各方寄予厚望的MySQL产品 -- MySQL Fabric，用来管理MySQL 服务，提供扩展性和容易使用的系统，Fabric当前实现了两个特性：高可用和使用数据分片实现可扩展性和负载均衡，这两个特性能单独使用或结合使用。MySQL Fabric 使用了一系列的python脚本实现。
- 应用案例：
由于该方案在去年才推出，目前在网上暂时没搜索到有大公司的应用案例。
- 架构及实现原理：
Fabric支持实现高可用性的架构图如下：
Fabric使用HA组实现高可用性，其中一台是主服务器，其他是备份服务器，备份服务器通过同步复制实现数据冗余。应用程序使用特定的驱动，连接到Fabric 的Connector组件，当主服务器发生故障后，Connector自动升级其中一个备份服务器为主服务器，应用程序无需修改。
Fabric支持可扩展性及负载均衡的架构如下：
使用多个HA 组实现分片，每个组之间分担不同的分片数据（组内的数据是冗余的，这个在高可用性中已经提到）应用程序只需向connector发送query和insert等语句，Connector通过MasterGroup自动分配这些数据到各个组，或从各个组中组合符合条件的数据，返回给应用程序。
- 缺点及限制：
影响比较大的两个限制是：自增长键不能作为分片的键；事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。
4. Galera Cluster简介：
Galera Cluster号称是世界上最先进的开源数据库集群方案。
- 主要优点及特性：
- 真正的多主服务模式：多个服务能同时被读写，不像Fabric那样某些服务只能作备份用。
- 同步复制：无延迟复制，不会产生数据丢失。
- 热备用：当某台服务器当机后，备用服务器会自动接管，不会产生任何当机时间。
- 自动扩展节点：新增服务器时，不需手工复制数据库到新的节点。
- 支持InnoDB引擎对应用程序透明：应用程序不需作修改。
- 架构及实现原理：
首先，我们看看传统的基于mysql Replication（复制）的架构图：
Replication方式是通过启动复制线程从主服务器上拷贝更新日志，然后传送到备份服务器上执行，这种方式存在事务丢失及同步不及时的风险。Fabric以及传统的主从复制都是使用这种实现方式。而Galera则采用以下架构保证事务在所有机器的一致性：
客户端通过Galera Load Balancer访问数据库，提交的每个事务都会通过wsrep API 在所有服务器中执行，要不所有服务器都执行成功，要不就所有都回滚，保证所有服务的数据一致性，而且所有服务器同步实时更新。
- 缺点及限制：
由于同一个事务需要在集群的多台机器上执行，因此网络传输及并发执行会导致性能上有一定的消耗。所有机器上都存储着相同的数据，全冗余。若一台机器既作为主服务器，又作为备份服务器，出现乐观锁导致rollback的概率会增大，编写程序时要小心。不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…不支持XA Transaction。
5. 对比总结
MySQL Fabric：
- 使用案例：2014年5月才推出，目前在网上暂时没搜索到有大公司的应用案例。
- 数据备份的实时性：由于使用异步复制，一般延时几十秒，但数据不会丢失。
- 数据冗余：使用分片，通过设置分片key规则可以将同一张表的不同数据分散在多台机器中。
- 高可用性：通过Fabric Connector实现主服务器当机后的自动切换，但由于备份延迟，切换后可能不能立即查询数据。
- 可伸缩性：添加节点后，需要先手工复制集群数据。
- 负载均衡：通过HASharding实现。
- 程序修改：需要切换成jdbc:mysql:fabric的jdbc类和url。
- 性能对比：使用java直接用jdbc插入100条记录，大概2000+ms。
MySQL Cluster：
- 使用案例：没有提到具体案例。
- 数据备份的实时性：实时备份，数据立即生效。
- 数据冗余：每个节点全冗余，没有分片。
- 高可用性：使用HAProxy实现。由于实时同步，切换的可用性更高。
- 可伸缩性：添加节点后，需要先手动复制集群数据。
- 负载均衡：使用HAProxy实现负载均衡。
- 程序修改：没有提到需要修改的情况。
- 性能对比：跟直接操作mysql一样，直接用jdbc插入100条记录，大概600ms。
Galera Cluster：
- 使用案例：超过2000多家外国企业使用，包括某些知名企业。
- 数据备份的实时性：实时同步，数据不会丢失。
- 数据冗余：每个节点全冗余，没有分片。
- 高可用性：使用HAProxy实现。由于实时同步，切换的可用性更高。
- 可伸缩性：扩展节点十分方便，启动节点时自动同步集群数据，100w数据（100M）只需20秒左右。
- 负载均衡：使用HAProxy实现负载均衡。
- 程序修改：程序无需修改。
- 性能对比：跟直接操作mysql一样，直接用jdbc插入100条记录，大概600ms。
6. 实践应用
综合考虑上面方案的优缺点，我们比较偏向选择Galera。如果只有两台数据库服务器，考虑采用以下数据库架构实现高可用性、负载均衡和动态扩展：如果三台机器可以考虑：2024-10-24
