ORACLE RAC 数据库负载均衡方案
Real Application Cluster(以前称作Oracle Parallel Server，OPS)用来在集群环境下实现多机共享数据库，以保证应用的高可用性。同时可以自动实现并行处理及均分负载，还能实现数据库在故障时的容错和无断点恢复。
Real Application Cluster为大多数关键业务要求的数据库环境提供了极高的性能和完善的纠错功能。Real Application Cluster允许集群系统或大型并行系统中的多个节点共享同一物理数据库。Real Application Cluster 可以自动进行负载平衡、故障修复和规划停机时间，以支持高可用性应用程序。它还显著地提高了大型数据仓库和决策支持系统的性能。通过与并行查询选件结合，它还提供了节点间的并行性和节点内的并行性，以得到更高的性能。
当并行服务器中某节点失效，透明的应用程序容错能够把用户自动转接到另一节点上继续运行，应用程序在用户没有察觉的情况下继续执行。这使周期性和非周期性发生故障的系统增大了连续可用性。进程的失效可以完全透明地转移到另一节点上去，通过适当地配置，可以指定所有查询都在客户端进行缓存，这样它们便可以在转移后的节点上重新设置。同时，还可以在没有失效时预先与容错节点建立一个连接，这样可以减少容错时在连接所花的时间。
下图是并行服务器(Real Application Cluster)方式：
具有Cache Fusion体系结构的Oracle Real Application Clusters为企业电子商务应用开发提供了以下好处：
●电子商务应用的灵活和毫不费力的伸缩性；应用用户可以登录到单独的虚拟高性能集群服务器。
向数据库添加节点非常容易，并且当需要添加处理器节点或者业务需求变化时，不用手工对数据
进行分区。对于所有的应用即时提供集群的可伸缩性－－不用修改应用程序。
●较之传统集群数据库体系结构的高可用性解决方案；该体系结构为客户提供了几乎连续的数据
访问，使硬件和软件故障导致的业务中断最小化。系统具备对多个节点失败的容错能力，使部件
失败屏蔽开最终用户。
●单独的管理实体；为了进行所有管理操作，在集群中保持一个单独的系统映像。DBA一次性地
进行安装、配置、备份、升级以及监控等功能，然后Oracle将管理功能自动分配到适宜的节点。
这意味着DBA只管理着一个虚拟服务器。
●Cache Fusion保存了所有Oracle客户在他们电子商务应用中学习和开发Oracle的投资。所有
单节点数据库功能都保留下来，并且应用程序使用相同标准的Oracle接口连接到数据库上。
1.可伸缩性
基于RAC的电子商务应用的用户或者中间层应用服务器客户，可以通过虚拟数据库服务名连接到数据库上。Oracle在集群中多个节点之间自动平衡用户负载。不同节点上的Real Application Clusters数据库实例预订所有数据库服务或者部分子集数据库服务。这使得DBA高度灵活地选定，连接到特定数据库服务的特定应用程序客
户是否可以连接到某些或者全部的数据库节点。
虽然每一个节点有一个不同的物理IP地址时，应用客户仍可以在一个逻辑数据库服务名的水平上进行连接。因此客户端对于不相关的事情如多服务器的多个地址可以毫不关心。
随着业务的增长，电子商务可以从容地增加处理能力。Cache Fusion体系结构直接地利用新节点的CPU和内存资源。DBA无需用手工对数据重新分区。这个优点是这种体系结构的副产品，因为有透明度的数据存取是Cache Fusion的一项基本功能。
Cache Fusion体系机构自动适应快速变化的电子商务需求及随之而来的工作负荷的改变。DBA也不必因为工作负荷变化而对数据进行手工的重新分区。Real Application Clusters通过动态地重新分配数据库资源，从而在节点之间用最小化的磁盘I/O和低的延迟通信来优化利用集群系统资源。这使得Real Application Clusters可以从容实现增加的应用吞吐量和优化的响应时间。
2.高可用性
Real Application Clusters提供了真正的高可用性解决方案，关键的突破是在大多数数据库恢复期间能提供完整的数据库访问。这使得Real Application Clusters成为电子商务应用所要求的24x7可用性的最佳平台。
Real Application Clusters在高可用性上在三个关键领域胜出：
●提供了数据库恢复期间的数据块访问
●透明的失效转移对最终用户屏蔽了系统失效
●N-1节点失效的容错能力
只要有一个数据库节点幸存，Real Application Clusters就能够提供完全的数据库访问和相对不间断的操作。3.可管理性
Real Application Clusters实现了真正意义上的一个单系统访问数据库，它提供了从任何节点到所有磁盘设备和远程高速缓存进行无缝数据访问的能力。此单系统映像延伸到所有数据库管理操作。安装、配置、备份、升级以及监控等操作只需进行一次，然后会自动发布到集群中所有节点上去。各种Oracle工具（如Oracle Universal Installer、Database Configuration Assistant以及Recovery Manager）将发现集群数据块中所有不同的节点并以它们为目标分配给想得到的任务。
通过为特定的管理操作选择多个目标节点，管理任务在数据库集群中多个节点上执行。这为电子商务管理其环境带来了极大的可伸缩性上的经济实惠。例如，向数据库集群添加一个节点只会增加最小的管理任务。这样，
Real Application Clusters支持在线电子商务应用和决策支持之类的应用，并且为数据访问和管理提供了单一的虚拟高性能服务器。
大型ORACLE数据库优化设计方案 本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手，分析ORACLE的系统结构和工作机理，从九个不同方面较全面地总结了ORACLE数据库的优化调整方案。 对于ORACLE数据库的数据存取，主要有四个不同的调整级别，第一级调整是操作系统级 包括硬件平台,第二级调整是ORACLE RDBMS级的调整,第三级是数据库设计级的调整,最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化，数据库的整体性能会得到很大的改善。下面从九个不 同方面介绍ORACLE数据库优化设计方案。 一.数据库优化自由结构OFA(Optimal flexible Architecture) 数据库的逻辑配置对数据库性能有很大的影响,为此,ORACLE公司对表空间设计提出了一种优化结构OFA。使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构OFA,简单地讲就是在数据库中可以高效自由地分布逻辑数据对象,因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。数据库逻辑设计的结果应当符合下面的准则：(1)把以同样方式使用的段类型存储在一起； (2)按照标准使用来设计系统；(3)存在用于例外的分离区域；(4)最小化表空间冲突；(5)将数 据字典分离。 二、充分利用系统全局区域SGA(SYSTEM GLOBAL AREA) SGA是oracle数据库的心脏。用户的进程对这个内存区发送事务，并且以这里作为高速缓存读取命中的数据，以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA 包括以下几个部分： 1、数据块缓冲区(data block buffer cache)是SGA中的一块高速缓存，占整个数据库大小 的1%-2%，用来存储从数据库重读取的数据块(表、索引、簇等)，因此采用least recently used (LRU,最近最少使用)的方法进行空间管理。 2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表 说明和权限，它也采用LRU方式管理。 3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。 4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU算法 管理。如果设置过小，语句将被连续不断地再装入到库缓存，影响系统性能。 另外，SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这
存储集群双机热备方案
目录 一、前言 (3) 1、公司简介 (3) 2、企业构想 (3) 3、背景资料 (4) 二、需求分析 (4) 三、方案设计 (5) 1．双机容错基本架构 (5) 2、软件容错原理 (6) 3、设计原则 (7) 4、拓扑结构图 (7) 四、方案介绍 (10) 方案一1对1数据库服务器应用 (10) 方案二CLUSTER数据库服务器应用 (11) 五、设备选型 (12) 方案1：双机热备+冷机备份 (12) 方案2：群集+负载均衡+冷机备份 (13) 六、售后服务 (15) 1、技术支持与服务 (15) 2、用户培训 (15)
一、前言 1.1、公司简介 《公司名称》成立于2000年,专业从事网络安全设备营销。随着业务的迅速发展，经历了从计算机营销到综合系统集成的飞跃发展。从成立至今已完成数百个网络工程，为政府、银行、公安、交通、电信、电力等行业提供了IT相关系统集成项目项目和硬件安全产品，并取得销售思科、华为、安达通、IBM、HP、Microsoft等产品上海地区市场名列前茅的骄人业绩。 《公司名称》致力于实现网络商务模式的转型。作为国内领先的联网和安全性解决方案供应商，《公司名称》对依赖网络获得战略性收益的客户一直给予密切关注。公司的客户来自全国各行各业，包括主要的网络运营商、企业、政府机构以及研究和教育机构等。 《公司名称》推出的一系列互联网解决方案，提供所需的安全性和性能来支持国内大型、复杂、要求严格的关键网络，其中包括国内的20余家企事业和政府机关. 《公司名称》成立的唯一宗旨是--企业以诚信为本安全以创新为魂。今天，《公司名称》通过以下努力，帮助国内客户转变他们的网络经济模式，从而建立强大的竞争优势：（1）提出合理的解决方案，以抵御日益频繁复杂的攻击 （2）利用网络应用和服务来取得市场竞争优势。 （3）为客户和业务合作伙伴提供安全的定制方式来接入远程资源 1.2、企业构想 《公司名称》的构想是建立一个新型公共安全网络，将互联网广泛的连接性和专用网络有保障的性能和安全性完美地结合起来。《公司名称》正与业界顶尖的合作伙伴协作，通过先进的技术和高科产品来实施这个构想。使我们和国内各大企业可通过一个新型公共网络来获得有保障的安全性能来支持高级应用。 《公司名称》正在帮助客户改进关键网络的经济模式、安全性以及性能。凭借国际上要求最严格的网络所开发安全产品，《公司名称》正致力于使联网超越低价商品化连接性的境界。《公司名称》正推动国内各行业的网络转型，将今天的"尽力而为"网络改造成可靠、安全的高速网络，以满足今天和未来应用的需要。 1.3、背景资料 随着计算机系统的日益庞大，应用的增多，客户要求计算机网络系统具有高可靠，高
oracle双机热备架构方案 双机热备有两种实现模式，一种是基于共享的储备设备的方式，另一种是没有共享的储备设备的方式，一样称为纯软件方式。 基于储备共享的双机热备是双机热备的最标准方案。 关于这种方式，采纳两台（或多台）服务器，使用共享的储备设备（磁盘阵列柜或储备区域网SAN）。两台服务器能够采纳互备、主从、并行等不同的方式。在工作过程中，两台服务器将以一个虚拟的IP地址对外提供服务，依工作方式的不同，将服务要求发送给其中一台服务器承担。同时，服务器通过心跳线(目前往往采纳建立私有网络的方式)侦测另一台服务器的工作状况。当一台服务器显现故障时，另一台服务器依照心跳侦测的情形做出判定，并进行切换，接管服务。关于用户而言，这一过程是全自动的，在专门短时刻内完成，从而对业务可不能造成阻碍。由于使用共享的储备设备，因此两台服务器使用的实际上是一样的数据，由双机或集群软件对其进行治理。 关于纯软件的方式，则是通过支持镜像的双机软件，将数据能够实时复制到另一台服务器上，如此同样的数据就在两台服务器上各存在一份，假如一台服务器显现故障，能够及时切换到另一台服务器。 纯软件方式还有另外一种情形，即服务器只是提供应用服务，而并不储存数据（比如只进行某些运算，做为应用服务器使用）。这种情形下同样也不需要使用共享的储备设备，而能够直截了当使用双机或集群软件即可。但这种情形事实上与镜像无关，只只是是标准的双机热备的一种小的变化。 本方案是前者————基于共享储备设备的数据库热备。 数据库服务器双机热备的好处 这种配置模式的优点是有利于数据库的升级，当其中systemA需要升级的时候，就把服务切换到systemB上运行，升级A的DB2程序，之后还能够把服务切换回到A来，然后升级B的DB2程序。那个升级过程可不能阻碍用户的DB2使用，因为总有一台机器能够使用DB2程序来响应用户的服务要求。 服务器的故障可能由各种缘故引起，如设备故障、操作系统故障、软件系统故障等等。一样地讲，在技术人员在现场的情形下，复原服务器正常可能需要１０分钟、几小时甚至几天。从实际体会上看，除非是简单地重启服务器（可能隐患仍旧存在），否则往往需要几个小时以上。而假如技术人员不在现场，则复原服务的时刻就更长了。 而关于一些重要系统而言，用户是专门难忍耐如此长时刻的服务中断的。因此，就需要通过双机热备，来幸免长时刻的服务中断，保证系统长期、可靠的服务。
IBM3650双机热备方案示例 IBM3650双机热备方案示例 IBM X3650服务器+DS3200 SAS 磁盘柜双机热备方案双机热备方案所需软硬件清单如下： 1、IBM X3650 服务器2台（具体配置根据需求选配） 2、IBM DS3200 磁盘柜一台（单控制器，单SAS 接口） 3、SAS HBA 卡2块（每台服务器各加一块） 4、双机模块（子卡）一块 5、SAS 连接线2条 6、双机热备软件（ROSE HA OR LIFEKEEPER ）一套 DS3200/DS3400安装心得及技巧 这应该是网络上第一篇关于IBM System Storage DS3200和DS3400产品安装的非官方性文章，希望可以对大家的工作中带来帮助。 作为DS400产品的更新型号，DS3200和DS3400提供了更强的性能及灵活性，相信会成为今后一两年内的IBM低端存储产品的首选。 DS3200和DS3400均出自于LSI公司的Engenio系统（DS4000系列的大部分产品也是由Engenio为IBM协议设计及生产，去年Engenio被LSI收购）。所以设计思想和结构与DS400（Adapter 公司设计）会有较大的不同，管理方式也会与DS4000系列较为接近。
DS3000系列均需要在自身上安装不少于4个硬盘。建议先装上硬盘再上电开机。 DS3000系列提供与DS4000系列类似的带内和带外两种管理方法，带外管理的默认IP地址也与DS4000一样，控制器A为192.168.128.,控制器B为192.168.128.102。 本人比较喜欢采用带外管理，将本本网卡设至192.168.128网段后，可以ping通即可。 管理口长时间未起用时需要若干分钟的时候等待管理接口工作。 在本本上安装DS3000 Storage Manager（随机附带），注意该SM与DS4000上的Storage Manager为不同程序，不可替换使用。甚至不能在一台机器上共存。 打开Storage Manager后，首先需要发现设备，可以ping通控制器后，发现工作会非常容易。 双击发现的设备就可以进入该设备的管理界面，学名叫Subsystem Management。 Subsystem Management分为5个大项，Summary，Configure，Modify，Tools，Support。 常规的操作这里不再详述，如果你装过DS4000产品，应该对配置方法不会感到陌生。当然Storage Manager里只提供一些常规功能，在遇到问题的时候，比如需要重置手动清零时在该程序里无法完成的，所以与DS4000产品一样，提供了Script的方式，运行Script有两种方法。方法一：在DS3000 Storage
生产数据库性能优化方案（初稿） 1.背景 生产数据库上线一段时间后由于数据量远大于预期，导致数据库性能低下而影响正常业务，故需要对数据库进行性能优化。 2.现状 当前数据库结构如下图所示： 图2-1 系统结构示意图 上游三个数据源通过DI工具以定时任务的方式将上游数据抽取到基础数据库中（红色部分），从基础库到下游目标库则是通过用户操作应用程序将基础数
据库中的数据调度到目标数据库中。根据目前对数据量的统计基础库约为400GB+的数据总量。 目前基础数据库的性能低下，主要表现于定时抽取任务执行时间过长，任务间的时间间隔变短；应用执行数据调度时间过长，导致应用长时间处于无响应状态。 3.分析 基础数据库获取上游数据时，数据传输量较大，数据库写操作频繁，操作系统层表现于数据文件所在磁盘写IO高，并持续时间长。 由于基础库放数据到下游数据库是人为操作，数据库读操作频繁，操作系统层表现于数据文件所在磁盘读IO高，且经常会与DI定时任务同时执行，通过系统监控发现磁盘出现大量IO等待状态。 图3-1 磁盘IO状态
图3-2 磁盘等待状态 由于基础库保存原始数据并不对数据进行处理，所以CPU消耗很低，从监控看CPU不视为性能瓶颈点。 图3-3 CPU使用率 从以上分析可以判断数据库操作性能低下主要在高磁盘IO时造成IO挣用较
大导致拖慢整体性能。故本次优化将重点放在解决磁盘IO挣用问题和提高磁盘IOPS上。 4.优化方案 本着应用层变动最小的原则，为解决基础库磁盘IO性能低下问题，我们将从三个方面着手进行，即：优化数据库物理架构、优化DI任务执行时间和优化数据库数据文件所在Path的磁盘VG结构。 4.1.优化数据库物理架构 根据基础库的业务特点，这里将对基础库的读写操作进行分离（即：读、写分离）。这样做的好处在于可以最大限度规避数据库读、写同时操作所带来的磁盘IO挣用问题。调整后的架构如下图： 数据库采用主/从模式，使用binlog复制方式实现数据同步。由于考虑到大数据量复制可能带来的同步延迟问题，实现时需要注意优化复制线程参数。4.2.优化DI任务执行时间 为了避免多任务同时写一个数据库产生磁盘写IO过高的问题，需要对每一
SQL2008双机热备方案 Question 0Sign in to vote公司要上一套系统，DB用SQL2008，怎么实现双机热备？ 一种方案是用windows的故障转移群集搭配SQL自己的群集功能，这种方案需要有共享存储，我现在在虚拟测试环境没办法做实验，所以暂时先不考虑这个。 另外一种是用镜像的方式做双机热备，DB都放在服务器上，不用外接存储，主节点服务器DB实时复制到备用节点中，主节点故障后自动跳到备用节点，不会出现服务中断的问题。这种方式能否实现，该如何操作？因为没做过这种，所以思路有些乱，需要高手们给点指引，谢谢啦。 Friday, November 09, 2012 7:42 AMReply | Quote Rik1012 10 Points
Answers 0Sign in to vote你好，你的方法是不是要有3台服务器安装SQL，一台主机，一台备机，一台做见证，安装完SQL后，打开SQL输入你提供的命令，来实现镜像功能？因为以前没做过这块，所以比较小白，想细致了解一下，高手有空来指点指点，谢谢了。 你好， 那个见证服务器是可选的，你可以选择安装也可以不安装，见证服务器的作用就是，如果主机出错，那见证服务器就会自动地实现故障转移，然后使备机转化成主机，代替主机继续工作，如果你不安装的就只好出错的时候，自己手动转移了。 也不是说要输入命令，SSMS 里这些都有的，你直接点击就可以了，因为我配置的时候也不愿意敲代码，不过这里有现成的你可以直接复制就好。 这篇文档可以手把手教你如果配置，不用写命令，请参考：https://www.doczj.com/doc/5e5576780.html,/p-690922020761.html 。 有什么不清楚的，在问我们，大家相互学习啦。
农村集体建设用地使用权、宅基地使用权确权项 目数据库建设技术方案
一、地籍数据库建设 （一）、成果数据库建设的内容 农村地籍调查成果数据库建设是在农村集体建设用地和宅基地使用权地籍调查的基础上，按照相关数据库标准的要求，建立集空间信息和属性信息为一体的土地调查成果数据库。 农村集体建设用地和宅基地使用权数据库内容： 1、农村地籍数据库包括地籍区、地籍子区、土地权属、土地利用、基础地理等数据。 2、土地权属数据包括宗地的权属、位置、界址、面积等空间和属性信息； 3、土地利用数据包括行政区（含行政村）图斑的权属、地类、面积、界线等； 4、基础地理信息数据包括数学基础、境界、测量控制点、居民地、交通、水系、地理名称等。 （二）成果数据库建设要求 1、严格遵循数据库标准 农村集体建设用地和宅基地使用地籍调查数据库建设以《城镇地籍数据库标准》为基础，结合《宗地代码编制规则（试行）》等新的技术规范和要求，对相关要素属性结构表进行扩展，以满足农村地籍调查成果管理要求。 2、坐标系统
数据库建设采用的坐标系统为山西省全省及区域地籍测量控制及服务体系定制的独立坐标系统。 3、面积计算 农村集体建设用地和宅基地使用权宗地面积按高斯－克吕格投影面面积计算。 4、数据库逻辑结构 农村集体建设用地和宅基地使用权调查数据库由空间数据库和非空间数据库组成。空间数据由矢量数据和栅格数据组成，主要包括：基础地理数据、居民地数据、土地权属数据等。非空间数据由权属信息调查数据组成。农村集体建设用地和宅基地使用权调查数据库逻辑结构见图1。 空间数据库 农村集 体建设 用地和 宅基地 使用权 非空间数据库 扫描文件 调查表格 权属资料 其他数据 土地权属数据 居民地数据 基础地理数据 图1 农村集体建设用地和宅基地使用权调查数据库逻辑结构图
PLUSWELL多机集群、数据备份解决方案 北京蓝科泰达科技有限公司 2008年7月
一：概述 企业和事业单位的运转越来越依赖于计算机系统，如果一旦这个数据处理中心无法正常运转，就会造成业务停顿，导致不可挽回的损失。 而现有的双机热备份设备存在价格高昂，成本较高的情况，往往使用户望而却步。而用户寻求底成本的纯软件方案又往往因产品不容易维护，纯软件双机方案不稳定等因素，往往给用户造成不必要的使用麻烦。有时因护理不当造成数据损坏，发生更大的事故。 蓝科泰达凭借其丰富的研发经验，为您提供高可用性系列产品和优质的服务，推出了蓝科泰达双机容错打包解决方案，目的在于保证数据永不丢失和系统永不停顿，同时为用户节省大量的开支。蓝科泰达容错系统结合了蓝科泰达磁盘阵列产品的安全可靠性与双机容错技术高可用性的优点，相互配合二者的优势。蓝科泰达磁盘阵列针对双机容错技术做了许多优化和改进，满足了双机硬件的连接要求，根据应用环境的实际情况，适用于Windows2000平台以上，开放源代码Linux 平台，SCO UNIX平台上的多种双机热备软件。 二、需求分析 企业关键业务一旦中断，企业的日常运作将受到致命的影响，那么就要求我们的系统在最短的时间内将系统恢复到正常状态。 所以我们要求双机软件能够实现以下几点： 1、异常终端检测 2、网络故障，系统故障，应用程序故障等全系统检测 3、当高可用系统中的某个节点故障，无须人工干预自动切换，保障系统运行 4、速度快（快速恢复） 贵单位业务平台，是以Windwos 2003 Server系统平台为基础，以SQL Server核心的数据 库应用系统，该系统对稳定性要求很高、系统实时性和可用性提出要有连续运行的能力，系统一旦出现故障，其损失是惨重的。 因此，建议用户采用高可用技术，高可用系统在各个节点间保持的间歇的通讯，使系统中的独立节点组合成整体的一套系统，并使用PlusWell 软件可以保障该系统中的某一节点故障都可 被PlusWell 软件所监控，如主服务器应用程序、网卡、操作系统，均纳入公共的安全体系，确 保7*24的不停机。 比较典型的危及系统安全应用和系统错误主要有： （1）进程错误，比如用户应用与文件数据库的连接异常中断或用户进程发生错误。 （2）文件系统故障，由于异常操作或其它原因造成文件系统内部部分信息丢失或不一致。 （3）操作系统故障，操作系统本身的系统调用问题及底层的应用驱动在安装或更新出现冲突； （4）网络线缆故障。 （5）介质问题，网络连接或物理硬盘也可能会出现问题。 方案拓扑：
双机热备方案 双机热备针对的是服务器的临时故障所做的一种备份技术，通过双机热备，来避免长时间的服务中断，保证系统长期、可靠的服务。 1.集群技术 在了解双机热备之前，我们先了解什么是集群技术。 集群（Cluster）技术是指一组相互独立的计算机，利用高速通信网络组成一个计算机系统，每个群集节点（即集群中的每台计算机）都是运行其自己进程的一个独立服务器。这些进程可以彼此通信，对网络客户机来说就像是形成了一个单一系统，协同起来向用户提供应用程序、系统资源和数据，并以单一系统的模式加以管理。一个客户端（Client）与集群相互作用时，集群像是一个独立的服务器。计算机集群技术的出发点是为了提供更高的可用性、可管理性、可伸缩性的计算机系统。一个集群包含多台拥有共享数据存储空间的服务器，各服务器通过内部局域网相互通信。当一个节点发生故障时，它所运行的应用程序将由其他节点自动接管。 其中，只有两个节点的高可用集群又称为双机热备，即使用两台服务器互相备份。当一台服务器出现故障时，可由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续对外提供服务。可见，双机热备是集群技术中最简单的一种。 2. 双机热备适用对象 一般邮件服务器是要长年累月工作的，且为了工作上需要，其邮件备份工作就绝对少不了。有些企业为了避免服务器故障产生数据丢失等现象，都会采用RAID 技术和数据备份技术。但是数据备份只能解决系统出现问题后的恢复；而RAID
技术，又只能解决硬盘的问题。我们知道，无论是硬件还是软件问题，都会造成邮件服务的中断，而RAID及数据备份技术恰恰就不能解决避免服务中断的问题。 要恢复服务器，再轻微的问题或者强悍的技术支持，服务器都要中断一段时间，对于一些需要随时实时在线的用户而言，丢失邮件就等于丢失金钱，损失可大可小，这类用户是很难忍受服务中断的。因此，就需要通过双机热备，来避免长时间的服务中断，保证系统长期、可靠的服务。 3. 实现方案 双机热备有两种实现模式，一种是基于共享的存储设备的方式，另一种是没有共享的存储设备的方式，一般称为纯软件方式。 1）基于共享的存储设备的方式 基于存储共享的双机热备是双机热备的最标准方案。对于这种方式，采用两台服务器（邮件系统同时运行在两台服务器上），使用共享的存储设备磁盘阵列（邮件系统的数据都存放在该磁盘阵列中）。两台服务器可以采用互备、主从、并行等不同的方式。在工作过程中，两台服务器将以一个虚拟的IP地址对外提供服务，依工作方式的不同，将服务请求发送给其中一台服务器承担。同时，服务器
Oracle 11g共享存储双机热备配置手册 本文介绍通过ServHA Cluster配置Oracle共享磁盘阵列双机容错集群。 集群软件下载地址： 主要步骤： 一、防火墙配置。 二、安装Oracle 11g。 三、配置监听器。 四、配置Oracle 11g实例。 五、修改Oracle 11g控制文件。 六、安装并配置ServHA Cluster。 注意事项： 一、O racle配置双机集群方案要求两机都安装Oracle，其中Oracle主服务安装在本机磁 盘内（非共享盘内），数据库实例安装在共享盘内。 二、安装Oracle实例时，请确保对机共享盘处于离线状态并且数据库服务处于停止状 态。 三、两机的Oracle安装配置必须完全相同，例如：实例名，监听器名称，权限，密码。 四、当一台服务器完成所有操作后（包括安装Oracle主服务，配置监听器，实例安装）， 停止本机的Oracle服务，并在对机同样也安装一遍，然后修改控制文件（步骤五）。 防火墙配置 此步骤目的为让ServHA Cluster 工作所必须的端口不受防火墙的拦截，不同操作系统防火墙配置方式不同，但基本思想是相同的，在双机软件通信的过程中，如果没有进行设置，防火墙会阻止ServHA Cluster的通信，使双机集群工作异常。 MicroColor ServHA Cluster在配置的过程中主要需要设置的防火墙例外： 1.18562端口：此端口为“ServHA 配置监控端”的连入端口，如不将此端口设置为 防火墙例外端口，“ServHA 配置监控端”将无法连入集群，如果您修改过ServHA Cluster 的“配置端连入端口号”，请将例外设置为修改过的“配置端连入端口号”；同时，针对该端口的例外IP您可以设置为常用来管理集群的客户计算机IP地址。 2.15538端口：此端口为集群双机相互通信的端口，如不将此端口设置为防火墙例外 端口，ServHA Cluster将无法正常工作，如果您修改过ServHA Cluster的“全局TCP/IP 端口”，请将例外设置为修改过的“全局TCP/IP端口”；同时，针对该端口的例外IP设置为对机的IP地址即可。 注：上述操作在双机均需要执行。
微服务系统和数据库设计方案 1.微服务本质 微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。 简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。 对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。 本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。 理解微服务架构和理念是核心。 2.系统环境
3.微服务架构的挑战 可靠性： 由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。 也就是没有充分的保障机制，则单点故障会大量增加。 运维要求高： 系统监控、高可用性、自动化技术 分布式复杂性： 网络延迟、系统容错、分布式事务 部署依赖性强： 服务依赖、多版本问题 性能（服务间通讯成本高）： 无状态性、进程间调用、跨网络调用 数据一致性： 分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务，成本要高得多。另外，在分布式系统中，通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。 重复开发： 微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发，甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了。 4.架构设计 4.1.思维设计 微服务架构设计的根本目的是实现价值交付，微服务架构只有遵循DevOps理念方可进行的更顺畅，思维方式的转变是最重要的。
双机热备方案
双机热备方案
一:需求分析 客户当前采用二台IBM X3850X5服务器加ROSE MIRRO HA软件在实时数据镜像基础上，实现了不需要共享存储的纯软高可用性系统。RoseMirrorHA 经过现有的以太网络基础环境，经过TCP/IP 协议，在两台主机之间实现了数据的实时镜像，不需要额外的硬件投资。在充分利用已有资源的基础上，经过先进的软件技术，实现纯软的高可用性系统。但ROSE MIRRO HA只是针对高可用性的双机热备，但客户的数据量过大时，如果一台服务器出现故障，另一台服务器在接管数据时将会对庞大的数据进行校验，这将会是一个漫长的过程，而客户的应用将会受到灾难性的问题。考虑到数据量增大的问题，因此建议客户考虑使用存储来实现双机热备份，这样将会在服务器出现故障的情况下，避免需要经过漫长的等待来实现应用的切换，这样将真正实现高可用性和高安全性。 二:双机介绍 双机热备份技术是一种软硬件结合的较高容错应用方案。该方案是由客户现用两台X3850X5服务器经过IBM B24光纤交换机和外接共享磁盘阵列柜DS5020来连接，并经过相应的双机热备份软件来实现的双机热备方案。在这个容错方案中，操作系统和应用程序安装在两台服务器的本地系统盘上，整个网络系统的数据是经过磁盘阵列集中管理和数据备份的。数据集中管理是经过双机热备份系统，将所有站点
的数据直接从中央存储设备读取和存储，并由专业人员进行管理，极大地保护了数据的安全性和保密性。用户的数据存放在外接共享磁盘阵列中，在一台服务器出现故障时，备机主动替代主机工作，保证应用服务不间断。双机热备份系统采用“心跳”方法保证主系统与备用系统的联系。所谓“心跳”，指的是主从系统之间相互按照一定的时间间隔发送通讯信号，表明各自系统当前的运行状态。一旦“心跳”信号表明主机系统发生故障，或者备用系统无法收到主机系统的“心跳” 信号，则系统的高可用性管理软件认为主机系统发生故障，主机停止工作，并将系统资源转移到备用系统上，备用系统将替代主机发挥作用，以保证应用服务运行不间断。 双机热备份方案中，根据两台服务器的工作方式能够有三种不同的工作模式，即：双机热备模式、双机互备模式和双机双工模式。 双机热备模式即当前一般所说的active/standby 方式，active 服务器处于工作状态；而standby 服务器处于监控准备状态，服务器数据包括数据库数据同时往两台或多台服务器写入（一般各服务器采用RAID磁盘阵列卡），保证数据的即时同步。当active 服务器出现故障的时候，经过软件诊测或手工方式将standby机器激活，保证应用在短时间内完全恢复正常使用。典型应用在证券资金服务器或行情服务器。这是当前采用较多的一种模式，但
高可用数据库架构设计标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]
MySQL数据库高可用架构设计 目标： MySQL 数据库服务器不受单点宕机的影响，即时 A 服务器挂掉或者磁盘损坏物理故障导致数据库不可用也不会导致整个系统处于不可用状态，因为还有另外一台备用的数据库服务器可以提供服务。派宝箱采取方案双机主从热备 (Mater Slave 模式) 背景： 双机热备的概念简单说一下，就是要保持两个数据库的状态自动同步。对任何一个数据库的操作都自动应用到另外一个数据库，始终保持两个数据库数据一致。这样做的好处: 1. 可以做灾备，其中一个坏了可以切换到另一个。 2. 可以做负载均衡，可以将请求分摊到其中任何一台上，提高网站吞吐量。对于异地热备，尤其适合灾备。 原理： MySQL Replication双机热备 + 每天自动sqldump出物理文件备份 双机主从自动热备实现数据库服务的高可用加sqldump导出数据文件的方式备份。双重保险！ 可能遇到的问题与挑战：
主从数据库数据一致性问题 宕机后主从切换的问题 1 复制概述 Mysql内建的复制功能(MySQL REPLICATION)是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。 mysql支持的复制类型： （１）：基于语句的复制：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。 一旦发现没法精确复制时，会自动选着基于行的复制。 （２）：基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从开始支持（３）：混合类型的复制: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。 . 复制解决的问题
双机数据库热备系统 安 全 解 决 方 案
一前言 计算机信息化技术的全面发展使得医院的正常运营越来越依赖于HIS 系统，并随着医院信息化的不断深入，HIS系统所产生的大量业务数据已成为一项蕴涵医院命脉的宝贵资源！而诸如数据丢失、盘柜损坏、阵列信息丢失、病毒侵害、人为破坏等危机，却时时威胁着医院数据的安全。 针对上述隐患，传统的共享盘柜式双机热备系统已无法解决。建议医院采用双机数据库热备系统，真正彻底解决上述故障，最大限度降低医院信息业务在各种不可预料灾难发生时的损失，最大限度地保护数据的实时性、完整性和一致性！ 二传统外挂盘柜式双机热备存在安全隐患 1.单点链路隐患 服务器虽然实现了双机冗余，但磁盘阵列柜和光钎交换机都配置为单件，又形成了新的单点隐患！很可能发生链路故障或阵列硬件崩溃，造成整个生产系统宕机。（通常这种结构出了问题属于严重生产事故） 2.数据误删除无法恢复问题 磁盘阵列柜上数据库只有单份，有可能数据库崩溃。由于病毒破坏、人员误操作等原因，导致库表被删或数据丢失；将会给医院造成无法挽回的巨大损失。 3.数据库异地容灾问题 传统的HA结构，不支持远程数据同步容灾。
三双机数据库热备系统能够实现 1.当主服务器出现意外宕机时，备份服务器可以立刻接管主服务器的IP，提供对 外的所有服务，保证了医院的业务连续性，可以提供对医院的365天7*24小时的业务不间断的保护。 2.能实现对主服务器上数据库的数据进行实时智能备份，保证了数据的安全，一 旦出现数据丢失或破坏，可以迅速的从备份服务器上把数据恢复回来。 3.利用双机数据库热备系统独特的数据找回功能，可以在数据库发生人为误操作 或病毒损坏操作时，回退到错误前的状态。 4.整个备份系统具有高容灾性和可扩展性，以后随着数据量的增加也可以增加磁 盘阵列等。 5.可以做到异地实时热备份，真正的做到了有备无患。 四双机数据库热备系统的功能特点 1.实时：实时数据热备 对数据库进行自动监控，连续捕获和备份数据变化,只要数据库内的数据发生变化，便实时、准确的备份下来。 2.回退：找回丢失数据
数据架构规划 一．当前架构 结合研发二部数据量最大的校讯通产品来描述，其他的产品在性能上出现瓶颈，可以向校讯通靠拢。 数据库整体架构：目前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度，横向采用了历史库+当前库的分库架构或者单一的当前库架构，其中历史库只作为web平台读数据库，纵向结合了applications的 memcache+Sybase ASE12.5传统永久磁盘化数据库架构。 数据模型架构：原则上采用了一事一地的数据模型（3NF范式），为了性能考虑，一些大数据量表适当的引用了数据冗余，根据业务再结合采用了当前表+历史表的数据模型。 以下就用图表来进行当前数据架构的说明： 横向分库数据库架构图：
纵向app layer+memcache layler+disk db layer图：
其中web层指的是客户端浏览器层，逻辑上：app层指的是应用服务层，mc 层指的是memcache的客户端层，ms层指的是memcache的服务层，db层指的是目前永久磁盘化的数据库层，当然在物理机器上可能app层跟mc层，ms层是重叠的部署在相同服务器上。 数据模型架构图：
其中以上数据模型中除了少数几张表外其他的都有历史表存在，当然有很多表是没在这个模型图中的，这部分是核心数据模型。这部分模型对象中也包括了一些冗余性的设计，比如用户中有真实姓名，特别是不在这个模型内，由模型核心表产生的一些统计报表，为了查询的性能冗余了合理一些学校名称，地区名称等方面的设计。 二．劣势现象 1.流水表性能瓶颈
当前架构的性能瓶颈集中在流水表的访问上，最大流水表的记录量达到了超5亿级别，这是由于目前外网在用的sybase数据库系统版本，没有采取很好的关于分区的技术。曾经有过把流水表进行物理水平分割，把不同月份的数据分割放在不同的物理表上的模型改造设想，碍于产生的应用程序修改工作量大，老旧数据迁移的麻烦，再加上进行了从单库架构改造到分库架构后，数据库性能瓶颈就不是特别突出。所以模型改造这部分工作没展开。 无论是单库或是分库的模式，出现平台访问数据库的性能瓶颈依然集中在大流水表上，在访问高峰高并发量情况下，短信的流水表进程堵塞，数据库服务 I/O ,CPU的资源耗费达到顶点，在服务器硬件环境不是特别理想情况下，出现了一定概率造成用户访问缓慢甚至觉得页面无法响应现象，造成了用户体念不良影响。 2. 运营维护难点 1)历史数据清理运维工作 为了存储充分利用，为了性能的提升，需要定期进行不再使用的历史数据清理， 由于清理的数据量庞大，传统的数据清理方法根本不可能保证一个晚上有效清理完毕，确保平台第二天正常的运行。虽然目前已经实行了比较高效且可行的数据清理方法，但是每次实行都需要晚上到通宵进行处理，使得数据清理的运维
双机热备解决方案 方案特点： 双机热备可以采用第三方双机软件实现，也可以采用windows server系统自带的mscs来实现双机热备。两套相同应用的服务器采用主/备机模式，主备机采用心跳线连接， 备机会监测主机的运行状态，如果主机出现故障，备机可以自动接管主机的应用继续服务，保证业务的连续性。双机热备的方案建议采用存储设备，数据全部存放在存储设备中，保证数据的一致性，可以让备机顺利接管主机应用。也可以选择不带存储来实现双机。需要软件支持，相当于两台服务器做镜像的模式。 避免的风险： 随着业务对IT系统的依存度越来越高、为保证业务连续性、IT系统的安定、连续运行成为必需。系统中断服务、业务被中断的可能性如下所示。 一、由于操作错误造成系统停止 二、软件/硬件故障 三、利用备份软件等进行恢复的情况下、长时间的操作导致业务中断 四、自然灾害 您的收益： 一、系统安全：双重保护，实时保护公司重要的无形资产 二、业务连续性：IT系统7x24在线，减少停机时间，提供最优质的IT服务 三、IT体验：提高企业员工IT使用体验，提高工作效率 四、满意度：先进的IT系统能更好的服务客户，提高客户满意度
WINDOWS故障转移群集 故障转移群集是一种高可用性的基础结构层，由多台计算机组成，每台计算机相当于一个冗余节点，整个群集系统允许某部分节点掉线、故障或损坏而不影响整个系统的正常运作。一台服务器接管发生故障的服务器的过程通常称为"故障转移"。 如果一台服务器变为不可用，则另一台服务器自动接管发生故障的服务器并继续处理任务。群集中的每台服务器在群集中至少有一台其他服务器确定为其备用服务器。 故障转移群集可应用于Windows server 2003、Windows server 2008、Windows 2012 server等操作系统中部署。 适用环境 1. 硬件组件、应用程序或服务出现故障导致程序或服务无法使用或影响工作；例 如某服务器电源出现故障，如果该该服务器和电源都是唯一的，则存在单点故障， 并且服务器提供的应用程序将不可用。 2. 计划内的服务器停机或维护影响应用程序的可用性；例如要更新无备用服务器 的一台数据库服务器 上的操作系统，你可能需要重启或停止应用程序服务才能安装更新修补程序； 3. 监视和维护多服务器层增加了对系统和网络资源的要求。例如你需要多台服务 器提供多种应用程序服务，各自独立的服务器不利于监视与维护； 工作原理 故障转移群集必须基于域的管理模式部署，以“心跳机制”来监视各个节点的健康状况；备用服务器以心跳信号来确定活动服务器是否正常，要让备用服务器变成活动服务器，它必须确定活动服务器不再正常工作。 同步状态 备用服务器必须首先将其状态与发生故障的服务器的状态进行同步，然后才能开始处理事务。主要有三种不同的同步方法：
Window Server 2012 故障转移集群配置与Oracle 11G R2双机实现
文件修改控制
1准备工作： 需要准备3台服务器（必须），1台磁盘阵列（可选），主要用到的资源如下 1.1一台域控制器（以下所有服务器的操作系统均为windows server 2012 Enterprise R2 X64bit） 计算机名字为AD3 IP地址：192.168.1.250 掩码：255.255.255.0 网关：192.168.1.1（可有可无）自己看着办。。。。。。。 DNS：192.168.1.250 域名为：bbc.local 1.2节点1：域成员服务器 IP地址：192.168.1.251 掩码：255.255.255.0 网关：192.168.1.1 DNS;192.168.1.250 心跳网络：192.168.2.1 加域：bbc.local 1.3节点2: 域成员服务器 IP地址：192.168.1.252 掩码：255.255.255.0 网关：192.168.1.1
DNS;192.168.1.250 心跳网络：192.168.2.2 加域：bbc.local 1.4集群虚拟IP Cluster IP：19 2.168.1.253 需要三个共享磁盘M数据盘、Q仲裁盘、oracle通用服务和 依赖盘I盘，共享盘建议用专用存储，(测试可用 windows 2012系统自带的iscsi功能实现，正式环境建议 使用磁盘柜，要求磁盘柜分2-3个逻辑驱动器，1个作为仲 裁盘、另外1个作为数据盘、通用服务和依赖盘可有可 无)。注意是逻辑驱动器不是磁盘分区。 1.5oracle通用服务共享IP：19 2.168.1.200 （漂移IP） 1.6以下文档中部分图片来自网络，图片内容仅供参考，以文字描 述为准。 2设置第一台AD服务器 2.1网络参数，其余两台也是按上面给出的参数来设定，就不分别 做图解。
数据库架构规划方案
架构的演变 架构演变一定是根据当时要求的场景、压力下性能的需要、安全性、连续性的要求、技术的发展..... 我把架构的发展分为大概4个阶段： 1.单机模式 IT建设初期，高速建设阶段，大家要做的只有一件事，我需要什么构建什么，我需要ERP我买软件，需要HIS买HIS，这个时期按需构建大量的系统基本在这个时期产生，当然那个时候也没什么高可用的要求。 2.双机热备和镜像 基本是20年前的技术了，在高速构建后，一堆的系统运行中，用户发现我们的核心业务如果坏掉业务受影响，停机几个小时做恢复这是无法接受的，那么双机热备或镜像，Active-Standby的模式出现，这样一台机器工作，一台备用坏了在短时间可以接管业务，造成的损失会低很多！
那么问题也很明显，备机资源浪费，依赖存储，数据还是单点，成本较高。产品也很多：RoseHA/RoseMirrorHA、NEC ExpressCluster、微软MSCS、Symantec VCS、Legato、RHCS 太多太多了。 随后为了解决数据单点的问题有出现了存储的主备，存储的双活这厂商也太多了，这里就不介绍了 基本上传统企业依然停留在第一和第二阶段，也就是要么单机，要么双机热备 3.节点多活
随着业务量越来越大，数据量不断飚升，系统高效性的矛盾显现出来，系统卡慢、报表、接口业务无法分离OLAP OLTP业务混合导致系统锁情况严重，资源消耗极其庞大，光靠升级硬件已经无法满足要求，横向扩展已经成为大势所趋。 同时切换时间、备机无法启动的问题也困扰着用户。 那么节点多活，多台机器同时对外提供访问的技术登上舞台，代表的ORACLE RAC、微软ALWAYSON 、MOEBIUS集群 多活的两种模式也是从第二带架构的演变 oracle rac 把双机热备的辅助节点变的可以访问，关键点数据在多节点内存中的调配 Microsoft awo、Moebius 则是把镜像的辅助节点变的可以访问，关键点数据多节点同步 这样横向扩展来分担压力，并且可以在业务上进行分离。 4.分布式架构 分布式架构真的不知道从何说起，概念太大，每个人理解的都不一样，只能意会不能言传： 比如说一份数据分开存成多份