Я унаследовал мастер-систему Mysql, я заметил, что второй мастер (теперь давайте называть его подчиненным, поскольку он работает на «подчиненной» машине) перестал обновлять свою базу данных. я видел это
Мастер:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Slave: (с ошибкой, которую я обрезал)
Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_Errno: 1062
Last_Error: Error 'Duplicate entry '3' for key 'PRIMARY'' on [...]
Я не знаю, что заставило его обработать, учитывая, что мы не можем получить там дубликат. Важно возобновить нормальную работу;
Прямо сейчас у меня stop slave;
на Мастере и stop slave;
на ведомом, потому что я видел, что если я изменяю записи на ведомом устройстве, изменения действительно передаются ведущему, который активно используется.
Как мне: принудительно синхронизировать ВСЕ от ведущего к ведомому, не затрагивая данные на ведущем? Тогда, надеюсь, будет репликация ведомого захвата как обычно?
ОБНОВИТЬ ОК. Я попытался удалить все таблицы на ведомом устройстве, затем в этом разделе ошибок он пожаловался на то, что «таблица» не существует. Поэтому я не сделал дамп данных Мастера и убедился, что у меня есть только пустые таблицы во Вторичном (подчиненном) сервере. я start slave;
на ведомом, НО теперь он жалуется на кровавые операторы alter table, например:
Last_Errno: 1060
Last_Error: Error 'Duplicate column name [...] Query: 'ALTER TABLE [...]
Как пропустить операторы изменения гидроразрыва Я просто хочу реплицировать кровавые данные и покончить с ними, в моих таблицах уже есть последние изменения FFS, и теперь он жалуется на изменения, сделанные после репликации, захваченной несколько недель назад
Как мне сбросить лог или еще что?
ВЫДАЮЩИЙСЯ Почему это началось? «Вторичный» переходит в «Первичный». «Первичный» не распространяется на «Вторичный». Но любые исправления, которые я пытался сделать, оставляли его в том же состоянии Yes-Yes Yes-No с тем же Last_Error. Я думаю, что примерно в то время сервер был отключен от сети, могло ли это каким-то образом запутать MySQL?
Сначала вам нужно понять, что репликация MySQL синхронизирует только ИЗМЕНЕНИЯ. Очистка таблиц (или их удаление) не приведет к повторной репликации данных. Вы должны запустить ведомое устройство с согласованным набором файлов данных.
Грубый процесс повторного посева вашего раба выглядит следующим образом: (не следуйте этим инструкциям)
Если вы не можете терпеть простои, то есть 2 способа сделать это.
Если ваши данные достаточно малы, чтобы вы могли mysqldump все, включая данные, тогда эти инструкции хороши. Если у вас несколько баз данных, обязательно прочтите эту статью, поскольку я не собираюсь повторять здесь эти соображения. Но если у вас только 1 база данных, основные шаги:
mysqldump -u root -e -q --single-transaction --master-data database_name
START SLAVE UNTIL MASTER_LOG_FILE='bin.000029', MASTER_LOG_POS=651322976;
Если ваши базы данных слишком велики для дампа mysql, вам нужно будет сделать снимки таблиц с помощью функций моментальных снимков тома вашей ОС. Это приостановит ваш сервер MySQL на несколько секунд, поэтому лучше делать это в нерабочее время, когда это, вероятно, никому не помешает.
flush tables with write lock
. Это фактически приостановит сервер.SHOW MASTER STATUS
чтобы получить текущую позицию журнала, затем UNLOCK TABLES
чтобы снять блокировку. Сервер теперь не приостановлен.START SLAVE UNTIL MASTER_LOG_FILE='bin.000029', MASTER_LOG_POS=651322976;