Bigtable-Sicherungen – Übersicht
Diese Seite bietet einen Überblick über Bigtable-Sicherungen. Inhalt ist für Bigtable-Administratoren gedacht zu entwickeln.
Mit Bigtable-Sicherungen können Sie eine Kopie einer das Schema und die Daten der Tabelle und stellen Sie sie später aus der Sicherung in einer neuen Tabelle wieder her. Sie können Sicherungen manuell erstellen oder automatisierte Sicherungen aktivieren Back-up, damit Bigtable tägliche Sicherungen erstellen kann. Sie können auch eine Kopie einer Sicherung.
Bevor Sie diese Seite lesen, sollten Sie sich mit den Bigtable overview und Manage Tabellen.
Features
- Vollständig integriert: Sicherungen werden vollständig vom Bigtable-Dienst verarbeitet, ohne dass ein Import oder Export erforderlich ist.
- Inkrementell: Eine Sicherung teilt den physischen Speicher mit der Quelltabelle und andere Sicherungen der Tabelle.
- Kosteneffizient: Mit Bigtable-Sicherungen können Sie die Kosten für das Exportieren, Speichern und Importieren von Daten mit anderen Diensten vermeiden.
- Automatisches Ablaufdatum: Jede Sicherung hat ein benutzerdefiniertes Ablaufdatum, kann bis zu 90 Tage nach dem Erstellen der Sicherung sein. Ich kann eine Kopie einer Sicherung bis zu 30 Tage lang speichern.
- Flexible Wiederherstellungsoptionen: Sie können eine Sicherung in einer Tabelle einer anderen Instanz wiederherstellen, in der die Sicherung nicht erstellt wurde.
- Automatische Sicherung: Aktivieren Sie die automatische Sicherung, Bigtable erstellt tägliche Sicherungen.
Anwendungsfälle
Sicherungen sind für die folgenden Anwendungsfälle nützlich:
- Geschäftskontinuität
- Gesetzliche Vorschriften
- Tests und Entwicklung
- Notfallwiederherstellung
Betrachten Sie die folgenden Szenarien für die Notfallwiederherstellung:
| Ziel | Sicherungsstrategie | Wiederherstellungsstrategie |
|---|---|---|
| Schutz vor menschlichen Fehlern : Sie möchten immer für den Fall, dass Sie versehentlich Löschung oder Beschädigung. | Legen Sie einen geeigneten Zeitplan für die Erstellung von Sicherungen fest. Geschäftsanforderungen zu erfüllen, z. B. täglich. Optional können Sie regelmäßige Kopien von und in einem anderen Projekt oder einer anderen Region speichern, für mehr Isolation und Schutz. Für noch mehr Schutz solltest du die Kopien in einem Projekt oder einer Instanz mit eingeschränkten Zugriffsberechtigungen. | Stellen Sie die Daten aus der Sicherung oder Kopie in einer neuen Tabelle wieder her und leiten Sie sie dann um. an die neue Tabelle senden. |
| Nichtverfügbarkeit von Zonen : Sie müssen sicherstellen, dass den unwahrscheinlichen Fall, dass eine Google Cloud-Zone nicht mehr verfügbar ist, sind Ihre Daten weiterhin verfügbar. | Erstellen Sie regelmäßig, z. B. täglich, Sicherungen. In regelmäßigen Abständen eine Kopie der letzten Sicherung erstellen und auf einer oder mehreren Cluster in verschiedenen Zonen (optional in einer anderen Instanz oder Projekt). | Wenn die Zone, in der der Bereitstellungscluster nicht mehr verfügbar ist, wieder verfügbar ist, aus der Remote-Sicherungskopie in eine neue Tabelle an die neue Tabelle senden. |
| Datenbeschädigung: Verwenden Sie eine Sicherung zur Wiederherstellung. der Daten einer Tabelle, z. B. wenn ein Teil der Quelltabelle korrumpiert werden. | Erstellen Sie regelmäßig Sicherungen Ihrer Daten. | Stellen Sie die Sicherung in einer neuen Tabelle auf der neuen Instanz wieder her. Dann eine Anwendung mit einer Bigtable-Clientbibliothek oder Dataflow, das aus dem neuen und schreibt die Daten dann zurück in die Quelltabelle. Wenn der Parameter Daten in die ursprüngliche Tabelle kopiert, löschen Sie die neue . |
Mit Bigtable-Sicherungen arbeiten
Die folgenden Aktionen sind für Bigtable-Sicherungen verfügbar. Insgesamt Cases, das Zielprojekt, die Instanz und der Cluster müssen bereits vorhanden sein. Ich können diese Ressourcen nicht als Teil eines Sicherungsvorgangs erstellen. Sie sind keine Kopie einer Sicherungskopie erstellen.
| Aktion | Zieloptionen |
|---|---|
| Sicherung erstellen |
|
| Aus einer Sicherung in einer neuen Tabelle wiederherstellen |
|
| Sicherung kopieren |
|
Unter Sicherungen verwalten finden Sie eine detaillierte Anleitung zu Aktionen wie die Aktualisierung und das Löschen von Sicherungen.
So verwenden Sie Bigtable-Sicherungen:
- Die Google Cloud Console
- Google Cloud CLI
- Cloud Bigtable-Clientbibliotheken.
Sie können auch direkt auf die Cloud Bigtable Admin API zugreifen, dies wird jedoch dringend empfohlen. nur, wenn Sie keine Cloud Bigtable-Clientbibliothek verwenden können, Back-up-Aufrufe an die API senden.
So funktionieren Bigtable-Sicherungen
Das Erstellen einer Sicherung umfasst das Verständnis des Sicherungsspeichers und der Aufbewahrung in Bigtable.
Sicherungsspeicher
Sie können eine Tabellensicherung manuell erstellen oder die automatische Sicherung aktivieren, Bigtable für tägliche Sicherungen anzulegen. Eine Tabellensicherung wird in einem Cluster in einem Instanz. Bei manuellen Sicherungen wird die Tabellensicherung in einem Cluster im Instanz, die Sie auswählen. Wenn die automatische Sicherung aktiviert ist, wird eine Tabellensicherung auf jedem Cluster in der Instanz.
Eine Sicherung einer Tabelle umfasst alle Daten, die zum Zeitpunkt der Erstellung der Sicherung in der Tabelle enthalten waren, und zwar in dem Cluster, in dem die Sicherung erstellt wird. Eine Sicherung ist nie größer als die Quelltabelle zum Zeitpunkt der Sicherung.
Bigtable-Sicherungen sind inkrementell. Der Speicherplatz den eine Sicherung verbraucht, hängt von der Größe der Tabelle und dem Ausmaß ab, Er kann die Speicherung unveränderter Daten mit der ursprünglichen Tabelle oder anderen Sicherungen teilen. aus derselben Tabelle. Aus diesem Grund hängt die Größe einer Sicherung von der Datenabweichungen seit der vorherigen Sicherung.
Sie können bis zu 150 Sicherungen pro Tabelle und Cluster.
Sie können eine Tabelle mit einer Sicherung löschen. Zum Schutz Ihrer Sicherungen können Sie keine Cluster löschen, die eine Sicherung enthalten. Außerdem können Sie keine Instanzen löschen, die in einem Cluster eine oder mehrere Sicherungen enthalten.
Eine Sicherung ist nach dem Wiederherstellen in einer neuen Tabelle noch vorhanden. Sie können Folgendes löschen: oder ablaufen zu lassen, wenn Sie sie nicht mehr benötigen. Der Sicherungsspeicher wird nicht berücksichtigt In Höhe des Knotenspeicherlimits für ein Projekt.
Die Daten in Sicherungen sind verschlüsselt.
Aufbewahrung
Sie können eine Aufbewahrungsdauer von bis zu 90 Tagen für ein Back-up. Wenn Sie eine Kopie einer Sicherung erstellen, ist die maximale Aufbewahrungsdauer für Kopie 30 Tage nach ihrer Erstellung.
Für Tabellen mit aktivierter automatischer Sicherung beträgt die standardmäßige Aufbewahrungsdauer 3 Tage. Sie können die Aufbewahrungsdauer für eine Sicherung auf bis zu 90 Tage ändern ab dem Zeitpunkt der Sicherungserstellung.
Nach der Wiederherstellung
Die Speicherkosten für eine neue Tabelle, die aus einer Sicherung wiederhergestellt wurde, entsprechen denen anderer beliebiger Tabellen.
Eine aus einer Sicherung wiederhergestellte Tabelle verbraucht möglicherweise nicht so viel Speicherplatz wie und die Größe der Tabelle kann sich nach der Wiederherstellung verringern. Der Größenunterschied hängt davon ab, wie lange die Verdichtung kürzlich im Quell- und Zielcluster aufgetreten ist.
Da die Verdichtung rollierend erfolgt, kann es vorkommen, dass die Verdichtung erfolgt, sobald die Tabelle erstellt wurde. Die Verdichtung kann jedoch bis zu eine Woche dauern.
Eine neue Tabelle, die aus einer Sicherung wiederhergestellt wurde, übernimmt die automatische Speicherbereinigung nicht der Quelltabelle. Konfigurieren Sie die Richtlinien für die automatische Speicherbereinigung in der neuen bevor Sie neue Daten in die Tabelle schreiben. Weitere Informationen finden Sie unter Automatische Speicherbereinigung konfigurieren
Kosten
Bei der Arbeit mit Sicherungen fallen die Standard-Netzwerkkosten an. Ihnen werden keine Kosten in Rechnung gestellt. für Sicherungsvorgänge wie das Erstellen, Kopieren oder Wiederherstellen aus einer Sicherung.
Speicherkosten
Wenn Sie eine Sicherung oder eine Kopie einer Sicherung speichern möchten, wird die Standardsicherung in Rechnung gestellt Speicherpreis für die Region, in der sich der Cluster mit der oder Sicherungskopie befindet.
Eine Sicherung ist eine vollständige logische Kopie einer Tabelle. Im Hintergrund optimiert Bigtable die Speicherauslastung für Sicherungen. Diese Optimierung bedeutet, dass eine Sicherung inkrementell ist, d. h., sie teilt physischen Speicher mit dem Originaltabelle oder nach Möglichkeit mit anderen Sicherungen der Tabelle. Aus den integrierten Speicheroptimierungen von Bigtable, die Kosten für die Speicherung einer Sicherung oder eine Kopie einer Sicherung kann manchmal unter den Kosten für eine vollständige eine physische Kopie der Tabellensicherung.
In replizierten Instanzen, in denen die automatische Sicherung aktiviert ist, können die Speicherkosten höher sein da in jedem Cluster täglich Sicherungen erstellt werden.
Kosten beim Kopieren einer Sicherung
Wenn Sie eine Kopie einer Sicherung in einer anderen Region als die der Quellsicherung erstellen, werden Ihnen Standardnetzwerkpreise für das Kopieren der Daten in die Zielcluster. Für den Netzwerkverkehr fallen keine Kosten an, wenn Sie eine in derselben Region wie die Quellsicherung zu kopieren.
Kosten bei der Wiederherstellung
Wenn Sie eine neue Tabelle aus einer Sicherung wiederherstellen, werden Ihnen die Netzwerkkosten für die Replikation in Rechnung gestellt. Wenn sich die neue Tabelle in einer Instanz mit Replikation befindet, werden Ihnen einmalige Replikationskosten in Rechnung gestellt, damit die Daten in alle Cluster in der Instanz kopiert werden.
Wenn Sie eine Wiederherstellung auf einer anderen Instanz durchführen als der, in der die Sicherung erstellt wurde, und Die Instanz der Sicherung und die Zielinstanz haben nicht mindestens eine sich in derselben Region befinden, werden einmalig die Kosten für die ersten Daten in Rechnung gestellt. Daten in den Zielcluster zu den Standard-Netzwerktarifen kopieren.
CMEK
Wenn Sie eine Sicherung in einem Cluster erstellen, der durch einen vom Kunden verwalteten Verschlüsselungsschlüssel (Customer-Managed Encryption Key, CMEK) geschützt ist, wird die Sicherung an die primäre Version des CMEK-Schlüssels des Clusters angepinnt zum Zeitpunkt an dem sie vorgenommen wird. Nachdem die Sicherung erstellt wurde, können Schlüssel und Schlüsselversion nicht mehr geändert werden, auch nicht, wenn der KMS-Schlüssel rotiert wird.
Wenn Sie aus einer Sicherung wiederherstellen, muss die Schlüsselversion, an die die Sicherung angepinnt ist, aktiviert sein, damit die Sicherung entschlüsselt werden kann. Die neue Tabelle wird mit der neuesten primären Version des CMEK-Schlüssels für jeden Cluster in der Zielinstanz geschützt. Wenn Sie aus einer CMEK-geschützten Sicherung eine Wiederherstellung in einer anderen Instanz ausführen möchten, muss die Zielinstanz ebenfalls CMEK-geschützt sein; sie muss jedoch nicht dieselbe CMEK-Konfiguration wie die Quellinstanz haben.
Überlegungen zur Replikation
In diesem Abschnitt werden zusätzliche Konzepte beschrieben, mit denen Sie verstehen, wann eine Tabelle in einer Instanz, die Replikation verwendet, gesichert und wiederhergestellt wird.
Replikation und Sicherung
Wenn Sie eine Tabelle manuell in einer replizierten Instanz sichern, wählen Sie dem Cluster, in dem Sie die Sicherung erstellen und speichern möchten. Für Tabellen mit automatische Sicherung aktiviert ist, wird eine tägliche Sicherung für jeden Cluster im Instanz.
Sie müssen das Schreiben in den Cluster, der die Sicherung enthält, nicht anhalten. Sie sollten aber wissen, wie replizierte Schreibvorgänge in den Cluster verarbeitet werden.
Eine Sicherung ist eine Kopie der Tabelle in ihrem Zustand auf dem Cluster, in dem die Sicherung zum Zeitpunkt der Sicherung erstellt wird. Tabellendaten, die noch nicht von einem anderen Cluster in der Instanz repliziert wurden, sind nicht in der Sicherung enthalten.
Jede Sicherung hat eine Start- und Endzeit. Schreibvorgänge, die kurzzeitig vor oder während des Sicherungsvorgangs an den Cluster gesendet werden, sind nicht in der Sicherung enthalten. Zwei Faktoren beeinflussen diese Unsicherheit:
- Es kann sein, dass ein Schreibvorgang an einen Abschnitt der Tabelle gesendet wird, den die Sicherung bereits kopiert hat.
- Ein Schreibvorgang in einen anderen Cluster wurde möglicherweise nicht in den Cluster repliziert, der enthält die Sicherung.
Es besteht also die Möglichkeit, dass einige Schreibvorgänge mit einem Zeitstempel vor der Sicherung in der Sicherung nicht enthalten sind. Dies gilt auch für Sicherungen, wenn die automatische Sicherung aktiviert ist. Die Sicherungen einer Instanz sind keine exakten Kopien voneinander da die Sicherungszeiten von Cluster zu Cluster variieren können.
Wenn diese Inkonsistenz für Ihre Geschäftsanforderungen inakzeptabel ist, können Sie eine einheitliche Token mit Ihren Schreibanfragen, um sicherzustellen, dass alle replizierten Schreibvorgänge sind in einer Sicherung enthalten.
Replikation und Wiederherstellung
Wenn Sie eine Sicherung in einer neuen Tabelle wiederherstellen, beginnt die Replikation zu und von den anderen Clustern in der Instanz sofort, nachdem der Wiederherstellungsvorgang auf dem Zielcluster abgeschlossen ist.
Leistung
Beachten Sie beim Erstellen von Sicherungen die folgenden Best Practices, damit Ihre dass die Leistung optimal bleibt.
Leistung bei der Sicherung
Das Erstellen einer Sicherung dauert in der Regel weniger als eine Minute, kann aber bis zu einer Stunde dauern. Unter normalen Umständen wirkt sich die Sicherungserstellung nicht auf die Bereitstellungsleistung aus.
Für eine optimale Leistung sollten Sie eine Sicherung einer einzelnen Tabelle nicht öfter als einmal alle fünf Minuten. Wenn häufiger Sicherungen erstellt werden, kann dies zu einer steigenden Bereitstellungslatenz führen.
Leistung beim Wiederherstellen
Die Wiederherstellung aus einer Sicherung in eine Tabelle in einer Instanz mit einem einzelnen Cluster dauert einige Minuten. In replizierten Instanzen dauert die Wiederherstellung länger, da die Daten in alle Cluster kopiert werden. Bigtable wählt immer die effizienteste Route zum Kopieren von Daten aus.
Wenn Sie die Instanz in einer anderen Instanz wiederherstellen, als die Sicherung erstellt wurde, dauert die Wiederherstellung länger als bei einer Wiederherstellung in derselben Instanz. Dies gilt insbesondere, wenn die Zielinstanz keinen Cluster in derselben Zone wie der Cluster hat, in dem die Sicherung erstellt wurde.
Bei größeren Tabellen dauert die Wiederherstellung länger als bei kleineren Tabellen.
Wenn Sie eine SSD-Instanz haben, kann es nach dem Abschluss einer Wiederherstellung zu einer höheren Leselatenz kommen, während die Tabelle optimiert wird. Sie können während der Wiederherstellung jederzeit den Status prüfen, um festzustellen, ob die Optimierung noch läuft.
Wenn Sie die Instanz in einer anderen Instanz wiederherstellen, als die Sicherung erstellt wurde, kann es sein, dass die Zielinstanz HDD oder SSD-Speicher verwendet. Sie muss nicht den gleichen Speichertyp wie die Quellinstanz verwenden.
Zugriffssteuerung
IAM-Berechtigungen steuern den Zugriff auf Sicherungs- und Wiederherstellungsvorgänge. Sicherungsberechtigungen werden auf Instanzebene vorgenommen und auf alle Sicherungen in der Instanz angewendet.
Das Konto, das Sie zum Erstellen einer Sicherung einer Tabelle verwenden, muss die Berechtigung zum Lesen der Tabelle und zum Erstellen von Sicherungen in der Instanz haben, in der sich die Tabelle befindet (die Quellinstanz).
Das Konto, das Sie zum Kopieren einer Sicherung verwenden, muss zum Lesen der und eine Sicherung in der Zielinstanz zu erstellen. Projekt arbeiten.
Das Konto, das Sie zum Wiederherstellen einer neuen Tabelle aus einer Sicherung verwenden, muss die Berechtigung zum Erstellen einer Tabelle in der Instanz haben, in der Sie die Wiederherstellung ausführen.
| Aktion | Erforderliche IAM-Berechtigung |
|---|---|
| Sicherung erstellen | bigtable.tables.readRows, bigtable.backups.create |
| Eine Sicherung abrufen | bigtable.backups.get |
| Sicherungen auflisten | bigtable.backups.list |
| Sicherung löschen | bigtable.backups.delete |
| Sicherung aktualisieren | bigtable.backups.update |
| Sicherung kopieren | Bigtable.backups.read, Bigtable.backups.create |
| Aus einer Sicherung in einer neuen Tabelle wiederherstellen | bigtable.tables.create, bigtable.backups.restore |
| Einen Vorgang abrufen | bigtable.instances.get |
| Vorgänge auflisten | bigtable.instances.get |
Best Practices
Die folgenden Best Practices müssen beachtet werden, bevor Sie eine Sicherungsstrategie erstellen.
Sicherungen erstellen
- Sichern Sie Tabellen nicht öfter als einmal alle fünf Minuten.
- Wenn Sie eine Tabelle mit Replikation sichern, wählen Sie den Cluster aus, um die Sicherung zu speichern. Berücksichtigen Sie dabei die folgenden Faktoren:
- Kosten: Ein Cluster in Ihrer Instanz befindet sich möglicherweise in einer kostengünstigeren Region als die anderen.
- In der Nähe Ihres Anwendungsservers. Sie sollten die Sicherung möglichst in der Nähe Ihrer Bereitstellungsanwendung speichern.
- Speicherauslastung Sie benötigen genügend Speicherplatz, um Ihre Sicherungen zu speichern, während sie sich ansammeln. Je nach Arbeitslast können Cluster mit verschiedenen Größen oder mit unterschiedlicher Laufwerknutzung vorhanden sein. Dies kann den Cluster beeinflussen, den Sie auswählen.
- Wenn Sie sicherstellen müssen, dass alle replizierten Schreibvorgänge in einer Sicherung enthalten sind, sichern Sie eine Tabelle in einer Instanz mit Replikation, verwenden Sie Konsistenztoken mit Ihren Schreibanfragen.
Daten aus Sicherungen wiederherstellen
- Planen Sie im Voraus, wie Sie die neue Tabelle benennen wollen, wenn Sie eine Sicherung wiederherstellen müssen. Der entscheidende Punkt ist, dass Sie vorab vorbereitet sein müssen, damit Sie sich nicht entscheiden müssen, sobald ein Problem auftritt.
- Wenn Sie eine Tabelle aus einem anderen Grund als einem versehentlichen Löschen wiederherstellen, achten Sie darauf, dass alle Lese- und Schreibvorgänge an die neue Tabelle gehen, bevor Sie die ursprüngliche Tabelle löschen.
- Wenn Sie den Zugriff auf eine andere Instanz wiederherstellen möchten, erstellen Sie die Zielinstanz, bevor Sie die Sicherung wiederherstellen.
Kontingente und Limits
Sicherungs- und Wiederherstellungsanfragen und der Sicherungsspeicher unterliegen den Kontingenten und Limits für Bigtable.
Beschränkungen
Die folgenden Einschränkungen gelten für Bigtable-Sicherungen:
Allgemein
- Sie können nicht direkt aus einer Sicherung lesen.
- Eine Sicherung ist eine Version einer Tabelle in einem einzelnen Cluster zu einem bestimmten Zeitpunkt. Sicherungen stellen keinen konsistenten Status dar. Dasselbe gilt auch für Sicherungen derselben Tabelle in verschiedenen Clustern.
- Sie können in einem Vorgang nicht mehr als eine Tabelle sichern.
- Bigtable-Sicherungen können nicht exportiert, kopiert oder in einen anderen Dienst wie Cloud Storage verschoben werden.
- Bigtable-Sicherungen enthalten nur Bigtable-Daten und nicht in andere Google-Dienste integriert oder damit in Verbindung stehen.
Wird wiederhergestellt
- Sie können aus einer Sicherung keine Wiederherstellung in einer vorhandenen Tabelle vornehmen.
- Sie können nur Instanzen wiederherstellen, die bereits vorhanden sind. Bigtable erstellt bei der Wiederherstellung aus einer Sicherung keine neue Instanz. Wenn die in einer Wiederherstellungsanfrage angegebene Zielinstanz nicht vorhanden ist, schlägt der Wiederherstellungsvorgang fehl.
- Wenn Sie die Sicherung einer Tabelle in einem SSD-Cluster wiederherstellen und dann die neu wiederhergestellte Tabelle löschen, kann das Löschen der Tabelle eine Weile dauern, da Bigtable auf das Beenden der Tabellenoptimierung wartet.
Kopieren
- Sie können keine Kopie einer Sicherung erstellen, deren Ablauf in den nächsten 24 Stunden liegt.
- Sie können keine Kopie einer Sicherungskopie erstellen.
CMEK
- Eine durch CMEK geschützte Sicherung muss in einer neuen Tabelle in einer CMEK-geschützten Instanz wiederhergestellt werden.
- Wenn Sie eine Kopie einer Sicherung erstellen, die CMEK-geschützt ist, wird das Ziel Cluster muss außerdem CMEK-geschützt sein.