Oracle RAC 深度解释.docx
- 文档编号:12437889
- 上传时间:2023-06-05
- 格式:DOCX
- 页数:18
- 大小:28.78KB
Oracle RAC 深度解释.docx
《Oracle RAC 深度解释.docx》由会员分享,可在线阅读,更多相关《Oracle RAC 深度解释.docx(18页珍藏版)》请在冰点文库上搜索。
OracleRAC深度解释
OracleRAC深度解释
在集群环境中,关键数据通常是共享存放的,比如放在共享磁盘上。
而各个节点的对数据有相同的访问权限,这时就必须有某种机制能够操纵节点对数据的访问。
OracleRAC是利用DLM(DistributeLockManagement)机制来进行多个实例间的并发操纵。
1.2健忘症(Amnesia)
集群环境配置文件不是集中存放的,而是每个节点都有一个本地副本,在集群正常运行时,用户能够在任何节点更换集群的配置,同时这种更换会自动同步到其他节点。
有一种专门情形:
节点A正常关闭,在节点B上修改配置,关闭结点A,启动结点B。
这种情形下,修改的配置文件是丢失的,确实是所谓的健忘症。
1.3脑裂(SplitBrain)
在集群中,节点间通过某种机制(心跳)了解彼此的健康状态,以确保各节点和谐工作。
假设只有"心跳"显现问题,各个节点还在正常运行,这时,每个节点都认为其他的节点宕机了,自己是整个集群环境中的"唯独建在者",自己应该获得整个集群的"操纵权"。
在集群环境中,储备设备差不多上共享的,这就意味着数据灾难,这种情形确实是"脑裂"
解决那个问题的通常方法是使用投票算法(QuorumAlgorithm).它的算法机理如下:
集群中各个节点需要心跳机制来通报彼此的"健康状态",假设每收到一个节点的"通报"代表一票。
关于三个节点的集群,正常运行时,每个节点都会有3票。
当结点A心跳显现故障但节点A还在运行,这时整个集群就会分裂成2个小的partition。
节点A是一个,剩下的2个是一个。
这是必须剔除一个partition才能保证集群的健康运行。
关于有3个节点的集群,A心跳显现问题后,B和C是一个partion,有2票,A只有1票。
按照投票算法,B和C组成的集群获得操纵权,A被剔除。
假如只有2个节点,投票算法就失效了。
因为每个节点上都只有1票。
这时就需要引入第三个设备:
QuorumDevice.QuorumDevice通常采纳饿是共享磁盘,那个磁盘也叫作Quorumdisk。
那个QuorumDisk也代表一票。
当2个结点的心跳显现问题时,2个节点同时去争取QuorumDisk这一票,最早到达的要求被最先满足。
故最先获得QuorumDisk的节点就获得2票。
另一个节点就会被剔除。
1.4IO隔离(Fencing)
当集群系统显现"脑裂"问题的时候,我们能够通过"投票算法"来解决谁获得集群操纵权的问题。
然而如此是不够的,我们还必须保证被赶出去的结点不能操作共享数据。
这确实是IOFencing要解决的问题。
IOFencing实现有硬件和软件2种方式:
软件方式:
关于支持SCSIReserve/Release命令的储备设备,能够用SG命令来实现。
正常的节点使用SCSIReserve命令"锁住"储备设备,故障节点发觉储备设备被锁住后,就明白自己被赶出了集群,也确实是说自己显现了专门情形,就要自己进行重启,以复原到正常状态。
那个机制也叫作Sicide(自杀).Sun和Veritas使用的确实是这种机制。
硬件方式:
STONITH(ShootTheOtherNodeintheHead),这种方式直截了当操作电源开关,当一个节点发生故障时,另一个节点假如能侦测到,就会通过串口发出命令,操纵故障节点的电源开关,通过临时断电,而又上电的方式使故障节点被重启动,这种方式需要硬件支持。
二RAC集群
2.1Clusterware
在单机环境下,Oracle是运行在OSKernel之上的。
OSKernel负责治理硬件设备,并提供硬件访问接口。
Oracle可不能直截了当操作硬件,而是有OSKernel代替它来完成对硬件的调用要求。
在集群环境下,储备设备是共享的。
OSKernel的设计差不多上针对单机的,只能操纵单机上多个进程间的访问。
假如还依靠OSKernel的服务,就无法保证多个主机间的和谐工作。
这时就需要引入额外的操纵机制,在RAC中,那个机制确实是位于Oracle和OSKernel之间的Clusterware,它会在OSKernel之前截获要求,然后和其他结点上的Clusterware协商,最终完成上层的要求。
在Oracle10G之前,RAC所需要的集群件依靠与硬件厂商,比如SUN,HP,Veritas.从Oracle10.1版本中,Oracle推出了自己的集群产品.ClusterReadyService(CRS),从此RAC不在依靠与任何厂商的集群软件。
在Oracle10.2版本中,那个产品改名为:
OracleClusterware。
因此我们能够看出,在整个RAC集群中,实际上有2个集群环境的存在,一个是由Clusterware软件组成的集群,另一个是由Database组成的集群。
2.2Clusterware组成
OracleCluster是一个单独的安装包,安装后,在每个结点上的OracleClusterware会自动启动。
OracleClusterware的运行环境由2个磁盘文件(OCR,VotingDisk),假设干进程和网络元素组成。
2.2.1磁盘文件:
Clusterware在运行期间需要两个文件:
OCR和VotingDisk.这2个文件必须存放在共享储备上。
OCR用于解决健忘问题,VotingDisk用于解决脑裂问题。
Oracle建议使用裸设备来存放这2个文件,每个文件创建一个裸设备,每个裸设备分配100M左右的空间就够了。
2.2.1.1OCR
健忘问题是由于每个节点都有配置信息的拷贝,修改节点的配置信息不同步引起的。
Oracle采纳的解决方法确实是把那个配置文件放在共享的储备上,那个文件确实是OCRDisk。
OCR中储存整个集群的配置信息,配置信息以"Key-Value"的形式储存其中。
在Oracle10g往常,那个文件叫作ServerManageabilityRepository(SRVM).在Oracle10g,这部分内容被重新设计,并重名为OCR.在OracleClusterware安装的过程中,安装程序会提示用户指定OCR位置。
同时用户指定的那个位置会被记录在/etc/oracle/ocr.Loc(LinuxSystem)或者/var/opt/oracle/ocr.Loc(SolarisSystem)文件中。
而在Oracle9iRAC中,对等的是srvConfig.Loc文件。
OracleClusterware在启动时会依照那个地点面的内容从指定位置读入OCR内容。
1).OCRkey
整个OCR的信息是树形结构,有3个大分支。
分别是SYSTEM,DATABASE和CRS。
每个分支下面又有许多小分支。
这些记录的信息只能由root用户修改。
2)OCRprocess
OracleClusterware在OCR中存放集群配置信息,故OCR的内容专门的重要,所有对OCR的操作必须确保OCR内容完整性,因此在ORACLEClusterware运行过程中,并不是所有结点都能操作OCRDisk.
在每个节点的内存中都有一份OCR内容的拷贝,这份拷贝叫作OCRCache。
每个结点都有一个OCRProcess来读写OCRCache,但只有一个节点的OCRprocess能读写OCRDisk中的内容,那个节点叫作OCRMaster结点。
那个节点的OCRprocess负责更新本地和其他结点的OCRCache内容。
所有需要OCR内容的其他进程,比如OCSSD,EVM等都叫作ClientProcess,这些进程可不能直截了当访问OCRCache,而是像OCRProcess发送要求,借助OCRProcess获得内容,假如想要修改OCR内容,也要由该节点的OCRProcess像Masternode的OCRprocess提交申请,由MasterOCRProcess完成物理读写,并同步所有节点OCRCache中的内容。
2.2.1.2VotingDisk
VotingDisk那个文件要紧用于记录节点成员状态,在显现脑裂时,决定那个Partion获得操纵权,其他的Partion必须从集群中剔除。
在安装Clusterware时也会提示指定那个位置。
安装完成后能够通过如下命令来查看VotingDisk位置。
$Crsctlquerycssvotedisk
2.2.2Clusterware后台进程
Clusterware由假设干进程组成,其中最重要的3个是:
CRSD,CSSD,EVMD.在安装clusterware的最后时期,会要求在每个节点执行root.sh脚本,那个脚本会在/etc/inittab文件的最后把这3个进程加入启动项,如此以后每次系统启动时,Clusterware也会自动启动,其中EVMD和CRSD两个进程假如显现专门,那么系统会自动重启这两个进程,假如是CSSD进程专门,系统会赶忙重启。
1).OCSSD
OCSSD那个进程是Clusterware最关键的进程,假如那个进程显现专门,会导致系统重启,那个进程提供CSS(ClusterSynchronizationService)服务。
CSS服务通过多种心跳机制实时监控集群状态,提供脑裂爱护等基础集群服务功能。
CSS服务有2种心跳机制:
一种是通过私有网络的NetworkHeartbeat,另一种是通过VotingDisk的DiskHeartbeat.
这2种心跳都有最大延时,关于DiskHeartbeat,那个延时叫作IOT(I/OTimeout);关于NetworkHeartbeat,那个延时叫MC(Misscount)。
这2个参数都以秒为单位,缺省时IOT大于MC,在默认情形下,这2个参数是Oracle自动判定的,同时不建议调整。
能够通过如下命令来查看参数值:
$crsctlgetcssdisktimeout
$crsctlgetcssmisscount
注:
除了Clusterware需要那个进程,在单节点环境中假如使用了ASM,也需要那个进程;那个进程用于支持ASMInstance和RDBMSInstance之间的通信。
假如在使用了ASM的节点上安装RAC,会遇到一个问题:
RAC节点要求只有一个OCSSD进程,同时应该是运行$CRS_HOME名目下的,这时就需要先停止ASM,并通过$ORACLE_HOME/bin/localcfig.Shdelete删除之前的inittab条目。
之前安装ASM时,也使用那个脚本来启动OCSSD:
$ORACLE_HOME/bin/localconfig.Shadd.
2).CRSD
CRSD是实现"高可用性(HA)"的要紧进程,它提供的服务叫作CRS(ClusterReadyService)服务。
OracleClusterware是位于集群层的组件,它要为应用层资源(CRSResource)提供"高可用性服务",因此,OracleClusterware必须监控这些资源,并在这些资源运行专门时进行干预,包括关闭,重启进程或者转移服务。
CRSD进程提供的确实是这些服务。
所有需要高可用性的组件,都会在安装配置的时候,以CRSResource的形式登记到OCR中,而CRSD进程确实是依照OCR中的内容,决定监控哪些进程,如何监控,显现问题时又如何解决。
也确实是说,CRSD进程负责监控CRSResource的运行状态,并要启动,停止,监控,Failover这些资源。
默认情形下,CRS会自动尝试重启资源5次,假如依旧失败,那么舍弃尝试。
CRSResource包括GSD(GlobalServeiceDaemon),ONS(OracleNotificationService),VIP,Database,Instance和Service.这些资源被分成2类:
GSD,ONS,VIP和Listener属于Noteapps类
Database,Instance和Service属于Database-RelatedResource类。
我们能够如此明白得:
Nodeapps确实是说每个节点只需要一个就够了,比如每个节点只有一个Listener,而Database-RelatedResource确实是说这些资源和数据库有关,不受节点的限制,比如一个节点能够有多个实例,每个实例能够有多个Service。
GSD,ONS,VIP这3个服务是在安装Clusterware的最后,执行VIPCA时创建并登记到OCR中的。
而Database,Listener,Instance和Service是在各自的配置过程中自动或者手动登记到OCR中的。
3).EVMD
EVMD那个进程负责公布CRS产生的各种事件(Event).这些Event能够通过2种方式公布给客户:
ONS和CalloutScript.用户能够自定义回调脚本,放在特定的名目下,如此当有某些事件发生时,EVMD会自动扫描该名目,并调用用户的脚本,这种调用是通过racgevt进程来完成的。
EVMD进程除了复杂公布事件之外,它依旧CRSD和CSSD两个进程之间的桥梁。
CRS和CSS两个服务之前的通信确实是通过EVMD进程完成的。
4).RACGIMON
RACGIMON那个进程负责检查数据库健康状态,负责Service的启动,停止,故障转移(Failover)。
那个进程会建立到数据库的持久连接,定期检查SGA中的特定信息,该信息由PMON进程定时更新。
5).OPROCD
OPROCD那个进程也叫作ProcessMonitorDaemon.假如在非Linux平台上,同时没有使用第三方的集群软件时,就会看到那个进程。
那个进程用来检查节点的ProcessorHang(CPU挂起),假如调度时刻超过1.5秒,就会认为CPU工作专门,会重启节点。
也确实是说那个进程提供"IO隔离"的功能。
从其在Windows平台上的服务名:
OraFnceService也能够看出它的功能。
而在Linux平台上,是利用Hangcheck-timer模块来实现"IO隔离"的。
2.3VIP原理和特点
Oracle的TAF确实是建立在VIP技术之上的。
IP和VIP区别在与:
IP是利用TCP层超时,VIP利用的是应用层的赶忙响应。
VIP它是浮动的IP.当一个节点显现问题时会自动的转到另一个节点上。
假设有一个2个节点的RAC,正常运行时每个节点上都有一个VIP。
VIP1和VIP2.当节点2发生故障,比如专门关系。
RAC会做如下操作:
1).CRS在检测到rac2节点专门后,会触发Clusterware重构,最后把rac2节点剔除集群,由节点1组成新的集群。
2).RAC的Failover机制会把节点2的VIP转移到节点1上,这时节点1的PUBLIC网卡上就有3个IP地址:
VIP1,VIP2,PUBLICIP1.
3).用户对VIP2的连接要求会被IP层路由转到节点1
4).因为在节点1上有VIP2的地址,所有数据包会顺利通过路由层,网络层,传输层。
5).然而,节点1上只监听VIP1和publicIP1的两个IP地址。
并没有监听VIP2,故应用层没有对应的程序接收那个数据包,那个错误赶忙被捕捉。
6).客户段能够赶忙接收到那个错误,然后客户段会重新发起向VIP1的连接要求。
VIP特点:
1).VIP是通过VIPCA脚本创建的
2).VIP作为Nodeapps类型的CRSResource注册到OCR中,并由CRS爱护状态。
3).VIP会绑定到节点的public网卡上,故public网卡有2个地址。
4).当某个节点发生故障时,CRS会把故障节点的VIP转移到其他节点上。
5).每个节点的Listener会同时监听public网卡上的publicip和VIP
6).客户端的tnsnames.Ora一样会配置指向节点的VIP.
2.4Clusterware的日志体系
OracleClusterware的辅助诊断,只能从log和trace进行。
而且它的日志体系比较复杂。
alert.log:
$ORA_CRS_HOME\log\hostname\alert.Log,这是首选的查看文件。
Clusterware后台进程日志:
crsd.Log:
$ORA_CRS_HOME\log\hostname\crsd\crsd.Log
ocssd.Log:
$ORA_CRS_HOME\log\hostname\cssd\ocsd.Log
evmd.Log:
$ORA_CRS_HOME\log\hostname\evmd\evmd.Log
Nodeapp日志位置:
$ORA_CRS_HOME\log\hostname\racg\
那个地点面放的是nodeapp的日志,包括ONS和VIP,比如:
ora.Rac1.ons.Log
工具执行日志:
$ORA_CRS_HOME\log\hostname\client\
Clusterware提供了许多命令行工具:
比如ocrcheck,ocrconfig,ocrdump,oifcfg和clscfg,这些工具产生的日志就放在那个名目下
还有$ORACLE_HOME\log\hostname\client\和
$ORACLE_HOME\log\hostname\racg也有相关的日志。
一.RAC并发
RAC的本质是一个数据库,运行在多台运算机上的数据库,它的要紧任务是数据库确实是事务处理,它通过DistributedLockManagement(DLM:
分布式锁治理器)来解决并发问题。
因为RAC的资源是共享的,为了保证数据的一致性,就需要使用DLM来和谐实例间对资源的竞争访问。
RAC的DLM就叫作CacheFusion。
在DLM中,依照资源数量,活动密集程度,把资源分成两类:
CacheFusion和Non-CacheFusion。
CacheFusionResource指数据块这种资源,包括一般数据库,索引数据库,段头块(SegmentHeader),undo数据库。
Non-CacheFusionResource是所有的非数据库块资源,包括数据文件,操纵文件,数据字典,LibraryCache,sharePool的RowCache等。
RowCache中存放的是数据字典,它的目的是在编译过程中减少对磁盘的访问。
在CacheFusion中,每一个数据块都被映射成一个CacheFusion资源,CacheFusion资源实际确实是一个数据结构,资源的名称确实是数据块地址〔DBA〕。
每个数据要求动作差不多上分步完成的。
第一把数据块地址X转换成CacheFusion资源名称,然后把那个CacheFusion资源要求提交给DLM,DLM进行GlobalLock的申请,开释活动,只有进程获得了PCMLock才能连续下一步,即:
实例要获得数据块的使用权。
CacheFusion要解决的首要问题确实是:
数据块拷贝在集群节点间的状态分布图,这是通过GRD实现的。
GRD〔GlobalResourceDirectory〕
能够把GRD看作一个内部数据库,那个地点记录的是每一个数据块在集群间的分布图,它位于每一个实例的SGA中,然而每个实例SGA中差不多上部分GRD,所有实例的GRD汇总在一起确实是一个完整的GRD。
RAC会依照每个资源的名称从集群中选择一个节点作为它的MasterNode,而其他节点叫作ShadowNode。
MasterNode的GRD中记录了该资源在所有节点上的使用信息,而ShadowNode的GRD中只需要记录资源在该节点上的使用情形,这些信息实际确实是PCMLock信息。
PCMLock有3个属性:
Mode,Role和PI(PastImage)
二.RAC架构
2.1SGA的变化
和传统的单实例相比,RACInsance的SGA最显著的变化确实是多了一个GRD部分。
Oracle中的数据操作差不多上在内存的SGA区完成的,和传统的单实例不同,RAC是有多个,每个数据块能够在任何一个Instance的SGA中都有拷贝,RAC必须明白这些拷贝的分布版本,状态,而GRD确实是这些信息的内存区。
GRD尽管位于SGA中,然而不像BufferCache或者Logbuffer等SGA组件,有明确的参数来对应,每个节点中都只有部分GRD内容,所有的节点合在一起才构成完整的GRD.
2.2后台进程的变化
每个RAC的实例和传统的单实例一样,都有DBWR,LGWR,ARCn,CKPT这些后台进程,除了这些进程外,每个实例还增加了假设干RAC特有的进程,要注意的是,这些进程名称和进程提供的服务名称差异专门大,比如LMS进程提供的是GCS服务,专门不便与经历,造成这种现象的缘故是进程名称从9i之前的OPS〔RAC前身〕连续下来的,然而服务却差不多在RAC中重新设计并命名。
2.2.1LMSn
那个进程是CacheFusion的要紧进程,负责数据块在实例间的传递,对应的服务叫作GCS(GlobalCacheService),那个进程的名称来源与LockManagerService。
从Oracle9开始,Oracle对那个服务重新命名成GlobalCacheSErvice,然而进程名字确没有调整。
那个进程的数量是通过参数GCS_SERVER_PROCESSES来操纵,缺省值是2个,取值范畴为0-9.
2.2.2LMD
那个进程负责的是GlobalEnqueueService〔GES〕,具体来说,那个进程负责在多个实例之间和谐对数据块的访问顺序,保证数据的一致性访问。
它和LMSn进程的GCS服务还有GRD共同构成RAC最核心的功能CacheFusion。
2.2.3LCK
那个进程负责Non-CacheFusion资源的同步访问,每个实例有一个LCK进程
2.2.4LMON
各个实例的LMON进程会定期通信,以检查集群中各个节点的健康状态,当某个节点显现故障时,负责集群重构,GRD复原等操作,它提供的服务叫作:
ClusterGroupServices〔CGS〕。
LMON要紧借助两种心跳机制来完成健康检查:
1〕节点间的网络心跳〔NetworkHeartbeat〕:
能够想象陈节点间定时的发送ping包检测节点状态,假如能在规定时刻内收到回应,就认为对方状态正常
2〕通过操纵文件的磁盘心跳〔ControlfileHeartbeat〕:
每个节点的CKPT进程每隔3秒更新一次操纵文件一个数据块,那个数据块叫作CheckpointProgressRecord
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Oracle RAC 深度解释 深度 解释
![提示](https://static.bingdoc.com/images/bang_tan.gif)