Съвсем наскоро се опитвах да приложа най-новата и най-добрата актуализация на комплекта за корекции (PSU) към система Oracle RAC с 2 възела. Всичко мина гладко на първия възел. Имах проблеми, когато се опитвах да приложа PSU към втория възел. Проблемът не беше в OPatch или PSU, а по-скоро не можах дори да сваля успешно Grid Infrastructure (GI). И за да влоши нещата, това също нямаше да се появи.
Проследих проблема си до Grid Inter Process Communication Daemon (gipcd) При издаване на „crsctl stop crs“, получих съобщение, че gipcd не може да бъде успешно прекратен. При стартиране на GI стартирането стигна до опит да стартира gipcd и след това се отказа. Намерих много полезни статии за моята поддръжка на Oracle (MOS) и с Google търсения. Много от тези документи изглеждаха добре с моя проблем, но не можах успешно да върна GI обратно и да работи. Рестартирането на възела също не помогна. Останалата част от тази статия може да ви помогне, дори ако проблемът ви не е с gipcd, това беше само точката на пречка за мен.
Така че в този момент трябваше да взема решение. Мога да подам заявка за услуга (SR) на MOS. Или мога да „възстановя“ този възел в клъстера. Знаех, че ако подам SR, ще имам късмет възелът да работи по всяко време през следващата седмица. Не исках да чакам толкова дълго и ако това беше производствена система, не бих могъл да чакам толкова дълго. Затова реших да възстановя възела. Тази публикация в блога ще описва подробно стъпките, които предприех. На високо ниво става дума за това:
- Премахнете възела от клъстера
- Почистете всички остатъци от GI и RDBMS на този възел.
- Добавете възела обратно към клъстера.
- Добавете екземпляра и услугата за новия възел.
- Стартирайте екземпляра.
В случай, че има значение, тази система е Oracle 12.1.0.2 (както GI, така и RDBMS), работеща на Oracle Linux 7. В моя пример host01 е „добрият“ възел, а host02 е „лошият“ възел. Името на базата данни е „orcl“. Където е възможно, моята команда ще има подкана, указващ възела, от който изпълнявам тази команда.
Първо, ще премахна лошия възел от клъстера.
Започвам с премахване на софтуера на RDBMS от инвентара на добрия възел.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 След това премахвам GI софтуера от инвентара.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Сега ще премахна този възел от клъстерния регистър.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
Премахнете VIP.
[root@host01]# srvctl config vip -node host02 VIP exists: network number 1, hosting node host02 VIP Name: host02-vip VIP IPv4 Address: 192.168.1.101 VIP IPv6 Address: VIP is enabled. VIP is individually enabled on nodes: VIP is individually disabled on nodes: [root@host01]# srvctl stop vip -vip host02-vip -force [root@host01]# srvctl remove vip -vip host02-vip Please confirm that you intend to remove the VIPs host02-vip (y/[n]) y
След това премахнете екземпляра.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
В този момент лошият възел вече не е част от клъстера от гледна точка на добрия възел.
След това ще премина към лошия възел и ще премахна софтуера и ще почистя някои конфигурационни файлове.
[oracle@host02]$ rm -rf /u01/app/oracle/product/12.1.0.2/ [root@host02 ~]# rm -rf /u01/grid/crs12.1.0.2/* [root@host02 ~]# rm /var/tmp/.oracle/* [oracle@host02]$ /tmp]$ rm -rf /tmp/* [root@host02]# rm /etc/oracle/ocr* [root@host02]# rm /etc/oracle/olr* [root@host02]# rm -rf /pkg/oracle/app/oraInventory [root@host02]# rm -rf /etc/oracle/scls_scr
Взех лесния изход и просто използвах „rm“, за да премахна домашния софтуер за RDBMS и Grid. Сега всички неща са изчистени. Добрият възел смята, че е част от клъстер с един възел, а лошият възел дори не знае за клъстера. След това ще добавя този възел обратно към клъстера. Ще използвам помощната програма addnode на host01.
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" Това ще клонира дома на GI от host01 към host02. Накрая получавам подкана да стартирам root.sh на host02. Изпълнението на този скрипт ще свърже GI с OCR и дисковете за гласуване и ще изведе клъстерния стек. Трябва обаче да изпълня още една процедура за почистване като root на host02, преди да мога да продължа.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
Възможно е да съм пуснал горното по-рано при почистване на възела. Но това е мястото, където го изпълних в този момент. Сега стартирам скрипта root.sh, както поискам.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
В този момент host02 вече е част от клъстера и GI работи и работи. Проверявам с “crs_stat -t” и “olsnodes -n”. Проверявам и VIP.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Сега отново на host01, време е да клонирате софтуера на RDBMS.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" Това ще стартира OUI. Разходете се през съветника, за да завършите процеса на клониране.
Сега ще добавя екземпляра обратно към този възел.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Ако всичко е минало добре, екземплярът ще стартира веднага.
[oracle@host01]$ srvctl start instance -db orcl -instance orcl2
[oracle@host01]$ srvctl status database -d orcl Instance orcl1 is running on node host01 Instance orcl2 is running on node host02
SQL> select inst_id,status from gv$instance;
INST_ID STATUS ---------- ------------ 1 OPEN 2 OPEN
Страхотно! Всичко, което остава, е да преконфигурирате и стартирате всички необходими услуги. Имам един.
srvctl modify service -db orcl -service hr_svc -modifyconfig -preferred "orcl1,orcl2"
srvctl start service -db orcl -service hr_svc -node host02
srvctl status service -db orcl
Това е. Вече имам всичко работещо.
Надяваме се, че тази публикация в блога е показала колко лесно е да извадите „лош“ възел от клъстера и да го добавите обратно. Целият този процес ми отне около 2 часа. Много по-бързо от всяка разделителна способност, която някога съм получавал от MOS.
Никога не стигнах до основната причина за първоначалния ми проблем. Изваждането на възела от клъстера и добавянето му обратно ме върна и работех. Този процес няма да работи, ако основната причина за проблема ми е свързана с хардуера или ОС.
И най-добрата част за мен във всичко това? Тъй като host01 вече е използвал PSU, както в GI, така и в RDBMS домове, клонирането им към host02 означава, че не е трябвало да стартирам OPatch на host02. Този хост получи пластира за PSU. Всичко, което трябваше да направя, за да завърша корекцията, беше да стартирам datapatch в базата данни.
