SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 07.05.2018 13:36:08

ibeltek
Участник
Зарегистрирован: 07.05.2018
Сообщений: 6

Миграция существующей master-slave в percona-xtradb-cluster

Добрый день сообщество,

Надеюсь на Вашу пользу и коллективный разум.

И так, есть существующая инфраструктура master-slave  репликации с несколькими 10ми слейвов и включенными GTID, задача, - переключить это хозяйство в  percona-xtradb-cluster.
на одном из слейвов я делаю:

systemctl start mysql@bootstrap.service


получаю ожидаемый результат:

+----------------------------+--------------------------------------+
| Variable_name              | Value                                |
+----------------------------+--------------------------------------+
| wsrep_local_state_uuid     | c2883338-834d-11e2-0800-03c9c68e41ec |
| ...                        | ...                                  |
| wsrep_local_state          | 4                                    |
| wsrep_local_state_comment  | Synced                               |
| ...                        | ...                                  |
| wsrep_cluster_size         | 2                                    |
| wsrep_cluster_status       | Primary                              |
| wsrep_connected            | ON                                   |
| ...                        | ...                                  |
| wsrep_ready                | ON                                   |
+----------------------------+--------------------------------------+



после добавляю второю ноду кластера, стартует синк и после синка падает с ошибкой:

018-05-07T10:03:47.347436Z WSREP_SST: [INFO] Proceeding with SST.........
    2018-05-07T10:03:47.752176Z WSREP_SST: [INFO] ............Waiting for SST streaming to complete!
    2018-05-07T10:23:25.468144Z WSREP_SST: [INFO] Preparing the backup at /var/lib/mysql//.sst
    2018-05-07T10:23:47.816165Z WSREP_SST: [INFO] Moving the backup to /var/lib/mysql/
    2018-05-07T10:23:47.978690Z WSREP_SST: [INFO] Galera co-ords from recovery: 24a73232-51d6-11e8-8762-f633b3d05274:145210
2018-05-07T10:23:48.472481Z 2 [ERROR] WSREP: Failed to apply trx: source: 24a6d198-51d6-11e8-a367-0be4506e5a31 version: 3 local: 0 state: APPLYING flags: 1 conn_id: 20 trx_id: 2792203 seqnos (l: 35945, g: 145211, s: 145210, d: 145067, ts: 4142186552171721)
2018-05-07T10:23:48.472526Z 2 [ERROR] WSREP: Failed to apply trx 145211 4 times
2018-05-07T10:23:48.472537Z 2 [ERROR] WSREP: Node consistency compromised, aborting...
 


и отваливается реплика.

В чем ошибка, что я делаю не так?

Неактивен

 

#2 07.05.2018 15:47:06

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: Миграция существующей master-slave в percona-xtradb-cluster

Выглядит как ошибка SST.

    2018-05-07T10:23:25.468144Z WSREP_SST: [INFO] Preparing the backup at /var/lib/mysql//.sst
    2018-05-07T10:23:47.816165Z WSREP_SST: [INFO] Moving the backup to /var/lib/mysql/

Вот эти штуки смущают. Как будто где-то вписан пустой путь (или абсолютный). Пробовали запусить с настройками по умолчанию?

Неактивен

 

#3 07.05.2018 16:37:37

ibeltek
Участник
Зарегистрирован: 07.05.2018
Сообщений: 6

Re: Миграция существующей master-slave в percona-xtradb-cluster

paulus написал:

Выглядит как ошибка SST.

    2018-05-07T10:23:25.468144Z WSREP_SST: [INFO] Preparing the backup at /var/lib/mysql//.sst
    2018-05-07T10:23:47.816165Z WSREP_SST: [INFO] Moving the backup to /var/lib/mysql/

Вот эти штуки смущают. Как будто где-то вписан пустой путь (или абсолютный). Пробовали запусить с настройками по умолчанию?

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

Неактивен

 

#4 07.05.2018 16:50:07

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: Миграция существующей master-slave в percona-xtradb-cluster

То есть у вас есть два рабочих сервера и не работает подключение третьего?

Неактивен

 

#5 07.05.2018 17:37:23

ibeltek
Участник
Зарегистрирован: 07.05.2018
Сообщений: 6

Re: Миграция существующей master-slave в percona-xtradb-cluster

paulus написал:

То есть у вас есть два рабочих сервера и не работает подключение третьего?

http://pix.toile-libre.org/upload/origi … 705755.png - моя схема реализации,и картина такова что:
1. на выделенной слейв ноде bootstrap cтартует без проблем, кластер запускается, репликация работает
2. на ноде pxc1 при ключении ее в кластер запускается процесс синка, а по окончанию синка процесс вывалиается с ошибкой:


2018-05-07T10:23:48.472481Z 2 [ERROR] WSREP: Failed to apply trx: source: 24a6d198-51d6-11e8-a367-0be4506e5a31 version: 3 local: 0 state: APPLYING flags: 1 conn_id: 20 trx_id: 2792203 seqnos (l: 35945, g: 145211, s: 145210, d: 145067, ts: 4142186552171721)
2018-05-07T10:23:48.472526Z 2 [ERROR] WSREP: Failed to apply trx 145211 4 times
2018-05-07T10:23:48.472537Z 2 [ERROR] WSREP: Node consistency compromised, aborting...

Отредактированно ibeltek (07.05.2018 18:10:38)

Неактивен

 

#6 07.05.2018 18:43:08

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: Миграция существующей master-slave в percona-xtradb-cluster

А если остановить репликацию, то всё работает? Ну в смысле — это конфликт wsrep-транзакций с gtid-транзакциями?

Неактивен

 

#7 07.05.2018 18:54:09

ibeltek
Участник
Зарегистрирован: 07.05.2018
Сообщений: 6

Re: Миграция существующей master-slave в percona-xtradb-cluster

да, именно так.

Неактивен

 

#8 07.05.2018 19:26:27

ibeltek
Участник
Зарегистрирован: 07.05.2018
Сообщений: 6

Re: Миграция существующей master-slave в percona-xtradb-cluster

остановил слейв на время слива данных во вторую ноду кластера, - кластер стартанул, потом запустил слейв на доноре, пока полет нормальный

Неактивен

 

#9 08.05.2018 10:09:44

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: Миграция существующей master-slave в percona-xtradb-cluster

Интересный эффект. Главное, чтобы не выстрелило еще раз. В теории такого не должно случиться в случае с InnoDB cluster (он использует те же GTID, а не собственный набор), но он может быть еще сыроват.

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson