PostgreSQL中的本机流复制仅在具有相同主版本的服务器之间起作用。 在上一篇文章中我们讨论了逻辑复制。 我们看到了逻辑复制如何帮助将数据从PostgreSQL的一个版本迁移到另一个版本。 但是逻辑复制仅适用于受支持的PostgreSQL版本，例如PostgreSQL 9.4和PostgreSQL11。如何处理9.4之前的版本？ 使用Slony-I 。
与Slony-I一起使用复制将数据从旧数据库传输到最新版本的PostgreSQL。 什么是Slony，它如何运作？
这是我们将PostgreSQL的较早版本升级或迁移到新版本中的第四篇文章，我们在此学习了各种更新PostgreSQL数据库的方法。
斯洛尼
Slony是PostgreSQL的应用程序级逻辑复制实现。 或者，它是第三方复制工具，需要单独的安装和配置。 Slony已经存在了很长时间。 最新版本支持PostgreSQL从8.4到11。
复制的主要目的是将更改从一台数据库服务器转移到另一台数据库服务器。 为了更好地理解体系结构，我们来看一下术语：Slon，事件和slonik。
顺便说一句，斯洛尼（Slony），如果您没有猜到，它们就是“大象”。 他们的记忆力真的很棒。 严格而可爱的大象在PostgreSQL徽标上炫耀绝非偶然。
斯隆
Slon是一个守护程序，可在Slony-I复制中的每个PostgreSQL节点上运行。 这些守护程序用于处理每个PostgreSQL服务器的配置和复制事件。 每个PostgreSQL服务器都称为主机。 所有节点一起形成Slony群集。
发布者节点是更改的来源，订阅者节点从发布者那里接收并应用更改。
要配置复制，必须指定所有复制的表或一组复制。 订阅适用于特定集合。 对复制表的更改被合并到SYNC中，SYNC是一组在订阅服务器上一起应用的事务。
大事记
更改从发布者报告为事件。 当事件由远程主机上的Slon守护程序处理时，将生成确认。 事件会通知节点配置更改，例如添加或删除新节点，新订阅或DDL更改。
每个事件都有其自己的唯一源标识符，序列号，事件节点上快照的事务标识符，几个自变量以及带时区的时间戳。
写入PL / pgSQL的触发器会将所有更改记录到复制表中。 不幸的是，没有可靠的方法来处理对Blob，DDL的更改或对用户和角色的更改。
斯洛尼克
这是一个带有分析器和解释器的命令行实用程序，该分析器和解释器接受slonik脚本-一种简单的声明性语言。 它旨在克服程序语言的局限性。 借助slonik命令，您可以在Slony中配置或修改复制，并且可以将它们嵌入到Shell脚本中。 它接受来自标准输入或文件的命令。 以下示例显示了如何将slonik脚本传递给slonik并嵌入到Shell脚本中。
在pgbench数据库中为简单的主从方案创建初始配置的脚本如下所示：
#!/bin/sh slonik <<_EOF_ cluster name = percona_pg; node 1 admin conninfo = 'dbname=pg93 host=pg93_host user=percona_pg93_user'; node 2 admin conninfo = 'dbname=pg11 host=pg11_host user=percona_pg11_user'; #-- # Creates a _$(clustername), this example, _percona_pg schema #-- init cluster ( id=1, comment = 'Legacy PG Node'); #-- # Add a list of tables being replicated to a set. #-- create set (id=1, origin=1, comment='pgbench'); set add table (set id=1, origin=1, id=1, fully qualified name = 'public.pgbench_accounts', comment='accounts'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.pgbench_branches', comment='branches'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.pgbench_tellers', comment='tellers'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.pgbench_history', comment='history'); #-- # Create the second node (the slave) tell the 2 nodes how to connect to # each other and how they should listen for events. #-- store node (id=2, comment = 'Target node', event node=1); store path (server = 1, client = 2, conninfo='dbname=pg93 host=pg93_host user=percona_pg93_user'); store path (server = 2, client = 1, conninfo='dbname=pg11 host=pg11_host user=percona_pg11_user'); _EOF_
为什么Slony方便迁移？
尽管具有内部逻辑复制的优点，但对于PostgreSQL 9.4之前的版本，您必须使用此第三方解决方案。 基于触发器的方法取决于数据库API-两个版本都必须兼容才能使用PL / pgSQL和SQL语法。
如何调整数据库以用于Slony？
- 表必须具有主键。 在没有主键的情况下向所有表添加一个串行字段。
- OID Blob的更改不会被复制。 如果您的列的值较短，请将其转换为BYTEA。 如果对象很大（例如图像），则最好将数据存储在外部存储中（例如，Amazon云中的S3）。 如果更改应用程序太复杂，请在迁移的最后一步中应用Blob更改。
- ALTER TABLE和其他DDL操作。 Slony不会检测表结构更改。 使用slonik EXECUTE SCRIPT命令将具有SQL或DDL字符串的SQL文件应用于整个复制群集。
从早期版本的PostgreSQL在线迁移
- 创建具有超级用户特权的复制用户。 您可以详细配置权限，但是要复杂得多。
- 使用TCP / IP访问在目标位置创建数据库。
- 将表定义从主服务器复制到从服务器。
- 安装Slony-I。 在具有旧版OS的服务器上，从源代码安装Slony-I会更容易。
- 将群集，表集和节点连接信息定义为slonik命令的列表。
- 在每个PostgreSQL服务器上运行slon守护程序。 检查标准输出或日志文件是否存在连接错误。
- 运行slonik subscription命令以启动同步。
- 在新版本的Postgres中测试只读请求。
- 复制并同步所有数据后，请停止应用程序并将其定向到新的Postgres服务器。
- 在新版本的PostgreSQL中使用卸载节点删除所有Slony复制痕迹。
过渡到以前的版本
使用相同的过程升级到以前的版本。 使用Slony，您可以从Slony版本支持的任何版本复制到PosgreSQL的任何版本。 最低支持的版本是8.4。
总结
我们大致了解了如何使用Slony在最少的停机时间内升级到新版本。 在我们的网络研讨会上了解更多信息。