发文章是为了证明自己真的掌握了一个知识，同时给他人带来帮助，如有问题，欢迎指正，祝大家万事胜意！
目录
前言
openGauss 数据库日志管理
1 实验介绍
2 实验目的
3 系统日志
3.1 运行时日志
3.2 安装卸载时日志
4 操作日志
4.1 操作步骤
5 审计日志
5.1 前提条件
5.2 背景信息
5.3 选择日志维护方式进行维护
5.3.1 设置自动删除审计日志
5.3.2 手动备份审计文件
5.3.3 手动删除审计日志
6 WAL 日志
6.1 操作步骤
7 性能日志
7.1 操作步骤
前言
我的环境：
| 设备名称 | 设备型号 | 软件版本 |
| 虚拟机 | VMware | VMware-workstation-full-17.5.1 |
| 操作系统 | openEuler | openEuler 22.3LTS |
| 数据库 | openGauss | openGauss 5.0.0 |
需要的工具，大家不用现在下，后面用到了再下也可以，如果需要相关文件，可以评论，其实大多数都是可以去官网下的哈，因为我只能通过网盘给大家，文件又有点大，网盘的速度大家都是清楚的哈哈，所以还是推荐大家去官网，如果实在找不到可以找我
openGauss 数据库日志管理
1 实验介绍
在实际的数据库管理工作中，小数据量的日志可以按照实验手册，使用 cat 查看。但需要注意
的是，生产环境的日志量可能比较多，日志文件容量经常在 GB 级别左右，为了提升读取日志
的有效性，一般建议使用 more、tail、grep 等命令查看日志，所以学会这些命令的基本使用方
法也是必须的。另外，在生产环境节点较多（成千上万个生产节点）、日志类型较复杂的情况
下，人工已无法满足实际生产需求，针对这种情况，一般使用脚本自动化分析或使用第三方软
件对日志进行实时监控、分析、告警。
本实验主要描述 openGauss 数据库中日志管理的内容，并对数据库进行日常管理维护、问题定
位和数据库恢复的操作。
2 实验目的
掌握 openGauss 数据库中日志管理的内容；
掌握对数据库进行日常管理维护、问题定位。
3 系统日志
openGauss 运行时数据库节点以及 openGauss 安装部署时产生的日志统称为系统日志。如果
openGauss 在运行时发生故障，可以通过这些系统日志及时定位故障发生的原因，根据日志内
容制定恢复 openGauss 的方法。
说明：
日志路径在安装 openGauss 时已由 XML 文件中 gaussdbLogPath 参数指定，如果未指定
该参数值，则默认路径在/var/log/gaussdb。
数据文件路径在安装 openGauss 时已由 XML 文件中 dataNode 参数指定，如果未指定该
参数值，则默认路径在/gaussdb/data/data_dn。
3.1 运行时日志
步骤 1 切换到 omm 用户，以操作系统用户 omm 登录数据库主节点
[root@node0 ~]# su - omm
Last login: Sun Mar 31 16:51:15 CST 2024 on tty1
Welcome to 5.10.0-153.12.0.92.oe2203sp2.x86_64
System information as of time: 2024年 03月 31日 星期日 17:04:47 CST
System load: 0.00
Processes: 200
Memory used: 38.3%
Swap used: 10.1%
Usage On: 25%
IP address: 192.168.28.131
Users online: 2
To run a command as administrator(user "root"),use "sudo <command>".
步骤 2 数据库节点的运行日志放在“$gaussdbLogPath/用户名/pg_log /用户名/pg_log”中，当前场景下
用户名为”omm”，切换到 pg_log 文件夹，并显示文件夹中的内容。
每个人可能不一样，我就找了一会，大家可以利用WinSCP来找，下面这个是我的
[omm@node0 ~]$ cd /var/log/omm/omm/pg_log ##实际路径以$gaussdbLogPat为准，这是注释
[omm@node0 pg_log]$ ll
文件内容显示如下:
total 4
drwxr-x--- 2 omm dbgrp 4096 Mar 31 16:51 dn_6001数据库节点文件夹为”dn_6001”,以自己实际数据库节点名先为准。
步骤 3 切换到“pg_log”文件夹下的数据库节点文件夹中，查看日志文件。
[omm@node0 pg_log]$ cd dn_6001
[omm@node0 dn_6001]$ ls
日志文件列表如下：
postgresql-2024-03-16_095122.log postgresql-2024-03-28_210211.log
postgresql-2024-03-17_214212.log postgresql-2024-03-28_222633.log
postgresql-2024-03-18_000000.log postgresql-2024-03-28_223555.log
postgresql-2024-03-18_033830.log postgresql-2024-03-29_110930.log
postgresql-2024-03-18_045238.log postgresql-2024-03-31_162857.log
postgresql-2024-03-25_182658.log postgresql-2024-03-31_165132.log
postgresql-2024-03-25_194258.log
步骤 4 由于在运行过程中日志的大小可能会超过 16 MB，所以在简单查询的过程中，可以先查看日 志的大小（其中 l 是 L 的小写）。
[omm@node0 dn_6001]$ ll -h
列表显示如下：
total 2.0M
-rw------- 1 omm dbgrp 73K Mar 16 10:34 postgresql-2024-03-16_095122.log
-rw------- 1 omm dbgrp 358K Mar 17 23:59 postgresql-2024-03-17_214212.log
-rw------- 1 omm dbgrp 401K Mar 18 03:35 postgresql-2024-03-18_000000.log
-rw------- 1 omm dbgrp 158K Mar 18 04:51 postgresql-2024-03-18_033830.log
-rw------- 1 omm dbgrp 147K Mar 18 06:07 postgresql-2024-03-18_045238.log
-rw------- 1 omm dbgrp 136K Mar 25 19:36 postgresql-2024-03-25_182658.log
-rw------- 1 omm dbgrp 178K Mar 25 21:17 postgresql-2024-03-25_194258.log
-rw------- 1 omm dbgrp 179K Mar 28 22:25 postgresql-2024-03-28_210211.log
-rw------- 1 omm dbgrp 38K Mar 28 22:35 postgresql-2024-03-28_222633.log
-rw------- 1 omm dbgrp 42K Mar 28 22:49 postgresql-2024-03-28_223555.log
-rw------- 1 omm dbgrp 105K Mar 29 11:55 postgresql-2024-03-29_110930.log
-rw------- 1 omm dbgrp 27K Mar 31 16:29 postgresql-2024-03-31_162857.log
-rw------- 1 omm dbgrp 71K Mar 31 17:21 postgresql-2024-03-31_165132.log
步骤 5 可以查看内容较少的日志（是查你自己的！！我查的是我的日志文件，你肯定没有这个文件，注意输入自己的）。
[omm@node0 dn_6001]$ cat postgresql-2024-03-31_162857.log
日志内容为（日志，没看看的必要）：
2024-03-31 16:28:57.767 66091ec9.10000 [unknown] 140435825620544 dn_6001 0 dn_6001 00000 0 [BACKEND] LOG: reaper backend started.
2024-03-31 16:28:57.769 66091ec9.10000 [unknown] 140435847767616 dn_6001 0 dn_6001 00000 0 [BACKEND] LOG: [Alarm Module]alarm checker started.
2024-03-31 16:28:57.781 [MOT] <TID:03978/-----> <SID:-----/-----> [INFO] <System> Startup: Loading configuration from /opt/huawei/install/data/dn/mot.conf
2024-03-31 16:28:57.829 [MOT] <TID:03978/-----> <SID:-----/-----> [INFO] <Configuration> Configuring total memory for relative memory values to: 2048 MB
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [INFO] <Configuration> Loading max_connections from envelope into MOTEngine: 6000
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [WARNING] <Configuration> Adjusted maximum number of threads to 4096 due to maximum limit
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [INFO] <Configuration> Configuring asynchronous redo-log handler due to synchronous_commit=off
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [WARNING] <Configuration> Using minimal memory limits in MOT Engine due to system total memory restrictions
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [WARNING] <Configuration> Adjusting MOT memory limits: global = 128 MB, local = 64 MB, session large store = 0 MB, total = 192 MB
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [INFO] <Memory> Global Memory Limit is configured to: 0 MB --> 128 MB
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [INFO] <Memory> Local Memory Limit is configured to: 0 MB --> 64 MB
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [INFO] <Memory> Session Memory Limit is configured to: 0 KB --> 0 KB (maximum 6000 sessions)
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [INFO] <Memory> Configured automatic chunk allocation policy to 'LOCAL' on single node machine
2024-03-31 16:28:57.859 [MOT] <TID:03978/-----> <SID:-----/-----> [WARNING] <FDW> Allowing MOT to work in minimal memory mode
……（不用看，很多，只是部分截取）
3.2 安装卸载时日志
步骤 1 切换到 omm 用户，以操作系统用户 omm 登录数据库主节点。
[root@node0 ~]# su - omm
Last login: Sun Mar 31 17:04:47 CST 2024 on pts/0
Welcome to 5.10.0-153.12.0.92.oe2203sp2.x86_64
System information as of time: 2024年 03月 31日 星期日 17:35:07 CST
System load: 0.07
Processes: 202
Memory used: 38.6%
Swap used: 11.4%
Usage On: 25%
IP address: 192.168.28.131
Users online: 2
To run a command as administrator(user "root"),use "sudo <command>".
步骤 2 openGauss 安装卸载时产生的日志放在“$gaussdbLogPath/用户名/om”目录下，当前场景下用 户名为”omm”，切换到 om 文件夹，并显示文件夹中的内容。
[omm@node0 ~]$ cd /var/log/omm/omm/om ##实际路径以$gaussdbLogPath 为准
[omm@node0 om]$ ll -h
文件夹中内容显示如下：
total 536K
-rw------- 1 omm dbgrp 2.7K Mar 25 19:46 gs_check-2024-03-18_033618.log
-rw------- 1 omm dbgrp 49K Mar 25 20:16 gs_checkperf-2024-03-18_034308.log
-rw------- 1 omm dbgrp 4.2K Mar 28 21:36 gs_collector-2024-03-25_190140.log
-rw------- 1 omm dbgrp 49K Mar 17 21:43 gs_install-2024-03-15_174154.log
-rw------- 1 omm dbgrp 315K Mar 31 16:51 gs_local-2024-03-15_165648.log
-rw------- 1 omm dbgrp 56K Mar 31 16:51 gs_om-2024-03-15_174942.log
-rw------- 1 omm dbgrp 26K Mar 16 13:40 gs_preinstall-2024-03-15_165624.log
步骤 3 查看“gs_install-2024-03-15_174154.log”（我们不一样哈）日志，了解 openGauss 安装情况。
omm@node0 om]$ cat gs_install-2024-03-15_174154.log
日志内容如下：
[2024-03-15 17:41:54.051585][7624][gs_install][DEBUG]:The /opt/huawei/tmp/install_step/install_step.dat does not exits.
[2024-03-15 17:41:54.051757][7624][gs_install][DEBUG]:gs_install execution takes 7 steps in total
[2024-03-15 17:41:54.051918][7624][gs_install(initGlobals:109)][gs_install][LOG][Step1]:Parsing the configuration file.
[2024-03-15 17:41:54.287209][7624][gs_install(initGlobals:125)][gs_install][DEBUG][Step1]:Successfully parsed the configuration file.
[2024-03-15 17:41:54.497368][7624][gs_install][DEBUG]:{'node0': 6001}
[2024-03-15 17:41:54.497677][7624][InstallImpl.py(checkGaussenvFlag:189)][gs_install][LOG][Step2]:Check preinstall on every node.
[2024-03-15 17:41:54.756723][7624][InstallImpl.py(checkGaussenvFlag:192)][gs_install][LOG][Step2]:Successfully checked preinstall on every node.
……
[2024-03-17 21:43:48.256824][4573][InstallImplOLAP.py(checkNodeInstall:169)][gs_install][LOG][Step5]:Checking the installation environment on all nodes.
[2024-03-17 21:43:48.257149][4573][gs_install][DEBUG]:Command for checking installation: source /home/omm/.bashrc;python3 '/opt/huawei/install/om/script/local/CheckInstall.py' -U omm:dbgrp -R /opt/huawei/install/app -l /var/log/omm/omm/om/gs_local.log -X /opt/software/openGauss/cluster_config.xml.
[2024-03-17 21:43:48.611973][4573][gs_install][ERROR]:Checking old installation.
[GAUSS-51806] : The cluster has been installed.
4 操作日志
操作日志是指数据库管理员使用工具操作数据库时以及工具被 openGauss 调用时产生的日志。
如果 openGauss 发生故障，可以通过这些日志信息跟踪用户对数据库进行了哪些操作，重现故
障场景。
4.1 操作步骤
步骤 1 切换到 omm 用户，以操作系统用户 omm 登录数据库主节点
[omm@node0 om]$ su - omm
Password:
[omm@node0 om]$ logout
[root@node0 ~]# su - omm
Last login: Sun Mar 31 17:35:07 CST 2024 on pts/0
Welcome to 5.10.0-153.12.0.92.oe2203sp2.x86_64
System information as of time: 2024年 03月 31日 星期日 17:47:51 CST
System load: 0.20
Processes: 202
Memory used: 38.4%
Swap used: 20.0%
Usage On: 25%
IP address: 192.168.28.131
Users online: 2
To run a command as administrator(user "root"),use "sudo <command>".
步骤 2 默认在“$GAUSSLOG/bin”目录下，其中$GAUSSLOG 默认为“/var/log/gaussdb/用户名”， 当
前场景下用户名为”omm”。
[omm@node0 ~]$ cd /var/log/omm/omm/bin
[omm@node0 bin]$ ls
显示如下：
gs_cgroup gs_ctl gs_guc gs_initdb gs_obs
步骤 3 以 gs_guc 操作为例，进入 gs_guc 文件夹，并查看文件的属性
[omm@node0 bin]$ cd gs_guc
[omm@node0 gs_guc]$ ll -h
文件列表显示如下：
total 8.0K
-rw------- 1 omm dbgrp 6.6K Mar 28 22:18 gs_guc-2024-03-15_174436-current.log
[omm@node0 gs_guc]$
步骤 4 查看操作日志文件
[omm@node0 gs_guc]$ cat gs_guc-2024-03-15_174436-current.log
日志显示如下：
[2024-03-15 17:44:36]
expected instance path: [/opt/huawei/install/data/dn/postgresql.conf]
gs_guc set: ssl=on: [/opt/huawei/install/data/dn/postgresql.conf]
gs_guc set: ssl_cert_file='server.crt': [/opt/huawei/install/data/dn/postgresql.conf]
gs_guc set: ssl_key_file='server.key': [/opt/huawei/install/data/dn/postgresql.conf]
gs_guc set: ssl_ca_file='cacert.pem': [/opt/huawei/install/data/dn/postgresql.conf]
Total instances: 1. Failed instances: 0.
Success to perform gs_guc!
……
[2024-03-18 04:49:24]
expected instance path: [/opt/huawei/install/data/dn/postgresql.conf]
gs_guc reload: max_connections=6000: [/opt/huawei/install/data/dn/postgresql.conf]
server signaled
Total instances: 1. Failed instances: 0.
Success to perform gs_guc!
[2024-03-28 22:18:23]
expected instance path: [/opt/huawei/install/data/dn/postgresql.conf]
gs_guc reload: max_connections=6000: [/opt/huawei/install/data/dn/postgresql.conf]
server signaled
Total instances: 1. Failed instances: 0.
Success to perform gs_guc!
5 审计日志
审计功能开启时会不断产生大量的审计日志，占用磁盘空间。用户可以根据磁盘空间的大小设置审计日志维护策略。
5.1 前提条件
用户必须拥有审计权限。
omm 用户连接数据库。
步骤 1 以操作系统用户 omm 登录数据库主节点。
[omm@node0 gs_guc]$ logout
[root@node0 ~]# su - omm
Last login: Sun Mar 31 17:47:50 CST 2024 on pts/0
Welcome to 5.10.0-153.12.0.92.oe2203sp2.x86_64
System information as of time: 2024年 03月 31日 星期日 17:57:54 CST
System load: 0.13
Processes: 203
Memory used: 38.6%
Swap used: 20.0%
Usage On: 25%
IP address: 192.168.28.131
Users online: 2
To run a command as administrator(user "root"),use "sudo <command>".
步骤 2 启动 openGauss 数据库服务
[omm@node0 ~]$ gs_om -t start
Starting cluster.
=========================================
[SUCCESS] node0:
[2024-03-31 18:43:01.563][13308][][gs_ctl]: gs_ctl started,datadir is /opt/huawei/install/data/dn
[2024-03-31 18:43:01.573][13308][][gs_ctl]: another server might be running; Please use the restart command
=========================================
Successfully started.
步骤 3 使用如下命令连接数据库
[omm@node0 ~]$ gsql -d postgres -p 15400 -r
gsql ((openGauss 5.0.0 build a07d57c3) compiled at 2023-03-29 03:37:13 commit 0 last mr )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.
postgres 为需要连接的数据库名称，15400为数据库主节点的端口号。
5.2 背景信息
与审计日志相关的配置参数及其含义请参见下表。
表1-1 与审计日志相关的配置参数说明
| 配置项 | 含义 | 默认值 |
| audit_directory | 审计文件的存储目录。 | /var/log/gaussdb/用户名 /pg_audit |
| audit_resource_policy | 审计日志的保存策略。 | on（表示使用空间配置策略） |
| audit_space_limit | 审计文件占用的磁盘空间总量。 | 1 GB |
| audit_file_remain_time | 审计日志文件的最小保存时间。 | 90天 |
| audit_file_remain_thresh old | 审计目录下审计文件的最大数量。 | 1048576 |
说明：如果使用 gs_om 工具部署 openGauss，则审计日志路径为 “/var/log/gaussdb/用户名
/pg_audit”。
审计日志删除命令为数据库提供的 sql 函数 pg_delete_audit，其原型为：
pg_delete_audit(timestamp startime,timestamp endtime)
其中参数 startime 和 endtime 分别表示审计记录的开始时间和结束时间。
目前常用的记录审计内容的方式有两种：记录到数据库的表中、记录到 OS 文件中。这
两种方式的优缺点比较如下表所示。
表1-2 两种方式的优缺点比较
| 方式 | 优点 | 缺点 |
| 记录到表中 | 不需要用户维护审计日志。 | 由于表是数据库的对象，如果一个数据库用户具有一定的权限，就能够访问到审计表。如果该用户非法操作审计表，审计记录的准确性难以得到保证。 |
| 记录到OS文件中 | 比较安全，即使一个帐户可以访问数据库，但不一定有访问OS这个文件的权限。 | 需要用户维护审计日志。 |
从数据库安全角度出发，openGauss 采用记录到 OS 文件的方式来保存审计结果，保证了审计
结果的可靠性。
5.3 选择日志维护方式进行维护
5.3.1 设置自动删除审计日志
审计文件占用的磁盘空间或者审计文件的个数超过指定的最大值时，系统将删除最早的审计文
件，并记录审计文件删除信息到审计日志中。
注：审计文件占用的磁盘空间大小默认值为 1024MB，用户可以根据磁盘空间大小重新设置参
数。
步骤 1 配置审计文件占用磁盘空间的大小（audit_space_limit），查看已配置的参数。
openGauss=# SHOW audit_space_limit;
audit_space_limit
-------------------
1GB
(1 row)
如果显示结果不为 1 GB（1024 MB），执行“\q”命令退出数据库
openGauss =# \q步骤 2 建议执行如下命令设置成默认值 1024 MB。
[omm@node0 ~]$ gs_guc reload -N all -I all -c "audit_space_limit=1024MB"
显示结果为：
The gs_guc run with the following arguments: [gs_guc -N all -I all -c audit_space_limit=1024MB reload ].
Begin to perform the total nodes: 1.
Popen count is 1, Popen success count is 1, Popen failure count is 0.
Begin to perform gs_guc for datanodes.
Command count is 1, Command success count is 1, Command failure count is 0.
Total instances: 1. Failed instances: 0.
ALL: Success to perform gs_guc!
步骤 3 配置审计文件个数的最大值（audit_file_remain_threshold）。连接数据库，查看已配置的参
数。
连接数据库：
[omm@node0 ~]$ gsql -d postgres -p 15400 -r
gsql ((openGauss 5.0.0 build a07d57c3) compiled at 2023-03-29 03:37:13 commit 0 last mr )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.
查看审计文件个数的参数：
openGauss=# SHOW audit_file_remain_threshold;
audit_file_remain_threshold
-----------------------------
1048576
(1 row)
如果显示结果不为 1048576，执行“\q”命令退出数据库
openGauss=# \q
步骤 4 建议执行如下命令设置成默认值 1048576
[omm@node0 ~]$ gs_guc reload -N all -I all -c "audit_file_remain_threshold=1048576"
显示为：
The gs_guc run with the following arguments: [gs_guc -N all -I all -c audit_file_remain_threshold=1048576 reload ].
Begin to perform the total nodes: 1.
Popen count is 1, Popen success count is 1, Popen failure count is 0.
Begin to perform gs_guc for datanodes.
Command count is 1, Command success count is 1, Command failure count is 0.
Total instances: 1. Failed instances: 0.
ALL: Success to perform gs_guc!
5.3.2 手动备份审计文件
当审计文件占用的磁盘空间或者审计文件的个数超过配置文件指定的值时，系统将会自动删除
较早的审计文件，因此建议用户周期性地对比较重要的审计日志进行保存。
步骤 1 连接数据库，使用 show 命令获得审计文件所在目录（audit_directory）。
连接数据库：
[omm@node0 ~]$ gsql -d postgres -p 15400 -r
gsql ((openGauss 5.0.0 build a07d57c3) compiled at 2023-03-29 03:37:13 commit 0 last mr )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.
获得审计文件所在目录：
openGauss=# SHOW audit_directory;
audit_directory
-----------------------------------
/var/log/omm/omm/pg_audit/dn_6001
(1 row)
退出数据库
openGauss=# \q
步骤 2 将审计目录整个拷贝出来进行保存。
(以自己的目录为准)
[omm@node0 ~]$ cp -r /var/log/omm/omm/pg_audit/dn_6001 /var/log/omm/omm/pg_audit/dn_6001_bak
查看备份是否成功：
[omm@node0 ~]$ cd /var/log/omm/omm/pg_audit/
[omm@node0 pg_audit]$ ll -h
total 8.0K
drwxr-x--- 3 omm dbgrp 4.0K Mar 18 00:00 dn_6001
drwx------ 3 omm dbgrp 4.0K Apr 1 10:27 dn_6001_bak
5.3.3 手动删除审计日志
当不再需要某时段的审计记录时，可以使用审计接口命令 pg_delete_audit 进行手动删除。
以删除 2020/07/20 到 2020/07/21 之间的审计记录为例：
步骤 1 连接数据库
[omm@node0 pg_audit]$ gsql -d postgres -p 15400 -r
gsql ((openGauss 5.0.0 build a07d57c3) compiled at 2023-03-29 03:37:13 commit 0 last mr )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.
步骤 2 删除 2020/07/20 到 2020/07/21 之间的审计记录：
openGauss=# SELECT pg_delete_audit('2020-07-20','2020-07-22');
pg_delete_audit
-----------------
(1 row)
openGauss=# \q
6 WAL 日志
预写式日志 WAL（Write Ahead Log，也称为 Xlog）是指如果要修改数据文件，必须是在这些
修改操作已经记录到日志文件之后才能进行修改，即在描述这些变化的日志记录刷新到永久存
储器之后。在系统崩溃时，可以使用 WAL 日志对 openGauss 进行恢复操作。
6.1 操作步骤
步骤 1 以操作系统用户 omm 登录数据库主节点。
[root@node0 ~]# su - omm
Last login: Mon Apr 1 09:52:02 CST 2024 on pts/0
Welcome to 5.10.0-153.12.0.92.oe2203sp2.x86_64
System information as of time: 2024年 04月 01日 星期一 10:41:17 CST
System load: 0.05
Processes: 196
Memory used: 38.7%
Swap used: 14.7%
Usage On: 25%
IP address: 192.168.28.132
Users online: 1
To run a command as administrator(user "root"),use "sudo <command>".
步骤 2 以一个数据库节点为例，默认在“/opt/huawei/install/data/data_dn/pg_xlog”目录下。其中“/opt/huawei/install/data/data_dn”代表 openGauss 节点的数据目录，当前情况下为“/opt/huawei/install/data/dn
[omm@node0 ~]$ cd /opt/huawei/install/data/
[omm@node0 data]$ ls
dn
切换到 dn文件夹。
[omm@node0 data]$ cd dn
[omm@node0 dn]$ ls
文件夹中内容如下：
base pg_ident.conf postgresql.conf
cacert.pem pg_llog postgresql.conf.bak
gaussdb.state pg_location postgresql.conf.guc.bak
global pg_logical postgresql.conf.lock
gs_gazelle.conf pg_multixact postmaster.opts
gswlm_userinfo.cfg pg_notify postmaster.pid
mot.conf pg_replslot postmaster.pid.lock
pg_clog pg_serial server.crt
pg_csnlog pg_snapshots server.key
pg_ctl.lock pg_stat_tmp server.key.cipher
pg_errorinfo pg_tblspc server.key.rand
pg_hba.conf pg_twophase undo
pg_hba.conf.bak PG_VERSION
pg_hba.conf.lock pg_xlog
步骤 3 切换到 pg_xlog 文件夹，查看 WAL 日志文件
[omm@node0 dn]$ cd pg_xlog
[omm@node0 pg_xlog]$ ls
000000010000000000000001 000000010000000000000002 archive_status
[omm@node0 pg_xlog]$ 7 性能日志
性能日志主要关注外部资源的访问性能问题。性能日志指的是数据库系统在运行时检测物理资
源的运行状态的日志，在对外部资源进行访问时的性能检测，包括磁盘、OBS 等外部资源的访
问检测信息。在出现性能问题时，可以借助性能日志及时的定位问题发生的原因，能极大地提
升问题解决效率。
7.1 操作步骤
步骤 1 以操作系统用户 omm 登录数据库主节点。
[omm@node0 pg_xlog]$ logout
[root@node0 ~]# su - omm
Last login: Mon Apr 1 10:41:16 CST 2024 on pts/0
Welcome to 5.10.0-153.12.0.92.oe2203sp2.x86_64
System information as of time: 2024年 04月 01日 星期一 11:28:45 CST
System load: 0.74
Processes: 198
Memory used: 39.1%
Swap used: 16.5%
Usage On: 25%
IP address: 192.168.28.132
Users online: 1
To run a command as administrator(user "root"),use "sudo <command>".
步骤 2 数据库节点的性能日志目录在“$GAUSSLOG/gs_profile”中各自对应的目录下, 其中
$GAUSSLOG 默认为“/var/log/omm/用户名”， 当前场景下用户名为”omm”。切换到文件
夹，查看文件列表的信息。
[omm@node0 ~]$ cd /var/log/omm/omm/gs_profile/
[omm@node0 gs_profile]$ ls
dn_6001
性能日志内容显示如下
total 4.0K
-rw------- 1 omm dbgrp 0 Mar 16 09:51 postgresql-2024-03-16_095122.prf
-rw------- 1 omm dbgrp 48 Mar 18 00:00 postgresql-2024-03-17_214212.prf
-rw------- 1 omm dbgrp 0 Mar 18 00:00 postgresql-2024-03-18_000000.prf
-rw------- 1 omm dbgrp 0 Mar 18 03:38 postgresql-2024-03-18_033830.prf
-rw------- 1 omm dbgrp 0 Mar 18 04:52 postgresql-2024-03-18_045238.prf
-rw------- 1 omm dbgrp 0 Mar 25 18:26 postgresql-2024-03-25_182658.prf
-rw------- 1 omm dbgrp 0 Mar 25 19:42 postgresql-2024-03-25_194258.prf
-rw------- 1 omm dbgrp 0 Mar 28 21:02 postgresql-2024-03-28_210211.prf
-rw------- 1 omm dbgrp 0 Mar 28 22:26 postgresql-2024-03-28_222633.prf
-rw------- 1 omm dbgrp 0 Mar 28 22:35 postgresql-2024-03-28_223555.prf
-rw------- 1 omm dbgrp 0 Mar 29 11:09 postgresql-2024-03-29_110930.prf
-rw------- 1 omm dbgrp 0 Mar 31 16:28 postgresql-2024-03-31_162857.prf
-rw------- 1 omm dbgrp 0 Mar 31 16:51 postgresql-2024-03-31_165132.prf
-rw------- 1 omm dbgrp 0 Apr 1 09:52 postgresql-2024-04-01_095226.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 导出文件进行查看。
本实验结束。
