例行维护
日维护检查项
检查openGauss状态
通过openGauss提供的工具查询数据库和实例状态,确认数据库和实例都处于正常的运行状态,可以对外提供数据服务。
检查实例状态
gs_check -U omm -i CheckClusterState
检查参数
openGauss=# SHOW parameter_name;
上述命令中,parameter_name需替换成具体的参数名称。
修改参数
gs_guc reload -D /gaussdb/data/dbnode -c "paraname=value"
检查锁信息
锁机制是数据库保证数据一致性的重要手段,检查相关信息可以检查数据库的事务和运行状况。
查询数据库中的锁信息
openGauss=# SELECT * FROM pg_locks;
查询等待锁的线程状态信息
openGauss=# SELECT * FROM pg_thread_wait_status WHERE wait_status = 'acquire lock';
结束系统进程
查找正在运行的系统进程,然后使用kill命令结束此进程。
ps ux kill -9 pid
统计事件数据
SQL语句长时间运行会占用大量系统资源,用户可以通过查看事件发生的时间,占用内存大小来了解现在数据库运行状态。
查询事件的时间
查询事件的线程启动时间、事务启动时间、SQL启动时间以及状态变更时间。
openGauss=# SELECT backend_start,xact_start,query_start,state_change FROM pg_stat_activity;
查询当前服务器的会话计数信息
openGauss=# SELECT count(*) FROM pg_stat_activity;
查询系统级统计信息
查询当前使用内存最多的会话信息。
openGauss=# SELECT * FROM pv_session_memory_detail() ORDER BY usedsize desc limit 10;
对象检查
表、索引、分区、约束等是数据库的核心存储对象,其核心信息和对象维护是DBA重要的日常工作。
查看表的详细信息
openGauss=# \d+ table_name
查询表统计信息
openGauss=# SELECT * FROM pg_statistic;
查看索引的详细信息
openGauss=# \d+ index_name
查询分区表信息
openGauss=# SELECT * FROM pg_partition;
收集统计信息
使用ANALYZE语句收集数据库相关的统计信息。
使用VACUUM语句可以回收空间并更新统计信息。
查询约束信息
openGauss=# SELECT * FROM pg_constraint;
SQL报告检查
使用EXPLAIN语句查看执行计划。
备份
数据备份重于一切,日常应检查备份执行情况,并检查备份有效性,确保备份能够保障数据安全,备份安全加密也应兼顾。
指定用户导出数据库
gs_dump dbname -p port -f out.sql -U user_name -W password
导出schema
gs_dump dbname -p port -n schema_name -f out.sql
导出table
gs_dump dbname -p port -t table_name -f out.sql
基本信息检查
基本信息包括版本、组件、补丁集等信息,定期检查数据库信息并登记在案是数据库生命周期管理的重要内容之一。
版本信息
openGauss=# SELECT version();
容量检查
openGauss=# SELECT pg_table_size('table_name'); openGauss=# SELECT pg_database_size('database_name');
检查操作系统参数
检查办法
通过openGauss提供的gs_checkos工具可以完成操作系统状态检查。
前提条件
- 当前的硬件和网络环境正常。
- 各主机间root互信状态正常。
- 只能使用root用户执行gs_checkos命令。
操作步骤
以root用户身份登录任意一台服务器。
执行如下命令对openGauss节点服务器的OS参数进行检查。
gs_checkos -i A
检查节点服务器的OS参数的目的是保证openGauss正常通过预安装,并且在安装成功后可以安全高效的运行。详细的检查项目请参见《工具与命令参考》中“服务端工具 > gs_checkos”章节。
示例
执行gs_checkos前需要先使用gs_preinstall工具执行前置脚本,准备环境。以参数“A”为例。
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 ] : Normal
A6. [ System control parameters status ] : Normal
A7. [ File system configuration status ] : Normal
A8. [ Disk configuration status ] : Normal
A9. [ Pre-read block size status ] : Normal
A10.[ IO scheduler status ] : Normal
A11.[ Network card configuration status ] : Normal
A12.[ Time consistency status ] : Warning
A13.[ Firewall service status ] : Normal
A14.[ THP service status ] : Normal
Total numbers:14. Abnormal numbers:0. Warning number:1.
以参数“B”为例。
gs_checkos -i B
Setting items:
B1. [ Set system control parameters ] : Normal
B2. [ Set file system configuration value ] : Normal
B3. [ Set pre-read block size value ] : Normal
B4. [ Set IO scheduler value ] : Normal
B5. [ Set network card configuration value ] : Normal
B6. [ Set THP service ] : Normal
B7. [ Set RemoveIPC value ] : Normal
B8. [ Set Session Process ] : Normal
Total numbers:6. Abnormal numbers:0. Warning number:0.
异常处理
使用gs_checkos检查openGauss状态,可以使用如下命令查看详细的错误信息。
gs_checkos -i A --detail
其中,Abnormal为必须处理项,影响openGauss安装。Warning可以不处理,不会影响openGauss安装。
如果操作系统版本(A1)检查项检查结果为Abnormal,需要将不属于混编范围的操作系统版本替换为混编范围内的操作系统版本。
如果内核版本(A2)检查项检查结果为Warning,则表示openGauss集群内操作系统平台的内核版本不一致。
如果Unicode状态(A3)检查项检查结果为Abnormal,需要将各主机的字符集设置为相同的字符集,可以在/etc/profile文件中添加“export LANG=XXX”(XXX为Unicode编码)。
vim /etc/profile
如果时区状态(A4)检查项检查结果为Abnormal,需要将各主机的时区设置为相同时区,可以将/usr/share/zoneinfo/目录下的时区文件拷贝为/etc/localtime文件。
cp /usr/share/zoneinfo/$主时区/$次时区 /etc/localtime
如果交换内存状态(A5)检查项检查结果为Abnormal,可能是因为Swap空间大于Mem空间,可减小Swap解决或者增大Mem空间解决。
如果系统控制参数(A6)检查项检查结果为Abnormal,可以使用以下两种方法进行设置。
可以使用如下命令进行设置。
gs_checkos -i B1
根据错误提示信息,在/etc/sysctl.conf文件中进行设置。然后执行sysctl -p使其生效。
vim /etc/sysctl.conf
如果文件系统配置状态(A7)检查项检查结果为Abnormal,可以使用如下命令进行设置。
gs_checkos -i B2
如果磁盘配置状态(A8)检查项检查结果为Abnormal,需修改磁盘挂载格式为:“rw,noatime,inode64,allocsize=16m”。
使用linux的man mount命令挂载XFS选项:
rw,noatime,inode64,allocsize=16m
也可以在/etc/fstab文件中设定XFS选项。如下示例:
/dev/data /data xfs rw,noatime,inode64,allocsize=16m 0 0
如果预读块大小(A9)检查项检查结果为Abnormal,可以使用如下命令进行设置。
gs_checkos -i B3
如果IO调度状态(A10)检查项检查结果为Abnormal,可以使用如下命令进行设置。
gs_checkos -i B4
如果网卡配置状态(A11)检查项检查结果为Warning,可以使用如下命令进行设置。
gs_checkos -i B5
如果时间一致性(A12)检查项检查结果为Abnormal,需检查是否安装ntp服务,以及ntp服务是否启动;并与ntp时钟源同步。
如果防火墙状态(A13)检查项检查结果为Abnormal,需关闭防火墙服务。使用如下命令进行设置。
SuSE:
SuSEfirewall2 stop
RedHat7:
systemctl disable firewalld systemctl stop firewalld
RedHat6:
service iptables stop
如果THP服务(A14)检查项检查结果为Abnormal,可以使用如下命令进行设置。
gs_checkos -i B6
检查openGauss健康状态
检查办法
通过openGauss提供的gs_check工具可以开展openGauss健康状态检查。
注意事项
- 扩容新节点检查只能在root用户下执行,其他场景都必须在omm用户下执行。
- 必须指定-i或-e参数,-i会检查指定的单项,-e会检查对应场景配置中的多项。
- 如果-i参数中不包含root类检查项或-e场景配置列表中没有root类检查项,则不需要交互输入root权限的用户及其密码。
- 可使用--skip-root-items跳过检查项中包含的root类检查,以免需要输入root权限用户及密码。
- 检查扩容新节点与现有节点之间的一致性,在现有节点执行gs_check命令指定--hosts参数进行检查,其中hosts文件中需要写入新节点ip。
操作步骤
方式1:
以操作系统用户omm登录数据库主节点。
执行如下命令对openGauss数据库状态进行检查。
gs_check -i CheckClusterState
其中,-i指定检查项,注意区分大小写。格式:-i CheckClusterState、-i CheckCPU或-i CheckClusterState,CheckCPU。
取值范围为所有支持的检查项名称,详细列表请参见《工具与命令参考》中“服务端工具 > gs_checkos > openGauss状态检查表”,用户可以根据需求自己编写新检查项。
方式2:
以操作系统用户omm登录数据库主节点。
执行如下命令对openGauss数据库进行健康检查。
gs_check -e inspect
其中,-e指定场景名,注意区分大小写。格式:-e inspect或-e upgrade。
取值范围为所有支持的巡检场景名称,默认列表包括:inspect(例行巡检)、upgrade(升级前巡检)、install(安装)、binary_upgrade(升级前巡检)、health(健康检查巡检)、slow_node(节点)、longtime(耗时长巡检),用户可以根据需求自己编写场景。
openGauss巡检的主要作用是在openGauss运行过程中,检查整个openGauss状态是否正常,或者重大操作前(升级、扩容),确保openGauss满足操作所需的环境条件和状态条件。详细的巡检项目和场景请参见《工具与命令参考》中“服务端工具 > gs_checkos > openGauss状态检查表”。
示例
执行单项检查结果:
perfadm@lfgp000700749:/opt/huawei/perfadm/tool/script> gs_check -i CheckCPU
Parsing the check items config file successfully
Distribute the context file to remote hosts successfully
Start to health check for the cluster. Total Items:1 Nodes:3
Checking... [=========================] 1/1
Start to analysis the check result
CheckCPU....................................OK
The item run on 3 nodes. success: 3
Analysis the check result successfully
Success. All check items run completed. Total:1 Success:1 Failed:0
For more information please refer to /opt/huawei/wisequery/script/gspylib/inspection/output/CheckReport_201902193704661604.tar.gz
本地执行结果:
perfadm@lfgp000700749:/opt/huawei/perfadm/tool/script> gs_check -i CheckCPU -L
2017-12-29 17:09:29 [NAM] CheckCPU
2017-12-29 17:09:29 [STD] 检查主机CPU占用率,如果idle 大于30%并且iowait 小于 30%.则检查项通过,否则检查项不通过
2017-12-29 17:09:29 [RST] OK
2017-12-29 17:09:29 [RAW]
Linux 4.4.21-69-default (lfgp000700749) 12/29/17 _x86_64_
17:09:24 CPU %user %nice %system %iowait %steal %idle
17:09:25 all 0.25 0.00 0.25 0.00 0.00 99.50
17:09:26 all 0.25 0.00 0.13 0.00 0.00 99.62
17:09:27 all 0.25 0.00 0.25 0.13 0.00 99.37
17:09:28 all 0.38 0.00 0.25 0.00 0.13 99.25
17:09:29 all 1.00 0.00 0.88 0.00 0.00 98.12
Average: all 0.43 0.00 0.35 0.03 0.03 99.17
执行场景检查结果:
[perfadm@SIA1000131072 Check]$ gs_check -e inspect
Parsing the check items config file successfully
The below items require root privileges to execute:[CheckBlockdev CheckIOrequestqueue CheckIOConfigure CheckCheckMultiQueue CheckFirewall CheckSshdService CheckSshdConfig CheckCrondService CheckBootItems CheckFilehandle CheckNICModel CheckDropCache]
Please enter root privileges user[root]:root
Please enter password for user[root]:
Please enter password for user[root] on the node[10.244.57.240]:
Check root password connection successfully
Distribute the context file to remote hosts successfully
Start to health check for the cluster. Total Items:57 Nodes:2
Checking... [ ] 21/57
Checking... [=========================] 57/57
Start to analysis the check result
CheckClusterState...........................OK
The item run on 2 nodes. success: 2
CheckDBParams...............................OK
The item run on 1 nodes. success: 1
CheckDebugSwitch............................OK
The item run on 2 nodes. success: 2
CheckDirPermissions.........................OK
The item run on 2 nodes. success: 2
CheckReadonlyMode...........................OK
The item run on 1 nodes. success: 1
CheckEnvProfile.............................OK
The item run on 2 nodes. success: 2 (consistent)
The success on all nodes value:
GAUSSHOME /usr1/gaussdb/app
LD_LIBRARY_PATH /usr1/gaussdb/app/lib
PATH /usr1/gaussdb/app/bin
CheckBlockdev...............................OK
The item run on 2 nodes. success: 2
CheckCurConnCount...........................OK
The item run on 1 nodes. success: 1
CheckCursorNum..............................OK
The item run on 1 nodes. success: 1
CheckPgxcgroup..............................OK
The item run on 1 nodes. success: 1
CheckDiskFormat.............................OK
The item run on 2 nodes. success: 2
CheckSpaceUsage.............................OK
The item run on 2 nodes. success: 2
CheckInodeUsage.............................OK
The item run on 2 nodes. success: 2
CheckSwapMemory.............................OK
The item run on 2 nodes. success: 2
CheckLogicalBlock...........................OK
The item run on 2 nodes. success: 2
CheckIOrequestqueue.....................WARNING
The item run on 2 nodes. warning: 2
The warning[host240,host157] value:
On device (vdb) 'IO Request' RealValue '256' ExpectedValue '32768'
On device (vda) 'IO Request' RealValue '256' ExpectedValue '32768'
CheckMaxAsyIOrequests.......................OK
The item run on 2 nodes. success: 2
CheckIOConfigure............................OK
The item run on 2 nodes. success: 2
CheckMTU....................................OK
The item run on 2 nodes. success: 2 (consistent)
The success on all nodes value:
1500
CheckPing...................................OK
The item run on 2 nodes. success: 2
CheckRXTX...................................NG
The item run on 2 nodes. ng: 2
The ng[host240,host157] value:
NetWork[eth0]
RX: 256
TX: 256
CheckNetWorkDrop............................OK
The item run on 2 nodes. success: 2
CheckMultiQueue.............................OK
The item run on 2 nodes. success: 2
CheckEncoding...............................OK
The item run on 2 nodes. success: 2 (consistent)
The success on all nodes value:
LANG=en_US.UTF-8
CheckFirewall...............................OK
The item run on 2 nodes. success: 2
CheckKernelVer..............................OK
The item run on 2 nodes. success: 2 (consistent)
The success on all nodes value:
3.10.0-957.el7.x86_64
CheckMaxHandle..............................OK
The item run on 2 nodes. success: 2
CheckNTPD...................................OK
host240: NTPD service is running, 2020-06-02 17:00:28
host157: NTPD service is running, 2020-06-02 17:00:06
CheckOSVer..................................OK
host240: The current OS is centos 7.6 64bit.
host157: The current OS is centos 7.6 64bit.
CheckSysParams..........................WARNING
The item run on 2 nodes. warning: 2
The warning[host240,host157] value:
Warning reason: variable 'net.ipv4.tcp_retries1' RealValue '3' ExpectedValue '5'.
Warning reason: variable 'net.ipv4.tcp_syn_retries' RealValue '6' ExpectedValue '5'.
CheckTHP....................................OK
The item run on 2 nodes. success: 2
CheckTimeZone...............................OK
The item run on 2 nodes. success: 2 (consistent)
The success on all nodes value:
+0800
CheckCPU....................................OK
The item run on 2 nodes. success: 2
CheckSshdService............................OK
The item run on 2 nodes. success: 2
Warning reason: UseDNS parameter is not set; expected: no
CheckCrondService...........................OK
The item run on 2 nodes. success: 2
CheckStack..................................OK
The item run on 2 nodes. success: 2 (consistent)
The success on all nodes value:
8192
CheckSysPortRange...........................OK
The item run on 2 nodes. success: 2
CheckMemInfo................................OK
The item run on 2 nodes. success: 2 (consistent)
The success on all nodes value:
totalMem: 31.260929107666016G
CheckHyperThread............................OK
The item run on 2 nodes. success: 2
CheckTableSpace.............................OK
The item run on 1 nodes. success: 1
CheckSysadminUser...........................OK
The item run on 1 nodes. success: 1
CheckGUCConsistent..........................OK
All DN instance guc value is consistent.
CheckMaxProcMemory..........................OK
The item run on 1 nodes. success: 1
CheckBootItems..............................OK
The item run on 2 nodes. success: 2
CheckHashIndex..............................OK
The item run on 1 nodes. success: 1
CheckPgxcRedistb............................OK
The item run on 1 nodes. success: 1
CheckNodeGroupName..........................OK
The item run on 1 nodes. success: 1
CheckTDDate.................................OK
The item run on 1 nodes. success: 1
CheckDilateSysTab...........................OK
The item run on 1 nodes. success: 1
CheckKeyProAdj..............................OK
The item run on 2 nodes. success: 2
CheckProStartTime.......................WARNING
host157:
STARTED COMMAND
Tue Jun 2 16:57:18 2020 /usr1/dmuser/dmserver/metricdb1/server/bin/gaussdb --single_node -D /usr1/dmuser/dmb1/data -p 22204
Mon Jun 1 16:15:15 2020 /usr1/gaussdb/app/bin/gaussdb -D /usr1/gaussdb/data/dn1 -M standby
CheckFilehandle.............................OK
The item run on 2 nodes. success: 2
CheckRouting................................OK
The item run on 2 nodes. success: 2
CheckNICModel...............................OK
The item run on 2 nodes. success: 2 (consistent)
The success on all nodes value:
version: 1.0.1
model: Red Hat, Inc. Virtio network device
CheckDropCache..........................WARNING
The item run on 2 nodes. warning: 2
The warning[host240,host157] value:
No DropCache process is running
CheckMpprcFile..............................NG
The item run on 2 nodes. ng: 2
The ng[host240,host157] value:
There is no mpprc file
Analysis the check result successfully
Failed. All check items run completed. Total:57 Success:50 Warning:5 NG:2
For more information please refer to /usr1/gaussdb/tool/script/gspylib/inspection/output/CheckReport_inspect611.tar.gz
异常处理
如果发现检查结果异常,可以根据以下内容进行修复。
表 1 检查openGauss运行状态
检查数据库性能
检查办法
通过openGauss提供的性能统计工具gs_checkperf可以对硬件性能进行检查。
前提条件
- openGauss运行状态正常。
- 运行在数据库之上的业务运行正常。
操作步骤
以操作系统用户omm登录数据库主节点。
执行如下命令对openGauss数据库进行性能检查。
gs_checkperf
具体的性能统计项目请参见《工具与命令参考》中“服务端工具 > gs_checkperf > 性能检查项”。
示例
以简要格式在屏幕上显示性能统计结果。
gs_checkperf -i pmk -U omm
Cluster statistics information:
Host CPU busy time ratio : 1.43 %
MPPDB CPU time % in busy time : 1.88 %
Shared Buffer Hit ratio : 99.96 %
In-memory sort ratio : 100.00 %
Physical Reads : 4
Physical Writes : 25
DB size : 70 MB
Total Physical writes : 25
Active SQL count : 2
Session count : 3
异常处理
使用gs_checkperf工具检查openGauss性能状态后,如果发现检查结果发现异常,可以根据以下内容进行修复。
表 2 检查openGauss级别性能状态
2、使用top命令查看系统哪些进程的CPU占有率高,然后使用kill命令关闭没有使用的进程。 top | |
查看哪个进程占用CPU/内存高或I/O使用率高,若是无用的进程,则kill掉,否则排查具体原因。例如SQL执行占用内存大,查看是否SQL语句需要优化。 |
表 5 SSD性能状态
gs_checkperf -i SSD -U omm |
检查和清理日志
日志是检查系统运行及故障定位的关键手段。建议按月度例行查看操作系统日志及数据库的运行日志。同时,随着时间的推移,日志的增加会占用较多的磁盘空间。建议按月度清理数据库的运行日志。
检查操作系统日志
建议按月检查操作系统日志,排除操作系统运行异常隐患。
执行如下命令查看操作系统日志文件。
vim /var/log/messages
关注其中近一个月出现的kernel、error、fatal等字样,根据系统报警信息进行处理。
检查openGauss运行日志
数据库运行时,某些操作在执行过程中可能会出现错误,数据库依然能够运行。但是此时数据库中的数据可能已经发生不一致的情况。建议按月检查openGauss运行日志,及时发现隐患。
前提条件
- 收集日志的主机网络通畅且未宕机,数据库安装用户互信正常。
- 日志收集工具依赖操作系统工具如gstack,如果未安装该工具,则提示错误后,跳过该收集项。
操作步骤
以操作系统用户omm登录数据库主节点。
gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59"
20160616 01:01为日志的开始时间,20160616 23:59为日志的结束时间。
根据2的界面输出提示,进入相应的日志收集目录,解压收集的日志,并检查数据库日志。
以下以日志收集路径“/opt/gaussdb/tmp/gaussdba_mppdb/collector_20160726_105158.tar.gz”为例进行操作。
tar -xvzf /opt/gaussdb/tmp/gaussdba_mppdb/collector_20160726_105158.tar.gz cd /opt/gaussdb/tmp/gaussdba_mppdb/collector_20160726_105158
示例
以--begin-time与--end-time为参数执行gs_collector命令。
gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59"
当显示类似如下信息表示日志已经归档。
Successfully collected files All results are stored in /tmp/gaussdba_mppdb/collector_20160616_175615.tar.gz.
以--begin-time、--end-time与-h为参数执行gs_collector命令。
gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" -h plat2
当显示类似如下信息表示日志已经归档。
Successfully collected files All results are stored in /tmp/gaussdba_mppdb/collector_20160616_190225.tar.gz.
以--begin-time、--end-time与-f为参数执行gs_collector命令。
gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" -f /opt/software/gaussdb/output
当显示类似如下信息表示日志已经归档。
Successfully collected files All results are stored in /opt/software/gaussdb/output/collector_20160616_190511.tar.gz.
以--begin-time、--end-time与--keyword为参数执行gs_collector命令。
gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" --keyword="os"
当显示类似如下信息表示日志已经归档。
Successfully collected files. All results are stored in /tmp/gaussdba_mppdb/collector_20160616_190836.tar.gz.
以--begin-time、--end-time与-o为参数执行gs_collector命令。
gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" -o /opt/software/gaussdb/output
当显示类似如下信息表示日志已经归档。
Successfully collected files. All results are stored in /opt/software/gaussdb/output/collector_20160726_113711.tar.gz.
以--begin-time、--end-time与-l为参数(文件名必须以.log为后缀)执行gs_collector命令。
gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" -l /opt/software/gaussdb/logfile.log
当显示类似如下信息表示日志已经归档。
Successfully collected files. All results are stored in /opt/software/gaussdb/output/collector_20160726_113711.tar.gz.
清理运行日志
数据库运行过程中会产生大量运行日志,占用大量的磁盘空间,建议清理过期日志文件,只保留一个月的日志。
操作步骤
以操作系统用户omm登录数据库主节点。
清理日志。
a. 将超过1个月的日志备份到其他磁盘。
b. 进入日志存放目录。
cd $GAUSSLOG
c. 进入相应的子目录,使用如下方式删除1个月之前产生的日志。
rm 日志名称
日志文件的命名格式为“postgresql-年-月-日_HHMMSS”。
检查时间一致性
数据库事务一致性通过逻辑时钟保证,与操作系统时间无关,但是系统时间不一致会导致诸多潜在问题,主要是后台运维和监控功能异常,因此在月度检查时建议检查各个节点的时间一致性。
操作步骤
以操作系统用户omm登录数据库主节点。
创建记录openGauss各节点的配置文件(_mpphosts文件目录_用户可随意指定,建议放在/tmp下)。
vim /tmp/mpphosts
增加各节点的主机名称。
plat1 plat2 plat3
保存配置文件。
:wq!
执行如下命令,输出各节点上的时间到“/tmp/sys_ctl-os1.log”文件中。
for ihost in `cat /tmp/mpphosts`; do ssh -n -q $ihost "hostname;date"; done > /tmp/sys_ctl-os1.log
根据输出确认各个节点的时间一致性,节点之间时间差异不能超过30秒。
cat /tmp/sys_ctl-os1.log plat1 Thu Feb 9 16:46:38 CST 2017 plat2 Thu Feb 9 16:46:49 CST 2017 plat3 Thu Feb 9 16:46:14 CST 2017
检查应用连接数
如果应用程序与数据库的连接数超过最大值,则新的连接无法建立。建议每天检查连接数,及时释放空闲的连接或者增加最大连接数。
操作步骤
以操作系统用户omm登录数据库主节点。
使用如下命令连接数据库。
gsql -d postgres -p 8000
postgres为需要连接的数据库名称,8000为数据库主节点的端口号。
连接成功后,系统显示类似如下信息:
gsql ((openGauss 1.0 build 290d125f) compiled at 2020-05-08 02:59:43 commit 2143 last mr 131 Non-SSL connection (SSL connection is recommended when requiring high-security) Type "help" for help. openGauss=#
执行如下SQL语句查看连接数。
openGauss=# SELECT count(*) FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
显示类似如下的信息,其中2表示当前有两个应用连接到数据库。
count ------- 2 (1 row)
查看现有最大连接数。
openGauss=# SHOW max_connections;
显示信息如下,其中200为现在的最大连接数。
max_connections ----------------- 200 (1 row)
异常处理
如果显示的连接数接近数据库的最大连接数max_connections,则需要考虑清理现有连接数或者增加新的连接数。
执行如下SQL语句,查看state字段等于idle,且state_change字段长时间没有更新过的连接信息。
openGauss=# SELECT * FROM pg_stat_activity where state='idle' order by state_change;
显示类似如下的信息:
datid | datname | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | xact_start | quer y_start | state_change | waiting | enqueue | state | resource_pool | query -------+----------+-----------------+----------+----------+------------------+--------------- -+-----------------+-------------+-------------------------------+------------+-------------- -----------------+-------------------------------+---------+---------+-------+--------------- +---------------------------------------------- 13626 | postgres | 140390162233104 | 10 | gaussdba | | | | -1 | 2016-07-15 14:08:59.474118+08 | | 2016-07-15 14 :09:04.496769+08 | 2016-07-15 14:09:04.496975+08 | f | | idle | default_pool | select count(group_name) from pgxc_group; 13626 | postgres | 140390132872976 | 10 | gaussdba | cn_5002 | 10.180.123.163 | | 48614 | 2016-07-15 14:11:16.014871+08 | | 2016-07-15 14 :21:17.346045+08 | 2016-07-15 14:21:17.346095+08 | f | | idle | default_pool | SET SESSION AUTHORIZATION DEFAULT;RESET ALL; (2 rows)
释放空闲的连接数。
查看每个连接,并与此连接的使用者确认是否可以断开连接,或执行如下SQL语句释放连接。其中,pid为上一步查询中空闲连接所对应的pid字段值。
openGauss=# SELECT pg_terminate_backend(140390132872976);
显示类似如下的信息:
openGauss=# SELECT pg_terminate_backend(140390132872976); pg_terminate_backend ---------------------- t (1 row)
如果没有可释放的连接,请执行下一步。
增加最大连接数。
gs_guc set -D /gaussdb/data/dbnode -c "max_connections= 800"
其中800为新修改的连接数。
重启数据库服务使新的设置生效。
说明: 重启openGauss操作会导致用户执行操作中断,请在操作之前规划好合适的执行窗口。
gs_om -t stop && gs_om -t start
例行维护表
为了保证数据库的有效运行,数据库必须在插入/删除操作后,基于客户场景,定期做VACUUM FULL和ANALYZE,更新统计信息,以便获得更优的性能。
相关概念
使用VACUUM、VACUUM FULL和ANALYZE命令定期对每个表进行维护,主要有以下原因:
- VACUUM FULL可回收已更新或已删除的数据所占据的磁盘空间,同时将小数据文件合并。
- VACUUM对每个表维护了一个可视化映射来跟踪包含对别的活动事务可见的数组的页。一个普通的索引扫描首先通过可视化映射来获取对应的数组,来检查是否对当前事务可见。若无法获取,再通过堆数组抓取的方式来检查。因此更新表的可视化映射,可加速唯一索引扫描。
- VACUUM可避免执行的事务数超过数据库阈值时,事务ID重叠造成的原有数据丢失。
- ANALYZE可收集与数据库中表内容相关的统计信息。统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据,生成最有效的执行计划。
操作步骤
使用VACUUM或VACUUM FULL命令,进行磁盘空间回收。
VACUUM:
对表执行VACUUM操作
openGauss=# VACUUM customer;
VACUUM
可以与数据库操作命令并行运行。(执行期间,可正常使用的语句:SELECT、INSERT、UPDATE和DELETE。不可正常使用的语句:ALTER TABLE)。
对表分区执行VACUUM操作
openGauss=# VACUUM customer_par PARTITION ( P1 );
VACUUM
VACUUM FULL:
openGauss=# VACUUM FULL customer;
VACUUM
需要向正在执行的表增加排他锁,且需要停止其他所有数据库操作。
使用ANALYZE语句更新统计信息。
openGauss=# ANALYZE customer;
ANALYZE
使用ANALYZE VERBOSE语句更新统计信息,并输出表的相关信息。
openGauss=# ANALYZE VERBOSE customer;
ANALYZE
也可以同时执行VACUUM ANALYZE命令进行查询优化。
openGauss=# VACUUM ANALYZE customer;
VACUUM
说明: VACUUM和ANALYZE会导致I/O流量的大幅增加,这可能会影响其他活动会话的性能。因此,建议通过“vacuum_cost_delay”参数设置《数据库参考》中“GUC参数说明 > 资源消耗 > 基于开销的清理延迟”。
删除表。
openGauss=# DROP TABLE customer; openGauss=# DROP TABLE customer_par; openGauss=# DROP TABLE part;
当结果显示为如下信息,则表示删除成功。
DROP TABLE
维护建议
- 定期对部分大表做VACUUM FULL,在性能下降后为全库做VACUUM FULL,目前暂定每月做一次VACUUM FULL。
- 定期对系统表做VACUUM FULL,主要是PG_ATTRIBUTE。
- 启用系统自动清理线程(AUTOVACUUM)自动执行VACUUM和ANALYZE,回收被标识为删除状态的记录空间,并更新表的统计数据。
例行重建索引
背景信息
数据库经过多次删除操作后,索引页面上的索引键将被删除,造成索引膨胀。例行重建索引,可有效的提高查询效率。
数据库支持的索引类型为B-tree索引,例行重建索引可有效的提高查询效率。
- 如果数据发生大量删除后,索引页面上的索引键将被删除,但索引页面并不会直接删除,即索引页面数量并不会减少,因此会造成索引膨胀。重建索引可回收浪费的空间。
- 新建的索引中逻辑结构相邻的页面,通常在物理结构中也是相邻的,所以一个新建的索引比更新了多次的索引访问速度要快。
重建索引
重建索引有以下两种方式:
先运行DROP INDEX语句删除索引,再运行CREATE INDEX语句创建索引。
在删除索引过程中,会在父表上增加一个短暂的排他锁,阻止相关读写操作。在创建索引过程中,会锁住写操作但是不会锁住读操作,此时读操作只能使用顺序扫描。
使用REINDEX语句重建索引。
- 使用REINDEX TABLE语句重建索引,会在重建过程中增加排他锁,阻止相关读写操作。
- 使用REINDEX INTERNAL TABLE语句重建desc表(包括列存表的cudesc表)的索引,会在重建过程中增加排他锁,阻止相关读写操作。
操作步骤
假定在导入表“areaS”上的“area_id”字段上存在普通索引“areaS_idx”。重建索引有以下两种方式:
先删除索引(DROP INDEX),再创建索引(CREATE INDEX)。
删除索引。
openGauss=# DROP INDEX areaS_idx;
当结果显示如下信息,则表示删除成功。
DROP INDEX
创建索引。
openGauss=# CREATE INDEX areaS_idx ON areaS (area_id);
当结果显示如下信息,则表示创建成功。
CREATE INDEX
使用REINDEX重建索引。
使用REINDEX TABLE语句重建索引。
openGauss=# REINDEX TABLE areaS;
当结果显示如下信息,则表示重建成功。
REINDEX
使用REINDEX INTERNAL TABLE重建desc表(包括列存表的cudesc表)的索引。
openGauss=# REINDEX INTERNAL TABLE areaS;
当结果显示如下信息,则表示重建成功。
REINDEX
说明: 在重建索引前,用户可以通过临时增大maintenance_work_mem和psort_work_mem的取值来加快索引的重建。
导出并查看wdr诊断报告
生成快照数据需参数enable_wdr_snapshot=on,访问WDR快照数据需要sysadmin或monadmin权限,因此需要使用root账号或其他拥有权限的账号来生成WDR诊断报告。
执行如下命令新建报告文件。
touch /home/om/wdrTestNode.html
连接系统库postgres。
gsql -d postgres -p 端口号 -r
选择snapshot.snapshot表中两个不同的snapshot,当这两个snapshot之间未发生服务重启,便可以使用这两个snapshot生成报告。
openGauss=# select * from snapshot.snapshot order by start_ts desc limit 10;
执行如下命令,在本地生成HTML格式的WDR报告。
执行如下命令,设置报告格式。\a: 不显示表行列符号, \t: 不显示列名 ,\o: 指定输出文件。
openGauss=# \a \t \o {报告路径}
示例:
openGauss=# \a \t \o /home/omm/wdrTestNode.html
执行如下命令,生成HTML格式的WDR报告。
openGauss=# select generate_wdr_report(begin_snap_id Oid, end_snap_id Oid, int report_type, int report_scope, int node_name );
示例一,生成集群级别的报告:
openGauss=# select generate_wdr_report(1, 2, 'all', 'cluster',null);
示例二,生成某个节点的报告:
openGauss=# select generate_wdr_report(1, 2, 'all', 'node', pgxc_node_str()::cstring);
说明:
- 当前openGauss的节点名固定是“dn_6001”,也可直接代入。
表 1 参数说明
执行如下命令关闭输出选项及格式化输出命令。
\o \a \t
在/home/om/下根据需要查看WDR报告内容。
表 2 WDR报表主要内容
数据安全维护建议
为保证openGauss数据库中的数据安全,避免丢失数据、非法访问数据等事故发生,请仔细阅读以下内容。
避免数据被丢失
建议用户规划周期性的物理备份,且对备份文件进行可靠的保存。在系统发生严重错误的情况下,可以利用备份文件,将系统恢复到备份前的状态。
避免数据被非法访问
- 建议对数据库用户进行权限分级管理。数据库管理员根据业务需要,建立用户并赋予权限,保证各用户对数据库的合理访问。
- 对于openGauss的服务端和客户端(或基于客户端库开发的应用程序),最好也部署在可信任的内网中。如果服务端和客户端一定要部署在非信任的网络中,需要在服务启动前,打开SSL加密,保证数据在非信任网络上的传输安全。需要注意的是,打开SSL加密会降低数据库的性能。
避免系统日志泄露个人数据
将调试日志发给他人进行分析前,请删除个人数据。
说明: 因为日志级别(log_min_messages)设置为DEBUGx(x为DEBUG级别,取值范围为1~5)时,调试日志中记录的信息可能包含用户的个人数据。
将系统日志发给其他人进行分析前,请删除个人数据。因为在默认配置下,当SQL语句执行错误时,日志中会记录出错的SQL语句,而这些SQL语句中可能包含用户个人数据。
将log_min_error_statement参数的值设置为PANIC,可以避免将出错的SQL语句记录在系统日志中。若禁用该功能,当出现故障时,很难定位故障原因。
慢sql诊断
背景信息
在SQL语句执行性能不符合预期时,可以查看SQL语句执行信息,便于事后分析SQL语句执行时的行为,从而诊断SQL语句执行出现的相关问题。
前提条件
- 数据库实例运行正常。
- 查询SQL语句信息,需要合理设置GUC参数track_stmt_stat_level。track_stmt_stat_level参数控制语句执行跟踪的级别,第一部分控制全量SQL,第二部分控制慢SQL。对于慢SQL,当track_stmt_stat_level的值为非OFF时,且SQL执行时间超过log_min_duration_statement,会记录为慢SQL。默认值为"OFF,L0",建议设置为"L0,L0"。
- 只能用系统管理员和监控管理员权限进行操作。
执行命令查看数据库实例中SQL语句执行信息
select * from dbe_perf.get_global_full_sql_by_timestamp(start_timestamp, end_timestamp);
例如:
select * from DBE_PERF.get_global_full_sql_by_timestamp('2020-12-01 09:25:22', '2020-12-31 23:54:41');
-[ RECORD 1 ]--------+---------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------
node_name | dn_6001_6002_6003
db_name | postgres
schema_name | "$user",public
origin_node | 1938253334
user_name | user_dj
application_name | gsql
client_addr |
client_port | -1
unique_query_id | 3671179229
debug_query_id | 72339069014839210
query | select name, setting from pg_settings where name in (?)
start_time | 2020-12-19 16:19:51.216818+08
finish_time | 2020-12-19 16:19:51.224513+08
slow_sql_threshold | 1800000000
transaction_id | 0
thread_id | 139884662093568
session_id | 139884662093568
n_soft_parse | 0
n_hard_parse | 1
query_plan | Datanode Name: dn_6001_6002_6003
| Function Scan on pg_show_all_settings a (cost=0.00..12.50 rows=5 width=64)
| Filter: (name = '***'::text)
...
执行命令查看数据库实例中慢SQL语句执行信息
select * from dbe_perf.get_global_slow_sql_by_timestamp(start_timestamp, end_timestamp);
例如:
select * from DBE_PERF.get_global_slow_sql_by_timestamp('2020-12-01 09:25:22', '2020-12-31 23:54:41');
-[ RECORD 1 ]--------+---------------------------------------------------------------------------------------------------
node_name | dn_6001_6002_6003
db_name | postgres
schema_name | "$user",public
origin_node | 1938253334
user_name | user_dj
application_name | gsql
client_addr |
client_port | -1
unique_query_id | 2165004317
debug_query_id | 72339069014839319
query | select * from DBE_PERF.get_global_slow_sql_by_timestamp(?, ?);
start_time | 2020-12-19 16:23:20.738491+08
finish_time | 2020-12-19 16:23:20.773714+08
slow_sql_threshold | 10000
transaction_id | 0
thread_id | 139884662093568
session_id | 139884662093568
n_soft_parse | 10
n_hard_parse | 8
query_plan | Datanode Name: dn_6001_6002_6003
| Result (cost=1.01..1.02 rows=1 width=0)
| InitPlan 1 (returns $0)
| -> Seq Scan on pgxc_node (cost=0.00..1.01 rows=1 width=64)
| Filter: (nodeis_active AND ((node_type = '***'::"char") OR (node_type = '***'::"char")))
...
查看当前主节点SQL语句执行信息
select * from statement_history;
例如:
select * from statement_history;
-[ RECORD 1 ]--------+---------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------
db_name | postgres
schema_name | "$user",public
origin_node | 1938253334
user_name | user_dj
application_name | gsql
client_addr |
client_port | -1
unique_query_id | 3671179229
debug_query_id | 72339069014839210
query | select name, setting from pg_settings where name in (?)
start_time | 2020-12-19 16:19:51.216818+08
finish_time | 2020-12-19 16:19:51.224513+08
slow_sql_threshold | 1800000000
transaction_id | 0
thread_id | 139884662093568
session_id | 139884662093568
n_soft_parse | 0
n_hard_parse | 1
query_plan | Datanode Name: dn_6001_6002_6003
| Function Scan on pg_show_all_settings a (cost=0.00..12.50 rows=5 width=64)
| Filter: (name = '***'::text)
...
查看当前备节点SQL语句执行信息
select * from dbe_perf.standby_statement_history(is_only_slow, start_timestamp, end_timestamp);
例如:
select * from dbe_perf.standby_statement_history(true, '2022-08-01 09:25:22', '2022-08-31 23:54:41');
db_name | postgres
schema_name | "$user",public
origin_node | 0
user_name | user_dj
application_name | gsql
client_addr |
client_port | -1
unique_query_id | 1660376009
debug_query_id | 281474976710740
query | select name, setting from pg_settings where name in (?)
start_time | 2022-08-19 16:19:51.216818+08
finish_time | 2022-08-19 16:19:51.224513+08
slow_sql_threshold | 1800000000
transaction_id | 0
thread_id | 140058747205376
session_id | 140058747205376
n_soft_parse | 0
n_hard_parse | 1
query_plan | Datanode Name: sgnode
| Function Scan on pg_show_all_settings a (cost=0.00..12.50 rows=5 width=64)
| Filter: (name = '***'::text)
...