KingbaseES 归档日志清理

WAL是Write Ahead Log的简写，和Oracle的redo日志类似，在R3版本存放在data/sys_log中，R6版本以后在data/sys_wal目录，在数据库访问过程中，任何对数据块的修改都会记录到wal日志，并写入到wal文件保存到磁盘，wal日志可用于数据库的实例恢复和数据恢复。

如果开启了归档，在目录archive_status下会有一些文件，以ready结尾的，表示可以归档但还没有归档，done结尾的表示已经归档。开启了归档后，只有归档成功的sys_wal文件才会被清除。在每次归档命令被执行后，会触发清除标签的动作，在执行检查点时，也会触发清除归档标签文件的动作。

首先明确如下几个相关参数的含义：

• wal_segment_size：单个 WAL 文件的大小，默认为16MB，一般可不做更改。
• wal_keep_segments：指定在后备服务器需要为流复制获取日志段文件的情况下，sys_wal目录下所能保留的日志文件段的最小数目。每个段通常是 16 兆字节。如果一个连接到发送服务器的后备服务器落后了超过wal_keep_segments个段，发送服务器可以移除一个后备机仍然需要的 WAL 段，在这种情况下复制连接将被中断。最终结果是下行连接也将最终失败（不过，如果在使用 WAL 归档，后备服务器可以通过从归档获取段来恢复）。
• min_wal_size：只要 WAL 磁盘用量保持在这个设置之下，在检查点时旧的 WAL 文件总是 被回收以便未来使用，而不是直接被删除。这可以被用来确保有足够的 WAL 空间被保留来应付 WAL 使用的高峰，例如运行大型的批处理任务。 默认是 80 MB。这个参数只能在kingbase.conf 或者服务器命令行中设置。
• max_wal_size：在自动 WAL 检查点之间允许 WAL 增长到的最大尺寸。这是一个软限制， 在特殊的情况下 WAL 尺寸可能会超过max_wal_size， 例如在重度负荷下，archive_command失败或者高的 wal_keep_segments设置。默认为 1 GB。增加这个参数 可能导致崩溃恢复所需的时间。这个参数只能在kingbase.conf 或者服务器命令行中设置。
• archive_timeout：如果 DB 实例写入量很少，到达 archive_timeout 会触发 WAL 文件的强制切换。因此如果 archive_timeout 如果太短就会产生很多新的 WAL，从而产生大量归档。

WAL空间使用情况如下：

1. 如果日志量大于max_wal_size，则WAL日志空间尽量保持在max_wal_size。因为会触发检查点，不需要的段文件将被移除直到系统回到这个限制以下。
2. 如果日志量小于max_wal_size，则WAL日志空间至少保持min_wal_size。
3. 通常情况下，WAL日志空间大小在min_wal_size和max_wal_size之间动态评估。该估计基于在以前的检查点周期中使用的WAL文件数的动态平均值。如果实际使用量超过估计值，动态平均数会立即增加。

一、WAL日志膨胀无法清理案例

通常情况下wal日志可以数据库自动清理，如果配置了archive_mode=on，但是没有配置archive_command，那么wal文件会一直堆积（wal写完后，会写.ready，但是由于没有配置archive_command，也就是说不会触发归档命令，所以一直都不会写.done），所以wal会一直不清理。如果你开启了归档，但是归档命令是失效的，那么wal目录会一直增长，不会自动删除WAL，会使得此目录被撑爆。

如下案例归档失败，导致wal日志不断增长的案例：

1）查看sys_log日志，发现归档失败：

2）查看数据库后台进程（archiver归档失败）

3）查看wal日志信息

4）手工执行归档命令（执行失败）

5）查看归档配置及日志目录信息

=如下所示，归档日志目录名（archiv）和配置文件中指定的目录名（archive）不匹配=

6）查看归档信息

二、手工清理wal日志

1、WAL日志保留

对于wal日志可以通过操作系统rm命令直接删除，也可以使用数据库系统命令 sys_archivecleanup，建议使用 sys_archivecleanup命令。

在清除wal日志或归档日志前，首先需要判断需要保留的wal日志，如果误删除了系统正在访问的wal日志，将导致数据库系统运行故障或数据丢失。

WAL日志保留原则：

1）按照业务应用对基于时间点恢复(PITR)的要求，保留wal日志或归档日志。

2）查看控制文件中"Latest checkpoint's REDO WAL file"，记录检查点的wal日志文件，在此之前wal日志文件可以清理。

3）对于业务应用有要求保留的按照第一条原则，如果应用没有要求，按照第二条原则。

2、清理wal日志

1）查看当前control文件信息

2）查看wal日志信息并清理

#清理前：
[kingbase@node1 sys_wal]$ ls -lh
total 80M
-rw------- 1 kingbase kingbase 16M May 11 13:26 000000010000000000000006
-rw------- 1 kingbase kingbase 16M May 11 13:26 000000010000000000000007
-rw------- 1 kingbase kingbase 16M May 11 13:26 000000010000000000000008
-rw------- 1 kingbase kingbase 16M May 11 13:00 000000010000000000000009
-rw------- 1 kingbase kingbase 16M May 11 13:02 00000001000000000000000A
drwx------ 2 kingbase kingbase  78 May 11 13:49 archive_status

日志清理：

=如下所示，在“000000010000000000000008”之前的日志均可清理。=

清理后：
[kingbase@node1 sys_wal]$ ls -lh
total 32M
-rw------- 1 kingbase kingbase 16M May 11 13:00 000000010000000000000008
-rw------- 1 kingbase kingbase 16M May 11 13:00 000000010000000000000009
-rw------- 1 kingbase kingbase 16M May 11 13:02 00000001000000000000000A
drwx------ 2 kingbase kingbase  78 May 11 13:49 archive_status

三、总结

本文是针对于单实例环境的wal日志的清理，对于单实例环境，在执行手工清理时所要考虑的因素比较简单。但对于流复制集群环境，在执行手工的日志清理时，需要考虑的因素比较多，这个在另外的文档中再介绍。