MySQL Shell 9.0  /  MySQL InnoDB ClusterSet  /  InnoDB ClusterSet 狀態與拓撲

8.6 InnoDB ClusterSet 狀態與拓撲

本節說明下列內容

InnoDB ClusterSet 狀態

AdminAPI 的 clusterSet.status() 命令會傳回一個 JSON 物件，描述 InnoDB ClusterSet 部署的狀態。輸出包含 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 Cluster 管理員帳戶是適當的。對於初始叢集部署程序，InnoDB Cluster 伺服器組態帳戶是適當的。如需詳細資訊，請參閱第 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 Cluster 中每個成員伺服器的狀態。輸出包含成員的 Group Replication 狀態（memberState 欄位），以及複本叢集中伺服器的複寫狀態。有關 Group Replication 狀態的資訊，請參閱Group Replication 伺服器狀態。

針對 InnoDB Cluster 回報的全域狀態（globalStatus 欄位）可以是下列其中之一

OK

叢集在 InnoDB ClusterSet 部署中正常運作。叢集中至少有一個成員伺服器處於 Group Replication 的 ONLINE 狀態，且複寫群組具有法定人數。如果叢集是複本叢集，則 ClusterSet 複寫狀態也為 OK。此全域狀態不一定表示叢集沒有技術問題。某些成員可能處於離線狀態，或者叢集可能沒有足夠的成員來提供容錯能力。然而，叢集運作良好，足以繼續作為 InnoDB ClusterSet 部署的一部分。主叢集或複本叢集都可能具有此全域狀態。

OK_NOT_REPLICATING

叢集運作正常，但 ClusterSet 複寫通道上的複寫已停止，原因可能是受控停止或複寫錯誤。只有複本叢集才可能具有此全域狀態。

OK_NOT_CONSISTENT

叢集運作正常，但叢集上的交易集（GTID 集）已與主叢集上的交易集發散，導致複本叢集上有多餘的主叢集沒有的交易。複寫可能已在 ClusterSet 複寫通道上停止，原因可能是受控停止或複寫錯誤，或者通道可能仍在複寫。只有複本叢集才可能具有此全域狀態。具有此狀態的複本叢集無法用於計劃的切換，但可以強制容錯移轉。

OK_MISCONFIGURED

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

NOT_OK

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

UNKNOWN

叢集是 InnoDB ClusterSet 部署的主叢集，但 MySQL Shell 目前無法聯絡它以判斷其狀態。在無法聯絡主叢集時，InnoDB ClusterSet 部署會被賦予 UNAVAILABLE 狀態。

INVALIDATED

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

針對 InnoDB Cluster 回報的叢集狀態（status 欄位）可以是下列其中之一，所有狀態都可能針對主叢集或複本叢集回報

OK

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

OK_PARTIAL

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

OK_NO_TOLERANCE

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

OK_NO_TOLERANCE_PARTIAL

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

NO_QUORUM

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

OFFLINE

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

ERROR

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

UNKNOWN

MySQL Shell 目前無法聯絡任何成員伺服器以判斷叢集的狀態。如果這是主叢集，則 InnoDB ClusterSet 部署會被賦予 UNAVAILABLE 狀態。

INVALIDATED

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

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

OK

ClusterSet 複寫通道正在執行中。

STOPPED

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

CONNECTING

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

ERROR

ClusterSet 複寫通道因複寫錯誤而停止，例如組態不正確或與主叢集上的交易集不同的交易集。

MISCONFIGURED

偵測到 ClusterSet 複寫通道的組態不正確，例如從錯誤的來源複寫。通道可能仍在執行，或者複寫可能已停止。

MISSING

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

UNKNOWN

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

如果叢集唯一的問題是 ClusterSet 複寫通道，對該叢集發出 clusterSet.rejoinCluster() 指令，會在必要時自動修正通道的設定並重新啟動通道。這可能足以解決問題。有關如何執行此操作的說明，請參閱第 8.9.5 節，「將叢集重新加入 InnoDB ClusterSet」。

InnoDB ClusterSet 拓撲

如果您只想檢視 InnoDB ClusterSet 的拓撲，而不需要狀態資訊，可以使用 clusterSet.describe() 函式。此函式會傳回一個 JSON 物件，描述 InnoDB ClusterSet 部署的拓撲，並提供每個 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 ClusterSet 的 MySQL Router 狀態

若要查看為 InnoDB ClusterSet 註冊的 MySQL Router 執行個體，請在連線至 InnoDB ClusterSet 部署中任何成員伺服器時，於 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 協定進行讀取和寫入流量的連接埠號碼、目標叢集，以及執行個體上次與目標叢集簽入的時間。如果 MySQL Router 的版本低於與此 InnoDB ClusterSet 部署搭配運作所需的版本，執行個體資訊會說明這一點。

若要查看為每個 MySQL Router 執行個體設定的路由選項，以及 InnoDB ClusterSet 部署的整體政策，請在連線至 InnoDB ClusterSet 部署中任何成員伺服器時，於 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 (美式信紙) - 2.3Mb
PDF (A4) - 2.3Mb