Группа может состоять не более чем из 9 серверов. Попытка добавить другой сервер в группу с 9 членами приводит к отклонению запроса на присоединение. Это ограничение установлено на основе тестов и бенчмарков как безопасная граница, при которой группа работает надёжно в стабильной локальной сети.

Серверы в группе подключаются к другим серверам в группе с помощью установления соединения TCP «равноправный с равным». Эти соединения используются только для внутренней связи и обмена сообщениями между серверами в группе. Этот адрес настраивается переменной group_replication_local_address.

Флаг bootstrap указывает члену создать группу и действовать в качестве начального сервера-затравки. Второму члену, присоединяющемуся к группе, необходимо попросить члена, который запустил группу, динамически изменить конфигурацию, чтобы его можно было добавить в группу.

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

Вы можете постоянно установить учётные данные пользователя как учётные данные для канала group_replication_recovery, используя оператор CHANGE REPLICATION SOURCE TO. Вы можете указать их в операторе START GROUP_REPLICATION каждый раз при запуске Group Replication.

Учётные данные пользователя, установленные с помощью CHANGE REPLICATION SOURCE TO, хранятся в открытом виде в хранилищах репликации метаданных на сервере, но учётные данные пользователя, указанные в операторе START GROUP_REPLICATION, сохраняются только в памяти и удаляются оператором STOP GROUP_REPLICATION или при выключении сервера. Использование START GROUP_REPLICATION для указания учётных данных пользователя, таким образом, помогает защитить серверы Group Replication от несанкционированного доступа. Однако этот метод несовместим с автоматическим запуском Group Replication, как указано в системной переменной group_replication_start_on_boot. Дополнительную информацию см. в разделе Раздел 20.6.3.1, «Защита учётных данных пользователя для распределённого восстановления».

Не напрямую, но MySQL Group Replication — это полное решение для репликации без общего состояния, где все серверы в группе реплицируют одинаковое количество данных. Поэтому, если один член группы записывает N байт в хранилище в результате операции подтверждения транзакции, то примерно N байт записывается в хранилище и на других членах, поскольку транзакция реплицируется повсюду.

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

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

Подводя итог, вы можете масштабировать обработку, распределяя конфликтно-безопасные транзакции по разным членам группы. И вы, вероятно, сможете масштабировать небольшую часть операций ввода/вывода, так как удалённые серверы получают только необходимые изменения для чтения-модификации-записи в устойчивое хранилище.

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

Также объём памяти и потребление ЦП больше, поскольку выполняется более сложная работа для части синхронизации серверов и для группового обмена сообщениями.

Да, но подключение между каждым членом должно быть надёжным и иметь соответствующую производительность. Для оптимальной производительности необходимы низкая задержка и высокая пропускная способность сетевых соединений.

Если проблема только в пропускной способности сети, то можно использовать Раздел 20.7.4, «Сжатие сообщений», чтобы снизить требования к пропускной способности. Однако если сеть теряет пакеты, что приводит к повторной передаче и более высокой общей задержке, то и пропускная способность, и задержка ухудшаются.

Это зависит от причины проблемы с подключением. Если проблема с подключением временная и повторное подключение происходит достаточно быстро, чтобы детектор отказов не смог его определить, то сервер может не быть удалён из группы. Если это «длительная» проблема с подключением, то детектор отказов в конечном итоге заподозрит проблему, и сервер будет удалён из группы.

Доступно две настройки для повышения шансов на то, что член останется в группе или снова присоединится к ней:

Если сервер исключён из группы, и все попытки автоматического присоединения не увенчались успехом, вам необходимо повторно присоединиться к нему вручную (или иметь скрипт, делающий это автоматически).

Если член становится неактивным, другие члены удаляют его из конфигурации группы. На практике это может произойти, когда член упал или произошло отключение сети.

Ошибка обнаруживается после истечения заданного тайм-аута для данного члена и создания новой конфигурации без неактивного члена в ней.

Нет метода для определения правил, когда нужно автоматически исключать членов из группы. Вам нужно выяснить, почему член отстаёт, и исправить это или удалить члена из группы. В противном случае, если сервер настолько медленный, что вызывает контроль потока, вся группа также замедляется. Контроль потока можно настроить в соответствии с вашими потребностями.

Нет, в группе нет специального члена, ответственного за инициирование переконфигурации.

Любой член может заподозрить, что есть проблема. Все члены должны (автоматически) согласиться, что данный член вышел из строя. Один член отвечает за исключение его из группы, инициировав переконфигурацию. Какой член отвечает за исключение члена, не подлежит вашему контролю или установке.

Group Replication разработан для обеспечения высокодоступных реплик; данные и записи дублируются на каждом члене группы. Для масштабирования, превышающего возможности одной системы, вам требуется механизм оркестрации и фрагментации, построенный на основе нескольких наборов Group Replication, где каждый набор реплик поддерживает и управляет заданным фрагментом или разделом вашего полного набора данных. Такая структура, часто называемая “фрагментированным кластером”, позволяет линейно масштабировать чтение и запись без ограничений.

Если SELinux включен, что можно проверить с помощью sestatus -v, вам необходимо включить использование порта связи Group Replication. См. Установка контекста порта TCP для Group Replication.

Если iptables включен, вам необходимо открыть порт Group Replication для связи между машинами. Чтобы увидеть действующие правила на каждой машине, выполните iptables -L. Предполагая, что настроенный порт — 33061, включите связь по необходимому порту, выполнив iptables -A INPUT -p tcp --dport 33061 -j ACCEPT.

Каналы репликации, используемые Group Replication, ведут себя так же, как каналы репликации, используемые в асинхронной репликации от источника к реплике, и, таким образом, полагаются на журнал ретрансляции. В случае изменения переменной relay_log или при отсутствии настройки и изменении имени хоста возможны ошибки. Обратитесь к Разделу 19.2.4.1, «Журнал ретрансляции» для процедуры восстановления в такой ситуации. В качестве альтернативы, другой способ решения проблемы, специфичный для Group Replication, заключается в выполнении оператора STOP GROUP_REPLICATION, а затем оператора START GROUP_REPLICATION для перезапуска экземпляра. Плагин Group Replication снова создает канал group_replication_applier.

Group Replication использует два адреса привязки, чтобы разделить сетевой трафик между адресом SQL, используемым клиентами для связи с членом, и group_replication_local_address, используемым внутри группами для связи. Например, предположим сервер с двумя сетевыми интерфейсами, назначенными сетевым адресам 203.0.113.1 и 198.51.100.179. В такой ситуации вы можете использовать 203.0.113.1:33061 для внутреннего адреса сети группы, установив group_replication_local_address=203.0.113.1:33061. Затем вы можете использовать 198.51.100.179 для hostname и 3306 для port. Клиентские приложения SQL будут подключаться к члену по адресу 198.51.100.179:3306. Это позволяет настроить разные правила на разных сетях. Аналогично, внутренняя связь группы может быть отделена от сетевого подключения, используемого для клиентских приложений, для повышения безопасности.

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

Это означает, что любое значение, настроенное вами с помощью имени хоста, такое как сетевой адрес SQL или адрес семян группы, должно быть полным квалифицированным именем и разрешаемым каждым членом группы. Это можно обеспечить, например, с помощью DNS, правильно настроенных файлов /etc/hosts или других локальных процессов. Если вы хотите настроить значение MEMBER_HOST на сервере, укажите его с помощью параметра --report-host на сервере до присоединения его к группе.

Чтобы настроить MEMBER_PORT на сервере, укажите его с помощью переменной системы report_port.

При запуске Group Replication на сервере значение auto_increment_increment изменяется на значение group_replication_auto_increment_increment, которое по умолчанию равно 7, а значение auto_increment_offset изменяется на идентификатор сервера. Изменения отменяются при остановке Group Replication. Эти настройки предотвращают выбор дублирующихся значений автоинкремента для записей на членах группы, что приводит к откату транзакций. Значение автоинкремента по умолчанию 7 для Group Replication представляет баланс между количеством используемых значений и максимальным допустимым размером группы репликации (9 членов).

Изменения выполняются и отменяются только если auto_increment_increment и auto_increment_offset имеют значения по умолчанию (1 в обоих случаях). Если их значения уже изменены с предустановленных, Group Replication их не изменяет. Переменные системы также не изменяются, когда Group Replication находится в режиме единого первичного сервера, где запись выполняет только один сервер.

Если группа работает в режиме единого первичного сервера, может быть полезно выяснить, какой член является первичным. См. Раздел 20.1.3.1.2, «Поиск первичного сервера»