PostgreSQL troubleshooting系列之七-备份与复制
前言
本文的内容来源于电子书《Troubleshooting PostgreSQL》。那本书虽老，但是里边的内容依然很有参考价值。俺这里尝试对其简译，对某些地方进行修正和补充，希望对学习和深入了解使用PG有帮助。
本文来自原书第8章。
这一章里头，主要有如下内容：
使用pg_dump进行文本方式转储（备份）
使用自定义格式备份
执行二进制格式备份
理解PITR方式恢复
搭建异步流复制
升级至同步流复制
本章对备份与流复制做了一个直观的介绍。相当于一个简单的指南。
8、解决备份与复制的问题
8.1、使用pg_dump
pg_dump命令是PostgreSQL中最重要的命令之一。它可以用来创建文本备份和二进制备份。每个系统管理员都会偶尔接触到这个命令。下面是它的工作原理。
8.1.1、创建文本备份
创建文本转储是大多数深入研究PostgreSQL的管理员的入门方式。这是一个必要的，但易于管理的任务。
pg_dump背后的思想很简单; 它连接到应该保存的数据库，并将内容转换为文本格式。下面是它的用法:
pg_dump test > /backup/dump.sql
最简单的备份形式是将pg_dump创建的SQL输出直接发送到纯文本文件。
需要指出的是，转储始终是一致的。在内部，转储是一个隔离级别可重复读（RR）的大型事务。转储表示数据的快照，这意味着如果启动转储并且需要一个小时才能完成，那么这一小时内的更改将不包括在转储中。这是因为它在启动时获取数据快照并从中获取备份。
在下一个示例中，转储被恢复到一个名为new_test的数据库中:
psql new_test < /backup/dump.sql
通常，转储是一种非阻塞操作。但是，ddl可能与某些读取发生冲突。一般来说，小心处理ddl和转储是个好主意，因为它们可能相互排斥。
8.1.1.1、留意blob值
Blob值并不自动包含在dump(转储)当中，在某些情况下，可能会出问题。因此，推荐使用-b （-- blobs)选项。如果启用了-b, pg_dump将在文本格式中包含那些blob值，确保你的dump能完整的完成。
8.1.1.2、处理密码
下边的例子里，我们假定一个连接被设为信任的。到现在为止没有使用任何密码。但这离现实其实很远。现实的设置中，总是有各种安全机制。
很多情况下，.pgpass文件, 会被使用。当然，它的位置也可以被环境变量PGPASSFILE指定。该文件采取下边的格式：
hostname:port:database:username:password
这样配置以后，就不再会有输入密码的提示。
为什么PostgreSQL不提供某种--put-password-here这样的参数?原因是传递给程序(如pg_dump或psql)的任何密码都将自动显示在进程表中。这必须不惜任何代价加以避免。
8.1.2、创建自定义格式的dump
很多情况下，文本格式的dump可能并不是你真正想要的那种方式。使用文本方式dump可能遇到的问题有：
文件容易变得很大
如果要抽取一个子集的数据变得相对困难。
自定义格式这个时候就可以用来救场。通常它就是一个压缩格式的dump, 并且包含 一个TOC (table of contents)。它的好处就是比较容易抽取表的子集，甚至抽取一个索引或者单个存储过程。除此以外，它还允许往多个CPU上重放这个过程。
下边的例子就是一个自定义格式的dump:
$ pg_dump test -Fc > /tmp/dump.fc
-Fc选项是创建自定义格式dump的唯一选项。一旦dump被创建，我们可以看看dump文件的基本内容：
$ pg_restore --list /tmp/dump.fc
*snip*
175; 1259 16447 TABLE public a hs
176; 1259 16450 TABLE public b hs
174; 1259 16445 SEQUENCE public seq_a hs
172; 1259 16436 TABLE public t_test hs
173; 1259 16442 TABLE public x hs
This file should contain lines of the following format:
hostname:port:database:username:password
Just create the desired entries. No password prompt will be shown anymore.
*snip*
--list 选项会返回dump文件中的所有对象。这样就可以有选择性的恢复数据，而不是恢复整个数据库。
下边是如何从dump文件中恢复单个表：
pg_restore -t t_test /tmp/dump.fc
如果要将数据加载到某个数据库，可以使用简单的管道或者 -d:
$ pg_restore -t t_test /tmp/dump.fc | psql xy
$ pg_restore -t t_test /tmp/dump.fc -d xy
8.1.2.1、利用多个CPU
到目前，用于回放dump文件只用到一个CPU。但是，对于特别大的数据库而言，很难在相对合理的时间以内去回放完整个dump。创建索引就是一个昂贵耗时的操作。
-j选项允许自定义格式dump同时使用多个CPU进行回放：
$ pg_restore -j 4 /tmp/dump.fc -d xy
这个示例将恢复dump中的数据到数据库xy里。在这个例子里，PostgreSQL会使用多达4个CPU核并发的回放这个dump文件。
当然，我们也要注意：一张表是无法使用多核特性的。只有多于一张表才可能利用这个功能。
8.2 管理PITR (point-in-time recovery)
pg_dump实用程序更像是创建备份的传统形式。对于少量数据来说，它是有意义的，但一旦数据量超过一定限制，它就会有局限性。不要误解我的意思;即使是tb级的数据，Pg_dump也能完美地工作。然而，让我们假设你有一堆一个10tb的庞然大物!从转储中重放10tb的数据库真的有意义吗?只要考虑一下必须构建的所有索引，以及做这些工作所花费的大量时间。使用不同的方法肯定是有意义的。这种方法称为时间点恢复(PITR)，或简称为xlog(现在叫做wal)归档。在本节中，您将详细了解PITR。
PITR是如何工作的呢？
PITR背后中的思想就是获取数据以及归档事务日志的一个快照。在crash的情况下，可能就要在全备的基础上恢复到某一个给定的时间点。
8.2.1 PITR的准备
为了配置PITR，需要有三项设置。配置文件：postgresql.conf。这三项是：wal_level, archive_mode以及archive_command。wal_level必须是archive ｜ replica或以上级别。使用minimal或者off是不行的。而archive_mode则告诉系统要将事务日志归档到一个安全的地方。archive_command则告诉系统将如何归档。
这里我们可以为归档创建一个单独的目录：
mkdir /archive
postgresql.conf里添加如下内容：
wal_level = archive -- 到了现在的新版本，已经改做replica
archive_mode = on
archive_command = 'cp %p /archive/%f '
现在数据库可以通过重启来启用这些配置项。
一旦这些配置生效，事务日志就会在归档目录 archive不断聚积。一旦一个16MB的wal段被填满，它将会通过archive_command传送到归档目录。看起来像下边这样：
$ ls -l
total 131072
-rw------- 1 hs wheel 16777216 Dec 8 12:24 000000010000000000000001
-rw------- 1 hs wheel 16777216 Dec 8 12:26 000000010000000000000002
-rw------- 1 hs wheel 16777216 Dec 8 12:26 000000010000000000000003
-rw------- 1 hs wheel 16777216 Dec 8 12:26 000000010000000000000004
8.2.2 执行基础备份
一旦wal文件归好档，我们就可以做简单的基础备份。有两种方式可以实现这个任务：
SELECT pg_start_backup pg_stop_backup: 传统方式
pg_basebackup: 流行方式
下面我们分别进行介绍。PITR的示例中，我们使用传统方式。先使用超级用户执行下边的语句：
test=# SELECT pg_start_backup('some label');
pg_start_backup
-----------------
0/7000028
(1 row)
这个语句如果要花点时间，也不用担心。这个语句执行时，系统会等待一个检查点发生，然后返回一个事务日志的位置。实际上，也没有什么魔幻的事情发生。它无非是告诉系统从哪里开始重放xlog(现在叫wal)。
一旦这个函数完成，就可以将整个数据库实例复制到一个安全的地方。记住，这个动作可以在生产环境运行时执行。在操作时无需关闭系统。
同时，也不用担心在备份过程中，文件会消失或再现。请记住，在xlog (wal) 中不会发生无法找到的更改。我们看看下边的示例：
mkdir /base
cd $PGDATA
cp -Rv * /base/
你可以使用简单的copy, rsync，ftp或其它方式来进行备份。只要确保整个目录被完整的备份即可。一旦这个做完，备份过程就可以停下来。
记住所有这些操作在系统运行的时候就可以做。不需要任何停机时间。备份完以后，在归档目录/archive下边会有文件：
$ cat 000000010000000000000007.00000028.backup
START WAL LOCATION: 0/7000028
(file 000000010000000000000007)
STOP WAL LOCATION: 0/70000B8
(file 000000010000000000000007)
CHECKPOINT LOCATION: 0/7000028
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2014-12-08 12:33:50 CET
LABEL: some label
STOP TIME: 2014-12-08 12:39:46 CET
.backup文件显示备份创建的时间。它还将告诉我们执行重播过程所需的最早的xlog文件。在此例中，为0000000100000000000000000007文件。比该文件更早的所有内容都可以安全地从服务器上删除。
8.2.3 重放blog (WAL)
系统在运行以后，越来越多的事务日志会累积到/archive目录当中：
-rw------- 1 hs wheel 294 Dec 8 12:39 000000010000000000000007.0
0000028.backup
-rw------- 1 hs wheel 16777216 Dec 8 12:45 000000010000000000000008
-rw------- 1 hs wheel 16777216 Dec 8 12:45 000000010000000000000009
-rw------- 1 hs wheel 16777216 Dec 8 12:45 00000001000000000000000A
我们现在假定服务器挂掉了，基础备份需要被用来做PITR。
要使它能工作，第一件事就是要添加一个recovery.conf （这个是在过去老版本postgresql11或更早中的操作）。在PG12及以后，使用的是信号文件：recovery.signal。
旧版本里，recovery.conf中添加内容：
restore_command = 'cp /archive/%f %p'
recovery_target_time = '2025-04-05 14:32'
新版本，将上述内容添加到主配置文件：postgresql.conf中即可。另外要添加一个信号文件：recovery.signal。实际上，一个命令就可以了。restore_command函数将把所需的文件从归档文件复制到PostgreSQL所需的位置(%p)。PostgreSQL将一个接一个地调用restore_command，直到它运行超出xlog或直到达到所需的recovery_target_time。实际上，recovery_target_time命令也可以算是多余的。如果不存在，PostgreSQL将尽可能恢复，而不是在期望的时间点停止。
一旦recovery.conf文件就位，管理员必须确保包含基本备份的目录被设置为700:
chmod 700 base
然后服务器就可以启动了(在这个例子中，日志被配置为显示在屏幕上):
$ pg_ctl -D /tmp/base/ start
server starting
$ LOG: database system was interrupted; last known up
at 2014-12-08 12:33:50 CET
LOG: starting point-in-time recovery to
2025-04-05 14:32:00+02
服务器提到它被中断了，并将告诉我们系统打算前滚到的时间点。然后从存档中一个接一个地复制文件并重播:
LOG: restored log file "000000010000000000000007" from archive
LOG: redo starts at 0/7000090
LOG: consistent recovery state reached at 0/70000B8
LOG: restored log file "000000010000000000000008" from archive
LOG: restored log file "000000010000000000000009" from archive
LOG: restored log file "00000001000000000000000A" from archive
LOG: restored log file "00000001000000000000000B" from archive
在某些时候，PostgreSQL会抛出一个错误，因为它不能复制下一个文件。这是有道理的，因为这一章是在2014年底写的，因此，2025年不容易达到现有的xlog。不过别担心!PostgreSQL将发现没有更多的xlog，并直接上线。如果在基本备份和最后一个xlog文件之间选择了一个日期，PostgreSQL将不会发出任何错误:
cp: /tmp/archive/00000001000000000000000C: No such file or directory
LOG: redo done at 0/BD3C218
LOG: last completed transaction was at log time 2014-12-08
12:46:11.755618+01
LOG: restored log file "00000001000000000000000B" from archive
cp: /tmp/archive/00000002.history: No such file or directory
LOG: selected new timeline ID: 2
cp: /tmp/archive/00000001.history: No such file or directory
LOG: archive recovery complete
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
恢复过程已经顺利完成，数据库实例已经准备好进行操作。注意，在流程结束时，recovery.conf被重命名为recovery.done。新版本里头，recovery.signal信号文件将会消失。
8.3 使用异步流复制
PITR技术虽然很好，但仍不完美。很多情况下，人们想要一个最新的备用服务器，它也可以作为只读的备用服务器。被称作流复制的功能就应运而生。
配置流复制比较简单，可以通过如下步骤来完成：
主节点上适配下postgresql.conf
个性pg_hba.conf，允许远程基础备份
运行pg_basebackup，得到一份初始的拷贝
启动从节点
要适配postgresql.conf，下边的选项值是需要的：
wal_level = hot_standby
max_wal_senders = 5
hot_standby = on
（啰嗦两句，笔记注，上边的值是针对11及以下的老版本。12和以后的版本推荐的应该是：wal_level中已经没有hot_standby了。使用replica就行。
wal_level = replica
max_wal_senders = 5
hot_standby = on
前两个设置在主服务器上是必需的。wal_level字段告诉服务器创建足够的xlog以允许流复制，max_wal_sender将指示主服务器允许保持打开的复制进程的数量。
注: 如果您计划运行一个从节点，请考虑将max_wal_sender设置为3或更高。在流式传输期间，只使用一个wal-sender进程，但在初始复制期间，最多需要两个连接。设置得太紧可能会导致不必要的数据库重启。
这里更改的第三个设置是hot_standby。基本上，这是一个从节点环境，主节点会忽略它。之所以设置它，是因为在下一步(基本备份)中，包括配置在内的整个实例将被发送到备用服务器。如果这个变量已经在主服务器上设置了，那么以后就不需要在从服务器上更改它(这比较方便)。
【笔者注】： hot_standby=on设在从节点上有什么用？Allows connections and queries during recovery. 指定在恢复期间，你是否能够连接并运行查询，如hot-standby中所述。默认值是on
。这个参数只能在服务器启动时设置。它只在归档恢复期间或后备机模式下才有效。
一旦postgresql.conf文件设置完毕，接着就可以配置防火墙文件：pg_hba.conf了。主要是告诉PG允许谁能做流复制，谁不能。IP限制必须加上，像：
host replication all 192.168.0.34/32 trust
在这里，备节点运行在192.168.0.34上，不需要输入密码就可以从主节点上获取事务日志。用到这里刚好。
如果只是在同一台机器上验证复制，那么下边的配置就够了：
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
一旦修改了postgresql.conf和pg_hba.conf，服务器就可以重新启动了。
8.3.1 使用pg_basebackup
在下一步中，可以获取数据库实例的初始副本。请记住，在上一节中，这个步骤是使用pg_start_backup和pg_stop_backup执行的。在本节中，将使用第二种方法pg_basebackup。
要为备节点准备复制，可以使用下边的步骤：
mkdir /slave
chown postgres.postgres slave
chmod 700 slave
这个示例假定服务器运行在postgres用户下边，并且目标目录是/slave。
在备节点上使用下边的命令创建初始备份：
pg_basebackup -D /slave \
-h master.server.com --checkpoint=fast \
--xlog-method=stream -R
确保上边的主机名换成您自己的服务器名或IP。该命令行的相关参数含义如下：
-D: 告诉pg_basebackup，初始备份要放到哪里
-h： 连接主节点的主机名或IP
--checkpoint=fase： 表明基础备份会发一个checkpoint到主节点上。这个好理解，如果不这样，小的备份也会比实际时间长。
--xlog-method=stream： 它会强制pg_basebackup打开第二个连接，并在备份的同时传输log。它的优势是新创建的基础备份总是充分完备的。它可以直接启动。它还确保可以启动新的备份，而不必退回到使用存档。
-R: 它指示将为流复制创建一个recovery.conf文件。它会包含下边两行内容：
standby_mode = 'on'
primary_conninfo = '...'
standby_mode=on这个设置表示服务器会保持流复制状态，即使已经没有xlog (WAL) (它应该只是等待更多的WAL)。
primary_conninfo这个设置用于指向连到主节点的连接信息。这两个设置就可以让流复制工作起来。
【笔者注：】稍等，上边说的都是pg11甚至pg10及以前的版本。如果是新版本，上边的参数：--xlog-method要换成--wal-method。并且命令执行完，在/slave目录下边，也不会有什么recovery.conf。而是自动生成standby.signal信号文件，表明它是一个备节点。同时会有一个文件：postgresql.auto.conf，里边有相关的连接参数等信息：
primary_conninfo = '...'
而standby_mode参数也不再使用了。
8.3.2 启动复制节点
一旦基础备份做好了，服务器就可以启动了。如果只是为了测试的目的，主节点和从节点可以在同一台主机上，您可以使用不同的端口来启动备节点，而不用修改配置文件。就像下边这样来启动：
$ pg_ctl -D /slave/ -o "--port=5433" start
从slave的服务器日志文件里头，可以看到：
server starting
LOG: database system was interrupted; last known up at
2014-12-08 15:07:39 CET
LOG: creating missing WAL directory
"pg_xlog/archive_status"
LOG: entering standby mode
对于服务器来说，整个过程看起来就像是崩溃。它告诉我们它感觉停止工作的时间(即在基本备份时)。
一旦PostgreSQL进入备用模式，它就走上了正路。PostgreSQL将开始重放内容，并最终达到一致状态:
LOG: redo starts at 0/D000028
LOG: consistent recovery state reached at 0/D0000F0
始终检查是否已达到一致状态。如果你没有一致的状态，这意味着前方有麻烦。
LOG: database system is ready to accept read only
connections
LOG: started streaming WAL from primary at 0/E000000
on timeline 1
此外，请确保您已进入流式传输模式。
瞧!服务器现在已经启动并运行。要检查复制是否安全工作，可以依赖一个名为pg_stat_replication的系统视图。每个slave包含一行:
postgres=# \d pg_stat_replication
View "pg_catalog.pg_stat_replication"
Column | Type | Collation | Nullable | Default
------------------+--------------------------+-----------+----------+---------
pid | integer | | |
usesysid | oid | | |
usename | name | | |
application_name | text | | |
client_addr | inet | | |
client_hostname | text | | |
client_port | integer | | |
backend_start | timestamp with time zone | | |
backend_xmin | xid | | |
state | text | | |
sent_lsn | pg_lsn | | |
write_lsn | pg_lsn | | |
flush_lsn | pg_lsn | | |
replay_lsn | pg_lsn | | |
write_lag | interval | | |
flush_lag | interval | | |
replay_lag | interval | | |
sync_priority | integer | | |
sync_state | text | | |
reply_time | timestamp with time zone | | |
这些领域非常重要，值得对它们进行更详细的解释。
第一个字段包含在主服务器上服务从服务器的进程ID。然后是usesysid字段和连接到系统的用户名。这是客户端连接的用户。然后是application_name字段。application_name字段的目的是为连接提供一个真实的名称。这对于调试(对于普通应用程序)以及同步复制(您将在下一节中看到)非常重要。
然后有几个字段显示连接来自哪里(client_*)。这些字段将告诉您整行是关于哪个奴隶的。backend_start字段告诉我们从服务器何时开始流。
backend_xmin字段之后是连接所处的状态。如果一切正常，应该设置为流式。然后有四个位置字段。它们将告诉管理员从属服务器已经分别消耗了多少重放的xlog。
最后是sync_state字段。它告诉我们服务器是处于同步复制模式还是异步复制模式。
我们如果在主节点执行查询，会看到下边的结果：
postgres=# select * from pg_stat_replication \gx
-[ RECORD 1 ]----+-----------------------------
pid | 12008
usesysid | 16384
usename | postgres
application_name | walreceiver
client_addr | 127.0.0.1
client_hostname | localhost
client_port | 52545
backend_start | 2023-12-14 07:43:39.54457+08
backend_xmin |
state | streaming
sent_lsn | 0/2E000148
write_lsn | 0/2E000148
flush_lsn | 0/2E000148
replay_lsn | 0/2E000148
write_lag |
flush_lag |
replay_lag |
sync_priority | 0
sync_state | async
reply_time | 2023-12-14 08:05:01.30449+08
能看到sync_state为async。
8.3.3 从节点提升为主节点
将从节点提升为主节点很容易。直接执行下边的命令即可：
pg_ctl -D /slave promote
从机将接收到信号，并把自己变成主机。最酷的是在这里，即使是现有的只读连接也会自动被打开进入读/写连接。甚至不需要重新连接;PostgreSQL将为您完成所有这些工作。现在新的主节点完全独立于老的主节点。这两个方框将不再保持同步。
请注意，主节点不能轻易地转换回从节点。应该执行完整的重新同步，以将损坏的旧主服务器转换为新的从服务器副本。
8.3.4 让复制更安全
到目前为止，已经展示了一个简单的复制设置。但是，如果用户使用基本备份，并且没有立即将从服务器连接到主服务器，会发生什么情况呢? 没有什么可以阻止主服务器回收其复制日志。如果从服务器姗姗来迟，则所需的事务日志不再存在。在连接缓慢的情况下也会发生同样的情况。用户可能以每秒200mb的速度将数据加载到主机，但网络每秒只能处理100mb的数据。从节点落后了，同样，没有什么能阻止主人回收它的xlog。为了解决这类问题，有一个简单的机制——wal_keep_segments (现在叫做 wal_keep_size）。
如果在postgresql.conf中将wal_keep_segments设置为100，这意味着主服务器将保留100 * 16 MB的事务日志，而不是在崩溃时修复自己所需的事务日志。这个小缓冲区为从服务器提供了一些喘息的空间，并且它定义了允许从服务器落后于主服务器而不失去主服务器视线的最大数据量。我个人的建议是始终将wal_keep_segments设置为一个合理的值，以确保在连接过慢、从端重新启动等情况下，从端始终能够跟上主节点。
在许多情况下可以观察到的另一个问题是冲突的出现。
在PostgreSQL中，slave可以用来服务只读事务。有时它会做一些与主节点意图相冲突的事情。作为一个例子，让我们假设从服务器正在运行一个很长的SELECT语句。与此同时，主服务器上的某个人执行DELETE语句并立即触发VACUUM命令来清理这些行。从服务器上的SELECT语句可能仍然需要这些数据。但是，xlog告诉系统清理这些行。因此，冲突发生了。如果有疑问的事务没有提前完成，从服务器将等待max_standby_streaming_delay = 30s，然后才直接终止从服务器上的连接。
为了防止大多数冲突，可以设置hot_standby_feedback = on。这将使从服务器将其最旧的事务ID (xmin)发送给主服务器。然后，主服务器将知道在从服务器上仍有一个正在运行的查询正在观察某些数据。因此，VACUUM将被延迟到冲突不再发生为止。
8.4 切换到同步流复制
虽然异步复制在90%的情况下就足够了，但许多人要求同步复制。同步复制背后的思想是，一个事务只有在被至少两个服务器接受时才有效。听起来容易吗?它是要配置PostgreSQL进行同步复制，只需要两个设置。
首先要配置的是从节点。所要做的就是将application_name字段添加到recovery.conf或新版本里postgresql.auto.conf中的primary_conninfo中。看看下边的示例：
primary_conninfo = 'host=master.server.com user=postgres
port=5432 application_name=some_name'
从服务器将在主服务器上注册为some_name。主服务器现在将检查它的synchronous_standby_names字段。在synchronous_standby_names中匹配的第一个条目将被认为是同步的; 其余的将被认为是异步的。
简言之，步骤如下：
在从节点的recovery.conf( 新版本里，postgresql.auto.conf)中, 为配置项 primary_conninfo 添加application_name
为主节点配置文件的 synchronous_standby_names 添加 配对的名字。
但是，同步复制有两个问题。第一个问题很明显;短事务的性能将下降，因为网络延迟可能是一个问题。
第二个问题与可用性有关。黄金法则是永远不应该只在两台服务器上进行同步复制。请记住，PostgreSQL确保一个事务只有在被至少两个服务器批准时才被认为是安全的。如果你有两个服务器，其中一个丢失了，PostgreSQL不能实现它的承诺。结果是PostgreSQL将不再接受写，直到提供第二个服务器，它可以接收数据并使系统满意!
强烈建议至少使用3台服务器，并相互冗余连接。
8.4 处理时间线
如果您只有两台服务器，那么时间安排就不是问题。然而，如果企业规模扩大，了解时间线对成功至关重要。这是怎么回事?当服务器从从服务器提升到主服务器时，它会增加其时间线。这样做是为了确保在大型设置中，每个服务器都使用正确的xlog。
在两台服务器的情况下，这不是问题。如果一切正常，两个服务器将在时间线1中启动。如果主服务器死亡，其余服务器将切换到时间线2，一切都会好起来。
但是由三台服务器组成的设置呢?万一主服务器崩溃，这些剩余服务器中的一个将成为下一个主服务器。但谁应该成为下一任大师呢?那要由你来决定。你不能随便找一个服务器。检查哪个服务器接收了多少事务日志，并决定使用最先进的服务器是很重要的。你可以这样计算:
select pg_last_xlog_replay_location ();
但不要立即提升最先进的从节点。这将使服务器跳转到下一个时间线。剩下的节点怎么办? 它们将在时间线1中闲置，复制将被破坏。
因此，在提升服务器之前，将所有从服务器重新连接到所需的新主服务器(通过更改primary_conninfo并向服务器发送信号)，然后提升新主服务器。它将确保新的主服务器跳转到时间线2，并将此更改复制到所有从服务器，以便这些从服务器可以轻松地与主服务器一起跳转到时间线2。
小结
在本章中，简要介绍了PITR和流复制。概述了与这些技术相关的所有基本概念，并对这些主题进行了实际介绍。
在下一章中，您将看到与硬件灾难和硬件故障相关的问题。
【笔者注】这一章内容比较基础。其实算不上什么troubleshooting， 就当作是备份与流复制的简单的复习内容吧。
参考：
《Troubleshooting PostgreSQL》第8章
