流复制需主库wal_level=replica、max_wal_senders≥从库数，pg_hba.conf须添加正确replication条目，pg_basebackup -r初始化从库，并确保主从locale与时区一致，否则复制失败。
流复制不是“配完就能用”的功能，主库参数错一个、认证规则漏一行、从库初始化少个标志，复制就卡在连接阶段或启动后立刻断开。
主库 wal_level 和 max_wal_senders 必须设对
这两个参数是流复制的硬性门槛，设错直接导致 walsender 进程不启动，从库连都连不上。
-
wal_level必须为replica（PostgreSQL 10+），minimal或logical都不行；logical虽然也支持流，但会额外生成逻辑解码信息，没必要且增加开销 -
max_wal_senders要 ≥ 实际从库数量，比如你计划部署 3 个从库，这里至少填3；设成1后新加第二个从库会直接被拒绝，错误日志里出现no more replication connections allowed - 改完必须重载或重启：用
pg_ctl reload -D /path/to/data或systemctl restart postgresql-16，只改文件不生效
pg_hba.conf 的 replication 条目不能写错位置或掩码
即使主库参数全对，pg_hba.conf 里一行写错，从库连接就会被拒，报错通常是 FATAL: no pg_hba.conf entry for replication connection。
- 必须新增一条
host replication <user><ip>/32 md5</ip></user>，注意类型是replication，不是all或数据库名 -
/32是关键：写成/24可能放行不该连的机器；写成0.0.0.0/0是严重安全风险 - 这条规则必须放在所有
host all all通配规则之前，否则会被提前匹配并拒绝（因为replication权限比普通连接更严格） - 改完用
pg_ctl reload生效，不要只改文件就以为 OK
pg_basebackup -R 初始化从库时常见断点
从库启动失败，90% 出在 pg_basebackup 执行环节。它不只是拷数据，还要自动生成控制文件和连接配置。
- 执行前必须清空从库
data目录，且属主为postgres用户，否则启动时报data directory has wrong ownership - 务必加
-R参数：它会自动创建standby.signal文件，并在postgresql.auto.conf中写入primary_conninfo；漏掉这个，从库会以“普通主库”模式启动，直接拒绝接收 WAL -
-X stream要带上：避免先存档再传输，减少中间磁盘 IO 和时间；不加可能触发归档模式校验失败 - 如果主库开了复制槽（
-C -S slot_name），从库断连后主库不会清理对应 WAL，但槽名slot_name必须全局唯一，重复会导致pg_basebackup报错replication slot already exists
从库启动后怎么确认真正在 streaming
看到 ps aux | grep startup 或 pg_is_in_recovery() 返回 t 不代表复制在跑，得看 WAL 是否实时接收并应用。
- 在从库执行
SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();：三个值都非空，且后两者接近（差几个字节正常），说明接收和重放都在进行 - 在主库查
SELECT * FROM pg_stat_replication;：状态列state必须是streaming，不是startup或空；sent_lsn和write_lsn差距大，说明网络或磁盘有瓶颈 - 别依赖
pg_stat_activity：里面看不到 walsender/walreceiver 进程，它们不属于用户会话
最容易被忽略的是 locale 和时区一致性——主从服务器的 LC_COLLATE、LC_CTYPE 和 timezone 必须完全相同，否则从库启动时可能报 database files are incompatible with operating system，这不是数据损坏，而是初始化时没对齐环境变量。
