GitLab.com je offline kvůli problémům s produkční databází

GitLab.com (Wikipedie) je offline kvůli problémům s produkční databází. Produkční data byla omylem smazána. Řešení problému lze sledovat na Twitteru. Podrobnosti v dokumentu na Dokumenty Google [Hacker News].

1.2.2017 09:55 | Ladislav Hagara | Upozornění

Komentáře

[Josef Kufner]

… he was going to sign off as it was getting late (23:00 or so local time), but didn’t due to the replication problems popping up all of a sudden.

… an empty data directory, decides to remove the directory. After a second or two he notices he ran it on db1.cluster.gitlab.com, instead of db2.cluster.gitlab.com.

[xvasek]

Upsy Daisy. Myslím, že si to úplně umím představit, jak mu zatrnulo v břichu.

[j]

Presne v okamziku, kdy dal posledni enter ... ;D

[koroptev]

hm, takze sluzba k nepouziti, amateri

Netrolluj.

[NN]

YP = fail, on so many levels..

[kolb\Y\]

Ach, ten pocit když se vám protočí vnitřnosti a poleje studený pot

[Max]

To jen v lepším případě ...
Zdar Max

[dustin]

Tak výhodou gitu je, že klon repozitáře githubu je stejně na devel kompu (ze kterého se to pushuje), včetně verzované wikiny. Samozřejmě by chyběla data z diskusí/ticketů atd., ale to naštěstí není tak klíčové.

[Conscript89]

Jenom takova poznamka, tady jde o gitlab, jen aby bylo jasno :)

[dustin]

Díky, jsem slepý.

[Kate]

A takové drobnosti jako nastavení CI runnerů a tak...

[Heron]

Samozřejmě by chyběla data z diskusí/ticketů atd., ale to naštěstí není tak klíčové.

Asi jak pro koho. Smyslem těchto systémů je mít kromě obyč. repositáře taky issues, diskuse, komentáře ke commitům (případně řádkům) apod. Ta data (git a u někoho možná i wiki) budou na více místech u vývojářů, ale zrovna ty projektové věci typicky nejsou krom gitlabu nikde.

Gitlab(CE) provozuju u sebe, zálohy dělám přes snapshoty a sem tam ten jejich tar (jehož obnova je teda dost opruz, protože je potřeba mít přesně stejnou verzi gitlabu, na které se to pořizovalo - ale funguje to), a nedovedu si představit, v jakém stavu bude gitlab.com, když tam nahrnou DB starší, než mají commity v gitu. Tam nebude vzájemně sedět prakticky nic.

[alkoholik]

Live stream.

[JoHnY3]

Musim se jim nechat, ze nijak netutlaji jak se prusvih stal a to vcetne celkem nevhodne konfigurace postgresu, selhani velke casti zalohovacich mechanismu kvuli chybam nastaveni a spatne kontrole. Takhle jit s kuzi na trh chce velkou odvahu.

Docela me prekvapilo, ze maji cely system tak krehky jak se ted ukazalo.

[Kate]

Na druhou stranu, po tomto incidentu věřím že budou mit zálohy pořešené skvěle. Protože projít si tím podruhé chtít určitě nebudou :)

[m-a]

Toto podrobne zverejnenie mi prislo ako najlepsi moment celeho toho "incidentu" - ze som sa zamyslel a znovu venoval podrobny pohlad tomu, ako mam nastavene zalohovanie a ci a ako viem predist podobnemu omylu u seba.

[Max]

Jako, krizovku zvládli dobře, na to, jak byli v háji.
Přesně, jak se říká, za většinu problémů může lidský faktor.
Já si před pár měsíci pustil na pc dd if=/dev/zero of=/dev/sdx bs=4096 count=1024 na produkční disk místo na flashku, kterou jsem chtěl vyčistit. Naštěstí i v tomto případě jsem měl vše v poli, takže jsem dal nový sync a data byly zpátky.
Kolegovi jsem zase nedávno zadal úkol nastavit port na switchi, taková blbost a on omylem vytvořil na switchi všech 4096 vlan. Jenže to nebyl jen takový switch, ale produkční cluster, přes který jedou všechny servery. Trochu se nám chudák zapotil, ale podařilo se mi to vyčistit relativně rychle. Myslel jsem, že takovou blbost zvládne, asi jsem myslivec.
Zdar Max

[R]

Tiez sa mi "podarilo" nieco podobne s dd, akurat som tam mal bs=1M a bez count... Rychlo som to zastavil, ale aj tak to stihlo prepisat dost.

Bol testovaci disk, kde sice neboli dolezite data, ale nainstalovany Debian s kopou blbosti, postahovanych zdrojakov a ineho bordelu - samozrejme bez zalohy. Kedze sa mi to nechcelo robit cele znovu, tak som radsej venoval trochu casu zachrane - MBR som vytvoril, na filesystem (ext3) pustil fsck. Nakoniec reinstall vsetkych balikov, grub-install a ono to dodnes funguje.

[Santiago]

Timto se na pamatku vypadku Gitlabu vyhlasuje 1. unora jako Mezinarodni den kontroly zaloh: February 1st - Check your backups Day!.