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的结果：
Purge done for trx's n:o < 63937358965 undo n:o < 0 state: running
History list length 1704027077
Purge done for trx's n:o < 63937393786 undo n:o < 0 state: running
History list length 1704037619
Purge done for trx's n:o < 63937425346 undo n:o < 0 state: running
History list length 1704049023
Purge done for trx's n:o < 63937468691 undo n:o < 118 state: running
History list length 1704060157
从上面来看，purge的速度超过undo产生的速度，以为可以有希望undo能被清理
但是接下来2分钟又获取了这个数据如下：
Purge done for trx's n:o < 63937861327 undo n:o < 0 state: running
History list length 1705084819
Purge done for trx's n:o < 63937861327 undo n:o < 0 state: running
History list length 1705153982
Purge done for trx's n:o < 63937868288 undo n:o < 0 state: running
History list length 1705178010
这个undo产生的速度远远高于purge的速度。
并且我们的从库也是存在这个undo大文件 :L
已经让开发优化过一波事务有点效果，但是看还不够，
服务器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性能才能抗住。
页:
1
[2]