PostgreSQL复制

Question

我们经常在办公室里这样做，这个问题还在不断地出现。如何处理PostgreSQL复制？我甚至不一定要谈论高级集群，只是简单地处理主从、主从和主-主。我发现为MySQL设置它通常非常简单。故障转移即使不是完美的，也是简单明了的，特别是对于配置起来有多容易。我们曾经玩过Slony，但这有点太过火了(模式更改需要干预，新数据库需要干预，等等)。PGPool2很不错，直到一个节点崩溃了，我们找不到一种优雅的方法(除了把所有的东西都降下来并重新播种掉掉的节点)来使复制恢复同步。基本上，这就是我通常要找的东西：

• 容易设置(我会满足于困难的设置，但易于扩展)
• 简单故障转移
• 让一个倒下的节点返回只需要时间(比如mysql )。服务器关机，你打开它，等待复制赶上)
• 模式更改不会中断复制
• 向服务器添加新数据库是无缝的(例如，像mysql一样，您可以复制整个DB服务器，因此在主服务器上创建了一个新数据库，它会自动传播到从服务器)

MySQL很好地处理了大部分这些问题，但我对PostgreSQL有一定的兴趣。此外，我们有一些情况下，它是我们的唯一选择，我们想要添加复制混合。你目前使用的是什么，你对你的解决方案有什么看法？我保证，这不是MySQL对PostgreSQL的文章，因为这不是我想要开始的。:)

Answer 1

简短的回答--如果你需要在线只读奴隶，PostgreSQL还没有这样的解决方案。

目前在这一领域正在进行两个主要的开发项目，这些项目包括在PostgreSQL 9.0 (2010年春季/夏季)中，即：

• 同步复制：

http://wiki.postgresql.org/wiki/NTT's_开发_项目

• 只读取热待机奴隶：

http://wiki.postgresql.org/wiki/Hot_备用

它的目标是实现MySQL风格复制的易用性，减去MySQL的bug/问题，再加上用户从PostgreSQL中了解到的可靠性。

所有这一切都是由2008年PostgreSQL核心团队的一份清单启动的：

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

到目前为止，拥有最大用户基础的PostgreSQL复制解决方案是Slony-I (编写起来更昂贵，模式更改更精细)、WAL配送/walmgr(不能在线使用奴隶)和Skype/Skytools的pgQ/londiste (比完成的解决方案更多的工具/构建块)。

我在日志托运，walmgr和Slony上写了一些东西-我，看

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20获取更多信息。

Answer 2

把另一个解决方案扔到戒指上:鲁比代表。

要与您的要求进行比较：

• 简单setup是的，这实际上是rubyrep的主要关注点。
• 简单的failover是的。事实上，rubyrep做了主复制--主复制--失败了，根本不需要任何操作。开始使用另一个数据库。
• 模式更改不会破坏非主键更改的replication Yes.复制甚至不必停止(但确保模式同时在双方都发生更改)来添加/删除表，只需重新启动复制守护进程。仅更改表的主键列需要付出一些努力。
• 向服务器添加一个新数据库是无缝的(例如，像mysql一样，您可以复制整个DB服务器，因此在主服务器上创建一个新数据库，它会自动传播到从服务器)--只支持有限的方式:每次只复制一个数据库。(但为多个数据库设置复制非常容易。)

Answer 3

您没有提到有一个热读-从作为一个要求，所以我将建议使用共享存储或DRBD的心跳。它只是做了正确的事情，管理是一件轻而易举的事。它相当于较旧的Microsoft集群。一个节点是活动的，另一个节点是被动的，而数据是在这两个节点之间共享的。您不必担心基于SQL的复制，因为所有这些都是在块级别下处理的。

说真的，如果你不需要阅读奴隶，这是最好的解决方案。WAL存档的内容充其量只能是一个密钥，如果您曾经中断服务器重新启动的传送过程，那么您必须再次设置所有的内容。辛辣和寂寞不会切芥末。如果你想呆在主源树上而不去做商业活动，心跳是你最好的选择。