PostgreSQL 复制

从 9.0 版本开始，PostgreSQL 随核心产品一起提供流复制，从而扭转了长期以来将复制留给第三方插件（如 Slony 或 pgpool）的策略。

该蓝图建议支持流复制，因为它随核心产品一起提供，尽管关于其他 PostgreSQL 选项的讨论可以在替代方案部分找到。

https://blueprints.launchpad.net/trove/+spec/postgresql-replication

问题描述

为了实现与 MySQL 的功能对等性，Trove 应该提供对 PostgreSQL 至少一种复制解决方案的支持。

提议的变更

配置

用于启用复制策略的标准参数，replication_strategy 和 replication_namespace，将被添加到指向 PostgreSQL 客体策略代码的位置。

数据库

无。

公共 API

与其他支持复制的数据存储一样，创建实例操作将支持 replica_of 和 replica_count 字段，用于 PostgreSQL 客体

POST http://127.0.0.1:8779/v1.0/<tenant id>/instances
{
    "instance": {
        "volume": {"size": <size>},
        "flavorRef": "<flavor-id>",
        "name": "s",
        "replica_of": "<master id>",
        *"replica_count": "<n>"*
    }
}

对于支持 pg_rewind 9 支持的客体，支持以下实例操作

POST http://127.0.0.1:8779/v1.0/<tenant id>/instance/<instance id>/action
{
    *"detach_replica": null*
}

POST http://127.0.0.1:8779/v1.0/<tenant id>/instance/<instance id>/action
{
    *"eject_replica_source": null*
}

POST http://127.0.0.1:8779/v1.0/<tenant id>/instance/<instance id>/action
{
    *"promote_to_replica_source": null*
}

公共 API 安全

无。

Python API

无。

CLI (python-troveclient)

与其他支持复制的数据存储一样，这将启用以下命令

trove create <inst> .. --replica_of <master_inst>

在 PostgreSQL 客体上。在客体上支持 pg_rewind 9 的情况下，支持故障转移和重新配置命令

trove detach-replica <inst>
trove eject-replica-source <inst>
trove promote-to-replica-source <inst>

内部 API

无。

Guest Agent

预写式日志 (WAL) 和连续传送

PostgreSQL 通过使用预写式日志提供高性能和崩溃恢复能力。WAL 文件会针对数据库的每次更改进行追加，并定期进行检查点以清除日志并将更改集成到数据库文件中 4。

PostgreSQL 流复制建立在恢复系统之上：主数据库以连续归档模式运行，将 WAL 文件的内容发送到一个或多个从服务器。这些从服务器反过来以连续恢复模式运行，在接收到日志时“恢复”。可以就地提升从服务器以代替故障的主服务器，并且可以在恢复模式下配置以支持只读事务。

复制接口

复制快照

PostgreSQL guestagent 当前提供一种备份和恢复策略，该策略使用 pg_dump 和 pg_restore 命令。这些生成逻辑转储，不能用作依赖于连续归档的复制系统的一部分。因此，使用 pg_basebackup 工具的备份/恢复策略是复制的必要条件。

启用主服务器

为了支持热备用从服务器，PostgreSQL 主服务器必须将 wal_level 设置为 hot_standby，这是最详细的模式。复制是通过赋予 REPLICATION 权限的用户处理的 6，并且已被明确允许访问 pg_hba.conf 文件中的特殊复制数据库。在启用这些更改后，将执行配置重新加载。

启用从服务器

启用从服务器需要恢复最近的备份。由于流复制启动恢复系统，因此会将 recovery.conf 文件写入 PGDATA 目录，其中包含要从中复制的主服务器的连接详细信息。需要重新启动才能启用连续恢复模式。

分离从服务器

在 PostgreSQL 中分离从服务器意味着停止恢复模式。这是通过写入配置了 trigger_file 选项的恢复配置中的特殊触发文件来完成的。

降级主服务器

降级主服务器不需要特殊操作，只需将配置更改恢复到默认值即可。

故障转移和故障恢复

Trove 中的故障转移过程由任务管理器控制，但 guest agent 必须实现允许任务管理器确定最佳要提升的从服务器以及何时可以继续执行的函数。

全局事务

标准 PostgreSQL 不支持 MySQL 中 GTID 的等效项，因此主机 + WAL 位置 8 的组合将在必要时用作事务标识符。

将实现一种简单的轮询机制，以确定从服务器何时赶上特定更改的点。

重新连接从服务器

postgresql 中的故障恢复因恢复时间线 2 而复杂。当从服务器被触发退出恢复模式时，它会跳转到新的时间线，生成新的 WAL 数据到先前数据库状态的“分支”中。这可以在这些 24 个字符的 WAL 文件名的示例中看到

000000010000000000000006
000000020000000000000007

这些代表 WAL 文件 6 和 7，但第 7 个文件位于从第一个文件分叉的第二个时间线中。

但是，当降级主服务器时，它不会更改时间线，因此为了安全地将此降级主服务器重新连接到新提升的从服务器，需要进行时间线同步。

只能通过使用工具 pg_rewind 9 安全地完成此操作。此工具支持 PostgreSQL 9.4，但必须单独编译。在 PostgreSQL 9.5 中，它将随核心产品一起提供。

对于具有可用 pg_rewind 的客体，可以进行故障恢复，否则需要手动重新创建从主服务器的另一个从服务器。

备选方案

PostgreSQL 存在许多第三方复制选项，包括 Slony、pgpool-II 和许多商业解决方案 1。

pgpool-II 依赖于插入在客户端和底层数据库实例之间的中间件。它提供了多主复制的好处，但是某些情况下可能需要冲突解决。

Slony 使用表级触发器提供主从复制。它比标准的流复制对主数据库的开销更大，但具有表级粒度的优势。

Dashboard 影响 (UX)

待定 (在批准后添加的部分)

实现

负责人

主要负责人：atomic77

里程碑

完成目标里程碑

mitaka-1

工作项

  • 实现基本的流复制

  • 实现故障转移相关 API

  • 根据需要添加 PostgreSQL 特定的钩子，以启用针对 PostgreSQL 客体的通用集成测试，以运行针对 PostgreSQL 客体的复制。

升级影响

无。

依赖项

PostgreSQL 的 pg_basebackup 增量备份和恢复策略。3 10

测试

将根据需要添加 PostgreSQL 特定的钩子到通用的集成测试框架。

文档影响

需要更新文档，以指示 PostgreSQL 客体支持复制。

附录

无。