从共享存储到流复制的HA架构演进：解决备库长期闲置浪费资源的问题

业界大多数数据库的高可用实现，长期以来都基于共享存储方式——数据库一主一备，两者共用同一份底层存储；正常情况下只有主库连接存储和虚拟IP（VIP）来处理业务，备库始终处于非运行状态，只有主库真的出现故障时，备库才会接管存储和VIP。这套架构在传统企业里非常普遍，但存在一个明显的结构性浪费：备库的计算资源长期处于完全闲置的状态，只是作为”万一主库挂了能顶上”的保险，平时对业务毫无贡献。随着PostgreSQL等数据库支持了Streaming Replication（流式复制）这类数据复制技术，架构开始朝一个更充分利用资源的方向演进：备库不再是被动等待接管的闲置资源，而是可以作为只读服务器主动承接一部分业务的只读查询流量——主库负责所有的写操作和读写业务，备库通过持续的流复制同步数据，同时对外提供只读查询服务，两台服务器都在真实地为业务提供价值，而不是一台全力工作、一台完全闲置。这个演进案例给出了一条评估”冗余设计”合理性的重要视角：为了追求高可用而引入的冗余资源（备份节点、副本），不应该被默认地当作”纯保险、平时不产生价值”来对待——如果这份冗余资源具备承接一部分实际业务流量的能力（比如只读查询这类对数据实时性要求不那么严苛的场景），就应该主动把它利用起来，让”高可用”和”资源利用率”这两个目标同时被满足，而不是把”为了容灾”和”为了提升利用率”当成两个互相排斥、只能二选一的设计目标。