Valkey- oder Redis-OSS-Knoten und -Shards - Amazon ElastiCache

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.

Valkey- oder Redis-OSS-Knoten und -Shards

Ein Shard (in der API und CLI: Knotengruppe) ist eine hierarchische Anordnung von Knoten, die jeweils in einem Cluster eingebunden sind. Shards unterstützen die Replikation. Innerhalb eines Shards dient ein Knoten als Primärknoten mit Lese-/Schreibzugriff. Alle anderen Knoten in einem Shard dienen als schreibgeschützte Replikate des Primärknotens. Valkey oder Redis OSS Version 3.2 und höher unterstützen mehrere Shards innerhalb eines Clusters (in der API und CLI, einer Replikationsgruppe). Diese Unterstützung ermöglicht die Partitionierung Ihrer Daten in einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert).

Das folgende Diagramm veranschaulicht die Unterschiede zwischen einem Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) und einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert).

Bild: Valkey oder Redis OSS (Cluster-Modus deaktiviert) & Valkey oder Redis OSS (Cluster-Modus aktiviert) Shards (API/CLI: Knotengruppen)

Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) unterstützen die Replikation über Shards. Die API-Operation DescribeReplicationGroups(CLI: describe-replication-groups) listet die Knotengruppen mit den Mitgliedsknoten, der Rolle des Knotens innerhalb der Knotengruppe und anderen Informationen auf.

Wenn Sie einen Valkey- oder Redis OSS-Cluster erstellen, geben Sie an, ob Sie einen Cluster mit aktiviertem Clustering erstellen möchten. Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) haben nie mehr als einen Shard. Dieser kann horizontal skaliert werden, indem Read Replica-Knoten hinzugefügt (bis zu insgesamt fünf) oder gelöscht werden. Weitere Informationen finden Sie unter Hohe Verfügbarkeit mit Replikationsgruppen, Hinzufügen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert) oder Löschen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert). Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) können auch vertikal skaliert werden, indem sie die Knotentypen ändern. Weitere Informationen finden Sie unter Skalierung von Replikatknoten für Valkey oder Redis OSS (Clustermodus deaktiviert).

Das Knoten- oder Shard-Limit kann auf maximal 500 pro Cluster erhöht werden, wenn es sich bei der Engine um Valkey oder Redis OSS Version 5.0.6 oder höher handelt. 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.

Nachdem ein Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) erstellt wurde, kann er geändert (nach innen oder außen skaliert) werden. Weitere Informationen erhalten Sie unter Skalierung ElastiCache und Knoten ersetzen (Valkey und Redis OSS).

Wenn Sie einen neuen Cluster erstellen, können Sie ihn mit Daten aus dem alten Cluster bestücken, damit er nicht von Anfang an leer ist. Dieser Ansatz funktioniert nur, wenn die Cluster-Gruppe die gleiche Anzahl an Shards hat wie der alte Cluster. Dies kann hilfreich sein, wenn Sie Ihren Knotentyp oder die Engine-Version ändern müssen. Weitere Informationen erhalten Sie unter Erstellen manueller Backups und Wiederherstellen aus einem Backup in einen neuen Cache.