service的起停,要看START_DEPENDENCIES和STOP_DEPENDENCIES:
我们用如下命令建立一个service:
1 |
srvctl add service -d ora11g -s srv_di_1 -r node1 -a node2 -P basic -e SELECT -m basic -z 180 -w 5 |
我们具体看看这个service情况:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
[oracle@rac1 ~]$ crsctl stat res ora.ora11g.srv_di_1.svc -p NAME=ora.ora11g.srv_di_1.svc TYPE=ora.service.type ACL=owner:oracle:rwx,pgrp:oinstall:r--,other::r--,group:dba:r-x,group:oinstall:r-x,user:oracle:r-x ACTION_FAILURE_TEMPLATE= ACTION_SCRIPT= ACTIVE_PLACEMENT=1 AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX% AGENT_PARAMETERS= AQ_HA_NOTIFICATION=0 AUTO_START=restore CARDINALITY=1 CHECK_INTERVAL=600 CHECK_TIMEOUT=30 CLB_GOAL=LONG DEFAULT_TEMPLATE=PROPERTY(RESOURCE_CLASS=service) PROPERTY(SERVICE_NAME=%GEN_SERVICE_NAME%) PROPERTY(DB_UNIQUE_NAME=CONCAT(PARSE(%NAME%, ., 2), STAT(ora.ora11g.db, USR_ORA_DOMAIN), .)) ELEMENT(INSTANCE_NAME=STAT(ora.ora11g.db, GEN_USR_ORA_INST_NAME)) DEGREE=1 DESCRIPTION=Oracle Service resource DTP=0 EDITION= ENABLED=1 FAILOVER_DELAY=5 FAILOVER_METHOD=BASIC FAILOVER_RETRIES=180 FAILOVER_TYPE=SELECT FAILURE_INTERVAL=0 FAILURE_THRESHOLD=0 GEN_SERVICE_NAME=srv_di_1 HOSTING_MEMBERS= LOAD=1 LOGGING_LEVEL=1 MANAGEMENT_POLICY=AUTOMATIC NLS_LANG= NOT_RESTARTING_TEMPLATE= OFFLINE_CHECK_INTERVAL=0 PLACEMENT=restricted PROFILE_CHANGE_TEMPLATE= RESTART_ATTEMPTS=0 RLB_GOAL=NONE ROLE=PRIMARY SCRIPT_TIMEOUT=60 SERVER_POOLS=ora.ora11g_srv_di_1 SERVICE_NAME=srv_di_1 START_DEPENDENCIES=hard(ora.ora11g.db,type:ora.cluster_vip_net1.type) weak(type:ora.listener.type) pullup(type:ora.cluster_vip_net1.type) pullup:always(ora.ora11g.db) START_TIMEOUT=600 STATE_CHANGE_TEMPLATE= STOP_DEPENDENCIES=hard(intermediate:ora.ora11g.db,type:ora.cluster_vip_net1.type) STOP_TIMEOUT=600 TAF_POLICY=BASIC TYPE_VERSION=2.2 UPTIME_THRESHOLD=1h USR_ORA_DISCONNECT=false USR_ORA_ENV= USR_ORA_FLAGS= USR_ORA_OPEN_MODE= USR_ORA_OPI=false USR_ORA_STOP_MODE= VERSION=11.2.0.4.0 [oracle@rac1 ~]$ |
可以看到,
(1)start的依赖:
硬依赖于DB是否启动和VIP类型的资源是否启动,
弱依赖于listener是否启动,
尝试重启在VIP资源已经online的情况下,
不管DB如何状态下,尝试重启。
(2)stop的依赖:
硬依赖,如果资源要保持启动的情况,必须DBd资源在intermedia的中间状态或者online状态,和VIP类型的资源online状态
注:start和stop的依赖关系的详细解释,参考这里的在线文档
所以我们讨论如下3种场景:
1 2 3 4 5 6 7 8 9 |
1. srvctl 来起停数据库 1.1 srvctl stop instance on node1 service stop on node1, not startup on node2 1.2 srvctl start instance on node1 service start on node 1 用srvctl停数据库,在crsctl stat res -t中看到数据库资源的offline的。不符合service start的条件硬依赖db资源必须online。所以在节点1上的service停了。 但是如果按照pullup的条件,资源会在节点2被拉起,此时没有被拉起,是因为11.2.0.2之后的srvctl stop instance多了一个-f的参数,只有指定这个参数停instance,service才会漂移到另一个节点上。参考下面2个文档: 11gR2 RAC Service Not Failing Over To Other Node When Instance Is Shut Down (Doc ID 1324574.1) How to failover a service during instance shutdown using srvctl (Doc ID 1520454.1) |
1 2 3 4 5 6 7 8 |
2. sqlplus 2.1 sqlplus shutdown immediate on node1 service relocate to node2 2.2 sqlplus startup on node1 service still running node2, need manual relocate the service 用sqlplus停数据库,在crsctl stat res -t中看到数据库资源的offline的。不符合service start的条件硬依赖db资源必须online。所以在节点1上的service停了。 按照pullup的条件,资源在节点2被拉起。 节点1再次被sqlplus拉起,但是由于service在节点2上不满足stop依赖,所以无法自动的漂移到重启启动的节点1上。 |
1 2 3 4 5 6 7 8 |
3. kill 3.1 kill db pmon process on node1 service relocate to node2 3.2 db instance restart by cluster service still running node2, need manual relocate the service 用kill停数据库,在crsctl stat res -t中看到数据库资源的target是online的。但是state有一段时间变成offline,不符合service start的条件硬依赖db资源必须online。所以在节点1上的service停了。 按照pullup的条件,资源在节点2被拉起。 由于节点1上db的target是online,符合pullup的条件,所以db被自动拉起。但是由于service在节点2上不满足stop依赖,所以无法自动的漂移到重启启动的节点1上。 |
一条评论