Не могли бы вы помочь мне понять, почему я получаю «Дублированная запись для первичного ключа» на подчиненном сервере после полной повторной синхронизации.

По сути, «mysqldump» работал почти всю ночь, а затем процесс восстановления занял пару часов, поэтому, когда я запускал ведомое устройство, он отставал от мастера на ~ 63874 секунды.

Подчиненный сервер доступен только для чтения (read_only), и в процессе повторной синхронизации не было никаких записей, поэтому я не понимаю, почему существуют дублированные ключи.

Двоичный формат журнала установлен на MIXED на ведущем устройстве.

Команда, используемая для резервного копирования БД:

mysqldump --opt --single-transaction -Q --master-data=2 db | bzip2 -cz > db.sql.bz2

Ведомое устройство реплицирует только одну базу данных из master (db -> db_backup) со следующими параметрами:

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

АСПЕКТ № 1: Репликация

Я не думаю что

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

принадлежат друг другу.

Другие люди задавались вопросом об этом также

• Jun 14, 2012: Настроена репликация MySQL, но она не работает
• Jun 13, 2012: В чем разница между «replicate-rewrite-db» и «replicate-do-db» во время репликации mysql?
• May 31, 2012: Mysql replicate-rewrite-db не работает

Проблема связана с обработкой правил репликации заказа. Согласно документации MySQL по правилам репликации :

Если были указаны какие-либо параметры --replicate-rewrite-db, они применяются до проверки правил фильтрации --replicate- *.

Даже документация MySQL по replicate-rewrite-db гласит:

Перевод имени базы данных выполняется до тестирования правил --replicate- *.

Применяется replicate-wild-do-tableпосле перезаписи. Не было бы удивительно, если бы этот порядок как-то наложил INSERT в таблицу, в которой уже есть данные.

Вы, наверное, спрашиваете, как эти данные попали туда?

АСПЕКТ № 2: mysqldump

Делая mysqldump --single-transactionбы , кажется, самый лучший способ на определенный момент времени отвалов данных. К сожалению, mysqldump --single-transactionесть Ахиллесова пята ALTER TABLE. Если к таблице применяются какие-либо ALTER TABLEкоманды, такие как DROP TABLEи CREATE TABLE, которые могут нарушить целостность транзакции, в которой mysqldump пытался выполнить дамп. Усечение таблицы (которая является DDL в MySQL Universe), удаление и добавление индексов может и быть таким же разрушительным.

Вы можете найти более подробную информацию об этом в MySQLDump 's Best Best MySQLDump Secret . Я фактически обратился к этому вопросу в прошлом вопросе, описывающем 12 команд, которые могут нарушить целостность транзакции mysqldump: резервная копия MySQL InnoDB

ПРЕДОСТЕРЕЖЕНИЕ

• Лично я бы переключил бинарный формат на ЗАЯВЛЕНИЕ
• Как я уже говорил в резервной копии MySQL InnoDB , у вас должен быть другой подчиненный (без каких-либо фильтров репликации), предназначенный для выполнения mysqldumps.
• 63000+ секунд позади? Вам следует заняться созданием параллельных дампов таблиц: Как я могу оптимизировать mysqldump для большой базы данных?

Эпилог

Один или оба аспекта, возможно, способствовали проскальзыванию строки во время mysqldump, которого не должно было быть из-за правил перезаписи или изолированной переопределенности mysqldump.

SUGGESTIONS

Я бы сделал дамп mysqlbinlog всех журналов ретрансляции с момента запуска mysqldump, чтобы увидеть все INSERT, которые будет обрабатывать ведомый, и посмотреть, существуют ли эти строки на ведомом. Если они это сделают, вы могли бы сделать две вещи:

1: пропустить все ошибки Duplicate Key

Просто добавьте это в my.cnf на Рабе

[mysqld]
slave-skip-errors=1062
skip-slave-start

и перезапустите MySQL. Затем бегиSTART SLAVE;

все ошибки дубликата ключа будут обойдены. Когда Seconds_Behind_Masterдоберетесь до 0, удалите эти строки и перезапустите mysql.

2: скачать инструменты Percona

Инструменты, которые вам нужны

• пт-таблицы контрольной суммы
• пт-таблицы синхронизации

Используйте их, чтобы найти различия в Рабе, а затем исправить их

Проверьте наличие запроса вставки в коде, который вставляется непосредственно в ведомое устройство. Мы можем читать только от раба. Запросы на запись должны быть направлены на мастера.