尧图网站建设 
银河麒麟V10-ARM架构-postgresql安装与部署指南最近在给单位机房里的几台国产化服务器做数据库选型平台是银河麒麟V10ARM架构飞腾/鲲鹏那一类芯片数据库要装PostgreSQL。说起来这事儿看着不复杂网上教程也不少但真到自己上手才发现ARM架构 国产系统这套组合拳坑比想象中多。我把整个从零开始的安装部署过程完整记录了一遍包括方案选型的纠结、踩过的坑、最终敲定的步骤和配置希望对正在搞国产化替代、信创项目或者单纯想在ARM Linux上跑PG的朋友有点帮助。先说结论银河麒麟V10 ARM版装PostgreSQL最稳的路子是源码编译安装别指望直接用官方现成的二进制包。原因后面详细说。整个过程大概分四步走准备环境、编译安装、初始化配置、安全加固。每条命令都是我在机器上一行行敲过、验证过能跑的不是那种抄来抄去连路径都对不上的“复制粘贴教程”。如果你手头正好是Kylin V10 飞腾/鲲鹏的机器照着操作基本一遍过就算不是这两款芯片只要摸清了ARM架构Linux的安装逻辑也能顺利迁移过去。1. 内容整体设计与思路拆解1.1 为什么ARM架构下不能“无脑”装PostgreSQL先说第一个问题为什么不直接yum install postgresql-server或者去官网下载RPM包装就完事了非要搞源码编译这一套原因其实就三个字——不兼容。银河麒麟V10虽然底层兼容CentOS的生态很多命令都和RHEL系很像但它在ARM架构下的软件仓库和x86_64体系是有差异的。具体到PostgreSQL官方提供的RPM包是针对主流Linux发行版编译好的二进制ARM版本也有但挑系统环境。银河麒麟的glibc版本、内核头文件、openssl库和官方打包时假设的环境不一定完全匹配经常出现两种情况一种是装完以后initdb初始化时报动态链接库找不到另一种是能装上但运行一段时间就莫名其妙崩了日志里全是段错误之类的问题。生产环境出这种幺蛾子谁都兜不住。还有一个很隐蔽的问题ARM架构下PostgreSQL的某些汇编优化并不通用。PostgreSQL底层为了性能在x86和ARM上有不同的原子操作实现如果直接用别的发行版编译好的二进制可能就没有把ARM芯片的特性指令集利用起来比如LSE原子指令导致在高并发下性能掉得厉害。自己编译这些都能根据本机CPU特性打开性能上有保障。所以对于银河麒麟V10 ARM这种“定制化”环境源码编译是最可控、最不容易踩坑的选择。编译参数自己定、依赖自己解决、安装路径自己规划完全掌控在手里排查问题也方便。对搞运维的人来说多花个十几分钟编译换后面几个月省心这买卖划算。1.2 安装方式与版本选型的取舍逻辑PostgreSQL在Linux上的安装方式主要有四种自带包管理器安装yum/apt、官方RPM仓库安装、Docker容器化安装、源码编译安装。在这个项目里我最终放弃了前三种选了源码编译安装理由在1.1部分已经说了一部分再补充几点。Docker容器化安装IDE很想推荐拉个镜像几分钟搞定但有两个硬伤一是很多政企内网环境根本没有外网权限去拉镜像需要离线交付二是PostgreSQL在容器里的性能裸跑在高并发下的IO延迟比物理机部署要高而且管理运维复杂对传统运维团队不是特别友好。当然如果你在内网提前导入了镜像Docker依然是个好方案这里不做死推荐。官方RPM仓库方案直接被毙因为PostgreSQL官方没有针对银河麒麟V10 ARM做专门打包。虽然技术上可能有“兼容性很好直接拿来用也能跑”的说法但生产环境我不愿意赌这个万一。版本选型上我用的是PostgreSQL 14.x的当前补丁版本。为什么不选最新的16一是兼容性考虑PG14的编译依赖比较保守对glibc、gcc版本要求不高和银河麒麟V10默认自带的gcc 8.x搭配很好不容易报编译错误二是PG14上踩坑的人多相关资料、内核参数优化案例都比较成熟出了问题能在网上很快找到解决方案三是新特性对当前业务没有特别大的吸引力稳定压倒一切。建议你也别追新选一个自己熟悉的、生态成熟的版本这比追求几个新功能实在得多。1.3 部署路径与关键前置条件梳理整个部署流程里有几个前置条件必须在动手前确认不然中途容易卡住。第一个是硬件架构确认。别光看CPU品牌用uname -m看一下系统架构输出是aarch64就对了这是ARM 64位的标识。如果是x86_64那是普通Intel/AMD平台安装逻辑又不一样了。第二个是系统版本确认。用cat /etc/os-release和nproc确认系统版本和CPU核数后面编译参数里要用到核数比如make -j8如果CPU核数少编译参数填太大了容易内存不足。第三个是磁盘空间。编译安装需要至少2GB临时空间数据目录建议单独放一个分区至少预留几十GB看业务量定。我见过有人把数据目录直接放根分区跑一段时间根分区满了整个库直接变只读这种事故很低级尽量别犯。第四个是网络权限。编译过程中会下载一些依赖包比如readline、zlib如果内网环境没有yum源需要提前把这些依赖包准备好离线安装。我在2.2节会详细说怎么处理离线依赖。2. 环境准备与依赖处理2.1 系统信息确认与基础环境检查准备工作先从确认系统信息开始我习惯先敲这几条命令把机器基本情况摸清楚再决定后续操作cat /etc/os-release # 查看系统版本 uname -m # 查看芯片架构 nproc # 查看CPU核数 free -h # 查看内存 df -h / # 查看根分区磁盘空间 gcc --version # 查看gcc编译器版本我测试机上返回的结果大概是这样的系统是Kylin V10 SP1或SP2架构是aarch64CPU核数16核内存32GB。这只是测试机的配置生产环境更高的配置当然更好但编译参数要跟着调整。确认完系统还有一个很重要的检查项——确认系统里有没有安装PostgreSQL相关的旧包。如果有要先卸载掉避免端口、数据目录冲突rpm -qa | grep postgresql # 查看是否有旧包如果有输出用rpm -e --nodeps 包名强制卸载。这一步虽然简单但有时候会被忽略导致后面初始化数据库时报“data directory exists”或者端口被占用的错很烦人。2.2 依赖包安装方法与离线环境处理PostgreSQL源码编译需要几个基础依赖库readline命令行历史记录功能、zlib压缩支持、gcc编译器、make构建工具、还有openssl可选SSL连接用。在有外网权限的环境里直接用yum安装yum install -y readline readline-devel zlib zlib-devel gcc make openssl openssl-devel注意一点一定要装xxx-devel版本光有运行库没用编译的时候需要头文件。我记得之前就有同事只装了readline没装readline-develconfigure阶段一直报找不到库浪费了半小时。如果是纯内网环境没有外网也没有内网yum源那就需要在一台能联网的同架构机器上把RPM包下载好再拷贝过去。下载命令如下# 在联网机器上执行 yum install --downloadonly --downloaddir/opt/pgdeps readline readline-devel zlib zlib-devel gcc make openssl openssl-devel把/opt/pgdeps目录打包拷到内网机器上然后rpm -Uvh /opt/pgdeps/*.rpm这里有一个非常容易被坑的点拷贝依赖包的时候一定要确保源机器和目标机器的系统版本尽量一致。如果源机器是CentOS 8目标机器是麒麟V10rpm包勉强能装上但如果源机器是CentOS 7包的glibc要求可能和目标不匹配强制装会破坏系统底层的依赖关系。这个问题处理起来很麻烦严重的情况可能要重装系统。所以条件允许的话最好的方式是在一台同系统版本、同架构的机器上准备好依赖包再拿到目标机器上用。我不想吓唬人但这种风险真实存在提前说明有备无患。2.3 新建运行用户与数据目录规划PostgreSQL不能用root用户运行这在官方文档里是明确警告过的。原因很简单数据库进程需要控制文件权限、防止越权访问用root跑会带来巨大的安全隐患。所以我们要创建一个专用用户。groupadd postgres useradd -g postgres -m -s /bin/bash postgres创建数据目录。我的习惯是把数据目录放到独立的挂载点上比如/data分区专门用于数据库存储mkdir -p /data/pgdata chown -R postgres:postgres /data/pgdata chmod 700 /data/pgdatachmod 700这里为啥要单独提因为PostgreSQL官方建议PGDATA目录权限必须是700也就是只有属主能进否则initdb会拒绝初始化。这是出于保护数据文件的考虑目录权限太开放任何用户都能读数据库文件等于脱裤子。安装目录我一般放在/usr/local/postgresql也把它归属到postgres用户mkdir -p /usr/local/postgresql chown -R postgres:postgres /usr/local/postgresql别小看目录规划这一步。很多人在后面启动服务时报各种奇怪错误根本原因就是目录权限不对。先规划好后面省心。3. 下载、编译与安装PostgreSQL的完整流程3.1 PostgreSQL源码获取与校验源码从官网下载地址是https://www.postgresql.org/ftp/source/。因为我在隔离内网环境所以提前在外面下载好用U盘拷进去。选择版本号比如v14.17这种具体的补丁版本号别选v14这种大版本补丁版本带了Bug修复稳定性更好。下载完以后解压tar -zxvf postgresql-14.17.tar.gz cd postgresql-14.17这里我额外多做一步校验文件完整性这是很多教程都不会提的。PostgreSQL官网在源码包旁边提供了sha256校验文件下载后算一下sha256sum postgresql-14.17.tar.gz和官网给出的校验值对比一致才继续。为什么强调这个源码包在传输过程中如果损坏编译会报各种莫名其妙的错误提前校验能排除这一点。另外从安全角度讲确认下载的源码没有被篡改对生产环境部署而言也是一种基本保障。3.2 configure参数详解与选择依据解压完成后进入源码目录执行configure脚本。这里参数很关键不是随便敲的。我当时的配置命令长这样./configure --prefix/usr/local/postgresql \ --with-pgport5432 \ --with-openssl \ --readline \ --zlib \ --with-perl \ --with-python参数含义拆开讲一下--prefix指定安装路径后续的所有二进制文件、库文件、头文件都会装到这个目录下。我习惯用/usr/local/postgresql好记也方便卸载。--with-pgport指定数据库默认端口不指定的话默认就是5432用系统标准端口的话可以不写。但我建议你写因为显式声明端口可以在初始化时就把配置文件里的端口写死避免后面还要手动改。--with-openssl启用SSL加密连接支持。生产环境基本都要求数据库连接走SSL现在不开启后面业务要加密连接还得重新编译费老劲了。--with-perl和--with-python启用PL/Perl和PL/Python存储过程语言支持。如果业务里用不到可以不开启减少依赖。我保留了因为之前遇到过业务方要做数据清洗写了自定义存储过程没有这个支持直接报错。还有一个可选参数--with-icu启用ICU国际化支持处理多语言排序、字符集比较时更准确。如果系统里没有ICU库configure会报错得先装libicu-devel。考虑到很多系统环境里字符集是GBK或UTF8排序要求不高我当时就没启用反正够用。看你的实际需求取舍。configure执行完最后会输出一个配置摘要检查一下有没有“WARNING”字样。某些依赖库没有找到时即使configure成功了也会以警告形式提示比如“readline not found”这时候编译出来的PG命令行工具就没有历史记录功能虽然不影响主功能但用起来很别扭。所以看到WARNING建议先解决掉再继续。3.3 make编译过程与常见卡点configure通过以后开始编译make -j 8-j 8代表用8个线程并行编译。我机器是16核的理论上-j 16更快但我保守了一点只用了8。为啥不拉满因为我遇到过并行编译任务开太多导致内存撑爆的。编译PostgreSQL时GCC的预处理阶段特别吃内存每个编译任务大约占1~2GB内存如果机器只有16GB内存开16个并行任务很容易把内存耗尽。到时候编译进程被内核杀掉前功尽弃还得重来。一般建议内存多少GB就用多少并行任务比如32GB内存用8~16个任务16GB内存用4~8个。编译过程根据CPU性能不同大约要5~15分钟。这一步出错比较少如果报了错90%的可能性是前置依赖没装全。常见的报错是找不到头文件比如fatal error: zlib.h: No such file or directory这就是zlib-devel没装。回到2.2节把依赖装全了重新编译。编译完成后安装make install到这里PostgreSQL软件本体就已经装好了。验证一下ls /usr/local/postgresql/bin/应该能看到initdb、postgres、psql、pg_ctl这些关键命令到这里安装阶段完成。注意如果后面还要装PostGIS、pgvector这类扩展插件源码目录先别删很多扩展编译需要用到PG的源码头文件删了还得重新下载。3.4 配置环境变量安装完成后要把PostgreSQL的bin目录加进PATH不然每次执行psql都要写完整路径繁琐也容易输错。编辑postgres用户的~/.bashrcsu - postgres vi ~/.bashrc在文件末尾追加export PATH/usr/local/postgresql/bin:$PATH export PGDATA/data/pgdata export LD_LIBRARY_PATH/usr/local/postgresql/lib:$LD_LIBRARY_PATHLD_LIBRARY_PATH这里特别提醒一下PostgreSQL的很多库文件不放在系统默认库路径下不把这个目录加进去启动服务时可能会报找不到libpq.so.5这类错误。这个变量是一定要加的。改完以后让配置生效source ~/.bashrc which psql能输出/usr/local/postgresql/bin/psql说明环境变量生效了。顺便说一句如果你习惯用root用户操作那把这三个变量也加到root的~/.bashrc里省得来回切换用户。数据库服务和数据文件归postgres用户管但排查问题时经常要用root去看系统日志两边都配好环境变量操作起来顺手得多。4. 初始化数据库与核心配置4.1 initdb初始化与premote认证说明这是整个部署流程里最容易出问题、也最需要谨慎对待的一步。初始化数据库一定要用postgres用户来跑su - postgres initdb -D /data/pgdata -E UTF8 --localeen_US.UTF8 -U postgres参数解释-D指定数据目录必须和前面创建的一致。-E UTF8指定数据库默认编码为UTF8。这个很重要现在业务数据基本都会涉及中文UTF8是通用标准。如果默认编码设成SQL_ASCII或GBK后面想转UTF8很麻烦导出再导入太折腾数据量大一点直接伤筋动骨。--localeen_US.UTF8指定数据库的初始化区域设置。这里有个坑如果系统里没有安装en_US.UTF8这个localeinitdb会报错。可以先执行locale -a查看系统支持的locale列表没有的话用localedef生成localedef -i en_US -f UTF-8 en_US.UTF-8-U postgres指定数据库超级用户名为postgres。这相当于MySQL里的root是整个数据库实例权限最高的账号。初始化完成以后日志最后会有一段提示说“You can now start the database server”。先别急着启动检查一个东西——认证配置文件pg_hba.conf。默认生成的配置在最底层有几行trust认证记录意思是不需要密码就能连上数据库这对于安全性要求高的生产环境是不可接受的。后面5.2节我会详细讲怎么改认证配置。注意initdb生成的初始密码是不是空的是这样的但这里的“空密码”不等于“无认证”。默认pg_hba.conf对本地连接配的是trust认证也就是本地任何用户都不用输入密码就能以任何数据库用户身份登录这个是相当危险的。虽然默认只允许本地连接服务器上只要有另一个账号被入侵数据库整个就暴露了。所以“初始化完立即改认证方式和密码”是必须要做的。4.2 postgresql.conf核心参数修改建议初始化完成后编辑/data/pgdata/postgresql.conf这里是最核心的配置文件。我把关键参数的调整思路说明一下vi /data/pgdata/postgresql.conflisten_addresses默认是localhost只允许本机访问。如果要让其他机器连数据库改成*或者指定IP。改成*表示监听所有网卡配合防火墙白名单来限制访问。如果你只让特定客户端连接写成具体IP比如192.168.1.100。port端口号默认5432前面configure时已指定不用改。如果系统里还跑着其他数据库比如人大金仓的默认端口也是5432记得错开。max_connections最大连接数默认100。要根据业务并发量调但也不是越大越好每个连接都要消耗内存连接数设置太高会导致内存吃紧。我一般按照“每连接额外消耗2MB内存左右”来估算。比如内存32GB预留一部分给系统max_connections设500左右比较合理。shared_buffers共享缓冲区这是最影响性能的参数之一。PG官方建议设为物理内存的25%比如32GB内存就设8GB。但要注意4GB以上需要系统共享内存参数支持如果系统内核参数没调设置太高会导致数据库启动失败。如果设置后启动报错可以先调回1GB再查看系统/etc/sysctl.conf中kernel.shmmax参数并调大。work_mem单个排序操作可以使用的内存默认4MB。这个参数不是越大越好因为它是按操作分配的并发高的场景下几百个排序操作同时执行每个4MB变成几百MB。一般先保留默认等业务上线后通过慢查询日志和性能监控逐步调优。effective_cache_size这不是实际分配内存的参数而是告诉优化器“系统大概有多少内存可以用于文件缓存”。一般设为物理内存的50%~75%设太低了可能导致优化器低估索引扫描的效率走全表扫描性能差很多。这个参数不影响实际内存分配设高一点没有风险。wal_level如果是生产环境做流复制要改成replica单机部署默认的replica即可。minimal级别虽然性能好一点但很多灾备功能用不了安全起见用replica。我做完这些修改后会先检查一遍文件内容确认没有语法问题再启动。注意PG配置文件是改一个生效一个不是大部分参数要重启数据库服务才生效小部分通过pg_ctl reload就能热加载比如max_connections要重启shared_buffers要重启work_mem可以热加载。不确定的参数改完统一重启服务。4.3 配置systemd服务实现开机自启动编译安装的PostgreSQL不会自动注册systemd服务每次手动pg_ctl start效率太低服务器重启后数据库也不会自动拉起来这在生产环境是绝对不行的。我写了一个systemd服务配置文件放到/etc/systemd/system/postgresql.service内容如下[Unit] DescriptionPostgreSQL database server Afternetwork.target [Service] Typeforking Userpostgres Grouppostgres PIDFile/data/pgdata/postmaster.pid ExecStart/usr/local/postgresql/bin/pg_ctl start -D /data/pgdata -l /data/pgdata/logfile ExecStop/usr/local/postgresql/bin/pg_ctl stop -D /data/pgdata -m fast ExecReload/usr/local/postgresql/bin/pg_ctl reload -D /data/pgdata TimeoutSec600 [Install] WantedBymulti-user.target配置说明Typeforkingpostgres主进程启动后会fork出子进程用这个类型systemd才能正确跟踪主进程状态。PIDFile指向postmaster.pid这个文件由PostgreSQL自动生成记录主进程PID。路径一定要和PGDATA一致不一致会导致systemd认为服务启动失败。ExecStop用-m fast快速关闭模式相当于SQL里的快速关机拒绝新连接并等待正在执行的事务完成然后再停。默认模式是smart会一直等所有客户端断连才停有长连接挂着可能等几个小时。运维中一般用fast比较合适。WantedBy让服务在系统进入多用户模式时自动启动。配置文件写好以后systemctl daemon-reload systemctl enable postgresql systemctl start postgresql systemctl status postgresql看到active (running)说明服务启动成功了。这里有一个编译安装最常见的坑pg_ctl start启动时可能报找不到libpq.so.5这个动态库。虽然我们在3.4节配置了环境变量但systemd启动服务时不会加载用户的环境变量只加载系统环境。解决方式是创建一个库文件配置echo /usr/local/postgresql/lib /etc/ld.so.conf.d/postgresql.conf ldconfig然后重启服务这个问题就解决了。5. 安全加固、远程连接与基础运维5.1 设置超级用户密码并调整pg_hba.conf认证初始化之后的第一件事给postgres用户设置密码su - postgres psql -c ALTER USER postgres WITH PASSWORD 你的强密码;密码复杂度建议至少12位包含大小写字母数字特殊字符。生产环境千万别用postgres、123456这种弱口令现在的安全扫描工具很成熟弱口令基本一抓一个准。然后编辑/data/pgdata/pg_hba.conf。这个文件是PG的访问控制清单决定谁能连、从哪连、怎么认证。我建议这样配置# 本地Unix套接字连接使用peer认证即系统用户和数据库用户同名即可连接仅限本地 local all all peer # 本机IPv4回环地址使用scram-sha-256加密认证 host all all 127.0.0.1/32 scram-sha-256 # 本机IPv6回环地址 host all all ::1/128 scram-sha-256 # 内网网段按实际调整 host all all 192.168.0.0/16 scram-sha-256peer认证的含义是“系统用户名 数据库用户名”即通过认证不需要密码。这个只对本地生效安全性尚可基于操作系统用户身份。对于远程连接全部用scram-sha-256密码加密认证。PostgreSQL 14里默认的密码加密方式就是scram-sha-256比老的md5安全得多。修改完pg_hba.conf以后执行pg_ctl reload让配置生效不需要重启数据库pg_ctl reload -D /data/pgdata注意每次改完pg_hba.conf之前建议先备份原文件。别问我为什么改错一个参数导致数据库拒绝所有连接然后手忙脚乱找回滚文件的经历一次就长记性了。5.2 防火墙与远程连接测试远程连接数据库除了PG侧的认证配置还要过防火墙这一关。用firewalld的话firewall-cmd --permanent --add-port5432/tcp firewall-cmd --reload如果是用iptables管理自己加一条规则iptables -A INPUT -p tcp --dport 5432 -j ACCEPT这里说一个我踩过的坑有些麒麟V10系统带了一个叫kysec的安全组件它会额外拦截网络端口的访问即使防火墙放行了也可能连不上。如果发现端口明明开着、数据库也在监听、防火墙也放行了但就是连不上第一反应看看是不是kysec的问题。这东西属于麒麟自带的强制访问控制机制命中了会在/var/log/messages里留下记录查看系统日志是一个很有效的排查路径。配置完成后在内网的另外一台机器上测试连接psql -h 192.168.1.10 -p 5432 -U postgres -d postgres输入密码能连上并进入psql交互界面就说明整个链路是通的。提示一下客户端也需要安装PostgreSQL的客户端工具包如果在Windows上可以用pgAdmin或者直接用psql命令行。5.3 数据库日常启停、日志查看与备份命令部署完成不代表结束日常运维手段才是保障生产稳定性的关键。核心命令我整理了一份速查清单systemctl start postgresql # 启动数据库 systemctl stop postgresql # 停止数据库 systemctl restart postgresql # 重启数据库 systemctl status postgresql # 查看运行状态 pg_ctl reload -D /data/pgdata # 热加载配置无需重启 tail -f /data/pgdata/logfile # 实时查看数据库日志日志这块PG的默认配置是把日志输出到stderr再转写到日志文件。我在postgresql.conf里还改了logging_collector为on并设置log_directory log这样日志会统一放到PGDATA/log目录下按天滚动方便排查问题。生产环境建议将log_min_duration_statement设为1000ms记录执行超过1秒的慢SQL这是后续性能调优的重要依据。备份是最不能忽视的环节。PG的单机备份最简单有效的方式是pg_dump# 备份单个数据库 pg_dump -h localhost -U postgres -d 你的数据库名 -F c -f /backup/库名.dump # 还原数据库 pg_restore -h localhost -U postgres -d 新库名 -c /backup/库名.dump-F c是自定义压缩格式比纯SQL脚本体积小也便于pg_restore选择性恢复。生产环境建议至少每天做一次全量备份保留最近7天的备份文件再用cron定时任务在凌晨自动执行。如果允许停机一小会儿物理备份pg_basebackup是更完整的方案可以配合WAL归档实现时间点恢复那个功能更强大这里篇幅有限不多展开。5.4 常见问题排查与避坑经验整合把我在这次部署中遇到的和网上反馈比较多的问题整理成一个速查表方便直接对照排查问题现象可能原因解决方法configure阶段报错找不到zlib.h缺zlib-devel包yum install zlib-devel编译时报c compiler cannot create executablesgcc未装或版本不对yum install gcc make确认gcc可用initdb报locale不存在系统缺en_US.UTF8区域localedef -i en_US -f UTF-8 en_US.UTF-8启动时报Permission denied目录权限不对chown postgres:postgres -R /data/pgdata启动时报could not identify version of libpqLD_LIBRARY_PATH没有设置添加export LD_LIBRARY_PATH/usr/local/postgresql/lib:$LD_LIBRARY_PATHsystemd启动但是状态异常PIDFile路径或权限不对检查postmaster.pid的属主和路径远程连接超时防火墙/kysec拦截检查防火墙策略和/var/log/messages远程连接提示no pg_hba.conf entrypg_hba.conf配置遗漏按5.1节配置添加对应网段条目提示password authentication failed密码错误或认证方式不匹配检查pg_hba.conf用的认证方式和密码算法是否一致psql命令找不到PATH没有包含PG的bin目录配置环境变量PATH重新source服务器重启后数据库没起来systemd服务没有enablesystemctl enable postgresql以上每一条我都实际遇到过或验证过按图索骥一般能解决大部分问题。如果你遇到的是表里没有的怪异错误先看数据库日志文件通常日志里会有明确的原因提示。我处理过太多“报错不看日志直接百度”的人了最后绕了一圈回来发现日志里早就把原因写清楚了。学会看日志是数据库运维的入门基本功。6. 整体安全性补充系统加固思路与扩展方向6.1 ARM架构下的关键内核参数调优与内存管理PostgreSQL在大内存机器上有一些内核参数需要调一调否则性能发挥不出来。编辑/etc/sysctl.confkernel.shmall 1073741824 kernel.shmmax 274877906944 vm.overcommit_memory 2 vm.overcommit_ratio 90shmmax和shmall是System V共享内存的上限参数。PG的shared_buffers如果设置的比较大就依赖这个参数。不调的话shared_buffers设8GB可能启动报错日志提示无法分配共享内存。vm.overcommit_memory 2表示系统执行严格的内存过载检查配合vm.overcommit_ratio控制总内存分配比例。这个参数在PG社区里有一定争议改完以后如果业务方有单独申请大内存的程序可能被拒。我的建议如果对Linux内存管理不够熟只改shmmax和shmall就够了overcommit这块保持默认别上来就一顿乱调反而搞出问题。ARM架构下还有一个特殊优化点如果CPU支持LSELarge System Extension原子指令编译时加上-marcharmv8.1-a这个编译选项可以让PostgreSQL在高并发下减少内核锁竞争性能提升明显。但这个选项要求CPU必须支持ARMv8.1指令集老一点的ARMv8.0芯片不支持加了反而可能编译出非法指令。我的处理方式先查lscpu里的Flags看到有atomics字样就支持加上没有就不加稳定优先。6.2 升级、卸载与扩展插件的后续思路部署完成以后随着版本更新和业务扩展“升级”和“卸载”这两件事早晚要遇到。这里把思路梳理一下。PG的小版本升级很简单下载新版源码configure make make install然后重启服务数据目录不需要迁移。PG的小版本升级是兼容的完全支持原地覆盖。大版本升级比如从14升到15要复杂一些需要用pg_upgrade工具这个工具要求新旧版本都装在同一台机器上而且会锁库需要配合业务停机窗口操作前一定先把备份做扎实。卸载的话我一般不用make uninstall因为编译安装在/usr/local/postgresql目录下非常集中直接systemctl stop postgresql rm -rf /usr/local/postgresql rm -rf /data/pgdata userdel postgres干干净净不留残余。这就是编译安装的好处想卸就卸不会像rpm包那样卸载时还要处理各种依赖关系。扩展插件方面如果你后面要装PostGIS空间数据、pgvector向量检索这类扩展源码目录一定要保留。以pgvector为例编译流程是cd /opt/pgvector-0.7.4 make PG_CONFIG/usr/local/postgresql/bin/pg_config make install PG_CONFIG/usr/local/postgresql/bin/pg_config因为扩展插件编译时要通过pg_config找到PostgreSQL的头文件和库文件如果不指定PG_CONFIG路径系统会在默认路径找很可能找不到编译安装的PG最后报一堆莫须有的错误。所以建议源码目录直接留在/opt下别删。6.3 从单机到主从复制的基本过渡方案单机部署跑通以后你很可能下一步会面临高可用问题——数据库挂了怎么办。这里简单说下从单机到主从复制的思路。PG的主从复制非常简单主库配置需要wal_level replica max_wal_senders 10 max_replication_slots 10备库从主库做一个基础备份pg_basebackup -h 主库IP -p 5432 -U repuser -D /data/pgdata -F p -R然后在备库的standby.signal文件-R参数自动生成里就有standby_modeon再配置primary_conninfo指向主库IP即可。整个过程比MySQL的主从简单不少但需要注意两点一是要创建专门的复制账号不能直接用postgres超级用户二是主从之间的网络延迟影响比较大尽量在同一内网机房部署。说回这次的完整部署过程。我在实际安装中最大的体会是银河麒麟V10 ARM上的数据库部署硬骨头不在PostgreSQL本身而在环境适配。一旦把依赖管理、编译参数、系统服务这几个关节打通了后面跑起来是非常稳的。我现在这套环境已经连续运行了几个月没有出现过异常重启、数据损坏之类的问题日常的备份、监控、慢查询日志都在正常工作。如果你也在搞国产化环境下的数据库部署希望这篇记录能帮你少走几个弯路。最后再分享一个习惯每次部署完数据库把操作系统版本、内核参数、PG版本、配置文件的关键选项都记到一个文档里。半年以后你要排查一个诡异问题这个文档可能比搜索引擎都管用。祝顺利。 银河麒麟V10 ARM架构下PostgreSQL源码编译安装与部署指南
银河麒麟V10-ARM架构-postgresql安装与部署指南最近在给单位机房里的几台国产化服务器做数据库选型平台是银河麒麟V10ARM架构飞腾/鲲鹏那一类芯片数据库要装PostgreSQL。说起来这事儿看着不复杂网上教程也不少但真到自己上手才发现ARM架构 国产系统这套组合拳坑比想象中多。我把整个从零开始的安装部署过程完整记录了一遍包括方案选型的纠结、踩过的坑、最终敲定的步骤和配置希望对正在搞国产化替代、信创项目或者单纯想在ARM Linux上跑PG的朋友有点帮助。先说结论银河麒麟V10 ARM版装PostgreSQL最稳的路子是源码编译安装别指望直接用官方现成的二进制包。原因后面详细说。整个过程大概分四步走准备环境、编译安装、初始化配置、安全加固。每条命令都是我在机器上一行行敲过、验证过能跑的不是那种抄来抄去连路径都对不上的“复制粘贴教程”。如果你手头正好是Kylin V10 飞腾/鲲鹏的机器照着操作基本一遍过就算不是这两款芯片只要摸清了ARM架构Linux的安装逻辑也能顺利迁移过去。1. 内容整体设计与思路拆解1.1 为什么ARM架构下不能“无脑”装PostgreSQL先说第一个问题为什么不直接yum install postgresql-server或者去官网下载RPM包装就完事了非要搞源码编译这一套原因其实就三个字——不兼容。银河麒麟V10虽然底层兼容CentOS的生态很多命令都和RHEL系很像但它在ARM架构下的软件仓库和x86_64体系是有差异的。具体到PostgreSQL官方提供的RPM包是针对主流Linux发行版编译好的二进制ARM版本也有但挑系统环境。银河麒麟的glibc版本、内核头文件、openssl库和官方打包时假设的环境不一定完全匹配经常出现两种情况一种是装完以后initdb初始化时报动态链接库找不到另一种是能装上但运行一段时间就莫名其妙崩了日志里全是段错误之类的问题。生产环境出这种幺蛾子谁都兜不住。还有一个很隐蔽的问题ARM架构下PostgreSQL的某些汇编优化并不通用。PostgreSQL底层为了性能在x86和ARM上有不同的原子操作实现如果直接用别的发行版编译好的二进制可能就没有把ARM芯片的特性指令集利用起来比如LSE原子指令导致在高并发下性能掉得厉害。自己编译这些都能根据本机CPU特性打开性能上有保障。所以对于银河麒麟V10 ARM这种“定制化”环境源码编译是最可控、最不容易踩坑的选择。编译参数自己定、依赖自己解决、安装路径自己规划完全掌控在手里排查问题也方便。对搞运维的人来说多花个十几分钟编译换后面几个月省心这买卖划算。1.2 安装方式与版本选型的取舍逻辑PostgreSQL在Linux上的安装方式主要有四种自带包管理器安装yum/apt、官方RPM仓库安装、Docker容器化安装、源码编译安装。在这个项目里我最终放弃了前三种选了源码编译安装理由在1.1部分已经说了一部分再补充几点。Docker容器化安装IDE很想推荐拉个镜像几分钟搞定但有两个硬伤一是很多政企内网环境根本没有外网权限去拉镜像需要离线交付二是PostgreSQL在容器里的性能裸跑在高并发下的IO延迟比物理机部署要高而且管理运维复杂对传统运维团队不是特别友好。当然如果你在内网提前导入了镜像Docker依然是个好方案这里不做死推荐。官方RPM仓库方案直接被毙因为PostgreSQL官方没有针对银河麒麟V10 ARM做专门打包。虽然技术上可能有“兼容性很好直接拿来用也能跑”的说法但生产环境我不愿意赌这个万一。版本选型上我用的是PostgreSQL 14.x的当前补丁版本。为什么不选最新的16一是兼容性考虑PG14的编译依赖比较保守对glibc、gcc版本要求不高和银河麒麟V10默认自带的gcc 8.x搭配很好不容易报编译错误二是PG14上踩坑的人多相关资料、内核参数优化案例都比较成熟出了问题能在网上很快找到解决方案三是新特性对当前业务没有特别大的吸引力稳定压倒一切。建议你也别追新选一个自己熟悉的、生态成熟的版本这比追求几个新功能实在得多。1.3 部署路径与关键前置条件梳理整个部署流程里有几个前置条件必须在动手前确认不然中途容易卡住。第一个是硬件架构确认。别光看CPU品牌用uname -m看一下系统架构输出是aarch64就对了这是ARM 64位的标识。如果是x86_64那是普通Intel/AMD平台安装逻辑又不一样了。第二个是系统版本确认。用cat /etc/os-release和nproc确认系统版本和CPU核数后面编译参数里要用到核数比如make -j8如果CPU核数少编译参数填太大了容易内存不足。第三个是磁盘空间。编译安装需要至少2GB临时空间数据目录建议单独放一个分区至少预留几十GB看业务量定。我见过有人把数据目录直接放根分区跑一段时间根分区满了整个库直接变只读这种事故很低级尽量别犯。第四个是网络权限。编译过程中会下载一些依赖包比如readline、zlib如果内网环境没有yum源需要提前把这些依赖包准备好离线安装。我在2.2节会详细说怎么处理离线依赖。2. 环境准备与依赖处理2.1 系统信息确认与基础环境检查准备工作先从确认系统信息开始我习惯先敲这几条命令把机器基本情况摸清楚再决定后续操作cat /etc/os-release # 查看系统版本 uname -m # 查看芯片架构 nproc # 查看CPU核数 free -h # 查看内存 df -h / # 查看根分区磁盘空间 gcc --version # 查看gcc编译器版本我测试机上返回的结果大概是这样的系统是Kylin V10 SP1或SP2架构是aarch64CPU核数16核内存32GB。这只是测试机的配置生产环境更高的配置当然更好但编译参数要跟着调整。确认完系统还有一个很重要的检查项——确认系统里有没有安装PostgreSQL相关的旧包。如果有要先卸载掉避免端口、数据目录冲突rpm -qa | grep postgresql # 查看是否有旧包如果有输出用rpm -e --nodeps 包名强制卸载。这一步虽然简单但有时候会被忽略导致后面初始化数据库时报“data directory exists”或者端口被占用的错很烦人。2.2 依赖包安装方法与离线环境处理PostgreSQL源码编译需要几个基础依赖库readline命令行历史记录功能、zlib压缩支持、gcc编译器、make构建工具、还有openssl可选SSL连接用。在有外网权限的环境里直接用yum安装yum install -y readline readline-devel zlib zlib-devel gcc make openssl openssl-devel注意一点一定要装xxx-devel版本光有运行库没用编译的时候需要头文件。我记得之前就有同事只装了readline没装readline-develconfigure阶段一直报找不到库浪费了半小时。如果是纯内网环境没有外网也没有内网yum源那就需要在一台能联网的同架构机器上把RPM包下载好再拷贝过去。下载命令如下# 在联网机器上执行 yum install --downloadonly --downloaddir/opt/pgdeps readline readline-devel zlib zlib-devel gcc make openssl openssl-devel把/opt/pgdeps目录打包拷到内网机器上然后rpm -Uvh /opt/pgdeps/*.rpm这里有一个非常容易被坑的点拷贝依赖包的时候一定要确保源机器和目标机器的系统版本尽量一致。如果源机器是CentOS 8目标机器是麒麟V10rpm包勉强能装上但如果源机器是CentOS 7包的glibc要求可能和目标不匹配强制装会破坏系统底层的依赖关系。这个问题处理起来很麻烦严重的情况可能要重装系统。所以条件允许的话最好的方式是在一台同系统版本、同架构的机器上准备好依赖包再拿到目标机器上用。我不想吓唬人但这种风险真实存在提前说明有备无患。2.3 新建运行用户与数据目录规划PostgreSQL不能用root用户运行这在官方文档里是明确警告过的。原因很简单数据库进程需要控制文件权限、防止越权访问用root跑会带来巨大的安全隐患。所以我们要创建一个专用用户。groupadd postgres useradd -g postgres -m -s /bin/bash postgres创建数据目录。我的习惯是把数据目录放到独立的挂载点上比如/data分区专门用于数据库存储mkdir -p /data/pgdata chown -R postgres:postgres /data/pgdata chmod 700 /data/pgdatachmod 700这里为啥要单独提因为PostgreSQL官方建议PGDATA目录权限必须是700也就是只有属主能进否则initdb会拒绝初始化。这是出于保护数据文件的考虑目录权限太开放任何用户都能读数据库文件等于脱裤子。安装目录我一般放在/usr/local/postgresql也把它归属到postgres用户mkdir -p /usr/local/postgresql chown -R postgres:postgres /usr/local/postgresql别小看目录规划这一步。很多人在后面启动服务时报各种奇怪错误根本原因就是目录权限不对。先规划好后面省心。3. 下载、编译与安装PostgreSQL的完整流程3.1 PostgreSQL源码获取与校验源码从官网下载地址是https://www.postgresql.org/ftp/source/。因为我在隔离内网环境所以提前在外面下载好用U盘拷进去。选择版本号比如v14.17这种具体的补丁版本号别选v14这种大版本补丁版本带了Bug修复稳定性更好。下载完以后解压tar -zxvf postgresql-14.17.tar.gz cd postgresql-14.17这里我额外多做一步校验文件完整性这是很多教程都不会提的。PostgreSQL官网在源码包旁边提供了sha256校验文件下载后算一下sha256sum postgresql-14.17.tar.gz和官网给出的校验值对比一致才继续。为什么强调这个源码包在传输过程中如果损坏编译会报各种莫名其妙的错误提前校验能排除这一点。另外从安全角度讲确认下载的源码没有被篡改对生产环境部署而言也是一种基本保障。3.2 configure参数详解与选择依据解压完成后进入源码目录执行configure脚本。这里参数很关键不是随便敲的。我当时的配置命令长这样./configure --prefix/usr/local/postgresql \ --with-pgport5432 \ --with-openssl \ --readline \ --zlib \ --with-perl \ --with-python参数含义拆开讲一下--prefix指定安装路径后续的所有二进制文件、库文件、头文件都会装到这个目录下。我习惯用/usr/local/postgresql好记也方便卸载。--with-pgport指定数据库默认端口不指定的话默认就是5432用系统标准端口的话可以不写。但我建议你写因为显式声明端口可以在初始化时就把配置文件里的端口写死避免后面还要手动改。--with-openssl启用SSL加密连接支持。生产环境基本都要求数据库连接走SSL现在不开启后面业务要加密连接还得重新编译费老劲了。--with-perl和--with-python启用PL/Perl和PL/Python存储过程语言支持。如果业务里用不到可以不开启减少依赖。我保留了因为之前遇到过业务方要做数据清洗写了自定义存储过程没有这个支持直接报错。还有一个可选参数--with-icu启用ICU国际化支持处理多语言排序、字符集比较时更准确。如果系统里没有ICU库configure会报错得先装libicu-devel。考虑到很多系统环境里字符集是GBK或UTF8排序要求不高我当时就没启用反正够用。看你的实际需求取舍。configure执行完最后会输出一个配置摘要检查一下有没有“WARNING”字样。某些依赖库没有找到时即使configure成功了也会以警告形式提示比如“readline not found”这时候编译出来的PG命令行工具就没有历史记录功能虽然不影响主功能但用起来很别扭。所以看到WARNING建议先解决掉再继续。3.3 make编译过程与常见卡点configure通过以后开始编译make -j 8-j 8代表用8个线程并行编译。我机器是16核的理论上-j 16更快但我保守了一点只用了8。为啥不拉满因为我遇到过并行编译任务开太多导致内存撑爆的。编译PostgreSQL时GCC的预处理阶段特别吃内存每个编译任务大约占1~2GB内存如果机器只有16GB内存开16个并行任务很容易把内存耗尽。到时候编译进程被内核杀掉前功尽弃还得重来。一般建议内存多少GB就用多少并行任务比如32GB内存用8~16个任务16GB内存用4~8个。编译过程根据CPU性能不同大约要5~15分钟。这一步出错比较少如果报了错90%的可能性是前置依赖没装全。常见的报错是找不到头文件比如fatal error: zlib.h: No such file or directory这就是zlib-devel没装。回到2.2节把依赖装全了重新编译。编译完成后安装make install到这里PostgreSQL软件本体就已经装好了。验证一下ls /usr/local/postgresql/bin/应该能看到initdb、postgres、psql、pg_ctl这些关键命令到这里安装阶段完成。注意如果后面还要装PostGIS、pgvector这类扩展插件源码目录先别删很多扩展编译需要用到PG的源码头文件删了还得重新下载。3.4 配置环境变量安装完成后要把PostgreSQL的bin目录加进PATH不然每次执行psql都要写完整路径繁琐也容易输错。编辑postgres用户的~/.bashrcsu - postgres vi ~/.bashrc在文件末尾追加export PATH/usr/local/postgresql/bin:$PATH export PGDATA/data/pgdata export LD_LIBRARY_PATH/usr/local/postgresql/lib:$LD_LIBRARY_PATHLD_LIBRARY_PATH这里特别提醒一下PostgreSQL的很多库文件不放在系统默认库路径下不把这个目录加进去启动服务时可能会报找不到libpq.so.5这类错误。这个变量是一定要加的。改完以后让配置生效source ~/.bashrc which psql能输出/usr/local/postgresql/bin/psql说明环境变量生效了。顺便说一句如果你习惯用root用户操作那把这三个变量也加到root的~/.bashrc里省得来回切换用户。数据库服务和数据文件归postgres用户管但排查问题时经常要用root去看系统日志两边都配好环境变量操作起来顺手得多。4. 初始化数据库与核心配置4.1 initdb初始化与premote认证说明这是整个部署流程里最容易出问题、也最需要谨慎对待的一步。初始化数据库一定要用postgres用户来跑su - postgres initdb -D /data/pgdata -E UTF8 --localeen_US.UTF8 -U postgres参数解释-D指定数据目录必须和前面创建的一致。-E UTF8指定数据库默认编码为UTF8。这个很重要现在业务数据基本都会涉及中文UTF8是通用标准。如果默认编码设成SQL_ASCII或GBK后面想转UTF8很麻烦导出再导入太折腾数据量大一点直接伤筋动骨。--localeen_US.UTF8指定数据库的初始化区域设置。这里有个坑如果系统里没有安装en_US.UTF8这个localeinitdb会报错。可以先执行locale -a查看系统支持的locale列表没有的话用localedef生成localedef -i en_US -f UTF-8 en_US.UTF-8-U postgres指定数据库超级用户名为postgres。这相当于MySQL里的root是整个数据库实例权限最高的账号。初始化完成以后日志最后会有一段提示说“You can now start the database server”。先别急着启动检查一个东西——认证配置文件pg_hba.conf。默认生成的配置在最底层有几行trust认证记录意思是不需要密码就能连上数据库这对于安全性要求高的生产环境是不可接受的。后面5.2节我会详细讲怎么改认证配置。注意initdb生成的初始密码是不是空的是这样的但这里的“空密码”不等于“无认证”。默认pg_hba.conf对本地连接配的是trust认证也就是本地任何用户都不用输入密码就能以任何数据库用户身份登录这个是相当危险的。虽然默认只允许本地连接服务器上只要有另一个账号被入侵数据库整个就暴露了。所以“初始化完立即改认证方式和密码”是必须要做的。4.2 postgresql.conf核心参数修改建议初始化完成后编辑/data/pgdata/postgresql.conf这里是最核心的配置文件。我把关键参数的调整思路说明一下vi /data/pgdata/postgresql.conflisten_addresses默认是localhost只允许本机访问。如果要让其他机器连数据库改成*或者指定IP。改成*表示监听所有网卡配合防火墙白名单来限制访问。如果你只让特定客户端连接写成具体IP比如192.168.1.100。port端口号默认5432前面configure时已指定不用改。如果系统里还跑着其他数据库比如人大金仓的默认端口也是5432记得错开。max_connections最大连接数默认100。要根据业务并发量调但也不是越大越好每个连接都要消耗内存连接数设置太高会导致内存吃紧。我一般按照“每连接额外消耗2MB内存左右”来估算。比如内存32GB预留一部分给系统max_connections设500左右比较合理。shared_buffers共享缓冲区这是最影响性能的参数之一。PG官方建议设为物理内存的25%比如32GB内存就设8GB。但要注意4GB以上需要系统共享内存参数支持如果系统内核参数没调设置太高会导致数据库启动失败。如果设置后启动报错可以先调回1GB再查看系统/etc/sysctl.conf中kernel.shmmax参数并调大。work_mem单个排序操作可以使用的内存默认4MB。这个参数不是越大越好因为它是按操作分配的并发高的场景下几百个排序操作同时执行每个4MB变成几百MB。一般先保留默认等业务上线后通过慢查询日志和性能监控逐步调优。effective_cache_size这不是实际分配内存的参数而是告诉优化器“系统大概有多少内存可以用于文件缓存”。一般设为物理内存的50%~75%设太低了可能导致优化器低估索引扫描的效率走全表扫描性能差很多。这个参数不影响实际内存分配设高一点没有风险。wal_level如果是生产环境做流复制要改成replica单机部署默认的replica即可。minimal级别虽然性能好一点但很多灾备功能用不了安全起见用replica。我做完这些修改后会先检查一遍文件内容确认没有语法问题再启动。注意PG配置文件是改一个生效一个不是大部分参数要重启数据库服务才生效小部分通过pg_ctl reload就能热加载比如max_connections要重启shared_buffers要重启work_mem可以热加载。不确定的参数改完统一重启服务。4.3 配置systemd服务实现开机自启动编译安装的PostgreSQL不会自动注册systemd服务每次手动pg_ctl start效率太低服务器重启后数据库也不会自动拉起来这在生产环境是绝对不行的。我写了一个systemd服务配置文件放到/etc/systemd/system/postgresql.service内容如下[Unit] DescriptionPostgreSQL database server Afternetwork.target [Service] Typeforking Userpostgres Grouppostgres PIDFile/data/pgdata/postmaster.pid ExecStart/usr/local/postgresql/bin/pg_ctl start -D /data/pgdata -l /data/pgdata/logfile ExecStop/usr/local/postgresql/bin/pg_ctl stop -D /data/pgdata -m fast ExecReload/usr/local/postgresql/bin/pg_ctl reload -D /data/pgdata TimeoutSec600 [Install] WantedBymulti-user.target配置说明Typeforkingpostgres主进程启动后会fork出子进程用这个类型systemd才能正确跟踪主进程状态。PIDFile指向postmaster.pid这个文件由PostgreSQL自动生成记录主进程PID。路径一定要和PGDATA一致不一致会导致systemd认为服务启动失败。ExecStop用-m fast快速关闭模式相当于SQL里的快速关机拒绝新连接并等待正在执行的事务完成然后再停。默认模式是smart会一直等所有客户端断连才停有长连接挂着可能等几个小时。运维中一般用fast比较合适。WantedBy让服务在系统进入多用户模式时自动启动。配置文件写好以后systemctl daemon-reload systemctl enable postgresql systemctl start postgresql systemctl status postgresql看到active (running)说明服务启动成功了。这里有一个编译安装最常见的坑pg_ctl start启动时可能报找不到libpq.so.5这个动态库。虽然我们在3.4节配置了环境变量但systemd启动服务时不会加载用户的环境变量只加载系统环境。解决方式是创建一个库文件配置echo /usr/local/postgresql/lib /etc/ld.so.conf.d/postgresql.conf ldconfig然后重启服务这个问题就解决了。5. 安全加固、远程连接与基础运维5.1 设置超级用户密码并调整pg_hba.conf认证初始化之后的第一件事给postgres用户设置密码su - postgres psql -c ALTER USER postgres WITH PASSWORD 你的强密码;密码复杂度建议至少12位包含大小写字母数字特殊字符。生产环境千万别用postgres、123456这种弱口令现在的安全扫描工具很成熟弱口令基本一抓一个准。然后编辑/data/pgdata/pg_hba.conf。这个文件是PG的访问控制清单决定谁能连、从哪连、怎么认证。我建议这样配置# 本地Unix套接字连接使用peer认证即系统用户和数据库用户同名即可连接仅限本地 local all all peer # 本机IPv4回环地址使用scram-sha-256加密认证 host all all 127.0.0.1/32 scram-sha-256 # 本机IPv6回环地址 host all all ::1/128 scram-sha-256 # 内网网段按实际调整 host all all 192.168.0.0/16 scram-sha-256peer认证的含义是“系统用户名 数据库用户名”即通过认证不需要密码。这个只对本地生效安全性尚可基于操作系统用户身份。对于远程连接全部用scram-sha-256密码加密认证。PostgreSQL 14里默认的密码加密方式就是scram-sha-256比老的md5安全得多。修改完pg_hba.conf以后执行pg_ctl reload让配置生效不需要重启数据库pg_ctl reload -D /data/pgdata注意每次改完pg_hba.conf之前建议先备份原文件。别问我为什么改错一个参数导致数据库拒绝所有连接然后手忙脚乱找回滚文件的经历一次就长记性了。5.2 防火墙与远程连接测试远程连接数据库除了PG侧的认证配置还要过防火墙这一关。用firewalld的话firewall-cmd --permanent --add-port5432/tcp firewall-cmd --reload如果是用iptables管理自己加一条规则iptables -A INPUT -p tcp --dport 5432 -j ACCEPT这里说一个我踩过的坑有些麒麟V10系统带了一个叫kysec的安全组件它会额外拦截网络端口的访问即使防火墙放行了也可能连不上。如果发现端口明明开着、数据库也在监听、防火墙也放行了但就是连不上第一反应看看是不是kysec的问题。这东西属于麒麟自带的强制访问控制机制命中了会在/var/log/messages里留下记录查看系统日志是一个很有效的排查路径。配置完成后在内网的另外一台机器上测试连接psql -h 192.168.1.10 -p 5432 -U postgres -d postgres输入密码能连上并进入psql交互界面就说明整个链路是通的。提示一下客户端也需要安装PostgreSQL的客户端工具包如果在Windows上可以用pgAdmin或者直接用psql命令行。5.3 数据库日常启停、日志查看与备份命令部署完成不代表结束日常运维手段才是保障生产稳定性的关键。核心命令我整理了一份速查清单systemctl start postgresql # 启动数据库 systemctl stop postgresql # 停止数据库 systemctl restart postgresql # 重启数据库 systemctl status postgresql # 查看运行状态 pg_ctl reload -D /data/pgdata # 热加载配置无需重启 tail -f /data/pgdata/logfile # 实时查看数据库日志日志这块PG的默认配置是把日志输出到stderr再转写到日志文件。我在postgresql.conf里还改了logging_collector为on并设置log_directory log这样日志会统一放到PGDATA/log目录下按天滚动方便排查问题。生产环境建议将log_min_duration_statement设为1000ms记录执行超过1秒的慢SQL这是后续性能调优的重要依据。备份是最不能忽视的环节。PG的单机备份最简单有效的方式是pg_dump# 备份单个数据库 pg_dump -h localhost -U postgres -d 你的数据库名 -F c -f /backup/库名.dump # 还原数据库 pg_restore -h localhost -U postgres -d 新库名 -c /backup/库名.dump-F c是自定义压缩格式比纯SQL脚本体积小也便于pg_restore选择性恢复。生产环境建议至少每天做一次全量备份保留最近7天的备份文件再用cron定时任务在凌晨自动执行。如果允许停机一小会儿物理备份pg_basebackup是更完整的方案可以配合WAL归档实现时间点恢复那个功能更强大这里篇幅有限不多展开。5.4 常见问题排查与避坑经验整合把我在这次部署中遇到的和网上反馈比较多的问题整理成一个速查表方便直接对照排查问题现象可能原因解决方法configure阶段报错找不到zlib.h缺zlib-devel包yum install zlib-devel编译时报c compiler cannot create executablesgcc未装或版本不对yum install gcc make确认gcc可用initdb报locale不存在系统缺en_US.UTF8区域localedef -i en_US -f UTF-8 en_US.UTF-8启动时报Permission denied目录权限不对chown postgres:postgres -R /data/pgdata启动时报could not identify version of libpqLD_LIBRARY_PATH没有设置添加export LD_LIBRARY_PATH/usr/local/postgresql/lib:$LD_LIBRARY_PATHsystemd启动但是状态异常PIDFile路径或权限不对检查postmaster.pid的属主和路径远程连接超时防火墙/kysec拦截检查防火墙策略和/var/log/messages远程连接提示no pg_hba.conf entrypg_hba.conf配置遗漏按5.1节配置添加对应网段条目提示password authentication failed密码错误或认证方式不匹配检查pg_hba.conf用的认证方式和密码算法是否一致psql命令找不到PATH没有包含PG的bin目录配置环境变量PATH重新source服务器重启后数据库没起来systemd服务没有enablesystemctl enable postgresql以上每一条我都实际遇到过或验证过按图索骥一般能解决大部分问题。如果你遇到的是表里没有的怪异错误先看数据库日志文件通常日志里会有明确的原因提示。我处理过太多“报错不看日志直接百度”的人了最后绕了一圈回来发现日志里早就把原因写清楚了。学会看日志是数据库运维的入门基本功。6. 整体安全性补充系统加固思路与扩展方向6.1 ARM架构下的关键内核参数调优与内存管理PostgreSQL在大内存机器上有一些内核参数需要调一调否则性能发挥不出来。编辑/etc/sysctl.confkernel.shmall 1073741824 kernel.shmmax 274877906944 vm.overcommit_memory 2 vm.overcommit_ratio 90shmmax和shmall是System V共享内存的上限参数。PG的shared_buffers如果设置的比较大就依赖这个参数。不调的话shared_buffers设8GB可能启动报错日志提示无法分配共享内存。vm.overcommit_memory 2表示系统执行严格的内存过载检查配合vm.overcommit_ratio控制总内存分配比例。这个参数在PG社区里有一定争议改完以后如果业务方有单独申请大内存的程序可能被拒。我的建议如果对Linux内存管理不够熟只改shmmax和shmall就够了overcommit这块保持默认别上来就一顿乱调反而搞出问题。ARM架构下还有一个特殊优化点如果CPU支持LSELarge System Extension原子指令编译时加上-marcharmv8.1-a这个编译选项可以让PostgreSQL在高并发下减少内核锁竞争性能提升明显。但这个选项要求CPU必须支持ARMv8.1指令集老一点的ARMv8.0芯片不支持加了反而可能编译出非法指令。我的处理方式先查lscpu里的Flags看到有atomics字样就支持加上没有就不加稳定优先。6.2 升级、卸载与扩展插件的后续思路部署完成以后随着版本更新和业务扩展“升级”和“卸载”这两件事早晚要遇到。这里把思路梳理一下。PG的小版本升级很简单下载新版源码configure make make install然后重启服务数据目录不需要迁移。PG的小版本升级是兼容的完全支持原地覆盖。大版本升级比如从14升到15要复杂一些需要用pg_upgrade工具这个工具要求新旧版本都装在同一台机器上而且会锁库需要配合业务停机窗口操作前一定先把备份做扎实。卸载的话我一般不用make uninstall因为编译安装在/usr/local/postgresql目录下非常集中直接systemctl stop postgresql rm -rf /usr/local/postgresql rm -rf /data/pgdata userdel postgres干干净净不留残余。这就是编译安装的好处想卸就卸不会像rpm包那样卸载时还要处理各种依赖关系。扩展插件方面如果你后面要装PostGIS空间数据、pgvector向量检索这类扩展源码目录一定要保留。以pgvector为例编译流程是cd /opt/pgvector-0.7.4 make PG_CONFIG/usr/local/postgresql/bin/pg_config make install PG_CONFIG/usr/local/postgresql/bin/pg_config因为扩展插件编译时要通过pg_config找到PostgreSQL的头文件和库文件如果不指定PG_CONFIG路径系统会在默认路径找很可能找不到编译安装的PG最后报一堆莫须有的错误。所以建议源码目录直接留在/opt下别删。6.3 从单机到主从复制的基本过渡方案单机部署跑通以后你很可能下一步会面临高可用问题——数据库挂了怎么办。这里简单说下从单机到主从复制的思路。PG的主从复制非常简单主库配置需要wal_level replica max_wal_senders 10 max_replication_slots 10备库从主库做一个基础备份pg_basebackup -h 主库IP -p 5432 -U repuser -D /data/pgdata -F p -R然后在备库的standby.signal文件-R参数自动生成里就有standby_modeon再配置primary_conninfo指向主库IP即可。整个过程比MySQL的主从简单不少但需要注意两点一是要创建专门的复制账号不能直接用postgres超级用户二是主从之间的网络延迟影响比较大尽量在同一内网机房部署。说回这次的完整部署过程。我在实际安装中最大的体会是银河麒麟V10 ARM上的数据库部署硬骨头不在PostgreSQL本身而在环境适配。一旦把依赖管理、编译参数、系统服务这几个关节打通了后面跑起来是非常稳的。我现在这套环境已经连续运行了几个月没有出现过异常重启、数据损坏之类的问题日常的备份、监控、慢查询日志都在正常工作。如果你也在搞国产化环境下的数据库部署希望这篇记录能帮你少走几个弯路。最后再分享一个习惯每次部署完数据库把操作系统版本、内核参数、PG版本、配置文件的关键选项都记到一个文档里。半年以后你要排查一个诡异问题这个文档可能比搜索引擎都管用。祝顺利。