このページは機械翻訳したものです。
このセクションでは、AdminAPI を使用して InnoDB クラスタ を監視する方法について説明します。
          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()
          クラスタオブジェクトには、クラスタの実行方法を確認できる 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",
                "mode": "R/W",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            },
            "ic-2:3306": {
                "address": "ic-2:3306",
                "mode": "R/O",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            },
            "ic-3:3306": {
                "address": "ic-3:3306",
                "mode": "R/O",
                "readReplicas": {},
                "role": "HA",
                "status": "ONLINE"
            }
        }
    },
    "groupInformationSourceMember": "mysql://icadmin@ic-1:3306"
}
           の出力には、次の情報が表示されます:
        Cluster.status()
clusterName:dba.createCluster()中にこのクラスタに割り当てられた名前。defaultReplicaSet: InnoDB クラスタ に属し、データセットを含むサーバーインスタンス。primary: クラスタがシングルプライマリモードで動作している場合にのみ表示されます。 現在のプライマリインスタンスのアドレスを表示します。 このフィールドが表示されない場合、クラスタはマルチプライマリモードで動作しています。ssl: セキュアな接続がクラスタで使用されているかどうか。createCluster()またはaddInstance()中にmemberSslModeオプションがどのように構成されたかに応じて、REQUIREDまたはDISABLEDの値が表示されます。 このパラメータによって返される値は、インスタンス上のgroup_replication_ssl_modeサーバー変数の値に対応します。 クラスタの保護を参照してください。- 
status: クラスタのこの要素のステータス。 クラスタ全体について、このクラスタによって提供される高可用性について説明します。 ステータスは次のいずれかです:ONLINE: インスタンスはオンラインで、クラスタに参加しています。OFFLINE: インスタンスは他のインスタンスへの接続を失いました。RECOVERING: インスタンスは、ONLINEメンバーになる前に必要なトランザクションを取得して、クラスタと同期しようとしています。UNREACHABLE: インスタンスはクラスタとの通信を失いました。- 
ERROR: リカバリフェーズ中またはトランザクションの適用中にインスタンスでエラーが発生しました。重要インスタンスが
ERROR状態になると、super_read_onlyオプションはONに設定されます。ERRORの状態のままにするには、super_read_only=OFFを使用してインスタンスを手動で構成する必要があります。 - 
(MISSING): 構成済クラスタの一部であるが、現在使用できないインスタンスの状態。注記MISSINGの状態は InnoDB クラスタ に固有であり、Group Replication によって生成される状態ではありません。MySQL Shell はこの状態を使用して、メタデータに登録されているが、ライブクラスタビューに見つからないインスタンスを示します。 
 topology: クラスタに追加されたインスタンス。Host name of instance: インスタンスのホスト名 (localhost:3310 など)。role: このインスタンスがクラスタ内で提供する機能。 現在は HA のみで、高可用性を実現しています。mode: サーバーが読取り/書込み ("R/W") か読取り専用 ("R/O") か。 バージョン 8.0.17 から、これはインスタンス上のsuper_read_only変数の現在の状態、およびクラスタにクォーラムがあるかどうかから導出されます。 以前のバージョンでは、mode の値は、インスタンスがプライマリインスタンスとして機能していたかセカンダリインスタンスとして機能していたかから導出されていました。 通常、インスタンスがプライマリの場合、モードは R/W で、インスタンスがセカンダリの場合、モードは R/O です。 表示可能なクォーラムがないクラスタ内のインスタンスは、super_read_only変数の状態に関係なく、R/O としてマークされます。groupInformationSourceMember: URI のような接続文字列として表示される、クラスタに関する情報の取得に使用される内部接続。 通常は、クラスタの作成に最初に使用される接続です。
          クラスタの詳細を表示するには、extended オプションを使用します。 バージョン 8.0.17 からは、extended オプションで整数またはブール値がサポートされます。  が提供する追加情報を構成するには、次の値を使用:  
        Cluster.status({'extended':value})
0: 追加情報を無効にします (デフォルト)
1: には、Group Replication Protocol Version、Group name、クラスタメンバー UUID、クラスタメンバー役割よび Group Replication によって報告される状態、およびフェンシングされたシステム変数のリストに関する情報が含まれています
2: 接続および適用者によって処理されたトランザクションに関する情報が含まれます
3: には、各クラスタメンバーによって実行されるレプリケーションに関するより詳細な統計が含まれます。
          ブール値を使用して extended を設定することは、整数値 0 および 1 を設定することと同等です。 8.0.17 より前のバージョンでは、extended オプションはブールのみでした。 同様に、以前のバージョンでは、queryMembers ブールオプションを使用して、クラスタ内のインスタンスの詳細情報を提供していました。これは、extended を 3 に設定することと同等です。 queryMembers オプションは非推奨であり、将来のリリースで削除される予定です。 
        
           を発行するか、Cluster.status({'extended':1})extended オプションが true に設定されている場合、出力には次のものが含まれます:
        
- 
defaultReplicaSetオブジェクトの次の追加属性:- 
GRProtocolVersionは、クラスタで使用されるグループレプリケーションプロトコルバージョンです。ヒントInnoDB クラスタ は、自動的に使用される Group Replication Protocol のバージョンを管理します。詳細は、InnoDB クラスタ およびグループのレプリケーションプロトコル を参照してください。
 groupNameはグループ名 (UUID) です。
 - 
 - 
topologyオブジェクトの各オブジェクトについて、次の追加属性:fenceSysVarsは、AdminAPI によって構成されたフェンシングされたシステム変数の名前を含むリストです。 現在考慮されるフェンシングされたシステム変数は、read_only、super_read_onlyおよびoffline_modeです。 システム変数は、その値に関係なくリストされます。インスタンスごとの
instanceErrors。インスタンスで検出可能な診断情報が表示されます。 たとえば、インスタンスがセカンダリで、super_read_only変数がONに設定されていない場合、警告が表示されます。 この情報は、エラーのトラブルシューティングに使用できます。memberId各クラスタメンバー UUID。Group Replication プラグインによって報告されたメンバーロールを
memberRoleします。replication_group_membersテーブルのMEMBER_ROLEカラムを参照してください。Group Replication プラグインによって報告されたメンバー状態を
memberStateします。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 テーブルの情報が表示されます。 値 3 は、非推奨の queryMembers オプションを true に設定することと同等です。 connection セクションには、次のものを含めることができます: 
        
          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_TIMESTAMPstartTimestamp: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 セクションには、ワーカーによって現在適用されているトランザクションに関する次の情報が表示されます:
        
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 セクションには、ワーカーが最後に処理したトランザクションに関する次の情報が表示されます:
        
bufferTime:LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMPマイナスLAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMPendTimestamp: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_TIMESTAMPoriginalCommitTimestamp:LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMPを参照originalCommitToEndTime:LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMPマイナスLAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMPstartTimestamp:LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMPを参照transaction:LAST_PROCESSED_TRANSACTIONを参照
          パラレルレプリケーションアプライヤが有効になっている場合は、transactions または recovery の workers 配列内のオブジェクト数が構成済ワーカー数と一致し、追加のコーディネータオブジェクトが含まれます。 表示される情報は、replication_applier_status_by_coordinator テーブルの情報と一致します。 オブジェクトには、次のものを含めることができます: 
        
          currentlyProcessing セクションには、ワーカーが処理しているトランザクションに関する次の情報が表示されます:
        
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 クローンまたは増分リカバリのいずれかを使用してリカバリするインスタンスの情報が表示されます。 次のフィールドをモニターします: 
        
recoveryStatusTextフィールドには、使用されているリカバリのタイプに関する情報が含まれます。 MySQL クローンが機能している場合、このフィールドには「「クローニング進行中」」と表示されます。 増分リカバリが機能している場合、このフィールドには「「分散リカバリの進行中」」と表示されます。- 
MySQL クローンが使用されている場合、
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" }, ... 
MySQL 8.0.16 から、グループレプリケーションにはグループの通信プロトコルの概念があります。バックグラウンド情報は、グループ通信プロトコルバージョンの設定 を参照してください。 Group Replication 通信プロトコルのバージョンは通常、明示的に管理する必要があり、グループでサポートする最も古い MySQL Server バージョンに対応するように設定する必要があります。 ただし、クラスタトポロジが AdminAPI 操作を使用して変更されるたびに、InnoDB クラスタ はそのメンバーの通信プロトコルバージョンを自動的かつ透過的に管理します。 クラスタでは、現在クラスタの一部であるか参加しているすべてのインスタンスでサポートされている最新の通信プロトコルバージョンが常に使用されます。
クラスタに対してインスタンスが追加、削除または再結合されたり、再スキャンまたは再起動操作が実行されると、通信プロトコルバージョンは、現在最も古い MySQL Server バージョンであるインスタンスでサポートされているバージョンに自動的に設定されます。
クラスタからインスタンスを削除してローリングアップグレードを実行し、それらをアップグレードしてクラスタに再度追加すると、古い MySQL Server バージョンの残りのインスタンスがアップグレード前にクラスタから削除されたときに、通信プロトコルバージョンが自動的にアップグレードされます。
          クラスタで使用されている通信プロトコルのバージョンを確認するには、extended オプションを有効にして  関数を使用します。 クラスタにクォーラムがあり、アクセスできないクラスタメンバーがない場合、通信プロトコルバージョンが Cluster.status()GRProtocolVersion フィールドに返されます。 
        
次の操作では、インスタンスで実行されている 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 に設定されています (または、非推奨のqueryMembersがtrueです)。
たとえば、バージョン 8.0.16 を実行しているインスタンスでは、次のようになります:
"topology": { "ic-1:3306": { "address": "ic-1:3306", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE", "version": "8.0.16" }たとえば、バージョン 5.7.24 を実行しているインスタンスでは、次のようになります:
"topology": { "ic-1:3306": { "address": "ic-1:3306", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE", "version": "5.7.24" } - 
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" } ]