使用PostgreSQL foreign data wrapper能否将SELECT请求重定向到其他服务器

可行性结论 #

可以通过postgres_fdw实现读请求重定向到只读从库。核心实现逻辑是在主库上创建指向只读从库的外部服务器、用户映射，再为需要分流读请求的表创建外部表映射，业务侧查询主库上的外部表时，请求会自动转发到从库执行，写操作依然直接访问主库本地表即可。

方案合理性评估 #

这个方案有明确的适用场景，优缺点都非常突出：

• 优势
  • 改造成本极低：不需要调整业务侧的数据库连接配置，仅需在数据库侧完成外部表映射，对业务几乎无侵入
  • 灵活性强：可以按需选择部分表的读请求走从库分流，核心低延迟敏感的表依然直接访问主库
  • 无额外组件依赖：完全依托PG原生FDW能力实现，不需要额外部署读写分离中间件，运维成本低
• 劣势
  • 存在固定额外开销：跨节点的网络传输、数据序列化/反序列化会带来10%~30%的性能损耗，对于延迟敏感的高频小查询影响尤为明显
  • 执行计划限制：如果查询涉及主库本地表和外部表的JOIN、聚合操作，优化器无法生成最优执行计划，大概率会出现明显的性能劣化
  • 运维负担增加：主库表结构变更后需要同步更新外部表的映射定义，否则会出现字段不匹配的查询报错；同时FDW本身无法处理主从同步延迟问题，需要业务接受读请求的毫秒级到秒级数据不一致

落地指导建议 #

• 优先适配大查询场景：如果你的读请求以分析类、批量查询为主，本身查询耗时较高，FDW的额外开销占比极低，这个方案的性价比非常高
• 高频短查询场景不推荐：如果业务以毫秒级的高频点查为主，更建议采用应用层读写分离、或者Pgpool-II这类连接中间件做透明读写分流，性能损耗远低于FDW方案
• 提前做性能验证：用业务实际的读请求分别测试直连从库、查询主库FDW外部表的延迟差异，确认性能损耗在可接受范围内再全量上线
• 做性能优化：创建外部服务器时开启use_remote_estimate参数让FDW拉取从库的统计信息生成更优的执行计划，同时将fetch_size调整到1000以上，减少跨节点网络往返次数
• 规避一致性风险：不要在同一个事务内混合写入主库本地表、读取FDW外部表的操作，避免因主从同步延迟读到旧数据，引发业务逻辑异常

内容的提问来源于stack exchange，提问作者hassan_i