主从复制集¶

PipelineDB配置复制集的方式跟普通的PostgreSQL一摸一样。如果您以前搭建过PostgreSQL的复制集，后面的所有操作都是及其相似的。如果没有这类经验的话，本章节是值得一读的，因为PostgreSQL复制集的搭建存在许多特性，这些特性大多是伴随着技术的演进形成的。这是由Peter Eisentraut撰写的 PostgreSQL发展历史，里面记录了技术的演进过程。

我们不会涉及如 Log-Shipping Standby Servers 之类的的老的复制技术，因为这些技术复杂且不稳定。唯一的阅读理由可能就是您正在使用老版本的PostgreSQL，但自PostgreSQL 9.5版本之后版本已经最新的强大特性。

流复制¶

PostgreSQL的流复制（同步和异步模式）对PipelineDB是开箱即用的，我们可以创建一个通过 tailing 预写日志（write-ahead log，WAL）与主节点保持同步并且提供只读服务的热备节点。主节点宕机时，热备节点可以升级为新的主节点。

假定我们已经装好了PipelineDB并运行在 localhost:5432。首先，我们需要在主节点上创建一个具有 REPLICATION 权限的 role。这个 role 可用于从节点流式读取主节点的WAL。

$ psql -h localhost -p 5432 -d postgres -c \
"CREATE ROLE replicator WITH LOGIN REPLICATION;"

CREATE ROLE

如果您的主节点在开放的网络环境下（这种情况是不应该存在的），您可以在创建 role 时设置 PASSWORD。

接下来需要将从节点的网络信息添加到主节点的 pg_hba.conf 文件。您可以在主节点的数据目录下找到该文件。pg_hba.conf 文件包含所有的客户端认证连接信息。比如，我们添加如下配置，可以根据实际情况进行调整：

host replication replicator 0.0.0.0/0 trust

然后，我们需要更新 postgresql.conf 文件或在执行 postgresql 时通过 -c 将其传递进去。将 wal_level 设置为 hot_standby，hot_standby 设置为 on，max_replication_slots 设置为1，max_wal_senders 设置为2。即使一个从节点只需要建立一条发送的连接，但在启动时需要建立两条（不是必须的，但在下面的文档中是必要的）。修改完这些参数后需要重启主节点。

最后，为从节点创建一个 replication slot。Replication slots用于从节点在主节点上注册工具，它使主节点能获悉需要保留的WAL片段。一旦从节点消费了一个WAL片段，它就会更新 pg_replication_slots 目录中的 restart_lsn 列，以便主节点知悉当前可回收的WAL片段。

$ psql -h localhost -p 5432 -d postgres -c \
"SELECT * FROM pg_create_physical_replication_slot('replicator_slot');"

    slot_name    | xlog_position
-----------------+---------------
 replicator_slot |
(1 row)

以上是我们需要在主节点上执行的所有操作，下面开始配置从节点。第一步，选取主节点的基础备份，您可以将主节点的数据目录 rsync 到从节点中 ———— 从节点需要基于这些数据来启动。为此，我们使用 pipeline-basebackup 工具（类似于 pg_basebackup）。您也可以使用 rsync ————这通常更快一点，但会使自身的鉴权设置变得复杂。pipeline-basebackup 使用普通的PostgreSQL连接来传输基础文件，所以您不用担心认证细节。

$ pg_basebackup -X stream -D /path/to/standby_datadir -h localhost -p 5432 -U replicator

-X stream 选项就是配置第二个slot的原因。本质上来说，这个操作就是在基础备份发生变化时，将WAL的变化也实时传输到从节点，所以我们不必手动配置 wal_keep_segments 参数。

最后一步，在从节点的数据目录中添加一个 recovery.conf 文件来通知PipelineDB实例切换到standby模式以及如何连接主节点：

standby_mode = 'on'
primary_slot_name = 'replicator_slot'
primary_conninfo = 'user=replicator host=localhost port=5432'
recovery_target_timeline = 'latest'

设置完毕，在 6544 端口上启动热备节点。

pg_ctl start -D /path/to/standby_datadir -o "-p 6544"

启动后，您应该会看到如下所示的日式：

LOG:  entering standby mode
LOG:  redo starts at 0/5000028
LOG:  consistent recovery state reached at 0/50000F0
LOG:  database system is ready to accept read only connections
LOG:  started streaming WAL from primary at 0/6000000 on timeline 1

确认从节点以recovery模式运行：

$ psql -h localhost -p 6544 -d postgres -c \
"SELECT pg_is_in_recovery();"

 pg_is_in_recovery
-------------------
 t
(1 row)

高可用¶

PostgreSQL没有开箱即用的高可用方案。大多数部署都是依赖于在主节点宕机时手动切换到热备节点。Failover 可以被 pg_ctl promote 触发，也可以通过在 recovery.conf 文件中配置 trigger_file 来实现。Compose.io 中有一篇讲述如何设计高可用的博客，您可以复用他们的 Governor 系统，确保将代码中引用的PostgreSQL二进制文件切换到PipelineDB。

如果以上内容对您来说不够丰富，请联系我们，我们将提供一些指导！