From 04ae27606ba2ba545e85c04241fbf9cd10026f87 Mon Sep 17 00:00:00 2001 From: Erik Uden Date: Fri, 20 Sep 2024 23:39:03 +0200 Subject: [PATCH] troet.cafe blog: Update Glossar --- .../2024/07/die-rettung-vom-troet-cafe.md | 39 ++++++++++++++----- 1 file changed, 30 insertions(+), 9 deletions(-) diff --git a/content/de/blog/2024/07/die-rettung-vom-troet-cafe.md b/content/de/blog/2024/07/die-rettung-vom-troet-cafe.md index c088545..55b2f46 100644 --- a/content/de/blog/2024/07/die-rettung-vom-troet-cafe.md +++ b/content/de/blog/2024/07/die-rettung-vom-troet-cafe.md @@ -114,12 +114,33 @@ Folgendes war der ungefähre Plan den wir am 10. Mai (*einen Tag vor der Rettung
  • Tag 2 der Rettung
  • Zeitaufzeichnung
    • @@ -805,7 +826,7 @@ Wir schauten also in der offiziellen [Mastodon-Dokumentation über PgBouncer Use Die `pgbouncer.ini` Datei wurde editiert und die Einstellungen angepasst. Wir verifizierten um 12:03 anhand von journalctl (*der Logs der Datenbank*) das es funktioniert. Der worker3-Server konnte nun mit dem Datenbank-Server kommunizieren! Wir dachten, dass weil die Userlist nicht vorhanden war konnte PgBouncer das Passwort nicht verifizeren und somit galt unsere Aktion und unser User als unauthentifiziert, deshalb `authentication failure`. -### (1.) Ausführen vom Maintenance-Skript (Gescheitert) +### (1.) Ausführung vom Maintenance-Skript (Fehlgeschlagen) Da jetzt die tootctl Software vom worker3-Server die Datenbank des neuen Datenbank-Servers editieren konnte schien uns eigentlich nichts mehr im Weg zu sein. Das Maintenance-Skript um alle unsere Probleme zu lösen und eine Kopie der Datenbank welche alle diese Probleme hatte. So leicht war es dann leider auch nicht... @@ -817,7 +838,7 @@ Daraufhin bekamen wir eine Antwort welche die komplette Zeit des restlichen Tage
    -### Das Ändern der Datenbank-Schema-Version (Gescheitert) +### Das Ändern der Datenbank-Schema-Version (Fehlgeschlagen) > "Your version of the database schema is more recent than this script, this may cause unexpected errors." @@ -923,7 +944,7 @@ Nick hatte mit allem Recht. Als Ich damals anwies das wir die neu aufgesetzte Da Ich loggte mich also als postgres User (*SuperUser*) in der Postgresql Datenbank auf dem neuen Datenbank-Server ein und führte folgenden Befehl aus: `ALTER DATABASE mastodon_production OWNER TO "mastodon";` -### (2.) Ausführung vom Maintenance-Skript (Gescheitert) +### (2.) Ausführung vom Maintenance-Skript (Fehlgeschlagen) Nun konnte der PgBouncer oder externe worker3-Server überhaupt die Datenbank editieren. Daraufhin versuchten wir es erneut mit dem Maintenance-Skript, was in den Log 012 `troet.cafe-012-tootctl-maintenance-2024-05-12-16-48.txt`) resultierte.