流复制通过主库发送WAL日志、备库接收并应用实现数据同步。需配置主库wal_level、max_wal_senders、pg_hba.conf允许复制连接，使用pg_basebackup创建基础备份，备库启用hot_standby并启动服务；验证通过pg_stat_replication和pg_is_in_recovery()检查状态，注意网络、权限、WAL保留策略及磁盘空间。
在PostgreSQL的世界里，流复制（Streaming Replication）无疑是构建高可用和数据冗余基石的关键技术。简单来说，它就是让你的数据有一个或多个实时备份，以防不测，或者分担读请求的压力。配置和建立流复制数据源，核心就在于主库（Primary）和备库（Standby）之间，通过传输和应用预写日志（WAL）来达到数据同步的目的。
说实话，第一次接触流复制，光是看着那些配置参数就有点头大。但一旦理解了背后的逻辑，其实也就那么回事。核心在于让主库知道它需要发送WAL日志，让备库知道它需要接收并应用这些日志。整个过程可以粗略分成几步，每一步都有其考量。
解决方案
配置和建立PostgreSQL流复制数据源，通常涉及主库的准备、基础备份的创建以及备库的配置启动。
1. 主库（Primary）配置
首先，我们需要调整主库的一些参数，使其能够支持流复制。这主要在
postgresql.conf
和
pg_hba.conf
文件中进行。
修改
postgresql.conf
：
wal_level = replica
：这是最基础的，它告诉PostgreSQL生成足够的WAL信息以支持流复制。在旧版本中可能是
hot_standby
或
logical
，但
replica
是当前推荐的。
max_wal_senders = 10
：这个参数定义了主库最多可以同时支持多少个备库连接来传输WAL。根据你的需求和备库数量设置一个合理的值，比如5-10个通常足够。
wal_keep_size = 5GB
：这决定了主库在
pg_wal
目录下保留多少WAL文件，以供备库在需要时拉取。如果备库因为网络或其他原因短暂掉线，这些保留的WAL文件可以帮助它追赶进度。这个值需要根据你的WAL生成速度和备库的掉线容忍度来估算，太大浪费空间，太小容易导致备库无法追赶。
listen_addresses = '*'
: 确保主库监听所有网络接口，这样备库才能连接上来。或者指定具体的IP地址。
hot_standby = on
: 虽然这个参数主要在备库上起作用，但为了完整性，有时在主库上也会提及，不过它对主库本身的功能影响不大。
# postgresql.conf (Primary)wal_level = replicamax_wal_senders = 10wal_keep_size = 5GB # 或者根据实际情况调整listen_addresses = '*'
修改
pg_hba.conf
：
添加一行允许备库连接到主库进行复制的规则。这通常是针对
replication
数据库用户。例如，如果你的备库IP是
192.168.1.100
，且你打算使用一个名为
repl_user
的用户进行复制：
# pg_hba.conf (Primary)host replication repl_user 192.168.1.100/32 md5
请确保
repl_user
在主库中已创建，并且拥有
replication
权限。
重启主库：所有配置更改后，需要重启PostgreSQL服务以使之生效。
2. 创建基础备份（Base Backup）
在主库配置完成后，我们需要从主库创建一个完整的数据备份，作为备库的起点。这个过程通常使用
pg_basebackup
工具来完成。
在备库机器上执行：选择一个空目录作为备库的数据目录，然后运行
pg_basebackup
命令。
# 假设备库数据目录是 /var/lib/postgresql/14/main_standby# -h: 主库地址# -p: 主库端口# -U: 复制用户# -D: 备库数据目录# -Fp: plain格式，非tar# -Xs: streaming模式，复制WAL日志# -R: 自动生成 recovery.conf (或 standby.signal 和 postgresql.auto.conf)pg_basebackup -h -p 5432 -U repl_user -D /var/lib/postgresql/14/main_standby -Fp -Xs -R
执行此命令时，会提示输入
repl_user
的密码。成功后，备库数据目录下会包含主库的完整数据，以及一个
standby.signal
文件（PostgreSQL 12及更高版本）或
recovery.conf
文件（旧版本），用于指示备库启动时进入恢复模式。
3. 备库（Standby）配置与启动
修改
postgresql.conf
(备库)：
hot_standby = on
：如果希望备库在复制的同时，也能接受只读查询，这个参数必须打开。
primary_conninfo = 'host= port=5432 user=repl_user password='
：这个连接字符串告诉备库如何连接到主库。
restore_command = 'cp /path/to/archive/%f %p'
：如果你同时启用了WAL归档，并且希望备库在流复制中断时能从归档中恢复，就需要配置这个。但对于纯流复制，通常不是必需的。
# postgresql.conf (Standby)hot_standby = on# primary_conninfo 通常由 pg_basebackup -R 自动生成在 postgresql.auto.conf 中，# 但你也可以手动添加或修改。# primary_conninfo = 'host= port=5432 user=repl_user password='
请注意，
pg_basebackup -R
选项会自动在备库数据目录下的
postgresql.auto.conf
文件中生成
primary_conninfo
，通常无需手动设置。
1.1.8PbootCMS
PbootCMS是一款高效、简洁、强悍的开源PHP企业网站开发建设管理系统。PbootCMS 1.1.8 更新日志：2018-08-071.修复提交表单多选字段接收数据问题；2.修复登录过程中二次登陆在页面不刷新时验证失败问题；3.新增搜索结果fuzzy参数来控制是否模糊匹配；4.新增父分类，顶级分类名称及链接独立标签，具体见手册；5.新增内容多图拖动排序功能。
243 查看详情 
启动备库：启动备库的PostgreSQL服务。它会自动读取
standby.signal
或
recovery.conf
，并尝试连接主库进行WAL日志的同步和应用。
systemctl start postgresql-14 # 或你的PostgreSQL服务名
流复制的核心原理是什么？为什么我们需要它？
这事儿听起来简单，但背后的原理其实挺精妙的。WAL日志，你可以理解为数据库的所有变更记录，它保证了数据的一致性和持久性。PostgreSQL在任何数据写入磁盘之前，都会先将这些变更写入到WAL日志中。流复制，就是把这些日志实时地从主库“快递”到备库，备库再按顺序“播放”这些变更，将其应用到自己的数据文件中。这个过程是物理级别的复制，效率很高。
至于为什么我们需要它，除了显而易见的数据安全，还有几个关键点：
高可用性（High Availability）：这是最主要的驱动力。如果主库突然挂了，备库可以迅速地被提升为新的主库，大大减少了业务中断的时间。这就像给你的核心业务数据买了一份实时保险。读扩展（Read Scaling）：当你的应用读请求远超写请求时，可以将部分只读查询分流到备库上执行，从而减轻主库的压力，提高整体系统的吞吐量。不过，这需要应用程序层面的支持，能区分读写请求。灾难恢复（Disaster Recovery）：如果整个数据中心发生灾难，只要你的备库位于不同的地理位置，就能提供快速的恢复能力。数据分析/报告：有时，我们会在备库上运行一些耗时的数据分析或报告生成任务，避免这些任务影响主库的性能。
对我来说，流复制不仅仅是一个技术配置，它更是一种风险管理策略。尤其是在生产环境中，没有流复制的数据库，就像走钢丝没有安全网，心里总是不踏实。
配置流复制时，有哪些常见的“坑”和注意事项？
我个人觉得，流复制最容易出问题的地方往往不是配置本身，而是对细节的忽略和环境的差异。比如网络延迟，有时能把人折腾疯。还有WAL日志的管理，这绝对是个重灾区。
网络连接与防火墙：这是最基础也最容易被忽视的问题。主备库之间必须能够互相访问，特别是主库的5432端口。防火墙规则（如
ufw
或
firewalld
）一定要正确配置，允许复制用户从备库IP连接。我遇到过几次，就是因为防火墙没开通，排查了半天才发现。
wal_keep_size
的设置：这个参数非常关键。如果备库因为网络波动、机器重启等原因暂时掉线，它会尝试从主库拉取缺失的WAL文件。如果主库因为
wal_keep_size
设置太小，已经清除了备库需要的WAL文件，那么备库就无法追赶，只能重新做一次基础备份。这是一个很常见的“坑”。所以，
wal_keep_size
要结合你的WAL生成速度和备库的掉线容忍度来设置，或者配合WAL归档（
archive_mode
）使用，让备库可以从归档中获取历史WAL。
pg_hba.conf
权限问题：复制用户必须有正确的权限，并且在
pg_hba.conf
中有对应的
replication
规则。如果这里配置错了，备库根本连不上主库。用户权限与密码：复制用户（如
repl_user
）必须在主库上创建，并拥有
replication
权限。密码也要确保正确，并且在
primary_conninfo
中配置无误。磁盘空间：备库需要和主库一样甚至更多的磁盘空间来存储数据和WAL日志。如果备库磁盘满了，复制就会停止。PostgreSQL版本一致性：强烈建议主备库使用完全相同的PostgreSQL版本，包括小版本号。虽然有时大版本之间在一定条件下也能复制，但为了避免不必要的兼容性问题，最好保持一致。时区与系统时间：主备库的系统时间最好同步，并使用相同的时区设置，这有助于日志分析和事件关联。故障切换（Failover）：很多人只关注了如何搭建流复制，却忽略了当主库真正挂掉时，如何安全、有效地将备库提升为主库。这需要一套成熟的故障切换策略和工具（如
pg_auto_failover
,
Patroni
等），以及应用程序如何感知新的主库地址。单纯的手动提升备库为主库，操作不当可能会导致数据丢失或脑裂。
如何验证流复制是否正常工作，以及故障排查的初步思路？
配置完流复制，别以为就万事大吉了。最关键的是要确认它真的在工作，而且是健康地工作。我见过太多次，配置好了，但一检查发现备库早就掉队了，或者干脆就没连上。所以，定期的检查和一套初步的排查思路是必不可少的。
验证流复制状态：
在主库上检查
pg_stat_replication
视图：这是最直接的检查方式。连接到主库，执行：
SELECT client_addr, state, sync_state, sync_priority, replay_lag, write_lag, flush_lag FROM pg_stat_replication;
client_addr
：应该显示备库的IP地址。
state
：应该是
streaming
，表示正在实时传输WAL。
sync_state
：如果是同步复制，会显示
sync
；如果是异步复制，则显示
async
。
replay_lag
：这个非常重要，表示备库落后主库多少时间。理想情况下应该非常小，接近0。如果持续增大，说明备库跟不上了。
在备库上检查
pg_is_in_recovery()
：连接到备库，执行：
SELECT pg_is_in_recovery();
如果返回
t
(true)，说明备库正在恢复模式，即正在进行流复制。如果返回
f
，说明它已经脱离恢复模式，可能已经提升为主库，或者复制失败。
检查数据库日志文件：主备库的PostgreSQL日志文件（通常在数据目录的
log
文件夹下）会记录复制相关的事件和错误信息。查看这些日志是排查问题的第一步。例如，主库日志会记录备库的连接信息，备库日志会记录它尝试连接主库和应用WAL的情况。
写入测试数据并验证：如果备库设置为
hot_standby = on
，你可以在主库上插入一条数据，然后在备库上立即查询，看是否能查到。这是最直观的验证方法。
故障排查的初步思路：
当发现流复制不正常时，可以按照以下步骤进行排查：
网络连通性检查：首先确认主备库之间网络是否畅通。从备库
ping
主库IP，或者用
telnet 5432
检查端口是否开放。防火墙问题往往在这里暴露。
主库
pg_hba.conf
和用户权限：检查主库的
pg_hba.conf
是否允许备库IP的
replication
用户连接。同时确认
repl_user
是否存在且密码正确。
主库
postgresql.conf
参数：确认
wal_level = replica
和
max_wal_senders
是否配置正确，并且主库已重启生效。
备库日志文件：仔细查看备库的PostgreSQL日志。它通常会告诉你为什么连接不上主库，或者为什么无法应用WAL。常见的错误信息包括“could not connect to server”、“FATAL: password authentication failed”、“WAL segment xxx not found”等。
wal_keep_size
或 WAL归档问题：如果备库日志显示“WAL segment xxx not found”，这通常意味着备库落后太多，主库已经清理了它需要的WAL文件。这时候你可能需要：
增大主库的
wal_keep_size
。如果启用了WAL归档，检查归档是否正常工作，以及备库的
restore_command
是否正确。最坏的情况，可能需要重新做一次基础备份。
备库磁盘空间：检查备库的数据目录所在分区是否有足够的空间。磁盘满会导致WAL无法写入，复制中断。
primary_conninfo
检查：确认备库的
postgresql.auto.conf
或
postgresql.conf
中的
primary_conninfo
连接字符串是否正确，包括主库IP、端口、用户和密码。
排查问题就像侦探破案，需要耐心和细致。从最基础的网络和权限开始，逐步深入到配置参数和日志分析，通常都能找到症结所在。
以上就是PostgreSQL流复制数据源配置_PostgreSQL流复制数据源建立的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1059291.html
微信扫一扫 
支付宝扫一扫 
