7.6 PostgreSQL和高可用性

数据库是我们日常数字生活的一部分，并期望它们快速工作。

您浏览网上论坛吗？那个帖子在数据库中。您看医生吗？您的医疗记录在数据库中。您在网上购物吗？那个货物，您的数据和以前购买的东西都在数据库中。

希望所有这些数据在几秒钟内出现。这不仅是您的期望。一个小网店可能同时有成百上千的访客，每个访客都希望网站快速展现。较大的网站可以同时处理几万或者几十万的访问。

这意味着该服务背后的数据库必须一直可用。当我们考虑这样的网站服务于全球的用户时，问题的范围变得很明显。总是有有光线的地方，因此没有夜晚可以隐藏停机时间。对于个别的机器来说，停机时间是绝对必要的，因为需要定期维护，像软件升级和清洁，更不用提当一些实际的硬件出问题的时候了。

数据库的客户端程序，诸如web服务器或计费软件，希望数据库不在一个特定的计算机上(具有给定的序列号)但在一个特定的网络上。计算机可以按需获取和释放网络地址。(在有限的条件下，TCP网络是另一个大的课题。)这使得特定的计算机可以停机，另一台计算机获取相同的地址。客户端程序会注意到最初的数据库无响应并尝试重新连接，现在连接到另外一台计算机。在一个集群中的两个节点之间漂移的地址称为漂移地址或虚拟IP地址(virtual IP address)。

集群的管理员可以发出命令，使一台机器离线，换句话说，停止对 数据库客户端服务，另外一台机器自动接管服务。

既然已经讨论过了高可用集群的概念，现在是时候看两个不的，小数据库集群的详细例子了。

7.6.1 高可用性与仲裁

在本节中，我们看一个小集群，其中防护是通过集群中的节点自愿完成。

仲裁意味着多数，它可以由具有奇数个节点的集群保证。

如果两个节点之间的网络通信被切断，就形成了独立的“孤岛”节点。至少会有两个这样的岛，没有岛的大小是和另外一个岛的大小是一样的，因为节点的总数是奇数。

所有这些岛通过计算岛内活着的节点并和整个集群中节点的总数比较来“知道”它们是否有多数或少数。

有了适当的限制，处于少数的岛提供的服务会自动放弃，并被另一个处于多数的岛接管。如果网络断开如此严重以至于没有岛比总节点数的一半大，则每个岛将放弃服务。这是一件好事，因为它可以防止脑裂情形并且为处于不同岛的不同的客户提供相同的服务。当一个复制的数据库进入这样的状况意味着麻烦：两个(或更多)master数据库开始服务于不同的客户。给处于不同数据库中的数据分配相同的数字标识会发生主键冲突。当尝试合并数据库时，这也会导致外键冲突。清理起来可能需要大量的手工劳动。

在这个高级的视图中，我们有一个三节点的集群。请记住，所有的连接都是冗余的，如前所述。

只有两个节点装有数据库，第三个节点是所谓的法定服务器(仲裁服务器)。

所有的节点都连接的两个网络：公共网络范围为192.168.0.x(客户也通过这个网络连接到数据库)，私有网络范围为：192.168.1.x 。

这是因为两天服务器被连接作为作为一个复制集群和一个高流量的数据库，复制流本身也会造成一个高流量。为了允许从客户端到数据库的流量最高，复制走私有网络。

高可用性软件(前面提到的带有Heartbeat或Corosync传输的Pacemaker)也需要通信。通常只使用私有网络是足够的。但是，因为它只需要很少的带宽，为了提供更多的冗余，传输层可以被设置为同时使用公共网络和私有网络。

仲裁服务器提供了决胜投票，以防两个数据库服务器之间的通信出现故障。这可由网络问题引起。在这种情况下，两个数据库服务器都活着并且每个数据库都尝试去做它需要做的事情：master节点为客户提供服务，slave复制master。脑裂情形有三个例子：

• master 服务器故障或成为独立模式

• slave 服务器故障或成为独立模式

• 仲裁服务器故障或成为独立模式

请记住，所有节点运行在高可用性集群软件的集群管理层。

在第一种情况下，其它两个节点不能与master节点进行通信。因而，会发生两件事情。slave节点和仲裁服务器代表多数，因此slave节点接管服务，它提升复制数据库为master实例并拉起虚拟IP。以前的master节点可能已经崩溃，因此它不再工作，或者它和其他两个节点之间的网络可能已经出错。如果该节点自己不工作，它需要进行维修或至少重新启动。如果它仍然工作，它知道它自己在少数中，因此，它自愿放弃服务。它停止数据库并丢弃虚拟IP。

当之前的master节点或网络连接被修好时，它启动它的高可用性软件实例，因为master 的数据库副本已经在别处运行了，它也不会启动。但是，资源可以作为slave启动，因为这是Pacemaker下master-slave资源的工作方式。但是，正确的资源代理的实施可以防止这种情况发生，因为当前的master节点(我们之前的 slave 数据库)和最初的master已经分开了，复制不能自动在这一点建立。需要从当前的master做一个新的基础备份，故障节点恢复后，复制和slave的数据库实例可以在 高可用性管理层启动。

在第二种情况下，当slave服务器出项故障或成为单机模式，这种情况是比较好的。master 数据库实例仍然工作并对客户提供服务，但是复制停止了。取决于slave节点的的停机时间的长短和master数据库的配置，slave不会自动赶上复制，或者在复制再次建立之前需要一个新的基础备份。

在第三种情况下，什么都不需要担心。只有仲裁服务器出现故障或进入独立模式。但是，master和slave节点仍然工作并可以相互通信，它们代表集群中的多数。这意味着服务不受影响，复制也在继续。

7.6.2 高可用性与STONTH

我们来看一个防护是由远程管理设备强制执行的集群。和节点数量必须是奇数的集群中的自愿防护相反，强制防护不是必须的。

在这个设置中，没有第三个节点提供打破平局的投票。如果任何一个节点出现故障或者切断网络，它会被外部强制防护。这就是所谓的STONITH设备(IPMI, iLO, DRAC,等等)所要做的。由集群进行的 STONITH 操作可以关闭节点或重新启动节点。

当其中一个节点出现故障或者离线，另外一个节点可以通过实际将其关闭并要求将它手动启动来确保它保持离线。另外一个解决办法是重新启动它以便它无服务在线，它处于一个已知的较好的节点状态。然后，它可以从这个状态适应集群中其它节点的新状态。

在这种情况下，网络冗余和高可用性的通信尤其重要。当两个节点之间的私有网络只有一条电缆和一台交换机时，考虑一下这种情况和只走私有网络的高可用性。例如，当两个节点之间的交换机出现故障，每个节点理所当然地表现为它是集群中唯一活着的节点并在其它节点上执行 STONITH 动作。这导致两个节点要么被关机要么被重新启动,这(取决于硬件)需要一段时间，会使可用性的数字受到损失。

7.7 总结

在本章，我们介绍了通用体系结构和高可用性集群软件的术语，两个开源集群栈和两种从架构的角度详细设置高可用性集群的方法。

在下一章，将讲述一个连接池软件包，pgbouncer。