Oracle – co dělat když se rozsype ASM
Na Oracle clusteru používáme ASM pro ukládání souborů databáze. Když všechno běží, je to paráda. Když se něco pokazí, je to paráda trochu menší, ale náprava naštěstí nebývá složitá. Jednoho dne se v našem ASM pokazila metadata a následkem toho ztratilo přehled o discích s daty. Co se vlastně stalo a co s tím dělat se dočtete dále.
Co to vlastně je ASM?
Diskgroups
U Oraclích databází máme dvě možnosti, kam ukládat data – buď klasicky na filesystém nebo na ASM. ASM stojí na principu tzv. groups. Grupa je zhruba analogická oddílu filesystému – může na ní ležet jedna nebo více databází, podle potřeby.
ASM potom podle nastavené redundance dat v grupě (external=žádná, normal=mirror, high=mirror s dvěma kopiemi dat) využívá datová úložiště a samo se stará o uložení a správu datových bloků, tzv. extents.
Aby to nebylo tak jednoduché, grupa je rozdělena na logické celky, kterým se říká failgroups. Pro ty platí vše, co jsme zatím zmínili o grupě. Pokud má grupa jen jeden disk, je tento disk vlastně samostatnou failgrupou.
Podle nastavené redundance je pak vyžadován určitý počet failgroup v grupě. Například pokud budeme mít normal redundancy grupu DBG a v ní failgrupu DBFG1 s jedním diskem. Po přidání dalšího disku do DBG se automaticky vytvoří DBFG2, pokud mu to ovšem explicitně nezakážeme. Tyto failgroup jsou vzájemně mirrorem. Pokud bychom přišli o celou DBFG1, databáze stále poběží, protože všechna data máme v kopii v DBFG2.
ASM instance
Ačkoli jde o datové úložiště, dokáže se ASM do určité míry chovat jako instance databáze. K této instanci pak jako klienti lokálně přistupují jednotlivé databáze.
K administraci ASM slouží utilita asmcmd, což je ekvivalent přizpůsobené a hodně osekané příkazové řádky. Protože se ale ASM dokáže chovat jako databázová instance, nic nám nebrání se k ní připojit přes sqlplus. Potom si můžeme v klasickém SQL stylu spouštět i dotazy na vlastnosti, stav a aktuální akce.
Co se vlastně stalo
“Příčina nehody: neznámá. Místo: neznámé. Čas: neznámý. Doufám, že tyto informace pomohou objasnit nehodu, ke které tu došlo.” –Kryton, seriál Červený trpaslík
Citát to vystihuje naprosto přesně. ASM se jednoho dne prostě rozhodlo, že se mu DBFG1 nelíbí, vyhodilo z ní všechny disky a pak se ji pokusilo z DBG odebrat. Odebírání disků z grupy je běžná věc – jde o automatický mechanismus, kdy ASM při zjištění mrtvého disku (nelze z něj číst nebo na něj zapisovat) tento disk po určité době odstraní. Následně přesype data v grupě, aby vyžila s tím, co jí zůstalo, a zároveň co možná nejlépe splnila podmínky na redundanci dat. Odstraněným diskům se nastaví hromada příznaků, aby šlo poznat, co se s nimi dělo. ASM také každé odstranění zaloguje.
Stav po zjištění problému byl následující: u disků právě probíhalo odstraňování, ASM ale nepřesýpalo data, příznaky u disků byly podivně nastavené a v logách instance bylo prázdno. Podle operačního systému byly disky dostupné po celou dobu běhu serveru.
Vše tedy ukazovalo na neplechu v ASM. Takže aktuálně vyřešit nápravu a potom hledat příčinu, pokud ji vůbec máme šanci najít.
Chybový stav
Připojil jsem se do ASM jako “sqlplus / as sysasm” a vypsal si grupy:
SQL> select mount_status, header_status, state, failgroup, os_mb, total_mb, path from v$asm_disk; MOUNT_STATUS HEADER_STATUS STATE FAILGROUP OS_MB TOTAL_MB PATH -------------------------------------------------------------------------------------------------------- MISSING UNKNOWN FORCING DBFG1 0 26624 CLOSED MEMBER NORMAL 26624 0 /dev/mapper/dbfg1_disk CACHED MEMBER NORMAL DBFG2 26624 26624 /dev/mapper/dbfg2_disk
Můžete si všimnout, že disk z DBFG1 podle ASM nemá korektní hlavičku. Tady s ním moc neuděláme, podíváme se přímo do operačního systému.
kfed
Kfed je šikovná utilita, která člověku umožňuje hrabat se přímo v metadatech ASM disku. Navíc nepotřebuje, aby běželo cokoliv z Oracle stacku. Stačí mít disk namountovaný v operačním systému nebo mít fungující ASMlib (pokud je používán). Pomocí “kfed read” si vypíšeme hlavičku disku (offsety úplně nesedí, protože DBG a DBFG jsou upravené názvy):
[root@node1 ~]# kfed read /dev/mapper/dbfg1_disk ... kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD ... kfdhdb.grptyp: 2 ; 0x026: KFDGTP_NORMAL kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DBG_0 ; 0x028: length=5 kfdhdb.grpname: DBG ; 0x048: length=3 kfdhdb.fgname: DBFG1 ; 0x068: length=5 ...
Stručný význam jednotlivých polí, konkrétní hodnoty si můžete vyčíst třeba zde:
type - typ hlavičky, zde nám říká, že jde o ASM diskovou hlavičku grptyp - typ redundance grupy, kam disk patří hdrsts - stav disku vůči grupě dskname - jméno disku grpname - jméno grupy fgname - jméno failgrupy
Takže tímhle to nebude. Ještě pomocí “kfed find” zkontrolujeme metadata disku:
[root@node1 ~]# kfed find /dev/mapper/dbfg1_disk Block 0 has type 1 Block 1 has type 2 Block 2 has type 3 ... (všechno další musí být "type 3")
Příkaz find projde bloky disku a vyzkouší, zda sedí metadata bloků. Odhalí tedy špatné checksumy, ale nikoli chyby v datech. Pokud budou v bloku poškozená data, ze kterých bude správně spočten checksum, nedozvíme se to.
Náprava
Poškozená fyzická data nás momentálně netrápí, protože databáze normálně běží a klienti v ní spouštějí dotazy. Disk z grupy vypadl před nějakou dobou, a tedy ho stejně musíme sesynchronizovat, aby obsahoval aktuální data. Protože disk nevypadá poškozený, prostě ho do grupy našťoucháme zpátky:
SQL> alter diskgroup DBG add failgroup DBFG1 disk '/dev/mapper/dbfg1_disk';
Na což Oracle zareaguje hlášením, že disk už součástí nějaké grupy je. Trochu příkaz upravíme (protože v tomto případě nic rozbít nemůžeme):
SQL> alter diskgroup DBG add failgroup DBFG1 disk '/dev/mapper/dbfg1_disk' force;
Což už projde. Inu, co nejde silou…
Teď jsme tedy přidali disk do grupy a proběhne přesýpání (tzv. rebalance). ASM má najednou více failgroup, takže si na ně rozhodí data kvůli redundanci. Proces chvilku trvá a lze ho uspíšit explicitním zvýšením priority. Konkrétní dotaz, který jsem použil při nápravě:
SQL> alter diskgroup DBG add failgroup DBFG1 disk '/dev/mapper/dbfg1_disk' force rebalance power 4;
Parametr “power” může nabývat hodnot 0-11 (0-STOP,11-TURBO:) ), default je 1. Grupa se rebalancovala a od té doby běží vše tak, jak má.
U velkých databází může rebalance trvat dlouho, proto je dobré použít “power” a trochu přesýpání pomoci. Aktuální činnost ASM lze získat výpisem:
SQL> select * from v$asm_operation; GROUP_NUMBER OPERA STATE POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES ERROR_CODE ------------------------------------------------------------------------------------------------------------------ 1 REBAL RUN 4 2 475 2310 1360 0
Závěr
V článku jsem představil postup nápravy chybného stavu ASM za použití standardních utilit dodávaných s Oracle databází. Dále jsme si ukázali utilitku kfed, jakožto rychlého pomocníka pro orientaci v datech ASM disků. Podobný postup se uplatňuje, pokud disky skutečně oprávněně vypadnou z ASM grupy – v takovém případě není třeba nic “forcovat”. Pokud vás článek zaujal, nebo byste se chtěli zeptat na cokoliv ohledně ASM a Oracle DB, neváhejte mne kontaktovat na info@bcvsolutions.eu.
