GitLab má velký výpadek, služba nefunguje a správci se snaží zachránit situaci. Výpadky se občas stávají, dokonce se i někdy stává, že si spletete server a smažete si data někde jinde. V tomto případě správce v Nizozemí omylem smazal databázi na produkčním serveru, ze kterého měla proběhnout replikace. Jedním příkazem tak služba přišla o 300 GB uživatelských dat.
Nepříjemné je to hlavně pro velké množství uživatelů, ale Git je z principu decentralizovaný, takže není problém chvíli počkat a commitovat lokálně nebo repozitář dočasně přesunout jinam.
Známý mi nedávno vyprávěl, jak se snažil dokola restartovat server, ale nedařilo se mu to. Pak k němu i dojel a skutečně to pořád nedělalo, co chtěl. Až po nějaké chvíli zjistil, že má v telefonu hromadu nepřijatých hovorů od šéfa a zákazníků. Restartoval totiž omylem produkční stroj a divil se, že ten jeho stále žije svým životem. Kdo to nezažil, není admin.
Na případu GitLab je pozoruhodný jiný fakt: totiž že měli pět různých zálohovacích mechanismů a pět z nich selhalo. Ani jeden nefungoval správně. Výsledkem je smazaná produkční databáze, ke které neexistuje snadno dostupná a dostatečně čerstvá záloha. Databáze obsahovala například hlášení chyb (issues) a merge requests. Samotné gitovské repozitáře a soubory s wiki poškozeny nebyly.
We accidentally deleted production data and might have to restore from backup. Google Doc with live notes https://t.co/EVRbHzYlk8
— GitLab.com Status (@gitlabstatus) February 1, 2017
- LVM snapshoty se automaticky dělaly jen jednou za 24 hodin. Šest hodin před výpadkem byl jeden udělán manuálně.
- Klasické zálohy probíhaly také jednou za 24 hodin, ale není jasné, kam byly ukládány. Zálohy na S3 jsou prázdné.
- Snapshoty v Azure byly zapnuté pro NFS disky, ale už ne pro databázové úložiště.
- Záloha pomocí pg_dump také selhávala, protože se omylem pouštěl PostgreSQL verze 9.2 místo správné 9.6. Proces tak potichu selhával a nikdo si toho nevšiml.
- Replikační procedura byla prováděna nahodile napsanými shellovými skripty bez dokumentace.
Zároveň se objevily další problémy, jako že byly špatně zpracovány webhooky, takže pravděpodobně jsou součástí záloh a budou ztraceny a podobně. Postupně se daří staré zálohy obnovovat, ale není jasné, jak dlouho to bude trvat ani kolik toho bude nakonec ztraceno. V každém případě budou data minimálně šest hodin stará.
GitLab se rozhodl pro radikální změnu, v budoucnu poběží na Ceph clusteru a to by jej mělo činit odolnějším proti podobným problémům. Uvidíme. V každém případě to opět ukazuje na fakt, že zálohy je potřeba nejen dělat (třeba pětkrát), ale hlavně kontrolovat jejich funkčnost.
ČLÁNKY DO MAILU