RAC 11.2.0.2 graceful shutdown
Новой возможностью в RAC 11.2.0.2 является так называемый graceful shutdown, когда узел кластера не уходит в reboot, а при устранении проблемы быстренько поднимает ресурсы обратно. Как вы знаете, потеря interconnect является примером ситуации, вызывавшей reboot в RAC до версии 11.2.0.2, вне зависимости от доступности voting дисков. Давайте посмотрим как это работает теперь в 11.2.0.2
Итак у нас есть двух узловой кластер Oracle RAC на IBM AIX 7.1. Узлы кластера называются vs-ora00-01a и vs-ora00-01b. Из узла vs-ora00-01b мы выдернули все сетевые кабели интерконнект соединения примерно в 12:07. После чего немедленно увидели, что узел 01a выкинул узел 01b из кластера:
В то же самое время экземпляр на узле 01a произвел реконфигурацию:
Но самое интересное вас ждет в логах узла 01b
tail -f /u01/grid/log/vs-ora00-01b/crsd/crsd.log
[cssd(8519870)]CRS-1609:This node is unable to communicate with other nodes in the cluster and is going down to preserve cluster integrity; details at (:CSSNM00008:) in /u01/gri
d/log/vs-ora00-01b/cssd/ocssd.log.
2011-09-09 12:07:22.338
[cssd(8519870)]CRS-1656:The CSS daemon is terminating due to a fatal error; Details at (:CSSSC00012:) in /u01/grid/log/vs-ora00-01b/cssd/ocssd.log
2011-09-09 12:07:22.461
[cssd(8519870)]CRS-1608:This node was evicted by node 1, vs-ora00-01a; details at (:CSSNM00005:) in /u01/grid/log/vs-ora00-01b/cssd/ocssd.log.
2011-09-09 12:07:22.479
[cssd(8519870)]CRS-1652:Starting clean up of CRSD resources.
В тоже самое время в ocssd.log
tail -f ./vs-ora00-01b/cssd/ocssd.log
2011-09-09 12:07:25.531: [ CSSD][1029]clssgmClientShutdown: total iocapables 0
2011-09-09 12:07:25.531: [ CSSD][1029]clssgmClientShutdown: graceful shutdown completed.
2011-09-09 12:07:25.531: [ CSSD][1029]clssnmSendManualShut: Notifying all nodes that this node has been manually shut down
2011-09-09 12:07:25.531: [ CSSD][3091]clssnmrCheckEDFenceStatus: Node vs-ora00-01b, number 2, EXADATA fence handle 1 has status 1, status request return code ORA-0
(не обращайте внимания на слово Exadata - мы по прежнему на IBM AIX -))
В это же время остановился экземпляр, как легко видеть потому что потерял связь с ASM:
Fri Sep 09 12:07:25 2011
NOTE: ASMB terminating
Errors in file /u01/app/oracle/diag/rdbms/skdbse/skdbse2/trace/skdbse2_asmb_13500572.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Process ID:
Session ID: 466 Serial number: 3
Errors in file /u01/app/oracle/diag/rdbms/skdbse/skdbse2/trace/skdbse2_asmb_13500572.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Process ID:
Session ID: 466 Serial number: 3
ASMB (ospid: 13500572): terminating the instance due to error 15064
Instance terminated by ASMB, pid = 13500572
На этом - все. Узел не перегружается. Смотрим что происходит дальше
Через буквально минуту в логе начинают появляться сообщения cssd демон перегружается и в логе начинают появляться сообщения что у системы все еще нет interconnect.
2011-09-09 12:10:46.822: [ CSSD][2577]clssnmvDHBValidateNCopy: node 1, vs-ora00-01a has a disk HB, but no network HB, , DHB has rcfg 209399966, wrtcnt, 1609564, LATS 632310336
, lastSeqNo 1609563, uniqueness 1315500768, timestamp 1315555846/782244784
Выждав пару минут мы втыкаем кабели обратно и наш кластер это немедленно чувствует:
2011-09-09 12:10:49.224: [GIPCHALO][1543] gipchaLowerProcessAcks: ESTABLISH finished for node 111a91bd0 { host 'vs-ora00-01a', haName 'CSS_vs-ora-cluster', srcLuid 9e33405f-1cd6
333f, dstLuid 6115cc51-2d011204 numInf 1, contigSeq 1, lastAck 185, lastValidAck 1, sendSeq [187 : 187], createTime 632125984, sentRegister 1, localMonitor 1, flags 0x20c }
Далее стартуют кластерные демоны:
tailf -f /u01/grid/log/vs-ora00-01b/crsd/crsd.log
2011-09-09 12:11:13.322
[crsd(8650808)]CRS-1012:The OCR service started on node vs-ora00-01b.
2011-09-09 12:11:13.428
[evmd(16121970)]CRS-1401:EVMD started on node vs-ora00-01b.
2011-09-09 12:11:15.573
[crsd(8650808)]CRS-1201:CRSD started on node vs-ora00-01b.
2011-09-09 12:11:17.748
И затем поднимается база данных:
Fri Sep 09 12:11:27 2011
Starting ORACLE instance (normal)
PS Имейте пожалуйста в виду, что для того чтобы данный тест прошел нам пришлось обновить систему до последнего на момент написания поста GI PSU 11.2.0.2.3.
Итак у нас есть двух узловой кластер Oracle RAC на IBM AIX 7.1. Узлы кластера называются vs-ora00-01a и vs-ora00-01b. Из узла vs-ora00-01b мы выдернули все сетевые кабели интерконнект соединения примерно в 12:07. После чего немедленно увидели, что узел 01a выкинул узел 01b из кластера:
tail -f /u01/grid/log/vs-ora00-01a/alertvs-ora00-01a.log
2011-09-09 12:07:08.022
[cssd(8192004)]CRS-1612:Network communication with node vs-ora00-01b (2) missing for 50% of timeout interval. Removal of this node from cluster in 14.385 seconds
2011-09-09 12:07:15.024
[cssd(8192004)]CRS-1611:Network communication with node vs-ora00-01b (2) missing for 75% of timeout interval. Removal of this node from cluster in 7.384 seconds
2011-09-09 12:07:20.026
[cssd(8192004)]CRS-1610:Network communication with node vs-ora00-01b (2) missing for 90% of timeout interval. Removal of this node from cluster in 2.382 seconds
2011-09-09 12:07:22.412
[cssd(8192004)]CRS-1607:Node vs-ora00-01b is being evicted in cluster incarnation 209399965; details at (:CSSNM00007:) in /u01/grid/log/vs-ora00-01a/cssd/ocssd.log.
2011-09-09 12:07:26.419
[cssd(8192004)]CRS-1625:Node vs-ora00-01b, number 2, was manually shut down
2011-09-09 12:07:26.426
[cssd(8192004)]CRS-1601:CSSD Reconfiguration complete. Active nodes are vs-ora00-01a .
2011-09-09 12:07:26.491
[crsd(10682442)]CRS-5504:Node down event reported for node 'vs-ora00-01b'.
2011-09-09 12:07:30.123
[crsd(10682442)]CRS-2773:Server 'vs-ora00-01b' has been removed from pool 'Generic'.
2011-09-09 12:07:30.123
[crsd(10682442)]CRS-2773:Server 'vs-ora00-01b' has been removed from pool 'ora.skdbse'.
В то же самое время экземпляр на узле 01a произвел реконфигурацию:
Fri Sep 09 12:07:27 2011
Reconfiguration started (old inc 4, new inc 6)
List of instances:
1 (myinst: 1)
Global Resource Directory frozen
* dead instance detected - domain 0 invalid = TRUE
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
Fri Sep 09 12:07:27 2011
Fri Sep 09 12:07:27 2011
LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
LMS 2: 0 GCS shadows cancelled, 0 closed, 0 Xw survived
Fri Sep 09 12:07:27 2011
LMS 0: 1 GCS shadows cancelled, 1 closed, 0 Xw survived
Set master node info
Submitted all remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
Post SMON to start 1st pass IR
Fri Sep 09 12:07:27 2011
Но самое интересное вас ждет в логах узла 01b
tail -f /u01/grid/log/vs-ora00-01b/crsd/crsd.log
[cssd(8519870)]CRS-1609:This node is unable to communicate with other nodes in the cluster and is going down to preserve cluster integrity; details at (:CSSNM00008:) in /u01/gri
d/log/vs-ora00-01b/cssd/ocssd.log.
2011-09-09 12:07:22.338
[cssd(8519870)]CRS-1656:The CSS daemon is terminating due to a fatal error; Details at (:CSSSC00012:) in /u01/grid/log/vs-ora00-01b/cssd/ocssd.log
2011-09-09 12:07:22.461
[cssd(8519870)]CRS-1608:This node was evicted by node 1, vs-ora00-01a; details at (:CSSNM00005:) in /u01/grid/log/vs-ora00-01b/cssd/ocssd.log.
2011-09-09 12:07:22.479
[cssd(8519870)]CRS-1652:Starting clean up of CRSD resources.
В тоже самое время в ocssd.log
tail -f ./vs-ora00-01b/cssd/ocssd.log
2011-09-09 12:07:25.531: [ CSSD][1029]clssgmClientShutdown: total iocapables 0
2011-09-09 12:07:25.531: [ CSSD][1029]clssgmClientShutdown: graceful shutdown completed.
2011-09-09 12:07:25.531: [ CSSD][1029]clssnmSendManualShut: Notifying all nodes that this node has been manually shut down
2011-09-09 12:07:25.531: [ CSSD][3091]clssnmrCheckEDFenceStatus: Node vs-ora00-01b, number 2, EXADATA fence handle 1 has status 1, status request return code ORA-0
(не обращайте внимания на слово Exadata - мы по прежнему на IBM AIX -))
В это же время остановился экземпляр, как легко видеть потому что потерял связь с ASM:
Fri Sep 09 12:07:25 2011
NOTE: ASMB terminating
Errors in file /u01/app/oracle/diag/rdbms/skdbse/skdbse2/trace/skdbse2_asmb_13500572.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Process ID:
Session ID: 466 Serial number: 3
Errors in file /u01/app/oracle/diag/rdbms/skdbse/skdbse2/trace/skdbse2_asmb_13500572.trc:
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
Process ID:
Session ID: 466 Serial number: 3
ASMB (ospid: 13500572): terminating the instance due to error 15064
Instance terminated by ASMB, pid = 13500572
На этом - все. Узел не перегружается. Смотрим что происходит дальше
Через буквально минуту в логе начинают появляться сообщения cssd демон перегружается и в логе начинают появляться сообщения что у системы все еще нет interconnect.
2011-09-09 12:10:46.822: [ CSSD][2577]clssnmvDHBValidateNCopy: node 1, vs-ora00-01a has a disk HB, but no network HB, , DHB has rcfg 209399966, wrtcnt, 1609564, LATS 632310336
, lastSeqNo 1609563, uniqueness 1315500768, timestamp 1315555846/782244784
Выждав пару минут мы втыкаем кабели обратно и наш кластер это немедленно чувствует:
2011-09-09 12:10:49.224: [GIPCHALO][1543] gipchaLowerProcessAcks: ESTABLISH finished for node 111a91bd0 { host 'vs-ora00-01a', haName 'CSS_vs-ora-cluster', srcLuid 9e33405f-1cd6
333f, dstLuid 6115cc51-2d011204 numInf 1, contigSeq 1, lastAck 185, lastValidAck 1, sendSeq [187 : 187], createTime 632125984, sentRegister 1, localMonitor 1, flags 0x20c }
Далее стартуют кластерные демоны:
tailf -f /u01/grid/log/vs-ora00-01b/crsd/crsd.log
2011-09-09 12:11:13.322
[crsd(8650808)]CRS-1012:The OCR service started on node vs-ora00-01b.
2011-09-09 12:11:13.428
[evmd(16121970)]CRS-1401:EVMD started on node vs-ora00-01b.
2011-09-09 12:11:15.573
[crsd(8650808)]CRS-1201:CRSD started on node vs-ora00-01b.
2011-09-09 12:11:17.748
И затем поднимается база данных:
Fri Sep 09 12:11:27 2011
Starting ORACLE instance (normal)
PS Имейте пожалуйста в виду, что для того чтобы данный тест прошел нам пришлось обновить систему до последнего на момент написания поста GI PSU 11.2.0.2.3.
Комментариев нет:
Отправить комментарий