例行维护

日维护检查项

检查openGauss状态

通过openGauss提供的工具查询数据库和实例状态，确认数据库和实例都处于正常的运行状态，可以对外提供数据服务。

  • 检查实例状态

    1. gs_check -U omm -i CheckClusterState

  • 检查参数

    1. openGauss=# SHOW parameter_name;

    上述命令中，parameter_name需替换成具体的参数名称。

  • 修改参数

    1. gs_guc reload  -D /gaussdb/data/dbnode -c "paraname=value"

检查锁信息

锁机制是数据库保证数据一致性的重要手段，检查相关信息可以检查数据库的事务和运行状况。

  • 查询数据库中的锁信息

    1. openGauss=# SELECT * FROM pg_locks;

  • 查询等待锁的线程状态信息

    1. openGauss=# SELECT * FROM pg_thread_wait_status WHERE wait_status = 'acquire lock';

  • 结束系统进程

    查找正在运行的系统进程，然后使用kill命令结束此进程。

    1. ps ux
    2. kill -9 pid

统计事件数据

SQL语句长时间运行会占用大量系统资源，用户可以通过查看事件发生的时间，占用内存大小来了解现在数据库运行状态。

  • 查询事件的时间

    查询事件的线程启动时间、事务启动时间、SQL启动时间以及状态变更时间。

    1. openGauss=# SELECT backend_start,xact_start,query_start,state_change FROM pg_stat_activity;

  • 查询当前服务器的会话计数信息

    1. openGauss=# SELECT count(*) FROM pg_stat_activity;

  • 查询系统级统计信息

    查询当前使用内存最多的会话信息。

    1. openGauss=# SELECT * FROM pv_session_memory_detail() ORDER BY usedsize desc limit 10;

对象检查

表、索引、分区、约束等是数据库的核心存储对象，其核心信息和对象维护是DBA重要的日常工作。

  • 查看表的详细信息

    1. openGauss=# \d+ table_name

  • 查询表统计信息

    1. openGauss=# SELECT * FROM pg_statistic;

  • 查看索引的详细信息

    1. openGauss=# \d+ index_name

  • 查询分区表信息

    1. openGauss=# SELECT * FROM pg_partition;

  • 收集统计信息

    使用ANALYZE语句收集数据库相关的统计信息。

    使用VACUUM语句可以回收空间并更新统计信息。

  • 查询约束信息

    1. openGauss=# SELECT * FROM pg_constraint;

SQL报告检查

使用EXPLAIN语句查看执行计划。

备份

数据备份重于一切，日常应检查备份执行情况，并检查备份有效性，确保备份能够保障数据安全，备份安全加密也应兼顾。

  • 指定用户导出数据库

    1. gs_dump dbname -p port -f out.sql -U user_name -W password

  • 导出schema

    1. gs_dump dbname -p port -n schema_name -f out.sql

  • 导出table

    1. gs_dump dbname -p port -t table_name -f out.sql

基本信息检查

基本信息包括版本、组件、补丁集等信息，定期检查数据库信息并登记在案是数据库生命周期管理的重要内容之一。

  • 版本信息

    1. openGauss=# SELECT version();

  • 容量检查

    1. openGauss=# SELECT pg_table_size('table_name');
    2. openGauss=# SELECT pg_database_size('database_name');

检查操作系统参数

检查办法

通过openGauss提供的gs_checkos工具可以完成操作系统状态检查。

前提条件

  • 当前的硬件和网络环境正常。
  • 各主机间root互信状态正常。
  • 只能使用root用户执行gs_checkos命令。

操作步骤

  1. 以root用户身份登录任意一台服务器。

  2. 执行如下命令对openGauss节点服务器的OS参数进行检查。

    1. gs_checkos -i A

    检查节点服务器的OS参数的目的是保证openGauss正常通过预安装，并且在安装成功后可以安全高效的运行。详细的检查项目请参见《openGauss 工具参考》中“服务端工具 > gs_checkos”章节。

示例

执行gs_checkos前需要先使用gs_preinstall工具执行前置脚本，准备环境。以参数“A”为例。

  1. gs_checkos -i A
  2. Checking items:
  3.     A1. [ OS version status ]                                   : Normal
  4.     A2. [ Kernel version status ]                               : Normal
  5.     A3. [ Unicode status ]                                      : Normal
  6.     A4. [ Time zone status ]                                    : Normal
  7.     A5. [ Swap memory status ]                                  : Normal
  8.     A6. [ System control parameters status ]                    : Normal
  9.     A7. [ File system configuration status ]                    : Normal
  10.     A8. [ Disk configuration status ]                           : Normal
  11.     A9. [ Pre-read block size status ]                          : Normal
  12.     A10.[ IO scheduler status ]                                 : Normal
  13.     A11.[ Network card configuration status ]                   : Normal
  14.     A12.[ Time consistency status ]                             : Warning
  15.     A13.[ Firewall service status ]                             : Normal
  16.     A14.[ THP service status ]                                  : Normal
  17. Total numbers:14. Abnormal numbers:0. Warning number:1.

以参数“B”为例。

  1. gs_checkos -i B
  2. Setting items:
  3.     B1. [ Set system control parameters ]                       : Normal
  4.     B2. [ Set file system configuration value ]                 : Normal
  5.     B3. [ Set pre-read block size value ]                       : Normal
  6.     B4. [ Set IO scheduler value ]                              : Normal
  7.     B5. [ Set network card configuration value ]                : Normal
  8.     B6. [ Set THP service ]                                     : Normal
  9.     B7. [ Set RemoveIPC value ]                                 : Normal
  10.     B8. [ Set Session Process ]                                 : Normal
  11. Total numbers:6. Abnormal numbers:0. Warning number:0.

异常处理

使用gs_checkos检查openGauss状态，可以使用如下命令查看详细的错误信息。

  1. gs_checkos -i A --detail

其中，Abnormal为必须处理项，影响openGauss安装。Warning可以不处理，不会影响openGauss安装。

  • 如果操作系统版本（A1）检查项检查结果为Abnormal，需要将不属于混编范围的操作系统版本替换为混编范围内的操作系统版本。

  • 如果内核版本（A2）检查项检查结果为Warning，则表示openGauss集群内操作系统平台的内核版本不一致。

  • 如果Unicode状态（A3）检查项检查结果为Abnormal，需要将各主机的字符集设置为相同的字符集，可以在/etc/profile文件中添加“export LANG=XXX”（XXX为Unicode编码）。

    1. vim /etc/profile

  • 如果时区状态（A4）检查项检查结果为Abnormal，需要将各主机的时区设置为相同时区，可以将/usr/share/zoneinfo/目录下的时区文件拷贝为/etc/localtime文件。

    1. cp /usr/share/zoneinfo/$主时区/$次时区 /etc/localtime

  • 如果交换内存状态（A5）检查项检查结果为Abnormal，可能是因为Swap空间大于Mem空间，可减小Swap解决或者增大Mem空间解决。

  • 如果系统控制参数（A6）检查项检查结果为Abnormal，可以使用以下两种方法进行设置。

    • 可以使用如下命令进行设置。

      1. gs_checkos -i B1

    • 根据错误提示信息，在/etc/sysctl.conf文件中进行设置。然后执行sysctl -p使其生效。

      1. vim /etc/sysctl.conf

  • 如果文件系统配置状态（A7）检查项检查结果为Abnormal，可以使用如下命令进行设置。

    1. gs_checkos -i B2

  • 如果磁盘配置状态（A8）检查项检查结果为Abnormal，需修改磁盘挂载格式为：“rw,noatime,inode64,allocsize=16m”。

    使用linux的man mount命令挂载XFS选项：

    1. rw,noatime,inode64,allocsize=16m

    也可以在/etc/fstab文件中设定XFS选项。如下示例：

    1. /dev/data /data xfs rw,noatime,inode64,allocsize=16m 0 0

  • 如果预读块大小（A9）检查项检查结果为Abnormal，可以使用如下命令进行设置。

    1. gs_checkos -i B3

  • 如果IO调度状态（A10）检查项检查结果为Abnormal，可以使用如下命令进行设置。

    1. gs_checkos -i B4

  • 如果网卡配置状态（A11）检查项检查结果为Warning，可以使用如下命令进行设置。

    1. gs_checkos -i B5

  • 如果时间一致性（A12）检查项检查结果为Abnormal，需检查是否安装ntp服务，以及ntp服务是否启动；并与ntp时钟源同步。

  • 如果防火墙状态（A13）检查项检查结果为Abnormal，需关闭防火墙服务。使用如下命令进行设置。

    • SuSE：

      1. SuSEfirewall2 stop

    • RedHat7：

      1. systemctl disable firewalld
      2. systemctl stop firewalld

    • RedHat6：

      1. service iptables stop

  • 如果THP服务（A14）检查项检查结果为Abnormal，可以使用如下命令进行设置。

    1. 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：

  1. 以操作系统用户omm登录数据库主节点。

  2. 执行如下命令对openGauss数据库状态进行检查。

    1. gs_check -i CheckClusterState

    其中，-i指定检查项，注意区分大小写。格式：-i CheckClusterState、-i CheckCPU或-i CheckClusterState，CheckCPU。

    取值范围为所有支持的检查项名称，详细列表请参见《openGauss 工具参考》中“服务端工具 > gs_checkos > openGauss状态检查表”，用户可以根据需求自己编写新检查项。

方式2：

  1. 以操作系统用户omm登录数据库主节点。

  2. 执行如下命令对openGauss数据库进行健康检查。

    1. 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状态检查表”。

示例

执行单项检查结果：

  1. perfadm@lfgp000700749:/opt/huawei/perfadm/tool/script> gs_check -i CheckCPU
  2. Parsing the check items config file successfully
  3. Distribute the context file to remote hosts successfully
  4. Start to health check for the cluster. Total Items:1 Nodes:3
  6. Checking...               [=========================] 1/1
  7. Start to analysis the check result
  8. CheckCPU....................................OK
  9. The item run on 3 nodes.  success: 3
  11. Analysis the check result successfully
  12. Success. All check items run completed. Total:1  Success:1  Failed:0
  13. For more information please refer to /opt/huawei/wisequery/script/gspylib/inspection/output/CheckReport_201902193704661604.tar.gz

本地执行结果：

  1. perfadm@lfgp000700749:/opt/huawei/perfadm/tool/script> gs_check -i CheckCPU -L
  3. 2017-12-29 17:09:29 [NAM] CheckCPU
  4. 2017-12-29 17:09:29 [STD] 检查主机CPU占用率，如果idle 大于30%并且iowait 小于 30%.则检查项通过，否则检查项不通过
  5. 2017-12-29 17:09:29 [RST] OK
  7. 2017-12-29 17:09:29 [RAW]
  8. Linux 4.4.21-69-default (lfgp000700749)  12/29/17  _x86_64_
  10. 17:09:24        CPU     %user     %nice   %system   %iowait    %steal     %idle
  11. 17:09:25        all      0.25      0.00      0.25      0.00      0.00     99.50
  12. 17:09:26        all      0.25      0.00      0.13      0.00      0.00     99.62
  13. 17:09:27        all      0.25      0.00      0.25      0.13      0.00     99.37
  14. 17:09:28        all      0.38      0.00      0.25      0.00      0.13     99.25
  15. 17:09:29        all      1.00      0.00      0.88      0.00      0.00     98.12
  16. Average:        all      0.43      0.00      0.35      0.03      0.03     99.17

执行场景检查结果：

  1. [perfadm@SIA1000131072 Check]$ gs_check -e inspect
  2. Parsing the check items config file successfully
  3. The below items require root privileges to execute:[CheckBlockdev CheckIOrequestqueue CheckIOConfigure CheckCheckMultiQueue CheckFirewall CheckSshdService CheckSshdConfig CheckCrondService CheckBootItems CheckFilehandle CheckNICModel CheckDropCache]
  4. Please enter root privileges user[root]:root
  5. Please enter password for user[root]:
  6. Please enter password for user[root] on the node[10.244.57.240]:
  7. Check root password connection successfully
  8. Distribute the context file to remote hosts successfully
  9. Start to health check for the cluster. Total Items:57 Nodes:2
  11. Checking...               [                         ] 21/57
  12. Checking...               [=========================] 57/57
  13. Start to analysis the check result
  14. CheckClusterState...........................OK
  15. The item run on 2 nodes.  success: 2
  17. CheckDBParams...............................OK
  18. The item run on 1 nodes.  success: 1
  20. CheckDebugSwitch............................OK
  21. The item run on 2 nodes.  success: 2
  23. CheckDirPermissions.........................OK
  24. The item run on 2 nodes.  success: 2
  26. CheckReadonlyMode...........................OK
  27. The item run on 1 nodes.  success: 1
  29. CheckEnvProfile.............................OK
  30. The item run on 2 nodes.  success: 2  (consistent)
  31. The success on all nodes value:
  32. GAUSSHOME        /usr1/gaussdb/app
  33. LD_LIBRARY_PATH  /usr1/gaussdb/app/lib
  34. PATH             /usr1/gaussdb/app/bin
  37. CheckBlockdev...............................OK
  38. The item run on 2 nodes.  success: 2
  40. CheckCurConnCount...........................OK
  41. The item run on 1 nodes.  success: 1
  43. CheckCursorNum..............................OK
  44. The item run on 1 nodes.  success: 1
  46. CheckPgxcgroup..............................OK
  47. The item run on 1 nodes.  success: 1
  49. CheckDiskFormat.............................OK
  50. The item run on 2 nodes.  success: 2
  52. CheckSpaceUsage.............................OK
  53. The item run on 2 nodes.  success: 2
  55. CheckInodeUsage.............................OK
  56. The item run on 2 nodes.  success: 2
  58. CheckSwapMemory.............................OK
  59. The item run on 2 nodes.  success: 2
  61. CheckLogicalBlock...........................OK
  62. The item run on 2 nodes.  success: 2
  64. CheckIOrequestqueue.....................WARNING
  65. The item run on 2 nodes.  warning: 2
  66. The warning[host240,host157] value:
  67. On device (vdb) 'IO Request' RealValue '256' ExpectedValue '32768'
  68. On device (vda) 'IO Request' RealValue '256' ExpectedValue '32768'
  70. CheckMaxAsyIOrequests.......................OK
  71. The item run on 2 nodes.  success: 2
  73. CheckIOConfigure............................OK
  74. The item run on 2 nodes.  success: 2
  76. CheckMTU....................................OK
  77. The item run on 2 nodes.  success: 2  (consistent)
  78. The success on all nodes value:
  79. 1500
  81. CheckPing...................................OK
  82. The item run on 2 nodes.  success: 2
  84. CheckRXTX...................................NG
  85. The item run on 2 nodes.  ng: 2
  86. The ng[host240,host157] value:
  87. NetWork[eth0]
  88. RX: 256
  89. TX: 256
  92. CheckNetWorkDrop............................OK
  93. The item run on 2 nodes.  success: 2
  95. CheckMultiQueue.............................OK
  96. The item run on 2 nodes.  success: 2
  98. CheckEncoding...............................OK
  99. The item run on 2 nodes.  success: 2  (consistent)
  100. The success on all nodes value:
  101. LANG=en_US.UTF-8
  103. CheckFirewall...............................OK
  104. The item run on 2 nodes.  success: 2
  106. CheckKernelVer..............................OK
  107. The item run on 2 nodes.  success: 2  (consistent)
  108. The success on all nodes value:
  109. 3.10.0-957.el7.x86_64 
  111. CheckMaxHandle..............................OK
  112. The item run on 2 nodes.  success: 2
  114. CheckNTPD...................................OK
  115. host240: NTPD service is running, 2020-06-02 17:00:28
  116. host157: NTPD service is running, 2020-06-02 17:00:06
  119. CheckOSVer..................................OK
  120. host240: The current OS is centos 7.6 64bit.
  121. host157: The current OS is centos 7.6 64bit.
  124. CheckSysParams..........................WARNING
  125. The item run on 2 nodes.  warning: 2
  126. The warning[host240,host157] value:
  127. Warning reason: variable 'net.ipv4.tcp_retries1' RealValue '3' ExpectedValue '5'.
  128. Warning reason: variable 'net.ipv4.tcp_syn_retries' RealValue '6' ExpectedValue '5'.
  131. CheckTHP....................................OK
  132. The item run on 2 nodes.  success: 2
  134. CheckTimeZone...............................OK
  135. The item run on 2 nodes.  success: 2  (consistent)
  136. The success on all nodes value:
  137. +0800
  139. CheckCPU....................................OK
  140. The item run on 2 nodes.  success: 2
  142. CheckSshdService............................OK
  143. The item run on 2 nodes.  success: 2
  145. Warning reason: UseDNS parameter is not set; expected: no
  147. CheckCrondService...........................OK
  148. The item run on 2 nodes.  success: 2
  150. CheckStack..................................OK
  151. The item run on 2 nodes.  success: 2  (consistent)
  152. The success on all nodes value:
  153. 8192
  155. CheckSysPortRange...........................OK
  156. The item run on 2 nodes.  success: 2
  158. CheckMemInfo................................OK
  159. The item run on 2 nodes.  success: 2  (consistent)
  160. The success on all nodes value:
  161. totalMem: 31.260929107666016G
  163. CheckHyperThread............................OK
  164. The item run on 2 nodes.  success: 2
  166. CheckTableSpace.............................OK
  167. The item run on 1 nodes.  success: 1
  170. CheckSysadminUser...........................OK
  171. The item run on 1 nodes.  success: 1
  174. CheckGUCConsistent..........................OK
  175. All DN instance guc value is consistent.
  177. CheckMaxProcMemory..........................OK
  178. The item run on 1 nodes.  success: 1
  180. CheckBootItems..............................OK
  181. The item run on 2 nodes.  success: 2
  183. CheckHashIndex..............................OK
  184. The item run on 1 nodes.  success: 1
  186. CheckPgxcRedistb............................OK
  187. The item run on 1 nodes.  success: 1
  189. CheckNodeGroupName..........................OK
  190. The item run on 1 nodes.  success: 1
  192. CheckTDDate.................................OK
  193. The item run on 1 nodes.  success: 1
  195. CheckDilateSysTab...........................OK
  196. The item run on 1 nodes.  success: 1
  198. CheckKeyProAdj..............................OK
  199. The item run on 2 nodes.  success: 2
  201. CheckProStartTime.......................WARNING
  202. host157:
  203. STARTED COMMAND
  204. Tue Jun  2 16:57:18 2020 /usr1/dmuser/dmserver/metricdb1/server/bin/gaussdb --single_node -D /usr1/dmuser/dmb1/data -p 22204
  205. Mon Jun  1 16:15:15 2020 /usr1/gaussdb/app/bin/gaussdb -D /usr1/gaussdb/data/dn1 -M standby
  208. CheckFilehandle.............................OK
  209. The item run on 2 nodes.  success: 2
  211. CheckRouting................................OK
  212. The item run on 2 nodes.  success: 2
  214. CheckNICModel...............................OK
  215. The item run on 2 nodes.  success: 2  (consistent)
  216. The success on all nodes value:
  217. version: 1.0.1
  218. model: Red Hat, Inc. Virtio network device
  221. CheckDropCache..........................WARNING
  222. The item run on 2 nodes.  warning: 2
  223. The warning[host240,host157] value:
  224. No DropCache process is running
  226. CheckMpprcFile..............................NG
  227. The item run on 2 nodes.  ng: 2
  228. The ng[host240,host157] value:
  229. There is no mpprc file
  231. Analysis the check result successfully
  232. Failed. All check items run completed. Total:57   Success:50   Warning:5   NG:2
  233. For more information please refer to /usr1/gaussdb/tool/script/gspylib/inspection/output/CheckReport_inspect611.tar.gz

异常处理

如果发现检查结果异常，可以根据以下内容进行修复。

表 1 检查openGauss运行状态

检查项

异常状态

处理方法

CheckClusterState（检查openGauss状态）

openGauss未启动或openGauss实例未启动

使用以下命令启动openGauss及实例。

  1. gs_om -t start

openGauss状态异常或openGauss实例异常

检查各主机、实例状态，根据状态信息进行排查。

  1. gs_check -i CheckClusterState

CheckDBParams（检查数据库参数）

数据库参数错误

通过gs_guc工具修改数据库参数为指定值。

CheckDebugSwitch（检查调试日志）

日志级别不正确

使用gs_guc工具将log_min_messages改为指定内容。

CheckDirPermissions（检查目录权限）

路径权限错误

修改对应目录权限为指定数值（750/700）。

  1. chmod 750 DIR

CheckReadonlyMode（检查只读模式）

只读模式被打开

确认数据库节点所在磁盘使用率未超阈值（默认85%）且未在执行其他运维操作。

  1. gs_check -i CheckDataDiskUsage
  2. ps ux

使用gs_guc工具关闭openGauss只读模式。

  1. gs_guc reload -N all -I all -c ‘default_transaction_read_only = off’

CheckEnvProfile（检查环境变量）

环境变量不一致

重新执行前置更新环境变量信息。

CheckBlockdev（检查磁盘预读块）

磁盘预读块大小不为16384

使用gs_checkos设置预读块大小为16384KB，并写入自启动文件。

  1. gs_checkos -i B3

CheckCursorNum（检查游标数）

检查游标数失败

检查数据库能否正常连接，openGauss状态是否正常。

CheckPgxcgroup（检查重分布状态）

有未完成重分布的pgxc_group表

继续完成扩容或缩容的数据重分布操作。

  1. gs_expand、gs_shrink

CheckDiskFormat（检查磁盘配置）

各节点磁盘配置不一致

将各节点的磁盘规格改为相同。

CheckSpaceUsage（检查磁盘空间使用率）

磁盘可用空间不足

清理或扩展对应目录所在的磁盘。

CheckInodeUsage（检查磁盘索引使用率）

磁盘可用索引不足

清理或扩展对应目录所在的磁盘。

CheckSwapMemory（检查交换内存）

交换内存大于物理内存

将交换内存调小或关闭。

CheckLogicalBlock（检查磁盘逻辑块）

磁盘逻辑块大小不为512

使用gs_checkos修改磁盘逻辑块大小为512KB，并写入开机自启动文件。

  1. gs_checkos -i B4

CheckIOrequestqueue（检查IO请求）

IO请求值不为32768

使用gs_checkos设置IO请求值为32768，并写入开机自启动文件。

  1. gs_checkos -i B4

CheckCurConnCount（检查当前连接数）111

当前连接数超过最大连接数的90%

断开未使用的数据库主节点连接。

CheckMaxAsyIOrequests（检查最大异步请求）

最大异步请求值小于104857600或当前节点数据库实例数乘以1048576

使用gs_checkos设置最大异步请求值为104857600和当前节点数据库实例数乘以1048576中的最大值。

  1. gs_checkos -i B4

CheckMTU（检查MTU值）

MTU值不一致

设置各节点的MTU一致为1500或8192。

  1. ifconfig eth* MTU 1500

CheckIOConfigure（检查IO配置）

IO配置不是deadline

使用gs_checkos设置IO配置为deadline，并写入开机自启动文件。

  1. gs_checkos -i B4

CheckRXTX（检查RXTX值）

网卡RX/TX值不是4096

使用checkos设置openGauss使用的物理网卡RX/TX值为4096。

  1. gs_checkos -i B5

CheckPing（检查网络通畅）

存在openGauss IP无法ping通

检查异常ip间网络设置和状态、防火墙状态。

CheckNetWorkDrop（检查网络丢包率）

网络通信丢包率高于1%

检查对应IP间网络负载、状态。

CheckMultiQueue（检查网卡多队列）

未开启网卡多队列并未将网卡中断绑定到不同CPU核心

开启网卡多队列并将网卡队列中断绑定到不同的CPU核心。

CheckEncoding（检查编码格式）

各节点编码格式不一致

在/etc/profile中写入一致的编码信息。

  1. echo “export LANG=XXX” >> /etc/profile

CheckFirewall（检查防火墙）

防火墙未关闭

关闭防火墙服务。

  1. systemctl disable firewalld.service
  2. systemctl stop firewalld.service

CheckMaxHandle（检查最大文件句柄数）

最大文件句柄数小于1000000

设置91-nofile.conf/90-nofile.conf最大文件句柄数软硬限制为1000000。

  1. gs_checkos -i B2

CheckNTPD（检查时间同步服务）

NTPD服务未开启或时间误差超过一分钟

开启NTPD服务并设置时钟一致。

CheckSysParams（检查操作系统参数）

操作系统参数设置不满足要求

使用gs_checkos进行参数设置或手动设置。

  1. gs_checkos -i B1
  2. vim /etc/sysctl.conf

CheckTHP（检查THP服务）

THP服务未开启

使用gs_checkos设置THP服务。

  1. gs_checkos -i B6

CheckTimeZone（检查时区）

时区不一致

设置各节点为同一时区。

  1. cp /usr/share/zoneinfo/$主时区/$次时区 /etc/localtime

CheckCPU（检查CPU）

CPU占用过高或IO等待过高

进行CPU配置升级或磁盘性能升级。

CheckSshdService（检查SSHD服务）

未开启SSHD服务

启动SSHD服务并写入开机自启动文件。

  1. service sshd start
  2. echo “server sshd start” >> initFile

CheckSshdConfig（检查SSHD配置）

SSHD服务配置错误

设置SSHD服务，

  1. PasswordAuthentication=no;
  2. MaxStartups=1000;
  3. UseDNS=yes;
  4. ClientAliveInterval=10800/ClientAliveInterval=0

并重启服务：

  1. server sshd start

CheckCrondService（检查Crond服务）

Crond服务未启动

安装Crond服务并启用。

CheckStack（检查堆栈大小）

堆栈大小小于3072

使用gs_checkos设置为3072并重启堆栈值过小进程。

  1. gs_checkos -i B2

CheckSysPortRange（检查系统端口设置）

系统ip端口不在预期范围内或openGauss端口在系统ip端口内

设置系统ip端口范围参数到26000-65535之中；设置openGauss端口在系统ip端口范围外。

  1. vim /etc/sysctl.conf

CheckMemInfo（检查内存信息）

各节点内存大小不一致

使用相同规格的物理内存。

CheckHyperThread（检查超线程）

未开启CPU超线程

开启CPU超线程。

CheckTableSpace（检查表空间）

表空间路径和openGauss路径存在嵌套或表空间路径相互存在嵌套

将表空间数据迁移到路径合法的表空间中。

检查数据库性能

检查办法

通过openGauss提供的性能统计工具gs_checkperf可以对硬件性能进行检查。

前提条件

  • openGauss运行状态正常。
  • 运行在数据库之上的业务运行正常。

操作步骤

  1. 以操作系统用户omm登录数据库主节点。

  2. 执行如下命令对openGauss数据库进行性能检查。

    1. gs_checkperf

具体的性能统计项目请参见《openGauss 工具参考》中“服务端工具 > gs_checkperf > 性能检查项”。

示例

以简要格式在屏幕上显示性能统计结果。

  1. gs_checkperf -i pmk -U omm
  2. Cluster statistics information:
  3.     Host CPU busy time ratio                     :    1.43       %
  4.     MPPDB CPU time % in busy time                :    1.88       %
  5.     Shared Buffer Hit ratio                      :    99.96      %
  6.     In-memory sort ratio                         :    100.00     %
  7.     Physical Reads                               :    4
  8.     Physical Writes                              :    25
  9.     DB size                                      :    70         MB
  10.     Total Physical writes                        :    25
  11.     Active SQL count                             :    2
  12.     Session count                                :    3

异常处理

使用gs_checkperf工具检查openGauss性能状态后，如果发现检查结果发现异常，可以根据以下内容进行修复。

表 2 检查openGauss级别性能状态

异常状态

处理方法

主机CPU占有率高

1、更换和增加高性能的CPU。

2、使用top命令查看系统哪些进程的CPU占有率高，然后使用kill命令关闭没有使用的进程。

  1. top

openGauss CPU占有率高

1、更换和增加高性能的CPU。

2、使用top命令查看数据库哪些进程的CPU占有率高，然后使用kill命令关闭没有使用的进程。

  1. top

3、使用gs_expand工具扩容，增加新的主机均衡CPU占有率。

共享内存命中率低

1、扩大内存。

2、使用如下命令查看操作系统配置文件/etc/sysctl.conf，调大共享内存kernel.shmmax值。

  1. vim /etc/sysctl.conf

内存中排序比率低

扩大内存。

I/O、磁盘使用率高

1、更换高性能的磁盘。

2、调整数据布局，尽量将I/O请求较合理的分配到所有物理磁盘中。

3、全库进行VACUUM FULL操作。

  1. vacuum full;

4、进行磁盘整理，参考上面执行全库vacuum full或针对性做单表vacuum/vacuum full操作。

5、降低并发数。

事务统计

查询pg_stat_activity系统表，将不必要的连接断开。（登录数据库后查询：openGauss=# \d+ pg_stat_activity;）

**表 3** 检查节点级别性能状态

异常状态

处理方法

CPU占有率高

1、更换和增加高性能的CPU。

2、使用top命令查看系统哪些进程的CPU占有率高，然后使用kill命令关闭没有使用的进程。

  1. top

内存使用率过高情况

扩大或清理内存。

I/O使用率过高情况

1、更换高性能的磁盘。

2、进行磁盘清理。

3、尽可能用内存的读写代替直接磁盘I/O，使频繁访问的文件或数据放入内存中进行操作处理。

**表 4** 会话/进程级别性能状态

异常状态

处理方法

CPU、内存、I/O使用率过高情况

查看哪个进程占用CPU/内存高或I/O使用率高，若是无用的进程，则kill掉，否则排查具体原因。例如SQL执行占用内存大，查看是否SQL语句需要优化。

表 5 SSD性能状态

异常状态

处理方法

SSD读写性能故障

使用以下命令查看SSD是否有故障，排查具体故障原因。

  1. gs_checkperf -i SSD -U omm

检查和清理日志

日志是检查系统运行及故障定位的关键手段。建议按月度例行查看操作系统日志及数据库的运行日志。同时，随着时间的推移，日志的增加会占用较多的磁盘空间。建议按月度清理数据库的运行日志。

检查操作系统日志

建议按月检查操作系统日志，排除操作系统运行异常隐患。

执行如下命令查看操作系统日志文件。

  1. vim /var/log/messages

关注其中近一个月出现的kernel、error、fatal等字样，根据系统报警信息进行处理。

检查openGauss运行日志

数据库运行时，某些操作在执行过程中可能会出现错误，数据库依然能够运行。但是此时数据库中的数据可能已经发生不一致的情况。建议按月检查openGauss运行日志，及时发现隐患。

前提条件

  • 收集日志的主机网络通畅且未宕机，数据库安装用户互信正常。
  • 日志收集工具依赖操作系统工具如gstack，如果未安装该工具，则提示错误后，跳过该收集项。

操作步骤

  1. 以操作系统用户omm登录数据库主节点。

  2. 执行如下命令收集数据库日志。

    1. gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59"

    20160616 01:01为日志的开始时间，20160616 23:59为日志的结束时间。

  3. 根据2的界面输出提示，进入相应的日志收集目录，解压收集的日志，并检查数据库日志。

    以下以日志收集路径“/opt/gaussdb/tmp/gaussdba_mppdb/collector_20160726_105158.tar.gz”为例进行操作。

    1. tar -xvzf /opt/gaussdb/tmp/gaussdba_mppdb/collector_20160726_105158.tar.gz 
    2. cd /opt/gaussdb/tmp/gaussdba_mppdb/collector_20160726_105158

示例

  • 以–begin-time与–end-time为参数执行gs_collector命令。

    1. gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59"

    当显示类似如下信息表示日志已经归档。

    1. Successfully collected  files 
    2. All results are stored in /tmp/gaussdba_mppdb/collector_20160616_175615.tar.gz.

  • 以–begin-time、–end-time与-h为参数执行gs_collector命令。

    1. gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" -h plat2

    当显示类似如下信息表示日志已经归档。

    1. Successfully collected  files
    2. All results are stored in /tmp/gaussdba_mppdb/collector_20160616_190225.tar.gz.

  • 以–begin-time、–end-time与-f为参数执行gs_collector命令。

    1. gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" -f /opt/software/gaussdb/output

    当显示类似如下信息表示日志已经归档。

    1. Successfully collected  files
    2. All results are stored in /opt/software/gaussdb/output/collector_20160616_190511.tar.gz.

  • 以–begin-time、–end-time与–keyword为参数执行gs_collector命令。

    1. gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" --keyword="os"

    当显示类似如下信息表示日志已经归档。

    1. Successfully collected files.
    2. All results are stored in /tmp/gaussdba_mppdb/collector_20160616_190836.tar.gz.

  • 以–begin-time、–end-time与-o为参数执行gs_collector命令。

    1. gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" -o /opt/software/gaussdb/output

    当显示类似如下信息表示日志已经归档。

    1. Successfully collected files.
    2. All results are stored in /opt/software/gaussdb/output/collector_20160726_113711.tar.gz.

  • 以–begin-time、–end-time与-l为参数（文件名必须以.log为后缀）执行gs_collector命令。

    1. gs_collector --begin-time="20160616 01:01" --end-time="20160616 23:59" -l /opt/software/gaussdb/logfile.log

    当显示类似如下信息表示日志已经归档。

    1. Successfully collected files.
    2. All results are stored in /opt/software/gaussdb/output/collector_20160726_113711.tar.gz.

清理运行日志

数据库运行过程中会产生大量运行日志，占用大量的磁盘空间，建议清理过期日志文件，只保留一个月的日志。

操作步骤

  1. 以操作系统用户omm登录数据库主节点。

  2. 清理日志。

    a. 将超过1个月的日志备份到其他磁盘。

    b. 进入日志存放目录。

    1. cd $GAUSSLOG

    c. 进入相应的子目录，使用如下方式删除1个月之前产生的日志。

    1. rm 日志名称

    日志文件的命名格式为“postgresql-年-月-日_HHMMSS”。

检查时间一致性

数据库事务一致性通过逻辑时钟保证，与操作系统时间无关，但是系统时间不一致会导致诸多潜在问题，主要是后台运维和监控功能异常，因此在月度检查时建议检查各个节点的时间一致性。

操作步骤

  1. 以操作系统用户omm登录数据库主节点。

  2. 创建记录openGauss各节点的配置文件（_mpphosts文件目录_用户可随意指定，建议放在/tmp下）。

    1. vim /tmp/mpphosts

    增加各节点的主机名称。

    1. plat1
    2. plat2
    3. plat3

  3. 保存配置文件。

    1. :wq!

  4. 执行如下命令，输出各节点上的时间到“/tmp/sys_ctl-os1.log”文件中。

    1. for ihost in `cat /tmp/mpphosts`; do ssh -n -q $ihost "hostname;date"; done > /tmp/sys_ctl-os1.log

  5. 根据输出确认各个节点的时间一致性，节点之间时间差异不能超过30秒。

    1. cat /tmp/sys_ctl-os1.log
    2. plat1
    3. Thu Feb  9 16:46:38 CST 2017
    4. plat2
    5. Thu Feb  9 16:46:49 CST 2017
    6. plat3
    7. Thu Feb  9 16:46:14 CST 2017

检查应用连接数

如果应用程序与数据库的连接数超过最大值，则新的连接无法建立。建议每天检查连接数，及时释放空闲的连接或者增加最大连接数。

操作步骤

  1. 以操作系统用户omm登录数据库主节点。

  2. 使用如下命令连接数据库。

    1. gsql -d postgres -p 8000

    postgres为需要连接的数据库名称，8000为数据库主节点的端口号。

    连接成功后，系统显示类似如下信息：

    1. gsql ((openGauss 1.0 build 290d125f) compiled at 2020-05-08 02:59:43 commit 2143 last mr 131
    2. Non-SSL connection (SSL connection is recommended when requiring high-security)
    3. Type "help" for help.
    5. openGauss=#

  3. 执行如下SQL语句查看连接数。

    1. openGauss=# SELECT count(*) FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;

    显示类似如下的信息，其中2表示当前有两个应用连接到数据库。

    1. count
    2. -------
    3.      2
    4. (1 row)

  4. 查看现有最大连接数。

    1. openGauss=# SHOW max_connections;

    显示信息如下，其中200为现在的最大连接数。

    1.  max_connections 
    2. -----------------
    3.  200
    4. (1 row)

异常处理

如果显示的连接数接近数据库的最大连接数max_connections，则需要考虑清理现有连接数或者增加新的连接数。

  1. 执行如下SQL语句，查看state字段等于idle，且state_change字段长时间没有更新过的连接信息。

    1. openGauss=# SELECT * FROM pg_stat_activity where state='idle' order by state_change;

    显示类似如下的信息：

    1.  datid | datname  |       pid       | usesysid | usename  | application_name |  client_addr  
    2.  | client_hostname | client_port |         backend_start         | xact_start |          quer
    3. y_start          |         state_change          | waiting | enqueue | state | resource_pool 
    4. |                    query                     
    5. -------+----------+-----------------+----------+----------+------------------+---------------
    6. -+-----------------+-------------+-------------------------------+------------+--------------
    7. -----------------+-------------------------------+---------+---------+-------+---------------
    8. +----------------------------------------------
    9.  13626 | postgres | 140390162233104 |       10 | gaussdba |                  |               
    10.  |                 |          -1 | 2016-07-15 14:08:59.474118+08 |            | 2016-07-15 14
    11. :09:04.496769+08 | 2016-07-15 14:09:04.496975+08 | f       |         | idle  | default_pool  
    12. | select count(group_name) from pgxc_group;
    13.  13626 | postgres | 140390132872976 |       10 | gaussdba | cn_5002          | 10.180.123.163
    14.  |                 |       48614 | 2016-07-15 14:11:16.014871+08 |            | 2016-07-15 14
    15. :21:17.346045+08 | 2016-07-15 14:21:17.346095+08 | f       |         | idle  | default_pool  
    16. | SET SESSION AUTHORIZATION DEFAULT;RESET ALL;
    17. (2 rows)

  2. 释放空闲的连接数。

    查看每个连接，并与此连接的使用者确认是否可以断开连接，或执行如下SQL语句释放连接。其中，pid为上一步查询中空闲连接所对应的pid字段值。

    1. openGauss=# SELECT pg_terminate_backend(140390132872976);

    显示类似如下的信息：

    1. openGauss=# SELECT pg_terminate_backend(140390132872976);
    2.  pg_terminate_backend 
    3. ----------------------
    4.  t
    5. (1 row)

    如果没有可释放的连接，请执行下一步。

  3. 增加最大连接数。

    1. gs_guc set -D /gaussdb/data/dbnode -c "max_connections= 800"

    其中800为新修改的连接数。

  4. 重启数据库服务使新的设置生效。

    例行维护 - 图1 说明： 重启openGauss操作会导致用户执行操作中断，请在操作之前规划好合适的执行窗口。

    1. gs_om -t stop && gs_om -t start

例行维护表

为了保证数据库的有效运行，数据库必须在插入/删除操作后，基于客户场景，定期做VACUUM FULL和ANALYZE，更新统计信息，以便获得更优的性能。

相关概念

使用VACUUM、VACUUM FULL和ANALYZE命令定期对每个表进行维护，主要有以下原因：

  • VACUUM FULL可回收已更新或已删除的数据所占据的磁盘空间，同时将小数据文件合并。
  • VACUUM对每个表维护了一个可视化映射来跟踪包含对别的活动事务可见的数组的页。一个普通的索引扫描首先通过可视化映射来获取对应的数组，来检查是否对当前事务可见。若无法获取，再通过堆数组抓取的方式来检查。因此更新表的可视化映射，可加速唯一索引扫描。
  • VACUUM可避免执行的事务数超过数据库阈值时，事务ID重叠造成的原有数据丢失。
  • ANALYZE可收集与数据库中表内容相关的统计信息。统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据，生成最有效的执行计划。

操作步骤

  1. 使用VACUUM或VACUUM FULL命令，进行磁盘空间回收。

    • VACUUM：

      对表执行VACUUM操作

      1. openGauss=# VACUUM customer;
      1. VACUUM

      可以与数据库操作命令并行运行。（执行期间，可正常使用的语句：SELECT、INSERT、UPDATE和DELETE。不可正常使用的语句：ALTER TABLE）。

      对表分区执行VACUUM操作

      1. openGauss=# VACUUM customer_par PARTITION ( P1 );
      1. VACUUM

    • VACUUM FULL：

      1. openGauss=# VACUUM FULL customer;
      1. VACUUM

      需要向正在执行的表增加排他锁，且需要停止其他所有数据库操作。

  2. 使用ANALYZE语句更新统计信息。

    1. openGauss=# ANALYZE customer;
    1. ANALYZE

    使用ANALYZE VERBOSE语句更新统计信息，并输出表的相关信息。

    1. openGauss=# ANALYZE VERBOSE customer;
    1. ANALYZE

    也可以同时执行VACUUM ANALYZE命令进行查询优化。

    1. openGauss=# VACUUM ANALYZE customer;
    1. VACUUM

    例行维护 - 图2 说明： VACUUM和ANALYZE会导致I/O流量的大幅增加，这可能会影响其他活动会话的性能。因此，建议通过“vacuum_cost_delay”参数设置《开发者指南》中“GUC参数说明 > 资源消耗 > 基于开销的清理延迟”。

  3. 删除表。

    1. openGauss=# DROP TABLE customer;
    2. openGauss=# DROP TABLE customer_par;
    3. openGauss=# DROP TABLE part;

    当结果显示为如下信息，则表示删除成功。

    1. 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）。

    1. 删除索引。

      1. openGauss=# DROP INDEX areaS_idx;

      当结果显示如下信息，则表示删除成功。

      1. DROP INDEX

    2. 创建索引。

      1. openGauss=# CREATE INDEX areaS_idx ON areaS (area_id);

      当结果显示如下信息，则表示创建成功。

      1. CREATE INDEX

  • 使用REINDEX重建索引。

    • 使用REINDEX TABLE语句重建索引。

      1. openGauss=# REINDEX TABLE areaS;

      当结果显示如下信息，则表示重建成功。

      1. REINDEX

    • 使用REINDEX INTERNAL TABLE重建desc表（包括列存表的cudesc表）的索引。

      1. openGauss=# REINDEX INTERNAL TABLE areaS;

      当结果显示如下信息，则表示重建成功。

      1. REINDEX

例行维护 - 图3 说明： 在重建索引前，用户可以通过临时增大maintenance_work_mem和psort_work_mem的取值来加快索引的重建。

导出并查看wdr诊断报告

生成快照数据需参数enable_wdr_snapshot=on，访问WDR快照数据需要sysadmin或monadmin权限，因此需要使用root账号或其他拥有权限的账号来生成WDR诊断报告。

  1. 执行如下命令新建报告文件。

    1. touch  /home/om/wdrTestNode.html

  2. 连接系统库postgres。

    1. gsql -d postgres -p 端口号 -r

  3. 选择snapshot.snapshot表中两个不同的snapshot，当这两个snapshot之间未发生服务重启，便可以使用这两个snapshot生成报告。

    1. openGauss=#  select * from snapshot.snapshot order by start_ts desc limit 10;

  4. 执行如下命令，在本地生成HTML格式的WDR报告。

    1. 执行如下命令，设置报告格式。\a: 不显示表行列符号， \t: 不显示列名 ，\o: 指定输出文件。

      1. openGauss=# \a \t \o {报告路径}

      示例：

      1. openGauss=# \a \t \o /home/omm/wdrTestNode.html

    2. 执行如下命令，生成HTML格式的WDR报告。

      1. openGauss=# select generate_wdr_report(begin_snap_id Oid, end_snap_id Oid, int report_type, int report_scope, int node_name );

      示例一，生成集群级别的报告：

      1. openGauss=# select generate_wdr_report(1, 2, 'all', 'cluster',null);

      示例二，生成某个节点的报告：

      1. openGauss=# select generate_wdr_report(1, 2, 'all', 'node', pgxc_node_str()::cstring);

      例行维护 - 图4 说明：

      • 当前openGauss的节点名固定是“dn_6001”，也可直接代入。

      表 1 参数说明

      参数

      说明

      取值范围

      begin_snap_id

      要查看的某段时间性能的开始的snapshot的id（表snapshot.snaoshot中的snapshot_id）

      -

      end_snap_id

      结束snapshot的id，默认end_snap_id大于begin_snap_id（表snapshot.snaoshot中的snapshot_id）

      -

      report_type

      指定生成report的类型。

      • summary
      • detail
      • all，即同时包含summary和detail。

      report_scope

      指定生成report的范围。

      • cluster：集群
      • node：集群中某个节点。

      node_name

      • 在report_scope指定为single node时，需要把该参数指定为对应节点的名称。
      • 在report_scope为cluster时，该值可以指定为省略或者为NULL。

      -

  5. 执行如下命令关闭输出选项及格式化输出命令。

    1. \o \a \t

  6. 在/home/om/下根据需要查看WDR报告内容。

    表 2 WDR报表主要内容

    项目

    描述

    Database Stat（集群范围）

    数据库维度性能统计信息：事务，读写，行活动，写冲突，死锁等。

    Load Profile（集群范围）

    集群维度的性能统计信息：CPU时间，DB时间，逻辑读/物理读，IO性能，登入登出，负载强度，负载性能表现等。

    Instance Efficiency Percentages（集群/节点范围）

    集群级或者节点缓冲命中率。

    IO Profile（集群/节点范围）

    集群或者节点维度的IO的使用情况。

    Top 10 Events by Total Wait Time（节点范围）

    最消耗时间的事件。

    Wait Classes by Total Wait Time（节点范围）

    最消耗时间的等待时间分类。

    Host CPU（节点范围）

    主机CPU消耗。

    Memory Statistics（节点范围）

    内核内存使用分布。

    Time Model（节点范围）

    节点范围的语句的时间分布信息。

    Wait Events（节点范围）

    节点级别的等待事件的统计信息。

    Cache IO Stats (集群/节点范围)

    用户的表、索引的IO的统计信息。

    Utility status （节点范围）

    复制槽和后台checkpoint的状态信息。

    Object stats（集群/节点范围）

    表、索引维度的性能统计信息。

    Configuration settings（节点范围）

    节点配置。

    SQL Statistics（集群/节点范围）

    SQL语句各个维度性能统计：端到端时间，行活动，缓存命中，CPU消耗，时间消耗细分。

    SQL Detail（集群/节点范围）

    SQL语句文本详情。

数据安全维护建议

为保证openGauss数据库中的数据安全，避免丢失数据、非法访问数据等事故发生，请仔细阅读以下内容。

避免数据被丢失

建议用户规划周期性的物理备份，且对备份文件进行可靠的保存。在系统发生严重错误的情况下，可以利用备份文件，将系统恢复到备份前的状态。

避免数据被非法访问

  • 建议对数据库用户进行权限分级管理。数据库管理员根据业务需要，建立用户并赋予权限，保证各用户对数据库的合理访问。
  • 对于openGauss的服务端和客户端（或基于客户端库开发的应用程序），最好也部署在可信任的内网中。如果服务端和客户端一定要部署在非信任的网络中，需要在服务启动前，打开SSL加密，保证数据在非信任网络上的传输安全。需要注意的是，打开SSL加密会降低数据库的性能。

避免系统日志泄露个人数据

  • 将调试日志发给他人进行分析前，请删除个人数据。

    例行维护 - 图5 说明： 因为日志级别（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”。
  • 只能用系统管理员和监控管理员权限进行操作。
  1. 执行命令查看数据库实例中SQL语句执行信息
  2. select * from dbe_perf.get_global_full_sql_by_timestamp(start_timestamp, end_timestamp); 
  3. 例如：
  4. select * from DBE_PERF.get_global_full_sql_by_timestamp('2020-12-01 09:25:22', '2020-12-31 23:54:41');
  5. -[ RECORD 1 ]--------+---------------------------------------------------------------------------------------------------------------
  6. ---------------------------------------------------------------
  7. node_name            | dn_6001_6002_6003
  8. db_name              | postgres
  9. schema_name          | "$user",public
  10. origin_node          | 1938253334
  11. user_name            | user_dj
  12. application_name     | gsql
  13. client_addr          |
  14. client_port          | -1
  15. unique_query_id      | 3671179229
  16. debug_query_id       | 72339069014839210
  17. query                | select name, setting from pg_settings where name in (?)
  18. start_time           | 2020-12-19 16:19:51.216818+08
  19. finish_time          | 2020-12-19 16:19:51.224513+08
  20. slow_sql_threshold   | 1800000000
  21. transaction_id       | 0
  22. thread_id            | 139884662093568
  23. session_id           | 139884662093568
  24. n_soft_parse         | 0
  25. n_hard_parse         | 1
  26. query_plan           | Datanode Name: dn_6001_6002_6003
  27.                      | Function Scan on pg_show_all_settings a  (cost=0.00..12.50 rows=5 width=64)
  28.                      |   Filter: (name = '***'::text)
  29. ...
  31. 执行命令查看数据库实例中慢SQL语句执行信息
  32. select * from dbe_perf.get_global_slow_sql_by_timestamp(start_timestamp, end_timestamp);
  33. 例如：
  34. select * from DBE_PERF.get_global_slow_sql_by_timestamp('2020-12-01 09:25:22', '2020-12-31 23:54:41');
  35. -[ RECORD 1 ]--------+---------------------------------------------------------------------------------------------------
  36. node_name            | dn_6001_6002_6003
  37. db_name              | postgres
  38. schema_name          | "$user",public
  39. origin_node          | 1938253334
  40. user_name            | user_dj
  41. application_name     | gsql
  42. client_addr          |
  43. client_port          | -1
  44. unique_query_id      | 2165004317
  45. debug_query_id       | 72339069014839319
  46. query                | select * from DBE_PERF.get_global_slow_sql_by_timestamp(?, ?);
  47. start_time           | 2020-12-19 16:23:20.738491+08
  48. finish_time          | 2020-12-19 16:23:20.773714+08
  49. slow_sql_threshold   | 10000
  50. transaction_id       | 0
  51. thread_id            | 139884662093568
  52. session_id           | 139884662093568
  53. n_soft_parse         | 10
  54. n_hard_parse         | 8
  55. query_plan           | Datanode Name: dn_6001_6002_6003
  56.                      | Result  (cost=1.01..1.02 rows=1 width=0)
  57.                      |   InitPlan 1 (returns $0)
  58.                      |     ->  Seq Scan on pgxc_node  (cost=0.00..1.01 rows=1 width=64)
  59.                      |           Filter: (nodeis_active AND ((node_type = '***'::"char") OR (node_type = '***'::"char")))
  60. ...
  62. 查看当前主节点SQL语句执行信息
  63. select * from statement_history;
  64. 例如：
  65. select * from statement_history;
  66. -[ RECORD 1 ]--------+---------------------------------------------------------------------------------------------------------------
  67. ---------------------------------------------------------------
  68. db_name              | postgres
  69. schema_name          | "$user",public
  70. origin_node          | 1938253334
  71. user_name            | user_dj
  72. application_name     | gsql
  73. client_addr          |
  74. client_port          | -1
  75. unique_query_id      | 3671179229
  76. debug_query_id       | 72339069014839210
  77. query                | select name, setting from pg_settings where name in (?)
  78. start_time           | 2020-12-19 16:19:51.216818+08
  79. finish_time          | 2020-12-19 16:19:51.224513+08
  80. slow_sql_threshold   | 1800000000
  81. transaction_id       | 0
  82. thread_id            | 139884662093568
  83. session_id           | 139884662093568
  84. n_soft_parse         | 0
  85. n_hard_parse         | 1
  86. query_plan           | Datanode Name: dn_6001_6002_6003
  87.                      | Function Scan on pg_show_all_settings a  (cost=0.00..12.50 rows=5 width=64)
  88.                      |   Filter: (name = '***'::text)
  89. ...
  91. 查看当前备节点SQL语句执行信息
  92. select * from dbe_perf.standby_statement_history(is_only_slow, start_timestamp, end_timestamp);
  93. 例如：
  94. select * from dbe_perf.standby_statement_history(true, '2022-08-01 09:25:22', '2022-08-31 23:54:41');
  95. db_name              | postgres
  96. schema_name          | "$user",public
  97. origin_node          | 0
  98. user_name            | user_dj
  99. application_name     | gsql
  100. client_addr          |
  101. client_port          | -1
  102. unique_query_id      | 1660376009
  103. debug_query_id       | 281474976710740
  104. query                | select name, setting from pg_settings where name in (?)
  105. start_time           | 2022-08-19 16:19:51.216818+08
  106. finish_time          | 2022-08-19 16:19:51.224513+08
  107. slow_sql_threshold   | 1800000000
  108. transaction_id       | 0
  109. thread_id            | 140058747205376
  110. session_id           | 140058747205376
  111. n_soft_parse         | 0
  112. n_hard_parse         | 1
  113. query_plan           | Datanode Name: sgnode
  114.                      | Function Scan on pg_show_all_settings a  (cost=0.00..12.50 rows=5 width=64)
  115.                      |   Filter: (name = '***'::text)
  116. ...