Spec-Zone.ru › MySQL Shell 9.2

8.7 Мониторинг кластера InnoDB

В этом разделе описывается, как использовать AdminAPI для мониторинга кластера InnoDB.

  • Cluster.describe()">Использование Cluster.describe()

  • Проверка состояния кластера с помощью Cluster.status()

  • Мониторинг операций восстановления

  • Кластер InnoDB и протокол Group Replication

  • Проверка версии MySQL на узлах

Использование 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 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: используются ли для кластера защищенные соединения. Показывается значения REQUIRED или DISABLED, в зависимости от того, как был настроен параметр memberSslMode при createCluster() или addInstance(). Возвращаемое значение этого параметра соответствует значению переменной сервера в экземпляре. См. Раздел 8.6, «Защита InnoDB Cluster».

  • status: Статус InnoDB Cluster. Статус описывает обеспечиваемую этим кластером высокодоступность. Статус может быть одним из следующих:

    • OK: Кластер онлайн и может выдержать до n отказов. В кластере три или более участников, и они функционируют.

    • OK_PARTIAL: Кластер онлайн и может выдержать до n отказов. Как минимум, три сервера-участника в кластере находятся в онлайн-состоянии Group Replication. Однако один или несколько серверов-участников в данный момент не участвуют в качестве активных участников кластера.

    • OK_NO_TOLERANCE: Кластер не устойчив к отказам.

    • OK_NO_TOLERANCE_PARTIAL: Кластер не устойчив к отказам. Один или два сервера-участника в кластере онлайн, но один или несколько серверов находятся в режиме оффлайн, восстановления, ошибки или недоступности. Кластер не обладает достаточной устойчивостью к отказам из-за недоступности некоторых участников.

    • NO_QUORUM: Кластер не имеет кворума, что означает, что большинство серверов-участников группы репликации недоступны для согласования решения и не могут обрабатывать транзакции записи.

    • OFFLINE: Все участники группы оффлайн.

    • ERROR: В кластере нет онлайн-участников.

    • UNREACHABLE: Нет подключения к онлайн-участникам.

    • UNKNOWN: Нет подключения к онлайн-участникам.

    • FENCED_WRITES: Кластер изолирован от трафика записи.

  • topology: Статус экземпляра MySQL Server. Статус может быть одним из следующих:

    • Host name of instance: имя хоста экземпляра, например "localhost:3310".

    • memberRole роль участника, как сообщает плагин Group Replication, см. столбец MEMBER_ROLE таблицы.

    • mode: является ли сервер чтением-записью ("R/W") или только чтением ("R/O"). Это выводится из текущего состояния переменной в экземпляре и наличия кворума в кластере. В предыдущих версиях значение режима выводилось из того, выступал ли экземпляр в качестве первичного или вторичного экземпляра. Обычно, если экземпляр является первичным, режим равен "R/W", а если экземпляр является вторичным, режим равен "R/O". Все экземпляры в кластере, не имеющие видимого кворума, помечаются как "R/O", независимо от состояния переменной.

      Примечание

      Если член status отличается от ONLINE, mode сообщается как n/a.

    • replicationLag: возвращает одно из следующих значений:

      • Разница во времени между последней датой завершения транзакции и последней применённой датой транзакции в формате ЧЧ:ММ:СС.

        Если используются несколько рабочих процессов, значение извлекается из рабочего процесса, выполняющего самую старую транзакцию.

      • null: подключение к репликации или SQL-поток не работает.

      • applier_queue_applied: очередь применения применила все. То есть, если последняя транзакция в очереди и последняя примененная транзакция одинаковы, или транзакция применения равна 0.

    • role: какая функция выполняется этим экземпляром в кластере. В настоящее время только HA для обеспечения высокой доступности.

    • status: Статус этого элемента кластера. Статус может быть одним из следующих:

      • ONLINE: экземпляр онлайн и участвует в кластере.

      • OFFLINE: экземпляр потерял соединение с другими экземплярами.

      • RECOVERING: экземпляр пытается синхронизироваться с кластером, извлекая транзакции, необходимые ему перед тем, как он сможет стать онлайн-участником.

      • UNREACHABLE: экземпляр потерял связь с кластером.

      • ERROR: экземпляр столкнулся с ошибкой во время фазы восстановления или при применении транзакции.

        Важно

        После того, как экземпляр переходит в состояние ERROR, параметр устанавливается в значение ON. Чтобы выйти из состояния ERROR, необходимо вручную настроить экземпляр с .

      • (MISSING): состояние экземпляра, который входит в конфигурированный кластер, но в настоящее время недоступен.

        Примечание

        Состояние MISSING специфично для InnoDB Cluster, это не состояние, генерируемое Group Replication. MySQL Shell использует это состояние для указания экземпляров, которые зарегистрированы в метаданных, но не могут быть найдены в живом представлении кластера.

    • 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:

    • GRProtocolVersion: версия протокола групповой репликации, используемая в кластере.

      Подсказка

      InnoDB Cluster автоматически управляет используемой версией протокола групповой репликации, см. InnoDB Cluster и протокол групповой репликации для получения дополнительной информации.

    • communicationStack: используемый кластером стек коммуникаций. Возможные значения: XCOM или MYSQL. См. Раздел 8.5.9, «Настройка стека коммуникаций групповой репликации» для получения дополнительной информации.

    • groupName: имя группы, UUID.

    • groupViewChangeUuid: значение .

    • groupViewId: текущий идентификатор представления для этой группы. Это значение берется из столбца VIEW_ID таблицы .

    • paxosSingleLeader: отображает значение .

      Примечание

      Это доступно только в MySQL Server 8.0.31 и выше, поскольку MySQL Shell требует информации, предоставляемой WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE в таблице , которая была введена в MySQL 8.0.31.

  • следующие дополнительные атрибуты для каждого объекта объекта topology:

    • fenceSysVars список, содержащий имена изолированных системных переменных, которые настроены AdminAPI. В настоящее время рассматриваются изолированные системные переменные , и . Системные переменные перечислены независимо от их значения.

    • instanceErrors для каждого экземпляра, отображающая любую диагностическую информацию, которая может быть обнаружена для экземпляра. Например, если экземпляр является вторичным, а переменная не установлена в ON, то отображается предупреждение. Эта информация может быть использована для устранения неполадок.

    • memberId UUID каждого члена кластера.

    • memberState состояние участника, как сообщается плагином Group Replication, см. столбец MEMBER_STATE таблицы .

Чтобы увидеть информацию о восстановлении и обычном вводе-выводе транзакций, статистике потоков-работчиков аппликатора и любых задержках; статистике координатора аппликатора, если включен параллельный аппликатор репликации; ошибках и другой информации от потоков-приемников и аппликаторов, используйте значение 2 или 3 для extended. При использовании этих значений открывается соединение с каждым экземпляром в кластере, чтобы можно было запрашивать дополнительную статистику, специфичную для экземпляра. Точная статистика, включенная в вывод, зависит от состояния и конфигурации экземпляра и версии сервера. Эта информация соответствует информации, показанной в таблице , см. описания соответствующих столбцов для получения дополнительной информации. Экземпляры, которые являются 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 показывает информацию из таблицы .

Раздел 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, который содержит информацию о потоках-работниках и соответствует информации, показанной в таблице .

Раздел 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_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 соответствует количеству настроенных работников, и включается дополнительный объект координатора. Показанная информация соответствует информации в таблице . Объект может содержать:

Раздел 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

worker объекты содержат следующую информацию, если в таблице была обнаружена ошибка:

  • lastErrno: см. LAST_ERROR_NUMBER

  • lastError: см. LAST_ERROR_MESSAGE

  • lastErrorTimestamp: см. LAST_ERROR_TIMESTAMP

connection объекты содержат следующую информацию, если в таблице была обнаружена ошибка:

  • lastErrno: см. LAST_ERROR_NUMBER

  • lastError: см. LAST_ERROR_MESSAGE

  • lastErrorTimestamp: см. LAST_ERROR_TIMESTAMP

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: Текущее состояние потоков применителя. Предоставляет подробную информацию о том, что именно делает поток применителя. Для получения дополнительной информации, см. .

      • receiverStatus: Текущий статус потока получателя. Агрегирование состояний, показанных в поле receiverThreadState. Может быть одним из следующих:

        • ON: поток получателя успешно подключился и готов к приему

        • CONNECTING: поток получателя подключается к источнику

        • ERROR: произошла ошибка при получении транзакций

        • OFF: поток получателя корректно отключился

      • receiverThreadState: Текущее состояние потока получателя. Предоставляет подробную информацию о том, что именно делает поток получателя. Для получения дополнительной информации, см. .

      • 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 и Group Replication

Group Replication имеет понятие протокола связи для группы, см. для получения дополнительной информации. Версия протокола связи Group Replication обычно должна управляться явно и устанавливаться в соответствии со старейшей версией MySQL Server, которую вы хотите поддерживать в группе. Однако InnoDB Cluster автоматически и прозрачно управляет версиями протоколов связи своих членов всякий раз, когда топология кластера изменяется с помощью операций AdminAPI. Кластер всегда использует самую последнюю версию протокола связи, поддерживаемую всеми экземплярами, которые в настоящее время являются частью кластера или присоединяются к нему.

  • При добавлении, удалении или повторном присоединении экземпляра к кластеру, а также при выполнении операции ресканирования или перезапуска кластера, версия протокола связи автоматически устанавливается на версию, поддерживаемую экземпляром, который сейчас имеет самую раннюю версию MySQL Server.

  • При выполнении поэтапного обновления путем удаления экземпляров из кластера, их обновления и повторного добавления в кластер, версия протокола связи автоматически обновляется, когда последний оставшийся экземпляр со старой версией MySQL Server удаляется из кластера перед его обновлением.

Чтобы увидеть используемую версию протокола связи в кластере, используйте функцию Cluster.status() с включенным параметром extended. Версия протокола связи возвращается в поле GRProtocolVersion, при условии, что кластер имеет кворум и ни один член кластера недоступен.

Проверка версии MySQL на экземплярах

Следующие операции могут сообщать информацию о версии MySQL Server, работающей на экземпляре:

  • Cluster.status()

  • Cluster.describe()

  • Cluster.rescan()

Поведение зависит от версии MySQL Server сеанса объекта Cluster.

  • Cluster.status()

    Если выполняются следующие требования, для каждого объекта JSON экземпляра объекта topology возвращается строка 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 или выше, для каждого объекта JSON экземпляра объекта topology возвращается строка 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() обнаруживает экземпляры, которые не принадлежат кластеру, для каждого объекта JSON экземпляра объекта newlyDiscoveredInstance возвращается строка version.

    Например, на экземпляре, работающем с версией 8.0.16: 

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

© 2025 Oracle
Licensed under the GPLv2 License.
https://docs.oracle.com/cd/E17952_01/mysql-shell-9.2-en/monitoring-innodb-cluster.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API