OpenGauss数据库日志管理

Posted 2023-03-18 呼长喜

本文介绍openGauss数据库日志相关内容和管理方法，了解openGauss数据库中日志管理的内容，并对数据库进行日常管理维护、问题定位和数据库恢复的操作。

环境说明
组网说明
本实验环境为openGauss数据库管理系统，安装在华为云openEuler弹性服务器ECS上。

设备介绍
为了满足数据库原理与实践课程实验需要，建议每套实验环境软件版本采用以下配置：

设备名称 设备型号 软件版本
数据库 openGauss openGauss 1.1.0
操作系统 openEuler openEuler 20.3LTS
概览

 

 

1.日志管理
1.1实验介绍

1.1.1 关于本实验
在实际的数据库管理工作中，小数据量的日志可以按照实验手册，使用cat查看。但需要注意的是，生产环境的日志量可能比较多，日志文件容量经常在GB级别左右，为了提升读取日志的有效性，一般建议使用more、tail、grep等命令查看日志，所以学会这些命令的基本使用方法也是必须的。另外，在生产环境节点较多（成千上万个生产节点）、日志类型较复杂的情况下，人工已无法满足实际生产需求，针对这种情况，一般使用脚本自动化分析或使用第三方软件对日志进行实时监控、分析、告警。
本实验主要描述openGauss数据库中日志管理的内容，并对数据库进行日常管理维护、问题定位和数据库恢复的操作。

1.1.2 实验目的

掌握openGauss数据库中日志管理的内容；
掌握对数据库进行日常管理维护、问题定位。
1.1.3 系统日志
openGauss运行时数据库节点以及openGauss安装部署时产生的日志统称为系统日志。如果openGauss在运行时发生故障，可以通过这些系统日志及时定位故障发生的原因，根据日志内容制定恢复openGauss的方法。
说明：

日志路径在安装openGauss时已由XML文件中gaussdbLogPath参数指定，如果未指定该参数值，则默认路径在/var/log/gaussdb。

数据文件路径在安装openGauss时已由XML文件中dataNode参数指定，如果未指定该参数值，则默认路径在/gaussdb/data/data_dn。

1.1.3.1 运行时日志

步骤 1 切换到omm用户，以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 数据库节点的运行日志放在“$gaussdbLogPath/用户名/pg_log /用户名/pg_log”中，当前场景下用户名为”omm”，切换到pg_log文件夹，并显示文件夹中的内容。

cd /var/log/gaussdb/omm/pg_log ##实际路径以$gaussdbLogPath为准
ls

文件内容显示如下:

dn_6001

数据库节点文件夹为”dn_6001”,以自己实际数据库节点名先为准。

步骤 3 切换到“pg_log”文件夹下的数据库节点文件夹中，查看日志文件。

cd dn_6001
ls

日志文件列表如下：

postgresql-2020-07-21_170715.log postgresql-2020-07-23_145207.log
postgresql-2020-07-21_174440.log postgresql-2020-07-23_160709.log
postgresql-2020-07-22_102526.log postgresql-2020-07-23_162357.log
postgresql-2020-07-23_140520.log postgresql-2020-07-24_103226.log
postgresql-2020-07-23_142946.log postgresql-2020-07-25_000000.log

步骤 4 由于在运行过程中日志的大小可能会超过16 MB，所以在简单查询的过程中，可以先查看日志的大小（其中l是L的小写）。

ll -h

列表显示如下：

total 56M
-rw------- 1 omm dbgrp 56K Jul 21 17:38 postgresql-2020-07-21_170715.log
-rw------- 1 omm dbgrp 3.5M Jul 21 20:51 postgresql-2020-07-21_174440.log
-rw------- 1 omm dbgrp 12M Jul 22 21:10 postgresql-2020-07-22_102526.log
-rw------- 1 omm dbgrp 46K Jul 23 14:06 postgresql-2020-07-23_140520.log
-rw------- 1 omm dbgrp 83K Jul 23 14:32 postgresql-2020-07-23_142946.log
-rw------- 1 omm dbgrp 1.1M Jul 23 15:45 postgresql-2020-07-23_145207.log
-rw------- 1 omm dbgrp 373K Jul 23 16:23 postgresql-2020-07-23_160709.log
-rw------- 1 omm dbgrp 5.3M Jul 23 21:03 postgresql-2020-07-23_162357.log
-rw------- 1 omm dbgrp 15M Jul 24 23:59 postgresql-2020-07-24_103226.log
-rw------- 1 omm dbgrp 19M Jul 25 16:52 postgresql-2020-07-25_000000.log

步骤 5 可以查看内容较少的日志。

cat postgresql-2020-07-23_142946.log

日志内容为：

2020-07-23 14:29:46.457 5f192e5a.1 [unknown] 281466519832976 [unknown] 0 dn_6001 00000 0 [BACKEND] LOG: start create thread!
2020-07-23 14:29:46.457 5f192e5a.1 [unknown] 281466519832976 [unknown] 0 dn_6001 00000 0 [BACKEND] LOG: create thread end!
2020-07-23 14:29:46.458 5f192e5a.10000 [unknown] 281466446432848 dn_6001 0 dn_6001 00000 0 [BACKEND] LOG: reaper backend started.
2020-07-23 14:29:46.458 5f192e5a.10000 [unknown] 281466463275600 dn_6001 0 dn_6001 00000 0 [BACKEND] LOG: [Alarm Module]alarm checker started.
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <JitExec> Using native LLVM version 7.0.0
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <Configuration> Configuring total memory for relative memory values to: 2048 MB
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <System> Startup: Loading configuration from /gaussdb/data/db1/mot.conf
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <Configuration> Loaded max_mot_global_memory: 80% from total = 1638 MB
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <Configuration> Loaded max_mot_local_memory: 15% from total = 307 MB
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <Configuration> Loading max_connections from envelope into MOTEngine: 5000
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <Configuration> Configuring asynchronous redo-log handler due to synchronous_commit=off
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [WARNING] <Configuration> Adjusting MOT memory limits: global = 102 MB, local = 26 MB, session large store = 0 MB, total = 128 MB
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <Memory> Global Memory Limit is configured to: 0 MB --> 102 MB
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <Memory> Local Memory Limit is configured to: 0 MB --> 26 MB
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <Memory> Session Memory Limit is configured to: 0 KB --> 0 KB (maximum 5000 sessions)
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO] <Memory> Configured automatic chunk allocation policy to \'LOCAL\' on single node machine

1.1.3.2 安装卸载时日志
步骤 1 切换到omm用户，以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 openGauss安装卸载时产生的日志放在“$gaussdbLogPath/用户名/om”目录下，当前场景下用户名为”omm”，切换到om文件夹，并显示文件夹中的内容。

cd /var/log/gaussdb/omm/om ##实际路径以$gaussdbLogPath为准
ll -h

文件夹中内容显示如下：

total 160K
-rw------- 1 omm dbgrp 9.1K Jul 21 17:07 gs_install-2020-07-21_170455.log
-rw------- 1 omm dbgrp 68K Jul 24 10:32 gs_local-2020-07-21_160847.log
-rw------- 1 omm dbgrp 35K Jul 24 10:32 gs_om-2020-07-21_174438.log
-rw------- 1 omm dbgrp 32K Jul 21 16:36 gs_preinstall-2020-07-21_160843.log

步骤 3 查看“gs_install-2020-07-21_170455.log”日志，了解openGauss安装情况。

cat gs_install-2020-07-21_170455.log

日志内容如下：

[2020-07-21 17:04:55.967536][27138][gs_install][DEBUG]:The /opt/huawei/wisequery/omm_mppdb/install_step/install_step.dat does not exits.
[2020-07-21 17:04:55.967641][27138][gs_install][DEBUG]:gs_install execution takes 7 steps in total
[2020-07-21 17:04:55.967709][27138][gs_install][LOG][Step1]:Parsing the configuration file.
[2020-07-21 17:04:55.970059][27138][gs_install][DEBUG]:Instance information of cluster:
ClusterName=dbCluster,AppPath=/opt/gaussdb/app,LogPath=/var/log/gaussdb,ClusterType=single-inst
HostName=db1,backIps=[\'192.168.0.58\']
InstanceId=10001,MirrorId=-3,Host=db1,Port=0,DataDir=cm_agent,XlogDir=,SsdDir=,InstanceType=-1,Role=5,ListenIps=[\'192.168.0.58\'],HaIps=[]
InstanceId=6001,MirrorId=1,Host=db1,Port=26000,DataDir=/gaussdb/data/db1,XlogDir=,SsdDir=,InstanceType=0,Role=4,ListenIps=[\'192.168.0.58\'],HaIps=[\'192.168.0.58\'],azName=AZ1.
[2020-07-21 17:04:56.022578][27138][gs_install][DEBUG][Step1]:Successfully parsed the configuration file.
[2020-07-21 17:04:56.067808][27138][gs_install][LOG][Step2]:Check preinstall on every node.
……
alarm=/opt/huawei/snas/bin/snas_cm_cmd --time_out=300
[2020-07-21 17:07:16.476528][27138][gs_install][LOG]:Successfully started cluster.
[2020-07-21 17:07:16.476605][27138][gs_install][DEBUG][Step7]:Successfully started the cluster.
[2020-07-21 17:07:16.487388][27138][gs_install][LOG]:Successfully installed application.
[2020-07-21 17:07:16.487469][27138][gs_install][LOG]:end deploy..

1.1.4 操作日志
操作日志是指数据库管理员使用工具操作数据库时以及工具被openGauss调用时产生的日志。如果openGauss发生故障，可以通过这些日志信息跟踪用户对数据库进行了哪些操作，重现故障场景。
1.1.4.1 操作步骤
步骤 1 切换到omm用户，以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 默认在“G A U S S L O G / b i n ” 目 录 下 ， 其 中 GAUSSLOG/bin”目录下，其中GAUSSLOG/bin”目录下，其中GAUSSLOG默认为“/var/log/gaussdb/用户名”， 当前场景下用户名为”omm”。

cd /var/log/gaussdb/omm/bin
ls

显示如下：

gs_ctl gs_guc gs_initdb gs_obs

步骤 3 以gs_guc操作为例，进入gs_guc文件夹，并查看文件的属性。

cd gs_guc
ll -h

文件列表显示如下：

total 20K
-rw------- 1 omm dbgrp 17K Jul 23 17:20 gs_guc-2020-07-21_170713-current.log

步骤 4 查看操作日志文件

cat gs_guc-2020-07-21_170713-current.log

日志显示如下：

[2020-07-21 17:07:13]
expected instance path: [/gaussdb/data/db1/postgresql.conf]
gs_guc set: ssl=on: [/gaussdb/data/db1/postgresql.conf]
gs_guc set: ssl_cert_file=\'server.crt\': [/gaussdb/data/db1/postgresql.conf]
gs_guc set: ssl_key_file=\'server.key\': [/gaussdb/data/db1/postgresql.conf]
gs_guc set: ssl_ca_file=\'cacert.pem\': [/gaussdb/data/db1/postgresql.conf]

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!
……
[2020-07-23 17:20:20]
Begin to perform gs_guc for all datanodes.
[2020-07-23 17:20:20]
[2020-07-23 17:20:20]
expected instance path: [/gaussdb/data/db1/pg_hba.conf]
Notice: the above configuration uses cluster internal communication, your configuration may affect the cluster internal communication.
gs_guc sethba: host all dim 192.168.0.96/24 sha256: [/gaussdb/data/db1/pg_hba.conf]

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!

1.1.5 审计日志
审计功能开启时会不断产生大量的审计日志，占用磁盘空间。用户可以根据磁盘空间的大小设置审计日志维护策略。
1.1.5.1 前提条件

用户必须拥有审计权限。
omm用户连接数据库。
步骤 1 以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 启动openGauss数据库服务

gs_om -t start

步骤 3 使用如下命令连接数据库。

gsql -d postgres -p 26000 -r

postgres为需要连接的数据库名称，26000为数据库主节点的端口号。

1.1.5.2 背景信息
与审计日志相关的配置参数及其含义请参见下表。

配置项 含义 默认值
audit_directory 审计文件的存储目录。 /var/log/gaussdb/用户名/pg_audit
audit_resource_policy 审计日志的保存策略。 on（表示使用空间配置策略）
audit_space_limit 审计文件占用的磁盘空间总量。 1 GB
audit_file_remain_time 审计日志文件的最小保存时间。 90天
audit_file_remain_threshold 审计目录下审计文件的最大数量。 1048576
说明：如果使用gs_om工具部署openGauss，则审计日志路径为 “/var/log/gaussdb/用户名/pg_audit”。

审计日志删除命令为数据库提供的sql函数pg_delete_audit，其原型为：
pg_delete_audit(timestamp startime,timestamp endtime)
其中参数startime和endtime分别表示审计记录的开始时间和结束时间。
目前常用的记录审计内容的方式有两种：记录到数据库的表中、记录到OS文件中。这两种方式的优缺点比较如下表所示。

方式 优点 缺点
记录到表中 不需要用户维护审计日志。 由于表是数据库的对象，如果一个数据库用户具有一定的权限，就能够访问到审计表。如果该用户非法操作审计表，审计记录的准确性难以得到保证。
记录到OS文件中 比较安全，即使一个帐户可以访问数据库，但不一定有访问OS这个文件的权限。 需要用户维护审计日志。
从数据库安全角度出发，openGauss采用记录到OS文件的方式来保存审计结果，保证了审计结果的可靠性。

1.1.5.3 选择日志维护方式进行维护。

1.1.5.3.1 设置自动删除审计日志
审计文件占用的磁盘空间或者审计文件的个数超过指定的最大值时，系统将删除最早的审计文件，并记录审计文件删除信息到审计日志中。
注：审计文件占用的磁盘空间大小默认值为1024MB，用户可以根据磁盘空间大小重新设置参数。

步骤 1 配置审计文件占用磁盘空间的大小（audit_space_limit），查看已配置的参数。

postgres=# SHOW audit_space_limit;

audit_space_limit
-------------------
1GB
(1 row)

如果显示结果不为1 GB（1024 MB），执行“\\q”命令退出数据库。

postgres=# \\q

步骤 2 建议执行如下命令设置成默认值1024 MB。

gs_guc reload -N all -I all -c "audit_space_limit=1024MB"

显示结果为：

"audit_space_limit=1024MB";
Begin to perform gs_guc for all datanodes.

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!

步骤 3 配置审计文件个数的最大值（audit_file_remain_threshold）。连接数据库，查看已配置的参数。
连接数据库：

gsql -d postgres -p 26000 -r

查看审计文件个数的参数：

postgres=# SHOW audit_file_remain_threshold;
audit_file_remain_threshold
-----------------------------
1048576
(1 row)

如果显示结果不为1048576，执行“\\q”命令退出数据库。

postgres=# \\q

步骤 4 建议执行如下命令设置成默认值1048576。

gs_guc reload -N all -I all -c "audit_file_remain_threshold=1048576"

显示为：

Begin to perform gs_guc for all datanodes.

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!

1.1.5.3.2 手动备份审计文件
当审计文件占用的磁盘空间或者审计文件的个数超过配置文件指定的值时，系统将会自动删除较早的审计文件，因此建议用户周期性地对比较重要的审计日志进行保存。

步骤 1 连接数据库，使用show命令获得审计文件所在目录（audit_directory）。
连接数据库：

gsql -d postgres -p 26000 -r

获得审计文件所在目录：

postgres=# SHOW audit_directory;

audit_directory
---------------------------------------
/var/log/gaussdb/omm/pg_audit/dn_6001
(1 row)

退出数据库

postgres=# \\q

步骤 2 将审计目录整个拷贝出来进行保存。

cp -r /var/log/gaussdb/omm/pg_audit/dn_6001 /var/log/gaussdb/omm/pg_audit/dn_6001_bak

查看备份是否成功：

cd /var/log/gaussdb/omm/pg_audit/
ll -h

total 8.0K
drwx------ 2 omm dbgrp 4.0K Sep 14 16:52 dn_6001
drwx------ 2 omm dbgrp 4.0K Sep 15 11:43 dn_6001_bak

1.1.6 WAL日志
预写式日志WAL（Write Ahead Log，也称为Xlog）是指如果要修改数据文件，必须是在这些修改操作已经记录到日志文件之后才能进行修改，即在描述这些变化的日志记录刷新到永久存储器之后。在系统崩溃时，可以使用WAL日志对openGauss进行恢复操作。
1.1.6.1 操作步骤
步骤 1 以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 以一个数据库节点为例，默认在“/gaussdb/data/data_dn/pg_xlog”目录下。其中“/gaussdb/data/data_dn”代表openGauss节点的数据目录，当前情况下为“/gaussdb/data/db1/”。

cd /gaussdb/data/
ls
db1

切换到db1文件夹。

cd db1
ls

文件夹中内容如下：

base pg_ctl.lock pg_notify postgresql.conf
cacert.pem pg_errorinfo pg_replslot postgresql.conf.bak
gaussdb.state pg_hba.conf pg_serial postgresql.conf.lock
global pg_hba.conf.bak pg_snapshots postmaster.opts
gswlm_userinfo.cfg pg_hba.conf.lock pg_stat_tmp postmaster.pid
mot.conf pg_ident.conf pg_tblspc server.crt
pg_clog pg_llog pg_twophase server.key
pg_copydir pg_location PG_VERSION server.key.cipher
pg_csnlog pg_multixact pg_xlog server.key.rand

步骤 3 切换到pg_xlog文件夹，查看WAL日志文件。

cd pg_xlog
ls

日志文件列表如下：

00001000000010000004E 000000010000000100000066 00000001000000010000007E
00000001000000010000004F 000000010000000100000067 00000001000000010000007F
000000010000000100000050 000000010000000100000068
……
000000010000000100000063 00000001000000010000007B archive_status
000000010000000100000064 00000001000000010000007C
000000010000000100000065 00000001000000010000007D

1.1.7 性能日志
性能日志主要关注外部资源的访问性能问题。性能日志指的是数据库系统在运行时检测物理资源的运行状态的日志，在对外部资源进行访问时的性能检测，包括磁盘、OBS等外部资源的访问检测信息。在出现性能问题时，可以借助性能日志及时的定位问题发生的原因，能极大地提升问题解决效率。
1.1.7.1 操作步骤
步骤 1 以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 数据库节点的性能日志目录在“$GAUSSLOG/gs_profile”中各自对应的目录下, 其中$GAUSSLOG默认为“/var/log/gaussdb/用户名”， 当前场景下用户名为”omm”。切换到文件夹，查看文件列表的信息。

cd /var/log/gaussdb/omm/gs_profile/
ls
dn_6001

切换到dn_6001文件夹。

cd dn_6001
ls –h

性能日志内容显示如下:

total 4.0K
-rw------- 1 omm dbgrp 0 Jul 21 17:07 postgresql-2020-07-21_170715.prf
-rw------- 1 omm dbgrp 0 Jul 21 17:44 postgresql-2020-07-21_174440.prf
-rw------- 1 omm dbgrp 0 Jul 22 10:25 postgresql-2020-07-22_102526.prf
-rw------- 1 omm dbgrp 0 Jul 23 14:05 postgresql-2020-07-23_140520.prf
-rw------- 1 omm dbgrp 0 Jul 23 14:29 postgresql-2020-07-23_142946.prf
-rw------- 1 omm dbgrp 0 Jul 23 14:52 postgresql-2020-07-23_145207.prf
-rw------- 1 omm dbgrp 0 Jul 23 16:07 postgresql-2020-07-23_160709.prf
-rw------- 1 omm dbgrp 0 Jul 23 16:23 postgresql-2020-07-23_162357.prf
-rw------- 1 omm dbgrp 48 Jul 25 00:00 postgresql-2020-07-24_103226.prf
-rw------- 1 omm dbgrp 0 Jul 25 00:00 postgresql-2020-07-25_000000.prf

说明：

性能日志主要监控三种资源访问：磁盘、OBS、Hadoop。openGauss不支持OBS、Hadoop，所以只有磁盘访问的监控信息。
磁盘监控的访问信息主要在磁盘文件IO读写的时候进行统计。比如拷贝文件时的读文件IO，正常SQL执行时访问OS表文件的pread系统调用。
性能日志进行收集的配置：logging_collector 是否进行日志收集；plog_merge_age 多久进行一次性能日志汇聚，单位毫秒。logging_collector 参数为on，且plog_merge_age大于0，且是主机正常运行中，恢复过程不进行性能收集。
通过工具gs_log导出文件进行查看。
到此，openGauss数据库日志管理指导结束。