日志参考

日志类型简介

在数据库运行过程中，会出现大量日志，既有保证数据库安全可靠的WAL日志（预写式日志，也称为Xlog），也有用于数据库日常维护的运行和操作日志等。在数据库发生故障时，可以参考这些日志进行问题定位和数据库恢复的操作。

日志类型

日志类型的详细说明请参见下表。

表 1 日志类型

类型	说明
系统日志	数据库系统进程运行时产生的日志，记录系统进程的异常信息。
操作日志	通过客户端工具（例如gs_guc）操作数据库时产生的日志。
Trace日志	打开数据库的调试开关后，会记录大量的Trace日志。这些日志可以用来分析数据库的异常信息。
黑匣子日志	数据库系统崩溃的时候，通过故障现场堆、栈信息可以分析出故障发生时的进程上下文，方便故障定位。黑匣子具有在系统崩溃时，dump出进程和线程的堆、栈、寄存器信息的功能。
审计日志	开启数据库审计功能后，将数据库用户的某些操作记录在日志中，这些日志称为审计日志。
WAL日志	又称为REDO日志，在数据库异常损坏时，可以利用WAL日志进行恢复。由于WAL日志的重要性，所以需要经常备份这些日志。
性能日志	数据库系统在运行时检测物理资源的运行状态的日志，在对外部资源进行访问时的性能日志，例如：磁盘、OBS等。

系统日志

MogDB运行时数据库节点以及MogDB安装部署时产生的日志统称为系统日志。如果MogDB在运行时发生故障，可以通过这些系统日志及时定位故障发生的原因，根据日志内容制定恢复MogDB的方法。

日志文件存储路径

数据库节点的运行日志放在“/var/log/mogdb/用户名/pg_log”中各自对应的目录下。

OM MogDB安装卸载时产生的日志放在“/var/log/mogdb/用户名/om”目录下。

日志文件命名格式

• 数据库节点运行日志的命名规则：

  postgresql-创建时间.log

  默认情况下，每日0点或者日志文件大于16MB或者数据库实例（数据库节点）重新启动后，会生成新的日志文件。

• CM的运行日志的命名规则：

  • cm_agent的日志：cm_agent-创建时间.log、cm_agent-创建时间-current.log、system_call-创建时间.log、system_call-创建时间-current.log。
  • cm_server的日志：cm_server-创建时间.log、cm_server-创建时间-current.log；key_event-创建时间.log、key_event-创建时间-current.log。
  • om_monitor的日志：om_monitor-创建时间.log、om_monitor-创建时间-current.log。

  其中，不带current标识符的文件是历史日志文件，带current标识符的文件是当前日志文件。最初调用进程时，进程会先创建一个带current标识符的日志文件，当该日志文件的大小超过16MB时，会将当前日志文件重命名为历史日志文件，并以当前时间生成新的当前日志文件。

日志内容说明

• 数据库节点每一行日志内容的默认格式：

  日期+时间+时区+用户名称+数据库名称+会话ID+日志级别+日志内容

• cm_agent、cm_server、om_monitor每一行日志内容的默认格式：

  时间+时区+会话ID+日志内容 SYSTEM_CALL系统调用日志记录了CM_AGENT在运行过程中调用工具命令的情况。 key_event每一行日志内容的默认格式: 时间+线程号+线程名: 关键事件类型+仲裁对象实例ID+仲裁细节。

操作日志

操作日志是指数据库管理员使用工具操作数据库时以及工具被MogDB调用时产生的日志。如果MogDB发生故障，可以通过这些日志信息跟踪用户对数据库进行了哪些操作，重现故障场景。

日志文件存储路径

默认在$GAUSSLOG/bin目录下, 如果环境变量$GAUSSLOG不存在或者变量值为空，则工具日志信息不会记录到对应的工具日志文件中，日志信息只会打印到屏幕上。

其中$GAUSSLOG默认为/var/log/mogdb/_用户名_。

说明: 如果使用om脚本部署时，则日志路径为/var/log/mogdb/_用户名_。

日志文件命名格式

日志文件命名格式为：

• 工具名-日志创建时间.log
• 工具名-日志创建时间-current.log

其中，“工具名-日志创建时间.log”是历史日志文件，“工具名-日志创建时间-current.log”是当前日志文件。

如果日志大小超过16MB，在下一次调用该工具时，会重命名当前日志文件为历史日志文件，并以当前时间生成新的当前日志文件。

例如将“gs_guc-2015-01-16_183728-current.log”重命名为“gs_guc-2015-01-16_183728.log”，然后重新生成“gs_guc-2015-01-17_142216-current.log”。

维护建议

建议定时对过期的日志文件进行转储，以避免大量日志占用太多的磁盘空间和避免重要日志丢失。

审计日志

审计功能开启时会不断产生大量的审计日志，占用磁盘空间。用户可以根据磁盘空间的大小设置审计日志维护策略。

关于如何设置审计日志维护策略请参见《数据库安全管理》中设置数据库审计 > 维护审计日志”章节。

WAL日志

预写式日志WAL（Write Ahead Log，也称为Xlog）是实现事务日志的标准方法，对数据文件（表和索引的载体）持久化修改之前必须先持久化相应的日志。如果要修改数据文件，必须是在这些修改操作已经记录到日志文件之后才能进行修改，即在描述这些变化的日志记录刷新到永久存储器之后。在系统崩溃时，可以使用WAL日志对MogDB进行恢复操作。

日志文件存储路径

以一个数据库节点为例，默认在/mogdb/data/data_dn/pg_xlog目录下。

其中/mogdb/data/data_dn代表MogDB节点的数据目录。

日志文件命名格式

日志文件以段文件的形式存储的，每个段为16MB，并分割成若干页，每页8KB。对WAL日志的命名说明如下：一个段文件的名称由24个十六进制组成，分为三个部分，每个部分由8个十六进制字符组成。第一部分表示时间线，第二部分表示日志文件标号，第三部分表示日志文件的段标号。时间线由1开始，日志文件标号和日志文件的段标号由0开始。

例如，系统中的第一个事务日志文件是000000010000000000000000。

说明: 这些数字一般情况下是顺序增长使用的（要把所有可用数字都用光也需要非常长的时间），但也存在循环使用的情况。

日志内容说明

WAL日志的内容取决于记录事务的类型，在系统崩溃时可以利用WAL日志进行恢复。

默认配置下，MogDB每次启动时会先读取WAL日志进行恢复。

维护建议

WAL日志对数据库异常恢复有重要的作用，建议定期对WAL日志进行备份。

性能日志

性能日志主要关注外部资源的访问性能问题。性能日志指的是数据库系统在运行时检测物理资源的运行状态的日志，在对外部资源进行访问时的性能检测，包括磁盘等外部资源的访问检测信息。在出现性能问题时，可以借助性能日志及时的定位问题发生的原因，能极大地提升问题解决效率。

日志文件存储路径

数据库节点的性能日志目录在“$GAUSSLOG/gs_profile”中各自对应的目录下。

日志文件命名格式

数据库节点的性能日志的命名规则：

postgresql-创建时间.prf

默认情况下，每日0点或者日志文件大于20MB或者数据库实例（数据库节点）重新启动后，会生成新的日志文件。

日志内容说明

数据库节点每一行日志内容的默认格式：

主机名称+日期+时间+实例名称+线程号+日志内容。