Я пытаюсь выполнить репликацию Master Slave для MySQL. Когда я набираю следующую команду:
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;
выдает следующую ошибку:
ОШИБКА 1201 (HY000): не удалось инициализировать главную информационную структуру; больше сообщений об ошибках можно найти в журнале ошибок MySQL
Любая помощь будет принята с благодарностью.
ПОПРОБУЙТЕ СБРОСИТЬ ЕГО, ЭТО ДЕЛАЕТ ВОЛШЕБСТВО! НА ПОДЧИНЕННОМ ТИПЕ КОМАНДЫ MYSQL:
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;
Пожалуйста, проверьте несколько вещей:
1) Убедитесь, что в файле /etc/my.cnf мастера действительно установлен server_id
И вот почему: Репликация зависит от server_id. Всякий раз, когда запрос выполняется и записывается в двоичный журнал мастера, вместе с ним записывается server_id мастера. По умолчанию, если server_id не определен в /etc/my.cnf, server_id по умолчанию равен 1. Однако правила репликации MySQL требуют, чтобы server_id был явно определен в главном файле /etc/my.cnf. Кроме того, для любого заданного ведомого устройства mysqld проверяет server_id оператора SQL по мере того, как он считывает его из журнала ретрансляции, и убеждается, что он отличается от server_id ведомого устройства. Вот как MySQL Replication узнает, что выполнение этого оператора SQL безопасно. Это правило необходимо в случае реализации Циркулярной (Мастер-Мастер, Мультимастер) репликации.
используйте select @@server_id; в командной строке sql, чтобы проверить конфигурацию на сервере.
2) Убедитесь, что в /etc/my.cnf ведомого устройства действительно установлен server_id
Вот почему: та же причина, что и в № 1.
3) Убедитесь, что server_id в файле /etc/my.cnf ведущего устройства отличается от server_id в /etc/my.cnf ведомого устройства.
Вот почему: та же причина, что и в № 1.
В качестве примечания: если вы настраиваете несколько ведомых устройств, убедитесь, что каждое ведомое устройство имеет другой идентификатор server_id, отличный от своего ведущего и подчиненных ему братьев и сестер.
Вот почему: Пример
Ведущий с 2 подчиненными
ГЛАВНЫЙ имеет server_id 1
ПОДЧИНЕННЫЙ1 имеет server_id 2
ПОДЧИНЕННЫЙ2 имеет server_id 2
Репликация станет агрессивно медленной на SLAVE2, потому что одноуровневое подчиненное устройство имеет тот же server_id. На самом деле он будет постоянно отставать, ловить передышку, обрабатывать несколько операторов SQL. Это вина ведущего из-за наличия одного или нескольких ведомых устройств с одинаковыми идентификаторами server_id. Это ловушка, которая на самом деле нигде не задокументирована. Я видел это десятки раз в моей жизни время.
У меня было что-то очень близкое к этому, и я получил те же сообщения об ошибках. Репликация работает нормально, перезапуск mariadb -> «не удается открыть журнал ретрансляции»
Решение от Neo помогло в первую очередь.
Но основная причина, по-видимому, заключалась в небольших ограничениях на количество открытых файлов.
Попробуйте lsof | wc и увеличьте DefaultLimitNOFILE до 65535 в /etc/systemd/system.conf и /etc/systemd/user.conf
Если больше ничего не помогает и вы уверены, что все настроено правильно, вам придется удалить этот файл:
/var/lib/mysql/<relay_logname>-<connection>.info
после этого выполните команду «CHANGE MASTER», как указано выше.
