我正在运行 MySQL 的主从复制服务器。作为清理旧数据的一部分，我运行了一个删除查询，该查询从数据库中删除了大量记录。它在主服务器上运行良好，但在从服务器上，它给了我以下错误：
从 SQL 线程徒劳地重试了事务 10 次，放弃了。考虑提高 slave_transaction_retries 变量的值。
从服务器机器不如主服务器机器强大。我怎样才能克服这个？
该查询是单行删除查询。我正在运行 MySQL 5.6。
AskOverflow.Dev
您需要停止复制，使 Slave 具有与 Master 相同的规格，然后开始复制。
确保从站没有传入连接。否则，这将使 Slave 上的 SQL 线程与
SELECT对您正在运行的同一个表运行查询的传入连接竞争DELETE。如果您无法重新路由传入的连接，则必须
DELETE在本地重新运行 Slave 上的 in 块（一次可能 5000 行）。作为最后的手段，重建奴隶（在扩大奴隶的硬件和配置之后）。
有多个问题；我将尝试涵盖其中的大部分内容。
直到最近，复制还是单线程的。（即使是现在，它在多线程方面也有限制。）所以，Master 很容易并行地做很多事情，但是一旦发送到 Slave 并串行运行，Slave 就会落后。如果 Slave 的硬件比 Master 慢，情况会更糟。
根据您的配置，可以使用 SBR 或 RBR 运行删除一百万行的单行删除。细节明显不同：
SBR（Statement Based Replication）：Master 完成删除后，快速复制语句。复制（假设为单线程）挂起，直到从站可以删除所有百万行。这需要时间。所有后续的复制命令都将坐等；奴隶“落后”。
RBR（Row Based Replication）：Master 完成删除后，通过网络将一百万条单行记录泵送到 Slave。这增加了开销。但是由于流的简单性，从属可以（可能）更快地执行删除。尽管如此，复制将被捆绑一段不平凡的时间，在此期间，从站将“落后”。
再多的硬件也无法阻止“落后”。
同时，任何
SELECTs击中该表的 Slave 都会受到一定程度的影响，反之亦然。也就是说，SELECTs可能会减慢删除速度。大删除是一个常见问题。 我的博客描述了几种解决方案。它包括有关如何进行 Rolando 建议的“分块”的详细信息。
如果您“分块”并使每个块成为自己的事务，那么对主服务器和从服务器的影响都较小。缺点是崩溃可能会使表中的一些块被删除，有些则不会。（重新运行分块删除可能既简单又安全。）
我假设删除的大小（因此，时间长度）会导致错误消息。
请注意，我的博客中的建议之一是……如果要删除表的“大部分”，请复制要保留的行，然后重命名以交换表。快很多等等。