Spec-Zone.ru › MySQL Shell 8.4

7.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: отображается только когда кластер работает в режиме single-primary. Показывает адрес текущего первичного экземпляра. Если это поле не отображается, кластер работает в режиме multi-primary.

  • ssl: используется ли кластером защищённое соединение. Показывает значения REQUIRED или DISABLED, в зависимости от того, как был настроен параметр memberSslMode во время createCluster() или addInstance(). Возвращаемое значение этого параметра соответствует значению переменной сервера на экземпляре. См. Раздел 7.6, «Защита кластера InnoDB».

  • 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. См. Раздел 7.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 Уникальный идентификатор каждого члена кластера.

    • 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

Если включен параллельный аппликатор репликации, то количество объектов в массиве workers в 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-8.4-en/monitoring-innodb-cluster.html

Spec-Zone.ru

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