1. View system logs
The running log and the debugging log can be collectively referred to as the system log. The running log is the log generated when the database is running normally, and the debugging log is based on the log generated when the database is developed and debugged. GaussDB's running log and debugging log are recorded in the same log file.
The log file storage path is
in the $GAUSSDATA\pg_log directory. Among them, $GAUSSDATA represents the data directory of GaussDB.
Log file naming format
GaussDB running log and debugging log are recorded in the following files:
- gaussdb+date+time.log.
- By default, if more than 1 day or the log file is larger than 16MB, a new log file is generated to record the log.
Log content description
The default format of each log line is: [+date+time+time zone+]+session ID+database name+thread ID+process name+transaction ID+command ID+error code+log description.
[2013-12-11 11:21:51.023 CST] c=1386732111.810 d=[AUXILIARY] p=JobScheduler 1174452544 a= x=0 n=0 e=00000 LOG: job scheduler is running
Through the log level, you can easily distinguish the run log and the debug log.
Run log level: log, info, notice, warning, error, fatal, panic.
Debug log level: debug5, debug4, debug3, debug2, debug1
Maintenance recommendations
- It is recommended that you back up expired logs regularly to avoid a large number of logs from occupying too much storage space and avoid loss of important logs.
- Setting the value of the log_min_error_statement parameter to panic can avoid recording error SQL statements in the system log, but turning off this function will make it difficult to locate errors when they occur.
- Storage path, please refer to log_directory for configuration method.
- Log file name, please refer to log_filename for configuration method.
- The interval for creating a new log file. For the configuration method, see log_rotation_age.
- Control the log level written to the server log file. For the configuration method, see log_min_messages.
Related log reference
gaussdb database parameter description [Log related parameter settings] [08]
https://blog.csdn.net/qq_42226855/article/details/108775942
2. View operation log
The operation log contains the logs of the gs_guc and gs_ctl tools, which are generated when the database administrator uses the tool to operate the database. These log information will be printed to the log file and the screen at the same time.
The log file storage path
defaults to the $GAUSSDATA\pg_log directory. If the user who uses the tool does not have the write permission of the pg_log directory, the operation log will be recorded in the $GAUSSHOME\bin directory.
The log file naming format is
gs_ctl-current.log and gs_guc-current.log. If the log size reaches 16MB, it will be renamed according to the current time.
For example, rename gs_ctl-current.log to gs_ctl-2012-11-10_101348.log, and then regenerate gs_ctl-current.log.
Log content description The
operation log records the logs generated by these tools, including error messages and normal prompt messages.
Maintenance recommendations It is recommended
that you regularly back up expired logs to avoid a large number of logs from occupying too much storage space and to avoid the loss of important logs.
3. View the black box log
The black box log records on-site information such as the process, thread heap, stack memory, and registers when the database crashes. Through the black box log, the process context when the fault occurs can be analyzed to facilitate the location of the cause of the fault.
Black box file storage path (Needed by kernel developers, basically not needed by operation and maintenance personnel) Is
in the $GAUSSDATA/pg_blackbox directory by default (%GAUSSDATA%\pg_blackbox by default under Windows). The black box file storage directory can be configured through the configuration parameter black_box_directory.
4. Manage audit logs
gaussdb database audit [Set database audit] [01]
https://blog.csdn.net/qq_42226855/article/details/109557807
Gaussdb database parameter description [Audit log related parameter settings] [10]
https://blog.csdn.net/qq_42226855/article/details/108780801
5. Manage WAL logs
The central idea of WAL (Write Ahead Log, also known as Xlog) is to write the log first and then write the data. The data file must be modified after the modification has been recorded in the log file, that is, after the log record describing these changes is refreshed to the permanent storage.
The log file storage path
defaults to the $GAUSSDATA\pg_xlog directory. Among them, $GAUSSDATA represents the data directory of GaussDB.
Log file naming format The
log file is stored in the form of segment files, each segment is 16MB, and is divided into several pages, each page is 8KB. The naming instructions for WAL logs are as follows:
- The name of a segment file is composed of 24 hexadecimals, divided into three parts, and each part is composed of 8 hexadecimal characters.
- The first part represents the timeline , the second part represents the log file label , and the third part represents the log file segment label . The timeline starts from 1, and the log file label and the segment label of the log file start from 0.
For example, the first transaction log file in the system is 000000010000000000000000.
Note :
These numbers are generally used in sequential increments (it takes a very long time to use up all available numbers), but there are also cases of recycling.
The content of the log shows that
the content of the WAL log depends on the type of transaction recorded, and the WAL log can be used to recover when the system crashes.
In the default configuration, GaussDB reads the WAL log for recovery every time it is started.
Maintenance Suggestions
Considering the importance of WAL logs for abnormal database recovery, it is recommended that you regularly back up WAL logs.
For related logs,
please refer to gaussdb database parameter description [pre-write log settings, checkpoints, archiving] [04]
https://blog.csdn.net/qq_42226855/article/details/108768033