Fix typos

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.
 ![Transaktionen in PostgreSQL (vereinfacht)](pg-transaktionen.png)
 
 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