По умолчанию кластер 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 секунд. Сведения об изменении значения по умолчанию см. в разделе Раздел 13.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, который пропускает ошибку в этом случае.