Двигатель хранения 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 9.2 двоичный журнал включён по умолчанию. Вы можете дополнительно указать имена файлов двоичного журнала, используя --log-bin[=log_file_name]. Репликация группы копирует содержимое двоичного журнала, поэтому для его работы двоичный журнал должен быть включён. См. Раздел 7.4.4, «Двоичный журнал».

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

Формат строк двоичного журнала. При необходимости установите binlog_format=ROW; в MySQL 9.2 это значение по умолчанию. Репликация группы полагается на формат репликации на основе строк для согласованного распространения изменений между серверами в группе и извлечения необходимой информации для обнаружения конфликтов между транзакциями, которые выполняются одновременно на разных серверах в группе. Значение для 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 9.2 и более поздние версии поддерживают отключенные 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-транзакций» для получения дополнительной информации.