PG数据库管理-配置文件 postgresql.conf 参数文件管理
一、前言
PostgreSql 初始化完成后,在 PGDATA 下生成 postgresql.conf 配置文件,在不做任何更改的情况下,数据库初始化完成后,就可以顺利启动,查看该配置文件可发现,绝大多数配置参数都被注释掉了,它们默认被内置到了数据库中,仅剩下几个参数没有被注释掉,被系统重写了(数据库版本不同,重写参数可能不同),如 pg 12.4 中被重写的了如下几个参数。测试环境使用可以采用默认参数,但在生产中使用就需要对默认参数进行一些优化配置了,参考了阿里云最佳实验和 pg 官方手册学习整理了生产环境中可使用的配置。
select pg_reload_conf();
查看配置文件:
\h show
show config_file
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name LIKE '%wal%'; -- 替换关键词
系统视图:pg_settings;
postgres=# \d pg_settings;
View "pg_catalog.pg_settings"
Column | Type | Collation | Nullable | Default
-----------------+---------+-----------+----------+---------
name | text | | |
setting | text | | |
unit | text | | |
category | text | | |
short_desc | text | | |
extra_desc | text | | |
context | text | | |
vartype | text | | |
source | text | | |
min_val | text | | |
max_val | text | | |
enumvals | text[] | | |
boot_val | text | | |
reset_val | text | | |
sourcefile | text | | |
sourceline | integer | | |
pending_restart | boolean | | |
postgres=#
pg_settings中context列的含义
在PostgreSQL的系统视图pg_settings中,context列用于描述配置参数的生效范围或修改方式。该列的值决定了参数何时生效、是否需要重启数据库实例或会话重载等操作。以下是常见的context值及其含义:
internal
表示参数为只读参数,通常由PostgreSQL内部初始化时固定设置,无法通过用户配置修改。例如编译时决定的参数(如块大小)。
postmaster
此类参数需修改postgresql.conf文件后重启PostgreSQL服务(即重启postmaster进程)才能生效。例如shared_buffers、max_connections等核心参数。
sighup
修改后需向postmaster进程发送SIGHUP信号(或执行pg_reload_conf())重载配置,无需重启服务。例如log_min_messages。
postgres=# select pg_reload_conf();
superuser
仅超级用户可在会话中通过SET命令修改,影响当前会话或事务。例如work_mem。
user
普通用户可在会话中通过SET命令修改,仅影响当前会话。例如search_path。
backend
参数在后台进程启动时初始化,通常无法动态修改。例如DateStyle。
如何查看和修改参数
查询所有参数及其context值:
SELECT name, context, unit, setting, short_desc
FROM pg_settings
ORDER BY context;
动态修改参数(适用于superuser或user级别的参数):
SET work_mem = '16MB'; -- 仅当前会话生效
ALTER SYSTEM SET log_min_messages = 'warning'; -- 写入配置文件,需重载或重启
注意事项
- 修改
postmaster级别的参数后,必须重启数据库服务。 - 通过
ALTER SYSTEM SET会将修改写入postgresql.auto.conf,优先级高于postgresql.conf。 - 使用
pg_file_settings视图可检查配置文件的加载状态。
max_connections = 100
shared_buffers = 128MB
dynamic_shared_memory_type = posix
max_wal_size = 1GB
min_wal_size = 80MB
log_timezone = 'PRC'
datestyle = 'iso, mdy'
timezone = 'PRC'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
二、配置脚本
如下脚本,根据实际环境更改 shared_buffers、effective_cache_size、 log_directory 几个参数即可。
#connection control
listen_addresses = '*'
max_connections = 2000
superuser_reserved_connections = 10尝试在postgresql.conf 文件中添加idle_in_transaction_session_timeout参数控制,参数单位为毫秒idle_in_transaction_session_timeout=30000
假设我们有一个在PostgreSQL数据库中与一个长时间运行的查询保持连接的应用程序。为了确保连接的有效性并避免空闲连接被关闭,我们可以启用tcp_keepalives设置。
tcp_keepalives_idle = 60
tcp_keepalives_interval = 10
tcp_keepalives_count = 10
password_encryption = md5释放空闲链接
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state='idle';
#memory management
shared_buffers = 16GB #推荐操作系统物理内存的1/4
max_prepared_transactions = 2000
work_mem = 8MB
maintenance_work_mem = 2GB
autovacuum_work_mem = 1GB
dynamic_shared_memory_type = posix
max_files_per_process = 24800
effective_cache_size = 32GB #推荐操作系统物理内存的1/2#write optimization
bgwriter_delay = 10ms
bgwriter_lru_maxpages = 1000
bgwriter_lru_multiplier = 10.0
bgwriter_flush_after = 512kB
effective_io_concurrency = 1
max_worker_processes = 256
max_parallel_maintenance_workers = 6
max_parallel_workers_per_gather = 0
max_parallel_workers = 28# -----------------------------------------------------------------------------
# WAL 核心配置
# -----------------------------------------------------------------------------# 1. WAL 写入同步策略 (最关键的性能开关)
fsync=on
# on (默认): 每次事务提交都刷盘,最安全,但写性能最差。
# off: 操作系统决定何时刷盘,性能极高,但 OS 崩溃可能丢失最近几秒数据。
# local: 本地事务提交不强制刷盘,但主从复制时等待备库确认。
# 推荐: 生产环境通常保持 'on'。如果追求极致性能且能容忍少量数据丢失,可设为 'off' 或 'local' (如果有备库)。
wal_level = replica # 必须至少为 'replica' 才能支持主从复制或物理备份
synchronous_commit = on # 建议保持 'on'。若设为 'off' 可提升写性能约 2-3 倍,但有丢数据风险。# 2. WAL 文件大小与数量
# wal_segment_size 通常在编译时确定 (PG18 默认为 16MB),不可动态修改。
# max_wal_size: WAL 文件总大小上限。超过后触发检查点。
# 推荐: 设置为内存的 10%-20%,或者根据写入量调整。太小会导致频繁检查点,太大会延长崩溃恢复时间。
max_wal_size = 2GB # 默认通常是 1GB,高写入系统建议调大到 2GB-4GB# min_wal_size: WAL 文件保留的最小数量。
# 推荐: 设置为 max_wal_size 的 10%-20%,避免频繁创建/删除文件。
min_wal_size = 512MB # 默认 80MB,建议调大以减少文件IO抖动# 3. 检查点 (Checkpoint) 调优
# checkpoint_timeout: 两次自动检查点的最大时间间隔。
checkpoint_timeout = 15min # 默认 5min。增大此值可减少检查点频率,提升写入性能,但崩溃恢复变慢。# checkpoint_completion_target: 检查点完成的目标时间比例 (0.0 - 1.0)。
# 越接近 1.0,检查点越平滑,IO 越均匀;越小则越突击。
checkpoint_completion_target = 0.9 # 默认 0.9,保持即可,让检查点尽量平滑 spread out# 4. WAL 写入缓冲
# wal_buffers: WAL 数据在共享内存中的缓冲区大小。
# 推荐: -1 表示自动设置为 shared_buffers 的 3% (通常足够)。
wal_buffers = -1
#log optimization
log_destination = 'csvlog'
logging_collector = on
log_directory = '/pg12.4/logs' # 日志存放路径,提前规划在系统上创建好
log_filename = 'postgresql-%a.log'
log_file_mode = 0600
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 1GB#audit settings
log_min_duration_statement = 5s
log_checkpoints = on
log_connections = on
log_disconnections = on
log_error_verbosity = verbose
log_line_prefix = '%m [%p] %q %u %d %a %r %e '
log_statement = 'ddl'
log_timezone = 'PRC'
track_io_timing = on
track_activity_query_size = 2048#autovacuum
autovacuum = on
vacuum_cost_delay = 0
old_snapshot_threshold = 6h
log_autovacuum_min_duration = 0
autovacuum_max_workers = 8
autovacuum_vacuum_scale_factor = 0.02
autovacuum_analyze_scale_factor = 0.01
autovacuum_freeze_max_age = 1200000000
autovacuum_multixact_freeze_max_age = 1250000000
autovacuum_vacuum_cost_delay = 0ms#system environment
datestyle = 'iso, mdy'
timezone = 'Asia/Shanghai'
lc_messages = 'en_US.utf8'
lc_monetary = 'en_US.utf8'
lc_numeric = 'en_US.utf8'
lc_time = 'en_US.utf8'
default_text_search_config = 'pg_catalog.english'
三、参数说明
3.1 连接设置
listen_addresses:指定服务器在哪些 TCP/IP 地址上监听客户端连接,默认值是localhost,只允许本地连接。
max_connections:决定数据库的最大并发连接数,默认值通常是 100 个连接,如果内核设置不支持(initdb时决定),可能会比这个数少。
superuser_reserved_connections:为超级用户保留的连接数,默认是 3,不能大于max_connections。
3.2 内存设置
shared_buffers:数据库服务器使用的共享内存大小,默认值为128MB。若内核不支持(由initdb决定),该值可能更小,但最小不得低于128KB。推荐设置为系统内存的25%。由于PostgreSQL同时依赖操作系统缓存,若设置超过系统内存40%可能导致性能下降。
effective_cache_size:如果是pg专用服务器,也可以考虑设置为RAM*0.8。此参数只影响执行计划评估,不实际分配内存。
max_prepared_transactions:控制同时处于"prepared"状态的最大事务数。默认值为0表示禁用该功能。如需使用预备事务,建议将此参数设置为不小于max_connections的值。
work_mem:单个查询操作(如排序或哈希表)可用的最大内存,默认4MB。影响排序操作(ORDER BY、DISTINCT、归并连接)和哈希操作(哈希连接、哈希聚集、IN子查询处理)。
maintenance_work_mem:维护操作(VACUUM、CREATE INDEX等)的最大内存,默认64MB。增大此值可提升数据库维护和恢复操作的性能。
autovacuum_work_mem:单个自动清理进程的最大内存,默认-1表示继承maintenance_work_mem的值。建议单独配置,避免与维护操作争抢资源。
dynamic_shared_memory_type:指定共享内存管理方式,可选:
- posix(POSIX共享内存)
- sysv(System V共享内存)
- windows(Windows共享内存)
- mmap(内存映射文件) 平台默认采用首个支持的方式。mmap方式因性能问题通常不推荐使用,除非其他方式不可用或pg_dynshmem位于RAM磁盘。
3.3 IO设置
后台写入相关参数
bgwriter_delay:控制后台写入器活动轮次之间的延迟时间(默认200ms)。每轮写入操作完成后,写入器会休眠指定时长。当缓冲池没有脏缓冲区时,写入器会进入更长休眠。
bgwriter_lru_maxpages:限制每轮后台写入器最多可写出的缓冲区数量(默认100)。设为0将禁用后台写入功能。
bgwriter_lru_multiplier:用于计算下一轮所需缓冲区数量的乘数因子(默认2.0)。该值与最近所需缓冲区的平均值相乘得出预测值。写入器会持续写出脏缓冲区直到有足够干净缓冲区可用(不超过bgwriter_lru_maxpages限制)。值设为1.0表示精确匹配预测值,更高值可为突发负载提供缓冲。
I/O 和并行处理参数
effective_io_concurrency:控制PostgreSQL可同时发起的I/O请求数(默认1)。取值范围0-1000,0表示禁用异步I/O。机械硬盘建议保持默认,SSD/NVMe建议设为200。
max_worker_processes:系统支持的最大后台进程数(默认8)。调整时需同步考虑max_parallel_workers等相关参数。
max_parallel_workers:系统支持的最大并行工作进程数(默认8)。注意该值不能超过max_worker_processes。
max_parallel_maintenance_workers:单条维护命令可使用的最大并行数(默认2)。当前仅支持B-树索引创建和VACUUM(不含FULL选项)。
max_parallel_workers_per_gather:单次查询允许的最大并行数(默认2)。设为0将禁用并行查询。
3.4 日志log设置
WAL (REDO)相关参数
wal_level 参数概述
wal_level是PostgreSQL中的一个重要配置参数,用于控制WAL(Write-Ahead Logging)日志的详细程度。WAL是PostgreSQL实现事务持久性和数据恢复的核心机制,通过调整wal_level可以满足不同场景下的需求,如主从复制、逻辑解码等。
wal_level参数支持以下三种级别:
-
minimal:仅写入崩溃恢复所需的最基本WAL信息。此级别不支持归档(archive_mode)或流复制(streaming replication)。
-
replica:在
minimal基础上增加支持WAL归档和流复制所需的信息。这是默认值,适用于大多数主从复制场景。 -
logical:在
replica基础上进一步添加逻辑解码所需的信息。启用此级别后,可以使用逻辑复制或第三方工具(如Debezium)捕获数据变更。
修改wal_level需要编辑PostgreSQL的配置文件(postgresql.conf)并重启数据库实例。例如:
动态调整wal_level从低级别到高级别(如minimal→replica)无需重启,但反向调整(如logical→replica)必须重启。
wal_compression:控制是否压缩WAL中的完整页面镜像(默认off)。仅当full_page_writes开启或基础备份期间生效。需超级用户权限修改,可减少WAL空间占用但增加CPU开销。
wal_writer_delay:指定WAL写入器刷写间隔(默认200ms)。写入器在刷写后会休眠指定时长,除非被异步提交事务唤醒。
commit_delay:增加WAL刷写前的延迟时间。当系统负载高且有至少commit_siblings个活动事务时,可提高组提交吞吐量。若fsync禁用则不会执行延迟。
checkpoint_timeout:自动WAL检查点间的最长间隔(默认5分钟)。合理范围30秒至1天,增大此值会增加崩溃恢复时间。
max_wal_size:自动检查点间允许的WAL最大尺寸(默认1GB)。此为软限制,特殊情况可能超额。
min_wal_size:WAL用量低于此值时,旧文件会被回收而非删除(默认80MB)。确保保留足够WAL空间应对高峰需求。
archive_mode:控制WAL归档行为。除off外还有on和always模式。always模式会在归档恢复或备库模式下仍启用归档器。wal_level为minimal时不可启用。
max_replication_slots:服务器支持的复制槽最大数量(默认10)。要求wal_level至少为replica。
synchronous_commit 参数
单实例环境
- on(默认):事务提交需等待本地WAL写入磁盘后才返回成功。安全性最高但性能有损耗。
- local:功能与on相同。
- off:事务提交不等待WAL写入即返回。宕机时可能丢失少量最新事务,适用于对准确性要求不高的高性能场景。
- on:需等待备库WAL写入磁盘(两份持久化WAL),但备库可能尚未重做。
- remote_write:仅需等待备库将WAL写入操作系统缓存(一份持久化WAL)。备库宕机时可能丢失未落盘数据。
- remote_apply:需等待备库完成WAL重做(两份持久化WAL且备库已完成重做)。事务响应时间最长
数据库运行日志参数
日志系统支持三种输出方式:stderr、csvlog和syslog。在Windows平台上还额外支持eventlog。默认输出方式为stderr,若选择csvlog则必须启用logging_collector。同时使用csvlog和stderr时,系统会生成两种格式的日志文件。
核心参数说明:
alter system set logging_collector=on;
alter system set log_directory='/home/postgres';
alter system set log_filename='postgresql-%Y-%m-%d_%H%M%S.log';
alter system set log_rotation_age='1d';
alter system set log_rotation_size= 1024000; 1G、
select pg_reload_conf();
慢查询记录日志log
ALTER SYSTEM SET log_min_duration_statement = 1000;
SELECT pg_reload_conf();
- 性能调优:识别需要优化的慢查询。
- 生产环境监控:长期跟踪潜在性能问题。
- 开发环境调试:验证查询性能是否符合预期
logging_collector通常与其他日志配置参数配合使用:
- log_directory:指定日志文件的存储目录(如
log_directory = 'pg_log')。- log_filename:定义日志文件的命名格式(如
log_filename = 'postgresql-%Y-%m-%d.log')。- log_rotation_age:设置日志文件的轮换时间(如
log_rotation_age = 1d)。- log_rotation_size:设置日志文件的最大大小(如
log_rotation_size = 10MB)。
- logging_collector
- 功能:后台进程,负责捕获stderr的日志消息并重定向至日志文件
- 默认值:OFF
- log_directory
- 功能:指定日志文件存储路径(需启用logging_collector)
- log_filename
- 功能:定义日志文件命名格式
- 默认值:postgresql-%Y-%m-%d_%H%M%S.log
- log_file_mode
- 功能:设置日志文件权限
- 默认权限:0600(仅限服务器所有者读写)
- 建议权限:0640(允许组内成员读取)
- 注意:需将日志目录设置在数据目录外才能生效
- log_truncate_on_rotation
- 功能:控制日志轮转时的处理方式
- 启用时:基于时间轮转会覆盖同名文件
- 禁用时:始终追加日志内容
- log_rotation_age
- 功能:设置单个日志文件的最大使用时长
- 默认值:24小时
- 设为0时:禁用基于时间的轮转
- log_rotation_size
- 功能:设置单个日志文件的最大容量
- 默认值:10MB
- 设为0时:禁用基于大小的轮转
- log_min_duration_statement
- 功能:记录慢SQL的阈值
- 默认值:-1(不记录)
- log_checkpoints
- 功能:记录检查点和重启点信息
- 默认值:关闭
- log_connections
- 功能:记录连接信息
- 默认值:关闭
- 注意:会话期间不可修改
- log_disconnections
- 功能:记录会话终止信息
- 默认值:关闭
- 注意:会话期间不可修改
- log_error_verbosity
- 可选值:TERSE、DEFAULT、VERBOSE
- 默认值:DEFAULT
- log_line_prefix
- 功能:定义日志行前缀内容
- 默认值:'%m [%p] '(时间戳+进程ID)
- log_statement
- 功能:控制SQL语句记录级别
- 可选值:none/ddl/mod/all
- 默认值:none
- log_timezone
- 功能:设置日志时间戳时区
- 默认值:GMT
日志文件名格式说明: %a 星期缩写(如Mon) %A 星期全称(如Monday) %b 月份缩写(如Jan) %B 月份全称(如January) %c 日期时间字符串(03/08/15 23:01:26) %d 当月第几天 %f 微秒[0,999999] %H 24小时制 %I 12小时制 %j 当年第几天[001,366] %m 月份[0,12] %M 分钟[0,59] %P 上午/下午(AM/PM) %S 秒数[0,61] %U 当年第几周(周日为第一天) %W 当年第几周(周一为第一天) %w 当周第几天[0,6](6=周日) %x 日期字符串(03/08/15) %X 时间字符串(23:22:08) %y 两位数年份(15) %Y 四位数年份(2015) %z UTC时差(本地时间为空) %Z 时区名称(本地时间为空)
日志行前缀格式说明: %a 应用名 %u 用户名 %d 数据库名 %r 远程主机:端口 %h 远程主机 %b 后端类型 %p 进程ID %t 无毫秒时间戳 %m 带毫秒时间戳 %n Unix时间戳 %i 命令类型 %e SQLSTATE错误码 %c 会话ID %l 行号(从1开始) %s 进程启动时间 %v 虚拟事务ID %x 事务ID(未分配为0) %q 非会话进程终止标记 %% 百分号
pg数据库archive归档相关日志
在PostgreSQL中,归档日志(WAL归档)是数据库备份和恢复的关键组成部分。通过配置归档模式,可以将WAL(Write-Ahead Logging)日志文件归档到指定位置,确保数据的安全性和可恢复性。
启用归档模式
修改postgresql.conf文件,设置以下参数:
wal_level = replica
archive_mode = on
archive_command = 'cp %p /path/to/archive/%f'
wal_level设置为replica或更高,确保生成足够的WAL日志。archive_mode启用归档模式。archive_command定义归档命令,将WAL日志复制到指定目录。
归档命令示例
归档命令可以根据需求定制,以下是一些常见示例:
使用cp命令:
archive_command = 'cp %p /var/lib/postgresql/archive/%f'
使用rsync命令:
archive_command = 'rsync -a %p /mnt/backup/archive/%f'
使用压缩归档:
archive_command = 'gzip -c %p > /archive/%f.gz'
检查归档状态
查询pg_stat_archiver视图,检查归档状态:
SELECT * FROM pg_stat_archiver;
archived_count显示已归档的WAL文件数量。last_archived_wal显示最后归档的WAL文件名。last_failed_wal显示最后归档失败的WAL文件名。
手动触发归档
执行以下SQL命令,手动触发WAL切换并归档:
SELECT pg_switch_wal();
清理旧归档日志
配置archive_cleanup_command自动清理旧归档日志:
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
%r表示最早需要的WAL文件名,早于该文件的日志会被清理。
归档日志恢复
使用归档日志进行时间点恢复(PITR):
- 创建
recovery.conf或修改postgresql.auto.conf: --创建recovery.conf文件或者直接使用alter system set的配置文件。restore_command = 'cp /path/to/archive/%f %p' recovery_target_time = '2023-01-01 12:00:00' - 重启PostgreSQL服务,数据库将进入恢复模式。
常见问题排查
归档失败时,检查PostgreSQL日志文件:
tail -f /var/log/postgresql/postgresql-13-main.log
- 确保归档目录存在且PostgreSQL用户有写入权限。
- 检查
archive_command是否正确配置。
通过以上配置和管理,可以确保PostgreSQL的归档日志功能正常运行,为数据备份和恢复提供保障。
3.5 autovacuum 设置
autovacuum:控制服务器是否运行自动清理启动器后台进程。默认为开启,不过要自动清理正常工作还需要启用 track_counts(默认启用)。 该参数只能在postgresql.conf文件或服务器命令行中设置,通过更改表存储参数可以为表禁用自动清理。 注意即使该参数被禁用,系统也会在需要防止事务ID回卷时发起清理进程。
old_snapshot_threshold:设置可以使用查询快照的最小时间,以规避使用快照时出现“snapshot too old” 错误的风险,超过此阈值时间的数据将可以被清除,这可以有助于阻止长时间使用的快照造成的快照膨胀,默认值为 -1(禁用此功能),实际上将快照的时限设置为无穷大。
log_autovacuum_min_duration:超过这个时间阀值的自动清理动作都会被日志记录,将该参数设置为0会记录所有的自动清理动作,默认值为 -1 (禁用对自动清理动作的记录)。 此外,当该参数被设置为除-1外的任何值时, 如果一个自动清理动作由于一个锁冲突或者被并发删除的关系而被跳过,将会为此记录一个消息。 开启这个参数对于追踪自动清理活动非常有用,但是可以通过更改表的存储 参数为个别表覆盖这个设置。
autovacuum_max_workers:设置能同时运行的自动清理进程(除了自动清理启动器之外)的最大数量,默认值为3。
autovacuum_vacuum_scale_factor:触发 vacuum 自动清理操作的 dml 比例,默认值 0.2,当表上的 dml 操作占据表数据量的 20% 时触发 vacuum 自动清理操作,为防止数据量较小的表被频繁清理,与 autovacuum_vacuum_threshold(改参数默认值为 50,表中至少有 50 条数据发成 dml 操作时,才会触发 vacuum 自动清理) 参数共同作用。
autovacuum_analyze_scale_factor:触发 vacuum 自动 analyze 操作的 dml 比例,默认值 0.1,当表上的 dml 操作占据表数据量的 10% 时触发 vacuum 自动 analyze 操作,为防止数据量较小的表被频繁 analyze,与 autovacuum_analyze_threshold(改参数默认值为 50,表中至少有 50 条数据发成 dml 操作时,才会触发 vacuum 自动 analyze) 参数共同作用。
autovacuum_freeze_max_age:某表的pg_class.relfrozenxid的最大值,如果超出此值则重置xid,默认值为2亿,注意即便自动清理被禁用,系统也将发起自动清理进程来阻止回卷。
autovacuum_multixact_freeze_max_age:某表的pg_class.relminmxid最大值,如果超出此值则重置xid,默认值为4亿,注意即便自动清理被禁用,系统也将发起自动清理进程来阻止回卷。
autovacuum_vacuum_cost_delay:指定用于自动 VACUUM 操作中的代价延迟值,如果指定-1(默认值),则使用 vacuum_cost_delay 值(默认值 2ms)。
补充说明
由于生产环境中每张业务表作用、使用频繁程度、“死元组 ”的增长速度等都不同,建议结合业务情况,对重要的生产业务表单独进行设置参数值。
dml 操作特别频繁的表,做类似如下设置:
ALTER TABLE mytable SET (autovacuum_vacuum_scale_factor = 0.01);
索引字段,dml 操作特别频繁的表,做类似如下设置:
ALTER TABLE mytable SET (fillfactor=80);
仅插入数据库表,做类似如下设置:
ALTER TABLE mytable SET (autovacuum_freeze_max_age = 10000000);
standby.signal 文件的作用
standby.signal 是 PostgreSQL 数据库中的一个信号文件,用于控制数据库实例的状态转换。当该文件存在于 PostgreSQL 的数据目录(data_directory)中时,数据库会进入“standby mode”(备用模式),通常用于流复制或逻辑复制场景。以下是关于该文件的详细信息:
文件功能
- 触发备用模式:当
standby.signal文件存在时,PostgreSQL 实例会以备用服务器(standby)模式启动,自动从主服务器(primary)接收 WAL(Write-Ahead Log)日志并应用。 - 与
recovery.signal的区别:在 PostgreSQL 12 及更高版本中,standby.signal和recovery.signal被明确区分。standby.signal表示实例为长期运行的备用服务器,而recovery.signal表示实例处于一次性恢复状态(如 PITR)。
使用方法
-
创建文件
在 PostgreSQL 的数据目录中创建空文件standby.signal:touch $PGDATA/standby.signal -
配置复制参数
需在postgresql.conf中配置流复制相关参数,例如:primary_conninfo = 'host=primary_server user=replication password=xxx port=5432' restore_command = 'cp /path/to/archive/%f %p' -
重启实例
文件创建后,重启 PostgreSQL 实例以进入备用模式:pg_ctl restart -D $PGDATA
注意事项
- 文件权限:确保
standby.signal文件对 PostgreSQL 运行用户可读。 - 版本兼容性:PostgreSQL 10 及更早版本使用
recovery.conf文件配置备用模式,而非standby.signal。 - 自动删除:当备用服务器提升为主服务器时(通过
pg_promote()或pg_ctl promote),standby.signal文件会被自动删除。
验证备用状态
通过查询数据库状态确认是否成功进入备用模式:
SELECT pg_is_in_recovery();
返回 true 表示当前为备用服务器。
故障排查
- 日志检查:若备用模式未生效,查看 PostgreSQL 日志文件(
logfile)排查错误。 - 文件冲突:确保数据目录中不存在
recovery.signal或旧的recovery.conf文件(仅限 PostgreSQL 12+)。
通过以上步骤,可以正确配置并使用 standby.signal 文件管理 PostgreSQL 备用服务器。
DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐



所有评论(0)