| 以文本方式查看主题 - 曙海教育集团论坛 (http://sun4.cn/bbs/index.asp) -- Oracle数据库 (http://sun4.cn/bbs/list.asp?boardid=65) ---- oracle高可靠性的一些讨论和想法 (http://sun4.cn/bbs/dispbbs.asp?boardid=65&id=2495) |
| -- 作者：wangxinxin -- 发布时间：2010-12-11 10:46:58 -- oracle高可靠性的一些讨论和想法 有关oracle高可靠性的一些讨论和想法 http://skyhorse.blogbus.com/logs/2004/03/106569.html 有关RAC的工作日志： 12月16日到12月23日做RAC的试验。12月24日把服务器交给QYC做DataGuard. QYC做完DataGuard试验之后，1月4日我重新开始做RAC的试验。 当初说是要做XX集团的双机热备,因为我应用oracle的时间非常短，对oracle并不熟悉，所以我这段时间就搜集了 一些相关的信息和资料，以供大家参考。 XX集团的应用我分析了一下，应该是不要求24*7连续工作的，只要能够及时恢复访问即可，而且数据量不是太大 。 而且我原来让XX方面做了NAT, 我们在这里就可以进行远端的控制，控制到XX集团内部的Intranet的个别服务器。 我在网上所能搜到的信息是高可用性解决方案分为4种， 一种是oracle提供的被用方法,Standby (=9i DataGuard) 一种是AR (高级复制Advanced Replication，在以前版本叫快照snapshot) 一种是oracle 并行服务器8i的OPS (9i RAC,Real Application Cluster) 一种是第三方HA解决方案 （如Rose HA，故障切换时间是几分钟) oracle公司的牛人著的里也是 把这4种方法做为高可用方案的组成。 这几种方案从原理上来讲都很容易理解，但是实际上有相当多的细节和问题。 另外还有一种是大家都不太熟悉的是oracle 的 failsafe。 failsafe 采用的是SHARE NOTHING结构，即采用若干台服务器组成集群，共同连接到一个共享磁盘系统， 在同一时刻，只有一台服务器能够访问共享磁盘，能够对外提供服务.这与第3方HA方案的概念基本一样。 但是 failsafe系统局限于WINDOWS(winnt,win2k...)平台，必须配合MSCS(microsoft cluster server). 我在网上找到现成的双机热备的文档 就是讲在 oracle8i上如何做standby. 其保证了始终有一台备用的 数据库能够在很短时间内通过人工，恢复正常的访问，并保证数据一致。这是不要求24*7连续工作时所考虑的方 案。 我们所能做试验的就是前三种方案，因为人手有限，所以就做了9i的DataGuard 和RAC 两种方案的试验。 高级复制据说lwd在很久以前做过。我打电话问oracle公司，他说AR对数据库的性能影响太大。 高级复制也分为两种情况 1.主动／被动策略: node1处于主动模式，数据库可读写，node2处于被动模式，数据库只读。 2.主动／主动策略: node1和node2 都处于主动模式，数据库都可读写。这种对数据库的性能影响特别大。 在讲述DataGuard和RAC这两种方案之前，我先补充一点关于oracle Client 如何能够不修改本机配置就能 访问两台oracles数据库的方法。 也就是修改本机的tnsname.ora 一个通常的tnsname.ora 如下： RACDB = (DESCRIPTION = (LOAD_BALANCE = off) (failover = on) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 211.68.29.61)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 211.68.29.62)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = racdb) ) ) 在 ADDRESS_LIST 中 写了两个地址，client 通过oracle net 在访问时，如果访问不通第一个ip,就会访问第2个 ip. 这个特性是早就有了的。load_balance 特性也是有的。但是在两台数据库内容不一致的情况下是没有任何意义的 。 不过，在oracle9i 的官方pdf中，load_balance 特性是不推荐使用的。 RAC 的试验我昨天已经做成了，虽然遇到了一些不大不小的Bug和不稳定现象。 环境是oracle9.2.0.1.0 , 2* RedHatAdvanceServer 2.1 和一个磁盘阵列, 采用的是裸设备。 RAC 是share everything 模式，两个数据库实例同时共享同一套数据文件，控制文件，日志文件。 客户端可以同时访问这两台数据库得到的数据都是一致的，它的重点是高性能,可扩展性。但是可靠性是不如Data Guard的。 因为首先在物理上是连接在一起的，是没法容灾的。 其次，instance1 死掉的话，可能可能影响instance2。 (Oracle 公司的电话支持说的， 以及网上的论坛中有相关的例子，一个实例down机拖累另一台不能正常工作, 我在做RAC试验的时候，也出现了node1 重起，造成node2也重起的个别现象) 当然了，与单机的oracle相比，可用性肯定是高的。 另外网上我所能找得到的RAC成功案例(论坛oracle版主之类实施)，无一例外都是oracle经过认证的服务器硬件和 软件. 例如HP,DELL PowerEdge服务器。DELL/EMC fiber-channel storage array 等等。 另外，因为没有多余交换机，4块网卡中的进行内部通信用的两块网卡我采用的是直接级联 (新聚思公司的oracle支持说这样不稳定，但是为什么不稳定也没有说原因) 有关共享文件系统的一些问题： 采用裸设备无法进行日常管理，也没有办法进行文件系统级的备份。 开始我第一次在Mandrake8.1的时候，对阵列进行分区，而fdisk在linux下只能分16个分区，我只好采用 lvm（logical volume manager，支持256个)对裸设备进行管理。后来在dbca创建数据库的最后阶段无法创建，只 好作罢。 第二次用RedHat AS2.1，oracle网站新推出了针对ocfs，我将其2003-1-3 更新的有关ocfs的所有rpm包(只适用 于AS2.1）安装上，但是却发现无法正常加载ocfs module, 我查了好久，估计这与我们所用的世纪曙光硬件有关 ， 采用的AMD双Athlon MP 1800+ 以及相关主机硬件，RedHat AS 2.1 无法正常认出，从而造成ocfs modules也无法 正常加载，因为ocfs modules与kernel是相关的。或许换成intel 的双cpu, 或换成单cpu ，然后重装系统就可以 解决。 因为rhAS2.1的内核不支持 lvm, 需要重新编译内核才能支持，我只好 将磁盘阵列分成2个drive,分别进行了 分区，跳过了fdisk分区数量限制，给oracle提供了足够多的裸分区。 当初做方案时买的vertris 的冷备份软件(大概10万元)是只能在oracle停机时通过smb来copy 文件进行备份到磁 带里的。 而裸设备是没有办法copy 的。 客户端在tnsname.ora配好address_list后， 当nodeA 停机时，是可以不用修改配置访问到nodeB 的。 但是这也分很多种情况 nodeA down, listenerA down, InstanceA down, InstanceA in indeterminate state, session die等等。 并非每种情况都能实现自动转到node2上。 第三方HA软件是靠自己的agent软件检测模块按照自己的故障判断标准进行强制转换的。第一台肯定不会被访问到 ， 在几分钟之后所有的访问都会访问到第二台刚刚起来的数据库上。 oracle 要想实现与第三方HA软件一样的功能，只能与microsoft cluster server一起 在windows平台 上实现failover. 除此之外，oracle本身的几种High Available 方案是不提供与此类似的自动failover功能的。 RAC提供并行； standby/dataguard提供热备份服务器(需要人工维护切换)； AR 可以基本实时提供两台数据一致的数据库，但是数据库性能受影响。而且客户端能否在各种各样的情况下都自 动 切换到第二台数据库上我也不知道。(例如listener running, instance down时无法切换到第二台) 主数据库发生灾难，无法访问的情况下应该是能够切换的，但是有些情况下，只需要修改 tnsname.ora或者停掉node1的listener即可。 以前曾经有人在职成网做过 RoseHA+oracle817+Turbolinux的集成方案, 据说效果也非常差。我所看到我们这里 的人去职成网 进行维护N多次。(N非常大) 所以在集成方案中如果用到了oracle数据库，就准备好有人长期进行维护，主数据库 在万一情况下发生灾难，只要有一台热的备用数据库能够在比较短(电话通知之后1天之内)的时间内继续投入使用 就达到了可用性的目的，不至于主数据库损坏，重新进行安装恢复占用星期级的时间。 要想达到failover自动切换，无需人的参予是一种理想化状态，在unix平台上无法实现，windows平台上的oracle failover 我不太清楚，应该是能实现这个想法的。 standby备用数据库 是在oracle7.x才开始提供的一项功能，到了oracle8i才能提供read only模式， 到了9i 才使日志应用等实现了自动化，但是这个自动化不是故障切换自动化，而是只为了实现热备份数据库的功 能完善而 增加的一些自动化。 归根到底，oracle公司开发这么久，还没有开发完善这些高可用方案，只是一直处于完善阶 段。 RAC的并行提供服务我从一些oracle技术支持那里听来的说法也是最好一台用来做读写，另一台专门提供只读操作 的查询， 不然仍然影响性能。用来做我们这种failover应用的倒不多。 很容易理解的一些稍微复杂的原理，要想在实际中应用是需要大量时间的，里面所涉及到的众多细节如日志增量 等等很麻烦。 就连oracle9.0.0.1在linux下的OUI(oracle univesal installer) 安装程序在它认证的linux上运行也是一堆Bug. 也就是它的jre有毛病，所以我当初在mandrake8.1上创建数据库出现了问题，无法进行下去。 特定的环境，特定的问题，很多都是没有解释的。这是网上的一个DBA的原话。 网上也有oracle81700升级到81740就出故障的案例。 使用DataGuard(standby) 是不能实现故障的自动切换的，因为据oracle公司的人说无从判断究竟算什么样的故障 才开始进行转移， 这个已经超出oracle软件本身的范围了。或许可以通过自己编写程序来按照自己的标准来进行判断和转移。 但是DataGuard做到了始终有一台数据库与主数据库保持一致。在加上客户端的tnsname.ora的addresslist在一定 程度上 是可以实现部分的故障切换的。 备数据库平时只能处于read only或 recovery manage 模式。 read only 不能应用主数据库传来的重作日志，recovery manage 可以进行数据恢复，但是不能被客户端访问。 备用数据库经常处于修复状态，因此不能被终端用户使用，这从管理角度是一种浪费(所以8i开始提供了read only模式)。 我的想法是 1. 主数据库发生灾难，被迫关闭，XX方面打电话通知过来，我们通过远程由人工激活备用的数据库即可。也就是 敲几行sql命令即可。 完全可以写成脚本，随便找一个人执行一下即可。 2. 备数据库白天处于read only 模式，可供webserver(也就是客户端)查询，晚上12点到1点通过cron 运行在recover managed模式， 将白天主数据库的更改应用到备数据库上。 3. 通过cron将备数据库白天处于 primary 模式，可读可写，晚上通过脚本改回standby模式，并且应用主数据库 的更新。 这样当主数据库down机，客户端会立刻连到第二台数据库上，同时也能够进行读写。数据分歧只有一天，并且达 到了无人 切换状态。 这3种方法，第1种是最好的。 第2种是可行的，是oracle官方认可的，有数据分歧，和只读的局限性。 第3种有数据分歧并且有或大或小的细节问题没有考虑，只是我的一个临时想法。 在RAC 和 DataGuard 这两种方案中， RAC对硬件和操作系统要求都比较高，维护也非常复杂，我们买的vertas 备份软件也没有办法使用冷备的文件。 对人员的素质要求也很高。 随便举个例子，RedHat AS 2.1 如果认不出SCSI driver，就没法做了。因为oracle9.2i只能用这个操作系统。 ( webmail没有用mandrake8.1而是用mandrake8.2就是这个原因) 不确定因素太多。 在做系统集成方案和买硬件时都要仔细考虑，买什么样的服务器，阵列，网卡，几个交换机，linuxAS21能否装上 等等。 而不是随便写个双机热备，买两个服务器，一个交换机就行了。 不过这个方案可以用在我们自己的机房里，提供高性能的oracle数据库服务。(但是需要比较多的时间来准备和调 试）。 我现在只能做到把oracle92i装起来，具体平时的管理还要靠有数据库使用经验的其他同事来做。 安装文档我放在附件里了。 |