PostgreSQL 需要一个新的负载均衡器

Send_linux

     我们为客户做了很对高可用性的PostgreSQL部署。从9.1版开始,流复制(SR)就非常合适干这些事情，通过一些简单的工具来管理，我们可以有效的进行跨客户机扩展和AWS节点的扩展。但我们深刻的意识到当前缺乏的是简单的负载均衡和故障恢复功能。. pgPool设置好后，我们将经常它来做这些事情。但是pgPool 经常使我们遭受sporkism失控：它是一个拥有负载均衡、故障恢复工具、多主机复制、缓存、对SR的兼容、Slony和Bucardo所有功能。如果你需要使用到所有的这些东西，那就好。但是如果你只需要其中的一个你，那你还是要陷入到所有功能的复杂性中去。你还得被迫忍受那些不是针对普通情况，而是满足针对特定SRA客户需求的做的设计。我们想了很久，最终还是没想到要为了满足通过情况，该如何修复pgPool；我们需要重头开始设计一种新的，简单的，能满足80%使用情形的一种工具。

我们需要一个简单工具，或者一套工具，它们被设计成只拥有故障恢复、有负载均衡、有负载均衡或针对PostgreSQL的流复制这些功能中单一的一个。用户可以根据自己的需要对这些工具进行随机组合，就像pgBouncer。他们应该能可以通过Web服务提供信息和进行配置。 我把第一个工具叫做“pgFailover”。这个工具的作用是管理服务器的主从服务组，包括同时管理计划或非计划的故障恢复。为了避免“裂脑”咋一个组中，你只需要激活一个pgFailover节点。而且它不需要数据库连接。

pgFailover会跟踪主节点和几个它的复制节点。每个服务器的信息，包括每台服务器的复制信息和主服务器的pg_stat_replication表(记录复制的相关信息，包括复制用的用户名，复制类型，同步状态等)的信息都会被监控。pgFailover将通过web服务提供这些信息，同时它支持通过web服务和本地命令行执行命令。 根据用户设置的规范，pgFailover可以提供下面的操作：故障转移到其他新的主节点；将其它复制节点设置为主节点；添加新的复制节点而不需要进行数据同步；重新同步一个复制节点和关闭一个复制节点。它还会自动处理一些情况。基于用户设置的一些当“遇到无响应情况”的条件，它会将服务转移到最好的一个复制节点。系统会根据配置或者最新的复制时间戳，决定哪一台复制节点为故障转移的节点。同样的，当复制节点变成不可用时，它也也会在可用性列表中被丢弃。

第二个工具我把它叫做“pgBalancer”,来自Skype的未发行的工具。pgBalancer能对跨复制节点的数据库连接进行负载均衡。它自己不会处理故障或者监听服务器，而是依赖于pgFailover。用户可拥有几个独立的pgBalancer服务器，以便支持高的可用性或更加复杂的负载均衡配置。 由于自动区分读和写是一件不可能的任务，所以我们不会试图去解决这个问题。但我们假设应用本身是知道是否是读或写的，所以我们提供了两个独立的数据库连接端口，一个作为读写(RW)连接，一个做为只读(RO)连接。pgBalancer同时包含了一些关于哪些服务器是通过配置文件来连接的，哪些服务器是通过Web服务来查询pgFailover服务器消息的一些信息。只读连接将会基于“最近活动”和“循环算法”对所有的可用服务器进行负载均衡。

   pgBalancer也能通过Web服务来接受各种命令，包括：暂停一个或所有的服务；断开一个指定的连接或所有连接;写入节点发生故障时将其转移到指定的新服务器；从负载均衡列表中删除一台服务器;向负载均衡列表添加一台服务器;列出所有连接的列表；列出所有服务器的列表。 如果我们可以建立两个工具来或多或少地匹配以上规格，我想他们还需要走很多路来进一步支持我们为未来应用所要使用的各类高可用性的，水平缩放的PostgreSQL服务器集群。如果时间允许，我会在pgFailover上开始工作。一个怪胎也可以有梦想，不是吗？
        
   
英文原文：PostgreSQL needs a new load balancer

本文转自：开源中国社区 [http://www.oschina.net]
本文地址：http://www.oschina.net/translate/postgresql-needs-new-load-balancer

本文来自ChinaUnix新闻频道，如果查看原文请点：http://news.chinaunix.net/opensource/2013/0723/2860146.shtml