用 Bitnami 的 Postgresql-Repmgr 镜像来搞个高可用的 PostgreSQL 环境，快又省事

Bitnami 的 bitnami/postgresql-repmgr 镜像确实是一个能快速搭建 PostgreSQL 高可用集群的解决方案，它把 PostgreSQL 数据库和 repmgr（复制管理器）这个工具打包在一起，省去了我们手动安装和配置的麻烦，它的核心思想是“一主多从”，就是一个主节点负责读写，多个备用节点同步主节点的数据，如果主节点出问题了，repgmgr 会自动从备用节点里选一个新的主节点出来,保证服务不中断。

要跑起来这个环境，Docker 和 Docker Compose 是必不可少的，下面我详细说一下用 Docker Compose 来部署一个包含一个主节点和两个备用节点的集群步骤,这样最直观。

第一步是准备配置文件，我们需要一个 docker-compose.yml 文件来定义三个服务：主节点（postgresql-primary）、备用节点1（postgresql-standby1）和备用节点2（postgresql-standby2），这个文件里会写明用哪个镜像（bitnami/postgresql-repmgr:16），设置必要的环境变量，挂载数据卷,还有配置网络。

根据 Bitnami 的说明，有几个环境变量是必须设置的。POSTGRESQL_POSTGRES_PASSWORD 是超级用户 postgres 的密码，这个很重要。POSTGRESQL_USERNAME 和 POSTGRESQL_PASSWORD 是你创建的普通数据库用户和密码。POSTGRESQL_DATABASE 是初始创建的数据库名。POSTGRESQL_PGAUDIT_LOG 这个可以设置一下，用来开启审计日志，还有一个关键的叫 POSTGRESQL_SYNCHRONOUS_COMMIT_MODE，这个决定了数据同步的强度，为了平衡性能和数据一致性，通常可以设为 on 或者 remote_apply。

对于 repmgr 部分，每个节点都需要一个唯一的名字，用 REPMGR_NODE_NAME 设置，比如主节点叫 primary，备用节点叫 standby1、standby2，还需要用 REPMGR_NODE_NETWORK_NAME 设置节点在网络中的主机名，这个要和 Docker Compose 里服务的名字对应起来，因为节点之间要靠这个主机名互相通信。REPMGR_PRIMARY_HOST 这个变量只有在初始化备用节点时才需要，指向主节点的主机名（也就是 postgresql-primary），告诉备用节点“你去哪里同步数据”，主节点本身不需要这个设置。REPMGR_PASSWORD 是 repmgr 元数据数据库的用户密码，所有节点必须一致,这样它们才能互相交流集群状态信息。

网络配置也很关键，Bitnami 建议为这三个容器创建一个自定义的 Docker 网络，在 docker-compose.yml 里定义一个自定义网络，比如叫 postgresql-ha-network，然后让三个服务都连接到这个网络，这样它们之间就可以用服务名作为主机名互相访问了,非常方便。

数据持久化是生产环境必须的，要为每个节点挂载一个数据卷到容器内的 /bitnami/postgresql 路径，这样即使容器重启,数据库数据也不会丢失。

配置文件准备好之后，第二步就是启动集群，首先启动主节点，在终端里，进入 docker-compose.yml 所在的目录，运行命令 docker compose up -d postgresql-primary，这会先拉取镜像（如果本地没有的话），然后启动主节点容器，用 docker compose logs postgresql-primary 查看日志，等到看到 repmgr 说主节点注册成功的信息,就说明主节点启动好了。

第三步是启动备用节点，主节点正常运行后，就可以启动备用了，运行命令 docker compose up -d postgresql-standby1 postgresql-standby2，这时候，这两个备用节点会根据配置里的 REPMGR_PRIMARY_HOST 找到主节点，然后开始同步数据，同样，查看备用节点的日志，能看到它们连接到主节点并开始流复制的过程,最后注册自己为备用节点。

一个三节点的 PostgreSQL 高可用集群就跑起来了，你可以用 docker compose ps 看看三个容器的状态，怎么验证高可用呢？可以连接到主节点创建一个表插入点数据，然后去备用节点查询，应该能看到数据已经同步过来了，最关键的测试是故障转移：手动停掉主节点容器，docker compose stop postgresql-primary，然后观察 repmgr 的日志，几秒钟内，它会发现主节点挂了，然后在两个备用节点中选举出一个新的主节点（standby1），这时候，你的应用程序如果配置了正确的连接字符串（后面会说到），就能自动连接到新的主节点,业务影响降到最低。

最后说一下应用程序怎么连接，直接连一个特定节点是不对的，因为主节点可能会变，Bitnami 推荐的方法是使用连接池中间件，PgBouncer 或者 pgPool，它们可以自动感知哪个节点是当前的主节点，把写请求发到主节点，读请求可以分发到备用节点，实现负载均衡，Bitnami 也提供了 bitnami/pgpool 镜像，可以很方便地和这个 postgresql-repmgr 集群配合使用，在你的应用连接字符串里，就配置 PgBouncer 或 pgPool 的地址和端口就行了。

用 Bitnami 的 postgresql-repmgr 镜像，配合 Docker Compose，确实能又快又省事地搭建一个 PostgreSQL 高可用集群，它封装了复杂的配置，我们主要就是写个 docker-compose.yml 文件，设置一下环境变量，剩下的启动、数据同步、故障转移，都是自动完成的，对于想快速拥有数据库高可用能力，又不想深陷配置细节的情况，这是个非常实用的选择，以上内容主要参考自 Bitnami 官方文档中关于 PostgreSQL 高可用集群的部署指南。