8.7 InnoDB ClusterSet Status and Topology — MySQL Shell 8.4

8.7 Статус и топология набора InnoDB ClusterSet

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

Статус набора InnoDB ClusterSet

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

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

Если есть проблемы с любым из кластеров в наборе InnoDB ClusterSet, раздел 8.10, «Ремонт и повторное присоединение набора InnoDB ClusterSet» описывает процедуру их устранения и повторного присоединения кластера к набору (или удаления его, если проблему нельзя исправить). Если проблемный кластер является первичным, вам сначала необходимо выполнить контролируемый перевод, если он все еще функционирует (как описано в разделе 8.8, «Контролируемый перевод набора InnoDB ClusterSet»), или аварийный перевод, если он не функционирует или недоступен (как описано в разделе 8.9, «Аварийный перевод набора InnoDB ClusterSet»).

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

extended: 0 или опускание опции возвращает основную информацию о статусе доступности развертывания InnoDB ClusterSet, каждого кластера InnoDB в наборе и статусе репликации ClusterSet для каждого кластера-копии.
extended: 1 добавляет топологию для каждого кластера InnoDB в наборе, статус каждого отдельного узла-члена в каждом кластере и более подробную информацию о статусе канала репликации 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, который входит в развертывание InnoDB ClusterSet, даже если первичный кластер для развертывания InnoDB ClusterSet в настоящее время недоступен. Сам целевой экземпляр сервера должен быть доступен при использовании объекта. Если целевой экземпляр является членом кластера, который был помечен как недействительный, команда возвращает предупреждение, но все равно возвращает объект ClusterSet. Если целевой экземпляр в настоящее время не является членом развертывания InnoDB ClusterSet, команда возвращает ошибку. Объект ClusterSet содержит сведения о подключении сервера, из которого он был получен, поэтому объект ClusterSet, ранее извлеченный с узла-члена, который сейчас отключен, больше не будет работать, и вам потребуется получить его снова с сервера, который онлайн в развертывании InnoDB ClusterSet.

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

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

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

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

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

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

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

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, см. Раздел 8.10, «Восстановление и повторное присоединение InnoDB ClusterSet».
OFFLINE: Все серверы-члены кластера находятся в состоянии OFFLINE Групповой репликации. Кластер в таком случае не может функционировать в рамках развертывания InnoDB ClusterSet. Для достижения статуса OK в случае, если кластер не должен быть в настоящее время отключён, см. Раздел 8.10, «Восстановление и повторное присоединение InnoDB ClusterSet».
ERROR: Все серверы-члены кластера находятся в состоянии ERROR Групповой репликации. Кластер в таком случае не может функционировать в рамках развертывания InnoDB ClusterSet. Для достижения статуса OK, см. Раздел 8.10, «Восстановление и повторное присоединение InnoDB ClusterSet».
UNKNOWN: MySQL Shell в настоящее время не может связаться ни с одним сервером-членом, чтобы определить состояние кластера. Если это первичный кластер, развертыванию InnoDB ClusterSet присваивается статус UNAVAILABLE.
INVALIDATED: Кластер был признан недействительным во время процесса переключения. Во время управляемого переключения обеспечивается согласованность данных, и исходный первичный кластер понижается до работающего только для чтения кластера реплик. Однако во время аварийного переключения согласованность данных не гарантируется, поэтому для безопасности исходный первичный кластер помечается как недействительный во время процесса переключения. Кластеры реплик также помечаются как недействительные, если они недоступны или недоступны в момент переключения или во время управляемого переключения. Кластер с этим глобальным статусом вообще не функционирует в рамках развертывания InnoDB ClusterSet. Кластер не обязательно имеет какие-либо технические проблемы и может быть способен повторно присоединиться к развертыванию InnoDB ClusterSet после ручной проверки. Если с кластером можно связаться, необходимо убедиться, что он остановлен, чтобы он не принимал новые транзакции. Для обработки этой ситуации см. Раздел 8.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() для кластера автоматически корректирует конфигурацию канала при необходимости и перезапускает канал. Это может быть достаточно для решения проблемы. Инструкции по выполнению этой операции см. в разделе 8.10.5 «Присоединение кластера к InnoDB ClusterSet».

Топология InnoDB ClusterSet

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

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() см. в разделе 6.10.4 «Параметры маршрутизации».

Статус маршрутизатора MySQL для 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.