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.
# Arbeiten mit ElastiCache
In diesem Abschnitt finden Sie Einzelheiten zur Verwaltung der verschiedenen Komponenten Ihrer ElastiCache Implementierung.
**Topics**
+ [Snapshot und Wiederherstellung](backups.md)
+ [Motorversionen und Aufrüstung in ElastiCache](engine-versions.md)
+ [ElastiCache Best Practices und Caching-Strategien](BestPractices.md)
+ [Verwaltung Ihres knotenbasierten Clusters in ElastiCache](manage-self-designed-cluster.md)
+ [Automatisches Verbinden einer EC2 Instanz und eines ElastiCache Caches](compute-connection.md)
+ [Skalierung ElastiCache](Scaling.md)
+ [Erste Schritte mit Bloom-Filtern](BloomFilters.md)
+ [Erste Schritte mit Watch in Serverless](ServerlessWatch.md)
+ [Erste Schritte mit Vector Search](vector-search.md)
+ [Erste Schritte mit JSON für Valkey und Redis OSS](json-gs.md)
+ [Verschlagworten Sie Ihre Ressourcen ElastiCache](Tagging-Resources.md)
+ [Verwenden des Amazon ElastiCache Well-Architected-Objektivs](WellArchitechtedLens.md)
+ [Allgemeine Schritte zur Fehlerbehebung und bewährte Methoden mit ElastiCache](wwe-troubleshooting.md)
# Snapshot und Wiederherstellung
ElastiCache Amazon-Caches, auf denen Valkey, Redis OSS oder Serverless Memcached ausgeführt werden, können ihre Daten sichern, indem sie einen Snapshot erstellen. Sie können das Backup verwenden, um einen Cache wiederherzustellen oder Daten in einem neuen Cache durch Seeding zu speichern. Ein Backup besteht aus den Metadaten des Caches zusammen mit allen Daten im Cache. Alle Sicherungen werden in Amazon Simple Storage Service (Amazon S3) geschrieben, der einen dauerhaften Speicher bereitstellt. Sie können Ihre Daten jederzeit wiederherstellen, indem Sie einen neuen Valkey-, Redis OSS- oder Serverless Memcached-Cache erstellen und ihn mit Daten aus einem Backup füllen. Mit ElastiCache können Sie Backups mithilfe der AWS-Managementkonsole,AWS Command Line Interface()AWS CLI und der API verwalten. ElastiCache
Wenn Sie vorhaben, den Cache zu löschen, und es wichtig ist, die Daten beizubehalten, können Sie eine zusätzliche Vorsichtsmaßnahme ergreifen. Erstellen Sie dazu zuerst ein manuelles Backup, überprüfen Sie, dass der Status *available* lautet und löschen Sie dann den Cache. Dadurch wird sichergestellt, dass die Cache-Daten weiterhin verfügbar sind, falls das Backup fehlschlagen sollte. Sie können nach den oben beschriebenen bewährten Methoden erneut versuchen, eine Sicherung anzufertigen.
**Topics**
+ [Sicherungseinschränkungen](#backups-constraints)
+ [Auswirkungen von Backups knotenbasierter Cluster auf die Leistung](#backups-performance)
+ [Planen automatischer Backups](backups-automatic.md)
+ [Erstellen manueller Backups](backups-manual.md)
+ [Erstellen einer endgültigen Sicherung](backups-final.md)
+ [Beschreiben von Sicherungen](backups-describing.md)
+ [Kopieren eines Backups](backups-copying.md)
+ [Exportieren einer Sicherung](backups-exporting.md)
+ [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md)
+ [Löschen einer Sicherung](backups-deleting.md)
+ [Markieren von Sicherungen](backups-tagging.md)
+ [Tutorial: Seeding eines neuen knotenbasierten Clusters mit einem extern erstellten Backup](backups-seeding-redis.md)
## Sicherungseinschränkungen
Berücksichtigen Sie die folgenden Einschränkungen bei der Planung und Erstellung von Sicherungen:
+ Backup und Wiederherstellung werden nur für Caches unterstützt, die auf Valkey, Redis OSS oder Serverless Memcached ausgeführt werden.
+ Bei Valkey- oder Redis OSS-Clustern (Clustermodus deaktiviert) werden Sicherung und Wiederherstellung auf Knoten nicht unterstützt. `cache.t1.micro` Alle anderen Cache-Knotentypen werden unterstützt.
+ Bei Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert) werden Sicherung und Wiederherstellung für alle Knotentypen unterstützt.
+ In einem zusammenhängenden Zeitraum von 24 Stunden können Sie nicht mehr als 24 manuelle Backups pro serverlosem Cache erstellen. Für knotenbasierte Valkey- und Redis OSS-Cluster können Sie nicht mehr als 20 manuelle Backups pro Knoten im Cluster erstellen.
+ Valkey oder Redis OSS (Clustermodus aktiviert) unterstützen nur das Erstellen von Backups auf Clusterebene (für die API oder CLI, die Replikationsgruppenebene). Valkey oder Redis OSS (Clustermodus aktiviert) unterstützt nicht das Erstellen von Backups auf Shard-Ebene (für die API oder CLI, auf Knotengruppenebene).
+ Während des Backup-Vorgangs können Sie keine anderen API- oder CLI-Operationen im serverlosen Cache ausführen. Sie können während des Backups API- oder CLI-Operationen auf einem knotenbasierten Cluster ausführen.
+ Wenn Sie Valkey- oder Redis OSS-Caches mit Data Tiering verwenden, können Sie kein Backup nach Amazon S3 exportieren.
+ Sie können ein Backup eines Clusters mit dem R6gd-Knotentyp nur für Cluster wiederherstellen, die den R6gd-Knotentyp verwenden.
## Auswirkungen von Backups knotenbasierter Cluster auf die Leistung
Backups auf Serverless-Caches sind für die Anwendung transparent, ohne dass sich dies auf die Leistung auswirkt. Bei der Erstellung von Backups für knotenbasierte Cluster kann es jedoch je nach verfügbarem reservierten Speicher zu Leistungseinbußen kommen. Backups für knotenbasierte Cluster sind ElastiCache für Memcached nicht verfügbar, aber für Redis OSS. ElastiCache
Im Folgenden finden Sie Richtlinien zur Verbesserung der Backup-Leistung für knotenbasierte Cluster.
+ `reserved-memory-percent`Parameter festlegen — Um übermäßiges Paging zu vermeiden, empfehlen wir Ihnen, den Parameter festzulegen. *reserved-memory-percent* Dieser Parameter verhindert, dass Valkey und Redis OSS den gesamten verfügbaren Speicher des Knotens verbrauchen, und kann dazu beitragen, den Umfang des Paging zu reduzieren. Die Leistung lässt sich möglicherweise einfach durch Verwenden eines größeren Knotens verbessern. Weitere Hinweise zum *reservierten Speicher und zu den Parametern* finden Sie unter. *reserved-memory-percent*[Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md)
+ Backups aus einer Read Replica erstellen — Wenn Sie Valkey oder Redis OSS in einer Knotengruppe mit mehr als einem Knoten ausführen, können Sie ein Backup vom primären Knoten oder einer der Read Replica erstellen. Aufgrund der während BGSAVE erforderlichen Systemressourcen wird empfohlen, Sicherungen von einer der Read Replicas zu erstellen. Während die Sicherung von der Replikation erstellt wird, wirken sich die BGSAVE-Ressourcenanforderungen nichth auf den primären Knoten aus. Der primäre Knoten kann weiterhin Anfragen verarbeiten, ohne langsamer zu werden.
Siehe dazu [Erstellen einer manuellen Sicherung (Konsole)](backups-manual.md#backups-manual-CON) und wählen Sie im Fenster **Sicherung erstellen** im Feld **Clustername** ein Replikat anstelle des standardmäßigen Primärknotens aus.
Wenn Sie eine Replikationsgruppe löschen und ein letztes Backup anfordern, wird das Backup ElastiCache immer vom primären Knoten erstellt. Dadurch wird sichergestellt, dass Sie die neuesten Valkey- oder Redis-OSS-Daten erfassen, bevor die Replikationsgruppe gelöscht wird.
# Planen automatischer Backups
Sie können automatische Backups für jeden serverlosen Cache oder knotenbasierten Cluster von Valkey oder Redis OSS aktivieren. Wenn automatische Backups aktiviert sind, ElastiCache erstellt täglich eine Sicherungskopie des Caches. Es gibt keine Auswirkungen auf den Cache und die Änderung erfolgt sofort. Automatische Backups schützen vor Datenverlust. Bei einem Ausfall können Sie einen neuen Cache erstellen, indem Sie Ihre Daten aus dem aktuellen Backup wiederherstellen. Das Ergebnis ist ein warm gestarteter Cache, auf dem Ihre Daten vorab geladen und einsatzbereit sind. Weitere Informationen finden Sie unter [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md).
Sie können automatische Backups für jeden Memcached Serverless Cache aktivieren. Wenn automatische Backups aktiviert sind, ElastiCache erstellt täglich eine Sicherungskopie des Caches. Es gibt keine Auswirkungen auf den Cache und die Änderung erfolgt sofort. Automatische Backups schützen vor Datenverlust. Bei einem Ausfall können Sie einen neuen Cache erstellen, indem Sie Ihre Daten aus dem aktuellen Backup wiederherstellen. Das Ergebnis ist ein warm gestarteter Cache, auf dem Ihre Daten vorab geladen und einsatzbereit sind. Weitere Informationen finden Sie unter [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md).
Wenn Sie automatische Sicherungen planen, sollten Sie die folgenden Einstellungen vornehmen:
+ **Backup-Startzeit** — Die Tageszeit, zu der mit der Erstellung eines Backups ElastiCache begonnen wird. Sie können das Backup-Fenster für jeden beliebigen Zeitpunkt festlegen, zu dem es am sinnvollsten ist. Wenn Sie kein Backup-Fenster angeben, wird automatisch eines ElastiCache zugewiesen.
+ **Aufbewahrungsfrist für Sicherungen** – Die Anzahl von Tagen, für die die Sicherung in Amazon S3 aufbewahrt wird. Wenn Sie z. B. als Aufbewahrungsfrist 5 festlegen, dann wird die heute erstellte Sicherung 5 Tage lang aufbewahrt. Bei Ablauf der Aufbewahrungsfrist wird die Sicherungs automatisch gelöscht.
Der maximale Aufbewahrungsfrist für Sicherungen ist 35 Tage. Wenn als Backup-Aufbewahrungsfrist „0“ festgelegt wird, werden automatische Backups für den Cache deaktiviert.
Wenn Sie automatische Backups planen, ElastiCache wird mit der Erstellung des Backups begonnen. Sie können das Backup-Fenster für jeden beliebigen Zeitpunkt festlegen, zu dem es am sinnvollsten ist. Wenn Sie kein Backup-Fenster angeben, wird automatisch eines ElastiCache zugewiesen.
Sie können automatische Backups aktivieren oder deaktivieren, wenn Sie entweder einen neuen Cache erstellen oder einen vorhandenen Cache aktualisieren, indem Sie die ElastiCache Konsole AWS CLI, die oder die ElastiCache API verwenden. Für Valkey und Redis OSS erfolgt dies, indem Sie das Kontrollkästchen **Automatische Backups aktivieren** im Abschnitt **Erweiterte Valkey-Einstellungen oder **Erweiterte Redis** OSS-Einstellungen** aktivieren. **Für Memcached erfolgt dies, indem Sie im Abschnitt Erweiterte Memcached-Einstellungen das Kontrollkästchen **Automatische Backups aktivieren aktivieren aktivieren**.**
# Erstellen manueller Backups
Zusätzlich zu automatischen Sicherungen können Sie jederzeit eine *manuelle* Sicherung erstellen. Im Gegensatz zu automatischen Sicherungen, die nach einem angegebenen Aufbewahrungszeitraum automatisch gelöscht werden, ist für manuelle Sicherungen kein Aufbewahrungszeitraum vorhanden, nachdem sie automatisch gelöscht werden. Selbst wenn Sie den Cache löschen, werden alle manuellen Backups aus diesem Cache beibehalten. Wenn Sie eine manuelle Sicherung nicht mehr aufbewahren möchten, müssen Sie sie selbst explizit löschen.
Eine manuelle Sicherung kann nicht nur direkt, sondern auch auf eine der folgenden Arten erstellt werden:
+ [Kopieren eines Backups](backups-copying.md). Es spielt keine Rolle, ob die Quellsicherung automatisch oder manuell erstellt wurde.
+ [Erstellen einer endgültigen Sicherung](backups-final.md). Erstellen Sie ein Backup unmittelbar vor dem Löschen eines Clusters oder Knotens.
Sie können ein manuelles Backup eines Caches mithilfe der AWS-ManagementkonsoleAWS CLI, der oder der ElastiCache API erstellen.
Sie können manuelle Backups von Replikaten erstellen, bei denen der Clustermodus aktiviert und der Clustermodus deaktiviert ist.
## Erstellen einer manuellen Sicherung (Konsole)
**So erstellen Sie ein manuelles Backup eines Caches (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich je nach Ihren **Vorlieben Valkey-Caches**, **Redis OSS-Caches** oder **Memcached-Caches** aus.
1. Wählen Sie das Feld links neben dem Namen des Caches aus, den Sie sichern möchten.
1. Wählen Sie **Backup**.
1. Geben Sie im Dialog **Create Backup** einen Namen für Ihre Sicherung im Feld **Backup Name** ein. Es ist empfehlenswert, dass aus dem Namen der gesicherte Cluster und das Datum sowie die Uhrzeit der Sicherung ersichtlich ist.
Für die Benennung von Clustern gelten die folgenden Einschränkungen:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
1. Wählen Sie **Create Bucket**.
Der Status des Clusters ändert sich in *snapshotting*.
## Erstellen einer manuellen Sicherung (AWS CLI)
**Manuelles Backup eines serverlosen Caches mit dem AWS CLI**
Um eine manuelle Sicherung eines Caches mit dem zu erstellen AWS CLI, verwenden Sie den `create-serverless-snapshot`AWS CLI Vorgang mit den folgenden Parametern:
+ `--serverless-cache-name` – der Name des Serverless-Caches, für den Sie ein Backup erstellen.
+ `--serverless-cache-snapshot-name` – der Name des zu erstellenden Snapshots.
Für Linux, macOS oder Unix:
+
```
aws elasticache create-serverless-snapshot \
--serverless-cache-name CacheName \
--serverless-cache-snapshot-name bkup-20231127
```
Für Windows:
+
```
aws elasticache create-serverless-snapshot ^
--serverless-cache-name CacheName ^
--serverless-cache-snapshot-name bkup-20231127
```
**Manuelles Backup eines knotenbasierten Clusters mit dem AWS CLI**
Um ein manuelles Backup eines knotenbasierten Clusters mithilfe von zu erstellen AWS CLI, verwenden Sie den `create-snapshot`AWS CLI Vorgang mit den folgenden Parametern:
+ `--cache-cluster-id`
+ Wenn der Cluster, den Sie sichern, keine Replikatknoten hat, `--cache-cluster-id` ist dies beispielsweise der Name des Clusters, den Sie sichern. *mycluster*
+ Wenn der von Ihnen gesicherte Cluster über mindestens einen Replikatknoten verfügt, lautet der Name des Knotens im Clusters, den Sie für die Sicherung verwenden möchten `--cache-cluster-id`. Der Name könnte beispielsweise lauten. *mycluster-002*
Verwenden Sie diesen Parameter nur, wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) sichern.
+ `--replication-group-id`— Name des Valkey- oder Redis OSS-Clusters (Cluster-Modus aktiviert) (CLI/API: eine Replikationsgruppe), der als Quelle für das Backup verwendet werden soll. Verwenden Sie diesen Parameter, wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) sichern.
+ `--snapshot-name` Name des zu erstellenden Snapshots.
Für die Benennung von Clustern gelten die folgenden Einschränkungen:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
### Beispiel 1: Sicherung eines Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert), der keine Replikatknoten hat
Mit dem folgenden AWS CLI Vorgang wird das Backup `bkup-20150515` aus dem Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) erstellt`myNonClusteredRedis`, der keine Read Replicas enthält.
Für Linux, macOS oder Unix:
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis \
--snapshot-name bkup-20150515
```
Für Windows:
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis ^
--snapshot-name bkup-20150515
```
### Beispiel 2: Sicherung eines Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) mit Replikatknoten
Der folgende AWS CLI Vorgang erstellt das Backup `bkup-20150515` aus dem Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert). `myNonClusteredRedis` Diese Sicherung hat eine oder mehrere Lesereplikate.
Für Linux, macOS oder Unix:
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis-001 \
--snapshot-name bkup-20150515
```
Für Windows:
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis-001 ^
--snapshot-name bkup-20150515
```
**Beispielausgabe: Sicherung eines Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) mit Replikatknoten**
Die Ausgabe der Operation sieht in etwa folgendermaßen aus.
```
{
"Snapshot": {
"Engine": "redis",
"CacheParameterGroupName": "default.redis6.x",
"VpcId": "vpc-91280df6",
"CacheClusterId": "myNonClusteredRedis-001",
"SnapshotRetentionLimit": 0,
"NumCacheNodes": 1,
"SnapshotName": "bkup-20150515",
"CacheClusterCreateTime": "2017-01-12T18:59:48.048Z",
"AutoMinorVersionUpgrade": true,
"PreferredAvailabilityZone": "us-east-1c",
"SnapshotStatus": "creating",
"SnapshotSource": "manual",
"SnapshotWindow": "08:30-09:30",
"EngineVersion": "6.0",
"NodeSnapshots": [
{
"CacheSize": "",
"CacheNodeId": "0001",
"CacheNodeCreateTime": "2017-01-12T18:59:48.048Z"
}
],
"CacheSubnetGroupName": "default",
"Port": 6379,
"PreferredMaintenanceWindow": "wed:07:30-wed:08:30",
"CacheNodeType": "cache.m3.2xlarge",
"DataTiering": "disabled"
}
}
```
### Beispiel 3: Sicherung eines Clusters für Valkey oder Redis OSS (Clustermodus aktiviert)
Der folgende AWS CLI Vorgang erstellt das Backup `bkup-20150515` aus dem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert). `myClusteredRedis` Beachten Sie die Verwendung von `--replication-group-id` anstelle von `--cache-cluster-id` zum Identifizieren der Quelle. Beachten Sie außerdem, dass ElastiCache für die Sicherung der Replikatknoten verwendet wird, sofern vorhanden, und standardmäßig der primäre Knoten verwendet wird, wenn ein Replikatknoten nicht verfügbar ist.
Für Linux, macOS oder Unix:
```
aws elasticache create-snapshot \
--replication-group-id myClusteredRedis \
--snapshot-name bkup-20150515
```
Für Windows:
```
aws elasticache create-snapshot ^
--replication-group-id myClusteredRedis ^
--snapshot-name bkup-20150515
```
**Beispielausgabe: Sicherung eines Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert)**
Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus.
```
{
"Snapshot": {
"Engine": "redis",
"CacheParameterGroupName": "default.redis6.x.cluster.on",
"VpcId": "vpc-91280df6",
"NodeSnapshots": [
{
"CacheSize": "",
"NodeGroupId": "0001"
},
{
"CacheSize": "",
"NodeGroupId": "0002"
}
],
"NumNodeGroups": 2,
"SnapshotName": "bkup-20150515",
"ReplicationGroupId": "myClusteredRedis",
"AutoMinorVersionUpgrade": true,
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotStatus": "creating",
"SnapshotSource": "manual",
"SnapshotWindow": "10:00-11:00",
"EngineVersion": "6.0",
"CacheSubnetGroupName": "default",
"ReplicationGroupDescription": "2 shards 2 nodes each",
"Port": 6379,
"PreferredMaintenanceWindow": "sat:03:30-sat:04:30",
"CacheNodeType": "cache.r3.large",
"DataTiering": "disabled"
}
}
```
### Verwandte Themen
Weitere Informationen finden Sie unter [create-bucket](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-snapshot.html) in der *AWS CLI-Befehlsreferenz*.
## Erstellen eines Backups mit CloudFormation
Sie können CloudFormation es verwenden, um mithilfe der Eigenschaften oder eine Sicherungskopie Ihres ElastiCache Redis OSS- oder Valkey-Caches zu erstellen. `AWS::ElastiCache::ServerlessCache` `AWS::ElastiCache::ReplicationGroup`
**Verwenden der Ressource `AWS::ElastiCache::ServerlessCache`**
Verwenden Sie dies, um mithilfe der AWS::ElastiCache::ServerlessCache Ressource ein Backup zu erstellen:
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ServerlessCache
Properties:
...
ServerlessCacheName: "your-cache-name"
Engine: "redis"
CacheUsageLimits
```
**Verwendung der AWS::ElastiCache::ReplicationGroup Ressource**
Verwenden Sie die `AWS::ElastiCache::ReplicationGroup` Ressource:
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ReplicationGroup
Properties:
...
ReplicationGroupDescription: "Description of your replication group"
Engine: "redis"
CacheNodeType
NumCacheClusters
AutomaticFailoverEnabled
AtRestEncryptionEnabled
```
# Erstellen einer endgültigen Sicherung
Sie können mit der ElastiCache Konsole, der oder der AWS CLI ElastiCache API ein endgültiges Backup erstellen.
## Erstellen einer endgültigen Sicherung (Konsole)
Sie können eine endgültige Sicherung erstellen, wenn Sie mithilfe der Konsole einen serverlosen Valkey-, Memcached- oder Redis OSS-Cache oder einen knotenbasierten Valkey- oder Redis OSS-Cluster löschen. ElastiCache
**Um beim Löschen eines Caches eine endgültige Sicherung zu erstellen, wählen Sie im Löschdialogfeld unter Backup erstellen die Option **Ja** aus und geben Sie der Sicherung einen Namen.**
**Verwandte Themen**
+ [Mit dem AWS-Managementkonsole](Clusters.Delete.md#Clusters.Delete.CON)
+ [Löschen einer Replikationsgruppe (Konsole)](Replication.DeletingRepGroup.md#Replication.DeletingRepGroup.CON)
## Erstellen einer endgültigen Sicherung (AWS CLI)
Sie können ein endgültiges Backup erstellen, wenn Sie einen Cache löschen, indem Sie den AWS CLI
**Topics**
+ [Beim Löschen eines Valkey-Caches, eines Memcached Serverless Caches oder eines Redis OSS-Caches](#w2aac24b7c29b7b1b7)
+ [Beim Löschen eines Valkey- oder Redis OSS-Clusters ohne Read Replicas](#w2aac24b7c29b7b1b9)
+ [Wenn Sie einen Valkey- oder Redis OSS-Cluster mit Read Replicas löschen](#w2aac24b7c29b7b1c11)
### Beim Löschen eines Valkey-Caches, eines Memcached Serverless Caches oder eines Redis OSS-Caches
Verwenden Sie den `delete-serverless-cache`AWS CLI Vorgang mit den folgenden Parametern, um ein endgültiges Backup zu erstellen.
+ `--serverless-cache-name` – Name des zu löschenden Clusters.
+ `--final-snapshot-name` – Name des Backups.
Der folgende Code erstellt das endgültige Backup `bkup-20231127-final` beim Löschen des Caches `myserverlesscache`.
Für Linux, macOS oder Unix:
```
aws elasticache delete-serverless-cache \
--serverless-cache-name myserverlesscache \
--final-snapshot-name bkup-20231127-final
```
Für Windows:
```
aws elasticache delete-serverless-cache ^
--serverless-cache-name myserverlesscache ^
--final-snapshot-name bkup-20231127-final
```
Weitere Informationen finden Sie unter [delete-serverless-cache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache.html) in der Referenz zum *AWS CLI-Befehl*.
### Beim Löschen eines Valkey- oder Redis OSS-Clusters ohne Read Replicas
Verwenden Sie den Vorgang mit den folgenden Parametern, um ein endgültiges Backup für einen knotenbasierten Cluster ohne Read Replicas zu erstellen. `delete-cache-cluster`AWS CLI
+ `--cache-cluster-id` Name des zu löschenden Clusters.
+ `--final-snapshot-identifier` Name der Sicherung.
Der folgende Code erstellt die endgültige Sicherung `bkup-20150515-final` beim Löschen des Clusters `myRedisCluster`.
Für Linux, macOS oder Unix:
```
aws elasticache delete-cache-cluster \
--cache-cluster-id myRedisCluster \
--final-snapshot-identifier bkup-20150515-final
```
Für Windows:
```
aws elasticache delete-cache-cluster ^
--cache-cluster-id myRedisCluster ^
--final-snapshot-identifier bkup-20150515-final
```
Weitere Informationen finden Sie unter [delete-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-cluster.html) in der Referenz zum *AWS CLI-Befehl*.
### Wenn Sie einen Valkey- oder Redis OSS-Cluster mit Read Replicas löschen
Verwenden Sie den `delete-replication-group`AWS CLI Vorgang mit den folgenden Parametern, um beim Löschen einer Replikationsgruppe ein letztes Backup zu erstellen:
+ `--replication-group-id` Name der zu löschenden Replikationsgruppe.
+ `--final-snapshot-identifier` Name der endgültigen Sicherung.
Der folgende Code erstellt die endgültige Sicherung `bkup-20150515-final` beim Löschen der Replikationsgruppe `myReplGroup`.
Für Linux, macOS oder Unix:
```
aws elasticache delete-replication-group \
--replication-group-id myReplGroup \
--final-snapshot-identifier bkup-20150515-final
```
Für Windows:
```
aws elasticache delete-replication-group ^
--replication-group-id myReplGroup ^
--final-snapshot-identifier bkup-20150515-final
```
Weitere Informationen finden Sie unter [delete-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-replication-group.html) in der Referenz zum *AWS CLI-Befehl*.
# Beschreiben von Sicherungen
Die folgenden Verfahren zeigen, wie Sie eine Liste Ihrer Sicherungen anzeigen. Wenn Sie möchten, können Sie auch die Details zu einer bestimmten Sicherung anzeigen.
## Beschreibung von Backups (Konsole)
**Um Backups anzuzeigen, verwenden Sie AWS-Managementkonsole**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Backups** aus.
1. Um die Details zu einer bestimmten Sicherung anzuzeigen, aktivieren Sie das Kontrollkästchen links neben dem Namen der betreffenden Sicherung.
## Beschreiben von Serverless-Backups (AWS CLI)
Verwenden Sie die CLI-Operation `describe-serverless-cache-snapshots`, um eine Liste von Serverless-Backups und optional Details zu einem bestimmten Backup anzuzeigen.
**Beispiele**
Die folgende Operation listet mit dem Parameter `--max-records` bis zu 20 zum Konto gehörende Sicherungen auf. Wenn der Parameter `--max-records` weggelassen wird, werden bis zu 50 Sicherungen aufgelistet.
```
aws elasticache describe-serverless-cache-snapshots --max-records 20
```
Die folgende Operation listet mit dem Parameter `--serverless-cache-name` nur die zum Cache `my-cache` gehörenden Backups auf.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-name my-cache
```
Die folgende Operation listet mit dem Parameter `--serverless-cache-snapshot-name` die Details der Sicherung `my-backup` auf.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-snapshot-name my-backup
```
Weitere Informationen finden Sie [describe-serverless-cache-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-serverless-cache-snapshots.html)in der AWS CLI Befehlsreferenz.
## Beschreibung knotenbasierter Cluster-Backups ()AWS CLI
Verwenden Sie den `describe-snapshots` CLI-Vorgang, um eine Liste von knotenbasierten Cluster-Backups und optional Details zu einem bestimmten Backup anzuzeigen.
**Beispiele**
Die folgende Operation listet mit dem Parameter `--max-records` bis zu 20 zum Konto gehörende Sicherungen auf. Wenn der Parameter `--max-records` weggelassen wird, werden bis zu 50 Sicherungen aufgelistet.
```
aws elasticache describe-snapshots --max-records 20
```
Die folgende Operation listet mit dem Parameter `--cache-cluster-id` nur die zum Cluster `my-cluster` gehörenden Sicherungen auf.
```
aws elasticache describe-snapshots --cache-cluster-id my-cluster
```
Die folgende Operation listet mit dem Parameter `--snapshot-name` die Details der Sicherung `my-backup` auf.
```
aws elasticache describe-snapshots --snapshot-name my-backup
```
Weitere Informationen finden Sie unter [describe-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-snapshots.html) in der Befehlsreferenz.AWS CLI
# Kopieren eines Backups
Sie können eine Kopie jedes beliebigen Backups erstellen. Dabei spielt es keine Rolle, ob es automatisch oder manuell erstellt wurde. Sie können Ihr Backup auch exportieren, sodass Sie von außen darauf zugreifen können ElastiCache. Eine Anleitung zum Exportieren Ihrer Sicherung finden Sie unter [Exportieren einer Sicherung](backups-exporting.md).
Das folgende Verfahren zeigt, wie Sie ein Backup kopieren.
## Kopieren von Backups (Konsole)
**So kopieren Sie ein Backup (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Um eine Liste Ihrer Sicherungen anzuzeigen, wählen Sie im linken Navigationsbereich **Backups** aus.
1. Aktivieren Sie in der Liste der Sicherungen das Kontrollkästchen links neben dem Namen der Sicherung, die Sie kopieren möchten.
1. Wählen Sie **Aktionen** und dann **Kopieren** aus.
1. Geben Sie in das Feld **New backup name** einen Namen für die neue Sicherung ein.
1. Wählen Sie die Option **Kopieren** aus.
## Kopieren eines Serverless-Backups (AWS CLI)
Verwenden Sie die Operation `copy-serverless-cache-snapshot`, um ein Backup eines Serverless-Caches zu kopieren.
**Parameters**
+ `--source-serverless-cache-snapshot-name` Name der zu kopierenden Sicherung.
+ `--target-serverless-cache-snapshot-name` Name der Sicherungskopie.
Das folgende Beispiel erstellt eine Kopie einer automatischen Sicherung.
Für Linux, macOS oder Unix:
```
aws elasticache copy-serverless-cache-snapshot \
--source-serverless-cache-snapshot-name automatic.my-cache-2023-11-27-03-15 \
--target-serverless-cache-snapshot-name my-backup-copy
```
Für Windows:
```
aws elasticache copy-serverless-cache-snapshot ^
--source-serverless-cache-snapshot-name automatic.my-cache-2023-11-27-03-15 ^
--target-serverless-cache-snapshot-name my-backup-copy
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-serverless-cache-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-serverless-cache-snapshot.html) im *AWS CLI*.
## Ein knotenbasiertes Cluster-Backup wird kopiert ()AWS CLI
Verwenden Sie den Vorgang, um eine Sicherung eines knotenbasierten Clusters zu kopieren. `copy-snapshot`
**Parameters**
+ `--source-snapshot-name` Name der zu kopierenden Sicherung.
+ `--target-snapshot-name` Name der Sicherungskopie.
+ `--target-bucket` Reserviert zum Exportieren einer Sicherung. Verwenden Sie den Parameter nicht, um eine Kopie einer Sicherung anzufertigen. Weitere Informationen finden Sie unter [Exportieren einer Sicherung](backups-exporting.md).
Das folgende Beispiel erstellt eine Kopie einer automatischen Sicherung.
Für Linux, macOS oder Unix:
```
aws elasticache copy-snapshot \
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 \
--target-snapshot-name amzn-s3-demo-bucket
```
Für Windows:
```
aws elasticache copy-snapshot ^
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 ^
--target-snapshot-name amzn-s3-demo-bucket
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html) im *AWS CLI*.
# Exportieren einer Sicherung
Amazon ElastiCache unterstützt den Export Ihres OSS-Backups ElastiCache für Redis in einen Amazon Simple Storage Service (Amazon S3) -Bucket, sodass Sie von außen ElastiCache darauf zugreifen können. Sie können ein Backup mithilfe der ElastiCache Konsole AWS CLI, der oder der ElastiCache API exportieren.
Das Exportieren eines Backups kann hilfreich sein, wenn Sie einen Cluster in einer anderen AWS Region starten müssen. Sie können Ihre Daten in eine AWS Region exportieren, die RDB-Datei in die neue AWS Region kopieren und dann diese RDB-Datei verwenden, um den neuen Cache zu speichern, anstatt darauf zu warten, dass der neue Cluster durch Use gefüllt wird. Informationen zum Erstellen eines neuen Clusters durch Seeding finden Sie unter [Tutorial: Seeding eines neuen knotenbasierten Clusters mit einem extern erstellten Backup](backups-seeding-redis.md). Ein weiterer Grund, warum Sie die Daten Ihres Caches exportieren möchten, ist die Verwendung der RDB-Datei für die Offline-Verarbeitung.
**Wichtig**
Das ElastiCache Backup und der Amazon S3 S3-Bucket, in den Sie es kopieren möchten, müssen sich in derselben AWS Region befinden.
Obwohl Sicherungen, die in einen Amazon-S3-Bucket kopiert werden, verschlüsselt sind, empfehlen wir dringend, dass Sie anderen Personen keinen Zugriff auf den Amazon-S3-Bucket mit Ihren gespeicherten Sicherungen gewähren.
Das Exportieren eines Backups nach Amazon S3 wird für Cluster, die Daten-Tiering verwenden, nicht unterstützt. Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
Das Exportieren eines Backups ist verfügbar für: knotenbasierte Valkey-Cluster, knotenbasierte Redis-OSS-Cluster und serverlose Valkey-, Memcached- und Redis OSS-Caches. Das Exportieren eines Backups ist für knotenbasierte Memcached-Cluster nicht verfügbar.
Bevor Sie ein Backup in einen Amazon S3 S3-Bucket exportieren können, müssen Sie über einen Amazon S3 S3-Bucket in derselben AWS Region wie das Backup verfügen. Gewähren ElastiCache Sie Zugriff auf den Bucket. Die ersten beiden Schritte zeigen, wie Sie dabei vorgehen.
## Erstellen Sie einen Amazon S3 S3-Bucket
Die folgenden Schritte verwenden die Amazon S3 S3-Konsole, um einen Amazon S3 S3-Bucket zu erstellen, in den Sie Ihr ElastiCache Backup exportieren und speichern.
**So erstellen Sie einen Amazon-S3-Bucket**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Wählen Sie **Create Bucket (Bucket erstellen)** aus.
1. Verfahren Sie unter **Create a Bucket – Select a Bucket Name and Region** wie folgt:
1. Geben Sie für **Bucket-Name** einen Namen für Ihren Amazon-S3-Bucket ein.
Der Name Ihres Amazon-S3-Buckets muss DNS-konform sein. Andernfalls ElastiCache kann ich nicht auf Ihre Backup-Datei zugreifen. Die Regeln für die DNS-Konformität lauten:
+ Bucket-Namen müssen mindestens 3 und dürfen höchstens 63 Zeichen umfassen.
+ Die Namen müssen eine Folge aus einer oder mehreren Beschriftungen darstellen, die durch einen Punkt (.) getrennt sind, wobei jede Beschriftung:
+ mit einem Kleinbuchstaben oder einer Zahl beginnen.
+ mit einem Kleinbuchstaben oder einer Zahl beginnen.
+ Enthält nur Kleinbuchstaben, Zahlen und Bindestriche.
+ Er darf nicht als IP-Adresse (z. B. 192.0.2.0) formatiert sein.
1. Wählen Sie aus der **Regionsliste** eine AWS Region für Ihren Amazon S3 S3-Bucket aus. Diese AWS Region muss dieselbe AWS Region sein wie das ElastiCache Backup, das Sie exportieren möchten.
1. Wählen Sie **Erstellen** aus.
Weitere Informationen zum Erstellen eines Amazon-S3-Buckets finden Sie unter [Erstellen von Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html) im *Handbuch für Amazon Simple Storage Service*.
## Gewähren Sie ElastiCache Zugriff auf Ihren Amazon S3 S3-Bucket
ElastiCache Um einen Snapshot in einen Amazon S3 S3-Bucket kopieren zu können, müssen Sie Ihre IAM-Bucket-Richtlinie aktualisieren, um ElastiCache Zugriff auf den Bucket zu gewähren.
**Warnung**
Obwohl Sicherungen, die in einen Amazon-S3-Bucket kopiert werden, verschlüsselt sind, kann jede Person mit Zugriff auf Ihren Amazon-S3-Bucket auf Ihre Daten zugreifen. Daher wird sehr dazu geraten, IAM-Richtlinien einzurichten, um unbefugten Zugriff auf diesen Amazon-S3-Bucket zu verhindern. Weitere Informationen finden Sie unter [Verwalten des Zugriffs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) im *Benutzerhandbuch zu Amazon S3*.
Führen Sie die folgenden Schritte aus, um die korrekten Berechtigungen für einen Amazon S3 Bucket zu erstellen.
**Um ElastiCache Zugriff auf einen S3-Bucket zu gewähren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Wählen Sie den Namen des Amazon-S3-Buckets aus, in den Sie die Sicherung kopieren möchten. Dies sollte der in [Erstellen Sie einen Amazon S3 S3-Bucket](#backups-exporting-create-s3-bucket) erstellte S3-Bucket sein.
1. Wählen Sie die Registerkarte **Permissions** (Berechtigungen) und unter **Permissions** (Berechtigungen) **Access control list (ACL)** (Zugriffssteuerungsliste (ACL)) und dann **Edit** (Bearbeiten) aus.
1. Fügen Sie die Fügen Sie die Kanonische Empfänger-ID `540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353` mit den folgenden Optionen hinzu:
+ **Objekte – Auflisten oder Schreiben**
+ **Bucket ACL: Lesen oder Schreiben**
**Anmerkung**
Für die GovCloud PDT-Region lautet die Canonical ID. `40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6`
Für die GovCloud OSU-Region lautet die kanonische ID. `c54286759d2a83da9c480405349819c993557275cf37d820d514b42da6893f5c`
1. Wählen Sie **Speichern**.
## Exportieren Sie ein Backup ElastiCache
Jetzt haben Sie Ihren S3-Bucket erstellt und ElastiCache Zugriffsberechtigungen erteilt. Als Nächstes können Sie die ElastiCache Konsole, die AWS CLI oder die ElastiCache API verwenden, um Ihren Snapshot dorthin zu exportieren.
Nachfolgend finden Sie ein Beispiel dafür, wie die aktualisierte Richtlinie aussehen könnte.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399484",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::hkg-elasticache-backup",
"arn:aws:s3:::hkg-elasticache-backup/*"
]
}
]
}
```
------
Für Opt-in-Regionen finden Sie im Folgenden ein Beispiel dafür, wie die aktualisierte IAM-Richtlinie für den S3-Bucket aussehen könnte. (In diesem Beispiel wird die Region Asien-Pazifik (Hongkong) verwendet.)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399483",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::hkg-elasticache-backup",
"arn:aws:s3:::hkg-elasticache-backup/*"
]
},
{
"Sid": "Stmt15399484",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::hkg-elasticache-backup",
"arn:aws:s3:::hkg-elasticache-backup/*"
]
}
]
}
```
------
### Ein ElastiCache Backup exportieren (Konsole)
Die folgenden Schritte verwenden die ElastiCache Konsole, um ein Backup in einen Amazon S3 S3-Bucket zu exportieren, sodass Sie von außerhalb darauf zugreifen können ElastiCache. Der Amazon S3 S3-Bucket muss sich in derselben AWS Region wie das ElastiCache Backup befinden.
**Um ein ElastiCache Backup in einen Amazon S3 S3-Bucket zu exportieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Um eine Liste Ihrer Sicherungen anzuzeigen, wählen Sie im linken Navigationsbereich **Backups** aus.
1. Aktivieren Sie in der Liste der Sicherungen das Kontrollkästchen links neben dem Namen der Sicherung, die Sie exportieren möchten.
1. Wählen Sie die Option **Kopieren** aus.
1. Gehen Sie im Dialogfeld **Create a Copy of the Backup (Eine Kopie der Sicherung erstellen?)** wie folgt vor:
1. Geben Sie in das Feld **New backup name** einen Namen für die neue Sicherung ein.
Der Name muss zwischen 1 und 1.000 Zeichen lang sein und UTF-8-codierbar sein.
ElastiCache fügt eine Instanz-ID und `.rdb` zu dem Wert hinzu, den Sie hier eingeben. Wenn Sie z. B. `my-exported-backup` eingeben, erstellt ElastiCache `my-exported-backup-0001.rdb`.
1. Wählen Sie aus der Liste **S3-Zielspeicherort** den Namen des Amazon-S3-Buckets aus, in den Sie Ihre Sicherung kopieren möchten (der von Ihnen unter [Erstellen Sie einen Amazon S3 S3-Bucket](#backups-exporting-create-s3-bucket) erstellte Bucket).
Der **Ziel-S3-Standort** muss ein Amazon S3 S3-Bucket in der AWS Region des Backups mit den folgenden Berechtigungen sein, damit der Exportvorgang erfolgreich ist.
+ Objektzugriff – **Lesen** und **Schreiben**.
+ Berechtigungszugriff – **Lesen**.
Weitere Informationen finden Sie unter [Gewähren Sie ElastiCache Zugriff auf Ihren Amazon S3 S3-Bucket](#backups-exporting-grant-access).
1. Wählen Sie die Option **Kopieren** aus.
**Anmerkung**
Wenn Ihr S3-Bucket nicht über die erforderlichen Berechtigungen verfügt, ElastiCache um ein Backup dorthin zu exportieren, erhalten Sie eine der folgenden Fehlermeldungen. Kehren Sie zu [Gewähren Sie ElastiCache Zugriff auf Ihren Amazon S3 S3-Bucket](#backups-exporting-grant-access) zurück, um die angegebenen Berechtigungen hinzuzufügen, und exportieren Sie Ihre Sicherung erneut.
ElastiCache hat keine LESE-Rechte %s für den S3-Bucket erhalten.
**Lösung:** Fügen Sie Leseberechtigungen für den Bucket hinzu.
ElastiCache hat keine SCHREIBBERECHTIGUNG %s für den S3-Bucket erhalten.
**Lösung:** Fügen Sie Schreibberechtigungen für den Bucket hinzu.
ElastiCache hat keine READ\$1ACP-Berechtigungen %s für den S3-Bucket erhalten.
**Lösung:** Fügen Sie **Read**-Zugriff für Berechtigungen für den Bucket hinzu.
Wenn Sie Ihr Backup in eine andere AWS Region kopieren möchten, verwenden Sie Amazon S3, um es zu kopieren. Weitere Informationen finden Sie unter [Kopieren von Objekten ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MakingaCopyofanObject.html) im *Entwicklerhandbuch zu Amazon Simple Storage Service*.
### Exportieren eines ElastiCache serverlosen Backups ()AWS CLI
**Exportieren des Backups eines Serverless-Caches**
Exportieren Sie die Sicherung mit der CLI-Operation `export-serverless-cache-snapshot` mit den folgenden Parametern zu einem Amazon-S3-Bucket:
**Parameters**
+ `--serverless-cache-snapshot-name` Name der zu kopierenden Sicherung.
+ `--s3-bucket-name` – Name des Amazon-S3-Buckets, zu dem die Sicherung exportiert werden soll. Im angegebenen Bucket wird eine Kopie der Sicherung erstellt.
Damit der Exportvorgang erfolgreich ist, `--s3-bucket-name` muss es sich um einen Amazon S3 S3-Bucket in der AWS Region des Backups mit den folgenden Berechtigungen handeln.
+ Objektzugriff – **Lesen** und **Schreiben**.
+ Berechtigungszugriff – **Lesen**.
Die folgende Operation kopiert eine Sicherung zu my-s3-bucket.
Für Linux, macOS oder Unix:
```
aws elasticache export-serverless-cache-snapshot \
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 \
--s3-bucket-name my-s3-bucket
```
Für Windows:
```
aws elasticache export-serverless-cache-snapshot ^
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 ^
--s3-bucket-name my-s3-bucket
```
### Exportieren eines knotenbasierten ElastiCache Cluster-Backups ()AWS CLI
**Exportieren eines Backups eines knotenbasierten Clusters**
Exportieren Sie die Sicherung mit der CLI-Operation `copy-snapshot` mit den folgenden Parametern zu einem Amazon-S3-Bucket:
**Parameters**
+ `--source-snapshot-name` Name der zu kopierenden Sicherung.
+ `--target-snapshot-name` Name der Sicherungskopie.
Der Name muss zwischen 1 und 1.000 Zeichen lang sein und UTF-8-codierbar sein.
ElastiCache fügt dem hier eingegebenen Wert eine Instanz-ID und `.rdb` hinzu. Wenn Sie z. B. `my-exported-backup` eingeben, erstellt ElastiCache `my-exported-backup-0001.rdb`.
+ `--target-bucket` – Name des Amazon-S3-Buckets, zu dem die Sicherung exportiert werden soll. Im angegebenen Bucket wird eine Kopie der Sicherung erstellt.
Damit der Exportvorgang erfolgreich ist, `--target-bucket` muss es sich um einen Amazon S3 S3-Bucket in der AWS Region des Backups mit den folgenden Berechtigungen handeln.
+ Objektzugriff – **Lesen** und **Schreiben**.
+ Berechtigungszugriff – **Lesen**.
Weitere Informationen finden Sie unter [Gewähren Sie ElastiCache Zugriff auf Ihren Amazon S3 S3-Bucket](#backups-exporting-grant-access).
Die folgende Operation kopiert eine Sicherung zu my-s3-bucket.
Für Linux, macOS oder Unix:
```
aws elasticache copy-snapshot \
--source-snapshot-name automatic.my-redis-primary-2016-06-27-03-15 \
--target-snapshot-name my-exported-backup \
--target-bucket my-s3-bucket
```
Für Windows:
```
aws elasticache copy-snapshot ^
--source-snapshot-name automatic.my-redis-primary-2016-06-27-03-15 ^
--target-snapshot-name my-exported-backup ^
--target-bucket my-s3-bucket
```
# Wiederherstellen aus einem Backup in einen neuen Cache
Sie können ein vorhandenes Backup von Valkey in einem neuen Valkey-Cache oder einem knotenbasierten Cluster wiederherstellen und ein vorhandenes Redis OSS-Backup in einem neuen Redis OSS-Cache oder einem knotenbasierten Cluster wiederherstellen. Sie können auch ein vorhandenes Memcached-Cache-Backup in einem neuen serverlosen Memcached-Cache wiederherstellen.
## Wiederherstellen eines Backups in einem Serverless-Cache (Konsole)
**Anmerkung**
ElastiCache Serverless unterstützt RDB-Dateien, die mit Valkey 7.2 und höher kompatibel sind, sowie Redis OSS-Versionen zwischen 5.0 und der neuesten verfügbaren Version.
**So stellen Sie ein Backup in einem Serverless-Cache wieder her (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Konsole unter. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Backups** aus.
1. Aktivieren Sie in der Liste der Backups das Kontrollkästchen links neben dem Namen des Backups, das Sie wiederherstellen möchten.
1. Wählen Sie **Aktionen** und anschließend **Wiederherstellen** aus.
1. Geben Sie einen Namen und eine optionale Beschreibung für den neuen Serverless-Cache ein.
1. Klicken Sie auf **Erstellen**, um Ihren neuen Cache zu erstellen und Daten aus Ihrem Backup zu importieren.
## Wiederherstellung eines Backups in einem knotenbasierten Cluster (Konsole)
**So stellen Sie ein Backup auf einem knotenbasierten Cluster (Konsole) wieder her**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Backups** aus.
1. Aktivieren Sie in der Liste der Sicherungen das Kontrollkästchen links neben dem Namen der Sicherung, aus der Sie wiederherstellen möchten.
1. Wählen Sie **Aktionen** und anschließend **Wiederherstellen** aus.
1. Wählen Sie **Node-based Cache** und passen Sie die Cluster-Einstellungen wie Knotentyp, Größe, Anzahl der Shards, Replikate, AZ-Platzierung und Sicherheitseinstellungen an.
1. Wählen Sie **Erstellen**, um Ihren neuen knotenbasierten Cluster zu erstellen und Daten aus Ihrem Backup zu importieren.
## Wiederherstellen eines Backups in einem Serverless-Cache (AWS CLI)
**Anmerkung**
ElastiCache Serverless unterstützt RDB-Dateien, die mit Valkey 7.2 und höher kompatibel sind, sowie Redis OSS-Versionen zwischen 5.0 und der neuesten verfügbaren Version.
**So stellen Sie ein Backup in einem neuen Serverless-Cache wieder her (AWS CLI)**
Im folgenden AWS CLI Beispiel wird ein neuer Cache erstellt, der Daten aus einer Sicherung verwendet `create-serverless-cache` und aus dieser importiert.
Für Linux, macOS oder Unix:
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine redis
--snapshot-arns-to-restore Snapshot-ARN
```
Für Windows:
```
aws elasticache create-serverless-cache ^
--serverless-cache-name CacheName ^
--engine redis ^
--snapshot-arns-to-restore Snapshot-ARN
```
# Löschen einer Sicherung
Eine automatische Sicherung wird automatisch gelöscht, wenn ihre Aufbewahrungsfrist abläuft. Wenn Sie einen Cluster löschen, werden alle seine automatischen Sicherungen ebenfalls gelöscht. Wenn Sie eine Replikationsgruppe löschen, werden alle automatischen Sicherungen von den Clustern in der betreffenden Gruppe ebenfalls gelöscht.
ElastiCache bietet einen API-Löschvorgang, mit dem Sie ein Backup jederzeit löschen können, unabhängig davon, ob das Backup automatisch oder manuell erstellt wurde. Da für manuelle Sicherungen keine Aufbewahrungsfrist gilt, können sie nur durch manuelles Löschen entfernt werden.
Sie können ein Backup mithilfe der ElastiCache Konsole AWS CLI, der oder der ElastiCache API löschen.
## Löschen einer Sicherung (Konsole)
Das folgende Verfahren löscht ein Backup mithilfe der ElastiCache Konsole.
**So löschen Sie ein Backup**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Sicherungen** aus.
Der Bildschirm „Backups“ wird mit einer Liste Ihrer Sicherungen angezeigt.
1. Aktivieren Sie das Kontrollkästchen links neben dem Namen der Sicherung, die Sie löschen möchten.
1. Wählen Sie **Löschen** aus.
1. Wenn Sie diese Sicherung löschen möchten, wählen Sie auf dem Bestätigungsbildschirm **Delete Backup** die Option **Delete** aus. Der Status wird in *deleting* geändert.
## Löschen eines Serverless-Backups (AWS CLI)
Verwenden Sie den AWS CLI Vorgang delete-snapshot mit dem folgenden Parameter, um ein serverloses Backup zu löschen.
+ `--serverless-cache-snapshot-name` Name der zu löschenden Sicherung.
Der folgende Code löscht die Sicherung `myBackup`.
```
aws elasticache delete-serverless-cache-snapshot --serverless-cache-snapshot-name myBackup
```
Weitere Informationen finden Sie unter [delete-serverless-cache-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache-snapshot.html) in der Referenz zum *AWS CLI-Befehl*.
## Löschen einer knotenbasierten Clustersicherung ()AWS CLI
Verwenden Sie den AWS CLI Vorgang delete-snapshot mit dem folgenden Parameter, um eine knotenbasierte Clustersicherung zu löschen.
+ `--snapshot-name` Name der zu löschenden Sicherung.
Der folgende Code löscht die Sicherung `myBackup`.
```
aws elasticache delete-snapshot --snapshot-name myBackup
```
Weitere Informationen finden Sie unter [delete-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-snapshot.html) in der*AWS CLI-CLI-Befehlsreferenz*.
# Markieren von Sicherungen
Sie können -Tresoren Metadaten in Form von Tags zuweisen. Mit Tags (Markierungen) können Sie Ihre -Ressourcen auf unterschiedliche Weise kategorisieren (z. B. nach Zweck, Eigentümer oder Umgebung). Dies ist nützlich, wenn Sie viele Ressourcen desselben Typs haben — In diesem Fall können Sie schnell bestimmte Ressourcen basierend auf den zugewiesenen Tags (Markierungen) bestimmen. Weitere Informationen finden Sie unter [Ressourcen, die markiert werden können](Tagging-Resources.md#Tagging-your-resources).
Mithilfe von Tags zur Kostenzuweisung können Sie Ihre Kosten für mehrere AWS Dienste verfolgen, indem Sie Ihre Ausgaben auf Rechnungen nach Tagwerten gruppieren. Weitere Informationen zu Kostenzuordnungs-Tags finden Sie unter [Verwenden von Kostenzuordnungs-Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html).
Mithilfe der ElastiCache Konsole AWS CLI, der oder der ElastiCache API können Sie Kostenzuordnungs-Tags zu Ihren Backups hinzufügen, auflisten, ändern, entfernen oder kopieren. Weitere Informationen finden Sie unter [Überwachung von Kosten mit Kostenzuordnungs-Tags](Tagging.md).
# Tutorial: Seeding eines neuen knotenbasierten Clusters mit einem extern erstellten Backup
Wenn Sie einen neuen knotenbasierten Valkey- oder Redis OSS-Cluster erstellen, können Sie ihn mit Daten aus einer Valkey- oder Redis OSS .rdb-Backup-Datei versorgen. Das Seeding des Clusters ist nützlich, wenn Sie derzeit eine Valkey- oder Redis OSS-Instanz außerhalb von verwalten und Ihren neuen knotenbasierten Cluster ElastiCache für Redis OSS mit Ihren vorhandenen Valkey ElastiCache - oder Redis OSS-Daten auffüllen möchten.
Informationen zum Seeding eines neuen knotenbasierten Valkey- oder Redis OSS-Clusters aus einem Valkey- oder Redis OSS-Backup, das in Amazon erstellt wurde, finden Sie unter. ElastiCache [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md)
Wenn Sie eine Valkey- oder Redis OSS .rdb-Datei zum Seeding eines neuen knotenbasierten Clusters verwenden, können Sie Folgendes tun:
+ Führen Sie ein Upgrade von einem nicht partitionierten Cluster auf einen knotenbasierten Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) durch, auf dem Redis OSS Version 3.2.4 ausgeführt wird.
+ Geben Sie eine Reihe von Shards (in der API und CLI als Knotengruppen bezeichnet) im neuen knotenbasierten Cluster an. Diese Anzahl kann sich von der Anzahl der Shards im knotenbasierten Cluster unterscheiden, der zur Erstellung der Backup-Datei verwendet wurde.
+ Geben Sie einen anderen Knotentyp für den neuen knotenbasierten Cluster an, der größer oder kleiner ist als der Knotentyp, der in dem Cluster verwendet wurde, der das Backup erstellt hat. Wenn Sie auf einen kleineren Knotentyp skalieren, stellen Sie sicher, dass der neue Knotentyp über ausreichend Speicher für Ihre Daten und den OSS-Overhead von Valkey oder Redis verfügt. Weitere Informationen finden Sie unter [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md).
+ Verteilen Sie Ihre Schlüssel in den Steckplätzen des neuen Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert) anders als in dem Cluster, der zur Erstellung der Backup-Datei verwendet wurde.
**Anmerkung**
Sie können einen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) nicht anhand einer .rdb-Datei starten, die aus einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) erstellt wurde.
**Wichtig**
Sie müssen sicherstellen, dass Ihre Valkey- oder Redis OSS-Backup-Daten die Ressourcen des Knotens nicht überschreiten. Sie können beispielsweise keine .rdb-Datei mit 5 GB Valkey- oder Redis-OSS-Daten auf einen cache.m3.medium-Knoten hochladen, der über 2,9 GB Arbeitsspeicher verfügt.
Wenn die Sicherung zu groß ist, lautet der Status des resultierenden Clusters `restore-failed`. In diesem Fall müssen Sie den Cluster löschen und von Neuem beginnen.
Eine vollständige Liste der Knotentypen und Spezifikationen finden Sie unter [Redis OSS-Knotentyp-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific) und zu [ ElastiCache Amazon-Produktfunktionen und -details](https://aws.amazon.com/elasticache/details/).
Sie können eine Valkey- oder Redis OSS .rdb-Datei nur mit der serverseitigen Amazon S3 S3-Verschlüsselung (SSE-S3) verschlüsseln. Weitere Informationen finden Sie unter [Schützen von Daten mithilfe serverseitiger Verschlüsselung](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html).
Im Folgenden finden Sie Themen, die Sie durch die Migration Ihres Clusters von außerhalb ElastiCache für Valkey oder Redis OSS zu für Redis OSS führen. ElastiCache
**Topics**
+ [Schritt 1: Erstellen Sie ein Valkey- oder Redis OSS-Backup](#backups-seeding-redis-create-backup)
+ [Schritt 2: Erstellen eines Amazon-S3-Buckets und -Ordners](#backups-seeding-redis-create-s3-bucket)
+ [Schritt 3: Hochladen Ihrer Sicherung auf Amazon S3](#backups-seeding-redis-upload)
+ [Schritt 4: Gewähren ElastiCache Sie Lesezugriff auf die .rdb-Datei](#backups-seeding-redis-grant-access)
**Topics**
+ [Schritt 1: Erstellen Sie ein Valkey- oder Redis OSS-Backup](#backups-seeding-redis-create-backup)
+ [Schritt 2: Erstellen eines Amazon-S3-Buckets und -Ordners](#backups-seeding-redis-create-s3-bucket)
+ [Schritt 3: Hochladen Ihrer Sicherung auf Amazon S3](#backups-seeding-redis-upload)
+ [Schritt 4: Gewähren ElastiCache Sie Lesezugriff auf die .rdb-Datei](#backups-seeding-redis-grant-access)
## Schritt 1: Erstellen Sie ein Valkey- oder Redis OSS-Backup
**Um das Valkey- oder Redis OSS-Backup zu erstellen, um Ihre ElastiCache Redis OSS-Instanz zu starten**
1. Connect zu Ihrer vorhandenen Valkey- oder Redis OSS-Instanz her.
1. Führen Sie einen der beiden `BGSAVE` `SAVE` Operationen aus, um ein Backup zu erstellen. Achten Sie auf den Speicherort der .rdb-Datei.
`BGSAVE` ist asynchron und blockiert während der Verarbeitung keine anderen Clients. Weitere Informationen finden Sie unter [BGSAVE](https://valkey.io/commands/bgsave) auf der Valkey-Website.
`SAVE` ist synchron und blockiert andere Vorgänge, bis sie Verarbeitung abgeschlossen ist. Weitere Informationen finden Sie unter [SAVE](https://valkey.io/commands/save) auf der Valkey-Website.
Weitere Informationen zum Erstellen eines Backups finden Sie unter [Persistence](https://valkey.io/topics/persistence) auf der Valkey-Website.
## Schritt 2: Erstellen eines Amazon-S3-Buckets und -Ordners
Wenn Sie die Sicherungsdatei erstellt haben, müssen Sie sie zu einem Ordner innerhalb eines Amazon-S3-Buckets hochladen. Hierzu müssen bereits ein Amazon-S3-Bucket und ein Ordner innerhalb dieses Buckets vorhanden sein. Wenn Sie bereits einen Amazon-S3-Bucket und Ordner mit den entsprechenden Berechtigungen besitzen, können Sie mit [Schritt 3: Hochladen Ihrer Sicherung auf Amazon S3](#backups-seeding-redis-upload) fortfahren.
**So erstellen Sie einen Amazon-S3-Bucket**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Führen Sie die Anweisungen zum Erstellen eines Amazon S3 Buckets unter[Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html) im *Benutzerhandbuch zu Amazon Simple Storage Service* aus.
Der Name Ihres Amazon-S3-Buckets muss DNS-konform sein. Andernfalls ElastiCache kann ich nicht auf Ihre Backup-Datei zugreifen. Die Regeln für die DNS-Konformität lauten:
+ Bucket-Namen müssen mindestens 3 und dürfen höchstens 63 Zeichen umfassen.
+ Die Namen müssen eine Folge aus einer oder mehreren Beschriftungen darstellen, die durch einen Punkt (.) getrennt sind, wobei jede Beschriftung:
+ mit einem Kleinbuchstaben oder einer Zahl beginnen.
+ mit einem Kleinbuchstaben oder einer Zahl beginnen.
+ Enthält nur Kleinbuchstaben, Zahlen und Bindestriche.
+ Er darf nicht als IP-Adresse (z. B. 192.0.2.0) formatiert sein.
Sie müssen Ihren Amazon S3 S3-Bucket in derselben AWS Region wie Ihr neuer OSS-Cluster ElastiCache für Redis erstellen. Dieser Ansatz stellt sicher, dass beim ElastiCache Lesen Ihrer RDB-Datei aus Amazon S3 die höchste Datenübertragungsgeschwindigkeit erreicht wird.
**Anmerkung**
Um Ihre Daten so sicher wie möglich zu halten, sollten Sie die Berechtigungen für Ihr Amazon-S3-Bucket so restriktiv wie möglich gestalten. Gleichzeitig müssen die Berechtigungen weiterhin zulassen, dass der Bucket und sein Inhalt für das Seeding Ihres neuen Valkey- oder Redis-OSS-Clusters verwendet werden können.
**So fügen Sie einem Amazon S3 Bucket einen Ordner hinzu**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Wählen Sie den Namen des Buckets aus, in den die .rdb-Datei hochgeladen werden soll.
1. Wählen Sie **Create folder**.
1. Geben Sie einen Namen für den neuen Ordner ein.
1. Wählen Sie **Speichern**.
Notieren Sie sich sowohl den Bucketnamen als auch den Ordnernamen.
## Schritt 3: Hochladen Ihrer Sicherung auf Amazon S3
Laden Sie jetzt die .rdb-Datei hoch, die Sie in [Schritt 1: Erstellen Sie ein Valkey- oder Redis OSS-Backup](#backups-seeding-redis-create-backup) erstellt haben. Sie laden sie in den Amazon-S3-Bucket und -Ordner hoch, die sie in [Schritt 2: Erstellen eines Amazon-S3-Buckets und -Ordners](#backups-seeding-redis-create-s3-bucket) erstellt haben. Weitere Informationen zu dieser Aufgabe finden Sie unter [Objekte in einen Bucket einfügen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html). Wählen Sie zwischen den Schritten 2 und 3 den Namen des von Ihnen erstellten Ordners aus.
**So laden Sie Ihre .rdb-Datei in einen Amazon-S3-Ordner hoch**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Wählen Sie den Namen des Amazon-S3-Bucket aus, den Sie in Schritt 2 erstellt haben.
1. Wählen Sie den Namen des Ordners aus, den Sie in Schritt 2 erstellt haben.
1. Klicken Sie auf **Upload**.
1. Klicken Sie auf **Add files**.
1. Navigieren Sie zu der Datei oder den Dateien, die Sie hochladen möchten, und wählen Sie dann die Datei oder die Dateien aus. Halten Sie zur Auswahl mehrerer Dateien die Strg-Taste während der Auswahl der Dateinamen gedrückt.
1. Klicken Sie auf **Open**.
1. Bestätigen Sie, dass die korrekte Datei bzw. die korrekten Dateien im Dialogfeld **Upload** aufgelistet werden. Wählen Sie dann **Upload**.
Notieren Sie den Pfad zu Ihrer .rdb-Datei. Wenn der Bucket-Name z. B. `myBucket` und der Pfad `myFolder/redis.rdb` lautet, geben Sie `myBucket/myFolder/redis.rdb` ein. Sie benötigen diesen Pfad zum Starten des neuen Clusters mit den Daten in dieser Sicherung.
Weitere Informationen finden Sie unter [Bucket-Einschränkungen und -Limits](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) im *Entwicklerhandbuch zu Amazon Simple Storage Service*.
## Schritt 4: Gewähren ElastiCache Sie Lesezugriff auf die .rdb-Datei
Gewähren ElastiCache Sie jetzt Lesezugriff auf Ihre .rdb-Backup-Datei. Sie gewähren ElastiCache Zugriff auf Ihre Backup-Datei auf unterschiedliche Weise, je nachdem, ob sich Ihr Bucket in einer AWS Standardregion oder einer AWS Opt-in-Region befindet.
AWS Regionen, die vor dem 20. März 2019 eingeführt wurden, sind standardmäßig aktiviert. Sie können sofort mit der Arbeit in diesen AWS Regionen beginnen. Regionen, die nach dem 20. März 2019 eingeführt werden, wie Asien-Pazifik (Hongkong) und Naher Osten (Bahrain), sind standardmäßig deaktiviert. Sie müssen diese Regionen aktivieren oder sich dafür anmelden, bevor Sie sie verwenden können, wie unter [Verwalten von AWS-Regionen](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) im *Allgemeine AWS-Referenz* beschrieben.
Wählen Sie Ihren Ansatz je nach AWS Region:
+ Verwenden Sie für eine Standardregion das Verfahren unter [Gewähren ElastiCache Sie Lesezugriff auf die RDB-Datei in einer Standardregion](#backups-seeding-redis-default-region).
+ Verwenden Sie für eine Opt-In-Region das Verfahren unter [Gewähren ElastiCache Sie Lesezugriff auf die RDB-Datei in einer Opt-in-Region](#backups-seeding-opt-in-region).
### Gewähren ElastiCache Sie Lesezugriff auf die RDB-Datei in einer Standardregion
AWS Regionen, die vor dem 20. März 2019 eingeführt wurden, sind standardmäßig aktiviert. Sie können sofort mit der Arbeit in diesen AWS Regionen beginnen. Regionen, die nach dem 20. März 2019 eingeführt werden, wie Asien-Pazifik (Hongkong) und Naher Osten (Bahrain), sind standardmäßig deaktiviert. Sie müssen diese Regionen aktivieren oder sich dafür anmelden, bevor Sie sie verwenden können, wie unter [Verwalten von AWS-Regionen](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) im *Allgemeine AWS-Referenz* beschrieben.
**Um ElastiCache Lesezugriff auf die Backup-Datei in einer AWS Region zu gewähren, die standardmäßig aktiviert ist**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Wählen Sie den Namen des S3-Buckets aus, in dem sich Ihre .rdb-Datei befindet.
1. Wählen Sie den Namen des Ordners aus, in dem sich Ihre .rdb-Datei befindet.
1. Wählen Sie den Namen Ihrer .rdb-Sicherungsdatei aus. Der Name der ausgewählten Datei erscheint oberhalb der Registerkarten oben auf der Seite.
1. Wählen Sie **Berechtigungen**.
1. Wenn **aws-scs-s3-readonly** oder einer der kanonischen Benutzer IDs in der folgenden Liste nicht als Benutzer aufgeführt ist, gehen Sie wie folgt vor:
1. **Wählen **Sie unter Zugriff für andere AWS Konten** die Option Zuschussempfänger hinzufügen aus.**
1. Fügen Sie in dem Feld die kanonische ID der AWS Region wie folgt hinzu:
+ AWS GovCloud Region (USA West):
```
40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6
```
**Wichtig**
Das Backup muss sich in einem S3-Bucket befinden, damit Sie es auf einen Valkey- oder Redis-OSS-Cluster herunterladen können.AWS GovCloud (US)AWS GovCloud (US)
+ AWS Standardmäßig aktivierte Regionen:
```
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353
```
1. Richten Sie die Berechtigungen für den Bucket durch Auswahl von **Yes (Ja)** für die folgenden Optionen ein:
+ **List/write object** (Objekt auflisten/schreiben)
+ **Read/write·object·ACL·permissions** (Lese-/Schreibberechtigungen für Objekt-ACL)
1. Wählen Sie **Speichern**.
1. Wählen Sie **Overview (Übersicht)** und dann **Download (Herunterladen)**.
### Gewähren ElastiCache Sie Lesezugriff auf die RDB-Datei in einer Opt-in-Region
AWS Regionen, die vor dem 20. März 2019 eingeführt wurden, sind standardmäßig aktiviert. Sie können sofort mit der Arbeit in diesen AWS Regionen beginnen. Regionen, die nach dem 20. März 2019 eingeführt werden, wie Asien-Pazifik (Hongkong) und Naher Osten (Bahrain), sind standardmäßig deaktiviert. Sie müssen diese Regionen aktivieren oder sich dafür anmelden, bevor Sie sie verwenden können, wie unter [Verwalten von AWS-Regionen](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) im *Allgemeine AWS-Referenz* beschrieben.
Gewähren Sie jetzt ElastiCache Lesezugriff auf Ihre .rdb-Backup-Datei.
**Um ElastiCache Lesezugriff auf die Sicherungsdatei zu gewähren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Wählen Sie den Namen des S3-Buckets aus, in dem sich Ihre .rdb-Datei befindet.
1. Wählen Sie den Namen des Ordners aus, in dem sich Ihre .rdb-Datei befindet.
1. Wählen Sie den Namen Ihrer .rdb-Sicherungsdatei aus. Der Name der ausgewählten Datei erscheint oberhalb der Registerkarten oben auf der Seite.
1. Wählen Sie die Registerkarte **Berechtigungen**.
1. Wählen Sie unter **Permissions** (Berechtigungen) **Bucket policy** (Bucket-Richtlinie) aus und klicken Sie dann auf **Edit** (Bearbeiten).
1. Aktualisieren Sie die Richtlinie, um die ElastiCache erforderlichen Berechtigungen zur Durchführung von Vorgängen zu gewähren:
+ Fügen Sie `[ "Service" : "region-full-name.elasticache-snapshot.amazonaws.com" ]` zu `Principal` hinzu.
+ Fügen Sie die folgenden Berechtigungen hinzu, die für das Exportieren eines Snapshots in den Amazon-S3-Bucket erforderlich sind:
+ `"s3:GetObject"`
+ `"s3:ListBucket"`
+ `"s3:GetBucketAcl"`
Nachfolgend finden Sie ein Beispiel dafür, wie die aktualisierte Richtlinie aussehen könnte.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Policy15397346",
"Statement": [
{
"Sid": "Stmt15399483",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketAcl"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/backup1.rdb",
"arn:aws:s3:::amzn-s3-demo-bucket/backup2.rdb"
]
}
]
}
```
------
1. Wählen Sie **Änderungen speichern ** aus.
### Füllen Sie den ElastiCache Cluster mit den Daten der .rdb-Datei
Jetzt sind Sie bereit, einen ElastiCache Cluster zu erstellen und ihn mit den Daten aus der RDB-Datei zu versorgen. Folgen Sie zum Erstellen des Clusters den Anweisungen unter [Einen Cluster für Valkey oder Redis OSS erstellen](Clusters.Create.md) oder [Eine Valkey- oder Redis OSS-Replikationsgruppe von Grund auf neu erstellen](Replication.CreatingReplGroup.NoExistingCluster.md). Achten Sie darauf, Valkey oder Redis OSS als Cluster-Engine zu wählen.
Die Methode, mit der Sie angeben, ElastiCache wo sich das Backup befindet, das Sie auf Amazon S3 hochgeladen haben, hängt von der Methode ab, mit der Sie den Cluster erstellt haben:
**Füllen Sie den OSS-Cluster oder die Replikationsgruppe ElastiCache für Redis mit den Daten der .rdb-Datei**
+ **Verwenden der Konsole ElastiCache **
Wählen Sie bei der Auswahl der **Cluster settings** (Cluster-Einstellungen) die Option **Restore from backups** (Aus Backups wiederherstellen) als Methode zur Cluster-Erstellung aus, und wählen Sie dann im Abschnitt **Backup source** (Backup-Quelle) die Option **Other backups** (Andere Backups) als **Source** (Quelle) aus. Geben Sie im Feld **Seed-RDB-Datei-S3-Speicherort** den Amazon-S3-Pfad für die Datei(en) ein. Wenn Sie mehrere .rdb-Dateien besitzen, geben Sie den Pfad für jede Datei in eine durch Kommas getrennten Liste ein. Der Amazon-S3-Pfad sieht etwa aus wie `myBucket/myFolder/myBackupFilename.rdb`.
+ **Mit dem AWS CLI**
Verwenden Sie bei Einsatz der Operation `create-cache-cluster` oder `create-replication-group` den Parameter `--snapshot-arns`, um einen vollqualifizierten ARN für jede .rdb-Datei anzugeben. Beispiel, `arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb`. Der ARN muss auf die in Amazon S3 gespeicherten Sicherungsdateien aufgelöst werden.
+ **Mithilfe der ElastiCache API**
Wenn Sie die `CreateReplicationGroup` ElastiCache API-Operation `CreateCacheCluster` oder verwenden, verwenden Sie den Parameter, `SnapshotArns` um einen vollqualifizierten ARN für jede .rdb-Datei anzugeben. Beispiel, `arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb`. Der ARN muss auf die in Amazon S3 gespeicherten Sicherungsdateien aufgelöst werden.
**Wichtig**
Beim Seeding eines Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert) müssen Sie jede Knotengruppe (Shard) im neuen Cluster oder in der neuen Replikationsgruppe konfigurieren. Dazu verwenden Sie den Parameter `--node-group-configuration` (API: `NodeGroupConfiguration`). Weitere Informationen finden Sie hier:
CLI: [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)in der AWS CLI Referenz
API: [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)in der ElastiCache API-Referenz
Während der Erstellung Ihres Clusters werden die Daten in Ihrem Valkey- oder Redis OSS-Backup in den Cluster geschrieben. Sie können den Fortschritt überwachen, indem Sie sich die ElastiCache Ereignismeldungen ansehen. Rufen Sie dazu die ElastiCache Konsole auf und wählen Sie **Cache Events** aus. Sie können auch die AWS ElastiCache Befehlszeilenschnittstelle oder ElastiCache API verwenden, um Ereignismeldungen abzurufen. Weitere Informationen finden Sie unter [ElastiCache Ereignisse anzeigen](ECEvents.Viewing.md).
# Motorversionen und Aufrüstung in ElastiCache
In diesem Abschnitt werden die unterstützten Valkey-, Memcached- und Redis OSS-Engines sowie Informationen zum Upgrade behandelt. Beachten Sie, dass alle mit Redis OSS 7.2 verfügbaren Funktionen standardmäßig in Valkey 7.2 und höher verfügbar sind. Sie können auch ein Upgrade von einigen vorhandenen ElastiCache für Redis OSS-Engines auf eine Valkey-Engine durchführen.
# Aufrüstung von Motorversionen, einschließlich motorübergreifender Upgrades
**Valkey und Redis OSS**
Mit Valkey und Redis OSS initiieren Sie Versionsupgrades für Ihren Cluster oder Ihre Replikationsgruppe, indem Sie ihn mithilfe der ElastiCache Konsole, der oder der AWS CLI ElastiCache API ändern und eine neuere Engine-Version angeben.
Sie können auch ein Cross-Upgrade von Redis OSS auf Valkey durchführen. Weitere Informationen zu Cross-Upgrades finden Sie unter. [Wie führe ich ein Upgrade von Redis OSS auf Valkey durch](#VersionManagement.HowTo.cross-engine-upgrade)
**Topics**
+ [Wie führe ich ein Upgrade von Redis OSS auf Valkey durch](#VersionManagement.HowTo.cross-engine-upgrade)
+ [Blockierte Valkey- oder Redis OSS-Engine-Upgrades lösen](#resolving-blocked-engine-upgrades)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Memcached**
Um mit Memcached Versionsupgrades für Ihren Cluster zu starten, ändern Sie ihn und geben eine neuere Engine-Version an. Sie können dies tun, indem Sie die ElastiCache Konsole AWS CLI, die oder die ElastiCache API verwenden:
+ Informationen zur Verwendung von AWS-Managementkonsole finden Sie unter —[Unter Verwendung der ElastiCache AWS-Managementkonsole](Clusters.Modify.md#Clusters.Modify.CON).
+ Informationen zur Verwendung von AWS CLI finden Sie unter[Verwenden Sie das mit AWS CLI ElastiCache](Clusters.Modify.md#Clusters.Modify.CLI).
+ Informationen zur Verwendung der ElastiCache API finden Sie unter[Verwenden der ElastiCache API](Clusters.Modify.md#Clusters.Modify.API).
## Wie führe ich ein Upgrade von Redis OSS auf Valkey durch
Valkey ist als Drop-In-Ersatz für Redis OSS 7 konzipiert. Sie können mithilfe der Konsole, API oder CLI ein Upgrade von Redis OSS auf Valkey durchführen, indem Sie die neue Engine und die Hauptversion der Engine angeben. Die IP-Adresse des Endpunkts und alle anderen Aspekte der Anwendung werden durch das Upgrade nicht geändert. Beim Upgrade von Redis OSS 5.0.6 und höher treten keine Ausfallzeiten auf.
**Anmerkung**
**AWS Anforderungen an die CLI-Version für Upgrades von Redis OSS auf Valkey:**
Für AWS CLI v1: Erforderliche Mindestversion 1.35.2 (Aktuelle Version: 1.40.22)
Für AWS CLI v2: Mindestens erforderliche Version 2.18.2 (Aktuelle Version: 2.27.22)
**Anmerkung**
Bei einem Upgrade von früheren Redis OSS-Versionen als 5.0.6 kann es während der DNS-Propagierung zu einer Failover-Zeit von 30 bis 60 Sekunden kommen.
Gehen Sie zunächst wie folgt vor, um einen vorhandenen Redis OSS-Single-Node-Cluster (Cluster-Modus deaktiviert) auf die Valkey-Engine zu aktualisieren:. [Erstellen einer Replikationsgruppe unter Verwendung eines vorhandenen Clusters](Replication.CreatingReplGroup.ExistingCluster.md) Sobald der Redis OSS-Cluster (Cluster-Modus deaktiviert) mit einem Knoten zu einer Replikationsgruppe hinzugefügt wurde, können Sie ein Engine-übergreifendes Upgrade auf Valkey durchführen.
### Upgrade einer Replikationsgruppe von Redis OSS auf Valkey
Wenn Sie über eine bestehende Redis OSS-Replikationsgruppe verfügen, die die Standard-Cache-Parametergruppe verwendet, können Sie ein Upgrade auf Valkey durchführen, indem Sie die neue Engine und die Engine-Version mit der API angeben. modify-replication-group
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0
```
Für Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0
```
Wenn Sie eine benutzerdefinierte Cache-Parametergruppe auf die bestehende Redis OSS-Replikationsgruppe angewendet haben, die Sie aktualisieren möchten, müssen Sie in der Anfrage auch eine benutzerdefinierte Valkey-Cache-Parametergruppe übergeben. Die benutzerdefinierte Valkey-Eingabeparametergruppe muss dieselben statischen Redis OSS-Parameterwerte haben wie die vorhandene benutzerdefinierte Redis OSS-Parametergruppe.
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0 \
--cache-parameter-group-name myParamGroup
```
Für Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0 ^
--cache-parameter-group-name myParamGroup
```
### Aktualisieren eines serverlosen Redis OSS-Caches auf Valkey mit der CLI
Für Linux, macOS oder Unix:
```
aws elasticache modify-serverless-cache \
--serverless-cache-name myCluster \
--engine valkey \
--major-engine-version 8
```
Für Windows:
```
aws elasticache modify-serverless-cache ^
--serverless-cache-name myCluster ^
--engine valkey ^
--major-engine-version 8
```
### Redis OSS mit der Konsole auf Valkey aktualisieren
**Upgrade von Redis OSS 5 auf Valkey**
1. Wählen Sie den Redis OSS-Cache für das Upgrade aus.
1. Ein Fenster „**Upgrade to Valkey**“ sollte angezeigt werden. Wählen Sie die **Schaltfläche Auf Valkey aktualisieren**.
1. Gehen Sie zu den **Cache-Einstellungen** und wählen Sie dann **Engine-Version** aus. Die neueste Version von Valkey wird empfohlen.
1. Wenn dieser Cache serverlos ist, müssen Sie die Parametergruppe aktualisieren. Gehen Sie in den **Cache-Einstellungen** zum Bereich **Parametergruppen** und wählen Sie eine entsprechende Parametergruppe aus, z. B. *default.valkey8*.
1. **Wählen Sie Upgrade aus.**
Dieser Cache wird nun im Valkey-Bereich der Konsole aufgeführt.
**Anmerkung**
Ein direktes Upgrade von Redis OSS 4 oder niedriger auf Valkey kann eine längere Failover-Zeit von 30 bis 60 Sekunden während der DNS-Propagierung beinhalten.
### Wie führe ich ein Downgrade von Valkey auf Redis OSS durch
Wenn Sie aus irgendeinem Grund Ihren aktualisierten Cluster zurücksetzen möchten, ElastiCache unterstützt Amazon das Rollback eines Valkey 7.2-Caches auf Redis OSS 7.1. Sie können ein Rollback mit denselben Konsolen-, API- oder CLI-Schritten wie bei einem Engine-Upgrade durchführen und Redis OSS 7.1 als Ziel-Engine-Version angeben. Rollbacks verwenden dieselben Prozesse wie ein Upgrade. Die IP-Adresse des Endpunkts und alle anderen Aspekte der Anwendung werden durch das Rollback nicht geändert, und es treten keine Ausfallzeiten auf.
Darüber hinaus können Sie einen aus Ihrem Valkey 7.2-Cache erstellten Snapshot als Redis OSS 7.1-Cache wiederherstellen. Wenn Sie aus einem Snapshot wiederherstellen, können Sie Redis OSS 7.1 als Ziel-Engine-Version angeben. Wenn Sie diese Option verwenden, wird aus dem Snapshot ein neuer Cache erstellt. Die Wiederherstellung aus einem Snapshot hat keine Auswirkung auf den Valkey-Cache, aus dem der Snapshot erstellt wurde.
Bei der Durchführung eines Rollbacks gelten die folgenden Anforderungen und Einschränkungen:
+ ElastiCache unterstützt nur das Rollback von Valkey 7.2 auf Redis OSS 7.1. Dies gilt auch dann, wenn Sie von einer früheren Version als Redis OSS 7.1 auf Valkey 7.2 aktualisiert haben.
+ Jede Benutzergruppe und jeder Benutzer, die der Replikationsgruppe oder dem serverlosen Cache zugeordnet sind, für den ein Rollback ausgeführt wird, müssen mit dem Engine-Typ konfiguriert werden. `REDIS`
## Blockierte Valkey- oder Redis OSS-Engine-Upgrades lösen
Wie in der folgenden Tabelle dargestellt, ist Ihr Valkey- oder Redis OSS-Engine-Upgrade-Vorgang blockiert, wenn ein Scale-Up-Vorgang aussteht.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Um ein blockiertes Valkey- oder Redis OSS-Engine-Upgrade zu beheben**
+ Führen Sie eine der folgenden Aktionen aus:
+ Planen Sie Ihren Redis OSS- oder Valkey-Engine-Upgrade-Vorgang für das nächste Wartungsfenster, indem **Sie das Kontrollkästchen Sofort anwenden** deaktivieren.
Mit der CLI verwenden Sie `--no-apply-immediately`. Mit der API verwenden Sie `ApplyImmediately=false`.
+ Warten Sie bis zum nächsten Wartungsfenster (oder danach), um Ihr Redis OSS-Engine-Upgrade durchzuführen.
+ Fügen Sie dieser Cluster-Änderung den Redis OSS-Scale-Up-Vorgang hinzu, indem Sie das Kontrollkästchen **Sofort anwenden** aktivieren.
Mit der CLI verwenden Sie `--apply-immediately`. Mit der API verwenden Sie `ApplyImmediately=true`.
Dieser Ansatz bricht das Engine-Upgrade während des nächsten Wartungsfensters effektiv ab, indem es direkt ausgeführt wird.
# ElastiCache Erweiterter Support
Mit ElastiCache Extended Support können Sie Ihren Cache gegen Aufpreis auch nach Ablauf des Standard-Supportdatums auf einer Hauptversion der Engine weiter ausführen. Wenn Sie nach Ablauf des Standard-Supportdatums kein Upgrade durchführen, wird Ihnen eine Gebühr berechnet.
Extended Support bietet die folgenden Updates und technischen Support:
+ Sicherheitsupdates für kritische und hohe Sicherheitsaktualisierungen CVEs für Ihren Cache und Ihre Cache-Engine
+ Bugfixes und Patches für kritische Probleme
+ Die Möglichkeit, im Rahmen des standardmäßigen ElastiCache Service Level Agreements Supportanfragen zu eröffnen und Hilfe bei der Fehlerbehebung zu erhalten
Dieses kostenpflichtige Angebot gibt Ihnen mehr Zeit für ein Upgrade auf eine unterstützte Hauptversion der Engine.
Beispielsweise ElastiCache endet der Standardsupport für Redis OSS 4.0.10 am 31. Januar 2026. Wenn Sie bis zu diesem Datum nicht bereit sind, manuell auf Valkey oder auf Redis OSS 6 oder höher zu aktualisieren, ElastiCache werden Ihre Caches automatisch für Extended Support registriert und Sie können Redis OSS 4.0.10 weiterhin ausführen. Ab dem ersten Tag des Monats nach Ablauf des Standard-Supports, dem 1. Februar 2026, ElastiCache wird Ihnen automatisch der erweiterte Support in Rechnung gestellt.
Extended Support ist bis zu 3 Jahre nach Ablauf des Standard-Supportdatums für eine Hauptversion der Engine verfügbar. Für die OSS-Versionen 4 und 5 von Elasticache für Redis ist das der 31. Januar 2029. Nach diesem Datum werden alle Caches, auf denen die Redis OSS-Versionen 4 und 5 noch ausgeführt werden, automatisch auf die neueste Version von Valkey aktualisiert.
Sobald der Supportzeitraum einer Engine endet, werden Caches, auf denen die alte Version weiterhin ausgeführt wird, automatisch auf Extended Support umgestellt. Sie werden vor dem Startdatum der Preise für den erweiterten Support benachrichtigt, sodass Sie stattdessen ein Upgrade Ihrer Instance durchführen können. Sie können sich auch jederzeit ausdrücklich abmelden, indem Sie ein Upgrade auf unterstützte Versionen durchführen.
Weitere Informationen zum Ende der Standard-Supportdaten und zum Ende der Extended Support-Daten finden Sie unter [ElastiCache Zeitplan für das Ende der Lebensdauer von Versionen für Redis OSS](engine-versions.md#deprecated-engine-versions) für Valkey, Memcached oder Redis OSS.
**Topics**
+ [ElastiCache Gebühren für erweiterten Support](extended-support-charges.md)
+ [Versionen mit ElastiCache erweitertem Support](extended-support-versions.md)
+ [ElastiCache und Kundenverantwortung mit ElastiCache Extended Support](extended-support-responsibilities.md)
# ElastiCache Gebühren für erweiterten Support
Ab dem Tag nach dem Ende des Standardsupports fallen Gebühren für alle Engines an, die für den ElastiCache erweiterten Support registriert sind. Informationen zum ElastiCache Ende des Standard-Supports finden Sie unter. [Versionen mit ElastiCache erweitertem Support](extended-support-versions.md)
Die zusätzliche Gebühr für den ElastiCache erweiterten Support endet automatisch, wenn Sie eine der folgenden Maßnahmen ergreifen:
+ Führen Sie ein Upgrade auf eine Engine-Version durch, für die der Standardsupport gilt.
+ Löschen Sie den Cache, auf dem eine Hauptversion nach ElastiCache Ablauf des Standard-Supportdatums ausgeführt wird.
Die Gebühren werden wieder aufgenommen, wenn Ihre Ziel-Engine-Version in future in den erweiterten Support aufgenommen wird.
Nehmen wir zum Beispiel an, dass ElastiCache Version 4 für Redis OSS am 1. Februar 2026 in den erweiterten Support aufgenommen wird und Sie Ihre Caches von v4 am 1. Januar 2027 auf v6 aktualisieren. Bei ElastiCache Version 4 für Redis OSS werden Ihnen nur 11 Monate Extended Support in Rechnung gestellt. Wenn Sie ElastiCache Version 6 für Redis OSS nach dem Ende des Standard-Supports am 31. Januar 2027 weiter ausführen, fallen für diese Caches ab dem 1. Februar 2027 erneut Gebühren für den erweiterten Support an.
Sie können vermeiden, dass ElastiCacheExtended Support in Rechnung gestellt wird, indem Sie ElastiCache verhindern, dass nach ElastiCache Ablauf des Standard-Supportdatums ein Cache erstellt oder wiederhergestellt wird.
Weitere Informationen finden Sie unter [ ElastiCache Amazon-Preise](https://aws.amazon.com/elasticache/pricing/).
# Versionen mit ElastiCache erweitertem Support
Die Versionen 4 und 5 von Redis Open Source Software (OSS) erreichten 2020 bzw. 2022 das Ende der Nutzungsdauer ihrer Community. Dies bedeutet, dass keine weiteren Updates, Bugfixes oder Sicherheitspatches von der Community veröffentlicht werden. Der Standardsupport für die ElastiCache Redis OSS-Versionen 4 und 5 ElastiCache endet am 31. Januar 2026. Wenn Sie weiterhin nicht unterstützte Versionen von Redis OSS verwenden, könnten Ihre Daten anfällig für [bekannte Sicherheitslücken und Sicherheitslücken](https://nvd.nist.gov/vuln-metrics/cvss) () werden. CVEs
Ab dem 1. Februar 2026 werden ElastiCache Caches, die noch auf den Redis OSS-Versionen 4 und 5 laufen, automatisch für Extended Support registriert, um kontinuierliche Verfügbarkeit und Sicherheit zu gewährleisten. Extended Support bietet zwar Flexibilität, wir empfehlen jedoch, das Ende des Standard-Supports als Planungsmeilenstein für Ihre Produktionsworkloads zu betrachten. Wir empfehlen Ihnen dringend, Ihre Redis OSS v4- und v5-Caches vor dem Ende des ElastiCache Standardsupports auf Valkey oder Redis OSS v6 oder höher zu aktualisieren.
In der folgenden Tabelle sind das Datum für das ElastiCache Ende des Standard-Supports und das Datum des erweiterten Supports von Amazon zusammengefasst.
**Erweiterter Support und Zeitplan für das Ende der Nutzungsdauer**
| Hauptversion der Engine | Ende des Standard-Supports | Beginn des erweiterten Support Y1 Premium | Beginn des erweiterten Support Y2 Premium | Beginn des erweiterten Support Y3 Premium | Ende des erweiterten Support und Versions-EOL |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 31.1.2026 | 1.2.2026 | 1.2.2027 | 1.2.2028 | 31.1.2029 |
| Redis OSS v5 | 31.1.2026 | 1.2.2026 | 1.2.2027 | 1.2.2028 | 31.1.2029 |
| Redis OSS v6 | 31.1.2027 | 1.2.2027 | 1.2.2028 | 1.2.2029 | 31.1.2030 |
Erweiterter Support wird nur für die neueste unterstützte Patch-Version jeder Hauptversion von Redis OSS angeboten. Wenn der erweiterte Support am 1. Februar 2026 beginnt und Ihre Redis OSS v4- und v5-Cluster noch nicht auf den neuesten Patch-Versionen installiert sind, werden sie automatisch auf v4.0.10 für Redis OSS v4 und v5.0.6 für Redis OSS v5 aktualisiert, bevor sie für Extended Support registriert werden. Dadurch wird sichergestellt, dass Sie Sicherheitsupdates und Bugfixes über den erweiterten Support erhalten. Sie müssen keine Maßnahmen ergreifen, um im Rahmen der Umstellung auf den erweiterten Support ein Upgrade auf diese neuesten Patch-Versionen durchzuführen.
# ElastiCache und Kundenverantwortung mit ElastiCache Extended Support
Im Folgenden sind die Aufgaben von Amazon ElastiCache und Ihre Verantwortlichkeiten mit ElastiCache Extended Support aufgeführt.
** ElastiCache Verantwortlichkeiten von Amazon**
Nach ElastiCache Ablauf des Standard-Supportdatums ElastiCache stellt Amazon Patches, Bugfixes und Upgrades für Engines bereit, die für den ElastiCache erweiterten Support registriert sind. Dies gilt für bis zu 3 Jahre oder bis Sie die Engines im Extended Support nicht mehr verwenden, je nachdem, was zuerst eintritt.
**Ihre Aufgaben**
Sie sind dafür verantwortlich, die Patches, Bugfixes und Upgrades zu installieren, die für Caches im ElastiCache Extended Support bereitgestellt werden. Amazon ElastiCache behält sich das Recht vor, solche Patches, Bugfixes und Upgrades jederzeit zu ändern, zu ersetzen oder zurückzuziehen. Wenn ein Patch erforderlich ist, um Sicherheits- oder kritische Stabilitätsprobleme zu beheben, ElastiCache behält sich Amazon das Recht vor, Ihre Caches mit dem Patch zu aktualisieren oder zu verlangen, dass Sie den Patch installieren.
Sie sind auch dafür verantwortlich, Ihre Engine vor ElastiCache Ablauf des Extended Support-Datums auf eine neuere Engine-Version zu aktualisieren. Das ElastiCache Ende des erweiterten Support liegt in der Regel 3 Jahre nach dem ElastiCache Ende des Standard-Supportdatums.
Wenn Sie Ihren Motor nicht aufrüsten, versucht Amazon ElastiCache nach ElastiCache Ablauf des Extended Support-Datums, Ihren Motor auf eine neuere Engine-Version aufzurüsten, die im Rahmen des ElastiCache Standardsupports unterstützt wird. Wenn das Upgrade fehlschlägt, ElastiCache behält sich Amazon das Recht vor, den Cache zu löschen, in dem die Engine nach ElastiCache Ablauf des Standard-Supportdatums läuft. Vorher bewahrt Amazon ElastiCache jedoch Ihre Daten aus dieser Engine auf.
# Versionsverwaltung für ElastiCache
Sie können festlegen, wie Sie Ihre ElastiCache Caches und knotenbasierten Cluster aktualisieren möchten, die für die Valkey-, Memcached- und Redis OSS-Engines aktualisiert wurden.
## ElastiCache Versionsverwaltung für Serverless Cache
Verwalten Sie, ob und wann der ElastiCache Serverless Cache aktualisiert wird, und führen Sie Versionsupgrades zu Ihren eigenen Bedingungen und Zeitplänen durch.
ElastiCache Serverless wendet automatisch die neueste Minor- und Patch-Softwareversion auf Ihren Cache an, ohne dass dies Auswirkungen oder Ausfallzeiten auf Ihre Anwendung hat. Von Ihrer Seite aus ist keine Aktion erforderlich.
Wenn eine neue Hauptversion verfügbar ist, sendet Ihnen ElastiCache Serverless eine Benachrichtigung in der Konsole und ein Ereignis in. EventBridge Sie können Ihren Cache auf die neueste Hauptversion aktualisieren, indem Sie ihn mithilfe der Konsole, CLI oder API ändern und die neueste Engine-Version auswählen. Ähnlich wie bei kleineren Upgrades und Patch-Upgrades werden Hauptversions-Upgrades ohne Ausfallzeiten Ihrer Anwendung durchgeführt.
## Versionsverwaltung für knotenbasierte Cluster ElastiCache
Wenn Sie mit knotenbasierten ElastiCache Clustern arbeiten, können Sie steuern, wann die Software, die Ihren Cluster unterstützt, auf neue Versionen aktualisiert wird, die von unterstützt werden. ElastiCache Sie können steuern, wann Ihr Cache auf die neuesten verfügbaren Haupt-, Neben- und Patch-Versionen aktualisiert werden soll. Sie starten Engine-Versions-Upgrades für Ihren Cluster oder Ihre Replikationsgruppe, indem Sie ihn bzw. sie ändern und eine neue Engine-Version angeben.
Sie können steuern, ob und wann die protokollkonforme Software, die Ihren Cluster unterstützt, auf neue Versionen aktualisiert wird, die von unterstützt werden. ElastiCache Mit diesem Maß an Kontrolle können Sie die Kompatibilität mit bestimmten Versionen aufrechterhalten, neue Versionen mit Ihrer Anwendung testen, bevor Sie sie für die Produktion bereitstellen, und Versions-Upgrades nach Ihren eigenen Vorgaben und Zeitplänen durchführen lassen.
Da Versions-Upgrades ggf. mit Kompatibilitätsrisiken verbunden sind, können sie nicht automatisch eingestellt werden. Sie müssen von Ihnen selbst installiert werden.
**Valkey- und Redis OSS-Cluster**
**Anmerkung**
Wenn ein Valkey- oder Redis OSS-Cluster in einer oder mehreren Regionen repliziert wird, wird die Engine-Version für sekundäre Regionen und dann für die primäre Region aktualisiert.
ElastiCache für Redis werden OSS-Versionen mit einer semantischen Version identifiziert, die eine Haupt- und eine Nebenkomponente umfasst. In Redis OSS 6.2 ist die Hauptversion beispielsweise 6 und die Nebenversion 2. Beim Betrieb knotenbasierter Cluster wird ElastiCache für Redis OSS auch die Patch-Komponente verfügbar gemacht, z. B. Redis OSS 6.2.1, und die Patch-Version ist 1.
Hauptversionen sind für API-inkompatible Änderungen und Nebenversionen für neue Funktionen vorgesehen, die abwärtskompatibel hinzugefügt wurden. Patch-Versionen sind für abwärtskompatible Bugfixes und nicht funktionale Änderungen vorgesehen.
Mit Valkey und Redis OSS initiieren Sie Engine-Versions-Upgrades für Ihren Cluster oder Ihre Replikationsgruppe, indem Sie ihn ändern und eine neue Engine-Version angeben. Weitere Informationen finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
**Memcached**
Bei Memcached müssen Sie für ein Upgrade auf eine neuere Version Ihren Cluster ändern und die neue Engine-Version angeben, die Sie verwenden möchten. Das Upgrade auf eine neuere Memcached-Version ist ein destruktiver Prozess – Sie verlieren Ihre Daten und beginnen mit einem kalten Cache. Weitere Informationen finden Sie unter [Einen ElastiCache Cluster ändern](Clusters.Modify.md).
Beim Upgraden einer älteren Memcached-Version auf Memcached Version 1.4.33 oder höher sind folgende Anforderungen zu beachten. `CreateCacheCluster` und `ModifyCacheCluster` schlagen unter den folgenden Bedingungen fehl:
+ Wenn `slab_chunk_max > max_item_size`.
+ Wenn `max_item_size modulo slab_chunk_max != 0`.
+ Wenn `max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4)`.
Der Wert `(max_cache_memory - memcached_connections_overhead)` ist der für Daten nutzbare Speicher des Knotens. Weitere Informationen finden Sie unter [Overhead von Memcached-Verbindungen](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead).
## Unterstützte Engines und Versionen
ElastiCache Serverlose Caches unterstützen ElastiCache Version 7.2 für Valkey und höher, ElastiCache Version 1.6 für Memcached und höher und ElastiCache 7.0 für Redis OSS und höher.
Knotenbasierte ElastiCache Cluster unterstützen ElastiCache Version 7.2 für Valkey und höher, ElastiCache Version 1.4.5 für Memcached und höher und 4.0.10 für Redis OSS und höher. ElastiCache
**Topics**
+ [Unterstützte Valkey-Versionen](#supported-engine-versions.valkey)
+ [Valkey 8.2](#valkey-version-8.2)
+ [Valkey 8.1](#valkey-version-8.1)
+ [Valkey 8.0](#valkey-version-8)
+ [ElastiCache Version 7.2.6 für Valkey](#valkey-version-7.2.6)
### Unterstützte Valkey-Versionen
Nachfolgend finden Sie die unterstützten Valkey-Versionen. Beachten Sie, dass Valkey standardmäßig die meisten Funktionen unterstützt, die in ElastiCache Version 7.2 für Redis OSS verfügbar sind.
+ Sie können Ihre ElastiCache Cluster auch mit Versionen vor 5.0.6 aktualisieren. Der Prozess ist identisch, kann jedoch längere Failover-Zeit während der DNS-Ausbreitung (30 Sek. - 1 Min.) verursachen.
+ Ab Redis OSS 7 wird ElastiCache das Umschalten zwischen Valkey oder Redis OSS (Clustermodus deaktiviert) und Valkey oder Redis OSS (Clustermodus aktiviert) unterstützt.
+ Der Upgrade-Prozess ElastiCache für die Amazon for Redis OSS-Engine ist darauf ausgelegt, Ihre vorhandenen Daten bestmöglich beizubehalten, und erfordert eine erfolgreiche Redis OSS-Replikation.
+ Beim Upgrade der Engine ElastiCache werden bestehende Client-Verbindungen beendet. [Um Ausfallzeiten bei Engine-Upgrades zu minimieren, empfehlen wir Ihnen, [bewährte Methoden für Redis OSS-Clients](BestPractices.Clients.redis.md) mit Fehlerwiederholungen und exponentiellem Backoff sowie bewährte Methoden zur Minimierung von Ausfallzeiten während der Wartung zu implementieren.](BestPractices.MinimizeDowntime.md)
+ Sie können beim Upgrade Ihrer Engine kein direktes Upgrade von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis OSS (Clustermodus aktiviert) durchführen. Das folgende Verfahren zeigt Ihnen, wie Sie von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis OSS (Clustermodus aktiviert) aktualisieren.
**Um ein Upgrade von einer Valkey- oder Redis OSS-Engine-Version (Cluster-Modus deaktiviert) auf eine Valkey- oder Redis OSS-Engine-Version (Clustermodus aktiviert) durchzuführen**
1. Erstellen Sie eine Sicherungskopie Ihres Valkey- oder Redis OSS-Clusters oder Ihrer Replikationsgruppe (Clustermodus deaktiviert). Weitere Informationen finden Sie unter [Erstellen manueller Backups](backups-manual.md).
1. Verwenden Sie das Backup, um einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mit einem Shard (Knotengruppe) zu erstellen und zu starten. Geben Sie die neue Engine-Version an und aktivieren Sie den Cluster-Modus, wenn Sie den Cluster oder die Replikationsgruppe erstellen. Weitere Informationen finden Sie unter [Tutorial: Seeding eines neuen knotenbasierten Clusters mit einem extern erstellten Backup](backups-seeding-redis.md).
1. Löschen Sie den alten Valkey- oder Redis OSS-Cluster oder die alte Replikationsgruppe (Clustermodus deaktiviert). Für weitere Informationen siehe [Löschen eines Clusters in ElastiCache](Clusters.Delete.md) oder [Löschen einer Replikationsgruppe](Replication.DeletingRepGroup.md).
1. Skalieren Sie den neuen Valkey- oder Redis OSS-Cluster oder die neue Replikationsgruppe (Clustermodus aktiviert) auf die Anzahl der Shards (Knotengruppen), die Sie benötigen. Weitere Informationen finden Sie unter [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md).
+ Beim Upgrade von Hauptversionen der Engine, beispielsweise von 5.0.6 auf 6.0, müssen Sie auch eine neue Parametergruppe auswählen, die mit der neuen Engine-Version kompatibel ist.
+ Für einzelne Redis OSS-Cluster und Cluster mit deaktiviertem Multi-AZ empfehlen wir, Redis OSS ausreichend Speicher zur Verfügung zu stellen, wie unter beschrieben. [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md) In diesen Fällen steht der primäre Knoten während des Upgrade-Prozesses für Serviceanfragen nicht zur Verfügung.
+ Für Redis OSS-Cluster mit aktiviertem Multi-AZ empfehlen wir außerdem, Engine-Upgrades in Zeiten mit geringem eingehendem Schreibverkehr zu planen. Bei einem Upgrade auf Redis OSS 5.0.6 oder höher steht der primäre Cluster während des Upgrade-Vorgangs weiterhin für Serviceanfragen zur Verfügung.
Cluster und Replikationsgruppen mit mehreren Shards werden wie folgt verarbeitet und gepatcht:
+ Alle Shards werden parallel verarbeitet. Es wird jeweils nur eine Upgrade-Operation für einen Shard gleichzeitig durchgeführt.
+ In jedem Shard werden alle Replicas verarbeitet, bevor der Primärknoten verarbeitet wird. Wenn es in einem Shard weniger Replicas gibt, kann der Primärknoten in diesem Shard verarbeitet werden, bevor die Verarbeitung der Replicas in anderen Shards abgeschlossen wird.
+ Die Primärknoten für alle Shards werden seriell verarbeitet. Es erfolgt jeweils nur ein Upgrade für einen Primärknoten gleichzeitig.
+ Wenn die Verschlüsselung in Ihrem aktuellen Cluster oder Ihrer Replikationsgruppe aktiviert ist, können Sie nicht auf eine Engine-Version aktualisieren, die keine Verschlüsselung unterstützt, z. B. von 3.2.6 auf 3.2.10.
**Überlegungen zu Memcached**
Beachten Sie beim Upgrade eines knotenbasierten Memcached-Clusters Folgendes.
+ Versionsverwaltung der Enginge ist so entwickelt, dass Sie so viel Kontrolle wie möglich darüber haben, wie Patchen erfolgt. Behält sich jedoch ElastiCache das Recht vor, Ihren Cluster in Ihrem Namen zu patchen, sollte der unwahrscheinliche Fall eintreten, dass das System oder die Cache-Software eine kritische Sicherheitslücke aufweist.
+ Da die Memcached-Engine keine Persistenz unterstützt, stellen Versions-Upgrades der Memcached-Engine immer einen Störfall dar, bei dem alle Cache-Daten im Cluster gelöscht werden.
### ElastiCache Version 8.2 für Valkey
Hier sind einige der neuen Funktionen, die in Valkey 8.2 eingeführt wurden (im Vergleich zu ElastiCache Valkey 8.1):
+ Native Unterstützung für [Vector Search](vector-search.md), mit der Sie Milliarden von hochdimensionalen Vektoreinbettungen im Speicher speichern, indexieren, suchen und aktualisieren können, mit Latenzen von nur Mikrosekunden.
[Weitere Informationen zu Valkey finden Sie unter Valkey.](https://valkey.io/)
[Weitere Informationen zur Version Valkey 8.2, in der die Vektorsuche eingeführt wird, finden Sie unter Valkey Search.](https://github.com/valkey-io/valkey-search)
### ElastiCache Version 8.1 für Valkey
Hier sind einige der neuen Funktionen, die in Valkey 8.1 eingeführt wurden (im Vergleich zu ElastiCache Valkey 8.0):
+ Eine [neue Hash-Tabellenimplementierung](https://valkey.io/blog/new-hash-table/), die den Speicheraufwand reduziert, um den Speicherverbrauch für gängige key/value Muster um bis zu 20% zu senken.
+ Native Unterstützung für [Bloom-Filter](https://valkey.io/topics/bloomfilters/), einen neuen Datentyp, mit dem Sie Suchvorgänge mit bis zu 98% weniger Speicher durchführen können als mit dem Set-Datentyp.
+ Neuer Befehl [COMMANDLOG](https://valkey.io/commands/commandlog-get/), der langsame Ausführungen, umfangreiche Anfragen und umfangreiche Antworten aufzeichnet.
+ Neue Unterstützung für bedingte Updates des SET-Befehls mithilfe des IFEQ-Arguments.
+ Leistungsverbesserungen, darunter eine um bis zu 45% geringere Latenz für den Befehl ZRANK, eine bis zu 12-mal schnellere Leistung für PFMERGE und PFCOUNT und ein um bis zu 514% höherer Durchsatz für BITCOUNT.
[Weitere Informationen zu Valkey finden Sie unter Valkey](https://valkey.io/)
Weitere Informationen zur Version Valkey 8.1 finden Sie in den Versionshinweisen zu [Valkey](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES) 8.1
### ElastiCache Version 8.0 für Valkey
Hier sind einige der neuen Funktionen, die in Valkey 8.0 eingeführt wurden (im Vergleich zu ElastiCache Valkey 7.2.6):
+ Verbesserungen der Speichereffizienz, sodass Benutzer bis zu 20% mehr Daten pro Knoten speichern können, ohne dass Änderungen an der Anwendung vorgenommen werden müssen.
+ Neu eingeführte Metrikinfrastruktur pro Steckplatz für knotenbasierte Cluster, die detaillierte Einblicke in die Leistung und den Ressourcenverbrauch einzelner Steckplätze bietet.
+ ElastiCache Serverless for Valkey 8.0 kann die Anzahl der unterstützten Anfragen pro Sekunde (RPS) alle 2 bis 3 Minuten verdoppeln, sodass 5 Millionen RPS pro Cache in weniger als 13 Minuten von Null erreicht werden, und das bei gleichbleibender p50-Leselatenz von unter einer Millisekunde.
[Weitere Informationen zu Valkey finden Sie unter Valkey](https://valkey.io/)
Weitere Informationen zur Valkey 8-Version finden Sie in den Versionshinweisen zu [Valkey](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES) 8
### ElastiCache Version 7.2.6 für Valkey
Am 10. Oktober 2024 ElastiCache wurde Version 7.2.6 für Valkey veröffentlicht. Hier sind einige der neuen Funktionen, die in 7.2 eingeführt wurden (im Vergleich zu ElastiCache Version 7.1 für Redis OSS):
+ Leistungs- und Speicheroptimierungen für verschiedene Datentypen: Speicheroptimierung für Tasten vom Typ List und Set, Geschwindigkeitsoptimierung für Befehle mit sortierten Sets, Leistungsoptimierung für Befehle mit mehreren Tasten im Clustermodus, pub/sub Leistungsverbesserungen, Leistungsoptimierung für SCAN-, SSCAN-, HSCAN-, ZSCAN-Befehle und zahlreiche andere kleinere Optimierungen.
+ Neue WITHSCORE-Option für die Befehle ZRANK und ZREVRANK
+ CLIENT NO-TOUCH ermöglicht es Clients, Befehle auszuführen, ohne die Tasten zu beeinträchtigen. LRU/LFU
+ Neuer Befehl CLUSTER MYSHARDID, der die Shard-ID des Knotens zurückgibt, um Knoten im Clustermodus auf der Grundlage der Replikation logisch zu gruppieren.
[Weitere Informationen zu Valkey finden Sie unter Valkey](https://valkey.io/)
Weitere Informationen zur ElastiCache Version 7.2 für Valkey finden Sie in den [Versionshinweisen zu Redis OSS 7.2.4](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (ElastiCache Version 7.2 für Valkey enthält alle Änderungen von Version 7.1 für Redis OSS bis ElastiCache ElastiCache Version 7.2.4 für Redis OSS). Versionshinweise zu Valkey 7.2 bei [Valkey](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) am. GitHub
## ElastiCache Version 8.2 für Valkey
Hier sind einige der neuen Funktionen, die in Valkey 8.2 eingeführt wurden (im Vergleich zu ElastiCache Valkey 8.1):
+ Native Unterstützung für [Vector Search](vector-search.md), mit der Sie Milliarden von hochdimensionalen Vektoreinbettungen im Speicher speichern, indexieren, suchen und aktualisieren können, mit Latenzen von nur Mikrosekunden.
[Weitere Informationen zu Valkey finden Sie unter Valkey.](https://valkey.io/)
[Weitere Informationen zur Version Valkey 8.2, in der die Vektorsuche eingeführt wird, finden Sie unter Valkey Search.](https://github.com/valkey-io/valkey-search)
## ElastiCache Version 8.1 für Valkey
Hier sind einige der neuen Funktionen, die in Valkey 8.1 eingeführt wurden (im Vergleich zu ElastiCache Valkey 8.0):
+ Eine [neue Hash-Tabellenimplementierung](https://valkey.io/blog/new-hash-table/), die den Speicheraufwand reduziert, um den Speicherverbrauch für gängige key/value Muster um bis zu 20% zu senken.
+ Native Unterstützung für [Bloom-Filter](https://valkey.io/topics/bloomfilters/), einen neuen Datentyp, mit dem Sie Suchvorgänge mit bis zu 98% weniger Speicher durchführen können als mit dem Set-Datentyp.
+ Neuer Befehl [COMMANDLOG](https://valkey.io/commands/commandlog-get/), der langsame Ausführungen, umfangreiche Anfragen und umfangreiche Antworten aufzeichnet.
+ Neue Unterstützung für bedingte Updates des SET-Befehls mithilfe des IFEQ-Arguments.
+ Leistungsverbesserungen, darunter eine um bis zu 45% geringere Latenz für den Befehl ZRANK, eine bis zu 12-mal schnellere Leistung für PFMERGE und PFCOUNT und ein um bis zu 514% höherer Durchsatz für BITCOUNT.
[Weitere Informationen zu Valkey finden Sie unter Valkey](https://valkey.io/)
Weitere Informationen zur Version Valkey 8.1 finden Sie in den Versionshinweisen zu [Valkey](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES) 8.1
## ElastiCache Version 8.0 für Valkey
Hier sind einige der neuen Funktionen, die in Valkey 8.0 eingeführt wurden (im Vergleich zu ElastiCache Valkey 7.2.6):
+ Verbesserungen der Speichereffizienz, sodass Benutzer bis zu 20% mehr Daten pro Knoten speichern können, ohne dass Änderungen an der Anwendung erforderlich sind.
+ Neu eingeführte Metrikinfrastruktur pro Steckplatz für knotenbasierte Cluster, die detaillierte Einblicke in die Leistung und den Ressourcenverbrauch einzelner Steckplätze bietet.
+ ElastiCache Serverless for Valkey 8.0 kann die Anzahl der unterstützten Anfragen pro Sekunde (RPS) alle 2 bis 3 Minuten verdoppeln, sodass 5 Millionen RPS pro Cache in weniger als 13 Minuten erreicht werden, und das bei gleichbleibender p50-Leselatenz von unter einer Millisekunde.
[Weitere Informationen zu Valkey finden Sie unter Valkey](https://valkey.io/)
Weitere Informationen zur Valkey 8-Version finden Sie in den Versionshinweisen zu [Valkey](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES) 8
## ElastiCache Version 7.2.6 für Valkey
Am 10. Oktober 2024 ElastiCache wurde Version 7.2.6 für Valkey veröffentlicht. Hier sind einige der neuen Funktionen, die in 7.2 eingeführt wurden (im Vergleich zu ElastiCache Version 7.1 für Redis OSS):
+ Leistungs- und Speicheroptimierungen für verschiedene Datentypen: Speicheroptimierung für Tasten vom Typ List und Set, Geschwindigkeitsoptimierung für Befehle mit sortierten Sets, Leistungsoptimierung für Befehle mit mehreren Tasten im Clustermodus, pub/sub Leistungsverbesserungen, Leistungsoptimierung für SCAN-, SSCAN-, HSCAN-, ZSCAN-Befehle und zahlreiche andere kleinere Optimierungen.
+ Neue WITHSCORE-Option für die Befehle ZRANK und ZREVRANK
+ CLIENT NO-TOUCH ermöglicht es Clients, Befehle auszuführen, ohne die Tasten zu beeinträchtigen. LRU/LFU
+ Neuer Befehl CLUSTER MYSHARDID, der die Shard-ID des Knotens zurückgibt, um Knoten im Clustermodus auf der Grundlage der Replikation logisch zu gruppieren.
[Weitere Informationen zu Valkey finden Sie unter Valkey](https://valkey.io/)
Weitere Informationen zur ElastiCache Version 7.2 für Valkey finden Sie in den [Versionshinweisen zu Redis OSS 7.2.4](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (ElastiCache Version 7.2 für Valkey enthält alle Änderungen von Version 7.1 für Redis OSS bis ElastiCache ElastiCache Version 7.2.4 für Redis OSS). Versionshinweise zu Valkey 7.2 bei [Valkey](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) am. GitHub
## Unterstützte Redis OSS-Engine-Versionen
ElastiCache Serverlose Caches und knotenbasierte Cluster unterstützen alle Redis OSS-Versionen 7.1 und früher.
+ [ElastiCache Version 7.1 für Redis OSS (erweitert)](#redis-version-7.1)
**Topics**
+ [ElastiCache Version 7.1 für Redis OSS (erweitert)](#redis-version-7.1)
+ [ElastiCache Version 7.0 für Redis OSS (erweitert)](#redis-version-7.0)
+ [ElastiCache Version 6.2 für Redis OSS (erweitert)](#redis-version-6.2)
+ [ElastiCache Version 6.0 für Redis OSS (erweitert)](#redis-version-6.0)
+ [ElastiCache Version 5.0.6 für Redis OSS (erweitert)](#redis-version-5-0.6)
+ [ElastiCache Version 5.0.5 für Redis OSS (veraltet, verwenden Sie Version 5.0.6)](#redis-version-5-0.5)
+ [ElastiCache Version 5.0.4 für Redis OSS (veraltet, verwenden Sie Version 5.0.6)](#redis-version-5-0.4)
+ [ElastiCache Version 5.0.3 für Redis OSS (veraltet, verwenden Sie Version 5.0.6)](#redis-version-5-0.3)
+ [ElastiCache Version 5.0.0 für Redis OSS (veraltet, verwenden Sie Version 5.0.6)](#redis-version-5-0)
+ [ElastiCache Version 4.0.10 für Redis OSS (erweitert)](#redis-version-4-0-10)
+ [Frühere Versionen für das Ende der Lebensdauer (EOL) (3.x)](#redis-version-3-2-10-scheduled-eol)
+ [Frühere Versionen für das Ende der Lebensdauer (EOL) (2.x)](#redis-version-2-x-eol)
### ElastiCache Version 7.1 für Redis OSS (erweitert)
Diese Version enthält Leistungsverbesserungen, die es Workloads ermöglichen, einen höheren Durchsatz und geringere Betriebslatenzen zu erzielen. ElastiCache Version 7.1 für Redis OSS bietet [zwei](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/) Hauptverbesserungen:
Wir haben die erweiterte I/O Thread-Funktionalität erweitert, um auch die Logik der Präsentationsebene zu handhaben. Mit Presentation Layer meinen wir die erweiterten I/O-Threads, die jetzt nicht nur Client-Eingaben lesen, sondern die Eingabe auch im Redis OSS-Binärbefehlsformat analysieren. Diese wird dann zur Ausführung an den Haupt-Thread weitergeleitet, was zu einer Leistungssteigerung führt. Verbessertes Redis OSS-Speicherzugriffsmuster. Die Ausführungsschritte vieler Datenstrukturoperationen sind miteinander verwoben, um Speicherzugriff und reduzierte Speicherzugriffslatenz parallel zu gewährleisten. Kunden, die ElastiCache auf Graviton3 `R7g.4xlarge` oder höher basieren, können über 1 Million Anfragen pro Sekunde und Knoten erreichen. Mit den Leistungsverbesserungen von Redis OSS v7.1 können Kunden im Vergleich zu ElastiCache Redis OSS v7.0 einen um bis zu 100% höheren Durchsatz und eine um 50% geringere P99-Latenz erzielen. ElastiCache Diese Verbesserungen sind bei Knotengrößen mit mindestens 8 physischen Kernen (`2xlarge` auf Graviton und `4xlarge` auf x86) unabhängig vom CPU-Typ aktiviert und erfordern keine Client-Änderungen.
**Anmerkung**
ElastiCache v7.1 ist mit Redis OSS v7.0 kompatibel.
### ElastiCache Version 7.0 für Redis OSS (erweitert)
ElastiCache für Redis OSS 7.0 bietet eine Reihe von Verbesserungen und Unterstützung für neue Funktionen:
+ [Funktionen](https://valkey.io/topics/functions-intro/): ElastiCache für Redis OSS 7 bietet Unterstützung für Redis OSS-Funktionen und bietet eine verwaltete Oberfläche, die es Entwicklern ermöglicht, [LUA-Skripts](https://valkey.io/topics/eval-intro/) mit auf dem ElastiCache Cluster gespeicherter Anwendungslogik auszuführen, ohne dass Clients die Skripts bei jeder Verbindung erneut an den Server senden müssen.
+ [ACL-Verbesserungen](https://valkey.io/topics/acl/): Valkey und Redis OSS 7 bieten Unterstützung für die nächste Version von Access Control Lists (). ACLs Clients können jetzt mehrere Berechtigungssätze für bestimmte Schlüssel oder Schlüsselräume in Valkey und Redis OSS angeben.
+ [Sharded Pub/Sub](https://valkey.io/topics/pubsub/): ElastiCache Für Valkey und Redis bietet OSS 7 Unterstützung für Pub/Sub functionality in a sharded way when running ElastiCache in Cluster Mode Enabled (CME). Pub/Sub Run-Funktionen, mit denen Publisher Nachrichten an eine beliebige Anzahl von Abonnenten auf einem Kanal versenden können. Kanäle sind an einen Shard im ElastiCache Cluster gebunden, sodass Kanalinformationen nicht mehr über mehrere Shards verteilt werden müssen, was zu einer verbesserten Skalierbarkeit führt.
+ Verbessertes I/O Multiplexing: ElastiCache Für Valkey und Redis führt OSS 7 ein erweitertes I/O-Multiplexing ein, das einen höheren Durchsatz und eine geringere Latenz für Workloads mit hohem Durchsatz und vielen gleichzeitigen Client-Verbindungen zu einem Cluster bietet. ElastiCache Wenn Sie beispielsweise einen Cluster von r6g.xlarge-Knoten verwenden und 5200 Clients gleichzeitig ausführen, können Sie im Vergleich zu ElastiCache Version 6 für Redis OSS einen um bis zu 72% höheren Durchsatz (Lese- und Schreibvorgänge pro Sekunde) und eine um bis zu 71% verringerte P99-Latenz erzielen.
[Weitere Informationen zu Valkey finden Sie unter Valkey.](https://valkey.io/) Weitere Informationen zur Version Redis OSS 7.0 finden Sie in den [Versionshinweisen zu Redis OSS 7.0 unter Redis OSS](https://github.com/redis/redis/blob/7.0/00-RELEASENOTES) auf. GitHub
### ElastiCache Version 6.2 für Redis OSS (erweitert)
ElastiCache für Redis OSS 6.2 beinhaltet Leistungsverbesserungen für TLS-fähige Cluster, die x86-Knotentypen mit 8 V CPUs oder mehr oder Graviton2-Knotentypen mit 4 V oder mehr verwenden. CPUs Diese Verbesserungen verbessern den Durchsatz und reduzieren die Zeit für den Verbindungsaufbau der Clients, indem die Verschlüsselung auf andere V verlagert wird. CPUs Mit Redis OSS 6.2 können Sie auch den Zugriff auf Pub/Sub-Kanäle mithilfe von ACL-Regeln (Access Control List) verwalten.
Mit dieser Version führen wir auch Unterstützung für Daten-Tiering auf Clusterknoten ein, die lokal angeschlossene SSDs enthalten. NVMe Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
Version 6.2.6 der Redis OSS Engine bietet auch Unterstützung für das native JSON-Format ( JavaScript Object Notation), eine einfache, schemalose Methode zur Kodierung komplexer Datensätze in Redis OSS-Clustern. Mit der JSON-Unterstützung können Sie die Leistung und Redis OSS für Anwendungen nutzen, die über JSON arbeiten. APIs Weitere Informationen finden Sie unter [Erste Schritte mit JSON](json-gs.md). Ebenfalls enthalten sind JSON-bezogene Metriken `JsonBasedCmds` und`JsonBasedCmdsLatency`, die CloudWatch zur Überwachung der Verwendung dieses Datentyps integriert sind. Weitere Informationen finden Sie unter [Metriken für Valkey und Redis OSS](CacheMetrics.Redis.md).
Sie geben die Engine-Version mit 6.2 an. ElastiCache ruft automatisch die bevorzugte Patch-Version von Redis OSS 6.2 auf, die verfügbar ist. Wenn Sie beispielsweise einen Cluster erstellen/ändern, setzen Sie den `--engine-version` Parameter auf 6.2. Der Cluster wird mit der jeweils aktuell verfügbaren bevorzugten Patch-Version von Redis OSS 6.2 gestartet. creation/modification Die Angabe der Engine-Version 6.x in der API führt zur neuesten Nebenversion von Redis OSS 6.
Für bestehende 6.0-Cluster können Sie sich für das nächste Autominor-Versions-Upgrade entscheiden, indem Sie den `AutoMinorVersionUpgrade` Parameter `yes` im`CreateCacheCluster`,`ModifyCacheCluster`, `CreateReplicationGroup` oder `ModifyReplicationGroup` APIs auf setzen. ElastiCache aktualisiert die Nebenversion Ihrer vorhandenen 6.0-Cluster mithilfe von Self-Service-Updates auf 6.2. Weitere Informationen finden Sie unter [Self-Service-Updates in Amazon ElastiCache](Self-Service-Updates.md).
Beim Aufrufen der DescribeCacheEngineVersions API wird der `EngineVersion` Parameterwert auf 6.2 gesetzt und die tatsächliche Engine-Version mit der Patch-Version wird im `CacheEngineVersionDescription` Feld zurückgegeben.
Weitere Informationen zur Version Redis OSS 6.2 finden Sie in den [Versionshinweisen zu Redis OSS 6.2](https://github.com/redis/redis/blob/6.2/00-RELEASENOTES) unter Redis OSS auf. GitHub
### ElastiCache Version 6.0 für Redis OSS (erweitert)
Amazon ElastiCache stellt die nächste Version der ElastiCache Redis OSS-Engine vor, die die [Authentifizierung von Benutzern mit rollenbasierter Zugriffskontrolle](Clusters.RBAC.md), clientseitiges Caching und erhebliche betriebliche Verbesserungen umfasst.
Ab Redis OSS 6.0 ElastiCache wird es eine einzige Version für jede Redis OSS-Nebenversion geben, anstatt mehrere Patch-Versionen anzubieten. ElastiCache verwaltet automatisch die Patch-Version Ihrer laufenden Cluster und sorgt so für eine verbesserte Leistung und erhöhte Sicherheit.
Sie können sich auch für das nächste auto Nebenversions-Upgrade anmelden, indem Sie den `AutoMinorVersionUpgrade` Parameter auf `yes` setzen. Das Upgrade der Nebenversion ElastiCache wird über Self-Service-Updates verwaltet. Weitere Informationen finden Sie unter [Service-Updates in ElastiCache](Self-Service-Updates.md).
Sie geben die Engine-Version an, indem Sie `6.0` ElastiCache ruft automatisch die bevorzugte Patch-Version von Redis OSS 6.0 auf, die verfügbar ist. Wenn Sie beispielsweise create/modify einen Cluster erstellen, setzen Sie den `--engine-version` Parameter auf 6.0. Der Cluster wird zum Zeitpunkt der Erstellung/Änderung mit der aktuell verfügbaren bevorzugten Patch-Version von Redis OSS 6.0 gestartet. Jede Anfrage mit einem bestimmten Patch-Versionswert wird abgelehnt, eine Ausnahme wird ausgelöst und der Vorgang schlägt fehl.
Beim Aufrufen der DescribeCacheEngineVersions API wird der `EngineVersion` Parameterwert auf 6.0 gesetzt und die tatsächliche Engine-Version mit der Patch-Version wird im Feld zurückgegeben. `CacheEngineVersionDescription`
Weitere Informationen zur Version Redis OSS 6.0 finden Sie in den [Versionshinweisen zu Redis OSS 6.0](https://github.com/redis/redis/blob/6.0/00-RELEASENOTES) unter Redis OSS auf. GitHub
### ElastiCache Version 5.0.6 für Redis OSS (erweitert)
Amazon ElastiCache stellt die nächste Version von ElastiCache für die Redis OSS-Engine vor, die Fehlerkorrekturen und die folgenden kumulativen Updates enthält:
+ Garantierte Engine-Stabilität in speziellen Bedingungen.
+ Verbesserte Hyperloglog-Fehlerbehandlung.
+ Erweiterte Handshake-Befehle für eine zuverlässige Replikation.
+ Konsistente Nachverfolgung der Nachrichtenzustellung über den `XCLAIM`-Befehl.
+ Verbesserte `LFU `-Feldverwaltung in Objekten.
+ Verbesserte Transaktionsverwaltung bei Verwendung von `ZPOP`.
+ Möglichkeit, Befehle umzubenennen: Ein Parameter namens`rename-commands`, der es Ihnen ermöglicht, potenziell gefährliche oder teure Redis OSS-Befehle umzubenennen, die zu versehentlichem Datenverlust führen könnten, wie z. B. oder. `FLUSHALL` `FLUSHDB` Dies ähnelt der Konfiguration mit Rename-Commands im Open-Source-Redis OSS. ElastiCacheHat jedoch die Benutzererfahrung durch die Bereitstellung eines vollständig verwalteten Workflows verbessert. Die Befehlsnamensänderungen werden sofort übernommen und automatisch in allen Knoten im Cluster vorgenommen, die die Befehlsliste enthalten. Es ist kein Eingriff Ihrerseits erforderlich, wie etwa das Neustarten der Knoten.
Die folgenden Beispiele zeigen, wie Sie vorhandene Parametergruppen ändern. Sie enthalten den `rename-commands`-Parameter, eine durch Leerzeichen getrennte Liste von Befehlen, die Sie umbenennen möchten:
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall'" --region region
```
In diesem Beispiel wird der *rename-commands*-Parameter zum Umbenennen des `flushall`-Befehls in `restrictedflushall` verwendet.
Zum Umbenennen mehrerer Befehle verwenden Sie Folgendes:
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall flushdb restrictedflushdb''" --region region
```
Zum Zurücksetzen einer Änderung führen Sie den Befehl erneut aus und schließen sämtliche umbenannten Werte folgendermaßen von der `ParameterValue`-Liste aus, die Sie beibehalten möchten:
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall'" --region region
```
In diesem Fall wird der `flushall`-Befehl in `restrictedflushall` umbenannt und sämtliche anderen umbenannten Befehle werden auf ihre ursprünglichen Befehlsnamen zurückgesetzt.
**Anmerkung**
Beim Umbenennen von Befehlen unterliegen Sie den folgenden Einschränkungen:
Alle umbenannten Befehle müssen alphanumerisch sein.
Die maximale Länge neuer Befehlsnamen beträgt 20 alphanumerische Zeichen.
Beim Umbenennen von Befehlen muss sichergestellt werden, dass Sie die Parametergruppe aktualisieren, die mit Ihrem Cluster verknüpft ist.
Um die Nutzung eines Befehls gänzlich zu verhindern, verwenden Sie das Schlüsselwort `blocked` folgendermaßen:
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall blocked'" --region region
```
Weitere Informationen zu den Parameteränderungen und eine Liste der Befehle, die umbenannt werden können, finden Sie unter [Änderungen an den Parametern von Redis OSS 5.0.3](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3).
+ Redis OSS Streams: Dabei wird eine Protokolldatenstruktur modelliert, die es Produzenten ermöglicht, neue Elemente in Echtzeit anzuhängen. Nachrichten können auch blockierend oder blockierungsfrei abgerufen werden. Streams ermöglichen auch Konsumentengruppen als Gruppe von Clients, die zusammen unterschiedliche Teile desselben Nachrichten-Streams abrufen, ähnlich wie bei [Apache Kafka](https://kafka.apache.org/documentation/). [Weitere Informationen finden Sie unter Streams.](https://valkey.io/topics/streams-intro)
+ Unterstützung für eine Reihe von Stream-Befehlen wie etwa `XADD`, `XRANGE` und `XREAD`. Weitere Informationen finden Sie unter [Streams-Befehle](https://valkey.io/commands/#stream).
+ Eine Anzahl neuer und umbenannter Parameter. Weitere Informationen finden Sie unter [Änderungen der Parameter von Redis OSS 5.0.0](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0).
+ Eine neue Redis-OSS-Metrik,`StreamBasedCmds`.
+ Etwas schnellere Snapshot-Zeit für Redis OSS-Knoten.
**Wichtig**
ElastiCache hat zwei kritische Bugfixes aus der [Open-Source-Version 5.0.1 von Redis OSS](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) zurückportiert. Sie sind im Folgenden aufgeführt:
RESTORE-Antwort bei fehlender Übereinstimmung, wenn bestimmte Schlüssel bereits abgelaufen sind.
Der Befehl `XCLAIM` kann einen falschen Eintrag zurückgeben oder die Synchronisierung des Protokolls verhindern.
Beide Bugfixes sind in der Redis OSS-Unterstützung ElastiCache für Redis OSS Engine Version 5.0.0 enthalten und werden in future Versionsupdates verwendet.
Weitere Informationen finden Sie in den [Versionshinweisen zu Redis OSS 5.0.6](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) unter Redis OSS unter. GitHub
### ElastiCache Version 5.0.5 für Redis OSS (veraltet, verwenden Sie Version 5.0.6)
Amazon ElastiCache stellt die nächste Version von ElastiCache für die Redis OSS-Engine vor;. Es beinhaltet Online-Konfigurationsänderungen für ElastiCache Auto-Failover-Cluster während aller geplanten Operationen. Sie können jetzt Ihren Cluster skalieren, die Redis OSS-Engine-Version aktualisieren und Patches und Wartungsupdates anwenden, während der Cluster online bleibt und weiterhin eingehende Anfragen bearbeitet. Das beinhaltet auch Fehlerbehebungen.
Weitere Informationen finden Sie in den [Versionshinweisen zu Redis OSS 5.0.5](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) unter Redis OSS unter. GitHub
### ElastiCache Version 5.0.4 für Redis OSS (veraltet, verwenden Sie Version 5.0.6)
Amazon ElastiCache stellt die nächste Version der Redis OSS-Engine vor, die von ElastiCache unterstützt wird. Die Version enthält die folgenden Erweiterungen:
+ Garantierte Engine-Stabilität in speziellen Bedingungen.
+ Verbesserte Hyperloglog-Fehlerbehandlung.
+ Erweiterte Handshake-Befehle für eine zuverlässige Replikation.
+ Konsistente Nachverfolgung der Nachrichtenzustellung über den `XCLAIM`-Befehl.
+ Verbesserte `LFU `-Feldverwaltung in Objekten.
+ Verbesserte Transaktionsverwaltung bei Verwendung von `ZPOP`.
Weitere Informationen finden Sie in den [Versionshinweisen zu Redis OSS 5.0.4](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) unter Redis OSS am. GitHub
### ElastiCache Version 5.0.3 für Redis OSS (veraltet, verwenden Sie Version 5.0.6)
Amazon ElastiCache stellt die nächste Version von ElastiCache für die Redis OSS-Engine vor, die Fehlerkorrekturen enthält.
### ElastiCache Version 5.0.0 für Redis OSS (veraltet, verwenden Sie Version 5.0.6)
Amazon ElastiCache stellt die nächste Hauptversion von ElastiCache für die Redis OSS-Engine vor. ElastiCache Version 5.0.0 für Redis OSS bietet Unterstützung für die folgenden Verbesserungen:
+ Redis OSS Streams: Dies modelliert eine Protokolldatenstruktur, die es Produzenten ermöglicht, neue Elemente in Echtzeit anzuhängen. Nachrichten können auch blockierend oder blockierungsfrei abgerufen werden. Streams ermöglichen auch Konsumentengruppen als Gruppe von Clients, die zusammen unterschiedliche Teile desselben Nachrichten-Streams abrufen, ähnlich wie bei [Apache Kafka](https://kafka.apache.org/documentation/). [Weitere Informationen finden Sie unter Streams.](https://valkey.io/topics/streams-intro)
+ Unterstützung für eine Reihe von Stream-Befehlen wie etwa `XADD`, `XRANGE` und `XREAD`. Weitere Informationen finden Sie unter [Streams-Befehle](https://valkey.io/commands/#stream).
+ Eine Anzahl neuer und umbenannter Parameter. Weitere Informationen finden Sie unter [Änderungen der Parameter von Redis OSS 5.0.0](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0).
+ Eine neue Redis-OSS-Metrik,`StreamBasedCmds`.
+ Etwas schnellere Snapshot-Zeit für Redis OSS-Knoten.
### ElastiCache Version 4.0.10 für Redis OSS (erweitert)
Amazon ElastiCache stellt die nächste Hauptversion von ElastiCache für die Redis OSS-Engine vor. ElastiCache Version 4.0.10 für Redis OSS bietet Unterstützung für die folgenden Verbesserungen:
+ Sowohl Online-Cluster-Größenänderung als auch Verschlüsselung in einer einzigen Version. ElastiCache Weitere Informationen finden Sie hier:
+ [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md)
+ [Online-Resharding für Valkey oder Redis OSS (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Datensicherheit bei Amazon ElastiCache](encryption.md)
+ Eine Anzahl neuer Parameter. Weitere Informationen finden Sie unter [Änderungen an den Parametern von Redis OSS 4.0.10](ParameterGroups.Engine.md#ParameterGroups.Redis.4-0-10).
+ Unterstützung für eine Reihe von Speicherbefehlen wie etwa `MEMORY`. Weitere Informationen finden Sie unter [Befehle](https://valkey.io/commands) (Suche auf MEMO).
+ Unterstützung für Speicherdefragmentierung, während das System online ist, wodurch eine effizientere Speichernutzung ermöglicht wird und mehr Speicher für Ihre Daten zur Verfügung steht.
+ Support für asynchrone Leerungen und Löschungen. ElastiCache für Redis unterstützt OSS Befehle wie `UNLINK` `FLUSHDB` und `FLUSHALL` zur Ausführung in einem anderen Thread als dem Haupt-Thread. Dies hilft, Leistung und Reaktionszeiten für Ihre Anwendungen zu verbessern, indem Speicher asynchron freigegeben wird.
+ Eine neue Redis OSS-Metrik,. `ActiveDefragHits` Weitere Informationen finden Sie unter [Metriken für Redis OSS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CacheMetrics.Redis.html).
Redis OSS-Benutzer (Clustermodus deaktiviert), die ElastiCache Version 3.2.10 für Redis OSS ausführen, können die Konsole verwenden, um ihre Cluster per Online-Upgrade zu aktualisieren.
**Vergleich der ElastiCache Clustergrößenänderung und der Verschlüsselungsunterstützung**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/engine-versions.html)
### Frühere Versionen für das Ende der Lebensdauer (EOL) (3.x)
#### ElastiCache Version 3.2.10 für Redis OSS (erweitert)
Amazon ElastiCache stellt die nächste Hauptversion von ElastiCache für die Redis OSS-Engine vor. ElastiCache Version 3.2.10 für Redis OSS (verbessert) führt die Online-Größenänderung von Clustern ein, um Shards zum Cluster hinzuzufügen oder daraus zu entfernen, während der Cluster weiterhin eingehende Anfragen bearbeitet. I/O ElastiCache für Redis OSS 3.2.10 stehen Benutzern alle Funktionen früherer Redis OSS-Versionen zur Verfügung, mit Ausnahme der Möglichkeit, ihre Daten zu verschlüsseln. Diese Möglichkeit ist derzeit nur in Version 3.2.6 verfügbar.
**Vergleich der ElastiCache Versionen 3.2.6 und 3.2.10 für Redis OSS**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/engine-versions.html)
Weitere Informationen finden Sie hier:
+ [Online-Resharding für Valkey oder Redis OSS (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Online-Größenanpassung von Clustern](best-practices-online-resharding.md)
#### ElastiCache Version 3.2.6 für Redis OSS (erweitert)
Amazon ElastiCache stellt die nächste Hauptversion von ElastiCache für die Redis OSS-Engine vor. ElastiCache Version 3.2.6 für Redis OSS-Benutzer haben Zugriff auf alle Funktionen früherer Redis OSS-Versionen sowie auf die Option, ihre Daten zu verschlüsseln. Weitere Informationen finden Sie hier:
+ [ElastiCache Verschlüsselung bei der Übertragung (TLS)](in-transit-encryption.md)
+ [Verschlüsselung im Ruhezustand in ElastiCache](at-rest-encryption.md)
+ [Konformitätsvalidierung für Amazon ElastiCache](elasticache-compliance.md)
#### ElastiCache Version 3.2.4 für Redis OSS (erweitert)
ElastiCache Amazon-Version 3.2.4 führt die nächste Hauptversion von ElastiCache für die Redis OSS-Engine ein. ElastiCache *3.2.4-Benutzern stehen alle Funktionen früherer Redis OSS-Versionen sowie die Option zur Ausführung im *Cluster-Modus oder Nicht-Cluster-Modus* zur Verfügung.* Die folgende Tabelle enthält eine Zusammenfassung.
**Vergleich von Redis OSS 3.2.4 im Nicht-Cluster-Modus und im Cluster-Modus**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/engine-versions.html)
**Hinweise:**
+ **Partitionierung** – die Möglichkeit, Ihre Daten auf 2 bis 500 Knotengruppen (Shards) mit Replikationsunterstützung für jede Knotengruppe aufzuteilen.
+ **Geospatiale Indizierung** — Redis OSS 3.2.4 bietet Unterstützung für die Geodatenindizierung über sechs GEO-Befehle. Weitere Informationen finden Sie in der Redis OSS GEO\$1-Befehlsdokumentation [Befehle: GEO auf der Seite Valkey-Befehle (gefiltert nach GEO](http://valkey.io/commands#geo)).
Informationen zu zusätzlichen Funktionen von Redis OSS 3 finden Sie in den Versionshinweisen zu [Redis OSS 3.2 und den Versionshinweisen](https://github.com/redis/redis/blob/3.2/00-RELEASENOTES) zu [Redis](https://github.com/redis/redis/blob/3.0/00-RELEASENOTES) OSS 3.0.
Derzeit ElastiCache verwaltetes Valkey oder Redis OSS (Clustermodus aktiviert) unterstützt die folgenden Redis OSS 3.2-Funktionen nicht:
+ Replikatmigration
+ Cluster-Ausgleich
+ Lua Debugger
ElastiCache deaktiviert die folgenden Redis OSS 3.2-Verwaltungsbefehle:
+ `cluster meet`
+ `cluster replicate`
+ `cluster flushslots`
+ `cluster addslots`
+ `cluster delslots`
+ `cluster setslot`
+ `cluster saveconfig`
+ `cluster forget`
+ `cluster failover`
+ `cluster bumpepoch`
+ `cluster set-config-epoch`
+ `cluster reset`
Informationen zu den Redis OSS 3.2.4-Parametern finden Sie unter. [Änderungen der Parameter in Redis OSS 3.2.4](ParameterGroups.Engine.md#ParameterGroups.Redis.3-2-4)
### Frühere Versionen für das Ende der Lebensdauer (EOL) (2.x)
#### ElastiCache Version 2.8.24 für Redis OSS (erweitert)
Zu den seit Version 2.8.23 hinzugefügten Verbesserungen an Redis OSS gehören Bugfixes und die Protokollierung fehlerhafter Speicherzugriffsadressen. Weitere Informationen finden Sie in den Versionshinweisen zu [Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
#### ElastiCache Version 2.8.23 für Redis OSS (erweitert)
Die seit Version 2.8.22 hinzugefügten Redis OSS-Verbesserungen beinhalten Fehlerkorrekturen. Weitere Informationen finden Sie in den Versionshinweisen zu [Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES). Diese Version umfasst außerdem Support für den neuen Parameter `close-on-slave-write` der in aktiviertem Zustand die Verbindung zu Clients trennt, die versuchen, in ein schreibgeschütztes Replikat zu schreiben.
Weitere Informationen zu den Parametern von Redis OSS 2.8.23 finden Sie [Redis OSS 2.8.23 (erweitert) hat Parameter hinzugefügt](ParameterGroups.Engine.md#ParameterGroups.Redis.2-8-23) im Benutzerhandbuch. ElastiCache
#### ElastiCache Version 2.8.22 für Redis OSS (erweitert)
Zu den Verbesserungen von Redis OSS, die seit Version 2.8.21 hinzugefügt wurden, gehören:
+ Support für unvergabelte Sicherungen und Synchronisationen, sodass Sie weniger Speicher für die Sicherungsverwaltung und mehr für Ihre Anwendung zuweisen können. Weitere Informationen finden Sie unter [So werden Synchronisation und Backup implementiert](Replication.Redis.Versions.md). Der unvergabelte Prozess kann sich sowohl auf die Latenz als auch den Durchsatz auswirken. Bei einem hohen Schreibdurchsatz kann ein Replikat, das erneut synchronisiert wird, für den gesamten Synchronisierungszeitraum nicht erreichbar sein.
+ Bei einem Failover werden Replikationsgruppen nun schneller wiederhergestellt, da Replikate möglichst eine partielle Synchronisierung mit dem primären Knoten anstelle von vollständigen Synchronisierungen durchführen. Darüber hinaus verwenden sowohl der primäre Knoten als auch die Replicas während der Synchronisierungen keinen Datenträger mehr, was sich positiv auf die Geschwindigkeit auswirkt.
+ Support für zwei neue CloudWatch Metriken.
+ `ReplicationBytes` – Die Anzahl der Bytes, die der primäre Cluster einer Replikationsgruppe an die Lesereplikate sendet.
+ `SaveInProgress` – Ein Binärwert, der angibt, ob ein Speicherprozess im Hintergrund ausgeführt wird oder nicht.
Weitere Informationen finden Sie unter [Überwachung der Nutzung mit CloudWatch Metrics](CacheMetrics.md).
+ Eine Reihe entscheidender Fehlerbehebungen im PSYNC-Replikationsverhalten. Weitere Informationen finden Sie in den [Versionshinweisen zu Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
+ Um die verbesserte Replikationsleistung in Multi-AZ-Replikationsgruppen aufrechtzuerhalten und die Cluster-Stabilität zu erhöhen, werden ElastiCache Nicht-Replikate nicht mehr unterstützt.
+ Zur Verbesserung der Datenkonsistenz zwischen dem primären Cluster und Replikaten in einer Replikationsgruppe entfernen die Replikate keine Schlüssel unabhängig vom primären Cluster mehr.
+ Redis OSS-Konfigurationsvariablen `appendonly` und `appendfsync` werden in Redis OSS Version 2.8.22 und höher nicht unterstützt.
+ In Situationen mit geringem Speicher können Clients mit einem großen Ausgabepuffer von einem Replikat-Cluster getrennt werden. In diesem Fall muss der Client die Verbindung erneut herstellen. Solche Situationen treten häufig bei PUBSUB-Clients auf.
#### ElastiCache Version 2.8.21 für Redis OSS
Die seit Version 2.8.19 hinzugefügten Redis OSS-Verbesserungen beinhalten eine Reihe von Fehlerkorrekturen. Weitere Informationen finden Sie in den Versionshinweisen zu [Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
#### ElastiCache Version 2.8.19 für Redis OSS
Zu den Verbesserungen von Redis OSS, die seit Version 2.8.6 hinzugefügt wurden, gehören:
+ Support für HyperLogLog. Weitere Informationen finden Sie unter [Neue Datenstruktur von Redis OSS: HyperLogLog](http://antirez.com/news/75).
+ Der Datentyp „Sorted Set“ verfügt mit den neuen Befehlen `ZRANGEBYLEX`, `ZLEXCOUNT` und `ZREMRANGEBYLEX` nun über Support für lexikografische Bereichsabfragen.
+ Damit ein primärer Knoten keine veralteten Daten an Replica-Knoten sendet, schlägt die Master-Synchronisierung fehl, wenn ein untergeordneter Speicherprozess im Hintergrund (`bgsave`) abgebrochen wird.
+ Support für die *HyperLogLogBasedCommands* CloudWatchMetrik. Weitere Informationen finden Sie unter [Metriken für Valkey und Redis OSS](CacheMetrics.Redis.md).
#### ElastiCache Version 2.8.6 für Redis OSS
Zu den Verbesserungen von Redis OSS, die seit Version 2.6.13 hinzugefügt wurden, gehören:
+ Verbesserte Resilienz und Fehlertoleranz für Read Replicas.
+ Support für partielle Synchronisierung.
+ Support für eine benutzerdefinierte Mindestanzahl von Read Replicas, die jederzeit verfügbar sein müssen.
+ Volle Unterstützung für Pub/Sub – Benachrichtigen von Clients über Ereignisse auf dem Server.
+ Automatische Erkennung eines Ausfalls des primären Knotens und eines Failovers Ihres primären auf einen sekundären Knoten.
#### ElastiCache Version 2.6.13 für Redis OSS
ElastiCache Version 2.6.13 für Redis OSS war die erste Version, die Redis OSS unterstützte. ElastiCache Multi-AZ wird in ElastiCache Version 2.6.13 für Redis OSS nicht unterstützt.
## ElastiCache Zeitplan für das Ende der Lebensdauer von Versionen für Redis OSS
In diesem Abschnitt werden die Termine für das Ende der Lebensdauer (EOL) für ältere Hauptversionen so festgelegt, wie sie angekündigt werden. Auf diese Weise können Sie Versions- und Upgrade-Entscheidungen für die Zukunft treffen.
**Anmerkung**
ElastiCache Versionen von 5.0.0 bis 5.0.5 für Redis OSS sind veraltet. Verwenden Sie Version 5.0.6 oder höher.
Die folgende Tabelle zeigt den Zeitplan für den [erweiterten Support](extended-support.md) ElastiCache für Redis OSS-Engines.
**Erweiterter Support und Zeitplan für das Ende des Lebenszyklus**
| Hauptversion der Engine | Ende des Standard-Supports | Beginn des erweiterten Support Y1 Premium | Beginn des erweiterten Support Y2 Premium | Beginn des erweiterten Support Y3 Premium | Ende des erweiterten Support und Versions-EOL |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 31.1.2026 | 1.2.2026 | 1.2.2027 | 1.2.2028 | 31.1.2029 |
| Redis OSS v5 | 31.1.2026 | 1.2.2026 | 1.2.2027 | 1.2.2028 | 31.1.2029 |
| Redis OSS v6 | 31.1.2027 | 1.2.2027 | 1.2.2028 | 1.2.2029 | 31.1.2030 |
Die folgende Tabelle fasst jede Version und ihr angekündigtes EOL-Datum sowie die empfohlene Upgrade-Zielversion zusammen.
**Vergangenes EOL**
| Quelle für Hauptversionen | Quelle für Unterversionen | Empfohlenes Upgrade-Ziel | EOL-Datum |
| --- | --- | --- | --- |
| Version 3 | 3.2.4, 3.2.6 und 3.2.10 | Version 6.2 oder höher Für die Regionen US-ISO-EAST US-ISO-WEST -1, -1 und US-ISOB-EAST -1 empfehlen wir 5.0.6 oder höher. | 31. Juli 2023 |
| Version 2 | 2.8.24, 2.8.23, 2.8.22, 2.8.21, 2.8.19, 2.8.12, 2.8.6, 2.6.13 | Version 6.2 oder höher Für die Regionen -1, -1 und -1 empfehlen wir 5.0.6 oder höher. US-ISO-EAST US-ISO-WEST US-ISOB-EAST | 13. Januar 2023 |
## Wird ElastiCache für Memcached-Versionen unterstützt
ElastiCache unterstützt die folgenden Memcached-Versionen und Upgrades auf neuere Versionen. Achten Sie beim Upgrade auf eine neuere Version sorgfältig auf die Bedingungen, die Ihr Upgrade fehlschlagen lassen, wenn sie nicht erfüllt werden.
**Topics**
+ [ElastiCache Version 1.6.22 für Memcached](#memcached-version-1-6-22)
+ [ElastiCache Version 1.6.17 für Memcached](#memcached-version-1-6-17)
+ [ElastiCache Version 1.6.12 für Memcached](#memcached-version-1-6-12)
+ [ElastiCache Version 1.6.6 für Memcached](#memcached-version-1-6-6)
+ [ElastiCache Version 1.5.16 für Memcached](#memcached-version-1-5-16)
+ [ElastiCache Version 1.5.10 für Memcached](#memcached-version-1-5-10)
+ [ElastiCache Version 1.4.34 für Memcached](#memcached-version-1-4-34)
+ [ElastiCache Version 1.4.33 für Memcached](#memcached-version-1-4-33)
+ [ElastiCache Version 1.4.24 für Memcached](#memcached-version-1-4-24)
+ [ElastiCache Version 1.4.14 für Memcached](#memcached-version-1-4-14)
+ [ElastiCache Version 1.4.5 für Memcached](#memcached-version-1-4-5)
### ElastiCache Version 1.6.22 für Memcached
ElastiCache für Memcached Version 1.6.22 für Memcached fügt Unterstützung für Memcached Version 1.6.22 hinzu. Es sind keine neuen Funktionen enthalten, aber Fehlerbehebungen und kumulative Updates von [Memcached 1.6.18](https://github.com/memcached/memcached/wiki/ReleaseNotes1618).
[Weitere Informationen finden Sie unter 1622 bei Memcached am. ReleaseNotes](https://github.com/memcached/memcached/wiki/ReleaseNotes1622) GitHub
### ElastiCache Version 1.6.17 für Memcached
ElastiCache für Memcached Version 1.6.17 für Memcached fügt Unterstützung für Memcached Engine Version 1.6.17 hinzu. Es sind keine neuen Funktionen enthalten, aber Fehlerbehebungen und kumulative Updates von [Memcached 1.6.17](https://github.com/memcached/memcached/wiki/ReleaseNotes1617).
[Weitere Informationen finden Sie unter 1617 bei Memcached am. ReleaseNotes](https://github.com/memcached/memcached/wiki/ReleaseNotes1617) GitHub
### ElastiCache Version 1.6.12 für Memcached
ElastiCache Version 1.6.12 für Memcached für Memcached fügt Unterstützung für Memcached Engine 1.6.12 und Verschlüsselung bei der Übertragung hinzu. Es enthält Fehlerkorrekturen und kumulative Aktualisierungen von [Memcached 1.5.16](https://github.com/memcached/memcached/wiki/ReleaseNotes166).
Weitere Informationen finden Sie [ReleaseNotesunter 1612](https://github.com/memcached/memcached/wiki/ReleaseNotes1612) bei GitHub Memcached am.
### ElastiCache Version 1.6.6 für Memcached
ElastiCache für Memcached Version 1.6.6 für Memcached fügt Unterstützung für Memcached Version 1.6.6 hinzu. [Sie enthält keine neuen Funktionen, jedoch Bugfixes und kumulative Updates von Memcached 1.5.16.](https://github.com/memcached/memcached/wiki/ReleaseNotes1.5.16) ElastiCache [für Memcached beinhaltet keine Unterstützung für Extstore.](https://memcached.org/extstore)
Weitere Informationen finden Sie in Memcached unter [ReleaseNotes166](https://github.com/memcached/memcached/wiki/ReleaseNotes166). GitHub
### ElastiCache Version 1.5.16 für Memcached
ElastiCache Version 1.5.16 für Memcached fügt Unterstützung für Memcached Version 1.5.16 hinzu. Es sind keine neuen Funktionen enthalten, dafür aber Fehlerbehebungen und kumulative Updates von [Memcached 1.5.14](https://github.com/memcached/memcached/wiki/ReleaseNotes1514) und [Memcached 1.5.15](https://github.com/memcached/memcached/wiki/ReleaseNotes1515).
[Weitere Informationen finden Sie in den Versionshinweisen zu Memcached 1.5.16 auf Memcached am.](https://github.com/memcached/memcached/wiki/ReleaseNotes1516) GitHub
### ElastiCache Version 1.5.10 für Memcached
ElastiCache Version 1.5.10 für Memcached unterstützt die folgenden Memcached-Funktionen:
+ Automatisierter Slab-Ausgleich
+ Schnelleres Suchen von Hash-Tabellen durch `murmur3`-Algorithmus
+ Segmentierter LRU-Algorithmus
+ LRU-Crawler, um im Hintergrund Speicher zurückzugewinnen
+ `--enable-seccomp`: eine Kompilierungszeitoption
Es werden auch die Parameter `no_modern` und `inline_ascii_resp` eingeführt. Weitere Informationen finden Sie unter [Parameteränderungen für Memcached 1.5.10](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-5-10).
Zu den Verbesserungen von Memcached, die seit ElastiCache Version 1.4.34 für Memcached hinzugefügt wurden, gehören:
+ Kumulative Korrekturen wie ASCII-Multigets, CVE-2017-9951 und Limit-Crawler for `metadumper`
+ Verbesserte Verbindungsverwaltung durch das Schließen von Verbindungen beim Erreichen der maximalen Verbindungsanzahl
+ Verbesserte Verwaltung der Elementgröße bei Elementen, deren Größe 1 MB überschreitet
+ Bessere Leistung und Optimierung des Speichermehraufwands durch Reduzierung der Speicheranforderungen pro Element um wenige Bytes
Weitere Informationen finden Sie in den Versionshinweisen zu Memcached 1.5.10 auf [Memcached](https://github.com/memcached/memcached/wiki/ReleaseNotes1510) am. GitHub
### ElastiCache Version 1.4.34 für Memcached
ElastiCache Version 1.4.34 für Memcached fügt Version 1.4.33 keine neuen Funktionen hinzu. Version 1.4.34 dient der Fehlerbehebung und ist größer als für eine solche Version üblich.
Weitere Informationen finden Sie in den Versionshinweisen zu Memcached 1.4.34 auf [Memcached](https://github.com/memcached/memcached/wiki/ReleaseNotes1434) am. GitHub
### ElastiCache Version 1.4.33 für Memcached
Zu den Verbesserungen, die seit Version 1.4.24 hinzugefügt wurden, gehören:
+ Die Fähigkeit, alle Metadaten für eine bestimmte Slab-Klasse, eine Liste der Slab-Klassen oder alle Slab-Klassen zu sichern. Weitere Informationen finden Sie unter [Memcached 1.4.31 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1431).
+ Verbesserter Support für große Elemente über den Standardwert von 1 MB. Weitere Informationen finden Sie unter [Memcached 1.4.29 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1429).
+ Die Fähigkeit, anzugeben, wie lange sich ein Client im Leerlauf befinden kann, bevor er zum Schließen aufgefordert wird.
Die Fähigkeit, den für Memcached verfügbaren Speicherplatz dynamisch zu erhöhen, ohne den Cluster neu starten zu müssen. Weitere Informationen finden Sie unter [Memcached 1.4.27 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1427).
+ Die Protokollierung von `fetchers`, `mutations` und `evictions` wird jetzt unterstützt. Weitere Informationen finden Sie unter [Memcached 1.4.26 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1426).
+ Freier Speicher kann für einen globalen Pool wieder freigegeben und neuen Slab-Klassen zugewiesen werden. Weitere Informationen finden Sie unter [Memcached 1.4.25 Release Notes](https://github.com/memcached/memcached/wiki/ReleaseNotes1425).
+ Mehrere Fehlerbehebungen
+ Einige neue Befehle und Parameter Eine Liste finden Sie hier: [In Memcached 1.4.33 hinzugefügte Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-33).
### ElastiCache Version 1.4.24 für Memcached
Zu den Verbesserungen, die seit Version 1.4.14 hinzugefügt wurden, gehören:
+ Die LRU-Verwaltung (Least Recently Used) mit einem Hintergrundprozess wurde verbessert.
+ Die Option, *jenkins* oder *murmur3* als Hash-Algorithmus zu verwenden, wurde hinzugefügt.
+ Einige neue Befehle und Parameter Eine Liste finden Sie hier: [In Memcached 1.4.24 hinzugefügte Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-24).
+ Mehrere Fehlerbehebungen
### ElastiCache Version 1.4.14 für Memcached
Zu den Verbesserungen, die seit Version 1.4.5 hinzugefügt wurden, gehören:
+ Verbesserter Slab-Ausgleich.
+ Performance und Skalierbarkeit wurden verbessert.
+ Der Befehl *touch* wurde eingeführt, um das Ablaufdatum eines vorhandenen Elements zu aktualisieren, ohne es abzurufen.
+ Automatische Erkennung – die Möglichkeit für Client-Programme, automatisch alle Cache-Knoten in einem Cluster zu ermitteln und Verbindungen zu all diesen Knoten zu initiieren und aufrechtzuerhalten.
### ElastiCache Version 1.4.5 für Memcached
ElastiCache Version 1.4.5 für Memcached war die erste Engine und Version, die von Amazon ElastiCache für Memcached unterstützt wurden.
# Wichtige Unterschiede zwischen dem Verhalten und der Kompatibilität der Engine-Versionen mit Valkey
Valkey 7.2.6 weist ähnliche Kompatibilitätsunterschiede zu früheren Versionen von Redis OSS 7.2.4 auf. Die neueste unterstützte Version von Valkey finden Sie unter. [Unterstützte Engines und Versionen](VersionManagement.md#supported-engine-versions)
Weitere Informationen zur Version Valkey 7.2 finden Sie in den [Versionshinweisen zu Redis OSS 7.2.4](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (Valkey 7.2 enthält alle Änderungen von Redis OSS bis Version 7.2.4) und in den Versionshinweisen zu Valkey 7.2 unter [Valkey](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) am. GitHub
Hier sind die potenziell schwerwiegenden Verhaltensänderungen zwischen Valkey 7.2 und Redis OSS 7.1 (oder 7.0):
+ Das Freeze Time-Sampling erfolgt während der Befehlsausführung und in Skripten.
+ Ein blockierter Stream-Befehl, der freigegeben wird, wenn der Schlüssel nicht mehr existiert, enthält einen anderen Fehlercode (-NOGROUP oder -WRONGTYPE statt -UNBLOCKED).
+ Die clientseitige Nachverfolgung von Skripten verfolgt nun die Schlüssel, die vom Skript gelesen werden, und nicht die Schlüssel, die vom Aufrufer von EVAL//FCALL deklariert wurden.
# Wesentliche Unterschiede zwischen dem Verhalten und der Kompatibilität der Engine-Versionen mit Redis OSS
**Wichtig**
Auf der folgenden Seite sind alle Inkompatibilitätsunterschiede zwischen den Versionen aufgeführt und alle Aspekte angegeben, die Sie beim Upgrade auf neuere Versionen beachten sollten. In dieser Liste sind alle Probleme bezüglich Versionsinkompatibilitäten aufgeführt, die beim Upgrade auftreten können.
Sie können direkt von Ihrer aktuellen Redis OSS-Version auf die neueste verfügbare Redis OSS-Version aktualisieren, ohne dass sequentielle Upgrades erforderlich sind. Sie können beispielsweise direkt von Redis OSS Version 3.0 auf Version 7.0 aktualisieren.
Redis OSS-Versionen werden mit einer semantischen Version identifiziert, die aus einer Haupt-, Neben- und einer Patch-Komponente besteht. In Redis OSS 4.0.10 ist die Hauptversion beispielsweise 4, die Nebenversion 0 und die Patch-Version 10. Diese Werte werden im Allgemeinen basierend auf den folgenden Konventionen schrittweise erhöht:
+ Hauptversionen sind für API-inkompatible Änderungen vorgesehen
+ Nebenversionen sind für neue Funktionen vorgesehen, die abwärtskompatibel hinzugefügt wurden
+ Patch-Versionen sind für abwärtskompatible Bugfixes und nicht funktionale Änderungen vorgesehen
Wir empfehlen, immer die neueste Patch-Version innerhalb einer bestimmten **Haupt-/Nebenversion zu verwenden, um die neuesten Leistungs** - und Stabilitätsverbesserungen zu erzielen. Ab ElastiCache Version 6.0 für Redis OSS ElastiCache wird eine einzige Version für jede Redis OSS-Nebenversion angeboten, anstatt mehrere Patch-Versionen anzubieten. ElastiCacheverwaltet automatisch die Patch-Version Ihrer laufenden Cluster und sorgt so für eine verbesserte Leistung und erhöhte Sicherheit.
Wir empfehlen außerdem, regelmäßig auf die neueste Hauptversion zu aktualisieren, da die meisten wichtigen Verbesserungen nicht auf ältere Versionen zurückportiert werden. Da die Verfügbarkeit auf eine neue AWS Region ElastiCache ausgedehnt wird, unterstützt OSS ElastiCache für Redis die beiden jeweils neuesten **Major.Minor-Versionen** für die neue Region. ****Wenn beispielsweise eine neue AWS Region eingeführt wird und die neuesten ElastiCache Major.Minor-Versionen für Redis OSS 7.0 und 6.2 sind, ElastiCache werden die Redis OSS-Versionen **7.0** und **6.2** in der neuen Region unterstützt.****AWS Sobald neuere Major.Minor-Versionen von ElastiCache für Redis OSS veröffentlicht werden, ElastiCache wird weiterhin Unterstützung für die neu veröffentlichten Versionen hinzugefügt. Weitere Informationen zur Auswahl von Regionen für finden Sie unter Regionen ElastiCache und [Verfügbarkeitszonen auswählen](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/RegionsAndAZs.html#SupportedRegions).
Wenn Sie ein Upgrade durchführen, das Haupt- oder Nebenversionen umfasst, beachten Sie bitte die folgende Liste, die Verhaltens- und rückwärtsinkompatible Änderungen enthält, die im Laufe der Zeit mit Redis OSS veröffentlicht wurden.
## Verhalten und abwärtsinkompatible Änderungen von Redis OSS 7.0
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu [Redis OSS 7.0](https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES).
+ `SCRIPT LOAD` und `SCRIPT FLUSH` werden nicht mehr auf Replikate weitergeleitet. Wenn Sie eine gewisse Haltbarkeit für Skripts benötigen, empfehlen wir Ihnen, die Verwendung von [Redis OSS-Funktionen](https://valkey.io/topics/functions-intro/) in Betracht zu ziehen.
+ Pubsub-Kanäle sind jetzt für neue ACL-Benutzer standardmäßig gesperrt.
+ Der `STRALGO`-Befehl wurde durch den `LCS`-Befehl ersetzt.
+ Das Format für `ACL GETUSER` wurde geändert, sodass alle Felder das standardmäßige Zugriffszeichenfolgemuster anzeigen. Wenn Sie Automatisierung mit `ACL GETUSER` verwendet haben, sollten Sie überprüfen, ob beide Formate verarbeitet werden.
+ Die ACL-Kategorien für `SELECT`, `WAIT`, `ROLE`, `LASTSAVE`, `READONLY`, `READWRITE` und `ASKING` haben sich geändert.
+ Der `INFO`-Befehl zeigt jetzt Befehlsstatistiken pro Unterbefehl und anstatt bei den Container-Befehlen in der obersten Ebene an.
+ Die Rückgabewerte der Befehle `LPOP`, `RPOP`, `ZPOPMIN` und `ZPOPMAX` haben sich in bestimmten Randfällen geändert. Wenn Sie diese Befehle verwenden, sollten Sie die Versionshinweise überprüfen und bewerten, ob Sie betroffen sind.
+ Die Befehle `SORT` und `SORT_RO` erfordern jetzt Zugriff auf den gesamten Schlüsselraum, um die Argumente `GET` sowie `BY` verwenden zu können.
## Verhalten und abwärtsinkompatible Änderungen in Redis OSS 6.2
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu [Redis OSS 6.2](https://raw.githubusercontent.com/redis/redis/6.2/00-RELEASENOTES).
+ Die ACL-Flags der Befehle `TIME`, `ECHO`, `ROLE` und `LASTSAVE` wurden geändert. Dies kann dazu führen, dass Befehle, die zuvor gestattet waren, abgelehnt werden und umgekehrt.
**Anmerkung**
Keiner dieser Befehle verändert Daten oder gewährt Zugriff darauf.
+ Beim Upgrade von Redis OSS 6.0 wird die Reihenfolge der key/value Paare geändert, die von einer Map-Antwort an ein Lua-Skript zurückgegeben werden. Wenn Ihre Skripte eine Map verwenden `redis.setresp()` oder zurückgeben (neu in Redis OSS 6.0), sollten Sie die Auswirkungen berücksichtigen, die sich daraus ergeben können, dass das Skript bei Upgrades nicht mehr funktioniert.
## Verhalten von Redis OSS 6.0 und abwärtsinkompatible Änderungen
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu [Redis OSS 6.0](https://raw.githubusercontent.com/redis/redis/6.0/00-RELEASENOTES).
+ Die maximale Anzahl zugelassener Datenbanken wurde von 1,2 Millionen auf 10.000 verringert. Der Standardwert ist 16, und wir raten davon ab, Werte zu verwenden, die viel größer sind, da wir Probleme mit der Leistung und dem Arbeitsspeicher festgestellt haben.
+ Stellen Sie den `AutoMinorVersionUpgrade` Parameter auf yes ein und das Upgrade der Nebenversion ElastiCache wird über Self-Service-Updates verwaltet. Dies wird über Standardkanäle für die Kundenbenachrichtigung über eine Self-Service-Update-Kampagne abgewickelt. Weitere Informationen finden Sie unter [Self-Service-Updates](Self-Service-Updates.md) unter. ElastiCache
## Verhalten und abwärtsinkompatible Änderungen in Redis OSS 5.0
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu [Redis OSS 5.0](https://raw.githubusercontent.com/redis/redis/5.0/00-RELEASENOTES).
+ Skripte werden durch Effekte repliziert, statt das Skript auf dem Replikat erneut auszuführen. Dies verbessert im Allgemeinen die Leistung, kann jedoch die Menge der zwischen primären Replikaten und Replikaten replizierten Daten erhöhen. Es gibt eine Option, um zum vorherigen Verhalten zurückzukehren, die nur in ElastiCache Version 5.0 für Redis OSS verfügbar ist.
+ Wenn Sie ein Upgrade von Redis OSS 4.0 durchführen, geben einige Befehle in LUA-Skripten Argumente in einer anderen Reihenfolge zurück als in früheren Versionen. In Redis OSS 4.0 ordnete Redis OSS einige Antworten lexographisch an, um die Antworten deterministisch zu machen. Diese Reihenfolge wird nicht angewendet, wenn Skripten durch Effekte repliziert werden.
+ In Redis OSS 5.0.3 und höher wird bei Redis OSS bei ElastiCache Instance-Typen mit mehr als 4 ein Teil der I/O-Arbeit auf Hintergrundkerne ausgelagert. VCPUs Dies kann die Leistungsmerkmale von Redis OSS und die Werte einiger Metriken ändern. Weitere Informationen finden Sie unter [Welche Metriken sollte ich überwachen?](CacheMetrics.WhichShouldIMonitor.md), um zu verstehen, ob Sie ändern müssen, welche Metriken Sie sich ansehen.
## Verhalten von Redis OSS 4.0 und abwärtsinkompatible Änderungen
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu [Redis OSS 4.0](https://raw.githubusercontent.com/redis/redis/4.0/00-RELEASENOTES).
+ Slow Log protokolliert jetzt zwei zusätzliche Argumente, den Namen und die Adresse des Clients. Diese Änderung sollte abwärtskompatibel sein, sofern Sie sich nicht explizit darauf verlassen, dass jeder Slow-Log-Eintrag 3 Werte enthält.
+ Der Befehl `CLUSTER NODES` gibt jetzt ein etwas anderes Format zurück, das nicht abwärtskompatibel ist. Wir empfehlen, dass Clients diesen Befehl nicht verwenden, um mehr über die in einem Cluster vorhandenen Knoten zu erfahren, sondern stattdessen `CLUSTER SLOTS` verwenden.
## Vergangenes EOL
### Verhalten von Redis OSS 3.2 und abwärtsinkompatible Änderungen
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu [Redis OSS 3.2](https://raw.githubusercontent.com/redis/redis/3.2/00-RELEASENOTES).
+ Für diese Version sind keine Kompatibilitätsänderungen erforderlich.
Weitere Informationen finden Sie unter [ElastiCache Zeitplan für das Ende der Lebensdauer von Versionen für Redis OSS](engine-versions.md#deprecated-engine-versions).
### Verhalten von Redis OSS 2.8 und abwärtsinkompatible Änderungen
Eine vollständige Liste der Änderungen finden Sie in den Versionshinweisen zu [Redis OSS 2.8](https://raw.githubusercontent.com/redis/redis/2.8/00-RELEASENOTES).
+ Ab Redis OSS 2.8.22 wird Redis OSS AOF für Redis OSS nicht mehr unterstützt. ElastiCache Wir empfehlen die Verwendung von MemoryDB, wenn Daten dauerhaft gespeichert werden müssen.
+ Ab Redis OSS 2.8.22 unterstützt Redis OSS das Anhängen von Replikaten an ElastiCache darin gehostete Primärdateien nicht mehr. ElastiCache Während des Upgrades werden externe Replikate getrennt und sie können keine erneute Verbindung herstellen. Wir empfehlen die Verwendung von clientseitigem Caching, das in Redis OSS 6.0 als Alternative zu externen Replikaten verfügbar ist.
+ Die Befehle `TTL` und `PTTL` geben jetzt -2 zurück, wenn der Schlüssel nicht existiert, und -1, wenn er existiert, aber kein zugehöriges Ablaufdatum hat. Redis OSS 2.6 und frühere Versionen gaben in beiden Fällen -1 zurück.
+ `SORT` mit `ALPHA` sortiert jetzt nach lokalem Standardgebietsschema, wenn keine `STORE`-Option verwendet wird.
Weitere Informationen finden Sie unter [ElastiCache Zeitplan für das Ende der Lebensdauer von Versionen für Redis OSS](engine-versions.md#deprecated-engine-versions).
# Überlegungen zum Upgrade bei der Arbeit mit knotenbasierten Clustern
**Anmerkung**
Die folgenden Überlegungen gelten nur für das Upgrade knotenbasierter Cluster. Sie gelten nicht für Serverless. ElastiCache
**Überlegungen zu Valkey und Redis OSS**
Beachten Sie beim Upgrade eines knotenbasierten Valkey- oder Redis OSS-Clusters Folgendes.
+ Versionsverwaltung der Enginge ist so entwickelt, dass Sie so viel Kontrolle wie möglich darüber haben, wie Patchen erfolgt. ElastiCache behält sich jedoch das Recht vor, Ihren Cluster in Ihrem Namen zu patchen, falls im unwahrscheinlichen Fall eine kritische Sicherheitslücke im System oder in der Cache-Software auftritt.
+ Ab ElastiCache Version 7.2 für Valkey und ElastiCache Version 6.0 für Redis OSS ElastiCache wird für jede Nebenversion eine einzige Version angeboten, anstatt mehrere Patch-Versionen anzubieten.
+ Ab Redis OSS Engine Version 5.0.6 können Sie Ihre Cluster-Version mit minimaler Ausfallzeit aktualisieren. Der Cluster kann während des gesamten Upgrades gelesen und in der Regel auch beschrieben werden, ausgenommen während der Failover-Operation, der nur einige Sekunden dauert.
+ Sie können Ihre ElastiCache Cluster auch mit Versionen vor 5.0.6 aktualisieren. Der Prozess ist identisch, kann jedoch längere Failover-Zeit während der DNS-Ausbreitung (30 Sek. - 1 Min.) verursachen.
+ Ab Redis OSS 7 wird ElastiCache das Umschalten zwischen Valkey oder Redis OSS (Clustermodus deaktiviert) und Valkey oder Redis OSS (Clustermodus aktiviert) unterstützt.
+ Der Upgrade-Prozess ElastiCache für die Amazon for Redis OSS-Engine ist darauf ausgelegt, Ihre vorhandenen Daten bestmöglich beizubehalten, und erfordert eine erfolgreiche Redis OSS-Replikation.
+ Beim Upgrade der Engine ElastiCache werden bestehende Client-Verbindungen beendet. [Um Ausfallzeiten bei Engine-Upgrades zu minimieren, empfehlen wir Ihnen, [bewährte Methoden für Redis OSS-Clients](BestPractices.Clients.redis.md) mit Fehlerwiederholungen und exponentiellem Backoff sowie bewährte Methoden zur Minimierung von Ausfallzeiten während der Wartung zu implementieren.](BestPractices.MinimizeDowntime.md)
+ Sie können beim Upgrade Ihrer Engine kein direktes Upgrade von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis OSS (Clustermodus aktiviert) durchführen. Das folgende Verfahren zeigt Ihnen, wie Sie von Valkey oder Redis OSS (Clustermodus deaktiviert) auf Valkey oder Redis OSS (Clustermodus aktiviert) aktualisieren.
**Um ein Upgrade von einer Valkey- oder Redis OSS-Engine-Version (Cluster-Modus deaktiviert) auf eine Valkey- oder Redis OSS-Engine-Version (Clustermodus aktiviert) durchzuführen**
1. Erstellen Sie eine Sicherungskopie Ihres Valkey- oder Redis OSS-Clusters oder Ihrer Replikationsgruppe (Clustermodus deaktiviert). Weitere Informationen finden Sie unter [Erstellen manueller Backups](backups-manual.md).
1. Verwenden Sie das Backup, um einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mit einem Shard (Knotengruppe) zu erstellen und zu starten. Geben Sie die neue Engine-Version an und aktivieren Sie den Cluster-Modus, wenn Sie den Cluster oder die Replikationsgruppe erstellen. Weitere Informationen finden Sie unter [Tutorial: Seeding eines neuen knotenbasierten Clusters mit einem extern erstellten Backup](backups-seeding-redis.md).
1. Löschen Sie den alten Valkey- oder Redis OSS-Cluster oder die alte Replikationsgruppe (Clustermodus deaktiviert). Für weitere Informationen siehe [Löschen eines Clusters in ElastiCache](Clusters.Delete.md) oder [Löschen einer Replikationsgruppe](Replication.DeletingRepGroup.md).
1. Skalieren Sie den neuen Valkey- oder Redis OSS-Cluster oder die neue Replikationsgruppe (Clustermodus aktiviert) auf die Anzahl der Shards (Knotengruppen), die Sie benötigen. Weitere Informationen finden Sie unter [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md).
+ Beim Upgrade von Hauptversionen der Engine, beispielsweise von 5.0.6 auf 6.0, müssen Sie auch eine neue Parametergruppe auswählen, die mit der neuen Engine-Version kompatibel ist.
+ Für einzelne Redis OSS-Cluster und Cluster mit deaktiviertem Multi-AZ empfehlen wir, Redis OSS ausreichend Speicher zur Verfügung zu stellen, wie unter beschrieben. [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md) In diesen Fällen steht der primäre Knoten während des Upgrade-Prozesses für Serviceanfragen nicht zur Verfügung.
+ Für Redis OSS-Cluster mit aktiviertem Multi-AZ empfehlen wir außerdem, Engine-Upgrades in Zeiten mit geringem eingehendem Schreibverkehr zu planen. Bei einem Upgrade auf Redis OSS 5.0.6 oder höher steht der primäre Cluster während des Upgrade-Vorgangs weiterhin für Serviceanfragen zur Verfügung.
Cluster und Replikationsgruppen mit mehreren Shards werden wie folgt verarbeitet und gepatcht:
+ Alle Shards werden parallel verarbeitet. Es wird jeweils nur eine Upgrade-Operation für einen Shard gleichzeitig durchgeführt.
+ In jedem Shard werden alle Replicas verarbeitet, bevor der Primärknoten verarbeitet wird. Wenn es in einem Shard weniger Replicas gibt, kann der Primärknoten in diesem Shard verarbeitet werden, bevor die Verarbeitung der Replicas in anderen Shards abgeschlossen wird.
+ Die Primärknoten für alle Shards werden seriell verarbeitet. Es erfolgt jeweils nur ein Upgrade für einen Primärknoten gleichzeitig.
+ Wenn die Verschlüsselung in Ihrem aktuellen Cluster oder Ihrer Replikationsgruppe aktiviert ist, können Sie nicht auf eine Engine-Version aktualisieren, die keine Verschlüsselung unterstützt, z. B. von 3.2.6 auf 3.2.10.
**Überlegungen zu Memcached**
Beachten Sie beim Upgrade eines knotenbasierten Memcached-Clusters Folgendes.
+ Versionsverwaltung der Enginge ist so entwickelt, dass Sie so viel Kontrolle wie möglich darüber haben, wie Patchen erfolgt. Behält sich jedoch ElastiCache das Recht vor, Ihren Cluster in Ihrem Namen zu patchen, sollte der unwahrscheinliche Fall eintreten, dass das System oder die Cache-Software eine kritische Sicherheitslücke aufweist.
+ Da die Memcached-Engine keine Persistenz unterstützt, stellen Versions-Upgrades der Memcached-Engine immer einen Störfall dar, bei dem alle Cache-Daten im Cluster gelöscht werden.
# ElastiCache Best Practices und Caching-Strategien
Im Folgenden finden Sie empfohlene Best Practices für Amazon ElastiCache. Durch die Einhaltung dieser Methoden lassen sich die Performance und Zuverlässigkeit des Caches verbessern.
**Topics**
+ [Allgemeine Best Practices](WorkingWithRedis.md)
+ [Bewährte Methoden für die Verwendung von Read Replicas](ReadReplicas.md)
+ [Unterstützte und eingeschränkte Valkey-, Memcached- und Redis OSS-Befehle](SupportedCommands.md)
+ [Konfiguration und Grenzwerte für Valkey und Redis OSS](RedisConfiguration.md)
+ [IPv6 Kundenbeispiele für Valkey, Memcached und Redis OSS](network-type-best-practices.md)
+ [Bewährte Methoden für Kunden (Valkey und Redis OSS)](BestPractices.Clients.redis.md)
+ [Bewährte Methoden für Kunden (Memcached)](BestPractices.Clients.memcached.md)
+ [TLS-fähige ElastiCache Dual-Stack-Cluster](#network-type-configuring-tls-enabled-dual-stack)
+ [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md)
+ [Bewährte Methoden bei der Arbeit mit nodenbasierten Valkey- und Redis OSS-Clustern](BestPractices.SelfDesigned.md)
+ [Caching-Strategien für Memcached](Strategies.md)
# Allgemeine Best Practices
Im Folgenden finden Sie Informationen zu bewährten Methoden für die Verwendung der OSS-Schnittstellen Valkey, Memcached und Redis. ElastiCache
+ **Verwenden Sie Konfigurationen mit aktiviertem Clustermodus — Bei aktiviertem** Clustermodus kann der Cache horizontal skaliert werden, um mehr Speicherplatz und Durchsatz zu erzielen als bei einer Konfiguration mit deaktiviertem Clustermodus. ElastiCache Serverless ist nur in einer Konfiguration mit aktiviertem Clustermodus verfügbar.
+ **Langlebige Verbindungen verwenden** – Das Erstellen einer neuen Verbindung ist teuer und beansprucht Zeit und CPU-Ressourcen aus dem Cache. Verwenden Sie Verbindungen nach Möglichkeit wieder (z. B. mit Verbindungspooling), um diese Kosten für viele Befehle zu amortisieren.
+ **Aus Replikaten lesen — Wenn Sie ElastiCache serverlose Systeme verwenden oder Read Replicas** (knotenbasierte Cluster) bereitgestellt haben, leiten Sie Lesevorgänge direkt an Replikate weiter, um eine bessere Skalierbarkeit und geringere Latenz zu erreichen. and/or Lesevorgänge aus Replikaten sind mit dem Primärknoten letztendlich konsistent.
Vermeiden Sie es in einem knotenbasierten Cluster, Leseanforderungen an eine einzelne Read Replica weiterzuleiten, da Lesevorgänge möglicherweise vorübergehend nicht verfügbar sind, wenn der Knoten ausfällt. Konfigurieren Sie Ihren Client entweder so, dass Leseanfragen an mindestens zwei Read Replicas weitergeleitet werden oder Lesevorgänge an ein einzelnes Replikat und den Primärknoten weitergeleitet werden.
Im ElastiCache serverlosen Modus werden Lesevorgänge, wenn vom Replikat-Port (6380) gelesen wird, nach Möglichkeit in die lokale Availability Zone des Clients geleitet, wodurch die Latenz beim Abrufen reduziert wird. Bei Ausfällen wird automatisch auf die anderen Knoten zurückgegriffen.
+ **Vermeiden Sie teure Befehle** — Vermeiden Sie es, I/O rechenintensive Operationen wie die Befehle und auszuführen. `KEYS` `SMEMBERS` Wir empfehlen diesen Ansatz, da diese Operationen die Last auf dem Cluster erhöhen und Einfluss auf die Performance des Clusters haben. Verwenden Sie stattdessen die Befehle `SCAN` und `SSCAN`.
+ **Befolgen Sie die bewährten Methoden von Lua** – Vermeiden Sie lange laufende Lua-Skripte und deklarieren Sie Schlüssel, die in Lua-Skripten verwendet werden, immer im Voraus. Wir empfehlen diesen Ansatz, um festzustellen, dass im Lua-Skript keine slotübergreifenden Befehle verwendet werden. Vergewissern Sie sich, dass die in Lua-Skripts verwendeten Schlüssel zum gleichen Slot gehören.
+ **Sharded Pub/Sub verwenden** — Wenn Sie Valkey oder Redis OSS verwenden, um pub/sub Workloads mit hohem Durchsatz zu unterstützen, empfehlen wir die Verwendung von [Sharded Pub/Sub](https://valkey.io/topics/pubsub/) (verfügbar mit Valkey und mit Redis OSS 7 oder höher). Herkömmliche Cluster, die pub/sub im Clustermodus aktiviert sind, senden Nachrichten an alle Knoten im Cluster, was zu hohen Werten führen kann. `EngineCPUUtilization` Beachten Sie, dass es sich bei ElastiCache serverlosen Befehlen um herkömmliche Befehle handelt. pub/sub commands internally use sharded pub/sub
**Topics**
# Bewährte Methoden für die Verwendung von Read Replicas
Viele Anwendungen, wie Sitzungsspeicher, Bestenlisten und Empfehlungsmodule, erfordern eine hohe Verfügbarkeit und verarbeiten deutlich mehr Lese- als Schreibvorgänge. Diese Anwendungen können häufig leicht veraltete Daten tolerieren (letztendliche Konsistenz), was bedeutet, dass es akzeptabel ist, wenn verschiedene Benutzer vorübergehend leicht unterschiedliche Versionen derselben Daten sehen. Beispiel:
+ Im Cache gespeicherte Abfrageergebnisse können häufig leicht veraltete Daten tolerieren, insbesondere bei zwischengespeicherten Mustern, bei denen die Quelle der Wahrheit extern ist.
+ In einer Gaming-Bestenliste wirkt sich eine Verzögerung von einigen Sekunden bei aktualisierten Ergebnissen häufig nicht wesentlich auf die Benutzererfahrung aus.
+ Bei Sitzungsspeichern wirken sich geringfügige Verzögerungen bei der Übertragung von Sitzungsdaten zwischen Replikaten selten auf die Anwendungsfunktionalität aus.
+ Empfehlungs-Engines verwenden in der Regel historische Datenanalysen, sodass Konsistenz in Echtzeit weniger wichtig ist.
Letztendliche Konsistenz bedeutet, dass alle Replikatknoten irgendwann dieselben Daten zurückgeben, sobald der Replikationsprozess abgeschlossen ist, normalerweise innerhalb von Millisekunden. Für solche Anwendungsfälle ist die Implementierung von Read Replicas eine effektive Strategie, um die Latenz beim Lesen aus Ihrer Instance zu reduzieren. ElastiCache
Die Verwendung von Read Replicas in Amazon ElastiCache kann erhebliche Leistungsvorteile bieten durch:
**Verbesserte Leseskalierbarkeit**
+ Verteilt Lesevorgänge auf mehrere Replikatknoten
+ Lädt den Lesetraffic vom primären Knoten ab
+ Reduziert die Leselatenz, indem Anfragen von geografisch näher gelegenen Replikaten bearbeitet werden
**Optimierte Leistung des Primärknotens**
+ Weist Ressourcen des primären Knotens für Schreiboperationen zu
+ Reduziert den Verbindungsaufwand auf dem Primärknoten
+ Verbessert die Schreibleistung und sorgt für bessere Antwortzeiten in Zeiten mit hohem Datenverkehr
## Verwenden von Read from Replica in Serverless ElastiCache
ElastiCache Serverless bietet zwei verschiedene Endpunkte für unterschiedliche Konsistenzanforderungen. Die beiden Endpunkte verwenden denselben DNS-Namen, aber unterschiedliche Ports. Um den read-from-replica Port verwenden zu können, müssen Sie den Zugriff auf beide Ports von Ihrer Client-Anwendung aus autorisieren, indem Sie [die Sicherheitsgruppen und Netzwerkzugriffskontrolllisten Ihrer VPC konfigurieren](set-up.md#elasticache-install-grant-access-VPN).
**Primärer Endpunkt (Port 6379)**
+ Wird für Operationen verwendet, die sofortige Konsistenz erfordern
+ Garantiert das Lesen der meisten up-to-date Daten
+ Am besten für kritische Transaktionen und Schreibvorgänge
+ Erforderlich für Schreiboperationen
+ Beispiel: `test-12345.serverless.use1.cache.amazonaws.com:6379`
**Latenzoptimierter Endpunkt (Port 6380)**
+ Optimiert für Lesevorgänge, die eine eventuelle Konsistenz tolerieren
+ Wenn möglich, leitet ElastiCache Serverless Leseanfragen automatisch an den Replikatknoten in der lokalen Availability Zone des Clients weiter. Diese Optimierung sorgt für eine geringere Latenz, da die zusätzliche Netzwerklatenz vermieden wird, die beim Abrufen von Daten von einem Knoten in einer anderen Availability Zone entsteht.
+ ElastiCache Serverless wählt automatisch verfügbare Knoten in anderen Zonen aus, wenn ein lokaler Knoten nicht verfügbar ist
+ Beispiel: `test-12345.serverless.use1.cache.amazonaws.com:6380`
+ Clients wie Glide und Lettuce erkennen Lesevorgänge automatisch und leiten sie an den latenzoptimierten Endpunkt weiter, wenn Sie die Konfiguration „Read from Replica“ angeben. Wenn Ihr Client die Routing-Konfiguration nicht unterstützt (z. B. Valkey-Java und ältere Jedis-Versionen), müssen Sie den richtigen Port und die richtige Client-Konfiguration definieren, um aus Replikaten zu lesen.
## Verbindung herstellen, um Repliken in Serverless zu lesen — Valkey und Glide ElastiCache
Der folgende Codeausschnitt zeigt, wie Sie Read from Replica für ElastiCache Serverless in der Valkey-Glide-Bibliothek konfigurieren können. Sie müssen keinen Port für das Lesen von Replikaten angeben, aber Sie müssen die Routing-Konfiguration konfigurieren. `ReadFrom.PREFER_REPLICA`
```
package glide.examples;
import glide.api.GlideClusterClient;
import glide.api.logging.Logger;
import glide.api.models.configuration.GlideClusterClientConfiguration;
import glide.api.models.configuration.NodeAddress;
import glide.api.models.exceptions.ClosingException;
import glide.api.models.exceptions.ConnectionException;
import glide.api.models.exceptions.TimeoutException;
import glide.api.models.configuration.ReadFrom;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutionException;
public class ClusterExample {
public static void main(String[] args) {
// Set logger configuration
Logger.setLoggerConfig(Logger.Level.INFO);
GlideClusterClient client = null;
try {
System.out.println("Connecting to Valkey Glide...");
// Configure the Glide Client
GlideClusterClientConfiguration config = GlideClusterClientConfiguration.builder()
.address(NodeAddress.builder()
.host("your-endpoint")
.port(6379)
.build())
.useTLS(true)
.readFrom(ReadFrom.PREFER_REPLICA)
.build();
// Create the GlideClusterClient
client = GlideClusterClient.createClient(config).get();
System.out.println("Connected successfully.");
// Perform SET operation
CompletableFuture setResponse = client.set("key", "value");
System.out.println("Set key 'key' to 'value': " + setResponse.get());
// Perform GET operation
CompletableFuture getResponse = client.get("key");
System.out.println("Get response for 'key': " + getResponse.get());
// Perform PING operation
CompletableFuture pingResponse = client.ping();
System.out.println("PING response: " + pingResponse.get());
} catch (ClosingException | ConnectionException | TimeoutException | ExecutionException e) {
System.err.println("An exception occurred: ");
e.printStackTrace();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
// Close the client connection
if (client != null) {
try {
client.close();
System.out.println("Client connection closed.");
} catch (ClosingException | ExecutionException e) {
System.err.println("Error closing client: " + e.getMessage());
}
}
}
}
}
```
# Unterstützte und eingeschränkte Valkey-, Memcached- und Redis OSS-Befehle
## Unterstützte Valkey- und Redis OSS-Befehle
**Unterstützte Valkey- und Redis OSS-Befehle**
Die folgenden Valkey- und Redis OSS-Befehle werden von serverlosen Caches unterstützt. Zusätzlich zu diesen Befehlen werden außerdem diese [Unterstützte Valkey- und Redis OSS-BefehleJSON-Befehle](json-list-commands.md) unterstützt.
Informationen zu Bloom-Filter-Befehlen finden Sie unter [Bloom-Filter-Befehle](BloomFilters.md#SupportedCommandsBloom)
**Bitmap-Befehle**
+ `BITCOUNT`
Zählt die Anzahl der gesetzten Bits (Populationszählung) in einer Zeichenfolge.
[Weitere Informationen](https://valkey.io/commands/bitcount/)
+ `BITFIELD`
Führt willkürliche Bitfeld-Ganzzahl-Operationen für Zeichenfolgen aus.
[Weitere Informationen](https://valkey.io/commands/bitfield/)
+ `BITFIELD_RO`
Führt willkürliche, schreibgeschützte Bitfeld-Ganzzahl-Operationen für Zeichenfolgen aus.
[Weitere Informationen](https://valkey.io/commands/bitfield_ro/)
+ `BITOP`
Führt bitweise Operationen an mehreren Zeichenfolgen aus und speichert das Ergebnis.
[Weitere Informationen](https://valkey.io/commands/bitop/)
+ `BITPOS`
Findet das erste gesetzte (1) oder nicht gesetzte Bit (0) in einer Zeichenfolge.
[Weitere Informationen](https://valkey.io/commands/bitpos/)
+ `GETBIT`
Gibt einen Bitwert nach Offset zurück.
[Weitere Informationen](https://valkey.io/commands/getbit/)
+ `SETBIT`
Setzt oder löscht das Bit am Offset des Zeichenfolgenwerts. Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/setbit/)
**Befehle zur Clusterverwaltung**
+ `CLUSTER COUNTKEYSINSLOT`
Gibt die Anzahl der Schlüssel in einem Hash-Slot zurück.
[Weitere Informationen](https://valkey.io/commands/cluster-countkeysinslot/)
+ `CLUSTER GETKEYSINSLOT`
Gibt die Schlüsselnamen in einem Hash-Slot zurück.
[Weitere Informationen](https://valkey.io/commands/cluster-getkeysinslot/)
+ `CLUSTER INFO`
Gibt Informationen zum Status eines Knotens zurück. Gibt in einem Serverless-Cache den Status des einzelnen virtuellen „Shard“ zurück, der dem Client angezeigt wird.
[Weitere Informationen](https://valkey.io/commands/cluster-info/)
+ `CLUSTER KEYSLOT`
Gibt den Hash-Slot für einen Schlüssel zurück.
[Weitere Informationen](https://valkey.io/commands/cluster-keyslot/)
+ `CLUSTER MYID`
Gibt die ID eines Knotens zurück. Gibt in einem Serverless-Cache den Status des einzelnen virtuellen „Shard“ zurück, der dem Client angezeigt wird.
[Weitere Informationen](https://valkey.io/commands/cluster-myid/)
+ `CLUSTER NODES`
Gibt die Clusterkonfiguration für einen Knoten zurück. Gibt in einem Serverless-Cache den Status des einzelnen virtuellen „Shard“ zurück, der dem Client angezeigt wird.
[Weitere Informationen](https://valkey.io/commands/cluster-nodes/)
+ `CLUSTER REPLICAS`
Listet die Replikatknoten eines Hauptknotens auf. Gibt in einem Serverless-Cache den Status des einzelnen virtuellen „Shard“ zurück, der dem Client angezeigt wird.
[Weitere Informationen](https://valkey.io/commands/cluster-replicas/)
+ `CLUSTER SHARDS`
Gibt die Zuordnung von Cluster-Slots zu Shards zurück. Gibt in einem Serverless-Cache den Status des einzelnen virtuellen „Shard“ zurück, der dem Client angezeigt wird.
[Weitere Informationen](https://valkey.io/commands/cluster-shards/)
+ `CLUSTER SLOTS`
Gibt die Zuordnung von Cluster-Slots zu Knoten zurück. Gibt in einem Serverless-Cache den Status des einzelnen virtuellen „Shard“ zurück, der dem Client angezeigt wird.
[Weitere Informationen](https://valkey.io/commands/cluster-slots/)
+ `CLUSTER SLOT-STATS`
Ermöglicht die Nachverfolgung von Metriken pro Steckplatz für Schlüsselanzahl, CPU-Auslastung, eingehende Netzwerk-Bytes und ausgehende Netzwerk-Bytes.
[Weitere Informationen](https://valkey.io/commands/cluster-slot-stats/)
+ `READONLY`
Ermöglicht schreibgeschützte Abfragen für eine Verbindung zu einem Valkey- oder Redis OSS-Cluster-Replikatknoten.
[Weitere Informationen](https://valkey.io/commands/readonly/)
+ `READWRITE`
Aktiviert Lese-/Schreibabfragen für eine Verbindung zu einem Valkey- oder Redis OSS-Cluster-Replikatknoten.
[Weitere Informationen](https://valkey.io/commands/readwrite/)
+ `SCRIPT SHOW`
Gibt den ursprünglichen Quellcode eines Skripts im Skript-Cache zurück.
[Weitere Informationen](https://valkey.io/commands/script-show/)
**Befehle zur Verbindungsverwaltung**
+ `AUTH`
Authentifiziert die Verbindung.
[Weitere Informationen](https://valkey.io/commands/auth/)
+ `CLIENT GETNAME`
Gibt den Namen der Verbindung zurück.
[Weitere Informationen](https://valkey.io/commands/client-getname/)
+ `CLIENT REPLY`
Weist den Server an, ob er auf Befehle antworten soll.
[Weitere Informationen](https://valkey.io/commands/client-reply/)
+ `CLIENT SETNAME`
Legt den Verbindungsnamen fest.
[Weitere Informationen](https://valkey.io/commands/client-setname/)
+ `ECHO`
Gibt die angegebene Zeichenfolge zurück.
[Weitere Informationen](https://valkey.io/commands/echo/)
+ `HELLO`
Handshakes mit dem Valkey- oder Redis OSS-Server.
[Weitere Informationen](https://valkey.io/commands/hello/)
+ `PING`
Gibt die Lebhaftigkeitsantwort des Servers zurück.
[Weitere Informationen](https://valkey.io/commands/ping/)
+ `QUIT`
Schließt die Verbindung.
[Weitere Informationen](https://valkey.io/commands/quit/)
+ `RESET`
Setzt die Verbindung zurück.
[Weitere Informationen](https://valkey.io/commands/reset/)
+ `SELECT`
Ändert die ausgewählte Datenbank.
[Weitere Informationen](https://valkey.io/commands/select/)
**Generische Befehle**
+ `COPY`
Kopiert den Wert eines Schlüssels in einen neuen Schlüssel.
[Weitere Informationen](https://valkey.io/commands/copy/)
+ `DEL`
Löscht einen oder mehrere Schlüssel.
[Weitere Informationen](https://valkey.io/commands/del/)
+ `DUMP`
Gibt eine serialisierte Darstellung des in einem Schlüssel gespeicherten Werts zurück.
[Weitere Informationen](https://valkey.io/commands/dump/)
+ `EXISTS`
Ermittelt, ob ein oder mehrere Schlüssel existieren.
[Weitere Informationen](https://valkey.io/commands/exists/)
+ `EXPIRE`
Legt die Ablaufzeit eines Schlüssels in Sekunden fest.
[Weitere Informationen](https://valkey.io/commands/expire/)
+ `EXPIREAT`
Legt die Ablaufzeit eines Schlüssels auf einen Unix-Zeitstempel fest.
[Weitere Informationen](https://valkey.io/commands/expireat/)
+ `EXPIRETIME`
Gibt die Ablaufzeit eines Schlüssels als Unix-Zeitstempel zurück.
[Weitere Informationen](https://valkey.io/commands/expiretime/)
+ `PERSIST`
Entfernt die Ablaufzeit eines Schlüssels.
[Weitere Informationen](https://valkey.io/commands/persist/)
+ `PEXPIRE`
Legt die Ablaufzeit eines Schlüssels in Millisekunden fest.
[Weitere Informationen](https://valkey.io/commands/pexpire/)
+ `PEXPIREAT`
Legt die Ablaufzeit eines Schlüssels auf einen Unix-Millisekunden-Zeitstempel fest.
[Weitere Informationen](https://valkey.io/commands/pexpireat/)
+ `PEXPIRETIME`
Gibt die Ablaufzeit eines Schlüssels als Unix-Millisekunden-Zeitstempel zurück.
[Weitere Informationen](https://valkey.io/commands/pexpiretime/)
+ `PTTL`
Gibt die Ablaufzeit eines Schlüssels in Millisekunden zurück.
[Weitere Informationen](https://valkey.io/commands/pttl/)
+ `RANDOMKEY`
Gibt einen zufälligen Schlüsselnamen aus der Datenbank zurück.
[Weitere Informationen](https://valkey.io/commands/randomkey/)
+ `RENAME`
Benennt einen Schlüssel um und überschreibt das Ziel.
[Weitere Informationen](https://valkey.io/commands/rename/)
+ `RENAMENX`
Benennt einen Schlüssel nur um, wenn der Name des Zielschlüssels nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/renamenx/)
+ `RESTORE`
Erstellt einen Schlüssel aus der serialisierten Darstellung eines Werts.
[Weitere Informationen](https://valkey.io/commands/restore/)
+ `SCAN`
Iteriert über die Schlüsselnamen in der Datenbank.
[Weitere Informationen](https://valkey.io/commands/scan/)
+ `SORT`
Sortiert die Elemente in einer Liste, einem Set oder einem sortierten Set und speichert optional das Ergebnis.
[Weitere Informationen](https://valkey.io/commands/sort/)
+ `SORT_RO`
Gibt die sortierten Elemente einer Liste, eines Sets oder eines sortierten Sets zurück.
[Weitere Informationen](https://valkey.io/commands/sort_ro/)
+ `TOUCH`
Gibt die Anzahl der vorhandenen Schlüssel aus den angegebenen Schlüsseln zurück, nachdem der Zeitpunkt des letzten Zugriffs aktualisiert wurde.
[Weitere Informationen](https://valkey.io/commands/touch/)
+ `TTL`
Gibt die Ablaufzeit eines Schlüssels in Sekunden zurück.
[Weitere Informationen](https://valkey.io/commands/ttl/)
+ `TYPE`
Ermittelt den Typ des Wertes, der in einem Schlüssel gespeichert ist.
[Weitere Informationen](https://valkey.io/commands/type/)
+ `UNLINK`
Löscht asynchron einen oder mehrere Schlüssel.
[Weitere Informationen](https://valkey.io/commands/unlink/)
**Geodatenbefehle**
+ `GEOADD`
Fügt einem Geodatenindex ein oder mehrere Mitglieder hinzu. Der Schlüssel wird erstellt, wenn er nicht existiert.
[Weitere Informationen](https://valkey.io/commands/geoadd/)
+ `GEODIST`
Gibt den Abstand zwischen zwei Mitgliedern eines Geodatenindex zurück.
[Weitere Informationen](https://valkey.io/commands/geodist/)
+ `GEOHASH`
Gibt Elemente aus einem Geodatenindex als Geohash-Zeichenfolgen zurück.
[Weitere Informationen](https://valkey.io/commands/geohash/)
+ `GEOPOS`
Gibt den Längen- und Breitengrad von Elementen aus einem Geodatenindex zurück.
[Weitere Informationen](https://valkey.io/commands/geopos/)
+ `GEORADIUS`
Fragt einen Geodatenindex nach Elementen ab, die sich innerhalb einer Entfernung von einer Koordinate befinden, und speichert optional das Ergebnis.
[Weitere Informationen](https://valkey.io/commands/georadius/)
+ `GEORADIUS_RO`
Gibt Elemente aus einem Geodatenindex zurück, die sich innerhalb einer Entfernung von einer Koordinate befinden.
[Weitere Informationen](https://valkey.io/commands/georadius_ro/)
+ `GEORADIUSBYMEMBER`
Fragt einen Geodatenindex nach Elementen ab, die sich innerhalb einer Entfernung von einem Element befinden, und speichert optional das Ergebnis.
[Weitere Informationen](https://valkey.io/commands/georadiusbymember/)
+ `GEORADIUSBYMEMBER_RO`
Gibt Elemente aus einem Geodatenindex zurück, die sich innerhalb einer Entfernung von einem Element befinden.
[Weitere Informationen](https://valkey.io/commands/georadiusbymember_ro/)
+ `GEOSEARCH`
Fragt einen Geodatenindex nach Elementen ab, die sich in einem Bereich eines Felds oder Kreises befinden.
[Weitere Informationen](https://valkey.io/commands/geosearch/)
+ `GEOSEARCHSTORE`
Fragt einen Geodatenindex nach Elementen ab, die sich in einem Bereich eines Felds oder Kreises befinden, und speichert optional das Ergebnis.
[Weitere Informationen](https://valkey.io/commands/geosearchstore/)
**Hash-Befehle**
+ `HDEL`
Löscht ein oder mehrere Felder und deren Werte aus einem Hash. Löscht den Hash, wenn keine Felder mehr vorhanden sind.
[Weitere Informationen](https://valkey.io/commands/hdel/)
+ `HEXISTS`
Ermittelt, ob ein Feld in einem Hash existiert.
[Weitere Informationen](https://valkey.io/commands/hexists/)
+ `HGET`
Gibt den Wert eines Felds in einem Hash zurück.
[Weitere Informationen](https://valkey.io/commands/hget/)
+ `HGETALL`
Gibt alle Felder und Werte in einem Hash zurück.
[Weitere Informationen](https://valkey.io/commands/hgetall/)
+ `HINCRBY`
Inkrementiert den Ganzzahlwert eines Felds in einem Hash um eine Zahl. Verwendet 0 als Anfangswert, wenn das Feld nicht existiert.
[Weitere Informationen](https://valkey.io/commands/hincrby/)
+ `HINCRBYFLOAT`
Inkrementiert den Gleitkommawert eines Felds um eine Zahl. Verwendet 0 als Anfangswert, wenn das Feld nicht existiert.
[Weitere Informationen](https://valkey.io/commands/hincrbyfloat/)
+ `HKEYS`
Gibt alle Felder in einem Hash zurück.
[Weitere Informationen](https://valkey.io/commands/hkeys/)
+ `HLEN`
Gibt die Anzahl der Felder in einem Hash zurück.
[Weitere Informationen](https://valkey.io/commands/hlen/)
+ `HMGET`
Gibt die Werte aller Felder in einem Hash zurück.
[Weitere Informationen](https://valkey.io/commands/hmget/)
+ `HMSET`
Legt die Werte mehrerer Felder fest.
[Weitere Informationen](https://valkey.io/commands/hmset/)
+ `HRANDFIELD`
Gibt ein oder mehrere zufällige Felder aus einem Hash zurück.
[Weitere Informationen](https://valkey.io/commands/hrandfield/)
+ `HSCAN`
Iteriert über Felder und Werte eines Hashs.
[Weitere Informationen](https://valkey.io/commands/hscan/)
+ `HSET`
Erstellt oder ändert den Wert eines Felds in einem Hash.
[Weitere Informationen](https://valkey.io/commands/hset/)
+ `HSETNX`
Legt den Wert eines Felds in einem Hash nur fest, wenn das Feld nicht existiert.
[Weitere Informationen](https://valkey.io/commands/hsetnx/)
+ `HSTRLEN`
Gibt die Länge des Werts eines Felds zurück.
[Weitere Informationen](https://valkey.io/commands/hstrlen/)
+ `HVALS`
Gibt alle Werte in einem Hash zurück.
[Weitere Informationen](https://valkey.io/commands/hvals/)
**HyperLogLog Befehle**
+ `PFADD`
Fügt einem Schlüssel Elemente hinzu. HyperLogLog Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/pfadd/)
+ `PFCOUNT`
Gibt die ungefähre Kardinalität der Menge (n) zurück, die von dem/den HyperLogLog Schlüssel (n) beobachtet wurde.
[Weitere Informationen](https://valkey.io/commands/pfcount/)
+ `PFMERGE`
Führt einen oder mehrere HyperLogLog Werte zu einem einzigen Schlüssel zusammen.
[Weitere Informationen](https://valkey.io/commands/pfmerge/)
**Listenbefehle**
+ `BLMOVE`
Löscht ein Element aus einer Liste, verschiebt es in eine andere Liste und gibt es zurück. Blockiert, bis ein Element anderweitig verfügbar ist. Löscht die Liste, wenn das letzte Element verschoben wurde.
[Weitere Informationen](https://valkey.io/commands/blmove/)
+ `BLMPOP`
Löscht das erste Element aus einer von mehreren Listen. Blockiert, bis ein Element anderweitig verfügbar ist. Löscht die Liste, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/blmpop/)
+ `BLPOP`
Entfernt das erste Element in einer Liste und gibt es zurück. Blockiert, bis ein Element anderweitig verfügbar ist. Löscht die Liste, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/blpop/)
+ `BRPOP`
Entfernt das letzte Element in einer Liste und gibt es zurück. Blockiert, bis ein Element anderweitig verfügbar ist. Löscht die Liste, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/brpop/)
+ `BRPOPLPUSH`
Löscht ein Element aus einer Liste, verschiebt es in eine andere Liste und gibt es zurück. Blockiert, bis ein Element anderweitig verfügbar ist. Löscht die Liste, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/brpoplpush/)
+ `LINDEX`
Gibt ein Element anhand seines Index aus einer Liste zurück.
[Weitere Informationen](https://valkey.io/commands/lindex/)
+ `LINSERT`
Fügt ein Element vor oder nach einem anderen Element in eine Liste ein.
[Weitere Informationen](https://valkey.io/commands/linsert/)
+ `LLEN`
Gibt die Länge einer Liste zurück.
[Weitere Informationen](https://valkey.io/commands/llen/)
+ `LMOVE`
Gibt ein Element zurück, nachdem es aus einer Liste entfernt und in eine andere verschoben wurde. Löscht die Liste, wenn das letzte Element verschoben wurde.
[Weitere Informationen](https://valkey.io/commands/lmove/)
+ `LMPOP`
Gibt mehrere Elemente aus einer Liste zurück, nachdem sie entfernt wurden. Löscht die Liste, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/lmpop/)
+ `LPOP`
Gibt die ersten Elemente in einer Liste zurück, nachdem sie entfernt wurde. Löscht die Liste, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/lpop/)
+ `LPOS`
Gibt den Index übereinstimmender Elemente in einer Liste zurück.
[Weitere Informationen](https://valkey.io/commands/lpos/)
+ `LPUSH`
Stellt einer Liste ein oder mehrere Elemente voran. Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/lpush/)
+ `LPUSHX`
Stellt einer Liste nur dann ein oder mehrere Elemente voran, wenn die Liste existiert.
[Weitere Informationen](https://valkey.io/commands/lpushx/)
+ `LRANGE`
Gibt einen Bereich von Elementen aus einer Liste zurück.
[Weitere Informationen](https://valkey.io/commands/lrange/)
+ `LREM`
Entfernt Elemente aus einer Liste. Löscht die Liste, wenn das letzte Element entfernt wurde.
[Weitere Informationen](https://valkey.io/commands/lrem/)
+ `LSET`
Legt den Wert eines Elements in einer Liste anhand seines Index fest.
[Weitere Informationen](https://valkey.io/commands/lset/)
+ `LTRIM`
Entfernt Elemente am Anfang und Ende einer Liste. Löscht die Liste, wenn alle Elemente gekürzt wurden.
[Weitere Informationen](https://valkey.io/commands/ltrim/)
+ `RPOP`
Gibt die letzten Elemente einer Liste zurück und entfernt sie. Löscht die Liste, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/rpop/)
+ `RPOPLPUSH`
Gibt das letzte Element einer Liste zurück, nachdem es entfernt und in eine andere Liste verschoben wurde. Löscht die Liste, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/rpoplpush/)
+ `RPUSH`
Fügt ein oder mehrere Elemente an eine Liste an. Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/rpush/)
+ `RPUSHX`
Fügt ein Element nur dann an eine Liste an, wenn die Liste existiert.
[Weitere Informationen](https://valkey.io/commands/rpushx/)
**Pub/Sub-Befehle**
**Anmerkung**
PUBSUB-Befehle verwenden intern Sharded PUBSUB, sodass Kanalnamen gemischt werden.
+ `PUBLISH`
Sendet eine Nachricht an einen Kanal.
[Weitere Informationen](https://valkey.io/commands/publish/)
+ `PUBSUB CHANNELS`
Gibt die aktiven Kanäle zurück.
[Weitere Informationen](https://valkey.io/commands/pubsub-channels/)
+ `PUBSUB NUMSUB`
Gibt die Anzahl der Subscriber von Kanälen zurück.
[Weitere Informationen](https://valkey.io/commands/pubsub-numsub/)
+ `PUBSUB SHARDCHANNELS`
Gibt die aktiven Shard-Kanäle zurück.
[Weitere Informationen](https://valkey.io/commands/pubsub-shardchannels/)
+ `PUBSUB SHARDNUMSUB`
Gibt die Anzahl der Subscriber von Shard-Kanälen zurück.
[Weitere Informationen](https://valkey.io/commands/pubsub-shardnumsub/)
+ `SPUBLISH`
Sendet eine Nachricht an einen Shard-Kanal.
[Weitere Informationen](https://valkey.io/commands/spublish/)
+ `SSUBSCRIBE`
Lauscht nach Nachrichten, die auf Shard-Kanälen veröffentlicht wurden.
[Weitere Informationen](https://valkey.io/commands/ssubscribe/)
+ `SUBSCRIBE`
Lauscht nach Nachrichten, die auf Kanälen veröffentlicht wurden.
[Weitere Informationen](https://valkey.io/commands/subscribe/)
+ `SUNSUBSCRIBE`
Beendet das Lauschen nach Nachrichten, die an Shard-Kanäle gesendet wurden.
[Weitere Informationen](https://valkey.io/commands/sunsubscribe/)
+ `UNSUBSCRIBE`
Beendet das Lauschen nach Nachrichten, die an Kanäle gesendet wurden.
[Weitere Informationen](https://valkey.io/commands/unsubscribe/)
**Befehle zur Skripterstellung**
+ `EVAL`
Führt ein serverseitiges Lua-Skript aus.
[Weitere Informationen](https://valkey.io/commands/eval/)
+ `EVAL_RO`
Führt ein schreibgeschütztes serverseitiges Lua-Skript aus.
[Weitere Informationen](https://valkey.io/commands/eval_ro/)
+ `EVALSHA`
Führt ein serverseitiges Lua-Skript per Digest aus. SHA1
[Weitere Informationen](https://valkey.io/commands/evalsha/)
+ `EVALSHA_RO`
Führt ein schreibgeschütztes serverseitiges Lua-Skript per Digest aus. SHA1
[Weitere Informationen](https://valkey.io/commands/evalsha_ro/)
+ `SCRIPT EXISTS`
Ermittelt, ob serverseitige Lua-Skripte im Skriptcache vorhanden sind.
[Weitere Informationen](https://valkey.io/commands/script-exists/)
+ `SCRIPT FLUSH`
Derzeit wird ein No-Op-Skript-Cache vom Service verwaltet.
[Weitere Informationen](https://valkey.io/commands/script-flush/)
+ `SCRIPT LOAD`
Lädt ein serverseitiges Lua-Skript in den Skript-Cache.
[Weitere Informationen](https://valkey.io/commands/script-load/)
**Befehle zur Serververwaltung**
**Anmerkung**
Bei der Verwendung knotenbasierter ElastiCache Cluster für Valkey und Redis OSS müssen vom Client Flush-Befehle an jeden Primärserver gesendet werden, um alle Schlüssel zu leeren. ElastiCache Serverless für Valkey und Redis OSS funktioniert unterschiedlich, da es die zugrunde liegende Cluster-Topologie wegabstrahiert. Das Ergebnis ist, dass in ElastiCache Serverless `FLUSHDB` und mit `FLUSHALL` Befehlen immer alle Schlüssel im Cluster geleert werden. Aus diesem Grund können Flush-Befehle nicht in eine serverlose Transaktion aufgenommen werden.
+ `ACL CAT`
Listet die ACL-Kategorien oder die Befehle innerhalb einer Kategorie auf.
[Weitere Informationen](https://valkey.io/commands/acl-cat/)
+ `ACL GENPASS`
Generiert ein pseudozufälliges, sicheres Passwort, das zur Identifizierung von ACL-Benutzern verwendet werden kann.
[Weitere Informationen](https://valkey.io/commands/acl-genpass/)
+ `ACL GETUSER`
Listet die ACL-Regeln eines Benutzers auf.
[Weitere Informationen](https://valkey.io/commands/acl-getuser/)
+ `ACL LIST`
Gibt die effektiven Regeln im ACL-Dateiformat aus.
[Weitere Informationen](https://valkey.io/commands/acl-list/)
+ `ACL USERS`
Listet alle ACL-Benutzer auf.
[Weitere Informationen](https://valkey.io/commands/acl-users/)
+ `ACL WHOAMI`
Gibt den authentifizierten Benutzernamen der aktuellen Verbindung zurück.
[Weitere Informationen](https://valkey.io/commands/acl-whoami/)
+ `DBSIZE`
Gibt die Anzahl der Schlüssel in der aktuell ausgewählten Datenbank zurück. Es kann nicht garantiert werden, dass diese Operation in allen Slots atomar abläuft.
[Weitere Informationen](https://valkey.io/commands/dbsize/)
+ `COMMAND`
Gibt detaillierte Informationen zu allen Befehlen zurück.
[Weitere Informationen](https://valkey.io/commands/command/)
+ `COMMAND COUNT`
Gibt eine Anzahl von Befehlen zurück.
[Weitere Informationen](https://valkey.io/commands/command-count/)
+ `COMMAND DOCS`
Gibt durch Dokumente belegte Informationen zu einem, mehreren oder allen Befehlen zurück.
[Weitere Informationen](https://valkey.io/commands/command-docs/)
+ `COMMAND GETKEYS`
Extrahiert die Schlüsselnamen aus einem willkürlichen Befehl.
[Weitere Informationen](https://valkey.io/commands/command-getkeys/)
+ `COMMAND GETKEYSANDFLAGS`
Extrahiert die Schlüsselnamen und Zugriffs-Flags für einen willkürlichen Befehl.
[Weitere Informationen](https://valkey.io/commands/command-getkeysandflags/)
+ `COMMAND INFO`
Gibt Informationen zu einem, mehreren oder allen Befehlen zurück.
[Weitere Informationen](https://valkey.io/commands/command-info/)
+ `COMMAND LIST`
Gibt eine Liste von Befehlsnamen zurück.
[Weitere Informationen](https://valkey.io/commands/command-list/)
+ `COMMANDLOG`
Ein Container für Befehlsprotokollbefehle.
[Weitere Informationen](https://valkey.io/commands/commandlog/)
+ `COMMANDLOG GET`
Gibt die Einträge des angegebenen Befehlsprotokolls zurück.
[Weitere Informationen](https://valkey.io/commands/commandlog-get/)
+ `COMMANDLOG HELP`
Zeigt hilfreichen Text zu den verschiedenen Unterbefehlen an.
[Weitere Informationen](https://valkey.io/commands/commandlog-help/)
+ `COMMANDLOG LEN`
Gibt die Anzahl der Einträge im angegebenen Typ von Befehlsprotokoll zurück.
[Weitere Informationen](https://valkey.io/commands/commandlog-len/)
+ `COMMANDLOG RESET`
Löscht alle Einträge aus dem angegebenen Typ von Befehlsprotokoll.
[Weitere Informationen](https://valkey.io/commands/commandlog-reset/)
+ `FLUSHALL`
Entfernt alle Schlüssel aus allen Datenbanken. Es kann nicht garantiert werden, dass diese Operation in allen Slots atomar abläuft.
[Weitere Informationen](https://valkey.io/commands/flushall/)
+ `FLUSHDB`
Entfernt alle Schlüssel aus der aktuellen Datenbank. Es kann nicht garantiert werden, dass diese Operation in allen Slots atomar abläuft.
[Weitere Informationen](https://valkey.io/commands/flushdb/)
+ `INFO`
Gibt Informationen und Statistiken über den Server zurück.
[Weitere Informationen](https://valkey.io/commands/info/)
+ `LOLWUT`
Zeigt Computergrafiken und die Valkey- oder Redis-OSS-Version an.
[Weitere Informationen](https://valkey.io/commands/lolwut/)
+ `ROLE`
Gibt die Replikationsrolle zurück.
[Weitere Informationen](https://valkey.io/commands/role/)
+ `TIME`
Gibt die Serverzeit zurück.
[Weitere Informationen](https://valkey.io/commands/time/)
**Set-Befehle**
+ `SADD`
Fügt einem Set ein oder mehrere Mitglieder hinzu. Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/sadd/)
+ `SCARD`
Gibt die Anzahl der Mitglieder in einem Set zurück.
[Weitere Informationen](https://valkey.io/commands/scard/)
+ `SDIFF`
Gibt die Differenz zwischen mehreren Sets zurück.
[Weitere Informationen](https://valkey.io/commands/sdiff/)
+ `SDIFFSTORE`
Speichert die Differenz zwischen mehreren Sets in einem Schlüssel.
[Weitere Informationen](https://valkey.io/commands/sdiffstore/)
+ `SINTER`
Gibt den Schnittpunkt mehrerer Sets zurück.
[Weitere Informationen](https://valkey.io/commands/sinter/)
+ `SINTERCARD`
Gibt die Anzahl der Mitglieder des Schnittpunkts mehrerer Sets zurück.
[Weitere Informationen](https://valkey.io/commands/sintercard/)
+ `SINTERSTORE`
Speichert den Schnittpunkt mehrerer Sets in einem Schlüssel.
[Weitere Informationen](https://valkey.io/commands/sinterstore/)
+ `SISMEMBER`
Ermittelt, ob ein Mitglied zu einem Set gehört.
[Weitere Informationen](https://valkey.io/commands/sismember/)
+ `SMEMBERS`
Gibt alle Mitglieder eines Sets zurück.
[Weitere Informationen](https://valkey.io/commands/smembers/)
+ `SMISMEMBER`
Ermittelt, ob mehrere Mitglieder zu einem Set gehören.
[Weitere Informationen](https://valkey.io/commands/smismember/)
+ `SMOVE`
Verschiebt ein Mitglied von einem Set in ein anderes.
[Weitere Informationen](https://valkey.io/commands/smove/)
+ `SPOP`
Gibt ein oder mehrere zufällige Mitglieder aus einer Gruppe zurück, nachdem sie entfernt wurden. Löscht das Set, wenn das letzte Mitglied gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/spop/)
+ `SRANDMEMBER`
Ruft ein oder mehrere zufällige Mitglieder aus einem Set ab.
[Weitere Informationen](https://valkey.io/commands/srandmember/)
+ `SREM`
Entfernt ein oder mehrere Mitglieder aus einem Set. Löscht das Set, wenn das letzte Mitglied entfernt wurde.
[Weitere Informationen](https://valkey.io/commands/srem/)
+ `SSCAN`
Iteriert über Mitglieder eines Sets.
[Weitere Informationen](https://valkey.io/commands/sscan/)
+ `SUNION`
Gibt die Vereinigung mehrerer Sets zurück.
[Weitere Informationen](https://valkey.io/commands/sunion/)
+ `SUNIONSTORE`
Speichert die Vereinigung mehrerer Sets in einem Schlüssel.
[Weitere Informationen](https://valkey.io/commands/sunionstore/)
**Befehle zu Sorted Sets**
+ `BZMPOP`
Entfernt ein Mitglied aus einem oder mehreren sortierten Sets und gibt es nach Score zurück. Blockiert, bis ein Element anderweitig verfügbar ist. Löscht das sortierte Set, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/bzmpop/)
+ `BZPOPMAX`
Entfernt das Element mit dem höchsten Score aus einem oder mehreren sortierten Sets und gibt es zurück. Blockiert, bis ein Element anderweitig verfügbar ist. Löscht das sortierte Set, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/bzpopmax/)
+ `BZPOPMIN`
Entfernt das Element mit dem niedrigsten Score aus einem oder mehreren sortierten Sets und gibt es zurück. Blockiert, bis ein Element anderweitig verfügbar ist. Löscht das sortierte Set, wenn das letzte Element gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/bzpopmin/)
+ `ZADD`
Fügt einem sortierten Set ein oder mehrere Mitglieder hinzu oder aktualisiert deren Scores. Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/zadd/)
+ `ZCARD`
Gibt die Anzahl der Mitglieder in einem sortierten Set zurück.
[Weitere Informationen](https://valkey.io/commands/zcard/)
+ `ZCOUNT`
Gibt die Anzahl der Mitglieder in einem sortierten Set zurück, deren Scores innerhalb eines bestimmten Bereichs liegen.
[Weitere Informationen](https://valkey.io/commands/zcount/)
+ `ZDIFF`
Gibt den Unterschied zwischen mehreren sortierten Sets zurück.
[Weitere Informationen](https://valkey.io/commands/zdiff/)
+ `ZDIFFSTORE`
Speichert den Unterschied mehrerer sortierter Sets in einem Schlüssel.
[Weitere Informationen](https://valkey.io/commands/zdiffstore/)
+ `ZINCRBY`
Inkrementiert den Score eines Mitglieds in einem sortierten Set.
[Weitere Informationen](https://valkey.io/commands/zincrby/)
+ `ZINTER`
Gibt den Schnittpunkt mehrerer sortierter Sets zurück.
[Weitere Informationen](https://valkey.io/commands/zinter/)
+ `ZINTERCARD`
Gibt die Anzahl der Mitglieder des Schnittpunkts mehrerer sortierter Sets zurück.
[Weitere Informationen](https://valkey.io/commands/zintercard/)
+ `ZINTERSTORE`
Speichert den Schnittpunkt mehrerer sortierter Sets in einem Schlüssel.
[Weitere Informationen](https://valkey.io/commands/zinterstore/)
+ `ZLEXCOUNT`
Gibt die Anzahl der Elemente in einem sortierten Set innerhalb eines lexikografischen Bereichs zurück.
[Weitere Informationen](https://valkey.io/commands/zlexcount/)
+ `ZMPOP`
Gibt die Elemente mit dem höchsten oder niedrigsten Score aus einem oder mehreren sortierten Sets zurück, nachdem sie entfernt wurden. Löscht das sortierte Set, wenn das letzte Mitglied gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/zmpop/)
+ `ZMSCORE`
Gibt den Score eines oder mehrerer Mitglieder eines sortierten Sets zurück.
[Weitere Informationen](https://valkey.io/commands/zmscore/)
+ `ZPOPMAX`
Gibt die Mitglieder mit dem höchsten Score aus einem sortierten Set zurück, nachdem sie entfernt wurden. Löscht das sortierte Set, wenn das letzte Mitglied gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/zpopmax/)
+ `ZPOPMIN`
Gibt die Mitglieder mit dem niedrigsten Score aus einem sortierten Set zurück, nachdem sie entfernt wurden. Löscht das sortierte Set, wenn das letzte Mitglied gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/zpopmin/)
+ `ZRANDMEMBER`
Gibt ein oder mehrere zufällige Mitglieder aus einem sortierten Set zurück.
[Weitere Informationen](https://valkey.io/commands/zrandmember/)
+ `ZRANGE`
Gibt Elemente in einem sortierten Set innerhalb eines Indexbereichs zurück.
[Weitere Informationen](https://valkey.io/commands/zrange/)
+ `ZRANGEBYLEX`
Gibt Elemente in einem sortierten Set innerhalb eines lexikografischen Bereichs zurück.
[Weitere Informationen](https://valkey.io/commands/zrangebylex/)
+ `ZRANGEBYSCORE`
Gibt Elemente in einem sortierten Set innerhalb eines Score-Bereichs zurück.
[Weitere Informationen](https://valkey.io/commands/zrangebyscore/)
+ `ZRANGESTORE`
Speichert einen Bereich von Elementen aus einem sortierten Set in einem Schlüssel.
[Weitere Informationen](https://valkey.io/commands/zrangestore/)
+ `ZRANK`
Gibt den Index eines Elements in einem sortierten Set zurück, sortiert nach aufsteigenden Scores.
[Weitere Informationen](https://valkey.io/commands/zrank/)
+ `ZREM`
Entfernt ein oder mehrere Elemente aus einem sortierten Set. Löscht das sortierte Set, wenn alle Elemente entfernt wurden.
[Weitere Informationen](https://valkey.io/commands/zrem/)
+ `ZREMRANGEBYLEX`
Entfernt Elemente in einem sortierten Set innerhalb eines lexikografischen Bereichs. Löscht das sortierte Set, wenn alle Elemente entfernt wurden.
[Weitere Informationen](https://valkey.io/commands/zremrangebylex/)
+ `ZREMRANGEBYRANK`
Entfernt Elemente in einem sortierten Sete innerhalb eines Indexbereichs. Löscht das sortierte Set, wenn alle Elemente entfernt wurden.
[Weitere Informationen](https://valkey.io/commands/zremrangebyrank/)
+ `ZREMRANGEBYSCORE`
Entfernt Elemente aus einem sortierten Set innerhalb eines Score-Bereichs. Löscht das sortierte Set, wenn alle Elemente entfernt wurden.
[Weitere Informationen](https://valkey.io/commands/zremrangebyscore/)
+ `ZREVRANGE`
Gibt Elemente in einem sortierten Set innerhalb eines Indexbereichs in umgekehrter Reihenfolge zurück.
[Weitere Informationen](https://valkey.io/commands/zrevrange/)
+ `ZREVRANGEBYLEX`
Gibt Elemente in einem sortierten Set innerhalb eines lexikografischen Bereichs in umgekehrter Reihenfolge zurück.
[Weitere Informationen](https://valkey.io/commands/zrevrangebylex/)
+ `ZREVRANGEBYSCORE`
Gibt Elemente in einem sortierten Set innerhalb eines Score-Bereichs in umgekehrter Reihenfolge zurück.
[Weitere Informationen](https://valkey.io/commands/zrevrangebyscore/)
+ `ZREVRANK`
Gibt den Index eines Elements in einem sortierten Set zurück, sortiert nach absteigenden Scores.
[Weitere Informationen](https://valkey.io/commands/zrevrank/)
+ `ZSCAN`
Iteriert über Elemente und Scores eines sortierten Sets.
[Weitere Informationen](https://valkey.io/commands/zscan/)
+ `ZSCORE`
Gibt den Score eines Elements in einem sortierten Set zurück.
[Weitere Informationen](https://valkey.io/commands/zscore/)
+ `ZUNION`
Gibt die Vereinigung mehrerer sortierter Sets zurück.
[Weitere Informationen](https://valkey.io/commands/zunion/)
+ `ZUNIONSTORE`
Speichert die Vereinigung mehrerer sortierter Sets in einem Schlüssel.
[Weitere Informationen](https://valkey.io/commands/zunionstore/)
**Stream-Befehle**
+ `XACK`
Gibt die Anzahl der Nachrichten zurück, die vom Mitglied der Verbrauchergruppe eines Streams erfolgreich bestätigt wurden.
[Weitere Informationen](https://valkey.io/commands/xack/)
+ `XADD`
Hängt eine neue Nachricht an einen Stream an. Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/xadd/)
+ `XAUTOCLAIM`
Ändert oder erwirbt den Besitz von Nachrichten in einer Verbrauchergruppe, als ob die Nachrichten als Mitglied der Verbrauchergruppe zugestellt würden.
[Weitere Informationen](https://valkey.io/commands/xautoclaim/)
+ `XCLAIM`
Ändert oder erwirbt den Besitz einer Nachricht in einer Verbrauchergruppe, als ob die Nachricht als Mitglied der Verbrauchergruppe zugestellt würde.
[Weitere Informationen](https://valkey.io/commands/xclaim/)
+ `XDEL`
Gibt die Anzahl der Nachrichten zurück, nachdem sie aus einem Stream entfernt wurden.
[Weitere Informationen](https://valkey.io/commands/xdel/)
+ `XGROUP CREATE`
Erstellt eine Verbrauchergruppe.
[Weitere Informationen](https://valkey.io/commands/xgroup-create/)
+ `XGROUP CREATECONSUMER`
Erstellt einen Verbraucher in einer Verbrauchergruppe.
[Weitere Informationen](https://valkey.io/commands/xgroup-createconsumer/)
+ `XGROUP DELCONSUMER`
Löscht einen Verbraucher aus einer Verbrauchergruppe.
[Weitere Informationen](https://valkey.io/commands/xgroup-delconsumer/)
+ `XGROUP DESTROY`
Löscht eine Verbrauchergruppe.
[Weitere Informationen](https://valkey.io/commands/xgroup-destroy/)
+ `XGROUP SETID`
Legt die zuletzt zugestellte ID einer Verbrauchergruppe fest.
[Weitere Informationen](https://valkey.io/commands/xgroup-setid/)
+ `XINFO CONSUMERS`
Gibt eine Liste der Verbraucher in einer Verbrauchergruppe zurück.
[Weitere Informationen](https://valkey.io/commands/xinfo-consumers/)
+ `XINFO GROUPS`
Gibt eine Liste der Verbrauchergruppen eines Streams zurück.
[Weitere Informationen](https://valkey.io/commands/xinfo-groups/)
+ `XINFO STREAM`
Gibt Informationen zu einem Stream zurück.
[Weitere Informationen](https://valkey.io/commands/xinfo-stream/)
+ `XLEN`
Gibt die Anzahl der Nachrichten in einem Stream zurück.
[Weitere Informationen](https://valkey.io/commands/xlen/)
+ `XPENDING`
Gibt die Informationen und Einträge aus der Liste der ausstehenden Einträge einer Stream-Verbrauchergruppe zurück.
[Weitere Informationen](https://valkey.io/commands/xpending/)
+ `XRANGE`
Gibt die Nachrichten aus einem Stream innerhalb eines Bereichs von zurück. IDs
[Weitere Informationen](https://valkey.io/commands/xrange/)
+ `XREAD`
Gibt Nachrichten aus mehreren Streams zurück, deren IDs Anzahl größer als die angeforderten ist. Blockiert, bis eine Nachricht anderweitig verfügbar ist.
[Weitere Informationen](https://valkey.io/commands/xread/)
+ `XREADGROUP`
Gibt neue oder historische Nachrichten aus einem Stream für einen Verbraucher in einer Gruppe zurück. Blockiert, bis eine Nachricht anderweitig verfügbar ist.
[Weitere Informationen](https://valkey.io/commands/xreadgroup/)
+ `XREVRANGE`
Gibt die Nachrichten aus einem Stream innerhalb eines Bereichs von IDs in umgekehrter Reihenfolge zurück.
[Weitere Informationen](https://valkey.io/commands/xrevrange/)
+ `XTRIM`
Löscht Nachrichten am Anfang eines Streams.
[Weitere Informationen](https://valkey.io/commands/xtrim/)
**Zeichenfolgenbefehle**
+ `APPEND`
Hängt eine Zeichenfolge an den Wert eines Schlüssels an. Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/append/)
+ `DECR`
Dekrementiert den Ganzzahlwert eines Schlüssels um eins. Verwendet 0 als Anfangswert, wenn der Schlüssel nicht existiert.
[Weitere Informationen](https://valkey.io/commands/decr/)
+ `DECRBY`
Dekrementiert eine Zahl vom Ganzzahlwert eines Schlüssels. Verwendet 0 als Anfangswert, wenn der Schlüssel nicht existiert.
[Weitere Informationen](https://valkey.io/commands/decrby/)
+ `GET`
Gibt den Zeichenfolgenwert eines Schlüssels zurück.
[Weitere Informationen](https://valkey.io/commands/get/)
+ `GETDEL`
Gibt den Zeichenfolgenwert eines Schlüssels zurück, nachdem der Schlüssel gelöscht wurde.
[Weitere Informationen](https://valkey.io/commands/getdel/)
+ `GETEX`
Gibt den Zeichenfolgenwert eines Schlüssels zurück, nachdem dessen Ablaufzeit festgelegt wurde.
[Weitere Informationen](https://valkey.io/commands/getex/)
+ `GETRANGE`
Gibt eine Teilzeichenfolge der Zeichenfolge zurück, die in einem Schlüssel gespeichert ist.
[Weitere Informationen](https://valkey.io/commands/getrange/)
+ `GETSET`
Gibt den vorherigen Zeichenfolgenwert eines Schlüssels zurück, nachdem dieser auf einen neuen Wert festgelegt wurde.
[Weitere Informationen](https://valkey.io/commands/getset/)
+ `INCR`
Inkrementiert den Ganzzahlwert eines Schlüssels um eins. Verwendet 0 als Anfangswert, wenn der Schlüssel nicht existiert.
[Weitere Informationen](https://valkey.io/commands/incr/)
+ `INCRBY`
Inkrementiert den Ganzzahlwert eines Schlüssels um eine Zahl. Verwendet 0 als Anfangswert, wenn der Schlüssel nicht existiert.
[Weitere Informationen](https://valkey.io/commands/incrby/)
+ `INCRBYFLOAT`
Inkrementiert den Gleitkommawert eines Schlüssels um eine Zahl. Verwendet 0 als Anfangswert, wenn der Schlüssel nicht existiert.
[Weitere Informationen](https://valkey.io/commands/incrbyfloat/)
+ `LCS`
Findet die längste gemeinsame Teilzeichenfolge.
[Weitere Informationen](https://valkey.io/commands/lcs/)
+ `MGET`
Gibt atomar die Zeichenfolgenwerte eines oder mehrerer Schlüssel zurück.
[Weitere Informationen](https://valkey.io/commands/mget/)
+ `MSET`
Erstellt oder ändert atomar die Zeichenfolgenwerte eines oder mehrerer Schlüssel.
[Weitere Informationen](https://valkey.io/commands/mset/)
+ `MSETNX`
Ändert die Zeichenfolgenwerte eines oder mehrerer Schlüssel nur dann atomar, wenn alle Schlüssel nicht existieren.
[Weitere Informationen](https://valkey.io/commands/msetnx/)
+ `PSETEX`
Legt sowohl den Zeichenfolgenwert als auch die Ablaufzeit eines Schlüssels in Millisekunden fest. Der Schlüssel wird erstellt, wenn er nicht existiert.
[Weitere Informationen](https://valkey.io/commands/psetex/)
+ `SET`
Legt den Zeichenfolgenwert eines Schlüssels fest, wobei sein Typ ignoriert wird. Der Schlüssel wird erstellt, wenn er nicht existiert.
[Weitere Informationen](https://valkey.io/commands/set/)
+ `SETEX`
Legt den Zeichenfolgenwert und die Ablaufzeit eines Schlüssels fest. Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/setex/)
+ `SETNX`
Legt den Zeichenfolgenwert eines Schlüssels nur fest, wenn der Schlüssel nicht existiert.
[Weitere Informationen](https://valkey.io/commands/setnx/)
+ `SETRANGE`
Überschreibt einen Teil eines Zeichenfolgenwerts durch einen anderen um einen Offset. Erstellt den Schlüssel, sofern er nicht vorhanden ist.
[Weitere Informationen](https://valkey.io/commands/setrange/)
+ `STRLEN`
Gibt die Länge eines Zeichenfolgenwerts zurück.
[Weitere Informationen](https://valkey.io/commands/strlen/)
+ `SUBSTR`
Gibt eine Teilzeichenfolge aus einem Zeichenfolgenwert zurück.
[Weitere Informationen](https://valkey.io/commands/substr/)
**Transaktionsbefehle**
+ `DISCARD`
Verwirft eine Transaktion.
[Weitere Informationen](https://valkey.io/commands/discard/)
+ `EXEC`
Führt alle Befehle in einer Transaktion aus.
[Weitere Informationen](https://valkey.io/commands/exec/)
+ `MULTI`
Startet eine Transaktion.
[Weitere Informationen](https://valkey.io/commands/multi/)
## Eingeschränkte Valkey- und Redis OSS-Befehle
ElastiCache Schränkt den Zugriff auf bestimmte Cache-Engine-spezifische Befehle ein, die erweiterte Rechte erfordern, um ein Managed Service-Erlebnis zu bieten. Für Caches, auf denen Redis OSS ausgeführt wird, sind die folgenden Befehle nicht verfügbar:
+ `acl setuser`
+ `acl load`
+ `acl save`
+ `acl deluser`
+ `bgrewriteaof`
+ `bgsave`
+ `cluster addslot`
+ `cluster addslotsrange`
+ `cluster bumpepoch`
+ `cluster delslot`
+ `cluster delslotsrange `
+ `cluster failover `
+ `cluster flushslots `
+ `cluster forget `
+ `cluster links`
+ `cluster meet`
+ `cluster setslot`
+ `config`
+ `debug`
+ `migrate`
+ `psync`
+ `replicaof`
+ `save`
+ `slaveof`
+ `shutdown`
+ `sync`
Darüber hinaus sind die folgenden Befehle für Serverless-Caches nicht verfügbar:
+ `acl log`
+ `client caching`
+ `client getredir`
+ `client id`
+ `client info`
+ `client kill`
+ `client list`
+ `client no-evict`
+ `client pause`
+ `client tracking`
+ `client trackinginfo`
+ `client unblock`
+ `client unpause`
+ `cluster count-failure-reports`
+ `commandlog`
+ `commandlog get`
+ `commandlog help`
+ `commandlog len`
+ `commandlog reset`
+ `fcall`
+ `fcall_ro`
+ `function`
+ `function delete`
+ `function dump`
+ `function flush`
+ `function help`
+ `function kill`
+ `function list`
+ `function load`
+ `function restore`
+ `function stats`
+ `keys`
+ `lastsave`
+ `latency`
+ `latency doctor`
+ `latency graph`
+ `latency help`
+ `latency histogram`
+ `latency history`
+ `latency latest`
+ `latency reset`
+ `memory`
+ `memory doctor`
+ `memory help`
+ `memory malloc-stats`
+ `memory purge`
+ `memory stats`
+ `memory usage`
+ `monitor`
+ `move`
+ `object`
+ `object encoding`
+ `object freq`
+ `object help`
+ `object idletime`
+ `object refcount`
+ `pfdebug`
+ `pfselftest`
+ `psubscribe`
+ `pubsub numpat`
+ `punsubscribe`
+ `script kill`
+ `slowlog`
+ `slowlog get`
+ `slowlog help`
+ `slowlog len`
+ `slowlog reset`
+ `swapdb`
+ `wait`
## Unterstützte Memcached-Befehle
ElastiCache Serverless for Memcached unterstützt alle [Memcached-Befehle](https://github.com/memcached/memcached/wiki/Commands) in Open Source Memcached 1.6 mit Ausnahme der folgenden:
+ Client-Verbindungen erfordern TLS, weshalb das UDP-Protokoll nicht unterstützt wird.
+ Das Binärprotokoll wird nicht unterstützt, da es in Memcached 1.6 offiziell [veraltet](https://github.com/memcached/memcached/wiki/ReleaseNotes160) ist.
+ `GET/GETS`-Befehle sind auf 16 KB begrenzt, um einen möglichen DoS-Angriff auf den Server durch Abrufen einer großen Anzahl von Schlüsseln zu vermeiden.
+ Ein verzögerter `flush_all`-Befehl wird mit `CLIENT_ERROR` zurückgewiesen.
+ Befehle, die die Engine konfigurieren oder interne Informationen zum Engine-Status oder zu Protokollen preisgeben, werden nicht unterstützt. Dazu gehören:
+ Für `STATS`-Befehle werden nur `stats` und `stats reset` unterstützt. Für andere Varianten wird `ERROR` zurückgegeben.
+ `lru / lru_crawler` – Änderung der LRU- und LRU-Crawler-Einstellungen
+ `watch` – beobachtet Memcached-Serverprotokolle
+ `verbosity` – konfiguriert die Protokollstufe des Servers
+ `me`- Der Befehl meta debug (me) wird nicht unterstützt
# Konfiguration und Grenzwerte für Valkey und Redis OSS
Die Valkey- und Redis OSS-Engines bieten jeweils eine Reihe von Konfigurationsparametern, von denen einige ElastiCache für Redis OSS modifizierbar sind und andere nicht modifizierbar sind, um eine stabile Leistung und Zuverlässigkeit zu gewährleisten.
## Serverless-Caches
Für serverlose Caches werden keine Parametergruppen verwendet und die gesamte Valkey- oder Redis-OSS-Konfiguration kann nicht geändert werden. Die folgenden Valkey- oder Redis-OSS-Parameter sind vorhanden:
****
| Name | Details | Description |
| --- | --- | --- |
| acl-pubsub-default | `allchannels` | Standardberechtigungen für Pub/Sub-Kanäle für ACL-Benutzer im Cache. |
| client-output-buffer-limit | `normal 0 0 0` `pubsub 32mb 8mb 60` | Normale Clients haben kein Pufferlimit. PUB/SUB Clients werden getrennt, wenn sie den 32 MiB-Backlog oder den 8 MiB-Backlog für 60 Sekunden überschreiten. |
| client-query-buffer-limit | 1 GiB | Die maximale Größe eines einzelnen Client-Abfragepuffers. Darüber hinaus können Kunden keine Anfrage mit mehr als 3.999 Argumenten stellen. |
| cluster-allow-pubsubshard-when-down | yes | Dadurch kann der Cache Pub/Sub-Datenverkehr bereitstellen, während der Cache teilweise ausgefallen ist. |
| cluster-allow-reads-when-down | yes | Dadurch kann der Cache Lesedatenverkehr bereitstellen, während der Cache teilweise ausgefallen ist. |
| cluster-enabled | yes | Für alle Serverless-Caches ist der Clustermodus aktiviert, sodass sie ihre Daten transparent auf mehrere Backend-Shards partitionieren können. Alle Slots werden den Clients so angezeigt, als gehörten sie einem einzigen virtuellen Knoten. |
| cluster-require-full-coverage | no | Wenn der Keyspace teilweise ausgefallen ist (d. h. auf mindestens einen Hash-Slot kann nicht zugegriffen werden), akzeptiert der Cache weiterhin Abfragen für den Teil des Keyspace, der noch abgedeckt ist. Der gesamte Keyspace wird immer von einem einzigen virtuellen Knoten in cluster slots „abgedeckt“. |
| lua-time-limit | 5000 | Die maximale Ausführungszeit für ein Lua-Skript in Millisekunden, bevor Maßnahmen zum Stoppen des Skripts ergriffen ElastiCache werden. *Wenn sie überschritten `lua-time-limit` wird, geben alle Valkey- oder Redis OSS-Befehle möglicherweise einen Fehler der Form \$1\$1\$1\$1-BUSY zurück.* *Da dieser Status viele wichtige Valkey- oder Redis-OSS-Operationen stören kann, ElastiCache wird zunächst ein SCRIPT KILL-Befehl ausgegeben.* Wenn dies nicht erfolgreich ist, ElastiCache wird Valkey oder Redis OSS zwangsweise neu gestartet. |
| maxclients | 65000 | Die maximale Anzahl von Clients, die zu jedem beliebigen Zeitpunkt mit dem Cache verbunden sein können. Weitere Verbindungen können erfolgreich hergestellt werden oder auch nicht. |
| maxmemory-policy | volatile-lru | Elemente mit einem TTL-Satz werden nach einer Schätzung least-recently-used (LRU) gelöscht, wenn das Speicherlimit eines Caches erreicht ist. |
| notify-keyspace-events | (eine leere Zeichenfolge) | Keyspace-Ereignisse werden in Serverless-Caches derzeit nicht unterstützt. |
| port | Primärer Port: 6379 Leseport: 6380 | Serverless-Caches kündigen zwei Ports mit demselben Hostnamen an. Der primäre Port lässt Schreib- und Lesevorgänge zu, wohingegen der Leseport mithilfe des Befehls READONLY letztendlich konsistente Lesevorgänge mit niedrigerer Latenz ermöglicht. |
| proto-max-bulk-len | 512 MiB | Die maximale Größe einer einzelnen Elementanforderung. |
| timeout | 0 | Zu einer bestimmten Leerlaufzeit werden die Verbindungen mit Clients nicht gewaltsam getrennt, sie können jedoch aus Gründen des Lastausgleichs im stabilen Zustand getrennt werden. |
Darüber hinaus gelten die folgenden Limits:
****
| Name | Details | Description |
| --- | --- | --- |
| Größe pro Cache | 5.000 GiB | Maximale Datenmenge, die pro serverlosem Cache gespeichert werden kann. |
| Größe pro Steckplatz | 32 GiB | Die maximale Größe eines einzelnen Valkey- oder Redis OSS-Hash-Slots. Clients, die versuchen, mehr Daten auf einem einzelnen Valkey- oder Redis-OSS-Steckplatz zu speichern, lösen die Räumungsrichtlinie für den Steckplatz aus, und wenn keine Schlüssel entfernt werden können, wird ein Fehler wegen Speichermangel () angezeigt. OOM |
| ECPU pro Cache | 15.000.000 ECPU/Sekunde | ElastiCache Metrisch für Verarbeitungseinheiten (ECPU) Die Anzahl der von Ihren Anfragen ECPUs verbrauchten Daten hängt von der vCPU vCPU-Zeit und der Menge der übertragenen Daten ab. |
| ECPU pro Steckplatz | 30.000 bis 90.000 ECPU/Sekunde | Maximal 30.000 ECPUs/second pro Steckplatz oder 90.000 ECPUs/second bei Verwendung von Read from Replica mit READONLY-Verbindungen. |
| Argumente pro Anfrage | 3.999 | Maximale Anzahl von Argumenten pro Anfrage. Clients, die mehr Argumente pro Anfrage senden, erhalten eine Fehlermeldung. |
| Länge des Schlüsselnamens | 4 KiB | Die maximale Größe für einen einzelnen Valkey- oder Redis-OSS-Schlüssel oder Kanalnamen. Clients, die auf Schlüssel verweisen, die größer sind, wird eine Fehlermeldung angezeigt. |
| Größe des Lua-Skripts | 4 MiB | Die maximale Größe eines einzelnen Valkey- oder Redis OSS-Lua-Skripts. Versuche, ein Lua-Skript zu laden, das größer ist als dieses, führen zu einer Fehlermeldung. |
## Knotenbasierte Cluster
Informationen zu knotenbasierten Clustern finden Sie unter [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis) Die Standardwerte der Konfigurationsparameter und die konfigurierbaren Werte. Die Standardwerte werden generell empfohlen, es sei denn, Sie haben einen bestimmten Anwendungsfall, bei dem sie außer Kraft gesetzt werden müssen.
# IPv6 Kundenbeispiele für Valkey, Memcached und Redis OSS
ElastiCache ist mit Valkey, Memcached und Redis OSS kompatibel. Das bedeutet, dass Clients, die IPv6 Verbindungen unterstützen, in der Lage sein sollten, eine Verbindung zu Clustern herzustellen, die für Memcached IPv6 aktiviert sind ElastiCache . Bei der Interaktion mit IPv6 aktivierten Ressourcen gibt es einige Vorsichtsmaßnahmen, die es zu beachten gilt.
Empfehlungen zur Konfiguration von [Valkey- und Redis OSS-Clients für Ressourcen finden Sie im Blogbeitrag Best Practices](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) für Valkey- und Redis-Clients im AWS Datenbank-Blog. ElastiCache
Im Folgenden finden Sie bewährte Methoden für die Interaktion mit IPv6 aktivierten ElastiCache Ressourcen mithilfe häufig verwendeter Open-Source-Clientbibliotheken.
## Validierte Kunden mit Valkey und Redis OSS
ElastiCache ist mit Valkey und dem Open-Source-Redis OSS kompatibel. Das bedeutet, dass Valkey- und Open-Source-Redis-OSS-Clients, die IPv6 Verbindungen unterstützen, in der Lage sein sollten, eine Verbindung zu für Redis IPv6 aktivierten ElastiCache OSS-Clustern herzustellen. Darüber hinaus wurden mehrere der beliebtesten Python- und Java-Clients speziell getestet und validiert, sodass sie mit allen unterstützten Netzwerktypkonfigurationen (IPv4 nur, IPv6 nur und Dual Stack) funktionieren.
Die folgenden Clients wurden speziell dafür validiert, dass sie mit allen unterstützten Netzwerktypkonfigurationen für Valkey und Redis OSS funktionieren.
Validierte Clients:
+ [Redis Py ()](https://github.com/redis/redis-py) – [4.1.2](https://github.com/redis/redis-py/tree/v4.1.2)
+ [Lettuce](https://lettuce.io/) – [Version: 6.1.6.RELEASE](https://github.com/lettuce-io/lettuce-core/tree/6.1.6.RELEASE)
+ [Jedis](https://github.com/redis/jedis) – [Version: 3.6.0](https://github.com/redis/jedis/tree/jedis-3.6.0)
# Bewährte Methoden für Kunden (Valkey und Redis OSS)
Lernen Sie bewährte Methoden für gängige Szenarien kennen und folgen Sie den Codebeispielen einiger der beliebtesten Open-Source-Clientbibliotheken von Valkey und Redis OSS (redis-py und Lettuce) sowie von Best Practices für die Interaktion mit ElastiCache Ressourcen mit häufig verwendeten Open-Source-Memcached-Clientbibliotheken. PHPRedis
**Topics**
+ [Große Anzahl von Verbindungen (Valkey und Redis OSS)](BestPractices.Clients.Redis.Connections.md)
+ [Cluster-Client-Erkennung und exponentielles Backoff (Valkey und Redis OSS)](BestPractices.Clients.Redis.Discovery.md)
+ [Konfigurieren Sie ein clientseitiges Timeout (Valkey und Redis OSS)](BestPractices.Clients.Redis.ClientTimeout.md)
+ [Konfigurieren Sie ein serverseitiges Leerlauf-Timeout (Valkey und Redis OSS)](BestPractices.Clients.Redis.ServerTimeout.md)
+ [Lua-Skripte](BestPractices.Clients.Redis.LuaScripts.md)
+ [Speichern großer zusammengesetzter Artikel (Valkey und Redis OSS)](BestPractices.Clients.Redis.LargeItems.md)
+ [Konfiguration des Lettuce-Clients (Valkey und Redis OSS)](BestPractices.Clients-lettuce.md)
+ [Konfiguration eines bevorzugten Protokolls für Dual-Stack-Cluster (Valkey und Redis OSS)](#network-type-configuring-dual-stack-redis)
# Große Anzahl von Verbindungen (Valkey und Redis OSS)
Serverlose Caches und individuelle Caches ElastiCache für Redis OSS-Knoten unterstützen bis zu 65.000 gleichzeitige Client-Verbindungen. Zur Optimierung der Leistung empfehlen wir jedoch, dass Client-Anwendungen nicht ständig mit diesem Verbindungsaufkommen arbeiten. Valkey und Redis OSS verfügen jeweils über einen Single-Thread-Prozess, der auf einer Ereignisschleife basiert, in der eingehende Client-Anfragen sequentiell bearbeitet werden. Das bedeutet, dass die Antwortzeit eines bestimmten Clients mit zunehmender Anzahl verbundener Clients länger wird.
Sie können die folgenden Maßnahmen ergreifen, um einen Verbindungsengpass auf einem Valkey- oder Redis OSS-Server zu vermeiden:
+ Führen Sie Lesevorgänge von Read Replicas aus durch. Dies kann durch die Verwendung der ElastiCache Leser-Endpunkte im deaktivierten Clustermodus oder durch die Verwendung von Replikaten für Lesevorgänge im aktivierten Clustermodus, einschließlich eines serverlosen Caches, erreicht werden.
+ Verteilen Sie den Schreibdatenverkehr auf mehrere Primärknoten. Es gibt zwei Methoden dafür: Sie können einen Valkey- oder Redis-OSS-Cluster mit mehreren Shards und einem Client verwenden, der den Clustermodus unterstützt. Sie können auch im deaktivierten Cluster-Modus mit clientseitigem Sharding auf mehrere Primärknoten schreiben. Dies erfolgt automatisch in einem Serverless-Cache.
+ Verwenden Sie einen Verbindungspool, sofern dieser in Ihrer Client-Bibliothek verfügbar ist.
Im Allgemeinen ist das Erstellen einer TCP-Verbindung im Vergleich zu typischen Valkey- oder Redis OSS-Befehlen ein rechenintensiver Vorgang. Beispielsweise ist die Bearbeitung einer SET/GET Anfrage um eine Größenordnung schneller, wenn eine bestehende Verbindung wiederverwendet wird. Durch die Verwendung eines Client-Verbindungspools mit begrenzter Größe wird der Aufwand für die Verbindungsverwaltung reduziert. Außerdem wird dadurch die Anzahl der gleichzeitig eingehenden Verbindungen von der Client-Anwendung begrenzt.
Das folgende Codebeispiel PHPRedis zeigt, dass für jede neue Benutzeranfrage eine neue Verbindung erstellt wird:
```
$redis = new Redis();
if ($redis->connect($HOST, $PORT) != TRUE) {
//ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
Wir haben diesen Code in einer Schleife auf einer Amazon Elastic Compute Cloud (Amazon EC2) -Instance verglichen, die mit einem Graviton2 (m6g.2xlarge) für Redis OSS-Knoten verbunden ist. ElastiCache Client und Server wurden in derselben Availability Zone platziert. Die durchschnittliche Latenz des gesamten Vorgangs betrug 2,82 Millisekunden.
Beim Aktualisieren des Codes und bei Verwendung persistenter Verbindungen sowie eines Verbindungspools betrug die durchschnittliche Latenz des gesamten Vorgangs 0,21 Millisekunden:
```
$redis = new Redis();
if ($redis->pconnect($HOST, $PORT) != TRUE) {
// ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
Erforderliche Konfigurationen für redis.ini:
+ `redis.pconnect.pooling_enabled=1`
+ `redis.pconnect.connection_limit=10`
Der folgende Code ist ein Beispiel für einen [Redis-py-Verbindungspool](https://redis.readthedocs.io/en/stable/):
```
conn = Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
conn.set(key, value)
```
Der folgende Code ist ein Beispiel für einen [Lettuce-Verbindungspool](https://lettuce.io/core/release/reference/#_connection_pooling):
```
RedisClient client = RedisClient.create(RedisURI.create(HOST, PORT));
GenericObjectPool pool = ConnectionPoolSupport.createGenericObjectPool(() -> client.connect(), new GenericObjectPoolConfig());
pool.setMaxTotal(10); // Configure max connections to 10
try (StatefulRedisConnection connection = pool.borrowObject()) {
RedisCommands syncCommands = connection.sync();
syncCommands.set(key, value);
}
```
# Cluster-Client-Erkennung und exponentielles Backoff (Valkey und Redis OSS)
Wenn Sie im aktivierten Clustermodus eine Verbindung zu einem ElastiCache Valkey- oder Redis-OSS-Cluster herstellen, muss die entsprechende Clientbibliothek clusterfähig sein. Die Clients müssen eine Zuordnung der Hash-Slots zu den entsprechenden Knoten im Cluster abrufen, um Anfragen an die richtigen Knoten zu senden und den zusätzlichen Leistungsaufwand bei der Bearbeitung von Cluster-Umleitungen zu vermeiden. Aus diesem Grund muss der Client in zwei verschiedenen Situationen eine vollständige Liste der Slots und der zugewiesenen Knoten erkennen:
+ Der Client ist initialisiert und muss die anfängliche Slot-Konfiguration auffüllen.
+ Eine MOVED-Umleitung wird vom Server empfangen, z. B. im Fall eines Failovers, bei dem alle vom ehemaligen Primärknoten bereitgestellten Slots vom Replikat übernommen werden, oder beim Re-Sharding, wenn Slots vom primären Quellknoten zum primären Zielknoten verschoben werden.
Die Client-Erkennung erfolgt normalerweise durch Ausgabe eines CLUSTER SLOT- oder CLUSTER NODE-Befehls an den Valkey- oder Redis OSS-Server. Wir empfehlen die CLUSTER SLOT-Methode, da sie das Set der Slot-Bereiche und die zugehörigen Primär- und Replikatknoten an den Client zurückgibt. Dies erfordert kein zusätzliches Parsen durch den Client und ist effizienter.
Abhängig von der Cluster-Topologie kann die Größe der Antwort auf den Befehl CLUSTER SLOT je nach Clustergröße variieren. Größere Cluster mit mehr Knoten erzeugen eine größere Antwort. Daher muss sichergestellt werden, dass die Anzahl der Clients, die die Cluster-Topologie ermitteln, nicht unbegrenzt zunimmt. Wenn beispielsweise die Client-Anwendung startet oder die Verbindung mit dem Server unterbrochen wird und die Cluster-Erkennung durchgeführt werden muss, besteht ein häufiger Fehler darin, dass die Client-Anwendung mehrere Wiederverbindungs- und Erkennungsanforderungen auslöst, ohne dass bei einem erneuten Versuch ein exponentielles Backoff erfolgt. Dies kann dazu führen, dass der Valkey- oder Redis OSS-Server bei einer CPU-Auslastung von 100% über einen längeren Zeitraum nicht reagiert. Der Ausfall verlängert sich, wenn jeder CLUSTER SLOT-Befehl eine große Anzahl von Knoten im Cluster-Bus verarbeiten muss. Aufgrund dieses Verhaltens haben wir in der Vergangenheit mehrere Client-Ausfälle in verschiedenen Sprachen beobachtet, darunter Python (redis-py-cluster) und Java (Lettuce und Redisson).
In einem Serverless-Cache werden viele der Probleme automatisch behoben, da die angekündigte Cluster-Topologie statisch ist und aus zwei Einträgen besteht: einem Schreib- und einem Lese-Endpunkt. Die Cluster-Erkennung wird außerdem automatisch auf mehrere Knoten verteilt, wenn der Cache-Endpunkt verwendet wird. Die folgenden Empfehlungen sind jedoch nach wie vor nützlich.
Wir empfehlen Folgendes, um die Auswirkungen eines plötzlichen Zustroms von Verbindungs- und Erkennungsanforderungen zu minimieren:
+ Implementieren Sie einen Client-Verbindungspool mit einer begrenzten Größe, um die Anzahl der gleichzeitig eingehenden Verbindungen von der Client-Anwendung zu begrenzen.
+ Wenn der Client aufgrund eines Timeouts die Verbindung mit dem Server unterbricht, versuchen Sie es erneut mit exponentiellem Backoff mit Jitter. Dadurch wird vermieden, dass mehrere Clients den Server gleichzeitig überlasten.
+ Verwenden Sie die Anleitung unter [Verbindungsendpunkte finden in ElastiCache](Endpoints.md), um den Cluster-Endpunkt zur Durchführung der Cluster-Erkennung zu finden. Dadurch verteilen Sie die Erkennungslast auf alle Knoten im Cluster (bis zu 90), anstatt einige fest codierte Seed-Knoten im Cluster zu erhalten.
Im Folgenden finden Sie einige Codebeispiele für die exponentielle Backoff-Wiederholungslogik in Redis-py, und Lettuce. PHPRedis
**Beispiel 1 für Backoff-Logik: redis-py**
Redis-py verfügt über einen integrierten Wiederholungsmechanismus, der unmittelbar nach einem Fehler einen erneuten Versuch vornimmt. [Dieser Mechanismus kann durch das `retry_on_timeout` Argument aktiviert werden, das beim Erstellen eines Redis-OSS-Objekts angegeben wird.](https://redis.readthedocs.io/en/stable/examples/connection_examples.html#redis.Redis) Hier demonstrieren wir einen benutzerdefinierten Wiederholungsmechanismus mit exponentiellem Backoff und Jitter. Wir haben eine Pull-Anfrage gesendet, um exponentielles Backoff in [redis-py (\$11494)](https://github.com/andymccurdy/redis-py/pull/1494) nativ zu implementieren. Künftig ist eine manuelle Implementierung möglicherweise nicht mehr erforderlich.
```
def run_with_backoff(function, retries=5):
base_backoff = 0.1 # base 100ms backoff
max_backoff = 10 # sleep for maximum 10 seconds
tries = 0
while True:
try:
return function()
except (ConnectionError, TimeoutError):
if tries >= retries:
raise
backoff = min(max_backoff, base_backoff * (pow(2, tries) + random.random()))
print(f"sleeping for {backoff:.2f}s")
sleep(backoff)
tries += 1
```
Sie können dann den folgenden Code verwenden, um einen Wert festzulegen:
```
client = redis.Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
res = run_with_backoff(lambda: client.set("key", "value"))
print(res)
```
Abhängig von Ihrem Workload möchten Sie möglicherweise den Basis-Backoff-Wert von 1 Sekunde auf einige Dutzende oder Hunderte von Millisekunden für latenzempfindliche Workloads ändern.
**Beispiel 2 für Backoff-Logik: PHPRedis**
PHPRedis verfügt über einen integrierten Wiederholungsmechanismus, der (nicht konfigurierbar) maximal zehnmal versucht. Es gibt eine konfigurierbare Verzögerung zwischen den Wiederholungsversuchen (mit einem Jitter ab dem zweiten Versuch). Weitere Informationen finden Sie im folgenden [Codebeispiel](https://github.com/phpredis/phpredis/blob/b0b9dd78ef7c15af936144c1b17df1a9273d72ab/library.c#L335-L368). [Wir haben eine Pull-Anfrage zur nativen Implementierung des exponentiellen Backoffs in [PHPredis (\$11986)](https://github.com/phpredis/phpredis/pull/1986) eingereicht, die inzwischen zusammengeführt und dokumentiert wurde.](https://github.com/phpredis/phpredis/blob/develop/README.md#retry-and-backoff) Für diejenigen, die die neueste Version von verwenden PHPRedis, ist eine manuelle Implementierung nicht erforderlich, aber wir haben hier die Referenz für die Versionen früherer Versionen aufgenommen. Im Folgenden finden Sie zunächst ein Codebeispiel, das die Verzögerung des Wiederholungsmechanismus konfiguriert:
```
$timeout = 0.1; // 100 millisecond connection timeout
$retry_interval = 100; // 100 millisecond retry interval
$client = new Redis();
if($client->pconnect($HOST, $PORT, $timeout, NULL, $retry_interval) != TRUE) {
return; // ERROR: connection failed
}
$client->set($key, $value);
```
**Beispiel 3 für Backoff-Logik: Lettuce**
Lettuce verfügt über integrierte Wiederholungsmechanismen, die auf den exponentiellen Backoff-Strategien basieren, wie im Beitrag [Exponentielles Backoff und Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) beschrieben. Im Folgenden finden Sie einen Codeauszug, der den vollständigen Jitter-Ansatz zeigt:
```
public static void main(String[] args)
{
ClientResources resources = null;
RedisClient client = null;
try {
resources = DefaultClientResources.builder()
.reconnectDelay(Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(5), // maximum 5 second delay
100, TimeUnit.MILLISECONDS) // 100 millisecond base
).build();
client = RedisClient.create(resources, RedisURI.create(HOST, PORT));
client.setOptions(ClientOptions.builder()
.socketOptions(SocketOptions.builder().connectTimeout(Duration.ofMillis(100)).build()) // 100 millisecond connection timeout
.timeoutOptions(TimeoutOptions.builder().fixedTimeout(Duration.ofSeconds(5)).build()) // 5 second command timeout
.build());
// use the connection pool from above example
} finally {
if (connection != null) {
connection.close();
}
if (client != null){
client.shutdown();
}
if (resources != null){
resources.shutdown();
}
}
}
```
# Konfigurieren Sie ein clientseitiges Timeout (Valkey und Redis OSS)
**Konfiguration des clientseitigen Timeouts**
Konfigurieren Sie das clientseitige Timeout so, dass der Server genügend Zeit hat, die Anfrage zu verarbeiten und die Antwort zu generieren. Dies ermöglicht einen Fail-Fast, wenn die Verbindung zum Server nicht hergestellt werden kann. Bestimmte Valkey- oder Redis OSS-Befehle können rechenintensiver sein als andere. Zum Beispiel Lua-Skripte oder MULTI/EXEC Transaktionen, die mehrere Befehle enthalten, die atomar ausgeführt werden müssen. Im Allgemeinen wird ein höheres clientseitiges Timeout empfohlen, um ein Timeout des Clients zu vermeiden, bevor die Antwort vom Server empfangen wird. Dies umfasst:
+ Ausführen von Befehlen über mehrere Tasten
+ Ausführen von MULTI/EXEC Transaktionen oder Lua-Skripten, die aus mehreren einzelnen Valkey- oder Redis-OSS-Befehlen bestehen
+ Lesen von großen Werten
+ Durchführen von Blockiervorgängen wie BLPOP
Im Falle eines Blockiervorgangs wie BLPOP empfiehlt es sich, das Befehls-Timeout auf einen Wert festzulegen, der unter dem Socket-Timeout liegt.
Im Folgenden finden Sie Codebeispiele für die Implementierung eines clientseitigen Timeouts in redis-py, und Lettuce. PHPRedis
**Beispiel 1 für eine Timeout-Konfiguration: redis-py**
Im Folgenden finden Sie ein Codebeispiel für redis-py:
```
# connect to Redis server with a 100 millisecond timeout
# give every Redis command a 2 second timeout
client = redis.Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10,socket_connect_timeout=0.1,socket_timeout=2))
res = client.set("key", "value") # will timeout after 2 seconds
print(res) # if there is a connection error
res = client.blpop("list", timeout=1) # will timeout after 1 second
# less than the 2 second socket timeout
print(res)
```
**Beispiel 2 für eine Timeout-Konfiguration: PHPRedis**
Das Folgende ist ein Codebeispiel mit PHPRedis:
```
// connect to Redis server with a 100ms timeout
// give every Redis command a 2s timeout
$client = new Redis();
$timeout = 0.1; // 100 millisecond connection timeout
$retry_interval = 100; // 100 millisecond retry interval
$client = new Redis();
if($client->pconnect($HOST, $PORT, 0.1, NULL, 100, $read_timeout=2) != TRUE){
return; // ERROR: connection failed
}
$client->set($key, $value);
$res = $client->set("key", "value"); // will timeout after 2 seconds
print "$res\n"; // if there is a connection error
$res = $client->blpop("list", 1); // will timeout after 1 second
print "$res\n"; // less than the 2 second socket timeout
```
**Beispiel 3 für eine Timeout-Konfiguration: Lettuce**
Im Folgenden finden Sie ein Codebeispiel für Lettuce:
```
// connect to Redis server and give every command a 2 second timeout
public static void main(String[] args)
{
RedisClient client = null;
StatefulRedisConnection connection = null;
try {
client = RedisClient.create(RedisURI.create(HOST, PORT));
client.setOptions(ClientOptions.builder()
.socketOptions(SocketOptions.builder().connectTimeout(Duration.ofMillis(100)).build()) // 100 millisecond connection timeout
.timeoutOptions(TimeoutOptions.builder().fixedTimeout(Duration.ofSeconds(2)).build()) // 2 second command timeout
.build());
// use the connection pool from above example
commands.set("key", "value"); // will timeout after 2 seconds
commands.blpop(1, "list"); // BLPOP with 1 second timeout
} finally {
if (connection != null) {
connection.close();
}
if (client != null){
client.shutdown();
}
}
}
```
# Konfigurieren Sie ein serverseitiges Leerlauf-Timeout (Valkey und Redis OSS)
Wir haben Fälle beobachtet, in denen mit der Anwendung eines Kunden eine hohe Anzahl inaktiver Clients verbunden war, diese aber keine aktiven Befehle sendet. In solchen Szenarien können Sie alle 65 000 Verbindungen mit einer hohen Anzahl inaktiver Clients ausschöpfen. Zur Vermeidung solcher Szenarien konfigurieren Sie die Timeout-Einstellung auf dem Server entsprechend über [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis). Dadurch wird sichergestellt, dass der Server die Verbindung inaktiver Clients aktiv trennt, um eine Erhöhung der Anzahl von Verbindungen zu vermeiden. Diese Einstellung ist für Serverless-Caches nicht verfügbar.
# Lua-Skripte
Valkey und Redis OSS unterstützen mehr als 200 Befehle, einschließlich solcher zum Ausführen von Lua-Skripten. Bei Lua-Skripten gibt es jedoch mehrere Fallstricke, die sich auf den Arbeitsspeicher und die Verfügbarkeit von Valkey oder Redis OSS auswirken können.
**Nicht parametrisierte Lua-Skripte**
Jedes Lua-Skript wird auf dem Valkey- oder Redis-OSS-Server zwischengespeichert, bevor es ausgeführt wird. Unparametrisierte Lua-Skripten sind einzigartig, was dazu führen kann, dass der Valkey- oder Redis-OSS-Server eine große Anzahl von Lua-Skripten speichert und mehr Speicher verbraucht. Damit dies vermieden wird, stellen Sie sicher, dass alle Lua-Skripte parametrisiert sind, und führen Sie bei Bedarf regelmäßig SCRIPT FLUSH aus, um zwischengespeicherte Lua-Skripte zu bereinigen.
Beachten Sie auch, dass Schlüssel bereitgestellt werden müssen. Wenn kein Wert für den KEY-Parameter angegeben wird, schlägt das Skript fehl. Das wird zum Beispiel nicht funktionieren:
```
serverless-test-lst4hg.serverless.use1.cache.amazonaws.com:6379> eval 'return "Hello World"' 0
(error) ERR Lua scripts without any input keys are not supported.
```
Das wird funktionieren:
```
serverless-test-lst4hg.serverless.use1.cache.amazonaws.com:6379> eval 'return redis.call("get", KEYS[1])' 1 mykey-2
"myvalue-2"
```
Das folgende Codebeispiel zeigt, wie parametrisierte Skripte verwendet werden. Zunächst haben wir ein Beispiel für einen nicht parametrisierten Ansatz, der zu drei verschiedenen zwischengespeicherten Lua-Skripten führt. Dieser Ansatz wird nicht empfohlen:
```
eval "return redis.call('set','key1','1')" 0
eval "return redis.call('set','key2','2')" 0
eval "return redis.call('set','key3','3')" 0
```
Verwenden Sie stattdessen das folgende Muster, um ein einzelnes Skript zu erstellen, das übergebene Parameter akzeptieren kann:
```
eval "return redis.call('set',KEYS[1],ARGV[1])" 1 key1 1
eval "return redis.call('set',KEYS[1],ARGV[1])" 1 key2 2
eval "return redis.call('set',KEYS[1],ARGV[1])" 1 key3 3
```
**Lang andauernde Lua-Skripte**
Lua-Skripte können mehrere Befehle atomar ausführen, sodass die Ausführung länger dauern kann als bei einem normalen Valkey- oder Redis OSS-Befehl. Wenn das Lua-Skript nur schreibgeschützte Operationen ausführt, können Sie es zwischendurch beenden. Sobald das Lua-Skript jedoch einen Schreibvorgang ausführt, kann es nicht mehr beendet werden und muss vollständig ausgeführt werden. Ein mutierendes Lua-Skript mit langer Laufzeit kann dazu führen, dass der Valkey- oder Redis-OSS-Server lange Zeit nicht reagiert. Zur Behebung dieses Problems vermeiden Sie lang andauernde Lua-Skripte und testen Sie das Skript in einer Vorproduktionsumgebung.
**Lua-Skript mit Stealth-Schreibvorgängen**
Es gibt mehrere Möglichkeiten, wie ein Lua-Skript weiterhin neue Daten in Valkey oder Redis OSS schreiben kann, selbst wenn Valkey oder Redis OSS beendet ist: `maxmemory`
+ Das Skript startet, wenn sich der Valkey- oder Redis-OSS-Server unten `maxmemory` befindet, und enthält mehrere Schreiboperationen
+ Der erste Schreibbefehl des Skripts verbraucht keinen Speicher (wie DEL), gefolgt von weiteren Schreibvorgängen, die Speicher belegen
+ Sie können dieses Problem beheben, indem Sie auf einem anderen Valkey- oder Redis-OSS-Server eine geeignete Räumungsrichtlinie konfigurieren als. `noeviction` Auf diese Weise kann Redis OSS Objekte entfernen und Speicherplatz zwischen Lua-Skripten freigeben.
# Speichern großer zusammengesetzter Artikel (Valkey und Redis OSS)
In einigen Szenarien kann eine Anwendung große zusammengesetzte Elemente in Valkey oder Redis OSS speichern (z. B. einen Hash-Datensatz mit mehreren GB). Diese Vorgehensweise wird nicht empfohlen, da sie häufig zu Leistungsproblemen in Valkey oder Redis OSS führt. Der Client kann beispielsweise den Befehl HGETALL ausführen, um die gesamte Hash-Sammlung mit mehreren GB abzurufen. Dies kann zu erheblichem Speicherdruck auf den Valkey- oder Redis-OSS-Server führen, der das große Objekt im Client-Ausgabepuffer zwischenspeichert. Außerdem werden bei der Steckplatzmigration im Clustermodus ElastiCache keine Steckplätze migriert, die Elemente mit einer serialisierten Größe von mehr als 256 MB enthalten.
Zur Lösung der Probleme mit großen Elementen wird Folgendes empfohlen:
+ Teilen Sie das große zusammengesetzte Element in mehrere kleinere Objekte auf. Teilen Sie beispielsweise eine große Hash-Sammlung in einzelne Schlüssel-Wert-Felder auf, wobei das Schlüsselnamensschema die Sammlung angemessen widerspiegelt, z. B. indem Sie ein gemeinsames Präfix im Schlüsselnamen verwenden, um die Sammlung von Elementen zu identifizieren. Wenn Sie atomar auf mehrere Felder in derselben Sammlung zugreifen müssen, können Sie den Befehl MGET verwenden, um mehrere Schlüsselwerte in demselben Befehl abzurufen.
+ Wenn Sie alle Optionen geprüft haben und den großen Sammlungsdatensatz immer noch nicht aufteilen können, versuchen Sie, Befehle zu verwenden, die auf eine Teilmenge der Daten in der Sammlung statt auf die gesamte Sammlung angewendet werden. Vermeiden Sie einen Anwendungsfall, bei dem Sie die gesamte Sammlung mit mehreren GB mit demselben Befehl atomar abrufen müssen. Ein Beispiel ist die Verwendung von HGET- oder HMGET-Befehlen anstelle von HGETALL für Hash-Sammlungen.
# Konfiguration des Lettuce-Clients (Valkey und Redis OSS)
In diesem Abschnitt werden die empfohlenen Konfigurationsoptionen für Java und Lettuce sowie deren Anwendung auf Cluster beschrieben. ElastiCache
Die Empfehlungen in diesem Abschnitt wurden mit Lettuce Version 6.2.2 getestet.
**Topics**
+ [Beispiel: Lettuve-Konfiguration für den Clustermodus, TLS aktiviert](BestPractices.Clients-lettuce-cme.md)
+ [Beispiel: Die Lettuce-Konfiguration für den Cluster-Modus ist deaktiviert, TLS aktiviert](BestPractices.Clients-lettuce-cmd.md)
**Java-DNS-Cache-TTLs**
Die Java Virtual Machine (JVM) speichert DNS-Namensauflösungen zwischen. Wenn die JVM einen Hostnamen in eine IP-Adresse auflöst, speichert sie die IP-Adresse für einen bestimmten Zeitraum, der als (TTL) bezeichnet wird. *time-to-live*
Die Wahl des TTL-Werts ist ein Kompromiss zwischen Latenz auf der einen und Reaktionsfähigkeit auf Änderungen auf der anderen Seite. Bei einer kürzeren TTLs Variante erkennen DNS-Resolver Aktualisierungen im DNS des Clusters schneller. Dadurch kann Ihre Anwendung schneller auf Ersetzungen oder andere Workflows reagieren, denen Ihr Cluster unterzogen wird. Ist die TTL jedoch zu niedrig, erhöht sich das Abfragevolumen, was die Latenz Ihrer Anwendung erhöhen kann. Zwar gibt es keinen korrekten TTL-Wert, ist es bei der Festlegung des TTL-Werts beachtenswert, zu berücksichtigen, wie lange Sie darauf warten können, das eine Änderung wirksam wird.
Da ElastiCache Knoten DNS-Namenseinträge verwenden, die sich ändern können, empfehlen wir Ihnen, Ihre JVM mit einer niedrigen TTL von 5 bis 10 Sekunden zu konfigurieren. Auf diese Weise wird bei Änderung der IP-Adresse eines Knotens sichergestellt, dass Ihre Anwendung die neue IP-Adresse der Ressource durch erneute Abfrage des DNS-Eintrags abrufen und nutzen kann.
Bei einigen Java-Konfigurationen ist die JVM-Standard-TTL so festgelegt, dass DNS-Einträge nie aktualisiert werden, bis die JVM neu gestartet wird.
Einzelheiten zum Festlegen der JVM-TTL finden Sie unter [So legen Sie die JVM-TTL fest](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html#how-to-set-the-jvm-ttl).
**Lettuce-Version**
Wir empfehlen die Verwendung der Lettuce-Version 6.2.2 oder höher.
**Endpunkte**
Wenn Sie Cluster verwenden, für die der Cluster-Modus aktiviert ist, legen Sie den `redisUri` auf den Endpunkt der Cluster-Konfiguration fest. Die DNS-Suche für diesen URI gibt eine Liste aller verfügbaren Knoten im Cluster zurück und wird während der Cluster-Initialisierung nach dem Zufallsprinzip auf einen davon aufgelöst. Weitere Informationen zur Funktionsweise der Topologieaktualisierung finden Sie weiter unten in diesem *dynamicRefreshResources*Thema.
**SocketOption**
Aktivieren Sie [KeepAlive](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.KeepAliveOptions.html). Durch die Aktivierung dieser Option wird die Notwendigkeit verringert, während der Befehlslaufzeit ausgefallene Verbindungen zu behandeln.
Stellen Sie sicher, dass Sie das [Verbindungs-Timeout](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.Builder.html#connectTimeout-java.time.Duration-) entsprechend Ihren Anwendungsanforderungen und Ihrer Workload festlegen. Weitere Informationen finden Sie im Abschnitt „Timeouts“ weiter unten in diesem Thema.
**ClusterClientOption: Client-Optionen mit aktiviertem Clustermodus**
Aktiviert [AutoReconnect](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#autoReconnect-boolean-), wenn die Verbindung unterbrochen wird.
Set [CommandTimeout](https://lettuce.io/core/release/api/io/lettuPrce/core/RedisURI.html#getTimeout--). Weitere Einzelheiten finden Sie im Abschnitt „Timeouts“ weiter unten in diesem Thema.
Legen Sie [nodeFilter](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#nodeFilter-java.util.function.Predicate-) fest, um ausgefallene Knoten aus der Topologie herauszufiltern. Lettuce speichert alle Knoten, die sich in der Ausgabe „Cluster-Knoten“ befinden (einschließlich der Knoten mit PFAIL/FAIL-Status), in den „Partitionen“ des Clients (auch als Shards bekannt). Während der Erstellung der Cluster-Topologie wird versucht, eine Verbindung mit allen Knoten der Partition herzustellen. Dieses Verhalten von Lettuce, bei dem ausgefallene Knoten hinzugefügt werden, kann Verbindungsfehlern (oder Warnungen) verursachen, wenn Knoten aus einem beliebigen Grund ersetzt werden.
Wenn beispielsweise ein Failover abgeschlossen ist und der Cluster den Wiederherstellungsprozess startet, während das clusterTopologie-Element aktualisiert wird, weist die Zuordnung der Cluster-Busknoten einen kurzen Zeitraum auf, in dem der ausgefallene Knoten als FAIL-Knoten aufgeführt wird, bevor er vollständig aus der Topologie entfernt wird. Während dieser Zeit betrachtet der Lettuce-Client ihn als fehlerfreien Knoten und stellt kontinuierlich eine Verbindung zu ihm her. Dies führt zu einem Fehler, nachdem alle Wiederholungsversuche durchgeführt wurden.
Zum Beispiel:
```
final ClusterClientOptions clusterClientOptions =
ClusterClientOptions.builder()
... // other options
.nodeFilter(it ->
! (it.is(RedisClusterNode.NodeFlag.FAIL)
|| it.is(RedisClusterNode.NodeFlag.EVENTUAL_FAIL)
|| it.is(RedisClusterNode.NodeFlag.HANDSHAKE)
|| it.is(RedisClusterNode.NodeFlag.NOADDR)))
.validateClusterNodeMembership(false)
.build();
redisClusterClient.setOptions(clusterClientOptions);
```
**Anmerkung**
Die Knotenfilterung wird am besten verwendet, wenn sie auf true DynamicRefreshSources gesetzt ist. Andernfalls wird der Primärknoten eines Shards herausgefiltert, wenn die Topologieansicht von einem einzelnen problematischen Seed-Knoten übernommen wird, der diesen primären Knoten als ausgefallen ansieht. Dies führt dazu, dass die Slots nicht abgedeckt werden. Wenn mehrere Seed-Knoten vorhanden sind (wenn wahr), verringert DynamicRefreshSources sich die Wahrscheinlichkeit, dass dieses Problem auftritt, da zumindest einige der Seed-Knoten nach einem Failover mit dem neu hochgestuften Primärknoten über eine aktualisierte Topologieansicht verfügen sollten.
**ClusterTopologyRefreshOptions: Optionen zur Steuerung der Aktualisierung der Clustertopologie auf dem Client mit aktiviertem Clustermodus**
**Anmerkung**
Cluster mit deaktivierten Cluster-Modus unterstützen die Befehle zur Cluster-Ermittlung nicht und sind nicht mit allen Funktionen zur dynamischen Topologieermittlung des Clients kompatibel.
Der Clustermodus ist deaktiviert mit ElastiCache ist nicht mit dem von Lettuce kompatibel. `MasterSlaveTopologyRefresh` Stattdessen können Sie für einen deaktivierten Cluster-Modus einen `StaticMasterReplicaTopologyProvider` konfigurieren und die Lese- und Schreibendpunkte des Clusters bereitstellen.
Weitere Informationen zum Herstellen einer Verbindung mit Clustern mit deaktiviertem Cluster-Modus finden Sie unter [Finden Sie die Endpunkte eines Valkey- oder Redis OSS-Clusters (Cluster-Modus deaktiviert) (Konsole)](Endpoints.md#Endpoints.Find.Redis).
Wenn Sie die Funktion zur dynamischen Topologieermittlung von Lettuce verwenden möchten, können Sie einen Cluster mit aktiviertem Cluster-Modus mit derselben Shard-Konfiguration wie Ihr vorhandener Cluster erstellen. Für Cluster mit aktiviertem Cluster-Modus empfehlen wir jedoch, mindestens 3 Shards mit mindestens einem Replikat zu konfigurieren, um schnelles Failover zu unterstützen.
Aktivieren Sie [enablePeriodicRefresh](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enablePeriodicRefresh-java.time.Duration-). Dies ermöglicht eine regelmäßige Aktualisierung der Cluster-Topologie, sodass der Client die Cluster-Topologie in den Intervallen des refreshPeriod-Elements aktualisiert (Standard: 60 Sekunden). Wenn das Element deaktiviert ist, aktualisiert der Client die Cluster-Topologie nur, falls es bei dem Versuch, Befehle für den Cluster auszuführen, zu Fehlern kommt.
Wenn diese Option aktiviert ist, können Sie die mit der Aktualisierung der Cluster-Topologie verbundene Latenz reduzieren, indem Sie diesen Auftrag zu einer Hintergrundaufgabe hinzufügen. Die Aktualisierung der Topologie erfolgt zwar im Hintergrund, kann jedoch bei Clustern mit vielen Knoten etwas langsam sein. Dies liegt daran, dass alle Knoten nach ihren Ansichten abgefragt werden, um die aktuellste Cluster-Ansicht zu erhalten. Wenn Sie einen großen Cluster betreiben, sollten Sie den Zeitraum erhöhen.
Aktivieren Sie [enableAllAdaptiveRefreshTriggers](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enableAllAdaptiveRefreshTriggers--). Dies ermöglicht eine adaptive Aktualisierung der Topologie, die alle [Trigger](https://lettuce.io/core/6.1.6.RELEASE/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.RefreshTrigger.html) verwendet: MOVED\$1REDIRECT, ASK\$1REDIRECT, PERSISTENT\$1RECONNECTS, UNCOVERED\$1SLOT, UNKNOWN\$1NODE. Adaptive Aktualisierungsauslöser initiieren Aktualisierungen der Topologieansicht auf der Grundlage von Ereignissen, die während Valkey- oder Redis OSS-Clustervorgängen auftreten. Das Aktivieren dieser Option führt zu einer sofortigen Aktualisierung der Topologie, wenn einer der zuvor genannten Trigger auftritt. Die Rate der adaptiv ausgelöste Aktualisierungen ist durch einen Timeout begrenzt, da Ereignisse in großem Umfang auftreten können (Standard-Timeout zwischen Updates: 30).
Aktivieren Sie [closeStaleConnections](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#closeStaleConnections-boolean-). Dadurch können alte Verbindungen beim Aktualisieren der Cluster-Topologie geschlossen werden. [Sie tritt nur in Kraft, wenn. ClusterTopologyRefreshOptions isPeriodicRefreshEnabled ()](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.html#isPeriodicRefreshEnabled--) ist wahr. Wenn es aktiviert ist, kann der Client alte Verbindungen schließen und im Hintergrund neue erstellen. Dadurch wird die Notwendigkeit verringert, während der Befehlslaufzeit ausgefallene Verbindungen zu behandeln.
Aktivieren Sie [dynamicRefreshResources](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#dynamicRefreshSources-boolean-). Wir empfehlen, die dynamicRefreshResources Option für kleine Cluster zu aktivieren und für große Cluster zu deaktivieren. dynamicRefreshResourcesermöglicht die Erkennung von Clusterknoten anhand des bereitgestellten Seed-Knotens (z. B. vom Cluster-Konfigurationsendpunkt). Es verwendet alle erkannten Knoten als Quellen für die Aktualisierung der Cluster-Topologie.
Bei der Verwendung der dynamischen Aktualisierung werden alle erkannten Knoten nach der Cluster-Topologie abgefragt und es wird versucht, die genaueste Cluster-Ansicht auszuwählen. Wenn der Wert auf „falsch“ festgelegt ist, werden nur die anfänglichen Seed-Knoten als Quellen für die Topologieerkennung verwendet, und die Anzahl der Clients wird nur für die ersten Seed-Knoten ermittelt. Ist er deaktiviert und der Endpunkt der Cluster-Konfiguration wird in einen ausgefallenen Knoten aufgelöst, schlägt der Versuch, die Cluster-Ansicht zu aktualisieren, fehl und führt zu Ausnahmen. Dieses Szenario kann eintreten, da es einige Zeit dauert, bis der Eintrag eines ausgefallenen Knotens vom Endpunkt der Cluster-Konfiguration entfernt wird. Daher kann der Konfigurationsendpunkt für einen kurzen Zeitraum immer noch nach dem Zufallsprinzip auf einen ausgefallenen Knoten aufgelöst werden.
Ist er aktiviert, verwenden wir jedoch alle Cluster-Knoten, die von der Cluster-Ansicht empfangen werden, um ihre aktuelle Ansicht abzufragen. Da wir ausgefallene Knoten aus dieser Ansicht herausfiltern, ist die Topologieaktualisierung erfolgreich. Wenn dies jedoch dynamicRefreshSources zutrifft, fragt Lettuce alle Knoten ab, um die Clusteransicht abzurufen, und vergleicht dann die Ergebnisse. Daher kann dieses Vorgehen für Cluster mit vielen Knoten teuer sein. Wir empfehlen, dass Sie diese Funktion für Cluster mit vielen Knoten deaktivieren.
```
final ClusterTopologyRefreshOptions topologyOptions =
ClusterTopologyRefreshOptions.builder()
.enableAllAdaptiveRefreshTriggers()
.enablePeriodicRefresh()
.dynamicRefreshSources(true)
.build();
```
**ClientResources**
Konfigurieren Sie [DnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#dnsResolver-io.lettuce.core.resource.DnsResolver-) mit [DirContextDnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DirContextDnsResolver.html). Der DNS-Resolver basiert auf Javas com.sun.jndi.dns. DnsContextFactory.
Konfigurieren Sie [reconnectDelay](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#reconnectDelay-io.lettuce.core.resource.Delay-) mit exponentiellem Backoff und vollständigem Jitter. Lettuce verfügt über integrierte Wiederholungsmechanismen, die auf den exponentiellen Backoff-Strategien basieren. Einzelheiten finden Sie unter [Exponential Backoff and Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter) im Architecture-Blog. AWS [Weitere Informationen zur Bedeutung einer Backoff-Strategie mit wiederholten Versuchen finden Sie in den Abschnitten zur Backoff-Logik im Blogbeitrag Best Practices im Datenbank-Blog.](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) AWS
```
ClientResources clientResources = DefaultClientResources.builder()
.dnsResolver(new DirContextDnsResolver())
.reconnectDelay(
Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(10), // maximum 10 second delay
100, TimeUnit.MILLISECONDS)) // 100 millisecond base
.build();
```
**Timeouts**
Verwenden Sie einen niedrigeren Wert für das Verbindungs-Timeout als für das Befehls-Timeout. Lettuce verwendet einen verzögerten Verbindungsaufbau. Wenn also das Verbindungs-Timeout höher als das Befehls-Timeout ist, kann es nach einer Topologieaktualisierung zu einem Zeitraum mit anhaltendem Ausfall kommen, falls Lettuce versucht, eine Verbindung mit einem fehlerhaften Knoten herzustellen, und das Befehls-Timeout immer überschritten wird.
Verwenden Sie ein dynamisches Befehls-Timeout für verschiedene Befehle. Wir empfehlen, das Befehls-Timeout auf der Grundlage der erwarteten Dauer des Befehls festzulegen. Verwenden Sie beispielsweise ein längeres Timeout für Befehle, die über mehrere Schlüssel hinweg iterieren, z. B. FLUSHDB-, FLUSHALL-, KEYS-, SMEMBERS- oder Lua-Skripts. Verwenden Sie kürzere Timeouts für einzelne Schlüsselbefehle wie SET, GET und HSET.
**Anmerkung**
Die im folgenden Beispiel konfigurierten Timeouts gelten für Tests, bei denen SET/GET-Befehle mit Schlüsseln und Werten von bis zu 20 Byte ausgeführt wurden. Die Verarbeitungszeit kann bei komplexen Befehlen oder größeren Schlüsseln und Werten länger sein. Sie sollten die Timeouts je nach Anwendungsfall Ihrer Anwendung festlegen.
```
private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
SocketOptions socketOptions = SocketOptions.builder()
.connectTimeout(CONNECT_TIMEOUT)
.build();
class DynamicClusterTimeout extends TimeoutSource {
private static final Set META_COMMAND_TYPES = ImmutableSet.builder()
.add(CommandType.FLUSHDB)
.add(CommandType.FLUSHALL)
.add(CommandType.CLUSTER)
.add(CommandType.INFO)
.add(CommandType.KEYS)
.build();
private final Duration defaultCommandTimeout;
private final Duration metaCommandTimeout;
DynamicClusterTimeout(Duration defaultTimeout, Duration metaTimeout)
{
defaultCommandTimeout = defaultTimeout;
metaCommandTimeout = metaTimeout;
}
@Override
public long getTimeout(RedisCommand command) {
if (META_COMMAND_TYPES.contains(command.getType())) {
return metaCommandTimeout.toMillis();
}
return defaultCommandTimeout.toMillis();
}
}
// Use a dynamic timeout for commands, to avoid timeouts during
// cluster management and slow operations.
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(
new DynamicClusterTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();
```
# Beispiel: Lettuve-Konfiguration für den Clustermodus, TLS aktiviert
**Anmerkung**
Timeouts im folgenden Beispiel beziehen sich auf Tests, bei denen SET/GET Befehle mit Schlüsseln und Werten ausgeführt wurden, die bis zu 20 Byte lang waren. Die Verarbeitungszeit kann bei komplexen Befehlen oder größeren Schlüsseln und Werten länger sein. Sie sollten die Timeouts je nach Anwendungsfall Ihrer Anwendung festlegen.
```
// Set DNS cache TTL
public void setJVMProperties() {
java.security.Security.setProperty("networkaddress.cache.ttl", "10");
}
private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
// Create RedisURI from the cluster configuration endpoint
clusterConfigurationEndpoint = // TODO: add your cluster configuration endpoint
final RedisURI redisUriCluster =
RedisURI.Builder.redis(clusterConfigurationEndpoint)
.withPort(6379)
.withSsl(true)
.build();
// Configure the client's resources
ClientResources clientResources = DefaultClientResources.builder()
.reconnectDelay(
Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(10), // maximum 10 second delay
100, TimeUnit.MILLISECONDS)) // 100 millisecond base
.dnsResolver(new DirContextDnsResolver())
.build();
// Create a cluster client instance with the URI and resources
RedisClusterClient redisClusterClient =
RedisClusterClient.create(clientResources, redisUriCluster);
// Use a dynamic timeout for commands, to avoid timeouts during
// cluster management and slow operations.
class DynamicClusterTimeout extends TimeoutSource {
private static final Set META_COMMAND_TYPES = ImmutableSet.builder()
.add(CommandType.FLUSHDB)
.add(CommandType.FLUSHALL)
.add(CommandType.CLUSTER)
.add(CommandType.INFO)
.add(CommandType.KEYS)
.build();
private final Duration metaCommandTimeout;
private final Duration defaultCommandTimeout;
DynamicClusterTimeout(Duration defaultTimeout, Duration metaTimeout)
{
defaultCommandTimeout = defaultTimeout;
metaCommandTimeout = metaTimeout;
}
@Override
public long getTimeout(RedisCommand command) {
if (META_COMMAND_TYPES.contains(command.getType())) {
return metaCommandTimeout.toMillis();
}
return defaultCommandTimeout.toMillis();
}
}
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(new DynamicClusterTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();
// Configure the topology refreshment options
final ClusterTopologyRefreshOptions topologyOptions =
ClusterTopologyRefreshOptions.builder()
.enableAllAdaptiveRefreshTriggers()
.enablePeriodicRefresh()
.dynamicRefreshSources(true)
.build();
// Configure the socket options
final SocketOptions socketOptions =
SocketOptions.builder()
.connectTimeout(CONNECT_TIMEOUT)
.keepAlive(true)
.build();
// Configure the client's options
final ClusterClientOptions clusterClientOptions =
ClusterClientOptions.builder()
.topologyRefreshOptions(topologyOptions)
.socketOptions(socketOptions)
.autoReconnect(true)
.timeoutOptions(timeoutOptions)
.nodeFilter(it ->
! (it.is(RedisClusterNode.NodeFlag.FAIL)
|| it.is(RedisClusterNode.NodeFlag.EVENTUAL_FAIL)
|| it.is(RedisClusterNode.NodeFlag.NOADDR)))
.validateClusterNodeMembership(false)
.build();
redisClusterClient.setOptions(clusterClientOptions);
// Get a connection
final StatefulRedisClusterConnection connection =
redisClusterClient.connect();
// Get cluster sync/async commands
RedisAdvancedClusterCommands sync = connection.sync();
RedisAdvancedClusterAsyncCommands async = connection.async();
```
# Beispiel: Die Lettuce-Konfiguration für den Cluster-Modus ist deaktiviert, TLS aktiviert
**Anmerkung**
Timeouts im folgenden Beispiel beziehen sich auf Tests, bei denen SET/GET Befehle mit Schlüsseln und Werten ausgeführt wurden, die bis zu 20 Byte lang waren. Die Verarbeitungszeit kann bei komplexen Befehlen oder größeren Schlüsseln und Werten länger sein. Sie sollten die Timeouts je nach Anwendungsfall Ihrer Anwendung festlegen.
```
// Set DNS cache TTL
public void setJVMProperties() {
java.security.Security.setProperty("networkaddress.cache.ttl", "10");
}
private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
// Create RedisURI from the primary/reader endpoint
clusterEndpoint = // TODO: add your node endpoint
RedisURI redisUriStandalone =
RedisURI.Builder.redis(clusterEndpoint).withPort(6379).withSsl(true).withDatabase(0).build();
ClientResources clientResources =
DefaultClientResources.builder()
.dnsResolver(new DirContextDnsResolver())
.reconnectDelay(
Delay.fullJitter(
Duration.ofMillis(100), // minimum 100 millisecond delay
Duration.ofSeconds(10), // maximum 10 second delay
100,
TimeUnit.MILLISECONDS)) // 100 millisecond base
.build();
// Use a dynamic timeout for commands, to avoid timeouts during
// slow operations.
class DynamicTimeout extends TimeoutSource {
private static final Set META_COMMAND_TYPES = ImmutableSet.builder()
.add(CommandType.FLUSHDB)
.add(CommandType.FLUSHALL)
.add(CommandType.INFO)
.add(CommandType.KEYS)
.build();
private final Duration metaCommandTimeout;
private final Duration defaultCommandTimeout;
DynamicTimeout(Duration defaultTimeout, Duration metaTimeout)
{
defaultCommandTimeout = defaultTimeout;
metaCommandTimeout = metaTimeout;
}
@Override
public long getTimeout(RedisCommand command) {
if (META_COMMAND_TYPES.contains(command.getType())) {
return metaCommandTimeout.toMillis();
}
return defaultCommandTimeout.toMillis();
}
}
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(new DynamicTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();
final SocketOptions socketOptions =
SocketOptions.builder().connectTimeout(CONNECT_TIMEOUT).keepAlive(true).build();
ClientOptions clientOptions =
ClientOptions.builder().timeoutOptions(timeoutOptions).socketOptions(socketOptions).build();
RedisClient redisClient = RedisClient.create(clientResources, redisUriStandalone);
redisClient.setOptions(clientOptions);
```
## Konfiguration eines bevorzugten Protokolls für Dual-Stack-Cluster (Valkey und Redis OSS)
Bei Valkey- oder Redis OSS-Clustern, die im Clustermodus aktiviert sind, können Sie mit dem IP Discovery-Parameter steuern, welches Protokoll Clients verwenden, um eine Verbindung zu den Knoten im Cluster herzustellen. Der IP Discovery-Parameter kann entweder auf oder IPv4 gesetzt werden. IPv6
Für Valkey- oder Redis-OSS-Cluster legt der IP-Discovery-Parameter das IP-Protokoll fest, das in der Ausgabe von [Cluster-Slots ()](https://valkey.io/commands/cluster-slots/), [Cluster-Shards ()](https://valkey.io/commands/cluster-shards/) und [Clusterknoten (](https://valkey.io/commands/cluster-nodes/)) verwendet wird. Diese Befehle werden von Clients verwendet, um die Cluster-Topologie zu ermitteln. Clients verwenden die IPs in diesen Befehlen enthaltenen Befehle, um eine Verbindung zu den anderen Knoten im Cluster herzustellen.
Eine Änderung vom IP-Discovery führt zu keinen Ausfallzeiten für verbundene Clients. Die VerarbeitWeiterleitung ung der Änderungen wird jedoch einige Zeit dauern. Um festzustellen, wann sich die Änderungen für einen Valkey- oder Redis-OSS-Cluster vollständig verbreitet haben, überwachen Sie die Ausgabe von. `cluster slots` Sobald alle vom Befehl Cluster-Slots zurückgegebenen Knoten das neue Protokoll gemeldet IPs haben, ist die Übertragung der Änderungen abgeschlossen.
Beispiel mit Redis-Py:
```
cluster = RedisCluster(host="xxxx", port=6379)
target_type = IPv6Address # Or IPv4Address if changing to IPv4
nodes = set()
while len(nodes) == 0 or not all((type(ip_address(host)) is target_type) for host in nodes):
nodes = set()
# This refreshes the cluster topology and will discovery any node updates.
# Under the hood it calls cluster slots
cluster.nodes_manager.initialize()
for node in cluster.get_nodes():
nodes.add(node.host)
self.logger.info(nodes)
time.sleep(1)
```
Beispiel mit Lettuce:
```
RedisClusterClient clusterClient = RedisClusterClient.create(RedisURI.create("xxxx", 6379));
Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4
Set nodes;
do {
// Check for any changes in the cluster topology.
// Under the hood this calls cluster slots
clusterClient.refreshPartitions();
Set nodes = new HashSet<>();
for (RedisClusterNode node : clusterClient.getPartitions().getPartitions()) {
nodes.add(node.getUri().getHost());
}
Thread.sleep(1000);
} while (!nodes.stream().allMatch(node -> {
try {
return finalTargetProtocolType.isInstance(InetAddress.getByName(node));
} catch (UnknownHostException ignored) {}
return false;
}));
```
# Bewährte Methoden für Kunden (Memcached)
Erfahren Sie mehr über bewährte Methoden für gängige Szenarien mit ElastiCache Memcached-Clustern.
**Topics**
+ [Konfiguration Ihres ElastiCache Clients für einen effizienten Lastenausgleich (Memcached)](BestPractices.LoadBalancing.md)
+ [Validierte Kunden mit Memcached](network-type-validated-clients-memcached.md)
+ [Konfiguration eines bevorzugten Protokolls für Dual-Stack-Cluster (Memcached)](network-type-configuring-dual-stack-memcached.md)
# Konfiguration Ihres ElastiCache Clients für einen effizienten Lastenausgleich (Memcached)
**Anmerkung**
Dieser Abschnitt bezieht sich auf knotenbasierte Memcached-Cluster mit mehreren Knoten.
Um mehrere ElastiCache Memcached-Knoten effektiv nutzen zu können, müssen Sie in der Lage sein, Ihre Cache-Schlüssel auf die Knoten zu verteilen. Eine einfache Methode zum Lastenausgleich eines Clusters mit *n* Knoten besteht darin, den Hash des Objektschlüssels zu berechnen und das Ergebnis mit *n*: zu modifizieren. `hash(key) mod n` Der resultierende Wert (0 bis *n*–1) ist die Nummer des Knotens, auf dem Sie das Objekt platzieren.
Diese Methode ist einfach und funktioniert gut, solange die Anzahl der Knoten (*n*) konstant bleibt. Wenn Sie einen Knoten zum Cluster hinzufügen oder daraus entfernen, beträgt die Anzahl der zu verschiebenden Schlüssel jedoch jedes Mal *(n - 1) / n* (dabei entspricht *n* der neuen Anzahl von Knoten). Diese Methode führt daher dazu, dass eine große Anzahl von Schlüsseln verschoben werden. Dies ist mit einer großen Anzahl anfänglicher Cache-Fehlelemente verbunden, insbesondere bei einer umfangreichen Anzahl von Knoten. Die Skalierung von 1 auf 2 Knoten führt bestenfalls dazu, dass (2-1) / 2 (50 %) der Schlüssel verschoben werden. Eine Skalierung von 9 auf 10 Knoten hat bestenfalls zur Folge, dass (10–1) / 10 (90 %) der Schlüssel verschoben werden. Ist die Aufwärtsskalierung durch einen sprunghaften Anstieg im Datenverkehr bedingt, ist eine große Anzahl von Cache-Fehlelementen nicht wünschenswert. Eine große Anzahl von Cache-Fehlelementen führt zu Anfragen bei der Datenbank, die aufgrund des sprunghaften Anstiegs im Datenverkehr bereits überlastet ist.
Die Lösung zu diesem Dilemma ist konsistentes Hashing. Beim konsistenten Hashing wird ein Algorithmus verwendet, bei dem jedes Mal, wenn ein Knoten zu einem Cluster hinzugefügt oder daraus entfernt wird, die Anzahl der zu verschiebenden Schlüssel ungefähr *1 / n* beträgt (wobei *n* die neue Anzahl von Knoten ist). Eine Skalierung von 1 auf 2 Knoten hat schlimmstenfalls zur Folge, dass 1/2 (50 Prozent) der Schlüssel verschoben werden. Eine Skalierung von 9 auf 10 Knoten hat zur Folge, dass 1/10 (10 Prozent) der Schlüssel verschoben werden.
Sie als Benutzer steuern, welcher Hashalgorithmus für Mehrknoten-Cluster verwendet wird. Wir empfehlen, dass Sie Ihre Clients zur Verwendung von konsistentem Hashing konfigurieren. Glücklicherweise sind viele Memcached-Clientbibliotheken in den meisten gängigen Sprachen verfügbar, die konsistentes Hashing implementieren. Überprüfen Sie die Dokumentation der von Ihnen verwendeten Bibliothek darauf, ob sie konsistentes Hashing unterstützt und wie es implementiert wird.
Wenn Sie in Java, PHP oder .NET arbeiten, empfehlen wir Ihnen, eine der ElastiCache Amazon-Clientbibliotheken zu verwenden.
## Konsistentes Hashing mithilfe von Java
Der ElastiCache Memcached Java-Client basiert auf dem Open-Source-Spymemcached-Java-Client, der über integrierte konsistente Hashing-Funktionen verfügt. Die Bibliothek umfasst eine Klasse, die konsistentes Hashing implementiert. KetamaConnectionFactory Konsistentes Hashing ist in spymemcached standardmäßig deaktiviert.
Weitere Informationen finden Sie in der KetamaConnectionFactory Dokumentation unter [KetamaConnectionFactory](https://github.com/RTBHOUSE/spymemcached/blob/master/src/main/java/net/spy/memcached/KetamaConnectionFactory.java).
## Konsistentes Hashing mithilfe von PHP mit Memcached
Der ElastiCache Memcached PHP-Client ist ein Wrapper rund um die integrierte Memcached-PHP-Bibliothek. Konsistentes Hashing wird von der Memcached-PHP-Bibliothek standardmäßig deaktiviert.
Verwenden Sie den folgenden Code, um konsistentes Hashing zu aktivieren.
```
$m = new Memcached();
$m->setOption(Memcached::OPT_DISTRIBUTION, Memcached::DISTRIBUTION_CONSISTENT);
```
Zusätzlich zum obigen Code wird empfohlen, ebenfalls `memcached.sess_consistent_hash` in der Datei php.ini einzuschalten.
[Weitere Informationen finden Sie in der Dokumentation zur Laufzeitkonfiguration für Memcached PHP unter http://php. net/manual/en/memcached.configuration.php.](http://php.net/manual/en/memcached.configuration.php) Beachten Sie insbesondere den Parameter `memcached.sess_consistent_hash`.
## Konsistentes Hashing mit.NET mit Memcached
Der ElastiCache Memcached.NET-Client ist ein Wrapper für Enyim Memcached. Konsistentes Hashing wird vom Enyim-Memcached-Client standardmäßig aktiviert.
[Weitere Informationen finden Sie in der Dokumentation unter -Configuration\$1. `memcached/locator` https://github.com/enyim/ EnyimMemcached/wiki/MemcachedClient user-content-memcachedlocator](https://github.com/enyim/EnyimMemcached/wiki/MemcachedClient-Configuration#user-content-memcachedlocator)
# Validierte Kunden mit Memcached
Die folgenden Clients wurden speziell daraufhin geprüft, ob sie mit allen unterstützten Netzwerktypkonfigurationen für Memcached funktionieren.
Validierte Clients:
+ [AWS ElastiCache Cluster-Client Memcached für](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php) [Php — Version \$13.6.2](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php/tree/v3.2.0)
+ [AWS ElastiCache Cluster Client Memcached für](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-java) Java — Neuester Master auf Github
# Konfiguration eines bevorzugten Protokolls für Dual-Stack-Cluster (Memcached)
Bei Memcached-Clustern können Sie mit dem IP-Discovery-Parameter das Protokoll steuern, das Clients für die Verbindung mit den Knoten im Cluster verwenden. Der IP Discovery-Parameter kann entweder auf oder IPv4 gesetzt werden. IPv6
Der IP-Erkennungsparameter steuert das IP-Protokoll, das in der Cluster-Ausgabe der Konfiguration verwendet wird. Dies wiederum bestimmt das IP-Protokoll, das von Clients verwendet wird, die automatische Erkennung ElastiCache für Memcached-Cluster unterstützen.
Eine Änderung vom IP-Discovery führt zu keinen Ausfallzeiten für verbundene Clients. Die Weiterleitung der Änderungen wird jedoch einige Zeit dauern.
Überwachen Sie die Ausgabe von `getAvailableNodeEndPoints` für Java und für Php überwachen Sie die Ausgabe von `getServerList`. Sobald die Ausgabe dieser Funktionen Berichte IPs für alle Knoten im Cluster enthält, die das aktualisierte Protokoll verwenden, ist die Übertragung der Änderungen abgeschlossen.
Java-Beispiel:
```
MemcachedClient client = new MemcachedClient(new InetSocketAddress("xxxx", 11211));
Class targetProtocolType = Inet6Address.class; // Or Inet4Address.class if you're switching to IPv4
Set nodes;
do {
nodes = client.getAvailableNodeEndPoints().stream().map(NodeEndPoint::getIpAddress).collect(Collectors.toSet());
Thread.sleep(1000);
} while (!nodes.stream().allMatch(node -> {
try {
return finalTargetProtocolType.isInstance(InetAddress.getByName(node));
} catch (UnknownHostException ignored) {}
return false;
}));
```
Php-Beispiel:
```
$client = new Memcached;
$client->setOption(Memcached::OPT_CLIENT_MODE, Memcached::DYNAMIC_CLIENT_MODE);
$client->addServer("xxxx", 11211);
$nodes = [];
$target_ips_count = 0;
do {
# The PHP memcached client only updates the server list if the polling interval has expired and a
# command is sent
$client->get('test');
$nodes = $client->getServerList();
sleep(1);
$target_ips_count = 0;
// For IPv4 use FILTER_FLAG_IPV4
$target_ips_count = count(array_filter($nodes, function($node) { return filter_var($node["ipaddress"], FILTER_VALIDATE_IP, FILTER_FLAG_IPV6); }));
} while (count($nodes) !== $target_ips_count);
```
Alle vorhandenen Client-Verbindungen, die vor der Aktualisierung von IP Discovery erstellt wurden, werden weiterhin mit dem alten Protokoll verbunden. Alle validierten Clients stellen mithilfe des neuen IP-Protokolls automatisch wieder eine Verbindung mit dem Cluster her, sobald die Änderungen in der Ausgabe der Cluster-Erkennungsbefehle erkannt wurden. Dies hängt jedoch von der Implementierung des Clients ab.
## TLS-fähige ElastiCache Dual-Stack-Cluster
Wenn TLS für ElastiCache Cluster aktiviert ist, geben die Cluster-Erkennungsfunktionen (`cluster slots``cluster shards`, und `cluster nodes` für Redis) oder `config get cluster`für Memcached statt Hostnamen zurück. IPs Die Hostnamen werden dann verwendet, anstatt eine Verbindung IPs zum ElastiCache Cluster herzustellen und einen TLS-Handshake durchzuführen. Das bedeutet, dass Clients nicht vom IP-Discovery-Parameter betroffen sind. Bei TLS-fähigen Clustern hat der IP Discovery-Parameter keine Auswirkung auf das bevorzugte IP-Protokoll. Stattdessen wird das verwendete IP-Protokoll dadurch bestimmt, welches IP-Protokoll der Client bei der Auflösung von DNS-Hostnamen bevorzugt.
**Java-Clients**
Wenn Sie eine Verbindung von einer Java-Umgebung aus herstellen, die IPv4 sowohl als auch unterstützt IPv6, wird Java aus IPv6 Gründen der Abwärtskompatibilität standardmäßig IPv4 den Vorzug geben. Die IP-Protokollpräferenz ist jedoch über die JVM-Argumente konfigurierbar. Zu bevorzugen IPv4, akzeptiert die JVM `-Djava.net.preferIPv4Stack=true` und bevorzugt IPv6 gesetzt. `-Djava.net.preferIPv6Stack=true` Die Einstellung `-Djava.net.preferIPv4Stack=true` bedeutet, dass die JVM keine Verbindungen mehr herstellt. IPv6 **Für Valkey oder Redis OSS umfasst dies auch die Verbindungen zu anderen Nicht-Valkey- und Nicht-Redis-OSS-Anwendungen.**
**Einstellungen auf Host-Ebene**
Wenn vom Client oder von der Client-Laufzeit keine Konfigurationsoptionen zum Festlegen einer IP-Protokollpräferenz bereitgestellt wird, hängt das IP-Protokoll bei der DNS-Auflösung im Allgemeinen von der Konfiguration des Hosts ab. Standardmäßig bevorzugen die meisten Hosts den Vorzug, IPv4 aber diese Einstellung kann IPv6 auf Host-Ebene konfiguriert werden. Dies wirkt sich auf alle DNS-Anfragen von diesem Host aus, nicht nur auf Anfragen an ElastiCache Cluster.
**Linux-Hosts**
Für Linux kann eine IP-Protokollpräferenz konfiguriert werden, indem die `gai.conf`-Datei geändert wird. Sie finden die `gai.conf`-Datei unter `/etc/gai.conf`. Wenn keine `gai.conf` angegeben ist, sollte ein Beispiel davon `/usr/share/doc/glibc-common-x.xx/gai.conf` verfügbar sein, das nach `/etc/gai.conf` kopiert werden kann. Die Standardkonfiguration sollte dann unkommentiert sein. Um die Konfiguration zu aktualisieren, die IPv4 bei der Verbindung zu einem ElastiCache Cluster bevorzugt wird, aktualisieren Sie die Priorität für den CIDR-Bereich, der den Cluster umfasst, so dass IPs sie über der Priorität für Standardverbindungen liegt. IPv6 Standardmäßig haben IPv6 Verbindungen eine Priorität von 40. Angenommen, der Cluster befindet sich in einem Subnetz mit dem CIDR 172.31.0. 0:0 /16, würde die folgende Konfiguration dazu führen, dass Clients Verbindungen zu diesem Cluster bevorzugen. IPv4
```
label ::1/128 0
label ::/0 1
label 2002::/16 2
label ::/96 3
label ::ffff:0:0/96 4
label fec0::/10 5
label fc00::/7 6
label 2001:0::/32 7
label ::ffff:172.31.0.0/112 8
#
# This default differs from the tables given in RFC 3484 by handling
# (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
# The reason for this difference is that these addresses are never
# NATed while IPv4 site-local addresses most probably are. Given
# the precedence of IPv6 over IPv4 (see below) on machines having only
# site-local IPv4 and IPv6 addresses a lookup for a global address would
# see the IPv6 be preferred. The result is a long delay because the
# site-local IPv6 addresses cannot be used while the IPv4 address is
# (at least for the foreseeable future) NATed. We also treat Teredo
# tunnels special.
#
# precedence
# Add another rule to the RFC 3484 precedence table. See section 2.1
# and 10.3 in RFC 3484. The default is:
#
precedence ::1/128 50
precedence ::/0 40
precedence 2002::/16 30
precedence ::/96 20
precedence ::ffff:0:0/96 10
precedence ::ffff:172.31.0.0/112 100
```
[Weitere Informationen dazu finden Sie auf der Linux-Manpage `gai.conf`](https://man7.org/linux/man-pages/man5/gai.conf.5.html)
**Windows-Hosts**
Der Prozess für Windows-Hosts ist ähnlich. Für Windows-Hosts können Sie `netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL` ausführen. Dies hat den gleichen Effekt wie das Ändern der `gai.conf`-Datei für Linux-Hosts.
Dadurch werden die Präferenzrichtlinien aktualisiert, sodass Verbindungen IPv4 IPv6 Verbindungen für den angegebenen CIDR-Bereich vorgezogen werden. Wenn beispielsweise angenommen wird, dass sich der Cluster in einem Subnetz befindet, in dem 172.31.0. 0:0 /16 CIDR ausgeführt wird, würde zu der folgenden Rangfolgetabelle führen, was dazu führen `netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15` würde, dass Clients eine Verbindung mit dem Cluster bevorzugen. IPv4
```
C:\Users\Administrator>netsh interface ipv6 show prefixpolicies
Querying active state...
Precedence Label Prefix
---------- ----- --------------------------------
100 15 ::ffff:172.31.0.0:0/112
20 4 ::ffff:0:0/96
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96
```
# Verwaltung von reserviertem Speicher für Valkey und Redis OSS
Reservierter Speicher ist Speicher, der nicht für Daten verwendet werden soll. Bei der Durchführung eines Backups oder Failovers verwenden Valkey und Redis OSS den verfügbaren Speicher, um Schreibvorgänge in Ihrem Cluster aufzuzeichnen, während die Daten des Clusters in die RDB-Datei geschrieben werden. Wenn nicht genügend Speicher für alle Schreibvorgängen zur Verfügung steht, tritt ein Fehler auf. Im Folgenden finden Sie Informationen zu Optionen für die Verwaltung von reserviertem Speicher ElastiCache für Redis OSS und zur Anwendung dieser Optionen.
**Topics**
+ [Wie viel reservierten Speicher benötigen Sie?](#redis-memory-management-need)
+ [Parameter zum Veralten von reserviertem Speicher](#redis-memory-management-parameters)
+ [Angabe Ihres Parameters für die Verwaltung reservierten Arbeitsspeichers](#redis-reserved-memory-management-change)
## Wie viel reservierten Speicher benötigen Sie?
Wenn Sie eine Version von Redis OSS vor 2.8.22 ausführen, reservieren Sie mehr Speicher für Backups und Failover, als wenn Sie Redis OSS 2.8.22 oder höher ausführen. Diese Anforderung ist auf die unterschiedlichen Arten zurückzuführen, mit denen der Backup-Prozess ElastiCache für Redis OSS implementiert wird. Als Faustregel gilt, die Hälfte des `maxmemory` Werts eines Knotentyps für Redis OSS-Overhead für Versionen vor 2.8.22 und ein Viertel für Redis OSS-Versionen 2.8.22 und höher zu reservieren.
Aufgrund der unterschiedlichen ElastiCache Implementierungsmethoden des Sicherungs- und Replikationsprozesses lautet die Faustregel, 25% des Werts eines Knotentyps mithilfe des Parameters zu reservieren. `maxmemory` `reserved-memory-percent` Dies ist der Standardwert und wird in den meisten Fällen empfohlen.
Wenn die Typen Burstable Micro und Small Instances in der Nähe der `maxmemory` Grenzwerte arbeiten, kann es zu Swap-Nutzung kommen. Um die Betriebssicherheit dieser Instance-Typen bei Backups, Replikationen und hohem Datenaufkommen zu verbessern, empfehlen wir, den Wert des `reserved-memory-percent` Parameters bei kleinen Instance-Typen um bis zu 30% und bei Micro-Instance-Typen um bis zu 50% zu erhöhen.
Für schreibintensive Workloads auf ElastiCache Clustern mit Daten-Tiering empfehlen wir, den verfügbaren Speicher des Knotens auf `reserved-memory-percent` bis zu 50% zu erhöhen.
Weitere Informationen finden Sie hier:
+ [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md)
+ [So werden Synchronisation und Backup implementiert](Replication.Redis.Versions.md)
+ [Datenzuweisung ElastiCache](data-tiering.md)
## Parameter zum Veralten von reserviertem Speicher
Seit dem 16. März 2017 ElastiCache bietet Amazon zwei sich gegenseitig ausschließende Parameter für die Verwaltung Ihres Valkey- oder Redis-OSS-Speichers und`reserved-memory`. `reserved-memory-percent` Keiner dieser Parameter ist Teil der Valkey- oder Redis-OSS-Distribution.
Je nachdem, wann Sie ElastiCache Kunde wurden, ist der eine oder andere dieser Parameter der Standardparameter für die Speicherverwaltung. Dieser Parameter gilt, wenn Sie einen neuen Valkey- oder Redis OSS-Cluster oder eine neue Replikationsgruppe erstellen und eine Standardparametergruppe verwenden.
+ Für Kunden, die vor dem 16. März 2017 damit angefangen haben: Wenn Sie einen Redis OSS-Cluster oder eine Redis-OSS-Cluster oder eine Redis-Replikationsgruppe mithilfe der Standardparametergruppe erstellen, lautet Ihr Speicherverwaltungsparameter. `reserved-memory` In diesem Fall werden null (0) Byte Speicher reserviert.
+ Für Kunden, die am oder nach dem 16. März 2017 angefangen haben: Wenn Sie einen Valkey- oder Redis OSS-Cluster oder eine Replikationsgruppe mithilfe der Standardparametergruppe erstellen, lautet Ihr Speicherverwaltungsparameter. `reserved-memory-percent` In diesem Fall sind 25 Prozent des `maxmemory`-Wertes Ihres Knotens für Nichtdatenzwecke reserviert.
Nachdem Sie sich mit den beiden Speicherverwaltungsparametern Valkey oder Redis OSS vertraut gemacht haben, ziehen Sie es vielleicht vor, den zu verwenden, der nicht Ihr Standard ist oder nicht die Standardwerte enthält. Wenn dies der Fall ist, können Sie zu dem anderen Verwaltungsparameter für reservierten Speicher wechseln.
Um den Wert dieses Parameters zu ändern, können Sie eine benutzerdefinierte Parametergruppe erstellen und sie ändern, um Ihren bevorzugten Speicherverwaltungsparameter und -wert zu verwenden. Sie können die benutzerdefinierte Parametergruppe dann immer dann verwenden, wenn Sie einen neuen Valkey- oder Redis OSS-Cluster oder eine neue Replikationsgruppe erstellen. Existierende Cluster und Replikationsgruppen können Sie so ändern, dass sie die benutzerdefinierte Parametergruppe verwenden.
Weitere Informationen finden Sie hier:
+ [Angabe Ihres Parameters für die Verwaltung reservierten Arbeitsspeichers](#redis-reserved-memory-management-change)
+ [Eine ElastiCache Parametergruppe erstellen](ParameterGroups.Creating.md)
+ [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md)
+ [Einen ElastiCache Cluster ändern](Clusters.Modify.md)
+ [Ändern einer Replikationsgruppe](Replication.Modify.md)
### Der Parameter "reserved-memory"
Vor dem 16. März 2017 wurde die gesamte Verwaltung des reservierten Speichers ElastiCache für Redis OSS mithilfe des Parameters durchgeführt. `reserved-memory` Der Standardwert von `reserved-memory` ist 0. Diese Standardeinstellung reserviert keinen Speicher für Valkey- oder Redis OSS-Overhead und ermöglicht es Valkey oder Redis OSS, den gesamten Speicher eines Knotens mit Daten zu verbrauchen.
Wenn Sie `reserved-memory` ändern, damit ausreichend Speicher für Sicherungen und Failovers zur Verfügung steht, müssen Sie eine benutzerdefinierte Parametergruppe erstellen. In dieser benutzerdefinierten Parametergruppe legen `reserved-memory` Sie einen Wert fest, der für die Valkey- oder Redis OSS-Version, die auf Ihrem Cluster ausgeführt wird, und für den Knotentyp des Clusters geeignet ist. Weitere Informationen finden Sie unter [Wie viel reservierten Speicher benötigen Sie?](#redis-memory-management-need).
Der Parameter `reserved-memory` ist spezifisch für die allgemeine Redis OSS-Distribution ElastiCache und nicht Teil dieser.
Das folgende Verfahren zeigt, wie Sie `reserved-memory` den Speicher auf Ihrem Valkey- oder Redis OSS-Cluster verwalten.
**So reservieren Sie Speicher mithilfe von reserviertem Speicher**
1. Erstellen Sie eine benutzerdefinierte Parametergruppe, indem Sie die Parametergruppenfamilie angeben, die der von Ihnen ausgeführten Engine-Version entspricht, z. B. indem Sie die `redis2.8`-Parametergruppenfamilie angeben. Weitere Informationen finden Sie unter [Eine ElastiCache Parametergruppe erstellen](ParameterGroups.Creating.md).
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name redis6x-m3xl \
--description "Redis OSS 2.8.x for m3.xlarge node type" \
--cache-parameter-group-family redis6.x
```
1. Berechnen Sie, wie viele Byte Speicher für den OSS-Overhead von Valkey oder Redis reserviert werden müssen. Sie finden den Wert von `maxmemory` für Ihren Knotentyp unter [Redis OSS-Knotentyp-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).
1. Ändern Sie die benutzerdefinierte Parametergruppe, sodass der Parameter `reserved-memory` der Anzahl von Bytes entspricht, die Sie im vorherigen Schritt berechnet haben. Im folgenden AWS CLI Beispiel wird davon ausgegangen, dass Sie eine Version von Redis OSS vor 2.8.22 ausführen und die Hälfte der Knoten reservieren müssen. `maxmemory` Weitere Informationen finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis28-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=7130316800"
```
Sie benötigen für jeden verwendeten Knotentyp eine eigene benutzerdefinierte Parametergruppe, da jeder Knotentyp einen anderen `maxmemory`-Wert hat. Daher benötigt jeder Knotentyp einen anderen Wert für `reserved-memory`.
1. Ändern Sie Ihren Redis OSS-Cluster oder Ihre Redis-Replikationsgruppe so, dass sie Ihre benutzerdefinierte Parametergruppe verwendet.
Mit dem folgenden CLI-Beispiel wird der Cluster ` my-redis-cluster` geändert, damit er ab sofort die benutzerdefinierte Parametergruppe `redis28-m3xl` verwendet. Weitere Informationen finden Sie unter [Einen ElastiCache Cluster ändern](Clusters.Modify.md).
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
Mit dem folgenden CLI-Beispiel wird die Replikationsgruppe `my-redis-repl-grp` geändert, damit sie ab sofort die benutzerdefinierte Parametergruppe `redis28-m3xl` verwendet. Weitere Informationen finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
### Der Parameter reserved-memory-percent
Am 16. März 2017 ElastiCache führte Amazon den Parameter ein `reserved-memory-percent` und stellte ihn in allen Versionen von ElastiCache for Redis OSS zur Verfügung. Der Zweck von `reserved-memory-percent` besteht darin, die Verwaltung des reservierten Speichers für alle Ihre Cluster zu vereinfachen. Dies wird dadurch erreicht, dass Sie eine einzige Parametergruppe für jede Parametergruppenfamilie (wie `redis2.8`) zur Verfügung haben, um den reservierten Speicher Ihrer Cluster unabhängig vom Knotentyp zu verwalten. Der Standardwert für `reserved-memory-percent` ist 25 (25 Prozent).
Der Parameter `reserved-memory-percent` ist spezifisch für die allgemeine Redis OSS-Distribution ElastiCache und nicht Teil davon.
Wenn Ihr Cluster einen Knotentyp aus der R6gd-Familie verwendet und Ihre Speicherauslastung 75 Prozent erreicht, wird Daten-Tiering automatisch ausgelöst. Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
**Um Speicher zu reservieren mit reserved-memory-percent**
Gehen Sie wie folgt vor`reserved-memory-percent`, um den Speicher auf Ihrem ElastiCache for Redis OSS-Cluster zu verwalten:
+ Wenn Sie Redis OSS 2.8.22 oder höher ausführen, weisen Sie Ihrem Cluster die Standardparametergruppe zu. Der Standardwert 25 Prozent sollte ausreichen. Falls nicht, führen Sie die folgenden Schritte aus, um den Wert zu ändern.
+ Wenn Sie eine Version von Redis OSS vor 2.8.22 ausführen, müssen Sie wahrscheinlich mehr Speicher als die standardmäßigen 25 Prozent reservieren. `reserved-memory-percent` Führen Sie dazu die folgenden Schritte aus.
**Um den Prozentwert von zu ändern reserved-memory-percent**
1. Erstellen Sie eine benutzerdefinierte Parametergruppe, indem Sie die Parametergruppenfamilie angeben, die der von Ihnen ausgeführten Engine-Version entspricht, z. B. indem Sie die `redis2.8`-Parametergruppenfamilie angeben. Eine benutzerdefinierte Parametergruppe ist erforderlich, da Sie eine Standardparametergruppe nicht ändern können. Weitere Informationen finden Sie unter [Eine ElastiCache Parametergruppe erstellen](ParameterGroups.Creating.md).
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name redis28-50 \
--description "Redis OSS 2.8.x 50% reserved" \
--cache-parameter-group-family redis2.8
```
Da `reserved-memory-percent` Speicher als Prozentanteil von `maxmemory` eines Knotens reserviert, benötigen Sie keine benutzerdefinierte Parametergruppe für jeden Knotentyp.
1. Ändern Sie die benutzerdefinierte Parametergruppe, sodass `reserved-memory-percent` 50 (50 Prozent) beträgt. Weitere Informationen finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis28-50 \
--parameter-name-values "ParameterName=reserved-memory-percent, ParameterValue=50"
```
1. Verwenden Sie diese benutzerdefinierte Parametergruppe für alle Redis OSS-Cluster oder Replikationsgruppen, auf denen eine Version von Redis OSS ausgeführt wird, die älter als 2.8.22 ist.
Das folgende CLI-Beispiel ändert den Redis OSS-Cluster so`my-redis-cluster`, dass er `redis28-50` ab sofort die benutzerdefinierte Parametergruppe verwendet. Weitere Informationen finden Sie unter [Einen ElastiCache Cluster ändern](Clusters.Modify.md).
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
Das folgende CLI-Beispiel ändert die Redis OSS-Replikationsgruppe so`my-redis-repl-grp`, dass sie `redis28-50` ab sofort die benutzerdefinierte Parametergruppe verwendet. Weitere Informationen finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
## Angabe Ihres Parameters für die Verwaltung reservierten Arbeitsspeichers
Wenn Sie am 16. März 2017 ein aktueller ElastiCache Kunde waren, lautet Ihr Standardparameter für die Verwaltung von reserviertem Speicher `reserved-memory` mit null (0) Byte reserviertem Speicher. Wenn Sie nach dem 16. März 2017 ElastiCache Kunde wurden, ist `reserved-memory-percent` Ihr Standardparameter für die Verwaltung von reserviertem Speicher so, dass 25 Prozent des Speichers des Knotens reserviert sind. Dies gilt unabhängig davon, wann Sie Ihren OSS-Cluster oder Ihre Replikationsgruppe ElastiCache für Redis erstellt haben. Sie können Ihren Parameter für die Verwaltung des reservierten Speichers jedoch entweder mithilfe der ElastiCache API AWS CLI oder ändern.
Die Parameter `reserved-memory` und `reserved-memory-percent` schließen sich gegenseitig aus. Eine Parametergruppe verfügt immer über einen dieser Parameter, niemals jedoch über beide. Sie können den Parameter ändern, den eine Parametergruppe für die Verwaltung von reserviertem Speicher verwendet, indem Sie die Parametergruppe ändern. Die Parametergruppe muss eine benutzerdefinierte Parametergruppe sein, da Sie die Standardparametergruppen nicht ändern können. Weitere Informationen finden Sie unter [Eine ElastiCache Parametergruppe erstellen](ParameterGroups.Creating.md).
**Um zu spezifizieren reserved-memory-percent**
Um `reserved-memory-percent` als Verwaltungsparameter für reservierten Speicher zu verwenden, ändern Sie eine benutzerdefinierte Parametergruppe mit dem `modify-cache-parameter-group`-Befehl. Verwenden Sie den `parameter-name-values`-Parameter zum Angeben von `reserved-memory-percent` sowie einen Wert dafür.
Mit dem folgenden CLI-Beispiel wird die benutzerdefinierte Parametergruppe `redis32-cluster-on` geändert, sodass sie `reserved-memory-percent` zum Verwalten von reserviertem Speicher verwendet. Für die Parametergruppe muss `ParameterValue` ein Wert zugewiesen werden, um den `ParameterName`-Parameter für die Verwaltung des reservierten Speichers zu verwenden. Weitere Informationen finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis32-cluster-on \
--parameter-name-values "ParameterName=reserved-memory-percent, ParameterValue=25"
```
**So geben Sie reserved-memory an**
Um `reserved-memory` als Verwaltungsparameter für reservierten Speicher zu verwenden, ändern Sie eine benutzerdefinierte Parametergruppe mit dem `modify-cache-parameter-group`-Befehl. Verwenden Sie den `parameter-name-values`-Parameter zum Angeben von `reserved-memory` sowie einen Wert dafür.
Mit dem folgenden CLI-Beispiel wird die benutzerdefinierte Parametergruppe `redis32-m3xl` geändert, sodass sie `reserved-memory` zum Verwalten von reserviertem Speicher verwendet. Für die Parametergruppe muss `ParameterValue` ein Wert zugewiesen werden, um den `ParameterName`-Parameter für die Verwaltung des reservierten Speichers zu verwenden. Da die Engine-Version höher als 2.8.22 ist, wird der Wert auf `3565158400` gesetzt. Dieser Wert entspricht 25 % des Werts von `maxmemory` für `cache.m3.xlarge`. Weitere Informationen finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis32-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=3565158400"
```
# Bewährte Methoden bei der Arbeit mit nodenbasierten Valkey- und Redis OSS-Clustern
Multi-AZ-Nutzung, ausreichender Arbeitsspeicher, Clustergrößenänderung und Minimierung von Ausfallzeiten sind alles nützliche Konzepte, die Sie bei der Arbeit mit knotenbasierten Clustern in Valkey oder Redis OSS berücksichtigen sollten. Wir empfehlen Ihnen, sich mit diesen bewährten Methode vertraut zu machen und sie zu befolgen.
**Topics**
+ [Minimierung von Ausfallzeiten mit Multi-AZ](multi-az.md)
+ [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md)
+ [Online-Größenanpassung von Clustern](best-practices-online-resharding.md)
+ [Minimieren der Ausfallzeit während der Wartung](BestPractices.MinimizeDowntime.md)
# Minimierung von Ausfallzeiten mit Multi-AZ
Es gibt eine Reihe von Fällen, in denen ElastiCache Valkey oder Redis OSS möglicherweise einen Primärknoten ersetzen müssen. Dazu gehören bestimmte Arten von geplanten Wartungsarbeiten und der unwahrscheinliche Fall eines Ausfalls eines Primärknotens oder einer Availability Zone.
Dieser Austausch führt zu einer gewissen Ausfallzeit für den Cluster, aber wenn Multi-AZ aktiviert ist, wird die Ausfallzeit minimiert. Die Rolle des primären Knotens wird automatisch auf eines der Read Replicas übertragen. Es ist nicht erforderlich, einen neuen Primärknoten zu erstellen und bereitzustellen, da dies transparent ElastiCache gehandhabt wird. Dieser Failover und die Replikatheraufstufung stellen sicher, dass Sie weiter in den neuen primären Knoten schreiben können, sobald die Heraufstufung abgeschlossen wurde.
Weitere Informationen [Minimierung von Ausfallzeiten durch die Verwendung ElastiCache von Multi-AZ mit Valkey und Redis OSS](AutoFailover.md) über Multi-AZ und die Minimierung von Ausfallzeiten finden Sie unter.
# Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen
**Snapshots und Synchronisationen in Valkey 7.2 und höher sowie Redis OSS Version 2.8.22 und höher**
Valkey unterstützt standardmäßig Snapshots und Synchronisationen. Redis OSS 2.8.22 führt einen forkless-Speicherprozess ein, der es Ihnen ermöglicht, einen größeren Teil Ihres Speichers für die Nutzung durch Ihre Anwendung zuzuweisen, ohne dass es bei Synchronisationen und Speichervorgängen zu einer erhöhten Swap-Nutzung kommt. Weitere Informationen finden Sie unter [So werden Synchronisation und Backup implementiert](Replication.Redis.Versions.md).
**Redis OSS-Snapshots und Synchronisationen vor Version 2.8.22**
Wenn Sie mit ElastiCache for Redis OSS arbeiten, ruft Redis OSS in einer Reihe von Fällen einen Schreibbefehl im Hintergrund auf:
+ Beim Erstellen eines Snapshots für eine Sicherung
+ Beim Synchronisieren von Replikaten mit dem primären Cluster in einer Replikationsgruppe
+ Wenn Sie die Funktion „Nur Dateien anhängen“ (AOF) für Redis OSS aktivieren.
+ Beim Hochstufen eines Replikats zu einem primären (was eine primäre/Replikat-Synchronisierung verursacht).
Immer wenn Redis OSS einen Schreibvorgang im Hintergrund ausführt, müssen Sie über ausreichend verfügbaren Speicher verfügen, um den Prozessaufwand zu bewältigen. Wenn nicht genügend Arbeitsspeicher verfügbar ist, schlägt der Vorgang fehl. Aus diesem Grund ist es wichtig, bei der Erstellung Ihres Redis OSS-Clusters einen Knoteninstanztyp auszuwählen, der über ausreichend Speicher verfügt.
## Schreibvorgang im Hintergrund und Speichernutzung mit Valkey und Redis OSS
Immer wenn ein Schreibvorgang im Hintergrund aufgerufen wird, forken Valkey und Redis OSS seinen Prozess ab (denken Sie daran, dass diese Engines Single-Threading verwenden). Ein Fork speichert Ihre Daten auf der Festplatte in einer Redis OSS .rdb-Snapshot-Datei. Die andere Vergabelung führt alle Lese- und Schreibvorgänge durch. Um sicherzustellen, dass es sich bei Ihrem point-in-time Snapshot um einen Snapshot handelt, werden alle Datenaktualisierungen und Ergänzungen in einen vom Datenbereich getrennten Bereich des verfügbaren Speichers geschrieben.
Solange genügend Arbeitsspeicher zum Aufzeichnen aller Schreibvorgänge verfügbar ist, während die Daten dauerhaft auf dem Datenträger erhalten bleiben, treten keine Probleme aufgrund von Speichermangel auf. Wenn vermehrt Probleme aufgrund von Speichermangel auftreten, treffen beliebige der folgenden Situationen ein:
+ Ihre Anwendung führt viele Schreibvorgänge aus und benötigt daher eine große Menge an verfügbarem Arbeitsspeicher zum Akzeptieren neuer oder aktualisierter Daten.
+ Es ist sehr wenig Arbeitsspeicher zum Schreiben neuer oder aktualisierter Daten verfügbar.
+ Die dauerhafte Erhaltung eines großen Datensatzes auf der Festplatte dauert eine lange Zeit und erfordert eine große Anzahl von Schreibvorgängen.
Das folgende Diagramm veranschaulicht die Speichernutzung beim Ausführen eines Hintergrundschreibvorgangs.
![\[Abbildung: Diagramm der Speichernutzung während eines Hintergrundschreibvorgangs.\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCache-bgsaveMemoryUseage.png)
Informationen zu den Auswirkungen einer Sicherung auf die Leistung finden Sie unter [Auswirkungen von Backups knotenbasierter Cluster auf die Leistung](backups.md#backups-performance).
[Weitere Informationen darüber, wie Valkey und Redis OSS Snapshots durchführen, finden Sie unter http://valkey.io.](http://valkey.io)
Weitere Informationen zu Regionen und Availability Zones finden Sie unter [Auswahl von Regionen und Verfügbarkeitszonen für ElastiCache](RegionsAndAZs.md).
## Vermeidung von Speichermangel beim Ausführen eines Hintergrundschreibvorgangs
Immer wenn ein Schreibvorgang im Hintergrund wie `BGSAVE` oder aufgerufen `BGREWRITEAOF` wird, muss mehr Speicher verfügbar sein, als durch Schreibvorgänge während des Vorgangs verbraucht wird, um zu verhindern, dass der Prozess fehlschlägt. Im schlimmsten Fall wird während des Schreibvorgangs im Hintergrund jeder Datensatz aktualisiert und einige neue Datensätze werden dem Cache hinzugefügt. Aus diesem Grund empfehlen wir, den Wert `reserved-memory-percent` auf 50 (50 Prozent) für Redis OSS-Versionen vor 2.8.22 oder 25 (25 Prozent) für Valkey und alle Redis OSS-Versionen 2.8.22 und höher festzulegen.
Der Wert `maxmemory` gibt den für die Daten und den Betriebsaufwand verfügbaren Arbeitsspeicher an. Da der Parameter `reserved-memory` in der Standardparametergruppe nicht geändert werden kann, müssen Sie eine benutzerdefinierte Parametergruppe für den Cluster erstellen. Der Standardwert für `reserved-memory` ist 0, was es Redis OSS ermöglicht, den gesamten *maximalen Speicher mit Daten zu verbrauchen, sodass möglicherweise zu wenig Speicher* für andere Zwecke übrig bleibt, z. B. für einen Schreibvorgang im Hintergrund. Informationen zu `maxmemory`-Werten nach Knoten-Instance-Typ finden Sie unter [Redis OSS-Knotentyp-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).
Sie können `reserved-memory` Parameter auch verwenden, um den Speicherverbrauch auf der Box zu reduzieren.
Weitere Informationen zu Valkey- und Redis-spezifischen Parametern finden Sie unter. ElastiCache [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis)
Weitere Informationen zum Erstellen und Ändern von Parametergruppen finden Sie unter [Eine ElastiCache Parametergruppe erstellen](ParameterGroups.Creating.md) und [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md).
# Online-Größenanpassung von Clustern
*Resharding* umfasst das Hinzufügen und Entfernen von Shards oder Knoten für den Cluster sowie die Neuverteilung von Schlüsselräumen. Daher haben viele Aspekte Einfluss auf die Resharding-Operation, z. B. Workload des Clusters, Speichernutzung und allgemeine Datengröße. Für optimale Ergebnisse empfehlen wir, dass Sie die allgemeinen bewährten Methoden zu Clustern für eine gleichmäßige Verteilung von Workload-Verteilung befolgen. Außerdem empfehlen wir, die folgenden Schritte durchzuführen.
Vor dem Beginn des Resharding sollten Sie Folgendes durchführen:
+ **Testen Sie Ihre Anwendung** – Testen Sie das Verhalten Ihrer Anwendung während des Reshardings nach Möglichkeit in einer Staging-Umgebung.
+ **Erhalten Sie frühzeitige Benachrichtigungen bei Skalierungsproblemen** – Resharding ist ein rechenintensiver Vorgang. Aus diesem Grund empfehlen wir, beim Resharding die CPU-Auslastung bei Multicore-Instances unter 80 Prozent und bei Single-Core-Instances unter 50 Prozent zu halten. Überwachen Sie ElastiCache die OSS-Metriken von Redis und initiieren Sie das Resharding, bevor Ihre Anwendung Skalierungsprobleme beobachtet. Die Überwachung folgender Metriken ist nützlich: `CPUUtilization`, `NetworkBytesIn`, `NetworkBytesOut`, `CurrConnections`, `NewConnections`, `FreeableMemory`, `SwapUsage` und `BytesUsedForCacheItems`.
+ **Stellen Sie vor dem Hochskalieren sicher, dass ausreichend freier Speicher verfügbar ist** – Stellen Sie beim Hochskalieren sicher, dass der freie Speicher auf den beizubehaltenden Shards mindestens das 1,5-fache des Arbeitsspeichers beträgt, der auf den Shards verwendet wird, die Sie entfernen möchten.
+ **Initiieren Sie Resharding außerhalb der Spitzenzeiten** – Diese Vorgehensweise hilft, die Auswirkungen auf die Latenz und den Durchsatz auf den Client während des Resharding-Vorgangs zu reduzieren. Außerdem wird das Resharding schneller abgeschlossen, da bei der Slot-Verteilung mehr Ressourcen verwendet werden können.
+ **Überprüfen Sie das Client-Timeout-Verhalten** – Einige Clients stellen möglicherweise eine höhere Latenz während der Online-Cluster-Größenänderung fest. Es kann helfen, bei Ihrer Client-Bibliothek einen höheren Timeout zu konfigurieren, da dem System so Zeit zur Verbindungsherstellung unter höheren Lastbedingungen auf dem Server gegeben wird. Manchmal wird eine große Anzahl an Verbindungen zum Server geöffnet. Fügen Sie in diesen Fällen exponentielles Backoff hinzu, um Logik erneut zu verbinden. Hierdurch wird verhindert, dass ein Schub neuer Verbindungen den Server gleichzeitig erreicht.
+ **Laden Sie Ihre Funktionen auf jeden Shard** — Beim Skalieren Ihres Clusters ElastiCache werden die Funktionen, die in einem der vorhandenen Knoten geladen wurden (zufällig ausgewählt), automatisch auf die neuen Knoten repliziert. Wenn Ihr Cluster über Valkey 7.2 und höher oder Redis OSS 7.0 oder höher verfügt und Ihre Anwendung [Functions](https://valkey.io/topics/functions-intro/) verwendet, empfehlen wir, alle Ihre Funktionen vor dem Skalieren auf alle Shards zu laden, damit Ihr Cluster nicht mit unterschiedlichen Funktionen auf verschiedenen Shards endet.
Beachten Sie nach dem Resharding Folgendes:
+ Die Skalierung nach oben ist möglicherweise nur zum Teil erfolgreich, wenn auf den Ziel-Shards nicht ausreichend Arbeitsspeicher verfügbar ist. In diesem Fall prüfen Sie den verfügbaren Speicher und wiederholen Sie ggf. die Operation. Die Daten auf den Ziel-Shards werden nicht gelöscht.
+ Die Befehle `FLUSHALL` und `FLUSHDB` werden in Lua-Skripten während eines Resharding-Vorgangs nicht unterstützt. Vor Redis OSS 6 wurde der `BRPOPLPUSH` Befehl nicht unterstützt, wenn er auf dem zu migrierenden Steckplatz ausgeführt wird.
# Minimieren der Ausfallzeit während der Wartung
Die Konfiguration des Cluster-Modus ist am besten im Rahmen verwalteter oder nicht verwalteter Operationen verfügbar. Es wird empfohlen, einen im Cluster-Modus unterstützten Client zu verwenden, der eine Verbindung mit dem Clusterermittlungsendpunkt herstellt. Bei deaktiviertem Cluster-Modus empfehlen wir, den primären Endpunkt für alle Schreiboperationen zu verwenden.
Für Lesevorgänge können Anwendungen Verbindungen zu jedem Knoten im Cluster herstellen. Im Gegensatz zum primären Endpunkt werden Knotenendpunkte auf bestimmte Endpunkte aufgelöst. Wenn Sie eine Änderung am Cluster vornehmen, wie z. B. Hinzufügen oder Löschen eines Replikats, müssen Sie die Knotenendpunkte in Ihrer Anwendung aktualisieren. Bei deaktiviertem Cluster-Modus empfehlen wir daher, den Reader-Endpunkt für Leseaktivitäten zu verwenden.
Wenn im Cluster aktiviert AutoFailover ist, kann sich der primäre Knoten ändern. Daher sollte die Anwendung die Rolle des Knotens bestätigen und alle Leseendpunkte aktualisieren. Dadurch wird sichergestellt, dass Sie keine große Belastung des primären Knotens verursachen. Bei AutoFailover deaktivierter Option ändert sich die Rolle des Knotens nicht. Die Ausfallzeiten bei verwalteten oder nicht verwalteten Vorgängen sind jedoch höher als bei Clustern mit AutoFailover aktivierter Option.
Vermeiden Sie es, Leseanforderungen an einen einzelnen Read-Replica-Knoten weiterzuleiten, da dessen Nichtverfügbarkeit zu einem Leseausfall führen könnte. Entweder Sie greifen auf das Lesen vom Primärknoten zurück oder stellen sicher, dass Sie über mindestens zwei Read Replicas verfügen, um Leseunterbrechungen während der Wartung zu vermeiden.
# Caching-Strategien für Memcached
Im folgenden Thema finden Sie Strategien zum Auffüllen und Verwalten Ihres Memcached-Caches.
Welche Strategien Sie zum Auffüllen und Verwalten Ihres Cache implementieren müssen, hängt von den zwischengespeicherten Daten und den Zugriffsmustern auf diese Daten ab. Zum Beispiel möchten Sie wahrscheinlich nicht dieselbe Strategie für eine Top-10-Bestenliste auf einer Spieleseite und für trendige Nachrichten verwenden. Im Rest dieses Abschnitts besprechen wir gängige Cache-Wartungsstrategien und ihre Vor- und Nachteile.
**Topics**
+ [Read Replicas](#Strategies.ReadReplicas)
+ [Lazy Loading](#Strategies.LazyLoading)
+ [Write-Through](#Strategies.WriteThrough)
+ [Hinzufügen von TTL](#Strategies.WithTTL)
+ [Verwandte Themen](#Strategies.SeeAlso)
## Read Replicas
Sie können die Leistung ElastiCache serverloser Caches häufig erheblich verbessern, indem Sie Replikate erstellen und aus ihnen lesen, anstatt sie vom primären Cache-Knoten aus zu lesen. Weitere Informationen finden Sie unter [Bewährte Methoden für die Verwendung von Read Replicas](ReadReplicas.md).
## Lazy Loading
Wie der Name schon sagt, ist *Lazy Loading* (“langsames Laden“) eine Caching-Strategie, die Daten nur bei Bedarf in den Cache lädt. Es funktioniert folgendermaßen.
Amazon ElastiCache ist ein speicherinterner Schlüsselwertspeicher, der sich zwischen Ihrer Anwendung und dem Datenspeicher (Datenbank) befindet, auf den sie zugreift. Immer wenn Ihre Anwendung Daten anfordert, sendet sie die Anfrage zuerst an den Cache. ElastiCache Wenn die Daten im Cache vorhanden und aktuell sind, gibt ElastiCache die Daten an Ihre Anwendung zurück. Wenn die Daten nicht im Cache vorhanden sind oder abgelaufen sind, fordert Ihre Anwendung die Daten von Ihrem Datenspeicher an. Ihr Datenspeicher gibt die Daten dann an Ihre Anwendung zurück. Als nächstes schreibt Ihre Anwendung die vom Speicher empfangenen Daten in den Cache. Auf diese Weise können sie bei der nächsten Anforderung schneller abgerufen werden.
Ein *Cache-Treffer* tritt auf, wenn sich Daten im Cache befinden und nicht abgelaufen sind:
1. Die Anwendung fordert Daten aus dem Cache an.
1. Der Cache gibt die Daten an die Anwendung zurück.
Ein *Cache-Fehltreffer* tritt auf, wenn sich Daten nicht im Cache befinden oder abgelaufen sind:
1. Die Anwendung fordert Daten vom Cache an.
1. Der Cache enthält die angeforderten Daten nicht und gibt daher `null` zurück.
1. Ihre Anwendung fordert die Daten an und erhält sie aus der Datenbank.
1. Ihre Anwendung aktualisiert den Cache mit den neuen Daten.
### Vor- und Nachteile von Lazy Loading
Die Vorteile von Lazy Loading sind:
+ Es werden nur die angeforderten Daten im Cache abgelegt.
Da die meisten Daten nie angefordert werden, wird durch Lazy Loading vermieden, dass der Cache mit nicht angeforderten Daten gefüllt wird.
+ Knotenfehler sind für Ihre Anwendung nicht fatal.
Wenn ein Knoten ausfällt und durch einen neuen, leeren Knoten ersetzt wird, funktioniert Ihre Anwendung weiterhin, allerdings mit erhöhter Latenz. Wenn Anforderungen an den neuen Knoten gestellt werden, führt jeder Cache-Fehltreffer zu einer Abfrage der Datenbank. Gleichzeitig wird die Datenkopie dem Cache hinzugefügt, so dass nachfolgende Anforderungen aus dem Cache abgerufen werden.
Die Nachteile von Lazy Loading sind:
+ Bei Cache-Fehlschlägen gibt es Verzögerungen. Jeder Cache-Fehltreffer führt zu drei Übertragungsvorgängen:
1. Anfängliche Anforderung von Daten aus dem Cache
1. Abfrage der Daten aus der Datenbank
1. Schreiben der Daten in den Cache
Diese Fehltreffer können zu einer merklichen Verzögerung beim Eingang der Daten in die Anwendung führen.
+ Veraltete Daten.
Wenn Daten nur bei einem Cache-Fehltreffer in den Cache geschrieben werden, können Daten im Cache veraltet sein. Dieses Ergebnis tritt auf, weil der Cache nicht aktualisiert wird, wenn Daten in der Datenbank geändert werden. Um dieses Problem zu beheben, können Sie die [Write-Through](#Strategies.WriteThrough) und [Hinzufügen von TTL](#Strategies.WithTTL)-Strategien anwenden.
### Beispiel für Lazy Loading Pseudocode
Im Folgenden finden Sie ein Pseudocode-Beispiel für Lazy Loading-Logik.
```
// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is
// retrieved from the database,
// added to the cache, and
// returned to the application
// *****************************************
get_customer(customer_id)
customer_record = cache.get(customer_id)
if (customer_record == null)
customer_record = db.query("SELECT * FROM Customers WHERE id = {0}", customer_id)
cache.set(customer_id, customer_record)
return customer_record
```
In diesem Beispiel sieht der Anwendungscode, der die Daten abruft, wie folgt aus.
```
customer_record = get_customer(12345)
```
## Write-Through
Die Write-Through-Strategie fügt dem Cache Daten hinzu oder aktualisiert Daten im Cache, wenn Daten in die Datenbank geschrieben werden.
### Vor- und Nachteile von Write-Through
Die Vorteile von Write-Through sind:
+ Die Daten im Cache sind nie veraltet.
Da die Daten im Cache jedes Mal aktualisiert werden, wenn sie in die Datenbank geschrieben werden, sind die Daten im Cache immer aktuell.
+ Schreibstrafe im Vergleich zu Lesestrafe.
Jeder Schreibvorgang umfasst zwei Übertragungsvorgänge:
1. Ein Schreibvorgang in den Cache
1. Ein Schreibvorgang in die Datenbank
Dadurch wird die Latenz des Prozesses erhöht. Endbenutzer tolerieren im Allgemeinen Latenz beim Aktualisieren von Daten eher als beim Abrufen. Aktualisierungen werden als arbeits- und zeitintensiver wahrgenommen.
Die Nachteile von Write-Through sind:
+ Fehlende Daten.
Wenn Sie einen neuen Knoten hochfahren, sei es aufgrund eines Knotenfehlers oder einer horizontalen Skalierung, fehlen Daten. Diese Daten fehlen weiterhin, bis sie in der Datenbank hinzugefügt oder aktualisiert werden. Sie können dies minimieren, indem Sie [Lazy Loading](#Strategies.LazyLoading) mit Write-Through implementieren.
+ Cache-Änderung.
Die meisten Daten werden nie gelesen, was eine Verschwendung von Ressourcen darstellt. Durch [Hinzufügen eines Time-to-Live-Werts (TTL)](#Strategies.WithTTL) können Sie verschwendeten Speicherplatz minimieren.
### Beispiel für Write-Through-Pseudocode
Das Folgende ist ein Pseudocode-Beispiel für Write-Through-Logik.
```
// *****************************************
// function that saves a customer's record.
// *****************************************
save_customer(customer_id, values)
customer_record = db.query("UPDATE Customers WHERE id = {0}", customer_id, values)
cache.set(customer_id, customer_record)
return success
```
In diesem Beispiel sieht der Anwendungscode, der die Daten abruft, wie folgt aus.
```
save_customer(12345,{"address":"123 Main"})
```
## Hinzufügen von TTL
Lazy Loading ermöglicht veraltete Daten, schlägt jedoch nicht wegen leeren Knoten fehl. Write-Through stellt sicher, dass die Daten immer frisch sind, kann aber bei leeren Knoten fehlschlagen und den Cache mit überflüssigen Daten füllen. Indem Sie jedem Schreibvorgang einen Time-to-Live-Wert (TTL) hinzufügen, können Sie die Vorteile jeder Strategie nutzen. Gleichzeitig können Sie das Überladen des Caches mit zusätzlichen Daten weitgehend vermeiden.
*Time to Live (TTL)* ist ein ganzzahliger Wert, der die Anzahl der Sekunden angibt, bis der Schlüssel abläuft. Valkey oder Redis OSS können Sekunden oder Millisekunden für diesen Wert angeben. Memcached gibt diesen Wert in Sekunden an. Wenn eine Anwendung versucht, einen abgelaufenen Schlüssel zu lesen, gilt der Schlüssel als nicht gefunden. Die Datenbank wird nach dem Schlüssel abgefragt und der Cache aktualisiert. Dieser Ansatz garantiert nicht, dass ein Wert nicht veraltet ist. Er verhindert jedoch, dass die Daten zu veraltet werden, und erfordert, dass Werte im Cache gelegentlich aus der Datenbank aktualisiert werden.
[Weitere Informationen finden Sie unter den OSS-Befehlen [Valkey und Redis](https://valkey.io/commands) oder den Memcached-Befehlen. `set`](https://www.tutorialspoint.com/memcached/memcached_set_data.htm)
### Beispiele für TTL Pseudocode
Das Folgende ist ein Pseudocode-Beispiel für Write-Through-Logik mit TTL.
```
// *****************************************
// function that saves a customer's record.
// The TTL value of 300 means that the record expires
// 300 seconds (5 minutes) after the set command
// and future reads will have to query the database.
// *****************************************
save_customer(customer_id, values)
customer_record = db.query("UPDATE Customers WHERE id = {0}", customer_id, values)
cache.set(customer_id, customer_record, 300)
return success
```
Das Folgende ist ein Pseudocode-Beispiel für Lazy-Loading-Logik mit TTL.
```
// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is
// retrieved from the database,
// added to the cache, and
// returned to the application.
// The TTL value of 300 means that the record expires
// 300 seconds (5 minutes) after the set command
// and subsequent reads will have to query the database.
// *****************************************
get_customer(customer_id)
customer_record = cache.get(customer_id)
if (customer_record != null)
if (customer_record.TTL < 300)
return customer_record // return the record and exit function
// do this only if the record did not exist in the cache OR
// the TTL was >= 300, i.e., the record in the cache had expired.
customer_record = db.query("SELECT * FROM Customers WHERE id = {0}", customer_id)
cache.set(customer_id, customer_record, 300) // update the cache
return customer_record // return the newly retrieved record and exit function
```
In diesem Beispiel sieht der Anwendungscode, der die Daten abruft, wie folgt aus.
```
save_customer(12345,{"address":"123 Main"})
```
```
customer_record = get_customer(12345)
```
## Verwandte Themen
+ [In-Memory-Datastore](elasticache-use-cases.md#elasticache-use-cases-data-store)
+ [Auswählen einer Engine und einer Version](SelectEngine.md)
+ [Skalierung ElastiCache](Scaling.md)
# Verwaltung Ihres knotenbasierten Clusters in ElastiCache
ElastiCache bietet zwei Bereitstellungsoptionen: serverlose Caches und knotenbasierte Cluster. Jeder hat seine eigenen Fähigkeiten und Anforderungen.
Dieser Abschnitt enthält Themen, die Sie bei der Verwaltung Ihrer knotenbasierten Cluster unterstützen.
**Anmerkung**
Diese Themen gelten nicht für Serverless. ElastiCache
**Topics**
+ [Auto Scaling Valkey- und Redis OSS-Cluster](AutoScaling.md)
+ [Ändern des Clustermodus](modify-cluster-mode.md)
+ [AWS Regionsübergreifende Replikation mithilfe globaler Datenspeicher](Redis-Global-Datastore.md)
+ [Hohe Verfügbarkeit mit Replikationsgruppen](Replication.md)
+ [Verwaltung der ElastiCache Cluster-Wartung](maintenance-window.md)
+ [Konfiguration von Motorparametern mithilfe von ElastiCache Parametergruppen](ParameterGroups.md)
# Auto Scaling Valkey- und Redis OSS-Cluster
## Voraussetzungen
ElastiCache Auto Scaling ist auf Folgendes beschränkt:
+ Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert), auf denen Valkey 7.2 oder Redis OSS 6.0 oder höher ausgeführt wird
+ Cluster mit Datenklassierung (Clustermodus aktiviert), auf denen Valkey 7.2 oder Redis OSS 7.0.7 oder höher ausgeführt wird
+ Instanzgrößen: Groß, 2 XLarge XLarge
+ Instance-Familien – R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn
+ Auto Scaling in ElastiCache wird nicht für Cluster unterstützt, die in globalen Datenspeichern, Outposts oder Local Zones ausgeführt werden.
## Automatisches Kapazitätsmanagement mit ElastiCache Auto Scaling mit Valkey oder Redis OSS
ElastiCache Auto Scaling mit Valkey oder Redis OSS ist die Möglichkeit, die gewünschten Shards oder Replikate in Ihrem Service automatisch zu erhöhen oder zu verringern. ElastiCache ElastiCache nutzt den Application Auto Scaling Scaling-Dienst, um diese Funktionalität bereitzustellen. Weitere Informationen finden Sie unter [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). Um die automatische Skalierung zu verwenden, definieren und wenden Sie eine Skalierungsrichtlinie an, die von Ihnen CloudWatch zugewiesene Metriken und Zielwerte verwendet. ElastiCache Auto Scaling verwendet die Richtlinie, um die Anzahl der Instanzen als Reaktion auf tatsächliche Workloads zu erhöhen oder zu verringern.
Sie können die verwenden AWS-Managementkonsole, um eine Skalierungsrichtlinie anzuwenden, die auf einer vordefinierten Metrik basiert. Eine `predefined metric` ist in einer Aufzählung definiert, sodass Sie sie im Code durch einen Namen angeben oder in der AWS-Managementkonsole verwenden können. Benutzerdefinierte Metriken können nicht über die AWS-Managementkonsole ausgewählt werden. Alternativ können Sie entweder die AWS CLI oder die Application Auto Scaling-API verwenden, um eine Skalierungsrichtlinie anzuwenden, die auf einer vordefinierten oder benutzerdefinierten Metrik basiert.
ElastiCache für Valkey und Redis unterstützt OSS die Skalierung für die folgenden Dimensionen:
+ **Shards**— Automatisches Hinzufügen/Entfernen von Shards im Cluster ähnlich wie beim manuellen Online-Resharding. In diesem Fall löst ElastiCache Auto Scaling die Skalierung in Ihrem Namen aus.
+ **Replikate** — Automatisch und add/remove replicas in the cluster similar to manual Increase/Decrease replica operations. ElastiCache auto scaling for Valkey and Redis OSS adds/removes einheitlich auf allen Shards im Cluster repliziert.
ElastiCache für Valkey und Redis unterstützt OSS die folgenden Arten von Richtlinien für die automatische Skalierung:
+ [Skalierungsrichtlinien für die Ziel-Nachverfolgung](AutoScaling-Scaling-Policies-Target.md)— Erhöhen oder verringern Sie die Anzahl shards/replicas , mit der Ihr Service ausgeführt wird, basierend auf einem Zielwert für eine bestimmte Metrik. Dies ähnelt der Art und Weise, wie ein Thermostat die Temperatur in Ihrem Zuhause konstant hält. Sie wählen eine Temperatur aus und der Thermostat erledigt den Rest.
+ [Geplante Skalierung für Ihre Anwendung.](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) — ElastiCache Für Valkey und Redis kann OSS Auto Scaling die Anzahl der ausgeführten shards/replicas Dienste je nach Datum und Uhrzeit erhöhen oder verringern.
![\[Bild der auto Skalierung ElastiCache für Valkey und Redis OSS\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/Auto-scaling.png)
Die folgenden Schritte fassen den auto Skalierungsprozess ElastiCache für Valkey und Redis OSS zusammen, wie im vorherigen Diagramm dargestellt:
1. Sie erstellen eine ElastiCache Auto Scaling-Richtlinie für Ihre Replikationsgruppe.
1. ElastiCache Auto Scaling erstellt in Ihrem Namen ein Paar CloudWatch Alarme. Jedes Paar stellt die Ober- und Untergrenze für Metriken dar. Diese CloudWatch Alarme werden ausgelöst, wenn die tatsächliche Auslastung des Clusters über einen längeren Zeitraum von Ihrer Zielauslastung abweicht. Sie können jetzt -Alarme in der -Konsole anzeigen.
1. Wenn der konfigurierte Metrikwert Ihre Zielauslastung für einen bestimmten Zeitraum überschreitet (oder unter das Ziel fällt), wird ein Alarm CloudWatch ausgelöst, der Auto Scaling zur Bewertung Ihrer Skalierungsrichtlinie auslöst.
1. ElastiCache Auto Scaling gibt eine Modifizierungsanforderung aus, um Ihre Clusterkapazität anzupassen.
1. ElastiCache verarbeitet die Modifizierungsanforderung und erhöht (oder verringert) die Shards/Replicas Clusterkapazität dynamisch, sodass sie sich Ihrer Zielauslastung annähert.
Um zu verstehen, wie ElastiCache Auto Scaling funktioniert, nehmen wir an, Sie haben einen Cluster mit dem Namen`UsersCluster`. Durch die Überwachung der CloudWatch Metriken bestimmen Sie die maximale Anzahl an Shards, die der Cluster benötigt, wenn der Verkehr seinen Höhepunkt erreicht, und die Mindestanzahl an Shards, wenn der Verkehr am niedrigsten Punkt ist. `UsersCluster` Sie legen auch einen Zielwert für die CPU-Auslastung für den `UsersCluster` Cluster fest. ElastiCache Auto Scaling verwendet seinen Target-Tracking-Algorithmus, um sicherzustellen, dass die bereitgestellten Shards von `UsersCluster` nach Bedarf angepasst werden, sodass die Auslastung auf oder nahe dem Zielwert bleibt.
**Anmerkung**
Die Skalierung kann viel Zeit in Anspruch nehmen und erfordert zusätzliche Cluster-Ressourcen, damit die Shards wieder ausgeglichen werden können. ElastiCache Auto Scaling ändert die Ressourceneinstellungen nur, wenn die tatsächliche Arbeitslast über einen längeren Zeitraum von mehreren Minuten erhöht (oder reduziert) bleibt. Der Auto Scaling Target-Tracking-Algorithmus versucht, die Zielauslastung langfristig auf oder nahe dem von Ihnen gewählten Wert zu halten.
# Auto-Scaling-Richtlinien
Eine Skalierungsrichtlinie enthält die folgenden Komponenten:
+ Eine Zielmetrik — Die CloudWatch Metrik, die ElastiCache für Valkey und Redis OSS Auto Scaling verwendet, um zu bestimmen, wann und wie stark skaliert werden soll.
+ Minimale und maximale Kapazität — Die minimale und die maximale Anzahl an Shards oder Replikaten, die für die Skalierung verwendet werden sollen.
**Wichtig**
Wenn bei der Erstellung der Auto Scaling-Richtlinie die aktuelle Kapazität höher als die konfigurierte maximale Kapazität ist, skalieren wir MaxCapacity bei der Richtlinienerstellung entsprechend. Wenn die aktuelle Kapazität unter der konfigurierten Mindestkapazität liegt, skalieren wir ebenfalls auf die. MinCapacity
+ Eine Cooldown-Phase: Die Zeitspanne (in Sekunden) zwischen dem Ende einer Scale-In- bzw. einer Scale-Out-Aktivität und dem Beginn einer neuen Scale-Out-Aktivität.
+ Eine dienstverknüpfte Rolle — Eine AWS Identity and Access Management (IAM) -Rolle, die mit einem bestimmten AWS Dienst verknüpft ist. Eine dienstbezogene Rolle umfasst alle Berechtigungen, die der Dienst benötigt, um andere AWS Dienste in Ihrem Namen aufzurufen. ElastiCache Auto Scaling generiert diese Rolle automatisch für Sie. `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG`
+ Scale-In-Aktivitäten aktivieren oder deaktivieren: Die Möglichkeit, Scale-In-Aktivitäten für eine Richtlinie zu aktivieren oder zu deaktivieren.
**Topics**
+ [Zielmetrik für Auto Scaling](#AutoScaling-TargetMetric)
+ [Minimale und maximale Kapazität](#AutoScaling-MinMax)
+ [Abkühlungszeit](#AutoScaling-Cooldown)
+ [Aktivieren oder Deaktivieren von Scale-In-Aktivitäten](#AutoScaling-enable-disable-scale-in)
## Zielmetrik für Auto Scaling
Bei diesem Richtlinientyp werden eine vordefinierte oder benutzerdefinierte Metrik und ein Zielwert für die Metrik in einer Skalierungsrichtlinienkonfiguration zur Zielverfolgung angegeben. ElastiCache für Valkey und Redis OSS Auto Scaling erstellt und verwaltet CloudWatch Alarme, die die Skalierungsrichtlinie auslösen, und berechnet die Skalierungsanpassung auf der Grundlage der Metrik und des Zielwerts. Die Skalierungsrichtlinie fügt nach shards/replicas Bedarf hinzu oder entfernt sie, um die Metrik auf oder nahe dem angegebenen Zielwert zu halten. Abgesehen davon, dass eine Skalierungsrichtlinie für die Ziel-Nachverfolgung die Metrik nahe an dem Zielwert hält, passt sie sich auch an die Schwankungen in der Metrik aufgrund eines sich ändernden Workloads an. Eine solche Richtlinie minimiert auch schnelle Schwankungen bei der Anzahl der shards/replicas für Ihren Cluster verfügbaren Geräte.
Nehmen wir zum Beispiel eine Skalierungsrichtlinie, die die vordefinierte durchschnittliche `ElastiCachePrimaryEngineCPUUtilization`-Metrik verwendet. Eine solche Richtlinie kann die CPU-Auslastung bei einem bestimmten Prozentsatz der Auslastung halten, z. B. bei 70 Prozent.
**Anmerkung**
Für jeden DB-Cluster können Sie nur eine Auto-Scaling-Richtlinie für jede Zielmetrik erstellen.
## Minimale und maximale Kapazität
**Shards**
Sie können die maximale Anzahl von Shards angeben, auf die skaliert werden kann, indem Sie Valkey und Redis ElastiCache OSS Auto Scaling verwenden. Dieser Wert muss kleiner oder gleich 250 sein und mindestens 1 sein. Sie können auch die Mindestanzahl von Shards angeben, die mit Auto Scaling verwaltet werden sollen. Dieser Wert muss mindestens 1 betragen und gleich oder kleiner sein als der Wert, der für die maximale Anzahl von Scherben 250 angegeben ist.
**Replikas**
Sie können die maximale Anzahl von Replikaten angeben, mit denen Valkey und Redis OSS Auto ElastiCache Scaling verwaltet werden sollen. Dieser Wert muss gleich oder kleiner 5 sein. Sie können auch die Mindestanzahl von Replikaten angeben, die mit Auto Scaling verwaltet werden sollen. Dieser Wert muss mindestens 1 betragen und gleich oder kleiner als der für die maximale Anzahl von Replikaten angegebene Wert 5 sein.
Um die minimale und maximale Anzahl davon zu ermitteln shards/replicas , die Sie für den typischen Datenverkehr benötigen, testen Sie Ihre Auto Scaling Scaling-Konfiguration mit der erwarteten Datenverkehrsrate zu Ihrem Modell.
**Anmerkung**
ElastiCache Auto Scaling-Richtlinien erhöhen die Clusterkapazität, bis sie Ihre definierte Maximalgröße erreicht hat oder bis Servicebeschränkungen gelten. Um eine Erhöhung des Limits zu beantragen, [AWS siehe Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) und wählen Sie den Limittyp **Nodes per cluster per instance type**.
**Wichtig**
Scaling-in findet statt, wenn es keinen Verkehr gibt. Wenn der Traffic einer Variante Null wird, wird ElastiCache automatisch auf die angegebene Mindestanzahl von Instanzen skaliert.
## Abkühlungszeit
Sie können die Reaktionsfähigkeit einer Skalierungsrichtlinie für die Zielverfolgung anpassen, indem Sie Ruhephasen hinzufügen, nachdem eine Skalierung Ihres DB-Clusters erfolgt ist. Eine Ruhephase blockiert nachfolgende Scale-in- oder Scale-out-Anforderungen bis zum Ablauf der Frist. Dies verlangsamt das Löschen von shards/replicas in Ihrem ElastiCache for Valkey- und Redis OSS-Cluster für Scale-In-Anfragen und das Erstellen von für Scale-Out-Anfragen. shards/replicas Sie können die folgenden Ruhephasen angeben:
+ Eine Scale-In-Aktivität reduziert die Anzahl der in Ihrem Cluster. shards/replicas Eine Ruhephase zum Abskalieren gibt die Zeitspanne in Sekunden an, nach der eine Abskalierung abgeschlossen sein muss, bevor eine weitere Abskalierung gestartet werden kann.
+ Eine Scale-Out-Aktivität erhöht die Anzahl der shards/replicas in Ihrem Cluster. Eine Ruhephase zum Aufskalieren gibt die Zeitspanne in Sekunden an, nach der eine Aufskalierung abgeschlossen sein muss, bevor eine weitere Aufskalierung gestartet werden kann.
Wenn keine Ruhephase für das Abskalieren oder Aufskalieren angegeben ist, beträgt der Standardwert für die Aufskalierung 600 Sekunden und für das Abskalieren 900 Sekunden.
## Aktivieren oder Deaktivieren von Scale-In-Aktivitäten
Sie können die Scale-In-Aktivitäten für eine Richtlinie aktivieren oder deaktivieren. Durch die Aktivierung von Scale-In-Aktivitäten kann die Skalierungsrichtlinie gelöscht werden. shards/replicas. When scale-in activities are enabled, the scale-in cooldown period in the scaling policy applies to scale-in activities. Disabling scale-in activities prevents the scaling policy from deleting shards/replicas
**Anmerkung**
Scale-Out-Aktivitäten sind immer aktiviert, sodass die Skalierungsrichtlinie nach Bedarf ElastiCache Shards oder Replikate erstellen kann.
## Für Auto Scaling sind IAM-Berechtigungen erforderlich
ElastiCache für Valkey und Redis OSS wird Auto Scaling durch eine Kombination aus ElastiCache CloudWatch, und Application Auto Scaling ermöglicht. APIs Cluster werden mit Application Auto Scaling erstellt und aktualisiert ElastiCache CloudWatch, Alarme werden mit erstellt und Skalierungsrichtlinien werden erstellt. Zusätzlich zu den Standard-IAM-Berechtigungen für das Erstellen und Aktualisieren von Clustern muss der IAM-Benutzer, der auf die ElastiCache Auto Scaling Scaling-Einstellungen zugreift, über die entsprechenden Berechtigungen für die Dienste verfügen, die dynamische Skalierung unterstützen. In dieser neuesten Richtlinie haben wir mit der Aktion Unterstützung für die vertikale Skalierung von Memcached hinzugefügt. `elasticache:ModifyCacheCluster` IAM-Benutzer müssen die Berechtigung haben, die Aktionen in der folgenden Beispielrichtlinie zu verwenden:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"application-autoscaling:*",
"elasticache:DescribeReplicationGroups",
"elasticache:ModifyReplicationGroupShardConfiguration",
"elasticache:IncreaseReplicaCount",
"elasticache:DecreaseReplicaCount",
"elasticache:DescribeCacheClusters",
"elasticache:DescribeCacheParameters",
"cloudwatch:DeleteAlarms",
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmsForMetric",
"cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics",
"cloudwatch:PutMetricAlarm",
"cloudwatch:DisableAlarmActions",
"cloudwatch:EnableAlarmActions",
"iam:CreateServiceLinkedRole",
"sns:CreateTopic",
"sns:Subscribe",
"sns:Get*",
"sns:List*"
],
"Resource": "arn:aws:iam::123456789012:role/autoscaling-roles-for-cluster"
}
]
}
```
------
## Servicegebundene Rolle
Der auto Skalierungsdienst ElastiCache für Valkey und Redis OSS benötigt außerdem die Erlaubnis, Ihre Cluster und CloudWatch Alarme zu beschreiben, sowie Berechtigungen, Ihre ElastiCache Zielkapazität in Ihrem Namen zu ändern. Wenn Sie Auto Scaling für Ihren Cluster aktivieren, wird eine dienstverknüpfte Rolle mit dem Namen `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG` erstellt. Diese dienstbezogene Rolle gewährt ElastiCache Auto Scaling-Berechtigungen, um die Alarme für Ihre Richtlinien zu beschreiben, die aktuelle Kapazität der Flotte zu überwachen und die Kapazität der Flotte zu ändern. Die serviceverknüpfte Rolle ist die Standardrolle für ElastiCache Auto Scaling. Weitere Informationen finden Sie unter [Serviceverknüpfte Rollen ElastiCache für Redis OSS Auto Scaling im Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) Scaling-Benutzerhandbuch.
## Bewährte Methoden für die Auto Scaling
Wir empfehlen vor der Registrierung für Auto Scaling Folgendes:
1. **Verwenden Sie nur eine Tracking-Metrik** – Ermitteln Sie, ob Ihr Cluster über CPU- oder datenintensive Workloads verfügt, und verwenden Sie eine entsprechende vordefinierte Metrik, um die Skalierungsrichtlinie zu definieren.
+ Engine-CPU: `ElastiCachePrimaryEngineCPUUtilization` (Shard-Dimension) oder `ElastiCacheReplicaEngineCPUUtilization` (Replikatdimension)
+ Datenbanknutzung: `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` Diese Skalierungsrichtlinie funktioniert am besten, wenn „maxmemory-policy“ im Cluster auf „noeviction“ festgelegt ist.
Wir empfehlen Ihnen, mehrere Richtlinien pro Dimension auf dem Cluster zu vermeiden. ElastiCache Für Valkey und Redis OSS skaliert Auto Scaling das skalierbare Ziel, wenn irgendwelche Richtlinien zur Zielverfolgung bereit für die horizontale Skalierung sind. Die Skalierung erfolgt jedoch nur, wenn alle Zielverfolgungsrichtlinien (mit aktiviertem Scale-In-Teil) skalierbar sind. Wenn mehrere Richtlinien das skalierbare Ziel anweisen, gleichzeitig zu herauf oder herunter zu skalieren, skaliert auf Grundlage der Richtlinie, die die größte Kapazität für das Herauf- und Herunterskalieren bietet.
1. **Benutzerdefinierte Metriken für die Zielverfolgung** – Seien Sie vorsichtig, wenn Sie benutzerdefinierte Metriken für die Zielverfolgung verwenden, da die automatische Skalierung am besten geeignet ist, um proportional zu Änderungen der für die Richtlinie ausgewählten Metriken auf-/abzuskalieren. Wenn solche Metriken, die sich nicht proportional zu den Skalierungsaktionen ändern, zur Richtlinienerstellung verwendet werden, kann dies zu kontinuierlichen Auf- oder Abskalierungsaktionen führen, was sich auf Verfügbarkeit oder Kosten auswirken kann.
Vermeiden Sie bei Daten-Tiering-Clustern (Instance-Familie r6gd) die Verwendung speicherbasierter Metriken für die Skalierung.
1. **Geplante Skalierung** — Wenn Sie feststellen, dass Ihre Arbeitslast deterministisch ist (sie erreicht high/low zu einem bestimmten Zeitpunkt), empfehlen wir die Verwendung von Scheduled Scaling und die Konfiguration Ihrer Zielkapazität entsprechend den Anforderungen. Target Tracking eignet sich am besten für nicht-deterministische Workloads und für einen Cluster für den Betrieb mit der erforderlichen Zielmetrik, indem er aufskaliert, wenn Sie mehr Ressourcen benötigen, und abskaliert, wenn Sie weniger benötigen.
1. **Scale-In deaktivieren** — Die automatische Skalierung bei Target Tracking eignet sich am besten für Cluster mit schrittweisen Workloads, da In-Metriken increase/decrease aufeinanderfolgende spikes/dip Scale-Out-/In-Oszillationen auslösen können. Um solche Schwankungen zu vermeiden, können Sie mit deaktivierter Abskalierung beginnen. Später können Sie jederzeit manuell nach Ihren Bedürfnissen abskalieren.
1. **Testen Sie Ihre Anwendung** — Wir empfehlen Ihnen, Ihre Anwendung mit Ihren geschätzten Min/Max Workloads zu testen, um die für den Cluster shards/replicas erforderlichen Mindest-/Höchstwerte zu ermitteln und gleichzeitig Skalierungsrichtlinien zu erstellen, um Verfügbarkeitsprobleme zu vermeiden. Die automatische Skalierung kann bis zum Maximal- und Minimalwert auf- bzw. abskalieren, der für das Ziel konfiguriert wurde.
1. **Definition des Zielwerts** — Sie können die entsprechenden CloudWatch Metriken für die Clusterauslastung über einen Zeitraum von vier Wochen analysieren, um den Schwellenwert für den Zielwert zu ermitteln. Wenn Sie sich immer noch nicht sicher sind, welchen Wert Sie wählen möchten, empfehlen wir, mit dem minimal unterstützten vordefinierten Metrikwert zu beginnen.
1. AutoScaling On Target Tracking eignet sich am besten für Cluster mit einheitlicher Verteilung der Workloads über alle shards/replicas Dimensionen. Eine ungleichmäßige Verteilung kann zu folgenden Faktoren führen:
+ Skalierung, wenn sie aufgrund der Arbeitslast spike/dip bei einigen Hot-Shards/Replicas nicht erforderlich ist.
+ Keine Skalierung, wenn erforderlich, da insgesamt durchschnittlich nahe am Ziel liegt, obwohl Hot-Shards/Replikate vorhanden sind.
**Anmerkung**
Bei der Skalierung Ihres Clusters ElastiCache werden die Funktionen, die in einem der vorhandenen Knoten geladen wurden (zufällig ausgewählt), automatisch auf die neuen Knoten repliziert. Wenn Ihr Cluster über Valkey oder Redis OSS 7.0 oder höher verfügt und Ihre Anwendung [Functions](https://valkey.io/topics/functions-intro/) verwendet, empfehlen wir, alle Ihre Funktionen vor dem Skalieren auf alle Shards zu laden, damit Ihr Cluster nicht mit unterschiedlichen Funktionen auf verschiedenen Shards endet.
Beachten Sie nach der Registrierung Folgendes AutoScaling:
+ Es gibt Einschränkungen bei den unterstützten Konfigurationen für die automatische Skalierung, daher empfehlen wir, die Konfiguration einer Replikationsgruppe, die für die automatische Skalierung registriert ist, nicht zu ändern. Im Folgenden sind einige Beispiele aufgeführt:
+ Manuelles Ändern des Instance-Typs in nicht unterstützte Typen.
+ Zuordnen der Replikationsgruppe zu einem globalen Datenspeicher.
+ Ändern`ReservedMemoryPercent`-Parameter.
+ Manuell konfigurierte increasing/decreasing shards/replicas beyond the Min/Max Kapazität bei der Richtlinienerstellung.
# Verwenden von Auto Scaling mit Shards
Damit ElastiCache können AutoScaling Sie Tracking- und geplante Richtlinien mit Ihrer Valkey- oder Redis OSS-Engine verwenden.
Im Folgenden finden Sie Einzelheiten zur Zielverfolgung und zu geplanten Richtlinien sowie dazu, wie Sie diese mithilfe von und anwenden können. AWS-Managementkonsole AWS CLI APIs
**Topics**
+ [Skalierungsrichtlinien für die Ziel-Nachverfolgung](AutoScaling-Scaling-Policies-Target.md)
+ [Hinzufügen einer Skalierungsrichtlinie](AutoScaling-Scaling-Adding-Policy-Shards.md)
+ [Registrieren eines skalierbaren Ziels](AutoScaling-Scaling-Registering-Policy-CLI.md)
+ [Definieren einer Skalierungsrichtlinie](AutoScaling-Scaling-Defining-Policy-API.md)
+ [Deaktivieren der Scale-In-Aktivität](AutoScaling-Scaling-Disabling-Scale-in.md)
+ [Anwenden einer Skalierungsrichtlinie](AutoScaling-Scaling-Applying-a-Scaling-Policy.md)
+ [Bearbeiten einer Skalierungsrichtlinie](AutoScaling-Scaling-Editing-a-Scaling-Policy.md)
+ [Löschen einer Skalierungsrichtlinie](AutoScaling-Scaling-Deleting-a-Scaling-Policy.md)
+ [CloudFormation Für Auto Scaling Scaling-Richtlinien verwenden](AutoScaling-with-Cloudformation-Shards.md)
+ [Geplante Skalierung](AutoScaling-with-Scheduled-Scaling-Shards.md)
# Skalierungsrichtlinien für die Ziel-Nachverfolgung
Bei Skalierungsrichtlinien für die Zielverfolgung wählen Sie eine Metrik aus und legen einen Zielwert fest. ElastiCache für Valkey und Redis erstellt und verwaltet OSS Auto Scaling die CloudWatch Alarme, die die Skalierungsrichtlinie auslösen, und berechnet die Skalierungsanpassung auf der Grundlage der Metrik und des Zielwerts. Durch die Skalierungsrichtlinie wird so viel Kapazität wie erforderlich hinzugefügt oder entfernt, damit die Metrik auf oder nahe an dem Zielwert gehalten wird. Abgesehen davon, dass eine Skalierungsrichtlinie für die Ziel-Nachverfolgung die Metrik nahe an dem Zielwert hält, passt sie sich auch an die Schwankungen in der Metrik aufgrund eines schwankenden Lastmusters an und verringert schnelle Schwankungen der Kapazität der Flotte.
Nehmen wir zum Beispiel eine Skalierungsrichtlinie, die die vordefinierte `ElastiCachePrimaryEngineCPUUtilization`-Durchschnittsmetrik mit konfiguriertem Zielwert verwendet. Eine solche Richtlinie kann die CPU-Nutzung auf oder nahe an dem Zielwert halten.
## Vordefinierte Metriken
Eine vordefinierte Metrik ist eine Struktur, die sich auf einen bestimmten Namen, eine Dimension und eine Statistik (`average`) einer bestimmten Metrik bezieht. CloudWatch Ihre Auto-Scaling-Richtlinie definiert eine der folgenden vordefinierten Metriken für Ihren Cluster:
****
| Vordefinierter Metrikname | CloudWatch Metrikname | CloudWatch Metrische Dimension | Nicht geeignete Instance-Typen |
| --- | --- | --- | --- |
| ElastiCachePrimaryEngineCPUUtilization | `EngineCPUUtilization` | ReplicationGroupId, Rolle = Primär | Keine |
| ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage | `DatabaseCapacityUsageCountedForEvictPercentage` | Metriken für Valkey- oder Redis OSS-Replikationsgruppen | Keine |
| ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage | `DatabaseMemoryUsageCountedForEvictPercentage` | Metriken für die OSS-Replikationsgruppe von Valkey oder Redis | R6gd |
Instance-Typen mit Daten-Tiering können `ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage` nicht verwenden, da diese Instance-Typen Daten sowohl im Arbeitsspeicher als auch im SSD-Speicher ablegen. Der erwartete Anwendungsfall für Instances mit Daten-Tiering ist eine 100-prozentige Speichernutzung und das Auffüllen des SSD-Speichers nach Bedarf.
## Kriterien für die Auto Scaling für Shards
Wenn der Service feststellt, dass Ihre vordefinierte Metrik gleich oder größer als die Zieleinstellung ist, erhöht er die Kapazität Ihrer Shards automatisch. ElastiCache für Valkey und Redis OSS skaliert OSS Ihre Cluster-Shards um eine Anzahl, die der größeren von zwei Zahlen entspricht: prozentuale Abweichung von Target und 20 Prozent der aktuellen Shards. Bei Scale-In erfolgt ElastiCache keine auto Skalierung, es sei denn, der Gesamtmetrikwert liegt unter 75 Prozent Ihres definierten Ziels.
Wenn Sie für ein Scal-Out-Beispiel 50 Shards und
+ Wenn Ihr Target die Sicherheitslücken um 30 Prozent überschreitet, wird eine ElastiCache Skalierung um 30 Prozent vorgenommen, was zu 65 Shards pro Cluster führt.
+ Wenn Ihr Target die Sicherheitslücken um 10 Prozent überschreitet, wird standardmäßig ein Minimum von 20 Prozent ElastiCache skaliert, was zu 60 Shards pro Cluster führt.
Wenn Sie beispielsweise einen Zielwert von 60 Prozent ausgewählt haben, erfolgt die auto Skalierung ElastiCache erst, wenn die Metrik 45 Prozent oder weniger beträgt (25 Prozent unter dem Ziel von 60 Prozent).
## Überlegungen zum Auto Scaling
Beachten Sie folgende Überlegungen:
+ Eine Skalierungsrichtlinie für die Ziel-Nachverfolgung geht davon aus, dass sie eine horizontale Skalierung nach oben vornehmen soll, wenn die angegebene Metrik über dem Zielwert liegt. Sie können keine Skalierungsrichtlinie für die Zielverfolgung verwenden, um eine Skalierung vorzunehmen, wenn die angegebene Metrik unter dem Zielwert liegt. ElastiCache für Valkey und Redis skaliert OSS die Shards um eine Abweichung von mindestens 20 Prozent vom Ziel vorhandener Shards im Cluster.
+ Eine Skalierungsrichtlinie für die Ziel-Nachverfolgung nimmt keine Skalierung vor, wenn die angegebene Metrik unzureichende Daten aufweist. Es wird keine Abskalierung vorgenommen, da unzureichende Daten nicht als geringe Auslastung interpretiert werden.
+ Möglicherweise werden Lücken zwischen den Datenpunkten für den Zielwert und die aktuelle Metrik angezeigt. Das liegt daran, dass ElastiCache Auto Scaling immer konservativ agiert, indem es auf- oder abrundet, wenn es bestimmt, wie viel Kapazität hinzugefügt oder entfernt werden soll. Dadurch wird verhindert, dass zu wenig Kapazität hinzufügt oder zu viel Kapazität entfernt wird.
+ Um die Verfügbarkeit der Anwendung sicherzustellen, wird der Service schnellstmöglich proportional zur Metrik hochskaliert, jedoch etwas langsamer herunterskaliert.
+ Sie können mehrere Skalierungsrichtlinien zur Zielverfolgung für einen OSS-Cluster ElastiCache für Valkey und Redis verwenden, vorausgesetzt, dass jeder von ihnen eine andere Metrik verwendet. Die Absicht von ElastiCache Auto Scaling besteht darin, der Verfügbarkeit immer Priorität einzuräumen. Daher unterscheidet sich das Verhalten je nachdem, ob die Zielverfolgungsrichtlinien für die horizontale Skalierung oder für die Skalierung bereit sind. Sofern Richtlinien für die Ziel-Nachverfolgung für die Skalierung nach oben bereit sind, findet eine Skalierung des Service nach oben statt. Eine Skalierung nach unten wird jedoch nur vorgenommen, wenn alle Richtlinien für die Ziel-Nachverfolgung (mit aktivierter Skalierung nach unten) zur Skalierung nach unten bereit sind.
+ Bearbeiten oder löschen Sie nicht die CloudWatch Alarme, die ElastiCache Auto Scaling für eine Skalierungsrichtlinie zur Zielverfolgung verwaltet. ElastiCache Auto Scaling löscht die Alarme automatisch, wenn Sie die Skalierungsrichtlinie löschen.
+ ElastiCache Auto Scaling verhindert nicht, dass Sie Cluster-Shards manuell ändern. Diese manuellen Anpassungen wirken sich nicht auf bestehende CloudWatch Alarme aus, die mit der Skalierungsrichtlinie verknüpft sind, können sich jedoch auf Metriken auswirken, die diese CloudWatch Alarme auslösen können.
+ Diese von Auto Scaling verwalteten CloudWatch Alarme werden anhand der AVG-Metrik für alle Shards im Cluster definiert. So kann Hot-Shards zu einem beliebigen Szenario führen:
+ Skalierung, wenn sie nicht erforderlich ist, weil die Belastung einiger Hot-Shards einen Alarm auslöst CloudWatch
+ nicht skalieren, wenn dies erforderlich ist, aufgrund aggregierter AVG über alle Shards, die den Alarm nicht verletzen.
+ ElastiCache Die Standardgrenzwerte für Knoten pro Cluster gelten weiterhin. Wenn Sie sich also für Auto Scaling entscheiden und erwarten, dass maximale Knoten mehr als die Standardgrenze sind, fordern Sie eine Limiterhöhung bei [AWS -Service-Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) an und wählen Sie den Limit-Typ **Knoten pro Cluster pro Instance-Typ**.
+ Stellen Sie sicher, dass in Ihrer VPC genügend ENIs (Elastic Network Interfaces) verfügbar sind, die beim Scale-Out benötigt werden. Weitere Informationen finden Sie unter [Elastic-Network-Schnittstellen](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html).
+ Wenn nicht genügend Kapazität verfügbar ist EC2, wird ElastiCache Auto Scaling nicht skaliert und verzögert, bis die Kapazität verfügbar ist.
+ ElastiCache für Redis OSS Auto Scaling entfernt beim Scale-In keine Shards mit Steckplätzen, die nach der Serialisierung eine Objektgröße von mehr als 256 MB haben.
+ Während des Scale-Ins werden Shards nicht entfernt, wenn nicht genügend Speicher für die resultierende Shard-Konfiguration verfügbar ist.
# Hinzufügen einer Skalierungsrichtlinie
Sie können eine Skalierungsrichtlinie hinzufügen, indem Sie die verwenden AWS-Managementkonsole.
**So fügen Sie einem OSS-Cluster ElastiCache für Valkey und Redis eine Auto Scaling Scaling-Richtlinie hinzu**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Amazon-Konsole unter [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis** OSS aus.
1. Wählen Sie den Cluster aus, dem Sie eine Richtlinie hinzufügen möchten (wählen Sie den Cluster-Namen und nicht die Schaltfläche links davon aus).
1. Wählen Sie die Registerkarte **Auto-Scaling-Richtlinien** aus.
1. Wählen Sie **Add dynamic scaling** (Dynamische Skalierung hinzufügen) aus.
1. Geben Sie unter **Policy Name (Richtlinienname)** einen Namen für diese Richtlinie ein.
1. Für **Skalierbare Dimension** wählen Sie **Shards** aus.
1. Wählen Sie für die Zielmetrik eine der nachstehenden Optionen aus:
+ **Primäre CPU-Auslastung**, um eine Richtlinie auf der Grundlage der durchschnittlichen CPU-Auslastung zu erstellen.
+ **Memory (Arbeitsspeicher)**Um eine Richtlinie zu erstellen, die auf dem durchschnittlichen Datenbankspeicher basiert.
+ **Kapazität** zum Erstellen einer Richtlinie auf der Grundlage der durchschnittlichen Datenbankkapazitätsauslastung. Die Kapazitätsmetrik umfasst die Speicher- und SSD-Auslastung für Daten-Tiering-Instances und die Speichernutzung für alle anderen Instance-Typen.
1. Wählen Sie für den Zielwert einen Wert größer oder gleich 35 und kleiner oder gleich 70 aus. Bei der automatischen Skalierung wird dieser Wert für die ausgewählte Zielmetrik auf allen Ihren ElastiCache Shards beibehalten:
+ **Primäre CPU-Auslastung**: behält den Zielwert für die `EngineCPUUtilization`-Metrik auf den Primärknoten bei.
+ **Speicher**: behält den Zielwert für die `DatabaseMemoryUsageCountedForEvictPercentage`-Metrik bei
+ **Kapazität** behält den Zielwert für die `DatabaseCapacityUsageCountedForEvictPercentage`-Metrik bei
Cluster-Shards werden hinzugefügt oder entfernt, um die Metrik in der Nähe des angegebenen Wertes zu halten.
1. (Optional) Die Ruhephase für Scale-In- oder Scale-Out-Ruhephase werden von der Konsole nicht unterstützt. Verwenden Sie die AWS CLI , um die Abklingzeitwerte zu ändern.
1. Geben Sie für **Mindestkapazität** die Mindestanzahl von Shards ein, für deren Verwaltung die ElastiCache Auto Scaling Scaling-Richtlinie erforderlich ist.
1. Geben Sie für **Maximale Kapazität** die maximale Anzahl von Shards ein, für deren Verwaltung die ElastiCache Auto Scaling Scaling-Richtlinie erforderlich ist. Dieser Wert muss gleich oder kleiner 250 sein.
1. Wählen Sie **Erstellen** aus.
# Registrieren eines skalierbaren Ziels
Bevor Sie Auto Scaling mit einem OSS-Cluster ElastiCache für Valkey und Redis verwenden können, registrieren Sie Ihren Cluster bei ElastiCache Auto Scaling. Sie tun dies, um die Skalierungsdimension und die Grenzwerte zu definieren, die auf diesen Cluster angewendet werden sollen. ElastiCache Auto Scaling skaliert den Cluster dynamisch entlang der `elasticache:replication-group:NodeGroups` skalierbaren Dimension, die die Anzahl der Cluster-Shards darstellt.
**Unter Verwendung der AWS CLI**
Verwenden Sie den [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)Befehl mit den folgenden Parametern, um Ihren OSS-Cluster ElastiCache für Valkey und Redis zu registrieren:
+ `--service-namespace` – Legen Sie diesen Wert auf `elasticache` fest
+ `--resource-id`— Die Ressourcen-ID für den Cluster. Für diesen Parameter ist der Ressourcentyp `ReplicationGroup` und die eindeutige Kennung beispielsweise der Name des Clusters`replication-group/myscalablecluster`.
+ `--scalable-dimension` – Legen Sie diesen Wert auf `elasticache:replication-group:NodeGroups` fest.
+ `--max-capacity `— Die maximale Anzahl von Shards, die durch ElastiCache Auto Scaling verwaltet werden können. Informationen zur Beziehung zwischen `--min-capacity`, `--max-capacity` und der Anzahl der DB-Instances in Ihrem Cluster finden Sie unter [Minimale und maximale Kapazität](AutoScaling-Policies.md#AutoScaling-MinMax).
+ `--min-capacity `— Die Mindestanzahl von Shards, die durch ElastiCache Auto Scaling verwaltet werden müssen. Informationen zur Beziehung zwischen `--min-capacity`, `--max-capacity` und der Anzahl der DB-Instances in Ihrem Cluster finden Sie unter [Minimale und maximale Kapazität](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Im folgenden Beispiel registrieren Sie einen ElastiCache Cluster mit dem Namen`myscalablecluster`. Die Registrierung zeigt an, dass der DB-Cluster dynamisch skaliert werden soll, um zwischen einer und acht -Replicas zu haben.
Für Linux, macOS oder Unix:
```
aws application-autoscaling register-scalable-target \
--service-namespace elasticache \
--resource-id replication-group/myscalablecluster \
--scalable-dimension elasticache:replication-group:NodeGroups \
--min-capacity 1 \
--max-capacity 10 \
```
Für Windows:
```
aws application-autoscaling register-scalable-target ^
--service-namespace elasticache ^
--resource-id replication-group/myscalablecluster ^
--scalable-dimension elasticache:replication-group:NodeGroups ^
--min-capacity 1 ^
--max-capacity 10 ^
```
**Verwenden der API**
Verwenden Sie den [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)Befehl mit den folgenden Parametern, um Ihren ElastiCache Cluster zu registrieren:
+ ServiceNamespace — Setzen Sie diesen Wert auf elasticache.
+ ResourceID — Die Ressourcen-ID für den ElastiCache Cluster. Für diesen Parameter ist der Ressourcentyp ReplicationGroup und die eindeutige Kennung beispielsweise `replication-group/myscalablecluster` der Name des Clusters.
+ ScalableDimension — Setzen Sie diesen Wert auf`elasticache:replication-group:NodeGroups`.
+ MinCapacity — Die Mindestanzahl von Shards, die durch ElastiCache Auto Scaling verwaltet werden müssen. Informationen zur Beziehung zwischen --min-capacity, --max-capacity und der Anzahl der Replikate in Ihrem Cluster finden Sie unter [Minimale und maximale Kapazität](AutoScaling-Policies.md#AutoScaling-MinMax).
+ MaxCapacity — Die maximale Anzahl von Shards, die durch ElastiCache Auto Scaling verwaltet werden können. Informationen zur Beziehung zwischen --min-capacity, --max-capacity und der Anzahl der Replikate in Ihrem Cluster finden Sie unter [Minimale und maximale Kapazität](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Im folgenden Beispiel registrieren Sie einen ElastiCache Cluster, der `myscalablecluster` mit der Application Auto Scaling API benannt ist. Diese Registrierung zeigt an, dass der Cluster dynamisch skaliert werden soll, um zwischen 1 und 5 Replikate zu haben.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups",
"MinCapacity": 1,
"MaxCapacity": 5
}
```
# Definieren einer Skalierungsrichtlinie
Eine Konfiguration der Skalierungsrichtlinie für die Zielverfolgung wird durch einen JSON-Block repräsentiert, in dem die Metriken und Zielwerte definiert sind. Sie können die Konfiguration einer Skalierungsrichtlinie als JSON-Block in einer Textdatei speichern. Sie verwenden diese Textdatei, wenn Sie die AWS CLI oder die Application Auto Scaling Scaling-API aufrufen. Weitere Informationen zur Syntax der Richtlinienkonfiguration finden Sie unter [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in der Application Auto Scaling API Reference.
Die folgenden Optionen stehen zur Verfügung, um eine Konfiguration der Skalierungsrichtlinien für die Zielverfolgung zu definieren:
**Topics**
+ [Verwenden einer vordefinierten Metrik](#AutoScaling-Scaling-Predefined-Metric)
+ [Verwenden einer benutzerdefinierten Metrik](#AutoScaling-Scaling-Custom-Metric)
+ [Verwenden von Ruhephasen](#AutoScaling-Scaling-Cooldown-periods)
## Verwenden einer vordefinierten Metrik
Mithilfe vordefinierter Metriken können Sie schnell eine Skalierungsrichtlinie für die Zielverfolgung für einen OSS-Cluster ElastiCache für Valkey und Redis definieren, der mit der Zielverfolgung in Auto Scaling funktioniert. ElastiCache
ElastiCache Unterstützt derzeit die folgenden vordefinierten Metriken in NodeGroup Auto Scaling:
+ **ElastiCachePrimaryEngineCPUUtilization**— Der Durchschnittswert der `EngineCPUUtilization` Metrik CloudWatch auf allen Primärknoten im Cluster.
+ **ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage**— Der Durchschnittswert der `DatabaseMemoryUsageCountedForEvictPercentage` Metrik CloudWatch für alle Primärknoten im Cluster.
+ **ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage**— Der Durchschnittswert der `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` Metrik CloudWatch für alle Primärknoten im Cluster.
Weitere Informationen über die Metriken `EngineCPUUtilization`, `DatabaseMemoryUsageCountedForEvictPercentage` und `DatabaseCapacityUsageCountedForEvictPercentage` finden Sie unter [Überwachung der Nutzung mit CloudWatch Metrics](CacheMetrics.md). Um eine vordefinierte Metrik in Ihrer Skalierungsrichtlinie zu verwenden, erstellen Sie eine Zielverfolgungskonfiguration für Ihre Skalierungsrichtlinie. Diese Konfiguration muss eine `PredefinedMetricSpecification` für die vordefinierte Metrik und einen TargetValue für den Zielwert dieser Metrik enthalten.
**Example**
Das folgende Beispiel beschreibt eine typische Richtlinienkonfiguration für die Skalierung nach Zielverfolgung für einen OSS-Cluster ElastiCache für Valkey und Redis. In dieser Konfiguration wird die `ElastiCachePrimaryEngineCPUUtilization` vordefinierte Metrik verwendet, um den Cluster auf der Grundlage einer durchschnittlichen CPU-Auslastung von 40 Prozent auf allen Primärknoten im Cluster anzupassen.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
```
## Verwenden einer benutzerdefinierten Metrik
Durch die Verwendung von benutzerdefinierten Metriken können Sie eine Skalierungsrichtlinie für die Zielverfolgung definieren, die Ihren individuellen Anforderungen entspricht. Sie können eine benutzerdefinierte Metrik basierend auf einer beliebigen ElastiCache -Metrik definieren, die sich proportional zur Skalierung ändert. Nicht alle ElastiCache Metriken eignen sich für die Zielverfolgung. Die Metrik muss eine gültige Auslastungsmetrik sein und beschreiben, wie ausgelastet eine Instance ist. Der Wert der Metrik muss sich proportional zur Anzahl der -Replicas im -DB-Cluster erhöhen oder verringern. Diese proportionale Erhöhung oder Verminderung ist notwendig, um die metrischen Daten zur proportionalen Skalierung oder in der Anzahl der -Repliken zu verwenden.
**Example**
Das folgende Beispiel beschreibt die Konfiguration einer Zielverfolgung für eine Skalierungsrichtlinie. In dieser Konfiguration passt eine benutzerdefinierte Metrik einen ElastiCache für Redis OSS-Cluster auf der Grundlage einer durchschnittlichen CPU-Auslastung von 50 Prozent für alle Shards in einem genannten Cluster an. `my-db-cluster`
```
{
"TargetValue": 50,
"CustomizedMetricSpecification":
{
"MetricName": "EngineCPUUtilization",
"Namespace": "AWS/ElastiCache",
"Dimensions": [
{
"Name": "ReplicationGroup","Value": "my-db-cluster"
},
{
"Name": "Role","Value": "PRIMARY"
}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
```
## Verwenden von Ruhephasen
Sie können einen Wert in Sekunden für `ScaleOutCooldown` angeben, um eine Ruhephase für die Aufskalierung Ihres Clusters hinzuzufügen. Ähnlich können Sie einen Wert in Sekunden für `ScaleInCooldown` angeben, um eine Ruhephase für die Abskalierung Ihres Clusters hinzuzufügen. Weitere Informationen finden Sie [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)in der API-Referenz für Application Auto Scaling.
Das folgende Beispiel beschreibt die Konfiguration einer Zielverfolgung für eine Skalierungsrichtlinie. In dieser Konfiguration wird die `ElastiCachePrimaryEngineCPUUtilization` vordefinierte Metrik verwendet, um einen ElastiCache für Redis OSS-Cluster auf der Grundlage einer durchschnittlichen CPU-Auslastung von 40 Prozent auf allen primären Knoten in diesem Cluster anzupassen. Die Konfiguration sieht eine Ruhephase von 10 Minuten zum Abskalieren und eine Ruhephase von 5 Minuten zum Aufskalieren vor.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
# Deaktivieren der Scale-In-Aktivität
Sie können verhindern, dass die Konfiguration der Skalierungsrichtlinie für die Zielverfolgung in Ihrem Cluster skaliert, indem Sie die Scale-In-Aktivität deaktivieren. Das Deaktivieren der Scale-In-Aktivität verhindert das Löschen von -Repliken durch die Skalierungsrichtlinie, und erlaubt der Skalierungsrichtlinie dennoch, Repliken nach Bedarf zu erstellen.
Sie können einen booleschen Wert für `DisableScaleIn` angeben, um die Scale-In-Aktivität für Ihren Cluster zu aktivieren oder zu deaktivieren. Weitere Informationen finden Sie [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)in der API-Referenz für Application Auto Scaling.
Das folgende Beispiel beschreibt die Konfiguration einer Zielverfolgung für eine Skalierungsrichtlinie. In dieser Konfiguration passt die `ElastiCachePrimaryEngineCPUUtilization` vordefinierte Metrik einen OSS-Cluster ElastiCache für Valkey und Redis auf der Grundlage einer durchschnittlichen CPU-Auslastung von 40 Prozent auf allen primären Knoten in diesem Cluster an. Die Konfiguration deaktiviert die Scale-In-Aktivität für die Skalierungsrichtlinie.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
# Anwenden einer Skalierungsrichtlinie
Nachdem Sie Ihren Cluster bei ElastiCache for Valkey und Redis OSS Auto Scaling registriert und eine Skalierungsrichtlinie definiert haben, wenden Sie die Skalierungsrichtlinie auf den registrierten Cluster an. Um eine Skalierungsrichtlinie auf einen ElastiCache für Redis OSS-Cluster anzuwenden, können Sie die AWS CLI oder die Application Auto Scaling Scaling-API verwenden.
## Anwenden einer Skalierungsrichtlinie mithilfe der AWS CLI
Um eine Skalierungsrichtlinie auf Ihren OSS-Cluster ElastiCache für Valkey und Redis anzuwenden, verwenden Sie den [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)Befehl mit den folgenden Parametern:
+ **—policy-name**– Der Name der Skalierungsrichtlinie.
+ **--policy-type** – Legen Sie diesen Wert auf `TargetTrackingScaling` fest.
+ **--resource-id — Die Ressourcen-ID.** Für diesen Parameter ist der Ressourcentyp `ReplicationGroup` und der eindeutige Bezeichner beispielsweise der Name des Clusters. `replication-group/myscalablecluster`
+ **--service-namespace** – Legen Sie diesen Wert auf `elasticache` fest.
+ **--scalable-dimension** – Setzen Sie diesen Wert auf `elasticache:replication-group:NodeGroups`.
+ **-- target-tracking-scaling-policy -configuration — Die Konfiguration** der Skalierungsrichtlinie für die Zielverfolgung, die für den Cluster verwendet werden soll.
Im folgenden Beispiel wenden Sie eine Skalierungsrichtlinie `myscalablepolicy` zur Zielverfolgung an, die auf einen mit Auto Scaling benannten OSS-Cluster ElastiCache für Valkey und Redis OSS benannt `myscalablecluster` ist. ElastiCache Dazu verwenden Sie eine Richtlinienkonfiguration, die in einer Datei mit dem Namen `config.json` gespeichert ist.
Für Linux, macOS oder Unix:
```
aws application-autoscaling put-scaling-policy \
--policy-name myscalablepolicy \
--policy-type TargetTrackingScaling \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:NodeGroups \
--target-tracking-scaling-policy-configuration file://config.json
```
Für Windows:
```
aws application-autoscaling put-scaling-policy ^
--policy-name myscalablepolicy ^
--policy-type TargetTrackingScaling ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:NodeGroups ^
--target-tracking-scaling-policy-configuration file://config.json
```
## Anwendung einer Skalierungsrichtlinie mit der API
Um eine Skalierungsrichtlinie auf Ihren OSS-Cluster ElastiCache für Valkey und Redis anzuwenden, verwenden Sie den [PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) AWS CLI Befehl mit den folgenden Parametern:
+ **—policy-name**– Der Name der Skalierungsrichtlinie.
+ **--resource-id — Die Ressourcen-ID.** Für diesen Parameter ist der Ressourcentyp `ReplicationGroup` und der eindeutige Bezeichner beispielsweise der Name des Clusters. `replication-group/myscalablecluster`
+ **--service-namespace** – Legen Sie diesen Wert auf `elasticache` fest.
+ **--scalable-dimension** – Setzen Sie diesen Wert auf `elasticache:replication-group:NodeGroups`.
+ **-- target-tracking-scaling-policy -configuration — Die Konfiguration** der Skalierungsrichtlinie für die Zielverfolgung, die für den Cluster verwendet werden soll.
Im folgenden Beispiel wenden Sie eine Zielverfolgungs-Skalierungsrichtlinie mit dem Namen auf einen ElastiCache Cluster `myscalablepolicy` an, der `myscalablecluster` mit ElastiCache Auto Scaling benannt ist. Sie verwenden die Richtlinienkonfiguration `ElastiCachePrimaryEngineCPUUtilization` basierend auf einer vordefinierten Metrik.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
}
```
# Bearbeiten einer Skalierungsrichtlinie
Sie können eine Skalierungsrichtlinie mit der AWS-Managementkonsole, der oder der AWS CLI Application Auto Scaling API bearbeiten.
## Bearbeiten einer Skalierungsrichtlinie mit dem AWS-Managementkonsole
**So bearbeiten Sie eine Auto Scaling Scaling-Richtlinie ElastiCache für einen OSS-Cluster für Valkey und Redis**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Amazon-Konsole unter [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich die entsprechende Engine aus.
1. Wählen Sie den Cluster aus, dem Sie eine Richtlinie hinzufügen möchten (wählen Sie den Cluster-Namen und nicht die Schaltfläche links davon aus).
1. Wählen Sie die Registerkarte **Auto-Scaling-Richtlinien** aus.
1. Wählen Sie unter **Scaling policies** (Skalierungsrichtlinien) die Schaltfläche links neben der Auto-Scaling-Richtlinie aus, die Sie ändern möchten, und klicken Sie dann auf **Modify** (Ändern).
1. Nehmen Sie die erforderlichen Änderungen an der Richtlinie vor.
1. Wählen Sie **Ändern** aus.
## Bearbeiten einer Skalierungsrichtlinie mithilfe der AWS CLI AND-API
Sie können die AWS CLI oder die Application Auto Scaling Scaling-API verwenden, um eine Skalierungsrichtlinie auf die gleiche Weise zu bearbeiten, wie Sie eine Skalierungsrichtlinie anwenden:
+ Wenn Sie die verwenden AWS CLI, geben Sie den Namen der Richtlinie, die Sie bearbeiten möchten, im `--policy-name` Parameter an. Legen Sie neue Werte für die Parameter fest, die Sie ändern möchten.
+ Wenn Sie die Application Auto Scaling API verwenden, geben Sie den Namen der zu bearbeitenden Richtlinie im Parameter `PolicyName` an. Legen Sie neue Werte für die Parameter fest, die Sie ändern möchten.
Weitere Informationen finden Sie unter [Anwenden einer Skalierungsrichtlinie](AutoScaling-Scaling-Applying-a-Scaling-Policy.md).
# Löschen einer Skalierungsrichtlinie
Sie können eine Skalierungsrichtlinie mithilfe der AWS-Managementkonsole, der oder der AWS CLI Application Auto Scaling API löschen.
## Löschen einer Skalierungsrichtlinie mithilfe der AWS-Managementkonsole
**So löschen Sie eine Auto Scaling Scaling-Richtlinie für einen ElastiCache für Redis OSS-Cluster**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Amazon-Konsole unter [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis** OSS aus.
1. Wählen Sie den Cluster aus, dessen Auto-Scaling-Richtlinie Sie bearbeiten möchten (wählen Sie den Clusternamen aus, nicht die Schaltfläche links davon).
1. Wählen Sie die Registerkarte **Auto-Scaling-Richtlinien** aus.
1. Wählen Sie im Abschnitt **Scaling policies** (Skalierungsrichtlinien) die Auto-Scaling-Richtline und dann **Delete** (Löschen) aus.
## Löschen einer Skalierungsrichtlinie mit dem AWS CLI
Um eine Skalierungsrichtlinie ElastiCache für Ihren OSS-Cluster für Valkey und Redis zu löschen, verwenden Sie den [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI Befehl mit den folgenden Parametern:
+ **—policy-name**– Der Name der Skalierungsrichtlinie.
+ **--resource-id — Die Ressourcen-ID.** Für diesen Parameter ist der Ressourcentyp `ReplicationGroup` und der eindeutige Bezeichner beispielsweise der Name des Clusters. `replication-group/myscalablecluster`
+ **--service-namespace** – Legen Sie diesen Wert auf `elasticache` fest.
+ **--scalable-dimension** – Setzen Sie diesen Wert auf `elasticache:replication-group:NodeGroups`.
Im folgenden Beispiel löschen Sie eine Skalierungsrichtlinie für die Zielverfolgung mit dem Namen `myscalablepolicy` aus einem Cluster mit dem Namen. `myscalablecluster`
Für Linux, macOS oder Unix:
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:NodeGroups
```
Für Windows:
```
aws application-autoscaling delete-scaling-policy ^
--policy-name myscalablepolicy ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:NodeGroups
```
## Löschen einer Skalierungsrichtlinie über die API
Verwenden Sie den [DeleteScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI Befehl mit den folgenden Parametern, um eine Skalierungsrichtlinie ElastiCache für Ihren OSS-Cluster für Valkey und Redis zu löschen:
+ **—policy-name**– Der Name der Skalierungsrichtlinie.
+ **--resource-id — Die Ressourcen-ID.** Für diesen Parameter ist der Ressourcentyp `ReplicationGroup` und der eindeutige Bezeichner beispielsweise der Name des Clusters. `replication-group/myscalablecluster`
+ **--service-namespace** – Legen Sie diesen Wert auf `elasticache` fest.
+ **--scalable-dimension** – Setzen Sie diesen Wert auf `elasticache:replication-group:NodeGroups`.
Im folgenden Beispiel löschen Sie eine Skalierungsrichtlinie für die Zielverfolgung mit dem Namen `myscalablepolicy` aus einem Cluster mit dem Namen. `myscalablecluster`
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:NodeGroups"
}
```
# CloudFormation Für Auto Scaling Scaling-Richtlinien verwenden
Dieser Ausschnitt zeigt, wie Sie eine Richtlinie zur Zielverfolgung erstellen und sie auf eine [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)Ressource anwenden, die die [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)Ressource verwendet. Sie verwendet die intrinsischen Funktionen [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) und [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html), um die `ResourceId`-Eigenschaft mit dem logischen Namen der `AWS::ElastiCache::ReplicationGroup`-Ressource zu erstellen, die in derselben Vorlage angegeben ist.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 3
MinCapacity: 1
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:NodeGroups'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScalingPolicy:
Type: "AWS::ApplicationAutoScaling::ScalingPolicy"
Properties:
ScalingTargetId: !Ref ScalingTarget
ServiceNamespace: elasticache
PolicyName: testpolicy
PolicyType: TargetTrackingScaling
ScalableDimension: 'elasticache:replication-group:NodeGroups'
TargetTrackingScalingPolicyConfiguration:
PredefinedMetricSpecification:
PredefinedMetricType: ElastiCachePrimaryEngineCPUUtilization
TargetValue: 40
```
# Geplante Skalierung
Eine Skalierung anhand eines Zeitplans ermöglicht es Ihnen, Ihre Anwendung entsprechend vorhersagbarer Anforderungsänderungen zu skalieren. Um die geplante Skalierung zu verwenden, erstellen Sie geplante Aktionen, die Valkey und Redis OSS anweisen ElastiCache , Skalierungsaktivitäten zu bestimmten Zeiten durchzuführen. Wenn Sie eine geplante Aktion erstellen, geben Sie einen vorhandenen Cluster an, wann die Skalierungsaktivität stattfinden soll, sowie die Mindestkapazität und die maximale Kapazität. Sie können geplante Aktionen erstellen, die nur einmal skalieren oder wiederholt geplant ausgeführt werden.
Sie können eine geplante Aktion nur für Cluster erstellen, die bereits vorhanden sind. Sie können eine geplante Aktion und einen Cluster nicht gleichzeitig erstellen.
Weitere Informationen zur Terminologie für die Erstellung, Verwaltung und Löschung geplanter Aktionen finden Sie unter[Häufig verwendete Befehle für geplante Aktionen erstellen, verwalten und löschen](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)
**So erstellen Sie einen sich wiederholenden Zeitplan:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Amazon-Konsole unter [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis** OSS aus.
1. Wählen Sie den DB-Cluster aus, zu dem Sie die Richtlinie hinzufügen möchten.
1. Wählen Sie das Symbol**Verwalten der Auto Scaling Richtlinie**aus**Aktionen**Dropdown erstellen.
1. Wählen Sie die Registerkarte **Auto-Scaling-Richtlinien** aus.
1. Im Abschnitt **Auto-Scaling-Richtlinien** wird **Skalierungsrichtlinie hinzufügen** angezeigt. Klicken Sie auf **Geplante Skalierung**.
1. Geben Sie unter **Policy Name (Richtlinienname)** einen Namen für diese Richtlinie ein.
1. Für **Skalierbare Dimension** wählen Sie **Shards** aus.
1. Wählen Sie für **Ziel-Shards** den Wert aus.
1. Für **Wiederholung**, wählen Sie **Wiederkehrende** aus.
1. Für **Häufigkeit** wählen Sie den entsprechenden Wert aus.
1. Für**Startdatum**und**Beginnzeit**wählen Sie den Zeitpunkt aus, ab dem die Richtlinie wirksam wird.
1. Wählen Sie **Add Policy (Richtlinie hinzufügen)** aus.
**Erstellen Sie eine einmalige geplante Aktion wie folgt:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Amazon-Konsole unter [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis** OSS aus.
1. Wählen Sie den DB-Cluster aus, zu dem Sie die Richtlinie hinzufügen möchten.
1. Wählen Sie das Symbol**Verwalten der Auto Scaling Richtlinie**aus**Aktionen**Dropdown erstellen.
1. Wählen Sie die Registerkarte **Auto-Scaling-Richtlinien** aus.
1. Im Abschnitt **Auto-Scaling-Richtlinien** wird **Skalierungsrichtlinie hinzufügen** angezeigt. Klicken Sie auf **Geplante Skalierung**.
1. Geben Sie unter **Policy Name (Richtlinienname)** einen Namen für diese Richtlinie ein.
1. Für **Skalierbare Dimension** wählen Sie **Shards** aus.
1. Wählen Sie für **Ziel-Shards** den Wert aus.
1. Wählen Sie für **Wiederholung** **Einmalig** aus.
1. Für**Startdatum**und**Beginnzeit**wählen Sie den Zeitpunkt aus, ab dem die Richtlinie wirksam wird.
1. Für**Enddatum**wählen Sie das Datum, bis zu dem die Richtlinie wirksam sein würde.
1. Wählen Sie **Add Policy (Richtlinie hinzufügen)** aus.
**Löschen einer geplanten Aktion**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Amazon-Konsole unter [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis** OSS aus.
1. Wählen Sie den DB-Cluster aus, zu dem Sie die Richtlinie hinzufügen möchten.
1. Wählen Sie das Symbol**Verwalten der Auto Scaling Richtlinie**aus**Aktionen**Dropdown erstellen.
1. Wählen Sie die Registerkarte **Auto-Scaling-Richtlinien** aus.
1. Wählen Sie im Abschnitt **Auto-Scaling-Richtlinien** die Auto-Scaling-Richtlinie und dann **Löschen** im **Aktionen**-Dialog aus.
**Verwalten einer geplanten Skalierung mit AWS CLI **
Verwenden Sie die folgende automatische Anwendungsskalierung: APIs
+ [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-action.html)
+ [describe-scheduled-actions](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-scheduled-actions.html)
+ [delete-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scheduled-action.html)
## Verwenden Sie CloudFormation für die Erstellung einer geplanten Aktion
Dieser Ausschnitt zeigt, wie Sie eine Richtlinie zur Zielverfolgung erstellen und sie auf eine [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)Ressource anwenden, die die [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)Ressource verwendet. Sie verwendet die intrinsischen Funktionen [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) und [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html), um die `ResourceId`-Eigenschaft mit dem logischen Namen der `AWS::ElastiCache::ReplicationGroup`-Ressource zu erstellen, die in derselben Vorlage angegeben ist.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 3
MinCapacity: 1
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:NodeGroups'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScheduledActions:
- EndTime: '2020-12-31T12:00:00.000Z'
ScalableTargetAction:
MaxCapacity: '5'
MinCapacity: '2'
ScheduledActionName: First
Schedule: 'cron(0 18 * * ? *)'
```
# Verwenden von Auto Scaling mit Replikaten
Eine ElastiCache Replikationsgruppe kann einen oder mehrere Caches so einrichten, dass sie als einzelner logischer Knoten funktionieren.
Im Folgenden finden Sie Einzelheiten zur Zielverfolgung und zu geplanten Richtlinien sowie deren Anwendung mithilfe von AWS-Managementkonsole AWS CLI und APIs.
# Skalierungsrichtlinien für die Ziel-Nachverfolgung
Bei Skalierungsrichtlinien für die Zielverfolgung wählen Sie eine Metrik aus und legen einen Zielwert fest. ElastiCache für Valkey und Redis AutoScaling erstellt und verwaltet OSS die CloudWatch Alarme, die die Skalierungsrichtlinie auslösen, und berechnet die Skalierungsanpassung auf der Grundlage der Metrik und des Zielwerts. Die Skalierungsrichtlinie fügt -Repliken hinzu oder entfernt sie, wenn erforderlich, um die Metrik auf dem angegebenen Zielwert oder in der Nähe davon zu halten. Abgesehen davon, dass eine Skalierungsrichtlinie für die Ziel-Nachverfolgung die Metrik nahe an dem Zielwert hält, passt sie sich auch an die Schwankungen in der Metrik aufgrund eines schwankenden Lastmusters an und verringert schnelle Schwankungen der Kapazität der Flotte.
## Kriterien für die Auto Scaling von Replikaten
Ihre Auto Scaling Richtlinie definiert die folgende vordefinierte Metrik für Ihren Cluster:
`ElastiCacheReplicaEngineCPUUtilization`: Der Schwellenwert für die CPU-Auslastung von AVG Engine, aggregiert für alle Replikate, der ElastiCache verwendet wird, um einen auto-scaling Skalierungsvorgang auszulösen. Sie können das Auslastungsziel zwischen 35 Prozent und 70 Prozent festlegen.
Wenn der Service feststellt, dass Ihre `ElastiCacheReplicaEngineCPUUtilization` Metrik gleich oder größer als die Zieleinstellung ist, erhöht er automatisch die Anzahl der Replikate auf Ihren Shards. ElastiCache skaliert Ihre Cluster-Replikate um eine Anzahl, die der größeren von zwei Zahlen entspricht: prozentuale Abweichung von Target und ein Replikat. Bei Scale-In erfolgt ElastiCache keine auto Skalierung, es sei denn, der Gesamtmetrikwert liegt unter 75 Prozent Ihres definierten Ziels.
Wenn Sie für ein Scale-Out-Beispiel jeweils 5 Shards und 1 Replikat haben:
Wenn Ihr Target die Sicherheitslücken um 30 Prozent überschreitet, skaliert OSS ElastiCache für Valkey und Redis über alle Shards hinweg um 1 Replikat (max. 0,3, Standard 1). Das Ergebnis sind 5 Shards mit jeweils 2 Replikaten.
Wenn Sie beispielsweise einen Zielwert von 60 Prozent ausgewählt haben, wird OSS ElastiCache für Valkey und Redis erst auto skalieren, wenn die Metrik 45 Prozent oder weniger beträgt (25 Prozent unter dem Ziel von 60 Prozent).
### Überlegungen zum Auto Scaling
Beachten Sie folgende Überlegungen:
+ Eine Skalierungsrichtlinie für die Ziel-Nachverfolgung geht davon aus, dass sie eine horizontale Skalierung nach oben vornehmen soll, wenn die angegebene Metrik über dem Zielwert liegt. Sie können keine Skalierungsrichtlinie für die Zielverfolgung verwenden, um eine Skalierung vorzunehmen, wenn die angegebene Metrik unter dem Zielwert liegt. ElastiCache für Valkey und Redis skaliert OSS Replikate nach dem Maximum (% Abweichung abgerundet von Target, Standard 1) der vorhandenen Replikate auf allen Shards im Cluster.
+ Eine Skalierungsrichtlinie für die Ziel-Nachverfolgung nimmt keine Skalierung vor, wenn die angegebene Metrik unzureichende Daten aufweist. Es wird keine horizontale Skalierung nach unten vorgenommen, da unzureichende Daten nicht als geringe Auslastung interpretiert werden.
+ Möglicherweise werden Lücken zwischen den Datenpunkten für den Zielwert und die aktuelle Metrik angezeigt. Das liegt daran, dass ElastiCache Auto Scaling immer konservativ agiert, indem es auf- oder abrundet, wenn es bestimmt, wie viel Kapazität hinzugefügt oder entfernt werden soll. Dadurch wird verhindert, dass zu wenig Kapazität hinzufügt oder zu viel Kapazität entfernt wird.
+ Um die Verfügbarkeit der Anwendung sicherzustellen, wird der Service schnellstmöglich proportional zur Metrik hochskaliert, jedoch etwas langsamer herunterskaliert.
+ Sie können mehrere Skalierungsrichtlinien zur Zielverfolgung für einen OSS-Cluster ElastiCache für Valkey und Redis verwenden, vorausgesetzt, dass jeder von ihnen eine andere Metrik verwendet. Die Absicht von Auto Scaling besteht darin, der Verfügbarkeit immer Priorität einzuräumen. Daher unterscheidet sich das Verhalten je nachdem, ob die Zielverfolgungsrichtlinien für die horizontale Skalierung oder für die Skalierung bereit sind. Sofern Richtlinien für die Ziel-Nachverfolgung für die Skalierung nach oben bereit sind, findet eine Skalierung des Service nach oben statt. Eine Skalierung nach unten wird jedoch nur vorgenommen, wenn alle Richtlinien für die Ziel-Nachverfolgung (mit aktivierter Skalierung nach unten) zur Skalierung nach unten bereit sind.
+ Bearbeiten oder löschen Sie nicht die CloudWatch Alarme, die ElastiCache Auto Scaling für eine Skalierungsrichtlinie zur Zielverfolgung verwaltet. Auto Scaling löscht die Alarme automatisch, wenn Sie die Skalierungsrichtlinie oder den Cluster löschen.
+ ElastiCache Auto Scaling hindert Sie nicht daran, Replikate auf mehreren Shards manuell zu ändern. Diese manuellen Anpassungen wirken sich nicht auf bestehende CloudWatch Alarme aus, die mit der Skalierungsrichtlinie verknüpft sind, können sich jedoch auf Metriken auswirken, die diese CloudWatch Alarme auslösen können.
+ Diese von Auto Scaling verwalteten CloudWatch Alarme werden anhand der AVG-Metrik für alle Shards im Cluster definiert. So kann Hot-Shards zu einem beliebigen Szenario führen:
+ Skalierung, wenn sie nicht erforderlich ist, weil die Belastung einiger Hot-Shards einen Alarm auslöst CloudWatch
+ nicht skalieren, wenn dies erforderlich ist, aufgrund aggregierter AVG über alle Shards, die den Alarm nicht verletzen.
+ ElastiCache Die Standardgrenzwerte für Knoten pro Cluster gelten weiterhin. Wenn Sie sich also für Auto Scaling entscheiden und erwarten, dass maximale Knoten mehr als die Standardgrenze sind, fordern Sie eine Limiterhöhung bei [AWS -Service-Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) an und wählen Sie den Limit-Typ **Knoten pro Cluster pro Instance-Typ**.
+ Stellen Sie sicher, dass in Ihrer VPC genügend ENIs (Elastic Network Interfaces) verfügbar sind, die beim Scale-Out benötigt werden. Weitere Informationen finden Sie unter [Elastic-Network-Schnittstellen](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html).
+ Wenn nicht genügend Kapazität verfügbar ist EC2, wird ElastiCache Auto Scaling erst skaliert, wenn entweder die Kapazität verfügbar ist oder wenn Sie den Cluster manuell auf die Instance-Typen mit ausreichender Kapazität ändern.
+ ElastiCache Auto Scaling unterstützt keine Skalierung von Replikaten mit einem Cluster mit `ReservedMemoryPercent` weniger als 25 Prozent. Weitere Informationen finden Sie unter [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md).
# Hinzufügen einer Skalierungsrichtlinie
Sie können eine Skalierungsrichtlinie hinzufügen, indem Sie die verwenden AWS-Managementkonsole.
**Hinzufügen einer Skalierungsrichtlinie mithilfe des AWS-Managementkonsole**
Um eine Auto Scaling-Richtlinie ElastiCache für Valkey und Redis OSS hinzuzufügen
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Amazon-Konsole unter [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis** OSS aus.
1. Wählen Sie den Cluster aus, dem Sie eine Richtlinie hinzufügen möchten (wählen Sie den Cluster-Namen und nicht die Schaltfläche links davon aus).
1. Wählen Sie die Registerkarte **Auto-Scaling-Richtlinien** aus.
1. Wählen Sie **Add dynamic scaling** (Dynamische Skalierung hinzufügen) aus.
1. Wählen Sie unter **Scaling policies** (Skalierungsrichtlinien) **Add dynamic scaling** (Dynamische Skalierung hinzufügen) aus.
1. Geben Sie unter **Policy Name (Richtlinienname)** einen Namen für diese Richtlinie ein.
1. Für**Skalierbare Dimension**auf und danach**Replicas**-Dialogfeld aus erstellen.
1. Geben Sie als Zielwert den durchschnittlichen Prozentsatz der CPU-Auslastung ein, den Sie auf ElastiCache Replicas beibehalten möchten. Dieser Wert muss größer 35 und kleiner 70 sein. -Repliken werden hinzugefügt oder entfernt, um die Metrik in der Nähe des angegebenen Wertes zu halten.
1. (Optional) Die Ruhephase für Scale-In- oder Scale-Out-Ruhephase werden von der Konsole nicht unterstützt. Verwenden Sie den AWS CLI , um die Abkühlwerte zu ändern.
1. Geben Sie für **Mindestkapazität** die Mindestanzahl von Replikaten ein, für deren Verwaltung die ElastiCache Auto Scaling Scaling-Richtlinie erforderlich ist.
1. Geben Sie für **Maximale Kapazität** die maximale Anzahl von Replikaten ein, die die ElastiCache Auto Scaling Scaling-Richtlinie verwalten muss. Der Wert muss größer als 5 sein.
1. Wählen Sie **Erstellen** aus.
# Registrieren eines skalierbaren Ziels
Sie können eine Skalierungsrichtlinie anwenden, die entweder auf einer vordefinierten oder einer benutzerdefinierten Metrik basiert. Dazu können Sie die AWS CLI oder die Application Auto Scaling API verwenden. Der erste Schritt besteht darin, Ihre OSS-Replikationsgruppe ElastiCache für Valkey und Redis bei Auto Scaling zu registrieren.
Bevor Sie ElastiCache Auto Scaling mit einem Cluster verwenden können, müssen Sie Ihren Cluster bei ElastiCache Auto Scaling registrieren. Sie tun dies, um die Skalierungsdimension und die Grenzwerte zu definieren, die auf diesen Cluster angewendet werden sollen. ElastiCache Auto Scaling skaliert den Cluster dynamisch entlang der `elasticache:replication-group:Replicas` skalierbaren Dimension, die die Anzahl der Cluster-Replikate pro Shard darstellt.
**Verwenden der CLI**
Verwenden Sie den [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)Befehl mit den folgenden Parametern, um Ihren ElastiCache Cluster zu registrieren:
+ —service-namespace — Legen Sie diesen Wert auf elasticache fest.
+ --resource-id — Die Ressourcen-ID für den Cluster. ElastiCache Für diesen Parameter ist der Ressourcentyp ReplicationGroup und die eindeutige Kennung beispielsweise der Name des Clusters. `replication-group/myscalablecluster`
+ --scalable-dimension – Setzen Sie diesen Wert auf `elasticache:replication-group:Replicas`.
+ --min-capacity — Die Mindestanzahl von Replikaten, die mit Auto Scaling verwaltet werden sollen. ElastiCache Informationen zur Beziehung zwischen --min-capacity, --max-capacity und der Anzahl der Replikate in Ihrem Cluster finden Sie unter [Minimale und maximale Kapazität](AutoScaling-Policies.md#AutoScaling-MinMax).
+ --max-capacity — Die maximale Anzahl von Replikaten, die mit Auto Scaling verwaltet werden können. ElastiCache Informationen zur Beziehung zwischen --min-capacity, --max-capacity und der Anzahl der Replikate in Ihrem Cluster finden Sie unter [Minimale und maximale Kapazität](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Im folgenden Beispiel registrieren Sie einen Cluster mit dem Namen. ElastiCache `myscalablecluster` Die Registrierung zeigt an, dass der Cluster dynamisch skaliert werden soll, um zwischen einem und 5 Replikaten zu haben.
Für Linux, macOS oder Unix:
```
aws application-autoscaling register-scalable-target \
--service-namespace elasticache \
--resource-id replication-group/myscalablecluster \
--scalable-dimension elasticache:replication-group:Replicas \
--min-capacity 1 \
--max-capacity 5 \
```
Für Windows:
```
aws application-autoscaling register-scalable-target ^
--service-namespace elasticache ^
--resource-id replication-group/myscalablecluster ^
--scalable-dimension elasticache:replication-group:Replicas ^
--min-capacity 1 ^
--max-capacity 5 ^
```
**Verwenden der API**
Verwenden Sie den [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)Befehl mit den folgenden Parametern, um Ihren ElastiCache Cluster zu registrieren:
+ ServiceNamespace — Setzen Sie diesen Wert auf elasticache.
+ ResourceID — Die Ressourcen-ID für den ElastiCache Cluster. Für diesen Parameter ist der Ressourcentyp ReplicationGroup und die eindeutige Kennung beispielsweise `replication-group/myscalablecluster` der Name des Clusters.
+ ScalableDimension — Setzen Sie diesen Wert auf`elasticache:replication-group:Replicas`.
+ MinCapacity — Die Mindestanzahl von Replikaten, die mit ElastiCache Auto Scaling verwaltet werden müssen. Informationen zur Beziehung zwischen --min-capacity, --max-capacity und der Anzahl der Replikate in Ihrem Cluster finden Sie unter [Minimale und maximale Kapazität](AutoScaling-Policies.md#AutoScaling-MinMax).
+ MaxCapacity — Die maximale Anzahl von Replikaten, die mit ElastiCache Auto Scaling verwaltet werden können. Informationen zur Beziehung zwischen --min-capacity, --max-capacity und der Anzahl der Replikate in Ihrem Cluster finden Sie unter [Minimale und maximale Kapazität](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Im folgenden Beispiel registrieren Sie einen Cluster, der `myscalablecluster` mit der Application Auto Scaling API benannt ist. Diese Registrierung zeigt an, dass der Cluster dynamisch skaliert werden soll, um zwischen 1 und 5 Replikate zu haben.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.RegisterScalableTarget
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas",
"MinCapacity": 1,
"MaxCapacity": 5
}
```
# Definieren einer Skalierungsrichtlinie
Eine Konfiguration der Skalierungsrichtlinie für die Zielverfolgung wird durch einen JSON-Block repräsentiert, in dem die Metriken und Zielwerte definiert sind. Sie können die Konfiguration einer Skalierungsrichtlinie als JSON-Block in einer Textdatei speichern. Sie verwenden diese Textdatei, wenn Sie die AWS CLI oder die Application Auto Scaling Scaling-API aufrufen. Weitere Informationen zur Syntax der Richtlinienkonfiguration finden Sie unter [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in der *API-Referenz für Application Auto Scaling*.
Die folgenden Optionen stehen zur Verfügung, um eine Konfiguration der Skalierungsrichtlinien für die Zielverfolgung zu definieren:
**Topics**
+ [Verwenden einer vordefinierten Metrik](#AutoScaling-Predefined-Metric)
+ [Bearbeiten einer Skalierungsrichtlinie](AutoScaling-Editing-Policy.md)
+ [Löschen einer Skalierungsrichtlinie](AutoScaling-Deleting-Policy.md)
+ [CloudFormation Für Auto Scaling Scaling-Richtlinien verwenden](AutoScaling-with-Cloudformation.md)
+ [Geplante Skalierung](AutoScaling-with-Scheduled-Scaling-Replicas.md)
## Verwenden einer vordefinierten Metrik
Eine Konfiguration der Skalierungsrichtlinie für die Zielverfolgung wird durch einen JSON-Block repräsentiert, in dem die Metriken und Zielwerte definiert sind. Sie können die Konfiguration einer Skalierungsrichtlinie als JSON-Block in einer Textdatei speichern. Sie verwenden diese Textdatei, wenn Sie die AWS CLI oder die Application Auto Scaling Scaling-API aufrufen. Weitere Informationen zur Syntax der Richtlinienkonfiguration finden Sie unter [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in der *API-Referenz für Application Auto Scaling*.
Die folgenden Optionen stehen zur Verfügung, um eine Konfiguration der Skalierungsrichtlinien für die Zielverfolgung zu definieren:
**Topics**
+ [Verwenden einer vordefinierten Metrik](#AutoScaling-Predefined-Metric)
+ [Verwenden einer benutzerdefinierten Metrik](#AutoScaling-Custom-Metric)
+ [Verwenden von Ruhephasen](#AutoScaling-Using-Cooldowns)
+ [Deaktivieren der Scale-In-Aktivität](#AutoScaling-Disabling-Scalein)
+ [Anwendung einer Skalierungsrichtlinie auf einen ElastiCache OSS-Cluster für Valkey und Redis](#AutoScaling-Applying-Policy)
### Verwenden einer vordefinierten Metrik
Mithilfe vordefinierter Metriken können Sie schnell eine Skalierungsrichtlinie für die Zielverfolgung für einen OSS-Cluster ElastiCache für Valkey und Redis definieren, der mit der Zielverfolgung in Auto Scaling funktioniert. ElastiCache ElastiCache Unterstützt derzeit die folgende vordefinierte Metrik in ElastiCache Replicas Auto Scaling:
`ElastiCacheReplicaEngineCPUUtilization`— Der Durchschnittswert der CPUUtilization Engine-Metrik CloudWatch für alle Replikate im Cluster. Den aggregierten Metrikwert finden Sie CloudWatch unter „Erforderlich“ ReplicationGroupId und „ ElastiCache `ReplicationGroupId, Role`Rollenreplikat“.
Um eine vordefinierte Metrik in Ihrer Skalierungsrichtlinie zu verwenden, erstellen Sie eine Zielverfolgungskonfiguration für Ihre Skalierungsrichtlinie. Diese Konfiguration muss eine `PredefinedMetricSpecification` für die vordefinierte Metrik und einen `TargetValue` für den Zielwert dieser Metrik enthalten.
### Verwenden einer benutzerdefinierten Metrik
Durch die Verwendung von benutzerdefinierten Metriken können Sie eine Skalierungsrichtlinie für die Zielverfolgung definieren, die Ihren individuellen Anforderungen entspricht. Sie können eine benutzerdefinierte Metrik definieren, die auf einer beliebigen OSS-Metrik ElastiCache für Valkey und Redis basiert und sich proportional zur Skalierung ändert. Nicht alle ElastiCache Metriken eignen sich für die Zielverfolgung. Die Metrik muss eine gültige Auslastungsmetrik sein und beschreiben, wie ausgelastet eine Instance ist. Der Wert der Metrik muss sich proportional zur Anzahl der -Replicas im -DB-Cluster erhöhen oder verringern. Diese proportionale Erhöhung oder Verminderung ist notwendig, um die metrischen Daten zur proportionalen Skalierung oder in der Anzahl der -Repliken zu verwenden.
**Example**
Das folgende Beispiel beschreibt die Konfiguration einer Zielverfolgung für eine Skalierungsrichtlinie. In dieser Konfiguration passt eine benutzerdefinierte Metrik einen Cluster auf der Grundlage einer durchschnittlichen CPU-Auslastung von 50 Prozent für alle Replikate in einem Cluster mit dem Namen an. `my-db-cluster`
```
{"TargetValue": 50,
"CustomizedMetricSpecification":
{"MetricName": "EngineCPUUtilization",
"Namespace": "AWS/ElastiCache",
"Dimensions": [
{"Name": "ReplicationGroup","Value": "my-db-cluster"},
{"Name": "Role","Value": "REPLICA"}
],
"Statistic": "Average",
"Unit": "Percent"
}
}
```
### Verwenden von Ruhephasen
Sie können einen Wert in Sekunden für `ScaleOutCooldown` angeben, um eine Ruhephase für die Aufskalierung Ihres Clusters hinzuzufügen. Ähnlich können Sie einen Wert in Sekunden für `ScaleInCooldown` angeben, um eine Ruhephase für die Abskalierung Ihres Clusters hinzuzufügen. Weitere Informationen über `ScaleInCooldown` und `ScaleOutCooldown` finden Sie unter [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in der *API-Referenz für Application Auto Scaling*. Das folgende Beispiel beschreibt die Konfiguration einer Zielverfolgung für eine Skalierungsrichtlinie. In dieser Konfiguration wird die `ElastiCacheReplicaEngineCPUUtilization` vordefinierte Metrik verwendet, um einen Cluster auf der Grundlage einer durchschnittlichen CPU-Auslastung von 40 Prozent für alle Replikate in diesem Cluster anzupassen. Die Konfiguration sieht eine Scale-In-Ruhephase von 10 Minuten und eine Scale-Out-Ruhephase von 5 Minuten vor.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
### Deaktivieren der Scale-In-Aktivität
Sie können verhindern, dass die Konfiguration der Skalierungsrichtlinie für die Zielverfolgung in Ihrem OSS-Cluster ElastiCache für Valkey und Redis skaliert, indem Sie die Scale-In-Aktivität deaktivieren. Das Deaktivieren der Scale-In-Aktivität verhindert das Löschen von -Repliken durch die Skalierungsrichtlinie, und erlaubt der Skalierungsrichtlinie dennoch, Repliken nach Bedarf zu erstellen.
Sie können einen booleschen Wert für `DisableScaleIn` angeben, um die Scale-In-Aktivität für Ihren Cluster zu aktivieren oder zu deaktivieren. Weitere Informationen über `DisableScaleIn` finden Sie unter [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in der *API-Referenz für Application Auto Scaling*.
**Example**
Das folgende Beispiel beschreibt die Konfiguration einer Zielverfolgung für eine Skalierungsrichtlinie. In dieser Konfiguration passt die `ElastiCacheReplicaEngineCPUUtilization` vordefinierte Metrik einen Cluster auf der Grundlage einer durchschnittlichen CPU-Auslastung von 40 Prozent für alle Replikate in diesem Cluster an. Die Konfiguration deaktiviert die Scale-In-Aktivität für die Skalierungsrichtlinie.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
### Anwendung einer Skalierungsrichtlinie auf einen ElastiCache OSS-Cluster für Valkey und Redis
Nachdem Sie Ihren Cluster bei ElastiCache for Valkey und Redis OSS Auto Scaling registriert und eine Skalierungsrichtlinie definiert haben, wenden Sie die Skalierungsrichtlinie auf den registrierten Cluster an. Um eine Skalierungsrichtlinie auf einen OSS-Cluster ElastiCache für Valkey und Redis anzuwenden, können Sie die AWS CLI oder die Application Auto Scaling Scaling-API verwenden.
**Unter Verwendung der AWS CLI**
Verwenden Sie den [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)Befehl mit den folgenden Parametern, um eine Skalierungsrichtlinie auf Ihren OSS-Cluster ElastiCache für Valkey und Redis anzuwenden:
+ --plolicy-name – Der Name der Skalierungsrichtlinie.
+ --policy-type – Setzen Sie diesen Wert auf `TargetTrackingScaling`.
+ --resource-id — Die Ressourcen-ID für den Cluster. Für diesen Parameter ist der Ressourcentyp ReplicationGroup und die eindeutige Kennung beispielsweise der Name des Clusters. `replication-group/myscalablecluster`
+ —service-namespace — Legen Sie diesen Wert auf elasticache fest.
+ --scalable-dimension – Setzen Sie diesen Wert auf `elasticache:replication-group:Replicas`.
+ -- target-tracking-scaling-policy -configuration — Die Konfiguration der Skalierungsrichtlinie für die Zielverfolgung, die für den Cluster verwendet werden soll.
**Example**
Im folgenden Beispiel wenden Sie eine Zielverfolgungs-Skalierungsrichtlinie mit dem Namen auf einen Cluster `myscalablepolicy` an, der `myscalablecluster` mit ElastiCache Auto Scaling benannt ist. Dazu verwenden Sie eine Richtlinienkonfiguration, die in einer Datei mit dem Namen `config.json` gespeichert ist.
Für Linux, macOS oder Unix:
```
aws application-autoscaling put-scaling-policy \
--policy-name myscalablepolicy \
--policy-type TargetTrackingScaling \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:Replicas \
--target-tracking-scaling-policy-configuration file://config.json
```
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
Für Windows:
```
aws application-autoscaling put-scaling-policy ^
--policy-name myscalablepolicy ^
--policy-type TargetTrackingScaling ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:Replicas ^
--target-tracking-scaling-policy-configuration file://config.json
```
**Verwenden der API**
Um mit der Application Auto Scaling API eine Skalierungsrichtlinie auf Ihren ElastiCache Cluster anzuwenden, verwenden Sie den [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)Application Auto Scaling API-Vorgang mit den folgenden Parametern:
+ PolicyName — Der Name der Skalierungsrichtlinie.
+ PolicyType — Setzen Sie diesen Wert auf`TargetTrackingScaling`.
+ ResourceID — Die Ressourcen-ID für den Cluster. Für diesen Parameter ist der Ressourcentyp ReplicationGroup und der eindeutige Bezeichner beispielsweise der Name des ElastiCache für Redis OSS-Clusters. `replication-group/myscalablecluster`
+ ServiceNamespace — Setzen Sie diesen Wert auf Elasticache.
+ ScalableDimension — Setze diesen Wert auf`elasticache:replication-group:Replicas`.
+ TargetTrackingScalingPolicyConfiguration — Die Konfiguration der Skalierungsrichtlinie für die Zielverfolgung, die für den Cluster verwendet werden soll.
**Example**
Im folgenden Beispiel wenden Sie eine Zielverfolgungs-Skalierungsrichtlinie mit dem Namen auf einen Cluster `scalablepolicy` an, der `myscalablecluster` mit ElastiCache Auto Scaling benannt ist. Sie verwenden die Richtlinienkonfiguration `ElastiCacheReplicaEngineCPUUtilization` basierend auf einer vordefinierten Metrik.
```
POST / HTTP/1.1
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.PutScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
}
}
}
```
# Bearbeiten einer Skalierungsrichtlinie
Sie können eine Skalierungsrichtlinie mit der AWS-Managementkonsole, der oder der AWS CLI Application Auto Scaling API bearbeiten.
**Bearbeiten einer Skalierungsrichtlinie mit dem AWS-Managementkonsole**
Sie können Richtlinien mit dem Typ Vordefinierte Metriken nur bearbeiten, indem Sie die AWS-Managementkonsole
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Amazon-Konsole unter [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis** OSS
1. Wählen Sie den Cluster aus, dem Sie eine Richtlinie hinzufügen möchten (wählen Sie den Cluster-Namen und nicht die Schaltfläche links davon aus).
1. Wählen Sie die Registerkarte **Auto-Scaling-Richtlinien** aus.
1. Wählen Sie unter **Scaling policies** (Skalierungsrichtlinien) die Schaltfläche links neben der Auto-Scaling-Richtlinie aus, die Sie ändern möchten, und klicken Sie dann auf **Modify** (Ändern).
1. Nehmen Sie die erforderlichen Änderungen an der Richtlinie vor.
1. Wählen Sie **Ändern** aus.
1. Nehmen Sie die Änderungen an der Richtlinie vor.
1. Wählen Sie **Ändern** aus.
**Bearbeiten einer Skalierungsrichtlinie mit der AWS CLI oder der Application Auto Scaling API**
Sie können die AWS CLI oder die Application Auto Scaling Scaling-API verwenden, um eine Skalierungsrichtlinie auf die gleiche Weise zu bearbeiten, wie Sie eine Skalierungsrichtlinie anwenden:
+ Wenn Sie die Application Auto Scaling API verwenden, geben Sie den Namen der zu bearbeitenden Richtlinie im Parameter `PolicyName` an. Legen Sie neue Werte für die Parameter fest, die Sie ändern möchten.
Weitere Informationen finden Sie unter [Anwendung einer Skalierungsrichtlinie auf einen ElastiCache OSS-Cluster für Valkey und Redis](AutoScaling-Defining-Policy.md#AutoScaling-Applying-Policy).
# Löschen einer Skalierungsrichtlinie
Sie können eine Skalierungsrichtlinie mit der AWS-Managementkonsole, der AWS CLI oder der Application Auto Scaling API löschen
**Löschen einer Skalierungsrichtlinie mithilfe der AWS-Managementkonsole**
Sie können Richtlinien mit dem Typ Vordefinierte Metriken nur bearbeiten, indem Sie die AWS-Managementkonsole
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Amazon-Konsole unter [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis** OSS
1. Wählen Sie den Cluster aus, dessen Auto-Scaling-Richtlinie Sie löschen möchten.
1. Wählen Sie die Registerkarte **Auto-Scaling-Richtlinien** aus.
1. Wählen Sie im Abschnitt **Scaling policies** (Skalierungsrichtlinien) die Auto-Scaling-Richtlinie und dann **Delete** (Löschen) aus.
**Löschen einer Skalierungsrichtlinie mithilfe der AWS CLI oder der Application Auto Scaling API**
Sie können die AWS CLI oder die Application Auto Scaling API verwenden, um eine Skalierungsrichtlinie aus einem ElastiCache Cluster zu löschen.
**CLI**
Verwenden Sie den [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html)Befehl mit den folgenden Parametern, um eine Skalierungsrichtlinie aus Ihrem OSS-Cluster ElastiCache für Valkey und Redis zu löschen:
+ --plolicy-name – Der Name der Skalierungsrichtlinie.
+ --resource-id — Die Ressourcen-ID für den Cluster. Für diesen Parameter ist der Ressourcentyp ReplicationGroup und die eindeutige Kennung beispielsweise der Name des Clusters. `replication-group/myscalablecluster`
+ —service-namespace — Legen Sie diesen Wert auf elasticache fest.
+ --scalable-dimension – Setzen Sie diesen Wert auf `elasticache:replication-group:Replicas`.
**Example**
Im folgenden Beispiel löschen Sie eine Zielverfolgungs-Skalierungsrichtlinie namens `myscalablepolicy` aus einem ElastiCache-Cluster namens `myscalablecluster`.
Für Linux, macOS oder Unix:
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:Replicas \
```
Für Windows:
```
aws application-autoscaling delete-scaling-policy ^
--policy-name myscalablepolicy ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:Replicas ^
```
**API**
Um eine Skalierungsrichtlinie aus Ihrem ElastiCache für Valkey und Redis OSS-Cluster zu löschen, verwenden Sie den [DeleteScalingPolicy](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_DeleteScalingPolicy.html)Application Auto Scaling API-Vorgang mit den folgenden Parametern:
+ PolicyName — Der Name der Skalierungsrichtlinie.
+ ResourceId — Die ResourceID für den Cluster. Für diesen Parameter ist der Ressourcentyp ReplicationGroup und die eindeutige Kennung beispielsweise `replication-group/myscalablecluster` der Name des Clusters.
+ ServiceNamespace — Setzen Sie diesen Wert auf Elasticache.
+ ScalableDimension — Setze diesen Wert auf`elasticache:replication-group:Replicas`.
Im folgenden Beispiel löschen Sie eine Skalierungsrichtlinie für die Zielverfolgung, die `myscalablepolicy` aus einem Cluster benannt ist, der `myscalablecluster` mit der Application Auto Scaling Scaling-API benannt ist.
```
POST / HTTP/1.1
>>>>>>> mainline
Host: autoscaling.us-east-2.amazonaws.com
Accept-Encoding: identity
Content-Length: 219
X-Amz-Target: AnyScaleFrontendService.DeleteScalingPolicy
X-Amz-Date: 20160506T182145Z
User-Agent: aws-cli/1.10.23 Python/2.7.11 Darwin/15.4.0 botocore/1.4.8
Content-Type: application/x-amz-json-1.1
Authorization: AUTHPARAMS
{
"PolicyName": "myscalablepolicy",
"ServiceNamespace": "elasticache",
"ResourceId": "replication-group/myscalablecluster",
"ScalableDimension": "elasticache:replication-group:Replicas"
}
```
# CloudFormation Für Auto Scaling Scaling-Richtlinien verwenden
Dieser Ausschnitt zeigt, wie Sie eine geplante Aktion erstellen und sie auf eine Ressource anwenden, die die [AWS::ElastiCache::ReplicationGroup[AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)Ressource verwendet. Sie verwendet die intrinsischen Funktionen [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) und [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html), um die `ResourceId`-Eigenschaft mit dem logischen Namen der `AWS::ElastiCache::ReplicationGroup`-Ressource zu erstellen, die in derselben Vorlage angegeben ist.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 0
MinCapacity: 0
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:Replicas'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScalingPolicy:
Type: "AWS::ApplicationAutoScaling::ScalingPolicy"
Properties:
ScalingTargetId: !Ref ScalingTarget
ServiceNamespace: elasticache
PolicyName: testpolicy
PolicyType: TargetTrackingScaling
ScalableDimension: 'elasticache:replication-group:Replicas'
TargetTrackingScalingPolicyConfiguration:
PredefinedMetricSpecification:
PredefinedMetricType: ElastiCacheReplicaEngineCPUUtilization
TargetValue: 40
```
# Geplante Skalierung
Eine Skalierung anhand eines Zeitplans ermöglicht es Ihnen, Ihre Anwendung entsprechend vorhersagbarer Anforderungsänderungen zu skalieren. Um die geplante Skalierung zu verwenden, erstellen Sie geplante Aktionen, die Valkey und Redis OSS anweisen ElastiCache , Skalierungsaktivitäten zu bestimmten Zeiten durchzuführen. Wenn Sie eine geplante Aktion erstellen, geben Sie einen vorhandenen ElastiCache Cluster an, wann die Skalierungsaktivität stattfinden soll, sowie die Mindestkapazität und die maximale Kapazität. Sie können geplante Aktionen erstellen, die nur einmal skalieren oder wiederholt geplant ausgeführt werden.
Sie können eine geplante Aktion nur für ElastiCache Cluster erstellen, die bereits vorhanden sind. Sie können eine geplante Aktion und einen Cluster nicht gleichzeitig erstellen.
Weitere Informationen zur Terminologie für die Erstellung, Verwaltung und Löschung geplanter Aktionen finden Sie unter[Häufig verwendete Befehle für geplante Aktionen erstellen, verwalten und löschen](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)
**Erstellen Sie eine einmalige geplante Aktion wie folgt**
Ähnlich wie Shard Dimension. Siehe [Geplante Skalierung](AutoScaling-with-Scheduled-Scaling-Shards.md).
**Löschen einer geplanten Aktion**
Ähnlich wie Shard Dimension. Siehe [Geplante Skalierung](AutoScaling-with-Scheduled-Scaling-Shards.md).
**Verwalten einer geplanten Skalierung mit AWS CLI **
Verwenden Sie die folgende automatische Anwendungsskalierung APIs:
+ [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html)
+ [describe-scheduled-actions](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scheduled-actions.html)
+ [delete-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scheduled-action.html)
## Wird verwendet CloudFormation , um Auto Scaling Scaling-Richtlinien zu erstellen
Dieser Ausschnitt zeigt, wie Sie eine geplante Aktion erstellen und sie auf eine Ressource anwenden, die die [AWS::ElastiCache::ReplicationGroup[AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)Ressource verwendet. Sie verwendet die intrinsischen Funktionen [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) und [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html), um die `ResourceId`-Eigenschaft mit dem logischen Namen der `AWS::ElastiCache::ReplicationGroup`-Ressource zu erstellen, die in derselben Vorlage angegeben ist.
```
ScalingTarget:
Type: 'AWS::ApplicationAutoScaling::ScalableTarget'
Properties:
MaxCapacity: 0
MinCapacity: 0
ResourceId: !Sub replication-group/${logicalName}
ScalableDimension: 'elasticache:replication-group:Replicas'
ServiceNamespace: elasticache
RoleARN: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/elasticache.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG"
ScheduledActions:
- EndTime: '2020-12-31T12:00:00.000Z'
ScalableTargetAction:
MaxCapacity: '5'
MinCapacity: '2'
ScheduledActionName: First
Schedule: 'cron(0 18 * * ? *)'
```
# Ändern des Clustermodus
Valkey und Redis OSS sind verteilte In-Memory-Datenbanken, die Sharding und Replikation unterstützen. ElastiCache Valkey- und Redis OSS-Cluster sind die verteilte Implementierung, mit der Daten auf mehrere Knoten partitioniert werden können. Ein OSS-Cluster ElastiCache für Redis hat zwei Betriebsmodi: den Clustermodus aktiviert (CME) und den Clustermodus deaktiviert (CMD). In CME funktioniert eine Valkey- und Redis-OSS-Engine als verteilte Datenbank mit mehreren Shards und Knoten, während Valkey und Redis OSS in CMD als ein einziger Knoten arbeiten.
Vor der Migration von CMD zu CME müssen die folgenden Bedingungen erfüllt sein:
**Wichtig**
Die Konfiguration des Clustermodus kann nur vom deaktivierten in den aktivierten Clustermodus geändert werden. Das Zurücksetzen dieser Konfiguration ist nicht möglich.
+ Der Cluster darf nur Schlüssel in der Datenbank 0 haben.
+ Anwendungen müssen einen Valkey- oder Redis-OSS-Client verwenden, der das Cluster-Protokoll verwenden kann, und einen Konfigurationsendpunkt verwenden.
+ Das automatische Failover muss auf dem Cluster mit mindestens einem Replikat aktiviert sein.
+ Die für die Migration erforderliche Engine-Mindestversion ist Valkey 7.2 und höher oder Redis OSS 7.0 und höher.
Um von CMD zu CME zu migrieren, muss die Konfiguration des Clustermodus vom deaktivierten in den aktivierten Clustermodus geändert werden. Dies ist ein zweistufiges Verfahren, das die Clusterverfügbarkeit während des Migrationsprozesses sicherstellt.
**Anmerkung**
Sie müssen eine Parametergruppe mit clusterfähiger Konfiguration angeben, d. h., der clusterfähige Parameter ist auf `yes` festgelegt. Wenn Sie eine Standardparametergruppe verwenden, wählt OSS ElastiCache für Redis automatisch die entsprechende Standardparametergruppe mit einer clusterfähigen Konfiguration aus. Der clusterfähige Parameterwert ist für einen CMD-Cluster auf `no` festgelegt. Wenn der Cluster in den kompatiblen Modus wechselt, wird der clusterfähige Parameterwert im Rahmen der Änderungsaktion auf `yes` aktualisiert.
Weitere Informationen finden Sie unter [Konfiguration von Motorparametern mithilfe von ElastiCache Parametergruppen](ParameterGroups.md).
1. **Vorbereitung** — Erstellen Sie einen CME-Test-CME-Cluster und stellen Sie sicher, dass Ihr Stack bereit ist, damit zu arbeiten. ElastiCache für Redis OSS gibt es keine Möglichkeit, Ihre Bereitschaft zu überprüfen. Weitere Informationen finden Sie unter [Einen Cluster für Valkey oder Redis OSS erstellen](Clusters.Create.md).
1. **Ändern Sie die bestehende CMD-Clusterkonfiguration so, dass sie mit dem Clustermodus kompatibel** ist — In diesem Modus wird ein einziger Shard bereitgestellt, und ElastiCache für Redis funktioniert OSS als einzelner Knoten, aber auch als einzelner Shard-Cluster. Kompatibler Modus bedeutet, dass die Client-Anwendung eines der beiden Protokolle verwenden kann, um mit dem Cluster zu kommunizieren. In diesem Modus müssen Anwendungen neu konfiguriert werden, damit sie das Valkey- oder Redis OSS-Cluster-Protokoll und den Konfigurationsendpunkt verwenden können. Gehen Sie wie folgt vor, um den Valkey- oder Redis OSS-Clustermodus auf Clusterkompatibilität umzustellen:
**Anmerkung**
Im kompatiblen Modus sind andere Änderungsvorgänge, wie Änderung der Skalierung und der Engine-Version, für den Cluster nicht zulässig. Darüber hinaus können Parameter (ausgenommen`cacheParameterGroupName`) nicht geändert werden, wenn der Clustermodus-Parameter in der Anfrage definiert wird. [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
1. **Verwenden Sie den AWS-Managementkonsole, sehen Sie sich den Clustermodus an [Ändern einer Replikationsgruppe](Replication.Modify.md) und setzen Sie ihn auf Compatible**
1. Sehen Sie sich den `ClusterMode` Parameter mithilfe der API an [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)und aktualisieren Sie ihn auf`compatible`.
1. Verwenden Sie den AWS CLI, sehen Sie sich den `cluster-mode` Parameter an [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)und aktualisieren Sie ihn auf`compatible`.
Nach dem Ändern des Valkey- oder Redis OSS-Clustermodus in den Clustermodus kompatibel, gibt die [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API den Endpunkt ElastiCache für die Redis OSS-Clusterkonfiguration zurück. Der Cluster-Konfigurationsendpunkt ist ein einzelner Endpunkt, der von Anwendungen verwendet werden kann, um eine Verbindung mit dem Cluster herzustellen. Weitere Informationen finden Sie unter [Verbindungsendpunkte finden in ElastiCache](Endpoints.md).
1. **Clusterkonfiguration in den aktivierten Clustermodus ändern** – Sobald der Clustermodus auf den kompatiblen Clustermodus eingestellt ist, besteht der zweite Schritt darin, die Clusterkonfiguration so zu ändern, dass der Clustermodus aktiviert ist. In diesem Modus wird ein einzelner Shard ausgeführt und Kunden können jetzt ihre Cluster skalieren oder andere Clusterkonfigurationen ändern.
Gehen Sie wie folgt vor, um den Clustermodus in aktiviert zu ändern:
Bevor Sie beginnen, stellen Sie sicher, dass Ihre Valkey- oder Redis OSS-Clients auf das Cluster-Protokoll umgestellt wurden und dass der Konfigurationsendpunkt des Clusters nicht verwendet wird.
1. **Sehen Sie sich mit dem den AWS-Managementkonsole Clustermodus an [Ändern einer Replikationsgruppe](Replication.Modify.md) und setzen Sie ihn auf Aktiviert.**
1. Sehen Sie sich mithilfe der API den `ClusterMode` Parameter an [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)und aktualisieren Sie ihn auf`enabled`.
1. Verwenden Sie den AWS CLI, sehen Sie sich den `cluster-mode` Parameter an [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)und aktualisieren Sie ihn auf`enabled`.
Nachdem der Clustermodus auf aktiviert geändert wurde, werden die Endpoints gemäß der Valkey- oder Redis OSS-Clusterspezifikation konfiguriert. Die [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API gibt den Clustermodus-Parameter als `enabled` und die Cluster-Endpunkte zurück, die jetzt für Anwendungen zur Verbindung mit dem Cluster verfügbar sind.
Beachten Sie, dass sich die Cluster-Endpunkte ändern, sobald der Clustermodus auf aktiviert geändert wird. Achten Sie darauf, Ihre Anwendungen mit den neuen Endpunkten zu aktualisieren.
Sie können sich auch dafür entscheiden, vom kompatiblen Clustermodus (CMD) zum deaktivierten Clustermodus (CMD) zurückzukehren und die ursprünglichen Konfigurationen beizubehalten.
**Ändern der Clusterkonfiguration vom kompatiblen in den deaktivierten Clustermodus**
1. **Sehen Sie sich den AWS-Managementkonsole Clustermodus mithilfe von an [Ändern einer Replikationsgruppe](Replication.Modify.md) und setzen Sie ihn auf Deaktiviert**
1. Sehen Sie sich den `ClusterMode` Parameter mithilfe der API an [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)und aktualisieren Sie ihn auf`disabled`.
1. Verwenden Sie den AWS CLI, sehen Sie sich den `cluster-mode` Parameter an [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)und aktualisieren Sie ihn auf`disabled`.
Nachdem der Clustermodus auf deaktiviert geändert wurde, gibt die [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API den Clustermodus-Parameter als zurück`disabled`.
# AWS Regionsübergreifende Replikation mithilfe globaler Datenspeicher
**Anmerkung**
Global Datastore ist derzeit nur für knotenbasierte Cluster verfügbar.
Mithilfe der Global Datastore-Funktion können Sie mit einer vollständig verwalteten, schnellen, zuverlässigen und sicheren Valkey- oder Redis OSS-Clusterreplikation über Regionen hinweg arbeiten.AWS Mit dieser Funktion können Sie regionsübergreifende Read Replica-Cluster erstellen, um Lesevorgänge mit geringer Latenz und regionsübergreifende Disaster Recovery zu ermöglichen.AWS
In den folgenden Abschnitten finden Sie eine Beschreibung der Arbeit mit globalen Datenspeichern.
**Topics**
+ [-Übersicht](#Redis-Global-Data-Stores-Overview)
+ [Voraussetzungen und Einschränkungen](Redis-Global-Datastores-Getting-Started.md)
+ [Verwendung globaler Datenspeicher (Konsole)](Redis-Global-Datastores-Console.md)
+ [Verwenden globaler Datenspeicher (CLI)](Redis-Global-Datastores-CLI.md)
## -Übersicht
Jeder *globale Datenspeicher* ist eine Sammlung von einem oder mehreren Clustern, die zueinander repliziert werden.
Ein globaler Datenspeicher besteht aus folgenden Komponenten:
+ **Primärer (aktiver) Cluster** – Ein primärer Cluster nimmt Schreibvorgänge entgegen, die auf alle Cluster innerhalb des globalen Datenspeichers repliziert werden. Ein primärer Cluster akzeptiert auch Leseanfragen.
+ **Sekundärer (passiver) Cluster** – Ein sekundärer Cluster nimmt nur Leseanforderungen entgegen und repliziert Datenaktualisierungen von einem primären Cluster. Ein sekundärer Cluster muss sich in einer anderen AWS Region befinden als der primäre Cluster.
Wenn Sie einen globalen Datenspeicher ElastiCache für Valkey oder Redis OSS erstellen, repliziert dieser Ihre Daten automatisch vom primären Cluster auf den sekundären Cluster. Sie wählen die AWS Region aus, in der die Valkey- oder Redis OSS-Daten repliziert werden sollen, und erstellen dann einen sekundären Cluster in dieser Region.AWS ElastiCache richtet dann die automatische, asynchrone Replikation von Daten zwischen den beiden Clustern ein und verwaltet sie.
Die Verwendung eines globalen Datenspeichers für Valkey oder Redis OSS bietet die folgenden Vorteile:
+ **Geolokale Leistung** — Indem Sie Remote-Replikat-Cluster in zusätzlichen AWS Regionen einrichten und Ihre Daten zwischen diesen Regionen synchronisieren, können Sie die Latenz beim Datenzugriff in dieser Region reduzieren.AWS Ein globaler Datenspeicher kann dazu beitragen, die Reaktionsfähigkeit Ihrer Anwendung zu erhöhen, indem er geolokale Lesevorgänge mit niedriger Latenz in allen Regionen bereitstellt.AWS
+ **Notfallwiederherstellung** – Wenn Ihr primärer Cluster in einem globalen Datenspeicher eine Verschlechterung aufweist, können Sie einen sekundären Cluster als Ihren neuen primären Cluster heraufstufen. Sie können dies tun, indem Sie eine Verbindung zu einer beliebigen Region herstellen, die einen sekundären Cluster enthält AWS.
Das folgende Diagramm zeigt, wie globale Datenspeicher funktionieren können.
![\[globaler Datenspeicher\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/Global-DataStore.png)
# Voraussetzungen und Einschränkungen
Bevor Sie die Arbeit mit globalen Datenspeichern beginnen, beachten Sie Folgendes:
+ Globale Datenspeicher werden in den folgenden AWS Regionen unterstützt:
+ **Afrika** — Kapstadt
+ **Asien-Pazifik** — Hongkong, Hyderabad, Jakarta, Malaysia, Melbourne, Mumbai, Osaka, Seoul, Singapur, Sydney, Thailand und Tokio
+ **Kanada** — Kanada Zentral und Kanada West (Calgary)
+ **China** - Peking und Ningxia
+ **Europa** — Frankfurt, London, Irland, Mailand, Paris, Spanien, Stockholm und Zürich
+ **AWS GovCloud**-US-West und US-Ost
+ **Israel** - Tel Aviv
+ **Naher Osten** — Bahrain und Vereinigte Arabische Emirate
+ **USA** — Ost (Nord-Virginia und Ohio) und USA West (Nordkalifornien und Oregon)
+ **Südamerika** — Mexiko (Zentral) und São Paulo
+ Alle Cluster – primär und sekundär – in Ihrem globalen Datenspeicher sollten die gleiche Anzahl von primären Knoten, Knotentyp, Engine-Version und Anzahl von Shards (bei aktiviertem Cluster-Modus) aufweisen. Jeder Cluster in Ihrem globalen Datenspeicher kann über eine andere Anzahl von Read Replicas verfügen, um mit dem lokalen Lesedatenverkehr in diesem Cluster umgehen zu können.
Die Replikation muss aktiviert sein, wenn Sie einen vorhandenen Cluster mit einem einzelnen Knoten verwenden möchten.
+ Globale Datenspeicher werden auf Instances mit einer Größe von mindestens einer Größe unterstützt.
+ Sie können die Replikation für einen primären Cluster von einer AWS Region zu einem sekundären Cluster in bis zu zwei anderen AWS Regionen einrichten.
**Anmerkung**
Eine Ausnahme sind die Regionen China (Peking) und China (Ningxia), wo eine Replikation nur zwischen den beiden Regionen erfolgen kann.
+ Mit globalen Datenspeichern können Sie nur in VPC-Clustern arbeiten. Weitere Informationen finden Sie unter [Zugriffsmuster für den Zugriff auf einen ElastiCache Cache in einer Amazon VPC](elasticache-vpc-accessing.md). Globale Datenspeicher werden nicht unterstützt, wenn Sie -Classic verwenden EC2. Weitere Informationen finden Sie unter [EC2-Classic](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-classic-platform.html) im * EC2 Amazon-Benutzerhandbuch*.
**Anmerkung**
Derzeit können Sie keine globalen Datenspeicher in [Verwenden von lokalen Zonen mit ElastiCache](Local_zones.md) verwenden.
+ ElastiCache unterstützt kein automatisches Failover von einer AWS Region in eine andere. Bei Bedarf können Sie einen sekundären Cluster manuell heraufstufen. Ein Beispiel finden Sie unter [Heraufstufen des sekundären Clusters zum primären Cluster](Redis-Global-Datastores-Console.md#Redis-Global-Datastores-Console-Promote-Secondary).
+ Um eine Bootstrap-Aktion von vorhandenen Daten durchzuführen, verwenden Sie einen vorhandenen Cluster als primären Cluster, um einen globalen Datenspeicher zu erstellen. Das Hinzufügen eines vorhandenen Clusters als sekundärer Cluster wird nicht unterstützt. Beim Hinzufügen des Clusters als sekundärer Cluster werden Daten gelöscht, was zu Datenverlusten führen kann.
+ Parameteraktualisierungen werden auf alle Cluster angewendet, wenn Sie eine lokale Parametergruppe eines Clusters ändern, der zu einem globalen Datenspeicher gehört.
+ Sie können regionale Cluster sowohl vertikal (Skalierung nach oben und unten) als auch horizontal (Ein- und Ausskalierung) skalieren. Sie können die Cluster skalieren, indem Sie den globalen Datenspeicher ändern. Alle regionalen Cluster in dem globalen Datenspeicher werden dann ohne Unterbrechung skaliert. Weitere Informationen finden Sie unter [Skalierung ElastiCache](Scaling.md).
+ [Globale Datenspeicher unterstützen [Verschlüsselung im Ruhezustand, Verschlüsselung bei der](at-rest-encryption.md)[Übertragung](in-transit-encryption.md) und AUTH.](auth.md)
+ Globale Datenspeicher unterstützen das Internetprotokoll Version 6 () nicht. IPv6
+ Globale Datenspeicher unterstützen Schlüssel. AWS KMS Weitere Informationen finden Sie unter [AWS Schlüsselverwaltungsdienstkonzepte](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys) im *AWS Key Management Service Entwicklerhandbuch.*
**Anmerkung**
Globale Datenspeicher unterstützen [Pub/Sub-Messaging](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/elasticache-use-cases.html#elasticache-for-redis-use-cases-messaging) mit den folgenden Vorgaben:
Für den Cluster-Modus deaktiviert, pub/sub wird vollständig unterstützt. Ereignisse, die auf dem primären Cluster der primären AWS Region veröffentlicht wurden, werden an sekundäre Regionen weitergegeben. AWS
Bei aktiviertem Cluster-Modus gilt Folgendes:
Bei veröffentlichten Ereignissen, die sich nicht in einem Schlüsselraum befinden, erhalten nur Abonnenten in derselben AWS Region die Ereignisse.
Bei veröffentlichten Keyspace-Veranstaltungen erhalten Abonnenten in allen AWS Regionen die Ereignisse.
# Verwendung globaler Datenspeicher (Konsole)
Führen Sie den folgenden aus zwei Schritten bestehenden Vorgang durch, um einen globalen Datenspeicher mit der Konsole zu erstellen:
1. Erstellen Sie einen primären Cluster, entweder mithilfe eines vorhandenen Clusters oder durch Erstellen eines neuen Clusters. Die Engine muss Valkey 7.2 oder höher oder Redis OSS 5.0.6 oder höher sein.
1. Fügen Sie bis zu zwei sekundäre Cluster in verschiedenen AWS Regionen hinzu, wiederum mit Valkey 7.2 oder höher oder Redis OSS 5.0.6 oder höher.
In den folgenden Verfahren erfahren Sie, wie Sie einen globalen Datenspeicher für Valkey oder Redis OSS erstellen und andere Vorgänge mithilfe der Konsole ausführen. ElastiCache
**Topics**
+ [Erstellen eines globalen Datenspeichers mit einem vorhandenen Cluster](#Redis-Global-Datastores-Console-Create-Primary)
+ [Erstellen eines neuen globalen Datenspeichers mit einem neuen primären Cluster](#Redis-Global-Datastores-Create-From-Scratch)
+ [Anzeigen von Details zu einem globalen Datenspeicher](#Redis-Global-Datastores-Console-Details)
+ [Hinzufügen einer Region zu einem globalen Datenspeicher](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Ändern eines globalen Datenspeichers](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
+ [Heraufstufen des sekundären Clusters zum primären Cluster](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Entfernen einer Region aus einem globalen Datenspeicher](#Redis-Global-Datastore-Console-Remove-Region)
+ [Löschen eines globalen Datenspeichers](#Redis-Global-Datastores-Console-Delete-GlobalDatastore)
## Erstellen eines globalen Datenspeichers mit einem vorhandenen Cluster
In diesem Szenario verwenden Sie einen vorhandenen Cluster, der als primärer Cluster des neuen globalen Datenspeichers dient. Anschließend erstellen Sie einen sekundären, schreibgeschützten Cluster in einer separaten AWS -Region. Dieser sekundäre Cluster erhält automatische und asynchrone Updates vom primären Cluster.
**Wichtig**
Der vorhandene Cluster muss eine Engine verwenden, die Valkey 7.2 oder höher oder Redis OSS 5.0.6 oder höher ist.
**So erstellen Sie einen globalen Datenspeicher unter Verwendung eines vorhandenen Clusters:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Global Datastores** und dann **Create Global** Datastore aus.
1. Gehen Sie auf der Seite mit den **Einstellungen für den primären Cluster** wie folgt vor:
+ Geben Sie im Feld **Informationen zum globalen Datenspeicher** einen Namen für den neuen globalen Datenspeicher ein.
+ (Optional) Geben Sie einen Wert für **Description (Beschreibung)** ein.
1. Wählen Sie unter **Regionaler Cluster** die Option Bestehenden regionalen Cluster **verwenden** aus.
1. Wählen Sie unter **Existierender** Cluster den vorhandenen Cluster aus, den Sie verwenden möchten.
1. Behalten Sie die folgenden Optionen unverändert bei. Sie sind so vorausgefüllt, dass sie der primären Clusterkonfiguration entsprechen. Sie können sie nicht ändern.
+ Engine-Version
+ Knotentyp
+ Parametergruppe
**Anmerkung**
ElastiCache generiert automatisch eine neue Parametergruppe aus Werten der angegebenen Parametergruppe und wendet die neue Parametergruppe auf den Cluster an. Verwenden Sie diese neue Parametergruppe, um Parameter in einem globalen Datenspeicher zu ändern. Jede automatisch generierte Parametergruppe ist einem Cluster und daher nur einem globalen Datenspeicher zugeordnet.
+ Anzahl der Shards
+ Verschlüsselung im Ruhezustand – Aktiviert die Verschlüsselung von Daten, die auf der Festplatte gespeichert sind. Weitere Informationen finden Sie unter [Verschlüsselung im Ruhezustand](at-rest-encryption.md).
**Anmerkung**
Sie können einen anderen Verschlüsselungsschlüssel angeben, indem Sie **Customer Managed AWS KMS key** und dann den Schlüssel auswählen. Weitere Informationen finden Sie unter [Verwenden von vom Kunden verwalteten AWS KMS-Schlüsseln](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ Verschlüsselung während der Übertragung – Aktiviert die Verschlüsselung von Daten bei der Übertragung. Weitere Informationen finden Sie unter [Verschlüsselung während der Übertragung](in-transit-encryption.md). Wenn Sie für Valkey 7.2 und höher und ab Redis OSS 6.0 die Verschlüsselung während der Übertragung aktivieren, werden Sie aufgefordert, eine der folgenden **Zugriffskontrolloptionen** anzugeben:
+ **Keine Zugriffskontrolle** – Dies ist die Standardeinstellung. Dies weist auf keine Einschränkungen hin.
+ **Zugriffskontrollliste für Benutzergruppen** – Wählen Sie eine Benutzergruppe mit einem definierten Satz von Benutzern und Berechtigungen für verfügbare Vorgänge aus. Weitere Informationen finden Sie unter [Verwalten von Benutzergruppen mit der Konsole und dem CLI](Clusters.RBAC.md#User-Groups).
+ **AUTH Default User** — Ein Authentifizierungsmechanismus für einen Valkey- oder Redis OSS-Server. [Weitere Informationen finden Sie unter AUTH.](auth.md)
1. (Optional) Aktualisieren Sie bei Bedarf die verbleibenden Einstellungen für den sekundären Cluster. Diese werden mit den gleichen Werten wie beim primären Cluster vorausgefüllt, Sie können sie jedoch aktualisieren, um bestimmte Anforderungen für diesen Cluster zu erfüllen.
+ Port
+ Anzahl der Replikate
+ Subnetzgruppe
+ Bevorzugte Availability Zone(s)
+ Sicherheitsgruppen
+ Vom Kunden verwaltet (AWS KMS-Schlüssel)
+ AUTH-Token
+ Aktivieren automatischer Sicherungen.
+ Aufbewahrungszeitraum für Backups
+ Backup-Fenster
+ Wartungsfenster
+ Thema für SNS-Benachrichtigung
1. Wählen Sie **Erstellen** aus. Dadurch wird der Status des globalen Datenspeichers auf **Creating (Erstellen)** festgelegt. Der Status wechselt zu **Modifying (Ändern)**, nachdem der primäre Cluster dem globalen Datenspeicher zugeordnet wurde und der sekundäre Cluster den Status **Associating (Zuordnen)** hat.
Nachdem der primäre Cluster und die sekundären Cluster mit dem globalen Datenspeicher verknüpft wurden, ändert sich der Status zu **Available (Verfügbar)**. An dieser Stelle verfügen Sie über einen primären Cluster, der Lese- und Schreibvorgänge akzeptiert, sowie sekundäre Cluster, die vom primären Cluster replizierte Lesevorgänge akzeptieren.
Die Seite wird aktualisiert und gibt nun an, ob ein Cluster Teil eines globalen Datenspeichers ist. Dazu gehören:
+ **Globaler Datenspeicher** – Der Name des globalen Datenspeichers, zu dem der Cluster gehört.
+ **Globale Datenspeicherrolle** – Die Rolle des Clusters, entweder primär oder sekundär.
Sie können bis zu einem zusätzlichen sekundären Cluster in einer anderen AWS Region hinzufügen. Weitere Informationen finden Sie unter [Hinzufügen einer Region zu einem globalen Datenspeicher](#Redis-Global-Datastores-Console-Create-Secondary).
## Erstellen eines neuen globalen Datenspeichers mit einem neuen primären Cluster
Wenn Sie einen globalen Datenspeicher mit einem neuen Cluster erstellen möchten, gehen Sie folgendermaßen vor.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Global Datastores** und dann **Create Global** Datastore aus.
1. Führen Sie unter **Primary cluster settings** (Primäre Cluster-Einstellungen) die folgenden Schritte aus:
1. Wählen Sie für **Cluster mode** (Cluster-Modus) **Enabled** (Aktiviert) oder **Disabled** (Deaktiviert) aus.
1. **Geben Sie für **Informationen zum globalen Datenspeicher** einen Wert für Name ein.** ElastiCache verwendet das Suffix, um einen eindeutigen Namen für den globalen Datenspeicher zu generieren. Sie können nach dem globalen Datenspeicher suchen, indem Sie das hier angegebene Suffix verwenden.
1. (Optional) Geben Sie einen Wert für die **Global Datastore description (Beschreibung des globalen Datenspeichers)** ein.
1. Unter **Regional luster** (Regionaler Cluster):
1. Wählen Sie für **Region** eine verfügbare Region aus. AWS
1. Wählen Sie **Create new regional cluster** (Neuen regionalen Cluster erstellen) oder **Use existing regional cluster** (Bestehenden regionalen Cluster verwenden) aus.
1. Wenn Sie **Create new regional cluster** (Neuen regionalen Cluster erstellen), auswählen, geben Sie unter **Cluster infos** (Cluster-Infos) einen Namen und eine optionale Beschreibung des Clusters ein.
1. Wir empfehlen, unter **Location** (Speicherort) die Voreinstellungen für **Multi-AZ** und **Auto-failover** (Automatisches Failover) zu akzeptieren.
1. Unter **Cluster settings** (Cluster-Einstellungen):
1. Wählen Sie für **Engine version** (Engine-Version) eine verfügbare Version (5.0.6 oder höher).
1. Verwenden Sie für **Port** den Standardport 6379. Wenn es einen Grund gibt, einen anderen Port zu verwenden, geben Sie die betreffende Portnummer ein.
1. Wählen Sie für die **Parameter group (Parametergruppe)** eine Parametergruppe aus oder erstellen Sie eine neue Parametergruppe. Parametergruppen steuern die Laufzeitparameter Ihres Clusters. Weitere Informationen zu Parametergruppen finden Sie unter [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis) und [Eine ElastiCache Parametergruppe erstellen](ParameterGroups.Creating.md).
**Anmerkung**
Wenn Sie eine Parametergruppe zum Festlegen der Engine-Konfigurationswerte auswählen, wird diese Parametergruppe auf alle Cluster im globalen Datenspeicher angewendet. Auf der Seite **Parameter Groups (Parametergruppen)** gibt das Ja/nein-Attribut **Global** an, ob eine Parteigruppe Teil eines globalen Datenspeichers ist.
1. Klicken Sie für **Node type (Knotentyp)** auf den Abwärtspfeil (![\[Downward-pointing triangle icon, typically used to indicate a dropdown menu.\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCache-DnArrow.png)). Wählen Sie im Dialogfeld **Change node type (Knotentyp ändern)** einen Wert für **Instance family (Instance-Familie)** für den gewünschten Knotentyp aus. Wählen Sie dann den Knotentyp aus, den Sie für diesen Cluster verwenden möchten, und wählen Sie dann **Save (Speichern)**.
Weitere Informationen finden Sie unter [Auswahl der Knotengröße](CacheNodes.SelectSize.md).
Wenn Sie einen r6gd-Knotentyp wählen, wird Daten-Tiering automatisch aktiviert. Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
1. Wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) erstellen:
Wählen Sie unter **Number of replicas** (Anzahl der Replikate) die für diesen Cluster gewünschte Anzahl von Replikaten aus.
1. Wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) erstellen:
1. Wählen Sie unter **Anzahl der Shards** die Anzahl der Shards (Partitionen/Knotengruppen) aus, die Sie für diesen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) benötigen.
Bei einigen Versionen von Valkey oder Redis OSS (Clustermodus aktiviert) können Sie die Anzahl der Shards in Ihrem Cluster dynamisch ändern:
+ **Redis OSS 3.2.10 und höher** — Wenn auf Ihrem Cluster Redis OSS 3.2.10 oder spätere Versionen ausgeführt werden, können Sie die Anzahl der Shards in Ihrem Cluster dynamisch ändern. Weitere Informationen finden Sie unter [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md).
+ **Andere Redis OSS-Versionen** — Wenn auf Ihrem Cluster eine Version von Redis OSS vor Version 3.2.10 ausgeführt wird, gibt es einen anderen Ansatz. Um die Anzahl der Shards in Ihrem Cluster in diesem Fall zu ändern, erstellen Sie einen neuen Cluster mit der neuen Anzahl von Shards. Weitere Informationen finden Sie unter [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md).
1. Wählen Sie für **Replicas per shard (Replikate pro Shard)** die Anzahl der Read Replica-Knoten aus, die sich in jedem Shard befinden sollen.
Die folgenden Einschränkungen gelten für Valkey oder Redis OSS (Clustermodus aktiviert).
+ Wenn Sie Multi-AZ aktiviert haben, stellen Sie sicher, dass mindestens ein Replikat pro Shard vorhanden ist.
+ Die Anzahl der Replikate ist für jeden Shard gleich, wenn der Cluster mithilfe der Konsole erstellt wird.
+ Die Anzahl der Lesereplikate pro Shard ist ein fester Wert, der nicht geändert werden kann. Wenn Sie feststellen, dass Sie mehr oder weniger Replikate pro Shard (API/CLI: Knotengruppe) benötigen, müssen Sie einen neuen Cluster mit der neuen Anzahl von Replikaten erstellen. Weitere Informationen finden Sie unter [Tutorial: Seeding eines neuen knotenbasierten Clusters mit einem extern erstellten Backup](backups-seeding-redis.md).
1. Wählen Sie **unter Einstellungen für Subnetzgruppen** das Subnetz aus, das Sie auf diesen Cluster anwenden möchten. ElastiCache stellt eine IPv4 Standard-Subnetzgruppe bereit, oder Sie können wählen, ob Sie eine neue erstellen möchten. Denn IPv6 Sie müssen eine Subnetzgruppe mit einem IPv6 CIDR-Block erstellen. Wenn Sie sich für **Dual-Stack** entscheiden, müssen Sie anschließend einen Discovery-IP-Typ auswählen, entweder oder IPv6 . IPv4
Weitere Informationen finden Sie unter [Erstellen eines Subnetzes in Ihrer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet).
1. Für **Availability zone placements** (Availability-Zone-Platzierungen) haben Sie zwei Optionen:
+ **Keine Präferenz** — ElastiCache wählt die Availability Zone.
+ **Availability Zones** angeben – Sie geben die Availability Zone für jeden Cluster an.
Wenn Sie die Availability Zones angeben, wählen Sie für jeden Cluster in jedem Shard die Availability Zone aus der Liste aus.
Weitere Informationen finden Sie unter [Auswahl von Regionen und Verfügbarkeitszonen für ElastiCache](RegionsAndAZs.md).
![\[Abbildung: Angeben von Keyspaces und Availability Zones\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCache-ClusterOn-Slots-AZs.png)
*Angeben von Keyspaces und Availability Zones*
1. Wählen Sie **Next** (Weiter).
1. Unter **Advanced Valkey und Redis OSS-Einstellungen**
1. Für **Security** (Sicherheit):
1. Zur Verschlüsselung Ihrer Daten haben Sie die folgenden Optionen:
+ **Verschlüsselung im Ruhezustand** – Ermöglicht die Verschlüsselung von Daten, die auf der Festplatte gespeichert sind. Weitere Informationen finden Sie unter [Verschlüsselung im Ruhezustand](at-rest-encryption.md).
**Anmerkung**
Sie haben die Möglichkeit, einen anderen Verschlüsselungsschlüssel anzugeben, indem Sie **Customer Managed AWS KMS Key** und dann den Schlüssel auswählen. Weitere Informationen finden Sie unter [Verwendung von kundenverwalteten Schlüsseln aus AWS -KMS](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ **Verschlüsselung während der Übertragung** – Ermöglicht die Verschlüsselung von Daten während der Übertragung. Weitere Informationen finden Sie unter [Verschlüsselung während der Übertragung](in-transit-encryption.md). Wenn Sie für Valkey 7.2 und höher und Redis OSS 6.0 und höher die Verschlüsselung während der Übertragung aktivieren, werden Sie aufgefordert, eine der folgenden **Zugriffskontrolloptionen** anzugeben:
+ **Keine Zugriffskontrolle** – Dies ist die Standardeinstellung. Dies bedeutet, dass es keine Einschränkungen für den Benutzerzugang zum Cluster gibt.
+ **Zugriffskontrollliste für Benutzergruppen** – Wählen Sie eine Benutzergruppe mit einer bestimmten Anzahl von Benutzern aus, die auf den Cluster zugreifen können. Weitere Informationen finden Sie unter [Verwalten von Benutzergruppen mit der Konsole und dem CLI](Clusters.RBAC.md#User-Groups).
+ **AUTH Default User** — Ein Authentifizierungsmechanismus für einen Valkey- oder Redis OSS-Server. [Weitere Informationen finden Sie unter AUTH.](auth.md)
+ **AUTH** — Ein Authentifizierungsmechanismus für einen Valkey- oder Redis OSS-Server. [Weitere Informationen finden Sie unter AUTH.](auth.md)
**Anmerkung**
Für Redis OSS-Versionen zwischen 3.2.6 und höher, mit Ausnahme von Version 3.2.10, ist AUTH die einzige Option.
1. Wählen Sie für **Security groups (Sicherheitsgruppen)** die gewünschten Sicherheitsgruppen für diesen Cluster aus. Eine *security group (Sicherheitsgruppe)* fungiert als Firewall, um den Netzwerkzugriff auf Ihren Cluster zu steuern. Sie können die Standardsicherheitsgruppe für Ihre VPC verwenden oder eine neue erstellen.
Weitere Informationen zu Sicherheitsgruppen finden Sie unter [Sicherheitsgruppen für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) im *Benutzerhandbuch zu Amazon VPC.*
1. Wenn Sie regelmäßig geplante automatische Sicherungen möchten, aktivieren Sie **Enable automatic backups** und geben Sie ein, wie viele Tage lang jede automatische Sicherung beibehalten werden soll, bevor sie automatisch gelöscht wird. Wenn Sie keine regelmäßig geplanten automatischen Sicherungen möchten, deaktivieren Sie das Kontrollkästchen **Enable automatic backups**. In beiden Fällen haben Sie jederzeit die Option, manuelle Sicherungen zu erstellen.
Weitere Informationen zur Sicherung und Wiederherstellung finden Sie unter. [Snapshot und Wiederherstellung](backups.md)
1. (Optional) Geben Sie ein Wartungsfenster an. Das *Maintenance window (Wartungsfenster)* ist der (in der Regel eine Stunde lange) allwöchentliche Zeitraum, für den ElastiCache die Systemwartung Ihres Clusters plant. Sie können ElastiCache den Tag und die Uhrzeit für Ihr Wartungsfenster wählen (*keine Präferenz*), oder Sie können Tag, Uhrzeit und Dauer selbst wählen (*Wartungsfenster angeben*). Treffen Sie bei Wahl von *Specify maintenance window* eine Auswahl in den Listen *Start day*, *Start time* und *Duration* (in Stunden) für Ihr Wartungsfenster. Alle Uhrzeiten sind in UCT angegeben.
Weitere Informationen finden Sie unter [Verwaltung der ElastiCache Cluster-Wartung](maintenance-window.md).
1. (Optional) Für **Protokolle**:
+ Unter **Protokollformat** wählen Sie entweder**Text** oder **JSON** aus.
+ Wählen Sie unter **Zieltyp** entweder **CloudWatch Logs** oder **Kinesis Firehose** aus.
+ Wählen Sie unter **Protokollziel** entweder **Neu erstellen** aus und geben Sie entweder Ihren CloudWatch Logs-Log-Gruppennamen oder Ihren Firehose-Stream-Namen ein, oder wählen **Sie Bestehende auswählen** und wählen Sie dann entweder Ihren CloudWatch Logs-Log-Gruppennamen oder Ihren Firehose-Streamnamen aus.
1. Um Ihnen bei der Verwaltung Ihrer Cluster und anderer ElastiCache Ressourcen unter **Tags** zu helfen, können Sie jeder Ressource Ihre eigenen Metadaten in Form von Tags zuweisen. Weitere Information finden Sie unter [Verschlagworten Sie Ihre Ressourcen ElastiCache](Tagging-Resources.md).
1. Überprüfen Sie alle Ihre Einträge und ausgewählten Optionen und machen Sie dann evtl. erforderliche Korrekturen. Wählen Sie danach **Next (Weiter)** aus.
1. Nachdem Sie den Cluster in den vorherigen Schritten konfiguriert haben, konfigurieren Sie nun die Details des sekundären Clusters.
1. Wählen Sie unter **Regionaler Cluster** die AWS Region aus, in der sich der Cluster befindet.
1. Geben Sie unter **Cluster info** (Cluster-Info) einen Namen und eine optionale Beschreibung des Clusters ein.
1. Die folgenden Optionen sind für die Konfiguration des primären Clusters vorausgefüllt und können nicht geändert werden:
+ Ort
+ Engine-Version
+ Instance-Typ
+ Knotentyp
+ Anzahl der Shards
+ Parametergruppe
**Anmerkung**
ElastiCache generiert automatisch eine neue Parametergruppe aus Werten der angegebenen Parametergruppe und wendet die neue Parametergruppe auf den Cluster an. Verwenden Sie diese neue Parametergruppe, um Parameter in einem globalen Datenspeicher zu ändern. Jede automatisch generierte Parametergruppe ist einem Cluster und daher nur einem globalen Datenspeicher zugeordnet.
+ Verschlüsselung im Ruhezustand – Aktiviert die Verschlüsselung von Daten, die auf der Festplatte gespeichert sind. Weitere Informationen finden Sie unter [Verschlüsselung im Ruhezustand](at-rest-encryption.md).
**Anmerkung**
Sie können einen anderen Verschlüsselungsschlüssel angeben, indem Sie **Customer Managed AWS KMS key** und dann den Schlüssel auswählen. Weitere Informationen finden Sie unter [Verwenden von vom Kunden verwalteten AWS KMS-Schlüsseln](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ Verschlüsselung während der Übertragung – Aktiviert die Verschlüsselung von Daten bei der Übertragung. Weitere Informationen finden Sie unter [Verschlüsselung während der Übertragung](in-transit-encryption.md). Wenn Sie für Valkey 7.2 und höher und Redis OSS 6.4 und höher die Verschlüsselung während der Übertragung aktivieren, werden Sie aufgefordert, eine der folgenden **Zugriffskontrolloptionen** anzugeben:
+ **Keine Zugriffskontrolle** – Dies ist die Standardeinstellung. Dies bedeutet, dass es keine Einschränkungen für den Benutzerzugang zum Cluster gibt.
+ **Zugriffskontrollliste für Benutzergruppen** – Wählen Sie eine Benutzergruppe mit einer bestimmten Anzahl von Benutzern, die auf den Cluster zugreifen können. Weitere Informationen finden Sie unter [Verwalten von Benutzergruppen mit der Konsole und dem CLI](Clusters.RBAC.md#User-Groups).
+ **AUTH Default User** — Ein Authentifizierungsmechanismus für einen Valkey- oder Redis OSS-Server. [Weitere Informationen finden Sie unter AUTH.](auth.md)
**Anmerkung**
Für Redis OSS-Versionen zwischen 4.0.2, als Verschlüsselung bei der Übertragung erstmals unterstützt wurde, und 6.0.4 ist AUTH die einzige Option.
Die verbleibenden Einstellungen für den sekundären Cluster werden mit den gleichen Werten wie der primäre Cluster ausgefüllt, aber Folgendes kann aktualisiert werden, um bestimmte Anforderungen für diesen Cluster zu erfüllen.
+ Port
+ Anzahl der Replikate
+ Subnetzgruppe
+ Bevorzugte Availability Zone(s)
+ Sicherheitsgruppen
+ Vom Kunden verwaltet (KMS-Schlüssel)AWS
+ AUTH-Token
+ Aktivieren automatischer Sicherungen.
+ Aufbewahrungszeitraum für Backups
+ Backup-Fenster
+ Wartungsfenster
+ Thema für SNS-Benachrichtigung
1. Wählen Sie **Erstellen** aus. Dadurch wird der Status des globalen Datenspeichers auf **Creating (Erstellen**) gesetzt. Nachdem der primäre Cluster und die sekundären Cluster mit dem globalen Datenspeicher verknüpft wurden, ändert sich der Status zu **Available (Verfügbar)**. Sie verfügen über einen primären Cluster, der Lese- und Schreibvorgänge akzeptiert, und einen sekundären Cluster, der Lesevorgänge akzeptiert, die vom primären Cluster repliziert werden.
Die Seite wird außerdem aktualisiert, um anzugeben, ob ein Cluster Teil eines globalen Datenspeichers ist, einschließlich der folgenden Informationen:
+ **Globaler Datenspeicher** – Der Name des globalen Datenspeichers, zu dem der Cluster gehört.
+ **Globale Datenspeicherrolle** – Die Rolle des Clusters, entweder primär oder sekundär.
Sie können bis zu einem zusätzlichen sekundären Cluster in einer anderen AWS Region hinzufügen. Weitere Informationen finden Sie unter [Hinzufügen einer Region zu einem globalen Datenspeicher](#Redis-Global-Datastores-Console-Create-Secondary).
## Anzeigen von Details zu einem globalen Datenspeicher
Sie können die Details vorhandener globaler Datenspeicher anzeigen und sie auch auf der Seite **Globale Datenspeicher** ändern.
**So zeigen Sie Details zu einem globalen Datenspeicher an:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Konsole unter. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Globale Datenspeicher** und dann einen verfügbaren globalen Datenspeicher aus.
Anschließend können Sie die folgenden Eigenschaften des globalen Datenspeichers untersuchen:
+ **Global Datastore Name (Name des globalen Datenspeichers):** Der Name des globalen Datenspeichers
+ **Description (Beschreibung):** Eine Beschreibung des globalen Datenspeichers
+ **Status:** Folgende Optionen stehen zur Verfügung:
+ Erstellen
+ Ändern
+ Verfügbar
+ Löschen
+ Nur Primär - Dieser Status gibt an, dass der globale Datenspeicher nur einen primären Cluster enthält. Entweder wurden alle sekundären Cluster gelöscht oder nicht erfolgreich erstellt.
+ **Cluster Mode (Cluster-Modus):** Aktiviert oder deaktiviert.
+ **Engine-Version:** Die Valkey- oder Redis OSS-Engine-Version, auf der der globale Datenspeicher ausgeführt wird
+ **Instance Node Type (Instance-Knotentyp):** Der für den globalen Datenspeicher verwendete Knotentyp
+ **Encryption at-rest (Verschlüsselung im Ruhezustand):** Aktiviert oder deaktiviert
+ **Encryption in-transit (Verschlüsselung während der Übertragung):** Aktiviert oder deaktiviert
+ **AUTH**: Entweder aktiviert oder deaktiviert
Sie können die folgenden Änderungen an dem globalen Datenspeicher vornehmen:
+ [Hinzufügen einer Region zu einem globalen Datenspeicher](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Entfernen einer Region aus einem globalen Datenspeicher](#Redis-Global-Datastore-Console-Remove-Region)
+ [Heraufstufen des sekundären Clusters zum primären Cluster](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Ändern eines globalen Datenspeichers](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
Auf der Seite „Global Datastore (Globaler Datenspeicher)“ werden auch die einzelnen Cluster aufgelistet, aus denen der globale Datenspeicher besteht, sowie die folgenden Eigenschaften für jeden davon:
+ **Region** — Die AWS Region, in der der Cluster gespeichert ist
+ **Role (Rolle)** - Entweder primär oder sekundär
+ **Cluster name (Cluster-Name)** - Der Name des Clusters
+ **Status** - Zu den Optionen gehören:
+ **Associating (Zuordnen)** - Der Cluster wird gerade dem globalen Datenspeicher zugeordnet
+ **Associated (Zugeordnet)** - Der Cluster ist dem globalen Datenspeicher zugeordnet
+ **Disassociating (Trennen)** - Der Vorgang des Entfernens eines sekundären Clusters aus dem globalen Datenspeicher unter Verwendung des Namens des globalen Datenspeichers. Danach erhält der sekundäre Cluster keine Updates mehr vom primären Cluster, sondern er verbleibt als eigenständiger Cluster in dieser AWS Region.
+ **Disassociated (Getrennt)** - Der sekundäre Cluster wurde aus dem globalen Datenspeicher entfernt und ist jetzt ein eigenständiger Cluster in seiner AWS -Region.
+ **Global Datastore Replica Lag** — Zeigt einen Wert pro sekundärer AWS Region im globalen Datenspeicher an. Dies ist die Verzögerung zwischen dem Primärknoten der sekundären Region und dem Primärknoten der primären Region. Bei aktiviertem Valkey oder Redis OSS im Clustermodus gibt die Verzögerung die maximale Verzögerung in Sekunden zwischen den Shards an.
## Hinzufügen einer Region zu einem globalen Datenspeicher
Sie können einem vorhandenen globalen Datenspeicher bis zu eine zusätzliche AWS Region hinzufügen. In diesem Szenario erstellen Sie einen schreibgeschützten Cluster in einer separaten AWS Region, der automatische und asynchrone Updates vom primären Cluster empfängt.
**Um eine AWS Region zu einem globalen Datenspeicher hinzuzufügen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Globale Datenspeicher** und dann einen vorhandenen globalen Datenspeicher aus.
1. Wählen Sie **Regionalen Cluster hinzufügen** und wählen Sie die AWS Region aus, in der sich der sekundäre Cluster befinden soll.
1. Geben Sie unter **Clusterinformationen** einen Wert für **Name** und optional für **Beschreibung** für den Cluster ein.
1. Behalten Sie die folgenden Optionen unverändert bei. Sie sind bereits so ausgefüllt, dass sie der primären Clusterkonfiguration entsprechen, und Sie können sie nicht ändern.
+ Engine-Version
+ Instance-Typ
+ Knotentyp
+ Anzahl der Shards
+ Parametergruppe
**Anmerkung**
ElastiCache generiert automatisch eine neue Parametergruppe aus Werten der angegebenen Parametergruppe und wendet die neue Parametergruppe auf den Cluster an. Verwenden Sie diese neue Parametergruppe, um Parameter in einem globalen Datenspeicher zu ändern. Jede automatisch generierte Parametergruppe ist einem Cluster und daher nur einem globalen Datenspeicher zugeordnet.
+ Verschlüsselung im Ruhezustand
**Anmerkung**
Sie können einen anderen Verschlüsselungsschlüssel angeben, indem Sie **Customer Managed AWS KMS key** und dann den Schlüssel auswählen.
+ Verschlüsselung während der Übertragung
+ AUTHENTIFIZIEREN
1. (Optional) Aktualisieren Sie die verbleibenden Einstellungen für den sekundären Cluster. Diese werden mit den gleichen Werten wie beim primären Cluster vorausgefüllt, Sie können sie jedoch aktualisieren, um bestimmte Anforderungen für diesen Cluster zu erfüllen.
+ Port
+ Anzahl der Replikate
+ Subnetzgruppe
+ Bevorzugte Availability Zone(s)
+ Sicherheitsgruppen
+ Vom Kunden verwalteter AWS KMS-Schlüssel)
+ AUTH-Token
+ Aktivieren automatischer Sicherungen.
+ Aufbewahrungszeitraum für Backups
+ Backup-Fenster
+ Wartungsfenster
+ Thema für SNS-Benachrichtigung
1. Wählen Sie **Hinzufügen** aus.
## Ändern eines globalen Datenspeichers
Sie können die Eigenschaften regionaler Cluster ändern. In einem globalen Datenspeicher kann nur jeweils eine Änderungsoperation ausgeführt werden, mit Ausnahme der Heraufstufung eines sekundären Clusters zu einem primären Cluster. Weitere Informationen finden Sie unter [Heraufstufen des sekundären Clusters zum primären Cluster](#Redis-Global-Datastores-Console-Promote-Secondary).
**So ändern Sie einen globalen Datenspeicher:**
1. Melden Sie sich bei an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Global Datastores** und dann für **Global Datastore Name einen globalen Datenspeicher** aus.
1. Wählen Sie **Modify (Ändern)**, und wählen Sie unter den folgenden Optionen:
+ **Modify description (Beschreibung ändern)** – Aktualisieren der Beschreibung des globalen Datenspeichers
+ **Engine-Version ändern** — Nur Valkey 7.2 und höher oder Redis OSS 5.0.6 und höher sind verfügbar.
+ **Modify node type (Knotentyp ändern)** – Vertikale (Aufwärts- und Abwärts-) und horizontale (Ein- und Aus-) Skalierung regionaler Cluster. Zu den Optionen gehören die R5- und M5-Knotenfamilien. Weitere Informationen zu Knotentypen finden Sie unter [Unterstützte Knotentypen](CacheNodes.SupportedTypes.md).
+ **Modify Automatic Failover (Ändern des automatischen Failovers)** – Aktivieren oder deaktivieren Sie das automatische Failover. Wenn Sie Failover aktivieren und Primärknoten in regionalen Clustern unerwartet heruntergefahren werden, erfolgt ein Failover ElastiCache zu einem der regionalen Replikate. Weitere Informationen finden Sie im Abschnitt [Automatisches Failover](AutoFailover.md).
Für Valkey- oder Redis-OSS-Cluster mit aktiviertem Clustermodus:
+ **Add shards (Shards hinzufügen)** – Geben Sie die Anzahl der hinzuzufügenden Shards ein, und geben Sie eine oder mehrere Availability Zones an.
+ Shards **löschen — Wählen Sie Shards** aus, die in jeder Region gelöscht werden sollen. AWS
+ **Rebalance shards (Shards neu ausbalancieren)** – Balancieren Sie die Slot-Verteilung neu aus, um eine gleichmäßige Verteilung über die in dem Cluster vorhandenen Shards zu gewährleisten.
Um die Parameter eines globalen Datenspeichers zu ändern, ändern Sie die Parametergruppe eines beliebigen Mitgliedsclusters für den globalen Datenspeicher. ElastiCache wendet diese Änderung automatisch auf alle Cluster innerhalb dieses globalen Datenspeichers an. Verwenden Sie die Valkey- oder Redis-OSS-Konsole oder den API-Vorgang, um die Parametergruppe dieses Clusters zu ändern. [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) Weitere Informationen finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md). Wenn Sie die Parametergruppe eines Clusters ändern, der in einem globalen Datenspeicher enthalten ist, wird sie auf alle Cluster innerhalb dieses globalen Datenspeichers angewendet.
Verwenden Sie die [ResetCacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ResetCacheParameterGroup.html)API-Operation, um eine gesamte Parametergruppe oder bestimmte Parameter zurückzusetzen.
## Heraufstufen des sekundären Clusters zum primären Cluster
Wenn der primäre Cluster oder die AWS Region nicht mehr verfügbar ist oder Leistungsprobleme auftreten, können Sie einen sekundären Cluster zum primären Cluster heraufstufen. Die Heraufstufung ist jederzeit erlaubt, auch wenn gleichzeitig andere Änderungen vorgenommen werden. Sie können auch mehrere Heraufstufungen gleichzeitig durchführen, und der globale Datenspeicher wird schließlich zu einem primären Cluster aufgelöst. Wenn Sie mehrere sekundäre Cluster gleichzeitig heraufstufen, kann ElastiCache nicht garantiert werden, welcher letztendlich zum primären Cluster wird.
**So stufen Sie einen sekundären Cluster zu einem primären Cluster herauf:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Global Datastores** aus.
1. Wählen Sie den Namen des globalen Datenspeichers aus, um die Details anzuzeigen.
1. Wählen Sie den **Secondary (sekundären)** Cluster.
1. Wählen Sie **Auf Primär heraufstufen**.
Sie werden dann mit der folgenden Warnung aufgefordert, Ihre Entscheidung zu bestätigen: ` Promoting a region to primary will make the cluster in this region as read/writable. Are you sure you want to promote the secondary cluster to primary?`
`The current primary cluster in primary region will become secondary and will stop accepting writes after this operation completes. Please ensure you update your application stack to direct traffic to the new primary region.`
1. Wählen Sie **Confirm (Bestätigen)**, wenn Sie die Heraufstufung fortsetzen möchten, oder **Cancel (Abbrechen)**, wenn Sie dies nicht möchten.
Wenn Sie sich für die Bestätigung entscheiden, wechselt Ihr globaler Datenspeicher in den Status **Modifying (Ändern)** und ist erst verfügbar, wenn die Heraufstufung abgeschlossen ist.
## Entfernen einer Region aus einem globalen Datenspeicher
Sie können eine AWS Region aus einem globalen Datenspeicher entfernen, indem Sie das folgende Verfahren verwenden.
**Um eine AWS Region aus einem globalen Datenspeicher zu entfernen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Global Datastores** aus.
1. Wählen Sie einen globalen Datenspeicher aus.
1. Wählen Sie die **Region** aus, die Sie entfernen möchten.
1. Wählen Sie **Remove region (Region entfernen)**.
**Anmerkung**
Diese Option ist nur für sekundäre Cluster verfügbar.
Sie werden dann mit der folgenden Warnung aufgefordert, Ihre Entscheidung zu bestätigen: ` Removing the region will remove your only available cross region replica for the primary cluster. Your primary cluster will no longer be set up for disaster recovery and improved read latency in remote region. Are you sure you want to remove the selected region from the global datastore?`
1. Wählen Sie **Confirm (Bestätigen)**, wenn Sie die Heraufstufung fortsetzen möchten, oder **Cancel (Abbrechen)**, wenn Sie dies nicht möchten.
Wenn Sie „Bestätigen“ wählen, wird die AWS Region entfernt und der sekundäre Cluster erhält keine Replikationsupdates mehr.
## Löschen eines globalen Datenspeichers
Um einen globalen Datenspeicher zu löschen, entfernen Sie zuerst alle sekundären Cluster. Weitere Informationen finden Sie unter [Entfernen einer Region aus einem globalen Datenspeicher](#Redis-Global-Datastore-Console-Remove-Region). Dadurch bleibt der globale Datenspeicher im Status **primary-only**.
**So löschen Sie einen globalen Datenspeicher:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Global Datastores** aus.
1. Wählen Sie unter **Global Datastore Name (Name des globalen Datenspeichers)** den globalen Datenspeicher, den Sie löschen möchten, und dann **Delete (Löschen)**.
Sie werden dann mit der folgenden Warnung aufgefordert, Ihre Entscheidung zu bestätigen: `Are you sure you want to delete this Global Datastore?`
1. Wählen Sie **Löschen** aus.
Der globale Datenspeicher wechselt zum Status **Deleting (Löschen)**.
# Verwenden globaler Datenspeicher (CLI)
Sie können die AWS Command Line Interface (AWS CLI) verwenden, um mehrere AWS Dienste von der Befehlszeile aus zu steuern und sie mithilfe von Skripten zu automatisieren. Sie können die AWS CLI für (einmalige) Ad-hoc-Operationen verwenden.
## Herunterladen und Konfigurieren der AWS CLI
Das AWS CLI läuft unter Windows, MacOS oder Linux. Gehen Sie folgendermaßen vor, um sie herunterzuladen und zu konfigurieren.
**So laden Sie den CLI herunter, installieren und konfigurieren ihn**
1. Laden Sie die AWS CLI von der Webseite mit der [AWS Befehlszeilenschnittstelle](https://aws.amazon.com/cli) herunter.
1. Folgen Sie den Anweisungen zur Installation der AWS CLI und zur Konfiguration der AWS CLI im *AWS Command Line Interface Benutzerhandbuch*.
## Verwenden der AWS CLI mit globalen Datenspeichern
Verwenden Sie die folgenden CLI-Operationen, um mit globalen Datenspeichern zu arbeiten:
+ [create-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-global-replication-group.html)
```
aws elasticache create-global-replication-group \
--global-replication-group-id-suffix my global datastore \
--primary-replication-group-id sample-repl-group \
--global-replication-group-description an optional description of the global datastore
```
Amazon wendet ElastiCache automatisch ein Präfix auf die globale Datenspeicher-ID an, wenn sie erstellt wird. Jede AWS Region hat ihr eigenes Präfix. Beispielsweise beginnt eine globale Datenspeicher-ID, die in der Region USA West (Nordkalifornien) erstellt wurde, mit „virxk“ zusammen mit dem von Ihnen angegebenen Suffixnamen. Das Suffix in Kombination mit dem automatisch generierten Präfix garantiert die Eindeutigkeit des globalen Datenspeichernamens über mehrere Regionen hinweg.
In der folgenden Tabelle sind jede AWS Region und ihr globales Datenspeicher-ID-Präfix aufgeführt.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/Redis-Global-Datastores-CLI.html)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)— Verwenden Sie diesen Vorgang, um sekundäre Cluster für einen globalen Datenspeicher zu erstellen, indem Sie den Namen des globalen Datenspeichers für den Parameter angeben. `--global-replication-group-id`
```
aws elasticache create-replication-group \
--replication-group-id secondary replication group name \
--replication-group-description “Replication group description" \
--global-replication-group-id global datastore name
```
Wenn Sie diesen Vorgang aufrufen und einen `--global-replication-group-id` Wert übergeben, ElastiCache werden die Werte für die folgenden Parameter aus der primären Replikationsgruppe der globalen Replikationsgruppe abgeleitet. Übergeben Sie keine Werte für diese Parameter:
`"PrimaryClusterId",`
`"AutomaticFailoverEnabled",`
` "NumNodeGroups",`
` "CacheParameterGroupName",`
` "CacheNodeType",`
` "Engine",`
` "EngineVersion",`
` "CacheSecurityGroupNames",`
` "EnableTransitEncryption",`
` "AtRestEncryptionEnabled",`
` "SnapshotArns",`
` "SnapshotName"`
+ [describe-global-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-global-replication-groups.html)
```
aws elasticache describe-global-replication-groups \
--global-replication-group-id my global datastore \
--show-member-info an optional parameter that returns a list of the primary and secondary clusters that make up the global datastore
```
+ [modify-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-global-replication-group.html)
```
aws elasticache modify-global-replication-group \
--global-replication-group-id my global datastore \
--automatic-failover-enabled \
--cache-node-type node type \
--cache-parameter-group-name parameter group name \
--engine-version engine version \
-—apply-immediately \
--global-replication-group-description description
```
**Engine-übergreifendes Upgrade von Redis auf OSS Valkey für ElastiCache GlobalDataStore**
Sie können eine bestehende globale Redis OSS-Replikationsgruppe mithilfe der Konsole, API oder CLI auf Valkey aktualisieren.
Wenn Sie bereits über eine globale Redis OSS-Replikationsgruppe verfügen, können Sie ein Upgrade auf Valkey durchführen, indem Sie die neue Engine und die Engine-Version mit der API angeben. modify-global-replication-group
Für Linux, macOS oder Unix:
```
aws elasticache modify-global-replication-group \
--global-replication-group-id myGlobalReplGroup \
--engine valkey \
--apply-immediately \
--engine-version 8.0
```
Für Windows:
```
aws elasticache modify-global-replication-group ^
--global-replication-group-id myGlobalReplGroup ^
--engine valkey ^
--apply-immediately ^
--engine-version 8.0
```
Wenn Sie eine benutzerdefinierte Cache-Parametergruppe auf die bestehende globale Redis OSS-Replikationsgruppe angewendet haben, die Sie aktualisieren möchten, müssen Sie in der Anfrage auch eine benutzerdefinierte Valkey-Cache-Parametergruppe übergeben. Die benutzerdefinierte Valkey-Eingabeparametergruppe muss dieselben statischen Redis OSS-Parameterwerte haben wie die vorhandene benutzerdefinierte Redis OSS-Parametergruppe.
Für Linux, macOS oder Unix:
```
aws elasticache modify-global-replication-group \
--global-replication-group-id myGlobalReplGroup \
--engine valkey \
--engine-version 8.0 \
--apply-immediately \
--cache-parameter-group-name myParamGroup
```
Für Windows:
```
aws elasticache modify-global-replication-group ^
--global-replication-group-id myGlobalReplGroup ^
--engine valkey ^
--engine-version 8.0 ^
--apply-immediately ^
--cache-parameter-group-name myParamGroup
```
+ [delete-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-global-replication-group.html)
```
aws elasticache delete-global-replication-group \
--global-replication-group-id my global datastore \
--retain-primary-replication-group defaults to true
```
+ [disassociate-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/disassociate-global-replication-group.html)
```
aws elasticache disassociate-global-replication-group \
--global-replication-group-id my global datastore \
--replication-group-id my secondary cluster \
--replication-group-region the AWS Region in which the secondary cluster resides
```
+ [failover-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/failover-global-replication-group.html)
```
aws elasticache failover-replication-group \
--global-replication-group-id my global datastore \
--primary-region The AWS Region of the primary cluster \
--primary-replication-group-id The name of the global datastore, including the suffix.
```
+ [increase-node-groups-in-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/increase-node-groups-in-global-replication-group.html)
```
aws elasticache increase-node-groups-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name \
--node-group-count 3
```
+ [decrease-node-groups-in-global-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/decrease-node-groups-in-global-replication-group.html)
```
aws elasticache decrease-node-groups-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name \
--node-group-count 3
```
+ [rebalance-shards-in-global-Replikationsgruppe](https://docs.aws.amazon.com/cli/latest/reference/elasticache/rebalance-slots-in-global-replication-group.html)
```
aws elasticache rebalance-shards-in-global-replication-group \
--apply-immediately yes \
--global-replication-group-id global-replication-group-name
```
Verwenden Sie die Hilfe, um alle verfügbaren Befehle ElastiCache für Valkey oder Redis OSS aufzulisten.
```
aws elasticache help
```
Sie können die Hilfe auch verwenden, um einen bestimmten Befehl zu beschreiben und mehr über seine Verwendung zu erfahren:
```
aws elasticache create-global-replication-group help
```
# Hohe Verfügbarkeit mit Replikationsgruppen
Amazon ElastiCache Valkey- und Redis OSS-Cluster mit einem Knoten sind In-Memory-Einheiten mit eingeschränkten 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 gruppieren, 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 API/CLI als *Knotengruppe* bezeichnet) 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 (Cluster-Modus aktiviert) können bis zu 500 Shards haben, wobei die Daten des Clusters auf die Shards verteilt 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 mit ElastiCache Version 5.0.6 oder höher für Redis OSS 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](SubnetGroups.Creating.md).
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](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) und wählen Sie den Limittyp **Nodes per cluster per instance type**.
![\[Bild: Der Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) hat einen Shard und 0 bis 5 Replikatknoten\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Der Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) hat einen Shard und 0 bis 5 Replikatknoten*
Wenn für den Cluster mit Replikaten Multi-AZ aktiviert ist, wird bei einem Ausfall des primären Knotens ein automatisches Failover auf eine Read Replica durchgeführt. 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 Fehlern beim Ausführen von Valkey oder Redis OSS](disaster-recovery-resiliency.md#FaultTolerance.Redis).
**Topics**
+ [Die OSS-Replikation von Valkey und Redis verstehen](Replication.Redis.Groups.md)
+ [Replikation: Valkey- und Redis OSS-Clustermodus deaktiviert oder aktiviert](Replication.Redis-RedisCluster.md)
+ [Minimierung von Ausfallzeiten durch die Verwendung ElastiCache von Multi-AZ mit Valkey und Redis OSS](AutoFailover.md)
+ [So werden Synchronisation und Backup implementiert](Replication.Redis.Versions.md)
+ [Erstellen einer Valkey- oder Redis OSS-Replikationsgruppe](Replication.CreatingRepGroup.md)
+ [Anzeigen der Details einer Replikationsgruppe](Replication.ViewDetails.md)
+ [Suchen von Endpunkten von Replikationsgruppen](Replication.Endpoints.md)
+ [Ändern einer Replikationsgruppe](Replication.Modify.md)
+ [Löschen einer Replikationsgruppe](Replication.DeletingRepGroup.md)
+ [Ändern der Anzahl von Replikaten](increase-decrease-replica-count.md)
+ [Heraufstufen einer Read Replica zu primären Replikationsgruppen für Valkey oder Redis OSS (Clustermodus deaktiviert)](Replication.PromoteReplica.md)
# Die OSS-Replikation von Valkey und Redis verstehen
Redis OSS implementiert die Replikation auf zwei Arten:
+ Mit einem einzigen Shard, der alle Clusterdaten in jedem Knoten enthält — Valkey oder Redis OSS (Clustermodus deaktiviert)
+ Mit Daten, die auf bis zu 500 Shards partitioniert sind — Valkey oder Redis OSS (Clustermodus aktiviert)
Jeder Shard in einer Replikationsgruppe hat einen einzelnen read/write primären Knoten und bis zu 5 schreibgeschützte Replikatknoten. 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 auf maximal 500 pro Cluster erhöht werden, wenn die Redis OSS-Engine-Version 5.0.6 oder höher ist. 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](SubnetGroups.Creating.md).
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](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) und wählen Sie den Limittyp **Nodes per cluster per instance type**.
**Topics**
+ [Valkey oder Redis OSS (Clustermodus deaktiviert)](#Replication.Redis.Groups.Classic)
+ [Valkey oder Redis OSS (Clustermodus aktiviert)](#Replication.Redis.Groups.Cluster)
## Valkey oder Redis OSS (Clustermodus deaktiviert)
Ein Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) hat einen einzelnen Shard, in dem sich eine Sammlung von Knoten befindet: ein primärer read/write Knoten und bis zu fünf sekundäre, schreibgeschützte Replikatknoten. Jede Read Replica speichert eine Kopie der Daten aus dem primären Knoten des Clusters. Mittels asynchroner Replikationsmechanismen werden die Read Replicas mit dem primären Knoten synchron gehalten. Anwendungen können aus jedem Knoten im Cluster lesen. Anwendungen können nur in den primären Knoten schreiben. Read Replicas verbessern den Lesedurchsatz und schützen vor Datenverlust im Falle eines Knotenausfalls.
![\[Bild: Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) mit einem einzigen Shard und Replikatknoten\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) mit einem einzigen Shard und Replikatknoten*
Sie können Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) mit Replikatknoten verwenden, um Ihre Lösung für leseintensive Anwendungen ElastiCache zu skalieren oder um eine große Anzahl von Clients zu unterstützen, die gleichzeitig aus demselben Cluster lesen.
Alle Knoten in einem Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) müssen sich in derselben Region befinden.
Wenn Sie eine Read Replica zu einem Cluster hinzufügen, werden alle Daten vom primären Knoten auf den neuen Knoten kopiert. Ab diesem Punkt werden Änderung jedes Mal, wenn Daten in den primären Knoten geschrieben werden, synchron auf alle Read Replicas übertragen.
Um die Fehlertoleranz zu verbessern und Ausfallzeiten beim Schreiben zu reduzieren, aktivieren Sie Multi-AZ mit automatischem Failover für Ihren Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) mit Replikaten. Weitere Informationen finden Sie unter [Minimierung von Ausfallzeiten durch die Verwendung ElastiCache von Multi-AZ mit Valkey und Redis OSS](AutoFailover.md).
Sie können die Rollen der Knoten innerhalb des Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) ändern, wobei der primäre Knoten und eines der Replikate die Rollen austauschen. Sie könnten sich aus Gründen der Leistungsoptimierung hierfür entscheiden. Bei einer Webanwendung mit der intensivsten Schreibaktivität könnten Sie z. B. den Knoten mit der niedrigsten Netzwerklatenz wählen. Weitere Informationen finden Sie unter [Heraufstufen einer Read Replica zu primären Replikationsgruppen für Valkey oder Redis OSS (Clustermodus deaktiviert)](Replication.PromoteReplica.md).
## Valkey oder Redis OSS (Clustermodus aktiviert)
Ein Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) besteht aus 1 bis 500 Shards (API/CLI: Knotengruppen). Jeder Shard verfügt über einen primären Knoten und bis zu fünf schreibgeschützte Replikatknoten. Die Konfiguration 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 auf maximal 500 pro Cluster erhöht werden, wenn die Engine-Version Valkey 7.2 und höher oder Redis OSS 5.0.6 und höher ist. 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](SubnetGroups.Creating.md).
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](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) und wählen Sie den Limittyp **Nodes per cluster per instance type**.
Jede Read Replica in einem Shard speichert eine Kopie der Daten aus dem primären Knoten des Shards. Mittels asynchroner Replikationsmechanismen werden die Read Replicas mit dem primären Knoten synchron gehalten. Anwendungen können aus jedem Knoten im Cluster lesen. Anwendungen können nur in die primären Knoten schreiben. Read Replicas verbessern die Leseskalierbarkeit und schützen vor Datenverlust. Die Daten werden auf die Shards in einem Valkey- oder Redis OSS-Cluster (Cluster-Modus aktiviert) aufgeteilt.
Anwendungen verwenden den *Konfigurationsendpunkt* des Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert), um eine Verbindung mit den Knoten im Cluster herzustellen. Weitere Informationen finden Sie unter [Verbindungsendpunkte finden in ElastiCache](Endpoints.md).
![\[Bild: Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mit mehreren Shards und Replikatknoten\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-RedisClusters.png)
*Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mit mehreren Shards und Replikatknoten*
Alle Knoten in einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) müssen sich in derselben Region befinden. Zur Verbesserung der Fehlertoleranz können Sie sowohl primären Knoten als auch Read Replicas in mehreren Availability Zones innerhalb dieser Region bereitstellen.
Derzeit weisen die Funktionen von Valkey oder Redis OSS (Clustermodus aktiviert) einige Einschränkungen auf.
+ Keine der Replikatknoten können zum primären Knoten manuell heraufgestuft werden.
# Replikation: Valkey- und Redis OSS-Clustermodus deaktiviert oder aktiviert
Ab Valkey 7.2 und Redis OSS Version 3.2 haben Sie die Möglichkeit, einen von zwei unterschiedlichen Clustertypen (API/CLI: replication groups). A Valkey or Redis OSS (cluster mode disabled) cluster always has a single shard (API/CLI: Knotengruppe) mit bis zu 5 Read Replica-Knoten zu erstellen. Ein Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) hat bis zu 500 Shards mit jeweils 1 bis 5 Read Replica-Knoten.
![\[Bild: Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) und Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert)\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCache-NodeGroups.png)
*Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) und Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert)*
In der folgenden Tabelle werden wichtige Unterschiede zwischen Valkey- oder Redis OSS-Clustern (Clustermodus deaktiviert) und Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert) zusammengefasst.
**Vergleich von Valkey- oder Redis OSS-Clustern (Clustermodus deaktiviert) und Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)**
| Funktion | Valkey oder Redis OSS (Clustermodus deaktiviert) | Valkey oder Redis OSS (Clustermodus aktiviert) |
| --- | --- | --- |
| Anpassbar | Ja. Unterstützt das Hinzufügen und Löschen von Replikatknoten und das Hochskalieren des Knotentyps. | Begrenzt. Weitere Informationen erhalten Sie unter [Versionsverwaltung für ElastiCache](VersionManagement.md) und [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md). |
| Datenpartitionierung | Nein | Ja |
| Shards | 1 | 1 bis 500 |
| Read Replicas | 0 bis 5 Wenn Sie bei einem Knotenausfall über keine Replikate verfügen, gehen alle Ihre Daten verloren. | 0 bis 5 pro Shard. Wenn Sie bei einem Knotenausfall über keine Replikate verfügen, gehen alle Ihre Daten in diesem Shard verloren. |
| Multi-AZ | Ja, mit mindestens 1 Replikat. Optional. Standardmäßig aktiviert | JaOptional. Standardmäßig aktiviert |
| Snapshots (Backups) | Ja, es wird eine einzelne .rdb-Datei erstellt. | Ja, es wird für jeden Shard eine eindeutige .rdb-Datei erstellt. |
| Wiederherstellung | Ja, mit einer einzigen .rdb-Datei aus einem Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert). | Ja, mit .rdb-Dateien aus einem Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) oder einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert). |
| Unterstützt von | Alle Valkey- und Redis OSS-Versionen | Alle Valkey-Versionen und Redis OSS 3.2 und folgende |
| Engine aktualisierbar | Ja, mit einigen Einschränkungen. Weitere Informationen finden Sie unter [Versionsverwaltung für ElastiCache](VersionManagement.md). | Ja, mit einigen Einschränkungen. Weitere Informationen finden Sie unter [Versionsverwaltung für ElastiCache](VersionManagement.md). |
| Verschlüsselung | Versionen 3.2.6 (für EOL geplant, siehe [Zeitplan für das Ende der Lebensdauer der Redis OSS-Versionen](engine-versions.md#deprecated-engine-versions)) und 4.0.10 und höher. | Versionen 3.2.6 (für EOL geplant, siehe Zeitplan für das [Ende der Lebensdauer der Redis OSS-Versionen](engine-versions.md#deprecated-engine-versions)) und 4.0.10 und höher. |
| HIPAA-konform | Versionen 3.2.6 (für EOL geplant, siehe Zeitplan für das [Ende der Lebensdauer der Redis OSS-Versionen](engine-versions.md#deprecated-engine-versions)) und 4.0.10 und höher. | Versionen 3.2.6 (für EOL geplant, siehe Zeitplan für das [Ende der Lebensdauer der Redis OSS-Versionen](engine-versions.md#deprecated-engine-versions)) und 4.0.10 und höher. |
| Zu PCI DSS konform | Versionen 3.2.6 (für EOL geplant, siehe Zeitplan für das [Ende der Lebensdauer der Redis OSS-Versionen](engine-versions.md#deprecated-engine-versions)) und 4.0.10 und höher. | Versionen 3.2.6 (für EOL geplant, siehe Zeitplan für das [Ende der Lebensdauer der Redis OSS-Versionen](engine-versions.md#deprecated-engine-versions)) und 4.0.10 und höher. |
| Online-Resharding | N/A | Version 3.2.10 (für EOL geplant, siehe Zeitplan für das Ende der Lebensdauer der [Redis OSS-Versionen](engine-versions.md#deprecated-engine-versions)) und höher. |
## Welchen Cluster soll ich wählen?
Wenn Sie zwischen Valkey oder Redis OSS (Cluster-Modus deaktiviert) oder Valkey oder Redis OSS (Cluster-Modus aktiviert) wählen, sollten Sie die folgenden Faktoren berücksichtigen:
+ **Skalierung im Vergleich zu Partitionierung** – Geschäftliche Anforderungen ändern sich. Sie müssen entweder für Spitzenbedarf vorsorgen oder bei Bedarfsänderungen skalieren. Valkey oder Redis OSS (Clustermodus deaktiviert) unterstützt die Skalierung. Sie können die Lesekapazität durch Hinzufügen oder Löschen von Replikatknoten skalieren. Sie können die Kapazität auch nach oben skalieren, indem Sie auf einen größeren Knotentyp skalieren. Beide dieser Operationen sind zeitaufwendig. Weitere Informationen finden Sie unter [Skalierung von Replikatknoten für Valkey oder Redis OSS (Clustermodus deaktiviert)](Scaling.RedisReplGrps.md).
Valkey oder Redis OSS (Clustermodus aktiviert) unterstützt die Partitionierung Ihrer Daten auf bis zu 500 Knotengruppen. Sie können die Anzahl der Shards dynamisch ändern, wenn sich Ihre Geschäftsanforderungen ändern. Ein Vorteil der Partitionierung liegt darin, dass Ihre Arbeitslast über eine größere Anzahl von Endpunkten verteilt wird. Dadurch lassen sich Engpässe in Zeiten mit höchster Auslastung reduzieren. Zusätzlich dazu können Sie einen größeren Datensatz bewältigen, da die Daten über mehrere Server verteilt werden können. Informationen zur Skalierung Ihrer Partitionen finden Sie unter. [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md)
+ **Knotengröße vs. Anzahl der Knoten** — Da ein Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) nur einen Shard hat, muss der Knotentyp groß genug sein, um alle Daten des Clusters sowie den erforderlichen Overhead aufzunehmen. Da Sie Ihre Daten andererseits auf mehrere Shards partitionieren können, wenn Sie einen Valkey- oder Redis OSS-Cluster (Cluster-Modus aktiviert) verwenden, können die Knotentypen kleiner sein, obwohl Sie mehr davon benötigen. Weitere Informationen finden Sie unter [Auswahl der Knotengröße](CacheNodes.SelectSize.md).
+ **Lesevorgänge versus Schreibvorgänge** — Wenn die Hauptlast auf Ihrem Cluster darin besteht, dass Anwendungen Daten lesen, können Sie einen Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) skalieren, indem Sie Read Replicas hinzufügen und löschen. Es gibt jedoch maximal 5 Read Replicas. Wenn die Last auf Ihrem Cluster viele Schreibvorgänge erfordert, können Sie von den zusätzlichen Schreibendpunkten eines Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert) mit mehreren Shards profitieren.
Unabhängig von dem ausgewählten, zu implementierenden Clustertyp ist es wichtig, einen Knotentyp zu wählen, der für Ihre derzeitigen und zukünftigen Anforderungen angemessen ist.
# Minimierung von Ausfallzeiten durch die Verwendung ElastiCache von Multi-AZ mit Valkey und Redis OSS
Es gibt eine Reihe von Fällen, in denen OSS ElastiCache für Valkey und Redis möglicherweise einen Primärknoten austauschen muss. Dazu gehören bestimmte Arten von geplanten Wartungsarbeiten und der unwahrscheinliche Fall eines Ausfalls eines Primärknotens oder einer Availability Zone.
Dieser Austausch führt zu einer gewissen Ausfallzeit für den Cluster, aber wenn Multi-AZ aktiviert ist, wird die Ausfallzeit minimiert. Die Rolle des primären Knotens wird automatisch auf eines der Read Replicas übertragen. Es ist nicht erforderlich, einen neuen Primärknoten zu erstellen und bereitzustellen, da dies transparent ElastiCache gehandhabt wird. Dieser Failover und die Replikatheraufstufung stellen sicher, dass Sie weiter in den neuen primären Knoten schreiben können, sobald die Heraufstufung abgeschlossen wurde.
ElastiCache verbreitet auch den DNS-Namen (Domain Name Service) des beworbenen Replikats. Auf diese Weise ist in Ihrer Anwendung, falls sie in den primären Endpunkt schreibt, keine Endpunktänderung erforderlich. Wenn Sie aus individuellen Endpunkten lesen, müssen Sie den Leseendpunkt des zum primären Knoten heraufgestuften Replikats in den Endpunkt des neuen Replikats ändern.
Im Falle eines geplanten Knotenaustauschs, der aufgrund von Wartungs- oder Self-Service-Aktualisierungen eingeleitet wird, beachten Sie Folgendes:
+ Bei Valkey- und Redis OSS-Clustern werden die geplanten Knotenersetzungen abgeschlossen, während der Cluster eingehende Schreibanforderungen bearbeitet.
+ Bei deaktivierten Clustern im Valkey- und Redis OSS-Clustermodus mit aktiviertem Multi-AZ, die auf der Engine 5.0.6 oder höher ausgeführt werden, werden die geplanten Knotenersetzungen abgeschlossen, während der Cluster eingehende Schreibanforderungen bearbeitet.
+ Bei deaktivierten Clustern im Valkey- und Redis OSS-Clustermodus mit aktiviertem Multi-AZ, die auf der Engine 4.0.10 oder früher ausgeführt werden, stellen Sie möglicherweise eine kurze Schreibunterbrechung im Zusammenhang mit DNS-Updates fest. Diese Unterbrechung kann bis zu einigen Sekunden dauern. Dieser Vorgang ist viel schneller als die Neuerstellung und Bereitstellung einer neuen Primärdatenbank, was geschieht, wenn Sie Multi-AZ nicht aktivieren.
Sie können Multi-AZ mithilfe der ElastiCache Management Console, der oder der API aktivieren. AWS CLI ElastiCache
Die Aktivierung von ElastiCache Multi-AZ auf Ihrem Valkey- oder Redis OSS-Cluster (in der API und CLI, Replikationsgruppe) verbessert Ihre Fehlertoleranz. Dies gilt insbesondere in Fällen, in denen der read/write primäre Cluster Ihres Clusters nicht mehr erreichbar ist oder aus irgendeinem Grund ausfällt. Multi-AZ wird nur auf Valkey- und Redis OSS-Clustern mit mehr als einem Knoten in jedem Shard unterstützt.
**Topics**
+ [Aktivieren von Multi-AZ](#AutoFailover.Enable)
+ [Fehlerszenarien mit Multi-AZ-Antworten](#AutoFailover.Scenarios)
+ [Testen des automatischen Failovers](#auto-failover-test)
+ [Einschränkungen bei Multi-AZ](#AutoFailover.Limitations)
## Aktivieren von Multi-AZ
Sie können Multi-AZ aktivieren, wenn Sie einen Cluster (API oder CLI, Replikationsgruppe) mithilfe der ElastiCache Konsole oder der ElastiCache API erstellen oder ändern. AWS CLI
Sie können Multi-AZ nur auf Valkey- oder Redis OSS-Clustern (Clustermodus deaktiviert) aktivieren, für die mindestens eine Read Replica verfügbar ist. Cluster ohne Read Replicas bieten keine hohe Verfügbarkeit oder Fehlertoleranz. Weitere Informationen zum Erstellen eines Clusters mit Replikation finden Sie unter [Erstellen einer Valkey- oder Redis OSS-Replikationsgruppe](Replication.CreatingRepGroup.md). Weitere Informationen zum Hinzufügen einer Read Replica zu einem Cluster mit Replikation finden Sie unter [Hinzufügen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert)](Replication.AddReadReplica.md).
**Topics**
+ [Aktivieren von Multi-AZ (Konsole)](#AutoFailover.Enable.Console)
+ [Aktivieren von Multi-AZ (AWS CLI)](#AutoFailover.Enable.CLI)
+ [Multi-AZ (ElastiCache API) aktivieren](#AutoFailover.Enable.API)
### Aktivieren von Multi-AZ (Konsole)
Sie können Multi-AZ mithilfe der ElastiCache Konsole aktivieren, wenn Sie einen neuen Valkey- oder Redis OSS-Cluster erstellen oder indem Sie einen vorhandenen Cluster mit Replikation ändern.
Multi-AZ ist standardmäßig auf Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert) aktiviert.
**Wichtig**
ElastiCache aktiviert Multi-AZ automatisch nur dann, wenn der Cluster in allen Shards mindestens ein Replikat in einer anderen Availability Zone als der primären enthält.
#### Multi-AZ wird aktiviert, wenn ein Cluster mithilfe der Konsole erstellt wird ElastiCache
Weitere Informationen zu diesem Vorgang finden Sie unter [Erstellen eines Valkey-Clusters (Cluster-Modus deaktiviert) (Konsole)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs). Achten Sie darauf, dass mehr als ein Replikat vorhanden und Multi-AZ aktiviert ist.
#### Aktivieren von Multi-AZ auf einem vorhandenen Cluster (Konsole)
Weitere Informationen zu diesem Prozess finden Sie unter „Ändern eines Clusters“ [Unter Verwendung der ElastiCache AWS-Managementkonsole](Clusters.Modify.md#Clusters.Modify.CON).
### Aktivieren von Multi-AZ (AWS CLI)
Im folgenden Codebeispiel wird Multi-AZ für die AWS CLI Replikationsgruppe aktiviert. `redis12`
**Wichtig**
Die Replikationsgruppe `redis12` muss bereits vorhanden sein und mindestens eine verfügbare Read Replica besitzen.
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group \
--replication-group-id redis12 \
--automatic-failover-enabled \
--multi-az-enabled \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id redis12 ^
--automatic-failover-enabled ^
--multi-az-enabled ^
--apply-immediately
```
Die JSON-Ausgabe dieses Befehls sollte in etwa folgendermaßen aus.
```
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "One shard, two nodes",
"NodeGroups": [
{
"Status": "modifying",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis12-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "redis12",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabling",
"MultiAZ": "enabled",
"SnapshotWindow": "07:00-08:00",
"SnapshottingClusterId": "redis12-002",
"MemberClusters": [
"redis12-001",
"redis12-002"
],
"PendingModifiedValues": {}
}
}
```
Weitere Informationen zu diesen Themen finden Sie in der *AWS CLI -Befehlsreferenz*:
+ [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
+ [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)in der *AWS CLI Befehlsreferenz.*
### Multi-AZ (ElastiCache API) aktivieren
Das folgende Codebeispiel verwendet die ElastiCache API, um Multi-AZ für die Replikationsgruppe zu aktivieren. `redis12`
**Anmerkung**
Zur Verwendung dieses Beispiels muss die Replikationsgruppe `redis12` bereits vorhanden sein und mindestens ein verfügbares Lesereplikat besitzen.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&AutoFailover=true
&MultiAZEnabled=true
&ReplicationGroupId=redis12
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20140401T192317Z
&X-Amz-Credential=
```
Weitere Informationen zu diesen Themen finden Sie in der *ElastiCache -API-Befehlsreferenz*:
+ [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html)
+ [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
+ [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
## Fehlerszenarien mit Multi-AZ-Antworten
Vor der Einführung von Multi-AZ wurden die ausgefallenen Knoten eines Clusters ElastiCache erkannt und ersetzt, indem der ausgefallene Knoten neu erstellt und erneut bereitgestellt wurde. Wenn Sie Multi-AZ aktivieren, wird bei einem ausgefallenen primärer Knoten ein Failover auf das Replikat mit der geringsten Replikationsverzögerung durchgeführt. Das ausgewählte Replikat wird automatisch zum primären Knoten heraufgestuft. Dies ist sehr viel schneller, als einen neuen primären Knoten zu erstellen und neu bereitzustellen. Bei diesem Vorgang dauert gewöhnlich nur wenige Sekunden, bis Sie wieder in den Cluster schreiben können.
Wenn Multi-AZ aktiviert ist, wird der Status des ElastiCache Primärknotens kontinuierlich überwacht. Sollte der primäre Knoten ausfallen, wird abhängig von der Art des Ausfalls eine der folgenden Aktionen durchgeführt.
**Topics**
+ [Fehlerszenarien, wenn nur der Primärknoten ausfällt](#AutoFailover.Scenarios.PrimaryOnly)
+ [Fehlerszenarien, wenn der Primärknoten und einige Read Replicas (Lesereplikate) fehlschlagen](#AutoFailover.Scenarios.PrimaryAndReplicas)
+ [Fehlerszenarien, wenn der gesamte Cluster ausfällt](#AutoFailover.Scenarios.AllFail)
### Fehlerszenarien, wenn nur der Primärknoten ausfällt
Wenn nur der primäre Knoten ausfällt, wird das Read Replica mit der geringsten Replikationsverzögerung wird zum primären Cluster heraufgestuft. Ein Ersatz-Read Replica wird dann in derselben Availability Zone wie der ausgefallene primäre Knoten erstellt und bereitgestellt .
Wenn nur der Primärknoten ausfällt, geht ElastiCache Multi-AZ wie folgt vor:
1. Der ausgefallene primäre Knoten wird in den Offline-Zustand versetzt.
1. Die Read Replica mit der geringsten Replikationsverzögerung wird zum primären Knoten heraufgestuft.
Die Schreibvorgänge können fortgesetzt werden, sobald der Vorgang der Heraufstufung abgeschlossen ist. Dies dauert in der Regel nur einige Sekunden. Wenn Ihre Anwendung auf den primären Endpunkt schreibt, ist keine Endpunktänderung für Schreib- oder Lesevorgänge Vorgänge erforderlich, da ElastiCache den DNS-Namen des heraufgestuften Replikats überträgt.
1. Ein Ersatz-Read Replica wird gestartet und bereitgestellt.
Die Ersatz-Read Replica wird in der Availability Zone gestartet, in der sich der ausgefallene Knoten befand. Die Verteilung der Knoten bleibt daher erhalten.
1. Die anderen Replikate werden mit dem neuen primären Knoten synchronisiert.
Nachdem das neue Replikat verfügbar ist, beachten Sie die folgenden Effekte:
+ **Primärer Endpunkt** – Sie müssen keine Änderungen an Ihrer Anwendung vornehmen, da der DNS-Name des neuen primären Knotens an den primären Endpunkt weitergegeben wird.
+ **Lese-Endpunkt** – Der Lese-Endpunkt wird automatisch aktualisiert, sodass er auf die neuen Replikatknoten verweist.
Weitere Informationen zum Suchen der Endpunkte eines Clusters finden Sie in den folgenden Themen:
+ [Finden Sie die Endpunkte eines Valkey- oder Redis OSS-Clusters (Cluster-Modus deaktiviert) (Konsole)](Endpoints.md#Endpoints.Find.Redis)
+ [Finden der Endpunkte für Valkey- oder Redis OSS-Replikationsgruppen ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Suche nach Endpunkten für Valkey- oder Redis OSS-Replikationsgruppen (API) ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
### Fehlerszenarien, wenn der Primärknoten und einige Read Replicas (Lesereplikate) fehlschlagen
Bei Ausfall des primären Clusters und mindestens einer Read Replica wird das verfügbare Replikat mit der geringsten Replikationsverzögerung zum primären Cluster heraufgestuft. Zudem werden in denselben Availability Zones, in der sich die ausgefallenen Knoten und das zum primären Cluster heraufgestufte Replikat befanden, neue Read Replicas erstellt und bereitgestellt.
Wenn der Primärknoten und einige Read Replicas ausfallen, geht ElastiCache Multi-AZ wie folgt vor:
1. Der ausgefallene primäre Knoten und ausgefallenen die Read Replicas werden in den Offline-Zustand versetzt.
1. Das verfügbare Replikat mit der geringsten Replikationsverzögerung wird zum primären Knoten heraufgestuft.
Die Schreibvorgänge können fortgesetzt werden, sobald der Vorgang der Heraufstufung abgeschlossen ist. Dies dauert in der Regel nur einige Sekunden. Wenn Ihre Anwendung auf den primären Endpunkt schreibt, müssen Sie den Endpunkt für Schreibvorgänge nicht ändern. ElastiCache verbreitet den DNS-Namen des beworbenen Replikats.
1. Ersatzreplikate werden erstellt und bereitgestellt.
Die Ersatzreplikate werden in den Availability Zones der ausgefallenen Knoten erstellt, sodass die Verteilung der Knoten erhalten bleibt.
1. Alle Cluster werden mit dem neuen primären Knoten synchronisiert.
Nehmen Sie die folgenden Änderungen an Ihrer Anwendung vor, wenn die neuen Knoten verfügbar sind:
+ **Primärer Endpunkt** – Nehmen Sie keine Änderungen an Ihrer Anwendung vor. Der DNS-Name des neuen Primärknotens wird an den primären Endpunkt weitergegeben.
+ **Lese-Endpunkt** – Der Lese-Endpunkt wird automatisch so aktualisiert, dass er auf die neuen Replikatknoten verweist.
Weitere Informationen zum Suchen der Endpunkte einer Replikationsgruppe finden Sie in den folgenden Themen:
+ [Finden Sie die Endpunkte eines Valkey- oder Redis OSS-Clusters (Cluster-Modus deaktiviert) (Konsole)](Endpoints.md#Endpoints.Find.Redis)
+ [Finden der Endpunkte für Valkey- oder Redis OSS-Replikationsgruppen ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Suche nach Endpunkten für Valkey- oder Redis OSS-Replikationsgruppen (API) ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
### Fehlerszenarien, wenn der gesamte Cluster ausfällt
Bei einem umfassenden Ausfall werden in denselben Availability Zones, der sich die Originalknoten befanden, alle Knoten neu erstellt und bereitgestellt.
In diesem Szenario gehen alle Daten im Cluster aufgrund des Ausfalls eines jeden Knotens im Cluster verloren. Ein solches Ereignis ist selten.
Wenn der gesamte Cluster ausfällt, geht ElastiCache Multi-AZ wie folgt vor:
1. Der ausgefallene primäre Knoten und die Read Replicas werden in den Offline-Zustand versetzt.
1. Es wird ein primäre Ersatzknoten erstellt und bereitgestellt.
1. Ersatzreplikate werden erstellt und bereitgestellt.
Die Ersetzungen werden in den Availability Zones der ausgefallenen Knoten erstellt, sodass die Verteilung der Knoten erhalten bleibt.
Da der gesamte Cluster ausgefallen ist, kam es zu Datenverlust. Alle neuen Knoten werden kalt gestartet.
Da jeder Ersatzknoten denselben Endpunkt wie der Knoten hat, der durch ihn ersetzt wird, müssen in Ihrer Anwendung keine Endpunktänderungen vorgenommen werden.
Weitere Informationen zum Suchen der Endpunkte einer Replikationsgruppe finden Sie in den folgenden Themen:
+ [Finden Sie die Endpunkte eines Valkey- oder Redis OSS-Clusters (Cluster-Modus deaktiviert) (Konsole)](Endpoints.md#Endpoints.Find.Redis)
+ [Finden der Endpunkte für Valkey- oder Redis OSS-Replikationsgruppen ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Suche nach Endpunkten für Valkey- oder Redis OSS-Replikationsgruppen (API) ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
Es wird empfohlen, den primären Knoten und die Read Replicas in verschiedenen Availability Zones zu erstellen. Dadurch wird der Grad der Fehlertoleranz erhöht.
## Testen des automatischen Failovers
Nachdem Sie den automatischen Failover aktiviert haben, können Sie ihn mithilfe der ElastiCache Konsole AWS CLI, der und der ElastiCache API testen.
Beim Testen ist Folgendes zu beachten:
+ Sie können diesen Vorgang verwenden, um das automatische Failover auf bis zu 15 Shards (in der ElastiCache API als Knotengruppen bezeichnet AWS CLI) in einem beliebigen Zeitraum von 24 Stunden zu testen.
+ Wenn Sie diese Operation für Shards in verschiedenen Clustern (in der API und CLI als Replikationsgruppen bezeichnet) aufrufen, können diese Aufrufe gleichzeitig erfolgen.
+ In einigen Fällen können Sie diesen Vorgang mehrmals auf verschiedenen Shards in derselben Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) aufrufen. In solchen Fällen muss die erste Knotenersetzung abgeschlossen werden, bevor ein nachfolgender Aufruf ausgeführt werden kann.
+ Um festzustellen, ob der Knotenaustausch abgeschlossen ist, überprüfen Sie die Ereignisse mithilfe der ElastiCache Amazon-Konsole AWS CLI, der oder der ElastiCache API. Suchen Sie nach den folgenden Ereignissen im Zusammenhang mit automatischem Failover, die hier nach der Wahrscheinlichkeit ihres Auftretens aufgelistet werden:
1. Meldung der Repliakationsgruppe: `Test Failover API called for node group `
1. Meldung des Cache-Clusters: `Failover from primary node to replica node completed`
1. Meldung der Repliakationsgruppe: `Failover from primary node to replica node completed`
1. Meldung des Cache-Clusters: `Recovering cache nodes `
1. Meldung des Cache-Clusters: `Finished recovery for cache nodes `
Weitere Informationen finden Sie hier:
+ [ElastiCache Ereignisse anzeigen](ECEvents.Viewing.md) im *ElastiCache -Benutzerhandbuch*
+ [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html) in der *ElastiCache -API-Referenz*
+ [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) in der *AWS CLI -Befehlsreferenz*.
+ Diese API wurde entwickelt, um das Verhalten Ihrer Anwendung im Falle eines ElastiCache Failovers zu testen. Sie wurde nicht als Betriebstool zum Einleiten eines Failovers konzipiert, um ein Problem mit dem Cluster zu beheben. Darüber hinaus AWS kann diese API unter bestimmten Bedingungen, z. B. bei großen Betriebsereignissen, blockiert werden.
**Topics**
+ [Testen des automatischen Failovers mit dem AWS-Managementkonsole](#auto-failover-test-con)
+ [Testen Sie den automatischen Failover mit dem AWS CLI](#auto-failover-test-cli)
+ [Testen Sie den automatischen Failover mithilfe der API ElastiCache](#auto-failover-test-api)
### Testen des automatischen Failovers mit dem AWS-Managementkonsole
Verwenden Sie das folgende Verfahren, um das automatische Failover mit der Konsole zu testen.
**So testen Sie das automatische Failover**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis** OSS aus.
1. Wählen Sie in der Clusterliste das Feld links neben dem Cluster aus, den Sie testen möchten. Dieser Cluster muss mindestens einen Read Replica-Knoten enthalten.
1. Bestätigen Sie im Bereich **Details**, dass dieser Cluster Multi-AZ-fähig ist. Wenn der Cluster nicht Multi-AZ-fähig ist, wählen Sie einen anderen Cluster aus oder bearbeiten Sie diesen Cluster so, dass Multi-AZ aktiviert wird. Weitere Informationen finden Sie unter [Unter Verwendung der ElastiCache AWS-Managementkonsole](Clusters.Modify.md#Clusters.Modify.CON).
![\[Bild: Detailbereich eines Multi-AZ-fähigen Clusters\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCache-AutoFailover-MultiAZ-Enabled.png)
1. Wählen Sie für Valkey oder Redis OSS (Clustermodus deaktiviert) den Namen des Clusters.
Gehen Sie für Valkey oder Redis OSS (Clustermodus aktiviert) wie folgt vor:
1. Wählen Sie den Cluster-Namen aus.
1. Wählen Sie auf der Seite **Shards** für den Shard (in API und CLI als Knotengruppe bezeichnet), auf dem das Failover getestet werden soll, den Namen des Shards aus.
1. Wählen Sie auf der Seite „Nodes“ **Failover Primary**.
1. Wählen Sie **Continue**, um ein Failover des primären Knotens auszuführen, oder wählen Sie **Cancel**, um die Operation ohne ein Failover des primären Knotens abzubrechen.
Während des Failover-Vorgangs zeigt die Konsole den Status des Knotens weiterhin als *available* an. Um den Status des Failover-Tests zu verfolgen, wählen Sie im Navigationsbereich der Konsole **Events** aus. Suchen Sie auf der Registerkarte **Events** nach Ereignissen, für die angegeben wird, dass Ihr Failover gestartet (`Test Failover API called`) und abgeschlossen (`Recovery completed`) wurde.
### Testen Sie den automatischen Failover mit dem AWS CLI
Mithilfe dieses Vorgangs können Sie das automatische Failover auf jedem Multi-AZ-fähigen Cluster testen. AWS CLI `test-failover`
**Parameter**
+ `--replication-group-id` – Erforderlich. Die Replikationsgruppe (auf der Konsole als Cluster bezeichnet), die getestet werden soll.
+ `--node-group-id` – Erforderlich. Der Name der Knotengruppe, auf der das automatische Failover getestet werden soll. Sie können maximal 15 Knotengruppen in einem fortlaufenden Zeitraum von 24 Stunden testen.
Im folgenden Beispiel wird der verwendet AWS CLI , um das automatische Failover für die Knotengruppe `redis00-0003` im Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) zu testen. `redis00`
**Example Testen des automatischen Failovers**
Für Linux, macOS oder Unix:
```
aws elasticache test-failover \
--replication-group-id redis00 \
--node-group-id redis00-0003
```
Für Windows:
```
aws elasticache test-failover ^
--replication-group-id redis00 ^
--node-group-id redis00-0003
```
Die Ausgabe des vorhergehenden Befehls sieht in etwa wie folgt aus.
```
{
"ReplicationGroup": {
"Status": "available",
"Description": "1 shard, 3 nodes (1 + 2 replicas)",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "redis1x3-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ClusterEnabled": false,
"ReplicationGroupId": "redis1x3",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"MultiAZ": "enabled",
"SnapshotWindow": "11:30-12:30",
"SnapshottingClusterId": "redis1x3-002",
"MemberClusters": [
"redis1x3-001",
"redis1x3-002",
"redis1x3-003"
],
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}
```
Verwenden Sie den Vorgang, um den Fortschritt Ihres Failovers zu verfolgen. AWS CLI `describe-events`
Weitere Informationen finden Sie hier:
+ [test-failover](https://docs.aws.amazon.com/cli/latest/reference/elasticache/test-failover.html) in der *AWS CLI -Befehlsreferenz*.
+ [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) in der *AWS CLI -Befehlsreferenz*.
### Testen Sie den automatischen Failover mithilfe der API ElastiCache
Mithilfe der ElastiCache API-Operation können Sie das automatische Failover auf jedem Cluster testen, für den Multi-AZ aktiviert ist. `TestFailover`
**Parameter**
+ `ReplicationGroupId` – Erforderlich. Die Replikationsgruppe (auf der Konsole als Cluster bezeichnet), die getestet werden soll.
+ `NodeGroupId` – Erforderlich. Der Name der Knotengruppe, auf der das automatische Failover getestet werden soll. Sie können maximal 15 Knotengruppen in einem fortlaufenden Zeitraum von 24 Stunden testen.
Das folgende Beispiel testet das automatische Failover auf der Knotengruppe `redis00-0003` in der Replikationsgruppe (auf der Konsole im Cluster) `redis00`.
**Example Testen des automatischen Failovers**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=TestFailover
&NodeGroupId=redis00-0003
&ReplicationGroupId=redis00
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20140401T192317Z
&X-Amz-Credential=
```
Verwenden Sie den ElastiCache `DescribeEvents` API-Vorgang, um den Fortschritt Ihres Failovers zu verfolgen.
Weitere Informationen finden Sie hier:
+ [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)in der *ElastiCache API-Referenz*
+ [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html)in der *ElastiCache API-Referenz*
## Einschränkungen bei Multi-AZ
Beachten Sie die folgenden Einschränkungen für Multi-AZ:
+ Multi-AZ wird auf Valkey und auf Redis OSS Version 2.8.6 und höher unterstützt.
+ Multi-AZ wird auf T1-Knotentypen nicht unterstützt.
+ Die OSS-Replikation von Valkey und Redis erfolgt asynchron. Daher kann es passieren, dass bei dem Failover eines primären Clusters auf ein Replikat aufgrund der Replikationsverzögerung eine kleine Datenmenge verloren geht.
Bei der Auswahl des Replikats, das zum primären Replikat heraufgestuft werden soll, wird das Replikat mit ElastiCache der geringsten Verzögerung bei der Replikation ausgewählt. Es wird also das neueste Replikat ausgewählt. Hierdurch kann die Menge verlorener Daten reduziert werden. Das Replikat mit der geringsten Replikationsverzögerung kann sich in der gleichen oder in einer anderen Availability Zone als der ausgefallene primäre Knoten befinden.
+ Wenn Sie Read Replicas auf Valkey- oder Redis OSS-Clustern mit deaktiviertem Clustermodus manuell zu primär heraufstufen, können Sie dies nur tun, wenn Multi-AZ und automatisches Failover deaktiviert sind. So stufen Sie eine Read Replica zum primären Knoten herauf:
1. Deaktivieren Sie Multi-AZ auf dem Cluster.
1. Deaktivieren Sie das automatische Failover auf dem Cluster. Sie können dies über die Konsole tun, indem Sie das Kontrollkästchen **Auto Failover für die Replikationsgruppe** deaktivieren. Sie können dies auch tun, AWS CLI indem Sie die `AutomaticFailoverEnabled` Eigenschaft `false` beim Aufrufen des `ModifyReplicationGroup` Vorgangs auf setzen.
1. Stufen Sie das Lesereplikat zum primären Knoten herauf.
1. Multi-AZ wieder aktivieren.
+ ElastiCache für Redis OSS schließen sich Multi-AZ und Append-Only File (AOF) gegenseitig aus. Wenn Sie eine dieser Funktionen aktivieren, kann die andere nicht aktiviert werden.
+ Der Ausfall eines Knotens kann durch den Ausfall einer gesamten Availability Zone verursacht werden. In diesem Fall wird das Replikat, das den ausgefallenen primären Knoten ersetzt, nur bei Verfügbarkeit der Availability Zone erstellt. Betrachten Sie beispielsweise eine Replikationsgruppe mit den primären Knoten in AZ-a und Replikaten in AZ-b und AZ-c. Wenn der primäre Konten ausfällt, wird das Replikat mit der geringsten Replikationsverzögerung wird zum primären Cluster heraufgestuft. ElastiCache Erstellt dann nur dann ein neues Replikat in AZ-a (wo sich die ausgefallene Primärreplikation befand), wenn AZ-a gesichert und verfügbar ist.
+ Ein vom Kunden initiierter Neustart des primären Clusters löst kein automatisches Failover aus. Andere Neustarts und Ausfälle hingegen lösen ein automatisches Failover aus.
+ Wenn der primäre Cluster neu gestartet wird, werden seine Daten gelöscht, wenn er wieder online ist. Wenn die Read Replicas den gelöschten primären Cluster sehen, löschen sie ihre Kopie der Daten, was zu Datenverlust führt.
+ Nachdem die Read Replica heraufgestuft wurde, werden die anderen Replikate mit dem neuen primären Cluster synchronisiert. Nach der ersten Synchronisierung wird der Inhalt der Replikate gelöscht, und sie synchronisieren die Daten aus dem neuen primären Cluster. Dieser Synchronisierungsvorgang führt zu einer kurzen Unterbrechung, bei der auf die Replikate nicht zugegriffen werden kann. Dieser Synchronisierungsvorgang bewirkt eine temporäre Zunahme der Arbeitslast auf dem primären Cluster, während er mit den Replikaten synchronisiert wird. Dieses Verhalten ist typisch für Valkey und Redis OSS und gilt nicht nur für Multi-AZ. ElastiCache Einzelheiten zu diesem Verhalten finden Sie unter [Replikation](http://valkey.io/topics/replication) auf der Valkey-Website.
**Wichtig**
Für Valkey 7.2.6 und höher oder Redis OSS Version 2.8.22 und höher können Sie keine externen Replikate erstellen.
Für Redis OSS-Versionen vor 2.8.22 empfehlen wir, kein externes Replikat mit einem Cluster zu verbinden, der Multi-AZ-fähig ist. ElastiCache Diese nicht unterstützte Konfiguration kann zu Problemen führen, die eine ordnungsgemäße Durchführung von Failover und Wiederherstellung ElastiCache verhindern. Um ein externes Replikat mit einem ElastiCache Cluster zu verbinden, stellen Sie sicher, dass Multi-AZ nicht aktiviert ist, bevor Sie die Verbindung herstellen.
# So werden Synchronisation und Backup implementiert
Alle unterstützten Versionen von Valkey und Redis OSS unterstützen Backup und Synchronisation zwischen dem Primär- und dem Replikatknoten. Die Art und Weise, wie Sicherung und Synchronisation implementiert werden, variiert jedoch je nach Version.
## Redis OSS Version 2.8.22 und höher
Bei der Redis OSS-Replikation in den Versionen 2.8.22 und höher können Sie zwischen zwei Methoden wählen. Weitere Informationen erhalten Sie unter [Redis OSS-Versionen vor 2.8.22](#Replication.Redis.Earlier2-8-22) und [Snapshot und Wiederherstellung](backups.md).
Wenn die Schreiblasten während des unvergabelten Vorgangs zu intensiv werden, werden Schreibvorgänge in den Cluster verzögert, damit sich nicht zu viele Änderungen anstauen und somit einen erfolgreichen Snapshot verhindern würden.
## Redis OSS-Versionen vor 2.8.22
Die Sicherung und Synchronisation von Redis OSS in Versionen vor 2.8.22 erfolgt in drei Schritten.
1. Vergabeln und serialisieren Sie die Clusterdaten als Hintergrundprozess auf dem Datenträger. Dadurch wird ein Snapshot erstellt. point-in-time
1. Akkumulieren Sie im Vordergrund ein Änderungsprotokoll im *Client-Ausgabepuffer*.
**Wichtig**
Wenn das Änderungsprotokoll die Größe des *Client-Ausgabepuffers* überschreitet, schlägt die Sicherung oder Synchronisierung fehl. Weitere Informationen finden Sie unter [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md).
1. Übertragen Sie schließlich die Cachedaten und anschließend das Änderungsprotokoll auf den Replikatknoten.
# Erstellen einer Valkey- oder Redis OSS-Replikationsgruppe
Es bieten sich Ihnen die folgenden Optionen für das Erstellen eines Clusters mit Replikatknoten. Eine Option gilt, wenn Sie bereits über einen verfügbaren Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) verfügen, der keinem Cluster zugeordnet ist, der über Replikate verfügt, die als primärer Knoten verwendet werden können. Die andere trifft zu, wenn Sie einen Primärknoten mit dem Cluster und Lesereplikaten erstellen müssen. Derzeit muss ein Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) von Grund auf neu erstellt werden.
**Option 1: [Erstellen einer Replikationsgruppe unter Verwendung eines vorhandenen Clusters](Replication.CreatingReplGroup.ExistingCluster.md)**
Verwenden Sie diese Option, um einen vorhandenen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) mit einem Knoten zu nutzen. Sie geben diesen vorhandenen Knoten als Primärknoten im neuen Cluster an und fügen dem Cluster dann einzeln 1 bis 5 Lesereplikate hinzu. Wenn der vorhandene Cluster aktiv ist, werden die Read Replicas bei ihrer Erstellung mit ihm synchronisiert. Siehe [Erstellen einer Replikationsgruppe unter Verwendung eines vorhandenen Clusters](Replication.CreatingReplGroup.ExistingCluster.md).
Sie können keinen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mithilfe eines vorhandenen Clusters erstellen. Informationen zum Erstellen eines Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert) (API/CLI: Replikationsgruppe) mithilfe der ElastiCache Konsole finden Sie unter. [Erstellen eines Valkey- oder Redis OSS-Clusters (Cluster-Modus aktiviert) (Konsole)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
**Option 2: [Eine Valkey- oder Redis OSS-Replikationsgruppe von Grund auf neu erstellen](Replication.CreatingReplGroup.NoExistingCluster.md)**
Verwenden Sie diese Option, wenn Sie noch keinen verfügbaren Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) haben, den Sie als primären Knoten des Clusters verwenden können, oder wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) erstellen möchten. Siehe [Eine Valkey- oder Redis OSS-Replikationsgruppe von Grund auf neu erstellen](Replication.CreatingReplGroup.NoExistingCluster.md).
# Erstellen einer Replikationsgruppe unter Verwendung eines vorhandenen Clusters
Das folgende Verfahren fügt Ihrem Valkey- oder Redis OSS-Single-Node-Cluster (Clustermodus deaktiviert) eine Replikationsgruppe hinzu, die erforderlich ist, um Ihren Cluster auf die neueste Version von Valkey zu aktualisieren. Dabei handelt es sich um ein direktes Verfahren, das keine Ausfallzeiten und keinen Datenverlust beinhaltet. Wenn Sie eine Replikationsgruppe für Ihren Cluster mit einem Knoten erstellen, wird der Knoten des Clusters zum primären Knoten im neuen Cluster. Wenn Sie keinen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) haben, den Sie als primären Cluster verwenden können, finden Sie weitere Informationen unter. [Eine Valkey- oder Redis OSS-Replikationsgruppe von Grund auf neu erstellen](Replication.CreatingReplGroup.NoExistingCluster.md)
Ein verfügbarer Cluster ist ein vorhandener Valkey- oder Redis OSS-Cluster mit einem Knoten. Derzeit unterstützt Valkey oder Redis OSS (Clustermodus aktiviert) die Erstellung eines Clusters mit Replikaten unter Verwendung eines verfügbaren Clusters mit einem einzelnen Knoten nicht. Wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) erstellen möchten, finden Sie weitere Informationen unter. [Erstellen eines Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert) (Konsole)](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON)
## Erstellen einer Replikationsgruppe mithilfe eines vorhandenen Clusters (Konsole)
Weitere Informationen finden Sie im Thema [Mit dem ElastiCache AWS-Managementkonsole](Clusters.AddNode.md#Clusters.AddNode.CON).
## Erstellen einer Replikationsgruppe mithilfe eines verfügbaren Valkey- oder Redis OSS-Clusters ()AWS CLI
Es gibt zwei Schritte zum Erstellen einer Replikationsgruppe mit Read Replicas, wenn Sie einen verfügbaren Valkey- oder Redis OSS-Cache-Cluster als Primär-Cache-Cluster verwenden, wenn Sie den verwenden.AWS CLI
Wenn AWS CLI Sie den verwenden, erstellen Sie eine Replikationsgruppe, indem Sie den verfügbaren Standalone-Knoten als primären Knoten des Clusters `--primary-cluster-id` und die Anzahl der Knoten, die Sie im Cluster haben möchten, mit dem CLI-Befehl angeben`create-replication-group`. Schließen Sie die folgenden Parameter ein.
**--replication-group-id**
Der Name der zu erstellenden Replikationsgruppe. Der Wert dieses Parameters wird als Basis für die Namen der hinzugefügten Knoten mit einer fortlaufenden 3-stelligen Nummer am Ende der `--replication-group-id` verwendet. Beispiel, `sample-repl-group-001`.
Die Benennungsbeschränkungen für Valkey oder Redis OSS (Clustermodus deaktiviert) für Replikationsgruppen lauten wie folgt:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
**--replication-group-description**
Beschreibung der Replikationsgruppe.
**--num-node-groups**
Die Anzahl der Knoten, die Sie in diesem Cluster benötigen. Dieser Wert umfasst den primären Knoten. Dieser Parameter hat einen Maximalwert von sechs.
**--primary-cluster-id**
Der Name des Knotens des verfügbaren Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert), den Sie als primärer Knoten in dieser Replikationsgruppe verwenden möchten.
Mit dem folgenden Befehl wird die Replikationsgruppe erstellt, `sample-repl-group` wobei der verfügbare Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) `redis01` als primärer Knoten der Replikationsgruppe verwendet wird. Er erstellt 2 neue Knoten, bei denen es sich um Read Replicas handelt. Die Einstellungen von `redis01` (d. h. Parametergruppe, Sicherheitsgruppe, Knotentyp, Engine-Version usw.) werden auf alle Knoten in der Replikationsgruppe angewendet.
Für Linux, macOS oder Unix:
```
aws elasticache create-replication-group \
--replication-group-id sample-repl-group \
--replication-group-description "demo cluster with replicas" \
--num-cache-clusters 3 \
--primary-cluster-id redis01
```
Für Windows:
```
aws elasticache create-replication-group ^
--replication-group-id sample-repl-group ^
--replication-group-description "demo cluster with replicas" ^
--num-cache-clusters 3 ^
--primary-cluster-id redis01
```
Weitere Informationen und Parameter, die Sie möglicherweise verwenden möchten, finden Sie im AWS CLI Thema. [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
**Als Nächstes Hinzufügen von Read Replicas zur Replikationsgruppe**
Nachdem die Replikationsgruppe erstellt wurde, fügen Sie ihr mit dem Befehl `create-cache-cluster` eine bis fünf Read Replicas hinzu und schließen Sie unbedingt die folgenden Parameter ein.
**--cache-cluster-id**
Der Name des Clusters, den Sie zur Replikationsgruppe hinzufügen.
Für die Benennung von Clustern gelten die folgenden Einschränkungen:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
**--replication-group-id**
Der Name der Replikationsgruppe, zu der Sie diesen Cluster hinzufügen.
Wiederholen Sie diesen Befehl für jede Read Replica, die Sie zur Replikationsgruppe hinzufügen möchten, und ändern Sie dabei nur den Wert des Parameters `--cache-cluster-id`.
**Anmerkung**
Denken Sie daran, dass eine Replikationsgruppe über nicht mehr als fünf Read Replicas verfügen kann. Bei dem Versuch, einer Replikationsgruppe mit bereits fünf Read Replicas eine weitere Read Replica hinzuzufügen, schlägt die Operation fehl.
Der folgende Code fügt die Read Replica `my-replica01` zur Replikationsgruppe `sample-repl-group` hinzu. Die Einstellungen des primären Clusters – Parametergruppe, Sicherheitsgruppe, Knotentyp usw. – werden auf Knoten angewendet, sobald sie der Replikationsgruppe hinzugefügt werden.
Für Linux, macOS oder Unix:
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-replica01 \
--replication-group-id sample-repl-group
```
Für Windows:
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-replica01 ^
--replication-group-id sample-repl-group
```
Die Ausgabe dieses Befehls sieht in etwa folgendermaßen aus.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "demo cluster with replicas",
"ClusterEnabled": false,
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "00:00-01:00",
"SnapshottingClusterId": "redis01",
"MemberClusters": [
"sample-repl-group-001",
"sample-repl-group-002",
"redis01"
],
"CacheNodeType": "cache.m4.large",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}
```
Weitere Informationen finden Sie in den folgenden AWS CLI Themen:
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
+ [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)
## Hinzufügen von Replikaten zu einem eigenständigen Valkey- oder Redis OSS-Cluster (Cluster Mode Disabled) (API) ElastiCache
Wenn Sie die ElastiCache API verwenden, erstellen Sie eine Replikationsgruppe, die den verfügbaren Standalone-Knoten als primären Knoten des Clusters `PrimaryClusterId` und die Anzahl der Knoten, die Sie im Cluster haben möchten, mit dem CLI-Befehl, angeben`CreateReplicationGroup`. Schließen Sie die folgenden Parameter ein.
**ReplicationGroupId**
Der Name der zu erstellenden Replikationsgruppe. Der Wert dieses Parameters wird als Basis für die Namen der hinzugefügten Knoten mit einer fortlaufenden 3-stelligen Nummer am Ende der `ReplicationGroupId` verwendet. Beispiel, `sample-repl-group-001`.
Die Benennungsbeschränkungen für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert) lauten wie folgt:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
**ReplicationGroupDescription**
Beschreibung des Clusters mit Replikaten.
**NumCacheClusters**
Die Anzahl der Knoten, die Sie in diesem Cluster benötigen. Dieser Wert umfasst den primären Knoten. Dieser Parameter hat einen Maximalwert von sechs.
**PrimaryClusterId**
Der Name des verfügbaren Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert), den Sie als primärer Knoten in diesem Cluster verwenden möchten.
Der folgende Befehl erstellt den Cluster mit Replikaten, `sample-repl-group` wobei der verfügbare Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) `redis01` als primärer Knoten der Replikationsgruppe verwendet wird. Er erstellt 2 neue Knoten, bei denen es sich um Read Replicas handelt. Die Einstellungen von `redis01` (d. h. Parametergruppe, Sicherheitsgruppe, Knotentyp, Engine-Version usw.) werden auf alle Knoten in der Replikationsgruppe angewendet.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&Engine=redis
&EngineVersion=6.0
&ReplicationGroupDescription=Demo%20cluster%20with%20replicas
&ReplicationGroupId=sample-repl-group
&PrimaryClusterId=redis01
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie in den ElastiCache APL-Themen:
+ [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
+ [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
**Als Nächstes Hinzufügen von Read Replicas zur Replikationsgruppe**
Nachdem die Replikationsgruppe erstellt wurde, fügen Sie ihr mit der Operation `CreateCacheCluster` eine bis fünf Read Replicas hinzu und schließen Sie unbedingt die folgenden Parameter ein.
**CacheClusterId**
Der Name des Clusters, den Sie zur Replikationsgruppe hinzufügen.
Für die Benennung von Clustern gelten die folgenden Einschränkungen:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
**ReplicationGroupId**
Der Name der Replikationsgruppe, zu der Sie diesen Cluster hinzufügen.
Wiederholen Sie diese Operation für jede Read Replica, die Sie zur Replikationsgruppe hinzufügen möchten, und ändern Sie dabei nur den Wert des Parameters `CacheClusterId`.
Der folgende Code fügt die Lesereplikate `myReplica01` der Replikationsgruppe `myReplGroup` hinzu. Die Einstellungen des primären Clusters – Parametergruppe, Sicherheitsgruppe, Knotentyp usw. – werden auf Knoten angewendet, wenn sie der Replikationsgruppe hinzugefügt werden.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=myReplica01
&ReplicationGroupId=myReplGroup
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2015-02-02
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Credential=[your-access-key-id]/20150202/us-west-2/elasticache/aws4_request
&X-Amz-Date=20150202T170651Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=[signature-value]
```
Weitere Informationen und Parameter, die Sie möglicherweise verwenden möchten, finden Sie im ElastiCache API-Thema[CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html).
# Eine Valkey- oder Redis OSS-Replikationsgruppe von Grund auf neu erstellen
Im Folgenden erfahren Sie, wie Sie eine Valkey- oder Redis OSS-Replikationsgruppe erstellen, ohne einen vorhandenen Valkey- oder Redis OSS-Cluster als primären Cluster zu verwenden. Sie können mithilfe der Konsole, der oder der API eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) oder Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) von Grund auf neu erstellen. ElastiCache AWS CLI ElastiCache
Bevor Sie fortfahren, entscheiden Sie, ob Sie eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) oder eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) erstellen möchten. Hilfreiche Informationen zur Entscheidung finden Sie unter [Replikation: Valkey- und Redis OSS-Clustermodus deaktiviert oder aktiviert](Replication.Redis-RedisCluster.md).
**Topics**
+ [Eine Valkey- oder Redis OSS-Replikationsgruppe (Cluster Mode Disabled) von Grund auf neu erstellen](Replication.CreatingReplGroup.NoExistingCluster.Classic.md)
+ [Eine Replikationsgruppe in Valkey oder Redis OSS (Cluster Mode Enabled) von Grund auf neu erstellen](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md)
# Eine Valkey- oder Redis OSS-Replikationsgruppe (Cluster Mode Disabled) von Grund auf neu erstellen
Sie können mithilfe der ElastiCache Konsole, der oder der API eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) von Grund auf neu erstellen. AWS CLI ElastiCache Eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) besteht immer aus einer Knotengruppe, einem primären Cluster und bis zu fünf Read Replicas. Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert) unterstützen die Partitionierung Ihrer Daten nicht.
**Anmerkung**
Das node/shard Limit kann auf maximal 500 pro Cluster erhöht werden. Informationen zum Anfordern einer Limiterhöhung finden Sie unter [AWS Service-Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html), wenn Sie den Instance-Typ in die Anfrage eingeben.
Um eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) von Grund auf neu zu erstellen, wählen Sie einen der folgenden Ansätze:
## Eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) von Grund auf neu erstellen ()AWS CLI
Das folgende Verfahren erstellt eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) mithilfe von. AWS CLI
Wenn Sie eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) von Grund auf neu erstellen, erstellen Sie die Replikationsgruppe und alle ihre Knoten mit einem einzigen Befehlsaufruf. AWS CLI `create-replication-group` Schließen Sie die folgenden Parameter ein.
**--replication-group-id**
Der Name der zu erstellenden Replikationsgruppe.
Die Benennungsbeschränkungen für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert) lauten wie folgt:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
**--replication-group-description**
Beschreibung der Replikationsgruppe.
**--num-cache-clusters**
Die Gesamtzahl von Knoten, die Sie mit dieser Replikationsgruppe erstellen möchten, primäre Knoten und Read Replicas kombiniert.
Wenn Sie Multi-AZ (`--automatic-failover-enabled`) aktivieren, muss der Wert für `--num-cache-clusters` mindestens 2 sein.
**--cache-node-type**
Der Knotentyp für jeden Knoten in der Replikationsgruppe.
ElastiCache unterstützt die folgenden Knotentypen. Im Allgemeinen bieten die Typen der aktuellen Generation im Vergleich zu den entsprechenden Typen der vorherigen Generationen mehr Speicher und Rechenleistung zu niedrigeren Kosten.
Weitere Informationen zu Leistungsdetails für jeden Knotentyp finden Sie unter [ EC2 Amazon-Instanztypen](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Legen Sie diesen Parameter fest, wenn Sie einen R6gd-Knotentyp verwenden. Wenn Sie kein Daten-Tiering verwenden möchten, legen Sie `--no-data-tiering-enabled` fest. Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
**--cache-parameter-group**
Geben Sie eine Parametergruppe an, die Ihrer Engine-Version entspricht. Wenn Sie Redis OSS 3.2.4 oder höher ausführen, geben Sie die Parametergruppe oder eine davon abgeleitete `default.redis3.2` Parametergruppe an, um eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) `default.redis3.2` zu erstellen. Weitere Informationen finden Sie unter [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis).
**--Netzwerktyp**
Entweder `ipv4`, `ipv6` oder `dual-stack`. Wenn Sie Dual-Stack auswählen, müssen Sie den `--IpDiscovery`-Parameter entweder auf `ipv4` oder `ipv6` festlegen.
**--engine**
redis
**--engine-version**
Wählen Sie für den umfangreichsten Satz von Funktionen die neueste Engine-Version aus.
Die Namen der Knoten werden vom Namen der Replikationsgruppe abgeleitet, indem `-00`*\$1*an den Namen der Replikationsgruppe angehängt wird. Wenn Sie z. B. den Replikationsgruppennamen `myReplGroup` verwenden, lauten die Namen des primären Knotens `myReplGroup-001` und der Read Replicas `myReplGroup-002` bis `myReplGroup-006`.
Wenn Sie die Verschlüsselung während der Übertragung oder im Ruhezustand für diese Replikationsgruppe aktivieren möchten, fügen Sie einen oder beide der Parameter `--transit-encryption-enabled` oder `--at-rest-encryption-enabled` hinzu und erfüllen die folgenden Bedingungen.
+ In Ihrer Replikationsgruppe muss Redis OSS Version 3.2.6 oder 4.0.10 ausgeführt werden.
+ Die Replikationsgruppe muss in einer Amazon VPC erstellt werden.
+ Sie müssen außerdem den Parameter `--cache-subnet-group` einbinden.
+ Sie müssen auch den Parameter `--auth-token` einbinden, mit dem vom Kunden angegebenen Zeichenfolgenwert für Ihr AUTH-Token (Passwort), das für Operationen auf dieser Replikationsgruppe benötigt wird.
Der folgende Vorgang erstellt eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) `sample-repl-group` mit drei Knoten, einem primären und zwei Replikaten.
Für Linux, macOS oder Unix:
```
aws elasticache create-replication-group \
--replication-group-id sample-repl-group \
--replication-group-description "Demo cluster with replicas" \
--num-cache-clusters 3 \
--cache-node-type cache.m4.large \
--engine redis
```
Für Windows:
```
aws elasticache create-replication-group ^
--replication-group-id sample-repl-group ^
--replication-group-description "Demo cluster with replicas" ^
--num-cache-clusters 3 ^
--cache-node-type cache.m4.large ^
--engine redis
```
Die Ausgabe dieses Befehls sieht in etwa wie folgt aus:
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Demo cluster with replicas",
"ClusterEnabled": false,
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 0,
"AutomaticFailover": "disabled",
"SnapshotWindow": "01:30-02:30",
"MemberClusters": [
"sample-repl-group-001",
"sample-repl-group-002",
"sample-repl-group-003"
],
"CacheNodeType": "cache.m4.large",
"DataTiering": "disabled",
"PendingModifiedValues": {}
}
}
```
Weitere Informationen und Parameter, die Sie möglicherweise verwenden möchten, finden Sie im Thema. AWS CLI [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
## Eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) von Grund auf neu erstellen (ElastiCache API)
Mit dem folgenden Verfahren wird mithilfe der API eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) erstellt. ElastiCache
Wenn Sie eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) von Grund auf neu erstellen, erstellen Sie die Replikationsgruppe und alle ihre Knoten mit einem einzigen Aufruf des API-Vorgangs. ElastiCache `CreateReplicationGroup` Schließen Sie die folgenden Parameter ein.
**ReplicationGroupId**
Der Name der zu erstellenden Replikationsgruppe.
Die Benennungsbeschränkungen für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus aktiviert) lauten wie folgt:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
**ReplicationGroupDescription**
Ihre Beschreibung der Replikationsgruppe.
**NumCacheClusters**
Die Gesamtzahl der Knoten, die Sie mit dieser Replikationsgruppe erstellen möchten, primäre Knoten und Read Replicas kombiniert.
Wenn Sie Multi-AZ (`AutomaticFailoverEnabled=true`) aktivieren, muss der Wert für `NumCacheClusters` mindestens 2 sein.
**CacheNodeType**
Der Knotentyp für jeden Knoten in der Replikationsgruppe.
ElastiCache unterstützt die folgenden Knotentypen. Im Allgemeinen bieten die Typen der aktuellen Generation im Vergleich zu den entsprechenden Typen der vorherigen Generationen mehr Speicher und Rechenleistung zu niedrigeren Kosten.
Weitere Informationen zu Leistungsdetails für jeden Knotentyp finden Sie unter [ EC2 Amazon-Instanztypen](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Legen Sie diesen Parameter fest, wenn Sie einen R6gd-Knotentyp verwenden. Wenn Sie kein Daten-Tiering verwenden möchten, legen Sie `--no-data-tiering-enabled` fest. Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
**CacheParameterGroup**
Geben Sie eine Parametergruppe an, die Ihrer Engine-Version entspricht. Wenn Sie Redis OSS 3.2.4 oder höher ausführen, geben Sie die Parametergruppe oder eine davon abgeleitete `default.redis3.2` Parametergruppe an, um eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) `default.redis3.2` zu erstellen. Weitere Informationen finden Sie unter [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis).
**--Netzwerktyp**
Entweder `ipv4`, `ipv` oder `dual-stack`. Wenn Sie Dual-Stack auswählen, müssen Sie den `--IpDiscovery`-Parameter entweder auf `ipv4` oder `ipv6` festlegen.
**Engine**
redis
**EngineVersion**
6.0
Die Namen der Knoten werden vom Namen der Replikationsgruppe abgeleitet, indem `-00`*\$1*an den Namen der Replikationsgruppe angehängt wird. Wenn Sie z. B. den Replikationsgruppennamen `myReplGroup` verwenden, lauten die Namen des primären Knotens `myReplGroup-001` und der Read Replicas `myReplGroup-002` bis `myReplGroup-006`.
Wenn Sie die Verschlüsselung während der Übertragung oder im Ruhezustand für diese Replikationsgruppe aktivieren möchten, fügen Sie einen oder beide der Parameter `TransitEncryptionEnabled=true` oder `AtRestEncryptionEnabled=true` hinzu und erfüllen die folgenden Bedingungen.
+ In Ihrer Replikationsgruppe muss Redis OSS Version 3.2.6 oder 4.0.10 ausgeführt werden.
+ Die Replikationsgruppe muss in einer Amazon VPC erstellt werden.
+ Sie müssen außerdem den Parameter `CacheSubnetGroup` einbinden.
+ Sie müssen auch den Parameter `AuthToken` einbinden, mit dem vom Kunden angegebenen Zeichenfolgenwert für Ihr AUTH-Token (Passwort), das für Operationen auf dieser Replikationsgruppe benötigt wird.
Der folgende Vorgang erstellt die Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) `myReplGroup` mit drei Knoten, einem primären und zwei Replikaten.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&CacheNodeType=cache.m4.large
&CacheParameterGroup=default.redis6.x
&Engine=redis
&EngineVersion=6.0
&NumCacheClusters=3
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen und Parameter, die Sie möglicherweise verwenden möchten, finden Sie im ElastiCache API-Thema. [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
# Eine Replikationsgruppe in Valkey oder Redis OSS (Cluster Mode Enabled) von Grund auf neu erstellen
Sie können einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) (API/CLI: *Replikationsgruppe*) mithilfe der ElastiCache Konsole, der oder der AWS CLI API erstellen. ElastiCache Eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) hat 1 bis 500 Shards (API/CLI: Knotengruppen), einen primären Knoten in jedem Shard und bis zu 5 Read Replicas in jedem Shard. 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 auf maximal 500 pro Cluster erhöht werden, wenn die Valkey- oder Redis-OSS-Engine-Version 5.0.6 oder höher ist. 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](SubnetGroups.Creating.md).
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](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) und wählen Sie den Limittyp **Nodes per cluster per instance type**.
**Topics**
+ [Verwenden der Konsole ElastiCache](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON)
+ [Eine Valkey- oder Redis OSS-Replikationsgruppe (Cluster Mode Enabled) von Grund auf neu erstellen ()AWS CLI](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CLI)
+ [Eine Replikationsgruppe in Valkey oder Redis OSS (Cluster Mode Enabled) von Grund auf neu erstellen (ElastiCache API)](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.API)
## Erstellen eines Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert) (Konsole)
Informationen zum Erstellen eines Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert) finden Sie unter. [Erstellen eines Valkey- oder Redis OSS-Clusters (Cluster-Modus aktiviert) (Konsole)](Clusters.Create.md#Clusters.Create.CON.RedisCluster) Stellen Sie sicher, dass der Cluster-Modus aktiviert ist, **Cluster-Modus aktiviert (aufskalieren)** und dass mindestens zwei Shards und ein Replikationsknoten in jedem angegeben sind.
## Eine Valkey- oder Redis OSS-Replikationsgruppe (Cluster Mode Enabled) von Grund auf neu erstellen ()AWS CLI
Das folgende Verfahren erstellt eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) mithilfe von. AWS CLI
Wenn Sie eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) von Grund auf neu erstellen, erstellen Sie die Replikationsgruppe und alle ihre Knoten mit einem einzigen Befehlsaufruf. AWS CLI `create-replication-group` Schließen Sie die folgenden Parameter ein.
**--replication-group-id**
Der Name der zu erstellenden Replikationsgruppe.
Die Benennungsbeschränkungen für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus aktiviert) lauten wie folgt:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
**--replication-group-description**
Beschreibung der Replikationsgruppe.
**--cache-node-type**
Der Knotentyp für jeden Knoten in der Replikationsgruppe.
ElastiCache unterstützt die folgenden Knotentypen. Im Allgemeinen bieten die Typen der aktuellen Generation im Vergleich zu den entsprechenden Typen der vorherigen Generationen mehr Speicher und Rechenleistung zu niedrigeren Kosten.
Weitere Informationen zu Leistungsdetails für jeden Knotentyp finden Sie unter [ EC2 Amazon-Instanztypen](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Legen Sie diesen Parameter fest, wenn Sie einen R6gd-Knotentyp verwenden. Wenn Sie kein Daten-Tiering verwenden möchten, legen Sie `--no-data-tiering-enabled` fest. Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
**--cache-parameter-group**
Geben Sie die `default.redis6.x.cluster.on` Parametergruppe oder eine davon abgeleitete Parametergruppe an, um eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) `default.redis6.x.cluster.on` zu erstellen. Weitere Informationen finden Sie unter [Änderungen der Parameter in Redis OSS 6.x](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
**--engine**
redis
**--engine-version**
3.2.4
**--num-node-groups**
Die Anzahl der Knotengruppen in dieser Replikationsgruppe. Gültige Werte sind 1 bis 500.
Das node/shard Limit kann auf maximal 500 pro Cluster erhöht werden. Um eine Limiterhöhung anzufordern, lesen Sie [AWS Service Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) und wählen Sie den Limittyp "Knoten per Cluster per Instance-Typ".
**--replicas-per-node-group**
Die Anzahl der Replikat-Knoten in jeder Knotengruppe. Gültige Werte sind 0 bis 5.
**--Netzwerktyp**
Entweder `ipv4`, `ipv` oder `dual-stack`. Wenn Sie Dual-Stack auswählen, müssen Sie den `--IpDiscovery`-Parameter entweder auf `ipv4` oder `ipv6` festlegen.
Wenn Sie die Verschlüsselung während der Übertragung oder im Ruhezustand für diese Replikationsgruppe aktivieren möchten, fügen Sie einen oder beide der Parameter `--transit-encryption-enabled` oder `--at-rest-encryption-enabled` hinzu und erfüllen die folgenden Bedingungen.
+ In Ihrer Replikationsgruppe muss Redis OSS Version 3.2.6 oder 4.0.10 ausgeführt werden.
+ Die Replikationsgruppe muss in einer Amazon VPC erstellt werden.
+ Sie müssen außerdem den Parameter `--cache-subnet-group` einbinden.
+ Sie müssen auch den Parameter `--auth-token` einbinden, mit dem vom Kunden angegebenen Zeichenfolgenwert für Ihr AUTH-Token (Passwort), das für Operationen auf dieser Replikationsgruppe benötigt wird.
Der folgende Vorgang erstellt die Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) `sample-repl-group` mit drei Knoten groups/shards (--num-node-groups) mit jeweils drei Knoten, einem primären und zwei Read Replicas (--). replicas-per-node-group
Für Linux, macOS oder Unix:
```
aws elasticache create-replication-group \
--replication-group-id sample-repl-group \
--replication-group-description "Demo cluster with replicas" \
--num-node-groups 3 \
--replicas-per-node-group 2 \
--cache-node-type cache.m4.large \
--engine redis \
--security-group-ids SECURITY_GROUP_ID \
--cache-subnet-group-name SUBNET_GROUP_NAME>
```
Für Windows:
```
aws elasticache create-replication-group ^
--replication-group-id sample-repl-group ^
--replication-group-description "Demo cluster with replicas" ^
--num-node-groups 3 ^
--replicas-per-node-group 2 ^
--cache-node-type cache.m4.large ^
--engine redis ^
--security-group-ids SECURITY_GROUP_ID ^
--cache-subnet-group-name SUBNET_GROUP_NAME>
```
Der voranstehende Befehl erzeugt die folgende Ausgabe.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Demo cluster with replicas",
"ReplicationGroupId": "sample-repl-group",
"SnapshotRetentionLimit": 0,
"AutomaticFailover": "enabled",
"SnapshotWindow": "05:30-06:30",
"MemberClusters": [
"sample-repl-group-0001-001",
"sample-repl-group-0001-002",
"sample-repl-group-0001-003",
"sample-repl-group-0002-001",
"sample-repl-group-0002-002",
"sample-repl-group-0002-003",
"sample-repl-group-0003-001",
"sample-repl-group-0003-002",
"sample-repl-group-0003-003"
],
"PendingModifiedValues": {}
}
}
```
Wenn Sie eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) von Grund auf neu erstellen, können Sie jeden Shard im Cluster mithilfe des `--node-group-configuration` Parameters konfigurieren, wie im folgenden Beispiel gezeigt, der zwei Knotengruppen konfiguriert (Konsole: Shards). Der erste Shard verfügt über zwei Knoten, einen primären Knoten und eine Read Replica. Der zweite Shard verfügt über drei Knoten, einen primären Knoten und zwei Read Replicas.
**--node-group-configuration**
Die Konfiguration jeder Knotengruppe. Der Parameter `--node-group-configuration` besteht aus den folgenden Feldern.
+ `PrimaryAvailabilityZone` – Die Availability Zone, in der sich der Primärknoten dieser Knotengruppe befindet. Wenn dieser Parameter weggelassen wird, wird die Availability Zone ElastiCache für den primären Knoten ausgewählt.
**Beispiel:** us-west-2a.
+ `ReplicaAvailabilityZones` – Eine durch Kommas getrennte Liste von Availability Zones, in denen sich die Lesereplikate befinden. Die Anzahl der Availability Zones in dieser Liste muss mit dem Wert von `ReplicaCount` übereinstimmen. Wenn dieser Parameter weggelassen wird, werden die ElastiCache Availability Zones für die Replikatknoten ausgewählt.
**Beispiel:** „us-west-2a,us-west-2b,us-west-2c“
+ `ReplicaCount` – Die Anzahl der Replikatknoten in dieser Knotengruppe.
+ `Slots` – Eine Zeichenfolge, die den Keyspace für die Knotengruppe angibt. Das Format für die Zeichenfolge ist `startKey-endKey`. Wenn dieser Parameter weggelassen wird, werden ElastiCache die Schlüssel gleichmäßig auf die Knotengruppen verteilt.
**Beispiel:** "0–4999"
Der folgende Vorgang erstellt die Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) `new-group` mit zwei Knotengruppen/Shards (). `--num-node-groups` Im Gegensatz zum voranstehenden Beispiel sind die einzelnen Knotengruppen unterschiedlich konfiguriert (`--node-group-configuration`).
Für Linux, macOS oder Unix:
```
aws elasticache create-replication-group \
--replication-group-id new-group \
--replication-group-description "Sharded replication group" \
--engine redis \
--snapshot-retention-limit 8 \
--cache-node-type cache.m4.medium \
--num-node-groups 2 \
--node-group-configuration \
"ReplicaCount=1,Slots=0-8999,PrimaryAvailabilityZone='us-east-1c',ReplicaAvailabilityZones='us-east-1b'" \
"ReplicaCount=2,Slots=9000-16383,PrimaryAvailabilityZone='us-east-1a',ReplicaAvailabilityZones='us-east-1a','us-east-1c'"
```
Für Windows:
```
aws elasticache create-replication-group ^
--replication-group-id new-group ^
--replication-group-description "Sharded replication group" ^
--engine redis ^
--snapshot-retention-limit 8 ^
--cache-node-type cache.m4.medium ^
--num-node-groups 2 ^
--node-group-configuration \
"ReplicaCount=1,Slots=0-8999,PrimaryAvailabilityZone='us-east-1c',ReplicaAvailabilityZones='us-east-1b'" \
"ReplicaCount=2,Slots=9000-16383,PrimaryAvailabilityZone='us-east-1a',ReplicaAvailabilityZones='us-east-1a','us-east-1c'"
```
Die voranstehende Operation erzeugt die folgende Ausgabe.
```
{
"ReplicationGroup": {
"Status": "creating",
"Description": "Sharded replication group",
"ReplicationGroupId": "rc-rg",
"SnapshotRetentionLimit": 8,
"AutomaticFailover": "enabled",
"SnapshotWindow": "10:00-11:00",
"MemberClusters": [
"rc-rg-0001-001",
"rc-rg-0001-002",
"rc-rg-0002-001",
"rc-rg-0002-002",
"rc-rg-0002-003"
],
"PendingModifiedValues": {}
}
}
```
Weitere Informationen und Parameter, die Sie möglicherweise verwenden möchten, finden Sie im Thema. AWS CLI [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
## Eine Replikationsgruppe in Valkey oder Redis OSS (Cluster Mode Enabled) von Grund auf neu erstellen (ElastiCache API)
Das folgende Verfahren erstellt mithilfe der API eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert). ElastiCache
Wenn Sie eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) von Grund auf neu erstellen, erstellen Sie die Replikationsgruppe und alle ihre Knoten mit einem einzigen Aufruf der API-Operation. ElastiCache `CreateReplicationGroup` Schließen Sie die folgenden Parameter ein.
**ReplicationGroupId**
Der Name der zu erstellenden Replikationsgruppe.
Die Benennungsbeschränkungen für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus aktiviert) lauten wie folgt:
+ Er muss 1-40 alphanumerische Zeichen oder Bindestriche enthalten.
+ Er muss mit einem Buchstaben beginnen.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
**ReplicationGroupDescription**
Beschreibung der Replikationsgruppe.
**NumNodeGroups**
Die Anzahl der Knotengruppen, die Sie mit dieser Replikationsgruppe erstellen möchten. Gültige Werte sind 1 bis 500.
**ReplicasPerNodeGroup**
Die Anzahl der Replikat-Knoten in jeder Knotengruppe. Gültige Werte sind 1 bis 5.
**NodeGroupConfiguration**
Die Konfiguration jeder Knotengruppe. Der Parameter `NodeGroupConfiguration` besteht aus den folgenden Feldern.
+ `PrimaryAvailabilityZone` – Die Availability Zone, in der sich der Primärknoten dieser Knotengruppe befindet. Wenn dieser Parameter weggelassen wird, wird die ElastiCache Availability Zone für den primären Knoten ausgewählt.
**Beispiel:** us-west-2a.
+ `ReplicaAvailabilityZones` – Eine Liste der Availability Zones, in denen sich die Lesereplikate befinden. Die Anzahl der Availability Zones in dieser Liste muss mit dem Wert von `ReplicaCount` übereinstimmen. Wenn dieser Parameter weggelassen wird, werden die ElastiCache Availability Zones für die Replikatknoten ausgewählt.
+ `ReplicaCount` – Die Anzahl der Replikatknoten in dieser Knotengruppe.
+ `Slots` – Eine Zeichenfolge, die den Keyspace für die Knotengruppe angibt. Das Format für die Zeichenfolge ist `startKey-endKey`. Wenn dieser Parameter weggelassen wird, werden ElastiCache die Schlüssel gleichmäßig auf die Knotengruppen verteilt.
**Beispiel:** "0–4999"
**CacheNodeType**
Der Knotentyp für jeden Knoten in der Replikationsgruppe.
ElastiCache unterstützt die folgenden Knotentypen. Im Allgemeinen bieten die Typen der aktuellen Generation im Vergleich zu den entsprechenden Typen der vorherigen Generationen mehr Speicher und Rechenleistung zu niedrigeren Kosten.
Weitere Informationen zu Leistungsdetails für jeden Knotentyp finden Sie unter [ EC2 Amazon-Instanztypen](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Legen Sie diesen Parameter fest, wenn Sie einen R6gd-Knotentyp verwenden. Wenn Sie kein Daten-Tiering verwenden möchten, legen Sie `--no-data-tiering-enabled` fest. Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
**CacheParameterGroup**
Geben Sie die `default.redis6.x.cluster.on` Parametergruppe oder eine davon abgeleitete Parametergruppe an, um eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) `default.redis6.x.cluster.on` zu erstellen. Weitere Informationen finden Sie unter [Änderungen der Parameter in Redis OSS 6.x](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
**--Netzwerktyp**
Entweder `ipv4`, `ipv` oder `dual-stack`. Wenn Sie Dual-Stack auswählen, müssen Sie den `--IpDiscovery`-Parameter entweder auf `ipv4` oder `ipv6` festlegen.
**Engine**
redis
**EngineVersion**
6.0
Wenn Sie die Verschlüsselung während der Übertragung oder im Ruhezustand für diese Replikationsgruppe aktivieren möchten, fügen Sie einen oder beide der Parameter `TransitEncryptionEnabled=true` oder `AtRestEncryptionEnabled=true` hinzu und erfüllen die folgenden Bedingungen.
+ Auf Ihrer Replikationsgruppe muss Redis OSS Version 3.2.6 oder 4.0.10 ausgeführt werden.
+ Die Replikationsgruppe muss in einer Amazon VPC erstellt werden.
+ Sie müssen außerdem den Parameter `CacheSubnetGroup` einbinden.
+ Sie müssen auch den Parameter `AuthToken` einbinden, mit dem vom Kunden angegebenen Zeichenfolgenwert für Ihr AUTH-Token (Passwort), das für Operationen auf dieser Replikationsgruppe benötigt wird.
Die Zeilenumbrüche dienen der besseren Lesbarkeit.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateReplicationGroup
&CacheNodeType=cache.m4.large
&CacheParemeterGroup=default.redis6.xcluster.on
&Engine=redis
&EngineVersion=6.0
&NumNodeGroups=3
&ReplicasPerNodeGroup=2
&ReplicationGroupDescription=test%20group
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen und Parameter, die Sie möglicherweise verwenden möchten, finden Sie im API-Thema. ElastiCache [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
# Anzeigen der Details einer Replikationsgruppe
Unter bestimmten Umständen möchten Sie vielleicht Details zu einer Replikationsgruppe einsehen. Sie können die ElastiCache Konsole, das AWS CLI for ElastiCache oder die ElastiCache API verwenden. Der Konsolenprozess unterscheidet sich für Valkey oder Redis OSS (Clustermodus deaktiviert) und Valkey oder Redis OSS (Clustermodus aktiviert).
**Contents**
+ [Valkey- oder Redis-OSS (Clustermodus deaktiviert) mit Replikaten anzeigen](Replication.ViewDetails.Redis.md)
+ [Die Konsole verwenden ElastiCache](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CON)
+ [Verwenden der AWS CLI](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CLI)
+ [Verwenden der API ElastiCache](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.API)
+ [Eine Replikationsgruppe anzeigen: Valkey oder Redis OSS (Clustermodus aktiviert)](Replication.ViewDetails.RedisCluster.md)
+ [Die Konsole verwenden ElastiCache](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CON)
+ [Verwenden des AWS CLI](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CLI)
+ [Verwenden der API ElastiCache](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.API)
+ [Anzeigen der Details einer Replikationsgruppe (AWS CLI)](Replication.ViewDetails.CLI.md)
+ [Details einer Replikationsgruppe anzeigen (ElastiCache API)](Replication.ViewDetails.API.md)
# Valkey- oder Redis-OSS (Clustermodus deaktiviert) mit Replikaten anzeigen
Sie können die Details eines Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) mit Replikaten (API/CLI: *Replikationsgruppe*) mithilfe der ElastiCache Konsole, des For oder der AWS CLI API anzeigen. ElastiCache ElastiCache
**Contents**
+ [Die Konsole verwenden ElastiCache](#Replication.ViewDetails.Redis.CON)
+ [Verwenden der AWS CLI](#Replication.ViewDetails.Redis.CLI)
+ [Verwenden der API ElastiCache](#Replication.ViewDetails.Redis.API)
## Anzeigen einer Valkey- oder Redis OSS-Replikationsgruppe (Cluster-Modus deaktiviert) (Konsole)
Informationen zum Anzeigen der Details eines Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) mit Replikaten mithilfe der ElastiCache Konsole finden Sie im Thema. [Details zu Valkey oder Redis OSS (Clustermodus deaktiviert) anzeigen (Konsole)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.Redis)
## Eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) anzeigen ()AWS CLI
Ein AWS CLI Beispiel, in dem die Details einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) angezeigt werden, finden Sie unter. [Anzeigen der Details einer Replikationsgruppe (AWS CLI)](Replication.ViewDetails.CLI.md)
## Eine Valkey- oder Redis OSS-Replikationsgruppe (API) anzeigen (Cluster-Modus deaktiviert) ElastiCache
Ein ElastiCache API-Beispiel, in dem die Details einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) angezeigt werden, finden Sie unter. [Details einer Replikationsgruppe anzeigen (ElastiCache API)](Replication.ViewDetails.API.md)
# Eine Replikationsgruppe anzeigen: Valkey oder Redis OSS (Clustermodus aktiviert)
## Anzeigen eines Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert) (Konsole)
Informationen zum Anzeigen der Details eines Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert) mithilfe der ElastiCache Konsole finden Sie unter. [Details für einen Valkey- oder Redis OSS-Cluster (Cluster Mode Enabled) anzeigen (Konsole)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.RedisCluster)
## Einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) anzeigen ()AWS CLI
Ein ElastiCache CLI-Beispiel, das die Details einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) anzeigt, finden Sie unter. [Anzeigen der Details einer Replikationsgruppe (AWS CLI)](Replication.ViewDetails.CLI.md)
## Einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) (API) anzeigen ElastiCache
Ein ElastiCache API-Beispiel, das die Details einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) anzeigt, finden Sie unter. [Details einer Replikationsgruppe anzeigen (ElastiCache API)](Replication.ViewDetails.API.md)
# Anzeigen der Details einer Replikationsgruppe (AWS CLI)
Sie können die Details für eine Replikationsgruppe mit dem AWS CLI `describe-replication-groups` Befehl anzeigen. Verfeinern Sie die Auflistung mit den folgenden optionalen Parametern. Wenn die Parameter weggelassen werden, werden Details für bis zu 100 Replikationsgruppen zurückgegeben.
**Optionale Parameter**
+ `--replication-group-id` – Verwenden Sie diesen Parameter zur Auflistung der Details einer bestimmten Replikationsgruppe. Wenn die angegebene Replikationsgruppe mehr als eine Knotengruppe besitzt, werden die zurückgegebenen Ergebnisse nach Knotengruppe gruppiert.
+ `--max-items` – Verwenden Sie diesen Parameter, um die Anzahl der aufgelisteten Replikationsgruppen einzuschränken. Der Wert für `--max-items` darf nicht kleiner als 20 oder größer als 100 sein.
**Example**
Der folgende Code listet die Details für bis zu 100 Replikationsgruppen auf.
```
aws elasticache describe-replication-groups
```
Der folgende Code listet die Details für `sample-repl-group` auf.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
Der folgende Code listet die Details für `sample-repl-group` auf.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
Der folgende Code listet die Details für bis zu 25 Replikationsgruppen auf.
```
aws elasticache describe-replication-groups --max-items 25
```
Die Ausgabe dieser Operation sollte etwa wie nachfolgend dargestellt aussehen (JSON-Format).
```
{
"ReplicationGroups": [
{
"Status": "available",
"Description": "test",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2a",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-001.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-002.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-002"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "rg-name-003.1abc4d.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "rg-name-003"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "rg-name.1abc4d.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "rg-name",
"AutomaticFailover": "enabled",
"SnapshottingClusterId": "rg-name-002",
"MemberClusters": [
"rg-name-001",
"rg-name-002",
"rg-name-003"
],
"PendingModifiedValues": {}
},
{
... some output omitted for brevity
}
]
}
```
Weitere Informationen finden Sie im ElastiCache Thema AWS CLI für[describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html).
# Details einer Replikationsgruppe anzeigen (ElastiCache API)
Sie können die Details für eine Replikation mithilfe des AWS CLI `DescribeReplicationGroups` Vorgangs anzeigen. Verfeinern Sie die Auflistung mit den folgenden optionalen Parametern. Wenn die Parameter weggelassen werden, werden Details für bis zu 100 Replikationsgruppen zurückgegeben.
**Optionale Parameter**
+ `ReplicationGroupId` – Verwenden Sie diesen Parameter zur Auflistung der Details einer bestimmten Replikationsgruppe. Wenn die angegebene Replikationsgruppe mehr als eine Knotengruppe besitzt, werden die zurückgegebenen Ergebnisse nach Knotengruppe gruppiert.
+ `MaxRecords` – Verwenden Sie diesen Parameter, um die Anzahl der aufgelisteten Replikationsgruppen einzuschränken. Der Wert für `MaxRecords` darf nicht kleiner als 20 oder größer als 100 sein. Der Standardwert ist 100.
**Example**
Der folgende Code listet die Details für bis zu 100 Replikationsgruppen auf.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Der folgende Code listet die Details für `myReplGroup` auf.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Der folgende Code listet die Details für bis zu 25 Cluster auf.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&MaxRecords=25
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie im ElastiCache API-Referenzthema[DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html).
# Suchen von Endpunkten von Replikationsgruppen
Eine Anwendung kann eine Verbindung zu jedem beliebigen Knoten in einer Replikationsgruppe herstellen, vorausgesetzt, dass es über den DNS-Endpunkt und die Portnummer für den betreffenden Knoten verfügt. Je nachdem, ob Sie eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) oder eine Valkey- oder Redis OSS-Replikationsgruppe (Cluster-Modus aktiviert) ausführen, sind Sie an verschiedenen Endpunkten interessiert.
**Valkey oder Redis OSS (Clustermodus deaktiviert)**
*Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) mit Replikaten haben drei Arten von Endpunkten: den *primären Endpunkt, den *Reader-Endpunkt** und die Knotenendpunkte.* Der primäre Endpunkt ist ein DNS-Name, der immer auf den primären Knoten im Cluster aufgelöst wird. Der primäre Endpunkt ist Änderungen an Ihrem Cluster, wie Heraufstufen einer Read Replica in die Rolle des primären Knotens, gegenüber immun. Für Schreibvorgänge empfehlen wir, dass Anwendungen sich ausschließlich mit dem primären Endpunkt verbinden.
Ein Reader-Endpunkt verteilt eingehende Verbindungen zum Endpunkt gleichmäßig auf alle Read Replicas in einem Cluster. ElastiCache Zusätzliche Faktoren, z. B. wenn die Anwendung die Verbindungen erstellt oder wie die Anwendung die Verbindungen (erneut) verwendet, bestimmen die Verteilung des Datenverkehrs. Reader-Endpunkte bleiben hinsichtlich der Cluster-Änderungen beim Hinzufügen oder Entfernen von Replicas in Echtzeit auf dem aktuellen Stand. Sie können die mehreren Read Replicas Ihres ElastiCache Redis OSS-Clusters in verschiedenen AWS Availability Zones (AZ) platzieren, um eine hohe Verfügbarkeit der Leser-Endpunkte sicherzustellen.
**Anmerkung**
Ein Leser-Endpunkt ist kein Load Balancer. Es handelt sich um einen DNS-Eintrag, der nach dem Rotationsprinzip zu einer IP-Adresse eines der Replikationsknoten aufgelöst wird.
Für Lesevorgänge können Anwendungen Verbindungen zu jedem Knoten im Cluster herstellen. Im Gegensatz zum primären Endpunkt werden Knotenendpunkte auf bestimmte Endpunkte aufgelöst. Wenn Sie eine Änderung am Cluster vornehmen, wie z. B. Hinzufügen oder Löschen eines Replikats, müssen Sie die Knotenendpunkte in Ihrer Anwendung aktualisieren.
**Valkey oder Redis OSS (Clustermodus aktiviert)**
Valkey- oder Redis OSS-Cluster (Cluster-Modus aktiviert) mit Replikaten, da sie mehrere Shards (API/CLI: Knotengruppen) haben, was bedeutet, dass sie auch mehrere Primärknoten haben, haben eine andere Endpunktstruktur als Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert). Valkey oder Redis OSS (Clustermodus aktiviert) haben einen *Konfigurationsendpunkt, der alle Primär-* und Knotenendpunkte im Cluster „kennt“. Ihre Anwendung stellt eine Verbindung zum Konfigurationsendpunkt her. Immer wenn Ihre Anwendung auf den Konfigurationsendpunkt des Clusters schreibt oder von diesem liest, bestimmen Valkey und Redis OSS im Hintergrund, zu welchem Shard der Schlüssel gehört und welcher Endpunkt in diesem Shard verwendet werden soll. Dies läuft alles transparent für Ihre Anwendung ab.
Sie können die Endpunkte für einen Cluster mithilfe der ElastiCache Konsole, der oder der API finden. AWS CLI ElastiCache
**Suchen von Replikationsgruppen-Endpunkten**
Anweisungen zur Suche nach den Endpunkten für Ihre Replikationsgruppe finden Sie in einem der folgenden Themen:
+ [Finden Sie die Endpunkte eines Valkey- oder Redis OSS-Clusters (Cluster-Modus deaktiviert) (Konsole)](Endpoints.md#Endpoints.Find.Redis)
+ [Finden von Endpunkten für einen Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) (Konsole)](Endpoints.md#Endpoints.Find.RedisCluster)
+ [Finden der Endpunkte für Valkey- oder Redis OSS-Replikationsgruppen ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Suche nach Endpunkten für Valkey- oder Redis OSS-Replikationsgruppen (API) ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
# Ändern einer Replikationsgruppe
**Wichtige Einschränkungen**
ElastiCache Unterstützt derzeit begrenzte Änderungen einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert), z. B. das Ändern der Engine-Version mithilfe der API-Operation `ModifyReplicationGroup` (CLI:`modify-replication-group`). Sie können die Anzahl der Shards (Knotengruppen) in einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mit der API-Operation [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html)(CLI:) ändern. [https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html) Weitere Informationen finden Sie unter [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md).
Andere Änderungen an einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) erfordern, dass Sie einen Cluster mit dem neuen Cluster erstellen, der die Änderungen enthält.
Sie können Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) und Valkey- oder Redis OSS-Cluster und Replikationsgruppen (Clustermodus aktiviert) auf neuere Engine-Versionen aktualisieren. Ein Downgrade auf vorhergehende Engine-Versionen ist jedoch nur durch Löschen des vorhandenen Clusters oder der vorhandenen Replikationsgruppe und der anschließenden Erstellung eines neuen Clusters oder einer neuen Replikationsgruppe möglich. Weitere Informationen finden Sie unter [Versionsverwaltung für ElastiCache](VersionManagement.md).
Sie können einen vorhandenen OSS-Cluster ElastiCache für Valkey oder Redis, der den Clustermodus deaktiviert verwendet, mithilfe der Konsole, der [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)API oder des [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)CLI-Befehls aktualisieren, um den Clustermodus aktiviert zu verwenden, wie im folgenden Beispiel gezeigt. Sie können auch den Schritten unter [Ändern des Clustermodus](modify-cluster-mode.md) folgen.
Sie können die Einstellungen eines Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) mithilfe der ElastiCache Konsole, der oder der AWS CLI API ändern. ElastiCache ElastiCache Unterstützt derzeit eine begrenzte Anzahl von Änderungen an einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert). Andere Änderungen erfordern, dass Sie eine Sicherungskopie der aktuellen Replikationsgruppe erstellen und diese Sicherung dann verwenden, um eine neue Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) zu erstellen.
**Topics**
+ [Unter Verwendung der AWS-Managementkonsole](#Replication.Modify.CON)
+ [Verwenden des AWS CLI](#Replication.Modify.CLI)
+ [Verwenden der API ElastiCache](#Replication.Modify.API)
## Unter Verwendung der AWS-Managementkonsole
Informationen zum Ändern eines Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) finden Sie unter. [Einen ElastiCache Cluster ändern](Clusters.Modify.md)
## Verwenden des AWS CLI
Im Folgenden finden Sie AWS CLI Beispiele für den `modify-replication-group` Befehl. Sie können mit demselben Befehl andere Änderungen an einer Replikationsgruppe vornehmen.
**Aktivieren Sie Multi-AZ für eine bestehende Valkey- oder Redis OSS-Replikationsgruppe:**
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--multi-az-enabled = true
```
Für Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--multi-az-enabled
```
**Ändern des Clustermodus von deaktiviert auf aktiviert:**
Wenn Sie den Clustermodus von *deaktiviert* auf *aktiviert* ändern möchten, müssen Sie zuerst den Clustermodus auf *kompatibel* festlegen. Im kompatiblen Modus können sich Ihre Valkey- oder Redis OSS-Clients sowohl mit aktiviertem als auch mit deaktiviertem Clustermodus verbinden. *Nachdem Sie alle Valkey- oder Redis OSS-Clients zur Verwendung des aktivierten Clustermodus migriert haben, können Sie die Konfiguration des Clustermodus abschließen und den Clustermodus auf aktiviert setzen.*
Für Linux, macOS oder Unix:
Legen Sie den Clustermodus auf *kompatibel* fest.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cache-parameter-group-name myParameterGroupName \
--cluster-mode compatible
```
Legen Sie den Clustermodus auf *aktiviert* fest.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cluster-mode enabled
```
Für Windows:
Legen Sie den Clustermodus auf *kompatibel* fest.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cache-parameter-group-name myParameterGroupName ^
--cluster-mode compatible
```
Legen Sie den Clustermodus auf *aktiviert* fest.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cluster-mode enabled
```
Weitere Informationen zu diesem AWS CLI `modify-replication-group` Befehl finden Sie unter [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) oder [Ändern des Clustermodus]() im Benutzerhandbuch *ElastiCache für Redis OSS*.
## Verwenden der API ElastiCache
Der folgende ElastiCache API-Vorgang aktiviert Multi-AZ auf einer vorhandenen Valkey- oder Redis OSS-Replikationsgruppe. Sie können mit derselben Operation andere Änderungen an einer Replikationsgruppe vornehmen.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&AutomaticFailoverEnabled=true
&Mutli-AZEnabled=true
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Weitere Informationen zum ElastiCache `ModifyReplicationGroup` API-Vorgang finden Sie unter. [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
# Löschen einer Replikationsgruppe
Wenn Sie einen Ihrer Cluster mit Replikaten (in API/CLI als *Replikationsgruppen* bezeichnet) nicht mehr benötigen, können Sie ihn löschen. Wenn Sie eine Replikationsgruppe ElastiCache löschen, werden alle Knoten in dieser Gruppe gelöscht.
Sobald die Operation gestartet wurde, kann sie nicht mehr unterbrochen oder abgebrochen werden.
**Warnung**
Wenn Sie einen ElastiCache für Redis OSS-Cluster löschen, bleiben Ihre manuellen Snapshots erhalten. Sie erhalten außerdem die Möglichkeit, einen letzten Snapshot zu erstellen, bevor der Cluster gelöscht wird. Automatisch erstellte Cache-Snapshots werden nicht aufbewahrt.
`CreateSnapshot`Für die Erstellung eines endgültigen Snapshots ist eine Genehmigung erforderlich. Ohne diese Genehmigung schlägt der API-Aufruf mit einer `Access Denied` Ausnahme fehl.
## Löschen einer Replikationsgruppe (Konsole)
Zum Löschen eines Clusters mit Replikaten informieren Sie sich unter [Löschen eines Clusters in ElastiCache](Clusters.Delete.md).
## Löschen einer Replikationsgruppe (AWS CLI)
Mit dem Befehl [delete-replication-group](https://docs.aws.amazon.com/AmazonElastiCache/latest/CommandLineReference/CLIReference-cmd-DeleteReplicationGroup.html) können Sie eine Replikationsgruppe löschen.
```
aws elasticache delete-replication-group --replication-group-id my-repgroup
```
Sie werden aufgefordert, Ihre Entscheidung zu bestätigen. Geben Sie *y* (Ja) ein, um die Operation sofort zu starten. Einmal gestartet kann der Vorgang nicht mehr rückgängig gemacht werden.
```
After you begin deleting this replication group, all of its nodes will be deleted as well.
Are you sure you want to delete this replication group? [Ny]y
REPLICATIONGROUP my-repgroup My replication group deleting
```
## Löschen einer Replikationsgruppe (ElastiCache API)
Rufen Sie [DeleteReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteReplicationGroup.html) mit dem Parameter `ReplicationGroup` auf.
**Example**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteReplicationGroup
&ReplicationGroupId=my-repgroup
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
**Anmerkung**
Wenn Sie den Parameter `RetainPrimaryCluster` auf `true` einstellen, werden alle Read Replicas gelöscht, der primäre Cluster wird jedoch beibehalten.
# Ändern der Anzahl von Replikaten
Sie können die Anzahl der Read Replicas in Ihrer Valkey- oder Redis OSS-Replikationsgruppe mithilfe der AWS-Managementkonsole, der oder der API dynamisch erhöhen oder verringern. AWS CLI ElastiCache Wenn es sich bei Ihrer Replikationsgruppe um eine Valkey- oder Redis OSS-Replikationsgruppe (Cluster-Modus aktiviert) handelt, können Sie auswählen, mit welchen Shards (Knotengruppen) die Anzahl der Replikate erhöht oder verringert werden soll.
Um die Anzahl der Replikate in Ihrer Replikationsgruppe dynamisch zu ändern, wählen Sie den Vorgang aus der folgenden Tabelle aus, der zu Ihrer Situation passt.
| So gehen Sie vor | Für Valkey oder Redis OSS (Clustermodus aktiviert) | Für Valkey oder Redis OSS (Clustermodus deaktiviert) |
| --- | --- | --- |
| Replikate hinzufügen | [Erhöhen der Anzahl der Replikate in einem Shard](increase-replica-count.md) | [Erhöhen der Anzahl der Replikate in einem Shard](increase-replica-count.md) [Hinzufügen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert)](Replication.AddReadReplica.md) |
| Replikate löschen | [Verringern der Anzahl der Replikate in einem Shard](decrease-replica-count.md) | [Verringern der Anzahl der Replikate in einem Shard](decrease-replica-count.md) [Löschen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert)](Replication.RemoveReadReplica.md) |
# Erhöhen der Anzahl der Replikate in einem Shard
Sie können die Anzahl der Replikate in einer Valkey- oder Redis OSS-Replikationsgruppe (Cluster-Modus aktiviert) oder einer Valkey- oder Redis-OSS-Replikationsgruppe (Cluster-Modus deaktiviert) auf maximal fünf erhöhen. Sie können dazu die, oder die API AWS-Managementkonsole verwenden. AWS CLI ElastiCache
**Topics**
+ [Mit dem AWS-Managementkonsole](#increase-replica-count-con)
+ [Unter Verwendung der AWS CLI](#increase-replica-count-cli)
+ [Verwendung der API ElastiCache](#increase-replica-count-api)
## Mit dem AWS-Managementkonsole
Das folgende Verfahren verwendet die Konsole, um die Anzahl der Replikate in einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) zu erhöhen.
**Um die Anzahl der Replikate in Shards zu erhöhen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis OSS** und dann den Namen der Replikationsgruppe aus, zu der Sie Replikate hinzufügen möchten.
1. Aktivieren Sie das Kontrollkästchen eines jeden Shards, den Sie zu Replikaten hinzufügen möchten.
1. Wählen Sie **Add replicas (Replikate hinzufügen)**.
1. Füllen Sie die Seite **Add Replicas to Shards (Replikate zu Shards hinzufügen)** aus:
+ Geben Sie für **New number of replicas/shard (Neue Anzahl der Replikate pro Shard)** die Anzahl der Replikate ein, über die alle Ihre ausgewählten Shards verfügen sollen. Dieser Wert muss größer oder gleich dem Wert für **Current Number of Replicas per shard (Aktuelle Anzahl der Replicas pro Shard)** und kleiner oder gleich fünf sein. Als funktionelles Minimum empfehlen wir mindestens zwei Replikate.
+ Wählen Sie für **Availability Zones** entweder **Keine Präferenz** aus, um für jedes neue Replikat eine Availability Zone ElastiCache ausgewählt zu haben, oder **Availability Zones angeben**, um für jedes neue Replikat eine Availability Zone auszuwählen.
Geben Sie bei Auswahl von **Availability Zones angeben** für jedes neue Replikat eine Availability Zone aus der Liste an.
1. Klicken Sie auf **Add (Hinzufügen)**, um die Replikate hinzuzufügen, oder auf **Cancel (Abbrechen)**, um den Vorgang abzubrechen.
## Unter Verwendung der AWS CLI
Um die Anzahl der Replikate in einem Valkey- oder Redis OSS-Shard zu erhöhen, verwenden Sie den `increase-replica-count` Befehl mit den folgenden Parametern:
+ `--replication-group-id` – Erforderlich. Identifiziert, in welcher Replikationsgruppe Sie die Anzahl von Replikaten erhöhen möchten.
+ `--apply-immediately` oder `--no-apply-immediately` – Erforderlich. Gibt an, ob die Replikatanzahl sofort (`--apply-immediately`) oder während des nächsten Wartungsfensters (`--no-apply-immediately`) erhöht werden soll. `--no-apply-immediately` wird derzeit nicht unterstützt.
+ `--new-replica-count` – Optional. Gibt die gewünschte Anzahl von Replikatknoten nach der Fertigstellung an, bis zu maximal fünf. Verwenden Sie diesen Parameter für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert), wenn es nur eine Knotengruppe oder Valkey- oder Redis OSS-Gruppe (Clustermodus aktiviert) gibt oder wenn Sie möchten, dass alle Knotengruppen dieselbe Anzahl von Replikaten haben. Wenn dieser Wert nicht größer als die aktuelle Anzahl der Replikate in der Knotengruppe ist, schlägt der Aufruf mit einer Ausnahme fehl.
+ `--replica-configuration` – Optional. Ermöglicht Ihnen, die Anzahl der Replikate und Availability Zones für jede Knotengruppe separat festzulegen. Verwenden Sie diesen Parameter für Valkey- oder Redis OSS-Gruppen (Clustermodus aktiviert), bei denen Sie jede Knotengruppe unabhängig konfigurieren möchten.
`--replica-configuration` verfügt über drei optionale Mitglieder:
+ `NodeGroupId` Die vierziffrige ID der Knotengruppe, die Sie derzeit konfigurieren. Für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert) ist die Shard-ID immer. `0001` Informationen zur ID einer Valkey- oder Redis OSS-Knotengruppe (Shards) (Clustermodus aktiviert) finden Sie unter. [Auffinden der ID eines Shards](Shards.md#shard-find-id)
+ `NewReplicaCount` Die Anzahl der Replikate, die sich am Ende dieser Operation in dieser Knotengruppe befinden sollen. Der Wert muss höher als die aktuelle Anzahl der Replikate sein und darf maximal fünf betragen. Wenn dieser Wert nicht größer als die aktuelle Anzahl der Replikate in der Knotengruppe ist, schlägt der Aufruf mit einer Ausnahme fehl.
+ `PreferredAvailabilityZones`Eine Liste der `PreferredAvailabilityZone`-Zeichenfolgen, die angeben, in welchen Availability Zones sich die Knoten der Replikationsgruppe befinden sollen. Die Anzahl der `PreferredAvailabilityZone`-Werte muss gleich dem Wert von `NewReplicaCount` plus 1 sein, um dem primären Knoten Rechnung zu tragen. Wenn dieses Mitglied von weggelassen `--replica-configuration` wird, wählt OSS ElastiCache für Redis die Availability Zone für jedes der neuen Replikate.
**Wichtig**
Sie müssen in Ihren Aufruf entweder den Parameter `--new-replica-count` oder den Parameter `--replica-configuration`, aber nicht beide, einbeziehen.
**Example**
Im folgenden Beispiel wird die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` auf drei erhöht. Wenn das Beispiel abgeschlossen ist, befinden sich in jeder Knotengruppe drei Replikate. Diese Zahl gilt unabhängig davon, ob es sich um eine Valkey- oder Redis OSS-Gruppe (Clustermodus deaktiviert) mit einer einzelnen Knotengruppe oder um eine Valkey- oder Redis OSS-Gruppe (Clustermodus aktiviert) mit mehreren Knotengruppen handelt.
Für Linux, macOS oder Unix:
```
aws elasticache increase-replica-count \
--replication-group-id sample-repl-group \
--new-replica-count 3 \
--apply-immediately
```
Für Windows:
```
aws elasticache increase-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 3 ^
--apply-immediately
```
Im folgenden Beispiel erhöht sich die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` auf den Wert, der für die beiden angegebenen Knotengruppen festgelegt ist. Da es mehrere Knotengruppen gibt, handelt es sich um eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert). Wenn optional ein Wert für `PreferredAvailabilityZones` angegeben wird, muss die Anzahl der aufgelisteten Availability Zones gleich dem Wert von `NewReplicaCount` plus 1 sein. Diese Methode trägt dem primären Knoten für die durch `NodeGroupId` identifizierte Gruppe Rechnung.
Für Linux, macOS oder Unix:
```
aws elasticache increase-replica-count \
--replication-group-id sample-repl-group \
--replica-configuration \
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1c,us-east-1b \
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c,us-east-1c \
--apply-immediately
```
Für Windows:
```
aws elasticache increase-replica-count ^
--replication-group-id sample-repl-group ^
--replica-configuration ^
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1c,us-east-1b ^
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c,us-east-1c \
--apply-immediately
```
Weitere Informationen zur Erhöhung der Anzahl von Replikaten mithilfe der CLI finden Sie [increase-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/increase-replica-count.html)in der * ElastiCache Amazon-Befehlszeilenreferenz.*
## Verwendung der API ElastiCache
Verwenden Sie die `IncreaseReplicaCount` Aktion mit den folgenden Parametern, um die Anzahl der Replikate in einem Valkey- oder Redis OSS-Shard zu erhöhen:
+ `ReplicationGroupId` – Erforderlich. Identifiziert, in welcher Replikationsgruppe Sie die Anzahl von Replikaten erhöhen möchten.
+ `ApplyImmediately` – Erforderlich. Gibt an, ob die Replikatanzahl sofort (`ApplyImmediately=True`) oder während des nächsten Wartungsfensters (`ApplyImmediately=False`) erhöht werden soll. `ApplyImmediately=False` wird derzeit nicht unterstützt.
+ `NewReplicaCount` – Optional. Gibt die gewünschte Anzahl von Replikatknoten nach der Fertigstellung an, bis zu maximal fünf. Verwenden Sie diesen Parameter für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert), bei denen es nur eine Knotengruppe gibt, oder für Valkey- oder Redis OSS-Gruppen (Clustermodus aktiviert), bei denen alle Knotengruppen dieselbe Anzahl von Replikaten haben sollen. Wenn dieser Wert nicht größer als die aktuelle Anzahl der Replikate in der Knotengruppe ist, schlägt der Aufruf mit einer Ausnahme fehl.
+ `ReplicaConfiguration` – Optional. Ermöglicht Ihnen, die Anzahl der Replikate und Availability Zones für jede Knotengruppe separat festzulegen. Verwenden Sie diesen Parameter für Valkey- oder Redis OSS-Gruppen (Clustermodus aktiviert), bei denen Sie jede Knotengruppe unabhängig konfigurieren möchten.
`ReplicaConfiguraion` verfügt über drei optionale Mitglieder:
+ `NodeGroupId` Die vierziffrige ID für die Knotengruppe, die Sie derzeit konfigurieren. Für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert) ist die Knotengruppen-ID (Shard) immer. `0001` Informationen zur ID einer Valkey- oder Redis OSS-Knotengruppe (Shards) (Clustermodus aktiviert) finden Sie unter. [Auffinden der ID eines Shards](Shards.md#shard-find-id)
+ `NewReplicaCount` Die Anzahl der Replikate, die sich am Ende dieser Operation in dieser Knotengruppe befinden sollen. Der Wert muss höher als die aktuelle Anzahl der Replikate sein und darf maximal fünf betragen. Wenn dieser Wert nicht größer als die aktuelle Anzahl der Replikate in der Knotengruppe ist, schlägt der Aufruf mit einer Ausnahme fehl.
+ `PreferredAvailabilityZones`Eine Liste der `PreferredAvailabilityZone`-Zeichenfolgen, die angeben, in welchen Availability Zones sich die Knoten der Replikationsgruppe befinden sollen. Die Anzahl der `PreferredAvailabilityZone`-Werte muss gleich dem Wert von `NewReplicaCount` plus 1 sein, um dem primären Knoten Rechnung zu tragen. Wenn dieses Mitglied von weggelassen `ReplicaConfiguration` wird, wählt OSS ElastiCache für Redis die Availability Zone für jedes der neuen Replikate.
**Wichtig**
Sie müssen in Ihren Aufruf entweder den Parameter `NewReplicaCount` oder den Parameter `ReplicaConfiguration`, aber nicht beide, einbeziehen.
**Example**
Im folgenden Beispiel wird die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` auf drei erhöht. Wenn das Beispiel abgeschlossen ist, befinden sich in jeder Knotengruppe drei Replikate. Diese Zahl gilt unabhängig davon, ob es sich um eine Valkey- oder Redis OSS-Gruppe (Clustermodus deaktiviert) mit einer einzelnen Knotengruppe oder um eine Valkey- oder Redis OSS-Gruppe (Clustermodus aktiviert) mit mehreren Knotengruppen handelt.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=IncreaseReplicaCount
&ApplyImmediately=True
&NewReplicaCount=3
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Im folgenden Beispiel erhöht sich die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` auf den Wert, der für die beiden angegebenen Knotengruppen festgelegt ist. Da es mehrere Knotengruppen gibt, handelt es sich um eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert). Wenn optional ein Wert für `PreferredAvailabilityZones` angegeben wird, muss die Anzahl der aufgelisteten Availability Zones gleich dem Wert von `NewReplicaCount` plus 1 sein. Diese Methode trägt dem primären Knoten für die durch `NodeGroupId` identifizierte Gruppe Rechnung.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=IncreaseReplicaCount
&ApplyImmediately=True
&ReplicaConfiguration.ConfigureShard.1.NodeGroupId=0001
&ReplicaConfiguration.ConfigureShard.1.NewReplicaCount=2
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1c
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.3=us-east-1b
&ReplicaConfiguration.ConfigureShard.2.NodeGroupId=0003
&ReplicaConfiguration.ConfigureShard.2.NewReplicaCount=3
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1b
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.3=us-east-1c
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.4=us-east-1c
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen zur Erhöhung der Anzahl von Replikaten, die die API verwenden, finden Sie [IncreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_IncreaseReplicaCount.html)in der *Amazon ElastiCache API-Referenz.*
# Verringern der Anzahl der Replikate in einem Shard
Sie können die Anzahl der Replikate in einem Shard für Valkey oder Redis OSS (Clustermodus aktiviert) oder in einer Replikationsgruppe für Valkey oder Redis OSS (Clustermodus deaktiviert) verringern:
+ Für Valkey oder Redis OSS (Clustermodus deaktiviert) können Sie die Anzahl der Replikate auf eins reduzieren, wenn Multi-AZ aktiviert ist, und auf Null, wenn es nicht aktiviert ist.
+ Für Valkey oder Redis OSS (Clustermodus aktiviert) können Sie die Anzahl der Replikate auf Null reduzieren. Es ist jedoch kein Failover auf ein Replikat möglich, wenn Ihr primärer Knoten ausfällt.
Sie können die AWS-Managementkonsole, die AWS CLI oder die ElastiCache API verwenden, um die Anzahl der Replikate in einer Knotengruppe (Shard) oder Replikationsgruppe zu verringern.
**Topics**
+ [Mit dem AWS-Managementkonsole](#decrease-replica-count-con)
+ [Mit dem AWS CLI](#decrease-replica-count-cli)
+ [Verwendung der API ElastiCache](#decrease-replica-count-api)
## Mit dem AWS-Managementkonsole
Das folgende Verfahren verwendet die Konsole, um die Anzahl der Replikate in einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) zu verringern.
**Um die Anzahl der Replikate in einem Valkey- oder Redis OSS-Shard zu verringern**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Konsole unter. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Valkey** oder **Redis OSS** und dann den Namen der Replikationsgruppe aus, aus der Sie Replikate löschen möchten.
1. Aktivieren Sie das Kontrollkästchen eines jeden Shards, aus dem Sie einen Replikatknoten entfernen möchten.
1. Wählen Sie **Delete replicas (Replikate löschen)**.
1. Füllen Sie die Seite **Delete Replicas from to Shards (Replikate aus Shards löschen)** aus:
1. Geben Sie für **New number of replicas/shard (Neue Anzahl der Replikate pro Shard)** die Anzahl der Replikate ein, über die die ausgewählten Shards verfügen sollen. Dieser Wert muss größer oder gleich 1 sein. Als funktionelles Minimum empfehlen wir mindestens zwei Replikate pro Shard.
1. Klicken Sie auf **Delete (Löschen)**, um die Replikate zu löschen, oder auf **Cancel (Abbrechen)**, um den Vorgang abzubrechen.
**Wichtig**
Wenn Sie die zu löschenden Replikatknoten nicht angeben, wählt OSS ElastiCache für Redis automatisch Replikatknoten zum Löschen aus. Dabei versucht OSS ElastiCache für Redis, die Multi-AZ-Architektur für Ihre Replikationsgruppe beizubehalten, gefolgt von der Beibehaltung von Replikaten mit minimaler Replikationsverzögerung gegenüber der Primärgruppe.
Primäre oder Master-Knoten in einer Replikationsgruppe können nicht gelöscht werden. Wenn Sie einen primären Knoten für die Löschoperation angeben, schlägt dies mit einem Fehlerereignis fehl, das darauf hinweist, dass der primäre Knoten zum Löschen ausgewählt wurde.
## Mit dem AWS CLI
Um die Anzahl der Replikate in einem Valkey- oder Redis OSS-Shard zu verringern, verwenden Sie den `decrease-replica-count` Befehl mit den folgenden Parametern:
+ `--replication-group-id` – Erforderlich. Identifiziert, in welcher Replikationsgruppe Sie die Anzahl der Replikate verringern möchten.
+ `--apply-immediately` oder `--no-apply-immediately` – Erforderlich. Gibt an, ob die Replikatanzahl sofort (`--apply-immediately`) oder während des nächsten Wartungsfensters (`--no-apply-immediately`) verringert werden soll. `--no-apply-immediately` wird derzeit nicht unterstützt.
+ `--new-replica-count` – Optional. Gibt die Anzahl der von Ihnen gewünschten Replikatknoten an. Der Wert `--new-replica-count` muss ein gültiger Wert kleiner als die aktuelle Anzahl der Replikate in den Knotengruppen sein. Informationen zu den zulässigen Mindestwerten finden Sie unter [Verringern der Anzahl der Replikate in einem Shard](#decrease-replica-count). Wenn der Wert von `--new-replica-count` dieser Anforderung nicht entspricht, schlägt der Aufruf fehl.
+ `--replicas-to-remove` – Optional. Enthält eine Liste von Knoten, die die zu entfernenden Replikatknoten IDs angeben.
+ `--replica-configuration` – Optional. Ermöglicht Ihnen, die Anzahl der Replikate und Availability Zones für jede Knotengruppe separat festzulegen. Verwenden Sie diesen Parameter für Valkey- oder Redis OSS-Gruppen (Clustermodus aktiviert), bei denen Sie jede Knotengruppe unabhängig konfigurieren möchten.
`--replica-configuration` verfügt über drei optionale Mitglieder:
+ `NodeGroupId` Die vierziffrige ID der Knotengruppe, die Sie derzeit konfigurieren. Für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert) ist die Shard-ID immer. `0001` Informationen zur ID einer Valkey- oder Redis OSS-Knotengruppe (Shards) (Clustermodus aktiviert) finden Sie unter. [Auffinden der ID eines Shards](Shards.md#shard-find-id)
+ `NewReplicaCount` Ein optionaler Parameter, der die Anzahl der von Ihnen gewünschten Replikatknoten angibt. Der Wert `NewReplicaCount` muss ein gültiger Wert kleiner als die aktuelle Anzahl der Replikate in den Knotengruppen sein. Informationen zu den zulässigen Mindestwerten finden Sie unter [Verringern der Anzahl der Replikate in einem Shard](#decrease-replica-count). Wenn der Wert von `NewReplicaCount` dieser Anforderung nicht entspricht, schlägt der Aufruf fehl.
+ `PreferredAvailabilityZones`Eine Liste von `PreferredAvailabilityZone`-Zeichenfolgen, die angeben, in welchen Availability Zones sich die Knoten der Replikationsgruppen befinden. Die Anzahl der `PreferredAvailabilityZone`-Werte muss gleich dem Wert von `NewReplicaCount` plus 1 sein, um dem primären Knoten Rechnung zu tragen. Wenn dieses Mitglied von weggelassen `--replica-configuration` wird, wählt OSS ElastiCache für Redis die Availability Zone für jedes der neuen Replikate.
**Wichtig**
Sie dürfen nur genau einen der `--new-replica-count`-, `--replicas-to-remove`- oder `--replica-configuration`-Parameter einschließen.
**Example**
Im folgenden Beispiel wird mit `--new-replica-count` die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` um eins verringert. Wenn das Beispiel abgeschlossen ist, befindet sich ein Replikat in jeder Knotengruppe. Diese Zahl gilt unabhängig davon, ob es sich um eine Valkey- oder Redis OSS-Gruppe (Clustermodus deaktiviert) mit einer einzelnen Knotengruppe oder um eine Valkey- oder Redis OSS-Gruppe (Clustermodus aktiviert) mit mehreren Knotengruppen handelt.
Für Linux, macOS oder Unix:
```
aws elasticache decrease-replica-count
--replication-group-id sample-repl-group \
--new-replica-count 1 \
--apply-immediately
```
Für Windows:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 1 ^
--apply-immediately
```
Im folgenden Beispiel wird die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` verringert, indem zwei bestimmte Replikate (`0001` und `0003`) aus der Knotengruppe entfernt werden.
Für Linux, macOS oder Unix:
```
aws elasticache decrease-replica-count \
--replication-group-id sample-repl-group \
--replicas-to-remove 0001,0003 \
--apply-immediately
```
Für Windows:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--replicas-to-remove 0001,0003 \
--apply-immediately
```
Im folgenden Beispiel wird mit `--replica-configuration` die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` auf den Wert verringert, der für die beiden angegebenen Knotengruppen festgelegt ist. Da es mehrere Knotengruppen gibt, handelt es sich um eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert). Wenn optional ein Wert für `PreferredAvailabilityZones` angegeben wird, muss die Anzahl der aufgelisteten Availability Zones gleich dem Wert von `NewReplicaCount` plus 1 sein. Diese Methode trägt dem primären Knoten für die durch `NodeGroupId` identifizierte Gruppe Rechnung.
Für Linux, macOS oder Unix:
```
aws elasticache decrease-replica-count \
--replication-group-id sample-repl-group \
--replica-configuration \
NodeGroupId=0001,NewReplicaCount=1,PreferredAvailabilityZones=us-east-1a,us-east-1c \
NodeGroupId=0003,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c \
--apply-immediately
```
Für Windows:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--replica-configuration ^
NodeGroupId=0001,NewReplicaCount=2,PreferredAvailabilityZones=us-east-1a,us-east-1c ^
NodeGroupId=0003,NewReplicaCount=3,PreferredAvailabilityZones=us-east-1a,us-east-1b,us-east-1c \
--apply-immediately
```
Weitere Informationen zur Verringerung der Anzahl von Replikaten mithilfe der CLI finden Sie [decrease-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/decrease-replica-count.html)in der * ElastiCache Amazon-Befehlszeilenreferenz.*
## Verwendung der API ElastiCache
Verwenden Sie die `DecreaseReplicaCount` Aktion mit den folgenden Parametern, um die Anzahl der Replikate in einem Valkey- oder Redis OSS-Shard zu verringern:
+ `ReplicationGroupId` – Erforderlich. Identifiziert, in welcher Replikationsgruppe Sie die Anzahl der Replikate verringern möchten.
+ `ApplyImmediately` – Erforderlich. Gibt an, ob die Replikatanzahl sofort (`ApplyImmediately=True`) oder während des nächsten Wartungsfensters (`ApplyImmediately=False`) verringert werden soll. `ApplyImmediately=False` wird derzeit nicht unterstützt.
+ `NewReplicaCount` – Optional. Gibt die Anzahl der von Ihnen gewünschten Replikatknoten an. Der Wert `NewReplicaCount` muss ein gültiger Wert kleiner als die aktuelle Anzahl der Replikate in den Knotengruppen sein. Informationen zu den zulässigen Mindestwerten finden Sie unter [Verringern der Anzahl der Replikate in einem Shard](#decrease-replica-count). Wenn der Wert von `--new-replica-count` dieser Anforderung nicht entspricht, schlägt der Aufruf fehl.
+ `ReplicasToRemove` – Optional. Enthält eine Liste von Knoten, die die zu entfernenden Replikatknoten IDs angeben.
+ `ReplicaConfiguration` – Optional. Enthält eine Liste von Knotengruppen, mit denen Sie die Anzahl der Replikate und Availability Zones separat für jede Knotengruppe festlegen können. Verwenden Sie diesen Parameter für Valkey- oder Redis OSS-Gruppen (Clustermodus aktiviert), bei denen Sie jede Knotengruppe unabhängig konfigurieren möchten.
`ReplicaConfiguraion` verfügt über drei optionale Mitglieder:
+ `NodeGroupId` Die vierziffrige ID für die Knotengruppe, die Sie derzeit konfigurieren. Für Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert) ist die Knotengruppen-ID immer. `0001` Informationen zur ID einer Valkey- oder Redis OSS-Knotengruppe (Shards) (Clustermodus aktiviert) finden Sie unter. [Auffinden der ID eines Shards](Shards.md#shard-find-id)
+ `NewReplicaCount` Die Anzahl der Replikate, die sich am Ende dieser Operation in dieser Knotengruppe befinden sollen. Der Wert muss weniger als die aktuelle Anzahl der Replikate sein. Der Mindestwert ist 1, wenn Multi-AZ aktiviert ist, bzw. 0, wenn Multi-AZ mit Automatic Failover nicht aktiviert ist. Wenn dieser Wert nicht kleiner als die aktuelle Anzahl der Replikate in der Knotengruppe ist, schlägt der Aufruf mit einer Ausnahme fehl.
+ `PreferredAvailabilityZones`Eine Liste von `PreferredAvailabilityZone`-Zeichenfolgen, die angeben, in welchen Availability Zones sich die Knoten der Replikationsgruppen befinden. Die Anzahl der `PreferredAvailabilityZone`-Werte muss gleich dem Wert von `NewReplicaCount` plus 1 sein, um dem primären Knoten Rechnung zu tragen. Wenn dieses Mitglied von weggelassen `ReplicaConfiguration` wird, wählt OSS ElastiCache für Redis die Availability Zone für jedes der neuen Replikate.
**Wichtig**
Sie dürfen nur genau einen der `NewReplicaCount`-, `ReplicasToRemove`- oder `ReplicaConfiguration`-Parameter einschließen.
**Example**
Im folgenden Beispiel wird mit `NewReplicaCount` die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` um eins verringert. Wenn das Beispiel abgeschlossen ist, befindet sich ein Replikat in jeder Knotengruppe. Diese Zahl gilt unabhängig davon, ob es sich um eine Valkey- oder Redis OSS-Gruppe (Clustermodus deaktiviert) mit einer einzelnen Knotengruppe oder um eine Valkey- oder Redis OSS-Gruppe (Clustermodus aktiviert) mit mehreren Knotengruppen handelt.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&NewReplicaCount=1
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Im folgenden Beispiel wird die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` verringert, indem zwei bestimmte Replikate (`0001` und `0003`) aus der Knotengruppe entfernt werden.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&ReplicasToRemove.ReplicaToRemove.1=0001
&ReplicasToRemove.ReplicaToRemove.2=0003
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Im folgenden Beispiel wird mit `ReplicaConfiguration` die Anzahl der Replikate in der Replikationsgruppe `sample-repl-group` auf den Wert verringert, der für die beiden angegebenen Knotengruppen festgelegt ist. Da es mehrere Knotengruppen gibt, handelt es sich um eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert). Wenn optional ein Wert für `PreferredAvailabilityZones` angegeben wird, muss die Anzahl der aufgelisteten Availability Zones gleich dem Wert von `NewReplicaCount` plus 1 sein. Diese Methode trägt dem primären Knoten für die durch `NodeGroupId` identifizierte Gruppe Rechnung.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DecreaseReplicaCount
&ApplyImmediately=True
&ReplicaConfiguration.ConfigureShard.1.NodeGroupId=0001
&ReplicaConfiguration.ConfigureShard.1.NewReplicaCount=1
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.1.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1c
&ReplicaConfiguration.ConfigureShard.2.NodeGroupId=0003
&ReplicaConfiguration.ConfigureShard.2.NewReplicaCount=2
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.1=us-east-1a
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.2=us-east-1b
&ReplicaConfiguration.ConfigureShard.2.PreferredAvailabilityZones.PreferredAvailabilityZone.4=us-east-1c
&ReplicationGroupId=sample-repl-group
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen zur Verringerung der Anzahl von Replikaten, die die API verwenden, finden Sie [DecreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DecreaseReplicaCount.html)in der *Amazon ElastiCache API-Referenz.*
# Hinzufügen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert)
Die Informationen im folgenden Thema beziehen sich nur auf Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert).
Mit zunehmendem Datenverkehr durch Lesezugriffe empfiehlt es sich, diese Lesezugriffe über mehr Knoten zu verteilen und somit die Belastung durch Lesezugriffe auf jedem Knoten zu reduzieren. In diesem Thema erfahren Sie, wie Sie einem Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) eine Read Replica hinzufügen.
Eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) kann maximal fünf Read Replicas haben. Bei dem Versuch, einer Replikationsgruppe mit bereits fünf Read Replicas ein weiteres Read Replica hinzuzufügen, schlägt die Operation fehl.
Informationen zum Hinzufügen von Replikaten zu einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) finden Sie im Folgenden:
+ [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md)
+ [Erhöhen der Anzahl der Replikate in einem Shard](increase-replica-count.md)
Sie können einem Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) mithilfe der ElastiCache Konsole, der oder der API eine Read Replica hinzufügen. AWS CLI ElastiCache
**Verwandte Themen**
+ [Hinzufügen von Knoten zu einem ElastiCache Cluster](Clusters.AddNode.md)
+ [Hinzufügen einer Read Replica zu einer Replikationsgruppe (AWS CLI)](#Replication.AddReadReplica.CLI)
+ [Hinzufügen eines Read Replica zu einer Replikationsgruppe mithilfe der API](#Replication.AddReadReplica.API)
## Hinzufügen einer Read Replica zu einer Replikationsgruppe (AWS CLI)
Um einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) eine Read Replica hinzuzufügen, verwenden Sie den AWS CLI `create-cache-cluster` Befehl mit dem Parameter, `--replication-group-id` um anzugeben, zu welcher Replikationsgruppe der Cluster (Knoten) hinzugefügt werden soll.
Im folgenden Beispiel wird der Cluster `my-read replica` erstellt und zur Replikationsgruppe `my-replication-group` hinzugefügt. Die Knotentypen, Parametergruppen, Sicherheitsgruppen, das Wartungsfenster und andere Einstellungen für das Read Replica sind mit denen für die anderen Knoten in `my-replication-group` identisch.
Für Linux, macOS oder Unix:
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-read-replica \
--replication-group-id my-replication-group
```
Für Windows:
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-read-replica ^
--replication-group-id my-replication-group
```
Weitere Informationen zum Hinzufügen einer Read Replica mithilfe der CLI finden Sie [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html) in der * ElastiCache Amazon-Befehlszeilenreferenz.*
## Hinzufügen eines Read Replica zu einer Replikationsgruppe mithilfe der API
Um eine Read Replica zu einer Valkey- oder Redis OSS-Replikationsgruppe (Cluster-Modus deaktiviert) hinzuzufügen, verwenden Sie den ElastiCache `CreateCacheCluster` Vorgang mit dem Parameter, `ReplicationGroupId` um anzugeben, zu welcher Replikationsgruppe der Cluster (Knoten) hinzugefügt werden soll.
Im folgenden Beispiel wird der Cluster `myReadReplica` erstellt und zur Replikationsgruppe `myReplicationGroup` hinzugefügt. Die Knotentypen, Parametergruppen, Sicherheitsgruppen, das Wartungsfenster und andere Einstellungen für das Read Replica sind mit denen für die anderen Knoten in `myReplicationGroup` identisch.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheCluster
&CacheClusterId=myReadReplica
&ReplicationGroupId=myReplicationGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen zum Hinzufügen einer Read Replica mithilfe der API finden Sie [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html) in der *Amazon ElastiCache API-Referenz.*
# Löschen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert)
Die Informationen im folgenden Thema beziehen sich nur auf Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert).
Wenn sich der Lesedatenverkehr in Ihrer Valkey- oder Redis OSS-Replikationsgruppe ändert, möchten Sie möglicherweise Read Replicas hinzufügen oder entfernen. Das Entfernen eines Knotens aus einer -Replikationsgruppe ist mit dem Löschen eines Clusters vergleichbar, aber mit einigen Einschränkungen:
+ Der primäre Knoten kann nicht aus einer Replikationsgruppe entfernt werden. Wenn Sie den primären Knoten entfernen möchten, verfahren Sie wie folgt:
1. Stufen Sie eine Read Replica zum primären Knoten herauf. Weitere Informationen zum Heraufstufen einer Read Replica zum primären Knoten finden Sie unter [Heraufstufen einer Read Replica zu primären Replikationsgruppen für Valkey oder Redis OSS (Clustermodus deaktiviert)](Replication.PromoteReplica.md).
1. Löschen Sie den alten primären Knoten. Eine Einschränkung dieser Methode finden Sie im nächsten Gliederungspunkt.
+ Wenn Multi-AZ für eine Replikationsgruppe aktiviert ist, kann das letzte Read Replica nicht aus der Replikationsgruppe entfernt werden. Führen Sie in diesem Fall folgende Schritte aus:
1. Bearbeiten Sie die Replikationsgruppe, indem Sie Multi-AZ deaktivieren. Weitere Informationen finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
1. Löschen Sie das Read Replica.
Sie können eine Read Replica mit der ElastiCache Konsole, dem For oder der API aus einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) entfernen. AWS CLI ElastiCache ElastiCache
Anweisungen zum Löschen eines Clusters aus einer Valkey- oder Redis OSS-Replikationsgruppe finden Sie im Folgenden:
+ [Mit dem AWS-Managementkonsole](Clusters.Delete.md#Clusters.Delete.CON)
+ [Verwenden Sie den AWS CLI, um einen ElastiCache Cluster zu löschen](Clusters.Delete.md#Clusters.Delete.CLI)
+ [Verwenden der ElastiCache API](Clusters.Delete.md#Clusters.Delete.API)
+ [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md)
+ [Verringern der Anzahl der Replikate in einem Shard](decrease-replica-count.md)
# Heraufstufen einer Read Replica zu primären Replikationsgruppen für Valkey oder Redis OSS (Clustermodus deaktiviert)
Die Informationen im folgenden Thema beziehen sich nur auf Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus deaktiviert).
Sie können eine Valkey- oder Redis OSS-Lesereplik (Clustermodus deaktiviert) mithilfe der AWS-Managementkonsole, oder der API zur primären Replikation AWS CLI heraufstufen. ElastiCache Ein Read Replica kann nicht zum primären Knoten heraufgestuft werden, wenn für die -Replikationsgruppe Multi-AZ mit automatischem Failover aktiviert ist. Gehen Sie wie folgt vor, um ein Valkey- oder Redis OSS-Replikat (Clustermodus deaktiviert) in einer Multi-AZ-fähigen Replikationsgruppe zum Primärreplikat hochzustufen:
1. Bearbeiten Sie die Replikationsgruppe so, dass Multi-AZ deaktiviert wird (dazu müssen sich nicht alle Ihre Cluster in derselben Availability Zone befinden). Weitere Informationen finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
1. Stufen Sie das Lesereplikat zum primären Knoten herauf.
1. Bearbeiten Sie die Replikationsgruppe so, dass Multi-AZ wieder aktiviert ist.
Multi-AZ ist für Replikationsgruppen, auf denen Redis OSS 2.6.13 oder früher ausgeführt wird, nicht verfügbar.
## Unter Verwendung des AWS-Managementkonsole
Im folgenden Verfahren wird ein Replikatknoten mithilfe der Konsole zum primären Knoten heraufgestuft.
**Heraufstufen eines Lesereplikats zur primären (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wenn das Replikat, das Sie heraufstufen möchten, Mitglied einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) ist, in der Multi-AZ aktiviert ist, ändern Sie die Replikationsgruppe so, dass Multi-AZ deaktiviert wird, bevor Sie fortfahren. Weitere Informationen finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
1. Wählen Sie **Valkey** oder **Redis OSS** aus und wählen Sie dann aus der Clusterliste die Replikationsgruppe aus, die Sie ändern möchten. Diese Replikationsgruppe muss die "Redis"-Engine und nicht die "Clustered Redis"-Engine ausführen und muss aus mindestens zwei Knoten bestehen.
1. Wählen Sie aus der Liste der Knoten den Replikationsknoten aus, den Sie zum primären Knoten heraufstufen möchten. Wählen Sie dann für **Actions (Aktionen)** die Option **Promote (Heraufstufen)** aus.
1. Führen Sie im Dialogfeld **Promote Read Replica (Read Replica heraufstufen)** die folgenden Schritte aus:
1. Wählen Sie für **Apply Immediately (Sofort anwenden)** die Option **Yes (Ja)** aus, wenn das Read Replica sofort heraufgestuft weden soll, oder die Option **No (Nein)**, um es im nächsten Wartungsfenster des Clusters heraufzustufen.
1. Wählen Sie **Promote**, um die Read Replica heraufzustufen, oder **Cancel**, um die Operation abzubrechen.
1. Wenn für den Cluster vor Beginn des Hochstufens Multi-AZ aktiviert war, warten Sie, bis der Status der Replikationsgruppe **available (verfügbar)** lautet, bevor Sie den Cluster so bearbeiten, dass Multi-AZ wieder aktiviert wird. Weitere Informationen finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
## Unter Verwendung der AWS CLI
Sie können eine Read Replica nicht zum primären Knoten heraufstufen, wenn für die Replikationsgruppe Multi-AZ aktiviert ist. In einigen Fällen ist das heraufzustufende Replikat möglicherweise Teil einer Replikationsgruppe, in der Multi-AZ aktiviert ist. Sollte dies der Fall sein, muss Multi-AZ vor dem Fortfahren für die Replikationsgruppe deaktiviert werden. Für dieses Verfahren müssen sich nicht alle Ihre Cluster in der gleichen Availability Zone befinden. Weitere Informationen zum Ändern einer Replikationsgruppe finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
Mit dem folgenden AWS CLI Befehl wird die Replikationsgruppe geändert`sample-repl-group`, sodass die Read Replica zur primären Replica in `my-replica-1` der Replikationsgruppe wird.
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group \
--replication-group-id sample-repl-group \
--primary-cluster-id my-replica-1
```
Für Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id sample-repl-group ^
--primary-cluster-id my-replica-1
```
Weitere Informationen zum Ändern einer Replikationsgruppe finden Sie [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) in der *Amazon ElastiCache Command Line Reference.*
## Verwenden der ElastiCache API
Sie können eine Read Replica nicht zum primären Knoten heraufstufen, wenn für die Replikationsgruppe Multi-AZ aktiviert ist. In einigen Fällen ist das heraufzustufende Replikat möglicherweise Teil einer Replikationsgruppe, in der Multi-AZ aktiviert ist. Sollte dies der Fall sein, muss Multi-AZ vor dem Fortfahren für die Replikationsgruppe deaktiviert werden. Für dieses Verfahren müssen sich nicht alle Ihre Cluster in der gleichen Availability Zone befinden. Weitere Informationen zum Ändern einer Replikationsgruppe finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
Mit der folgenden ElastiCache API-Aktion wird die Replikationsgruppe geändert`myReplGroup`, sodass die Read Replica zur primären Replica in `myReplica-1` der Replikationsgruppe wird.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ReplicationGroupId=myReplGroup
&PrimaryClusterId=myReplica-1
&Version=2014-12-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Weitere Informationen zum Ändern einer Replikationsgruppe finden Sie [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) in der *Amazon ElastiCache API-Referenz.*
# Verwaltung der ElastiCache Cluster-Wartung
Jeder Cluster verfügt über ein wöchentliches Wartungsfenster, während dem alle Systemänderungen angewendet werden. Bei Valkey und Redis OSS haben Replikationsgruppen dasselbe wöchentliche Wartungsfenster. Wenn Sie bei der Erstellung oder Änderung eines Clusters oder einer Replikationsgruppe kein bevorzugtes Wartungsfenster angeben, ElastiCache weisen Sie innerhalb des Wartungsfensters Ihrer Region an einem zufällig ausgewählten Wochentag ein 60-minütiges Wartungsfenster zu.
Das 60-minütige Wartungsfenster wird zufällig aus einem 8-Stunden-Zeitraum pro Region ausgewählt. Die folgende Tabelle listet die Blöcke für jede Region auf, von denen die Standard-Wartungsfenster zugewiesen werden. Sie können ein bevorzugtes Wartungsfenster außerhalb des Wartungsfensterblocks der Region auswählen.
| Regionscode | Name der Region | Regionale Wartungsfenster |
| --- | --- | --- |
| ap-northeast-1 | Region Asien-Pazifik (Tokio) | 13:00 - 21:00 UHR UTC |
| ap-northeast-2 | Region Asien-Pazifik (Seoul) | 12:00 - 20:00 UTC |
| ap-northeast-3 | Region Asien-Pazifik (Osaka) | 12:00 - 20:00 UTC |
| ap-southeast-3 | Region Asien-Pazifik (Jakarta) | 14:00 - 22:00 UHR UTC |
| ap-south-1 | Region Asien-Pazifik (Mumbai) | 17:30 - 1:30 UHR UTC |
| ap-southeast-1 | Region Asien-Pazifik (Singapur) | 14:00 - 22:00 UHR UTC |
| cn-north-1 | Region China (Peking) | 14:00 - 22:00 UHR UTC |
| cn-northwest-1 | Region China (Ningxia) | 14:00 - 22:00 UHR UTC |
| ap-east-1 | Region Asien-Pazifik (Hongkong) | 13:00 - 21:00 UTC |
| ap-southeast-2 | Region Asien-Pazifik (Sydney) | 12:00 - 20:00 UHR UTC |
| eu-west-3 | Region Europa (Paris) | 23:59 - 07:29 UTC |
| af-south-1 | Region Afrika (Kapstadt) | 13:00 - 21:00 UTC |
| eu-central-1 | Region Europa (Frankfurt) | 23:00 - 07:00 UTC |
| eu-west-1 | Region Europa (Irland) | 22:00 bis 06:00 Uhr UTC |
| eu-west-2 | Region Europa (London) | 23:00 - 07:00 UTC |
| me-south-1 | Region Naher Osten (Bahrain) | 13:00 - 21:00 UTC |
| me-central-1 | Region „Naher Osten (VAE)“ | 13:00 - 21:00 UTC |
| eu-south-1 | Region Europa (Mailand) | 21:00 - 05:00 UTC |
| sa-east-1 | Region Südamerika (São Paulo) | 01:00 - 09:00 UHR UTC |
| us-east-1 | Region USA Ost (Nord-Virginia) | 03:00 - 11:00 UHR UTC |
| us-east-2 | Region USA Ost (Ohio) | 04:00 - 12:00 UHR UTC |
| us-gov-west-1 | AWS GovCloud (US) Region | 06:00 bis 14:00 Uhr UTC |
| us-west-1 | Region USA West (Nordkalifornien) | 06:00 - 14:00 UHR UTC |
| us-west-2 | Region USA West (Oregon) | 06:00 bis 14:00 Uhr UTC |
**Das Wartungsfenster Ihres Clusters oder Ihrer Replikationsgruppe ändern**
Das Wartungsfenster sollte in den Zeitraum mit der geringsten Nutzung fallen und daher unter Umständen von Zeit zu Zeit geändert werden. Sie können den Cluster oder die Replikationsgruppe ändern und einen Zeitraum mit einer Dauer von bis zu 24 Stunden festlegen, in dem alle angeforderten Wartungsaktivitäten durchgeführt werden sollen. In diesem Zeitraum werden alle verzögerten oder ausstehenden Cluster-Änderungen, die Sie angefordert haben, ausgeführt.
**Anmerkung**
Wenn Sie Änderungen am Knotentyp vornehmen möchten, aktivieren Sie das Kästchen **Jetzt anwenden, indem AWS-Managementkonsole Sie die Option and/or Engine-Upgrades sofort anwenden**. Andernfalls werden diese Änderungen während des nächsten geplanten Wartungsfensters angewendet. Informationen zur Verwendung der API finden Sie unter [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)oder [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html).
**Weitere Informationen**
Informationen zu Ihrem Wartungsfenster und dem Austausch von Knoten finden Sie unter:
+ [ElastiCache Wartung](https://aws.amazon.com/elasticache/elasticache-maintenance/) — Häufig gestellte Fragen zur Wartung und zum Austausch von Knoten
+ [Knoten ersetzen (Memcached)](CacheNodes.NodeReplacement-mc.md)— Verwaltung des Knotenaustauschs für Memcached
+ [Einen ElastiCache Cluster ändern](Clusters.Modify.md) – Ändern des Wartungsfensters für einen Cluster
+ [Knoten ersetzen (Valkey und Redis OSS)](CacheNodes.NodeReplacement.md) – Verwalten des Knotenaustauschs
+ [Ändern einer Replikationsgruppe](Replication.Modify.md) – Ändern des Wartungsfensters einer Replikationsgruppe
# Konfiguration von Motorparametern mithilfe von ElastiCache Parametergruppen
Amazon ElastiCache verwendet Parameter, um die Laufzeiteigenschaften Ihrer Knoten und Cluster zu steuern. In der Regel enthalten neuere Engine-Versionen zusätzliche Parameter zur Unterstützung der neueren Funktionalität. Tabellen mit Memcached-Parametern finden Sie unter. [Memcached-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached) Tabellen mit Valkey- und Redis-OSS-Parametern finden Sie unter. [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis)
Wie zu erwarten, werden einige Parameterwerte, wie z. B. `maxmemory` durch die Engine und den Knotentyp bestimmt. Eine Tabelle dieser Memcached-Parameterwerte nach Knotentyp finden Sie unter. [Spezifische Parameter des Memcached-Knotentyps](ParameterGroups.Engine.md#ParameterGroups.Memcached.NodeSpecific) Eine Tabelle dieser Valkey- und Redis OSS-Parameterwerte nach Knotentyp finden Sie unter. [Redis OSS-Knotentyp-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific)
**Anmerkung**
Eine Liste der Memcached-spezifischen Parameter finden Sie unter [Memcached-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached).
**Topics**
+ [Parameterverwaltung in ElastiCache](ParameterGroups.Management.md)
+ [Cache-Parametergruppen werden in ElastiCache](ParameterGroups.Tiers.md)
+ [Eine ElastiCache Parametergruppe erstellen](ParameterGroups.Creating.md)
+ [ElastiCache Parametergruppen nach Namen auflisten](ParameterGroups.ListingGroups.md)
+ [Werte einer ElastiCache Parametergruppe auflisten](ParameterGroups.ListingValues.md)
+ [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md)
+ [Löschen einer ElastiCache Parametergruppe](ParameterGroups.Deleting.md)
+ [Motorspezifische Parameter](ParameterGroups.Engine.md)
# Parameterverwaltung in ElastiCache
ElastiCache Parameter werden zur einfacheren Parameterverwaltung in benannten Parametergruppen zusammengefasst. Eine Parametergruppe stellt eine Kombination spezifischer Werte für die Parameter dar, die der Engine-Software während des Systemstarts übergeben werden. Diese Werte bestimmen, wie sich die Engine-Prozesse auf jedem Knoten während der Laufzeit verhalten. Die Parameterwerte für eine bestimmte Parametergruppe gelten für alle Knoten, die der betreffenden Gruppe zugehören. Dabei spielt es keine Rolle, zu welchem Cluster sie gehören.
Zur Feinabstimmung der Leistung Ihres Clusters können Sie einige Parameterwerte bearbeiten oder die Parametergruppe des Clusters ändern.
+ Standard-Parametergruppen können nicht geändert oder gelöscht werden. Wenn Sie benutzerdefinierte Parameterwerte benötigen, müssen Sie eine benutzerdefinierte Parametergruppe erstellen.
+ Für Memcached müssen die Parametergruppenfamilie und der Cluster, dem Sie sie zuweisen, kompatibel sein. Wenn Ihr Cluster z. B. Memcached Version 1.4.8 ausführt, können Sie nur Parametergruppen, Standard oder benutzerdefiniert, von der Memcached 1.4-Familie verwenden.
Für Redis OSS müssen die Parametergruppenfamilie und der Cluster, dem Sie sie zuweisen, kompatibel sein. Wenn auf Ihrem Cluster beispielsweise Redis OSS Version 3.2.10 ausgeführt wird, können Sie nur Standardparametergruppen oder benutzerdefinierte Parametergruppen aus der Redis OSS 3.2-Familie verwenden.
+ Wenn Sie die Parametergruppe eines Clusters ändern, müssen die Werte aller bedingungsabhängig veränderbaren Parameter in der aktuellen und in der neuen Parametergruppe übereinstimmen.
+ Wenn Sie bei Memcached die Parameter eines Clusters ändern, wird die Änderung sofort auf den Cluster angewendet. Dies gilt unabhängig davon, ob Sie die Parametergruppe des Clusters oder einen Parameterwert innerhalb der Parametergruppe des Clusters ändern. Anhand der Spalte **Changes Take Effect (Änderungen treten in Kraft)** in den Tabellen für [Memcached-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached) können Sie bestimmen, wann eine bestimmte Parameteränderung übernommen wird. Weitere Informationen zum Neustarten der Knoten eines Clusters finden Sie unter [Neustarten von Clustern](Clusters.html#Rebooting).
+ Wenn Sie bei Redis OSS die Parameter eines Clusters ändern, wird die Änderung entweder sofort oder, mit den unten genannten Ausnahmen, nach dem Neustart der Clusterknoten auf den Cluster angewendet. Dies gilt unabhängig davon, ob Sie die Parametergruppe des Clusters oder einen Parameterwert innerhalb der Parametergruppe des Clusters ändern. Anhand der Spalte **Changes Take Effect (Änderungen treten in Kraft)** in den Tabellen für [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis) können Sie bestimmen, wann eine bestimmte Parameteränderung übernommen wird.
Weitere Informationen zum Neustart von Valkey- oder Redis OSS-Knoten finden Sie unter. [Knoten neu starten](nodes.rebooting.md)
**Änderungen der Parameter Valkey oder Redis OSS (Cluster Mode Enabled)**
Wenn Sie Änderungen an den folgenden Parametern auf einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) vornehmen, gehen Sie wie folgt vor.
activerehashing
databases
Erstellen Sie eine manuelle Sicherung des Clusters. Siehe [Erstellen manueller Backups](backups-manual.md).
Löschen Sie den Cluster. Siehe [Löschen von Clustern](Clusters.html#Delete).
Stellen Sie den Cluster mit der abgeänderten Parametergruppe und der Sicherung zum Starten des neuen Clusters wieder her. Siehe [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md).
Bei Änderungen an anderen Parametern ist dies nicht erforderlich.
+ Sie können Parametergruppen globalen Valkey- und Redis OSS-Datenspeichern zuordnen. *Globale Datenspeicher* sind eine Sammlung von einem oder mehreren Clustern, die sich über Regionen erstrecken. AWS In diesem Fall wird die Parametergruppe von allen Clustern gemeinsam genutzt, die den globalen Datenspeicher bilden. Alle Änderungen an der Parametergruppe des primären Clusters werden auf alle verbleibenden Cluster im globalen Datenspeicher repliziert. Weitere Informationen finden Sie unter [AWS Regionsübergreifende Replikation mithilfe globaler Datenspeicher](Redis-Global-Datastore.md).
Sie können überprüfen, ob eine Parametergruppe Teil eines globalen Datenspeichers ist, indem Sie an folgenden Stellen suchen:
+ **In der ElastiCache Konsole auf der Seite „**Parametergruppen**“ das globale Attribut yes/no **
+ Die yes/no `IsGlobal` Eigenschaft des [CacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CacheParameterGroup.html)API-Vorgangs
# Cache-Parametergruppen werden in ElastiCache
Amazon ElastiCache hat drei Stufen von Cache-Parametergruppen, wie im Folgenden dargestellt.
![\[Bild: ElastiCache Amazon-Parametergruppenstufen\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCache-ParameterGroups-Tiers.png)
* ElastiCache Amazon-Parametergruppenstufen*
**Global Default**
Die Stammparametergruppe der obersten Ebene für alle ElastiCache Amazon-Kunden in der Region.
Die globale Standard-Cache-Parametergruppe:
+ Ist für den Kunden reserviert ElastiCache und steht ihm nicht zur Verfügung.
**Customer Default**
Eine Kopie der Cache-Parametergruppe „Global Default“, die für die Verwendung durch den Kunden erstellt wird.
Die Cache-Parametergruppe „Customer Default“:
+ Ist erstellt und gehört ihm ElastiCache.
+ Ist für den Kunden zur Verwendung als Cache-Parametergruppe für alle Cluster verfügbar, die eine Engine-Version ausführen, die von dieser Cache-Parametergruppe unterstützt wird.
+ Kann vom Kunden nicht bearbeitet werden.
**Customer Owned**
Eine Kopie der Cache-Parametergruppe „Customer Default“. Die Cache-Parametergruppe „Customer Owned“ wird immer dann erstellt, wenn der Kunde eine Cache-Parametergruppe anlegt.
Die Cache-Parametergruppe „Customer Owned“:
+ Wird vom Kunden erstellt und ist dessen Eigentum.
+ Kann beliebigen kompatiblen Clustern des Kunden zugeordnet werden.
+ Kann vom Kunden in eine benutzerdefinierte Cache-Parametergruppe abgewandelt werden.
Nicht alle Parameterwerte können geändert werden. Weitere Informationen zu Memcached-Werten finden Sie unter. [Memcached-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached) Weitere Informationen zu Valkey- und Redis-OSS-Werten finden Sie unter. [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis)
# Eine ElastiCache Parametergruppe erstellen
Sie müssen eine neue Parametergruppe erstellen, wenn Sie die Standardwerte für einen oder mehrere Parameterwerte ändern möchten. Sie können eine Parametergruppe mithilfe der ElastiCache Konsole AWS CLI, der oder der ElastiCache API erstellen.
## Eine ElastiCache Parametergruppe erstellen (Konsole)
Mit dem folgenden Verfahren wird eine Parametergruppe mithilfe der ElastiCache-Konsole erstellt.
**Um eine Parametergruppe mit der ElastiCache Konsole zu erstellen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Eine Liste aller verfügbaren Parametergruppen finden Sie, wenn Sie im linken Navigationsbereich **Parametergruppen** auswählen.
1. Um eine Parametergruppe zu erstellen, wählen Sie **Create Parameter Group**.
Der Bildschirm **Create Parameter Group** wird angezeigt.
1. Wählen Sie aus der Liste **Family** die Familie der Parametergruppe aus, die als Vorlage für Ihre Parametergruppe dienen soll.
Die Parametergruppenfamilie, wie z. B. *memcached1.4* oder *redis3.2*, definiert die tatsächlichen Parameter in Ihrer Parametergruppe und deren Anfangswerte. Die Familie der Parametergruppe muss mit der Engine und Version des Clusters übereinstimmen.
1. Geben Sie in das Feld **Name** einen eindeutigen Namen für diese Parametergruppe ein.
Wenn Sie einen Cluster erstellen oder die Parametergruppe eines Clusters ändern, wählen Sie die Parametergruppe nach Namen aus. Daher wird empfohlen, einen informativen und die Familie der Parametergruppe identifizierenden Namen zu wählen.
Namenseinschränkungen für die Parametergruppe:
+ Er muss mit einem ASCII-Buchstaben beginnen.
+ Er kann nur ASCII-Buchstaben, Ziffern und Bindestriche („-“) enthalten.
+ Er muss 1 – 255 Zeichen enthalten.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
1. Geben Sie in das Feld **Description** eine Beschreibung für die Parametergruppe ein.
1. Um die Parametergruppe zu erstellen, wählen Sie **Create**.
Um den Vorgang zu beenden, ohne die Parametergruppe zu erstellen, wählen Sie **Cancel**.
1. Die erstellte Parametergruppe besitzt die Standardwerte der Familie. Zum Ändern der Standardwerte müssen Sie die Parametergruppe abändern. Weitere Informationen finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md).
## Eine Parametergruppe erstellen () ElastiCache AWS CLI
Um eine Parametergruppe mit dem zu erstellen AWS CLI, verwenden Sie den Befehl `create-cache-parameter-group` mit diesen Parametern.
+ `--cache-parameter-group-name` Der Name der Parametergruppe.
Namenseinschränkungen für die Parametergruppe:
+ Er muss mit einem ASCII-Buchstaben beginnen.
+ Er kann nur ASCII-Buchstaben, Ziffern und Bindestriche („-“) enthalten.
+ Er muss 1 – 255 Zeichen enthalten.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
+ `--cache-parameter-group-family` Die Engine und Versionsfamilie der Parametergruppe.
+ `--description` Eine vom Benutzer eingegebene Beschreibung der Parametergruppe.
**Example**
Im folgenden Beispiel wird anhand der memcached1.4-Familie als Vorlage eine Parametergruppe namens *myMem14* erstellt.
Für Linux, macOS oder Unix:
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myMem14 \
--cache-parameter-group-family memcached1.4 \
--description "My first parameter group"
```
Für Windows:
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myMem14 ^
--cache-parameter-group-family memcached1.4 ^
--description "My first parameter group"
```
Die Ausgabe dieses Befehls sollte in etwa folgendermaßen aussehen.
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
}
```
**Example**
Im folgenden Beispiel wird anhand der redis2.8-Familie als Vorlage eine Parametergruppe namens *myRed28* erstellt.
Für Linux, macOS oder Unix:
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myRed28 \
--cache-parameter-group-family redis2.8 \
--description "My first parameter group"
```
Für Windows:
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myRed28 ^
--cache-parameter-group-family redis2.8 ^
--description "My first parameter group"
```
Die Ausgabe dieses Befehls sollte in etwa folgendermaßen aussehen.
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
}
```
Die erstellte Parametergruppe besitzt die Standardwerte der Familie. Zum Ändern der Standardwerte müssen Sie die Parametergruppe abändern. Weitere Informationen finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md).
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-parameter-group.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-parameter-group.html).
## Eine ElastiCache Parametergruppe (ElastiCache API) erstellen
Um eine Parametergruppe mithilfe der ElastiCache API zu erstellen, verwenden Sie die `CreateCacheParameterGroup` Aktion mit diesen Parametern.
+ `ParameterGroupName` Der Name der Parametergruppe.
Namenseinschränkungen für die Parametergruppe:
+ Er muss mit einem ASCII-Buchstaben beginnen.
+ Er kann nur ASCII-Buchstaben, Ziffern und Bindestriche („-“) enthalten.
+ Er muss 1 – 255 Zeichen enthalten.
+ Er darf keine zwei aufeinanderfolgenden Bindestriche enthalten.
+ Er darf nicht mit einem Bindestrich enden.
+ `CacheParameterGroupFamily` Die Engine und Versionsfamilie der Parametergruppe. Beispiel, `memcached1.4`.
+ `CacheParameterGroupFamily` Die Engine und Versionsfamilie der Parametergruppe. Beispiel, `redis2.8`.
+ `Description` Eine vom Benutzer eingegebene Beschreibung der Parametergruppe.
**Example**
Im folgenden Beispiel wird anhand der memcached1.4-Familie als Vorlage eine Parametergruppe namens *myMem14* erstellt.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheParameterGroup
&CacheParameterGroupFamily=memcached1.4
&CacheParameterGroupName=myMem14
&Description=My%20first%20parameter%20group
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Die Antwort auf diese Aktion sollte in etwa folgendermaßen aussehen.
```
myMem14memcached1.4My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
**Example**
Im folgenden Beispiel wird anhand der redis2.8-Familie als Vorlage eine Parametergruppe namens *myRed28* erstellt.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=CreateCacheParameterGroup
&CacheParameterGroupFamily=redis2.8
&CacheParameterGroupName=myRed28
&Description=My%20first%20parameter%20group
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Die Antwort auf diese Aktion sollte in etwa folgendermaßen aussehen.
```
myRed28redis2.8My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
Die erstellte Parametergruppe besitzt die Standardwerte der Familie. Zum Ändern der Standardwerte müssen Sie die Parametergruppe abändern. Weitere Informationen finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md).
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheParameterGroup.html).
# ElastiCache Parametergruppen nach Namen auflisten
Sie können die Parametergruppen mithilfe der ElastiCache Konsole AWS CLI, der oder der ElastiCache API auflisten.
## Auflisten von Parametergruppen nach Namen (Konsole)
Mit dem folgenden Verfahren wird eine Liste der Parametergruppen mithilfe der ElastiCache -Konsole angezeigt.
**Um Parametergruppen mithilfe der ElastiCache Konsole aufzulisten**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Eine Liste aller verfügbaren Parametergruppen finden Sie, wenn Sie im linken Navigationsbereich **Parametergruppen** auswählen.
## ElastiCache Parametergruppen nach Namen auflisten (AWS CLI)
Verwenden Sie den Befehl, um mit dem AWS CLI eine Liste von Parametergruppen zu generieren`describe-cache-parameter-groups`. Wenn Sie den Namen einer Parametergruppe angeben, wird nur die betreffende Parametergruppe aufgelistet. Wenn Sie keinen Namen einer Parametergruppe angeben,werden bis zu `--max-records` Parametergruppen aufgelistet. In beiden Fälle werden Name, Familie und Beschreibung der Parametergruppe aufgelistet.
**Example**
Der folgenden Beispielcode listet die Parametergruppe *myMem14* auf.
Für Linux, macOS oder Unix:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myMem14
```
Für Windows:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myMem14
```
Die Ausgabe dieses Befehls sieht folgendermaßen aus und listet Name, Familie und Beschreibung der Parametergruppe auf.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
]
}
```
**Example**
Der folgenden Beispielcode listet die Parametergruppe *myRed28* auf.
Für Linux, macOS oder Unix:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed28
```
Für Windows:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed28
```
Die Ausgabe dieses Befehls sieht folgendermaßen aus und listet Name, Familie und Beschreibung der Parametergruppe auf.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
]
}
```
**Example**
Der folgende Beispielcode listet die Parametergruppe *myRed56* für Parametergruppen auf, die auf der Redis OSS-Engine ab Version 5.0.6 ausgeführt werden. Wenn die Parametergruppe Teil einer [AWS Regionsübergreifende Replikation mithilfe globaler Datenspeicher](Redis-Global-Datastore.md) ist, ist der in der Ausgabe zurückgegebene `IsGlobal`-Eigenschaftswert `Yes`.
Für Linux, macOS oder Unix:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed56
```
Für Windows:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed56
```
Die Ausgabe dieses Befehls sieht folgendermaßen aus und listet den Namen, die Familie „isGlobal“ und die Beschreibung der Parametergruppe auf.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed56",
"CacheParameterGroupFamily": "redis5.0",
"Description": "My first parameter group",
"IsGlobal": "yes"
}
]
}
```
**Example**
Der folgenden Beispielcode listet bis zu 10 Parametergruppen auf.
```
aws elasticache describe-cache-parameter-groups --max-records 10
```
Die JSON-Ausgabe dieses Befehls sieht ungefähr so aus und listet für jede Parametergruppe den Namen, die Familie, die Beschreibung und im Fall von redis5.6, ob die Parametergruppe Teil eines globalen Datenspeichers (IsGlobal) ist, auf.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "custom-redis32",
"CacheParameterGroupFamily": "redis3.2",
"Description": "custom parameter group with reserved-memory > 0"
},
{
"CacheParameterGroupName": "default.memcached1.4",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "Default parameter group for memcached1.4"
},
{
"CacheParameterGroupName": "default.redis2.6",
"CacheParameterGroupFamily": "redis2.6",
"Description": "Default parameter group for redis2.6"
},
{
"CacheParameterGroupName": "default.redis2.8",
"CacheParameterGroupFamily": "redis2.8",
"Description": "Default parameter group for redis2.8"
},
{
"CacheParameterGroupName": "default.redis3.2",
"CacheParameterGroupFamily": "redis3.2",
"Description": "Default parameter group for redis3.2"
},
{
"CacheParameterGroupName": "default.redis3.2.cluster.on",
"CacheParameterGroupFamily": "redis3.2",
"Description": "Customized default parameter group for redis3.2 with cluster mode on"
},
{
"CacheParameterGroupName": "default.redis5.6.cluster.on",
"CacheParameterGroupFamily": "redis5.0",
"Description": "Customized default parameter group for redis5.6 with cluster mode on",
"isGlobal": "yes"
},
]
}
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameter-groups.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameter-groups.html).
## ElastiCache Parametergruppen nach Namen auflisten (API) ElastiCache
Verwenden Sie die `DescribeCacheParameterGroups` Aktion, um mithilfe der ElastiCache API eine Liste von Parametergruppen zu generieren. Wenn Sie den Namen einer Parametergruppe angeben, wird nur die betreffende Parametergruppe aufgelistet. Wenn Sie keinen Namen einer Parametergruppe angeben,werden bis zu `MaxRecords` Parametergruppen aufgelistet. In beiden Fälle werden Name, Familie und Beschreibung der Parametergruppe aufgelistet.
**Example**
Der folgenden Beispielcode listet die Parametergruppe *myMem14* auf.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Die Antwort auf diese Aktion sieht folgendermaßen aus und listet Name, Familie und Beschreibung jeder Parametergruppe auf.
```
myMem14memcached1.4My custom Memcached 1.4 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
Der folgenden Beispielcode listet bis zu 10 Parametergruppen auf.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&MaxRecords=10
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Die Antwort dieser Aktion sieht ungefähr so aus und listet für jede Parametergruppe den Namen, die Familie, die Beschreibung und im Fall von redis5.6, ob die Parametergruppe zu einem globalen Datenspeicher (IsGlobal) gehört, auf.
```
myRedis28redis2.8My custom Redis 2.8 parameter groupmyMem14memcached1.4My custom Memcached 1.4 parameter groupmyRedis56redis5.0My custom redis 5.6 parameter groupyes3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
Der folgenden Beispielcode listet die Parametergruppe *myRed28* auf.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Die Antwort auf diese Aktion sieht folgendermaßen aus und listet den Namen, die Familie und die Beschreibung auf.
```
myRed28redis2.8My custom Redis 2.8 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
Der folgende Beispiel-Code listet die Parametergruppe *myRed56* auf.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed56
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Die Antwort dieser Aktion sieht ungefähr so aus und listet den Namen, die Familie, die Beschreibung, und ob die Parametergruppe Teil eines globalen Datenspeichers (IsGlobal) ist, auf.
```
myRed56redis5.0My custom Redis 5.6 parameter groupyes3540cc3d-af48-11e0-97f9-279771c4477e
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameterGroups.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameterGroups.html).
# Werte einer ElastiCache Parametergruppe auflisten
Sie können die Parameter und ihre Werte für eine Parametergruppe mithilfe der ElastiCache Konsole AWS CLI, der oder der ElastiCache API auflisten.
## Die Werte einer ElastiCache Parametergruppe auflisten (Konsole)
Das folgende Verfahren zeigt, wie Sie die Parameter und ihre Werte für eine Parametergruppe mithilfe der ElastiCache Konsole auflisten.
**So listen Sie die Parameter und deren Werte für eine Parametergruppe mithilfe der ElastiCache-Konsole auf**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Eine Liste aller verfügbaren Parametergruppen finden Sie, wenn Sie im linken Navigationsbereich **Parametergruppen** auswählen.
1. Wählen Sie die Parametergruppe aus, für die Sie die Parameter und Werte auflisten möchten, indem Sie das Kontrollkästchen links neben dem Namen der Parametergruppe aktivieren.
Die Parameter und deren Werten werden unten auf dem Bildschirm aufgelistet. Aufgrund der Anzahl der Parameter müssen Sie möglicherweise nach oben und unten scrollen, um den Parameter zu finden, an dem Sie interessiert sind.
## Auflisten der Werte einer Parametergruppe (AWS CLI)
Um die Parameter einer Parametergruppe und ihre Werte mithilfe von aufzulisten AWS CLI, verwenden Sie den Befehl`describe-cache-parameters`.
**Example**
*Der folgende Beispielcode listet alle Memcached-Parameter und ihre Werte für die Parametergruppe MyMem14 auf.*
Für Linux, macOS oder Unix:
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myMem14
```
Für Windows:
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myMem14
```
**Example**
Der folgende Beispielcode listet alle Parameter und deren Werte für die Parametergruppe *myRedis28* auf.
Für Linux, macOS oder Unix:
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myRedis28
```
Für Windows:
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myRed28
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameters.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-parameters.html).
## Auflisten der Werte einer Parametergruppe (API) ElastiCache
Verwenden Sie die `DescribeCacheParameters` Aktion, um die Parameter einer Parametergruppe und ihre Werte mithilfe der ElastiCache API aufzulisten.
**Example**
*Der folgende Beispielcode listet alle Memcached-Parameter für die Parametergruppe MyMem14 auf.*
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameters
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Die Antwort auf diese Aktion sieht in etwa folgendermaßen aus. Diese Antwort wurde abgeschnitten.
```
integersystemfalseThe maximum configurable amount of memory to use to store items, in megabytes.1000cache.c1.medium6000cache.c1.xlarge7100cache.m1.large1300cache.m1.small
...output omitted...
6d355589-af49-11e0-97f9-279771c4477e
```
**Example**
Der folgende Beispielcode listet alle Parameter für die Parametergruppe *myRed28* auf.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameters
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Die Antwort auf diese Aktion sieht in etwa folgendermaßen aus. Diese Antwort wurde abgeschnitten.
```
integersystemfalseThe maximum configurable amount of memory to use to store items, in megabytes.1000cache.c1.medium6000cache.c1.xlarge7100cache.m1.large1300cache.m1.small
...output omitted...
6d355589-af49-11e0-97f9-279771c4477e
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameters.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameters.html).
# Änderung einer ElastiCache Parametergruppe
**Wichtig**
Die Standard-Parametergruppe kann nicht abgeändert werden.
Einige Parameterwerte in einer Parametergruppe können bearbeitet werden. Diese Parameterwerte werden auf die zur Parametergruppe gehörenden Cluster angewendet. Weitere Informationen dazu, wann eine Änderung eines Parameterwerts auf eine Parametergruppe angewendet wird, finden Sie unter [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis) und[Memcached-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached).
## Ändern einer Parametergruppe (Konsole)
Das folgende Verfahren zeigt, wie Sie den Wert des `cluster-enabled` Parameters mithilfe der ElastiCache Konsole ändern können. Dieses Verfahren ist bei der Bearbeitung des Wertes aller Parameter gleich.
**So ändern Sie den Wert eines Parameters mithilfe der ElastiCache Konsole**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Eine Liste aller verfügbaren Parametergruppen finden Sie, wenn Sie im linken Navigationsbereich **Parametergruppen** auswählen.
1. Wählen Sie die Parametergruppe aus, die Sie bearbeiten möchten, indem Sie das Kontrollkästchen links neben dem Namen der Parametergruppe aktivieren.
Die Parameter der Parametergruppe werden unten auf dem Bildschirm aufgelistet. Sie können die Liste seitenweise durchlaufen, um alle Parameter zu sehen.
1. Um einen oder mehrere Parameter zu bearbeiten, wählen Sie **Edit Parameters**.
1. Scrollen Sie auf dem Bildschirm **Edit Parameter Group:** mit der linken und rechten Pfeiltaste, bis Sie zum Parameter `binding_protocol` gelangen. Geben Sie dann `ascii` in die Spalte **Value** ein.
1. Wählen Sie **Save Changes**.
1. Informationen zum Namen des Parameters, den Sie geändert haben, finden Sie unter. [Memcached-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached) Wenn als Zeitpunkt für die Übernahme der Parameteränderung *After restart* festgelegt ist, starten Sie jeden Cluster neu, der von dieser Parametergruppe Gebrauch macht. Weitere Informationen finden Sie unter [Neustarten von Clustern](Clusters.html#Rebooting).
1. Bei Valkey und Redis OSS finden Sie den Namen des Parameters, den Sie geändert haben, unter. [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis) Wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) haben und Änderungen an den folgenden Parametern vornehmen, müssen Sie die Knoten im Cluster neu starten:
+ activerehashing
+ databases
Weitere Informationen finden Sie unter [Knoten neu starten](nodes.rebooting.md).
**Änderungen der Parameter Valkey oder Redis OSS (Clustermodus aktiviert)**
Wenn Sie Änderungen an den folgenden Parametern auf einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) vornehmen, gehen Sie wie folgt vor.
activerehashing
databases
Mit Redis OSS können Sie ein manuelles Backup Ihres Clusters erstellen. Siehe [Erstellen manueller Backups](backups-manual.md).
Löschen Sie den Cluster. Siehe [Löschen von Clustern](Clusters.html#Delete).
Stellen Sie den Cluster mit der abgeänderten Parametergruppe und der Sicherung zum Starten des neuen Clusters wieder her. Siehe [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md).
Bei Änderungen an anderen Parametern ist dies nicht erforderlich.
## Ändern einer Parametergruppe (AWS CLI)
Um den Wert eines Parameters mit dem zu ändern AWS CLI, verwenden Sie den Befehl. `modify-cache-parameter-group`
**Example**
Bei Memcached finden Sie den Namen und die zulässigen Werte des Parameters, den Sie ändern möchten, unter [Memcached-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached)
Der folgende Beispiel-Code legt den Wert zweier Parameter fest: *chunk\$1size* und *chunk\$1size\$1growth\$1fact* auf der Parametergruppe `myMem14`.
Für Linux, macOS oder Unix:
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name myMem14 \
--parameter-name-values \
ParameterName=chunk_size,ParameterValue=96 \
ParameterName=chunk_size_growth_fact,ParameterValue=1.5
```
Für Windows:
```
aws elasticache modify-cache-parameter-group ^
--cache-parameter-group-name myMem14 ^
--parameter-name-values ^
ParameterName=chunk_size,ParameterValue=96 ^
ParameterName=chunk_size_growth_fact,ParameterValue=1.5
```
Die Ausgabe dieses Befehls sieht in etwa folgendermaßen aus.
```
{
"CacheParameterGroupName": "myMem14"
}
```
**Example**
Bei Valkey und Redis OSS finden Sie den Namen und die zulässigen Werte des Parameters, den Sie ändern möchten, unter [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis)
Im folgenden Beispielcode wird der Wert von zwei Parametern festgelegt *reserved-memory-percent*und für die *Parametergruppe ein Cluster aktiviert*. `myredis32-on-30` Wir setzen *reserved-memory-percent*auf `30` (30 Prozent) und *cluster-enabled* auf, `yes` sodass die Parametergruppe mit Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert) (Replikationsgruppen) verwendet werden kann.
Für Linux, macOS oder Unix:
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name myredis32-on-30 \
--parameter-name-values \
ParameterName=reserved-memory-percent,ParameterValue=30 \
ParameterName=cluster-enabled,ParameterValue=yes
```
Für Windows:
```
aws elasticache modify-cache-parameter-group ^
--cache-parameter-group-name myredis32-on-30 ^
--parameter-name-values ^
ParameterName=reserved-memory-percent,ParameterValue=30 ^
ParameterName=cluster-enabled,ParameterValue=yes
```
Die Ausgabe dieses Befehls sieht in etwa folgendermaßen aus.
```
{
"CacheParameterGroupName": "my-redis32-on-30"
}
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-parameter-group.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-parameter-group.html).
Den Namen des Parameters, den Sie in einem dieser Themen bearbeitet haben, finden Sie unter [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis).
Wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) haben und Änderungen an den folgenden Parametern vornehmen, müssen Sie die Knoten im Cluster neu starten:
+ activerehashing
+ databases
Weitere Informationen finden Sie unter [Knoten neu starten](nodes.rebooting.md).
**Änderungen der Parameter Valkey oder Redis OSS (Clustermodus aktiviert)**
Wenn Sie Änderungen an den folgenden Parametern auf einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) vornehmen, gehen Sie wie folgt vor.
activerehashing
databases
Erstellen Sie eine manuelle Sicherung des Clusters. Siehe [Erstellen manueller Backups](backups-manual.md).
Löschen Sie den Cluster. Siehe [Löschen von Clustern](Clusters.html#Delete).
Stellen Sie den Cluster mit der abgeänderten Parametergruppe und der Sicherung zum Starten des neuen Clusters wieder her. Siehe [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md).
Bei Änderungen an anderen Parametern ist dies nicht erforderlich.
## Ändern einer Parametergruppe (API) ElastiCache
Verwenden Sie die `ModifyCacheParameterGroup` Aktion, um die Parameterwerte einer Parametergruppe mithilfe der ElastiCache API zu ändern.
**Example**
Bei Memcached finden Sie den Namen und die zulässigen Werte des Parameters, den Sie ändern möchten, unter [Memcached-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached)
Der folgende Beispiel-Code legt den Wert zweier Parameter fest: *chunk\$1size* und *chunk\$1size\$1growth\$1fact* auf der Parametergruppe `myMem14`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheParameterGroup
&CacheParameterGroupName=myMem14
&ParameterNameValues.member.1.ParameterName=chunk_size
&ParameterNameValues.member.1.ParameterValue=96
&ParameterNameValues.member.2.ParameterName=chunk_size_growth_fact
&ParameterNameValues.member.2.ParameterValue=1.5
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
**Example**
Bei Valkey und Redis OSS finden Sie den Namen und die zulässigen Werte des Parameters, den Sie ändern möchten, unter [Valkey- und Redis OSS-Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis)
Im folgenden Beispielcode wird der Wert von zwei Parametern festgelegt *reserved-memory-percent*und für die *Parametergruppe ein Cluster aktiviert*. `myredis32-on-30` Wir setzen *reserved-memory-percent*auf `30` (30 Prozent) und *cluster-enabled* auf, `yes` sodass die Parametergruppe mit Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert) (Replikationsgruppen) verwendet werden kann.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheParameterGroup
&CacheParameterGroupName=myredis32-on-30
&ParameterNameValues.member.1.ParameterName=reserved-memory-percent
&ParameterNameValues.member.1.ParameterValue=30
&ParameterNameValues.member.2.ParameterName=cluster-enabled
&ParameterNameValues.member.2.ParameterValue=yes
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheParameterGroup.html).
Wenn Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) haben und Änderungen an den folgenden Parametern vornehmen, müssen Sie die Knoten im Cluster neu starten:
+ activerehashing
+ databases
Weitere Informationen finden Sie unter [Knoten neu starten](nodes.rebooting.md).
**Änderungen der Parameter Valkey oder Redis OSS (Clustermodus aktiviert)**
Wenn Sie Änderungen an den folgenden Parametern auf einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) vornehmen, gehen Sie wie folgt vor.
activerehashing
databases
Erstellen Sie eine manuelle Sicherung des Clusters. Siehe [Erstellen manueller Backups](backups-manual.md).
Löschen Sie den Cluster. Siehe [Löschen eines Clusters in ElastiCache](Clusters.Delete.md).
Stellen Sie den Cluster mit der abgeänderten Parametergruppe und der Sicherung zum Starten des neuen Clusters wieder her. Siehe [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md).
Bei Änderungen an anderen Parametern ist dies nicht erforderlich.
# Löschen einer ElastiCache Parametergruppe
Sie können eine benutzerdefinierte Parametergruppe mithilfe der ElastiCache Konsole AWS CLI, der oder der ElastiCache API löschen.
Parametergruppen, die Clustern zugeordnet sind, können nicht gelöscht werden. Standard-Parametergruppen können ebenfalls nicht gelöscht werden.
## Löschen einer Parametergruppe (Konsole)
Mit dem folgenden Verfahren wird eine Parametergruppe mithilfe der ElastiCache-Konsole gelöscht.
**Um eine Parametergruppe mit der ElastiCache Konsole zu löschen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Eine Liste aller verfügbaren Parametergruppen finden Sie, wenn Sie im linken Navigationsbereich **Parametergruppen** auswählen.
1. Wählen Sie die Parametergruppen aus, die Sie löschen möchten, indem Sie das Kontrollkästchen links neben dem Namen der Parametergruppe aktivieren.
Die Schaltfläche **Löschen** wird aktiv.
1. Wählen Sie **Löschen** aus.
Der Bestätigungsbildschirm **Delete Parameter Groups** wird angezeigt.
1. Zum Löschen der Parametergruppen wählen Sie auf dem Bestätigungsbildschirm **Delete Parameter Groups** die Option **Delete** aus.
Um die Parametergruppen beizubehalten, wählen Sie **Cancel**.
## Löschen einer Parametergruppe (AWS CLI)
Um eine Parametergruppe mit dem zu löschen AWS CLI, verwenden Sie den Befehl`delete-cache-parameter-group`. Der durch `--cache-parameter-group-name` angegebenen Parametergruppe dürfen eine Cluster zugeordnet sein und es darf sich nicht um eine Standard-Parametergruppe handeln, damit sie gelöscht wird.
Der folgenden Beispielcode löscht die Parametergruppe *myMem14*.
**Example**
Für Linux, macOS oder Unix:
```
aws elasticache delete-cache-parameter-group \
--cache-parameter-group-name myRed28
```
Für Windows:
```
aws elasticache delete-cache-parameter-group ^
--cache-parameter-group-name myRed28
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-parameter-group.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-parameter-group.html).
## Löschen einer Parametergruppe (ElastiCache API)
Verwenden Sie die `DeleteCacheParameterGroup` Aktion, um eine Parametergruppe mithilfe der ElastiCache API zu löschen. Der durch `CacheParameterGroupName` angegebenen Parametergruppe dürfen eine Cluster zugeordnet sein und es darf sich nicht um eine Standard-Parametergruppe handeln, damit sie gelöscht wird.
**Example**
Bei Memcached löscht der folgende Beispielcode die *MyMem14-Parametergruppe*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheParameterGroup
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
**Example**
Der folgenden Beispielcode löscht die Parametergruppe *myRed28*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DeleteCacheParameterGroup
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteCacheParameterGroup.html).
# Motorspezifische Parameter
**Valkey und Redis OSS**
Die meisten Valkey 8-Parameter sind mit den Redis OSS 7.1-Parametern kompatibel. Die Valkey 7.2-Parameter sind dieselben wie die Redis OSS 7-Parameter.
Wenn Sie keine Parametergruppe für Ihren Valkey- oder Redis OSS-Cluster angeben, wird eine Standardparametergruppe verwendet, die Ihrer Engine-Version entspricht. Sie können die Werte von Parametern in der Standard-Parametergruppe nicht ändern. Sie können jedoch jederzeit eine benutzerdefinierte Parametergruppe erstellen und sie Ihrem Cluster zuordnen, solange die Werte von bedingungsabhängig veränderbaren Parametern in beiden Parametergruppen gleich sind. Weitere Informationen finden Sie unter [Eine ElastiCache Parametergruppe erstellen](ParameterGroups.Creating.md).
**Topics**
+ [Valkey- und Redis OSS-Parameter](#ParameterGroups.Redis)
+ [Memcached-spezifische Parameter](#ParameterGroups.Memcached)
## Valkey- und Redis OSS-Parameter
**Topics**
+ [Änderungen der Valkey 8.2-Parameter](#ParameterGroups.Valkey.8.2)
+ [Valkey 8.1-Parameteränderungen](#ParameterGroups.Valkey.8.1)
+ [Valkey 8.0-Parameteränderungen](#ParameterGroups.Valkey.8)
+ [Änderungen der Parameter von Valkey 7.2 und Redis OSS 7](#ParameterGroups.Redis.7)
+ [Änderungen der Parameter in Redis OSS 6.x](#ParameterGroups.Redis.6-x)
+ [Änderungen an den Parametern von Redis OSS 5.0.3](#ParameterGroups.Redis.5-0-3)
+ [Änderungen der Parameter von Redis OSS 5.0.0](#ParameterGroups.Redis.5.0)
+ [Änderungen an den Parametern von Redis OSS 4.0.10](#ParameterGroups.Redis.4-0-10)
+ [Änderungen an den Parametern von Redis OSS 3.2.10](#ParameterGroups.Redis.3-2-10)
+ [Änderungen der Parameter in Redis OSS 3.2.6](#ParameterGroups.Redis.3-2-6)
+ [Änderungen der Parameter in Redis OSS 3.2.4](#ParameterGroups.Redis.3-2-4)
+ [Redis OSS 2.8.24 (erweitert) hat Parameter hinzugefügt](#ParameterGroups.Redis.2-8-24)
+ [Redis OSS 2.8.23 (erweitert) hat Parameter hinzugefügt](#ParameterGroups.Redis.2-8-23)
+ [Redis OSS 2.8.22 (erweitert) hat Parameter hinzugefügt](#ParameterGroups.Redis.2-8-22)
+ [Redis OSS 2.8.21 hat Parameter hinzugefügt](#ParameterGroups.Redis.2-8-21)
+ [Redis OSS 2.8.19 hat Parameter hinzugefügt](#ParameterGroups.Redis.2-8-19)
+ [Redis OSS 2.8.6 hat Parameter hinzugefügt](#ParameterGroups.Redis.2-8-6)
+ [Redis OSS 2.6.13-Parameter](#ParameterGroups.Redis.2-6-13)
+ [Redis OSS-Knotentyp-spezifische Parameter](#ParameterGroups.Redis.NodeSpecific)
### Änderungen der Valkey 8.2-Parameter
**Parametergruppenfamilie: valkey8**
**Anmerkung**
Die Parameteränderungen von Valkey 8.2 gelten nicht für Valkey 8.1
Parametergruppen von Valkey 8.0 und höher sind mit Redis OSS 7.2.4 nicht kompatibel.
In Valkey 8.2 sind die folgenden Befehle für serverlose Caches nicht verfügbar:,,, und `commandlog` `commandlog get` `commandlog help` `commandlog len` `commandlog reset.`
**Neue Parametergruppen in Valkey 8.2**
| Name | Details | Description |
| --- | --- | --- |
| search-fanout-target-mode (in 8.2 hinzugefügt) | Standard: Client Type: Zeichenkette Veränderbar: Ja Änderungen werden wirksam: sofort | Der search-fanout-target-mode Konfigurationsparameter steuert, wie Suchanfragen auf die Knoten in einer Valkey-Cluster-Umgebung verteilt werden. Diese Einstellung akzeptiert zwei Werte: „Throughput“, der für maximalen Durchsatz optimiert wird, indem Suchabfragen unabhängig vom Clienttyp oder READONLY-Status nach dem Zufallsprinzip auf alle Clusterknoten verteilt werden, und „Client“, der die Verbindungseigenschaften der Clients respektiert, indem nicht schreibgeschützte Clients nur an primäre Knoten, READONLY-Clients nur auf Replikatverbindungen zu Replikatknoten und READONLY-Clients auf primären Verbindungen nach dem Zufallsprinzip über alle Knoten weitergeleitet werden. Das Standardverhalten ist der „Client“ -Modus, was bedeutet, dass das System die Client-Verbindungstypen und den READONLY-Status bei Routing-Entscheidungen für Abfragen berücksichtigt. Verwenden Sie den Durchsatzmodus für umfangreiche Such-Workloads, bei denen eine maximale Auslastung der Clusterressourcen gewünscht wird, und den Client-Modus, wenn Sie die read/write Trennung beibehalten und READONLY-Verbindungsmuster auf Anwendungsebene respektieren möchten. |
| search-default-timeout-ms | Standard: 50000 Zulässige Werte: 1 bis 60000 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: sofort | Das standardmäßige Timeout für Valkey-Suchanfragen (in Millisekunden). |
| search-enable-partial-results | Standard: yes Zulässige Werte: ja, nein Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: sofort | Konfiguriert das Verhalten bei Abfragefehlern für die Valkey-Suche. Wenn diese Option aktiviert ist, geben Suchanfragen unvollständige Ergebnisse zurück, wenn Timeouts bei einem oder mehreren Shards auftreten. Wenn diese Option deaktiviert ist, führt jedes Shard-Timeout dazu, dass die gesamte Suchabfrage fehlschlägt und ein Fehler zurückgegeben wird. |
### Valkey 8.1-Parameteränderungen
**Parametergruppenfamilie: valkey8**
**Anmerkung**
Valkey 8.1-Parameteränderungen gelten nicht für Valkey 8.0
Parametergruppen von Valkey 8.0 und höher sind mit Redis OSS 7.2.4 nicht kompatibel.
In Valkey 8.1 sind die folgenden Befehle für serverlose Caches nicht verfügbar:,,, und `commandlog` `commandlog get` `commandlog help` `commandlog len` `commandlog reset.`
**Neue Parametergruppen in Valkey 8.1**
| Name | Details | Description |
| --- | --- | --- |
| commandlog-large-request-max-len (in 8.1 hinzugefügt) | Standard: 1048576 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: sofort | Die maximale Größe in Byte für Anfragen, die von der Valkey Command Log-Funktion protokolliert werden können. |
| commandlog-large-request-max-len (in 8.1 hinzugefügt) | Standard: 128 Zulässige Werte: 0-1024 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: sofort | Die maximale Länge des Valkey-Befehlsprotokolls für Anfragen. |
| commandlog-reply-larger-than (in 8.1 hinzugefügt) | Standard: 1048576 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: sofort | Die maximale Größe (in Byte) für Antworten, die von der Valkey Command Log-Funktion protokolliert werden können. |
| commandlog-large-reply-max-len (in 8.1 hinzugefügt) | Standard: 128 Zulässige Werte: 0-1024 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: sofort | Die maximale Länge des Valkey-Befehlsprotokolls für Antworten. |
### Valkey 8.0-Parameteränderungen
**Parametergruppenfamilie: valkey8**
**Anmerkung**
Redis OSS 7.2.4 ist nicht mit Parametergruppen von Valkey 8 und höher kompatibel.
**Spezifische Parameteränderungen in Valkey 8.0**
| Name | Details | Description |
| --- | --- | --- |
| repl-backlog-size | Standard: 10485760 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: sofort | Die Größe, in Byte, des Bacḱlogs des primären Knotens. Das Backlog dient zur Aufzeichnung von Aktualisierungen an den Daten auf dem primären Knoten. Wenn eine Read Replica eine Verbindung zum Primärknoten herstellt, versucht sie, eine Teilsynchronisierung (psync) durchzuführen, bei der sie Daten aus dem Backlog anwendet, um catch dem Primärknoten Schritt zu halten. Wenn der Psync fehlschlägt, ist eine vollständige Synchronisierung erforderlich. Der Mindestwert für diesen Parameter ist 16384. Hinweis: Ab Redis OSS 2.8.22 gilt dieser Parameter sowohl für den primären Cluster als auch für die Read Replicas. |
| maxmemory-samples | Standard: 3 Zulässige Werte: 1 bis 64 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: sofort | Bei Berechnungen least-recently-used (LRU) und time-to-live (TTL) stellt dieser Parameter die Stichprobengröße der zu überprüfenden Schlüssel dar. Standardmäßig wählt Redis OSS 3 Schlüssel aus und verwendet den Schlüssel, der zuletzt verwendet wurde. |
**Neue Parametergruppen in Valkey 8.0**
| Name | Details | Description |
| --- | --- | --- |
| extended-redis-compatibility | Zulässige Werte: ja, nein Standard: yes Typ: Boolesch Veränderbar: Ja Änderungen treten in Kraft: sofort | Im erweiterten Redis OSS-Kompatibilitätsmodus gibt Valkey vor, Redis OSS 7.2 zu sein. Aktivieren Sie diese Option nur, wenn Sie Probleme mit Tools oder Clients haben. Auswirkungen auf Kunden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
**Parametergruppen wurden in Valkey 8.0 entfernt**
| Name | Details | Description |
| --- | --- | --- |
| lazyfree-lazy-eviction | Zulässige Werte: ja, nein Standard: no Typ: Boolesch Veränderbar: Ja Änderungen treten in Kraft: sofort | Führt eine asynchrone Löschung bei Bereinigungen durch. |
| lazyfree-lazy-expire | Zulässige Werte: ja, nein Standard: no Typ: Boolesch Veränderbar: Ja Änderungen treten in Kraft: sofort | Führt eine asynchrone Löschung bei abgelaufenen Schlüsseln durch. |
| lazyfree-lazy-server-del | Zulässige Werte: ja, nein Standard: no Typ: Boolesch Veränderbar: Ja Änderungen treten in Kraft: sofort | Führt eine asynchrone Löschung bei Befehlen durch, die Werte aktualisieren. |
| lazyfree-lazy-user-del | Standard: no Typ: Zeichenfolge Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Wenn der Wert auf Ja gesetzt ist, verhält sich der Befehl DEL genauso wie UNLINK. |
| replica-lazy-flush | Standard: yes Typ: Boolesch Veränderbar: Nein Früherer Name: slave-lazy-flush | Führt einen asynchronen flushDB-Befehl während einer Replikatsynchronisierung durch |
### Änderungen der Parameter von Valkey 7.2 und Redis OSS 7
**Parametergruppenfamilie**: valkey7
Die Standardparametergruppen von Valkey 7.2 lauten wie folgt:
+ `default.valkey7`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey-Cluster und Replikationsgruppen (Clustermodus deaktiviert).
+ `default.valkey7.cluster.on`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey-Cluster und Replikationsgruppen (Clustermodus aktiviert).
**Familie der Parametergruppe:** redis7
Die Standardparametergruppen von Redis OSS 7 lauten wie folgt:
+ `default.redis7`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Redis OSS-Cluster (Clustermodus deaktiviert) und Replikationsgruppen.
+ `default.redis7.cluster.on`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Redis OSS-Cluster (Cluster Mode Enabled) und Replikationsgruppen.
**Spezifische Parameteränderungen**
Die in Redis OSS 7 hinzugefügten Parameter lauten wie folgt. Valkey 7.2 unterstützt auch diese Parameter.
| Name | Details | Description |
| --- | --- | --- |
| cluster-allow-pubsubshard-when-down | Gültige Werte: `yes`, `no` Standard: `yes` Typ: Zeichenfolge Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Wenn die Standardeinstellung „Ja“ lautet, können Knoten Pubsub-Shard-Datenverkehr bereitstellen, während sich der Cluster in einem ausgefallenen Zustand befindet, sofern er glauben, dass er die Slots besitzt. |
| cluster-preferred-endpoint-type | Gültige Werte: `ip`, `tls-dynamic` Standard: `tls-dynamic` Typ: Zeichenfolge Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Dieser Wert steuert, welcher Endpunkt für MOVED/ASKING-Anforderungen zurückgegeben wird, sowie das Endpunktfeld für `CLUSTER SLOTS` und `CLUSTER SHARDS`. Wenn der Wert auf „ip“ festgelegt ist, gibt der Knoten seine IP-Adresse bekannt. Wenn der Wert auf tls-dynamic gesetzt ist, gibt der Knoten einen Hostnamen bekannt, wenn er aktiviert encryption-in-transit ist, und andernfalls eine IP-Adresse. |
| latency-tracking | Gültige Werte: `yes`, `no` Standard: `no` Typ: Zeichenfolge Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Wenn diese Option auf „Ja“ festgelegt ist, werden die Latenzen pro Befehl protokolliert und die Perzentilverteilung über den Latenzstatistiken-Befehl `INFO` wird aktiviert. Ebenso werden die kumulativen Latenzverteilungen (Histogramme) über den `LATENCY`-Befehl exportiert. |
| hash-max-listpack-entries | Zulässige Werte: `0+` Standard: `512` Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Die maximale Anzahl von Hash-Einträgen, damit der Datensatz komprimiert werden kann. |
| hash-max-listpack-value | Zulässige Werte: `0+` Standard: `64` Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Der Schwellenwert der maximalen Anzahl von Hash-Einträgen, damit der Datensatz komprimiert werden kann. |
| zset-max-listpack-entries | Zulässige Werte: `0+` Standard: `128` Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Die maximale Anzahl von Einträgen zu sortierten Sätzen, damit der Datensatz komprimiert werden kann. |
| zset-max-listpack-value | Zulässige Werte: `0+` Standard: `64` Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Der Schwellenwert der maximalen Anzahl von Einträgen zu sortierten Sätzen, damit der Datensatz komprimiert werden kann. |
Die in Redis OSS 7 geänderten Parameter lauten wie folgt.
| Name | Details | Description |
| --- | --- | --- |
| activerehashing | Anpassbar: `no`. In Redis OSS 7 ist dieser Parameter ausgeblendet und standardmäßig aktiviert. Wenn Sie ihn deaktivieren möchten, müssen Sie einen [Support-Fall erstellen](https://console.aws.amazon.com/support/home). | Veränderbar war ja. |
In Redis OSS 7 wurden die folgenden Parameter entfernt.
| Name | Details | Description |
| --- | --- | --- |
| hash-max-ziplist-entries | Zulässige Werte: `0+` Standard: `512` Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Für die Darstellung kleiner Hash-Kodierungen `listpack` statt `ziplist` verwenden |
| hash-max-ziplist-value | Zulässige Werte: `0+` Standard: `64` Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Für die Darstellung kleiner Hash-Kodierungen `listpack` statt `ziplist` verwenden |
| zset-max-ziplist-entries | Zulässige Werte: `0+` Standard: `128` Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Verwenden Sie `listpack` statt `ziplist` für die Darstellung kleiner Hash-Kodierungen. |
| zset-max-ziplist-value | Zulässige Werte: `0+` Standard: `64` Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Verwenden Sie `listpack` statt `ziplist` für die Darstellung kleiner Hash-Kodierungen. |
| list-max-ziplist-size | Gültige Werte: Standard: `-2` Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Die Anzahl der zulässigen Einträge pro internem Listenknoten. |
### Änderungen der Parameter in Redis OSS 6.x
**Familie der Parametergruppe:** redis6.x
Die Standardparametergruppen von Redis OSS 6.x lauten wie folgt:
+ `default.redis6.x`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) und Replikationsgruppen.
+ `default.redis6.x.cluster.on`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) und Replikationsgruppen.
**Anmerkung**
*In der Redis OSS-Engine-Version 6.2, als die R6GD-Node-Familie für die Verwendung mit eingeführt wurde, wurden nur *Noeviction* -[Datenzuweisung ElastiCache](data-tiering.md), *Volatile-Lru- und Allkeys-LRU-Memory-Richtlinien* mit r6gd-Knotentypen unterstützt.*
Weitere Informationen erhalten Sie unter [ElastiCache Version 6.2 für Redis OSS (erweitert)](engine-versions.md#redis-version-6.2) und [ElastiCache Version 6.0 für Redis OSS (erweitert)](engine-versions.md#redis-version-6.0).
Die in Redis OSS 6.x hinzugefügten Parameter lauten wie folgt.
| Details | Description |
| --- | --- |
| acl-pubsub-default (added in 6.2) | Gültige Werte: `resetchannels`, `allchannels` Standard: `allchannels` Typ: Zeichenfolge Veränderbar: Ja Die Änderungen werden wirksam: Die vorhandenen Redis OSS-Benutzer, die dem Cluster zugeordnet sind, werden weiterhin über bestehende Berechtigungen verfügen. Aktualisieren Sie entweder die Benutzer oder starten Sie den Cluster neu, um die vorhandenen Redis OSS-Benutzer zu aktualisieren. | Standardberechtigungen für Pub/Sub-Kanäle für ACL-Benutzer, die in diesem Cluster bereitgestellt werden. |
| cluster-allow-reads-when-down (added in 6.0) | Standard: no Typ: Zeichenfolge Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Wenn diese Option auf Ja gesetzt ist, verarbeitet eine Redis OSS-Replikationsgruppe (Clustermodus aktiviert) weiterhin Lesebefehle, auch wenn ein Knoten nicht in der Lage ist, ein Quorum von Primärdaten zu erreichen. Wenn der Standardwert Nein festgelegt ist, lehnt die Replikationsgruppe alle Befehle ab. Wir empfehlen, diesen Wert auf yes zu setzen, wenn Sie einen Cluster mit weniger als drei Knotengruppen verwenden oder Ihre Anwendung veraltete Lesevorgänge sicher verarbeiten kann. |
| tracking-table-max-keys (added in 6.0) | Standard: 1.000.000 Typ: Zahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Um das clientseitige Caching zu unterstützen, unterstützt Redis OSS die Nachverfolgung, welche Clients auf welche Schlüssel zugegriffen haben. Wenn der verfolgte Schlüssel geändert wird, werden Invalidierungsnachrichten an alle Clients gesendet, um ihnen mitzuteilen, dass ihre zwischengespeicherten Werte nicht mehr gültig sind. Mit diesem Wert können Sie die Obergrenze dieser Tabelle angeben. Nachdem dieser Parameterwert überschritten wurde, werden Clients zufällig Invalidierung gesendet. Dieser Wert sollte so eingestellt werden, dass die Speicherauslastung begrenzt wird, während immer noch genügend Schlüssel verfolgt werden. Schlüssel werden auch unter niedrigen Speicherbedingungen ungültig gemacht. |
| acllog-max-len (added in 6.0) | Standard: 128 Typ: Zahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Dieser Wert entspricht der maximalen Anzahl von Einträgen im ACL-Protokoll. |
| active-expire-effort (added in 6.0) | Standard: 1 Typ: Zahl Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Redis OSS löscht Schlüssel, deren Gültigkeitsdauer überschritten wurde, auf zwei Arten. In einem wird auf einen Schlüssel zugegriffen und festgestellt, dass er abgelaufen ist. In der anderen, ein periodischer Job Proben Schlüssel und bewirkt, dass diejenigen, die ihre Zeit überschritten haben, ablaufen. Dieser Parameter definiert den Aufwand, den Redis OSS aufwendet, um Elemente im periodischen Job ablaufen zu lassen. Der Standardwert von 1 versucht zu vermeiden, dass mehr als 10 Prozent der abgelaufenen Schlüssel noch im Speicher sind. Außerdem wird versucht, mehr als 25 Prozent des gesamten Arbeitsspeichers zu verbrauchen und das System Latenz zu erhöhen. Sie können diesen Wert auf bis zu 10 erhöhen, um den Aufwand für ablaufende Schlüssel zu erhöhen. Der Kompromiss ist eine höhere CPU und eine potenziell höhere Latenz. Wir empfehlen den Wert 1, es sei denn, Sie sehen eine hohe Speicherauslastung und können eine Erhöhung der CPU-Auslastung tolerieren. |
| lazyfree-lazy-user-del (added in 6.0) | Standard: no Typ: Zeichenfolge Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Wenn der Wert auf Ja gesetzt ist, verhält sich der `DEL`-Befehl genauso wie `UNLINK`. |
In Redis OSS 6.x wurden die folgenden Parameter entfernt.
| Name | Details | Description |
| --- | --- | --- |
| lua-replicate-commands | Zulässige Werte: yes/no Standard: yes Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Sofort | Diese Parameter aktivieren immer Lua-Effektreplikation oder Nicht-in-Lua-Skripts. |
### Änderungen an den Parametern von Redis OSS 5.0.3
**Familie der Parametergruppe:** redis5.0
Standardparametergruppen für Redis OSS 5.0
+ `default.redis5.0`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) und Replikationsgruppen.
+ `default.redis5.0.cluster.on`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) und Replikationsgruppen.
**In Redis OSS 5.0.3 hinzugefügte Parameter**
| Name | Details | Description |
| --- | --- | --- |
| rename-commands | Standard: keiner Typ: Zeichenfolge Veränderbar: Ja Änderungen treten in Kraft: unmittelbar auf allen Knoten im Cluster | Eine durch Leerzeichen getrennte Liste umbenannter Redis OSS-Befehle. Im Folgenden finden Sie eine eingeschränkte Liste der verfügbaren Befehle: `APPEND AUTH BITCOUNT BITFIELD BITOP BITPOS BLPOP BRPOP BRPOPLPUSH BZPOPMIN BZPOPMAX CLIENT CLUSTER COMMAND DBSIZE DECR DECRBY DEL DISCARD DUMP ECHO EVAL EVALSHA EXEC EXISTS EXPIRE EXPIREAT FLUSHALL FLUSHDB GEOADD GEOHASH GEOPOS GEODIST GEORADIUS GEORADIUSBYMEMBER GET GETBIT GETRANGE GETSET HDEL HEXISTS HGET HGETALL HINCRBY HINCRBYFLOAT HKEYS HLEN HMGET HMSET HSET HSETNX HSTRLEN HVALS INCR INCRBY INCRBYFLOAT INFO KEYS LASTSAVE LINDEX LINSERT LLEN LPOP LPUSH LPUSHX LRANGE LREM LSET LTRIM MEMORY MGET MONITOR MOVE MSET MSETNX MULTI OBJECT PERSIST PEXPIRE PEXPIREAT PFADD PFCOUNT PFMERGE PING PSETEX PSUBSCRIBE PUBSUB PTTL PUBLISH PUNSUBSCRIBE RANDOMKEY READONLY READWRITE RENAME RENAMENX RESTORE ROLE RPOP RPOPLPUSH RPUSH RPUSHX SADD SCARD SCRIPT SDIFF SDIFFSTORE SELECT SET SETBIT SETEX SETNX SETRANGE SINTER SINTERSTORE SISMEMBER SLOWLOG SMEMBERS SMOVE SORT SPOP SRANDMEMBER SREM STRLEN SUBSCRIBE SUNION SUNIONSTORE SWAPDB TIME TOUCH TTL TYPE UNSUBSCRIBE UNLINK UNWATCH WAIT WATCH ZADD ZCARD ZCOUNT ZINCRBY ZINTERSTORE ZLEXCOUNT ZPOPMAX ZPOPMIN ZRANGE ZRANGEBYLEX ZREVRANGEBYLEX ZRANGEBYSCORE ZRANK ZREM ZREMRANGEBYLEX ZREMRANGEBYRANK ZREMRANGEBYSCORE ZREVRANGE ZREVRANGEBYSCORE ZREVRANK ZSCORE ZUNIONSTORE SCAN SSCAN HSCAN ZSCAN XINFO XADD XTRIM XDEL XRANGE XREVRANGE XLEN XREAD XGROUP XREADGROUP XACK XCLAIM XPENDING GEORADIUS_RO GEORADIUSBYMEMBER_RO LOLWUT XSETID SUBSTR` |
Weitere Informationen finden Sie unter [ElastiCache Version 5.0.6 für Redis OSS (erweitert)](engine-versions.md#redis-version-5-0.6).
### Änderungen der Parameter von Redis OSS 5.0.0
**Familie der Parametergruppe:** redis5.0
Standardparametergruppen für Redis OSS 5.0
+ `default.redis5.0`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) und Replikationsgruppen.
+ `default.redis5.0.cluster.on`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) und Replikationsgruppen.
**In Redis OSS 5.0 hinzugefügte Parameter**
| Name | Details | Description |
| --- | --- | --- |
| stream-node-max-bytes | Zulässige Werte: 0\$1 Standard: 4096 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Die Struktur der Stream-Daten ist eine baumartige Struktur von Knoten, die mehrere Elemente im Innern codieren. Mit dieser Konfiguration legen Sie die maximale Größe (in Bytes) eines einzelnen Knotens in der Baumstruktur fest. Wird die Einstellung „0” gewählt, ist die Größe des Baumknotens unbegrenzt. |
| stream-node-max-entries | Zulässige Werte: 0\$1 Standard: 100 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Die Struktur der Stream-Daten ist eine baumartige Struktur von Knoten, die mehrere Elemente im Innern codieren. Legen Sie mit dieser Konfiguration die maximale Anzahl der Elemente fest, die ein einzelner Knoten enthalten kann, bevor beim Anhängen neuer Stream-Einträge zu einem neuen Knoten gewechselt wird. Wird die Einstellung „0” gewählt, ist die Anzahl der Elemente des Baumknotens unbegrenzt. |
| active-defrag-max-scan-fields | Zulässige Werte: 1 bis 1 000 000 Standard: 1000 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Maximale Anzahl von set/hash/zset/list Feldern, die beim Hauptwörterbuch-Scan verarbeitet werden |
| lua-replicate-commands | Zulässige Werte: yes/no Standard: yes Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Sofort | Diese Parameter aktivieren immer Lua-Effektreplikation oder Nicht-in-Lua-Skripts. |
| replica-ignore-maxmemory | Standard: yes Typ: Boolesch Veränderbar: Nein | Dieser Parameter bestimmt, ob das Replikat die Einstellung maxmemory ignoriert, indem Elemente nicht unabhängig von der Primär-Instance bereinigt werden |
Redis OSS hat als Reaktion auf das Feedback der Community mehrere Parameter in Engine-Version 5.0 umbenannt. Weitere Informationen finden Sie unter [Was ist neu in Redis OSS 5](https://aws.amazon.com/redis/Whats_New_Redis5/)? . In der folgenden Tabelle sind die neuen Parameternamen und deren Entsprechung in früheren Versionen angegeben.
**Parameter wurden in Redis OSS 5.0 umbenannt**
| Name | Details | Description |
| --- | --- | --- |
| replica-lazy-flush | Standard: yes Typ: Boolesch Veränderbar: Nein Früherer Name: slave-lazy-flush | Führt einen asynchronen flushDB-Befehl während einer Replikatsynchronisierung durch |
| client-output-buffer-limit-replica-hard-limit | Standard: Für Werte siehe [Redis OSS-Knotentyp-spezifische Parameter](#ParameterGroups.Redis.NodeSpecific) Typ: Ganzzahl Veränderbar: Nein Früherer Name: client-output-buffer-limit - slave-hard-limit | Für Redis OSS Read Replicas: Wenn der Ausgabepuffer eines Clients die angegebene Anzahl von Byte erreicht, wird der Client getrennt. |
| client-output-buffer-limit-replica-soft-limit | Standard: Für Werte siehe [Redis OSS-Knotentyp-spezifische Parameter](#ParameterGroups.Redis.NodeSpecific) Typ: Ganzzahl Veränderbar: Nein Früherer Name: - client-output-buffer-limit slave-soft-limit | Für Redis OSS-Lesereplikate: Wenn der Ausgabepuffer eines Clients die angegebene Anzahl von Byte erreicht, wird der Client getrennt, aber nur, wenn dieser Zustand weiterhin besteht. client-output-buffer-limit-replica-soft-seconds |
| client-output-buffer-limit-replica-soft-seconds | Standard: 60 Typ: Ganzzahl Veränderbar: Nein Früherer Name: - client-output-buffer-limit slave-soft-seconds | Für Redis OSS-Lesereplikate: Wenn der Ausgabepuffer eines Clients länger als diese Anzahl von Sekunden auf client-output-buffer-limit-replica-soft-limit Byte verbleibt, wird die Verbindung zum Client getrennt. |
| replica-allow-chaining | Standard: no Typ: Zeichenfolge Veränderbar: Nein Früherer Name: slave-allow-chaining | Bestimmt, ob eine Read Replica in Redis OSS eigene Read Replicas haben kann. |
| min-replicas-to-write | Standard: 0 Typ: Ganzzahl Veränderbar: Ja Früherer Name: min-slaves-to-write Änderungen werden wirksam: Sofort | Die Mindestanzahl an Read Replicas, die verfügbar sein müssen, damit der primäre Knoten Schreibanforderungen von Clients akzeptiert. Wenn die Anzahl der verfügbaren Replikate unter diesen Wert abfällt, dann akzeptiert der primäre Knoten keine Schreibanforderungen mehr. Wenn entweder dieser Parameter oder 0 min-replicas-max-lag ist, akzeptiert der primäre Knoten immer Schreibanforderungen, auch wenn keine Replikate verfügbar sind. |
| min-replicas-max-lag | Standard: 10 Typ: Ganzzahl Veränderbar: Ja Früherer Name: min-slaves-max-lag Änderungen werden wirksam: Sofort | Die Anzahl von Sekunden, innerhalb der der primäre Knoten eine Ping-Anforderung von einer Read Replica empfangen muss. Wenn dieser Zeitraum überschritten wird, ohne dass der primäre Knoten einen Ping erhält, dann wird das Replikat nicht mehr als verfügbar angesehen. Wenn die Anzahl der verfügbaren Replikate unter den Wert fällt min-replicas-to-write, akzeptiert das primäre Replikat zu diesem Zeitpunkt keine Schreibvorgänge mehr. Wenn entweder dieser Parameter oder 0 min-replicas-to-write ist, akzeptiert der primäre Knoten immer Schreibanforderungen, auch wenn keine Replikate verfügbar sind. |
| close-on-replica-write | Standard: yes Typ: Boolesch Veränderbar: Ja Früherer Name: close-on-slave-write Änderungen werden wirksam: Sofort | Wenn er aktiviert ist, wird die Verbindung mit Clients, die versuchen, in ein schreibgeschütztes Replikat zu schreiben, unterbrochen. |
**In Redis OSS 5.0 entfernte Parameter**
| Name | Details | Description |
| --- | --- | --- |
| repl-timeout | Standard: 60 Veränderbar: Nein | Parameter ist in dieser Version nicht verfügbar |
### Änderungen an den Parametern von Redis OSS 4.0.10
**Familie der Parametergruppe:** redis4.0
Standardparametergruppen für Redis OSS 4.0.x
+ `default.redis4.0`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) und Replikationsgruppen.
+ `default.redis4.0.cluster.on`— Verwenden Sie diese oder eine davon abgeleitete Parametergruppe für Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) und Replikationsgruppen.
**Die Parameter wurden in Redis OSS 4.0.10 geändert**
| Name | Details | Description |
| --- | --- | --- |
| maxmemory-policy | Gültige Werte: `allkeys-lru`, `volatile-lru`, **allkeys-lfu**, **volatile-lfu**, `allkeys-random`, `volatile-random`, `volatile-ttl`, `noeviction` Standard: volatile-lru Typ: Zeichenfolge Veränderbar: Ja Änderungen treten in Kraft: sofort | maxmemory-policy wurde in Version 2.6.13 hinzugefügt. In Version 4.0.10 wurden zwei neue zulässige Werte hinzugefügt: allkeys-lfu, womit jeder beliebige Schlüssel mittels angenähertem LFU-Wert bereinigt wird, und volatile-lfu, womit unter den Schlüsseln mit einem festgelegten Ablaufdatum mittels angenährtem LFU-Wert bereinigt wird. In Version 6.2, als die R6gd-Knotenfamilie zur Verwendung mit Daten-Tiering eingeführt wurde, werden nur die maxmemory-Richtlinien noeviction, volatile-lru und allkeys-lru mit R6gd-Knotentypen unterstützt. |
**In Redis OSS 4.0.10 hinzugefügte Parameter**
| Name | Details | Description |
| --- |--- |--- |
| **Parameter für asynchrones Löschen** |
| --- |
| lazyfree-lazy-eviction | Zulässige Werte: yes/no Standard: no Typ: Boolesch Veränderbar: Ja Änderungen treten in Kraft: sofort | Führt eine asynchrone Löschung bei Bereinigungen durch. |
| lazyfree-lazy-expire | Zulässige Werte: yes/no Standard: no Typ: Boolesch Veränderbar: Ja Änderungen treten in Kraft: sofort | Führt eine asynchrone Löschung bei abgelaufenen Schlüsseln durch. |
| lazyfree-lazy-server-del | Zulässige Werte: yes/no Standard: no Typ: Boolesch Veränderbar: Ja Änderungen treten in Kraft: sofort | Führt eine asynchrone Löschung bei Befehlen durch, die Werte aktualisieren. |
| slave-lazy-flush | Zulässige Werte: Nicht zutreffend Standard: no Typ: Boolesch Veränderbar: Nein Änderungen treten in Kraft: Nicht zutreffend | Führt einen asynchrones flushDB-Befehl während einer Slave-Synchronisierung durch. |
| **LFU-Parameter** |
| --- |
| lfu-log-factor | Zulässige Werte: jede Ganzzahl Standard: 10 Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: sofort | Legen den Protokollfaktor fest, der die Anzahl der Schlüsseltreffer zur Deckung des Schlüsselzählers bestimmt. |
| lfu-decay-time | Zulässige Werte: jede Ganzzahl Standard: 1 Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: sofort | Zeitdauer in Minuten für die Verringerung des Schlüsselzählers. |
| **Parameter für aktive Defragmentierung** |
| --- |
| activedefrag | Zulässige Werte: yes/no Standard: no Typ: Boolesch Veränderbar: Ja Änderungen treten in Kraft: sofort | Aktiviert die aktive Defragmentierung. In den OSS-Versionen 7.0 und höher von Valkey und Redis AWS kann unabhängig von dieser Einstellung automatisch eine Defragmentierung durchführen, wenn dies betrieblich erforderlich ist. |
| active-defrag-ignore-bytes | Zulässige Werte: 10485760-104857600 Standard: 104857600 Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: sofort | Mindestmenge an Fragmentierungsresten für das Starten der aktiven Defragmentierung. |
| active-defrag-threshold-lower | Zulässige Werte: 1–100 Standard: 10 Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: sofort | Mindestprozentsatz der Fragmentierung zum Starten der aktiven Defragmentierung. |
| active-defrag-threshold-upper | Zulässige Werte: 1–100 Standard: 100 Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: sofort | Maximaler Prozentsatz der Fragmentierung, bei dem der maximale Einsatz aufgewandt wird. |
| active-defrag-cycle-min | Zulässige Werte: 1–75 Standard: 25 Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: sofort | Minimaler Aufwand für die Defragmentierung als CPU-Prozentsatz. |
| active-defrag-cycle-max | Zulässige Werte: 1–75 Standard: 75 Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: sofort | Maximaler Aufwand für die Defragmentierung als CPU-Prozentsatz. |
| **Client-Ausgabepuffer-Parameter** |
| --- |
| client-query-buffer-limit | Zulässige Werte: 1048576-1073741824 Standard: 1073741824 Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: sofort | Maximale Größe eines einzelnen Client-Abfragepuffers. |
| proto-max-bulk-len | Zulässige Werte: 1048576-536870912 Standard: 536870912 Typ: Ganzzahl Veränderbar: Ja Änderungen treten in Kraft: sofort | Maximale Größe einer einzelnen Elementanforderung. |
### Änderungen an den Parametern von Redis OSS 3.2.10
**Familie der Parametergruppe:** redis3.2
ElastiCache für Redis OSS 3.2.10 werden keine zusätzlichen Parameter unterstützt.
### Änderungen der Parameter in Redis OSS 3.2.6
**Familie der Parametergruppe:** redis3.2
Für Redis OSS 3.2.6 werden keine zusätzlichen Parameter unterstützt.
### Änderungen der Parameter in Redis OSS 3.2.4
**Familie der Parametergruppe:** redis3.2
Ab Redis OSS 3.2.4 gibt es zwei Standardparametergruppen.
+ `default.redis3.2`— Wenn Sie Redis OSS 3.2.4 ausführen, geben Sie diese oder eine davon abgeleitete Parametergruppe an, wenn Sie eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) erstellen und trotzdem die zusätzlichen Funktionen von Redis OSS 3.2.4 verwenden möchten.
+ `default.redis3.2.cluster.on`— Geben Sie diese oder eine davon abgeleitete Parametergruppe an, wenn Sie eine Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus aktiviert) erstellen möchten.
**Topics**
+ [Neue Parameter für Redis OSS 3.2.4](#ParameterGroups.Redis.3-2-4.New)
+ [Die Parameter wurden in Redis OSS 3.2.4 geändert (erweitert)](#ParameterGroups.Redis.3-2-4.Changed)
#### Neue Parameter für Redis OSS 3.2.4
**Familie der Parametergruppe:** redis3.2
Für Redis OSS 3.2.4 werden die folgenden zusätzlichen Parameter unterstützt.
****
| Name | Details | Description |
| --- | --- | --- |
| list-max-ziplist-size | Standard: -2 Typ: Ganzzahl Veränderbar: Nein | Listen sind auf besondere Weise codiert, um Platz zu sparen. Die Anzahl der Einträge, die pro internem Listenknoten zulässig sind, können als eine feste maximale Größe oder als maximale Anzahl von Elementen angegeben werden. Verwenden Sie für eine feste maximale Größe -5 bis -1 mit der folgenden Bedeutung: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| list-compress-depth | Standard: 0 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Listen können auch komprimiert werden. Die Komprimierungstiefe ist die Anzahl der quicklist ziplist-Knoten ab jeder Seite der Liste, die von der Komprimierung ausgeschlossen werden sollen. Anfang und Ende der Liste sind für schnelle push- und pop-Operationen immer dekomprimiert. Die Einstellungen sind: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| cluster-enabled | Standard: \$1 no/yes Type: Zeichenkette Veränderbar: Nein | Gibt an, ob es sich um eine Valkey- oder Redis OSS-Replikationsgruppe (Cluster-Modus aktiviert) im Cluster-Modus (ja) oder um eine Valkey- oder Redis OSS-Replikationsgruppe (Cluster-Modus aktiviert) im Nicht-Cluster-Modus (nein) handelt. Valkey- oder Redis OSS-Replikationsgruppen (Clustermodus aktiviert) im Clustermodus können ihre Daten auf bis zu 500 Knotengruppen partitionieren. \$1 Redis OSS 3.2. *x* hat zwei Standardparametergruppen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html). |
| cluster-require-full-coverage | Standard: no Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Sofort | Wenn auf gesetzt`yes`, akzeptieren Valkey- oder Redis OSS-Knoten (Clustermodus aktiviert) im Clustermodus keine Anfragen mehr, wenn sie feststellen, dass mindestens ein Hash-Slot aufgedeckt ist (kein verfügbarer Knoten bedient ihn). Auf diese Weise ist ein Cluster nicht mehr verfügbar, falls er teilweise ausfällt. Er wird automatisch wieder verfügbar, sobald alle Slots wieder abgedeckt sind. Manchmal ist es jedoch wünschenswert, dass der Teilbereich des Clusters, der funktioniert, für den immer noch abgedeckten Teil des Keyspace weiterhin Abfragen akzeptiert. Stellen Sie dazu die Option `cluster-require-full-coverage` auf `no` ein. |
| hll-sparse-max-bytes | Standard: 3000 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | HyperLogLog Limit für spärliche Repräsentations-Bytes. Das Limit umfasst den 16-Byte-Header. Wenn eine Darstellung HyperLogLog mit geringer Dichte diese Grenze überschreitet, wird sie in eine Darstellung mit hoher Dichte umgewandelt. Ein Wert größer als 16000 wird nicht empfohlen, da ab einem solchen Wert die dichte Repräsentation effizienter ist. Es wird ein Wert von ca. 3 000 empfohlen, um die Vorteile der platzsparenden Codierung zu nutzen, ohne PFADD zu sehr zu verlangsamen. Dies entspricht der Einstellung O(N) bei der Sparse-Codierung. Der Wert kann auf \$110000 angehoben werden, wenn die CPU kein Problem darstellt, sondern der Speicherplatz, und der Datensatz besteht aus vielen Datensätzen HyperLogLogs mit einer Kardinalität zwischen 0 und 15000. |
| reserved-memory-percent | Standard: 25 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Der reservierte Prozentsatz des Knotenspeichers, der nicht für Daten verwendet werden soll. Standardmäßig wächst der Redis OSS-Datenbedarf, bis er den gesamten Speicher des Knotens verbraucht. In diesem Fall wird die Knotenleistung aufgrund der übermäßigen Speicherauslagerung beeinträchtigt. Indem Sie Speicher reservieren, können Sie einen Teil des verfügbaren Speichers für andere Zwecke als Redis OSS reservieren, um den Umfang des Paging zu reduzieren. Dieser Parameter ist spezifisch für die ElastiCache Redis-OSS-Standarddistribution und nicht Teil dieser. Weitere Informationen erhalten Sie unter `reserved-memory` und [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md). |
#### Die Parameter wurden in Redis OSS 3.2.4 geändert (erweitert)
**Familie der Parametergruppe:** redis3.2
Für Redis OSS 3.2.4 wurden die folgenden Parameter geändert.
****
| Name | Details | Änderungen |
| --- | --- | --- |
| activerehashing | Modifizierbar: Ja, wenn die Parametergruppe keinem Cluster zugeordnet ist. Ansonsten nein. | Veränderbar war Nein. |
| databases | Änderbar: Ja, wenn die Parametergruppe keinem Cluster zugeordnet ist. Ansonsten nein. | Veränderbar war Nein. |
| appendonly | Standard: deaktiviert Veränderbar: Nein | Wenn Sie ein Upgrade von einer früheren Redis OSS-Version durchführen möchten, müssen Sie das System zuerst ausschalten`appendonly`. |
| appendfsync | Standard: deaktiviert Veränderbar: Nein | Wenn Sie ein Upgrade von einer früheren Redis OSS-Version durchführen möchten, müssen Sie das Gerät zuerst ausschalten`appendfsync`. |
| repl-timeout | Standard: 60 Veränderbar: Nein | Ist nun nicht mehr veränderbar mit einem Standard von 60. |
| tcp-keepalive | Standard: 300 | Standard war 0. |
| list-max-ziplist-entries | | Der Parameter ist nicht mehr verfügbar. |
| list-max-ziplist-value | | Der Parameter ist nicht mehr verfügbar. |
### Redis OSS 2.8.24 (erweitert) hat Parameter hinzugefügt
**Familie der Parametergruppe:** redis2.8
Für Redis OSS 2.8.24 werden keine zusätzlichen Parameter unterstützt.
### Redis OSS 2.8.23 (erweitert) hat Parameter hinzugefügt
**Familie der Parametergruppe:** redis2.8
Für Redis OSS 2.8.23 wird der folgende zusätzliche Parameter unterstützt.
****
| Name | Details | Description |
| --- | --- | --- |
| close-on-slave-write | Standard: yes Typ: Zeichenfolge (yes/no) Veränderbar: Ja Änderungen werden wirksam: Sofort | Wenn er aktiviert ist, wird die Verbindung mit Clients, die versuchen, in ein schreibgeschütztes Replikat zu schreiben, unterbrochen. |
#### Funktionsweise von close-on-slave-write
Der `close-on-slave-write` Parameter wurde von Amazon eingeführt, ElastiCache um Ihnen mehr Kontrolle darüber zu geben, wie Ihr Cluster reagiert, wenn ein primärer Knoten und ein Read Replica-Knoten aufgrund der Heraufstufung einer Read Replica zum primären Knoten die Rollen wechseln.
![\[Bild: close-on-replica-write, alles funktioniert einwandfrei\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-01.png)
Wenn der Read Replica-Cluster nur aufgrund des Failovers einer Multi-AZ-fähigen Replikation heraufgestuft wird, versucht der Client weiterhin, in den Endpunkt A zu schreiben. Da Endpunkt A nun der Endpunkt für eine Read Replica ist, schlagen diese Schreibvorgänge fehl. Dies ist das Verhalten für Redis OSS vor der ElastiCache Einführung `close-on-replica-write` und das Verhalten, wenn Sie es deaktivieren`close-on-replica-write`.
![\[Bild: close-on-slave-write, Schreibvorgänge schlagen fehl\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-02.png)
Wenn `close-on-replica-write` aktiviert ist, wird jedes Mal bei dem Versuch des Clients, in eine Read Replica zu schreiben, die Client-Verbindung mit dem Cluster unterbrochen. Die Logik Ihre Anwendung sollte die Unterbrechung erkennen, die DNS-Tabelle überprüfen und wieder eine Verbindung zum primären Endpunkt herstellen, wobei es sich um Endpunkt B handeln würde.
![\[Bild: close-on-slave-write, Schreiben in einen neuen primären Cluster\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-03.png)
#### Wann könnten Sie deaktivieren close-on-replica-write
Wenn `close-on-replica-write`-Resultate beim Schreiben in fehlerhafte Cluster deaktiviert werden, warum sollte `close-on-replica-write` deaktiviert werden?
Wie zuvor erwähnt, wird jedes Mal, wenn `close-on-replica-write` aktiviert ist, bei dem Versuch des Clients, in eine Read Replica zu schreiben, die Client-Verbindung mit dem Cluster unterbrochen. Das Herstellen einer neuen Verbindung zum Knoten nimmt einige Zeit in Anspruch. Daher beeinträchtigt das Trennen und Wiederherstellen einer Verbindung als Ergebnis einer Schreibanforderung in das Replica auch die Latenz von Leseanforderungen, die über die gleiche Verbindung bedient werden. Dieser Effekt bleibt bestehen bis eine neue Verbindung hergestellt wird. Wenn Ihre Anwendung besonders leseintensiv oder latenzempfindlich ist, können Sie die Verbindung Ihrer Clients aufrecht erhalten, um eine Beeinträchtigung der Leseleistung zu vermeiden.
### Redis OSS 2.8.22 (erweitert) hat Parameter hinzugefügt
**Familie der Parametergruppe:** redis2.8
Für Redis OSS 2.8.22 werden keine zusätzlichen Parameter unterstützt.
**Wichtig**
`repl-backlog-size`Gilt ab Redis OSS Version 2.8.22 sowohl für den primären Cluster als auch für Replikatcluster.
Ab Redis OSS Version 2.8.22 wird der Parameter nicht unterstützt. `repl-timeout` Wenn er geändert wird, ElastiCache wird er mit der Standardeinstellung (60s) überschrieben, wie wir es bei tun. `appendonly`
Die folgenden Parameter werden nicht mehr unterstützt.
+ *appendonly*
+ *appendfsync*
+ *repl-timeout*
### Redis OSS 2.8.21 hat Parameter hinzugefügt
**Familie der Parametergruppe:** redis2.8
Für Redis OSS 2.8.21 werden keine zusätzlichen Parameter unterstützt.
### Redis OSS 2.8.19 hat Parameter hinzugefügt
**Familie der Parametergruppe:** redis2.8
Für Redis OSS 2.8.19 werden keine zusätzlichen Parameter unterstützt.
### Redis OSS 2.8.6 hat Parameter hinzugefügt
**Familie der Parametergruppe:** redis2.8
Für Redis OSS 2.8.6 werden die folgenden zusätzlichen Parameter unterstützt.
****
| Name | Details | Description |
| --- | --- | --- |
| min-slaves-max-lag | Standard: 10 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Die Anzahl von Sekunden, innerhalb der der primäre Knoten eine Ping-Anforderung von einer Read Replica empfangen muss. Wenn dieser Zeitraum überschritten wird, ohne dass der primäre Knoten einen Ping erhält, dann wird das Replikat nicht mehr als verfügbar angesehen. Wenn die Anzahl der verfügbaren Replikate unter den Wert fällt min-slaves-to-write, akzeptiert der primäre Server zu diesem Zeitpunkt keine Schreibvorgänge mehr. Wenn entweder dieser Parameter oder 0 min-slaves-to-write ist, akzeptiert der primäre Knoten immer Schreibanforderungen, auch wenn keine Replikate verfügbar sind. |
| min-slaves-to-write | Standard: 0 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Die Mindestanzahl an Read Replicas, die verfügbar sein müssen, damit der primäre Knoten Schreibanforderungen von Clients akzeptiert. Wenn die Anzahl der verfügbaren Replikate unter diesen Wert abfällt, dann akzeptiert der primäre Knoten keine Schreibanforderungen mehr. Wenn entweder dieser Parameter oder 0 min-slaves-max-lag ist, akzeptiert der primäre Knoten immer Schreibanforderungen, auch wenn keine Replikate verfügbar sind. |
| notify-keyspace-events | Standardwert: (eine leere Zeichenfolge) Typ: Zeichenfolge Veränderbar: Ja Änderungen werden wirksam: Sofort | Die Arten von Schlüsselraumereignissen, über die Redis OSS Clients informieren kann. Jede Art von Ereignis wird durch einen einzelnen Buchstaben repräsentiert: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) Es kann eine beliebige Kombination dieser Ereignistypen vorliegen. *AKE* bedeutet beispielsweise, dass Redis OSS Benachrichtigungen aller Ereignistypen veröffentlichen kann. Verwenden Sie nur die oben aufgelisteten Zeichen. Die versuchte Eingabe anderer Zeichen führt zu Fehlermeldungen. Für diesen Parameter ist standardmäßig eine leere Zeichenfolge eingestellt. Dies bedeutet, dass die Keyspace-Ereignisbenachrichtigung deaktiviert ist. |
| repl-backlog-size | Standard: 1048576 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Die Größe, in Byte, des Bacḱlogs des primären Knotens. Das Backlog dient zur Aufzeichnung von Aktualisierungen an den Daten auf dem primären Knoten. Wenn sich eine Read Replica mit dem primären Knoten verbindet, versucht sie, eine teilweise Synchronisierung (`psync`) durchzuführen. Dabei wendet sie die Daten aus dem Backlog an, um den primären Knoten auf den neuesten Stand zu bringen. Wenn `psync` fehlschlägt, ist eine vollständige Synchronisierung erforderlich. Der Mindestwert für diesen Parameter ist 16384. Ab Redis OSS 2.8.22 gilt dieser Parameter sowohl für den primären Cluster als auch für die Read Replicas. |
| repl-backlog-ttl | Standard: 3600 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Die Anzahl von Sekunden, für die der primäre Knoten den Backlog-Puffer beibehält. Ab dem Zeitpunkt, an dem die Verbindung des letzte Replikatknotens getrennt wurde, bleiben die Daten im Backlog intakt, bis `repl-backlog-ttl` abläuft. Wenn das Replikat innerhalb dieses Zeitraums keine Verbindung zum primären Knoten hergestellt hat, dann gibt der primäre Knoten den Backlog-Puffer frei. Wenn das Replikat sich schließlich verbindet, muss es sich einer vollständigen Synchronisierung mit dem primären Knoten unterziehen. Wenn dieser Parameter auf „0“ eingestellt ist, wird der Backlog-Puffer niemals freigegeben. |
| repl-timeout | Standard: 60 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Sofort | Stellt den Zeitraum für die Zeitüberschreitung in Sekunden dar für: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
### Redis OSS 2.6.13-Parameter
**Familie der Parametergruppe:** redis2.6
Redis OSS 2.6.13 war die erste Version von Redis OSS, die von unterstützt wurde. ElastiCache Die folgende Tabelle zeigt die unterstützten Redis OSS 2.6.13-Parameter. ElastiCache
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html)
**Anmerkung**
Wenn Sie keine Parametergruppe für Ihren Redis OSS 2.6.13-Cluster angeben, wird eine Standardparametergruppe () `default.redis2.6` verwendet. Sie können die Werte der Parameter in der Parametergruppe nicht ändern. Sie können jedoch jederzeit immer eine benutzerdefinierte Parametergruppe erstellen und Sie Ihrem Cluster zuweisen.
### Redis OSS-Knotentyp-spezifische Parameter
Obwohl die meisten Parameter über einen einzelnen Wert verfügen, ist bei einigen Parametern der jeweilige Wert vom verwendeten Knotentyp abhängig. Die folgende Tabelle zeigt die Standardwerte der Parameter `maxmemory`, `client-output-buffer-limit-slave-hard-limit` und `client-output-buffer-limit-slave-soft-limit` für jeden Knotentyp. Der Wert `maxmemory` ist die maximale Anzahl von Bytes, die für Ihre Verwendung, für Daten oder für andere Zwecke auf dem Knoten verfügbar sind. Weitere Informationen finden Sie unter [Verfügbarer Speicher](https://aws.amazon.com/premiumsupport/knowledge-center/available-memory-elasticache-redis-node/).
**Anmerkung**
Der Parameter `maxmemory` kann nicht geändert werden.
| Knotentyp | Maxmemory | C lient-output-buffer-limit - slave-hard-limit | C lient-output-buffer-limit - slave-soft-limit |
| --- | --- | --- | --- |
| cache.t1.micro | 142606336 | 14260633 | 14260633 |
| cache.t2.micro | 581959680 | 58195968 | 58195968 |
| cache.t2.small | 1665138688 | 166513868 | 166513868 |
| cache.t2.medium | 3461349376 | 346134937 | 346134937 |
| cache.t3.micro | 536870912 | 53687091 | 53687091 |
| cache.t3.small | 1471026299 | 147102629 | 147102629 |
| cache.t3.medium | 3317862236 | 331786223 | 331786223 |
| cache.t4g.micro | 536870912 | 53687091 | 53687091 |
| cache.t4g.small | 1471026299 | 147102629 | 147102629 |
| cache.t4g.medium | 3317862236 | 331786223 | 331786223 |
| cache.m1.small | 943718400 | 94371840 | 94371840 |
| cache.m1.medium | 3093299200 | 309329920 | 309329920 |
| cache.m1.large | 7025459200 | 702545920 | 702545920 |
| cache.m1.xlarge | 14889779200 | 1488977920 | 1488977920 |
| cache.m2.xlarge | 17091788800 | 1709178880 | 1709178880 |
| cache.m2.2xlarge | 35022438400 | 3502243840 | 3502243840 |
| cache.m2.4xlarge | 70883737600 | 7088373760 | 7088373760 |
| cache.m3.medium | 2988441600 | 309329920 | 309329920 |
| cache.m3.large | 6501171200 | 650117120 | 650117120 |
| cache.m3.xlarge | 14260633600 | 1426063360 | 1426063360 |
| cache.m3.2xlarge | 29989273600 | 2998927360 | 2998927360 |
| cache.m4.large | 6892593152 | 689259315 | 689259315 |
| cache.m4.xlarge | 15328501760 | 1532850176 | 1532850176 |
| cache.m4.2xlarge | 31889126359 | 3188912636 | 3188912636 |
| cache.m4.4xlarge | 65257290629 | 6525729063 | 6525729063 |
| cache.m4.10xlarge | 166047614239 | 16604761424 | 16604761424 |
| cache.m5.large | 6854542746 | 685454275 | 685454275 |
| cache.m5.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m5.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m5.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m5.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m5.24xlarge | 337500562842 | 33750056284 | 33750056284 |
| cache.m6g.large | 6854542746 | 685454275 | 685454275 |
| cache.m6g.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m6g.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m6g.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m6g.8xlarge | 111325552312 | 11132555231 | 11132555231 |
| cache.m6g.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m6g.16xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.c1.xlarge | 6501171200 | 650117120 | 650117120 |
| cache.r3.large | 14470348800 | 1468006400 | 1468006400 |
| cache.r3.xlarge | 30513561600 | 3040870400 | 3040870400 |
| cache.r3.2xlarge | 62495129600 | 6081740800 | 6081740800 |
| cache.r3.4xlarge | 126458265600 | 12268339200 | 12268339200 |
| cache.r3.8xlarge | 254384537600 | 24536678400 | 24536678400 |
| cache.r4.large | 13201781556 | 1320178155 | 1320178155 |
| cache.r4.xlarge | 26898228839 | 2689822883 | 2689822883 |
| cache.r4.2xlarge | 54197537997 | 5419753799 | 5419753799 |
| cache.r4.4xlarge | 108858546586 | 10885854658 | 10885854658 |
| cache.r4.8xlarge | 218255432090 | 21825543209 | 21825543209 |
| cache.r4.16xlarge | 437021573120 | 43702157312 | 43702157312 |
| cache.r5.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r5.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r5.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r5.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r5.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r5.24xlarge | 682485973811 | 68248597381 | 68248597381 |
| cache.r6g.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r6g.xlarge | 28261849702 | 2826184970 | 2826184970 |
| dache.r6g.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| dache.r6g.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| dache.r6g.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| dache.r6g.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r6g.16xlarge | 450000750456 | 45000075046 | 45000075046 |
| cache.r6gd.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r6gd.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r6gd.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r6gd.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.r6gd.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r6gd.16xlarge | 450000750456 | 45000075046 | 45000075046 |
| cache.r7g.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r7g.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r7g.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r7g.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r7g.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.r7g.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r7g.16xlarge | 450000750456 | 45000075046 | 45000075046 |
| cache.m7g.large | 6854542746 | 685454275 | 685454275 |
| cache.m7g.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m7g.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m7g.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m7g.8xlarge | 111325552312 | 11132555231 | 11132555231 |
| cache.m7g.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m7g.16xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.c7gn.large | 3317862236 | 1403718103 | 1403718103 |
| cache.c7gn.xlarge | 6854542746 | 2826184970 | 2826184970 |
| cache.c7gn.2xlarge | 13891921715 | 5671118356 | 5671118356 |
| cache.c7gn.4xlarge | 27966669210 | 11360986522 | 11360986522 |
| cache.c7gn.8xlarge | 56116178125 | 22500037523 | 22500037523 |
| cache.c7gn.12xlarge | 84357985997 | 34120634655 | 34120634655 |
| cache.c7gn.16xlarge | 113609865216 | 45000075046 | 45000075046 |
**Anmerkung**
Alle Instance-Typen der aktuellen Generation werden standardmäßig in Amazon Virtual Private Cloud VPC erstellt.
T1-Instances unterstützen Multi-AZ nicht.
T1- und T2-Instances unterstützen Redis OSS AOF nicht.
Redis OSS-Konfigurationsvariablen `appendonly` und `appendfsync` werden in Redis OSS Version 2.8.22 und höher nicht unterstützt.
## Memcached-spezifische Parameter
**Memcached**
Wenn Sie für Ihren Memcached-Cluster keine Parametergruppe angeben, wird eine für Ihre Engine-Version geeignete Standard-Parametergruppe verwendet. Sie können die Werte von Parametern in einer Standard-Parametergruppe nicht ändern. Sie können jedoch jederzeit eine benutzerdefinierte Parameterguppe erstellen und sie Ihrem Cluster zuordnen. Weitere Informationen finden Sie unter [Eine ElastiCache Parametergruppe erstellen](ParameterGroups.Creating.md).
**Topics**
+ [Änderungen an Memcached 1.6.17](#ParameterGroups.Memcached.1.6.17)
+ [In Memcached 1.6.6 hinzugefügte Parameter](#ParameterGroups.Memcached.1-6-6)
+ [Parameteränderungen für Memcached 1.5.10](#ParameterGroups.Memcached.1-5-10)
+ [In Memcached 1.4.34 hinzugefügte Parameter](#ParameterGroups.Memcached.1-4-34)
+ [In Memcached 1.4.33 hinzugefügte Parameter](#ParameterGroups.Memcached.1-4-33)
+ [In Memcached 1.4.24 hinzugefügte Parameter](#ParameterGroups.Memcached.1-4-24)
+ [In Memcached 1.4.14 hinzugefügte Parameter](#ParameterGroups.Memcached.1-4-14)
+ [In Memcached 1.4.5 unterstützte Parameter](#ParameterGroups.Memcached.1-4-5)
+ [Overhead von Memcached-Verbindungen](#ParameterGroups.Memcached.Overhead)
+ [Spezifische Parameter des Memcached-Knotentyps](#ParameterGroups.Memcached.NodeSpecific)
### Änderungen an Memcached 1.6.17
Ab Memcached 1.6.17 unterstützen wir die folgenden administrativen Befehle nicht mehr: `lru_crawler`, `lru` und `slabs`. Mit diesen Änderungen wird es Ihnen zur Laufzeit nicht möglich sein, enable/disable `lru_crawler` Befehle zu verwenden. Bitte enable/disable `lru_crawler` ändern Sie Ihre benutzerdefinierte Parametergruppe.
### In Memcached 1.6.6 hinzugefügte Parameter
Für Memcached 1.6.6 werden keine zusätzlichen Parameter unterstützt.
**Familie der Parametergruppe:** memcached1.6
### Parameteränderungen für Memcached 1.5.10
Für Memcached 1.5.10 werden die folgenden zusätzlichen Parameter unterstützt.
**Familie der Parametergruppe:** memcached1.5
| Name | Details | Description |
| --- | --- | --- |
| no\$1modern | Standard: 1 Typ: Boolesch Veränderbar: Ja Zulässige Werte: 0, 1 Änderungen werden wirksam: Beim Start | Ein Alias für die Deaktivierung von `maxconns_fast` Befehlen `slab_reassign` `lru_maintainer_thread``lru_segmented`,, und. Wenn Sie Memcached 1.5 und höher verwenden, wird der hash\$1algorithm `no_modern` auch auf gesetzt. `jenkins` Bei Verwendung von Memcached 1.5.10 wird dies außerdem durch den Parameter gesteuert. `inline_ascii_reponse` `parallelly` Das heißt, wenn deaktiviert ist, `no_modern` ist es auch deaktiviert. `inline_ascii_reponse` Ab Memcached Engine 1.5.16 gilt der `inline_ascii_response` Parameter nicht mehr, sodass die Aktivierung oder Deaktivierung keine `no_modern` Auswirkung auf hat. `inline_ascii_reponse` Wenn er deaktiviert `no_modern` ist, dann werden`slab_reassign`, `lru_maintainer_thread``lru_segmented`, und aktiviert. `maxconns_fast` Da es sich bei den `hash_algorithm` Parametern `slab_automove` und nicht um SWITCH-Parameter handelt, basiert ihre Einstellung auf den Konfigurationen in der Parametergruppe. Wenn Sie den Parameter deaktivieren `no_modern` und zu ihm zurückkehren möchten`modern`, müssen Sie eine benutzerdefinierte Parametergruppe konfigurieren, um diesen Parameter zu deaktivieren, und dann einen Neustart durchführen, damit diese Änderungen wirksam werden. Der Standardkonfigurationswert für diesen Parameter wurde am 20. August 2021 von 0 in 1 geändert. Der aktualisierte Standardwert wird nach dem 20. August 2021 automatisch von neuen ElastiCache Benutzern für jede Region übernommen. Bestehende ElastiCache Benutzer in den Regionen vor dem 20. August 2021 müssen ihre benutzerdefinierten Parametergruppen manuell ändern, um diese neue Änderung zu übernehmen. |
| inline\$1ascii\$1resp | Standard: 0 Typ: Boolesch Veränderbar: Ja Zulässige Werte: 0, 1 Änderungen werden wirksam: Beim Start | Speichert Zahlen der `VALUE`-Antwort innerhalb eines Elements mit bis zu 24 Bytes. Geringe Verlangsamung für ASCII-Sätze `get` und `faster`. |
Für Memcached 1.5.10 werden die folgenden Parameter entfernt.
| Name | Details | Description |
| --- | --- | --- |
| expirezero\$1does\$1not\$1evict | Standard: 0 Typ: Boolesch Veränderbar: Ja Zulässige Werte: 0, 1 Änderungen werden wirksam: Beim Start | Wird in dieser Version nicht länger unterstützt |
| modern | Standard: 1 Typ: Boolesch Anpassbar: Ja (erfordert Neustart, wenn auf `no_modern`gesetzt) Zulässige Werte: 0, 1 Änderungen werden wirksam: Beim Start | Wird in dieser Version nicht länger unterstützt Ab dieser Version ist `no-modern` standardmäßig bei jedem Start oder Neustart aktiviert. |
### In Memcached 1.4.34 hinzugefügte Parameter
Für Memcached 1.4.34 werden keine zusätzlichen Parameter unterstützt.
**Familie der Parametergruppe:** memcached1.4
### In Memcached 1.4.33 hinzugefügte Parameter
Für Memcached 1.4.33 werden die folgenden zusätzlichen Parameter unterstützt.
**Familie der Parametergruppe:** memcached1.4
| Name | Details | Description |
| --- | --- | --- |
| modern | Standard: aktiviert Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Beim Start | Ein Alias für mehrere Funktionen. Das Aktivieren von `modern` ist gleichbedeutend mit dem Einschalten der folgenden Befehle und der Verwendung eines murmur3-Hash-Algorithmus: `slab_reassign`, `slab_automove`, `lru_crawler`, `lru_maintainer`, `maxconns_fast` und `hash_algorithm=murmur3`. |
| watch | Standard: aktiviert Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Sofort Protokolle werden möglicherweise verworfen, wenn der Benutzer die Grenzwerte für `watcher_logbuf_size` und `worker_logbuf_size` erreicht. | Protokollabrufe, Bereinigungen oder Mutationen. Wenn der Benutzer z. B. `watch` aktiviert, kann er Protokolle sehen, wenn `get`, `set`, `delete` oder `update` auftreten. |
| idle\$1timeout | Standard: 0 (deaktiviert) Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Beim Start | Die minimale Anzahl von Sekunden, die sich ein Client im Leerlauf befinden kann, bevor er zum Schließen aufgefordert wird. Wertebereich: 0 bis 86400. |
| track\$1sizes | Standard: deaktiviert Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Beim Start | Zeigt die Größen an, die jede Slab-Gruppe verbraucht hat. Wenn `track_sizes` aktiviert ist, können Sie `stats sizes` ausführen, ohne `stats sizes_enable` ausführen zu müssen. |
| watcher\$1logbuf\$1size | Standard: 256 (KB) Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Beim Start | Der Befehl `watch` schaltet die Stream-Protokollierung für Memcached ein. `watch` kann jedoch Protokolle verwerfen, wenn die Rate der Bereinigungen, Mutationen oder Abrufe so hoch ist, dass der Protokollierungspuffer voll wird. In solchen Fällen kann der Benutzer die Puffergröße erhöhen, um die Gefahr von Protokollverlusten zu verringern. |
| worker\$1logbuf\$1size | Standard: 64 (KB) Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Beim Start | Der Befehl `watch` schaltet die Stream-Protokollierung für Memcached ein. `watch` kann jedoch Protokolle verwerfen, wenn die Rate der Bereinigungen, Mutationen oder Abrufe so hoch ist, dass der Protokollierungspuffer voll wird. In solchen Fällen kann der Benutzer die Puffergröße erhöhen, um die Gefahr von Protokollverlusten zu verringern. |
| slab\$1chunk\$1max | Standard: 524288 (Byte) Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Beim Start | Gibt die maximale Größe eines Slabs an. Bei Festlegen einer kleineren Slab-Größe wird der Speicher effizienter genutzt. Elemente, die größer als `slab_chunk_max` sind, werden über mehrere Slabs hinweg aufgeteilt. |
| lru\$1crawler metadump [all\$11\$12\$13] | Standard: deaktiviert Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Sofort | Wenn lru\$1crawler aktiviert ist, sichert dieser Befehl ein Abbild aller Schlüssel. `all\|1\|2\|3` – alle Slabs oder geben Sie eine bestimmte Slab-Nummer an |
### In Memcached 1.4.24 hinzugefügte Parameter
Für Memcached 1.4.24 werden die folgenden zusätzlichen Parameter unterstützt.
**Familie der Parametergruppe:** memcached1.4
| Name | Details | Description |
| --- | --- | --- |
| disable\$1flush\$1all | Standard: 0 (deaktiviert) Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Beim Start | Hinzufügen von Parameter (`-F`), um flush\$1all zu deaktivieren. Nützlich, wenn Sie niemals eine volle Leerung für Produktions-Instances ausführen möchten. Werte: 0, 1 (Benutzer kann einen `flush_all` ausführen, wenn der Wert 0 ist). |
| hash\$1algorithm | Standard: jenkins Typ: Zeichenfolge Veränderbar: Ja Änderungen werden wirksam: Beim Start | Der zu verwendende Hash-Algorithmus. Zulässige Werte: murmur3 und jenkins. |
| lru\$1crawler | Standard: 0 (deaktiviert) Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart Sie können `lru_crawler` vorübergehend zur Laufzeit über die Befehlszeile aktivieren. Weitere Informationen finden Sie in der Spalte „Description“. | Bereinigt Slab-Klassen abgelaufener Elemente. Dies ist ein Vorgang mit geringen Auswirkungen, der im Hintergrund ausgeführt wird. Er erfordert zurzeit, dass das Durchsuchen mit einem manuellen Befehl initiiert wird. Um ihn auf bestimmte Zeit zu aktivieren, führen Sie `lru_crawler enable` über die Befehlszeile aus. `lru_crawler 1,3,5` durchläuft Slab-Klassen 1, 3 und 5 auf der Suche nach abgelaufenen Elementen, die zur Freelist hinzugefügt werden sollen. Werte: 0,1 Wenn `lru_crawler` über die Befehlszeile aktiviert wird, wird der Crawler so lange aktiviert, bis er über die Befehlszeile oder beim nächsten Neustart deaktiviert wird. Um ihn permanent zu aktivieren, müssen Sie den Parameterwert ändern. Weitere Informationen finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md). |
| lru\$1maintainer | Standard: 0 (deaktiviert) Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Beim Start | Ein Hintergrund-Thread, der Elemente zwischen den Objekten hin und her mischt, LRUs sobald die Kapazitäten erreicht sind. Werte: 0, 1. |
| expirezero\$1does\$1not\$1evict | Standard: 0 (deaktiviert) Typ: Boolesch Veränderbar: Ja Änderungen werden wirksam: Beim Start | Bewirkt bei Verwendung zusammen mit `lru_maintainer`, dass Elemente mit der Ablaufzeit 0 nicht bereinigt werden können. Dadurch kann der Speicher für andere Elemente, die bereinigt werden können, knapp werden. Kann so eingestellt werden, dass `lru_maintainer` ignoriert wird. |
### In Memcached 1.4.14 hinzugefügte Parameter
Für Memcached 1.4.14 werden die folgenden zusätzlichen Parameter unterstützt.
**Familie der Parametergruppe:** memcached1.4
**In Memcached 1.4.14 hinzugefügte Parameter**
| Name | Details | Description |
| --- | --- | --- |
| config\$1max | Standard: 16 Typ: Ganzzahl Veränderbar: Nein | Die maximale Anzahl von ElastiCache Konfigurationseinträgen. |
| config\$1size\$1max | Standard: 65536 Typ: Ganzzahl Veränderbar: Nein | Die maximale Größe der Konfigurationseinträge in Byte. |
| hashpower\$1init | Standard: 16 Typ: Ganzzahl Veränderbar: Nein | Die Anfangsgröße der ElastiCache Hashtabelle, ausgedrückt als Zweierpotenz. Der Standard ist 16 (2^16), oder 65536 Schlüssel. |
| maxconns\$1fast | Standard: 0(false) Typ: Boolescher Wert Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Ändert, auf welche Art neue Verbindungsanforderungen gehandhabt werden, wenn das maximale Verbindungslimit erreicht ist. Wenn dieser Parameter auf 0 (Null) eingestellt ist, werden neue Verbindungen zur Rückstandwarteschlange hinzugefügt und gewartet, bis andere Verbindungen geschlossen werden. Wenn der Parameter auf 1 gesetzt ist, wird ein Fehler an den Client ElastiCache gesendet und die Verbindung sofort geschlossen. |
| slab\$1automove | Standard: 0 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Korrigiert den Slab-AutoMove-Algorithmus: Wenn dieser Parameter auf 0 (Null) eingestellt ist, ist der AutoMove-Algorithmus deaktiviert. Wenn er auf 1 eingestellt ist, geht ElastiCache beim automatischen Verschieben von Slabs langsam und zurückhaltend vor. Wenn der Wert auf 2 gesetzt ist, werden Platten bei jeder Räumung ElastiCache aggressiv bewegt. (Dieser Modus wird ausschließlich zu Testzwecken empfohlen.) |
| slab\$1reassign | Standard: 0(false) Typ: Boolescher Wert Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Aktiviert oder deaktiviert die Slab-Neuzuweisung. Wenn dieser Parameter auf 1 eingestellt ist, können Sie mit dem Befehl „slabs reassign“ Speicher manuell neu zuweisen. |
### In Memcached 1.4.5 unterstützte Parameter
**Familie der Parametergruppe:** memcached1.4
Für Memcached 1.4.5 werden die folgenden Parameter unterstützt.
**In Memcached 1.4.5 hinzugefügte Parameter**
| Name | Details | Description |
| --- | --- | --- |
| backlog\$1queue\$1limit | Standard: 1024 Typ: Ganzzahl Veränderbar: Nein | Das Limit der Rückstandwarteschlange (Backlog Queue). |
| binding\$1protocol | Standard: auto Typ: Zeichenfolge Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Das Bindungsprotokoll. Zulässige Werte sind: `ascii` und `auto`. Eine Anleitung zum Ändern des Wertes von `binding_protocol` finden Sie unter [Änderung einer ElastiCache Parametergruppe](ParameterGroups.Modifying.md). |
| cas\$1disabled | Standard: 0(false) Typ: Boolescher Wert Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Bei dem Wert 1 (true) werden die Operationen check und set (CAS) deaktiviert und gespeicherte Elemente verbrauchen 8 Bytes weniger als bei aktiviertem CAS. |
| chunk\$1size | Standard: 48 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Die Mindestmenge, in Byte, von Speicher, die für den Schlüssel, Wert und die Flags des kleinsten Elements zuzuordnen sind. |
| chunk\$1size\$1growth\$1factor | Standard: 1.25 Typ: Gleitkommazahl Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Der Wachstumsfaktor, der die Größe aller nachfolgenden Memcached-Datenblöcke steuert. Jeder Datenblock wird chunk\$1size\$1growth\$1factor Mal größer als der vorherige Datenblock sein. |
| error\$1on\$1memory\$1exhausted | Standard: 0(false) Typ: Boolescher Wert Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Bei dem Wert 1 (true) gibt Memcached einen Fehler zurück, wenn kein Speicher zum Speichern der Elemente mehr verfügbar ist, anstatt Elemente zu bereinigen. |
| large\$1memory\$1pages | Standard: 0(false) Typ: Boolescher Wert Veränderbar: Nein | Falls 1 (true), ElastiCache wird versucht, große Speicherseiten zu verwenden. |
| lock\$1down\$1paged\$1memory | Standard: 0(false) Typ: Boolescher Wert Veränderbar: Nein | Falls 1 (wahr), ElastiCache wird der gesamte ausgelagerte Speicher gesperrt. |
| max\$1item\$1size | Standard: 1048576 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Die Größe, in Byte, des größten Elements, das im Cluster gespeichert werden kann. |
| max\$1simultaneous\$1connections | Standard: 65000 Typ: Ganzzahl Veränderbar: Nein | Die maximale Anzahl gleichzeitiger Verbindungen. |
| maximize\$1core\$1file\$1limit | Standard: 0(false) Typ: Boolescher Wert Anpassbar: Änderungen werden wirksam: Nach dem Neustart | Falls 1 (wahr), ElastiCache wird das Limit für die Kerndateien maximiert. |
| memcached\$1connections\$1overhead | Standard: 100 Typ: Ganzzahl Veränderbar: Ja Änderungen werden wirksam: Nach dem Neustart | Die Menge an Speicher, die für Memcached-Verbindungen und verschiedene Overhead-Anforderungen zu reservieren ist. Informationen zu diesem Parameter finden Sie unter [Overhead von Memcached-Verbindungen](#ParameterGroups.Memcached.Overhead). |
| requests\$1per\$1event | Standard: 20 Typ: Ganzzahl Veränderbar: Nein | Die maximale Anzahl von Anforderungen pro Ereignis für eine bestimmte Verbindung. Dieses Limit wird benötigt, um zu verhindern, dass die Ressourcen aufgebraucht werden. |
### Overhead von Memcached-Verbindungen
Der auf jedem Knoten zum Speichern von Elementen verfügbar gemachte Speicher ist der verfügbare Gesamtspeicher auf diesem Knoten (der im Parameter `max_cache_memory` gespeichert wird) minus des für Verbindungen und anderes Overhead verwendeten Speichers (der im Parameter `memcached_connections_overhead` gespeichert wird). Ein Knoten vom Typ `cache.m1.small` verfügt z. B. über `max_cache_memory` von 1300 MB. Bei einem `memcached_connections_overhead`-Standardwert von 100 MB hat der Memcached-Prozess 1200 MB zum Speichern von Elementen verfügbar.
Die Standardwerte für den Parameter `memcached_connections_overhead` genügen für die meisten Anwendungsfälle. Die erforderliche Menge, die für das Overhead der Verbindungen zugewiesen werden muss, kann abhängig von mehreren Faktoren, darunter Anforderungsrate, Nutzlastgröße und die Anzahl von Verbindungen, variieren.
Sie können den Wert von `memcached_connections_overhead` ändern, um den Anforderungen Ihrer Anwendung besser zu genügen. Wenn z. B. der Wert des Parameters `memcached_connections_overhead` erhöht wird, verringert sich die Menge des Speichers, der zum Speichern von Elementen verfügbar ist. Auch wird ein größerer Puffer für das Overhead von Verbindungen geschaffen. Wenn der Wert des Parameters `memcached_connections_overhead` verringert wird, erhalten Sie mehr Speicher zum Speichern von Elementen. Dadurch kann sich aber das Risiko bezüglich Swap-Nutzung und Leistungseinbußen erhöhen. Wenn Swap-Nutzung und Leistungseinbußen zu beobachten sind, versuchen Sie, den Wert des Parameters `memcached_connections_overhead` zu verringern.
**Wichtig**
Für den Knotentyp `cache.t1.micro` wird der Wert für `memcached_connections_overhead` folgendermaßen bestimmt:
Wenn Ihr Cluster die Standardparametergruppe verwendet, ElastiCache wird der Wert für `memcached_connections_overhead` auf 13 MB gesetzt.
Wenn Ihr Cluster eine Parametergruppe nutzt, die Sie selbst erstellt haben, können Sie als Wert für `memcached_connections_overhead` einen Wert Ihrer Wahl festlegen.
### Spezifische Parameter des Memcached-Knotentyps
Obwohl die meisten Parameter über einen einzelnen Wert verfügen, ist bei einigen Parametern der jeweilige Wert vom verwendeten Knotentyp abhängig. Die folgende Tabelle zeigt die Standardwerte der Parameter `max_cache_memory` und `num_threads` für jeden Knotentyp. Die Werte für diese Parameter können nicht geändert werden.
| Knotentyp | max\$1cache\$1memory (in Megabyte) | num\$1threads |
| --- | --- | --- |
| cache.t1.micro | 213 | 1 |
| cache.t2.micro | 555 | 1 |
| cache.t2.small | 1588 | 1 |
| cache.t2.medium | 3301 | 2 |
| cache.t3.micro | 512 | 2 |
| cache.t3.small | 1402 | 2 |
| cache.t3.medium | 3364 | 2 |
| cache.t4g.micro | 512 | 2 |
| cache.t4g.small | 1402 | 2 |
| cache.t4g.medium | 3164 | 2 |
| cache.m1.small | 1301 | 1 |
| cache.m1.medium | 3350 | 1 |
| cache.m1.large | 7100 | 2 |
| cache.m1.xlarge | 14600 | 4 |
| cache.m2.xlarge | 33800 | 2 |
| cache.m2.2xlarge | 30412 | 4 |
| cache.m2.4xlarge | 68000 | 16 |
| cache.m3.medium | 2850 | 1 |
| cache.m3.large | 6200 | 2 |
| cache.m3.xlarge | 13600 | 4 |
| cache.m3.2xlarge | 28600 | 8 |
| cache.m4.large | 6573 | 2 |
| cache.m4.xlarge | 11496 | 4 |
| cache.m4.2xlarge | 30412 | 8 |
| cache.m4.4xlarge | 62234 | 16 |
| cache.m4.10xlarge | 158355 | 40 |
| cache.m5.large | 6537 | 2 |
| cache.m5.xlarge | 13248 | 4 |
| cache.m5.2xlarge | 26671 | 8 |
| cache.m5.4xlarge | 53516 | 16 |
| cache.m5.12xlarge | 160900 | 48 |
| cache.m5.24xlarge | 321865 | 96 |
| cache.m6g.large | 6537 | 2 |
| cache.m6g.xlarge | 13248 | 4 |
| dache.m6g.2xlarge | 26671 | 8 |
| dache.m6g.4xlarge | 53516 | 16 |
| dache.m6g.8xlarge | 107000 | 32 |
| dache.m6g.12xlarge | 160900 | 48 |
| dache.m6g.16xlarge | 214577 | 64 |
| cache.c1.xlarge | 6600 | 8 |
| cache.r3.large | 13800 | 2 |
| cache.r3.xlarge | 29100 | 4 |
| cache.r3.2xlarge | 59600 | 8 |
| cache.r3.4xlarge | 120600 | 16 |
| cache.r3.8xlarge | 120600 | 32 |
| cache.r4.large | 12590 | 2 |
| cache.r4.xlarge | 25652 | 4 |
| cache.r4.2xlarge | 51686 | 8 |
| cache.r4.4xlarge | 103815 | 16 |
| cache.r4.8xlarge | 208144 | 32 |
| cache.r4.16xlarge | 416776 | 64 |
| cache.r5.large | 13387 | 2 |
| cache.r5.xlarge | 26953 | 4 |
| cache.r5.2xlarge | 54084 | 8 |
| cache.r5.4xlarge | 108347 | 16 |
| cache.r5.12xlarge | 325400 | 48 |
| cache.r5.24xlarge | 650869 | 96 |
| cache.r6g.large | 13387 | 2 |
| cache.r6g.xlarge | 26953 | 4 |
| dache.r6g.2xlarge | 54084 | 8 |
| dache.r6g.4xlarge | 108347 | 16 |
| dache.r6g.8xlarge | 214577 | 32 |
| dache.r6g.12xlarge | 325400 | 48 |
| dache.r6g.16xlarge | 429154 | 64 |
| cache.c7gn.large | 3164 | 2 |
| cache.c7gn.xlarge | 6537 | 4 |
| cache.c7gn.2xlarge | 13248 | 8 |
| cache.c7gn.4xlarge | 26671 | 16 |
| cache.c7gn.8xlarge | 53516 | 32 |
| cache.c7gn.12xlarge | 325400 | 48 |
| cache.c7gn.16xlarge | 108347 | 64 |
**Anmerkung**
Alle T2-Instances werden in einer Amazon Virtual Private Cloud (Amazon VPC) erstellt.
# Automatisches Verbinden einer EC2 Instanz und eines ElastiCache Caches
Sie können die ElastiCache Konsole verwenden, um die Einrichtung einer Verbindung zwischen einer Amazon Elastic Compute Cloud (Amazon EC2) -Instance und einem ElastiCache Cache zu vereinfachen. Oft befindet sich Ihr Cache in einem privaten Subnetz und Ihre EC2 Instance in einem öffentlichen Subnetz innerhalb einer VPC. Sie können einen SQL-Client auf Ihrer EC2 Instance verwenden, um eine Verbindung zu Ihrem Cache herzustellen. ElastiCache Die EC2 Instanz kann auch Webserver oder Anwendungen ausführen, die auf Ihren privaten ElastiCache Cache zugreifen.
![\[Automatisch einen ElastiCache Cache mit einer EC2 Instanz verbinden.\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ec2-elasticache-connect-network_diagram.png)
**Topics**
+ [Automatische Konnektivität mit einer EC2 Instanz](#ec2-elc-connect-overview)
+ [Anzeigen verbundener Rechenressourcen](#ec2-elc-connect-viewing)
## Automatische Konnektivität mit einer EC2 Instanz
Wenn Sie eine Verbindung zwischen einer EC2 Instance und einem ElastiCache Cache einrichten, konfiguriert ElastiCache automatisch die VPC-Sicherheitsgruppe für Ihre EC2 Instance und für Ihren ElastiCache Cache.
Die folgenden Anforderungen müssen erfüllt sein, um eine EC2 Instance mit einem ElastiCache Cache zu verbinden:
+ Die EC2 Instanz muss in derselben VPC wie der ElastiCache Cache existieren.
Wenn in derselben VPC keine EC2 Instanzen vorhanden sind, bietet die Konsole einen Link zum Erstellen einer Instanz.
+ Der Benutzer, der die Konnektivität einrichtet, muss über Berechtigungen verfügen, um die folgenden EC2 Amazon-Operationen auszuführen. Diese Berechtigungen werden in der Regel den EC2 Konten hinzugefügt, wenn sie erstellt werden. Weitere Informationen zu EC2 Berechtigungen finden Sie unter [Gewährung der erforderlichen Berechtigungen für EC2 Amazon-Ressourcen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/ec2-api-permissions.html).
+ `ec2:AuthorizeSecurityGroupEgress`
+ `ec2:AuthorizeSecurityGroupIngress`
+ `ec2:CreateSecurityGroup`
+ `ec2:DescribeInstances`
+ `ec2:DescribeNetworkInterfaces`
+ `ec2:DescribeSecurityGroups`
+ `ec2:ModifyNetworkInterfaceAttribute`
+ `ec2:RevokeSecurityGroupEgress`
Wenn Sie eine Verbindung zu einer EC2 Instance einrichten, ElastiCache verhält es sich entsprechend der aktuellen Konfiguration der Sicherheitsgruppen, die dem ElastiCache Cache und der EC2 Instance zugeordnet sind, wie in der folgenden Tabelle beschrieben.
****
| Aktuelle Konfiguration der ElastiCache Sicherheitsgruppe | Aktuelle Konfiguration der EC2 Sicherheitsgruppe | ElastiCache Aktion |
| --- | --- | --- |
| Dem ElastiCache Cache sind eine oder mehrere Sicherheitsgruppen zugeordnet, deren Name dem Muster entspricht`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Eine Sicherheitsgruppe, die dem Muster entspricht, wurde nicht geändert. Diese Sicherheitsgruppe hat nur eine Regel für eingehenden Datenverkehr mit der VPC-Sicherheitsgruppe der EC2 Instance als Quelle. | Der EC2 Instanz sind eine oder mehrere Sicherheitsgruppen zugeordnet, deren Name dem Muster entspricht. `elasticache-ec2-${cacheId}:${ec2InstanceId}` Eine Sicherheitsgruppe, die dem Muster entspricht, wurde nicht geändert. Diese Sicherheitsgruppe hat nur eine ausgehende Regel mit der VPC-Sicherheitsgruppe des ElastiCache Caches als Quelle. | ElastiCache ergreift keine Maßnahmen. Eine Verbindung zwischen der EC2 Instanz und dem ElastiCache Cache wurde bereits automatisch konfiguriert. Da bereits eine Verbindung zwischen der EC2 Instance und dem ElastiCache Cache besteht, werden die Sicherheitsgruppen nicht geändert. |
| Es gilt eine der folgenden Bedingungen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/compute-connection.html) | Es gilt eine der folgenden Bedingungen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/compute-connection.html) | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| Dem ElastiCache Cache sind eine oder mehrere Sicherheitsgruppen zugeordnet, deren Name dem Muster entspricht`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Eine Sicherheitsgruppe, die dem Muster entspricht, wurde nicht geändert. Diese Sicherheitsgruppe hat nur eine Regel für eingehenden Datenverkehr mit der VPC-Sicherheitsgruppe der EC2 Instance als Quelle. | Der EC2 Instanz sind eine oder mehrere Sicherheitsgruppen zugeordnet, deren Name dem Muster entspricht. `elasticache-ec2-${cacheId}:${ec2InstanceId}` ElastiCache Kann jedoch keine dieser Sicherheitsgruppen für die Verbindung mit dem ElastiCache Cache verwenden. ElastiCache kann keine Sicherheitsgruppe verwenden, die keine ausgehende Regel mit der VPC-Sicherheitsgruppe des ElastiCache Caches als Quelle hat. ElastiCache kann auch keine Sicherheitsgruppe verwenden, die geändert wurde. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| Dem ElastiCache Cache sind eine oder mehrere Sicherheitsgruppen zugeordnet, deren Name dem Muster entspricht`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Eine Sicherheitsgruppe, die dem Muster entspricht, wurde nicht geändert. Diese Sicherheitsgruppe hat nur eine Regel für eingehenden Datenverkehr mit der VPC-Sicherheitsgruppe der EC2 Instance als Quelle. | Eine gültige EC2 Sicherheitsgruppe für die Verbindung ist vorhanden, aber sie ist der EC2 Instance nicht zugeordnet. Die Sicherheitsgruppe trägt einen Namen, der dem Muster `ec2-elasticache-${ec2InstanceId}:${cacheId}` entspricht. Sie wurde nicht geändert. Es gibt nur eine ausgehende Regel mit der VPC-Sicherheitsgruppe des theElastiCache Caches als Quelle. | [ELC action: associate EC2 security group](#elc-action-associate-ec2-security-group) |
| Es gilt eine der folgenden Bedingungen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/compute-connection.html) | Der EC2 Instanz sind eine oder mehrere Sicherheitsgruppen zugeordnet, deren Name dem Muster entspricht`ec2-elasticache-${ec2InstanceId}:${cacheId}`. Eine Sicherheitsgruppe, die dem Muster entspricht, wurde nicht geändert. Diese Sicherheitsgruppe hat nur eine ausgehende Regel mit der VPC-Sicherheitsgruppe des ElastiCache Caches als Quelle. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
**ElastiCacheAktion: neue Sicherheitsgruppen erstellen**
ElastiCache ergreift die folgenden Aktionen:
+ Erstellt eine neue Sicherheitsgruppe, die dem Muster `elasticache-ec2-${cacheId}:${ec2InstanceId}` entspricht. Diese Sicherheitsgruppe hat eine eingehende Regel mit der VPC-Sicherheitsgruppe der EC2 Instance als Quelle. Diese Sicherheitsgruppe ist dem ElastiCache Cache zugeordnet und ermöglicht der EC2 Instance den Zugriff darauf.
+ Erstellt eine neue Sicherheitsgruppe, die dem Muster `elasticache-ec2-${cacheId}:${ec2InstanceId}` entspricht. Diese Sicherheitsgruppe hat eine ausgehende Regel mit der VPC-Sicherheitsgruppe des ElastiCache Caches als Ziel. Diese Sicherheitsgruppe ist der EC2 Instance zugeordnet und ermöglicht es der EC2 Instance, Traffic an den ElastiCache Cache zu senden.
**ElastiCache Aktion: EC2 Sicherheitsgruppe zuordnen**
ElastiCacheordnet der EC2 Instanz die gültige, bestehende EC2 Sicherheitsgruppe zu. Diese Sicherheitsgruppe ermöglicht es der EC2 Instance, Traffic an den ElastiCache Cache zu senden.
## Anzeigen verbundener Rechenressourcen
Sie können den verwenden AWS-Managementkonsole , um die Rechenressourcen anzuzeigen, die mit einem ElastiCache Cache verbunden sind. Zu den angezeigten Ressourcen gehören Rechenressourcenverbindungen, die automatisch eingerichtet wurden. Sie können beispielsweise einer Rechenressource den manuellen Zugriff auf einen Cache ermöglichen, indem Sie der mit dem Cache verknüpften VPC-Sicherheitsgruppe eine Regel hinzufügen. Diese Ressourcen werden nicht in der Liste der verbundenen Rechenressourcen angezeigt.
Damit eine Rechenressource aufgeführt wird, müssen dieselben Bedingungen gelten wie beim automatischen Verbinden einer EC2 Instanz und eines ElastiCache Caches.
**Um Rechenressourcen anzuzeigen, die mit einem ElastiCache Cache verbunden sind**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole
1. Wählen Sie im Navigationsbereich **Caches** und dann einen Valkey- oder Redis OSS-Cache aus.
1. Sehen Sie sich auf der Registerkarte **Konnektivität und Sicherheit** unter Rechenverbindung **einrichten** die Rechenressourcen an.
![\[Verbundene Rechenressourcen.\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/images/ec2-elasticache-connected_resources.png)
# Skalierung ElastiCache
Sie können Ihren ElastiCache Cache an Ihre Bedürfnisse anpassen. Serverlose Caches und knotenbasierte Cluster bieten verschiedene Skalierungsoptionen.
## ElastiCache Serverlose Skalierung
ElastiCache Serverless passt sich automatisch Ihrem Workload-Verkehr an, wenn er steigt oder fällt. Verfolgt für jeden ElastiCache serverlosen Cache ElastiCache kontinuierlich die Auslastung von Ressourcen wie CPU, Arbeitsspeicher und Netzwerk. Wenn eine dieser Ressourcen eingeschränkt ist, skaliert ElastiCache Serverless, indem es einen neuen Shard hinzufügt und die Daten auf den neuen Shard umverteilt, ohne dass es zu Ausfallzeiten für Ihre Anwendung kommt. Sie können die Ressourcen überwachen, die von Ihrem Cache-In CloudWatch verbraucht werden, indem Sie die `BytesUsedForCache` Metrik für den Cache-Datenspeicher und `ElastiCacheProcessingUnits` (ECPU) für die Computernutzung überwachen.
## Festlegen von Skalierungslimits zur Kostenkontrolle
Sie können wählen, ob Sie eine maximale Nutzung sowohl für den Cache-Datenspeicher als auch ECPU/second für Ihren Cache konfigurieren möchten, um die Cache-Kosten zu kontrollieren. Dadurch wird sichergestellt, dass Ihre Cache-Nutzung das konfigurierte Maximum nicht überschreitet.
Wenn Sie ein Skalierungsmaximum festlegen, kann es bei Ihrer Anwendung zu einer verringerten Cache-Leistung kommen, wenn der Cache das Maximum erreicht. Wenn Sie ein Maximum für den Cache-Datenspeicher festlegen und Ihr Cache-Datenspeicher das Maximum erreicht, ElastiCache beginnt das Löschen von Daten in Ihrem Cache, für die ein Time-To-Live (TTL) festgelegt ist. Dabei wird die LRU-Logik verwendet. Wenn es keine Daten gibt, die bereinigt werden können, wird bei Anfragen zum Schreiben zusätzlicher Daten eine Out-of-Memory-Fehlermeldung (OOM) angezeigt. Wenn Sie ein ECPU/second Maximum festlegen und die Rechenauslastung Ihrer Arbeitslast diesen Wert überschreitet, ElastiCache beginnt die Drosselung von Anfragen.
Wenn Sie ein Höchstlimit für `BytesUsedForCache` oder einrichten`ElastiCacheProcessingUnits`, empfehlen wir dringend, einen CloudWatch Alarm bei einem niedrigeren Wert als dem Höchstwert einzurichten, damit Sie benachrichtigt werden, wenn Ihr Cache in der Nähe dieser Grenzwerte arbeitet. Wir empfehlen, einen Alarm bei 75 % des von Ihnen festgelegten maximalen Limits einzustellen. Informationen zum Einrichten von CloudWatch Alarmen finden Sie in der Dokumentation.
## Vorskalierung mit Serverless ElastiCache
**ElastiCache Serverlose Vorskalierung**
Mit der Vorskalierung, auch Pre-Warming genannt, können Sie die unterstützten Mindestgrenzen für Ihren Cache festlegen. ElastiCache Sie können diese Mindestwerte für ElastiCache Verarbeitungseinheiten (ECPUs) pro Sekunde oder Datenspeicher festlegen. Dies kann bei der Vorbereitung auf erwartete Skalierungsereignisse nützlich sein. Wenn ein Spieleunternehmen beispielsweise innerhalb der ersten Minute, in der sein neues Spiel veröffentlicht wird, eine 5-fache Zunahme der Logins erwartet, kann es seinen Cache für diesen deutlichen Anstieg der Nutzung vorbereiten.
Sie können die Vorskalierung über die ElastiCache Konsole, CLI oder API durchführen. ElastiCache Serverless aktualisiert die im Cache verfügbaren ECPUs/second Daten innerhalb von 60 Minuten und sendet eine Ereignisbenachrichtigung, wenn die Aktualisierung des Mindestlimits abgeschlossen ist.
**So funktioniert die Vorskalierung**
Wenn das Mindestlimit für ECPUs/second den Datenspeicher über die Konsole, CLI oder API aktualisiert wird, ist dieses neue Limit innerhalb von 1 Stunde verfügbar. ElastiCache Serverless unterstützt 30 KB ECPUs/second bei leerem Cache und bis zu 90 KB ECPUs/sec bei Verwendung der Funktion „Aus Replikat lesen“. ElastiCache Serverless for Valkey 8.0 kann die Anzahl der unterstützten Anfragen pro Sekunde (RPS) alle 2 bis 3 Minuten verdoppeln, sodass 5 Millionen RPS pro Cache in weniger als 13 Minuten erreicht werden, und das bei gleichbleibender p50-Leselatenz von unter einer Millisekunde. Wenn Sie davon ausgehen, dass ein bevorstehendes Skalierungsereignis diese Rate überschreiten könnte, empfehlen wir, das Minimum auf den Höchstwert festzulegen, den ECPUs/sec Sie mindestens 60 Minuten vor ECPUs/second dem Spitzenereignis erwarten. Andernfalls kann es bei der Anwendung zu einer erhöhten Latenz und einer Drosselung von Anfragen kommen.
Sobald die Aktualisierung des Mindestlimits abgeschlossen ist, beginnt ElastiCache Serverless mit der Berechnung des neuen Mindestwerts ECPUs pro Sekunde oder des neuen Mindestspeichers. Dies ist auch dann der Fall, wenn Ihre Anwendung keine Anforderungen im Cache ausführt oder wenn Ihre Datenspeichernutzung unter dem Mindestwert liegt. Wenn Sie den Mindestgrenzwert gegenüber der aktuellen Einstellung herabsetzen, erfolgt die Aktualisierung sofort, sodass ElastiCache Serverless sofort mit der Messung des neuen Mindestlimits beginnt.
**Anmerkung**
Wenn Sie ein Mindestnutzungslimit festlegen, wird Ihnen dieses Limit in Rechnung gestellt, auch wenn Ihre tatsächliche Nutzung unter dem Mindestnutzungslimit liegt. Für die Nutzung von ECPU oder Datenspeicher, die das Mindestnutzungslimit überschreiten, wird der reguläre Tarif berechnet. Wenn Sie beispielsweise ein Mindestnutzungslimit von 100.000 ECPUs/second festlegen, werden Ihnen mindestens 1,224 USD pro Stunde berechnet (unter Verwendung der ECPU-Preise in US-East-1), auch wenn Ihre Nutzung unter dem festgelegten Mindestwert liegt.
ElastiCache Serverless unterstützt den angeforderten Mindestmaßstab auf aggregierter Ebene im Cache. ElastiCache Serverless unterstützt außerdem maximal 30.000 ECPUs/second pro Steckplatz (90.000 ECPUs/second bei Verwendung von Read from Replica mit READONLY-Verbindungen). Als bewährte Methode sollte Ihre Anwendung sicherstellen, dass die Schlüsselverteilung zwischen den Valkey- oder Redis-OSS-Steckplätzen und der Datenverkehr zwischen den Schlüsseln so einheitlich wie möglich sind.
## Skalierungsgrenzen mithilfe der Konsole festlegen und AWS CLI
*Skalierungsgrenzen mithilfe der AWS Konsole festlegen*
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Wählen Sie im Navigationsbereich die Engine aus, die auf dem Cache ausgeführt wird, den Sie ändern möchten.
1. Es wird eine Liste der Caches der ausgewählten Engine angezeigt.
1. Wählen Sie den zu ändernden Cache aus, indem Sie das Optionsfeld links neben dem Cache-Namen anklicken.
1. Wählen Sie **Aktionen** und dann **Ändern**.
1. Legen Sie unter **Nutzungslimits** die entsprechenden **Speicher** - oder **Rechenlimits** fest.
1. Klicken Sie auf **Änderungen in der Vorschau anzeigen** und dann auf **Änderungen speichern**.
**Festlegen von Skalierungsgrenzen mit dem AWS CLI**
Verwenden Sie die modify-serverless-cache API, um Skalierungsgrenzen mithilfe der CLI zu ändern.
**Linux:**
```
aws elasticache modify-serverless-cache --serverless-cache-name \
--cache-usage-limits 'DataStorage={Minimum=10,Maximum=100,Unit=GB}, ECPUPerSecond={Minimum=1000,Maximum=100000}'
```
**Windows:**
```
aws elasticache modify-serverless-cache --serverless-cache-name ^
--cache-usage-limits 'DataStorage={Minimum=10,Maximum=100,Unit=GB}, ECPUPerSecond={Minimum=1000,Maximum=100000}'
```
**Entfernen von Skalierungslimits mithilfe der CLI**
Um Skalierungsgrenzen mithilfe der CLI zu entfernen, setzen Sie die Parameter Minimal und Maximum auf 0.
**Linux:**
```
aws elasticache modify-serverless-cache --serverless-cache-name \
--cache-usage-limits 'DataStorage={Minimum=0,Maximum=0,Unit=GB}, ECPUPerSecond={Minimum=0,Maximum=0}'
```
**Windows:**
```
aws elasticache modify-serverless-cache --serverless-cache-name ^
--cache-usage-limits 'DataStorage={Minimum=0,Maximum=0,Unit=GB}, ECPUPerSecond={Minimum=0,Maximum=0}'
```
# Skalierung knotenbasierter Cluster
Die Datenmenge, die von einer Anwendung verarbeitet wird, ist selten statisch. Sie steigt und sinkt mit dem Unternehmenswachstum und unterliegt normalen Schwankungen im Bedarf. Wenn Sie Ihren Cache selbst verwalten, müssen Sie für Bedarfsspitzen ausreichend Hardware bereitstellen – dies kann kostspielig sein. Mit Amazon können ElastiCache Sie skalieren, um der aktuellen Nachfrage gerecht zu werden, und zahlen nur für das, was Sie tatsächlich nutzen. ElastiCache ermöglicht es Ihnen, Ihren Cache an die Nachfrage anzupassen.
**Anmerkung**
Wenn ein Valkey- oder Redis-OSS-Cluster in einer oder mehreren Regionen repliziert wird, werden diese Regionen der Reihe nach skaliert. Bei der Skalierung werden zuerst sekundäre Regionen und dann die primäre Region skaliert. Beim Herunterskalieren steht die primäre Region an erster Stelle und dann folgen alle sekundären Regionen.
Bei der Aktualisierung der Engine-Version lautet die Reihenfolge sekundäre Region und dann primäre Region.
**Topics**
+ [Skalierung auf Abruf für Memcached-Cluster](Scaling-self-designed.mem-heading.md)
+ [Manuelle Skalierung für Memcached-Cluster](Scaling.Memcached.manually.md)
+ [Skalierung für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert)](scaling-redis-classic.md)
+ [Skalierung von Replikatknoten für Valkey oder Redis OSS (Clustermodus deaktiviert)](Scaling.RedisReplGrps.md)
+ [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md)
# Skalierung auf Abruf für Memcached-Cluster
ElastiCache for Memcached bietet einen vollständig verwalteten In-Memory-Caching-Service, der Memcached in der Cloud bereitstellt, betreibt und vertikal skaliert.AWS
**Vertikale Skalierung auf Abruf**
Mit vertikaler Skalierung bietet Memcached ein leistungsstarkes, verteiltes Speicher-Caching-System, das häufig verwendet wird, um dynamische Anwendungen zu beschleunigen, indem die Datenbanklast verringert wird. ElastiCache Es speichert Daten und Objekte im RAM, sodass weniger Daten aus externen Datenquellen gelesen werden müssen.
Sie können vertikale Skalierung sowohl auf bestehende als auch auf neue knotenbasierte Cluster anwenden. Dies kann für Flexibilität bei der Ressourcenzuweisung sorgen, sodass Benutzer sich effizient an sich ändernde Workloads anpassen können, ohne die Clusterarchitektur zu ändern. Diese Skalierungsfähigkeit verbessert die Leistung, indem sie die Cache-Kapazität in Zeiten hoher Nachfrage erhöht und in Zeiten geringer Nachfrage nach unten skaliert, um die Kosten zu optimieren. Dies vereinfacht den Betrieb, macht die Erstellung neuer Cluster für wechselnde Ressourcenanforderungen überflüssig und ermöglicht eine schnelle Reaktion auf Verkehrsschwankungen. Insgesamt kann die vertikale Skalierung für knotenbasierte Memcached-Cluster dazu beitragen, die Kosteneffizienz zu erhöhen, die Ressourcennutzung zu verbessern und es Benutzern sogar zu ermöglichen, ihren Memcached-Instance-Typ zu ändern. All das erleichtert es Benutzern, ihre Caching-Infrastruktur an den tatsächlichen Anwendungsanforderungen auszurichten.
**Anmerkung**
Änderungen des Knotentyps sind nur für knotenbasierte Memcached-Cluster mit Engine-Versionen 1.5 oder höher verfügbar.
Auto Discovery muss aktiviert sein, um die vertikale Skalierung nutzen zu können.
## Einrichtung der vertikalen Skalierung auf Abruf für knotenbasierte Memcached-Cluster
Sie können die vertikale Skalierung auf Abruf für Memcached mit konfigurieren`scale-config`, die zwei Parameter enthält:
1. **ScaleIntervalMinutes:** Zeit (in Minuten) zwischen den Skalierungsstapeln während des Memcached-Upgrade-Vorgangs
1. **ScalePercentage:** Prozentsatz der Knoten, die während des Memcached-Upgrade-Vorgangs gleichzeitig skaliert werden
**Konvertierung eines vorhandenen Memcached-Knotentyps in einen Cache, der über die CLI vertikal skaliert werden kann**
Um einen vorhandenen knotenbasierten Memcached-Cluster in einen Cache umzuwandeln, der vertikal skaliert werden kann, können Sie dies über die CLI verwenden`elasticache modify-cache-cluster`.
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config \
--apply-immediately
```
**Vertikale Skalierung mit der CLI einrichten**
Um die vertikale Skalierung für einen knotenbasierten Memcached-Cluster über die CLI einzurichten, verwenden Sie `elasticache modify-cache-cluster` with `scale-config` und seine Parameter und. `ScalePercentage` `ScaleIntervalMinutes`
+ **scale-interval-minutes:** Dies definiert die Zeit (in Minuten) zwischen den Skalierungsstapeln. Diese Einstellung kann zwischen 2 und 30 Minuten liegen. Wenn kein Wert angegeben ist, wird der Standardwert von 5 Minuten angewendet.
+ **Skalierungsprozentsatz:** Dies gibt den Prozentsatz der Knoten an, die in jedem Stapel gleichzeitig skaliert werden sollen. Diese Einstellung kann zwischen 10 und 100 liegen. Die Einstellung wird beim Dividieren aufgerundet. Wenn das Ergebnis beispielsweise 49,5 wäre, wird die Einstellung 50 angewendet. Wenn kein Wert angegeben ist, wird der Standardwert 20 angewendet.
Diese Konfigurationsoptionen ermöglichen es Ihnen, den Skalierungsprozess an Ihre spezifischen Bedürfnisse anzupassen und dabei ein Gleichgewicht zwischen der Minimierung von Clusterunterbrechungen und der Optimierung der Skalierungsgeschwindigkeit zu finden. Der Parameter scale-config gilt nur für Memcached-Engine-Typen und wird für andere Cache-Engines ignoriert, sodass die Abwärtskompatibilität mit der bestehenden API-Nutzung für andere Cluster gewährleistet ist.
**API-Aufruf**
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config '{
"ScalePercentage": 30,
"ScaleIntervalMinutes": 2
}'
--apply-immediately
```
**Ergebnis:**
Gibt die Cluster-ID und die ausstehende Änderung zurück.
```
{
"CacheCluster": {
"CacheNodeType": "old_insance_type",
...
...
"PendingModifiedValues": {
"CacheNodeType": "new_instance_type"
},
}
}
```
**Listet Ihre vertikale Skalierungseinstellung für den Memcached-Cache auf**
Sie können die Skalierungsoptionen für Ihre Memcache-Caches abrufen und sehen, welche aktuellen Optionen für die vertikale Skalierung verfügbar sind.
**API-Aufruf**
```
aws elasticache list-allowed-node-type-modifications --cache-cluster-id
```
**Ergebnis:**
```
{
"ScaleUpModifications": [
"cache.x.xxxx",
"cache.x.xxxx"
],
"ScaleDownModifications": [
"cache.x.xxxx",
"cache.x.xxxx",
"cache.x.xxxx"
]
}
```
**Vertikale Skalierung für Memcached mit dem AWS-Managementkonsole**
Gehen Sie wie folgt vor, um mit dem einen AWS-Managementkonsole knotenbasierten Memcached-Cluster in einen vertikal skalierbaren Cluster umzuwandeln.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Konsole unter. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie den zu konvertierenden Memcached-Cluster aus.
1. Wählen Sie die Registerkarte **Ändern** aus.
1. Gehen Sie zum Abschnitt **Cache-Einstellungen** und wählen Sie den gewünschten **Knotentyp** aus.
1. Wählen Sie „**Änderungen in der Vorschau anzeigen**“ und überprüfen Sie die Änderungen.
1. Wählen Sie **Modify** aus.
## Automatisierte horizontale Skalierung für Memcached
ElastiCache lässt sich jetzt in den Service AWS Application Auto Scaling (AAS) integrieren, um automatisierte horizontale Skalierung für Memcached-Cluster zu ermöglichen. Sie können Skalierungsrichtlinien über den AWS Application Auto Scaling Scaling-Dienst definieren und die Anzahl der Knoten in Memcached-Clustern automatisch nach Bedarf anpassen, basierend auf vordefinierten Metriken oder Zeitplänen.
**Anmerkung**
Automatisierte horizontale Skalierung ist derzeit in den Regionen Peking und Ningxia nicht verfügbar.
Dies sind die verfügbaren Methoden für die automatische horizontale Skalierung Ihrer knotenbasierten Cluster.
+ **Geplante Skalierung:** Die Skalierung auf der Grundlage eines Zeitplans ermöglicht es Ihnen, Ihren eigenen Skalierungsplan für vorhersehbare Laständerungen festzulegen. Angenommen, die Auslastung Ihrer Webanwendung steigt am Mittwoch, bleibt am Donnerstag auf diesem hohen Niveau und fällt am Freitag ab. Sie können Auto Scaling so konfigurieren, dass die Kapazität am Mittwoch erhöht und die Kapazität am Freitag verringert wird.
+ **Zielverfolgung:** Bei Skalierungsrichtlinien für die Zielverfolgung wählen Sie eine Skalierungsmetrik und legen einen Zielwert fest. Application Auto Scaling erstellt und verwaltet die CloudWatch Alarme, die die Skalierungsrichtlinie auslösen, und berechnet die Skalierungsanpassung auf der Grundlage der Metrik und des Zielwerts. Durch die Skalierungsrichtlinie wird so viel Kapazität wie erforderlich hinzugefügt oder entfernt, damit die Metrik auf oder nahe an dem Zielwert gehalten wird.
**So richten Sie die horizontale Skalierung für einen knotenbasierten Memcached-Cluster über die CLI ein**
Bei der horizontalen Skalierung eines knotenbasierten Memcached-Clusters können Sie eine Ziel-Tracking-Richtlinie, eine geplante Richtlinie oder beides verwenden.
1. **Registrieren Sie eine Ressource als skalierbares Ziel**
Rufen Sie die `RegisterScalableTarget` API in AWS Application Auto Scaling auf, um das Ziel für die skalierbare Dimension zu registrieren`elasticache:cache-cluster:Nodes`.
**API: ApplicationAutoScaling. RegisterScalableTarget**
Eingabe:
```
{
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"MinCapacity": 20,
"MaxCapacity": 50
}
```
1. **Erstellen Sie eine Skalierungsrichtlinie für Target-Tracking**
Als Nächstes können Sie eine Skalierungsrichtlinie für die Zielverfolgung für die Ressource erstellen, indem Sie die API für die Skalierungsrichtlinie aufrufen.
1. **Vordefinierte Metrik**
Im Folgenden finden Sie eine Richtlinie, die entlang der Cache-Node-Dimension skaliert und dabei die vordefinierte Metrik verwendet` ElastiCacheCPUUtilization`, die für Cluster test-cluster-1 auf 50 festgelegt ist. Beim Löschen von Knoten für das Skalieren werden die letzten n Knoten entfernt.
API:. ApplicationAutoScaling PutScalingPolicy
Eingabe:
```
{
"PolicyName": "cpu50-target-tracking-scaling-policy",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"TargetValue": 50,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ElastiCacheCPUUtilization"
},
"ScaleOutCooldown": 600,
"ScaleInCooldown": 600
},
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1"
}
```
Ausgabe:
```
{
"PolicyARN": "arn:aws:autoscaling:us-west-2:012345678910:scalingPolicy:6d8972f3-efc8-437c-92d1-6270f29a66e7:resource/elasticache/cache-cluster/test-cluster-1:policyName/cpu50-target-tracking-scaling-policy",
"Alarms": [
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:012345678910:alarm:TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca",
"AlarmName": "TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:012345678910:alarm:TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmLow-1b437334-d19b-4a63-a812-6c67aaf2910d",
"AlarmName": "TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmLow-1b437334-d19b-4a63-a812-6c67aaf2910d"
}
]
}
```
1. **Benutzerdefinierte Metrik**
Sie können auch eine Skalierungsrichtlinie für die Dimension festlegen, indem Sie einen benutzerdefinierten Prozentsatz verwenden, der auf der Cloudwatch-Metrik basiert.
Eingabe:
```
{
"PolicyName": "cpu50-target-tracking-scaling-policy",
"PolicyType": "TargetTrackingScaling",
"TargetTrackingScalingPolicyConfiguration": {
"CustomizedMetricSpecification": {
"Dimensions": [
{
"Name": "MyMetricDimension",
"Value": "DimensionValue"
}
],
"MetricName": "MyCustomMetric",
"Namespace": "MyNamespace",
"Statistic": "Average",
"Unit": "Percent"
},
"TargetValue": 40,
"ScaleOutCooldown": 600,
"ScaleInCooldown": 600
},
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1"
}
```
1. **Geplante Aktionen**
Wenn Sie für ein bestimmtes Ereignis die Skalierung vornehmen und nach dem Ereignis wieder skalieren müssen, können Sie zwei geplante Aktionen erstellen, indem Sie die `PutScheduledAction` API aufrufen.
**Richtlinie 1: Skalierung**
Der `at` Befehl in `--schedule` plant, dass die Aktion einmal an einem bestimmten Datum und zu einer bestimmten Uhrzeit in der future ausgeführt wird. Das Zeitplanfeld unterstützt auch Rate (Minute, Stunde, Tag usw.) und Cron (für Cron-Ausdruck).
Zum angegebenen Datum und zur angegebenen Uhrzeit aktualisiert Application Auto Scaling die Werte `MinCapacity` und `MaxCapacity`. Application Auto Scaling skaliert MinCapacity auf bis zu 70 Cache-Knoten.
**API: ApplicationAutoScaling. PutScheduledAction**
Eingabe:
```
{
"ResourceId": "elasticache:ache-cluster:test-cluster-1",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ScalableTargetAction": {
"MaxCapacity": 100,
"MinCapacity": 70
},
"Schedule": "at(2020-05-20T17:05:00)",
"ScheduledActionName": "ScalingOutScheduledAction",
"ServiceNamespace": "elasticache",
}
```
**Richtlinie 2: Skalierung**
Am angegebenen Datum und zur angegebenen Uhrzeit aktualisiert Application Auto Scaling die Werte `MinCapacity` und und skaliert auf `MaxCapacity``MaxCapacity`, sodass die Cache-Knoten wieder auf 60 zurückgesetzt werden.
**API: ApplicationAutoScaling. PutScheduledAction**
Eingabe:
```
{
"ResourceId": "elasticache:cache-cluster:test-cluster-1",
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ScalableTargetAction": {
"MaxCapacity": 60,
"MinCapacity": 40
},
"Schedule": "at(2020-05-21T17:05:00)",
"ScheduledActionName": "ScalingInScheduledAction",
"ServiceNamespace": "elasticache",
}
```
1. **Sehen Sie sich die Skalierungsaktivitäten an**
Sie können die Skalierungsaktivitäten mithilfe der `DescribeScalingActivities` API anzeigen.
**API: ApplicationAutoScaling. DescribeScalingActivities**
Ausgabe:
```
{
"ScalingActivities": [
{
"ScalableDimension": "elasticache:elasticache:DesiredCount",
"Description": "Setting desired count to 30.",
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ActivityId": "4d759079-a31f-4d0c-8468-504c56e2eecf",
"StartTime": 1462574194.658,
"elasticacheNamespace": "elasticache",
"EndTime": 1462574276.686,
"Cause": "monitor alarm TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca in state ALARM triggered policy cpu50-target-tracking-scaling-policy",
"StatusMessage": "Failed to set desired count to 30",
"StatusCode": "Failed"
},
{
"ScalableDimension": "elasticache:elasticache:DesiredCount",
"Description": "Setting desired count to 25.",
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ActivityId": "90aff0eb-dd6a-443c-889b-b809e78061c1",
"StartTime": 1462574254.223,
"elasticacheNamespace": "elasticache",
"EndTime": 1462574333.492,
"Cause": "monitor alarm TargetTracking-elasticache/cache-cluster/test-cluster-1-AlarmHigh-d4f0770c-b46e-434a-a60f-3b36d653feca in state ALARM triggered policy cpu50-target-tracking-scaling-policy",
"StatusMessage": "Successfully set desired count to 25. Change successfully fulfilled by elasticache.",
"StatusCode": "Successful"
}
]
}
```
1. **Skalierungsrichtlinie bearbeiten/löschen**
Sie können Richtlinien bearbeiten oder löschen, indem Sie die `PutScalingPolicy` API erneut aufrufen oder Action aufrufen`DeleteScalingPolicy`. `DeleteScheduled`
1. **Registrierung skalierbarer Ziele aufheben**
Sie können die Registrierung des skalierbaren Ziels über die `DeregisterScalableTarget` API aufheben. Durch die Deregistrierung eines skalierbaren Ziels werden die Skalierungsrichtlinien und die damit verbundenen geplanten Aktionen gelöscht.
**API:. ApplicationAutoScaling DeregisterScalableTarget**
Eingabe:
```
{
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes"
}
```
1. **Skalierung der Richtlinienbereinigung**
1. **Mehrere Skalierungsrichtlinien**
Sie können mehrere Skalierungsrichtlinien erstellen. Im Folgenden finden Sie wichtige Hinweise zum Verhalten von [Auto Scaling Target Tracking](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html).
+ Sie können mehrere Skalierungsrichtlinien für die Ziel-Nachverfolgung für ein skalierbares Ziel besitzen, vorausgesetzt, dass diese alle verschiedene Metriken verwenden.
+ Die Absicht von Application Auto Scaling ist es, der Verfügbarkeit immer Vorrang einzuräumen. Daher unterscheidet sich das Verhalten von Application Auto Scaling, je nachdem, ob die Ziel-Tracking-Richtlinien für die Skalierung nach außen oder nach innen bereit sind. Sofern Richtlinien für die Ziel-Nachverfolgung für die horizontale Skalierung nach oben bereit sind, findet eine horizontale Skalierung des skalierbaren Ziels nach oben statt. Eine horizontale Skalierung nach unten wird jedoch nur vorgenommen, wenn alle Richtlinien für die Ziel-Nachverfolgung (mit aktivierter horizontaler Skalierung nach unten) zur horizontalen Skalierung nach unten bereit sind.
+ Wenn mehrere Richtlinien das skalierbare Ziel gleichzeitig zum Skalieren nach außen oder nach innen anweisen, erfolgt Application Auto Scaling auf der Grundlage der Richtlinie, die die größte Kapazität sowohl für die Skalierung nach innen als auch nach außen bietet. Dies bietet Ihnen eine größere Flexibilität für verschiedene Szenarien und stellt sicher, dass immer ausreichend Kapazität vorhanden ist, um Ihre Anwendungs-Workloads zu verarbeiten.
**Anmerkung**
AWS Application Auto Scaling stellt Skalierungsrichtlinien nicht in eine Warteschlange. Application Auto Scaling wartet, bis die erste Skalierung abgeschlossen ist, kühlt sich dann ab und wiederholt dann den obigen Algorithmus.
**Automatisches horizontales Skalieren eines knotenbasierten Memcached-Clusters über AWS-Managementkonsole**
Gehen Sie wie folgt vor, um mit dem einen vorhandenen AWS-Managementkonsole knotenbasierten Memcache-Cluster in einen horizontal skalierbaren Cluster umzuwandeln.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Konsole unter. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie den zu konvertierenden Memcached-Cache aus.
1. Gehen Sie zur Registerkarte **Autoscaling**.
1. Wählen Sie die anzuwendende Skalierungsrichtlinie aus, indem Sie entweder **Dynamische Skalierung hinzufügen oder Geplante Skalierung** **hinzufügen** auswählen.
1. Geben Sie nach Bedarf die Details für die ausgewählte Richtlinie ein.
1. Klicken Sie auf **Create**.
# Manuelle Skalierung für Memcached-Cluster
Die manuelle horizontale Skalierung eines Memcached-Clusters nach innen oder außen ist so einfach wie das Hinzufügen oder Entfernen von Knoten aus dem Cluster. Memcached-Cluster bestehen aus 1 bis 60 Knoten.
Da Sie in einem Memcached-Cluster Ihre Daten auf alle vorhandenen Knoten verteilen können, müssen Sie selten auf einen Knotentyp mit mehr Speicher hochskalieren. Da die Memcached-Engine jedoch keine Daten speichert, ist Ihr neuer Cluster bei der Skalierung auf einen anderen Knotentyp zunächst leer, es sei denn, Ihre Anwendung füllt ihn auf.
Um Ihren Memcached-Cluster manuell vertikal zu skalieren, müssen Sie einen neuen Cluster erstellen. Memcached-Cluster sind zunächst leer, bis sie von der Anwendung befüllt werden.
**Manuelles Skalieren von Memcached-Clustern**
| Action | Thema |
| --- | --- |
| Ausskalieren | [Hinzufügen von Knoten zu einem Cluster](Clusters.html#AddNode) |
| Einskalieren | [Löschen von Knoten aus einem Cluster](Clusters.html#DeleteNode) |
| Ändern von Knotentypen | [Manuelles vertikales Skalieren knotenbasierter Memcached-Cluster](#Scaling.Memcached.Vertically) |
**Topics**
+ [Manuelles horizontales Skalieren eines knotenbasierten Memcached-Clusters](#Scaling.Memcached.Horizontally)
+ [Manuelles vertikales Skalieren knotenbasierter Memcached-Cluster](#Scaling.Memcached.Vertically)
## Manuelles horizontales Skalieren eines knotenbasierten Memcached-Clusters
Die Memcached-Engine unterstützt die Partitionierung Ihrer Daten über mehrere Knoten hinweg. Dadurch lassen sich Memcached-Cluster einfach horizontal skalieren. Ein Memcached-Cluster wird einfach durch Hinzufügen oder Entfernen von Knoten horizontal skaliert.
In den folgenden Themen wird erläutert, wie Sie Memcached-Cluster durch Hinzufügen oder Entfernen von Knoten ein- oder ausskalieren.
+ [Hinzufügen von Knoten zu einem Cluster](Clusters.html#AddNode)
+ [Löschen von Knoten aus Ihrem Cluster](Clusters.html#AddNode)
Jedes Mal, wenn Sie die Anzahl der Knoten in Ihrem Memcached-Cluster ändern, müssen Sie zumindest einen Teil Ihres Keyspace neu zuordnen, sodass er dem richtigen Knoten zugeordnet ist. Detaillierte Informationen zum Lastausgleich Ihres Memcached-Clusters finden Sie unter [Konfiguration Ihres ElastiCache Clients für einen effizienten Lastenausgleich (Memcached)](BestPractices.LoadBalancing.md).
Wenn Sie für Ihr Memcached-Cluster Auto Discovery verwenden, müssen Sie die Endpunkte in Ihrer Anwendung nicht ändern, wenn Sie Knoten hinzufügen oder entfernen. Weitere Informationen zu Auto Discovery finden Sie unter [Identifizieren Sie automatisch Knoten in Ihrem Cluster (Memcached)](AutoDiscovery.md). Wenn Sie Auto Discovery nicht verwenden, müssen Sie bei jeder Änderung der Anzahl der Knoten in Ihrem Memcached-Cluster die Endpunkte in Ihrer Anwendung aktualisieren.
## Manuelles vertikales Skalieren knotenbasierter Memcached-Cluster
Wenn Sie Ihren Memcached-Cluster manuell nach oben oder unten skalieren, müssen Sie einen neuen Cluster erstellen. Memcached-Cluster sind zunächst leer, bis sie von der Anwendung befüllt werden.
**Wichtig**
Vergewissern Sie sich beim Skalieren zu einem kleineren Knotentyp davon, dass der Speicher des kleineren Knotentyps für Ihre Daten und den Overhead ausreicht. Weitere Informationen finden Sie unter [Auswahl der Knotengröße](CacheNodes.SelectSize.md).
**Topics**
+ [Vertikales Skalieren eines knotenbasierten Memcached-Clusters (Konsole)](#Scaling.Memcached.Vertically.CON)
+ [Vertikales Skalieren eines knotenbasierten Memcached-Clusters ()AWS CLI](#Scaling.Memcached.Vertically.CLI)
+ [Vertikale Skalierung eines knotenbasierten Memcached-Clusters (API) ElastiCache](#Scaling.Memcached.Vertically.API)
### Vertikales Skalieren eines knotenbasierten Memcached-Clusters (Konsole)
Das folgende Verfahren führt Sie durch die vertikale Skalierung eines knotenbasierten Memcache-Clusters mithilfe von.AWS-Managementkonsole
1. Erstellen Sie einen neuen Cluster mit dem neuen Knotentyp. Weitere Informationen finden Sie unter [Erstellen eines Memcached-Clusters (Konsole)](Clusters.Create-mc.md#Clusters.Create.CON.Memcached).
1. Aktualisieren Sie in Ihrer Anwendung die Endpunkte auf die neuen Cluster-Endpunkte. Weitere Informationen finden Sie unter [Die Endpunkte eines Clusters finden (Konsole) (Memcached)](Endpoints.md#Endpoints.Find.Memcached).
1. Löschen Sie den alten Cluster. Weitere Informationen finden Sie unter [Löschen eines neuen Knotens in Memcached](Clusters.html#Delete.CON.Memcached).
### Vertikales Skalieren eines knotenbasierten Memcached-Clusters ()AWS CLI
Das folgende Verfahren führt Sie durch die vertikale Skalierung eines knotenbasierten Memcache-Clusters mithilfe von.AWS CLI
1. Erstellen Sie einen neuen Cluster mit dem neuen Knotentyp. Weitere Informationen finden Sie unter [Erstellen eines Clusters (AWS CLI)](Clusters.Create.md#Clusters.Create.CLI).
1. Aktualisieren Sie in Ihrer Anwendung die Endpunkte auf die neuen Cluster-Endpunkte. Weitere Informationen finden Sie unter [Suchen von Endpunkten (AWS CLI)](Endpoints.md#Endpoints.Find.CLI).
1. Löschen Sie den alten Cluster. Weitere Informationen finden Sie unter [Verwenden Sie den AWS CLI, um einen ElastiCache Cluster zu löschen](Clusters.Delete.md#Clusters.Delete.CLI).
### Vertikale Skalierung eines knotenbasierten Memcached-Clusters (API) ElastiCache
Das folgende Verfahren führt Sie durch die vertikale Skalierung eines knotenbasierten Memcache-Clusters mithilfe der API. ElastiCache
1. Erstellen Sie einen neuen Cluster mit dem neuen Knotentyp. Weitere Informationen finden Sie unter [Einen Cluster für Memcached (API) erstellen ElastiCache](Clusters.Create-mc.md#Clusters.Create.API.mem-heading).
1. Aktualisieren Sie in Ihrer Anwendung die Endpunkte auf die neuen Cluster-Endpunkte. Weitere Informationen finden Sie unter [Endpunkte finden (API) ElastiCache](Endpoints.md#Endpoints.Find.API).
1. Löschen Sie den alten Cluster. Weitere Informationen finden Sie unter [Verwenden der ElastiCache API](Clusters.Delete.md#Clusters.Delete.API).
# Skalierung für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert)
Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) können ein Einzelknoten-Cluster mit 0 Shards oder Mehrknoten-Cluster mit 1 Shard sein. Cluster mit nur einem Knoten verwenden einen Knoten sowohl für Lese- als auch für Schreibvorgänge. Cluster mit mehreren Knoten haben immer einen Knoten als read/write primären Knoten mit 0 bis 5 schreibgeschützten Replikatknoten.
**Topics**
+ [Skalierung für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert)](#Scaling.RedisStandalone)
**Skalierung von Valkey- oder Redis OSS-Clustern**
| Action | Valkey oder Redis OSS (Clustermodus deaktiviert) | Valkey oder Redis OSS (Clustermodus aktiviert) |
| --- | --- | --- |
| Einskalieren | [Knoten aus einem ElastiCache Cluster entfernen](Clusters.DeleteNode.md) | [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md) |
| Ausskalieren | [Hinzufügen von Knoten zu einem Cluster](Clusters.html#AddNode) | [Online-Resharding für Valkey oder Redis OSS (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) |
| Ändern von Knotentypen | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/scaling-redis-classic.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/scaling-redis-classic.html) | [Vertikales Online-Skalieren durch Ändern des Knotentyps](redis-cluster-vertical-scaling.md) |
| Ändern der Anzahl der Knotengruppen | Wird für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) nicht unterstützt | [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md) |
**Contents**
+ [Skalierung für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert)](#Scaling.RedisStandalone)
+ [Skalierung von Valkey- oder Redis OSS-Clustern mit einem Knoten](#Scaling.RedisStandalone.ScaleUp)
+ [Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus deaktiviert) (Konsole) mit einem Knoten](#Scaling.RedisStandalone.ScaleUp.CON)
+ [Skalierung von Valkey- oder Redis OSS-Clustern mit einem Knoten ()AWS CLI](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Skalierung von Valkey- oder Redis OSS-Clustern (API) mit einem Knoten ElastiCache](#Scaling.RedisStandalone.ScaleUp.API)
+ [Herunterskalierung von Valkey- oder Redis OSS-Clustern mit einem Knoten](#Scaling.RedisStandalone.ScaleDown)
+ [Herunterskalierung eines Valkey- oder Redis OSS-Clusters mit einem Knoten (Konsole)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [Herunterskalierung der Valkey- oder Redis OSS-Cluster mit einem Knoten ()AWS CLI](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [Herunterskalierung der Valkey- oder Redis OSS-Cluster (API) mit einem Knoten ElastiCache](#Scaling.RedisStandalone.ScaleDown.API)
## Skalierung für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert)
Valkey- oder Redis OSS-Knoten (Clustermodus deaktiviert) müssen groß genug sein, um alle Cache-Daten plus den Valkey- oder Redis-OSS-Overhead aufzunehmen. Um die Datenkapazität Ihres Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) zu ändern, müssen Sie vertikal skalieren. Sie müssen auf einen größeren Knotentyp skalieren, um die Datenkapazität zu erhöhen, oder auf einen kleineren Knotentyp herunterskalieren, um die Datenkapazität zu reduzieren.
Der ElastiCache Skalierungsprozess ist darauf ausgelegt, Ihre vorhandenen Daten bestmöglich beizubehalten, und erfordert eine erfolgreiche Valkey- oder Redis-OSS-Replikation. Für Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) empfehlen wir, Valkey oder Redis OSS ausreichend Arbeitsspeicher zur Verfügung zu stellen.
Sie können Ihre Daten nicht auf mehrere Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) partitionieren. Wenn Sie jedoch nur die Lesekapazität Ihres Clusters erhöhen oder verringern müssen, können Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) mit Replikatknoten erstellen und Read Replicas hinzufügen oder entfernen. Informationen zum Erstellen eines Valkey- oder Redis OSS-Clusters (Clustermodus deaktiviert) mit Replikatknoten, die Ihren Valkey- oder Redis OSS-Cluster mit einem Knoten als primärem Cluster verwenden, finden Sie unter. [Erstellen eines Valkey-Clusters (Cluster-Modus deaktiviert) (Konsole)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
Nachdem Sie den Cluster mit Replikaten erstellt haben, können Sie die Lesekapazität durch Hinzufügen von Read Replicas erweitern. Später kann die Lesekapazität durch Entfernen von Read Replicas wieder reduziert werden. Für weitere Informationen siehe [Erhöhen der Lesekapazität](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleOut) oder [Verringern der Lesekapazität](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleIn).
Valkey- oder Redis OSS-Cluster (Cluster-Modus deaktiviert) mit Replikaten bieten nicht nur die Möglichkeit, die Lesekapazität zu skalieren, sondern bieten auch weitere Geschäftsvorteile. Weitere Informationen finden Sie unter [Hohe Verfügbarkeit mit Replikationsgruppen](Replication.md).
**Wichtig**
Wenn Ihre Parametergruppe Speicher für Valkey- oder Redis-OSS-Overhead reserviert, stellen Sie vor Beginn der Skalierung sicher, dass Sie über eine benutzerdefinierte Parametergruppe verfügen, die die richtige Speichermenge für Ihren neuen Knotentyp reserviert. `reserved-memory` Alternativ können Sie eine benutzerdefinierte Parametergruppe anpassen, die `reserved-memory-percent` verwendet, und diese Parametergruppe für Ihren neuen Cluster verwenden.
Wenn Sie `reserved-memory-percent` verwenden, ist dies nicht erforderlich.
Weitere Informationen finden Sie unter [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md).
**Topics**
+ [Skalierung von Valkey- oder Redis OSS-Clustern mit einem Knoten](#Scaling.RedisStandalone.ScaleUp)
+ [Herunterskalierung von Valkey- oder Redis OSS-Clustern mit einem Knoten](#Scaling.RedisStandalone.ScaleDown)
### Skalierung von Valkey- oder Redis OSS-Clustern mit einem Knoten
Wenn Sie einen Valkey- oder Redis OSS-Cluster mit einem Knoten skalieren, ElastiCache führt der folgende Prozess durch, unabhängig davon, ob Sie die ElastiCache Konsole, die oder die API verwenden.AWS CLI ElastiCache
1. Ein neuer Cluster mit dem neuen Knotentyp wird in derselben Availability Zone wie der vorhandene Cluster eingerichtet.
1. Die Cache-Daten im vorhandenen Cluster werden in den neuen Cluster kopiert. Wie lange dieser Vorgang dauert, hängt von Ihrem Knotentyp und davon ab, wie viele Daten sich im Cluster befinden.
1. Lese- und Schreibvorgänge werden jetzt über den neuen Cluster bedient. Da die Endpunkte des neuen Clusters dieselben sind wie die des alten Clusters, müssen Sie die Endpunkte in Ihrer Anwendung nicht aktualisieren. Sie werden eine kurze Unterbrechung (einige Sekunden) der Lese- und Schreiboperationen des Primärknotens feststellen, während der DNS-Eintrag aktualisiert wird.
1. ElastiCache löscht den alten Cluster. Sie werden eine kurze Unterbrechung (einige Sekunden) der Lese- und Schreiboperationen des alten Knotens feststellen, da die Verbindungen zum alten Knoten getrennt werden.
**Anmerkung**
Bei Clustern, auf denen der R6gd-Knotentyp ausgeführt wird, können Sie nur auf Knotengrößen innerhalb der R6gd-Knotenfamilie skalieren.
Wie in der folgenden Tabelle dargestellt, ist Ihr Valkey- oder Redis-OSS-Scale-Up-Vorgang blockiert, wenn Sie für das nächste Wartungsfenster ein Engine-Upgrade geplant haben. Weitere Informationen zu Wartungsfenstern finden Sie unter [Verwaltung der ElastiCache Cluster-Wartung](maintenance-window.md).
**Blockierte Valkey- oder Redis OSS-Operationen**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/scaling-redis-classic.html)
Wenn Sie durch ausstehende Operationen blockiert werden, haben Sie folgende Möglichkeiten.
+ Planen Sie Ihren Valkey- oder Redis OSS-Scale-up-Vorgang für das nächste Wartungsfenster, indem Sie das Kontrollkästchen **Sofort anwenden** deaktivieren (CLI use:`--no-apply-immediately`, API use:). `ApplyImmediately=false`
+ Warten Sie bis zu Ihrem nächsten Wartungsfenster (oder danach), um Ihren Valkey- oder Redis OSS-Skalierungsvorgang durchzuführen.
+ Fügen Sie das Valkey- oder Redis OSS-Engine-Upgrade zu dieser Cluster-Änderung hinzu, wobei das Kontrollkästchen **Sofort anwenden** aktiviert ist (CLI use:`--apply-immediately`, API use:`ApplyImmediately=true`). Dadurch wird die Skalierung freigegeben, da das Engine-Upgrade sofort ausgeführt wird.
Sie können einen Valkey- oder Redis OSS-Cluster mit einem Knoten (Clustermodus deaktiviert) mithilfe der ElastiCache Konsole, der oder der API hochskalieren.AWS CLI ElastiCache
**Wichtig**
Wenn Ihre Parametergruppe Speicher für Valkey- oder Redis OSS-Overhead reserviert, stellen Sie vor Beginn der Skalierung sicher, dass Sie über eine benutzerdefinierte Parametergruppe verfügen, die die richtige Speichermenge für Ihren neuen Knotentyp reserviert. `reserved-memory` Alternativ können Sie eine benutzerdefinierte Parametergruppe anpassen, die `reserved-memory-percent` verwendet, und diese Parametergruppe für Ihren neuen Cluster verwenden.
Wenn Sie `reserved-memory-percent` verwenden, ist dies nicht erforderlich.
Weitere Informationen finden Sie unter [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md).
#### Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus deaktiviert) (Konsole) mit einem Knoten
Das folgende Verfahren beschreibt, wie Sie einen Valkey- oder Redis OSS-Cluster mit einem Knoten mithilfe der Management Console skalieren. ElastiCache Während dieses Vorgangs bearbeitet Ihr Valkey- oder Redis OSS-Cluster weiterhin Anfragen mit minimaler Ausfallzeit.
**So skalieren Sie einen Valkey- oder Redis OSS-Cluster mit einem Knoten (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Valkey- oder Redis OSS-Cluster** aus.
1. Wählen Sie aus der Clusterliste den Cluster aus, den Sie skalieren möchten (auf ihm muss die Valkey- oder Redis OSS-Engine ausgeführt werden, nicht die geclusterte Valkey- oder Redis OSS-Engine).
1. Wählen Sie **Ändern** aus.
1. Gehen Sie im **Modify Cluster**-Assistenten wie folgt vor:
1. Wählen Sie in der Liste **Node type** den Knotentyp aus, auf den Sie skalieren möchten.
1. Wenn Sie zur Speicherverwaltung `reserved-memory` verwenden, wählen Sie in der Liste **Parameter Group** die benutzerdefinierte Parametergruppe aus, die die korrekte Speichermenge für den neuen Knotentyp reserviert.
1. Wenn Sie die Skalierung sofort starten möchten, aktivieren Sie das Kontrollkästchen **Apply immediately**. Wenn Sie das Kontrollkästchen für **Apply immediately** nicht aktivieren, wird die Skalierung während des nächsten Wartungsfensters des Clusters durchgeführt.
1. Wählen Sie **Ändern** aus.
Wenn Sie im vorherigen Schritt **Apply immediately** aktiviert haben, ändert sich der Cluster-Status zu *modifying*. Wenn der Status zu *available* wechselt, ist die Änderung abgeschlossen und Sie können den neuen Cluster verwenden.
#### Skalierung von Valkey- oder Redis OSS-Clustern mit einem Knoten ()AWS CLI
Das folgende Verfahren beschreibt, wie Sie einen Valkey- oder Redis-OSS-Cluster mit einem Knoten mithilfe von skalieren.AWS CLI Während dieses Vorgangs bearbeitet Ihr Valkey- oder Redis OSS-Cluster weiterhin Anfragen mit minimaler Ausfallzeit.
**Um einen Valkey- oder Redis OSS-Cluster mit einem Knoten zu skalieren ()AWS CLI**
1. Ermitteln Sie die Knotentypen, auf die Sie skalieren können, indem Sie den AWS CLI`list-allowed-node-type-modifications` Befehl mit dem folgenden Parameter ausführen.
+ `--cache-cluster-id`
Für Linux, macOS oder Unix:
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Für Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small ",
],
}
```
Weitere Informationen finden Sie unter [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in der *AWS CLI-Referenz*.
1. Ändern Sie Ihren vorhandenen Cluster, indem Sie den zu skalierenden Cluster und den neuen, größeren Knotentyp angeben. Verwenden Sie dazu den AWS CLI`modify-cache-cluster` Befehl und die folgenden Parameter.
+ `--cache-cluster-id`— Der Name des Clusters, den Sie skalieren möchten.
+ `--cache-node-type`— Der neue Knotentyp, für den Sie den Cluster skalieren möchten. Der Wert muss einer der Knotentypen sein, die in Schritt 1 mit dem Befehl `list-allowed-node-type-modifications` zurückgegeben wurden.
+ `--cache-parameter-group-name` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `--apply-immediately` – Führt die Skalierung sofort aus. Wenn Sie die Skalierung für das nächste Wartungsfenster des Clusters planen möchten, verwenden Sie den Parameter `--no-apply-immediately`.
Für Linux, macOS oder Unix:
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cache-cluster \
--cache-node-type cache.m3.xlarge \
--cache-parameter-group-name redis32-m2-xl \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-cache-cluster ^
--cache-cluster-id my-redis-cache-cluster ^
--cache-node-type cache.m3.xlarge ^
--cache-parameter-group-name redis32-m2-xl ^
--apply-immediately
```
Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format).
```
{
"CacheCluster": {
"Engine": "redis",
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis6.x",
"ParameterApplyStatus": "in-sync"
},
"SnapshotRetentionLimit": 1,
"CacheClusterId": "my-redis-cache-cluster",
"CacheSecurityGroups": [],
"NumCacheNodes": 1,
"SnapshotWindow": "00:00-01:00",
"CacheClusterCreateTime": "2017-02-21T22:34:09.645Z",
"AutoMinorVersionUpgrade": true,
"CacheClusterStatus": "modifying",
"PreferredAvailabilityZone": "us-west-2a",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/home#client-download:",
"CacheSubnetGroupName": "default",
"EngineVersion": "6.0",
"PendingModifiedValues": {
"CacheNodeType": "cache.m3.2xlarge"
},
"PreferredMaintenanceWindow": "tue:11:30-tue:12:30",
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
}
}
```
Weitere Informationen finden Sie unter [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) in der *AWS CLI-Referenz*.
1. Wenn Sie den verwendet haben`--apply-immediately`, überprüfen Sie den Status des neuen Clusters mithilfe des AWS CLI`describe-cache-clusters` Befehls mit dem folgenden Parameter. Wenn sich der Status auf *verfügbar* ändert, können Sie mit der Verwendung des neuen, größeren Clusters beginnen.
+ `--cache-cluster-id`— Der Name Ihres Valkey- oder Redis OSS-Clusters mit einem Knoten. Verwenden Sie diesen Parameter, um einen bestimmten Cluster und nicht alle Cluster zu beschreiben.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
Weitere Informationen finden Sie unter [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) in der *AWS CLI-Referenz*.
#### Skalierung von Valkey- oder Redis OSS-Clustern (API) mit einem Knoten ElastiCache
Das folgende Verfahren beschreibt, wie Sie einen Valkey- oder Redis-OSS-Cluster mit einem Knoten mithilfe der API skalieren. ElastiCache Während dieses Vorgangs bearbeitet Ihr Valkey- oder Redis OSS-Cluster weiterhin Anfragen mit minimaler Ausfallzeit.
**Um einen Valkey- oder Redis OSS-Cluster (API) mit einem Knoten zu skalieren ElastiCache**
1. Ermitteln Sie die Knotentypen, auf die Sie skalieren können, indem Sie die ElastiCache `ListAllowedNodeTypeModifications` API-Aktion mit dem folgenden Parameter ausführen.
+ `CacheClusterId`— Der Name des Valkey- oder Redis-OSS-Clusters mit einem Knoten, den Sie skalieren möchten.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in der *Amazon ElastiCache API-Referenz*.
1. Ändern Sie Ihren vorhandenen Cluster und geben Sie den zu skalierenden Cluster und den neuen, größeren Knotentyp an. Verwenden Sie dazu die `ModifyCacheCluster` ElastiCache API-Aktion und die folgenden Parameter.
+ `CacheClusterId`— Der Name des Clusters, den Sie skalieren möchten.
+ `CacheNodeType`— Der neue, größere Knotentyp, auf den Sie den Cluster skalieren möchten. Dieser Wert muss einer der Knotentypen sein, die von der `ListAllowedNodeTypeModifications` Aktion im vorherigen Schritt zurückgegeben wurden.
+ `CacheParameterGroupName` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `ApplyImmediately`Legen Sie `true` fest, um die Skalierung sofort auszuführen. Wenn Sie die Skalierung für das nächste Wartungsfenster des Clusters planen möchten, verwenden Sie `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&ApplyImmediately=true
&CacheClusterId=MyRedisCacheCluster
&CacheNodeType=cache.m3.xlarge
&CacheParameterGroupName redis32-m2-xl
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) in der *Amazon ElastiCache API-Referenz*.
1. Falls Sie dies verwendet haben `ApplyImmediately``=true`, überprüfen Sie den Status des neuen Clusters mithilfe der ElastiCache `DescribeCacheClusters` API-Aktion mit dem folgenden Parameter. Wenn sich der Status auf *verfügbar* ändert, können Sie mit der Verwendung des neuen, größeren Clusters beginnen.
+ `CacheClusterId`— Der Name Ihres Valkey- oder Redis OSS-Clusters mit einem Knoten. Verwenden Sie diesen Parameter, um einen bestimmten Cluster und nicht alle Cluster zu beschreiben.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) in der *Amazon ElastiCache API-Referenz*.
### Herunterskalierung von Valkey- oder Redis OSS-Clustern mit einem Knoten
In den folgenden Abschnitten erfahren Sie, wie Sie einen Valkey- oder Redis OSS-Cluster mit einem Knoten auf einen kleineren Knotentyp herunterskalieren können. Es ist wichtig für den langfristigen Erfolg Ihres neuen Valkey- oder Redis OSS-Clusters sicherzustellen, dass der neue, kleinere Knotentyp groß genug ist, um alle Daten und den OSS-Overhead von Valkey oder Redis aufzunehmen. Weitere Informationen finden Sie unter [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md).
**Anmerkung**
Bei Clustern, auf denen der R6gd-Knotentyp ausgeführt wird, können Sie nur auf Knotengrößen innerhalb der R6gd-Knotenfamilie skalieren.
**Topics**
+ [Herunterskalierung eines Valkey- oder Redis OSS-Clusters mit einem Knoten (Konsole)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [Herunterskalierung der Valkey- oder Redis OSS-Cluster mit einem Knoten ()AWS CLI](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [Herunterskalierung der Valkey- oder Redis OSS-Cluster (API) mit einem Knoten ElastiCache](#Scaling.RedisStandalone.ScaleDown.API)
#### Herunterskalierung eines Valkey- oder Redis OSS-Clusters mit einem Knoten (Konsole)
Das folgende Verfahren führt Sie durch die Skalierung Ihres Valkey- oder Redis OSS-Clusters mit einem Knoten auf einen kleineren Knotentyp mithilfe der Konsole. ElastiCache
**Wichtig**
Wenn Ihre Parametergruppe Speicher für Valkey- oder Redis-OSS-Overhead reserviert, stellen Sie vor Beginn der Skalierung sicher, dass Sie über eine benutzerdefinierte Parametergruppe verfügen, die die richtige Speichermenge für Ihren neuen Knotentyp reserviert. `reserved-memory` Alternativ können Sie eine benutzerdefinierte Parametergruppe anpassen, die `reserved-memory-percent` verwendet, und diese Parametergruppe für Ihren neuen Cluster verwenden.
Wenn Sie `reserved-memory-percent` verwenden, ist dies nicht erforderlich.
Weitere Informationen finden Sie unter [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md).
**Um Ihren Valkey- oder Redis OSS-Cluster (Konsole) mit einem Knoten zu verkleinern**
1. Vergewissern Sie sich, dass der Speicher des kleineren Knotentyps für Ihre Daten und den Overhead ausreicht.
1. Wenn Ihre Parametergruppe Speicher für Valkey- oder Redis-OSS-Overhead reserviert, stellen Sie sicher, dass Sie über eine benutzerdefinierte Parametergruppe verfügen, um die richtige Speichermenge für Ihren neuen Knotentyp bereitzustellen. `reserved-memory`
Alternativ können Sie eine benutzerdefinierte Parametergruppe für die Verwendung von `reserved-memory-percent` anpassen. Weitere Informationen finden Sie unter [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md).
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie aus der Liste der Cluster den Cluster aus, den Sie nach unten skalieren möchten. Auf diesem Cluster muss die Valkey- oder Redis OSS-Engine ausgeführt werden und nicht die geclusterte Valkey- oder Redis OSS-Engine.
1. Wählen Sie **Ändern** aus.
1. Gehen Sie im **Modify Cluster**-Assistenten wie folgt vor:
1. Wählen Sie in der Liste **Node type (Knotentyp)** den Knotentyp aus, auf den Sie herunterskalieren möchten.
1. Wenn Sie zur Speicherverwaltung `reserved-memory` verwenden, wählen Sie in der Liste **Parameter Group** die benutzerdefinierte Parametergruppe aus, die die korrekte Speichermenge für den neuen Knotentyp reserviert.
1. Wenn Sie die Skalierung nach unten sofort starten möchten, aktivieren Sie das Kontrollkästchen **Apply immediately (Sofort anwenden)**. Wenn Sie das Kontrollkästchen für **Apply immediately (Sofort anwenden)** nicht aktivieren, wird die Skalierung nach unten während des nächsten Wartungsfensters des Clusters durchgeführt.
1. Wählen Sie **Ändern** aus.
1. Wenn der Status des Clusters von *modifying* zu *available* wechselt, wurde die Skalierung auf den neuen Knotentyp erfolgreich abgeschlossen. Die Endpunkte müssen nicht in der Anwendung aktualisiert werden.
#### Herunterskalierung der Valkey- oder Redis OSS-Cluster mit einem Knoten ()AWS CLI
Das folgende Verfahren beschreibt, wie Sie einen Valkey- oder Redis-OSS-Cluster mit einem Knoten mithilfe von herunterskalieren.AWS CLI
**So verkleinern Sie einen Valkey- oder Redis OSS-Cluster mit einem Knoten ()AWS CLI**
1. Ermitteln Sie die Knotentypen, auf die Sie herunterskalieren können, indem Sie den AWS CLI`list-allowed-node-type-modifications` Befehl mit dem folgenden Parameter ausführen.
+ `--cache-cluster-id`
Für Linux, macOS oder Unix:
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Für Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small ",
],
}
```
Weitere Informationen finden Sie unter [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in der *AWS CLI-Referenz*.
1. Ändern Sie Ihren vorhandenen Cluster, indem Sie den Cluster, der herunterskaliert werden soll, und den neuen, kleineren Knotentyp angeben. Verwenden Sie dazu den AWS CLI`modify-cache-cluster` Befehl und die folgenden Parameter.
+ `--cache-cluster-id`— Der Name des Clusters, den Sie herunterskalieren.
+ `--cache-node-type`— Der neue Knotentyp, für den Sie den Cluster skalieren möchten. Der Wert muss einer der Knotentypen sein, die in Schritt 1 mit dem Befehl `list-allowed-node-type-modifications` zurückgegeben wurden.
+ `--cache-parameter-group-name` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `--apply-immediately` – Bewirkt, dass der Verkleinerungsprozess sofort angewendet wird. Wenn Sie die Skalierung für das nächste Wartungsfenster des Clusters planen möchten, verwenden Sie den Parameter `--no-apply-immediately`.
Für Linux, macOS oder Unix:
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cache-cluster \
--cache-node-type cache.m3.xlarge \
--cache-parameter-group-name redis32-m2-xl \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-cache-cluster ^
--cache-cluster-id my-redis-cache-cluster ^
--cache-node-type cache.m3.xlarge ^
--cache-parameter-group-name redis32-m2-xl ^
--apply-immediately
```
Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format).
```
{
"CacheCluster": {
"Engine": "redis",
"CacheParameterGroup": {
"CacheNodeIdsToReboot": [],
"CacheParameterGroupName": "default.redis6,x",
"ParameterApplyStatus": "in-sync"
},
"SnapshotRetentionLimit": 1,
"CacheClusterId": "my-redis-cache-cluster",
"CacheSecurityGroups": [],
"NumCacheNodes": 1,
"SnapshotWindow": "00:00-01:00",
"CacheClusterCreateTime": "2017-02-21T22:34:09.645Z",
"AutoMinorVersionUpgrade": true,
"CacheClusterStatus": "modifying",
"PreferredAvailabilityZone": "us-west-2a",
"ClientDownloadLandingPage": "https://console.aws.amazon.com/elasticache/home#client-download:",
"CacheSubnetGroupName": "default",
"EngineVersion": "6.0",
"PendingModifiedValues": {
"CacheNodeType": "cache.m3.2xlarge"
},
"PreferredMaintenanceWindow": "tue:11:30-tue:12:30",
"CacheNodeType": "cache.m3.medium",
"DataTiering": "disabled"
}
}
```
Weitere Informationen finden Sie unter [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) in der *AWS CLI-Referenz*.
1. Wenn Sie den verwendet haben`--apply-immediately`, überprüfen Sie den Status des neuen Clusters mithilfe des AWS CLI`describe-cache-clusters` Befehls mit dem folgenden Parameter. Wenn sich der Status auf *verfügbar* ändert, können Sie mit der Verwendung des neuen, größeren Clusters beginnen.
+ `--cache-cluster-id`— Der Name Ihres Valkey- oder Redis OSS-Clusters mit einem Knoten. Verwenden Sie diesen Parameter, um einen bestimmten Cluster und nicht alle Cluster zu beschreiben.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
Weitere Informationen finden Sie unter [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) in der *AWS CLI-Referenz*.
#### Herunterskalierung der Valkey- oder Redis OSS-Cluster (API) mit einem Knoten ElastiCache
Das folgende Verfahren beschreibt, wie ein Valkey- oder Redis-OSS-Cluster mit einem Knoten mithilfe der API nach oben und unten skaliert wird. ElastiCache
**So verkleinern Sie einen Valkey- oder Redis OSS-Cluster (API) mit einem Knoten ElastiCache**
1. Ermitteln Sie die Knotentypen, auf die Sie herunterskalieren können, indem Sie die ElastiCache `ListAllowedNodeTypeModifications` API-Aktion mit dem folgenden Parameter ausführen.
+ `CacheClusterId`— Der Name des Valkey- oder Redis-OSS-Clusters mit einem Knoten, den Sie herunterskalieren möchten.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in der *Amazon ElastiCache API-Referenz*.
1. Ändern Sie Ihren vorhandenen Cluster und geben Sie den zu skalierenden Cluster und den neuen, größeren Knotentyp an. Verwenden Sie dazu die `ModifyCacheCluster` ElastiCache API-Aktion und die folgenden Parameter.
+ `CacheClusterId`— Der Name des Clusters, den Sie herunterskalieren.
+ `CacheNodeType`— Der neue, kleinere Knotentyp, auf den Sie den Cluster herunterskalieren möchten. Dieser Wert muss einer der Knotentypen sein, die von der `ListAllowedNodeTypeModifications` Aktion im vorherigen Schritt zurückgegeben wurden.
+ `CacheParameterGroupName` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `ApplyImmediately` – Legen Sie `true` fest, um die Skalierung sofort auszuführen. Wenn Sie die Skalierung für das nächste Wartungsfenster des Clusters planen möchten, verwenden Sie `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyCacheCluster
&ApplyImmediately=true
&CacheClusterId=MyRedisCacheCluster
&CacheNodeType=cache.m3.xlarge
&CacheParameterGroupName redis32-m2-xl
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) in der *Amazon ElastiCache API-Referenz*.
1. Falls Sie dies verwendet haben `ApplyImmediately``=true`, überprüfen Sie den Status des neuen Clusters mithilfe der ElastiCache `DescribeCacheClusters` API-Aktion mit dem folgenden Parameter. Wenn sich der Status auf *verfügbar* ändert, können Sie mit der Verwendung des neuen, kleineren Clusters beginnen.
+ `CacheClusterId`— Der Name Ihres Valkey- oder Redis OSS-Clusters mit einem Knoten. Verwenden Sie diesen Parameter, um einen bestimmten Cluster und nicht alle Cluster zu beschreiben.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) in der *Amazon ElastiCache API-Referenz*.
# Skalierung von Replikatknoten für Valkey oder Redis OSS (Clustermodus deaktiviert)
Ein Valkey- oder Redis-OSS-Cluster mit Replikatknoten (in der API/CLI als *Replikationsgruppe* bezeichnet) bietet Hochverfügbarkeit über eine Replikation, bei der Multi-AZ mit aktiviertem automatischem Failover aktiviert ist. Ein Cluster mit Replikatknoten ist eine logische Sammlung von bis zu sechs Valkey- oder Redis-OSS-Knoten, wobei ein Knoten, der primäre, sowohl Lese- als auch Schreibanforderungen bearbeiten kann. Alle anderen Knoten im Cluster sind reine Read Replicas des primären Clusters. Daten, die im primären Cluster geschrieben werden, werden asynchron auf die Read Replicas im Cluster repliziert. Da Valkey oder Redis OSS (Clustermodus deaktiviert) die Partitionierung Ihrer Daten auf mehrere Cluster nicht unterstützen, enthält jeder Knoten in einer Valkey- oder Redis OSS-Replikationsgruppe (Clustermodus deaktiviert) den gesamten Cache-Datensatz. Valkey- oder Redis OSS-Cluster (Cluster-Modus aktiviert) unterstützen die Partitionierung Ihrer Daten auf bis zu 500 Shards.
Um die Datenkapazität Ihres Clusters zu ändern, müssen Sie es auf einen größeren Knotentyp hoch- oder auf einen kleineren Knotentyp herabskalieren.
Um die Lesekapazität Ihres Clusters zu ändern, fügen Sie bis auf maximal 5 weitere Lesereplikate hinzu oder entfernen Sie Lesereplikate.
Der ElastiCache Skalierungsprozess ist darauf ausgelegt, Ihre vorhandenen Daten bestmöglich beizubehalten, und erfordert eine erfolgreiche Valkey- oder Redis-OSS-Replikation. Für Valkey- oder Redis OSS-Cluster mit Replikaten empfehlen wir, Valkey oder Redis OSS ausreichend Speicher zur Verfügung zu stellen.
**Topics**
+ [Skalierung von Valkey- oder Redis OSS-Clustern mit Replikaten](#Scaling.RedisReplGrps.ScaleUp)
+ [Herunterskalierung von Valkey- oder Redis OSS-Clustern mit Replikaten](#Scaling.RedisReplGrps.ScaleDown)
+ [Erhöhen der Lesekapazität](#Scaling.RedisReplGrps.ScaleOut)
+ [Verringern der Lesekapazität](#Scaling.RedisReplGrps.ScaleIn)
**Verwandte Themen**
+ [Hohe Verfügbarkeit mit Replikationsgruppen](Replication.md)
+ [Replikation: Valkey- und Redis OSS-Clustermodus deaktiviert oder aktiviert](Replication.Redis-RedisCluster.md)
+ [Minimierung von Ausfallzeiten durch die Verwendung ElastiCache von Multi-AZ mit Valkey und Redis OSS](AutoFailover.md)
+ [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md)
**Topics**
+ [Skalierung von Valkey- oder Redis OSS-Clustern mit Replikaten](#Scaling.RedisReplGrps.ScaleUp)
+ [Herunterskalierung von Valkey- oder Redis OSS-Clustern mit Replikaten](#Scaling.RedisReplGrps.ScaleDown)
+ [Erhöhen der Lesekapazität](#Scaling.RedisReplGrps.ScaleOut)
+ [Verringern der Lesekapazität](#Scaling.RedisReplGrps.ScaleIn)
## Skalierung von Valkey- oder Redis OSS-Clustern mit Replikaten
Amazon ElastiCache bietet Konsolen-, CLI- und API-Unterstützung für die Skalierung Ihrer Valkey- oder Redis OSS-Replikationsgruppe (Cluster-Modus deaktiviert).
Wenn der Scale-Up-Prozess eingeleitet wird, ElastiCache geht Folgendes vor:
1. Es wird eine Replikationsgruppe unter Verwendung des neuen Knotentyps gestartet.
1. Alle Daten aus dem derzeitigen primären Knoten werden in den neuen primären Knoten kopiert.
1. Die neuen Read Replicas werden mit dem neuen primären Knoten synchronisiert.
1. Die DNS-Einträge werden aktualisiert und verweisen nun auf die neuen Knoten. Daher müssen Sie die Endpunkte in Ihrer Anwendung nicht aktualisieren. Für Valkey 7.2 und höher oder Redis OSS 5.0.5 und höher können Sie Cluster mit auto Failover skalieren, während der Cluster weiterhin online bleibt und eingehende Anfragen bearbeitet. Bei Redis OSS Version 4.0.10 und niedriger stellen Sie möglicherweise eine kurze Unterbrechung der Lese- und Schreibvorgänge auf früheren Versionen vom Primärknoten aus fest, während der DNS-Eintrag aktualisiert wird.
1. Die alten Knoten (CLI/API: Replikationsgruppe) werden gelöscht. Sie werden eine kurze Unterbrechung (ein paar Sekunden) der Lese- und Schreiboperationen der alten Knoten feststellen, da die Verbindungen zu den alten Knoten getrennt werden.
Die Dauer dieses Prozess ist abhängig vom Knotentyp und der Datenmenge im Cluster.
Wie in der folgenden Tabelle dargestellt, ist Ihr Valkey- oder Redis OSS-Scale-up-Vorgang blockiert, wenn Sie ein Engine-Upgrade für das nächste Wartungsfenster des Clusters geplant haben.
**Blockierte Valkey- oder Redis OSS-Operationen**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonElastiCache/latest/dg/Scaling.RedisReplGrps.html)
Wenn Sie durch ausstehende Operationen blockiert werden, haben Sie folgende Möglichkeiten.
+ Planen Sie Ihren Valkey- oder Redis OSS-Scale-up-Vorgang für das nächste Wartungsfenster, indem Sie das Kontrollkästchen **Sofort anwenden** deaktivieren (CLI use:`--no-apply-immediately`, API use:). `ApplyImmediately=false`
+ Warten Sie bis zu Ihrem nächsten Wartungsfenster (oder danach), um Ihren Valkey- oder Redis OSS-Scale-up-Vorgang durchzuführen.
+ Fügen Sie das Valkey- oder Redis OSS-Engine-Upgrade zu dieser Cluster-Änderung hinzu, wobei das Kontrollkästchen **Sofort anwenden** aktiviert ist (CLI use:`--apply-immediately`, API use:`ApplyImmediately=true`). Dadurch wird die Skalierung freigegeben, da das Engine-Upgrade sofort ausgeführt wird.
In den folgenden Abschnitten wird beschrieben, wie Sie Ihren Valkey- oder Redis-OSS-Cluster mithilfe der ElastiCache Konsole, der und der API skalieren, wobei Replikate aktiviert werden.AWS CLI ElastiCache
**Wichtig**
Wenn Ihre Parametergruppe Speicher für `reserved-memory` den Valkey- oder Redis-OSS-Overhead reserviert, stellen Sie vor Beginn der Skalierung sicher, dass Sie über eine benutzerdefinierte Parametergruppe verfügen, die die richtige Speichermenge für Ihren neuen Knotentyp reserviert. Alternativ können Sie eine benutzerdefinierte Parametergruppe anpassen, die `reserved-memory-percent` verwendet, und diese Parametergruppe für Ihren neuen Cluster verwenden.
Wenn Sie `reserved-memory-percent` verwenden, ist dies nicht erforderlich.
Weitere Informationen finden Sie unter [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md).
### Skalierung eines Valkey- oder Redis OSS-Clusters mit Replikaten (Konsole)
Wie lange die Aufwärtsskalierung auf einen größeren Knotentyp dauert, hängt vom Knotentyp und der Datenmenge in Ihrem derzeitigen Cluster ab.
Der folgende Prozess skaliert Ihren Cluster mit Replikaten mithilfe der Konsole vom aktuellen Knotentyp auf einen neuen, größeren Knotentyp. ElastiCache Während dieses Vorgangs kann für andere Versionen eine kurze Unterbrechung der Lese- und Schreibvorgänge vom Primärknoten auftreten, während der DNS-Eintrag aktualisiert wird. Für Knoten, die auf 5.0.6-Versionen ausgeführt werden, tritt möglicherweise eine Ausfallzeit unter 1 Sekunde und bei älteren Versionen von wenigen Sekunden auf.
**So skalieren Sie den Valkey- oder Redis OSS-Cluster mit Replikaten (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Valkey-Cluster** oder **Redis** OSS-Cluster aus
1. Wählen Sie aus der Liste der Cluster den Cluster aus, den Sie skalieren möchten. Auf diesem Cluster muss die Valkey- oder Redis OSS-Engine ausgeführt werden und nicht die geclusterte Valkey- oder Redis OSS-Engine.
1. Wählen Sie **Ändern** aus.
1. Gehen Sie im **Modify Cluster**-Assistenten wie folgt vor:
1. Wählen Sie in der Liste **Node type** den Knotentyp aus, auf den Sie skalieren möchten. Beachten Sie, dass nicht alle Knotentypen für das Herunterskalieren zur Verfügung stehen.
1. Wenn Sie zur Speicherverwaltung `reserved-memory` verwenden, wählen Sie in der Liste **Parameter Group** die benutzerdefinierte Parametergruppe aus, die die korrekte Speichermenge für den neuen Knotentyp reserviert.
1. Wenn Sie die Skalierung sofort starten möchten, aktivieren Sie das Kontrollkästchen **Apply immediately**. Wenn Sie das Kontrollkästchen für **Apply immediately** nicht aktivieren, wird die Skalierung während des nächsten Wartungsfensters des Clusters durchgeführt.
1. Wählen Sie **Ändern** aus.
1. Wenn der Status des Clusters von *modifying* zu *available* wechselt, wurde die Skalierung auf den neuen Knotentyp erfolgreich abgeschlossen. Die Endpunkte müssen nicht in der Anwendung aktualisiert werden.
### Skalierung einer Valkey- oder Redis OSS-Replikationsgruppe ()AWS CLI
Im nachfolgenden Verfahren wird eine Replikationsgruppe mithilfe der AWS CLI vom derzeitigen Knotentyp auf einen neuen, größeren Knotentyp skaliert. Während dieses Vorgangs werden die DNS-Einträge ElastiCache aktualisiert, sodass sie auf die neuen Knoten verweisen. Daher müssen Sie die Endpunkte in Ihrer Anwendung nicht aktualisieren. Für Valkey 7.2 und höher oder Redis OSS 5.0.5 und höher können Sie Cluster mit auto Failover skalieren, während der Cluster weiterhin online bleibt und eingehende Anfragen bearbeitet. Bei Version 4.0.10 und niedriger stellen Sie bei vorherigen Versionen möglicherweise eine kurze Unterbrechung der Lese- und Schreibvorgänge vom Primärknoten fest, während der DNS-Eintrag aktualisiert wird.
Die Zeit, die für die Skalierung auf einen größeren Knotentyp benötigt wird, hängt von Ihrem Knotentyp und der Datenmenge in Ihrem aktuellen Cluster ab.
**So skalieren Sie eine Valkey- oder Redis OSS-Replikationsgruppe ()AWS CLI**
1. Ermitteln Sie, auf welche Knotentypen Sie skalieren können, indem Sie den AWS CLI`list-allowed-node-type-modifications` Befehl mit dem folgenden Parameter ausführen.
+ `--replication-group-id` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
Für Linux, macOS oder Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Für Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
Die Ausgabe dieser Operation sollte etwa wie nachfolgend dargestellt aussehen (JSON-Format).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
}
```
Weitere Informationen finden Sie unter [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in der *AWS CLI-Referenz*.
1. Skalieren Sie Ihre aktuelle Replikationsgruppe mithilfe des AWS CLI`modify-replication-group` Befehls mit den folgenden Parametern auf den neuen Knotentyp.
+ `--replication-group-id` der Name der Replikationsgruppe.
+ `--cache-node-type`— der neue, größere Knotentyp der Cluster in dieser Replikationsgruppe. Dieser Wert muss einer der Instance-Typen sein, die vom `list-allowed-node-type-modifications` Befehl im vorherigen Schritt zurückgegeben wurden.
+ `--cache-parameter-group-name` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `--apply-immediately` – Führt die Skalierung sofort aus. Wenn Sie die Skalierung für das nächste Wartungsfenster planen möchten, verwenden Sie `--no-apply-immediately`.
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group \
--replication-group-id my-repl-group \
--cache-node-type cache.m3.xlarge \
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id my-repl-group ^
--cache-node-type cache.m3.xlarge ^
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Die Ausgabe dieses Befehls sollte etwa wie nachfolgend dargestellt aussehen (JSON-Format).
```
{
"ReplicationGroup": {
"Status": "available",
"Description": "Some description",
"NodeGroups": [{
"Status": "available",
"NodeGroupMembers": [{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
}
}],
"ReplicationGroupId": "my-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "12:00-13:00",
"SnapshottingClusterId": "my-repl-group-002",
"MemberClusters": [
"my-repl-group-001",
"my-repl-group-002"
],
"PendingModifiedValues": {}
}
}
```
Weitere Informationen finden Sie unter [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) in der *AWS CLI-Referenz*.
1. Wenn Sie den `--apply-immediately` Parameter verwendet haben, überwachen Sie den Status der Replikationsgruppe mithilfe des AWS CLI`describe-replication-group` Befehls mit dem folgenden Parameter. Wenn der Status noch *wird geändert* lautet, tritt möglicherweise eine Ausfallzeit unter 1 Sekunde für Knoten auf, die auf 5.0.6-Versionen ausgeführt werden, und für ältere Versionen eine kurze Unterbrechung von Lese- und Schreibvorgängen vom Primärkonten, während der DNS-Eintrag aktualisiert wird.
+ `--replication-group-id` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
Für Linux, macOS oder Unix:
```
aws elasticache describe-replication-groups \
--replication-group-id my-replication-group
```
Für Windows:
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
Weitere Informationen finden Sie unter [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) in der *AWS CLI-Referenz*.
### Skalierung einer Valkey- oder Redis OSS-Replikationsgruppe (API) ElastiCache
Der folgende Prozess skaliert Ihre Replikationsgruppe mithilfe der API von ihrem aktuellen Knotentyp auf einen neuen, größeren Knotentyp. ElastiCache Für Valkey 7.2 und höher oder Redis OSS 5.0.5 und höher können Sie Cluster mit auto Failover skalieren, während der Cluster weiterhin online bleibt und eingehende Anfragen bearbeitet. Bei Version Redis OSS 4.0.10 und niedriger stellen Sie möglicherweise eine kurze Unterbrechung der Lese- und Schreibvorgänge auf früheren Versionen vom Primärknoten aus fest, während der DNS-Eintrag aktualisiert wird.
Die Zeit, die für die Skalierung auf einen größeren Knotentyp benötigt wird, hängt von Ihrem Knotentyp und der Datenmenge in Ihrem aktuellen Cluster ab.
**So skalieren Sie eine Valkey- oder Redis OSS-Replikationsgruppe (API) ElastiCache**
1. Ermitteln Sie mit dem folgenden Parameter, auf welche Knotentypen Sie mithilfe der ElastiCache `ListAllowedNodeTypeModifications` API-Aktion skalieren können.
+ `ReplicationGroupId` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in der *Amazon ElastiCache API-Referenz*.
1. Skalieren Sie Ihre aktuelle Replikationsgruppe mithilfe der `ModifyReplicationGroup` ElastiCache API-Aktion und mit den folgenden Parametern auf den neuen Knotentyp.
+ `ReplicationGroupId` der Name der Replikationsgruppe.
+ `CacheNodeType`— der neue, größere Knotentyp der Cluster in dieser Replikationsgruppe. Dieser Wert muss einer der Instanztypen sein, die von der `ListAllowedNodeTypeModifications` Aktion im vorherigen Schritt zurückgegeben wurden.
+ `CacheParameterGroupName` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `ApplyImmediately`Legen Sie `true` fest, um die Skalierung sofort auszuführen. Wenn Sie die Skalierung für das nächste Wartungsfenster planen möchten, verwenden Sie `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Weitere Informationen finden Sie [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) in der *Amazon ElastiCache API-Referenz*.
1. Falls Sie dies verwendet haben `ApplyImmediately``=true`, überwachen Sie den Status der Replikationsgruppe mithilfe der ElastiCache `DescribeReplicationGroups` API-Aktion mit den folgenden Parametern. Wenn der Status von *modifying* zu *available* wechselt, können Sie die neue, aufskalierte Replikationsgruppe verwenden.
+ `ReplicationGroupId` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) in der *Amazon ElastiCache API-Referenz*.
## Herunterskalierung von Valkey- oder Redis OSS-Clustern mit Replikaten
In den folgenden Abschnitten erfahren Sie, wie Sie einen Valkey- oder Redis OSS-Cluster (Clustermodus deaktiviert) mit Replikatknoten auf einen kleineren Knotentyp herunterskalieren. Es ist für den Erfolg wichtig sicherzustellen, dass der neue, kleinere Knotentyp für die Datenmenge und den Overhead ausreicht. Weitere Informationen finden Sie unter [Stellen Sie sicher, dass Sie über genügend Arbeitsspeicher verfügen, um einen Valkey- oder Redis OSS-Snapshot zu erstellen](BestPractices.BGSAVE.md).
**Anmerkung**
Bei Clustern, auf denen der R6gd-Knotentyp ausgeführt wird, können Sie nur auf Knotengrößen innerhalb der R6gd-Knotenfamilie skalieren.
**Wichtig**
Wenn Ihre Parametergruppe Speicher für Valkey- oder Redis OSS-Overhead reserviert, stellen Sie vor Beginn der Skalierung sicher, dass Sie über eine benutzerdefinierte Parametergruppe verfügen, die die richtige Speichermenge für Ihren neuen Knotentyp reserviert. `reserved-memory` Alternativ können Sie eine benutzerdefinierte Parametergruppe anpassen, die `reserved-memory-percent` verwendet, und diese Parametergruppe für Ihren neuen Cluster verwenden.
Wenn Sie `reserved-memory-percent` verwenden, ist dies nicht erforderlich.
Weitere Informationen finden Sie unter [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md).
**Topics**
### Herunterskalierung eines Valkey- oder Redis OSS-Clusters mit Replikaten (Konsole)
Der folgende Prozess skaliert Ihren Valkey- oder Redis OSS-Cluster mit Replikatknoten mithilfe der Konsole auf einen kleineren Knotentyp. ElastiCache
**So verkleinern Sie einen Valkey- oder Redis OSS-Cluster mit Replikatknoten (Konsole)**
1. Vergewissern Sie sich, dass der Speicher des kleineren Knotentyps für Ihre Daten und den Overhead ausreicht.
1. Wenn Ihre Parametergruppe Speicher für Valkey- oder Redis-OSS-Overhead reserviert, stellen Sie sicher, dass Sie über eine benutzerdefinierte Parametergruppe verfügen, um die richtige Speichermenge für Ihren neuen Knotentyp bereitzustellen. `reserved-memory`
Alternativ können Sie eine benutzerdefinierte Parametergruppe für die Verwendung von `reserved-memory-percent` anpassen. Weitere Informationen finden Sie unter [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md).
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie aus der Liste der Cluster den Cluster aus, den Sie nach unten skalieren möchten. Auf diesem Cluster muss die Valkey- oder Redis OSS-Engine ausgeführt werden und nicht die geclusterte Valkey- oder Redis OSS-Engine.
1. Wählen Sie **Ändern** aus.
1. Gehen Sie im **Modify Cluster**-Assistenten wie folgt vor:
1. Wählen Sie in der Liste **Node type (Knotentyp)** den Knotentyp aus, auf den Sie herunterskalieren möchten.
1. Wenn Sie zur Speicherverwaltung `reserved-memory` verwenden, wählen Sie in der Liste **Parameter Group** die benutzerdefinierte Parametergruppe aus, die die korrekte Speichermenge für den neuen Knotentyp reserviert.
1. Wenn Sie die Skalierung nach unten sofort starten möchten, aktivieren Sie das Kontrollkästchen **Apply immediately (Sofort anwenden)**. Wenn Sie das Kontrollkästchen für **Apply immediately (Sofort anwenden)** nicht aktivieren, wird die Skalierung nach unten während des nächsten Wartungsfensters des Clusters durchgeführt.
1. Wählen Sie **Ändern** aus.
1. Wenn der Status des Clusters von *modifying* zu *available* wechselt, wurde die Skalierung auf den neuen Knotentyp erfolgreich abgeschlossen. Die Endpunkte müssen nicht in der Anwendung aktualisiert werden.
### Herunterskalierung einer Valkey- oder Redis OSS-Replikationsgruppe ()AWS CLI
Im nachfolgenden Verfahren wird eine Replikationsgruppe mithilfe der AWS CLI vom derzeitigen Knotentyp auf einen neuen, kleineren Knotentyp skaliert. Während dieses Vorgangs werden die DNS-Einträge ElastiCache aktualisiert, sodass sie auf die neuen Knoten verweisen. Daher müssen Sie die Endpunkte in Ihrer Anwendung nicht aktualisieren. Für Valkey 7.2 und höher oder Redis OSS 5.0.5 und höher können Sie Cluster mit auto Failover skalieren, während der Cluster weiterhin online bleibt und eingehende Anfragen bearbeitet. Bei Version 4.0.10 und niedriger stellen Sie bei vorherigen Versionen möglicherweise eine kurze Unterbrechung der Lese- und Schreibvorgänge vom Primärknoten fest, während der DNS-Eintrag aktualisiert wird.
Die Lesevorgänge aus den Read Replica-Clustern werden jedoch ohne Unterbrechung fortgesetzt.
Die Zeit, die benötigt wird, um auf einen kleineren Knotentyp herunterzuskalieren, hängt von Ihrem Knotentyp und der Datenmenge in Ihrem aktuellen Cluster ab.
**So verkleinern Sie eine Valkey- oder Redis OSS-Replikationsgruppe ()AWS CLI**
1. Ermitteln Sie, auf welche Knotentypen Sie herunterskalieren können, indem Sie den AWS CLI`list-allowed-node-type-modifications` Befehl mit dem folgenden Parameter ausführen.
+ `--replication-group-id` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
Für Linux, macOS oder Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Für Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
Die Ausgabe dieser Operation sollte etwa wie nachfolgend dargestellt aussehen (JSON-Format).
```
{
"ScaleDownModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
}
```
Weitere Informationen finden Sie unter [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in der *AWS CLI-Referenz*.
1. Skalieren Sie Ihre aktuelle Replikationsgruppe mithilfe des AWS CLI`modify-replication-group` Befehls mit den folgenden Parametern auf den neuen Knotentyp.
+ `--replication-group-id` der Name der Replikationsgruppe.
+ `--cache-node-type`— der neue, kleinere Knotentyp der Cluster in dieser Replikationsgruppe. Dieser Wert muss einer der Instance-Typen sein, die vom `list-allowed-node-type-modifications` Befehl im vorherigen Schritt zurückgegeben wurden.
+ `--cache-parameter-group-name` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `--apply-immediately` – Führt die Skalierung sofort aus. Wenn Sie die Skalierung für das nächste Wartungsfenster planen möchten, verwenden Sie `--no-apply-immediately`.
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group \
--replication-group-id my-repl-group \
--cache-node-type cache.t2.small \
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id my-repl-group ^
--cache-node-type cache.t2.small ^
--cache-parameter-group-name redis32-m3-2xl \
--apply-immediately
```
Die Ausgabe dieses Befehls sollte etwa wie nachfolgend dargestellt aussehen (JSON-Format).
```
{"ReplicationGroup": {
"Status": "available",
"Description": "Some description",
"NodeGroups": [
{
"Status": "available",
"NodeGroupMembers": [
{
"CurrentRole": "primary",
"PreferredAvailabilityZone": "us-west-2b",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-001.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-001"
},
{
"CurrentRole": "replica",
"PreferredAvailabilityZone": "us-west-2c",
"CacheNodeId": "0001",
"ReadEndpoint": {
"Port": 6379,
"Address": "my-repl-group-002.8fdx4s.0001.usw2.cache.amazonaws.com"
},
"CacheClusterId": "my-repl-group-002"
}
],
"NodeGroupId": "0001",
"PrimaryEndpoint": {
"Port": 6379,
"Address": "my-repl-group.8fdx4s.ng.0001.usw2.cache.amazonaws.com"
}
}
],
"ReplicationGroupId": "my-repl-group",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "disabled",
"SnapshotWindow": "12:00-13:00",
"SnapshottingClusterId": "my-repl-group-002",
"MemberClusters": [
"my-repl-group-001",
"my-repl-group-002",
],
"PendingModifiedValues": {}
}
}
```
Weitere Informationen finden Sie unter [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) in der *AWS CLI-Referenz*.
1. Wenn Sie den `--apply-immediately` Parameter verwendet haben, überwachen Sie den Status der Replikationsgruppe mithilfe des AWS CLI`describe-replication-group` Befehls mit dem folgenden Parameter. Wenn der Status von *In Bearbeitung* zu *Verfügbar* wechselt, können Sie die neue, abwärts skalierte Replikationsgruppe verwenden.
+ `--replication-group-id` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
Für Linux, macOS oder Unix:
```
aws elasticache describe-replication-group \
--replication-group-id my-replication-group
```
Für Windows:
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
Weitere Informationen finden Sie unter [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) in der *AWS CLI-Referenz*.
### Herunterskalierung einer Valkey- oder Redis OSS-Replikationsgruppe (API) ElastiCache
Der folgende Prozess skaliert Ihre Replikationsgruppe mithilfe der API von ihrem aktuellen Knotentyp auf einen neuen, kleineren Knotentyp. ElastiCache Während dieses Vorgangs werden die DNS-Einträge ElastiCache aktualisiert, sodass sie auf die neuen Knoten verweisen. Daher müssen Sie die Endpunkte in Ihrer Anwendung nicht aktualisieren. Für Valkey 7.2 und höher oder Redis OSS 5.0.5 und höher können Sie Cluster mit auto Failover skalieren, während der Cluster weiterhin online bleibt und eingehende Anfragen bearbeitet. Bei Redis OSS Version 4.0.10 und niedriger stellen Sie möglicherweise eine kurze Unterbrechung der Lese- und Schreibvorgänge auf früheren Versionen vom Primärknoten aus fest, während der DNS-Eintrag aktualisiert wird. Die Lesevorgänge aus den Read Replica-Clustern werden jedoch ohne Unterbrechung fortgesetzt.
Die Zeit, die benötigt wird, um auf einen kleineren Knotentyp herunterzuskalieren, hängt von Ihrem Knotentyp und der Datenmenge in Ihrem aktuellen Cluster ab.
**So verkleinern Sie eine Valkey- oder Redis OSS-Replikationsgruppe (API) ElastiCache**
1. Ermitteln Sie, auf welche Knotentypen Sie mithilfe der ElastiCache `ListAllowedNodeTypeModifications` API-Aktion mit dem folgenden Parameter herunterskalieren können.
+ `ReplicationGroupId` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in der *Amazon ElastiCache API-Referenz*.
1. Skalieren Sie Ihre aktuelle Replikationsgruppe mithilfe der `ModifyReplicationGroup` ElastiCache API-Aktion und mit den folgenden Parametern auf den neuen Knotentyp.
+ `ReplicationGroupId` der Name der Replikationsgruppe.
+ `CacheNodeType`— der neue, kleinere Knotentyp der Cluster in dieser Replikationsgruppe. Dieser Wert muss einer der Instance-Typen sein, die von der `ListAllowedNodeTypeModifications` Aktion im vorherigen Schritt zurückgegeben wurden.
+ `CacheParameterGroupName` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `ApplyImmediately`Legen Sie `true` fest, um die Skalierung sofort auszuführen. Wenn Sie die Abwärtsskalierung für das nächste Wartungsfenster planen möchten, verwenden Sie `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Weitere Informationen finden Sie [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) in der *Amazon ElastiCache API-Referenz*.
1. Falls Sie dies verwendet haben `ApplyImmediately``=true`, überwachen Sie den Status der Replikationsgruppe mithilfe der ElastiCache `DescribeReplicationGroups` API-Aktion mit den folgenden Parametern. Wenn der Status von *In Bearbeitung* zu *Verfügbar* wechselt, können Sie die neue, abwärts skalierte Replikationsgruppe verwenden.
+ `ReplicationGroupId` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) in der *Amazon ElastiCache API-Referenz*.
## Erhöhen der Lesekapazität
Um die Lesekapazität zu erhöhen, fügen Sie Read Replicas (bis zu maximal fünf) zu Ihrer Valkey- oder Redis OSS-Replikationsgruppe hinzu.
Sie können die Lesekapazität Ihres Valkey- oder Redis OSS-Clusters mithilfe der ElastiCache Konsole, der oder der API skalieren.AWS CLI ElastiCache Weitere Informationen finden Sie unter [Hinzufügen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert)](Replication.AddReadReplica.md).
## Verringern der Lesekapazität
Um die Lesekapazität zu verringern, löschen Sie eine oder mehrere Read Replicas aus Ihrem Valkey- oder Redis OSS-Cluster mit Replikaten (in der API/CLI als *Replikationsgruppe* bezeichnet). Wenn es sich bei dem Cluster um Multi-AZ mit aktiviertem automatischem Failover handelt, können Sie das letzte Read Replica nicht löschen, ohne zuvor Multi-AZ zu deaktivieren. Weitere Informationen finden Sie unter [Ändern einer Replikationsgruppe](Replication.Modify.md).
Weitere Informationen finden Sie unter [Löschen einer Read Replica für Valkey oder Redis OSS (Cluster-Modus deaktiviert)](Replication.RemoveReadReplica.md).
# Skalierung von Valkey- oder Redis OSS-Clustern (Clustermodus aktiviert)
Wenn sich die Nachfrage nach Ihren Clustern ändert, können Sie entscheiden, die Leistung zu verbessern oder die Kosten zu senken, indem Sie die Anzahl der Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) ändern. Wir empfehlen, dazu die horizontale Online-Skalierung zu verwenden, da Ihr Cluster während des Skalierungsprozesses weiterhin Anforderungen bedienen kann.
Zu den Bedingungen, unter denen Sie den Cluster möglicherweise neu skalieren, gehören folgende:
+ **Speicherbelastung**
Wenn die Knoten in Ihrem Cluster einer hohen Speicherbelastung ausgesetzt sind, können Sie sich für eine Skalierung entscheiden, sodass Sie über mehr Ressourcen verfügen, um Daten besser speichern und Anforderungen verarbeiten zu können.
Sie können feststellen, ob Ihre Knoten unter Speicherauslastung stehen, indem Sie die folgenden Messwerte überwachen: *FreeableMemory*, und *SwapUsage*. *BytesUsedForCache*
+ **CPU- oder Netzwerkengpässe:**
Wenn latency/throughput Probleme in Ihrem Cluster auftreten, müssen Sie möglicherweise eine Skalierung vornehmen, um die Probleme zu lösen.
Sie können Ihre Latenz und Ihren Durchsatz überwachen, indem Sie die folgenden Messwerte überwachen: *CPUUtilization*, *NetworkBytesIn*, *NetworkBytesOut*CurrConnections**, und. *NewConnections*
+ **Ihr Cluster ist übermäßig skaliert:**
Der aktuelle Bedarf an Ihrem Cluster ist so hoch, dass eine Skalierung die Leistung nicht beeinträchtigt und Ihre Kosten reduziert.
Sie können die Nutzung Ihres Clusters überwachen, um anhand der folgenden Metriken festzustellen, ob Sie sicher skalieren können oder nicht: *FreeableMemory*SwapUsage*BytesUsedForCache***, *CPUUtilization*, *NetworkBytesIn*, *NetworkBytesOut*, *CurrConnections*, und *NewConnections*.
**Leistungsbeeinträchtigung durch Skalierung**
Wenn Sie den Offline-Prozess skalieren, ist Ihr Cluster für einen erheblichen Teil des Prozesses offline und kann daher keine Anforderungen erfüllen. Wenn Sie mithilfe der Onlinemethode skalieren, da die Skalierung eine rechenintensive Operation ist, gibt es eine Leistungseinbuße. Ihr Cluster führt jedoch weiterhin während der Skalierungsoperation Anforderungen aus. Wie stark die Verschlechterung ist, hängt von Ihrer normalen CPU-Auslastung und Ihren Daten ab.
Es gibt zwei Möglichkeiten, Ihren Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) zu skalieren: horizontale und vertikale Skalierung.
+ Mit horizontaler Skalierung ändern Sie die Anzahl der Knotengruppen (Shards) in der Replikationsgruppe, indem Sie Knotengruppen hinzufügen oder entfernen. Der Online-Resharding-Prozess ermöglicht die Skalierung, in/out während der Cluster weiterhin eingehende Anfragen bearbeitet.
Konfigurieren Sie die Slots in Ihrem neuen Cluster anders als im alten Cluster. Nur Offline-Methode.
+ Vertikale Skalierung – Ändern Sie den Knotentyp, um die Größe des Clusters anzupassen. Die vertikale Online-Skalierung ermöglicht die Skalierung up/down , während der Cluster weiterhin eingehende Anfragen bearbeitet.
Wenn Sie die Größe und Speicherkapazität des Clusters reduzieren, indem Sie entweder ein- oder herunterskalieren, stellen Sie sicher, dass die neue Konfiguration über ausreichend Speicher für Ihre Daten und den OSS-Overhead von Valkey oder Redis verfügt.
Weitere Informationen finden Sie unter [Auswahl der Knotengröße](CacheNodes.SelectSize.md).
**Contents**
+ [Offline-Resharding für Valkey oder Redis OSS (Clustermodus aktiviert)](#redis-cluster-resharding-offline)
+ [Online-Resharding für Valkey oder Redis OSS (Clustermodus aktiviert)](#redis-cluster-resharding-online)
+ [Hinzufügen von Shards mit Online-Resharding](#redis-cluster-resharding-online-add)
+ [Entfernen von Shards mit Online-Resharding](#redis-cluster-resharding-online-remove)
+ [Entfernen von Shards (Konsole)](#redis-cluster-resharding-online-remove-console)
+ [Entfernen von Shards (AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [Shards entfernen (API) ElastiCache](#redis-cluster-resharding-online-remove-api)
+ [Online-Shard-Rebalancing](#redis-cluster-resharding-online-rebalance)
+ [Online-Shard-Rebalancing (Console)](#redis-cluster-resharding-online-rebalance-console)
+ [Online-Shard-Rebalancing (AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [Online-Shard-Rebalancing (API) ElastiCache](#redis-cluster-resharding-online-rebalance-api)
+ [Vertikales Online-Skalieren durch Ändern des Knotentyps](redis-cluster-vertical-scaling.md)
+ [Online-aufwärtsskalieren](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
+ [Skalierung von Valkey- oder Redis OSS-Clustern (Konsole)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-console)
+ [Skalierung von Valkey- oder Redis OSS-Clustern ()AWS CLI](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Skalierung von Valkey- oder Redis OSS-Clustern (API) ElastiCache](redis-cluster-vertical-scaling.md#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [Online-abwärtsskalieren](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-down)
+ [Herunterskalierung von Valkey- oder Redis OSS-Clustern (Konsole)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-down-console)
+ [Herunterskalieren von Valkey- oder Redis OSS-Clustern ()AWS CLI](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Herunterskalierung der Valkey- oder Redis OSS-Cluster (API) ElastiCache](redis-cluster-vertical-scaling.md#Scaling.Vertical.ScaleDown.API)
## Offline-Resharding für Valkey oder Redis OSS (Clustermodus aktiviert)
Der Hauptvorteil der Offline-Shard-Rekonfiguration besteht darin, dass Sie mehr als nur das Hinzufügen oder Entfernen von Shards aus Ihrer Replikationsgruppe tun können. Wenn Sie Resharding und Rebalancing offline durchführen, können Sie nicht nur die Anzahl der Shards in Ihrer Replikationsgruppe ändern, sondern auch Folgendes tun:
**Anmerkung**
Offline-Resharding wird auf Valkey- oder Redis-OSS-Clustern mit aktiviertem Data Tiering nicht unterstützt. Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
+ Ändern Sie den Knotentyp Ihrer Replikationsgruppe.
+ Geben Sie die Availability Zone für jeden Knoten in der Replikationsgruppe an.
+ Upgrade auf eine neuere Engine-Version.
+ Geben Sie die Anzahl der Replikatknoten in jeder Shard unabhängig voneinander an.
+ Geben Sie den Keyspace für jede Shard an.
Der Hauptnachteil der Offline-Shard-Neukonfiguration besteht darin, dass Ihr Cluster offline ist und mit dem Wiederherstellungsabschnitt des Prozesses beginnt und so lange fortfährt, bis Sie die Endpunkte in Ihrer Anwendung aktualisieren. Die Dauer, in der Ihr Cluster offline ist, hängt von der Datenmenge in Ihrem Cluster ab.
**Um Ihre Shards Valkey oder Redis OSS-Cluster (Clustermodus aktiviert) offline neu zu konfigurieren**
1. Erstellen Sie ein manuelles Backup Ihres vorhandenen Valkey- oder Redis OSS-Clusters. Weitere Informationen finden Sie unter [Erstellen manueller Backups](backups-manual.md).
1. Erstellen Sie einen neuen Cluster, indem Sie sie aus der Sicherung wiederherstellen. Weitere Informationen finden Sie unter [Wiederherstellen aus einem Backup in einen neuen Cache](backups-restoring.md).
1. Aktualisieren Sie in Ihrer Anwendung die Endpunkte auf die neuen Cluster-Endpunkte. Weitere Informationen finden Sie unter [Verbindungsendpunkte finden in ElastiCache](Endpoints.md).
## Online-Resharding für Valkey oder Redis OSS (Clustermodus aktiviert)
Mithilfe von Online-Resharding und Shard-Rebalancing mit ElastiCache Valkey 7.2 oder neuer oder Redis OSS Version 3.2.10 oder neuer können Sie Ihren Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) dynamisch und ohne Ausfallzeiten skalieren. Dieser Ansatz bedeutet, dass Ihr Cluster weiterhin Anfragen bearbeiten kann, selbst wenn die Skalierung oder das Rebalancing in Bearbeitung ist.
Sie haben die folgenden Möglichkeiten:
+ **Skalierung — Erhöhen Sie die Lese- und Schreibkapazität, indem Sie Ihrem Valkey- oder Redis OSS-Cluster** (Clustermodus aktiviert) (Replikationsgruppe) Shards (Knotengruppen) hinzufügen.
Wenn Sie Ihrer Replikationsgruppe einen oder mehrere Shards hinzufügen, entspricht die Anzahl der Knoten in jedem neuen Shard der Anzahl der Knoten in der kleinsten der vorhandenen Shards.
+ **Skalierung** — Reduzieren Sie die Lese- und Schreibkapazität und damit die Kosten, indem Sie Shards aus Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) entfernen.
+ **Rebalance** — Verschieben Sie die Keyspaces zwischen den Shards in Ihrem Valkey- oder Redis OSS-Cluster (Cluster-Modus aktiviert), sodass sie so gleichmäßig wie möglich auf die Shards verteilt sind.
Sie haben nicht die folgenden Möglichkeiten:
+ **Konfigurieren Sie Shards unabhängig:**
Sie können den Keyspace für Shards nicht unabhängig angeben. Um dies zu tun, müssen Sie den Offline-Prozess verwenden.
Derzeit gelten die folgenden Einschränkungen für Online-Resharding und Rebalancing: ElastiCache
+ Diese Prozesse erfordern Valkey 7.2 und neuer oder Redis OSS 3.2.10 oder neuer. Informationen zum Aktualisieren der Engine-Version finden Sie unter [Versionsverwaltung für ElastiCache](VersionManagement.md).
+ Es gibt Einschränkungen bei Slots oder Keyspaces und großen Elementen:
Wenn ein Schlüssel in einem Shard ein großes Element enthält, wird dieser Schlüssel beim horizontalen Skalieren oder Neuausrichten nicht in eine neue Shard migriert. Diese Funktionalität kann zu unsymmetrischen Shards führen.
Wenn einer der Schlüssel in einer Shard ein großes Element enthält (Elemente größer als 256 MB nach der Serialisierung), wird diese Shard beim Skalieren nicht gelöscht. Diese Funktionalität kann dazu führen, dass einige Shards nicht gelöscht werden.
+ Beim Ausskalieren entspricht die Anzahl der Knoten in neuen Shards der Anzahl der Knoten in der kleinsten vorhandenen Shard.
+ Beim Ausskalieren werden alle Tags, die allen vorhandenen Shards gemeinsam sind, in die neuen Shards kopiert.
+ Beim Skalieren eines Global Data Store-Clusters ElastiCache werden Funktionen nicht automatisch von einem der vorhandenen Knoten auf die neuen Knoten repliziert. Wir empfehlen, Ihre Funktionen nach der Aufskalierung Ihres Clusters in den (die) neuen Shard(s) zu laden, sodass alle Shards dieselben Funktionen aufweisen.
**Anmerkung**
ElastiCache Für Valkey 7.2 und höher und ElastiCache für Redis OSS Version 7 und höher: Wenn Sie Ihren Cluster skalieren, repliziert er ElastiCache automatisch die Funktionen, die in einem der vorhandenen Knoten geladen sind (zufällig ausgewählt), auf die neuen Knoten. Wenn Ihre Anwendung [Functions](https://valkey.io/topics/functions-intro/) verwendet, empfehlen wir, alle Ihre Funktionen vor dem Skalieren auf alle Shards zu laden, damit Ihr Cluster nicht mit unterschiedlichen Funktionsdefinitionen auf verschiedenen Shards endet.
Weitere Informationen finden Sie unter [Online-Größenanpassung von Clustern](best-practices-online-resharding.md).
Sie können Ihre Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mithilfe der API AWS-Managementkonsole, der und der API horizontal skalieren oder neu ausbalancieren AWS CLI. ElastiCache
### Hinzufügen von Shards mit Online-Resharding
Sie können Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mithilfe der API, oder Shards hinzufügen.AWS-ManagementkonsoleAWS CLI ElastiCache Wenn Sie Shards zu einem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) hinzufügen, werden alle Tags auf den vorhandenen Shards auf die neuen Shards kopiert.
**Topics**
#### Hinzufügen von Shards (Konsole)
Sie können den verwenden AWS-Managementkonsole, um Ihrem Valkey- oder Redis OSS-Cluster (Cluster-Modus aktiviert) einen oder mehrere Shards hinzuzufügen. Das folgende Verfahren beschreibt den Prozess.
**Um Shards zu Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) hinzuzufügen**
1. Öffnen Sie die Konsole unter ElastiCache . [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Valkey-Cluster** oder **Redis OSS-Cluster** aus.
1. Suchen Sie den Namen des Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert), dem Sie Shards hinzufügen möchten, und wählen Sie ihn aus, nicht das Feld links neben dem Clusternamen.
**Tipp**
****Valkey oder Redis OSS (Clustermodus aktiviert) zeigen **Clustered Valkey oder Clustered** Redis OSS in der Modus-Spalte****
1. Wählen Sie **Shard hinzufügen** aus.
1. Wählen Sie für **Anzahl der hinzuzufügenden Shards**die Anzahl der Shards, die Sie diesem Cluster hinzufügen möchten.
1. Für **Availability zone(s)**, entweder **No preference** oder **Specify availability zones** angeben.
1. Wenn Sie **Availability Zones angeben**für jeden Knoten angeben möchten, wählen Sie für jeden Knoten in jeder Shard die Availability Zone des Knotens aus der Liste der Availability Zones.
1. Wählen Sie **Hinzufügen** aus.
#### Shards hinzufügen (AWS CLI)
Der folgende Prozess beschreibt, wie Sie die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu konfigurieren, indem Sie Shards mit dem hinzufügen.AWS CLI
Verwenden Sie die folgenden Parameter mit `modify-replication-group-shard-configuration`.
**Parameters**
+ `--apply-immediately` – Erforderlich. Gibt an, dass die Shard-Rekonfigurationsoperation sofort gestartet werden soll.
+ `--replication-group-id` – Erforderlich. Gibt an, für welche Replikationsgruppe (Cluster) die Shard-Rekonfigurationsoperation ausgeführt werden soll.
+ `--node-group-count` – Erforderlich. Gibt die Anzahl der Shards (Knotengruppen) an, die nach Abschluss des Vorgangs vorhanden sein müssen. Beim Hinzufügen von Shards muss der Wert von `--node-group-count` größer als die aktuelle Anzahl von Shards sein.
Optional können Sie die Availability Zone für jeden Knoten in der Replikationsgruppe mit `--resharding-configuration` angeben.
+ `--resharding-configuration` – Optional. Eine Liste der bevorzugten Availability Zones für jeden Knoten in jedem Shard in der Replikationsgruppe. Verwenden Sie diesen Parameter nur, wenn der Wert von `--node-group-count` größer ist als die aktuelle Anzahl von Shards. Wenn dieser Parameter beim Hinzufügen von Shards weggelassen wird, ElastiCache wählt Amazon die Availability Zones für die neuen Knoten aus.
Im folgenden Beispiel werden die Keyspaces für vier Shards in einem Valkey- oder Redis OSS-Cluster (Cluster-Modus aktiviert) mit dem Namen neu konfiguriert. `my-cluster` Das Beispiel gibt auch die Availability Zone für jeden Knoten in jedem Shard an. Die Operation beginnt sofort.
**Example - Shards hinzufügen**
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 4 \
--resharding-configuration \
"PreferredAvailabilityZones=us-east-2a,us-east-2c" \
"PreferredAvailabilityZones=us-east-2b,us-east-2a" \
"PreferredAvailabilityZones=us-east-2c,us-east-2d" \
"PreferredAvailabilityZones=us-east-2d,us-east-2c" \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 4 ^
--resharding-configuration ^
"PreferredAvailabilityZones=us-east-2a,us-east-2c" ^
"PreferredAvailabilityZones=us-east-2b,us-east-2a" ^
"PreferredAvailabilityZones=us-east-2c,us-east-2d" ^
"PreferredAvailabilityZones=us-east-2d,us-east-2c" ^
--apply-immediately
```
[Weitere Informationen finden Sie unter -configuration in der Dokumentationmodify-replication-group-shard.](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html)AWS CLI
#### Hinzufügen von Shards (API) ElastiCache
Sie können die ElastiCache API verwenden, um die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) online neu zu konfigurieren, indem Sie den Vorgang verwenden. `ModifyReplicationGroupShardConfiguration`
Verwenden Sie die folgenden Parameter mit `ModifyReplicationGroupShardConfiguration`.
**Parameters**
+ `ApplyImmediately=true` – Erforderlich. Gibt an, dass die Shard-Rekonfigurationsoperation sofort gestartet werden soll.
+ `ReplicationGroupId` – Erforderlich. Gibt an, für welche Replikationsgruppe (Cluster) die Shard-Rekonfigurationsoperation ausgeführt werden soll.
+ `NodeGroupCount` – Erforderlich. Gibt die Anzahl der Shards (Knotengruppen) an, die nach Abschluss des Vorgangs vorhanden sein müssen. Beim Hinzufügen von Shards muss der Wert von `NodeGroupCount` größer als die aktuelle Anzahl von Shards sein.
Optional können Sie die Availability Zone für jeden Knoten in der Replikationsgruppe mit `ReshardingConfiguration` angeben.
+ `ReshardingConfiguration` – Optional. Eine Liste der bevorzugten Availability Zones für jeden Knoten in jedem Shard in der Replikationsgruppe. Verwenden Sie diesen Parameter nur, wenn der Wert von `NodeGroupCount` größer ist als die aktuelle Anzahl von Shards. Wenn dieser Parameter beim Hinzufügen von Shards weggelassen wird, ElastiCache wählt Amazon die Availability Zones für die neuen Knoten aus.
Der folgende Prozess beschreibt, wie Sie die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Cluster-Modus aktiviert) neu konfigurieren, indem Sie Shards mithilfe der API hinzufügen. ElastiCache
**Example - Shards hinzufügen**
Im folgenden Beispiel werden dem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) Knotengruppen hinzugefügt`my-cluster`, sodass nach Abschluss des Vorgangs insgesamt vier Knotengruppen vorhanden sind. Das Beispiel gibt auch die Availability Zone für jeden Knoten in jedem Shard an. Die Operation beginnt sofort.
```
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=4
&ReplicationGroupId=my-cluster
&ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2a
&ReshardingConfiguration.ReshardingConfiguration.1.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2c
&ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2b
&ReshardingConfiguration.ReshardingConfiguration.2.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2a
&ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2c
&ReshardingConfiguration.ReshardingConfiguration.3.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2d
&ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.1=us-east-2d
&ReshardingConfiguration.ReshardingConfiguration.4.PreferredAvailabilityZones.AvailabilityZone.2=us-east-2c
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [ModifyReplicationGroupShardConfiguration](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html)in der ElastiCache API-Referenz.
### Entfernen von Shards mit Online-Resharding
Sie können Shards mithilfe der API, oder aus Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) entfernen.AWS-ManagementkonsoleAWS CLI ElastiCache
**Topics**
+ [Entfernen von Shards (Konsole)](#redis-cluster-resharding-online-remove-console)
+ [Entfernen von Shards (AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [Shards entfernen (API) ElastiCache](#redis-cluster-resharding-online-remove-api)
#### Entfernen von Shards (Konsole)
Der folgende Prozess beschreibt, wie Sie die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu konfigurieren, indem Sie Shards mit dem entfernen.AWS-Managementkonsole
Bevor Sie Knotengruppen (Shards) aus Ihrer Replikationsgruppe entfernen, stellen Sie sicher, ElastiCache dass alle Ihre Daten in die verbleibenden Shards passen. Wenn die Daten passen, werden die angegebenen Shards wie angefordert aus der Replikationsgruppe gelöscht. Wenn die Daten nicht in die verbleibenden Knotengruppen passen, wird der Prozess beendet und die Replikationsgruppe hat dieselbe Knotengruppenkonfiguration wie vor dem Zeitpunkt, an dem die Anforderung erstellt wurde.
Sie können den verwenden AWS-Managementkonsole, um einen oder mehrere Shards aus Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) zu entfernen. Sie können nicht alle Shards in einer Replikationsgruppe entfernen. Stattdessen müssen Sie die Replikationsgruppe löschen. Weitere Informationen finden Sie unter [Löschen einer Replikationsgruppe](Replication.DeletingRepGroup.md). Das folgende Verfahren beschreibt den Vorgang zum Löschen eines oder mehrerer Shards.
**Um Shards aus Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) zu entfernen**
1. Öffnen Sie die Konsole unter ElastiCache . [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Valkey-Cluster** oder **Redis OSS-Cluster** aus.
1. Suchen Sie den Namen des Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert), aus dem Sie Shards entfernen möchten, und wählen Sie ihn aus, nicht das Feld links neben dem Clusternamen.
**Tipp**
**Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) haben in der Spalte Shards einen Wert von 1 oder höher.**
1. Wählen Sie in der Liste der Shards das Feld links von den Namen aller Shards, die Sie löschen möchten.
1. Wählen Sie **Delete Shard**.
#### Entfernen von Shards (AWS CLI)
Der folgende Prozess beschreibt, wie Sie die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu konfigurieren, indem Sie Shards mit dem entfernen.AWS CLI
**Wichtig**
Bevor Sie Knotengruppen (Shards) aus Ihrer Replikationsgruppe entfernen, stellen Sie sicher, ElastiCache dass alle Ihre Daten in die verbleibenden Shards passen. Wenn die Daten passen, werden die angegebenen Shards (`--node-groups-to-remove`) wie angefordert aus der Replikationsgruppe gelöscht und ihre Keyspaces den verbleibenden Shards zugeordnet. Wenn die Daten nicht in die verbleibenden Knotengruppen passen, wird der Prozess beendet und die Replikationsgruppe hat dieselbe Knotengruppenkonfiguration wie vor dem Zeitpunkt, an dem die Anforderung erstellt wurde.
Sie können den verwenden AWS CLI, um einen oder mehrere Shards aus Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) zu entfernen. Sie können nicht alle Shards in einer Replikationsgruppe entfernen. Stattdessen müssen Sie die Replikationsgruppe löschen. Weitere Informationen finden Sie unter [Löschen einer Replikationsgruppe](Replication.DeletingRepGroup.md).
Verwenden Sie die folgenden Parameter mit `modify-replication-group-shard-configuration`.
**Parameters**
+ `--apply-immediately` – Erforderlich. Gibt an, dass die Shard-Rekonfigurationsoperation sofort gestartet werden soll.
+ `--replication-group-id` – Erforderlich. Gibt an, für welche Replikationsgruppe (Cluster) die Shard-Rekonfigurationsoperation ausgeführt werden soll.
+ `--node-group-count` – Erforderlich. Gibt die Anzahl der Shards (Knotengruppen) an, die nach Abschluss des Vorgangs vorhanden sein müssen. Beim Entfernen von Shards muss der Wert von `--node-group-count` kleiner als die aktuelle Anzahl von Shards sein.
+ `--node-groups-to-remove`Erforderlich, wenn `--node-group-count` kleiner als die aktuelle Anzahl der Knotengruppen (Shards) ist. Eine Liste von Shards (Knotengruppe), die aus der Replikationsgruppe entfernt IDs werden sollen.
Das folgende Verfahren beschreibt den Vorgang zum Löschen eines oder mehrerer Shards.
**Example - Entfernen von Shards**
Im folgenden Beispiel werden zwei Knotengruppen aus dem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) entfernt`my-cluster`, sodass nach Abschluss des Vorgangs insgesamt zwei Knotengruppen vorhanden sind. Die Keyspaces der entfernten Shards werden gleichmäßig auf die verbleibenden Shards verteilt.
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 2 \
--node-groups-to-remove "0002" "0003" \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 2 ^
--node-groups-to-remove "0002" "0003" ^
--apply-immediately
```
#### Shards entfernen (API) ElastiCache
Sie können die ElastiCache API verwenden, um die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) online neu zu konfigurieren, indem Sie den Vorgang verwenden. `ModifyReplicationGroupShardConfiguration`
Der folgende Prozess beschreibt, wie Sie die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu konfigurieren, indem Sie Shards mithilfe der API entfernen. ElastiCache
**Wichtig**
Bevor Sie Knotengruppen (Shards) aus Ihrer Replikationsgruppe entfernen, stellen Sie sicher, ElastiCache dass alle Ihre Daten in die verbleibenden Shards passen. Wenn die Daten passen, werden die angegebenen Shards (`NodeGroupsToRemove`) wie angefordert aus der Replikationsgruppe gelöscht und ihre Keyspaces den verbleibenden Shards zugeordnet. Wenn die Daten nicht in die verbleibenden Knotengruppen passen, wird der Prozess beendet und die Replikationsgruppe hat dieselbe Knotengruppenkonfiguration wie vor dem Zeitpunkt, an dem die Anforderung erstellt wurde.
Sie können die ElastiCache API verwenden, um einen oder mehrere Shards aus Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) zu entfernen. Sie können nicht alle Shards in einer Replikationsgruppe entfernen. Stattdessen müssen Sie die Replikationsgruppe löschen. Weitere Informationen finden Sie unter [Löschen einer Replikationsgruppe](Replication.DeletingRepGroup.md).
Verwenden Sie die folgenden Parameter mit `ModifyReplicationGroupShardConfiguration`.
**Parameters**
+ `ApplyImmediately=true` – Erforderlich. Gibt an, dass die Shard-Rekonfigurationsoperation sofort gestartet werden soll.
+ `ReplicationGroupId` – Erforderlich. Gibt an, für welche Replikationsgruppe (Cluster) die Shard-Rekonfigurationsoperation ausgeführt werden soll.
+ `NodeGroupCount` – Erforderlich. Gibt die Anzahl der Shards (Knotengruppen) an, die nach Abschluss des Vorgangs vorhanden sein müssen. Beim Entfernen von Shards muss der Wert von `NodeGroupCount` kleiner als die aktuelle Anzahl von Shards sein.
+ `NodeGroupsToRemove`Erforderlich, wenn `--node-group-count` kleiner als die aktuelle Anzahl der Knotengruppen (Shards) ist. Eine Liste von Shards (Knotengruppe), die aus der Replikationsgruppe entfernt IDs werden sollen.
Das folgende Verfahren beschreibt den Vorgang zum Löschen eines oder mehrerer Shards.
**Example - Entfernen von Shards**
Im folgenden Beispiel werden zwei Knotengruppen aus dem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) entfernt`my-cluster`, sodass nach Abschluss des Vorgangs insgesamt zwei Knotengruppen vorhanden sind. Die Keyspaces der entfernten Shards werden gleichmäßig auf die verbleibenden Shards verteilt.
```
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=2
&ReplicationGroupId=my-cluster
&NodeGroupsToRemove.member.1=0002
&NodeGroupsToRemove.member.2=0003
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=
```
### Online-Shard-Rebalancing
Sie können Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) mithilfe der API, oder neu verteilen.AWS-ManagementkonsoleAWS CLI ElastiCache
**Topics**
+ [Online-Shard-Rebalancing (Console)](#redis-cluster-resharding-online-rebalance-console)
+ [Online-Shard-Rebalancing (AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [Online-Shard-Rebalancing (API) ElastiCache](#redis-cluster-resharding-online-rebalance-api)
#### Online-Shard-Rebalancing (Console)
Der folgende Prozess beschreibt, wie Sie die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu konfigurieren, indem Sie die Shards mithilfe von neu verteilen.AWS-Managementkonsole
**Um die Schlüsselräume zwischen den Shards auf Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu auszurichten**
1. Öffnen Sie die Konsole unter. ElastiCache [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Valkey-Cluster** oder **Redis OSS-Cluster** aus.
1. Wählen Sie den Namen des Valkey- oder Redis OSS-Clusters (Clustermodus aktiviert), den Sie neu verteilen möchten, und nicht das Feld links neben dem Namen.
**Tipp**
**Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) haben in der Spalte Shards einen Wert von 1 oder höher.**
1. Wählen Sie **Rebalance** aus.
1. Wählen Sie nach Aufforderung die Option **Rebalance** aus. Möglicherweise wird eine Meldung ähnlich der folgenden angezeigt:. *Slots in the replication group are uniformly distributed. Nothing to do. (Service: AmazonElastiCache; Status Code: 400; Error Code: InvalidReplicationGroupState; Request ID: 2246cebd-9721-11e7-8d5b-e1b0f086c8cf)* Wählen Sie **Cancel** wenn Sie das tun.
#### Online-Shard-Rebalancing (AWS CLI)
Verwenden Sie die folgenden Parameter mit `modify-replication-group-shard-configuration`.
**Parameters**
+ `-apply-immediately` – Erforderlich. Gibt an, dass die Shard-Rekonfigurationsoperation sofort gestartet werden soll.
+ `--replication-group-id` – Erforderlich. Gibt an, für welche Replikationsgruppe (Cluster) die Shard-Rekonfigurationsoperation ausgeführt werden soll.
+ `--node-group-count` – Erforderlich. Um die Keyspaces über alle Shards im Cluster neu zu verteilen, muss dieser Wert der aktuellen Anzahl von Shards entsprechen.
Der folgende Prozess beschreibt, wie Sie die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu konfigurieren, indem Sie die Shards mithilfe von neu verteilen.AWS CLI
**Example - Ausgleichen der Shards in einem Cluster**
Im folgenden Beispiel werden die Steckplätze im Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu verteilt, sodass die Steckplätze `my-cluster` so gleichmäßig wie möglich verteilt werden. Der Wert von `--node-group-count` (`4`) ist die Anzahl der derzeit im Cluster befindlichen Shards.
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 4 \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 4 ^
--apply-immediately
```
#### Online-Shard-Rebalancing (API) ElastiCache
Sie können die ElastiCache API verwenden, um die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) online neu zu konfigurieren, indem Sie den Vorgang verwenden. `ModifyReplicationGroupShardConfiguration`
Verwenden Sie die folgenden Parameter mit `ModifyReplicationGroupShardConfiguration`.
**Parameters**
+ `ApplyImmediately=true` – Erforderlich. Gibt an, dass die Shard-Rekonfigurationsoperation sofort gestartet werden soll.
+ `ReplicationGroupId` – Erforderlich. Gibt an, für welche Replikationsgruppe (Cluster) die Shard-Rekonfigurationsoperation ausgeführt werden soll.
+ `NodeGroupCount` – Erforderlich. Um die Keyspaces über alle Shards im Cluster neu zu verteilen, muss dieser Wert der aktuellen Anzahl von Shards entsprechen.
Der folgende Prozess beschreibt, wie Sie die Shards in Ihrem Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu konfigurieren, indem Sie die Shards mithilfe der API neu verteilen. ElastiCache
**Example - Cluster-Ausgleich**
Im folgenden Beispiel werden die Steckplätze im Valkey- oder Redis OSS-Cluster (Clustermodus aktiviert) neu verteilt, sodass die Steckplätze `my-cluster` so gleichmäßig wie möglich verteilt werden. Der Wert von `NodeGroupCount` (`4`) ist die Anzahl der derzeit im Cluster befindlichen Shards.
```
https://elasticache.us-east-2.amazonaws.com/
?Action=ModifyReplicationGroupShardConfiguration
&ApplyImmediately=true
&NodeGroupCount=4
&ReplicationGroupId=my-cluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20171002T192317Z
&X-Amz-Credential=
```
# Vertikales Online-Skalieren durch Ändern des Knotentyps
Durch die Verwendung der vertikalen Online-Skalierung mit Valkey Version 7.2 oder neuer oder Redis OSS Version 3.2.10 oder neuer können Sie Ihre Valkey- oder Redis OSS-Cluster dynamisch mit minimalen Ausfallzeiten skalieren. Dadurch kann Ihr Valkey- oder Redis OSS-Cluster Anfragen auch während der Skalierung bearbeiten.
**Anmerkung**
Die Skalierung zwischen einem Cluster mit Daten-Tiering (z. B. ein Cluster, der einen R6gd-Knotentyp verwendet) und einem Cluster ohne Daten-Tiering (z. B. ein Cluster, der einen R6g-Knotentyp verwendet) wird nicht unterstützt. Weitere Informationen finden Sie unter [Datenzuweisung ElastiCache](data-tiering.md).
Sie haben die folgenden Möglichkeiten:
+ **Skalieren** — Erhöhen Sie die Lese- und Schreibkapazität, indem Sie den Knotentyp Ihres Valkey- oder Redis OSS-Clusters so anpassen, dass ein größerer Knotentyp verwendet wird.
ElastiCache passt die Größe Ihres Clusters dynamisch an, bleibt aber online und bearbeitet Anfragen.
+ **Herunterskalierung** – Verringern Sie die Lese- und Schreibkapazität, indem Sie den Knotentyp auf die Verwendung eines kleineren Knotens anpassen. Auch hier wird die Größe Ihres Clusters ElastiCache dynamisch angepasst, während er online bleibt und Anfragen bearbeitet. In diesem Fall verringern Sie die Kosten durch die Verkleinerung des Knotens.
**Anmerkung**
Aufwärts- und Abwärtsskalieren basiert auf der Erstellung von neu ausgewählten Knotentypen und der Synchronisierung der neuen Knoten mit den vorherigen. Gehen Sie wie folgt vor, um einen reibungslosen up/down Ablauf der Skalierung sicherzustellen:
Stellen Sie Sicher, dass die Elastic Network-Schnittstelle (ENI) über ausreichend Kapazität verfügt. Vergewissern Sie sich beim Abwärtsskalieren, dass der kleinere Knoten über ausreichend Speicher für erwarteten Datenverkehr verfügt.
Erfahren Sie mehr über bewährte Methoden für die Speicherverwaltung unter [Verwaltung von reserviertem Speicher für Valkey und Redis OSS](redis-memory-management.md).
Während die vertikale Skalierung ausgelegt ist, vollständig online zu bleiben, basiert sie auf der Synchronisierung von Daten zwischen dem alten und dem neuen Knoten. Wir empfehlen, dass Sie Abwärts-/Aufwärtsskalieren zu einem Zeitpunkt durchführen, an dem der Datenverkehr am geringsten ist.
Testen Sie das Verhalten Ihrer Anwendung während der Skalierung möglichst in einer Staging-Umgebung.
**Contents**
+ [Online-aufwärtsskalieren](#redis-cluster-vertical-scaling-scaling-up)
+ [Skalierung von Valkey- oder Redis OSS-Clustern (Konsole)](#redis-cluster-vertical-scaling-console)
+ [Skalierung von Valkey- oder Redis OSS-Clustern ()AWS CLI](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Skalierung von Valkey- oder Redis OSS-Clustern (API) ElastiCache](#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [Online-abwärtsskalieren](#redis-cluster-vertical-scaling-scaling-down)
+ [Herunterskalierung von Valkey- oder Redis OSS-Clustern (Konsole)](#redis-cluster-vertical-scaling-down-console)
+ [Herunterskalieren von Valkey- oder Redis OSS-Clustern ()AWS CLI](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Herunterskalierung der Valkey- oder Redis OSS-Cluster (API) ElastiCache](#Scaling.Vertical.ScaleDown.API)
## Online-aufwärtsskalieren
**Topics**
+ [Skalierung von Valkey- oder Redis OSS-Clustern (Konsole)](#redis-cluster-vertical-scaling-console)
+ [Skalierung von Valkey- oder Redis OSS-Clustern ()AWS CLI](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Skalierung von Valkey- oder Redis OSS-Clustern (API) ElastiCache](#VeticalScaling.RedisReplGrps.ScaleUp.API)
### Skalierung von Valkey- oder Redis OSS-Clustern (Konsole)
Das folgende Verfahren beschreibt, wie Sie einen Valkey- oder Redis-OSS-Cluster mithilfe der ElastiCache Management Console skalieren. Während dieses Vorgangs bearbeitet Ihr Cluster weiterhin Anfragen mit minimaler Ausfallzeit.
**Um einen Valkey- oder Redis OSS-Cluster (Konsole) zu skalieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Valkey-Cluster** oder **Redis OSS-Cluster** aus.
1. Wählen Sie aus der Liste der Cluster den Cluster aus.
1. Wählen Sie **Ändern** aus.
1. Gehen Sie im **Modify Cluster**-Assistenten wie folgt vor:
1. Wählen Sie in der Liste **Node type** den Knotentyp aus, auf den Sie skalieren möchten. Wählen Sie zur Aufwärtsskalierung einen Knotentyp, der größer als Ihr bestehender Knoten ist.
1. Wenn Sie die Aufwärtsskalierung sofort starten möchten, aktivieren Sie das Kontrollkästchen **Apply immediately**. Wenn Sie das Kontrollkästchen für **Apply immediately** nicht aktivieren, wird die Skalierung während des nächsten Wartungsfensters des Clusters durchgeführt.
1. Wählen Sie **Ändern** aus.
Wenn Sie im vorherigen Schritt **Apply immediately** aktiviert haben, ändert sich der Cluster-Status zu *modifying*. Wenn der Status zu *available* wechselt, ist die Änderung abgeschlossen und Sie können den neuen Cluster verwenden.
### Skalierung von Valkey- oder Redis OSS-Clustern ()AWS CLI
Das folgende Verfahren beschreibt, wie Sie einen Valkey- oder Redis-OSS-Cluster mithilfe von skalieren.AWS CLI Während dieses Vorgangs bearbeitet Ihr Cluster weiterhin Anfragen mit minimaler Ausfallzeit.
**Um einen Valkey- oder Redis OSS-Cluster zu skalieren ()AWS CLI**
1. Ermitteln Sie die Knotentypen, auf die Sie skalieren können, indem Sie den AWS CLI`list-allowed-node-type-modifications` Befehl mit dem folgenden Parameter ausführen.
Für Linux, macOS oder Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Für Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium",
"cache.t1.small "
],
}
```
Weitere Informationen finden Sie unter [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in der *AWS CLI-Referenz*.
1. Ändern Sie Ihre Replikationsgruppe mithilfe des AWS CLI`modify-replication-group` Befehls und der folgenden Parameter, sodass sie auf den neuen, größeren Knotentyp skaliert werden kann.
+ `--replication-group-id` Der Name der zu erstellenden Replikationsgruppe, zu der Sie aufwärtsskalieren.
+ `--cache-node-type`— Der neue Knotentyp, für den Sie den Cluster skalieren möchten. Der Wert muss einer der Knotentypen sein, die in Schritt 1 mit dem Befehl `list-allowed-node-type-modifications` zurückgegeben wurden.
+ `--cache-parameter-group-name` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `--apply-immediately` – Führt die Skalierung sofort aus. Wenn Sie die Skalierung für das nächste Wartungsfenster des Clusters planen möchten, verwenden Sie den Parameter `--no-apply-immediately`.
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.m3.xlarge \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.m3.xlarge ^
--apply-immediately
```
Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format).
```
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "my-redis-cluster",
"NodeGroups": [
{
"Status": "modifying",
"Slots": "0-16383",
"NodeGroupId": "0001",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-east-1f",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-001"
},
{
"PreferredAvailabilityZone": "us-east-1d",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-002"
}
]
}
],
"ConfigurationEndpoint": {
"Port": 6379,
"Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
},
"ClusterEnabled": true,
"ReplicationGroupId": "my-redis-cluster",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotWindow": "07:30-08:30",
"MemberClusters": [
"my-redis-cluster-0001-001",
"my-redis-cluster-0001-002"
],
"CacheNodeType": "cache.m3.xlarge",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
```
Weitere Informationen finden Sie unter [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) in der *AWS CLI-Referenz*.
1. Wenn Sie den verwendet haben`--apply-immediately`, überprüfen Sie den Status des Clusters mithilfe des AWS CLI`describe-cache-clusters` Befehls mit dem folgenden Parameter. Wenn sich der Status auf *verfügbar* ändert, können Sie mit der Verwendung des neuen, größeren Clusterknotens beginnen.
### Skalierung von Valkey- oder Redis OSS-Clustern (API) ElastiCache
Der folgende Prozess skaliert Ihren Cluster mithilfe der API von seinem aktuellen Knotentyp auf einen neuen, größeren Knotentyp. ElastiCache Während dieses Vorgangs werden die DNS-Einträge ElastiCache aktualisiert, sodass sie auf die neuen Knoten verweisen. Daher müssen Sie die Endpunkte in Ihrer Anwendung nicht aktualisieren. Für Valkey 7.2 und höher, Redis OSS 5.0.5 und höher, können Sie Cluster mit auto Failover skalieren, während der Cluster weiterhin online bleibt und eingehende Anfragen bearbeitet. Bei Version Redis OSS 4.0.10 und niedriger stellen Sie möglicherweise eine kurze Unterbrechung der Lese- und Schreibvorgänge auf früheren Versionen vom Primärknoten aus fest, während der DNS-Eintrag aktualisiert wird.
Die Zeit, die für die Skalierung auf einen größeren Knotentyp benötigt wird, hängt von Ihrem Knotentyp und der Datenmenge in Ihrem aktuellen Cluster ab.
**So skalieren Sie einen Valkey- oder Redis OSS-Cache-Cluster (API) ElastiCache**
1. Ermitteln Sie, auf welche Knotentypen Sie mithilfe der ElastiCache `ListAllowedNodeTypeModifications` API-Aktion mit dem folgenden Parameter skalieren können.
+ `ReplicationGroupId` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in der *Amazon ElastiCache API-Referenz*.
1. Skalieren Sie Ihre aktuelle Replikationsgruppe mithilfe der `ModifyReplicationGroup` ElastiCache API-Aktion und mit den folgenden Parametern auf den neuen Knotentyp.
+ `ReplicationGroupId` der Name der Replikationsgruppe.
+ `CacheNodeType`— der neue, größere Knotentyp der Cluster in dieser Replikationsgruppe. Dieser Wert muss einer der Instance-Typen sein, die von der `ListAllowedNodeTypeModifications` Aktion im vorherigen Schritt zurückgegeben wurden.
+ `CacheParameterGroupName` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `ApplyImmediately`Legen Sie `true` fest, um die Skalierung sofort auszuführen. Wenn Sie die Skalierung für das nächste Wartungsfenster planen möchten, verwenden Sie `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.m3.2xlarge
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Weitere Informationen finden Sie [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) in der *Amazon ElastiCache API-Referenz*.
1. Falls Sie dies verwendet haben `ApplyImmediately``=true`, überwachen Sie den Status der Replikationsgruppe mithilfe der ElastiCache `DescribeReplicationGroups` API-Aktion mit den folgenden Parametern. Wenn der Status von *modifying* zu *available* wechselt, können Sie die neue, aufskalierte Replikationsgruppe verwenden.
+ `ReplicationGroupId` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) in der *Amazon ElastiCache API-Referenz*.
## Online-abwärtsskalieren
**Topics**
+ [Herunterskalierung von Valkey- oder Redis OSS-Clustern (Konsole)](#redis-cluster-vertical-scaling-down-console)
+ [Herunterskalieren von Valkey- oder Redis OSS-Clustern ()AWS CLI](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Herunterskalierung der Valkey- oder Redis OSS-Cluster (API) ElastiCache](#Scaling.Vertical.ScaleDown.API)
### Herunterskalierung von Valkey- oder Redis OSS-Clustern (Konsole)
Das folgende Verfahren beschreibt, wie Sie einen Valkey- oder Redis-OSS-Cluster mithilfe der ElastiCache Management Console herunterskalieren. Während dieses Vorgangs bearbeitet Ihr Valkey- oder Redis OSS-Cluster weiterhin Anfragen mit minimaler Ausfallzeit.
**Um einen Valkey- oder Redis OSS-Cluster herunterzuskalieren (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die ElastiCache Konsole unter. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Wählen Sie im Navigationsbereich **Valkey-Cluster** oder **Redis OSS-Cluster** aus.
1. Wählen Sie aus der Liste der Cluster Ihren bevorzugten Cluster.
1. Wählen Sie **Ändern** aus.
1. Gehen Sie im **Modify Cluster**-Assistenten wie folgt vor:
1. Wählen Sie in der Liste **Node type** den Knotentyp aus, auf den Sie skalieren möchten. Wählen Sie zur Abwärtsskalierung einen Knotentyp, der kleiner als Ihr bestehender Knoten ist. Beachten Sie, dass nicht alle Knotentypen für das Herunterskalieren zur Verfügung stehen.
1. Wenn Sie die Abwärtsskalierung sofort starten möchten, aktivieren Sie das Kontrollkästchen **Apply immediately**. Wenn Sie das Kontrollkästchen für **Apply immediately** nicht aktivieren, wird die Abwärtsskalierung während des nächsten Wartungsfensters des Clusters durchgeführt.
1. Wählen Sie **Ändern** aus.
Wenn Sie im vorherigen Schritt **Apply immediately** aktiviert haben, ändert sich der Cluster-Status zu *modifying*. Wenn der Status zu *available* wechselt, ist die Änderung abgeschlossen und Sie können den neuen Cluster verwenden.
### Herunterskalieren von Valkey- oder Redis OSS-Clustern ()AWS CLI
Das folgende Verfahren beschreibt, wie Sie einen Valkey- oder Redis-OSS-Cluster mithilfe von herunterskalieren.AWS CLI Während dieses Vorgangs bearbeitet Ihr Cluster weiterhin Anfragen mit minimaler Ausfallzeit.
**Um einen Valkey- oder Redis OSS-Cluster herunterzuskalieren ()AWS CLI**
1. Ermitteln Sie die Knotentypen, auf die Sie herunterskalieren können, indem Sie den AWS CLI`list-allowed-node-type-modifications` Befehl mit dem folgenden Parameter ausführen.
Für Linux, macOS oder Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Für Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format).
```
{
"ScaleUpModifications": [
"cache.m3.2xlarge",
"cache.m3.large",
"cache.m3.xlarge",
"cache.m4.10xlarge",
"cache.m4.2xlarge",
"cache.m4.4xlarge",
"cache.m4.large",
"cache.m4.xlarge",
"cache.r3.2xlarge",
"cache.r3.4xlarge",
"cache.r3.8xlarge",
"cache.r3.large",
"cache.r3.xlarge"
]
"ScaleDownModifications": [
"cache.t2.micro",
"cache.t2.small ",
"cache.t2.medium ",
"cache.t1.small"
]
}
```
Weitere Informationen finden Sie unter [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) in der *AWS CLI-Referenz*.
1. Ändern Sie Ihre Replikationsgruppe mithilfe des AWS CLI`modify-replication-group` Befehls und der folgenden Parameter, sodass sie auf den neuen, kleineren Knotentyp herunterskaliert wird.
+ `--replication-group-id` Der Name der Replikationsgruppe, zu der Sie abwärtsskalieren.
+ `--cache-node-type`— Der neue Knotentyp, für den Sie den Cluster skalieren möchten. Der Wert muss einer der Knotentypen sein, die in Schritt 1 mit dem Befehl `list-allowed-node-type-modifications` zurückgegeben wurden.
+ `--cache-parameter-group-name` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `--apply-immediately` – Führt die Skalierung sofort aus. Wenn Sie die Skalierung für das nächste Wartungsfenster des Clusters planen möchten, verwenden Sie den Parameter `--no-apply-immediately`.
Für Linux, macOS oder Unix:
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.t2.micro \
--apply-immediately
```
Für Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.t2.micro ^
--apply-immediately
```
Die Ausgabe des obigen Befehls sieht in etwa folgendermaßen aus (JSON format).
```
{
"ReplicationGroup": {
"Status": "modifying",
"Description": "my-redis-cluster",
"NodeGroups": [
{
"Status": "modifying",
"Slots": "0-16383",
"NodeGroupId": "0001",
"NodeGroupMembers": [
{
"PreferredAvailabilityZone": "us-east-1f",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-001"
},
{
"PreferredAvailabilityZone": "us-east-1d",
"CacheNodeId": "0001",
"CacheClusterId": "my-redis-cluster-0001-002"
}
]
}
],
"ConfigurationEndpoint": {
"Port": 6379,
"Address": "my-redis-cluster.r7gdfi.clustercfg.use1.cache.amazonaws.com"
},
"ClusterEnabled": true,
"ReplicationGroupId": "my-redis-cluster",
"SnapshotRetentionLimit": 1,
"AutomaticFailover": "enabled",
"SnapshotWindow": "07:30-08:30",
"MemberClusters": [
"my-redis-cluster-0001-001",
"my-redis-cluster-0001-002"
],
"CacheNodeType": "cache.t2.micro",
"DataTiering": "disabled"
"PendingModifiedValues": {}
}
}
```
Weitere Informationen finden Sie unter [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) in der *AWS CLI-Referenz*.
1. Wenn Sie den verwendet haben`--apply-immediately`, überprüfen Sie den Status des Clusters mithilfe des AWS CLI`describe-cache-clusters` Befehls mit dem folgenden Parameter. Wenn sich der Status auf *verfügbar* ändert, können Sie mit der Verwendung des neuen, kleineren Clusterknotens beginnen.
### Herunterskalierung der Valkey- oder Redis OSS-Cluster (API) ElastiCache
Mit dem folgenden Prozess wird Ihre Replikationsgruppe mithilfe der API vom aktuellen Knotentyp auf einen neuen, kleineren Knotentyp skaliert. ElastiCache Während dieses Vorgangs bearbeitet Ihr Valkey- oder Redis OSS-Cluster weiterhin Anfragen mit minimaler Ausfallzeit.
Die Zeit, die benötigt wird, um auf einen kleineren Knotentyp herunterzuskalieren, hängt von Ihrem Knotentyp und der Datenmenge in Ihrem aktuellen Cluster ab.
**Herunterskalierung (ElastiCache API)**
1. Ermitteln Sie, auf welche Knotentypen Sie mithilfe der ElastiCache `ListAllowedNodeTypeModifications` API-Aktion mit dem folgenden Parameter herunterskalieren können.
+ `ReplicationGroupId` der Name der Replikationsgruppe. Verwenden Sie diesen Parameter, um eine bestimmte Replikationsgruppe zu beschreiben, statt alle Replikationsgruppen anzugeben.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) in der *Amazon ElastiCache API-Referenz*.
1. Skalieren Sie Ihre aktuelle Replikationsgruppe mithilfe der `ModifyReplicationGroup` ElastiCache API-Aktion und mit den folgenden Parametern auf den neuen Knotentyp herunter.
+ `ReplicationGroupId` der Name der Replikationsgruppe.
+ `CacheNodeType`— der neue, kleinere Knotentyp der Cluster in dieser Replikationsgruppe. Dieser Wert muss einer der Instance-Typen sein, die von der `ListAllowedNodeTypeModifications` Aktion im vorherigen Schritt zurückgegeben wurden.
+ `CacheParameterGroupName` – [Optional) Verwenden Sie diesen Parameter, wenn Sie `reserved-memory` verwenden, um Speicher für den Cluster zu reservieren. Geben Sie eine benutzerdefinierte Cache-Parametergruppe an, die die korrekte Speichermenge für den neuen Knotentyp reserviert. Wenn Sie `reserved-memory-percent` verwenden, können Sie diesen Parameter weglassen.
+ `ApplyImmediately` – Legen Sie `true` fest, um die Abwärtsskalierung sofort auszuführen. Wenn Sie die Abwärtsskalierung für das nächste Wartungsfenster planen möchten, verwenden Sie `ApplyImmediately``=false`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ModifyReplicationGroup
&ApplyImmediately=true
&CacheNodeType=cache.t2.micro
&CacheParameterGroupName=redis32-m3-2xl
&ReplicationGroupId=myReplGroup
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20141201T220302Z
&Version=2014-12-01
&X-Amz-Algorithm=&AWS;4-HMAC-SHA256
&X-Amz-Date=20141201T220302Z
&X-Amz-SignedHeaders=Host
&X-Amz-Expires=20141201T220302Z
&X-Amz-Credential=
&X-Amz-Signature=
```
Weitere Informationen finden Sie [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) in der *Amazon ElastiCache API-Referenz*.
# Erste Schritte mit Bloom-Filtern
ElastiCache unterstützt die Bloom-Filter-Datenstruktur, die eine platzsparende probabilistische Datenstruktur bietet, mit der überprüft werden kann, ob ein Element Mitglied einer Menge ist. Bei der Verwendung von Bloom-Filtern sind falsch positive Ergebnisse möglich — ein Filter kann fälschlicherweise angeben, dass ein Element vorhanden ist, obwohl dieses Element dem Satz nicht hinzugefügt wurde. Die Verwendung von Bloom-Filtern verhindert jedoch falsch *negative Ergebnisse* — falsche Hinweise darauf, dass ein Element *nicht* existiert, obwohl dieses Element dem Satz hinzugefügt wurde.
Sie können den Prozentsatz potenzieller falsch positiver Ergebnisse auf eine für Ihre Arbeitslast bevorzugte Rate festlegen, indem Sie die FP-Rate anpassen. Sie können auch die Kapazität (die Anzahl der Elemente, die ein Bloom-Filter aufnehmen kann), Eigenschaften für Skalierung und Nicht-Skalierung und vieles mehr konfigurieren.
Nachdem Sie einen Cluster mit einer unterstützten Engine-Version erstellt haben, sind der Bloom-Datentyp und die zugehörigen Befehle automatisch verfügbar. Der `bloom` Datentyp ist API-kompatibel mit der Bloom-Filter-Befehlssyntax der offiziellen Valkey-Clientbibliotheken`valkey-py`, einschließlich`valkey-java`, und`valkey-go`. Sie können bestehende Bloom-basierte Valkey- und Redis-OSS-Anwendungen problemlos in diese migrieren. ElastiCache Eine vollständige Liste der Befehle finden Sie unter. [Bloom-Filter-Befehle](#SupportedCommandsBloom)
Die Bloom-bezogenen Metriken `BloomFilterBasedCmds``BloomFilterBasedCmdsLatency`, und `BloomFilterBasedCmdsECPUs` sind integriert, CloudWatch um die Verwendung dieses Datentyps zu überwachen. Weitere Informationen finden Sie unter [Metriken für Valkey und Redis OSS](CacheMetrics.Redis.md).
**Anmerkung**
Um Bloom-Filter verwenden zu können, müssen Sie ElastiCache Valkey 8.1 und höher verwenden.
Der Bloom-Datentyp ist nicht RDB-kompatibel mit anderen Bloom-Angeboten, die nicht auf Valkey basieren.
## Übersicht über den Datentyp Bloom-Filter
Bloom-Filter sind eine platzsparende probabilistische Datenstruktur, mit der Elemente hinzugefügt und überprüft werden können, ob Elemente vorhanden sind. Falsch positive Ergebnisse sind möglich, wenn ein Filter fälschlicherweise anzeigt, dass ein Element existiert, obwohl es nicht hinzugefügt wurde. Bloom-Filter garantieren jedoch, dass falsch negative Ergebnisse (die fälschlicherweise darauf hinweisen, dass ein Element nicht existiert, obwohl es hinzugefügt wurde) nicht vorkommen.
Die Hauptdokumentationsquelle für Bloom-Filter finden Sie auf der valkey.io-Dokumentationsseite. Diese enthält die folgenden Informationen:
+ [Häufige Anwendungsfälle für Bloom-Filter](https://valkey.io/topics/bloomfilters/#common-use-cases-for-bloom-filters)
+ Deduplizierung von Werbung und Ereignissen
+ Betrugserkennung
+ Filterung schädlicher Inhalte /Spam
+ Einzigartige Benutzererkennung
+ [Unterschiede zwischen skalierenden und nicht skalierenden Bloom-Filtern](https://valkey.io/topics/bloomfilters/#scaling-and-non-scaling-bloom-filters)
+ Wie entscheidet man sich zwischen skalierenden und nicht skalierenden Bloom-Filtern
+ [Bloom-Eigenschaften](https://valkey.io/topics/bloomfilters/#bloom-properties)
+ Erfahren Sie mehr über die einstellbaren Eigenschaften von Bloom-Filtern. Dazu gehören die Falsch-Positiv-Rate, die Kapazität, die Skalierung und die Nicht-Skalierung und vieles mehr.
+ [Leistung von Bloom-Befehlen](https://valkey.io/topics/bloomfilters/#performance)
+ [Überwachung der gesamten Bloom-Filter-Statistiken](https://valkey.io/topics/bloomfilters/#monitoring)
+ [Umgang mit großen Bloom-Filtern](https://valkey.io/topics/bloomfilters/#handling-large-bloom-filters)
+ Empfehlungen und Details, wie Sie überprüfen können, ob ein Bloom-Filter sein Speichernutzungslimit erreicht hat und ob er skaliert werden kann, um die gewünschte Kapazität zu erreichen.
+ Mit dem Befehl [BF.INFO können Sie gezielt überprüfen, wie viel Speicher von einem Bloom-Filter-Dokument belegt](https://valkey.io/commands/bf.info/) wird.
## Größenbeschränkung für Bloom
Der Speicherverbrauch eines einzelnen Bloom-Filterobjekts ist auf 128 MB begrenzt. Mit dem `BF.INFO SIZE` Befehl können Sie überprüfen, wie viel Speicher von einem Bloom-Filter verbraucht wird.
## Bloom ACLs
Ähnlich wie bei den bestehenden Kategorien pro Datentyp (@string, @hash usw.) wurde eine neue Kategorie @bloom hinzugefügt, um die Verwaltung des Zugriffs auf Bloom-Befehle und -Daten zu vereinfachen. Keine anderen vorhandenen Valkey- oder Redis OSS-Befehle gehören zur Kategorie @bloom.
Es gibt 3 bestehende ACL-Kategorien, die aktualisiert wurden und nun die neuen Bloom-Befehle enthalten: @read, @write und @fast. Die folgende Tabelle zeigt die Zuordnung der Bloom-Befehle zu den entsprechenden Kategorien.
| Befehl Bloom | @read | @write | @fast | @bloom |
| --- | --- | --- | --- | --- |
| BF.HINZUFÜGEN | | y | y | y |
| BF.CARD | y | | y | y |
| BF.EXISTIERT | y | | y | y |
| BF.INFO | y | | y | y |
| BF.EINFÜGEN | | y | y | y |
| BF.MADD | | y | y | y |
| BF.M EXISTIERT | y | | y | y |
| BF.RESERVE | y | | y | y |
## Metriken im Zusammenhang mit Bloom-Filtern
Die folgenden CloudWatch Metriken im Zusammenhang mit Bloom-Datenstrukturen werden bereitgestellt:
| CW-Metriken | Einheit | Serverlos/knotenbasiert | Description |
| --- | --- | --- | --- |
| BloomFilterBasedCmds | Anzahl | beides | Die Gesamtzahl der Bloom-Filterbefehle, einschließlich Lese- und Schreibbefehlen. |
| BloomFilterBasedCmdsLatency | Mikrosekunden | Selbstverwaltet | Latenz aller Bloom-Filterbefehle, einschließlich Lese- und Schreibbefehlen. |
| BloomFilterBasedCmdsECPUs | Anzahl | Serverless | ECPUs wird von allen Bloom-Filterbefehlen, einschließlich Lese- und Schreibbefehlen, verbraucht. |
## Bloom-Filter-Befehle
[Bloom-Filter-Befehle](https://valkey.io/commands/#bloom) sind auf der [Valkey.io-Website](https://valkey.io/) dokumentiert. Jede Befehlsseite bietet einen umfassenden Überblick über die Bloom-Befehle, einschließlich ihrer Syntax, ihres Verhaltens, ihrer Rückgabewerte und möglicher Fehlerbedingungen.
| Name | Description |
| --- | --- |
| [BF.ADD](https://valkey.io/commands/bf.add/) | Fügt einem Bloom-Filter ein einzelnes Element hinzu. Wenn der Filter noch nicht existiert, wird er erstellt. |
| [BF.CARD](https://valkey.io/commands/bf.card/) | Gibt die Kardinalität eines Bloom-Filters zurück. |
| [BF. EXISTIERT](https://valkey.io/commands/bf.exists/) | Ermittelt, ob der Bloom-Filter das angegebene Element enthält. |
| [BF.INFO](https://valkey.io/commands/bf.info/) | Gibt Nutzungsinformationen und Eigenschaften eines bestimmten Bloom-Filters zurück. |
| [BF.INSERT](https://valkey.io/commands/bf.insert/) | Erstellt einen Bloom-Filter mit 0 oder mehr Elementen oder fügt Elemente zu einem vorhandenen Bloom-Filter hinzu. |
| [BF.MADD](https://valkey.io/commands/bf.madd/) | Fügt einem Bloom-Filter ein oder mehrere Elemente hinzu. |
| [BF.M EXISTIERT](https://valkey.io/commands/bf.mexists/) | Ermittelt, ob der Bloom-Filter ein oder mehrere Elemente enthält. |
| [BF.RESERVE](https://valkey.io/commands/bf.reserve/) | Erzeugt einen leeren Bloom-Filter mit den angegebenen Eigenschaften. |
**Anmerkung**
**BF.LOAD** wird von nicht unterstützt. ElastiCache Es ist nur für die Verwendung von AOF relevant, die ElastiCache nicht unterstützt wird.
# Erste Schritte mit Watch in Serverless
ElastiCache unterstützt den `WATCH` Befehl, mit dem Sie Schlüssel auf Änderungen überwachen und bedingte [Transaktionen](https://valkey.io/topics/transactions/) ausführen können. Der `WATCH` Befehl ist besonders nützlich für Anwendungen, die eine optimistische Parallelitätssteuerung erfordern. Dadurch wird sichergestellt, dass Transaktionen nur ausgeführt werden, wenn die überwachten Schlüssel nicht geändert wurden. Dazu gehören Änderungen, die von einem Client vorgenommen wurden, wie Schreibbefehle, und von Valkey selbst, wie Ablauf oder Räumung. Wenn Schlüssel seit ihrer Eingabe `WATCH` und bis zum Zeitpunkt ihres Eingangs geändert wurden, wird die gesamte Transaktion abgebrochen. `EXEC`
Für ElastiCache Serverless werden die folgenden Einschränkungen eingeführt:
ElastiCache Serverless `WATCH` ist auf einen einzelnen Hash-Slot beschränkt. Das bedeutet, dass nur Schlüssel, die demselben Hash-Slot zugeordnet sind, gleichzeitig über dieselbe Verbindung überwacht werden können und die Transaktion, die den Watch-Befehlen folgt, nur auf demselben Hash-Slot ausgeführt werden kann. Wenn eine Anwendung versucht, Schlüssel aus verschiedenen Hash-Slots zu überwachen oder Transaktionsbefehle auszuführen, die auf Schlüsseln ausgeführt werden, die einem anderen Hash-Slot als dem der überwachten Schlüssel zugeordnet sind, wird ein `CROSSSLOT` Fehler zurückgegeben. [Hashtags](https://valkey.io/topics/cluster-spec/#hash-tags) können verwendet werden, um sicherzustellen, dass mehrere Schlüssel demselben Hash-Slot zugeordnet sind.
Darüber hinaus kann der `SCAN` Befehl nicht innerhalb einer Verbindung mit überwachten Schlüsseln ausgeführt werden und gibt einen `command not supported during watch state` Fehler zurück.
Die Transaktion wird abgebrochen (als ob überwachte Schlüssel berührt worden wären), wenn ElastiCache Serverless nicht sicher ist, ob ein Schlüssel geändert wurde. Zum Beispiel, wenn ein Slot migriert wurde und die überwachten Schlüssel nicht auf demselben Knoten gefunden werden können.
**Codebeispiele**
## Tasten von verschiedenen Steckplätzen aus überwachen und bedienen
Im folgenden Beispiel sind der überwachte Schlüssel und der im `SET` Befehl angegebene Schlüssel verschiedenen Hash-Slots zugeordnet. Die Ausführung gibt a zurück`CROSSSLOT ERROR`.
```
> WATCH foo:{005119}
OK
> MULTI
OK
> SET bar:{011794} 1234
QUEUED
> EXEC
CROSSSLOT Keys in request don't hash to the same slot
```
## Tasten vom selben Steckplatz aus beobachten und bedienen
Das folgende Beispiel zeigt eine erfolgreiche Transaktion, da der eingegebene Schlüssel `WATCH` nicht geändert wurde.
```
> WATCH foo:{005119}
OK
> MULTI
OK
> SET bar:{005119} 1234
QUEUED
> EXEC
1) OK
```
## Sehen Sie sich die Schlüssel von verschiedenen Spielautomaten an
Im folgenden Beispiel gibt ein Versuch, `WATCH` Schlüssel von verschiedenen Steckplätzen gleichzeitig innerhalb derselben Client-Verbindung zu verwenden, a zurück`CROSSSLOT ERROR`.
```
> WATCH foo:{005119}
OK
> WATCH bar:{123455}
CROSSSLOT Keys in request don't hash to the same slot
```
## Limit ansehen
Jede Client-Verbindung kann bis zu 1000 Schlüssel gleichzeitig überwachen.
## Unterstützte Befehle im Zusammenhang mit Watch
Die Befehle [WATCH](https://valkey.io/commands/watch/) und [UNWATCH](https://valkey.io/commands/unwatch/) sind auf der [Valkey.io-Website](https://valkey.io/) dokumentiert. Sie bietet einen umfassenden Überblick über die Befehle, einschließlich ihrer Syntax, ihres Verhaltens, ihrer Rückgabewerte und möglicher Fehlerbedingungen.
# Erste Schritte mit Vector Search
Amazon ElastiCache for Valkey unterstützt die Vektorsuche, sodass Sie Milliarden von hochdimensionalen Vektoreinbettungen mit Latenzen von nur Mikrosekunden und einem Abruf von mehr als 99% im Speicher speichern, suchen und aktualisieren können. ElastiCache for Valkey bietet Funktionen zum Indizieren, Suchen und Aktualisieren von Milliarden von hochdimensionalen Vektoreinbettungen von bekannten Anbietern wie Amazon Bedrock, Amazon SageMaker, Anthropic oder OpenAI für schnelles Suchen und Abrufen. Die Vektorsuche für Amazon ElastiCache ist ideal für Anwendungsfälle, in denen Spitzenleistung und Skalierbarkeit die wichtigsten Auswahlkriterien sind. Dazu gehören semantisches Caching, Generierung mit erweitertem Abruf, Empfehlungen in Echtzeit, Personalisierung und Erkennung von Anomalien.
Die Vektorsuche kann in Verbindung mit anderen Funktionen verwendet werden, um Ihre Anwendungen zu verbessern. ElastiCache Die Vektorsuche nach ElastiCache ist in Valkey Version 8.2 auf knotenbasierten Clustern in allen [AWS Regionen](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) ohne zusätzliche Kosten verfügbar. Erstellen Sie zunächst einen neuen Valkey 8.2-Cluster mit dem SDK oder [AWS-Managementkonsole](https://console.aws.amazon.com/elasticache/).AWSAWS CLI Sie können die Vektorsuche auch in Ihrem vorhandenen Cluster verwenden, indem Sie mit [wenigen Klicks](VersionManagement.HowTo.md) und ohne Ausfallzeiten von einer beliebigen früheren Version von Valkey oder Redis OSS auf Valkey 8.2 aktualisieren.
# Überblick über die Vektorsuche
ElastiCache for Valkey bietet Funktionen zum Indizieren, Suchen und Aktualisieren von Milliarden von hochdimensionalen Vektoreinbettungen. Die Vektorsuche ermöglicht es Ihnen, Sekundärindizes für eine effiziente und skalierbare Suche zu erstellen, zu verwalten und zu verwenden. Jeder Vektorsuchvorgang bezieht sich auf einen einzelnen Index. Indexoperationen gelten nur für den angegebenen Index. Eine beliebige Anzahl von Vorgängen kann jederzeit für jeden Index ausgeführt werden, mit Ausnahme von Vorgängen zum Erstellen und Löschen von Indizes. Auf Clusterebene können mehrere Operationen für mehrere Indizes gleichzeitig ausgeführt werden.
In diesem Dokument sind die Begriffe Schlüssel, Zeile und Datensatz identisch und werden synonym verwendet. In ähnlicher Weise werden auch die Begriffe Spalte, Feld, Pfad und Element synonym verwendet.
Der `FT.CREATE` Befehl kann verwendet werden, um einen Index für eine Teilmenge von Schlüsseln mit den angegebenen Indextypen zu erstellen. `FT.SEARCH`führt Abfragen an erstellten Indizes durch und `FT.DROPINDEX` entfernt einen vorhandenen Index und alle zugehörigen Daten. Es gibt keine speziellen Befehle zum Hinzufügen, Löschen oder Ändern indizierter Daten. Die vorhandenen `JSON` Befehle `HASH` oder, die einen Schlüssel ändern, der sich in einem Index befindet, aktualisieren den Index automatisch.
**Topics**
+ [Indizes und der Valkey OSS-Keyspace](#indexes-keyspace)
+ [Index-Feldtypen](#index-field-types)
+ [Vektor-Index-Algorithmen](#vector-index-algorithms)
+ [Sicherheit bei der Vektorsuche](#vector-search-security)
## Indizes und der Valkey OSS-Keyspace
Indizes werden für eine Teilmenge des Valkey-OSS-Schlüsselraums erstellt und verwaltet. Der Schlüsselraum für jeden Index wird durch eine Liste von Schlüsselpräfixen definiert, die bei der Erstellung des Indexes bereitgestellt werden. Die Liste der Präfixe ist optional, und wenn sie weggelassen wird, ist der gesamte Schlüsselraum Teil dieses Indexes. Bei mehreren Indizes können unzusammenhängende oder überlappende Teilmengen des Schlüsselraums ohne Einschränkung ausgewählt werden.
Indizes werden auch so eingegeben, dass sie nur Schlüssel abdecken, die einen übereinstimmenden Typ haben. Derzeit werden Indizes nur für Typen und unterstützt. `JSON` `HASH` Ein `HASH` Index indexiert nur `HASH` Schlüssel, die in seiner Präfixliste enthalten sind, und in ähnlicher Weise indexiert ein `JSON` Index nur `JSON` Schlüssel, die in seiner Präfixliste enthalten sind. Schlüssel in der Schlüsselraumpräfixliste eines Indexes, die nicht den angegebenen Typ haben, werden ignoriert und wirken sich nicht auf Suchvorgänge aus.
Ein Index wird aktualisiert, wenn ein Befehl eine Taste ändert, die sich innerhalb des Schlüsselraums des Indexes befindet. Valkey extrahiert automatisch die deklarierten Felder für jeden Index und aktualisiert den Index mit dem neuen Wert. Der Aktualisierungsprozess besteht aus drei Schritten. Im ersten Schritt wird der HASH- oder JSON-Schlüssel geändert und der anfragende Client wird blockiert. Der zweite Schritt wird im Hintergrund ausgeführt und aktualisiert jeden der Indizes, die den geänderten Schlüssel enthalten. Im dritten Schritt wird der Client entsperrt. Bei Abfrageoperationen, die auf derselben Verbindung wie eine Mutation ausgeführt werden, ist diese Änderung also sofort in den Suchergebnissen sichtbar.
Die Erstellung eines Indexes ist ein mehrstufiger Prozess. Der erste Schritt besteht darin, den Befehl FT.CREATE auszuführen, der den Index definiert. Bei erfolgreicher Ausführung einer Erstellung wird automatisch der zweite Schritt eingeleitet — das Backfilling. Der Backfill-Prozess läuft in einem Hintergrund-Thread und durchsucht den Schlüsselbereich nach Schlüsseln, die sich in der Präfixliste des neuen Indexes befinden. Jeder gefundene Schlüssel wird dem Index hinzugefügt. Schließlich wird der gesamte Schlüsselraum gescannt, wodurch der Indexerstellungsprozess abgeschlossen ist. Beachten Sie, dass während der Ausführung des Backfill-Prozesses Mutationen von indizierten Schlüsseln zulässig sind, es keine Einschränkungen gibt und dass der Index-Backfill-Prozess erst abgeschlossen wird, wenn alle Schlüssel ordnungsgemäß indexiert sind. Abfrageoperationen, die versucht werden, während ein Index aufgefüllt wird, sind nicht zulässig und werden mit einem Fehler beendet. Der Befehl FT.INFO gibt den Status des Backfill-Vorgangs im Feld „backfill\$1status“ zurück.
## Index-Feldtypen
Jeder Index hat einen bestimmten Typ, der zusammen mit der Position eines zu indizierenden Felds (Spalte) deklariert wird, wenn der Index erstellt wird. Bei `HASH` Schlüsseln ist die Position der Feldname innerhalb von. `HASH` Bei `JSON` Schlüsseln ist der Speicherort eine JSON-Pfadbeschreibung. Wenn ein Schlüssel geändert wird, werden die mit den deklarierten Feldern verknüpften Daten extrahiert, in den deklarierten Typ konvertiert und im Index gespeichert. Wenn die Daten fehlen oder nicht erfolgreich in den deklarierten Typ konvertiert werden können, wird dieses Feld aus dem Index weggelassen. Es gibt drei Arten von Feldern, die im Folgenden erklärt werden:
+ **Vektorfelder** enthalten einen Zahlenvektor, der auch als Vektoreinbettung bezeichnet wird. Vektorfelder können verwendet werden, um Vektoren auf der Grundlage bestimmter Entfernungsmetriken zur Messung der Ähnlichkeit zu filtern. Bei `HASH` Indizes sollte das Feld den gesamten Vektor enthalten, der im Binärformat codiert ist (Little-Endian IEEE 754). Bei `JSON` Schlüsseln sollte der Pfad auf ein mit Zahlen gefülltes Array der richtigen Größe verweisen. Beachten Sie, dass bei der Verwendung eines JSON-Arrays als Vektorfeld die interne Darstellung des Arrays innerhalb des JSON-Schlüssels in das für den ausgewählten Algorithmus erforderliche Format konvertiert wird, wodurch der Speicherverbrauch und die Genauigkeit reduziert werden. Nachfolgende Lesevorgänge mit den JSON-Befehlen ergeben den reduzierten Genauigkeitswert.
+ **Zahlenfelder** enthalten eine einzelne Zahl. Zahlenfelder können mit dem Bereichs-Suchoperator verwendet werden. Denn es wird erwartet`HASH`, dass das Feld den ASCII-Text einer Zahl enthält, die im Standardformat von Fest- oder Gleitkommazahlen geschrieben ist. Bei `JSON` Feldern müssen die numerischen Regeln für JSON-Zahlen befolgt werden. Unabhängig von der Darstellung innerhalb des Schlüssels wird dieses Feld zur Speicherung im Index in eine 64-Bit-Fließkommazahl umgewandelt. Da die zugrunde liegenden Zahlen aufgrund ihrer Genauigkeitseinschränkungen in Fließkommazahlen gespeichert werden, gelten die üblichen Regeln für numerische Vergleiche für Fließkommazahlen.
+ **Tag-Felder** enthalten null oder mehr Tag-Werte, die als einzelne UTF-8-Zeichenfolge codiert sind. Tag-Felder können verwendet werden, um Abfragen nach der Äquivalenz von Tag-Werten zu filtern, wobei entweder Groß- und Kleinschreibung beachtet wird oder nicht. Die Zeichenfolge wird mithilfe eines Trennzeichens (Standard ist ein Komma, kann aber überschrieben werden) in Tagwerte zerlegt, wobei führende und nachfolgende Leerzeichen entfernt werden. In einem einzigen Tag-Feld können beliebig viele Tag-Werte enthalten sein.
## Vektor-Index-Algorithmen
Zwei Vektorindex-Algorithmen werden in Valkey unterstützt:
+ **Flat** — Der Flat-Algorithmus ist eine lineare Brute-Force-Verarbeitung aller Vektoren im Index, die exakte Antworten innerhalb der Grenzen der Genauigkeit der Entfernungsberechnungen liefert. Aufgrund der linearen Verarbeitung des Index können die Laufzeiten für diesen Algorithmus bei großen Indizes sehr hoch sein. Flache Indizes unterstützen höhere Aufnahmegeschwindigkeiten.
+ **Hierarchical Navigable Small Worlds (HNSW)** — Der HNSW-Algorithmus ist eine Alternative, bei der annähernd engste Vektorübereinstimmungen im Austausch für wesentlich kürzere Ausführungszeiten bereitgestellt werden. Der Algorithmus wird durch drei Parameter gesteuert, und. `M` `EF_CONSTRUCTION` `EF_RUNTIME` Die ersten beiden Parameter werden bei der Indexerstellung angegeben und können nicht geändert werden. Der `EF_RUNTIME` Parameter hat einen Standardwert, der bei der Indexerstellung angegeben wird, aber danach bei jedem einzelnen Abfragevorgang überschrieben werden kann. Diese drei Parameter wirken zusammen, um den Speicher- und CPU-Verbrauch bei Aufnahme- und Abfragevorgängen auszugleichen und die Qualität der Annäherung an eine exakte KNN-Suche (bekannt als Recall-Ratio) zu steuern.
In HNSW steuert der Parameter M die maximale Anzahl von Nachbarn, mit denen jeder Knoten eine Verbindung herstellen kann, wodurch die Indexdichte bestimmt wird. Ein höherer Wert von M, z. B. 32 und höher, führt zu einem stärker vernetzten Graphen, wodurch die Abruf- und Abfragegeschwindigkeit verbessert wird, da mehr Pfade existieren, um relevante Nachbarn zu erreichen. Es erhöht jedoch die Indexgröße und den Speicherverbrauch und verlangsamt die Indizierung. Ein niedrigeres M, z. B. 8 und weniger, ergibt einen kleineren faster-to-build Index mit geringerer Speicherbelegung, aber der Abruf nimmt ab und Abfragen können aufgrund weniger Verbindungen länger dauern.
Der Parameter EF\$1Construction bestimmt, wie viele mögliche Verbindungen bei der Indexerstellung ausgewertet werden. Ein höherer Wert von EF\$1Construction, z. B. 400 und höher, bedeutet, dass der Indexer mehr Pfade berücksichtigt, bevor er Nachbarn auswählt. Dies führt zu einem Diagramm, das später sowohl die Abruf- als auch die Abfrageeffizienz verbessert, jedoch auf Kosten einer langsameren Indizierung und einer höheren CPU- und Speicherauslastung während der Konstruktion. Eine niedrige EF\$1Construction, z. B. 64-120, beschleunigt die Indizierung und reduziert den Ressourcenverbrauch, aber das resultierende Diagramm kann die Anzahl der Rückrufaktionen reduzieren und Abfragen verlangsamen, selbst wenn EF\$1Runtime auf einen hohen Wert eingestellt ist.
Schließlich bestimmt EF\$1Runtime den Umfang der Suche während der Abfrage und steuert, wie viele Nachbarkandidaten zur Laufzeit untersucht werden. Ein hoher Wert erhöht den Abruf und die Genauigkeit, geht jedoch auf Kosten der Abfragelatenz und der CPU-Auslastung. Ein niedriger Wert für EF\$1Runtime macht Abfragen schneller und einfacher, allerdings mit geringerem Abruf. Im Gegensatz zu M oder EF\$1Construction hat dieser Parameter keinen Einfluss auf die Indexgröße oder die Erstellungszeit, sodass er der Parameter ist, mit dem die Kompromisse zwischen Abruf und Latenz nach der Indexerstellung abgestimmt werden können.
Beide Vektorsuchalgorithmen (Flat und HNSW) unterstützen einen optionalen Parameter. `INITIAL_CAP` Wenn dieser Parameter angegeben ist, weist er den Indizes vorab Speicher zu, was zu einem geringeren Speicherverwaltungsaufwand und höheren Vektoraufnahmeraten führt. Flache Indizes unterstützen bessere Aufnahmegeschwindigkeiten als HNSW.
Vektorsuchalgorithmen wie HNSW können das Löschen oder Überschreiben zuvor eingefügter Vektoren möglicherweise nicht effizient handhaben. Die Verwendung dieser Operationen kann zu einem übermäßigen Index-Speicherverbrauch und einer and/or Verschlechterung der Abrufqualität führen. Die Neuindizierung ist eine Methode zur Wiederherstellung einer optimalen Speicherauslastung beim Abrufen. and/or
## Sicherheit bei der Vektorsuche
Die Sicherheitsmechanismen von [Valkey ACL (Access Control Lists)](https://valkey.io/topics/acl/) sowohl für den Befehls- als auch für den Datenzugriff wurden erweitert, um die Suchfunktion zu kontrollieren. Die ACL-Steuerung einzelner Suchbefehle wird vollständig unterstützt. Eine neue ACL-Kategorie`@search`,, wird bereitgestellt, und viele der vorhandenen Kategorien (`@fast``@read`,`@write`, usw.) wurden aktualisiert, um die neuen Befehle aufzunehmen. Suchbefehle ändern keine Schlüsseldaten, was bedeutet, dass die bestehende ACL-Maschinerie für den Schreibzugriff erhalten bleibt. Die Zugriffsregeln für `HASH` und `JSON` Operationen werden durch das Vorhandensein eines Indexes nicht verändert; auf diese Befehle wird weiterhin die normale Zugriffskontrolle auf Schlüsselebene angewendet.
Der Zugriff auf Suchbefehle mit einem Index wird ebenfalls über ACL gesteuert. Zugriffsprüfungen werden auf der Ebene des gesamten Indexes durchgeführt, nicht auf der Ebene einzelner Schlüssel. Das bedeutet, dass einem Benutzer nur dann Zugriff auf einen Index gewährt wird, wenn dieser Benutzer berechtigt ist, auf alle möglichen Schlüssel in der Schlüsselraumpräfixliste dieses Indexes zuzugreifen. Mit anderen Worten, der tatsächliche Inhalt eines Indexes steuert den Zugriff nicht. Vielmehr ist es der theoretische Inhalt eines Indexes, wie er in der Präfixliste definiert ist, der für die Sicherheitsüberprüfung verwendet wird. Situationen, in denen ein Benutzer Lese- und and/or Schreibzugriff auf einen Schlüssel hat, aber nicht auf einen Index zugreifen kann, der diesen Schlüssel enthält, sind möglich. Beachten Sie, dass nur Lesezugriff auf den Schlüsselraum erforderlich ist, um einen Index zu erstellen oder zu verwenden. Das Vorhandensein oder Fehlen von Schreibzugriff wird nicht berücksichtigt.
# Funktionen und Grenzen der Vektorsuche
## Verfügbarkeit der Vektorsuche
Die Vektorsuche für Amazon ElastiCache ist mit Valkey Version 8.2 auf knotenbasierten Clustern in allen AWS Regionen ohne zusätzliche Kosten verfügbar. [Sie können die Vektorsuche auch für Ihre vorhandenen Cluster verwenden, indem Sie mit wenigen Klicks und ohne Ausfallzeiten von einer beliebigen Version von Valkey oder Redis OSS auf Valkey 8.2 aktualisieren.](VersionManagement.HowTo.md)
Die Vektorsuche ist derzeit für alle ElastiCache Instance-Typen mit Ausnahme von Knoten mit Daten-Tiering verfügbar. Die Verwendung der Vektorsuche auf T2-, T3- und T4G-Instances erfordert eine Erhöhung der Speicherreserve auf mindestens 50% für Mikro- und 30% für kleine Instances. Weitere Informationen finden Sie auf [dieser Seite](redis-memory-management.md).
## Parametrische Einschränkungen
Die folgende Tabelle zeigt Grenzwerte für verschiedene Vektor-Suchelemente:
**Grenzwerte für die Vektorsuche**
| Item | Maximaler Wert |
| --- | --- |
| Anzahl der Dimensionen in einem Vektor | 32768 |
| Anzahl der Indizes, die erstellt werden können | 10 |
| Anzahl der Felder in einem Index | 50 |
| FT.SEARCH TIMEOUT-Klausel (Millisekunden) | 60000 |
| Maximal zulässige Anzahl von Präfixen pro Index | 16 |
| Maximale Länge eines Tag-Felds | 10000 |
| Maximale Länge eines numerischen Feldes | 256 |
| HNSW M-Parameter | 2000000 |
| HNSW EF\$1KONSTRUKTIONSPARAMETER | 4096 |
| HNSW EF\$1RUNTIME-Parameter | 4096 |
## Betriebseinschränkungen
### Persistenz und Backfilling von Indizes
Der Aktualisierungsvorgang besteht aus drei Schritten. Im ersten Schritt wird der HASH- oder JSON-Schlüssel geändert und der anfragende Client wird blockiert. Der zweite Schritt wird im Hintergrund ausgeführt und aktualisiert jeden der Indizes, die den geänderten Schlüssel enthalten. Im dritten Schritt wird der Client entsperrt. Bei Abfrageoperationen, die auf derselben Verbindung wie eine Mutation ausgeführt werden, ist diese Änderung also sofort in den Suchergebnissen sichtbar. Das Einfügen oder Aktualisieren eines Schlüssels ist jedoch möglicherweise für einen kurzen Zeitraum nicht in den Suchergebnissen anderer Clients sichtbar. In Zeiten hoher Systemlast und and/or starker Mutation von Daten kann sich die Sichtbarkeitsverzögerung verlängern.
Die Vektorsuchfunktion behält die Definition von Indizes und den Inhalt der Indizes bei. Indizes für Vektorfelder werden gespeichert, aber die Indizes für TAGS und NUMERIC werden nicht gespeichert, was bedeutet, dass sie neu erstellt werden müssen, wenn sie extern geladen werden (vollständige Synchronisierung oder Neuladen). Das bedeutet, dass bei jeder Betriebsanfrage oder jedem Ereignis, das zum Starten oder Neustarten eines Knotens führt, die Indexdefinition und der Inhalt für Vektoren aus dem letzten Snapshot wiederhergestellt werden. Um dies zu initiieren, ist keine Benutzeraktion erforderlich. Bei TAGS- und NUMERIC-Indizes wird die Neuerstellung jedoch als Backfill-Vorgang durchgeführt, sobald die Daten wiederhergestellt sind. Dies entspricht funktionell der automatischen Ausführung eines FT.CREATE-Befehls durch das System für jeden definierten Index. Beachten Sie, dass der Knoten für Anwendungsoperationen verfügbar ist, sobald die Daten wiederhergestellt sind, aber wahrscheinlich bevor das Auffüllen des Index abgeschlossen ist, was bedeutet, dass Backfill-Operationen wieder für Anwendungen sichtbar werden.
Der Abschluss des Index-Backfills wird nicht zwischen einem primären Replikat und einem Replikat synchronisiert. Dieser Mangel an Synchronisation kann für Anwendungen unerwartet sichtbar werden. Es wird daher empfohlen, dass Anwendungen den Abschluss des Backfills für Primärdateien und alle Replikate überprüfen, bevor sie Suchvorgänge einleiten.
### Grenzen der Skalierung
Bei Skalierungsereignissen kann es vorkommen, dass der Index bei der Migration von Daten wieder aufgefüllt wird. Dies führt zu einem geringeren Abruf von Suchanfragen.
### Snapshot import/export und Live-Migration
Die RDB-Dateien aus dem einen Cluster mit Suchindizes können in einen anderen ElastiCache Valkey-Cluster mit Version 8.2 oder höher importiert werden. Der neue Cluster wird den Indexinhalt beim Laden der RDB-Datei neu erstellen. Das Vorhandensein von Suchindizes in einer RDB-Datei schränkt jedoch die Kompatibilität dieser Daten mit früheren Versionen von Valkey ein. Das durch die Vektorsuchfunktion definierte Format der Suchindizes wird nur von einem anderen ElastiCache Cluster mit Valkey-Version 8.2 oder höher verstanden. RDB-Dateien, die keine Indizes enthalten, sind auf diese Weise jedoch nicht eingeschränkt.
### Beim Auffüllen ist nicht genügend Arbeitsspeicher verfügbar
Ähnlich wie bei Valkey-OSS-Schreiboperationen unterliegt ein Index-Backfill Einschränkungen. out-of-memory Wenn der Engine-Speicher voll ist, während ein Backfill läuft, werden alle Backfills angehalten. Wenn Speicher verfügbar wird, wird der Backfill-Vorgang wieder aufgenommen. Es ist möglich, einen Index zu löschen, wenn das Auffüllen aufgrund von Speichermangel unterbrochen wird.
### Transaktionen
Die Befehle`FT.CREATE`,, `FT.DROPINDEX` `FT.ALIASADD``FT.ALIASDEL`, und `FT.ALIASUPDATE` können nicht in einem Transaktionskontext ausgeführt werden, d. h. nicht innerhalb eines `MULTI/EXEC` Blocks oder innerhalb eines LUA- oder FUNCTION-Skripts.
# Auswahl der geeigneten Konfiguration
In der Konsolenumgebung können ElastiCache Sie auf einfache Weise den richtigen Instance-Typ auswählen, der auf den Speicher- und CPU-Anforderungen Ihres Vektor-Workloads basiert.
## Speicherverbrauch
Der Speicherverbrauch basiert auf der Anzahl der Vektoren, der Anzahl der Dimensionen, dem M-Wert und der Menge der Nicht-Vektordaten, z. B. Metadaten, die dem Vektor zugeordnet sind, oder auf anderen in der Instanz gespeicherten Daten. Der Gesamtspeicherbedarf ist eine Kombination aus dem für die eigentlichen Vektordaten benötigten Speicherplatz und dem für die Vektorindizes benötigten Speicherplatz. Der für Vektordaten benötigte Speicherplatz wird berechnet, indem die tatsächliche Kapazität gemessen wird, die für die Speicherung von Vektoren in unseren `HASH` `JSON` Datenstrukturen erforderlich ist, und der Overhead bis zu den nächstgelegenen Speicherplatten, um optimale Speicherzuweisungen zu erzielen. Jeder der Vektorindizes verwendet Verweise auf die in diesen Datenstrukturen gespeicherten Vektordaten sowie eine zusätzliche Kopie des Vektors im Index. Es wird empfohlen, diesen zusätzlichen Speicherverbrauch im Index einzuplanen.
Die Anzahl der Vektoren hängt davon ab, wie Sie Ihre Daten als Vektoren darstellen möchten. Sie können beispielsweise festlegen, dass ein einzelnes Dokument in mehreren Abschnitten dargestellt wird, wobei jeder Abschnitt einen Vektor darstellt. Sie können sich auch dafür entscheiden, das gesamte Dokument als einen einzigen Vektor darzustellen. Die Anzahl der Dimensionen Ihrer Vektoren hängt vom ausgewählten Einbettungsmodell ab. Wenn Sie sich beispielsweise für das AWS Titan-Einbettungsmodell entscheiden, beträgt die Anzahl der Dimensionen 1536. Beachten Sie, dass Sie den Instance-Typ testen sollten, um sicherzustellen, dass er Ihren Anforderungen entspricht.
## Skalieren Sie Ihren Workload
Die Vektorsuche unterstützt alle drei Skalierungsmethoden: horizontal, vertikal und Replikate. Bei der Kapazitätsskalierung verhält sich die Vektorsuche genauso wie normales Valkey, d. h. die Erhöhung des Speichers einzelner Knoten (vertikale Skalierung) oder die Erhöhung der Anzahl der Knoten (horizontale Skalierung) erhöht die Gesamtkapazität. Im Clustermodus kann der `FT.CREATE` Befehl an jeden primären Knoten des Clusters gesendet werden, und das System verteilt die neue Indexdefinition automatisch an alle Clustermitglieder.
Aus Sicht der Leistung verhält sich die Vektorsuche jedoch ganz anders als das reguläre Valkey. Die Multithread-Implementierung der Vektorsuche bedeutet zusätzliche CPUs Erträge bis hin zu linearen Steigerungen sowohl des Abfrage- als auch des Aufnahmedurchsatzes. Die horizontale Skalierung führt zu einer linearen Erhöhung des Aufnahmedurchsatzes, kann jedoch den Abfragedurchsatz verringern. Wenn zusätzlicher Abfragedurchsatz erforderlich ist, ist eine Skalierung durch Replikate oder zusätzliche CPUs Daten erforderlich.
# Befehle für die Vektorsuche
Im Folgenden finden Sie eine Liste der unterstützten Befehle für die Vektorsuche.
**Topics**
+ [FT.CREATE](vector-search-commands-ft.create.md)
+ [FT.SEARCH](vector-search-commands-ft.search.md)
+ [FT.DROPINDEX](vector-search-commands-ft.dropindex.md)
+ [FT.INFO](vector-search-commands-ft.info.md)
+ [FT. \$1LISTE](vector-search-commands-ft.list.md)
# FT.CREATE
Der `FT.CREATE` Befehl erstellt einen leeren Index und leitet den Backfill-Prozess ein. Jeder Index besteht aus einer Reihe von Felddefinitionen. Jede Felddefinition gibt einen Feldnamen, einen Feldtyp und einen Pfad innerhalb jedes indizierten Schlüssels an, um einen Wert des deklarierten Typs zu finden. Einige Feldtypdefinitionen haben zusätzliche Untertypbezeichner.
Bei Indizes für HASH-Schlüssel ist der Pfad derselbe wie der Name des Hash-Elements. Die optionale `AS` Klausel kann verwendet werden, um das Feld auf Wunsch umzubenennen. Das Umbenennen von Feldern ist besonders nützlich, wenn der Elementname Sonderzeichen enthält.
Bei Indizes für JSON-Schlüssel ist der Pfad ein JSON-Pfad zu den Daten des deklarierten Typs. Da der JSON-Pfad immer Sonderzeichen enthält, ist die `AS` Klausel erforderlich.
**Syntax**
```
FT.CREATE
ON HASH | JSON
[PREFIX [...]]
SCHEMA
( [AS ]
| VECTOR [HNSW|FLAT] [])
| TAG [SEPARATOR ] [CASESENSITIVE]
| NUMERIC
)+
```
**(erforderlich):** Dies ist der Name, den Sie Ihrem Index geben. Wenn bereits ein Index mit demselben Namen existiert, wird ein Fehler zurückgegeben.
**ON HASH \$1 JSON (optional):** Nur Schlüssel, die dem angegebenen Typ entsprechen, sind in diesem Index enthalten. Wenn es weggelassen wird, wird HASH angenommen.
**PREFIX (optional):** Wenn diese Klausel angegeben ist, werden nur Schlüssel, die mit denselben Bytes wie eines oder mehrere der angegebenen Präfixe beginnen, in diesen Index aufgenommen. Wenn diese Klausel weggelassen wird, werden alle Schlüssel des richtigen Typs eingeschlossen. Ein Präfix mit der Länge Null würde auch allen Schlüsseln des richtigen Typs entsprechen.
**Feldtypen:**
+ TAG: Ein Tag-Feld ist eine Zeichenfolge, die einen oder mehrere Tag-Werte enthält.
+ SEPARATOR (optional): Eines der Zeichen, die zur Abgrenzung einzelner Tags `,.<>{}[]"':;!@#$%^&*()-+=~` verwendet werden. Wenn es weggelassen wird, ist `,` der Standardwert.
+ CASESENSITIVE (optional): Falls vorhanden, wird bei Tag-Vergleichen zwischen Groß- und Kleinschreibung unterschieden. Standardmäßig wird bei Tag-Vergleichen NICHT zwischen Groß- und Kleinschreibung unterschieden.
+ NUMERISCH: Ein numerisches Feld enthält eine Zahl.
+ VEKTOR: Ein Vektorfeld enthält einen Vektor. Derzeit werden zwei Algorithmen zur Vektorindizierung unterstützt: HNSW (Hierarchical Navigable Small World) und FLAT (Brute Force). Jeder Algorithmus hat eine Reihe zusätzlicher Attribute, von denen einige erforderlich und andere optional sind.
+ FLAT: Der Flat-Algorithmus liefert exakte Antworten, hat jedoch eine Laufzeit, die proportional zur Anzahl der indizierten Vektoren ist, und ist daher möglicherweise nicht für große Datensätze geeignet.
+ DIM (erforderlich): Gibt die Anzahl der Dimensionen in einem Vektor an.
+ TYPE FLOAT32 (erforderlich): Datentyp, FLOAT32 wird derzeit nur unterstützt.
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (erforderlich): Gibt den Entfernungsalgorithmus an.
+ INITIAL\$1CAP (optional): Anfängliche Indexgröße.
+ HNSW: Der HNSW-Algorithmus liefert ungefähre Antworten, arbeitet aber wesentlich schneller als FLAT.
+ DIM (erforderlich): Gibt die Anzahl der Dimensionen in einem Vektor an.
+ TYPE FLOAT32 (erforderlich): Datentyp, FLOAT32 wird derzeit nur unterstützt.
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (erforderlich): Gibt den Entfernungsalgorithmus an.
+ INITIAL\$1CAP (optional): Anfängliche Indexgröße.
+ M (optional): Anzahl der maximal zulässigen ausgehenden Kanten für jeden Knoten im Diagramm in jeder Ebene. Auf Ebene Null beträgt die maximale Anzahl ausgehender Kanten 2\$1M. Der Standardwert ist 16, das Maximum ist 512.
+ EF\$1CONSTRUCTION (optional): Steuert die Anzahl der Vektoren, die bei der Indexkonstruktion untersucht werden. Höhere Werte für diesen Parameter verbessern die Abrufrate auf Kosten längerer Indexerstellungszeiten. Der Standardwert ist 200. Der Höchstwert ist 4096.
+ EF\$1RUNTIME (optional): Steuert die Anzahl der Vektoren, die während eines Abfragevorgangs untersucht werden sollen. Der Standardwert ist 10 und der Höchstwert ist 4096. Sie können diesen Parameterwert für jede Abfrage festlegen, die Sie ausführen. Höhere Werte verlängern die Abfragezeit, verbessern jedoch den Abfrageabruf.
**ANTWORT:** OK oder Fehler.
# FT.SEARCH
Führt eine Suche im angegebenen Index durch. Die Schlüssel, die dem Abfrageausdruck entsprechen, werden zurückgegeben.
```
FT.SEARCH
[NOCONTENT]
[RETURN ( [AS ])+]
[TIMEOUT timeout]
[PARAMS []]
[LIMIT ]
```
+ (erforderlich): Dieser Indexname, den Sie abfragen möchten.
+ (erforderlich): Die Abfragezeichenfolge, Einzelheiten finden Sie unten.
+ NOCONTENT (optional): Falls vorhanden, werden nur die resultierenden Schlüsselnamen zurückgegeben, keine Schlüsselwerte sind enthalten.
+ TIMEOUT (optional): Ermöglicht das Festlegen eines Timeout-Werts für den Suchbefehl. Dies muss eine Ganzzahl in Millisekunden sein.
+ PARAMETER... (optional): `count` entspricht der Anzahl der Argumente, d. h. der doppelten Anzahl von Wertenamenpaaren. Einzelheiten zur Verwendung finden Sie in der Abfragezeichenfolge.
+ RÜCKKEHR ... (optional): Anzahl ist die Anzahl der Felder, die zurückgegeben werden sollen. Gibt die Felder an, die Sie aus Ihren Dokumenten abrufen möchten, zusammen mit allen Aliasnamen für die zurückgegebenen Werte. Standardmäßig werden alle Felder zurückgegeben, es sei denn, die Option NOCONTENT ist gesetzt. In diesem Fall werden keine Felder zurückgegeben. Wenn count auf 0 gesetzt ist, verhält es sich genauso wie NOCONTENT.
+ LIMIT: : Ermöglicht es Ihnen, einen Teil des Ergebnisses auszuwählen. Die ersten Schlüssel werden übersprungen und nur ein Maximum an Schlüsseln ist enthalten. Die Standardeinstellung ist LIMIT 0 10, wodurch maximal 10 Schlüssel zurückgegeben werden.
+ PARAMS: Zweimal so viele Schlüssel-Wert-Paare. Auf key/value Parameterpaare kann innerhalb des Abfrageausdrucks verwiesen werden. Weitere Informationen finden Sie unter [Abfrageausdruck für die Vektorsuche](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).
+ DIALEKT: (optional): Gibt Ihren Dialekt an. Der einzige unterstützte Dialekt ist 2.
**ANTWORT**
Der Befehl gibt bei Erfolg entweder ein Array oder einen Fehler zurück.
Bei Erfolg steht der erste Eintrag im Antwort-Array für die Anzahl der passenden Schlüssel, gefolgt von einem Array-Eintrag für jeden passenden Schlüssel. Beachten Sie, dass die angegebene `LIMIT` Option nur die Anzahl der zurückgegebenen Schlüssel steuert und den Wert des ersten Eintrags nicht beeinflusst.
Wenn `NOCONTENT` angegeben, enthält jeder Eintrag in der Antwort nur den passenden Schlüsselnamen. Andernfalls enthält jeder Eintrag den passenden Schlüsselnamen, gefolgt von einem Array der zurückgegebenen Felder. Die Ergebnisfelder für einen Schlüssel bestehen aus einer Reihe von name/value Paaren. Das erste name/value Paar steht für die berechnete Entfernung. Der Name dieses Paares wird aus dem Vektorfeldnamen gebildet, dem „\$1\$1“ vorangestellt und „\$1score“ angehängt wird. Der Wert entspricht der berechneten Entfernung. Die verbleibenden name/value Paare sind die Elemente und Werte des Schlüssels, der durch die Klausel gesteuert wird. `RETURN`
Die Abfragezeichenfolge entspricht dieser Syntax:
```
=>[ KNN @ $ ]
```
Wobei Folgendes gilt:
+ : Ist entweder ein\$1 oder ein Filterausdruck. Ein \$1 bedeutet, dass keine Filterung erfolgt und somit alle Vektoren innerhalb des Index durchsucht werden. Ein Filterausdruck kann angegeben werden, um eine Teilmenge der zu durchsuchenden Vektoren zu bezeichnen.
+ : Der Name eines Vektorfeldes innerhalb des angegebenen Index.
+ : Die Anzahl der Vektoren mit den nächsten Nachbarn, die zurückgegeben werden sollen.
+ : Ein PARAM-Name, dessen entsprechender Wert den Abfragevektor für den KNN-Algorithmus bereitstellt. Beachten Sie, dass dieser Parameter als binäre 32-Bit-Gleitkommazahl nach IEEE 754 im Little-Endian-Format codiert werden muss.
+ : (Optional) Eine Liste von keyword/value Paaren, die diese spezielle KNN-Suche modifizieren. Derzeit werden zwei Schlüsselwörter unterstützt:
+ EF\$1RUNTIME: Dieses Schlüsselwort wird von einem Integer-Wert begleitet, der den Standardwert von EF\$1RUNTIME überschreibt, der bei der Indexerstellung angegeben wurde.
+ AS: Dieses Schlüsselwort wird von einem Zeichenkettenwert begleitet, der im Ergebnis zum Namen des Bewertungsfeldes wird und den Standardalgorithmus zur Generierung von Score-Feldnamen überschreibt.
**Ausdruck filtern**
Ein Filterausdruck besteht aus einer logischen Kombination von Tag-Suchoperatoren und numerischen Suchoperatoren, die in Klammern stehen.
**Markierung**
Der Tag-Suchoperator wird mit einer oder mehreren Zeichenfolgen angegeben, die durch das Zeichen \$1 getrennt sind. Ein Schlüssel entspricht dem Tag-Suchoperator, wenn das angegebene Feld eine der angegebenen Zeichenketten enthält.
```
@:{}
or
@:{ | }
or
@:{ | | ...}
```
Die folgende Abfrage gibt beispielsweise Dokumente mit blauer ODER schwarzer ODER grüner Farbe zurück.
`@color:{blue | black | green}`
Als weiteres Beispiel gibt die folgende Abfrage Dokumente zurück, die „Hello World“ oder „Hello Universe“ enthalten.
`@description:{hello world | hello universe}`
**Numerischer Bereich**
Der numerische Bereichsoperator ermöglicht das Filtern von Abfragen, sodass nur Werte zurückgegeben werden, die zwischen einem bestimmten Start- und Endwert liegen. Sowohl inklusive als auch exklusive Bereichsabfragen werden unterstützt. Für einfache relationale Vergleiche kann \$1inf, -inf mit einer Bereichsabfrage verwendet werden. Die Syntax für einen Bereichssuchoperator lautet:
```
@:[ [(] [(] ]
```
... wobei entweder eine Zahl oder \$1inf oder -inf ist. Grenzen ohne eine führende offene Klammer sind inklusiv, wohingegen Grenzen mit der führenden offenen Klammer exklusiv sind.
Verwenden Sie die folgende Tabelle als Leitfaden für die Zuordnung mathematischer Ausdrücke zu Filterabfragen:
```
min <= field <= max @field:[min max]
min < field <= max @field:[(min max]
min <= field < max @field:[min (max]
min < field < max @field:[(min (max]
field >= min @field:[min +inf]
field > min @field:[(min +inf]
field <= max @field:[-inf max]
field < max @field:[-inf (max]
field == val @field:[val val]
```
**Logische Operatoren**
Mehrere Tags und numerische Suchoperatoren können verwendet werden, um komplexe Abfragen mithilfe logischer Operatoren zu erstellen.
**Logisches UND**
Um ein logisches UND festzulegen, verwenden Sie ein Leerzeichen zwischen den Prädikaten. Beispiel:
`query1 query2 query3`
**Logisches ODER**
Um ein logisches ODER festzulegen, verwenden Sie ein Leerzeichen zwischen den Prädikaten. Beispiel:
`query1 | query2 | query3`
**Logische Negation**
Jede Abfrage kann negiert werden, indem das `-` Zeichen vor jeder Abfrage vorangestellt wird. Negative Abfragen geben alle Einträge zurück, die nicht mit der Abfrage übereinstimmen. Dies schließt auch Schlüssel ein, die das Feld nicht enthalten.
Eine negative Abfrage auf @genre: \$1comedy\$1 gibt beispielsweise alle Bücher zurück, die keine Komödie sind UND alle Bücher, die kein Genrefeld haben.
Die folgende Abfrage gibt alle Bücher des Genres „Komödie“ zurück, die nicht zwischen 2015 und 2024 veröffentlicht wurden oder die kein Jahresfeld haben: @genre: [Komödie] - @year: [2015 2024]
Rangfolge der Operatoren
Es gelten die typischen Regeln für die Rangfolge von Operatoren, d. h. logisches NEGATE hat die höchste Priorität, gefolgt von logischem UND dann logisches ODER mit der niedrigsten Priorität. Klammern können verwendet werden, um die Standardregeln für die Rangfolge außer Kraft zu setzen.
*Beispiele für die Kombination logischer Operatoren*
Logische Operatoren können zu komplexen Filterausdrücken kombiniert werden.
Die folgende Abfrage gibt alle Bücher mit den Genres „Komödie“ oder „Horror“ (AND) zurück, die zwischen 2015 und 2024 veröffentlicht wurden: `@genre:[comedy|horror] @year:[2015 2024]`
Die folgende Abfrage gibt alle Bücher mit den Genres „Komödie“ oder „Horror“ (OR) zurück, die zwischen 2015 und 2024 veröffentlicht wurden: `@genre:[comedy|horror] | @year:[2015 2024]`
Die folgende Abfrage gibt alle Bücher zurück, die entweder kein Genrefeld haben oder deren Genrefeld nicht „Komödie“ entspricht und die zwischen 2015 und 2024 veröffentlicht wurden: `-@genre:[comedy] @year:[2015 2024]`
# FT.DROPINDEX
**Syntax**
```
FT.DROPINDEX
```
Der angegebene Index wird gelöscht. Gibt OK oder einen Fehler zurück, wenn dieser Index nicht existiert.
+ (erforderlich): Der Name des zu löschenden Indexes.
# FT.INFO
**Syntax**
```
FT.INFO
```
Die Vektorsuche erweitert den Befehl [FT.INFO](https://valkey.io/commands/info/) um mehrere zusätzliche Abschnitte mit Statistiken und Zählern. Eine Anfrage zum Abrufen des Abschnitts SEARCH ruft alle der folgenden Statistiken ab:
| Tastenname | Werttyp | Description |
| --- | --- | --- |
| index\$1name | Zeichenfolge | Name des Indexes |
| index\$1options | Zeichenfolge | Reserved Instances. Derzeit auf „0" gesetzt |
| index\$1definition | Array | Im Folgenden finden Sie die Definition dieser Array-Elemente. |
| Attribute | Array von Attributinformationen | Ein Element in diesem Array für jedes definierte Attribut. Die Definition der Attributinformationen finden Sie weiter unten. |
| num\$1docs | Ganzzahl | Anzahl der aktuell im Index enthaltenen Schlüssel |
| num\$1terms | Ganzzahl | Reserved Instances. Derzeit auf „0" gesetzt. |
| record\$1count | Ganzzahl | Die Summe des Felds „Größe“ für jedes Attribut. |
| hash\$1indexing\$1failures | Ganzzahl | Gibt an, wie oft ein Attribut nicht in den deklarierten Attributtyp konvertiert werden konnte. Trotz des Namens gilt dies auch für JSON-Schlüssel. |
| backfill\$1in\$1progress | Ganzzahl | Wenn gerade ein Backfill im Gange ist, wird dies eine '1' sein, andernfalls ist es eine '0' |
| backfill\$1percent\$1complete | float | Schätzung des Abschlusses des Füllstands, eine Bruchzahl im Bereich [0.. 1] |
| mutation\$1queue\$1size | Ganzzahl | Anzahl der Schlüssel, die darauf warten, den Index zu aktualisieren. |
| recent\$1mutations\$1queue\$1delay | Ganzzahl | Schätzung der Verzögerung (in Sekunden) der Indexaktualisierung. 0, wenn keine Aktualisierungen im Gange sind. |
| state | Zeichenfolge | Backfill-Status: „Bereit“ gibt an, dass das Auffüllen erfolgreich abgeschlossen wurde. „backfill\$1in\$1progress“ gibt an, dass das Auffüllen fortgesetzt wird. „backfill\$1paused\$1by\$1oom“ bedeutet, dass das Backfilling aufgrund eines unzureichenden Speicherzustands unterbrochen wurde. Sobald der Speichermangel behoben ist, wird der Backillvorgang fortgesetzt. |
Die Struktur index\$1definition ist ein Array von key/value Paaren, die wie folgt definiert sind:
| Tastenname | Werttyp | Description |
| --- | --- | --- |
| key\$1type | Zeichenfolge | Entweder die Zeichenfolge 'JSON' oder die Zeichenfolge 'HASH' |
| prefixes | Array | Jedes Element im Array ist ein definiertes Präfix für den Index. Wenn bei der Erstellung des Indexes keine Präfixe angegeben wurden, hat dieses Array 0 Einträge. |
| default\$1score | Zeichenfolge | Reserved Instances. Derzeit auf „1" eingestellt |
Attributinformationen: Die Attributinformationen sind typspezifisch.
Numerische Attribute:
| Key (Schlüssel) | Werttyp | Description |
| --- | --- | --- |
| Bezeichner | Zeichenfolge | Position des Attributs innerhalb eines Schlüssels. Hash-Mitgliedsname oder JSON-Pfad |
| alias | Zeichenfolge | Name des Attributs, das in Abfragebeschreibungen verwendet wird. |
| type | Zeichenfolge | Die Zeichenfolge „NUMERIC“ |
| size | Ganzzahl | Die Anzahl der Schlüssel mit gültigen numerischen Werten in diesem Attribut. |
Tag-Attribute:
| Tastenname | Werttyp | Description |
| --- | --- | --- |
| Bezeichner | Zeichenfolge | Position des Attributs innerhalb eines Schlüssels. Hash-Mitgliedsname oder JSON-Pfad |
| alias | Zeichenfolge | Name des Attributs, das in Abfragebeschreibungen verwendet wird. |
| type | Zeichenfolge | Die Zeichenfolge „TAG“ |
| SEPARATOR | character | Das Trennzeichen, das bei der Erstellung des Indexes definiert wurde |
| GROSS- UND KLEINSCHREIBUNG BEACHTEN | – | Diesem Schlüssel ist kein Wert zugeordnet. Es ist nur vorhanden, wenn das Attribut mit dieser Option erstellt wurde. |
| size | Ganzzahl | Die Anzahl der Schlüssel mit gültigen Tag-Werten in diesem Attribut |
Vektor-Attribute:
| Tastenname | Werttyp | Description |
| --- | --- | --- |
| Bezeichner | Zeichenfolge | Position des Attributs innerhalb eines Schlüssels. Hash-Mitgliedsname oder JSON-Pfad |
| alias | Zeichenfolge | Name des Attributs, das in Abfragebeschreibungen verwendet wird. |
| type | Zeichenfolge | Die Zeichenfolge „VECTOR“ |
| index | character | Eine weitere Beschreibung des Vektorindex finden Sie unten. |
Beschreibung des Vektorindex:
| Tastenname | Werttyp | Description |
| --- | --- | --- |
| Kapazität | Zeichenfolge | Aktuelle Kapazität des Index |
| dimensions | Zeichenfolge | Anzahl der Elemente in jedem Vektor |
| distance\$1metric | Zeichenfolge | Einer von „COSINE“, „L2" oder „IP“ |
| size | Array | Beschreibung des Vektorindex, siehe unten. |
| data\$1type | Zeichenfolge | Deklarierter Datentyp. Derzeit wird nur FLOAT32 "" unterstützt. |
| Algorithmus | Array | Weitere Beschreibung des Vektorsuchalgorithmus. |
FLAT-Vektor-Suchalgorithmus Beschreibung:
| Tastenname | Werttyp | Description |
| --- | --- | --- |
| name | Zeichenfolge | Name des Algorithmus: FLAT |
| block\$1size | number | Größe eines Blocks des FLAT-Index. |
Beschreibung des HNSW-Vektorindexes:
| Tastenname | Werttyp | Description |
| --- | --- | --- |
| name | Zeichenfolge | Name des Algorithmus: HNSW |
| m | number | Der Parameter „M“ für HNSW |
| ef\$1construction | number | Der Parameter „ef\$1construction“ für HNSW |
| ef\$1runtime | number | Der Parameter „ef\$1runtime“ für HNSW. |
# FT. \$1LISTE
Listet alle Indizes auf.
**Syntax**
```
FT._LIST
```
Gibt ein Array von Zeichenketten zurück, die den Namen des aktuell definierten Indexes entsprechen.
# Erste Schritte mit JSON für Valkey und Redis OSS
ElastiCache unterstützt das native JSON-Format ( JavaScript Object Notation), das eine einfache, schemalose Methode zur Kodierung komplexer Datensätze in Valkey- und Redis-OSS-Clustern darstellt. Sie können Daten mithilfe des JSON-Formats ( JavaScript Object Notation) nativ innerhalb der Cluster speichern und darauf zugreifen und die in diesen Clustern gespeicherten JSON-Daten aktualisieren, ohne dass Sie benutzerdefinierten Code für die Serialisierung und Deserialisierung verwalten müssen.
Neben der Verwendung von Valkey- und Redis OSS-API-Operationen für Anwendungen, die über JSON arbeiten, können Sie jetzt auch bestimmte Teile eines JSON-Dokuments effizient abrufen und aktualisieren, ohne das gesamte Objekt bearbeiten zu müssen. Dies kann die Leistung verbessern und Kosten senken. Sie können den Inhalt Ihres JSON-Dokuments auch mit der [Goessner](https://goessner.net/articles/JsonPath/)-Abfrage abfragen.
Nachdem Sie einen Cluster mit einer unterstützten Engine-Version erstellt haben, sind der JSON-Datentyp und die zugehörigen Befehle automatisch verfügbar. API-kompatibel und RDB-kompatibel mit Version 2 des JSON-Moduls, sodass Sie bestehende JSON-basierte Valkey- und Redis OSS-Anwendungen problemlos in diese migrieren können. ElastiCache Weitere Informationen zu den unterstützten Befehlen finden Sie unter. [Unterstützte Valkey- und Redis OSS-BefehleJSON-Befehle](json-list-commands.md)
Die JSON-bezogenen Metriken `JsonBasedCmds` und `JsonBasedCmdsLatency` dienen CloudWatch zur Überwachung der Verwendung dieses Datentyps. Weitere Informationen finden Sie unter [Metriken für Valkey und](CacheMetrics.Redis.md) Redis OSS.
**Anmerkung**
Um JSON verwenden zu können, müssen Sie Valkey 7.2 und höher oder Redis OSS 6.2.6 oder höher ausführen.
**Topics**
+ [Überblick über den JSON-Datentyp](json-document-overview.md)
+ [Unterstützte Valkey- und Redis OSS-Befehle](json-list-commands.md)
# Überblick über den JSON-Datentyp
ElastiCache unterstützt eine Reihe von Valkey- und Redis OSS-Befehlen für die Arbeit mit dem JSON-Datentyp. Im Folgenden finden Sie eine Übersicht über den JSON-Datentyp und eine detaillierte Liste der unterstützten Befehle.
## Terminologie
****
| Begriff | Beschreibung |
| --- | --- |
| JSON-Dokument | Bezieht sich auf den Wert eines JSON-Schlüssels. |
| JSON-Wert | Bezieht sich auf eine Teilmenge eines JSON-Dokuments, einschließlich des Stammverzeichnisses, das das gesamte Dokument darstellt. Ein Wert könnte ein Container oder ein Eintrag innerhalb eines Containers sein. |
| JSON-Element | Äquivalent zu JSON-Wert. |
## Unterstützter JSON-Standard
Das JSON-Format ist mit [RFC 7159](https://www.ietf.org/rfc/rfc7159.txt) und dem [ECMA-404](https://www.ietf.org/rfc/rfc7159.txt)-JSON-Datenaustauschstandard konform. UTF-8 [Unicode](https://www.unicode.org/standard/WhatIsUnicode.html) wird im JSON-Text unterstützt.
## Stammelement
Das Stammelement kann von jedem JSON-Datentyp stammen. Beachten Sie, dass in früheren RFC 4627 nur Objekte oder Arrays als Stammwerte zugelassen waren. Seit dem Update auf RFC 7159 kann das Stammverzeichnis eines JSON-Dokuments einen beliebigen JSON-Datentyp haben.
## Begrenzung der Dokumentgröße
JSON-Dokumente werden intern in einem Format gespeichert, das für schnellen Zugriff und Änderung optimiert ist. Dieses Format führt in der Regel dazu, dass etwas mehr Speicher verbraucht wird als bei der äquivalenten serialisierten Darstellung desselben Dokuments.
Der Speicherverbrauch eines einzelnen JSON-Dokuments ist auf 64 MB begrenzt, was der Größe der In-Memory-Datenstruktur entspricht, nicht der JSON-Zeichenfolge. Sie können mit dem `JSON.DEBUG MEMORY`-Befehl den Speicherplatz überprüfen, der von einem JSON-Dokument verbraucht wird.
## JSON ACLs
+ Ähnlich wie bei den vorhandenen Pro-Datentyp-Kategorien (@string, @hash usw.) wird eine neue Kategorie @json hinzugefügt, um die Verwaltung des Zugriffs auf JSON-Befehle und -Daten zu vereinfachen. Keine anderen vorhandenen Valkey- oder Redis OSS-Befehle gehören zur Kategorie @json. Alle JSON-Befehle erzwingen alle Keyspace- oder Befehlseinschränkungen und -berechtigungen.
+ Es gibt fünf bestehende Valkey- und Redis OSS-ACL-Kategorien, die aktualisiert wurden und nun die neuen JSON-Befehle enthalten: @read, @write, @fast, @slow und @admin. Die folgende Tabelle zeigt die Zuordnung von JSON-Befehlen zu den entsprechenden Kategorien an.
**ACL**
| JSON-Befehl | @read | @write | @fast | @slow | @admin |
| --- | --- | --- | --- | --- | --- |
| JSON.ARRAPPEND | | y | y | | |
| JSON.ARRINDEX | y | | y | | |
| JSON.ARRINSERT | | y | y | | |
| JSON.ARRLEN | y | | y | | |
| JSON.ARRPOP | | y | y | | |
| JSON.ARRTRIM | | y | y | | |
| JSON.CLEAR | | y | y | | |
| JSON.DEBUG | y | | | y | y |
| JSON.DEL | | y | y | | |
| JSON.FORGET | | y | y | | |
| JSON.GET | y | | y | | |
| JSON.MGET | y | | y | | |
| JSON.NUMINCRBY | | y | y | | |
| JSON.NUMMULTBY | | y | y | | |
| JSON.OBJKEYS | y | | y | | |
| JSON.OBJLEN | y | | y | | |
| JSON.RESP | y | | y | | |
| JSON.SET | | y | | y | |
| JSON.STRAPPEND | | y | y | | |
| JSON.STRLEN | y | | y | | |
| JSON.STRLEN | y | | y | | |
| JSON.TOGGLE | | y | y | | |
| JSON.TYPE | y | | y | | |
| JSON.NUMINCRBY | | y | y | | |
## Begrenzung der Verschachtelungstiefe
Wenn ein JSON-Objekt oder Array ein Element hat, das selbst ein anderes JSON-Objekt oder Array ist, wird gesagt, dass dieses innere Objekt oder Array innerhalb des äußeren Objekts oder Arrays „verschachtelt“ wird. Die maximale Verschachtelungstiefe ist 128. Jeder Versuch, ein Dokument zu erstellen, das eine Verschachtelungstiefe von mehr als 128 enthält, wird mit einem Fehler abgelehnt.
## Befehlssyntax
Die meisten Befehle erfordern einen Schlüsselnamen als erstes Argument. Einige Befehle haben auch ein Pfadargument. Das Pfadargument ist standardmäßig das Stammverzeichnis, wenn es optional und nicht im Lieferumfang enthalten ist.
Notation:
+ Erforderliche Argumente sind in spitzen Klammern eingeschlossen. Zum Beispiel:
+ Optionale Argumente werden in eckige Klammern gesetzt. Zum Beispiel: [path]
+ Zusätzliche optionale Argumente sind durch eine Ellipse („...“) gekennzeichnet. Zum Beispiel: [json ...]
## Pfadsyntax
Redis JSON unterstützt zwei Arten von Pfadsyntaxen:
+ **Verbesserte Syntax** — Folgt der von [Goessner](https://goessner.net/articles/JsonPath/) beschriebenen JSONPath Syntax, wie in der folgenden Tabelle dargestellt. Wir haben die Beschreibungen in der Tabelle zur besseren Übersicht neu angeordnet und geändert.
+ **Beschränkte Syntax** – Hat begrenzte Abfragemöglichkeiten.
**Anmerkung**
Die Ergebnisse einiger Befehle sind davon abhängig, welche Art von Pfadsyntax verwendet wird.
Wenn ein Abfragepfad mit „\$1“ beginnt, verwendet er die erweiterte Syntax. Andernfalls wird eine eingeschränkte Syntax verwendet.
**Verbesserte Syntax**
****
| Symbol/Ausdruck | Beschreibung |
| --- | --- |
| \$1 | Das Stammelement. |
| . oder [] | Untergeordneter Operator |
| .. | Rekursiver Abstieg |
| \$1 | Platzhalter Alle Elemente in einem Objekt oder Array. |
| [] | Array-Index-Operator Der Index basiert auf 0. |
| [,] | Union-Operator |
| [start:end:step] | Array-Slice-Operator |
| ?() | Wendet einen Filterausdruck (Skript) auf das aktuelle Array oder Objekt an. |
| () | Filterausdruck |
| @ | Wird in Filterausdrücken verwendet, die zum aktuellen Knoten verweisen, der verarbeitet wird. |
| == | Ist gleich; wird in Filterausdrücken verwendet. |
| \$1= | Ist nicht gleich; wird in Filterausdrücken verwendet. |
| > | Größer als; wird in Filterausdrücken verwendet. |
| >= | Größer als oder gleich; wird in Filterausdrücken verwendet. |
| < | Kleiner als; wird in Filterausdrücken verwendet. |
| <= | Kleiner als oder gleich; wird in Filterausdrücken verwendet. |
| && | Logisches UND; wird verwendet, um mehrere Filterausdrücke zu kombinieren. |
| \$1\$1 | Logisches ODER; wird verwendet, um mehrere Filterausdrücke zu kombinieren. |
**Beispiele**
Die folgenden Beispiele bauen auf den Beispiel-XML-Daten von [Goessner](https://goessner.net/articles/JsonPath/) auf, die wir durch Hinzufügen zusätzlicher Felder geändert haben.
```
{ "store": {
"book": [
{ "category": "reference",
"author": "Nigel Rees",
"title": "Sayings of the Century",
"price": 8.95,
"in-stock": true,
"sold": true
},
{ "category": "fiction",
"author": "Evelyn Waugh",
"title": "Sword of Honour",
"price": 12.99,
"in-stock": false,
"sold": true
},
{ "category": "fiction",
"author": "Herman Melville",
"title": "Moby Dick",
"isbn": "0-553-21311-3",
"price": 8.99,
"in-stock": true,
"sold": false
},
{ "category": "fiction",
"author": "J. R. R. Tolkien",
"title": "The Lord of the Rings",
"isbn": "0-395-19395-8",
"price": 22.99,
"in-stock": false,
"sold": false
}
],
"bicycle": {
"color": "red",
"price": 19.95,
"in-stock": true,
"sold": false
}
}
}
```
****
| Pfad | Beschreibung |
| --- | --- |
| \$1.store.book[\$1].author | Die Autoren aller Bücher im Laden. |
| \$1..author | Alle Autoren |
| \$1.store.\$1 | Alle Mitglieder des Ladens. |
| \$1["store"].\$1 | Alle Mitglieder des Ladens. |
| \$1.store..price | Der Preis von allem im Laden. |
| \$1..\$1 | Alle rekursiven Mitglieder der JSON-Struktu. |
| \$1..book[\$1] | Alle Bücher. |
| \$1..book[0] | Das erste Buch. |
| \$1..book[-1] | Das letzte Buch. |
| \$1..book[0:2] | Die ersten beiden Bücher. |
| \$1..book[0,1] | Die ersten beiden Bücher. |
| \$1..book[0:4] | Bücher von Index 0 bis 3 (Endindex ist nicht inklusive). |
| \$1..book[0:4:2] | Bücher bei Index 0, 2. |
| \$1..book[?(@.isbn)] | Alle Bücher mit einer ISBN-Nummer. |
| \$1..book[?(@.price<10)] | Alle Bücher günstiger als 10 USD. |
| '\$1..book[?(@.price < 10)]' | Alle Bücher günstiger als 10 USD. (Der Pfad muss in Anführungszeichen gesetzt werden, wenn er Leerzeichen enthält.) |
| '\$1..book[?(@["price"] < 10)]' | Alle Bücher günstiger als 10 USD. |
| '\$1..book[?(@.["price"] < 10)]' | Alle Bücher günstiger als 10 USD. |
| \$1..book[?(@.price>=10&&@.price<=100)] | Alle Bücher im Preisbereich von 10 bis 100 USD inklusive. |
| '\$1..book[?(@.price>=10 && @.price<=100)]' | Alle Bücher im Preisbereich von 10 bis 100 USD inklusive. (Der Pfad muss in Anführungszeichen gesetzt werden, wenn er Leerzeichen enthält.) |
| \$1..book[?(@.sold==true\$1\$1@.in-stock==false)] | Alle Bücher verkauft oder ausverkauft. |
| '\$1..book[?(@.sold == true \$1\$1 @.in-stock == false)]' | Alle Bücher verkauft oder ausverkauft. (Der Pfad muss in Anführungszeichen gesetzt werden, wenn er Leerzeichen enthält.) |
| '\$1.store.book[?(@.["category"] == "fiction")]' | Alle Bücher der Kategorie Belletristik. |
| '\$1.store.book[?(@.["category"] \$1= "fiction")]' | Alle Bücher in der Kategorie Sachbücher. |
Zusätzliche Beispiele für Filterausdrücke:
```
127.0.0.1:6379> JSON.SET k1 . '{"books": [{"price":5,"sold":true,"in-stock":true,"title":"foo"}, {"price":15,"sold":false,"title":"abc"}]}'
OK
127.0.0.1:6379> JSON.GET k1 $.books[?(@.price>1&&@.price<20&&@.in-stock)]
"[{\"price\":5,\"sold\":true,\"in-stock\":true,\"title\":\"foo\"}]"
127.0.0.1:6379> JSON.GET k1 '$.books[?(@.price>1 && @.price<20 && @.in-stock)]'
"[{\"price\":5,\"sold\":true,\"in-stock\":true,\"title\":\"foo\"}]"
127.0.0.1:6379> JSON.GET k1 '$.books[?((@.price>1 && @.price<20) && (@.sold==false))]'
"[{\"price\":15,\"sold\":false,\"title\":\"abc\"}]"
127.0.0.1:6379> JSON.GET k1 '$.books[?(@.title == "abc")]'
[{"price":15,"sold":false,"title":"abc"}]
127.0.0.1:6379> JSON.SET k2 . '[1,2,3,4,5]'
127.0.0.1:6379> JSON.GET k2 $.*.[?(@>2)]
"[3,4,5]"
127.0.0.1:6379> JSON.GET k2 '$.*.[?(@ > 2)]'
"[3,4,5]"
127.0.0.1:6379> JSON.SET k3 . '[true,false,true,false,null,1,2,3,4]'
OK
127.0.0.1:6379> JSON.GET k3 $.*.[?(@==true)]
"[true,true]"
127.0.0.1:6379> JSON.GET k3 '$.*.[?(@ == true)]'
"[true,true]"
127.0.0.1:6379> JSON.GET k3 $.*.[?(@>1)]
"[2,3,4]"
127.0.0.1:6379> JSON.GET k3 '$.*.[?(@ > 1)]'
"[2,3,4]"
```
**Beschränkte Syntax**
****
| Symbol/Ausdruck | Beschreibung |
| --- | --- |
| . oder [] | Untergeordneter Operator |
| [] | Array-Index-Operator Der Index basiert auf 0. |
**Beispiele**
****
| Pfad | Beschreibung |
| --- | --- |
| .store.book[0].author | Der Autor des ersten Buches. |
| .store.book[-1].author | Der Autor des letzten Buches. |
| .address.city | Name der Stadt. |
| ["store"]["book"][0]["title"] | Der Titel des ersten Buches. |
| ["store"]["book"][-1]["title"] | Der Titel des letzten Buches. |
**Anmerkung**
Alle [Goessner](https://goessner.net/articles/JsonPath/)-Inhalte, die in dieser Dokumentation erwähnt werden, unterliegen der [Creative-Commons-Lizenz](https://creativecommons.org/licenses/by/2.5/).
## Häufige Fehlerpräfixe
Jede Fehlermeldung hat ein Präfix. Im Folgenden finden Sie eine Liste mit allgemeinen Fehlerpräfixen.
****
| Präfix | Beschreibung |
| --- | --- |
| ERR | Ein allgemeiner Fehler. |
| LIMIT | Ein Fehler, der auftritt, wenn die Größenbeschränkung überschritten wird. Zum Beispiel wurde die Größenbeschränkung oder Verschachtelungstiefe überschritten. |
| NONEXISTENT | Ein Schlüssel oder Pfad ist nicht vorhanden. |
| OUTOFBOUNDARIES | Array-Index außerhalb des gültigen Bereichs. |
| SYNTAXERR | Syntaxfehler |
| WRONGTYPE | Falscher Werttyp. |
## JSON-verwandte Metriken
Die folgenden JSON-Infometriken werden bereitgestellt:
****
| Informationen | Beschreibung |
| --- | --- |
| json\$1total\$1memory\$1bytes | JSON-Objekten zugewiesener Gesamtspeicher |
| json\$1num\$1documents | Gesamtzahl der Dokumente in Valkey oder Redis OSS. |
Führen Sie den folgenden Befehl aus, um Kernmetriken abzufragen:
```
info json_core_metrics
```
## Wie interagiert OSS ElastiCache bei Valkey und Redis mit JSON
Im folgenden Abschnitt wird beschrieben, wie OSS ElastiCache für Valkey und Redis mit dem JSON-Datentyp interagiert.
### Rangfolge der Operatoren
Bei der Bewertung bedingter Ausdrücke zum Filtern, haben &&s zuerst Vorrang, und dann werden \$1\$1s ausgewertet, wie es in den meisten Sprachen üblich ist. Operationen innerhalb von Klammern werden zuerst ausgeführt.
### Verhalten der maximalen Verschachtelungsbeschränkung
Das maximale Limit für Pfadverschachtelung ElastiCache für Redis OSS ist 128. Ein Wert wie `$.a.b.c.d...` kann also nur 128 Level erreichen.
### Umgang mit numerischen Werten
JSON hat keine separaten Datentypen für ganze Zahlen und Gleitkommazahlen. Sie werden alle Zahlen genannt.
Numerische Repräsentationen:
Wenn eine JSON-Nummer bei der Eingabe empfangen wird, wird sie in eine der beiden internen Binärdarstellungen umgewandelt: eine 64-Bit-Ganzzahl oder eine doppelt genaue 64-Bit-Gleitkommazahl. Die Ursprüngliche Zeichenfolge und alle ihre Formatierungen werden nicht beibehalten. Wenn also eine Zahl als Teil einer JSON-Antwort ausgegeben wird, wird sie von der internen Binärdarstellung in eine druckbare Zeichenfolge konvertiert, die generische Formatierungsregeln verwendet. Diese Regeln könnten dazu führen, dass eine andere Zeichenfolge generiert wird als empfangen wurde.
Arithmetische Befehle `NUMINCRBY` und `NUMMULTBY`:
+ Wenn beide Zahlen ganze Zahlen sind und das Ergebnis außerhalb des Bereichs von `int64` liegt, ergibt sich daraus automatisch eine doppelt genaue 64-Bit-Gleitkommazahl.
+ Wenn mindestens eine der Zahlen eine Gleitkommazahl ist, ergibt sich daraus eine doppelt genaue 64-Bit-Gleitkommazahl.
+ Wenn das Ergebnis den Bereich einer doppelt genauen 64-Bit-Gleitkommazahl überschreitet, gibt der Befehl einen `OVERFLOW`-Fehler aus.
Eine detaillierte Liste der verfügbaren Befehle finden Sie unter [Unterstützte Valkey- und Redis OSS-BefehleJSON-Befehle](json-list-commands.md).
### Direktes Array-Filtern
ElastiCache für Valkey oder Redis filtert OSS Array-Objekte direkt.
Bei Daten wie `[0,1,2,3,4,5,6]` und einer Pfadabfrage wie `$[?(@<4)]` oder Daten wie `{"my_key":[0,1,2,3,4,5,6]}` und einer Pfadabfrage wie ElastiCache würde `$.my_key[?(@<4)]` unter beiden Umständen [1,2,3] zurückgegeben werden.
### Array-Indizierung
ElastiCache für Valkey oder Redis erlaubt OSS sowohl positive als auch negative Indizes für Arrays. Bei einem Array mit der Länge fünf würde 0 das erste Element abfragen, 1 das zweite usw. Negative Zahlen beginnen am Ende des Arrays, also würde -1 das fünfte Element abfragen, -2 das vierte Element usw.
Um ein vorhersehbares Verhalten für Kunden zu gewährleisten, werden Array-Indizes ElastiCache weder nach unten noch nach oben gerundet. Wenn Sie also ein Array mit einer Länge von 5 haben, würde der Aufruf von Index 5 oder höher oder -6 oder niedriger zu keinem Ergebnis führen.
### Strikte Syntaxbewertung
MemoryDB erlaubt keine JSON-Pfade mit ungültiger Syntax, selbst wenn eine Teilmenge des Pfads einen gültigen Pfad enthält. Dies soll für unsere Kunden ein korrektes Verhalten sicherstellen.
# Unterstützte Valkey- und Redis OSS-Befehle
ElastiCache unterstützt die folgenden Valkey- und Redis OSS-JSON-Befehle:
**Topics**
+ [JSON.ARRAPPEND](json-arrappend.md)
+ [JSON.ARRINDEX](json-arrindex.md)
+ [JSON.ARRINSERT](json-arrinsert.md)
+ [JSON.ARRLEN](json-arrlen.md)
+ [JSON.ARRPOP](json-arrpop.md)
+ [JSON.ARRTRIM](json-arrtrim.md)
+ [JSON.CLEAR](json-clear.md)
+ [JSON.DEBUG](json-debug.md)
+ [JSON.DEL](json-del.md)
+ [JSON.FORGET](json-forget.md)
+ [JSON.GET](json-get.md)
+ [JSON.MGET](json-mget.md)
+ [JSON.MSET](json-mset.md)
+ [JSON.NUMINCRBY](json-numincrby.md)
+ [JSON.NUMMULTBY](json-nummultby.md)
+ [JSON.OBJLEN](json-objlen.md)
+ [JSON.OBJKEYS](json-objkeys.md)
+ [JSON.RESP](json-resp.md)
+ [JSON.SET](json-set.md)
+ [JSON.STRAPPEND](json-strappend.md)
+ [JSON.STRLEN](json-strlen.md)
+ [JSON.TOGGLE](json-toggle.md)
+ [JSON.TYPE](json-type.md)
# JSON.ARRAPPEND
Hängen Sie einen oder mehrere Werte für die Array-Werte an den Pfad an.
Syntax
```
JSON.ARRAPPEND [json ...]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (erforderlich) – Ein JSON-Pfad.
+ json (erforderlich) – Der JSON-Wert, der an das Array angehängt werden soll.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Ganzzahlen, die die neue Länge des Arrays bei jedem Pfad darstellen.
+ Wenn ein Wert kein Array ist, ist der entsprechende Rückgabewert Null.
+ `NONEXISTENT`-Fehler, wenn der Pfad nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Ganzzahl, die neue Länge des Arrays.
+ Wenn mehrere Array-Werte ausgewählt sind, gibt der Befehl die neue Länge des ersten aktualisierten Arrays zurück.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad kein Array ist.
+ `SYNTAXERR`-Fehler, wenn eines der eingegebenen JSON-Argumente keine gültige JSON-Zeichenfolge ist.
+ `NONEXISTENT`-Fehler, wenn der Pfad nicht vorhanden ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRAPPEND k1 $[*] '"c"'
1) (integer) 1
2) (integer) 2
3) (integer) 3
127.0.0.1:6379> JSON.GET k1
"[[\"c\"],[\"a\",\"c\"],[\"a\",\"b\",\"c\"]]"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRAPPEND k1 [-1] '"c"'
(integer) 3
127.0.0.1:6379> JSON.GET k1
"[[],[\"a\"],[\"a\",\"b\",\"c\"]]"
```
# JSON.ARRINDEX
Sucht nach dem ersten Vorkommen eines skalaren JSON-Werts in den Arrays am Pfad.
+ Fehler außerhalb des Bereichs werden behandelt, indem der Index auf den Anfang und das Ende des Arrays gerundet wird.
+ Wenn start > end, return -1 (nicht gefunden).
Syntax
```
JSON.ARRINDEX [start [end]]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (erforderlich) – Ein JSON-Pfad.
+ json-scalar (erforderlich) – Der Skalarwert für die Suche nach . JSON-Skalar bezieht sich auf Werte, die keine Objekte oder Arrays sind. Das bedeutet, dass die Werte „Zeichenfolge“, „Zahl“, „Boolescher Wert“ und „Null“ skalare Werte sind.
+ start (optional) – einschließlich Startindex. Es gilt der Standardwert „0“, falls nicht vorhanden.
+ end (optional) – Der Endindex (exklusive). Es gilt der Standardwert „0“, wenn keine Angabe gemacht wird, was bedeutet, dass das letzte Element enthalten ist. 0 oder -1 bedeutet, dass das letzte Element enthalten ist.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von ganzen Zahlen. Jeder Wert ist der Index des übereinstimmenden Elements im Array am Pfad. Der Wert ist -1, falls nicht gefunden.
+ Wenn ein Wert kein Array ist, ist der entsprechende Rückgabewert Null.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Ganzzahl, der Index des übereinstimmenden Elements oder -1, falls nicht gefunden.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad kein Array ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRINDEX k1 $[*] '"b"'
1) (integer) -1
2) (integer) -1
3) (integer) 1
4) (integer) 1
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"children": ["John", "Jack", "Tom", "Bob", "Mike"]}'
OK
127.0.0.1:6379> JSON.ARRINDEX k1 .children '"Tom"'
(integer) 2
```
# JSON.ARRINSERT
Fügt einen oder mehrere Werte in die Array-Werte beim Pfad vor dem Index ein.
Syntax
```
JSON.ARRINSERT [json ...]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (erforderlich) – Ein JSON-Pfad.
+ index (erforderlich) – Ein Array-Index, vor dem Werte eingefügt werden.
+ json (erforderlich) – Der JSON-Wert, der an das Array angehängt werden soll.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Ganzzahlen, die die neue Länge des Arrays bei jedem Pfad darstellen.
+ Wenn ein Wert ein leeres Array ist, ist der entsprechende Rückgabewert Null.
+ Wenn ein Wert kein Array ist, ist der entsprechende Rückgabewert Null.
+ `OUTOFBOUNDARIES`-Fehler, wenn das Index-Argument außerhalb des gültigen Bereichs liegt.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Ganzzahl, die neue Länge des Arrays.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad kein Array ist.
+ `OUTOFBOUNDARIES`-Fehler, wenn das Index-Argument außerhalb des gültigen Bereichs liegt.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRINSERT k1 $[*] 0 '"c"'
1) (integer) 1
2) (integer) 2
3) (integer) 3
127.0.0.1:6379> JSON.GET k1
"[[\"c\"],[\"c\",\"a\"],[\"c\",\"a\",\"b\"]]"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRINSERT k1 . 0 '"c"'
(integer) 4
127.0.0.1:6379> JSON.GET k1
"[\"c\",[],[\"a\"],[\"a\",\"b\"]]"
```
# JSON.ARRLEN
Ruft die Länge der Array-Werte am Pfad ab.
Syntax
```
JSON.ARRLEN [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Ganzzahlen, die die Array-Länge bei jedem Pfad darstellen.
+ Wenn ein Wert kein Array ist, ist der entsprechende Rückgabewert Null.
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Ganzzahl, Array-Länge.
+ Wenn mehrere Objekte ausgewählt sind, gibt der Befehl die Länge des ersten Arrays zurück.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad kein Array ist.
+ `NONEXISTENT JSON`-Fehler, wenn der Pfad nicht vorhanden ist.
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRLEN k1 $[*]
1) (integer) 0
2) (integer) 1
3) (integer) 2
4) (integer) 3
127.0.0.1:6379> JSON.SET k2 . '[[], "a", ["a", "b"], ["a", "b", "c"], 4]'
OK
127.0.0.1:6379> JSON.ARRLEN k2 $[*]
1) (integer) 0
2) (nil)
3) (integer) 2
4) (integer) 3
5) (nil)
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRLEN k1 [*]
(integer) 0
127.0.0.1:6379> JSON.ARRLEN k1 [1]
(integer) 1
127.0.0.1:6379> JSON.ARRLEN k1 [2]
(integer) 2
127.0.0.1:6379> JSON.SET k2 . '[[], "a", ["a", "b"], ["a", "b", "c"], 4]'
OK
127.0.0.1:6379> JSON.ARRLEN k2 [1]
(error) WRONGTYPE JSON element is not an array
127.0.0.1:6379> JSON.ARRLEN k2 [0]
(integer) 0
127.0.0.1:6379> JSON.ARRLEN k2 [6]
(error) OUTOFBOUNDARIES Array index is out of bounds
127.0.0.1:6379> JSON.ARRLEN k2 a.b
(error) NONEXISTENT JSON path does not exist
```
# JSON.ARRPOP
Entfernt und gibt ein Element am Index aus dem Array zurück. Das Öffnen eines leeren Arrays gibt null zurück.
Syntax
```
JSON.ARRPOP [path [index]]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
+ index (optional) —Die Position im Array, von der aus das Popping beginnen soll.
+ Ist standardmäßig -1, falls nicht angegeben, was auf das letzte Element verweist.
+ Negativer Wert bedeutet Position vom letzten Element.
+ Außerhalb der Grenzen liegende Indizes werden auf ihre jeweiligen Array-Grenzen gerundet.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Bulk-Strings, die eingeblendete Werte auf jedem Pfad darstellen.
+ Wenn ein Wert ein leeres Array ist, ist der entsprechende Rückgabewert Null.
+ Wenn ein Wert kein Array ist, ist der entsprechende Rückgabewert Null.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Bulk-String, der den eingeblendeten JSON-Wert darstellt.
+ Null, wenn das Array leer ist.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad kein Array ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRPOP k1 $[*]
1) (nil)
2) "\"a\""
3) "\"b\""
127.0.0.1:6379> JSON.GET k1
"[[],[],[\"a\"]]"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRPOP k1
"[\"a\",\"b\"]"
127.0.0.1:6379> JSON.GET k1
"[[],[\"a\"]]"
127.0.0.1:6379> JSON.SET k2 . '[[], ["a"], ["a", "b"]]'
OK
127.0.0.1:6379> JSON.ARRPOP k2 . 0
"[]"
127.0.0.1:6379> JSON.GET k2
"[[\"a\"],[\"a\",\"b\"]]"
```
# JSON.ARRTRIM
Trimmt einen Array am Pfad, der dadurch zum Subarray [Start, Ende] wird (beides inklusive).
+ Wenn das Array leer ist, tun Sie nichts, und geben Sie 0 zurück.
+ Wenn start <0 ist, behandeln Sie es als 0.
+ Wenn end >= size (Größe des Arrays), behandeln Sie es als size-1.
+ Wenn start >= size oder start > end, leeren Sie das Array und geben 0 zurück.
Syntax
```
JSON.ARRTRIM
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (erforderlich) – Ein JSON-Pfad.
+ start (erforderlich) – Der Startindex, einschließlich.
+ end (erforderlich) – Der Endindex, einschließlich.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Ganzzahlen, die die neue Länge des Arrays bei jedem Pfad darstellen.
+ Wenn ein Wert ein leeres Array ist, ist der entsprechende Rückgabewert Null.
+ Wenn ein Wert kein Array ist, ist der entsprechende Rückgabewert Null.
+ `OUTOFBOUNDARIES`-Fehler, wenn ein Indexargument außerhalb des gültigen Bereichs liegt.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Ganzzahl, die neue Länge des Arrays.
+ Null, wenn das Array leer ist.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad kein Array ist.
+ `OUTOFBOUNDARIES`-Fehler, wenn ein Indexargument außerhalb des gültigen Bereichs liegt.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[[], ["a"], ["a", "b"], ["a", "b", "c"]]'
OK
127.0.0.1:6379> JSON.ARRTRIM k1 $[*] 0 1
1) (integer) 0
2) (integer) 1
3) (integer) 2
4) (integer) 2
127.0.0.1:6379> JSON.GET k1
"[[],[\"a\"],[\"a\",\"b\"],[\"a\",\"b\"]]"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"children": ["John", "Jack", "Tom", "Bob", "Mike"]}'
OK
127.0.0.1:6379> JSON.ARRTRIM k1 .children 0 1
(integer) 2
127.0.0.1:6379> JSON.GET k1 .children
"[\"John\",\"Jack\"]"
```
# JSON.CLEAR
Entfernt die Arrays oder ein Objekt auf dem Pfad.
Syntax
```
JSON.CLEAR [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
**Ergebnis**
+ Ganzzahl, die Anzahl der entfernten Container.
+ Das Löschen eines leeren Arrays oder Objekts führt zu einem entfernten Container.
+ Das Löschen eines Nicht-Container-Werts gibt 0 zurück.
**Beispiele**
```
127.0.0.1:6379> JSON.SET k1 . '[[], [0], [0,1], [0,1,2], 1, true, null, "d"]'
OK
127.0.0.1:6379> JSON.CLEAR k1 $[*]
(integer) 7
127.0.0.1:6379> JSON.CLEAR k1 $[*]
(integer) 4
127.0.0.1:6379> JSON.SET k2 . '{"children": ["John", "Jack", "Tom", "Bob", "Mike"]}'
OK
127.0.0.1:6379> JSON.CLEAR k2 .children
(integer) 1
127.0.0.1:6379> JSON.GET k2 .children
"[]"
```
# JSON.DEBUG
Meldet Informationen. Unterstützte Unterbefehle sind:
+ MEMORY [path] – Meldet die Speicherauslastung eines JSON-Wertes in Byte. Falls nicht angegeben, gilt der Root-Standardwert für den Pfad.
+ FIELDS [path] – Meldet die Anzahl der Felder im angegebenen Dokumentpfad. Falls nicht angegeben, gilt der Root-Standardwert für den Pfad. Jeder JSON-Wert, der kein Container ist, zählt als ein Feld. Objekte und Arrays zählen rekursiv ein Feld für jeden ihrer JSON-Werte. Jeder Containerwert, mit Ausnahme des Root-Containers, zählt als ein zusätzliches Feld.
+ HELP – Druckt Hilfemeldungen des Befehls.
Syntax
```
JSON.DEBUG
```
Hängt vom Unterbefehl ab:
MEMORY
+ Wenn der Pfad eine erweiterte Syntax ist:
+ Gibt ein Array von ganzen Zahlen zurück, das die Speichergröße (in Byte) des JSON-Werts bei jedem Pfad darstellt.
+ Gibt ein leeres Array zurück, wenn der Valkey- oder Redis-OSS-Schlüssel nicht existiert.
+ Wenn der Pfad eine eingeschränkte Syntax hat:
+ Gibt eine Ganzzahl, Speichergröße und den JSON-Wert in Byte zurück.
+ Gibt null zurück, wenn der Valkey- oder Redis-OSS-Schlüssel nicht existiert.
FIELDS
+ Wenn der Pfad eine erweiterte Syntax ist:
+ Gibt ein Array von ganzen Zahlen zurück, die die Anzahl der Felder mit JSON-Wert in jedem Pfad darstellen.
+ Gibt ein leeres Array zurück, wenn der Valkey- oder Redis-OSS-Schlüssel nicht existiert.
+ Wenn der Pfad eine eingeschränkte Syntax hat:
+ Gibt eine Ganzzahl und die Anzahl der Felder des JSON-Werts zurück.
+ Gibt null zurück, wenn der Valkey- oder Redis-OSS-Schlüssel nicht existiert.
HELP – Gibt ein Array von Hilfemeldungen zurück.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[1, 2.3, "foo", true, null, {}, [], {"a":1, "b":2}, [1,2,3]]'
OK
127.0.0.1:6379> JSON.DEBUG MEMORY k1 $[*]
1) (integer) 16
2) (integer) 16
3) (integer) 19
4) (integer) 16
5) (integer) 16
6) (integer) 16
7) (integer) 16
8) (integer) 50
9) (integer) 64
127.0.0.1:6379> JSON.DEBUG FIELDS k1 $[*]
1) (integer) 1
2) (integer) 1
3) (integer) 1
4) (integer) 1
5) (integer) 1
6) (integer) 0
7) (integer) 0
8) (integer) 2
9) (integer) 3
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.DEBUG MEMORY k1
(integer) 632
127.0.0.1:6379> JSON.DEBUG MEMORY k1 .phoneNumbers
(integer) 166
127.0.0.1:6379> JSON.DEBUG FIELDS k1
(integer) 19
127.0.0.1:6379> JSON.DEBUG FIELDS k1 .address
(integer) 4
127.0.0.1:6379> JSON.DEBUG HELP
1) JSON.DEBUG MEMORY [path] - report memory size (bytes) of the JSON element. Path defaults to root if not provided.
2) JSON.DEBUG FIELDS [path] - report number of fields in the JSON element. Path defaults to root if not provided.
3) JSON.DEBUG HELP - print help message.
```
# JSON.DEL
Löscht die JSON-Werte am Pfad in einem Dokumentschlüssel. Wenn der Pfad das Stammverzeichnis ist, entspricht dies dem Löschen des Schlüssels aus Valkey oder Redis OSS.
Syntax
```
JSON.DEL [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
**Ergebnis**
+ Anzahl der gelöschten Elemente.
+ 0, wenn der Valkey- oder Redis-OSS-Schlüssel nicht existiert.
+ 0, wenn der JSON-Pfad ungültig ist oder nicht existiert.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}, "e": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.DEL k1 $.d.*
(integer) 3
127.0.0.1:6379> JSOn.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[1,2,3,4,5]}"
127.0.0.1:6379> JSON.DEL k1 $.e[*]
(integer) 5
127.0.0.1:6379> JSOn.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[]}"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}, "e": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.DEL k1 .d.*
(integer) 3
127.0.0.1:6379> JSON.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[1,2,3,4,5]}"
127.0.0.1:6379> JSON.DEL k1 .e[*]
(integer) 5
127.0.0.1:6379> JSON.GET k1
"{\"a\":{},\"b\":{\"a\":1},\"c\":{\"a\":1,\"b\":2},\"d\":{},\"e\":[]}"
```
# JSON.FORGET
Alias von [JSON.DEL](json-del.md)
# JSON.GET
Gibt das serialisierte JSON in einem oder mehreren Pfaden zurück.
Syntax
```
JSON.GET
[INDENT indentation-string]
[NEWLINE newline-string]
[SPACE space-string]
[NOESCAPE]
[path ...]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ INDENT/NEWLINE/SPACE(optional) — Steuert das Format der zurückgegebenen JSON-Zeichenfolge, d. h. „pretty print“. Der Standardwert in jedem Fall ist eine leere Zeichenfolge. Die Werte können in jeder Kombination überschrieben werden. Sie können in beliebiger Reihenfolge angegeben werden.
+ NOESCAPE – Optional, darf aus Gründen der Legacy-Kompatibilität vorhanden sein und hat keine andere Auswirkung.
+ path (optional) – Null oder mehr JSON-Pfade, standardmäßig das Stammverzeichnis, wenn keine Angabe. Die Pfadargumente müssen am Ende platziert werden.
**Ergebnis**
Erweiterte Pfad-Syntax:
Wenn ein Pfad angegeben ist:
+ Gibt eine serialisierte Zeichenfolge eines Arrays von Werten zurück.
+ Wenn kein Wert ausgewählt ist, gibt der Befehl ein leeres Array zurück.
Wenn mehrere Pfade angegeben sind:
+ Gibt ein stringiertes JSON-Objekt zurück, in dem jeder Pfad ein Schlüssel ist.
+ Wenn es gemischte, erweiterte und eingeschränkte Pfadsyntax gibt, entspricht das Ergebnis der erweiterten Syntax.
+ Wenn ein Pfad nicht existiert, ist der entsprechende Wert ein leeres Array.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.GET k1 $.address.*
"[\"21 2nd Street\",\"New York\",\"NY\",\"10021-3100\"]"
127.0.0.1:6379> JSON.GET k1 indent "\t" space " " NEWLINE "\n" $.address.*
"[\n\t\"21 2nd Street\",\n\t\"New York\",\n\t\"NY\",\n\t\"10021-3100\"\n]"
127.0.0.1:6379> JSON.GET k1 $.firstName $.lastName $.age
"{\"$.firstName\":[\"John\"],\"$.lastName\":[\"Smith\"],\"$.age\":[27]}"
127.0.0.1:6379> JSON.SET k2 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}}'
OK
127.0.0.1:6379> json.get k2 $..*
"[{},{\"a\":1},{\"a\":1,\"b\":2},1,1,2]"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.GET k1 .address
"{\"street\":\"21 2nd Street\",\"city\":\"New York\",\"state\":\"NY\",\"zipcode\":\"10021-3100\"}"
127.0.0.1:6379> JSON.GET k1 indent "\t" space " " NEWLINE "\n" .address
"{\n\t\"street\": \"21 2nd Street\",\n\t\"city\": \"New York\",\n\t\"state\": \"NY\",\n\t\"zipcode\": \"10021-3100\"\n}"
127.0.0.1:6379> JSON.GET k1 .firstName .lastName .age
"{\".firstName\":\"John\",\".lastName\":\"Smith\",\".age\":27}"
```
# JSON.MGET
Wird JSONs am Pfad aus mehreren Dokumentschlüsseln serialisiert. Es gibt null für einen nicht existierenden Schlüssel oder JSON-Pfad zurück.
**Syntax**
```
JSON.MGET [key ...]
```
+ key (erforderlich) — Ein oder mehrere Valkey- oder Redis-OSS-Schlüssel des Dokumenttyps.
+ path (erforderlich) – Ein JSON-Pfad.
**Ergebnis**
+ Array von Bulk-Strings. Die Größe des Arrays entspricht der Anzahl der Schlüssel im Befehl. Jedes Element des Arrays wird entweder mit (a) dem serialisierten JSON gefüllt, wie es sich im Pfad befindet, oder (b) mit null, wenn der Schlüssel nicht existiert, der Pfad nicht im Dokument festgehalten oder ungültig (Syntaxfehler) ist.
+ Wenn einer der angegebenen Schlüssel existiert und kein JSON-Schlüssel ist, gibt der Befehl den Fehler `WRONGTYPE` zurück.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021"}}'
OK
127.0.0.1:6379> JSON.SET k2 . '{"address":{"street":"5 main Street","city":"Boston","state":"MA","zipcode":"02101"}}'
OK
127.0.0.1:6379> JSON.SET k3 . '{"address":{"street":"100 Park Ave","city":"Seattle","state":"WA","zipcode":"98102"}}'
OK
127.0.0.1:6379> JSON.MGET k1 k2 k3 $.address.city
1) "[\"New York\"]"
2) "[\"Boston\"]"
3) "[\"Seattle\"]"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021"}}'
OK
127.0.0.1:6379> JSON.SET k2 . '{"address":{"street":"5 main Street","city":"Boston","state":"MA","zipcode":"02101"}}'
OK
127.0.0.1:6379> JSON.SET k3 . '{"address":{"street":"100 Park Ave","city":"Seattle","state":"WA","zipcode":"98102"}}'
OK
127.0.0.1:6379> JSON.MGET k1 k2 k3 .address.city
1) "\"New York\""
2) "\"Seattle\""
3) "\"Seattle\""
```
# JSON.MSET
Wird für Valkey Version 8.1 und höher unterstützt.
Legen Sie JSON-Werte für mehrere Schlüssel fest. Die Operation ist atomar. Entweder sind alle Werte gesetzt oder es sind keine gesetzt.
**Syntax**
```
JSON.MSET key path json [ key path json ... ]
```
+ Wenn der Pfad ein Objektmitglied aufruft:
+ Wenn das übergeordnete Element nicht existiert, gibt der Befehl den Fehler NONEXISTENT zurück.
+ Wenn das übergeordnete Element existiert, aber kein Objekt ist, gibt der Befehl ERROR zurück.
+ Wenn das übergeordnete Element existiert und ein Objekt ist:
+ Wenn das Mitglied nicht existiert, wird ein neues Mitglied an das übergeordnete Objekt angehängt, wenn das übergeordnete Objekt das letzte untergeordnete Objekt im Pfad ist. Andernfalls gibt der Befehl den Fehler NONEXISTENT zurück.
+ Wenn das Mitglied existiert, wird sein Wert durch den JSON-Wert ersetzt.
+ Wenn der Pfad einen Array-Index aufruft:
+ Wenn das übergeordnete Element nicht existiert, gibt der Befehl den Fehler NONEXISTENT zurück.
+ Wenn das übergeordnete Element existiert, aber kein Array ist, gibt der Befehl ERROR zurück.
+ Wenn das übergeordnete Element existiert, der Index jedoch außerhalb der Grenzen liegt, gibt der Befehl den Fehler OUTOFBOUNDARIES zurück.
+ Wenn das übergeordnete Element existiert und der Index gültig ist, wird das Element durch den neuen JSON-Wert ersetzt.
+ Wenn der Pfad ein Objekt oder Array aufruft, wird der Wert (Objekt oder Array) durch den neuen JSON-Wert ersetzt.
**Ergebnis**
+ Einfache Zeichenkettenantwort: 'OK', wenn der Vorgang erfolgreich war.
+ Einfache Fehlerantwort: Wenn der Vorgang fehlgeschlagen ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.MSET k1 . '[1,2,3,4,5]' k2 . '{"a":{"a":1, "b":2, "c":3}}' k3 . '{"a": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.GET k1
"[1,2,3,4,5]"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.MSET k2 $.a.* '0' k3 $.a[*] '0'
OK
127.0.0.1:6379> JSON.GET k2
"{\"a\":{\"a\":0,\"b\":0,\"c\":0}}"
127.0.0.1:6379> JSON.GET k3
"{\"a\":[0,0,0,0,0]}"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.MSET k1 . '{"name": "John","address": {"street": "123 Main St","city": "Springfield"},"phones": ["555-1234","555-5678"]}'
OK
127.0.0.1:6379> JSON.MSET k1 .address.street '"21 2nd Street"' k1 .address.city '"New York"'
OK
127.0.0.1:6379> JSON.GET k1 .address.street
"\"21 2nd Street\""
127.0.0.1:6379> JSON.GET k1 .address.city
"\"New York\""
```
# JSON.NUMINCRBY
Gibt die Zahlenwerte am Pfad durch eine bestimmte Zahl in Schritten an.
Syntax
```
JSON.NUMINCRBY
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (erforderlich) – Ein JSON-Pfad.
+ Zahl (erforderlich) – Eine Zahl
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Bulk-Strings, die eingeblendete Werte auf jedem Pfad darstellen.
+ Wenn ein Wert keine Zahl ist, ist der entsprechende Rückgabewert Null.
+ `WRONGTYPE`-Fehler, wenn die Zahl nicht analysiert werden kann.
+ `OVERFLOW`-Fehler, wenn das Ergebnis außerhalb des Bereichs der doppelt genauen 64-Bit-Gleitkommazahl liegt.
+ `NONEXISTENT` wenn der Dokumentschlüssel nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Bulk-String, der den daraus resultierenden Wert darstellt.
+ Wenn mehrere Werte ausgewählt wurden, gibt der Befehl das Ergebnis des zuletzt aktualisierten Arrays zurück.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad keine Zahl ist.
+ `WRONGTYPE`-Fehler, wenn die Zahl nicht analysiert werden kann.
+ `OVERFLOW`-Fehler, wenn das Ergebnis außerhalb des Bereichs der doppelt genauen 64-Bit-Gleitkommazahl liegt.
+ `NONEXISTENT` wenn der Dokumentschlüssel nicht vorhanden ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 $.d[*] 10
"[11,12,13]"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[11,12,13]}"
127.0.0.1:6379> JSON.SET k1 $ '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 $.a[*] 1
"[]"
127.0.0.1:6379> JSON.NUMINCRBY k1 $.b[*] 1
"[2]"
127.0.0.1:6379> JSON.NUMINCRBY k1 $.c[*] 1
"[2,3]"
127.0.0.1:6379> JSON.NUMINCRBY k1 $.d[*] 1
"[2,3,4]"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,3],\"d\":[2,3,4]}"
127.0.0.1:6379> JSON.SET k2 $ '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k2 $.a.* 1
"[]"
127.0.0.1:6379> JSON.NUMINCRBY k2 $.b.* 1
"[2]"
127.0.0.1:6379> JSON.NUMINCRBY k2 $.c.* 1
"[2,3]"
127.0.0.1:6379> JSON.NUMINCRBY k2 $.d.* 1
"[2,3,4]"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":3},\"d\":{\"a\":2,\"b\":3,\"c\":4}}"
127.0.0.1:6379> JSON.SET k3 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k3 $.a.* 1
"[null]"
127.0.0.1:6379> JSON.NUMINCRBY k3 $.b.* 1
"[null,2]"
127.0.0.1:6379> JSON.NUMINCRBY k3 $.c.* 1
"[null,null]"
127.0.0.1:6379> JSON.NUMINCRBY k3 $.d.* 1
"[2,null,4]"
127.0.0.1:6379> JSON.GET k3
"{\"a\":{\"a\":\"a\"},\"b\":{\"a\":\"a\",\"b\":2},\"c\":{\"a\":\"a\",\"b\":\"b\"},\"d\":{\"a\":2,\"b\":\"b\",\"c\":4}}"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 .d[1] 10
"12"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[1,12,3]}"
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k1 .a[*] 1
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMINCRBY k1 .b[*] 1
"2"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[1,2],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMINCRBY k1 .c[*] 1
"3"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,3],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMINCRBY k1 .d[*] 1
"4"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,3],\"d\":[2,3,4]}"
127.0.0.1:6379> JSON.SET k2 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k2 .a.* 1
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMINCRBY k2 .b.* 1
"2"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":1,\"b\":2},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMINCRBY k2 .c.* 1
"3"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":3},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMINCRBY k2 .d.* 1
"4"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":3},\"d\":{\"a\":2,\"b\":3,\"c\":4}}"
127.0.0.1:6379> JSON.SET k3 . '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMINCRBY k3 .a.* 1
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMINCRBY k3 .b.* 1
"2"
127.0.0.1:6379> JSON.NUMINCRBY k3 .c.* 1
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMINCRBY k3 .d.* 1
"4"
```
# JSON.NUMMULTBY
Multipliziert die Zahlenwerte am Pfad durch eine bestimmte Zahl.
Syntax
```
JSON.NUMMULTBY
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (erforderlich) – Ein JSON-Pfad.
+ Zahl (erforderlich) – Eine Zahl
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Bulk-Strings, die den sich daraus ergebenden Wert auf jedem Pfad darstellen.
+ Wenn ein Wert keine Zahl ist, ist der entsprechende Rückgabewert Null.
+ `WRONGTYPE`-Fehler, wenn die Zahl nicht analysiert werden kann.
+ `OVERFLOW`-Fehler, wenn das Ergebnis außerhalb des Bereichs eines doppelt genauen 64-Bit-IEEE-Gleitkommawerts liegt.
+ `NONEXISTENT` wenn der Dokumentschlüssel nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Bulk-String, der den daraus resultierenden Wert darstellt.
+ Wenn mehrere Werte ausgewählt wurden, gibt der Befehl das Ergebnis des zuletzt aktualisierten Arrays zurück.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad keine Zahl ist.
+ `WRONGTYPE`-Fehler, wenn die Zahl nicht analysiert werden kann.
+ `OVERFLOW`-Fehler, wenn das Ergebnis außerhalb des Bereichs eines doppelt genauen 64-Bit-IEEE-Werts liegt.
+ `NONEXISTENT` wenn der Dokumentschlüssel nicht vorhanden ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 $.d[*] 2
"[2,4,6]"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[2,4,6]}"
127.0.0.1:6379> JSON.SET k1 $ '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 $.a[*] 2
"[]"
127.0.0.1:6379> JSON.NUMMULTBY k1 $.b[*] 2
"[2]"
127.0.0.1:6379> JSON.NUMMULTBY k1 $.c[*] 2
"[2,4]"
127.0.0.1:6379> JSON.NUMMULTBY k1 $.d[*] 2
"[2,4,6]"
127.0.0.1:6379> JSON.SET k2 $ '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k2 $.a.* 2
"[]"
127.0.0.1:6379> JSON.NUMMULTBY k2 $.b.* 2
"[2]"
127.0.0.1:6379> JSON.NUMMULTBY k2 $.c.* 2
"[2,4]"
127.0.0.1:6379> JSON.NUMMULTBY k2 $.d.* 2
"[2,4,6]"
127.0.0.1:6379> JSON.SET k3 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k3 $.a.* 2
"[null]"
127.0.0.1:6379> JSON.NUMMULTBY k3 $.b.* 2
"[null,2]"
127.0.0.1:6379> JSON.NUMMULTBY k3 $.c.* 2
"[null,null]"
127.0.0.1:6379> JSON.NUMMULTBY k3 $.d.* 2
"[2,null,6]"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 .d[1] 2
"4"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[1],\"c\":[1,2],\"d\":[1,4,3]}"
127.0.0.1:6379> JSON.SET k1 . '{"a":[], "b":[1], "c":[1,2], "d":[1,2,3]}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k1 .a[*] 2
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMMULTBY k1 .b[*] 2
"2"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[1,2],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMMULTBY k1 .c[*] 2
"4"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,4],\"d\":[1,2,3]}"
127.0.0.1:6379> JSON.NUMMULTBY k1 .d[*] 2
"6"
127.0.0.1:6379> JSON.GET k1
"{\"a\":[],\"b\":[2],\"c\":[2,4],\"d\":[2,4,6]}"
127.0.0.1:6379> JSON.SET k2 . '{"a":{}, "b":{"a":1}, "c":{"a":1, "b":2}, "d":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k2 .a.* 2
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.NUMMULTBY k2 .b.* 2
"2"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":1,\"b\":2},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMMULTBY k2 .c.* 2
"4"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":4},\"d\":{\"a\":1,\"b\":2,\"c\":3}}"
127.0.0.1:6379> JSON.NUMMULTBY k2 .d.* 2
"6"
127.0.0.1:6379> JSON.GET k2
"{\"a\":{},\"b\":{\"a\":2},\"c\":{\"a\":2,\"b\":4},\"d\":{\"a\":2,\"b\":4,\"c\":6}}"
127.0.0.1:6379> JSON.SET k3 . '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"b"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.NUMMULTBY k3 .a.* 2
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMMULTBY k3 .b.* 2
"2"
127.0.0.1:6379> JSON.GET k3
"{\"a\":{\"a\":\"a\"},\"b\":{\"a\":\"a\",\"b\":2},\"c\":{\"a\":\"a\",\"b\":\"b\"},\"d\":{\"a\":1,\"b\":\"b\",\"c\":3}}"
127.0.0.1:6379> JSON.NUMMULTBY k3 .c.* 2
(error) WRONGTYPE JSON element is not a number
127.0.0.1:6379> JSON.NUMMULTBY k3 .d.* 2
"6"
127.0.0.1:6379> JSON.GET k3
"{\"a\":{\"a\":\"a\"},\"b\":{\"a\":\"a\",\"b\":2},\"c\":{\"a\":\"a\",\"b\":\"b\"},\"d\":{\"a\":2,\"b\":\"b\",\"c\":6}}"
```
# JSON.OBJLEN
Ruft die Anzahl der Schlüssel in den Objektwerten am Pfad ab.
Syntax
```
JSON.OBJLEN [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Ganzzahlen, die die Objektlänge in jedem Pfad darstellen.
+ Wenn ein Wert kein Objekt ist, ist der entsprechende Rückgabewert null.
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Ganzzahl, Anzahl der Schlüssel im Objekt.
+ Wenn mehrere Objekte ausgewählt sind, gibt der Befehl die Länge des ersten Objekts zurück.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad kein Objekt ist.
+ `NONEXISTENT JSON`-Fehler, wenn der Pfad nicht vorhanden ist.
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJLEN k1 $.a
1) (integer) 0
127.0.0.1:6379> JSON.OBJLEN k1 $.a.*
(empty array)
127.0.0.1:6379> JSON.OBJLEN k1 $.b
1) (integer) 1
127.0.0.1:6379> JSON.OBJLEN k1 $.b.*
1) (nil)
127.0.0.1:6379> JSON.OBJLEN k1 $.c
1) (integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 $.c.*
1) (nil)
2) (nil)
127.0.0.1:6379> JSON.OBJLEN k1 $.d
1) (integer) 3
127.0.0.1:6379> JSON.OBJLEN k1 $.d.*
1) (nil)
2) (nil)
3) (integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 $.*
1) (integer) 0
2) (integer) 1
3) (integer) 2
4) (integer) 3
5) (nil)
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJLEN k1 .a
(integer) 0
127.0.0.1:6379> JSON.OBJLEN k1 .a.*
(error) NONEXISTENT JSON path does not exist
127.0.0.1:6379> JSON.OBJLEN k1 .b
(integer) 1
127.0.0.1:6379> JSON.OBJLEN k1 .b.*
(error) WRONGTYPE JSON element is not an object
127.0.0.1:6379> JSON.OBJLEN k1 .c
(integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 .c.*
(error) WRONGTYPE JSON element is not an object
127.0.0.1:6379> JSON.OBJLEN k1 .d
(integer) 3
127.0.0.1:6379> JSON.OBJLEN k1 .d.*
(integer) 2
127.0.0.1:6379> JSON.OBJLEN k1 .*
(integer) 0
```
# JSON.OBJKEYS
Ruft Schlüsselnamen in den Objektwerten am Pfad ab.
Syntax
```
JSON.OBJKEYS [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Arrays von Bulk-Strings. Jedes Element ist ein Array von Schlüsseln in einem übereinstimmenden Objekt.
+ Wenn ein Wert kein Objekt ist, ist der entsprechende Rückgabewert leer.
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Array von Bulk-Strings. Jedes Element ist ein Schlüsselname im Objekt.
+ Wenn mehrere Objekte ausgewählt sind, gibt der Befehl die Schlüssel des ersten Objekts zurück.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad kein Objekt ist.
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJKEYS k1 $.*
1) (empty array)
2) 1) "a"
3) 1) "a"
2) "b"
4) 1) "a"
2) "b"
3) "c"
5) (empty array)
127.0.0.1:6379> JSON.OBJKEYS k1 $.d
1) 1) "a"
2) "b"
3) "c"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{}, "b":{"a":"a"}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":{"a":3,"b":4}}, "e":1}'
OK
127.0.0.1:6379> JSON.OBJKEYS k1 .*
1) "a"
127.0.0.1:6379> JSON.OBJKEYS k1 .d
1) "a"
2) "b"
3) "c"
```
# JSON.RESP
Gibt den JSON-Wert im angegebenen Pfad im Valkey oder Redis OSS Serialization Protocol (RESP) zurück. Wenn der Wert Container lautet, ist die Antwort ein RESP-Array oder verschachteltes Array.
+ JSON null wird dem RESP Null Bulk String zugeordnet.
+ Boolesche JSON-Werte werden den jeweiligen RESP Simple Strings zugeordnet.
+ Ganzzahlen werden RESP-Ganzzahlen zugeordnet.
+ Doppelt genaue 64-Bit-Gleitkommazahlen werden RESP-Bulk-Strings zugeordnet.
+ JSON-Strings werden RESP Bulk Strings zugeordnet.
+ JSON-Arrays werden als RESP-Arrays dargestellt, wobei das erste Element die einfache Zeichenfolge [ ist, gefolgt von den Elementen des Arrays.
+ JSON-Objekte werden als RESP-Arrays dargestellt, wobei das erste Element die einfache Zeichenfolge \$1 ist, gefolgt von Schlüssel-Wert-Paaren, von denen jedes ein RESP-Bulk-String ist.
Syntax
```
JSON.RESP [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Arrays. Jedes Array-Element repräsentiert die RESP-Form des Werts in einem Pfad.
+ Leeres Array wenn der Dokumentschlüssel nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Array, das die RESP-Form des Werts in einem Pfad repräsentiert.
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.RESP k1 $.address
1) 1) {
2) 1) "street"
2) "21 2nd Street"
3) 1) "city"
2) "New York"
4) 1) "state"
2) "NY"
5) 1) "zipcode"
2) "10021-3100"
127.0.0.1:6379> JSON.RESP k1 $.address.*
1) "21 2nd Street"
2) "New York"
3) "NY"
4) "10021-3100"
127.0.0.1:6379> JSON.RESP k1 $.phoneNumbers
1) 1) [
2) 1) {
2) 1) "type"
2) "home"
3) 1) "number"
2) "555 555-1234"
3) 1) {
2) 1) "type"
2) "office"
3) 1) "number"
2) "555 555-4567"
127.0.0.1:6379> JSON.RESP k1 $.phoneNumbers[*]
1) 1) {
2) 1) "type"
2) "home"
3) 1) "number"
2) "212 555-1234"
2) 1) {
2) 1) "type"
2) "office"
3) 1) "number"
2) "555 555-4567"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.RESP k1 .address
1) {
2) 1) "street"
2) "21 2nd Street"
3) 1) "city"
2) "New York"
4) 1) "state"
2) "NY"
5) 1) "zipcode"
2) "10021-3100"
127.0.0.1:6379> JSON.RESP k1
1) {
2) 1) "firstName"
2) "John"
3) 1) "lastName"
2) "Smith"
4) 1) "age"
2) (integer) 27
5) 1) "weight"
2) "135.25"
6) 1) "isAlive"
2) true
7) 1) "address"
2) 1) {
2) 1) "street"
2) "21 2nd Street"
3) 1) "city"
2) "New York"
4) 1) "state"
2) "NY"
5) 1) "zipcode"
2) "10021-3100"
8) 1) "phoneNumbers"
2) 1) [
2) 1) {
2) 1) "type"
2) "home"
3) 1) "number"
2) "212 555-1234"
3) 1) {
2) 1) "type"
2) "office"
3) 1) "number"
2) "555 555-4567"
9) 1) "children"
2) 1) [
10) 1) "spouse"
2) (nil)
```
# JSON.SET
Legt JSON-Werte im Pfad fest.
Wenn der Pfad ein Objektmitglied aufruft:
+ Wenn das übergeordnete Element nicht vorhanden ist, gibt der Befehl den Fehler NONEXISTENT aus.
+ Wenn das übergeordnete Element vorhanden aber kein Objekt ist, gibt der Befehl einen FEHLER zurück.
+ Wenn das übergeordnete Element existiert und ein Objekt ist:
+ Wenn das Mitglied nicht existiert, wird ein neues Mitglied an das übergeordnete Objekt angehängt, wenn das übergeordnete Objekt das letzte untergeordnete Objekt im Pfad ist. Ansonsten gibt der Befehl den Fehler NONEXISTENT zurück.
+ Wenn das Mitglied existiert, wird sein Wert durch den JSON-Wert ersetzt.
Wenn der Pfad einen Array-Index aufruft:
+ Wenn das übergeordnete Element nicht vorhanden ist, gibt der Befehl den Fehler NONEXISTENT aus.
+ Wenn das übergeordnete Element vorhanden aber kein Array ist, gibt der Befehl einen FEHLER zurück.
+ Wenn das übergeordnete Element vorhanden ist, der Index jedoch außerhalb der Grenzen liegt, gibt der Befehl den Fehler OUTOFBOUNDARIES zurück.
+ Wenn das übergeordnete Element existiert und der Index gültig ist, wird das Element durch den neuen JSON-Wert ersetzt.
Wenn der Pfad ein Objekt oder Array aufruft, wird der Wert (Objekt oder Array) durch den neuen JSON-Wert ersetzt.
Syntax
```
JSON.SET [NX | XX]
```
[NX \$1 XX] Wo Sie 0 oder 1 von [NX \$1 XX] Identifikatoren haben können.
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (erforderlich) – Ein JSON-Pfad. Für einen neuen Schlüssel muss der JSON-Pfad der Stamm „.“ sein.
+ NX (optional) — Wenn es sich bei dem Pfad um das Stammverzeichnis handelt, legen Sie den Wert nur fest, wenn der Schlüssel nicht existiert. Das heißt, sie fügen ein neues Dokument ein. Wenn der Pfad nicht der Stamm ist, legen Sie den Wert nur fest, wenn der Pfad nicht existiert. Das heißt, Sie fügen einen Wert in das Dokument ein.
+ XX (optional) — Wenn es sich bei dem Pfad um das Stammverzeichnis handelt, legen Sie den Wert nur fest, wenn der Schlüssel vorhanden ist. Das heißt, Sie ersetzen das vorhandene Dokument. Wenn der Pfad nicht der Stamm ist, legen Sie den Wert nur fest, wenn der Pfad existiert. Das heißt, Sie aktualisieren den vorhandenen Wert.
**Ergebnis**
+ Einfache Zeichenfolge 'OK' bei Erfolg.
+ Null, wenn die NX- oder XX-Bedingungen nicht erfüllt sind.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{"a":1, "b":2, "c":3}}'
OK
127.0.0.1:6379> JSON.SET k1 $.a.* '0'
OK
127.0.0.1:6379> JSON.GET k1
"{\"a\":{\"a\":0,\"b\":0,\"c\":0}}"
127.0.0.1:6379> JSON.SET k2 . '{"a": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.SET k2 $.a[*] '0'
OK
127.0.0.1:6379> JSON.GET k2
"{\"a\":[0,0,0,0,0]}"
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"c":{"a":1, "b":2}, "e": [1,2,3,4,5]}'
OK
127.0.0.1:6379> JSON.SET k1 .c.a '0'
OK
127.0.0.1:6379> JSON.GET k1
"{\"c\":{\"a\":0,\"b\":2},\"e\":[1,2,3,4,5]}"
127.0.0.1:6379> JSON.SET k1 .e[-1] '0'
OK
127.0.0.1:6379> JSON.GET k1
"{\"c\":{\"a\":0,\"b\":2},\"e\":[1,2,3,4,0]}"
127.0.0.1:6379> JSON.SET k1 .e[5] '0'
(error) OUTOFBOUNDARIES Array index is out of bounds
```
# JSON.STRAPPEND
Hängt eine Zeichenfolge an die JSON-Zeichenfolgen im Pfad an.
Syntax
```
JSON.STRAPPEND [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
+ json\$1string (erforderlich) – Die JSON-Darstellung einer Zeichenfolge. Beachten Sie, dass eine JSON-Zeichenfolge in Anführungszeichen gesetzt werden muss. Zum Beispiel: ""Beispiel für eine Zeichenfolge""
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Ganzzahlen, die die neue Länge des Arrays bei jedem Pfad darstellen.
+ Wenn ein Wert im Pfad keine Zeichenfolge ist, ist der entsprechende Rückgabewert Null.
+ `SYNTAXERR`-Fehler, wenn das angegebene JSON-Argument keine gültige JSON-Zeichenfolge ist.
+ `NONEXISTENT`-Fehler, wenn der Pfad nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Ganzzahl, die neue Länge der Zeichenfolge.
+ Wenn mehrere Zeichenfolgenwerte ausgewählt wurden, gibt der Befehl die neue Länge der zuletzt aktualisierten Zeichenfolge zurück.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad keine Zeichenfolge ist.
+ `WRONGTYPE`-Fehler, wenn das angegebene JSON-Argument keine gültige JSON-Zeichenfolge ist.
+ `NONEXISTENT`-Fehler, wenn der Pfad nicht vorhanden ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRAPPEND k1 $.a.a '"a"'
1) (integer) 2
127.0.0.1:6379> JSON.STRAPPEND k1 $.a.* '"a"'
1) (integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 $.b.* '"a"'
1) (integer) 2
2) (nil)
127.0.0.1:6379> JSON.STRAPPEND k1 $.c.* '"a"'
1) (integer) 2
2) (integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 $.c.b '"a"'
1) (integer) 4
127.0.0.1:6379> JSON.STRAPPEND k1 $.d.* '"a"'
1) (nil)
2) (integer) 2
3) (nil)
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRAPPEND k1 .a.a '"a"'
(integer) 2
127.0.0.1:6379> JSON.STRAPPEND k1 .a.* '"a"'
(integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 .b.* '"a"'
(integer) 2
127.0.0.1:6379> JSON.STRAPPEND k1 .c.* '"a"'
(integer) 3
127.0.0.1:6379> JSON.STRAPPEND k1 .c.b '"a"'
(integer) 4
127.0.0.1:6379> JSON.STRAPPEND k1 .d.* '"a"'
(integer) 2
```
# JSON.STRLEN
Ruft die Länge des JSON-Zeichenfolgenwerts im Pfad ab.
Syntax
```
JSON.STRLEN [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Ganzzahlen, die die Länge des Zeichenfolgenwerts bei jedem Pfad darstellen.
+ Wenn ein Wert keine Zeichenfolge ist, ist der entsprechende Rückgabewert Null.
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Ganzzahl, die Länge der Zeichenfolge.
+ Wenn mehrere Zeichenfolgenwerte ausgewählt wurden, gibt der Befehl die erste Zeichenfolgenlänge zurück.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad keine Zeichenfolge ist.
+ `NONEXISTENT`-Fehler, wenn der Pfad nicht vorhanden ist.
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRLEN k1 $.a.a
1) (integer) 1
127.0.0.1:6379> JSON.STRLEN k1 $.a.*
1) (integer) 1
127.0.0.1:6379> JSON.STRLEN k1 $.c.*
1) (integer) 1
2) (integer) 2
127.0.0.1:6379> JSON.STRLEN k1 $.c.b
1) (integer) 2
127.0.0.1:6379> JSON.STRLEN k1 $.d.*
1) (nil)
2) (integer) 1
3) (nil)
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 $ '{"a":{"a":"a"}, "b":{"a":"a", "b":1}, "c":{"a":"a", "b":"bb"}, "d":{"a":1, "b":"b", "c":3}}'
OK
127.0.0.1:6379> JSON.STRLEN k1 .a.a
(integer) 1
127.0.0.1:6379> JSON.STRLEN k1 .a.*
(integer) 1
127.0.0.1:6379> JSON.STRLEN k1 .c.*
(integer) 1
127.0.0.1:6379> JSON.STRLEN k1 .c.b
(integer) 2
127.0.0.1:6379> JSON.STRLEN k1 .d.*
(integer) 1
```
# JSON.TOGGLE
Ein-/Ausblenden der Booleschen Werte zwischen true und false im Pfad.
Syntax
```
JSON.TOGGLE [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Ganzzahlen (0 - falsch, 1 - wahr), die den booleschen Wert in jedem Pfad repräsentieren.
+ Wenn ein Wert kein Boolescher Wert ist, ist der entsprechende Rückgabewert Null.
+ `NONEXISTENT` wenn der Dokumentschlüssel nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Zeichenfolge („true“/"false“), die den Booleschen Wert repräsentiert.
+ `NONEXISTENT` wenn der Dokumentschlüssel nicht vorhanden ist.
+ `WRONGTYPE`-Fehler, wenn der Wert im Pfad kein Boolescher Wert ist.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"a":true, "b":false, "c":1, "d":null, "e":"foo", "f":[], "g":{}}'
OK
127.0.0.1:6379> JSON.TOGGLE k1 $.*
1) (integer) 0
2) (integer) 1
3) (nil)
4) (nil)
5) (nil)
6) (nil)
7) (nil)
127.0.0.1:6379> JSON.TOGGLE k1 $.*
1) (integer) 1
2) (integer) 0
3) (nil)
4) (nil)
5) (nil)
6) (nil)
7) (nil)
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . true
OK
127.0.0.1:6379> JSON.TOGGLE k1
"false"
127.0.0.1:6379> JSON.TOGGLE k1
"true"
127.0.0.1:6379> JSON.SET k2 . '{"isAvailable": false}'
OK
127.0.0.1:6379> JSON.TOGGLE k2 .isAvailable
"true"
127.0.0.1:6379> JSON.TOGGLE k2 .isAvailable
"false"
```
# JSON.TYPE
Meldet die Art der Werte im jeweiligen Pfad.
Syntax
```
JSON.TYPE [path]
```
+ key (erforderlich) — Ein Valkey- oder Redis-OSS-Schlüssel vom JSON-Dokumenttyp.
+ path (optional) – Ein JSON-Pfad. Es gilt der Root-Standardwert, falls nicht angegeben.
**Ergebnis**
Wenn der Pfad eine erweiterte Syntax ist:
+ Array von Zeichenfolgen, die die Werte in jedem Pfad repräsentieren. Typ \$1„null“, „boolean“, „string“, „number“, „integer“, „object“ und „array"\$1.
+ Wenn ein Pfad nicht existiert, ist der entsprechende Ausgabewert null.
+ Leeres Array wenn der Dokumentschlüssel nicht vorhanden ist.
Wenn der Pfad eine eingeschränkte Syntax hat:
+ Zeichenfolge, Typ des Werts
+ Null, wenn der Dokumentschlüssel nicht vorhanden ist.
+ Null, wenn der JSON-Pfad ungültig ist oder nicht existiert.
**Beispiele**
Erweiterte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '[1, 2.3, "foo", true, null, {}, []]'
OK
127.0.0.1:6379> JSON.TYPE k1 $[*]
1) integer
2) number
3) string
4) boolean
5) null
6) object
7) array
```
Eingeschränkte Pfad-Syntax:
```
127.0.0.1:6379> JSON.SET k1 . '{"firstName":"John","lastName":"Smith","age":27,"weight":135.25,"isAlive":true,"address":{"street":"21 2nd Street","city":"New York","state":"NY","zipcode":"10021-3100"},"phoneNumbers":[{"type":"home","number":"212 555-1234"},{"type":"office","number":"646 555-4567"}],"children":[],"spouse":null}'
OK
127.0.0.1:6379> JSON.TYPE k1
object
127.0.0.1:6379> JSON.TYPE k1 .children
array
127.0.0.1:6379> JSON.TYPE k1 .firstName
string
127.0.0.1:6379> JSON.TYPE k1 .age
integer
127.0.0.1:6379> JSON.TYPE k1 .weight
number
127.0.0.1:6379> JSON.TYPE k1 .isAlive
boolean
127.0.0.1:6379> JSON.TYPE k1 .spouse
null
```
# Verschlagworten Sie Ihre Ressourcen ElastiCache
Um Ihnen bei der Verwaltung Ihrer Cluster und anderer ElastiCache Ressourcen zu helfen, können Sie jeder Ressource Ihre eigenen Metadaten in Form von Tags zuweisen. Mithilfe von Tags können Sie Ihre AWS Ressourcen auf unterschiedliche Weise kategorisieren, z. B. nach Zweck, Eigentümer oder Umgebung. Dies ist nützlich, wenn Sie viele Ressourcen desselben Typs haben — In diesem Fall können Sie schnell bestimmte Ressourcen basierend auf den zugewiesenen Tags (Markierungen) bestimmen. In diesem Thema werden Tags (Markierungen) und deren Erstellung beschrieben.
**Warnung**
Als bewährte Vorgehensweise empfehlen wir Ihnen, keine sensiblen Daten in Ihre Tags (Markierungen) aufzunehmen.
## Grundlagen zu Tags (Markierungen)
Ein Tag ist eine Bezeichnung, die Sie einer AWS Ressource zuweisen. Jeder Tag (Markierung) besteht aus einem Schlüssel und einem optionalen Wert, beides können Sie bestimmen. Mithilfe von Tags können Sie Ihre AWS Ressourcen auf unterschiedliche Weise kategorisieren, z. B. nach Zweck oder Eigentümer. Sie könnten beispielsweise eine Reihe von Stichwörtern für die ElastiCache Cluster Ihres Kontos definieren, mit deren Hilfe Sie den Besitzer und die Benutzergruppe jeder Instanz nachverfolgen können.
Wir empfehlen die Verwendung von Tag (Markierung)-Schlüsseln, die die Anforderungen der jeweiligen Ressourcentypen erfüllen. Die Verwendung einheitlicher Tag-Schlüssel vereinfacht das Verwalten der -Ressourcen. Sie können die Ressourcen auf Grundlage der hinzugefügten Tags (Markierungen) filtern und danach suchen. Weitere Informationen zum Implementieren einer effektiven Ressourcen-Markierungs-Strategie finden Sie im [-Whitepaper AWS Bewährte Methoden zur Markierung](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf).
Tags haben keine semantische Bedeutung ElastiCache und werden ausschließlich als Zeichenfolge interpretiert. Außerdem werden Tags (Markierungen) nicht automatisch Ihren Ressourcen zugewiesen. Sie können Tag (Markierung)-Schlüssel und -Werte bearbeiten und Tags (Markierungen) jederzeit von einer Ressource entfernen. Sie können den Wert eines Tags auf `null` setzen. Wenn Sie ein Tag (Markierung) mit demselben Schlüssel wie ein vorhandener Tag (Markierung) für die Ressource hinzufügen, wird der alte Wert mit dem neuen überschrieben. Wenn Sie eine Ressource löschen, werden alle Tags (Markierungen) der Ressource ebenfalls gelöscht. Wenn Sie einer Replikationsgruppe Tags hinzufügen oder löschen, werden außerdem die Tags aller Knoten in dieser Replikationsgruppe hinzugefügt oder entfernt.
Sie können mit Tags arbeiten, indem Sie die AWS-ManagementkonsoleAWS CLI, und die ElastiCache API verwenden.
Wenn Sie IAM verwenden, können Sie steuern, welche Benutzer in Ihrem AWS Konto berechtigt sind, Tags zu erstellen, zu bearbeiten oder zu löschen. Weitere Informationen finden Sie unter [Berechtigungen auf Ressourcenebene](IAM.ResourceLevelPermissions.md).
## Ressourcen, die markiert werden können
Sie können die meisten ElastiCache Ressourcen, die bereits in Ihrem Konto vorhanden sind, taggen. In der Tabelle unten werden die Ressourcen aufgeführt, die das Markieren unterstützen. Wenn Sie den verwenden AWS-Managementkonsole, können Sie mithilfe des [Tag-Editors](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) Tags auf Ressourcen anwenden. Auf einigen Ressourcenbildschirmen können Sie beim Erstellen der Ressource Tags für diese Ressource angeben, z. B. ein Tag mit dem Schlüssel „Name“ und einem von Ihnen angegebenen Wert. In den meisten Fällen wendet die Konsole Tags (Markierungen) direkt nach dem Erstellen der Ressource an und nicht während des Erstellens. Die Konsole kann Ressourcen nach dem **Name-Tag** organisieren, aber dieses Tag hat für den ElastiCache Dienst keine semantische Bedeutung.
Zudem können Sie mit einigen Aktionen zur Ressourcenerstellung Tags beim Erstellen einer Ressource angeben. Wenn Tags (Markierungen) nicht während der Ressourcenerstellung angewendet werden können, wird die Ressourcenerstellung rückgängig gemacht. Auf diese Weise werden Ressourcen entweder mit Tags (Markierungen) oder überhaupt nicht erstellt und keine Ressourcen verbleiben ohne Tags (Markierungen). Indem Sie Ressourcen zum Erstellungszeitpunkt markieren, müssen Sie anschließend keine benutzerdefinierten Skripts ausführen.
Wenn Sie die ElastiCache Amazon-API, die AWS CLI oder ein AWS SDK verwenden, können Sie den `Tags` Parameter für die entsprechende ElastiCache API-Aktion verwenden, um Tags anzuwenden. Diese sind:
+ `CreateServerlessCache`
+ `CreateCacheCluster`
+ `CreateReplicationGroup`
+ `CopyServerlessCacheSnapshot`
+ `CopySnapshot`
+ `CreateCacheParameterGroup`
+ `CreateCacheSecurityGroup`
+ `CreateCacheSubnetGroup`
+ `CreateServerlessCacheSnapshot`
+ `CreateSnapshot`
+ `CreateUserGroup`
+ `CreateUser`
+ `PurchaseReservedCacheNodesOffering`
In der folgenden Tabelle werden die ElastiCache Ressourcen beschrieben, die markiert werden können, und die Ressourcen, die bei der Erstellung mithilfe der ElastiCache API, der AWS CLI oder eines AWS SDK markiert werden können.
**Tagging-Unterstützung für Ressourcen ElastiCache**
| Ressource | Unterstützt Tags (Markierungen) | Unterstützt Markierung bei der Erstellung |
| --- | --- | --- |
| serverlesscache | Ja | Ja |
| parametergroup | Ja | Ja |
| securitygroup | Ja | Ja |
| subnetgroup | Ja | Ja |
| replicationgroup | Ja | Ja |
| Cluster | Ja | Ja |
| reserved-instance | Ja | Ja |
| serverlesscachesnapshot | Ja | Ja |
| Snapshot | Ja | Ja |
| user | Ja | Ja |
| usergroup | Ja | Ja |
**Anmerkung**
Globale Datenspeicher können nicht mit Tags versehen werden.
Sie können in Ihren IAM-Richtlinien tagbasierte Berechtigungen auf Ressourcenebene auf ElastiCache API-Aktionen anwenden, die das Tagging bei der Erstellung unterstützen, um eine detaillierte Kontrolle über die Benutzer und Gruppen zu implementieren, die Ressourcen bei der Erstellung taggen können. Ihre Ressourcen sind vor der Erstellung ordnungsgemäß gesichert – Tags, die sofort auf Ihre Ressourcen angewendet werden. Daher sind alle tagbasierten Berechtigungen auf Ressourcenebene, welche die Verwendung von Ressourcen steuern, sofort wirksam. Ihre Ressourcen können nachverfolgt und genauer erfasst werden. Sie können das Markieren neuer Ressourcen gewährleisten und steuern, welche Tag (Markierung)-Schlüssel und Werte für Ihre Ressourcen festgelegt sind.
Weitere Informationen finden Sie unter [Beispiele für das Taggen von Ressourcen](#Tagging-your-resources-example).
Weitere Informationen zur Markierung von Ressourcen für die Fakturierung finden Sie unter [Überwachung von Kosten mit Kostenzuordnungs-Tags](Tagging.md).
## Markieren von Caches und Snapshots
Die folgenden Regeln gelten für das Markieren im Rahmen von Anforderungsvorgängen:
+ **CreateReplicationGroup**:
+ Wenn die `--tags` Parameter `--primary-cluster-id` und in der Anforderung enthalten sind, werden die Anforderungs-Tags der Replikationsgruppe hinzugefügt und an alle Cluster in der Replikationsgruppe weitergegeben. Wenn der primäre Cluster über vorhandene Tags verfügt, werden diese mit den Anforderungs-Tags überschrieben, um konsistente Tags für alle Knoten zu gewährleisten.
Wenn keine Anforderungs-Tags vorhanden sind, werden die primären Cluster-Tags der Replikationsgruppe hinzugefügt und an alle Cluster weitergegeben.
+ Wenn `--snapshot-name` oder `--serverless-cache-snapshot-name` angegeben wird:
Wenn die Anforderung Tags enthält, wird die Replikationsgruppe nur mit diesen Tags markiert. Wenn die Anforderung keine Tags enthält, werden der Replikationsgruppe die Snapshot-Tags hinzugefügt.
+ Wenn `--global-replication-group-id` geliefert wird:
Wenn Tags in der Anfrage enthalten sind, werden die Anforderungs-Tags der Replikationsgruppe hinzugefügt und an alle Cluster weitergegeben.
+ **CreateCacheCluster** :
+ Wenn `--replication-group-id` geliefert wird:
Wenn Tags in der Anfrage enthalten sind, wird der Cluster nur mit diesen Tags gekennzeichnet. Wenn die Anfrage keine Tags enthält, erbt der Cluster die Tags der Replikationsgruppe anstelle der Tags des primären Clusters.
+ Wenn `--snapshot-name` geliefert wird:
Wenn Tags in der Anfrage enthalten sind, wird der Cluster nur mit diesen Tags gekennzeichnet. Wenn die Anfrage keine Tags enthält, werden die Snapshot-Tags dem Cluster hinzugefügt.
+ **CreateServerlessCache** :
+ Wenn die Anforderung Tags enthält, werden dem Serverless-Cache nur die Anforderungs-Tags hinzugefügt.
+ **CreateSnapshot** :
+ Wenn `--replication-group-id` geliefert wird:
Wenn die Anforderung Tags enthält, werden nur die Anfrage-Tags zum Snapshot hinzugefügt. Wenn die Anforderung keine Tags enthält, werden die Replikationsgruppen-Tags zum Snapshot hinzugefügt.
+ Wenn `--cache-cluster-id` geliefert wird:
Wenn die Anforderung Tags enthält, werden nur die Anfrage-Tags zum Snapshot hinzugefügt. Wenn die Anfrage keine Tags enthält, werden die Cluster-Tags dem Snapshot hinzugefügt.
+ Für automatische Snapshots:
Tags werden von den Replikationsgruppen-Tags weitergegeben.
+ **CreateServerlessCacheSnapshot** :
+ Wenn die Anforderung Tags enthält, werden dem Serverless-Cache-Snapshot nur die Anforderungs-Tags hinzugefügt.
+ **CopySnapshot** :
+ Wenn die Anforderung Tags enthält, werden nur die Request-Tags zum Snapshot hinzugefügt. Wenn die Anforderung keine Tags enthält, werden die Quell-Snapshot-Tags zum kopierten Snapshot hinzugefügt.
+ **CopyServerlessCacheSnapshot** :
+ Wenn die Anforderung Tags enthält, werden dem Serverless-Cache-Snapshot nur die Anforderungs-Tags hinzugefügt.
+ **AddTagsToResource**und **RemoveTagsFromResource**:
+ Die Tags added/removed stammen aus der Replikationsgruppe und die Aktion wird an alle Cluster in der Replikationsgruppe weitergegeben.
**Anmerkung**
**AddTagsToResource**und **RemoveTagsFromResource**kann nicht für Standardparameter und Sicherheitsgruppen verwendet werden.
+ **IncreaseReplicaCount**und **ModifyReplicationGroupShardConfiguration**:
+ Für alle neuen Cluster, die der Replikationsgruppe hinzugefügt wurden, werden dieselben Tags wie für die Replikationsgruppe angewendet.
## Tag-Einschränkungen
Die folgenden grundlegenden Einschränkungen gelten für Tags (Markierungen):
+ Maximale Anzahl von Tags (Markierungen) pro Ressource: 50
+ Jeder Tag (Markierung) muss für jede Ressource eindeutig sein. Jeder Tag (Markierung) kann nur einen Wert haben.
+ Maximale Schlüssellänge – 128 Unicode-Zeichen in UTF-8.
+ Maximale Wertlänge – 256 Unicode-Zeichen in UTF-8.
+ Obwohl ElastiCache jedes beliebige Zeichen in seinen Tags zulässig ist, können andere Dienste restriktiv sein. Folgende Zeichen sind dienstübergreifend zulässig: Buchstaben, Zahlen und Leerzeichen, die in UTF-8 dargestellt werden können, sowie die folgenden Zeichen: \$1 - = . \$1 : / @
+ Bei Tag-Schlüsseln und -Werten wird zwischen Groß- und Kleinschreibung unterschieden.
+ Das `aws:` Präfix ist für die AWS Verwendung reserviert. Wenn der Tag (Markierung) über einen Tag (Markierung)-Schlüssel mit diesem Präfix verfügt, können Sie den Schlüssel oder Wert des Tags (Markierung) nicht bearbeiten oder löschen. Tags (Markierungen) mit dem Präfix `aws:` werden nicht als Ihre Tags (Markierungen) pro Ressourcenlimit angerechnet.
Sie können Ressourcen nicht allein auf Grundlage ihrer Tags (Markierungen) beenden, anhalten oder löschen. Sie müssen den Ressourcenbezeichner angeben. Um Snapshots zu löschen, die Sie mit dem Tag (Markierung)-Schlüssel `DeleteMe` markiert haben, müssen Sie die `DeleteSnapshot`-Aktion mit den Ressourcenbezeichnern der Snapshots verwenden, z. B. `snap-1234567890abcdef0`.
Weitere Informationen zu ElastiCache Ressourcen, die Sie taggen können, finden Sie unter[Ressourcen, die markiert werden können](#Tagging-your-resources).
## Beispiele für das Taggen von Ressourcen
+ Einen serverlosen Cache mithilfe von Tags erstellen. In diesem Beispiel wird Memcached als Engine verwendet.
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine memcached
--tags Key="Cost Center", Value="1110001" Key="project",Value="XYZ"
```
+ Hinzufügen von Tags zu einem Serverless-Cache
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-east-1:111111222233:serverlesscache:my-cache \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ Hinzufügen von Tags zu einer Replikationsgruppe.
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-east-1:111111222233:replicationgroup:my-rg \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ Erstellen eines Cache-Clusters mithilfe von Tags.
```
aws elasticache create-cache-cluster \
--cluster-id testing-tags \
--cluster-description cluster-test \
--cache-subnet-group-name test \
--cache-node-type cache.t2.micro \
--engine valkey \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ Erstellen eines Cache-Clusters mithilfe von Tags. In diesem Beispiel wird Redis als Engine verwendet.
```
aws elasticache create-cache-cluster \
--cluster-id testing-tags \
--cluster-description cluster-test \
--cache-subnet-group-name test \
--cache-node-type cache.t2.micro \
--engine valkey \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ Erstellen eines Serverless-Snapshots mit Tags. In diesem Beispiel wird Memcached als Engine verwendet.
```
aws elasticache create-serverless-cache-snapshot \
--serverless-cache-name testing-tags \
--serverless-cache-snapshot-name bkp-testing-tags-scs \
--tags Key="work",Value="foo"
```
+ Erstellen eines Snapshots mit Tags.
Snapshots sind derzeit nur für Redis verfügbar. Wenn Sie in diesem Fall Tags auf Anfrage hinzufügen, erhält der Snapshot nur die Anfrage-Tags, selbst wenn die Replikationsgruppe Tags enthält.
```
aws elasticache create-snapshot \
--replication-group-id testing-tags \
--snapshot-name bkp-testing-tags-rg \
--tags Key="work",Value="foo"
```
## Beispiele für Tag-basierte Zugriffssteuerungsrichtlinien
1. `AddTagsToResource`-Aktion für einen Cluster nur zulassen, wenn der Cluster das Tag „Project=XYZ“ hat.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "XYZ"
}
}
}
]
}
```
------
1. Zulassen von `RemoveTagsFromResource`-Aktion von einer Replikationsgruppe, wenn sie die Tags „Project“ und „Service“ enthält und Schlüssel sich von „Project“ und „Service“ unterscheiden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:RemoveTagsFromResource",
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Service": "Elasticache",
"aws:ResourceTag/Project": "XYZ"
},
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Project",
"Service"
]
}
}
}
]
}
```
------
1. Zulassen von `AddTagsToResource` zu einer Ressource nur dann, wenn sich Tags von „Project“ und „Service“ unterscheiden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:*:*"
],
"Condition": {
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Service",
"Project"
]
}
}
}
]
}
```
------
1. Verweigerung `CreateReplicationGroup`-Aktion, wenn die Anfrage `Tag Project=Foo` enthält.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "elasticache:CreateReplicationGroup",
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "Foo"
}
}
}
]
}
```
------
1. Verweigerung `CopySnapshot`-Aktion, wenn der Quell-Snapshot das Tag „Project=XYZ“ hat und das Anforderungs-Tag Service=Elasticache ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "elasticache:CopySnapshot",
"Resource": [
"arn:aws:elasticache:*:*:snapshot:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "XYZ",
"aws:RequestTag/Service": "Elasticache"
}
}
}
]
}
```
------
1. Verweigern der Aktion `CreateCacheCluster`, wenn das Anforderungs-Tag `Project` fehlt oder nicht `Dev`, `QA` oder `Prod` entspricht.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:parametergroup:*",
"arn:aws:elasticache:*:*:subnetgroup:*",
"arn:aws:elasticache:*:*:securitygroup:*",
"arn:aws:elasticache:*:*:replicationgroup:*"
]
},
{
"Effect": "Deny",
"Action": [
"elasticache:CreateCacheCluster"
],
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"Null": {
"aws:RequestTag/Project": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"elasticache:CreateCacheCluster",
"elasticache:AddTagsToResource"
],
"Resource": "arn:aws:elasticache:*:*:cluster:*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": [
"Dev",
"Prod",
"QA"
]
}
}
}
]
}
```
------
Weitere Informationen zu Bedingungsschlüsseln finden Sie unter [Verwenden von Bedingungsschlüssel](IAM.ConditionKeys.md).
# Überwachung von Kosten mit Kostenzuordnungs-Tags
Wenn Sie Ihren Ressourcen in Amazon Kostenzuordnungs-Tags hinzufügen ElastiCache, können Sie die Kosten verfolgen, indem Sie die Ausgaben auf Ihren Rechnungen nach Ressourcen-Tag-Werten gruppieren.
Ein ElastiCache Kostenzuweisungs-Tag ist ein Schlüssel-Wert-Paar, das Sie definieren und einer Ressource zuordnen. ElastiCache Bei Schlüsseln und Werten werden Groß-/Kleinschreibung berücksichtigt. Sie können einen Tag-Schlüssel verwenden, um eine Kategorie zu definieren, und der Tag-Wert kann ein Element in dieser Kategorie sein. So könnten Sie beispielsweise den Tag-Schlüssel `CostCenter` und den Tag-Wert `10010` definieren, um anzugeben, dass die Ressource der Kostenstelle 10010 zugewiesen ist. Sie können mit Tags auch Ressourcen kennzeichnen, die zu Test- oder Produktionszwecken verwendet werden, indem Sie einen Schlüssel wie z. B. `Environment` und Werte wie z. B. `test` oder `production` verwenden. Wir empfehlen, einheitliche Tag-Schlüssel zu verwenden, um die mit Ihren Ressourcen verknüpften Kosten einfacher verfolgen zu können.
Verwenden Sie Kostenzuordnungs-Tags, um Ihre AWS Rechnung so zu organisieren, dass sie Ihrer eigenen Kostenstruktur entspricht. Melden Sie sich dazu an, um Ihre AWS Kontorechnung mit den Tag-Schlüsselwerten zu erhalten. Um dann die Kosten kombinierter Ressourcen anzuzeigen, organisieren Sie Ihre Fakturierungsinformationen nach Ressourcen mit gleichen Tag-Schlüsselwerten. Beispielsweise können Sie mehrere Ressourcen mit einem bestimmten Anwendungsnamen markieren und dann Ihre Fakturierungsinformationen so organisieren, dass Sie die Gesamtkosten dieser Anwendung über mehrere Services hinweg sehen können.
Sie können auch Tags miteinander kombinieren, um Kosten detaillierter zu verfolgen. Um beispielsweise Ihre Kosten für Services nach Region zu verfolgen, könnten Sie die Tag-Schlüssel `Service` und `Region` verwenden. Für eine Ressource lauten die Werte möglicherweise `ElastiCache` und `Asia Pacific (Singapore)` und für eine andere Ressource lauten sie `ElastiCache` und `Europe (Frankfurt)`. Sie können dann Ihre ElastiCache Gesamtkosten nach Regionen aufgeschlüsselt sehen. Weitere Informationen finden Sie unter [Verwendung von Kostenzuordnungs-Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) im *AWS Billing-Benutzerhandbuch*.
Sie können ElastiCache knotenbasierten ElastiCache Clustern Tags für die Kostenzuweisung hinzufügen. Wenn Sie ein Tag hinzufügen, auflisten, ändern, kopieren oder entfernen, wird die Operation nur auf die angegebenen Cluster angewendet.
**Eigenschaften von ElastiCache Kostenzuweisungs-Tags**
+ Kostenzuweisungs-Tags werden auf ElastiCache Ressourcen angewendet, die in CLI- und API-Vorgängen als ARN angegeben sind. Der Ressourcentyp ist ein „Cluster“.
Beispiel-ARN: `arn:aws:elasticache::::`
Beispiel-ARN: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
+ Der Tag-Schlüssel ist der erforderliche Name des Tags. Der Zeichenfolgenwert kann aus 1 bis 128 Unicode-Zeichen bestehen. Ihm darf kein `aws:` als Präfix vorangestellt werden. Die Zeichenfolge darf nur Unicode-Zeichen, Ziffern, Leerzeichen, Unterstriche (\$1), Punkte (.), Doppelpunkte (:), Backslashes (\$1), Gleichheitszeichen (=), Pluszeichen (\$1), Trennstriche (-) oder At-Zeichen (@) enthalten.
+ Der Tag-Wert ist der optionale Wert des Tags. Der Zeichenfolgenwert kann aus 1 bis 256 Unicode-Zeichen bestehen. Ihm darf kein `aws:` als Präfix vorangestellt werden. Die Zeichenfolge darf nur Unicode-Zeichen, Ziffern, Leerzeichen, Unterstriche (\$1), Punkte (.), Doppelpunkte (:), Backslashes (\$1), Gleichheitszeichen (=), Pluszeichen (\$1), Trennstriche (-) oder At-Zeichen (@) enthalten.
+ Eine ElastiCache Ressource kann maximal 50 Tags haben.
+ Die Werte innerhalb eines Tag-Satzes müssen nicht eindeutig sein. Beispiel: In einem Tag-Satz könnten die Schlüssel `Service` und `Application` beide den Wert `ElastiCache` besitzen.
AWS wendet Ihren Tags keine semantische Bedeutung an. Tags werden ausschließlich als Zeichenketten interpretiert.AWS setzt nicht automatisch irgendwelche Tags für eine ElastiCache Ressource.
# Verwaltung Ihrer Kostenzuweisungs-Tags mithilfe der AWS CLI
Sie können die verwenden, AWS CLI um Kostenzuordnungs-Tags hinzuzufügen, zu ändern oder zu entfernen.
Kostenzuweisungs-Tags werden auf ElastiCache Cluster angewendet. Der Cluster, der gekennzeichnet werden soll, wird mit einem ARN (Amazon Resource Name) angegeben.
Beispiel-ARN: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [Stichwörter auflisten mit dem AWS CLI](#Tagging.Managing.CLI.List)
+ [Hinzufügen von Tags mit dem AWS CLI](#Tagging.Managing.CLI.Add)
+ [Ändern von Tags mit dem AWS CLI](#Tagging.Managing.CLI.Modify)
+ [Entfernen von Tags mit dem AWS CLI](#Tagging.Managing.CLI.Remove)
## Stichwörter auflisten mit dem AWS CLI
Sie können die verwenden AWS CLI , um Tags für eine vorhandene ElastiCache Ressource aufzulisten, indem Sie die [list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html) Operation verwenden.
Der folgende Code verwendet die AWS CLI , um die Tags auf dem Memcached-Cluster `my-cluster` in der Region us-west-2 aufzulisten.
Für Linux, macOS oder Unix:
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
Für Windows:
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
Der folgende Code verwendet die AWS CLI , um die Tags auf dem Valkey- oder Redis-OSS-Knoten `my-cluster-001` im `my-cluster` Cluster in der Region us-west-2 aufzulisten.
Für Linux, macOS oder Unix:
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
Für Windows:
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
Die Ausgabe dieser Operation sieht in etwa folgendermaßen aus und besteht aus einer Liste aller Tags für die Ressource.
```
{
"TagList": [
{
"Value": "10110",
"Key": "CostCenter"
},
{
"Value": "EC2",
"Key": "Service"
}
]
}
```
Wenn die Ressource keine Tags enthält, ist die Ausgabe leer. TagList
```
{
"TagList": []
}
```
Weitere Informationen finden Sie unter AWS CLI für ElastiCache [list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html).
## Hinzufügen von Tags mit dem AWS CLI
Sie können das verwenden AWS CLI , um einer vorhandenen ElastiCache Ressource mithilfe der [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html) CLI-Operation Tags hinzuzufügen. Wenn das Tag in der Ressource nicht vorhanden ist, werden Schlüssel und Wert zur Ressource hinzugefügt. Wenn der Schlüssel in der Ressource bereits vorhanden ist, wird der diesem Schlüssel zugeordnete Wert auf den neuen Wert aktualisiert.
Der folgende Code verwendet die AWS CLI , um die Schlüssel `Service` und `Region` mit den Werten `elasticache` `us-west-2` jeweils zum Knoten `my-cluster-001` im Cluster `my-cluster` in der Region us-west-2 hinzuzufügen.
**Memcached**
Für Linux, macOS oder Unix:
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster \
--tags Key=Service,Value=elasticache \
Key=Region,Value=us-west-2
```
Für Windows:
```
aws elasticache add-tags-to-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster ^
--tags Key=Service,Value=elasticache ^
Key=Region,Value=us-west-2
```
**Redis**
Für Linux, macOS oder Unix:
```
aws elasticache add-tags-to-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 \
--tags Key=Service,Value=elasticache \
Key=Region,Value=us-west-2
```
Für Windows:
```
aws elasticache add-tags-to-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 ^
--tags Key=Service,Value=elasticache ^
Key=Region,Value=us-west-2
```
Die Ausgabe dieses Operation sieht in etwa folgendermaßen aus und besteht aus einer Liste aller Tags für die Ressource nach der Operation.
```
{
"TagList": [
{
"Value": "elasticache",
"Key": "Service"
},
{
"Value": "us-west-2",
"Key": "Region"
}
]
}
```
Weitere Informationen finden Sie unter für. AWS CLI ElastiCache [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html)
Sie können den auch verwenden AWS CLI , um einem Cluster Tags hinzuzufügen, wenn Sie mithilfe des Vorgangs einen neuen Cluster erstellen[create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html). Sie können keine Tags hinzufügen, wenn Sie einen Cluster mithilfe der ElastiCache Managementkonsole erstellen. Nachdem der Cluster erstellt wurde, können Sie über die Konsole Tags zum Cluster hinzufügen.
## Ändern von Tags mit dem AWS CLI
Sie können den verwenden AWS CLI , um die Tags auf einem ElastiCache Cluster zu ändern.
Ändern Sie Tags wie folgt:
+ Verwenden Sie [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html) zum Hinzufügen eines neuen Tags und Wertes oder zum Ändern des zu einem vorhandenen Tag gehörenden Wertes.
+ Verwenden Sie [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html) zum Entfernen angegebener Tags aus der Ressource.
zum Entfernen von Tags aus dem Cluster.
## Entfernen von Tags mit dem AWS CLI
Sie können den verwenden AWS CLI , um Tags aus einem vorhandenen ElastiCache Memcached-Cluster zu entfernen, indem Sie den [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html) Vorgang verwenden.
Für Memcached verwendet der folgende Code die, AWS CLI um die Tags mit den Schlüsseln `Service` und `Region` aus dem Knoten `my-cluster-001` im Cluster `my-cluster` in der Region us-west-2 zu entfernen.
Für Linux, macOS oder Unix:
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster \
--tag-keys PM Service
```
Für Windows:
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster ^
--tag-keys PM Service
```
Für Redis OSS verwendet der folgende Code die, AWS CLI um die Tags mit den Schlüsseln `Service` und `Region` vom Knoten `my-cluster-001` im Cluster `my-cluster` in der Region us-west-2 zu entfernen.
Für Linux, macOS oder Unix:
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 \
--tag-keys PM Service
```
Für Windows:
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 ^
--tag-keys PM Service
```
Die Ausgabe dieses Operation sieht in etwa folgendermaßen aus und besteht aus einer Liste aller Tags für die Ressource nach der Operation.
```
{
"TagList": []
}
```
Weitere Informationen finden Sie unter für. AWS CLI ElastiCache [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html)
# Verwaltung Ihrer Kostenzuweisungs-Tags mithilfe der ElastiCache API
Sie können die ElastiCache API verwenden, um Kostenzuweisungs-Tags hinzuzufügen, zu ändern oder zu entfernen.
Kostenzuweisungs-Tags werden ElastiCache für Memcached-Cluster angewendet. Der Cluster, der gekennzeichnet werden soll, wird mit einem ARN (Amazon Resource Name) angegeben.
Beispiel-ARN: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [Tags mithilfe der API auflisten ElastiCache](#Tagging.Managing.API.List)
+ [Hinzufügen von Tags mithilfe der API ElastiCache](#Tagging.Managing.API.Add)
+ [Ändern von Tags mithilfe der ElastiCache API](#Tagging.Managing.API.Modify)
+ [Tags mithilfe der ElastiCache API entfernen](#Tagging.Managing.API.Remove)
## Tags mithilfe der API auflisten ElastiCache
Sie können die ElastiCache API verwenden, um Tags für eine vorhandene Ressource aufzulisten, indem Sie den [ListTagsForResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListTagsForResource.html) Vorgang verwenden.
Für Memcached verwendet der folgende Code die ElastiCache API, um die Tags auf der Ressource `my-cluster` in der Region us-west-2 aufzulisten.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListTagsForResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Für Redis OSS verwendet der folgende Code die ElastiCache API, um die Tags auf der Ressource `my-cluster-001` in der Region us-west-2 aufzulisten.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListTagsForResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
## Hinzufügen von Tags mithilfe der API ElastiCache
Sie können die ElastiCache API verwenden, um einem vorhandenen ElastiCache Cluster Tags hinzuzufügen, indem Sie den [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) Vorgang verwenden. Wenn das Tag in der Ressource nicht vorhanden ist, werden Schlüssel und Wert zur Ressource hinzugefügt. Wenn der Schlüssel in der Ressource bereits vorhanden ist, wird der diesem Schlüssel zugeordnete Wert auf den neuen Wert aktualisiert.
Der folgende Code verwendet die ElastiCache API, um die Schlüssel `Service` und `Region` mit den Werten `elasticache` `us-west-2` bzw. Bei Memcached wird dies auf die Ressource angewendet. `my-cluster` Für Redis OSS wird dies auf die Ressource `my-cluster-001` in der Region US-West-2 angewendet.
**Memcached**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=AddTagsToResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Tags.member.1.Key=Service
&Tags.member.1.Value=elasticache
&Tags.member.2.Key=Region
&Tags.member.2.Value=us-west-2
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
**Redis**
```
https://elasticache.us-west-2.amazonaws.com/
?Action=AddTagsToResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Tags.member.1.Key=Service
&Tags.member.1.Value=elasticache
&Tags.member.2.Key=Region
&Tags.member.2.Value=us-west-2
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Weitere Informationen finden Sie [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) in der *Amazon ElastiCache API-Referenz*.
## Ändern von Tags mithilfe der ElastiCache API
Sie können die ElastiCache API verwenden, um die Tags in einem ElastiCache Cluster zu ändern.
Den Wert eines Tags ändern:
+ Verwenden Sie die Operation [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) zum Hinzufügen eines neuen Tags und Wertes oder zum Ändern des Wertes eines vorhandenen Tags.
+ Verwenden Sie [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) zum Entfernen von Tags aus der Ressource.
Die Ausgabe beider Operationen ist eine Liste der Tags und deren Werte für die angegebene Ressource.
Verwenden Sie [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) zum Entfernen von Tags aus der Ressource.
## Tags mithilfe der ElastiCache API entfernen
Sie können die ElastiCache API verwenden, um Tags aus einem vorhandenen ElastiCache Memcached-Cluster zu entfernen, indem Sie den [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) Vorgang verwenden.
Der folgende Code verwendet die ElastiCache API, um die Tags mit den Schlüsseln `Service` und `Region` vom Knoten `my-cluster-001` im Cluster `my-cluster` in der Region us-west-2 zu entfernen.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=RemoveTagsFromResource
&ResourceName=arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&TagKeys.member.1=Service
&TagKeys.member.2=Region
&Version=2015-02-02
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
# Verwenden des Amazon ElastiCache Well-Architected-Objektivs
In diesem Abschnitt wird Amazon ElastiCache Well-Architected Lens beschrieben, eine Sammlung von Entwurfsprinzipien und Anleitungen für die Gestaltung gut ElastiCache strukturierter Workloads.
+ Die ElastiCache Linse ist eine Ergänzung zum [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html).
+ Jede Säule hat eine Reihe von Fragen, die helfen sollen, die Diskussion rund um eine ElastiCache Architektur zu beginnen.
+ Jede Frage enthält eine Reihe von führenden Methoden sowie deren Ergebnisse für die Berichterstattung.
+ *Erforderlich* – notwendig vor dem Wechsel in die Produktion (sofern kein hohes Risiko besteht)
+ *Am besten* – bestmöglicher Zustand für einen Kunden
+ *Gut* – unsere Empfehlungen für den Kunden (sofern kein mittleres Risiko besteht)
+ Well-Architected-Terminologie
+ [Komponente](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html) — Code, Konfiguration und AWS Ressourcen, die zusammen eine Anforderung erfüllen. Komponenten interagieren mit anderen Komponenten und entsprechen in Microservice-Architekturen häufig einem Service.
+ [Arbeitslast](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html) — Eine Reihe von Komponenten, die zusammen einen geschäftlichen Nutzen bieten. Beispiele für Workloads sind Marketing-Websites, E-Commerce-Websites, das Backend für eine mobile App, Analyseplattformen usw.
**Anmerkung**
Dieses Handbuch wurde nicht aktualisiert und enthält nun Informationen zum ElastiCache serverlosen Caching und zur neuen Valkey-Engine.
**Topics**
+ [Säule Operational Excellence von Amazon ElastiCache Well-Architected Lens](OperationalExcellencePillar.md)
+ [Sicherheitssäule von Amazon ElastiCache Well-Architected Lens](SecurityPillar.md)
+ [Säule der Zuverlässigkeit von Amazon ElastiCache Well-Architected Lens](ReliabilityPillar.md)
+ [Säule der Leistung und Effizienz von Amazon ElastiCache Well-Architected Lens](PerformanceEfficiencyPillar.md)
+ [Säule zur ElastiCache Kostenoptimierung bei Amazon Well-Architected Lens](CostOptimizationPillar.md)
# Säule Operational Excellence von Amazon ElastiCache Well-Architected Lens
Die Säule „Operational Excellence“ konzentriert sich auf den Betrieb und die Überwachung von Systemen, um einen Mehrwert für das Unternehmen zu schaffen, sowie auf die kontinuierliche Verbesserung von Prozessen und Verfahren. Zu den wichtigsten Themen gehören die Automatisierung von Änderungen, die Reaktion auf Ereignisse und die Definition von Standards für die Verwaltung des täglichen Betriebs.
**Topics**
+ [OE 1: Wie verstehen Sie Warnmeldungen und Ereignisse, die von Ihrem ElastiCache Cluster ausgelöst werden, und wie reagieren Sie darauf?](#OperationalExcellencePillarOE1)
+ [OE 2: Wann und wie skalieren Sie Ihre vorhandenen Cluster? ElastiCache](#OperationalExcellencePillarOE2)
+ [OE 3: Wie verwalten Sie Ihre ElastiCache Cluster-Ressourcen und pflegen Ihren Cluster up-to-date?](#OperationalExcellencePillarOE3)
+ [OE 4: Wie verwalten Sie die Verbindungen der Kunden zu Ihren ElastiCache Clustern?](#OperationalExcellencePillarOE4)
+ [OE 5: Wie werden ElastiCache Komponenten für einen Workload bereitgestellt?](#OperationalExcellencePillarOE5)
+ [OE 6: Wie planen und minimieren Sie Ausfälle?](#OperationalExcellencePillarOE6)
+ [OE 7: Wie behebt man Valkey- oder Redis OSS-Engine-Ereignisse?](#OperationalExcellencePillarOE7)
## OE 1: Wie verstehen Sie Warnmeldungen und Ereignisse, die von Ihrem ElastiCache Cluster ausgelöst werden, und wie reagieren Sie darauf?
**Einführung auf Fragenebene:** Wenn Sie ElastiCache Cluster betreiben, können Sie optional Benachrichtigungen und Warnmeldungen erhalten, wenn bestimmte Ereignisse eintreten. ElastiCacheprotokolliert standardmäßig [Ereignisse](ECEvents.md), die sich auf Ihre Ressourcen beziehen, z. B. Failover, Knotenaustausch, Skalierungsvorgänge, geplante Wartungsarbeiten und mehr. Jedes Ereignis enthält das Datum und die Uhrzeit, den Quellnamen und den Quelltyp sowie eine Beschreibung.
**Vorteil auf Fragenebene: **Wenn Sie in der Lage sind, die zugrundeliegenden Ursachen für die Ereignisse, die von Ihrem Cluster generierte Warnmeldungen auslösen, zu verstehen und zu verwalten, können Sie effektiver arbeiten und angemessen auf Ereignisse reagieren.
+ **[Erforderlich]** [Überprüfen Sie die Ereignisse, die ElastiCache auf der ElastiCache Konsole (nachdem Sie Ihre Region ausgewählt haben) oder mithilfe des Befehls [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) (CLI) von [Amazon Command Line Interface](https://aws.amazon.com/cli) (AWS CLI) und der ElastiCache API generiert wurden.](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html) Konfigurieren Sie ElastiCache das Senden von Benachrichtigungen für wichtige Cluster-Ereignisse mithilfe von Amazon Simple Notification Service (Amazon SNS). Wenn Sie Amazon SNS mit Ihren Clustern verwenden, können Sie bei Ereignissen programmgesteuert Maßnahmen ergreifen. ElastiCache
+ Es gibt zwei große Ereigniskategorien: aktuelle und geplante Ereignisse. Die Liste der aktuellen Ereignisse umfasst: Erstellung und Löschung von Ressourcen, Skalierungsvorgänge, Failover, Neustart des Knotens, Erstellung eines Snapshots, Änderung der Cluster-Parameter, Verlängerung des CA-Zertifikats, Fehlerereignisse (Fehler bei der Cluster-Bereitstellung – VPC oder ENI, Skalierungsfehler – ENI- und Snapshot-Fehler). Die Liste der geplanten Ereignisse umfasst: Knoten, dessen Austausch während des Wartungsfensters geplant ist, und Knotenaustausch, der verschoben wurde.
+ Auch wenn Sie auf einige dieser Ereignisse möglicherweise nicht sofort reagieren müssen, ist es wichtig, sich zunächst alle Fehlerereignisse anzusehen:
+ ElastiCache:AddCacheNodeFailed
+ ElastiCache:CacheClusterProvisioningFailed
+ ElastiCache:CacheClusterScalingFailed
+ ElastiCache:CacheNodesRebooted
+ ElastiCache: SnapshotFailed (Nur Valkey oder Redis OSS)
+ **[Ressourcen]:**
+ [Verwaltung von ElastiCache Amazon SNS SNS-Benachrichtigungen](ECEvents.SNS.md)
+ [Ereignisbenachrichtigungen und Amazon SNS](ElastiCacheSNS.md)
+ **[Am besten]** Nutzen Sie AWS Produkt- und Servicefunktionen wie SNS und Lambda Functions, um Reaktionen auf Ereignisse zu automatisieren. Halten Sie sich an bewährte Methoden, indem Sie kleine, häufige, umkehrbare Änderungen als Code vornehmen, um Ihre Operationen im Laufe der Zeit weiterzuentwickeln. Sie sollten CloudWatch Amazon-Metriken verwenden, um Ihre Cluster zu überwachen.
**[Ressourcen]:** [Überwachen Sie ElastiCache (Cluster-Modus deaktiviert) Lesereplikat-Endpunkte mit AWS Lambda, Amazon Route 53 und Amazon SNS für einen Anwendungsfall,](https://aws.amazon.com/blogs/database/monitor-amazon-elasticache-for-redis-cluster-mode-disabled-read-replica-endpoints-using-aws-lambda-amazon-route-53-and-amazon-sns/) der Lambda und SNS verwendet.
## OE 2: Wann und wie skalieren Sie Ihre vorhandenen Cluster? ElastiCache
**Einführung auf Fragenebene:** Die richtige Größe Ihres ElastiCache Clusters ist ein Balanceakt, der bei jeder Änderung der zugrunde liegenden Workload-Typen bewertet werden muss. Ihr Ziel ist es, mit der richtigen Größe für Ihren Workload zu arbeiten.
**Vorteil auf Fragenebene: **Eine Überlastung Ihrer Ressourcen kann zu einer erhöhten Latenz und einer insgesamt verringerten Leistung führen. Eine Unterauslastung kann andererseits zu einer Überbereitstellung von Ressourcen bei nicht optimaler Kostenoptimierung führen. Durch die richtige Dimensionierung Ihrer Umgebungen können Sie ein Gleichgewicht zwischen Leistungseffizienz und Kostenoptimierung erreichen. Um eine Über- oder Unterauslastung Ihrer Ressourcen zu beheben, ElastiCache können Sie in zwei Dimensionen skalieren. Sie können vertikal skalieren, indem Sie die Knotenkapazität erhöhen oder verringern. Sie können auch horizontal skalieren, indem Sie Knoten hinzufügen und entfernen.
+ **[Erforderlich]** Die Überauslastung der CPU und des Netzwerks auf den Primärknoten sollte dadurch behoben werden, dass die Lesevorgänge ausgelagert und an die Replikatknoten umgeleitet werden. Verwenden Sie Replikatknoten für Lesevorgänge, um die Auslastung des Primärknotens zu reduzieren. Dies kann in Ihrer Valkey- oder Redis OSS-Clientbibliothek konfiguriert werden, indem Sie eine Verbindung zum ElastiCache Reader-Endpunkt herstellen, wenn der Clustermodus deaktiviert ist, oder indem Sie den Befehl READONLY verwenden, wenn der Clustermodus aktiviert ist.
**[Ressourcen]:**
+ [Verbindungsendpunkte finden in ElastiCache](Endpoints.md)
+ [Richtige Clustergröße](https://aws.amazon.com/blogs/database/five-workload-characteristics-to-consider-when-right-sizing-amazon-elasticache-redis-clusters/)
+ [READONLY-Befehl](https://valkey.io/commands/readonly)
+ **[Erforderlich]** Überwachen Sie die Auslastung kritischer Clusterressourcen wie CPU, Arbeitsspeicher und Netzwerk. Die Auslastung dieser spezifischen Clusterressourcen muss nachverfolgt werden, um eine Entscheidung für eine Skalierung und die Art des Skalierungsvorgangs treffen zu können. Wenn der ElastiCache Clustermodus deaktiviert ist, können Primär- und Replikatknoten vertikal skaliert werden. Replikatknoten können auch horizontal von 0 auf 5 Knoten skaliert werden. Wenn der Clustermodus aktiviert ist, gilt dasselbe für jeden Shard Ihres Clusters. Darüber hinaus können Sie die Anzahl der Shards erhöhen oder reduzieren.
**[Ressourcen]:**
+ [Überwachung von Best Practices ElastiCache mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [Skalierung von ElastiCache Clustern für Valkey und Redis OSS](Scaling.md)
+ [Skalierung von ElastiCache Clustern für Memcached](Scaling.md)
+ **[Am besten]** Wenn Sie Trends im Zeitverlauf überwachen, können Sie Workload-Änderungen erkennen, die bei punktueller Überwachung unbemerkt bleiben würden. Um längerfristige Trends zu erkennen, verwenden Sie CloudWatch Metriken, um nach längeren Zeiträumen zu suchen. Die Erkenntnisse aus der Beobachtung von CloudWatch Kennzahlen über längere Zeiträume sollten als Grundlage für Ihre Prognose zur Auslastung der Cluster-Ressourcen dienen. CloudWatch Datenpunkte und Metriken sind für bis zu 455 Tage verfügbar.
**[Ressourcen]:**
+ [Überwachung ElastiCache mit CloudWatch Metriken](CacheMetrics.md)
+ [Überwachung von Memcached mit Metriken CloudWatch ](CacheMetrics.md)
+ [Überwachung von Best Practices ElastiCache mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Optimal]** Wenn Ihre ElastiCache Ressourcen damit erstellt werden, empfiehlt CloudFormation es sich, Änderungen mithilfe von CloudFormation Vorlagen vorzunehmen, um die betriebliche Konsistenz zu wahren und unverwaltete Konfigurationsänderungen und Stack-Drifts zu vermeiden.
**[Ressourcen]:**
+ [ElastiCache Referenz zum Ressourcentyp für CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ **[Am besten]** Automatisieren Sie Ihre Skalierungsvorgänge mithilfe von Cluster-Betriebsdaten und definieren Sie Schwellenwerte für CloudWatch die Einrichtung von Alarmen. Verwenden Sie CloudWatch Events und Simple Notification Service (SNS), um Lambda-Funktionen auszulösen, und führen Sie eine ElastiCache API aus, um Ihre Cluster automatisch zu skalieren. Ein Beispiel wäre, Ihrem Cluster einen Shard hinzuzufügen, wenn die Metrik `EngineCPUUtilization` über einen längeren Zeitraum 80 % erreicht. Eine weitere Option wäre die Verwendung von `DatabaseMemoryUsedPercentages` für einen speicherbasierten Schwellenwert.
**[Ressourcen]:**
+ [Amazon CloudWatch Alarms verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Was sind CloudWatch Amazon-Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Verwendung AWS Lambda mit Amazon Simple Notification Service](https://docs.aws.amazon.com/lambda/latest/dg/with-sns.html)
+ [ElastiCache API Referenz](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
## OE 3: Wie verwalten Sie Ihre ElastiCache Cluster-Ressourcen und pflegen Ihren Cluster up-to-date?
**Einführung auf Fragenebene:** Wenn Sie in großem Maßstab arbeiten, ist es wichtig, dass Sie in der Lage sind, all Ihre Ressourcen zu lokalisieren und zu identifizieren. ElastiCache Bei der Einführung neuer Anwendungsfunktionen müssen Sie für eine Symmetrie der Cluster-Versionen in all Ihren ElastiCache Umgebungstypen sorgen: Entwicklung, Testen und Produktion. Mithilfe von Ressourcenattributen können Sie Umgebungen für unterschiedliche betriebliche Ziele trennen, z. B. bei der Einführung neuer Funktionen und der Aktivierung neuer Sicherheitsmechanismen.
**Vorteil auf Fragenebene: **Die Trennung Ihrer Entwicklungs-, Test- und Produktionsumgebungen ist die beste betriebliche Methode. Es ist auch eine bewährte Methode, dass auf Ihren Clustern und Knoten in allen Umgebungen die neuesten Softwarepatches installiert werden, wobei wohlverstandene und dokumentierte Prozesse verwendet werden. Durch die Nutzung systemeigener ElastiCache Funktionen kann sich Ihr Entwicklungsteam auf die Erreichung der Geschäftsziele konzentrieren und nicht auf die ElastiCache Wartung.
+ **[Am besten]** Verwenden Sie die neueste verfügbare Engine-Version und installieren Sie die Self-Service-Updates, sobald sie verfügbar sind. ElastiCache aktualisiert die zugrunde liegende Infrastruktur automatisch während des angegebenen Wartungsfensters des Clusters. Die in Ihren Clustern laufenden Knoten werden jedoch über Self-Service-Updates aktualisiert. Es gibt zwei Arten von Updates: Sicherheitspatches oder kleinere Software-Updates. Stellen Sie sicher, dass Sie den Unterschied zwischen den Patch-Typen verstehen und wissen, wann diese angewendet werden.
**[Ressourcen]:**
+ [Self-Service-Updates bei Amazon ElastiCache](Self-Service-Updates.md)
+ [Hilfeseite für Amazon ElastiCache Managed Maintenance and Service Updates](https://aws.amazon.com/elasticache/elasticache-maintenance/)
+ **[Am besten]** Organisieren Sie Ihre ElastiCache Ressourcen mithilfe von Tags. Verwenden Sie Tags für Replikationsgruppen und nicht für einzelne Knoten. Sie können Tags so konfigurieren, dass sie angezeigt werden, wenn Sie Ressourcen abfragen, und Sie können Tags verwenden, um Suchen durchzuführen und Filter anzuwenden. Sie sollten Ressourcengruppen verwenden, um auf einfache Weise Sammlungen von Ressourcen zu erstellen und zu verwalten, die gemeinsame Tag-Sätze verwenden.
**[Ressourcen]:**
+ [Bewährte Methoden zum Taggen](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf)
+ [ElastiCache Referenz zum Ressourcentyp für CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [Parametergruppen](ParameterGroups.Engine.md#ParameterGroups.Redis)
## OE 4: Wie verwalten Sie die Verbindungen der Kunden zu Ihren ElastiCache Clustern?
**Einführung auf Fragenebene:** Wenn Sie in großem Maßstab arbeiten, müssen Sie verstehen, wie Ihre Kunden mit dem ElastiCache Cluster kommunizieren, um die betrieblichen Aspekte Ihrer Anwendung (z. B. Reaktionszeiten) verwalten zu können.
**Vorteil auf Fragenebene: **Durch die Auswahl des am besten geeigneten Verbindungsmechanismus wird sichergestellt, dass Ihre Anwendung nicht aufgrund von Verbindungsfehlern, wie Timeouts, unterbrochen wird.
+ **[Erforderlich]** Trennen Sie Lese- und Schreibvorgänge und stellen Sie eine Verbindung mit dem Replikatknoten her, um Lesevorgänge auszuführen. Beachten Sie jedoch, dass Sie, wenn Sie die Schreibvorgänge von den Lesevorgängen trennen, aufgrund der asynchronen Natur der Valkey- und Redis-OSS-Replikation die Fähigkeit verlieren, einen Schlüssel unmittelbar nach dem Schreiben zu lesen. Der WAIT-Befehl kann genutzt werden, um die Datensicherheit in der Praxis zu verbessern und Replikate dazu zu zwingen, Schreibvorgänge zu bestätigen, bevor sie auf Clients antworten, was die Gesamtleistung beeinträchtigt. Die Verwendung von Replikatknoten für Lesevorgänge kann in Ihrer ElastiCache Client-Bibliothek konfiguriert werden, indem der ElastiCache Reader-Endpunkt für den Clustermodus deaktiviert ist. Wenn der Clustermodus aktiviert ist, verwenden Sie den Befehl READONLY. Für viele der ElastiCache Clientbibliotheken ist READONLY standardmäßig oder über eine Konfigurationseinstellung implementiert.
**[Ressourcen]:**
+ [Verbindungsendpunkte finden in ElastiCache](Endpoints.md)
+ [READONLY](https://valkey.io/commands/readonly)
+ **[Erforderlich] **Verwenden Sie Verbindungspooling. Der Aufbau einer TCP-Verbindung kostet sowohl auf Client- als auch auf Serverseite CPU-Zeit. Durch Pooling können Sie die TCP-Verbindung wiederverwenden.
Um den Verbindungsaufwand zu reduzieren, sollten Sie Verbindungspooling verwenden. Mit einem Pool von Verbindungen kann Ihre Anwendung Verbindungen „nach Belieben“ wiederverwenden und freigeben, ohne dass Kosten für den Verbindungsaufbau anfallen. Sie können das Verbindungspooling über Ihre ElastiCache Clientbibliothek (sofern unterstützt) implementieren, wobei ein Framework für Ihre Anwendungsumgebung verfügbar ist, oder es von Grund auf neu erstellen.
+ **[Am besten]** Stellen Sie sicher, dass das Socket-Timeout des Clients auf mindestens eine Sekunde eingestellt ist (im Vergleich zur typischen Standardeinstellung „Keine“ bei verschiedenen Clients).
+ Wenn Sie den Timeout-Wert zu niedrig einstellen, kann dies zu möglichen Timeouts führen, wenn die Serverlast hoch ist. Eine zu hohe Einstellung kann dazu führen, dass Ihre Anwendung lange braucht, um Verbindungsprobleme zu erkennen.
+ Kontrollieren Sie das Volumen neuer Verbindungen, indem Sie Verbindungspooling in Ihrer Client-Anwendung implementieren. Dadurch werden Latenz und CPU-Auslastung reduziert, die erforderlich sind, um Verbindungen zu öffnen und zu schließen, und es wird ein TLS-Handshake durchgeführt, wenn TLS im Cluster aktiviert ist.
**[Ressourcen]: ElastiCache ** [Für höhere Verfügbarkeit konfigurieren](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ **[Gut]** Der Einsatz von Pipelining (sofern Ihre Anwendungsfälle dies zulassen) kann die Leistung erheblich steigern.
+ Mit Pipelining reduzieren Sie die Round-Trip Time (RTT, Roundtrip-Zeit) zwischen Ihren Anwendungsclients und dem Cluster und neue Anfragen können verarbeitet werden, auch wenn der Client die vorherigen Antworten noch nicht gelesen hat.
+ Mit Pipelining können Sie mehrere Befehle an den Server senden, ohne auf Antworten/Bestätigungen warten zu müssen. Der Nachteil von Pipelining ist, dass, wenn Sie irgendwann alle Antworten in Massen abrufen, möglicherweise ein Fehler aufgetreten ist, den Sie erst am Ende erkennen können.
+ Implementieren Sie Methoden, um Anfragen erneut zu versuchen, wenn ein Fehler zurückgegeben wird, der die fehlerhafte Anfrage auslässt.
**[Ressourcen]:** [Pipelining](https://valkey.io/topics/pipelining/)
## OE 5: Wie werden ElastiCache Komponenten für einen Workload bereitgestellt?
**Einführung auf Fragenebene:** ElastiCache Umgebungen können manuell über die AWS Konsole oder programmgesteuert über CLIAPIs, Toolkits usw. bereitgestellt werden. Bewährte Methoden für Operational Excellence sehen vor, Bereitstellungen möglichst mithilfe von Code zu automatisieren. Darüber hinaus können ElastiCache Cluster entweder nach Arbeitslast isoliert oder zur Kostenoptimierung kombiniert werden.
**Vorteil auf Frageebene: Durch** die Auswahl des für Ihre ElastiCache Umgebungen am besten geeigneten Bereitstellungsmechanismus kann Operation Excellence im Laufe der Zeit verbessert werden. Es wird empfohlen, Operationen möglichst als Code auszuführen, um menschliche Fehler zu minimieren und die Wiederholbarkeit, Flexibilität und Reaktionszeit auf Ereignisse zu erhöhen.
Wenn Sie die Anforderungen an die Workload-Isolierung verstehen, können Sie entscheiden, ob Sie pro Workload dedizierte ElastiCache Umgebungen einrichten oder mehrere Workloads zu einzelnen Clustern oder Kombinationen daraus zusammenfassen möchten. Die Nachteile zu verstehen, kann dazu beitragen, ein Gleichgewicht zwischen Operational Excellende und Kostenoptimierung zu finden
+ **[Erforderlich] Machen** Sie sich mit den verfügbaren Bereitstellungsoptionen vertraut und automatisieren Sie diese Verfahren ElastiCache, wann immer dies möglich ist. Zu den möglichen Automatisierungsmöglichkeiten gehören CloudFormation AWS CLI/SDK und. APIs
**[Ressourcen]:**
+ [Referenz zum ElastiCache Amazon-Ressourcentyp](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [elasticache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html)
+ [ ElastiCache Amazon-API-Referenz](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
+ **[Erforderlich]** Ermitteln Sie für alle Workloads den erforderlichen Grad der Clusterisolierung.
+ **[Am besten]:** Hohe Isolierung – eine 1:1-Zuordnung zwischen Workload und Cluster. Ermöglicht die feinste Kontrolle über den Zugriff, die Größe, Skalierung und Verwaltung von ElastiCache Ressourcen auf Workload-Basis.
+ **[Besser]:** Mittlere Isolierung – M:1 ist zweckmäßig isoliert, aber möglicherweise von mehreren Workloads gemeinsam genutzt (z. B. ein Cluster, der für das Zwischenspeichern von Workloads vorgesehen ist, und ein anderer, der für Messaging dediziert ist).
+ **[Gut]:** Niedrige Isolierung – M:1 für alle Zwecke, vollständig gemeinsam genutzt. Empfohlen für Workloads, bei denen gemeinsamer Zugriff akzeptabel ist.
## OE 6: Wie planen und minimieren Sie Ausfälle?
**Einführung auf Fragenebene:** Operational Excellence umfasst die Antizipation von Ausfällen durch regelmäßige „Pre-Mortem“ -Übungen zur Identifizierung potenzieller Fehlerquellen, sodass sie behoben oder gemildert werden können. ElastiCache bietet eine Failover-API, die zu Testzwecken simulierte Knotenausfälle ermöglicht.
**Vorteil auf Fragenebene: **Wenn Sie Ausfallszenarien vorab testen, können Sie herausfinden, wie sie sich auf Ihren Workload auswirken. Dies ermöglicht ein sicheres Testen der Reaktionsverfahren und ihrer Wirksamkeit und macht Ihr Team mit deren Ausführung vertraut.
**[Erforderlich]** Führen Sie regelmäßig Failover-Tests in Entwickler-/Testkonten durch. [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)
## OE 7: Wie behebt man Valkey- oder Redis OSS-Engine-Ereignisse?
**Einführung auf Fragenebene:** Operational Excellence erfordert die Fähigkeit, sowohl Informationen auf Service- als auch auf Engine-Ebene zu untersuchen, um den Zustand und den Status Ihrer Cluster zu analysieren. ElastiCache kann Valkey- oder Redis-OSS-Engine-Protokolle sowohl an Amazon als auch an Amazon Kinesis CloudWatch Data Firehose senden.
**Vorteil auf Fragenebene:** Durch die Aktivierung von Valkey- oder Redis-OSS-Engine-Protokollen auf ElastiCache Clustern erhalten Sie Einblicke in Ereignisse, die sich auf den Zustand und die Leistung von Clustern auswirken. Die Logs der Valkey- oder Redis OSS-Engine liefern Daten direkt von der Engine, die über den Ereignismechanismus nicht verfügbar sind. ElastiCache Durch sorgfältige Beobachtung sowohl der ElastiCache Ereignisse (siehe oben in OE-1) als auch der Engine-Logs ist es möglich, bei der Fehlerbehebung eine Reihenfolge der Ereignisse sowohl aus ElastiCache Service- als auch aus Engine-Perspektive zu bestimmen.
+ **[Erforderlich]** Stellen Sie sicher, dass die Protokollierungsfunktion der Redis OSS-Engine aktiviert ist. Diese Funktion ist ab ElastiCache Version 6.2 für Redis OSS und neuer verfügbar. Dieser Vorgang kann während der Clustererstellung oder durch Änderung des Clusters nach der Erstellung erfolgen.
+ Stellen Sie fest, ob Amazon CloudWatch Logs oder Amazon Kinesis Data Firehose das geeignete Ziel für Redis OSS-Engine-Protokolle ist.
+ Wählen Sie ein geeignetes Zielprotokoll in CloudWatch oder Kinesis Data Firehose aus, um die Protokolle beizubehalten. Wenn Sie mehrere Cluster haben, sollten Sie für jeden Cluster ein anderes Zielprotokoll verwenden, da Daten bei der Fehlerbehebung so besser isoliert werden können.
**[Ressourcen]:**
+ Protokollzustellung: [Protokollzustellung](Log_Delivery.md)
+ Ziele für die Protokollierung: [Amazon CloudWatch Logs](Logging-destinations.md#Destination_Specs_CloudWatch_Logs)
+ Einführung in Amazon CloudWatch Logs: [Was ist Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ Einführung in Amazon Kinesis Data Firehose: [Was ist Amazon Kinesis Data Firehose?](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
+ **[Am besten]** Wenn Sie Amazon CloudWatch Logs verwenden, sollten Sie Amazon CloudWatch Logs Insights nutzen, um das Valkey- oder Redis OSS-Engine-Protokoll nach wichtigen Informationen abzufragen.
Erstellen Sie als Beispiel eine Abfrage für die CloudWatch Log-Gruppe, die die Logs der Valkey- oder Redis-OSS-Engine enthält, die Ereignisse mit dem Zusatz „WARNING“ zurückgeben, wie zum Beispiel: LogLevel
```
fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"
```
**[Ressourcen]:** [Analysieren von Protokolldaten mit CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) Logs Insights
# Sicherheitssäule von Amazon ElastiCache Well-Architected Lens
Die Säule der Sicherheit konzentriert sich auf den Schutz von Informationen und Systemen. Zu den wichtigsten Themen gehören die Vertraulichkeit und Integrität von Daten, die Ermittlung und Verwaltung von Berechtigungen mithilfe der Berechtigungsverwaltung, der Schutz von Systemen und die Einrichtung von Kontrollen zur Erkennung von Sicherheitsereignissen.
**Topics**
+ [SEC 1: Welche Schritte ergreifen Sie, um den autorisierten Zugriff auf Daten zu ElastiCache kontrollieren?](#SecurityPillarSEC1)
+ [SEC 2: Benötigen Ihre Anwendungen zusätzliche Autorisierungen, die ElastiCache über netzwerkbasierte Kontrollen hinausgehen?](#SecurityPillarSEC2)
+ [SEC 3: Besteht das Risiko, dass Befehle versehentlich ausgeführt werden können und Datenverlust oder -ausfall verursachen?](#SecurityPillarSEC3)
+ [SEC 4: Wie stellen Sie die Datenverschlüsselung im Ruhezustand sicher ElastiCache](#SecurityPillarSEC4)
+ [SEC 5: Wie verschlüsselt man Daten bei der Übertragung mit? ElastiCache](#SecurityPillarSEC5)
+ [SEC 6: Wie schränken Sie den Zugriff auf Ressourcen der Steuerebene ein?](#SecurityPillarSEC6)
+ [SEC 7: Wie erkennen Sie Sicherheitsereignisse und wie reagieren Sie darauf?](#SecurityPillarSEC7)
## SEC 1: Welche Schritte ergreifen Sie, um den autorisierten Zugriff auf Daten zu ElastiCache kontrollieren?
**Einführung auf Fragenebene:** Alle ElastiCache Cluster sind so konzipiert, dass sie von Amazon Elastic Compute Cloud-Instances in einer VPC, serverlosen Funktionen (AWS Lambda) oder Containern (Amazon Elastic Container Service) aus aufgerufen werden können. Das am häufigsten anzutreffende Szenario ist der Zugriff auf einen ElastiCache Cluster von einer Amazon Elastic Compute Cloud-Instanz innerhalb derselben Amazon Virtual Private Cloud (Amazon Virtual Private Cloud). Bevor Sie von einer EC2 Amazon-Instance aus eine Verbindung zu einem Cluster herstellen können, müssen Sie die EC2 Amazon-Instance autorisieren, auf den Cluster zuzugreifen. Um auf einen ElastiCache Cluster zuzugreifen, der in einer VPC ausgeführt wird, muss dem Cluster Netzwerkzugang gewährt werden.
**Vorteil auf Fragenebene: **Der Netzwerkeingang für den Cluster wird über VPC-Sicherheitsgruppen gesteuert. Eine Sicherheitsgruppe fungiert als virtuelle Firewall für Ihre EC2 Amazon-Instances, um den eingehenden und ausgehenden Datenverkehr zu kontrollieren. Eingehende Regeln steuern den eingehenden Datenverkehr zu Ihrer Instance und ausgehende Regeln steuern den ausgehenden Datenverkehr von Ihrer Instance. Im Fall von ElastiCache, wenn ein Cluster gestartet wird, muss eine Sicherheitsgruppe zugeordnet werden. Dadurch wird sichergestellt, dass Regeln für ein- und ausgehenden Datenverkehr für alle Knoten gelten, aus denen der Cluster besteht. Darüber hinaus ElastiCache ist es so konfiguriert, dass es ausschließlich in privaten Subnetzen bereitgestellt wird, sodass auf sie nur über das private Netzwerk der VPC zugegriffen werden kann.
+ **[Erforderlich] **Die Ihrem Cluster zugeordnete Sicherheitsgruppe steuert den Netzwerkeingang und den Zugriff auf den Cluster. Standardmäßig sind für eine Sicherheitsgruppe keine Regeln für eingehenden Datenverkehr definiert und daher auch kein Eingangspfad zu. ElastiCache Um dies zu aktivieren, konfigurieren Sie eine eingehende Regel für die Sicherheitsgruppe, die die Quell-IP-Adresse/den Bereich, den TCP-Verkehr und den Port für Ihren ElastiCache Cluster angibt (Standardport 6379 ElastiCache für beispielsweise Valkey und Redis OSS). Es ist zwar möglich, eine sehr breite Palette von Eingangsquellen zuzulassen, z. B. alle Ressourcen innerhalb einer VPC (0.0.0.0/0), es wird jedoch empfohlen, die Regeln für eingehenden Datenverkehr so detailliert wie möglich zu definieren, z. B. nur den eingehenden Zugriff auf Valkey- oder Redis OSS-Clients zu autorisieren, die auf Amazon Amazon-Instances ausgeführt werden, die einer bestimmten Sicherheitsgruppe zugeordnet sind. EC2
**[Ressourcen]:**
+ [Subnetze und Subnetzgruppen](SubnetGroups.md)
+ [Zugriff auf Ihren Cluster oder die Replikationsgruppe](accessing-elasticache.md)
+ [Steuern des Datenverkehrs zu Ressourcen mithilfe von Sicherheitsgruppen](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#DefaultSecurityGroupdefault%20security%20group)
+ [Sicherheitsgruppen von Amazon Elastic Compute Cloud für Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#creating-your-own-security-groups)
+ **[Erforderlich]**AWS Identity and Access Management Richtlinien können Funktionen zugewiesen werden, die ihnen den Zugriff auf Daten ermöglichen. AWS Lambda ElastiCache Um diese Funktion zu aktivieren, erstellen Sie eine IAM-Ausführungsrolle mit der entsprechenden `AWSLambdaVPCAccessExecutionRole` Berechtigung und weisen Sie die Rolle dann der AWS Lambda Funktion zu.
**[Ressourcen]:** Konfiguration einer Lambda-Funktion für den Zugriff auf Amazon ElastiCache in einer Amazon VPC: [Tutorial: Konfiguration einer Lambda-Funktion für den Zugriff auf Amazon ElastiCache in einer Amazon](https://docs.aws.amazon.com/lambda/latest/dg/services-elasticache-tutorial.html) VPC
## SEC 2: Benötigen Ihre Anwendungen zusätzliche Autorisierungen, die ElastiCache über netzwerkbasierte Kontrollen hinausgehen?
**Einführung auf Fragenebene:** In Szenarien, in denen es notwendig ist, den Zugriff auf Cluster auf individueller Client-Ebene einzuschränken oder zu kontrollieren, wird empfohlen, sich über den AUTH-Befehl zu authentifizieren. ElastiCache Authentifizierungstoken mit optionaler Benutzer- und Benutzergruppenverwaltung ermöglichen ElastiCache die Eingabe eines Kennworts, bevor Clients Befehle ausführen und auf Schlüssel zugreifen können, wodurch die Sicherheit der Datenebene verbessert wird.
**Vorteil auf Fragenebene:** Damit Ihre Daten sicher bleiben, ElastiCache bietet es Mechanismen zum Schutz vor unbefugtem Zugriff auf Ihre Daten. Dazu gehört auch, dass Clients, bevor sie autorisierte Befehle ausführen, mithilfe von RBAC (Role-Based Access Control) AUTH oder AUTH-Token (Passwort) eine Verbindung herstellen. ElastiCache
+ **[Am besten]** Definieren Sie für ElastiCache Version 6.x und höher für Redis OSS und ElastiCache Version 7.2 und höher für Valkey Authentifizierungs- und Autorisierungskontrollen, indem Sie Benutzergruppen, Benutzer und Zugriffszeichenfolgen definieren. Weisen Sie Benutzer Benutzergruppen zu und weisen Sie Benutzergruppen dann Clustern zu. Damit RBAC verwendet wird, muss es bei der Clustererstellung ausgewählt und die Verschlüsselung während der Übertragung aktiviert sein. Stellen Sie sicher, dass Sie einen Valkey- oder Redis OSS-Client verwenden, der TLS unterstützt, um RBAC nutzen zu können.
**[Ressourcen]:**
+ [Anwenden von RBAC auf eine Replikationsgruppe für ElastiCache](Clusters.RBAC.md#rbac-using)
+ [Spezifizieren von Berechtigungen mithilfe einer Zugriffszeichenfolge](Clusters.RBAC.md#Access-string)
+ [ACL](https://valkey.io/topics/acl/)
+ [Unterstützte Versionen ElastiCache ](VersionManagement.md#supported-engine-versions)
+ **[Optimal]** Für ElastiCache Versionen vor 6.x für Redis OSS empfiehlt es sich, neben der Festlegung starker token/password und strikter Kennwortrichtlinien für AUTH auch die Rotation des Passworts/Tokens zu verwenden. ElastiCache kann bis zu zwei (2) Authentifizierungstoken gleichzeitig verwalten. Sie können den Cluster auch so ändern, dass explizit die Verwendung von Authentifizierungstoken erforderlich ist.
**[Ressourcen]:** [Ändern des AUTH-Tokens auf einem vorhandenen Cluster ElastiCache](auth.md#auth-modifyng-token)
## SEC 3: Besteht das Risiko, dass Befehle versehentlich ausgeführt werden können und Datenverlust oder -ausfall verursachen?
**Einführung auf Fragenebene:** Es gibt eine Reihe von Valkey- oder Redis OSS-Befehlen, die sich nachteilig auf den Betrieb auswirken können, wenn sie versehentlich oder von böswilligen Akteuren ausgeführt werden. Diese Befehle können im Hinblick auf die Leistung und Datensicherheit unbeabsichtigte Folgen haben. Beispielsweise kann ein Entwickler in einer Entwicklungsumgebung routinemäßig den Befehl FLUSHALL aufrufen und aufgrund eines Fehlers versehentlich versuchen, diesen Befehl in einem Produktionssystem aufzurufen, was zu unbeabsichtigtem Datenverlust führt.
**Vorteil auf Fragenebene:** Ab ElastiCache Version 5.0.3 für Redis OSS haben Sie die Möglichkeit, bestimmte Befehle umzubenennen, die Ihre Arbeitslast stören könnten. Durch das Umbenennen der Befehle kann verhindert werden, dass diese versehentlich auf dem Cluster ausgeführt werden.
+ **[Erforderlich] **
**[Ressourcen]:**
+ [ElastiCache Version 5.0.3 für Redis OSS (veraltet, verwenden Sie Version 5.0.6)](engine-versions.md#redis-version-5-0.3)
+ [ElastiCache Version 5.0.3 für Redis OSS-Parameteränderungen](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3)
+ [Redis OSS-Sicherheit](https://redis.io/docs/management/security/)
## SEC 4: Wie stellen Sie die Datenverschlüsselung im Ruhezustand sicher ElastiCache
**Einführung auf Fragenebene:** Es ElastiCache handelt sich zwar um einen In-Memory-Datenspeicher, aber es ist möglich, alle Daten zu verschlüsseln, die im Rahmen der Standardoperationen des Clusters dauerhaft (im Speicher) gespeichert werden. Dazu gehören sowohl geplante als auch manuelle Backups, die in Amazon S3 geschrieben wurden, sowie Daten, die aufgrund von Synchronisierungs- und Swap-Vorgängen auf dem Festplattenspeicher gespeichert wurden. Instance-Typen der M6g- und R6g-Familien verfügen außerdem über eine ständig aktive In-Memory-Verschlüsselung.
**Vorteil auf Fragenebene:** ElastiCache Bietet optionale Verschlüsselung im Ruhezustand, um die Datensicherheit zu erhöhen.
+ **[Erforderlich]** Die Verschlüsselung im Ruhezustand kann auf einem ElastiCache Cluster (Replikationsgruppe) nur aktiviert werden, wenn dieser erstellt wurde. Ein vorhandener Cluster kann nicht geändert werden, um mit der Verschlüsselung von Daten im Ruhezustand zu beginnen. Stellt standardmäßig die Schlüssel bereit und verwaltet ElastiCache sie, die bei der Verschlüsselung im Ruhezustand verwendet werden.
**[Ressourcen]:**
+ [Einschränkungen bei der Verschlüsselung im Ruhezustand](at-rest-encryption.md#at-rest-encryption-constraints)
+ [Aktivieren der Verschlüsselung im Ruhezustand](at-rest-encryption.md#at-rest-encryption-enable)
+ **[Am besten]** Nutzen Sie EC2 Amazon-Instance-Typen, die Daten verschlüsseln, während sie sich im Arbeitsspeicher befinden (z. B. M6g oder R6g). Wenn möglich, sollten Sie erwägen, eigene Schlüssel für die Verschlüsselung im Ruhezustand zu verwalten. In Umgebungen mit strengeren Datensicherheitsumgebungen kann AWS Key Management Service (KMS) zur Selbstverwaltung der Customer Master Keys (CMK) verwendet werden. Durch die ElastiCache Integration mit sind Sie in der Lage AWS Key Management Service, die Schlüssel zu erstellen, zu besitzen und zu verwalten, die für die Verschlüsselung ruhender Daten in Ihrem ElastiCache Cluster verwendet werden.
**[Ressourcen]:**
+ [Verwenden Sie vom Kunden verwaltete Schlüssel von AWS Key Management Service](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security)
+ [AWS Schlüsselverwaltungsdienst](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
+ [AWS -KMS-Konzepte](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys)
## SEC 5: Wie verschlüsselt man Daten bei der Übertragung mit? ElastiCache
**Einführung auf Fragenebene: **Es ist eine gängige Anforderung, zu verhindern, dass Daten während der Übertragung beschädigt werden. Dabei handelt es sich um Daten innerhalb von Komponenten eines verteilten Systems sowie zwischen Anwendungsclients und Clusterknoten. ElastiCache unterstützt diese Anforderung, indem es die Verschlüsselung von Daten ermöglicht, die zwischen Clients und Clustern sowie zwischen den Clusterknoten selbst übertragen werden. Instance-Typen der M6g- und R6g-Familien verfügen außerdem über eine ständig aktive In-Memory-Verschlüsselung.
**Vorteil auf Frageebene:** Die Verschlüsselung ElastiCache während der Übertragung durch Amazon ist eine optionale Funktion, mit der Sie die Sicherheit Ihrer Daten an den anfälligsten Stellen erhöhen können, wenn sie von einem Ort zum anderen übertragen werden.
+ **[Erforderlich]** Die Verschlüsselung bei der Übertragung kann bei der Erstellung nur auf einem Cluster (Replikationsgruppe) aktiviert werden. Bitte beachten Sie, dass die Implementierung der Verschlüsselung bei der Übertragung aufgrund der zusätzlichen Verarbeitung, die für die Ver-/Entschlüsselung von Daten erforderlich ist, Auswirkungen auf die Leistung hat. Um die Auswirkungen zu verstehen, wird empfohlen, Ihren Workload vor und nach der Aktivierung encryption-in-transit zu vergleichen.
**[Ressourcen]:**
+ [Übersicht über die Verschlüsselung bei der Übertragung](in-transit-encryption.md#in-transit-encryption-overview)
## SEC 6: Wie schränken Sie den Zugriff auf Ressourcen der Steuerebene ein?
**Einführung auf Fragenebene:** IAM-Richtlinien und ARN ermöglichen detaillierte Zugriffskontrollen ElastiCache für Valkey und Redis OSS und ermöglichen so eine strengere Kontrolle bei der Verwaltung der Erstellung, Änderung und Löschung von Clustern.
**Vorteil auf Frageebene:** Die Verwaltung von ElastiCache Amazon-Ressourcen wie Replikationsgruppen, Knoten usw. kann auf AWS Konten beschränkt werden, die über spezifische Berechtigungen auf der Grundlage von IAM-Richtlinien verfügen, wodurch die Sicherheit und Zuverlässigkeit der Ressourcen verbessert wird.
+ **[Erforderlich]** Verwalten Sie den Zugriff auf ElastiCache Amazon-Ressourcen, indem Sie AWS Benutzern bestimmte AWS Identity and Access Management Richtlinien zuweisen, sodass Sie genauer kontrollieren können, welche Konten welche Aktionen auf Clustern ausführen können.
**[Ressourcen]:**
+ [Überblick über die Verwaltung der Zugriffsberechtigungen für Ihre Ressourcen ElastiCache](IAM.Overview.md)
+ [Verwendung identitätsbasierter Richtlinien (IAM-Richtlinien) für Amazon ElastiCache](IAM.IdentityBasedPolicies.md)
## SEC 7: Wie erkennen Sie Sicherheitsereignisse und wie reagieren Sie darauf?
**Einführung auf Fragenebene:** ElastiCache Exportiert bei der Implementierung mit aktiviertem RBAC CloudWatch Metriken, um Benutzer über Sicherheitsereignisse zu informieren. Diese Metriken helfen bei der Identifizierung von fehlgeschlagenen Authentifizierungsversuchen, Zugriffsschlüsseln oder der Ausführung von Befehlen, für die RBAC-Benutzer, die eine Verbindung herstellen, nicht autorisiert sind.
Darüber hinaus tragen AWS Produkte und Serviceressourcen dazu bei, Ihre gesamte Arbeitslast zu sichern, indem sie Bereitstellungen automatisieren und alle Aktionen und Änderungen für eine spätere Überprüfung/Prüfung protokollieren.
**Vorteil auf Fragenebene: **Durch die Überwachung von Ereignissen ermöglichen Sie Ihrem Unternehmen, gemäß Ihren Anforderungen, Richtlinien und Verfahren zu reagieren. Durch die Automatisierung der Überwachung und Reaktion auf diese Sicherheitsereignisse wird Ihre allgemeine Sicherheitslage gestärkt.
+ **[Erforderlich]** Machen Sie sich mit den veröffentlichten CloudWatch Kennzahlen vertraut, die sich auf RBAC-Authentifizierungs- und Autorisierungsfehler beziehen.
+ AuthenticationFailures = Fehlgeschlagene Versuche, sich bei Valkey oder Redis OSS zu authentifizieren
+ KeyAuthorizationFailures = Fehlgeschlagene Versuche von Benutzern, ohne Erlaubnis auf Schlüssel zuzugreifen
+ CommandAuthorizationFailures = Fehlgeschlagene Versuche von Benutzern, Befehle ohne Erlaubnis auszuführen
**[Ressourcen]:**
+ [Metriken für Valkey oder Redis OSS](CacheMetrics.Redis.md)
+ **[Am besten] **Es wird empfohlen, Warnmeldungen und Benachrichtigungen für diese Metriken einzurichten und je nach Bedarf zu reagieren.
**[Ressourcen]:**
+ [ CloudWatch Amazon-Alarme verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ **[Am besten]** Verwenden Sie den Befehl Valkey oder Redis OSS ACL LOG, um weitere Informationen zu sammeln
**[Ressourcen]:**
+ [ACL LOG](https://valkey.io/commands/acl-log/)
+ **[Am besten]** Machen Sie sich mit den Funktionen der AWS Produkte und Services im Zusammenhang mit der Überwachung, Protokollierung und Analyse von ElastiCache Bereitstellungen und Ereignissen vertraut
**[Ressourcen]:**
+ [Protokollierung Amazon ElastiCache Amazon-API-Aufrufen mit AWS CloudTrail](logging-using-cloudtrail.md)
+ [elasticache-redis-cluster-automatic-Backup-Check](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html)
+ [Überwachung der Nutzung mit Metrics CloudWatch ](CacheMetrics.md)
# Säule der Zuverlässigkeit von Amazon ElastiCache Well-Architected Lens
Der Schwerpunkt der Zuverlässigkeit liegt auf Workloads, die ihre vorgesehenen Funktionen erfüllen, und darauf, wie sie bei einem Ausfall schnell wiederhergestellt werden können, um die Anforderungen zu erfüllen. Zu den wichtigsten Themen gehören der Entwurf verteilter Systeme, die Wiederherstellungsplanung und die Anpassung an sich ändernde Anforderungen.
**Topics**
+ [REL 1: Wie unterstützen Sie Bereitstellungen von Hochverfügbarkeitsarchitekturen (HA)?](#ReliabilityPillarREL1)
+ [REL 2: Wie erreichen Sie Ihre Recovery Point Objectives (RPOs) mit? ElastiCache](#ReliabilityPillarREL2)
+ [REL 3: Wie unterstützen Sie die Anforderungen an Disaster Recovery (DR, Notfallwiederherstellung)?](#ReliabilityPillarREL3)
+ [REL 4: Wie planen Sie Failovers effektiv?](#ReliabilityPillarREL4)
+ [REL 5: Sind Ihre ElastiCache Komponenten so konzipiert, dass sie skalierbar sind?](#ReliabilityPillarREL5)
## REL 1: Wie unterstützen Sie Bereitstellungen von Hochverfügbarkeitsarchitekturen (HA)?
**Einführung auf Fragenebene:** Wenn Sie die Hochverfügbarkeitsarchitektur von Amazon verstehen, können ElastiCache Sie bei Verfügbarkeitsereignissen in einem stabilen Zustand arbeiten.
**Vorteil auf Fragenebene: Wenn Sie** Ihre ElastiCache Cluster so gestalten, dass sie ausfallsicher sind, wird eine höhere Verfügbarkeit Ihrer Bereitstellungen gewährleistet. ElastiCache
+ **[Erforderlich]** Ermitteln Sie das Maß an Zuverlässigkeit, das Sie für Ihren Cluster benötigen. ElastiCache Verschiedene Workloads haben unterschiedliche Resilienzstandards, von rein kurzlebigen bis hin zu geschäftskritischen Workloads. Definieren Sie die Anforderungen für jede Art von Umgebung, die Sie betreiben, z. B. Entwicklung, Test und Produktion.
Caching-Engine: ElastiCache für Memcached im Vergleich zu Valkey und ElastiCache Redis OSS
1. ElastiCache für Memcached bietet keinen Replikationsmechanismus und wird hauptsächlich für kurzlebige Workloads verwendet.
1. ElastiCache für Valkey und Redis bietet OSS HA-Funktionen, die im Folgenden beschrieben werden
+ **[Am besten]** Verwenden Sie ElastiCache für Workloads, die HA erfordern, den Clustermodus mit mindestens zwei Replikaten pro Shard, auch für Workloads mit geringem Durchsatz, die nur einen Shard benötigen.
1. Wenn der Clustermodus aktiviert ist, wird Multi-AZ automatisch aktiviert.
Multi-AZ minimiert Ausfallzeiten, indem automatische Failovers vom Primärknoten bis zu den Replikaten im Falle einer geplanten oder ungeplanten Wartung durchgeführt und AZ-Ausfälle minimiert werden.
1. Bei Shard-Workloads sorgen mindestens drei Shards für eine schnellere Wiederherstellung bei Failover-Ereignissen, da das Valkey- oder Redis OSS-Cluster-Protokoll erfordert, dass die Mehrheit der Primärknoten verfügbar ist, um ein Quorum zu erreichen.
1. Richten Sie zwei oder mehr Replikate für die Verfügbarkeit ein.
Zwei Replikate bieten eine verbesserte Leseskalierbarkeit sowie Leseverfügbarkeit in Szenarien, in denen ein Replikat gewartet wird.
1. Verwenden Sie Graviton2-basierte Knotentypen (Standardknoten in den meisten Regionen).
ElastiCache hat die Leistung auf diesen Knoten optimiert. Dadurch erhalten Sie eine bessere Replikations- und Synchronisierungsleistung, was zu einer insgesamt verbesserten Verfügbarkeit führt.
1. Überwachen Sie und passen Sie die Größe an, um zu erwartende Verkehrsspitzen zu bewältigen: Bei hoher Auslastung reagiert die Engine möglicherweise nicht mehr, was sich auf die Verfügbarkeit auswirkt. `BytesUsedForCache`und `DatabaseMemoryUsagePercentage` sind gute Indikatoren für Ihre Speicherauslastung, wohingegen `ReplicationLag` sie anhand Ihrer Schreibrate ein Indikator für den Zustand Ihrer Replikation sind. Sie können diese Metriken verwenden, um die Clusterskalierung auszulösen.
1. Stellen Sie die clientseitige Resilienz sicher, indem Sie [vor einem Produktions-Failover-Ereignis Tests mit der Failover-API](https://docs.amazonaws.cn/en_us/AmazonElastiCache/latest/APIReference/API_TestFailover.html) durchführen.
**[Ressourcen]:**
+ [Konfigurieren Sie ElastiCache für Redis OSS für eine höhere Verfügbarkeit](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [Hohe Verfügbarkeit mit Replikationsgruppen](Replication.md)
## REL 2: Wie erreichen Sie Ihre Recovery Point Objectives (RPOs) mit? ElastiCache
**Einführung auf Fragenebene:** Machen Sie sich mit Workload-RPO vertraut, um fundierte Entscheidungen über ElastiCache Sicherungs- und Wiederherstellungsstrategien treffen zu können.
**Vorteil auf Fragenebene: **Eine integrierte RPO-Strategie kann die Geschäftskontinuität im Falle eines Notfallwiederherstellungs-Szenarios verbessern. Die Gestaltung Ihrer Sicherungs- und Wiederherstellungsrichtlinien kann Ihnen helfen, Ihre Recovery Point Objectives (RPO) für Ihre Daten zu erreichen. ElastiCache ElastiCache bietet Snapshot-Funktionen, die in Amazon S3 gespeichert werden, zusammen mit einer konfigurierbaren Aufbewahrungsrichtlinie. Diese Snapshots werden während eines definierten Backup-Fensters aufgenommen und vom Service automatisch verarbeitet. Wenn Ihr Workload zusätzliche Backup-Granularität erfordert, haben Sie die Möglichkeit, bis zu 20 manuelle Backups pro Tag zu erstellen. Manuell erstellte Backups unterliegen keiner Serviceaufbewahrungsrichtlinie und können auf unbestimmte Zeit aufbewahrt werden.
+ **[Erforderlich] Machen** Sie sich mit dem RPO Ihrer ElastiCache Bereitstellungen vertraut und dokumentieren Sie es.
+ Beachten Sie, dass Memcached keine Backup-Prozesse anbietet.
+ Informieren Sie sich über die Funktionen der ElastiCache Backup- und Wiederherstellungsfunktionen.
+ **[Am besten] **Etablieren Sie einen gut kommunizierten Prozess für die Sicherung Ihres Clusters.
+ Initiieren Sie bei Bedarf manuelle Backups.
+ Überprüfen Sie die Aufbewahrungsrichtlinien für automatische Backups.
+ Beachten Sie, dass manuelle Backups auf unbestimmte Zeit aufbewahrt werden.
+ Planen Sie Ihre automatischen Backups in Zeiten geringer Auslastung.
+ Führen Sie Backup-Operationen anhand von Lesereplikaten durch, um sicherzustellen, dass die Auswirkungen auf die Cluster-Leistung so gering wie möglich gehalten werden.
+ **[Gut]** Nutzen Sie die Funktion für geplante Backups von ElastiCache , um Ihre Daten regelmäßig innerhalb eines bestimmten Zeitfensters zu sichern.
+ Testen Sie regelmäßig Wiederherstellungen aus Ihren Backups.
+ **[Ressourcen]:**
+ [Redis OSS](https://aws.amazon.com/elasticache/faqs/#Redis)
+ [Backup und Wiederherstellung für ElastiCache](backups.md)
+ [Erstellen manueller Backups](backups-manual.md)
+ [Planen automatischer Backups](backups-automatic.md)
+ [ ElastiCache Cluster Backup und wiederherstellen](https://aws.amazon.com/blogs/aws/backup-and-restore-elasticache-redis-nodes/)
## REL 3: Wie unterstützen Sie die Anforderungen an Disaster Recovery (DR, Notfallwiederherstellung)?
**Einführung auf Fragenebene:** Disaster Recovery ist ein wichtiger Aspekt jeder Workload-Planung. ElastiCache bietet verschiedene Optionen für die Implementierung von Disaster Recovery auf der Grundlage der Anforderungen an die Belastbarkeit von Workloads. Mit Amazon ElastiCache Global Datastore können Sie in Ihren Cluster in einer Region schreiben und die Daten zum Lesen aus zwei anderen regionsübergreifenden Replikatclustern zur Verfügung stellen, wodurch Lesevorgänge mit niedriger Latenz und regionsübergreifende Notfallwiederherstellung ermöglicht werden.
**Vorteil auf Fragenebene: **Durch das Nachvollziehen und die Planung verschiedener Notfallszenarien kann die Geschäftskontinuität gewährleistet werden. DR-Strategien müssen gegenüber Kosten, Leistungseinbußen und Datenverlustpotenzial abgewogen werden.
+ **[Erforderlich]** Entwickeln und dokumentieren Sie DR-Strategien für all Ihre ElastiCache Komponenten auf der Grundlage der Workload-Anforderungen. ElastiCache ist insofern einzigartig, als einige Anwendungsfälle völlig kurzlebig sind und keine DR-Strategie erfordern, während andere am anderen Ende des Spektrums liegen und eine extrem robuste DR-Strategie erfordern. Alle Optionen müssen gegenüber Kostenoptimierung abgewogen werden – eine größere Resilienz erfordert eine umfassendere Infrastruktur.
Machen Sie sich mit den DR-Optionen vertraut, die auf regionaler und multiregionaler Ebene verfügbar sind.
+ Multi-AZ-Bereitstellungen werden empfohlen, um sich vor AZ-Ausfällen zu schützen. Stellen Sie sicher, dass bei der Bereitstellung der Cluster-Modus in Multi-AZ-Architekturen aktiviert ist und mindestens 3 verfügbar sind. AZs
+ Global Datastore wird als Schutz vor regionalen Ausfällen empfohlen.
+ **[Am besten] **Aktivieren Sie Global Datastore für Workloads, die Resilienz auf regionaler Ebene erfordern.
+ Planen Sie ein Failover auf die sekundäre Region für den Fall einer Verschlechterung der primären Region ein.
+ Testen Sie den Failover-Prozess für mehrere Regionen, bevor Sie ein Failover in der Produktion durchführen.
+ Überwachen Sie die `ReplicationLag`-Metrik, um die möglichen Auswirkungen von Datenverlusten bei Failover-Ereignissen zu verstehen.
+ **[Ressourcen]:**
+ [Minimieren von Ausfällen](disaster-recovery-resiliency.md#FaultTolerance)
+ [Regionsübergreifende Replikation mithilfe globaler Datenspeicher AWS](Redis-Global-Datastore.md)
+ [Wiederherstellen aus einem Backup mit optionaler Cluster-Größenanpassung](backups-restoring.md)
+ [Minimierung der Ausfallzeiten bei Valkey und ElastiCache Redis OSS mit Multi-AZ](AutoFailover.md)
## REL 4: Wie planen Sie Failovers effektiv?
**Einführung auf Fragenebene:** Die Aktivierung von Multi-AZ mit automatischen Failovers ist eine bewährte Methode. ElastiCache In bestimmten Fällen ersetzt OSS ElastiCache bei Valkey und Redis die Primärknoten im Rahmen des Servicebetriebs. Beispiele hierfür sind geplante Wartungsereignisse und der unwahrscheinliche Falle eines Ausfalls des Knotens oder eines Problems mit der Availability Zone. Erfolgreiche Failover hängen sowohl von Ihrer Konfiguration als auch von Ihrer ElastiCache Client-Bibliothekskonfiguration ab.
**Vorteil auf Fragenebene:** Wenn Sie sich an bewährte Methoden für ElastiCache Failover in Verbindung mit Ihrer spezifischen ElastiCache Client-Bibliothek halten, können Sie potenzielle Ausfallzeiten bei Failover-Ereignissen minimieren.
+ **[Erforderlich] **Verwenden Sie bei deaktiviertem Clustermodus Timeouts, damit Ihre Clients anhand der aktualisierten IP-Adresse des primären Endpunkts erkennen, ob die Verbindung zum alten Primärknoten getrennt und erneut eine Verbindung zum neuen Primärknoten hergestellt werden muss. Im aktivierten Clustermodus ist die Clientbibliothek dafür zuständig, Änderungen in der zugrundeliegenden Cluster-Topologie zu erkennen. Dies wird in den meisten Fällen durch Konfigurationseinstellungen in der ElastiCache Client-Bibliothek erreicht, mit denen Sie auch die Häufigkeit und die Methode der Aktualisierung konfigurieren können. Jede Clientbibliothek bietet eigene Einstellungen. Weitere Informationen finden Sie in der entsprechenden Dokumentation.
**[Ressourcen]:**
+ [Minimierung der Ausfallzeiten ElastiCache bei Valkey und Redis OSS mit Multi-AZ](AutoFailover.md)
+ Informieren Sie sich über die Best Practices Ihrer Kundenbibliothek. ElastiCache
+ **[Erforderlich] **Erfolgreiche Failover hängen von einer fehlerfreien Replikationsumgebung zwischen dem Primärknoten und den Replikatknoten ab. Informieren Sie sich über die asynchrone Natur der Valkey- und Redis-OSS-Replikation sowie über die verfügbaren CloudWatch Kennzahlen zur Berichterstattung über die Replikationsverzögerung zwischen Primär- und Replikatknoten. In Anwendungsfällen, die eine höhere Datensicherheit erfordern, können Sie den Befehl WAIT nutzen, um Replikate zu zwingen, Schreibvorgänge zu bestätigen, bevor sie auf verbundene Clients antworten.
**[Ressourcen]:**
+ [Metriken für Valkey oder Redis OSS](CacheMetrics.Redis.md)
+ [Überwachung von Best Practices ElastiCache mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Am besten]** Überprüfen Sie regelmäßig die Reaktionsfähigkeit Ihrer Anwendung während eines Failovers mithilfe der ElastiCache Test Failover API.
**[Ressourcen]:**
+ [Testen des automatischen Failovers auf eine Read Replica am ElastiCache](https://aws.amazon.com/blogs/database/testing-automatic-failover-to-a-read-replica-on-amazon-elasticache-for-redis/)
+ [Testen des automatischen Failovers](AutoFailover.md#auto-failover-test)
## REL 5: Sind Ihre ElastiCache Komponenten so konzipiert, dass sie skalierbar sind?
**Einführung auf Fragenebene:** Wenn Sie die Skalierungsmöglichkeiten und die verfügbaren Bereitstellungstopologien verstehen, können sich Ihre ElastiCache Komponenten im Laufe der Zeit an sich ändernde Workload-Anforderungen anpassen. ElastiCachebietet 4-Wege-Skalierung: in/out (horizontal) und (vertikal). up/down
**Vorteil auf Frageebene:** Die Einhaltung von Best Practices für ElastiCache Bereitstellungen bietet ein Höchstmaß an Flexibilität bei der Skalierung und erfüllt gleichzeitig das Well-Architected-Prinzip der horizontalen Skalierung, um die Auswirkungen von Ausfällen zu minimieren.
+ **[Erforderlich] **Machen Sie sich mit dem Unterschied zwischen Topologien im aktivierten und im deaktivierten Clustermodus vertraut. In fast allen Fällen wird empfohlen, die Bereitstellung mit aktiviertem Clustermodus vorzunehmen, da dies im Zeitverlauf eine größere Skalierbarkeit ermöglicht. Komponenten im deaktiviertem Clustermodus können nur begrenzt horizontal skaliert werden, indem Lesereplikate hinzugefügt werden.
+ **[Erforderlich] **Machen Sie sich damit vertraut, wann und wie Sie skalieren müssen.
+ Für mehr READIOPS: Replikate hinzufügen
+ Für mehr WRITEOPS: Shards hinzufügen (aufskalieren)
+ Für mehr Netzwerk-I/O – netzwerkoptimierte Instances verwenden, hochskalieren
+ **[Am besten]** Stellen Sie Ihre ElastiCache Komponenten mit aktiviertem Cluster-Modus bereit, wobei Sie sich eher auf mehr, kleinere Knoten als auf weniger, größere Knoten konzentrieren. Dadurch wird der Explosionsradius eines Knotenausfalls effektiv begrenzt.
+ **[Am besten] **Nehmen Sie Replikate in Ihre Cluster auf, um die Reaktionsfähigkeit bei Skalierungsereignissen zu verbessern
+ **[Gut] Verwenden** Sie bei deaktiviertem Cluster-Modus Read Replicas, um die gesamte Lesekapazität zu erhöhen. ElastiCache unterstützt bis zu 5 Read Replicas im deaktivierten Cluster-Modus sowie vertikale Skalierung.
+ **[Ressourcen]:**
+ [Skalierung von Clustern ElastiCache ](Scaling.md)
+ [Online-Hochskalieren](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
# Säule der Leistung und Effizienz von Amazon ElastiCache Well-Architected Lens
Die Säule der Leistungseffizienz konzentriert sich auf die effiziente Nutzung von IT- und Computing-Ressourcen. Zu den wichtigsten Themen gehören die Auswahl der richtigen Ressourcentypen und -größen je nach Workload-Anforderungen, die Überwachung der Leistung und das Treffen fundierter Entscheidungen, um die Effizienz aufrechtzuerhalten, wenn sich die Geschäftsanforderungen weiterentwickeln.
**Topics**
+ [PE 1: Wie überwachen Sie die Leistung Ihres ElastiCache Amazon-Clusters?](#PerformanceEfficiencyPillarPE1)
+ [PE 2: Wie verteilen Sie die Arbeit auf Ihre ElastiCache Clusterknoten?](#PerformanceEfficiencyPillarPE2)
+ [PE 3: Wie verfolgen und protokollieren Sie bei Caching-Workloads die Effektivität und Leistung Ihres Caches?](#PerformanceEfficiencyPillarPE3)
+ [PE 4: Wie optimiert Ihr Workload den Einsatz von Netzwerkressourcen und Verbindungen?](#PerformanceEfficiencyPillarPE4)
+ [PE 5: Wie gehen Sie mit dem Löschen von Schlüsseln um and/or ?](#PerformanceEfficiencyPillarPE5)
+ [PE 6: Wie modellieren und interagieren Sie mit Daten in ElastiCache?](#PerformanceEfficiencyPillarPE6)
+ [PE 7: Wie protokollieren Sie langsam laufende Befehle in Ihrem ElastiCache Amazon-Cluster?](#PerformanceEfficiencyPillarPE7)
+ [PE8: Wie hilft Auto Scaling dabei, die Leistung des ElastiCache Clusters zu steigern?](#PerformanceEfficiencyPillarPE8)
## PE 1: Wie überwachen Sie die Leistung Ihres ElastiCache Amazon-Clusters?
**Einführung auf Fragenebene: **Wenn Sie die vorhandenen Überwachungsmetriken verstehen, können Sie die aktuelle Auslastung ermitteln. Eine ordnungsgemäße Überwachung kann dazu beitragen, potenzielle Engpässe zu identifizieren, die sich auf die Leistung Ihres Clusters auswirken.
**Vorteil auf Fragenebene: **Wenn Sie die Metriken Ihres Clusters kennen, können Sie Optimierungsmethoden entwickeln, die zu einer geringeren Latenz und einem höheren Durchsatz führen können.
+ **[Erforderlich] **Basisleistungstests mit einer Teilmenge Ihres Workloads.
+ Sie sollten die Leistung des tatsächlichen Workloads mithilfe von Mechanismen wie Lasttests überwachen.
+ Überwachen Sie die CloudWatch Metriken, während Sie diese Tests durchführen, um sich ein Bild von den verfügbaren Metriken zu machen und eine Leistungsbasis festzulegen.
+ **[Am besten]** Benennen Sie rechenintensive Befehle ElastiCache für Valkey- und Redis-OSS-Workloads um, z. B. um die Fähigkeit von Benutzern einzuschränken`KEYS`, blockierende Befehle auf Produktionsclustern auszuführen.
+ ElastiCache Workloads, auf denen Engine 6.x für Redis OSS ausgeführt wird, können die rollenbasierte Zugriffskontrolle nutzen, um bestimmte Befehle einzuschränken. Der Zugriff auf die Befehle kann gesteuert werden, indem Benutzer und Benutzergruppen mit der AWS Konsole oder CLI erstellt und die Benutzergruppen einem Cluster zugeordnet werden. Wenn RBAC in Redis OSS 6 aktiviert ist, können wir „- @dangerous" verwenden. Dadurch werden teure Befehle wie KEYS, MONITOR, SORT usw. für diesen Benutzer nicht zugelassen.
+ Benennen Sie Befehle für Engine-Version 5.x mithilfe des `rename-commands` Parameters in der Cluster-Parametergruppe um.
+ **[Besser] **Analysieren Sie langsame Abfragen und suchen Sie nach Optimierungsmöglichkeiten.
+ ElastiCache Für Valkey- und Redis-OSS-Workloads erfahren Sie mehr über Ihre Abfragen, indem Sie das Slow Log analysieren. Sie können beispielsweise den folgenden Befehl verwenden, `valkey-cli slowlog get 10` um die letzten 10 Befehle anzuzeigen, die die Latenzschwellenwerte überschritten haben (standardmäßig 10 Millisekunden).
+ Bestimmte Abfragen können effizienter ausgeführt werden, wenn komplexe OSS-Datenstrukturen ElastiCache für Valkey und Redis verwendet werden. Für Bereichsabfragen im numerischen Stil kann eine Anwendung beispielsweise einfache numerische Indizes mit sortierten Sätzen implementieren. Die Verwaltung dieser Indizes kann die Anzahl der am Datensatz durchgeführten Scans reduzieren und Daten mit höherer Leistungseffizienz zurückgeben.
+ ElastiCache Für OSS-Workloads von Valkey und Redis `redis-benchmark` bietet es eine einfache Oberfläche zum Testen der Leistung verschiedener Befehle mithilfe benutzerdefinierter Eingaben wie Anzahl der Clients und Datengröße.
+ Da Memcached nur einfache Befehle auf Schlüsselebene unterstützt, sollten Sie erwägen, zusätzliche Schlüssel als Indizes zu erstellen, um zu vermeiden, dass der Schlüsselbereich wiederholt wird, um Client-Abfragen zu bearbeiten.
+ **[Ressourcen]: **
+ [Überwachung der Nutzung mit Metrics CloudWatch ](CacheMetrics.md)
+ [ CloudWatch Amazon-Alarme verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [OSS-spezifische Parameter für Valkey und Redis](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [SLOWLOG](https://valkey.io/commands/slowlog/)
+ [Benchmark](https://valkey.io/topics/benchmark/)
## PE 2: Wie verteilen Sie die Arbeit auf Ihre ElastiCache Clusterknoten?
**Einführung auf Fragenebene:** Die Art und Weise, wie Ihre Anwendung eine Verbindung zu ElastiCache Amazon-Knoten herstellt, kann sich auf die Leistung und Skalierbarkeit des Clusters auswirken.
**Vorteil auf Fragenebene: **Durch die richtige Nutzung der verfügbaren Knoten im Cluster wird sichergestellt, dass die Arbeit auf die verfügbaren Ressourcen verteilt wird. Die folgenden Methoden tragen ebenfalls dazu bei, ungenutzte Ressourcen zu vermeiden.
+ **[Erforderlich] Sorgen Sie dafür**, dass sich die Clients mit dem richtigen ElastiCache Endpunkt verbinden.
+ ElastiCache für Valkey und Redis implementiert OSS je nach verwendetem Clustermodus unterschiedliche Endpunkte. Wenn der Clustermodus aktiviert ist, ElastiCache wird ein Konfigurationsendpunkt bereitgestellt. ElastiCache Stellt bei deaktiviertem Clustermodus einen primären Endpunkt bereit, der normalerweise für Schreibvorgänge verwendet wird, und einen Leser-Endpunkt für die Verteilung von Lesevorgängen zwischen Replikaten. Die korrekte Implementierung dieser Endpunkte führt zu einer besseren Leistung und einfacheren Skalierungsvorgängen. Vermeiden Sie es, eine Verbindung zu einzelnen Knotenendpunkten herzustellen, es sei denn, dies ist ausdrücklich erforderlich.
+ ElastiCache Stellt für Memcached-Cluster mit mehreren Knoten einen Konfigurationsendpunkt bereit, der Auto Discovery aktiviert. Es wird empfohlen, einen Hashing-Algorithmus zu verwenden, um die Arbeit gleichmäßig auf die Cache-Knoten zu verteilen. Viele Memcached-Clientbibliotheken implementieren konsistentes Hashing. Überprüfen Sie die Dokumentation der von Ihnen verwendeten Bibliothek darauf, ob sie konsistentes Hashing unterstützt und wie es implementiert wird. Weitere Informationen zur Implementierung dieser Funktionen finden Sie [hier](BestPractices.LoadBalancing.md).
+ **[Besser]** Nutzen Sie die Vorteile von Clustern, die im OSS-Clustermodus aktiviert sind, ElastiCache für Valkey und Redis, um die Skalierbarkeit zu verbessern.
+ ElastiCache Für Valkey und Redis OSS (Clustermodus aktiviert) unterstützen Cluster [Online-Skalierungsoperationen](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) (out/in and up/down), um Daten dynamisch auf mehrere Shards zu verteilen. Durch die Verwendung des Konfigurationsendpunkts wird sichergestellt, dass sich Ihre clusterfähigen Clients an Änderungen in der Cluster-Topologie anpassen können.
+ Sie können den Cluster auch neu verteilen, indem Sie Hashslots zwischen verfügbaren Shards in Ihrem ElastiCache for Valkey- und Redis OSS-Cluster (Cluster-Modus aktiviert) verschieben. Dies trägt dazu bei, die Arbeit effizienter auf die verfügbaren Shards zu verteilen.
+ **[Besser] **Implementieren Sie eine Strategie zur Identifizierung und Korrektur von Tastaturbefehlen in Ihrem Workload.
+ Bedenken Sie die Auswirkungen multidimensionaler Valkey- oder Redis-OSS-Datenstrukturen wie Listen, Streams, Sets usw. Diese Datenstrukturen werden in einzelnen Schlüsseln gespeichert, die sich auf einem einzigen Knoten befinden. Ein sehr großer multidimensionaler Schlüssel nimmt potenziell mehr Netzwerkkapazität und Speicher in Anspruch als andere Datentypen und kann eine unverhältnismäßige Nutzung dieses Knotens bewirken. Wenn möglich, sollten Sie Ihren Workload so gestalten, dass der Datenzugriff auf viele einzelne Schlüssel verteilt wird.
+ Tastaturbefehle im Workload können die Leistung des verwendeten Knotens beeinträchtigen. ElastiCache Bei OSS-Workloads von Valkey und Redis können Sie Hotkeys erkennen, `valkey-cli --hotkeys` wenn eine LFU-Richtlinie zur maximalen Speicherbelegung vorhanden ist.
+ Erwägen Sie, Tastaturbefehle auf mehreren Knoten zu replizieren, um den Zugriff auf sie gleichmäßiger zu verteilen. Bei diesem Ansatz muss der Client auf mehrere Primärknoten schreiben (der Valkey- oder Redis-OSS-Knoten selbst bietet diese Funktionalität nicht) und zusätzlich zum ursprünglichen Schlüsselnamen eine Liste mit Schlüsselnamen zum Lesen führen.
+ ElastiCache [Engine 7.2 für Valkey und höher sowie ElastiCache Version 6 für Redis OSS und höher unterstützen alle servergestütztes clientseitiges Caching.](https://valkey.io/topics/client-side-caching/) Auf diese Weise können Anwendungen auf Änderungen an einem Schlüssel warten, bevor sie über das Netzwerk zurückrufen. ElastiCache
+ **[Ressourcen]:**
+ [Konfigurieren Sie ElastiCache für Valkey und Redis OSS für eine höhere Verfügbarkeit](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [Verbindungsendpunkte finden in ElastiCache](Endpoints.md)
+ [Bewährte Methoden für den Lastausgleich](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/BestPractices.LoadBalancing.html)
+ [Online-Resharding für Valkey oder Redis OSS (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Clientseitiges Caching in Valkey und Redis OSS](https://valkey.io/topics/client-side-caching/)
## PE 3: Wie verfolgen und protokollieren Sie bei Caching-Workloads die Effektivität und Leistung Ihres Caches?
**Einführung auf Fragenebene:** Caching ist ein häufig auftretender Workload, ElastiCache und es ist wichtig, dass Sie wissen, wie Sie die Effektivität und Leistung Ihres Caches verwalten können.
**Vorteil auf Fragenebene: **Ihre Anwendung kann Anzeichen einer stagnierenden Leistung aufweisen. Ihre Fähigkeit, Cache-spezifische Metriken als Grundlage für Ihre Entscheidung zur Steigerung der App-Leistung zu verwenden, ist für Ihren Cache-Workload von entscheidender Bedeutung.
+ **[Erforderlich] **Messen und verfolgen Sie die Cache-Trefferquote im Zeitverlauf. Die Effizienz Ihres Caches wird durch seine „Cache-Trefferquote“ bestimmt. Die Cache-Trefferquote wird durch die Summe der Schlüsseltreffer geteilt durch die Gesamtzahl der Treffer und Fehlversuche definiert. Je näher die Quote an 1 liegt, desto effektiver ist Ihr Cache. Eine niedrige Cache-Trefferquote wird durch die Menge der Cache-Fehlversuche verursacht. Cache-Fehlversuche treten auf, wenn der angeforderte Schlüssel nicht im Cache gefunden wird. Ein Schlüssel befindet sich nicht im Cache, weil er entweder bereinigt oder gelöscht wurde, abgelaufen ist oder nie existiert hat. Machen Sie sich klar, warum sich Schlüssel nicht im Cache befinden, und entwickeln Sie geeignete Strategien, um sie im Cache vorliegen zu haben.
**[Ressourcen]:**
+ [Metriken für Valkey und Redis OSS](CacheMetrics.Redis.md)
+ **[Erforderlich]** Messen und erfassen Sie die Leistung Ihres Anwendungs-Caches in Verbindung mit den Werten für Latenz und CPU-Auslastung, um zu ermitteln, ob Sie Anpassungen an Ihren time-to-live oder anderen Anwendungskomponenten vornehmen müssen. ElastiCache bietet eine Reihe von CloudWatch Metriken für aggregierte Latenzen für jede Datenstruktur. Diese Latenzmetriken werden anhand der Commandstats-Statistik des Befehls INFO berechnet und beinhalten nicht die Netzwerk- und I/O-Zeit. Dies ist nur die Zeit, die für die Verarbeitung der ElastiCache Operationen benötigt wird.
**[Ressourcen]:**
+ [Metriken für Valkey und Redis OSS](CacheMetrics.Redis.md)
+ [Überwachung von Best Practices ElastiCache mithilfe von Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Am besten] **Wählen Sie die richtige Caching-Strategie für Ihre Anforderungen aus. Eine niedrige Cache-Trefferquote wird durch die Menge der Cache-Fehlversuche verursacht. Wenn Ihr Workload so konzipiert ist, dass es nur wenige Cache-Fehlversuche gibt (z. B. Kommunikation in Echtzeit), sollten Sie Ihre Caching-Strategien überprüfen und die für Ihren Workload am besten geeigneten Lösungen anwenden, z. B. Abfrage-Instrumente zur Messung von Speicher und Leistung. Die tatsächlichen Strategien, die Sie zum Auffüllen und Verwalten Ihres Cache implementieren müssen, hängt von den Daten, die Ihre Clients zwischenspeichern müssen, und den Zugriffsmustern auf diese Daten ab. Es ist beispielsweise unwahrscheinlich, dass Sie dieselbe Strategie sowohl für personalisierte Empfehlungen in einer Streaming-Anwendung als auch für aktuelle Nachrichten verwenden.
**[Ressourcen]:**
+ [Caching-Strategien für Memcached](Strategies.md)
+ [Bewährte Methoden für das Caching](https://aws.amazon.com/caching/best-practices/)
+ [Skalierbare Leistung mit Amazon ElastiCache Whitepaper](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf)
## PE 4: Wie optimiert Ihr Workload den Einsatz von Netzwerkressourcen und Verbindungen?
**Einführung auf Fragenebene:** ElastiCache Für Valkey, Memcached und Redis wird OSS von vielen Anwendungsclients unterstützt, und die Implementierungen können variieren. Sie müssen das vorhandene Netzwerk- und Verbindungsmanagement verstehen, um mögliche Auswirkungen auf die Leistung zu analysieren.
**Vorteil auf Fragenebene: **Die effiziente Nutzung von Netzwerkressourcen kann die Leistungseffizienz Ihres Clusters verbessern. Die folgenden Empfehlungen können die Netzwerkanforderungen reduzieren und die Latenz und den Durchsatz des Clusters verbessern.
+ **[Erforderlich]** Verwalten Sie proaktiv Verbindungen zu Ihrem Cluster. ElastiCache
+ Verbindungspooling in der Anwendung reduziert den Overhead im Cluster, der durch das Öffnen und Schließen von Verbindungen entsteht. Überwachen Sie das Verbindungsverhalten in Amazon CloudWatch mithilfe von `CurrConnections` und`NewConnections`.
+ Vermeiden Sie Verbindungslecks, indem Sie die Client-Verbindungen gegebenenfalls ordnungsgemäß schließen. Zu den Strategien zur Verbindungsverwaltung gehören das ordnungsgemäße Schließen von Verbindungen, die nicht verwendet werden, und das Festlegen von Verbindungs-Timeouts.
+ Für Memcached-Workloads gibt es eine konfigurierbare Speichermenge, die für die Verarbeitung von Verbindungen reserviert ist und als `memcached_connections_overhead` bezeichnet wird.
+ **[Besser] **Komprimieren Sie große Objekte, um den Speicherplatz zu reduzieren und den Netzwerkdurchsatz zu verbessern.
+ Datenkomprimierung kann den erforderlichen Netzwerkdurchsatz (GBit/s) reduzieren, erhöht jedoch den Arbeitsaufwand für die Anwendung zum Komprimieren und Dekomprimieren von Daten.
+ Durch die Komprimierung wird auch der Speicherverbrauch von Schlüsseln reduziert.
+ Berücksichtigen Sie auf der Grundlage Ihrer Anwendungsanforderungen die Kompromisse zwischen Komprimierungsverhältnis und Komprimierungsgeschwindigkeit.
+ **[Ressourcen]:**
+ [ElastiCache - Globaler Datenspeicher](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [Memcached-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Memcached)
+ [ElastiCache Version 5.0.3 für Redis OSS verbessert I/O die Handhabung, um die Leistung zu steigern](https://aws.amazon.com/about-aws/whats-new/2019/03/amazon-elasticache-for-redis-503-enhances-io-handling-to-boost-performance/)
+ [Metriken für Valkey und Redis OSS](CacheMetrics.Redis.md)
+ [ ElastiCache Für höhere Verfügbarkeit konfigurieren](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
## PE 5: Wie gehen Sie mit dem Löschen von Schlüsseln um and/or ?
**Einführung auf Fragenebene:** Workloads haben unterschiedliche Anforderungen und erwartetes Verhalten, wenn sich ein Clusterknoten den Grenzwerten für den Speicherverbrauch nähert. ElastiCache hat unterschiedliche Richtlinien für den Umgang mit diesen Situationen.
**Vorteil auf Fragenebene: **Die richtige Verwaltung des verfügbaren Speichers und das Verständnis der Löschungsrichtlinien tragen dazu bei, dass das Clusterverhalten bei Überschreitung der Speicherlimits von Instances besser erkannt wird.
+ **[Erforderlich] **Instrumentieren Sie den Datenzugriff, um zu beurteilen, welche Richtlinie angewendet werden soll. Identifizieren Sie eine geeignete Richtlinie für maximalen Arbeitsspeicher, um zu kontrollieren, ob und wie Bereinigungen im Cluster durchgeführt werden.
+ Eine Bereinigung erfolgt, wenn der maximale Arbeitsspeicher des Clusters verbraucht ist und eine Richtlinie vorhanden ist, welche die Bereinigung zulässt. Das Verhalten des Clusters in dieser Situation hängt von der angegebenen Bereinigungsrichtlinie ab. Diese Richtlinie kann mithilfe der Parametergruppe `maxmemory-policy` auf dem Cluster verwaltet werden.
+ Die Standardrichtlinie `volatile-lru` gibt Speicherplatz frei, indem Schlüssel mit einer festgelegten Ablaufzeit (TTL-Wert) bereinigt werden. Die Richtlinien „Least frequently used“ (LFU, am wenigsten häufig verwendet) und „Least recently used“ (LRU, am wenigsten zuletzt verwendet) entfernen Schlüssel je nach Nutzung.
+ Für Memcached-Workloads gibt es eine standardmäßige LRU-Richtlinie, welche die Bereinigungen auf jedem Knoten steuert. Die Anzahl der Räumungen in Ihrem ElastiCache Amazon-Cluster kann mithilfe der Räumungsmetrik auf Amazon überwacht werden. CloudWatch
+ **[Besser] **Standardisieren Sie das Löschverhalten, um die Auswirkungen auf die Leistung Ihres Clusters zu kontrollieren und unerwartete Leistungsengpässe zu vermeiden.
+ ElastiCache Denn bei OSS-Workloads von Valkey und Redis `UNLINK` ist das explizite Entfernen von Schlüsseln aus dem Cluster wie folgt`DEL`: Die angegebenen Schlüssel werden entfernt. Der Befehl führt jedoch die eigentliche Speicherrückgewinnung in einem anderen Thread durch, sodass er nicht blockiert, während dies mit `DEL` der Fall ist. Die eigentliche Entfernung erfolgt später asynchron.
+ Bei ElastiCache Version 6.x für Redis OSS-Workloads kann das Verhalten des `DEL` Befehls in der Parametergruppe mithilfe von Parameter geändert werden. `lazyfree-lazy-user-del`
+ **[Ressourcen]:**
+ [Konfiguration von Motorparametern mithilfe von ElastiCache Parametergruppen](ParameterGroups.md)
+ [UNLINK](https://valkey.io/commands/unlink/)
+ [Cloud-Finanzmanagement mit AWS](https://aws.amazon.com/aws-cost-management/)
## PE 6: Wie modellieren und interagieren Sie mit Daten in ElastiCache?
**Einführung auf Fragenebene:** ElastiCache Ist stark von der Anwendung abhängig von den Datenstrukturen und dem verwendeten Datenmodell, muss aber auch der zugrunde liegende Datenspeicher (falls vorhanden) berücksichtigt werden. Machen Sie sich mit den verfügbaren Datenstrukturen vertraut und stellen Sie sicher, dass Sie die Datenstrukturen verwenden, die Ihren Anforderungen am besten entsprechen.
**Vorteil auf Frageebene:** Die Datenmodellierung ElastiCache besteht aus mehreren Ebenen, einschließlich Anwendungsfällen, Datentypen und Beziehungen zwischen Datenelementen. Darüber hinaus verfügen alle Datentypen und Befehle über eigene, gut dokumentierte Leistungssignaturen.
+ **[Am besten] **Eine bewährte Methode besteht darin, das unbeabsichtigte Überschreiben von Daten zu reduzieren. Verwenden Sie eine Namenskonvention, die überlappende Schlüsselnamen minimiert. Bei der herkömmlichen Benennung Ihrer Datenstrukturen wird eine hierarchische Methode wie `APPNAME:CONTEXT:ID` bzw. `ORDER-APP:CUSTOMER:123` verwendet.
**[Ressourcen]:**
+ [Benennung von Schlüsseln](https://docs.gitlab.com/ee/development/redis.html#key-naming)
+ **[Best]** ElastiCache for Valkey und Redis OSS-Befehle haben eine Zeitkomplexität, die durch die Big-O-Notation definiert wird. Diese Zeitkomplexität eines Befehls ist eine algorithmic/mathematical Darstellung seiner Auswirkungen. Bei der Einführung eines neuen Datentyps in Ihre Anwendung müssen Sie die Zeitkomplexität der zugehörigen Befehle sorgfältig überprüfen. Befehle mit einer Zeitkomplexität von O(1) sind zeitlich konstant und hängen nicht von der Größe der Eingabe ab. Befehle mit einer Zeitkomplexität von O(N) sind jedoch zeitlich linear und hängen von der Größe der Eingabe ab. Aufgrund des Single-Thread-Designs von ElastiCache Valkey und Redis OSS führt ein großes Volumen an Vorgängen mit hoher Zeitkomplexität zu einer geringeren Leistung und möglichen Zeitüberschreitungen.
**[Ressourcen]:**
+ [Befehle](https://valkey.io/commands/)
+ **[Am besten]** Verwenden Sie diese Option APIs , um sich über die grafische Benutzeroberfläche einen Überblick über das Datenmodell in Ihrem Cluster zu verschaffen.
**[Ressourcen]:**
+ [Redis OSS Commander](https://www.npmjs.com/package/ElastiCache for Redis-commander)
+ [Redis OSS-Browser](https://github.com/humante/redis-browser)
+ [Redsmin](https://www.redsmin.com/)
## PE 7: Wie protokollieren Sie langsam laufende Befehle in Ihrem ElastiCache Amazon-Cluster?
**Einführung auf Fragenebene: **Die Leistungsoptimierung bietet Vorteile durch die Erfassung, Aggregation und Benachrichtigung von Befehlen mit langer Laufzeit. Wenn Sie wissen, wie lange die Ausführung von Befehlen dauert, können Sie feststellen, welche Befehle zu einer schlechten Leistung führen und welche Befehle die Engine daran hindern, optimal zu funktionieren. ElastiCache kann diese Informationen auch an Amazon CloudWatch oder Amazon Kinesis Data Firehose weiterleiten.
**Vorteil auf Fragenebene: **Die Protokollierung an einem festen Standort und die Bereitstellung von Benachrichtigungsereignissen bei langsamen Befehlen können zu einer detaillierten Leistungsanalyse beitragen und zur Auslösung automatisierter Ereignisse verwendet werden.
+ **[Erforderlich]** ElastiCache Ausführung einer Valkey-Engine 7.2 oder neuer oder Ausführung einer Redis OSS-Engine Version 6.0 oder neuer, ordnungsgemäß konfigurierte Parametergruppe und aktiviertes SLOWLOG-Logging auf dem Cluster.
+ Die erforderlichen Parameter sind nur verfügbar, wenn die Engine-Versionskompatibilität auf Valkey 7.2 und höher oder Redis OSS Version 6.0 oder höher eingestellt ist.
+ Die SLOWLOG-Protokollierung erfolgt, wenn die Serverausführungszeit eines Befehls länger als ein bestimmter Wert dauert. Das Verhalten des Clusters hängt von den zugehörigen Parametergruppenparametern ab, d. h. `slowlog-log-slower-than` und `slowlog-max-len`.
+ Änderungen werden sofort wirksam.
+ **[Am besten]** Nutzen Sie unsere Kinesis Data Firehose Firehose-Funktionen. CloudWatch
+ Nutzen Sie die Filter- und Alarmfunktionen von CloudWatch CloudWatch Logs Insights und Amazon Simple Notification Services, um die Leistung zu überwachen und Ereignisse zu benachrichtigen.
+ Verwenden Sie die Streaming-Funktionen von Kinesis Data Firehose, um SLOWLOG-Protokolle im permanenten Speicher zu archivieren oder um eine automatische Cluster-Parameteroptimierung auszulösen.
+ Stellen Sie fest, ob das JSON- oder Plain-TEXT-Format Ihren Anforderungen am besten entspricht.
+ Stellen Sie IAM-Berechtigungen für die Veröffentlichung in CloudWatch oder Kinesis Data Firehose bereit.
+ **[Besser] **Konfigurieren Sie `slowlog-log-slower-than` auf einen anderen Wert als den Standardwert.
+ Dieser Parameter bestimmt, wie lange ein Befehl innerhalb der Valkey- oder Redis-OSS-Engine ausgeführt werden kann, bevor er als langsam laufender Befehl protokolliert wird. Der Standardwert ist 10 000 Mikrosekunden (10 Millisekunden). Der Standardwert ist für einige Workloads möglicherweise zu hoch.
+ Ermitteln Sie auf der Grundlage der Anwendungsanforderungen und der Testergebnisse einen Wert, der für Ihren Workload besser geeignet ist. Ein zu niedriger Wert kann jedoch zu übermäßigen Daten führen.
+ **[Besser] **Übernehmen Sie für `slowlog-max-len` den Standardwert.
+ Dieser Parameter bestimmt die Obergrenze dafür, wie viele langsam laufende Befehle zu einem bestimmten Zeitpunkt im Valkey- oder Redis-OSS-Speicher erfasst werden. Mit dem Wert 0 wird die Erfassung effektiv deaktiviert. Je höher der Wert, desto mehr Einträge werden im Speicher gespeichert. Dadurch wird die Wahrscheinlichkeit verringert, dass wichtige Informationen bereinigt werden, bevor sie überprüft werden können. Der Standardwert lautet 128.
+ Der Standardwert ist für die meisten Workloads geeignet. Wenn Daten in einem erweiterten Zeitfenster von der Valkey-CLI aus über den SLOWLOG-Befehl analysiert werden müssen, sollten Sie erwägen, diesen Wert zu erhöhen. Dadurch können mehr Befehle im OSS-Speicher von Valkey oder Redis verbleiben.
Wenn Sie die SLOWLOG-Daten entweder an CloudWatch Logs oder Kinesis Data Firehose ausgeben, werden die Daten dauerhaft gespeichert und können außerhalb des ElastiCache Systems analysiert werden, wodurch die Notwendigkeit reduziert wird, eine große Anzahl langsam laufender Befehle im Valkey- oder Redis-OSS-Speicher zu speichern.
+ **[Ressourcen]:**
+ [Wie aktiviere ich Slow Log in einem Cluster?](https://repost.aws/knowledge-center/elasticache-turn-on-slow-log)
+ [Protokollzustellung](Log_Delivery.md)
+ [Redis OSS-spezifische Parameter](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [https://aws.amazon.com/cloudwatch/](https://aws.amazon.com/cloudwatch/)Amazon CloudWatch
+ [Amazon Kinesis Data Firehose](https://aws.amazon.com/kinesis/data-firehose/)
## PE8: Wie hilft Auto Scaling dabei, die Leistung des ElastiCache Clusters zu steigern?
**Einführung auf Fragenebene:** Durch die Implementierung der Funktion von Valkey oder Redis OSS Auto Scaling können sich Ihre ElastiCache Komponenten im Laufe der Zeit anpassen, um die gewünschten Shards oder Replicas automatisch zu erhöhen oder zu verringern. Dies kann erreicht werden, indem entweder die Zielverfolgung oder die geplante Skalierungsrichtlinie implementiert wird.
**Vorteil auf Fragenebene: Wenn Sie die Arbeitslastspitzen verstehen und entsprechend planen, können Sie eine verbesserte Caching-Leistung und einen unterbrechungsfreien** Betrieb sicherstellen. ElastiCache Auto Scaling überwacht kontinuierlich Ihre CPU-/Speicherauslastung, um sicherzustellen, dass Ihr Cluster mit den gewünschten Leistungsniveaus arbeitet.
+ **[Erforderlich]** Beim Starten eines Clusters ElastiCache für Valkey oder Redis OSS:
1. Stellen Sie sicher, dass der Clustermodus aktiviert ist.
1. Stellen Sie sicher, dass die Instance zu einer Familie mit einem bestimmten Typ und einer bestimmten Größe gehört, die Auto Scaling unterstützt.
1. Vergewissern Sie sich, dass der Cluster nicht in globalen Datenspeichern, Outposts oder lokalen Zonen ausgeführt wird
**[Ressourcen]:**
+ [Skalierung von Clustern in Valkey und Redis OSS (Clustermodus aktiviert)](scaling-redis-cluster-mode-enabled.md)
+ [Verwenden von Auto Scaling mit Shards](AutoScaling-Using-Shards.md)
+ [Verwenden von Auto Scaling mit Replikaten](AutoScaling-Using-Replicas.md)
+ **[Am besten] **Stellen Sie fest, ob Ihr Workload lese- oder schreibintensiv ist, um die Skalierungsrichtlinie zu definieren. Verwenden Sie nur eine Nachverfolgungsmetrik, um eine optimale Leistung zu erzielen. Es wird empfohlen, für jede Dimension mehrere Richtlinien zu vermeiden, da Auto-Scaling-Richtlinien aufskalieren, wenn das Ziel erreicht wird, aber erst dann abskalieren, wenn alle Ziel-Nachverfolgungsrichtlinien für die Abskalierung bereit sind.
**[Ressourcen]:**
+ [Auto-Scaling-Richtlinien](AutoScaling-Policies.md)
+ [Definieren einer Skalierungsrichtlinie](AutoScaling-Scaling-Defining-Policy-API.md)
+ **[Am besten] **Wenn Sie die Leistung im Zeitverlauf überwachen, können Sie Workload-Änderungen erkennen, die bei punktueller Überwachung unbemerkt bleiben würden. Sie können die entsprechenden CloudWatch Metriken für die Clusterauslastung über einen Zeitraum von vier Wochen analysieren, um den Zielschwellenwert zu bestimmen. Wenn Sie sich immer noch nicht sicher sind, welchen Wert Sie wählen möchten, empfehlen wir, mit dem minimal unterstützten vordefinierten Metrikwert zu beginnen.
**[Ressourcen]:**
+ [Überwachung der Nutzung mit Metriken CloudWatch ](CacheMetrics.md)
+ **[Besser]** Wir empfehlen, Ihre Anwendung mit den erwarteten minimalen und maximalen Workloads zu testen, um die genaue Anzahl der Workloads zu ermitteln, die der Cluster shards/replicas benötigt, um Skalierungsrichtlinien zu entwickeln und Verfügbarkeitsprobleme zu minimieren.
**[Ressourcen]:**
+ [Registrieren eines skalierbaren Ziels](AutoScaling-Register-Policy.md)
+ [Registrierung eines skalierbaren Ziels mit dem AWS CLI](AutoScaling-Scaling-Registering-Policy-CLI.md)
# Säule zur ElastiCache Kostenoptimierung bei Amazon Well-Architected Lens
Die Säule der Kostenoptimierung konzentriert sich auf die Vermeidung unnötiger Kosten. Zu den wichtigsten Themen gehören das Verständnis und die Kontrolle, wofür Geld ausgegeben wird, die Auswahl des am besten geeigneten Knotentyps (verwenden Sie Instances, die das Daten-Tiering auf der Grundlage der Workload-Anforderungen unterstützen), die richtige Anzahl von Ressourcentypen (wie viele Lesereplikate), die Analyse der Ausgaben im Zeitverlauf und die Skalierung, um Geschäftsanforderungen zu erfüllen, ohne zu viel Geld auszugeben.
**Topics**
+ [COST 1: Wie identifizieren und verfolgen Sie die mit Ihren ElastiCache Ressourcen verbundenen Kosten? Wie entwickeln Sie Mechanismen, die es Benutzern ermöglichen, Ressourcen zu erstellen, zu verwalten und zu entsorgen?](#CostOptimizationPillarCOST1)
+ [COST 2: Wie nutzen Sie Tools zur kontinuierlichen Überwachung, um die mit Ihren ElastiCache Ressourcen verbundenen Kosten zu optimieren?](#CostOptimizationPillarCOST2)
+ [COST 3: Sollten Sie einen Instance-Typ verwenden, der Daten-Tiering unterstützt? Was sind die Vorteile von Daten-Tiering? Wann sollten Daten-Tiering-Instances nicht verwendet werden?](#CostOptimizationPillarCOST3)
## COST 1: Wie identifizieren und verfolgen Sie die mit Ihren ElastiCache Ressourcen verbundenen Kosten? Wie entwickeln Sie Mechanismen, die es Benutzern ermöglichen, Ressourcen zu erstellen, zu verwalten und zu entsorgen?
**Einführung auf Fragenebene: **Um Kostenmetriken zu verstehen, müssen mehrere Teams beteiligt werden und zusammenarbeiten: Softwareentwicklung, Datenmanagement, Produktbesitzer, Finanzen und Führung. Um die wichtigsten Kostentreiber zu identifizieren, müssen alle Beteiligten die Hebel der Kontrolle der Servicenutzung und die Kompromisse beim Kostenmanagement verstehen. Dies ist häufig der entscheidende Unterschied zwischen erfolgreichen und weniger erfolgreichen Bemühungen zur Kostenoptimierung. Wenn Sie sicherstellen, dass Sie über Prozesse und Tools verfügen, mit denen Sie die Ressourcen verfolgen können, die von der Entwicklung über die Produktion bis hin zur Außerbetriebnahme geschaffen wurden, können Sie die damit verbundenen Kosten besser kontrollierenElastiCache.
**Vorteil auf Fragenebene:** Die kontinuierliche Erfassung aller mit Ihrem Workload verbundenen Kosten erfordert ein tiefes Verständnis der Architektur, zu der ElastiCache auch eine ihrer Komponenten gehört. Darüber hinaus sollten Sie über einen Kostenmanagementplan verfügen, um die Nutzung zu erfassen und mit Ihrem Budget zu vergleichen.
+ **[Erforderlich] Richten** Sie ein Cloud Center of Excellence (CCoE) mit einer der Gründungschartas ein, das die Definition, Nachverfolgung und Umsetzung von Kennzahlen rund um die Nutzung in Ihrem Unternehmen selbst übernimmt. ElastiCache Wenn ein CCo E existiert und funktioniert, stellen Sie sicher, dass es weiß, wie die damit verbundenen Kosten zu lesen und nachzuverfolgen sind. ElastiCache Wenn Ressourcen erstellt werden, überprüfen Sie anhand von IAM-Rollen und -Richtlinien, dass nur bestimmte Teams und Gruppen Ressourcen instanziieren können. Damit wird sichergestellt, dass die Kosten mit den Geschäftsergebnissen in Verbindung stehen und dass im Hinblick auf die Kosten eine klare Linienverantwortung festgelegt wird.
1. CCoE sollte Kostenkennzahlen identifizieren, definieren und veröffentlichen, die regelmäßig — monatlich — aktualisiert werden und sich auf die wichtigsten ElastiCache Nutzungsdaten beziehen, wie z. B.:
1. Verwendete Knotentypen und ihre Attribute: Standard oder speicheroptimiert, On-Demand-Instances oder Reserved Instances, Regionen und Availability Zones
1. Arten von Umgebungen: kostenlose Umgebungen, Entwicklungsumgebungen, Testumgebungen und Produktionsumgebungen
1. Strategien zur Speicherung und Aufbewahrung von Backups
1. Datentransfer innerhalb und zwischen Regionen
1. Instances, die in Amazon Outposts ausgeführt werden
1. CCoE besteht aus einem funktionsübergreifenden Team, in dem nicht ausschließlich Softwareentwicklung, Datenmanagement, Produktteam, Finanzen und Führungsteams in Ihrem Unternehmen vertreten sind.
**[Ressourcen]:**
+ [Schaffen eines Cloud-Kompetenzzentrums](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html)
+ [ ElastiCacheAmazon-Preisgestaltung](https://aws.amazon.com/elasticache/pricing/)
+ **[Erforderlich] **Verwenden Sie Kostenzuordnungs-Tags, um die Kosten auf einer niedrigen Granularitätsstufe zu verfolgen. Verwenden Sie AWS Cost Management, um Ihre AWS Kosten und Nutzung im Laufe der Zeit zu visualisieren, zu verstehen und zu verwalten.
1. Verwenden Sie Tags, um Ihre Ressourcen zu organisieren, und Tags zur Kostenzuweisung, um Ihre AWS Kosten detailliert zu verfolgen. Nachdem Sie die Kostenzuordnungs-Tags aktiviert haben, AWS verwendet es die Kostenzuordnungs-Tags, um Ihre Ressourcenkosten in Ihrem Kostenzuordnungsbericht zu organisieren, sodass Sie Ihre AWS Kosten leichter kategorisieren und verfolgen können. AWS stellt zwei Arten von Kostenverrechnungs-Tags bereit: AWS generierte Tags und benutzerdefinierte Tags. AWS definiert, erstellt und wendet die AWS generierten Tags für Sie an, und Sie definieren, erstellen und wenden benutzerdefinierte Tags an. Sie müssen beide Arten von Tags separat aktivieren, bevor sie in AWS-Kostenmanagement oder einem Kostenzuordnungsbericht angezeigt werden können.
1. Verwenden Sie Tags für die Kostenzuweisung, um Ihre AWS Rechnung so zu organisieren, dass sie Ihrer eigenen Kostenstruktur entspricht. Wenn Sie Ihren Ressourcen in Amazon Kostenzuordnungs-Tags hinzufügen ElastiCache, können Sie die Kosten verfolgen, indem Sie die Ausgaben auf Ihren Rechnungen nach Ressourcen-Tag-Werten gruppieren. Erwägen Sie, ob Sie Tags miteinander kombinieren, um Kosten detaillierter zu verfolgen.
**[Ressourcen]:**
+ [Verwenden von AWS Kostenzuweisungs-Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [Überwachen von Kosten mit Kostenzuordnungs-Tags](Tagging.md)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ **[Am besten] Verknüpfen** Sie ElastiCache Kosten mit Kennzahlen, die sich auf das gesamte Unternehmen auswirken.
1. Berücksichtigen Sie sowohl Geschäftsmetriken als auch betriebliche Metriken wie die Latenz – welche Konzepte in Ihrem Geschäftsmodell sind rollenübergreifend verständlich? Die Metriken müssen für so viele Rollen wie möglich in der Organisation verständlich sein.
1. Beispiele: Benutzer, die gleichzeitig bedient werden, maximale und durchschnittliche Latenz pro Vorgang und Benutzer, Werte der Benutzerinteraktion, Anzahl der rates/week, session length/user Benutzerrückgänge, Abbruchrate, Cache-Trefferquote und verfolgte Schlüssel
**[Ressourcen]:**
+ [Überwachung der Nutzung mit Metriken CloudWatch ](CacheMetrics.md)
+ **[Gut]** Sorgen Sie für einen Überblick über die up-to-date Architektur und den Betrieb der Kennzahlen und Kosten für den gesamten verwendeten Workload ElastiCache.
1. Verstehen Sie Ihr gesamtes Lösungsökosystem, das in der ElastiCache Regel Teil eines vollständigen Ökosystems von AWS Diensten in seinem Technologieangebot ist, von Kunden über API Gateway, Redshift bis hin QuickSight zu Reporting-Tools (zum Beispiel).
1. Tragen Sie die Komponenten Ihrer Lösung wie Clients, Verbindungen, Sicherheit, In-Memory-Betrieb, Speicher, Ressourcenautomatisierung, Datenzugriff und -verwaltung in Ihrem Architekturdiagramm auf. Jede Ebene ist mit der gesamten Lösung verbunden und hat ihre eigenen Bedürfnisse und Funktionen, die and/or Ihnen helfen, die Gesamtkosten im Griff zu behalten.
1. Ihr Diagramm sollte die Nutzung von Rechenleistung, Netzwerk, Speicher, Lebenszyklusrichtlinien, die Erfassung von Kennzahlen sowie die betrieblichen und funktionalen ElastiCache Elemente Ihrer Anwendung beinhalten
1. Die Anforderungen Ihres Workloads werden sich wahrscheinlich im Laufe der Zeit ändern. Es ist wichtig, dass Sie Ihr Wissen über die zugrundeliegenden Komponenten sowie Ihre primären funktionalen Ziele aufrechterhalten und dokumentieren, um Ihr Workload-Kostenmanagement proaktiv zu gestalten.
1. Die Unterstützung der Geschäftsleitung in Bezug auf Transparenz, Rechenschaftspflicht, Priorisierung und Ressourcen ist entscheidend für eine effektive Kostenmanagementstrategie für Ihr Unternehmen. ElastiCache
## COST 2: Wie nutzen Sie Tools zur kontinuierlichen Überwachung, um die mit Ihren ElastiCache Ressourcen verbundenen Kosten zu optimieren?
**Einführung auf Fragenebene:** Sie müssen ein ausgewogenes Verhältnis zwischen Ihren ElastiCache Kosten- und Anwendungsleistungskennzahlen anstreben. Amazon CloudWatch bietet Einblicke in wichtige Betriebskennzahlen, anhand derer Sie beurteilen können, ob Ihre ElastiCache Ressourcen im Verhältnis zu Ihren Anforderungen über- oder unterausgelastet sind. Im Hinblick auf die Kostenoptimierung müssen Sie verstehen, wann Ihre Ressourcen überlastet sind, und in der Lage sein, geeignete Mechanismen zu entwickeln, um die Größe Ihrer ElastiCache Ressourcen zu ändern und gleichzeitig Ihre Betriebs-, Verfügbarkeits-, Belastbarkeits- und Leistungsanforderungen aufrechtzuerhalten.
**Vorteil auf Fragenebene: **Im Idealfall haben Sie genügend Ressourcen bereitgestellt, um die betrieblichen Anforderungen Ihres Workloads zu erfüllen, und verfügen nicht über unterausgelastete Ressourcen, was zu einer suboptimalen Kostensituation führen kann. Sie müssen in der Lage sein, überdimensionierte ElastiCache Ressourcen sowohl zu identifizieren als auch zu vermeiden, sie über einen längeren Zeitraum zu betreiben.
+ **[Erforderlich] Wird** verwendet CloudWatch , um Ihre ElastiCache Cluster zu überwachen und zu analysieren, wie sich diese Metriken auf Ihre AWS Cost Explorer Explorer-Dashboards beziehen.
1. ElastiCache bietet sowohl Metriken auf Host-Ebene (z. B. CPU-Auslastung) als auch Metriken, die für die Cache-Engine-Software spezifisch sind (z. B. Cache-Abrufe und Cache-Fehlschläge). Diese Metriken werden für jeden Cache-Knoten in 60-Sekunden-Intervallen erfasst und veröffentlicht.
1. ElastiCache Leistungsmetriken (CPUUtilization, EngineUtilization SwapUsage CurrConnections, und Räumungen) können darauf hinweisen, dass Sie skalieren müssen up/down (verwenden Sie larger/smaller Cache-Knotentypen) oder Shards). in/out (add more/less Machen Sie sich mit den Auswirkungen von Skalierungsentscheidungen auf die Kosten vertraut, indem Sie eine Playbook-Matrix erstellen, in der die zusätzlichen Kosten sowie die Mindest- und Höchstdauer geschätzt werden, die erforderlich sind, um die Schwellenwerte für die Anwendungsleistung zu erreichen.
**[Ressourcen]:**
+ [Überwachung der Nutzung mithilfe von Metriken CloudWatch ](CacheMetrics.md)
+ [Welche Metriken sollte ich überwachen?](CacheMetrics.WhichShouldIMonitor.md)
+ [ ElastiCacheAmazon-Preisgestaltung](https://aws.amazon.com/elasticache/pricing/)
+ **[Erforderlich] **Verstehen und dokumentieren Sie Ihre Backup-Strategie und die Auswirkungen auf die Kosten.
1. Mit ElastiCache, die Backups werden in Amazon S3 gespeichert, was eine dauerhafte Speicherung bietet. Sie müssen die Kostenauswirkungen verstehen, die sich aus Ihrer Fähigkeit ergeben, sich nach Ausfällen zu erholen.
1. Aktivieren Sie automatische Backups, mit denen Backup-Dateien gelöscht werden, die das Aufbewahrungslimit überschritten haben.
**[Ressourcen]:**
+ [Planen automatischer Backups](backups-automatic.md)
+ [Amazon Simple Storage Service – Preise](https://aws.amazon.com/s3/pricing/)
+ **[Am besten] **Verwenden Sie reservierte Knoten für Ihre Instances als bewusste Strategie zur Kostenkontrolle für Workloads, die wohlverstanden und dokumentiert sind. Für reservierte Knoten wird eine Vorausgebühr erhoben, die von der Art des Knotens und der Dauer der Reservierung – ein oder drei Jahre – abhängt. Diese Gebühr ist wesentlich geringer als die stündliche Nutzungsgebühr, die bei On-Demand-Knoten anfällt.
1. Möglicherweise müssen Sie Ihre ElastiCache Cluster mit On-Demand-Knoten betreiben, bis Sie genügend Daten gesammelt haben, um die Reserved Instance-Anforderungen abzuschätzen. Planen und dokumentieren Sie die Ressourcen, die Sie benötigen, um Ihre Anforderungen zu erfüllen, und vergleichen Sie die erwarteten Kosten für die verschiedenen Instance-Typen (On-Demand-Instances und Reserved Instances).
1. Evaluieren Sie regelmäßig die neuen verfügbaren Cache-Knotentypen und beurteilen Sie, ob es aus Sicht der Kosten- und Betriebsmetriken sinnvoll ist, Ihre Instance-Flotte auf neue Cache-Knotentypen zu migrieren.
## COST 3: Sollten Sie einen Instance-Typ verwenden, der Daten-Tiering unterstützt? Was sind die Vorteile von Daten-Tiering? Wann sollten Daten-Tiering-Instances nicht verwendet werden?
**Einführung auf Fragenebene: **Die Auswahl des geeigneten Instance-Typs wirkt sich nicht nur auf die Leistung und das Service-Level aus, sondern hat auch finanzielle Auswirkungen. Mit Instance-Typen sind unterschiedliche Kosten verbunden. Die Auswahl eines oder mehrerer großer Instance-Typen, die alle Speicheranforderungen im Arbeitsspeicher erfüllen, könnte sich anbieten. Dies könnte jedoch erhebliche Kostenauswirkungen haben, sobald das Projekt ausgereift ist. Um sicherzustellen, dass der richtige Instance-Typ ausgewählt wird, muss die Leerlaufzeit der ElastiCache Objekte regelmäßig überprüft werden.
**Vorteil auf Fragenebene: **Sie sollten genau wissen, wie sich verschiedene Instance-Typen derzeit und in Zukunft auf Ihre Kosten auswirken. Geringe oder regelmäßige Workload-Änderungen sollten nicht zu unverhältnismäßigen Kostenänderungen führen. Wenn der Workload es zulässt, bieten Instance-Typen, die Daten-Tiering unterstützen, einen besseren Preis pro verfügbarem Speicher. Aufgrund des pro Instance verfügbaren SSD-Speichers unterstützen Daten-Tiering-Instances eine viel höhere Gesamtkapazität für Daten pro Instance.
+ **[Erforderlich] **Kennen der Einschränkungen von Daten-Tiering-Instances
1. Nur ElastiCache für Valkey- oder Redis OSS-Cluster verfügbar.
1. Nur begrenzte Instance-Typen unterstützen Daten-Tiering.
1. Nur ElastiCache Version 6.2 für Redis OSS und höher wird unterstützt
1. Große Objekte werden nicht auf SSD ausgelagert. Objekte über 128 MiB werden im Speicher aufbewahrt.
**[Ressourcen]:**
+ [Daten-Tiering](data-tiering.md)
+ [ ElastiCacheAmazon-Preisgestaltung](https://aws.amazon.com/elasticache/pricing/)
+ **[Erforderlich] **Finden Sie heraus, auf welchen Anteil Ihrer Datenbank in Prozent Ihr Workload regelmäßig zugreift.
1. Daten-Tiering-Instances eignen sich für Workloads, die häufig auf einen kleinen Teil Ihres gesamten Datensatzes zugreifen, aber dennoch einen schnellen Zugriff auf die verbleibenden Daten benötigen. Mit anderen Worten, das Verhältnis von heißen zu warmen Daten beträgt etwa 20:80.
1. Entwickeln Sie eine Nachverfolgung der Leerlaufzeit von Objekten auf Clusterebene.
1. Große Implementierungen mit über 500 GB Daten sind gute Kandidaten.
+ **[Erforderlich] **Machen Sie sich bewusst, dass Daten-Tiering-Instances für bestimmte Workloads nicht optional sind.
1. Der Zugriff auf weniger häufig verwendete Objekte ist mit geringen Leistungseinbußen verbunden, da diese auf eine lokale SSD ausgelagert werden. Wenn Ihre Anwendung empfindlich auf die Reaktionszeit reagiert, testen Sie die Auswirkungen auf Ihren Workload.
1. Nicht geeignet für Caches, die hauptsächlich große Objekte mit einer Größe von über 128 MiB speichern.
**[Ressourcen]:**
+ [Einschränkungen](data-tiering.md#data-tiering-prerequisites)
+ **[Am besten] **Reserved-Instance-Typen unterstützen Daten-Tiering. Dadurch werden die niedrigsten Kosten in Bezug auf die Menge an Datenspeicher pro Instance gewährleistet.
1. Möglicherweise müssen Sie Ihre ElastiCache Cluster mit Instances ohne Datenklassifizierung betreiben, bis Sie Ihre Anforderungen besser verstanden haben.
1. Analysieren Sie das Datennutzungsmuster Ihrer ElastiCache Cluster.
1. Erstellen Sie einen automatisierten Auftrag, der in regelmäßigen Abständen die Leerlaufzeit von Objekten erfasst.
1. Wenn Sie feststellen, dass ein großer Prozentsatz (etwa 80 %) der Objekte für einen Zeitraum inaktiv ist, der für Ihren Workload als angemessen erachtet wird, dokumentieren Sie die Ergebnisse und schlagen Sie vor, den Cluster auf Instances zu migrieren, die Daten-Tiering unterstützen.
1. Evaluieren Sie regelmäßig die neuen verfügbaren Cache-Knotentypen und beurteilen Sie, ob es aus Sicht der Kosten- und Betriebsmetriken sinnvoll ist, Ihre Instance-Flotte auf neue Cache-Knotentypen zu migrieren.
**[Ressourcen]:**
+ [OBJECT IDLETIME](https://valkey.io/commands/object-idletime/)
+ [ ElastiCacheAmazon-Preisgestaltung](https://aws.amazon.com/elasticache/pricing/)
# Allgemeine Schritte zur Fehlerbehebung und bewährte Methoden mit ElastiCache
Die folgenden Themen enthalten Hinweise zur Behebung von Fehlern und Problemen, die bei der Verwendung auftreten können. ElastiCache Wenn Sie auf ein Problem stoßen, das hier nicht aufgeführt ist, können Sie die Schaltfläche „Feedback“ auf dieser Seite verwenden, um es zu melden.
Weitere Tipps zur Fehlerbehebung und Antworten auf häufig gestellte Supportfragen finden Sie im [AWS Knowledge Center](https://aws.amazon.com/premiumsupport/knowledge-center/)
**Topics**
+ [Verbindungsprobleme](#wwe-troubleshooting.connection)
+ [Valkey- oder Redis OSS-Client-Fehler](#wwe-troubleshooting.clienterrors)
+ [Fehlerbehebung bei hoher Latenz in Serverless ElastiCache](#wwe-troubleshooting.latency)
+ [Behebung von Drosselungsproblemen in Serverless ElastiCache](#wwe-troubleshooting.throttling)
+ [Anhaltende Verbindungsprobleme](TroubleshootingConnections.md)
+ [Verwandte Themen](#wwe-troubleshooting.related)
## Verbindungsprobleme
Wenn Sie keine Verbindung zu Ihrem ElastiCache Cache herstellen können, ziehen Sie eine der folgenden Möglichkeiten in Betracht:
1. **Verwenden von TLS:** Wenn beim Versuch, eine Verbindung zu Ihrem ElastiCache Endpunkt herzustellen, eine Verbindung nicht mehr hergestellt wird, verwenden Sie TLS möglicherweise nicht in Ihrem Client. Wenn Sie ElastiCache Serverless verwenden, ist die Verschlüsselung bei der Übertragung immer aktiviert. Stellen Sie sicher, dass Ihr Client TLS verwendet, um eine Verbindung zum Cache herzustellen. [Erfahren Sie mehr über das Herstellen einer Verbindung zu einem TLS-fähigen Cache](connect-tls.md).
1. **VPC: Auf** ElastiCache Caches kann nur innerhalb einer VPC zugegriffen werden. Stellen Sie sicher, dass die EC2 Instance, von der aus Sie auf den Cache zugreifen, und der ElastiCache Cache in derselben VPC erstellt wurden. Alternativ müssen Sie das [VPC-Peering zwischen der VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), in der sich Ihre EC2 Instance befindet, und der VPC, in der Sie Ihren Cache erstellen, aktivieren.
1. **Sicherheitsgruppen:** ElastiCache verwendet Sicherheitsgruppen, um den Zugriff auf Ihren Cache zu kontrollieren. Berücksichtigen Sie dabei Folgendes:
1. Stellen Sie sicher, dass die von Ihrem ElastiCache Cache verwendete Sicherheitsgruppe eingehenden Zugriff von Ihrer EC2 Instance aus darauf zulässt. [Hier](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) erfahren Sie, wie Sie Regeln für eingehenden Datenverkehr in Ihrer Sicherheitsgruppe korrekt einrichten.
1. Stellen Sie sicher, dass die von Ihrem ElastiCache Cache verwendete Sicherheitsgruppe den Zugriff auf die Ports Ihres Caches ermöglicht (6379 und 6380 für serverlose und 6379 standardmäßig für knotenbasierte Cluster). ElastiCache verwendet diese Ports, um Valkey- oder Redis OSS-Befehle zu akzeptieren. [Erfahren Sie hier mehr darüber, wie Sie den Portzugriff einrichten.](set-up.md#elasticache-install-grant-access-VPN)
Wenn die Verbindung weiterhin schwierig ist, finden Sie [Anhaltende Verbindungsprobleme](TroubleshootingConnections.md) weitere Schritte.
## Valkey- oder Redis OSS-Client-Fehler
ElastiCache Auf Serverless kann nur über Clients zugegriffen werden, die das Valkey- oder Redis OSS-Clustermodus-Protokoll unterstützen. Auf knotenbasierte Cluster kann von Clients in beiden Modi zugegriffen werden, abhängig von der Clusterkonfiguration.
Wenn bei Ihrem Client Fehler auftreten, sollten Sie Folgendes beachten:
1. **Clustermodus:** Wenn bei Ihnen CROSSLOT-Fehler oder Fehler mit dem [SELECT-Befehl](https://valkey.io/commands/select/) auftreten, versuchen Sie möglicherweise, mit einem Valkey- oder Redis-OSS-Client, der das Cluster-Protokoll nicht unterstützt, auf einen Cache mit aktiviertem Clustermodus zuzugreifen. ElastiCache Serverless unterstützt nur Clients, die das Valkey- oder Redis OSS-Clusterprotokoll unterstützen. Wenn Sie Valkey oder Redis OSS im Modus „Cluster Mode Disabled“ (CMD) verwenden möchten, müssen Sie einen knotenbasierten Cluster erstellen.
1. **CROSSLOT-Fehler:** Wenn der `ERR CROSSLOT Keys in request don't hash to the same slot` Fehler auftritt, versuchen Sie möglicherweise, auf Schlüssel zuzugreifen, die nicht zu demselben Steckplatz in einem Clustermodus-Cache gehören. Zur Erinnerung: ElastiCache Serverless arbeitet immer im Clustermodus. Operationen mit mehreren Schlüsseln, Transaktionen oder Lua-Skripten mit mehreren Schlüsseln sind nur zulässig, wenn sich alle beteiligten Schlüssel im selben Hash-Slot befinden.
[Weitere bewährte Methoden zur Konfiguration von Valkey- oder Redis OSS-Clients finden Sie in diesem Blogbeitrag.](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/)
## Fehlerbehebung bei hoher Latenz in Serverless ElastiCache
Wenn bei Ihrem Workload eine hohe Latenz auftritt, können Sie anhand der `SuccessfulWriteRequestLatency` Messwerte CloudWatch `SuccessfulReadRequestLatency` und überprüfen, ob die Latenz mit ElastiCache Serverless zusammenhängt. Diese Metriken messen die Latenz, die innerhalb von ElastiCache Serverless liegt. Die clientseitige Latenz und die Netzwerkausfallzeiten zwischen Ihrem Client und dem ElastiCache serverlosen Endpunkt sind nicht enthalten.
**Fehlerbehebung bei der clientseitigen Latenz**
Wenn Sie eine erhöhte Latenz auf der Clientseite, aber keinen entsprechenden Anstieg `` CloudWatch `SuccessfulReadRequestLatency` der `SuccessfulWriteRequestLatency` Messwerte für die serverseitige Latenz feststellen, sollten Sie Folgendes beachten:
+ **Stellen Sie sicher, dass die Sicherheitsgruppe den Zugriff auf die Ports 6379 und 6380 zulässt:** ElastiCache Serverless verwendet den 6379-Port für den primären Endpunkt und den 6380-Port für den Leser-Endpunkt. Einige Clients stellen für jede neue Verbindung eine Verbindung zu beiden Ports her, auch wenn Ihre Anwendung die Funktion „Aus Replikat lesen“ nicht verwendet. Wenn Ihre Sicherheitsgruppe keinen eingehenden Zugriff auf beide Ports zulässt, kann der Verbindungsaufbau länger dauern. Erfahren Sie [hier](set-up.md#elasticache-install-grant-access-VPN) mehr darüber, wie Sie den Portzugriff einrichten.
**Fehlerbehebung bei serverseitiger Latenz**
Einige Schwankungen und gelegentliche Spitzenwerte sollten keinen Anlass zur Sorge geben. Wenn die `Average` Statistik jedoch einen starken Anstieg zeigt und anhält, sollten Sie im Health Dashboard und in Ihrem Personal Health Dashboard nach weiteren Informationen suchen. Falls erforderlich, erwägen Sie, einen Support-Fall mit zu eröffnen.Support
Ziehen Sie die folgenden bewährten Methoden und Strategien zur Reduzierung der Latenz in Betracht:
+ **Read from Replica aktivieren:** Wenn Ihre Anwendung dies zulässt, empfehlen wir, die Funktion „Read from Replica“ in Ihrem Valkey- oder Redis OSS-Client zu aktivieren, um Lesevorgänge zu skalieren und eine geringere Latenz zu erreichen. Wenn diese Option aktiviert ist, versucht ElastiCache Serverless, Ihre Leseanfragen an Replikat-Cache-Knoten weiterzuleiten, die sich in derselben Availability Zone (AZ) wie Ihr Client befinden, wodurch AZ-übergreifende Netzwerklatenzen vermieden werden. Beachten Sie, dass die Aktivierung der Funktion „Aus Replikat lesen“ in Ihrem Client bedeutet, dass Ihre Anwendung eine eventuelle Datenkonsistenz akzeptiert. Ihre Anwendung empfängt möglicherweise für einige Zeit ältere Daten, wenn Sie versuchen, sie zu lesen, nachdem Sie in einen Schlüssel geschrieben haben.
+ **Stellen Sie sicher, dass Ihre Anwendung im selben AZs Cache bereitgestellt wird:** Möglicherweise stellen Sie eine höhere clientseitige Latenz fest, wenn Ihre Anwendung nicht im selben AZs Cache bereitgestellt wird. Wenn Sie einen serverlosen Cache erstellen, können Sie die Subnetze angeben, von denen aus Ihre Anwendung auf den Cache zugreift, und ElastiCache Serverless erstellt VPC-Endpunkte in diesen Subnetzen. Stellen Sie sicher, dass Ihre Anwendung in derselben Umgebung bereitgestellt wird. AZs Andernfalls kann es bei Ihrer Anwendung beim Zugriff auf den Cache zu einem AZ-übergreifenden Hop kommen, was zu einer höheren clientseitigen Latenz führt.
+ **Verbindungen wiederverwenden:** ElastiCache Serverlose Anfragen werden über eine TLS-fähige TCP-Verbindung unter Verwendung des RESP-Protokolls gestellt. Das Initiieren der Verbindung (einschließlich der Authentifizierung der Verbindung, falls konfiguriert) nimmt Zeit in Anspruch, sodass die Latenz der ersten Anfrage höher als üblich ist. Anfragen über eine bereits initialisierte Verbindung sorgen für eine gleichbleibend niedrige ElastiCache Latenz. Aus diesem Grund sollten Sie die Verwendung von Verbindungspooling oder die Wiederverwendung vorhandener Valkey- oder Redis OSS-Verbindungen in Betracht ziehen.
+ **Skalierungsgeschwindigkeit:** ElastiCache Serverless skaliert automatisch, wenn Ihre Anforderungsrate steigt. Ein plötzlicher starker Anstieg der Anforderungsrate, der schneller ist als die Geschwindigkeit, mit der ElastiCache Serverless skaliert, kann für einige Zeit zu einer erhöhten Latenz führen. ElastiCache Serverless kann die unterstützte Anforderungsrate in der Regel schnell erhöhen. Es dauert bis zu 10 bis 12 Minuten, bis sich die Anforderungsrate verdoppelt.
+ **Untersuchen Sie Befehle mit langer Laufzeit:** Einige Valkey- oder Redis-OSS-Befehle, einschließlich Lua-Skripten oder Befehle für große Datenstrukturen, können lange laufen. ElastiCache Veröffentlicht Metriken auf Befehlsebene, um diese Befehle zu identifizieren. Mit [ElastiCache Serverless](serverless-metrics-events-redis.md#serverless-metrics) können Sie die `BasedECPUs` Metriken verwenden.
+ **Gedrosselte Anfragen:** Wenn Anfragen in ElastiCache Serverless gedrosselt werden, kann es zu einem Anstieg der clientseitigen Latenz in Ihrer Anwendung kommen. [Wenn Anfragen in Serverless gedrosselt werden, sollten Sie einen ElastiCache Anstieg der Serverless-Metrik feststellen. `ThrottledRequests` ElastiCache ](serverless-metrics-events-redis.md#serverless-metrics) Im folgenden Abschnitt finden Sie Informationen zur Behebung gedrosselter Anfragen.
+ **Gleichmäßige Verteilung von Schlüsseln und Anfragen:** ElastiCache Bei Valkey und Redis OSS kann eine ungleichmäßige Verteilung von Schlüsseln oder Anfragen pro Steckplatz zu einem Hot-Slot führen, was zu einer erhöhten Latenz führen kann. ElastiCache Serverless unterstützt bis zu 30.000 ECPUs/second (90.000 ECPUs/second bei Verwendung von Read from Replica) an einem einzigen Steckplatz in einer Arbeitslast, die einfache Befehle ausführt. SET/GET Wir empfehlen, Ihre Schlüssel- und Anforderungsverteilung auf die einzelnen Slots zu überprüfen und für eine gleichmäßige Verteilung zu sorgen, falls Ihre Anforderungsrate diese Grenze überschreitet.
## Behebung von Drosselungsproblemen in Serverless ElastiCache
In serviceorientierten Architekturen und verteilten Systemen wird die Begrenzung der Geschwindigkeit, mit der API-Aufrufe durch verschiedene Servicekomponenten verarbeitet werden, als Drosselung bezeichnet. Dadurch werden Leistungsspitzen geglättet, Abweichungen im Komponentendurchsatz vermieden und bei unerwarteten Betriebsereignissen besser vorhersehbare Wiederherstellungen ermöglicht. ElastiCache Serverless wurde für diese Art von Architekturen konzipiert, und die meisten Valkey- oder Redis OSS-Clients verfügen über integrierte Wiederholungsversuche für gedrosselte Anfragen. Ein gewisses Maß an Drosselung ist nicht zwangsläufig ein Problem für Ihre Anwendung. Eine anhaltende Drosselung eines latenzsensitiven Teils des Datenworkflows kann sich jedoch negativ auf die Benutzererfahrung auswirken und die allgemeine Effizienz des Systems beeinträchtigen.
[Wenn Anfragen in Serverless gedrosselt werden, sollten Sie einen Anstieg der ElastiCache Serverless-Metrik feststellen. `ThrottledRequests` ElastiCache ](serverless-metrics-events-redis.md#serverless-metrics) Wenn Sie eine hohe Anzahl gedrosselter Anfragen feststellen, sollten Sie Folgendes beachten:
+ **Skalierungsgeschwindigkeit:** ElastiCache Serverless wird automatisch skaliert, wenn Sie mehr Daten aufnehmen oder Ihre Anforderungsrate erhöhen. Wenn Ihre Anwendung schneller skaliert als die Geschwindigkeit, mit der Serverless skaliert, werden Ihre Anfragen möglicherweise gedrosselt, während ElastiCache Serverless an Ihre Arbeitslast angepasst wird. ElastiCache ElastiCache Serverless kann die Speichergröße in der Regel schnell erhöhen. Es dauert bis zu 10 bis 12 Minuten, bis sich die Speichergröße in Ihrem Cache verdoppelt hat.
+ **Gleichmäßige Verteilung von Schlüsseln und Anfragen:** ElastiCache Bei Valkey und Redis OSS kann eine ungleichmäßige Verteilung von Schlüsseln oder Anfragen pro Steckplatz zu einem Hot-Slot führen. Ein Hot-Slot kann zu einer Drosselung von Anfragen führen, wenn die Anforderungsrate für einen einzelnen Slot 30.000 übersteigt ECPUs/second und es sich um eine Arbeitslast handelt, die einfache Befehle ausführt. SET/GET Ähnlich kann ElastiCache bei Memcached ein Hotkey zu einer Drosselung von Anfragen führen, wenn die Anforderungsrate 30.000 /Sekunde überschreitet. ECPUs
+ **Aus Replikat lesen:** Wenn Ihre Anwendung dies zulässt, sollten Sie in Erwägung ziehen, die Funktion „Aus Replikat lesen“ zu verwenden. Die meisten Valkey- oder Redis-OSS-Clients können so konfiguriert werden, dass sie Lesevorgänge“ skalieren „, sodass Lesevorgänge direkt an Replikatknoten weitergeleitet werden. Mit dieser Funktion können Sie den Lesetraffic skalieren. Darüber hinaus leitet ElastiCache Serverless automatisch Lesevorgänge von Replikatanfragen an Knoten weiter, die sich in derselben Availability Zone wie Ihre Anwendung befinden, was zu einer geringeren Latenz führt. Wenn Read from Replica aktiviert ist, können Sie bei Workloads mit einfachen Befehlen bis zu 90.000 ECPUs/second an einem einzigen Steckplatz erreichen. SET/GET
# Anhaltende Verbindungsprobleme
Bei der Behebung anhaltender Verbindungsprobleme mit müssen die folgenden Punkte überprüft werden ElastiCache:
**Topics**
+ [Sicherheitsgruppen](#Security_groups)
+ [Netzwerk ACLs](#Network_ACLs)
+ [Routing-Tabellen](#Route_tables)
+ [DNS-Auflösung](#DNS_Resolution)
+ [Identifizieren von Problemen mit serverseitiger Diagnose](#Diagnostics)
+ [Netzwerkkonnektivität](#Connectivity)
+ [Netzwerkbezogene Grenzen](#Network-limits)
+ [CPU-Verwendung](#CPU-Usage)
+ [Verbindungen, die von der Serverseite beendet werden](#Connections-server)
+ [Clientseitige Fehlerbehebung für Amazon-Instances EC2](#Connections-client)
+ [Aufschlüsselung der Zeit, die zum Abschließen einer einzelnen Anfrage benötigt wird](#Dissecting-time)
## Sicherheitsgruppen
Sicherheitsgruppen sind virtuelle Firewalls, die Ihren ElastiCache Client (EC2 Instance, AWS Lambda Funktion, Amazon ECS-Container usw.) und Ihren ElastiCache Cache schützen. Sicherheitsgruppen sind statusbehaftet, was bedeutet, dass nach dem Zulassen des eingehenden oder ausgehenden Datenverkehrs die Antworten für diesen Datenverkehr automatisch im Kontext dieser bestimmten Sicherheitsgruppe autorisiert werden.
Die Statusfunktion erfordert, dass die Sicherheitsgruppe alle autorisierten Verbindungen verfolgt, und es gibt ein Limit für verfolgte Verbindungen. Wenn das Limit erreicht ist, schlagen neue Verbindungen fehl. Im Abschnitt zur Fehlerbehebung finden Sie Hilfe dazu, wie Sie feststellen können, ob die Grenzwerte auf dem Client oder auf der ElastiCache Seite erreicht wurden.
Sie können dem Client und dem ElastiCache Cluster eine einzelne Sicherheitsgruppe gleichzeitig oder einzelne Sicherheitsgruppen für jede Gruppe zuweisen.
In beiden Fällen müssen Sie den ausgehenden TCP-Verkehr auf dem ElastiCache Port von der Quelle und den eingehenden Verkehr auf demselben Port zulassen. ElastiCache Der Standardport ist 11211 für Memcached und 6379 für Valkey oder Redis OSS. Standardmäßig gestatten Sicherheitsgruppen allen ausgehenden Datenverkehr. In diesem Fall ist nur die eingehende Regel in der Zielsicherheitsgruppe erforderlich.
Weitere Informationen finden Sie unter [Zugriffsmuster für den Zugriff auf einen ElastiCache Cluster in einer Amazon VPC](elasticache-vpc-accessing.md).
## Netzwerk ACLs
Network Access Control Lists (ACLs) sind statuslose Regeln. Der Datenverkehr muss in beide Richtungen (Eingehend und Ausgehend) zugelassen sein, um erfolgreich zu sein. Netzwerke ACLs werden Subnetzen zugewiesen, nicht bestimmten Ressourcen. Es ist möglich, dass der Client-Ressource dieselbe ACL zugewiesen ElastiCache wird, insbesondere wenn sie sich im selben Subnetz befinden.
Standardmäßig lässt das Netzwerk den gesamten ACLs Datenverkehr zu. Es ist jedoch möglich, sie anzupassen, um Datenverkehr zu verweigern oder zu erlauben. Darüber hinaus erfolgt die Auswertung der ACL-Regeln sequenziell, was bedeutet, dass die Regel mit der niedrigsten Zahl, die dem Datenverkehr entspricht, dies zulässt oder verweigert. Die Mindestkonfiguration, um den Valkey- oder Redis-OSS-Verkehr zuzulassen, ist:
Clientseitige Netzwerk-ACL:
+ **Regeln für eingehenden Datenverkehr:**
+ Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;
+ Type (Typ): Custom TCP Rule (TCP-Regel anpassen);
+ Protokoll: TCP
+ Portbereich: 1024-65535
+ Quelle: 0.0.0.0/0 (oder erstellen Sie individuelle Regeln für die Cluster-Subnetze) ElastiCache
+ Erlauben/Verweigern
+ **Regeln für ausgehenden Datenverkehr:**
+ Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;
+ Type (Typ): Custom TCP Rule (TCP-Regel anpassen);
+ Protokoll: TCP
+ Portbereich: 6379
+ Quelle: 0.0.0.0/0 (oder die Cluster-Subnetze. ElastiCache Beachten Sie, dass die Verwendung bestimmter Optionen im Falle eines Failovers oder der Skalierung des Clusters zu Problemen führen IPs kann.
+ Erlauben/Verweigern
ElastiCache Netzwerk-ACL:
+ **Regeln für eingehenden Datenverkehr:**
+ Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;
+ Type (Typ): Custom TCP Rule (TCP-Regel anpassen);
+ Protokoll: TCP
+ Portbereich: 6379
+ Quelle: 0.0.0.0/0 (oder erstellen Sie individuelle Regeln für die Cluster-Subnetze) ElastiCache
+ Erlauben/Verweigern
+ **Regeln für ausgehenden Datenverkehr:**
+ Regelnummer: vorzugsweise niedriger als jede Ablehnungsregel;
+ Type (Typ): Custom TCP Rule (TCP-Regel anpassen);
+ Protokoll: TCP
+ Portbereich: 1024-65535
+ Quelle: 0.0.0.0/0 (oder die Cluster-Subnetze. ElastiCache Beachten Sie, dass die Verwendung bestimmter Optionen im Falle eines Failovers oder der Skalierung des Clusters zu Problemen führen IPs kann.
+ Erlauben/Verweigern
Weitere Informationen finden Sie unter [Netzwerk ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html).
## Routing-Tabellen
Ähnlich wie beim Netzwerk ACLs kann jedes Subnetz unterschiedliche Routing-Tabellen haben. Wenn sich Clients und der ElastiCache Cluster in unterschiedlichen Subnetzen befinden, stellen Sie sicher, dass ihre Routing-Tabellen es ihnen ermöglichen, einander zu erreichen.
Bei komplexeren Umgebungen mit mehreren VPCs dynamischen Routing- oder Netzwerk-Firewalls kann es schwierig werden, Fehler zu beheben. Siehe [Netzwerkkonnektivität](#Connectivity), um zu bestätigen, dass Ihre Netzwerkeinstellungen angemessen sind.
## DNS-Auflösung
ElastiCache stellt die Dienstendpunkte auf der Grundlage von DNS-Namen bereit. Die verfügbaren Endpunkte sind`Configuration`,`Primary`,`Reader`, und`Node`-Endpunkte. Weitere Informationen finden Sie unter [Verbindungsendpunkte ermitteln](Endpoints.md).
Im Falle eines Failovers oder einer Clusteränderung kann sich die dem Endpunktnamen zugeordnete Adresse ändern und wird automatisch aktualisiert.
Benutzerdefinierte DNS-Einstellungen (d. h. wenn der VPC-DNS-Dienst nicht verwendet wird) kennen die ElastiCache bereitgestellten DNS-Namen möglicherweise nicht. Stellen Sie sicher, dass Ihr System die ElastiCache Endpunkte mithilfe von Systemtools wie `dig` (wie unten gezeigt) oder erfolgreich auflösen kann. `nslookup`
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4
```
Sie können die Namensauflösung auch über den VPC DNS-Dienst erzwingen:
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4
```
## Identifizieren von Problemen mit serverseitiger Diagnose
CloudWatch Metriken und Laufzeitinformationen von der ElastiCache Engine sind gängige Informationsquellen zur Identifizierung potenzieller Ursachen von Verbindungsproblemen. Eine gute Analyse beginnt üblicherweise mit den folgenden Elementen:
+ CPU-Auslastung: Valkey und Redis OSS sind Multithread-Anwendungen. Die Ausführung jedes Befehls erfolgt jedoch in einem einzigen (Haupt-) Thread. Aus diesem Grund ElastiCache bietet es die Metriken und. `CPUUtilization` `EngineCPUUtilization` `EngineCPUUtilization`liefert die CPU-Auslastung, die für den Valkey- oder Redis-OSS-Prozess vorgesehen ist, und `CPUUtilization` die Nutzung für alle V. CPUs Knoten mit mehr als einer vCPU haben normalerweise unterschiedliche Werte für `CPUUtilization` und`EngineCPUUtilization`, wobei der zweite Wert in der Regel höher ist. Hoch`EngineCPUUtilization`kann durch eine erhöhte Anzahl von Anforderungen oder komplexe Vorgänge verursacht werden, die eine erhebliche CPU-Zeit in Anspruch nehmen. Sie können beide folgendermaßen identifizieren:
+ Erhöhte Anzahl von Anforderungen: Prüfen Sie auf Erhöhungen für andere Metriken, die den `EngineCPUUtilization`-Muster. Nützliche Metriken sind:
+ `CacheHits`und`CacheMisses`: Die Anzahl der erfolgreichen Anforderungen oder Anforderungen, die kein gültiges Element im Cache gefunden haben. Wenn das Verhältnis von Fehlern im Vergleich zu Treffern hoch ist, verschwendet die Anwendung Zeit und Ressourcen mit unfruchtbaren Anfragen.
+ `SetTypeCmds` und `GetTypeCmds`: Diese Metriken, die mit `EngineCPUUtilization` korreliert sind, können helfen zu verstehen, ob die Last für Schreibanforderungen signifikant höher ist, gemessen durch `SetTypeCmds`, oder liest, gemessen durch `GetTypeCmds`. Wenn die Last überwiegend Lesevorgänge ist, kann die Verwendung mehrerer Read-Replicas die Anforderungen über mehrere Knoten hinweg ausgleichen und die primäre für Schreibvorgänge ersparen. In Clustern mit deaktiviertem Clustermodus können Read-Replicas verwendet werden, indem in der Anwendung mithilfe des Reader-Endpunkts eine zusätzliche Verbindungskonfiguration erstellt wird. ElastiCache Weitere Informationen finden Sie unter [Verbindungsendpunkte ermitteln](Endpoints.md). Die Lesevorgänge müssen an diese zusätzliche Verbindung gesendet werden. Schreibvorgänge werden über den regulären primären Endpunkt durchgeführt. Im Clustermodus ist es ratsam, eine Bibliothek zu verwenden, die Read Replicas nativ unterstützt. Mit den richtigen Flags kann die Bibliothek automatisch die Cluster-Topologie und die Replikatknoten erkennen, die Lesevorgänge über den Befehl [READONLY Valkey oder Redis OSS aktivieren und die Leseanfragen](https://valkey.io/commands/readonly) an die Replikate senden.
+ Erhöhte Anzahl von Verbindungen:
+ `CurrConnections`und`NewConnections`:`CurrConnection`ist die Anzahl der etablierten Verbindungen zum Zeitpunkt der Datenpunkt-Sammlung, während`NewConnections`zeigt an, wie viele Verbindungen in der Periode erstellt wurden.
Das Erstellen und Behandeln von Verbindungen bedeutet einen erheblichen CPU-Overhead. Darüber hinaus wirkt sich der TCP-3-Wege-Handshake, der zum Erstellen neuer Verbindungen erforderlich ist, negativ auf die Gesamtreaktionszeiten aus.
Ein ElastiCache Knoten mit Tausenden `NewConnections` pro Minute bedeutet, dass eine Verbindung mit nur wenigen Befehlen hergestellt und verwendet wird, was nicht optimal ist. Es ist eine bewährte Vorgehensweise, Verbindungen herzustellen und sie für neue Vorgänge wiederzuverwenden. Dies ist möglich, wenn die Clientanwendung Verbindungspooling oder persistente Verbindungen unterstützt und ordnungsgemäß implementiert. Beim Verbindungspooling wird die Anzahl der`currConnections`hat keine großen Variationen, und die`NewConnections`sollte so niedrig wie möglich sein. Valkey und Redis OSS bieten eine optimale Leistung mit einer geringen Anzahl von CurrConnections. Wenn Sie CurrConnection in der Größenordnung von zehn oder Hunderten halten, wird die Nutzung von Ressourcen minimiert, um einzelne Verbindungen wie Clientpuffer und CPU-Zyklen zu unterstützen, um die Verbindung zu bedienen.
+ Netzwerkdurchsatz:
+ Ermitteln Sie die Bandbreite: Die Netzwerkbandbreite der ElastiCache Knoten ist proportional zur Knotengröße. Da Anwendungen unterschiedliche Merkmale aufweisen, können die Ergebnisse je nach Workload variieren. Beispiele dafür sind Anwendungen mit einer hohen Rate kleiner Anforderungen eher die CPU-Auslastung als der Netzwerkdurchsatz, während größere Schlüssel eine höhere Netzwerkauslastung verursachen. Aus diesem Grund ist es ratsam, die Knoten mit der tatsächlichen Workload zu testen, um die Grenzen besser zu verstehen.
Die Simulation der Last aus der Anwendung würde genauere Ergebnisse liefern. Benchmark-Tools können jedoch eine gute Vorstellung von den Grenzen geben.
+ In Fällen, in denen die Anforderungen überwiegend Lesevorgänge sind, verringert die Verwendung von Replikaten für Lesevorgänge die Belastung des primären Knotens. Wenn der Anwendungsfall überwiegend Schreibvorgänge ist, wird die Verwendung vieler Replikate die Netzwerknutzung verstärken. Für jedes Byte, das auf den primären Knoten geschrieben wird, werden N Bytes an die Replikate gesendet, wobei N die Anzahl der Replikate ist. Die bewährte Methode für schreibintensive Workloads ist die Verwendung von ElastiCache Redis OSS mit aktiviertem Cluster-Modus, sodass die Schreibvorgänge auf mehrere Shards verteilt oder auf einen Knotentyp mit mehr Netzwerkfähigkeiten skaliert werden können.
+ Die CloudWatchmetrics `NetworkBytesIn` und `NetworkBytesOut` geben jeweils die Datenmenge an, die in den Knoten eingeht oder ihn verlässt. `ReplicationBytes`ist der Verkehr, der der Datenreplikation gewidmet ist.
Weitere Informationen finden Sie unter [Netzwerkbezogene Grenzen](#Network-limits).
+ Komplexe Befehle: Redis OSS-Befehle werden in einem einzigen Thread bedient, was bedeutet, dass Anfragen sequentiell bedient werden. Ein einzelner langsamer Befehl kann sich auf andere Anforderungen und Verbindungen auswirken, was zu Timeouts führt. Die Verwendung von Befehlen, die auf mehrere Werte, Schlüssel oder Datentypen wirken, muss sorgfältig durchgeführt werden. Verbindungen können abhängig von der Anzahl der Parameter oder der Größe der Ein- oder Ausgabewerte blockiert oder beendet werden.
Ein berüchtigtes Beispiel ist die`KEYS`-Befehl. Es fegt den gesamten Schlüsselraum auf der Suche nach einem bestimmten Muster und blockiert die Ausführung anderer Befehle während der Ausführung. Redis OSS verwendet die Notation „Big O“, um die Komplexität seiner Befehle zu beschreiben.
Keys Befehl hat O (N) Zeitkomplexität, wobei N die Anzahl der Schlüssel in der Datenbank ist. Je größer die Anzahl der Schlüssel ist, desto langsamer wird der Befehl.`KEYS`kann auf verschiedene Arten Probleme verursachen: Wenn kein Suchmuster verwendet wird, gibt der Befehl alle verfügbaren Schlüsselnamen zurück. In Datenbanken mit tausend oder Millionen von Elementen wird eine riesige Ausgabe erstellt und die Netzwerkpuffer überflutet.
Wenn ein Suchmuster verwendet wird, werden nur die Schlüssel, die dem Muster entsprechen, an den Client zurückgegeben. Die Engine wird jedoch immer noch den gesamten Schlüsselraum durchsucht, und die Zeit, um den Befehl abzuschließen, ist gleich.
Eine Alternative für`KEYS`ist die`SCAN`-Befehl. Es iteriert über den Schlüsselraum und begrenzt die Iterationen in einer bestimmten Anzahl von Elementen, wodurch längere Blöcke auf der Engine vermieden werden.
Der Scan hat die`COUNT`, der zum Festlegen der Größe der Iterationsblöcke verwendet wird. Der Standardwert ist 10 (10 Elemente pro Iteration).
Abhängig von der Anzahl der Elemente in der Datenbank sind kleine`COUNT`-Werte-Blöcke erfordern mehr Iterationen, um einen vollständigen Scan abzuschließen, und größere Werte halten die Engine bei jeder Iteration länger beschäftigt. Während kleine Zählwerte `SCAN` langsamer in großen Datenbanken machen, können größere Werte die gleichen Probleme verursachen, die für `KEYS` beschrieben sind.
Als Beispiel wird das Ausführen des`SCAN`Befehl mit Zählwert als 10 erfordert 100.000 Wiederholungen in einer Datenbank mit 1 Million Schlüsseln. Wenn die durchschnittliche Netzwerk-Roundtrip-Zeit 0,5 Millisekunden beträgt, werden etwa 50.000 Millisekunden (50 Sekunden) für die Übertragung von Anforderungen ausgegeben.
Auf der anderen Seite, wenn der Zählwert 100,0000 wäre, wäre eine einzelne Iteration erforderlich und nur 0,5 ms würden ausgegeben, um sie zu übertragen. Die Engine wäre jedoch für andere Operationen vollständig blockiert, bis der Befehl den gesamten Schlüsselraum beendet hat.
Außerdem`KEYS`, sind einige andere Befehle potenziell schädlich, wenn sie nicht korrekt verwendet werden. Eine Liste aller Befehle und ihrer jeweiligen Zeitkomplexität finden Sie unter [Valkey- und Redis](https://valkey.io/commands) OSS-Befehle.
Beispiele für mögliche Probleme:
+ Lua-Skripte: Valkey und Redis OSS bieten einen eingebetteten Lua-Interpreter, der die Ausführung von Skripten auf der Serverseite ermöglicht. Lua-Skripte auf Valkey und Redis OSS werden auf Engine-Ebene ausgeführt und sind per Definition atomar, was bedeutet, dass kein anderer Befehl oder Skript ausgeführt werden darf, während ein Skript ausgeführt wird. Lua-Skripte bieten die Möglichkeit, mehrere Befehle, Entscheidungsalgorithmen, Datenanalyse und andere Befehle direkt auf der Engine auszuführen. Während die Atomizität von Skripten und die Möglichkeit, die Anwendung zu entladen, verlockend sind, müssen Skripte mit Sorgfalt und für kleine Operationen verwendet werden. Bei ElastiCache aktivierter Option ist die Ausführungszeit von Lua-Skripten auf 5 Sekunden begrenzt. Skripte, die nicht in den Schlüsselraum geschrieben wurden, werden nach Ablauf der 5 Sekunden automatisch beendet. Um Datenbeschädigungen und Inkonsistenzen zu vermeiden, wird der Knoten ein Failover ausgeführt, wenn die Skriptausführung nicht innerhalb von 5 Sekunden abgeschlossen wurde und während der Ausführung Schreibvorgänge stattfand. [Transaktionen](https://valkey.io/topics/transactions) sind die Alternative, um die Konsistenz mehrerer verwandter wichtiger Änderungen in Redis OSS zu gewährleisten. Eine Transaktion ermöglicht die Ausführung eines Blocks von Befehlen und überwacht vorhandene Schlüssel auf Änderungen. Wenn sich einer der überwachten Schlüssel vor Abschluss der Transaktion ändert, werden alle Änderungen verworfen.
+ Massenlöschung von Elementen: Die`DEL`akzeptiert mehrere Parameter, bei denen es sich um die Schlüsselnamen handelt, die gelöscht werden sollen. Löschvorgänge sind synchron und erfordern erhebliche CPU-Zeit, wenn die Liste der Parameter groß ist oder eine große Liste, eine Menge, eine sortierte Menge oder einen Hash enthält (Datenstrukturen, die mehrere Unterelemente enthalten). Mit anderen Worten, selbst das Löschen eines einzelnen Schlüssels kann erhebliche Zeit in Anspruch nehmen, wenn es viele Elemente enthält. Die Alternative zu `DEL` is`UNLINK`, einem asynchronen Befehl, der seit Redis OSS 4 verfügbar ist. `UNLINK`muss, `DEL` wann immer möglich, vorgezogen werden. Ab ElastiCache Redis OSS 6.x verhält sich der `DEL` Befehl aufgrund des `lazyfree-lazy-user-del` Parameters so, `UNLINK` als ob er aktiviert wäre. Weitere Informationen finden Sie unter [Redis OSS 6.0-Parameteränderungen](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
+ Befehle, die auf mehrere Tasten wirken:`DEL`wurde zuvor als Befehl erwähnt, der mehrere Argumente akzeptiert und seine Ausführungszeit wird direkt proportional dazu sein. Redis OSS bietet jedoch viele weitere Befehle, die ähnlich funktionieren. Als Beispiele`MSET`und`MGET`ermöglichen das gleichzeitige Einfügen oder Abrufen mehrerer String-Schlüssel. Ihre Nutzung kann vorteilhaft sein, um die Netzwerklatenz zu reduzieren, die mehreren einzelnen`SET`oder`GET`-Befehle. Eine umfangreiche Liste von Parametern wirkt sich jedoch auf die CPU-Auslastung aus.
Obwohl die CPU-Auslastung allein nicht die Ursache für Konnektivitätsprobleme ist, kann es zu viel Zeit für die Verarbeitung einzelner oder einiger Befehle über mehrere Schlüssel zu einem Ausfall anderer Anforderungen führen und die CPU-Gesamtauslastung erhöhen.
Die Anzahl der Schlüssel und ihre Größe beeinflussen die Komplexität des Befehls und damit die Fertigstellungszeit.
Weitere Beispiele für Befehle, die auf mehrere Tasten wirken können: `HMGET`, `HMSET`, `MSETNX`, `PFCOUNT`, `PFMERGE`, `SDIFF`, `SDIFFSTORE`, `SINTER`, `SINTERSTORE`, `SUNION`, `SUNIONSTORE`, `TOUCH`, `ZDIFF`, `ZDIFFSTORE`, `ZINTER` oder `ZINTERSTORE`.
+ Befehle, die auf mehrere Datentypen einwirken: Redis OSS bietet auch Befehle, die auf einen oder mehrere Schlüssel wirken, unabhängig von ihrem Datentyp. ElastiCache für Redis bietet OSS die Metrik `KeyBasedCmds` zur Überwachung solcher Befehle. Diese Metrik summiert die Ausführung der folgenden Befehle im ausgewählten Zeitraum:
+ Komplexität von O (N):
+ `KEYS`
+ O(1)
+ `EXISTS`
+ `OBJECT`
+ `PTTL`
+ `RANDOMKEY`
+ `TTL`
+ `TYPE`
+ `EXPIRE`
+ `EXPIREAT`
+ `MOVE`
+ `PERSIST`
+ `PEXPIRE`
+ `PEXPIREAT`
+ `UNLINK (O(N)`, um Speicher zurückzugewinnen. Die Speicherwiederherstellungsaufgabe geschieht jedoch in einem getrennten Thread und blockiert die Engine nicht
+ Unterschiedliche Komplexitätszeiten je nach Datentyp:
+ `DEL`
+ `DUMP`
+ `RENAME`wird als Befehl mit O (1) -Komplexität betrachtet, führt aber`DEL`intern. Die Ausführungszeit hängt von der Größe des umbenannten Schlüssels ab.
+ `RENAMENX`
+ `RESTORE`
+ `SORT`
+ Große Hashes: Hash ist ein Datentyp, der einen einzelnen Schlüssel mit mehreren Schlüssel-Wert-Unterelementen erlaubt. Jeder Hash kann 4.294.967.295 Elemente speichern und Operationen auf großen Hashes können teuer werden. Ähnlich wie`KEYS`, haben Hashes die`HKEYS`Befehl mit O (N) Zeitkomplexität, wobei N die Anzahl der Elemente im Hash ist.`HSCAN`hat Vorrang vor`HKEYS`, um lange laufende Befehle zu vermeiden.`HDEL`,`HGETALL`,`HMGET`,`HMSET`und`HVALS`sind Befehle, die bei großen Hashes mit Vorsicht verwendet werden sollten.
+ Andere Big-Data-Strukturen: Neben Hashes können andere Datenstrukturen CPU-intensiv sein. Auch Sets, Listen, Sortierte Sets und Hyperloglogs können abhängig von ihrer Größe und den verwendeten Befehlen viel Zeit in Anspruch nehmen. Weitere Informationen zu diesen Befehlen finden Sie unter [Valkey- und Redis](https://valkey.io/commands) OSS-Befehle.
## Netzwerkkonnektivität
Nach der Überprüfung der Netzwerkkonfigurationen in Bezug auf DNS-Auflösung, Sicherheitsgruppen ACLs, Netzwerk- und Routingtabellen kann die Konnektivität mit dem VPC Reachability Analyzer und den Systemtools überprüft werden.
Reachability Analyzer testet die Netzwerkkonnektivität und bestätigt, ob alle Anforderungen und Berechtigungen erfüllt sind. Für die folgenden Tests benötigen Sie die ENI-ID (Elastic Network Interface Identification) eines der in Ihrer VPC verfügbaren ElastiCache Knoten. Gehen Sie dazu wie folgt vor:
1. Zu [https://console.aws.amazon.com/ec2/v2/home gehen? \$1NIC:](https://console.aws.amazon.com/ec2/v2/home?#NIC)
1. Filtern Sie die Schnittstellenliste nach Ihrem ElastiCache Clusternamen oder der IP-Adresse, die Sie zuvor bei den DNS-Validierungen erhalten haben.
1. Notieren oder auf andere Weise speichern Sie die ENI ID. Wenn mehrere Schnittstellen angezeigt werden, überprüfen Sie die Beschreibung, um sicherzustellen, dass sie zum richtigen ElastiCache Cluster gehören, und wählen Sie eine davon aus.
1. Fahren Sie mit dem nächsten Schritt fort.
1. Zu [https://console.aws.amazon.com/vpc/Hause einen Analysepfad erstellen? ](https://console.aws.amazon.com/vpc/home?#ReachabilityAnalyzer)\$1 ReachabilityAnalyzer und wählen Sie die folgenden Optionen:
+ **Quelltyp**: Wählen Sie die **Instance**, wenn Ihr ElastiCache Client auf einer EC2 Amazon-Instance läuft, oder eine **Netzwerkschnittstelle** (falls er einen anderen Service verwendet, z. B. AWS Fargate Amazon ECS mit awsvpc-Netzwerk usw.) AWS Lambda, und die entsprechende Ressourcen-ID (EC2 Instance- oder ENI-ID);
+ **Typ Ziel**: Wählen Sie aus**Netzwerkschnittstelle**und wählen Sie das Kontrollkästchen**Elasticache ENI**aus der Liste.
+ **Zielport**: Geben Sie 6379 für Redis OSS oder 11211 ElastiCache für Memcached an. ElastiCache Dies sind die Ports, die mit der Standardkonfiguration definiert sind, und in diesem Beispiel wird davon ausgegangen, dass sie nicht geändert werden.
+ **Protocol (Protokoll)**: TCP
Erstellen Sie den Analyse-Pfad und warten Sie ein paar Augenblicke auf das Ergebnis. Wenn der Status nicht erreichbar ist, öffnen Sie die Analysedetails und überprüfen Sie die**Analyse-Explorer**für Details, in denen die Anfragen blockiert wurden.
Wenn die Erreichbarkeitstests bestanden haben, fahren Sie mit der Überprüfung auf Betriebssystemebene fort.
Um die TCP-Konnektivität auf dem ElastiCache Service-Port zu überprüfen: Auf Amazon Linux `Nping` ist es im Paket enthalten `nmap` und kann die TCP-Konnektivität auf dem ElastiCache Port testen sowie die Netzwerk-Round-Trip-Zeit für den Verbindungsaufbau bereitstellen. Verwenden Sie diese Option, um die Netzwerkkonnektivität und die aktuelle Latenz zum ElastiCache Cluster zu überprüfen, wie im Folgenden dargestellt:
```
$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )
Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds
```
In der Standardeinstellung`nping`sendet 5 Sonden mit einer Verzögerung von 1 Sekunde zwischen ihnen. Sie können die Option „-c“ verwenden, um die Anzahl der Prüfpunkte zu erhöhen und „—delay“, um die Zeit für das Senden eines neuen Tests zu ändern.
Wenn die Tests mit`nping`schlägt fehl und die*VPC Reachability Analyzer*-Tests bestanden haben, bitten Sie Ihren Systemadministrator, mögliche hostbasierte Firewall-Regeln, asymmetrische Routingregeln oder andere mögliche Einschränkungen auf Betriebssystemebene zu überprüfen.
Überprüfen Sie auf der ElastiCache Konsole, ob die **Verschlüsselung während der Übertragung** in Ihren ElastiCache Clusterdetails aktiviert ist. Wenn die Verschlüsselung bei der Übertragung aktiviert ist, bestätigen Sie, ob die TLS-Sitzung mit folgendem Befehl eingerichtet werden kann:
```
openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379
```
Eine umfangreiche Ausgabe wird erwartet, wenn die Verbindung und TLS-Verhandlung erfolgreich sind. Überprüfen Sie den in der letzten Zeile verfügbaren Rückgabecode, der Wert muss `0 (ok)` sein. [Wenn openssl etwas anderes zurückgibt, überprüfen Sie den Grund für den Fehler unter https://www.openssl.org/docs/man1.0.2/man1/verify.html \$1DIAGNOSTICS.](https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS)
Wenn alle Infrastruktur- und Betriebssystemtests bestanden wurden, Ihre Anwendung aber immer noch keine Verbindung herstellen kann ElastiCache, überprüfen Sie, ob die Anwendungskonfigurationen den ElastiCache Einstellungen entsprechen. Häufige Fehler sind:
+ Ihre Anwendung unterstützt den ElastiCache Clustermodus nicht und der Clustermodus ElastiCache ist aktiviert;
+ Ihre Anwendung unterstützt TLS/SSL nicht und die Verschlüsselung bei der Übertragung ElastiCache ist aktiviert;
+ Die Anwendung unterstützt TLS/SSL , verfügt aber nicht über die richtigen Konfigurationsflags oder vertrauenswürdigen Zertifizierungsstellen;
## Netzwerkbezogene Grenzen
+ Maximale Anzahl von Verbindungen: Es gibt harte Grenzen für gleichzeitige Verbindungen. Jeder ElastiCache Knoten ermöglicht bis zu 65.000 gleichzeitige Verbindungen zwischen allen Clients. Dieses Limit kann mithilfe der eingeschalteten `CurrConnections` Metriken überwacht werden. CloudWatch Clients haben jedoch auch ihre Grenzen für ausgehende Verbindungen. Überprüfen Sie unter Linux den zulässigen flüchtigen Portbereich mit folgendem Befehl:
```
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
```
Im vorherigen Beispiel sind 28231 Verbindungen von derselben Quelle zu derselben Ziel-IP (ElastiCache Knoten) und demselben Zielport zulässig. Der folgende Befehl zeigt, wie viele Verbindungen für einen bestimmten ElastiCache Knoten (IP 1.2.3.4) bestehen:
```
ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l
```
Wenn die Zahl zu hoch ist, wird Ihr System möglicherweise überlastet und versucht, die Verbindungsanforderungen zu verarbeiten. Es ist ratsam, Techniken wie Verbindungspooling oder persistente Verbindungen zu implementieren, um die Verbindungen besser zu handhaben. Wenn möglich, konfigurieren Sie den Verbindungspool so, dass die maximale Anzahl von Verbindungen auf einige hundert begrenzt wird. Außerdem wäre eine Back-Off-Logik zur Behandlung von Timeouts oder anderen Verbindungsausnahmen ratsam, um im Falle von Problemen eine Verbindungsabwanderung zu vermeiden.
+ Grenzwerte für den Netzwerkverkehr: Überprüfen Sie die folgenden [CloudWatch Metriken für Redis OSS](CacheMetrics.Redis.md), um mögliche Netzwerklimits zu identifizieren, die auf dem Knoten erreicht werden: ElastiCache
+ `NetworkBandwidthInAllowanceExceeded`/`NetworkBandwidthOutAllowanceExceeded`: Netzwerkpakete geformt, weil der Durchsatz das aggregierte Bandbreitenlimit überschritten hat.
Es ist wichtig zu beachten, dass jedes Byte, das auf den primären Knoten geschrieben wird, auf N Replikate repliziert wird, wobei N die Anzahl der Replikate ist. Cluster mit kleinen Knotentypen, mehreren Replikaten und intensiven Schreibanforderungen können den Replikationsrückstand möglicherweise nicht bewältigen. In solchen Fällen ist es eine bewährte Methode, hochzuskalieren (Knoten-Typ ändern), aufzuskalieren (Shards in Cluster mit aktiviertem Cluster-Modus hinzufügen), die Anzahl der Replikate zu reduzieren oder die Anzahl der Schreibvorgänge zu minimieren.
+ `NetworkConntrackAllowanceExceeded`: Pakete geformt, weil die maximale Anzahl von Verbindungen, die über alle dem Knoten zugewiesenen Sicherheitsgruppen nachverfolgt werden, überschritten wurde. Neue Verbindungen werden in diesem Zeitraum wahrscheinlich fehlschlagen.
+ `NetworkPackets PerSecondAllowanceExceeded`: Maximale Anzahl von Paketen pro Sekunde überschritten. Arbeitslasten, die auf einer hohen Rate von sehr kleinen Anforderungen basieren, können diese Grenze vor der maximalen Bandbreite erreichen.
Die oben genannten Metriken sind der ideale Weg, um zu bestätigen, dass Knoten ihre Netzwerklimits erreichen. Grenzwerte können jedoch auch von Plateaus in Netzwerkmetriken identifiziert werden.
Wenn die Plateaus über längere Zeiträume beobachtet werden, folgen sie wahrscheinlich Replikationsverzögerung, Zunahme der Bytes, die für den Cache verwendet werden, Drop auf freien Speicher, hohe Swap und CPU-Auslastung. EC2 Amazon-Instances haben auch Netzwerklimits, die anhand von [ENA-Treibermetriken](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) verfolgt werden können. Linux-Instances mit erweiterter Netzwerkunterstützung und ENA-Treibern 2.2.10 oder höher können die Limitindikatoren mit folgendem Befehl überprüfen:
```
# ethtool -S eth0 | grep "allowance_exceeded"
```
## CPU-Verwendung
Die Metrik zur CPU-Auslastung ist der Ausgangspunkt der Untersuchung, und die folgenden Punkte können helfen, mögliche Probleme ElastiCache nebenbei einzugrenzen:
+ Redis OSS SlowLogs: In der ElastiCache Standardkonfiguration werden die letzten 128 Befehle beibehalten, deren Ausführung mehr als 10 Millisekunden gedauert hat. Der Verlauf der langsamen Befehle wird während der Motorlaufzeit beibehalten und geht im Falle eines Fehlers oder eines Neustarts verloren. Wenn die Liste 128 Einträge erreicht, werden alte Ereignisse entfernt, um Raum für neue zu öffnen. Die Größe der Liste der langsamen Ereignisse und die Ausführungszeit, die als langsam betrachtet wird, kann durch die Parameter `slowlog-max-len` und `slowlog-log-slower-than`in einer [Benutzerdefinierte Parametergruppe](ParameterGroups.md) angepasst werden. Die slowlogs-Liste kann abgerufen werden, indem`SLOWLOG GET 128`auf dem Motor, 128 sind die letzten 128 langsamen Befehle gemeldet. Jeder Spielereintrag hat folgende Felder:
```
1) 1) (integer) 1 -----------> Sequential ID
2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
3) (integer) 4823378 -----> Time in microseconds to complete the command.
4) 1) "keys" -------------> Command
2) "*" ----------------> Arguments
5) "1.2.3.4:57004"-> Source
```
Das obige Ereignis geschah am 26. Dezember um 19:26:07 UTC, dauerte 4,8 Sekunden (4,823 ms) und wurde durch die`KEYS`Befehl vom Client 1.2.3.4 angefordert.
Unter Linux kann der Zeitstempel mit dem Befehlsdatum konvertiert werden:
```
$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020
```
Mit Python:
```
>>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)
```
Oder unter Windows mit: PowerShell
```
PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime : 12/26/2020 7:26:07 PM
UtcDateTime
: 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date : 12/26/2020 12:00:00 AM
Day : 26
DayOfWeek
: Saturday
DayOfYear : 361
Hour : 19
Millisecond : 0
Minute : 26
Month
: 12
Offset : 00:00:00Ticks : 637446075670000000
UtcTicks
: 637446075670000000
TimeOfDay : 19:26:07
Year : 2020
```
Viele langsame Befehle in kurzer Zeit (gleiche Minute oder weniger) sind ein Grund zur Besorgnis. Überprüfen Sie die Art der Befehle und wie sie optimiert werden können (siehe vorangegangene Beispiele). Wenn Befehle mit O (1) -Zeitkomplexität häufig gemeldet werden, überprüfen Sie die anderen Faktoren für eine hohe CPU-Auslastung, die zuvor erwähnt wurden.
+ Latenzmetriken: ElastiCache Für Redis bietet OSS CloudWatch Metriken zur Überwachung der durchschnittlichen Latenz für verschiedene Befehlsklassen. Der Datenpunkt wird berechnet, indem die Gesamtzahl der Ausführungen von Befehlen in der Kategorie durch die gesamte Ausführungszeit in der Periode dividiert wird. Es ist wichtig zu verstehen, dass Latenzmetrikergebnisse ein Aggregat mehrerer Befehle sind. Ein einzelner Befehl kann unerwartete Ergebnisse wie Timeouts verursachen, ohne signifikante Auswirkungen auf die Metriken zu haben. In solchen Fällen wären die Slowlog-Ereignisse eine genauere Informationsquelle. Die folgende Liste enthält die verfügbaren Latenzmetriken und die entsprechenden Befehle, die sie betreffen.
+ EvalBasedCmdsLatency: bezieht sich auf Lua-Script-Befehle,,; `eval` `evalsha`
+ GeoSpatialBasedCmdsLatency: `geodist`, `geohash`, `geopos`, `georadius`, `georadiusbymember`, `geoadd`;
+ GetTypeCmdsLatency: Befehle lesen, unabhängig vom Datentyp;
+ HashBasedCmdsLatency: `hexists`, `hget`, `hgetall`, `hkeys`, `hlen`, `hmget`, `hvals`, `hstrlen`, `hdel`, `hincrby`, `hincrbyfloat`, `hmset`, `hset`, `hsetnx`;
+ HyperLogLogBasedCmdsLatency: `pfselftest`, `pfcount`, `pfdebug`, `pfadd`, `pfmerge`;
+ KeyBasedCmdsLatency: Befehle, die auf verschiedene Datentypen einwirken können:`dump`,,`exists`,`keys`,`object`,`pttl`,,`randomkey`,`ttl`,`type`,`del`,`expire`,`expireat`,,`move`,`persist`,`pexpire`,`pexpireat`,`rename`,`renamenx`,,`restoreK`,`sort`,`unlink`;
+ ListBasedCmdsLatency: lindex, len, lrange, blpop, brpop, brpoplpush, linsert, lpop, push, pushx, lrem, let, ltrim, rpop, rpoplpush, rpush, rpushx;
+ PubSubBasedCmdsLatency: abonnieren, veröffentlichen, pubsub, abbestellen, abonnieren, abbestellen;
+ SetBasedCmdsLatency: `scard`, `sdiff`, `sinter`, `sismember`, `smembers`, `srandmember`, `sunion`, `sadd`, `sdiffstore`, `sinterstore`, `smove`, `spop`, `srem`, `sunionstore`;
+ SetTypeCmdsLatency: Befehle schreiben, unabhängig vom Datentyp;
+ SortedSetBasedCmdsLatency: `zcard`, `zcount`, `zrange`, `zrangebyscore`, `zrank`, `zrevrange`, `zrevrangebyscore`, `zrevrank`, `zscore`, `zrangebylex`, `zrevrangebylex`, `zlexcount`, `zadd`. `zincrby`, `zinterstore`, `zrem`, `zremrangebyrank`, `zremrangebyscore`, `zunionstore`, `zremrangebylex`, `zpopmax`, `zpopmin`, `bzpopmin`, `bzpopmax`;
+ StringBasedCmdsLatency: `bitcount`, `get`, `getbit`, `getrange`, `mget`, `strlen`, `substr`, `bitpos`, `append`, `bitop`, `bitfield`, `decr`, `decrby`, `getset`, `incr`, `incrby`, `incrbyfloat`, `mset`, `msetnx`, `psetex`, `set`, `setbit`, `setex`, `setnx`, `setrange`;
+ StreamBasedCmdsLatency: `xrange`, `xrevrange`, `xlen`, `xread`, `xpending`, `xinfo`, `xadd`, `xgroup`, `readgroup`, `xack`, `xclaim`, `xdel`, `xtrim`, `xsetid`;
+ Redis OSS-Laufzeitbefehle:
+ info commandstats: Stellt eine Liste der Befehle bereit, die seit dem Start der Engine ausgeführt wurden, ihre kumulative Anzahl der Ausführungen, die Gesamtausführungszeit und die durchschnittliche Ausführungszeit pro Befehl;
+ Client-Liste: Bietet eine Liste der aktuell verbundenen Clients und relevante Informationen wie Pufferverwendung, zuletzt ausgeführter Befehl usw.;
+ Backup und Replikation: Verwenden Sie ElastiCache für Redis OSS-Versionen vor 2.8.22 einen Fork-Prozess, um Backups zu erstellen und vollständige Synchronisationen mit den Replikaten durchzuführen. Diese Methode kann in erheblichem Speicheraufwand für schreibintensive Anwendungsfälle auftreten.
Beginnend mit ElastiCache Redis OSS 2.8.22 wurde eine Sicherungs- und Replikationsmethode ohne Forkless eingeführt. AWS Die neue Methode kann Schreibvorgänge verzögern, um Fehler zu vermeiden. Beide Methoden können Perioden höherer CPU-Auslastung verursachen, zu höheren Reaktionszeiten führen und somit zu Client-Timeouts während ihrer Ausführung führen. Überprüfen Sie immer, ob die Client-Fehler während des Backup-Fensters oder der`SaveInProgress`-Metrik war 1 in der Periode. Es ist ratsam, das Backup-Fenster für Zeiten geringer Auslastung zu planen, um die Möglichkeit von Problemen mit Clients oder Backup-Fehlern zu minimieren.
## Verbindungen, die von der Serverseite beendet werden
Die Standardeinstellung ElastiCache für die Redis OSS-Konfiguration sorgt dafür, dass die Client-Verbindungen auf unbestimmte Zeit hergestellt werden. In einigen Fällen kann eine Verbindungsbeendigung jedoch wünschenswert sein. Zum Beispiel:
+ Fehler in der Client-Anwendung können dazu führen, dass Verbindungen vergessen und im Leerlauf gehalten werden. Dies wird als „Verbindungsleck „bezeichnet und die Folge ist eine stetige Zunahme der Anzahl etablierter Verbindungen, die auf der `CurrConnections`-Metrik beobachtet werden. Dieses Verhalten kann zu einer Überlastung des Clients oder ElastiCache der Seite führen. Wenn eine sofortige Korrektur von der Client-Seite aus nicht möglich ist, legen einige Administratoren in ihrer ElastiCache Parametergruppe einen Wert für das“ Timeout „fest. Das Timeout ist die Zeit in Sekunden, die erlaubt ist, dass Verbindungen im Leerlauf bestehen bleiben. Wenn der Client innerhalb dieses Zeitraums keine Anfrage einreicht, beendet die Engine die Verbindung, sobald die Verbindung den Timeout-Wert erreicht. Kleine Zeitüberschreitungswerte können zu unnötigen Trennungen führen, und Clients müssen sie ordnungsgemäß behandeln und eine erneute Verbindung herstellen, was zu Verzögerungen führt.
+ Der Speicher, der zum Speichern von Schlüsseln verwendet wird, wird für Clientpuffer freigegeben. Langsame Clients mit großen Anfragen oder Antworten benötigen möglicherweise eine beträchtliche Menge an Speicher, um ihre Puffer zu verarbeiten. Die Standardeinstellung ElastiCache für Redis OSS-Konfigurationen schränkt die Größe der regulären Client-Ausgabepuffer nicht ein. Wenn das Symbol`maxmemory`-Limit erreicht wird, versucht die Engine, Elemente zu vertreiben, um die Pufferverwendung zu erfüllen. Bei extrem wenig Arbeitsspeicher kann sich OSS ElastiCache für Redis dazu entscheiden, die Verbindung von Clients zu trennen, die große Client-Ausgabepuffer verbrauchen, um Speicherplatz freizugeben und den Zustand des Clusters zu erhalten.
Es ist möglich, die Größe von Clientpuffern mit benutzerdefinierten Konfigurationen zu begrenzen, und Clients, die das Limit erreichen, werden getrennt. Clients sollten jedoch in der Lage sein, unerwartete Trennungen zu verarbeiten. Die Parameter für die Puffergröße für reguläre Clients sind die folgenden:
+ client-query-buffer-limit: Maximale Größe einer einzelnen Eingabeanforderung;
+ client-output-buffer-limit-normal-soft-limit: Soft-Limit für Client-Verbindungen. Die Verbindung wird beendet, wenn sie länger als die für client-output-buffer-limit - definierte Zeit in Sekunden über dem Soft-Limit bleibt normal-soft-seconds oder wenn sie das Hard-Limit erreicht;
+ client-output-buffer-limit-normal-soft-seconds: Zulässige Zeit für Verbindungen, die den Wert von client-output-buffer-limit - überschreitennormal-soft-limit;
+ client-output-buffer-limit-normal-hard-limit: Eine Verbindung, die dieses Limit erreicht, wird sofort beendet.
Neben den regulären Client-Puffern steuern die folgenden Optionen den Puffer für Replikatknoten und Clients Pub/Sub (Publish/Subscribe):
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-replica-soft-seconds;
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-pubsub-soft-limit;
+ client-output-buffer-limit-pubsub-soft-seconds;
+ client-output-buffer-limit-pubsub-hard-limit;
## Clientseitige Fehlerbehebung für Amazon-Instances EC2
Die Auslastung und Reaktionsfähigkeit auf der Client-Seite können sich auch auf die Anfragen an auswirken. ElastiCache EC2 Bei der Behebung von zeitweiligen Verbindungs- oder Timeout-Problemen müssen die Beschränkungen für Instanzen und Betriebssysteme sorgfältig geprüft werden. Einige wichtige Punkte zu beachten:
+ CPU:
+ EC2 CPU-Auslastung der Instanz: Stellen Sie sicher, dass die CPU nicht ausgelastet ist oder fast zu 100 Prozent ausgelastet ist. Die historische Analyse kann wie folgt durchgeführt werden. Beachten Sie jedoch CloudWatch, dass die Granularität der Datenpunkte entweder 1 Minute (bei aktivierter detaillierter Überwachung) oder 5 Minuten beträgt;
+ Wenn Sie [ EC2 Burstable-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html) verwenden, stellen Sie sicher, dass ihr CPU-Guthaben nicht aufgebraucht ist. Diese Informationen sind in der Metrik verfügbar. `CPUCreditBalance` CloudWatch
+ Kurze Perioden mit hoher CPU-Auslastung können zu Timeouts führen, ohne dass eine 100-prozentige Auslastung berücksichtigt wird. CloudWatch Solche Fälle erfordern eine Echtzeitüberwachung mit Betriebssystem-Tools wie `top`,`ps` und `mpstat`.
+ Netzwerk
+ Überprüfen Sie, ob der Netzwerkdurchsatz gemäß den Instance-Funktionen unter akzeptablen Werten liegt. Weitere Informationen finden Sie unter [ EC2 Amazon-Instance-Typen](https://aws.amazon.com/ec2/instance-types/)
+ Bei Instances mit Erweiterten `ena`-Netzwerktreiber, überprüfen Sie die [EN-Statistiken](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-ena.html#statistics-ena) für Timeouts oder überschritten Limits. Die folgenden Statistiken sind nützlich, um die Sättigung der Netzwerklimits zu bestätigen:
+ `bw_in_allowance_exceeded`/`bw_out_allowance_exceeded`: Anzahl der Pakete, die durch übermäßigen eingehenden oder ausgehenden Durchsatz geformt werden;
+ `conntrack_allowance_exceeded`: Anzahl der Pakete, die aufgrund von Sicherheitsgruppen [Verbindungsverfolgung von Grenzen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#connection-tracking-throttling) gelöscht wurden. Neue Verbindungen werden fehlschlagen, wenn diese Grenze gesättigt ist;
+ `linklocal_allowance_exceeded`: Anzahl der Pakete, die aufgrund übermäßiger Anfragen an Instance-Meta-Daten gelöscht wurden, NTP über VPC DNS. Das Limit beträgt 1024 Pakete pro Sekunde für alle Dienste;
+ `pps_allowance_exceeded`: Anzahl der Pakete, die aufgrund übermäßiger Pakete pro Sekunde verworfen wurden. Das PPS-Limit kann erreicht werden, wenn der Netzwerkverkehr aus Tausenden oder Millionen sehr kleiner Anfragen pro Sekunde besteht. ElastiCache Der Datenverkehr kann optimiert werden, um Netzwerkpakete über Pipelines oder Befehle, die beispielsweise `MGET` mehrere Operationen gleichzeitig ausführen, besser zu nutzen. `GET`
## Aufschlüsselung der Zeit, die zum Abschließen einer einzelnen Anfrage benötigt wird
+ Im Netzwerk sind: `Tcpdump` und `Wireshark` (tshark auf der Befehlszeile) praktische Tools, um zu verstehen, wie viel Zeit die Anfrage benötigt hat, um das Netzwerk zu erreichen, die ElastiCache Engine zu starten und eine Antwort zu erhalten. Im folgenden Beispiel wird eine einzelne Anforderung hervorgehoben, die mit dem folgenden Befehl erstellt wurde:
```
$ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG
```
Parallel zum obigen Befehl wurde tcpdump ausgeführt und zurückgegeben:
```
$ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
> 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
```
Aus der obigen Ausgabe können wir bestätigen, dass der TCP-3-Wege-Handshake in 222 Mikrosekunden (918091 - 917869) abgeschlossen wurde und der Ping-Befehl in 173 Mikrosekunden (918295 - 918122) zurückgegeben wurde.
Es dauerte 438 Mikrosekunden (918307 - 917869) vom Anfordern bis zum Schließen der Verbindung. Diese Ergebnisse würden bestätigen, dass Netz- und Triebwerksreaktionszeiten gut sind und sich die Untersuchung auf andere Komponenten konzentrieren kann.
+ Auf dem Betriebssystem:`Strace`kann helfen, Zeitlücken auf Betriebssystemebene zu identifizieren. Die Analyse der tatsächlichen Anwendungen wäre viel umfangreicher und spezialisierte Anwendungsprofiler oder Debugger sind ratsam. Das folgende Beispiel zeigt nur, ob die Basisbetriebssystemkomponenten wie erwartet funktionieren, andernfalls können weitere Untersuchungen erforderlich sein. Wenn wir denselben Redis `PING` OSS-Befehl verwenden, erhalten `strace` wir:
```
$ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
(+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
(+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
(+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
(Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
(+ 0.003569) +++ exited with 0 +++
```
Im obigen Beispiel dauerte der Befehl etwas mehr als 54 Millisekunden (752110 - 697712 = 54398 Mikrosekunden).
Eine beträchtliche Zeit, etwa 20 ms, wurde benötigt, um nc zu instanziieren und die Namensauflösung durchzuführen (von 697712 bis 717890), danach waren 2 ms erforderlich, um den TCP-Socket zu erstellen (745659 bis 747858) und 0,4 ms (747858 bis 748330), um die Antwort für die Anfrage zu senden und zu erhalten.
## Verwandte Themen
+ [ElastiCache Best Practices und Caching-Strategien](BestPractices.md)