Der Datenbank-Standby und die Berichtskopie (für das Kaam360-Team)

Diese Anleitung ist für das Kaam360-Team (Plattform-Panel). Kunden brauchen sie nicht.

Was der Standby ist

Die Live-Site hält ihre Daten in einer PostgreSQL-Datenbank auf dem Server. Der Standby ist ein zweites PostgreSQL auf demselben Server, das jede Änderung im selben Moment erhält und daher nur Millisekunden zurückliegt. Geht die Live-Datenbank kaputt, kann die Site in etwa zwei Minuten auf den Standby umgeschaltet werden, statt die Sicherung der letzten Nacht wiederherzustellen. Er ersetzt nicht die nächtliche externe Sicherung, die vor dem Verlust des ganzen Servers schützt: beides wird gebraucht.

Alles geschieht über Schaltflächen in GitHub (Actions, PostgreSQL standby, Run workflow): Modus wählen, dasselbe Wort in das Bestätigungsfeld tippen, grüne Schaltfläche drücken. Das schriftliche Vorgehen steht in der Datei deploy/STANDBY.txt.

Sehen, ob er gesund ist

1. Öffnen Sie das Plattform-Panel und sehen Sie auf Overview. Die Karte Database standby sagt Streaming (gut), Behind (zurück) oder Not connected (nicht verbunden), mit dem Rückstand.
2. Dieselben Angaben stehen unter der Adresse /health der Site im Teil "standby".
3. In GitHub druckt der Modus status eine ganze Seite: Windows-Dienst, Streaming-Zustand, Bytes und Sekunden Rückstand, Größe der Kopie. Er ändert nichts.
4. Ist der Standby zehn Minuten lang weg oder zurück, bekommt das Team eine E-Mail (an die Support-Adresse unter Settings & team, sonst an alle Plattform-Administratoren), höchstens alle sechs Stunden wiederholt. Das Plattform-Protokoll Activity erhält eine Zeile, wenn etwas schiefgeht und wenn es wieder in Ordnung ist.

Einrichten oder reparieren

Führen Sie den Modus setup aus. Die Live-Site wird nicht angehalten. Er legt die Datenbankbenutzer an (Passwörter bleiben nur auf dem Server), nimmt eine vollständige Kopie, startet sie als Standby, registriert den Windows-Dienst, sperrt den Port nach außen und informiert die Site. Ein gesunder Standby bleibt unangetastet, erneutes Ausführen ist also immer sicher. Scheitert ein Schritt, sagt das Skript welcher und warum, und an der Live-Site ändert sich nichts.

Auf den Standby umschalten

Führen Sie den Modus failover aus, wenn die Live-Datenbank kaputt und der Standby in Ordnung ist. Die Site zeigt etwa zwei Minuten lang eine "Aktualisierung"-Seite. Der Standby wird zur Live-Datenbank, die Site wird auf ihn gelenkt, und die vorherigen Einstellungen bleiben als appsettings.local.json.before-failover erhalten. Danach druckt das Skript die nächsten Schritte: die Site wie gewohnt nutzen, den alten Datenbankordner vorerst behalten und bei Ruhe auf dem Server setup ausführen, um einen neuen Standby zu machen. Eine beförderte Kopie wird nie wieder Standby; ein neuer entsteht aus einer frischen Kopie.

Schwere Berichte lesen aus der Kopie

Wenn der Standby streamt und weniger als ein paar Minuten zurückliegt, lesen der Berichts-Builder, geplante Berichts-E-Mails, CSV- und Excel-Downloads, das Portfolio, Projektberichte und der vollständige Datendownload aus ihm statt aus der Live-Datenbank, damit ein großer Bericht nie die arbeitenden Personen bremst. Ein solcher Bericht zeigt Daten vom mit der Zeit der neuesten Änderung in der Kopie. Fehlt die Kopie, ist sie nicht erreichbar oder mehr als ein paar Minuten zurück, nutzen Berichte stattdessen die Live-Datenbank, ohne dass jemand etwas tun muss. In die Kopie wird nie geschrieben, und jeder Bericht sieht nur die Daten seiner eigenen Organisation, genau wie in der Live-Datenbank. Die Adresse /health sagt, ob Berichte aus der Kopie bedient werden ("reports").

Entfernen

Führen Sie den Modus remove aus. Er stoppt und löscht den Standby und nimmt ihn aus den Einstellungen der Site. Die Live-Datenbank wird nicht berührt. Setup kann jederzeit erneut ausgeführt werden.