SQLserver高可用方案设计
SQL server高可用方案
一、高可用的类型
●Always On 高可用性解决方案，需要sql server 版本在2012以上
SQL Server Always On 即“全面的高可用性和灾难恢复解决方案”。客户通过使用Always On 技术，可以提高应用程序可用性，并且通过简化高可用性的部署和管理方面的工作。
SQL Server Always On 在以下2个级别提供了可用性。
*数据库级可用性
是一种“热备份”技术。在同步提交模式下，主副本的数据被同步更新到其他辅助副本，主副本与辅助副本之间可以保持实时同步。当系统监测到主副本发生故障时，辅助副本可以立即成为新的主副本。
*实例级可用性
Always On 故障转移群集实例（Failover Cluster Instance，简称FCI）可以在多个16个节点之间实现故障转移（Failover）。企业版最多支持16个节点，标准版只支持2个节点。
当主节点发生故障时，辅助节点提升为主节点并获取共享存储中的数据，然后才在这个新的主节点服务器中启动SQL Server 服务。
FCI 是一种“冷备份”技术。辅助节点并不从主节点同步数据，唯一的一份数据被保存在共享存储（群集共享磁盘）中。
●日志传送
日志传送依赖于传统的Windows 文件复制技术与SQL Server 代理。
主数据库所做出的任何数据变化都会被生成事务日志，这些事务日志将定期备份。然后备份文件被辅助数据库所属的实例复制到它的本地文件夹，
最后事务日志备份在辅助数据库中进行恢复，从面实现在两个数据库之间异步更新数据。
当主数据库发生故障时，可以使辅助数据库变成联机状态。可以把每一个辅助数据库都当作“冷备用”数据库
●其它辅助技术
对数据库进行备份，当出现故障时，手动将数据还原到服务器，使得数据库重新联机，这也可以算作实现高可用性的一种技术手段。
复制（Replication）并不算是一个高可用性解决方案，只是它的功能可以实现高可用性。复制通过“发布-订阅”模式，由主服务器向辅助服务器发布数据，使这些服务器间实现可用性。
SQL server复制
定义及应用：数据库间复制和分发数据和数据库对象，然后在数据库间进行
同步操作以维持一致性。使用复制，可以通过局域网和广域网、拨号连接、
无线连接和Internet 将数据分配到不同位置以及分配给远程或移动用户sql server复制分成三类：
事务复制通常用于需要高吞吐量的服务器到服务器方案（包括：提高可伸缩
性和可用性、数据仓库和报告、集成多个站点的数据、集成异类数据以及减
轻批处理的负荷）。
合并复制主要是为可能存在数据冲突的移动应用程序或分步式服务器应用
程序设计的。常见应用场景包括：与移动用户交换数据、POS（消费者销售
点）应用程序以及集成来自多个站点的数据。
快照复制用于为事务复制和合并复制提供初始数据集；在适合数据完全刷新
时也可以使用快照复制。
二、高可用的服务器配置：
如果只是需要复制方式，则搭建两台相同硬件配置和操作系统版本与补丁、
相同数据库版本和补丁的服务器即可
如果需要Always On 高可用方式，即出现故障后系统自动进行切换到备用
服务器上，则需要3台(数据库主服务器、监听服务器、从服务器)相同硬件
配置和操作系统版本与补丁、相同数据库版本和补丁的服务器
三、各种实现方式的对比
下表将SQL Server 常用的高可用性解决方案进行综合对比。
四、以上各种类型的实现方式及优缺点
4.1 日志传送
4.1.1 实现方式
https://https://www.360docs.net/doc/ba17324620.html,/zh-cn/library/ms190640(v=sql.110).aspx
1. 为主数据库创建一个事务日志备份计划
2. 为辅助数据库创建一个文件复制计划
3. 为辅助数据库创建一个事务日志还原计划
4.1.2 优劣势
优点：
可以广泛地部署。通过在多个辅助服务器上配置多个辅助数据库，可以建立多个“冷备用”数据库。
辅助数据库可以提供只读访问，作为报表等应用程序的数据源，从而将报表查询等只读访问的负载分摊到一个或多个辅助服务器。
局限：
主数据库和辅助数据库分别属于不同的实例，辅助数据库只是被动地进行事务日志恢复，不主动识别主数据库的状态，因此日志传送技术不支持自动的故障转移。
主数据库与辅助数据库之间的异步数据更新被拆分成3个独立的步骤来实现，因此会有较大的延时。
相关注意事项：
数据库备份进程和事务日志备份进程不能并发运行
截断事务日志将断开日志链，从而导致日志传送无法正常工作
4.2 Always On 方式
4.2.1 应用方式
对于通过第三方共享磁盘解决方案(SAN) 进行的数据保护，建议你使用Always On 故障转移群集实例。即实例级可用性
对于通过 SQL Server进行的数据保护，建议您使用 Always On 可用性组。即数据库级可用性在主数据库和备用副本之间传送数据。有同步提交和异步提交两种模式
4.2.1.1 同步提交方式
同步提交时，需要经过一系列的过程。
（1）主数据库在将事务日志写入文件的同时就传送给辅助数据库。然后主数据库等待辅助数据库的回应。
（2）辅助数据库收到了来自主数据库的事务，写入本地事务日志文件（固化），然后发送确认信息给主数据库。
（3）主数据库收到辅助数据库发来的确认信息，结束等待状态，继续运行。
（4）主数据库在遇到检查点时才将缓存中的“脏页”回写到数据文件；辅助数据库根据收到的事务在本地进行重做（Re-do）。
同步提交模式可以保证时刻拥有着一模一样的副本，因此具有极高的安全性。但是辅助服务器接收事务日志、写入事务日志文件和发送确认信息这一系列过程也会带来一定程度的延迟，从而影响到主数据库的性能。
由于同步提交对性能影响较大，因此SQL Server 仅允许单向的同步提交（从一个主副本单向同步到多个辅助副本）。
而且，SQL Server 严格限制了同步提交的副本数量，Always On 可用性组的一个主副本最多可以同时向2 个辅助副本实现同步提交，其他副本则使用异步提交模式。
4.2.1.2 异步提交模式
异步提交时，主数据库将事务发送给辅助数据库后，无需等待而直接继续运行。
异步提交模式消除了主数据库的等待状态，因此这种提交模式对性能几乎没有影响。但是辅助数据库可能遇到更新数据失败的情况（例如，因网络故障导致未接受主数据库的事务，或写入本地事务日志日志文件时遇到错误），而此时主数据库如果发生故障则可能造成数据丢失。
SQL Server 2014 最多允许Always On 可用性组拥有8 个辅助副本，其中同步提交的副本数量不能超过2个。
4.2.1.3 Always On 可用性组，--数据库级可用性
https://https://www.360docs.net/doc/ba17324620.html,/zh-cn/sql/database-engine/ava
ilability-groups/windows/availability-modes-always-on-ava
ilability-groups
Always On 可用性组是 SQL Server 2012 中引入的企业级高可用性和灾难恢复解决方案，可使一个或多个用户数据库的可用性达到最高。
Always On 可用性组要求 SQL Server 实例驻留在Windows Server 故障转移群集(WSFC) 节点上。
“可用性组”（Availability Group，简称AG）针对一组离散的用户数据库（称为“可用性数据库”，它们共同实现故障转移）支持故障转移环境。一个可用性组支持一组主数据库以及多组对应的辅助数据库。
每组可用性数据库都由一个“可用性副本”承载。有以下两种类型的可用性副本：
（1）一个“主副本”
主副本用于承载主数据库。主副本使一组主数据库可用于客户端的读写连接。
（2）多个“辅助副本”
辅助副本承载一组辅助数据库并作为可用性组的潜在故障转移目标。主副本将每个主数据库的事务日志记录发送到每个辅助数据库。每个辅助副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。
可以配置一个或多个辅助副本以支持对辅助数据库进行只读访问，并且可以将任何辅助副本配置为允许对辅助数据库进行备份。
可用性组的优势
可用性组具有以下优势：
（1）与FCI 相比，可用性组不依赖于共享存储。
（2）辅助副本数量最多可达到8个（SQL Server 2012 限制为4个）。
（3）辅助副本可以直接提供只读访问。
（4）“数据同步”延迟时间已经极大地缩短，甚至可以“同步提交”。而且可用性组的辅助副本在还原事务日志时不需要断开客户端的已有连接(需要确定目前使用的JDBC驱动是否支持SQL SERVER 2014以上的版本)。
（5）提供VNN 和虚拟IP 地址，供客户端透明访问。
可用性组的不足
可用性组具有以下不足：
（1）在部署可用性组的过程中，集中了日志传送、数据库镜像和FCI 的大部分功能与属性，增加了部署的复杂程度。
（2）Always On 可用性组与数据库镜像都不支持跨数据库事务和分布式事务。这是因为无法保证事务的原子性和完整性，可能出现逻辑上的不一致。
4.2.1.4 Always On 故障转移群集实例
https://https://www.360docs.net/doc/ba17324620.html,/zh-cn/sql/sql-server/failover-clusters/windows/windo ws-server-failover-clustering-wsfc-with-sql-server
Windows Server 故障转移群集（Windows Server Failover Cluster，简称WSFC）由一组物理服务器（节点）构成，这些服务器包含类似的硬件配置以及相同的软件配置
WSFC 服务可以监视由其托管的角色（Windows Server 2012 以前称为“服务和应用程序”）的运行状况，并根据预设的条件进行故障转移处理。
SQL Server 安装在Always On 故障转移群集实例（Failover Cluster Instance，简称FCI）的每个节点上。但是，在启动过程中，SQL Server 服务不会自动启动，而是交由WSFC 托管。
Always On FCI 简介
对于数据库和日志存储，FCI 必须在FCI 的所有节点之间使用共享存储。共享存储的形式可以为WSFC 群集磁盘、SAN 上的磁盘或SMB 上的文件共享。这样一来，当发生故障转移时，FCI 中的所有节点都会具有相同的实例数据视图。
FCI 使用一个虚拟网络名称（Virtual Network Name，简称VNN）和虚拟IP 地址，应用程序和客户端可使用同一VNN（或虚拟IP 地址）连接到FCI。当发生故障转移时，VNN 会在新的活动节点启动后注册到该节点。此过程对于连接到SQL Server 的客户端或应用程序是透明的，可以最大限度地缩短出现故障时应用程序或客户端的停机时间。
FCI 作为WSFC 的一个“角色”，在一个资源组中运行。群集中一次只有一个节点（活动节点）拥有该资源组。此节点拥有有资源包括：虚拟网络名称、虚拟IP 地址、共享存储、SQL Server 数据库引擎服务、SQL Server 代理服务、SSAS（如果已安装）、一个文件共享资源（如果安装了FILESTREAM 功能。
当活动节点出现故障（硬件故障、操作系统故障、应用程序或服务故障）或进行计划的升级时，将按照以下顺序进行故障转移过程。
（1）将缓冲区的所有“脏页”写入磁盘。
（2）停止FCI 活动节点上的所有SQL Server 相应服务。
（3）资源组的所有权转移到FCI 的另一个节点，使其成为新的活动节点。
（4）新的活动节点启动SQL Server 相应服务。
（5）客户端应用程序的连接请求将自动定向到VNN 的新的活动节点。
Always On FCI 的优势
FCI 具有以下优势：
（1）自动故障转移FCI 通过冗余在实例级提供保护。
（2）客户端透明连接
应用程序连接到VNN（或虚拟IP 地址），而无需知道当前活动节点。当发生故障转移时，VNN 会会自动切换到新的活动节点。在故障转移过程中，无需重新配置应用程序和客户端。
Always On FCI 的不足
FCI 具有以下不足：
（1）单一故障点
FCI 必须在所有的节点之间使用共享存储，这意味着共享存储有可能成为单个故障点。因此FCI 依赖于共享存储拥有的硬件解决方案来确保数据保护，但这种解决方案往往需要较高的成本。（2）资源利用率
任何时候FCI 只有1个节点（活动节点）运行SQL Server 服务，其他节点则处于“冷备用”状态，资源利用率较不高。
4.3复制应用
https://https://www.360docs.net/doc/ba17324620.html,/zh-cn/sql/relational-databas es/replication/types-of-replication
4.3.1快照复制
特定时刻的状态分发数据，而不监视数据是否更新。发生同步时，将生成完整的快照并将其发送到订阅服务器。
当符合以下一个或多个条件时，使用快照复制本身是最合适的：
?很少更改数据。
?在一段时间内允许具有相对发布服务器已过时的数据副本。
?复制少量数据。
?在短期内出现大量更改。
在数据更改量很大，但很少发生更改时，快照复制是最合适的。例如，如果某销售组织维护一个产品价格列表且这些价格每年要在固定时间进行一两次完全更新，那么建议在数据更改后复制完整的数据快照。对于给定的某些类型的数据，更频繁的快照可能也比较适合。例如，如果一天中在发布服务器上更新相对小的表，但可以接受一定的滞后时间，则可以在夜间以快照形式传递更改。
发布服务器上快照复制的连续开销低于事务复制的开销，因为不用跟踪增量更改。但是，如果要复制的数据集非常大，那么若要生成和应用快照，将需要使用大量资源。评估是否使用快照复制时，需要考虑整个数据集的大小以及数据的更改频率。
与备份的区别
先来看快照.
快照,其本质类似于数据库的照片,也就是在某个特定时间点(创建快照的时间点)给数据库拍个照放在那儿.但是这个照片是一个新的数据库,可以应用SQL语句.
快照数据库里的数据是不变的.创建快照后,系统会对原数据库的所有数据页做个标识,如果数据页在创建快照后被修改,会复制一个数据页出来,没有修改的数据页则不会有快照(原数据库和快照数据库共用该数据页).
从这样来看,快照存在的时间越长,对系统的压力会越大(要维护的变化数据页太多).
一般来说,快照用在数据库的镜像机上,因为镜像机上的数据库永远是Restoring状态,可以在某个特定的时间点生成一个快照,这样就可以在镜像机上提供一个可访问的数据库,用来为数据仓库提供数据源比较合适.
再来看备份.
备份,其本质是一个副本.相当于在某个时间点把数据库里的所有对象内容都COPY一份,放到一个特定的文件里(备份文件,一般是.bak).
这个文件不是一个数据库,不能直接应用SQL,必须先通过还原的方式还原到一个数据库(可以是和原数据库名称一致,也可以是一个新的数据库),之后才能访问里面的数据.
因为备份的结果是文件,这个文件可以被COPY走,或者写入磁带(放到银行里),从而实现离线容灾.
4.3.2事物复制
事务复制通常从发布数据库对象和数据的快照开始。创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。数据更改将按照
其在发布服务器上发生的顺序和事务边界应用于订阅服务器，因此，在发布内部可以保证事务的一致性。
事务复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务复制：
?希望发生增量更改时将其传播到订阅服务器。
?从发布服务器上发生更改，至更改到达订阅服务器，
应用程序需要这两者之间的滞后时间较短。
?应用程序需要访问中间数据状态。例如，如果某一行
更改了五次，事务复制将允许应用程序响应每次更改
（例如，激发触发器），而不只是响应该行最终的数
据更改。
?发布服务器有大量的插入、更新和删除活动。
?发布服务器或订阅服务器不是SQL Server 数据库
（例如，Oracle）。
默认情况下，事务发布的订阅服务器应视为只读，因为更改不会传播回发布服务器。但是，事务复制确实提供了允许在订阅服务器上进行更新的选项。
要求：
数据库的恢复方式不能是简单模式，并且不能截断数据库日志，数据库表必须都得有主键索引
4.3.3 合并复制
合并复制通常用于服务器到客户端的环境中。合并复制适用于下列各种情况：
?多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器。
?订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
?每个订阅服务器都需要不同的数据分区。
?可能会发生冲突，并且在冲突发生时，您需要具有检测和解决冲突的能力。
?应用程序需要最终的数据更改结果，而不是访问中间数据状态。例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（也就是第五次更改的值）。
合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。由于更新是在多个节点上进行的，同一数据可能由发布服务器和多个订阅服务器进行了更新。因此，在合并更新时可能会产生冲突，合并复制提供了多种处理冲突的方法。
合并复制是由 SQL Server 快照代理和合并代理实现的。如果发布未经筛选或使用静态筛选器，快照代理将创建单个快照。如果发布使用参数化筛选器，则快照代理将为每个数据分区创建一个快照。合并代理将初始快照应用于订阅服务器。它还将合并自初始快照创建后发布服务器或订阅服务器上所发生的增量数据更改，并根据所配置的规则检测和解决任何冲突。
复制总结：
1、初始设置比较复杂，需要进行多次模拟才能最终成功，并且无论哪种复制形式都是异步复
制，中间会有延迟的损失；
2、由于复制等业务会影响I/O性能，比较合理的方式是使用SSD硬盘，PCI-E卡最佳，同时
要避免发布与订阅之间的网络延迟，SQL Server默认事务隔离级别要设置成
READ_COMMITTED_SNAPSHOT；
3、发布服务器出现问题瘫痪，需要人工进行调整一段时间；
4、在发布服务器要注意数据库的日志文件的容量和增长速度，数据库日志文件超大之后会影
响系统的正常运行，影响硬盘空间的利用；
5、
Oracle数据库高可用解决方案
甲骨文最高可用性架构 骨 最高 用性架构 Maximum Availability Architecture
议程表
? ? ? ? ? 甲骨文简介 高可用性介绍 传 高 用性分析 传统高可用性分析 甲骨文高可用性方案介绍(MAA) 客户成功案例分享
2
Oracle公司概揽
总揽
? ? ? ? ? ? 从08财年收入$22.4B，11财年收入35.6B 在40多项产品或市场领域占据业界第一 320,000客户跨越145国家 10W员工规模 (1 in i 3 joined j i df from acquisition) i iti ) Oracle在线社区上有超过五百万开发者 34年从业经验
革新和创新
? 超过3,000 3 000个产品，拥有 个产品 拥有2,000 2 000多个专利 ? 09财年投入$3B 研发和测试资金 ? 7,500 售后支持人员, 支持27国语言
3
今天的甲骨文公司
? 全球最大的企业软件供应商 ? 数据库市场占有率第一 ? 中间件市场占有率第一 ? 应用软件市场占有率第一 ? 服务器市场占有率第三 ? 开源产品的领军者 ? 虚拟化产品的竞争者 ? 云计算方案供应商
FAST?=?FusionMiddleware Applications System Tech
4
议程表
? ? ? ? ? 甲骨文简介 高可用性介绍 传 高 用性分析 传统高可用性分析 甲骨文高可用性方案介绍(MAA) 客户成功案例分享
5
技术方案-应用高可用解决方案(两地三中心)
英方软件数据库系统高可用解决方案 英方软件（上海）有限公司
目录 1. 概述 (1) 2. 需求分析 (2) 3.1主机配置 (3) 3.2方案拓扑图： (3) 3.3 I2高可用方案功能介绍 (4) 3.4管理控制台 (7) 5. I2的主要优势 (10) 6. 典型案例 (12) 7.公司简介 (13)
1. 概述 现代大型企业大多拥有为数众多的服务器，提供Internet与Intranet使用者各种不同的服务。如数据库系统、影像系统、录音系统、Email系统等。保持业务的持续性是当今企业用户进行数据存储需要考虑的一个重要方面。系统故障的出现，可能导致生产停顿，客户满意度降低，甚至失去客户，企业的竞争力也大打折扣。因此，保持业务的持续性是用户在选择计算机系统的重要指标。究其根本，保护业务持续性的重要手段就是提高计算机系统的高可靠性同时将数据的损失降至最低限度。 关键数据和数据库的备份操作已经成为日常运行处理的一个组成部分，以确保出现问题时及时恢复重要数据。传统的解决方案,类似于磁带机备份存在较大的缺点. 通常数据采用磁带离线备份，当数据量较大或突发灾难发生时，备份磁带无法真正及时快速恢复数据及业务。 提供有效的数据保护和高可用性服务,又在合理预算范围之内,并且能够基于你现有环境当中,获得实时数据保护,并无距离限制,为确保你重要数据的保护----包含数据库和邮件系统。I2为您提供了完美的解决方案。 I2 采用先进的异步实时数据复制技术(Asychronous Real-Time Data Replication)，立即将所有服务器上对于磁盘系统的变更透过网络传输至备援服务器，而非整个档案或磁盘的镜设(Mirror)，因此对于服务器的效能与网络带宽的影响都能降至最低，并能将成本降至最低，做到真正的实时数据保护. 业务数据是用户最宝贵的资产之一，数据的损失就是企业资产利润的损失，所以保护业务数据是企业计算系统的主要功能之一。实施I2的备份方案可以将用户数据的损失降至最低甚至为零。
SQL server高可用方案
SQL server高可用方案 一、高可用的类型 ●AlwaysOn 高可用性解决方案，需要sql server 版本在2012以上 SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”。客户通过使用AlwaysOn 技术，可以提高应用管理方面的工作。 SQL Server AlwaysOn 在以下2个级别提供了可用性。 *数据库级可用性 是一种“热备份”技术。在同步提交模式下，主副本的数据被同步更新到其他辅助副本，主副本与辅助副本之间可以时，辅助副本可以立即成为新的主副本。 *实例级可用性 AlwaysOn 故障转移群集实例（Failover Cluster Instance，简称FCI）可以在多个16个节点之间实现故障转移（版只支持2个节点。 当主节点发生故障时，辅助节点提升为主节点并获取共享存储中的数据，然后才在这个新的主节点服务器中启动FCI 是一种“冷备份”技术。辅助节点并不从主节点同步数据，唯一的一份数据被保存在共享存储（群集共享磁盘）●日志传送 日志传送依赖于传统的Windows 文件复制技术与SQL Server 代理。 主数据库所做出的任何数据变化都会被生成事务日志，这些事务日志将定期备份。然后备份文件被辅助数据库所属最后事务日志备份在辅助数据库中进行恢复，从面实现在两个数据库之间异步更新数据。 当主数据库发生故障时，可以使辅助数据库变成联机状态。可以把每一个辅助数据库都当作“冷备用”数据库
●其它辅助技术 对数据库进行备份，当出现故障时，手动将数据还原到服务器，使得数据库重新联机，这也可以算作实现高可用性复制（Replication）并不算是一个高可用性解决方案，只是它的功能可以实现高可用性。复制通过“发布-订阅”模式服务器间实现可用性。 SQL server复制 定义及应用：数据库间复制和分发数据和数据库对象，然后在数据库间进 过局域网和广域网、拨号连接、无线连接和Internet 将数据分配到不同位sql server复制分成三类： 事务复制通常用于需要高吞吐量的服务器到服务器方案（包括：提高可伸 点的数据、集成异类数据以及减轻批处理的负荷）。 合并复制主要是为可能存在数据冲突的移动应用程序或分步式服务器应用 交换数据、POS（消费者销售点）应用程序以及集成来自多个站点的数据 快照复制用于为事务复制和合并复制提供初始数据集；在适合数据完全刷二、高可用的服务器配置： 如果只是需要复制方式，则搭建两台相同硬件配置和操作系统版本与补丁 如果需要AlwaysOn 高可用方式，即出现故障后系统自动进行切换到备用 服务器、从服务器)相同硬件配置和操作系统版本与补丁、相同数据库版本三、各种实现方式的对比 下表将SQL Server 常用的高可用性解决方案进行综合对比。
数据库负载均衡解决方案
双节点数据库负载均衡解决方案 问题的提出？ 在SQL Server数据库平台上，企业的数据库系统存在的形式主要有单机模式和集群模式（为了保证数据库的可用性或实现备份）如：失败转移集群（MSCS）、镜像（Mirror）、第三方的高可用（HA）集群或备份软件等。伴随着企业的发展，企业的数据量和访问量也会迅猛增加，此时数据库就会面临很大的负载和压力，意味着数据库会成为整个信息系统的瓶颈。这些“集群”技术能解决这类问题吗？SQL Server数据库上传统的集群技术 Microsoft Cluster Server(MSCS) 相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术，属于高可用集群，Microsoft称之为失败转移集群。 MSCS 从硬件连接上看，很像Oracle的RAC，两个节点，通过网络连接，共享磁盘；事实上SQL Server 数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份； 因为始终只有一个节点在运行，在性能上也得不到提升,系统也就不具备扩展的能力。当现有的服务器不能满足应用的负载时只能更换更高配置的服务器。 Mirror 镜像是SQL Server 2005中的一个主要特点，目的是为了提高可用性，和MSCS相比，用户实现数据库的高可用更容易了，不需要共享磁盘柜，也不受地域的限制。共设了三个服务器，第一是工作数据库（Principal Datebase），第二个是镜像数据库（Mirror），第三个是监视服务器（Witness Server，在可用性方面有了一些保证，但仍然是单服务器工作；在扩展和性能的提升上依旧没有什么帮助。
MSSQL数据库高可用性方案
高可用MS SQL Server数据库解决方案 建设目标 减少硬件或软件故障造成的影响，保持业务连续性，从而将用户可以察觉到的停机时间减至最小，确保数据库服务7*24小时（RTO为99.9%）运转，建设一套完整的高可用性MS SQL Server数据库系统。 需求分析 服务器宕机造成的影响 服务器宕机时间使得丢失客户收益并降低员工生产效率，为了避免对业务造成影响，从两个方面采取预防措施： 一、计划宕机时的可用性： ●补丁或补丁包安装 ●软硬件升级 ●更改系统配置 ●数据库维护 ●应用程序升级 二、防止非计划性宕机： ●人为错误导致的失败 ●站点灾难 ●硬件故障
●数据损毁 ●软件故障 现有状况 ●服务器存在单点故障； ●数据库未做高可用性配置； ●数据库版本为MS SQL Server2008； ●服务器配置为CPU E7540 2.0，24G存； ●数据库容量约800G 技术解决方案 解决思路 考虑到本项目的需求和最佳性能，为了达到最佳可用性，方案采用两台数据库服务器做故障转移集群，连接同一台存储做数据库的共享存储，实现故障自动转移。同时，将旧服务器作为镜像数据库，采用SQL Server 2012的alwayson 功能来再次完成自动故障转移，并可以分担查询的负载。
架构拓扑 新数据库：承担数据库主体计算功能，用于生产数据，采用双机集群，实现自动故障转移。 旧数据库：通过镜像功能，存储数据库副本，用于发生故障时的转移。也可配置为只读，承担备份的负载。 存储：存储采用双控制器，双FC连接两台服务器，避免单点故障。 主/辅域控制器：采用双机模式，SQL Server 2012 实现高可用的必备基础设施。 高可靠性技术方案 SQL Server的企业版支持所有的高可用性功能，这些功能包括：
MYSQL数据库高可用性方案
撰写人：陈明2010-7-25
目录 I综述 (2) II实现目标 (2) III方案建设概要 (2) III.1现有高可用方案分析 (2) III.2Mysql+replication (2) III.2.1概述 (2) III.2.2Mysql replication方案拓扑图 (3) III.2.3Mysql+replication优缺点 (4) III.3mysql+heartbeat+共享存储 (4) III.3.1概述 (4) III.3.2Mysql+heartbeat+共享存储方案拓扑图 (5) III.3.3Mysql+heartbeat+共享存储优缺点 (6) III.4Mysql+drbd+heartbeat (6) III.4.1概述 (6) III.4.2Mysql+drbd+heartbeat方案拓扑图 (7) III.4.3Mysql+drbd+heartbeat优缺点 (7) III.5Mysql cluster (8) III.5.1概述 (8) III.5.2Mysql cluster方案拓扑图 (8) III.5.3Mysql cluster优缺点 (9) IV可行性方案选择 (9) V Mysql+heartbeat+共享存储方案具体实施步骤 (9)
I综述 数据库位于现代企业应用的核心，它储存了组织机构中最有价值的资产，包括客户信息、产品信息、订单信息和历史数据。另外，组织机构依赖于数据库来运行他们关键业务应用。几小时甚至是几分钟的宕机，往往会造成收入的大量流失和客户的不满。因此，保证数据库高可用是所有组织机构优先考虑的事情。对于希望在当今瞬息万变的经济环境立于不败之地并取得成功的企业来说，构建一个具有高可用性的IT基础架构至关重要。 II实现目标 通过技术手段实现mysql数据库的高可用性，从而减少停工时间保证服务的正常稳定运行。 III方案建设概要 III.1现有高可用方案分析 Mysql作为一款开源软件经过多年的发展，已经形成很多套实现高可用方案，并且均都投入生产使用，主要为这几种：mysql+replication、mysql+heartbeat+共享存储、mysql+drbd+ heartbeat、mysql cluster。以下将依次对各个方案进行分析。 III.2Mysql+replication III.2.1概述 Mysql的复制（Replication）是一个异步的复制，从一个Mysql instace（称之为Master）复制到另一个Mysql instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在Master（IO进程）上。
Oracle 三种高可用方案原理介绍--解决方案
Oracle 三种高可用方案原理介绍 一、概述 Oracle因为是商用版本，所以高可用方案都已经非常成熟，主要有三种高可用方案，下边分别介绍一下。 1 RAC（Real Application Clusters） 多个Oracle服务器组成一个共享的Cache，而这些oracle服务器共享一个基于网络的存储。这个系统可以容忍单机/或是多机失败。不过系统内部的多个节点需要高速网络互连，基本上也就是要全部东西放在在一个机房内，或者说一个数据中心内。如果机房出故障，比如网络不通，那就坏了。所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要，重要业务需要多机房来容忍单个机房的事故。 2 Data Guard.（最主要的功能是冗灾）
Data Guard这个方案就适合多机房的。某机房一个production的数据库，另外其他机房部署standby的数据库。Standby数据库分物理的和逻辑的。物理的standby数据库主要用于production失败后做切换。而逻辑的standby数据库则在平时可以分担production数据库的读负载。 3 MAA MAA(Maximum Availability Architecture)其实不是独立的第三种，而是前面两种的结合，来提供最高的可用性。每个机房内部署RAC集群，多个机房间用Data Guard同步。 二、三种高可用方式工作原理 1、Oracle 11G RAC RAC环境与单实例最主要的区别是: . RAC的每个实例都有属于自己的SGA、后台进程。
. 由于数据文件、控制文件共享于所有实例，所以必须放在共享存储中。 . . 联机重做日志文件：只有一个实例可以写入，但是其他实例可以再回复和存档期间读取。 . . 归档日志：属于该实例，但在介质恢复期间，其他实例需要访问所需的归档日志。 . . alter和trace日志：属于每个实例自己，其他实例不可读写。 . RAC的主要组件包括： ? 共享磁盘系统 ? Oracle集群件 ? 集群互联 ? Oracle内核组件 oracle集群件： Oracle集群件能使节点能够互相通信，构成集群，从而这些节点能够像单个逻辑服务器那样整体运行。构成Oracle集群件的后台进程和服务是crsd、ocssd、oprocd、evmd和ons。Oracle集群件由CRS服务使用OCR和votingdisk进行管理。 OCR记录和维持集群及节点的成员资格信息，而votingdisk在通信故障时充当一个仲裁者。在集群运行期间，来自所有节点的一致性心跳信息都会发送给votingdisk。 CRS的组件包括，在Linux系统可以通过ps -ef来查看以下进程：
数据库安全、高可用性
保障数据安全防篡改 为了保证数据安全，落实到软件，最重要的就是权限控制、审计追踪和数据版本可追溯。那么，针对这三点，计算机化系统附录都做了哪些规定呢？ 访问控制和权限分配： 第十四条只有经许可的人员才能进入和使用系统。企业应当采取适当的方式杜绝未经许可的人员进入和使用系统。 也就是说需要访问控制，为不同级别的用户设置不同权限，没有权限不能进入和使用系统。第十六条计算机化系统应当记录输入或确认关键数据人员的身份。只有经授权人员，方可修改已输入的数据。每次修改已输入的关键数据均应当经过批准，并应当记录更改数据的理由。 也就是说，没有相应的权限，用户将无法修改数据的，而且更改数据时还要注明更改的理由，不能留空。 这两条强调了数据输入的准确性和数据修改等处理过程的正确性和合理性，以保证数据的合规性。 审计追踪（基于风险评估）： 第十六条应当根据风险评估的结果，考虑在计算机化系统中建立数据审计跟踪系统，用于记录数据的输入和修改以及系统的使用和变更。
这里的审计跟踪功能适用于数据的访问、录入、修改和删除等操作，所有和数据有关的活动都需要有记录，并且不可被编辑或者删除。 电子签名 第十八条对于电子数据和纸质打印文稿同时存在的情况，应当有文件明确规定以电子数据为主数据还是以纸质打印文稿为主数据。 这里的电子签名，是可以有，而不是必须。 所谓电子数据签名就是不打印这份报告，直接在软件里点击签名，也表示了对这个报告的认可。使用电子数据签名，应当写一个书面的文档，规定实验室里电子签名的效力。 第十九条以电子数据为主数据时，应当满足以下要求： 为满足质量审计的目的，存储的电子数据应当能够打印成清晰易懂的文件。 比如说PDF文件。对数据的每一次修改都可以存储和打印为的结果版本，以避免非授权的修改，造成审计时，数据结果不能重现。 这里就涉及到数据版本可追溯，也就是说你的每个版本的数据都需要存储，不能被覆盖以及删除。 强调计算机系统的逻辑和物理安全性： 第十九条（二）日常运行维护和系统发生变更（如计算机设备或其程序）时，应当检查所存储数据的可访问性及数据完整性。
高可用数据库架构设计
MySQL数据库高可用架构设计 目标： MySQL 数据库服务器不受单点宕机的影响，即时A 服务器挂掉或者磁盘损坏物理故障导致数据库不可用也不会导致整个系统处于不可用状态，因为还有另外一台备用的数据库服务器可以提供服务。派宝箱采取方案双机主从热备(Mater Slave 模式) 背景： 双机热备的概念简单说一下，就是要保持两个数据库的状态自动同步。对任何一个数据库的操作都自动应用到另外一个数据库，始终保持两个数据库数据一致。这样做的好处: 1. 可以做灾备，其中一个坏了可以切换到另一个。 2. 可以做负载均衡，可以将请求分摊到其中任何一台上，提高网站吞吐量。对于异地热备，尤其适合灾备。 原理： MySQL Replication双机热备+ 每天自动sqldump出物理文件备份 双机主从自动热备实现数据库服务的高可用加sqldump导出数据文件的方式备份。双重保险！
可能遇到的问题与挑战： 主从数据库数据一致性问题 宕机后主从切换的问题 1 复制概述 Mysql内建的复制功能(MySQL REPLICATION)是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。 1.1 mysql支持的复制类型：
SQL Server 2012 AlwaysOn高可用性解决方案
Microsoft SQL Server 2012 AlwaysOn 高可用性解决方案
1.术语定义 1)高可用性：HA（High Availability） 通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性 2)灾难恢复：DR（Disaster Recovery） 指自然或人为灾害后，重新启用信息系统的数据、硬件及软件设备，恢复正常商业运作的过程 3)故障转移群集：WSFC（Windows Server Failover Cluster） 微软操作系统针对服务器提供的一种服务，该服务用于防止单台服务器故障导致服务失效。 2.公司数据库使用现状及问题瓶颈 其他部门对应用开发部负责的融资管理系统性能提出以下问题： 1)数据部： a)服务器不稳定 b)数据库性能配置低 2)市场部： a)查询效率太低 3)产品部： a)报表、BI支撑难 这些性能问题无不涉及到后台数据库的性能及可靠性问题。 还有一个安全问题也值得重视。目前，公司产品数据库和融资管系统都部署在10.44.1.3一台服务器上。理论上，产品数据库不应与Web应用部署在同一台机器而暴露给用户，产品数据库最好只交由专职DBA 来管理。因为，万一Web应用遭受黑客攻击，产品数据将会面临巨大威胁，甚至有可能被永久性物理删除。 前不久，就有报道携程数据遭受有预谋的内部攻击被物理删除
（https://www.360docs.net/doc/ba17324620.html,/20150528/n413987338.shtml）。如果分开部署，那么即使Web应用遭受攻击，只要产品数据在，我们仍然可以在短时间内部署新的Web应用。 3.SQL Server 高可用技术简介 1)故障转移群集(Failover Cluster) 共享存储，效率高，但某一个时间点只有一个节点处于活动状态，造成硬件资源浪费。 2)数据库镜像(Database Mirror) 提供几乎是瞬时的故障转移，以提高数据库的可用性。但其最大弊端在于镜像数据库处于不可读状态，同样造成硬件资源浪费。 3)日志传送(Log Shipping) 还原作业之间的间隔时间内的只读访问权限，可用做报表查询。一般用于远程的异步容灾，存在部分数据丢失的可能性。 4)复制(Replication) 基于数据库对象级别，灵活性较高，但弊端在于，它不支持DDL命令，不便维护。 5)AlwaysOn AlwaysOn是SQL Server 2012中提供的一种全新的高可用性技术，其集中了上述4种高可用性技术的优点，以确保企业无需增加成本和提高复杂度，即可实现最高级别的可用性和数据保护。可在数据中心内部以及跨数据中心实现数据冗余，快速地实现应用程序故障转移，保护现有硬件资源，同时简化了其配置过程。AlwaysOn可以实现服务器实例级和数据库级配置高可用性，所对应的技术就是AlwaysOn故障转移群集实例和AlwaysOn可用性组。 下图1展示了使用Alwayson可用性组的HA 和DR 解决方案
数据库HA解决方案
HA解决方案
●项目背景及需求分析 企业的核心业务系统，一旦出现中断，势必极大影响企业的正常运转，造成巨大的损失。在实际的应用过程中，非法操作、硬件故障、软件错误、人为因素、自然灾害等灾难事故都对这套业务信息系统的持续运行构成潜在威胁。 用户充分考虑到了信息系统业务容灾的必要性，对其企业内部业务系统提出了业务高可用性的需求。做到有备无患，防范于未然。 用户准备了两台备用服务器，希望实现当生产服务器在运行时产生的数据能够实时的传送到备用服务器上，且在生产服务器遭遇故障，业务信息系统无法继续正常运行时能够自动切换到备用服务器上。保证对外服务的连续性，达到7X24的高可用级别。 ●解决方案 通过对客户需求的详细分析，经过细致的产品对比、慎重的方案筛选以及客户现有资源等因素的综合考虑，Rose公司推荐其采用基于数据镜像的业务连续性旗舰产品——RoseMirrorHA，为客户应用系统（WEB应用+后台数据库Oracle）提供了具有无单点故障容错能力的系统平台。 1. 总体架构描述 在客户应用系统的主备4台服务器上，分别安装RoseMirrorHA。两两搭建基于数据镜像的双机高可用系统，无需客户更改现有系统的任何环节。 2. 具体实现过程 一台服务器作为用户业务系统的前台应用主机，一台服务器作为用户业务系统的后台数据库主机，另两台服务器分别作为应用和数据库的备机。客户端通过活动IP或主机别名访问应用服务。RoseMirrorHA高可用性系统，可以对主机的IP、应用程序、数据等进行监控和保护，当应用程序或主机发生故障后，RoseMirrorHA将自动、快速的切换活动IP和应用资源到备机，保证应用系统的持续运营。当资源在备机启动以后，客户端重连就能访问到应用。 原主机恢复后，接管了应用的备机将把变化后的数据进行同步，保障主备机的应用数据保持完全一致。
MySQL数据库高可用性方案
MySQL数据库高可用性方案 一、综述 数据库位于现代企业应用的核心，它储存了组织机构中最有价值的资产，包括客户信息、产品信息、订单信息和历史数据。另外，组织机构依赖于数据库来运行他们关键业务应用。几小时甚至是几分钟的宕机，往往会造成收入的大量流失和客户的不满。因此，保证数据库高可用是所有组织机构优先考虑的事情。对于希望在当今瞬息万变的经济环境立于不败之地并取得成功的企业来说，构建一个具有高可用性的IT 基础架构至关重要。 二、完成目标通过技术手段实现mysql数据库的高可用性，从而减少停工时间保证服务的正常稳定运行。 三、方案建设概要 1、现有高可用方案分析 Mysql作为一款开源软件经过多年的发展，已经形成很多套实现高可用方案，并且均都投入生产使用，主要为这几种：mysql + replication 、mysql + heartbeat + 存储、mysql + drbd + heartbeat 、mysql cluster。以下将依次对各个方案进行分析。 2、Mysql+replication2.1 概述 Mysql的复制（Replication）是一个异步的复制，从一个Mysql
instace（称之为Master）复制到另一个Mysql instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在Master（IO进程）上。 2.2 Mysqlreplication方案拓扑图 Mysql+replication主从复制拓扑图 方案具体解释： 要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave 从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。 2.3 Mysql+replication优缺点优点：易实施、成本低、经济实惠、后期维护方便，且由于整套系统架构简单，不涉及到存储及双机软件，因此系统出现故障率很低。方便做到读写分离。 缺点：在主机出现问题后不能自动切换到备份机，需要人工干涉更改IP地址。
多种数据库高可用性解决方案对比分析
在SQLServer2008数据库中，本身就带有不少的高可用性解决方案。如可以采用故障转移群集、数据库镜像、日志传送或者复制等手段来提高数据库的高可用性。由于解决方案多了，数据库管理员不得不掌握各个解决方案的优点与缺陷，然后根据企业的实际应用来选择合适的解决方案。其实，这不仅仅是在考验解决方案的优劣性，也是在考验数据库管理员的能力。 一、数据库镜像的优劣分析 数据库镜像是一个软件解决方案，可以提供几乎是瞬时的故障转移，以提高数据库的可用性。简单的说，数据库镜像解决方案就是设置多个数据库，在多个数据库之间进行数据多同步。不同在同一个时间内，只有一个生产数据库(或者叫做主体数据库)，而其他数据库都是备用数据库(又叫做镜像数据库)。当主体数据库出现故障时，系统会自动切换到镜像数据库上。此时这个镜像数据库就变为了主体数据库。由于主体数据库与镜像数据库之间数据进行了实时的同步，所以对于用户访问来说，基本不受影响。 镜像服务器解决方案最大的优点就是可以提供几乎是瞬时的故障转移。不过所采用的数据库镜像的方案不同，对于这个“瞬时”的影响也是不同的。数据库镜像可以具体分为高安全模式与高性能模式。在高安全模式下，主要体现“安全”两个字，已提交的事务会交给伙伴双方提交，此时虽然比较安全，大那时会延长事务滞后的时间。而在高性能模式下，事务部需要等待镜像服务器将日志写入到硬盘中便可以提交，为此可以最大程度的提高数据库数据不同的性能。 不过这个解决方案也有一定的缺陷，最主要是其限制条件比较多。如只能够使用标准服务器;只能够使用数据库快照对镜像服务器进行有限的报告;只能够使用数据库单一、重复的副本。如果需要其他的副本的话，在可以在使用数据库镜像的同时，采用数据库的日志传送功能。可见几个不同的解决方案可以一起结合使用，吸长补短，以提高数据库的性能与高可用性。 二、日志传送的优劣分析 跟数据库镜像一样，日志传送也是数据库级别的操作。通常情况下，可以使用日志传送来维护相应生产数据库的一个或者多个备用数据库。在日志传送中，这个生产服务器叫做主数据库服务器，备份服务器叫做辅助数据库。而在数据库镜像解决方案中，这个生产服务器也叫做主数据库服务器，不过这个辅助数据库则叫做镜像数据库。虽然他们的名字相同，但是实际上代表着同一种含义。 日志传送配置包括一个主服务器(包含主数据库)，一个或多个辅助服务器(每个服务器包含一个辅助数据库)和一个监视服务器。每个辅助服务器从主数据库的日志备份按设置的时间间隔更新其辅助数据库。日志传送涉及到主服务器创建主数据库日志备份和辅助服务器还原日志备份之间用户可修改的延迟。发生故障转移之前，必须通过手动应用全部未还原的日志备份来完全更新辅助数据库。 日志传送的优势也很明显，如最大的优势可以根据需要来定义数据同步的时间，如可以将延迟的时间定义为从主服务器备份主数据库日志到辅助服务器必须还原日志备份之间的时间。在某些特定的应用环境中，这个特性会非常的有用。而且，针对单个主数据库可以在多个服务器实例上支持多个辅助数据库等等。
Oracle DataGuard容灾解决方案
Oracle DataGuard容灾解决方案
目录 一. 需求分析 (3) 二. 解决方案 (3) 2.1拓扑架构 (3) 2.2方案特点 (4) 2.3方案优势 (4) 2.4产品介绍 (5) 三. Oracle维保服务 (8) 四. 方案报价 (10)
一. 需求分析 用户现有两台服务器，windows2008平台，一台运行oracle 11g r2，一台运行用友NC 6.3。现在通过每天备份的方式保证安全。用户希望在他的另一个机房（裸光纤互联）中搭建容灾平台。 因此本方案针对以上现状，提出Oracle DataGuard容灾解决方案，这样主数据库在遇到极端状况时，可以及时切换到备库，保证业务的连续性。 二. 解决方案 2.1 拓扑架构 Dataguard可以实现远程数据容灾,利用该功能也可实现高可用性。 数据容灾是指建立一个异地的数据系统，该系统是本地关键应用数据的一个实时复制。在本地数据及整个应用系统出现灾难时，系统至少在或本地异地保存有一份可用的关键业务的数据,基于该功能,结合客户实际情况我方推荐使用其作为保证系统可靠运行的一种解决方案,由于两台机器的数据一致性以及低延迟,完全可以胜任,在主机出现故障时,切换至备机运行。
2.2 方案特点 对现有的环境改动小，能最大限度的减少对现有应用系统的影响。 能满足客户对海量数据的管理要求。 可以实现远距离容灾，对网络要求低，低延时，快速业务切换。 同步或异步日志传输； 低成本的投入。 2.3 方案优势 灾难恢复和高可用性—Data Guard 提供了一个高效和全面的灾难恢复和高可用性解决方案。易于管理的转换和故障切换功能允许主数据库和备用数据库之间的角色转换，从而使主数据库因计划的和计划外的中断所导致的停机时间减到最少。 完善的数据保护—使用备用数据库，Data Guard 可保证即使遇到不可预见的灾难也不会丢失数据。备用数据库提供了防止数据损坏和用户错误的安全保护。主数据库上的存储器级物理损坏不会传播到备用数据库上。同样，导致主数据库永久损坏的逻辑损坏或用户错误也能够得到解决。最后，在将重做数据应用到备用数据库时会对其进行验证。 有效利用系统资源—备用数据库表使用从主数据库接收到的重做数据进行更新，并且可用于诸如备份操作、报表、合计和查询等其它任务，从而减少执行这些任务所必需的主数据库工作负载，节省宝贵的CPU 和I/O 周期。使用逻辑备用数据库，用户可以在模式中不从主数据库进行更新的表上执行数据处理操作。逻辑备用数据库可以在从主数据库中对表进行更新时保持打开，并可同时对表进行只读访问。最后，可以在维护的表上创建额外索引和物化视图，以获得更好的查询性能和适应特定的业务要求。 灵活的数据保护功能，从而在可用性与性能要求之间取得平衡—Oracle Data Guard 提供了最大保护、最高可用性和最高性能等模式，来帮助企业在系统性能要求和数据保护之间取得平衡。 自动间隔检测及其解决方案—如果主数据库与一个或更多个备用数据库之间的连接丢失（例如，由于网络问题），则在主数据库上生成的重做数据将无法
数据库服务器双机热备解决方案
数据库服务器双机热备解决方案 数据库服务器双机热备解决方案是根据用户需求实现数据库安全的一种高性能、高可靠性的解决方案。本文以荆门市掇刀区电子政务系统为例，探讨了双机热备系统的工作原理、技术方案及成果经验。 随着以数据库为核心的计算机管理系统的普及，企业对计算机系统的依赖程度也日渐增加，数据存储技术的可靠和安全变得越来越重要，双机热备系统就是根据用户需求保证数据库安全的、高可靠性的解决方案。荆门市掇刀区在电子政务平台的建设和完善中，采用基于DM 数据库服务的双机热备解决方案，保证了数据的安全。本文就荆门市掇刀区电子政务系统中实现双机热备系统的工作原理、技术方案及成果经验等进行探讨。 1 系统需求 根据应用要求，数据库双机热备系统配置为： a.系统基于Red flag Linux DC 5.0平台，数据库平台采用DM 5.0.6。 b.服务器双机热备为单工模式(Active/Standby)。一台服务器运行DM数据库系统，另一台服务器为备机，两台机器相互监测对方的运行状况。当一台主机宕机时，另一台主机立即接管其工作，保证工作不间断。 c.数据集中在磁盘阵列柜，磁盘柜使用RAID5技术。 d.双机容错软件选用DataWare双机容错系统，DataWare是一套提供防止业务主机因不可避免的意外性或计划性宕机问题的高可用性软件。 e.服务器与客户端遵循TCP/IP协议，对用户而言，切换是透明的。 2 工作原理 DataWare软件同时安装在两台主机上，监视系统的状态，协调两台主机的工作，维护系统的可用性。它能侦测应用级系统软件、硬件发生的故障，及时进行错误隔绝、恢复，以最低成本提供用户几乎不停顿的计算机作业环境。在正常的运作情形之下，主机之间透过冗余侦测机制互相侦测，当任一主机有错误产生时，DataWare提供严谨的判断与分析，确认主机出错之后，才完全启动备援接管动作。容错软件在服务器节点间保持着间歇的通信信号，也叫做心跳信号，是错误检测的一个机制。 即通过每一个通信路径，在两个对等系统之间进行周期性的握手，如果连续没有收到的心跳信号到了一定的数目，DataWare容错软件就把这条路径标示为