Így menekült meg a KDE
A Nagy 2013-as KDE-Katasztrófa - ilyen néven vonulhatott volna be a köztudatba az az adatvesztés, amelyet hajszál híján sikerült elkerülnie a projektnek. Egy adatvesztés miatt ugyanis hibásan replikálódott tovább a repository, ezzel a biztonsági mentésként használt másodlagos szerverek is elvesztek. Csak a szerencsének köszönhető, hogy a mintegy 1500 kódrepó megmenekült.
A KDE egy központi Git-kiszolgálót használ (ez a git.kde.org), ennek tartalmát tükrözi számos másik szerver, amelyek hozzáférést biztosítanak a névtelen webes felhasználók felé - írja le a kezdeti állapotot Jeff Mitchell bejegyzése. Ezek a másodlagos szerverek működnek biztonsági mentésként a rendszerben, ez a megközelítés azonban hibásnak bizonyult. Amikor a központi szerver virtuális gépeit újraindították biztonsági frissítések telepítéséhez, az újra felálló VM-ek fájlrendszer-hiba miatt nem látták megfelelően a tárolt Git repository-kat. Az adatvesztés az automatikus és korlátlan tükrözés miatt szinte azonnal továbbterjedt a másodlagos szerverekre is, így a tárolt kódbázisok azokról is eltűntek.
Mire az üzemeltetők a hibát felfedezték, már túl késő volt. A központi rendszer adatvesztése miatt a legtöbb repository eltűnt a projektlistából, amit a másodlagos gépek a projektek törléseként értelmeztek és a szinkronizálás szabályai értelmében törölték ezeket. "A túl tökéletes tükrözés" következtében a másodlagos kiszolgálók a hibát is replikálták, ezzel mindenhonnan eltűnt a KDE Git-kódadatbázisának tartalma.
"Szerencse. Szerencse, szerencse, szerencse"
Ezzel az alcímmel foglalta össze Mitchell a kódbázis megmenekülését a posztban. Volt ugyanis egy, lecserélésre ítélt, elavult szerver, amelyet egy újabb hardverre migráltak az előző nap, az új szerveren pedig éppen megmaradt a teljes anyag, a hibák nélkül. És ebben a szerencsének tényleg nagyon nagy szerepe volt: az új gép szinkronizációs ablaka ugyanis pont arra az időpontra esett, amikor a központi gép újraindult, így a replikációs szkript nem tudta elvégezni feladatát, a már leszinkronizált repository-k pedig épen maradtak.
Ebből a forrásból viszonylag gyorsan sikerült visszaállítani a központi kiszolgáló és a másodlagos csomópontok adatait, a metaadatokkal együtt, pusztán a szinkronizációs script irányainak megfordításával. Az üzemeltető csapat nem mindent állított vissz, a Gitolite repository-t például inkább nulláról építették újra, friss verzióval.
Okos küszöbökkel érdemes védekezni
Az ilyen magas szinten automatizált rendszerek esetében nagyon gyorsan lehet nagyon nagy bajt is csinálni, mint történt (szinte) ebben az esetben. A közvetlen üzemeltetői kontroll nélkül lefutó szkriptekbe ezért érdemes olyan küszöböket, gátakat, fékeket tenni, amelyeket a normális működés nem lép át, a rendkívüli eseményeket azonban megfogja és csak külön emberi beavatkozásra megy le a folyamat. Ebben az esetben az üzemeltetők a hiba újbóli elkerülésére beépítettek egy egyszázalékos küszöböt: ha szinkronizációk között több, mint a projektek egy százaléka módosul, akkor a replikáció mellett biztonsági másolatot készít az előző állapotról is, biztos ami biztos. A helyzet megismétlődését elkerülendő a központi kiszolgáló a jövőben a Git adatbázisát ZFS fájlrendszeren fogja tárolni, amely a fájlrendszer hibája esetén is képes visszaállítani az előző állapotot a belső snapshoton keresztül.
Nyerd meg az 5 darab, 1000 eurós Craft konferenciajegy egyikét! A kétnapos, nemzetközi fejlesztői konferencia apropójából a HWSW kraftie nyereményjátékot indít.
A hiba nyilvánosságra hozatalát követően az üzemeltető csapatot rengetegen támadták az alapvetően hibás biztonsági mentésekért, ezért Mitchell egy további posztban tisztázta, hogy a rendszerben volt valódi biztonsági mentés is, a kódbázist hagyományos módon, tarball formátumban is mentették, ezeket pedig az adatvesztés nem írta felül. A mentés azonban csak a forráskódokra vonatkozott, a rendkívül gazdag Git-metaadatok és egyéb információk ebben a formában nem őrződtek volna meg.
A tükrözés-alapú mentéseknek azonban GIt-környezetben Mitchell szerint nem nagyon van alternatívája, a repository-k integritását ellenőrző git fsck ugyanis egy ekkora projekten rendkívül hosszú ideig fut (becslése szerint több, mint egy nap), így a sűrű mentésekhez eleve használhatatlan, tükrözések előtt pedig lehetetlen rendszeresen futtatni. További problémát jelent, hogy a snapshot-alapú mentések az adatbázist inkonzisztens formában tárolhatják, ami visszaállíthatatlan, így szintén adatvesztéshez vezet. Mitchell szerint így nem a megközelítés volt hibás, csupán néhány olyan alapfeltevés, amely ebben az esetben nem állta meg a helyét. Az egyik ilyen, hogy a repository-k központi gépen tárolt listája minden esetben megbízható, ezért a lista alapján akárhány projekt törölhető a másodlagos gépeken - ezt a beépített küszöbökkel jól kezelik a jövőben. A másik problémát a git clone -mirror a várthoz képest eltérő viselkedése okozott, Mitchell szerint a dokumentáció pontatlanul fogalmaz a kérdésben, ez vezetett félreértéshez és végül a hibához (a részletekért érdemes az eredeti bejegyzést elolvasni).