Двигатель хранения InnoDB. Данные должны храниться в транзакционном движке хранения InnoDB. Транзакции выполняются оптимистично, а затем, на этапе фиксации, проверяются на наличие конфликтов. Если конфликты возникают, для поддержания согласованности в группе некоторые транзакции отменяются. Это означает, что требуется транзакционный двигатель хранения. Более того, InnoDB предоставляет некоторые дополнительные функции, которые улучшают управление и обработку конфликтов при совместной работе с группой репликации. Использование других движков хранения, включая временный движок хранения MEMORY, может привести к ошибкам в группе репликации. Преобразуйте все таблицы в других движках хранения для использования InnoDB перед использованием экземпляра с группой репликации. Вы можете предотвратить использование других движков хранения, установив переменную системы disabled_storage_engines на членах группы, например:

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

Первичные ключи. Каждая таблица, которая должна быть реплицирована группой, должна иметь определенный первичный ключ или эквивалент первичного ключа, где эквивалент представляет собой уникальный ключ без NULL-значений. Такие ключи необходимы в качестве уникального идентификатора для каждой строки в таблице, что позволяет системе определять, какие транзакции конфликтуют, идентифицируя точно, какие строки каждая транзакция изменила. Группа репликации имеет собственный набор встроенных проверок первичных ключей или их эквивалентов и не использует проверки, выполняемые переменной системы sql_require_primary_key. Вы можете установить sql_require_primary_key=ON для серверного экземпляра, где работает группа репликации, и вы можете установить опцию REQUIRE_TABLE_PRIMARY_KEY_CHECK оператора CHANGE REPLICATION SOURCE TO на ON для канала группы репликации. Однако имейте в виду, что вы можете найти некоторые транзакции, которые допускаются встроенными проверками группы репликации, но не допускаются проверками, выполняемыми при установке sql_require_primary_key=ON или REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON.

Производительность сети. MySQL Group Replication разработан для развертывания в кластерной среде, где серверные экземпляры находятся очень близко друг к другу. Производительность и стабильность группы могут быть затронуты как задержкой, так и пропускной способностью сети. Двунаправленное общение должно поддерживаться в любое время между всеми членами группы. Если входящее или исходящее общение заблокировано для серверного экземпляра (например, брандмауэром или проблемами подключения), член не может функционировать в группе, и члены группы (включая члена с проблемами) могут не сообщить о корректном статусе члена для затронутого серверного экземпляра.

Вы можете использовать сетевую инфраструктуру на основе IPv4, IPv6 или их сочетания для TCP-общения между удаленными серверами Group Replication. Также ничего не мешает Group Replication работать через виртуальную частную сеть (VPN).

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

Уникальный идентификатор сервера. Используйте системную переменную server_id, чтобы настроить сервер с уникальным идентификатором сервера, как это требуется для всех серверов в репликации. Идентификатор сервера должен быть положительным целым числом от 1 до (2³²)−1, и он должен отличаться от любого другого идентификатора сервера, используемого любым другим сервером в репликации.

Активный двоичный журнал. В MySQL 8.4 двоичный журнал включён по умолчанию. Вы можете указать имена файлов двоичного журнала, используя --log-bin[=log_file_name]. Групповая репликация дублирует содержимое двоичного журнала, поэтому он должен быть включён для её работы. См. Раздел 7.4.4, «Двоичный журнал».

Регистрация обновлений реплики. Установите log_replica_updates=ON, если он ещё не включён. (В MySQL 8.4 это значение по умолчанию.) Члены группы должны регистрировать транзакции, полученные от своих доноров во время присоединения и применённые с помощью репликации, а также регистрировать все транзакции, которые они получают и применяют от группы. Это позволяет Групповой репликации проводить распределённое восстановление путём передачи состояния из двоичного журнала существующего члена группы.

Формат строк двоичного журнала. Установите binlog_format=ROW, если необходимо; в MySQL 8.4 это значение по умолчанию. Групповая репликация полагается на формат репликации на основе строк для согласованного распространения изменений между серверами в группе и извлечения необходимой информации для обнаружения конфликтов между транзакциями, выполняемыми параллельно на различных серверах в группе. Настройка REQUIRE_ROW_FORMAT автоматически добавляется в каналы Групповой репликации для принудительного использования репликации на основе строк при применении транзакций. См. Раздел 19.2.1, «Форматы репликации» и Раздел 19.3.3, «Проверка привилегий репликации».

Включить глобальные идентификаторы транзакций. Установите gtid_mode=ON и enforce_gtid_consistency=ON. Эти настройки не являются значениями по умолчанию. Репликация на основе GTID необходима для Групповой репликации, которая использует глобальные идентификаторы транзакций для отслеживания транзакций, которые были подтверждены на каждом серверном экземпляре в группе. См. Раздел 19.1.3, «Репликация с глобальными идентификаторами транзакций».

Шифрование таблиц по умолчанию. Установите default_table_encryption на одинаковое значение на всех членах группы. Шифрование схемы и табличного пространства по умолчанию может быть включено (ON) или отключено (OFF, по умолчанию), при условии, что настройка одинакова на всех участниках.

Имена таблиц в нижнем регистре. Установите lower_case_table_names на одинаковое значение на всех членах группы. Значение 1 является корректным для использования движка InnoDB, который необходим для Групповой репликации. Обратите внимание, что это значение не является значением по умолчанию на всех платформах.

Многопоточные прикладные программы. Члены Групповой репликации могут быть сконфигурированы как многопоточные реплики, позволяя выполнять транзакции параллельно. Все реплики настраиваются как многопоточные по умолчанию. Значение, отличное от нуля, для replica_parallel_workers, включает многопоточный прикладной модуль на участнике. Значение по умолчанию — 4 параллельных потока прикладной программы; можно указать до 1024 параллельных потоков прикладной программы.

Установление replica_parallel_workers=0 отключает параллельное выполнение и даёт реплике один прикладной поток и нет координационного потока. С этой настройкой replica_parallel_type и replica_preserve_commit_order опции не действуют и игнорируются. Если параллельное выполнение отключено, когда GTID используются на реплике, реплика фактически использует одного параллельного исполнителя, чтобы использовать метод повторного выполнения транзакций без доступа к позициям файла. Однако это поведение ничего не изменяет для пользователя.

Отключенные транзакции XA. MySQL 8.4 и более поздние версии поддерживают отделённые транзакции XA. Отделенная транзакция — это транзакция, которая после подготовки больше не связана с текущей сессией. Это происходит автоматически при выполнении XA PREPARE. Подготовленную транзакцию XA можно подтвердить или отменить с помощью другого подключения, а текущая сессия может затем начать другую транзакцию XA или локальную транзакцию без ожидания завершения только что подготовленной транзакции.

Когда поддержка отделённых транзакций XA включена (xa_detach_on_prepare = ON), любое подключение к этому серверу может перечислить (с помощью XA RECOVER), отменить или подтвердить любую подготовленную транзакцию XA. Кроме того, вы не можете использовать временные таблицы в рамках отделённых транзакций XA.

Вы можете отключить поддержку отделённых транзакций XA, установив xa_detach_on_prepare на OFF, но это не рекомендуется. В частности, если этот сервер настраивается как экземпляр в MySQL групповой репликации, вам следует оставить эту переменную со значением по умолчанию (ON).

См. Раздел 15.3.8.2, «Состояния транзакций XA» для получения дополнительной информации.