19.4.9 Switching Sources and Replicas with Asynchronous Connection Failover — MySQL 9.2

19.4.9 Переключение источников и реплик с асинхронным отказоустойчивым соединением

Вы можете использовать механизм асинхронного отказа соединения для автоматического установления асинхронного (источник-реплика) соединения репликации с новым источником после отказа существующего соединения от реплики к источнику. Механизм асинхронного отказа соединения может использоваться для поддержания синхронизации реплики с несколькими серверами MySQL или группами серверов, которые разделяют данные. Список потенциальных серверов-источников хранится на реплике, и в случае отказа соединения новый источник выбирается из списка на основе заданного вами взвешенного приоритета.

Механизм асинхронного отказа соединения также поддерживает топологии Group Replication, автоматически отслеживая изменения в составе группы и различая первичные и вторичные серверы. При добавлении члена группы в список источников и определении его как части управляемой группы механизм асинхронного отказа соединения обновляет список источников, чтобы он соответствовал изменениям в составе, автоматически добавляя и удаляя членов группы по мере их присоединения или выхода. Для соединений и получения состояния используются только онлайн-члены группы, составляющие большинство.

Последний оставшийся член управляемой группы не удаляется автоматически, даже если он покидает группу, чтобы сохранить конфигурацию управляемой группы. Однако вы можете вручную удалить управляемую группу, если она больше не нужна.

Механизм асинхронного отказа соединения также позволяет реплике, которая является частью управляемой группы репликации, автоматически подключаться к отправителю, если текущий получатель (первичный в группе) выходит из строя. Эта функция работает с Group Replication, в группе, настроенной в режиме single-primary, где первичный сервер группы является репликой, имеющей канал репликации, использующий этот механизм. Функция предназначена для того, чтобы группа отправителей и группа получателей сохраняли синхронизацию друг с другом, даже когда некоторые члены временно недоступны. Она также синхронизирует группу получателей с одним или несколькими отправителями, которые не являются частью управляемой группы. Реплика, которая не является частью группы репликации, не может использовать эту функцию.

Требования к использованию механизма асинхронного отказа соединения:

На источнике и реплике должны использоваться GTID (gtid_mode=ON), и опция SOURCE_AUTO_POSITION оператора CHANGE REPLICATION SOURCE TO должна быть включена на реплике, чтобы использовать автоматическое позиционирование GTID для подключения к источнику.
На всех серверах-источниках в списке источника для канала должны существовать одинаковые учетные данные пользователя и пароль репликации. Эти данные используются для подключения к каждому из источников. Вы можете настроить разные учетные данные для разных каналов.
Учетные данные пользователя репликации должны иметь разрешения SELECT на таблицы Performance Schema, например, выполнив GRANT SELECT ON performance_schema.* TO 'repl_user';
Учетные данные пользователя и пароль репликации нельзя указывать в операторе запуска репликации, поскольку они должны быть доступны при автоматическом перезапуске для подключения к альтернативному источнику. Они должны быть установлены для канала с помощью оператора CHANGE REPLICATION SOURCE TO на реплике и записаны в хранилища метаданных репликации.
Если канал, в котором используется механизм асинхронного отказа соединения, находится на первичном сервере группы Group Replication в режиме single-primary, то асинхронный отказ соединения между репликами также активирован по умолчанию. В этой ситуации канал репликации и учетные данные пользователя и пароль репликации для канала должны быть настроены на всех вторичных серверах в группе репликации и на всех новых присоединяющихся членах. Если новые серверы настроены с помощью функции клонирования MySQL, это всё происходит автоматически.

Важно

Если вы не хотите, чтобы асинхронный отказ соединения происходил между репликами в этой ситуации, отключите его, отключив действие члена mysql_start_failover_channels_if_primary для группы, используя функцию group_replication_disable_member_action. Когда функция отключена, вам не нужно настраивать канал репликации на вторичных членах группы, но если первичный сервер выходит из строя или переходит в состояние ошибки, репликация для канала останавливается.

MySQL InnoDB ClusterSet доступен для обеспечения отказоустойчивости развертываний InnoDB Cluster, соединяя первичный InnoDB Cluster с одной или несколькими репликами в альтернативных местоположениях, например, в разных центрах обработки данных. Рассмотрите использование этого решения для упрощения настройки нового многогруппового развертывания для репликации, отказоустойчивости и аварийного восстановления. Вы можете использовать существующее развертывание Group Replication как InnoDB Cluster.

InnoDB ClusterSet и InnoDB Cluster разработаны для абстрагирования и упрощения процедур настройки, управления, мониторинга, восстановления и ремонта групп репликации. InnoDB ClusterSet автоматически управляет репликацией с первичного кластера на кластеры реплик, используя выделенный канал репликации ClusterSet. Вы можете использовать команды администратора для инициирования управляемого переключения или аварийного переключения между группами, если первичный кластер не функционирует нормально. Серверы и группы могут быть легко добавлены к или удалены из развертывания InnoDB ClusterSet после первоначальной настройки по мере изменения спроса. Для получения дополнительной информации см. .