MySQL-Galera-Cluster集群详细介绍_galera集群

一、什么是Mysql集群？

1.单节点mysql存在的常见问题

• 当数据量和并发量上去后，单节点数据库无法满足大并发时性能上的要求。
• 单节点的MySQL无法满足高可用，数据库宕机或者意外中断等故障后，业务服务被迫中断。
• 当数据量和并发量上去后，单节点 MySQL无法承载巨大的业务量，数据库负载巨大。

2.mysql集群介绍

• MySQL集群是指多台服务器共同处理数据库请求，并具有高可用性和可伸缩性的MySQL数据库系统。由多个节点组成，每个节点都运行着MySQL的实例，并且共享数据，相互之间通过网络互联。当其中一个节点失败时，其他节点可以自动接管它的工作，确保系统的连续可用性。
• MySQL群集需要有一组计算机，每台计算机的角色可能是不一样的。
• MySQL群集中有三种节点：管理节点、数据节点和SQL节点。群集中的某计算机可能是某一种节点，也可能是两种或三种节点的集合。这三种节点只是在逻辑上的划分，所以它们不一定和物理计算机是一一对应的关系。

• 管理节点（也可以称管理服务器）主要负责管理数据节点和SQL节点，还有群集配置文件和群集日志文件。它监控其他节点的工作状态，能够启动、关闭或重启某个节点。其他节点从管理节点检索配置数据，当数据节点有新事件时就把事件信息发送给管理节点并写入群集日志。
• 数据节点用于存储数据，使用内存存放数据，保存进数据节点的数据都会自动复制并存储到其他数据节点。
• SQL节点跟一般的MySQL服务器是一样的，我们可以通过它进行SQL操作。也叫数据库节点，和我们平时使用的mysql相同，作为数据库使用。被数据节点访问。

3.Mysql集群的优点和风险

针对上面单节点mysql存在的常见问题对应，mysql集群有以下几点好处：

• 高可用性：通过在多个节点上复制数据，MySQL集群可以在某个节点发生故障时自动切换到其他节点，确保数据的不间断访问。
• 可扩展性：MySQL集群可以通过添加更多的节点来扩展系统的容量，以满足不断增长的业务需求。
• 高性能：MySQL集群可以通过并行处理和分布式计算来提高数据处理速度，从而提供更好的性能。
• 负载均衡：当数据量和并发量上去后，分摊原先只访问单个节点的数据库压力，分担压力到多个节点上。
• 当然谈到集群，就不得不提集群普遍存在的风险之一，脑裂，因为半数机制，所以还是尽可能的使用奇数个节点。

集群要考虑的风险

• 网络分裂：群集还可能由于网络故障而拆分为多个部分，每部分内的节点相互连接，但各部分之间的节点失去连接。
• 脑裂：导致数据库节点彼此独立运行的集群故障称为“脑裂”。这种情况可能导致数据不一致，并且无法修复，例如当两个数据库节点独立更新同一表上的同一行时。

二、Mysql集群的一些疑问

1.mysql的AB复制和Galera Cluster有什么区别？

• MySQL的AB复制和Galera Cluster是两种不同的复制和集群技术
• AB复制：AB复制（Asynchronous Binary Replication）是MySQL的一种异步复制技术。在AB复制中，一个MySQL服务器作为主服务器（A），接收写操作并将其记录在二进制日志中。另一个MySQL服务器作为从服务器（B），通过读取主服务器的二进制日志来复制数据。AB复制是MySQL的传统主从复制方式，主服务器和从服务器之间的复制是异步的。
• Galera Cluster：Galera Cluster是一种同步多主复制技术，它通过在多个MySQL节点之间保持数据一致性来实现高可用性和水平扩展。Galera Cluster使用了全球事务标识符（GTID）来跟踪和保证事务的一致性。Galera Cluster中的所有节点都是对等的，可以接收写操作，并且数据的复制是同步进行的，确保所有节点上的数据保持一致。

2.什么情况下适用AB复制，什么情况下使用Galera cluster？

AB复制适用于以下情况：

• 数据备份和恢复：AB复制可以通过复制主服务器的二进制日志来实现数据备份和恢复。
• 读写分离：通过将读操作分发到从服务器，可以分担主服务器的负载。
• 数据分析：通过在从服务器上进行数据分析，可以减轻主服务器的压力。

Galera Cluster适用于以下情况：

• 高可用性：Galera Cluster提供了多个节点间的同步复制，当一个节点发生故障时，其他节点可以继续提供服务，实现高可用性。
• 水平扩展：Galera Cluster可以通过增加节点来实现水平扩展，提供更好的性能和容量。
• 数据强一致性：Galera Cluster通过同步复制确保所有节点上的数据一致性，适用于对数据一致性要求较高的应用场景。

3.可以在AB复制的基础上做Galera集群么？

• 可以在AB复制的基础上构建Galera Cluster，但它们是两种不同的复制和集群技术，并不建议这么操作。
• AB复制是异步复制，而Galera Cluster是同步复制。
• 如果你想将AB复制迁移到Galera Cluster，需要进行一些额外的步骤和配置，例如将现有的AB复制节点转换为Galera Cluster的节点，并确保数据的一致性和正确性。
• 这通常需要进行数据同步和一致性检查，并确保所有节点都满足Galera Cluster的要求。
• 建议在进行此类迁移之前进行充分的规划和测试，以确保数据的安全和可靠性。

4.Myslq的AB复制是属于mysql集群中的一种么？

MySQL的AB复制(主从复制)并不属于严格意义上的数据库集群技术，主要原因如下：

• AB复制采用的是异步单向复制，存在数据不一致的问题，不满足集群对数据强一致性的要求。
• AB复制是一主多从的结构，只有主节点可以进行写操作，从节点为只读，这不符合集群的所有节点地位对等的特征。
• 当主节点发生故障时，AB复制需要人工进行故障切换和恢复，不能实现集群的自动故障转移。
• 从节点发生故障并不会影响主节点，而集群要求节点之间紧密协作，如果存在节点故障则整个集群不可用。
• AB复制也无法轻松实现在线扩容等集群的特性。
• 没有实现读写分离、负载均衡等集群功能。

5.为什么做了AB复制，还要做mysql galera集群呢？

• AB复制是单向异步复制，存在数据不一致，而Galera是多主同步复制，可以保证强一致性。
• AB复制需要手动故障切换，Galera支持自动故障检测和切换。
• AB复制只有主节点可写，从节点只读，不支持读写分离。Galera所有节点都可读写，支持灵活的读写分离。
• AB复制扩容需要手动添加新从节点。Galera可以在线动态添加新节点实现自动扩容。
• AB复制不提供负载均衡能力。Galera可以根据查询路由实现负载均衡。
• AB复制节点间没有数据校验，从节点数据不一致时不影响主节点。而Galera节点之间有数据校验，不一致时整个集群不可用。
• AB复制不支持自动节点提拔恢复，需要人工维护。Galera节点故障可以自动恢复。

6.总结

• AB复制是MySQL的异步复制机制，用于数据备份和故障恢复，不提供自动的读写分离和负载均衡功能。
• Galera Cluster 是基于同步复制的集群方案，利用 Galera 技术实现多主同步复制，它提供了高可用性、数据一致性、读写分离和负载均衡等功能。

三、Mysql-Galera-Cluster集群概念

1.galera-cluster 的介绍

• Galera Cluster：集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有三个版本，分别是Percona Xtradb Cluster、Mysql Galera Cluster及MariaDB Galera Cluster
• Galera本身是具有多主特性的，即采用multi-master的集群架构，是一个既稳健，又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案
• 当有客户端要写入或者读取数据时，连接哪个实例都是一样的，读到的数据是相同的，写入某一个节点之后，集群自己会将新数据同步到其它节点上面，这种架构不像其他集群共享任何自己数据，是一种高冗余架构
• Galera Cluster需要至少三个节点
• 如下图所示：三个节点组成了一个集群，与普通的主从架构不同，它们都可以作为主节点，三个节点是对等的，称为multi-master架构
  

2.Galera-cluster集群的优缺点

优点

• 多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的。
• 同步复制：集群不同节点之间数据同步，没有延迟，在数据库挂掉之后，数据不会丢失。
• 并发复制：从节点APPLY数据时，支持并行执行，更好的性能
• 故障切换：在出现数据库故障时，因支持多点写入，切换容易
• 热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少。在节点故障期间，节点本身对集群的影响非常小
• 自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为一致
• 对应用透明：集群的维护，对应用程序是透明的

缺点：

• 每个节点独立、异步执行会导致节点不一致性（每个节点其实是维护一个队列），为了保证各个节点的最终一致性，必须使用类tcp的滑动窗口来进行限制，实现原理如下：

整个galera cluster中，同时只有一个节点可以广播消息（数据），每个节点都会获得广播消息的机会（获得机会后也可以不广播），当慢节点的待执行队列超过一定长度后，它会广播一个FC_PAUSE消息，所以节点收到消息后都会暂缓广播消息，直到该慢节点的待执行队列长度减小到一定长度后，galera cluster数据同步又开始恢复

3.Galera-Cluster的工作流程

• 依靠一个全局的事务id，整个集群环境，每个事务的事务id都是唯一的。
• 客户端连接到一台主服务器上做更改，提交请求后会在当前连接的主服务器上做检查，如果失败，直接返回更新失败；如果成功，会把修改操作发给其他主节点；如果发生冲突，那么操作就会取消，返回失败信息。这样确保所有的服务器都会执行正确的指令，不会出现冲突
• 因此，所有节点都要做检查就会造成效率问题，延迟问题。
• 因此，galera cluster的集群有数量限制，主节点过多容易造成效率过低
  
• 当client端执行DML数据库操作语言时，将操作发给server，server将数据库所做的更改收集到一个写集中发给cluster，cluster中每个动作对应一个GTID
• 其它server接收到并通过验证(合并数据)后，执行appyl_cb动作和commit_cb动作，若验证没通过，则会退出处理当前server节点验证通过后，执行commit_cb，并返回，若没通过，执行rollback_cb。
• 只要当前节点执行了commit_cb和其它节点验证通过后就可返回。
• commit_cb和rollback_cb是什么？

• commit_cb（Commit Callback）：commit_cb 是在【事务提交】时执行的回调函数。当集群中的所有节点都接收并验证了写集中的更改后，如果验证通过，则会执行 commit_cb。在 commit_cb 中，可以进行一些后续的处理操作，例如更新数据库的状态、清理临时数据等。执行 commit_cb 表示事务已成功提交并在所有节点上生效。
• rollback_cb（Rollback Callback）：rollback_cb 是在【事务回滚】时执行的回调函数。如果在集群中的任何一个节点验证失败或发生错误，则会执行 rollback_cb。在 rollback_cb 中，可以进行一些回滚操作，例如撤销已应用的更改、恢复之前的状态等。执行 rollback_cb 表示事务未能成功提交，并需要回滚到事务开始前的状态。