25.2. 日志传送备份服务器

25.2.1. 规划

至少从数据库服务器的角度看， 创建主服务器和备份服务器并令两者尽可能完全相同是非常明智的。 特别是表空间的路径名必须保持完全一致， 这样主服务器和备份服务器就必须拥有同样的表空间挂载路径(如果使用了表空间的话)。 需要记住的是如果在主服务器上执行了CREATE TABLESPACE命令， 那么该命令需要的任何新挂载点必须在执行该命令之前同时在主服务器和备份服务器 上创建。 硬件不必完全相同，但是经验显示维护两个完全相同的系统比维护两 个不同的系统要少许多麻烦。 无论如何，应尽量保持体系结构相同— 比如一个是32-bit系统另一个是64-bit系统将不能正常工作。

通常，在主PostgreSQL版本不同的服务器之间传送日志是不可能的， 它是PostgreSQL全球开发组在次要版本升级中不能改变磁盘格式的一种策略。 在主服务器和备份服务器上运行不同的次要版本可能成功。 但是，没有正式支持，建议你尽可能的保持主服务器和备用服务器在同一个级别上。 在进行版本升级的时候，正确的做法是首先升级备份服务器— 因为新版本的服务器通常可以读取老版本的WAL文件，但反之则不然。

25.2.2. 备用服务器操作

在备用模式，该服务器连续应用从主服务器收取的WAL。 备服务器可以从一个WAL归档（参阅restore_command） 或直接通过一个TCP连接（流复制）从主服务器上读取WAL。 备服务器也可以在备用集群pg_xlog尝试查找恢复任何WAL。 这通常发生在服务器重启后，当备服务器重播，在备服务器重启前， 从主服务器流复制的WAL，但是你也可以手工复制文件到pg_xlog， 在任何时候可以重播它们。

在启动，备服务器恢复可用在所有的WAL开始存档位置,调用restore_command。 一旦它到达可用WAL的结束，restore_command失败， 将尝试恢复pg_xlog目录下任何可用的WAL。 如果那也失败了，并且已经配置了流复制，则尝试连接到主服务器， 从在归档或pg_xlog找到最后一条有效的记录开始WAL流。如果那也失败了， 或没有配置流复制，或连接断开，备服务器再次回到步骤1，循环尝试从归档里恢复文件。 从归档，pg_xlog，通过连续流复制直到服务器停止或有触发器文件触发的失效切换时。

当运行pg_ctl promote时，或者找到一个触发文件（trigger_file）时， 退出备用模式并且服务器切换到正常运行。 在失效切换前，将立即恢复归档或pg_xlog任何可用的WAL， 但不做尝试连接主服务器。

25.2.3. 为备用服务器准备主服务器

在主服务器上设置连续归档到一个备服务器可访问的存档目录， 正如第 24.3 节所描述的。即使主服务器关掉， 从备服务器应该可以访问这个归档位置。 即它应该驻留在备用服务器自身或其它可信赖的服务器上， 而不是主服务器。

如果你想使用流复制，在主服务器上设置认证，允许从备用服务器复制连接； 在pg_hba.conf提供一个或多个合适项使用数据库字段设置replication。 还要在主服务器的配置文件确保设置max_wal_senders足够大。 如果要使用复制槽，也要确保max_replication_slots设置的足够高。

启动备用服务器做一个基准备份，参见第 24.3.2 节。

25.2.4. 建立备用服务器

要建立备用服务器，从主服务器恢复基准备份（参阅第 24.3.4 节）。 在备用服务器的集群数据目录，创建一个恢复命令文件recovery.conf, 开启standby_mode。设置restore_command 为一条从WAL归档复制文件的简单命令。如果为了高可用性目的计划有多个备用服务器， 设置recovery_target_timeline为latest， 使得备用服务器按照发生故障转移到另一个备用服务器的时间变化。

如果你想使用流复制，在primary_conninfo填写一个libpq连接串， 其包括主机名（或IP地址）和连接到主服务器需要的其它详细信息。 如果主服务器需要个密码验证，也要在primary_conninfo指定所需要的密码。

如果你要建立高可用目的备服务器，设置WAL归档， 像主服务器的连接和身份验证，因为在失效切换后， 备服务器要作为主服务器运行。

如果你使用WAL归档，其大小可以使用archive_cleanup_command这个参数设置最小 ，用来删除那些备服务器不再需要的文件。 专门设计的pg_archivecleanup这个实用程序就是在通常的单备配置里， 使用archive_cleanup_command的。参阅pg_archivecleanup。 请注意，如果你使用备份目的归档， 你仍要保留需要恢复的至少最新的基准备份文件， 即使备服务器不再需要。

recovery.conf的一个简单例子：

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

你可能有任何数目的备服务器，但是如果你用流复制， 确保你在主服务器上设置的max_wal_senders足够大允许它们同时连接。

25.2.5. 流复制

与基于文件日志传送相比，流复制允许保持备服务器更新。 备服务器连接主服务器，其产生的流WAL记录到备服务器， 而不需要等待填写WAL文件。

流复制是异步的，参阅第 25.2.8 节， 在主服务器上提交事务和备用服务器上变化可见之间有一个小的延迟。 这个延迟远小于基于文件日志传送，通常1秒内足够与负载保持。 使用流复制，为减少数据丢失窗口archive_timeout不是必要的。

如果使用流复制而不是基于文件连续归档，主服务器可能在备服务器接收到它们之前回收老的WAL段。 如果发生了这种情况，备用服务器将需要从新的基础备份中重新初始化。 你可以通过设置wal_keep_segments为一个足够大的值， 确保WAL段不那么早的回收或者通过为备用服务器配置一个复制槽来避免这种情况。 如果你设置一个备服务器可访问的WAL归档，那么就不需要这些解决方法了， 因为保持供给备用服务器足够的WAL段，那么它总是可以使用这些归档来赶上主服务器的变化。

要使用流复制，建立一个基于文件的日志传送备服务器描述在第 25.2 节。 该步将一个基于文件的日志传送备服务器转为流复制备服务器， 在recovery.conf文件中设置primary_conninfo指向主服务器。 在主服务器上设置listen_addresses和身份验证选项 （参阅pg_hba.conf）， 因此备用服务器可以连接到在主服务器的replication伪数据库 （参阅第 25.2.5.1 节）。

系统上支持保持活动的套接字选项， 设置tcp_keepalives_idle, tcp_keepalives_interval和 tcp_keepalives_count 帮助主机及时发现断开的连接。

设置备用服务器的最大并发连接数。 （参阅max_wal_senders获取更多详细信息）。

当启动了备服务器并且正确设置了primary_conninfo, 该备服务器在回放所有可用的WAL文件后，将连接到主服务器。如果成功建立了该连接， 你将在备服务器中看到WAL接收进程，并且在主服务器相应的一个WAL发送进程。

# Allow the user "foo" from host 192.168.1.100 to connect to the primary
# as a replication standby if the user's password is correctly supplied.
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     foo             192.168.1.100/32        md5

# The standby connects to the primary that is running on host 192.168.1.50
# and port 5432 as the user "foo" whose password is "foopass".
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

25.2.6. 复制槽

复制槽提供一种自动的方式确保主服务器不删除WAL段，直到所有备用服务器都接收到了这些WAL段， 并且确保主服务器不删除会导致恢复冲突 的行，即使备用服务器是断开连接的。

为了替代使用复制槽，通过使用wal_keep_segments， 或使用archive_command存储WAL段在一个归档中都有可能阻止删除老的WAL段。 不过，这些方法经常导致保持比需要的更多的WAL段，而复制槽仅保持那些已知需要的WAL段数量。 这些方法的一个好处是，它们绑定pg_xlog所需的空间； 这是复制槽目前无法做到的。

相似的，hot_standby_feedback和 vacuum_defer_cleanup_age保护那些被vacuum删除的行的相关行， 但是前者在备用服务器没有连接之前的任意时间段都不提供保护， 后者经常需要设置为一个高值以提供足够的保护。复制槽克服了这些缺点。

postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
  slot_name  | xlog_position
-------------+---------------
 node_a_slot |

postgres=# SELECT * FROM pg_replication_slots;
  slot_name  | slot_type | datoid | database | active | xmin | restart_lsn
-------------+-----------+--------+----------+--------+------+-------------
 node_a_slot | physical  |        |          | f      |      |
(1 row)

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
primary_slot_name = 'node_a_slot'

25.2.7. 级联复制

级联复制功能允许备用服务器接受复制连接和到其他备库的流WAL记录，充当延迟。 这可以用来降低直接连接主库的数量，同时也尽量减少站点间的带宽开销。

同时充当接收器和发送器的待机称为级联 待机状态。更直接地连接到主库的备库作为上游服务器已知， 而备用服务器较远的下游服务器。级联复制不放在数量限制或 下游服务器的安排，虽然每个备库连接到一个上流服务器， 而最终链接到一个单一的主/主服务器。

级联备库不仅仅发送来自主库的WAL记录，而且来自归档的记录。 因此即使一些上流连接的复制连接终止， 连接复制继续往下只要有新的WAL记录可用。

级联复制当前是异步的，同步复制（参阅第 25.2.8 节）设置当前不影响级联复制。

热备用反馈传播到上游，无论级联配置。

如果上游备用服务器上升成为新主库，下游服务器将继续流向新主库， 如果recovery_target_timeline设置为'latest'。

使用级联复制，建立连锁备库从而接受复制连接（即设置 max_wal_senders和hot_standby， 以及配置host-based authentication）。 在下游备库指向级联备库中你还需要设定primary_conninfo。

25.2.8. 同步复制

PostgreSQL流复制缺省是异步的。如果主服务器崩溃，然后一些事务承诺不得不 复制到备用服务器，造成数据丢失。数据丢失量是与故障转移时的复制延迟是成比例的。

同步复制提供确认所有变化已经由事务转移到一个同步备用服务器的能力。 这延伸一个事务提交的耐久性标准。 这种级别的保护是指2-安全复制的计算机科学理论。

当请求同步复制，每次提交的写事务将等待直到确认收到提交已被写入到主库和备用服务器磁盘上的事务日志。 这些数据丢失的可能性是如果主库和备库同一时间遭受崩溃。 这可以提供一个更高层次的耐久性，但如果系统管理员对两个服务器的安置和管理非常谨慎。 等待确认增加用户的信心，在服务器崩溃的情况下更改将不会丢失，而是增加请求事务的响应时间。 最小等待时间是主库到备库的往返时间。

只读事务和事务回滚不需要等待从备用服务器的回复。 子事务提交不等待从备用服务器的响应，只有顶级提交。 长时间运行动作如加载数据或索引建立不等待直到最后提交信息。 所有的两阶段提交的行动需要提交等待，包括准备和提交。