文档章节

PostgreSQL高可用性、负载均衡、复制与集群方案介绍

YuanyuanL
 YuanyuanL
发布于 2015/08/27 10:57
字数 2022
阅读 11000
收藏 5

9.3官方文档(中文):http://58.58.27.50:8079/doc/html/9.3.1_zh/high-availability.html

复制、集群和连接池: https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

集群方案功能列表: http://blog.osdba.net/46.html


一、高可用性、负载均衡、复制的几个方案比较:

共享磁盘失效切换

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

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

文件系统复制(块设备)

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

事务日志传送

    热备份服务器可以通过读取WAL记录流来保持数据库的当前状态。 如果主服务器失效,那么热备份服务器将包含几乎所有主服务器的数据, 并可以迅速的将自己切换为主服务器。这是一个异步方案, 并且只能在整个数据库服务器上实施。

    使用基于文件的日志传送或流复制,或两者相结合。 前者参阅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工具集实现。


二、多节点集群方案比较

可以基于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



© 著作权归作者所有

共有 人打赏支持
YuanyuanL

YuanyuanL

粉丝 152
博文 322
码字总数 188376
作品 0
济南
部门经理
私信 提问
加载中

评论(2)

YuanyuanL
YuanyuanL

引用来自“纯洁徐”的评论

想知道,你现在在用的是哪种方案?or 用过哪些靠谱的方案?
现在pg用的最多的是流复制。。MPP用greenplum,集群近几年又开发了xl和xc等不过目前还有不少待完善的地方。
纯洁徐
纯洁徐
想知道,你现在在用的是哪种方案?or 用过哪些靠谱的方案?
PostgreSQL 9.6 更新版本发布说明

PostgreSQL是世界上最先进的开源数据库,9.6最新版本由PostgreSQL全球开发者今天发布。 此版本将允许用户纵向扩展(scale-up)和横向扩展(scale-out)来提高数据库的查询性能。 新功能包括并行查...

有理想的猪
2016/09/30
6.9K
31
PostgreSQL 流计算插件pipelinedb sharding 集群版原理介绍 - 一个全功能的分布式流计算引擎

标签 PostgreSQL , pipelinedb , 流计算 , sharding , 水平扩展 背景 pipelinedb cluster定位为一个分布式流式计算引擎。拥有强大的分布式计算能力,扩展能力,高可用能力,负载均衡能力,读...

德哥
04/18
0
0
PostgreSQL 数据库初体验

高强,“DBA+济南群”联合发起人。现就职于山东华鲁科技发展股份有限公司。擅长Oracle、AIX、Linux、PostgreSQL和DB2等产品的实施、运维和故障处理。曾是一名存储工程师,负责实施存储、双机...

高强
2015/10/15
0
0
PostgreSQL 基于PG内置流复制的,靠谱的PostgreSQL高可用方案

标签 PostgreSQL , etcd , raft , 高可用 , Patroni 背景 可能是目前除“基于共享存储的数据库高可用方案”以外,基于PG内置流复制的,最靠谱的PostgreSQL高可用方案。 《Patroni: PostgreS...

德哥
10/05
0
0
大佬为你揭秘微信支付的系统架构,你想知道的都在这里了

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由李跃森发表于云+社区专栏 李跃森,腾讯云PostgreSQL首席架构师,腾讯数据库团队架构师,负责微信支付商户系统核心数据库的...

腾讯云+社区
09/14
0
0

没有更多内容

加载失败,请刷新页面

加载更多

vue-cli 3 分环境打包

在vue-cli3的项目中, npm run serve时会把process.env.NODE_ENV设置为‘development’; npm run build 时会把process.env.NODE_ENV设置为‘production’; 此时只要根据process.env.NODE_...

灰白发
12分钟前
1
0
集合初始化,泛型及相关操作

集合初始化通常进行分配容量,设置特定参数等相关工作,推荐在任何情况下,都需要显式地设定集合容量的初始大小。 ArrayList 使用无参构造时,默认大小为 10 ,也就是说在第一次add的时候,分...

Canaan_
21分钟前
1
0
Sping之项目中pofile的应用

工程中,我们必须要面对的一件事就是, 开发环境中使用的数据库连接地址等与生产上的不同, 如果上线, 那么我们是否还要手动修改这些地址么, 这样做有很多弊端, 不方便, 这时我们就可以使用spr...

克虏伯
29分钟前
0
0
Linux中安装MySQL

Linux中安装MySQL 一、准备工作 此处准备的操作系统位CentOS 7。 MySQL安装包: MySQL-server-5.6.29-1.linux_glibc2.5.x86_64.rpm MySQL-client-5.6.29-1.linux_glibc2.5.x86_64.rpm 将准备......

星汉
34分钟前
1
0
深入理解Hadoop之HDFS架构

Hadoop分布式文件系统(HDFS)是一种分布式文件系统。它与现有的分布式文件系统有许多相似之处。但是,与其他分布式文件系统的差异是值得我们注意的: HDFS具有高度容错能力,旨在部署在低成...

架构师springboot
38分钟前
1
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部