Большая задержка репликации mysql (Relay_Log_Pos и ​​Exec_Master_Log_Pos не увеличивается)

Сегодня два моих подчиненных (один mysql 5.1 и второй MariaDB 5.5, главный - mysql 5.1) начали отставать. Подобная ситуация довольно часто с задержками возрастает даже до 10000 секунд, потому что ведомые устройства имеют худшую аппаратную конфигурацию, чем ведущие, но сейчас я очень напряжен. Лаги на обоих серверах все еще растут, и на данный момент он отстает от мастера на 25 тысяч секунд. Итак, я начал исследовать, что происходит не так. Просмотр журналов mysql на главном и подчиненном серверах ничего мне не дал. Серверы находятся на Centos 5, а Mariadb - на Centos 6.

Это вывод из статуса подчиненного устройства MariaDB:

MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: masterserevr
                  Master_User: slaveuser
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysqld-bin.006778
          Read_Master_Log_Pos: 401041447
               Relay_Log_File: relay-bin.020343
                Relay_Log_Pos: 14867924
        Relay_Master_Log_File: mysqld-bin.006777
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: ses,phar
           Replicate_Do_Table: 
       Replicate_Ignore_Table: portal.aaa_jm_tmp,portal.newsletter
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 14867639
              Relay_Log_Space: 1474785535
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 26484
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
1 row in set (0.00 sec)

Из нескольких выходов я заметил, что Relay_Log_Pos и ​​Exec_Master_Log_Pos не увеличивается. Я попытался перезапустить подчиненные процессы, но это ничего не изменило, и лаги все еще увеличиваются. Следующим шагом было посмотреть, на каком запросе остановлена ​​репликация.

С помощью mysqlbinlog

mysqlbinlog relay-bin.020343 > /root/RelayLogQueries1.txt

В RelayLogQueries1.txt я нашел позицию 14867924:

# at 14867924
#130927 10:03:21 server id 1  end_log_pos 14867709      Query   thread_id=160780134     exec_time=3     error_code=0
SET TIMESTAMP=1380269001/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=9/*!*/;
BEGIN
/*!*/;
# at 14867994
# at 14868101
# at 14868669
# at 14869417
# at 14869873
# at 14870663
# at 14871697
# at 14872055
# at 14872845
# at 14873747
# at 14874591
# at 14875387
# at 14876265
# at 14877039
# at 14877985
# at 14878299
# at 14879091
# at 14879853
# at 14880255
# at 14881029
.
.
.
# at 117398235
# at 117399219
# at 117400203
# at 117401191
# at 117402179
# at 117403167
# at 117403969
# at 117404957
# at 117405945
# at 117406933
# at 117407921
# at 117408909
# at 117409897
# at 117410885
# at 117411873
# at 117412861
# at 117413849
# at 117414837
# at 117415785
# at 117416797
# at 117417839
# at 117418595
# at 117419585
#130927 10:03:21 server id 1  end_log_pos 14867816      Table_map: `test`.`pac_list` mapped to number 216570427
#130927 10:03:21 server id 1  end_log_pos 14868384      Update_rows: table id 216570427
#130927 10:03:21 server id 1  end_log_pos 14869132      Update_rows: table id 216570427
#130927 10:03:21 server id 1  end_log_pos 14869588      Update_rows: table id 216570427
#130927 10:03:21 server id 1  end_log_pos 14870378      Update_rows: table id 216570427
#130927 10:03:21 server id 1  end_log_pos 14871412      Update_rows: table id 216570427
#130927 10:03:21 server id 1  end_log_pos 14871770      Update_rows: table id 216570427
#130927 10:03:21 server id 1  end_log_pos 14872560      Update_rows: table id 216570427
#130927 10:03:21 server id 1  end_log_pos 14873462      Update_rows: table id 216570427
.
.
.

Теперь я сбит с толку, потому что, во-первых, я не знаю, как интерпретировать этот журнал (нормально это или неправильно), а во-вторых, не знаю, как это исправить.

Иногда, когда я получаю ошибки репликации, мне помогает этот трюк:

SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;

Но теперь у меня нет ошибок, и выполняются процессы IO и SQL slave.

Может ли установка SQL_SLAVE_SKIP_COUNTER = 1 вернуть репликацию на ??

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

РЕДАКТИРОВАТЬ: задержка начала, когда один из разработчиков случайно скопировал одну из таблиц pac_list (200 МБ с 600000 записями), и он скопировал ее с именем test.pac_list (у нее есть точка в имени таблицы), он хочет создать копию в тесте базы данных, но он сделал что-то не так и создать таблицу test.pac_list в той же базе данных, что и исходная таблица. После того, как он обнаружил свою ошибку, он удалил таблицу test.pac_list и создал таблицы pac_list в новой базе данных. Не в этом ли причина такого большого отставания?