ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀，每一条都经过真实交付验证。

首页 / 资讯中心 / 正文

PostgreSQL一键安装：RPM与源码双轨制工程实践

2026/9/26 1:50:59 拓冰建站 浏览量
PostgreSQL一键安装：RPM与源码双轨制工程实践 1. 项目概述为什么“PG一键安装”不是偷懒而是工程化落地的必然选择“PG一键安装”这五个字在PostgreSQL运维圈里几乎等同于一句暗号——它背后站着的不是某个脚本而是一整套对数据库部署场景的深度理解。我从2012年开始在金融和政务系统里部署PG最早是手敲./configure --prefix/opt/pgsql --with-openssl --with-python编译一次要47分钟中间只要make报错就得翻config.log逐行查依赖缺失后来用YUM装结果CentOS 7默认仓库只提供9.2版本而业务方明确要求13.6再后来切到RPM包又遇到libicu版本冲突、systemd服务模板缺失、pg_hba.conf权限不合规等一系列“安装成功但无法启动”的经典陷阱。所谓“一键”从来不是把curl | bash当银弹而是把十年间踩过的所有坑压缩成一个可验证、可审计、可回滚的标准化动作。它解决的不是“会不会装”的问题而是“能不能在生产环境里稳定交付”的问题。关键词里的PG、PostgreSQL、RPM、源码其实对应着三条完全不同的技术路径RPM适合快速交付与合规审计源码编译适合深度定制与性能调优而“一键”必须同时兼容二者并在中间划出清晰边界。比如某省政务云项目安全规范强制要求所有软件必须基于官方源码构建RPM包但业务部门又要求2小时内完成三套测试环境部署——这时候“一键安装”就不再是效率工具而是合规与敏捷之间的唯一桥梁。它面向的不是刚学SQL的新手而是每天要处理5个以上异构环境、被安全审计和业务上线双重倒逼的DBA、SRE或交付工程师。你不需要懂C语言但必须清楚pg_config输出的INCLUDEDIR路径是否被正确写入pkgconfig你不需要背熟initdb所有参数但得知道--auth-hostmd5和--auth-localpeer在容器化场景下为何必须显式声明。这才是“PG一键安装”真正的门槛和价值。2. 核心设计逻辑RPM与源码双轨制不是妥协而是分层治理的必然结果2.1 为什么拒绝“纯脚本派”从三个真实故障看单点风险很多团队早期会用Shell脚本封装安装流程比如install_pg.sh里写死wget https://ftp.postgresql.org/pub/source/v14.5/postgresql-14.5.tar.gz看似简洁实则埋下三重雷区第一重雷网络不可控性某次金融客户现场交付因防火墙策略临时收紧脚本卡在wget环节超时而脚本未设置--timeout30和重试机制导致整个自动化流水线中断。更致命的是脚本未校验下载文件的SHA256值曾有同事误将缓存中损坏的tar包解压make阶段报syntax error near unexpected token AM_INIT_AUTOMAKE排查两小时才发现是autogen.sh脚本头被截断。第二重雷环境漂移失控同一版脚本在CentOS 7和Rocky Linux 8上表现迥异前者gcc默认4.8.5后者已升至8.5.0而PG 14.5的contrib/pg_stat_statements模块在高版本GCC下需额外加-fcommon编译标志否则make install后CREATE EXTENSION报undefined symbol: pgstat_report_stat。脚本无法自动感知这种差异只能靠人工补丁。第三重雷审计追溯断链某政务项目安全检查要求提供“软件供应链证明”需明确回答“二进制文件是否由官方源码构建”“构建环境是否隔离”。Shell脚本生成的二进制无构建日志、无签名、无SBOM软件物料清单最终被迫手工重建RPM包并补录200行构建记录。提示RPM不是“更重的包”而是带元数据的契约。它强制声明Requires: openssl-devel 1.0.2k自动触发依赖解析它的%post段能确保systemctl daemon-reload执行完毕才返回它的%files列表就是一份天然的文件完整性清单。2.2 RPM与源码的分工哲学什么该打包什么该编译“一键安装”真正的技术难点不在于如何把东西装上而在于精准划分RPM和源码的职责边界。我们团队经过37个生产环境验证形成如下铁律RPM负责“确定性交付”所有与操作系统强耦合的组件必须打入RPMpostgresql-server含initdb、pg_ctl、postgresql-contrib含pg_stat_statements、postgresql-libs含libpq.so.5。关键点在于RPM的%build阶段必须调用./configure而非直接make且--prefix必须固定为/usr/pgsql-14非/opt或/usr/local因为/usr是FHS标准路径systemd单元文件才能通过/usr/lib/systemd/system/postgresql-14.service被正确加载。我们曾因将prefix设为/opt/pgsql导致pg_ctl start报No data directory specified——因为/opt下无/var/lib/pgsql符号链接而RPM的%post脚本未处理此路径映射。源码负责“动态适配”所有需运行时决策的组件必须保留源码形态pgbackrest备份工具、wal-g云存储插件、timescaledb时序扩展。它们不打入RPM而由“一键安装”脚本在post-install阶段按需编译。例如timescaledb其cmake需检测PG的pg_config --includedir输出若RPM已预装PG 14.5则脚本自动执行cmake -DCMAKE_BUILD_TYPERelWithDebInfo -DREGRESS_CHECKSOFF -DPG_CONFIG/usr/pgsql-14/bin/pg_config ..若检测到PG 15.2则切换PG_CONFIG路径。这种动态绑定是RPM静态元数据无法实现的。交叉验证机制让RPM和源码互相守门我们在RPM的%post脚本末尾加入校验# 验证源码编译的扩展能否被PG识别 if ! /usr/pgsql-14/bin/pg_config --version | grep -q 14\.5; then echo ERROR: RPM installed PG version mismatch 2 exit 1 fi同时在源码编译脚本开头加入RPM存在性检查if ! rpm -q postgresql14-server /dev/null 21; then echo FATAL: PostgreSQL RPM not found. Install it first. 2 exit 1 fi这种双向锁机制确保任何一方的变更都不会破坏整体一致性。2.3 版本矩阵设计为什么必须放弃“最新版崇拜”网络热词里高频出现postgresql下载哪个版本暴露了一个普遍误区把“新”等同于“好”。我们在某省级医保平台遭遇过惨痛教训——上线前测试用PG 15.3一切正常正式环境因安全组要求降级到14.7结果jsonb_path_query函数行为变更导致结算报表SQL全量报错。因此“一键安装”的版本策略是场景驱动型矩阵场景类型推荐PG版本关键依据RPM构建约束金融核心交易14.11PG 14系列最长LTS支持至2027年Oracle兼容性补丁最全必须启用--with-openssl政务云信创环境13.15适配麒麟V10 SP1内核5.10.0-60.18.0.200.ky10.aarch64避免epoll_wait兼容问题--without-readline禁用readlineAI训练数据湖15.6原生支持vector类型pgvector扩展无需手动编译--with-python且Python3.9这个矩阵不是拍脑袋定的。比如政务云信创环境我们实测发现PG 14在麒麟V10 SP1上若启用readlinepsql交互模式下输入长SQL会触发SIGSEGV根源是麒麟glibc 2.28的__libc_readline函数与PG的rl_bind_key冲突。因此RPM构建时必须硬编码--without-readline并替换为libedit——这正是“一键安装”脚本在pre-build阶段自动注入的配置项。3. 实操细节拆解从RPM构建到源码编译的完整链路3.1 RPM构建用SPEC文件定义可审计的交付契约RPM的SPEC文件不是配置清单而是法律契约。以postgresql14.spec为例关键段落解析如下# 定义基础元数据审计溯源核心 Name: postgresql14 Version: 14.11 Release: 1%{?dist} Summary: PostgreSQL object-relational database system (v14) License: PostgreSQL URL: https://www.postgresql.org/ Source0: https://ftp.postgresql.org/pub/source/v%{version}/postgresql-%{version}.tar.gz # 构建时强制校验防篡改 %define sha256sum a1b2c3... # 此处为实际SHA256值每次更新必须重算 # 依赖声明精确到小版本杜绝隐式升级 BuildRequires: gcc 8.5.0 BuildRequires: openssl-devel 1.1.1k BuildRequires: python3-devel 3.6.8 Requires: systemd 219 Requires: libicu 60.2 # 构建阶段严格遵循FHS禁止污染/usr/local %build %configure \ --prefix/usr/pgsql-14 \ --sysconfdir/etc/sysconfig/pgsql \ --datadir/usr/pgsql-14/share \ --bindir/usr/pgsql-14/bin \ --libdir/usr/pgsql-14/lib \ --includedir/usr/pgsql-14/include \ --with-openssl \ --with-python \ --with-systemd \ --without-readline \ # 信创环境特供 --enable-dtrace # 安装阶段仅拷贝必要文件禁用make install-strip破坏调试符号 %install rm -rf $RPM_BUILD_ROOT make DESTDIR$RPM_BUILD_ROOT install # 强制创建符号链接解决/usr/bin/pg_ctl找不到的问题 ln -sf /usr/pgsql-14/bin/pg_ctl $RPM_BUILD_ROOT/usr/bin/pg_ctl-14 # 文件清单精确到每个配置文件权限 %files %defattr(-,root,root,-) %dir /usr/pgsql-14 %dir /usr/pgsql-14/bin %attr(0755,root,root) /usr/pgsql-14/bin/pg_ctl %attr(0755,root,root) /usr/pgsql-14/bin/initdb %config(noreplace) /etc/sysconfig/pgsql/postgresql-14 %doc /usr/pgsql-14/share/doc/README注意%config(noreplace)是关键。它确保/etc/sysconfig/pgsql/postgresql-14在RPM升级时不被覆盖保留用户自定义的PGDATA路径。我们曾因漏写此标记导致客户修改的PGDATA/data/pg14被重置为默认/var/lib/pgsql/data引发服务中断。构建命令必须带--define _topdir %(pwd)/rpmbuild指定构建目录避免污染系统/root/rpmbuild。实测命令# 在干净容器中执行保证环境纯净 docker run -it --rm -v $(pwd):/workspace centos:7 /bin/bash -c yum install -y rpm-build gcc make openssl-devel python3-devel systemd-devel cd /workspace rpmbuild -ba --define _topdir %(pwd)/rpmbuild postgresql14.spec 构建产物位于rpmbuild/RPMS/x86_64/postgresql14-14.11-1.el7.x86_64.rpm大小约28MB——比官方RPM小12%因为我们剔除了contrib/pgbench的文档和示例数据。3.2 “一键安装”主脚本三层防御机制设计主脚本pg-install.sh不是简单串联命令而是构建了三层防御第一层环境预检Pre-flight Check脚本开头执行check_system_requirements()函数check_system_requirements() { # 检查磁盘空间PGDATA至少需5GB空闲 local free_space$(df -B1 /var/lib/pgsql | awk NR2 {print $4}) if [ $free_space -lt 5368709120 ]; then echo ERROR: /var/lib/pgsql has less than 5GB free space 2 return 1 fi # 检查SELinux状态避免后续avc denied if sestatus | grep -q enabled; then if ! semanage fcontext -l | grep -q /var/lib/pgsql; then echo WARN: SELinux context for /var/lib/pgsql not set. Running restorecon... semanage fcontext -a -t postgresql_db_t /var/lib/pgsql(/.*)? restorecon -Rv /var/lib/pgsql fi fi }第二层RPM安装与服务初始化Atomic Install使用rpm -Uvh --force --nodeps是自杀行为。我们采用原子化安装# 先校验RPM包完整性 rpm -K postgresql14-14.11-1.el7.x86_64.rpm || { echo RPM checksum failed; exit 1; } # 使用--replacepkgs避免冲突但禁止--nodeps rpm -Uvh --replacepkgs postgresql14-14.11-1.el7.x86_64.rpm || { echo RPM install failed. Checking conflicts... rpm -qf /usr/pgsql-14/bin/pg_ctl 2/dev/null echo Old PG version detected. Removing... rpm -e $(rpm -qf /usr/pgsql-14/bin/pg_ctl 2/dev/null | head -1) --nodeps rpm -Uvh --replacepkgs postgresql14-14.11-1.el7.x86_64.rpm } # 初始化数据目录关键必须指定locale和encoding sudo -u postgres /usr/pgsql-14/bin/initdb \ --pgdata/var/lib/pgsql/14/data \ --localeen_US.UTF-8 \ --encodingUTF8 \ --auth-hostmd5 \ --auth-localpeer第三层源码扩展编译Just-in-time Compile以pgvector为例脚本动态生成编译指令# 自动探测PG版本和路径 PG_VERSION$(/usr/pgsql-14/bin/pg_config --version | awk {print $2} | cut -d. -f1,2) PG_CONFIG/usr/pgsql-14/bin/pg_config # 下载并编译带超时和重试 curl -fsSL --max-time 300 --retry 3 \ https://github.com/pgvector/pgvector/archive/refs/tags/v0.5.1.tar.gz \ -o /tmp/pgvector.tar.gz || { echo Download failed; exit 1; } tar -xzf /tmp/pgvector.tar.gz -C /tmp/ cd /tmp/pgvector-0.5.1 make PG_CONFIG$PG_CONFIG sudo make install PG_CONFIG$PG_CONFIG3.3 配置文件生成超越模板的智能注入pg_hba.conf和postgresql.conf不能简单复制模板。我们的脚本会根据环境自动注入网络策略注入若检测到hostname -I包含10.0.0.0/8网段则在pg_hba.conf末尾追加# Auto-generated for internal network host all all 10.0.0.0/8 md5 host replication all 10.0.0.0/8 md5性能参数动态计算shared_buffers不写死128MB而是按物理内存计算MEM_GB$(free -g | awk /Mem:/ {print $2}) if [ $MEM_GB -ge 64 ]; then SHARED_BUFFERS8GB elif [ $MEM_GB -ge 16 ]; then SHARED_BUFFERS2GB else SHARED_BUFFERS512MB fi sed -i s/^#*shared_buffers .*/shared_buffers $SHARED_BUFFERS/ /var/lib/pgsql/14/data/postgresql.confSSL证书自动生成若/etc/pki/tls/certs/localhost.crt不存在则用OpenSSL生成openssl req -new -x509 -days 3650 -nodes \ -out /etc/pki/tls/certs/localhost.crt \ -keyout /etc/pki/tls/private/localhost.key \ -subj /CCN/STBeijing/LBeijing/OMyOrg/CNlocalhost \ -addext subjectAltName DNS:localhost, IP:127.0.0.1 chmod 600 /etc/pki/tls/private/localhost.key chown postgres:postgres /etc/pki/tls/{certs,private}/*4. 常见问题与实战排障那些文档里不会写的血泪经验4.1 RPM安装后pg_ctl start失败的五大根因现象根本原因排查命令解决方案pg_ctl: cannot be run as rootinitdb未用sudo -u postgres执行导致/var/lib/pgsql/14/data属主为rootls -ld /var/lib/pgsql/14/datachown -R postgres:postgres /var/lib/pgsql/14/dataFATAL: could not create lock file /var/run/postgresql/.s.PGSQL.5432.lock: Permission deniedSELinux阻止postgres用户写/var/run/postgresqlausearch -m avc -ts recent | grep postgressemanage fcontext -a -t var_run_t /var/run/postgresql(/.*)? restorecon -Rv /var/run/postgresqlcould not access the server configuration file /var/lib/pgsql/14/data/postgresql.confpostgresql.conf权限为644但属主非postgresls -l /var/lib/pgsql/14/data/postgresql.confchown postgres:postgres /var/lib/pgsql/14/data/postgresql.confFATAL: password authentication failed for user postgrespg_hba.conf中local all all peer未改为md5grep local.*all.*all /var/lib/pgsql/14/data/pg_hba.conf修改后执行sudo -u postgres /usr/pgsql-14/bin/pg_ctl reloadcould not open log file /var/lib/pgsql/14/data/log/postgresql-Fri.log: Permission deniedlog_directory路径/var/lib/pgsql/14/data/log不存在或权限错误mkdir -p /var/lib/pgsql/14/data/log chown postgres:postgres /var/lib/pgsql/14/data/logmkdir -p /var/lib/pgsql/14/data/log chown postgres:postgres /var/lib/pgsql/14/data/log实操心得我们把上述五条写成troubleshoot_pg_start.sh脚本放入RPM的%files中。客户遇到问题时只需运行sudo /usr/pgsql-14/bin/troubleshoot_pg_start.sh脚本自动执行全部检查并输出修复建议。这比教客户看日志快10倍。4.2 源码编译pgvector时make报错的终极解法网络热词里常搜pgvector compile error90%源于PG配置路径混乱。典型错误fatal error: postgres.h: No such file or directory这不是缺头文件而是pg_config路径错误。解决方案分三步确认pg_config位置# 必须用RPM安装的pg_config而非系统自带 which pg_config # 应输出 /usr/pgsql-14/bin/pg_config /usr/pgsql-14/bin/pg_config --includedir # 应输出 /usr/pgsql-14/include强制Makefile使用指定路径不要依赖make自动查找显式传参make clean make PG_CONFIG/usr/pgsql-14/bin/pg_config若仍失败检查pg_config输出是否被篡改某些环境pg_config --includedir返回/usr/include/pgsql错误正确应为/usr/pgsql-14/include。此时需重建pg_config软链接rm /usr/pgsql-14/bin/pg_config ln -s /usr/pgsql-14/lib/pgxs/src/makefiles/pg_config /usr/pgsql-14/bin/pg_config4.3 “一键安装”后连接拒绝的隐蔽陷阱客户常问“安装成功但psql -U postgres连不上”。除常规网络配置外两个隐蔽点防火墙放行不等于端口开放firewall-cmd --add-port5432/tcp只是添加规则还需firewall-cmd --reload生效。更致命的是某些云厂商安全组默认关闭lo回环接口导致psql -h localhost走TCP而psql走Unix socket失败。验证命令# 测试Unix socket绕过网络栈 psql -U postgres -d postgres # 测试TCP连接暴露真实问题 psql -h 127.0.0.1 -U postgres -d postgrespg_hba.conf的顺序陷阱文件按顺序匹配若顶部有host all all 0.0.0.0/0 reject则后续md5规则永不生效。必须确保# TYPE DATABASE USER ADDRESS METHOD local all all peer host all all 127.0.0.1/32 md5 host all all ::1/128 md5 # 最后才放通内网 host all all 10.0.0.0/8 md54.4 RPM升级时数据目录迁移的零停机方案RPM升级如14.10→14.11需迁移数据目录。暴力cp -r会导致数小时停机。我们采用pg_upgrade在线迁移# 1. 安装新版本RPM不启动服务 rpm -Uvh postgresql14-14.11-1.el7.x86_64.rpm # 2. 创建新数据目录 sudo -u postgres mkdir -p /var/lib/pgsql/14.11/data # 3. 执行就地升级--link参数创建硬链接秒级完成 sudo -u postgres /usr/pgsql-14.11/bin/pg_upgrade \ --old-datadir/var/lib/pgsql/14/data \ --new-datadir/var/lib/pgsql/14.11/data \ --old-bindir/usr/pgsql-14/bin \ --new-bindir/usr/pgsql-14.11/bin \ --link # 4. 切换服务指向新目录 sed -i s|/var/lib/pgsql/14/data|/var/lib/pgsql/14.11/data| /etc/sysconfig/pgsql/postgresql-14 systemctl restart postgresql-14注意--link参数要求新旧PG版本主版本号相同均为14.x且文件系统必须支持硬链接XFS/EXT4均可。实测1TB数据目录迁移耗时3秒真正实现零停机。5. 工具链与生态整合让“一键安装”成为DevOps流水线的齿轮5.1 Ansible Role标准化从单机脚本到集群交付单机pg-install.sh无法满足生产需求。“一键安装”必须升维为Ansible Role。我们设计的role/postgresql结构如下roles/postgresql/ ├── defaults/main.yml # 默认变量pg_version: 14.11, pg_data_dir: /var/lib/pgsql/14/data ├── vars/main.yml # 版本矩阵变量pg_versions: { 14: 14.11, 15: 15.6 } ├── tasks/main.yml # 主任务链install_rpm → init_db → configure_ssl → deploy_extensions ├── handlers/main.yml # 重启服务- name: restart postgresql-14 ├── templates/ # Jinja2模板postgresql.conf.j2动态注入shared_buffers │ ├── postgresql.conf.j2 │ └── pg_hba.conf.j2 └── files/ # 静态文件ssl证书、自定义函数SQL └── ssl/关键创新点在于tasks/configure_ssl.yml- name: Generate SSL certificate if not exists openssl_certificate: path: /etc/pki/tls/certs/localhost.crt privatekey_path: /etc/pki/tls/private/localhost.key csr_path: /etc/pki/tls/private/localhost.csr provider: selfsigned when: not (lookup(file, /etc/pki/tls/certs/localhost.crt) | length 0) - name: Ensure SSL files owned by postgres file: path: {{ item }} owner: postgres group: postgres mode: 0600 loop: - /etc/pki/tls/private/localhost.key - /etc/pki/tls/certs/localhost.crt此Role已在某银行私有云落地管理217个PG实例平均部署时间从42分钟降至3.7分钟。5.2 与CI/CD流水线的深度咬合“一键安装”不是终点而是CI/CD的起点。我们在GitLab CI中设计如下流水线stages: - build-rpm - test-install - deploy-prod build-rpm: stage: build-rpm image: centos:7 script: - yum install -y rpm-build gcc make - rpmbuild -ba postgresql14.spec artifacts: paths: - rpmbuild/RPMS/x86_64/postgresql14-*.rpm test-install: stage: test-install image: centos:7 script: - yum install -y /builds/$CI_PROJECT_PATH/rpmbuild/RPMS/x86_64/postgresql14-*.rpm - sudo -u postgres /usr/pgsql-14/bin/initdb -D /tmp/pgtest - sudo -u postgres /usr/pgsql-14/bin/pg_ctl -D /tmp/pgtest start - psql -U postgres -d postgres -c SELECT version(); after_script: - sudo -u postgres /usr/pgsql-14/bin/pg_ctl -D /tmp/pgtest stop deploy-prod: stage: deploy-prod image: registry.example.com/ansible-runner:2.12 script: - ansible-playbook deploy.yml -i inventory/prod -e pg_version14.11 when: manual关键设计test-install阶段在干净容器中验证RPM可安装、可初始化、可启动任何环节失败即阻断流水线。这比“先部署再测试”减少90%的线上事故。5.3 监控与告警的前置集成“一键安装”脚本末尾自动部署监控探针# 安装pg_exporterPrometheus指标导出器 curl -fsSL https://github.com/wrouesnel/postgres_exporter/releases/download/v0.12.0/postgres_exporter_v0.12.0_linux-amd64.tar.gz | tar -xzf - -C /usr/local/bin # 创建systemd服务 cat /etc/systemd/system/pg_exporter.service EOF [Unit] DescriptionPostgreSQL Exporter Afternetwork.target postgresql-14.service [Service] Typesimple Userpostgres EnvironmentDATA_SOURCE_NAMEpostgresql://postgres:passwordlocalhost:5432/postgres?sslmodedisable ExecStart/usr/local/bin/postgres_exporter --web.listen-address:9187 Restarton-failure [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable pg_exporter systemctl start pg_exporter同时注入Prometheus告警规则- alert: PostgreSQLDown expr: pg_up{jobpostgresql} 0 for: 1m labels: severity: critical annotations: summary: PostgreSQL instance down description: PostgreSQL instance {{ $labels.instance }} has been down for more than 1 minute. - alert: HighConnectionCount expr: pg_stat_database_connections{datnamepostgres} 100 for: 5m labels: severity: warning annotations: summary: High connection count on PostgreSQL description: Connection count is above 100 on {{ $labels.instance }}这使得新部署的PG实例在systemctl start postgresql-14后30秒内即可在Grafana看到PostgreSQL Overview面板真正实现“安装即可观测”。6. 安全加固与合规实践超越基础安装的生产级保障6.1 密码策略的强制植入RPM安装后默认postgres用户密码为空这是最大安全漏洞。我们的脚本在post-install阶段强制执行# 生成高强度随机密码24字符含大小写字母、数字、符号 PG_PASS$(openssl rand -base64 24 | tr -d / | cut -c1-24) # 设置postgres用户密码使用ALTER ROLE非psql交互 sudo -u postgres psql -c ALTER ROLE postgres PASSWORD $PG_PASS; # 将密码写入.pgpass文件供后续脚本使用 echo localhost:5432:*:postgres:$PG_PASS /var/lib/pgsql/.pgpass chmod 600 /var/lib/pgsql/.pgpass chown postgres:postgres /var/lib/pgsql/.pgpass注意.pgpass文件必须设为600权限否则psql拒绝读取。我们曾因权限为644导致备份脚本pg_dump始终提示password authentication failed排查3小时才发现是此文件权限问题。6.2 审计日志的默认开启PG默认不开启审计需手动配置。脚本自动注入# 启用pgaudit扩展需先安装postgresql14-contrib sudo -u postgres psql -c CREATE EXTENSION IF NOT EXISTS pgaudit; # 修改postgresql.conf echo pgaudit.logwrite, ddl, role /var/lib/pgsql/14/data/postgresql.conf echo pgaudit.log_catalogoff /var/lib/pgsql/14/data/postgresql.conf echo log_line_prefix %t [%p]: [%l-1] user%u,db%d,app%a,client%h /var/lib/pgsql/14/data/postgresql.conf echo log_statement none /var/lib/pgsql/14/data/postgresql.conf # 避免重复记录 # 重启生效 sudo -u postgres /usr/pgsql-14/bin/pg_ctl -D /var/lib/pgsql/14/data reload审计日志默认写入/var/lib/pgsql/14/data/log/按天轮转符合等保2.0三级要求。6.3 内核参数的自动化调优PG对内核参数敏感脚本自动校验并修复# 检查vm.swappiness应≤1 if [ $(cat /proc/sys/vm/swappiness) -gt 1 ]; then echo vm.swappiness 1 /etc