我的 MySql DB 上有一个主/从复制。
我的从数据库宕机了几个小时，然后又恢复了（主数据库一直在运行），当发出 show slave status 时，我可以看到从数据库比主数据库晚 X 秒。
问题是slave似乎没有追上master，master后面的X秒似乎没有下降......
关于如何帮助奴隶赶上的任何想法？
【问题讨论】：
标签： mysql replication mysql-management
这是一个想法
为了让您知道 MySQL 正在完全处理来自中继日志的 SQL。请尝试以下操作：
STOP SLAVE IO_THREAD;
这将阻止复制将新条目从主服务器下载到其中继日志中。
另一个线程，称为 SQL 线程，将继续处理它从 master 下载的 SQL 语句。
当您运行SHOW SLAVE STATUS\G 时，请留意Exec_Master_Log_Pos。再次运行SHOW SLAVE STATUS\G。如果一分钟后Exec_Master_Log_Pos 没有移动，您可以继续运行START SLAVE IO_THREAD;。这可能会减少Seconds_Behind_Master 的数量。
除此之外，你真的无能为力：
Seconds_Behind_Master
Exec_Master_Log_Pos
SHOW PROCESSLIST;，记下SQL线程，看看它是否在处理长时间运行的查询。BTW 请记住，当您在运行复制的情况下运行SHOW PROCESSLIST; 时，应该有两个用户名为system user 的数据库连接。这些数据库连接之一将通过复制处理当前的 SQL 语句。只要每次运行 SHOW PROCESSLIST; 时都可以看到不同的 SQL 语句，就可以相信 mysql 仍在正常复制。
【讨论】：
您使用什么二进制日志格式？您使用的是 ROW 还是 STATEMENT ？
SHOW GLOBAL VARIABLES LIKE 'binlog_format';
如果您使用 ROW 作为二进制日志格式，请确保您的所有表都有主键或唯一键：
SELECT t.table_schema,t.table_name,engine
FROM information_schema.tables t
INNER JOIN information_schema .columns c
on t.table_schema=c.table_schema
and t.table_name=c.table_name
and t.table_schema not in ('performance_schema','information_schema','mysql')
GROUP BY t.table_schema,t.table_name
HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;
如果你执行例如主节点上的一条 delete 语句删除没有 PK 或唯一键的表上的 100 万条记录，那么主节点将只进行一次全表扫描，而从节点则不会发生这种情况。
当使用 ROW binlog_format 时，MySQL 将行更改写入二进制日志（不是像 STATEMENT binlog_format 这样的语句），并且该更改将逐行应用于从站一侧，这意味着 100 万次全表扫描将发生在从站上，以反映主站上的一个删除语句，这会导致从站滞后问题。
【讨论】：
“落后秒数”并不是一个很好的工具，可以让你知道你到底落后了多少。它说的是“我刚刚执行的查询是 X 秒前在主服务器上执行的”。这并不意味着你会在下一秒追上并紧随主人。
如果你的从服务器通常不落后并且主服务器的工作量大致恒定，你会赶上，但可能需要一些时间，如果从服务器通常只是勉强跟上，它甚至可能需要“永远”大师。从属服务器在一个线程上运行，因此它在设计上比主服务器慢得多，而且如果有一些查询在主服务器上需要一段时间，它们会在从服务器上运行时阻塞复制。
【讨论】：
只需检查两台服务器（即主服务器和从服务器）上的时间和时区是否相同。
【讨论】：
如果您使用的是 INNODB 表，请检查您的 innodb_flush_log_at_trx_commit 是否与 SLAVE 中的 0 不同。
http://dev.mysql.com/doc/refman/4.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit
【讨论】：
从最近的备份设置我们的奴隶后，我们遇到了完全相同的问题。
我们已经更改了从站的配置以更加安全：
sync_binlog = 1
sync_master_info = 1
relay_log_info_repository = TABLE
relay_log_recovery = 1
我认为尤其是 sync_binlog = 1 会导致问题，因为该从属设备的规格不如主设备那么快。此配置选项强制从服务器在执行之前将每个事务存储在二进制 lo 中（而不是默认的每 10k 个事务）。
在将这些配置选项再次禁用为默认值后，我看到从站再次赶上。
【讨论】：
只是在我的类似案例中添加调查结果。
master 中很少发生批量临时表插入/更新/删除，占用了 slave 中中继日志的大部分空间。而在 Mysql 5.5 中，由于是单线程的，CPU 总是在 100% 并且需要花费大量时间来处理这些记录。
我所做的只是将这些行添加到 mysql cnf 文件中
replicate-ignore-table=<dbname>.<temptablename1>
replicate-ignore-table=<dbname>.<temptablename2>
一切又恢复了平静。
为了确定哪些表在中继日志中占用更多空间，请尝试以下命令，然后在文本编辑器中打开。你可能会得到一些提示
cd /var/lib/mysql
mysqlbinlog relay-bin.000010 > /root/RelayQueries.txt
less /root/RelayQueries.txt
【讨论】：
如果您有多个架构，请考虑使用多线程从属复制。这是相对较新的功能。
这可以在不停止服务器的情况下动态完成。只需停止从属 sql 线程。
STOP SLAVE SQL_THREAD;
SET GLOBAL slave_parallel_threads = 4;
START SLAVE SQL_THREAD;
【讨论】：