例行维护
为保证openGauss数据库中的数据安全,避免丢失数据和非法访问数据等事故发生,请仔细阅读以下内容。
日维护检查项
检查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正常通过预安装,并且在安装成功后可以安全高效的运行。详细的检查项目请参见《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。
取值范围为所有支持的检查项名称,详细列表请参见《openGauss 工具参考》中“服务端工具 > 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满足操作所需的环境条件和状态条件。详细的巡检项目和场景请参见《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
复制
具体的性能统计项目请参见《openGauss 工具参考》中“服务端工具 > 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诊断报告
访问WDR快照数据需要sysadmin或monadmin权限,因此需要使用root账号或其他拥有权限的账号来生成WDR诊断报告。
执行如下命令新建报告文件。
复制代码
touch /home/om/wdrTestNode.html
复制连接系统库postgres。
复制代码
gsql -d postgres -p 端口号 -r
复制选择snapshot.snapshot表中两个不同的snapshot,当这两个snapshot之间未发生服务重启,便可以使用这两个snapshot生成报告。
复制代码
gsql> select * from snapshot.snapshot order by start_ts desc limit 10;
复制执行如下命令,在本地生成HTML格式的WDR报告。
执行如下命令,设置报告格式。\a: 不显示表行列符号, \t: 不显示列名 ,\o: 指定输出文件。
复制代码
gsql> \a gsql> \t gsql> \o {报告路径}
复制执行如下命令,生成HTML格式的WDR报告。
复制代码
gsql> 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', 'cluster',null);
复制示例二,生成某个节点的报告:
复制代码
select generate_wdr_report(1, 2, 'all', 'node', pgxc_node_str()::cstring);
复制说明: 当前openGauss的节点名固定是“dn_6001_6002_6003”,也可直接代入。
表 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。
只能用系统管理员和监控管理员权限进行操作。
复制代码
执行命令查看数据库实例中SQL语句执行信息 gsql> select * from dbe_perf.get_global_full_sql_by_timestamp(start_timestamp, end_timestamp); 执行命令查看数据库实例中慢SQL语句执行信息 gsql> select * from dbe_perf.get_global_slow_sql_by_timestamp(start_timestamp, end_timestamp); 查看当前节点SQL语句执行信息 gsql> select * from statement_history;
复制
文章被以下合辑收录
评论

