MySQL Shell 8.4  /  MySQL InnoDB 叢集  /  監控 InnoDB 叢集

7.7 監控 InnoDB 叢集

本節說明如何使用 AdminAPI 監控 InnoDB 叢集。

使用 Cluster.describe()

若要取得關於 InnoDB 叢集本身結構的資訊,請使用 Cluster.describe() 函數

mysql-js> cluster.describe();
{
    "clusterName": "testCluster",
    "defaultReplicaSet": {
        "name": "default",
        "topology": [
            {
                "address": "ic-1:3306",
                "label": "ic-1:3306",
                "role": "HA"
            },
            {
                "address": "ic-2:3306",
                "label": "ic-2:3306",
                "role": "HA"
            },
            {
                "address": "ic-3:3306",
                "label": "ic-3:3306",
                "role": "HA"
            }
        ]
    }
}

此函數的輸出會顯示 InnoDB 叢集的結構,包括其所有組態資訊等等。位址、標籤和角色值與 使用 Cluster.status() 檢查叢集狀態 中所述的內容相符。

使用 Cluster.status() 檢查叢集狀態

叢集物件提供 status() 方法,讓您可以檢查叢集的執行情況。在您可以檢查 InnoDB 叢集的狀態之前,您需要連線至其任何實例,以取得 InnoDB 叢集物件的參考。不過,如果您想要變更叢集的組態,您必須連線至「R/W」實例。發出 status() 會根據您連線的伺服器實例所知的叢集檢視,擷取叢集的狀態,並輸出狀態報告。

重要事項

實例在叢集中的狀態會直接影響狀態報告中提供的資訊。因此,請確保您連線的實例具有 ONLINE 狀態。

若要取得關於 InnoDB 叢集執行情況的資訊,請使用叢集的 status() 方法

mysql-js> var cluster = dba.getCluster()
mysql-js> cluster.status()
{
    "clusterName": "testcluster",
    "defaultReplicaSet": {
        "name": "default",
        "primary": "ic-1:3306",
        "ssl": "REQUIRED",
        "status": "OK",
        "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
        "topology": {
            "ic-1:3306": {
                "address": "ic-1:3306",
                "memberRole": "PRIMARY",
                "mode": "R/W",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE"
                "version": "8.0.30"
            },
            "ic-2:3306": {
                "address": "ic-2:3306",
                "memberRole": "SECONDARY",
                "mode": "R/O",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE"
                "version": "8.0.30"
            },
            "ic-3:3306": {
                "address": "ic-3:3306",
                "memberRole": "SECONDARY",
                "mode": "R/O",
                "readReplicas": {},
                "replicationLag": "applier_queue_applied",
                "role": "HA",
                "status": "ONLINE"
                "version": "8.0.30"
            }
        }
        "topologyMode": "Single-Primary"
    },
    "groupInformationSourceMember": "mysql://icadmin@ic-1:3306"
}

Cluster.status() 的輸出會提供下列資訊

  • clusterName:在 dba.createCluster() 期間指派給此叢集的名稱。

  • defaultReplicaSet:屬於 InnoDB 叢集且包含資料集的伺服器實例。

  • primary:僅當叢集以單一主要模式運作時才會顯示。顯示目前主要實例的位址。如果未顯示此欄位,則叢集以多重主要模式運作。

  • ssl:叢集是否使用安全連線。根據 createCluster()addInstance() 期間如何設定 memberSslMode 選項,顯示 REQUIREDDISABLED 的值。此參數傳回的值對應至實例上 group_replication_ssl_mode 伺服器變數的值。請參閱 第 7.6 節「保護 InnoDB 叢集」

  • status:InnoDB 叢集的狀態。此狀態描述此叢集提供的高可用性。狀態為下列其中之一

    • OK:叢集處於線上狀態,最多可容許 n 個失敗。叢集中有三個或更多成員,且它們正在運作。

    • OK_PARTIAL:叢集處於線上狀態,最多可容許 n 個失敗。叢集中至少有三個成員伺服器處於群組複寫的線上狀態。不過,一個或多個成員伺服器目前並未以叢集的活動成員身分參與。

    • OK_NO_TOLERANCE:叢集無法容許任何失敗。

    • OK_NO_TOLERANCE_PARTIAL:叢集無法容許任何失敗。叢集中有一個或兩個成員伺服器處於線上狀態,但一個或多個伺服器處於離線、復原、錯誤或無法連線狀態。由於某些成員無法使用,因此叢集沒有足夠的容錯能力。

    • NO_QUORUM:叢集沒有仲裁,表示複寫群組的大多數成員伺服器無法用於同意決策,且無法處理寫入交易。

    • OFFLINE:群組的所有成員都處於離線狀態。

    • ERROR:叢集中沒有線上成員。

    • UNREACHABLE:無法連線至任何線上成員。

    • UNKNOWN:無法連線至任何線上成員。

    • FENCED_WRITES:叢集已隔離寫入流量。

  • topology:MySQL 伺服器實例的狀態。狀態為下列其中之一

    • 實例的主機名稱:實例的主機名稱,例如 "localhost:3310"

    • memberRole:群組複寫外掛程式回報的成員角色,請參閱 replication_group_members 資料表的 MEMBER_ROLE 欄。

    • mode:伺服器是讀寫 ("R/W") 還是唯讀 ("R/O")。這衍生自實例上 super_read_only 變數的目前狀態,以及叢集是否有仲裁。在先前版本中,模式的值衍生自實例是作為主要實例還是次要實例。通常,如果實例是主要實例,則模式為「R/W」,如果實例是次要實例,則模式為「R/O」。叢集中任何沒有可見仲裁的實例都會標示為「R/O」,無論 super_read_only 變數的狀態為何。

      注意

      如果成員 status 不是 ONLINE,則 mode 會回報為 n/a

    • replicationLag:傳回下列其中一個值

      • 上次交易認可時間戳記與上次套用交易時間戳記之間的時間差,格式為 HH:MM:SS。

        如果使用多個工作者,則會從執行最舊交易的工作者擷取值。

      • null:複寫連線或 SQL 執行緒未執行。

      • applier_queue_applied:應用程式佇列已套用所有內容。也就是說,如果最後一個已排隊交易和最後一個已套用交易相同,或套用交易為 0。

    • role:此實例在叢集中提供的功能。目前只有 HA,用於高可用性。

    • status:叢集這個元素的狀態。狀態為以下其中之一:

      • ONLINE:執行個體在線上並參與叢集。

      • OFFLINE:執行個體已失去與其他執行個體的連線。

      • RECOVERING:執行個體正嘗試與叢集同步,透過擷取成為線上成員前所需的交易。

      • UNREACHABLE:執行個體已失去與叢集的通訊。

      • ERROR:執行個體在復原階段或套用交易時遇到錯誤。

        重要事項

        一旦執行個體進入 ERROR 狀態,super_read_only 選項會設定為 ON。若要離開 ERROR 狀態,您必須手動將執行個體設定為 super_read_only=OFF

      • (MISSING):已設定的叢集中某執行個體的狀態,但該執行個體目前無法使用。

        注意

        MISSING 狀態是 InnoDB Cluster 特有的,並非 Group Replication 產生的狀態。MySQL Shell 使用此狀態來表示在 metadata 中已註冊,但在即時叢集檢視中找不到的執行個體。

    • groupInformationSourceMember:用於取得叢集相關資訊的內部連線,顯示為 URI 樣式的連線字串。通常是最初用於建立叢集的連線。

  • version:執行個體上執行的 MySQL Server 版本。如需詳細資訊,請參閱檢查執行個體上的 MySQL 版本

若要顯示更多關於叢集的資訊,請使用 extended 選項。extended 選項支援整數或布林值。若要設定 Cluster.status({'extended':value}) 提供的其他資訊,請使用以下值:

  • 0:停用額外資訊,為預設值。

  • 1:包含有關 Group Replication 通訊協定版本、群組名稱、通訊堆疊、叢集成員 UUID、Group Replication 回報的叢集成員角色和狀態,以及已隔離的系統變數清單的資訊。

  • 2:包含有關連線和應用程式處理的交易的資訊。

  • 3:包含每個叢集成員執行複寫的更詳細統計資料。

使用布林值設定 extended 等同於設定整數值 0 和 1。

當您發出 Cluster.status({'extended':1}) 或將 extended 選項設定為 true 時,輸出會包含

  • defaultReplicaSet 物件的下列其他屬性:

  • topology 物件的每個物件的下列其他屬性:

    • fenceSysVars:包含 AdminAPI 設定的已隔離系統變數名稱的清單。目前考量的已隔離系統變數為 read_onlysuper_read_onlyoffline_mode。無論系統變數的值為何,都會列出這些變數。

    • instanceErrors:針對每個執行個體,顯示可以偵測到的任何診斷資訊。例如,如果執行個體是次要的,且 super_read_only 變數未設定為 ON,則會顯示警告。此資訊可用於疑難排解錯誤。

    • memberId:每個叢集成員 UUID。

    • memberState:Group Replication 外掛程式回報的成員狀態,請參閱 replication_group_members 資料表的 MEMBER_STATE 資料行。

若要查看有關復原和一般交易 I/O、應用程式工作執行緒統計資料和任何延遲的資訊;如果啟用平行複寫應用程式,則會查看應用程式協調器統計資料;錯誤,以及來自接收器和應用程式執行緒的其他資訊,請將 extended 的值設定為 2 或 3。當您使用這些值時,系統會開啟與叢集中每個執行個體的連線,以便查詢其他執行個體特定的統計資料。輸出中包含的確切統計資料取決於執行個體的狀態和設定以及伺服器版本。此資訊與 replication_group_member_stats 資料表中顯示的資訊相符,如需詳細資訊,請參閱相符資料行的描述。ONLINE 的執行個體在輸出中包含 transactions 區段。RECOVERING 的執行個體在輸出中包含 recovery 區段。當您將 extended 設定為 2 時,無論哪種情況,這些區段都可能包含以下內容:

  • appliedCount:請參閱 COUNT_TRANSACTIONS_REMOTE_APPLIED

  • checkedCount:請參閱 COUNT_TRANSACTIONS_CHECKED

  • committedAllMembers:請參閱 TRANSACTIONS_COMMITTED_ALL_MEMBERS

  • conflictsDetectedCount:請參閱 COUNT_CONFLICTS_DETECTED

  • inApplierQueueCount:請參閱 COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE

  • inQueueCount:請參閱 COUNT_TRANSACTIONS_IN_QUEUE

  • lastConflictFree:請參閱 LAST_CONFLICT_FREE_TRANSACTION

  • proposedCount:請參閱 COUNT_TRANSACTIONS_LOCAL_PROPOSED

  • rollbackCount:請參閱 COUNT_TRANSACTIONS_LOCAL_ROLLBACK

當您將 extended 設定為 3 時,connection 區段會顯示來自 replication_connection_status 資料表的資訊。

currentlyQueueing 區段具有關於目前已排入佇列的交易的資訊。

  • immediateCommitTimestamp:請參閱 QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToNowTime:請參閱 QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMPNOW()

  • originalCommitTimestamp:請參閱 QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToNowTime:請參閱 QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMPNOW()

  • startTimestamp:請參閱 QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP

  • transaction:請參閱 QUEUEING_TRANSACTION

  • lastHeartbeatTimestamp:請參閱 LAST_HEARTBEAT_TIMESTAMP

lastQueued 區段具有關於最近已排入佇列的交易的資訊。

  • endTimestamp:請參閱 LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP

  • immediateCommitTimestamp:請參閱 LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToEndTimeLAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMPNOW()

  • originalCommitTimestamp:請參閱 LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToEndTimeLAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMPNOW()

  • queueTimeLAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMPLAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP

  • startTimestamp:請參閱 LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP

  • transaction:請參閱 LAST_QUEUED_TRANSACTION

  • receivedHeartbeats:請參閱 COUNT_RECEIVED_HEARTBEATS

  • receivedTransactionSet:請參閱 RECEIVED_TRANSACTION_SET

  • threadId:請參閱 THREAD_ID

使用多執行緒複寫的執行個體具有 workers 區段,其中包含關於工作執行緒的資訊,並與 replication_applier_status_by_worker 資料表顯示的資訊相符。

lastApplied 區段顯示關於工作者套用的最後一個交易的下列資訊:

  • applyTime:請參閱 LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMPLAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP

  • endTimestamp:請參閱 LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP

  • immediateCommitTimestamp:請參閱 LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToEndTime:請參閱 LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 減去 NOW() 的值

  • originalCommitTimestamp:請參閱 LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 的值

  • originalCommitToEndTime:請參閱 LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 減去 NOW() 的值

  • startTimestamp:請參閱 LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP 的值

  • transaction:請參閱 LAST_APPLIED_TRANSACTION 的值

currentlyApplying 區段顯示目前 Worker 正在套用的交易的下列資訊

  • immediateCommitTimestamp:請參閱 APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 的值

  • immediateCommitToNowTime:請參閱 APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 減去 NOW() 的值

  • originalCommitTimestamp:請參閱 APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 的值

  • originalCommitToNowTime:請參閱 APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 減去 NOW() 的值

  • startTimestamp:請參閱 APPLYING_TRANSACTION_START_APPLY_TIMESTAMP 的值

  • transaction:請參閱 APPLYING_TRANSACTION 的值

lastProcessed 區段包含 Worker 上次處理的交易的下列資訊

  • bufferTimeLAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP 減去 LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP 的值

  • endTimestamp:請參閱 LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP 的值

  • immediateCommitTimestamp:請參閱 LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 的值

  • immediateCommitToEndTimeLAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 減去 LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP 的值

  • originalCommitTimestamp:請參閱 LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 的值

  • originalCommitToEndTimeLAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 減去 LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP 的值

  • startTimestamp:請參閱 LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP 的值

  • transaction:請參閱 LAST_PROCESSED_TRANSACTION 的值

如果啟用了並行複寫套用程式,則 transactionsrecovery 中 workers 陣列中的物件數量,會與設定的 worker 數量相符,並且會包含一個額外的協調器物件。顯示的資訊與 replication_applier_status_by_coordinator 表格中的資訊相符。物件可能包含

currentlyProcessing 區段包含 Worker 目前正在處理的交易的下列資訊

  • immediateCommitTimestamp:請參閱 PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 的值

  • immediateCommitToNowTimePROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 減去 NOW() 的值

  • originalCommitTimestamp:請參閱 PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 的值

  • originalCommitToNowTimePROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 減去 NOW() 的值

  • startTimestamp:請參閱 PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP 的值

  • transaction:請參閱 PROCESSING_TRANSACTION 的值

worker 物件在 replication_applier_status_by_worker 表格中偵測到錯誤時,會包含下列資訊

  • lastErrno:請參閱 LAST_ERROR_NUMBER 的值

  • lastError:請參閱 LAST_ERROR_MESSAGE 的值

  • lastErrorTimestamp:請參閱 LAST_ERROR_TIMESTAMP 的值

connection 物件在 replication_connection_status 表格中偵測到錯誤時,會包含下列資訊

  • lastErrno:請參閱 LAST_ERROR_NUMBER 的值

  • lastError:請參閱 LAST_ERROR_MESSAGE 的值

  • lastErrorTimestamp:請參閱 LAST_ERROR_TIMESTAMP 的值

coordinator 物件在 replication_applier_status_by_coordinator 表格中偵測到錯誤時,會包含下列資訊

  • lastErrno:請參閱 LAST_ERROR_NUMBER 的值

  • lastError:請參閱 LAST_ERROR_MESSAGE 的值

  • lastErrorTimestamp:請參閱 LAST_ERROR_TIMESTAMP 的值

監控復原作業

Cluster.status() 的輸出會顯示處於 RECOVERING 狀態的執行個體復原作業的進度資訊。會顯示使用 MySQL Clone 或增量復原進行復原的執行個體資訊。監控下列欄位

  • recoveryStatusText 欄位包含有關使用之復原類型的資訊。當 MySQL Clone 正在運作時,此欄位會顯示 正在進行複製。當增量復原正在運作時,此欄位會顯示 正在進行分散式復原

  • 使用 MySQL Clone 時,recovery 欄位會包含具有下列欄位的字典

    • cloneStartTime:複製程序開始的時間戳記

    • cloneState:複製進度的狀態

    • currentStage:複製程序已到達的目前階段

    • currentStageProgress:目前階段的進度,以完成百分比表示

    • currentStageState:目前階段的狀態

    Cluster.status() 輸出範例,為簡潔起見已修剪

    ...
    "recovery": {
    "cloneStartTime": "2019-07-15 12:50:22.730",
    "cloneState": "In Progress",
    "currentStage": "FILE COPY",
    "currentStageProgress": 61.726837675213865,
    "currentStageState": "In Progress"
    },
    "recoveryStatusText": "Cloning in progress",
    ...
  • 使用增量復原且 extended 選項設為 1 或更大時,recovery 欄位會包含具有下列欄位的字典

    • stategroup_replication_recovery 通道的狀態

    • recoveryChannel:針對執行增量復原的執行個體或復原通道狀態未關閉的執行個體顯示。增量復原會利用接收器執行緒接收來自來源的交易,而套用程式執行緒則會在執行個體上套用接收到的交易。提供下列資訊

      • applierQueuedTransactionSetSize:目前已排入佇列且正在等待套用的交易數量。

      • applierState:複寫套用程式的目前狀態,為 ONOFF

      • applierStatus:套用程式執行緒的目前狀態。這是 applierThreadState 欄位中顯示的狀態彙總。可以是下列其中一項

        • APPLIED_ALL:沒有已排入佇列等待套用的交易

        • APPLYING:有交易正在套用

        • ON:執行緒已連線且沒有已排入佇列的交易

        • ERROR:套用交易時發生錯誤

        • OFF:套用程式執行緒已停用

      • applierThreadState:任何套用程式執行緒的目前狀態。提供有關套用程式執行緒實際在做什麼的詳細資訊。如需更多資訊,請參閱 複寫 SQL 執行緒狀態

      • receiverStatus:接收器執行緒的目前狀態。這是 receiverThreadState 欄位中顯示的狀態彙總。可以是下列其中一項

        • ON:接收器執行緒已成功連線並準備好接收

        • CONNECTING:接收器執行緒正在連線至來源

        • ERROR:接收交易時發生錯誤

        • OFF:接收器執行緒已正常中斷連線

      • receiverThreadState:接收器執行緒的目前狀態。提供有關接收器執行緒實際在做什麼的詳細資訊。如需更多資訊,請參閱 複寫 I/O (接收器) 執行緒狀態

      • source:正在套用之交易的來源。

    Cluster.status() 輸出範例,為簡潔起見已修剪

    ...
    "recovery": {
                        "recoveryChannel": {
                            "applierQueuedTransactionSetSize": 2284, 
                            "applierStatus": "APPLYING", 
                            "applierThreadState": "Opening tables", 
                            "receiverStatus": "ON", 
                            "receiverThreadState": "Queueing master event to the relay log", 
                            "source": "ic-2:3306"
                        }, 
                        "state": "ON"
                    },
    ...

InnoDB Cluster 和群組複寫協定

群組複寫具有群組通訊協定的概念,如需更多資訊,請參閱 設定群組的通訊協定版本。群組複寫通訊協定版本通常必須明確管理,並設定為符合您要讓群組支援的最舊 MySQL Server 版本。不過,每當使用 AdminAPI 作業變更叢集拓撲時,InnoDB Cluster 會自動且透明地管理其成員的通訊協定版本。叢集一律會使用目前叢集或加入叢集的所有執行個體支援的最新通訊協定版本。

  • 當執行個體加入、從叢集中移除或重新加入叢集,或對叢集執行重新掃描或重新啟動作業時,通訊協定版本會自動設定為由現在處於最早 MySQL Server 版本的執行個體所支援的版本。

  • 當您藉由從叢集中移除執行個體、升級這些執行個體,並將它們加回叢集來執行滾動升級時,當舊 MySQL Server 版本中剩餘的最後一個執行個體從叢集中移除以進行升級時,通訊協定版本會自動升級。

若要查看叢集中使用的通訊協定版本,請使用啟用 extended 選項的 Cluster.status() 函數。通訊協定版本會在 GRProtocolVersion 欄位中傳回,前提是叢集具有仲裁且沒有任何叢集成員無法連線。

檢查執行個體上的 MySQL 版本

下列作業可以報告執行個體上執行的 MySQL Server 版本相關資訊

  • Cluster.status()

  • Cluster.describe()

  • Cluster.rescan()

行為會根據 Cluster 物件工作階段的 MySQL Server 版本而有所不同。

  • Cluster.status()

    如果符合下列其中一個需求,則會針對 topology 物件的每個執行個體 JSON 物件傳回 version 字串屬性

    • Cluster 物件的目前工作階段是 8.0.11 或更新版本。

    • Cluster 物件的目前工作階段執行的是 8.0.11 之前的版本,但 extended 選項已設為 3。

    例如,在執行 8.0.16 版本的執行個體上

    "topology": {
        "ic-1:3306": {
            "address": "ic-1:3306",
            "mode": "R/W",
            "readReplicas": {},
            "role": "HA",
            "status": "ONLINE",
            "version": "8.0.16"
    }
  • Cluster.describe()

    如果 Cluster 物件的目前工作階段是 8.0.11 或更新版本,則會針對 topology 物件的每個執行個體 JSON 物件傳回 version 字串屬性

    例如,在執行 8.0.16 版本的執行個體上

    "topology": [
        {
            "address": "ic-1:3306",
            "label": "ic-1:3306",
            "role": "HA",
            "version": "8.0.16"
        }
    ]
  • Cluster.rescan()

    如果 Cluster 物件的目前工作階段是 8.0.11 或更新版本,且 Cluster.rescan() 作業偵測到不屬於叢集的執行個體,則會針對 newlyDiscoveredInstance 物件的每個執行個體 JSON 物件傳回 version 字串屬性。

    例如,在執行 8.0.16 版本的執行個體上

    "newlyDiscoveredInstances": [
        {
            "host": "ic-4:3306",
            "member_id": "82a67a06-2ba3-11e9-8cfc-3c6aa7197deb",
            "name": null,
            "version": "8.0.16"
        }
    ]