Группа может состоять не более чем из 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, «Нахождение первичного узла»