PostgreSQL复制

我们经常在办公室蝙蝠,这个问题还在继续。 你如何处理PostgreSQL复制? 我甚至不一定要谈论高级集群,只要保持简单,主从,Master-MultiSlave和Master-Master。 我发现为MySQL设置它通常很简单。 如果不是完美的,故障转移很简单,特别是configuration有多容易。 我们已经和Slony玩过了,但是有点太过分了(模式变化需要干预,新的数据库需要干预等)。 PGPool2是相当不错的,直到一个节点崩溃,我们无法find一个优雅的方式(除了把所有东西都放下来,重新放置下降的节点),以使复制重新同步。 基本上这是我通常寻找的:

  • 简单的设置(我会解决困难的设置,但容易扩展)
  • 简单的故障转移
  • 把一个倒下的节点带回来只需要时间(例如像mysql一样,服务器停机,你把它提起来,等待复制赶上)
  • 架构更改不会中断复制
  • 添加一个新的数据库到服务器是无缝的(即像mysql一样,你可以复制一个完整的数据库服务器,所以在主服务器上创build一个新的数据库,它会自动传播到从服务器)

MySQL处理大部分这些都相当好,但我对PostgreSQL有一定的喜爱。 此外,我们还有一些情况是我们唯一的select,我们希望将复制添加到组合中。 你现在在用什么,你觉得你的解决scheme? 这不是一个MySQL与PostgreSQL的post,我保证,因为这不是我想开始。 🙂

    简短的回答 – 如果你需要在线只读从站,那么PostgreSQL还没有这样的解决scheme。

    目前在这个领域有两个主要的开发项目,包括PostgreSQL 9.0(2010年春夏),即:

    • 同步复制:

    http://wiki.postgresql.org/wiki/NTT's_Development_Projects

    • 只读热备份从站:

    http://wiki.postgresql.org/wiki/Hot_Standby

    它们旨在实现MySQL风格复制的易用性,减去MySQL所具有的缺陷/问题以及用户从PostgreSQL得知的可靠性。

    所有这些都是在2008年由PostgreSQL核心团队的一个清单开始的:

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

    到目前为止,拥有最大用户基础的PostgreSQL复制解决scheme是Slony-I(写入费用更高,更改架构),WAL shipping / walmgr(从站无法在线使用)以及Skype / Skytools中的pgQ / londiste比完成的解决scheme更多的工具/构build块)。

    我已经在日志发送上写了一些东西,Walmgr和Slony-I,请参阅

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

    把另一个解决scheme扔进环:rubyrep。

    要比较你的要求:

    • 设置简单
      是的,这实际上是rubyrep的主要焦点。
    • 简单的故障转移
      是。 事实上,rubyrep做主 – 主复制 – 故障转移,根本不需要任何操作。 刚开始使用其他数据库。
    • 架构更改不会中断复制
      是。
      对于非主键更改,复制甚至不必停止(但要确保模式同时在两侧进行更改)
      要添加/删除表,只需重新启动复制守护进程。 只更改表的主键列需要一点努力。
    • 添加一个新的数据库到服务器是无缝的(即像mysql一样,你可以复制一个完整的数据库服务器,所以在主服务器上创build一个新的数据库,它会自动传播到从服务器)
      这只受到有限的支持:每个rubyrep设置一次仅复制一个数据库。 (但是为多个数据库设置复制非常简单。)

    你没有提到有一个热的读取 – 从属作为一个需求,所以我打算build议使用Heartbeat共享存储或DRBD。 它只是做正确的事情和pipe理是一件轻而易举的事情。 这是旧版Microsoft SQL Server集群的Linux等价物。 一个节点处于活动状态,另一个节点处于被动状态,而数据在两者之间共享。 您不必担心基于SQL的复制,因为它在块级别处理得更低。

    说真的,如果你不需要阅读奴隶,这是迄今为止最好的解决scheme。 WAL归档文件充其量是最好的,如果你打乱了重启服务器的运行过程,你必须重新设置一切。 sl and和londiste不切断芥末。 如果你想留在主要的来源树上,而不是去商业,心跳是你最好的select。

    从您的要求看,PITR似乎是解决您的问题最简单的方法:

    在线备份和时间点恢复(PITR)

    你没有说你需要查询从服务器,所以PITR可能是正确的。

    它是8.0版PostgreSQL的标准部分,所以你可能已经拥有了启动和运行所需的一切。

    如果您发现说明过于冗长,请查看SkyTools WalMgr ,它将创build/故障转移到热备数据单命令任务。

    对于更复杂的复制场景,我有很好的经验Slony-1,但是PostgreSQL有很多好的复制/ HA选项。

    如果你想asynchronous的主/从复制考虑Londiste(来自Skype的skytools包的一部分)wiki.postgresql.org/wiki/Londiste_Tutorial

    安装很简单,添加一个新的数据库很容易,复制只是“赶上”。

    虽然故障转移不是内置的。 您将需要更改应用程序连接string或混淆另一层软件后面的数据库连接。

    一些模式更改很容易。 其他人则更加困难。 这取决于你的应用程序。 下一个版本的skytools(3.0版本)应该能够处理DDL,并且包含便于故障转移的function。

    findSlony太痛苦了,我们搬到了Londiste。

    在这里看到一个讨论,也许这可以帮助:

    http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html

    Bucardo Version One的竞争对手,在页面上find更低的位置:

    http://www.planetpostgresql.org/

    真的没有任何免费/开源的方式来提供你在找什么。 如果你想要的东西如此全面,请查看各种第三方商业复制解决scheme。

    现在,可以使用写头日志(WAL)发运,使用Postgres来自定义复制。

    http://www.postgresql.org/docs/8.3/interactive/warm-standby.html 

    基本上,您可以将辅助节点置于连续恢复模式,并且每隔{小间隔}将事务日志导入到其中。 Postgresconfiguration有一个“存根”,允许你在完成一个WAL的时候完成某些事情,那么这个设置就是基于这些“存根”的。

    但是,这不允许你做主 – 主和/或循环复制。

    无论如何,这绝对是不合适的,但我不会把它称为“简单的安装”,“简单的故障转移”,“无缝的”或类似的东西。

    除了“添加一个新的数据库”的东西,你可以尝试猛犸复制器( https://projects.commandprompt.com/public/replicator )。 它是开源的,易于设置和支持故障转移。 主要限制是单个数据库和无法复制DDL更改,都在TODO列表中。

    Postgres-R看起来很有希望,但我不知道这个项目是否还活着。

    我目前正在看钨复制器,我还有很远的距离,但可能值得一看。

    http://www.continuent.com