如何在 PostgreSQL 中一步步创建复制用户

什么是 PostgreSQL 复制用户

复制用户是使用 REPLICATION 属性创建的专用数据库角色。这使得该角色能够以复制模式连接，并通过物理或逻辑复制协议流式传输预写日志（WAL），而不是像标准 LOGIN 角色那样对表运行 SQL 查询。

团队会创建单独的复制角色，而不是使用 postgres 超级用户，以遵循最小权限原则。这种区分对安全性很重要：

• postgres 超级用户可以读取、修改或删除数据库中的任何对象，因此其凭据高度敏感。
• 如果备用服务器被攻破，暴露的超级用户凭据将交出主数据库的完全控制权。
• 受限的复制用户只能流式传输 WAL 文件，从而限制凭据泄露的影响范围。

一个常见的困惑点是 CREATEROLE 权限。正如 PostgreSQL 18 文档所确认的，拥有 CREATEROLE 并不能让角色创建复制用户，也不允许为他人授予或撤销 REPLICATION 权限。只有真正的超级用户，或者本身已被授予 REPLICATION 的角色，才能配置新的复制账户。

在 PostgreSQL 中创建用户前的先决条件

在创建复制用户之前，需要正确设置 postgresql.conf 中的几个参数。跳过这些设置将导致备用服务器无法建立复制流。

在主数据库实例上检查以下内容：

• WAL 级别：将 wal_level 设置为 replica，或者如果你计划使用逻辑复制而不是流式物理复制，则设置为 logical。这控制写入预写日志的详细程度。
• 复制发送进程：将 max_wal_senders 设置得足够高，以覆盖你计划运行的每个并发复制连接。每个备用服务器或备份工具使用一个发送进程槽位。
• 复制槽：确保 max_replication_slots 为每个备用服务器预留专用槽位。槽位通过跟踪副本的当前日志位置，防止副本落后太多。
• 管理权限：创建用户需要超级用户连接，或者具有 CREATEROLE 加上显式复制授权的角色。

如何创建复制用户（3 个步骤）

设置复制角色涉及两个层面：PostgreSQL 内部的角色本身，以及允许它通过网络连接的身份验证规则。在主服务器上按照以下三个步骤操作。

步骤 1：在 PostgreSQL 中创建用户

以 postgres 超级用户身份连接到主实例，并运行创建命令。为其设置强密码，以及 REPLICATION 属性，以便它可以流式传输 WAL。

CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD 'your_secure_password';

CREATE USER 默认包含 LOGIN，因此无需单独添加。如果你改用 CREATE ROLE，请显式添加 LOGIN，因为 CREATE ROLE 不会默认包含它。

步骤 2：更新 pg_hba.conf 中的基于主机的身份验证

仅在 PostgreSQL 内部创建角色还不够。服务器还需要被告知接受该连接。打开 pg_hba.conf，并添加一行限定为备用服务器 IP 地址的规则。

host replication replicator 192.168.1.50/32 scram-sha-256

从 PostgreSQL 14 开始，scram-sha-256 是默认身份验证方法，应使用它代替较旧、较弱的 md5 方法。数据库字段设置为字面值 replication，告诉 PostgreSQL 此规则适用于复制连接，而不是常规数据库访问。

步骤 3：重新加载数据库配置

对 pg_hba.conf 的更改在重新加载后生效，因此不需要完全重启。在 psql 内部重新加载：

SELECT pg_reload_conf();

或者从系统终端：

pg_ctl reload -D /var/lib/postgresql/data

验证用户是否已正确创建

重新加载后，确认复制用户以正确的属性存在。

在 psql 中，运行 \du 列出所有角色。查找 replicator，并检查 Attributes 下是否出现 Replication。你也可以直接查询目录：

SELECT rolname, rolreplication, rollogin FROM pg_roles WHERE rolname = 'replicator';

要检查 pg_hba.conf 行是否被解析且没有错误，请查询 pg_hba_file_rules：

SELECT line_number, type, database, user_name, address, auth_method, error 
FROM pg_hba_file_rules 
WHERE user_name = 'replicator';

error 列中的 NULL 值表示 PostgreSQL 成功解析了新规则。

如果你使用的是 AWS RDS、Azure 或 Google Cloud SQL

托管 PostgreSQL 服务不提供 shell 访问权限，因此无法直接编辑 pg_hba.conf 和 postgresql.conf。每个平台通过其自己的系统角色授予复制权限，而不是原始超级用户访问权限。

Amazon RDS 和 Aurora：授予内置角色以启用复制：

GRANT rds_replication TO your_replication_user;

这无需超级用户访问权限即可工作，它也是 RDS 中的自动故障转移在主节点宕机时提升备用节点所依赖的基础。

Azure Database for PostgreSQL（灵活服务器）：授予 Azure 管理角色的成员资格：

GRANT azure_pg_admin TO your_replication_user;

如果你以主管理员账户连接，也可以直接分配 REPLICATION。

Google Cloud SQL：在 Cloud SQL 的提升管理角色下创建用户：

CREATE USER replicator WITH REPLICATION IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'your_secure_password';

通过 Google Cloud Console 或 gcloud 管理网络访问，或者使用 Cloud SQL Auth Proxy 完全跳过 IP 允许列表。

创建复制用户时的常见错误及修复方法

即使步骤正确，设置复制仍可能触发身份验证或授权错误。以下是你最可能遇到的情况及其解决方法。

错误：“permission denied to create role”

这意味着你不是以超级用户身份连接，或者你使用的角色具有 CREATEROLE，但未被显式授予复制权限。

以 postgres 超级用户或其他超级用户角色连接。如果你需要使用具有 CREATEROLE 的非超级用户，请记住仅此权限并不能授予创建或管理 REPLICATION 角色的能力。超级用户必须单独委派该权限。

错误：“FATAL: no pg_hba.conf entry for replication connection”

主服务器的身份验证文件阻止了备用服务器的连接，通常是因为规则缺失、有拼写错误、顺序错误，或者配置从未重新加载。

检查 pg_hba.conf，确认有一条规则匹配备用服务器的 IP 地址、用户名和字面数据库值 replication。修复该行后，在主服务器上运行 SELECT pg_reload_conf();，然后查询 pg_hba_file_rules 以确认没有解析错误。

错误：“password authentication failed”

这通常是哈希不匹配：密码使用较旧的 md5 格式存储，但 pg_hba.conf 要求 scram-sha-256，或者相反。

使用 SHOW password_encryption; 检查当前加密设置。如果未设置为 scram-sha-256，请更新它，然后重新运行 ALTER USER replicator WITH PASSWORD 'your_password'; 以在新设置下重新哈希密码。确保匹配的 pg_hba.conf 行也使用 scram-sha-256。

错误：“pg_basebackup: permission denied”

尽管措辞如此，这很少与数据库角色或复制权限有关。它通常是文件系统问题，即运行命令的操作系统用户对目标目录没有写权限，或者主服务器数据目录中的文件所有权错误。

确保备用服务器上的目标目录为空，然后设置正确的所有者：

chown -R postgres:postgres /var/lib/postgresql/data

根据实际部署调整路径。还要检查是否有残留的锁文件或外部工具持有主服务器数据目录的锁。

面向近零 RPO 高可用性的自动化复制

设置复制用户只是第一步。保持复制流健康、受监控，并在主数据库宕机时准备好故障转移，是另一个挑战，而手动 PostgreSQL 配置本身无法完全解决这一问题。

i2Availability 正是为弥补这一差距而构建的。它在生产数据库及其备用数据库之间提供字节级实时数据复制，因此主服务器上的更改会被持续捕获并发送到备份，而不是按计划进行。这使 RPO 接近零，因为备用服务器永远不会落后源服务器太远。

主要功能包括：

• 自动故障检测：心跳监控检查服务器硬件、网络状态和应用程序健康状况，因此故障的主服务器会被快速发现，而不是事后才发现。
• 亚秒级故障转移：确认故障后，备用服务器使用预设程序和虚拟 IP 漂移自动接管，无需手动干预。
• 零延迟复制：字节级复制捕获生产系统上的每个写操作，因此备份可以直接使用，无需漫长的恢复步骤。
• 仲裁机制：节点和磁盘仲裁防止两台服务器同时误认为自己应处于活动状态的脑裂场景。
• 跨平台支持：适用于物理、虚拟和云环境，包括将本地数据库与公有云备用服务器结合的混合部署。

同步复制与异步复制之间的选择会影响备用服务器在故障转移变得有风险之前可以容忍多少延迟，而 i2Availability 的实时复制旨在无论哪种模式适合环境，都尽可能缩小这一差距。

对于同时管理整机或基于文件复制的团队，i2Move 将类似的实时同步扩展到更广泛的迁移和灾难恢复场景。

FAQ

Q1：postgres 与复制用户相同吗？

不相同。postgres 超级用户绕过所有权限检查，包括复制，但它用于管理任务，而不是流式传输 WAL。仅具有 REPLICATION 属性的专用复制用户限制了泄露凭据可以访问的内容。

Q2：我需要重启 PostgreSQL，还是重新加载就够了？

对于 pg_hba.conf 的更改，重新加载就够了。运行 SELECT pg_reload_conf(); 或 pg_ctl reload，新的身份验证规则将在不中断现有连接的情况下生效。

Q3：CREATE ROLE 与 CREATE USER，有区别吗？

CREATE USER 等同于 CREATE ROLE，区别在于它默认包含 LOGIN。CREATE ROLE 不包含，因此如果角色需要能够连接，你需要显式添加 LOGIN。

Q4：我可以使用 md5 而不是 scram-sha-256 吗？

可以，但不推荐。自版本 14 起，PostgreSQL 默认使用 scram-sha-256，因为它更能抵抗密码嗅探。只有在较旧的客户端不支持 scram-sha-256 时才使用 md5。

结论

一旦角色、身份验证和网络层都正确配置，创建 PostgreSQL 复制用户就很直接了。从一开始就使 REPLICATION 属性、pg_hba.conf 条目和密码哈希方法保持一致，可以避免本指南中涵盖的大多数错误。

对于同时运行 PostgreSQL 和其他数据库及虚拟化系统的团队，大规模保持复制健康通常需要比手动配置更多的自动化。英方软件 构建的工具将这种实时保护扩展到更广泛的基础设施，从数据库复制到全系统高可用性。