PDF (US Ltr) - 2.3Mb
PDF (A4) - 2.3Mb
如果 InnoDB 叢集的 GTID 集合與 InnoDB ClusterSet 中主要叢集的 GTID 集合不一致，AdminAPI 的 clusterSet.status()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 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 叢集的其餘部分協調的最安全方法，是識別 InnoDB ClusterSet 部署中具有最佳資料（最多交易、最近交易或最重要交易）的伺服器，並使用 MySQL 的複製功能將內容從該伺服器傳輸到受影響的伺服器。如需執行此作業的指示，請參閱複製遠端資料。然後使用 cluster.rejoinInstance()
如果整個 InnoDB 叢集受到影響，請依照第 8.9.4 節，「從 InnoDB ClusterSet 移除叢集」中的程序，從 InnoDB ClusterSet 部署中移除受影響的叢集，並在其位置設定新的 InnoDB 叢集。新的 InnoDB 叢集中的伺服器執行個體將在設定過程中接收正確的交易集合。
如果您想要保留額外交易，可以執行緊急容錯移轉，讓具有這些交易的 InnoDB 叢集成為主要叢集，請依照第 8.8 節，「InnoDB ClusterSet 緊急容錯移轉」中的程序進行。
如果您能夠處理問題交易，請使用 clusterSet.rejoinCluster()