Mysql раб разрушается после перезагрузки

Question

Пожалуйста помоги!

Я настроил репликацию "ведущий-ведомый" на основе механизма GTID. Репликация работает нормально, пока перезапуск mysqld не произойдет на ведомом устройстве. Тогда беспорядок начинается...

После такого перезапуска не могу восстановить репликацию. При выдаче команды "START SLAVE" я получаю следующее сообщение об ошибке:

ОШИБКА 1794 (HY000) в строке 1: ведомый не настроен или не удалось правильно инициализироваться. Вы должны, по крайней мере, установить --server-id, чтобы включить ведущий или ведомый. Дополнительные сообщения об ошибках можно найти в журнале ошибок MySQL.

Излишне говорить, что я установил идентификатор сервера в my.cnf (см. Ниже).

В файле /var/log/mysqld.log я обнаружил следующее сообщение об ошибке:

[ОШИБКА] Ошибка при создании основной информации: найдено несколько экземпляров репозитория метаданных репликации с данными в них. Невозможно решить, какой из них выбрать.

[ОШИБКА] Не удалось создать или восстановить репозиторий информации о репликации.

Я не могу понять, что я сделал не так.

Связь между ведущим и подчиненным ssl-туннелируется через stunnel, но я не думаю, что это актуальный факт, так как до перезагрузки все работает правильно.

Единственный способ восстановить репликацию (после перезапуска mysql) - вручную удалить файлы данных mysql, а затем снова загрузить файл дампа, импортированный из мастера. (Я использую mysqldump). Это, конечно, неразумно.

Ниже приведены файлы my.cnf:

На раб:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Recommended in standard MySQL setup
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
server-id=2
log-bin=mysql-bin
binlog_format=ROW
relay_log=relay-log
skip-slave-start
enforce-gtid-consistency
gtid-mode=ON
log-slave-updates
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

По матер:

[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW
gtid-mode=on
enforce-gtid-consistency
log-slave-updates
innodb_buffer_pool_size = 1G
query_cache_size = 32M

Ведомый автомат: Centos 6.6, mysql 5.6.24.

Мастер машины: RHEL 6.6, mysql 5.6.10.

Любая помощь будет принята с благодарностью!

Спасибо

Надав Блум

Answer 1

На мастера -

mysql> reset master;

[эта команда очищает двоичные журналы мастера и начинает с нового. так что сохраните, если хотите.]

когда вы запускаете slave mysqld, выполните следующую команду

mysql> stop salve;
mysql> reset slave;
mysql> change master to master_host='192.168.10.116', master_user='root', master_password='root', master_auto_position=1;
mysql> start slave;
mysql> show slave status \G

Теперь, если все прошло хорошо, вы можете перезапустить подчиненное устройство (если оно зафиксировало все транзакции, то нет проблем, иначе он начнет выполнять пересечение в вашем основном двоичном журнале. Вы можете проверить свой файл журнала ретрансляции)

Answer 2

Ну, загадка раскрыта.

Помните, как я написал, что проблема не имеет ничего общего с моим использованием stunnel в качестве средства туннелирования связи между ведущим и ведомым? Ну, я был не прав.

Дело в том, что я использовал локальный порт 3307 в качестве конечной точки для связи подчиненного устройства с ведущим. (Stunnel прослушал этот порт и перенаправил данные на ip главного сервера). Таким образом, "изменение мастера" было сделано через:

change master to master_host="localhost", master_port=3307, master_user="XXX", master_password="XXX", MASTER_AUTO_POSITION = 1;'

Эта вещь "localhost" вызвала беспорядок. Я изменил его на "127.0.0.1", и теперь перезапуски не причиняют вреда!

Спасибо Hitech и Jaydee за вашу помощь!

Answer 3

Вчера столкнулся с той же проблемой.

Оракул поддержки док помог.

Для людей, у которых нет поддержки Oracle.

ПРИЧИНА

The cause is that both TABLE and FILE replication repository metadata exist at the same time,  but only one form should.

РЕШЕНИЕ

Before setting up replication,  remove the files specified by the my.cnf variables relay_log_info_file and master_info_file .

По умолчанию их имена отображаются на relay-log.info и master.info, и они находятся в каталоге данных. (Мне пришлось удалить файл master.info)

И удалите любую остаточную конфигурацию, выполнив:

STOP SLAVE;
SET SQL_LOG_BIN=0;
DELETE FROM mysql.slave_master_info ;
DELETE FROM mysql.slave_relay_log_info ;
SET SQL_LOG_BIN=1;