从 Mysql 5.7 升级到 Mysql 8.0.32 后出现巨大的复制延迟

Question

在我的设置中，我有一个源和一个副本。复制在 MySQL 5.7 上一直运行良好。最近我们升级到了MySQL 8.0.32，从那以后我们不断地遇到副本与源相比的高延迟。复制基于二进制日志（未迁移到 GTID）。

到目前为止我尝试过的事情：

• 在副本处重新启动 mysql 服务
• 检查网络/CPU利用率
• 检查分配的内存和内存利用率
• 检查磁盘读写情况
• 在副本中查找长时间运行的用户查询并终止它们，这样它们就不会阻塞复制 SQL 线程。
• 检查没有主键的复制表：我们有 5 个这样的表，但它们都不超过 100k 条记录。

我希望能得到任何关于还需要检查哪些内容以找到延迟的根本原因以及如何解决它的提示。

显示副本状态：

Slave_IO_Running：是 Slave_SQL_Running：是 落后大师秒数：76824 最后 IO 错误号：0 最后 IO 错误： Last_SQL_Errno: 0 最后一个 SQL 错误： SQL_延迟：0 SQL_Remaining_Delay：NULL Slave_SQL_Running_State：等待依赖事务提交 Master_Retry_Count：86400 主控_绑定： 最后 IO 错误时间戳： Last_SQL_Error_Timestamp：

显示进程列表

8 event_scheduler localhost 守护进程 244034 等待空队列
44636 系统用户连接主机 Connect 19361 等待源发送事件
44637 系统用户查询 0 等待依赖事务提交 44638 系统用户查询 78677 应用批量行更改（更新）

编辑：

mysql 托管在 Azure VM 上 操作系统版本 Windows Server 2019 Datacenter 内存大小 256 GB 核心数量 32 任何 SSD 高级 SSD LRS

请在以下位置查找更多信息：https://justpaste.it/aizb0

Answer 1

每秒速率 = RPS

针对 Azure 门户、设置、服务器参数考虑的建议

innodb_thread_concurrency=0  # from 65 to avoid overloading CPU's let system manage
max_connections=512  # from 10000 - max_used_connections was 149 for the day
innodb_max_dirty_pages_pct_lwm=.00001  # from 10% to enable pre-flushing earlier
innodb_max_dirty_pages_pct=.00001  # from 90% to reduce pages_dirty of 157,602
read_rnd_buffer_size=16384  # from 262144 to reduce handler_read_rnd_next RPS of 160,262

这些只是缓解导致反应滞后的压力点的 5 个 - 还有更多。

来自 SHOW GLOBAL STATUS 的观察结果 com_rollback 有 6,355 个事件，每 17 秒平均 1 次，占用大量资源，如果可以的话，请防止 - 通常有方法可以避免。

com_savepoint 计数为 35，通常我们会看到 com_release_savepoint 具有匹配的值。 您的 com_release_savepoint 为 0，表示资源未释放。

使用索引可以避免 select_scan 频率 88 RPS - RPhr 315,423

请查看个人资料。