KingbaseES在线WAL日志

KingbaseES数据库WAL日志文件记录数据库的历史操作信息, 包含恢复数据库中的所有事务所需的信息。

1. KingbaseES在线WAL日志：

   WAL日志：

   预写式日志(Write-Ahead Logging(WAL)是保证数据完整性、实现事务日志的一种标准方法。WAL的主要记录对数据文件的修改(存储着表和索引)，对于数据文件的修改必须在修改动作被日志记录之后才被写入。当修改动作的日志记录被写出到持久存储，在数据库发生崩溃时可以使用wal日志来恢复数据库。任何还没有被应用到数据文件的改变可以根据其wal日志记录重做。使用WAL显著减少了磁盘写的次数。只有数据库发出commit or rollback时，才会写出到磁盘以保证事务被提交。而被事务改变的每一个数据文件不必被写出。日志文件按照顺序写入，因此同步日志的代价要远小于写数据文件的代价。在OLTP小事务的服务器尤其明显。使用WAL能够保证数据页的完整性。提供数据库在线备份和恢复的可能。通过归档的WAL文件，可以恢复到WAL文件包含的任意时间。WAL日志的redo可以修复数据库内部的不一致。

   事务日志

   在KingbaseES事务的状态及可见性等信息记录在事务日志文件中。只有通过事务日志信息才能从数据文件中得到有效的数据。因此事务日志对数据一致性是十分重要的。 主要的事务日志文件有sys_xact、sys_csnlog、sys_multixact..

   在线日志

   在KingbaseES中用户的SQL操作以及数据库的运行中的事件会以文本的形式记录在在线日志中.用于使用户可以了解和分析数据库当前状态，并分析可能产生的异常。 在线日志文件默认记录在sys_log中，并可以存放在用户指定的其他地方

2. 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/D04C76985 : logidD0 : wal segment段id4C7698：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 表示归档已完成

3. 关于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 + 2min_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 数据。

​

4. 单机开启归档场景

   kingbase.conf参数ora_input_emptystr_isnull = offarchive_mode = on archive_command='test ! -f /home/kingbase/data/sys_wal/archive_status/%f && cp %p /home/kingbase/archive_log/%f'wal_level = replicamax_wal_size = 800MBmin_wal_size = 80MBwal_keep_segments = 50log_filename = 'kingbase-%Y-%m-%d.log'

   4.1. 影响wal保存最大个数的参数

   max_wal_size = 800MBmin_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 datasys_control version number:            1201Catalog version number:               202208021Database system identifier:           7159464663528337316Database cluster state:               shut downsys_control last modified:             Tue 22 Nov 2022 05:29:23 PM CSTLatest checkpoint location:           A/93000028Latest checkpoint's REDO location:    A/93000028Latest checkpoint's REDO WAL file:    000000020000000A00000093Latest checkpoint's TimeLineID:       2Latest checkpoint's PrevTimeLineID:   2Latest checkpoint's full_page_writes: onLatest checkpoint's NextXID:          0:1932Latest checkpoint's NextOID:          17839Latest checkpoint's NextMultiXactId:  1Latest checkpoint's NextMultiOffset:  0Latest checkpoint's oldestXID:        519Latest checkpoint's oldestXID's DB:   13000Latest checkpoint's oldestActiveXID:  0Latest checkpoint's oldestMultiXid:   1Latest checkpoint's oldestMulti's DB: 13000Latest checkpoint's oldestCommitTsXid:0Latest checkpoint's newestCommitTsXid:0Time of latest checkpoint:            Tue 22 Nov 2022 05:29:23 PM CSTFake LSN counter for unlogged rels:   0/3E8Minimum recovery ending location:     0/0Min recovery ending loc's timeline:   0Backup start location:                0/0Backup end location:                  0/0End-of-backup record required:        nowal_level setting:                    replicawal_log_hints setting:                offmax_connections setting:              100max_worker_processes setting:         8max_wal_senders setting:              10max_prepared_xacts setting:           0max_locks_per_xact setting:           64track_commit_timestamp setting:       offMaximum data alignment:               8Database block size:                  8192Blocks per segment of large relation: 131072WAL block size:                       8192Bytes per WAL segment:                16777216Maximum length of identifiers:        64Maximum columns in an index:          32Maximum size of a TOAST chunk:        1988Size of a large-object chunk:         2048Date/time type storage:               64-bit integersFloat4 argument passing:              by valueFloat8 argument passing:              by valueData page checksum version:           0Mock authentication nonce:            f66a52790db7d81bc9e88e1fe8e85cb0703b937f4be6ed5d676304bbe6147d32database mode:                        0auth method mode:                     02 通过sys_archivecleanup手动清理归档日志。[kingbase@ora19c ~]$ sys_archivecleanup archive_log/ 000000020000000A00000093 -n |wc -l310[kingbase@ora19c ~]$ sys_archivecleanup archive_log/ 000000020000000A00000093[kingbase@ora19c ~]$ ls -l archive_log/ |wc -l1或者通过定时任务脚本清理vi wal_clean.sh#!/bin/bashDATA_DIR=/home/kingbase/dataARCHIVE_DIR=/home/kingbase/archive_logCMD_DIR=/home/kingbase/KingbaseES/V8/Server/binCRT_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

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！