Mysql 8.0 集群简介【官方文档5种方式】

Mysql官方介绍几种集群架构：

Replication【主从复制】
Group Replication 【组复制】
InnoDB Cluster
InnoDB ReplicaSet
MySQL NDB Cluster 8.0

网上比较全的介绍比较少，本文机翻了Mysql官网对Mysql 8.0 几种集群方式的简介。
之后会一一研究并实际部署。

Replication【主从复制】

https://dev.mysql.com/doc/refman/8.0/en/replication.html
复制使数据从一个MySQL数据库服务器(称为源)复制到一个或多个MySQL数据库服务器(称为副本)。默认情况下，复制是异步的;副本不需要永久连接就可以从源接收更新。根据配置的不同，可以在数据库中复制所有数据库、选定的数据库，甚至选定的表。

MySQL中复制的优势包括:

扩展解决方案——在多个副本之间分散负载，以提高性能。在这种环境中，所有写操作和更新都必须在源服务器上进行。然而，读取可能发生在一个或多个副本上。这个模型可以提高写的性能(因为源代码是专门用于更新的)，同时在不断增加的副本数量上显著提高读速度。

数据安全——因为副本可以暂停复制过程，所以可以在副本上运行备份服务，而不会破坏相应的源数据。

分析——实时数据可以在源上创建，而信息分析可以在副本上进行，而不会影响源的性能。

远程数据分布—您可以使用复制创建数据的本地副本，供远程站点使用，而无需对源进行永久访问。

有关如何在这种情况下使用复制的信息，请参阅17.4节“复制解决方案”。

MySQL 8.0支持不同的复制方法。传统的方法基于从源的二进制日志中复制事件，并要求在源和副本之间同步日志文件和其中的位置。基于全局事务标识符(gtid)的新方法是事务性的，因此不需要处理日志文件或这些文件中的位置，这极大地简化了许多常见的复制任务。只要在源上提交的所有事务也应用到副本上，使用gtid的复制就能保证源和副本之间的一致性。关于gtid和基于gtid的MySQL复制的更多信息，请参见17.1.3小节，“使用全局事务标识符的复制”。有关使用基于二进制日志文件位置的复制的信息，请参阅17.1节“配置复制”。
MySQL中的复制支持不同类型的同步。原始的同步类型是单向异步复制，其中一个服务器作为源，而一个或多个其他服务器作为副本。这与同步复制形成了鲜明的对比，同步复制是NDB集群的一个特征(见第23章，MySQL NDB集群8.0)。在MySQL 8.0中，除了内置的异步复制外，还支持半异步复制。对于半同步复制，在返回到执行事务的会话之前，在源块上执行的提交，直到至少有一个副本承认它已经接收并记录事务的事件;请参见17.4.10节“半同步复制”。MySQL 8.0还支持延迟复制，这样副本就会故意滞后于源文件至少一段时间;参见17.4.11节“延迟复制”。对于需要同步复制的场景，请使用NDB集群(参见第23章，MySQL NDB集群8.0)。

Group Replication【组复制】

https://dev.mysql.com/doc/refman/8.0/en/group-replication.html
介绍MySQL组复制的背景信息。
创建容错系统的最常见方法是使组件冗余，换句话说，可以删除组件，系统应继续按预期运行。这就产生了一系列挑战，将这些系统的复杂性提升到一个完全不同的水平。具体来说，复制的数据库必须处理这样一个事实，即它们需要维护和管理多个服务器，而不仅仅是一个服务器。此外，由于服务器共同协作创建组，需要处理其他几个经典的分布式系统问题，如网络分区或大脑分裂场景。
因此，最终的挑战是将数据库和数据复制的逻辑与以一致和简单的方式协调多个服务器的逻辑融合在一起。换句话说，让多个服务器对系统的状态和系统所经历的每次更改的数据达成一致。这可以总结为让服务器在每个数据库状态转换上达成一致，这样它们都作为一个单一的数据库前进，或者最终收敛到相同的状态。这意味着它们需要作为(分布式)状态机进行操作。
MySQL组复制提供分布式状态机复制，在服务器之间具有很强的协调性。当服务器属于同一组时，它们会自动协调自己。该组可以在具有自动主选择的单主模式下运行，在这种模式下，每次只有一台服务器接受更新。另外，对于更高级的用户，可以以多主模式部署组，其中所有服务器都可以接受更新，即使更新是并发发布的。这种能力是以应用程序必须绕过此类部署所施加的限制为代价的。
有一个内置的组成员服务，可以保持组视图的一致性，并且在任何给定的时间点对所有服务器都可用。服务器可以离开并加入组，视图也相应更新。有时，服务器可能会意外地离开组，在这种情况下，故障检测机制会检测到这一点，并通知组视图已经更改。这都是自动的。
要提交事务，组中的大多数成员必须同意全局事务序列中给定事务的顺序。决定提交或中止事务是由每个服务器单独完成的，但所有服务器都做出相同的决定。如果出现网络分区，导致成员无法达成一致意见，则系统不会继续运行，直到该问题得到解决。因此，大脑也有一个内置的、自动的、裂脑保护机制。
所有这些都是由提供的组通信系统(GCS)协议驱动的。它们提供了故障检测机制、组成员服务以及安全且完全有序的消息传递。所有这些属性都是创建系统的关键，该系统可以确保数据在一组服务器之间一致复制。该技术的核心是Paxos算法的实现。它充当组通信引擎。

InnoDB Cluster简介:

https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-introduction.html
MySQL InnoDB集群为MySQL提供了一个完整的高可用性解决方案。通过使用AdminAPI，它包含在MySQL Shell中，你可以很容易地配置和管理一组至少三个MySQL服务器实例作为InnoDB集群。

InnoDB集群中的每个MySQL服务器实例都运行MySQL组复制，它提供了在InnoDB集群中复制数据的机制，并带有内置的故障转移功能。AdminAPI消除了在InnoDB集群中直接使用组复制的需要，但更多信息请参见组复制，它解释了详细信息。从MySQL 8.0.27开始，你也可以设置InnoDB ClusterSet(见第八章，InnoDB ClusterSet)来为InnoDB集群的部署提供容灾能力，通过连接一个主InnoDB集群和它自己的一个或多个副本在不同的位置，比如不同的数据中心。

MySQL路由器可以根据部署的集群自动配置自己，透明地连接客户机应用程序到服务器实例。如果服务器实例出现意外故障，集群将自动重新配置。在默认的单主模式下，一个InnoDB集群有一个读写服务器实例——主服务器。多个辅助服务器实例是主服务器的副本。如果主服务器出现故障，则从服务器自动升级为主服务器。MySQL路由器检测到这一点，并将客户端应用程序转发到新的主服务器。高级用户还可以将集群配置为拥有多个主节点。

InnoDB ReplicaSet

https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-replicaset-introduction.html
AdminAPI支持InnoDB ReplicaSet，允许你管理一组运行基于异步gtid的复制的MySQL实例，就像InnoDB集群一样。一个InnoDB ReplicaSet由一个主服务器和多个从服务器组成(传统上称为MySQL复制源和副本)。您可以使用ReplicaSet对象和AdminAPI操作来管理ReplicaSet，例如检查InnoDB ReplicaSet的状态，并在故障发生时手动切换到一个新的主节点。

类似于InnoDB集群，MySQL路由器支持针对InnoDB ReplicaSet的引导，这意味着你可以自动配置MySQL路由器来使用你的InnoDB ReplicaSet，而不需要手动配置。这使得InnoDB ReplicaSet成为一种快速和简单的方式来启动和运行MySQL复制和MySQL路由器，使它非常适合扩展读取，并在不需要InnoDB集群提供高可用性的用例中提供手动故障转移功能。

除了使用AdminAPI部署InnoDB ReplicaSet，你还可以采用现有的复制设置。AdminAPI根据复制设置的拓扑结构配置InnoDB ReplicaSet。一旦采用了复制设置，您就可以像从头部署InnoDB ReplicaSet一样管理它。这使您能够利用AdminAPI和MySQL路由器，而不需要创建一个新的复制集。要了解更多信息，请参见9.3节“采用现有的复制设置”。

InnoDB ReplicaSet可以在广域网中使用，对写性能没有影响，因为服务器实例是通过异步复制通道连接的，不需要在事务上达成一致。然而，在广域网上，复制延迟会更大，导致InnoDB ReplicaSet中的辅助服务器进一步落后于主服务器。

InnoDB ReplicaSet局限性。与InnoDB集群相比，InnoDB复制集有几个限制，所以建议尽可能地部署InnoDB集群。通常，一个InnoDB ReplicaSet本身并不能提供高可用性。InnoDB ReplicaSet的限制如下:

没有自动故障转移。在主服务器变为不可用的事件中，需要使用AdminAPI手动触发故障转移，然后才能再次进行任何更改。但是，次要实例仍然可用于读取。

由于意外停止或不可用，无法防止部分数据丢失。在暂停之前尚未申请的交易可能会丢失。

在意外退出或不可用之后，没有针对不一致的保护。如果故障转移在前主服务器仍然可用(例如，由于网络分区)的情况下促进了备用服务器，则可能会由于大脑分裂而引入不一致性。

InnoDB ReplicaSet不支持多主模式。允许在所有成员中写入数据的经典复制拓扑不能保证数据一致性。

因为InnoDB ReplicaSet是基于异步复制的，所以不可能像组复制那样对流量控制进行调优。

所有次要成员都从一个源进行复制。对于某些特定的场景或用例，这可能会对源代码产生影响。例如，许多非常小的更新正在进行。

MySQL NDB Cluster 8.0

https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster.html
本章提供了MySQL NDB集群的信息，这是一种适用于分布式计算环境的MySQL高可用、高冗余版本。最新的NDB集群版本系列使用了NDB存储引擎(也被称为NDBCLUSTER)的版本8来支持在集群中运行多台带有MySQL服务器和其他软件的计算机。NDB集群8.0，现在作为通用可用性(GA)版本(从8.0.19版本开始)发布，包含了NDB存储引擎的8.0版本。NDB Cluster 7.6和NDB Cluster 7.5，仍然可以作为GA版本使用，分别使用NDB 7.6和7.5版本。以前的GA版本仍然可以在生产环境中使用，NDB Cluster 7.4和NDB Cluster 7.3，分别包含了NDB 7.4和NDB 7.3版本。不再支持或维护NDB 7.2和更早的版本系列。

本章包含关于NDB Cluster 8.0到8.0.29版本的信息。NDB Cluster 8.0现在作为通用可用性发布(从NDB 8.0.19开始)，推荐用于新部署;最新可用的版本是NDB 8.0.28。NDB Cluster 7.6和7.5是以前的GA版本，在生产中仍然支持;有关NDB集群7.6的信息，请参见NDB集群7.6新增内容。关于NDB集群7.5的类似信息，请参见NDB集群7.5新增内容。NDB Cluster 7.4和7.3是以前的GA版本，在生产环境中仍然支持，尽管我们建议新的部署使用NDB Cluster 8.0;请参考MySQL NDB集群7.3和NDB集群7.4。