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

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

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

Сеть IPv4. Двигатель групповой коммуникации, используемый MySQL Group Replication, поддерживает только IPv4. Поэтому групповая репликация требует инфраструктуры сети IPv4.

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

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

Активный бинарный журнал. Установите --log-bin[=log_file_name]. MySQL Group Replication реплицирует содержимое бинарного журнала, поэтому бинарный журнал должен быть включён для его работы. Этот параметр включён по умолчанию. См. Раздел 5.4.4, «Бинарный журнал».

Записанные обновления реплики. Установите --log-slave-updates. Серверам необходимо регистрировать бинарные журналы, которые применяются с помощью прикладного модуля репликации. Серверы в группе должны регистрировать все транзакции, которые они получают и применяют из группы. Это необходимо, поскольку восстановление выполняется, полагаясь на бинарные журналы от участников группы. Следовательно, копии каждой транзакции должны существовать на каждом сервере, даже для тех транзакций, которые не были инициированы на самом сервере.

Формат бинарного журнала. Установите --binlog-format=row. Групповая репликация полагается на формат репликации на основе строк для согласованного распространения изменений между серверами в группе. Она полагается на инфраструктуру на основе строк, чтобы извлечь необходимую информацию для обнаружения конфликтов между транзакциями, которые выполняются одновременно на разных серверах в группе. См. Раздел 16.2.1, «Форматы репликации».

Суммы проверок бинарного журнала отключены. Установите --binlog-checksum=NONE. Из-за ограничения в проекте, групповая репликация не может использовать суммы проверок событий репликации, и они должны быть отключены.

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

Репозитории информации о репликации. Установите master_info_repository=TABLE и relay_log_info_repository=TABLE. Прикладному модулю репликации необходимо, чтобы исходные и метаданные реплики были записаны в таблицы mysql.slave_master_info и mysql.slave_relay_log_info системы. Это гарантирует, что плагин Group Replication имеет согласованную возможность восстановления и транзакционное управление метаданными репликации. См. Раздел 16.2.4.2, «Репозитории метаданных репликации».

Извлечение набора операций записи транзакции. Установите --transaction-write-set-extraction=XXHASH64 для того, чтобы при сборе строк для их регистрации в бинарном журнале, сервер также собирал набор операций записи. Набор операций записи основан на первичных ключах каждой строки и является упрощенным и компактным представлением тега, который уникально идентифицирует строку, которая была изменена. Затем этот тег используется для обнаружения конфликтов.

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

Многопотоковые прикладные модули. Участники групповой репликации могут быть настроены как многопотоковые реплики, что позволяет выполнять транзакции параллельно. Значение, отличное от нуля, для slave_parallel_workers активирует многопотоковый прикладной модуль на участнике, и до 1024 потоков прикладного модуля могут быть указаны. Если вы это сделаете, также необходимы следующие параметры:

Установка slave_parallel_workers=0 отключает параллельное выполнение и предоставляет реплике один поток прикладного модуля и без потока координатора. С этой установкой параметры slave_parallel_type и slave_preserve_commit_order не имеют эффекта и игнорируются.