38 lines
3.0 KiB
Markdown
38 lines
3.0 KiB
Markdown
# Karte 13 – Hauptserver mit Satelliten-Servern
|
||
|
||
**Status:** Entschieden (Architektur-Erweiterung), betrifft Prompt 17 (Offline) und Prompt 19 (Architektur).
|
||
|
||
## Entscheidung
|
||
Zusätzlich zum Hauptserver können **Satelliten-Server** existieren, die lokal (am Einsatzort/an einer Wache) laufen und temporär vom Hauptserver getrennt sind.
|
||
|
||
## Einsatzfälle
|
||
1. KatS-Einsatzlage (Zeltlager/Einsatzort ohne Internet) – Satellit läuft autark vor Ort.
|
||
2. Wache mit dauerhaft schlechter Anbindung – Satellit als Regelbetrieb, nicht nur Notfall.
|
||
3. Reiner Ausfallschutz – Satellit übernimmt nur bei Komplettausfall Hauptserver/Internet.
|
||
|
||
## Autark-Dauer
|
||
Bewusst **nicht zeitlich begrenzt** – System darf keine feste Obergrenze annehmen (z. B. "nach 3 Tagen zwingend Sync nötig"). Trennung kann Stunden bis mehrere Tage/unbestimmt dauern.
|
||
|
||
## Mehrbenutzerfähigkeit am Satelliten
|
||
Satellit ist funktional ein vollwertiger, kleiner Hauptserver-Klon (gleiche Software/API), kein reiner Cache. Mehrere Mitarbeiter können gleichzeitig am selben Satelliten arbeiten – braucht keine eigene Konfliktlösung, da er wie der Hauptserver selbst funktioniert.
|
||
|
||
## Konfliktvermeidung (statt Konfliktlösung)
|
||
Zentrale Design-Entscheidung: Konflikte beim Zurücksynchronisieren **sollen strukturell nicht vorkommen**, nicht nachträglich aufgelöst werden.
|
||
- Jedes Objekt (Rucksack/Fahrzeug) ist während einer Trennung **fest genau einem Server zugeordnet** – entweder Hauptserver oder ein bestimmter Satellit, nie beiden gleichzeitig.
|
||
- Objekte, die einem Satelliten zugeteilt sind, werden am Hauptserver für Schreibzugriffe gesperrt/als "ausgelagert" markiert, bis Rücksynchronisation erfolgt ist.
|
||
- Dadurch kein "wer gewinnt"-Problem – es gibt pro Objekt nur eine schreibende Quelle zu jedem Zeitpunkt.
|
||
|
||
## Konsequenz für Datenmodell/Architektur (Vorbereitung, Details Prompt 19/20 zu vertiefen)
|
||
- Objekt braucht Feld "aktuell zugeordneter Server" (Hauptserver-ID oder Satelliten-ID).
|
||
- Zuordnung ändert sich nur durch bewussten Vorgang ("Objekt X an Satellit Y auslagern" / "Objekt X zurückholen"), nicht automatisch.
|
||
- Historie/Fehlbestände/Kontrollen, die am Satelliten entstehen, tragen von Anfang an die eindeutigen IDs des Gesamtsystems (nicht lokal generierte, kollisionsanfällige IDs) – Voraussetzung für widerspruchsfreies Zusammenführen beim Sync.
|
||
- Synchronisation überträgt beim Reconnect alle am Satelliten neu entstandenen Datensätze (Kontrollen, Fehlbestände, Nachfüllungen, Historie) an den Hauptserver, danach wird die Objekt-Zuordnung zurückgesetzt.
|
||
|
||
## Offene Punkte für weitere Ausarbeitung
|
||
- Wie wird eine Auslagerung technisch ausgelöst/verwaltet (manuell durch Administration vor einem Einsatz, oder automatisch bei Verbindungsverlust)?
|
||
- Muss der Satellit vorab mit den relevanten Stammdaten (Materialstamm, Vorlagen der betroffenen Objekte) bestückt werden, bevor er getrennt wird?
|
||
- Hardware-Anforderung an Satelliten-Server (kleiner lokaler Rechner/Mini-PC vor Ort, Prompt 19 zu ergänzen).
|
||
|
||
## Referenzen
|
||
Bezug: [[17_mobile_offline]], [[19_technische_architektur]]
|