日志参考

日志类型简介

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

日志类型

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

表 1 日志类型

类型

说明

系统日志

数据库系统进程运行时产生的日志,记录系统进程的异常信息。

操作日志

通过客户端工具(例如gs_guc)操作数据库时产生的日志。

Trace日志

通过gstrace工具指定启动trace功能的数据库实例后,会记录大量的Trace日志。这些日志可以用来分析数据库的异常信息。

黑匣子日志

数据库系统崩溃的时候,通过故障现场堆、栈信息可以分析出故障发生时的进程上下文,方便故障定位。黑匣子具有在系统崩溃时,dump出进程和线程的堆、栈、寄存器信息的功能。

审计日志

开启数据库审计功能后,将数据库用户的某些操作记录在日志中,这些日志称为审计日志。

WAL日志

又称为REDO日志,在数据库异常损坏时,可以利用WAL日志进行恢复。由于WAL日志的重要性,所以需要经常备份这些日志。

性能日志

数据库系统在运行时检测物理资源的运行状态的日志,在对外部资源进行访问时的性能检测,包括磁盘等外部资源的访问检测信息。

系统日志

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

日志文件存储路径

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

openGauss安装卸载时产生的日志放在安装卸载脚本的同级目录下。

日志文件命名格式

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

    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+仲裁细节

操作日志

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

日志文件存储路径

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

日志文件命名格式

日志文件命名格式为:

  • 工具名-日志创建时间.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日志对openGauss进行恢复操作。

日志文件存储路径

以一个数据库节点为例,默认在“/gaussdb/data/data_dn/pg_xlog”目录下。

其中“/gaussdb/data/data_dn”代表openGauss节点的数据目录。

日志文件命名格式

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

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

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

日志内容说明

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

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

维护建议

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

性能日志

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

日志文件存储路径

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

日志文件命名格式

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

postgresql-创建时间.prf

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

日志内容说明

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

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

日志翻译

openGauss的日志默认为英文,但也支持将数据库日志翻译为其他语言。目前支持翻译的目标语言有中文。

使用步骤

  1. 安装gettext工具包

  2. 后台编译时添加--enable-nls参数

    ./configure --enable-nls="zh_CN" --gcc-version=7.3.0 CC=g++ CFLAGS='-O0' --prefix=$GAUSSHOME --3rd=$BINARYLIBS --enable-debug --enable-cassert --enable-thread-safety --with-readline --without-zlib && make && make install
    

    --enable-nls 后如果不跟参数,则表示支持当前能支持的所有的语言。程序根据终端环境变量LANG自动切换help和主线程等打印语言,gsql会话中设置lc_messages参数变更当前会话日志语言,如lc_messages = 'zh_CN.UTF-8'表示使用中文,配置文件中修改则全局生效

  3. 生成翻译文件

    一般无须使用,仅针对新的项目

    make init-po
    
  4. 更新翻译文件

    make update-po
    

    该操作会将已有的zh_CN.po合并到zh_CN.po.new。手动修改 src/gausskernel/po/zh_CN.po.new中新增英文对应的翻译,其中fuzzy字样表示不确定的合并,需要修改。修改完成后将zh_CN.po.new 重命名为zh_CN.po并提交,然后执行:

    make install
    

    注意: 如果翻译后语言逻辑上要求多个格式控制符交换位置,后台依赖的旧版本secure c库不支持将格式化字符串修改为 %2$s %1$s 的方式交换。最新的 secure c 库支持。注意:需要重新编译三方库中的 secure c 库。 如果系统环境变量LC_CTYPELC_MESSAGES和 guc 参数 lc_messages 指定的字符集不匹配,会导致gaussdb 主线程和后台线程日志出现乱码。为避免这一情况,检测到系统环境变量LC_CTYPELC_MESSAGES和 guc 参数 lc_messages 指定的字符集不匹配时将自动关闭翻译开关。 如果数据库编码不是 utf-8,则应该设置 LC_MESSAGES 环境变量 和 guc 参数 lc_messages 为相应值,关闭翻译,否则用户数据中的非 utf-8/ascii 编码会导致日志文件乱码。 gettext 函数存在翻译缓存,不管翻译成功还是翻译失败(比如输出乱码),后续相同英文的翻译都会使用该缓存结果。 如果数据库编码为 gbk ,将用户输入的gbk格式的数据写入日志文件后,日志文件中同时存在 gbk 和 utf-8 的字符,会导致乱码。 增加guc参数 enable_nls ,翻译api影响性能时(日志级别较低且并发高)关闭即可避免性能损耗。该开关仅控制 elog 日志。

意见反馈
编组 3备份
    openGauss 2024-07-20 01:00:34
    取消