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 | 9.2.0 | XCom |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | s2 | 3306 | ONLINE | SECONDARY | 9.2.0 | 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: 9.2.0-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 USERrpl_user@'%' IDENTIFIED BY 'password';GRANT REPLICATION SLAVE ON *.* TOrpl_user@'%';GRANT CONNECTION_ADMIN ON *.* TOrpl_user@'%';GRANT BACKUP_ADMIN ON *.* TOrpl_user@'%';GRANT GROUP_REPLICATION_STREAM ON *.* TOrpl_user@'%';FLUSH PRIVILEGES;SET SQL_LOG_BIN=1;Если вы предоставляете учетные данные пользователя с помощью
CHANGE REPLICATION SOURCE TO, выполните следующую команду после этого: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 | 9.2.0 | XCom |
| group_replication_applier | 7eb217ff-6df3-11e6-966c-00212844f856 | s3 | 3306 | ONLINE | SECONDARY | 9.2.0 | XCom |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 | s2 | 3306 | ONLINE | SECONDARY | 9.2.0 | 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: 9.2.0-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 |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
© 2025 Oracle
Licensed under the GPLv2 License.