Предел размера группы

Ограничения размера транзакции

--upgrade=MINIMAL параметр. Групповая репликация не может быть запущена после обновления MySQL Server, использующего параметр MINIMAL (--upgrade=MINIMAL), который не обновляет системные таблицы, от которых зависят внутренности репликации.

Блокировки разрывов. Процесс сертификации групповой репликации для конкурирующих транзакций не учитывает информацию о блокировках разрывов, так как она недоступна за пределами InnoDB. Дополнительную информацию см. в разделе Блокировки разрывов.

Блокировки таблиц и именованные блокировки. Процесс сертификации не учитывает блокировки таблиц (см. Раздел 15.3.6 «Операции LOCK TABLES и UNLOCK TABLES») или именованные блокировки (см. GET_LOCK()).

Контрольные суммы бинарного журнала. Групповая репликация в MySQL 9.2 поддерживает контрольные суммы, поэтому члены группы могут использовать значение по умолчанию binlog_checksum=CRC32. Значение для binlog_checksum не должно быть одинаковым для всех членов группы.

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

Уровень изоляции SERIALIZABLE. SERIALIZABLE уровень изоляции по умолчанию не поддерживается в группах с несколькими основными серверами. Установка уровня изоляции транзакции на SERIALIZABLE настраивает групповую репликацию на отказ от подтверждения транзакции.

Конкурентные операции DDL и DML. Конкурентные операторы определения данных и операторы обработки данных, выполняемые над одним объектом, но на разных серверах, не поддерживаются при использовании режима нескольких основных серверов. Во время выполнения операторов языка определения данных (DDL) над объектом, выполнение одновременных операторов языка обработки данных (DML) над тем же объектом, но на другом экземпляре сервера, связано с риском того, что конфликтующие DDL, выполняемые на разных экземплярах, не будут обнаружены.

Внешние ключи с каскадными ограничениями. Группы с несколькими основными серверами (все члены настроенны на group_replication_single_primary_mode=OFF) не поддерживают таблицы с многоуровневыми зависимостями внешних ключей, в частности таблицы, которые имеют определенные CASCADING. Это связано с тем, что ограничения внешних ключей, которые приводят к каскадным операциям, выполняемым группой с несколькими основными серверами, могут привести к необнаруженным конфликтам и привести к несогласованным данным на всех членах группы. Поэтому мы рекомендуем установить group_replication_enforce_update_everywhere_checks=ON на экземплярах серверов, используемых в группах с несколькими основными серверами, чтобы избежать необнаруженных конфликтов.

В режиме одного основного сервера это не проблема, так как он не допускает одновременных записей на нескольких членов группы, и, следовательно, нет риска необнаруженных конфликтов.

Тупик в режиме нескольких основных серверов. Когда группа работает в режиме нескольких основных серверов, операторы SELECT .. FOR UPDATE могут привести к тупику. Это связано с тем, что блокировка не разделяется между членами группы, поэтому ожидание такого оператора может не быть достигнуто.

Фильтры репликации. Глобальные фильтры репликации не могут быть использованы на экземпляре MySQL, который настроен для групповой репликации, потому что фильтрация транзакций на некоторых серверах сделает группу неспособной достичь соглашения об согласованном состоянии. Специфичные для канала фильтры репликации могут быть использованы на каналах репликации, которые не участвуют непосредственно в групповой репликации, например, где член группы также действует как реплика источника, находящегося вне группы. Они не могут быть использованы на каналах group_replication_applier или group_replication_recovery.

Зашифрованные соединения. Поддержка протокола TLSv1.3 доступна в MySQL, при условии, что он был скомпилирован с использованием OpenSSL 1.1.1 или более поздней версии. Групповая репликация поддерживает TLSv1.3, где она может быть использована для соединений групповой связи и соединений распределенного восстановления.

group_replication_recovery_tls_version и group_replication_recovery_tls_ciphersuites могут использоваться для настройки поддержки клиентом любого набора шифров, включая только нестандартные шифры по желанию. См. Раздел 8.3.2 «Зашифрованные соединения TLS протоколы и шифры».

Операции клонирования. Групповая репликация инициирует и управляет операциями клонирования для распределенного восстановления, но члены группы, которые были настроены для поддержки клонирования, также могут участвовать в операциях клонирования, инициируемых пользователем вручную. Вы можете инициировать операцию клонирования вручную, если операция включает член группы, на котором запущена групповая репликация, при условии, что операция клонирования не удаляет и не заменяет данные на получателе. Поэтому оператор для инициирования операции клонирования должен включать в себя DATA DIRECTORY предложение, если запущена групповая репликация. См. Раздел 20.5.4.2.4 «Клонирование для других целей».