Thore Cimbal
c64b3290e8
#0056 asked for HA plus replication. The cluster is one node, measured repeatedly during #0088 and written into two manifests as a constraint. Replication on a single node does not buy what "HA" means, and the loss case is already covered by rehearsed restores rather than by replication. Struck as sorb decided; it becomes a new issue if a second node ever exists. #0004 is a homelab host and outside this project's scope. It held the milestone open without ever being worked. #0078 (CVE reporting path v2) goes to in-progress.
1.7 KiB
type, id, status, created, milestone, priority, area, projekt, gitlab_iid, related
| type | id | status | created | milestone | priority | area | projekt | gitlab_iid | related |
|---|---|---|---|---|---|---|---|---|---|
| issue | 0056 | rejected | 2026-05-14 | M1 | high | database | gitops | 9 |
External PostgreSQL Migration: CloudNativePG or Hetzner
Adoptiert aus gitops#9 (2026-08-18, ADR-0019). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei.
Migrate from ESS embedded Postgres to external database. Setup HA + Replication. Test all services. Est. Time: 1-2 days
Migriert aus Gitea sorb/axion1337.chat-gitops#9 — dort erstellt am 2026-05-14 von sorb.
Gestrichen — 2026-08-21
Entscheidung sorb: overkill. Das Ziel des Issues war „Setup HA + Replication".
Der Cluster besteht aus einem Knoten — bei #0088 mehrfach gemessen und in
networkpolicy.yaml sowie restore-drill-media.yaml als Randbedingung
festgehalten. Replikation auf einem Knoten schützt gegen Prozess- und
Datenfehler, nicht gegen den Ausfall, den „HA" meint. Der Nutzen stünde
damit in keinem Verhältnis zum Risiko, die Datenbank aller Dienste im laufenden
Betrieb zu verschieben.
Was den Zweck heute schon erfüllt: Der Datenverlust-Fall ist über geprobte Wiederherstellung abgedeckt, nicht über Replikation — nächtliche Borg-Sicherung, monatliche Datenbank-Probe und seit dem 2026-08-21 zusätzlich die Medien-Probe (#0030), jede mit eigener Positivkontrolle und Alarmierung.
Wann das wieder aufzumachen ist: sobald ein zweiter Knoten existiert. Dann ist es ein neues Issue mit einem Ziel, das auf der dann vorhandenen Topologie überhaupt erreichbar ist.