Eine Aufbewahrungsfrist als Löschjobs umsetzen

Ziel

Eine schriftlich festgelegte Aufbewahrungsfrist (zum Beispiel: Sitzungsdatensätze 30 Tage nach der letzten Aktivität, Support-Tickets zwei Jahre nach Abschluss) in Jobs umsetzen, die pünktlich, nachprüfbar und ohne Ausfall des Dienstes löschen. Welche Fristen für welche Daten richtig sind, ist eine organisatorische Entscheidung und nicht Teil dieser Methode.

Voraussetzungen

Eine Aufbewahrungstabelle: eine Zeile pro Datenklasse mit dem Speicher, der Uhr, die die Frist startet (Erstellung, letzte Aktivität, Abschluss), der Frist und der verantwortlichen Person. Jede Tabelle oder jeder Bucket mit Personendaten wird auf eine Zeile abgebildet. Zeitstempel, aus denen sich die Frist berechnen lässt (eine Spalte closed_at, kein Statusflag ohne Datum).

Schritte

1. Den Mechanismus pro Speicher wählen. Zeitpartitionierte Tabellen: die abgelaufene Partition droppen oder abtrennen; die PostgreSQL-Dokumentation hält fest, dass DROP TABLE oder ALTER TABLE DETACH PARTITION auf einer Partition weit schneller ist als eine Massenoperation und den VACUUM-Aufwand eines Massen-DELETE vermeidet, dass beide eine ACCESS EXCLUSIVE-Sperre auf der übergeordneten Tabelle benötigen, und dass DETACH PARTITION ... CONCURRENTLY nur eine SHARE UPDATE EXCLUSIVE-Sperre braucht. Objektspeicher: Lifecycle-Regeln; die Amazon-S3-Dokumentation beschreibt Ablaufaktionen, die abgelaufene Objekte im Auftrag des Kontos löschen. Alles Übrige: ein batchweises DELETE ... WHERE clock < now() - interval mit einem festen Zeilenlimit pro Durchlauf und einer Pause zwischen den Durchläufen, das Limit gewählt anhand der beobachteten Last des Speichers.
2. Den Job idempotent und fortsetzbar schreiben: Jeder Durchlauf wählt den nächsten Batch abgelaufener Zeilen aus, löscht, protokolliert die Anzahl und endet; ein Absturz mitten im Durchlauf kostet nichts.
3. Zuerst abhängige Datensätze löschen, oder bewusst auf ON DELETE CASCADE setzen und die Kaskade in der Aufbewahrungstabelle vermerken.
4. Den Job mit einer Sperre planen, sodass nie zwei Instanzen gleichzeitig laufen; pro Durchlauf ausgeben: geprüfte Zeilen, gelöschte Zeilen, Alter der ältesten verbleibenden Zeile.
5. Bei der ältesten verbleibenden Zeile alarmieren: Ist irgendeine Zeile älter als die Frist plus eine Kulanzspanne, ist der Job defekt, unabhängig davon, ob er Fehler meldet.
6. Im Trockenlauf-Modus starten: zählen, was gelöscht würde, mit der Erwartung vergleichen, dann aktivieren.
7. Weitergeben: abgeleitete Speicher (Suchindex, Analytics-Tabellen, Caches) laufen entweder selbst nach derselben Frist ab oder abonnieren die Löschereignisse.

Erwartetes Ergebnis

Jede Datenklasse hat einen Job oder eine Lifecycle-Regel, eine Metrik und einen Alarm; das Alter der ältesten Zeile bleibt unter der Frist; Aufbewahrung ist eine Eigenschaft des laufenden Systems statt eines Dokuments.

Grenzen und Prüfbasis

Backups liegen ausserhalb der Frist; die eigene Aufbewahrungsdauer eines Backups begrenzt, wie lange gelöschte Daten überleben. Datensätze unter einer Sperre (Hold) brauchen ein Ausnahme-Flag pro Datensatz, das der Job respektiert; welche Fälle eines benötigen, wird hier nicht behandelt. Sperr- und Lifecycle-Verhalten folgt der zitierten Dokumentation; es werden keine Durchsatzzahlen behauptet.