Mi immagino le decine e decine di aziende che si sono ritrovati a culo a terra da questa mattina. GitLab ha accidentalmente distrutto il proprio database di produzione.
Gitlab é un servizio simile a GitHub, permette di hostare sul loro cloud repository git.
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
tl;dr hanno cacellato il database primario al posto della replica.
Una replica é una copia continua del database. Solitamente un db é master, su cui vengono eseguite le scritture, ed uno o piú sono slave. In maniera automagica gli slave copiano tutto quello che viene scritto sul master. Sigli slave non é possibile eseguire scritture ma si possono tranquillamente eseguire letture. Il processo di replica é abbastanza delicato e dei record possono venir scritti in maniera errata, generando un disallineamento. Non é un grosso problema, normalemente. Si dice agli applicativi di non utilizzare quel database, si cancella tutto il contenuto del db, si ricopia tutto da capo e si fa ripartire la replica.
Cosa é successo? Sono stati molto cristallini nella comunicazione, per cui si puó capire nel bene e nel male cosa sia successo in modo dettagliato.
Nel pomeriggio del 31/01 c’é stato un botto di traffico spammoso che ha causato problemi ai database.
High load was partially caused by 47 000 IPs logging in to the same account at a high rate
— GitLab.com Status (@gitlabstatus) January 31, 2017
Sistemato il problema bannando gli ip si sono accorti che la replica si era bloccata e parecchie cose non funzionavano quindi il tecnico si é messo ad agigustare parametri qua e lá. Fatto ripartire il db1 ha confuso la shell di db1 e db2 e ha zappato la directory dei dati del server buono.
Il dramma peró é stata l’assenza di backup utilizzabili!
So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place. => we’re now restoring a backup from 6 hours ago that worked
Quindi in altre parole, di 5 techniche di backup/repliche implementate nessuna é funzionante o utilizzabile al bolo. => É stato effettuato il restore di un backuo di 6 ore fa che ha funzionato
Fortunatamente un backup era stato fatto per la copia verso il db di staging ma mancante di alcune parti, recuperati da altri snapshot.
Web hooks created prior to Jan 31st 17:20 UTC are restored
— GitLab.com Status (@gitlabstatus) February 1, 2017
É importante imparare dai propri errori, ma é molto piú pratico imparare dagli errori altrui:
- 1. I backup sono importanti
- 2. I backup funzionanti sono importanti
- 3. I backup funzionanti ripristinabili in breve tempo sono importanti
— Alessandro Lorenzi (@alorenzieu) January 25, 2017