文件首頁
MySQL Shell 9.0
下載本手冊
PDF (美國信紙尺寸) - 2.3Mb
PDF (A4) - 2.3Mb
MySQL Shell 9.0  /  MySQL InnoDB Cluster  /  監控 InnoDB Cluster

7.7 監控 InnoDB Cluster

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

使用 Cluster.describe()

若要取得 InnoDB Cluster 本身結構的相關資訊，請使用 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 的結構，包括其所有配置資訊等等。位址、標籤和角色值與使用 Cluster.status() 檢查叢集狀態中所述的相符。

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

叢集物件提供 status() 方法，可讓您檢查叢集的執行狀況。在您可以檢查 InnoDB Cluster 的狀態之前，您需要連線到其任何執行個體來取得 InnoDB Cluster 物件的參考。但是，如果您想要變更叢集的配置，您必須連線到「R/W」執行個體。發出 status() 會根據您連線的伺服器執行個體所知的叢集檢視來擷取叢集的狀態，並輸出狀態報告。

重要事項

執行個體在叢集中的狀態會直接影響狀態報告中提供的資訊。因此，請確保您連線的執行個體狀態為 ONLINE。

若要了解 InnoDB Cluster 的執行狀況，請使用叢集的 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 Cluster 並包含資料集的伺服器執行個體。

  • primary：僅當叢集以單一主要模式運作時才會顯示。顯示目前主要執行個體的位址。如果未顯示此欄位，則叢集以多重主要模式運作。

  • ssl：叢集是否使用安全連線。根據在 createCluster() 或 addInstance() 期間如何設定 memberSslMode 選項，顯示 REQUIRED 或 DISABLED 的值。此參數傳回的值對應至執行個體上 group_replication_ssl_mode 伺服器變數的值。請參閱第 7.6 節「保護 InnoDB Cluster 的安全」。

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

    • OK：叢集已上線，且可容許最多 n 個失敗。叢集中有三個或更多成員，且它們正常運作。

    • OK_PARTIAL：叢集已上線，且可容許最多 n 個失敗。叢集中至少有三個成員伺服器處於群組複寫的線上狀態。但是，一或多個成員伺服器目前未以叢集的活躍成員身分參與。

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

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

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

    • OFFLINE：群組的所有成員都已離線。

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

    • UNREACHABLE：無法連線到任何線上成員。

    • UNKNOWN：無法連線到任何線上成員。

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

  • topology：MySQL Server 執行個體的狀態。此狀態為下列其中之一

    • 執行個體的主機名稱：執行個體的主機名稱，例如 "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：表示 applier 佇列已套用所有內容。也就是說，如果最後一個加入佇列的交易和最後一個套用的交易相同，或是正在套用的交易為 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 使用此狀態來表示在元數據中註冊，但在即時叢集檢視中找不到的執行個體。

    • groupInformationSourceMember：用於取得叢集相關資訊的內部連線，顯示為類似 URI 的連線字串。通常是最初用於建立叢集的連線。

  • version：執行個體上執行的 MySQL 伺服器版本。如需詳細資訊，請參閱檢查執行個體上的 MySQL 版本。

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

  • 0：停用其他資訊，預設值。

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

  • 2：包含有關連線和 applier 處理的交易資訊。

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

使用布林值設定 extended 相當於設定整數值 0 和 1。

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

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

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

    • fenceSysVars：包含 AdminAPI 設定的受限系統變數名稱的清單。目前考慮的受限系統變數為 read_only、super_read_only 和 offline_mode。無論系統變數的值為何，都會列出。

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

    • memberId：每個叢集成員 UUID。

    • memberState：Group Replication 外掛程式回報的成員狀態，請參閱 replication_group_members 資料表的 MEMBER_STATE 欄位。

若要查看有關復原和常規交易 I/O、applier 工作執行緒統計資料和任何延遲的資訊；如果啟用平行複寫 applier，則查看 applier 協調器統計資料；以及來自接收器和 applier 執行緒的錯誤和其他資訊，請將 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_TIMESTAMP 減去 NOW()

  • originalCommitTimestamp：請參閱 QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToNowTime：請參閱 QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 減去 NOW()

  • 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

  • immediateCommitToEndTime：LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 減去 NOW()

  • originalCommitTimestamp：請參閱 LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToEndTime：LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 減去 NOW()

  • queueTime：LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP 減去 LAST_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_TIMESTAMP 減去 LAST_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 處理的最後一個交易的下列資訊。

  • bufferTime：LAST_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

  • immediateCommitToEndTime：LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 減去 LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP

  • originalCommitTimestamp：請參閱 LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToEndTime：LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 減去 LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP

  • startTimestamp：請參閱 LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP

  • transaction：請參閱 LAST_PROCESSED_TRANSACTION

如果啟用並行複寫應用程式，則 transactions 或 recovery 中 workers 陣列中的物件數量，會與設定的 workers 數量相符，並且包含額外的協調器物件。顯示的資訊會與 replication_applier_status_by_coordinator 表格中的資訊相符。物件可以包含

currentlyProcessing 區段包含有關 worker 正在處理的交易的下列資訊。

  • immediateCommitTimestamp：請參閱 PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

  • immediateCommitToNowTime：PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP 減去 NOW()

  • originalCommitTimestamp：請參閱 PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

  • originalCommitToNowTime：PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 減去 NOW()

  • startTimestamp：請參閱 PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP

  • transaction：請參閱 PROCESSING_TRANSACTION

如果在 replication_applier_status_by_worker 表格中偵測到錯誤，則 worker 物件具有下列資訊。

  • lastErrno：請參閱 LAST_ERROR_NUMBER

  • lastError：請參閱 LAST_ERROR_MESSAGE

  • lastErrorTimestamp：請參閱 LAST_ERROR_TIMESTAMP

如果在 replication_connection_status 表格中偵測到錯誤，則 connection 物件具有下列資訊。

  • lastErrno：請參閱 LAST_ERROR_NUMBER

  • lastError：請參閱 LAST_ERROR_MESSAGE

  • lastErrorTimestamp：請參閱 LAST_ERROR_TIMESTAMP

如果在 replication_applier_status_by_coordinator 表格中偵測到錯誤，則 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 欄位包含具有下列欄位的字典

    • state：group_replication_recovery 通道的狀態

    • recoveryChannel：針對執行增量復原的執行個體或復原通道狀態未關閉的執行個體顯示。增量復原利用接收器執行緒從來源接收交易，而應用程式執行緒則將接收到的交易套用至執行個體。提供下列資訊

      • applierQueuedTransactionSetSize：目前在佇列中等待套用的交易數量。

      • applierState：複寫應用程式的目前狀態，可以是 ON 或 OFF。

      • 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"
    }
]

上一步   首頁   上一層   下一步
下載本手冊
PDF (美國信紙尺寸) - 2.3Mb
PDF (A4) - 2.3Mb