mariadb 复制（主/从） - 由于删除查询执行时间较长，从属滞后答案

【问题标题】：mariadb replication (master / slave) - slave lagging behind due to long execution on delete querymariadb 复制（主/从） - 由于删除查询执行时间较长，从属滞后
【发布时间】：2020-11-11 17:08:51
【问题描述】：

我已经设置了一个非常经典的 MariaDB 10.4.13 复制 GTID 设置，带有两台服务器（可写主服务器和只读从服务器）。

一段时间以来，我注意到路由到从站的一些应用程序 SELECT 查询存在一些不一致。经过一些故障排除后，我发现从站的“Seconds_Behind_Master”值增长到 10,000 秒 (!)。

通过在从属设备上执行 SHOW PROCESSLIST，我注意到长查询，例如：

 11 | system user | | NULL | Slave_SQL | 14 | Delete_rows_log_event :: find_row (-1) | DELETE FROM `mytable` WHERE` id` = 5580

每一个都需要超过 20 秒的时间来执行（！），所以它们会累积并导致滞后......

在主服务器上启动的相同删除查询是瞬时的（0.031 秒） - 此外，从硬件比主硬件更强大（4 核 CPU 与 2 核 CPU），从服务器上的平均负载/CPU 非常低。

我已经尝试将并行“slave_parallel_threads”增加到从 CPU 的数量（4）正如here 解释的那样，但没有任何好处。

关于如何解决此问题或提高复制性能以保持主/从同步的任何线索？

【问题讨论】：

标签： mysql mariadb replication

【解决方案1】：

DELETE FROM mytable WHERE id = 5580 是整个查询吗？（可能除了表名。）

id 上没有索引吗？

如果id 是UNIQUE 或PRIMARY，那应该只需要几毫秒。

slave_parallel_threads -- 其他线程是否触及同一张表？

如果您要删除大量行，请参阅http://mysql.rjweb.org/doc.php/deletebig

也许在那张桌子上正在执行一个大的ALTER？

【讨论】：

【解决方案2】：

是的，问题是由于应用程序中的表格设计不佳造成的。

表缺少 UNIQUE / PRIMARY 键，因此 DELETE 对 slave 的查询需要很长时间，正如 here 所解释的那样

我通过在表上创建主索引并随后重建 SLAVE 来修复，到目前为止不再滞后:)

【讨论】：