开发者社区> 问答> 正文

PolarDB日志空间膨胀

已解决

PolarDB日志空间膨胀

展开
收起
提个问题 2024-06-13 10:06:57 34 0
1 条回答
写回答
取消 提交回答
  • 开发者社区问答官方账号
    官方回答
    采纳回答
    PolarDB的日志占用可能包括redo日志,undo日志及binlog:

    1. Redo日志
    Redo日志承担着故障恢复,主备同步,备份还原等作用,正常情况下会在备份完成后自动清理,无需手动干预。
    但由于Redo文件缓存池的存在,通常Redo空间占用会在2GB~11 GB左右,最多时会占用11 GB,其中包括缓冲池中8个Redo日志(8 GB)、正在写的Redo日志(1 GB)、提前创建的Redo日志(1 GB)以及最后一个Redo日志(1 GB)。
    可以通过参数loose_innodb_polar_log_file_max_reuse调整保留的Redo文件缓存个数,默认值为8。可以修改这个参数从而减少日志空间占用量,但在压力大的情况下,性能可能会出现周期性的小幅波动。


    2. Undo 日志
    • 检查是否有老事务未提交
      PolarDB中的undo log承担MVCC的历史版本作用,因此当有未提交事务持有老的Read View会阻塞undo log的清理,造成空间积累。可用如下命令查看是否存在大事务select * from information_schema.innodb_trx;需要注意,PolarDB的只读节点由于跟读写节点共享存储,只读节点上的未提交大事务同样会影响undo log的清理出现这种问题,再kill掉事务对应的线程后,undo会停止继续扩大, 如果需要undo文件回收,可以通过如下步骤中确定undo hisotry推进解释后,再进行undo文件的空间清理(truncate)
    • 确定是否undo清理滞后当写入压力大时,PolarDB的策略会优先保证当前的写入性能,可能会导致undo log的清理滞后,可以通过如下命令查看当前undo history的长度:select COUNT from information_schema.innodb_metrics where name = 'trx_rseg_history_len';如果这值大于100万,或者几分钟的时间内,还在不断地上升,并且当前压力确实比较大,可以通过如下步骤调整:1),调大参数innodb_purge_batch_size,这个不需要重启实例,可以观察一段时间2),调大参数innodb_purge_threads,建议跟实例规格核数一致,这个需要重启实例,建议业务低峰操作等待undo history长度降低以后,undo空间会停止增长,如果需要回收undo空间,见如下步骤打开undo truncate进行清理可以调整
    • innodb_undo_log_truncate=ON,来打开undo truncate,由于这个功能会在实例切换或重启是带来额外的开销, 建议在空间回收后就关闭,尤其是需要发起如小版本升级等任务之前先关闭。需要的时候再打开。PolarDB维护8个undo文件,当单个文件超过innodb_max_undo_log_size后,就会触发undo truncate,这个默认一共8G,因此如果长时间超过8G,写入压力较小,并且实例版本比较老,可以尝试做小版本升级来解决更多关于undo log的维护及清理详情见:Undo Log维护及清理原理


    3. Binlog
    可以重新打开 Binlog,将Binlog的保存时长参数(loose_expire_logs_hours或binlog_expire_logs_seconds)设置为一个较小的值,等文件超过保存时长自动删除后再关闭Binlog。
    2024-06-13 10:06:58
    赞同 1 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
PostgresChina2018_赖思超_PostgreSQL10_hash索引的WAL日志修改版final 立即下载
Kubernetes下日志实时采集、存储与计算实践 立即下载
日志数据采集与分析对接 立即下载