Administratorhandbuch

Datenbank

Wie Ephraim in Produktion MySQL als dauerhafte Datenbank nutzt und Redis/Valkey nur als maschineninternen Speed-Layer für laufende Streams und Worker-Wakeups einsetzt.

· Stand: Juni 2026

1. Kurzfassung

In Produktion ist MySQL die zentrale Datenbank von Ephraim. MySQL ist die dauerhafte Wahrheit: Konten, Rollen, Projekte, verschlüsselte Chats, Jobzustände, Knowledge-Metadaten, verschlüsselte Chunks, verschlüsselte Embeddings, Einstellungen und Auditdaten werden dort verwaltet.

Redis/Valkey ist davon getrennt. Es läuft auf demselben Host wie die Webanwendung und ist nur über ein maschineninternes Server-/Containernetz erreichbar. Ephraim verwendet Redis/Valkey nicht als zweite Nutzerdatenbank, nicht als Session-Speicher, nicht als Vault-Speicher und nicht als RAG-Vektordatenbank.

Merksatz: MySQL hält den Zustand. Redis/Valkey beschleunigt laufende Arbeit. Wenn Redis/Valkey ausfällt, darf das nicht bedeuten, dass private Daten verloren sind oder Klartextdaten offengelegt werden.

2. Zusammenspiel der Komponenten

MySQL und Redis/Valkey gehören beide zum Webserver-Betrieb, aber nicht zur gleichen Vertrauens- und Persistenzebene. Die Spark erzeugt Antworten, Vektoren und Audio; sie ist nicht die Datenbank.

3. MySQL: dauerhafte Wahrheit

MySQL ist der Zustandsspeicher von Ephraim. Wenn ein Konto angelegt wird, ein Chat gespeichert wird, ein Projekt entsteht, eine Datei Metadaten bekommt oder ein Knowledge-Chunk indexiert wird, ist MySQL der verbindliche Ort für diese Information. Viele Inhalte liegen dort nicht als Klartext, sondern verschlüsselt oder als Hash, HMAC, Fingerprint, Status oder Metadatum.

Datenbereich	Typische Speicherung in MySQL	Grenze
Konten und Rollen	Benutzername, Rolle, Klasse, Passwort-Hash, 2FA-Status, Session-Version	Kein Klartextpasswort; Tokens werden nicht roh gespeichert.
Chats und Jobs	verschlüsselte Nachrichten, Jobstatus, verschlüsselte Payloads, Stream-Fallbacks	Private Inhalte bleiben an Vault oder Scope gebunden.
Dateien	Metadaten, Status, verschlüsselter Anzeigename, Speicherreferenz, Hashes	Dateiinhalt liegt verschlüsselt im Storage, nicht öffentlich im Webroot.
RAG und Basiswissen	verschlüsselte Text-Chunks, verschlüsselte Embedding-Vektoren, Quellstatus	Retrieval, Rechteprüfung und Scoreberechnung laufen in der Webanwendung.
Admin und Betrieb	Systemeinstellungen, Cronstatus, Komponentenfreigaben, Auditmetadaten	Adminrechte öffnen keine fremden Vault-Klartexte.

4. Redis/Valkey: kurzlebiger Speed-Layer

Redis/Valkey wird nur dort gebraucht, wo Latenz zählt: bei laufenden Antwortstreams und beim Wecken von Workern. Ein Stream ist eine Antwort, die Stück für Stück beim Browser ankommt. Redis/Valkey kann diese laufenden Stücke schneller bereitstellen, als wenn jeder kurze Zwischenstand ausschließlich über MySQL gelesen würde.

Datenschutzentscheidend ist, was dort nicht liegt. Redis/Valkey speichert keine Klartextchats, keine Dateien, keine Vault-Schlüssel, keine Passwörter, keine Nutzerprofile, keine Sessions, keine RAG-Klartexte und keine Embedding-Vektoren. Stream-Chunks und Reconnect-Snapshots sind verschlüsselt. Wakeup-Signale enthalten nur technische Angaben wie Job-ID, Job-Typ und Zeitpunkt.

Redis/Valkey-Inhalt	Lebensdauer	Einordnung
Verschlüsselte Stream-Chunks	kurzlebig während laufender Antwortstreams	Reconnect und flüssige Ausgabe; kein lesbarer Chattext.
Verschlüsselte Reconnect-Snapshots	kurzlebig	Hilft nach Reload oder Verbindungsunterbrechung.
Worker-Wakeup-Signale	typischerweise bis zu einer Stunde	Technische Metadaten, damit Worker nicht träge pollen müssen.

5. Ausfall und Fallback

Redis/Valkey ist nicht die Quelle der Wahrheit. Ephraim schreibt Streamdaten weiterhin in den dauerhaften MySQL-Pfad beziehungsweise kann den Datenbankpuffer als Fallback verwenden. Ein Redis/Valkey-Problem ist deshalb in erster Linie ein Betriebs- und Performanceproblem: Streams können langsamer werden oder der Fallback muss greifen. Es ist kein Verlust privater Inhalte.

Für Administratoren heißt das: MySQL-Verfügbarkeit, Backup und Restore sind systemkritisch. Redis/Valkey-Verfügbarkeit ist wichtig für Reaktionsgeschwindigkeit und Worker-Latenz, aber nicht für die dauerhafte Integrität privater Daten.

6. Betriebsregeln für Production

MySQL ist die produktive Datenbank und Teil des Backup- und Restore-Konzepts.
Redis/Valkey läuft auf demselben Host wie die Webanwendung.
Redis/Valkey ist nur maschinenintern erreichbar; es gibt keinen öffentlichen Port.
Redis/Valkey wird nicht an externe Dienste, Monitoringanbieter oder Managed-Redis ausgelagert.
Redis/Valkey-Persistenz bleibt für diesen Zweck deaktiviert.
Redis/Valkey-Datenverzeichnisse werden nicht als dauerhafte Ephraim-Datenquelle gesichert.
Diagnosebefehle, die alle Redis-Kommandos mitschneiden, gehören nicht in den Regelbetrieb.
Redis/Valkey wird nicht für Sessions, Vaults, Dateien, Nutzerprofile, RAG-Klartexte oder dauerhafte Queues zweckentfremdet.

Neubewertung nötig: Wenn Redis/Valkey über Hostgrenzen hinweg betrieben, persistent gesichert, repliziert, extern erreichbar oder für neue Datenarten verwendet wird, ist das keine kleine technische Änderung. Dann müssen Datenschutz, Betrieb und Dokumentation neu bewertet werden.

7. Admin-Checkliste

Prüfpunkt	Erwartung
MySQL erreichbar	App, Login, Chat, Projekte, Dateien und Adminbereich funktionieren.
MySQL-Backup	Datenbankdump und Restore-Test sind dokumentiert.
Redis/Valkey erreichbar	Streams und Worker reagieren schnell; bei Ausfall greift der Datenbankpfad.
Redis/Valkey nicht extern	Keine öffentliche Erreichbarkeit, kein externer Dienst, kein Managed-Redis.
Redis/Valkey nicht persistent	Keine dauerhafte Redis-Datenquelle, keine normalen Redis-Datenbackups.
Datenschutzgrenze	Keine Klartextinhalte, Vault-Schlüssel, Dateien, Sessions oder RAG-Klartexte in Redis/Valkey.