Чи можете ви, будь ласка, допомогти мені зрозуміти, чому після повного повторного синхронізації я отримую "Дублюваний запис для ПРИМІТНОГО ключа" на підлеглому сервері.

В основному "mysqldump" працював майже цілу ніч, і тоді процес відновлення зайняв пару годин, тому коли я запустив раб, він був на 63874 секунди позаду майстра.

Підлеглий сервер читається лише (read_only) і під час повторної синхронізації не було записів, тому я не розумію, чому є дублюються ключі.

Формат бінарного журналу встановлено на MIXED на master.

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

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

Підлеглий реплікує лише одну базу даних з головного (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: Яка різниця між "repplic-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після перезапису. Не дивно, якби це замовлення якось наклало ВСТУП на таблицю, у якій вже є дані.

Ви, напевно, запитуєте, як потрапили дані?

АСПЕКТ №2: mysqldump

Роблячи mysqldump --single-transactionб , здається, найкращий спосіб на певний момент часу відвалів даних. На жаль, mysqldump --single-transactionмає ахілесову п'яту : ALTER TABLE. Якщо таблиця підпорядковується будь-яким ALTER TABLEкомандам, таким як a DROP TABLEі CREATE TABLE, які можуть порушити цілісність транзакції, mysqldump намагався виконати дамп. Структура таблиці (яка є DDL у Всесвіті MySQL) та видалення та додавання індексів може також бути таким же руйнівним.

Більше інформації про це ви можете знайти у найкращому збереженому MySQLDump Secret блозі MySQL . Я фактично звернувся до цього питання в минулому запитанні, в якому описував 12 команд, які можуть порушити цілісність транзакції mysqldump: Резервне копіювання MySQL InnoDB

КАВАТИ

• Особисто я перейшов би в бінарний формат на STATEMENT
• Як я вже говорив у MySQL резервного копіювання InnoDB , у вас повинен бути інший підлеглий (без жодних фільтрів реплікації), присвячений виконанню mysqldumps.
• 63000+ секунд позаду? Вам слід поглянути на виконання паралельних дампів таблиці: Як я можу оптимізувати mysqldump великої бази даних?

ЕПІЛОГ

Один або обидва аспекти, можливо, сприяли тому, що рядок проскакує під час mysqldump, який не повинен був існувати через правила перезапису або переоцінку ізоляції mysqldump.

ПРОПОЗИЦІЇ

Я би зробив mysqlbinlog скидання всіх журналів ретрансляції з початку роботи mysqldump, щоб побачити всі ВСТАВКИ, які підлеглий обробляє, і перевірити, чи ці рядки вже існують на підлеглому. Якщо вони будуть, ви, ймовірно, можете зробити дві речі:

1: Пропустіть всі помилки дублюючого ключа

Просто додайте це до my.cnf на Рабі

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

і перезапустити mysql. Потім бігайтеSTART SLAVE;

всі помилки повторюваних ключів будуть обійдені. Коли ви Seconds_Behind_Masterотримаєте 0, видаліть ці рядки та перезапустіть mysql.

2: Завантажте інструменти Percona

Потрібні інструменти є

• pt-table-контрольна сума
• pt-table-sync

Скористайтеся ними, щоб знайти відмінності в Рабі, а потім виправте їх

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