MySQL Binary Log Replication: можно ли игнорировать ошибки?

Question

Я использую систему репликации двоичных журналов MySQL «ведущий-ведомый» (фу!), Которая для некоторых данных не синхронизирована (то есть мастер хранит больше данных, чем ведомый). Но ведомый очень часто останавливается на малейшей ошибке 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, которая не убьет ведомого при первой ошибке .

Приветствия

/ * т.пл. 1015 *

Answer 1

стоп раб; установить глобальный sql_slave_skip_counter = 1; начать раб;

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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