# Chapter 25\. 高可用性与负载均衡，复制 **Table of Contents** + 25.1\. 不同解决方案的比较 + 25.2\. 日志传送备份服务器 + 25.2.1\. 规划 + 25.2.2\. 备用服务器操作 + 25.2.3\. 为备用服务器准备主服务器 + 25.2.4\. 建立备用服务器 + 25.2.5\. 流复制 + 25.2.6\. Cascading Replication + 25.2.7\. 同步复制 + 25.3\. 失效切换 + 25.4\. 日志传送的替代方法 + 25.4.1\. 实施 + 25.4.2\. 基于记录的日志传送 + 25.5\. 热备 + 25.5.1\. 用户概述 + 25.5.2\. 处理查询冲突 + 25.5.3\. 管理员概述 + 25.5.4\. 热备参数参考 + 25.5.5\. Caveats 多个数据库服务器可以协同工作， 比如在主服务器失效的时候备份服务器立即取代它的位置(高可用性)， 或者几台机器同时服务于同一个数据库(负载均衡)。 理想状态多台服务器之间可以无缝协作。 为静态页面提供服务的Web服务器可以轻松的通过将web请求分摊到多台机 器从而实现负载均衡。 事实上，只读数据库也能轻松的以相同的方法实现负载均衡。 不幸的是，大多数数据库服务器都需要同时处理混合的读/写请求， 将这些数据库联合起来工作是件很麻烦的事。 虽然只读数据只需要在每台服务器上复制一份即可， 但是在任何一台服务器上的写动作都必须传播到其它所有服务器上， 这样才能保证将来对这些已修改数据的读取返回一致的结果。 这个写同步问题就是导致多台服务器协同工作麻烦重重的最基本原因。 有多种解决此问题的方法，其思路也各不相同， 但都不是既简单又高效的方案。 有一种解决方案是仅允许单独的一台"主"服务器修改数据， 可以修改数据的服务器称为只读/写，_master_或者_primary_服务器。 跟踪“主”服务器数据变化的叫_备_ 或者_从_服务器。 备用服务器不能连接到主服务器，直到它晋升为_热备_服务器。 可以接受连接而且只读服务器称为_热备_服务器。 一些方案是"同步的"， 意思是直到所有服务器都完成了某个修改数据的事务之后， 该事务才被认为是已经完成的。 这将确保失效切换不会丢失任何数据并且所有服务器都将返回一致的结果。 另一些方案是"异步的"，这种方案允许在事务提交之后 与传播到所有其它服务器之间有一小段延时， 但是在切换到备份服务器的时候某些事务可能会丢失， 并且不同的服务器可能返回不一致的结果。 当同步可能会很慢的时候可以使用异步通信。 还可以按照粒度对解决方案进行分类。 某些方案只能将整个数据库集群作为一个整体， 而某些方案可以针对每个数据库或每张表分别做不同的处理。 在选择任何失效切换或负载均衡方案的时候都必须考虑性能因素。 功能和性能不可兼得，比如，一个完全同步的解决方案在慢速网络上可能削减性能一半以上， 而完全异步的方案可能仅对性能有极其微小的影响。 下面的部分大致描述了各种常见的失效切换、复制、负载均衡方案。 [glossary](http://www.postgres-r.org/documentation/terms) 也是可用的。