Ошибка: "не удалось инициализировать структуру главной информации" при выполнении Master Slave Replication в MySQL

Ответ 1

ПЫТАЙТЕСЬ RESET ЭТО, ЭТО ДЕЛАЕТ МАГИЯ! ON SLAVE THE SLAVE MYSQL COMMAND TYPE:

RESET SLAVE;

ПОСЛЕ ПРОТИВ:

CHANGE MASTER TO MASTER_HOST='10.1.100.1', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=451228;
mysql> START SLAVE;

Ответ 2

Пожалуйста, проверьте несколько вещей:

1) Убедитесь, что мастер /etc/my.cnf действительно установил server_id

И вот почему: Репликация опирается на идентификатор_сервера. Всякий раз, когда запрос выполняется и записывается в двоичный журнал мастера, вместе с ним записывается идентификатор_сервера мастера. По умолчанию, если server_id не определен в /etc/my.cnf, server_id по умолчанию равен 1. Однако правила MySQL Replication требуют, чтобы server_id был явно определен в master/etc/my.cnf. Кроме того, для любого данного ведомого, mysqld проверяет server_id оператора SQL, поскольку это читает его из журнала ретрансляции и удостоверяется, что это отличается от ведомого server_id. Таким образом, MySQL Replication знает, что выполнять этот оператор SQL безопасно. Это правило необходимо в том случае, если реализована репликация циркулярного (Master-Master, MultiMaster).

используйте select @@server_id; в командной строке sql для проверки конфигурации на сервере.

2) Убедитесь, что у ведомого /etc/my.cnf действительно установлен server_id

Вот почему: та же причина, что и в # 1

3) Убедитесь, что server_id в Master/etc/my.cnf отличается от server_id в Slave/etc/my.cnf

Вот почему: та же причина, что и в # 1

Примечание: если вы настроили несколько ведомых, убедитесь, что у каждого ведомого устройства свой идентификатор_сервера отличается от своего главного и дочерних подчиненных.

Вот почему: пример

Мастер с 2 рабами
MASTER имеет идентификатор_сервера 1
У SLAVE1 есть server_id 2
У SLAVE2 есть server_id 2

Репликация станет агрессивно вялой на SLAVE2, потому что подчиненный брат имеет тот же идентификатор server_id. Фактически, он неуклонно отстает, перехватывает, обрабатывает несколько операторов SQL. Это основная ошибка наличия одного или нескольких подчиненных с одинаковыми значениями server_ids. Это гоча, которая нигде не документирована. Я видел это десятки раз в моей жизни.

Ответ 3

У меня было что-то очень близкое к этому и я получил те же сообщения об ошибках. Репликация работает нормально, перезапуск mariadb → "не удается открыть релейный журнал"

Решение от Нео помогло в первую очередь.

Но основной причиной, по-видимому, были небольшие ограничения по размеру открытого файла.

Попробуйте lsof | wc и увеличьте DefaultLimitNOFILE до 65535 в /etc/systemd/system.conf и /etc/systemd/user.conf