KingbaseES数据库日志文件记录数据库的历史操作信息, 包含恢复数据库中的所有事务所需的信息。
-
KingbaseES在线WAL日志：
WAL日志：
预写式日志（Write-Ahead Logging（WAL）是保证数据完整性、实现事务日志的一种标准方法。 WAL的主要记录对数据文件的修改（存储着表和索引）必须在修改动作被日志记录之后才被写入。 当修改动作的日志记录被写出到持久存储。在数据库发生崩溃时可以使用wal日志来恢复数据库。 任何还没有被应用到数据文件的改变可以根据其wal日志记录重做。 使用WAL显著减少了磁盘写的次数。只有日志文件出发checkpoint时才会写出到磁盘以保证事务被提交。 而被事务改变的每一个数据文件不必被写出。 日志文件按照顺序写入，因此同步日志的代价要远小于写数据文件的代价。 在OLTP小事务的服务器尤其明显。 使用WAL能够保证数据页的完整性。 提供数据库在线备份和恢复的可能。 通过归档的WAL文件，可以恢复到WAL文件包含的任意时间。 WAL日志的redo可以修复数据库内部的不一致。事务日志
在KingbaseES事务的状态及可见性等信息记录在事务日志文件中。 只有通过事务日志信息才能从数据文件中得到有效的数据。 因此事务日志对数据一致性是十分重要的。 主要的事务日志文件有sys_xact、sys_csnlog、sys_multixact..在线日志
在KingbaseES中用户的SQL操作以及数据库的运行中的事件会以文本的形式记录在在线日志中. 用于使用户可以了解和分析数据库当前状态，并分析可能产生的异常。 在线日志文件默认记录在sys_log中，并可以存放在用户指定的其他地方 -
wal日志格式
WAL的名称由三部分组成，每个部分代表8个数字。 00000002是TimeLine ID,从1开始。 00000005是逻辑文件ID,从0开始。 000000D0是物理文件ID,从00开始,直到 FF,不停的循环 test=# select pg_current_wal_lsn(),pg_walfile_name(pg_current_wal_lsn()),pg_walfile_name_offset(pg_current_wal_lsn()); pg_current_wal_lsn | pg_walfile_name | pg_walfile_name_offset --------------------+--------------------------+------------------------------------ 5/D04C7698 | 0000000200000005000000D0 | (0000000200000005000000D0,5011096) (1 row) 当前事物号 5/D04C7698 5 : logid D0 : wal segment段id 4C7698：offset 偏移量 test=# select x'D04C7698'::bigint; int8 ------------ 3494672024 (1 row) test=# select ((3494672024-1)/(16*1024*1024*256::bigint)); ?column? ---------- 0 (1 row) test=# select mod(((3494672024-1)/(16*1024*1024)),256); --十进制 mod ----- 208 (1 row) test=# select to_hex(208); --计算wal日志编号 to_hex -------- d0 (1 row) test=# wal日志切换： select sys_switch_wal(); 在sys_wal/archive_status目录 .ready 表示准备归档 .done 表示归档已完成 -
关于wal日志的参数：
#wal_level = replica # replica 它会写入足够的数据以支持WAL归档和复制，包括在后备服务器上运行只读查询。 # minimal 会去掉除从崩溃或者立即关机中进行恢复所需的信息之外的所有记录。 # logical 会增加支持逻辑解码所需的信息。每个层次包括所有更低层次记录的信息。 #wal_sync_method = fsync # 可以通过 sys_test_fsync 测试设置。 #wal_compression = off # full_page_writes =on 或者处于基础备份期间会压缩写入到 WAL 中的完整页面镜像。 # 压缩页面镜像将在 WAL 重放时被解压。 #wal_log_hints = off # 参数必须开启，在流复制主备需要进行切换时，主备时间线出现分歧，方便使用sys_rewind进行时间同步 #wal_init_zero = on # 设置为 on (默认值)，会把新的WAL文件填充0，进行预分配空间 #wal_recycle = on # 通过重命名循环使用已经存在的WAL文件。 #wal_buffers = -1 # wal日志缓存 #wal_writer_delay = 200ms # wal日志写磁盘后，休眠时间。 #wal_writer_flush_after = 1MB # 新产生的wal字节，写出到系统缓存。 max_wal_size = 2GB # WAL 检查点之间允许 WAL 增长到的最大尺寸。这是一个软限制。 # 在特殊的情况下 WAL 尺寸可能会超过 max_wal_size + 2 min_wal_size = 1GB # WAL 磁盘用量保持在这个设置之下，在检查点时旧的 WAL 文件循环使用，而不直接被删除。 #max_wal_senders = 10 # 流复制环境wal 发送进程的最大数量，在流复制环境必须将此参数设置为与主服务器相同或更高的值。 #wal_keep_segments = 0 # 保留的wal 日志文件数目。每个wal 最大为16MB。 #wal_sender_timeout = 60s # 流复制环境wal 发送进程超时时间 #wal_receiver_status_interval = 10s # 流复制环境备机接受主发送wal日志的复制信息的频度 #wal_receiver_timeout = 60s # 流复制环境wal 接收进程超时时间 #wal_retrieve_retry_interval = 5s # 流复制环境从本地 sys_wal 或者 WAL 归档都得不到 WAL 数据时，备用服务器等待多久去重新尝试获取 WAL 数据。 -
单机开启归档场景
kingbase.conf参数 ora_input_emptystr_isnull = off archive_mode = on archive_command='test ! -f /home/kingbase/data/sys_wal/archive_status/%f && cp %p /home/kingbase/archive_log/%f' wal_level = replica max_wal_size = 800MB min_wal_size = 80MB wal_keep_segments = 50 log_filename = 'kingbase-%Y-%m-%d.log'4.1. 影响wal保存最大个数的参数
max_wal_size = 800MB min_wal_size = 80MB -- 上面的跟以下参数任选一个就可以 wal_keep_segments = 50 默认的wal segment大小为16MB。
4.2. 清理已经归档的wal日志
sys_wal/archive_status目录下的文件会自动清理。
设置archive_command参数后，归档目录需要手动清理。
1 通过sys_controldata读取控制文件，找到可以清理的wal日志
[kingbase@ora19c ~]$ sys_controldata -D data
sys_control version number: 1201
Catalog version number: 202208021
Database system identifier: 7159464663528337316
Database cluster state: shut down
sys_control last modified: Tue 22 Nov 2022 05:29:23 PM CST
Latest checkpoint location: A/93000028
Latest checkpoint's REDO location: A/93000028
Latest checkpoint's REDO WAL file: 000000020000000A00000093
Latest checkpoint's TimeLineID: 2
Latest checkpoint's PrevTimeLineID: 2
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0:1932
Latest checkpoint's NextOID: 17839
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 519
Latest checkpoint's oldestXID's DB: 13000
Latest checkpoint's oldestActiveXID: 0
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 13000
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint: Tue 22 Nov 2022 05:29:23 PM CST
Fake LSN counter for unlogged rels: 0/3E8
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline: 0
Backup start location: 0/0
Backup end location: 0/0
End-of-backup record required: no
wal_level setting: replica
wal_log_hints setting: off
max_connections setting: 100
max_worker_processes setting: 8
max_wal_senders setting: 10
max_prepared_xacts setting: 0
max_locks_per_xact setting: 64
track_commit_timestamp setting: off
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1988
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by value
Data page checksum version: 0
Mock authentication nonce: f66a52790db7d81bc9e88e1fe8e85cb0703b937f4be6ed5d676304bbe6147d32
database mode: 0
auth method mode: 0
2 通过sys_archivecleanup手动清理归档日志。
[kingbase@ora19c ~]$ sys_archivecleanup archive_log/ 000000020000000A00000093 -n |wc -l
310
[kingbase@ora19c ~]$ sys_archivecleanup archive_log/ 000000020000000A00000093
[kingbase@ora19c ~]$ ls -l archive_log/ |wc -l
1
或者通过定时任务脚本清理
vi wal_clean.sh
#!/bin/bash
DATA_DIR=/home/kingbase/data
ARCHIVE_DIR=/home/kingbase/archive_log
CMD_DIR=/home/kingbase/KingbaseES/V8/Server/bin
CRT_WAL_FILE=`$CMD_DIR/sys_controldata -D data |grep -i 'redo wal'|awk -F: '{print $2}'`
$CMD_DIR/sys_archivecleanup $ARCHIVE_DIR $CRT_WAL_FILE