Informationen zu Lesereplikaten

Die Standardstufe von Memorystore for Redis bietet die Möglichkeit, die Leseabfragen Ihrer Anwendung mithilfe von Lesereplikaten zu skalieren Auf dieser Seite wird davon ausgegangen, dass Sie mit den verschiedenen Redis-Stufenfunktionen vertraut sind.

Mit Lesereplikaten können Sie Ihre Lesearbeitslast durch Abfrage der Replikate skalieren. Ein Leseendpunkt ist bereitgestellt, um den Anwendungen das Verteilen von Abfragen auf Replikate zu erleichtern. Weitere Informationen finden Sie unter Lesevorgänge mit Leseendpunkt skalieren.

Eine Anleitung zum Verwalten einer Redis-Instanz mit Lesereplikaten finden Sie unter Lesereplikate verwalten.

Anwendungsfälle für Lesereplikate

Für Sitzungsspeicher, Bestenliste, Empfehlungssystem und andere Anwendungsfälle muss die Instanz hochverfügbar sein. Für diese Anwendungsfälle sind viel mehr Lesevorgänge als Schreibvorgänge vorhanden und diese Anwendungsfälle können im Allgemeinen einige veraltete Lesevorgänge tolerieren. In solchen Fällen ist es sinnvoll, Lesereplikate zu nutzen, um die Verfügbarkeit und Skalierbarkeit der Instanz zu erhöhen.

Verhalten des Lesereplikats

  • Lesereplikate sind auf Instanzen der Standardstufe nicht standardmäßig aktiviert.
  • Sobald Lesereplikate auf einer Instanz aktiviert sind, können sie für diese Instanz nicht mehr deaktiviert werden.
  • Instanzen der Standardstufe können ein bis fünf Lesereplikate haben.
  • Der Leseendpunkt bietet einen einzelnen Endpunkt zum Verteilen von Abfragen auf Replikatknoten.
  • Lesereplikate werden mit der asynchronen Redis-Replikation verwaltet.

Einschränkungen

  • Lesereplikate werden nur für Instanzgrößen mit Knoten ab 5 GB unterstützt.
  • Lesereplikate können nur auf Instanzen aktiviert werden, die Redis-Version 5.0 oder höher verwenden.
  • Wenn Sie eine Zone und eine alternative Zone für die Bereitstellung von Knoten festlegen, verwendet Memorystore diese Zonen für den ersten und den zweiten Knoten in der Instanz. Anschließend wählt Memorystore die Zonen für alle verbleibenden Knoten aus, die für die Instanz bereitgestellt werden.
  • Sie müssen die Instanz mit einem CIDR-IP-Adressbereich von /28 oder höher bereitstellen. Größere Bereichsgrößen wie /27 und /26 sind gültig. Kleinere Bereiche wie /29 werden für dieses Feature nicht unterstützt.

Architektur

Beim Aktivieren von Lesereplikaten geben Sie die gewünschte Anzahl der Replikate für die Instanz an. Memorystore verteilt die primären und Lesereplikatknoten automatisch auf die verfügbaren Zonen in einer Region.

Jede Instanz hat einen primären Endpunkt und einen Leseendpunkt. Der primäre Endpunkt leitet den Traffic immer an den primären Knoten weiter, während der Leseendpunkt das Load-Balancing von Leseabfragen automatisch auf verfügbare Replikate ausführt.

Der Systemdiagnosedienst von Memorystore for Redis überwacht die Instanz und ist für die Erkennung eines Ausfalls des primären Knotens zuständig. Er wählt ein Replikat als neue primäre Knoten aus und initiiert ein automatisches Failover auf die neue primäre Datenbank.

Failovers für Instanzen mit Lesereplikaten

Wenn ein primärer Knoten ausfällt, initiiert der Memorystore-Statusüberwachungsdienst das Failover und die neue primäre Datenbank wird sowohl für Lese- als auch für Schreibvorgänge verfügbar. Der Failover ist in der Regel in weniger als 30 Sekunden abgeschlossen.

Wenn ein Failover auftritt, leitet der primäre Endpunkt den Traffic automatisch an den neuen primären Endpunkt weiter. Alle Clientverbindungen zum primären Endpunkt werden jedoch während eines Failovers getrennt. Anwendungen mit Verbindungslogik für Verbindungen werden automatisch wieder verbunden, sobald die neue primäre Datenbank online ist. Einige der Clientverbindungen zum Leseendpunkt werden auch von dem Lesereplikat getrennt, das während des Failovers zur primären Datenbank hochgestuft wird. Verbindungen zu verbleibenden Replikaten werden während eines Failovers weiterhin bereitgestellt. Bei Wiederholungsversuchen werden die Verbindungen an die neuen Replikate weitergeleitet.

Wenn ein Failover auftritt, da die Replikation asynchron ist, können Replikate unterschiedliche Replikationsverzögerungen haben. Der Failover-Prozess versucht jedoch, mit minimaler Verzögerung ein Failover auf das Replikat auszuführen. Dadurch wird der Datenverlust minimiert und der Lesedurchsatz während eines Failovers reduziert. Die neu hochgestufte primäre Instanz kann sich in derselben Zone oder in einer anderen Zone wie die vorherige primäre Instanz befinden. Ein Replikat wird als neue primäre Instanz ausgewählt, wenn sie sich in derselben Zone wie die vorherige primäre Datenbank befindet und die geringste Verzögerung aufweist. Andernfalls kann ein Replikat aus einer anderen Zone zur neuen primären Zone werden.

Da die Replikation asynchron ist, besteht die Möglichkeit, dass veraltete Daten während eines Failovers immer gelesen werden. Während die neue primäre Instanz hochgestuft wird, gehen möglicherweise einige Schreibvorgänge in die Instanz verloren. Anwendungen sollten mit diesem Verhalten umgehen können.

Redis unternimmt alles, um die anderen Replikate zu vermeiden, die eine vollständige Synchronisierung während des Failovers erfordern. Dies kann jedoch in seltenen Fällen vorkommen. Eine vollständige Synchronisierung kann je nach Schreibrate und Größe des replizierten Datensatzes einige Minuten bis eine Stunde dauern. Während dieser Zeit sind Replikate, die einer vollständigen Synchronisierung unterzogen werden, nicht für Lesevorgänge verfügbar. Nach Abschluss der Synchronisierung kann auf Lesevorgänge auf die Replikate zugegriffen werden.

Fehlermodi für Lesereplikate

Instanzen mit Lesereplikaten können verschiedene Fehler und fehlerhafte Bedingungen ausführen, die sich auf die Anwendung auswirken. Das Verhalten hängt davon ab, ob die Instanz ein Replikat oder zwei oder mehr Replikate hat. Im Abschnitt werden einige gängige Fehlermodi beschrieben und das Verhalten der Instanz während dieser Bedingungen beschrieben.

Replikat ist nicht verfügbar

  • Wenn ein Replikat aus irgendeinem Grund fehlschlägt, wird es als nicht verfügbar gekennzeichnet und alle Verbindungen zum Replikat werden nach einem bestimmten Zeitlimit beendet. Sobald das Replikat wiederhergestellt ist, werden neue Verbindungen an das wiederhergestellte Replikat weitergeleitet. Die Zeit zur Wiederherstellung eines Replikats hängt vom Fehlermodus ab.

  • Bei einem Ausfall des Compute Engine-Speichers oder -Zonenfehlers wird das Replikat erst wiederhergestellt, wenn die Bedingung behoben wurde.

Zonenausfall

  • Wenn die Zone, in der sich die primäre Instanz befindet, ausfällt, wird für die primäre Instanz ein Failover auf ein Replikat in einer anderen Zone durchgeführt. Wenn die Instanz nur ein Replikat hat, ist der Leseendpunkt für die Dauer des Zonenausfalls nicht verfügbar. Wenn die Instanz mehr als ein Replikat hat, sind Replikate außerhalb der betroffenen Zone für Lesevorgänge verfügbar.

  • Wenn die Zone ausfällt, in der sich ein oder mehrere Replikate befinden, sind diese Replikate für die Dauer des Zonenausfalls nicht verfügbar. Wenn ein Zweizonenfehler auftritt und zwei oder mehr Replikate vorhanden sind, wird das Replikat mit der geringsten Verzögerung in den verbleibenden Zonen zum primären Knoten hochgestuft. Alle verbleibenden Replikate in den betroffenen Zonen sind für Lesevorgänge verfügbar.

Netzwerkpartitionierung:

Eine Netzwerkpartition ist ein Szenario, in dem Knoten ausgeführt werden, aber nicht alle Clients, Zonen oder Peer-Knoten erreichen können. Memorystore verwendet ein Quorum-basiertes System, um zu verhindern, dass isolierte Knoten Schreibvorgänge bereitstellen. Bei einer Netzwerkpartition wird jede primäre Instanz in einer Minderheitspartition selbst heruntergestuft. Die Mehrheitspartition (falls vorhanden) wählt eine neue primäre Datenbank aus, wenn sie noch keine hat. Isolierte Replikate verarbeiten weiterhin Lesevorgänge. Wenn sie jedoch von der primären Datenbank nicht synchronisiert werden können, sind sie möglicherweise veraltet.

Prüfen Sie, ob die isolierten Knoten die Messwerte master_link_down_since_seconds und offset_diff ermitteln, um festzustellen, ob die Verbindung unterbrochen wird.

Lagerbestand

Manchmal sind Compute Engine-Ressourcen, die von Memorystore benötigt werden, in einer Zone nicht verfügbar, was zu einem Fehlschlag führt. Wenn es in einer Region, in der Sie eine Instanz bereitstellen möchten, einen Bestand gibt, schlägt der Vorgang zum Erstellen der Instanz fehl.

Vollständige Synchronisierung

Wenn ein Replikat zu weit hinter die primäre Instanz zurückfällt, wird eine vollständige Synchronisierung ausgelöst, durch die ein vollständiger Snapshot der primären Instanz in ein Replikat kopiert wird. Dieser Vorgang kann im schlimmsten Fall zwischen Minuten und einer Stunde dauern. Eine vollständige Synchronisierung führt nicht zu einem Instanzfehler. In dieser Zeit ist das Replikat, über das die vollständige Synchronisierung durchgeführt wird, jedoch nicht für Lesevorgänge verfügbar und die primäre CPU hat eine höhere CPU- und Arbeitsspeicherauslastung.

Primärer Endpunkt gibt READONLY zurück

Bei Schreibvorgängen auf den primären Endpunkt einer Memorystore for Redis-Instanz mit Lesereplikaten können unerwartet -READONLY You can't write against a read only replica.-Fehler zurückgegeben werden. Wir empfehlen, die Verbindungen zur Instanz zu schließen und neu zu erstellen. In den meisten Fällen kann das Problem durch einen Neustart der Clientanwendung behoben werden. Wenn diese Optionen nicht umsetzbar sind oder das Verhalten weiterhin besteht, wenden Sie sich an das Google Cloud-Supportteam.

Lesevorgänge mit dem Leseendpunkt skalieren

Mit Lesereplikaten können Anwendungen ihre Lesevorgänge durch Lesen aus den Replikaten skalieren. Anwendungen können über den Leseendpunkt eine Verbindung zu Lesereplikaten herstellen.

Endpunkt lesen

Der Leseendpunkt ist eine IP-Adresse, mit der sich Ihre Anwendung verbindet. Es verteilt die Verbindungen gleichmäßig auf die Replikate in der Instanz. Verbindungen zum Lesereplikat können Leseabfragen senden, aber keine Schreibabfragen. Jede Instanz der Standardstufe, für die Lesereplikate aktiviert sind, hat einen Leseendpunkt. Eine Anleitung zum Anzeigen des Leseendpunkts Ihrer Instanz finden Sie unter Lesereplikatinformationen für die Instanz ansehen.

Verhalten des Leseendpunkts

  • Der Leseendpunkt verteilt Verbindungen automatisch auf alle verfügbaren Replikate. Verbindungen werden nicht an die primäre Instanz weitergeleitet.
  • Ein Replikat gilt als verfügbar, solange es den Client-Traffic verarbeiten kann. Die Zeiten, in denen ein Replikat eine vollständige Synchronisierung mit seiner primären Datenbank durchführt, sind nicht enthalten.
  • Ein Replikat mit einer hohen Replikationsverzögerung verarbeitet weiterhin Traffic. Anwendungen mit hohem Schreibvolumen können veraltete Daten aus einem Replikat lesen, das hohe Schreibvorgänge liefert.
  • Wenn ein Replikatknoten zum primären Knoten wird, werden die Verbindungen zu diesem Knoten beendet und neue Verbindungen an einen neuen Replikatknoten weitergeleitet.
  • Einzelne Verbindungen zum Leseendpunkt greifen während der Lebensdauer der Verbindung auf dasselbe Replikat zu. Verschiedene Verbindungen von demselben Clienthost werden nicht garantiert auf denselben Replikatknoten ausgerichtet.

Lesekonsistenz

Lesereplikate werden mit der nativen asynchronen OSS Redis-Replikation verwaltet. Aufgrund der Beschaffenheit der asynchronen Replikation ist es möglich, dass das Replikat hinter der primären Replikation zurückliegt. Anwendungen mit konstanten Schreibvorgängen, die auch Lesevorgänge aus dem Replikat ausführen, sollten inkonsistente Lesevorgänge tolerieren.

Wenn die Anwendung "Read-Write-Konsistenz" erfordert, empfehlen wir die Verwendung des primären Endpunkts für Schreib- und Lesevorgänge. Durch die Verwendung des primären Endpunkts wird sichergestellt, dass die Lesevorgänge immer an den primären Endpunkt weitergeleitet werden. Auch in diesem Fall ist es möglich, dass nach einem Failover veraltete Lesevorgänge vorhanden sind.

Durch Festlegen von TTLs für die Schlüssel auf der primären Instanz wird sichergestellt, dass abgelaufene Schlüssel weder von der primären Instanz noch vom Replikat gelesen werden. Dies liegt daran, dass Redis sicher ist, dass ein abgelaufener Schlüssel nicht aus dem Replikat gelesen werden kann.

Verhalten beim Aktivieren von Lesereplikaten auf einer vorhandenen Instanz

  • Das Aktivieren von Lesereplikaten auf einer vorhandenen Redis-Instanz ist ein exklusiver Vorgang. Das bedeutet, dass Sie keine anderen Aktualisierungsvorgänge-Instanzänderungen im Rahmen desselben Vorgangs vornehmen können, der Lesereplikate aktiviert.

  • Zum Aktivieren von Lesereplikaten auf einer vorhandenen Redis-Instanz müssen Sie unabhängig von der Größe des vorhandenen IP-Adressbereichs, der Memorystore for Redis zugewiesen ist, einen zusätzlichen gültigen IP-Adressbereich der Größe /28 zuweisen.

    • Sie müssen den zusätzlichen IP-Bereich angeben, wenn Sie Lesereplikate für die Redis-Instanz aktivieren. Sie können entweder einen bestimmten Bereich auswählen oder Memorystore einen automatisch für Sie auswählen lassen.

  • Die Lese-/Schreib-IP-Adresse für Ihre Instanz ändert sich bei der Aktivierung von Lesereplikaten nicht. Die IP-Adresse des Leseendpunkts befindet sich im ursprünglichen Bereich, der Ihrer Memorystore-Instanz zugewiesen wurde, und nicht in dem zusätzlichen Bereich, den Sie beim Aktivieren von Lesereplikaten angeben.

  • Um den neuen Lesereplikat zu finden, rufen Sie nach Abschluss des Vorgangs die Informationen zu den Lesereplikaten für Ihre Instanz auf, um Lesereplikate zu aktivieren.

Instanz skalieren

Sie können die Anzahl der Lesereplikate für Ihre Instanz skalieren und auch die Knotengröße ändern:

Wir empfehlen, die Instanz während eines Zeitraums mit geringem Lese- und Schreibtraffic zu skalieren, um die Auswirkungen auf die Anwendung zu minimieren.

Das Hinzufügen eines neuen Replikats führt zu einer zusätzlichen Belastung des primären Replikats, während das Replikat vollständig synchronisiert wird. Beim Hinzufügen von Knoten sind vorhandene Verbindungen nicht betroffen oder übertragen. Sobald das neue Replikat verfügbar ist, erhält es Verbindungen vom Endpunkt und verarbeitet Lesevorgänge. Durch das Entfernen eines Replikats werden alle aktiven Verbindungen geschlossen, die an dieses Replikat weitergeleitet wurden. Die Clientanwendung sollte so konfiguriert sein, dass automatisch eine Verbindung zum Leseendpunkt hergestellt wird, um die Verbindungen zu den verbleibenden Replikaten wiederherzustellen.

Best Practices

Speicherverwaltung

Redis lässt keine Schreibvorgänge von Clients zu, die das Limit maxmemory der Instanz überschreiten. Overhead wie Fragmentierung, Replikationspuffer und teure Befehle wie EVAL können jedoch die Speicherauslastung über dieses Limit hinaus erhöhen. In diesen Fällen schlägt Memorystore Schreibvorgänge fehl, bis der Arbeitsspeicherbedarf reduziert ist. Weitere Informationen finden Sie unter Best Practices für Arbeitsspeicherverwaltung.

Wenn Memorystore aufgrund eines Exports oder einer vollständigen Synchronisierungsreplikation einen BGSAVE-Vorgang durchführt und eine OOM-Bedingung auftritt, wird der untergeordnete Prozess beendet. In diesem Fall schlägt der BGSAVE-Vorgang fehl und der Redis-Knotenserver bleibt verfügbar.

Um die Replikation und die Erstellung von Snapshots zu garantieren, sollten Sie die Speicherauslastung während wichtiger Vorgänge wie Export, Skalierung usw. unter 50 % halten. Sie können den Export manuell auslösen oder Failover zum Einsehen der Leistung dieser Vorgänge.

CPU-Verwaltung

Memorystore stellt Messwerte zur CPU-Nutzung und zur Anzahl der Verbindungen für jeden Knoten bereit. Wir empfehlen, einen ausreichenden Overhead zuzuweisen, damit der Verlust einer einzelnen Verfügbarkeitszone toleriert wird. Das ideale Ziel kann je nach Anzahl der Replikate und Nutzungsmustern variieren. Ein guter Ausgangspunkt ist jedoch, die CPU-Auslastung unter 50 % zu halten.

Wenn die Clientnutzungsmuster unausgeglichen sind oder Failover-Vorgänge zu einer unausgeglichenen Verbindungsverteilung führen, kann es zu einer hohen Knotenauslastung kommen. In diesem Fall sollten Sie Ihre Verbindungen regelmäßig schließen, damit Memorystore automatisch neu ausgleichen kann. Memorystore stellt keine offenen Verbindungen wieder her.

Verwaltung des Verbindungsausgleichs

Jedes Mal, wenn die Verbindungen eines Knotens geschlossen werden, müssen Clients sich neu verbinden. Dies geschieht in der Regel durch Aktivieren der automatischen Verbindung in der Clientbibliothek Ihrer Wahl. Wenn der Knoten wieder hinzugefügt wird, werden vorhandene Verbindungen nicht umgeleitet, aber neue Verbindungen werden an den neuen Knoten weitergeleitet. Clients können Verbindungen regelmäßig beenden, um sicherzustellen, dass sie auf die verfügbaren Knoten verteilt sind.

Verwaltung von Replikationsverzögerungen

Replikate können verzögert sein, insbesondere wenn die Schreibrate sehr hoch ist. In solchen Szenarien ist das Replikat weiterhin für Lesevorgänge verfügbar. In diesem Fall können Lesevorgänge vom Replikat veraltet sein und die Anwendung sollte in der Lage sein, dies zu bewältigen, oder die hohe Schreibrate sollte behoben werden.

Nächste Schritte