大家好！
一旦一项任务出现在工作上-在使用centos 7.5的多个虚拟机上似乎已经配置了测试innoDB集群，您需要对其进行研究并添加更多的节点。 您可以随意破坏和嘲笑。 听起来很诱人。
在此之前，我没有使用此类集群的经验，但需要Google的帮助。
除少数例外，它和Yandex中的所有链接都位于dev.mysql.com上，或
位于Habr上的
本文上 。 似乎在其上配置了两个节点的集群。
好吧，我阅读了这篇文章，我对添加节点的复杂性和缺少许多细节感到有些惊讶，但是很好。 犯了一个错误，我添加了一半的新节点（有些命令没有用，有些命令通常破坏了所有内容），之后我开始尝试重启节点，等等。
经过数种方法和无数的神经细胞死亡，该簇无法忍受。 一个节点在任何情况下都不希望被添加，另一个节点在尝试对数据库的任何访问时都挂断了，第三个则假装一切正常。 我不得不射击并从头开始。
不幸的是，在创建新集群时，会出现很多问题和不一致之处。 也许关键在于软件版本，我尝试了mysql 5.7。 也许在分配。 结果，我停止了漫长的尝试来尝试在一张纸上做所有事情，并开始通过打字进行设置。 和谷歌。
几个愉快的夜晚和夜晚，群集聚集甚至拒绝崩溃。
同时，其创建方法与以前的尝试明显不同，我想与大家分享，因为 在Internet上，我没有找到其他相关的，详细的，易于理解的说明来设置indoDB集群。
因此，我们有三个完全相同的虚拟机，新安装的Centos 7.5 minimum 1804和禁用的selinux和firewalld：
1.1.1.1
1.1.1.2
1.1.1.3
为了工作，我使用mysql 5.7，因此我们使用它。 让我们从1.1.1.1开始：
1.安装mysql-community存储库：
rpm -i https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm
关闭8的存储库，打开5.7并检查-如果一切正常，然后安装mysql：
yum install yum-utils yum-config-manager --disable mysql80-community yum-config-manager --enable mysql57-community yum repolist yum install mysql-community-server mysql-shell
2.我们将/etc/my.cnf转换为以下格式：
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock symbolic-links=0 log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid bind-address=0.0.0.0 port=3301 # Replication part server_id=1 gtid_mode=ON enforce_gtid_consistency=ON master_info_repository=TABLE relay_log_info_repository=TABLE binlog_checksum=NONE log_slave_updates=ON log_bin=binlog binlog_format=ROW plugin-load = group_replication.so # Group replication part transaction_write_set_extraction=XXHASH64 loose-group_replication_start_on_boot = OFF loose-group_replication_local_address = 1.1.1.1:33011 loose-group_replication_bootstrap_group = OFF report_port = 3301 report_host = 1.1.1.1
这里的3301是mysql监听的端口，而33011是节点相互通信的端口。
3.启动mysql并执行初步配置：
systemctl start mysqld grep 'password' /var/log/mysqld.log mysql_secure_installation
4.好了，创建一个集群以及一个单独的用户来管理它。 如果事先知道节点的IP地址，则可以立即在ipWhitelist中列出它们。 我们将假装尚不了解1.1.1.2。 和1.1.1.3：
mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.1:3301 > dba.checkInstanceConfiguration() > cl=dba.createCluster('TestCluster', {ipWhitelist: '1.1.1.1'}) > dba.configureLocalInstance() > cl.status()
做完了！ cl.status应该输出如下内容：
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
更改集群时，有必要在所有节点上本地执行dba.configureLocalInstance（）命令以保存更改：
WARNING: On instance '1.1.1.1:3301' membership change cannot be persisted since MySQL version 5.7.23 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please use the <Dba>.configureLocalInstance command locally to persist the changes.
因为 我们将添加更多的节点，我们不会关闭与服务器1.1.1.1的连接，它将对我们很方便。
现在，让我们尝试将节点1.1.1.2添加到集群中。 为此，我们在其上执行所有相同的命令，包括3个步骤（包括3个步骤），不要忘记更改server_id，loose-group_replication_local_address和report_host。
4.我们执行1.1.1.2：
mysql -p > set GLOBAL group_replication_allow_local_disjoint_gtids_join=ON;
我试图通过mysqlsh设置此变量，切换到sql模式，但是那里的动作并没有影响mysql。 下一个：
mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.2:3301 > dba.checkInstanceConfiguration()
5.返回到第一个节点1.1.1.1。 如果关闭了连接，则可以像这样快速连接到集群：
mysqlsh --uri cladmin@1.1.1.1:3301 --cluster > \sql > STOP GROUP_REPLICATION; > SET GLOBAL group_replication_ip_whitelist="1.1.1.1,1.1.1.2"; > START GROUP_REPLICATION; > \js > cluster.addInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2'}) > cluster.status()
由于某些原因，当添加不带ipWhitelist选项的节点时，该节点不会自动传输给它，因此我们手动指定它。
如果最初为所有节点或子网配置了白名单，则可以跳过sql模式下的命令。
不要忘记在所有节点上执行dba.configureLocalInstance（）以保存配置。
他们的两个节点组成的集群：
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
好吧，这里有两个节点的群集，但是在“群集不能容忍任何故障”中。
添加第三个，该算法与添加第二个基本相同。
如果再次需要更改白名单，则需要在r / w节点上执行命令，因为 在R / O节点上，似乎没有任何作用。 在这种情况下，R / O节点将掉落，需要重新连接，同时报告新的白名单。
在我们的情况下：
> cluster.rejoinInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2,1.1.1.3'})
很好，同样，不要忘记在所有节点上执行dba.configureLocalInstance（）以保存配置。
由三个节点组成的集群如下所示：
{ "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.3:3301": { "address": "1.1.1.3:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" }
如果群集已崩溃到一个节点的状态，则需要使用/etc/my.cnf中的松散group_replication_bootstrap_group = ON参数启动它
启动后，将需要再次关闭该参数，否则该节点将始终与集群分离并保持其自身。
此处已对安装mysql-router进行了详细说明，因此我认为复制没有任何意义。
就是这样，我希望有人能对我的经验有所帮助。
谢谢您的关注。