InnoDB Cluster 中至少需要三个实例才能容忍一个实例的故障。添加更多实例会增加对 InnoDB Cluster 故障的容忍度。
从版本 8.0.17 开始,Group Replication 实现了考虑实例补丁版本的兼容性策略,
操作会检测到这一点,如果出现不兼容,操作会因错误而终止。请参阅
检查实例上的 MySQL 版本并
在一个组中组合不同的成员版本。
Cluster
.addInstance()
如果实例已经包含数据,
cluster.checkInstanceState()
首先使用该函数验证现有数据不会阻止实例加入集群。请参阅检查实例状态。
使用该
函数将实例添加到集群,其中
是到已配置实例的连接信息,请参阅
第 7.4.2 节,“为 InnoDB 集群使用配置生产实例”。例如:
Cluster
.addInstance(instance
)instance
mysql-js> cluster.addInstance('icadmin@ic-2:3306')
A new instance will be added to the InnoDB cluster. Depending on the amount of
data on the cluster this might take from a few seconds to several hours.
Please provide the password for 'icadmin@ic-2:3306': ********
Adding instance to the cluster ...
Validating instance at ic-2:3306...
This instance reports its own address as ic-2
Instance configuration is suitable.
The instance 'icadmin@ic-2:3306' was successfully added to the cluster.
该addInstance(instance[,
options])
函数的选项字典提供以下属性:
标签:正在添加的实例的标识符。
recoveryMethod:状态恢复的首选方法。可以是自动的、克隆的或增量的。默认为自动。
waitRecovery:整数值,指示命令是否应等待恢复过程完成及其详细级别。
password:实例连接密码。
memberSslMode:实例上使用的 SSL 模式。
ipWhitelist:允许连接到实例进行组复制的主机列表。已弃用。
ipAllowlist:允许连接到实例进行组复制的主机列表。
localAddress:字符串值,包含要使用的 Group Replication 本地地址,而不是自动生成的地址。
groupSeeds:字符串值,包含要使用的组复制对等地址的逗号分隔列表,而不是自动生成的地址。弃用和忽略。
interactive:布尔值,用于在命令执行中禁用/启用向导,即根据设置的值是否提供提示和确认。默认值等于 MySQL Shell 向导模式。
exitStateAction:表示组复制退出状态动作的字符串值。
memberWeight:整数值,带有故障转移时自动主要选举的百分比权重。
autoRejoinTries:整数值,用于定义实例在被驱逐后尝试重新加入集群的次数。
当一个新实例被添加到集群中时,这个实例的本地地址会自动添加到
group_replication_group_seeds
所有在线集群实例上的变量中,以便在需要时允许它们使用新实例重新加入组。
中列出的实例
group_replication_group_seeds
根据它们在列表中出现的顺序使用。这确保用户指定的设置首先使用并成为首选。有关更多信息,请参阅第 7.5.2 节,“自定义 InnoDB Cluster 成员服务器”。
如果您使用的是 MySQL 8.0.17 或更高版本,您可以选择实例如何恢复与集群同步所需的事务。只有当加入实例恢复了集群之前处理的所有事务后,它才能作为在线实例加入并开始处理事务。有关详细信息,请参阅 第 7.4.6 节,“将 MySQL 克隆与 InnoDB Cluster 一起使用”。
同样在 8.0.17 及更高版本中,您可以配置
行为方式,让恢复操作在后台进行或在 MySQL Shell 中监视不同级别的进度。
Cluster
.addInstance()
根据您选择从集群恢复实例的选项,您会在 MySQL Shell 中看到不同的输出。假设您要将实例 ic-2 添加到集群,而 ic-1 是种子或捐赠者。
-
当您使用 MySQL Clone 从集群中恢复实例时,输出如下所示:
Validating instance at ic-2:3306... This instance reports its own address as ic-2:3306 Instance configuration is suitable. A new instance will be added to the InnoDB cluster. Depending on the amount of data on the cluster this might take from a few seconds to several hours. Adding instance to the cluster... Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background. Clone based state recovery is now in progress. NOTE: A server restart is expected to happen as part of the clone process. If the server does not support the RESTART command or does not come back after a while, you may need to manually start it back. * Waiting for clone to finish... NOTE: ic-2:3306 is being cloned from ic-1:3306 ** Stage DROP DATA: Completed ** Clone Transfer FILE COPY ############################################################ 100% Completed PAGE COPY ############################################################ 100% Completed REDO COPY ############################################################ 100% Completed NOTE: ic-2:3306 is shutting down... * Waiting for server restart... ready * ic-2:3306 has restarted, waiting for clone to finish... ** Stage RESTART: Completed * Clone process has finished: 2.18 GB transferred in 7 sec (311.26 MB/s) State recovery already finished for 'ic-2:3306' The instance 'ic-2:3306' was successfully added to the cluster.
应注意有关服务器重启的警告,您可能必须手动重启实例。请参阅 RESTART 语句。
-
当您使用增量恢复从集群中恢复实例时,输出如下所示:
Incremental distributed state recovery is now in progress. * Waiting for incremental recovery to finish... NOTE: 'ic-2:3306' is being recovered from 'ic-1:3306' * Distributed recovery has finished
要取消对恢复阶段的监视,请发出
CONTROL+C。这会停止监视,但恢复过程会在后台继续进行。waitRecovery
整数选项可以与
操作一起使用,
以控制命令在恢复阶段的行为。接受以下值:
Cluster
.addInstance()
0:不等待,让恢复过程在后台完成;
1:等待恢复过程完成;
2:等待恢复过程完成;并显示详细的静态进度信息;
3:等待恢复过程完成;并显示详细的动态进度信息(进度条);
默认情况下,如果运行 MySQL Shell 的标准输出是指终端,则该waitRecovery
选项默认为 3。否则,它默认为 2。请参阅
监控恢复操作。
要验证实例是否已添加,请使用集群实例的status()
函数。例如,这是添加第二个实例后沙盒集群的状态输出:
mysql-js> cluster.status()
{
"clusterName": "testCluster",
"defaultReplicaSet": {
"name": "default",
"primary": "ic-1:3306",
"ssl": "REQUIRED",
"status": "OK_NO_TOLERANCE",
"statusText": "Cluster is NOT tolerant to any failures.",
"topology": {
"ic-1:3306": {
"address": "ic-1:3306",
"mode": "R/W",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
},
"ic-2:3306": {
"address": "ic-2:3306",
"mode": "R/O",
"readReplicas": {},
"role": "HA",
"status": "ONLINE"
}
}
},
"groupInformationSourceMember": "mysql://icadmin@ic-1:3306"
}
如何继续取决于实例是本地实例还是远程实例 MySQL Shell 正在运行,以及实例是否支持自动持久化配置更改,请参阅
第 6.2.4 节,“持久化设置”。如果实例支持自动保留配置更改,则您无需手动保留设置,可以添加更多实例或继续下一步。如果实例不支持自动持久化配置更改,您必须在本地配置实例。请参阅配置实例
dba.configureLocalInstance()
. 这对于确保实例在离开集群时重新加入集群至关重要。
如果实例有,
super_read_only=ON
那么您可能需要确认 AdminAPI 可以设置
super_read_only=OFF
。更多信息请参见
超级只读模式下的实例配置。
部署集群后,您可以配置 MySQL Router 以提供高可用性,请参阅 第 6.10 节,“将 MySQL Router 与 AdminAPI、InnoDB Cluster 和 InnoDB ReplicaSet 结合使用”。
该cluster.checkInstanceState()
函数可用于验证实例上的现有数据不会阻止它加入集群。此过程通过与集群已处理的 GTID 相比验证实例的全局事务标识符 (GTID) 状态来工作。有关 GTID 的更多信息,请参阅
GTID 格式和存储。此检查使您能够确定是否可以将已处理事务的实例添加到集群中。
下面演示了在正在运行的 MySQL Shell 中发出此命令:
mysql-js> cluster.checkInstanceState('icadmin@ic-4:3306')
此函数的输出可以是以下之一:
OK new:实例没有执行任何 GTID 事务,因此它不能与集群执行的 GTID 冲突
OK recoverable:实例执行的 GTID 与集群种子实例执行的 GTID 不冲突
ERROR diverged: 实例执行的 GTIDs 与集群种子实例的执行 GTIDs 不同
ERROR lost_transactions:实例执行的 GTID 多于集群种子实例的执行 GTID
状态为OK的实例可以加入集群,因为实例上的任何数据都与集群保持一致。换句话说,被检查的实例没有执行任何与集群执行的 GTID 冲突的事务,并且可以恢复到与集群其余实例相同的状态。