mysql8.0.22版本undo文件过大，如何快速清理？

yejr 发表于 2024-9-19 10:53
看了下数据变化，这一分钟内，新增的事务比已被purge的事务数更小
75337103297 - 75336947794 = 155503
7 ...

叶老师，75337103297 - 75336947794 = 155503（这应该是已经清理的增量吧）
7170881878 - 7170617944 = 263934（这个是等待清理的增量），应该是：新增的事务比已被purge的事务数更大吧？

wenbc 发表于 2024-9-19 17:48
叶老师，75337103297 - 75336947794 = 155503（这应该是已经清理的增量吧）
7170881878 - 7170617944 = 26 ...

对的对的，抱歉抱歉，脑子瓦特了。

等待被purge的undo增速比新增事务更高，因此purge跟不上进度，所以undo越来越大。

可以尝试几个方案：

1. 进行高可用切换，切到高可用备机上。

2. 控制前端应用服务器的请求量。

3. 想办法降低这个服务器上的负载，比如把只读请求流量切换到从节点。

yejr 发表于 2024-9-19 20:30
对的对的，抱歉抱歉，脑子瓦特了。

等待被purge的undo增速比新增事务更高，因此purge跟不上进度，所以und ...

这是半小时前连续4分钟使用show engine innodb status的结果：

1. Purge done for trx's n:o < 63937358965 undo n:o < 0 state: running
   
2. History list length 1704027077
   
3. 
   
4. Purge done for trx's n:o < 63937393786 undo n:o < 0 state: running
   
5. History list length 1704037619
   
6. 
   
7. Purge done for trx's n:o < 63937425346 undo n:o < 0 state: running
   
8. History list length 1704049023
   
9. 
   
10. Purge done for trx's n:o < 63937468691 undo n:o < 118 state: running
    
11. History list length 1704060157

复制代码

从上面来看，purge的速度超过undo产生的速度，以为可以有希望undo能被清理

但是接下来2分钟又获取了这个数据如下：
Purge done for trx's n < 63937861327 undo n < 0 state: running
History list length 1705084819

Purge done for trx's n < 63937861327 undo n < 0 state: running
History list length 1705153982

Purge done for trx's n < 63937868288 undo n < 0 state: running
History list length 1705178010
这个undo产生的速度远远高于purge的速度。

并且我们的从库也是存在这个undo大文件

已经让开发优化过一波事务有点效果，但是看还不够，
服务器12小时内的平均负载是130

备份的话也是会把这个undo文件备份进去

fengzhencai 发表于 2024-9-25 16:48
这是半小时前连续4分钟使用show engine innodb status的结果：

从上面来看，purge的速度超过undo产生的 ...

利用备份恢复启动从库后，先不设置主从复制关系，等所有undo都purge完了再启动复制关系，看能不能追上。
等追上后再高可用切换到从库。

yejr 发表于 2024-9-26 13:32
利用备份恢复启动从库后，先不设置主从复制关系，等所有undo都purge完了再启动复制关系，看能不能追上。
...

太难追了，有87亿的undo需要处理

fengzhencai 发表于 2024-9-26 14:59
太难追了，有87亿的undo需要处理

问题解决，解决方案是：
把部分业务分拆出去，这样这个库的事务量久骤然减少，通过2-3天的时间把undo文件purge掉了

fengzhencai 发表于 2024-10-12 14:55
问题解决，解决方案是：
把部分业务分拆出去，这样这个库的事务量久骤然减少，通过2-3天的时间把undo文件 ...

看来还是得降低事务并发量或者提升服务器的I/O性能才能抗住。