数据库服务器可以一起工作， 这样如果主要的服务器失效则允许一个第二服务器快速接手它的任务（高可用性）， 或者可以允许多个计算机提供相同的数据（负载均衡）。理想情况下， 数据库服务器能够无缝地一起工作。 提供静态网页服务的网页服务器可以非常容易地通过把网页请求均衡到多个机器来组合。 事实上，只读的数据库服务器也可以相对容易地组合起来。不幸的是， 大部分数据库服务器收到的请求是读/写混合的，并且读/写服务器更难于组合。 这是因为尽管只读数据只需要在每台服务器上放置一次， 但对于任意服务器的一次写动作却必须被传播给所有的服务器， 这样才能保证未来对于那些服务器的读请求能返回一致的结果。

这种同步问题是服务器一起工作的最根本的困难。 因为没有单一解决方案能够消除该同步问题对所有用例的影响。有多种解决方案， 每一种方案都以一种不同的方式提出了这个问题， 并且对于一种特定的负载最小化了该问题所产生的影响。

某些方案通过只允许一台服务器修改数据来处理同步。 能修改数据的服务器被称为读/写、主控或主要服务器。 跟踪主控机中改变的服务器被称为后备或第二服务器。 如果一台后备服务器只有被提升为一台主控服务器后才能被连接， 它被称为一台温后备服务器， 而一台能够接受连接并且提供只读查询的后备服务器被称为一台 热后备服务器。

某些方案是同步的， 即一个数据修改事务只有到所有服务器都提交了该事务之后才被认为是提交成功。 这保证了一次故障转移不会丢失任何数据并且所有负载均衡的服务器将返回一致的结果 （不管哪台服务器被查询）。相反， 异步的方案允许在一次提交和它被传播到其他服务器之间有一些延迟， 这产生了切换到一个备份服务器时丢失某些事务的可能性， 并且负载均衡的服务器可能会返回略微陈旧的结果。当同步通信可能很慢时， 可以使用异步通信。

方案也可以按照它们的粒度进行分类。某些方案只能处理一整个数据库服务器， 而其他的允许在每个表或每个数据库的级别上进行控制。

在任何选择中，都必须考虑性能。通常在功能和性能之间都存在着权衡。例如， 在一个低速网络上的一种完全同步的方案可能使性能减少超过一半， 而一种异步的方案产生的性能影响可能是最小的。

本节的剩余部分列出了多种故障转移、复制和负载均衡方案。

本文转自PostgreSQL中文社区，原文链接：