Я настраиваю реплику для чтения MySQL, которая доступна только для чтения. И ведущий, и ведомый работают под управлением MySQL 5.6. В подчиненное устройство никогда не записывают напрямую, но я не могу синхронизировать его дольше часа или двух. После небольшой пробежки я постоянно сталкиваюсь с ошибкой такого типа:
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log
Затем мне нужно пройти процесс воссоздания ведомого устройства из дампа MySQL, но, что бы я ни делал, я снова получаю эту ошибку. Кто-нибудь знает, почему это может происходить?
В зависимости от того, какой движок (ы) вы используете, используете ли вы несколько схем и параметры, которые вы используете с mysqldump, вы можете не получить согласованный дамп.
Если у вас две схемы, скажем, одна с именем development, а другая с именем production, mysqldump блокирует таблицы отдельно для каждой схемы. Это означает, что пока вы создаете резервную копию схемы разработки, рабочая схема все еще доступна для записи и обновляется.
Теперь, когда у вас есть дамп двух схем и запуск репликации, две схемы фактически находятся в разных позициях бинарного журнала. Это означает, что когда вы получаете Error_code 1032, у вас действительно нет этого ключа.
Если все из таблиц, которые вам нужно сделать резервную копию, являются InnoDB, вы должны изучить --single-transaction вариант для mysqldump. Если у вас есть смесь InnoDB и MyISAM, то только таблицы InnoDB гарантированно будут согласованными. Таблицы MyISAM по-прежнему будут записаны с использованием этой опции.
Если у вас есть смесь InnoDB и MyISAM или вы используете только MyISAM, лучшим вариантом (с использованием mysqldump) является использование --lock-all-tables. Это именно то, на что похоже, ничего не будет записано, пока дамп не будет завершен. Главный недостаток заключается в том, что ваше приложение или веб-сайт, зависящий от базы данных, также заблокирован (поскольку не может писать).
Лучший вариант IMO - переместить все в InnoDB, если это еще не сделано, и использовать Percona Xtrabackup. Он по-прежнему будет нормально работать с таблицами MyISAM, но с помощью другого инструмента, чем таблицы InnoDB (cp или rsync). При копировании таблиц MyISAM по-прежнему необходимо блокировать таблицы, но он делает все возможное, чтобы минимизировать это время. Если вы используете rsync метод, тогда инструмент сначала скопирует все ваши таблицы MyISAM, затем заблокировать таблицы, а затем скопировать все таблицы, которые были обновлены с момента первой копии. Блокировку необходимо удерживать только во время этого второго rsync.