9.7 InnoDB ClusterSet Status and Topology — MySQL Shell 9.2

9.7 Статус и топология InnoDB ClusterSet

В этом разделе описывается следующее:

Статус InnoDB ClusterSet

Команда AdminAPI's clusterSet.status() возвращает JSON-объект, описывающий статус развертывания InnoDB ClusterSet. Вывод включает в себя статус самого развертывания InnoDB ClusterSet и глобальный и кластерный статус каждого InnoDB Cluster в ClusterSet. Расширенный вывод добавляет статус каждого сервера-члена в каждом кластере, информацию о каналах асинхронной репликации, управляемых InnoDB ClusterSet, и другую конфигурационную и статусную информацию. Команда сообщает о статусе репликации ClusterSet, а также самих серверов. При наличии каких-либо проблем, сообщения об ошибках и предупреждениях включены для более подробного объяснения проблемы.

Экземпляр MySQL Shell, где вы используете clusterSet.status(), может быть подключен к любому активному члену InnoDB ClusterSet. Метаданные могут быть получены из первичного кластера через любой другой активный кластер в InnoDB ClusterSet.

Если возникла проблема с одним из кластеров в InnoDB ClusterSet, Раздел 9.10, «Ремонт и повторное присоединение InnoDB ClusterSet» объясняет процедуру ее устранения и повторного присоединения кластера к ClusterSet (или удаления его, если проблема не может быть устранена). Если кластер с проблемой является первичным кластером, сначала необходимо выполнить контролируемый отказ от работы, если он всё ещё функционирует (как описано в Разделе 9.8, «Контролируемый отказ от работы InnoDB ClusterSet»), или аварийный отказ от работы, если он не функционирует или не может быть достигнут (как описано в Разделе 9.9, «Аварийный отказ от работы InnoDB ClusterSet»).

Вы можете использовать опцию extended, значение которой по умолчанию равно 0, для увеличения уровня подробности вывода следующим образом:

extended: 0 или опускание опции возвращает основную информацию о статусе доступности развертывания InnoDB ClusterSet, каждого InnoDB Cluster в ClusterSet и статусе репликации ClusterSet для каждого кластера-реплики.
extended: 1 добавляет топологию каждого InnoDB Cluster в ClusterSet, статус каждого отдельного сервера-члена в каждом кластере и более подробную информацию о статусе канала репликации ClusterSet для каждого кластера-реплики.
extended: 2 добавляет дополнительные детали о каждом отдельном сервере-члене в каждом кластере и о канале репликации ClusterSet, включая набор GTID.
extended: 3 добавляет важные параметры конфигурации для канала репликации ClusterSet, такие как параметры повторных подключений.

Например:

mysql-js> myclusterset.status({extended: 1})
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "globalStatus": "OK",
            "primary": "127.0.0.1:3310",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:3310": {
                    "address": "127.0.0.1:3310",
                    "memberRole": "PRIMARY",
                    "mode": "R/W",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3320": {
                    "address": "127.0.0.1:3320",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:3330": {
                    "address": "127.0.0.1:3330",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8"
        },
        "clustertwo": {
            "clusterRole": "REPLICA",
            "clusterSetReplication": {
                "applierStatus": "APPLIED_ALL",
                "applierThreadState": "Waiting for an event from Coordinator",
                "applierWorkerThreads": 4,
                "receiver": "127.0.0.1:4410",
                "receiverStatus": "ON",
                "receiverThreadState": "Waiting for source to send event",
                "source": "127.0.0.1:3310"
            },
            "clusterSetReplicationStatus": "OK",
            "globalStatus": "OK",
            "status": "OK",
            "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
            "topology": {
                "127.0.0.1:4410": {
                    "address": "127.0.0.1:4410",
                    "memberRole": "PRIMARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:4420": {
                    "address": "127.0.0.1:4420",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                },
                "127.0.0.1:4430": {
                    "address": "127.0.0.1:4430",
                    "memberRole": "SECONDARY",
                    "mode": "R/O",
                    "replicationLagFromImmediateSource": "",
                    "replicationLagFromOriginalSource": "",
                    "status": "ONLINE",
                    "version": "8.0.27"
                }
            },
            "transactionSet": "0f6ff279-2764-11ec-ba06-00059a3c7a00:1-5,953a51d5-2690-11ec-ba07-00059a3c7a00:1,c51c1b15-269e-11ec-b9ba-00059a3c7a00:1-131,c51c29ad-269e-11ec-b9ba-00059a3c7a00:1-8",
            "transactionSetConsistencyStatus": "OK",
            "transactionSetErrantGtidSet": "",
            "transactionSetMissingGtidSet": ""
        }
    },
    "domainName": "testclusterset",
    "globalPrimaryInstance": "127.0.0.1:3310",
    "metadataServer": "127.0.0.1:3310",
    "primaryCluster": "clusterone",
    "status": "HEALTHY",
    "statusText": "All Clusters available."
}

Чтобы получить ссылку на объект ClusterSet, представляющий InnoDB ClusterSet для экземпляра целевого сервера, используйте команду dba.getClusterSet() или cluster.getClusterSet(). Эти команды работают, если целевой экземпляр сервера является членом InnoDB Cluster, который входит в состав развертывания InnoDB ClusterSet, даже если первичный кластер для развертывания InnoDB ClusterSet в настоящее время недоступен. Целевой экземпляр сервера должен быть доступен при использовании объекта. Если целевой экземпляр является членом кластера, который был помечен как устаревший, команда возвращает предупреждение, но всё ещё возвращает объект ClusterSet. Если целевой экземпляр не является в настоящее время членом развертывания InnoDB ClusterSet, команда возвращает ошибку. Объект ClusterSet содержит данные подключения к серверу, откуда он был получен, поэтому объект ClusterSet, который вы ранее получили с сервера-члена, который сейчас отключён, больше не будет работать, и вам потребуется получить его снова с сервера, который онлайн в развертывании InnoDB ClusterSet.

Объект ClusterSet по умолчанию использует учетную запись, с которой он был получен, для операций, требующих разрешений. Важно получить объект, когда вы подключены к экземпляру сервера с помощью соответствующей учетной записи пользователя для операций, которые вы хотите выполнить с помощью него. Некоторые операции во время процесса развертывания InnoDB ClusterSet требуют разрешений, и для этого используется учетная запись пользователя по умолчанию, сохранённая в объекте, так что процессу не нужно хранить другие учетные записи пользователей. Для мониторинга и устранения неполадок InnoDB ClusterSet, который вы уже настроили, подходит учетная запись администратора InnoDB Cluster. Для процесса первоначального развертывания кластера подходит учетная запись конфигурации сервера InnoDB Cluster. Дополнительная информация представлена в Разделе 9.3, «Учетные записи пользователей для InnoDB ClusterSet».

При использовании функции clusterSet.status(), общий статус ClusterSet (поле status) для развертывания InnoDB ClusterSet может быть одним из следующих:

HEALTHY: Первичный кластер в InnoDB ClusterSet функционирует удовлетворительно, и все кластеры-реплики функционируют удовлетворительно.
AVAILABLE: Первичный кластер в InnoDB ClusterSet функционирует удовлетворительно, но один или несколько кластеров-реплик имеют нарушения в функционировании или не функционируют.
UNAVAILABLE: Первичный кластер в InnoDB ClusterSet не функционирует, поскольку он отключён или потерял кворум, или MySQL Shell не может связаться с первичным кластером, чтобы определить его статус.

Общий статус ClusterSet, сообщаемый для развертывания InnoDB ClusterSet, зависит от общего статуса каждого InnoDB Cluster. InnoDB Cluster в ClusterSet сообщает три статуса:

Глобальный статус (поле globalStatus) — это статус InnoDB Cluster относительно его роли в InnoDB ClusterSet. Этот статус показывает, может ли кластер всё ещё функционировать удовлетворительно в развертывании InnoDB ClusterSet, даже если у него есть некоторые проблемы, например, сервер-член в настоящее время отключён. InnoDB Cluster может быть помечен как устаревший во время отката, независимо от статуса серверов-членов, и в таком случае это отображается как глобальный статус.
Статус кластера (поле status) — это статус InnoDB Cluster относительно его собственной работы. Этот статус показывает, есть ли у кластера технические проблемы, такие как один или несколько отключённых членов, потеря кворума или состояние ошибки Group Replication. Кластер может терпеть определённые проблемы, но всё ещё функционировать удовлетворительно как часть развертывания InnoDB ClusterSet. По этой причине при уровне подробности по умолчанию функция clusterSet.status() сообщает о статусе кластера только для тех кластеров, которые вызывают проблему глобального статуса. Чтобы просмотреть статус кластера для всех кластеров в InnoDB ClusterSet, независимо от того, вызывает ли он проблему глобального статуса или нет, используйте опцию extended, чтобы указать более высокий уровень подробности.
Статус репликации ClusterSet (поле clusterSetReplicationStatus) — это статус канала репликации ClusterSet для кластера-реплики InnoDB. Этот статус показывает, есть ли у реплицируемого кластера проблемы с репликацией из первичного кластера, так что их можно рассматривать отдельно от любых технических проблем с серверами-членами в кластере. Реплицируемый InnoDB Cluster сообщает о статусе репликации ClusterSet независимо от того, вызывает ли он проблему глобального статуса. У первичного InnoDB Cluster нет этого поля статуса, так как канал репликации ClusterSet не работает на первичном кластере.

При более высоких уровнях подробности расширенный вывод функции clusterSet.status() показывает статус каждого сервера-члена в каждом InnoDB Cluster. Вывод включает состояние Group Replication члена (поле memberState) и, для сервера в реплицируемом кластере, состояние репликации на члене. Для получения информации о состояниях Group Replication см. .

Глобальный статус (поле globalStatus) для InnoDB Cluster может быть одним из следующих:

OK: Кластер функционирует удовлетворительно в развертывании InnoDB ClusterSet. По крайней мере, один из серверов-членов кластера находится в состоянии ONLINE группы репликации, и группа репликации имеет кворум. Если кластер является кластером реплик, статус репликации ClusterSet также OK. Этот глобальный статус не обязательно означает отсутствие технических проблем с кластером. Некоторые члены могут быть отключены, или в кластере может быть недостаточно членов для обеспечения толерантности к сбоям. Однако кластер функционирует достаточно хорошо, чтобы продолжать работу в рамках развертывания InnoDB ClusterSet. Такой глобальный статус может иметь как первичный, так и реплицирующий кластер.
OK_NOT_REPLICATING: Кластер функционирует удовлетворительно, но репликация остановлена на канале репликации ClusterSet, либо по управляемому запросу, либо из-за ошибки репликации. Такой глобальный статус может иметь только кластер реплик.
OK_NOT_CONSISTENT: Кластер функционирует удовлетворительно, но набор транзакций в кластере (набор GTID) разошёлся с набором транзакций в первичном кластере, так что в кластере реплик есть дополнительные транзакции, которых нет в первичном кластере. Репликация может быть остановлена на канале репликации ClusterSet, либо по управляемому запросу, либо из-за ошибки репликации, или канал может по-прежнему выполнять репликацию. Такой глобальный статус может иметь только кластер реплик. Кластер реплик с таким статусом недоступен для запланированного переключения, хотя принудительное переключение возможно.
OK_MISCONFIGURED: Кластер функционирует удовлетворительно, но обнаружена некорректная конфигурация для канала репликации ClusterSet. Например, канал может выполнять репликацию с неправильного источника. Канал репликации может работать или репликация может быть остановлена. Такой глобальный статус может иметь только кластер реплик.
NOT_OK: Кластер вообще не функционирует в рамках развертывания InnoDB ClusterSet из-за технической проблемы. Он потерял кворум или все серверы-члены находятся в состоянии OFFLINE группы репликации. Такой глобальный статус может иметь как первичный, так и реплицирующий кластер. Если первичный кластер имеет этот глобальный статус, развертыванию InnoDB ClusterSet присваивается статус UNAVAILABLE.
UNKNOWN: Кластер является первичным кластером для развертывания InnoDB ClusterSet, но MySQL Shell в настоящее время не может связаться с ним для определения его состояния. Пока первичный кластер недоступен, развертыванию InnoDB ClusterSet присваивается статус UNAVAILABLE.
INVALIDATED: Кластер был аннулирован во время процесса переключения. Во время управляемого процесса переключения обеспечивается согласованность данных, и исходный первичный кластер понижается до рабочего кластера реплик только для чтения. Однако во время процесса аварийного переключения согласованность данных не гарантируется, поэтому для безопасности исходный первичный кластер помечается как аннулированный во время процесса переключения. Кластеры реплик также помечаются как аннулированные, если они недоступны или не могут быть достигнуты в момент переключения или во время управляемого переключения. Кластер с этим глобальным статусом не функционирует в рамках развертывания InnoDB ClusterSet. У кластера не обязательно есть какие-либо технические проблемы, и он может быть готов к повторному присоединению к развертыванию InnoDB ClusterSet после ручного подтверждения. Если с кластером можно связаться, необходимо убедиться, что он отключён, чтобы он не принимал новые транзакции.

Состояние кластера (поле status), сообщаемое для InnoDB Cluster, может быть одним из следующих, которые могут быть сообщены как для первичного, так и для реплицирующего кластера:

OK: Все серверы-члены кластера находятся в состоянии ONLINE группы репликации, и в кластере три или более членов.
OK_PARTIAL: По крайней мере, три сервера-члена кластера находятся в состоянии ONLINE группы репликации. Однако один или несколько серверов-членов находятся в состояниях OFFLINE, RECOVERING, ERROR или UNREACHABLE группы репликации, поэтому они в настоящее время не участвуют в работе кластера. Кластер в такой ситуации функционирует достаточно хорошо, чтобы продолжать работать в рамках развертывания InnoDB ClusterSet, но для достижения статуса OK необходимо устранить проблемы с серверами-членами.
OK_NO_TOLERANCE: Все серверы-члены кластера находятся в состоянии ONLINE группы репликации, но в кластере менее трёх членов, поэтому он не обладает достаточной толерантностью к сбоям. Кластер в такой ситуации функционирует достаточно хорошо, чтобы продолжать работать в рамках развертывания InnoDB ClusterSet, но для достижения статуса OK необходимо добавить больше серверов-членов.
OK_NO_TOLERANCE_PARTIAL: Один или два сервера-члена кластера находятся в состоянии ONLINE группы репликации, но один или несколько находятся в состояниях OFFLINE, RECOVERING, ERROR или UNREACHABLE группы репликации. Поэтому кластер не обладает достаточной толерантностью к сбоям из-за недоступности некоторых членов. Кластер в такой ситуации функционирует достаточно хорошо, чтобы продолжать работать в рамках развертывания InnoDB ClusterSet, но для достижения статуса OK необходимо устранить проблемы с серверами-членами.
NO_QUORUM: Кластер не имеет кворума, что означает, что большинство серверов-членов группы репликации недоступны для принятия решения. Группа репликации может переконфигурировать себя с новым номером группы, если члены покидают её добровольно или их удаляют по решению группы, поэтому потеря кворума означает, что отсутствующие серверы-члены либо потерпели неудачу, либо были отключены от других из-за сетевого разрыва. Кластер в этой ситуации не может функционировать в рамках развертывания InnoDB ClusterSet. Чтобы перевести кластер в состояние OK, см. Раздел 9.10, «Восстановление и повторное присоединение InnoDB ClusterSet».
OFFLINE: Все серверы-члены кластера находятся в состоянии OFFLINE группы репликации. Кластер в такой ситуации не может функционировать в рамках развертывания InnoDB ClusterSet. Для перевода кластера в состояние OK, если он не должен быть отключён, см. Раздел 9.10, «Восстановление и повторное присоединение InnoDB ClusterSet».
ERROR: Все серверы-члены кластера находятся в состоянии ERROR группы репликации. Кластер в такой ситуации не может функционировать в рамках развертывания InnoDB ClusterSet. Чтобы перевести кластер в состояние OK, см. Раздел 9.10, «Восстановление и повторное присоединение InnoDB ClusterSet».
UNKNOWN: MySQL Shell в настоящее время не может связаться ни с одним сервером-членом для определения состояния кластера. Если это первичный кластер, развертыванию InnoDB ClusterSet присваивается статус UNAVAILABLE.
INVALIDATED: Кластер был аннулирован во время процесса переключения. Во время управляемого процесса переключения обеспечивается согласованность данных, и исходный первичный кластер понижается до рабочего кластера реплик только для чтения. Однако во время процесса аварийного переключения согласованность данных не гарантируется, поэтому для безопасности исходный первичный кластер помечается как аннулированный во время процесса переключения. Кластеры реплик также помечаются как аннулированные, если они недоступны или не могут быть достигнуты в момент переключения или во время управляемого переключения. Кластер с этим глобальным статусом не функционирует в рамках развертывания InnoDB ClusterSet. У кластера не обязательно есть какие-либо технические проблемы, и он может быть готов к повторному присоединению к развертыванию InnoDB ClusterSet после ручного подтверждения. Если с кластером можно связаться, необходимо убедиться, что он отключён, чтобы он не принимал новые транзакции. Для обработки этой ситуации см. Раздел 9.10, «Восстановление и повторное присоединение InnoDB ClusterSet».

Состояние кластера относится к техническим проблемам с InnoDB Cluster в качестве группы репликации, а не к процессу репликации. Для кластера реплик также сообщается статус репликации ClusterSet (поле clusterSetReplicationStatus) следующим образом:

OK: Канал репликации ClusterSet работает.
STOPPED: Канал репликации ClusterSet был остановлен в управляемом режиме. Этот статус отображается, когда приостановлены поток получателя, поток прикладного модуля или оба потока.
CONNECTING: Канал репликации подключается. Если при подключении возникает ошибка, она игнорируется до тех пор, пока состояние канала не обновится до ON или OFF.
ERROR: Канал репликации ClusterSet остановлен из-за ошибки репликации, такой как некорректная конфигурация или набор транзакций, отличающийся от набора в первичном кластере.
MISCONFIGURED: Обнаружена некорректная конфигурация канала репликации ClusterSet, например, репликация с неправильного источника. Канал может работать или репликация может быть остановлена.
MISSING: Канала репликации ClusterSet нет на серверах в этом кластере.
UNKNOWN: MySQL Shell в настоящее время не может связаться с кластером реплик для определения статуса канала репликации.

Если единственная проблема кластера связана с каналом репликации ClusterSet, выполнение команды clusterSet.rejoinCluster() для кластера автоматически исправляет конфигурацию канала при необходимости и перезапускает канал. Это может быть достаточно для решения проблемы. Инструкции по этому вопросу см. в разделе 9.10.5 «Присоединение кластера к InnoDB ClusterSet».

Топология InnoDB ClusterSet

Если вам нужно только просмотреть топологию InnoDB ClusterSet и информация о состоянии не требуется, можно использовать функцию clusterSet.describe(). Эта функция возвращает JSON-объект, описывающий топологию развертывания InnoDB ClusterSet, а также IP-адрес и идентификатор каждого узла сервера в каждом InnoDB Cluster. Например:

mysql-js> myclusterset.describe()
{
    "clusters": {
        "clusterone": {
            "clusterRole": "PRIMARY",
            "topology": [
                {
                    "address": "127.0.0.1:3310",
                    "label": "127.0.0.1:3310"
                },
                {
                    "address": "127.0.0.1:3320",
                    "label": "127.0.0.1:3320"
                },
                {
                    "address": "127.0.0.1:3330",
                    "label": "127.0.0.1:3330"
                }
            ]
        },
        "clustertwo": {
            "clusterRole": "REPLICA",
            "topology": [
                {
                    "address": "127.0.0.1:4410",
                    "label": "127.0.0.1:4410"
                },
                {
                    "address": "127.0.0.1:4420",
                    "label": "127.0.0.1:4420"
                },
                {
                    "address": "127.0.0.1:4430",
                    "label": "127.0.0.1:4430"
                }
            ]
        }
    },
    "domainName": "testclusterset",
    "primaryCluster": "clusterone"
}

Эта информация также предоставляется расширенным выводом для функции clusterSet.status().

Сведения о clusterSet.setRoutingOption() см. в разделе 7.4 «Параметры маршрутизации».

Статус MySQL Router для InnoDB ClusterSet

Чтобы увидеть экземпляры MySQL Router, зарегистрированные для InnoDB ClusterSet, выполните команду clusterSet.listRouters() в MySQL Shell, подключившись к любому узлу сервера в развертывании InnoDB ClusterSet. Команда возвращает сведения обо всех зарегистрированных экземплярах MySQL Router или об одном экземпляре маршрутизатора, который вы указали с помощью его определения. Например:

mysql-js> myclusterset.listRouters()
{
    "domainName": "testclusterset",
    "routers": {
       "mymachine::Rome1": {
            "hostname": "mymachine",
            "lastCheckIn": 2021-10-15 11:58:37,
            "roPort": 6447,
            "roXPort": 6449,
            "rwPort": 6446,
            "rwXPort": 6448,
            "targetCluster": "primary",
            "version": "8.0.27"
        },
        "mymachine2::Rome2": {
            "hostname": "mymachine2",
            "lastCheckIn": 2021-10-15 11:58:37,
            "roPort": 6447,
            "roXPort": 6449,
            "rwPort": 6446,
            "rwXPort": 6448,
            "targetCluster": "primary",
            "version": "8.0.27"
        }
    }
}

Информация об экземпляре включает имя экземпляра MySQL Router, номера портов для чтения и записи трафика с использованием классического протокола MySQL и протокола X, целевой кластер и время последней проверки экземпляра с целевым кластером. Если версия MySQL Router ниже необходимой для работы с этим развертыванием InnoDB ClusterSet, в информации об экземпляре об этом указывается.

Чтобы увидеть параметры маршрутизации, установленные для каждого экземпляра MySQL Router, и глобальную политику для развертывания InnoDB ClusterSet, выполните команду clusterSet.routingOptions() в MySQL Shell, подключившись к любому узлу сервера в развертывании InnoDB ClusterSet. Настройка для определенного экземпляра MySQL Router переопределяет глобальную политику. Например:

mysql-js> myclusterset.routingOptions()
{
    "domainName": "testclusterset",
    "global": {
        "invalidated_cluster_policy": "drop_all",
        "target_cluster": "primary"
    },
    "routers": {
        "mymachine::Rome1":  {
            "target_cluster": "primary"
            "invalidated_cluster_policy": "accept_ro"
        },
        "mymachine2::Rome2": {}
    }
}

Если какой-либо параметр маршрутизации не отображается для экземпляра MySQL Router, как в приведенном выше примере для Rome2, это означает, что у экземпляра нет этого параметра, и он следует глобальной политике. Вывод для Rome1 показывает "target_cluster": "primary", что соответствует глобальной политике. Это потому, что у Rome1 параметр маршрутизации был явно установлен на "primary" с помощью команды clusterSet.setRoutingOption(), в этом случае он отображается. Чтобы очистить параметр маршрутизации, установите его значение в null.