PostgreSQL 12.0源码编译安装实战：从环境准备到生产部署

1. 为什么我还在坚持源码编译安装PostgreSQL 12.0先说一个很多刚入门的朋友会问的问题明明Linux发行版自带的软件源里就有PostgreSQL或者有Docker镜像可用为什么还要折腾源码编译安装我自己的答案是——这不是折腾是对环境掌控力的要求。当你需要在离线网络环境、特定硬件平台、或者需要定制某些编译参数时源码安装几乎是唯一可靠的选择。PostgreSQL 12.0虽然不是最新版本但在很多企业生产环境中依然是主力版本。这个版本引入了不少实质性改进比如可重复读的vacuum性能优化、通用表达式CTE的增量排序还有分区表的性能大幅提升。更重要的是对于国产化替代、信创环境适配这些场景很多组织都会指定在特定CPU架构和操作系统版本上部署PostgreSQL 12.x这时候发行版自带的版本可能根本不是12.0版本对不上就只能源码编译。还有一层考虑是安装路径的可控性。源码编译安装时二进制文件、数据目录、配置文件、日志文件的存放位置都由你说了算这对后续做备份脚本、监控采集、安全加固都非常重要。用发行版自带的安装方式文件散落在系统各处要改路径很麻烦。这篇文章我会完整走一遍PostgreSQL 12.0在Linux环境下的源码安装部署流程其中包含我在实际项目实施中踩过的坑、补充的细节和调优思路希望对你有实质性帮助。2. 版本选择背后的现实考量2.1 为什么是12.0而不是更新的版本PostgreSQL的版本演进速度很快截至目前新版本已经迭代了很多代。但选择12.0的原因往往不是“最新”而是“最合适”。首先12.0是支持在线reindex的基准版本在12.0之前在线reindex需要依赖第三方插件这在生产库维护中相当实用。其次12.0的分区表改进使得分区裁剪和分区聚合的计划生成效率显著提高很多从老版本如9.x、10.x升级上来的系统性能提升是肉眼可见的。更重要的是源码编译安装12.0在后期的大版本升级路径上是清晰且平滑的。官方文档明确指出从12.x可以借助pg_upgrade工具直接升级到更新的版本比如14、15、16升级路径经过大量验证风险相对可控。相比之下如果直接从10.x跳到16.x升级跨度太大很多行为变化集中爆发排错的复杂度会成倍上升。2.2 和二进制包安装的对比有人会问直接用apt install postgresql-12或者yum install postgresql12不就行了确实软件包管理器安装有它的优势比如依赖自动处理、启动脚本自动生成。但它也存在明显的局限性版本依赖仓库维护状况软件源里的版本往往是固定的不一定有12.0这个小版本号有时是12.7、12.15等不是你想精确安装12.0就可以的。目录结构不统一不同的发行版对配置文件、数据目录的默认路径定义不同在CentOS上是/var/lib/pgsql/12/data在Ubuntu上又是/var/lib/postgresql/12/main这套路径换一个环境就要重新适应。包含若干额外扩展包很多时候需要的插件没有对应打包比如PostGIS、TimescaleDB这些用源码编译反而更容易自行处理。源码编译安装的核心优势在于参数可定制、目录可定制、行为可预期。比如你可以通过configure参数决定是否启用--with-python、--with-perl、--with-icu、--with-ssl等特性这些都是生产环境中真正需要的东西。下面进入正题我先从环境准备开始讲。3. 环境准备与依赖检查3.1 编译环境的必备组件开始之前首先要确保Linux系统具备编译工具链。PostgreSQL 12.0使用C语言编写编译过程依赖GCC、Make等工具。同时它还需要一些开发库比如readline-devel命令行历史功能、zlib-devel压缩支持等。我以CentOS 7.8 x86_64环境为例来说明因为这套流程我跑过很多次最有把握。如果你用的是Ubuntu/Debian系把对应的包名替换成build-essential、libreadline-dev、zlib1g-dev即可。# CentOS/RHEL系列 yum install -y gcc gcc-c make readline-devel zlib-devel libxml2-devel openssl-devel# Ubuntu/Debian系列 apt update apt install -y build-essential libreadline-dev zlib1g-dev libxml2-dev libssl-dev这里有个值得注意的点openssl-devel或libssl-dev一定要装。如果不装后续configure的时候--with-openssl选项就无法启用远程连接走SSL加密通道的能力就缺失了。很多生产环境的合规检查里这一条是硬性要求。如果你还计划在PostgreSQL里跑PL/Python、PL/Perl等过程语言还需要额外装对应的开发包比如python3-devel、perl-ExtUtils-Embed。实际经验告诉我缺依赖的时候最常见的情况是configure步骤直接报错退出。与其反复试错不如先一次性装齐全。下面这张表是我整理的最小依赖清单组件作用缺失后果gcc、make编译核心工具无法编译readline-devel命令行编辑和历史记录configure报错psql体验差zlib-devel数据压缩支持pg_dump备份压缩不可用openssl-develSSL加密连接无法启用SSLlibxml2-develXML数据类型支持configure无法启用libxml2python3-develPL/Python过程语言支持无法启用Python扩展3.2 创建一个专用的操作系统用户PostgreSQL的官方安全规范是绝不允许以root用户运行数据库服务器。原因不复杂如果数据库被攻击攻击者能拿到root权限整个系统就会沦陷而以普通用户运行时攻击者拿到的权限会被限制在一个普通用户范围内。这不是危言耸听我见过不少因为用root启动数据库造成的安全问题。groupadd postgres useradd -g postgres -m -s /bin/bash postgres passwd postgres创建好用户后后续所有操作身份切换到postgres用户下进行。养成这个习惯后面少很多麻烦。3.3 确定安装目录与数据目录目录规划这块我建议在项目初始就定好规范。我常用的划分方式是软件安装目录/usr/local/pgsql12数据目录/data/pgsql12/data日志目录/data/pgsql12/log数据目录和数据文件独立挂载磁盘是生产环境的常见做法。这样做的目的是避免系统盘被数据撑爆同时也便于后续做磁盘扩容和备份策略。数据目录如果放在系统盘上一旦系统盘IO性能受限数据库性能也会跟着受影响。创建目录并设置权限mkdir -p /usr/local/pgsql12 mkdir -p /data/pgsql12/data mkdir -p /data/pgsql12/log chown -R postgres:postgres /usr/local/pgsql12 chown -R postgres:postgres /data/pgsql12注意这两个目录的所有者必须改成postgres用户不然后续初始化数据库时因为权限不足会直接报could not open directory类似的错误。4. 源码下载与编译安装全流程4.1 获取源码包PostgreSQL的官方下载地址是https://www.postgresql.org/ftp/source/v12.0/这里能找到所有官方发布的版本源码。你也可以从国内镜像站下载速度更快。源码包的文件名一般是postgresql-12.0.tar.gz。cd /tmp wget https://ftp.postgresql.org/pub/source/v12.0/postgresql-12.0.tar.gz tar -zxvf postgresql-12.0.tar.gz cd postgresql-12.0这里提醒一点——下载后建议先做md5校验。官网页面会给每个源码包提供md5和sha256值下载完用md5sum postgresql-12.0.tar.gz对比一下。虽然是开源软件但防止下载损坏或者被篡改这一步还是值得做的。如果你在的服务器网络环境访问官方源速度极慢可以考虑使用华为云、阿里云或者清华镜像站的PostgreSQL源码镜像。源码包的完整性校验方式是一样的。4.2 configure参数的选择逻辑进入解压后的源码目录执行configure脚本。这是整个安装过程中最具定制性的一步。我的推荐参数如下./configure --prefix/usr/local/pgsql12 \ --with-pgport5432 \ --with-openssl \ --with-libxml \ --with-perl \ --with-python \ --with-icu \ --with-systemd逐个解释这几个参数的含义和选择理由--prefix/usr/local/pgsql12安装路径。所有二进制文件、库文件、头文件都会安装到这个目录下后续卸载时只需删除该目录即可干净利落。--with-pgport5432指定默认的数据库端口。PostgreSQL的默认端口就是5432明确写出来是便于确认也防止将来用默认配置时产生困惑。--with-openssl启用SSL支持远程传输时数据加密这是安全基线要求。--with-libxml启用XML数据类型的支持。虽然现在JSON用得多但也保不齐有业务用到XML有备无患。--with-perl和--with-python启用PL/Perl和PL/Python过程语言支持。很多数据分析任务会用到PL/Python在函数内部直接调用Python生态的库这个能力在生产中价值不小。--with-icu启用ICUInternational Components for Unicode国际化支持对多语言排序、字符集处理更稳定尤其处理中文排序时比默认的libc排序更符合预期。--with-systemd支持systemd集成这样后续可以把PostgreSQL注册为systemd服务统一管理、开机自启都会很方便。这里有个小陷阱启用了--with-python后configure会去检查Python的头文件和库文件是否存在如果系统里只有Python 2.x而没有Python 3.x的开发包或者装的是python3但缺少对应的python3-devel都会在这里报错。我平时在CentOS 7环境会特意确认yum install -y python3-devel。同时在configure前设置PYTHON/usr/bin/python3强制指定版本。4.3 编译安装与常见错误处理configure执行完成后如果没有报错就可以进入编译和安装环节了。这里我按并行编译执行充分利用多核CPU优势make -j 4 make install-j 4的意思是启用4个编译任务并行执行。如果你的服务器CPU核数更多可以适当调大这个数字比如-j 8。如果内存资源紧张并行任务太多可能导致内存耗尽这时候降低并行数或者干脆不加-j参数。编译安装过程中我在不同机器上遇到频率最高的错误有这么几类c compiler cannot create executables基本可以断定是GCC没装好比如装了gcc但没有gcc-c或者系统里存在多个版本的GCC导致链接混乱。处理办法是重新检查编译工具链。readline library not found缺失readline-devel库按上面环境准备阶段装好即可。could not find suitable Python development headers缺少Python开发头文件。在CentOS上执行yum install -y python3-develUbuntu上执行apt install -y python3-dev。ICU library not found缺少ICU开发包。CentOS执行yum install -y libicu-develUbuntu执行apt install -y libicu-dev。编译完成后make install会把所有文件复制到/usr/local/pgsql12目录下这一步基本是一帆风顺的。安装完成后确认一下ls /usr/local/pgsql12/bin/能看到postgres、initdb、pg_ctl、psql这些可执行文件基本就到位了。5. 初始化数据目录与首次启动5.1 环境变量配置为了让postgres用户日常操作时不用总是输入完整路径配置环境变量是必要的。编辑~/.bashrc文件vi /home/postgres/.bashrc追加以下内容export PGHOME/usr/local/pgsql12 export PGDATA/data/pgsql12/data export PATH$PGHOME/bin:$PATH export LD_LIBRARY_PATH$PGHOME/lib:$LD_LIBRARY_PATH执行source ~/.bashrc让配置立即生效。这里我多说一句为什么要单独设置PGDATA这个环境变量——PostgreSQL的很多工具比如pg_ctl、pg_basebackup在未显式指定数据目录时会读取这个变量。提前设置好后面不少命令省略了-D参数也不会找错路径。5.2 initdb初始化数据库初始化数据库这一步是最容易被新手搞砸的一步因为一旦失败后面的所有操作都无法继续。建议先明白这件事的原理initdb的作用是创建一个基础的数据目录其中包含系统表、默认数据库postgres和template1、配置文件模板postgresql.conf、pg_hba.conf等。它并不创建一个具体的业务数据库先有个完整的基础架构。此时必须切换到postgres用户操作su - postgres initdb -D /data/pgsql12/data --encodingUTF8 --localeen_US.UTF-8 --authtrust参数解释-D指定数据目录位置。--encodingUTF8设置默认数据库编码为UTF-8。除非你有非常特殊的理由否则永远不要绕开UTF-8。在生产环境里因为编码不统一导致的乱码问题排查起来让人极其崩溃。--localeen_US.UTF-8设置系统的locale影响字符串排序规则和字符分类行为。这里要注意——Linux的locale设置会直接影响PostgreSQL的文本比较行为。如果你的操作系统没有安装这个locale会报错需要用localedef命令生成或者改用--localeC或--localeC.UTF-8作为替代方案。--authtrust本地连接的认证方式设为trust免密码。这一项只是为了让首次启动测试更容易通过后续生产环境配置中必须改成md5或scram-sha-256。初始化成功的标志是看到类似Success. You can now start the database server using:这样的提示并且data目录下出现了PG_VERSION文件、base/目录、global/目录等内容。5.3 首次启动数据库并验证启动方式一使用pg_ctlpg_ctl -D /data/pgsql12/data -l /data/pgsql12/log/pgsql.log start-l参数指定日志文件的路径。启动后可以通过以下命令验证进程是否存活ps -ef | grep postgres正常情况下你会看到多个进程包括postgres主进程和一些辅助进程checkpointer、background writer、walwriter等。看到这些说明核心进程已经跑起来了。然后尝试连接一下psql -U postgres -d postgres如果一切正常你会进入psql的交互界面。首次启动还有一件重要的事——设置数据库超级用户的密码ALTER USER postgres WITH PASSWORD 你的强密码;校验之后退出\q到这里一个最小可用的PostgreSQL 12.0实例已经跑起来了。但生产环境远远没结束接下来要处理服务化管理、远程访问配置和日常运维工具的部署。6. systemd服务化管理的落地配置6.1 为什么需要服务化管理默认的pg_ctl start方式启动数据库后进程挂在当前会话下一旦终端断开或服务器重启数据库不会自动恢复。在开发环境勉强可以接受但在生产环境这样搞很容易出事故。把PostgreSQL注册为systemd服务后可以实现开机自启、崩溃自动拉起、统一日志管理、通过systemctl status postgresql随时查看状态运维体验完全不同。6.2 编写systemd unit文件由于我们是源码编译安装发行版不会自动携带对应的systemd服务文件需要自己写一个。在/etc/systemd/system/postgresql-12.service文件中写入[Unit] DescriptionPostgreSQL 12.0 database server Afternetwork.target [Service] Typeforking Userpostgres Grouppostgres EnvironmentPGDATA/data/pgsql12/data ExecStart/usr/local/pgsql12/bin/pg_ctl -D /data/pgsql12/data -l /data/pgsql12/log/pgsql.log start ExecStop/usr/local/pgsql12/bin/pg_ctl -D /data/pgsql12/data stop ExecReload/usr/local/pgsql12/bin/pg_ctl -D /data/pgsql12/data reload PIDFile/data/pgsql12/data/postmaster.pid Restartalways RestartSec10 TimeoutSec300 [Install] WantedBymulti-user.target这里有几个关键点Typeforking表示启动命令在执行后会将进程转为后台守护进程systemd会跟踪主进程的PID文件来判断服务是否启动成功。PostgreSQL正是这种工作模式所以要这么配。PIDFile/data/pgsql12/data/postmaster.pidPostgreSQL在启动时会在数据目录下生成一个postmaster.pid文件记录主进程PID。systemd根据这个文件判断服务的运行状态。Restartalways如果数据库进程意外退出10秒后自动拉起。这一项在无人值守的生产环境中极其重要数据库崩了能自动恢复而不是等到用户发现才处理。TimeoutSec300有些大实例在启动时需要较长时间进行恢复比如崩溃恢复默认的90秒超时时间经常不够调大是踩过坑之后得出的经验。配置好之后依次执行systemctl daemon-reload systemctl enable postgresql-12 systemctl start postgresql-12 systemctl status postgresql-12需要注意的是使用systemd管理后不要再手动用pg_ctl start去启动数据库否则systemd会认为状态异常管理上会出现混乱。我在迁移到systemd管理时会先pg_ctl stop停掉手动启动的实例再统一走systemctl。7. 远程访问配置与防火墙放行7.1 postgresql.conf监听地址调整默认情况下PostgreSQL只监听本机回环地址127.0.0.1外部机器无法直接连接。要让其他机器通过网络访问数据库需要修改配置文件。编辑/data/pgsql12/data/postgresql.conf找到并修改以下参数listen_addresses * port 5432将监听地址设为*表示监听所有网卡地址。如果只想让特定IP访问可以写具体的IP地址比如192.168.1.10。这里我建议出于安全考虑优先明确指定内网IP而不是简单放通全部网卡。修改完配置后重启数据库使配置生效systemctl restart postgresql-127.2 pg_hba.conf认证规则配置PostgreSQL的访问控制体系是通过pg_hba.conf文件实现的这个文件定义了哪些主机、哪些用户、访问哪些数据库、用哪种认证方式。默认配置里只有本地连接远程连接需要追加规则。编辑/data/pgsql12/data/pg_hba.conf在文件末尾追加# 允许内网192.168.1.0/24网段的所有IP以scram-sha-256方式连接所有数据库 host all all 192.168.1.0/24 scram-sha-256 # 允许内网10.0.0.0/8网段的所有IP以scram-sha-256方式连接所有数据库 host all all 10.0.0.0/8 scram-sha-256认证方式我统一推荐scram-sha-256。这是目前PostgreSQL支持的最安全的密码认证协议比旧的md5认证强度高得多。默认安装的PostgreSQL 12.0已经支持这种认证方式不需要额外编译参数。修改完pg_hba.conf后执行以下命令使配置生效无需重启systemctl reload postgresql-12reload和restart的区别在于reload只是重新加载配置文件不影响正在运行的会话适合这个场景。对生产环境来说能reload解决的问题就尽量不要重启。7.3 防火墙与云安全组放行远程连接失败的案例中有相当高的比例是数据库配置本身没有问题但系统防火墙阻断了端口。在CentOS 7上默认的firewalld防火墙一般是开启的需要放行5432端口firewall-cmd --permanent --add-port5432/tcp firewall-cmd --reload如果你用的是云服务器还要检查云服务商的安全组规则在控制台里把5432端口的入方向流量放行。这个步骤在阿里云、腾讯云、华为云等平台上是独立于服务器系统的很容易被忽略。7.4 远程连接测试在客户端机器上用psql命令测试连接psql -h 192.168.1.100 -p 5432 -U postgres -d postgres输入正确的密码后能进入psql交互界面说明远程连接已经打通。如果连接报错常见情况我整理成下面的排查表报错信息原因解决办法Connection refused数据库未监听或防火墙拦截检查监听地址配置、防火墙规则No route to host网络不通或安全组未放行检查网段、ping通性、云安全组规则password authentication failed密码错误或认证方式不对重置密码检查pg_hba.conf认证方式no pg_hba.conf entry for hostpg_hba.conf未放行该IP追加对应网段的访问规则8. 基础运维命令与排错方法8.1 psql常用操作和日常检查数据库部署完成后日常的巡检和运维操作是必不可少的。我把最常用的命令整理在这里方便对照执行。查看数据库列表、大小和连接数-- 查看所有数据库 \l -- 查看当前实例所有数据库占用空间 SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database; -- 查看当前连接信息 SELECT datname, usename, client_addr, state FROM pg_stat_activity;查看PostgreSQL运行参数和状态-- 查看关键配置参数 SHOW shared_buffers; SHOW max_connections; SHOW listen_addresses; -- 查看数据库启动时间 SELECT pg_postmaster_start_time();日常巡检时重点关注慢查询和长事务。慢查询可以用pg_stat_statements插件来跟踪长事务可以通过pg_stat_activity中的xact_start字段判断。生产环境经常遇到的问题是某个应用连接一直挂着不提交事务导致vacuum无法清理旧数据表膨胀严重。出现这种迹象时需要及时定位并处理。8.2 日志管理要点PostgreSQL的系统日志默认会写到后端日志文件里我们前面已经在启动命令里指定了日志路径/data/pgsql12/log/pgsql.log。但在高负载生产环境中单一切割的日志文件会越来越大不便于排查问题。建议在postgresql.conf中配置日志轮转logging_collector on log_directory log log_filename postgresql-%a.log log_truncate_on_rotation on log_rotation_age 1d log_rotation_size 100MB按天生成日志文件同时限制单个文件大小。这样日志管理起来清晰很多后续接入集中式日志采集平台比如ELK或Loki也方便。8.3 常见运行故障的排查思路数据库运行中遇到故障时我的排查顺序基本都是先看日志再查资源后用手工命令验证。PostgreSQL日志文件里会记录所有错误信息找到对应时间点的报错是最直接的方式。比如启动失败的日志里会明确告诉你数据目录权限错误、磁盘空间不足、端口被占用等具体原因。系统层面用df -h看磁盘空间用free -h看内存用top看CPU。PostgreSQL是对IO和内存都比较敏感的服务磁盘满了会导致数据库直接罢工这是线上最常见的事故原因之一。举一个我实际遇到过的例子某次数据库突然无法写入应用侧报could not write to file pg_wal/xlogtemp No space left on device。查完df -h发现数据目录所在的磁盘没有满但df -i显示inode已经耗尽。原因是一个脚本大量创建小文件但没有清理把inode资源耗光了。这种情况下即使有剩余磁盘空间数据库也无法创建新文件。后来处理办法是找出无用的小文件清理掉对相关应用做了磁盘配额。9. 安全加固与日常维护经验补充9.1 不要忽略basic的加固措施部署刚完成很多人就会立刻投入业务开发但安全加固这一步不能省。我通常按以下顺序进行加固首先修改默认的超级用户密码这个在前面已经提过就不再重复。其次创建业务专用账号而不要让业务系统直接使用postgres超级用户连接数据库。最小权限原则是数据库安全管理的基本要求。创建业务账号的方式CREATE USER app_user WITH PASSWORD 安全的密码; CREATE DATABASE app_db OWNER app_user;然后回收超级用户的远程登录权限。生产环境的PostgreSQLpostgres用户最好只留在本地Unix socket或者在受控的堡垒机上使用远程连接一律用业务账号。对应在pg_hba.conf里可以这么配置# 本机socket连接postgres用户可登录 local all postgres peer local all all scram-sha-256 # 远程仅允许业务账号连接 host all app_user 192.168.1.0/24 scram-sha-256 host all postgres 127.0.0.1/32 scram-sha-256这样配置后远程就算想用postgres用户也连不上整体安全等级会明显提高。9.2 数据备份的核心思路PostgreSQL的备份方案有很多种最基本的是使用pg_dump进行逻辑备份pg_dump -U app_user -h localhost -d app_db -F c -f /backup/app_db_$(date %Y%m%d).dump-F c指定自定义格式这种格式可以使用pg_restore进行选择性恢复灵活性高。配合crontab定期执行可以形成基本的备份机制。更高级的是基于WAL连续归档的PITR时间点恢复方案这个能支持恢复到指定时间点应对误操作场景非常关键。虽然在本文中不展开讲但你要知道源码编译的PostgreSQL同样支持这些功能相关归档参数archive_mode、archive_command在postgresql.conf中都能找到。9.3 常见配置参数调优方向刚部署完的PostgreSQL默认参数偏向保守并不算最优。针对不同业务场景以下几个参数值得根据机器实际规格调整shared_buffersPostgreSQL自身的共享缓冲区大小一般建议设为物理内存的25%左右。比如32GB内存的机器可以设置约8GB。注意设得过大可能会导致操作系统换页性能反而下降。work_mem单个排序或哈希操作能使用的内存上限。这个值不是越大越好因为它是每个查询每个排序操作都可能分配的设置过大时并发高场景下内存容易被打满。maintenance_work_memVACUUM、创建索引等维护操作使用的内存建议比work_mem设得大一些有助于加快索引重建速度。effective_cache_size操作系统文件缓存大小的估计值一般设为物理内存的50%~75%。这个参数影响查询规划器对索引扫描和顺序扫描的决策倾向。改动这些参数后重启数据库才能全部生效work_mem和effective_cache_size属于可以reload的参数但shared_buffers必须重启。调优没有万能公式务必要结合你自己系统的负载测试结果来调节。9.4 版本演进与后续升级提醒如果你打算借这篇博文在自己的环境中落地PostgreSQL 12.0我建议你在熟悉基本操作之后再加一个意识PostgreSQL 12这个系列虽然是经典版本但也会慢慢进入维护期的尾声。在用12.0完成学习和项目原型之后要关注官方的安全公告和补丁更新及时升级到12.x系列的最高小版本甚至在条件允许的时机规划升到更高的主版本。升级到更高版本时pg_upgrade工具可以很大程度简化操作但升级前一定要先做完整备份并在测试环境走一遍流程不要直接在生产环境动刀。我个人的习惯是无论多自信正式升级前都至少演练两遍一遍是纯命令流程验证一遍是模拟真实数据量的压力演练。最后再分享一个我自己的小习惯每次部署完成后把数据库的安装路径、数据目录、配置参数、初始化时间、采用的编译参数和当时踩过的坑都记录在一个本地文件里。等过几个月再回来看这些信息往往帮大忙——定位问题、审计合规、交接给同事都靠它。PostgreSQL 12.0在Linux下的源码安装部署核心流程就是这样。你可能会在不同版本的Linux或者不同硬件架构上遇到一些细节差异但大的框架和思路完全通用。按照这套流程走下来一个稳定、安全、可控的PostgreSQL环境就落地了后面就是按照业务需求逐步深入使用的阶段了。