TIL 项目实战：为 PostgreSQL 服务器开启数据库活动日志（logging

文档
教程
知识库

【免费下载链接】til

:memo: Today I Learned

项目地址：https://gitcode.com/gh_mirrors/ti/til

本篇指南围绕 TIL 仓库中的 PostgreSQL 运维实践，讲解如何通过postgresql.conf中的logging_collector选项为 PostgreSQL 服务器开启数据库活动日志，涵盖配置文件定位、参数修改、服务器重启与日志查看的完整流程。读完本文，你将掌握一套从零启用 PostgreSQL 日志、并以会话级参数细粒度调整日志行为（如记录全部 SQL）的可落地方法。

为什么需要显式开启数据库日志

PostgreSQL 默认情况下并不会把数据库活动写入持久化的日志文件。要让服务器产生可供排查的日志，必须先确认并开启logging_collector这一核心开关——它是所有日志落盘行为的前提。从仓库中的另一篇相关笔记 include-all-queries-in-the-log-file 也可以看到，任何更细粒度的日志参数（如log_statement）生效的前提，都是"确保已通过logging_collector开启了日志收集"。

logging_collector默认处于off状态，且它是一个"需要重启服务器才能生效"（change requires restart）的服务器级参数，因此不能在psql会话中动态修改，必须走"改配置 → 重启 → 验证"的流程。

第一步：在 psql 会话中定位配置文件

配置文件的位置因安装方式而异（如 Homebrew、asdf、官方安装包）。最稳妥的做法是直接询问 PostgreSQL 本身：在psql会话中执行show config_file;，即可获得当前实例实际加载的postgresql.conf绝对路径：

> show config_file; config_file --------------------------------------------------------------------- /Users/jbranchaud/.asdf/installs/postgres/12.3/data/postgresql.conf (1 row)

仓库中的 find-the-location-of-postgres-config-files 记录了一个关键细节：postgresql.conf所在目录通常还存放着pg_hba.conf等其他配置文件的集合，因此定位到该目录后，后续所有服务器配置文件的查找都能顺藤摸瓜完成。

如果需要更进一步了解数据存放位置，可以在同一个 psql 会话中执行show data_directory;查看集群数据目录的绝对路径（见 find-the-data-directory），该目录与配置文件目录通常是一致的。

第二步：修改 postgresql.conf 开启 logging_collector

用编辑器打开上一步得到的postgresql.conf，搜索logging_collector相关行。该行默认被注释掉且值为off，需要取消注释并把值改为on：

# This is used when logging to stderr: logging_collector = on # Enable capturing of stderr and csvlog # into log files. Required to be on for # csvlogs. # (change requires restart)

结合配置注释可以提炼出以下关键事实：

作用：开启后，服务器会把原本输出到stderr的日志消息捕获并写入日志文件；
csvlog 依赖：若后续想使用csvlog格式（结构化日志，便于导入分析工具），该选项必须为on，注释中明确标注了"Required to be on for csvlogs"；
生效方式：属于(change requires restart)类型的参数，修改后必须重启服务器才能加载。

第三步：使用 pg_ctl 重启服务器

由于该参数需要重启才能生效，可以使用pg_ctl配合-D指定数据目录（即上一步中配置文件所在目录）完成重启：

$ ~/.asdf/installs/postgres/12.3/bin/pg_ctl -D ~/.asdf/installs/postgres/12.3/data restart waiting for server to shut down.... done server stopped waiting for server to start... done server started

输出中的server stopped与server started分别对应优雅停机和成功启动，说明重启流程已完整走通。

补充说明：pg_ctl的-D数据目录参数在 PostgreSQL 运维中是通用入口。仓库中的 create-a-cluster-in-a-specific-data-directory 展示了如何用initdb -D <目录>初始化一个自定义数据目录的集群，随后同样通过pg_ctl -D <目录> start启动；而 check-if-the-local-server-is-running 则记录了用pg_isready判断服务器是否就绪（返回accepting connections即正常）、并用pg_ctl ... start启动未运行的服务器的做法，可作为重启前后的可用性验证手段。

第四步：按需调整日志参数并查看日志

重启完成后，日志收集已经处于开启状态。接下来即可在"服务器级"或"会话级"两个维度调整进一步的日志参数：

服务器级：再次编辑postgresql.conf调整相关log_*参数，仍需重启（或 reload）生效；
会话级：在当前psql会话中执行SET语句即时调整，不影响其他连接。

仓库中的 include-all-queries-in-the-log-file 就是一个典型的会话级应用：log_statement的默认级别是none，合法取值还包括ddl、mod和all。如果想观察某个数据库收到的全部 SQL，可以在当前会话中执行：

> set log_statement = 'all';

由于all级别非常嘈杂，作者建议在"明确需要看到所有查询"的场景下按会话临时开启，而非全局常驻。设置完成后，即可通过tail跟踪日志文件观察实时写入的查询记录。

类似的会话级参数还包括statement_timeout（语句执行超时，默认0表示不限制），详见仓库笔记 limit-execution-time-of-statements，可见"会话内 SET 即时生效、show 可验证"是 PostgreSQL 运维中调整运行时行为的一致模式。

小结

开启 PostgreSQL 数据库活动日志的完整链路可概括为三步：

用show config_file;定位postgresql.conf，确认logging_collector = on（它是 stderr 与 csvlog 日志落盘的必要开关，默认关闭）；
由于该参数标注为change requires restart，用pg_ctl -D <数据目录> restart重启服务器使配置生效；
结合服务器级与会话级log_*参数（如log_statement）定制日志粒度，并用tail跟踪日志文件验证输出。

这套流程同样适用于排查慢查询、审计数据库访问等日常场景，仓库中的相关笔记（enable-logging-of-database-activity、include-all-queries-in-the-log-file、find-the-location-of-postgres-config-files）可以相互对照阅读，形成完整的 PostgreSQL 日志运维知识闭环。