Failovers

Wenn ein Bigtable-Cluster nicht mehr reagiert, ermöglicht die Replikation eingehende, für das Failover des Traffics auf einen anderen Cluster in derselben Instanz. Failovers können manuell oder automatisch ausgelöst werden, je nachdem, welches Anwendungsprofil eine Anwendung verwendet und wie das Anwendungsprofil konfiguriert ist.

Auf dieser Seite wird die Funktionsweise von manuellen und automatischen Failovers in einer Instanz mit Replikation beschrieben. Wie Sie einen Failover ausführen, erfahren Sie unter Failover verwalten.

Bevor Sie diese Seite lesen, sollten Sie sich mit den Informationen unter Bigtable-Replikation – Übersicht vertraut gemacht haben. Außerdem sollten Sie mit den verfügbaren Routingoptionen vertraut sein.

Manuelle Failovers

Wenn ein Anwendungsprofil Single-Cluster-Routing verwendet, um alle Anfragen an einen Cluster weiterzuleiten, müssen Sie nach eigenem Ermessen entscheiden, wann ein Failover zu einem anderen Cluster beginnt.

Im Folgenden sind einige Anzeichen aufgeführt, die darauf hinweisen könnten, dass ein Failover auf einen anderen Cluster angebracht wäre:

  • Der Cluster gibt eine große Anzahl von vorübergehenden Systemfehlern zurück.
  • Eine große Anzahl von Requests löst eine Zeitüberschreitung aus.
  • Die durchschnittliche Antwortlatenz nimmt ein inakzeptables Ausmaß an.

Da diese Anzeichen aus vielen verschiedenen Gründen auftreten können, ist ein Failover auf einen anderen Cluster keine Garantie für die Lösung des zugrunde liegenden Problems. Überwachen Sie Ihre Instanz vor und nach dem Failover, um zu überprüfen, ob sich die Messwerte verbessert haben.

Einzelheiten zum Ausführen eines manuellen Failovers finden Sie unter Manuelles Failover ausführen.

Automatische Failovers

Wenn in einem App-Profil Multi-Cluster-Routing verwendet wird, führt Bigtable Failovers automatisch aus. Sobald der nächste Cluster eine Anfrage nicht verarbeiten kann, leitet Bigtable den Traffic an den nächsten verfügbaren Cluster weiter.

Automatische Failovers können auch bei sehr kurzen Ausfallzeiten eines Clusters erfolgen. Wenn Bigtable beispielsweise eine Anfrage an einen Cluster weiterleitet und dieser Cluster extrem langsam antwortet oder einen vorübergehenden Fehler zurückgibt, wiederholt Bigtable die Anfrage normalerweise in einem anderen Cluster.

Wenn Sie Multi-Cluster-Routing verwenden und eine Anfrage mit einer Frist senden, schlägt Bigtable automatisch fehl, wenn die Frist abgelaufen ist. Wenn die Anfragefrist näher rückt, der erste Cluster jedoch keine Antwort gesendet hat, leitet Bigtable die Anfrage an den nächstgelegenen Cluster weiter.

Bigtable verwendet einen internen Algorithmus des Typs Last-Write-wins, um alle Datenkonflikte zu beheben, die aufgrund eines Failovers auftreten können, bevor die Replikation abgeschlossen ist. Weitere Informationen finden Sie unter Konfliktlösung.

Wenn Sie die Replikation mit Multi-Cluster-Routing verwenden, um eine hohe Verfügbarkeit für Ihre Anwendung zu erreichen, sollten Sie Ihre Client-Server oder VMs in oder in der Nähe von mehreren Google Cloud-Regionen einrichten. Diese Empfehlung gilt auch dann, wenn Ihr Anwendungsserver nicht von Google Cloud gehostet wird, da Ihre Daten über die Google Cloud-Region, die Ihrem Anwendungsserver am nächsten liegt, in das Google Cloud-Netzwerk gelangen. Wie bei jeder Anfrage wird ein Failover auf kürzeren Strecken schneller abgeschlossen.

Viele automatische Failovers sind so kurz, dass Sie sie gar nicht wahrnehmen. In der Grafik automatische Failovers in der Google Cloud Console sehen Sie die Anzahl der Anfragen, die in einem bestimmten Zeitraum automatisch umgeleitet wurden: Öffnen Sie dazu die Liste der Instanzen, klicken Sie auf den Instanznamen und danach auf Monitoring.

Nächste Schritte