Репликация двоичного журнала MySQL: может ли он быть установлен, чтобы игнорировать ошибки?

Question

Я запускаю систему репликации двоичного журнала MySQL-хозяина-хозяина (phew!), Которая для некоторых данных не синхронизирована (что означает, что ведущий хранит больше данных, чем подчиненный). Но подчиненный останавливается очень часто при малейшей ошибке MySQL, может ли это быть отключено? (возможно, параметр my.cnf для репликации ошибок-репликаций ведомых ошибок или некоторых из них;))

Это то, что происходит, время от времени, когда ведомое устройство пытается реплицировать элемент, который не существует , раб просто умирает. быстрая проверка на SHOW SLAVE STATUS \ 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, которая не будет убивать подчиненный при первой ошибке.

Приветствия,

/Тпл

Answer 1

Да, с -slave-skip-errors = xxx в my.cnf, где xxx - это «все» или список кодов ошибок запятой.

Answer 2

Во-первых, действительно ли вы хотите игнорировать ошибки? Если вы получите сообщение об ошибке, скорее всего, данные больше не синхронизируются. Возможно, вы хотите сбросить базу подчиненных и перезапустить процесс синхронизации, когда вы получите сообщение об ошибке.

Во-вторых, я думаю, что ошибка, которую вы получаете, это не когда вы копируете элемент, который не существует (что бы это значило?) - похоже, вы копируете элемент, который уже существует в базе данных подчиненных.

Я подозреваю, что проблема в основном возникает из-за того, что она не начинается с чистой копии данных. Кажется, что мастер был скопирован на раба; то репликация была отключена (или не удалась); и затем он снова начал работать, но не давал рабу шанс догнать то, что он пропустил.

Если у вас есть время, когда мастер может быть закрыт для доступа на запись достаточно долго, чтобы клонировать базу данных и импортировать ее в подчиненный, это может вызвать проблемы.

Answer 3

У современных команд mysqldump есть несколько вариантов, помогающих в настройке последовательной репликации. Проверьте --master-data, который поместит файл двоичного журнала и положение в дампе и автоматически установится при загрузке в подчиненный. Кроме того, --single-transaction будет выполнять дамп внутри транзакции, чтобы блокировка записи не требовалась для последовательного дампа.

Answer 4

Если ведомое устройство не используется для каких-либо записей, отличных от репликации, авторы High Performance MySQL рекомендуют добавить 0ABна подчиненный сервер, чтобы пользователи не ошибочно меняли данные на подчиненном устройстве, поскольку это также создаст тот же ошибки, которые вы испытали.

Answer 5

я думаю, что вы делаете репликацию с синхронизацией из базы данных первого синхронизировать базу данных и попробовать для репликации и серверы генерируют одинаковые уникальные идентификаторы и попытаться установить автоматическое incerment смещение

Answer 6

остановки ведомого; установить глобальный sql_slave_skip_counter = 1; запустить раб;

Вы можете игнорировать только текущую ошибку и продолжить процесс репликации.