【 openGauss数据库】--运维指南01
👈【上一篇】
💖The Begin💖 点点关注，收藏不迷路💖
【下一篇】👉
🔻 一、 openGauss数据库运维指南
该篇详细介绍了openGauss数据库常用的运维操作指导，方便更好地使用和管理openGauss数据库。
🔰 1.1 启停openGauss
###🍀1、启动openGauss###🍀以用户omm登录数据库节点🍀###[root@klgdj~]# su - omm###🍀启动openGauss🍀###[omm@klgdj~]$ gs_om -t start
###🍀2、停止openGauss🍀###[omm@klgdj~]$ gs_om -t stop
###🍀3、重启openGauss🍀###[omm@klgdj~]$ gs_om -t restart
🔰 1.2 查看openGauss数据库状态
###🍀1、以用户omm登录数据库节点🍀###[root@klgdj~]# su - omm###🍀2、查看openGauss状态🍀###[omm@klgdj~]$ gs_om -t status--detail###🍀3、查看某主机上的实例状态，请在命令中增加“-h”项，klgdj为主机名称🍀###[omm@klgdj~]$ gs_om -t status-h klgdj
-----------------------------------------------------------------------
cluster_state : Normal
redistributing : No-----------------------------------------------------------------------
node : 1
node_name : klgdj
instance_id : 6001
node_ip : 192.168.181.71
data_path : /opt/software/install/data/dn
instance_port : 15400type : Datanode
instance_state : Normal
az_name : AZ1
instance_role : Normal
-----------------------------------------------------------------------[omm@klgdj~]$
🔻 二、 维护检查项
🔰 2.1 检查实例状态
###🍀1、检查实例状态###🍀以用户omm登录数据库节点🍀###[omm@klgdj~]$ gs_check -U omm -i CheckClusterState -L
###🍀2、检查参数
openGauss=# SHOW parameter_name;----parameter_name为参数名
🔰 2.2 检查锁信息
锁机制是数据库保证数据一致性的重要手段，检查相关信息可以检查数据库的事务和运行状况。
###🍀1、查询数据库中的锁信息
openGauss=# SELECT * FROM pg_locks;###🍀2、查询等待锁的线程状态信息SELECT*FROM pg_thread_wait_status WHERE wait_status ='acquire lock';###🍀3、查找正在运行的系统进程，使用kill命令结束系统进程[omm@klgdj~]$ ps ux
USER PID %CPU %MEM VSZ RSS TTY STAT STARTTIME COMMAND
omm 149887.437.163933881293048 ? Ssl 6月2371:24/opt/software/install/app/bin/gaussdb -D /opt/software/install/data/dn
omm 678400.00.12235165652 pts/0 S 12:230:00-bash
omm 679570.00.22397888392 pts/0 S+12:230:00 gsql -d postgres -p 15400
omm 689460.50.12235165580 pts/1 S 12:360:00-bash
omm 690600.00.02241443448 pts/1 R+12:360:00 ps ux
[omm@klgdj~]$ kill-9 pid
🔰 2.3 统计事件数据
SQL语句长时间运行会占用大量系统资源，用户可以通过查看事件发生的时间，占用内存大小来了解现在数据库运行状态。
###🍀1、查询事件的线程启动时间、事务启动时间、SQL启动时间以及状态变更时间
openGauss=# SELECT backend_start,xact_start,query_start,state_change FROM pg_stat_activity;
backend_start | xact_start | query_start | state_change
-------------------------------+-------------------------------+-------------------------------+-------------------------------2023-06-2412:38:59.847138+08|2023-06-2412:39:02.996939+08|2023-06-2412:39:02.996939+08|2023-06-2412:39:02.996941+082023-06-2320:41:14.919088+08|||2023-06-2412:39:01.739872+082023-06-2320:41:14.91906+08|||2023-06-2320:41:14.919088+082023-06-2320:41:14.918752+08|||2023-06-2412:39:02.446464+082023-06-2320:41:14.896673+08|||2023-06-2320:41:14.919007+082023-06-2320:41:14.896506+08|||2023-06-2320:41:14.918569+082023-06-2320:41:14.892348+08|||2023-06-2320:41:14.918747+082023-06-2320:41:14.913153+08|||2023-06-2412:39:02.902451+08(8rows)
openGauss=####🍀2、查询当前服务器的会话计数信息
openGauss=# SELECT count(*) FROM pg_stat_activity;
count
-------8(1row)
openGauss=# ###🍀3、查询系统级统计信息
openGauss=# SELECT * FROM pv_session_memory_detail() ORDER BY usedsize desc limit 10;
🔰 2.4 对象检查
表、索引、分区、约束等是数据库的核心存储对象，其核心信息和对象维护是DBA重要的日常工作。
###🍀1、查看表的详细信息
openGauss=# \d+ table_name ###🍀2、查询表统计信息
openGauss=# SELECT * FROM pg_statistic;###🍀3、查看索引的详细信息
openGauss=# \d+ index_name###🍀4、查询分区表信息
openGauss=# SELECT * FROM pg_partition;###🍀5、查询约束信息
openGauss=# SELECT * FROM pg_constraint;
🔰 2.5 SQL报告检查
使用EXPLAIN语句查看执行计划。
如 ：在SQL 查询的前面加上EXPLAIN 关键字就行。
db_test01=# EXPLAIN select * from t_user;
QUERY PLAN-------------------------------------------------------
Seq Scan on t_user (cost=0.00..1.07rows=7 width=74)(1row)
db_test01=#
🔰 2.6 备份
数据备份重于一切，日常应检查备份执行情况，并检查备份有效性，确保备份能够保障数据安全，备份安全加密也应兼顾。
###🍀1、指定用户导出数据库
gs_dump dbname -p port -f out.sql-U user_name -W password
[omm@klgdj~]$ gs_dump db_test01 -p 15400-f db_test01_out.sql-U zyl -W zyl#2023
gs_dump[port='15400'][db_test01][2023-06-2413:11:55]: Notice: options -U isnot super or sysadmin role, can only back up objects belonging touser zyl.
gs_dump: [port='15400'][db_test01][archiver (db)][2023-06-2413:11:57] query failed: ERROR: permission denied for relation t_user
DETAIL: N/A
gs_dump: [port='15400'][db_test01][archiver (db)][2023-06-2413:11:57] query was: LOCKTABLEpublic.t_user IN ACCESS SHAREMODE[omm@klgdj~]$ ll
总用量 0-rw------- 1 omm dbgrp 0 6月 24 13:11 db_test01_out.sql
drwxr-xr-x 2 omm dbgrp 596月 1814:59 Desktop
drwxr-xr-x 2 omm dbgrp 64月 1418:07 Documents
drwxr-xr-x 2 omm dbgrp 64月 1418:07 Downloads
drwxr-xr-x 2 omm dbgrp 326月 1814:59 Music
drwxr-xr-x 3 omm dbgrp 246月 1814:59 Pictures
drwxr-xr-x 2 omm dbgrp 64月 1418:07 Videos
[omm@klgdj~]$
###🍀2、导出schema
gs_dump dbname -p port -n schema_name -f out.sql[omm@klgdj~]$ gs_dump db_test01 -p 15400-n test -f db_test01_schema_out.sql
gs_dump[port='15400'][db_test01][2023-06-2413:17:17]: The total objects number is420.
gs_dump[port='15400'][db_test01][2023-06-2413:17:17]: [100.00%]420 objects have been dumped.
gs_dump[port='15400'][db_test01][2023-06-2413:17:17]: dumpdatabase db_test01 successfully
gs_dump[port='15400'][db_test01][2023-06-2413:17:17]: total time: 6033 ms
[omm@klgdj~]$
###🍀3、导出table
gs_dump dbname -p port -t table_name -f out.sql[omm@klgdj~]$ gs_dump db_test01 -p 15400-t t_dept -f db_test01_t_dept_out.sql
gs_dump[port='15400'][db_test01][2023-06-2413:21:16]: The total objects number is421.
gs_dump[port='15400'][db_test01][2023-06-2413:21:16]: [100.00%]421 objects have been dumped.
gs_dump[port='15400'][db_test01][2023-06-2413:21:16]: dumpdatabase db_test01 successfully
gs_dump[port='15400'][db_test01][2023-06-2413:21:16]: total time: 4972 ms
[omm@klgdj~]$
🔰 2.7 基本信息检查
基本信息包括版本、组件、补丁集等信息，定期检查数据库信息并登记在案是数据库生命周期管理的重要内容之一。
###🍀1、版本信息
db_test01=# SELECT version();
version
------------------------------------------------------------------------------------------------------------------------------------------------------(openGauss 5.0.0 build a07d57c3) compiled at 2023-03-2903:09:38commit0last mr on x86_64-unknown-linux-gnu, compiled by g++(GCC)7.3.0,64-bit(1row)
db_test01=# ###🍀2、数据库、表容量检查
openGauss=# SELECT pg_table_size('table_name');
openGauss=# SELECT pg_database_size('database_name');
db_test01=# SELECT pg_table_size('t_user');
pg_table_size
---------------16384(1row)
db_test01=#
db_test01=# SELECT pg_database_size('db_test01');
pg_database_size
------------------13814465(1row)
db_test01=#
🔰 2.8 检查操作系统参数
通过openGauss提供的gs_checkos工具可以完成操作系统状态检查。
只能使用
root用户
执行
gs_checkos
命令。
A1…A14 表示只检查操作系统参数，并不设置。
B1…B6 表示将参数系统参数设置为期望值。
A和B不能同时输入。
###🍀1、以参数“A”为例[root@klgdj~]# gs_checkos -i A --detail[root@klgdj~]# gs_checkos -i A
Checking items:
A1.[ OS version status] : Normal
A2.[ Kernel version status] : Normal
A3.[ Unicode status] : Normal
A4.[Time zone status] : Normal
A5.[ Swap memory status] : Warning
A6.[ System control parameters status] : Warning
A7.[File system configuration status] : Normal
A8.[Disk configuration status] : Normal
A9.[ Pre-read block size status] : Normal
BondMode Null
A11.[ Network card configuration status] : Warning
A12.[Time consistency status] : Warning
A13.[ Firewall service status] : Normal
A14.[ THP service status] : Normal
Total numbers:13. Abnormal numbers:0. Warning numbers:4.[root@klgdj~]# ###🍀2、以参数“B”为例[root@klgdj~]# gs_checkos -i B --detail[root@klgdj~]# gs_checkos -i B
Setting items:
B1.[Set system control parameters ] : Normal
B2.[Setfile system configuration value] : Abnormal
B3.[Set pre-read block size value] : Normal
B5.[Set network card configuration value] : Normal
B6.[Set THP service ] : Normal
B7.[Set RemoveIPC value] : Normal
B8.[SetSession Process ] : Normal
NOTICE: MTU valueandsome warning items can NOT be set. Please do it manually.
Total numbers:7. Abnormal numbers:1. Warning numbers:0.Do setting operation finished. Result: Abnormal.[root@klgdj~]#
🔰 2.9 检查openGauss健康状态
通过openGauss提供的gs_check工具可以开展openGauss健康状态检查。
1、扩容新节点检查只能在root用户下执行，其他场景都必须在omm用户下执行。
2、必须指定-i或-e参数，-i会检查指定的单项，-e会检查对应场景配置中的多项。
3、如果-i参数中不包含root类检查项或-e场景配置列表中没有root类检查项，则不需要交互输入root权限的用户及其密码。
4、可使用–skip-root-items跳过检查项中包含的root类检查，以免需要输入root权限用户及密码。
5、检查扩容新节点与现有节点之间的一致性，在现有节点执行gs_check命令指定–hosts参数进行检查，其中hosts文件中需要写入新节点ip。
####🍀方式1、检查openGauss健康状态[omm@klgdj~]$ gs_check -i CheckClusterState
Parsing the check items config file successfully
[GAUSS-53042]: ERROR: Execute SSH command on host 192.168.181.71 faild. The exception is:
[omm@klgdj~]$
其中，-i指定检查项，注意区分大小写。格式：-i CheckClusterState、-i CheckCPU或-i CheckClusterState，CheckCPU。
####添加 -L 参数，代表本地执行。如果没做免密互连，就会报错[omm@klgdj~]$ gs_check -i CheckClusterState -L
2023-06-2414:04:55[NAM] CheckClusterState
2023-06-2414:04:55[STD] 检查fenced UDF状态,如果为down则报warning;检查集群状态，如果为Normal则检查项通过，否则检查项不通过
2023-06-2414:04:55[RST] OK
cluster_state : Normal
redistributing : No
balanced :
klgdj : Normal
2023-06-2414:04:55[RAW][omm@klgdj~]$
####🍀方式2、对openGauss数据库进行健康检查[omm@klgdj~]$ gs_check -e inspect -L
####其中，-e指定场景名，注意区分大小写。格式：-e inspect或-e upgrade。####默认列表包括：
inspect（例行巡检）、upgrade（升级前巡检）、
install（安装）、binary_upgrade（就地升级前巡检）、health（健康检查巡检）、
slow_node（节点）、longtime（耗时长巡检），可以根据需求自己编写场景。
解决：
[GAUSS-53042]: ERROR: Execute SSH command on host 192.168.181.71 faild. The exception is:添加 -L 参数，代表本地执行。
如果不加-L，他即使检查本机信息也会优先使用SSH连接本机，如果没做免密互连，就会报错
🔰 2.10 检查数据库性能
通过openGauss提供的性能统计工具gs_checkperf可以对硬件性能进行检查。
####🍀对openGauss数据库进行性能检查[omm@klgdj~]$ gs_checkperf
Cluster statistics information:
Host CPU busy time ratio : .69%
MPPDB CPU time%in busy time : 100.00%
Shared Buffer Hit ratio : 99.93%In-memory sort ratio : 0
Physical Reads : 1374
Physical Writes : 1659
DB size : 57 MB
Total Physical writes : 1659
Active SQL count : 4Session count : 8[omm@klgdj~]$
🔰 2.11 检查和清理日志
建议按月检查操作系统日志，排除操作系统运行异常隐患。
关注其中近一个月出现的kernel、error、fatal等字样，根据系统报警信息进行处理。
####🍀查看操作系统日志文件
vim /var/log/messages
🔰 2.12 检查openGauss运行日志
数据库运行时，某些操作在执行过程中可能会出现错误，数据库依然能够运行。但是此时数据库中的数据可能已经发生不一致的情况。
建议按月检查openGauss运行日志，及时发现隐患。
####🍀1、收集数据库日志
gs_collector --begin-time="20230616 01:01" --end-time="20230623 23:59"####🍀2、根据界面输出提示，进入相应的日志收集目录，解压收集的日志，并检查数据库日志。[omm@klgdj~]$ gs_collector --begin-time="20230616 01:01" --end-time="20230623 23:59"
Successfully parsed the configuration file.create Dir.
Successfully create dir.do system checkinterval0 : count 1
Collecting OS information.
Successfully collected OS information.dodatabasecheckinterval0 : count 1
Collecting catalog statistics.
Successfully collected catalog statistics.do log checkinterval0 : count 1
Collecting Log files.
Successfully collected Log files.do Config check0:1
Collecting Config files.
Successfully collected Config files.
Collecting files.
Successfully collected files.All results are stored in/var/log/omm/omm/collector_20230624_141528.tar.gz.[omm@klgdj~]$
####当显示Successfully collected files.----表示日志已经归档
🔰 2.13 清理运行日志
数据库运行过程中会产生大量运行日志，占用大量的磁盘空间，建议清理过期日志文件，只保留一个月的日志。
####🍀a. 将超过1个月的日志备份到其他磁盘。####🍀b. 进入日志存放目录。[omm@klgdj~]$ cd $GAUSSLOG
[omm@klgdj omm]$ ll
总用量 272
drwx------ 3 omm dbgrp 21 6月 18 16:36 asp_data
drwx------ 8 omm dbgrp 97 6月 24 13:11 bin
drwx------ 3 omm dbgrp 20 6月 24 14:09 cm-rw------- 1 omm dbgrp 17273 6月 24 14:14 collector_20230624_141411.tar.gz-rw------- 1 omm dbgrp 257536 6月 24 14:15 collector_20230624_141528.tar.gz
drwx------ 3 omm dbgrp 21 6月 18 16:36 gs_profile
drwx------ 3 omm dbgrp 21 6月 18 16:36 mem_log
drwx------ 2 omm dbgrp 284 6月 24 14:15 om
drwx------ 3 omm dbgrp 21 6月 18 16:35 pg_audit
drwx------ 3 omm dbgrp 21 6月 18 16:35 pg_log
drwx------ 3 omm dbgrp 21 6月 18 16:36 pg_perf
drwx------ 3 omm dbgrp 21 6月 18 16:36 sql_monitor[omm@klgdj omm]$
####🍀c. 进入相应的子目录，使用如下方式删除1个月之前产生的日志。
如：pg_log、mem_log、 om
🔰 2.14 检查时间一致性
数据库事务一致性通过逻辑时钟保证，与操作系统时间无关，但是系统时间不一致会导致诸多潜在问题，主要是后台运维和监控功能异常，因此在月度检查时建议检查各个节点的时间一致性。
**
各节点需要配置互信。
**
####🍀1、创建记录openGauss各节点的配置文件（_mpphosts文件目录_用户可随意指定，建议放在/tmp下）。
vim /tmp/mpphosts
增加各节点的主机名称，保存配置文件。
klgdj
klgdj02
klgdj03
####🍀2、执行如下命令，输出各节点上的时间到“/tmp/sys_ctl-os1.log”文件中。for ihost in`cat /tmp/mpphosts`;do ssh -n -q $ihost "hostname;date"; done >/tmp/sys_ctl-os1.log
####🍀3、根据输出确认各个节点的时间一致性，节点之间时间差异不能超过30秒。
cat /tmp/sys_ctl-os1.log
plat1
Thu June 2416:46:38 CST 2023
plat2
Thu June 2416:46:49 CST 2023
plat3
Thu June 2416:46:14 CST 2023
🔰 2.15 检查应用连接数
如果应用程序与数据库的连接数超过最大值，则新的连接无法建立。建议每天检查连接数，及时释放空闲的连接或者增加最大连接数。
####🍀1、查看连接数
openGauss=# SELECT count(*) FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
count
-------20(1row)
openGauss=# -----20个应用连接到数据库####🍀2、查看现有最大连接数
openGauss=# SHOW max_connections;
max_connections
-----------------5000(1row)
openGauss=#
🔰 2.16 例行维护表
为了保证数据库的有效运行，数据库必须在插入/删除操作后，基于客户场景，定期做VACUUM FULL和ANALYZE，更新统计信息，以便获得更优的性能。
主要有以下原因：
1、VACUUM FULL可回收已更新或已删除的数据所占据的磁盘空间，同时将小数据文件合并。
2、VACUUM对每个表维护了一个可视化映射来跟踪包含对别的活动事务可见的数组的页。一个普通的索引扫描首先通过可视化映射来获取对应的数组，来检查是否对当前事务可见。若无法获取，再通过堆数组抓取的方式来检查。因此更新表的可视化映射，可加速唯一索引扫描。
3、VACUUM可避免执行的事务数超过数据库阈值时，事务ID重叠造成的原有数据丢失。
4、ANALYZE可收集与数据库中表内容相关的统计信息。统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据，生成最有效的执行计划。
####🍀1、使用VACUUM或VACUUM FULL命令，进行磁盘空间回收###可以与数据库操作命令并行运行。###（执行期间，可正常使用的语句：SELECT、INSERT、UPDATE和DELETE。不可正常使用的语句：ALTER TABLE）。###🍀对表执行VACUUM
db_test01=# VACUUM t_user;
VACUUM
db_test01=# ###🍀对表分区执行VACUUM
db_test01=# VACUUM t_user_par PARTITION ( P1 );###🍀对表执行 VACUUM FULL,前提条件：需要向正在执行的表增加排他锁，且需要停止其他所有数据库操作。
db_test01=# VACUUM FULL t_user;
####🍀2、使用ANALYZE语句更新统计信息
db_test01=# ANALYZE t_user;ANALYZE
db_test01=# ####🍀 使用ANALYZE VERBOSE语句更新统计信息，并输出表的相关信息
db_test01=# ANALYZE VERBOSE t_user;
INFO: analyzing "public.t_user"(dn_6001 pid=14988)
INFO: ANALYZE INFO : "t_user": scanned 1of1 pages, containing 17 live rowsand0 dead rows;17rowsin sample,17 estimated total rows(dn_6001 pid=14988)ANALYZE
db_test01=# ####🍀也可以同时执行VACUUM ANALYZE命令进行查询优化
db_test01=# VACUUM ANALYZE t_user;
VACUUM
db_test01=#
🔰 2.17 例行重建索引
数据库经过多次删除操作后，索引页面上的索引键将被删除，造成索引膨胀。
例行重建索引，可有效的提高查询效率。
数据库支持的索引类型为B-tree索引，例行重建索引可有效的提高查询效率。
如果数据发生大量删除后，索引页面上的索引键将被删除，导致索引页面数量的减少，造成索引膨胀。重建索引可回收浪费的空间。
新建的索引中逻辑结构相邻的页面，通常在物理结构中也是相邻的，所以一个新建的索引比更新了多次的索引访问速度要快。
- 重建索引有以下两种方式：
1、先运行DROP INDEX语句删除索引，再运行CREATE INDEX语句创建索引。
在删除索引过程中，会在父表上增加一个短暂的排他锁，阻止相关读写操作。在创建索引过程中，会锁住写操作但是不会锁住读操作，此时读操作只能使用顺序扫描。
2、使用REINDEX语句重建索引。
使用REINDEX TABLE语句重建索引，会在重建过程中增加排他锁，阻止相关读写操作。
使用REINDEX INTERNAL TABLE语句重建desc表（包括列存表的cudesc表）的索引，会在重建过程中增加排他锁，阻止相关读写操作。
####🍀如：表“t_user”上的“id”字段上存在普通索引“t_user_idx”。重建索引有以下两种方式：🍀########🍀方式一🍀########🍀1、删除索引
db_test01=# DROP INDEX t_user_idx;####🍀2、创建索引
db_test01=# CREATE INDEX t_user_idx ON t_user(id);CREATEINDEX
db_test01=# ####🍀方式二🍀########🍀1、使用REINDEX TABLE语句重建索引
db_test01=# REINDEX TABLE t_user;
REINDEX
db_test01=#
🔰 2.18 导出并查看wdr诊断报告
生成快照数据需参数enable_wdr_snapshot=on，访问WDR快照数据需要sysadmin或monadmin权限，因此需要使用root账号或其他拥有权限的账号来生成WDR诊断报告。
####🍀 1、查看和修改生成快照数据需参数enable_wdr_snapshot=on
db_test01=# SHOW enable_wdr_snapshot;
enable_wdr_snapshot
---------------------off(1row)
db_test01=# [omm@klgdj~]$ gs_guc reload -N all-I all-c "enable_wdr_snapshot=on"
db_test01=# SHOW enable_wdr_snapshot;
enable_wdr_snapshot
---------------------on(1row)
db_test01=# ------on，表示开启生成快照数据需参数####🍀 2、启用逻辑内存管理模块（别问我为什么!!!）[omm@klgdj~]$ gs_guc set-N all-I all-c "enable_memory_limit=on"
####🍀1、执行如下命令新建报告文件[omm@klgdj~]$ touch /home/omm/wdrTestNode.html
####🍀2、连接系统库postgres
gsql -d postgres -p 15400-r
####🍀3、选择snapshot.snapshot表中两个不同的snapshot，当这两个snapshot之间未发生服务重启，便可以使用这两个snapshot生成报告
openGauss=# select * from snapshot.snapshot order by start_ts desc limit 10;####🍀4、执行如下命令，在本地生成HTML格式的WDR报告###设置报告格式。\a: 不显示表行列符号， \t: 不显示列名 ，\o: 指定输出文件。
openGauss=# \a \t \o {报告路径}
openGauss=# \a \t \o /home/omm/wdrTestNode.html
Output format is unaligned.
Showing only tuples.
openGauss=# ####🍀5、获取到snapshot的id后，使用generate_wdr_report来导出报告。[omm@klgdj~]$ gsql -d postgres -p 15400-c "select * from snapshot.snapshot"
snapshot_id | start_ts | end_ts
-------------+-------------------------------+-------------------------------1|2023-06-2414:52:37.398808+08|2023-06-2414:52:40.251829+082|2023-06-2415:06:28.114756+08|2023-06-2415:06:30.675224+08(2rows)###begin_snap_id---性能的开始的snapshot的id=1####end_snap_id---结束snapshot的id=2####🍀6、执行如下命令，生成HTML格式的WDR报告
openGauss=# select generate_wdr_report(begin_snap_id Oid, end_snap_id Oid, int report_type, int report_scope, int node_name );####🍀如：生成集群级别的报告：select generate_wdr_report(1,2,'all','dn_6001',null);####🍀生成某个节点的报告：select generate_wdr_report(1,2,'all','node', pgxc_node_str()::cstring);
####🍀或者使用生成报告：
gsql -d postgres -p15400 -q -c "select generate_wdr_report(1,2,'all','cluster',null)"-t -o /home/omm/wdr_report.html
- 查看报告内容
🔰 2.19 数据安全维护建议
为保证openGauss数据库中的数据安全，避免丢失数据、非法访问数据等事故发生。
- 避免数据被丢失
建议规划周期性的物理备份，且对备份文件进行可靠的保存。在系统发生严重错误的情况下，可以利用备份文件，将系统恢复到备份前的状态。
- 避免数据被非法访问
1、建议对数据库用户进行权限分级管理。数据库管理员根据业务需要，建立用户并赋予权限，保证各用户对数据库的合理访问。
2、对于openGauss的服务端和客户端（或基于客户端库开发的应用程序），最好也部署在可信任的内网中。如果服务端和客户端一定要部署在非信任的网络中，需要在服务启动前，打开SSL加密，保证数据在非信任网络上的传输安全。需要注意的是，打开SSL加密会降低数据库的性能。
- 避免系统日志泄露个人数据
1、将调试日志发给他人进行分析前，请删除个人数据。
因为日志级别（log_min_messages）设置为DEBUGx（x为DEBUG级别，取值范围为1~5）时，调试日志中记录的信息可能包含用户的个人数据。
2、将系统日志发给其他人进行分析前，请删除个人数据。因为在默认配置下，当SQL语句执行错误时，日志中会记录出错的SQL语句，而这些SQL语句中可能包含用户个人数据。
3、将log_min_error_statement参数的值设置为PANIC，可以避免将出错的SQL语句记录在系统日志中。若禁用该功能，当出现故障时，很难定位故障原因。
🔰 2.20 慢sql诊断
在SQL语句执行性能不符合预期时，可以查看SQL语句执行信息，便于事后分析SQL语句执行时的行为，从而诊断SQL语句执行出现的相关问题。
####🍀1、查看数据库实例中SQL语句执行信息select*from dbe_perf.get_global_full_sql_by_timestamp(start_timestamp, end_timestamp);
例如：
openGauss=# select * from DBE_PERF.get_global_full_sql_by_timestamp('2023-06-01 09:25:22', '2023-06-22 23:54:41');####🍀2、查看数据库实例中慢SQL语句执行信息select*from dbe_perf.get_global_slow_sql_by_timestamp(start_timestamp, end_timestamp);
例如：
openGauss=# select * from DBE_PERF.get_global_slow_sql_by_timestamp('2023-06-01 09:25:22', '2023-06-22 23:54:41');####🍀3、查看当前主节点SQL语句执行信息select*from statement_history;
例如：
openGauss=# select * from statement_history;####🍀4、查看当前备节点SQL语句执行信息select*from dbe_perf.standby_statement_history(is_only_slow, start_timestamp, end_timestamp);
例如：
select*from dbe_perf.standby_statement_history(true,'2023-06-01 09:25:22','2023-06-22 23:54:41');
🔻 三、总结—温故知新
❓ openGauss数据库运维指南01---通过该章了解，你即将对openGauss数据库有一个更深层次的提升，
如日常维护检查项，数据库备份、表备份，以及数据库健康状态等检查。
❓ openGauss数据库运维指南01---其次，你还可以对数据库日志、性能等方面维护，并通过gsql导出诊断报告。
👈【上一篇】
💖The End💖 点点关注，收藏不迷路💖
【下一篇】👉
本文转载自: https://blog.csdn.net/qq_41840843/article/details/131359761
版权归原作者 醉颜凉 所有， 如有侵权，请联系我们删除。
版权归原作者 醉颜凉 所有， 如有侵权，请联系我们删除。