SYBASE灾难备份方案
本方案主要从计算机系统的可用性出发，给出了高可用性问题的一般描述及群机方式的特色，进而提出了灾难备份的特殊考虑及SYBASE的灾难备份方案。
一、系统高可用性（High Availability）... 2
1、SYBASE建议的灾难备份方案及其主要组成部分... 5
1、SYBASE复制服务器Replication Server的基本原理... 7
2、Warm Standby Application中数据的传递方式... 7
一、系统高可用性（High Availability）
1、高可用性方案
随着计算机应用的不断深入，人们对计算机系统高可用性（High Availability）的要求越来越高，特别是企业基于数据库的关键业务系统，往往维系着企业的生命。人们不仅希望保障关键业务数据信息的完整，而且希望联机应用能够不间断或者在最短的时间内自动恢复，这就是所谓的计算机系统的可靠性、可用性问题。
|
硬件 |
|
软件 |
|
操作系统，网络软件系统，实用程序 |
|
应用软件 数据库管理系统 |
|
主机、硬盘、网络等。 |
高可用性问题是用户给整个计算机界提出的课题，这必然要求计算机系统的所有厂商包括计算机电源、硬件、操作系统、网络、数据库管理系统、应用软件等提供相应的保障措施，并且这些措施往往得综合考虑、统一配套使用。
图1 计算机系统及其高可用性
|
可靠性 |
|
费用、消耗资源 |
|
数据库系统 操作系统 硬件 |
当前可选用的措施较多：如依赖于硬件的容错机方式、广泛采用的群机方式（双机或多机cluster系统）、数据复制方式等。其层面不同、针对性有异，代价也不同，图示如下。
图2 计算机系统高可用性措施及其代价比较
目前我国用户广泛采用的是群机方式（双机或多机cluster系统），其基本配置如图3所示，其基本原理可以概括为：同一机群（cluster）内的节点机之间通过共享磁盘组联系起来，所有关键业务数据（共享数据）存储于共享磁盘组；故障节点被其它节点替换时，故障节点管辖的数据所在的数据设备（共享磁盘组的一部分）被接管；节点替换/接管的时机决定于集群内运行的监视软件；节点机上运行数据库管理系统，管理该节点机控制的设备上的数据；客户应用可以使用机群中的一个或多个数据库服务器；节点机的替换意味着节点上运行的数据库管理系统进程的切换，这些过程是在服务器后台完成的，对于前端应用是透明的。
|
TCP/IP(多网卡) |
RS232 & TCP/IP: Process Listener (Listen to each other for status) |
|
共享磁盘组（UNIX卷或原始分区） 存储关键数据：数据库 |
|
本地盘组 UNIX文件系统 |
图3 群机方式的备份方案
SYBASE的ASE数据库可以采用群机系统进行在线的、实时性的安全备份，并得到所有主流硬件/平台厂商（IBM、HP、SUN、NCR、DEC、NT、Veritas、EMC等）的支持，并且广泛应用于银行、邮电等关键业务应用系统。尤其是与Veritas 和 EMC的合作，使得ASE数据库更为高效地用于安全备份。
2、高可用性方案存在的问题
当前电信行业采用的大多为双机容错方案来实现系统的高可用性，如SYBASE的HA方式，Oracle的OPS或RAC等，它们的共同特点是两台机器共享一个磁盘阵列（共享磁盘组），当其中一台机器发生故障时，另外一台机器接管整个磁盘阵列，从而实现双机容错。具体如图4。
图4 Sybase HA系统
高可用性主要解决的是主机的容错问题，如处理器、内存、网卡等硬件故障，它对由于自然灾害所引发的容错能力较弱，具体表现在：
· 由于两台机器共享一个磁盘阵列，用户的所有数据都存储在磁盘阵列上，数据只有一份备份，一旦磁盘阵列整体发生问题，整个系统将崩溃，所有数据全部丢失。
· 由于两台机器共享一个磁盘阵列，两台主机的位置受到很大限制，一般是在同一个建筑物内，当发生火灾、地震、水灾等自然灾害时，整个系统也将崩溃，所有数据将丢失。
虽然我们定时对系统进行备份，但一般做不到实时备份，当系统崩溃后，即使可以利用备份进行恢复，也会造成数据丢失，同时在恢复期间，所用用户都不能访问数据库，对于电信行业的许多关键业务系统如计费、营账和网管系统来说，这种情况是绝对不允许发生的。
二、SYBASE建议的灾难备份方案
随着中国经济的高速发展，电信行业在国民经济中开始占有越来越重要的地位。对于电信系统，数据是一切工作的基础，因此对数据的安全性和实时性要求很高，美国911事件后，各个行业开始把数据灾难备份提到一个新的认识高度。因此，如何在管理好现有设备的同时建立一套功能完善的灾难备份系统，成为当前电信部门亟待解决的重要问题。
为了确保自然灾害（如火灾、地震）或战争等情况下的系统可靠性/高可用性，我们希望找到某种备份方案，它必须克服群机系统中对节点机物理分布的限制，允许互为备份的节点各成系统（特别是有自己的磁盘系统），地理上任意放置；同时通过某种机制在节点之间自动同步实时变化的数据；节点之间的切换过程必须简化；切换速度足够快，即系统恢复时间足够短；客户应用尽可能透明于后台/平滑切换。
这就是我们所说的灾难备份，以上条目应当成为该种方案的目标。
1、SYBASE建议的灾难备份方案及其主要组成部分
SYBASE建议的灾难备份方案如图5所示。在Sybase数据库系统中，主要包含两部分：数据库自动复制系统和客户端自动切换系统。
图5 SYBASE建议的灾难备份方案
其主要组成部分包括：
· 主点和复制点数据库服务器系统：用于为客户提供关键业务服务。二者是独立的计算机系统，物理分布无任何限制；逻辑上，二者互为备份，对客户而言是一个整体（一个数据库服务器）；一般地，将当时对外提供数据服务的节点称为主节点/活跃（Active）节点，另一节点称为备份（Standby）节点，客户连接主节点并作用于（修改）主点数据。
· 复制服务器系统：用于连接互为备份的两个数据库服务器系统，实现从主节点/活跃节点到备份节点的数据同步；在活跃节点失效时，可以方便地通知复制服务器，快速切换主、备节点（使备份节点变为活跃节点，反之活跃节点成为备份节点）。
· Sybase的OpenSwitch：客户端自动切换采用OpenSwitch，它是一个OpenServer应用网关，负责客户端和服务器端的连接管理和控制，CM(coordination Modules)是OpenSwitch的一个主要模块，负责协调和控制失败转移。
· 客户应用：连接到主节点/活跃节点，使用特别是更新主节点的业务数据。后台发生主、备节点的切换时，待切换完成后，客户应用自动重新连接到新的主节点（即由来的备份节点），继续工作。
· 网络：上述三部分之间的连接是通过网络实现的，可以是WAN或LAN。SYBASE复制服务器能有效支持WAN环境下的数据复制，所以主、备节点可任意分布于网络中。
2、数据库自动复制系统
数据库自动复制系统包括三部分：
· 主点数据库：系统正常运行时的数据库系统，在正常情况下客户端应用对数据库的修改操作必须集中在主点数据库。
· 备份点数据库：主点数据库的一个备份，可以与主点数据库在同一个地点，也可以在不同的地点，但主点数据库系统和备份点数据库系统必须通过专线网络进行连接。正常情况下，备份点数据库不能进行数据修改，但可以进行数据查询，以分担主点数据库的负载。当主点数据库系统发生故障时，所有客户端都自动连接到备份点数据库，进行正常操作，此时备份点数据库自动升级为主点数据库。
· 复制服务器系统：用于连接主点和复制点两个数据库服务器系统，实现从主节点/活跃节点到备份节点的数据实时同步；当主点的数据发生改变时，复制服务器系统通过数据库中的复制代理扫描数据库的日志，把变化的日志读取出来，通过复制服务器在复制点提交，从而保证数据的一致性。复制服务器具备断点续发功能，保证多个数据库间数据完整性与数据一致性。复制服务器采用复制命令语言(RCL)来监测和管理复制系统。
主点和复制点通过复制服务器的warm standby 技术实现两个数据库的准实时同步。当系统正常运行时，数据从主点复制到复制点。如果主点发生故障，则复制点接管主点的所有连接。当主点修复故障后，用户可以把原来的复制点作为主点、原来的主点作为复制点重新构建复制系统，新的复制系统购建成功后，用户可以保持切换后的运行状态（如果两个服务器在同一地点且硬件相同）也可以手工地切换到系统发生故障前的状态，即故障前的主点仍然为主点，所有客户端连接都连接到主点上。
1、SYBASE复制服务器Replication Server的基本原理
从上述对方案组成的叙述中可以看出，其关键产品是Sybase的复制服务器Replication Server。为了利于后续部分对方案细节的描述，有必要在此对Sybase的复制服务器Replication Server描述如下。
Sybase的复制服务器Replication Server突破了分布式数据库的限制，为真正的系统分布提供了解决方案，是业界第一个用于建立经济、可靠、高性能的分布式系统的实用产品。
· Replication Server能在整个分布式系统中保持数据的精确性，是因为它通过其敏感的日志传输代理(Log Transfer Agent)监测主节点的数据修改，由复制服务器异步地把提交的事务发送到存放数据拷贝的远程节点，并维护最新的数据拷贝。
· 对于网络出现故障的情况，Replication Server为了保障源点、目标点以及复制的正常工作，采取了先进的、智能的存储转发机制来保证系统的可用性。Replication Server拥有自己的存储转发队列，在网络故障情况下，对主点的数据的变化暂时存储在队列里，一旦网络故障恢复正常，系统会自动地将数据的变化传送到目标点服务器，保证数据的一致性。
· Replication Server不仅能够保证在网络中断情况下能正常工作，并且能够保证在网络连通后，系统能自动地从上一次发送的断点处继续发送，节省用户的网络资源，提高传送时间。这种智能的工作机制是靠Replication Server提供的复制机制中的稳定队列(Stable Query)来实现的：Replication Server首先将利用LTM将主点数据的变化存储在主点的稳定队列里，网络正常通信的情况下，准实时地将其中记录的主点变化数据传送到复制点的稳定队列中。一旦网络出现故障，LTM仍然会正常工作，监听本地数据的变化，将变化量存入本地的稳定队列，并且自动记忆网络故障前的中断点，当网络重新恢复正常后，主场点的复制服务器会与复制点的复制服务器会话，并从断点处将未传送完的变化数据传送到复制点的稳定队列中去，从而节省了网络传送时间。这种智能的机制非常适合于有大文本字段(如:text, image)系统的复制。
· Sybase的Replication Server支持各种复制工作模式：一对多、多对一、多对多，他们对应着实际工作中的从中央到地方的下发、从地方到中央的汇总、以及地方、中央的双向数据传输。Warm Standby Application是其最简单的应用方式，由于其应用的典型性，Sybase的Replication Server相应简化了这种应用的配置、操纵。
· Sybase的Replication Server还支持异种数据库之间的复制。Sybase公司的中间件互连产品是业界中最强的，通过针对各种数据库的中间件选项和复制服务器，可以在不同的数据库之间进行数据复制，满足信息系统的各种需要。
· 由各复制节点指明其所需要的数据，说明的精度可达到行级、列级，并给出相应的复制定义，则在复制节点就可得到涉及这些数据的所有更新。
· 不但支持基于事务的数据的复制，还支持存储过程/函数的复制，大大拓展了复制的能力和灵活性。这种传递机制特别适合于基于存储过程的业务系统的灾难备份，因为互备节点之间不必传递大量的数据，而是传递引起数据变化的存储过程名和参数。
2、Warm Standby Application中数据的传递方式
在明白了SYBASE复制服务器Replication Server的基本原理后，我们进一步以图示的方式说明在Warm Standby Application中数据的传递方式（注意图中步骤数字，不再分步说明）。在主、备节点发生切换后，其数据传递则反之。
图6 Warm Standby Application中数据的传递方式
3、客户端自动切换系统
为了使前台客户应用在后台服务器切换时顺利地实现重新连接甚至不改变连接，可以选择如下方法：
· 修改客户端使用的Interfaces文件。用切换后的数据库服务器的“网络地址/host-name + Port #”修正客户Interfaces文件。
· 可能时，可以改变客户应用连接的服务器名称。
· 根据SYBASE客户、服务器的识别机制，可以为同一逻辑名称的服务器指定不同的“网络地址/host-name + Port #”组合项，即映射到不同的物理服务器。
· 在客户应用程序中加入必要的程序段，控制客户应用的重新连接过程。
重新映射（Map）客户应用到数据库服务器的逻辑。比如，在客户应用与数据库服务器之间引入一个Open Server程序，一方面，它维持与前台客户应用的所有连接；另一方面，从该程序引出与后台实际数据库服务器的连接以一一对应于前台连接。后台数据库切换时，只通过程序改变它与后台的连接以及前后台连接的一一对应关系，而不改变前台连接。当然，有了这个中间程序后，还可通过程序帮助自动实现上述方案中后台前后的有关工作。此种功能的Open Server程序即为SYBASE公司的OpenSwitch产品。
客户端自动切换采用Sybase的OpenSwitch产品，它是一个OpenServer应用网关，负责客户端和服务器端的连接管理和控制。它的实现机制如图7，当客户端连接时，连接到OpenSwitch(incoming application connections),然后OpenSwitch再根据用户端的请求和数据库服务器的运行状况建立OpenSwitch的连接(outgoing connections)。
在系统的实际运行过程中，OpenSwitch把每一个客户端连接(incoming application connections)松散地捆绑到一对服务器端的连接上(outgoing connections)。在图7中即OpenSwitch到SQL SERVER A 和SQL SERVER B的连接。当正常运转时，OpenSwitch把客户端连接与OpenSwitch到SQL SERVER A的连接捆绑在一起，并对客户端的连接信息进行存储，如当前的数据库、事务状态等等。当服务器A发生故障时，OpenSwitch会自动把客户端连接与OpenSwitch到服务器B的连接捆绑到一起，并通过客户端的连接信息透明地实现客户端连接切换。
图7 OpenSwitchgong 工作原理
当主点服务器发生故障时，如果客户端正好在进行事务处理，并且事务没有结束，则OpenSwitch给客户端发送一个1205的错误信息，要求重新提交该事务，然后自动进行切换。如果客户端没有进行事务处理，则OpenSwitch进行透明的客户端连接切换。
系统的自动切换过程
在Sybase数据库的复制过程中，会存在很短的时间延迟，主要是：
· 主点的复制代理线程从日志读取日志的时间
· 日志在网络的传输时间
· 主点的操作在复制点提交时需要的时间
当主点数据库发生意外时，有可能在复制服务器中还存在没有提交的日志数据，因此必须先把这些日志数据在备份点提交，然后进行切换，允许客户端进行正常操作。OpenSwitch提供了一组API函数用于开发一个外部协调模块来解决该问题。具体如图8。
图8 自动切换过程
具体的切换过程如下：
1) 主点数据库服务器1发生故障
2) 外部协调模块接收到主点服务器发生故障的消息，所有客户端连接暂时悬挂起来。
3) 外部协调模块同复制服务器的复制代理线程进行通信，确认队列中所有的日志已经在备份点2进行了提交。
4) 外部协调模块通知OpenSwitch可以进行切换。
5) OpenSwitch切换所有客户端连接到备份点2。
三、SYBASE灾难备份方案的特点
通过采用Sybase的备份方案可以达到：
· 主点和备份点数据库系统可以位于地理位置相距很远的地方，并且系统的数据同时在主点和复制点都保存有一份，即使一份完全丢失，另一份数据也可以把系统恢复到故障前的工作状态。
· 主点的硬件系统和复制点的硬件系统不必完全一样，复制点的硬件可以比主点的硬件配置低，从而减少硬件投资费用，提高投资回报率。
· 因为Sybase复制系统复制的是数据库日志，因此对主点的数据库正常运行影响很小（5%以下）。
· 通过OpenSwitch可以实现客户端的透明切换，客户端无需重新启动。
· OpenSwitch支持连接缓冲、资源管理等功能，大大提高性能。
OpenSwitch的要求：
· 主点和复制点的数据库系统必须为Sybase数据库（版本最好一致）
· 主点和复制点的数据库名、设备名、逻辑段名必须一致
· 不支持SERVER-SIDE CURSOR
· 不支持动态SQL
· 不支持临时表
· 相对于普通的客户端/服务器结构，性能会受一定的影响。
当然，要构造一个完整的、实用的和可靠的灾备系统，需要从各个层面共同协调，统一构造，如：网络、硬件、电源、操作系统、数据库系统、应用系统和维护软件等。只有各个层面都考虑和配置了灾备方式和灾备的软硬件产品，才能称为一个容灾系统，才能建立一个完善的容灾中心。这样，才能够充分满足点新的业务需求。