По умолчанию кластер InnoDB работает в режиме с одним главным сервером, где в кластере есть один главный сервер, принимающий запросы чтения и записи (R/W), а все остальные экземпляры в кластере принимают только запросы чтения (R/O). При конфигурации кластера для работы в многоглавном режиме все экземпляры в кластере являются главными, что означает, что они принимают запросы чтения и записи (R/W). Если в кластере все экземпляры работают с версией MySQL сервера 8.0.15 или новее, вы можете изменять топологию кластера, пока кластер работает онлайн. В предыдущих версиях необходимо было полностью растворить и пересоздать кластер для внесения изменений в конфигурацию. Это использует координатор групповых действий, доступный через функции, описанные в , и поэтому вы должны соблюдать правила конфигурации онлайн-групп.

Обычно кластер с одним главным сервером выбирает нового главного сервера, когда текущий главный сервер неожиданно покидает кластер, например, из-за непредвиденной остановки. Процесс выбора обычно используется для выбора того, какой из текущих второстепенных серверов станет новым главным сервером. Чтобы переопределить процесс выбора и принудительно сделать конкретный экземпляр сервера в базовой группе репликации Group Replication новым главным сервером, используйте функцию Cluster.setPrimaryInstance(instance[, options), где instance указывает подключение к экземпляру, который должен стать новым главным сервером. Вы можете использовать параметр runningTransactionsTimeout, чтобы добавить тайм-аут от 0 до 3600 секунд для транзакций, которые выполняются при использовании функции. При установке таймаута входящие транзакции после выдачи команды отклоняются.

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

Вы можете удалить экземпляр из кластера в любое время по своему желанию. Это можно сделать с помощью метода Cluster.removeInstance(instance), как в следующем примере:

mysql-js> cluster.removeInstance('root@localhost:3310')

The instance will be removed from the InnoDB cluster. Depending on the instance
being the Seed or not, the Metadata session might become invalid. If so, please
start a new session to the Metadata Storage R/W instance.

Attempting to leave from the Group Replication group...

The instance 'localhost:3310' was successfully removed from the cluster.

Операция cluster.removeInstance() гарантирует, что экземпляр удален из метаданных всех членов кластера, которые являются ONLINE, и самого экземпляра. Последний экземпляр, оставшийся в состоянии ONLINE в кластере InnoDB, не может быть удален с помощью этой операции.

Когда удаляемый экземпляр имеет транзакции, которые все еще должны быть применены, AdminAPI ожидает до количества секунд, настроенных параметром MySQL Shell dba.gtidWaitTimeout для применения транзакций (GTID). Параметр MySQL Shell dba.gtidWaitTimeout имеет значение по умолчанию 60 секунд, см. Раздел 14.4, «Настройка параметров MySQL Shell» для получения информации о изменении значения по умолчанию. Если значение тайм-аута, определенное dba.gtidWaitTimeout, достигнуто при ожидании применения транзакций, и параметр force равен false (или не определен), выдается ошибка, и операция удаления прерывается. Если значение тайм-аута, определенное dba.gtidWaitTimeout, достигнуто при ожидании применения транзакций, и параметр force установлен в true, то операция продолжается без ошибки и удаляет экземпляр из кластера.

Для растворения кластера InnoDB подключитесь к экземпляру чтения-записи, например, главному в одноглавом кластере, и используйте команду Cluster.dissolve(). Это удалит все метаданные и конфигурацию, связанные с кластером, и отключит Group Replication на экземплярах. Любые данные, которые были реплицированы между экземплярами, не удаляются.

Операция Cluster.dissolve() может настраивать только экземпляры, которые являются ONLINE или доступны. Если члены кластера недоступны для члена, где вы выдали команду Cluster.dissolve(), вам необходимо решить, как должна проходить операция растворения. Если есть вероятность, что вы хотите вновь присоединить любые экземпляры, которые идентифицированы как отсутствующие в кластере, настоятельно рекомендуется отменить операцию растворения и сначала вернуть отсутствующие экземпляры в онлайн-режим, прежде чем продолжать операцию растворения. Это гарантирует, что все экземпляры смогут правильно обновить свои метаданные и что нет возможности возникновения ситуации раздвоенного мозга. Однако, если экземпляры из кластера, которые недоступны, навсегда покинули кластер, может не быть иного выбора, кроме как принудительно выполнить операцию растворения, что означает, что отсутствующие экземпляры игнорируются, а только онлайн-экземпляры подвергаются влиянию операции.

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

mysql-js> Cluster.dissolve()
The cluster still has the following registered instances:
{
    "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"
            }
        ]
    }
}
WARNING: You are about to dissolve the whole cluster and lose the high
availability features provided by it. This operation cannot be reverted. All
members will be removed from the cluster and replication will be stopped,
internal recovery user accounts and the cluster metadata will be dropped. User
data will be maintained intact in all instances.

Are you sure you want to dissolve the cluster? [y/N]: y

ERROR: The instance 'ic-2:3306' cannot be removed because it is on a '(MISSING)'
state. Please bring the instance back ONLINE and try to dissolve the cluster
again. If the instance is permanently not reachable, then you can choose to
proceed with the operation and only remove the instance from the Cluster
Metadata.

Do you want to continue anyway (only the instance metadata will be removed)?
[y/N]: y

Instance 'ic-3:3306' is attempting to leave the cluster...  Instance 'ic-1:3306'
is attempting to leave the cluster...

WARNING: The cluster was successfully dissolved, but the following instance was
skipped: 'ic-2:3306'. Please make sure this instance is permanently unavailable
or take any necessary manual action to ensure the cluster is fully dissolved.

В этом примере кластер состоял из трех экземпляров, один из которых был оффлайн при выполнении растворения. Ошибка обнаружена, и вам предоставляется выбор, как поступить. В данном случае отсутствующий ic-2 экземпляр игнорируется, а метаданные доступных членов обновляются.

Когда MySQL Shell работает в неинтерактивном режиме, например, при выполнении пакетного файла, вы можете настроить поведение операции Cluster.dissolve(), используя параметр force. Чтобы принудительно выполнить операцию растворения, игнорируя любые недоступные экземпляры, выполните:

mysql-js> Cluster.dissolve({force: true})

Любые достижимые экземпляры удаляются из кластера, а любые недоступные экземпляры игнорируются. Предупреждения в этом разделе о принудительном удалении отсутствующих экземпляров из кластера так же относятся к этому методу принудительного выполнения операции растворения.

Параметр MySQL Shell dba.gtidWaitTimeout настраивает время ожидания операции Cluster.dissolve() для применения транзакций кластера перед удалением целевого экземпляра из кластера, но только если целевой экземпляр является ONLINE. Ошибка выдается, если время ожидания истекло при ожидании применения транзакций кластера на любом из удаляемых экземпляров, за исключением случаев, когда используется force: true, что пропускает ошибку в этом случае.