17.3.2 Group Replication Limitations — MySQL 5.7

17.3.2 Ограничения групповой репликации

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

Подсказка

Групповая репликация основана на репликации на основе GTID, поэтому вы также должны быть осведомлены о Разделе 16.1.3.6, «Ограничения репликации с GTID».

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

Примечание

Для группы в режиме нескольких основных серверов, если вы не полагаетесь на REPEATABLE READ семантику в своих приложениях, рекомендуется использовать уровень изоляции READ COMMITTED с групповой репликацией. InnoDB не использует замки интервалов в READ COMMITTED, что согласует локальное обнаружение конфликтов внутри InnoDB с распределенным обнаружением конфликтов, выполняемым групповой репликацией. Для группы в режиме одного основного сервера только основной сервер принимает записи, поэтому уровень изоляции READ COMMITTED не важен для групповой репликации.
Замки таблиц и именованные замки. Процесс сертификации не учитывает замки таблиц (см. Раздел 13.3.5, «Выражения LOCK TABLES и UNLOCK TABLES») или именованные замки (см. GET_LOCK()).
Контрольные суммы событий репликации. Из-за ограничений по дизайну контрольных сумм событий репликации групповая репликация в настоящее время не может использовать их. Поэтому установите --binlog-checksum=NONE.
Уровень изоляции SERIALIZABLE. SERIALIZABLE уровень изоляции по умолчанию не поддерживается в группах с несколькими основными серверами. Установка уровня изоляции транзакции в SERIALIZABLE настраивает групповую репликацию на отказ от подтверждения транзакции.
Одновременные операции DDL и DML. Одновременные операторы определения данных (DDL) и операторы обработки данных (DML), выполняемые над одним объектом, но на разных серверах, не поддерживаются при использовании режима нескольких основных серверов. Во время выполнения операторов языка определения данных (DDL) над объектом выполнение одновременных операторов языка обработки данных (DML) над тем же объектом, но на другом экземпляре сервера, имеет риск, что конфликтующие DDL, выполняемые на разных экземплярах, не будут обнаружены.
Внешние ключи с каскадными ограничениями. Группы в режиме нескольких основных серверов (все члены настроены с group_replication_single_primary_mode=OFF) не поддерживают таблицы с многоуровневыми зависимостями внешних ключей, особенно таблицы, в которых определены CASCADING. Это связано с тем, что внешние ключи, которые приводят к выполнению каскадных операций группой в режиме нескольких основных серверов, могут привести к необнаруженным конфликтам и несогласованным данным между членами группы. Поэтому рекомендуется установить group_replication_enforce_update_everywhere_checks=ON на экземплярах сервера, используемых в группах в режиме нескольких основных серверов, чтобы избежать необнаруженных конфликтов.

В режиме одного основного сервера это не проблема, так как он не позволяет одновременные записи на нескольких членов группы, и, следовательно, нет риска необнаруженных конфликтов.
Аудит MySQL Enterprise и Брандмауэр MySQL Enterprise. До версии 5.7.21 MySQL Enterprise Audit и MySQL Enterprise Firewall используют MyISAM таблицы в базе данных системы mysql. Групповая репликация не поддерживает MyISAM таблицы.
Тупик в режиме нескольких основных серверов. Когда группа работает в режиме нескольких основных серверов, SELECT .. FOR UPDATE операторы могут привести к тупику. Это связано с тем, что замок не разделяется между членами группы, поэтому ожидание такого оператора может не быть достигнуто.
Фильтры репликации. Фильтры репликации не могут использоваться на экземпляре MySQL сервера, настроенном для групповой репликации, так как фильтрация транзакций на некоторых серверах сделает группу неспособной достичь согласованного состояния.

Ограничение размера группы

Максимальное количество MySQL серверов, которые могут быть членами одной группы репликации, равно 9. Если дальнейшие члены попытаются присоединиться к группе, их запрос будет отклонен. Это ограничение было определено на основе тестов и бенчмарков как безопасная граница, при которой группа работает стабильно в устойчивой локальной сети.

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

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

По возможности, старайтесь ограничить размер ваших транзакций. Например, разбейте файлы, используемые с LOAD DATA, на более мелкие куски.
Используйте переменную системы group_replication_transaction_size_limit, чтобы указать максимальный размер транзакции, который группа принимает. В выпусках до и включая MySQL 5.7.37 эта переменная системы имеет значение по умолчанию ноль, но начиная с MySQL 5.7.38 и в MySQL 8.0 она имеет значение по умолчанию максимального размера транзакции в 150000000 байт (приблизительно 143 МБ). Транзакции, превышающие этот предел, отменяются и не отправляются в систему групповой коммуникации групповой репликации (GCS) для распространения в группу. Настраивайте значение этой переменной в зависимости от максимального размера сообщения, которое вам нужно, чтобы группа могла переносить, помня о том, что время обработки транзакции пропорционально ее размеру.

Примечание

При обновлении с MySQL 5.7.37 или более ранней версии до MySQL 5.7.38 или более поздней версии, если ваши серверы групповой репликации ранее принимали транзакции, превышающие новый предел по умолчанию, и вы разрешали group_replication_transaction_size_limit по умолчанию до старого предела в ноль, эти транзакции начнут отклоняться после обновления до нового значения по умолчанию. Вам нужно либо указать соответствующий предел размера, который позволяет максимальный размер сообщения, который вам нужна группа (что является рекомендуемым решением), или установить значение ноль для восстановления предыдущего поведения.
Используйте переменную системы group_replication_compression_threshold, чтобы указать размер сообщения, превышающий который применяется сжатие. Эта переменная системы имеет значение по умолчанию 1000000 байт (1 МБ), поэтому большие сообщения сжимаются автоматически. Сжатие выполняется системой групповой коммуникации групповой репликации (GCS), когда она получает сообщение, которое было разрешено настройкой group_replication_transaction_size_limit, но превышает настройку group_replication_compression_threshold. Если вы установите значение переменной системы в ноль, сжатие отключено. Дополнительную информацию см. в Разделе 17.9.7.2, «Сжатие сообщений».

Если вы отключили сжатие сообщений и не указали максимальный размер транзакции, верхний предел размера сообщения, который может обрабатываться потоком применений на члене группы репликации, — это значение переменной системы члена slave_max_allowed_packet, которая имеет значение по умолчанию и максимальное значение 1073741824 байта (1 ГБ). Сообщение, превышающее этот предел, отклоняется при попытке его обработки принимающим членом. Верхний предел размера сообщения, которое может исходить от члена группы и пытаться передать в группу, составляет 4294967295 байт (приблизительно 4 ГБ). Это жесткий предел размера пакета, который принимается движком групповой коммуникации для групповой репликации (XCom, вариант Paxos), который получает сообщения после обработки их GCS.