2025年9月25日: PostgreSQL 18 发布!
支持的版本: 当前 (18) / 17 / 16 / 15 / 14 / 13
开发版本: devel
不支持的版本: 12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2

第 26 章 高可用性、负载均衡和复制

数据库服务器可以协同工作,以便在主服务器发生故障时(高可用性)能够快速接管,或者允许多台计算机服务相同的数据(负载均衡)。理想情况下,数据库服务器可以无缝地协同工作。提供静态网页的 Web 服务器可以很容易地组合起来,只需将 Web 请求负载均衡到多台计算机即可。事实上,只读数据库服务器也可以相对容易地组合起来。不幸的是,大多数数据库服务器的请求是读/写混合的,而读/写服务器要组合起来要困难得多。这是因为虽然只读数据只需要在每台服务器上放置一次,但对任何一台服务器的写入都必须传播到所有服务器,以便将来对这些服务器的读取请求返回一致的结果。

这种同步问题是服务器协同工作的根本困难。由于没有一个单一的解决方案可以消除所有用例的同步问题的影响,因此存在多种解决方案。每种解决方案都以不同的方式解决此问题,并最大程度地减少其对特定工作负载的影响。

一些解决方案通过只允许一台服务器修改数据来处理同步。可以修改数据的服务器称为读/写、主要服务器。跟踪主服务器更改的服务器称为备用辅助服务器。在提升为主服务器之前无法连接的备用服务器称为冷备用服务器,而可以接受连接并提供只读查询的服务器称为热备用服务器。

一些解决方案是同步的,这意味着修改数据的事务在所有服务器都提交事务之前不会被认为是已提交的。这保证了故障转移不会丢失任何数据,并且所有负载均衡的服务器无论查询哪个服务器都能返回一致的结果。相比之下,异步解决方案允许提交时间和向其他服务器传播之间存在一些延迟,这可能会导致在切换到备份服务器时丢失一些事务,并且负载均衡的服务器可能返回稍微过时的结果。当同步速度太慢时,就会使用异步通信。

解决方案还可以按粒度进行分类。一些解决方案只能处理整个数据库服务器,而其他解决方案则允许在每张表或每个数据库级别进行控制。

在任何选择中都必须考虑性能。功能和性能之间通常存在权衡。例如,在慢速网络上完全同步的解决方案可能会将性能降低一半以上,而异步解决方案可能对性能影响最小。

本节的其余部分将概述各种故障转移、复制和负载均衡解决方案。

提交更正

如果您在文档中发现任何不正确、与您对特定功能的使用体验不符或需要进一步澄清的内容,请使用此表单来报告文档问题。