PostgreSQL 服务器日志 pg_log

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
日志服务 SLS,月写入数据量 50GB 1个月
简介: 10.0版本PostgreSQL,存在三种日志WAL日志,即重做日志,一般不可读日志对应目录为 PGDATA/pgxlogPGDATA/pg_clog数据库运行日志日志对应目录为$PGDATA/pg_log前两种日志,虽然仍然非常重要,但却是不可读的,我们日常使用不多。

10.0版本PostgreSQL,存在三种日志

WAL日志,即重做日志,一般不可读

  • 日志对应目录为 $PGDATA/pg_xlog

事务提交日志,记录的是事务的元数据

  • 日志对应目录为 $PGDATA/pg_clog

数据库运行日志

  • 日志对应目录为$PGDATA/pg_log

前两种日志,虽然仍然非常重要,但却是不可读的,我们日常使用不多。
本次重点说明第三种日志。


数据库运行日志的相关配置

1.logging_collector = on/off
是否将日志重定向至文件中,默认是off(该配置修改后,需要重启DB服务)

2.log_directory = 'pg_log' ---- 日志文件目录,默认是PGDATA的相对路径,即{PGDATA}/pg_log,也可以改为绝对路径

3.log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' ---- 日志文件命名形式,其中格式化格式与linux date格式化相同。

4.log_rotation_age = 1d ---- 单个日志文件的生存期,默认1天,在日志文件大小没有达到log_rotation_size时,一天只生成一个日志文件

5.log_rotation_size = 10MB ---- 单个日志文件的大小,如果时间没有超过log_rotation_age,一个日志文件最大只能到10M,否则将新生成一个日志文件。

6.log_truncate_on_rotation = off ---- 当日志文件已存在时,该配置如果为off,新生成的日志将在文件尾部追加,如果为on,则会覆盖原来的日志。

7.log_lock_waits = off ---- 控制当一个会话等待时间超过deadlock_timeout而被锁时是否产生一个日志信息。在判断一个锁等待是否会影响性能时是有用的,缺省是off。

8.log_duration = off ---- 记录每条SQL语句执行完成消耗的时间,将此配置设置为on,用于统计哪些SQL语句耗时较长。

9.log_statement
设置日志记录内容--log_statement:none, ddl, mod, and all 。

None表示不记录(默认项)

ddl记录所有数据定义命令,比如CREATE,ALTER,和DROP语句。

mod记录所有ddl语句,加上数据修改语句INSERT,UPDATE等。

all记录所有执行的语句,将此配置设置为all可跟踪整个数据库执行的SQL语句,但会对数据库性能产生较大影响,生产环境不建议配置此值。

postgres=# alter system set log_statement=ddl;
ALTER SYSTEM
# show log_statement仍然显示原来的设置,需要退出,执行pg_ctl reload才能生效
postgres=# show log_statement;
 log_statement 
---------------
 mod
(1 row)

postgres=# \q
[postgres@localhost data]$ pg_ctl reload
server signaled
[postgres@localhost data]$ psql
psql (10.7)
Type "help" for help.

postgres=# show log_statement;
 log_statement 
---------------
 ddl
(1 row)

postgres=#
AI 代码解读

注:此处未记录select查询语句(log_min_duration_statement=-1 此处为默认值)。当同时设置log_statement=’mod’和log_min_duration_statement=0后,也会记录select。

highgo=#alter system set log_statement=mod;

ALTERSYSTEM

highgo=#alter system set log_min_duration_statement=0;

ALTERSYSTEM

highgo=#\q

[highgo@sourcedbdata]$ pg_ctl reload

serversignaled
AI 代码解读

10.log_min_duration_statement = -1 # -1 is disabled, 0 logs all statements and their durations, > 0 logs only statements running at least this number of milliseconds
-1表示不可用,0将记录所有SQL语句和它们的耗时,>0只记录那些耗时超过(或等于)这个值(ms)的SQL语句。个人更喜欢使用该配置来跟踪那些耗时较长,可能存在性能问题的SQL语句。虽然使用log_statement和log_duration也能够统计SQL语句及耗时,但是SQL语句和耗时统计结果可能相差很多行,或在不同的文件中,但是log_min_duration_statement会将SQL语句和耗时在同一行记录,更方便阅读

11.log_connections = off ----是否记录连接信息(修改后需要重启数据库)

12.log_disconnections = off ---- 是否记录连接断开日志

13.log_line_prefix = '%m %p %u %d %r ' ---- 日志输出格式(%m,%p实际意义配置文件中有解释),可根据自己需要设置(能够记录时间,用户名称,数据库名称,客户端IP和端口,方便定位问题)

#log_line_prefix = '%m [%p] ' 
# special value
# %a = application name
#   %u = user name
#   %d = database name
#   %r = remote host and port
#   %h = remote host
#   %p = process ID
#   %t = timestamp without milliseconds
#   %m = timestamp with millisecond#   
#   %n = timestamp with milliseconds (as a Unix epoch)
#   %i = command tag
#   %e = SQL state
AI 代码解读

14.log_timezone = 'Asia/Shanghai' ---- 日志时区,最好和服务器设置同一个时区,方便问题定位

--视图pg_timezone_names保存了所有可供选择的时区

select * from pg_timezone_names;

服务器时区设置
[root@localhost ~]# cp -rf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
打赏
0
0
0
0
2
分享
相关文章
【赵渝强老师】PostgreSQL的服务器日志文件
本文介绍了PostgreSQL数据库的物理存储结构,重点讨论了服务器日志文件。通过`pg_ctl`命令启动PostgreSQL实例时,使用`-l`参数指定日志文件位置,记录数据库启动、运行及关闭过程中的关键信息。附有相关视频讲解和日志文件示例。
187 0
【Azure App Service】分享使用Python Code获取App Service的服务器日志记录管理配置信息
本文介绍了如何通过Python代码获取App Service中“Web服务器日志记录”的配置状态。借助`azure-mgmt-web` SDK,可通过初始化`WebSiteManagementClient`对象、调用`get_configuration`方法来查看`http_logging_enabled`的值,从而判断日志记录是否启用及存储方式(关闭、存储或文件系统)。示例代码详细展示了实现步骤,并附有执行结果与官方文档参考链接,帮助开发者快速定位和解决问题。
82 23
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
215 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
Tomcat log日志解析
理解和解析Tomcat日志文件对于诊断和解决Web应用中的问题至关重要。通过分析 `catalina.out`、`localhost.log`、`localhost_access_log.*.txt`、`manager.log`和 `host-manager.log`等日志文件,可以快速定位和解决问题,确保Tomcat服务器的稳定运行。掌握这些日志解析技巧,可以显著提高运维和开发效率。
127 13
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
94 5
图解MySQL【日志】——Redo Log
简单聊聊MySQL的三大日志(Redo Log、Binlog和Undo Log)各有什么区别
在MySQL数据库管理中,理解Redo Log(重做日志)、Binlog(二进制日志)和Undo Log(回滚日志)至关重要。Redo Log确保数据持久性和崩溃恢复;Binlog用于主从复制和数据恢复,记录逻辑操作;Undo Log支持事务的原子性和隔离性,实现回滚与MVCC。三者协同工作,保障事务ACID特性。文章还详细解析了日志写入流程及可能的异常情况,帮助深入理解数据库日志机制。
154 0
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
164 7
MySQL事务日志-Undo Log工作原理分析
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
103 0