例行维护

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

    • 检查实例状态

    • 检查参数

      上述命令中，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检查或设置状态为Abnormal，可以使用如下命令查看详细的错误信息。

    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

      • 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:59 Nodes:2
    11. Checking...               [                         ] 21/57
    12. Checking...               [=========================] 59/57
    13. Start to analysis the check result
    14. CheckClusterState...........................OK
    15. The item run on 2 nodes.  success: 2
    16. CheckDBParams...............................OK
    17. The item run on 1 nodes.  success: 1
    19. CheckDebugSwitch............................OK
    20. The item run on 2 nodes.  success: 2
    22. CheckDirPermissions.........................OK
    23. The item run on 2 nodes.  success: 2
    25. CheckReadonlyMode...........................OK
    26. The item run on 1 nodes.  success: 1
    28. CheckEnvProfile.............................OK
    29. The item run on 2 nodes.  success: 2  (consistent)
    30. The success on all nodes value:
    31. GAUSSHOME        /usr1/gaussdb/app
    32. LD_LIBRARY_PATH  /usr1/gaussdb/app/lib
    33. PATH             /usr1/gaussdb/app/bin
    36. CheckBlockdev...............................OK
    37. The item run on 2 nodes.  success: 2
    39. CheckCurConnCount...........................OK
    40. The item run on 1 nodes.  success: 1
    42. CheckCursorNum..............................OK
    43. The item run on 1 nodes.  success: 1
    45. CheckPgxcgroup..............................OK
    46. The item run on 1 nodes.  success: 1
    48. CheckDiskFormat.............................OK
    49. The item run on 2 nodes.  success: 2
    51. CheckSpaceUsage.............................OK
    54. CheckInodeUsage.............................OK
    55. The item run on 2 nodes.  success: 2
    57. CheckSwapMemory.............................OK
    58. The item run on 2 nodes.  success: 2
    60. CheckLogicalBlock...........................OK
    61. The item run on 2 nodes.  success: 2
    63. CheckIOrequestqueue.....................WARNING
    64. The item run on 2 nodes.  warning: 2
    65. The warning[host240,host157] value:
    66. On device (vdb) 'IO Request' RealValue '256' ExpectedValue '32768'
    67. On device (vda) 'IO Request' RealValue '256' ExpectedValue '32768'
    69. CheckMaxAsyIOrequests.......................OK
    70. The item run on 2 nodes.  success: 2
    72. CheckIOConfigure............................OK
    73. The item run on 2 nodes.  success: 2
    75. CheckMTU....................................OK
    76. The item run on 2 nodes.  success: 2  (consistent)
    77. The success on all nodes value:
    78. 1500
    80. CheckPing...................................OK
    81. The item run on 2 nodes.  success: 2
    83. CheckRXTX...................................NG
    84. The item run on 2 nodes.  ng: 2
    85. The ng[host240,host157] value:
    86. NetWork[eth0]
    87. RX: 256
    88. TX: 256
    91. CheckNetWorkDrop............................OK
    92. The item run on 2 nodes.  success: 2
    94. CheckMultiQueue.............................OK
    95. The item run on 2 nodes.  success: 2
    97. CheckEncoding...............................OK
    98. The item run on 2 nodes.  success: 2  (consistent)
    99. The success on all nodes value:
    100. LANG=en_US.UTF-8
    102. CheckFirewall...............................OK
    103. The item run on 2 nodes.  success: 2
    105. CheckKernelVer..............................OK
    106. The item run on 2 nodes.  success: 2  (consistent)
    107. The success on all nodes value:
    108. 3.10.0-957.el7.x86_64 
    110. CheckMaxHandle..............................OK
    111. The item run on 2 nodes.  success: 2
    113. CheckNTPD...................................OK
    114. host240: NTPD service is running, 2020-06-02 17:00:28
    115. host157: NTPD service is running, 2020-06-02 17:00:06
    118. CheckOSVer..................................OK
    119. host240: The current OS is centos 7.6 64bit.
    120. host157: The current OS is centos 7.6 64bit.
    123. CheckSysParams..........................WARNING
    124. The item run on 2 nodes.  warning: 2
    125. The warning[host240,host157] value:
    126. Warning reason: variable 'net.ipv4.tcp_retries1' RealValue '3' ExpectedValue '5'.
    127. Warning reason: variable 'net.ipv4.tcp_syn_retries' RealValue '6' ExpectedValue '5'.
    130. CheckTHP....................................OK
    131. The item run on 2 nodes.  success: 2
    133. CheckTimeZone...............................OK
    134. The item run on 2 nodes.  success: 2  (consistent)
    135. The success on all nodes value:
    136. +0800
    138. CheckCPU....................................OK
    139. The item run on 2 nodes.  success: 2
    141. CheckSshdService............................OK
    142. The item run on 2 nodes.  success: 2
    144. Warning reason: UseDNS parameter is not set; expected: no
    146. CheckCrondService...........................OK
    147. The item run on 2 nodes.  success: 2
    149. CheckStack..................................OK
    150. The item run on 2 nodes.  success: 2  (consistent)
    151. The success on all nodes value:
    152. 8192
    154. CheckSysPortRange...........................OK
    155. The item run on 2 nodes.  success: 2
    157. CheckMemInfo................................OK
    158. The item run on 2 nodes.  success: 2  (consistent)
    159. The success on all nodes value:
    160. totalMem: 31.260929107666016G
    162. CheckHyperThread............................OK
    163. The item run on 2 nodes.  success: 2
    165. CheckTableSpace.............................OK
    166. The item run on 1 nodes.  success: 1
    169. CheckSysadminUser...........................OK
    170. The item run on 1 nodes.  success: 1
    173. CheckGUCConsistent..........................OK
    174. All DN instance guc value is consistent.
    176. CheckMaxProcMemory..........................OK
    177. The item run on 1 nodes.  success: 1
    179. CheckBootItems..............................OK
    180. The item run on 2 nodes.  success: 2
    182. CheckHashIndex..............................OK
    183. The item run on 1 nodes.  success: 1
    185. CheckPgxcRedistb............................OK
    186. The item run on 1 nodes.  success: 1
    188. CheckNodeGroupName..........................OK
    189. The item run on 1 nodes.  success: 1
    191. CheckTDDate.................................OK
    192. The item run on 1 nodes.  success: 1
    194. CheckDilateSysTab...........................OK
    195. The item run on 1 nodes.  success: 1
    197. CheckKeyProAdj..............................OK
    198. The item run on 2 nodes.  success: 2
    200. CheckProStartTime.......................WARNING
    201. host157:
    202. STARTED COMMAND
    203. Tue Jun  2 16:57:18 2020 /usr1/dmuser/dmserver/metricdb1/server/bin/gaussdb --single_node -D /usr1/dmuser/dmb1/data -p 22204
    204. Mon Jun  1 16:15:15 2020 /usr1/gaussdb/app/bin/gaussdb -D /usr1/gaussdb/data/dn1 -M standby
    207. CheckFilehandle.............................OK
    208. The item run on 2 nodes.  success: 2
    210. CheckRouting................................OK
    211. The item run on 2 nodes.  success: 2
    213. CheckNICModel...............................OK
    214. The item run on 2 nodes.  success: 2  (consistent)
    215. The success on all nodes value:
    216. version: 1.0.1
    217. model: Red Hat, Inc. Virtio network device
    220. CheckDropCache..........................WARNING
    221. The item run on 2 nodes.  warning: 2
    222. The warning[host240,host157] value:
    223. No DropCache process is running
    225. CheckMpprcFile..............................NG
    226. The item run on 2 nodes.  ng: 2
    227. There is no mpprc file
    229. Analysis the check result successfully
    230. Failed. All check items run completed. Total:57   Success:50   Warning:5   NG:2
    231. For more information please refer to /usr1/gaussdb/tool/script/gspylib/inspection/output/CheckReport_inspect611.tar.gz

    异常处理

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

    表 1 检查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性能状态后，如果发现检查结果发现异常，可以根据以下内容进行修复。

    表 1 检查openGauss级别性能状态

    表 2 检查节点级别性能状态

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

    表 4 SSD性能状态

    检查和清理日志

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

    检查操作系统日志

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

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

    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"

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

    • 以—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. 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

    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;
        2. DROP INDEX

      2. 创建索引。

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

    • 使用REINDEX重建索引。

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

        1. openGauss=# REINDEX TABLE areaS;
        2. REINDEX

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

        1. openGauss=# REINDEX INTERNAL TABLE areaS;

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

    避免数据被丢失

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

    避免数据被非法访问

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

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

    • 将log_min_error_statement参数的值设置为PANIC可以避免在系统日志中记录出错的SQL语句，但是关闭此功能将导致发生错误时难以定位。