背景
wal日志一直增长很快，查看归档目录也在执行归档，归档无异常，是归档执行太慢的原因吗？还是wal 日志生成的太快了的原因呢？现场环境wal日志的磁盘空间比较小。
分析
首先我们分析可否加速归档速度呢，因为如果能加快归档速度就可以缓解wal日志所在磁盘空间紧张的问题，答案是不可以。archive_command指定外部shell命令来进行归档，判定归档是否正常的方法，ps -ef 查看archiver 归档进程，查看archive_status目录下是否存在.ready的待归档wal文件，如果没有，只查看到.done结尾的文件，代表归档正常。我们没有办法通过增加归档进程或其他方式加快归档的速度。
那么，接下来，我们只能通过减少wal日志单位时间内的生成量或扩充磁盘空间来解决wal日志增长过快导致的磁盘空间紧张的问题。
wal日志保留数量和以下参数有关：
1、wal_keep_segments
2、max_wal_size
3、checkpoint的频度
4、复制槽
max_wal_size这个参数的意义是，当wal日志增长到这个参数的设定值就会触发检查点，也就意味着wal日志只能增长到这个参数设定值。但是，这个参数是个软限制，有些场景可能会超过这个参数的设定值，例如archive_command命令失败，或wal_keep_segments设置过大，或业务系统非常繁忙，单位时间内激增wal日志。当发生检查点时，对应脏块已经写入到磁盘，意味着检查点之前的wal日志不再需要，但并不意味着这些wal日志马上被清理，这需要一定的清理时间，这在数据库内部有判断机制。
wal_keep_segments 可以保留一定的wal日志，保证流复制过程中,如果standby节点失败后的,重新建立时,保证有一定的日志恢复standby节点。
wal日志和检查点：
检查点的作用是将数据库缓冲区中的脏页持久化到磁盘，也就是刷脏页。检查点函数会检测两次 checkpoint 的间隔（默认300毫秒）、或客户端请求 checkpoint 命令操作时执行检查点，
当发生检查点时，大体流程将内存中的 page 脏数据进行持久化、同时将当前执行 checkPoint 点对应 xlog 记录 lsn 保存到控制文件中。这里实现了下面几个重要功能：
1、脏页刷入。
2、删除或回收旧WAL：创建检查点后此位置之前的WAL不再需要，可以删除。
3、设置实例恢复起点。
4、更新控制文件中检查点信息，记录本次 CheckPoint 信息，以便实例崩溃恢复时做判断。
总结
以上分析的第二步，检查点的生成确实对删除wal日志有帮助，可实际并非如此，每次检查点后都会进行全页写，检查点后，第一次修改的数据库进行全页写。而全页写占用的wal日志量是非全页写的3倍左右。所以checkpoint_timeout参数需要根据实际业务场景酌情设置，不能设置太频繁，一般建议设置20-60min。在保证复制槽正常使用状态下，我们可以降低wal_keep_segments，max_wal_size参数设置以降低wal日志的占用的磁盘空间。Kingbase数据库没有办法对wal日志目录做大小硬限制，所以建议结合业务系统实际情况设置以上参数，保证wal日志所在磁盘空间充足。最后，无论wal日志还是归档所在目录的磁盘，需保证IO性能良好。
标签：wal,磁盘空间,参数,检查点,归档,日志,KingbaseES From： https://www.cnblogs.com/kingbase/p/17921548.html