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。
写回答
