Как настроить групповую репликацию MySQL на Ubuntu 20.04

Введение

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

Групповая репликация – это способ реализации более гибкого и устойчивого к отказам механизма репликации. Этот процесс включает в себя создание пула серверов, каждый из которых участвует в обеспечении правильного копирования данных. Если основной сервер столкнется с проблемами, выборы членов могут выбрать нового основного из группы. Это позволяет оставшимся узлам продолжать работу, даже в случае проблем. Для обеспечения членства, обнаружения сбоев и доставки сообщений используется реализация алгоритма консенсуса Паксоса.

В этом руководстве вы настроите групповую репликацию MySQL с помощью набора из трех серверов Ubuntu 20.04. Обратите внимание, что три – это минимальное количество экземпляров MySQL, которые вам нужно развернуть для групповой репликации в MySQL, а девять – максимальное. При работе с этим руководством у вас будет возможность настроить группу как группу репликации с одним основным или с несколькими основными.

Предварительные требования

Для завершения этого руководства вам потребуется:

• Три сервера, работающих под управлением Ubuntu 20.04. Каждый из них должен иметь неадминистративного пользователя с правами sudo и настроенный брандмауэр с использованием UFW. Следуйте нашему руководству по начальной настройке сервера для Ubuntu 20.04, чтобы настроить каждый сервер.
• Установлен MySQL на каждом сервере. В этом руководстве предполагается, что вы используете последнюю версию MySQL, доступную в репозиториях Ubuntu по умолчанию, которая на момент написания этого текста является версией 8.0.28. Чтобы установить его на всех ваших серверах, следуйте нашему руководству по установке MySQL на Ubuntu 20.04 для каждого компьютера.

Чтобы помочь сохранить ясность, в этом руководстве три сервера будут называться member1, member2 и member3. В примерах в этом руководстве этим участникам будут соответствовать следующие IP-адреса:

Любые команды, которые необходимо выполнить на member1, будут иметь синий фон, например, так:

Точно так же, любые команды, которые необходимо выполнить на member2, будут иметь красный фон:

А любые команды, которые необходимо выполнить на member3, будут иметь зеленый фон:

Наконец, любые команды, которые необходимо выполнить на каждом из трех серверов, будут иметь стандартный фон:

Шаг 1 — Генерация UUID для идентификации группы MySQL

Прежде чем открывать файл конфигурации MySQL для настройки параметров групповой репликации, вам нужно сгенерировать UUID, который вы сможете использовать для идентификации создаваемой вами группы MySQL.

На member1 используйте команду uuidgen, чтобы сгенерировать допустимый UUID для группы:

uuidgen

Output
168dcb64-7cce-473a-b338-6501f305e561

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

Шаг 2 — Настройка групповой репликации в файле конфигурации MySQL

Теперь вы готовы изменить файл конфигурации MySQL. Откройте основной файл конфигурации MySQL на каждом сервере MySQL с помощью выбранного вами текстового редактора. Здесь мы воспользуемся nano:

sudo nano /etc/mysql/my.cnf

На Ubuntu MySQL устанавливается сразу с несколькими различными файлами, которые можно использовать для определения различных конфигурационных изменений. По умолчанию файл my.cnf используется только для подключения дополнительных файлов из подкаталогов. Вам придется добавить свою собственную конфигурацию ниже строк !includedir. Это позволит вам переопределить любые настройки из включенных файлов.

Для начала, начните новый раздел, включив заголовок [mysqld], а затем добавьте необходимые настройки для включения групповой репликации, как показано в следующем примере. Обратите внимание, что эти настройки изменены от минимальных настроек, необходимых для групповой репликации, описанных в официальной документации MySQL. Префикс loose- позволяет MySQL обрабатывать опции, которые он не распознает, грациозно и без сбоев. Вам скоро придется заполнить и настроить некоторые из этих настроек:

. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

[mysqld]

# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1

# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""

# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON

# Host specific replication configuration
server_id = 
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""

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

Основные настройки групповой репликации

Первый раздел содержит общие настройки, не требующие изменений, необходимых для групповой репликации:

. . .
# Общие настройки репликации
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

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

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

Общие настройки групповой репликации

Второй раздел настраивает общие настройки для группы. Вам придется настроить это один раз, а затем использовать те же настройки на каждом из ваших узлов. Конкретно, вы должны добавить UUID группы (который вы создали на предыдущем этапе), список авторизованных участников группы и участков (seed members), с которыми нужно связаться, чтобы получить начальные данные при присоединении к группе.

Установите значение loose-group_replication_group_name на UUID-значение, которое вы сгенерировали ранее с помощью команды uuidgen. Убедитесь, что вы помещаете UUID между пустой парой двойных кавычек.

Затем установите loose-group_replication_ip_whitelist на список всех IP-адресов вашего сервера MySQL, разделенных запятыми. Настройка loose-group_replication_group_seeds должна быть почти такой же, как и белый список, но должна добавлять указанный порт групповой репликации в конец каждого участника. Для целей этого руководства используйте рекомендованный порт групповой репликации, 33061:

. . .
# Общая конфигурация групповой репликации
loose-group_replication_group_name = "168dcb64-7cce-473a-b338-6501f305e561"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .

Этот раздел должен быть одинаковым на каждом из ваших серверов MySQL, поэтому обязательно аккуратно скопируйте его на каждый сервер.

Выбор одиночного первичного или множественного первичного

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

Если вы хотите настроить многопримарную группу, раскомментируйте директивы loose-group_replication_single_primary_mode и loose-group_replication_enforce_update_everywhere_checks. Это настроит многопримарную группу. Для группы с единственным первичным узлом оставьте эти две строки закомментированными:

. . .
# Режим одиночного или многопримарного узла? Раскомментируйте эти две строки
# для многопримарного режима, в котором любой хост может принимать записи
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .

Эти настройки должны быть одинаковыми на каждом из ваших серверов MySQL.

Вы можете изменить эту настройку позже, но после этого вам придется перезапустить каждый участник вашей группы MySQL. Для перехода на новую конфигурацию вам придется остановить каждый из экземпляров MySQL в группе, запустить каждый участник с новыми настройками, а затем повторно проинициализировать репликацию группы. Это не повлияет на ваши данные, но потребует небольшого периода простоя.

Настройки конфигурации для каждого хоста

Четвертый раздел содержит настройки, которые будут отличаться на каждом из серверов, включая:

• Идентификатор сервера
• Адрес привязки
• Адрес для сообщения другим участникам
• Локальный адрес репликации и порт прослушивания

Директива server_id должна быть установлена ​​в уникальное число. Для первого участника установите это значение равным 1 и увеличивайте номер для каждого дополнительного хоста. Установите bind-address и report_host на соответствующий IP-адрес сервера, чтобы экземпляр MySQL мог прослушивать внешние подключения и корректно сообщать свой адрес другим хостам. Директива loose-group_replication_local_address также должна быть установлена ​​на текущий IP-адрес сервера с портом групповой репликации (33061), добавленным к IP-адресу.

Вот пример этой части конфигурации для member1 с использованием его примерного IP-адреса:

. . .
# Специфичная для хоста конфигурация репликации
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"

Выполните этот процесс на каждом из ваших серверов MySQL. Вот конфигурация для member2:

. . .
# Специфичная для хоста конфигурация репликации
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"

А вот конфигурация для member3:

. . .
# Специфичная для хоста конфигурация репликации
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"

Обязательно обновите каждый выделенный IP-адрес на IP-адрес сервера, конфигурацию которого вы редактируете.

Когда закончите, убедитесь, что общие настройки репликации одинаковы на каждом хосте, а специфичные для хоста настройки настроены индивидуально для каждого хоста. Сохраните и закройте файл на каждом хосте, когда закончите. Если вы использовали nano для редактирования файла, вы можете сделать это, нажав CTRL + X, Y, а затем ENTER.

Каждый из файлов конфигурации MySQL на ваших серверах теперь содержит директивы, необходимые для инициализации групповой репликации MySQL. Чтобы применить новые настройки к экземпляру MySQL, перезапустите службу на каждом из ваших серверов с помощью следующей команды:

sudo systemctl restart mysql

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

Шаг 3 — Обновление правил UFW на каждом сервере

Предполагая, что вы следовали предварительному руководству по начальной настройке сервера, вы настроили брандмауэр на каждом из серверов, на которых установлен MySQL, и разрешили доступ для профиля UFW OpenSSH. Это важная мера безопасности, поскольку эти брандмауэры в настоящее время блокируют соединения с любым портом на ваших серверах, за исключением подключений ssh, представленных ключами, соответствующими тем, что находятся в соответствующем файле authorized_keys на каждом сервере.

В файле конфигурации MySQL вы настроили службу на прослушивание внешних соединений на порту по умолчанию 3306. Вы также определили 33061 как порт, который должны использовать члены для согласования репликации.

На каждом из ваших серверов-участников вам нужно открыть доступ к этим портам для других участников этой группы, чтобы они могли общаться между собой. Чтобы открыть доступ к этим портам на участнике1 для участника2, выполните следующие команды ufw на участнике1:

sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Обязательно замените ip_сервера_участника2 на фактический IP-адрес вашего участника2. Затем, чтобы открыть те же порты для участника3, выполните эти команды:

sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Затем обновите правила брандмауэра для других двух серверов. Выполните следующие команды на участнике2, убедившись, что вы измените IP-адреса на соответствующие участника1 и участника3:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Наконец, выполните эти две команды на участнике3. Снова убедитесь, что вы вводите правильные IP-адреса для каждого сервера:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

После добавления этих правил UFW каждому из ваших трех экземпляров MySQL будет разрешен доступ к портам, используемым MySQL на других двух серверах.

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

Шаг 4 — Настройка пользователей репликации и включение плагина групповой репликации

Для установления соединений с другими серверами в группе репликации каждый экземпляр MySQL должен иметь выделенного пользователя репликации.

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

sudo mysql

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

SET SQL_LOG_BIN=0;

Теперь вы можете выполнить оператор CREATE USER, чтобы создать своего пользователя репликации. Выполните следующую команду, которая создает пользователя с именем repl. Эта команда указывает, что пользователь репликации должен подключаться с использованием SSL. Также убедитесь, что используете безопасный пароль вместо password, когда создаете этого пользователя репликации:

CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;

Затем предоставьте новому пользователю привилегии репликации на сервере:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

Затем сбросьте привилегии для внедрения изменений:

FLUSH PRIVILEGES;

После этого снова включите двоичное ведение журнала, чтобы возобновить нормальную работу:

SET SQL_LOG_BIN=1;

Затем установите канал group_replication_recovery, чтобы использовать вашего нового пользователя репликации и его связанный пароль. Затем каждый сервер будет использовать эти учетные данные для аутентификации в группе:

CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

После создания пользователя репликации вы можете включить плагин group_replication, чтобы подготовиться к инициализации группы:

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Убедитесь, что плагин активен, выполнив следующую команду:

SHOW PLUGINS;

Плагин group_replication будет отображаться внизу списка, так как это последний добавленный плагин:

Output
+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
|                            |          |                    |                      |         |
| . . .                      | . . .    | . . .              | . . .                | . . .   |
|                            |          |                    |                      |         |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)

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

Шаг 5 — Запуск групповой репликации

Теперь, когда на каждом сервере MySQL настроен пользователь репликации и включен плагин групповой репликации, вы можете начать поднимать вашу группу.

Загрузка первого узла

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

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

Если установлена переменная group_replication_bootstrap_group, то член группы получает сигнал, что не должен ожидать получения информации от сверстников, а вместо этого должен установить новую группу и избрать себя основным членом. Эту переменную можно включить следующей командой:

SET GLOBAL group_replication_bootstrap_group=ON;

После этого можно запустить репликацию для начального члена группы:

START GROUP_REPLICATION;

После этого можно снова установить переменную group_replication_bootstrap_group в значение OFF, так как это подходит только в том случае, когда нет существующих членов группы:

SET GLOBAL group_replication_bootstrap_group=OFF;

Группа будет запущена с этим сервером в качестве единственного участника. Это можно проверить, проверив записи в таблице replication_group_members в базе данных performance_schema:

SELECT * FROM performance_schema.replication_group_members;

Этот запрос вернет одну строку, представляющую текущий хост:

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
1 row in set (0.00 sec)

Значение ONLINE для MEMBER_STATE указывает на то, что этот узел полностью оперативен в группе.

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

Начните с создания образцовой базы данных с названием playground:

CREATE DATABASE playground;

Следующая команда создает пример таблицы с именем equipment в базе данных playground:

CREATE TABLE playground.equipment ( 
id INT NOT NULL AUTO_INCREMENT,
type VARCHAR(50),
quant INT,
color VARCHAR(25),
PRIMARY KEY(id)
);

Эта таблица содержит четыре следующих столбца:

• id: Этот столбец будет содержать целочисленные значения, которые автоматически увеличиваются, что означает, что вам не нужно указывать значения для этого столбца при загрузке таблицы с образцовыми данными
• type: Этот столбец будет содержать строковые значения, описывающие, какой тип оборудования для детских площадок представляет собой данная строка
• quant: Этот столбец будет содержать целочисленные значения, представляющие количество данного типа оборудования для детских площадок
• color: Этот столбец будет содержать строковые значения, указывающие цвет данного оборудования

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

Наконец, выполните следующую команду, чтобы вставить одну строку данных в таблицу:

INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

Запросите таблицу, чтобы убедиться, что данные были введены правильно:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

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

Запуск оставшихся узлов

Затем запустите групповую репликацию на члене2. Поскольку у вас уже есть активный член, вам не нужно инициализировать группу, и этот член может присоединиться сразу:

START GROUP_REPLICATION;

На члене3 запустите групповую репликацию таким же образом:

START GROUP_REPLICATION;

Проверьте список участников еще раз на любом из трех серверов. На этот раз в выводе будет три сервера:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

Все члены должны иметь значение MEMBER_STATE ONLINE. Для новой группы, если один из узлов перечислен как RECOVERING более нескольких секунд, это обычно свидетельствует о том, что произошла ошибка или что-то было неправильно настроено. Проверьте журналы по адресу /var/log/mysql/error.log, чтобы получить дополнительную информацию о том, что пошло не так.

Затем проверьте, была ли скопирована информация о тестовой базе данных на новых участниках:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.01 sec)

Если данные доступны на новых участниках, это означает, что групповая репликация работает правильно.

Шаг 6 — Проверка возможности записи новых участников группы

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

Проверка записей в среде с одним основным узлом

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

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

Значением запроса будет ИД_УЧАСТНИКА, который вы можете сопоставить с хостом, выполнив запрос списка участников группы, как вы делали раньше:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Как показывает этот пример вывода, хост на 203.0.113.1 — участник1 — в данный момент является основным сервером. Если вы попытаетесь выполнить запись в базу данных с другого участника, операция завершится ошибкой:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

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

Проверка записей в среде с несколькими основными узлами

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

Вы можете повторно проверить, что ваша группа работает в режиме множественного основного узла, проверив значение переменной group_replication_primary_member:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| group_replication_primary_member |       |
+----------------------------------+-------+
1 row in set (0.02 sec)

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

Проверьте это на участнике2, попытавшись записать какие-либо данные в таблицу equipment:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
Query OK, 1 row affected (0.00 sec)

Участник2 успешно завершил операцию записи без ошибок.

На участнике3 выполните следующий запрос, чтобы проверить, был ли добавлен новый элемент:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+--------+
| id | type  | quant | color  |
+----+-------+-------+--------+
|  1 | slide |     2 | blue   |
|  2 | swing |    10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)

Это подтверждает, что запись от участника2 успешно реплицирована.

Теперь протестируйте возможность записи на участнике3, запустив следующий запрос INSERT:

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");

Output
Query OK, 1 row affected (0.02 sec)

Вернитесь на участника1, чтобы убедиться, что операции записи от обоих новых участников были реплицированы обратно:

SELECT * FROM playground.equipment;

Output
+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  1 | slide  |     2 | blue   |
|  2 | swing  |    10 | yellow |
|  3 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.01 sec)

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

Шаг 7 — Восстановление работы группы

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

На member1 установите переменную group_replication_bootstrap_group в значение ON:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;

Затем инициализируйте группу:

START GROUP_REPLICATION;

После этого можно вернуть переменной group_replication_bootstrap_group значение OFF:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

Как только первый участник запустит группу, другие участники могут присоединиться:

START GROUP_REPLICATION;

Следуйте этому процессу для каждого дополнительного участника:

START GROUP_REPLICATION;

Группа должна теперь быть онлайн со всеми доступными участниками:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

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

Шаг 8 — Присоединение к группе автоматически при запуске MySQL

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

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

Во-вторых, включение этой настройки при первоначальной настройке группы может быть вредным. Когда нет существующей группы для присоединения, процесс MySQL будет долго запускаться, потому что он будет пытаться связаться с другими, несуществующими участниками для инициализации. Только после длительного ожидания он откажется и начнет работать нормально. Затем вам придется использовать процедуру, описанную выше, для настройки группы.

Учитывая вышеизложенные оговорки, если вы хотите настроить узлы для автоматического присоединения к группе при запуске MySQL, откройте основной файл конфигурации MySQL:

sudo nano /etc/mysql/my.cnf

Внутри найдите переменную loose-group_replication_start_on_boot и установите ее значение в ON:

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

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

Заключение

После завершения этого учебника вы узнали, как настроить групповую репликацию MySQL между тремя серверами Ubuntu 20.04. В случае настройки с одним основным участником участники автоматически выбирают основного участника, способного записывать, когда это необходимо. В случае настройки с несколькими основными участниками любой участник может выполнять записи и обновления.

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