问题标签 [slony]

我正在尝试使用 slony 教程中的示例，但看起来他们的示例中存在语法错误。我尝试在网上查找更多文档，但我还没有真正找到展示如何使用 slonik 命令的好文档。我试图运行的脚本是：

但我不断收到以下错误：

根据第一个答案更新上面的脚本。现在的错误是：

我们正在考虑将 Slony 和 PGPool 作为在我们的应用程序中处理故障转移的替代方案——看起来因为我们至少需要两个数据库服务器，所以我们也可以利用负载平衡——

在什么情况下 Slony 比 PGPool 好，反之亦然？

我发现此错误发生在 SQL 插入语句运行后。SQL 由从 Java 执行的存储过程调用。请看下图。

我的数据库中有 2 个模式。“app” 和 “report” 两者都是由 Slony 相互同步的。我检查了表格，发现这些记录是从20:39:13开始插入的。我担心的一点是为什么 Postgres 在22:15:04向 Java 返回释放信号，因为插入语句已经在20:39:13执行。我想上面的过程受到了插入语句的影响，过程被挂起，需要等到它完成然后释放到Java。

提前谢谢停止:)

我有一个场景，我有一个中央服务器和一个节点。服务器和节点都可以运行 PostgreSQL，但是节点上的存储空间是有限的。节点高速收集数据并将数据写入本地数据库。服务器需要从节点复制数据。我计划用Slony-I或Bucardo来完成这个。节点需要能够以设定的时间间隔从其表中删除所有记录，以最小化使用的磁盘空间。我是否应该将pgAgent与由脚本组成的作业一起使用

运行脚本的实际批处理文件类似于

?

如果这是完成此任务的最佳方法，或者是否有人知道从远程数据库中提取数据并清除该远程数据库以节省远程节点上的空间的更有效方法，我只是在寻找意见。谢谢你的时间。

PostgreSQL 版本：9.1.2

PgAdmin iii 版本：1.14.0

使用的操作系统：ubuntu 10.04

我已经在网上搜索以安装和实施 slony-i 复制，但我找不到任何合适的指南...，我已经阅读了一些指南，但我无法理解...我是新手，所以请帮我简单的步骤...

所以，任何人都可以分享我的分步指南，安装 slony-i 并进行测试复制..

我有一个 DebianEtch/Postgres 8.1 设置，它使用来自 master > slave 的 slony 进行复制。

这些服务器正在被 Debian Squeeze/Postgres 8.4 服务器取代。

我的 Squeeze 服务器之间的 Slony 运行良好，需要从 Etch.Master 复制到 Squeeze.Master，然后再拔下 Etch 盒上的插头。

然而：

我猜它在抱怨 Etch 和 Squeeze 服务器之间的“某些东西”的不同版本，但不确定是什么。

Etch box 是一个实时服务器，不会受到干扰，尽管如果需要（并且可用）我可以安装一个新版本的 slony，并且仍然必须复制到 Etch.Slave，尽管为此需要一些“停机时间”。

那么，我是否有希望，或者我必须在切换时转储/恢复相关的表、序列等？

干杯。

德布。挤压，Postgres 8.4，Slony 1.2.21

我创建了一个主 > 从集群，它已经完成了初始复制。但是，我无法获得更多数据来复制。我一直对应该运行哪些命令来在每一端启动所需的进程/守护进程感到有点困惑。

任何人都可以启发我吗？

干杯。

正如标题所示，

到目前为止，我发现的当前教程使用 Shell 脚本文件中的嵌入式 SLON 命令来设置 Slony-I 主从复制所需的配置。例如：Slony-I 安装教程

我想知道是否可以嵌入 SLON 设置命令并在另一种语言中调用它们，例如在 linux 环境中工作的 C/C++/Python？

我正在使用运行 Postgresql 8.1.3 和 Slony-I 复制系统（slon 版本 1.1.5）的 SuSE 机器（cat /etc/issue: SUSE Linux Enterprise Server 11 SP1 (i586)）。我们在这台服务器上的两个数据库之间有一个有效的复制设置，它正在生成要发送到我们负责维护的远程机器的日志传送文件。截至今天早上，我们遇到了这个问题。

一段时间以来，我们在这台机器上遇到了奇怪的内存问题——即使剩余大量可用内存，oom-killer 似乎也很惊人。这为我们当前的问题的发生奠定了基础 - 我们昨晚在系统上运行了大规模更新，同时关闭了复制。现在，就目前的情况而言，我们无法复制更改 - slony 正在尝试将所有更改编译到一个庞大的日志文件中，并且在运行大约半小时左右后，它遇到了 oom-killer 问题，该问题似乎重新启动了复制包。由于它一直在尝试重建同一个包，所以它永远不会到达任何地方。

我的第一个问题是：有没有办法限制 Slony 日志传送文件的大小，以便它写出不超过“X”字节（或 K，或 Meg 等），并且在超过该大小后关闭当前的日志传送文件并开始一个新的？在 oom-killer 以合理的规律性命中之前，我们已经能够达到大约 4 megs 的大小，所以如果我能把它限制在那里，我至少可以开始生成更小的文件，并希望最终能通过这个。

我想我的第二个问题是：有没有人有比我要问的更好的解决方案来解决这个问题？很有可能我在看问题时得到了隧道视野，而我真正需要的只是-a-解决方案，而不一定是-my-解决方案。

我正在考虑在不同的从站上复制不同的分区/表空间的场景。有可能实现这一目标吗？如果是这样，通过哪些可能的方案。

谢谢。