MySQL Shell 8.4  /  MySQL InnoDB ClusterSet  /  InnoDB ClusterSet 狀態與拓樸

8.6 InnoDB ClusterSet 狀態與拓樸

本節說明以下內容

InnoDB ClusterSet 狀態

AdminAPI 的 clusterSet.status() 命令會傳回描述 InnoDB ClusterSet 部署狀態的 JSON 物件。輸出包含 InnoDB ClusterSet 部署本身的狀態，以及 ClusterSet 中每個 InnoDB 叢集的整體和叢集狀態。擴充輸出會新增每個叢集中每個成員伺服器的狀態、由 InnoDB ClusterSet 管理的非同步複製通道的相關資訊，以及其他組態與狀態資訊。命令會報告 ClusterSet 複製和伺服器本身的狀態。如果有任何問題，則會包含警告和錯誤訊息，以更詳細地說明問題。

您使用 clusterSet.status() 的 MySQL Shell 執行個體可以連線至 InnoDB ClusterSet 的任何作用中成員。中繼資料可以透過 InnoDB ClusterSet 中任何其他作用中的叢集，從主要叢集擷取。

如果 InnoDB ClusterSet 中的任何叢集有問題，第 8.9 節：「InnoDB ClusterSet 修復與重新加入」會說明修復問題並將叢集重新加入 ClusterSet 的程序 (如果問題無法修復，則移除叢集)。如果出現問題的叢集是主要叢集，則您必須先執行受控切換 (如果它仍在運作) (如第 8.7 節：「InnoDB ClusterSet 受控切換」中所述)，或如果它無法運作或無法連線，則執行緊急容錯移轉 (如第 8.8 節：「InnoDB ClusterSet 緊急容錯移轉」中所述)。

您可以使用 extended 選項 (預設為 0)，以增加輸出詳細程度，如下所示

  • extended: 0 或省略選項，會傳回有關 InnoDB ClusterSet 部署可用性狀態、ClusterSet 中每個 InnoDB 叢集，以及每個複本叢集的 ClusterSet 複製狀態的基本資訊。

  • extended: 1 會新增 ClusterSet 中每個 InnoDB 叢集的拓樸、每個叢集中每個個別成員伺服器的狀態，以及有關每個複本叢集的 ClusterSet 複製通道狀態的更詳細資訊。

  • extended: 2 會新增有關每個叢集中每個個別成員伺服器的進一步詳細資料，以及有關 ClusterSet 複製通道的詳細資料，包括 GTID 集合。

  • extended: 3 會新增 ClusterSet 複製通道的重要組態設定，例如連線重試設定。

例如

mysql-js> myclusterset.status({extended: 1}) 
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "globalStatus": "OK",
            "primary": "127.0.0.1:3310",
            "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/W",
                    "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": "953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8"
        },
        "clustertwo": {
            "clusterRole": "REPLICA",
            "clusterSetReplication": {
                "applierStatus": "APPLIED_ALL",
                "applierThreadState": "Waiting for an event from Coordinator",
                "applierWorkerThreads": 4,
                "receiver": "127.0.0.1:4410",
                "receiverStatus": "ON",
                "receiverThreadState": "Waiting for source to send event",
                "source": "127.0.0.1:3310"
            },
            "clusterSetReplicationStatus": "OK",
            "globalStatus": "OK",
            "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/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "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": "0f6ff279-2764-11ec-ba06-00059a3c7a00:1-5,953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8",
            "transactionSetConsistencyStatus": "OK",
            "transactionSetErrantGtidSet": "",
            "transactionSetMissingGtidSet": ""
        }
    },
    "domainName": "testclusterset",
    "globalPrimaryInstance": "127.0.0.1:3310",
    "metadataServer": "127.0.0.1:3310",
    "primaryCluster": "clusterone",
    "status": "HEALTHY",
    "statusText": "All Clusters available."
}

若要取得代表目標伺服器執行個體的 InnoDB ClusterSet 的 ClusterSet 物件的控制代碼，請使用 dba.getClusterSet() 或 cluster.getClusterSet() 命令。如果目標伺服器執行個體是 InnoDB ClusterSet 部署一部分的 InnoDB 叢集成員，即使目前無法連線到 InnoDB ClusterSet 部署的主要叢集，這些命令也會運作。當您使用物件時，必須可以連線到目標伺服器執行個體本身。如果目標執行個體是已標示為失效的叢集成員，則命令會傳回警告，但仍會傳回 ClusterSet 物件。如果目標執行個體目前不是 InnoDB ClusterSet 部署的成員，則命令會傳回錯誤。ClusterSet 物件包含您從中擷取它的伺服器的連線詳細資料，因此您先前從現在離線的成員伺服器擷取的 ClusterSet 物件將不再運作，而且您需要從 InnoDB ClusterSet 部署中線上的伺服器再次取得它。

ClusterSet 物件預設使用取得它時所用的帳戶，以用於需要權限的操作。當您使用適合您想要使用它執行之操作的使用者帳戶連線至伺服器執行個體時，取得物件非常重要。InnoDB ClusterSet 部署程序中的某些操作需要權限，而儲存在物件中的預設使用者帳戶會用於此目的，以便程序不需要儲存任何其他使用者帳戶。對於監控和疑難排解您已設定的 InnoDB ClusterSet，InnoDB 叢集管理員帳戶是適當的。對於初始叢集部署程序，InnoDB 叢集伺服器組態帳戶是適當的。如需更多資訊，請參閱第 8.3 節：「InnoDB ClusterSet 的使用者帳戶」。

當您使用 clusterSet.status() 函數時，為 InnoDB ClusterSet 部署報告的整體 ClusterSet 狀態 (status 欄位) 可以是下列其中一種

HEALTHY

InnoDB ClusterSet 中的主要叢集運作正常，且所有複本叢集都運作正常。

AVAILABLE

InnoDB ClusterSet 中的主要叢集運作正常，但一個或多個複本叢集的運作受到影響或無法運作。

UNAVAILABLE

InnoDB ClusterSet 中的主要叢集無法運作，因為它處於離線狀態或遺失仲裁，或者 MySQL Shell 無法連線至主要叢集以判斷其狀態。

為 InnoDB ClusterSet 部署報告的整體 ClusterSet 狀態取決於每個 InnoDB 叢集的整體狀態。ClusterSet 中的 InnoDB 叢集會報告三種狀態

  • 整體狀態 (globalStatus 欄位) 是 InnoDB 叢集在其於 InnoDB ClusterSet 中角色方面的狀態。此狀態會顯示叢集是否仍可在 InnoDB ClusterSet 部署中正常運作，即使它有一些問題 (例如成員伺服器目前處於離線狀態)。在容錯移轉期間，InnoDB 叢集可能會標示為失效，無論成員伺服器的狀態為何，如果是，則會顯示為整體狀態。

  • 叢集狀態 (status 欄位) 是 InnoDB 叢集在其自身運作方面的狀態。此狀態會顯示叢集是否有任何技術問題，例如一個或多個成員處於離線狀態、遺失仲裁或群組複製錯誤狀態。叢集可以容忍某些問題，但仍可作為 InnoDB ClusterSet 部署的一部分正常運作。因此，在預設詳細程度下，clusterSet.status() 函數只會報告那些導致整體狀態問題的叢集的叢集狀態。若要檢視 InnoDB ClusterSet 中所有叢集的叢集狀態，無論是否導致整體狀態問題，請使用 extended 選項來指定較高的詳細程度。

  • ClusterSet 複製狀態 (clusterSetReplicationStatus 欄位) 是複本 InnoDB 叢集的 ClusterSet 複製通道的狀態。此狀態會顯示複本叢集從主要叢集進行複製是否有任何問題，以便將這些問題與叢集中成員伺服器的任何技術問題分開考慮。無論是否導致整體狀態問題，複本 InnoDB 叢集都會報告 ClusterSet 複製狀態。主要 InnoDB 叢集沒有此狀態欄位，因為 ClusterSet 複製通道未在主要叢集上運作。

在較高的詳細程度下，clusterSet.status() 函數的擴充輸出會顯示每個 InnoDB 叢集中每個成員伺服器的狀態。輸出包含成員的群組複製狀態 (memberState 欄位)，以及複本叢集中伺服器的成員複製狀態。如需群組複製狀態的資訊，請參閱群組複製伺服器狀態。

為 InnoDB 叢集報告的整體狀態 (globalStatus 欄位) 可以是下列其中一種

OK

叢集在 InnoDB ClusterSet 部署中運作正常。叢集中至少有一個成員伺服器處於群組複製的 ONLINE 狀態，且複製群組具有仲裁。如果叢集是複本叢集，則 ClusterSet 複製狀態也是 OK。此整體狀態不一定表示叢集沒有任何技術問題。某些成員可能處於離線狀態，或者叢集可能沒有足夠的成員來提供容錯能力。但是，叢集的運作狀況良好，足以繼續作為 InnoDB ClusterSet 部署的一部分。主要叢集或複本叢集可以具有此整體狀態。

OK_NOT_REPLICATING

叢集運作正常，但複製已在 ClusterSet 複製通道上停止，可能是因為受控停止或因複製錯誤。只有複本叢集可以具有此整體狀態。

OK_NOT_CONSISTENT

叢集運作尚可接受，但叢集上的交易集合（GTID 集合）與主要叢集上的交易集合已出現差異，導致複本叢集上存在主要叢集沒有的額外交易。叢集集合複寫通道上的複寫可能已停止，可能是受控停止或因複寫錯誤導致，也可能是通道仍在複寫中。只有複本叢集才可能具有此全域狀態。具有此狀態的複本叢集無法進行計畫性的切換，但可以強制容錯移轉。

OK_MISCONFIGURED

叢集運作尚可接受，但偵測到叢集集合複寫通道的配置不正確。例如，通道可能正在從錯誤的來源複寫。複寫通道可能仍在執行，或複寫可能已停止。只有複本叢集才可能具有此全域狀態。

NOT_OK

由於技術問題，叢集無法作為 InnoDB 叢集集合部署的一部分運作。它已失去仲裁，或所有成員伺服器都處於 Group Replication 的 OFFLINE 狀態。主要叢集或複本叢集都可能具有此全域狀態。如果主要叢集具有此全域狀態，InnoDB 叢集集合部署會被賦予 UNAVAILABLE 狀態。

UNKNOWN

此叢集是 InnoDB 叢集集合部署的主要叢集，但 MySQL Shell 目前無法連線以判斷其狀態。由於無法連線到主要叢集，InnoDB 叢集集合部署會被賦予 UNAVAILABLE 狀態。

INVALIDATED

此叢集在容錯移轉過程中已失效。在受控的切換過程中，資料一致性會受到保證，且原始主要叢集會降級為可運作的唯讀複本叢集。但是，在緊急容錯移轉過程中，資料一致性無法得到保證，因此為了安全起見，原始主要叢集會在容錯移轉過程中被標示為失效。如果複本叢集在容錯移轉時或在受控切換期間無法連線或無法使用，也會被標示為失效。具有此全域狀態的叢集完全無法作為 InnoDB 叢集集合部署的一部分運作。此叢集不一定有任何技術問題，並且可能在人工驗證後重新加入 InnoDB 叢集集合部署。如果可以連線到此叢集，您應該驗證它是否已關閉，以免接受新的交易。

InnoDB 叢集回報的叢集狀態（status 欄位）可能是下列其中一種，主要叢集或複本叢集都可能回報這些狀態

OK

叢集中所有成員伺服器都處於 Group Replication 的 ONLINE 狀態，且叢集中有三個或更多成員。

OK_PARTIAL

叢集中至少有三個成員伺服器處於 Group Replication 的 ONLINE 狀態。但是，有一個或多個成員伺服器處於 Group Replication 的 OFFLINE、RECOVERING、ERROR 或 UNREACHABLE 狀態，因此它們目前沒有作為叢集的活動成員參與。處於這種情況下的叢集運作狀況良好，足以繼續作為 InnoDB 叢集集合部署的一部分，但要將其提升到 OK 狀態，請解決成員伺服器的問題。

OK_NO_TOLERANCE

叢集中所有成員伺服器都處於 Group Replication 的 ONLINE 狀態，但叢集中的成員少於三個，因此它沒有足夠的容錯能力。處於這種情況下的叢集運作狀況良好，足以繼續作為 InnoDB 叢集集合部署的一部分，但要將其提升到 OK 狀態，請新增更多成員伺服器。

OK_NO_TOLERANCE_PARTIAL

叢集中有一或兩個成員伺服器處於 Group Replication 的 ONLINE 狀態，但有一個或多個處於 Group Replication 的 OFFLINE、RECOVERING、ERROR 或 UNREACHABLE 狀態。因此，由於某些成員無法使用，此叢集沒有足夠的容錯能力。處於這種情況下的叢集運作狀況良好，足以繼續作為 InnoDB 叢集集合部署的一部分，但要將其提升到 OK 狀態，請解決成員伺服器的問題。

NO_QUORUM

叢集沒有仲裁，這表示複寫群組中大多數成員伺服器無法就決策達成一致。如果成員自願離開或被群組決策驅逐，Group Replication 可以將自己重新配置為新的群組編號，因此失去仲裁表示遺失的成員伺服器可能已失敗，或因網路分割而與其他伺服器斷開連線。處於這種情況下的叢集無法作為 InnoDB 叢集集合部署的一部分運作。若要將處於此狀態的叢集提升到 OK 狀態，請參閱第 8.9 節，「InnoDB 叢集集合修復和重新加入」。

OFFLINE

叢集中所有成員伺服器都處於 Group Replication 的 OFFLINE 狀態。處於這種情況下的叢集無法作為 InnoDB 叢集集合部署的一部分運作。如果叢集目前不應離線，若要將處於此狀態的叢集提升到 OK 狀態，請參閱第 8.9 節，「InnoDB 叢集集合修復和重新加入」。

ERROR

叢集中所有成員伺服器都處於 Group Replication 的 ERROR 狀態。處於這種情況下的叢集無法作為 InnoDB 叢集集合部署的一部分運作。若要將處於此狀態的叢集提升到 OK 狀態，請參閱第 8.9 節，「InnoDB 叢集集合修復和重新加入」。

UNKNOWN

MySQL Shell 目前無法連線到任何成員伺服器以判斷叢集的狀態。如果此為主要叢集，InnoDB 叢集集合部署會被賦予 UNAVAILABLE 狀態。

INVALIDATED

此叢集在容錯移轉過程中已失效。在受控的切換過程中，資料一致性會受到保證，且原始主要叢集會降級為可運作的唯讀複本叢集。但是，在緊急容錯移轉過程中，資料一致性無法得到保證，因此為了安全起見，原始主要叢集會在容錯移轉過程中被標示為失效。如果複本叢集在容錯移轉時或在受控切換期間無法連線或無法使用，也會被標示為失效。具有此全域狀態的叢集完全無法作為 InnoDB 叢集集合部署的一部分運作。此叢集不一定有任何技術問題，並且可能在人工驗證後重新加入 InnoDB 叢集集合部署。如果可以連線到此叢集，您應該驗證它是否已關閉，以免接受新的交易。若要處理這種情況，請參閱第 8.9 節，「InnoDB 叢集集合修復和重新加入」。

叢集狀態與 InnoDB 叢集作為 Group Replication 群組的技術問題有關，而非與複寫流程有關。對於複本叢集，叢集集合複寫狀態（clusterSetReplicationStatus 欄位）也會回報如下

OK

叢集集合複寫通道正在執行中。

STOPPED

叢集集合複寫通道已以受控方式停止。當接收器執行緒、應用程式執行緒或兩個執行緒都已停止時，會顯示此狀態。

CONNECTING

複寫通道正在連線。如果在連線期間發生錯誤，則會忽略該錯誤，直到通道狀態更新為 ON 或 OFF。

ERROR

由於複寫錯誤（例如，組態不正確或一組與主要叢集上的集合不同的交易），叢集集合複寫通道已停止。

MISCONFIGURED

偵測到叢集集合複寫通道的配置不正確，例如從錯誤的來源複寫。通道可能仍在執行，或複寫可能已停止。

MISSING

此叢集中的伺服器上不存在叢集集合複寫通道。

UNKNOWN

MySQL Shell 目前無法連線到複本叢集以判斷複寫通道的狀態。

如果叢集的唯一問題在於叢集集合複寫通道，則對叢集發出 clusterSet.rejoinCluster() 命令會在必要時自動更正通道的配置，並重新啟動通道。這可能足以修正問題。如需執行此操作的指示，請參閱第 8.9.5 節，「將叢集重新加入 InnoDB 叢集集合」。

InnoDB 叢集集合拓撲

如果您只想檢視 InnoDB 叢集集合的拓撲，而不需要狀態資訊，可以使用 clusterSet.describe() 函數。此函數會傳回一個 JSON 物件，描述 InnoDB 叢集集合部署的拓撲，並提供每個 InnoDB 叢集中每個成員伺服器的 IP 位址和識別碼。例如

mysql-js> myclusterset.describe()
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "topology": [
                {
                    "address": "127.0.0.1:3310",
                    "label": "127.0.0.1:3310"
                },
                {
                    "address": "127.0.0.1:3320",
                    "label": "127.0.0.1:3320"
                },
                {
                    "address": "127.0.0.1:3330",
                    "label": "127.0.0.1:3330"
                }
            ]
        },
        "clustertwo": {
            "clusterRole": "REPLICA",
            "topology": [
                {
                    "address": "127.0.0.1:4410",
                    "label": "127.0.0.1:4410"
                },
                {
                    "address": "127.0.0.1:4420",
                    "label": "127.0.0.1:4420"
                },
                {
                    "address": "127.0.0.1:4430",
                    "label": "127.0.0.1:4430"
                }
            ]
        }
    },
    "domainName": "testclusterset",
    "primaryCluster": "clusterone"
}

此資訊也會由 clusterSet.status() 函數的擴充輸出提供。

如需 clusterSet.setRoutingOption() 的相關資訊，請參閱第 6.10.4 節，「路由選項」。

InnoDB 叢集集合的 MySQL Router 狀態

若要查看為 InnoDB 叢集集合註冊的 MySQL Router 執行個體，請在連線到 InnoDB 叢集集合部署中的任何成員伺服器時，於 MySQL Shell 中發出 clusterSet.listRouters() 命令。此命令會傳回所有已註冊的 MySQL Router 執行個體的詳細資訊，或您使用其路由器執行個體定義指定的單一路由器執行個體。例如

mysql-js> myclusterset.listRouters()
{
    "domainName": "testclusterset",
    "routers": {
       "mymachine::Rome1": {
            "hostname": "mymachine",
            "lastCheckIn": 2021-10-15 11:58:37,
            "roPort": 6447,
            "roXPort": 6449,
            "rwPort": 6446,
            "rwXPort": 6448,
            "targetCluster": "primary",
            "version": "8.0.27"
        },
        "mymachine2::Rome2": {
            "hostname": "mymachine2",
            "lastCheckIn": 2021-10-15 11:58:37,
            "roPort": 6447,
            "roXPort": 6449,
            "rwPort": 6446,
            "rwXPort": 6448,
            "targetCluster": "primary",
            "version": "8.0.27"
        }
    }
}

執行個體資訊包括 MySQL Router 執行個體的名稱、使用 MySQL 傳統協定和 X Protocol 讀取和寫入流量的連接埠號碼、目標叢集，以及執行個體上次向目標叢集簽到的時間。如果 MySQL Router 的版本低於與此 InnoDB 叢集集合部署搭配使用所需版本，則執行個體資訊會說明這一點。

若要查看為每個 MySQL Router 執行個體設定的路由選項，以及 InnoDB 叢集集合部署的全域政策，請在連線到 InnoDB 叢集集合部署中的任何成員伺服器時，於 MySQL Shell 中發出 clusterSet.routingOptions()。特定 MySQL Router 執行個體的設定會覆寫全域政策。例如

mysql-js> myclusterset.routingOptions()
{
    "domainName": "testclusterset",
    "global": {
        "invalidated_cluster_policy": "drop_all",
        "target_cluster": "primary"
    },
    "routers": {
        "mymachine::Rome1":  {
            "target_cluster": "primary"
            "invalidated_cluster_policy": "accept_ro"
        },
        "mymachine2::Rome2": {}
    }
}

如果未顯示特定 MySQL Router 執行個體的特定路由選項，如上述 Rome2 的範例所示，則表示該執行個體未設定該政策，並且會遵循全域政策。 Rome1 的輸出顯示 "target_cluster": "primary"，這與全域政策相同。這是因為 Rome1 已由 clusterSet.setRoutingOption() 命令明確將路由選項設定為 "primary"，因此會顯示它。若要清除路由選項，請將其設定為 null。


上一頁   首頁   上一層   下一頁
下載本手冊
PDF (US Ltr) - 2.2Mb
PDF (A4) - 2.3Mb