今天我的两个从服务器（一个是 mysql 5.1，另一个是 MariaDB 5.5，主服务器是 mysql 5.1）开始滞后。类似的情况经常发生，滞后甚至会上升到 10000 秒，因为从服务器的硬件配置比主服务器差，但现在我压力很大。两台服务器上的滞后仍在增加，此时它落后主服务器 25K 秒。所以我开始调查出了什么问题。查看主服务器和从服务器上的 mysql 日志，什么也没得到。服务器在 Centos 5 上，Mariadb 在 Centos 6 上。
这是 MariaDB 从属状态的输出：
MariaDB [(无)]>显示从属状态\G
**************************** 1. 行 ****************************
Slave_IO_State：等待主机发送事件
Master_Host: masterserevr
Master_User: 从属用户
主端口：3306
连接重试：60
Master_Log_File：mysqld-bin.006778
读取主日志位置：401041447
Relay_Log_File: Relay-bin.020343
中继日志位置：14867924
Relay_Master_Log_File: mysqld-bin.006777
Slave_IO_Running：是
Slave_SQL_Running：是
复制_Do_DB：
Replicate_Ignore_DB：ses，phar
复制执行表：
复制忽略表：portal.aaa_jm_tmp，portal.newsletter
复制_野生_执行_表：
复制_野生_忽略_表：
Last_Errno： 0
最后错误：
Skip_Counter：0
Exec_Master_Log_Pos：14867639
中继日志空间：1474785535
Until_Condition：无
直到日志文件：
直到日志位置: 0
Master_SSL_Allowed：否
Master_SSL_CA_文件：
Master_SSL_CA_路径：
主 SSL 证书：
Master_SSL_Cipher：
主 SSL 密钥：
落后大师秒数：26484
Master_SSL_Verify_Server_Cert：否
Last_IO_Errno： 0
上次输入输出错误：
Last_SQL_Errno： 0
上次 SQL 错误：
复制忽略服务器 ID：
Master_Server_Id：1
1 行 (0.00 秒)
从几个输出中我注意到 Relay_Log_Pos 和 Exec_Master_Log_Pos 没有增加。我尝试重新启动从属进程，但没有任何变化，并且滞后仍然增加。下一步是查看在哪个查询上复制已停止。
使用mysqlbinlog
mysqlbinlog Relay-bin.020343 > /root/RelayLogQueries1.txt
在 RelayLogQueries1.txt 中我找到了位置 14867924：
# 14867924 #130927 10:03:21 服务器 ID 1 end_log_pos 14867709 查询线程 ID=160780134 exec_time=3 错误代码=0 设置时间戳=1380269001/*!*/; /*!\C utf8 *//*!*/; 设置@@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=9/*!*/; 开始 /*！*/； # 在 14867994 # 在 14868101 # 在 14868669 # 14869417 # 在 14869873 # 在 14870663 # 在 14871697 # 14872055 # 14872845 # 在 14873747 # 在 14874591 # 在 14875387 # 14876265 # 14877039 # 14877985 # 在 14878299 # 在 14879091 # 14879853 # 14880255 # 14881029 。 。 。 # 117398235 # 117399219 # 117400203 # 在 117401191 # 117402179 # 117403167 # 117403969 # 117404957 # 117405945 # 117406933 # 在 117407921 # 在 117408909 # 117409897 # 117410885 # 在 117411873 # 在 117412861 # 117413849 # 117414837 # 117415785 # 在 117416797 # 在 117417839 # 在 117418595 # 117419585 #130927 10:03:21 服务器 ID 1 end_log_pos 14867816 Table_map: `test`.`pac_list` 映射到编号 216570427 #130927 10:03:21 服务器 ID 1 end_log_pos 14868384 Update_rows：表 ID 216570427 #130927 10:03:21 服务器 ID 1 end_log_pos 14869132 Update_rows：表 ID 216570427 #130927 10:03:21 服务器 ID 1 end_log_pos 14869588 Update_rows：表 ID 216570427 #130927 10:03:21 服务器 ID 1 end_log_pos 14870378 Update_rows：表 ID 216570427 #130927 10:03:21 服务器 ID 1 end_log_pos 14871412 Update_rows：表 ID 216570427 #130927 10:03:21 服务器 ID 1 end_log_pos 14871770 Update_rows：表 ID 216570427 #130927 10:03:21 服务器 ID 1 end_log_pos 14872560 Update_rows：表 ID 216570427 #130927 10:03:21 服务器 ID 1 end_log_pos 14873462 Update_rows：表 ID 216570427 。 。 。
现在我很困惑，因为首先我不知道如何解释这个日志（它是可以的还是错误的），其次我不知道如何解决这个问题。
有时当我遇到一些复制错误时，这个技巧很有用：
设置全局 SQL_SLAVE_SKIP_COUNTER=1;启动从属；
但是现在我没有错误并且 IO 和 SQL 从属进程都在运行。
设置 SQL_SLAVE_SKIP_COUNTER=1 是否可以恢复复制？？
我该怎么做才能进一步诊断此问题并修复它而无需从头开始设置副本（我想避免最后一种情况）
编辑：延迟开始于一名开发人员意外复制了其中一个表 pac_list（200MB，有 600000 条记录）并将其命名为 test.pac_list（表名中有一个点）时，他想在数据库测试中创建副本，但他做错了，在原始表所在的同一数据库中创建了表 test.pac_list。在他发现自己的错误后，他删除了表 test.pac_list，并在新数据库中创建了表 pac_list。这可能是延迟如此之大的原因吗？
答案1
执行显示完整进程列表来查看哪些查询正在挂起复制。
另外，我看到有一个开始：
14867924
设置时间戳=1380269001/！/;
设置@@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=9/！/;
开始
因此可能是复制被锁定直到结束？
答案2
您有一个巨大的事务，从属进程正在处理它。您需要等待它完成。不要跳过该事务，否则您可能需要重新初始化从属进程。
如果您愿意承担在发生操作系统崩溃/电源故障时必须重新初始化从属服务器的风险，那么您可以采取各种措施来加速从属服务器。
您还应该关心您距离 5.1 的 EOL 有多远。