diff --git a/content/blog/2024/07/2024-07-19_downtime-bericht/index.md b/content/blog/2024/07/2024-07-19_downtime-bericht/index.md index 5ebdb514fb486bb184b9a9107713777c29e92e34..553b1140df14bce36bb5fc45cc159d49352b0e50 100644 --- a/content/blog/2024/07/2024-07-19_downtime-bericht/index.md +++ b/content/blog/2024/07/2024-07-19_downtime-bericht/index.md @@ -4,7 +4,7 @@ authors = ["nik"] [extra.depiction] image = "rack-sharepic.jpg" -alt = "Frotnansicht einiger typischer Supermicro-Server in einem Rack" +alt = "Frontansicht einiger typischer Supermicro-Server in einem Rack" +++ Vom 12. bis 15. Juli waren unsere Dienste offline. Auslöser war ein @@ -62,15 +62,15 @@ werden: * Wie reduzieren wir die Auswirkungen der Umverteilung (*Rebalancing*) während des Umbaus? * Wie werden die Datenträgern in den Servern veteilt, so dass einigermaßen - gleichmäßig SPeicherplatz zur Verfügung steht? + gleichmäßig Speicherplatz zur Verfügung steht? ## Ausfall des Storage Da auch der Platz für Datenträger in den Servern begrenzt ist, entschieden wir uns, -zunächst den bisher vorhandenen, kleinen SSD-Cache zu deaktivieren. Das wúrde zwar -vorübergehend zu noch schlechterer Performance führen, aber dafÜr die Dauer der -Umbaumaßnahmen immens reduzieren. Deshalb haben wir als ersten Schritt am Fretiag, -dem 12. Juli, den Cache vom *witeback*- in den *readproxy*-Modus umgeschaltet. In +zunächst den bisher vorhandenen, kleinen SSD-Cache zu deaktivieren. Das würde zwar +vorübergehend zu noch schlechterer Performance führen, aber dafür die Dauer der +Umbaumaßnahmen immens reduzieren. Deshalb haben wir als ersten Schritt am Freitag, +dem 12. Juli, den Cache vom *writeback*- in den *readproxy*-Modus umgeschaltet. In diesem Modus sollten noch im Cache vorhandene Objekte benutzt, jedoch keine neuen Objekte mehr gecachet, werden. @@ -99,12 +99,12 @@ zusammenfassen.  Nach der Korrektur der Dateisystemfehler auf dem System, auf dem unser -PostgreSQL-Cluster läuft, fehlten Informatioen über bereits vergebene +PostgreSQL-Cluster läuft, fehlten Informationen über bereits vergebene Transaktions-Nummern und weitere verwandte Informationen. Notwendigerweise entschieden wir uns deshalb, den PostgreSQL-Cluster vollständig aus einem Backup wiederherzustellen. -## Restore der PostgreSQL-Datenbanken auf usnerem langsamsten Server +## Restore der PostgreSQL-Datenbanken auf unserem langsamsten Server Drei gute Nachrichten vorab: Wir hatten ein Backup des PostgreSQL-Clusters, es war aktuell und es ließ sich wiederherstellen! Was wir zu diesem @@ -118,7 +118,7 @@ wollten. Dabei gab es einige Eckpunkte zu beachten: * Das letzte volle Backup des Clusters war fünf Tage alt. Alle Daten zwischen dem 7. und dem 12. Juli mussten aus dem *Write Ahead Log* wiederhergestellt werden. -* Der Storage auf dem Datenbankserver war nach der Deaktivierugn des Caches nun +* Der Storage auf dem Datenbankserver war nach der Deaktivierung des Caches nun noch langsamer als vorher * Der Backup-Server hat mittelmäßige Storage-Geschwindigkeiten, aber nur eine Single-Core-CPU mit 2,1 GHz @@ -172,7 +172,7 @@ eine Tabellenzeile eindeutig benannt werden kann. Beim Versuch, die fehlenden Primary Keys selber anzulegen, zeigte sich, dass die betroffenen Tabellen tatsächlich einige Daten doppelt enthielten. Betroffen waren dabei die Datenbanken -von Syanpse und [Mastoson](https://joinmastodon.org/). Glücklicherweise stellten wir fest, +von Syanpse und [Mastodon](https://joinmastodon.org/). Glücklicherweise stellten wir fest, dass alle betroffenen Tabellen in zwei Kategorien fielen: * Tabellen, deren Daten durch Föderation erneut befüllt werden können