Назад | Перейти на главную страницу

MySQL Master-Master со смещениями получает ОШИБКУ 1872

Я пытаюсь исправить репликацию между моделью репликации базы данных MySQL master-master.

Сервер 1 (с IP-адресом 192.168.2.6) настроен с:

auto-increment-increment       = 2
auto-increment-offset          = 1

Таким образом, он записывает только нечетные автоматически увеличивающиеся идентификаторы первичного ключа.

Сервер 2 (с IP-адресом 192.168.2.7) настроен с:

auto-increment-increment       = 2
auto-increment-offset          = 2

Таким образом, он записывает только идентификаторы с автоинкрементом даже первичного ключа.

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

Моя работа - заставить его работать таким образом. Я сделал следующие шаги, чтобы попытаться синхронизировать их:

Server 1:
    mysql>
    RESET MASTER;
    # First time only:
    #GRANT REPLICATE SLAVE ON *.* TO 'replicate'@192.168.2.7 IDENTIFIED BY '[password_redacted]';
    #FLUSH PRIVILEGES;
    FLUSH TABLES WITH READ LOCK;
    SHOW MASTER STATUS;

    bash#
    mysqldump -u root -p -ceQRE --hex-blob --triggers --opt --single-transaction --comments --dump-date --no-autocommit --all-databases -r /root/master.sql
    scp -P 5934 /root/master.sql root@192.168.2.7:.

    mysql>
    UNLOCK TABLES;

Server 2:
    mysql>
    STOP SLAVE;

    bash#
    mysql -u root -p < /root/master.sql

    mysql>
    # First time only:
    #GRANT REPLICATE SLAVE ON *.* TO 'replicate'@192.168.2.6 IDENTIFIED BY '[password_redacted]';
    #FLUSH PRIVILEGES;
    RESET SLAVE;
    CHANGE MASTER TO MASTER_HOST='192.168.2.6', MASTER_USER='replicate', MASTER_PASSWORD='[password_redacted]', MASTER_LOG_FILE='ibm.000001', MASTER_LOG_POS=28556380;
    START SLAVE;
    SHOW SLAVE STATUS\G

Server 1:
    mysql>
    STOP SLAVE;
    CHANGE MASTER TO MASTER_HOST='192.168.2.7', MASTER_USER='replicate', MASTER_PASSWORD='[password_redacted]', MASTER_LOG_FILE='ibm.000004', MASTER_LOG_POS=121875;
    CHANGE REPLICATION FILTER REPLICATE_DO_DB = (reminderdental2), REPLICATE_IGNORE_DB = (mysql);
    START SLAVE;

Каждый раз он говорит, что синхронизируется, но количество строк никогда не согласуется. Через какое-то время я получу ошибку:

Slave SQL for channel '': Slave failed to initialize relay log info structure from the repository, Error_code: 1872
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

Я также пробовал Percona XtraBackup, чтобы получить двоичное резервное копирование / восстановление, чтобы запустить его в первый раз.

Я думал о переходе на репликацию GTID, но слышал, что производительность не так хороша. Меня интересуют оба решения, позволяющие заставить его работать таким образом, а также отзывы о производительности кластера из 2-9 серверов с использованием GTID.

Версия сервера 1:

5.7.21-0ubuntu0.16.04.1-log (Ubuntu)
percona-xtrabackup-24/unknown,now 2.4.9-1.xenial amd64 [installed]

Версия Serer 2:

5.7.21-log MySQL Community Server (GPL)
percona-xtrabackup-24, 2.4.9.1.el7

В MySQL> 6 вы также должны использовать

mysql> STOP SLAVE;
mysql> RESET SLAVE ALL;

Должно быть то же самое, но использование задокументированной команды лучше, чем настройка системных таблиц. Смотрите также https://dev.mysql.com/doc/refman/8.0/en/reset-slave.html

Если вы получаете следующую ошибку:

[ERROR] Slave SQL для канала group_replication_applier: Slave не удалось инициализировать структуру информации журнала реле из репозитория, Error_code: 1872

Вот решение:

Из консоли mysql:

USE mysql;
TRUNCATE TABLE slave_relay_log_info;

Затем перезапустите mysql:

service mysql restart

Надеюсь, это сработает и для вас, ребята!

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