PostgreSQL的高可用与数据复制方案

PostgreSQL是开源的,有多种高可用与数据复制方案,这里作个简单的比较。html

1、高可用性、负载均衡、复制方案

共享磁盘失效切换sql

    共享磁盘失效切换经过仅保存一份数据库副原本避免花在同步上的开销。 这个方案让多台服务器共享使用一个单独的磁盘阵列。 若是主服务器失效,备份服务器将当即挂载该数据库, 就像是从一次崩溃中恢复同样。这个方案容许快速的失效切换而且不会丢失数据。数据库

    共享硬件的功能一般由网络存储设备提供, 也可使用彻底符合POSIX行为的网络文件系统(参阅Section 17.2.1)。 这种方案的局限性在于若是共享的磁盘阵列损坏了, 那么整个系统将会瘫痪。 另外一个局限是备份服务器在主服务器正常运行的时候不能访问共享的存储器。ruby

文件系统复制(块设备)服务器

    一种改进的方案是文件系统复制:对文件系统的任何更改都将镜像到备份服务器上。 这个方案的惟一局限是必须确保备份服务器的镜像与主服务器彻底一致— 特别是写入顺序必须彻底相同。DRBD是Linux上的一种流行的文件系统复制方案。网络

事务日志传送负载均衡

    热备份服务器能够经过读取WAL记录流来保持数据库的当前状态。 若是主服务器失效,那么热备份服务器将包含几乎全部主服务器的数据, 并能够迅速的将本身切换为主服务器。这是一个异步方案, 而且只能在整个数据库服务器上实施。dom

    使用基于文件的日志传送或流复制,或二者相结合。 前者参阅Section 25.2, 后者参阅Section 25.2.5。 请参阅Section 25.5获取关于热备的信息。异步

基于触发器的主备复制函数

    这个方案将全部修改数据的请求发送到主服务器。 主服务器异步向从服务器发送数据的更改信息。 从服务器在主服务器运行的状况下只应答读请求。对于数据仓库的请求来讲, 从服务器很是理想的。

    Slony-I是这个方案的一个例子,它支持针对每一个表的粒度并支持多个从服务器。 由于它异步、批量的更新从服务器, 在失效切换的时候可能会有数据丢失。

基于语句的复制中间件

    可使用一个基于语句的复制中间件程序截取每个SQL查询, 并将其发送到某一个或者所有服务器。每个服务器都独立运行。 读-写请求发送给全部服务器,因此每一个服务器接收到任何变化。可是只 读请求则仅发送给某一个服务器,从而实现读取的负载均衡。

    若是只是简单的广播修改数据的SQL语句, 那么相似random()CURRENT_TIMESTAMP 以及序列函数在不一样的服务器上将生成不一样的结果。 这是由于每一个服务器都独立运行而且广播的是SQL语句而不是如何对行进行修改。 若是这种结果是不可接受的,那么中间件或者应用程序必须保证始终从同 一个服务器读取这些值并将其应用到写入请求中。 另外还必须保证每个事务必须在全部服务器上所有提交成功或者所有回滚, 或者使用两阶段提交(PREPARE TRANSACTION 和COMMIT PREPARED)。 Pgpool-II和Continuent Tungsten是这种方案的实例。

异步多主服务器复制

    对于那些不规则链接的服务器(好比笔记本电脑或远程服务器), 要在它们之间保持数据一致是很麻烦的。 在这个方案中,每台服务器都独立工做并周期性的与其余服务器通讯以识别相互冲突的事务。 能够经过用户或者冲突判决规则处理出现的冲突。

同步多主服务器复制

    在这种方案中,每一个服务器均可以接受写入请求, 修改的数据将在事务被提交以前必须从原始服务器广播到全部其它服务器。 过多的写入动做将致使过多的锁定,从而致使性能低下。 事实上,在多台服务器上同时写的性能老是比在单独一台服务器上写的性能低。 读请求将被均衡的分散到每台单独的服务器。 某些实现使用共享磁盘来减小通讯开销。 同步多主服务器复制方案最适合于读取远多于写入的场合。 它的优点是每台服务器都能接受写请求—所以不须要在主从服务器之间划分工做负荷。 由于在服务器之间发送的是数据的变化, 因此不会对非肯定性函数(好比random())形成不良影响。

    PostgreSQL不提供这种类型的复制。 可是PostgreSQL的两阶段提交(PREPARE TRANSACTION和 COMMIT PREPARED) 能够用于在应用层或中间件代码中实现这个功能。

商业解决方案

    由于PostgreSQL是开放源代码而且很容易被扩展, 许多公司在PostgreSQL的基础上建立了商业的闭源解决方案, 提供独特的失效切换、复制、负载均衡功能。

Feature Shared Disk Failover File System Replication Transaction Log Shipping Trigger-Based Master-Standby Replication Statement-Based Replication Middleware Asynchronous Multimaster Replication Synchronous Multimaster Replication
Most Common Implementation NAS DRBD Streaming Repl. Slony pgpool-II Bucardo  
Communication Method shared disk disk blocks WAL table rows SQL table rows table rows and row locks
No special hardware required   • • • • • •
Allows multiple master servers         • • •
No master server overhead •   •   •    
No waiting for multiple servers •   with sync off •   •  
Master failure will never lose data • • with sync on   •   •
Standby accept read-only queries     with hot • • • •
Per-table granularity       •   • •
No conflict resolution necessary • • • •     •

有几个解决方案不适合上边这些分类:

数据分区

    数据分区将表拆分为数据集。每一个数据集只有一台服务器能够修改。 例如,数据能够按办事处进行分区,例如, 伦敦和巴黎,每一个办公室用一个服务器。 若是查询须要伦敦和巴黎相结合的数据,应用程序能够查询两台服务器, 或主/备用复制能够用来保持每一个服务器上有其余办公室的只读数据副本。

多服务器并行查询执行

    许多上述解决方案容许多个服务器来处理多个查询, 但不是容许单个查询使用多个服务器来更快完成。 此解决方案容许多个服务器上单个查询同时运行。 它一般被经过服务器之间的数据分开而执行其查询的一部分, 并将结果返回到中央服务器,由它来联合结果并返回给用户。 Pgpool-II有这种能力。 也可使用PL/Proxy工具集实现。

2、多节点集群方案比较

能够基于Replication Stream(流复制)。

Program License Maturity Replication Method Sync Connection Pooling Load Balancing Query Partitioning
PgCluster BSD Stalled暂停 Master-Master Synchronous No Yes No
pgpool-I BSD Stable Statement-Based Middleware Synchronous Yes Yes No
Pgpool-II BSD Recent release Statement-Based Middleware Synchronous Yes Yes Yes
slony BSD Stable Master-Slave Asynchronous No No No
Bucardo BSD Stable Master-Master, Master-Slave Asynchronous No No No
Londiste BSD Stable Master-Slave Asynchronous No No No
Mammoth BSD Stalled Master-Slave Asynchronous No No No
rubyrep MIT Stalled Master-Master, Master-Slave Asynchronous No No No
BDR (Bi-Directional Replication) PostgreSQL (BSD) Beta Master-Master
(no triggers needed)
Asynchronous No No No
pg_shard LGPL Recent release Statement-based Middleware (as an extension) Synchronous No Yes Yes
相关文章
相关标签/搜索