​### 译者简介

李伟&崔鹏&海能达DBA团队,任职于海能达通信股份有限公司哈尔滨平台中心,数据库开发高级工程师,致力于PostgreSQL数据库在专网通信领域、公共安全领域PostgreSQL数据库的管理与维护,致力于高并发高可用数据库架构设计和数据库性能的优化。

校对者简介

赵全明 任职于华为技术有限公司，数据库内核开发工程师，参与RDS for PostgreSQL管控及GaussDB多个版本的研发，致力于PostgreSQL在全行业的应用与推广。

主从复制在保持高可用性方面起着至关重要的作用。服务器故障、操作系统或数据库软件可能需要升级。这就意味着需要重新排列服务器角色、修改复制的指向，同时维护所有数据库之间的数据一致性。

此时必须要更改服务器的拓扑结构，我们可以通过如下不同的方法来实现。

提升备用服务器

将备服务器提升为主服务器，这是可能是你最常见的操作。原因有很多，比如主服务器上的数据库维护会影响工作负载；由于某些硬件操作可能会计划停机；主服务器崩溃，使应用程序无法访问。无论是否在计划内，此时都要做好故障转移。以上所有这些情况，都必须将其中一个备用服务器提升为新的主服务器。

提升备服务器，可以执行如下命令：

postgres@vagrant-ubuntu-trusty-64:~$ /usr/lib/postgresql/10/bin/pg_ctl promote -D /var/lib/postgresql/10/main/
waiting for server to promote.... done
server promoted

在运行命令之前，首先要确保避免任何数据丢失。如果我们讨论的是“主服务器宕机”场景，可能没有太多的选项。如果是有计划的维护，那么就有可能做好准备。你需要停止主服务器上的通信，然后验证备用服务器接收并应用了所有的wal。

可以在备用服务器上完成，使用如下查询:

postgres=# select pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();
 pg_last_wal_receive_lsn | pg_last_wal_replay_lsn
-------------------------+------------------------
 1/AA2D2B08              | 1/AA2D2B08
(1 row)

将备用服务器挂到新的主服务器上

你可能有多个备用服务器在与主服务器同步。毕竟备用服务器对于分担只读流量非常有用。在将备用服务器提升到新的主服务器之后，你需要对仍然连接(或正在尝试连接)到旧主服务器的其余备用服务器做一些处理。不幸的是，你不能只更改recovery.conf并将它们连接到新的主服务器(因为新主服务器与其他备服务器之间，没有设置主备关系)。要连接它们，首先需要重新构建它们。这里有两种方法可以尝试:标准基础备份或pg_rewind。

我们暂不讨论如何做基础备份的细节--在之前的博客（https://severalnines.com/database-blog/logical-physical-postgresql-backups）中已经重点讨论了如何备份和恢复。如果你碰巧使用了ClusterControl，你也可以使用它创建基础备份。

这里我们多讨论一些pg_rewind。这两种方法的主要区别在于，基本备份创建了数据集的完整副本。如果我们讨论的是小数据量的情况下，这是可以的，但是对于数百GB(甚至更大)的数据量时，这很快就会成为一个问题。当你希望备用服务器快速启动并运行—以便分担你刚刚晋升的主服务器的负载，并在需要时拥有另一个备用服务器进行故障转移。pg_rewind的工作方式有所不同——它只复制那些修改过的块。它只复制更改的部分，而不是复制所有内容，这大大缩短了处理时间。假设新主服务器的IP是10.0.0.103。这就是执行pg_rewind的方法。

TIPS:请注意，您必须停止目标服务器的PostgreSQL数据库。

postgres@vagrant-ubuntu-trusty-64:~$ /usr/lib/postgresql/10/bin/pg_rewind --source-server="user=myuser dbname=postgres host=10.0.0.103" --target-pgdata=/var/lib/postgresql/10/main --dry-run
servers diverged at WAL location 1/AA4F1160 on timeline 3
rewinding from last common checkpoint at 1/AA4F10F0 on timeline 3
Done!

这将空运行，用来测试流程，实际上不做任何更改。如果一切正常，你所要做的就是再次运行它，这次不要使用“——dry-run”参数。完成之后，剩下的最后一步将是创建一个recovery.conf文件，在文件将指向新的主服务器。

它可能是这样的:

standby_mode = 'on'
primary_conninfo = 'application_name=pgsql_node_0 host=10.0.0.103 port=5432 user=replication_user password=replication_password'
recovery_target_timeline = 'latest'
trigger_file = '/tmp/failover.trigger'

现在可以启动备用服务器了，它将和新的主服务器建立复制关系。

链式复制

构建链式复制的原因有很多，但是构建链式复制通常是为了减少主服务器上的负载。将WAL提供给备用服务器会增加一些开销。如果你只有一两个备用服务器，这不是什么大问题，但是如果我们讨论的是大量的备用服务器，这可能会成为一个问题。例如，我们可以通过创建如下拓扑结构来最小化直接复制的备用服务器的数量:

从两个备用服务器的拓扑转移到链式复制非常简单。

您需要将10.0.0.103上的recovery.conf修改为指向10.0.0.102，然后重新启动PostgreSQL。

standby_mode = 'on'primary_conninfo = 'application_name=pgsql_node_0 host=10.0.0.102 port=5432 user=replication_user password=replication_password'recovery_target_timeline = 'latest'trigger_file = '/tmp/failover.trigger'

重启后，10.0.0.103应该开始应用WAL更新。

这些是拓扑更改的一些常见情况。有一个主题没有讨论，但是却很重要，这个主题就是这些更改对应用程序的影响。我们将在单独的博文中讨论这个问题以及如何保证拓扑更改对应用程序透明。

原文链接：https://severalnines.com/database-blog/performing-replication-topology-changes-postgresql