Как перейти с Galera кластер на MySQL Group Replication

В этой статье я покажу как можно осуществить онлайн миграцию с кластера Galera из трех нод (в этом случае используется PXC 5.7.14) на MySQL Group Replication кластер из трех нод (MySQL Community 5.7.17)

Перед переходом на Group Replication не забудьте убедиться, что ваше приложение соответствует следующим требованиям и ограничениям. После проверки можно начинать!

Давайте сначала рассмотрим текущую ситуацию:

У нас есть приложение (sysbench 0.5), которое читает и пишет в Galera кластер (Percona XtraDB Cluster 5.7.14) через ProxySQL. Запись идет на все ноды (Multi-Master), и мы хотим получить тоже самое на кластере MySQL Group Replication, используя Multi-Primary Group.

Эта команда используется для имитации нашего приложения:

while true; do sysbench --test=/usr/share/doc/sysbench/tests/db/oltp.lua \
--mysql-host=127.0.0.1 --mysql-port=6033 --mysql-password=fred \
--mysql-table-engine=innodb --mysql-user=fred --max-requests=0 \
--tx-rate=20 --num-threads=2 --report-interval=1 run ; done;

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

Для тех, кто знаком с ProxySQL ниже показано, как мы видим ноды кластера Galera через прокси:

Для осуществления задуманного нам необходимо иметь бинарные логи на каждой PXC ноде и, кроме того, использовать глобальные идентификаторы транзакций (MySQL GTIDs).
В конфигурационном файле my.cnf должно быть:

Шаг 1: отключаем одну ноду и переводим её на MySQL 5.7.17

Нашим первым шагом в этом разделе будет остановка mysqld и удаление пакетов PXC на mysql3:

[root@mysql3]# systemctl stop mysql

ProxySQL Admin> select hostname, status from runtime_mysql_servers;
+---------------+---------+
| hostname | status |
+---------------+---------+
| 192.168.90.11 | ONLINE |
| 192.168.90.12 | SHUNNED |
| 192.168.90.10 | ONLINE |
+---------------+---------+

Наше приложении при этом продолжает работать, т.е. sysbench выполняется в цикле.

Так как все наши ноды запущены на CentOS 7, мы будем использовать mysql57 community репозитарий для el7.

[root@mysql3 ~]# yum install http://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm

[root@mysql3 ~]# yum -y swap Percona-XtraDB-Cluster* mysql-community-server mysql-community-libs-compat
...
=========================================================================================================
Package Arch Version Repository Size
=========================================================================================================
Installing:
mysql-community-libs-compat x86_64 5.7.17-1.el7 mysql57-community 2.0 M
mysql-community-server x86_64 5.7.17-1.el7 mysql57-community 162 M
Removing:
Percona-XtraDB-Cluster-57 x86_64 5.7.14-26.17.1.el7 @percona-release-x86_64 0.0
Percona-XtraDB-Cluster-client-57 x86_64 5.7.14-26.17.1.el7 @percona-release-x86_64 37 M
Percona-XtraDB-Cluster-server-57 x86_64 5.7.14-26.17.1.el7 @percona-release-x86_64 227 M
Percona-XtraDB-Cluster-shared-57 x86_64 5.7.14-26.17.1.el7 @percona-release-x86_64 3.7 M
Percona-XtraDB-Cluster-shared-compat-57 x86_64 5.7.14-26.17.1.el7 @percona-release-x86_64 6.7 M
Installing for dependencies:
mysql-community-client x86_64 5.7.17-1.el7 mysql57-community 24 M
mysql-community-common x86_64 5.7.17-1.el7 mysql57-community 271 k
mysql-community-libs x86_64 5.7.17-1.el7 mysql57-community 2.1 M

Transaction Summary
=========================================================================================================
Install 2 Packages (+3 Dependent packages)
Remove 5 Packages

После этого шага нужно изменить my.cnf - закомментировать все wsrep и относящиеся к PXC опции, а также добавить ряд новых, являющихся обязательными:

binlog_checksum = none
master_info_repository = TABLE
relay_log_info_repository = TABLE
transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name="afb80f36-2bff-11e6-84e0-0800277dd3bf"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "192.168.90.12:3406"
loose-group_replication_group_seeds= "192.168.90.10:3406,192.168.90.11:3406"
loose-group_replication_bootstrap_group= off
loose-group_replication_single_primary_mode= off

Затем мы перенесем этот сервер в другую группу узлов в ProxySQL:

ProxySQL Admin> update mysql_servers set hostgroup_id =2 where hostname ="192.168.90.12";
ProxySQL Admin> load mysql servers to runtime;
ProxySQL Admin> select hostname, status, hostgroup_id from runtime_mysql_servers;
+---------------+---------+--------------+
| hostname | status | hostgroup_id |
+---------------+---------+--------------+
| 192.168.90.11 | ONLINE | 1 |
| 192.168.90.10 | ONLINE | 1 |
| 192.168.90.12 | SHUNNED | 2 |
+---------------+---------+--------------+

Шаг 2: создаём Group Replication кластер из 1 ноды

Теперь нам необходимо выполнить начальную загрузку нашей группы.
Это очень простой шаг.

Нет необходимости делать это прямо сейчас, но лучше сразу настроить учетные данные для процесса восстановления. Позднее об этом можно забыть.

Этот пользователь ещё не создан, но мы создадим его во время следующего шага (и он сразу будет реплицирован на все ноды).

Шаг 3: сделаем репликацию с PXC на MySQL 5.7.17

Теперь нужно создать пользователя для репликации на кластере Galera, который будет использоваться для репликации на новый MySQL 5.7 сервер (и позднее для процесса восстановления групповой репликации).

И запустим асинхронную репликацию с кластера Galera на новый MySQL сервер:

Шаг 4: миграция следующей ноды в Group Replication кластер

Теперь мы будем делать почти то же самое с mysql2:

В отличии от Galera в MySQL Group Replication необходимо, чтобы все ноды имели уникальный server_id. Нужно быть очень внимательными, в данном случае мы установим его равным 2.

Не забудьте также поменять адреса между mysql3 и mysql2 для group_replication_local_address и group_replication_group_seeds:

Перенесем mysql2 во вторую группу узлов в ProxySQL, после этого у нас:

ProxySQL Admin> select hostname, status, hostgroup_id from runtime_mysql_servers;
+---------------+---------+--------------+
| hostname | status | hostgroup_id |
+---------------+---------+--------------+
| 192.168.90.10 | ONLINE | 1 |
| 192.168.90.12 | ONLINE | 2 |
| 192.168.90.11 | SHUNNED | 2 |
+---------------+---------+--------------+

Запустим mysqld и в тоже время вступим в группу (шаг 7)!

mysql3> select * from performance_schema.replication_group_members\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 5221ffcf-c1e0-11e6-b1f5-08002718d305
MEMBER_HOST: pxc2
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 5a2d38db-c1e0-11e6-8bf6-08002718d305
MEMBER_HOST: pxc3
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE

Шаг 5: перевод приложения на наш новый кластер

Пришло время переключить приложение на наш новый MySQL Group Replication кластер. В ProxySQL мы меняем hostgroup_id у mysql2 и mysql3 на 1, и на 2 у mysql1, и применяем изменения на лету (без перезагрузки), после чего останавливаем mysql на ноде mysql1:

ProxySQL Admin> select hostname, status, hostgroup_id from runtime_mysql_servers;
+---------------+--------+--------------+
| hostname | status | hostgroup_id |
+---------------+--------+--------------+
| 192.168.90.10 | ONLINE | 1 |
| 192.168.90.12 | ONLINE | 2 |
| 192.168.90.11 | ONLINE | 2 |
+---------------+--------+--------------+
ProxySQL Admin> update mysql_servers set hostgroup_id =2 where hostname ="192.168.90.10";
ProxySQL Admin> update mysql_servers set hostgroup_id =1 where hostname ="192.168.90.11";
ProxySQL Admin> update mysql_servers set hostgroup_id =1 where hostname ="192.168.90.12";

ProxySQL Admin> load mysql servers to runtime;

ProxySQL Admin> select hostname, status, hostgroup_id from runtime_mysql_servers;
+---------------+--------+--------------+
| hostname | status | hostgroup_id |
+---------------+--------+--------------+
| 192.168.90.12 | ONLINE | 1 |
| 192.168.90.11 | ONLINE | 1 |
| 192.168.90.10 | ONLINE | 2 |
+---------------+--------+--------------+

В этом случае как только mysql1 (192.168.90.10) сменит группу, все соединения с ним будут убиты и переключатся на новые ноды, которые являются частью MySQL Group Replication кластера.

На последнем этапе у нас есть 2 варианта действий: или оставить на некоторое время последнюю PXC ноду в качестве slave, на случай, если решим откатить все изменения назад (тогда нужно рассмотреть вопрос добавления ещё одной к MySQL Group Replication кластеру, так как кластер из двух нод не устойчив к сбоям), или напрямую мигрировать последнюю Galera ноду в Group Replication.

Заключение

Как вы можете видеть, перевод текущей конфигурации Galera на MySQL Group Replication довольно прост и может быть выполнен с минимальными усилиями

Не стесняйтесь оставлять свои комментарии или вопросы.

Примечание

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

Лог также будет содержать информацию об этом:

[Note] Plugin group_replication reported: 'Starting group replication recovery
with view_id 14817109352506883:1'
[Note] Plugin group_replication reported: 'Only one server alive.
Declaring this server as online within the replication group'
[ERROR] Plugin group_replication reported: 'Transaction cannot be executed while Group Replication
is recovering. Try again when the server is ONLINE.'
[ERROR] Run function 'before_commit' in plugin 'group_replication' failed
[ERROR] Slave SQL for channel '': Error in Xid_log_event: Commit could not be completed,
'Error on observer while running replication hook 'before_commit'.', Error_code: 3100
[Warning] Slave: Error on observer while running replication hook 'before_commit'. Error_code: 3100
[ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart
the slave SQL thread with "SLAVE START". We stopped at log 'pxc1-bin.000009' position 76100764
[Note] Plugin group_replication reported: 'This server was declared online within the replication group'

Для решения проблемы нужжно перезапустить репликацию:

© Все права на данную статью принадлежат порталу SQLInfo.ru. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в бумажных изданиях допускается только с разрешения редакции.