Репликация двоичного журнала MySQL: можно ли настроить игнорирование ошибок?
Я использую систему репликации двоичного журнала MySQL master-slave (уф!), Которая для некоторых данных не синхронизирована (это означает, что мастер хранит больше данных, чем подчиненный). Но ведомое устройство очень часто останавливается при малейшей ошибке MySQL, можно ли это отключить? (возможно, настройка my.cnf для реплицирующего подчиненного сервера ignore-replicating-errors или что-то в этом роде;))
Это то, что происходит время от времени, когда ведомое устройство пытается воспроизвести несуществующий элемент, ведомое устройство просто умирает. быстрая проверка на ПОКАЗАТЬ СОСТОЯНИЕ ПОДГОТОВКИ \ G; дает
Slave-IO-Running: Yes
Slave-SQL-Running: No
Replicate-Do-DB:
Last-Errno: 1062
Last-Error: Error 'Duplicate entry '15218' for key 1' on query. Default database: 'db'. Query: 'INSERT INTO db.table ( FIELDS ) VALUES ( VALUES )'
который я быстро исправляю (как только понимаю, что ведомое устройство было остановлено), выполнив следующие действия:
STOP SLAVE;
RESET SLAVE;
START SLAVE;
... в последнее время это становится утомительным, и, прежде чем я выплюнул какой-то PHP, который делает это за меня, мне было интересно, есть ли какая-нибудь запись my.cnf, которая не убьет ведомого при первой ошибке.
Ваше здоровье,
/ мп
Ответы 6
Во-первых, вы действительно хотите игнорировать ошибки? Если вы получили сообщение об ошибке, вероятно, данные больше не синхронизированы. Возможно, вы хотите удалить подчиненную базу данных и перезапустить процесс синхронизации при появлении ошибки.
Во-вторых, я думаю, что ошибка, которую вы получаете, возникает не при репликации несуществующего элемента (что бы это значило в любом случае?) - похоже, что вы реплицируете элемент, который уже существует в подчиненной базе данных.
Я подозреваю, что проблема в основном возникает из-за того, что вы не запускаете чистую копию данных. Кажется, что мастер был скопирован на подчиненный; затем репликация отключена (или не удалась); а затем он снова запустился, но не дав рабу шанс догнать то, что он упустил.
Если у вас когда-нибудь будет время, когда мастер может быть закрыт для доступа на запись на достаточно долгое время, чтобы клонировать базу данных и импортировать ее в подчиненное устройство, это может решить проблемы.
Современные команды mysqldump имеют несколько опций, помогающих настроить согласованную репликацию. Обратите внимание на --master-data, который поместит двоичный файл журнала и позицию в дамп и автоматически установит при загрузке в подчиненное устройство. Кроме того, --single-transaction будет делать дамп внутри транзакции, поэтому для согласованного дампа не требуется блокировка записи.
Стоит отметить, что --single-transaction полезен только для транзакционных таблиц, таких как InnoDB.
Да, с --slave-skip-errors = xxx в my.cnf, где xxx - это «все» или список кодов ошибок, разделенных запятыми.
Справедливое предупреждение, что это может действительно повредить вашу подчиненную базу данных. Это ошибки неспроста. :)
в my.cnf, я полагаю, вы помещаете это без ведущего "-".
Если ведомое устройство не используется для каких-либо операций записи, кроме репликации, авторы High Performance MySQL рекомендуют добавить read_only на ведомый сервер, чтобы предотвратить ошибочное изменение пользователями данных на ведомом сервере, поскольку это также вызовет те же ошибки, с которыми вы столкнулись.
Я думаю, что вы выполняете репликацию без синхронизации, сначала синхронизируйте базу данных и попробуйте репликацию, а серверы генерируют одинаковые уникальные идентификаторы и пытаются установить смещение автоматического приращения
остановить раба; установить глобальный sql_slave_skip_counter = 1; запустить раб;
Вы можете проигнорировать только текущую ошибку и продолжить процесс репликации.
это отлично работает, спасибо. Не понимаю, почему это не лучший ответ.
исходный пост просил автоматический процесс, хотя это работает, он все еще ручной
он все еще может работать, но множество ошибок 1062 - верный признак рассинхронизации ведомых устройств базы данных. вам лучше изолировать, какая база данных является наиболее "современной" или "правильной", продвинуть ее до уровня ведущего, добавить еще несколько ведомых устройств в новый кластер и удалить исходные ведущие / ведомые устройства
«RESET SLAVE» просто снова запустит репликацию с самого начала. Одна и та же ошибка для той же строки должна рано или поздно появиться на правильном пути ... тогда как же она решила ваши проблемы.