Speicher und Wiederherstellung
Wählen Sie den Speicher danach aus, welche Daten einen Prozessneustart, ein neues Deployment oder einen Host-Ausfall überstehen müssen. Das sind unterschiedliche Ereignisse. Persistenter Speicher bietet für sich allein weder ein Backup noch einen Wiederherstellungspunkt oder Hochverfügbarkeit.
| Daten | Wo sie gespeichert werden sollten | Grenze |
|---|---|---|
| Anwendungsdaten | Managed Postgres oder eine andere Datenbank | Ein Neustart ist etwas anderes als das Wiederherstellen gelöschter oder beschädigter Daten. Testen Sie einen separaten Export- und Wiederherstellungsweg. |
| Cache- und Queue-Daten | Managed Redis | Entscheiden Sie, ob die Workload ihren Zustand neu aufbauen kann oder einen eigenen Wiederherstellungsplan braucht. Managed Redis hat weder eine Eviction-Richtlinie noch ein Append-only-File: Wenn der Arbeitsspeicher ausgeht, startet es neu und neuere Schreibvorgänge können verloren gehen. Speichern Sie Daten, die Sie nicht verlieren dürfen, in Managed Postgres. |
| Von Anwendungen gemeinsam genutzte Dateien | Managed Object Storage | Der automatisch erstellte Bucket default ist privat. Machen Sie einen Bucket nur dann im Bucket-Browser des Dashboards öffentlich, wenn jeder seine Dateien lesen darf. |
Für Sandbox-Dateien gelten andere Regeln: Nur Dateien auf einem angehängten Volume aus Persistent Volumes unter /workspace überdauern eine Sandbox. Siehe Speicher und Abrechnung.
Dateien nach dem Ende einer Sandbox behalten
Der Reiter Persistent Volumes verwaltet benannte Volumes und ihre Verbindungen. Hängen Sie ein Volume bei der Erstellung an und schreiben Sie nach /workspace. Stoppen Sie die aktuelle Sandbox, bevor Sie das Volume an eine andere hängen.
Wiederherstellung einer Datenbank planen
Vor einer Migration oder einem Release, das Daten verändert:
- Wählen Sie eine Exportmethode für die verwendete Datenbank und Version.
- Speichern Sie den Export getrennt von der Ressource, die geändert wird.
- Stellen Sie ihn in einer separaten Testdatenbank wieder her und prüfen Sie, ob die Anwendung ihn lesen kann.
- Halten Sie die Dauer der Wiederherstellung und die neuesten im Export enthaltenen Daten fest.
Gehen Sie nicht davon aus, dass es geplante Backups, Point-in-Time-Recovery, Multi-Node-Replikation oder eine Garantie für die Wiederherstellungszeit gibt, nur weil eine Datenbank verwaltet wird. Prüfen Sie die aktuelle Servicevereinbarung und die verfügbaren Steuerungsmöglichkeiten für Ihre Ressource.
Umgebungsreferenzen
Eine Anwendung sollte ihre Datenbankverbindung aus einer Umgebungsreferenz lesen. Ein Connection String ist ein Zugangsdatengeheimnis; geben Sie ihn nicht aus, um eine Aktualisierung zu prüfen. Eine Verbindungsprüfung wie SELECT 1 belegt mehr, als die Variable nur in einer Shell zu sehen.
Verwandte Anleitungen
- Managed Postgres
- Managed Redis
- Managed Object Storage
- Persistent Volumes
- Deployment-Wiederherstellung
Aktualisiert