Log Reference

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, OBS and Hadoop clusters).

System Logs

System logs include those generated by database nodes when MogDB is running, and those generated when MogDB is deployed. If an error occurs during MogDB 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/mogdb/username/pg_log directory.

Logs generated during OM MogDB installation and uninstallation are stored in the /var/log/mogdb/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/mogdb/username.

NOTE: If a database is deployed using the OM script, the log path is /var/log/mogdb/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 “Configuring Database Audit > Maintaining Audit Logs” in the Security 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 /mogdb/data/data_dn/pg_xlog directory.

/mogdb/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, MogDB 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, OBS and Hadoop clusters). 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