PDF (US Ltr) - 2.2Mb
PDF (A4) - 2.3Mb
如果 InnoDB Cluster 的 GTID 集與 InnoDB ClusterSet 中主要叢集的 GTID 集不一致，AdminAPI 的 clusterSet.status()OK_NOT_CONSISTENT。該叢集在此狀態下繼續在 InnoDB ClusterSet 中運作，如果其 GTID 集是可用的複本叢集中最新的，您可以對其執行緊急容錯移轉。但是，它不符合受控制的切換資格，因為交易中的差異可能會導致客戶端存取不正確的資料。如果叢集離線，也無法重新加入具有額外交易的 InnoDB ClusterSet。
InnoDB ClusterSet 中的複本叢集是唯讀的，因此如果它一直是一個複本叢集，則除非在沒有使用 AdminAPI 命令的情況下對叢集進行了變更，否則不應包含額外的交易。如果您需要在 Group Replication 停止時在執行個體上執行管理交易，請務必在發出管理語句之前將 sql_log_bin 系統變數的值設定為 OFF，然後再將其設定回 ON。
SET SQL_LOG_BIN=0;
<administrator action>
SET SQL_LOG_BIN=1;將此系統變數設定為 OFF 表示從該點開始到您將其設定回 ON 為止發生的交易不會寫入二進位日誌，也不會為其分配 GTID。
當主要叢集無法連線且使用緊急容錯移轉程序時，可能會在沒有外部變更的情況下產生分歧的交易集。如果主要叢集在容錯移轉後保持在線上，則它可能會繼續透過仍連線到它的任何 MySQL Router 執行個體接受來自客戶端的交易，並將這些交易傳遞給仍連線到它的任何複本叢集。或者，顯著的複寫延遲可能會導致選為取代主要叢集的複本叢集遺失主要叢集的一些交易。在這種情況下，當舊的主要叢集最初以無效的複本叢集重新上線時，從未傳輸到複本的交易會被識別為額外的交易。
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 Cluster 的其餘部分協調一致的最安全方法是識別 InnoDB ClusterSet 部署中具有最佳資料（最多的交易、最新的交易或最重要的交易）的伺服器，並使用 MySQL 的複製功能將內容從該伺服器傳輸到受影響的伺服器。有關執行此操作的說明，請參閱複製遠端資料。然後使用 cluster.rejoinInstance()
如果整個 InnoDB Cluster 受到影響，請按照第 8.9.4 節「從 InnoDB ClusterSet 中移除叢集」中的程序，從 InnoDB ClusterSet 部署中移除受影響的叢集，並在其位置設定一個新的 InnoDB Cluster。新 InnoDB Cluster 中的伺服器執行個體將在設定過程中接收正確的交易集。
如果您想保留額外的交易，可以執行緊急容錯移轉，以按照第 8.8 節「InnoDB ClusterSet 緊急容錯移轉」中的程序，將具有這些交易的 InnoDB Cluster 設為主要叢集。
如果您可以處理有問題的交易，請使用 clusterSet.rejoinCluster()