97 lines
4.1 KiB
Markdown
97 lines
4.1 KiB
Markdown
# Codex-Brief — DB-Namen-Altlast beseitigen (stiller Daten-GAU)
|
||
|
||
**Priorität: vor der ersten echten `@dr-gold.de`-Migration.** Das ist kein
|
||
Kosmetikproblem.
|
||
|
||
## Der Befund
|
||
|
||
| Stelle | `db_path` |
|
||
|---|---|
|
||
| `config.json.example` | `mail-graveyard.db` |
|
||
| `INSTALL.md` (`cp config.json.example config.json`) | → `mail-graveyard.db` |
|
||
| Code-Default in `ConnectDB` (02-database.go) | `mail-graveyard.db` |
|
||
| **LIVE auf GoldPi** | **`/app/data/emailforwarder.db`** ← hier liegen die echten Daten |
|
||
|
||
Im `data/`-Verzeichnis liegen aktuell:
|
||
```
|
||
emailforwarder.db 380.928 <- die ECHTEN Daten
|
||
emailforwarder.db-wal 4.124.152 <- ACHTUNG: groesser als die DB selbst!
|
||
emailforwarder.db-shm 32.768
|
||
mail-graveyard.db 0 <- Leiche
|
||
email-forwarder.db 0 <- Leiche
|
||
```
|
||
|
||
**Der Schaden, wenn der Default je greift** (jemand folgt der eigenen
|
||
INSTALL.md, oder `db_path` fehlt in einer Config): SQLite legt klaglos eine
|
||
**frische, leere DB** an. Konten weg, `copied`-Historie weg. Der Watcher sieht
|
||
eine leere `copied`-Tabelle und **kopiert jede Mail erneut in die
|
||
Ziel-Postfaecher** → **Dubletten quer ueber alle ~20 echten dr-gold-Postfaecher**,
|
||
lautlos, ohne einen einzigen Fehler im Log.
|
||
|
||
## Teil A — Die Daten umziehen (einmalige Ops-Aktion)
|
||
|
||
**Ist-Zustand als Baseline (muss danach identisch sein; Jobs duerfen durch
|
||
laufende Watch-/Deploy-Laeufe weiterzaehlen):**
|
||
`accounts=19`, `copied=215`, `app_users=3`, `jobs=294` vor Ops,
|
||
`jobs=296` nach Deploy-Abnahme.
|
||
|
||
Reihenfolge ist wichtig — **das WAL ist der gefaehrliche Teil**:
|
||
|
||
```sh
|
||
APP=/mnt/DATA/Containers/Test-Container/Mail-Graveyard-Pod
|
||
D=$APP/data
|
||
|
||
# 1. BEIDE Container stoppen -> kein Schreiber mehr auf der DB
|
||
podman stop mail-graveyard mail-graveyard-watch
|
||
|
||
# 2. Backup, bevor irgendwas angefasst wird (inkl. WAL/SHM!)
|
||
cp -a $D/emailforwarder.db $D/BACKUP-emailforwarder.db
|
||
cp -a $D/emailforwarder.db-wal $D/BACKUP-emailforwarder.db-wal
|
||
|
||
# 3. WAL in die Haupt-DB falten. OHNE DAS gehen 4 MB Daten verloren.
|
||
sqlite3 $D/emailforwarder.db "PRAGMA wal_checkpoint(TRUNCATE);"
|
||
|
||
# 4. Gegenpruefen, dass alles noch da ist
|
||
sqlite3 $D/emailforwarder.db "SELECT
|
||
(SELECT COUNT(*) FROM accounts), (SELECT COUNT(*) FROM copied),
|
||
(SELECT COUNT(*) FROM app_users), (SELECT COUNT(*) FROM jobs);"
|
||
# -> MUSS accounts=19, copied=215, app_users=3 liefern. Wenn nicht: STOPP,
|
||
# nichts weiter tun. jobs kann waehrend Watch/Deploy weiterwachsen.
|
||
|
||
# 5. Erst jetzt umbenennen (ueberschreibt die 0-Byte-Leiche)
|
||
mv -f $D/emailforwarder.db $D/mail-graveyard.db
|
||
rm -f $D/emailforwarder.db-wal $D/emailforwarder.db-shm $D/email-forwarder.db
|
||
|
||
# 6. Config umstellen
|
||
# $APP/config.json: "db_path": "/app/data/mail-graveyard.db"
|
||
```
|
||
|
||
## Teil B — Die Ursache beseitigen (Code + Repo)
|
||
|
||
1. `deploy/goldpi-test-container/mail-graveyard-pod/config.json` **und**
|
||
`config.json.example`: `db_path` auf `mail-graveyard.db` — damit Doku, Deploy
|
||
und Live endlich dasselbe sagen.
|
||
2. **Kein stilles Anlegen mehr.** Das ist die eigentliche Wurzel: `ConnectDB`
|
||
erzeugt heute klaglos eine leere DB, wenn die Datei fehlt. Bau eine
|
||
Sicherung ein:
|
||
- Wenn die DB-Datei **nicht existiert**, nur dann anlegen, wenn explizit
|
||
`--init-db` uebergeben wurde. Sonst: **laut scheitern** mit
|
||
`DB %q existiert nicht — mit --init-db neu anlegen oder db_path pruefen`
|
||
und Exit ≠ 0.
|
||
- Damit wird aus einem stillen Daten-GAU ein sofort sichtbarer Startfehler.
|
||
Dasselbe Prinzip wie beim Watch-Fail-Fast: **permanenter Konfigfehler muss
|
||
schreien, nicht schweigen.**
|
||
|
||
## Abnahme
|
||
|
||
1. Container wieder hoch, dann in der DB pruefen:
|
||
`accounts=19`, `copied=215`, `app_users=3`, `jobs=289` — **identisch**.
|
||
2. **Der entscheidende Test:** Der erste Watcher-Lauf nach dem Umzug muss
|
||
`copied=0` melden (`total=215 copied=0 errors=0`).
|
||
→ Meldet er stattdessen `copied=215`, ist die Dedup-Historie verloren
|
||
gegangen und er schreibt gerade Dubletten ins Ziel. **Sofort stoppen** und
|
||
das Backup aus Schritt 2 zurueckspielen.
|
||
3. Login in der Web-UI funktioniert weiter (die 3 Benutzer sind mitgezogen).
|
||
4. `go test ./...` gruen.
|
||
|
||
Ich (Claude) verifiziere danach Punkt 1–3 unabhaengig auf GoldPi.
|