Vergleich von Backups der Generation 1 und der Generation 2
Gen 2
Backups mit Instanzen der Generation 1 und Backups (Snapshots) mit Instanzen der Generation 2 unterscheiden sich sowohl hinsichtlich ihres Umfangs als auch hinsichtlich ihres Mechanismus. Herkömmliche Backups (Gen 1) arbeiten auf Dateiebene und erfassen Datenbankdateien sowie Write-Ahead-Logs (WAL). Diese Methode stützt sich auf eine tiefe Integration in die Datenbank-Engine, um die Transaktionskonsistenz und die Datenintegrität zu gewährleisten. Im Gegensatz dazu nutzt Gen 2 Snapshots auf Infrastrukturebene und greift dabei auf die Funktionen für Blockspeicher und Dateifreigaben der VPC von „ IBM “ zurück. Diese Snapshots erstellen nahezu sofortige Kopien auf Volume-Ebene, die schnell und skalierbar sind und selbst bei großen Datensätzen nur minimale Auswirkungen auf die Leistung haben. Ähnlich wie bei den Backups der ersten Generation werden für jede Instanz planmäßige Backups durchgeführt, die täglich während der Backup-Fenster automatisch ausgeführt werden. Sie können eine Liste der Sicherungen für Ihre Instanzen einsehen, Sicherungen auf Abruf auslösen und Sicherungen auf neuen Instanzen wiederherstellen.
Gen 2 bietet zwei Arten von Backups: gekoppelte Backups (für die meisten Dienste) und unabhängige Backups. Unabhängige Sicherungen sind separate Serviceinstanzen, die auch nach dem Löschen der Datenbank bestehen bleiben, während gekoppelte Sicherungen an den Lebenszyklus der Datenbankinstanz gebunden sind.
Unabhängige Backups sind derzeit nur für Databases for MySQL verfügbar. Alle anderen Dienste der Generation 2 nutzen gekoppelte Backups.
Instanzen der Generation 2 können nicht zur Wiederherstellung einer Instanz der Generation 1 verwendet werden, da für die Wiederherstellung anhand eines Volume-Snapshots vollständige Abbilder auf Blockebene erforderlich sind und nicht einzelne Datenbankdateien.
Wichtigste Unterschiede zwischen Gen 1 und Gen 2
| Differenzierer | Gen 1 | Gen 2 |
|---|---|---|
| Verfahren | Sicherungen auf Dateiebene: Es handelt sich um Sicherungen auf Dateiebene, bei denen einzelne Datenbankdateien und WAL-Segmente kopiert werden. Dabei werden für jede Datei in der Sicherung Prüfsummen berechnet, die bei der Wiederherstellung oder Überprüfung erneut überprüft werden. Der Sicherungsmechanismus arbeitet auf der Ebene der Produktanwendung und erfordert eine tiefe Integration in die Datenbank-Engine, um die Transaktionskonsistenz und die Datenintegrität zu gewährleisten. | Sicherungen auf Infrastrukturebene: Bei den Sicherungen kommen Volume-Snapshots auf Infrastrukturebene zum Einsatz, die den gesamten Speicherzustand auf Blockebene erfassen und so die Sicherungsfenster selbst bei Datenbanken mit mehreren Terabyte von Stunden auf Minuten verkürzen. Dieser Ansatz ermöglicht die nahezu sofortige Erstellung von Backups, unabhängig von der Größe der Datenbank. |
| Leistung | Beeinflusst die Leistung des Datenbankprozesses, da CPU- und Speicherressourcen beansprucht werden. | Backups laufen unabhängig vom Datenbankprozess ab und haben daher keinen Einfluss auf den CPU- und RAM-Verbrauch der Datenbanken. |
| Zugriff auf Wiederherstellungen | Verzögerter Zugriff auf Wiederherstellungen. Bei Backups müssen die Dateien vor dem Start der Datenbank vollständig wiederhergestellt werden. Während des Wartungsfensters ist kein Zugriff möglich. | Sofortiger Zugriff auf Wiederherstellungen bei verminderter E/A-Leistung, bis die Hydratisierung abgeschlossen ist. Ein Volume aus einem Snapshot wiederherstellen. |
| Maximale Wiederherstellungszeit nach einem Ausfall (RTO, Recovery Time Objective) | Längere RTO. Die Wiederherstellung des Zugriffs auf die Daten skaliert nahezu linear mit dem wachsenden Datenvolumen, was bei großen Datenbanken mehrere Stunden dauern kann. | Schnelle RTO: Die Wiederherstellung des Zugriffs auf die Daten dauert nur wenige Minuten und ist unabhängig vom Datenvolumen. Allerdings kann es während des Wiederherstellungsprozesses zu einer vorübergehenden Beeinträchtigung der E/A-Leistung kommen, wobei das Ausmaß dieser Beeinträchtigung von der Datenmenge abhängt. |
| Tolerierter Datenverlust aufgrund von Ausfällen (RPO - Recovery Point Objective) | Wird in festen Zeitabständen ausgeführt, wodurch potenzielle Zeitfenster für Datenverluste entstehen. | Kann häufig eingenommen werden, ohne die Leistung nennenswert zu beeinträchtigen. |
| Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) | Ja | Zukünftige Veröffentlichung. |
Funktionen für unabhängige Backups
Mit Gen 2 werden eigenständige Backups für „ Databases for MySQL “ eingeführt. Diese Backups bieten Funktionen, die über herkömmliche gekoppelte Backups hinausgehen:
| Feature | Gen 1 | Gen 2 (gekoppelt) | Gen 2 (unabhängig) |
|---|---|---|---|
| Lebenszyklus | Mit Instanz verknüpft | Mit Instanz verknüpft | Unabhängig von der Instanz |
| Ansichten auf Kontoebene | Nicht unterstützt | Nicht unterstützt | Datenbank-Hub mit zentraler Übersicht |
| Löschen von Sicherungskopien | Nur Automatik | Nur Automatik | Manuell und automatisch |
| Standort der Sicherungskopie | Fest | Regionssperre | Regionssperre; zukünftige Version wird Sicherungskopien unterstützen |
| Persistenz | Zusammen mit der Instanz gelöscht | Zusammen mit der Instanz gelöscht | Kann nach dem Löschen der Instanz beibehalten werden |
| Management | Datenbank-APIs | Nur Benutzeroberfläche | Datenbank-Hub, Ressourcenliste, Instanz-Benutzeroberfläche |
Unabhängige Backups sind derzeit nur für Databases for MySQL verfügbar. Alle anderen Dienste der Generation 2 nutzen gekoppelte Backups.
Weitere Informationen zu unabhängigen Sicherungen finden Sie unter „ Verwalten unabhängiger Sicherungen “.
Verwaltung von Gen-2-Backups
So verwalten Sie Ihre Gen-2-Backups:
- Informationen zu „ Databases for MySQL “ finden Sie unter „ Verwalten unabhängiger Backups “.
- Informationen zu allen anderen Gen-2-Diensten finden Sie unter „ Verwalten von Backups “.