mysql - 为什么长时间运行的选择查询会导致 MySQL 从属数据库中的复制滞后？

Question

我们有一个带有副本的 MySQL(5.7 带有基于行的复制)。

现在，主服务器以每秒大约 3000 次插入的峰值执行，而副本似乎读取得很好。但是，有时我们会执行长时间的选择查询(运行 10 到 20 秒)。在这些查询期间，复制滞后变得非常大。

我不明白的是，通常执行选择的 mysql 线程(不锁定任何表)如何导致复制线程变慢(即它执行大约 2.5K 插入而不是像 master 那样执行 3K)？我需要准确调整什么？

现在我检查了从站状态，这与 IO 线程无关——这个从主站读取事件就好了。它是 SQL 从属线程，不知何故无法 catch 。隔离级别为 Read Committed，因此选择查询可能会锁定某些记录并使从属线程等待。但我不确定。

已更新。我再次检查 - 事实证明，即使是从站上的单个繁重查询(例如扫描整个表)也会产生滞后。好像slave sql线程被阻塞了，但我不明白为什么？

更新 2。我终于找到了解决方案。首先，我将 slave_parallel_workers 的数量增加到 4，并将 slave_parallel_type 设置为 LOGICAL_CLOCK。然而，这很重要，这对我没有任何改善，因为交易是相关的。但是，在我将 master binlog_group_commit_sync_delay 增加到 10000(即 10 毫秒)后，延迟消失了。

Answer 1

mysql从属数据库复制滞后的原因可能有很多。但是正如你所说

It's SQL slave thread, that somehow does not manage to catch up.

假设 IO 工作正常，Percona说(强调我的):

[...] when the slave SQL_THREAD is the source of replication delays it is probably because of queries coming from the replication stream are taking too long to execute on the slave. This is sometimes because of different hardware between master/slave, different schema indexes, workload. Moreover, the slave OLTP workload sometimes causes replication delays because of locking.
For instance, if a long-running read against a MyISAM table blocks the SQL thread, or any transaction against an InnoDB table creates an IX lock and blocks DDL in the SQL thread. Also, take into account that slave is single threaded prior to MySQL 5.6, which would be another reason for delays on the slave SQL_THREAD.