mysql（8）- mysql数据库之集群

知识点：

1. 概念
   作用：目的是提供容错性和高性能
2. 架构图
3. 如何储存数据
4. 集群实现的方式
5. MySQL集群的横向扩展
6. 总结：MySQL集群的优缺点

一.概念

         MySQL集群是一个无共享的(shared-nothing)、分布式节点架构的存储方案，其目的是提供容错性和高性能。
         数据更新使用读已提交隔离级别（read-committedisolation)来保证所有节点数据的一致性，使用两阶段提交机制（two-phasedcommit)保证所有节点都有相同的数据(如果任何一个写操作失败，则更新失败）。
        无共享的对等节点使得某台服务器上的更新操作在其他服务器上立即可见。传播更新使用一种复杂的通信机制，这一机制专用来提供跨网络的高吞吐量。
         通过多个MySQL服务器分配负载，从而最大程序地达到高性能，通过在不同位置存储数据保证高可用性和冗余。

二.架构图

 

三.如何储存数据

1. Mysqlcluster数据节点组内主从同步采用的是同步复制，来保证组内节点数据的一致性。一般通过两阶段提交 协议来实现，一般工作过程如下：

    

   由于同步复制一共需要4次消息传递，故mysql  cluster的数据更新速度比单机mysql要慢。所以mysql cluster要求运行在千兆以上的局域网内，节点可以采用双网卡，节点组之间采用直连方式。

   疑问： 对cluster进行扩容增加数据节点组时会不会导致数据更新速度降低？
   答：不会，数据更新速度会变快。因为数据是分别处理，每个节点组所保存的数据是不一样的，也能减少锁定。

   1. Master执行提交语句时，事务被发送到slave，slave开始准备事务的提交。
   2. 每个slave都要准备事务，然后向master发送OK(或ABORT)消息，表明事务已经准备好（或者无法准备该事务）。
   3. Master等待所有Slave发送OK或ABORT消息
      1. 如果Master收到所有 Slave的OK消息，它就会向所有Slave发送提交消息，告诉Slave提交该事务；
      2. 如果Master收到来自任何一个Slave的ABORT消息，它就向所有 Slave发送ABORT消息，告诉Slave去中止事务。
   4. 每个Slave等待来自Master的OK或ABORT消息。
      1. 如果Slave收到提交请求，它们就会提交事务，并向Master发送事务已提交 的确认；
      2. 如果Slave收到取消请求,它们就会撤销所有改变并释放所占有的资源，从而中止事务，然后向Masterv送事务已中止的确认。
   5. 当Master收到来自所有Slave的确认后，就会报告该事务被提交（或中止），然后继续进行下一个事务处理。
2. Mysqlcluster将所有的索引列都保存在主存中，其他非索引列可以存储在内存中或者通过建立表空间存储到磁盘上。如果数据发生改变(insert,update,delete等)，mysql 集群将发生改变的记录写入重做日志，然后通过检查点定期将数据定入磁盘。由于重做日志是异步提交的，所以故障期间可能有少量事务丢失。为了减少事务丢失，mysql集群实现延迟写入(默认延迟两秒，可配置)，这样就可以在故障发生时完成检查点写入，而不会丢失最后一个检查点。一般单个数据节点故障不会导致任何数据丢失，因为集群内部采用同步数据复制。

四.集群实现的方式

方案：

1. LVS+Keepalived+MySQL（有脑裂问题？但似乎很多人推荐这个）
2. DRBD+Heartbeat+MySQL（有一台机器空余？Heartbeat切换时间较长？有脑裂问题？）
3. MySQL Proxy（不够成熟与稳定？使用了Lua？是不是用了他做分表则可以不用更改客户端逻辑？）
4. MySQL Cluster （社区版不支持INNODB引擎？商用案例不足？）
5. MySQL + MHA （如果配上异步复制，似乎是不错的选择，又和问题？）
6. MySQL + MMM （似乎反映有很多问题，未实践过，谁能给个说法）

回答：

不管哪种方案都是有其场景限制 或说 规模限制，以及优缺点的。

1. 首先反对大家做读写分离，关于这方面的原因解释太多次数（增加技术复杂度、可能导致读到落后的数据等），只说一点：99.8%的业务场景没有必要做读写分离，只要做好数据库设计优化 和配置合适正确的主机即可。
2. Keepalived+MySQL --确实有脑裂的问题，还无法做到准确判断mysqld是否HANG的情况；
3. DRBD+Heartbeat+MySQL --同样有脑裂的问题，还无法做到准确判断mysqld是否HANG的情况，且DRDB是不需要的，增加反而会出问题；
4. MySQL Proxy -- 不错的项目，可惜官方半途夭折了，不建议用，无法高可用，是一个写分离；
5. MySQL Cluster -- 社区版本不支持NDB是错误的言论，商用案例确实不多，主要是跟其业务场景要求有关系、这几年发展有点乱不过现在已经上正规了、对网络要求高；
6. MySQL + MHA -- 可以解决脑裂的问题，需要的IP多，小集群是可以的，但是管理大的就麻烦，其次MySQL + MMM 的话且坑很多，有MHA就没必要采用MMM

建议：

1. 若是双主复制的模式，不用做数据拆分，那么就可以选择MHA或 Keepalive 或 heartbeat
2. 若是双主复制，还做了数据的拆分，则可以考虑采用Cobar；
3. 若是双主复制+Slave，还做了数据的拆分，需要读写分类，可以考虑Amoeba；

总结：上述所有的内容都要依据公司内部的业务场景、数据量、访问量、并发量、高可用的要求、DBA人群的数量等 综合权衡

实例：

第一种 主从同步架构

此种架构，一般初创企业比较常用，也便于后面步步的扩展
此架构特点：

1. 成本低，布署快速、方便
2. 读写分离
3. 还能通过及时增加从库来减少读库压力
4. 主库单点故障
5. 数据一致性问题（同步延迟造成）

第二种 Mysql+DRBD架构

通过DRBD基于block块的复制模式，快速进行双主故障切换，很大程度上解决主库单点故障问题
此架构特点：

1. 高可用软件可使用Heartbeat,全面负责VIP、数据与DRBD服务的管理
2. 主故障后可自动快速切换，并且从库仍然能通过VIP与新主库进行数据同步
3. 从库也支持读写分离，可使用中间件或程序实现

第三种 Mysql+MHA架构
MHA目前在Mysql高可用方案中应该也是比较成熟和常见的方案，它由日本人开发出来，在mysql故障切换过程中，MHA能做到快速自动切换操作，而且还能最大限度保持数据的一致性

此架构特点：

1. 安装布署简单，不影响现有架构
2. 自动监控和故障转移
3. 保障数据一致性
4. 故障切换方式可使用手动或自动多向选择
5. 适应范围大（适用任何存储引擎）

第四种 Mysql+MMM架构

MMM即Master-Master Replication Manager for MySQL（mysql主主复制管理器），是关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入），这个套件也能基于标准的主从配置的任意数量的从服务器进行读负载均衡，所以你可以用它来在一组居于复制的服务器启动虚拟ip，除此之外，它还有实现数据备份、节点之间重新同步功能的脚本。

MySQL本身没有提供replication failover的解决方案，通过MMM方案能实现服务器的故障转移，从而实现mysql的高可用。
此方案特点：

1. 安全、稳定性较高，可扩展性好
2. 对服务器数量要求至少三台及以上
3. 对双主（主从复制性要求较高）
4. 同样可实现读写分离

第五种 官方mysql cluster方案

Mysql官方推出的集群高可用方案，由于本人没有用过，不好评价
摘自网络上的一段解释
MySQL Cluster 由一组计算机构成，每台计算机上均运行着多种进程，包括 MySQL 服务器，NDB Cluster的数据节点，管理服务器，以及（可能）专门的数据访问程序。 
由于MySQL Cluster架构复杂，部署费时（通常需要DBA几个小时的时间才能完成搭建），而依靠 MySQL Cluster Manager 只需一个命令即可完成，但 MySQL Cluster Manager 是收费的。并且业内资深人士认为NDB 不适合大多数业务场景，而且有安全问题。因此，使用的人数较少。

五.MySQL集群的横向扩展

1.添加数据节点组来扩展写操作，提高 cluster的存储能力。支持在线扩容，先将新的节点加入到clsuter里，启动后用
ALTER ONLINE TABLE table_name REORGANIZE PARTITION

命令进行数据迁移，把数据平均分配到数据节点上。

2.添加Slave仅仅扩展读，而不能做到写操作的横向扩展。

整个系统的平均负载可以描述为：

AverageLoad=∑readload+ ∑writeload / ∑capacity

假设每个服务器每秒有10000的事务量，而Master每秒的写负载为4000个事务，每秒的读负载为6000，结果就是:

AverageLoad=6000+4000/10000=100%

现在，添加3个slave,每秒的事务量增加到40000。因为写操作也会被复制，每个写操作执行4次，这样每个slave的写负载就是每秒4000个事务。那么现在的平均负载为：

AverageLoad=6000+4*4000/ 4*10000=55%

六.总结

1. 优点：
   1. 99.999%的高可用性
   2. 快速的自动失效切换
   3. 灵活的分布式体系结构，没有单点故障
   4. 高吞吐量和低延迟
   5. 可扩展性强，支持在线扩容
2. 缺点：
   1. 存在很多限制，比如：不支持外键
   2. 部署、管理、配置很复杂
   3. 占用磁盘空间大，内存大
   4. 备份和恢复不方便
   5. 重启的时候，数据节点将数据load到内存需要很长时间