AdminAPI 的 clusterSet.status() 命令警告您，如果 InnoDB 集群的 GTID 集与 InnoDB ClusterSet 中主集群上的 GTID 集不一致。与 InnoDB ClusterSet 中的其他集群相比，处于此状态的集群具有额外的事务，并且具有全局状态 OK_NOT_CONSISTENT 。 集群在 InnoDB ClusterSet 中继续运行，状态为该状态，如果其 GTID 集是可用副本集群中最新的，则可以对其执行紧急故障切换。但是，它不符合受控切换的条件，因为事务的差异可能会导致客户端访问不正确的数据。如果集群离线，它也不能用额外的事务重新加入 InnoDB ClusterSet 。
InnoDB ClusterSet 中的副本集群是只读的，因此如果它一直是副本集群，那么它不应该包含额外的事务，除非在不使用 AdminAPI 命令的情况下对集群进行了更改。如果需要在组复制停止时对实例执行管理事务，请在执行管理语句之前始终将 sql_log_bin 系统变量的值设置为 OFF ， 然后再设置为 on：
SET SQL_LOG_BIN=0;
<administrator action>
SET SQL_LOG_BIN=1;
将此系统变量设置为 OFF 意味着从该点开始直到将其设置回 ON 为止发生的事务不会写入二进制日志，也不会为其分配 GTID 。
当主集群变得不可访问并且使用了紧急故障切换过程时，可能会在没有外部更改的情况下创建一组分散的事务。如果主集群在故障切换后保持在线，它可以继续通过仍然连接到它的任何 MySQL 路由器实例接受来自客户端的事务，并将这些事务传递给仍然连接到其的任何副本集群，显著的复制延迟可能会导致选择作为替换主集群的副本集群丢失来自主集群的一些事务。在这种情况下，当旧的主集群最初作为无效的副本集群重新联机时，从未传输到副本的事务将被标识为额外事务。
clusterSet.status() 命令的扩展输出标识具有额外事务的任何集群，并为它们分配 OK_NOT_CONSISTENT 全局状态。例如：
mysql-js> myclusterset.status({extended: 1})
{
"clusters": {
"clusterone": {
"clusterErrors": [
"ERROR: Errant transactions detected"
],
"clusterRole": "REPLICA",
"clusterSetReplication": {
"applierStatus": "APPLIED_ALL",
"applierThreadState": "Waiting for an event from Coordinator",
"applierWorkerThreads": 4,
"receiver": "127.0.0.1:3310",
"receiverStatus": "ON",
"receiverThreadState": "Waiting for source to send event",
"source": "127.0.0.1:4410"
},
"clusterSetReplicationStatus": "OK",
"globalStatus": "OK_NOT_CONSISTENT",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"127.0.0.1:3310": {
"address": "127.0.0.1:3310",
"memberRole": "PRIMARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:3320": {
"address": "127.0.0.1:3320",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:3330": {
"address": "127.0.0.1:3330",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
}
},
"transactionSet": "54ff337b-2ccf-11ec-95da-3c6aa7197deb:1-131,54ff3ed7-2ccf-11ec-95da-3c6aa7197deb:1-5,c06527d6-2ce3-11ec-a55e-3c6aa7197deb:1,c0653492-2ce3-11ec-a55e-3c6aa7197deb:1-5",
"transactionSetConsistencyStatus": "INCONSISTENT",
"transactionSetConsistencyStatusText": "There are 1 transactions that were executed in this instance that did not originate from the PRIMARY.",
"transactionSetErrantGtidSet": "c06527d6-2ce3-11ec-a55e-3c6aa7197deb:1",
"transactionSetMissingGtidSet": ""
},
"clustertwo": {
"clusterRole": "PRIMARY",
"globalStatus": "OK",
"primary": "127.0.0.1:4410",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"127.0.0.1:4410": {
"address": "127.0.0.1:4410",
"memberRole": "PRIMARY",
"mode": "R/W",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:4420": {
"address": "127.0.0.1:4420",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
},
"127.0.0.1:4430": {
"address": "127.0.0.1:4430",
"memberRole": "SECONDARY",
"mode": "R/O",
"replicationLagFromImmediateSource": "",
"replicationLagFromOriginalSource": "",
"status": "ONLINE",
"version": "8.0.27"
}
},
"transactionSet": "54ff337b-2ccf-11ec-95da-3c6aa7197deb:1-131,54ff3ed7-2ccf-11ec-95da-3c6aa7197deb:1-5"
}
},
"domainName": "testclusterset",
"globalPrimaryInstance": "127.0.0.1:4410",
"metadataServer": "127.0.0.1:4410",
"primaryCluster": "clustertwo",
"status": "AVAILABLE",
"statusText": "Primary Cluster available, there are issues with a Replica cluster."
}
将单个服务器的数据与 InnoDB 集群的其他数据进行协调的最安全方法是在 InnoDB ClusterSet 部署中确定具有最佳数据的服务器（最多的事务、最近的事务或最重要的事务），并使用 MySQL 的克隆功能将内容从该服务器传输到受影响的服务器。有关执行此操作的说明，请参阅 克隆远程数据 。然后使用 cluster.rejoinInstance() 命令让实例重新加入 InnoDB 集群。有关此操作的详细信息，请参见 第 7.8.1 节 “将实例重新加入到集群” 。
如果整个 InnoDB 集群受到影响，请按照 8.9.4 从 InnoDB ClusterSet 中移除集群 中的步骤，从 InnoDB 集集群部署中删除受影响的集群，并在其位置设置一个新的 InnoDB 集群。作为设置过程的一部分，新 InnoDB 集群中的服务器实例将接收正确的事务集。
如果您想保留额外的事务，可以按照 8.8 InnoDB ClusterSet 的紧急故障切换 中的步骤，执行紧急故障切换，以使具有这些事务的 InnoDB Cluster 成为主集群。
如果您能够处理问题事务，请使用 clusterSet.rejoinCluster() 操作将 InnoDB 集群重新连接到 InnoDB clusterSet 部署。有关此操作的说明，请参阅 8.9.5 将集群重新加入到 InnoDB ClusterSet 。
扫一扫
735
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
