PolarDB中undolog大部分以独立表空间(独立文件)存在的,目前分了8个文件,文件名为undo001-undo008,每个文件默认初始大小为10M。
如果发现undolog占用量比较大,可以采用以下方式清理:
1、调整innodb_max_undo_log_size大小为10M;
2、打开truncate开关innodb_undo_log_truncate;
以上操作执行后,集群会把所有大于innodb_max_undo_log_size设置的undo tablespace调整为10M。
注:如果发现参数修改界面找不到innodb_undo_log_truncate参数:一些历史版本存在undo trucate相关缺陷,关闭了innodb_undo_log_truncate的修改,导致在参数修改界面看不到这个参数。遇到这种情况可以考虑升级到最新的小版本解决
需要注意:
避免在业务高峰及存在大事务情况下操作,清理完成后关闭truncate功能,避免业务高峰期间引发数据库延迟。
打开innodb_undo_log_truncate依然不能回收的原因及排查方式:
1. 存在未提交老事务
PolarDB中的undo log承担MVCC的历史版本作用,因此当有未提交事务持有老的Read View会阻塞undo log的清理,造成空间积累。可用如下命令查看是否存在大事务select * from information_schema.innodb_trx;需要注意,PolarDB的只读节点由于跟读写节点共享存储,只读节点上的未提交大事务同样会影响undo log的清理出现这种问题,需要结束对应的事务
2. undo清理动作滞后
当写入压力大时,PolarDB的策略会优先保证当前的写入性能,可能会导致undo log的清理滞后,可以通过如下命令查看当前undo history的长度:select COUNT from information_schema.innodb_metrics where name = 'trx_rseg_history_len';如果这值还在不断地上升,并且当前压力确实比较大,可以通过如下步骤调整:
1),调大参数innodb_purge_batch_size,这个不需要重启实例,可以观察一段时间2),调大参数innodb_purge_threads,建议跟实例规格核数一致,这个需要重启实例,建议业务低峰操作等待undo history长度降低以后,undo空间会停止增长
等清理结束后,undo truncate会生效