17th March 2016

Silverfin Database corruption - post mortem

We've currently resolved the database corruption, but we're still investigating the rootcause and are closely monitoring the database. Underneath you find a post mortem of the event which caused Silverfin to be offline from 11:07 till 15:10. The text below is in Dutch, as it's based on our internal communication, if you'd like an excerpt in French or English, we'd be glad to provide it on request.

  • 10:43 onze monitoring begint foutmeldingen door te geven over de connecties tussen de frontendservers en de database, daarnaast krijgen we een melding dat de replicatie naar de slave server gestopt is
  • 10:50 op basis van de database logs zien we het de database zelf is die voortdurend herstart wordt vanwege panics
  • 10:59 om het probleem te identificeren zetten we alle achtergrondprocessen af, het probleem blijft zich echter voordoen
  • 11:07 we plaatsen Silverfin in onderhoudsmodus, Silverfin is vanaf dan niet meer publiek toegankelijk
  • 11:09 we vragen hulp aan enkele postgres experten om te assisteren in dit onderzoek
  • 11:15 uit de logs van de database server blijkt dat de crash veroorzaakt wordt wanneer een insert of een update gebeurt op onze documenten tabel
  • 11:30 we bekijken de verschillende opties om Silverfin zo snel mogelijk terug online te krijgen:
    • restoren van een backup
    • een constante lock op de documenten tabel
    • overschakelen naar de failover omgeving
    • een recovery van de database
    • het terugzetten van een backup duurt meer dan 3 uur omwille van het genereren van indexes en zou tot dataverlies leiden (de backup bevat niet de data die vandaag werd aangemaakt). Het overschakelen naar de failover omgeving is risicovol, daarnaast hebben we nog geen compleet beeld op de situatie, dus Silverfin terug online halen zonder 'documenten' lijkt eveneens een groot risico, we besluiten om de data in de productie database goed te zetten
  • 11:45 na het installeren van de nodige tooling op de server is snel duidelijk dat er corrupte pages zijn in de database
  • 11:58 alvorens we starten met de data recovery maken we een snapshot van de complete server, dit duurt ongeveer 25 minuten
  • 12:26 we slagen er in om de specifieke rij in de documenten tabel te identificeren waar het fout gaat
  • 12:38 na het aanpassen van deze rij merken we dat er meer aan de hand is, de index op deze tabel is ook corrupt, waardoor een update of insert nog steeds niet lukt
  • 12:46 we besluiten om de volledige inhoud van de tabel in kwestie uit de database te verwijderen. Deze tabel bevat de OCR-inhoud van opgeladen documenten, deze info kan na de recovery volledig opnieuw aangemaakt worden
  • 12:58 het aanpassen van de kolom is geslaagd, de database geeft echter aan dat er meerdere documenten met hetzelfde id in de database zitten, iets wat normaal uniek moet zijn. we besluiten om dit probleem verder te bekijken terwijl Silverfin live staat, aangezien de basisfunctionaliteit hierdoor niet in het gedrang komt (beperkt tot enkele documenten).We starten onze frontendservers terug op en we brengen de servers terug uit onderhoudsmodus.
  • 13:12 Silverfin is kort terug online, maar we zien vrijwel onmiddellijk terug fouten via onze monitoring. Niet meer op de document tabel, maar op een tabel van het permanent dossier, we brengen Silverfin onmiddellijk terug in onderhoudsmodus.
  • 13:15 we gaan een voor een door alle tabellen en bekijken welke de corrupt zijn
  • 13:30 er blijken in het totaal 3 tabellen te zijn (inclusief de documenten): de documenten, het permanent dossier en de toelichtingen
  • 13:35 we proberen net zoals in de documenten de corrupte rijen te identificeren. Echter kunnen we niet zoals in de documenten zomaar de 'content' rij weggooien. Die bevat immers cruciale informatie. We merken dat alle corrupte data aangepast was om 10u27
  • 13:55 we besluiten de inhoud van de corrupte data leeg te maken en dit uit de backup te halen. Omdat de indexen hier ook corrupt zijn kopiëren we eerste de data naar een andere kolom, om vervolgens de originele te verwijderen en een lege toe te voegen. Daarna kopiëren we de gekopieerde data er terug over.
  • 14:25 we doen enkele checks op de inhoud van de kopie om te garanderen dat deze overeenstemt
  • 14:42 de indices op deze tabellen zijn ook corrupt, bij het herindexeren merken we dat ook hier rijen inzitten met dezelfde id, we besluiten dit probleem aan te pakken alvorens Silverfin online te plaatsen
  • 14:50 na onderzoek van de data kunnen we de dubbele er uit halen, dit doen we voor alle 3 de tabellen
  • 15:10 de dubbele rijen zijn er uitgehaald en alle drie de kolommen zijn ok, Silverfin wordt terug online geplaatst
  • 15:16 we zien dat er nog verschillende andere indexes op andere kolommen corrupt zijn, we herbouwen die asynchroon terwijl Silverfin online is
  • 15:19 we beginnen een voor een onze achtergrondprocessen terug op te zetten
  • 16:00 we monitoren het systeem en zien nog enkele corrupte indexes, waaronder enkele zeer grote tabellen, deze worden ook een voor een opnieuw geïndexeerd