正文

opengauss数据库日志管理

呼长喜  呼长喜  2023-03-18  344

关键词：

本文介绍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!

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数据库日志管理指导结束。

四opengauss存储引擎

一、简介openGauss存储引擎是可插拔、自组装的，支持多个存储引擎来满足不同场景的业务诉求，目前支持行存储引擎、列存储引擎和内存引擎。早期计算机程序通过文件系统管理数据，到了20世纪60年代这种方式就开始不能满足... 查看详情

opengauss维护管理之日志收集gs_collector

一、概述当openGauss发生故障时，使用此工具收集OS信息、日志信息以及配置文件等信息，来定位问题。可以使用-C参数，指定收集不同的信息内容，具体支持收集的内容信息如表所示。1、gs_collector内容收集对照表TypeNameContent描述... 查看详情

一opengauss概述

一、什么是openGaussopenGauss是一款开源的关系型数据库管理系统，它具有多核高性能、全链路安全性、智能运维等企业级特性。openGauss内核早期源自开源数据库PostgreSQL，融合了华为在数据库领域多年的内核经验，在架构、事务、... 查看详情

opengauss主备流程与参数的详细介绍(代码片段)

一、openGauss主备介绍openGauss的主备架构、如何修改事务提交方式（同步、异步）、解释了主备日志复制的相关GUC参数、以及对openGauss3.0新添加的CM工具进行了介绍。注意点：opengauss是支持单机和一主多备部署方式。(不... 查看详情

⭐opengauss数据库源码解析系列文章——对象权限管理⭐(代码片段)

...。9.4对象权限管理权限管理是安全管理重要的一环，openGauss权限管理基于访问控制列表（accesscontrollist，ACL&#x 查看详情

参赛作品3day1：初识opengauss

openGauss竞争力总览产品特点 openGauss相比其他开源数据库主要有复合应用场景、高性能和高可用等产品特点。系统架构 openGauss是单机系统，在这样的系统架构中，业务数据存储在单个物理节点上，数据访问... 查看详情

opengauss维护管理之基本操作

...试验1、登录数据库su-omm[omm@gsdb01~]$gsql-dpostgres-p26000-rgsql((openGauss3.1.1build70980198)compiledat2023-01-0609:27:09commit0lastmr)Non-SSLconnection(SSLconnectionisrecommendedwhenrequiringhigh-security)Type"help"forhelp.2、创建和管理用户1、创建用户通过CREATEUSER创建的... 查看详情

⭐opengauss数据库源码解析系列文章——角色管理⭐(代码片段)

❤️‍大家好，我是Gauss松鼠会，欢迎进来学习啦~❤️‍在前面介绍过“9.1安全管理整体架构和代码概览、9.2安全认证”，本篇我们介绍第9章安全管理源码解析中“9.3角色管理”的相关精彩内容介绍。9.3角色管理角... 查看详情

opengauss维护管理之db性能检查gs_checkperf

一、概述1、背景信息openGauss提供了gs_checkperf工具来帮助对openGauss级别（主机CPU占用率、GaussCPU占用率、I/O使用情况等）、节点级别（CPU使用情况、内存使用情况、I/O使用情况）、会话/进程级别（CPU使用情况、内存使用情况、I/O... 查看详情

opengauss维护管理之最大连接数设置

...、登录服务器gsql-dpostgres-p26000-r2、查看当前已使用连接数openGauss=#selectcount(1)frompg_stat_activity;count-------10(1row)3、查看数据库设置的最大连接数openGauss=#SHOWmax_connections;max_connections-----------------5000(1row)5000表示数据库设置的最大连接个... 查看详情

opengauss数据库源码解析系列文章——存储引擎源码解析(代码片段)

...aceUpdate更新模式，中文意思为：原地更新，是openGauss内核新增的一种存储模式。openGauss内核查看详情

opengauss主备流程与参数的详细介绍(代码片段)

opengauss和postgresql的源码目录结构对比(代码片段)

openGauss和PostgreSQL的源码目录结构对比ZTYan专注数据库 11人赞同了该文章前言：openGauss内核虽然源于PostgreSQL，但是华为在多个维度进行了深度的改进。本文从源目录的组织结构入手来研究openGauss，笔者在不断深入的研究中不禁... 查看详情

opengauss维护管理之大小写敏感

一、概述1、基于PostgreSQL数据敏感openGauss源于PostgreSQLPostgreSQL对数据大小写敏感：1、PG中默认是大小写不敏感，表名、字段名等不区分大小写，大写字母会自动转换为小写字母，需要使用大写字母时需要使用双引号，或借助函数2... 查看详情

opengauss维护管理之客户端连接工具gsql

一、概述gsql是openGauss提供在命令行下运行的数据库连接工具，可以通过此工具连接服务器并对其进行操作和维护，除了具备操作数据库的基本功能，gsql还提供了若干高级特性，便于用户使用。1、基本功能**连接数据库：gsql创建... 查看详情

六opengauss和postgresql的源码目录结构对比

...管理、内存管理等各个功能模块的代码进行深入的研究。openGauss内核源于PostgreSQL9.2.4版本，因此本文中我们通过对比的方式来探寻openGauss和PostgreSQL在源码目录和组织结构的异同。首先我们需要弄清楚openGauss的产品定位，以及它... 查看详情

三opengauss代码结构

一、通信管理openGauss查询响应是使用简单的“单一用户对应一个服务器线程”的客户端/服务器模型实现的。由于我们无法提前知道需要建立多少个连接，因此必须使用主进程（GaussMaster）主进程在指定的TCP/IP（TransmissionControlProto... 查看详情

opengauss维护管理之explain执行计划

...机模式中是被禁止使用的。假如使用，会产生如下错误。openGauss=#createtablestudent(idint,namechar(20));CREATETABLEopenGauss=#explain(nodestrue)insertintostudentvalues(5,a),(6,b);ERROR:unrecogn 查看详情