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

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

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

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

Вы предварительно настраиваете учетные данные канала восстановления Group Replication с помощью оператора CHANGE MASTER TO.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Group Replication разработана для обеспечения высокодоступных наборов реплик; данные и записи дублируются на каждом члене в группе. Для масштабирования сверх возможностей одной системы вам нужно использовать фреймворк оркестрации и фрагментации (шардинга), основанный на нескольких группах 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). В случае изменения переменной relay_log или в случае изменения имени хоста, когда опция не задана, возможны ошибки. См. Раздел 16.2.4.1, «Лог репликации (relay log)» для процедуры восстановления в такой ситуации. Альтернативный способ решения проблемы, специфичный для 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 не изменяет их.

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