Я столкнулся с той же проблемой и исправил с помощью следующих шагов. Полная ссылка на тему: http://www.percona.com/forums/questions-discussions/percona-xtrabackup/11842-backup-stopped-working-slave-sql-running-no
Шаги такие же, как упомянуто @ Luxknight007, за исключением его шага 2. Однако эта нить содержит больше деталей, что очень полезно. Следующее - решение, которое я использовал, и это работало.
"Первая проблема заключается в том, что вы изменили положение репликации вместо того, чтобы исправить ошибку, и использовали неверный формат имени файла binlog (вы, вероятно, просто использовали тот из того поста, который вы связали, я думаю). Чтобы вернуться к там, где вы начали, вам нужно найти файл binlog и положение, в котором остановился подчиненный sql_thread. На основании вашего вывода статуса ведомого, похоже, что ведомое устройство читает из нового файла binlog (вы можете видеть, что значение Read_Master_Log_Pos меньше, чем значение Exec_Master_Log_Pos, что означает, что он должен читать более новый файл binlog, чем тот, на котором остановился slav sql_thread), поэтому вам нужно найти файл binlog, на котором фактически произошел сбой slave sql_thread. Так что ищите в журнале ошибок что-то вроде ниже:
Код:
2013-10-08 12:48:51 37545 [ERROR] Slave SQL: Error 'Table 'testdb.test2' doesn't exist' on query. Default database: 'testdb'. Query: 'insert into test1 select * from test2', Error_code: 1146
2013-10-08 12:48:51 37545 [Warning] Slave: Table 'testdb.test2' doesn't exist Error_code: 1146
2013-10-08 12:48:51 37545 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000001' position 3427
Это образец, который я воссоздал, так что ваш будет немного другим. Обратите внимание, что ОШИБКА похожа на то, что вы видите в своем статусе подчиненного. Поэтому найдите свое конкретное сообщение об ошибке в файле журнала ошибок, а затем найдите конечную часть, где находится имя файла и его позиция (в нашем примере «Мы остановились на позиции« mysql-bin.000001 », позиция 3427»). Позиция должна быть 315098143 в зависимости от вашего статуса подчиненного шоу, так как в этом случае подчиненный sql_thread прекратил выполнение событий (Exec_Master_Log_Pos), но io_thread продолжал читать в новых (Read_Master_Log_Pos).
Как только вы найдете правильное имя и положение файла binlog, повторно запустите ваш главный оператор изменений на ведомом устройстве, используя информацию, которую вы нашли в журнале ошибок. Обратите внимание, что имя вашего файла должно быть что-то вроде «newcrmdb1-bin.XXXXXX», а не mysql-bin.XXXXXX (вы можете увидеть это соглашение об именах выше для своего статуса show slave).
Код:
mysql> change master to MASTER_LOG_FILE='newcrmdb1-bin.XXXXXX', Master_Log_Pos=315098143;
change master to MASTER_LOG_FILE='mysql-bin.000082' , Master_Log_Pos=47914844;
Как только вы вернетесь к исходному местоположению репликации, где произошел сбой ведомого sql_thread, вам нужно будет исправить ошибку, с которой он жаловался, чтобы начать.
Кажется, что первоначальная ошибка репликации говорит о том, что таблица asteriskcdr. bpleadcf не существует на ведомом устройстве, поэтому оператор вставки завершается неудачно, когда он пытается выбрать данные из этой таблицы. Таким образом, проблема в том, что ваш раб, похоже, уже не синхронизирован с вашим хозяином. Если рассматриваемая таблица на ведущем устройстве является статической или в основном статической, вы, вероятно, можете решить эту проблему, экспортировав данные только из этой таблицы на ведущем устройстве с помощью mysqldump и загрузив их в ведомое устройство. Если это невозможно или вам не нужны эти данные, вы всегда можете просто пропустить оператор репликации с помощью sql_slave_skip_counter, но тогда ведомое устройство будет еще не синхронизировано с ведущим.
А если ничего не помогает, вы всегда можете перестроить раба из мастера в качестве крайней меры. =) "