您现在的位置是：首页 >其他 >PostgreSQL修炼之道之高可用性方案设计（十六）网站首页其他

20 高可用性方案设计（一）

    在一个生产系统中，通常都需要用高可用方案来保证系统的不间断运行。本章将详细介绍如何实现PostgreSQL数据库的高可用方案。

20.1 高可用架构基础

        通常数据库的高可用方案都是让多个数据库服务器协同工作，比如，当一台服务器失效时，另一台服务器可以顶替上去工作，这样就可以不中断对外服务或只中断很短的时间;或者让几台数据库同时提供服务，用户可以访问任意一台数据库，当其中一台出现问题时，访问其他数据库即可。但与为静态页面提供服务的Web服务器不一样的是，数据库中记录了数据，要想在多台数据库中切换，需要进行数据同步，所以数据同步是数据库高可用方案的基础。

20.1.1 各种高可用架构介绍

        从解决数据同步问题的方式来看，高可用方案可以分为以下几种。

• 共享磁盘的失效切换或磁盘的底层复制方案:使用共享存储，如SAN存储，一台机器失败后，把SAN存储输出的磁盘挂到另一台机器上，然后把磁盘上的文件系统挂起来后完成切换。
• WAL日志同步或流复制同步的方案:PostgreSQL自身提供了这种方案，通过这个机制，可以搭建主从数据库，当主数据库失败时，把从数据库提升为主库，继续对外提供服务。
• 基于触发器的同步方案:使用触发器记录数据变化，然后同步到另一台数据库上。
• 基于语句复制的中间件:用户不直接连接到底层数据库，而是连接到一个中间件，中间件把数据库的变更发送到底层多台数据库上，从而完成数据的同步。
•         基于改造PostgreSQL源码的方案:修改PostgreSQL源码来截取数据的变更，然后同步到另一台数据库上。

        目前随着PostgreSQL自身复制功能的增强，越来越多的技术方案开始基于PostgreSQL自身的复制方案进行设计，改造PostgreSQL源码的开源软件技术方案已越来越不活跃了，如pgcluster软件已发布的最新版本1.3还是在PostgreSQL8.0之上改造的，pgcluster-II目前还没有开源出来。所以本书不再介绍“基于改造PostgreSQL源码的高可用方案”。至于其他方案在后面都会介绍。

20.1.2 服务的可靠性设计

        主备方式的高可用方案是通过主备之间的数据同步来实现的，数据同步有异步和同步两种方式。同步方式的优点是在故障切换过程中，数据完全不丢失，但缺点也很明显，主要问题有:

• 影响性能，这是很明显的，一个事务的数据必须写到备库中才能返回。
• 当主备库之间的网络中断时，要不让同步退化为异步，要不就让主库挂起。当然还有一种方案是让一个主库带两个备库，只要有一个备库是正常的，主库就不需要挂起。这个方案的缺点是增加了成本。

        如果系统可以容忍故障切换时丢失少量的数据，可以使用数据异步同步的方式。该方案需要避免备库落后主库太多，防止故障切换时丢失太多的数据。
        要保证服务中断的时间尽量地少，还需要灵敏的故障检测。但故障检测太灵敏时，误触发的概率也会增加，所以需要选择一个合适的故障检测时间。这个故障检测时间通常在秒级别以上。想要做到秒级别以下是比较困难的。

20.1.3 数据可靠性设计

        系统中最重要的资源就是数据，如何保证数据不丢失，是数据库系统中需要重点考虑的事情。导致数据丢失的原因有很多，如硬件故障或损坏、软件Bug、.人为失误等，所以通常要备份数据,除非这个数据库不重要，丢失了也没有关系。