背景高可用能力是公认的数据库必备能力也是一款数据库产品的核心竞争力之一。资源充沛的时候我们可以配置一主一备或者一主多备通过主备复制同步数据实现故障场景的快速切换。再结合代理能够自动实现读写均衡和对主节点的跟踪这似乎是一个较为完美的高可用方案。但是切换不是一个简单的动作对于pg来说还要维护新的流复制关系。一主多备场景下主节点的切换需要每个备库重新配置primary_info等参数并重启。主备存在延迟情况下切换还会丢失数据。虽然可以配置强同步复制模式但是对性能影响较大同时备库挂掉还会影响主库可用。另外虽然备库可以作为只读节点提供服务但是由于复制延迟等原因难以保证全局数据一致性只读节点的利用率很难提升浪费了很多资源。更极端的场景下有时候受条件所迫只有一台主机那主备切换的高可用方案就毫无用武之地了。综上所述主备切换不是完美的方案给pg的运维增加了很多难度如果能在故障场景下不需要切换就快速原地恢复数据库那无疑是更好的选择。自然地我们想到了用一个守护进程来管理postgres能在postgres主进程退出的时候重新拉起数据库最好能在机器重启之后也能把数据库自动启动。 systemd 就是其中一个方案。systemdsystemd是Linux的系统工具它的设计目标是为系统的启动和管理提供一套完整的解决方案。 根据 Linux 惯例字母d是守护进程daemon的缩写。 Systemd 这个名字的含义就是它要守护整个系统。为了用systemd管理postgres我们可以完成以下几步Step 1: 创建systemd单元文件首先创建一个新的systemd单元文件。这个文件通常会被放在/etc/systemd/system目录下。sudo nano /etc/systemd/system/postgresql.service文件中添加以下内容[Unit] DescriptionPostgreSQL database server Afternetwork.target [Service] Typeforking Userpostgres Grouppostgres # Environment variables EnvironmentPGDATA/var/lib/postgresql/data # Commands to manage the service ExecStart/usr/pgsql/bin/pg_ctl start -D ${PGDATA} -l ${PGDATA}/logfile ExecStop/usr/pgsql/bin/pg_ctl stop -D ${PGDATA} -s -m fast ExecReload/usr/pgsql/bin/pg_ctl reload -D ${PGDATA} # Restart settings Restarton-failure RestartSec5 # Limits LimitNOFILE65536 LimitNPROC65536 [Install] WantedBymulti-user.targetStep 2: 重新加载systemd配置保存并关闭文件后重新加载systemd配置sudo systemctl daemon-reloadStep 3: 启动并启用 PostgreSQL 服务使用以下命令启动并启用 PostgreSQL 服务# 启动服务 sudo systemctl start postgresql # 设置为开机自启 sudo systemctl enable postgresqlStep 4: 检查服务状态你可以使用以下命令检查服务的状态确保它正在运行sudo systemctl status postgresql示例解释[Unit] 部分Description: 描述功能。Afternetwork.target: 确保网络服务启动后才启动此服务。[Service] 部分Typeforking: 指定服务会在启动时派生一个新的进程。User和Group: 指定运行该服务的用户和组这里设置为postgres。Environment: 定义环境变量指定数据目录位置。ExecStart: 启动服务的命令。ExecStop: 停止服务的命令。ExecReload: 重新加载配置的命令。Restart和RestartSec: 指定服务在失败后的重启策略。LimitNOFILE和LimitNPROC: 设置打开文件和进程的限制。[Install] 部分WantedBymulti-user.target: 指定该服务在多用户模式下启动。这个示例假设 PostgreSQL 安装在/usr/pgsql/bin/目录下数据目录为/var/lib/postgresql/data。请根据你的实际情况调整路径。通过这个systemd配置文件你可以使用systemctl命令方便地管理 PostgreSQL 服务。例如启动服务:sudo systemctl start postgresql停止服务:sudo systemctl stop postgresql重新加载配置:sudo systemctl reload postgresql查看状态:sudo systemctl status postgresql缺点systemd 将被守护的程序进程维护在其 cgroups 层级结构中一旦进程退出可以重新拉起但是这要求被守护的程序只能被 systemd 来启动和停止一旦它被其他程序重启就脱离了守护。而用户习惯使用 pg_ctl 来管理数据库一旦用户使用 pg_ctl 停止或者重启了数据库就会导致数据库守护状态与实际运行状态不一致从而脱离守护。最好有一个支持通过 pid 文件如 pg 的 postmaster.pid来守护被托管程序的方案。尽管 systemd 也支持指定 PIDFile但是它不以此作为守护状态的依据仅会在停止被守护程序的时候清理它因为在 docker 容器中使用 systemd 需要特权模式privileged启动但是开启了 privileged 的容器可以访问宿主上所有设备几乎享有宿主上运行的进程的所有访问权限这显然不符合一般的安全策略规范如果为了安全考虑那systemd的确不是一个在主机和容器场景下通用的组件守护方案。supervisord此外基于开源项目 ochinchina/supervisord也可以实现以上需求主要优势与缺点如下优势既支持如 systemd 的子进程守护又提供了 pidproxy 工具来支持对 pid 文件中的进程号进行状态守护兼容 postmaster.pid 格式使用 golang 实现可以通过交叉编译支持多 CPU 架构/操作系统、容器中使用无需特权模式、对安装环境无依赖、体积较小。通过对其中 supervisord 和 pidproxy 组件的修改可以支持一键停止 supervisord 和它托管的进程、兼容缺点supervisord 本身没有被守护被误杀后进程会脱离守护。用户机器重启后程序无法自动拉起这一点也非常致命尤其是对于经常有重启需求但又不想手动运维的用户。supervisor需要额外的安装而systemd是Linux本身提供的工具。总结对于云上数据库来说只要探活机制足够可靠守护进程主备切换是能最快恢复的办法也能覆盖更对异常场景。毕竟大部分故障不是通过重启就能解决的机器断电、宕机、网卡故障、磁盘写满太多的故障场景都需要备库来容灾。云厂商一般都能提供强大的管控能力切换后流复制、节点重建等等也都不需要使用者关注。但是对于线下小型数据库系统来说systemd等提供的守护能力也不失为日常运维的简单有效方案。很难找到完美的高可用方案适合自身需要的就是好方案。