Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Hohe Verfügbarkeit mit Replikationsgruppen
Single-node Amazon ElastiCache Valkey- und Redis OSS-Cluster sind speicherinterne Einheiten mit begrenzten Datenschutzdiensten (AOF). Sollte Ihr Cluster aus irgendeinem Grund ausfallen, verlieren Sie alle Daten des Clusters. Wenn Sie jedoch eine Valkey- oder Redis OSS-Engine ausführen, können Sie 2 bis 6 Knoten zu einem Cluster mit Replikaten zusammenfassen, wobei 1 bis 5 schreibgeschützte Knoten replizierte Daten des einzelnen primären Knotens der Gruppe enthalten. read/write Wenn aus irgendeinem Grund ein Knoten in diesem Szenario ausfällt, verlieren Sie nicht alle Daten, da sie auf einem oder mehreren Knoten repliziert sind. Aufgrund der Replikationslatenz können einige Daten verloren gehen, wenn der primäre Knoten ausfällt. read/write
Wie in der folgenden Grafik zu sehen ist, ist die Replikationsstruktur in einem Shard (in der als Knotengruppe bezeichnet API/CLI) enthalten, der in einem Valkey- oder Redis OSS-Cluster enthalten ist. Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) haben immer einen Shard. Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) können bis zu 500 Shards haben, wobei die Cluster-Daten auf die Shards aufgeteilt sind. Sie können einen Cluster mit einer höheren Anzahl an Shards und einer geringeren Anzahl an Replikaten mit bis zu 90 Knoten pro Cluster erstellen. Diese Clusterkonfiguration reicht von 90 Shards und 0 Replikaten bis hin zu 15 Shards und 5 Replikaten, was dem Höchstwert für die Anzahl erlaubter Replikate entspricht.
Das Knoten- oder Shard-Limit kann ElastiCache für Valkey auf maximal 500 pro Cluster und für Redis OSS mit ElastiCache Version 5.0.6 oder höher erhöht werden. Sie können beispielsweise einen Cluster mit 500 Knoten konfigurieren, der zwischen 83 Shards (ein primärer Knoten und 5 Replikate pro Shard) und 500 Shards (ein primärer Knoten und keine Replikate) umfasst. Stellen Sie sicher, dass für die Erhöhung genügend IP-Adressen verfügbar sind. Häufige Fallstricke sind Subnetze in der Subnetzgruppe, die einen zu kleinen CIDR-Bereich haben, oder Subnetze, die gemeinsam genutzt und von anderen Clustern stark beansprucht werden. Weitere Informationen finden Sie unter Erstellen einer Subnetzgruppe.
Für Versionen unter 5.0.6 liegt das Limit bei 250 pro Cluster.
Um eine Erhöhung des Limits zu beantragen, AWS siehe Service Limits und wählen Sie den Limittyp Nodes per cluster per instance type.
Der Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) hat einen Shard und 0 bis 5 Replikatknoten
Wenn der Cluster mit den Replikaten Multi-AZ aktiviert wurde und der primäre Knoten ausfällt, erfolgt ein Failover des Primärknotens auf ein Read Replica. Da die Daten auf den Replikatknoten asynchron aktualisiert werden, kann die Latenz bei der Aktualisierung der Replikatknoten zu geringfügigem Datenverlust führen. Weitere Informationen finden Sie unter Minimierung von Ausfällen beim Ausführen von Valkey oder Redis OSS.
Anmerkung
Bei Clustern mit aktivierter Dauerhaftigkeit werden die Daten in einem Multi-AZ Transaktionslog gespeichert und können wiederhergestellt werden, selbst wenn alle Knoten ausfallen. Bei synchronen Schreibvorgängen gehen bei einem Failover keine bestätigten Daten verloren. Bei asynchronen Schreibvorgängen können im Falle eines Fehlers bis zu 10 Sekunden an Daten verloren gehen.
Themen
Replikation mit aktivierter Haltbarkeit
Bei Valkey 9.0+ Clustern mit aktivierter Beständigkeit erfolgt die Replikation über das Multi-AZ Transaktionslog und nicht über ein direktes Streaming von Primär zu Replikat. Der primäre Knoten schreibt in das Transaktionslog, und Replikate verarbeiten unabhängig voneinander festgeschriebene Schreibvorgänge aus dem Protokoll. Diese Architektur bedeutet, dass Replikate unabhängig voneinander wiederhergestellt werden, ohne den primären Knoten zu belasten.
Zuverlässige Synchronisation und Sicherung
Bei Clustern mit aktivierter Dauerhaftigkeit unterscheiden sich die Synchronisations- und Sicherungsvorgänge von den Standardclustern:
Off-box Snapshots: Snapshots werden von kurzlebigen Instanzen erstellt, die aus dem Multi-AZ Transaktionslog lesen, sodass die Leistung Ihres Clusters nicht beeinträchtigt wird.
Log-based Wiederherstellung: Fehlgeschlagene Replikate werden aus dem Transaktionslog und den Snapshots wiederhergestellt, sodass keine vollständige Synchronisation durch das primäre Protokoll erforderlich ist.
