Log Overview
During database running, a large number of logs are generated, including write-ahead logs (WALs, also called Xlogs) for ensuring database security and reliability and run logs and operation logs for daily database maintenance. If the database is faulty, you can refer to these logs to locate the fault and restore the database.
Log Type
The following table describes details about log types.
Table 1 Log types
Type
Description
System log
Logs generated during database running. They are used to record abnormal process information.
Operation log
Logs generated when a client tool (such as gs_guc) is operating databases.
Trace log
Logs generated after the database debug switch is enabled. They are used to analyze database exceptions.
Black box log
Logs generated when the database system breaks down. You can analyze the process context when the fault occurs based on the heap and stack information in the logs to facilitate fault locating. A black box dumps stack, heap, and register information about processes and threads when a system breaks down.
Audit log
Logs used to record some of the database user operations after the database audit function is enabled.
WAL
Logs used to restore a damaged database. They are also called redo logs. You are advised to routinely back up WALs.
Performance log
Logs used to record the status of physical resources and the performance of access to external resources (such as disks and OBS).
System Logs
System logs include those generated by database nodes when openGauss is running, and those generated when openGauss is deployed. If an error occurs during openGauss running, you can locate the cause and troubleshoot it based on system logs.
Log Storage Directory
Run logs of database nodes are stored in the corresponding folders in the /var/log/gaussdb/username/pg_log directory.
Logs generated during OM openGauss installation and uninstallation are stored in the /var/log/gaussdb/username/om directory.
Log Naming Rules
The name format of
database node
run logs is:
postgresql-creation time.log
By default, a new log file is generated at 0:00 every day, or when the size of the latest log file exceeds 16 MB or a database instance (database node) is restarted.
The name formats of CM run logs are:
cm_agent logs: cm_agent-creation time.log**, cm_agent-creation time-current.log, **system_call-creation time.log, and system_call-creation time-current.log
cm_server logs: cm_server-creation time.log, cm_server creation time-current.log, key_event-creation time.log, and key_event-creation time-current.log
om_monitor logs: om_monitor-creation time.log and om_monitor-creation time-current.log.
Logs whose names do not contain current are historical log files. Logs whose names contain current are current log files. When a process is invoked for the first time, a log file whose name contains current is created. If the size of this file exceeds 16 MB, the file is renamed in the historical log file name format, and a new log file is generated at the current time point.
Log Content Description
Content of a line in a
database node
log:
Date+Time+Time zone+Username+Database name+Session ID+Log level+Log content.
By default, a line in a cm_agent, cm_server, om_monitor log is arranged in the following format:
Time+Time zone+Session ID+Log content
The SYSTEM_CALL log records tool commands invoked by cm_agent.
By default, a line in a key_event log is arranged in the following format: Time+Thread ID+Thread name:Key event type+Arbitration object instance ID+Arbitration details.
Operation Logs
Operation logs are generated when database tools are used by a database administrator or invoked by a cluster. If the cluster is faulty, you can backtrack user operations on the database and reproduce the fault based on the operation logs.
Log Storage Directory
The default path is $GAUSSLOG*/bin*. If the environmental variable $GAUSSLOG does not exist or its value is empty, the log information generated for a tool will be displayed, but not recorded in the log file of the tool.
The default value of $GAUSSLOG is /var/log/gaussdb/username.
NOTE: If a database is deployed using the OM script, the log path is /var/log/gaussdb/username.
Log Naming Rules
The log file name format is as follows:
tool name*-log creation time.log*
tool name*-log creation time-current.log*
tool name*-log creation time.log* is a historical log file, and tool name*-log creation time-current.log* is a current log file.
If the size of a log file exceeds 16 MB, the next time the tool is invoked, the log file is renamed in the historical log file name format, and a new log file is generated at the current time point.
For example, gs_guc-2015-01-16_183728-current.log is renamed as gs_guc-2015-01-16_183728.log, and gs_guc-2015-01-17_142216-current.log is generated.
Maintenance Suggestions
You are advised to dump expired logs periodically to save disk space and prevent important logs from being lost.
Audit Logs
After the audit function is enabled, a large number of audit logs will be generated, which occupy large storage space. You can customize an audit log maintenance policy based on the size of available storage space.
For details, see “Database Security Management > Configuring Database Audit > Maintaining Audit Logs” in the Developer Guide.
WALs
In a system using write-ahead logs (WALs or Xlogs), all data file modifications are written to a log before they are applied. That is, the corresponding log must be written into a permanent memory before a data file is modified. You can use WALs to restore the cluster if the system crashes.
Log Storage Directory
Take a DN as an example. Its WALs are stored in the /gaussdb/data/data_dn*/pg_xlog* directory.
/gaussdb/data/data_dn is the data directory of a node in the cluster.
Log Naming Rules
Log files are saved as segment files. Each segment is 16 MB and is divided into multiple 8 KB pages. The name of a WAL file consists of 24 hexadecimal characters. Each name has three parts, with each part having eight hexadecimal characters. The first part indicates the time line, the second part indicates the log file identifier, and the third part indicates the file segment identifier. A time line starts from 1, and a log file identifier and a file segment identifier start from 0.
For example, the name of the first transaction log is 000000010000000000000000.
NOTE: The numbers in each part are used in ascending order in succession. Exhausting all available numbers takes a long time, and the numbers will start from zero again after they reach the maximum.
Log Content Description
The content of WALs depends on the types of recorded transactions. WALs can be used to restore a system after the system breaks down.
By default, GaussDB Kernel reads WALs for system restoration during each startup.
Maintenance Suggestions
WALs are important for database restoration. You are advised to routinely back up WALs.
Performance Logs
Performance logs focus on the access performance of external resources. Performance logs are used to record the status of physical resources and the performance of access to external resources (such as disks and OBS). When a performance issue occurs, you can locate the cause using performance logs, which greatly improves troubleshooting efficiency.
Log Storage Directory
The performance logs of database are stored in the directories under $GAUSSLOG*/gs_profile*.
Log Naming Rules
The name format ofdatabase performance logs is:
postgresql-creation time.prf
By default, a new log file is generated at 0:00 every day, or when the latest log file exceeds 20 MB or a database instance (CN or DN) is restarted.
Log Content Description
Content of a line in a database log:
Host name+Date+Time+Instance name+Thread number+Log content
Top comments (0)