20.2.1.6 Adding Instances to the Group — MySQL 8.4

20.2.1.6 Добавление экземпляров в группу

На данном этапе группа содержит одного члена, сервер s1, который содержит данные. Теперь необходимо расширить группу, добавив два других ранее настроенных сервера.

20.2.1.6.1 Добавление второго экземпляра

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

[mysqld]

#
# Disable other storage engines
#
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

#
# Replication configuration parameters
#
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON

#
# Group Replication configuration
#
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s2:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group= off

Аналогично процедуре для сервера s1, после создания файла опций, запускается сервер. Затем необходимо настроить учетные данные для распределенного восстановления следующим образом. Действия аналогичны тем, что использовались при настройке сервера s1, так как пользователь общий для группы. Этот член должен иметь тот же пользователь для репликации, настроенный в разделе 20.2.1.3 «Учетные данные пользователя для распределенного восстановления». Если вы полагаетесь на распределенное восстановление для настройки пользователя на всех членах, когда s2 подключается к источнику s1, пользователь для репликации реплицируется или клонируется на s1. Если двоичный лог не был включен при настройке учетных данных пользователя на s1, и операция удаленного клонирования не используется для передачи состояния, необходимо создать пользователя для репликации на s2. В этом случае подключитесь к s2 и выполните:

SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%';
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

Если вы предоставляете учетные данные пользователя с помощью CHANGE REPLICATION SOURCE TO, выполните следующее утверждение после этого:

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

Подсказка

Если используется плагин проверки подлинности SHA-2 с кэшированием (по умолчанию), см. раздел 20.6.3.1.1 «Пользователь репликации с плагином проверки подлинности SHA-2 с кэшированием».

При необходимости установите плагин Group Replication, см. раздел 20.2.1.4 «Запуск Group Replication».

Запустите Group Replication, и s2 начнет процесс присоединения к группе.

mysql> START GROUP_REPLICATION;

Если вы предоставляете учетные данные пользователя для распределенного восстановления в рамках START GROUP_REPLICATION, вы можете сделать это так:

mysql> START GROUP_REPLICATION USER='rpl_user', PASSWORD='password';

В отличие от предыдущих шагов, которые были одинаковыми для s1, здесь есть разница, заключающаяся в том, что вам не нужно выполнять загрузку группы, так как группа уже существует. Другими словами, на s2 group_replication_bootstrap_group установлено значение OFF, и вы не выполняете SET GLOBAL group_replication_bootstrap_group=ON; перед запуском Group Replication, потому что группа уже создана и загружена сервером s1. На данном этапе сервер s2 только нужно добавить в уже существующую группу.

Подсказка

При успешном запуске Group Replication и присоединении сервера к группе, проверяется переменная super_read_only. Установив super_read_only в значение ON в файле конфигурации члена, можно гарантировать, что серверы, которые завершаются при запуске Group Replication по какой-либо причине, не будут принимать транзакции. Если сервер должен присоединиться к группе как экземпляр чтения/записи, например, как основной в группе с одним главным или как член группы с несколькими главными, когда super_read_only установлено в ON, то оно устанавливается в OFF при присоединении к группе.

Проверка таблицы performance_schema.replication_group_members снова показывает, что в группе теперь два ONLINE сервера.

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 |   s1        |        3306 | ONLINE       | PRIMARY     | 8.4.4          | XCom                       |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 |   s2        |        3306 | ONLINE       | SECONDARY   | 8.4.4          | XCom                       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+

Когда s2 пытался присоединиться к группе, раздел 20.5.4 «Распределенное восстановление» гарантировал, что s2 применил те же транзакции, что и s1. После завершения этого процесса s2 смог присоединиться к группе как член, и на данном этапе он отмечен как ONLINE. Другими словами, он должен был автоматически догнать сервер s1. После того, как s2 стал ONLINE, он начинает обрабатывать транзакции с группой. Проверьте, что s2 действительно синхронизировался с сервером s1 следующим образом:

mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+

mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+

mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |    4 | Format_desc    |         2 |         123 | Server ver: 8.4.4-log, Binlog ver: 4                              |
| binlog.000001 |  123 | Previous_gtids |         2 |         150 |                                                                    |
| binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
| binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
| binlog.000001 |  646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 |  770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
| binlog.000001 |  831 | Query          |         1 |         890 | BEGIN                                                              |
| binlog.000001 |  890 | Table_map      |         1 |         933 | table_id: 108 (test.t1)                                            |
| binlog.000001 |  933 | Write_rows     |         1 |         975 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 |  975 | Xid            |         1 |        1002 | COMMIT /* xid=30 */                                                |
| binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
| binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
| binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
| binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+

Как показано выше, второй сервер был добавлен в группу, и он автоматически реплицировал изменения с сервера s1. Другими словами, транзакции, применённые на s1 до момента присоединения s2 к группе, были реплицированы на s2.

20.2.1.6.2 Добавление дополнительных экземпляров

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

Создайте файл конфигурации.

[mysqld]

#
# Disable other storage engines
#
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

#
# Replication configuration parameters
#
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON

#
# Group Replication configuration
#
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "s3:33061"
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"
group_replication_bootstrap_group= off

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

SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%';
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user',
    ->   SOURCE_PASSWORD='password'
    ->   FOR CHANNEL 'group_replication_recovery';

Установите плагин Group Replication, если это необходимо:
```
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
```
Запустите Group Replication:
```
mysql> START GROUP_REPLICATION;
```
Если вы предоставляете учетные данные пользователя для распределенного восстановления в START GROUP_REPLICATION, вы можете сделать это так:
```
mysql> START GROUP_REPLICATION USER='rpl_user', PASSWORD='password';
```

На этом этапе сервер s3 запущен, присоединился к группе и догнал другие серверы в группе. Консультация таблицы performance_schema.replication_group_members подтверждает это.

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 |   s1        |        3306 | ONLINE       | PRIMARY     | 8.4.4          | XCom                       |
| group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 |   s3        |        3306 | ONLINE       | SECONDARY   | 8.4.4          | XCom                       |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 |   s2        |        3306 | ONLINE       | SECONDARY   | 8.4.4          | XCom                       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+

Выполнение этого же запроса на серверах s2 или s1 дает тот же результат. Также можно проверить, что сервер s3 догнал:

mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+

mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+

mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |    4 | Format_desc    |         3 |         123 | Server ver: 8.4.4-log, Binlog ver: 4                              |
| binlog.000001 |  123 | Previous_gtids |         3 |         150 |                                                                    |
| binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'  |
| binlog.000001 |  211 | Query          |         1 |         270 | BEGIN                                                              |
| binlog.000001 |  270 | View_change    |         1 |         369 | view_id=14724832985483517:1                                        |
| binlog.000001 |  369 | Query          |         1 |         434 | COMMIT                                                             |
| binlog.000001 |  434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2'  |
| binlog.000001 |  495 | Query          |         1 |         585 | CREATE DATABASE test                                               |
| binlog.000001 |  585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3'  |
| binlog.000001 |  646 | Query          |         1 |         770 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 |  770 | Gtid           |         1 |         831 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4'  |
| binlog.000001 |  831 | Query          |         1 |         890 | BEGIN                                                              |
| binlog.000001 |  890 | Table_map      |         1 |         933 | table_id: 108 (test.t1)                                            |
| binlog.000001 |  933 | Write_rows     |         1 |         975 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 |  975 | Xid            |         1 |        1002 | COMMIT /* xid=29 */                                                |
| binlog.000001 | 1002 | Gtid           |         1 |        1063 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5'  |
| binlog.000001 | 1063 | Query          |         1 |        1122 | BEGIN                                                              |
| binlog.000001 | 1122 | View_change    |         1 |        1261 | view_id=14724832985483517:2                                        |
| binlog.000001 | 1261 | Query          |         1 |        1326 | COMMIT                                                             |
| binlog.000001 | 1326 | Gtid           |         1 |        1387 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6'  |
| binlog.000001 | 1387 | Query          |         1 |        1446 | BEGIN                                                              |
| binlog.000001 | 1446 | View_change    |         1 |        1585 | view_id=14724832985483517:3                                        |
| binlog.000001 | 1585 | Query          |         1 |        1650 | COMMIT                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+