镇江网站建设远航网络,wordpress的视频嵌入,微信云开发文档,重庆渝云建设有限公司AdminAPI 的 clusterSet.status() 命令警告您#xff0c;如果 InnoDB 集群的 GTID 集与 InnoDB ClusterSet 中主集群上的 GTID 集不一致。与 InnoDB ClusterSet 中的其他集群相比#xff0c;处于此状态的集群具有额外的事务#xff0c;并且具有全局状态 OK_NOT_CONSISTENT 。…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_BIN0;
administrator action
SET SQL_LOG_BIN1;将此系统变量设置为 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 。
