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

目录[-]

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

时间: 2024-11-03 05:41:57

PostgreSQL高可用性、负载均衡、复制与集群方案介绍的相关文章

nginx负载均衡实现tomcat集群方案简要小结

重点两部分:一.负载均衡二.tomcat集群 所谓tomcat集群,就是可以向外提供并行服务的多台机器,任何一台服务器宕机,其它服务器可以替代它向外提供服务,而不影响用户访问. nginx是一个常用的反向代理服务,可自定义模块,实现请求转发及负载均衡(根具体采用策略有关).为了tomcat集群的高可用性,还需要实现nginx的双机热备.  一,如果仅是对外提供一个页面访问,不用区分单一用户(不区分每个访问session,不涉及用户权限,用户资料等内容),仅仅配置nginx负载均衡策略即可. ng

linux系统下对网站实施负载均衡+高可用集群需要考虑的几点

随着linux系统的成熟和广泛普及,linux运维技术越来越受到企业的关注和追捧.在一些中小企业,尤其是牵涉到电子商务和电子广告类的网站,通常会要求作负载均衡和高可用的Linux集群方案. 那么如何实施linux集群架构,才能既有效保证网站健康运行,又能节省运维成本呢?下面依据近几年的运维经历,简单梳理下自己的一点感悟. (1)机房的选择如果有自己公司的机房那是再好不过的了:如果没有,建议放在BGP机房内托管,如果有选择的话,最好是选择带有硬件防火墙的机房,这样在安全方面也有保障:网站如若是放在

「mysql优化专题」高可用性、负载均衡的mysql集群解决方案(12)

一.为什么需要mysql集群? 一个庞大的分布式系统的性能瓶颈中,最脆弱的就是连接.连接有两个,一个是客户端与后端的连接,另一个是后端与数据库的连接.简单如图下两个蓝色框框(其实,这张图是我在悟空问答解答别人的时候用Windows的自带画板画的,勿喷啊..) 版权归作者所有,哈哈 在客户端与后端中可以利用类似nginx的负载均衡解决(本专题是mysql优化,后面出高并发专题再详细讲解连接1的负载均衡),而数据库层是最脆弱的一层,一般在应用设计时在上游就需要把请求拦截掉,数据库层只承担"能力范围内

【转】高可用性、负载均衡的mysql集群解决方案

高可用性.负载均衡的mysql集群解决方案 一.mysql的市场占有率 二.mysql为什么受到如此的欢迎 三.mysql数据库系统的优缺点 四.网络服务器的需求 五.什么是mysql的集群 六.什么是负载均衡 七.mysql集群部署和实现方法 八.负载均衡的配置和测试 九.Mysql集群系统的测试(测试方案+测试脚本+测试结果分析) l mysql的市场占有率 MySQL是世界上最流行的开源数据库,已有1100多万的击活安装,每天超过五万的下 载.MySQL为全球开发者.DBA和IT管理者在可

Redis 集群方案介绍

由于Redis出众的性能,其在众多的移动互联网企业中得到广泛的应用.Redis在3.0版本前只支持单实例模式,虽然现在的服务器内存可以到100GB.200GB的规模,但是单实例模式限制了Redis没法满足业务的需求(例如新浪微博就曾经用Redis存储了超过1TB的数据).Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能,但3.0版本等到2015年才发布正式版.各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈,纷纷推出了各自的Redis集群方案.这

Redis集群方案介绍

由于Redis出众的性能,其在众多的移动互联网企业中得到广泛的应用.Redis在3.0版本前只支持单实例模式,虽然现在的服务器内存可以到100GB.200GB的规模,但是单实例模式限制了Redis没法满足业务的需求(例如新浪微博就曾经用Redis存储了超过1TB的数据).Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能,但3.0版本等到2015年才发布正式版.各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈,纷纷推出了各自的Redis集群方案.这

高可用性、负载均衡的mysql集群解决方案

一.mysql的市场占有率 二.mysql为什么受到如此的欢迎 三.mysql数据库系统的优缺点 四.网络服务器的需求 五.什么是mysql的集群 六.什么是负载均衡 七.mysql集群部署和实现方法 八.负载均衡的配置和测试 九.Mysql集群系统的测试(测试方案+测试脚本+测试结果分析) l mysql的市场占有率 MySQL是世界上最流行的开源数据库,已有1100多万的击活安装,每天超过五万的下 载.MySQL为全球开发者.DBA和IT管理者在可靠性.性能.易用性方面提供了选 择. 第三方

负载均衡的mariadb集群搭建

集群介绍: Galera是一个MySQL(也支持MariaDB,Percona)的同步多主集群软件,目前只支持InnoDB引擎. 主要功能: 同步复制 真正的multi-master,即所有节点可以同时读写数据库 自动的节点成员控制,失效节点自动被清除 新节点加入数据自动复制 真正的并行复制,行级 用户可以直接连接集群,使用感受上与MySQL完全一致 优势: 因为是多主,所以不存在Slave lag(延迟) 不存在丢失交易的情况 同时具有读和写的扩展能力 更小的客户端延迟 节点间数据是同步的,而

同台电脑部署多组Tomcat负载均衡(或集群)

可能这种需求比较少见,不过如果手上服务器不够用.可以考虑先这么干着.. 具体Tomcat怎么搭集群,就不在这细说了.只写同台电脑部署多组集群需要修改和注意的地方. 一.Apache 先是Apache,同一台电脑装多台Apache需要把原来的复制一份. 修改conf/httpd.conf 1.文件中会有一些Apache的路径,需要全部替换成新位置 2.端口号需要改 然后添加服务:管理员权限打开cmd切换到新Apache目录下面执行:httpd -k install -n Apache2.2_2 二