Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Lavorare con ElastiCache
In questa sezione puoi trovare dettagli su come gestire i vari componenti dell' ElastiCache implementazione.
**Topics**
+ [Snapshot e ripristino](backups.md)
+ [Versioni del motore e aggiornamento in ElastiCache](engine-versions.md)
+ [ElastiCache migliori pratiche e strategie di caching](BestPractices.md)
+ [Gestione del cluster basato su nodi in ElastiCache](manage-self-designed-cluster.md)
+ [Connessione automatica di un' EC2 istanza e di una ElastiCache cache](compute-connection.md)
+ [Ridimensionamento ElastiCache](Scaling.md)
+ [Guida introduttiva ai filtri Bloom](BloomFilters.md)
+ [Guida introduttiva a Watch in Serverless](ServerlessWatch.md)
+ [Guida introduttiva alla ricerca vettoriale](vector-search.md)
+ [Guida introduttiva a JSON per Valkey e Redis OSS](json-gs.md)
+ [Taggare le tue risorse ElastiCache](Tagging-Resources.md)
+ [Utilizzo dell'obiettivo Amazon ElastiCache Well-Architected](WellArchitechtedLens.md)
+ [Procedure di risoluzione dei problemi e procedure consigliate comuni con ElastiCache](wwe-troubleshooting.md)
# Snapshot e ripristino
ElastiCache Le cache Amazon che eseguono Valkey, Redis OSS o Serverless Memcached possono eseguire il backup dei dati creando uno snapshot. Il backup può essere utilizzato per ripristinare una cache o inizializzare i dati in una nuova cache. Il backup è costituito dai metadati della cache, insieme a tutti i dati presenti nella cache. Tutti i backup vengono scritti su Amazon Simple Storage Service (Amazon S3), che fornisce uno storage durevole. In qualsiasi momento, puoi ripristinare i dati creando una nuova cache Valkey, Redis OSS o Serverless Memcached e popolandola con i dati di un backup. Con ElastiCache, puoi gestire i backup utilizzando, the () e Console di gestione AWS l'AWS Command Line Interface API.AWS CLI ElastiCache
Se pianifichi di eliminare una cache ed è importante preservare i dati, puoi prendere precauzioni aggiuntive. Per farlo, crea innanzitutto un backup manuale, verifica che lo stato sia *disponibile*, quindi elimina la cache. In questo modo hai la garanzia che, in caso di errore del backup, disporrai comunque dei dati della cache. Puoi provare nuovamente a creare un backup, seguendo le best practice illustrate in precedenza.
**Topics**
+ [Vincoli del backup](#backups-constraints)
+ [Impatto sulle prestazioni dei backup di cluster basati su nodi](#backups-performance)
+ [Pianificazione di backup automatici](backups-automatic.md)
+ [Esecuzione di backup manuali](backups-manual.md)
+ [Creazione di un backup finale](backups-final.md)
+ [Descrizione dei backup](backups-describing.md)
+ [Copia di backup](backups-copying.md)
+ [Esportazione di un backup](backups-exporting.md)
+ [Ripristino da un backup in una nuova cache](backups-restoring.md)
+ [Eliminazione di un backup](backups-deleting.md)
+ [Assegnazione di tag di backup](backups-tagging.md)
+ [Tutorial: Seminare un nuovo cluster basato su nodi con un backup creato esternamente](backups-seeding-redis.md)
## Vincoli del backup
Durante la pianificazione o la creazione di backup occorre considerare i seguenti vincoli:
+ Il backup e il ripristino sono supportati solo per le cache in esecuzione su Valkey, Redis OSS o Serverless Memcached.
+ Per i cluster Valkey o Redis OSS (modalità cluster disabilitata), il backup e il ripristino non sono supportati sui nodi. `cache.t1.micro` Tutti gli altri tipi di nodi di cache sono supportati.
+ Per i cluster Valkey o Redis OSS (modalità cluster abilitata), il backup e il ripristino sono supportati per tutti i tipi di nodi.
+ Durante un periodo contiguo di 24 ore, è possibile creare non più di 24 backup manuali per cache serverless. Per i cluster basati su nodi Valkey e Redis OSS, è possibile creare non più di 20 backup manuali per nodo del cluster.
+ Valkey o Redis OSS (modalità cluster abilitata) supporta solo l'esecuzione di backup a livello di cluster (per l'API o la CLI, a livello di gruppo di replica). Valkey o Redis OSS (modalità cluster abilitata) non supportano l'esecuzione di backup a livello di shard (per l'API o la CLI, a livello di gruppo di nodi).
+ Durante il processo di backup, non puoi eseguire altre operazioni API o CLI sulla cache serverless. È possibile eseguire operazioni API o CLI su un cluster basato su nodi durante il backup.
+ Se utilizzi cache Valkey o Redis OSS con tiering dei dati, non puoi esportare un backup su Amazon S3.
+ È possibile ripristinare un backup di un cluster utilizzando il tipo di nodo r6gd solo su cluster che utilizzano il tipo di nodo r6gd.
## Impatto sulle prestazioni dei backup di cluster basati su nodi
I backup sulle cache serverless sono trasparenti per l'applicazione senza alcun impatto sulle prestazioni. Tuttavia, quando si creano backup per cluster basati su nodi, può esserci un certo impatto sulle prestazioni a seconda della memoria riservata disponibile. I backup per i cluster basati su nodi non sono disponibili con Memcached ma sono disponibili con Redis ElastiCache OSS. ElastiCache
Di seguito sono riportate le linee guida per migliorare le prestazioni di backup per i cluster basati su nodi.
+ Imposta il `reserved-memory-percent` parametro: per ridurre il paging eccessivo, si consiglia di impostare il parametro. *reserved-memory-percent* Questo parametro impedisce a Valkey e Redis OSS di consumare tutta la memoria disponibile del nodo e può aiutare a ridurre la quantità di paging. È anche possibile che si verifichino miglioramenti delle prestazioni utilizzando semplicemente un nodo più grande. Per ulteriori informazioni sulla *memoria riservata e sui parametri, vedere*. *reserved-memory-percent*[Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md)
+ Creare backup da una replica di lettura: se si esegue Valkey o Redis OSS in un gruppo di nodi con più di un nodo, è possibile eseguire un backup dal nodo primario o da una delle repliche di lettura. A causa delle risorse di sistema richieste durante BGSAVE, ti consigliamo di creare backup da una delle repliche di lettura. Nel corso della creazione del backup dalla replica, il nodo primario non viene alterato dai requisiti della risorsa BGSAVE. Il nodo primario può continuare a servire le richieste senza rallentamenti.
A tale scopo, consulta [Creazione di un backup manuale (Console)](backups-manual.md#backups-manual-CON)e nel **Nome del cluster** nella finestra **Crea backup**, scegliere una replica anziché il nodo primario di default.
Se elimini un gruppo di replica e richiedi un backup finale, esegue ElastiCache sempre il backup dal nodo primario. Ciò garantisce l'acquisizione dei dati Valkey o Redis OSS più recenti, prima che il gruppo di replica venga eliminato.
# Pianificazione di backup automatici
È possibile abilitare i backup automatici per qualsiasi cache serverless Valkey o Redis OSS o cluster basato su nodi. Quando i backup automatici sono abilitati, ElastiCache crea un backup della cache su base giornaliera. Non vi è alcun impatto sulla cache e la modifica è immediata. I backup automatici possono fornire protezione da perdita di dati. In caso di errore, puoi creare una nuova cache ripristinando i dati dal backup più recente. Il risultato è una cache avviata a caldo, precaricata con i dati e pronta per l'uso. Per ulteriori informazioni, consulta [Ripristino da un backup in una nuova cache](backups-restoring.md).
È possibile abilitare i backup automatici per qualsiasi cache Memcached Serverless. Quando i backup automatici sono abilitati, ElastiCache crea un backup della cache su base giornaliera. Non vi è alcun impatto sulla cache e la modifica è immediata. I backup automatici possono fornire protezione da perdita di dati. In caso di errore, puoi creare una nuova cache ripristinando i dati dal backup più recente. Il risultato è una cache avviata a caldo, precaricata con i dati e pronta per l'uso. Per ulteriori informazioni, consulta [Ripristino da un backup in una nuova cache](backups-restoring.md).
Quando pianifichi backup automatici, considera le seguenti impostazioni:
+ **Ora di inizio del backup**: un'ora del giorno in cui ElastiCache inizia la creazione di un backup. Puoi impostare la finestra di backup in qualsiasi momento e quando è più comodo. Se non si specifica una finestra di backup, ne ElastiCache assegna una automaticamente.
+ **Periodo di retention di backup** : Il numero di giorni in cui il backup viene mantenuto in Amazon S3. Ad esempio, se imposti il limite del periodo di retention su 5, un backup acquisito oggi verrà mantenuto per 5 giorni. Quando il periodo di retention scade, il backup viene automaticamente eliminato.
Il periodo di retention di backup massimo è 35 giorni. Se il periodo di conservazione dei backup è impostato su 0, i backup automatici sono disabilitati per la cache.
Quando pianifichi i backup automatici, ElastiCache inizierà a creare il backup. Puoi impostare la finestra di backup in qualsiasi momento e quando è più comodo. Se non si specifica una finestra di backup, ne ElastiCache assegna una automaticamente.
È possibile abilitare o disabilitare i backup automatici quando si crea una nuova cache o si aggiorna una cache esistente, utilizzando la ElastiCache console AWS CLI, l'o l' ElastiCache API. **Per Valkey e Redis OSS, questa operazione viene eseguita selezionando la casella **Abilita backup automatici** nella sezione Impostazioni **avanzate Valkey o Impostazioni avanzate** Redis OSS.** **Per Memcached, questa operazione viene eseguita selezionando la casella **Abilita backup automatici nella sezione Impostazioni avanzate** Memcached.**
# Esecuzione di backup manuali
Oltre ai backup automatici, puoi creare un backup *manuale* in qualsiasi momento. A differenza dei backup automatici, che vengono eliminati automaticamente dopo un periodo di retention specificato, i backup manuali non dispongono di un periodo di retention dopo il quale vengono eliminati automaticamente. Anche se elimini la cache, tutti i backup manuali della cache vengono mantenuti. Se non desideri più mantenere un backup manuale, devi eliminarlo in maniera esplicita.
Oltre che direttamente, puoi creare un backup manuale in uno dei modi seguenti:
+ [Copia di backup](backups-copying.md). Non importa se il backup di origine è stato creato automaticamente o manualmente.
+ [Creazione di un backup finale](backups-final.md). Crea immediatamente un backup prima di eliminare un cluster o un nodo.
È possibile creare un backup manuale di una cache utilizzando l'Console di gestione AWSAWS CLI, la o l' ElastiCache API.
È possibile generare backup manuali da repliche abilitate in modalità cluster e disattivate in modalità cluster.
## Creazione di un backup manuale (Console)
**Per creare un backup di una cache (console)**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Dal pannello di navigazione, scegli le cache **Valkey, le cache** **Redis OSS o le cache **Memcached****, a seconda delle tue preferenze.
1. Scegli la casella a sinistra del nome della cache di cui desideri eseguire il backup.
1. Scegli **Backup**.
1. Nella finestra di dialogo **Crea backup**, digita un nome per il backup nella casella **Nome backup**. Il nome deve indicare quale cluster è stato sottoposto a backup e la data e l'ora di esecuzione del backup.
I vincoli di denominazione del cluster sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non posso terminare con un trattino.
1. Scegli **Crea backup**.
Lo stato de cluster cambia in *creazione di snapshot*.
## Creazione di un backup manuale (AWS CLI)
**Backup manuale di una cache serverless con AWS CLI**
Per creare un backup manuale di una cache utilizzando il AWS CLI, utilizzare l'`create-serverless-snapshot`AWS CLI operazione con i seguenti parametri:
+ `--serverless-cache-name`: il nome della cache serverless di cui esegui il backup.
+ `--serverless-cache-snapshot-name` - Nome dello snapshot da creare.
Per Linux, macOS o Unix:
+
```
aws elasticache create-serverless-snapshot \
--serverless-cache-name CacheName \
--serverless-cache-snapshot-name bkup-20231127
```
Per Windows:
+
```
aws elasticache create-serverless-snapshot ^
--serverless-cache-name CacheName ^
--serverless-cache-snapshot-name bkup-20231127
```
**Backup manuale di un cluster basato su nodi con AWS CLI**
Per creare un backup manuale di un cluster basato su nodi utilizzando il AWS CLI, utilizza l'`create-snapshot`AWS CLI operazione con i seguenti parametri:
+ `--cache-cluster-id`
+ Se il cluster di cui stai eseguendo il backup non ha nodi di replica, `--cache-cluster-id` è il nome del cluster di cui stai eseguendo il backup, ad esempio. *mycluster*
+ Se il cluster di cui stai eseguendo il backup dispone di uno o più nodi di replica, `--cache-cluster-id` è il nome del nodo nel cluster che desideri utilizzare per il backup. Ad esempio, il nome potrebbe essere. *mycluster-002*
Utilizzate questo parametro solo per il backup di un cluster Valkey o Redis OSS (modalità cluster disabilitata).
+ `--replication-group-id`— Nome del cluster Valkey o Redis OSS (modalità cluster abilitata) (CLI/API: un gruppo di replica) da utilizzare come origine per il backup. Utilizzate questo parametro per il backup di un cluster Valkey o Redis OSS (modalità cluster abilitata).
+ `--snapshot-name` - Nome dello snapshot da creare.
I vincoli di denominazione del cluster sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
### Esempio 1: backup di un cluster Valkey o Redis OSS (Cluster Mode Disabled) senza nodi di replica
La seguente AWS CLI operazione crea il backup `bkup-20150515` dal cluster Valkey o Redis OSS (modalità cluster disabilitata) `myNonClusteredRedis` che non ha repliche di lettura.
Per Linux, macOS o Unix:
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis \
--snapshot-name bkup-20150515
```
Per Windows:
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis ^
--snapshot-name bkup-20150515
```
### Esempio 2: backup di un cluster Valkey o Redis OSS (Cluster Mode Disabled) con nodi di replica
La seguente AWS CLI operazione crea il backup `bkup-20150515` dal cluster Valkey o Redis OSS (modalità cluster disabilitata). `myNonClusteredRedis` Questo backup ha una o più repliche di lettura.
Per Linux, macOS o Unix:
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis-001 \
--snapshot-name bkup-20150515
```
Per Windows:
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis-001 ^
--snapshot-name bkup-20150515
```
**Esempio di output: backup di un cluster Valkey o Redis OSS (modalità cluster disabilitata) con nodi di replica**
L'aspetto dell'output dell'operazione è simile al seguente.
```
{
"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"
}
}
```
### Esempio 3: backup di un cluster per Valkey o Redis OSS (modalità cluster abilitata)
La seguente AWS CLI operazione crea il backup `bkup-20150515` dal cluster Valkey o Redis OSS (modalità cluster abilitata). `myClusteredRedis` Nota l'uso di `--replication-group-id` anziché `--cache-cluster-id` per identificare l'fonte. Si noti inoltre che ElastiCache esegue il backup utilizzando il nodo di replica quando presente e, se un nodo di replica non è disponibile, passerà per impostazione predefinita al nodo primario.
Per Linux, macOS o Unix:
```
aws elasticache create-snapshot \
--replication-group-id myClusteredRedis \
--snapshot-name bkup-20150515
```
Per Windows:
```
aws elasticache create-snapshot ^
--replication-group-id myClusteredRedis ^
--snapshot-name bkup-20150515
```
**Esempio di output: backup di un cluster Valkey o Redis OSS (modalità cluster abilitata)**
L'aspetto dell'output di questa operazione è simile al seguente.
```
{
"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"
}
}
```
### Argomenti correlati
Per ulteriori informazioni, consulta [create-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-snapshot.html) nella *Guida di riferimento ai comandi della AWS CLI*.
## Creazione di un backup utilizzando CloudFormation
È possibile utilizzare CloudFormation per creare un backup della cache ElastiCache Redis OSS o Valkey, utilizzando le proprietà `AWS::ElastiCache::ServerlessCache` o`AWS::ElastiCache::ReplicationGroup`.
**Utilizzo della risorsa `AWS::ElastiCache::ServerlessCache`**
Usalo per creare un backup usando la AWS::ElastiCache::ServerlessCache risorsa:
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ServerlessCache
Properties:
...
ServerlessCacheName: "your-cache-name"
Engine: "redis"
CacheUsageLimits
```
**Utilizzo della AWS::ElastiCache::ReplicationGroup risorsa**
Usa la `AWS::ElastiCache::ReplicationGroup` risorsa:
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ReplicationGroup
Properties:
...
ReplicationGroupDescription: "Description of your replication group"
Engine: "redis"
CacheNodeType
NumCacheClusters
AutomaticFailoverEnabled
AtRestEncryptionEnabled
```
# Creazione di un backup finale
Puoi creare un backup finale utilizzando la ElastiCache console AWS CLI, l'o l' ElastiCache API.
## Creazione di un backup finale (console)
È possibile creare un backup finale quando si elimina una cache serverless Valkey, Memcached o Redis OSS o un cluster basato su nodi Valkey o Redis OSS, utilizzando la console. ElastiCache
**Per creare un backup finale quando si elimina una cache, nella finestra di dialogo di eliminazione scegli **Sì** in Crea backup e assegna un nome al backup.**
**Argomenti correlati**
+ [Utilizzando il Console di gestione AWS](Clusters.Delete.md#Clusters.Delete.CON)
+ [Eliminazione di un gruppo di replica (console)](Replication.DeletingRepGroup.md#Replication.DeletingRepGroup.CON)
## Creazione di un backup finale (AWS CLI)
È possibile creare un backup finale quando si elimina una cache utilizzando il.AWS CLI
**Topics**
+ [Quando si elimina una cache Valkey, una cache serverless Memcached o una cache Redis OSS](#w2aac24b7c29b7b1b7)
+ [Quando si elimina un cluster Valkey o Redis OSS senza repliche di lettura](#w2aac24b7c29b7b1b9)
+ [Quando si elimina un cluster Valkey o Redis OSS con repliche di lettura](#w2aac24b7c29b7b1c11)
### Quando si elimina una cache Valkey, una cache serverless Memcached o una cache Redis OSS
Per creare un backup finale, utilizzare l'operazione con i `delete-serverless-cache`AWS CLI seguenti parametri.
+ `--serverless-cache-name`: nome della cache da eliminare.
+ `--final-snapshot-name` : Nome del backup.
Il codice seguente consente di creare il backup finale `bkup-20231127-final` durante l'eliminazione della cache `myserverlesscache`.
Per Linux, macOS o Unix:
```
aws elasticache delete-serverless-cache \
--serverless-cache-name myserverlesscache \
--final-snapshot-name bkup-20231127-final
```
Per Windows:
```
aws elasticache delete-serverless-cache ^
--serverless-cache-name myserverlesscache ^
--final-snapshot-name bkup-20231127-final
```
Per ulteriori informazioni, consulta [delete-serverless-cache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache.html) nella *documentazione di riferimento dei comandi della AWS CLI*.
### Quando si elimina un cluster Valkey o Redis OSS senza repliche di lettura
Per creare un backup finale per un cluster basato su nodi senza repliche di lettura, utilizza l'operazione con i seguenti parametri. `delete-cache-cluster`AWS CLI
+ `--cache-cluster-id` : Nome del cluster in corso di eliminazione.
+ `--final-snapshot-identifier` : Nome del backup.
Il codice seguente consente di creare il backup finale `bkup-20150515-final` durante l'eliminazione del cluster `myRedisCluster`.
Per Linux, macOS o Unix:
```
aws elasticache delete-cache-cluster \
--cache-cluster-id myRedisCluster \
--final-snapshot-identifier bkup-20150515-final
```
Per Windows:
```
aws elasticache delete-cache-cluster ^
--cache-cluster-id myRedisCluster ^
--final-snapshot-identifier bkup-20150515-final
```
Per ulteriori informazioni, consulta [delete-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-cluster.html) nella *documentazione di riferimento dei comandi della AWS CLI*.
### Quando si elimina un cluster Valkey o Redis OSS con repliche di lettura
Per creare un backup finale quando si elimina un gruppo di replica, utilizzate l'`delete-replication-group`AWS CLI operazione con i seguenti parametri:
+ `--replication-group-id` : Nome del gruppo di replica in corso di eliminazione.
+ `--final-snapshot-identifier` : Nome del backup finale.
Il codice seguente prende il backup finale `bkup-20150515-final` durante l'eliminazione del gruppo di replica `myReplGroup`.
Per Linux, macOS o Unix:
```
aws elasticache delete-replication-group \
--replication-group-id myReplGroup \
--final-snapshot-identifier bkup-20150515-final
```
Per Windows:
```
aws elasticache delete-replication-group ^
--replication-group-id myReplGroup ^
--final-snapshot-identifier bkup-20150515-final
```
Per ulteriori informazioni, consulta [delete-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-replication-group.html) nella *documentazione di riferimento dei comandi della AWS CLI*.
# Descrizione dei backup
Le procedure seguenti illustrano come visualizzare un elenco dei backup. Se lo desideri, puoi visualizzare anche i dettagli di un particolare backup.
## Descrizione dei backup (console)
**Per visualizzare i backup utilizzando Console di gestione AWS**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel riquadro di navigazione, scegliere **Backups (Backup)**.
1. Per visualizzare i dettagli di un particolare backup, scegliere la casella a sinistra del nome del backup.
## Descrizione dei backup serverless (AWS CLI)
Per visualizzare un elenco di backup serverless e opzionalmente i dettagli relativi a un backup specifico, utilizza l'operazione `describe-serverless-cache-snapshots` della CLI.
**Esempi**
L'operazione seguente utilizza il parametro `--max-records` per elencare un massimo di 20 backup associati all'account. Se si omette il parametro `--max-records` vengono elencati fino a 50 backup.
```
aws elasticache describe-serverless-cache-snapshots --max-records 20
```
L'operazione seguente utilizza il parametro `--serverless-cache-name` per elencare solo i backup associati alla cache `my-cache`.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-name my-cache
```
L'operazione seguente utilizza il parametro `--serverless-cache-snapshot-name` per visualizzare i dettagli del backup `my-backup`.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-snapshot-name my-backup
```
Per ulteriori informazioni, consulta [describe-serverless-cache-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-serverless-cache-snapshots.html)la sezione AWS CLI Command Reference.
## Descrizione dei backup di cluster basati su nodi ()AWS CLI
Per visualizzare un elenco di backup del cluster basati su nodi e, facoltativamente, dettagli su un backup specifico, utilizzate l'operazione CLI. `describe-snapshots`
**Esempi**
L'operazione seguente utilizza il parametro `--max-records` per elencare un massimo di 20 backup associati all'account. Se si omette il parametro `--max-records` vengono elencati fino a 50 backup.
```
aws elasticache describe-snapshots --max-records 20
```
L'operazione seguente utilizza il parametro `--cache-cluster-id` per elencare solo i backup associati al cluster `my-cluster`.
```
aws elasticache describe-snapshots --cache-cluster-id my-cluster
```
L'operazione seguente utilizza il parametro `--snapshot-name` per visualizzare i dettagli del backup `my-backup`.
```
aws elasticache describe-snapshots --snapshot-name my-backup
```
Per ulteriori informazioni, consulta [describe-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-snapshots.html) nel Command Reference.AWS CLI
# Copia di backup
Puoi creare una copia di qualsiasi backup, a prescindere che sia stato eseguito automaticamente o manualmente. Puoi anche esportare il backup in modo da potervi accedere dall'esterno ElastiCache. Per ulteriori informazioni sull'esportazione del backup, consulta [Esportazione di un backup](backups-exporting.md).
I passaggi seguenti illustrano come copiare un backup.
## Copia dei backup (console)
**Copia di un backup (console)**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Per visualizzare un elenco dei backup, dal pannello di navigazione, scegliere **Backups (Backup)**.
1. Dall'elenco di backup, scegliere la casella a sinistra del nome del backup che si desidera copiare.
1. Seleziona **Operazioni** e quindi **Copia**.
1. Nella casella **New backup name (Nome del nuovo backup)**, digitare un nome per il nuovo backup.
1. Scegli **Copia**.
## Copia di un backup serverless (AWS CLI)
Per copiare un backup di una cache serverless utilizza l'operazione `copy-serverless-cache-snapshot`.
**Parameters**
+ `--source-serverless-cache-snapshot-name` - Nome del backup da copiare.
+ `--target-serverless-cache-snapshot-name` - Nome della copia del backup.
Nel seguente esempio viene creata una copia di un backup automatico.
Per Linux, macOS o 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
```
Per 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
```
Per ulteriori informazioni, consulta [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) nella *AWS CLI*.
## Copia di un backup del cluster basato su nodi ()AWS CLI
Per copiare un backup di un cluster basato su nodi, utilizzate l'operazione. `copy-snapshot`
**Parameters**
+ `--source-snapshot-name` - Nome del backup da copiare.
+ `--target-snapshot-name` - Nome della copia del backup.
+ `--target-bucket` Riservato per l'esportazione di un backup. Non utilizzare questo parametro durante la creazione di una copia di un backup. Per ulteriori informazioni, consulta [Esportazione di un backup](backups-exporting.md).
Nel seguente esempio viene creata una copia di un backup automatico.
Per Linux, macOS o Unix:
```
aws elasticache copy-snapshot \
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 \
--target-snapshot-name amzn-s3-demo-bucket
```
Per Windows:
```
aws elasticache copy-snapshot ^
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 ^
--target-snapshot-name amzn-s3-demo-bucket
```
Per ulteriori informazioni, consulta [https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html) nella *AWS CLI*.
# Esportazione di un backup
Amazon ElastiCache supporta l'esportazione del backup ElastiCache per Redis OSS in un bucket Amazon Simple Storage Service (Amazon S3), che consente di accedervi dall'esterno. ElastiCache Puoi esportare un backup utilizzando la ElastiCache console, l'o l'API AWS CLI. ElastiCache
L'esportazione di un backup può essere utile se è necessario avviare un cluster in un'altra AWS regione. È possibile esportare i dati in una AWS regione, copiare il file.rdb AWS nella nuova regione e quindi utilizzare il file.rdb per seminare la nuova cache invece di attendere che il nuovo cluster venga popolato tramite l'uso. Per informazioni sull'inizializzazione di un nuovo cluster, consulta [Tutorial: Seminare un nuovo cluster basato su nodi con un backup creato esternamente](backups-seeding-redis.md). Un altro motivo per cui potresti voler esportare i dati della cache è utilizzare il file.rdb per l'elaborazione offline.
**Importante**
Il ElastiCache backup e il bucket Amazon S3 in cui desideri copiarlo devono trovarsi nella stessa regione.AWS
Sebbene i backup copiati in un bucket Amazon S3 siano crittografati, ti consigliamo di non concedere altri accessi al bucket Amazon S3 in cui desideri archiviare i backup.
L'esportazione di un backup in Amazon S3 non è supportata per i cluster che utilizzano il tiering di dati. Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
L'esportazione di un backup è disponibile per: cluster Valkey basati su nodi, cluster Redis OSS basati su nodi e cache serverless Valkey, Memcached e Redis OSS. L'esportazione di un backup non è disponibile per i cluster Memcached basati su nodi.
Prima di poter esportare un backup in un bucket Amazon S3, devi avere un bucket Amazon S3 nella stessa regione del backup.AWS Concedi l' ElastiCache accesso al bucket. Le prime due fasi mostrano come eseguire questa operazione.
## Crea un bucket Amazon S3
I passaggi seguenti utilizzano la console Amazon S3 per creare un bucket Amazon S3 in cui esportare e archiviare il backup. ElastiCache
**Come creare un bucket Amazon S3.**
1. Accedi a Console di gestione AWS e apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Scegli **Crea bucket**.
1. In **Creare bucket - Scegli un nome di bucket e una regione**, esegui le seguenti operazioni:
1. In **Nome bucket**, digita un nome per il bucket Amazon S3.
Il nome del bucket Amazon S3 deve essere conforme a DNS. Altrimenti, non ElastiCache potrai accedere al tuo file di backup. Le regole per la conformità DNS sono:
+ I nomi devono avere una lunghezza compresa fra 3 e 63 caratteri.
+ I nomi devono contenere una serie di una o più etichette separate da un punto (.) in cui ciascuna etichetta:
+ Inizia con una lettera minuscola o un numero.
+ Finisce con una lettera minuscola o un numero.
+ Contiene solo lettere minuscole, numeri e trattini.
+ Non deve avere il formato di un indirizzo IP (ad esempio, 192.0.2.0).
1. Dall'elenco delle **regioni**, scegli una AWS regione per il tuo bucket Amazon S3. Questa AWS regione deve essere la stessa AWS del ElastiCache backup che desideri esportare.
1. Scegli **Create** (Crea).
Per ulteriori informazioni sulla creazione di un bucket Amazon S3, consulta[Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html)nella*Guida all'utente di Amazon Simple Storage Service*.
## Concedi ElastiCache l'accesso al tuo bucket Amazon S3
ElastiCache Per poter copiare uno snapshot in un bucket Amazon S3, devi aggiornare la policy del bucket IAM per ElastiCache concedere l'accesso al bucket.
**avvertimento**
Anche se i backup copiati in un bucket Amazon S3 sono crittografati, i dati sono accessibili a chiunque disponga dell'accesso al bucket Amazon S3. Pertanto, ti consigliamo di configurare le policy IAM per impedire l'accesso non autorizzato a questo bucket Amazon S3. Per ulteriori informazioni, consulta [Gestione accesso](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) nella *Guida per gli utenti di Amazon S3*.
Per creare le autorizzazioni corrette su un bucket Amazon S3, segui la procedura descritta di seguito.
**Per concedere l'accesso a un bucket ElastiCache S3**
1. Accedi a Console di gestione AWS e apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Scegli il nome del bucket Amazon S3 in cui desideri copiare il backup. Deve essere il bucket S3 che è stato creato in [Crea un bucket Amazon S3](#backups-exporting-create-s3-bucket).
1. Seleziona la scheda **Autorizzazioni** e sotto **Autorizzazioni** scegli **Lista di controllo degli accessi (ACL)**, quindi seleziona **Modifica**.
1. Aggiungi l’ID canonico `540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353` all’assegnatario con le opzioni seguenti:
+ **Oggetti: Elenco, Scrittura**
+ **ACL bucket: Lettura, Scrittura**
**Nota**
Per la GovCloud regione PDT, l'ID canonico è. `40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6`
Per la GovCloud regione OSU, l'ID canonico è. `c54286759d2a83da9c480405349819c993557275cf37d820d514b42da6893f5c`
1. Scegli **Save** (Salva).
## Esportazione e backup ElastiCache
Ora hai creato il tuo bucket S3 e concesso ElastiCache le autorizzazioni per accedervi. Successivamente, puoi utilizzare la ElastiCache console, la AWS CLI o l' ElastiCache API per esportare la tua istantanea al suo interno.
Di seguito è riportato un esempio di come potrebbe essere la policy aggiornata.
------
#### [ 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/*"
]
}
]
}
```
------
Per le regioni opt-in, di seguito è riportato un esempio di come potrebbe essere la policy IAM aggiornata per il bucket S3. (Questo esempio utilizza la regione Asia Pacifico (Hong Kong).)
------
#### [ 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/*"
]
}
]
}
```
------
### Esportazione di un ElastiCache backup (console)
I passaggi seguenti utilizzano la ElastiCache console per esportare un backup in un bucket Amazon S3 in modo da potervi accedere dall'esterno. ElastiCache Il bucket Amazon S3 deve trovarsi nella stessa AWS regione del backup. ElastiCache
**Per esportare un ElastiCache backup in un bucket Amazon S3**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Per visualizzare un elenco dei backup, dal riquadro di navigazione, scegliere **Backups (Backup)**.
1. Dall'elenco di backup, scegli la casella a sinistra del nome del backup che desideri esportare.
1. Scegli **Copia**.
1. In **Creare una copia del backup?**, procedere come segue:
1. Nella casella **Nome del nuovo backup**, digita un nome per il nuovo backup.
Il nome deve essere compreso tra 1 e 1000 caratteri e dotato di codifica UTF-8.
ElastiCache aggiunge un identificatore di istanza e `.rdb` al valore che inserisci qui. Ad esempio, se si inserisce `my-exported-backup`, ElastiCache crea `my-exported-backup-0001.rdb`.
1. Dall'elenco **Posizione di destinazione S3**, scegli il nome del bucket Amazon S3 in cui copiare il backup (il bucket creato in [Crea un bucket Amazon S3](#backups-exporting-create-s3-bucket)).
La **posizione S3 di destinazione** deve essere un bucket Amazon S3 nella regione AWS del backup con le seguenti autorizzazioni affinché il processo di esportazione abbia successo.
+ Accesso agli oggetti : **Lettura** e **Scrittura**.
+ Accesso alle autorizzazioni : **Lettura**.
Per ulteriori informazioni, consulta [Concedi ElastiCache l'accesso al tuo bucket Amazon S3](#backups-exporting-grant-access).
1. Scegli **Copia**.
**Nota**
Se il tuo bucket S3 non dispone delle autorizzazioni necessarie per esportare un backup ElastiCache al suo interno, ricevi uno dei seguenti messaggi di errore. Tornare a [Concedi ElastiCache l'accesso al tuo bucket Amazon S3](#backups-exporting-grant-access) per aggiungere le autorizzazioni specificate e riprovare a esportare il backup.
ElastiCache non sono state concesse le autorizzazioni READ %s sul bucket S3.
**Soluzione:** aggiungere autorizzazioni di lettura sul bucket.
ElastiCache non ha ricevuto le autorizzazioni di SCRITTURA %s sul bucket S3.
**Soluzione:** aggiungere autorizzazioni di scrittura sul bucket.
ElastiCache non ha ricevuto le autorizzazioni READ\$1ACP %s sul bucket S3.
**Soluzione:** aggiungere **Read (Lettura)** per Accesso alle autorizzazioni sul bucket.
Se desideri copiare il backup in un'altra AWS regione, usa Amazon S3 per copiarlo. Per ulteriori informazioni, consulta [Copia un oggetto](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MakingaCopyofanObject.html) nella *Guida per l’utente di Amazon Simple Storage Service*.
### Esportazione di un backup ElastiCache senza server ()AWS CLI
**Esportazione di un backup di una cache serverless**
Esporta il backup in un bucket Amazon S3 utilizzando l'operazione CLI `export-serverless-cache-snapshot` con i seguenti parametri:
**Parameters**
+ `--serverless-cache-snapshot-name` - Nome del backup da copiare.
+ `--s3-bucket-name` : Nome del bucket Amazon S3 in cui desideri esportare il backup. Viene creata una copia del backup nel bucket specificato.
`--s3-bucket-name`Affinché il processo di esportazione abbia successo, deve essere un bucket Amazon S3 AWS nella regione del backup con le seguenti autorizzazioni.
+ Accesso agli oggetti : **Lettura** e **Scrittura**.
+ Accesso alle autorizzazioni : **Lettura**.
La seguente operazione copia un backup in my-s3-bucket.
Per Linux, macOS o Unix:
```
aws elasticache export-serverless-cache-snapshot \
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 \
--s3-bucket-name my-s3-bucket
```
Per Windows:
```
aws elasticache export-serverless-cache-snapshot ^
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 ^
--s3-bucket-name my-s3-bucket
```
### Esportazione di un backup del cluster basato su nodi ElastiCache ()AWS CLI
**Esportazione di un backup di un cluster basato su nodi**
Esporta il backup in un bucket Amazon S3 utilizzando l'operazione CLI `copy-snapshot` con i seguenti parametri:
**Parameters**
+ `--source-snapshot-name` - Nome del backup da copiare.
+ `--target-snapshot-name` : Nome della copia del backup.
Il nome deve essere compreso tra 1 e 1000 caratteri e dotato di codifica UTF-8.
ElastiCache aggiunge un identificatore di istanza e `.rdb` al valore che inserisci qui. Ad esempio, se si inserisce `my-exported-backup`, ElastiCache crea `my-exported-backup-0001.rdb`.
+ `--target-bucket` : Nome del bucket Amazon S3 in cui desideri esportare il backup. Viene creata una copia del backup nel bucket specificato.
`--target-bucket`Affinché il processo di esportazione abbia successo, deve essere un bucket Amazon S3 AWS nella regione del backup con le seguenti autorizzazioni.
+ Accesso agli oggetti : **Lettura** e **Scrittura**.
+ Accesso alle autorizzazioni : **Lettura**.
Per ulteriori informazioni, consulta [Concedi ElastiCache l'accesso al tuo bucket Amazon S3](#backups-exporting-grant-access).
La seguente operazione copia un backup in my-s3-bucket.
Per Linux, macOS o 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
```
Per 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
```
# Ripristino da un backup in una nuova cache
È possibile ripristinare un backup esistente da Valkey in una nuova cache Valkey o in un cluster basato su nodi e ripristinare un backup Redis OSS esistente in una nuova cache Redis OSS o cluster basato su nodi. È inoltre possibile ripristinare un backup della cache serverless Memcached esistente in una nuova cache serverless Memcached.
## Ripristino di un backup in una cache serverless (console)
**Nota**
ElastiCache Serverless supporta file RDB compatibili con Valkey 7.2 e versioni successive e versioni Redis OSS comprese tra la 5.0 e l'ultima versione disponibile.
**Per ripristinare un backup in una cache serverless (console)**
1. Accedi a Console di gestione AWS e apri la console all'indirizzo. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nel riquadro di navigazione, scegliere **Backups (Backup)**.
1. Nell'elenco dei backup, scegli la casella a sinistra del nome del backup di cui desideri eseguire il ripristino.
1. Scegli **Operazioni** e quindi **Ripristina**.
1. Immetti un nome e facoltativamente una descrizione per la nuova cache serverless.
1. Fai clic su **Crea** per creare la nuova cache e importare i dati dal backup.
## Ripristino di un backup in un cluster basato su nodi (Console)
**Per ripristinare un backup in un cluster basato su nodi (console)**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nel riquadro di navigazione, scegliere **Backups (Backup)**.
1. Nell'elenco dei backup, scegli la casella a sinistra del nome di backup da cui desideri eseguire il ripristino.
1. Scegli **Operazioni** e quindi **Ripristina**.
1. Scegli la **cache basata su nodi** e personalizza le impostazioni del cluster, come il tipo di nodo, le dimensioni, il numero di shard, le repliche, il posizionamento AZ e le impostazioni di sicurezza.
1. Scegli **Crea per creare** il tuo nuovo cluster basato su nodi e importare i dati dal backup.
## Ripristino di un backup in una cache serverless (AWS CLI)
**Nota**
ElastiCache Serverless supporta file RDB compatibili con Valkey 7.2 e versioni successive e versioni Redis OSS comprese tra la 5.0 e l'ultima versione disponibile.
**Per ripristinare un backup in una nuova cache serverless (AWS CLI)**
L'AWS CLI esempio seguente crea una nuova cache utilizzando `create-serverless-cache` e importa i dati da un backup.
Per Linux, macOS o Unix:
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine redis
--snapshot-arns-to-restore Snapshot-ARN
```
Per Windows:
```
aws elasticache create-serverless-cache ^
--serverless-cache-name CacheName ^
--engine redis ^
--snapshot-arns-to-restore Snapshot-ARN
```
# Eliminazione di un backup
Un backup automatico viene automaticamente eliminato quando il suo periodo di retention scade. Se elimini un cluster, vengono anche eliminati tutti i relativi backup automatici. Se elimini un gruppo di replica, vengono anche eliminati tutti i backup automatici dai cluster in tale gruppo.
ElastiCache fornisce un'operazione API di eliminazione che consente di eliminare un backup in qualsiasi momento, indipendentemente dal fatto che il backup sia stato creato automaticamente o manualmente. Poiché i backup manuali non dispongono di un periodo di conservazione, l'eliminazione manuale è il solo modo per rimuoverli.
È possibile eliminare un backup utilizzando la ElastiCache console AWS CLI, l'o l' ElastiCache API.
## Eliminazione di un backup (console)
La procedura seguente elimina un backup utilizzando la ElastiCache console.
**Per eliminare un backup**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegliere **Backups (Backup)**.
Viene visualizzata la schermata dei backup con un elenco dei backup.
1. Scegliere la casella a sinistra del nome del backup da eliminare.
1. Scegli **Elimina**.
1. Per eliminare questo backup, scegliere **Delete (Elimina)** nella schermata di conferma **Delete Backup (Elimina backup)**. Lo stato cambia in *eliminazione*.
## Eliminazione di un backup serverless (AWS CLI)
Utilizzate l'AWS CLI operazione delete-snapshot con il seguente parametro per eliminare un backup senza server.
+ `--serverless-cache-snapshot-name` - Nome del backup da eliminare.
Il codice seguente elimina il backup `myBackup`.
```
aws elasticache delete-serverless-cache-snapshot --serverless-cache-snapshot-name myBackup
```
Per ulteriori informazioni, consulta [delete-serverless-cache-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache-snapshot.html) nella *documentazione di riferimento dei comandi della AWS CLI*.
## Eliminazione di un backup del cluster basato su nodi ()AWS CLI
Utilizzate l'AWS CLI operazione delete-snapshot con il seguente parametro per eliminare un backup del cluster basato su nodi.
+ `--snapshot-name` - Nome del backup da eliminare.
Il codice seguente elimina il backup `myBackup`.
```
aws elasticache delete-snapshot --snapshot-name myBackup
```
Per ulteriori informazioni, vedere [delete-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-snapshot.html) in *AWS CLI guida di riferimento del comando*.
# Assegnazione di tag di backup
Puoi assegnare metadati a ciascun backup sotto forma di tag. I tag consentono di categorizzare le tue risorse di backup in modi diversi, ad esempio, per scopo, proprietario o ambiente. Questa caratteristicaè molto utile quando hai tante risorse dello stesso tipo in quanto puoi rapidamente individuare una risorsa specifica in base ai tag assegnati. Per ulteriori informazioni, consulta [Risorse cui è possibile associare tag](Tagging-Resources.md#Tagging-your-resources).
I tag di allocazione dei costi sono un mezzo per tenere traccia dei costi su più AWS servizi raggruppando le spese sulle fatture in base ai valori dei tag. Per ulteriori informazioni sui tag di allocazione dei costi, consulta la sezione relativa all'[uso dei tag di allocazione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html).
Utilizzando la ElastiCache console AWS CLI, l' ElastiCache API o l'API puoi aggiungere, elencare, modificare, rimuovere o copiare i tag di allocazione dei costi sui tuoi backup. Per ulteriori informazioni, consulta [Monitoraggio dei costi con i tag di allocazione dei costi](Tagging.md).
# Tutorial: Seminare un nuovo cluster basato su nodi con un backup creato esternamente
Quando si crea un nuovo cluster basato su nodi Valkey o Redis OSS, è possibile eseguire il seed con i dati di un file di backup Valkey o Redis OSS .rdb. Il seeding del cluster è utile se attualmente gestite un'istanza Valkey o Redis OSS all'esterno ElastiCache e desiderate popolare il nuovo cluster basato su nodi Redis OSS con i dati Valkey o Redis OSS ElastiCache esistenti.
Per eseguire il seeding di un nuovo cluster basato su nodi Valkey o Redis OSS da un backup Valkey o Redis OSS creato all'interno di Amazon, consulta. ElastiCache [Ripristino da un backup in una nuova cache](backups-restoring.md)
Quando usi un file Valkey o Redis OSS .rdb per seminare un nuovo cluster basato su nodi, puoi fare quanto segue:
+ Esegui l'aggiornamento da un cluster non partizionato a un cluster basato su nodi Valkey o Redis OSS (modalità cluster abilitata) che esegue Redis OSS versione 3.2.4.
+ Specificate un numero di shard (chiamati gruppi di nodi nell'API e nella CLI) nel nuovo cluster basato su nodi. Questo numero può essere diverso dal numero di shard nel cluster basato su nodi utilizzato per creare il file di backup.
+ Specificare un tipo di nodo diverso per il nuovo cluster basato su nodi, più grande o più piccolo di quello utilizzato nel cluster che ha eseguito il backup. Se esegui la scalabilità a un tipo di nodo più piccolo, assicurati che il nuovo tipo di nodo disponga di memoria sufficiente per i dati e il sovraccarico di Valkey o Redis OSS. Per ulteriori informazioni, consulta [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md).
+ Distribuisci le chiavi negli slot del nuovo cluster Valkey o Redis OSS (modalità cluster abilitata) in modo diverso rispetto al cluster utilizzato per creare il file di backup.
**Nota**
Non è possibile eseguire il seeding di un cluster Valkey o Redis OSS (modalità cluster disabilitata) da un file.rdb creato da un cluster Valkey o Redis OSS (modalità cluster abilitata).
**Importante**
È necessario assicurarsi che i dati di backup di Valkey o Redis OSS non superino le risorse del nodo. Ad esempio, non è possibile caricare un file.rdb con 5 GB di dati Valkey o Redis OSS su un nodo cache.m3.medium con 2,9 GB di memoria.
Se il backup è troppo grande, lo stato del cluster risultante sarà `restore-failed`. In tal caso, occorre eliminare il cluster e ricominciare.
Per un elenco completo dei tipi e delle specifiche dei nodi, consulta le [caratteristiche [Parametri specifici del tipo di nodo Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific) e i dettagli dei ElastiCache prodotti Amazon](https://aws.amazon.com/elasticache/details/).
Puoi crittografare un file Valkey o Redis OSS .rdb solo con la crittografia lato server di Amazon S3 (SSE-S3). Per ulteriori informazioni, consulta [Protezione dei dati con la crittografia lato server](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html).
Di seguito, puoi trovare argomenti che illustrano la migrazione del cluster dall'esterno per Valkey o Redis OSS a Redis OSS. ElastiCache ElastiCache
**Topics**
+ [Passaggio 1: creare un backup Valkey o Redis OSS](#backups-seeding-redis-create-backup)
+ [Fase 2: creazione di un bucket Amazon S3 e una cartella](#backups-seeding-redis-create-s3-bucket)
+ [Fase 3: caricamento del backup in Amazon S3](#backups-seeding-redis-upload)
+ [Passaggio 4: concedere l'accesso in ElastiCache lettura al file.rdb](#backups-seeding-redis-grant-access)
**Topics**
+ [Passaggio 1: creare un backup Valkey o Redis OSS](#backups-seeding-redis-create-backup)
+ [Fase 2: creazione di un bucket Amazon S3 e una cartella](#backups-seeding-redis-create-s3-bucket)
+ [Fase 3: caricamento del backup in Amazon S3](#backups-seeding-redis-upload)
+ [Passaggio 4: concedere l'accesso in ElastiCache lettura al file.rdb](#backups-seeding-redis-grant-access)
## Passaggio 1: creare un backup Valkey o Redis OSS
**Per creare il backup Valkey o Redis OSS per eseguire il seeding dell'istanza per Redis OSS ElastiCache**
1. Connect alla tua istanza Valkey o Redis OSS esistente.
1. Esegui una delle due `BGSAVE` `SAVE` operazioni per creare un backup. Prendere nota della posizione del file .rdb.
`BGSAVE` è asincrona e non blocca altri client durante l'elaborazione. Per ulteriori informazioni, vedere [BGSAVE](https://valkey.io/commands/bgsave) sul sito Web di Valkey.
`SAVE` è sincrona e blocca altri processi finché non è terminata. Per ulteriori informazioni, vedere [SAVE](https://valkey.io/commands/save) sul sito Web di Valkey.
Per ulteriori informazioni sulla creazione di un backup, vedere [Persistence sul sito web](https://valkey.io/topics/persistence) di Valkey.
## Fase 2: creazione di un bucket Amazon S3 e una cartella
Dopo che è stato creato, il file di backup deve essere caricato in una cartella all'interno di un bucket Amazon S3. A questo scopo, tale bucket deve contenere un bucket Amazon S3 e una cartella. Se disponi già di un bucket Amazon S3 e una cartella con le autorizzazioni appropriate, puoi passare a [Fase 3: caricamento del backup in Amazon S3](#backups-seeding-redis-upload).
**Come creare un bucket Amazon S3.**
1. Accedi Console di gestione AWS e apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Seguire le istruzioni per creare un bucket Amazon S3 in [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html) nella *Guida per l'utente di Amazon Simple Storage Service*.
Il nome del bucket Amazon S3 deve essere conforme a DNS. Altrimenti, non ElastiCache potrai accedere al tuo file di backup. Le regole per la conformità DNS sono:
+ I nomi devono avere una lunghezza compresa fra 3 e 63 caratteri.
+ I nomi devono contenere una serie di una o più etichette separate da un punto (.) in cui ciascuna etichetta:
+ Inizia con una lettera minuscola o un numero.
+ Finisce con una lettera minuscola o un numero.
+ Contiene solo lettere minuscole, numeri e trattini.
+ Non deve avere il formato di un indirizzo IP (ad esempio, 192.0.2.0).
È necessario creare il bucket Amazon S3 nella stessa AWS regione del nuovo ElastiCache cluster Redis OSS. Questo approccio garantisce la massima velocità di trasferimento dei dati durante la ElastiCache lettura del file.rdb da Amazon S3.
**Nota**
Per tenere i dati al scuro, crea autorizzazioni al bucket Amazon S3 il più possibile restrittive. Allo stesso tempo, le autorizzazioni devono comunque consentire l'utilizzo del bucket e del suo contenuto per il seeding del nuovo cluster Valkey o Redis OSS.
**Per aggiungere una cartella a un bucket Amazon S3**
1. Accedi Console di gestione AWS e apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Scegliere il nome del bucket in cui caricare il file .rdb.
1. Scegliere **Create folder (Crea cartella)**.
1. Immettere un nome per la nuova cartella.
1. Scegli **Save** (Salva).
Prendi nota del nome del bucket e del nome della cartella.
## Fase 3: caricamento del backup in Amazon S3
Ora, carica il file .rdb creato in [Passaggio 1: creare un backup Valkey o Redis OSS](#backups-seeding-redis-create-backup). Caricalo nel bucket Amazon S3 e nella cartella creata in [Fase 2: creazione di un bucket Amazon S3 e una cartella](#backups-seeding-redis-create-s3-bucket). Per ulteriori informazioni su questo processo, consulta [Aggiungere un oggetto in un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html). Tra le fasi 2 e 3, scegliere il nome della cartella creata.
**Per caricare il file .rdb in una cartella Amazon S3**
1. Accedi Console di gestione AWS e apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Scegliere il nome del bucket Amazon S3 creato nella fase 2.
1. Scegliere il nome della cartella creata nella Fase 2.
1. Scegli **Carica**.
1. Scegliere **Add files (Aggiungi file)**.
1. Individuare il file o i file da caricare, quindi scegliere il file o i file. Per scegliere più file, tenere premuto il tasto CTRL durante la selezione di ciascun nome file.
1. Seleziona **Apri**.
1. Verificare che il file o i file corretti sono elencati nella finestra di dialogo **Upload (Carica)**, quindi scegliere **Upload (Carica)**.
Nota il percorso nel file .rdb. Ad esempio, se il nome del bucket è `myBucket` e il percorso è `myFolder/redis.rdb`, digitare `myBucket/myFolder/redis.rdb`. Questo percorso è richiesto per inizializzare il nuovo cluster con i dati in questo backup.
Per ulteriori informazioni, consulta [Restrizioni e limitazioni dei bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) nella *Guida per gli utenti di Amazon Simple Storage Service*.
## Passaggio 4: concedere l'accesso in ElastiCache lettura al file.rdb
Ora concedi l'accesso in ElastiCache lettura al tuo file di backup.rdb. Concedi ElastiCache l'accesso al tuo file di backup in un modo diverso a seconda che il bucket si trovi in una AWS regione predefinita o in una regione opzionale.AWS
AWS Le regioni introdotte prima del 20 marzo 2019 sono abilitate per impostazione predefinita. Puoi iniziare a lavorare in queste AWS regioni immediatamente. Le regioni introdotte dopo il 20 marzo 2019, come l'Asia Pacifico (Hong Kong) e Medio Oriente (Bahrein), sono disabilitate per impostazione predefinita. È necessario abilitare o scegliere tali regioni prima di poterle utilizzare, come descritto in [Managing AWS regions](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) (Gestione delle regioni AWS) nella *Riferimenti generali di AWS*.
Scegli il tuo approccio in base alla tua AWS regione:
+ Per una regione predefinita, utilizzare la procedura in [Concedi l'accesso in ElastiCache lettura al file.rdb in una regione predefinita](#backups-seeding-redis-default-region).
+ Per una regione scelta, utilizzare la procedura in [Concedi l'accesso in ElastiCache lettura al file.rdb in una regione opzionale](#backups-seeding-opt-in-region).
### Concedi l'accesso in ElastiCache lettura al file.rdb in una regione predefinita
AWS Le regioni introdotte prima del 20 marzo 2019 sono abilitate per impostazione predefinita. Puoi iniziare a lavorare in queste AWS regioni immediatamente. Le regioni introdotte dopo il 20 marzo 2019, come l'Asia Pacifico (Hong Kong) e Medio Oriente (Bahrein), sono disabilitate per impostazione predefinita. È necessario abilitare o scegliere tali regioni prima di poterle utilizzare, come descritto in [Managing AWS regions](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) (Gestione delle regioni AWS) nella *Riferimenti generali di AWS*.
**Per concedere l'accesso in ElastiCache lettura al file di backup in una AWS regione è abilitato per impostazione predefinita**
1. Accedi Console di gestione AWS e apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Scegliere il nome del bucket S3 contenente il file .rdb.
1. Scegliere il nome della cartella contenente il file .rdb.
1. Scegliere il nome del file di backup .rdb. Il nome del file selezionato viene visualizzato sopra le schede nella parte superiore della pagina.
1. Seleziona **Autorizzazioni**.
1. Se **aws-scs-s3-readonly** o uno dei canonical IDs del seguente elenco non è elencato come utente, procedi come segue:
1. **In **Accesso per altri AWS account**, scegli Aggiungi beneficiario.**
1. Nella casella, aggiungi l'ID canonico della AWS regione come mostrato di seguito:
+ AWS GovCloud Regione (Stati Uniti occidentali):
```
40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6
```
**Importante**
Il backup deve trovarsi in un bucket S3 AWS GovCloud (US) per poterlo scaricare su un cluster Valkey o Redis OSS.AWS GovCloud (US)
+ AWS Regioni abilitate per impostazione predefinita:
```
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353
```
1. Impostare le autorizzazioni sul bucket scegliendo **Yes (Sì)** per:
+ **Oggetto elenco/scrittura**
+ **Autorizzazioni ACL oggetto lettura/scrittura**
1. Scegli **Save** (Salva).
1. Scegliere **Overview (Panoramica)**, quindi **Download (Scarica)**.
### Concedi l'accesso in ElastiCache lettura al file.rdb in una regione opzionale
AWS Le regioni introdotte prima del 20 marzo 2019 sono abilitate per impostazione predefinita. Puoi iniziare a lavorare in queste AWS regioni immediatamente. Le regioni introdotte dopo il 20 marzo 2019, come l'Asia Pacifico (Hong Kong) e Medio Oriente (Bahrein), sono disabilitate per impostazione predefinita. È necessario abilitare o scegliere tali regioni prima di poterle utilizzare, come descritto in [Managing AWS regions](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) (Gestione delle regioni AWS) nella *Riferimenti generali di AWS*.
Ora concedi l'accesso in ElastiCache lettura al tuo file di backup.rdb.
**Per concedere l'accesso in ElastiCache lettura al file di backup**
1. Accedi Console di gestione AWS e apri la console Amazon S3 all'indirizzo. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Scegliere il nome del bucket S3 contenente il file .rdb.
1. Scegliere il nome della cartella contenente il file .rdb.
1. Scegliere il nome del file di backup .rdb. Il nome del file selezionato viene visualizzato sopra le schede nella parte superiore della pagina.
1. Scegli la scheda **Autorizzazioni**.
1. Sotto **Autorizzazioni**, scegli **Policy bucket** e seleziona **Modifica**.
1. Aggiorna la policy per concedere le autorizzazioni ElastiCache necessarie per eseguire le operazioni:
+ Aggiungere `[ "Service" : "region-full-name.elasticache-snapshot.amazonaws.com" ]` a `Principal`.
+ Aggiungere le seguenti autorizzazioni necessarie per l'esportazione di uno snapshot nel bucket Amazon S3:
+ `"s3:GetObject"`
+ `"s3:ListBucket"`
+ `"s3:GetBucketAcl"`
Di seguito è riportato un esempio di come potrebbe essere la policy aggiornata.
------
#### [ 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. Scegli **Save changes** (Salva modifiche).
### Semina il ElastiCache cluster con i dati del file.rdb
Ora sei pronto per creare un ElastiCache cluster e seminarlo con i dati del file.rdb. Per creare il cluster, segui le istruzioni in [Creazione di un cluster per Valkey o Redis OSS](Clusters.Create.md) o [Creazione da zero di un gruppo di replica Valkey o Redis OSS](Replication.CreatingReplGroup.NoExistingCluster.md). Assicurati di scegliere Valkey o Redis OSS come motore del cluster.
Il metodo utilizzato per indicare ElastiCache dove trovare il backup caricato su Amazon S3 dipende dal metodo utilizzato per creare il cluster:
**Esegui il seme del cluster o del gruppo di replica ElastiCache for Redis OSS con i dati del file.rdb**
+ **Utilizzo della console ElastiCache **
Quando selezioni **Cluster settings** (Impostazioni cluster), scegli **Restore from backups** (Ripristina dai backup) come metodo di creazione del cluster, quindi scegli **Other backups** (Altri backup) come **Source** (Origine) nella sezione **Backup source** (Fonte del backup). Nella casella **Seed RDB file S3 location (Inizializza posizione Amazon S3 del file RDB)**, digita il percorso per i file. Se disponi di più file .rdb, digita il percorso per ogni file in un elenco separato da virgole. Il percorso Amazon S3 appare simile a `myBucket/myFolder/myBackupFilename.rdb`.
+ **Utilizzando il AWS CLI**
Se utilizzi l'operazione `create-cache-cluster` o `create-replication-group`, utilizza il parametro `--snapshot-arns` per specificare un ARN completo per ogni file .rdb. Ad esempio, `arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb`. L'ARN deve essere risolto nei file di backup archiviati in Amazon S3.
+ **Utilizzando l' ElastiCache API**
Se si utilizza l'operazione `CreateCacheCluster` o l'`CreateReplicationGroup` ElastiCache API, utilizzare il parametro `SnapshotArns` per specificare un ARN completo per ogni file.rdb. Ad esempio, `arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb`. L'ARN deve essere risolto nei file di backup archiviati in Amazon S3.
**Importante**
Quando si esegue il seeding di un cluster Valkey o Redis OSS (modalità cluster abilitata), è necessario configurare ogni gruppo di nodi (shard) nel nuovo cluster o gruppo di replica. A questo proposito, utilizza il parametro `--node-group-configuration` (API: `NodeGroupConfiguration`). Per ulteriori informazioni, consulta gli argomenti seguenti:
CLI: [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)nel riferimento AWS CLI
API: [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)nel riferimento ElastiCache API
Durante il processo di creazione del cluster, i dati del backup Valkey o Redis OSS vengono scritti nel cluster. È possibile monitorare l'avanzamento visualizzando i messaggi degli ElastiCache eventi. Per fare ciò, consulta la ElastiCache console e scegli **Cache Events**. Puoi anche utilizzare l'interfaccia a riga di AWS ElastiCache comando o l' ElastiCache API per ottenere i messaggi relativi agli eventi. Per ulteriori informazioni, consulta [Visualizzazione ElastiCache degli eventi](ECEvents.Viewing.md).
# Versioni del motore e aggiornamento in ElastiCache
Questa sezione illustra i motori Valkey, Memcached e Redis OSS supportati e le modalità di aggiornamento. Tieni presente che tutte le funzionalità disponibili con Redis OSS 7.2 sono disponibili in Valkey 7.2 e versioni successive per impostazione predefinita. È inoltre possibile eseguire l'aggiornamento da alcuni motori Redis OSS esistenti ElastiCache a un motore Valkey.
# Aggiornamento delle versioni del motore, compresi gli aggiornamenti cross-engine
**Valkey e Redis OSS**
Con Valkey e Redis OSS, è possibile avviare gli aggiornamenti di versione del cluster o del gruppo di replica modificandolo utilizzando la ElastiCache console, l'API o l'API e specificando una versione più AWS CLI recente del ElastiCache motore.
È inoltre possibile effettuare l'aggiornamento incrociato da Redis OSS a Valkey. Per ulteriori informazioni sugli aggiornamenti incrociati, consulta. [Come eseguire l'aggiornamento da Redis OSS a Valkey](#VersionManagement.HowTo.cross-engine-upgrade)
**Topics**
+ [Come eseguire l'aggiornamento da Redis OSS a Valkey](#VersionManagement.HowTo.cross-engine-upgrade)
+ [Risoluzione degli aggiornamenti bloccati del motore Valkey o Redis OSS](#resolving-blocked-engine-upgrades)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Memcached**
Con Memcached, per avviare gli aggiornamenti di versione del cluster, è necessario modificarlo e specificare una versione più recente del motore. Puoi farlo utilizzando la ElastiCache console, l'o l'API AWS CLI: ElastiCache
+ Per usare il Console di gestione AWS, vedi —[Usando il ElastiCache Console di gestione AWS](Clusters.Modify.md#Clusters.Modify.CON).
+ Per usare il AWS CLI, vedi[Usare il con AWS CLI ElastiCache](Clusters.Modify.md#Clusters.Modify.CLI).
+ Per utilizzare l' ElastiCache API, consulta[Utilizzo dell' ElastiCache API](Clusters.Modify.md#Clusters.Modify.API).
## Come eseguire l'aggiornamento da Redis OSS a Valkey
Valkey è progettato come sostituto immediato di Redis OSS 7. È possibile eseguire l'aggiornamento da Redis OSS a Valkey utilizzando la console, l'API o la CLI, specificando il nuovo motore e la versione principale del motore. L'indirizzo IP dell'endpoint e tutti gli altri aspetti dell'applicazione non verranno modificati dall'aggiornamento. Durante l'aggiornamento da Redis OSS 5.0.6 e versioni successive non si verificheranno tempi di inattività.
**Nota**
**AWS Requisiti della versione CLI per gli aggiornamenti da Redis OSS a Valkey:**
Per AWS CLI v1: versione minima richiesta 1.35.2 (versione corrente: 1.40.22)
Per AWS CLI v2: versione minima richiesta 2.18.2 (versione corrente: 2.27.22)
**Nota**
Quando si esegue l'aggiornamento da versioni Redis OSS precedenti alla 5.0.6, è possibile che si verifichi un tempo di failover compreso tra 30 e 60 secondi durante la propagazione DNS.
Per aggiornare un cluster Redis OSS esistente (modalità cluster disabilitata) a nodo singolo al motore Valkey, segui innanzitutto questi passaggi:. [Creazione di un gruppo di replica utilizzando un cluster esistente](Replication.CreatingReplGroup.ExistingCluster.md) Dopo aver aggiunto il cluster Redis OSS (modalità cluster disabilitata) a nodo singolo a un gruppo di replica, è possibile eseguire l'aggiornamento tra motori a Valkey.
### Aggiornamento di un gruppo di replica da Redis OSS a Valkey
Se disponi di un gruppo di replica Redis OSS esistente che utilizza il gruppo di parametri di cache predefinito, puoi eseguire l'aggiornamento a Valkey specificando il nuovo motore e la nuova versione del motore con API. modify-replication-group
Per Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0
```
Per Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0
```
Se hai un gruppo di parametri di cache personalizzato applicato al gruppo di replica Redis OSS esistente che desideri aggiornare, dovrai anche passare un gruppo di parametri di cache Valkey personalizzato nella richiesta. Il gruppo di parametri personalizzati Valkey di input deve avere gli stessi valori dei parametri statici Redis OSS del gruppo di parametri personalizzati Redis OSS esistente.
Per Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0 \
--cache-parameter-group-name myParamGroup
```
Per Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0 ^
--cache-parameter-group-name myParamGroup
```
### Aggiornamento di una cache serverless Redis OSS a Valkey con la CLI
Per Linux, macOS o Unix:
```
aws elasticache modify-serverless-cache \
--serverless-cache-name myCluster \
--engine valkey \
--major-engine-version 8
```
Per Windows:
```
aws elasticache modify-serverless-cache ^
--serverless-cache-name myCluster ^
--engine valkey ^
--major-engine-version 8
```
### Aggiornamento di Redis OSS a Valkey con la console
**Aggiornamento da Redis OSS 5 a Valkey**
1. Seleziona la cache Redis OSS per l'aggiornamento.
1. Dovrebbe apparire una finestra **di aggiornamento a Valkey**. Seleziona il pulsante **Aggiorna a Valkey**.
1. Vai alle **impostazioni della cache**, quindi seleziona la **versione del motore**. Si consiglia la versione più recente di Valkey.
1. Se questa cache è serverless, sarà necessario aggiornare il gruppo di parametri. Vai all'area **Gruppi di parametri** delle **impostazioni della cache**, seleziona un gruppo di parametri appropriato come *default.valkey8*.
1. **Seleziona Aggiorna.**
Questa cache verrà ora elencata nell'area Valkey della console.
**Nota**
L'aggiornamento diretto da Redis OSS 4 o versioni precedenti a Valkey può includere un tempo di failover più lungo da 30 a 60 secondi durante la propagazione DNS.
### Come effettuare il downgrade da Valkey a Redis OSS
Se per qualsiasi motivo desideri ripristinare il cluster aggiornato, Amazon ElastiCache supporta il rollback di una cache Valkey 7.2 su Redis OSS 7.1. È possibile eseguire un rollback utilizzando gli stessi passaggi della console, dell'API o della CLI dell'aggiornamento del motore e specificando Redis OSS 7.1 come versione del motore di destinazione. I rollback utilizzano gli stessi processi di aggiornamento. L'indirizzo IP dell'endpoint e tutti gli altri aspetti dell'applicazione non verranno modificati dal rollback e non si verificheranno tempi di inattività.
Inoltre, è possibile ripristinare un'istantanea creata dalla cache di Valkey 7.2 come cache Redis OSS 7.1. Quando esegui il ripristino da un'istantanea, puoi specificare Redis OSS 7.1 come versione del motore di destinazione. Quando si utilizza questa opzione, verrà creata una nuova cache dall'istantanea. Il ripristino da un'istantanea non ha alcun effetto sulla cache Valkey da cui è stata creata l'istantanea.
Quando si esegue un rollback, si applicano i seguenti requisiti e limitazioni:
+ ElastiCache supporta solo il rollback da Valkey 7.2 a Redis OSS 7.1. Questo è vero anche se hai eseguito l'aggiornamento a Valkey 7.2 da una versione precedente a Redis OSS 7.1.
+ Qualsiasi gruppo di utenti e utente associato al gruppo di replica o alla cache serverless di cui si esegue il rollback deve essere configurato con il tipo di motore. `REDIS`
## Risoluzione degli aggiornamenti bloccati del motore Valkey o Redis OSS
Come illustrato nella tabella seguente, l'operazione di aggiornamento del motore Valkey o Redis OSS è bloccata se è in corso un'operazione di scalabilità.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Per risolvere un aggiornamento del motore Valkey o Redis OSS bloccato**
+ Esegui una di queste operazioni:
+ **Pianifica l'operazione di aggiornamento del motore Redis OSS o Valkey per la prossima finestra di manutenzione deselezionando la casella di controllo Applica immediatamente.**
Con la CLI utilizzare `--no-apply-immediately`. Con l'API, utilizzare `ApplyImmediately=false`.
+ Attendi la finestra di manutenzione successiva (o successiva) per eseguire l'operazione di aggiornamento del motore Redis OSS.
+ Aggiungi l'operazione di scalabilità Redis OSS a questa modifica del cluster selezionando la casella di controllo **Applica immediatamente**.
Con la CLI utilizzare `--apply-immediately`. Con l'API, utilizzare `ApplyImmediately=true`.
Questo approccio annulla efficacemente l'aggiornamento del motore nella finestra di manutenzione successiva, poiché lo si esegue immediatamente.
# ElastiCache Supporto esteso
Con ElastiCache Extended Support, puoi continuare a utilizzare la cache su una versione principale del motore oltre la data di fine del supporto standard a un costo aggiuntivo. Se non effettui l'upgrade dopo la fine della data di supporto standard, ti verrà addebitato un costo.
Extended Support fornisce i seguenti aggiornamenti e supporto tecnico:
+ Aggiornamenti di sicurezza critici e di livello elevato CVEs per la cache e il motore di cache
+ Correzioni di bug e patch per problemi critici
+ La possibilità di aprire casi di supporto e ricevere assistenza per la risoluzione dei problemi nell'ambito del contratto di ElastiCache servizio standard
Questa offerta a pagamento offre più tempo per effettuare l'aggiornamento a una versione del motore principale supportata.
Ad esempio, la data di ElastiCache fine del supporto standard per Redis OSS 4.0.10 è il 31 gennaio 2026. Se non sei pronto per l'aggiornamento manuale a Valkey o a Redis OSS 6 o versioni successive entro tale data, ElastiCache registrerà automaticamente le tue cache in Extended Support e potrai continuare a eseguire Redis OSS 4.0.10. A partire dal primo giorno del mese dopo la fine del supporto standard, il 1° febbraio 2026, ti ElastiCache addebiterà automaticamente l'importo dell'Extended Support.
L'Extended Support è disponibile fino a 3 anni dopo la fine della data di supporto standard per una versione principale del motore. Per le versioni 4 e 5 di Elasticache for Redis OSS, sarà il 31 gennaio 2029. Dopo questa data, tutte le cache che eseguono ancora le versioni 4 e 5 di Redis OSS verranno aggiornate automaticamente alla versione più recente di Valkey.
Al termine del periodo di supporto di un motore, le cache che continuano a eseguire la versione precedente passeranno automaticamente all'Extended Support. Riceverai una notifica prima della data di inizio dei prezzi di Extended Support, quindi potrai invece aggiornare la tua istanza. Puoi anche disattivare esplicitamente il consenso in qualsiasi momento effettuando l'aggiornamento alle versioni supportate.
Per ulteriori informazioni sulle date di fine del supporto standard e sulle date di fine del supporto esteso, consulta [ElastiCache versioni per la pianificazione di fine del ciclo di vita di Redis OSS](engine-versions.md#deprecated-engine-versions) Valkey, Memcached o Redis OSS.
**Topics**
+ [ElastiCache Costi di Extended Support](extended-support-charges.md)
+ [Versioni con ElastiCache Extended Support](extended-support-versions.md)
+ [ElastiCache e responsabilità dei clienti con ElastiCache Extended Support](extended-support-responsibilities.md)
# ElastiCache Costi di Extended Support
Ti verranno addebitati i costi per tutti i motori iscritti al ElastiCache servizio Extended Support a partire dal giorno successivo alla fine del supporto standard. Per la data di ElastiCache fine del supporto standard, vedi. [Versioni con ElastiCache Extended Support](extended-support-versions.md)
Il costo aggiuntivo per ElastiCache Extended Support si interrompe automaticamente quando si esegue una delle seguenti azioni:
+ Effettua l'upgrade a una versione del motore coperta dal supporto standard.
+ Elimina la cache su cui è in esecuzione una versione principale dopo la data di ElastiCache fine del supporto standard.
Gli addebiti verranno riavviati se la versione del motore di destinazione entrerà in Extended Support in futuro.
Ad esempio, supponiamo che la ElastiCache versione 4 per Redis OSS entri in Extended Support il 1° febbraio 2026 e che tu aggiorni le cache dalla v4 alla v6 il 1° gennaio 2027. Ti verranno addebitati solo 11 mesi di Extended Support, nella ElastiCache versione 4 per Redis OSS. Se continui a utilizzare la ElastiCache versione 6 per Redis OSS dopo la data di fine del supporto standard del 31 gennaio 2027, tali cache saranno nuovamente soggette ai costi di Extended Support a partire dal 1° febbraio 2027.
Puoi evitare di ricevere addebiti per l' ElastiCacheExtended assistenza ElastiCache impedendo di creare o ripristinare una cache dopo la data di ElastiCache fine del supporto standard.
Per ulteriori informazioni, consulta i [ ElastiCache prezzi di Amazon](https://aws.amazon.com/elasticache/pricing/).
# Versioni con ElastiCache Extended Support
Le versioni 4 e 5 di Redis Open Source Software (OSS) hanno raggiunto la fine del ciclo di vita della community rispettivamente nel 2020 e nel 2022. Ciò significa che la community non rilascia ulteriori aggiornamenti, correzioni di bug o patch di sicurezza. Il supporto standard per le versioni 4 e 5 di ElastiCache Redis OSS ElastiCache terminerà il 31 gennaio 2026. Continuare a utilizzare versioni non supportate di Redis OSS potrebbe rendere i dati vulnerabili a [vulnerabilità ed esposizioni comuni](https://nvd.nist.gov/vuln-metrics/cvss) note (). CVEs
A partire dal 1° febbraio 2026, le ElastiCache cache ancora in esecuzione sulle versioni 4 e 5 di Redis OSS verranno automaticamente registrate in Extended Support, per fornire disponibilità e sicurezza continue. Sebbene Extended Support offra flessibilità, consigliamo di considerare la fine del supporto standard come una pietra miliare della pianificazione per i carichi di lavoro di produzione. Ti consigliamo vivamente di aggiornare le cache Redis OSS v4 e v5 a ElastiCache Valkey o Redis OSS v6 o versioni successive, prima della fine del supporto standard.
La tabella seguente riassume la data di ElastiCache fine del supporto standard di Amazon e le date di Extended Support.
**Supporto esteso e pianificazione di fine del ciclo di vita**
| Versione principale del motore | Fine del supporto standard | Inizio dell'Extended Support Y1 Premium | Inizio dell'Extended Support Y2 Premium | Inizio dell'Extended Support Y3 Premium | Fine dell'Extended Support e della versione EOL |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 31/01/2026 | 1/2/2026 | 1/2/2027 | 1/2/2028 | 31/2029 |
| Redis OSS v5 | 31/01/2026 | 1/2/2026 | 1/2/2027 | 1/2/2028 | 31/2029 |
| Redis OSS v6 | 31/01/2027 | 1/2/2027 | 1/2/2028 | 1/2/2029 | 31/2030 |
L'Extended Support verrà offerto solo per l'ultima versione patch supportata di ogni versione principale di Redis OSS. Quando Extended Support inizierà il 1° febbraio 2026, se i cluster Redis OSS v4 e v5 non dispongono già delle ultime versioni di patch, verranno aggiornati automaticamente alla versione 4.0.10 per Redis OSS v4 e alla v5.0.6 per Redis OSS v5, prima di essere registrati in Extended Support. Ciò garantisce la ricezione di aggiornamenti di sicurezza e correzioni di bug tramite Extended Support. Non è necessario intraprendere alcuna azione per eseguire l'aggiornamento a queste ultime versioni di patch come parte della transizione Extended Support.
# ElastiCache e responsabilità dei clienti con ElastiCache Extended Support
Di seguito sono elencate le responsabilità di Amazon e ElastiCache le tue responsabilità con ElastiCache Extended Support.
** ElastiCache Responsabilità di Amazon**
Dopo la ElastiCache fine della data di supporto standard, Amazon ElastiCache fornirà patch, correzioni di bug e aggiornamenti per i motori registrati in Extended Support. ElastiCache Ciò avverrà per un massimo di 3 anni o fino a quando non smetterai di usare i motori in Extended Support, a seconda dell'evento che si verifica per primo.
**Le tue responsabilità**
Sei responsabile dell'applicazione delle patch, delle correzioni di bug e degli aggiornamenti forniti per le cache in Extended Support. ElastiCache Amazon ElastiCache si riserva il diritto di modificare, sostituire o ritirare tali patch, correzioni di bug e upgrade in qualsiasi momento. Se è necessaria una patch per risolvere problemi critici di sicurezza o stabilità, Amazon ElastiCache si riserva il diritto di aggiornare le cache con la patch o di richiedere l'installazione della patch.
Sei inoltre responsabile dell'aggiornamento del motore a una versione più recente del motore prima della ElastiCache fine della data di Extended Support. La data di ElastiCache fine del supporto esteso è in genere 3 anni dopo la ElastiCache fine della data di supporto standard.
Se non esegui l'upgrade del motore, dopo la data di ElastiCache fine della data di Extended Support, Amazon ElastiCache tenterà di aggiornare il motore a una versione più recente del motore supportata dal supporto ElastiCache standard. Se l'aggiornamento non riesce, Amazon si ElastiCache riserva il diritto di eliminare la cache su cui è in funzione il motore oltre la data di ElastiCache fine del supporto standard. Tuttavia, prima di farlo, Amazon ElastiCache conserverà i tuoi dati da quel motore.
# Gestione delle versioni per ElastiCache
Gestisci il modo in cui desideri aggiornare le ElastiCache cache e i cluster basati su nodi aggiornati per i motori Valkey, Memcached e Redis OSS.
## Gestione delle versioni per ElastiCache Serverless Cache
Gestisci se e quando la cache ElastiCache Serverless viene aggiornata ed esegui gli aggiornamenti di versione secondo le tue condizioni e tempistiche.
ElastiCache Serverless applica automaticamente la versione più recente del software secondario e delle patch alla cache, senza alcun impatto o tempi di inattività sull'applicazione. Non è richiesta nessuna azione da parte tua.
Quando è disponibile una nuova versione principale, ElastiCache Serverless ti invierà una notifica nella console e un evento in. EventBridge Puoi scegliere di aggiornare la cache all'ultima versione principale utilizzando la console, la CLI o l'API e selezionando la versione più recente del motore. Analogamente agli aggiornamenti minori e alle patch, gli aggiornamenti delle versioni principali vengono eseguiti senza tempi di inattività dell'applicazione.
## Gestione delle versioni per cluster basati su nodi ElastiCache
Quando si lavora con ElastiCache cluster basati su nodi, è possibile controllare quando il software che alimenta il cluster viene aggiornato alle nuove versioni supportate da. ElastiCache Puoi controllare quando aggiornare la cache alle ultime versioni principali, secondarie e patch disponibili. L'utente può eseguire l'aggiornamento a una versione del motore sul cluster o gruppo di replica modificando quest'ultimo e specificando la nuova versione da utilizzare.
È possibile controllare se e quando il software conforme al protocollo che alimenta il cluster viene aggiornato alle nuove versioni supportate da. ElastiCache Questo livello di controllo ti consente di mantenere la compatibilità con versioni specifiche, testare le nuove versioni con l'applicazione prima di distribuirle in produzione e aggiornare le versioni alle tue condizioni e secondo le tue scadenze.
Poiché presentano rischi relativi alla compatibilità, gli aggiornamenti delle versioni non vengono eseguiti automaticamente, ma devono essere avviati manualmente.
**Cluster Valkey e Redis OSS**
**Nota**
Se un cluster Valkey o Redis OSS viene replicato in una o più regioni, la versione del motore viene aggiornata per le regioni secondarie e quindi per la regione principale.
ElastiCache per Redis OSS le versioni sono identificate con una versione semantica che comprende un componente principale e uno secondario. Ad esempio, in Redis OSS 6.2, la versione principale è 6 e la versione secondaria 2. Quando si utilizzano cluster basati su nodi, ElastiCache per Redis OSS espone anche il componente patch, ad esempio Redis OSS 6.2.1, e la versione della patch è 1.
Le versioni principali riguardano modifiche incompatibili con le API e le versioni secondarie riguardano nuove funzionalità aggiunte in modo retrocompatibile. Le versioni patch riguardano correzioni di bug compatibili con le versioni precedenti e modifiche non funzionali.
Con Valkey e Redis OSS, è possibile avviare gli aggiornamenti della versione del motore nel cluster o nel gruppo di replica modificandolo e specificando una nuova versione del motore. Per ulteriori informazioni, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
**Memcached**
Con Memcached, per eseguire l'aggiornamento a una versione più recente è necessario modificare il cluster e specificare la nuova versione del motore che si desidera utilizzare. L'aggiornamento a una versione più recente di Memcached è un processo distruttivo: si perdono i dati e si inizia con una cache a freddo. Per ulteriori informazioni, consulta [Modifica di un cluster ElastiCache](Clusters.Modify.md).
Quando viene eseguito l'aggiornamento da una versione precedente alla versione 1.4.33 o una successiva di Memcached, è importante tenere presente i requisiti riportati di seguito. `CreateCacheCluster` e `ModifyCacheCluster` non riescono nelle condizioni seguenti:
+ Se `slab_chunk_max > max_item_size`.
+ Se `max_item_size modulo slab_chunk_max != 0`.
+ Se `max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4)`.
Il valore `(max_cache_memory - memcached_connections_overhead)` rappresenta la memoria del nodo utilizzabile per i dati. Per ulteriori informazioni, consulta [Sovraccarico delle connessioni Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead).
## Motori e versioni supportati
ElastiCache le cache serverless supportano la ElastiCache versione 7.2 per Valkey e versioni successive, la ElastiCache versione 1.6 per Memcached e versioni successive e la ElastiCache 7.0 per Redis OSS e versioni successive.
ElastiCache I cluster basati su nodi supportano la ElastiCache versione 7.2 per Valkey e versioni successive, la versione 1.4.5 per Memcached e versioni successive e la 4.0.10 per Redis OSS e ElastiCache versioni successive. ElastiCache
**Topics**
+ [Versioni Valkey supportate](#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 versione 7.2.6 per Valkey](#valkey-version-7.2.6)
### Versioni Valkey supportate
Versioni Valkey supportate di seguito. Nota che Valkey supporta per impostazione predefinita la maggior parte delle funzionalità disponibili nella ElastiCache versione 7.2 per Redis OSS.
+ Puoi anche aggiornare i tuoi ElastiCache cluster con versioni precedenti alla 5.0.6. Il processo utilizzato è lo stesso, ma potrebbe richiedere tempi di failover più lunghi durante la propagazione DNS (da 30 secondi a un minuto).
+ A partire da Redis OSS 7, ElastiCache supporta il passaggio tra Valkey o Redis OSS (modalità cluster disabilitata) e Valkey o Redis OSS (modalità cluster abilitata).
+ Il processo di aggiornamento del motore Amazon ElastiCache for Redis OSS è progettato per fare il massimo sforzo per conservare i dati esistenti e richiede una replica Redis OSS di successo.
+ Quando si aggiorna il motore, ElastiCache interromperà le connessioni client esistenti. [Per ridurre al minimo i tempi di inattività durante gli aggiornamenti del motore, consigliamo di implementare [le migliori pratiche per i client Redis OSS](BestPractices.Clients.redis.md) con tentativi di errore e backoff esponenziale, nonché le migliori pratiche per ridurre al minimo i tempi di inattività durante la manutenzione.](BestPractices.MinimizeDowntime.md)
+ Non è possibile eseguire l'aggiornamento direttamente da Valkey o Redis OSS (modalità cluster disabilitata) a Valkey o Redis OSS (modalità cluster abilitata) quando si aggiorna il motore. La procedura seguente mostra come eseguire l'aggiornamento da Valkey o Redis OSS (modalità cluster disabilitata) a Valkey o Redis OSS (modalità cluster abilitata).
**Per eseguire l'aggiornamento da una versione del motore Valkey o Redis OSS (modalità cluster disabilitata) a una versione del motore Valkey o Redis OSS (modalità cluster abilitata)**
1. Effettua un backup del cluster o del gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata). Per ulteriori informazioni, consulta [Esecuzione di backup manuali](backups-manual.md).
1. Usa il backup per creare e seminare un cluster Valkey o Redis OSS (modalità cluster abilitata) con uno shard (gruppo di nodi). Specificare la nuova versione del motore e abilitare la modalità cluster durante la creazione del cluster o gruppo di replica. Per ulteriori informazioni, consulta [Tutorial: Seminare un nuovo cluster basato su nodi con un backup creato esternamente](backups-seeding-redis.md).
1. Elimina il vecchio cluster o gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata). Per ulteriori informazioni, consulta [Eliminazione di un cluster in ElastiCache](Clusters.Delete.md) o [Eliminazione di un gruppo di replica](Replication.DeletingRepGroup.md).
1. Ridimensiona il nuovo cluster o gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) in base al numero di shard (gruppi di nodi) di cui hai bisogno. Per ulteriori informazioni, consulta [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md)
+ Quando si aggiornano le versioni principali del motore, ad esempio da 5.0.6 a 6.0, è necessario scegliere anche un nuovo gruppo di parametri compatibile con la nuova versione del motore.
+ Per i cluster Redis OSS singoli e i cluster con Multi-AZ disattivato, si consiglia di rendere disponibile una quantità di memoria sufficiente per Redis OSS come descritto in. [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md) In condizioni simili, il nodo primario non sarà a disposizione delle richieste di servizi durante la procedura di aggiornamento.
+ Per i cluster Redis OSS con Multi-AZ abilitato, consigliamo inoltre di pianificare gli aggiornamenti del motore durante i periodi di basso traffico di scrittura in entrata. Durante l'aggiornamento a Redis OSS 5.0.6 o versioni successive, il cluster primario continua a essere disponibile per le richieste di assistenza durante il processo di aggiornamento.
I cluster e gruppi di replica con più partizioni vengono elaborati e dotati di patch come di seguito:
+ Tutti le partizioni vengono elaborati in parallelo. Ognle partizioni ammette un'unica operazione di aggiornamento alla volta.
+ In ognle partizioni, tutte le repliche vengono elaborate prima del primario. Se una partizione annovera poche repliche, il suo nodo primario potrebbe giungere alla conclusione dell'elaborazione prima delle repliche negli altrle partizioni.
+ I nodi primari dei varle partizioni vengono elaborati in serie. Viene aggiornato un solo nodo primario alla volta.
+ Se sul cluster o gruppo di replica in uso sono abilitate le crittografie, non è possibile eseguire l'aggiornamento a una versione del motore che non le supporti come ad esempio, da 3.2.6 a 3.2.10.
**Considerazioni su Memcached**
Quando si aggiorna un cluster Memcached basato su nodi, si consideri quanto segue.
+ La gestione della versione del motore è progettata in modo da avere il maggior controllo possibile sulle modalità di applicazione delle patch. Tuttavia, ElastiCache si riserva il diritto di applicare una patch al cluster per conto dell'utente nell'improbabile eventualità che si verifichi una vulnerabilità critica di sicurezza nel sistema o nel software di cache.
+ Poiché il motore Memcached non prevede la persistenza, l'aggiornamento a una particolare versione è sempre un processo radicale, che cancella tutti i dati della cache nel cluster.
### ElastiCache versione 8.2 per Valkey
Ecco alcune delle nuove funzionalità introdotte in Valkey 8.2 (rispetto a ElastiCache Valkey 8.1):
+ Supporto nativo per [Vector Search](vector-search.md), che consente di archiviare, indicizzare, cercare e aggiornare miliardi di incorporamenti vettoriali ad alta dimensione in memoria con latenze di soli microsecondi.
[Per ulteriori informazioni su Valkey, vedere Valkey.](https://valkey.io/)
[Per ulteriori informazioni sulla versione Valkey 8.2, che introduce la ricerca vettoriale, vedi Valkey Search.](https://github.com/valkey-io/valkey-search)
### ElastiCache versione 8.1 per Valkey
Ecco alcune delle nuove funzionalità introdotte in Valkey 8.1 (rispetto a ElastiCache Valkey 8.0):
+ Una [nuova implementazione della tabella hash](https://valkey.io/blog/new-hash-table/) che riduce il sovraccarico di memoria per ridurre l'utilizzo della memoria fino al 20% per i modelli più comuni. key/value
+ Supporto nativo per [i filtri Bloom](https://valkey.io/topics/bloomfilters/), un nuovo tipo di dati che consente di eseguire ricerche utilizzando fino al 98% di memoria in meno rispetto all'utilizzo del tipo di dati Set.
+ Nuovo [comando COMMANDLOG](https://valkey.io/commands/commandlog-get/) che registra esecuzioni lente, richieste di grandi dimensioni e risposte di grandi dimensioni.
+ Nuovo supporto per l'aggiornamento condizionale del comando SET utilizzando l'argomento IFEQ.
+ Miglioramenti delle prestazioni, tra cui una latenza inferiore fino al 45% per il comando ZRANK, prestazioni fino a 12 volte più veloci per PFMERGE e PFCOUNT e un throughput fino al 514% superiore per BITCOUNT.
Per [ulteriori](https://valkey.io/) informazioni su Valkey, vedere Valkey
Per ulteriori informazioni sulla versione Valkey 8.1, vedere le note di rilascio di [Valkey](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES) 8.1
### ElastiCache versione 8.0 per Valkey
Ecco alcune delle nuove funzionalità introdotte in Valkey 8.0 (rispetto a ElastiCache Valkey 7.2.6):
+ Miglioramenti dell'efficienza della memoria, che consentono agli utenti di archiviare fino al 20% in più di dati per nodo senza modifiche all'applicazione.
+ Infrastruttura di metriche per slot introdotta di recente per i cluster basati su nodi, che offre una visibilità dettagliata sulle prestazioni e sull'utilizzo delle risorse dei singoli slot.
+ ElastiCache Serverless for Valkey 8.0 può raddoppiare le richieste al secondo supportate (RPS) ogni 2-3 minuti, raggiungendo 5 milioni di RPS per cache da zero in meno di 13 minuti, con una latenza di lettura p50 costante inferiore al millisecondo.
Per [ulteriori](https://valkey.io/) informazioni su Valkey, vedere Valkey
Per ulteriori informazioni sulla versione Valkey 8, vedere le note di rilascio di [Valkey](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES) 8
### ElastiCache versione 7.2.6 per Valkey
Il 10 ottobre 2024, è stata rilasciata la ElastiCache versione 7.2.6 per Valkey. Ecco alcune delle nuove funzionalità introdotte nella versione 7.2 (rispetto alla ElastiCache versione 7.1 per Redis OSS):
+ Ottimizzazioni delle prestazioni e della memoria per vari tipi di dati: ottimizzazione della memoria per le chiavi list e set type, ottimizzazione della velocità per i comandi di set ordinati, ottimizzazione delle prestazioni per i comandi con più chiavi in modalità cluster, miglioramenti delle prestazioni, ottimizzazione pub/sub delle prestazioni per i comandi SCAN, SSCAN, HSCAN, ZSCAN e numerose altre ottimizzazioni minori.
+ Nuova opzione WITHSCORE per i comandi ZRANK e ZREVRANK
+ CLIENT NO-TOUCH per consentire ai client di eseguire comandi senza influire sui tasti. LRU/LFU
+ Nuovo comando CLUSTER MYSHARDID che restituisce lo Shard ID del nodo per raggruppare logicamente i nodi in modalità cluster in base alla replica.
[Per ulteriori informazioni su Valkey, vedere Valkey](https://valkey.io/)
Per ulteriori informazioni sulla ElastiCache versione 7.2 per la versione Valkey, consultate le [Note di rilascio di Redis OSS 7.2.4 (la versione 7.2](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) per Valkey include tutte le modifiche dalla ElastiCache versione 7.1 per Redis OSS fino alla ElastiCache versione 7.2.4 per Redis OSS). ElastiCache Note [di rilascio di Valkey 7.2 su Valkey on](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES). GitHub
## ElastiCache versione 8.2 per Valkey
Ecco alcune delle nuove funzionalità introdotte in Valkey 8.2 (rispetto a ElastiCache Valkey 8.1):
+ Supporto nativo per [Vector Search](vector-search.md), che consente di archiviare, indicizzare, cercare e aggiornare miliardi di incorporamenti vettoriali ad alta dimensione in memoria con latenze di soli microsecondi.
[Per ulteriori informazioni su Valkey, vedere Valkey.](https://valkey.io/)
[Per ulteriori informazioni sulla versione Valkey 8.2, che introduce la ricerca vettoriale, vedi Valkey Search.](https://github.com/valkey-io/valkey-search)
## ElastiCache versione 8.1 per Valkey
Ecco alcune delle nuove funzionalità introdotte in Valkey 8.1 (rispetto a ElastiCache Valkey 8.0):
+ Una [nuova implementazione della tabella hash](https://valkey.io/blog/new-hash-table/) che riduce il sovraccarico di memoria per ridurre l'utilizzo della memoria fino al 20% per i modelli più comuni. key/value
+ Supporto nativo per [i filtri Bloom](https://valkey.io/topics/bloomfilters/), un nuovo tipo di dati che consente di eseguire ricerche utilizzando fino al 98% di memoria in meno rispetto all'utilizzo del tipo di dati Set.
+ Nuovo [comando COMMANDLOG](https://valkey.io/commands/commandlog-get/) che registra esecuzioni lente, richieste di grandi dimensioni e risposte di grandi dimensioni.
+ Nuovo supporto per l'aggiornamento condizionale del comando SET utilizzando l'argomento IFEQ.
+ Miglioramenti delle prestazioni, tra cui una latenza inferiore fino al 45% per il comando ZRANK, prestazioni fino a 12 volte più veloci per PFMERGE e PFCOUNT e un throughput fino al 514% superiore per BITCOUNT.
Per [ulteriori](https://valkey.io/) informazioni su Valkey, vedere Valkey
Per ulteriori informazioni sulla versione Valkey 8.1, vedere le note di rilascio di [Valkey](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES) 8.1
## ElastiCache versione 8.0 per Valkey
Ecco alcune delle nuove funzionalità introdotte in Valkey 8.0 (rispetto a ElastiCache Valkey 7.2.6):
+ Miglioramenti dell'efficienza della memoria, che consentono agli utenti di archiviare fino al 20% in più di dati per nodo senza modifiche all'applicazione.
+ Infrastruttura di metriche per slot introdotta di recente per i cluster basati su nodi, che offre una visibilità dettagliata sulle prestazioni e sull'utilizzo delle risorse dei singoli slot.
+ ElastiCache Serverless for Valkey 8.0 può raddoppiare le richieste al secondo supportate (RPS) ogni 2-3 minuti, raggiungendo 5 milioni di RPS per cache da zero in meno di 13 minuti, con una latenza di lettura p50 costante inferiore al millisecondo.
Per [ulteriori](https://valkey.io/) informazioni su Valkey, vedere Valkey
Per ulteriori informazioni sulla versione Valkey 8, vedere le note di rilascio di [Valkey](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES) 8
## ElastiCache versione 7.2.6 per Valkey
Il 10 ottobre 2024, è stata rilasciata la ElastiCache versione 7.2.6 per Valkey. Ecco alcune delle nuove funzionalità introdotte nella versione 7.2 (rispetto alla ElastiCache versione 7.1 per Redis OSS):
+ Ottimizzazioni delle prestazioni e della memoria per vari tipi di dati: ottimizzazione della memoria per le chiavi list e set type, ottimizzazione della velocità per i comandi di set ordinati, ottimizzazione delle prestazioni per i comandi con più chiavi in modalità cluster, miglioramenti delle prestazioni, ottimizzazione pub/sub delle prestazioni per i comandi SCAN, SSCAN, HSCAN, ZSCAN e numerose altre ottimizzazioni minori.
+ Nuova opzione WITHSCORE per i comandi ZRANK e ZREVRANK
+ CLIENT NO-TOUCH per consentire ai client di eseguire comandi senza influire sui tasti. LRU/LFU
+ Nuovo comando CLUSTER MYSHARDID che restituisce lo Shard ID del nodo per raggruppare logicamente i nodi in modalità cluster in base alla replica.
[Per ulteriori informazioni su Valkey, vedere Valkey](https://valkey.io/)
Per ulteriori informazioni sulla ElastiCache versione 7.2 per la versione Valkey, consultate le [Note di rilascio di Redis OSS 7.2.4 (la versione 7.2](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) per Valkey include tutte le modifiche dalla ElastiCache versione 7.1 per Redis OSS fino alla ElastiCache versione 7.2.4 per Redis OSS). ElastiCache Note [di rilascio di Valkey 7.2 su Valkey on](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES). GitHub
## Versioni del motore Redis OSS supportate
ElastiCache Le cache serverless e i cluster basati su nodi supportano tutte le versioni Redis OSS 7.1 e precedenti.
+ [ElastiCache versione 7.1 per Redis OSS (migliorata)](#redis-version-7.1)
**Topics**
+ [ElastiCache versione 7.1 per Redis OSS (migliorata)](#redis-version-7.1)
+ [ElastiCache versione 7.0 per Redis OSS (migliorata)](#redis-version-7.0)
+ [ElastiCache versione 6.2 per Redis OSS (migliorata)](#redis-version-6.2)
+ [ElastiCache versione 6.0 per Redis OSS (migliorata)](#redis-version-6.0)
+ [ElastiCache versione 5.0.6 per Redis OSS (migliorata)](#redis-version-5-0.6)
+ [ElastiCache versione 5.0.5 per Redis OSS (deprecata, usa la versione 5.0.6)](#redis-version-5-0.5)
+ [ElastiCache versione 5.0.4 per Redis OSS (deprecata, usa la versione 5.0.6)](#redis-version-5-0.4)
+ [ElastiCache versione 5.0.3 per Redis OSS (deprecata, usa la versione 5.0.6)](#redis-version-5-0.3)
+ [ElastiCache versione 5.0.0 per Redis OSS (obsoleta, usa la versione 5.0.6)](#redis-version-5-0)
+ [ElastiCache versione 4.0.10 per Redis OSS (migliorata)](#redis-version-4-0-10)
+ [Versioni precedenti di fine del ciclo di vita (EOL) (3.x)](#redis-version-3-2-10-scheduled-eol)
+ [Versioni precedenti di fine del ciclo di vita (EOL) (2.x)](#redis-version-2-x-eol)
### ElastiCache versione 7.1 per Redis OSS (migliorata)
Questa versione contiene miglioramenti delle prestazioni che consentono ai carichi di lavoro di aumentare il throughput e ridurre le latenze operative. ElastiCache [la versione 7.1 per Redis OSS introduce due miglioramenti principali:](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/)
Abbiamo esteso la funzionalità avanzata dei I/O thread per gestire anche la logica del livello di presentazione. Per livello di presentazione, intendiamo i thread di I/O avanzati che ora non solo leggono l'input del client, ma analizzano anche l'input nel formato di comando binario Redis OSS. L'input viene quindi inoltrato al thread principale per l'esecuzione, fornendo così un aumento delle prestazioni. Pattern di accesso alla memoria Redis OSS migliorato. Le fasi di esecuzione di molte operazioni sulla struttura dei dati sono interleaved, per garantire l'accesso parallelo alla memoria e una latenza di accesso alla memoria ridotta. Quando utilizzano sistemi basati ElastiCache su Graviton3 `R7g.4xlarge` o versioni successive, i clienti possono raggiungere oltre 1 milione di richieste al secondo per nodo. Con i miglioramenti delle prestazioni apportati a ElastiCache Redis OSS v7.1, i clienti possono ottenere un throughput fino al 100% in più e una latenza P99 inferiore del 50% rispetto a Redis OSS v7.0. ElastiCache Questi miglioramenti sono abilitati su nodi di dimensioni con almeno 8 core fisici (`2xlarge` su Graviton e `4xlarge` su x86), indipendentemente dal tipo di CPU e non richiedono modifiche al client.
**Nota**
ElastiCache la versione 7.1 è compatibile con Redis OSS v7.0.
### ElastiCache versione 7.0 per Redis OSS (migliorata)
ElastiCache per Redis OSS 7.0 aggiunge una serie di miglioramenti e supporto per nuove funzionalità:
+ [Funzioni](https://valkey.io/topics/functions-intro/): ElastiCache per Redis OSS 7 aggiunge il supporto per Redis OSS Functions e offre un'esperienza gestita che consente agli sviluppatori di eseguire [script LUA](https://valkey.io/topics/eval-intro/) con la logica dell'applicazione archiviata nel ElastiCache cluster, senza richiedere ai client di inviare nuovamente gli script al server ad ogni connessione.
+ [Miglioramenti ACL](https://valkey.io/topics/acl/): Valkey e Redis OSS 7 aggiungono il supporto per la prossima versione di Access Control Lists (). ACLs I client possono ora specificare più set di autorizzazioni su chiavi o spazi chiave specifici in Valkey e Redis OSS.
+ [Sharded Pub/Sub](https://valkey.io/topics/pubsub/): ElastiCache per Valkey e Redis OSS 7 aggiunge il supporto per eseguire Pub/Sub functionality in a sharded way when running ElastiCache in Cluster Mode Enabled (CME). Pub/Sub funzionalità che consentono agli editori di inviare messaggi a qualsiasi numero di abbonati su un canale. I canali sono associati a uno shard nel ElastiCache cluster, eliminando la necessità di propagare le informazioni sui canali tra gli shard, con conseguente migliore scalabilità.
+ I/O Multiplexing migliorato: ElastiCache per Valkey e Redis OSS 7 introduce il multiplexing I/O avanzato, che offre un throughput maggiore e una latenza ridotta per carichi di lavoro ad alto throughput con molte connessioni client simultanee a un cluster. ElastiCache Ad esempio, quando si utilizza un cluster di nodi r6g.xlarge e si eseguono 5200 client simultanei, è possibile ottenere un aumento del throughput fino al 72% (operazioni di lettura e scrittura al secondo) e una riduzione della latenza P99 fino al 71%, rispetto alla ElastiCache versione 6 per Redis OSS.
[Per ulteriori informazioni su Valkey, vedere Valkey.](https://valkey.io/) Per ulteriori informazioni sulla versione Redis OSS 7.0, consulta le note di rilascio di [Redis OSS 7.0 su Redis OSS](https://github.com/redis/redis/blob/7.0/00-RELEASENOTES) su. GitHub
### ElastiCache versione 6.2 per Redis OSS (migliorata)
ElastiCache per Redis OSS 6.2 include miglioramenti delle prestazioni per i cluster abilitati a TLS che utilizzano tipi di nodi x86 con 8 v CPUs o più o tipi di nodi Graviton2 con 4 v o più. CPUs Questi miglioramenti migliorano la velocità effettiva e riducono i tempi di creazione della connessione del client affidando la crittografia ad altri v. CPUs Con Redis OSS 6.2, puoi anche gestire l'accesso ai canali Pub/Sub con le regole Access Control List (ACL).
Con questa versione, introduciamo anche il supporto per il tiering dei dati su nodi del cluster contenenti SSD collegati localmente. NVMe Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
La versione 6.2.6 del motore Redis OSS introduce anche il supporto per il formato nativo di JavaScript Object Notation (JSON), un modo semplice e senza schemi per codificare set di dati complessi all'interno dei cluster Redis OSS. Con il supporto JSON, puoi sfruttare le prestazioni e Redis OSS per le applicazioni che funzionano su JSON. APIs Per ulteriori informazioni, consulta [Nozioni di base su JSON](json-gs.md). Sono incluse anche le metriche relative a JSON `JsonBasedCmds` e`JsonBasedCmdsLatency`, che sono incorporate CloudWatch per monitorare l'utilizzo di questo tipo di dati. Per ulteriori informazioni, consulta [Metriche per Valkey e Redis OSS](CacheMetrics.Redis.md).
Si specifica la versione del motore utilizzando 6.2. ElastiCache richiamerà automaticamente la versione patch preferita di Redis OSS 6.2 disponibile. Ad esempio, quando si crea/modifica un cluster, si imposta il parametro su 6.2. `--engine-version` Il cluster verrà avviato con la versione patch preferita attualmente disponibile di Redis OSS 6.2. creation/modification Specificando la versione 6.x del motore nell'API si otterrà l'ultima versione secondaria di Redis OSS 6.
Per i cluster 6.0 esistenti, è possibile attivare il successivo aggiornamento automatico della versione secondaria impostando il `AutoMinorVersionUpgrade` parametro su `yes` in`CreateCacheCluster`, `ModifyCacheCluster` o. `CreateReplicationGroup` `ModifyReplicationGroup` APIs ElastiCache aggiornerà la versione secondaria dei cluster 6.0 esistenti alla 6.2 utilizzando aggiornamenti self-service. Per ulteriori informazioni, consulta [Aggiornamenti self-service in Amazon ElastiCache](Self-Service-Updates.md).
Quando si chiama l' DescribeCacheEngineVersions API, il valore del `EngineVersion` parametro verrà impostato su 6.2 e la versione effettiva del motore con la versione della patch verrà restituita nel `CacheEngineVersionDescription` campo.
Per ulteriori informazioni sulla versione Redis OSS 6.2, consultate le [note di rilascio di Redis OSS 6.2 su Redis OSS](https://github.com/redis/redis/blob/6.2/00-RELEASENOTES) su. GitHub
### ElastiCache versione 6.0 per Redis OSS (migliorata)
Amazon ElastiCache introduce la nuova versione del ElastiCache motore Redis OSS, che include l'[autenticazione degli utenti con il controllo degli accessi basato sui ruoli, la memorizzazione](Clusters.RBAC.md) nella cache lato client e significativi miglioramenti operativi.
A partire da Redis OSS 6.0, ElastiCache offrirà un'unica versione per ogni versione minore di Redis OSS, anziché offrire più versioni di patch. ElastiCache gestirà automaticamente la versione patch dei cluster in esecuzione, garantendo prestazioni migliorate e maggiore sicurezza.
Puoi anche attivare il successivo aggiornamento automatico della versione secondaria impostando il `AutoMinorVersionUpgrade` parametro su `yes` e ElastiCache gestirai l'aggiornamento della versione secondaria tramite aggiornamenti self-service. Per ulteriori informazioni, consulta [Aggiornamenti del servizio in ElastiCache](Self-Service-Updates.md).
È possibile specificare la versione del motore utilizzando. `6.0` ElastiCache richiamerà automaticamente la versione patch preferita di Redis OSS 6.0 disponibile. Ad esempio, se siete create/modify un cluster, impostate il `--engine-version` parametro su 6.0. Il cluster verrà avviato con la versione patch preferita attualmente disponibile di Redis OSS 6.0 al momento della creazione/modifica. Qualsiasi richiesta con un valore di versione secondaria specifico verrà rifiutata, verrà generata un'eccezione e il processo avrà esito negativo.
Quando si chiama l' DescribeCacheEngineVersions API, il valore del `EngineVersion` parametro verrà impostato su 6.0 e nel campo verrà restituita la versione effettiva del motore con la versione della patch. `CacheEngineVersionDescription`
Per ulteriori informazioni sulla versione Redis OSS 6.0, consultate le [note di rilascio di Redis OSS 6.0 su Redis OSS](https://github.com/redis/redis/blob/6.0/00-RELEASENOTES) su. GitHub
### ElastiCache versione 5.0.6 per Redis OSS (migliorata)
Amazon ElastiCache introduce la nuova versione del ElastiCache motore Redis OSS, che include correzioni di bug e i seguenti aggiornamenti cumulativi:
+ Garanzia di stabilità del motore in condizioni speciali.
+ Miglioramento della gestione degli errori di Hyperloglog.
+ Comandi avanzati di handshake per una replica affidabile.
+ Tracciamento costante della consegna dei messaggi tramite il comando `XCLAIM`.
+ Gestione migliorata del campo `LFU `negli oggetti.
+ Gestione migliorata delle transazioni durante l'utilizzo `ZPOP`.
+ Possibilità di rinominare i comandi: un parametro chiamato `rename-commands` che consente di rinominare comandi Redis OSS potenzialmente pericolosi o costosi che potrebbero causare la perdita accidentale di dati, come o. `FLUSHALL` `FLUSHDB` È simile alla configurazione rename-command in Redis OSS open source. Tuttavia, ElastiCache ha migliorato l'esperienza fornendo un flusso di lavoro completamente gestito. Le modifiche al nome del comando vengono applicate immediatamente e propagate automaticamente su tutti i nodi del cluster che contengono l'elenco comandi. Non è richiesto alcun intervento da parte dell'utente, come il riavvio dei nodi.
I seguenti esempi mostrano come modificare i gruppi di parametri esistenti. È incluso il parametro `rename-commands` che è un elenco di comandi separati da spazi da rinominare:
```
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 questo esempio, il parametro *rename-commands* viene utilizzato per rinominare il comando `flushall` in `restrictedflushall`.
Per rinominare più comandi, usa:
```
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
```
Per ripristinare una modifica, esegui nuovamente il comando ed escludi i valori rinominati dall'elenco `ParameterValue` che vuoi conservare, come illustrato di seguito:
```
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 questo caso, il comando `flushall` viene rinominato in `restrictedflushall` e qualsiasi altro comando rinominato riacquista il nome originale.
**Nota**
Quando si rinominano i comandi, si applicano le seguenti limitazioni:
Tutti i comandi rinominati devono essere alfanumerici.
La lunghezza massima dei nuovi nomi di comandi è di 20 caratteri alfanumerici.
Durante la ridenominazione dei comandi, assicurati di aggiornare il gruppo di parametri associato al cluster.
Per impedire completamente l'uso di un comando, usa la parola chiave `blocked`, come indicato di seguito:
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall blocked'" --region region
```
Per ulteriori informazioni sulle modifiche ai parametri e per un elenco dei comandi idonei per la ridenominazione, vedi [Modifiche ai parametri Redis OSS 5.0.3](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3).
+ Redis OSS Streams: modella una struttura di dati di registro che consente ai produttori di aggiungere nuovi elementi in tempo reale. Inoltre consente ai consumatori di utilizzare i messaggi in modo bloccante e non. I flussi consentono i gruppi di consumatori, che rappresentano un gruppo di clienti che consumano cooperativamente diverse parti dello stesso flusso di messaggi, in modo simile ad [Apache Kafka](https://kafka.apache.org/documentation/). [Per ulteriori informazioni, consulta Streams.](https://valkey.io/topics/streams-intro)
+ Support per una famiglia di comandi di flusso come `XADD`, `XRANGE` e `XREAD`. Per ulteriori informazioni, consulta [Streams](https://valkey.io/commands/#stream) Commands.
+ Alcuni parametri nuovi e ridenominati. Per ulteriori informazioni, consulta [Modifiche ai parametri Redis OSS 5.0.0](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0).
+ Una nuova metrica Redis OSS,. `StreamBasedCmds`
+ Tempo di snapshot leggermente più rapido per i nodi Redis OSS.
**Importante**
ElastiCache ha ripristinato due correzioni di bug critici dalla versione open source 5.0.1 di [Redis](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) OSS. Sono elencati qui di seguito:
Risposta di mancata corrispondenza RESTORE quando determinate chiavi sono già scadute.
Il comando `XCLAIM` può potenzialmente restituire una voce errata o desincronizzare il protocollo.
Entrambe queste correzioni di bug sono incluse nel supporto Redis OSS ElastiCache per la versione 5.0.0 del motore Redis OSS e vengono utilizzate negli aggiornamenti delle versioni future.
Per ulteriori informazioni, consulta le note di rilascio di [Redis OSS 5.0.6 su Redis OSS](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) su. GitHub
### ElastiCache versione 5.0.5 per Redis OSS (deprecata, usa la versione 5.0.6)
Amazon ElastiCache introduce la prossima versione di ElastiCache per il motore Redis OSS;. Include modifiche alla configurazione online per i ElastiCache cluster con failover automatico durante tutte le operazioni pianificate. Ora puoi scalare il cluster, aggiornare la versione del motore Redis OSS e applicare patch e aggiornamenti di manutenzione mentre il cluster rimane online e continua a soddisfare le richieste in arrivo. Include anche correzioni di bug.
Per ulteriori informazioni, consulta le [note di rilascio di Redis OSS 5.0.5](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) su Redis OSS su. GitHub
### ElastiCache versione 5.0.4 per Redis OSS (deprecata, usa la versione 5.0.6)
Amazon ElastiCache introduce la prossima versione del motore Redis OSS supportato da. ElastiCache Include i miglioramenti seguenti:
+ Garanzia di stabilità del motore in condizioni speciali.
+ Miglioramento della gestione degli errori di Hyperloglog.
+ Comandi avanzati di handshake per una replica affidabile.
+ Tracciamento costante della consegna dei messaggi tramite il comando `XCLAIM`.
+ Gestione migliorata del campo `LFU `negli oggetti.
+ Gestione migliorata delle transazioni durante l'utilizzo `ZPOP`.
Per ulteriori informazioni, consulta le [note di rilascio di Redis OSS 5.0.4](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) su Redis OSS su. GitHub
### ElastiCache versione 5.0.3 per Redis OSS (deprecata, usa la versione 5.0.6)
Amazon ElastiCache introduce la prossima versione del ElastiCache motore Redis OSS, che include correzioni di bug.
### ElastiCache versione 5.0.0 per Redis OSS (obsoleta, usa la versione 5.0.6)
Amazon ElastiCache introduce la prossima versione principale del motore ElastiCache Redis OSS. ElastiCache la versione 5.0.0 per Redis OSS supporta i seguenti miglioramenti:
+ Redis OSS Streams: modella una struttura di dati di log che consente ai produttori di aggiungere nuovi elementi in tempo reale. Inoltre consente ai consumatori di utilizzare i messaggi in modo bloccante e non. I flussi consentono i gruppi di consumatori, che rappresentano un gruppo di clienti che consumano cooperativamente diverse parti dello stesso flusso di messaggi, in modo simile ad [Apache Kafka](https://kafka.apache.org/documentation/). [Per ulteriori informazioni, consulta Streams.](https://valkey.io/topics/streams-intro)
+ Support per una famiglia di comandi di flusso come `XADD`, `XRANGE` e `XREAD`. Per ulteriori informazioni, consulta [Streams](https://valkey.io/commands/#stream) Commands.
+ Alcuni parametri nuovi e ridenominati. Per ulteriori informazioni, consulta [Modifiche ai parametri Redis OSS 5.0.0](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0).
+ Una nuova metrica Redis OSS,. `StreamBasedCmds`
+ Tempo di snapshot leggermente più rapido per i nodi Redis OSS.
### ElastiCache versione 4.0.10 per Redis OSS (migliorata)
Amazon ElastiCache introduce la prossima versione principale del motore ElastiCache Redis OSS. ElastiCache la versione 4.0.10 per Redis OSS supporta i seguenti miglioramenti:
+ Ridimensionamento e crittografia dei cluster online in un'unica versione. ElastiCache Per ulteriori informazioni, consulta quanto segue:
+ [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md)
+ [Resharding online per Valkey o Redis OSS (modalità cluster abilitata)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Sicurezza dei dati in Amazon ElastiCache](encryption.md)
+ Alcuni nuovi parametri. Per ulteriori informazioni, consulta [Modifiche ai parametri Redis OSS 4.0.10](ParameterGroups.Engine.md#ParameterGroups.Redis.4-0-10).
+ Support per la famiglia di comandi di memoria, come `MEMORY`. Per ulteriori informazioni, vedere [Comandi](https://valkey.io/commands) (ricerca su MEMO).
+ Support per la deframmentazione della memoria in modalità online e, di conseguenza, un utilizzo più efficiente della memoria e più memoria disponibile per i dati.
+ Support per lavaggi ed eliminazioni asincroni. ElastiCache for Redis OSS supporta comandi come `UNLINK` `FLUSHDB` e da `FLUSHALL` eseguire in un thread diverso dal thread principale. Questo consente di migliorare i tempi di risposta e le prestazioni per le applicazioni liberando la memoria in modo asincrono.
+ Una nuova metrica Redis OSS,. `ActiveDefragHits` Per ulteriori informazioni, consulta [Metrics for](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CacheMetrics.Redis.html) Redis OSS.
Gli utenti Redis OSS (modalità cluster disabilitata) che eseguono la ElastiCache versione 3.2.10 per Redis OSS possono utilizzare la console per aggiornare i propri cluster tramite l'aggiornamento online.
**Confronto tra ElastiCache il ridimensionamento dei cluster e il supporto alla crittografia**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/engine-versions.html)
### Versioni precedenti di fine del ciclo di vita (EOL) (3.x)
#### ElastiCache versione 3.2.10 per Redis OSS (migliorata)
Amazon ElastiCache introduce la prossima versione principale del motore ElastiCache Redis OSS. ElastiCache la versione 3.2.10 per Redis OSS (enhanced) introduce il ridimensionamento online del cluster per aggiungere o rimuovere frammenti dal cluster mentre continua a soddisfare le richieste in arrivo. I/O ElastiCache per Redis OSS 3.2.10 gli utenti dispongono di tutte le funzionalità delle versioni precedenti di Redis OSS tranne la possibilità di crittografare i propri dati. Questa caratteristicaè attualmente disponibile nella versione 3.2.6.
**Confronto delle ElastiCache versioni 3.2.6 e 3.2.10 per Redis OSS**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/engine-versions.html)
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Resharding online per Valkey o Redis OSS (modalità cluster abilitata)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Ridimensionamento di cluster online](best-practices-online-resharding.md)
#### ElastiCache versione 3.2.6 per Redis OSS (migliorata)
Amazon ElastiCache introduce la prossima versione principale del motore ElastiCache Redis OSS. ElastiCache la versione 3.2.6 per Redis OSS gli utenti hanno accesso a tutte le funzionalità delle versioni precedenti di Redis OSS, oltre alla possibilità di crittografare i propri dati. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [ElastiCache crittografia in transito (TLS)](in-transit-encryption.md)
+ [Crittografia At-Rest in ElastiCache](at-rest-encryption.md)
+ [Convalida della conformità per Amazon ElastiCache](elasticache-compliance.md)
#### ElastiCache versione 3.2.4 per Redis OSS (migliorata)
ElastiCache La versione 3.2.4 di Amazon introduce la prossima versione principale del motore ElastiCache Redis OSS. ElastiCache *3.2.4 gli utenti hanno a disposizione tutte le funzionalità delle versioni precedenti di Redis OSS, oltre alla possibilità di eseguire in modalità cluster o non *cluster*.* La tabella seguente funge da riepilogo.
**Confronto tra la modalità non cluster di Redis OSS 3.2.4 e la modalità cluster**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/engine-versions.html)
**Note:**
+ **Partizionamento**: La possibilità di ripartire i dati tra un minimo di 2 e un massimo di 500 gruppi di nodi (partizioni), con il support della replica per ciascun gruppo di nodi.
+ Indicizzazione **geospaziale: Redis OSS 3.2.4 introduce il supporto per l'indicizzazione** geospaziale tramite sei comandi GEO. [Per ulteriori informazioni, consulta la documentazione del comando Redis OSS GEO\$1 Commands: GEO nella pagina Valkey Commands (filtrata per GEO).](http://valkey.io/commands#geo)
[Per informazioni sulle funzionalità aggiuntive di Redis OSS 3, consultate le note di rilascio di Redis OSS [3.2 e le note di rilascio di Redis OSS](https://github.com/redis/redis/blob/3.2/00-RELEASENOTES) 3.0.](https://github.com/redis/redis/blob/3.0/00-RELEASENOTES)
Valkey o Redis OSS attualmente ElastiCache gestiti (modalità cluster abilitata) non supportano le seguenti funzionalità di Redis OSS 3.2:
+ Migrazione di repliche
+ Ribilanciamento di cluster
+ Debugger Lua
ElastiCache disabilita i seguenti comandi di gestione Redis OSS 3.2:
+ `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`
Per informazioni sui parametri Redis OSS 3.2.4, vedere. [Modifiche ai parametri Redis OSS 3.2.4](ParameterGroups.Engine.md#ParameterGroups.Redis.3-2-4)
### Versioni precedenti di fine del ciclo di vita (EOL) (2.x)
#### ElastiCache versione 2.8.24 per Redis OSS (migliorata)
I miglioramenti di Redis OSS aggiunti dalla versione 2.8.23 includono correzioni di bug e registrazione di indirizzi di accesso errati alla memoria. Per ulteriori informazioni, consulta le note di rilascio di [Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
#### ElastiCache versione 2.8.23 per Redis OSS (migliorata)
I miglioramenti di Redis OSS aggiunti dalla versione 2.8.22 includono correzioni di bug. Per ulteriori informazioni, consulta le note di rilascio di [Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES). Questa versione include, tra l'altro, il support per il nuovo parametro `close-on-slave-write` che, se abilitato, disconnette i client che tentano di scrivere in una replica di sola lettura.
Per ulteriori informazioni sui parametri Redis OSS 2.8.23, [Parametri aggiunti per Redis OSS 2.8.23 (migliorato)](ParameterGroups.Engine.md#ParameterGroups.Redis.2-8-23) consultate la Guida per l'utente. ElastiCache
#### ElastiCache versione 2.8.22 per Redis OSS (migliorata)
I miglioramenti di Redis OSS aggiunti dalla versione 2.8.21 includono quanto segue:
+ Support per sincronizzazioni e backup senza fork, che permettono di allocare meno memoria per la gestione dei backup e più, invece, per l'applicazione. Per ulteriori informazioni, consulta [Modalità di implementazione di sincronizzazione e backup](Replication.Redis.Versions.md). L'elaborazione senza fork può influire su latenza e throughput. Nel caso di un elevato throughput di scrittura, al momento del riavvio della sincronizzazione e per tutta la sua durata, una replica può non essere raggiungibile.
+ In caso di failover, i gruppi di replica ora vengono ripristinati più velocemente perché, se possibile, le repliche eseguono sincronizzazioni parziali anziché complete con il nodo primario. Si guadagna ulteriormente in rapidità perché, inoltre, sia il primario che le repliche non utilizzano più il disco durante le sincronizzazioni.
+ Support per due nuove CloudWatch metriche.
+ `ReplicationBytes`:- Il numero di byte che il cluster primario di un gruppo di replica invia alle repliche di lettura.
+ `SaveInProgress` - Un valore binario che indica se sia in esecuzione o meno un processo di salvataggio in background.
Per ulteriori informazioni, consulta [Monitoraggio dell'utilizzo con CloudWatch Metrics](CacheMetrics.md).
+ Varie correzioni di bug critici nel comportamento della PSYNC di replica. Per ulteriori informazioni, consultate le note di [rilascio di Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
+ Per mantenere prestazioni di replica migliorate nei gruppi di replica Multi-AZ e per una maggiore stabilità del cluster, le non ElastiCache repliche non sono più supportate.
+ Per affinare la coerenza dei dati tra il cluster primario e le repliche in un gruppo di replica, le repliche non eliminano più le chiavi indipendenti dal cluster principale.
+ Le variabili di configurazione Redis OSS `appendonly` e non `appendfsync` sono supportate su Redis OSS versione 2.8.22 e successive.
+ In caso di memoria insufficiente, i client con un buffer di output consistente possono essere disconnessi da un cluster di replica. Se disconnesso, il client deve riconnettersi. Situazioni simili si verificano più frequentemente con i client PUBSUB.
#### ElastiCache versione 2.8.21 per Redis OSS
I miglioramenti di Redis OSS aggiunti dalla versione 2.8.19 includono una serie di correzioni di bug. Per ulteriori informazioni, consulta le note di rilascio di [Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
#### ElastiCache versione 2.8.19 per Redis OSS
I miglioramenti di Redis OSS aggiunti dalla versione 2.8.6 includono quanto segue:
+ Support per HyperLogLog. Per ulteriori informazioni, consulta la [nuova struttura dati di Redis OSS: HyperLogLog](http://antirez.com/news/75).
+ I dati basati su set ordinati estendono il support alle query di intervallo lessicografiche con i nuovi comandi `ZRANGEBYLEX`, `ZLEXCOUNT` e `ZREMRANGEBYLEX`.
+ Per impedire che un nodo primario invii dati non aggiornati ai nodi di replica, la sincronizzazione del master si blocca quando un processo di salvataggio in background (`bgsave`) figlio si interrompe.
+ Support per la *HyperLogLogBasedCommands* CloudWatchmetrica. Per ulteriori informazioni, consulta [Metriche per Valkey e Redis OSS](CacheMetrics.Redis.md).
#### ElastiCache versione 2.8.6 per Redis OSS
I miglioramenti di Redis OSS aggiunti dalla versione 2.6.13 includono quanto segue:
+ Resilienza e tolleranza ai guasti migliorate per le repliche di lettura.
+ Support per la risincronizzazione parziale.
+ Support per un numero minimo definito dall'utente di repliche di lettura che devono essere sempre disponibili.
+ Support completo per pub/sub-notifica ai client degli eventi sul server.
+ Rilevamento automatico di un errore del nodo primario e failover di quest'ultimo con un nodo secondario.
#### ElastiCache versione 2.6.13 per Redis OSS
ElastiCache la versione 2.6.13 per Redis OSS era la versione iniziale che supportava Redis OSS. ElastiCache Multi-AZ non è supportato nella ElastiCache versione 2.6.13 per Redis OSS.
## ElastiCache versioni per la pianificazione di fine del ciclo di vita di Redis OSS
Questa sezione definisce le date di fine vita (EOL) per le versioni principali precedenti mano a mano che vengono annunciate. Ciò consente di prendere decisioni future sulla versione e sugli aggiornamenti.
**Nota**
ElastiCache le versioni da 5.0.0 a 5.0.5 per Redis OSS sono obsolete. Usa versione 5.0.6 o successiva.
La tabella seguente mostra la pianificazione dell'[Extended Support](extended-support.md) ElastiCache per i motori Redis OSS.
**Extended Support e programma di fine vita**
| Versione principale del motore | Fine del supporto standard | Inizio dell'Extended Support Y1 Premium | Inizio dell'Extended Support Y2 Premium | Inizio dell'Extended Support Y3 Premium | Fine dell'Extended Support e della versione EOL |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 31/01/2026 | 1/2/2026 | 1/2/2027 | 1/2/2028 | 31/2029 |
| Redis OSS v5 | 31/01/2026 | 1/2/2026 | 1/2/2027 | 1/2/2028 | 31/2029 |
| Redis OSS v6 | 31/01/2027 | 1/2/2027 | 1/2/2028 | 1/2/2029 | 31/2030 |
La tabella seguente riepiloga ogni versione e la relativa data di fine vita annunciata, nonché la versione di destinazione dell'aggiornamento consigliata.
**EOL precedenti**
| Versione principale di origine | Versioni secondarie di origine | Destinazione aggiornamento consigliata | Data di fine vita |
| --- | --- | --- | --- |
| Versione 3 | 3.2.4, 3.2.6 e 3.2.10 | Versione 6.2 o successiva Per le regioni US-ISO-EAST -1, US-ISO-WEST -1 e US-ISOB-EAST -1, consigliamo la versione 5.0.6 o successiva. | 31 luglio 2023 |
| Versione 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 | Versione 6.2 o successiva Per le US-ISO-EAST regioni -1 US-ISO-WEST, -1 US-ISOB-EAST e -1, consigliamo la versione 5.0.6 o superiore. | 13 gennaio 2023 |
## Supportato ElastiCache per le versioni Memcached
ElastiCache supporta le seguenti versioni di Memcached e l'aggiornamento a versioni più recenti. Per effettuare l'aggiornamento a una versione più recente, occorre prestare particolare attenzione alle condizioni che, se non soddisfatte, ne possono causare la mancata esecuzione.
**Topics**
+ [ElastiCache versione 1.6.22 per Memcached](#memcached-version-1-6-22)
+ [ElastiCache versione 1.6.17 per Memcached](#memcached-version-1-6-17)
+ [ElastiCache versione 1.6.12 per Memcached](#memcached-version-1-6-12)
+ [ElastiCache versione 1.6.6 per Memcached](#memcached-version-1-6-6)
+ [ElastiCache versione 1.5.16 per Memcached](#memcached-version-1-5-16)
+ [ElastiCache versione 1.5.10 per Memcached](#memcached-version-1-5-10)
+ [ElastiCache versione 1.4.34 per Memcached](#memcached-version-1-4-34)
+ [ElastiCache versione 1.4.33 per Memcached](#memcached-version-1-4-33)
+ [ElastiCache versione 1.4.24 per Memcached](#memcached-version-1-4-24)
+ [ElastiCache versione 1.4.14 per Memcached](#memcached-version-1-4-14)
+ [ElastiCache versione 1.4.5 per Memcached](#memcached-version-1-4-5)
### ElastiCache versione 1.6.22 per Memcached
ElastiCache per la versione 1.6.22 di Memcached per Memcached aggiunge il supporto per la versione 1.6.22 di Memcached. Non include nuove funzionalità, ma include correzioni di bug e aggiornamenti cumulativi da [Memcached 1.6.18](https://github.com/memcached/memcached/wiki/ReleaseNotes1618).
[Per ulteriori informazioni, vedere 1622 su Memcached on. ReleaseNotes](https://github.com/memcached/memcached/wiki/ReleaseNotes1622) GitHub
### ElastiCache versione 1.6.17 per Memcached
ElastiCache per la versione 1.6.17 di Memcached per Memcached aggiunge il supporto per la versione 1.6.17 del motore Memcached. Non include nuove funzionalità, ma include correzioni di bug e aggiornamenti cumulativi da [Memcached 1.6.17](https://github.com/memcached/memcached/wiki/ReleaseNotes1617).
[Per ulteriori informazioni, vedere 1617 su Memcached on. ReleaseNotes](https://github.com/memcached/memcached/wiki/ReleaseNotes1617) GitHub
### ElastiCache versione 1.6.12 per Memcached
ElastiCache per Memcached la versione 1.6.12 per Memcached aggiunge il supporto per il motore Memcached 1.6.12 e la crittografia in transito. Inoltre, include correzioni di bug e aggiornamenti cumulativi da [Memcached 1.6.6](https://github.com/memcached/memcached/wiki/ReleaseNotes166).
Per ulteriori informazioni, [ReleaseNotesvedere 1612](https://github.com/memcached/memcached/wiki/ReleaseNotes1612) su GitHub Memcached on.
### ElastiCache versione 1.6.6 per Memcached
ElastiCache per Memcached la versione 1.6.6 per Memcached aggiunge il supporto per la versione 1.6.6 di Memcached. [Non include nuove funzionalità, ma include correzioni di bug e aggiornamenti cumulativi da Memcached 1.5.16.](https://github.com/memcached/memcached/wiki/ReleaseNotes1.5.16) ElastiCache [per Memcached non include il supporto per Extstore.](https://memcached.org/extstore)
Per ulteriori informazioni, vedere [ReleaseNotes166](https://github.com/memcached/memcached/wiki/ReleaseNotes166) su Memcached on. GitHub
### ElastiCache versione 1.5.16 per Memcached
ElastiCache la versione 1.5.16 per Memcached aggiunge il supporto per la versione 1.5.16 di Memcached. Non include nuove caratteristiche, ma include correzioni di bug e aggiornamenti cumulativi da [Memcached 1.5.14](https://github.com/memcached/memcached/wiki/ReleaseNotes1514) e [Memcached 1.5.15](https://github.com/memcached/memcached/wiki/ReleaseNotes1515).
[Per ulteriori informazioni, vedere le note di rilascio di Memcached 1.5.16 su Memcached su.](https://github.com/memcached/memcached/wiki/ReleaseNotes1516) GitHub
### ElastiCache versione 1.5.10 per Memcached
ElastiCache la versione 1.5.10 per Memcached supporta le seguenti funzionalità di Memcached:
+ Ribilanciamento automatizzato dell'allocazione.
+ Ricerche più rapide nella tabella hash con l'algoritmo `murmur3`.
+ Algoritmo LRU segmentato.
+ Crawler LRU alla memoria di recupero in background.
+ `--enable-seccomp`: un'opzione della fase di compilazione.
Introduce anche i parametri `no_modern` e `inline_ascii_resp`. Per ulteriori informazioni, consulta [Modifiche dei parametri di Memcached 1.5.10](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-5-10).
I miglioramenti di Memcached aggiunti dalla versione 1.4.34 per Memcached includono quanto segue ElastiCache :
+ Correzioni cumulative come ASCII multiget, CVE-2017-9951 e crawl dei limiti per `metadumper`.
+ Migliore gestione delle connessioni mediante la chiusura delle connessioni una volta raggiunto il limite di connessioni.
+ Gestione migliorata delle dimensioni per elementi di dimensioni maggiori di 1 MB.
+ Migliori prestazioni e miglioramenti del sovraccarico di memoria mediante la riduzione di qualche byte dei requisiti di memoria per voce.
Per ulteriori informazioni, vedere le note di rilascio di Memcached 1.5.10 su [Memcached](https://github.com/memcached/memcached/wiki/ReleaseNotes1510) su. GitHub
### ElastiCache versione 1.4.34 per Memcached
ElastiCache la versione 1.4.34 per Memcached non aggiunge nuove funzionalità alla versione 1.4.33. La 1.4.34 è una versione di correzione dei bug più estesa del solito.
Per ulteriori informazioni, vedere le note di rilascio di Memcached 1.4.34 su [Memcached](https://github.com/memcached/memcached/wiki/ReleaseNotes1434) su. GitHub
### ElastiCache versione 1.4.33 per Memcached
I miglioramenti aggiunti dalla versione 1.4.24 includono quanto segue:
+ Capacità di esecuzione del dump dei metadati afferenti a una classe, un elenco di classi o tutte le classi di slab. Per ulteriori informazioni, consulta le [note di rilascio di Memcached 1.4.31](https://github.com/memcached/memcached/wiki/ReleaseNotes1431).
+ Support migliorato per elementi di grandi dimensioni, superiori al megabyte di default. Per ulteriori informazioni, consulta le [note di rilascio di Memcached 1.4.29](https://github.com/memcached/memcached/wiki/ReleaseNotes1429).
+ Capacità di stabilire quanto tempo un client può rimanere inattivo prima che ne venga richiesta la chiusura.
Capacità di aumentare dinamicamente la quantità di memoria disponibile per Memcached senza dover riavviare il cluster. Per ulteriori informazioni, consulta le [note di rilascio di Memcached 1.4.27](https://github.com/memcached/memcached/wiki/ReleaseNotes1427).
+ Registrazione di `fetchers`, `mutations` ed `evictions` ora supportata. Per ulteriori informazioni, consulta le [note di rilascio di Memcached 1.4.26](https://github.com/memcached/memcached/wiki/ReleaseNotes1426).
+ Memoria liberata recuperabile in un pool globale e riassegnabile a nuove classi di slab. Per ulteriori informazioni, consulta le [note di rilascio di Memcached 1.4.25](https://github.com/memcached/memcached/wiki/ReleaseNotes1425).
+ Risoluzione di vari bug.
+ Nuovi comandi e parametri. Per un elenco, consulta [Parametri di Memcached 1.4.33 aggiunti](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-33).
### ElastiCache versione 1.4.24 per Memcached
I miglioramenti aggiunti dalla versione 1.4.14 includono quanto segue:
+ Gestione della cache utilizzata meno di recente (LRU) come attività in background.
+ Possibilità di utilizzo di *jenkins* o *murmur3* come algoritmo hash.
+ Nuovi comandi e parametri. Per un elenco, consulta [Parametri di Memcached 1.4.24 aggiunti](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-24).
+ Risoluzione di vari bug.
### ElastiCache versione 1.4.14 per Memcached
I miglioramenti aggiunti dalla versione 1.4.5 includono quanto segue:
+ Capacità potenziata di ribilanciamento dell'allocazione.
+ Miglioramenti nelle prestazioni e nella scalabilità.
+ Introduzione del comando *touch*, utile per aggiornare la scadenza di un elemento esistente senza il recupero.
+ Auto discovery - consente ai programmi client di identificare automaticamente tutti i nodi cache in un cluster e di avviare e mantenere le connessioni a tutti questi nodi.
### ElastiCache versione 1.4.5 per Memcached
ElastiCache la versione 1.4.5 per Memcached era il motore e la versione iniziali supportati da Amazon ElastiCache per Memcached.
# Principali differenze di comportamento e compatibilità della versione del motore con Valkey
Valkey 7.2.6 presenta differenze di compatibilità simili con le versioni precedenti di Redis OSS 7.2.4. Per la versione più recente supportata di Valkey, vedi. [Motori e versioni supportati](VersionManagement.md#supported-engine-versions)
[Per ulteriori informazioni sulla versione Valkey 7.2, consulta le [note di rilascio di Redis OSS 7.2.4 (Valkey 7.2 include tutte le modifiche da Redis OSS fino alla versione 7.2.4) e le note di rilascio](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) di Valkey 7.2 su Valkey su.](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) GitHub
Ecco le modifiche comportamentali potenzialmente irreversibili tra Valkey 7.2 e Redis OSS 7.1 (o 7.0):
+ Il freeze time sampling avviene durante l'esecuzione dei comandi e negli script.
+ Un comando di stream bloccato rilasciato quando la chiave non esiste più riporta un codice di errore diverso (-NOGROUP o -WRONGTYPE anziché -UNBLOCKED).
+ Il tracciamento degli script lato client ora tiene traccia delle chiavi lette dallo script, anziché delle chiavi dichiarate dal chiamante di EVAL/FCALL.
# Principali differenze di comportamento e compatibilità della versione del motore con Redis OSS
**Importante**
La pagina seguente è strutturata per indicare tutte le differenze di incompatibilità tra le versioni e informare l'utente di eventuali considerazioni da fare durante l'aggiornamento alle versioni più recenti. Questo elenco include tutti i problemi di incompatibilità delle versioni che potrebbero verificarsi durante l'aggiornamento.
È possibile eseguire l'aggiornamento direttamente dalla versione corrente di Redis OSS all'ultima versione Redis OSS disponibile, senza la necessità di aggiornamenti sequenziali. Ad esempio, è possibile eseguire l'aggiornamento direttamente dalla versione 3.0 di Redis OSS alla versione 7.0.
Le versioni Redis OSS sono identificate con una versione semantica che comprende un componente principale, secondario e patch. Ad esempio, in Redis OSS 4.0.10, la versione principale è 4, la versione secondaria 0 e la versione patch è 10. Questi valori generalmente vengono incrementati in base alle convenzioni seguenti:
+ Le versioni principali riguardano modifiche incompatibili con l'API
+ Le versioni secondarie riguardano nuove funzionalità aggiunte in modo retrocompatibile
+ Le versioni patch riguardano correzioni di bug compatibili con le versioni precedenti e modifiche non funzionali
Consigliamo di utilizzare sempre l'ultima versione della patch all'interno di una determinata versione **maggiore.minor** per avere gli ultimi miglioramenti in termini di prestazioni e stabilità. A partire dalla ElastiCache versione 6.0 per Redis OSS, ElastiCache offriremo un'unica versione per ogni versione secondaria di Redis OSS anziché offrire più versioni di patch. ElastiCachegestirà automaticamente la versione patch dei cluster in esecuzione, garantendo prestazioni migliorate e maggiore sicurezza.
È preferibile, inoltre, eseguire periodicamente l'aggiornamento all'ultima versione principale, siccome la maggior parte dei miglioramenti principali non viene ripristinata alle versioni precedenti. Poiché ElastiCache estende la disponibilità a una nuova AWS regione, ElastiCache for Redis OSS supporta le due versioni **major.minor** più recenti in quel momento per la nuova regione. ****Ad esempio, se viene lanciata una nuova AWS regione e le ultime versioni major.minor per Redis OSS sono **7.0 e 6.2, ElastiCache supporterà ElastiCache le versioni Redis OSS 7.0** e **6.2** nella nuova regione.****AWS Man mano che verranno rilasciate le nuove versioni major.minor di Redis OSS, continuerà ad aggiungere ElastiCache il supporto per le versioni appena rilasciate. ElastiCache Per ulteriori informazioni sulla scelta delle regioni per ElastiCache, consulta Scelta delle regioni e delle zone di [disponibilità](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/RegionsAndAZs.html#SupportedRegions).
Quando esegui un aggiornamento che include versioni principali o secondarie, prendi in considerazione il seguente elenco, che include il comportamento e le modifiche retrocompatibili rilasciate con Redis OSS nel tempo.
## Comportamento di Redis OSS 7.0 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di [Redis](https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES) OSS 7.0.
+ `SCRIPT LOAD` e `SCRIPT FLUSH` non sono più propagati alle repliche. Se hai bisogno di una certa durabilità per gli script, ti consigliamo di prendere in considerazione l'utilizzo delle funzioni [Redis](https://valkey.io/topics/functions-intro/) OSS.
+ I canali Pubsub sono ora bloccati per impostazione predefinita per i nuovi utenti ACL.
+ Il comando `STRALGO` è stato sostituito con il comando `LCS`.
+ Il formato per `ACL GETUSER` è stato modificato in modo che tutti i campi contengano il modello di stringa di accesso standard. Se l'automazione era dovuta all'utilizzo di `ACL GETUSER`, occorre verificare che siano gestiti entrambi i formati.
+ Le categorie ACL per `SELECT`, `WAIT`, `ROLE`, `LASTSAVE`, `READONLY`, `READWRITE` e `ASKING` sono cambiate.
+ Il comando `INFO` mostra ora le statistiche per sottocomando anziché nei comandi del container del livello superiore.
+ I valori restituiti dai comandi `LPOP`, `RPOP`, `ZPOPMIN` e `ZPOPMAX` sono cambiati in determinati casi limite. Se si utilizzano questi comandi, occorre controllare le note di rilascio e valutare se hanno un impatto.
+ I comandi `SORT` e `SORT_RO` richiedono ora l'accesso all'intero keyspace per poter utilizzare gli argomenti `GET` e `BY`.
## Comportamento di Redis OSS 6.2 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di [Redis](https://raw.githubusercontent.com/redis/redis/6.2/00-RELEASENOTES) OSS 6.2.
+ I flag ACL dei comandi `TIME`, `ECHO`, `ROLE` e `LASTSAVE` sono stati modificati. Ciò può causare il rifiuto di comandi precedentemente autorizzati e viceversa.
**Nota**
Nessuno di questi comandi modifica o fornisce accesso ai dati.
+ Quando si esegue l'aggiornamento da Redis OSS 6.0, l'ordine delle key/value coppie restituite da una risposta della mappa a uno script lua viene modificato. Se i tuoi script utilizzano `redis.setresp()` o restituiscono una mappa (novità in Redis OSS 6.0), considera le implicazioni che lo script potrebbe non funzionare durante gli aggiornamenti.
## Comportamento di Redis OSS 6.0 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di [Redis](https://raw.githubusercontent.com/redis/redis/6.0/00-RELEASENOTES) OSS 6.0.
+ Il numero massimo di database consentiti è stato ridotto da 1,2 milioni a 10.000. Il valore predefinito è 16 e sconsigliamo di utilizzare valori molto più grandi di questo poiché abbiamo riscontrato problemi di prestazioni e memoria.
+ Imposta il `AutoMinorVersionUpgrade` parametro su yes e ElastiCache gestirà l'aggiornamento della versione secondaria tramite aggiornamenti self-service. Questa operazione verrà gestita tramite canali standard di notifica dei clienti tramite una campagna di aggiornamento self-service. Per ulteriori informazioni, consulta [Aggiornamenti self-service](Self-Service-Updates.md) in. ElastiCache
## Comportamento di Redis OSS 5.0 e modifiche incompatibili con le versioni precedenti
Per un elenco completo delle modifiche, consulta le note di rilascio di [Redis OSS 5.0](https://raw.githubusercontent.com/redis/redis/5.0/00-RELEASENOTES).
+ Gli script vengono replicati dagli effetti invece di rieseguire lo script sulla replica. Ciò generalmente migliora le prestazioni, ma può aumentare la quantità di dati replicati tra primari e repliche. Esiste un'opzione per ripristinare il comportamento precedente, disponibile solo nella ElastiCache versione 5.0 per Redis OSS.
+ Se si esegue l'aggiornamento da Redis OSS 4.0, alcuni comandi negli script LUA restituiranno gli argomenti in un ordine diverso rispetto alle versioni precedenti. In Redis OSS 4.0, Redis OSS ordina alcune risposte in modo lessografico per rendere le risposte deterministiche, questo ordinamento non viene applicato quando gli script vengono replicati mediante effetti.
+ In Redis OSS 5.0.3 e versioni successive, ElastiCache per Redis OSS trasferirà parte del lavoro di I/O sui core in background su tipi di istanze con più di 4. VCPUs Ciò potrebbe modificare le caratteristiche prestazionali di Redis OSS e modificare i valori di alcune metriche. Per ulteriori informazioni, consulta [Quali parametri è opportuno monitorare?](CacheMetrics.WhichShouldIMonitor.md) per appurare se è necessario modificare le metriche.
## Comportamento di Redis OSS 4.0 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di [Redis OSS 4.0](https://raw.githubusercontent.com/redis/redis/4.0/00-RELEASENOTES).
+ Il registro lento ora registra altri due argomenti, il nome e l'indirizzo del client. Questa modifica dovrebbe essere compatibile con le versioni precedenti a meno che non si faccia esplicitamente affidamento su ogni voce del registro lento contenente 3 valori.
+ Il comando `CLUSTER NODES` ora restituisce un formato lievemente diverso, non compatibile a ritroso. È preferibile che i client non utilizzino questo comando per conoscere i nodi presenti in un cluster, utilizzando invece `CLUSTER SLOTS`.
## EOL precedenti
### Comportamento di Redis OSS 3.2 e modifiche incompatibili con le versioni precedenti
Per un elenco completo delle modifiche, consulta le note di rilascio di [Redis OSS 3.2](https://raw.githubusercontent.com/redis/redis/3.2/00-RELEASENOTES).
+ Non esistono modifiche di compatibilità da richiamare per questa versione.
Per ulteriori informazioni, consulta [ElastiCache versioni per la pianificazione di fine del ciclo di vita di Redis OSS](engine-versions.md#deprecated-engine-versions).
### Comportamento di Redis OSS 2.8 e modifiche retrocompatibili
Per un elenco completo delle modifiche, consulta le note di rilascio di [Redis OSS 2.8](https://raw.githubusercontent.com/redis/redis/2.8/00-RELEASENOTES).
+ A partire da Redis OSS 2.8.22, Redis OSS AOF non è più supportato in Redis OSS. ElastiCache È preferibile utilizzare MemoryDB quando i dati devono essere conservati in modo duraturo.
+ A partire da Redis OSS 2.8.22, ElastiCache per Redis OSS non supporta più il collegamento di repliche ai file primari ospitati all'interno. ElastiCache Durante l'aggiornamento, le repliche esterne verranno scollegate e non potranno ricollegarsi. Si consiglia di utilizzare il caching lato client, reso disponibile in Redis OSS 6.0 come alternativa alle repliche esterne.
+ I comandi `TTL` e `PTTL` ora restituiscono -2 se la chiave non esiste e -1 se esiste ma non ha una scadenza associata. Redis OSS 2.6 e versioni precedenti restituivano -1 per entrambe le condizioni.
+ `SORT` con `ALPHA` ora ordina in base alle impostazioni locali di confronto se non viene utilizzata alcuna opzione `STORE`.
Per ulteriori informazioni, consulta [ElastiCache versioni per la pianificazione di fine del ciclo di vita di Redis OSS](engine-versions.md#deprecated-engine-versions).
# Considerazioni sull'aggiornamento quando si lavora con cluster basati su nodi
**Nota**
Le seguenti considerazioni si applicano solo all'aggiornamento di cluster basati su nodi. Non si applicano a Serverless. ElastiCache
**Considerazioni su Valkey e Redis OSS**
Quando aggiorni un cluster Valkey o Redis OSS basato su nodi, considera quanto segue.
+ La gestione della versione del motore è progettata in modo da avere il maggior controllo possibile sulle modalità di applicazione delle patch. Tuttavia, ElastiCache si riserva il diritto di applicare una patch al cluster per conto dell'utente nell'improbabile eventualità che si verifichi una vulnerabilità critica di sicurezza nel sistema o nel software di cache.
+ A partire dalla ElastiCache versione 7.2 per Valkey e dalla ElastiCache versione 6.0 per Redis OSS, ElastiCache offrirà un'unica versione per ogni versione minore, anziché offrire più versioni di patch.
+ A partire dalla versione 5.0.6 del motore Redis OSS, puoi aggiornare la versione del cluster con tempi di inattività minimi. Il cluster è disponibile per la lettura durante l'intero aggiornamento ed è disponibile per la scrittura durante la maggior parte della sua durata, eccetto durante l'operazione di failover che dura alcuni secondi.
+ Puoi anche aggiornare i ElastiCache cluster con versioni precedenti alla 5.0.6. Il processo utilizzato è lo stesso, ma potrebbe richiedere tempi di failover più lunghi durante la propagazione DNS (da 30 secondi a un minuto).
+ A partire da Redis OSS 7, ElastiCache supporta il passaggio tra Valkey o Redis OSS (modalità cluster disabilitata) e Valkey o Redis OSS (modalità cluster abilitata).
+ Il processo di aggiornamento del motore Amazon ElastiCache for Redis OSS è progettato per fare il massimo sforzo per conservare i dati esistenti e richiede una replica Redis OSS di successo.
+ Quando si aggiorna il motore, ElastiCache interromperà le connessioni client esistenti. [Per ridurre al minimo i tempi di inattività durante gli aggiornamenti del motore, consigliamo di implementare [le migliori pratiche per i client Redis OSS](BestPractices.Clients.redis.md) con tentativi di errore e backoff esponenziale, nonché le migliori pratiche per ridurre al minimo i tempi di inattività durante la manutenzione.](BestPractices.MinimizeDowntime.md)
+ Non è possibile eseguire l'aggiornamento direttamente da Valkey o Redis OSS (modalità cluster disabilitata) a Valkey o Redis OSS (modalità cluster abilitata) quando si aggiorna il motore. La procedura seguente mostra come eseguire l'aggiornamento da Valkey o Redis OSS (modalità cluster disabilitata) a Valkey o Redis OSS (modalità cluster abilitata).
**Per eseguire l'aggiornamento da una versione del motore Valkey o Redis OSS (modalità cluster disabilitata) a una versione del motore Valkey o Redis OSS (modalità cluster abilitata)**
1. Effettua un backup del cluster o del gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata). Per ulteriori informazioni, consulta [Esecuzione di backup manuali](backups-manual.md).
1. Usa il backup per creare e seminare un cluster Valkey o Redis OSS (modalità cluster abilitata) con uno shard (gruppo di nodi). Specificare la nuova versione del motore e abilitare la modalità cluster durante la creazione del cluster o gruppo di replica. Per ulteriori informazioni, consulta [Tutorial: Seminare un nuovo cluster basato su nodi con un backup creato esternamente](backups-seeding-redis.md).
1. Elimina il vecchio cluster o gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata). Per ulteriori informazioni, consulta [Eliminazione di un cluster in ElastiCache](Clusters.Delete.md) o [Eliminazione di un gruppo di replica](Replication.DeletingRepGroup.md).
1. Ridimensiona il nuovo cluster o gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) in base al numero di shard (gruppi di nodi) di cui hai bisogno. Per ulteriori informazioni, consulta [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md)
+ Quando si aggiornano le versioni principali del motore, ad esempio da 5.0.6 a 6.0, è necessario scegliere anche un nuovo gruppo di parametri compatibile con la nuova versione del motore.
+ Per i cluster Redis OSS singoli e i cluster con Multi-AZ disattivato, si consiglia di rendere disponibile una quantità di memoria sufficiente per Redis OSS come descritto in. [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md) In condizioni simili, il nodo primario non sarà a disposizione delle richieste di servizi durante la procedura di aggiornamento.
+ Per i cluster Redis OSS con Multi-AZ abilitato, consigliamo inoltre di pianificare gli aggiornamenti del motore durante i periodi di basso traffico di scrittura in entrata. Durante l'aggiornamento a Redis OSS 5.0.6 o versioni successive, il cluster primario continua a essere disponibile per le richieste di assistenza durante il processo di aggiornamento.
I cluster e gruppi di replica con più partizioni vengono elaborati e dotati di patch come di seguito:
+ Tutti le partizioni vengono elaborati in parallelo. Ognle partizioni ammette un'unica operazione di aggiornamento alla volta.
+ In ognle partizioni, tutte le repliche vengono elaborate prima del primario. Se una partizione annovera poche repliche, il suo nodo primario potrebbe giungere alla conclusione dell'elaborazione prima delle repliche negli altrle partizioni.
+ I nodi primari dei varle partizioni vengono elaborati in serie. Viene aggiornato un solo nodo primario alla volta.
+ Se sul cluster o gruppo di replica in uso sono abilitate le crittografie, non è possibile eseguire l'aggiornamento a una versione del motore che non le supporti come ad esempio, da 3.2.6 a 3.2.10.
**Considerazioni su Memcached**
Quando si aggiorna un cluster Memcached basato su nodi, si consideri quanto segue.
+ La gestione della versione del motore è progettata in modo da avere il maggior controllo possibile sulle modalità di applicazione delle patch. Tuttavia, ElastiCache si riserva il diritto di applicare una patch al cluster per conto dell'utente nell'improbabile eventualità che si verifichi una vulnerabilità critica di sicurezza nel sistema o nel software di cache.
+ Poiché il motore Memcached non prevede la persistenza, l'aggiornamento a una particolare versione è sempre un processo radicale, che cancella tutti i dati della cache nel cluster.
# ElastiCache migliori pratiche e strategie di caching
Di seguito puoi trovare le best practice consigliate per Amazon ElastiCache. Queste best practice consentono di migliorare prestazioni e affidabilità della cache.
**Topics**
+ [Le migliori pratiche generali](WorkingWithRedis.md)
+ [Procedure consigliate per l'utilizzo delle repliche di lettura](ReadReplicas.md)
+ [Comandi Valkey, Memcached e Redis OSS supportati e limitati](SupportedCommands.md)
+ [Configurazione e limiti di Valkey e Redis OSS](RedisConfiguration.md)
+ [IPv6 esempi di client per Valkey, Memcached e Redis OSS](network-type-best-practices.md)
+ [Le migliori pratiche per i clienti (Valkey e Redis OSS)](BestPractices.Clients.redis.md)
+ [Le migliori pratiche per i clienti (Memcached)](BestPractices.Clients.memcached.md)
+ [Cluster dual ElastiCache stack abilitati per TLS](#network-type-configuring-tls-enabled-dual-stack)
+ [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md)
+ [Procedure consigliate per l'utilizzo di cluster basati su nodi Valkey e Redis OSS](BestPractices.SelfDesigned.md)
+ [Strategie di caching per Memcached](Strategies.md)
# Le migliori pratiche generali
Di seguito puoi trovare informazioni sulle migliori pratiche per l'utilizzo delle interfacce Valkey, Memcached e Redis OSS all'interno. ElastiCache
+ **Usa configurazioni abilitate per la modalità cluster: la modalità cluster abilitata** consente alla cache di scalare orizzontalmente per ottenere uno storage e un throughput più elevati rispetto a una configurazione disabilitata in modalità cluster. ElastiCache serverless è disponibile solo in una configurazione abilitata per la modalità cluster.
+ **Usa connessioni di lunga durata**: la creazione di una nuova connessione è costosa e richiede tempo e risorse della CPU della cache. Riutilizza le connessioni quando possibile (ad esempio con il pool di connessioni) per ammortizzare questo costo rispetto a molti comandi.
+ **Leggi dalle repliche**: se utilizzi sistemi ElastiCache serverless o disponi di repliche di lettura predisposte (cluster basati su nodi), indirizza le letture alle repliche per ottenere una migliore scalabilità, una latenza inferiore. and/or Le letture dalle repliche sono consistenti finali con il nodo primario.
In un cluster basato su nodi, evita di indirizzare le richieste di lettura a una singola replica di lettura, poiché le letture potrebbero non essere temporaneamente disponibili in caso di errore del nodo. Puoi configurare il client per indirizzare le richieste di lettura ad almeno due repliche di lettura oppure indirizzare le letture a una sola replica e al nodo primario.
In modalità ElastiCache serverless, la lettura dalla porta di replica (6380) indirizzerà le letture alla zona di disponibilità locale del client, ove possibile, riducendo la latenza di recupero. Esegue automaticamente il fallback agli altri nodi in caso di errore.
+ **Evita comandi costosi**: evita di eseguire operazioni computazionali e intensive, come i comandi and I/O . `KEYS` `SMEMBERS` Suggeriamo l'utilizzo di questo approccio perché queste operazioni aumentano il carico sul cluster e hanno impatto sulle prestazioni del cluster. Utilizza i comandi `SCAN` e `SSCAN`.
+ **Segui le best practice Lua** - Evita script Lua di lunga durata e dichiara sempre in anticipo le chiavi utilizzate degli script Lua. Consigliamo questo approccio per determinare che lo script Lua non utilizza comandi tra slot. Assicurati che le chiavi utilizzate negli script Lua appartengano allo stesso slot.
+ **Usa sharded pub/sub**: quando usi Valkey o Redis OSS per supportare pub/sub carichi di lavoro con throughput elevato, ti consigliamo di utilizzare [sharded pub/sub](https://valkey.io/topics/pubsub/) (disponibile con Valkey e con Redis OSS 7 o versione successiva). I cluster tradizionali abilitati alla modalità cluster pub/sub trasmettono messaggi a tutti i nodi del cluster, il che può comportare un aumento. `EngineCPUUtilization` Notatelo nei ElastiCache comandi tradizionali senza server. pub/sub commands internally use sharded pub/sub
**Topics**
# Procedure consigliate per l'utilizzo delle repliche di lettura
Molte applicazioni, come gli archivi di sessioni, le classifici e i motori di raccomandazione, richiedono un'elevata disponibilità e gestiscono un numero significativamente maggiore di operazioni di lettura rispetto alle operazioni di scrittura. Queste applicazioni possono spesso tollerare dati leggermente obsoleti (eventuale coerenza), il che significa che è accettabile che utenti diversi visualizzino momentaneamente versioni leggermente diverse degli stessi dati. Esempio:
+ I risultati delle query memorizzate nella cache possono spesso tollerare dati leggermente obsoleti, in particolare per i modelli di cache in cui la fonte della verità è esterna.
+ In una classifica di gioco, un ritardo di qualche secondo nell'aggiornamento dei punteggi spesso non ha un impatto significativo sull'esperienza dell'utente.
+ Per quanto riguarda gli archivi di sessione, alcuni lievi ritardi nella propagazione dei dati della sessione tra le repliche raramente influiscono sulla funzionalità dell'applicazione.
+ I motori di raccomandazione utilizzano in genere l'analisi dei dati storici, quindi la coerenza in tempo reale è meno importante.
La coerenza finale significa che tutti i nodi di replica restituiranno gli stessi dati una volta completato il processo di replica, in genere entro pochi millisecondi. In questi casi d'uso, l'implementazione di repliche di lettura è una strategia efficace per ridurre la latenza durante la lettura dall'istanza. ElastiCache
L'utilizzo di repliche di lettura in Amazon ElastiCache può offrire vantaggi significativi in termini di prestazioni attraverso:
**Scalabilità di lettura migliorata**
+ Distribuisce le operazioni di lettura su più nodi di replica
+ Scarica il traffico di lettura dal nodo primario
+ Riduce la latenza di lettura soddisfacendo le richieste provenienti da repliche geograficamente più vicine
**Prestazioni ottimizzate del nodo primario**
+ Dedica le risorse del nodo principale alle operazioni di scrittura
+ Riduce il sovraccarico di connessione sul nodo primario
+ Migliora le prestazioni di scrittura e mantiene tempi di risposta migliori durante i periodi di picco di traffico
## Utilizzo di Read from Replica in modalità Serverless ElastiCache
ElastiCache serverless fornisce due endpoint diversi, per requisiti di coerenza diversi. I due endpoint utilizzano lo stesso nome DNS ma porte diverse. Per utilizzare la read-from-replica porta, devi autorizzare l'accesso a entrambe le porte dall'applicazione client [configurando i gruppi di sicurezza e gli elenchi di controllo degli accessi alla rete del tuo VPC](set-up.md#elasticache-install-grant-access-VPN).
**Endpoint primario (porta 6379)**
+ Utilizzabile per operazioni che richiedono una coerenza immediata
+ Garantisce la lettura della maggior parte up-to-date dei dati
+ Ideale per transazioni critiche e operazioni di scrittura
+ Necessario per le operazioni di scrittura
+ Ad esempio: `test-12345.serverless.use1.cache.amazonaws.com:6379`
**Endpoint ottimizzato per la latenza (porta 6380)**
+ Ottimizzato per operazioni di lettura che possono tollerare un'eventuale coerenza
+ Quando possibile, la modalità ElastiCache serverless indirizza automaticamente le richieste di lettura al nodo di replica nella zona di disponibilità locale del client. Questa ottimizzazione offre una latenza inferiore evitando la latenza di rete aggiuntiva generata dal recupero dei dati da un nodo in una zona di disponibilità diversa.
+ ElastiCache serverless seleziona automaticamente i nodi disponibili in altre zone se un nodo locale non è disponibile
+ Ad esempio: `test-12345.serverless.use1.cache.amazonaws.com:6380`
+ Client come Glide e Lettuce rileveranno e indirizzeranno automaticamente le letture verso l'endpoint con latenza ottimizzata se si fornisce la configurazione di lettura dalla replica. Se il tuo client non supporta la configurazione del routing (ad esempio, valkey-java e versioni precedenti di jedis), devi definire la porta e la configurazione del client corrette per la lettura dalle repliche.
## Connessione per leggere le repliche in Serverless - Valkey e Glide ElastiCache
Il seguente frammento di codice mostra come configurare la lettura dalla replica per ElastiCache Serverless nella libreria Valkey glide. Non è necessario specificare la porta per la lettura dalle repliche, ma è necessario configurare la configurazione del routing. `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());
}
}
}
}
}
```
# Comandi Valkey, Memcached e Redis OSS supportati e limitati
## Comandi Valkey e Redis OSS supportati
**Comandi Valkey e Redis OSS supportati**
I seguenti comandi Valkey e Redis OSS sono supportati dalle cache serverless. Oltre a questi comandi, sono supportati anche i [Comandi Valkey e Redis OSS supportatiComandi JSON](json-list-commands.md).
Per informazioni sui comandi del filtro Bloom, vedere [Comandi del filtro Bloom](BloomFilters.md#SupportedCommandsBloom)
**Comandi bitmap**
+ `BITCOUNT`
Conta il numero di bit impostati (conteggio della popolazione) in una stringa.
[Ulteriori informazioni](https://valkey.io/commands/bitcount/)
+ `BITFIELD`
Esegue operazioni arbitrarie di numeri interi bitfield sulle stringhe.
[Ulteriori informazioni](https://valkey.io/commands/bitfield/)
+ `BITFIELD_RO`
Esegue operazioni arbitrarie di numeri interi bitfield di sola lettura sulle stringhe.
[Ulteriori informazioni](https://valkey.io/commands/bitfield_ro/)
+ `BITOP`
Esegue operazioni bit per bit su più stringhe e archivia il risultato.
[Ulteriori informazioni](https://valkey.io/commands/bitop/)
+ `BITPOS`
Trova il primo bit di impostazione (1) o cancellazione (0) in una stringa.
[Ulteriori informazioni](https://valkey.io/commands/bitpos/)
+ `GETBIT`
Restituisce un valore di bit per offset.
[Ulteriori informazioni](https://valkey.io/commands/getbit/)
+ `SETBIT`
Imposta o cancella il bit all'offset del valore della stringa. Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/setbit/)
**Comandi di gestione dei cluster**
+ `CLUSTER COUNTKEYSINSLOT`
Restituisce il numero di chiavi in uno slot hash.
[Ulteriori informazioni](https://valkey.io/commands/cluster-countkeysinslot/)
+ `CLUSTER GETKEYSINSLOT`
Restituisce i nomi delle chiavi in uno slot hash.
[Ulteriori informazioni](https://valkey.io/commands/cluster-getkeysinslot/)
+ `CLUSTER INFO`
Restituisce le informazioni sullo stato di un nodo. In una cache serverless, restituisce lo stato della singola "partizione" virtuale esposta al client.
[Ulteriori informazioni](https://valkey.io/commands/cluster-info/)
+ `CLUSTER KEYSLOT`
Restituisce lo slot hash per una chiave.
[Ulteriori informazioni](https://valkey.io/commands/cluster-keyslot/)
+ `CLUSTER MYID`
Restituisce l'ID di un nodo. In una cache serverless, restituisce lo stato della singola "partizione" virtuale esposta al client.
[Ulteriori informazioni](https://valkey.io/commands/cluster-myid/)
+ `CLUSTER NODES`
Restituisce la configurazione del cluster per un nodo. In una cache serverless, restituisce lo stato della singola "partizione" virtuale esposta al client.
[Ulteriori informazioni](https://valkey.io/commands/cluster-nodes/)
+ `CLUSTER REPLICAS`
Elenca i nodi di replica di un nodo principale. In una cache serverless, restituisce lo stato della singola "partizione" virtuale esposta al client.
[Ulteriori informazioni](https://valkey.io/commands/cluster-replicas/)
+ `CLUSTER SHARDS`
Restituisce la mappatura degli slot del cluster alle partizioni. In una cache serverless, restituisce lo stato della singola "partizione" virtuale esposta al client.
[Ulteriori informazioni](https://valkey.io/commands/cluster-shards/)
+ `CLUSTER SLOTS`
Restituisce la mappatura degli slot del cluster ai nodi. In una cache serverless, restituisce lo stato della singola "partizione" virtuale esposta al client.
[Ulteriori informazioni](https://valkey.io/commands/cluster-slots/)
+ `CLUSTER SLOT-STATS`
Consente il tracciamento delle metriche per slot relative al conteggio delle chiavi, all'utilizzo della CPU, ai byte di rete in ingresso e ai byte di rete in uscita.
[Ulteriori informazioni](https://valkey.io/commands/cluster-slot-stats/)
+ `READONLY`
Abilita le query di sola lettura per una connessione a un nodo di replica Valkey o Redis OSS Cluster.
[Ulteriori informazioni](https://valkey.io/commands/readonly/)
+ `READWRITE`
Abilita le query di lettura/scrittura per una connessione a un nodo di replica Valkey o Redis OSS Cluster.
[Ulteriori informazioni](https://valkey.io/commands/readwrite/)
+ `SCRIPT SHOW`
Restituisce il codice sorgente originale di uno script nella cache degli script.
[Ulteriori informazioni](https://valkey.io/commands/script-show/)
**Comandi di gestione della connessione**
+ `AUTH`
Autentica la connessione.
[Ulteriori informazioni](https://valkey.io/commands/auth/)
+ `CLIENT GETNAME`
Restituisce il nome della connessione.
[Ulteriori informazioni](https://valkey.io/commands/client-getname/)
+ `CLIENT REPLY`
Indica al server se rispondere ai comandi.
[Ulteriori informazioni](https://valkey.io/commands/client-reply/)
+ `CLIENT SETNAME`
Imposta il nome della connessione.
[Ulteriori informazioni](https://valkey.io/commands/client-setname/)
+ `ECHO`
Restituisce la specifica stringa.
[Ulteriori informazioni](https://valkey.io/commands/echo/)
+ `HELLO`
Strette di mano con il server Valkey o Redis OSS.
[Ulteriori informazioni](https://valkey.io/commands/hello/)
+ `PING`
Restituisce la risposta di attività del server.
[Ulteriori informazioni](https://valkey.io/commands/ping/)
+ `QUIT`
Chiude la connessione.
[Ulteriori informazioni](https://valkey.io/commands/quit/)
+ `RESET`
Reimposta la connessione.
[Ulteriori informazioni](https://valkey.io/commands/reset/)
+ `SELECT`
Cambia il database selezionato.
[Ulteriori informazioni](https://valkey.io/commands/select/)
**Comandi generici**
+ `COPY`
Copia il valore di una chiave in una nuova chiave.
[Ulteriori informazioni](https://valkey.io/commands/copy/)
+ `DEL`
Elimina una o più chiavi.
[Ulteriori informazioni](https://valkey.io/commands/del/)
+ `DUMP`
Restituisce una rappresentazione serializzata del valore archiviato in una chiave.
[Ulteriori informazioni](https://valkey.io/commands/dump/)
+ `EXISTS`
Determina se esistono una o più chiavi.
[Ulteriori informazioni](https://valkey.io/commands/exists/)
+ `EXPIRE`
Imposta l'ora di scadenza di una chiave in secondi.
[Ulteriori informazioni](https://valkey.io/commands/expire/)
+ `EXPIREAT`
Imposta l'ora di scadenza di una chiave su un timestamp Unix.
[Ulteriori informazioni](https://valkey.io/commands/expireat/)
+ `EXPIRETIME`
Restituisce l'ora di scadenza di una chiave come timestamp Unix.
[Ulteriori informazioni](https://valkey.io/commands/expiretime/)
+ `PERSIST`
Rimuove l'ora di scadenza di una chiave.
[Ulteriori informazioni](https://valkey.io/commands/persist/)
+ `PEXPIRE`
Imposta l'ora di scadenza di una chiave in millisecondi.
[Ulteriori informazioni](https://valkey.io/commands/pexpire/)
+ `PEXPIREAT`
Imposta l'ora di scadenza di una chiave su un timestamp in millisecondi Unix.
[Ulteriori informazioni](https://valkey.io/commands/pexpireat/)
+ `PEXPIRETIME`
Restituisce l'ora di scadenza di una chiave come timestamp in millisecondi Unix.
[Ulteriori informazioni](https://valkey.io/commands/pexpiretime/)
+ `PTTL`
Restituisce l'ora di scadenza di una chiave in millisecondi.
[Ulteriori informazioni](https://valkey.io/commands/pttl/)
+ `RANDOMKEY`
Restituisce un nome di chiave casuale del database.
[Ulteriori informazioni](https://valkey.io/commands/randomkey/)
+ `RENAME`
Rinomina una chiave e sovrascrive la destinazione.
[Ulteriori informazioni](https://valkey.io/commands/rename/)
+ `RENAMENX`
Rinomina una chiave solo quando il nome della chiave di destinazione non esiste.
[Ulteriori informazioni](https://valkey.io/commands/renamenx/)
+ `RESTORE`
Crea una chiave dalla rappresentazione serializzata di un valore.
[Ulteriori informazioni](https://valkey.io/commands/restore/)
+ `SCAN`
Esegue l'iterazione dei nomi delle chiavi nel database.
[Ulteriori informazioni](https://valkey.io/commands/scan/)
+ `SORT`
Ordina gli elementi in un elenco, un set o un set ordinato e archivia facoltativamente il risultato.
[Ulteriori informazioni](https://valkey.io/commands/sort/)
+ `SORT_RO`
Restituisce gli elementi ordinati di un elenco, un set o un set ordinato.
[Ulteriori informazioni](https://valkey.io/commands/sort_ro/)
+ `TOUCH`
Restituisce il numero di chiavi esistenti tra quelle specificate dopo l'aggiornamento dell'ora dell'ultimo accesso.
[Ulteriori informazioni](https://valkey.io/commands/touch/)
+ `TTL`
Restituisce l'ora di scadenza di una chiave in secondi.
[Ulteriori informazioni](https://valkey.io/commands/ttl/)
+ `TYPE`
Determina il tipo di valore archiviato in una chiave.
[Ulteriori informazioni](https://valkey.io/commands/type/)
+ `UNLINK`
Elimina in modo asincrono una o più chiavi.
[Ulteriori informazioni](https://valkey.io/commands/unlink/)
**Comandi geospaziali**
+ `GEOADD`
Aggiunge uno o più membri a un indice geospaziale. La chiave viene creata se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/geoadd/)
+ `GEODIST`
Restituisce la distanza tra due membri di un indice geospaziale.
[Ulteriori informazioni](https://valkey.io/commands/geodist/)
+ `GEOHASH`
Restituisce i membri di un indice geospaziale come stringhe geohash.
[Ulteriori informazioni](https://valkey.io/commands/geohash/)
+ `GEOPOS`
Restituisce la longitudine e la latitudine dei membri di un indice geospaziale.
[Ulteriori informazioni](https://valkey.io/commands/geopos/)
+ `GEORADIUS`
Esegue le query su un indice geospaziale per i membri che si trovano entro una distanza da una coordinata e facoltativamente archivia il risultato.
[Ulteriori informazioni](https://valkey.io/commands/georadius/)
+ `GEORADIUS_RO`
Restituisce i membri di un indice geospaziale che si trovano entro una distanza da una coordinata.
[Ulteriori informazioni](https://valkey.io/commands/georadius_ro/)
+ `GEORADIUSBYMEMBER`
Esegue le query su un indice geospaziale per i membri che si trovano entro una distanza da un membro e facoltativamente archivia il risultato.
[Ulteriori informazioni](https://valkey.io/commands/georadiusbymember/)
+ `GEORADIUSBYMEMBER_RO`
Restituisce i membri di un indice geospaziale che si trovano entro una distanza da un membro.
[Ulteriori informazioni](https://valkey.io/commands/georadiusbymember_ro/)
+ `GEOSEARCH`
Esegue le query su un indice geospaziale per i membri presenti all'interno dell'area di un riquadro o di un cerchio.
[Ulteriori informazioni](https://valkey.io/commands/geosearch/)
+ `GEOSEARCHSTORE`
Esegue le query su un indice geospaziale per i membri presenti all'interno dell'area di un riquadro o di un cerchio e facoltativamente archivia il risultato.
[Ulteriori informazioni](https://valkey.io/commands/geosearchstore/)
**Comandi hash**
+ `HDEL`
Elimina da un hash uno o più campi e i relativi valori. Elimina l'hash se non rimane alcun campo.
[Ulteriori informazioni](https://valkey.io/commands/hdel/)
+ `HEXISTS`
Determina se un campo è presente in un hash.
[Ulteriori informazioni](https://valkey.io/commands/hexists/)
+ `HGET`
Restituisce il valore di un campo in un hash.
[Ulteriori informazioni](https://valkey.io/commands/hget/)
+ `HGETALL`
Restituisce tutti i campi e i valori in un hash.
[Ulteriori informazioni](https://valkey.io/commands/hgetall/)
+ `HINCRBY`
Incrementa di un numero il valore intero di un campo in un hash. Utilizza 0 come valore iniziale se il campo non esiste.
[Ulteriori informazioni](https://valkey.io/commands/hincrby/)
+ `HINCRBYFLOAT`
Incrementa di un numero il valore in virgola mobile di un campo. Utilizza 0 come valore iniziale se il campo non esiste.
[Ulteriori informazioni](https://valkey.io/commands/hincrbyfloat/)
+ `HKEYS`
Restituisce tutti i campi in un hash.
[Ulteriori informazioni](https://valkey.io/commands/hkeys/)
+ `HLEN`
Restituisce il numero di campi in un hash.
[Ulteriori informazioni](https://valkey.io/commands/hlen/)
+ `HMGET`
Restituisce i valori di tutti i campi in un hash.
[Ulteriori informazioni](https://valkey.io/commands/hmget/)
+ `HMSET`
Imposta i valori di più campi.
[Ulteriori informazioni](https://valkey.io/commands/hmset/)
+ `HRANDFIELD`
Restituisce uno o più campi casuali di un hash.
[Ulteriori informazioni](https://valkey.io/commands/hrandfield/)
+ `HSCAN`
Esegue l'iterazione dei campi e dei valori di un hash.
[Ulteriori informazioni](https://valkey.io/commands/hscan/)
+ `HSET`
Crea o modifica il valore di un campo in un hash.
[Ulteriori informazioni](https://valkey.io/commands/hset/)
+ `HSETNX`
Imposta il valore di un campo in un hash solo quando il campo non esiste.
[Ulteriori informazioni](https://valkey.io/commands/hsetnx/)
+ `HSTRLEN`
Restituisce la lunghezza del valore di un campo.
[Ulteriori informazioni](https://valkey.io/commands/hstrlen/)
+ `HVALS`
Restituisce tutti i valori in un hash.
[Ulteriori informazioni](https://valkey.io/commands/hvals/)
**HyperLogLog Comandi**
+ `PFADD`
Aggiunge elementi a una chiave. HyperLogLog Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/pfadd/)
+ `PFCOUNT`
Restituisce la cardinalità approssimativa degli insiemi osservati dalle HyperLogLog chiavi.
[Ulteriori informazioni](https://valkey.io/commands/pfcount/)
+ `PFMERGE`
Unisce uno o più HyperLogLog valori in un'unica chiave.
[Ulteriori informazioni](https://valkey.io/commands/pfmerge/)
**Comandi di elenco**
+ `BLMOVE`
Visualizza l'elemento di un elenco, lo inserisce in un altro elenco e lo restituisce. Si blocca finché un elemento non è disponibile. Elimina l'elenco se l'ultimo elemento è stato spostato.
[Ulteriori informazioni](https://valkey.io/commands/blmove/)
+ `BLMPOP`
Visualizza il primo elemento da uno degli elenchi. Si blocca finché un elemento non è disponibile. Elimina l'elenco se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/blmpop/)
+ `BLPOP`
Rimuove e restituisce il primo elemento di un elenco. Si blocca finché un elemento non è disponibile. Elimina l'elenco se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/blpop/)
+ `BRPOP`
Rimuove e restituisce l'ultimo elemento di un elenco. Si blocca finché un elemento non è disponibile. Elimina l'elenco se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/brpop/)
+ `BRPOPLPUSH`
Visualizza l'elemento di un elenco, lo inserisce in un altro elenco e lo restituisce. Si blocca finché un elemento non è disponibile. Elimina l'elenco se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/brpoplpush/)
+ `LINDEX`
Restituisce un elemento di un elenco in base all'indice.
[Ulteriori informazioni](https://valkey.io/commands/lindex/)
+ `LINSERT`
Inserisce un elemento prima o dopo un altro elemento di un elenco.
[Ulteriori informazioni](https://valkey.io/commands/linsert/)
+ `LLEN`
Restituisce la lunghezza di un elenco.
[Ulteriori informazioni](https://valkey.io/commands/llen/)
+ `LMOVE`
Restituisce l'elemento di un elenco dopo averlo visualizzato e spostato in un altro. Elimina l'elenco se l'ultimo elemento è stato spostato.
[Ulteriori informazioni](https://valkey.io/commands/lmove/)
+ `LMPOP`
Restituisce più elementi di un elenco dopo averli rimossi. Elimina l'elenco se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/lmpop/)
+ `LPOP`
Restituisce i primi elementi di un elenco dopo averlo rimosso. Elimina l'elenco se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/lpop/)
+ `LPOS`
Restituisce l'indice degli elementi corrispondenti di un elenco.
[Ulteriori informazioni](https://valkey.io/commands/lpos/)
+ `LPUSH`
Antepone uno o più elementi a un elenco. Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/lpush/)
+ `LPUSHX`
Antepone uno o più elementi a un elenco solo quando l'elenco esiste.
[Ulteriori informazioni](https://valkey.io/commands/lpushx/)
+ `LRANGE`
Restituisce un intervallo di elementi di un elenco.
[Ulteriori informazioni](https://valkey.io/commands/lrange/)
+ `LREM`
Rimuove gli elementi da un elenco. Elimina l'elenco se l'ultimo elemento è stato rimosso.
[Ulteriori informazioni](https://valkey.io/commands/lrem/)
+ `LSET`
Imposta il valore di un elemento in un elenco in base al relativo indice.
[Ulteriori informazioni](https://valkey.io/commands/lset/)
+ `LTRIM`
Rimuove gli elementi all'inizio e alla fine di un elenco. Elimina l'elenco se tutti gli elementi sono stati tagliati.
[Ulteriori informazioni](https://valkey.io/commands/ltrim/)
+ `RPOP`
Restituisce e rimuove gli ultimi elementi di un elenco. Elimina l'elenco se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/rpop/)
+ `RPOPLPUSH`
Restituisce l'ultimo elemento di un elenco dopo averlo rimosso e inserito in un altro elenco. Elimina l'elenco se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/rpoplpush/)
+ `RPUSH`
Aggiunge uno o più elementi a un elenco. Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/rpush/)
+ `RPUSHX`
Aggiunge un elemento a un elenco solo quando l'elenco esiste.
[Ulteriori informazioni](https://valkey.io/commands/rpushx/)
**Comandi Pub/Sub**
**Nota**
I comandi PUBSUB utilizzano internamente PUBSUB partizionato, pertanto i nomi dei canali sono combinati.
+ `PUBLISH`
Invia un messaggio a un canale.
[Ulteriori informazioni](https://valkey.io/commands/publish/)
+ `PUBSUB CHANNELS`
Restituisce i canali attivi.
[Ulteriori informazioni](https://valkey.io/commands/pubsub-channels/)
+ `PUBSUB NUMSUB`
Restituisce il numero di abbonati ai canali.
[Ulteriori informazioni](https://valkey.io/commands/pubsub-numsub/)
+ `PUBSUB SHARDCHANNELS`
Restituisce i canali di partizione attivi.
[Ulteriori informazioni](https://valkey.io/commands/pubsub-shardchannels/)
+ `PUBSUB SHARDNUMSUB`
Restituisce il numero di abbonati ai canali di partizione.
[Ulteriori informazioni](https://valkey.io/commands/pubsub-shardnumsub/)
+ `SPUBLISH`
Invia un messaggio a un canale di partizione.
[Ulteriori informazioni](https://valkey.io/commands/spublish/)
+ `SSUBSCRIBE`
Ascolta i messaggi pubblicati sui canali di partizione.
[Ulteriori informazioni](https://valkey.io/commands/ssubscribe/)
+ `SUBSCRIBE`
Ascolta i messaggi pubblicati sui canali.
[Ulteriori informazioni](https://valkey.io/commands/subscribe/)
+ `SUNSUBSCRIBE`
Interrompe l'ascolto dei messaggi pubblicati sui canali di partizione.
[Ulteriori informazioni](https://valkey.io/commands/sunsubscribe/)
+ `UNSUBSCRIBE`
Interrompe l'ascolto dei messaggi pubblicati sui canali.
[Ulteriori informazioni](https://valkey.io/commands/unsubscribe/)
**Comandi di scripting**
+ `EVAL`
Esegue uno script Lua lato server.
[Ulteriori informazioni](https://valkey.io/commands/eval/)
+ `EVAL_RO`
Esegue uno script Lua lato server di sola lettura.
[Ulteriori informazioni](https://valkey.io/commands/eval_ro/)
+ `EVALSHA`
Esegue uno script Lua sul lato server tramite digest. SHA1
[Ulteriori informazioni](https://valkey.io/commands/evalsha/)
+ `EVALSHA_RO`
Esegue uno script Lua lato server di sola lettura tramite digest. SHA1
[Ulteriori informazioni](https://valkey.io/commands/evalsha_ro/)
+ `SCRIPT EXISTS`
Determina se esistono script Lua lato server nella cache degli script.
[Ulteriori informazioni](https://valkey.io/commands/script-exists/)
+ `SCRIPT FLUSH`
Attualmente la cache degli script no-op è gestita dal servizio.
[Ulteriori informazioni](https://valkey.io/commands/script-flush/)
+ `SCRIPT LOAD`
Carica uno script Lua lato server nella cache degli script.
[Ulteriori informazioni](https://valkey.io/commands/script-load/)
**Comandi di gestione del server**
**Nota**
Quando si utilizzano ElastiCache cluster basati su nodi per Valkey e Redis OSS, i comandi flush devono essere inviati a ogni primario dal client per cancellare tutte le chiavi. ElastiCache Serverless per Valkey e Redis OSS funziona in modo diverso, perché astrae la topologia del cluster sottostante. Il risultato è che in ElastiCache Serverless `FLUSHALL` i comandi svuoteranno sempre tutte `FLUSHDB` le chiavi del cluster. Per questo motivo, i comandi flush non possono essere inclusi in una transazione Serverless.
+ `ACL CAT`
Elenca le categorie ACL o i comandi all'interno di una categoria.
[Ulteriori informazioni](https://valkey.io/commands/acl-cat/)
+ `ACL GENPASS`
Genera una password pseudocasuale e sicura che può essere utilizzata per identificare gli utenti ACL.
[Ulteriori informazioni](https://valkey.io/commands/acl-genpass/)
+ `ACL GETUSER`
Elenca le regole ACL di un utente.
[Ulteriori informazioni](https://valkey.io/commands/acl-getuser/)
+ `ACL LIST`
Esegue il dump delle regole valide nel formato di file ACL.
[Ulteriori informazioni](https://valkey.io/commands/acl-list/)
+ `ACL USERS`
Elenca tutti gli utenti ACL.
[Ulteriori informazioni](https://valkey.io/commands/acl-users/)
+ `ACL WHOAMI`
Restituisce il nome utente autenticato della connessione corrente.
[Ulteriori informazioni](https://valkey.io/commands/acl-whoami/)
+ `DBSIZE`
Restituisce il numero di chiavi nel database attualmente selezionato. Non si garantisce che questa operazione sia atomica su tutti gli slot.
[Ulteriori informazioni](https://valkey.io/commands/dbsize/)
+ `COMMAND`
Restituisce informazioni dettagliate su tutti i comandi.
[Ulteriori informazioni](https://valkey.io/commands/command/)
+ `COMMAND COUNT`
Restituisce un numero di comandi.
[Ulteriori informazioni](https://valkey.io/commands/command-count/)
+ `COMMAND DOCS`
Restituisce informazioni documentarie su uno, molteplici o tutti i comandi.
[Ulteriori informazioni](https://valkey.io/commands/command-docs/)
+ `COMMAND GETKEYS`
Estrae i nomi delle chiavi da un comando arbitrario.
[Ulteriori informazioni](https://valkey.io/commands/command-getkeys/)
+ `COMMAND GETKEYSANDFLAGS`
Estrae i nomi delle chiavi e i flag di accesso per un comando arbitrario.
[Ulteriori informazioni](https://valkey.io/commands/command-getkeysandflags/)
+ `COMMAND INFO`
Restituisce informazioni su uno, molteplici o tutti i comandi.
[Ulteriori informazioni](https://valkey.io/commands/command-info/)
+ `COMMAND LIST`
Restituisce un elenco di nomi di comando.
[Ulteriori informazioni](https://valkey.io/commands/command-list/)
+ `COMMANDLOG`
Un contenitore per i comandi del registro dei comandi.
[Ulteriori informazioni](https://valkey.io/commands/commandlog/)
+ `COMMANDLOG GET`
Restituisce le voci del registro dei comandi specificato.
[Ulteriori informazioni](https://valkey.io/commands/commandlog-get/)
+ `COMMANDLOG HELP`
Mostra testo utile sui diversi sottocomandi.
[Ulteriori informazioni](https://valkey.io/commands/commandlog-help/)
+ `COMMANDLOG LEN`
Restituisce il numero di voci nel tipo di registro dei comandi specificato.
[Ulteriori informazioni](https://valkey.io/commands/commandlog-len/)
+ `COMMANDLOG RESET`
Cancella tutte le voci dal tipo di registro dei comandi specificato.
[Ulteriori informazioni](https://valkey.io/commands/commandlog-reset/)
+ `FLUSHALL`
Rimuove tutte le chiavi da tutti i database. Non si garantisce che questa operazione sia atomica su tutti gli slot.
[Ulteriori informazioni](https://valkey.io/commands/flushall/)
+ `FLUSHDB`
Rimuove tutte le chiavi dal database corrente. Non si garantisce che questa operazione sia atomica su tutti gli slot.
[Ulteriori informazioni](https://valkey.io/commands/flushdb/)
+ `INFO`
Restituisce informazioni e statistiche sul server.
[Ulteriori informazioni](https://valkey.io/commands/info/)
+ `LOLWUT`
Visualizza la grafica del computer e la versione Valkey o Redis OSS.
[Ulteriori informazioni](https://valkey.io/commands/lolwut/)
+ `ROLE`
Restituisce il ruolo di replica.
[Ulteriori informazioni](https://valkey.io/commands/role/)
+ `TIME`
Restituisce l'ora del server.
[Ulteriori informazioni](https://valkey.io/commands/time/)
**Comandi di set**
+ `SADD`
Aggiunge uno o più membri a un set. Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/sadd/)
+ `SCARD`
Restituisce il numero di membri di un set.
[Ulteriori informazioni](https://valkey.io/commands/scard/)
+ `SDIFF`
Restituisce la differenza di più set.
[Ulteriori informazioni](https://valkey.io/commands/sdiff/)
+ `SDIFFSTORE`
Archivia la differenza di più set in una chiave.
[Ulteriori informazioni](https://valkey.io/commands/sdiffstore/)
+ `SINTER`
Restituisce l'intersezione di più set.
[Ulteriori informazioni](https://valkey.io/commands/sinter/)
+ `SINTERCARD`
Restituisce il numero di membri dell'intersezione di più set.
[Ulteriori informazioni](https://valkey.io/commands/sintercard/)
+ `SINTERSTORE`
Archivia l'intersezione di più set in una chiave.
[Ulteriori informazioni](https://valkey.io/commands/sinterstore/)
+ `SISMEMBER`
Determina se un membro appartiene a un set.
[Ulteriori informazioni](https://valkey.io/commands/sismember/)
+ `SMEMBERS`
Restituisce tutti i membri di un set.
[Ulteriori informazioni](https://valkey.io/commands/smembers/)
+ `SMISMEMBER`
Determina se più membri appartengono a un set.
[Ulteriori informazioni](https://valkey.io/commands/smismember/)
+ `SMOVE`
Sposta un membro da un set all'altro.
[Ulteriori informazioni](https://valkey.io/commands/smove/)
+ `SPOP`
Restituisce uno o più membri casuali di un set dopo averli rimossi. Elimina il set se l'ultimo membro è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/spop/)
+ `SRANDMEMBER`
Ottiene uno o più membri casuali da un set.
[Ulteriori informazioni](https://valkey.io/commands/srandmember/)
+ `SREM`
Rimuove uno o più membri da un set. Elimina il set se l'ultimo membro è stato rimosso.
[Ulteriori informazioni](https://valkey.io/commands/srem/)
+ `SSCAN`
Esegue l'iterazione dei membri di un set.
[Ulteriori informazioni](https://valkey.io/commands/sscan/)
+ `SUNION`
Restituisce l'unione di più set.
[Ulteriori informazioni](https://valkey.io/commands/sunion/)
+ `SUNIONSTORE`
Archivia l'unione di più set in una chiave.
[Ulteriori informazioni](https://valkey.io/commands/sunionstore/)
**Comandi di set ordinati**
+ `BZMPOP`
Rimuove e restituisce un membro in base al punteggio da uno o più set ordinati. Si blocca finché un membro non è disponibile. Elimina il set ordinato se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/bzmpop/)
+ `BZPOPMAX`
Rimuove e restituisce il membro con il punteggio più alto da uno o più set ordinati. Si blocca finché un membro non è disponibile. Elimina il set ordinato se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/bzpopmax/)
+ `BZPOPMIN`
Rimuove e restituisce il membro con il punteggio più basso da uno o più set ordinati. Si blocca finché un membro non è disponibile. Elimina il set ordinato se l'ultimo elemento è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/bzpopmin/)
+ `ZADD`
Aggiunge uno o più membri a un set ordinato oppure ne aggiorna i punteggi. Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/zadd/)
+ `ZCARD`
Restituisce il numero di membri di un set ordinato.
[Ulteriori informazioni](https://valkey.io/commands/zcard/)
+ `ZCOUNT`
Restituisce il numero di membri di un set ordinato con il punteggio compreso in un intervallo.
[Ulteriori informazioni](https://valkey.io/commands/zcount/)
+ `ZDIFF`
Restituisce la differenza tra più set ordinati.
[Ulteriori informazioni](https://valkey.io/commands/zdiff/)
+ `ZDIFFSTORE`
Archivia la differenza di più set ordinati in una chiave.
[Ulteriori informazioni](https://valkey.io/commands/zdiffstore/)
+ `ZINCRBY`
Incrementa il punteggio di un membro in un set ordinato.
[Ulteriori informazioni](https://valkey.io/commands/zincrby/)
+ `ZINTER`
Restituisce l'intersezione di più set ordinati.
[Ulteriori informazioni](https://valkey.io/commands/zinter/)
+ `ZINTERCARD`
Restituisce il numero di membri dell'intersezione di più set ordinati.
[Ulteriori informazioni](https://valkey.io/commands/zintercard/)
+ `ZINTERSTORE`
Archivia l'intersezione di più set ordinati in una chiave.
[Ulteriori informazioni](https://valkey.io/commands/zinterstore/)
+ `ZLEXCOUNT`
Restituisce il numero di membri di un set ordinato in un intervallo lessicografico.
[Ulteriori informazioni](https://valkey.io/commands/zlexcount/)
+ `ZMPOP`
Restituisce i membri con il punteggio più alto o più basso di uno o più set ordinati dopo averli rimossi. Elimina il set ordinato se l'ultimo membro è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/zmpop/)
+ `ZMSCORE`
Restituisce il punteggio di uno o più membri di un set ordinato.
[Ulteriori informazioni](https://valkey.io/commands/zmscore/)
+ `ZPOPMAX`
Restituisce i membri con il punteggio più alto di un set ordinato dopo averli rimossi. Elimina il set ordinato se l'ultimo membro è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/zpopmax/)
+ `ZPOPMIN`
Restituisce i membri con il punteggio più basso di un set ordinato dopo averli rimossi. Elimina il set ordinato se l'ultimo membro è stato visualizzato.
[Ulteriori informazioni](https://valkey.io/commands/zpopmin/)
+ `ZRANDMEMBER`
Restituisce uno o più membri casuali di un set ordinato.
[Ulteriori informazioni](https://valkey.io/commands/zrandmember/)
+ `ZRANGE`
Restituisce i membri di un set ordinato in un intervallo di indici.
[Ulteriori informazioni](https://valkey.io/commands/zrange/)
+ `ZRANGEBYLEX`
Restituisce i membri di un set ordinato in un intervallo lessicografico.
[Ulteriori informazioni](https://valkey.io/commands/zrangebylex/)
+ `ZRANGEBYSCORE`
Restituisce i membri di un set ordinato in un intervallo di punteggi.
[Ulteriori informazioni](https://valkey.io/commands/zrangebyscore/)
+ `ZRANGESTORE`
Archivia in una chiave un intervallo di membri di un set ordinato.
[Ulteriori informazioni](https://valkey.io/commands/zrangestore/)
+ `ZRANK`
Restituisce l'indice di un membro in un set ordinato per punteggi in ordine crescente.
[Ulteriori informazioni](https://valkey.io/commands/zrank/)
+ `ZREM`
Rimuove uno o più membri da un set ordinato. Elimina il set ordinato se tutti i membri sono stati rimossi.
[Ulteriori informazioni](https://valkey.io/commands/zrem/)
+ `ZREMRANGEBYLEX`
Rimuove i membri di un set ordinato in un intervallo lessicografico. Elimina il set ordinato se tutti i membri sono stati rimossi.
[Ulteriori informazioni](https://valkey.io/commands/zremrangebylex/)
+ `ZREMRANGEBYRANK`
Rimuove i membri di un set ordinato in un intervallo di indici. Elimina il set ordinato se tutti i membri sono stati rimossi.
[Ulteriori informazioni](https://valkey.io/commands/zremrangebyrank/)
+ `ZREMRANGEBYSCORE`
Rimuove i membri di un set ordinato in un intervallo di punteggi. Elimina il set ordinato se tutti i membri sono stati rimossi.
[Ulteriori informazioni](https://valkey.io/commands/zremrangebyscore/)
+ `ZREVRANGE`
Restituisce i membri di un set ordinato in un intervallo di indici in ordine inverso.
[Ulteriori informazioni](https://valkey.io/commands/zrevrange/)
+ `ZREVRANGEBYLEX`
Restituisce i membri di un set ordinato in un intervallo lessicografico in ordine inverso.
[Ulteriori informazioni](https://valkey.io/commands/zrevrangebylex/)
+ `ZREVRANGEBYSCORE`
Restituisce i membri di un set ordinato in un intervallo di punteggi in ordine inverso.
[Ulteriori informazioni](https://valkey.io/commands/zrevrangebyscore/)
+ `ZREVRANK`
Restituisce l'indice di un membro in un set ordinato per punteggi in ordine decrescente.
[Ulteriori informazioni](https://valkey.io/commands/zrevrank/)
+ `ZSCAN`
Esegue l'iterazione dei membri e dei punteggi di un set ordinato.
[Ulteriori informazioni](https://valkey.io/commands/zscan/)
+ `ZSCORE`
Restituisce il punteggio di un membro in un set ordinato.
[Ulteriori informazioni](https://valkey.io/commands/zscore/)
+ `ZUNION`
Restituisce l'unione di più set ordinati.
[Ulteriori informazioni](https://valkey.io/commands/zunion/)
+ `ZUNIONSTORE`
Archivia l'unione di più set ordinati in una chiave.
[Ulteriori informazioni](https://valkey.io/commands/zunionstore/)
**Comandi di flusso**
+ `XACK`
Restituisce il numero di messaggi confermati dal membro del gruppo di consumer di un flusso.
[Ulteriori informazioni](https://valkey.io/commands/xack/)
+ `XADD`
Aggiunge un nuovo messaggio a un flusso. Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/xadd/)
+ `XAUTOCLAIM`
Cambia o acquisisce la proprietà dei messaggi in un gruppo di consumer, come se i messaggi fossero recapitati a un membro del gruppo di consumer.
[Ulteriori informazioni](https://valkey.io/commands/xautoclaim/)
+ `XCLAIM`
Cambia o acquisisce la proprietà di un messaggio in un gruppo di consumer, come se il messaggio fosse stato recapitato a un membro del gruppo di consumer.
[Ulteriori informazioni](https://valkey.io/commands/xclaim/)
+ `XDEL`
Restituisce il numero di messaggi dopo averli rimossi da un flusso.
[Ulteriori informazioni](https://valkey.io/commands/xdel/)
+ `XGROUP CREATE`
Crea un gruppo di consumer.
[Ulteriori informazioni](https://valkey.io/commands/xgroup-create/)
+ `XGROUP CREATECONSUMER`
Crea un consumer in un gruppo di consumer.
[Ulteriori informazioni](https://valkey.io/commands/xgroup-createconsumer/)
+ `XGROUP DELCONSUMER`
Elimina un consumer da un gruppo di consumer.
[Ulteriori informazioni](https://valkey.io/commands/xgroup-delconsumer/)
+ `XGROUP DESTROY`
Distrugge un gruppo di consumer.
[Ulteriori informazioni](https://valkey.io/commands/xgroup-destroy/)
+ `XGROUP SETID`
Imposta l'ultimo ID fornito di un gruppo di consumer.
[Ulteriori informazioni](https://valkey.io/commands/xgroup-setid/)
+ `XINFO CONSUMERS`
Restituisce l'elenco dei consumer di un gruppo di consumer.
[Ulteriori informazioni](https://valkey.io/commands/xinfo-consumers/)
+ `XINFO GROUPS`
Restituisce l'elenco dei gruppi di consumer di un flusso.
[Ulteriori informazioni](https://valkey.io/commands/xinfo-groups/)
+ `XINFO STREAM`
Restituisce le informazioni su un flusso.
[Ulteriori informazioni](https://valkey.io/commands/xinfo-stream/)
+ `XLEN`
Restituisce il numero dei messaggi in un flusso.
[Ulteriori informazioni](https://valkey.io/commands/xlen/)
+ `XPENDING`
Restituisce le informazioni e le voci dell'elenco delle voci in sospeso di un gruppo di consumer di un flusso.
[Ulteriori informazioni](https://valkey.io/commands/xpending/)
+ `XRANGE`
Restituisce i messaggi da uno stream all'interno di un intervallo di. IDs
[Ulteriori informazioni](https://valkey.io/commands/xrange/)
+ `XREAD`
Restituisce messaggi da più stream con IDs un numero maggiore di quelli richiesti. Si blocca finché un messaggio non è disponibile.
[Ulteriori informazioni](https://valkey.io/commands/xread/)
+ `XREADGROUP`
Restituisce i messaggi nuovi o storici di un flusso per un consumer di un gruppo. Si blocca finché un messaggio non è disponibile.
[Ulteriori informazioni](https://valkey.io/commands/xreadgroup/)
+ `XREVRANGE`
Restituisce i messaggi da uno stream all'interno di un intervallo IDs in ordine inverso.
[Ulteriori informazioni](https://valkey.io/commands/xrevrange/)
+ `XTRIM`
Elimina i messaggi dall'inizio di un flusso.
[Ulteriori informazioni](https://valkey.io/commands/xtrim/)
**Comandi di stringa**
+ `APPEND`
Aggiunge una stringa al valore di una chiave. Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/append/)
+ `DECR`
Diminuisce di uno il valore intero di una chiave. Utilizza 0 come valore iniziale se la chiave non esiste.
[Ulteriori informazioni](https://valkey.io/commands/decr/)
+ `DECRBY`
Diminuisce di un numero il valore intero di una chiave. Utilizza 0 come valore iniziale se la chiave non esiste.
[Ulteriori informazioni](https://valkey.io/commands/decrby/)
+ `GET`
Restituisce il valore di stringa di una chiave.
[Ulteriori informazioni](https://valkey.io/commands/get/)
+ `GETDEL`
Restituisce il valore di stringa di una chiave dopo l'eliminazione della chiave.
[Ulteriori informazioni](https://valkey.io/commands/getdel/)
+ `GETEX`
Restituisce il valore di stringa di una chiave dopo averne impostato l'ora di scadenza.
[Ulteriori informazioni](https://valkey.io/commands/getex/)
+ `GETRANGE`
Restituisce una sottostringa della stringa archiviata in una chiave.
[Ulteriori informazioni](https://valkey.io/commands/getrange/)
+ `GETSET`
Restituisce il valore di stringa precedente di una chiave dopo averla impostata su un nuovo valore.
[Ulteriori informazioni](https://valkey.io/commands/getset/)
+ `INCR`
Incrementa di uno il valore intero di una chiave. Utilizza 0 come valore iniziale se la chiave non esiste.
[Ulteriori informazioni](https://valkey.io/commands/incr/)
+ `INCRBY`
Incrementa di un numero il valore intero di una chiave. Utilizza 0 come valore iniziale se la chiave non esiste.
[Ulteriori informazioni](https://valkey.io/commands/incrby/)
+ `INCRBYFLOAT`
Incrementa di un numero il valore in virgola mobile di una chiave. Utilizza 0 come valore iniziale se la chiave non esiste.
[Ulteriori informazioni](https://valkey.io/commands/incrbyfloat/)
+ `LCS`
Trova la sottostringa comune più lunga.
[Ulteriori informazioni](https://valkey.io/commands/lcs/)
+ `MGET`
Restituisce atomicamente i valori di stringa di una o più chiavi.
[Ulteriori informazioni](https://valkey.io/commands/mget/)
+ `MSET`
Crea o modifica atomicamente i valori di stringa di una o più chiavi.
[Ulteriori informazioni](https://valkey.io/commands/mset/)
+ `MSETNX`
Modifica atomicamente i valori di stringa di una o più chiavi solo quando non esistono tutte le chiavi.
[Ulteriori informazioni](https://valkey.io/commands/msetnx/)
+ `PSETEX`
Imposta il valore di stringa e l'ora di scadenza in millisecondi di una chiave. La chiave viene creata se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/psetex/)
+ `SET`
Imposta il valore di stringa di una chiave, ignorandone il tipo. La chiave viene creata se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/set/)
+ `SETEX`
Imposta il valore di stringa e l'ora di scadenza di una chiave. Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/setex/)
+ `SETNX`
Imposta il valore di stringa di una chiave solo quando la chiave non esiste.
[Ulteriori informazioni](https://valkey.io/commands/setnx/)
+ `SETRANGE`
Sovrascrive una parte del valore di stringa mediante un offset. Crea la chiave, se non esiste.
[Ulteriori informazioni](https://valkey.io/commands/setrange/)
+ `STRLEN`
Restituisce la lunghezza di un valore di stringa.
[Ulteriori informazioni](https://valkey.io/commands/strlen/)
+ `SUBSTR`
Restituisce una sottostringa da un valore di stringa.
[Ulteriori informazioni](https://valkey.io/commands/substr/)
**Comandi di transazione**
+ `DISCARD`
Elimina una transazione.
[Ulteriori informazioni](https://valkey.io/commands/discard/)
+ `EXEC`
Esegue tutti i comandi in una transazione.
[Ulteriori informazioni](https://valkey.io/commands/exec/)
+ `MULTI`
Inizia una transazione.
[Ulteriori informazioni](https://valkey.io/commands/multi/)
## Comandi Valkey e Redis OSS con restrizioni
Per offrire un'esperienza di servizio gestito, ElastiCache limita l'accesso a determinati comandi specifici del motore di cache che richiedono privilegi avanzati. Per le cache che eseguono Redis OSS, i seguenti comandi non sono disponibili:
+ `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`
Inoltre, i seguenti comandi non sono disponibili per le cache serverless:
+ `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`
## Comandi Memcached supportati
ElastiCache Serverless for Memcached supporta tutti i [comandi](https://github.com/memcached/memcached/wiki/Commands) memcached in memcached 1.6 open source ad eccezione dei seguenti:
+ Le connessioni client richiedono TLS, di conseguenza il protocollo UDP non è supportato.
+ Il protocollo binario non è supportato, in quanto è ufficialmente [obsoleto](https://github.com/memcached/memcached/wiki/ReleaseNotes160) in memcached 1.6.
+ I comandi `GET/GETS` sono limitati a 16 KB per evitare potenziali attacchi DoS al server con il recupero di un numero elevato di chiavi.
+ Il comando `flush_all` ritardato verrà rifiutato con `CLIENT_ERROR`.
+ I comandi che configurano il motore o rivelano informazioni interne sullo stato o sui log del motore non sono supportati, ad esempio:
+ Per il comando `STATS` sono supportati solo `stats` e `stats reset`. Altre varianti restituiscono `ERROR`.
+ `lru / lru_crawler`: modifica delle impostazioni per LRU e crawler LRU.
+ `watch`: controlla i log del server memcached.
+ `verbosity`: configura il livello di log del server.
+ `me`- il comando meta debug (me) non è supportato
# Configurazione e limiti di Valkey e Redis OSS
I motori Valkey e Redis OSS forniscono ciascuno una serie di parametri di configurazione, alcuni dei quali sono modificabili in Redis OSS e altri non sono modificabili ElastiCache per fornire prestazioni e affidabilità stabili.
## Cache serverless
Per le cache serverless, i gruppi di parametri non vengono utilizzati e tutte le configurazioni di Valkey o Redis OSS non sono modificabili. Sono presenti i seguenti parametri Valkey o Redis OSS:
****
| Name | Informazioni | Description |
| --- | --- | --- |
| acl-pubsub-default | `allchannels` | Le autorizzazioni predefinite del canale pubsub per gli utenti ACL nella cache. |
| client-output-buffer-limit | `normal 0 0 0` `pubsub 32mb 8mb 60` | I client normali non hanno limiti di buffer. PUB/SUB i client verranno disconnessi se violano il backlog di 32 MiB o violano il backlog di 8 MiB per 60 minuti. |
| client-query-buffer-limit | 1 GiB | La dimensione massima di un singolo buffer di query dei client. Inoltre, i client non possono emettere una richiesta con più di 3.999 argomenti. |
| cluster-allow-pubsubshard-when-down | yes | In tal modo la cache può servire il traffico pubsub mentre è parzialmente inattiva. |
| cluster-allow-reads-when-down | yes | In tal modo la cache può servire il traffico di lettura mentre è parzialmente inattiva. |
| cluster-enabled | yes | Tutte le cache serverless sono abilitate alla modalità cluster, che consente loro di partizionare in modo trasparente i dati su più partizioni di back-end. Tutti gli slot vengono mostrati ai client come fossero di proprietà di un singolo nodo virtuale. |
| cluster-require-full-coverage | no | Quando il keyspace è parzialmente inattivo (ovvero almeno uno slot hash è inaccessibile), la cache continua ad accettare le query per la parte del keyspace ancora coperta. L'intero keyspace sarà sempre "coperto" da un singolo nodo virtuale in cluster slots. |
| lua-time-limit | 5000 | Il tempo massimo di esecuzione per uno script Lua, in millisecondi, prima che venga eseguita l'azione ElastiCache necessaria per arrestare lo script. *Se `lua-time-limit` viene superato, tutti i comandi Valkey o Redis OSS possono restituire un errore nel formato \$1\$1\$1\$1-BUSY.* *Poiché questo stato può causare interferenze con molte operazioni essenziali di Valkey o Redis OSS, ElastiCache emetterà prima un comando SCRIPT KILL.* Se ciò non riesce, ElastiCache riavvierà forzatamente Valkey o Redis OSS. |
| maxclients | 65000 | Il numero massimo di client che possono essere connessi contemporaneamente alla cache. Le altre connessioni possono essere o meno completate. |
| maxmemory-policy | volatile-lru | Gli elementi con un set TTL vengono eliminati in base alla stima least-recently-used (LRU) quando viene raggiunto il limite di memoria della cache. |
| notify-keyspace-events | Stringa vuota | Gli eventi del keyspace non sono attualmente supportati nelle cache serverless. |
| port | Porta principale: 6379 Porta di lettura: 6380 | Le cache serverless pubblicizzano due porte con lo stesso nome host. La porta principale consente scritture e letture, mentre la porta di lettura consente le letture a coerenza finale con una latenza inferiore utilizzando il comando READONLY. |
| proto-max-bulk-len | 512 MiB | La dimensione massima di una singola richiesta di elementi. |
| timeout | 0 | La disconnessione dei client non viene forzata per un determinato periodo di inattività, ma può essere eseguita durante lo stato stazionario a beneficio del sistema di bilanciamento del carico. |
Inoltre, sono applicati i limiti seguenti:
****
| Name | Informazioni | Description |
| --- | --- | --- |
| Dimensioni per cache | 5.000 GiB | Quantità massima di dati che è possibile archiviare per cache serverless. |
| Dimensioni per slot | 32 GiB | La dimensione massima di un singolo slot hash Valkey o Redis OSS. I client che cercano di impostare più dati di questi su un singolo slot Valkey o Redis OSS attiveranno la politica di espulsione sullo slot e, se nessuna chiave è eliminabile, riceveranno un errore out of memory (). OOM |
| ECPU per cache | 15.000.000 di ECPU/secondo | ElastiCache Metrica delle unità di elaborazione (ECPU). Il numero di dati ECPUs consumati dalle tue richieste dipende dal tempo impiegato dalla vCPU e dalla quantità di dati trasferiti. |
| ECPU per slot | 30.000 - 90.000 ECPU/secondo | Massimo 30.000 ECPUs/second per slot o 90.000 se si utilizza Read from Replica utilizzando connessioni ECPUs/second READONLY. |
| Argomenti per richiesta | 3.999 | Numero massimo di argomenti per richiesta. I client che inviano più argomenti per richiesta riceveranno un errore. |
| Lunghezza del nome della chiave | 4 KiB | La dimensione massima per una singola chiave Valkey o Redis OSS o nome di canale. I client che fanno riferimento a chiavi di dimensioni superiori restituiscono un errore. |
| Dimensione dello script Lua | 4 MiB | La dimensione massima di un singolo script Valkey o Redis OSS Lua. I tentativi di caricare uno script Lua più grande restituiscono un errore. |
## Cluster basati su nodi
Per i cluster basati su nodi, vedere [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis) i valori predefiniti dei parametri di configurazione e quali sono configurabili. I valori predefiniti sono generalmente consigliati a meno che non si abbia un caso d'uso specifico che ne richieda la sostituzione.
# IPv6 esempi di client per Valkey, Memcached e Redis OSS
ElastiCache è compatibile con Valkey, Memcached e Redis OSS. Ciò significa che i client che supportano IPv6 le connessioni dovrebbero essere in grado di connettersi ai cluster IPv6 Enabled ElastiCache for Memcached. Ci sono alcune avvertenze che vale la pena notare quando si interagisce con risorse abilitate. IPv6
È possibile visualizzare il post di blog [sulle migliori pratiche per i clienti Valkey e Redis](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) sul blog AWS Database per consigli sulla configurazione dei client Valkey e Redis OSS per le risorse. ElastiCache
Di seguito sono riportate le migliori pratiche per interagire con le ElastiCache risorse IPv6 abilitate con le librerie client open source di uso comune.
## Client convalidati con Valkey e Redis OSS
ElastiCache è compatibile con Valkey e Redis OSS open source. Ciò significa che Valkey e i client Redis OSS open source che supportano IPv6 le connessioni dovrebbero essere in grado di connettersi a cluster IPv6 Enabled ElastiCache for Redis OSS. Inoltre, molti dei client Python e Java più diffusi sono stati specificamente testati e convalidati per funzionare con tutte le configurazioni di tipo di rete supportate (IPv4 solo, IPv6 solo e Dual Stack)
I seguenti client sono stati specificamente convalidati per funzionare con tutte le configurazioni dei tipi di rete supportate per Valkey e Redis OSS.
Clienti convalidati:
+ [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/) – [Versione: 6.1.6.RELEASE](https://github.com/lettuce-io/lettuce-core/tree/6.1.6.RELEASE)
+ [Jedis](https://github.com/redis/jedis) – [Versione: 3.6.0](https://github.com/redis/jedis/tree/jedis-3.6.0)
# Le migliori pratiche per i clienti (Valkey e Redis OSS)
Scopri le best practice per gli scenari più comuni e segui gli esempi di codice di alcune delle più popolari librerie client open source Valkey e Redis OSS (redis-py e Lettuce) PHPRedis, nonché le migliori pratiche per interagire con le risorse con ElastiCache le librerie client Memcached open source di uso comune.
**Topics**
+ [Grande numero di connessioni (Valkey e Redis OSS)](BestPractices.Clients.Redis.Connections.md)
+ [Individuazione e backoff esponenziale dei client del cluster (Valkey e Redis OSS)](BestPractices.Clients.Redis.Discovery.md)
+ [Configurazione di un timeout lato client (Valkey e Redis OSS)](BestPractices.Clients.Redis.ClientTimeout.md)
+ [Configurazione di un timeout di inattività lato server (Valkey e Redis OSS)](BestPractices.Clients.Redis.ServerTimeout.md)
+ [Script Lua](BestPractices.Clients.Redis.LuaScripts.md)
+ [Archiviazione di elementi compositi di grandi dimensioni (Valkey e Redis OSS)](BestPractices.Clients.Redis.LargeItems.md)
+ [Configurazione del client Lettuce (Valkey e Redis OSS)](BestPractices.Clients-lettuce.md)
+ [Configurazione di un protocollo preferito per i cluster dual stack (Valkey e Redis OSS)](#network-type-configuring-dual-stack-redis)
# Grande numero di connessioni (Valkey e Redis OSS)
Le cache serverless e individuali ElastiCache per i nodi Redis OSS supportano fino a 65.000 connessioni client simultanee. Tuttavia, per ottimizzare le prestazioni, consigliamo che le applicazioni client non operino costantemente a un livello così elevato. Valkey e Redis OSS dispongono ciascuno di un processo a thread singolo basato su un ciclo di eventi in cui le richieste dei client in entrata vengono gestite in sequenza. Ciò significa che il tempo di risposta di un determinato client si allunga con l'aumento del numero di client connessi.
È possibile eseguire la seguente serie di azioni per evitare di imbattersi in un collo di bottiglia di connessione su un server Valkey o Redis OSS:
+ Esegui le operazioni di lettura dalle repliche di lettura. Ciò può essere fatto utilizzando gli endpoint di ElastiCache lettura in modalità cluster disattivata o utilizzando repliche per le letture in modalità cluster abilitata, inclusa una cache serverless.
+ Distribuisci il traffico di scrittura su più nodi primari. Sono disponibili due modi per farlo: È possibile utilizzare un cluster Valkey o Redis OSS con più sharded con un client compatibile con la modalità cluster. puoi scrivere su più nodi primari in modalità cluster disabilitata con il partizionamento lato client. Questa operazione viene eseguita automaticamente in una cache serverless.
+ Usa un pool di connessioni quando disponibile nella libreria client.
In generale, la creazione di una connessione TCP è un'operazione computazionalmente costosa rispetto ai tipici comandi Valkey o Redis OSS. Ad esempio, la gestione di una SET/GET richiesta è un ordine di grandezza più veloce quando si riutilizza una connessione esistente. L'uso di un pool di connessioni client di dimensioni limitate riduce il sovraccarico della gestione delle connessioni. Inoltre, limita il numero di connessioni simultanee in entrata dell'applicazione client.
Il seguente esempio di codice PHPRedis mostra che viene creata una nuova connessione per ogni nuova richiesta utente:
```
$redis = new Redis();
if ($redis->connect($HOST, $PORT) != TRUE) {
//ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
Abbiamo confrontato questo codice in un ciclo su un'istanza Amazon Elastic Compute Cloud (Amazon EC2) connessa a un nodo Graviton2 (m6g.2xlarge) per Redis OSS. ElastiCache Abbiamo posizionato il client e il server nella stessa zona di disponibilità. La latenza media dell'intera operazione è stata di 2,82 millisecondi.
Quando abbiamo aggiornato il codice e utilizzato le connessioni persistenti e un pool di connessioni, la latenza media dell'intera operazione è stata di 0,21 millisecondi:
```
$redis = new Redis();
if ($redis->pconnect($HOST, $PORT) != TRUE) {
// ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
Configurazioni di redis.ini richieste:
+ `redis.pconnect.pooling_enabled=1`
+ `redis.pconnect.connection_limit=10`
Il codice seguente è un esempio di [pool di connessioni Redis-py](https://redis.readthedocs.io/en/stable/):
```
conn = Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
conn.set(key, value)
```
Il codice seguente è un esempio di [pool di connessioni Lettuce](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);
}
```
# Individuazione e backoff esponenziale dei client del cluster (Valkey e Redis OSS)
Quando ci si connette a un cluster ElastiCache Valkey o Redis OSS in modalità cluster abilitata, la libreria client corrispondente deve essere in grado di riconoscere il cluster. I client devono ottenere una mappa degli slot hash ai nodi corrispondenti del cluster per inviare le richieste ai nodi giusti ed evitare il sovraccarico delle prestazioni dovuto alla gestione dei reindirizzamenti del cluster. Di conseguenza, il client deve ottenere l'elenco completo degli slot e dei nodi mappati in due diverse situazioni:
+ Il client è inizializzato e deve compilare la configurazione iniziale degli slot.
+ Il server riceve un reindirizzamento MOVED, ad esempio in caso di failover in cui tutti gli slot serviti dal precedente nodo primario vengono acquisiti dalla replica oppure in caso di ripartizionamento quando gli slot vengono spostati dal nodo primario di origine al nodo primario di destinazione.
L'individuazione dei client viene in genere effettuata tramite l'emissione di un comando CLUSTER SLOT o CLUSTER NODE al server Valkey o Redis OSS. Consigliamo il metodo CLUSTER SLOT perché restituisce al client il set di intervalli di slot e i nodi primari e di replica associati. Questo metodo non richiede un'analisi aggiuntiva da parte del client ed è più efficiente.
A seconda della topologia del cluster, la dimensione della risposta per il comando CLUSTER SLOT può variare in base alla dimensione del cluster. I cluster più grandi con più nodi producono una risposta di dimensione maggiore. Di conseguenza, è importante garantire che il numero di client che eseguono l'individuazione della topologia del cluster non cresca in modo illimitato. Ad esempio, quando l'applicazione client avvia o perde la connessione del server e deve eseguire l'individuazione del cluster, un errore comune è che l'applicazione client generi diverse richieste di riconnessione e individuazione senza aggiungere un backoff esponenziale al momento del nuovo tentativo. Ciò può impedire al server Valkey o Redis OSS di rispondere per un periodo di tempo prolungato, con un utilizzo della CPU al 100%. L'interruzione si prolunga se ogni comando CLUSTER SLOT deve elaborare un numero elevato di nodi nel bus del cluster. In passato abbiamo osservato diverse interruzioni dei client a causa di questo comportamento in diversi linguaggi, tra cui Python redis-py-cluster () e Java (Lettuce e Redisson).
In una cache serverless, molti problemi vengono mitigati automaticamente perché la topologia del cluster pubblicizzata è statica ed è composta da due elementi: un endpoint di scrittura e un endpoint di lettura. L'individuazione del cluster viene inoltre distribuita automaticamente su più nodi quando si utilizza l'endpoint di cache. I seguenti suggerimenti sono tuttavia utili.
Per mitigare l'impatto causato da un afflusso improvviso di richieste di connessione e individuazione, ti consigliamo di procedere come segue:
+ Implementa un pool di connessioni client di dimensioni limitate per contenere il numero di connessioni simultanee in entrata dell'applicazione client.
+ Quando il client si disconnette dal server a causa di un timeout, riprova con un backoff esponenziale con jitter. In tal modo eviti che più client sovraccarichino il server contemporaneamente.
+ Utilizza le indicazioni contenute in [Ricerca degli endpoint di connessione in ElastiCache](Endpoints.md) per trovare l'endpoint del cluster ed eseguire l'individuazione del cluster. In questo modo, distribuisci il carico dell'individuazione su tutti i nodi del cluster (fino a 90) invece di usare i pochi nodi di inizializzazione codificati nel cluster.
Di seguito sono riportati alcuni esempi di codice per la logica esponenziale dei tentativi di backoff in redis-py e Lettuce. PHPRedis
**Esempio 1 di logica di backoff: redis-py**
redis-py ha un meccanismo di ripetizione dei tentativi integrato che ripete il tentativo una volta subito dopo l'errore. [Questo meccanismo può essere abilitato tramite l'`retry_on_timeout`argomento fornito durante la creazione di un oggetto Redis OSS.](https://redis.readthedocs.io/en/stable/examples/connection_examples.html#redis.Redis) Di seguito è illustrato un meccanismo di ripetizione dei tentativi personalizzato con backoff esponenziale e jitter. Inviamo una richiesta pull per implementare in modo nativo il backoff esponenziale in [redis-py (\$11494)](https://github.com/andymccurdy/redis-py/pull/1494). In futuro potrebbe non essere necessario implementarlo manualmente.
```
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
```
Quindi puoi utilizzare il codice seguente per impostare un valore:
```
client = redis.Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
res = run_with_backoff(lambda: client.set("key", "value"))
print(res)
```
A seconda del carico di lavoro, è possibile modificare il valore di backoff di base da 1 secondo a poche decine o centinaia di millisecondi per i carichi di lavoro sensibili alla latenza.
**Esempio di logica di backoff 2: PHPRedis**
PHPRedis dispone di un meccanismo di riprova integrato che riprova un massimo di 10 volte (non configurabile). Si verifica un ritardo configurabile tra i tentativi (con un jitter dal secondo tentativo in poi). Per ulteriori informazioni, consulta il seguente [codice di esempio](https://github.com/phpredis/phpredis/blob/b0b9dd78ef7c15af936144c1b17df1a9273d72ab/library.c#L335-L368). [Abbiamo inviato una pull request per implementare nativamente il backoff esponenziale in [PHPredis (\$11986)](https://github.com/phpredis/phpredis/pull/1986), che da allora è stata unita e documentata.](https://github.com/phpredis/phpredis/blob/develop/README.md#retry-and-backoff) Per chi utilizza l'ultima versione di PHPRedis, non sarà necessario implementarlo manualmente, ma abbiamo incluso qui il riferimento per quelli delle versioni precedenti. Il seguente è un esempio di codice che configura il ritardo del meccanismo di ripetizione dei tentativi:
```
$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);
```
**Esempio 3 di logica di backoff: Lettuce**
Lettuce dispone di meccanismi di ripetizione dei tentativi incorporati basati sulle strategie di backoff esponenziale descritte nel post [Exponential Backoff and Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/). Di seguito è riportato un estratto di codice che mostra l'approccio completo del jitter:
```
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();
}
}
}
```
# Configurazione di un timeout lato client (Valkey e Redis OSS)
**Configurazione del timeout lato client**
Configura il timeout lato client in modo appropriato per assegnare al server il tempo sufficiente per elaborare la richiesta e generare la risposta. Ciò consente inoltre di anticipare l'errore (fail fast) se non è possibile stabilire la connessione al server. Alcuni comandi Valkey o Redis OSS possono essere più costosi dal punto di vista computazionale rispetto ad altri. Ad esempio, script o MULTI/EXEC transazioni Lua che contengono più comandi che devono essere eseguiti atomicamente. In generale, si consiglia un timeout lato client più elevato per evitare il timeout del client prima che la risposta venga ricevuta dal server, tra cui i seguenti scenari:
+ Esecuzione di comandi su più chiavi
+ Esecuzione di MULTI/EXEC transazioni o script Lua costituiti da più comandi singoli Valkey o Redis OSS
+ Lettura di valori di grandi dimensioni
+ Esecuzione di operazioni di blocco come BLPOP
Nel caso di un'operazione di blocco come BLPOP, la best practice consiste nell'impostare il timeout del comando su un valore inferiore al timeout del socket.
Di seguito sono riportati esempi di codice per l'implementazione di un timeout lato client in redis-py e Lettuce. PHPRedis
**Esempio 1 di configurazione del timeout: redis-py**
Di seguito è riportato un esempio di codice con 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)
```
**Esempio 2 di configurazione di Timeout: PHPRedis**
Di seguito è riportato un esempio di codice con: 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
```
**Esempio 3 di configurazione del timeout: Lettuce**
Di seguito è riportato un esempio di codice con 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();
}
}
}
```
# Configurazione di un timeout di inattività lato server (Valkey e Redis OSS)
Abbiamo osservato casi in cui l'applicazione di un cliente ha un numero elevato di client inattivi collegati, ma non invia attivamente comandi. In tali scenari, è possibile esaurire tutte le 65.000 connessioni con un numero elevato di client inattivi. Per evitare tali situazioni, configura l'impostazione del timeout in modo appropriato sul server con i [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis). In tal modo si garantisce che il server disconnetta attivamente i client inattivi per evitare un aumento del numero di connessioni. Questa impostazione non è disponibile nelle cache serverless.
# Script Lua
Valkey e Redis OSS supportano più di 200 comandi, inclusi quelli per eseguire gli script Lua. Tuttavia, quando si tratta di script Lua, ci sono diverse insidie che possono influire sulla memoria e sulla disponibilità di Valkey o Redis OSS.
**Script Lua non parametrizzati**
Ogni script Lua viene memorizzato nella cache sul server Valkey o Redis OSS prima di essere eseguito. Gli script Lua non parametrizzati sono unici, il che può portare il server Valkey o Redis OSS a archiviare un gran numero di script Lua e a consumare più memoria. Per mitigare questo problema, assicurati che tutti gli script Lua siano parametrizzati ed esegui regolarmente SCRIPT FLUSH per pulire gli script Lua memorizzati nella cache, se necessario.
Tieni inoltre presente che è necessario fornire le chiavi. Se non viene fornito un valore per il parametro KEY, lo script avrà esito negativo. Ad esempio, questo non funzionerà:
```
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.
```
Funzionerà:
```
serverless-test-lst4hg.serverless.use1.cache.amazonaws.com:6379> eval 'return redis.call("get", KEYS[1])' 1 mykey-2
"myvalue-2"
```
Il codice di esempio seguente mostra come utilizzare gli script parametrizzati. Innanzitutto, abbiamo un esempio di approccio non parametrizzato che non è consigliato e produce tre diversi script Lua memorizzati nella cache:
```
eval "return redis.call('set','key1','1')" 0
eval "return redis.call('set','key2','2')" 0
eval "return redis.call('set','key3','3')" 0
```
Utilizza invece lo schema seguente per creare un singolo script in grado di accettare i parametri passati:
```
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
```
**Script Lua a esecuzione prolungata**
Gli script Lua possono eseguire più comandi in modo atomico, quindi il completamento può richiedere più tempo rispetto a un normale comando Valkey o Redis OSS. Se lo script Lua esegue esclusivamente operazioni di sola lettura, puoi interromperlo a metà. Tuttavia, non appena lo script Lua esegue un'operazione di scrittura, non puoi più interromperlo e deve essere eseguito fino al completamento. Uno script Lua a esecuzione prolungata che sta mutando può far sì che il server Valkey o Redis OSS non risponda per un lungo periodo. Per mitigare questo problema, evita gli script Lua a esecuzione prolungata e testali in un ambiente di preproduzione.
**Script Lua con scritture invisibili**
Esistono alcuni modi in cui uno script Lua può continuare a scrivere nuovi dati in Valkey o Redis OSS anche quando Valkey o Redis OSS sono terminati: `maxmemory`
+ Lo script inizia quando il server Valkey o Redis OSS si trova al di sotto `maxmemory` e contiene più operazioni di scrittura al suo interno
+ Il primo comando di scrittura dello script non consuma memoria (come DEL), le successive operazioni di scrittura consumano memoria.
+ È possibile mitigare questo problema configurando una politica di sfratto adeguata in un server Valkey o Redis OSS diverso da. `noeviction` Ciò consente a Redis OSS di eliminare gli elementi e liberare memoria tra gli script Lua.
# Archiviazione di elementi compositi di grandi dimensioni (Valkey e Redis OSS)
In alcuni scenari, un'applicazione può archiviare elementi compositi di grandi dimensioni in Valkey o Redis OSS (come un set di dati hash da più GB). Questa non è una pratica consigliata perché spesso causa problemi di prestazioni in Valkey o Redis OSS. Ad esempio, il client può eseguire un comando HGETALL per recuperare l'intera raccolta di hash da più GB. Ciò può generare una notevole pressione sulla memoria del server Valkey o Redis OSS che memorizza nel buffer di output dell'elemento di grandi dimensioni nel buffer di output del client. Inoltre, per la migrazione degli slot in modalità cluster, ElastiCache non esegue la migrazione degli slot che contengono elementi con dimensioni serializzate superiori a 256 MB.
Per risolvere i problemi relativi agli elementi di grandi dimensioni, tieni in considerazione i seguenti suggerimenti:
+ Suddividi l'elemento composito di grandi dimensioni in più elementi più piccoli. Ad esempio, suddividi una raccolta di hash di grandi dimensioni in singoli campi chiave-valore con uno schema di nome della chiave che rifletta in modo appropriato la raccolta, ad esempio utilizzando un prefisso comune nel nome della chiave per identificare la raccolta di elementi. Se è necessario accedere atomicamente a più campi della stessa raccolta, è possibile utilizzare il comando MGET per recuperare più chiavi-valori nello stesso comando.
+ Se hai valutato tutte le opzioni ma non riesci ancora a suddividere il set di dati della raccolta di grandi dimensioni, prova a utilizzare comandi che operano su un sottoinsieme dei dati della raccolta anziché sull'intera raccolta. Evita il caso d'uso che richiede il recupero atomico dell'intera raccolta da più GB con lo stesso comando. Un esempio è l'utilizzo del comando HGET o HMGET anziché HGETALL nelle raccolte di hash.
# Configurazione del client Lettuce (Valkey e Redis OSS)
Questa sezione descrive le opzioni di configurazione consigliate per Java e Lettuce e come si applicano ai cluster. ElastiCache
I suggerimenti in questa sezione sono stati testati con Lettuce versione 6.2.2.
**Topics**
+ [Esempio: configurazione Lettuce per la modalità cluster, TLS abilitato](BestPractices.Clients-lettuce-cme.md)
+ [Esempio: configurazione Lettuce per la modalità cluster disattivata, TLS abilitato](BestPractices.Clients-lettuce-cmd.md)
**TTL della cache DNS Java**
Java Virtual Machine (JVM) memorizza nella cache le ricerche dei nomi DNS. Quando la JVM risolve un nome host in un indirizzo IP, memorizza l'indirizzo IP nella cache per un periodo di tempo specificato, noto come (TTL). *time-to-live*
La scelta di un valore TTL è un compromesso tra latenza e reattività al cambiamento. Con tempi più brevi TTLs, i resolver DNS notano gli aggiornamenti nel DNS del cluster più velocemente. Ciò può far sì che l'applicazione risponda più rapidamente alle sostituzioni o ad altri flussi di lavoro a cui è sottoposto il cluster. Tuttavia, se il TTL è troppo basso, aumenta il volume delle query, il che può aumentare la latenza dell'applicazione. Sebbene non esista un valore TTL corretto, quando si imposta il valore TTL è opportuno valutare il tempo che è possibile attendere affinché una modifica abbia effetto.
Poiché ElastiCache i nodi utilizzano voci di nome DNS che potrebbero cambiare, consigliamo di configurare la JVM con un TTL basso, compreso tra 5 e 10 secondi. In tal modo si garantisce che quando l'indirizzo IP di un nodo cambia, l'applicazione potrà ricevere e utilizzare il nuovo indirizzo IP della risorsa richiedendo la voce DNS.
In alcune configurazioni Java, il TTL predefinito di JVM è impostato in modo da non aggiornare mai le voci DNS finché JVM non viene riavviato.
Per dettagli su come impostare il TTL JVM, consulta [How to set the JVM TTL](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html#how-to-set-the-jvm-ttl) (Come impostare il TTL JVM).
**Versione Lettuce**
Consigliamo la versione Lettuce 6.2.2 o versioni successive.
**Endpoints**
Quando si utilizzano cluster abilitati in modalità cluster, impostare `redisUri` sull'endpoint di configurazione del cluster. La ricerca DNS per questo URI restituisce un elenco di tutti i nodi disponibili nel cluster e viene risolta casualmente in uno di essi durante l'inizializzazione del cluster. Per ulteriori dettagli su come funziona l'aggiornamento della topologia, vedere più avanti in questo argomento. *dynamicRefreshResources*
**SocketOption**
Abilita le [KeepAlive](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.KeepAliveOptions.html). L'abilitazione di questa opzione riduce la necessità di gestire le connessioni non riuscite durante il runtime del comando.
Assicurarsi di impostare il [timeout di connessione](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.Builder.html#connectTimeout-java.time.Duration-) in base ai requisiti dell'applicazione e al carico di lavoro. Per ulteriori informazioni, consulta la sezione relativa ai timeout più avanti in questo argomento.
**ClusterClientOption: opzioni client abilitate per la modalità cluster**
Abilita in [AutoReconnect](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#autoReconnect-boolean-)caso di interruzione della connessione.
Imposta [CommandTimeout](https://lettuce.io/core/release/api/io/lettuPrce/core/RedisURI.html#getTimeout--). Per ulteriori dettagli, consulta la sezione relativa ai timeout più avanti in questo argomento.
Impostare [NodeFilter](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#nodeFilter-java.util.function.Predicate-) per filtrare i nodi non riusciti dalla topologia. Lettuce salva tutti i nodi che si trovano nell'output dei "nodi del cluster" (inclusi i nodi con stato PFAIL/FAIL) nelle "partizioni" del client (note anche come partizioni). Durante il processo di creazione della topologia del cluster, tenta di connettersi a tutti i nodi della partizione. Questo comportamento di Lettuce, che consiste nell'aggiungere nodi non riusciti, può causare errori di connessione (o avvisi) quando i nodi vengono sostituiti per qualsiasi motivo.
Ad esempio, al termine di un failover e quando il cluster avvia il processo di ripristino, mentre clusterTopology si aggiorna, la mappa dei nodi del bus del cluster prevede un breve periodo di tempo in cui il nodo inattivo viene elencato come nodo non riuscito (FAIL), prima che venga completamente rimosso dalla topologia. Durante questo periodo, il client Lettuce lo considera un nodo sano e si connette continuamente ad esso. Ciò causa un errore dopo che il nuovo tentativo è esaurito.
Per esempio:
```
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);
```
**Nota**
Il filtraggio dei nodi viene utilizzato al meglio con DynamicRefreshSources set to true. Altrimenti, se la vista della topologia viene presa da un singolo nodo di origine problematico, che rileva un nodo primario non riuscito di qualche partizione, filtrerà questo nodo primario, il che comporterà la mancata copertura degli slot. La presenza di più nodi iniziali (quando DynamicRefreshSources è vero) riduce la probabilità che si verifichi questo problema, poiché almeno alcuni nodi iniziali dovrebbero avere una vista topologica aggiornata dopo un failover con il primario appena promosso.
**ClusterTopologyRefreshOptions: opzioni per controllare l'aggiornamento della topologia del cluster del client Cluster Mode Enabled**
**Nota**
I cluster con la modalità cluster disabilitata non supportano i comandi di rilevamento del cluster e non sono compatibili con la funzionalità di rilevamento della topologia dinamica di tutti i client.
La modalità cluster disabilitata con ElastiCache non è compatibile con Lettuce's. `MasterSlaveTopologyRefresh` Invece, per la modalità cluster disabilitata è possibile configurare un `StaticMasterReplicaTopologyProvider` e fornire gli endpoint di lettura e scrittura del cluster.
Per ulteriori informazioni sulla connessione a cluster disattivati, consulta [Ricerca degli endpoint (console) del cluster Valkey o Redis OSS (modalità cluster disabilitata)](Endpoints.md#Endpoints.Find.Redis).
Se desideri utilizzare la funzionalità di rilevamento della topologia dinamica di Lettuce, puoi creare un cluster con la modalità cluster abilitata con la stessa configurazione di partizioni del cluster esistente. Tuttavia, per i cluster abilitati alla modalità cluster, consigliamo di configurare almeno 3 shard con almeno una replica per supportare il failover rapido.
Abilita le [enablePeriodicRefresh](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enablePeriodicRefresh-java.time.Duration-). Ciò consente aggiornamenti periodici della topologia del cluster in modo che il client aggiorni la topologia del cluster negli intervalli refreshPeriod (impostazione predefinita: 60 secondi). Quando è disabilitato, il client aggiorna la topologia del cluster solo quando si verificano errori quando tenta di eseguire comandi sul cluster.
Con questa opzione abilitata, è possibile ridurre la latenza associata all'aggiornamento della topologia del cluster aggiungendo questo processo a un'attività in background. Sebbene l'aggiornamento della topologia venga eseguito in un processo in background, può essere piuttosto lento per i cluster con molti nodi. Questo perché vengono eseguite query sulle viste di tutti i nodi per ottenere la vista del cluster più aggiornata. Se si gestisce un cluster di grandi dimensioni, si potrebbe voler aumentare il periodo.
Abilita le [enableAllAdaptiveRefreshTriggers](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enableAllAdaptiveRefreshTriggers--). Ciò consente l'aggiornamento adattivo della topologia che utilizza tutti i [trigger](https://lettuce.io/core/6.1.6.RELEASE/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.RefreshTrigger.html): MOVED\$1REDIRECT, ASK\$1REDIRECT, PERSISTENT\$1RECONNECTS, UNCOVERED\$1SLOT, UNKNOWN\$1NODE. I trigger di aggiornamento adattivi avviano gli aggiornamenti della visualizzazione della topologia in base agli eventi che si verificano durante le operazioni del cluster Valkey o Redis OSS. L'attivazione di questa opzione comporta un aggiornamento immediato della topologia quando si verifica uno dei trigger precedenti. Gli aggiornamenti attivati adattivi hanno una frequenza limitata mediante un timeout perché gli eventi possono verificarsi su larga scala (timeout predefinito tra gli aggiornamenti: 30).
Abilita le [closeStaleConnections](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#closeStaleConnections-boolean-). Ciò consente di chiudere le connessioni obsolete durante l'aggiornamento della topologia del cluster. [Entra in vigore solo se. ClusterTopologyRefreshOptions isPeriodicRefreshEnabled ()](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.html#isPeriodicRefreshEnabled--) è vero. Quando è abilitato, il client può chiudere le connessioni obsolete e crearne di nuove in background. Ciò riduce la necessità di gestire le connessioni non riuscite durante il runtime del comando.
Abilita le [dynamicRefreshResources](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#dynamicRefreshSources-boolean-). Ti consigliamo di abilitarlo dynamicRefreshResources per i cluster di piccole dimensioni e di disabilitarlo per i cluster di grandi dimensioni. dynamicRefreshResourcesconsente di scoprire i nodi del cluster dal nodo iniziale fornito (ad esempio, l'endpoint di configurazione del cluster). Utilizza tutti i nodi rilevati come origine per aggiornare la topologia del cluster.
Utilizzando l'aggiornamento dinamico, esegue query su tutti i nodi rilevati per la topologia del cluster e tenta di scegliere la vista del cluster più accurata. Se è impostato su false, solo i nodi di origine iniziali vengono utilizzati come origini per l'individuazione della topologia e il numero di client viene ottenuto solo per i nodi di origine iniziali. Quando è disabilitato, se l'endpoint di configurazione del cluster viene risolto in un nodo non riuscito, il tentativo di aggiornare la vista del cluster restituisce un errore e genera delle eccezioni. Questo scenario può verificarsi perché è necessario del tempo prima che un nodo non riuscito venga rimosso dall'endpoint di configurazione del cluster. Pertanto, l'endpoint di configurazione può ancora essere risolto casualmente in un nodo non riuscito per un breve lasso di tempo.
Quando è abilitato, tuttavia, utilizziamo tutti i nodi del cluster ricevuti dalla vista del cluster per eseguire query sulla vista corrente. Poiché filtriamo i nodi non riusciti da quella vista, l'aggiornamento della topologia avverrà correttamente. Tuttavia, quando dynamicRefreshSources è vero, Lettuce interroga tutti i nodi per ottenere la visualizzazione del cluster e quindi confronta i risultati. Pertanto, l'operazione può essere costosa per i cluster con molti nodi. Consigliamo di disattivare questa funzionalità per i cluster con molti nodi.
```
final ClusterTopologyRefreshOptions topologyOptions =
ClusterTopologyRefreshOptions.builder()
.enableAllAdaptiveRefreshTriggers()
.enablePeriodicRefresh()
.dynamicRefreshSources(true)
.build();
```
**ClientResources**
Configura [DnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#dnsResolver-io.lettuce.core.resource.DnsResolver-) con [DirContextDnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DirContextDnsResolver.html). Il resolver DNS è basato su com.sun.jndi.dns di Java. DnsContextFactory.
Configurazione di [reconnectDelay](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#reconnectDelay-io.lettuce.core.resource.Delay-) con backoff esponenziale e jitter completo. Lettuce ha meccanismi di ripetizione incorporati basati sulle strategie di backoff esponenziale. Per maggiori dettagli, consulta [Exponential Backoff and Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter) sul blog di architettura. AWS Per ulteriori informazioni sull'importanza di adottare una strategia di backoff tra tentativi ripetuti, consulta le sezioni sulla logica di backoff del post sulle [best practice](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) sul Database Blog. 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();
```
**Timeout**
Usa un valore di timeout di connessione inferiore rispetto al timeout dei comandi. Lettuce utilizza l'avvio lento della connessione. Quindi, se il timeout di connessione è superiore al timeout del comando, si può avere un periodo di errore persistente dopo un aggiornamento della topologia se Lettuce tenta di connettersi a un nodo non integro e il timeout del comando viene sempre superato.
Utilizzo di un timeout dinamico dei comandi per diversi comandi. Consigliamo di impostare il timeout dei comandi in base alla durata prevista dei comandi. Ad esempio, utilizzare un timeout più lungo per i comandi che iterano su più chiavi, come FLUSHDB, FLUSHALL, KEYS, SMEMBERS o gli script Lua. Utilizzare timeout più brevi per i comandi a chiave singola, come SET, GET e HSET.
**Nota**
I timeout configurati nell'esempio seguente riguardano i test che eseguono comandi SET/GET con chiavi e valori lunghi fino a 20 byte. Il tempo di elaborazione può essere più lungo quando i comandi sono complessi o le chiavi e i valori sono più grandi. È necessario impostare i timeout in base al caso d'uso dell'applicazione.
```
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();
```
# Esempio: configurazione Lettuce per la modalità cluster, TLS abilitato
**Nota**
I timeout nell'esempio seguente riguardano i test che eseguono SET/GET comandi con chiavi e valori lunghi fino a 20 byte. Il tempo di elaborazione può essere più lungo quando i comandi sono complessi o le chiavi e i valori sono più grandi. È necessario impostare i timeout in base al caso d'uso dell'applicazione.
```
// 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();
```
# Esempio: configurazione Lettuce per la modalità cluster disattivata, TLS abilitato
**Nota**
I timeout nell'esempio seguente riguardano i test che eseguono SET/GET comandi con chiavi e valori lunghi fino a 20 byte. Il tempo di elaborazione può essere più lungo quando i comandi sono complessi o le chiavi e i valori sono più grandi. È necessario impostare i timeout in base al caso d'uso dell'applicazione.
```
// 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);
```
## Configurazione di un protocollo preferito per i cluster dual stack (Valkey e Redis OSS)
Per i cluster Valkey o Redis OSS abilitati alla modalità cluster, è possibile controllare il protocollo che i client utilizzeranno per connettersi ai nodi del cluster con il parametro IP Discovery. Il parametro IP Discovery può essere impostato su uno o. IPv4 IPv6
Per i cluster Valkey o Redis OSS, il parametro IP Discovery imposta il protocollo IP utilizzato nell'output degli [slot del cluster ()](https://valkey.io/commands/cluster-slots/), dei [cluster shard ()](https://valkey.io/commands/cluster-shards/) e [dei nodi del cluster](https://valkey.io/commands/cluster-nodes/) (). Questi comandi vengono utilizzati dai client per scoprire la topologia del cluster. I client utilizzano i comandi IPs in theses per connettersi agli altri nodi del cluster.
La modifica di IP Discovery non comporterà alcun tempo di inattività per i client connessi. Tuttavia, la propagazione delle modifiche richiederà tempo. Per determinare quando le modifiche si sono propagate completamente per un cluster Valkey o Redis OSS, monitora l'output di. `cluster slots` Una volta che tutti i nodi restituiti dal comando cluster slots hanno riportato il nuovo protocollo, IPs le modifiche hanno terminato la propagazione.
Esempio con 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)
```
Esempio con 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;
}));
```
# Le migliori pratiche per i clienti (Memcached)
Scopri le best practice per scenari comuni con i cluster ElastiCache Memcached.
**Topics**
+ [Configurazione ElastiCache del client per un bilanciamento efficiente del carico (Memcached)](BestPractices.LoadBalancing.md)
+ [Client convalidati con Memcached](network-type-validated-clients-memcached.md)
+ [Configurazione di un protocollo preferito per i cluster dual stack (Memcached)](network-type-configuring-dual-stack-memcached.md)
# Configurazione ElastiCache del client per un bilanciamento efficiente del carico (Memcached)
**Nota**
Questa sezione si applica ai cluster Memcached multinodo basati su nodi.
Per utilizzare in modo efficace più nodi ElastiCache Memcached, è necessario essere in grado di distribuire le chiavi della cache tra i nodi. *Un modo semplice per bilanciare il carico di un cluster con *n* nodi consiste nel calcolare l'hash della chiave dell'oggetto e modificare il risultato per n:.* `hash(key) mod n` Il valore risultante (da 0 a *n*-1) è il numero del nodo in cui inserisci l'oggetto.
Questo approccio è semplice ed efficace, purché il numero dei nodi (*n*) sia costante. Quando aggiungi o rimuovi un nodo dal cluster, il numero di chiavi da spostare corrisponde tuttavia a *(n - 1) / n* (dove *n* è il nuovo numero di nodi). Con questo approccio, il numero di chiavi da spostare è pertanto maggiore, con un conseguente numero elevato di mancati riscontri nella cache iniziali, specialmente man mano che aumenta il numero dei nodi. Con il dimensionamento da 1 a 2 nodi, viene spostato un numero di chiavi pari a (2-1)/2 (50 percento), ovvero il caso migliore. Con il dimensionamento da 9 a 10 nodi, viene spostato un numero di chiavi pari a (10-1)/10 (90 percento). In caso di un dimensionamento dovuto a un picco nel traffico, è bene evitare un elevato numero di mancati riscontri nella cache, in quanto ciò causerebbe hit nel database, già sovraccaricato dai picchi di traffico.
La soluzione a tale problema è rappresentata da un hashing coerente, L’hashing coerente utilizza un algoritmo in modo tale che quando un nodo viene aggiunto o rimosso da un cluster, il numero di chiavi da spostare è circa *1/n* (dove *n* è il nuovo numero di nodi). Passando da 1 a 2 nodi, viene spostato un numero di chiavi pari a 1/2 (50 percento), ovvero il caso peggiore. Passando da 9 a 10 nodi, viene spostato un numero di chiavi pari a 1/10 (10 percento).
Sei tu, in qualità di utente, che controlli l'algoritmo di hashing utilizzato per il cluster a più nodi. Ti consigliamo di configurare i client in modo da utilizzare un hashing coerente. Fortunatamente, sono disponibili numerose librerie client Memcached nei linguaggi più comuni in grado di implementare l'hashing coerente. Consulta la documentazione della libreria che utilizzi per verificare se supporta l'hashing coerente e ottenere informazioni su come implementarlo.
Se lavori in Java, PHP o.NET, ti consigliamo di utilizzare una delle librerie ElastiCache client Amazon.
## Hashing coerente in Java
Il client Java ElastiCache Memcached si basa sul client Java open source spymemcached, che dispone di funzionalità di hashing coerenti integrate. La libreria include una classe che implementa un hashing coerente. KetamaConnectionFactory Per impostazione predefinita, l'hashing coerente è disattivato in spymemcached.
Per ulteriori informazioni, consultate la KetamaConnectionFactory documentazione all'indirizzo. [KetamaConnectionFactory](https://github.com/RTBHOUSE/spymemcached/blob/master/src/main/java/net/spy/memcached/KetamaConnectionFactory.java)
## Hashing coerente con PHP con Memcached
Il client PHP ElastiCache Memcached è un wrapper della libreria PHP Memcached integrata. Per impostazione predefinita, l'hashing coerente è disattivato dalla libreria PHP Memcached.
Per attivare l'hashing coerente, utilizza il seguente codice.
```
$m = new Memcached();
$m->setOption(Memcached::OPT_DISTRIBUTION, Memcached::DISTRIBUTION_CONSISTENT);
```
Oltre al codice precedente, ti consigliamo anche di attivare `memcached.sess_consistent_hash` nel file php.ini.
[Per ulteriori informazioni, consulta la documentazione di configurazione in fase di esecuzione per Memcached PHP all'indirizzo http://php. net/manual/en/memcached.configurazione.php.](http://php.net/manual/en/memcached.configuration.php) Nota in particolare il parametro `memcached.sess_consistent_hash`.
## Hashing coerente utilizzando.NET con Memcached
Il client ElastiCache Memcached .NET è un wrapper per Enyim Memcached. Per impostazione predefinita, l'hashing coerente è attivato dal client Enyim Memcached.
[Per ulteriori informazioni, consulta la documentazione in -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)
# Client convalidati con Memcached
I seguenti client sono stati specificamente convalidati per funzionare con tutte le configurazioni dei tipi di rete supportate per Memcached.
Clienti convalidati:
+ [AWS ElastiCache Cluster Client Memcached](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php) [per Php — versione \$13.6.2](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php/tree/v3.2.0)
+ [AWS ElastiCache Cluster Client Memcached](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-java) per Java: master più recente su Github
# Configurazione di un protocollo preferito per i cluster dual stack (Memcached)
Per cluster Memcached puoi controllare il protocollo che verrà utilizzato dai client per connettersi ai nodi del cluster con il parametro IP Discovery. Il parametro IP Discovery può essere impostato su o. IPv4 IPv6
Il parametro IP Discovery controlla il protocollo IP utilizzato nell'output del cluster config get. Il che a sua volta determinerà il protocollo IP utilizzato dai client che supportano l'individuazione automatica ElastiCache per i cluster Memcached.
La modifica di IP Discovery non comporterà alcun tempo di inattività per i client connessi. Tuttavia, la propagazione delle modifiche richiederà tempo.
Monitorare l'output di `getAvailableNodeEndPoints` per Java e per Php monitorare l'output di `getServerList`. Una volta che l'output di queste funzioni riporta i risultati IPs per tutti i nodi del cluster che utilizzano il protocollo aggiornato, le modifiche hanno terminato la propagazione.
Esempio di Java
```
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;
}));
```
Esempio di Php:
```
$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);
```
Le eventuali connessioni client esistenti create prima dell'aggiornamento di IP Discovery, verranno comunque connesse utilizzando il vecchio protocollo. Tutti i client convalidati si riconnetteranno automaticamente al cluster utilizzando il nuovo protocollo IP una volta rilevate le modifiche nell'output dei comandi di individuazione del cluster. Tuttavia, ciò dipende dall'implementazione del client.
## Cluster dual ElastiCache stack abilitati per TLS
Quando TLS è abilitato per ElastiCache i cluster, le funzioni di rilevamento del cluster (`cluster slots``cluster shards`, e `cluster nodes` per Redis) o `config get cluster`per Memcached restituiscono nomi di host anziché. IPs I nomi host vengono quindi utilizzati anziché per connettersi al cluster ed eseguire IPs un handshake TLS. ElastiCache Ciò significa che i client non sono interessati dal parametro Individuazione IP. Per i cluster abilitati per TLS, il parametro Individuazione IP non ha alcun effetto sul protocollo IP preferito. Invece, il protocollo IP utilizzato verrà determinato in base a quello preferito dal client durante la risoluzione dei nomi host DNS.
**Client Java**
Quando ci si connette da un ambiente Java che supporta entrambi IPv4 e IPv6, IPv6 per impostazione predefinita Java preferisce la compatibilità con le IPv4 versioni precedenti. Tuttavia, la preferenza del protocollo IP è configurabile tramite gli argomenti JVM. Per preferire IPv4, la JVM accetta `-Djava.net.preferIPv4Stack=true` e per preferire impostato. IPv6 `-Djava.net.preferIPv6Stack=true` L'impostazione `-Djava.net.preferIPv4Stack=true` significa che la JVM non effettuerà più alcuna connessione. IPv6 **Per Valkey o Redis OSS, ciò include quelle verso altre applicazioni non Valkey e non Redis OSS.**
**Preferenze a livello di host**
In generale, se il client o il runtime client non forniscono opzioni di configurazione per l'impostazione di una preferenza del protocollo IP, quando si esegue la risoluzione DNS, il protocollo IP dipenderà dalla configurazione dell'host. Per impostazione predefinita, la maggior parte degli host preferisce questa IPv6 preferenza, IPv4 ma questa preferenza può essere configurata a livello di host. Ciò influirà su tutte le richieste DNS provenienti dall'host, non solo su quelle ai ElastiCache cluster.
**Host Linux**
Per Linux, una preferenza protocollo IP può essere configurata modificando il file `gai.conf`. Il file `gai.conf` è disponibile in `/etc/gai.conf`. Se non è specificato alcun `gai.conf`, uno di esempio deve essere disponibile in `/usr/share/doc/glibc-common-x.xx/gai.conf` che può essere copiato in `/etc/gai.conf`; è quindi necessario rimuovere i commenti dalla configurazione predefinita. Per aggiornare la configurazione da preferire IPv4 quando ci si connette a un ElastiCache cluster, aggiorna la precedenza per l'intervallo CIDR che comprende il cluster in modo che sia superiore IPs alla precedenza per le connessioni predefinite. IPv6 Per impostazione predefinita, IPv6 le connessioni hanno una precedenza di 40. Ad esempio, supponendo che il cluster si trovi in una sottorete con CIDR 172.31.0. 0:0 /16, la configurazione seguente farebbe sì che i client preferiscano le connessioni a quel cluster. 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
```
[Maggiori dettagli su sono disponibili nella pagina man di Linux `gai.conf`](https://man7.org/linux/man-pages/man5/gai.conf.5.html)
**Host Windows**
Il processo per gli host Windows è simile. Per gli host Windows è possibile eseguire `netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL`. L'effetto è identico alla modifica del file `gai.conf` su host Linux.
Ciò aggiornerà le politiche di preferenza per preferire IPv4 le connessioni alle IPv6 connessioni per l'intervallo CIDR specificato. Ad esempio, supponendo che il cluster si trovi in una sottorete con esecuzione CIDR 172.31.0. 0:0 /16, `netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15` risulterebbe la seguente tabella di precedenza che farebbe sì che i client preferiscano la connessione al cluster. 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
```
# Gestione della memoria riservata per Valkey e Redis OSS
La memoria prenotata è la memoria destinata all'utilizzo diverso dai dati. Quando si esegue un backup o un failover, Valkey e Redis OSS utilizzano la memoria disponibile per registrare le operazioni di scrittura sul cluster mentre i dati del cluster vengono scritti nel file.rdb. Se non disponi di memoria sufficiente per tutte le scritture, il processo non va a buon fine. Di seguito, è possibile trovare informazioni sulle opzioni per la gestione della memoria riservata ElastiCache per Redis OSS e su come applicarle.
**Topics**
+ [Qual è la quantità di memoria prenotata necessaria?](#redis-memory-management-need)
+ [Parametri per gestire memoria prenotata](#redis-memory-management-parameters)
+ [Specifica del parametro di gestione della memoria prenotata](#redis-reserved-memory-management-change)
## Qual è la quantità di memoria prenotata necessaria?
Se utilizzi una versione di Redis OSS precedente alla 2.8.22, riserva più memoria per i backup e i failover rispetto a Redis OSS 2.8.22 o successiva. Questo requisito è dovuto ai diversi modi in cui Redis OSS implementa il processo di backup. ElastiCache La regola generale consiste nel riservare metà del `maxmemory` valore di un tipo di nodo all'overhead Redis OSS per le versioni precedenti alla 2.8.22 e un quarto per le versioni Redis OSS 2.8.22 e successive.
A causa delle diverse modalità di ElastiCache implementazione del processo di backup e replica, la regola generale consiste nel riservare il 25% del valore di un tipo di nodo utilizzando il parametro. `maxmemory` `reserved-memory-percent` Questo è il valore predefinito e consigliato nella maggior parte dei casi.
Quando i tipi di istanze micro e piccole istanze burstable funzionano vicino `maxmemory` ai limiti, è possibile che si verifichi l'utilizzo dello swap. Per migliorare l'affidabilità operativa di questi tipi di istanze durante il backup, la replica e il traffico elevato, consigliamo di aumentare il valore del `reserved-memory-percent` parametro fino al 30% sui tipi di istanze di piccole dimensioni e fino al 50% sui tipi di micro istanze.
Per carichi di lavoro impegnativi in scrittura su ElastiCache cluster con tiering dei dati, consigliamo di aumentare la memoria disponibile del nodo fino `reserved-memory-percent` al 50%.
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md)
+ [Modalità di implementazione di sincronizzazione e backup](Replication.Redis.Versions.md)
+ [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md)
## Parametri per gestire memoria prenotata
A partire dal 16 marzo 2017, Amazon ElastiCache fornisce due parametri che si escludono a vicenda per la gestione della memoria Valkey o Redis OSS e. `reserved-memory` `reserved-memory-percent` Nessuno di questi parametri fa parte della distribuzione Valkey o Redis OSS.
A seconda di quando sei diventato ElastiCache cliente, l'uno o l'altro di questi parametri è il parametro di gestione della memoria predefinito. Questo parametro si applica quando si crea un nuovo cluster o gruppo di replica Valkey o Redis OSS e si utilizza un gruppo di parametri predefinito.
+ Per i clienti che hanno iniziato prima del 16 marzo 2017: quando si crea un cluster o un gruppo di replica Redis OSS utilizzando il gruppo di parametri predefinito, il parametro di gestione della memoria è. `reserved-memory` In questo caso, zero (0) byte di memoria sono riservati.
+ Per i clienti che hanno iniziato il 16 marzo 2017 o dopo tale data: quando si crea un cluster o un gruppo di replica Valkey o Redis OSS utilizzando il gruppo di parametri predefinito, il parametro di gestione della memoria è. `reserved-memory-percent` In questo caso, il 25% del valore `maxmemory` del nodo è riservato per scopi non dati.
Dopo aver letto i due parametri di gestione della memoria Valkey o Redis OSS, potresti preferire utilizzare quello che non è quello predefinito o con valori non predefiniti. In questo caso, puoi passare all'altro parametro di gestione della memoria prenotata.
Per modificare il valore di tale parametro, è possibile creare un gruppo di parametri personalizzato e modificarlo in modo da utilizzare il parametro e il valore di gestione della memoria preferiti. È quindi possibile utilizzare il gruppo di parametri personalizzato ogni volta che si crea un nuovo cluster o gruppo di replica Valkey o Redis OSS. Per cluster o gruppi di replica esistenti, puoi modificarli per utilizzare il gruppo di parametri personalizzato.
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Specifica del parametro di gestione della memoria prenotata](#redis-reserved-memory-management-change)
+ [Creazione di un gruppo di ElastiCache parametri](ParameterGroups.Creating.md)
+ [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md)
+ [Modifica di un cluster ElastiCache](Clusters.Modify.md)
+ [Modifica di un gruppo di replica](Replication.Modify.md)
### Il parametro reserved-memory
Prima del 16 marzo 2017, tutta la gestione della memoria riservata ElastiCache per Redis OSS veniva eseguita utilizzando il parametro. `reserved-memory` Il valore di default di `reserved-memory` è 0. Questa impostazione predefinita non riserva memoria per il sovraccarico di Valkey o Redis OSS e consente a Valkey o Redis OSS di consumare tutta la memoria di un nodo con i dati.
La modifica di `reserved-memory` per disporre di memoria sufficiente per i backup e i failover, richiede la creazione di un gruppo di parametri personalizzato. In questo gruppo di parametri personalizzati, viene impostato `reserved-memory` un valore appropriato per la versione Valkey o Redis OSS in esecuzione sul cluster e il tipo di nodo del cluster. Per ulteriori informazioni, consulta [Qual è la quantità di memoria prenotata necessaria?](#redis-memory-management-need)
Il parametro `reserved-memory` è specifico ElastiCache e non fa parte della distribuzione generale Redis OSS.
La procedura seguente mostra come utilizzare per `reserved-memory` gestire la memoria sul cluster Valkey o Redis OSS.
**Per prenotare la memoria utilizzando la memoria prenotata**
1. Creare un gruppo di parametri personalizzato specificando la famiglia di gruppi di parametri corrispondente alla versione del motore in esecuzione, ad esempio specificando la proprietà`redis2.8`famiglia di gruppi di parametri. Per ulteriori informazioni, consulta [Creazione di un gruppo di ElastiCache parametri](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. Calcola quanti byte di memoria riservare per il sovraccarico di Valkey o Redis OSS. Il valore di `maxmemory` per il tipo di nodo è disponibile in [Parametri specifici del tipo di nodo Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).
1. Modificare il gruppo di parametri personalizzato in modo che il parametro `reserved-memory` corrisponda al numero di byte calcolati nella fase precedente. L' AWS CLI esempio seguente presuppone che tu stia utilizzando una versione di Redis OSS precedente alla 2.8.22 e che sia necessario riservare metà di quella del nodo. `maxmemory` Per ulteriori informazioni, consulta [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis28-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=7130316800"
```
Occorre un gruppo di parametri personalizzato separato per ogni tipo di nodo in uso, perché ogni tipo di nodo dispone di un valore `maxmemory` diverso. Pertanto, ogni tipo di nodo richiede un valore diverso per `reserved-memory`.
1. Modifica il cluster o il gruppo di replica Redis OSS per utilizzare il gruppo di parametri personalizzato.
L'esempio CLI seguente modifica il cluster ` my-redis-cluster` per utilizzare da subito il gruppo di parametri personalizzato `redis28-m3xl`. Per ulteriori informazioni, consulta [Modifica di un cluster ElastiCache](Clusters.Modify.md).
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
L'esempio CLI seguente modifica il gruppo di replica `my-redis-repl-grp` per utilizzare da subito il gruppo di parametri personalizzato `redis28-m3xl`. Per ulteriori informazioni, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
### Parametro reserved-memory-percent
Il 16 marzo 2017, Amazon ElastiCache ha introdotto il parametro `reserved-memory-percent` e lo ha reso disponibile su tutte le versioni ElastiCache di Redis OSS. Lo scopo di `reserved-memory-percent` è semplificare la gestione della memoria prenotata tra tutti i cluster. A tal fine, l'utente può disporre di un singolo gruppo di parametri per ogni famiglia di gruppo di parametri (ad esempio `redis2.8`) per gestire la memoria prenotata dei cluster, a prescindere dal tipo di nodo. Il valore di default per `reserved-memory-percent` è 25 (25 percento).
Il parametro `reserved-memory-percent` è specifico ElastiCache e non fa parte della distribuzione generale Redis OSS.
Se il cluster utilizza un tipo di nodo della famiglia r6gd e l'utilizzo della memoria raggiunge il 75%, il tiering di dati verrà attivato automaticamente. Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
**Per riservare memoria utilizzando reserved-memory-percent**
Da utilizzare `reserved-memory-percent` per gestire la memoria sul cluster ElastiCache for Redis OSS, esegui una delle seguenti operazioni:
+ Se utilizzi Redis OSS 2.8.22 o versione successiva, assegna il gruppo di parametri predefinito al cluster. Il valore di default di 25 percento dovrebbe essere adeguato. In caso contrario, attenersi alla procedura descritta di seguito per modificare il valore.
+ Se utilizzi una versione di Redis OSS precedente alla 2.8.22, probabilmente dovrai riservare più memoria rispetto al 25 percento predefinito. `reserved-memory-percent` A tale scopo, procedi come indicato di seguito.
**Per modificare il valore percentuale di reserved-memory-percent**
1. Creare un gruppo di parametri personalizzato specificando la famiglia di gruppi di parametri corrispondente alla versione del motore in esecuzione, ad esempio specificando la famiglia di gruppi di parametri `redis2.8`. Un gruppo di parametri di default è necessario perché non è possibile modificare un gruppo di parametri di default. Per ulteriori informazioni, consulta [Creazione di un gruppo di ElastiCache parametri](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
```
Poiché `reserved-memory-percent` consente di riservare memoria con una percentuale della `maxmemory` del nodo, non è necessario un gruppo di parametri personalizzato per ogni tipo di nodo.
1. Modificare il gruppo di parametri personalizzato in modo che `reserved-memory-percent` sia 50 (50 percento). Per ulteriori informazioni, consulta [Modifica di un gruppo di ElastiCache parametri](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. Utilizzate questo gruppo di parametri personalizzato per qualsiasi cluster o gruppo di replica Redis OSS che esegue una versione di Redis OSS precedente alla 2.8.22.
L'esempio CLI seguente modifica il cluster Redis OSS `my-redis-cluster` per utilizzare il gruppo di parametri personalizzato a partire da subito. `redis28-50` Per ulteriori informazioni, consulta [Modifica di un cluster ElastiCache](Clusters.Modify.md).
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
L'esempio CLI seguente modifica il gruppo di replica Redis OSS `my-redis-repl-grp` per utilizzare il gruppo di parametri personalizzato a partire da subito. `redis28-50` Per ulteriori informazioni, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
## Specifica del parametro di gestione della memoria prenotata
Se eri un ElastiCache cliente attuale il 16 marzo 2017, il tuo parametro di gestione della memoria riservata predefinito è `reserved-memory` pari a zero (0) byte di memoria riservata. Se sei diventato ElastiCache cliente dopo il 16 marzo 2017, il tuo parametro di gestione della memoria riservata predefinito prevede `reserved-memory-percent` il 25 percento della memoria riservata del nodo. Questo vale indipendentemente dal momento in cui hai creato il cluster o il gruppo di replica ElastiCache per Redis OSS. Tuttavia, è possibile modificare il parametro di gestione della memoria riservata utilizzando l'API AWS CLI o ElastiCache .
I parametri `reserved-memory` e `reserved-memory-percent` sono mutuamente esclusivi. Un gruppo di parametri ne conterrà sempre uno ma non entrambi. Puoi cambiare il parametro utilizzato da un gruppo di parametri per la gestione della memoria prenotata modificando il gruppo di parametri. Il gruppo di parametri deve essere un gruppo di parametri personalizzato, perché non puoi modificare i gruppi di parametri di default. Per ulteriori informazioni, consulta [Creazione di un gruppo di ElastiCache parametri](ParameterGroups.Creating.md).
**Per specificare reserved-memory-percent**
Per utilizzare `reserved-memory-percent` come parametro di gestione della memoria prenotata, modifica un gruppo di parametri personalizzato utilizzando il comando `modify-cache-parameter-group`. Utilizzo del parametro `parameter-name-values` per specificare `reserved-memory-percent` e un valore per esso.
L'esempio CLI seguente modifica il gruppo di parametri personalizzato `redis32-cluster-on` in modo che utilizzi `reserved-memory-percent` per gestire memoria prenotata. Affinché il gruppo di parametri utilizzi il parametro `ParameterName` per la gestione della memoria prenotata, occorre assegnare un valore a `ParameterValue`. Per ulteriori informazioni, consulta [Modifica di un gruppo di ElastiCache parametri](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"
```
**Per specificare la memoria reserved-memory**
Per utilizzare `reserved-memory` come parametro di gestione della memoria prenotata, modifica un gruppo di parametri personalizzato utilizzando il comando `modify-cache-parameter-group`. Utilizzo del parametro `parameter-name-values` per specificare `reserved-memory` e un valore per esso.
L'esempio CLI seguente modifica il gruppo di parametri personalizzato `redis32-m3xl` in modo che utilizzi `reserved-memory` per gestire memoria prenotata. Affinché il gruppo di parametri utilizzi il parametro `ParameterName` per la gestione della memoria prenotata, occorre assegnare un valore a `ParameterValue`. Poiché la versione del motore è più recente di 2.8.22, impostiamo il valore su `3565158400` che è 25 percento di una `maxmemory` di `cache.m3.xlarge`. Per ulteriori informazioni, consulta [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis32-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=3565158400"
```
# Procedure consigliate per l'utilizzo di cluster basati su nodi Valkey e Redis OSS
L'uso della tecnologia Multi-AZ, la disponibilità di memoria sufficiente, il ridimensionamento dei cluster e la riduzione al minimo dei tempi di inattività sono tutti concetti utili da tenere a mente quando si lavora con cluster basati su nodi in Valkey o Redis OSS. Ti consigliamo di esaminare e seguire queste best practices.
**Topics**
+ [Ridurre al minimo i tempi di inattività con la funzione Multi-AZ](multi-az.md)
+ [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md)
+ [Ridimensionamento di cluster online](best-practices-online-resharding.md)
+ [Riduzione al minimo dei tempi di inattività durante la manutenzione](BestPractices.MinimizeDowntime.md)
# Ridurre al minimo i tempi di inattività con la funzione Multi-AZ
Esistono diversi casi in cui ElastiCache Valkey o Redis OSS potrebbero dover sostituire un nodo primario; questi includono alcuni tipi di manutenzione pianificata e l'improbabile evento di un guasto del nodo primario o della zona di disponibilità.
Questa sostituzione comporta alcuni tempi di inattività per il cluster, ma se la funzione Multi-AZ è abilitata, il tempo di inattività viene ridotto al minimo. Il ruolo del nodo primario eseguirà automaticamente il failover su una delle repliche di lettura. Non è necessario creare ed effettuare il provisioning di un nuovo nodo primario, in quanto ElastiCache gestirà il problema in modo trasparente. Questo failover e la promozione delle repliche garantiscono la possibilità di ricominciare a scrivere nel nuovo nodo primario non appena la promozione è terminata.
Vedi[Riduzione al minimo dei tempi di inattività ElastiCache utilizzando Multi-AZ con Valkey e Redis OSS](AutoFailover.md), per saperne di più su Multi-AZ e sulla riduzione al minimo dei tempi di inattività.
# Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS
**Istantanee e sincronizzazioni in Valkey 7.2 e versioni successive e Redis OSS versione 2.8.22 e successive**
Valkey offre il supporto predefinito per istantanee e sincronizzazioni. Redis OSS 2.8.22 introduce un processo di salvataggio senza forkless che consente di allocare una maggiore quantità di memoria all'uso dell'applicazione senza aumentare l'utilizzo dello swap durante le sincronizzazioni e i salvataggi. Per ulteriori informazioni, consulta [Modalità di implementazione di sincronizzazione e backup](Replication.Redis.Versions.md).
**Istantanee e sincronizzazioni Redis OSS precedenti alla versione 2.8.22**
Quando si lavora con ElastiCache Redis OSS, Redis OSS richiama un comando di scrittura in background in diversi casi:
+ Durante la creazione di uno snapshot per un backup.
+ Durante la sincronizzazione delle repliche con il nodo principale in un gruppo di repliche
+ Quando si abilita la funzionalità di sola aggiunta di file (AOF) per Redis OSS.
+ Durante la promozione di una replica a primaria (che causa una sincronizzazione tra nodi principali/replica).
Ogni volta che Redis OSS esegue un processo di scrittura in background, è necessario disporre di memoria disponibile sufficiente per far fronte al sovraccarico del processo. La mancanza di memoria sufficiente provoca un errore del processo. Per questo motivo, è importante scegliere un tipo di istanza di nodo con memoria sufficiente durante la creazione del cluster Redis OSS.
## Processo di scrittura in background e utilizzo della memoria con Valkey e Redis OSS
Ogni volta che viene chiamato un processo di scrittura in background, Valkey e Redis OSS ne eseguono un fork (ricordate che questi motori sono a thread singolo). Un fork mantiene i dati su disco in un file snapshot Redis OSS .rdb. Tutti gli altri servizi fork eseguono operazioni di lettura e scrittura. Per garantire che l'istantanea sia un' point-in-timeistantanea, tutti gli aggiornamenti e le aggiunte ai dati vengono scritti in un'area di memoria disponibile separata dall'area dati.
Finché è disponibile memoria sufficiente per registrare tutte le operazioni di scrittura mentre i dati vengono resi persistenti sul disco, non si dovrebbero avere problemi di memoria insufficiente. Potresti riscontrare problemi di memoria insufficiente qualora si verifichi uno dei seguenti casi:
+ L'applicazione esegue molte operazioni di scrittura e richiede pertanto un'elevata quantità di memoria disponibile per accettare dati nuovi o aggiornati.
+ Hai a disposizione una quantità di memoria veramente limitata in cui scrivere dati nuovi o aggiornati.
+ Il set di dati di cui disponi è di grandi dimensioni. Poiché per essere reso persistente sul disco è necessario molto tempo, sono necessarie numerose operazioni di scrittura.
Il diagramma seguente illustra l'utilizzo della memoria durante l'esecuzione di un processo di scrittura in background.
![\[Immagine. Diagramma dell'utilizzo della memoria durante una scrittura in background.\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-bgsaveMemoryUseage.png)
Per informazioni sull'impatto di un backup sulle prestazioni, consulta [Impatto sulle prestazioni dei backup di cluster basati su nodi](backups.md#backups-performance).
[Per ulteriori informazioni su come Valkey e Redis OSS eseguono le istantanee, consulta http://valkey.io.](http://valkey.io)
Per ulteriori informazioni sulle regioni e sulle zone di disponibilità, consulta [Scelta delle regioni e delle zone di disponibilità per ElastiCache](RegionsAndAZs.md).
## Come evitare di esaurire la memoria durante l'esecuzione di una scrittura in background
Ogni volta che `BGREWRITEAOF` viene chiamato un processo di scrittura in background come `BGSAVE` o, per evitare che il processo abbia esito negativo, è necessario disporre di più memoria di quella che verrà consumata dalle operazioni di scrittura durante il processo. Lo scenario peggiore è che durante l'operazione di scrittura in background ogni record venga aggiornato e alcuni nuovi record vengano aggiunti alla cache. Per questo motivo, si consiglia di impostare su 50 (50 percento) per le versioni Redis OSS precedenti `reserved-memory-percent` alla 2.8.22 o su 25 (25 percento) per Valkey e tutte le versioni Redis OSS 2.8.22 e successive.
Il valore `maxmemory` indica la memoria che hai a disposizione per i dati e il sovraccarico operativo. Poiché non puoi modificare il parametro `reserved-memory` nel gruppo di parametri di default, devi creare un gruppo di parametri personalizzato per il cluster. Il valore predefinito per `reserved-memory` è 0, che consente a Redis OSS di consumare tutta la *memoria massima con i dati, lasciando potenzialmente troppo poca memoria* per altri usi, ad esempio un processo di scrittura in background. Per i valori di `maxmemory` per tipo di istanza del nodo, consulta [Parametri specifici del tipo di nodo Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).
È inoltre possibile utilizzare il `reserved-memory` parametro per ridurre la quantità di memoria utilizzata sulla confezione.
Per ulteriori informazioni sui parametri specifici di Valkey e Redis in, vedere. ElastiCache [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
Per informazioni sulla creazione e sulla modifica di gruppi di parametri, consulta [Creazione di un gruppo di ElastiCache parametri](ParameterGroups.Creating.md) e [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md).
# Ridimensionamento di cluster online
Il *resharding * implica l'aggiunta e la rimozione di partizioni o nodi nel cluster e la ridistribuzione di spazi chiave. Diversi fattori hanno pertanto impatto sull'operazione di resharding, come il carico sul cluster, l'utilizzo della memoria e la dimensione complessiva dei dati. Per un'esperienza ottimale, ti consigliamo di attenerti a tutte le best practice relative al cluster per una distribuzione uniforme dei modelli di carico di lavoro. È inoltre consigliabile completare i passaggi indicati di seguito.
Prima di avviare il resharding, ti consigliamo di effettuare quanto segue:
+ **Testa la tua applicazione** - Testa il comportamento della tua applicazione durante il resharding in un ambiente di gestione temporanea, se possibile.
+ **Ottieni una notifica immediata dei problemi di dimensionamento** - Il resharding è un'operazione che richiede notevoli risorse di calcolo. Per questo motivo, consigliamo di mantenere l'utilizzo della CPU al di sotto dell'80% sulle istanze multicore e a meno del 50% sulle istanze single core durante il resharding. Monitora ElastiCache le metriche Redis OSS e avvia il resharding prima che l'applicazione inizi a rilevare problemi di scalabilità. Parametri utili da considerare sono `CPUUtilization`, `NetworkBytesIn`, `NetworkBytesOut`, `CurrConnections`, `NewConnections`, `FreeableMemory`, `SwapUsage` e `BytesUsedForCacheItems`.
+ **Verifica che sia disponibile memoria sufficiente per il dimensionamento** - Se esegui il dimensionamento, assicurati che la memoria libera disponibile sule partizioni da conservare sia almeno 1,5 volte quella utilizzata sule partizioni che desideri rimuovere.
+ **Avvia il resharding durante orari non di punta** Ciò consente di ridurre la latenza e l'impatto sulla velocità effettiva per il client durante l'operazione di resharding. In questo modo, il resharding viene inoltre completato più rapidamente, in quanto è possibile utilizzare più risorse per la ridistribuzione degli slot.
+ **Analizza il comportamento di timeout del client** - Alcuni client potrebbero presentare una latenza più elevata durante il dimensionamento del cluster online. Può essere utile configurare la libreria client con un timeout maggiore, in quanto aumenta il tempo a disposizione del sistema per eseguire la connessione, anche in caso di condizioni di carico più elevato sul server. In alcuni casi è possibile che si desideri aprire un numero elevato di connessioni al server. I questi casi considera la necessità di aggiungere backoff esponenziale alla logica di riconnessione. In questo modo è possibile evitare l'aumento di nuove connessioni eseguite contemporaneamente sul server.
+ **Carica le tue funzioni su ogni shard**: durante la scalabilità orizzontale del cluster, replica ElastiCache automaticamente le funzioni caricate in uno dei nodi esistenti (selezionati a caso) sui nuovi nodi. Se il tuo cluster ha Valkey 7.2 e versioni successive o Redis OSS 7.0 o versioni successive e la tua applicazione utilizza [Functions](https://valkey.io/topics/functions-intro/), ti consigliamo di caricare tutte le tue funzioni su tutti gli shard prima di scalare in modo che il cluster non finisca con funzioni diverse su shard diversi.
Dopo il resharding, tieni presente quanto segue:
+ Il dimensionamento potrebbe riuscire parzialmente se la memoria disponibile nele partizioni di destinazione non è sufficiente. In tal caso, controlla la memoria disponibile e prova di nuovo a eseguire l'operazione, se necessario. I dati sulle partizioni di destinazione non verranno eliminati.
+ I comandi `FLUSHALL` e `FLUSHDB` non sono supportati negli script Lua durante un'operazione di riassegnazione delle partizioni. Nelle versioni precedenti a Redis OSS 6, il `BRPOPLPUSH` comando non era supportato se opera sullo slot da migrare.
# Riduzione al minimo dei tempi di inattività durante la manutenzione
La configurazione in modalità cluster ha la migliore disponibilità durante le operazioni gestite o non gestite. Si consiglia di utilizzare un client supportato in modalità cluster che si connette all'endpoint di individuazione del cluster. Per la modalità cluster disattivata, si consiglia di utilizzare l'endpoint primario per tutte le operazioni di scrittura.
Per attività di lettura, le applicazioni possono inoltre connettersi a qualsiasi nodo nel cluster. A differenza dell'endpoint primario, gli endpoint dei nodi vengono risolti in endpoint specifici. Se apporti una modifica al cluster, ad esempio aggiungendo o eliminando una replica, devi aggiornare gli endpoint dei nodi nell'applicazione. Questo è il motivo per cui, con la modalità cluster disabilitata, ti consigliamo di utilizzare l'endpoint di lettura per le attività di lettura.
Se AutoFailover è abilitato nel cluster, il nodo primario potrebbe cambiare. Pertanto, l'applicazione deve confermare il ruolo del nodo e aggiornare tutti gli endpoint di lettura. In questo modo hai la garanzia che non verrà causato un carico eccessivo sull'endpoint primario. Se AutoFailover disabilitato, il ruolo del nodo non cambia. Tuttavia, il tempo di inattività nelle operazioni gestite o non gestite è maggiore rispetto ai cluster abilitati. AutoFailover
Evita di indirizzare le richieste di lettura a un singolo nodo di replica di lettura perché la sua indisponibilità potrebbe causare un'interruzione della lettura. Esegui il fallback alla lettura del nodo primario oppure assicurati di disporre di almeno due repliche di lettura per evitare interruzioni di lettura durante la manutenzione.
# Strategie di caching per Memcached
Nel seguente argomento, puoi trovare le strategie per popolare e gestire la cache Memcached.
L'implementazione di strategie per il popolamento e la gestione della cache dipende dal tipo di dati che desideri memorizzare e dai modelli di accesso a tali dati. Ad esempio, probabilmente non utilizzerai la stessa strategia per la classifica dei 10 migliori punteggi di gioco in un sito di gaming, o per le notizie più interessanti. Nella parte restante di questa sezione, discuteremo delle strategie più comuni di gestione della cache, dei loro vantaggi e svantaggi.
**Topics**
+ [Repliche di lettura](#Strategies.ReadReplicas)
+ [Caricamento lento](#Strategies.LazyLoading)
+ [Write-Through](#Strategies.WriteThrough)
+ [Aggiunta di TTL](#Strategies.WithTTL)
+ [Argomenti correlati](#Strategies.SeeAlso)
## Repliche di lettura
Spesso è possibile migliorare in modo significativo le prestazioni delle cache ElastiCache serverless creando repliche e leggendo da esse anziché dal nodo di cache principale. Per ulteriori informazioni, consulta [Procedure consigliate per l'utilizzo delle repliche di lettura](ReadReplicas.md).
## Caricamento lento
Come dice lo stesso nome, il *caricamento lento* è una strategia di caching che consente di caricare i dati nella cache solo quando necessario. Funziona come descritto di seguito.
Amazon ElastiCache è un archivio chiave-valore in memoria che si trova tra l'applicazione e l'archivio dati (database) a cui accede. Ogni volta che l'applicazione richiede dati, invia innanzitutto la richiesta alla cache. ElastiCache Se i dati sono presenti nella cache e sono correnti, ElastiCache restituisce tali dati all'applicazione. Se i dati non sono presenti nella cache o sono scaduti, l'applicazione richiede i dati al Data Store. L'archivio dati restituisce quindi i dati all'applicazione. Successivamente, l'applicazione scrive i dati ricevuti dall'archivio nella cache. In questo modo, può essere recuperato più rapidamente la prossima volta che viene richiesto.
Un’*occorrenza della cache* si verifica quando i dati sono presenti nella cache e non sono scaduti:
1. L'applicazione richiede i dati alla cache.
1. La cache restituisce i dati all'applicazione.
Una *mancato riscontro nella cache* si verifica quando i dati non sono presenti nella cache o sono scaduti:
1. L'applicazione richiede i dati alla cache.
1. La cache non dispone dei dati richiesti e restituisce un `null`.
1. L'applicazione richiede e riceve i dati dal database.
1. L'applicazione aggiorna la cache con i nuovi dati.
### Vantaggi e svantaggi del caricamento lento
I vantaggi del caricamento lento sono i seguenti:
+ Solo i dati richiesti vengono memorizzati nella cache.
Poiché la maggior parte dei dati non viene mai richiesta, il caricamento lento evita di riempire la cache con i dati non richiesti.
+ Gli errori dei nodi non sono fatali per l'applicazione.
Se un nodo restituisce un errore e viene sostituito da un nuovo nodo vuoto, l'applicazione continua a funzionare, nonostante l'aumento della latenza. Quando le richieste vengono effettuate al nuovo nodo, ogni mancato riscontro nella cache comporta una query del database. Allo stesso tempo, la copia dei dati viene aggiunta alla cache in modo che le richieste successive vengano richiamate dalla cache.
Gli svantaggi del caricamento pigro sono i seguenti:
+ Comporta una penalità per mancato riscontro nella cache. Ogni mancato riscontro nella cache comporta tre passaggi:
1. Richiesta iniziale dei dati dalla cache
1. Query del database per i database
1. Scrittura dei dati sulla cache
Questi mancati riscontri possono causare un notevole ritardo dei dati destinati all'applicazione.
+ Dati obsoleti.
Se i dati vengono scritti nella cache solo quando si verifica un mancato riscontro nella cache, i dati nella cache diventano obsoleti. Questo risultato si verifica perché non sono stati aggiornati alla cache quando i dati vengono modificati nel database. Per risolvere questo problema, è possibile utilizzare il [Write-Through](#Strategies.WriteThrough) e strategie [Aggiunta di TTL](#Strategies.WithTTL).
### Esempio di pseudocodice di caricamento pigro
Il codice seguente è un esempio di pseudo codice della logica di caricamento lento.
```
// *****************************************
// 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
```
Per questo esempio, il codice dell'applicazione che ottiene i dati è il seguente.
```
customer_record = get_customer(12345)
```
## Write-Through
La strategia di scrittura contemporanea aggiunge i dati o li aggiorna nella cache ogni qualvolta i dati vengano scritti sul database.
### Vantaggi e svantaggi della scrittura contemporanea
I vantaggi di write-through sono i seguenti:
+ I dati nella cache non sono mai obsoleti.
Poiché i dati nella cache vengono aggiornati ogni volta che vengono scritti sul database, i dati nella cache sono sempre correnti.
+ Penalità di scrittura e penalità di lettura.
Ogni scrittura comporta due passaggi:
1. Una scrittura sulla cache
1. Una scrittura sul database
Che aggiunge latenza al processo. Detto questo, gli utenti finali sono generalmente più tolleranti della latenza durante l'aggiornamento o il richiamo dei dati. Esiste la convinzione che gli aggiornamenti comportino maggior lavoro e richiedano pertanto tempi lunghi.
Gli svantaggi di write-through sono i seguenti:
+ Dati mancanti.
Se si esegue un giro verso l'alto di un nuovo nodo, dovuto a un errore del nodo o a un dimensionamento orizzontale, i dati mancanti sono stati visualizzati. Questi dati continuano a mancare fino a quando non vengono aggiunti o aggiornati nel database. È possibile ridurre al minimo questo implementando [caricamento lento](#Strategies.LazyLoading)con write-through.
+ Abbandono della cache.
La maggior parte dei dati non viene mai letta, il che è uno spreco di risorse. Da [aggiunta di un valore durata (TTL)](#Strategies.WithTTL), è possibile ridurre gli sprechi di spazio.
### Esempio di pseudocodice write-through
Il codice seguente è un esempio di pseudo codice della logica di wright-through.
```
// *****************************************
// 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
```
Per questo esempio, il codice dell'applicazione che ottiene i dati è il seguente.
```
save_customer(12345,{"address":"123 Main"})
```
## Aggiunta di TTL
Il caricamento lento accetta i dati obsoleti, ma non restituisce errori con i nodi vuoti. La scrittura contemporanea garantisce dati sempre aggiornati ma può restituire un errore con i nodi vuoti e può popolare la cache con dati superflui. Aggiungendo un valore durata (TTL) a ogni scrittura, puoi avere i vantaggi di ogni strategia. Allo stesso tempo, puoi in gran parte evitare di ingombrare la cache con dati extra.
*Time to live (TTL)* è un valore intero che specifica il numero di secondi che mancano alla scadenza della chiave. Valkey o Redis OSS possono specificare secondi o millisecondi per questo valore. Memcached specifica questo valore in secondi. Quando un'applicazione tenta di leggere una chiave scaduta, viene trattata come se la chiave non fosse mai stata trovata. Il database viene interrogato per la chiave e la cache viene aggiornata. Questo approccio non garantisce che un valore non sia obsoleto. Tuttavia, impedisce ai dati di diventare troppo obsoleti e richiede che i valori nella cache vengano occasionalmente aggiornati dal database.
[Per ulteriori informazioni, vedete i comandi [Valkey e Redis](https://valkey.io/commands) OSS o i comandi Memcached. `set`](https://www.tutorialspoint.com/memcached/memcached_set_data.htm)
### Esempi di pseudocodice TTL
Il codice seguente è un esempio di pseudo codice della logica di write-through con 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
```
Il codice seguente è un esempio di pseudo codice della logica di caricamento lento con 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
```
Per questo esempio, il codice dell'applicazione che ottiene i dati è il seguente.
```
save_customer(12345,{"address":"123 Main"})
```
```
customer_record = get_customer(12345)
```
## Argomenti correlati
+ [Datastore in memoria](elasticache-use-cases.md#elasticache-use-cases-data-store)
+ [Scelta di un motore e di una versione](SelectEngine.md)
+ [Ridimensionamento ElastiCache](Scaling.md)
# Gestione del cluster basato su nodi in ElastiCache
ElastiCache offre due opzioni di implementazione, cache serverless e cluster basati su nodi. Ognuno ha le proprie capacità e requisiti.
Questa sezione contiene argomenti per aiutarti a gestire i cluster basati su nodi.
**Nota**
Questi argomenti non si applicano a Serverless. ElastiCache
**Topics**
+ [Auto Scaling dei cluster Valkey e Redis OSS](AutoScaling.md)
+ [Modifica della modalità cluster](modify-cluster-mode.md)
+ [Replica tra AWS regioni utilizzando datastore globali](Redis-Global-Datastore.md)
+ [Alta disponibilità utilizzando gruppi di replica](Replication.md)
+ [Gestione della manutenzione dei ElastiCache cluster](maintenance-window.md)
+ [Configurazione dei parametri del motore utilizzando gruppi di ElastiCache parametri](ParameterGroups.md)
# Auto Scaling dei cluster Valkey e Redis OSS
## Prerequisiti
ElastiCache L'Auto Scaling è limitato a quanto segue:
+ Cluster Valkey o Redis OSS (modalità cluster abilitata) che eseguono Valkey 7.2 e versioni successive o Redis OSS 6.0 in poi
+ Cluster di data tiering (modalità cluster abilitata) che eseguono Valkey 7.2 e versioni successive o Redis OSS 7.0.7 in poi
+ Dimensioni XLarge delle istanze: grandi, 2 XLarge
+ Famiglie di tipi di istanza: R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn
+ L'Auto Scaling in non ElastiCache è supportato per i cluster in esecuzione in datastore globali, Outposts o Local Zones.
## Gestione automatica della capacità con ElastiCache Auto Scaling con Valkey o Redis OSS
ElastiCache la scalabilità automatica con Valkey o Redis OSS è la capacità di aumentare o diminuire automaticamente gli shard o le repliche desiderati nel servizio. ElastiCache ElastiCache sfrutta il servizio Application Auto Scaling per fornire questa funzionalità. Per ulteriori informazioni, consulta [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). Per utilizzare il ridimensionamento automatico, è necessario definire e applicare una politica di ridimensionamento che utilizza CloudWatch metriche e valori target assegnati dall'utente. ElastiCache la scalabilità automatica utilizza la policy per aumentare o diminuire il numero di istanze in risposta ai carichi di lavoro effettivi.
È possibile utilizzare il Console di gestione AWS per applicare una politica di scalabilità basata su una metrica predefinita. Un `predefined metric` viene definito in un'enumerazione in modo che tu possa specificarlo per nome nel codice o utilizzarlo nella Console di gestione AWS. I parametri personalizzati non possono essere selezionati tramite Console di gestione AWS. In alternativa, puoi utilizzare l'API Application Auto Scaling AWS CLI o l'API Application Auto Scaling per applicare una politica di scalabilità basata su una metrica predefinita o personalizzata.
ElastiCache per Valkey e Redis OSS supporta la scalabilità per le seguenti dimensioni:
+ **Partizioni** : Aggiungi/rimuovi automaticamente frammenti nel cluster in modo simile al risharding online manuale. In questo caso, il ridimensionamento ElastiCache automatico attiva la scalabilità per tuo conto.
+ Repliche: **replica** automaticamente in modo uniforme su tutti add/remove replicas in the cluster similar to manual Increase/Decrease replica operations. ElastiCache auto scaling for Valkey and Redis OSS adds/removes gli shard del cluster.
ElastiCache per Valkey e Redis OSS supporta i seguenti tipi di policy di scalabilità automatica:
+ [Policy di dimensionamento con monitoraggio degli obiettivi](AutoScaling-Scaling-Policies-Target.md)— Aumenta o diminuisci il numero di operazioni shards/replicas eseguite dal servizio in base a un valore target per una metrica specifica. Questa operazione può essere paragonata al modo in cui il termostato regola la temperatura di una casa. Tu selezioni la temperatura, il termostato si occupa del resto.
+ [Scalabilità pianificata per la tua applicazione.](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) — ElastiCache per Valkey e Redis OSS, la scalabilità automatica può aumentare o diminuire il numero di operazioni eseguite shards/replicas dal servizio in base alla data e all'ora.
![\[Immagine di ridimensionamento automatico ElastiCache per Valkey e Redis OSS\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/Auto-scaling.png)
I seguenti passaggi riassumono il processo di scalabilità automatica ElastiCache per Valkey e Redis OSS come mostrato nel diagramma precedente:
1. È possibile creare una policy di scalabilità ElastiCache automatica per il gruppo di replica.
1. ElastiCache il ridimensionamento automatico crea un paio di CloudWatch allarmi per tuo conto. Ogni coppia rappresenta i tuoi limiti superiore e inferiore per i parametri. Questi CloudWatch allarmi vengono attivati quando l'utilizzo effettivo del cluster si discosta dall'utilizzo previsto per un periodo di tempo prolungato. Puoi ora visualizzare gli allarm nella console .
1. Se il valore della metrica configurata supera l'utilizzo previsto (o scende al di sotto dell'obiettivo) per un periodo di tempo specifico, CloudWatch attiva un allarme che richiama l'auto scaling per valutare la politica di scalabilità.
1. ElastiCache auto scaling invia una richiesta di modifica per regolare la capacità del cluster.
1. ElastiCache elabora la richiesta di modifica, aumentando (o diminuendo) dinamicamente la Shards/Replicas capacità del cluster in modo che si avvicini all'utilizzo previsto.
Per capire come funziona ElastiCache Auto Scaling, supponiamo di avere un cluster denominato. `UsersCluster` Monitorando le CloudWatch metriche per`UsersCluster`, si determina il numero massimo di shard richiesti dal cluster quando il traffico è al suo picco e il numero minimo di shard quando il traffico è nel punto più basso. Decidi anche un valore di destinazione per l'utilizzo della CPU per il cluster. `UsersCluster` ElastiCache auto scaling utilizza il suo algoritmo di tracciamento del target per garantire che gli shard di `UsersCluster` forniti vengano regolati secondo necessità in modo che l'utilizzo rimanga pari o vicino al valore target.
**Nota**
La scalabilità potrebbe richiedere molto tempo e richiederà risorse di cluster aggiuntive per il ribilanciamento degli shard. ElastiCache Auto Scaling modifica le impostazioni delle risorse solo quando il carico di lavoro effettivo rimane elevato (o depresso) per un periodo prolungato di diversi minuti. L'algoritmo di tracciamento del target con scalabilità automatica cerca di mantenere l'utilizzo del target pari o vicino al valore prescelto a lungo termine.
# Policy di Auto Scaling
Una policy di dimensionamento dispone dei seguenti componenti:
+ Una metrica di destinazione: la CloudWatch metrica utilizzata da Valkey e Redis OSS Auto Scaling per determinare quando e quanto scalare. ElastiCache
+ Capacità minima e massima: il numero minimo e massimo di shard o repliche da utilizzare per il dimensionamento.
**Importante**
Durante la creazione della politica di Auto Scaling, se la capacità corrente è superiore alla capacità massima configurata, eseguiamo lo ScaleIn durante la creazione della politica. MaxCapacity Allo stesso modo, se la capacità attuale è inferiore alla capacità minima configurata, scaleOut viene impostato su. MinCapacity
+ Un tempo di raffreddamento: la quantità di tempo, in secondi, dopo il completamento di un'attività per ridurre orizzontalmente o aumentare orizzontalmente prima che un'altra attività per aumentare orizzontalmente si possa avviare.
+ Un ruolo collegato al servizio: un ruolo di AWS Identity and Access Management (IAM) collegato a un servizio specifico. AWS Un ruolo collegato al servizio include tutte le autorizzazioni richieste dal servizio per chiamare altri AWS servizi per tuo conto. ElastiCache Auto Scaling genera automaticamente questo ruolo per te. `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG`
+ Attiva o disabilita le attività di riduzione orizzontale: capacità di abilitare o disabilitare le attività di riduzione orizzontale per una policy.
**Topics**
+ [Parametro di destinazione per Auto Scaling](#AutoScaling-TargetMetric)
+ [Capacità minima e massima](#AutoScaling-MinMax)
+ [Periodo di raffreddamento](#AutoScaling-Cooldown)
+ [Abilitazione o disabilitazione delle attività di riduzione](#AutoScaling-enable-disable-scale-in)
## Parametro di destinazione per Auto Scaling
In questo tipo di politica, una metrica predefinita o personalizzata e un valore target per la metrica vengono specificati in una configurazione della politica di scalabilità di tracciamento degli obiettivi. ElastiCache per Valkey e Redis OSS Auto Scaling crea e CloudWatch gestisce allarmi che attivano la politica di scalabilità e calcola la regolazione della scalabilità in base alla metrica e al valore target. La politica di scalabilità aggiunge o rimuove shards/replicas se necessario per mantenere la metrica pari o vicina al valore target specificato. Oltre a mantenere il parametro vicino al valore di destinazione, una policy di dimensionamento con monitoraggio degli obiettivi si adatta anche alle oscillazioni del parametro dovute a un carico di lavoro mutevole. Tale politica riduce inoltre al minimo le rapide fluttuazioni del numero di elementi disponibili per il cluster. shards/replicas
Ad esempio, prendi una policy di dimensionamento che usa il parametro medio di default `ElastiCachePrimaryEngineCPUUtilization`. Tale policy può mantenere l'utilizzo della CPU a una percentuale specifica di utilizzo, come il 70 percento, o vicino ad essa.
**Nota**
Per ogni cluster , è possibile creare solo una policy di Auto Scaling per ogni parametro di destinazione.
## Capacità minima e massima
**Shard**
È possibile specificare il numero massimo di shard a cui è possibile scalare ElastiCache per la scalabilità automatica di Valkey e Redis OSS. Questo valore deve essere uguale o inferiore a 250 con un minimo di 1. È inoltre possibile specificare il numero minimo di shard da gestire mediante la scalabilità automatica. Questo valore deve essere almeno 1 e o uguale o minore del valore specificato per il numero massimo di 250 shard.
**Repliche**
È possibile specificare il numero massimo di repliche da ElastiCache gestire per la scalabilità automatica di Valkey e Redis OSS. Questo valore deve essere maggiore o uguale a 5. È inoltre possibile specificare il numero minimo di repliche da gestire mediante la scalabilità automatica. Questo valore deve essere almeno 1 e o uguale o inferiore del valore 5 specificato per il numero massimo repliche.
Per determinare il numero minimo e massimo di shards/replicas cui hai bisogno per il traffico tipico, verifica la configurazione Auto Scaling con la velocità di traffico prevista per il tuo modello.
**Nota**
ElastiCache le politiche di scalabilità automatica aumentano la capacità del cluster fino a raggiungere la dimensione massima definita o fino all'applicazione dei limiti di servizio. Per richiedere un aumento dei limiti, consulta [AWS Limiti del servizio](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e seleziona il tipo di limite **Nodi per cluster per tipo di istanza**.
**Importante**
Ridurre orizzontalmente in assenza di traffico Se il traffico di una variante diventa zero, ElastiCache viene ridimensionato automaticamente fino al numero minimo di istanze specificato.
## Periodo di raffreddamento
È possibile sintonizzare i tempi di risposta di una policy di dimensionamento con monitoraggio degli obiettivi aggiungendo dei tempi di raffreddamento che influiscano sul dimensionamento del cluster. Un periodo di attesa blocca le richieste di riduzione o aumento ulteriori finché il periodo non scade. Ciò rallenta le eliminazioni dei shards/replicas cluster ElastiCache for Valkey e Redis OSS per le richieste di scalabilità in entrata e la creazione di richieste di scalabilità orizzontale. shards/replicas Puoi specificare i seguenti periodi di attesa:
+ Un'attività scalabile riduce il numero di persone presenti nel cluster. shards/replicas Un periodo di attesa di riduzione specifica la quantità di tempo che deve passare, in secondi, tra il completamento di un'attività di riduzione e l'inizio di un'altra attività di questo tipo.
+ Un'attività con scalabilità orizzontale aumenta il numero di membri del shards/replicas cluster. Un periodo di attesa di aumento specifica la quantità di tempo che deve passare, in secondi, tra il completamento di un'attività di aumento e l'inizio di un'altra attività di questo tipo.
Quando un periodo di raffreddamento di riduzione orizzontale o di aumento orizzontale non viene specificato, il valore di default per ogni aumento orizzontale è pari a 600 secondi e 900 per ogni riduzione orizzontale.
## Abilitazione o disabilitazione delle attività di riduzione
Puoi abilitare o disabilitare le attività di riduzione per una policy. L'abilitazione delle attività di scalabilità consente l'eliminazione della politica di scalabilità. 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
**Nota**
Le attività di scalabilità orizzontale sono sempre abilitate in modo che la politica di scalabilità possa creare ElastiCache frammenti o repliche in base alle esigenze.
## Autorizzazioni IAM richieste per l'Auto Scaling
ElastiCache per Valkey e Redis OSS Auto Scaling è reso possibile da una combinazione di ElastiCache CloudWatch, e Application Auto Scaling. APIs I cluster vengono creati e aggiornati con ElastiCache, gli allarmi vengono creati e le politiche di scalabilità vengono create con CloudWatch Application Auto Scaling. Oltre alle autorizzazioni IAM standard per la creazione e l'aggiornamento dei cluster, l'utente IAM che accede alle impostazioni di ElastiCache Auto Scaling deve disporre delle autorizzazioni appropriate per i servizi che supportano la scalabilità dinamica. In questa policy più recente abbiamo aggiunto il supporto per il ridimensionamento verticale di Memcached, con l'azione. `elasticache:ModifyCacheCluster` Gli utenti IAM devono disporre dell'autorizzazione per utilizzare le operazioni nella seguente policy di esempio:
------
#### [ 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"
}
]
}
```
------
## Ruolo collegato al servizio
Il servizio di scalabilità automatica ElastiCache per Valkey e Redis OSS richiede inoltre l'autorizzazione per descrivere i cluster e gli CloudWatch allarmi e le autorizzazioni per modificare la capacità di destinazione per tuo ElastiCache conto. Se abiliti Auto Scaling per il tuo cluster, viene creato un ruolo collegato al servizio denominato. `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG` Questo ruolo collegato al servizio concede l'autorizzazione alla scalabilità ElastiCache automatica per descrivere gli allarmi per le tue politiche, monitorare la capacità attuale del parco veicoli e modificare la capacità del parco veicoli. Il ruolo collegato ai servizi è il ruolo predefinito per la scalabilità ElastiCache automatica. Per ulteriori informazioni, consulta [Ruoli collegati ai servizi ElastiCache per la scalabilità automatica Redis OSS nella Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) User Guide.
## Best practice Auto Scaling
Prima di effettuare la registrazione a Auto Scaling, ti consigliamo di attenerti alle seguenti indicazioni:
1. **Usa una sola metrica di tracciamento**: consente di identificare se il cluster dispone di carichi di lavoro che utilizzano notevoli risorse di CPU o dati e di utilizzare la metrica predefinita corrispondente per definire la policy di dimensionamento.
+ CPU del motore: `ElastiCachePrimaryEngineCPUUtilization` (dimensione partizione) o `ElastiCacheReplicaEngineCPUUtilization` (dimensione replica)
+ Utilizzo del database: `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` questa policy di dimensionamento è ideale con maxmemory-policy impostato su noeviction sul cluster.
Ti consigliamo di evitare più policy per dimensione nel cluster. ElastiCache per Valkey e Redis OSS Auto scaling ridimensionerà la destinazione scalabile se alcune policy di tracciamento delle destinazioni sono pronte per la scalabilità orizzontale, ma la scalerà solo se tutte le politiche di tracciamento della destinazione (con la parte scalabile abilitata) sono pronte per la scalabilità orizzontale. Se più policy impongono alla destinazione scalabile un dimensionamento orizzontale o verticale contemporaneamente, viene dimensionata in base al criterio che fornisce la capacità massima sia per riduzione orizzontale che per il dimensionamento orizzontale.
1. **Metriche personalizzate per il monitoraggio degli obiettivi**: prestare attenzione quando si utilizzano le metriche personalizzati per il monitoraggio degli obiettivi, poiché il dimensionamento automatico è più adatto alla scalabilità orizzontale/ridimensionamento proporzionale alle modifiche delle metriche scelte per la policy. Se tali metriche non cambiano proporzionalmente alle operazioni di dimensionamento utilizzate per la creazione della policy, potrebbero verificarsi operazioni di scalabilità orizzontale o ridimensionamento continue che possono influire sulla disponibilità o sui costi.
Per i cluster dei livelli di dati (tipi di istanza della famiglia r6gd), evita di utilizzare metriche basate sulla memoria per il dimensionamento.
1. **Scalabilità pianificata**: se ritieni che il tuo carico di lavoro sia deterministico (viene raggiunto high/low in un momento specifico), ti consigliamo di utilizzare Scheduled Scaling e configurare la capacità target in base alle necessità. Il monitoraggio dell’obiettivo è ideale per carichi di lavoro non deterministici e per il cluster per un funzionamento con la metrica obiettivo richiesta, con aumento orizzontale quando occorrono più risorse e riduzione orizzontale quando occorrono meno risorse.
1. **Disabilita la scalabilità in entrata**: la scalabilità automatica su Target Tracking è la soluzione ideale per i cluster con carichi di lavoro graduali, poiché le metriche possono innescare oscillazioni consecutive increase/decrease di scale-out/in. spikes/dip Per evitare tali oscillazioni, puoi iniziare con la riduzione orizzontale disabilitata e utilizzarla manualmente in un secondo momento in base alla necessità.
1. **Testa la tua applicazione: ti consigliamo di testare** l'applicazione con i Min/Max carichi di lavoro stimati per determinare il minimo e il massimo shards/replicas assoluti richiesti per il cluster, creando al contempo politiche di scalabilità per evitare problemi di disponibilità. La scalabilità automatica può effettuare l’aumento orizzontale fino alla soglia massima e la riduzione orizzontale fino alla soglia minima configurata per l’obiettivo.
1. **Definizione del valore target**: è possibile analizzare le CloudWatch metriche corrispondenti per l'utilizzo del cluster in un periodo di quattro settimane per determinare la soglia del valore target. Se non sei ancora certo del valore da scegliere, ti consigliamo di iniziare con il valore predefinito minimo supportato della metrica.
1. AutoScaling on Target Tracking è più adatto per i cluster con distribuzione uniforme dei carichi di lavoro tra le dimensioni. shards/replicas Avere una distribuzione non uniforme può portare a:
+ Scalabilità quando non necessaria a causa del carico di lavoro spike/dip su alcuni shard/repliche hot.
+ Non dimensionamento quando richiesto a causa della media complessiva vicina alla destinazione anche se si dispone di partizioni/repliche hot.
**Nota**
Durante la scalabilità orizzontale del cluster, ElastiCache replicherà automaticamente le funzioni caricate in uno dei nodi esistenti (selezionati a caso) sui nuovi nodi. Se il cluster utilizza Valkey o Redis OSS 7.0 o versioni successive e l'applicazione utilizza [Functions, consigliamo di caricare tutte le funzioni](https://valkey.io/topics/functions-intro/) su tutti gli shard prima di eseguire la scalabilità orizzontale, in modo che il cluster non finisca con funzioni diverse su shard diversi.
Dopo la registrazione a, tieni presente quanto segue: AutoScaling
+ Esistono limitazioni sulle configurazioni del dimensionamento automatico supportate, per cui è preferibile non modificare la configurazione di un gruppo di replica registrato per il dimensionamento automatico. Di seguito vengono mostrati gli esempi:
+ Modifica manuale del tipo di istanza in tipi non supportati.
+ Associazione del gruppo di replica a un Global Datastore.
+ Modifica `ReservedMemoryPercent` parametro .
+ increasing/decreasing shards/replicas beyond the Min/MaxCapacità configurata manualmente durante la creazione delle policy.
# Utilizzo di Auto Scaling con i shard
Con s AutoScaling puoi utilizzare le politiche ElastiCache di tracciamento e pianificazione con il tuo motore Valkey o Redis OSS.
Di seguito vengono forniti dettagli sul tracciamento degli obiettivi e sulle politiche pianificate e su come applicarle utilizzando e. Console di gestione AWS AWS CLI APIs
**Topics**
+ [Policy di dimensionamento con monitoraggio degli obiettivi](AutoScaling-Scaling-Policies-Target.md)
+ [Aggiunta di una policy di dimensionamento](AutoScaling-Scaling-Adding-Policy-Shards.md)
+ [Registrare un target scalabile](AutoScaling-Scaling-Registering-Policy-CLI.md)
+ [Definizione di una policy di dimensionamento](AutoScaling-Scaling-Defining-Policy-API.md)
+ [Disabilitazione dell'attività di riduzione orizzontale](AutoScaling-Scaling-Disabling-Scale-in.md)
+ [Applicazione di una policy di dimensionamento](AutoScaling-Scaling-Applying-a-Scaling-Policy.md)
+ [Modifica di una policy di dimensionamento](AutoScaling-Scaling-Editing-a-Scaling-Policy.md)
+ [Eliminazione di una policy di dimensionamento](AutoScaling-Scaling-Deleting-a-Scaling-Policy.md)
+ [Utilizzo CloudFormation per le politiche di Auto Scaling](AutoScaling-with-Cloudformation-Shards.md)
+ [Dimensionamento pianificato](AutoScaling-with-Scheduled-Scaling-Shards.md)
# Policy di dimensionamento con monitoraggio degli obiettivi
Con le politiche di scalabilità del tracciamento degli obiettivi, si seleziona una metrica e si imposta un valore obiettivo. ElastiCache per Valkey e Redis OSS Auto Scaling crea e gestisce gli allarmi che attivano CloudWatch la politica di scalabilità e calcola la regolazione della scalabilità in base alla metrica e al valore target. La policy di dimensionamento aggiunge o rimuove partizioni in base alle necessità, per mantenere il parametro al valore di destinazione specificato o vicino a esso. Oltre a mantenere il parametro vicino al valore di destinazione, una policy di dimensionamento di monitoraggio dei target si adatta anche alle fluttuazioni del parametro dovute a un modello di carico fluttuante e riduce al minimo le fluttuazioni rapide nella capacità del parco istanze.
Ad esempio, si consideri una policy di dimensionamento che utilizza la media predefinita`ElastiCachePrimaryEngineCPUUtilization`Metrica con il valore di destinazione configurato. Tale policy può mantenere l'utilizzo della CPU al valore di destinazione specificato o vicino al valore di destinazione specificato.
## Metriche predefinite
Una metrica predefinita è una struttura che fa riferimento a un nome, una dimensione e una statistica () specifici di una determinata metrica. `average` CloudWatch La policy di dimensionamento automatico definisce le seguenti metriche predefinite per il cluster:
****
| Nome parametro predefinito | CloudWatch Nome parametro | CloudWatch Dimensione metrica | Tipi di istanza non idonei |
| --- | --- | --- | --- |
| ElastiCachePrimaryEngineCPUUtilization | `EngineCPUUtilization` | ReplicationGroupId, Ruolo = primario | Nessuno |
| ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage | `DatabaseCapacityUsageCountedForEvictPercentage` | Metriche del gruppo di replica OSS Valkey o Redis | Nessuno |
| ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage | `DatabaseMemoryUsageCountedForEvictPercentage` | Metriche del gruppo di replica Valkey o Redis OSS | R6gd |
I tipi di istanza dei livelli di dati non possono utilizzare `ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage`, poiché questi tipi di istanza archiviano i dati in memoria e in SSD. Il caso d'uso previsto per le istanze dei livelli di dati è avere il 100% di utilizzo della memoria e riempire l'SSD in base alle esigenze.
## Criteri Auto Scaling per le partizioni
Quando il servizio rileva che la metrica predefinita è uguale o superiore all'impostazione di Target, aumenta automaticamente la capacità degli shard. ElastiCache per Valkey e Redis OSS ridimensiona gli shard del cluster in base a un conteggio pari al più grande tra due numeri: la variazione percentuale rispetto a Target e il 20% degli shard attuali. Per quanto riguarda la scalabilità in entrata, ElastiCache non verrà eseguita automaticamente a meno che il valore della metrica complessivo non sia inferiore al 75 percento del Target definito.
Per un esempio di scala orizzontale, se hai 50 frammenti e
+ se Target viola del 30 percento, si ElastiCache ridimensiona orizzontalmente del 30 percento, il che si traduce in 65 shard per cluster.
+ se Target viene violato del 10%, per impostazione predefinita viene ElastiCache ridimensionato almeno del 20%, il che si traduce in 60 shard per cluster.
Ad esempio, se hai selezionato un valore Target del 60 percento, ElastiCache non verrà eseguito lo scaling automatico finché la metrica non sarà inferiore o uguale al 45 percento (25 percento inferiore al 60 percento del Target).
## Considerazioni su Auto Scaling
Tieni a mente le seguenti considerazioni:
+ Una policy di dimensionamento di monitoraggio obiettivi presuppone che essa debba eseguire un dimensionamento orizzontale quando il parametro specificato supera il valore di destinazione. Non è possibile utilizzare una politica di ridimensionamento del tracciamento degli obiettivi per la scalabilità orizzontale quando la metrica specificata è inferiore al valore target. ElastiCache for Valkey e Redis OSS ridimensiona gli shard con una deviazione minima del 20% rispetto alla destinazione degli shard esistenti nel cluster.
+ Una policy di dimensionamento di monitoraggio obiettivi non esegue il dimensionamento quando il parametro specificato non dispone di dati sufficienti. Non esegue la riduzione orizzontale perché l’insufficienza di dati non viene interpretata come basso utilizzo.
+ Potrebbero esserci delle differenze tra il valore di destinazione e i punti di dati dei parametri reali. Questo perché ElastiCache Auto Scaling agisce sempre in modo conservativo arrotondando verso l'alto o verso il basso quando determina la quantità di capacità da aggiungere o rimuovere. In questo modo si impedisce l'aggiunta di capacità insufficiente o la rimozione di capacità eccessiva.
+ Per garantire la disponibilità delle applicazioni, il servizio aumenta in proporzione al parametro il più veloce possibile, ma si riduce in modo più conservativo.
+ È possibile disporre di più politiche di scalabilità di tracciamento degli obiettivi per un cluster ElastiCache for Valkey e Redis OSS, a condizione che ciascuna di esse utilizzi una metrica diversa. L'intenzione di ElastiCache Auto Scaling è quella di dare sempre la priorità alla disponibilità, quindi il suo comportamento varia a seconda che le policy di tracciamento di destinazione siano pronte per la scalabilità orizzontale o verticale. Il servizio viene aumentato se una qualsiasi delle policy di monitoraggio obiettivi è pronta per l'aumento, ma viene ridotto solo se tutte le policy di monitoraggio obiettivi (con la porzione di riduzione abilitata) sono pronte per la riduzione.
+ Non modificate o eliminate gli CloudWatch allarmi gestiti da ElastiCache Auto Scaling per una politica di scalabilità di tracciamento degli obiettivi. ElastiCache Auto Scaling elimina automaticamente gli allarmi quando si elimina la politica di ridimensionamento.
+ ElastiCache L'Auto Scaling non impedisce di modificare manualmente gli shard del cluster. Queste regolazioni manuali non influiscono sugli CloudWatch allarmi esistenti associati alla politica di scalabilità, ma possono influire sulle metriche che potrebbero attivare questi allarmi. CloudWatch
+ Questi CloudWatch allarmi gestiti da Auto Scaling sono definiti sulla base della metrica AVG su tutti gli shard del cluster. Quindi, avere frammenti caldi può comportare uno scenario di:
+ ridimensionamento quando non necessario a causa del caricamento su alcuni shard caldi che attiva un allarme CloudWatch
+ non dimensionare quando richiesto a causa di AVG aggregato su tutti le partizioni che influiscono sull'allarme non violato.
+ ElastiCache i limiti predefiniti relativi ai nodi per cluster sono ancora validi. Pertanto, quando si opta per il Auto Scaling e se si prevede che i nodi massimi siano superiori al limite di default, è necessario richiedere un aumento del limite a[AWS Restrizioni dei servizi](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)e scegliere il tipo di limite**Nodi per cluster per tipo di istanza**.
+ Assicurati di avere abbastanza ENIs (interfacce di rete elastiche) disponibili nel tuo VPC, necessarie durante la scalabilità orizzontale. Per ulteriori informazioni, consulta [Interfacce di rete elastiche](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html).
+ Se la capacità disponibile non è sufficiente EC2, ElastiCache Auto Scaling non scalerà e verrà ritardato fino a quando la capacità non sarà disponibile.
+ ElastiCache per Redis OSS Auto Scaling durante lo scale-in non rimuoverà gli shard con slot con una dimensione dell'elemento superiore a 256 MB dopo la serializzazione.
+ Durante la scale-in non rimuoverà i frammenti se la memoria disponibile è insufficiente nella configurazione di partizioni risultante.
# Aggiunta di una policy di dimensionamento
È possibile aggiungere una politica di scalabilità utilizzando. Console di gestione AWS
**Per aggiungere una policy di Auto Scaling a un cluster ElastiCache for Valkey e Redis OSS**
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli **Valkey** o **Redis** OSS.
1. Scegli il cluster a cui aggiungere una policy (seleziona il nome del cluster e non il pulsante a sinistra del cluster).
1. Seleziona la scheda **Policy di Auto Scaling**.
1. Scegli **add dynamic scaling** (Aggiungi dimensionamento automatico).
1. In **Nome policy**, immetti un nome per la policy.
1. Per **Dimensione scalabile** scegli **partizioni**.
1. Per il parametro di destinazione, scegli uno dei seguenti modi:
+ **Utilizzo primario della CPU** per creare una policy basata sull'utilizzo medio della CPU.
+ **Memoria** per creare una policy basata sulla memoria media del database.
+ **Capacità** per creare una policy basata sull'utilizzo della capacità database media. La metrica Capacità include l'utilizzo della memoria e di SSD per le istanze dei livelli di dati e l'utilizzo della memoria per tutti gli altri tipi di istanza.
1. Per il valore target, scegli un valore maggiore o uguale a 35 e inferiore o uguale a 70. La scalabilità automatica manterrà questo valore per la metrica target selezionata tra i tuoi shard: ElastiCache
+ **Utilizzo della CPU primaria**: mantiene il valore target per la metrica `EngineCPUUtilization` sui nodi primari.
+ **Memoria**: mantiene il valore target per la metrica `DatabaseMemoryUsageCountedForEvictPercentage`
+ **Capacità** mantiene il valore target per la metrica `DatabaseCapacityUsageCountedForEvictPercentage`,
Le partizioni del cluster vengono aggiunte o rimosse per tenere il parametro vicino al valore specificato.
1. (Facoltativo) I periodi di attesa di riduzione o aumento non sono supportati dalla console. Utilizzate il AWS CLI per modificare i valori di cooldown.
1. Per **Capacità minima**, digita il numero minimo di shard che la policy ElastiCache Auto Scaling deve mantenere.
1. Per **Capacità massima**, digitare il numero massimo di shard che la policy ElastiCache Auto Scaling deve mantenere. Questo valore deve essere maggiore o uguale a 250.
1. Scegli **Create** (Crea).
# Registrare un target scalabile
Prima di poter utilizzare Auto Scaling con un cluster ElastiCache for Valkey e Redis OSS, è necessario registrare il cluster con auto scaling. ElastiCache Lo fai per definire la dimensione di scalabilità e i limiti da applicare a quel cluster. ElastiCache la scalabilità automatica ridimensiona dinamicamente il cluster lungo la dimensione `elasticache:replication-group:NodeGroups` scalabile, che rappresenta il numero di shard del cluster.
**Usando il AWS CLI**
Per registrare il tuo cluster ElastiCache for Valkey e Redis OSS, usa il [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)comando con i seguenti parametri:
+ `--service-namespace` – Imposta questo valore su `elasticache`
+ `--resource-id`— L'identificatore di risorsa per il cluster. Per questo parametro, il tipo di risorsa è `ReplicationGroup` e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ `--scalable-dimension`: imposta questo valore su `elasticache:replication-group:NodeGroups`.
+ `--max-capacity `— Il numero massimo di shard da gestire mediante la scalabilità ElastiCache automatica. Per informazioni sulla relazione tra `--min-capacity`, `--max-capacity` e il numero di partizioni nel cluster, consulta [Capacità minima e massima](AutoScaling-Policies.md#AutoScaling-MinMax).
+ `--min-capacity `— Il numero minimo di shard da gestire tramite ElastiCache auto scaling. Per informazioni sulla relazione tra `--min-capacity`, `--max-capacity` e il numero di partizioni nel cluster, consulta [Capacità minima e massima](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Nell'esempio seguente, si registra un ElastiCache cluster denominato. `myscalablecluster` La registrazione indica che il cluster deve essere dimensionato dinamicamente per avere da uno a dieci partizioni .
Per Linux, macOS o 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 \
```
Per 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 ^
```
**Utilizzo dell'API**
Per registrare il ElastiCache cluster, utilizzate il [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)comando con i seguenti parametri:
+ ServiceNamespace — Imposta questo valore su elasticache.
+ resourceID: l'identificatore della risorsa per il cluster. ElastiCache Per questo parametro, il tipo di risorsa è ReplicationGroup e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ ScalableDimension — Imposta questo valore su. `elasticache:replication-group:NodeGroups`
+ MinCapacity — Il numero minimo di shard da gestire tramite ElastiCache auto scaling. Per informazioni sulla relazione tra —capacità-min, —capacità-max il numero di repliche nel cluster, consulta.[Capacità minima e massima](AutoScaling-Policies.md#AutoScaling-MinMax).
+ MaxCapacity — Il numero massimo di shard da gestire mediante la scalabilità ElastiCache automatica. Per informazioni sulla relazione tra —capacità-min, —capacità-max il numero di repliche nel cluster, consulta.[Capacità minima e massima](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Nell'esempio seguente, si registra un ElastiCache cluster denominato `myscalablecluster` con l'API Application Auto Scaling. Questa registrazione indica che il cluster database deve essere dimensionato dinamicamente per avere da uno a 5 repliche .
```
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
}
```
# Definizione di una policy di dimensionamento
Una configurazione della policy di dimensionamento di monitoraggio degli obiettivi è rappresentata da un blocco JSON in cui sono definiti i valori dei parametri e della destinazione. Puoi salvare una configurazione della policy di dimensionamento come un blocco JSON in un file di testo. Si utilizza quel file di testo quando si richiama l'API AWS CLI Application Auto Scaling. Per ulteriori informazioni sulla sintassi della configurazione della policy, consulta [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in Application Auto Scaling API Reference.
Le seguenti opzioni sono disponibili per definire una configurazione di una policy di dimensionamento con monitoraggio degli obiettivi.
**Topics**
+ [Utilizzo di un parametro di default](#AutoScaling-Scaling-Predefined-Metric)
+ [Utilizzo di un parametro personalizzato](#AutoScaling-Scaling-Custom-Metric)
+ [Utilizzo di periodi di attesa](#AutoScaling-Scaling-Cooldown-periods)
## Utilizzo di un parametro di default
Utilizzando metriche predefinite, puoi definire rapidamente una politica di scalabilità del tracciamento del target per un cluster ElastiCache for Valkey e Redis OSS che funziona con il tracciamento del target in Auto Scaling. ElastiCache
Attualmente, ElastiCache supporta le seguenti metriche predefinite in Auto NodeGroup Scaling:
+ **ElastiCachePrimaryEngineCPUUtilization**— Il valore medio della `EngineCPUUtilization` metrica in tutti i nodi primari del CloudWatch cluster.
+ **ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage**— Il valore medio della `DatabaseMemoryUsageCountedForEvictPercentage` metrica in CloudWatch tutti i nodi primari del cluster.
+ **ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage**— Il valore medio della `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` metrica in CloudWatch tutti i nodi primari del cluster.
Per ulteriori informazioni sulle metriche `EngineCPUUtilization`, `DatabaseMemoryUsageCountedForEvictPercentage` e `DatabaseCapacityUsageCountedForEvictPercentage`, consultare [Monitoraggio dell'utilizzo con CloudWatch Metrics](CacheMetrics.md). Per utilizzare un parametro di default nella policy di dimensionamento, crea una configurazione di monitoraggio degli obiettivi per la policy di dimensionamento. La configurazione deve includere un `PredefinedMetricSpecification` per il parametro di default e un TargetValue per il valore di destinazione del parametro.
**Example**
L'esempio seguente descrive una tipica configurazione delle policy per il ridimensionamento del target-tracking per un cluster ElastiCache for Valkey e Redis OSS. In questa configurazione, la metrica `ElastiCachePrimaryEngineCPUUtilization` predefinita viene utilizzata per regolare il cluster in base a un utilizzo medio della CPU del 40% su tutti i nodi primari del cluster.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
```
## Utilizzo di un parametro personalizzato
Utilizzando dei parametri personalizzati, è possibile definire una policy di dimensionamento di monitoraggio degli obiettivi che soddisfi i requisiti personalizzati. È possibile definire un parametro personalizzato in base a qualsiasi parametro ElastiCache che si modifichi in proporzione al dimensionamento. Non tutte le ElastiCache metriche funzionano per il tracciamento degli obiettivi. Il parametro deve essere un parametro di utilizzo valido e deve descrivere quanto è impegnata un'istanza. Il valore del parametro deve aumentare o diminuire in proporzione al numero di partizioni nel cluster. Questo aumento o riduzione proporzionale è necessario per utilizzare i dati del parametro per aumentare orizzontalmente in modo proporzionale il numero di repliche .
**Example**
Il seguente esempio descrive una configurazione di monitoraggio degli obiettivi per una policy di dimensionamento. In questa configurazione, una metrica personalizzata regola un ElastiCache cluster Redis OSS in base a un utilizzo medio della CPU del 50% su tutti gli shard di un cluster denominato. `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"
}
}
```
## Utilizzo di periodi di attesa
È possibile specificare un valore, in secondi, per `ScaleOutCooldown` per aggiungere un periodo di attesa per il dimensionamento orizzontale del cluster. Allo stesso modo, è possibile aggiungere un valore, in secondi, per `ScaleInCooldown` per aggiungere un periodo di attesa per la riduzione del cluster. Per ulteriori informazioni, consulta [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)l'Application Auto Scaling API Reference.
Il seguente esempio descrive una configurazione di monitoraggio degli obiettivi per una policy di dimensionamento. In questa configurazione, la metrica `ElastiCachePrimaryEngineCPUUtilization` predefinita viene utilizzata ElastiCache per regolare un cluster Redis OSS in base a un utilizzo medio della CPU del 40% su tutti i nodi primari di quel cluster. La configurazione fornisce un tempo di raffreddamento di riduzione orizzontale di 10 minuti e un tempo di raffreddamento di aumento di 5 minuti.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
# Disabilitazione dell'attività di riduzione orizzontale
È possibile impedire la scalabilità della configurazione della policy di scalabilità target-tracking nel cluster disabilitando l'attività di scalabilità in ingresso. La disabilitazione delle attività di riduzione orizzontale impedisce alla policy di dimensionamento di eliminare le partizioni, consentendo tuttavia alla policy di dimensionamento di crearle in base alle esigenze.
È possibile specificare un valore booleano per `DisableScaleIn` per abilitare o disabilitare l'attività di riduzione orizzontale per il cluster. Per ulteriori informazioni, consulta [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html)l'Application Auto Scaling API Reference.
Il seguente esempio descrive una configurazione di monitoraggio degli obiettivi per una policy di dimensionamento. In questa configurazione, la metrica `ElastiCachePrimaryEngineCPUUtilization` predefinita regola un cluster ElastiCache per Valkey e Redis OSS in base a un utilizzo medio della CPU del 40% su tutti i nodi primari di quel cluster. La configurazione disabilita l'attività di riduzione per la policy di dimensionamento.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
# Applicazione di una policy di dimensionamento
Dopo aver registrato il cluster con la scalabilità automatica ElastiCache di Valkey e Redis OSS e aver definito una politica di scalabilità, applichi la politica di scalabilità al cluster registrato. Per applicare una policy di scalabilità a un cluster ElastiCache for Redis OSS, puoi utilizzare AWS CLI o l'API Application Auto Scaling.
## Applicazione di una politica di scalabilità utilizzando AWS CLI
Per applicare una politica di scalabilità al cluster ElastiCache for Valkey e Redis OSS, utilizza il [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)comando con i seguenti parametri:
+ **—policy-name**– Il nome della policy di dimensionamento.
+ **—policy-type**— Impostare questo valore su`TargetTrackingScaling`.
+ **--resource-id — L'identificatore della risorsa**. Per questo parametro, il tipo di risorsa è `ReplicationGroup` e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ **—service-namespace**— Impostare questo valore su`elasticache`.
+ **—scalable-dimension**— Impostare questo valore su`elasticache:replication-group:NodeGroups`.
+ **-- target-tracking-scaling-policy -configuration — La configurazione** della policy di scalabilità target-tracking da utilizzare per il cluster.
Nell'esempio seguente, si applica una politica di scalabilità di tracciamento della destinazione denominata `myscalablepolicy` a un cluster ElastiCache for Valkey e Redis OSS denominato auto scaling. `myscalablecluster` ElastiCache Per fare ciò, usa la configurazione della policy salvata in un file denominato `config.json`.
Per Linux, macOS o 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
```
Per 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
```
## Applicazione di una policy di dimensionamento con l'API
Per applicare una politica di scalabilità al cluster ElastiCache for Valkey e Redis OSS, utilizza il [PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) AWS CLI comando con i seguenti parametri:
+ **—policy-name**– Il nome della policy di dimensionamento.
+ **--resource-id — L'identificatore della risorsa**. Per questo parametro, il tipo di risorsa è `ReplicationGroup` e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ **—service-namespace**— Impostare questo valore su`elasticache`.
+ **—scalable-dimension**— Impostare questo valore su`elasticache:replication-group:NodeGroups`.
+ **-- target-tracking-scaling-policy -configuration — La configurazione** della policy di scalabilità target-tracking da utilizzare per il cluster.
Nell'esempio seguente, si applica una politica di scalabilità di tracciamento della destinazione denominata `myscalablepolicy` a un ElastiCache cluster denominato `myscalablecluster` auto ElastiCache scaling. Si utilizza una policy di configurazione in base al parametro di default `ElastiCachePrimaryEngineCPUUtilization`.
```
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"
}
}
}
```
# Modifica di una policy di dimensionamento
È possibile modificare una politica di scalabilità utilizzando Console di gestione AWS l'API AWS CLI Application Auto Scaling.
## Modifica di una politica di scalabilità utilizzando il Console di gestione AWS
**Per modificare una policy di Auto Scaling per un cluster ElastiCache for Valkey e Redis OSS**
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli il motore appropriato.
1. Scegli il cluster a cui aggiungere una policy (seleziona il nome del cluster e non il pulsante a sinistra del cluster).
1. Seleziona la scheda **Policy di Auto Scaling**.
1. In **Policy di dimensionamento** scegli il pulsante a sinistra della policy di Auto Scaling su cui eseguire la modifica, quindi scegli **Modify** (Modifica).
1. Apportare le modifiche necessarie alla policy.
1. Scegli **Modifica**.
## Modifica di una politica di scalabilità utilizzando l'API AWS CLI and
Puoi utilizzare l' AWS CLI API Application Auto Scaling per modificare una policy di scaling nello stesso modo in cui applichi una policy di scaling:
+ Quando si utilizza il AWS CLI, specificare il nome della politica che si desidera modificare nel parametro. `--policy-name` Specifica i nuovi valori per i parametri che desideri modificare.
+ Quando si utilizza l'API Application Auto Scaling, specificare il nome della policy da modificare nel parametro `PolicyName`. Specifica i nuovi valori per i parametri che desideri modificare.
Per ulteriori informazioni, consulta [Applicazione di una policy di dimensionamento](AutoScaling-Scaling-Applying-a-Scaling-Policy.md).
# Eliminazione di una policy di dimensionamento
È possibile eliminare una politica di scalabilità utilizzando Console di gestione AWS l'API AWS CLI Application Auto Scaling.
## Eliminazione di una politica di scalabilità utilizzando il Console di gestione AWS
**Per eliminare una policy di Auto Scaling per un cluster ElastiCache per Redis OSS**
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli **Valkey** o **Redis** OSS.
1. Scegli il cluster a cui aggiungere una policy (seleziona il nome del cluster e non il pulsante a sinistra del cluster).
1. Seleziona la scheda **Policy di Auto Scaling**.
1. Nella sezione **Scaling Policies (Policy di Scaling)**, scegliere la policy di Auto Scaling e successivamente **Delete** (Elimina).
## Eliminazione di una politica di scalabilità utilizzando il AWS CLI
Per eliminare una politica di scalabilità dal cluster ElastiCache for Valkey e Redis OSS, utilizza il [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI comando con i seguenti parametri:
+ **—policy-name**– Il nome della policy di dimensionamento.
+ **--resource-id — L'identificatore della risorsa**. Per questo parametro, il tipo di risorsa è `ReplicationGroup` e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ **—service-namespace**— Impostare questo valore su`elasticache`.
+ **—scalable-dimension**— Impostare questo valore su`elasticache:replication-group:NodeGroups`.
Nell'esempio seguente, si elimina una politica di scalabilità di tracciamento degli obiettivi denominata `myscalablepolicy` da un cluster denominato. `myscalablecluster`
Per Linux, macOS o Unix:
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:NodeGroups
```
Per Windows:
```
aws application-autoscaling delete-scaling-policy ^
--policy-name myscalablepolicy ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:NodeGroups
```
## Eliminazione di una policy di dimensionamento usando l’ API
Per eliminare una politica di scalabilità dal cluster ElastiCache for Valkey e Redis OSS, utilizza il comando con i [DeleteScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI seguenti parametri:
+ **—policy-name**– Il nome della policy di dimensionamento.
+ **--resource-id — L'identificatore della risorsa**. Per questo parametro, il tipo di risorsa è `ReplicationGroup` e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ **—service-namespace**— Impostare questo valore su`elasticache`.
+ **—scalable-dimension**— Impostare questo valore su`elasticache:replication-group:NodeGroups`.
Nell'esempio seguente, si elimina una politica di scalabilità di tracciamento degli obiettivi denominata `myscalablepolicy` da un cluster denominato. `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"
}
```
# Utilizzo CloudFormation per le politiche di Auto Scaling
Questo frammento mostra come creare una politica di tracciamento degli obiettivi e applicarla a una [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)risorsa che utilizza la risorsa. [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) Utilizza le funzioni intrinseche [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) e [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) per costruire la proprietà `ResourceId` con il nome logico della risorsa `AWS::ElastiCache::ReplicationGroup` specificata nello stesso modello.
```
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
```
# Dimensionamento pianificato
Il dimensionamento basato su una pianificazione consente di dimensionare le applicazioni in relazione alle variazioni di domanda prevedibili. Per utilizzare il ridimensionamento pianificato, si creano azioni pianificate, che indicano ElastiCache a Valkey e Redis OSS di eseguire attività di scalabilità in momenti specifici. Quando si crea un'azione pianificata, si specifica un cluster esistente, quando deve avvenire l'attività di scalabilità, la capacità minima e la capacità massima. È possibile creare operazioni pianificate sia una tantum che ricorrenti.
È possibile creare un'azione pianificata solo per i cluster già esistenti. Non è possibile creare operazioni pianificate contemporaneamente alla creazione di un cluster.
Per ulteriori informazioni sulla terminologia per la creazione, la gestione ed l'eliminazione di azioni pianificate, consulta [I comandi comunemente utilizzati per creazione, la gestione ed eliminazione](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)
**Per creare in base a una pianificazione ricorrente:**
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli **Valkey** o **Redis** OSS.
1. Scegli il cluster a cui desideri aggiungere una policy.
1. Scegli **Gestione delle policy di Auto Scaling** dal dropdown **Operazioni**.
1. Seleziona la scheda **Policy di Auto Scaling**.
1. Nella sezione **Policy di Auto Scaling** viene visualizzata la finestra di dialogo**Aggiungi policy di dimensionamento** Scegli **Dimensionamento pianificato**.
1. In **Nome policy**, immetti un nome per la policy.
1. Per **Dimensione scalabile**, scegliere **Partizioni**.
1. Per **Obiettivi delle partizioni**, scegliere il valore.
1. Per **Ricorrenza**, scegli **Ricorrente**.
1. Per **Frequenza**, scegli il rispettivo valore.
1. Per **Data di inizio** e **Ora di inizio**, scegli il momento in cui la policy entrerà in vigore.
1. Scegli **Aggiungi policy**.
**Per creare un'operazione pianificata una tantum**
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli **Valkey** o **Redis** OSS.
1. Scegli il cluster a cui desideri aggiungere una policy.
1. Scegli **Gestione delle policy di Auto Scaling** dal dropdown **Operazioni**.
1. Seleziona la scheda **Policy di Auto Scaling**.
1. Nella sezione **Policy di Auto Scaling** viene visualizzata la finestra di dialogo**Aggiungi policy di dimensionamento** Scegli **Dimensionamento pianificato**.
1. In **Nome policy**, immetti un nome per la policy.
1. Per **Dimensione scalabile**, scegliere **Partizioni**.
1. Per **Obiettivi delle partizioni**, scegliere il valore.
1. Per **Ricorrenza**, scegli **Una volta**.
1. Per **Data di inizio** e **Ora di inizio**, scegli il momento in cui la policy entrerà in vigore.
1. Per **Data di fine** scegli la data fino a quando la policy sarà in vigore.
1. Scegli **Aggiungi policy**.
**Per eliminare un'operazione pianificata**
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli **Valkey** o **Redis** OSS.
1. Scegli il cluster a cui desideri aggiungere una policy.
1. Scegli **Gestione delle policy di Auto Scaling** dal dropdown **Operazioni**.
1. Scegli la scheda **Policy di Auto Scaling**.
1. Nella sezione **Policy di Auto Scaling**, scegli la policy di Auto Scaling e successivamente **Elimina** dalla finestra di dialogo **Azioni**.
**Per gestire il dimensionamento pianificato tramite AWS CLI **
Utilizzate la seguente scalabilità automatica delle applicazioni: 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)
## Utilizza CloudFormation per creare un'operazione pianificata
Questo frammento mostra come creare una policy di tracciamento degli obiettivi e applicarla a una [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)risorsa che utilizza la [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)risorsa. Utilizza le funzioni intrinseche [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) e [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) per costruire la proprietà `ResourceId` con il nome logico della risorsa `AWS::ElastiCache::ReplicationGroup` specificata nello stesso modello.
```
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 * * ? *)'
```
# Utilizzo di Auto Scaling con le repliche
Un gruppo di ElastiCache replica può configurare una o più cache per funzionare come un singolo nodo logico.
Di seguito vengono forniti dettagli sul tracciamento degli obiettivi e sulle politiche pianificate e su come applicarle utilizzando and. Console di gestione AWS AWS CLI APIs
# Policy di dimensionamento con monitoraggio degli obiettivi
Con le politiche di scalabilità del tracciamento degli obiettivi, si seleziona una metrica e si imposta un valore obiettivo. ElastiCache for Valkey e Redis OSS AutoScaling crea e gestisce gli CloudWatch allarmi che attivano la politica di scalabilità e calcola l'aggiustamento della scalabilità in base alla metrica e al valore target. La policy di dimensionamento aggiunge o rimuove le repliche uniformemente come richiesto per mantenere il parametro al valore di destinazione specificato o vicino a esso. Oltre a mantenere il parametro vicino al valore di destinazione, una policy di dimensionamento di monitoraggio dei target si adatta anche alle fluttuazioni del parametro dovute a un modello di carico fluttuante e riduce al minimo le fluttuazioni rapide nella capacità del parco istanze.
## Criteri Auto Scaling per le repliche
La policy di Auto Scaling definisce il seguente parametro di default per il cluster:
`ElastiCacheReplicaEngineCPUUtilization`: La soglia di utilizzo della CPU del motore AVG aggregata tra tutte le repliche utilizzata per attivare un'operazione di auto-scaling. ElastiCache È possibile impostare l'obiettivo di utilizzo tra il 35 percento e il 70 percento.
Quando il servizio rileva che la `ElastiCacheReplicaEngineCPUUtilization` metrica è uguale o superiore all'impostazione di Target, aumenterà automaticamente le repliche tra gli shard. ElastiCache ridimensiona le repliche del cluster in base a un conteggio pari al più grande tra due numeri: variazione percentuale rispetto a Target e una replica. Per quanto riguarda la scalabilità in entrata, ElastiCache non verrà eseguita automaticamente a meno che il valore della metrica complessivo non sia inferiore al 75 percento del Target definito.
Per un esempio di aumento orizzontale, se si dispone di 5 shard e 1 replica ciascuno:
Se Target viene violato del 30 percento, ElastiCache per Valkey e Redis OSS viene ridimensionato di 1 replica (max (0,3, impostazione predefinita 1)) su tutti gli shard, il che si traduce in 5 shard con 2 repliche ciascuno,
Ad esempio, se hai selezionato un valore Target del 60 percento, ElastiCache per Valkey e Redis OSS non eseguirà la scalabilità automatica finché la metrica non sarà inferiore o uguale al 45 percento (25 percento inferiore al 60 percento di Target).
### Considerazioni su Auto Scaling
Tieni a mente le seguenti considerazioni:
+ Una policy di dimensionamento di monitoraggio obiettivi presuppone che essa debba eseguire un dimensionamento orizzontale quando il parametro specificato supera il valore di destinazione. Non è possibile utilizzare una politica di ridimensionamento del tracciamento del target per la scalabilità orizzontale quando la metrica specificata è inferiore al valore target. ElastiCache per Valkey e Redis OSS ridimensiona le repliche in base al massimo (deviazione in% arrotondata rispetto a Target, impostazione predefinita 1) delle repliche esistenti su tutti gli shard del cluster.
+ Una policy di dimensionamento di monitoraggio obiettivi non esegue il dimensionamento quando il parametro specificato non dispone di dati sufficienti. Non esegue la scalabilità in quanto la carenza di dati non viene interpretata come basso utilizzo.
+ Potrebbero esserci delle differenze tra il valore di destinazione e i punti di dati dei parametri reali. Questo perché ElastiCache Auto Scaling agisce sempre in modo conservativo arrotondando verso l'alto o verso il basso quando determina la quantità di capacità da aggiungere o rimuovere. In questo modo si impedisce l'aggiunta di capacità insufficiente o la rimozione di capacità eccessiva.
+ Per garantire la disponibilità delle applicazioni, il servizio aumenta orizzontalmente in proporzione al parametro il più veloce possibile, ma riduce orizzontalmente in modo più graduale con una riduzione orizzontale di 1 replica nelle partizioni nel cluster.
+ È possibile disporre di più politiche di scalabilità di tracciamento degli obiettivi per un cluster ElastiCache for Valkey e Redis OSS, a condizione che ciascuna di esse utilizzi una metrica diversa. L'intenzione di Auto Scaling è quella di dare sempre la priorità alla disponibilità, quindi il suo comportamento varia a seconda che le policy di tracciamento di destinazione siano pronte per la scalabilità orizzontale o verticale. Il servizio viene aumentato se una qualsiasi delle policy di monitoraggio obiettivi è pronta per l'aumento, ma viene ridotto solo se tutte le policy di monitoraggio obiettivi (con la porzione di riduzione abilitata) sono pronte per la riduzione.
+ Non modificate o eliminate gli CloudWatch allarmi gestiti da ElastiCache Auto Scaling per una politica di scalabilità di tracciamento degli obiettivi. Auto Scaling elimina automaticamente gli allarmi quando si elimina la politica di scalabilità o si elimina il cluster.
+ ElastiCache L'Auto Scaling non impedisce di modificare manualmente le repliche tra gli shard. Queste regolazioni manuali non influiscono sugli CloudWatch allarmi esistenti associati alla politica di scalabilità, ma possono influire sulle metriche che possono attivare questi allarmi. CloudWatch
+ Questi CloudWatch allarmi gestiti da Auto Scaling sono definiti sulla base della metrica AVG su tutti gli shard del cluster. Quindi, avere frammenti caldi può comportare uno scenario di:
+ ridimensionamento quando non necessario a causa del caricamento su alcuni shard caldi che attiva un allarme CloudWatch
+ non dimensionare quando richiesto a causa di AVG aggregato su tutti le partizioni che influiscono sull'allarme non violato.
+ ElastiCache i limiti predefiniti sui nodi per cluster sono ancora validi. Pertanto, quando si opta per il Auto Scaling e se si prevede che i nodi massimi siano superiori al limite di default, è necessario richiedere un aumento del limite a[AWS Restrizioni dei servizi](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)e scegliere il tipo di limite**Nodi per cluster per tipo di istanza**.
+ Assicurati di avere abbastanza ENIs (interfacce di rete elastiche) disponibili nel tuo VPC, necessarie durante la scalabilità orizzontale. Per ulteriori informazioni, consulta [Interfacce di rete elastiche](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html).
+ Se non è disponibile una capacità sufficiente da EC2, ElastiCache Auto Scaling non eseguirà la scalabilità orizzontale finché la capacità non sarà disponibile o se si modifica manualmente il cluster in base ai tipi di istanza con capacità sufficiente.
+ ElastiCache Auto Scaling non supporta la scalabilità delle repliche con un cluster con `ReservedMemoryPercent` meno del 25 percento. Per ulteriori informazioni, consulta [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md).
# Aggiunta di una policy di dimensionamento
È possibile aggiungere una politica di scalabilità utilizzando. Console di gestione AWS
**Aggiungere una politica di scalabilità utilizzando il Console di gestione AWS**
Per aggiungere una politica di ridimensionamento automatico ElastiCache per Valkey e Redis OSS
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli **Valkey** o **Redis** OSS.
1. Scegli il cluster a cui aggiungere una policy (seleziona il nome del cluster e non il pulsante a sinistra del cluster).
1. Seleziona la scheda **Policy di Auto Scaling**.
1. Scegli **Add dynamic scaling** (Aggiungi dimensionamento automatico).
1. In **Policy di dimensionamento**, scegli **Add dynamic scaling** (Aggiungi dimensionamento automatico).
1. In **Policy Name (Nome policy)**, immettere un nome per la policy.
1. Per **Dimensione scalabile**, scegliere **Repliche** dalla finestra di dialogo.
1. Come valore target, digita la percentuale media di utilizzo della CPU che desideri mantenere sulle repliche. ElastiCache Questo valore deve essere tra >=35 e <=70. Le repliche dei cluster vengono aggiunte o rimosse per tenere il parametro vicino al valore specificato.
1. (Facoltativo) I periodi di attesa di riduzione o aumento non sono supportati dalla console. Utilizzate il AWS CLI per modificare i valori di raffreddamento.
1. Per **Capacità minima**, digitare il numero minimo di repliche che la policy ElastiCache Auto Scaling deve gestire.
1. Per **Capacità massima**, digitare il numero massimo di repliche che la policy di ElastiCache Auto Scaling deve mantenere. Questo valore deve essere >=5.
1. Scegli **Create** (Crea).
# Registrazione di un obiettivo scalabile
Puoi applicare una policy di dimensionamento basata un parametro di default o personalizzato. A tale scopo, puoi utilizzare AWS CLI o l'API Application Auto Scaling. Il primo passo consiste nel registrare il proprio gruppo di replica ElastiCache per Valkey e Redis OSS con Auto Scaling.
Prima di poter utilizzare la scalabilità ElastiCache automatica con un cluster, è necessario registrare il cluster con la scalabilità ElastiCache automatica. Lo fai per definire la dimensione di scalabilità e i limiti da applicare a quel cluster. ElastiCache la scalabilità automatica ridimensiona dinamicamente il cluster lungo la dimensione `elasticache:replication-group:Replicas` scalabile, che rappresenta il numero di repliche del cluster per shard.
**Utilizzo della CLI**
Per registrare il ElastiCache cluster, utilizzate il comando con i [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)seguenti parametri:
+ —service-namespace — Impostare questo valore su elasticache.
+ --resource-id — L'identificatore di risorsa per il cluster. ElastiCache Per questo parametro, il tipo di risorsa è ReplicationGroup e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ —scalable-dimension — Imposta questo valore su `elasticache:replication-group:Replicas`.
+ --min-capacity — Il numero minimo di repliche da gestire tramite auto scaling. ElastiCache Per informazioni sulla relazione tra —capacità-min, —capacità-max il numero di repliche nel cluster, consulta.[Capacità minima e massima](AutoScaling-Policies.md#AutoScaling-MinMax).
+ --max-capacity — Il numero massimo di repliche da gestire tramite auto scaling. ElastiCache Per informazioni sulla relazione tra —capacità-min, —capacità-max il numero di repliche nel cluster, consulta.[Capacità minima e massima](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Nell'esempio seguente, si registra un cluster denominato. ElastiCache `myscalablecluster` La registrazione indica che il cluster deve essere dimensionato dinamicamente per avere da una a 5 repliche .
Per Linux, macOS o 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 \
```
Per 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 ^
```
**Utilizzo dell'API**
Per registrare il ElastiCache cluster, utilizzate il [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)comando con i seguenti parametri:
+ ServiceNamespace — Imposta questo valore su elasticache.
+ resourceID: l'identificatore della risorsa per il cluster. ElastiCache Per questo parametro, il tipo di risorsa è ReplicationGroup e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ ScalableDimension — Imposta questo valore su. `elasticache:replication-group:Replicas`
+ MinCapacity — Il numero minimo di repliche da gestire mediante la scalabilità ElastiCache automatica. Per informazioni sulla relazione tra —capacità-min, —capacità-max il numero di repliche nel cluster, consulta.[Capacità minima e massima](AutoScaling-Policies.md#AutoScaling-MinMax).
+ MaxCapacity — Il numero massimo di repliche da gestire mediante la scalabilità ElastiCache automatica. Per informazioni sulla relazione tra —capacità-min, —capacità-max il numero di repliche nel cluster, consulta.[Capacità minima e massima](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
Nell'esempio seguente, si registra un cluster denominato `myscalablecluster` con l'API Application Auto Scaling. Questa registrazione indica che il cluster database deve essere dimensionato dinamicamente per avere da uno a 5 repliche .
```
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
}
```
# Definizione di una policy di dimensionamento
Una configurazione della policy di dimensionamento di monitoraggio degli obiettivi è rappresentata da un blocco JSON in cui sono definiti i valori dei parametri e della destinazione. Puoi salvare una configurazione della policy di dimensionamento come un blocco JSON in un file di testo. Si utilizza quel file di testo quando si richiama l'API AWS CLI Application Auto Scaling. Per ulteriori informazioni sulla sintassi della configurazione della policy, consulta [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in *Application Auto Scaling API Reference*.
Le seguenti opzioni sono disponibili per definire una configurazione di una policy di dimensionamento con monitoraggio degli obiettivi.
**Topics**
+ [Utilizzo di un parametro di default](#AutoScaling-Predefined-Metric)
+ [Modifica di una policy di dimensionamento](AutoScaling-Editing-Policy.md)
+ [Eliminazione di una policy di dimensionamento](AutoScaling-Deleting-Policy.md)
+ [Utilizzo CloudFormation per le politiche di Auto Scaling](AutoScaling-with-Cloudformation.md)
+ [Dimensionamento pianificato](AutoScaling-with-Scheduled-Scaling-Replicas.md)
## Utilizzo di un parametro di default
Una configurazione della policy di dimensionamento di monitoraggio degli obiettivi è rappresentata da un blocco JSON in cui sono definiti i valori dei parametri e della destinazione. Puoi salvare una configurazione della policy di dimensionamento come un blocco JSON in un file di testo. Si utilizza quel file di testo quando si richiama l'API AWS CLI Application Auto Scaling. Per ulteriori informazioni sulla sintassi della configurazione della policy, consulta [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in *Application Auto Scaling API Reference*.
Le seguenti opzioni sono disponibili per definire una configurazione di una policy di dimensionamento con monitoraggio degli obiettivi.
**Topics**
+ [Utilizzo di un parametro di default](#AutoScaling-Predefined-Metric)
+ [Utilizzo di un parametro personalizzato](#AutoScaling-Custom-Metric)
+ [Utilizzo di periodi di attesa](#AutoScaling-Using-Cooldowns)
+ [Disabilitazione dell'attività di riduzione orizzontale](#AutoScaling-Disabling-Scalein)
+ [Applicazione di una politica di scalabilità a un cluster for Valkey e Redis ElastiCache OSS](#AutoScaling-Applying-Policy)
### Utilizzo di un parametro di default
Utilizzando metriche predefinite, puoi definire rapidamente una politica di scalabilità del tracciamento del target per un cluster ElastiCache for Valkey e Redis OSS che funziona con il tracciamento del target in Auto Scaling. ElastiCache Attualmente, ElastiCache supporta la seguente metrica predefinita in ElastiCache Replicas Auto Scaling:
`ElastiCacheReplicaEngineCPUUtilization`— Il valore medio della CPUUtilization metrica Engine in tutte le repliche del CloudWatch cluster. Puoi trovare il valore aggregato della metrica CloudWatch in basso ElastiCache `ReplicationGroupId, Role` per Required e Role Replica. ReplicationGroupId
Per utilizzare un parametro di default nella policy di dimensionamento, crea una configurazione di monitoraggio degli obiettivi per la policy di dimensionamento. La configurazione deve includere un `PredefinedMetricSpecification` per il parametro di default e un `TargetValue` per il valore di destinazione del parametro.
### Utilizzo di un parametro personalizzato
Utilizzando dei parametri personalizzati, è possibile definire una policy di dimensionamento di monitoraggio degli obiettivi che soddisfi i requisiti personalizzati. È possibile definire una metrica personalizzata basata su qualsiasi ElastiCache metrica di Valkey e Redis OSS che cambia in proporzione alla scalabilità. Non tutte le ElastiCache metriche funzionano per il tracciamento degli obiettivi. Il parametro deve essere un parametro di utilizzo valido e deve descrivere quanto è impegnata un'istanza. Il valore del parametro deve aumentare o diminuire in proporzione al numero di repliche nel cluster . Questo aumento o riduzione proporzionale è necessario per utilizzare i dati del parametro per aumentare o diminuire in modo proporzionale il numero di repliche .
**Example**
Il seguente esempio descrive una configurazione di monitoraggio degli obiettivi per una policy di dimensionamento. In questa configurazione, una metrica personalizzata regola un cluster in base a un utilizzo medio della CPU del 50% su tutte le repliche di un cluster denominato. `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"
}
}
```
### Utilizzo di periodi di attesa
È possibile specificare un valore, in secondi, per `ScaleOutCooldown` per aggiungere un periodo di attesa per il dimensionamento orizzontale del cluster. Allo stesso modo, è possibile aggiungere un valore, in secondi, per `ScaleInCooldown` per aggiungere un periodo di attesa per la riduzione del cluster. Per ulteriori informazioni su `ScaleInCooldown` e `ScaleOutCooldown`, consulta [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in *Riferimento API Auto Scaling dell'applicazione*. Il seguente esempio descrive una configurazione di monitoraggio degli obiettivi per una policy di dimensionamento. In questa configurazione, la metrica `ElastiCacheReplicaEngineCPUUtilization` predefinita viene utilizzata per regolare un cluster in base a un utilizzo medio della CPU del 40% su tutte le repliche di quel cluster. La configurazione fornisce un tempo di raffreddamento di riduzione orizzontale di 10 minuti e un tempo di raffreddamento di aumento di 5 minuti.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
### Disabilitazione dell'attività di riduzione orizzontale
È possibile impedire che la configurazione della policy di scalabilità target-tracking venga scalata nel cluster ElastiCache for Valkey e Redis OSS disabilitando l'attività di scalabilità in. La disabilitazione delle attività di riduzione impedisce alla policy di dimensionamento di eliminare le repliche , consentendo tuttavia alla policy di dimensionamento di aggiungerle in base alle esigenze.
È possibile specificare un valore booleano per `DisableScaleIn` per abilitare o disabilitare l'attività di riduzione per il cluster database . Per ulteriori informazioni su `DisableScaleIn`, consulta [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) in *Riferimento API Auto Scaling dell'applicazione*.
**Example**
Il seguente esempio descrive una configurazione di monitoraggio degli obiettivi per una policy di dimensionamento. In questa configurazione, la metrica `ElastiCacheReplicaEngineCPUUtilization` predefinita regola un cluster in base a un utilizzo medio della CPU del 40% su tutte le repliche di quel cluster. La configurazione disabilita l'attività di riduzione per la policy di dimensionamento.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
### Applicazione di una politica di scalabilità a un cluster for Valkey e Redis ElastiCache OSS
Dopo aver registrato il cluster con la scalabilità automatica ElastiCache di Valkey e Redis OSS e aver definito una politica di scalabilità, applichi la politica di scalabilità al cluster registrato. Per applicare una politica di scalabilità a un cluster ElastiCache for Valkey e Redis OSS, puoi utilizzare AWS CLI o l'API Application Auto Scaling.
**Utilizzando il AWS CLI**
Per applicare una politica di scalabilità al cluster ElastiCache for Valkey e Redis OSS, utilizza il [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)comando con i seguenti parametri:
+ —policy-name– Il nome della policy di dimensionamento.
+ —policy-type — Impostare questo valore su `TargetTrackingScaling`.
+ --resource-id — L'identificatore di risorsa per il cluster. Per questo parametro, il tipo di risorsa è ReplicationGroup e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ —service-namespace — Impostare questo valore su elasticache.
+ —scalable-dimension — Imposta questo valore su `elasticache:replication-group:Replicas`.
+ -- target-tracking-scaling-policy -configuration — La configurazione della policy di scalabilità target-tracking da utilizzare per il cluster.
**Example**
Nell'esempio seguente, si applica una politica di scalabilità di tracciamento della destinazione denominata `myscalablepolicy` a un cluster denominato `myscalablecluster` auto ElastiCache scaling. Per fare ciò, usa la configurazione della policy salvata in un file denominato `config.json`.
Per Linux, macOS o 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
}
```
Per 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
```
**Utilizzo dell'API**
Per applicare una policy di scaling al ElastiCache cluster con l'API Application Auto Scaling, utilizza [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)l'operazione Application Auto Scaling API con i seguenti parametri:
+ PolicyName — Il nome della politica di scalabilità.
+ PolicyType — Imposta questo valore su. `TargetTrackingScaling`
+ resourceID: l'identificatore della risorsa per il cluster. Per questo parametro, il tipo di risorsa è ReplicationGroup e l'identificatore univoco è il nome del cluster ElastiCache for Redis OSS, ad esempio. `replication-group/myscalablecluster`
+ ServiceNamespace — Imposta questo valore su elasticache.
+ ScalableDimension — Imposta questo valore su. `elasticache:replication-group:Replicas`
+ TargetTrackingScalingPolicyConfiguration — La configurazione della politica di scalabilità del target-tracking da utilizzare per il cluster.
**Example**
Nell'esempio seguente, si applica una politica di scalabilità di tracciamento della destinazione denominata `scalablepolicy` a un cluster denominato `myscalablecluster` auto ElastiCache scaling. Si utilizza una policy di configurazione in base al parametro di default `ElastiCacheReplicaEngineCPUUtilization`.
```
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"
}
}
}
```
# Modifica di una policy di dimensionamento
È possibile modificare una politica di scalabilità utilizzando Console di gestione AWS l'API AWS CLI Application Auto Scaling.
**Modifica di una politica di scalabilità utilizzando il Console di gestione AWS**
È possibile modificare i criteri solo con tipo Parametri predefiniti utilizzando la Console di gestione AWS
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli **Valkey** o **Redis OSS**
1. Scegli il cluster a cui aggiungere una policy (seleziona il nome del cluster e non il pulsante a sinistra del cluster).
1. Seleziona la scheda **Policy di Auto Scaling**.
1. In **Policy di dimensionamento** scegli il pulsante a sinistra della policy di Auto Scaling su cui eseguire la modifica, quindi scegli **Modify** (Modifica).
1. Apportare le modifiche necessarie alla policy.
1. Scegli **Modifica**.
1. Apportare modifiche alla policy.
1. Scegli **Modifica**.
**Modifica di una politica di scalabilità utilizzando l'API AWS CLI Application Auto Scaling**
È possibile utilizzare l'API Application Auto Scaling AWS CLI o l'API Application Auto Scaling per modificare una policy di scaling nello stesso modo in cui si applica una policy di scaling:
+ Quando si utilizza l'API Application Auto Scaling, specificare il nome della policy da modificare nel parametro `PolicyName`. Specifica i nuovi valori per i parametri che desideri modificare.
Per ulteriori informazioni, consulta [Applicazione di una politica di scalabilità a un cluster for Valkey e Redis ElastiCache OSS](AutoScaling-Defining-Policy.md#AutoScaling-Applying-Policy).
# Eliminazione di una policy di dimensionamento
È possibile eliminare una politica di scalabilità utilizzando Console di gestione AWS l' AWS CLI API Application Auto Scaling
**Eliminazione di una politica di scalabilità utilizzando il Console di gestione AWS**
È possibile modificare i criteri solo con tipo Parametri predefiniti utilizzando la Console di gestione AWS
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli **Valkey** o **Redis OSS**
1. Scegliere il cluster con la policy di Auto Scaling che si desidera eliminare.
1. Seleziona la scheda **Policy Auto Scaling**.
1. Nella sezione **Scaling Policies** (Policy di dimensionamento), scegli la policy di Auto Scaling e successivamente **Delete** (Elimina).
**Eliminazione di una politica di scalabilità utilizzando l'API AWS CLI Application Auto Scaling**
È possibile utilizzare l'API Application Auto Scaling AWS CLI o l'API Application Auto Scaling per eliminare una politica di scalabilità da un cluster. ElastiCache
**CLI**
Per eliminare una politica di scalabilità dal cluster ElastiCache for Valkey e Redis OSS, utilizza il [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html)comando con i seguenti parametri:
+ —policy-name– Il nome della policy di dimensionamento.
+ --resource-id — L'identificatore di risorsa per il cluster. Per questo parametro, il tipo di risorsa è ReplicationGroup e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ —service-namespace — Impostare questo valore su elasticache.
+ —scalable-dimension — Imposta questo valore su`elasticache:replication-group:Replicas`.
**Example**
Nell'esempio seguente, eliminare una policy di dimensionamento con monitoraggio degli obiettivi denominata `myscalablepolicy` da un cluster ELC denominato `myscalablecluster`.
Per Linux, macOS o Unix:
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:Replicas \
```
Per 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**
Per eliminare una politica di scalabilità dal cluster ElastiCache for Valkey e Redis OSS, utilizza l'[DeleteScalingPolicy](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_DeleteScalingPolicy.html)operazione API Application Auto Scaling con i seguenti parametri:
+ PolicyName — Il nome della politica di scalabilità.
+ resourceID: l'identificatore della risorsa per il cluster. Per questo parametro, il tipo di risorsa è ReplicationGroup e l'identificatore univoco è il nome del cluster, ad esempio. `replication-group/myscalablecluster`
+ ServiceNamespace — Imposta questo valore su elasticache.
+ ScalableDimension — Imposta questo valore su. `elasticache:replication-group:Replicas`
Nell'esempio seguente, si elimina una policy di scaling di tracciamento del target denominata `myscalablepolicy` da un cluster denominato `myscalablecluster` con l'API Application Auto Scaling.
```
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"
}
```
# Utilizzo CloudFormation per le politiche di Auto Scaling
Questo frammento mostra come creare un'azione pianificata e applicarla a una [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)risorsa che utilizza la risorsa. [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html) Utilizza le funzioni intrinseche [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) e [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) per costruire la proprietà `ResourceId` con il nome logico della risorsa `AWS::ElastiCache::ReplicationGroup` specificata nello stesso modello.
```
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
```
# Dimensionamento pianificato
Il dimensionamento basato su una pianificazione consente di dimensionare le applicazioni in relazione alle variazioni di domanda prevedibili. Per utilizzare il ridimensionamento pianificato, si creano azioni pianificate, che indicano ElastiCache a Valkey e Redis OSS di eseguire attività di scalabilità in momenti specifici. Quando si crea un'azione pianificata, si specifica un ElastiCache cluster esistente, quando deve avvenire l'attività di scalabilità, la capacità minima e la capacità massima. È possibile creare operazioni pianificate sia una tantum che ricorrenti.
È possibile creare un'azione pianificata solo per ElastiCache i cluster già esistenti. Non è possibile creare operazioni pianificate contemporaneamente alla creazione di un cluster.
Per ulteriori informazioni sulla terminologia per la creazione, la gestione ed l'eliminazione di azioni pianificate, consulta[I comandi comunemente utilizzati per creazione, la gestione ed eliminazione](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)
**Per creare un'operazione pianificata una tantum**
Simile alla dimensione di Partizione. Consultare [Dimensionamento pianificato](AutoScaling-with-Scheduled-Scaling-Shards.md).
**Per eliminare un'operazione pianificata**
Simile alla dimensione Partizione. Consultare [Dimensionamento pianificato](AutoScaling-with-Scheduled-Scaling-Shards.md).
**Per gestire il dimensionamento pianificato tramite AWS CLI **
Utilizzate la seguente scalabilità automatica delle applicazioni 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)
## Utilizzabile CloudFormation per creare politiche di Auto Scaling
Questo frammento mostra come creare un'azione pianificata e applicarla a una [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html)risorsa che utilizza la [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)risorsa. Utilizza le funzioni intrinseche [Fn::Join](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-join.html) e [Ref](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-ref.html) per costruire la proprietà `ResourceId` con il nome logico della risorsa `AWS::ElastiCache::ReplicationGroup` specificata nello stesso modello.
```
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 * * ? *)'
```
# Modifica della modalità cluster
Valkey e Redis OSS sono database distribuiti in memoria che supportano lo sharding e la replica. ElastiCache I cluster Valkey e Redis OSS sono l'implementazione distribuita che consente il partizionamento dei dati su più nodi. Un ElastiCache cluster Redis OSS ha due modalità operative, la modalità cluster abilitata (CME) e la modalità cluster disabilitata (CMD). In CME, un motore Valkey e Redis OSS funziona come un database distribuito con più shard e nodi, mentre in CMD, Valkey e Redis OSS funzionano come un singolo nodo.
Prima di eseguire la migrazione da CMD a CME, devono essere soddisfatte le condizioni seguenti:
**Importante**
La configurazione della modalità cluster può essere modificata solo dalla modalità cluster disabilitata alla modalità cluster abilitata. Non è possibile ripristinare questa configurazione.
+ Il cluster può contenere chiavi solo nel database 0.
+ Le applicazioni devono utilizzare un client Valkey o Redis OSS in grado di utilizzare il protocollo Cluster e utilizzare un endpoint di configurazione.
+ Il failover automatico deve essere abilitato sul cluster con almeno 1 replica.
+ La versione minima del motore richiesta per la migrazione è Valkey 7.2 e versioni successive o Redis OSS 7.0 e versioni successive.
Per eseguire la migrazione da CMD a CME, la configurazione della modalità cluster può essere modificata solo dalla modalità cluster disabilitata alla modalità cluster abilitata. Si tratta di una procedura in due fasi che garantisce la disponibilità del cluster durante il processo di migrazione.
**Nota**
È necessario fornire un gruppo di parametri con una configurazione abilitata per i cluster, ovvero, il parametro abilitato per i cluster è impostato come `yes`. Se si utilizza un gruppo di parametri predefinito, ElastiCache per Redis OSS sceglierà automaticamente il gruppo di parametri predefinito corrispondente con una configurazione abilitata per il cluster. Il valore del parametro abilitato per i cluster è impostato su `no` per un cluster CMD. Quando il cluster passa alla modalità compatibile, il valore del parametro abilitato per i cluster viene aggiornato a `yes` come parte dell'azione di modifica.
Per ulteriori informazioni, consulta [Configurazione dei parametri del motore utilizzando gruppi di ElastiCache parametri](ParameterGroups.md)
1. **Preparazione**: crea un cluster CME di test e assicurati che lo stack sia pronto per utilizzarlo. ElastiCache for Redis OSS non ha modo di verificare la tua disponibilità. Per ulteriori informazioni, consulta [Creazione di un cluster per Valkey o Redis OSS](Clusters.Create.md).
1. **Modifica la configurazione del cluster CMD esistente rendendola compatibile con** la modalità cluster: in questa modalità, verrà distribuito un singolo shard e ElastiCache per Redis OSS funzionerà come nodo singolo ma anche come cluster a singolo shard. Modalità compatibile significa che l'applicazione client può utilizzare entrambi i protocolli per comunicare con il cluster. In questa modalità, le applicazioni devono essere riconfigurate per iniziare a utilizzare il protocollo Valkey o Redis OSS Cluster e l'endpoint di configurazione. Per modificare la modalità cluster Valkey o Redis OSS in una modalità compatibile con la modalità cluster, procedi nel seguente modo:
**Nota**
In modalità compatibile, altre operazioni di modifica come il dimensionamento e la versione del motore non sono consentite per il cluster. Inoltre, i parametri (esclusi`cacheParameterGroupName`) non possono essere modificati quando si definisce il parametro in modalità cluster all'interno della richiesta. [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
1. **Utilizzando Console di gestione AWS, visualizza [Modifica di un gruppo di replica](Replication.Modify.md) e imposta la modalità cluster su Compatibile**
1. Utilizzando l'API, visualizza [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)e aggiorna il `ClusterMode` parametro su`compatible`.
1. Utilizzando AWS CLI, visualizza [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)e aggiorna il `cluster-mode` parametro su`compatible`.
Dopo aver modificato la modalità cluster Valkey o Redis OSS in una modalità compatibile con la modalità cluster, l'[DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API restituirà l'endpoint di configurazione del ElastiCache cluster Redis OSS. L'endpoint di configurazione del cluster è un endpoint singolo che può essere utilizzato dalle applicazioni per connettersi al cluster. Per ulteriori informazioni, consulta [Ricerca degli endpoint di connessione in ElastiCache](Endpoints.md).
1. **Modifica della configurazione del cluster nella modalità cluster abilitata**: una volta impostata la modalità cluster sulla modalità cluster compatibile, il secondo passaggio consiste nel modificare la configurazione del cluster in modalità cluster abilitata. In questa modalità, viene eseguita una partizione singola e i clienti possono ora scalare i propri cluster o modificare altre configurazioni del cluster.
Per cambiare la modalità cluster in abilitata, procedi nel modo seguente:
Prima di iniziare, assicurati che i tuoi client Valkey o Redis OSS siano migrati all'utilizzo del protocollo cluster e che l'endpoint di configurazione del cluster non sia in uso.
1. **Utilizzando Console di gestione AWS, visualizza [Modifica di un gruppo di replica](Replication.Modify.md) e imposta la modalità cluster su Enabled.**
1. Utilizzando l'API, visualizza [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)e aggiorna il `ClusterMode` parametro su`enabled`.
1. Utilizzando AWS CLI, visualizza [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)e aggiorna il `cluster-mode` parametro su`enabled`.
Dopo aver modificato la modalità cluster in abilitata, gli endpoint verranno configurati secondo le specifiche del cluster Valkey o Redis OSS. L'[DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API restituirà il parametro della modalità cluster `enabled` e gli endpoint del cluster che ora sono disponibili per essere utilizzati dalle applicazioni per la connessione al cluster.
Tieni presente che gli endpoint del cluster cambieranno dopo che la modalità cluster viene modificata in abilitata. Assicurati di aggiornare le applicazioni con i nuovi endpoint.
Puoi anche scegliere di tornare alla modalità cluster disabilitata (CMD) dalla modalità cluster compatibile e preservare le configurazioni originali.
**Modifica della configurazione del cluster nella modalità cluster disabilitata dalla modalità cluster compatibile**
1. **Utilizzando Console di gestione AWS, visualizza [Modifica di un gruppo di replica](Replication.Modify.md) e imposta la modalità cluster su Disabilitato**
1. Utilizzando l'API, visualizza [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)e aggiorna il `ClusterMode` parametro su`disabled`.
1. Utilizzando AWS CLI, visualizza [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)e aggiorna il `cluster-mode` parametro su`disabled`.
Dopo aver modificato la modalità cluster in disabilitata, l'[DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API restituirà il parametro della modalità cluster come`disabled`.
# Replica tra AWS regioni utilizzando datastore globali
**Nota**
Global Datastore è attualmente disponibile solo per i cluster basati su nodi.
Utilizzando la funzionalità Global Datastore, puoi lavorare con una replica di cluster Valkey o Redis OSS completamente gestita, veloce, affidabile e sicura in tutte le regioni.AWS Utilizzando questa funzionalità, è possibile creare cluster di replica di lettura interregionali per consentire letture a bassa latenza e disaster recovery tra le regioni.AWS
Nelle sezioni seguenti è possibile trovare una descrizione di come utilizzare i Global Datastore.
**Topics**
+ [Panoramica di](#Redis-Global-Data-Stores-Overview)
+ [Prerequisiti e limitazioni](Redis-Global-Datastores-Getting-Started.md)
+ [Utilizzo di Global Datastore (Console)](Redis-Global-Datastores-Console.md)
+ [Utilizzo di Global Datastore (CLI)](Redis-Global-Datastores-CLI.md)
## Panoramica di
Ogni *Global Datastore* è una raccolta di uno o più cluster che si replicano tra loro.
Un Global Datastore è costituito dai seguenti elementi:
+ **Cluster primario (attivo)**— Un cluster primario accetta scritture replicate in tutti i cluster all'interno del datastore globale. Un cluster primario accetta anche richieste di lettura.
+ **Cluster secondario (passivo)**— Un cluster secondario accetta solo richieste di lettura e replica gli aggiornamenti dei dati da un cluster primario. Un cluster secondario deve trovarsi in una AWS regione diversa rispetto al cluster primario.
Quando crei un datastore globale ElastiCache per Valkey o Redis OSS, esso replica automaticamente i dati dal cluster primario al cluster secondario. Scegli la AWS regione in cui replicare i dati Valkey o Redis OSS e quindi crei un cluster secondario in quella regione.AWS ElastiCache quindi configura e gestisce la replica automatica e asincrona dei dati tra i due cluster.
L'utilizzo di un datastore globale per Valkey o Redis OSS offre i seguenti vantaggi:
+ **Prestazioni geolocali**: configurando cluster di replica remoti in AWS regioni aggiuntive e sincronizzando i dati tra di essi, è possibile ridurre la latenza di accesso ai dati in quella regione.AWS Un datastore globale può contribuire ad aumentare la reattività dell'applicazione fornendo letture geolocali a bassa latenza in tutte le regioni.AWS
+ **Ripristino di emergenza**: se il cluster primario in un datastore globale subisce una degradazione, è possibile promuovere un cluster secondario come nuovo cluster primario. Puoi farlo connettendoti a qualsiasi regione che contiene un cluster secondario.AWS
Il diagramma seguente mostra come possono funzionare i Global Datastore.
![\[Global Datastore\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/Global-DataStore.png)
# Prerequisiti e limitazioni
Prima di iniziare a utilizzare i Global Datastore, tenere presente quanto segue:
+ I datastore globali sono supportati nelle seguenti regioni: AWS
+ **Africa - Città** del Capo
+ **Asia Pacifico** - Hong Kong, Hyderabad, Giacarta, Malesia, Melbourne, Mumbai, Osaka, Seul, Singapore, Sydney, Tailandia e Tokyo
+ **Canada** - Canada centrale e Canada occidentale (Calgary)
+ **Cina** - Pechino e Ningxia
+ **Europa**: Francoforte, Londra, Irlanda, Milano, Parigi, Spagna, Stoccolma e Zurigo
+ **AWS GovCloud**-Stati Uniti occidentali e Stati Uniti orientali
+ **Israele** - Tel Aviv
+ **Medio Oriente** - Bahrein e Emirati Arabi Uniti
+ **Stati Uniti** orientali (Virginia settentrionale e Ohio) e Stati Uniti occidentali (California settentrionale e Oregon)
+ **Sud America** - Messico (centrale) e San Paolo
+ Tutti i cluster, primari e secondari, nel datastore globale, devono avere lo stesso numero di nodi primari, tipo di nodo, versione del motore e numero di frammenti (in caso di modalità cluster abilitata). Ogni cluster nel Global Datastore può avere un numero diverso di repliche di lettura per gestire il traffico di lettura locale al cluster.
La replica deve essere abilitata se si prevede di utilizzare un cluster a nodo singolo esistente.
+ I datastore globali sono supportati su istanze di dimensioni superiori o superiori.
+ È possibile configurare la replica per un cluster primario da una AWS regione a un cluster secondario in un massimo di altre due regioni. AWS
**Nota**
Le eccezioni sono le regioni Cina (Pechino) Regione e Cina (Ningxia), dove la replica può avvenire solo tra le due regioni.
+ È possibile utilizzare i Global Datastore solo nei cluster VPC. Per ulteriori informazioni, consulta [Modelli di accesso per l'accesso a una ElastiCache cache in un Amazon VPC](elasticache-vpc-accessing.md). I datastore globali non sono supportati quando si utilizza -Classic. EC2 Per ulteriori informazioni, consulta [EC2-Classic](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-classic-platform.html) nella *Amazon EC2 User Guide*.
**Nota**
Al momento, non è possibile utilizzare gli archivi dati globali in[Utilizzo delle zone locali con ElastiCache](Local_zones.md).
+ ElastiCache non supporta il failover automatico da una regione all'altra AWS . Se necessario, è possibile promuovere manualmente un cluster secondario. Per vedere un esempio, consulta [Promozione del cluster secondario a primario](Redis-Global-Datastores-Console.md#Redis-Global-Datastores-Console-Promote-Secondary).
+ Per eseguire il bootstrap dai dati esistenti, utilizzare un cluster esistente come primario per creare un Global Datastore. Non supportiamo l'aggiunta di un cluster esistente come cluster secondario. Il processo di aggiunta del cluster come secondario elimina i dati e quindi può causare la perdita di dati.
+ Gli aggiornamenti dei parametri vengono applicati a tutti i cluster quando si modifica un gruppo di parametri locale di un cluster appartenente a un Global Datastore.
+ È possibile dimensionare i cluster regionali sia verticalmente (dimensionamento verticale) che orizzontalmente (dimensionamento orizzontale). È possibile dimensionare i cluster modificando il Global Datastore. Tutti i cluster regionali nel Global Datastore vengono quindi dimensionati senza interruzioni. Per ulteriori informazioni, consulta [Ridimensionamento ElastiCache](Scaling.md).
+ [I datastore globali supportano la [crittografia a riposo, la crittografia in transito](at-rest-encryption.md) e l'[AUTH](in-transit-encryption.md).](auth.md)
+ I datastore globali non supportano la versione 6 del protocollo Internet (). IPv6
+ I datastore globali supportano le chiavi. AWS KMS Per ulteriori informazioni, consulta [AWS concetti chiave di servizi gestiti](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys) nella *AWS Key Management Service Guida per gli sviluppatori*.
**Nota**
I Global Datastore supportano la [messaggistica PUB/SUB](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/elasticache-use-cases.html#elasticache-for-redis-use-cases-messaging) con le seguenti disposizioni:
Per la modalità cluster disabilitata, pub/sub è completamente supportata. Gli eventi pubblicati sul cluster primario della AWS regione primaria vengono propagati alle regioni secondarie. AWS
Per la modalità cluster abilitata, si applica quanto segue:
Per gli eventi pubblicati che non si trovano in un keyspace, solo gli abbonati della stessa AWS regione ricevono gli eventi.
Per gli eventi keyspace pubblicati, gli abbonati di tutte le AWS regioni ricevono gli eventi.
# Utilizzo di Global Datastore (Console)
Per creare un Global Datastore utilizzando la console, attenersi a questa procedura in due fasi:
1. Creare un cluster primario, utilizzando un cluster esistente o creandone uno nuovo. Il motore deve essere Valkey 7.2 o successivo oppure Redis OSS 5.0.6 o successivo.
1. Aggiungi fino a due cluster secondari in AWS regioni diverse, sempre utilizzando Valkey 7.2 o versione successiva oppure Redis OSS 5.0.6 o versione successiva.
Le seguenti procedure guidano l'utente su come creare un datastore globale per Valkey o Redis OSS ed eseguire altre operazioni utilizzando la console. ElastiCache
**Topics**
+ [Creazione di un Global Datastore utilizzando un cluster esistente](#Redis-Global-Datastores-Console-Create-Primary)
+ [Creazione di un nuovo Global Datastore utilizzando un nuovo cluster primario](#Redis-Global-Datastores-Create-From-Scratch)
+ [Visualizzazione dei dettagli del Datastore globale](#Redis-Global-Datastores-Console-Details)
+ [Aggiunta di una regione a un Global Datastore](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Modifica di un Global Datastore](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
+ [Promozione del cluster secondario a primario](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Rimozione di una regione da un Global Datastore](#Redis-Global-Datastore-Console-Remove-Region)
+ [Eliminazione di un Global Datastore](#Redis-Global-Datastores-Console-Delete-GlobalDatastore)
## Creazione di un Global Datastore utilizzando un cluster esistente
In questo scenario, è possibile utilizzare un cluster esistente da utilizzare come cluster primario del nuovo Global Datastore. È quindi possibile creare un cluster secondario di sola lettura in una regione AWS separata. Questo cluster secondario riceve aggiornamenti automatici e asincroni dal cluster primario.
**Importante**
Il cluster esistente deve utilizzare un motore Valkey 7.2 o successivo o Redis OSS 5.0.6 o successivo.
**Per creare un Global Datastore utilizzando un cluster esistente**
1. Accedi a Console di gestione AWS e apri la console all'indirizzo. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nel riquadro di navigazione, scegli **Datastore globale**, quindi scegli **Crea datastore globale**.
1. Nella pagina delle **impostazioni del cluster primario**, procedi come segue:
+ Nel campo **Informazioni Global Datastore**, inserisci un nome per il nuovo datastore globale.
+ (Opzionale) Immettere un valore **Description (Descrizione)**.
1. In **Cluster regionale, seleziona **Usa** cluster regionale** esistente.
1. In **Cluster esistente**, seleziona il cluster esistente che desideri utilizzare.
1. Mantenere le seguenti opzioni invariate. Sono precompilate per corrispondere alla configurazione del cluster primario, non è possibile modificarle.
+ Versione del motore
+ Tipo di nodo
+ Gruppo di parametri
**Nota**
ElastiCache genera automaticamente un nuovo gruppo di parametri dai valori del gruppo di parametri fornito e applica il nuovo gruppo di parametri al cluster. Utilizzare questo nuovo gruppo di parametri per modificare i parametri in un Global Datastore. Ogni gruppo di parametri generati automaticamente è associato a un solo cluster e, pertanto, a un solo Global Datastore.
+ Numero dle partizioni
+ Crittografia dei dati inattivi - Consente la crittografia dei dati memorizzati su disco. Per ulteriori informazioni, consultare [Crittografia dei dati inattivi](at-rest-encryption.md).
**Nota**
È possibile fornire una chiave di crittografia diversa scegliendo la chiave ** AWS KMS gestita dal cliente e scegliendo la chiave**. Per ulteriori informazioni, consulta [Utilizzo delle chiavi AWS KMS gestite dal cliente](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ Crittografia dei dati in transito : Consente la crittografia dei dati in trasferimento. Per maggiori informazioni, consultare [Crittografia dei dati in transito](in-transit-encryption.md). **Per Valkey 7.2 e versioni successive e Redis OSS 6.0 in poi, se si abilita la crittografia in transito, viene richiesto di specificare una delle seguenti opzioni di controllo degli accessi:**
+ **Nessun controllo degli accessi** - Questa è l'impostazione di default. Questo non indica alcuna restrizione.
+ **Lista di controllo accessi gruppi di utenti**— Scegliere un gruppo di utenti con un set definito di utenti e autorizzazioni per le operazioni disponibili. Per ulteriori informazioni, consulta [Gestione dei gruppi di utenti con Console e CLI](Clusters.RBAC.md#User-Groups).
+ **AUTH Default User**: meccanismo di autenticazione per un server Valkey o Redis OSS. [Per ulteriori informazioni, consulta AUTH.](auth.md)
1. (Opzionale) In base alle necessità, aggiornare le restanti impostazioni del cluster secondario. Queste sono precompilate con gli stessi valori del cluster primario, ma è possibile aggiornarle per soddisfare requisiti specifici di tale cluster.
+ Porta
+ Numero di repliche
+ Subnet group (Gruppo di sottoreti)
+ Zone di disponibilità preferite
+ Gruppi di sicurezza
+ Gestito dal cliente (chiave AWS KMS)
+ Token DI AUTENTICAZIONE
+ Abilitazione backup automatici.
+ Backup retention period (Periodo di retention dei backup)
+ Finestra di backup
+ Maintenance window (Finestra di manutenzione)
+ Argomento per la notifica SNS
1. Scegli **Create** (Crea). In questo modo lo stato del Global Datastore viene impostato su **Creating (Creazione in corso)**. Lo stato passa a **Modifying (Modifica in corso)** dopo che il cluster primario viene associato al Global Datastore e il cluster secondario è in stato **Associating (Associazione in corso)**.
Dopo che il cluster primario e i cluster secondari sono stati associati al Global Datastore, lo stato cambia in **Available (Disponibile)**. A questo punto, si dispone di un cluster primario che accetta letture e scritture e cluster secondari che accettano letture replicate dal cluster primario.
La pagina viene aggiornata per indicare se un cluster fa parte di un datastore globale, tra cui:
+ **Global Datastore**— Il nome del Datastore globale a cui appartiene il cluster.
+ **Ruolo Global Datastore**— Il ruolo del cluster, primario o secondario.
È possibile aggiungere fino a un cluster secondario aggiuntivo in una regione diversa AWS . Per ulteriori informazioni, consulta [Aggiunta di una regione a un Global Datastore](#Redis-Global-Datastores-Console-Create-Secondary).
## Creazione di un nuovo Global Datastore utilizzando un nuovo cluster primario
Se si sceglie di creare un Datastore globale con un nuovo cluster, utilizzare la procedura seguente.
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel riquadro di navigazione, scegli **Datastore globale**, quindi scegli **Crea datastore globale**.
1. Sotto **Impostazioni cluster primario**, procedi come indicato di seguito:
1. Per **Modalità cluster** scegli **Abilitato** o **Disabilitato**.
1. **Per **informazioni su Global Datastore**, inserisci un valore per Nome.** ElastiCache utilizza il suffisso per generare un nome univoco per il datastore globale. È possibile cercare il Global Datastore utilizzando il suffisso specificato qui.
1. (Opzionale) Immettere un valore per **Global Datastore Description (Descrizione Global Datastore)**.
1. Sotto **Cluster regionale**:
1. Per **Regione**, scegli una regione disponibile. AWS
1. Scegli **Crea nuovo cluster regionale** o **Usa cluster regionale esistente**
1. Se scegli **Crea nuovo cluster regionale**, sotto **Informazioni sul cluster** inserisci un nome e una descrizione facoltativa del cluster.
1. Sotto **Posizione**, è preferibile accettare le impostazioni predefinite per **Multi-AZ** e **Failover automatico**.
1. Sotto **Impostazioni cluster**
1. Per **Versione motore** scegli una versione disponibile, cioè 5.0.6 o successiva.
1. Per **Porta** utilizza la porta predefinita, 6379. Se esiste un motivo per utilizzare una porta diversa, immettere il numero di porta.
1. Per **Parameter group (Gruppo di parametri)**, scegliere un gruppo di parametri o crearne uno nuovo. I gruppi di parametri controllano i parametri di runtime del cluster. Per ulteriori informazioni sui gruppi di parametri, consulta [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis) e [Creazione di un gruppo di ElastiCache parametri](ParameterGroups.Creating.md).
**Nota**
Quando si seleziona un gruppo di parametri per impostare i valori di configurazione del motore, tale gruppo di parametri viene applicato a tutti i cluster nel Global Datastore. Nella pagina **Parameter Groups (Gruppi di parametri)** con/senza l'attributo **Global (Globale)** indica se un gruppo di parametri fa parte di un Global Datastore.
1. In **Node type (Tipo di nodo)**, scegliere la freccia in giù (![\[Downward-pointing triangle icon, typically used to indicate a dropdown menu.\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-DnArrow.png)). Nella finestra di dialogo **Change node type (Cambia tipo di nodo)** scegliere un valore per **Instance family (Famiglia di istanze)** per il tipo di nodo desiderato. Scegliere quindi il tipo di nodo che si desidera utilizzare per il cluster, quindi scegliere **Save (Salva)**.
Per ulteriori informazioni, consulta [Scelta delle dimensioni dei nodi](CacheNodes.SelectSize.md).
Se scegli un tipo di nodo r6gd, il tiering dei dati viene abilitato automaticamente. Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
1. Se stai creando un cluster Valkey o Redis OSS (modalità cluster disabilitata):
In **Numero di repliche** scegli il numero di repliche per questo cluster.
1. Se stai creando un cluster Valkey o Redis OSS (modalità cluster abilitata):
1. Per **Numero di shard**, scegli il numero di shard (partizioni/gruppi di nodi) che desideri per questo cluster Valkey o Redis OSS (modalità cluster abilitata).
Per alcune versioni di Valkey o Redis OSS (modalità cluster abilitata), puoi modificare il numero di shard nel cluster in modo dinamico:
+ **Redis OSS 3.2.10 e versioni successive**: se sul cluster è in esecuzione Redis OSS 3.2.10 o versioni successive, è possibile modificare il numero di shard nel cluster in modo dinamico. Per ulteriori informazioni, consulta [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md).
+ **Altre versioni di Redis OSS**: se sul cluster è in esecuzione una versione di Redis OSS precedente alla versione 3.2.10, esiste un altro approccio. Per modificare il numero dle partizioni nel cluster in questo caso, creare un nuovo cluster con il nuovo numero dle partizioni. Per ulteriori informazioni, consulta [Ripristino da un backup in una nuova cache](backups-restoring.md).
1. In **Replicas per shard (Repliche per partizione)**: scegliere il numero di nodi di replica di lettura per ognle partizioni.
Esistono le seguenti restrizioni per Valkey o Redis OSS (modalità cluster abilitata).
+ Se hai abilitato la funzione Multi-AZ, assicurati di avere almeno una replica per ognle partizioni.
+ Quando utilizzi la console per creare il cluster, il numero delle repliche è lo stesso per ognle partizioni.
+ Il numero delle repliche di lettura per ognle partizioni è fisso e non modificabile. Se scopri che ti servono più o meno repliche per partizione (API/CLI: gruppo di nodi), devi creare un nuovo cluster con il nuovo numero di repliche. Per ulteriori informazioni, consulta [Tutorial: Seminare un nuovo cluster basato su nodi con un backup creato esternamente](backups-seeding-redis.md).
1. Per **le impostazioni del gruppo di sottoreti**, scegli la sottorete che desideri applicare a questo cluster. ElastiCache fornisce un gruppo di IPv4 sottoreti predefinito oppure puoi scegliere di crearne uno nuovo. Infatti IPv6, è necessario creare un gruppo di sottoreti con un blocco IPv6 CIDR. Se si sceglie il **dual stack**, è necessario selezionare un tipo di Discovery IP, oppure. IPv6 IPv4
Per ulteriori informazioni, consulta [Creazione di una sottorete nel VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet).
1. Per **Posizionamento zone disponibilità**, le opzioni sono due:
+ **Nessuna preferenza**: ElastiCache sceglie la zona di disponibilità.
+ **Specify Availability Zones (Specifica zone di disponibilità)** – L'utente specifica la zona di disponibilità per ogni cluster.
Se hai scelto di specificare le zone di disponibilità, per ogni cluster in ognle partizioni, seleziona la zona di disponibilità dall'elenco.
Per ulteriori informazioni, consulta [Scelta delle regioni e delle zone di disponibilità per ElastiCache](RegionsAndAZs.md).
![\[Immagine: specifica dei Keyspace e delle zone di disponibilità\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-ClusterOn-Slots-AZs.png)
*Specifica dei Keyspace e delle zone di disponibilità*
1. Scegli **Successivo**.
1. Nelle impostazioni **Advanced Valkey e Redis OSS**
1. Per **Sicurezza**:
1. Per crittografare i dati, le opzioni disponibili sono le seguenti:
+ **Crittografia dei dati inattivi** : Consente la crittografia dei dati memorizzati su disco. Per ulteriori informazioni, consultare [Crittografia dei dati inattivi](at-rest-encryption.md).
**Nota**
Hai la possibilità di fornire una chiave di crittografia diversa scegliendo la chiave ** AWS KMS gestita dal cliente e scegliendo la chiave**. Per ulteriori informazioni, vedere [Utilizzo di chiavi gestite dal cliente da AWS KMS](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ **Crittografia dei dati in transito** – Consente la crittografia dei dati in trasferimento. Per maggiori informazioni, consultare [Crittografia dei dati in transito](in-transit-encryption.md). **Per Valkey 7.2 e versioni successive e Redis OSS 6.0 e versioni successive, se abiliti Encryption in-transit ti verrà richiesto di specificare una delle seguenti opzioni di controllo degli accessi:**
+ **Nessun controllo degli accessi** - Questa è l'impostazione di default. Questo non indica alcuna restrizione sull'accesso dell’utente al cluster.
+ **Lista di controllo accessi** – scegliere un gruppo di utenti con un set definito di utenti che possono accedere al cluster. Per ulteriori informazioni, consulta [Gestione dei gruppi di utenti con Console e CLI](Clusters.RBAC.md#User-Groups).
+ **AUTH Default User**: meccanismo di autenticazione per un server Valkey o Redis OSS. [Per ulteriori informazioni, consulta AUTH.](auth.md)
+ **AUTH**: meccanismo di autenticazione per un server Valkey o Redis OSS. [Per ulteriori informazioni, consulta AUTH.](auth.md)
**Nota**
Per le versioni Redis OSS comprese tra 3.2.6 e successive, esclusa la versione 3.2.10, AUTH è l'unica opzione.
1. In **Security groups (Gruppi di sicurezza)**, scegliere i gruppi di sicurezza per il cluster. Un *gruppo di sicurezza* si comporta come un firewall, controllando l'accesso di rete al cluster. È possibile utilizzare il gruppo di sicurezza di default per il VPC o crearne uno nuovo.
Per ulteriori informazioni sui gruppi di sicurezza, consulta [Gruppi di sicurezza per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella *Guida per l'utente di Amazon VPC*.
1. Se si desiderano backup regolari pianificati regolarmente, scegliere **Enable automatic backups (Abilita backup automatici)**, quindi digitare il numero di giorni in cui conservare ciascun backup automatico prima che venga automaticamente eliminato. Se non si desiderano backup automatici pianificati regolarmente, deselezionare la casella di controllo **Enable automatic backups (Abilita backup automatici)**. In ogni caso, hai sempre la possibilità di creare backup manuali.
Per ulteriori informazioni sul backup e il ripristino, vedere. [Snapshot e ripristino](backups.md)
1. (Facoltativo) Specifica una finestra di manutenzione. La *Maintenance window (Finestra di manutenzione)* è l'intervallo di tempo, generalmente un'ora a settimana, in cui ElastiCache pianifica la manutenzione di sistema per il cluster. Puoi ElastiCache scegliere il giorno e l'ora della finestra di manutenzione (*nessuna preferenza*) oppure puoi scegliere tu stesso il giorno, l'ora e la durata (*Specificare la finestra di manutenzione*). Se dagli elenchi si sceglie *Specify maintenance window (Specifica finestra di manutenzione)*, selezionare *Start day (Giorno di inizio)*, *Start time (Ora di inizio)* e *Duration (Durata)* (in ore) per la finestra di manutenzione. Tutti gli orari si intendono in formato UCT.
Per ulteriori informazioni, consulta [Gestione della manutenzione dei ElastiCache cluster](maintenance-window.md).
1. (Facoltativo) Per**Registro**:
+ In **Formato del registro**, scegliere **Text** o **JSON**.
+ In **Tipo di destinazione**, scegli **CloudWatch Logs** o **Kinesis Firehose**.
+ In **Destinazione log**, scegliete **Crea nuovo** e inserite il nome del gruppo di log CloudWatch Logs o il nome dello stream Firehose, oppure **scegliete Seleziona esistente e quindi scegliete** il nome del gruppo di log Logs o CloudWatch il nome dello stream Firehose,
1. Per quanto riguarda i **tag**, per aiutarti a gestire i tuoi cluster e altre ElastiCache risorse, puoi assegnare i tuoi metadati a ciascuna risorsa sotto forma di tag. Per ulteriori informazioni, consulta [Taggare le tue risorse ElastiCache](Tagging-Resources.md).
1. Riesaminare le voci e le selezioni, quindi apportare le eventuali correzioni. Al termine, scegli **Next (Successivo)**.
1. Dopo aver configurato il cluster nei passaggi precedenti, ora puoi configurare i dettagli dei cluster secondari.
1. In **Cluster regionale**, scegli la AWS regione in cui si trova il cluster.
1. Sotto **Informazioni sul cluster** inserisci un nome e una descrizione facoltativa del cluster.
1. Le opzioni seguenti sono precompilate in modo che corrispondano alla configurazione del cluster primario e non possono essere modificate:
+ Ubicazione
+ Versione del motore
+ Tipo di istanza
+ Tipo di nodo
+ Numero dle partizioni
+ Gruppo di parametri
**Nota**
ElastiCache genera automaticamente un nuovo gruppo di parametri dai valori del gruppo di parametri fornito e applica il nuovo gruppo di parametri al cluster. Utilizzare questo nuovo gruppo di parametri per modificare i parametri in un Global Datastore. Ogni gruppo di parametri generati automaticamente è associato a un solo cluster e, pertanto, a un solo Global Datastore.
+ Crittografia dei dati inattivi : Consente la crittografia dei dati memorizzati su disco. Per ulteriori informazioni, consultare [Crittografia dei dati inattivi](at-rest-encryption.md).
**Nota**
È possibile fornire una chiave di crittografia diversa scegliendo la chiave ** AWS KMS gestita dal cliente e scegliendo la chiave**. Per ulteriori informazioni, consulta [Utilizzo delle chiavi AWS KMS gestite dal cliente](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ Crittografia dei dati in transito : Consente la crittografia dei dati in trasferimento. Per maggiori informazioni, consultare [Crittografia dei dati in transito](in-transit-encryption.md). **Per Valkey 7.2 e versioni successive e Redis OSS 6.4 e versioni successive, se si abilita la crittografia in transito, viene richiesto di specificare una delle seguenti opzioni di controllo degli accessi:**
+ **Nessun controllo degli accessi** - Questa è l'impostazione di default. Questo non indica alcuna restrizione sull'accesso dell’utente al cluster.
+ **Lista di controllo accessi** - Scegliere un gruppo di utenti con un set definito di utenti che possono accedere al cluster. Per ulteriori informazioni, consulta [Gestione dei gruppi di utenti con Console e CLI](Clusters.RBAC.md#User-Groups).
+ **AUTH Default User**: meccanismo di autenticazione per un server Valkey o Redis OSS. [Per ulteriori informazioni, consulta AUTH.](auth.md)
**Nota**
Per le versioni Redis OSS comprese tra la 4.0.2, quando Encryption in-transit è stata supportata per la prima volta, e la 6.0.4, AUTH è l'unica opzione.
Le restanti impostazioni del cluster secondario vengono precompilate con gli stessi valori del cluster primario, ma è possibile aggiornare quanto segue per soddisfare requisiti specifici per tale cluster:
+ Porta
+ Numero di repliche
+ Subnet group (Gruppo di sottoreti)
+ Zone di disponibilità preferite
+ Gruppi di sicurezza
+ Gestito dal cliente (chiave KMS)AWS
+ Token DI AUTENTICAZIONE
+ Abilitazione backup automatici.
+ Backup retention period (Periodo di retention dei backup)
+ Finestra di backup
+ Maintenance window (Finestra di manutenzione)
+ Argomento per la notifica SNS
1. Scegli **Create** (Crea). Ciò imposta lo stato del Global Datastore su **Creating (Creazione in corso)**. Dopo che il cluster primario e i cluster secondari sono stati associati al Global Datastore, lo stato cambia in **Available (Disponibile)**. Si dispone di un cluster primario che accetta letture e scritture e di un cluster secondario che accetta letture replicate dal cluster primario.
La pagina viene inoltre aggiornata per indicare se un cluster fa parte di un datastore globale, tra cui:
+ **Global Datastore**— Il nome del Datastore globale a cui appartiene il cluster.
+ **Ruolo Global Datastore**— Il ruolo del cluster, primario o secondario.
È possibile aggiungere fino a un cluster secondario aggiuntivo in una regione diversa AWS . Per ulteriori informazioni, consulta [Aggiunta di una regione a un Global Datastore](#Redis-Global-Datastores-Console-Create-Secondary).
## Visualizzazione dei dettagli del Datastore globale
È possibile visualizzare i dettagli dei datastore globali esistenti e modificarli anche nella pagina **Global Datastores**.
**Per visualizzare i dettagli del Global Datastore**
1. Accedi a Console di gestione AWS e apri la console all'indirizzo. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nel riquadro di navigazione, scegli **Datastore globali**, quindi scegli un datastore globale disponibile.
È quindi possibile esaminare le seguenti proprietà del Global Datastore:
+ **Global Datastore Name (Nome Global Datastore:** il nome del Global Datastore
+ **Description (Descrizione):** una descrizione del Global Datastore
+ **Status (Stato):** le opzioni includono:
+ Creazione
+ Modifying (Modifica in corso)
+ Disponibilità
+ Eliminazione in corso
+ Primary-Only (Solo primario): questo stato indica che il Global Datastore contiene solo un cluster primario. Tutti i cluster secondari vengono eliminati o creati non correttamente.
+ **Cluster Mode (Modalità cluster):** abilitata o disabilitata
+ **Versione del motore: la versione** del motore Valkey o Redis OSS che esegue il datastore globale
+ **Instance Node Type (Tipo di nodo di istanza):** il tipo di nodo utilizzato per il Global Datastore
+ **Encryption at-rest (Crittografia dei dati inattivi):** abilitata o disabilitata
+ **Encryption in-transit (Crittografia dei dati in transito):** abilitata o disabilitata
+ **AUTH: abilitata o disabilitata**
È possibile apportare le seguenti modifiche al Global Datastore:
+ [Aggiunta di una regione a un Global Datastore](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Rimozione di una regione da un Global Datastore](#Redis-Global-Datastore-Console-Remove-Region)
+ [Promozione del cluster secondario a primario](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Modifica di un Global Datastore](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
La pagina Global Datastore elenca anche i singoli cluster che formano il Global Datastore e le seguenti proprietà per ciascuno:
+ **Regione**: la AWS regione in cui è archiviato il cluster
+ **Role (Ruolo)**: primario o secondario
+ **Cluster Name (Nome cluster)**: il nome del cluster
+ **Status (Stato)**: le opzioni includono:
+ **Associating (Associazione in corso)**: il cluster è in procinto di essere associato al Global Datastore
+ **Associated (Associato)**: il cluster è stato associato al Global Datastore
+ **Disassociating (Annullamento associazione)**: il processo di rimozione di un cluster secondario dal Global Datastore utilizzando il nome del Global Datastore. Dopodiché, il cluster secondario non riceve più aggiornamenti dal cluster primario ma rimane un cluster autonomo in quella AWS regione.
+ **Disassociated (Disassociato)**: il cluster secondario è stato rimosso dal Global Datastore ed è ora un cluster autonomo nella propria regione AWS .
+ **Global Datastore Replica lag**: mostra un valore per AWS regione secondaria nel datastore globale. Questo è il ritardo tra il nodo primario della regione secondaria e il nodo primario della regione primaria. Per Valkey o Redis OSS abilitati alla modalità cluster, il ritardo indica il ritardo massimo in secondi tra gli shard.
## Aggiunta di una regione a un Global Datastore
È possibile aggiungere fino a una AWS regione aggiuntiva a un datastore globale esistente. In questo scenario, si sta creando un cluster di sola lettura in una AWS regione separata che riceve aggiornamenti automatici e asincroni dal cluster primario.
**Per aggiungere una regione a un AWS datastore globale**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nel riquadro di navigazione, scegli **Datastore globali**, quindi seleziona un datastore globale esistente.
1. Scegli **Aggiungi cluster regionale** e scegli la AWS regione in cui deve risiedere il cluster secondario.
1. In **Informazioni sul cluster**, inserisci un valore per **Nome** e, facoltativamente, per **Descrizione** per il cluster.
1. Mantenere le seguenti opzioni invariate. Sono precompilate per corrispondere alla configurazione del cluster primario, non è possibile modificarle.
+ Versione del motore
+ Tipo di istanza
+ Tipo di nodo
+ Numero dle partizioni
+ Gruppo di parametri
**Nota**
ElastiCache genera automaticamente un nuovo gruppo di parametri dai valori del gruppo di parametri fornito e applica il nuovo gruppo di parametri al cluster. Utilizzare questo nuovo gruppo di parametri per modificare i parametri in un Global Datastore. Ogni gruppo di parametri generati automaticamente è associato a un solo cluster e, pertanto, a un solo Global Datastore.
+ Crittografia a riposo
**Nota**
È possibile fornire una chiave di crittografia diversa scegliendo la chiave ** AWS KMS gestita dal cliente e scegliendo la chiave**.
+ Crittografia in transito
+ AUTENTICAZIONE
1. (Opzionale) Aggiornare le restanti impostazioni del cluster secondario. Queste sono precompilate con gli stessi valori del cluster primario, ma è possibile aggiornarle per soddisfare requisiti specifici di tale cluster:
+ Porta
+ Numero di repliche
+ Subnet group (Gruppo di sottoreti)
+ Zone di disponibilità preferite
+ Gruppi di sicurezza
+ (chiave AWS KMS gestita dal cliente)
+ Token di autenticazione
+ Abilitazione backup automatici.
+ Backup retention period (Periodo di retention dei backup)
+ Finestra di backup
+ Maintenance window (Finestra di manutenzione)
+ Argomento per la notifica SNS
1. Scegliere **Aggiungi**.
## Modifica di un Global Datastore
È possibile modificare le proprietà dei cluster regionali. Su un Global Datastore può essere in corso una sola operazione di modifica, ad eccezione della promozione di un cluster secondario a primario. Per ulteriori informazioni, consulta [Promozione del cluster secondario a primario](#Redis-Global-Datastores-Console-Promote-Secondary).
**Per modificare un Global Datastore**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel riquadro di navigazione, scegli **Global Datastores**, quindi per **Global Datastore Name, scegli un datastore** globale.
1. Scegliere **Modifica** e scegliere tra le seguenti opzioni:
+ **Descrizione:** una descrizione del Global Datastore
+ **Modifica la versione del motore**: sono disponibili solo Valkey 7.2 e versioni successive o Redis OSS 5.0.6 e versioni successive.
+ **Modifica tipo di nodo**: Dimensionamento dei cluster regionali sia verticalmente (dimensionamento verso l'alto e verso il basso) che orizzontalmente (dimensionamento orizzontale). Le opzioni includono le famiglie di nodi R5 e M5. Per ulteriori informazioni sui tipi di nodi, consulta [Tipi di nodi supportati](CacheNodes.SupportedTypes.md).
+ **Modifica del failover automatico**— Abilita o disabilita il failover automatico. Quando si abilita il failover e i nodi primari nei cluster regionali si chiudono in modo imprevisto, ElastiCache viene eseguito il failover su una delle repliche regionali. Per maggiori informazioni consulta [Failover automatico](AutoFailover.md).
Per i cluster Valkey o Redis OSS con modalità cluster abilitata:
+ **Aggiungle partizioni**: Immetti il numero dle partizioni da aggiungere e, facoltativamente, specifica una o più zone di disponibilità.
+ **Elimina frammenti: scegli i frammenti** da eliminare in ogni regione. AWS
+ **Ribilanciamento dle partizioni** Ribilancia la distribuzione degli slot per garantire una distribuzione uniforme tra le partizioni esistenti nel cluster.
Per modificare i parametri di un datastore globale, modifica il gruppo di parametri di qualsiasi cluster membro del datastore globale. ElastiCache applica automaticamente questa modifica a tutti i cluster all'interno di quel datastore globale. Per modificare il gruppo di parametri di quel cluster, utilizza la console Valkey o Redis OSS o l'operazione API. [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) Per ulteriori informazioni, consulta [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md). Quando si modifica il gruppo di parametri di qualsiasi cluster contenuto in un Global Datastore, ciò si applica a tutti i cluster all'interno del Global Datastore.
Per reimpostare un intero gruppo di parametri o parametri specifici, utilizzate l'operazione [ResetCacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ResetCacheParameterGroup.html)API.
## Promozione del cluster secondario a primario
Se il cluster o la AWS regione primari non sono disponibili o presentano problemi di prestazioni, è possibile promuovere un cluster secondario a primario. La promozione è consentita in qualsiasi momento, anche se sono in corso altre modifiche. È inoltre possibile effettuare più promozioni in parallelo e al termine il Global Datastore si risolve in un cluster primario. Se promuovi più cluster secondari contemporaneamente, ElastiCache non garantisce che alla fine quale di essi diventi primario.
**Per promuovere un cluster secondario a primario**
1. Accedi a Console di gestione AWS e apri la console all' ElastiCache indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nel riquadro di navigazione, scegli **Global Datastores**.
1. Scegliere il nome del Global Datastore per visualizzarne i dettagli
1. Scegliere il cluster **Secondario**
1. Scegliere **Promuovi a primario**.
Viene quindi richiesto di confermare la decisione con il seguente avviso: ` 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. Scegliere **Conferma** se si desidera continuare con la promozione o **Cancel (Annulla)** in caso contrario.
Se si sceglie di confermare, il Global Datastore passa a uno stato **Modifying (Modifica in corso)** e non sarà disponibile fino al completamento della promozione.
## Rimozione di una regione da un Global Datastore
È possibile rimuovere una AWS regione da un datastore globale utilizzando la procedura seguente.
**Per rimuovere una AWS regione da un datastore globale**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nel riquadro di navigazione, scegli **Global Datastores**.
1. Scegliere un datastore globale
1. Scegliere **Region (Regione)** per scegliere la regione che si desidera rimuovere.
1. Scegliere **Remove region (Rimuovi regione)**.
**Nota**
Questa opzione è disponibile solo per i cluster secondari.
Verrà quindi chiesto di confermare la decisione con il seguente avviso: ` 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. Scegliere **Conferma** se si desidera continuare con la promozione o **Cancel (Annulla)** in caso contrario.
Se scegli conferma, la AWS regione viene rimossa e il cluster secondario non riceve più gli aggiornamenti di replica.
## Eliminazione di un Global Datastore
Per eliminare un Global Datastore, rimuovere innanzitutto tutti i cluster secondari. Per ulteriori informazioni, consulta [Rimozione di una regione da un Global Datastore](#Redis-Global-Datastore-Console-Remove-Region). In questo modo il Global Datastore globale è in stato **primary-only (solo primario)**.
**Per eliminare un Global Datastore**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel riquadro di navigazione, scegli **Global Datastores**.
1. In **Global Datastore Name (Nome Global Datastore)** scegliere il Global Datastore che si desidera eliminare e quindi scegliere **Delete (Elimina)**.
Verrà quindi chiesto di confermare la decisione con il seguente avviso: `Are you sure you want to delete this Global Datastore?`
1. Scegliere **Delete** (Elimina).
Il Global Datastore passa allo stato **Deleting (Eliminazione in corso)**.
# Utilizzo di Global Datastore (CLI)
Puoi usare il AWS Command Line Interface (AWS CLI) per controllare più AWS servizi dalla riga di comando e automatizzarli tramite script. È possibile utilizzare la AWS CLI per operazioni ad hoc (una tantum).
## Scaricamento e configurazione di AWS CLI
AWS CLI Funziona su Windows, macOS o Linux. Utilizzare la procedura seguente per scaricarla e configurarla.
**Per scaricare, installare e configurare la CLI**
1. Scarica la AWS CLI dalla pagina web dell'[interfaccia a riga di AWS comando](https://aws.amazon.com/cli).
1. *Segui le istruzioni per l'installazione della AWS CLI e la configurazione della AWS CLI nella Guida per l'utente.AWS Command Line Interface *
## Utilizzo della AWS CLI con datastore globali
Utilizzare le seguenti operazioni della CLI per utilizzare i Global Datastore:
+ [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 applica ElastiCache automaticamente un prefisso all'ID globale del datastore al momento della creazione. Ogni AWS regione ha il proprio prefisso. Ad esempio, un ID datastore globale creato nella regione Stati Uniti occidentali (California settentrionale) inizia con "virxk" assieme al nome del suffisso fornito. Il suffisso, combinato al prefisso autogenerato, garantisce l'unicità del nome del datastore globale in più Regioni.
La tabella seguente elenca ogni AWS regione e il relativo prefisso ID globale del datastore.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/Redis-Global-Datastores-CLI.html)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)— Utilizzate questa operazione per creare cluster secondari per un datastore globale fornendo il nome del datastore globale al parametro. `--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
```
Quando si chiama questa operazione e si passa un `--global-replication-group-id` valore, ElastiCache dedurrà i valori dal gruppo di replica primario del gruppo di replica globale per i seguenti parametri. Non passare valori per questi parametri:
`"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
```
**Aggiornamento multimotore da Redis a OSS Valkey per ElastiCache GlobalDataStore**
È possibile aggiornare un gruppo di replica globale Redis OSS esistente a Valkey utilizzando la console, l'API o la CLI.
Se disponi di un gruppo di replica globale Redis OSS esistente, puoi eseguire l'aggiornamento a Valkey specificando il nuovo motore e la nuova versione del motore con API. modify-global-replication-group
Per Linux, macOS o Unix:
```
aws elasticache modify-global-replication-group \
--global-replication-group-id myGlobalReplGroup \
--engine valkey \
--apply-immediately \
--engine-version 8.0
```
Per Windows:
```
aws elasticache modify-global-replication-group ^
--global-replication-group-id myGlobalReplGroup ^
--engine valkey ^
--apply-immediately ^
--engine-version 8.0
```
Se hai un gruppo di parametri di cache personalizzato applicato al gruppo di replica globale Redis OSS esistente che desideri aggiornare, dovrai passare anche un gruppo di parametri di cache Valkey personalizzato nella richiesta. Il gruppo di parametri personalizzati Valkey di input deve avere gli stessi valori dei parametri statici Redis OSS del gruppo di parametri personalizzati Redis OSS esistente.
Per Linux, macOS o 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
```
Per 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-gruppo di replica](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
```
Usa help per elencare tutti i comandi disponibili ElastiCache per Valkey o Redis OSS.
```
aws elasticache help
```
È anche possibile utilizzare la guida per la descrizione di un comando specifico e per ulteriori informazioni relative al suo utilizzo:
```
aws elasticache create-global-replication-group help
```
# Alta disponibilità utilizzando gruppi di replica
I cluster Amazon ElastiCache Valkey e Redis OSS a nodo singolo sono entità in memoria con servizi di protezione dei dati (AOF) limitati. Se il cluster non viene eseguito per qualsiasi motivo, tutti i dati del cluster vengono persi. Tuttavia, se utilizzi un motore Valkey o Redis OSS, puoi raggruppare da 2 a 6 nodi in un cluster con repliche in cui da 1 a 5 nodi di sola lettura contengono dati replicati del singolo nodo primario del gruppo. read/write In questo scenario, se un nodo non viene eseguito per qualsiasi motivo, non tutti i dati vengono persi poiché vengono replicati in uno o più nodi. A causa della latenza di replica, alcuni dati potrebbero andare persi se è il nodo primario a fallire. read/write
Come illustrato nell'immagine seguente, la struttura di replica è contenuta all'interno di uno shard (chiamato *gruppo di nodi* nell'API/CLI) contenuto all'interno di un cluster Valkey o Redis OSS. I cluster Valkey o Redis OSS (modalità cluster disabilitata) hanno sempre uno shard. I cluster Valkey o Redis OSS (modalità cluster abilitata) possono avere fino a 500 shard con i dati del cluster partizionati tra gli shard. Puoi creare un cluster con un numero più alto dle partizioni e un numero più basso di repliche per un totale di 90 nodi per cluster. Questa configurazione del cluster può andare da 90 partizioni e 0 repliche a 15 partizioni e 5 repliche che è il numero massimo consentito di repliche.
Il limite di nodi o shard può essere aumentato fino a un massimo di 500 per cluster con Valkey e con la versione 5.0.6 o ElastiCache successiva per Redis OSS. ElastiCache Ad esempio, è possibile scegliere di configurare un cluster a 500 nodi che varia tra 83 partizioni (un primario e 5 repliche per partizione) e 500 partizioni (un singolo primario e nessuna replica). Assicurati che esistano abbastanza indirizzi IP disponibili per soddisfare l'aumento. Le problematiche comuni sono che le le sottoreti nel gruppo di sottoreti hanno un intervallo CIDR troppo piccolo o che le sottoreti sono condivise e utilizzate pesantemente da altri cluster. Per ulteriori informazioni, consulta [Creazione di un gruppo di sottoreti](SubnetGroups.Creating.md).
Per le versioni inferiori alla 5.0.6, il limite è 250 per cluster.
Per richiedere un aumento dei limiti, consulta [Limiti dei servizi AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e seleziona il tipo di limite **Nodi per cluster per tipo di istanza**.
![\[Immagine: il cluster Valkey o Redis OSS (modalità cluster disabilitata) ha uno shard e da 0 a 5 nodi di replica\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Il cluster Valkey o Redis OSS (modalità cluster disabilitata) ha uno shard e da 0 a 5 nodi di replica*
Se nel cluster con repliche è abilitata la funzione Multi-AZ e il nodo primario non viene eseguito, il nodo primario esegue il failover in una replica di lettura. Poiché i dati sui nodi di replica vengono aggiornati in maniera asincrona, è possibile che alcuni dati vengano persi a causa della latenza di aggiornamento dei nodi di replica. Per ulteriori informazioni, consulta [Mitigazione degli errori durante l'esecuzione di Valkey o Redis OSS](disaster-recovery-resiliency.md#FaultTolerance.Redis).
**Topics**
+ [Comprendere la replica di Valkey e Redis OSS](Replication.Redis.Groups.md)
+ [Replica: modalità cluster Valkey e Redis OSS disabilitata o abilitata](Replication.Redis-RedisCluster.md)
+ [Riduzione al minimo dei tempi di inattività ElastiCache utilizzando Multi-AZ con Valkey e Redis OSS](AutoFailover.md)
+ [Modalità di implementazione di sincronizzazione e backup](Replication.Redis.Versions.md)
+ [Creazione di un gruppo di replica Valkey o Redis OSS](Replication.CreatingRepGroup.md)
+ [Visualizzazione dei dettagli del gruppo di replica](Replication.ViewDetails.md)
+ [Individuazione di endpoint del gruppo di replica](Replication.Endpoints.md)
+ [Modifica di un gruppo di replica](Replication.Modify.md)
+ [Eliminazione di un gruppo di replica](Replication.DeletingRepGroup.md)
+ [Modifica del numero di repliche](increase-decrease-replica-count.md)
+ [Promozione di una replica di lettura a quella primaria, per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata)](Replication.PromoteReplica.md)
# Comprendere la replica di Valkey e Redis OSS
Redis OSS implementa la replica in due modi:
+ Con un singolo shard che contiene tutti i dati del cluster in ogni nodo: Valkey o Redis OSS (modalità cluster disabilitata)
+ Con dati partizionati su un massimo di 500 shard: Valkey o Redis OSS (modalità cluster abilitata)
Ogni shard in un gruppo di replica ha un singolo nodo read/write primario e fino a 5 nodi di replica di sola lettura. Puoi creare un cluster con un numero più alto dle partizioni e un numero più basso di repliche per un totale di 90 nodi per cluster. Questa configurazione del cluster può andare da 90 partizioni e 0 repliche a 15 partizioni e 5 repliche che è il numero massimo consentito di repliche.
Il limite di nodi o shard può essere aumentato fino a un massimo di 500 per cluster se la versione del motore Redis OSS è 5.0.6 o successiva. Ad esempio, è possibile scegliere di configurare un cluster a 500 nodi che varia tra 83 partizioni (un primario e 5 repliche per partizione) e 500 partizioni (un singolo primario e nessuna replica). Assicurati che esistano abbastanza indirizzi IP disponibili per soddisfare l'aumento. Le problematiche comuni sono che le le sottoreti nel gruppo di sottoreti hanno un intervallo CIDR troppo piccolo o che le sottoreti sono condivise e utilizzate pesantemente da altri cluster. Per ulteriori informazioni, consulta [Creazione di un gruppo di sottoreti](SubnetGroups.Creating.md).
Per le versioni inferiori alla 5.0.6, il limite è 250 per cluster.
Per richiedere un aumento dei limiti, consulta [Limiti dei servizi AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e seleziona il tipo di limite **Nodi per cluster per tipo di istanza**.
**Topics**
+ [Valkey o Redis OSS (modalità cluster disabilitata)](#Replication.Redis.Groups.Classic)
+ [Valkey o Redis OSS (modalità cluster abilitata)](#Replication.Redis.Groups.Cluster)
## Valkey o Redis OSS (modalità cluster disabilitata)
Un cluster Valkey o Redis OSS (modalità cluster disabilitata) ha un singolo shard, all'interno del quale è presente una raccolta di nodi, un read/write nodo primario e fino a cinque nodi di replica secondari di sola lettura. Ogni replica di lettura conserva una copia dei dati del nodo primario del cluster. Meccanismi di replica asincrona vengono utilizzati per mantenere le repliche di lettura sincronizzate con il nodo primario. Le applicazioni possono leggere da qualsiasi nodo nel cluster. Le applicazioni possono scrivere solo nel nodo primario. Le repliche di lettura migliorano il throughput di lettura e proteggono dalla perdita di dati nei casi di mancata esecuzione del nodo.
![\[Immagine: cluster Valkey o Redis OSS (modalità cluster disabilitata) con un singolo shard e nodi di replica\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Cluster Valkey o Redis OSS (modalità cluster disabilitata) con un singolo shard e nodi di replica*
È possibile utilizzare i cluster Valkey o Redis OSS (modalità cluster disabilitata) con nodi di replica per scalare la soluzione in modo da gestire applicazioni che richiedono un uso intensivo di lettura o ElastiCache per supportare un gran numero di client che leggono contemporaneamente dallo stesso cluster.
Tutti i nodi di un cluster Valkey o Redis OSS (modalità cluster disabilitata) devono risiedere nella stessa regione.
Quando aggiungi una replica di lettura a un cluster, tutti i dati del nodo primario vengono copiati nel nuovo nodo. Da quel punto in poi, ogni volta che vengono scritti dati nel nodo primario, le modifiche vengono propagate in modo asincrono a tutte le repliche di lettura.
Per migliorare la tolleranza agli errori e ridurre i tempi di inattività in scrittura, abilita Multi-AZ con failover automatico per il cluster Valkey o Redis OSS (modalità cluster disabilitata) con repliche. Per ulteriori informazioni, consulta [Riduzione al minimo dei tempi di inattività ElastiCache utilizzando Multi-AZ con Valkey e Redis OSS](AutoFailover.md).
È possibile modificare i ruoli dei nodi all'interno del cluster Valkey o Redis OSS (modalità cluster disabilitata), scambiando i ruoli della replica principale e di quella delle repliche. Ciò può essere fatto per motivi di tuning delle prestazioni. Ad esempio, in un'applicazione Web con attività di scrittura elevata, puoi scegliere il nodo che presenta la latenza di rete più bassa. Per ulteriori informazioni, consulta [Promozione di una replica di lettura a quella primaria, per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata)](Replication.PromoteReplica.md).
## Valkey o Redis OSS (modalità cluster abilitata)
Un cluster Valkey o Redis OSS (modalità cluster abilitata) è composto da 1 a 500 shard (API/CLI: gruppi di nodi). Ogni partizione dispone di un nodo primario e un massimo di cinque nodi di replica di sola lettura. La configurazione può variare da 90 partizioni e 0 repliche a 15 partizioni e 5 repliche che è il numero massimo consentito di repliche.
Il limite di nodi o shard può essere aumentato fino a un massimo di 500 per cluster se la versione del motore è Valkey 7.2 e successiva o Redis OSS 5.0.6 e successiva. Ad esempio, è possibile scegliere di configurare un cluster a 500 nodi che varia tra 83 partizioni (un primario e 5 repliche per partizione) e 500 partizioni (un singolo primario e nessuna replica). Assicurati che esistano abbastanza indirizzi IP disponibili per soddisfare l'aumento. Le problematiche comuni sono che le le sottoreti nel gruppo di sottoreti hanno un intervallo CIDR troppo piccolo o che le sottoreti sono condivise e utilizzate pesantemente da altri cluster. Per ulteriori informazioni, consulta [Creazione di un gruppo di sottoreti](SubnetGroups.Creating.md).
Per le versioni inferiori alla 5.0.6, il limite è 250 per cluster.
Per richiedere un aumento dei limiti, consulta [AWS Limiti del servizio](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e scegliere il tipo di limite **Nodi per cluster per tipo di istanza**.
Ogni replica di lettura in uno shard conserva una copia dei dati del nodo primario dello shard. Meccanismi di replica asincrona vengono utilizzati per mantenere le repliche di lettura sincronizzate con il nodo primario. Le applicazioni possono leggere da qualsiasi nodo nel cluster. Le applicazioni possono scrivere solo nei nodi primari. Le repliche di lettura migliorano la scalabilità in lettura e proteggono dalla perdita di dati. I dati vengono partizionati tra gli shard in un cluster Valkey o Redis OSS (modalità cluster abilitata).
Le applicazioni utilizzano l'*endpoint di configurazione* del cluster Valkey o Redis OSS (modalità cluster abilitata) per connettersi con i nodi del cluster. Per ulteriori informazioni, consulta [Ricerca degli endpoint di connessione in ElastiCache](Endpoints.md).
![\[Immagine: cluster Valkey o Redis OSS (modalità cluster abilitata) con più shard e nodi di replica\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-RedisClusters.png)
*Cluster Valkey o Redis OSS (modalità cluster abilitata) con più shard e nodi di replica*
Tutti i nodi di un cluster Valkey o Redis OSS (modalità cluster abilitata) devono risiedere nella stessa regione. Per migliorare la tolleranza ai guasti, puoi eseguire il provisioning dei nodi primari e delle repliche di lettura in più zone di disponibilità all'interno di tale regione.
Attualmente, le funzionalità di Valkey o Redis OSS (modalità cluster abilitata) presentano alcune limitazioni.
+ Non puoi promuovere manualmente nodi di replica al nodo primario.
# Replica: modalità cluster Valkey e Redis OSS disabilitata o abilitata
A partire da Valkey 7.2 e Redis OSS versione 3.2, è possibile creare uno dei due tipi distinti di cluster (API/CLI: replication groups). A Valkey or Redis OSS (cluster mode disabled) cluster always has a single shard (API/CLI: gruppo di nodi) con un massimo di 5 nodi di replica in lettura. Un cluster Valkey o Redis OSS (modalità cluster abilitata) ha fino a 500 shard con da 1 a 5 nodi di replica di lettura ciascuno.
![\[Immagine: cluster Valkey o Redis OSS (modalità cluster disabilitata) e cluster Valkey o Redis OSS (modalità cluster abilitata)\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-NodeGroups.png)
*Cluster Valkey o Redis OSS (modalità cluster disabilitata) e Valkey o Redis OSS (modalità cluster abilitata)*
La tabella seguente riassume le differenze importanti tra i cluster Valkey o Redis OSS (modalità cluster disabilitata) e i cluster Valkey o Redis OSS (modalità cluster abilitata).
**Confronto tra i cluster Valkey o Redis OSS (modalità cluster disabilitata) e Valkey o Redis OSS (modalità cluster abilitata)**
| Funzionalità | Valkey o Redis OSS (modalità cluster disabilitata) | Valkey o Redis OSS (modalità cluster abilitata) |
| --- | --- | --- |
| Modificabile | Sì. Supporta l'aggiunta e l'eliminazione di nodi di replica e il dimensionamento orizzontale del tipo di nodo. | Limitato. Per ulteriori informazioni, consultare [Gestione delle versioni per ElastiCache](VersionManagement.md) e [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md). |
| Partizionamento dei dati | No | Sì |
| Shard | 1 | Da 1 a 500 |
| Repliche di lettura | Da 0 a 5 Se non esistono repliche e il nodo non viene eseguito, tutti i dati vengono persi. | Da 0 a 5 per partizione. Se non esistono repliche e il nodo non viene eseguito, tutti i dati in tale shard vengono persi. |
| Multi-AZ | Sì, con almeno 1 replica. Facoltativo. Attivata per impostazione predefinita. | SìFacoltativo. Attivata per impostazione predefinita. |
| Snapshot (Backup) | Sì, creando un singolo file .rdb. | Sì, creando un file .rdb univoco per ogni shard. |
| Ripristino | Sì, utilizzando un singolo file.rdb da un cluster Valkey o Redis OSS (modalità cluster disabilitata). | Sì, utilizzando file.rdb da un cluster Valkey o Redis OSS (modalità cluster disabilitata) o da un cluster Valkey o Redis OSS (modalità cluster abilitata). |
| Supportato da | Tutte le versioni di Valkey e Redis OSS | Tutte le versioni di Valkey e Redis OSS 3.2 e successive |
| Motore aggiornabile | Sì, con alcuni limiti. Per ulteriori informazioni, consulta [Gestione delle versioni per ElastiCache](VersionManagement.md). | Sì, con alcuni limiti. Per ulteriori informazioni, consulta [Gestione delle versioni per ElastiCache](VersionManagement.md). |
| Crittografia | Versioni 3.2.6 (pianificata per EOL, consulta la [pianificazione di fine del ciclo di vita delle versioni Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e successive. | Versioni 3.2.6 (pianificata per EOL, consulta la pianificazione di [fine del ciclo di vita delle versioni Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e successive. |
| Conforme a HIPAA | Versioni 3.2.6 (pianificata per EOL, consulta la pianificazione di [fine del ciclo di vita delle versioni Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e successive. | Versioni 3.2.6 (pianificata per EOL, consulta la pianificazione di [fine del ciclo di vita delle versioni Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e successive. |
| Conforme a DSS PCI | Versioni 3.2.6 (pianificata per EOL, consulta la pianificazione di [fine del ciclo di vita delle versioni Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e successive. | Versioni 3.2.6 (pianificata per EOL, consulta la pianificazione di [fine del ciclo di vita delle versioni Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e successive. |
| Resharding online | N/D | Versione 3.2.10 (pianificata per EOL, consulta la pianificazione della fine del ciclo di vita delle versioni [Redis OSS](engine-versions.md#deprecated-engine-versions)) e successive. |
## scegliere il servizio più adatto.
Quando scegli tra Valkey o Redis OSS (modalità cluster disabilitata) o Valkey o Redis OSS (modalità cluster abilitata), considera i seguenti fattori:
+ **Dimensionamento e partizionamento ** - Le esigenze aziendali cambiano. Occorre fornire il provisioning per picchi di richiesta o ridimensionare quando la richiesta cambia. Valkey o Redis OSS (modalità cluster disabilitata) supporta la scalabilità. Puoi ridimensionare la capacità di lettura aggiungendo o eliminando nodi di replica, oppure può ridimensionare la capacità passando a un tipo di nodo più grande. Entrambe queste operazioni richiedono tempo. Per ulteriori informazioni, consultare [Scalabilità dei nodi di replica per Valkey o Redis OSS (modalità cluster disabilitata)](Scaling.RedisReplGrps.md).
Valkey o Redis OSS (modalità cluster abilitata) supporta il partizionamento dei dati su un massimo di 500 gruppi di nodi. Puoi modificare dinamicamente il numero di shard quando le esigenze aziendali cambiano. Un vantaggio del partizionamento è la possibilità di distribuire il carico su un numero maggiore di endpoint, riducendo i colli di bottiglia di accesso durante i picchi di richiesta. Inoltre, puoi ospitare un set di dati più grande poiché i dati possono essere distribuiti su più server. Per informazioni sul ridimensionamento delle partizioni, consulta. [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md)
+ **Dimensione del nodo rispetto al numero di nodi**: poiché un cluster Valkey o Redis OSS (modalità cluster disabilitata) ha un solo shard, il tipo di nodo deve essere sufficientemente grande da contenere tutti i dati del cluster più il sovraccarico necessario. D'altra parte, poiché è possibile partizionare i dati su più shard quando si utilizza un cluster Valkey o Redis OSS (modalità cluster abilitata), i tipi di nodi possono essere più piccoli, ma sono necessari più nodi. Per ulteriori informazioni, consulta [Scelta delle dimensioni dei nodi](CacheNodes.SelectSize.md).
+ **Letture o scritture**: se il carico principale sul cluster è costituito da applicazioni che leggono dati, è possibile scalare un cluster Valkey o Redis OSS (modalità cluster disabilitata) aggiungendo ed eliminando repliche di lettura. Tuttavia, esiste un numero massimo di 5 repliche di lettura. Se il carico sul cluster è elevato in termini di scrittura, puoi trarre vantaggio dagli endpoint di scrittura aggiuntivi di un cluster Valkey o Redis OSS (modalità cluster abilitata) con più shard.
A prescindere dal tipo di cluster che scegliere di implementare, assicurati di scegliere un tipo di nodo adeguato per le esigenze correnti e future.
# Riduzione al minimo dei tempi di inattività ElastiCache utilizzando Multi-AZ con Valkey e Redis OSS
Esistono diversi casi in cui ElastiCache per Valkey e Redis OSS potrebbe essere necessario sostituire un nodo primario, tra cui alcuni tipi di manutenzione pianificata e l'improbabile eventualità di un guasto del nodo primario o della zona di disponibilità.
Questa sostituzione comporta alcuni tempi di inattività per il cluster, ma se la funzione Multi-AZ è abilitata, il tempo di inattività viene ridotto al minimo. Il ruolo del nodo primario eseguirà automaticamente il failover su una delle repliche di lettura. Non è necessario creare ed effettuare il provisioning di un nuovo nodo primario, in quanto ElastiCache gestirà la situazione in modo trasparente. Questo failover e la promozione delle repliche garantiscono la possibilità di ricominciare a scrivere nel nuovo nodo primario non appena la promozione è terminata.
ElastiCache propaga anche il nome DNS (Domain Name Service) della replica promossa. Questo perché se l'applicazione scrive nell'endpoint primario, allora non è richiesta alcuna modifica dell'endpoint nell'applicazione. Tuttavia, poiché la lettura viene eseguita da singoli endpoint, occorre assicurarsi di modificare l'endpoint di lettura della replica promossa al nodo primario nel nuovo endpoint della replica.
In caso di sostituzioni dei nodi pianificati, iniziati a causa di aggiornamenti di manutenzione o aggiornamenti self-service, fare attenzione a quanto segue:
+ Per i cluster Valkey e Redis OSS, le sostituzioni pianificate dei nodi vengono completate mentre il cluster gestisce le richieste di scrittura in entrata.
+ Per i cluster Valkey e Redis OSS disabilitati in modalità cluster con Multi-AZ abilitato che funzionano sul motore 5.0.6 o successivo, le sostituzioni pianificate dei nodi vengono completate mentre il cluster gestisce le richieste di scrittura in entrata.
+ Per i cluster disabilitati in modalità cluster Valkey e Redis OSS con Multi-AZ abilitato che funzionano sul motore 4.0.10 o precedente, potresti notare una breve interruzione di scrittura associata agli aggiornamenti DNS. Questa interruzione potrebbe richiedere fino a pochi secondi. Questo processo è molto più veloce rispetto a dover ricreare e rieseguire il provisioning di un nuovo primario, come accade nel caso in cui la funzione Multi-AZ non viene abilitata.
È possibile abilitare Multi-AZ utilizzando la console di gestione, o l'API ElastiCache . AWS CLI ElastiCache
L'abilitazione di ElastiCache Multi-AZ sul cluster Valkey o Redis OSS (nell'API e nella CLI, gruppo di replica) migliora la tolleranza agli errori. Ciò è vero in particolare nei casi in cui il cluster read/write primario del cluster diventa irraggiungibile o si guasta per qualsiasi motivo. Multi-AZ è supportato solo sui cluster Valkey e Redis OSS con più di un nodo in ogni shard.
**Topics**
+ [Abilitazione della funzione Multi-AZ](#AutoFailover.Enable)
+ [Risposte per scenari di errore relativi alla funzione Multi-AZ](#AutoFailover.Scenarios)
+ [Test del failover automatico](#auto-failover-test)
+ [Limitazioni su Multi-AZ](#AutoFailover.Limitations)
## Abilitazione della funzione Multi-AZ
È possibile abilitare Multi-AZ quando si crea o si modifica un cluster (API o CLI, gruppo di replica) utilizzando ElastiCache la console AWS CLI o l'API. ElastiCache
È possibile abilitare Multi-AZ solo su cluster Valkey o Redis OSS (modalità cluster disabilitata) che dispongono di almeno una replica di lettura disponibile. I cluster senza repliche di lettura non forniscono alta disponibilità o tolleranza ai guasti. Per informazioni sulla creazione di un cluster con replica, consulta [Creazione di un gruppo di replica Valkey o Redis OSS](Replication.CreatingRepGroup.md). Per informazioni sull'aggiunta di una replica di lettura a un cluster con replica, consulta [Aggiungere una replica di lettura per Valkey o Redis OSS (modalità cluster disabilitata)](Replication.AddReadReplica.md).
**Topics**
+ [Abilitazione del Multi-AZ (console)](#AutoFailover.Enable.Console)
+ [Abilitazione di Multi-AZ (AWS CLI)](#AutoFailover.Enable.CLI)
+ [Abilitazione di Multi-AZ (ElastiCache API)](#AutoFailover.Enable.API)
### Abilitazione del Multi-AZ (console)
È possibile abilitare Multi-AZ utilizzando la ElastiCache console quando si crea un nuovo cluster Valkey o Redis OSS o modificando un cluster esistente con la replica.
Multi-AZ è abilitato per impostazione predefinita sui cluster Valkey o Redis OSS (modalità cluster abilitata).
**Importante**
ElastiCache abiliterà automaticamente Multi-AZ solo se il cluster contiene almeno una replica in una zona di disponibilità diversa da quella principale in tutti gli shard.
#### Abilitazione di Multi-AZ durante la creazione di un cluster utilizzando la console ElastiCache
Per ulteriori informazioni su questo processo, consulta [Creazione di un cluster Valkey (modalità cluster disabilitata) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs). Assicurati di disporre di una o più repliche e di abilitare la funzione Multi-AZ.
#### Abilitazione della funzione Multi-AZ in un cluster esistente (console)
Per ulteriori informazioni su questo processo, consulta [Usando il ElastiCache Console di gestione AWS](Clusters.Modify.md#Clusters.Modify.CON) nella sezione relativa alla modifica di un cluster.
### Abilitazione di Multi-AZ (AWS CLI)
Il seguente esempio di codice utilizza AWS CLI per abilitare Multi-AZ per il gruppo di replica. `redis12`
**Importante**
Il gruppo di replica `redis12` deve esistere già e disporre di almeno una replica di lettura.
Per Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id redis12 \
--automatic-failover-enabled \
--multi-az-enabled \
--apply-immediately
```
Per Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id redis12 ^
--automatic-failover-enabled ^
--multi-az-enabled ^
--apply-immediately
```
L'output JSON di questo comando dovrebbe essere simile a quanto segue:
```
{
"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": {}
}
}
```
Per ulteriori informazioni, consulta questi argomenti nel *Riferimento ai comandi AWS CLI *:
+ [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)nel *AWS CLI Command Reference*.
### Abilitazione di Multi-AZ (ElastiCache API)
Il seguente esempio di codice utilizza l' ElastiCache API per abilitare Multi-AZ per il gruppo di replica. `redis12`
**Nota**
Per utilizzare questo esempio, il gruppo di replica `redis12` deve esistere già e disporre di almeno una replica di lettura.
```
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=
```
Per ulteriori informazioni, consulta questi argomenti nella *Documentazione di riferimento dell'API ElastiCache *:
+ [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)
## Risposte per scenari di errore relativi alla funzione Multi-AZ
Prima dell'introduzione di Multi-AZ, ElastiCache rilevava e sostituiva i nodi guasti di un cluster ricreando e rifornendo il nodo guasto. Abilitando la funzione Multi-AZ, un nodo primario non riuscito esegue il failover nella replica con il ritardo di replica minimo. La replica selezionata viene promossa automaticamente al nodo primario. Questa è un'operazione molto più rapida rispetto alla creazione e al provisioning di un nuovo nodo primario. Questo processo richiede in genere pochi secondi prima che sia possibile scrivere nuovamente nel cluster.
Quando Multi-AZ è abilitato, monitora ElastiCache continuamente lo stato del nodo primario. Se il nodo primario non riesce, viene eseguita una delle seguenti operazioni a seconda del tipo di errore.
**Topics**
+ [Scenari di errore quando solo il nodo primario non riesce](#AutoFailover.Scenarios.PrimaryOnly)
+ [Scenari di errore quando il nodo primario e alcune repliche di lettura non riescono](#AutoFailover.Scenarios.PrimaryAndReplicas)
+ [Scenari di fallimento quando l'intero cluster non riesce](#AutoFailover.Scenarios.AllFail)
### Scenari di errore quando solo il nodo primario non riesce
Se il nodo primario non riesce, la replica di lettura con il tempo di replica minimo viene promossa al cluster primario. Viene quindi creata una replica di lettura sostitutiva e viene eseguito il provisioning nella stessa zona di disponibilità del nodo primario non riuscito.
Quando si verifica un errore solo nel nodo primario, ElastiCache Multi-AZ esegue le seguenti operazioni:
1. Il nodo primario non riuscito viene portato offline.
1. La replica di lettura con il tempo di replica minimo viene promossa al nodo primario.
Le scritture possono riprendere non appena il processo di promozione viene completato, in genere pochi secondi. Se l'applicazione sta scrivendo nell'endpoint primario, non occorre modificare l'endpoint delle scritture poiché ElastiCache propaga il nome DNS della replica promossa.
1. Una replica di lettura sostitutiva viene avviata e sottoposta a provisioning.
La replica di lettura sostitutiva viene avviata nella zona di disponibilità in cui si trovava il nodo primario non riuscito, in modo da mantenere la distribuzione dei nodi.
1. Le repliche si sincronizzano con il nuovo nodo primario.
Dopo che la nuova replica è disponibile, tieni presente questi effetti:
+ **Endpoint primario** - Non è necessario apportare modifiche alla tua applicazione, poiché il nome DNS del nuovo nodo primario viene propagato all'endpoint primario.
+ **Endpoint di lettura** - L'endpoint di lettura viene aggiornato automaticamente per puntare ai nuovi nodi di replica.
Per informazioni sull'individuazione degli endpoint di un cluster, consulta i seguenti argomenti:
+ [Ricerca degli endpoint (console) del cluster Valkey o Redis OSS (modalità cluster disabilitata)](Endpoints.md#Endpoints.Find.Redis)
+ [Individuazione degli endpoint per i gruppi di replica Valkey o Redis OSS ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Ricerca di endpoint per Valkey o Redis OSS Replication Groups (API) ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
### Scenari di errore quando il nodo primario e alcune repliche di lettura non riescono
Se il nodo primario e almeno una replica di lettura non riescono, la replica disponibile con il ritardo di replica minimo viene promossa al cluster primario. Nuove repliche di lettura vengono inoltre create e sottoposte a provisioning nelle stesse zone di disponibilità dei nodi non riusciti e della replica che è stata promossa al nodo primario.
Quando il nodo primario e alcune repliche di lettura falliscono, ElastiCache Multi-AZ esegue le seguenti operazioni:
1. Il nodo primario non riuscito e le repliche di lettura non riuscite vengono portate offline.
1. La replica disponibile con il tempo di replica minimo viene promossa al nodo primario.
Le scritture possono riprendere non appena il processo di promozione viene completato, in genere pochi secondi. Se l'applicazione sta scrivendo sull'endpoint primario, non è necessario modificare l'endpoint per le scritture. ElastiCache propaga il nome DNS della replica promossa.
1. Repliche sostitutive vengono create e sottoposte a provisioning.
Le repliche sostitutive vengono create nelle zone di disponibilità dei nodi non riusciti, in modo da mantenere la distribuzione dei nodi.
1. Tutti i cluster si sincronizzano con il nuovo nodo primario.
Dopo che i nuovi nodi sono disponibili, occorre apportare le seguenti modifiche all'applicazione:
+ **Endpoint primario** - Non apportare modifiche all'applicazione. Il nome DNS del nuovo nodo primario viene propagato all'endpoint primario.
+ **Endpoint di lettura** - L'endpoint di lettura viene aggiornato automaticamente per puntare ai nuovi nodi di replica.
Per informazioni sull'individuazione degli endpoint di un gruppo di replica, consulta i seguenti argomenti:
+ [Ricerca degli endpoint (console) del cluster Valkey o Redis OSS (modalità cluster disabilitata)](Endpoints.md#Endpoints.Find.Redis)
+ [Individuazione degli endpoint per i gruppi di replica Valkey o Redis OSS ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Ricerca di endpoint per Valkey o Redis OSS Replication Groups (API) ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
### Scenari di fallimento quando l'intero cluster non riesce
In caso di errore generale, tutti i nodi vengono ricreati e sottoposti a provisioning nelle stesse zone di disponibilità dei nodi originali.
In questo scenario, tutti i dati nel cluster vengono persi a causa del guasto di ogni nodo nel cluster. Questa eventualità è rara.
In caso di guasto dell'intero cluster, ElastiCache Multi-AZ esegue le seguenti operazioni:
1. Il nodo primario e le repliche di lettura non riusciti vengono portati offline.
1. Un nodo primario sostitutivo viene creato e sottoposto a provisioning.
1. Repliche sostitutive vengono create e sottoposte a provisioning.
Le sostituzioni vengono create nelle zone di disponibilità dei nodi non riusciti, in modo da mantenere la distribuzione dei nodi.
Poiché l'intero cluster non è riuscito, i dati vengono persi e tutti i nuovi nodi vengono avviati come inattivi.
Poiché ciascuno dei nodi sostitutivi ha lo stesso endpoint del nodo che sta sostituendo, non occorre apportare modifiche all'endpoint nell'applicazione.
Per informazioni sull'individuazione degli endpoint di un gruppo di replica, consulta i seguenti argomenti:
+ [Ricerca degli endpoint (console) del cluster Valkey o Redis OSS (modalità cluster disabilitata)](Endpoints.md#Endpoints.Find.Redis)
+ [Individuazione degli endpoint per i gruppi di replica Valkey o Redis OSS ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Ricerca di endpoint per Valkey o Redis OSS Replication Groups (API) ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
Ti consigliamo di creare il nodo primario e le repliche di lettura in zone di disponibilità diverse per aumentare il livello di tolleranza ai guasti.
## Test del failover automatico
Dopo aver abilitato il failover automatico, è possibile testarlo utilizzando la ElastiCache console AWS CLI, l'e l' ElastiCache API.
Durante il test, tieni presente quanto segue:
+ È possibile utilizzare questa operazione per testare il failover automatico su un massimo di 15 shard (chiamati gruppi di nodi nell' ElastiCache API e AWS CLI) in un periodo di 24 ore continuative.
+ Se chiami questa operazione su partizioni in cluster diversi (chiamati gruppi di replica nell'API e in CLI), puoi eseguire le chiamate contemporaneamente.
+ In alcuni casi, è possibile richiamare questa operazione più volte su shard diversi nello stesso gruppo di replica Valkey o Redis OSS (modalità cluster abilitata). In questi casi, la sostituzione del primo nodo deve essere completata prima di effettuare una chiamata successiva.
+ Per determinare se la sostituzione del nodo è completa, controlla gli eventi utilizzando la ElastiCache console Amazon AWS CLI, l'o l' ElastiCache API. Cerca i seguenti eventi correlati al failover automatico, elencati qui in ordine di occorrenza:
1. Messaggio del gruppo di replica: `Test Failover API called for node group `
1. Messaggio del cluster di cache: `Failover from primary node to replica node completed`
1. Messaggio del gruppo di replica: `Failover from primary node to replica node completed`
1. Messaggio del cluster di cache: `Recovering cache nodes `
1. Messaggio del cluster di cache: `Finished recovery for cache nodes `
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Visualizzazione ElastiCache degli eventi](ECEvents.Viewing.md) nella *Guida per l'utente di ElastiCache *
+ [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html) nel *Documentazione di riferimento API di ElastiCache *
+ [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) nel *Riferimento ai comandi AWS CLI .*
+ Questa API è progettata per testare il comportamento dell'applicazione in caso di ElastiCache failover. Non è progettato per essere uno strumento operativo per l'avvio di un failover per risolvere un problema con il cluster. Inoltre, in determinate condizioni, come eventi operativi su larga scala, AWS può bloccare questa API.
**Topics**
+ [Test del failover automatico utilizzando Console di gestione AWS](#auto-failover-test-con)
+ [Test del failover automatico utilizzando AWS CLI](#auto-failover-test-cli)
+ [Test del failover automatico utilizzando l'API ElastiCache](#auto-failover-test-api)
### Test del failover automatico utilizzando Console di gestione AWS
Utilizza la procedura seguente per testare il failover automatico con la console.
**Per testare il failover automatico**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel pannello di navigazione, scegli **Valkey** o **Redis** OSS.
1. Dall'elenco dei cluster, scegli la casella a sinistra del cluster che desideri testare. Questo cluster deve disporre almeno di un nodo di replica di lettura.
1. Nell'area **Dettagli**, conferma che questo cluster è abilitato per Multi-AZ. Se il cluster non è abilitato per la funzione Multi-AZ, scegliere un cluster diverso o modificare questo cluster per abilitare la funzione Multi-AZ. Per ulteriori informazioni, consulta [Usando il ElastiCache Console di gestione AWS](Clusters.Modify.md#Clusters.Modify.CON).
![\[Immagine: area dei dettagli di un cluster abilitato per Multi-AZ\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-AutoFailover-MultiAZ-Enabled.png)
1. Per Valkey o Redis OSS (modalità cluster disabilitata), scegli il nome del cluster.
Per Valkey o Redis OSS (modalità cluster abilitata), procedi come segue:
1. Seleziona il nome del cluster.
1. Nella pagina **Shards (Partizioni)**, per la partizione (chiamato gruppo di nodi nell'API e in CLI) su cui desideri testare il failover, scegliere il nome della partizione.
1. Nella pagina dei nodi, scegli **Failover Primary (Failover primario)**.
1. Scegli **Continua** per eseguire il failover nel nodo primario o **Annulla** per annullare l'operazione e non eseguire il failover nel nodo primario.
Durante il processo di failover, la console continua a visualizzare lo stato del nodo come *disponibile*. Per monitorare l'avanzamento del test di failover, scegli **Eventi** dal riquadro di navigazione della console. Nella scheda **Eventi**, cerca gli eventi che indicano che il failover è stato avviato (`Test Failover API called`) e completato (`Recovery completed`).
### Test del failover automatico utilizzando AWS CLI
È possibile testare il failover automatico su qualsiasi cluster dotato di Multi-AZ utilizzando l' AWS CLI operazione. `test-failover`
**Parametri**
+ `--replication-group-id` – Obbligatorio. Il gruppo di replica (sulla console, cluster) da testare.
+ `--node-group-id` – Obbligatorio. Il nome del gruppo di nodi sui cui testare il failover automatico. È possibile testare un massimo di 15 gruppi di nodi in un periodo continuativo di 24 ore.
L'esempio seguente lo utilizza AWS CLI per testare il failover automatico sul gruppo di nodi `redis00-0003` nel cluster Valkey o Redis OSS (modalità cluster abilitata). `redis00`
**Example Test del failover automatico**
Per Linux, macOS o Unix:
```
aws elasticache test-failover \
--replication-group-id redis00 \
--node-group-id redis00-0003
```
Per Windows:
```
aws elasticache test-failover ^
--replication-group-id redis00 ^
--node-group-id redis00-0003
```
L'aspetto dell'output del comando precedente è simile al seguente.
```
{
"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": {}
}
}
```
Per tenere traccia dell'avanzamento del failover, utilizzare l'operazione. AWS CLI `describe-events`
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [test-failover](https://docs.aws.amazon.com/cli/latest/reference/elasticache/test-failover.html) nel *Riferimento ai comandi AWS CLI .*
+ [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) nel *Riferimento ai comandi AWS CLI .*
### Test del failover automatico utilizzando l'API ElastiCache
È possibile testare il failover automatico su qualsiasi cluster abilitato con Multi-AZ utilizzando l'operazione ElastiCache API. `TestFailover`
**Parametri**
+ `ReplicationGroupId` – Obbligatorio. Il gruppo di replica (sulla console, cluster) da testare.
+ `NodeGroupId` – Obbligatorio. Il nome del gruppo di nodi sui cui testare il failover automatico. È possibile testare un massimo di 15 gruppi di nodi in un periodo continuativo di 24 ore.
L'esempio seguente esegue il test del failover automatico sul gruppo di nodi `redis00-0003` nel gruppo di replica (sulla console, cluster) `redis00`.
**Example Test del failover automatico**
```
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=
```
Per tenere traccia dell'avanzamento del failover, utilizzate l'operazione ElastiCache `DescribeEvents` API.
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)nell'*ElastiCache API Reference*
+ [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html)nell'*ElastiCache API Reference*
## Limitazioni su Multi-AZ
Tieni presente le seguenti limitazioni per Multi-AZ:
+ Multi-AZ è supportato su Valkey e sulla versione 2.8.6 e successive di Redis OSS.
+ Multi-AZ non è supportato sui tipi di nodi T1.
+ La replica di Valkey e Redis OSS è asincrona. Pertanto, quando un nodo primario esegue il failover in una replica, si può verificare una piccola perdita di dati a causa del ritardo di replica.
Quando si sceglie la replica da promuovere a principale, ElastiCache sceglie la replica con il minor ritardo di replica. ovvero quella più attuale. Ciò consente di ridurre al minimo la quantità di dati persi. La replica con il ritardo di replica minimo si può trovare nella stessa zona di disponibilità del nodo primario con errore o in una zona diversa.
+ Quando promuovi manualmente le repliche di lettura a primarie su cluster Valkey o Redis OSS con la modalità cluster disabilitata, puoi farlo solo quando Multi-AZ e il failover automatico sono disabilitati. Per promuovere una replica di lettura a nodo primario, procedi come indicato di seguito:
1. Disabilitare la funzione Multi-AZ nel cluster.
1. Disabilitare il failover automatico nel cluster. È possibile eseguire questa operazione tramite la console deselezionando la casella di controllo **Auto failover** per il gruppo di replica. È inoltre possibile eseguire questa operazione AWS CLI impostando la `AutomaticFailoverEnabled` proprietà su `false` quando si chiama l'operazione. `ModifyReplicationGroup`
1. Promuovere la replica di lettura al nodo primario.
1. Riattivare la funzione Multi-AZ.
+ ElastiCache per Redis OSS Multi-AZ e append-only file (AOF) si escludono a vicenda. Se si abilita una, non si può abilitare l'altra.
+ Un guasto del nodo può essere causato dal raro evento di errore di un'intera zona di disponibilità. In questo caso, la replica che sostituisce il nodo primario in errore viene creata solo quando la zona di disponibilità viene ripristinata. Ad esempio, considerare un gruppo di replica con il nodo primario in AZ e le repliche in AZ-b e AZ-c. Se il nodo primario non riesce, la replica con il tempo di replica minimo viene promossa al cluster primario. Quindi, ElastiCache crea una nuova replica in az-A (dove si trovava il file primario guasto) solo quando Az-a è di nuovo attivo e disponibile.
+ Un riavvio di un nodo primario iniziato dal cliente non attiva il failover automatico. Altri riavvi ed guasti attivano il failover automatico.
+ Ogni volta che il nodo primario viene riavviato, i dati vengono cancellati quando ritorna online. Quando le repliche di lettura rilevano il cluster primario cancellato, cancellano la loro copia dei dati causando perdita dei dati.
+ Dopo che una replica di lettura è stata promossa, le altre repliche si sincronizzano con il nuovo nodo primario. Dopo la sincronizzazione iniziale, il contenuto delle repliche viene eliminato e vengono sincronizzati i dati dal nuovo nodo primario. Questo processo di sincronizzazione causa una breve interruzione, durante la quale le repliche non sono accessibili. Il processo di sincronizzazione causa anche un incremento di carico temporaneo sul nodo primario durante la sincronizzazione con le repliche. Questo comportamento è nativo di Valkey e Redis OSS e non è esclusivo di Multi-AZ. ElastiCache Per i dettagli su questo comportamento, consulta [Replication](http://valkey.io/topics/replication) sul sito Web di Valkey.
**Importante**
Per Valkey 7.2.6 e versioni successive o Redis OSS versione 2.8.22 e successive, non è possibile creare repliche esterne.
Per le versioni Redis OSS precedenti alla 2.8.22, si consiglia di non connettere una replica esterna a un cluster con funzionalità Multi-AZ. ElastiCache Questa configurazione non supportata può creare problemi che impediscono la corretta esecuzione del failover e del ElastiCache ripristino. Per connettere una replica esterna a un ElastiCache cluster, assicurati che Multi-AZ non sia abilitato prima di effettuare la connessione.
# Modalità di implementazione di sincronizzazione e backup
Tutte le versioni supportate di Valkey e Redis OSS supportano il backup e la sincronizzazione tra i nodi primari e di replica. Tuttavia, il modo in cui vengono implementati il backup e la sincronizzazione varia a seconda della versione.
## Redis OSS versione 2.8.22 e successive
La replica Redis OSS, nelle versioni 2.8.22 e successive, è possibile scegliere tra due metodi. Per ulteriori informazioni, consultare [Versioni Redis OSS precedenti alla 2.8.22](#Replication.Redis.Earlier2-8-22) e [Snapshot e ripristino](backups.md).
Durante il processo senza fork, se i carichi di scrittura sono intensi, le scritture nel cluster vengono ritardate per garantire che non vengano accumulate troppe modifiche che impediscono la riuscita di una snapshot.
## Versioni Redis OSS precedenti alla 2.8.22
Il backup e la sincronizzazione di Redis OSS nelle versioni precedenti alla 2.8.22 sono un processo in tre fasi.
1. Fork e il processo in background serializzano i dati del cluster su disco. Questo crea un'istantanea. point-in-time
1. In primo piano, accumulare un change log nel *buffer di output client*.
**Importante**
Se il change log supera le dimensioni del *buffer di output del client*, l'operazione di backup o sincronizzazione non riesce. Per ulteriori informazioni, consulta [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md).
1. Infine, trasmettere i dati di cache e il change log al nodo di replica.
# Creazione di un gruppo di replica Valkey o Redis OSS
Per creare un cluster con nodi di replica sono disponibili le seguenti opzioni. Uno si applica quando è già disponibile un cluster Valkey o Redis OSS (modalità cluster disabilitata) non associato a nessun cluster che dispone di repliche da utilizzare come nodo principale. L'altra si applica quando desideri creare un nodo primario con il cluster e le repliche di lettura. Attualmente, un cluster Valkey o Redis OSS (modalità cluster abilitata) deve essere creato da zero.
**Opzione 1:[Creazione di un gruppo di replica utilizzando un cluster esistente](Replication.CreatingReplGroup.ExistingCluster.md)**
Utilizzate questa opzione per sfruttare un cluster Valkey o Redis OSS (modalità cluster disabilitata) esistente a nodo singolo. Specifica questo nodo esistente come il nodo primario nel nuovo cluster e quindi aggiungi individualmente da 1 a 5 repliche di lettura al cluster. Se il cluster esistente è attivo, le repliche di lettura si sincronizzano con il cluster mentre vengono create. Consultare [Creazione di un gruppo di replica utilizzando un cluster esistente](Replication.CreatingReplGroup.ExistingCluster.md).
Non è possibile creare un cluster Valkey o Redis OSS (modalità cluster abilitata) utilizzando un cluster esistente. Per creare un cluster Valkey o Redis OSS (modalità cluster abilitata) (API/CLI: gruppo di replica) utilizzando la console, vedere. ElastiCache [Creazione di un cluster Valkey o Redis OSS (modalità cluster abilitata) (Console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
**Opzione 2:[Creazione da zero di un gruppo di replica Valkey o Redis OSS](Replication.CreatingReplGroup.NoExistingCluster.md)**
Utilizza questa opzione se non disponi già di un cluster Valkey o Redis OSS (modalità cluster disabilitata) da utilizzare come nodo primario del cluster o se desideri creare un cluster Valkey o Redis OSS (modalità cluster abilitata). Consultare [Creazione da zero di un gruppo di replica Valkey o Redis OSS](Replication.CreatingReplGroup.NoExistingCluster.md).
# Creazione di un gruppo di replica utilizzando un cluster esistente
La procedura seguente aggiunge un gruppo di replica al cluster a nodo singolo Valkey o Redis OSS (modalità cluster disabilitata), necessario per aggiornare il cluster all'ultima versione di Valkey. Si tratta di una procedura in loco che comporta zero tempi di inattività e zero perdite di dati. Quando si crea un gruppo di replica per un cluster a nodo singolo, il nodo del cluster diventa il nodo principale del nuovo cluster. Se non disponi di un cluster Valkey o Redis OSS (modalità cluster disabilitata) che puoi utilizzare come principale del nuovo cluster, vedi. [Creazione da zero di un gruppo di replica Valkey o Redis OSS](Replication.CreatingReplGroup.NoExistingCluster.md)
Un cluster disponibile è un cluster Valkey o Redis OSS esistente a nodo singolo. Attualmente, Valkey o Redis OSS (modalità cluster abilitata) non supportano la creazione di un cluster con repliche utilizzando un cluster a nodo singolo disponibile. Se desideri creare un cluster Valkey o Redis OSS (modalità cluster abilitata), consulta. [Creazione di un cluster Valkey o Redis OSS (modalità cluster abilitata) (console)](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON)
## Creazione di un gruppo di replica utilizzando un cluster esistente (Console)
Consulta l'argomento [Utilizzando il ElastiCache Console di gestione AWS](Clusters.AddNode.md#Clusters.AddNode.CON)
## Creazione di un gruppo di replica utilizzando un cluster Valkey o Redis OSS disponibile ()AWS CLI
Esistono due passaggi per creare un gruppo di replica con repliche di lettura quando si utilizza un Valkey o Redis OSS Cache Cluster disponibile come primario quando si utilizza il.AWS CLI
Quando si utilizza il,AWS CLI si crea un gruppo di replica specificando il nodo standalone disponibile come nodo principale del cluster `--primary-cluster-id` e il numero di nodi che si desidera inserire nel cluster utilizzando il comando CLI,. `create-replication-group` Includi i seguenti parametri.
**--replication-group-id**
Il nome del gruppo di replica che stai creando. Il valore di questo parametro viene utilizzato come la base per i nomi dei nodi aggiunti con un numero di tre cifre sequenziale aggiunto alla fine di `--replication-group-id`. Ad esempio, `sample-repl-group-001`.
I vincoli di denominazione dei gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata) sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
**--replication-group-description**
Descrizione del gruppo di replica.
**--num-node-groups**
Numero di nodi desiderati in questo cluster. Questo valore include il nodo primario. Il valore massimo di questo parametro è sei.
**--primary-cluster-id**
Il nome del nodo del cluster Valkey o Redis OSS (modalità cluster disabilitata) disponibile che si desidera utilizzare come nodo principale in questo gruppo di replica.
Il comando seguente crea il gruppo di replica `sample-repl-group` utilizzando il cluster Valkey o Redis OSS (modalità cluster disabilitata) disponibile `redis01` come nodo primario del gruppo di replica. Vengono creati due nuovi nodi che sono repliche di lettura. Le impostazioni di `redis01` (ovvero, gruppo di parametri, gruppo di sicurezza, tipo di nodo, versione motore e così via) verranno applicate a tutti i nodi nel gruppo di replica.
Per Linux, macOS o 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
```
Per 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
```
Per ulteriori informazioni e parametri che potresti voler utilizzare, consulta l'argomento.AWS CLI[create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
**Aggiunta di repliche di lettura al gruppo di replica**
Dopo che il gruppo di replica è stato creato, aggiungi da una a cinque repliche di lettura utilizzando il comando `create-cache-cluster`, assicurandoti di includere i seguenti parametri.
**--cache-cluster-id**
Il nome del cluster che stai aggiungendo al gruppo di replica.
I vincoli di denominazione dei cluster sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
**--replication-group-id**
Il nome del gruppo di replica a cui si sta aggiungendo questo cluster.
Ripeti questo comando per ogni replica di lettura che desideri aggiungere al gruppo di replica, modificando solo il valore del parametro `--cache-cluster-id`.
**Nota**
Ricorda che un gruppo di replica non può contenere più di cinque repliche di lettura. Se tenti di aggiungere una replica di lettura a un gruppo di replica che contiene già cinque repliche di lettura, l'operazione non riesce.
Il codice seguente consente di aggiungere la replica di lettura `my-replica01` al gruppo di replica `sample-repl-group`. Le impostazioni del cluster primario, ovvero gruppo di parametri, gruppo di sicurezza, tipo di nodo e così via - verranno applicati ai nodi quando vengono aggiunti al gruppo di replica.
Per Linux, macOS o Unix:
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-replica01 \
--replication-group-id sample-repl-group
```
Per Windows:
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-replica01 ^
--replication-group-id sample-repl-group
```
L'aspetto dell'output di questo comando sarà simile al seguente.
```
{
"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": {}
}
}
```
Per ulteriori informazioni, vedere gli AWS CLI argomenti:
+ [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)
## Aggiungere repliche a un cluster (API) Valkey o Redis OSS (Cluster Mode Disabled) autonomo ElastiCache
Quando si utilizza l' ElastiCache API, si crea un gruppo di replica specificando il nodo standalone disponibile come nodo primario del cluster `PrimaryClusterId` e il numero di nodi che si desidera inserire nel cluster utilizzando il comando CLI,. `CreateReplicationGroup` Includi i seguenti parametri.
**ReplicationGroupId**
Il nome del gruppo di replica che stai creando. Il valore di questo parametro viene utilizzato come la base per i nomi dei nodi aggiunti con un numero di tre cifre sequenziale aggiunto alla fine di `ReplicationGroupId`. Ad esempio, `sample-repl-group-001`.
I vincoli di denominazione dei gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata) sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
**ReplicationGroupDescription**
Descrizione del cluster con repliche.
**NumCacheClusters**
Numero di nodi desiderati in questo cluster. Questo valore include il nodo primario. Il valore massimo di questo parametro è sei.
**PrimaryClusterId**
Il nome del cluster Valkey o Redis OSS (modalità cluster disabilitata) disponibile che si desidera utilizzare come nodo principale di questo cluster.
Il comando seguente crea il cluster con repliche `sample-repl-group` utilizzando il cluster Valkey o Redis OSS (modalità cluster disabilitata) disponibile `redis01` come nodo primario del gruppo di replica. Vengono creati due nuovi nodi che sono repliche di lettura. Le impostazioni di `redis01` (ovvero, gruppo di parametri, gruppo di sicurezza, tipo di nodo, versione motore e così via) verranno applicate a tutti i nodi nel gruppo di replica.
```
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=
```
Per ulteriori informazioni, consulta gli argomenti APL: ElastiCache
+ [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
+ [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
**Aggiunta di repliche di lettura al gruppo di replica**
Dopo che il gruppo di replica è stato creato, aggiungi a esso da una a cinque repliche di lettura utilizzando l'operazione `CreateCacheCluster`, assicurandoti di includere i seguenti parametri.
**CacheClusterId**
Il nome del cluster che stai aggiungendo al gruppo di replica.
I vincoli di denominazione dei cluster sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
**ReplicationGroupId**
Il nome del gruppo di replica a cui si sta aggiungendo questo cluster.
Ripeti questa operazione per ogni replica di lettura che desideri aggiungere al gruppo di replica, modificando solo il valore del parametro `CacheClusterId`.
Il seguente codice aggiunge la replica di lettura `myReplica01` al gruppo di replica `myReplGroup` Le impostazioni del cluster primario, ovvero gruppo di parametri, gruppo di sicurezza, tipo di nodo e così via - verranno applicati ai nodi quando vengono aggiunti al gruppo di replica.
```
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]
```
Per ulteriori informazioni e parametri che potresti voler utilizzare, consulta l'argomento ElastiCache [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html) API.
# Creazione da zero di un gruppo di replica Valkey o Redis OSS
Di seguito, è possibile scoprire come creare un gruppo di replica Valkey o Redis OSS senza utilizzare un cluster Valkey o Redis OSS esistente come principale. È possibile creare un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) o Valkey o Redis OSS (modalità cluster abilitata) partendo da zero utilizzando la console, l'o l'API. ElastiCache AWS CLI ElastiCache
Prima di continuare, decidete se volete creare un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) o un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata). Per le linee guida, consulta [Replica: modalità cluster Valkey e Redis OSS disabilitata o abilitata](Replication.Redis-RedisCluster.md).
**Topics**
+ [Creazione da zero di un gruppo di replica Valkey o Redis OSS (Cluster Mode Disabled)](Replication.CreatingReplGroup.NoExistingCluster.Classic.md)
+ [Creazione da zero di un gruppo di replica in Valkey o Redis OSS (modalità cluster abilitata)](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md)
# Creazione da zero di un gruppo di replica Valkey o Redis OSS (Cluster Mode Disabled)
È possibile creare un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) partendo da zero utilizzando la ElastiCache console, l'o l'API. AWS CLI ElastiCache Un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) ha sempre un gruppo di nodi, un cluster primario e fino a cinque repliche di lettura. I gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata) non supportano il partizionamento dei dati.
**Nota**
Il node/shard limite può essere aumentato fino a un massimo di 500 per cluster. Per richiedere un aumento dei limiti, consulta [AWS Limite dei servizi](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e includi il tipo di istanza nella richiesta.
Per creare da zero un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata), adotta uno dei seguenti approcci:
## Creazione da zero di un gruppo di replica Valkey o Redis OSS (Cluster Mode Disabled) ()AWS CLI
La procedura seguente crea un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) utilizzando. AWS CLI
Quando si crea un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) partendo da zero, si crea il gruppo di replica e tutti i relativi nodi con una singola chiamata al comando. AWS CLI `create-replication-group` Includi i seguenti parametri.
**--replication-group-id**
Il nome del gruppo di replica che stai creando.
I vincoli di denominazione dei gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata) sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
**--replication-group-description**
Descrizione del gruppo di replica.
**--num-cache-clusters**
Il numero di nodi che devono essere creati con questo gruppo di replica, nodo primario e repliche di lettura combinati.
Se abiliti Multi-AZ (`--automatic-failover-enabled`), il valore di `--num-cache-clusters` deve essere almeno 2.
**--cache-node-type**
Il tipo di nodo per ogni nodo nel gruppo di replica.
ElastiCache supporta i seguenti tipi di nodi. In generale, le generazioni attuali offrono più memoria e più potenza di elaborazione a un costo inferiore rispetto ai prodotti omologi della generazione precedente.
Per ulteriori informazioni sui dettagli delle prestazioni per ogni tipo di nodo, consulta [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Impostare questo parametro se si utilizza un tipo di nodo r6gd. Se non si desidera il tiering di dati, impostare `--no-data-tiering-enabled`. Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
**--cache-parameter-group**
Specifica un gruppo di parametri che corrisponde alla versione motore. Se utilizzi Redis OSS 3.2.4 o versione successiva, specifica il gruppo di parametri o un gruppo di `default.redis3.2` parametri derivato da `default.redis3.2` cui creare un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata). Per ulteriori informazioni, consulta [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
**--network-type**
`ipv4`, `ipv6` o `dual-stack`. Se scegli dual-stack, devi impostare il parametro `--IpDiscovery` su `ipv4` o `ipv6`.
**--engine**
redis
**--engine-version**
Per disporre del più ampio set di caratteristiche, scegliere la versione motore più recente.
I nomi dei nodi verranno derivati dal nome del gruppo di replica aggiungendo `-00`*\$1*. Ad esempio, utilizzando il nome del gruppo di replica `myReplGroup`, il nome del primario sarà `myReplGroup-001` e le repliche di lettura da `myReplGroup-002` a `myReplGroup-006`.
Se desideri abilitare la crittografia dei dati in transito o dei dati inattivi su questo gruppo di replica, aggiungi uno o entrambi i parametri `--transit-encryption-enabled` o `--at-rest-encryption-enabled` e soddisfa le seguenti condizioni.
+ Il gruppo di replica deve eseguire Redis OSS versione 3.2.6 o 4.0.10.
+ Il gruppo di replica deve essere creato in un Amazon VPC.
+ Devi anche includere il parametro `--cache-subnet-group`.
+ Deve anche includere il parametro `--auth-token` con il valore stringa specificato dal cliente per il token AUTH (password) necessario per eseguire operazioni su questo gruppo di replica.
La seguente operazione crea un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) `sample-repl-group` con tre nodi, uno principale e due repliche.
Per Linux, macOS o 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
```
Per 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
```
L'aspetto dell'output di questo comando è simile al seguente.
```
{
"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": {}
}
}
```
Per ulteriori informazioni e parametri che potresti voler utilizzare, consulta l'argomento. AWS CLI [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
## Creazione da zero di un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) (API) ElastiCache
La procedura seguente crea un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) utilizzando l'API. ElastiCache
Quando si crea un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) partendo da zero, si crea il gruppo di replica e tutti i relativi nodi con una singola chiamata all'operazione API. ElastiCache `CreateReplicationGroup` Includi i seguenti parametri.
**ReplicationGroupId**
Il nome del gruppo di replica che stai creando.
I vincoli di denominazione dei gruppi di replica Valkey o Redis OSS (modalità cluster abilitata) sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
**ReplicationGroupDescription**
La descrizione del gruppo di replica.
**NumCacheClusters**
Il numero totale di nodi che devono essere creati con questo gruppo di replica, nodo primario e repliche di lettura combinati.
Se abiliti Multi-AZ (`AutomaticFailoverEnabled=true`), il valore di `NumCacheClusters` deve essere almeno 2.
**CacheNodeType**
Il tipo di nodo per ogni nodo nel gruppo di replica.
ElastiCache supporta i seguenti tipi di nodi. In generale, le generazioni attuali offrono più memoria e più potenza di elaborazione a un costo inferiore rispetto ai prodotti omologi della generazione precedente.
Per ulteriori informazioni sui dettagli delle prestazioni per ogni tipo di nodo, consulta [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Impostare questo parametro se si utilizza un tipo di nodo r6gd. Se non si desidera il tiering di dati, impostare `--no-data-tiering-enabled`. Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
**CacheParameterGroup**
Specifica un gruppo di parametri che corrisponde alla versione motore. Se utilizzi Redis OSS 3.2.4 o versione successiva, specifica il gruppo di parametri o un gruppo di `default.redis3.2` parametri derivato da `default.redis3.2` cui creare un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata). Per ulteriori informazioni, consulta [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
**--network-type**
`ipv4`, `ipv` o `dual-stack`. Se scegli dual-stack, devi impostare il parametro `--IpDiscovery` su `ipv4` o `ipv6`.
**Motore**
redis
**EngineVersion**
6.0
I nomi dei nodi verranno derivati dal nome del gruppo di replica aggiungendo `-00`*\$1*. Ad esempio, utilizzando il nome del gruppo di replica `myReplGroup`, il nome del primario sarà `myReplGroup-001` e le repliche di lettura da `myReplGroup-002` a `myReplGroup-006`.
Se desideri abilitare la crittografia dei dati in transito o dei dati inattivi su questo gruppo di replica, aggiungi uno o entrambi i parametri `TransitEncryptionEnabled=true` o `AtRestEncryptionEnabled=true` e soddisfa le seguenti condizioni.
+ Il gruppo di replica deve eseguire Redis OSS versione 3.2.6 o 4.0.10.
+ Il gruppo di replica deve essere creato in un Amazon VPC.
+ Devi anche includere il parametro `CacheSubnetGroup`.
+ Deve anche includere il parametro `AuthToken` con il valore stringa specificato dal cliente per il token AUTH (password) necessario per eseguire operazioni su questo gruppo di replica.
La seguente operazione crea il gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) `myReplGroup` con tre nodi, uno principale e due repliche.
```
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=
```
Per ulteriori informazioni e parametri che potresti voler utilizzare, consulta l'argomento API. ElastiCache [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
# Creazione da zero di un gruppo di replica in Valkey o Redis OSS (modalità cluster abilitata)
È possibile creare un cluster Valkey o Redis OSS (modalità cluster abilitata) (API/CLI: *gruppo di replica*) utilizzando la ElastiCache console, l'o l'API. AWS CLI ElastiCache Un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) ha da 1 a 500 shard (API/CLI: gruppi di nodi), un nodo primario in ogni shard e fino a 5 repliche di lettura in ogni shard. Puoi creare un cluster con un numero più alto dle partizioni e un numero più basso di repliche per un totale di 90 nodi per cluster. Questa configurazione del cluster può andare da 90 partizioni e 0 repliche a 15 partizioni e 5 repliche che è il numero massimo consentito di repliche.
Il limite di nodi o shard può essere aumentato fino a un massimo di 500 per cluster se la versione del motore OSS Valkey o Redis è 5.0.6 o successiva. Ad esempio, è possibile scegliere di configurare un cluster a 500 nodi che varia tra 83 partizioni (un primario e 5 repliche per partizione) e 500 partizioni (un singolo primario e nessuna replica). Assicurati che esistano abbastanza indirizzi IP disponibili per soddisfare l'aumento. Le problematiche comuni sono che le le sottoreti nel gruppo di sottoreti hanno un intervallo CIDR troppo piccolo o che le sottoreti sono condivise e utilizzate pesantemente da altri cluster. Per ulteriori informazioni, consulta [Creazione di un gruppo di sottoreti](SubnetGroups.Creating.md).
Per le versioni inferiori alla 5.0.6, il limite è 250 per cluster.
Per richiedere un aumento dei limiti, consulta [Limiti dei servizi AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e seleziona il tipo di limite **Nodi per cluster per tipo di istanza**.
**Topics**
+ [Utilizzo della console ElastiCache](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON)
+ [Creazione da zero di un gruppo di replica Valkey o Redis OSS (Cluster Mode Enabled) ()AWS CLI](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CLI)
+ [Creazione da zero di un gruppo di replica in Valkey o Redis OSS (Cluster Mode Enabled) (API) ElastiCache](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.API)
## Creazione di un cluster Valkey o Redis OSS (modalità cluster abilitata) (console)
Per creare un cluster Valkey o Redis OSS (modalità cluster abilitata), vedere. [Creazione di un cluster Valkey o Redis OSS (modalità cluster abilitata) (Console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster) Assicurati di abilitare la modalità cluster, **Cluster Mode enabled (Modalità cluster abilitata (scalabilità orizzontale))**, e specifica almeno due partizioni e un nodo di replica in ciascuno di essi.
## Creazione da zero di un gruppo di replica Valkey o Redis OSS (Cluster Mode Enabled) ()AWS CLI
La procedura seguente crea un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) utilizzando. AWS CLI
Quando si crea un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) partendo da zero, si crea il gruppo di replica e tutti i relativi nodi con una singola chiamata al comando. AWS CLI `create-replication-group` Includi i seguenti parametri.
**--replication-group-id**
Il nome del gruppo di replica che stai creando.
I vincoli di denominazione dei gruppi di replica Valkey o Redis OSS (modalità cluster abilitata) sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
**--replication-group-description**
Descrizione del gruppo di replica.
**--cache-node-type**
Il tipo di nodo per ogni nodo nel gruppo di replica.
ElastiCache supporta i seguenti tipi di nodi. In generale, le generazioni attuali offrono più memoria e più potenza di elaborazione a un costo inferiore rispetto ai prodotti omologi della generazione precedente.
Per ulteriori informazioni sui dettagli delle prestazioni per ogni tipo di nodo, consulta [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Impostare questo parametro se si utilizza un tipo di nodo r6gd. Se non si desidera il tiering di dati, impostare `--no-data-tiering-enabled`. Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
**--cache-parameter-group**
Specificare il gruppo di `default.redis6.x.cluster.on` parametri o un gruppo di parametri da cui creare un gruppo di replica Valkey o Redis OSS (modalità `default.redis6.x.cluster.on` cluster abilitata). Per ulteriori informazioni, consulta [Modifiche ai parametri di Redis OSS 6.x](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
**--engine**
redis
**--engine-version**
3.2.4
**--num-node-groups**
Il numero di gruppi di nodi in questo gruppo di replica. I valori validi sono compresi tra 1 e 500.
Il node/shard limite può essere aumentato fino a un massimo di 500 per cluster. Per richiedere un aumento dei limiti, consulta [AWS Limite del servizio](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e seleziona il tipo di limite “nodi per cluster per tipo di istanza”.
**--replicas-per-node-group**
Il numero di nodi di replica in ogni gruppo di nodi. I valori validi sono compresi tra 0 e 5.
**--network-type**
`ipv4`, `ipv` o `dual-stack`. Se scegli dual-stack, devi impostare il parametro `--IpDiscovery` su `ipv4` o `ipv6`.
Se desideri abilitare la crittografia dei dati in transito o dei dati inattivi su questo gruppo di replica, aggiungi uno o entrambi i parametri `--transit-encryption-enabled` o `--at-rest-encryption-enabled` e soddisfa le seguenti condizioni.
+ Il gruppo di replica deve eseguire Redis OSS versione 3.2.6 o 4.0.10.
+ Il gruppo di replica deve essere creato in un Amazon VPC.
+ Devi anche includere il parametro `--cache-subnet-group`.
+ Deve anche includere il parametro `--auth-token` con il valore stringa specificato dal cliente per il token AUTH (password) necessario per eseguire operazioni su questo gruppo di replica.
La seguente operazione crea il gruppo di replica Valkey o Redis OSS (modalità cluster enabled) con tre nodi groups/shards (--num-node-groups), ciascuno `sample-repl-group` con tre nodi, una replica primaria e due di lettura (--). replicas-per-node-group
Per Linux, macOS o 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>
```
Per 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>
```
Il comando precedente genera il seguente output.
```
{
"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": {}
}
}
```
Quando si crea un gruppo di replica Valkey o Redis OSS (modalità cluster enabled) da zero, è possibile configurare ogni shard del cluster utilizzando il `--node-group-configuration` parametro come mostrato nell'esempio seguente che configura due gruppi di nodi (Console: shards). La prima partizione dispone di due nodi, un nodo primario e una replica di lettura. La seconda partizione dispone di tre nodi, un nodo primario e due repliche di lettura.
**--node-group-configuration**
La configurazione per ogni gruppo di nodi. Il parametro `--node-group-configuration` è costituito dai seguenti campi:
+ `PrimaryAvailabilityZone` - La zona di disponibilità in cui si trova il nodo primario di questo gruppo di nodi. Se questo parametro viene omesso, ElastiCache sceglie la zona di disponibilità per il nodo primario.
**Esempio:** us-west-2a.
+ `ReplicaAvailabilityZones` - Un elenco separato da virgole di zone di disponibilità in cui si trovano le repliche di lettura. Il numero di zone di disponibilità in questo elenco deve corrispondere al valore di `ReplicaCount`. Se questo parametro viene omesso, ElastiCache sceglie le zone di disponibilità per i nodi di replica.
**Esempio:** "us-west-2a,us-west-2b,us-west-2c"
+ `ReplicaCount` : Il numero di nodi di replica in questo gruppo di nodi.
+ `Slots` - Una stringa che specifica il keyspace per il gruppo di nodi. Il formato della stringa è `startKey-endKey`. Se questo parametro viene omesso, ElastiCache alloca le chiavi in modo equo tra i gruppi di nodi.
**Esempio:** "0-4999"
La seguente operazione crea il gruppo di replica Valkey o Redis OSS (modalità cluster enabled) `new-group` con due gruppi di nodi/shard (). `--num-node-groups` A differenza dell'esempio precedente, ogni gruppo di nodi è configurato in modo diverso rispetto all'altro gruppo di nodi (`--node-group-configuration`).
Per Linux, macOS o 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'"
```
Per 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'"
```
L'operazione precedente genera il seguente output.
```
{
"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": {}
}
}
```
Per ulteriori informazioni e parametri che potresti voler utilizzare, consulta l'argomento. AWS CLI [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
## Creazione da zero di un gruppo di replica in Valkey o Redis OSS (Cluster Mode Enabled) (API) ElastiCache
La procedura seguente crea un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) utilizzando l'API. ElastiCache
Quando si crea un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) partendo da zero, si crea il gruppo di replica e tutti i relativi nodi con una singola chiamata all'operazione API. ElastiCache `CreateReplicationGroup` Includi i seguenti parametri.
**ReplicationGroupId**
Il nome del gruppo di replica che stai creando.
I vincoli di denominazione dei gruppi di replica Valkey o Redis OSS (abilitata in modalità cluster) sono i seguenti:
+ Devono contenere da 1 a 40 caratteri alfanumerici o trattini.
+ Devono iniziare con una lettera.
+ Non possono contenere due trattini consecutivi.
+ Non possono terminare con un trattino.
**ReplicationGroupDescription**
Descrizione del gruppo di replica.
**NumNodeGroups**
Il numero di gruppi di nodi che deve essere creato con questo gruppo di replica. I valori validi sono compresi tra 1 e 500.
**ReplicasPerNodeGroup**
Il numero di nodi di replica in ogni gruppo di nodi. I valori validi sono compresi tra 1 e 5.
**NodeGroupConfiguration**
La configurazione per ogni gruppo di nodi. Il parametro `NodeGroupConfiguration` è costituito dai seguenti campi:
+ `PrimaryAvailabilityZone` - La zona di disponibilità in cui si trova il nodo primario di questo gruppo di nodi. Se questo parametro viene omesso, ElastiCache sceglie la zona di disponibilità per il nodo primario.
**Esempio:** us-west-2a.
+ `ReplicaAvailabilityZones` - Un elenco di zone di disponibilità in cui si trovano le repliche di lettura. Il numero di zone di disponibilità in questo elenco deve corrispondere al valore di `ReplicaCount`. Se questo parametro viene omesso, ElastiCache sceglie le zone di disponibilità per i nodi di replica.
+ `ReplicaCount` : Il numero di nodi di replica in questo gruppo di nodi.
+ `Slots` - Una stringa che specifica il keyspace per il gruppo di nodi. Il formato della stringa è `startKey-endKey`. Se questo parametro viene omesso, ElastiCache alloca le chiavi in modo equo tra i gruppi di nodi.
**Esempio:** "0-4999"
**CacheNodeType**
Il tipo di nodo per ogni nodo nel gruppo di replica.
ElastiCache supporta i seguenti tipi di nodi. In generale, le generazioni attuali offrono più memoria e più potenza di elaborazione a un costo inferiore rispetto ai prodotti omologi della generazione precedente.
Per ulteriori informazioni sui dettagli delle prestazioni per ogni tipo di nodo, consulta [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Impostare questo parametro se si utilizza un tipo di nodo r6gd. Se non si desidera il tiering di dati, impostare `--no-data-tiering-enabled`. Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
**CacheParameterGroup**
Specificare il gruppo di `default.redis6.x.cluster.on` parametri o un gruppo di parametri da cui creare un gruppo di replica Valkey o Redis OSS (modalità `default.redis6.x.cluster.on` cluster abilitata). Per ulteriori informazioni, consulta [Modifiche ai parametri di Redis OSS 6.x](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
**--network-type**
`ipv4`, `ipv` o `dual-stack`. Se scegli dual-stack, devi impostare il parametro `--IpDiscovery` su `ipv4` o `ipv6`.
**Motore**
redis
**EngineVersion**
6.0
Se desideri abilitare la crittografia dei dati in transito o dei dati inattivi su questo gruppo di replica, aggiungi uno o entrambi i parametri `TransitEncryptionEnabled=true` o `AtRestEncryptionEnabled=true` e soddisfa le seguenti condizioni.
+ Il gruppo di replica deve eseguire Redis OSS versione 3.2.6 o 4.0.10.
+ Il gruppo di replica deve essere creato in un Amazon VPC.
+ Devi anche includere il parametro `CacheSubnetGroup`.
+ Deve anche includere il parametro `AuthToken` con il valore stringa specificato dal cliente per il token AUTH (password) necessario per eseguire operazioni su questo gruppo di replica.
Le interruzioni di riga vengono aggiunte per facilitare la lettura.
```
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=
```
Per ulteriori informazioni e parametri che potresti voler utilizzare, consulta l'argomento API. ElastiCache [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
# Visualizzazione dei dettagli del gruppo di replica
A volte potrebbe essere necessario visualizzare i dettagli di un gruppo di replica. Puoi usare la ElastiCache console, il AWS CLI for ElastiCache o l' ElastiCache API. Il processo della console è diverso per Valkey o Redis OSS (modalità cluster disabilitata) e Valkey o Redis OSS (modalità cluster abilitata).
**Contents**
+ [Visualizzazione di un Valkey o Redis OSS (modalità cluster disabilitata) con repliche](Replication.ViewDetails.Redis.md)
+ [Utilizzo della console ElastiCache](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CON)
+ [Utilizzo del AWS CLI](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CLI)
+ [Utilizzo dell'API ElastiCache](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.API)
+ [Visualizzazione di un gruppo di replica: Valkey o Redis OSS (modalità cluster abilitata)](Replication.ViewDetails.RedisCluster.md)
+ [Utilizzo della console ElastiCache](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CON)
+ [Utilizzando il AWS CLI](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CLI)
+ [Utilizzo dell'API ElastiCache](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.API)
+ [Visualizzazione dei dettagli di un gruppo di replica (AWS CLI)](Replication.ViewDetails.CLI.md)
+ [Visualizzazione dei dettagli di un gruppo di replica (ElastiCache API)](Replication.ViewDetails.API.md)
# Visualizzazione di un Valkey o Redis OSS (modalità cluster disabilitata) con repliche
È possibile visualizzare i dettagli di un cluster Valkey o Redis OSS (modalità cluster disabilitata) con repliche (API/CLI: *gruppo di replica*) utilizzando la ElastiCache console, il for o l'API. AWS CLI ElastiCache ElastiCache
**Contents**
+ [Utilizzo della console ElastiCache](#Replication.ViewDetails.Redis.CON)
+ [Utilizzo del AWS CLI](#Replication.ViewDetails.Redis.CLI)
+ [Utilizzo dell'API ElastiCache](#Replication.ViewDetails.Redis.API)
## Visualizzazione di un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) (console)
Per visualizzare i dettagli di un cluster Valkey o Redis OSS (modalità cluster disabilitata) con repliche utilizzando la ElastiCache console, consulta l'argomento. [Visualizzazione dei dettagli di Valkey o Redis OSS (modalità cluster disabilitata) (console)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.Redis)
## Visualizzazione di un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) ()AWS CLI
Per un AWS CLI esempio che visualizza i dettagli di un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata), vedere. [Visualizzazione dei dettagli di un gruppo di replica (AWS CLI)](Replication.ViewDetails.CLI.md)
## Visualizzazione di un gruppo di replica (API) Valkey o Redis OSS (modalità cluster disabilitata) ElastiCache
Per un esempio di ElastiCache API che mostra i dettagli di un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata), consulta. [Visualizzazione dei dettagli di un gruppo di replica (ElastiCache API)](Replication.ViewDetails.API.md)
# Visualizzazione di un gruppo di replica: Valkey o Redis OSS (modalità cluster abilitata)
## Visualizzazione di un cluster Valkey o Redis OSS (Cluster Mode Enabled) (console)
Per visualizzare i dettagli di un cluster Valkey o Redis OSS (modalità cluster abilitata) utilizzando la ElastiCache console, vedere. [Visualizzazione dei dettagli per un cluster Valkey o Redis OSS (Cluster Mode Enabled) (Console)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.RedisCluster)
## Visualizzazione di un cluster Valkey o Redis OSS (Cluster Mode Enabled) ()AWS CLI
Per un esempio ElastiCache CLI che mostra i dettagli di un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata), vedere. [Visualizzazione dei dettagli di un gruppo di replica (AWS CLI)](Replication.ViewDetails.CLI.md)
## Visualizzazione di un cluster (API) Valkey o Redis OSS (Cluster Mode Enabled) ElastiCache
Per un esempio di ElastiCache API che mostra i dettagli di un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata), consulta. [Visualizzazione dei dettagli di un gruppo di replica (ElastiCache API)](Replication.ViewDetails.API.md)
# Visualizzazione dei dettagli di un gruppo di replica (AWS CLI)
È possibile visualizzare i dettagli di un gruppo di replica utilizzando il AWS CLI `describe-replication-groups` comando. Utilizza i seguenti parametri opzionali per perfezionare l'elenco. Se si omettono i parametri, vengono restituiti i dettagli per un massimo di 100 gruppi di replica.
**Parametri facoltativi**
+ `--replication-group-id` - Utilizza questo parametro per elencare i dettagli di un gruppo di replica specifico. Se il gruppo di replica specificato dispone di più gruppi di nodi, i risultati vengono restituiti raggruppati per gruppo di nodi.
+ `--max-items` - Utilizza questo parametro per limitare il numero di gruppi di replica elencati. Il valore di `--max-items` non può essere minore di 20 o maggiore di 100.
**Example**
Il codice seguente consente di elencare i dettagli per un massimo di 100 gruppi di replica.
```
aws elasticache describe-replication-groups
```
Il codice seguente consente di elencare i dettagli per `sample-repl-group`.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
Il codice seguente consente di elencare i dettagli per `sample-repl-group`.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
Il codice seguente consente di elencare i dettagli per un massimo di 25 gruppi di replica.
```
aws elasticache describe-replication-groups --max-items 25
```
L'aspetto dell'output di questa operazione è simile al seguente (in formato JSON).
```
{
"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
}
]
}
```
Per ulteriori informazioni, consultate l' ElastiCache argomento AWS CLI [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) per.
# Visualizzazione dei dettagli di un gruppo di replica (ElastiCache API)
È possibile visualizzare i dettagli di una replica utilizzando l' AWS CLI `DescribeReplicationGroups`operazione. Utilizza i seguenti parametri opzionali per perfezionare l'elenco. Se si omettono i parametri, vengono restituiti i dettagli per un massimo di 100 gruppi di replica.
**Parametri facoltativi**
+ `ReplicationGroupId` - Utilizza questo parametro per elencare i dettagli di un gruppo di replica specifico. Se il gruppo di replica specificato dispone di più gruppi di nodi, i risultati vengono restituiti raggruppati per gruppo di nodi.
+ `MaxRecords` - Utilizza questo parametro per limitare il numero di gruppi di replica elencati. Il valore di `MaxRecords` non può essere minore di 20 o maggiore di 100. Il valore di default è 100.
**Example**
Il codice seguente consente di elencare i dettagli per un massimo di 100 gruppi di replica.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Il codice seguente consente di elencare i dettagli per `myReplGroup`.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=myReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Il codice seguente consente di elencare i dettagli per un massimo di 25 cluster.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&MaxRecords=25
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, consulta l'argomento di riferimento sull' ElastiCache [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html)API.
# Individuazione di endpoint del gruppo di replica
Un'applicazione può connettersi a qualsiasi nodo in un gruppo di replica, purché disponga dell'endpoint DNS e del numero di porta per tale nodo. A seconda che stiate utilizzando un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) o un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata), sarete interessati a diversi endpoint.
**Valkey o Redis OSS (modalità cluster disabilitata)**
**I cluster Valkey o Redis OSS (modalità cluster disabilitata) con repliche hanno tre tipi di endpoint: l'endpoint *primario, l'endpoint reader e gli endpoint* del nodo.** L'endpoint primario è un nome DNS che viene sempre risolto nel nodo primario nel cluster. L'endpoint primario è immune a modifiche al cluster, ad esempio la promozione di una replica di lettura al ruolo primario. Per attività di scrittura, è preferibile collegare le applicazioni all'endpoint primario.
Un endpoint di lettura dividerà in modo uniforme le connessioni in entrata all'endpoint tra tutte le repliche di lettura in un cluster. ElastiCache Ulteriori fattori come, ad esempio, quando l'applicazione crea le connessioni o il modo in cui l'applicazione riutilizza le connessioni determineranno la distribuzione del traffico. Gli endpoint di lettura mantengono le modifiche ai cluster in tempo reale mano a mano che le repliche vengono aggiunte o rimosse. È possibile collocare le repliche di lettura multiple del cluster ElastiCache for Redis OSS in diverse zone di disponibilità (AZ) per garantire l'elevata AWS disponibilità degli endpoint di lettura.
**Nota**
Un endpoint di lettura non è un servizio di load balancer. Si tratta di un record DNS che si risolverà in un indirizzo IP di uno dei nodi di replica in modo round robin.
Per attività di lettura, le applicazioni possono inoltre connettersi a qualsiasi nodo nel cluster. A differenza dell'endpoint primario, gli endpoint dei nodi vengono risolti in endpoint specifici. Se apporti una modifica al cluster, ad esempio aggiungendo o eliminando una replica, devi aggiornare gli endpoint dei nodi nell'applicazione.
**Valkey o Redis OSS (modalità cluster abilitata)**
I cluster Valkey o Redis OSS (modalità cluster abilitata) con repliche, poiché dispongono di più shard (API/CLI: gruppi di nodi), il che significa che hanno anche più nodi primari, hanno una struttura di endpoint diversa rispetto ai cluster Valkey o Redis OSS (modalità cluster disabilitata). Valkey o Redis OSS (modalità cluster abilitata) dispone di un endpoint di *configurazione che «conosce» tutti gli endpoint* primari e i nodi del cluster. L'applicazione si connette all'endpoint di configurazione. Ogni volta che l'applicazione scrive o legge dall'endpoint di configurazione del cluster, Valkey e Redis OSS, dietro le quinte, determinano a quale shard appartiene la chiave e quale endpoint dello shard utilizzare. Tutto è trasparente all'applicazione.
Puoi trovare gli endpoint per un cluster utilizzando la console, l'o l' ElastiCache API. AWS CLI ElastiCache
**Individuazione di endpoint del gruppo di replica**
Per trovare gli endpoint per il gruppo di replica, consulta uno dei seguenti argomenti:
+ [Ricerca degli endpoint (console) del cluster Valkey o Redis OSS (modalità cluster disabilitata)](Endpoints.md#Endpoints.Find.Redis)
+ [Ricerca degli endpoint per un cluster (console) Valkey o Redis OSS (modalità cluster abilitata)](Endpoints.md#Endpoints.Find.RedisCluster)
+ [Individuazione degli endpoint per i gruppi di replica Valkey o Redis OSS ()AWS CLI](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Ricerca di endpoint per Valkey o Redis OSS Replication Groups (API) ElastiCache](Endpoints.md#Endpoints.Find.API.ReplGroups)
# Modifica di un gruppo di replica
**Vincoli importanti**
Attualmente, ElastiCache supporta modifiche limitate di un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata), ad esempio la modifica della versione del motore, utilizzando l'operazione API (`ModifyReplicationGroup`CLI:). `modify-replication-group` È possibile modificare il numero di shard (gruppi di nodi) in un cluster Valkey o Redis OSS (modalità cluster abilitata) con l'operazione API ([https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html)CLI:). [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) Per ulteriori informazioni, consulta [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md).
Altre modifiche a un cluster Valkey o Redis OSS (modalità cluster abilitata) richiedono la creazione di un cluster con il nuovo cluster che incorpora le modifiche.
È possibile aggiornare i cluster e i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata) e Valkey o Redis OSS (modalità cluster abilitata) a versioni più recenti del motore. Tuttavia, non puoi eseguire il downgrade alle versioni precedenti del motore se non eliminando il cluster esistente o il gruppo di replica e creandolo di nuovo. Per ulteriori informazioni, consulta [Gestione delle versioni per ElastiCache](VersionManagement.md).
È possibile aggiornare un cluster esistente ElastiCache per Valkey o Redis OSS che utilizza la modalità cluster disabilitata per utilizzare la modalità cluster abilitata, utilizzando la console, l'[ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)API o il comando [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)CLI, come mostrato nell'esempio seguente. Oppure, puoi seguire la procedura descritta in [Modifica della modalità cluster.](modify-cluster-mode.md)
È possibile modificare le impostazioni di un cluster Valkey o Redis OSS (modalità cluster disabilitata) utilizzando la ElastiCache console, l'o l' AWS CLI API. ElastiCache Attualmente, ElastiCache supporta un numero limitato di modifiche su un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata). Altre modifiche richiedono la creazione di un backup del gruppo di replica corrente e l'utilizzo di tale backup per avviare un nuovo gruppo di replica Valkey o Redis OSS (abilitato in modalità cluster).
**Topics**
+ [Utilizzando il Console di gestione AWS](#Replication.Modify.CON)
+ [Utilizzo del AWS CLI](#Replication.Modify.CLI)
+ [Utilizzo dell'API ElastiCache](#Replication.Modify.API)
## Utilizzando il Console di gestione AWS
Per modificare un cluster Valkey o Redis OSS (modalità cluster disabilitata), vedere. [Modifica di un cluster ElastiCache](Clusters.Modify.md)
## Utilizzo del AWS CLI
Di seguito sono AWS CLI riportati alcuni esempi del `modify-replication-group` comando. Puoi utilizzare lo stesso comando per apportare altre modifiche a un gruppo di replica.
**Abilita Multi-AZ su un gruppo di replica Valkey o Redis OSS esistente:**
Per Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--multi-az-enabled = true
```
Per Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--multi-az-enabled
```
**Modifica della modalità cluster da disabilitata ad abilitata:**
Per modificare la modalità cluster da *disabilitata* ad *abilitata*, è necessario innanzitutto impostare la modalità cluster su *compatibile*. La modalità compatibile consente ai client Valkey o Redis OSS di connettersi utilizzando la modalità cluster abilitata o disabilitata. *Dopo aver migrato tutti i client Valkey o Redis OSS per utilizzare la modalità cluster abilitata, è possibile completare la configurazione della modalità cluster e impostare la modalità cluster su abilitata.*
Per Linux, macOS o Unix:
Imposta la modalità cluster su *compatibile*.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cache-parameter-group-name myParameterGroupName \
--cluster-mode compatible
```
Imposta la modalità cluster su *abilitata*.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cluster-mode enabled
```
Per Windows:
Imposta la modalità cluster su *compatibile*.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cache-parameter-group-name myParameterGroupName ^
--cluster-mode compatible
```
Imposta la modalità cluster su *abilitata*.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cluster-mode enabled
```
Per ulteriori informazioni sul AWS CLI `modify-replication-group` comando, consulta [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) la sezione [Modifica della modalità cluster]() nella Guida *ElastiCache per l'utente di Redis OSS*.
## Utilizzo dell'API ElastiCache
La seguente operazione ElastiCache API abilita Multi-AZ su un gruppo di replica Valkey o Redis OSS esistente. Puoi utilizzare la stessa operazione per apportare altre modifiche a un gruppo di replica.
```
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=
```
Per ulteriori informazioni sul funzionamento dell' ElastiCache API`ModifyReplicationGroup`, vedere. [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
# Eliminazione di un gruppo di replica
Se non hai più bisogno dei cluster con repliche (chiamati *gruppi di replica* nell'API/CLI), puoi eliminarli. Quando si elimina un gruppo di replica, ElastiCache vengono eliminati tutti i nodi di quel gruppo.
Dopo che è stata avviata, questa operazione non può essere interrotta o annullata.
**avvertimento**
Quando si elimina un cluster ElastiCache For Redis OSS, le istantanee manuali vengono conservate. Hai anche la possibilità di creare uno snapshot finale prima che il cluster venga eliminato. Gli snapshot di cache automatici non vengono conservati.
`CreateSnapshot`è necessaria l'autorizzazione per creare un'istantanea finale. Senza questa autorizzazione, la chiamata API avrà esito negativo con un'`Access Denied`eccezione.
## Eliminazione di un gruppo di replica (console)
Per eliminare un cluster che dispone di repliche, consulta [Eliminazione di un cluster in ElastiCache](Clusters.Delete.md).
## Eliminazione di un gruppo di replica (AWS CLI)
Utilizza il comando [delete-replication-group](https://docs.aws.amazon.com/AmazonElastiCache/latest/CommandLineReference/CLIReference-cmd-DeleteReplicationGroup.html) per eliminare un gruppo di replica.
```
aws elasticache delete-replication-group --replication-group-id my-repgroup
```
Ti viene chiesto di confermare la tua decisione. Immetti *y* (sì) per avviare l'operazione immediatamente. Una volta avviato, il processo è irreversibile.
```
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
```
## Eliminazione di un gruppo di replica (API) ElastiCache
Chiama [DeleteReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteReplicationGroup.html) con il parametro `ReplicationGroup`.
**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=
```
**Nota**
Se imposti il parametro `RetainPrimaryCluster` su `true`, tutte le repliche di lettura verranno eliminate, ma il cluster primario verrà mantenuto.
# Modifica del numero di repliche
È possibile aumentare o diminuire dinamicamente il numero di repliche di lettura nel gruppo di replica Valkey o Redis OSS utilizzando l'API Console di gestione AWS, the AWS CLI o. ElastiCache Se il gruppo di replica è un gruppo di replica Valkey o Redis OSS (abilitato alla modalità cluster), è possibile scegliere quali shard (gruppi di nodi) aumentare o diminuire il numero di repliche.
Per modificare dinamicamente il numero di repliche nel gruppo di replica, scegliete l'operazione dalla tabella seguente che si adatta alla vostra situazione.
| Per | Per Valkey o Redis OSS (modalità cluster abilitata) | Per Valkey o Redis OSS (modalità cluster disabilitata) |
| --- | --- | --- |
| Aggiungere repliche | [Incremento del numero di repliche in uno shard](increase-replica-count.md) | [Incremento del numero di repliche in uno shard](increase-replica-count.md) [Aggiungere una replica di lettura per Valkey o Redis OSS (modalità cluster disabilitata)](Replication.AddReadReplica.md) |
| Eliminare repliche | [Riduzione del numero di repliche in uno shard](decrease-replica-count.md) | [Riduzione del numero di repliche in uno shard](decrease-replica-count.md) [Eliminazione di una replica di lettura per Valkey o Redis OSS (modalità cluster disabilitata)](Replication.RemoveReadReplica.md) |
# Incremento del numero di repliche in uno shard
È possibile aumentare il numero di repliche in uno shard Valkey o Redis OSS (modalità cluster abilitata) o in un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) fino a un massimo di cinque. È possibile farlo utilizzando l', il Console di gestione AWS o l'API. AWS CLI ElastiCache
**Topics**
+ [Usando il Console di gestione AWS](#increase-replica-count-con)
+ [Utilizzando il AWS CLI](#increase-replica-count-cli)
+ [Utilizzo dell'API ElastiCache](#increase-replica-count-api)
## Usando il Console di gestione AWS
La procedura seguente utilizza la console per aumentare il numero di repliche in un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata).
**Per aumentare il numero di repliche negli shard**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nel riquadro di navigazione, scegli **Valkey** o **Redis OSS**, quindi scegli il nome del gruppo di replica a cui desideri aggiungere le repliche.
1. Scegliere la casella per ogni shard cui si desidera aggiungere repliche.
1. Scegliere **Add replicas (Aggiungi repliche)**.
1. Completare la pagina **Add Replicas to Shards (Aggiungi repliche agli shard)**:
+ Per **New number of replicas/shard (Nuovo numero di repliche/shard)**, immettere il numero di repliche che devono avere tutti gli shard selezionati. Questo valore deve essere maggiore o uguale di **Current Number of Replicas per shard (Numero attuale di repliche per shard)** e minore o uguale a cinque. Si consiglia come minimo due repliche.
+ Per **Zone di disponibilità**, scegli **Nessuna preferenza** per aver ElastiCache scelto una zona di disponibilità per ogni nuova replica oppure **Specificare zone di disponibilità per scegliere una zona di disponibilità** per ogni nuova replica.
Se si sceglie **Specify Availability Zones (Specifica zone di disponibilità)**, per ogni nuova replica specificare una zona di disponibilità utilizzando l'elenco.
1. Scegliere **Add (Aggiungi)** per aggiungere le repliche o **Cancel (Annulla)** per annullare l'operazione.
## Utilizzando il AWS CLI
Per aumentare il numero di repliche in uno shard Valkey o Redis OSS, utilizzate il `increase-replica-count` comando con i seguenti parametri:
+ `--replication-group-id` - Obbligatorio Identifica il gruppo di replica in cui incrementare il numero di repliche.
+ `--apply-immediately` o `--no-apply-immediately` - Obbligatorio. Specifica se aumentare il conteggio di repliche immediatamente (`--apply-immediately`) o alla successiva finestra di manutenzione (`--no-apply-immediately`). Attualmente, `--no-apply-immediately` non è supportato.
+ `--new-replica-count` : Opzionale. Specifica il numero di nodi di replica desiderati, fino a un massimo di cinque. Utilizzate questo parametro per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata) in cui è presente un solo gruppo di nodi o gruppo Valkey o Redis OSS (modalità cluster abilitata) o dove desiderate che tutti i gruppi di nodi abbiano lo stesso numero di repliche. Se questo valore non è maggiore del numero corrente di repliche nel gruppo di nodi, la chiamata non riesce con un'eccezione.
+ `--replica-configuration` : Opzionale. Consente di impostare il numero di repliche e zone di disponibilità per ogni gruppo di nodi in maniera indipendente. Utilizzate questo parametro per i gruppi Valkey o Redis OSS (modalità cluster abilitata) in cui desiderate configurare ogni gruppo di nodi in modo indipendente.
`--replica-configuration` dispone di tre membri opzionali:
+ `NodeGroupId` - L'ID di quattro cifre del gruppo di nodi che stai configurando. Per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata), l'ID dello shard è sempre. `0001` Per trovare l'ID di un gruppo di nodi (shard) Valkey o Redis OSS (modalità cluster abilitata), vedi. [Ricerca dell'ID di uno shard](Shards.md#shard-find-id)
+ `NewReplicaCount` - Il numero di repliche desiderato in questo gruppo di nodi al termine di questa operazione. Il valore deve essere maggiore del numero corrente di repliche, fino a un massimo di cinque. Se questo valore non è maggiore del numero corrente di repliche nel gruppo di nodi, la chiamata non riesce con un'eccezione.
+ `PreferredAvailabilityZones` - Un elenco di stringhe `PreferredAvailabilityZone` che specifica in quali zone di disponibilità si devono trovare i nodi del gruppo di replica. Il numero di valori `PreferredAvailabilityZone` deve essere uguale al valore di `NewReplicaCount` più 1 per tenere conto del nodo primario. Se questo membro di `--replica-configuration` viene omesso, ElastiCache per Redis OSS sceglie la zona di disponibilità per ciascuna delle nuove repliche.
**Importante**
Nella chiamata è necessario includere il parametro `--new-replica-count` o `--replica-configuration`, ma non entrambi.
**Example**
Nell'esempio seguente il numero di repliche nel gruppo di replica `sample-repl-group` viene incrementato a tre. Al termine dell'esempio, ogni gruppo di nodi contiene tre repliche. Questo numero si applica sia che si tratti di un gruppo Valkey o Redis OSS (modalità cluster disabilitata) con un gruppo di nodi singolo o di un gruppo Valkey o Redis OSS (modalità cluster abilitata) con più gruppi di nodi.
Per Linux, macOS o Unix:
```
aws elasticache increase-replica-count \
--replication-group-id sample-repl-group \
--new-replica-count 3 \
--apply-immediately
```
Per Windows:
```
aws elasticache increase-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 3 ^
--apply-immediately
```
Nell'esempio seguente il numero di repliche nel gruppo di replica `sample-repl-group` viene incrementato al valore specificato per i due gruppi di nodi specificati. Dato che esistono più gruppi di nodi, si tratta di un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata). Durante la specifica del `PreferredAvailabilityZones` opzionale, il numero di zone di disponibilità elencate deve essere uguale al valore di `NewReplicaCount` più uno. Questo approccio consente di tenere conto del nodo primario per il gruppo identificato da `NodeGroupId`.
Per Linux, macOS o 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
```
Per 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
```
Per ulteriori informazioni sull'aumento del numero di repliche utilizzando la CLI, [increase-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/increase-replica-count.html)consulta * ElastiCache Amazon Command* Line Reference.
## Utilizzo dell'API ElastiCache
Per aumentare il numero di repliche in uno shard Valkey o Redis OSS, utilizzate l'`IncreaseReplicaCount`azione con i seguenti parametri:
+ `ReplicationGroupId` - Obbligatorio Identifica il gruppo di replica in cui incrementare il numero di repliche.
+ `ApplyImmediately` – Obbligatorio Specifica se aumentare il conteggio di repliche immediatamente (`ApplyImmediately=True`) o alla successiva finestra di manutenzione (`ApplyImmediately=False`). Attualmente, `ApplyImmediately=False` non è supportato.
+ `NewReplicaCount` : Opzionale. Specifica il numero di nodi di replica desiderati, fino a un massimo di cinque. Utilizzate questo parametro per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata) in cui è presente un solo gruppo di nodi o per i gruppi Valkey o Redis OSS (modalità cluster abilitata) in cui desiderate che tutti i gruppi di nodi abbiano lo stesso numero di repliche. Se questo valore non è maggiore del numero corrente di repliche nel gruppo di nodi, la chiamata non riesce con un'eccezione.
+ `ReplicaConfiguration` : Opzionale. Consente di impostare il numero di repliche e zone di disponibilità per ogni gruppo di nodi in maniera indipendente. Utilizzate questo parametro per i gruppi Valkey o Redis OSS (modalità cluster abilitata) in cui desiderate configurare ogni gruppo di nodi in modo indipendente.
`ReplicaConfiguraion` dispone di tre membri opzionali:
+ `NodeGroupId` - L'ID di quattro cifre del gruppo di nodi che si sta configurando. Per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata), l'ID del gruppo di nodi (shard) è sempre. `0001` Per trovare l'ID di un gruppo di nodi (shard) Valkey o Redis OSS (modalità cluster abilitata), vedi. [Ricerca dell'ID di uno shard](Shards.md#shard-find-id)
+ `NewReplicaCount` - Il numero di repliche desiderato in questo gruppo di nodi al termine di questa operazione. Il valore deve essere maggiore del numero corrente di repliche e non superiore a cinque. Se questo valore non è maggiore del numero corrente di repliche nel gruppo di nodi, la chiamata non riesce con un'eccezione.
+ `PreferredAvailabilityZones` - Un elenco di stringhe `PreferredAvailabilityZone` che specifica in quali zone di disponibilità si devono trovare i nodi del gruppo di replica. Il numero di valori `PreferredAvailabilityZone` deve essere uguale al valore di `NewReplicaCount` più 1 per tenere conto del nodo primario. Se questo membro di `ReplicaConfiguration` viene omesso, ElastiCache per Redis OSS sceglie la zona di disponibilità per ciascuna delle nuove repliche.
**Importante**
Nella chiamata è necessario includere il parametro `NewReplicaCount` o `ReplicaConfiguration`, ma non entrambi.
**Example**
Nell'esempio seguente il numero di repliche nel gruppo di replica `sample-repl-group` viene incrementato a tre. Al termine dell'esempio, ogni gruppo di nodi contiene tre repliche. Questo numero si applica sia che si tratti di un gruppo Valkey o Redis OSS (modalità cluster disabilitata) con un gruppo di nodi singolo o di un gruppo Valkey o Redis OSS (modalità cluster abilitata) con più gruppi di nodi.
```
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=
```
Nell'esempio seguente il numero di repliche nel gruppo di replica `sample-repl-group` viene incrementato al valore specificato per i due gruppi di nodi specificati. Dato che esistono più gruppi di nodi, si tratta di un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata). Durante la specifica del `PreferredAvailabilityZones` opzionale, il numero di zone di disponibilità elencate deve essere uguale al valore di `NewReplicaCount` più uno. Questo approccio consente di tenere conto del nodo primario per il gruppo identificato da `NodeGroupId`.
```
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=
```
Per ulteriori informazioni sull'aumento del numero di repliche utilizzando l'API, consulta [IncreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_IncreaseReplicaCount.html)*Amazon ElastiCache API Reference*.
# Riduzione del numero di repliche in uno shard
È possibile ridurre il numero di repliche in uno shard per Valkey o Redis OSS (modalità cluster abilitata) o in un gruppo di replica per Valkey o Redis OSS (modalità cluster disabilitata):
+ Per Valkey o Redis OSS (modalità cluster disabilitata), è possibile ridurre il numero di repliche a una se Multi-AZ è abilitato e a zero se non è abilitato.
+ Per Valkey o Redis OSS (modalità cluster abilitata), è possibile ridurre il numero di repliche a zero. Tuttavia, non puoi eseguire il failover in una replica se il nodo primario non riesce.
È possibile utilizzare Console di gestione AWS, the AWS CLI o l' ElastiCache API per ridurre il numero di repliche in un gruppo di nodi (shard) o in un gruppo di replica.
**Topics**
+ [Utilizzando il Console di gestione AWS](#decrease-replica-count-con)
+ [Utilizzando il AWS CLI](#decrease-replica-count-cli)
+ [Utilizzo dell'API ElastiCache](#decrease-replica-count-api)
## Utilizzando il Console di gestione AWS
La procedura seguente utilizza la console per ridurre il numero di repliche in un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata).
**Per ridurre il numero di repliche in uno shard Valkey o Redis OSS**
1. Accedi a Console di gestione AWS e apri la console all'indirizzo. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nel pannello di navigazione, scegli **Valkey** o **Redis OSS**, quindi scegli il nome del gruppo di replica da cui desideri eliminare le repliche.
1. Scegliere la casella per ogni shard da cui si desidera rimuovere un nodo di replica.
1. Scegliere **Delete replicas (Elimina repliche)**.
1. Completare la pagina **Delete Replicas from Shards (Elimina repliche dagli shard)**:
1. Per **New number of replicas/shard (Nuovo numero di repliche/shard)**, immettere il numero di repliche specificato per gli shard selezionati. Questo numero deve essere maggiore o uguale a 1. Si consiglia almeno due repliche per shard.
1. Scegliere **Delete (Elimina)** per eliminare le repliche o **Cancel (Annulla)** per annullare l'operazione.
**Importante**
Se non specificate i nodi di replica da eliminare, ElastiCache per Redis OSS vengono selezionati automaticamente i nodi di replica da eliminare. Nel farlo, ElastiCache For Redis OSS tenta di mantenere l'architettura Multi-AZ per il gruppo di replica, seguita da conservare le repliche con un ritardo di replica minimo con il primario.
Non è possibile eliminare il primario o nodi primari in un gruppo di replica. Se si specifica un nodo primario per l'eliminazione, l'operazione non riesce e viene restituito un errore che indica che il nodo primario è stato selezionato per l'eliminazione.
## Utilizzando il AWS CLI
Per ridurre il numero di repliche in uno shard Valkey o Redis OSS, utilizzate il `decrease-replica-count` comando con i seguenti parametri:
+ `--replication-group-id` - Obbligatorio Identifica il gruppo di replica in cui ridurre il numero di repliche.
+ `--apply-immediately` o `--no-apply-immediately` : Obbligatorio. Specifica se ridurre il conteggio di repliche immediatamente (`--apply-immediately`) o alla successiva finestra di manutenzione (`--no-apply-immediately`). Attualmente, `--no-apply-immediately` non è supportato.
+ `--new-replica-count` : Opzionale. Specifica il numero di nodi di replica desiderato. Il valore di `--new-replica-count` deve essere un valore valido minore del numero corrente di repliche nei gruppi di nodi. Per valori consentiti minimi, consulta [Riduzione del numero di repliche in uno shard](#decrease-replica-count). Se il valore di `--new-replica-count` non soddisfa questo requisiti, la chiamata non riesce.
+ `--replicas-to-remove` : Opzionale. Contiene un elenco di nodi che IDs specifica i nodi di replica da rimuovere.
+ `--replica-configuration` : Opzionale. Consente di impostare il numero di repliche e zone di disponibilità per ogni gruppo di nodi in maniera indipendente. Utilizzate questo parametro per i gruppi Valkey o Redis OSS (modalità cluster abilitata) in cui desiderate configurare ogni gruppo di nodi in modo indipendente.
`--replica-configuration` dispone di tre membri opzionali:
+ `NodeGroupId` - L'ID di quattro cifre del gruppo di nodi che stai configurando. Per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata), l'ID dello shard è sempre. `0001` Per trovare l'ID di un gruppo di nodi (shard) Valkey o Redis OSS (modalità cluster abilitata), vedi. [Ricerca dell'ID di uno shard](Shards.md#shard-find-id)
+ `NewReplicaCount` - Un parametro facoltativo che specifica il numero di nodi di replica desiderati. Il valore di `NewReplicaCount` deve essere un valore valido minore del numero corrente di repliche nei gruppi di nodi. Per valori consentiti minimi, consulta [Riduzione del numero di repliche in uno shard](#decrease-replica-count). Se il valore di `NewReplicaCount` non soddisfa questo requisiti, la chiamata non riesce.
+ `PreferredAvailabilityZones` - Un elenco di stringhe `PreferredAvailabilityZone` che specifica in quali zone di disponibilità si trovano i nodi del gruppo di replica. Il numero di valori `PreferredAvailabilityZone` deve essere uguale al valore di `NewReplicaCount` più 1 per tenere conto del nodo primario. Se questo membro di `--replica-configuration` viene omesso, ElastiCache per Redis OSS sceglie la zona di disponibilità per ciascuna delle nuove repliche.
**Importante**
Devi includere solo uno dei parametri `--new-replica-count`, `--replicas-to-remove` o `--replica-configuration`.
**Example**
L'esempio seguente utilizza `--new-replica-count` per ridurre a uno il numero di repliche nel gruppo di replica `sample-repl-group`. Al termine dell'esempio, ogni gruppo di nodi contiene una sola replica. Questo numero si applica sia che si tratti di un gruppo Valkey o Redis OSS (modalità cluster disabilitata) con un gruppo di nodi singolo o di un gruppo Valkey o Redis OSS (modalità cluster abilitata) con più gruppi di nodi.
Per Linux, macOS o Unix:
```
aws elasticache decrease-replica-count
--replication-group-id sample-repl-group \
--new-replica-count 1 \
--apply-immediately
```
Per Windows:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 1 ^
--apply-immediately
```
Nell'esempio seguente il numero di repliche nel gruppo di replica `sample-repl-group` viene ridotto rimuovendo due repliche specificate (`0001` e `0003`) dal gruppo di nodi.
Per Linux, macOS o Unix:
```
aws elasticache decrease-replica-count \
--replication-group-id sample-repl-group \
--replicas-to-remove 0001,0003 \
--apply-immediately
```
Per Windows:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--replicas-to-remove 0001,0003 \
--apply-immediately
```
L'esempio seguente utilizza `--replica-configuration` per ridurre il numero di repliche nel gruppo di replica `sample-repl-group` al valore specificato per i due gruppi di nodi specificati. Dato che esistono più gruppi di nodi, si tratta di un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata). Durante la specifica del `PreferredAvailabilityZones` opzionale, il numero di zone di disponibilità elencate deve essere uguale al valore di `NewReplicaCount` più uno. Questo approccio consente di tenere conto del nodo primario per il gruppo identificato da `NodeGroupId`.
Per Linux, macOS o 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
```
Per 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
```
Per ulteriori informazioni sulla riduzione del numero di repliche utilizzando la CLI, consulta *Amazon ElastiCache * Command Line [decrease-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/decrease-replica-count.html)Reference.
## Utilizzo dell'API ElastiCache
Per ridurre il numero di repliche in uno shard Valkey o Redis OSS, utilizzate l'`DecreaseReplicaCount`azione con i seguenti parametri:
+ `ReplicationGroupId` - Obbligatorio Identifica il gruppo di replica in cui ridurre il numero di repliche.
+ `ApplyImmediately` - Obbligatorio Specifica se ridurre il conteggio di repliche immediatamente (`ApplyImmediately=True`) o alla successiva finestra di manutenzione (`ApplyImmediately=False`). Attualmente, `ApplyImmediately=False` non è supportato.
+ `NewReplicaCount` : Opzionale. Specifica il numero di nodi di replica desiderato. Il valore di `NewReplicaCount` deve essere un valore valido minore del numero corrente di repliche nei gruppi di nodi. Per valori consentiti minimi, consulta [Riduzione del numero di repliche in uno shard](#decrease-replica-count). Se il valore di `--new-replica-count` non soddisfa questo requisiti, la chiamata non riesce.
+ `ReplicasToRemove` : Opzionale. Contiene un elenco di nodi che IDs specifica i nodi di replica da rimuovere.
+ `ReplicaConfiguration` : Opzionale. Contiene un elenco di gruppi di nodi che consentono di impostare il numero di repliche e zone di disponibilità per ogni gruppo di nodi in maniera indipendente. Utilizzate questo parametro per i gruppi Valkey o Redis OSS (modalità cluster abilitata) in cui desiderate configurare ogni gruppo di nodi in modo indipendente.
`ReplicaConfiguraion` dispone di tre membri opzionali:
+ `NodeGroupId` - L'ID di quattro cifre del gruppo di nodi che si sta configurando. Per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata), l'ID del gruppo di nodi è sempre. `0001` Per trovare l'ID di un gruppo di nodi (shard) Valkey o Redis OSS (modalità cluster abilitata), vedi. [Ricerca dell'ID di uno shard](Shards.md#shard-find-id)
+ `NewReplicaCount` - Il numero di repliche desiderato in questo gruppo di nodi al termine di questa operazione. Il valore deve essere inferiore al numero di repliche correnti fino a un minimo di 1 se la funzione Multi-AZ è abilitata o 0 se non è abilitata failover automatico. Se questo valore non è minore del numero corrente di repliche nel gruppo di nodi, la chiamata non riesce con un'eccezione.
+ `PreferredAvailabilityZones` - Un elenco di stringhe `PreferredAvailabilityZone` che specifica in quali zone di disponibilità si trovano i nodi del gruppo di replica. Il numero di valori `PreferredAvailabilityZone` deve essere uguale al valore di `NewReplicaCount` più 1 per tenere conto del nodo primario. Se questo membro di `ReplicaConfiguration` viene omesso, ElastiCache per Redis OSS sceglie la zona di disponibilità per ciascuna delle nuove repliche.
**Importante**
Devi includere solo uno dei parametri `NewReplicaCount`, `ReplicasToRemove` o `ReplicaConfiguration`.
**Example**
L'esempio seguente utilizza `NewReplicaCount` per ridurre a uno il numero di repliche nel gruppo di replica `sample-repl-group`. Al termine dell'esempio, ogni gruppo di nodi contiene una sola replica. Questo numero si applica sia che si tratti di un gruppo Valkey o Redis OSS (modalità cluster disabilitata) con un gruppo di nodi singolo o di un gruppo Valkey o Redis OSS (modalità cluster abilitata) con più gruppi di nodi.
```
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=
```
Nell'esempio seguente il numero di repliche nel gruppo di replica `sample-repl-group` viene ridotto rimuovendo due repliche specificate (`0001` e `0003`) dal gruppo di nodi.
```
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=
```
L'esempio seguente utilizza `ReplicaConfiguration` per ridurre il numero di repliche nel gruppo di replica `sample-repl-group` al valore specificato per i due gruppi di nodi specificati. Dato che esistono più gruppi di nodi, si tratta di un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata). Durante la specifica del `PreferredAvailabilityZones` opzionale, il numero di zone di disponibilità elencate deve essere uguale al valore di `NewReplicaCount` più uno. Questo approccio consente di tenere conto del nodo primario per il gruppo identificato da `NodeGroupId`.
```
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=
```
Per ulteriori informazioni sulla riduzione del numero di repliche utilizzando l'API, consulta [DecreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DecreaseReplicaCount.html)*Amazon ElastiCache API* Reference.
# Aggiungere una replica di lettura per Valkey o Redis OSS (modalità cluster disabilitata)
Le informazioni riportate nel seguente argomento si applicano solo ai gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata).
All'aumentare del traffico di lettura, potrebbe essere necessario distribuire tali letture tra più nodi e ridurre la pressione di lettura su qualsiasi nodo. In questo argomento, puoi scoprire come aggiungere una replica di lettura a un cluster Valkey o Redis OSS (modalità cluster disabilitata).
Un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) può avere un massimo di cinque repliche di lettura. Se tenti di aggiungere una replica di lettura a un gruppo di replica che dispone già di cinque repliche di lettura, l'operazione non riesce.
Per informazioni sull'aggiunta di repliche a un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata), consulta quanto segue:
+ [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md)
+ [Incremento del numero di repliche in uno shard](increase-replica-count.md)
È possibile aggiungere una replica di lettura a un cluster Valkey o Redis OSS (modalità cluster disabilitata) utilizzando la ElastiCache console, l'o l'API. AWS CLI ElastiCache
**Argomenti correlati**
+ [Aggiungere nodi a un ElastiCache cluster](Clusters.AddNode.md)
+ [Aggiunta di una replica di lettura a un gruppo di replica (AWS CLI)](#Replication.AddReadReplica.CLI)
+ [Aggiunta di una replica di lettura a un gruppo di replica utilizzando l'API](#Replication.AddReadReplica.API)
## Aggiunta di una replica di lettura a un gruppo di replica (AWS CLI)
Per aggiungere una replica di lettura a un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata), utilizzate il AWS CLI `create-cache-cluster` comando, con il parametro `--replication-group-id` per specificare a quale gruppo di replica aggiungere il cluster (nodo).
L'esempio seguente consente di creare il cluster `my-read replica` e di aggiungerlo al gruppo di replica `my-replication-group`. I tipi di nodi, i gruppi di parametri, i gruppi di sicurezza, la finestra di manutenzione e altre impostazioni per la replica di lettura sono identiche a quelle di altri nodi in `my-replication-group`.
Per Linux, macOS o Unix:
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-read-replica \
--replication-group-id my-replication-group
```
Per Windows:
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-read-replica ^
--replication-group-id my-replication-group
```
Per ulteriori informazioni sull'aggiunta di una replica di lettura utilizzando la CLI, [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html) consulta * ElastiCache Amazon Command* Line Reference.
## Aggiunta di una replica di lettura a un gruppo di replica utilizzando l'API
Per aggiungere una replica di lettura a un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata), utilizza l' ElastiCache `CreateCacheCluster`operazione, con il parametro `ReplicationGroupId` per specificare a quale gruppo di replica aggiungere il cluster (nodo).
L'esempio seguente consente di creare il cluster `myReadReplica` e di aggiungerlo al gruppo di replica `myReplicationGroup`. I tipi di nodi, i gruppi di parametri, i gruppi di sicurezza, la finestra di manutenzione e altre impostazioni per la replica di lettura sono identiche a quelle di altri nodi `myReplicationGroup`.
```
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=
```
Per ulteriori informazioni sull'aggiunta di una replica di lettura utilizzando l'API, consulta [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html) *Amazon ElastiCache API Reference*.
# Eliminazione di una replica di lettura per Valkey o Redis OSS (modalità cluster disabilitata)
Le informazioni riportate nel seguente argomento si applicano solo ai gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata).
Man mano che il traffico di lettura sul gruppo di replica Valkey o Redis OSS cambia, potresti voler aggiungere o rimuovere le repliche di lettura. La rimozione di un nodo da un gruppo di replica equivale all'eliminazione di un cluster, sebbene esistano delle limitazioni:
+ Non puoi rimuovere il nodo primario da un gruppo di replica. Se desideri eliminare il nodo primario, esegui le seguenti operazioni:
1. Promuovi una replica di lettura al nodo primario. Per ulteriori informazioni sulla promozione di una replica di lettura al nodo primario, consulta [Promozione di una replica di lettura a quella primaria, per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata)](Replication.PromoteReplica.md).
1. Elimina il vecchio nodo primario. Per una limitazione su questo metodo, consulta il punto successivo.
+ Se l'opzione Multi-AZ è abilitata su un gruppo di replica, non puoi rimuovere l'ultima replica di lettura dal gruppo di replica. In questo caso, esegui queste operazioni:
1. Modifica il gruppo di replica disabilitando la funzione Multi-AZ. Per ulteriori informazioni, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
1. Elimina la replica di lettura.
È possibile rimuovere una replica di lettura da un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) utilizzando la ElastiCache console, il for o l'API. AWS CLI ElastiCache ElastiCache
Per istruzioni sull'eliminazione di un cluster da un gruppo di replica Valkey o Redis OSS, vedere quanto segue:
+ [Utilizzando il Console di gestione AWS](Clusters.Delete.md#Clusters.Delete.CON)
+ [Utilizzo di AWS CLI per eliminare un ElastiCache cluster](Clusters.Delete.md#Clusters.Delete.CLI)
+ [Utilizzo dell' ElastiCache API](Clusters.Delete.md#Clusters.Delete.API)
+ [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md)
+ [Riduzione del numero di repliche in uno shard](decrease-replica-count.md)
# Promozione di una replica di lettura a quella primaria, per i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata)
Le informazioni riportate nel seguente argomento si applicano solo ai gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata).
È possibile promuovere una replica di lettura Valkey o Redis OSS (modalità cluster disabilitata) a replica di lettura principale utilizzando l' Console di gestione AWS, l'o l'API. AWS CLI ElastiCache Non puoi promuovere una replica di lettura al primario mentre la funzione Multi-AZ con failover automatico è abilitata sul gruppo di replica . Per promuovere una replica Valkey o Redis OSS (modalità cluster disabilitata) a principale su un gruppo di replica abilitato Multi-AZ, procedi come segue:
1. Modifica il gruppo di replica per disabilitare Multi-AZ (questa operazione non richiede che tutti i cluster siano nella stessa zona di disponibilità). Per ulteriori informazioni, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
1. Promuovere la replica di lettura al nodo primario.
1. Modifica il gruppo di replica per abilitare nuovamente Multi-AZ.
Multi-AZ non è disponibile nei gruppi di replica che eseguono Redis OSS 2.6.13 o versioni precedenti.
## Usando il Console di gestione AWS
La procedura seguente utilizza la console per promuovere un nodo di replica al nodo primario.
**Per promuovere una replica di lettura al nodo primario (console)**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Se la replica che desideri promuovere è membro di un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) in cui Multi-AZ è abilitato, modifica il gruppo di replica per disabilitare Multi-AZ prima di procedere. Per ulteriori informazioni, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
1. Scegliete **Valkey** o **Redis OSS**, quindi dall'elenco dei cluster, scegliete il gruppo di replica che desiderate modificare. Questo gruppo di replica deve eseguire il motore "Redis", non il motore "Clustered Redis"e deve avere due o più nodi.
1. Dall'elenco di nodi, scegliere il nodo di replica che si desidera promuovere al nodo primario, quindi per **Actions (Operazioni)**, scegliere **Promote (Promuovi)**.
1. Nella finestra di dialogo **Promote Read Replica (Promuovi replica di lettura)**, procedere come segue:
1. Per **Apply Immediately (Applica immediatamente)**, scegliere **Yes (Sì)** per promuovere immediatamente la replica di lettura o **No** per promuoverla alla successiva finestra di manutenzione del cluster.
1. Scegliere **Promote (Promuovi)** per promuovere la replica di lettura o **Cancel (Annulla)** per annullare l'operazione.
1. Se il cluster è stato abilitato per Multi-AZ prima di iniziare il processo di promozione, attendere finché lo stato del gruppo di replica è **available (disponibile)**, quindi modificare il cluster per abilitare nuovamente Multi-AZ. Per ulteriori informazioni, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
## Usando il AWS CLI
Non puoi promuovere una replica di lettura al nodo primario se il gruppo di replica è abilitato per Multi-AZ. In alcuni casi, la replica che desideri promuovere potrebbe essere membro di un gruppo di repliche in cui è abilitata la funzione Multi-AZ. In questi casi, prima di continuare è necessario modificare il gruppo di replica per disabilitare Multi-AZ. Questa operazione non richiede che tutti i cluster siano nella stessa zona di disponibilità. Per ulteriori informazioni sulla modifica di un gruppo di replica, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
Il AWS CLI comando seguente modifica il gruppo di replica`sample-repl-group`, rendendo la replica di lettura la principale `my-replica-1` del gruppo di replica.
Per Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id sample-repl-group \
--primary-cluster-id my-replica-1
```
Per Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id sample-repl-group ^
--primary-cluster-id my-replica-1
```
Per ulteriori informazioni sulla modifica di un gruppo di replica, consulta [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) *Amazon ElastiCache Command Line* Reference.
## Utilizzo dell'API ElastiCache
Non puoi promuovere una replica di lettura al nodo primario se il gruppo di replica è abilitato per Multi-AZ. In alcuni casi, la replica che desideri promuovere potrebbe essere membro di un gruppo di repliche in cui è abilitata la funzione Multi-AZ. In questi casi, prima di continuare è necessario modificare il gruppo di replica per disabilitare Multi-AZ. Questa operazione non richiede che tutti i cluster siano nella stessa zona di disponibilità. Per ulteriori informazioni sulla modifica di un gruppo di replica, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
La seguente azione ElastiCache API modifica il gruppo di replica`myReplGroup`, rendendo la replica di lettura la principale `myReplica-1` del gruppo di replica.
```
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=
```
Per ulteriori informazioni sulla modifica di un gruppo di replica, consulta [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) *Amazon ElastiCache API* Reference.
# Gestione della manutenzione dei ElastiCache cluster
Ogni cluster ha una finestra di manutenzione settimanale durante la quale vengono applicate le modifiche al sistema. Con Valkey e Redis OSS, i gruppi di replica hanno la stessa finestra di manutenzione settimanale. Se non specifichi una finestra di manutenzione preferita quando crei o modifichi un cluster o un gruppo di replica, ElastiCache assegna una finestra di manutenzione di 60 minuti all'interno della finestra di manutenzione della regione in un giorno della settimana scelto a caso.
La finestra di manutenzione di 60 minuti viene selezionata a caso da un blocco di tempo di 8 ore per regione. La seguente tabella elenca i blocchi temporali per ciascuna regione da cui sono assegnate le finestre di manutenzione predefinite. È possibile scegliere una finestra di manutenzione personalizzata, anche non compresa nel blocco della regione.
| Codice regione | Nome della regione | Finestra di manutenzione della regione |
| --- | --- | --- |
| ap-northeast-1 | Regione Asia Pacifico (Tokyo) | 13:00 - 21:00 UTC |
| ap-northeast-2 | Regione Asia Pacifico (Seoul) | 12:00 - 20:00 UTC |
| ap-northeast-3 | Regione Asia Pacifico (Osaka-Locale) | 12:00 - 20:00 UTC |
| ap-southeast-3 | Regione Asia Pacifico (Giacarta) | 14:00 - 22:00 UTC |
| ap-south-1 | Regione Asia Pacifico (Mumbai) | 17:30-1:30 UTC |
| ap-southeast-1 | Regione Asia Pacifico (Singapore) | 14:00 - 22:00 UTC |
| cn-north-1 | Regione Cina (Pechino) | 14:00 - 22:00 UTC |
| cn-northwest-1 | Regione Cina (Ningxia) | 14:00 - 22:00 UTC |
| ap-east-1 | Regione Asia Pacifico (Hong Kong) | 13:00 - 21:00 UTC |
| ap-southeast-2 | Asia Pacifico (Sydney) | 12:00 - 20:00 UTC |
| eu-west-3 | Regione UE (Parigi) | 23:59 - 07:29 UTC |
| af-south-1 | Regione Africa (Città del Capo) | 13:00 - 21:00 UTC |
| eu-central-1 | Regione Europa (Francoforte) | 23:00 - 07:00 UTC |
| eu-west-1 | Europa (Irlanda) | 22:00 - 06:00 UTC |
| eu-west-2 | Regione Europa (Londra) | 23:00 - 07:00 UTC |
| me-south-1 | Regione Medio Oriente (Bahrein) | 13:00 - 21:00 UTC |
| me-central-1 | Regione Medio Oriente (Emirati Arabi Uniti) | 13:00 - 21:00 UTC |
| eu-south-1 | Regione Europa (Milano) | 21:00 - 05:00 UTC |
| sa-east-1 | Regione Sud America (San Paolo) | 01:00 - 09:00 UTC |
| us-east-1 | Stati Uniti orientali (Virginia settentrionale) | 03:00 - 11:00 UTC |
| us-east-2 | Stati Uniti orientali (Ohio) | 04:00–12:00 UTC |
| us-gov-west-1 | AWS GovCloud (US) regione | 06:00 - 14:00 UTC |
| us-west-1 | Regione Stati Uniti occidentali (California settentrionale) | 06:00 - 14:00 UTC |
| us-west-2 | Stati Uniti occidentali (Oregon) | 06:00 - 14:00 UTC |
**Modifica della finestra di manutenzione del cluster o del gruppo di replica**
La finestra di manutenzione deve avvenire nel momento dell'utilizzo più basso e pertanto potrebbe essere necessario apportare modifiche di tanto in tanto. Puoi modificare il cluster o gruppo di replica e specificare un intervallo di tempo di 24 ore al massimo durante il quale si verifichino le attività di manutenzione richieste. Qualsiasi modifica del cluster richiesta, ma posticipata o in sospeso, viene apportata durante questo lasso di tempo.
**Nota**
Se desideri applicare immediatamente le modifiche al tipo di nodo, gli aggiornamenti and/or del motore, utilizza la Console di gestione AWS casella **Applica** ora. Altrimenti queste modifiche verranno applicate durante la successiva finestra di manutenzione programmata. Per utilizzare l'API, consulta [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)o. [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html)
**Ulteriori informazioni**
Per informazioni sulle finestre di manutenzione e la sostituzione dei nodi, consulta a seguire:
+ [ElastiCache Manutenzione](https://aws.amazon.com/elasticache/elasticache-maintenance/): domande frequenti sulla manutenzione e sulla sostituzione dei nodi
+ [Sostituzione dei nodi (Memcached)](CacheNodes.NodeReplacement-mc.md)—Gestione della sostituzione dei nodi per Memcached
+ [Modifica di un cluster ElastiCache](Clusters.Modify.md)— Modifica della finestra di manutenzione di un cluster
+ [Sostituzione dei nodi (Valkey e Redis OSS)](CacheNodes.NodeReplacement.md):-Gestione della sostituzione dei nodi
+ [Modifica di un gruppo di replica](Replication.Modify.md): modifica della finestra di manutenzione di un gruppo di replica
# Configurazione dei parametri del motore utilizzando gruppi di ElastiCache parametri
Amazon ElastiCache utilizza i parametri per controllare le proprietà di runtime dei nodi e dei cluster. Le versioni più recenti del prodotto includono in genere parametri aggiuntivi per il support delle nuove funzionalità. Per le tabelle dei parametri Memcached, vedi. [Parametri Memcached specifici](ParameterGroups.Engine.md#ParameterGroups.Memcached) Per le tabelle dei parametri OSS di Valkey e Redis, vedere. [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
Come previsto, alcuni valori di parametro, ad esempio `maxmemory`, sono determinati da tipo di nodo e motore. Per una tabella di questi valori dei parametri Memcached per tipo di nodo, vedere. [Parametri specifici del tipo di nodo Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached.NodeSpecific) Per una tabella di questi valori dei parametri Valkey e Redis OSS per tipo di nodo, vedere. [Parametri specifici del tipo di nodo Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific)
**Nota**
Per un elenco dei parametri specifici Memcached, consultare [Parametri Memcached specifici](ParameterGroups.Engine.md#ParameterGroups.Memcached).
**Topics**
+ [Gestione dei parametri in ElastiCache](ParameterGroups.Management.md)
+ [Memorizza i livelli del gruppo di parametri in ElastiCache](ParameterGroups.Tiers.md)
+ [Creazione di un gruppo di ElastiCache parametri](ParameterGroups.Creating.md)
+ [Elenco ElastiCache dei gruppi di parametri per nome](ParameterGroups.ListingGroups.md)
+ [Elenco dei valori di un gruppo di ElastiCache parametri](ParameterGroups.ListingValues.md)
+ [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md)
+ [Eliminazione di un gruppo di ElastiCache parametri](ParameterGroups.Deleting.md)
+ [Parametri specifici del motore](ParameterGroups.Engine.md)
# Gestione dei parametri in ElastiCache
ElastiCache i parametri sono raggruppati in gruppi di parametri denominati per una più semplice gestione dei parametri. Un gruppo di parametri rappresenta una combinazione di valori specifici per i parametri passati al software del motore durante l'avvio. Questi valori determinano il comportamento dei processi del motore su ciascun nodo in fase di runtime. I valori dei parametri su un gruppo di parametri specifico si applicano a tutti i nodi associati al gruppo, indipendentemente dal cluster a cui appartengono.
Per ottimizzare le prestazioni del cluster, puoi modificare alcuni valori dei parametri oppure puoi modificare il gruppo di parametri del cluster.
+ Non è possibile modificare né eliminare i gruppi di parametri predefiniti. Se hai bisogno di valori dei parametri personalizzati, devi creare un gruppo di parametri personalizzato.
+ Per Memcached, la famiglia di gruppi di parametri e il cluster a cui lo stai assegnando devono essere compatibili. Se il cluster esegue ad esempio Memcached versione 1.4.8, puoi usare solo gruppi di parametri della famiglia Memcached 1.4, predefiniti o personalizzati.
Per Redis OSS, la famiglia di gruppi di parametri e il cluster a cui la stai assegnando devono essere compatibili. Ad esempio, se il cluster esegue Redis OSS versione 3.2.10, è possibile utilizzare solo gruppi di parametri, predefiniti o personalizzati, della famiglia Redis OSS 3.2.
+ Se modifichi un gruppo di parametri del cluster, i valori di un parametro modificabile in base a condizioni devono essere gli stessi sia nel gruppo di parametri corrente sia in quello nuovo.
+ Per Memcached, quando si modificano i parametri di un cluster, la modifica viene applicata immediatamente al cluster. Ciò è valido se modifichi il gruppo dei parametri del cluster o un valore di parametro nel gruppo dei parametri del cluster. Per determinare quando viene applicata la modifica di un determinato parametro, consulta la colonna relativa all'**applicazione delle modifiche** nelle tabelle in [Parametri Memcached specifici](ParameterGroups.Engine.md#ParameterGroups.Memcached). Per ulteriori informazioni sul riavvio dei nodi del cluster, consulta [Rebooting clusters](Clusters.html#Rebooting).
+ Per Redis OSS, quando si modificano i parametri di un cluster, la modifica viene applicata al cluster immediatamente o, con le eccezioni riportate di seguito, dopo il riavvio dei nodi del cluster. Ciò è valido se modifichi il gruppo dei parametri del cluster o un valore di parametro nel gruppo dei parametri del cluster. Per determinare quando viene applicata la modifica di un determinato parametro, consulta la colonna relativa all'**applicazione delle modifiche** nelle tabelle in [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
Per ulteriori informazioni sul riavvio dei nodi Valkey o Redis OSS, consulta. [Riavvio dei nodi](nodes.rebooting.md)
**Modifiche ai parametri Valkey o Redis OSS (Cluster Mode Enabled)**
Se apporti modifiche ai seguenti parametri su un cluster Valkey o Redis OSS (modalità cluster abilitata), segui i passaggi seguenti.
activerehashing
database
Creare un backup manuale del cluster. Consultare [Esecuzione di backup manuali](backups-manual.md).
Elimina il cluster. Consulta [Deleting clusters](Clusters.html#Delete).
Ripristina il cluster utilizzando il gruppo di parametri modificato e il backup per inizializzare il nuovo cluster. Consultare [Ripristino da un backup in una nuova cache](backups-restoring.md).
Le modifiche ad altri parametri non richiedono questo.
+ È possibile associare gruppi di parametri ai datastore globali Valkey e Redis OSS. *I datastore globali* sono una raccolta di uno o più cluster che si estendono su più regioni. AWS In questo caso, il gruppo di parametri viene condiviso da tutti i cluster che costituiscono il Global Datastore. Eventuali modifiche al gruppo di parametri del cluster primario vengono replicate in tutti i cluster rimanenti nel Global Datastore. Per ulteriori informazioni, consulta [Replica tra AWS regioni utilizzando datastore globali](Redis-Global-Datastore.md).
È possibile verificare se un gruppo di parametri fa parte di un Global Datastore esaminando le seguenti posizioni:
+ **Sulla ElastiCache console, nella pagina **Parameter Groups**, l'attributo Global yes/no **
+ La yes/no `IsGlobal` proprietà dell'operazione [CacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CacheParameterGroup.html)API
# Memorizza i livelli del gruppo di parametri in ElastiCache
Amazon ElastiCache dispone di tre livelli di gruppi di parametri di cache, come illustrato di seguito.
![\[Immagine: livelli del gruppo di ElastiCache parametri Amazon\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-ParameterGroups-Tiers.png)
*Livelli ElastiCache dei gruppi di parametri Amazon*
**Di default globale**
Il gruppo di parametri principali di primo livello per tutti ElastiCache i clienti Amazon della regione.
Gruppo di parametri cache di default globale:
+ È riservato ElastiCache e non disponibile per il cliente.
**Di default del cliente**
Copia del gruppo di parametri cache di default globale creata per l'uso da parte del cliente.
Il gruppo di parametri cache di default globale:
+ È stato creato e di proprietà di ElastiCache.
+ È disponibile per l'uso da parte del cliente come gruppo di parametri cache per i cluster che eseguono una versione del motore supportata dal gruppo di parametri cache.
+ Non può essere modificato dal cliente.
**Di proprietà del cliente**
Copia del gruppo di parametri cache di default globale, un gruppo di parametri cache di proprietà del cliente viene creato ogni volta che il cliente crea un gruppo di parametri cache.
Il gruppo di parametri cache di proprietà del cliente:
+ Viene creato dal cliente ed è di sua proprietà.
+ Può essere assegnato a un cluster compatibile del cliente.
+ Può essere modificato dal cliente per creare un gruppo di parametri cache personalizzato.
Non è possibile modificare tutti i valori dei parametri. Per ulteriori informazioni sui valori Memcached, vedere. [Parametri Memcached specifici](ParameterGroups.Engine.md#ParameterGroups.Memcached) Per ulteriori informazioni sui valori OSS di Valkey e Redis, vedere. [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
# Creazione di un gruppo di ElastiCache parametri
Devi creare un nuovo gruppo di parametri se per uno o più valori di parametri desideri configurare un'impostazione diversa da quella predefinita. È possibile creare un gruppo di parametri utilizzando la ElastiCache console AWS CLI, l'o l' ElastiCache API.
## Creazione di un gruppo di ElastiCache parametri (Console)
La procedura seguente mostra come creare un gruppo di parametri tramite la console ElastiCache.
**Per creare un gruppo di parametri utilizzando la ElastiCache console**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Per un elenco di tutti i gruppi di parametri disponibili, nel pannello di navigazione a sinistra scegliere **Parameter Groups (Gruppi di parametri)**.
1. Per creare un nuovo gruppo di parametri, scegliere **Create Parameter Group (Crea gruppo di parametri)**.
Viene visualizzata la schermata **Create Parameter Group (Crea gruppo di parametri)**.
1. Nell'elenco **Family (Famiglia)** scegliere la famiglia del gruppo di parametri che verrà utilizzata come modello per il gruppo di parametri.
La famiglia di gruppi di parametri, come *memcached1.4* o *redis3.2*, definisce i parametri effettivi nel gruppo di parametri e i relativi valori iniziali. e deve coincidere con la versione e il motore del cluster.
1. Nella casella **Name (Nome)** digitare un nome univoco per il gruppo di parametri.
Quando si crea un cluster o si modifica un gruppo di parametri del cluster, il gruppo di parametri viene scelto in base al relativo nome. È pertanto consigliabile che il nome sia informativo e identifichi in qualche modo la famiglia del gruppo di parametri.
I vincoli per la denominazione dei gruppi di parametri sono i seguenti:
+ Devono iniziare con una lettera ASCII.
+ Può contenere solo lettere ASCII, cifre e trattini ('-').
+ Deve contenere da 1 a 255 caratteri.
+ Non possono contenere due trattini consecutivi.
+ Non posso terminare con un trattino.
1. Nella casella **Description (Descrizione)** digitare una descrizione per il gruppo di parametri.
1. Per creare il gruppo di parametri, scegliere **Create (Crea)**.
Per terminare il processo senza creare il gruppo di parametri, scegliere **Cancel (Annulla)**.
1. Quando viene creato, il gruppo di parametri è associato ai valori predefiniti della famiglia. Per modificare i valori predefiniti, è necessario modificare il gruppo di parametri. Per ulteriori informazioni, consulta [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md).
## Creazione di un gruppo di parametri () ElastiCache AWS CLI
Per creare un gruppo di parametri utilizzando il AWS CLI, utilizzate il comando `create-cache-parameter-group` con questi parametri.
+ `--cache-parameter-group-name`Nome del gruppo di parametri.
Vincoli per la denominazione dei gruppi di parametri:
+ Devono iniziare con una lettera ASCII.
+ Può contenere solo lettere ASCII, cifre e trattini ('-').
+ Deve contenere da 1 a 255 caratteri.
+ Non possono contenere due trattini consecutivi.
+ Non posso terminare con un trattino.
+ `--cache-parameter-group-family`— Il motore e la famiglia di versioni per il gruppo di parametri.
+ `--description` - Una descrizione per la copia del gruppo di parametri del cluster fornita dall'utente.
**Example**
L'esempio seguente crea un nuovo gruppo di parametri denominato *myMem14*, che utilizza la famiglia memcached1.4 come modello.
Per Linux, macOS o Unix:
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myMem14 \
--cache-parameter-group-family memcached1.4 \
--description "My first parameter group"
```
Per Windows:
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myMem14 ^
--cache-parameter-group-family memcached1.4 ^
--description "My first parameter group"
```
L'output di questo comando dovrebbe essere simile a quanto segue:
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
}
```
**Example**
L'esempio seguente crea un nuovo gruppo di parametri denominato *myRed28*, che utilizza la famiglia redis2.8 come modello.
Per Linux, macOS o Unix:
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myRed28 \
--cache-parameter-group-family redis2.8 \
--description "My first parameter group"
```
Per Windows:
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myRed28 ^
--cache-parameter-group-family redis2.8 ^
--description "My first parameter group"
```
L'output di questo comando dovrebbe essere simile a quanto segue:
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
}
```
Quando viene creato, il gruppo di parametri è associato ai valori predefiniti della famiglia. Per modificare i valori predefiniti, è necessario modificare il gruppo di parametri. Per ulteriori informazioni, consulta [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md).
Per ulteriori informazioni, consulta [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).
## Creazione di un gruppo di ElastiCache parametri (ElastiCache API)
Per creare un gruppo di parametri utilizzando l' ElastiCache API, utilizzate l'`CreateCacheParameterGroup`azione con questi parametri.
+ `ParameterGroupName`Nome del gruppo di parametri.
Vincoli per la denominazione dei gruppi di parametri:
+ Devono iniziare con una lettera ASCII.
+ Può contenere solo lettere ASCII, cifre e trattini ('-').
+ Deve contenere da 1 a 255 caratteri.
+ Non possono contenere due trattini consecutivi.
+ Non posso terminare con un trattino.
+ `CacheParameterGroupFamily`— Il motore e la famiglia di versioni per il gruppo di parametri. Ad esempio, `memcached1.4`.
+ `CacheParameterGroupFamily`— Il motore e la famiglia di versioni per il gruppo di parametri. Ad esempio, `redis2.8`.
+ `Description` - Una descrizione per la copia del gruppo di parametri del cluster fornita dall'utente.
**Example**
L'esempio seguente crea un nuovo gruppo di parametri denominato *myMem14*, che utilizza la famiglia memcached1.4 come modello.
```
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=
```
La risposta restituita da tale operazione dovrebbe essere simile a quanto segue:
```
myMem14memcached1.4My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
**Example**
L'esempio seguente crea un nuovo gruppo di parametri denominato *myRed28*, che utilizza la famiglia redis2.8 come modello.
```
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=
```
La risposta restituita da tale operazione dovrebbe essere simile a quanto segue:
```
myRed28redis2.8My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
Quando viene creato, il gruppo di parametri è associato ai valori predefiniti della famiglia. Per modificare i valori predefiniti, è necessario modificare il gruppo di parametri. Per ulteriori informazioni, consulta [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md).
Per ulteriori informazioni, consulta [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheParameterGroup.html).
# Elenco ElastiCache dei gruppi di parametri per nome
È possibile elencare i gruppi di parametri utilizzando la ElastiCache console AWS CLI, l'o l' ElastiCacheAPI.
## Elenco di gruppi di parametri per nome (console)
La procedura seguente mostra come visualizzare un elenco di gruppi di parametri tramite la console ElastiCache .
**Per elencare i gruppi di parametri utilizzando la ElastiCache console**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Per un elenco di tutti i gruppi di parametri disponibili, nel pannello di navigazione a sinistra scegliere **Parameter Groups (Gruppi di parametri)**.
## Elenco ElastiCache dei gruppi di parametri per nome (AWS CLI)
Per generare un elenco di gruppi di parametri utilizzando il AWS CLI, utilizzate il comando`describe-cache-parameter-groups`. Se specifichi un nome del gruppo di parametri, nell'elenco sarà presente solo tale gruppo di parametri. Se non specifichi un nome del gruppo di parametri, nell'elenco saranno presenti fino a `--max-records` gruppi di parametri. In entrambi i casi, saranno indicati nome, famiglia e descrizione del gruppo di parametri.
**Example**
Il codice di esempio seguente elenca il gruppo di parametri *myMem14*.
Per Linux, macOS o Unix:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myMem14
```
Per Windows:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myMem14
```
L'output di questo comando sarà simile al seguente e conterrà il nome, la famiglia e la descrizione del gruppo di parametri.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
]
}
```
**Example**
Il codice di esempio seguente elenca il gruppo di parametri *myRed28*.
Per Linux, macOS o Unix:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed28
```
Per Windows:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed28
```
L'output di questo comando sarà simile al seguente e conterrà il nome, la famiglia e la descrizione del gruppo di parametri.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
]
}
```
**Example**
Il codice di esempio seguente elenca il gruppo di parametri *myRed56* per i gruppi di parametri in esecuzione sul motore Redis OSS dalla versione 5.0.6 in poi. Se il gruppo di parametri fa parte di un [Replica tra AWS regioni utilizzando datastore globali](Redis-Global-Datastore.md), il valore della proprietà `IsGlobal` restituito nell'output sarà `Yes`.
Per Linux, macOS o Unix:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed56
```
Per Windows:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed56
```
L'output di questo comando sarà simile al seguente e conterrà il nome, la famiglia, isGlobal e la descrizione del gruppo di parametri.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed56",
"CacheParameterGroupFamily": "redis5.0",
"Description": "My first parameter group",
"IsGlobal": "yes"
}
]
}
```
**Example**
Il codice di esempio seguente elenca fino a 10 gruppi di parametri.
```
aws elasticache describe-cache-parameter-groups --max-records 10
```
L'output JSON di questo comando sarà simile a questo, elencando per ogni gruppo di parametri il nome, la famiglia, la descrizione e, nel caso di redis5.6, se il gruppo di parametri fa parte di un Global Datastore (isGlobal).
```
{
"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"
},
]
}
```
Per ulteriori informazioni, consulta [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).
## Elenco ElastiCache dei gruppi di parametri per nome (API) ElastiCache
Per generare un elenco di gruppi di parametri utilizzando l' ElastiCache API, utilizza l'`DescribeCacheParameterGroups`azione. Se specifichi un nome del gruppo di parametri, nell'elenco sarà presente solo tale gruppo di parametri. Se non specifichi un nome del gruppo di parametri, nell'elenco saranno presenti fino a `MaxRecords` gruppi di parametri. In entrambi i casi, saranno indicati nome, famiglia e descrizione del gruppo di parametri.
**Example**
Il codice di esempio seguente elenca il gruppo di parametri *myMem14*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La risposta restituita da tale operazione sarà simile a quanto segue e conterrà il nome, la famiglia e la descrizione di ciascun gruppo di parametri.
```
myMem14memcached1.4My custom Memcached 1.4 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
Il codice di esempio seguente elenca fino a 10 gruppi di parametri.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&MaxRecords=10
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La risposta di questa operazione sarà simile a questa, elencando per ogni gruppo di parametri il nome, la famiglia, la descrizione e, nel caso di redis5.6 se il gruppo di parametri appartiene a un Global Datastore (isGlobal).
```
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**
Il codice di esempio seguente elenca il gruppo di parametri *myRed28*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La risposta restituita da tale operazione sarà simile a quanto segue e conterrà il nome, la famiglia e la descrizione.
```
myRed28redis2.8My custom Redis 2.8 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
Il codice di esempio seguente elenca il gruppo di parametri *myRed56*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&CacheParameterGroupName=myRed56
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La risposta di questa operazione sarà simile a questa, elencando il nome, la famiglia, la descrizione e se il gruppo di parametri fa parte di un Datastore globale (isGlobal).
```
myRed56redis5.0My custom Redis 5.6 parameter groupyes3540cc3d-af48-11e0-97f9-279771c4477e
```
Per ulteriori informazioni, consulta [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameterGroups.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameterGroups.html).
# Elenco dei valori di un gruppo di ElastiCache parametri
È possibile elencare i parametri e i relativi valori per un gruppo di parametri utilizzando la ElastiCache console AWS CLI, l'o l' ElastiCache API.
## Elenco dei valori di un gruppo di ElastiCache parametri (Console)
La procedura seguente mostra come elencare i parametri e i relativi valori per un gruppo di parametri utilizzando la ElastiCache console.
**Per creare un elenco dei parametri e dei relativi valori in un gruppo di parametri tramite la console ElastiCache.**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Per un elenco di tutti i gruppi di parametri disponibili, nel pannello di navigazione a sinistra scegliere **Parameter Groups (Gruppi di parametri)**.
1. Scegliere il gruppo di parametri per cui si desidera elencare i parametri e i valori selezionando la casella a sinistra del nome del gruppo di parametri.
I parametri e i relativi valori verranno elencati nella parte inferiore dello schermo. A causa dell'elevato numero di parametri, potrebbe essere necessario scorrere verso l'alto e verso il basso per individuare il parametro desiderato.
## Generazione di un elenco di valori di un gruppo di parametri (AWS CLI)
Per elencare i parametri di un gruppo di parametri e i relativi valori utilizzando il AWS CLI, usa il comando`describe-cache-parameters`.
**Example**
*Il codice di esempio seguente elenca tutti i parametri Memcached e i relativi valori per il gruppo di parametri MyMem14.*
Per Linux, macOS o Unix:
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myMem14
```
Per Windows:
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myMem14
```
**Example**
Il seguente codice di esempio consente di creare un elenco di tutti i parametri e dei relativi valori per il gruppo di parametri *myRedis28*.
Per Linux, macOS o Unix:
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myRedis28
```
Per Windows:
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myRed28
```
Per ulteriori informazioni, consulta [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).
## Elenco dei valori di un gruppo di parametri (API) ElastiCache
Per elencare i parametri di un gruppo di parametri e i relativi valori utilizzando l' ElastiCache API, utilizza l'`DescribeCacheParameters`azione.
**Example**
*Il codice di esempio seguente elenca tutti i parametri Memcached per il gruppo di parametri MyMem14.*
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameters
&CacheParameterGroupName=myMem14
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La risposta restituita da tale operazione dovrebbe essere simile a quanto segue. In questo caso, la risposta è stata troncata.
```
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**
Il seguente codice di esempio consente di creare un elenco di tutti i parametri per il gruppo di parametri *myRed28*.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameters
&CacheParameterGroupName=myRed28
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
La risposta restituita da tale operazione dovrebbe essere simile a quanto segue. In questo caso, la risposta è stata troncata.
```
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
```
Per ulteriori informazioni, consulta [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameters.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameters.html).
# Modifica di un gruppo di ElastiCache parametri
**Importante**
Non è consentito modificare un gruppo di parametri di default.
Non puoi modificare alcuni valori di parametri in un gruppo di parametri. Tali valori di parametri sono applicati ai cluster associati al gruppo di parametri. Per ulteriori informazioni su quando una modifica del valore di un parametro viene applicata a un gruppo di parametri, vedere [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis) e[Parametri Memcached specifici](ParameterGroups.Engine.md#ParameterGroups.Memcached).
## Modifica di un gruppo di parametri (console)
La procedura seguente mostra come modificare il valore del `cluster-enabled` parametro utilizzando la ElastiCache console. Puoi usare la stessa procedura per modificare il valore di qualsiasi parametro.
**Per modificare il valore di un parametro utilizzando la ElastiCache console**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Per un elenco di tutti i gruppi di parametri disponibili, nel pannello di navigazione a sinistra scegliere **Parameter Groups (Gruppi di parametri)**.
1. Scegliere il gruppo di parametri che si desidera modificare selezionando la casella a sinistra del nome del gruppo di parametri.
I parametri del gruppo di parametri verranno elencati nella parte inferiore dello schermo. Potrebbe essere necessario scorrere l'elenco per visualizzare tutti i parametri.
1. Per modificare uno o più parametri, scegliere **Edit Parameters (Modifica parametri)**.
1. Nella schermata **Edit Parameter Group: (Modifica il gruppo di parametri:)** scorrere utilizzando le frecce sinistra e destra fino al parametro `binding_protocol`, quindi digitare `ascii` nella colonna **Value (Valore)**.
1. Seleziona **Salva modifiche**.
1. Per Memcached, per trovare il nome del parametro modificato, vedi. [Parametri Memcached specifici](ParameterGroups.Engine.md#ParameterGroups.Memcached) Se le modifiche apportate al parametro vengono applicate *dopo il riavvio*, riavvia ogni cluster che utilizza il gruppo di parametri. Per ulteriori informazioni, consulta [Rebooting clusters](Clusters.html#Rebooting).
1. Con Valkey e Redis OSS, per trovare il nome del parametro modificato, consulta. [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis) Se disponi di un cluster Valkey o Redis OSS (modalità cluster disabilitata) e apporti modifiche ai seguenti parametri, devi riavviare i nodi del cluster:
+ activerehashing
+ database
Per ulteriori informazioni sul riavvio, consultare [Riavvio dei nodi](nodes.rebooting.md).
**Modifiche ai parametri Valkey o Redis OSS (Cluster Mode Enabled)**
Se apporti modifiche ai seguenti parametri su un cluster Valkey o Redis OSS (modalità cluster abilitata), segui i passaggi seguenti.
activerehashing
database
Con Redis OSS, puoi creare un backup manuale del cluster. Consultare [Esecuzione di backup manuali](backups-manual.md).
Elimina il cluster. Consulta [Deleting clusters](Clusters.html#Delete).
Ripristinare il cluster utilizzando il gruppo di parametri modificato e il backup per inizializzare il nuovo cluster. Consultare [Ripristino da un backup in una nuova cache](backups-restoring.md).
Le modifiche ad altri parametri non richiedono questo.
## Modifica di un gruppo di parametri (AWS CLI)
Per modificare il valore di un parametro utilizzando il AWS CLI, usa il comando. `modify-cache-parameter-group`
**Example**
Con Memcached, per trovare il nome e i valori consentiti del parametro che desideri modificare, vedi [Parametri Memcached specifici](ParameterGroups.Engine.md#ParameterGroups.Memcached)
Il seguente codice di esempio imposta il valore di due parametri, *chunk\$1size* e *chunk\$1size\$1growth\$1fact*, nel gruppo di parametri `myMem14`.
Per Linux, macOS o 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
```
Per 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
```
L'aspetto dell'output di questo comando sarà simile al seguente.
```
{
"CacheParameterGroupName": "myMem14"
}
```
**Example**
Con Valkey e Redis OSS, per trovare il nome e i valori consentiti del parametro che desideri modificare, consulta [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
Il codice di esempio seguente imposta il valore di due parametri *reserved-memory-percent*ed è *abilitato in cluster* sul gruppo di parametri. `myredis32-on-30` Abbiamo impostato su `30` (30 percento) e *abilitato *reserved-memory-percent*per il cluster* in `yes` modo che il gruppo di parametri possa essere utilizzato con i cluster (gruppi di replica) Valkey o Redis OSS (abilitati alla modalità cluster).
Per Linux, macOS o 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
```
Per 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
```
L'aspetto dell'output di questo comando sarà simile al seguente.
```
{
"CacheParameterGroupName": "my-redis32-on-30"
}
```
Per ulteriori informazioni, consulta [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).
Per trovare il nome del parametro modificato, consultare [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
Se disponi di un cluster Valkey o Redis OSS (modalità cluster disabilitata) e apporti modifiche ai seguenti parametri, devi riavviare i nodi del cluster:
+ activerehashing
+ database
Per ulteriori informazioni sul riavvio, consultare [Riavvio dei nodi](nodes.rebooting.md).
**Modifiche ai parametri Valkey o Redis OSS (Cluster Mode Enabled)**
Se apporti modifiche ai seguenti parametri su un cluster Valkey o Redis OSS (modalità cluster abilitata), segui i passaggi seguenti.
activerehashing
database
Creare un backup manuale del cluster. Consultare [Esecuzione di backup manuali](backups-manual.md).
Elimina il cluster. Consulta [Deleting clusters](Clusters.html#Delete).
Ripristinare il cluster utilizzando il gruppo di parametri modificato e il backup per inizializzare il nuovo cluster. Consultare [Ripristino da un backup in una nuova cache](backups-restoring.md).
Le modifiche ad altri parametri non richiedono questo.
## Modifica di un gruppo di parametri (API) ElastiCache
Per modificare i valori dei parametri di un gruppo di parametri utilizzando l' ElastiCache API, utilizza l'`ModifyCacheParameterGroup`azione.
**Example**
Con Memcached, per trovare il nome e i valori consentiti del parametro che desideri modificare, consulta [Parametri Memcached specifici](ParameterGroups.Engine.md#ParameterGroups.Memcached)
Il seguente codice di esempio imposta il valore di due parametri, *chunk\$1size* e *chunk\$1size\$1growth\$1fact*, nel gruppo di parametri `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**
Con Valkey e Redis OSS, per trovare il nome e i valori consentiti del parametro che desideri modificare, consulta [Parametri Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
Il codice di esempio seguente imposta il valore di due parametri *reserved-memory-percent*ed è *abilitato in cluster* sul gruppo di parametri. `myredis32-on-30` Abbiamo impostato su `30` (30 percento) e *abilitato *reserved-memory-percent*per il cluster* in `yes` modo che il gruppo di parametri possa essere utilizzato con i cluster (gruppi di replica) Valkey o Redis OSS (abilitati alla modalità cluster).
```
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=
```
Per ulteriori informazioni, consulta [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheParameterGroup.html).
Se disponi di un cluster Valkey o Redis OSS (modalità cluster disabilitata) e apporti modifiche ai seguenti parametri, devi riavviare i nodi del cluster:
+ activerehashing
+ database
Per ulteriori informazioni, consulta [Riavvio dei nodi](nodes.rebooting.md).
**Modifiche ai parametri Valkey o Redis OSS (Cluster Mode Enabled)**
Se apporti modifiche ai seguenti parametri su un cluster Valkey o Redis OSS (modalità cluster abilitata), segui i passaggi seguenti.
activerehashing
database
Creare un backup manuale del cluster. Consultare [Esecuzione di backup manuali](backups-manual.md).
Elimina il cluster. Consultare [Eliminazione di un cluster in ElastiCache](Clusters.Delete.md).
Ripristinare il cluster utilizzando il gruppo di parametri modificato e il backup per inizializzare il nuovo cluster. Consultare [Ripristino da un backup in una nuova cache](backups-restoring.md).
Le modifiche ad altri parametri non richiedono questo.
# Eliminazione di un gruppo di ElastiCache parametri
È possibile eliminare un gruppo di parametri personalizzato utilizzando la ElastiCache console AWS CLI, l'o l'ElastiCache API.
Un gruppo di parametri non può essere eliminato se è associato a cluster. Non è inoltre possibile eliminare i gruppi di parametri predefiniti.
## Eliminazione di un gruppo di parametri (console)
La procedura seguente mostra come eliminare un gruppo di parametri tramite la console ElastiCache.
**Per eliminare un gruppo di parametri utilizzando la ElastiCache console**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Per un elenco di tutti i gruppi di parametri disponibili, nel pannello di navigazione a sinistra scegliere **Parameter Groups (Gruppi di parametri)**.
1. Scegliere i gruppi di parametri che si desidera eliminare selezionando la casella a sinistra del nome del gruppo di parametri.
Il pulsante **Delete (Elimina)** diventa attivo.
1. Scegliere **Delete** (Elimina).
Verrà visualizzata la schermata di conferma **Delete Parameter Groups (Elimina gruppi di parametri)**.
1. Per eliminare i gruppi di parametri, nella schermata di conferma **Delete Parameter Groups (Elimina gruppi di parametri)** scegliere **Delete (Elimina)**.
Per mantenere i gruppi di parametri, scegliere **Cancel (Annulla)**.
## Eliminazione di un gruppo di parametri (AWS CLI)
Per eliminare un gruppo di parametri utilizzando il AWS CLI, utilizzare il comando`delete-cache-parameter-group`. Per il gruppo di parametri da eliminare, il gruppo di parametri specificato da `--cache-parameter-group-name` non può essere associato ad alcun cluster, né può essere un gruppo di parametri di default.
Il codice di esempio seguente elimina il gruppo di parametri *myMem14*.
**Example**
Per Linux, macOS o Unix:
```
aws elasticache delete-cache-parameter-group \
--cache-parameter-group-name myRed28
```
Per Windows:
```
aws elasticache delete-cache-parameter-group ^
--cache-parameter-group-name myRed28
```
Per ulteriori informazioni, consulta [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).
## Eliminazione di un gruppo di parametri (ElastiCache API)
Per eliminare un gruppo di parametri utilizzando l' ElastiCache API, utilizzate l'`DeleteCacheParameterGroup`azione. Per il gruppo di parametri da eliminare, il gruppo di parametri specificato da `CacheParameterGroupName` non può essere associato ad alcun cluster, né può essere un gruppo di parametri di default.
**Example**
Con Memcached, il seguente codice di esempio elimina il gruppo di parametri *MyMem14*.
```
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**
Il codice di esempio seguente elimina il gruppo di parametri *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=
```
Per ulteriori informazioni, consulta [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteCacheParameterGroup.html).
# Parametri specifici del motore
**Valkey e Redis OSS**
La maggior parte dei parametri di Valkey 8 è compatibile con i parametri Redis OSS 7.1. I parametri di Valkey 7.2 sono gli stessi dei parametri di Redis OSS 7.
Se non si specifica un gruppo di parametri per il cluster Valkey o Redis OSS, verrà utilizzato un gruppo di parametri predefinito appropriato alla versione del motore. In un gruppo di parametri di default non puoi modificare i valori di nessuno dei parametri. Tuttavia puoi creare un gruppo di parametri personalizzato e assegnarlo in qualsiasi momento al cluster, purché i valori dei parametri modificabili in base a condizioni corrispondano in entrambi i gruppi di parametri. Per ulteriori informazioni, consulta [Creazione di un gruppo di ElastiCache parametri](ParameterGroups.Creating.md).
**Topics**
+ [Parametri Valkey e Redis OSS](#ParameterGroups.Redis)
+ [Parametri Memcached specifici](#ParameterGroups.Memcached)
## Parametri Valkey e Redis OSS
**Topics**
+ [Modifiche ai parametri di Valkey 8.2](#ParameterGroups.Valkey.8.2)
+ [Modifiche ai parametri di Valkey 8.1](#ParameterGroups.Valkey.8.1)
+ [Modifiche ai parametri di Valkey 8.0](#ParameterGroups.Valkey.8)
+ [Modifiche ai parametri di Valkey 7.2 e Redis OSS 7](#ParameterGroups.Redis.7)
+ [Modifiche ai parametri di Redis OSS 6.x](#ParameterGroups.Redis.6-x)
+ [Modifiche ai parametri Redis OSS 5.0.3](#ParameterGroups.Redis.5-0-3)
+ [Modifiche ai parametri Redis OSS 5.0.0](#ParameterGroups.Redis.5.0)
+ [Modifiche ai parametri Redis OSS 4.0.10](#ParameterGroups.Redis.4-0-10)
+ [Modifiche ai parametri Redis OSS 3.2.10](#ParameterGroups.Redis.3-2-10)
+ [modifiche ai parametri Redis OSS 3.2.6](#ParameterGroups.Redis.3-2-6)
+ [Modifiche ai parametri Redis OSS 3.2.4](#ParameterGroups.Redis.3-2-4)
+ [Parametri aggiunti per Redis OSS 2.8.24 (migliorato)](#ParameterGroups.Redis.2-8-24)
+ [Parametri aggiunti per Redis OSS 2.8.23 (migliorato)](#ParameterGroups.Redis.2-8-23)
+ [Parametri aggiunti Redis OSS 2.8.22 (migliorato)](#ParameterGroups.Redis.2-8-22)
+ [Parametri aggiunti a Redis OSS 2.8.21](#ParameterGroups.Redis.2-8-21)
+ [Parametri aggiunti Redis OSS 2.8.19](#ParameterGroups.Redis.2-8-19)
+ [Parametri aggiunti Redis OSS 2.8.6](#ParameterGroups.Redis.2-8-6)
+ [Parametri Redis OSS 2.6.13](#ParameterGroups.Redis.2-6-13)
+ [Parametri specifici del tipo di nodo Redis OSS](#ParameterGroups.Redis.NodeSpecific)
### Modifiche ai parametri di Valkey 8.2
**Famiglia di gruppi di parametri**: valkey8
**Nota**
Le modifiche ai parametri di Valkey 8.2 non si applicano a Valkey 8.1
I gruppi di parametri Valkey 8.0 e versioni successive non sono compatibili con Redis OSS 7.2.4.
in Valkey 8.2, i seguenti comandi non sono disponibili per le cache serverless:,,, e `commandlog` `commandlog get` `commandlog help` `commandlog len` `commandlog reset.`
**Nuovi gruppi di parametri in Valkey 8.2**
| Name | Informazioni | Description |
| --- | --- | --- |
| search-fanout-target-mode (aggiunto nella versione 8.2) | Predefinito: client Tipo: string Modificabile: sì Le modifiche hanno effetto: Immediatamente | Il parametro search-fanout-target-mode di configurazione controlla il modo in cui le query di ricerca vengono distribuite tra i nodi in un ambiente cluster Valkey. Questa impostazione accetta due valori: «throughput» che ottimizza la velocità effettiva massima distribuendo in modo casuale le query di ricerca su tutti i nodi del cluster indipendentemente dal tipo di client o dallo stato READONLY e «client» che rispetta le caratteristiche di connessione del client indirizzando i client non READONLY solo ai nodi primari, i client READONLY sulle connessioni di replica solo ai nodi di replica e i client READONLY sulle connessioni primarie in modo casuale su tutti i nodi. Il comportamento predefinito è la modalità «client», il che significa che il sistema rispetterà i tipi di connessione client e lo stato READONLY per le decisioni di routing delle query. Utilizza la modalità throughput per carichi di lavoro di ricerca ad alto volume in cui si desidera utilizzare al massimo le risorse del cluster e la modalità client per mantenere la read/write separazione e rispettare i modelli di connessione READONLY a livello di applicazione. |
| search-default-timeout-ms | Valore predefinito: 50000 Valori consentiti: da 1 a 60000 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Immediatamente | Il timeout predefinito della query di ricerca Valkey (in millisecondi). |
| search-enable-partial-results | Impostazione predefinita: yes (sì) Valori consentiti: sì, no Tipo: booleano Modificabile: sì Le modifiche hanno effetto: Immediatamente | Configura il comportamento di errore delle query per Valkey search. Se abilitata, le query di ricerca restituiranno risultati parziali se si verificano dei timeout su uno o più shard. Se disabilitato, qualsiasi timeout degli shard causerà il fallimento dell'intera query di ricerca e restituirà un errore. |
### Modifiche ai parametri di Valkey 8.1
**Famiglia di gruppi di parametri: valkey8**
**Nota**
Le modifiche ai parametri di Valkey 8.1 non si applicano a Valkey 8.0
I gruppi di parametri Valkey 8.0 e versioni successive non sono compatibili con Redis OSS 7.2.4.
in Valkey 8.1, i seguenti comandi non sono disponibili per le cache serverless:,,, e `commandlog` `commandlog get` `commandlog help` `commandlog len` `commandlog reset.`
**Nuovi gruppi di parametri in Valkey 8.1**
| Name | Informazioni | Description |
| --- | --- | --- |
| commandlog-large-request-max-len (aggiunto nella versione 8.1) | Impostazione predefinita: 1048576 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Immediatamente | La dimensione massima, in byte, per le richieste che devono essere registrate dalla funzione Valkey Command Log. |
| commandlog-large-request-max-len (aggiunto nella versione 8.1) | Impostazione predefinita: 128 Valori consentiti: 0-1024 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Immediatamente | La lunghezza massima del Valkey Command Log per le richieste. |
| commandlog-reply-larger-than (aggiunto nella versione 8.1) | Impostazione predefinita: 1048576 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Immediatamente | La dimensione massima, in byte, per le risposte che devono essere registrate dalla funzione Valkey Command Log. |
| commandlog-large-reply-max-len (aggiunto nella versione 8.1) | Impostazione predefinita: 128 Valori consentiti: 0-1024 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Immediatamente | La lunghezza massima del Valkey Command Log per le risposte. |
### Modifiche ai parametri di Valkey 8.0
**Famiglia di gruppi di parametri**: valkey8
**Nota**
Redis OSS 7.2.4 non è compatibile con i gruppi di parametri Valkey 8 e versioni successive.
**Modifiche specifiche dei parametri in Valkey 8.0**
| Name | Informazioni | Description |
| --- | --- | --- |
| repl-backlog-size | Valore predefinito: 10485760 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Immediatamente | La dimensione in byte del buffer di backlog del nodo principale. Il backlog viene utilizzato per la registrazione degli aggiornamenti apportati ai dati sul nodo principale. Quando una replica di lettura si connette al primario, tenta di eseguire una sincronizzazione parziale (psync), in cui applica i dati del backlog per recuperare il ritardo con il nodo primario. Se il file psync fallisce, è necessaria una sincronizzazione completa. Il valore minimo per questo parametro è 16384. Nota: a partire da Redis OSS 2.8.22, questo parametro si applica al cluster primario e alle repliche di lettura. |
| maxmemory-samples | Impostazione predefinita: 3 Valori consentiti: da 1 a 64 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Immediatamente | Per i calcoli least-recently-used (LRU) e time-to-live (TTL), questo parametro rappresenta la dimensione del campione di chiavi da controllare. Per impostazione predefinita, Redis OSS sceglie 3 chiavi e utilizza quella utilizzata meno di recente. |
**Nuovi gruppi di parametri in Valkey 8.0**
| Name | Informazioni | Description |
| --- | --- | --- |
| extended-redis-compatibility | Valori consentiti: sì, no Impostazione predefinita: yes (sì) Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente. | La modalità di compatibilità estesa di Redis OSS fa sì che Valkey finga di essere Redis OSS 7.2. Attivala solo se hai problemi con strumenti o client. Impatti rivolti ai clienti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
**Gruppi di parametri rimossi in Valkey 8.0**
| Name | Informazioni | Description |
| --- | --- | --- |
| lazyfree-lazy-eviction | Valori consentiti: sì, no Impostazione predefinita: no Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente. | Esegue un'eliminazione asincrona sulle espulsioni. |
| lazyfree-lazy-expire | Valori consentiti: sì, no Impostazione predefinita: no Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente. | Esegue un'eliminazione asincrona sulle chiavi scadute. |
| lazyfree-lazy-server-del | Valori consentiti: sì, no Impostazione predefinita: no Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente. | Esegue un'eliminazione asincrona per i comandi che aggiornano i valori. |
| lazyfree-lazy-user-del | Impostazione predefinita: no Tipo: stringa Modificabile: sì Le modifiche diventano effettive immediatamente in tutti i nodi del cluster | Quando il valore è impostato su yes, il comando DEL agisce come UNLINK. |
| replica-lazy-flush | Impostazione predefinita: yes (sì) Tipo: booleano Modificabile: no Nome precedente: slave-lazy-flush | Esegue un'operazione flushDB asincrona durante la sincronizzazione della replica. |
### Modifiche ai parametri di Valkey 7.2 e Redis OSS 7
Famiglia di **gruppi di parametri**: valkey7
I gruppi di parametri predefiniti di Valkey 7.2 sono i seguenti:
+ `default.valkey7`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per i cluster e i gruppi di replica Valkey (modalità cluster disabilitata).
+ `default.valkey7.cluster.on`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per i cluster e i gruppi di replica Valkey (abilitata in modalità cluster).
**Famiglia del gruppo di parametri:** redis7
I gruppi di parametri predefiniti di Redis OSS 7 sono i seguenti:
+ `default.redis7`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per i cluster e i gruppi di replica Redis OSS (modalità cluster disabilitata).
+ `default.redis7.cluster.on`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per i cluster e i gruppi di replica Redis OSS (abilitata alla modalità cluster).
**Modifiche specifiche dei parametri**
I parametri aggiunti in Redis OSS 7 sono i seguenti. Valkey 7.2 supporta anche questi parametri.
| Name | Informazioni | Description |
| --- | --- | --- |
| cluster-allow-pubsubshard-when-down | Valori consentiti: `yes`, `no` Impostazione predefinita: `yes` Tipo: string Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Se impostato sul valore predefinito yes, consente ai nodi di servire il traffico di partizione pubsub mentre il cluster è in uno stato inattivo, purché ritenga di possedere gli slot. |
| cluster-preferred-endpoint-type | Valori consentiti: `ip`, `tls-dynamic` Impostazione predefinita: `tls-dynamic` Tipo: string Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Questo valore controlla quale endpoint viene restituito per le richieste MOVED/ASKING nonché il campo endpoint per `CLUSTER SLOTS` e `CLUSTER SHARDS`. Quando il valore è impostato su ip, il nodo pubblicizzerà il suo indirizzo IP. Quando il valore è impostato su tls-dynamic, il nodo pubblicizzerà un nome host quando encryption-in-transit è abilitato e un indirizzo IP in caso contrario. |
| latency-tracking | Valori consentiti: `yes`, `no` Impostazione predefinita: `no` Tipo: string Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Se impostato su yes, tiene traccia delle latenze per comando e consente di esportare la distribuzione percentile tramite il comando delle statistiche di latenza `INFO` e le distribuzioni di latenza cumulative (istogrammi) tramite il comando `LATENCY`. |
| hash-max-listpack-entries | Valori consentiti: `0+` Impostazione predefinita: `512` Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Il numero massimo di voci hash per consentire la compressione del set di dati. |
| hash-max-listpack-value | Valori consentiti: `0+` Impostazione predefinita: `64` Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | La soglia del numero massimo di voci hash per consentire la compressione del set di dati. |
| zset-max-listpack-entries | Valori consentiti: `0+` Impostazione predefinita: `128` Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Il numero massimo di voci set ordinari per consentire la compressione del set di dati. |
| zset-max-listpack-value | Valori consentiti: `0+` Impostazione predefinita: `64` Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | La soglia del numero massimo di voci set ordinati per consentire la compressione del set di dati. |
I parametri modificati in Redis OSS 7 sono i seguenti.
| Name | Informazioni | Description |
| --- | --- | --- |
| activerehashing | Modificabile: `no`. In Redis OSS 7, questo parametro è nascosto e abilitato per impostazione predefinita. Per disattivarlo, è necessario creare un [caso di supporto](https://console.aws.amazon.com/support/home). | Era modificabile. |
I parametri rimossi in Redis OSS 7 sono i seguenti.
| Name | Informazioni | Description |
| --- | --- | --- |
| hash-max-ziplist-entries | Valori consentiti: `0+` Impostazione predefinita: `512` Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Utilizzare `listpack` anziché `ziplist` per rappresentare la codifica hash piccola |
| hash-max-ziplist-value | Valori consentiti: `0+` Impostazione predefinita: `64` Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Utilizzare `listpack` anziché `ziplist` per rappresentare la codifica hash piccola |
| zset-max-ziplist-entries | Valori consentiti: `0+` Impostazione predefinita: `128` Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Utilizzare `listpack` anziché `ziplist` per rappresentare la codifica hash piccola. |
| zset-max-ziplist-value | Valori consentiti: `0+` Impostazione predefinita: `64` Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Utilizzare `listpack` anziché `ziplist` per rappresentare la codifica hash piccola. |
| list-max-ziplist-size | Valori consentiti: Impostazione predefinita: `-2` Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente in tutti i nodi del cluster. | Il numero di voci consentite per nodo elenco interno. |
### Modifiche ai parametri di Redis OSS 6.x
**Famiglia del gruppo di parametri:** redis6.x
I gruppi di parametri predefiniti di Redis OSS 6.x sono i seguenti:
+ `default.redis6.x`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per i cluster e i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata).
+ `default.redis6.x.cluster.on`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per cluster e gruppi di replica Valkey o Redis OSS (modalità cluster enabled).
**Nota**
**Nella versione 6.2 del motore Redis OSS, quando è stata introdotta la famiglia di nodi r6gd per l'uso con, solo le politiche di memoria massima *noeviction [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md)*, volatile-lru e allkeys-lru sono supportate con i tipi di nodi r6gd.**
Per ulteriori informazioni, consultare [ElastiCache versione 6.2 per Redis OSS (migliorata)](engine-versions.md#redis-version-6.2) e [ElastiCache versione 6.0 per Redis OSS (migliorata)](engine-versions.md#redis-version-6.0).
I parametri aggiunti in Redis OSS 6.x sono i seguenti.
| Informazioni | Description |
| --- | --- |
| acl-pubsub-default (added in 6.2) | Valori consentiti: `resetchannels`, `allchannels` Impostazione predefinita: `allchannels` Tipo: string Modificabile: sì Le modifiche hanno effetto: gli utenti Redis OSS esistenti associati al cluster continueranno ad avere le autorizzazioni esistenti. Aggiorna gli utenti o riavvia il cluster per aggiornare gli utenti Redis OSS esistenti. | Autorizzazioni di canale pubsub di default per gli utenti ACL implementati in questo cluster. |
| cluster-allow-reads-when-down (added in 6.0) | Impostazione predefinita: no Tipo: stringa Modificabile: sì Le modifiche diventano effettive immediatamente in tutti i nodi del cluster | Se impostato su yes, un gruppo di replica Redis OSS (modalità cluster abilitata) continua a elaborare i comandi di lettura anche quando un nodo non è in grado di raggiungere un quorum di primari. Se impostato sul valore di default su no, il gruppo di replica rifiuta tutti i comandi. Si consiglia di impostare questo valore su sì se si utilizza un cluster con meno di tre gruppi di nodi o se l'applicazione è in grado di gestire in modo sicuro le letture non aggiornate. |
| tracking-table-max-keys (added in 6.0) | Impostazione di default: 1.000.000 Tipo: numero Modificabile: sì Le modifiche diventano effettive immediatamente in tutti i nodi del cluster | Per facilitare la memorizzazione nella cache lato client, Redis OSS supporta il monitoraggio dei client che hanno effettuato l'accesso a quali chiavi. Quando la chiave tracciata viene modificata, i messaggi di annullamento della convalida vengono inviati a tutti i client per notificare loro i valori memorizzati nella cache non sono più validi. Questo valore consente di specificare il limite superiore di questa tabella. Dopo aver superato questo valore di parametro, i client vengono inviati invalidazione casualmente. Questo valore dovrebbe essere sintonizzato per limitare l'utilizzo della memoria pur mantenendo traccia di un numero sufficiente di chiavi. Anche le chiavi vengono invalidate in condizioni di memoria insufficiente. |
| acllog-max-len (added in 6.0) | Impostazione predefinita: 128 Tipo: numero Modificabile: sì Le modifiche diventano effettive immediatamente in tutti i nodi del cluster | Questo valore corrisponde al numero massimo di voci nel registro ACL. |
| active-expire-effort (added in 6.0) | Impostazione predefinita: 1 Tipo: numero Modificabile: sì Le modifiche diventano effettive immediatamente in tutti i nodi del cluster | Redis OSS elimina le chiavi che hanno superato il tempo di validità secondo due meccanismi. In uno, si accede a una chiave e si trova scaduta. Nell'altro, un processo periodico campiona le chiavi e fa scadere quelle che hanno superato la loro durata (TTL). Questo parametro definisce lo sforzo impiegato da Redis OSS per far scadere gli elementi del job periodico. Il valore di default di 1 tenta di evitare di avere più del 10% delle chiavi scadute ancora in memoria. Inoltre cerca di evitare di consumare più del 25% della memoria totale e di aggiungere latenza al sistema. È possibile aumentare questo valore fino a 10 per aumentare la quantità di sforzo speso per le chiavi in scadenza. Il compromesso è una CPU più alta e una latenza potenzialmente più elevata. Si consiglia un valore pari a 1, a meno che non si verifichi un utilizzo elevato della memoria e si possa tollerare un aumento dell'utilizzo della CPU. |
| lazyfree-lazy-user-del (added in 6.0) | Impostazione predefinita: no Tipo: stringa Modificabile: sì Le modifiche diventano effettive immediatamente in tutti i nodi del cluster | Quando il valore è impostato su yes, la proprietà `DEL`agisce come`UNLINK`. |
I parametri rimossi in Redis OSS 6.x sono i seguenti.
| Name | Informazioni | Description |
| --- | --- | --- |
| lua-replicate-commands | Valori consentiti: yes/no (sì/no) Impostazione predefinita: yes (sì) Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente | Abilitare/disabilitare sempre la replica effetti Lua negli script Lua. |
### Modifiche ai parametri Redis OSS 5.0.3
**Famiglia del gruppo di parametri:** redis5.0
Gruppi di parametri predefiniti di Redis OSS 5.0
+ `default.redis5.0`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per cluster e gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata).
+ `default.redis5.0.cluster.on`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per cluster e gruppi di replica Valkey o Redis OSS (modalità cluster enabled).
**Parametri aggiunti in Redis OSS 5.0.3**
| Name | Informazioni | Description |
| --- | --- | --- |
| rename-commands | Impostazione predefinita: none Tipo: stringa Modificabile: sì Le modifiche diventano effettive immediatamente in tutti i nodi del cluster | Un elenco separato da spazi di comandi Redis OSS rinominati. Di seguito è riportato un elenco limitato di comandi disponibili per la ridenominazione: `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` |
Per ulteriori informazioni, consulta [ElastiCache versione 5.0.6 per Redis OSS (migliorata)](engine-versions.md#redis-version-5-0.6).
### Modifiche ai parametri Redis OSS 5.0.0
**Famiglia del gruppo di parametri:** redis5.0
Gruppi di parametri predefiniti di Redis OSS 5.0
+ `default.redis5.0`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per cluster e gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata).
+ `default.redis5.0.cluster.on`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per cluster e gruppi di replica Valkey o Redis OSS (modalità cluster enabled).
**Parametri aggiunti in Redis OSS 5.0**
| Name | Informazioni | Description |
| --- | --- | --- |
| stream-node-max-bytes | Valori consentiti: 0\$1 Impostazione predefinita: 4096 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | La struttura dati del flusso è una struttura radice che codifica più voci al suo interno. Utilizza questa configurazione per specificare le dimensioni massime in byte di un singolo nodo in una struttura radice. Se impostata su 0, il nodo della struttura è illimitato. |
| stream-node-max-entries | Valori consentiti: 0\$1 Impostazione predefinita: 100 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | La struttura dati del flusso è una struttura radice che codifica più voci al suo interno. Utilizza questa configurazione per specificare il numero massimo di elementi che un singolo nodo può contenere prima di passare a un nuovo nodo durante l'accodamento di nuove voci di flusso. Se impostata su 0, il numero delle voci nel nodo della struttura è illimitato |
| active-defrag-max-scan-fields | Valori consentiti: da 1 a 1000000 Impostazione predefinita: 1000 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | Numero massimo di set/hash/zset/list campi che verranno elaborati dalla scansione del dizionario principale |
| lua-replicate-commands | Valori consentiti: yes/no (sì/no) Impostazione predefinita: yes (sì) Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente | Abilitare/disabilitare sempre la replica effetti Lua negli script Lua. |
| replica-ignore-maxmemory | Impostazione predefinita: yes (sì) Tipo: booleano Modificabile: no | Determina se la replica ignora l'impostazione maxmemory senza espellere gli elementi indipendenti dal primario |
Redis OSS ha rinominato diversi parametri nella versione 5.0 del motore in risposta al feedback della community. Per ulteriori informazioni, consulta [Cosa c'è di nuovo in Redis](https://aws.amazon.com/redis/Whats_New_Redis5/) OSS 5? . La tabella seguente elenca i nuovi nomi e il modo in cui vengono mappati alle versioni precedenti.
**Parametri rinominati in Redis OSS 5.0**
| Name | Informazioni | Description |
| --- | --- | --- |
| replica-lazy-flush | Impostazione predefinita: yes (sì) Tipo: booleano Modificabile: no Nome precedente: slave-lazy-flush | Esegue un'operazione flushDB asincrona durante la sincronizzazione della replica. |
| client-output-buffer-limit-replica-hard-limit | Valore di default: per i valori, vedere [Parametri specifici del tipo di nodo Redis OSS](#ParameterGroups.Redis.NodeSpecific) Tipo: Integer Modificabile: no Nome precedente: client-output-buffer-limit - slave-hard-limit | Per le repliche di lettura Redis OSS: se il buffer di output di un client raggiunge il numero di byte specificato, il client verrà disconnesso. |
| client-output-buffer-limit-replica-soft-limit | Valore di default: per i valori, vedere [Parametri specifici del tipo di nodo Redis OSS](#ParameterGroups.Redis.NodeSpecific) Tipo: Integer Modificabile: no Nome precedente: - client-output-buffer-limit slave-soft-limit | Per le repliche di lettura Redis OSS: se il buffer di output di un client raggiunge il numero di byte specificato, il client verrà disconnesso, ma solo se questa condizione persiste. client-output-buffer-limit-replica-soft-seconds |
| client-output-buffer-limit-replica-soft-seconds | Impostazione predefinita: 60 Tipo: Integer Modificabile: no Nome precedente: - client-output-buffer-limit slave-soft-seconds | Per le repliche di lettura Redis OSS: se il buffer di output di un client rimane in client-output-buffer-limit-replica-soft-limit byte per un periodo superiore a questo numero di secondi, il client verrà disconnesso. |
| replica-allow-chaining | Impostazione predefinita: no Tipo: stringa Modificabile: no Nome precedente: slave-allow-chaining | Determina se una replica di lettura in Redis OSS può avere repliche di lettura proprie. |
| min-replicas-to-write | Impostazione predefinita: 0 Tipo: Integer Modificabile: sì Nome precedente: min-slaves-to-write Le modifiche diventano effettive: immediatamente | Il numero minimo di repliche di lettura che deve essere disponibile affinché il nodo principale accetti le operazioni di scrittura dai client. Se il numero di repliche disponibili scende al di sotto di questo numero, il nodo principale non accetterà più richieste di scrittura. Se questo parametro o min-replicas-max-lag è 0, il nodo primario accetterà sempre le richieste di scrittura, anche se non sono disponibili repliche. |
| min-replicas-max-lag | Impostazione predefinita: 10 Tipo: Integer Modificabile: sì Nome precedente: min-slaves-max-lag Le modifiche diventano effettive: immediatamente | Il numero di secondi entro i quali il nodo principale deve ricevere una richiesta di ping da una replica di lettura. Se trascorre questa quantità di tempo e il nodo principale non riceve un ping, la replica non viene più considerata disponibile. Se il numero di repliche disponibili scende al di sotto min-replicas-to-write, a quel punto il primario smetterà di accettare scritture. Se questo parametro o min-replicas-to-write è 0, il nodo primario accetterà sempre le richieste di scrittura, anche se non sono disponibili repliche. |
| close-on-replica-write | Impostazione predefinita: yes (sì) Tipo: booleano Modificabile: sì Nome precedente: close-on-slave-write Le modifiche diventano effettive: immediatamente | Se abilitato, i client che tentano di scrivere in una replica di sola lettura verranno disconnessi. |
**Parametri rimossi in Redis OSS 5.0**
| Name | Informazioni | Description |
| --- | --- | --- |
| repl-timeout | Impostazione predefinita: 60 Modificabile: no | Il parametro non è disponibile in questa versione. |
### Modifiche ai parametri Redis OSS 4.0.10
**Famiglia del gruppo di parametri:** redis4.0
Gruppi di parametri predefiniti di Redis OSS 4.0.x
+ `default.redis4.0`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per i cluster e i gruppi di replica Valkey o Redis OSS (modalità cluster disabilitata).
+ `default.redis4.0.cluster.on`— Utilizzate questo gruppo di parametri, o uno da esso derivato, per cluster e gruppi di replica Valkey o Redis OSS (modalità cluster enabled).
**Parametri modificati in Redis OSS 4.0.10**
| Name | Informazioni | Description |
| --- | --- | --- |
| maxmemory-policy | Valori consentiti: `allkeys-lru`, `volatile-lru`, **allkeys-lfu**, **volatile-lfu**, `allkeys-random`, `volatile-random`, `volatile-ttl`, `noeviction` Impostazione predefinita: volatile-lru Tipo: stringa Modificabile: sì Le modifiche diventano effettive: immediatamente. | maxmemory-policy è stato aggiunto nella versione 2.6.13. Nella versione 4.0.10 sono stati aggiunti due nuovi valori ammessi: allkeys-lfu, che eliminerà qualsiasi chiave utilizzando l'LFU approssimata e volatile-lfu, che effettuerà le eliminazioni utilizzando l'LFU approssimata tra le chiavi con una scadenza impostata. Nella versione 6.2, quando la famiglia di nodi r6gd è stata introdotta per l'uso con il tiering di dati, solo le policy noeviction, volatile-lru e allkeys-lru max-memory sono supportate con i tipi di nodi r6gd. |
**Parametri aggiunti in Redis OSS 4.0.10**
| Name | Informazioni | Description |
| --- |--- |--- |
| **Parametri di eliminazione asincrona** |
| --- |
| lazyfree-lazy-eviction | Valori consentiti: yes/no (sì/no) Impostazione predefinita: no Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente. | Esegue un'eliminazione asincrona sulle espulsioni. |
| lazyfree-lazy-expire | Valori consentiti: yes/no (sì/no) Impostazione predefinita: no Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente. | Esegue un'eliminazione asincrona sulle chiavi scadute. |
| lazyfree-lazy-server-del | Valori consentiti: yes/no (sì/no) Impostazione predefinita: no Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente. | Esegue un'eliminazione asincrona per i comandi che aggiornano i valori. |
| slave-lazy-flush | Valori consentiti: N/D Impostazione predefinita: no Tipo: booleano Modificabile: no Le modifiche diventano effettive: N/D | Esegue un'operazione flushDB asincrona durante la sincronizzazione slave. |
| **Parametri LFU** |
| --- |
| lfu-log-factor | Valori consentiti: qualsiasi numero intero > 0 Impostazione predefinita: 10 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente. | Imposta il fattore di log, che determina il numero di occorrenze delle chiavi per saturare il contatore delle chiavi. |
| lfu-decay-time | Valori consentiti: qualsiasi numero intero Impostazione predefinita: 1 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente. | La quantità di tempo in minuti per diminuire il contatore delle chiavi. |
| **Parametri di deframmentazione attivi** |
| --- |
| activedefrag | Valori consentiti: yes/no (sì/no) Impostazione predefinita: no Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente. | Abilita la deframmentazione attiva. Nelle versioni 7.0 e successive di Valkey e Redis OSS,AWS può eseguire automaticamente la deframmentazione quando necessario dal punto di vista operativo, indipendentemente da questa impostazione. |
| active-defrag-ignore-bytes | Valori consentiti: 10485760-104857600 Impostazione predefinita: 104857600 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente. | Quantità minima di scarto della frammentazione necessaria per avviare la deframmentazione attiva. |
| active-defrag-threshold-lower | Valori consentiti: 1-100 Impostazione predefinita: 10 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente. | Percentuale minima di frammentazione necessaria per avviare la deframmentazione attiva. |
| active-defrag-threshold-upper | Valori consentiti: 1-100 Impostazione predefinita: 100 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente. | Percentuale massima di frammentazione che richiede lo sforzo massimo. |
| active-defrag-cycle-min | Valori consentiti: 1-75 Impostazione predefinita: 25 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente. | Sforzo minimo per la deframmentazione in percentuale di CPU. |
| active-defrag-cycle-max | Valori consentiti: 1-75 Impostazione predefinita: 75 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente. | Sforzo massimo per la deframmentazione in percentuale di CPU. |
| **Parametri buffer di output client** |
| --- |
| client-query-buffer-limit | Valori consentiti: 1048576-1073741824 Impostazione predefinita: 1073741824 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente. | Dimensione massima di un singolo buffer di query client. |
| proto-max-bulk-len | Valori consentiti: 1048576-536870912 Impostazione predefinita: 536870912 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente. | Dimensione massima di una singola richiesta di elementi. |
### Modifiche ai parametri Redis OSS 3.2.10
**Famiglia del gruppo di parametri:** redis3.2
ElastiCache per Redis OSS 3.2.10 non sono supportati parametri aggiuntivi.
### modifiche ai parametri Redis OSS 3.2.6
**Famiglia del gruppo di parametri:** redis3.2
Per Redis OSS 3.2.6 non sono supportati parametri aggiuntivi.
### Modifiche ai parametri Redis OSS 3.2.4
**Famiglia del gruppo di parametri:** redis3.2
A partire da Redis OSS 3.2.4 ci sono due gruppi di parametri predefiniti.
+ `default.redis3.2`— Quando esegui Redis OSS 3.2.4, specifica questo gruppo di parametri o uno da esso derivato, se desideri creare un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) e continuare a utilizzare le funzionalità aggiuntive di Redis OSS 3.2.4.
+ `default.redis3.2.cluster.on`— Specificate questo gruppo di parametri o uno da esso derivato, quando desiderate creare un gruppo di replica Valkey o Redis OSS (abilitata in modalità cluster).
**Topics**
+ [Nuovi parametri per Redis OSS 3.2.4](#ParameterGroups.Redis.3-2-4.New)
+ [Parametri modificati in Redis OSS 3.2.4 (migliorato)](#ParameterGroups.Redis.3-2-4.Changed)
#### Nuovi parametri per Redis OSS 3.2.4
**Famiglia del gruppo di parametri:** redis3.2
Per Redis OSS 3.2.4 sono supportati i seguenti parametri aggiuntivi.
****
| Name | Informazioni | Description |
| --- | --- | --- |
| list-max-ziplist-size | Impostazione predefinita: -2 Tipo: Integer Modificabile: no | Gli elenchi sono codificati in un modo speciale per risparmiare spazio. Il numero di voci consentite per il nodo elenco interno può essere specificato come dimensione massima fissa o numero massimo di elementi. Per una dimensione massima fissa, utilizza da -5 a -1, ovvero: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| list-compress-depth | Impostazione predefinita: 0 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | Gli elenchi possono anche essere compressi. La profondità di compressione (compress depth) è il numero di nodi quicklist ziplist di ciascun lato dell'elenco da escludere dalla compressione. I nodi head e tail dell'elenco vengono sempre decompressi per ottenere operazioni di push e pop rapide. Le impostazioni sono: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| cluster-enabled | Predefinito: \$1 no/yes Tipo: stringa Modificabile: no | Indica se si tratta di un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) in modalità cluster (sì) o di un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) in modalità non cluster (no). I gruppi di replica Valkey o Redis OSS (abilitata in modalità cluster) in modalità cluster possono partizionare i propri dati su un massimo di 500 gruppi di nodi. \$1 Redis OSS 3.2. *x* ha due gruppi di parametri predefiniti. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html). |
| cluster-require-full-coverage | Impostazione predefinita: no Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente | Se impostato su`yes`, i nodi Valkey o Redis OSS (modalità cluster abilitata) in modalità cluster smettono di accettare le query se rilevano che è stato scoperto almeno uno slot hash (nessun nodo disponibile lo serve). In tal caso, se il cluster è parzialmente inattivo, il cluster diventa non disponibile. Diventa automaticamente di nuovo disponibile non appena tutti gli slot sono nuovamente coperti. In alcuni casi, è possibile fare in modo che il sottoinsieme del cluster funzionante continui ad accettare le query da parte dello spazio della chiave ancora coperto. A tale scopo, imposta l'opzione `cluster-require-full-coverage` su `no`. |
| hll-sparse-max-bytes | Impostazione predefinita: 3000 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | HyperLogLog limite di byte di rappresentazione sparsa. Il limite include l'intestazione a 16 byte. Quando si HyperLogLog utilizza la rappresentazione sparsa supera questo limite, viene convertita nella rappresentazione densa. Un valore maggiore di 16000 non è consigliato, perché a quel punto la rappresentazione dense è più efficiente in termini di memoria. È consigliabile un valore di circa 3000 per ottenere i vantaggi della codifica efficiente degli spazi, senza rallentare troppo PFADD, che è impostato su O(N) con la codifica sparse. Il valore può essere aumentato a \$110000 quando la CPU non è un problema, ma lo è lo spazio, e il set di dati è composto da molti dati HyperLogLogs con cardinalità compresa tra 0 e 15000. |
| reserved-memory-percent | Impostazione predefinita: 25 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | La percentuale di memoria di un nodo prenotata per un utilizzo diverso dai dati. Per impostazione predefinita, l'impronta dei dati Redis OSS aumenta fino a consumare tutta la memoria del nodo. In tal caso, le prestazioni del nodo subiranno una riduzione a causa di un eccessivo scambio di pagine di memoria. Riservando la memoria, è possibile riservare parte della memoria disponibile per scopi diversi da Redis OSS per ridurre la quantità di paging. Questo parametro è specifico e non fa parte della distribuzione Redis OSS standard. ElastiCache Per ulteriori informazioni, consultare `reserved-memory` e [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md). |
#### Parametri modificati in Redis OSS 3.2.4 (migliorato)
**Famiglia del gruppo di parametri:** redis3.2
Per Redis OSS 3.2.4 sono stati modificati i seguenti parametri.
****
| Name | Informazioni | Modifica |
| --- | --- | --- |
| activerehashing | Modificabile: Sì se il gruppo di parametri non è associato a nessun cluster. In caso contrario, no. | Non era modificabile |
| databases | Modificabile: Sì se il gruppo di parametri non è associato a nessun cluster. In caso contrario, no. | Non era modificabile |
| appendonly | Impostazione predefinita: off Modificabile: no | Se desideri eseguire l'aggiornamento da una versione precedente di Redis OSS, devi prima disattivarla. `appendonly` |
| appendfsync | Impostazione predefinita: off Modificabile: no | Se desideri eseguire l'aggiornamento da una versione precedente di Redis OSS, devi prima `appendfsync` disattivarla. |
| repl-timeout | Impostazione predefinita: 60 Modificabile: no | Ora non è modificabile con un valore di default di 60. |
| tcp-keepalive | Impostazione predefinita: 300 | Il valore di default era 0. |
| list-max-ziplist-entries | | Il parametro non è più disponibile. |
| list-max-ziplist-value | | Il parametro non è più disponibile. |
### Parametri aggiunti per Redis OSS 2.8.24 (migliorato)
**Famiglia del gruppo di parametri:** redis2.8
Per Redis OSS 2.8.24 non sono supportati parametri aggiuntivi.
### Parametri aggiunti per Redis OSS 2.8.23 (migliorato)
**Famiglia del gruppo di parametri:** redis2.8
Per Redis OSS 2.8.23 è supportato il seguente parametro aggiuntivo.
****
| Name | Informazioni | Description |
| --- | --- | --- |
| close-on-slave-write | Impostazione predefinita: yes (sì) Tipo: stringa (yes/no) Modificabile: sì Le modifiche diventano effettive: immediatamente | Se abilitato, i client che tentano di scrivere in una replica di sola lettura verranno disconnessi. |
#### Funzionamento di close-on-slave-write
Il `close-on-slave-write` parametro è stato introdotto da Amazon ElastiCache per darti un maggiore controllo sulla risposta del cluster quando un nodo primario e un nodo di replica di lettura scambiano i ruoli, promuovendo una replica di lettura a primaria.
![\[Immagine: tutto funziona bene close-on-replica-write\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-01.png)
Se la replica di lettura al cluster viene promossa a replica principale per un motivo diverso dal failover del gruppo di replica con opzione Multi-AZ abilitata, il client continuerà a tentare di scrivere sull'endpoint A. Poiché l'endpoint A è ora l'endpoint per una replica di lettura, le operazioni di lettura avranno esito negativo. Questo è il comportamento di Redis OSS prima dell'ElastiCache introduzione `close-on-replica-write` e il comportamento se lo disabiliti`close-on-replica-write`.
![\[Image: close-on-slave-write, scritture non riuscite\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-02.png)
Con `close-on-replica-write` abilitato, ogni volta che un client tenta di scrivere in una replica di lettura, la connessione client al cluster viene chiusa. La logica dell'applicazione dovrebbe rilevare la disconnessione, controllare la tabella DNS ed eseguire la riconnessione all'endpoint principale, che ora è l'endpoint B.
![\[Immagine: close-on-slave-write, scrittura su un nuovo cluster primario\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-03.png)
#### Quando potresti disabilitare close-on-replica-write
Se disabilitando `close-on-replica-write` le operazioni di scrittura vengono eseguite sul cluster in stato di errore, per quale motivo si dovrebbe eseguire la disabilitazione di `close-on-replica-write`?
Come indicato in precedenza, con `close-on-replica-write` abilitato, ogni volta che un client tenta di scrivere in una replica di lettura, la connessione client al cluster viene chiusa. Stabilire una nuova connessione verso i nodi richiede tempo. Pertanto, la disconnessione e la riconnessione come risultato di una richiesta di scrittura alla replica influiscono anche sulla latenza delle richieste di lettura che vengono soddisfatte attraverso la stessa connessione. Tale effetto persiste fino a quando non viene stabilita una nuova connessione. Se l'applicazione esegue un numero elevato di operazioni di lettura o è molto sensibile alla latenza, potresti preferire che i tuoi client rimangano connessi per evitare una riduzione delle prestazioni in lettura.
### Parametri aggiunti Redis OSS 2.8.22 (migliorato)
**Famiglia del gruppo di parametri:** redis2.8
Per Redis OSS 2.8.22 non sono supportati parametri aggiuntivi.
**Importante**
A partire dalla versione 2.8.22 di Redis OSS, `repl-backlog-size` si applica al cluster primario e ai cluster di replica.
A partire dalla versione 2.8.22 di Redis OSS, il parametro non è supportato. `repl-timeout` Se viene modificato, ElastiCache verrà sovrascritto con quello predefinito (60s), come facciamo con. `appendonly`
I parametri seguenti non sono più supportati.
+ *appendonly*
+ *appendfsync*
+ *repl-timeout*
### Parametri aggiunti a Redis OSS 2.8.21
**Famiglia del gruppo di parametri:** redis2.8
Per Redis OSS 2.8.21, non sono supportati parametri aggiuntivi.
### Parametri aggiunti Redis OSS 2.8.19
**Famiglia del gruppo di parametri:** redis2.8
Per Redis OSS 2.8.19 non sono supportati parametri aggiuntivi.
### Parametri aggiunti Redis OSS 2.8.6
**Famiglia del gruppo di parametri:** redis2.8
Per Redis OSS 2.8.6 sono supportati i seguenti parametri aggiuntivi.
****
| Name | Informazioni | Description |
| --- | --- | --- |
| min-slaves-max-lag | Impostazione predefinita: 10 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | Il numero di secondi entro i quali il nodo principale deve ricevere una richiesta di ping da una replica di lettura. Se trascorre questa quantità di tempo e il nodo principale non riceve un ping, la replica non viene più considerata disponibile. Se il numero di repliche disponibili scende al di sotto min-slaves-to-write, a quel punto la principale smetterà di accettare scritture. Se questo parametro o min-slaves-to-write è 0, il nodo primario accetterà sempre le richieste di scrittura, anche se non sono disponibili repliche. |
| min-slaves-to-write | Impostazione predefinita: 0 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | Il numero minimo di repliche di lettura che deve essere disponibile affinché il nodo principale accetti le operazioni di scrittura dai client. Se il numero di repliche disponibili scende al di sotto di questo numero, il nodo principale non accetterà più richieste di scrittura. Se questo parametro o min-slaves-max-lag è 0, il nodo primario accetterà sempre le richieste di scrittura, anche se non sono disponibili repliche. |
| notify-keyspace-events | Impostazione predefinita: (una stringa vuota) Tipo: stringa Modificabile: sì Le modifiche diventano effettive: immediatamente | I tipi di eventi keyspace che Redis OSS può notificare ai client. Ogni tipo di evento è rappresentato da una lettera singola: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) Può verificarsi una combinazione di questi tipi di eventi. Ad esempio, *AKE* significa che Redis OSS può pubblicare notifiche di tutti i tipi di eventi. Non utilizzare caratteri diversi da quelli elencati sopra, altrimenti verranno restituiti messaggi di errore. Per impostazione predefinita, questo parametro è impostato su una stringa vuota, a indicare che la notifica per l'evento keyspace è disabilitato. |
| repl-backlog-size | Impostazione predefinita: 1048576 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | La dimensione in byte del buffer di backlog del nodo principale. Il backlog viene utilizzato per la registrazione degli aggiornamenti apportati ai dati sul nodo principale. Quando una replica di lettura si connette al nodo principale, tenta di eseguire una sincronizzazione parziale (`psync`), durante la quale i dati del backlog vengono applicati per il recupero tramite il nodo principale. Se `psync` ha esito negativo, è richiesta una sincronizzazione completa. Il valore minimo per questo parametro è 16384. A partire da Redis OSS 2.8.22, questo parametro si applica al cluster primario e alle repliche di lettura. |
| repl-backlog-ttl | Impostazione predefinita: 3600 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | Numero di secondi durante i quali il nodo principale manterrà il buffer di backlog. A partire dalla disconnessione dell'ultimo nodo di replica, i dati nel backlog rimangono intatti fino alla scadenza di `repl-backlog-ttl`. Se la replica non viene connessa al nodo principale entro questo periodo di tempo, il nodo principale rilascerà il buffer di backlog. Qualora la replica dovesse riconnettersi, dovrà eseguire una sincronizzazione completa con il nodo principale. Se questo parametro è impostato su 0, il buffer di backlog non verrà mai rilasciato. |
| repl-timeout | Impostazione predefinita: 60 Tipo: Integer Modificabile: sì Le modifiche diventano effettive: immediatamente | Rappresenta il periodo di timeout in secondi per: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
### Parametri Redis OSS 2.6.13
**Famiglia del gruppo di parametri:** redis2.6
Redis OSS 2.6.13 è stata la prima versione di Redis OSS supportata da. ElastiCache La tabella seguente mostra i parametri Redis OSS 2.6.13 supportati. ElastiCache
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html)
**Nota**
Se non specificate un gruppo di parametri per il cluster Redis OSS 2.6.13, verrà utilizzato un gruppo di parametri predefinito ()`default.redis2.6`. Non puoi modificare i valori dei parametri nel gruppo di parametri di default, ma puoi sempre creare un gruppo di parametri personalizzato e assegnarlo al tuo cluster in qualsiasi momento.
### Parametri specifici del tipo di nodo Redis OSS
Sebbene la maggior parte dei parametri abbia un valore singolo, alcuni parametri hanno diversi valori in base al tipo di nodo utilizzato. La tabella seguente mostra i valori predefiniti dei parametri `maxmemory`, `client-output-buffer-limit-slave-hard-limit` e `client-output-buffer-limit-slave-soft-limit` per ciascun tipo di nodo. Il valore di `maxmemory` è il numero massimo di byte disponibili sul nodo per utilizzo, dati e altro. Per ulteriori informazioni consulta [Memoria disponibile](https://aws.amazon.com/premiumsupport/knowledge-center/available-memory-elasticache-redis-node/).
**Nota**
Il parametro `maxmemory` non può essere modificato.
| Tipo di nodo | Maxmemory | lient-output-buffer-limitC - 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 |
| cache.r6g.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r6g.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r6g.8xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.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 |
**Nota**
Tutti i tipi di istanza della generazione corrente sono creati in Amazon Virtual Private Cloud VPC per impostazione predefinita.
Le istanze T1 non supportano la funzione Multi-AZ.
Le istanze T1 e T2 non supportano Redis OSS AOF.
Le variabili di configurazione Redis OSS `appendonly` e non `appendfsync` sono supportate su Redis OSS versione 2.8.22 e successive.
## Parametri Memcached specifici
**Memcached**
Se non specifichi un gruppo di parametri per il cluster Memcached, verrà utilizzato un gruppo di parametri di default appropriato per la versione del motore. Non è possibile modificare nessun valore all'interno del gruppo di parametri di default. Tuttavia, è possibile creare un gruppo di parametri personalizzato e assegnarlo al cluster in qualsiasi momento. Per ulteriori informazioni, consulta [Creazione di un gruppo di ElastiCache parametri](ParameterGroups.Creating.md).
**Topics**
+ [Modifiche di Memcached 1.6.17](#ParameterGroups.Memcached.1.6.17)
+ [Parametri di Memcached 1.6.6 aggiunti](#ParameterGroups.Memcached.1-6-6)
+ [Modifiche dei parametri di Memcached 1.5.10](#ParameterGroups.Memcached.1-5-10)
+ [Parametri di Memcached 1.4.34 aggiunti](#ParameterGroups.Memcached.1-4-34)
+ [Parametri di Memcached 1.4.33 aggiunti](#ParameterGroups.Memcached.1-4-33)
+ [Parametri di Memcached 1.4.24 aggiunti](#ParameterGroups.Memcached.1-4-24)
+ [Parametri di Memcached 1.4.14 aggiunti](#ParameterGroups.Memcached.1-4-14)
+ [Parametri di Memcached 1.4.5 supportati](#ParameterGroups.Memcached.1-4-5)
+ [Sovraccarico delle connessioni Memcached](#ParameterGroups.Memcached.Overhead)
+ [Parametri specifici del tipo di nodo Memcached](#ParameterGroups.Memcached.NodeSpecific)
### Modifiche di Memcached 1.6.17
A partire da Memcached 1.6.17 non sono più supportati questi comandi amministrativi: `lru_crawler`, `lru` e `slabs`. Con queste modifiche, non sarà possibile farlo in enable/disable `lru_crawler` fase di esecuzione tramite comandi. Per favore, enable/disable `lru_crawler` modificando il gruppo di parametri personalizzato.
### Parametri di Memcached 1.6.6 aggiunti
Per Memcached 1.6.6, non sono supportati parametri aggiuntivi.
**Famiglia del gruppo di parametri:** memcached1.6
### Modifiche dei parametri di Memcached 1.5.10
Per Memcached 1.5.10, sono supportati i seguenti parametri aggiuntivi.
**Famiglia del gruppo di parametri:** memcached1.5
| Name | Informazioni | Description |
| --- | --- | --- |
| no\$1modern | Impostazione predefinita: 1 Tipo: booleano Modificabile: sì Valori consentiti: 0,1 Modificazioni hanno effetto: All’avvio | Un alias per disabilitare i comandi`slab_reassign`, `lru_maintainer_thread``lru_segmented`, e. `maxconns_fast` Quando si utilizza Memcached 1.5 e versioni successive, imposta `no_modern` anche hash\$1algorithm su. `jenkins` Inoltre, quando si utilizza Memcached 1.5.10, è controllato dal parametro. `inline_ascii_reponse` `parallelly` Ciò significa che se `no_modern` è disabilitato allora è disabilitato. `inline_ascii_reponse` Dal motore Memcached 1.5.16 in poi il `inline_ascii_response` parametro non si applica più, quindi `no_modern` essere abilitato o disabilitato non ha alcun effetto su. `inline_ascii_reponse` Se `no_modern` è disabilitato, allora,, `slab_reassign` e `lru_maintainer_thread` sarà abilitato. `lru_segmented` `maxconns_fast` Poiché `hash_algorithm` i parametri `slab_automove` e non sono parametri SWITCH, la loro impostazione si basa sulle configurazioni nel gruppo di parametri. Se si desidera disabilitare `no_modern` e ripristinare`modern`, è necessario configurare un gruppo di parametri personalizzato per disabilitare questo parametro e quindi riavviare il sistema per rendere effettive le modifiche. Il valore di configurazione di default per questo parametro è stato modificato da 0 a 1 a partire dal 20 agosto 2021. Il valore predefinito aggiornato verrà rilevato automaticamente dai nuovi ElastiCache utenti per ogni regione dopo il 20 agosto 2021. ElastiCache Gli utenti esistenti nelle regioni prima del 20 agosto 2021 devono modificare manualmente i propri gruppi di parametri personalizzati per rilevare questa nuova modifica. |
| inline\$1ascii\$1resp | Impostazione predefinita: 0 Tipo: booleano Modificabile: sì Valori consentiti: 0,1 Modificazioni hanno effetto: Al lancio | Archivia i numeri dalla risposta `VALUE` in una voce usando fino a 24 byte. Lieve rallentamento dei set ASCII `get`, `faster`. |
Per Memcached 1.5.10, i seguenti parametri sono stati rimossi.
| Name | Informazioni | Description |
| --- | --- | --- |
| expirezero\$1does\$1not\$1evict | Impostazione predefinita: 0 Tipo: booleano Modificabile: sì Valori consentiti: 0,1 Modificazioni hanno effetto: Al lancio | Non più supportati in questa versione. |
| modern | Impostazione predefinita: 1 Tipo: booleano Modificabile: Sì (richiede il riavvio, se impostato su `no_modern`) Valori consentiti: 0,1 Modificazioni hanno effetto: Al lancio | Non più supportati in questa versione. A partire da questa versione `no-modern` è abilitato per impostazione predefinita a ogni avvio o riavvio. |
### Parametri di Memcached 1.4.34 aggiunti
Per Memcached 1.4.34, non sono supportati parametri aggiuntivi.
**Famiglia del gruppo di parametri:** memcached1.4
### Parametri di Memcached 1.4.33 aggiunti
Per Memcached 1.4.33, sono supportati i seguenti parametri aggiuntivi.
**Famiglia del gruppo di parametri:** memcached1.4
| Name | Informazioni | Description |
| --- | --- | --- |
| modern | Impostazione predefinita: abilitato Tipo: booleano Modificabile: sì Modificazioni hanno effetto: Al lancio | Un alias per più funzionalità. L'abilitazione di `modern` equivale all'attivazione dei seguenti comandi e all'utilizzo dell'algoritmo hash murmur3: `slab_reassign`, `slab_automove`, `lru_crawler`, `lru_maintainer`, `maxconns_fast` e `hash_algorithm=murmur3`. |
| watch | Impostazione predefinita: abilitato Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente I log possono essere eliminati se l'utente raggiunge i limiti relativi a `watcher_logbuf_size` e `worker_logbuf_size`. | Recupero, espulsione o mutazione di log. Ad esempio, quando un utente attiva `watch`, può visualizzare i log quando si verifica `get`, `set`, `delete` o `update`. |
| idle\$1timeout | Impostazione predefinita: 0 (disabilitato) Tipo: Integer Modificabile: sì Le modifiche diventano effettive: Al lancio | Il numero minimo di secondi durante i quali un client può essere inattivo prima che ne venga richiesta la chiusura. Intervallo di valori: da 0 a 86400. |
| track\$1sizes | Impostazione predefinita: disabilitato Tipo: booleano Modificabile: sì Le modifiche diventano effettive: Al lancio | Mostra le dimensioni utilizzate da ciascun gruppo di slab. L'abilitazione di `track_sizes` consente di eseguire `stats sizes` senza dover eseguire `stats sizes_enable`. |
| watcher\$1logbuf\$1size | Impostazione predefinita: 256 (KB) Tipo: Integer Modificabile: sì Le modifiche diventano effettive: Al lancio | Il comando `watch` abilita la registrazione del flusso per Memcached. `watch` può tuttavia eliminare i log se il tasso di espulsioni, mutazioni o recuperi è sufficientemente elevato per riempire il buffer di registrazione. In tali situazioni, gli utenti possono aumentare le dimensioni del buffer in modo da ridurre la possibile perdita di log. |
| worker\$1logbuf\$1size | Impostazione predefinita: 64 (KB) Tipo: Integer Modificabile: sì Le modifiche diventano effettive: Al lancio | Il comando `watch` abilita la registrazione del flusso per Memcached. `watch` può tuttavia eliminare i log se il tasso di espulsioni, mutazioni o recuperi è sufficientemente elevato per riempire il buffer di registrazione. In tali situazioni, gli utenti possono aumentare le dimensioni del buffer in modo da ridurre la possibile perdita di log. |
| slab\$1chunk\$1max | Impostazione predefinita: 524288 (byte) Tipo: Integer Modificabile: sì Le modifiche diventano effettive: Al lancio | Specifica le dimensioni massime di uno slab. Impostando una dimensione inferiore di slab viene utilizzata una memoria più efficiente. Gli elementi più grandi di `slab_chunk_max` sono suddivisi in più slab. |
| lru\$1crawler metadump [all\$11\$12\$13] | Impostazione predefinita: disabilitato Tipo: booleano Modificabile: sì Le modifiche diventano effettive: immediatamente | Se lru\$1crawler è abilitato questo comando effettua il dump di tutte le chiavi. `all\|1\|2\|3`: tutti gli slab o specificare un determinato numero di slab |
### Parametri di Memcached 1.4.24 aggiunti
Per Memcached 1.4.24, sono supportati i seguenti parametri aggiuntivi.
**Famiglia del gruppo di parametri:** memcached1.4
| Name | Informazioni | Description |
| --- | --- | --- |
| disable\$1flush\$1all | Impostazione predefinita: 0 (disabilitato) Tipo: booleano Modificabile: sì Modificazioni hanno effetto: Al lancio | Aggiungere il parametro (`-F`) per disabilitare flush\$1all. Utile se non desideri poter eseguire uno svuotamento completo sulle istanze di produzione. Valori: 0, 1 (l'utente può utilizzare il parametro `flush_all` quando il valore è 0). |
| hash\$1algorithm | Impostazione predefinita: jenkins Tipo: stringa Modificabile: sì Modificazioni hanno effetto: Al lancio | L'algoritmo hash da utilizzare. Valori consentiti: murmur3 e jenkins. |
| lru\$1crawler | Impostazione predefinita: 0 (disabilitato) Tipo: booleano Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio Puoi abilitare temporaneamente `lru_crawler` in fase di runtime dalla riga di comando. Per ulteriori informazioni, consulta la colonna Descrizione. | Pulisce le classi di slab degli elementi scaduti. Si tratta di un processo a basso impatto che viene eseguito in background. Attualmente richiede l'avvio di un crawling tramite l'utilizzo di un comando manuale. Per un'abilitazione temporanea, esegui il comando `lru_crawler enable` alla riga di comando. `lru_crawler 1,3,5` esegue il crawling delle classi slab 1, 3 e 5 per cercare elementi scaduti da aggiungere all'elenco libero. Valori: 0,1 L'abilitazione di `lru_crawler` alla riga di comando abilita il crawler finché non viene disabilitato alla riga di comando o al successivo riavvio. Per abilitarlo in modo permanente, devi modificare il valore del parametro. Per ulteriori informazioni, consulta [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md). |
| lru\$1maintainer | Impostazione predefinita: 0 (disabilitato) Tipo: booleano Modificabile: sì Le modifiche diventano effettive: Al lancio | Un thread in background che mescola gli elementi tra i due LRUs quando viene raggiunta la capacità. Valori: 0, 1. |
| expirezero\$1does\$1not\$1evict | Impostazione predefinita: 0 (disabilitato) Tipo: booleano Modificabile: sì Modificazioni hanno effetto: Al lancio | Quando utilizzato con `lru_maintainer`, rende gli elementi non soggetti a espulsione con un tempo di scadenza pari a 0. Ciò consente di togliere spazio di memoria disponibile per gli elementi soggetti a espulsione. Può essere impostato in modo da ignorare `lru_maintainer`. |
### Parametri di Memcached 1.4.14 aggiunti
Per Memcached 1.4.14, sono supportati i seguenti parametri aggiuntivi.
**Famiglia del gruppo di parametri:** memcached1.4
**Parametri aggiunti in Memcached 1.4.14**
| Name | Informazioni | Description |
| --- | --- | --- |
| config\$1max | Impostazione predefinita: 16 Tipo: Integer Modificabile: no | Il numero massimo di voci di configurazione. ElastiCache |
| config\$1size\$1max | Impostazione predefinita: 65536 Tipo: Integer Modificabile: no | Dimensione massima delle voci di configurazione, in byte. |
| hashpower\$1init | Impostazione predefinita: 16 Tipo: Integer Modificabile: no | La dimensione iniziale della tabella ElastiCache hash, espressa come potenza di due. L'impostazione 16 (2^16) o 65536 chiavi. |
| maxconns\$1fast | Impostazione predefinita: 0(false) Tipo: Booleano Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | Modifica il modo in cui vengono gestite le nuove richieste di connessione quando viene raggiunto il limite massimo di connessioni. Se questo parametro è impostato su 0 (zero), nuove connessioni vengono aggiunte alla coda di backlog e verrà attesa la chiusura delle altre connessioni. Se il parametro è impostato su 1, ElastiCache invia un errore al client e chiude immediatamente la connessione. |
| slab\$1automove | Impostazione predefinita: 0 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | Regola l'algoritmo slab automove: se questo parametro è impostato su 0 (zero), l'algoritmo è disabilitato. Se è impostato su 1, ElastiCache utilizza un lento approccio tradizionale per lo spostamento automatico degli slab. Se è impostato su 2, sposta le lastre ElastiCache in modo aggressivo ogni volta che si verifica uno sfratto. Questa modalità è consigliabile esclusivamente a scopo di test. |
| slab\$1reassign | Impostazione predefinita: 0(false) Tipo: Booleano Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | Abilitare o disabilitare la riassegnazione dello slab. Se questo parametro è impostato su 1, puoi utilizzare il comando di "riassegnazione slab" (slab\$1reassign) per riassegnare manualmente la memoria. |
### Parametri di Memcached 1.4.5 supportati
**Famiglia del gruppo di parametri:** memcached1.4
Per Memcached 1.4.5, sono supportati i seguenti parametri.
**Parametri aggiunti in Memcached 1.4.5**
| Name | Informazioni | Description |
| --- | --- | --- |
| backlog\$1queue\$1limit | Impostazione predefinita: 1024 Tipo: Integer Modificabile: no | Limite della coda di backlog. |
| binding\$1protocol | Impostazione predefinita: auto Tipo: stringa Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | Il protocollo di binding. Valori consentiti: `ascii` e `auto`. Per ulteriori informazioni sulla modifica del valore di `binding_protocol`, consulta [Modifica di un gruppo di ElastiCache parametri](ParameterGroups.Modifying.md). |
| cas\$1disabled | Impostazione predefinita: 0(false) Tipo: Booleano Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | Se 1 (true), le operazioni di controllo e impostazione (CAS) verranno disabilitate e gli elementi archiviati utilizzeranno 8 byte in meno rispetto a quando CAS è abilitato. |
| chunk\$1size | Impostazione predefinita: 48 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | La quantità minima, in byte, di spazio da allocare per chiave, valore e flag dell'elemento più piccolo. |
| chunk\$1size\$1growth\$1factor | Impostazione predefinita: 1.25 Tipo: Float Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | Il fattore di crescita che controlla le dimensioni di ciascun successivo blocco di Memcached. Ciascun blocco sarà maggiore del precedente in base al valore di chunk\$1size\$1growth\$1factor. |
| error\$1on\$1memory\$1exhausted | Impostazione predefinita: 0(false) Tipo: Booleano Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | Se 1 (true), quando si esaurisce la memoria per archiviare gli elementi, Memcached restituirà un errore anziché espellere gli elementi. |
| large\$1memory\$1pages | Impostazione predefinita: 0(false) Tipo: Booleano Modificabile: no | Se 1 (true), ElastiCache proverà a utilizzare pagine di memoria di grandi dimensioni. |
| lock\$1down\$1paged\$1memory | Impostazione predefinita: 0(false) Tipo: Booleano Modificabile: no | Se 1 (true), ElastiCache bloccherà tutta la memoria paginata. |
| max\$1item\$1size | Impostazione predefinita: 1048576 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | La dimensione, in byte, dell'elemento più grande che può essere archiviato nel cluster. |
| max\$1simultaneous\$1connections | Impostazione predefinita: 65000 Tipo: Integer Modificabile: no | Il numero massimo di connessioni simultanee. |
| maximize\$1core\$1file\$1limit | Impostazione predefinita: 0(false) Tipo: Booleano Modificabile: Le modifiche hanno effetto: Dopo il riavvio | Se 1 (true), ElastiCache massimizzerà il limite del file principale. |
| memcached\$1connections\$1overhead | Impostazione predefinita: 100 Tipo: Integer Modificabile: sì Le modifiche hanno effetto: Dopo il riavvio | La quantità di memoria da riservare per le connessioni Memcached e altro sovraccarico vario. Per informazioni su questo parametro, consulta [Sovraccarico delle connessioni Memcached](#ParameterGroups.Memcached.Overhead). |
| requests\$1per\$1event | Impostazione predefinita: 20 Tipo: Integer Modificabile: no | Il numero massimo di richieste per evento per una connessione specifica. Questo limite è necessario per evitare un uso eccessivo delle risorse. |
### Sovraccarico delle connessioni Memcached
Su ciascun nodo, la memoria resa disponibile per l'archiviazione degli elementi è la memoria totale disponibile sul nodo, archiviata nel parametro `max_cache_memory`, meno la memoria utilizzata per le connessioni e altro sovraccarico, archiviata nel parametro `memcached_connections_overhead`. Un nodo di tipo `cache.m1.small` ha ad esempio un valore di `max_cache_memory` pari a 1300 MB. Con il valore `memcached_connections_overhead` di default di 100 MB, il processo Memcached avrà 1200 MB disponibili per archiviare gli elementi.
I valori predefiniti per il parametro `memcached_connections_overhead` sono sufficienti nella maggior parte dei casi. La quantità di allocazione richiesta per il sovraccarico delle connessioni può tuttavia variare in base a più fattori, tra cui tasso di richiesta, dimensione del payload e numero di connessioni.
Puoi modificare il valore di `memcached_connections_overhead` per soddisfare al meglio le esigenze della tua applicazione. Aumentando ad esempio il valore del parametro `memcached_connections_overhead` otterrai la riduzione della quantità di memoria disponibile per l'archiviazione degli elementi e verrà reso disponibile un buffer di dimensioni maggiori per il sovraccarico delle connessioni. Riducendo il valore del parametro `memcached_connections_overhead` avrai a disposizione una maggiore quantità di memoria per archiviare gli elementi, sebbene ciò aumenti il rischio di utilizzo di swap e di riduzione delle prestazioni. Se riscontri utilizzo dello swap e riduzione delle prestazioni, prova ad aumentare il valore del parametro `memcached_connections_overhead`.
**Importante**
Per il tipo di nodo `cache.t1.micro`, il valore di `memcached_connections_overhead` viene determinato come segue:
Se il cluster utilizza il gruppo di parametri predefinito, ElastiCache imposterà il valore su 13 `memcached_connections_overhead` MB.
Se il cluster utilizza un gruppo di parametri che tu hai creato, puoi impostare `memcached_connections_overhead` su un valore di tua scelta.
### Parametri specifici del tipo di nodo Memcached
Sebbene la maggior parte dei parametri abbia un valore singolo, alcuni parametri hanno diversi valori in base al tipo di nodo utilizzato. La tabella seguente mostra i valori predefiniti dei parametri `max_cache_memory` e `num_threads` per ciascun tipo di nodo. I valori di questi parametri non possono essere modificati.
| Tipo di nodo | 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 |
| cache.m6g.2xlarge | 26671 | 8 |
| cache.m6g.4xlarge | 53516 | 16 |
| cache.m6g.8xlarge | 107000 | 32 |
| cache.m6g.12xlarge | 160900 | 48 |
| cache.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 |
| cache.r6g.2xlarge | 54084 | 8 |
| cache.r6g.4xlarge | 108347 | 16 |
| cache.r6g.8xlarge | 214577 | 32 |
| cache.r6g.12xlarge | 325400 | 48 |
| cache.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 |
**Nota**
Tutte le istanze T2 vengono create in Amazon Virtual Private Cloud (Amazon VPC).
# Connessione automatica di un' EC2 istanza e di una ElastiCache cache
Puoi utilizzare la ElastiCache console per semplificare la configurazione di una connessione tra un'istanza Amazon Elastic Compute Cloud (Amazon EC2) e una ElastiCache cache. Spesso, la cache si trova in una sottorete privata e l' EC2 istanza si trova in una sottorete pubblica all'interno di un VPC. Puoi usare un client SQL sull' EC2 istanza per connetterti alla cache. ElastiCache L' EC2 istanza può anche eseguire server Web o applicazioni che accedono alla ElastiCache cache privata.
![\[Connetti automaticamente una ElastiCache cache a un' EC2 istanza.\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ec2-elasticache-connect-network_diagram.png)
**Topics**
+ [Connettività automatica con un' EC2 istanza](#ec2-elc-connect-overview)
+ [Visualizzazione delle risorse di calcolo connesse](#ec2-elc-connect-viewing)
## Connettività automatica con un' EC2 istanza
Quando configuri una connessione tra un' EC2 istanza e una ElastiCache cache, configura ElastiCache automaticamente il gruppo di sicurezza VPC per l'istanza e per EC2 ElastiCache la cache.
Di seguito sono riportati i requisiti per connettere un' EC2 istanza a una ElastiCache cache:
+ L' EC2 istanza deve esistere nello stesso VPC della ElastiCache cache.
Se non esistono EC2 istanze nello stesso VPC, la console fornisce un collegamento per crearne una.
+ L'utente che configura la connettività deve disporre delle autorizzazioni per eseguire le seguenti EC2 operazioni Amazon. Queste autorizzazioni vengono generalmente aggiunte agli EC2 account al momento della creazione. Per ulteriori informazioni sulle EC2 autorizzazioni, consulta [Concessione delle autorizzazioni richieste per le risorse Amazon](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/ec2-api-permissions.html). EC2
+ `ec2:AuthorizeSecurityGroupEgress`
+ `ec2:AuthorizeSecurityGroupIngress`
+ `ec2:CreateSecurityGroup`
+ `ec2:DescribeInstances`
+ `ec2:DescribeNetworkInterfaces`
+ `ec2:DescribeSecurityGroups`
+ `ec2:ModifyNetworkInterfaceAttribute`
+ `ec2:RevokeSecurityGroupEgress`
Quando configuri una connessione a un' EC2 istanza, ElastiCache agisce in base alla configurazione corrente dei gruppi di sicurezza associati alla ElastiCache cache e all' EC2 istanza, come descritto nella tabella seguente.
****
| Configurazione attuale del gruppo di ElastiCache sicurezza | Configurazione attuale del gruppo di EC2 sicurezza | ElastiCache azione |
| --- | --- | --- |
| Esistono uno o più gruppi di sicurezza associati alla ElastiCache cache con un nome che corrisponde al modello`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Un gruppo di sicurezza che corrisponde al modello non è stato modificato. Questo gruppo di sicurezza ha una sola regola in entrata con il gruppo di sicurezza VPC EC2 dell'istanza come origine. | All' EC2 istanza sono associati uno o più gruppi di sicurezza con un nome che corrisponde al modello. `elasticache-ec2-${cacheId}:${ec2InstanceId}` Un gruppo di sicurezza che corrisponde al modello non è stato modificato. Questo gruppo di sicurezza ha una sola regola in uscita con il gruppo di sicurezza VPC ElastiCache della cache come origine. | ElastiCache non esegue alcuna azione. Una connessione era già configurata automaticamente tra l' EC2 istanza e la ElastiCache cache. Poiché esiste già una connessione tra l' EC2 istanza e la ElastiCache cache, i gruppi di sicurezza non vengono modificati. |
| Si applica una delle due condizioni seguenti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/compute-connection.html) | Si applica una delle due condizioni seguenti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/compute-connection.html) | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| Esistono uno o più gruppi di sicurezza associati alla ElastiCache cache con un nome che corrisponde al modello`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Un gruppo di sicurezza che corrisponde al modello non è stato modificato. Questo gruppo di sicurezza ha una sola regola in entrata con il gruppo di sicurezza VPC EC2 dell'istanza come origine. | All' EC2 istanza sono associati uno o più gruppi di sicurezza con un nome che corrisponde al modello. `elasticache-ec2-${cacheId}:${ec2InstanceId}` Tuttavia, non è ElastiCache possibile utilizzare nessuno di questi gruppi di sicurezza per la connessione con la ElastiCache cache. ElastiCache non può utilizzare un gruppo di sicurezza che non ha una regola in uscita con il gruppo di sicurezza VPC ElastiCache della cache come origine. ElastiCache inoltre non può utilizzare un gruppo di sicurezza che è stato modificato. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| Esistono uno o più gruppi di sicurezza associati alla ElastiCache cache con un nome che corrisponde al modello`elasticache-ec2-${cacheId}:${ec2InstanceId}`. Un gruppo di sicurezza che corrisponde al modello non è stato modificato. Questo gruppo di sicurezza ha una sola regola in entrata con il gruppo di sicurezza VPC EC2 dell'istanza come origine. | Esiste un gruppo EC2 di sicurezza valido per la connessione, ma non è associato all' EC2 istanza. Questo gruppo di sicurezza ha un nome che corrisponde al modello `ec2-elasticache-${ec2InstanceId}:${cacheId}`. Non è stato modificato. Ha solo una regola in uscita con il gruppo di sicurezza VPC theElastiCache della cache come origine. | [ELC action: associate EC2 security group](#elc-action-associate-ec2-security-group) |
| Si applica una delle due condizioni seguenti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/compute-connection.html) | Esistono uno o più gruppi di sicurezza associati all' EC2 istanza con un nome che corrisponde al modello`ec2-elasticache-${ec2InstanceId}:${cacheId}`. Un gruppo di sicurezza che corrisponde al modello non è stato modificato. Questo gruppo di sicurezza ha una sola regola in uscita con il gruppo di sicurezza VPC ElastiCache della cache come origine. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
**ElastiCacheazione: creare nuovi gruppi di sicurezza**
ElastiCache esegue le seguenti azioni:
+ Crea un nuovo gruppo di sicurezza che corrisponde al modello `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Questo gruppo di sicurezza ha una regola in entrata con il gruppo di sicurezza VPC EC2 dell'istanza come origine. Questo gruppo di sicurezza è associato alla ElastiCache cache e consente all' EC2 istanza di accedervi.
+ Crea un nuovo gruppo di sicurezza che corrisponde al modello `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Questo gruppo di sicurezza ha una regola in uscita con il gruppo di sicurezza VPC ElastiCache della cache come destinazione. Questo gruppo di sicurezza è associato all' EC2 istanza e consente all' EC2 istanza di inviare traffico alla ElastiCache cache.
**ElastiCache azione: associare un gruppo EC2 di sicurezza**
ElastiCacheassocia il gruppo di EC2 sicurezza valido ed esistente all' EC2 istanza. Questo gruppo di sicurezza consente all' EC2istanza di inviare traffico alla ElastiCache cache.
## Visualizzazione delle risorse di calcolo connesse
È possibile utilizzare il Console di gestione AWS per visualizzare le risorse di calcolo connesse a una ElastiCache cache. Le risorse mostrate includono le connessioni delle risorse di calcolo configurate automaticamente. Ad esempio, puoi consentire a una risorsa di calcolo di accedere manualmente a una cache aggiungendo una regola al gruppo di sicurezza VPC associato alla cache. Queste risorse non verranno visualizzate nell'elenco delle risorse di elaborazione connesse.
Affinché una risorsa di calcolo venga elencata, devono essere applicate le stesse condizioni di quando si connette automaticamente un' EC2 istanza e una ElastiCache cache.
**Per visualizzare le risorse di calcolo connesse a una cache ElastiCache**
1. Accedi a Console di gestione AWS e apri la console ElastiCache
1. Nel pannello di navigazione, scegli **Cache, quindi scegli una cache** Valkey o Redis OSS.
1. Nella scheda **Connettività e sicurezza**, visualizza le risorse di elaborazione nella sezione **Configura** connessione di calcolo.
![\[Risorse di calcolo connesse.\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ec2-elasticache-connected_resources.png)
# Ridimensionamento ElastiCache
Puoi scalare la ElastiCache cache in base alle tue esigenze. Le cache serverless e i cluster basati su nodi offrono diverse opzioni di scalabilità.
## ElastiCache Scalabilità senza server
ElastiCache Serverless si adatta automaticamente al traffico del carico di lavoro man mano che aumenta o diminuisce. Per ogni cache ElastiCache Serverless, monitora ElastiCache continuamente l'utilizzo di risorse come CPU, memoria e rete. Quando una di queste risorse è limitata, ElastiCache Serverless esegue la scalabilità orizzontale aggiungendo un nuovo shard e ridistribuendo i dati sul nuovo shard, senza tempi di inattività dell'applicazione. È possibile monitorare le risorse utilizzate dalla cache monitorando la `BytesUsedForCache` metrica per l'archiviazione dei dati nella CloudWatch cache e (ECPU) per l'utilizzo dell'elaborazione. `ElastiCacheProcessingUnits`
## Impostazione dei limiti di dimensionamento per gestire i costi
Puoi scegliere di configurare un utilizzo massimo sia per l'archiviazione dei dati della cache che per la cache ECPU/second per controllare i costi della cache. In questo modo ti assicuri che l'utilizzo della cache non superi mai il limite massimo configurato.
Se si imposta una scalabilità massima, l'applicazione potrebbe subire una riduzione delle prestazioni della cache quando la cache raggiunge il massimo. Quando impostate un valore massimo di archiviazione dei dati nella cache e l'archiviazione dei dati della cache raggiunge il massimo, ElastiCache inizierà a rimuovere i dati dalla cache con un set Time-To-Live (TTL), utilizzando la logica LRU. Se non sono disponibili dati che possono essere sottoposti a espulsione, le richieste di scrittura di dati aggiuntivi restituiscono un messaggio di errore di memoria insufficiente (OOM). Quando imposti un ECPU/second valore massimo e l'utilizzo di calcolo del carico di lavoro supera questo valore, inizieranno a limitare le richieste. ElastiCache
Se imposti un limite massimo su `BytesUsedForCache` o`ElastiCacheProcessingUnits`, ti consigliamo vivamente di impostare un CloudWatch allarme a un valore inferiore al limite massimo in modo da ricevere una notifica quando la cache funziona in prossimità di questi limiti. Ti consigliamo di impostare l'allarme al 75% del limite massimo configurato. Consulta la documentazione su come configurare gli CloudWatch allarmi.
## Prescalabilità con Serverless ElastiCache
**ElastiCache Prescalabilità senza server**
Con il preridimensionamento, chiamato anche preriscaldamento, è possibile impostare limiti minimi supportati per la cache. ElastiCache È possibile impostare questi valori minimi per le unità di ElastiCache elaborazione (ECPUs) al secondo o per l'archiviazione dei dati. Ciò può essere utile in preparazione agli eventi di scalabilità previsti. Ad esempio, se una società di giochi prevede un aumento di 5 volte degli accessi entro il primo minuto dal lancio del nuovo gioco, può predisporre la cache per questo significativo picco di utilizzo.
È possibile eseguire la prescalabilità utilizzando la ElastiCache console, la CLI o l'API. ElastiCache Serverless aggiorna ciò che è ECPUs/second disponibile nella cache entro 60 minuti e invia una notifica di evento quando viene completato l'aggiornamento del limite minimo.
**Come funziona la prescalabilità**
Quando il limite minimo per ECPUs/second l'archiviazione dei dati viene aggiornato tramite console, CLI o API, il nuovo limite è disponibile entro 1 ora. ElastiCache Serverless supporta 30.000 pagine ECPUs/second su una cache vuota e fino a 90.000 ECPUs/sec se si utilizza la funzione Read from Replica. ElastiCache Serverless for Valkey 8.0 può raddoppiare le richieste al secondo (RPS) supportate ogni 2-3 minuti, raggiungendo 5 M RPS per cache da zero in meno di 13 minuti, con una latenza di lettura pari a p50 inferiore al millisecondo. Se prevedi che un evento di scalabilità imminente possa superare questa frequenza, ti consigliamo di impostare il minimo ECPUs/second sul picco previsto almeno 60 minuti prima dell'evento di picco. ECPUs/sec In caso contrario, l'applicazione potrebbe riscontrare una latenza e una limitazione delle richieste elevate.
Una volta completato l'aggiornamento del limite minimo, ElastiCache Serverless inizierà a contabilizzare il nuovo valore minimo ECPUs al secondo o il nuovo spazio di archiviazione minimo. Ciò si verifica anche se l'applicazione non esegue le richieste sulla cache o se l'utilizzo dell'archiviazione dei dati è inferiore al minimo. Quando si abbassa il limite minimo rispetto all'impostazione corrente, l'aggiornamento è immediato, quindi ElastiCache Serverless inizierà immediatamente a misurare il nuovo limite minimo.
**Nota**
Quando imposti un limite di utilizzo minimo, ti viene addebitato il costo di tale limite anche se l'utilizzo effettivo è inferiore al limite di utilizzo minimo. All'utilizzo dell'ECPU o dell'archiviazione dei dati che supera il limite di utilizzo minimo viene addebitata la tariffa normale. Ad esempio, se imposti un limite di utilizzo minimo di 100.000, ti ECPUs/second verranno addebitati almeno 1,224 USD all'ora (utilizzando i prezzi dell'ECPU in us-east-1), anche se l'utilizzo è inferiore al minimo impostato.
ElastiCache Serverless supporta la scala minima richiesta a livello aggregato sulla cache. ElastiCache Serverless supporta anche un massimo di 30.000 ECPUs/second per slot (90.000 ECPUs/second se si utilizza Read from Replica utilizzando connessioni READONLY). Come best practice, l'applicazione dovrebbe garantire che la distribuzione delle chiavi tra gli slot Valkey o Redis OSS e il traffico tra le chiavi siano il più uniformi possibile.
## Impostazione dei limiti di scalabilità utilizzando la console e AWS CLI
*Impostazione dei limiti di scalabilità tramite la console AWS*
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel riquadro di navigazione, scegli il motore che viene eseguito sulla cache che desideri modificare.
1. Viene visualizzato un elenco di cache che eseguono il motore scelto.
1. Scegli la cache da modificare facendo clic sul pulsante di opzione a sinistra del nome della cache.
1. Scegliere **Actions (Operazioni)**, quindi **Modify (Modifica)**.
1. In Limiti di **utilizzo, imposta i limiti** di **memoria** o **calcolo** appropriati.
1. Fai clic su **Visualizza l'anteprima delle modifiche** e quindi su **Salva le modifiche**.
**Impostazione dei limiti di scalabilità utilizzando il AWS CLI**
Per modificare i limiti di scalabilità utilizzando la CLI, utilizza l' modify-serverless-cacheAPI.
**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}'
```
**Rimozione dei limiti di dimensionamento tramite la CLI**
Per rimuovere i limiti di scalabilità utilizzando la CLI, imposta i parametri del limite minimo e massimo su 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}'
```
# Scalabilità dei cluster basati su nodi
Raramente la quantità dei dati che un'applicazione deve elaborare è statica. Aumenta e diminuisce secondo le fluttuazioni della domanda del tuo business. Se gestisci da solo la tua cache, è necessario disporre dell'hardware sufficiente per soddisfare i picchi della domanda e questo può comportare costi cospicui. Con Amazon ElastiCache puoi scalare per soddisfare la domanda attuale, pagando solo per ciò che usi. ElastiCache ti consente di scalare la cache in base alla domanda.
**Nota**
Se un cluster Valkey o Redis OSS viene replicato in una o più regioni, tali regioni vengono ridimensionate in ordine. Durante il ridimensionamento, le regioni secondarie vengono scalate prima e poi la regione principale. Quando si esegue la scala verso il basso, viene prima la regione principale e poi tutte le regioni secondarie.
Quando si aggiorna la versione del motore, l'ordine è Regione secondaria e quindi Regione principale.
**Topics**
+ [Scalabilità su richiesta per i cluster Memcached](Scaling-self-designed.mem-heading.md)
+ [Scalabilità manuale per i cluster Memcached](Scaling.Memcached.manually.md)
+ [Scalabilità per cluster Valkey o Redis OSS (modalità cluster disabilitata)](scaling-redis-classic.md)
+ [Scalabilità dei nodi di replica per Valkey o Redis OSS (modalità cluster disabilitata)](Scaling.RedisReplGrps.md)
+ [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md)
# Scalabilità su richiesta per i cluster Memcached
ElastiCache for Memcached offre un servizio di caching in memoria completamente gestito che implementa, gestisce e ridimensiona verticalmente Memcached nel cloud.AWS
**Scalabilità verticale su richiesta**
Con la scalabilità verticale, ElastiCache per Memcached fornisce un sistema di caching della memoria distribuito ad alte prestazioni ampiamente utilizzato per velocizzare le applicazioni dinamiche alleviando il carico del database. Memorizza dati e oggetti nella RAM, riducendo la necessità di leggere da fonti di dati esterne.
È possibile applicare la scalabilità verticale ai cluster esistenti basati su nodi e a quelli nuovi. Ciò può fornire flessibilità nell'allocazione delle risorse, consentendo agli utenti di adattarsi in modo efficiente ai carichi di lavoro in evoluzione senza alterare l'architettura del cluster. Questa capacità di scalabilità migliora le prestazioni aumentando la capacità della cache nei periodi di alta domanda e riducendola per ottimizzare i costi nei periodi di bassa domanda. Ciò semplifica le operazioni, elimina la necessità di creare nuovi cluster per modificare i requisiti di risorse e consente risposte rapide alle fluttuazioni del traffico. Nel complesso, la scalabilità verticale per i cluster basati su nodi Memcached può aiutare a migliorare l'efficienza dei costi, migliorare l'utilizzo delle risorse e persino consentire agli utenti di modificare il tipo di istanza Memcached. Tutto ciò consente agli utenti di allineare più facilmente la propria infrastruttura di caching alle effettive esigenze delle applicazioni.
**Nota**
Le modifiche al tipo di nodo sono disponibili solo per i cluster Memcached basati su nodi con versioni del motore 1.5 o successive.
Auto Discovery deve essere abilitato per poter utilizzare il ridimensionamento verticale.
## Configurazione del ridimensionamento verticale su richiesta per i cluster Memcached basati su nodi
È possibile configurare la scalabilità verticale su richiesta per Memcached con, che contiene due parametri: `scale-config`
1. **ScaleIntervalMinutes:** Tempo (in minuti) tra i batch di scalabilità durante il processo di aggiornamento di Memcached
1. **ScalePercentage:** percentuale di nodi da scalare contemporaneamente durante il processo di aggiornamento di Memcached
**Conversione di un tipo di nodo Memcached esistente in una cache scalabile verticalmente tramite la CLI**
Per convertire un cluster esistente basato su nodi Memcached in una cache scalabile verticalmente, puoi utilizzarlo tramite la CLI. `elasticache modify-cache-cluster`
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config \
--apply-immediately
```
**Configurazione della scalabilità verticale con la CLI**
Per configurare la scalabilità verticale per un cluster Memcached basato su nodi tramite la CLI, usa with e i relativi parametri e. `elasticache modify-cache-cluster` `scale-config` `ScalePercentage` `ScaleIntervalMinutes`
+ **scale-interval-minutes:** definisce il tempo (in minuti) che intercorre tra i batch di scalabilità. Questa impostazione può variare da 2 a 30 minuti. Se non viene specificato alcun valore, viene applicato il valore predefinito di 5 minuti.
+ **scale-percentage:** specifica la percentuale di nodi da scalare contemporaneamente in ogni batch. Questa impostazione può variare da 10 a 100. L'impostazione viene arrotondata per eccesso quando si divide, quindi ad esempio se il risultato è 49,5 viene applicata un'impostazione di 50. Se non viene specificato alcun valore, viene applicato il valore predefinito 20.
Queste opzioni di configurazione vi consentiranno di ottimizzare il processo di scalabilità in base alle vostre esigenze specifiche, bilanciando tra la riduzione al minimo delle interruzioni del cluster e l'ottimizzazione della velocità di scalabilità. Il parametro scale-config sarà applicabile solo ai tipi di motori Memcached e verrà ignorato per gli altri motori di cache, garantendo la retrocompatibilità con l'utilizzo delle API esistenti per altri cluster.
**Chiamata API**
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config '{
"ScalePercentage": 30,
"ScaleIntervalMinutes": 2
}'
--apply-immediately
```
**Risultato:**
Restituisce l'ID del cluster e la modifica in sospeso.
```
{
"CacheCluster": {
"CacheNodeType": "old_insance_type",
...
...
"PendingModifiedValues": {
"CacheNodeType": "new_instance_type"
},
}
}
```
**Elenca le impostazioni di ridimensionamento verticale della cache Memcached**
Puoi recuperare le opzioni di ridimensionamento per le tue cache Memcached e vedere quali sono le opzioni correnti per il ridimensionamento verticale.
**Chiamata API**
```
aws elasticache list-allowed-node-type-modifications --cache-cluster-id
```
**Risultato:**
```
{
"ScaleUpModifications": [
"cache.x.xxxx",
"cache.x.xxxx"
],
"ScaleDownModifications": [
"cache.x.xxxx",
"cache.x.xxxx",
"cache.x.xxxx"
]
}
```
**Ridimensionamento verticale per Memcached con Console di gestione AWS**
Segui questi passaggi per Console di gestione AWS convertire un cluster Memcached basato su nodi in un cluster scalabile verticalmente.
1. Accedi a e apri la console all'indirizzo.Console di gestione AWS ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Seleziona il cluster Memcached da convertire.
1. Seleziona la scheda **Modifica**.
1. Vai alla sezione **Impostazioni cache** e seleziona il **tipo di nodo** desiderato.
1. Seleziona **Anteprima delle modifiche** e rivedi le modifiche.
1. Selezionare **Modify (Modifica)**.
## Scalabilità orizzontale automatizzata per Memcached
ElastiCache ora si integra con il servizio AWS Application Auto Scaling (AAS) per includere la scalabilità orizzontale automatizzata per i cluster Memcached. È possibile definire policy di scalabilità tramite il servizio AWS Application Auto Scaling e regolare automaticamente il numero di nodi nei cluster Memcached secondo necessità, in base a metriche o pianificazioni predefinite.
**Nota**
La scalabilità orizzontale automatizzata non è attualmente disponibile nelle regioni di Pechino e Ningxia.
Questi sono i metodi disponibili per scalare automaticamente orizzontalmente i cluster basati su nodi.
+ **Scalabilità pianificata: la** scalabilità basata su una pianificazione consente di impostare una pianificazione di ridimensionamento personalizzata per modifiche prevedibili del carico. Ad esempio, ogni settimana il traffico verso l'applicazione Web inizia ad aumentare di mercoledì, rimane elevato di giovedì e inizia a scendere di venerdì. È possibile configurare Auto Scaling per aumentare la capacità il mercoledì e diminuirla il venerdì.
+ **Tracciamento degli obiettivi:** con le politiche di scalabilità del tracciamento degli obiettivi, scegli una metrica di scalabilità e imposti un valore obiettivo. Application Auto Scaling crea e gestisce gli CloudWatch allarmi che attivano la politica di scalabilità e calcola la regolazione della scalabilità in base alla metrica e al valore target. La policy di dimensionamento aggiunge o rimuove la capacità in base alle necessità, per mantenere il parametro al valore di destinazione specificato o vicino a esso.
**Come configurare la scalabilità orizzontale per un cluster Memcached basato su nodi tramite la CLI**
Quando si esegue la scalabilità orizzontale di un cluster Memcached basato su nodi, è possibile utilizzare una policy di tracciamento degli obiettivi, una policy pianificata o entrambe.
1. **Registra una risorsa come obiettivo scalabile**
Chiama l'`RegisterScalableTarget`API in AWS Application Auto Scaling per registrare la destinazione per la dimensione scalabile. `elasticache:cache-cluster:Nodes`
**API:. ApplicationAutoScaling RegisterScalableTarget**
Input:
```
{
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"MinCapacity": 20,
"MaxCapacity": 50
}
```
1. **Crea una politica di ridimensionamento del tracciamento di Target**
Successivamente, puoi creare una politica di ridimensionamento di tracciamento di destinazione per la risorsa chiamando l'API put scaling policy.
1. **Metrica predefinita**
Di seguito è riportata una politica scalabile in base alla dimensione di Cache Node, utilizzando la metrica predefinita` ElastiCacheCPUUtilization`, impostata su 50 per cluster test-cluster-1. Quando si eliminano i nodi per la scalabilità in, verranno rimossi gli ultimi n nodi.
API:. ApplicationAutoScaling PutScalingPolicy
Input:
```
{
"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"
}
```
Output:
```
{
"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. **Metrica personalizzata**
Puoi anche impostare una politica di scalabilità sulla dimensione utilizzando una percentuale personalizzata basata sulla metrica di Cloudwatch.
Input:
```
{
"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. **Operazioni pianificate**
Quando devi scalare orizzontalmente per un particolare evento e poi ampliarlo dopo l'evento, puoi creare due azioni pianificate chiamando l'API. `PutScheduledAction`
**Politica 1: Scalabilità orizzontale**
Il `at` comando in `--schedule` pianifica l'esecuzione dell'azione una sola volta in una data e ora specificate nelle future. Il campo schedulazione supporta anche rate (minute, hour, day ecc.) e cron (per l'espressione cron).
Alla data e all'ora specificate, Application Auto Scaling aggiorna i valori `MinCapacity` e `MaxCapacity`. Application Auto Scaling è scalabile fino a MinCapacity portare i nodi della cache a 70.
**API:. ApplicationAutoScaling PutScheduledAction**
Input:
```
{
"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",
}
```
**Politica 2: Scalabilità**
Alla data e all'ora specificate, Application Auto Scaling aggiorna la tabella `MinCapacity` e `MaxCapacity` la scala in modo da riportare i nodi della cache `MaxCapacity` a 60.
**API:. ApplicationAutoScaling PutScheduledAction**
Input:
```
{
"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. **Visualizza le attività di scalabilità**
È possibile visualizzare le attività di scalabilità utilizzando l'`DescribeScalingActivities`API.
**API: ApplicationAutoScaling. DescribeScalingActivities**
Output:
```
{
"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. **Modifica/elimina politica di ridimensionamento**
È possibile modificare o eliminare le politiche chiamando nuovamente `PutScalingPolicy` l'API o `DeleteScalingPolicy` chiamando o Action. `DeleteScheduled`
1. **Annulla la registrazione degli obiettivi scalabili**
È possibile annullare la registrazione del target scalabile tramite l'API. `DeregisterScalableTarget` L'annullamento della registrazione di un target scalabile comporta l'eliminazione delle politiche di scalabilità e delle azioni pianificate ad esso associate.
**API:. ApplicationAutoScaling DeregisterScalableTarget**
Input:
```
{
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes"
}
```
1. **Pulizia delle politiche di scalabilità**
1. **Politiche di scalabilità multiple**
È possibile creare più politiche di scalabilità. Di seguito sono riportati i principali richiami al comportamento di [Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) Target Tracking.
+ È possibile avere più policy di dimensionamento del monitoraggio di target per un target scalabile, purché ciascuna di esse utilizzi un parametro diverso.
+ Lo scopo di Application Auto Scaling è sempre quello di assegnare la priorità alla disponibilità, quindi il suo comportamento varia a seconda che le policy di monitoraggio degli obiettivi siano pronte o meno per l'aumento o la riduzione orizzontale. L'obiettivo scalabile viene aumentato se una qualsiasi delle policy di monitoraggio dei target è pronta per l'aumento e viene ridotto solo se tutte le policy di monitoraggio dei target (con la porzione di riduzione abilitata) sono pronte per essere ridotte.
+ Se più policy impongono all'obiettivo scalabile una riduzione o un aumento orizzontale allo stesso tempo, Application Auto Scaling dimensiona in base alla policy che fornisce la capacità massima sia per la riduzione sia per l'aumento orizzontale. Ciò offre maggiore flessibilità per coprire scenari diversi e garantisce che vi sia sempre capacità sufficiente per elaborare i carichi di lavoro delle applicazioni.
**Nota**
AWS Application Auto Scaling non mette in coda le politiche di scalabilità. Application Auto Scaling attenderà il completamento del primo ridimensionamento, quindi si raffredderà e quindi ripeterà l'algoritmo precedente.
**Ridimensiona automaticamente orizzontalmente un cluster Memcached basato su nodi tramite Console di gestione AWS**
Segui questi passaggi per convertire un cluster Memcached Console di gestione AWS esistente basato su nodi in un cluster scalabile orizzontalmente.
1. Accedi a e apri la console all'indirizzo.Console di gestione AWS ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Seleziona la cache Memcached da convertire.
1. Vai alla scheda **Autoscaling**.
1. **Seleziona la politica di ridimensionamento da applicare, selezionando Aggiungi ridimensionamento **dinamico o Aggiungi ridimensionamento pianificato.****
1. Se necessario, inserisci i dettagli per la politica selezionata.
1. Fai clic su **Create (Crea)**.
# Scalabilità manuale per i cluster Memcached
Scalare manualmente e orizzontalmente un cluster Memcached in entrata o in uscita è facile tanto quanto aggiungere o rimuovere nodi dal cluster. I cluster Memcached sono composti da 1 a 60 nodi.
Poiché è possibile ripartire i dati su tutti i nodi in un cluster Memcached, il dimensionamento verso l'alto a un tipo di nodo con una memoria di dimensioni maggiori è richiesto raramente. Tuttavia, poiché il motore Memcached non mantiene i dati in modo permanente, se si esegue la scalabilità a un tipo di nodo diverso, il nuovo cluster risulterà vuoto a meno che l'applicazione non lo compili.
Per scalare manualmente in verticale il cluster Memcached, è necessario creare un nuovo cluster. Al momento della creazione, i cluster Memcached sono sempre vuoti, a meno che l'applicazione non li popoli.
**Ridimensionamento manuale dei cluster Memcached**
| Azione | Topic |
| --- | --- |
| Dimensionamento orizzontale | [Aggiunta di nodi a un cluster](Clusters.html#AddNode) |
| Dimensionamento verticale | [Eliminazione di nodi da un cluster](Clusters.html#DeleteNode) |
| Modifica dei tipi di nodo | [Ridimensionamento manuale e verticale dei cluster Memcached basati su nodi](#Scaling.Memcached.Vertically) |
**Topics**
+ [Scalabilità manuale orizzontale di un cluster Memcached basato su nodi](#Scaling.Memcached.Horizontally)
+ [Ridimensionamento manuale e verticale dei cluster Memcached basati su nodi](#Scaling.Memcached.Vertically)
## Scalabilità manuale orizzontale di un cluster Memcached basato su nodi
Il motore Memcached supporta il partizionamento dei dati su più nodi. Per questo motivo, il dimensionamento orizzontale dei cluster Memcached è più semplice. Per dimensionare orizzontalmente un cluster Memcached è sufficiente aggiungere o rimuovere i nodi.
Gli argomenti che seguono illustrano nel dettaglio come dimensionare un cluster Memcached verso l'alto o verso il basso aggiungendo o rimuovendo nodi.
+ [Aggiunta di nodi a un cluster](Clusters.html#AddNode)
+ [Eliminazione di nodi da un cluster](Clusters.html#AddNode)
Ogni volta che si cambia il numero di nodi di un cluster Memcached, è necessario rimappare almeno una parte del keyspace in modo da mapparlo sul nodo corretto. Per informazioni più dettagliate sul load balancer del cluster Memcached, consulta [Configurazione ElastiCache del client per un bilanciamento efficiente del carico (Memcached)](BestPractices.LoadBalancing.md):
Se utilizzi il rilevamento automatico sul cluster Memcached, non è necessario modificare gli endpoint nell'applicazione quando aggiungi o rimuovi nodi. Per ulteriori informazioni sull'individuazione automatica, consulta [Identifica automaticamente i nodi del cluster (Memcached)](AutoDiscovery.md). Se non utilizzi l'individuazione automatica, ogni volta che modifichi il numero di nodi nel cluster Memcached è necessario aggiornare gli endpoint nell'applicazione.
## Ridimensionamento manuale e verticale dei cluster Memcached basati su nodi
Quando si aumenta o riduce manualmente il cluster Memcached, è necessario creare un nuovo cluster. Al momento della creazione, i cluster Memcached sono sempre vuoti, a meno che l'applicazione non li popoli.
**Importante**
Se esegui il dimensionamento a un tipo di nodo più piccolo, assicurati che il tipo di nodo più piccolo sia adeguato ai dati e all'overhead. Per ulteriori informazioni, consulta [Scelta delle dimensioni dei nodi](CacheNodes.SelectSize.md).
**Topics**
+ [Scalabilità verticale di un cluster Memcached basato su nodi (Console)](#Scaling.Memcached.Vertically.CON)
+ [Ridimensionamento verticale di un cluster Memcached basato su nodi ()AWS CLI](#Scaling.Memcached.Vertically.CLI)
+ [Ridimensionamento verticale di un cluster Memcached basato su nodi (API) ElastiCache](#Scaling.Memcached.Vertically.API)
### Scalabilità verticale di un cluster Memcached basato su nodi (Console)
La procedura seguente illustra la scalabilità verticale di un cluster Memcached basato su nodi utilizzando.Console di gestione AWS
1. Creare un nuovo cluster con il nuovo tipo di nodo. Per ulteriori informazioni, consulta [Creazione di un cluster Memcached (console)](Clusters.Create-mc.md#Clusters.Create.CON.Memcached).
1. Nell'applicazione, aggiornare gli endpoint con gli endpoint del nuovo cluster. Per ulteriori informazioni, consulta [Individuazione degli endpoint di un cluster (console) (Memcached)](Endpoints.md#Endpoints.Find.Memcached).
1. Eliminare il cluster precedente. Per ulteriori informazioni, consulta [Deleting a new node in Memcached](Clusters.html#Delete.CON.Memcached).
### Ridimensionamento verticale di un cluster Memcached basato su nodi ()AWS CLI
La procedura seguente illustra la scalabilità verticale di un cluster Memcached basato su nodi utilizzando.AWS CLI
1. Creare un nuovo cluster con il nuovo tipo di nodo. Per ulteriori informazioni, consulta [Creazione di un cluster (AWS CLI)](Clusters.Create.md#Clusters.Create.CLI).
1. Nell'applicazione, aggiornare gli endpoint con gli endpoint del nuovo cluster. Per ulteriori informazioni, consulta [Individuazione degli endpoint (AWS CLI)](Endpoints.md#Endpoints.Find.CLI).
1. Eliminare il cluster precedente. Per ulteriori informazioni, consulta [Utilizzo di AWS CLI per eliminare un ElastiCache cluster](Clusters.Delete.md#Clusters.Delete.CLI).
### Ridimensionamento verticale di un cluster Memcached basato su nodi (API) ElastiCache
La procedura seguente illustra la scalabilità verticale di un cluster Memcached basato su nodi utilizzando l'API. ElastiCache
1. Creare un nuovo cluster con il nuovo tipo di nodo. Per ulteriori informazioni, consulta [Creazione di un cluster per Memcached (API) ElastiCache](Clusters.Create-mc.md#Clusters.Create.API.mem-heading)
1. Nell'applicazione, aggiornare gli endpoint con gli endpoint del nuovo cluster. Per ulteriori informazioni, consulta [Ricerca degli endpoint (API) ElastiCache](Endpoints.md#Endpoints.Find.API).
1. Eliminare il cluster precedente. Per ulteriori informazioni, consulta [Utilizzo dell' ElastiCache API](Clusters.Delete.md#Clusters.Delete.API).
# Scalabilità per cluster Valkey o Redis OSS (modalità cluster disabilitata)
I cluster Valkey o Redis OSS (modalità cluster disabilitata) possono essere cluster a nodo singolo con 0 shard o cluster multinodo con 1 shard. I cluster a nodo singolo usano un nodo per entrambe le operazioni di lettura e scrittura. I cluster multinodo hanno sempre 1 nodo come nodo principale con da 0 a 5 nodi di replica di sola lettura read/write .
**Topics**
+ [Scalabilità per cluster Valkey o Redis OSS (Cluster Mode Disabled)](#Scaling.RedisStandalone)
**Scalabilità dei cluster Valkey o Redis OSS**
| Azione | Valkey o Redis OSS (modalità cluster disabilitata) | Valkey o Redis OSS (modalità cluster abilitata) |
| --- | --- | --- |
| Dimensionamento verticale | [Rimozione di nodi da un ElastiCache cluster](Clusters.DeleteNode.md) | [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md) |
| Dimensionamento orizzontale | [Aggiunta di nodi a un cluster](Clusters.html#AddNode) | [Resharding online per Valkey o Redis OSS (modalità cluster abilitata)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) |
| Modifica dei tipi di nodo | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/scaling-redis-classic.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/scaling-redis-classic.html) | [Ridimensionamento verticale online tramite la modifica del tipo di nodo](redis-cluster-vertical-scaling.md) |
| Modifica del numero di gruppi del nodo | Non supportato per i cluster Valkey o Redis OSS (modalità cluster disabilitata) | [Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)](scaling-redis-cluster-mode-enabled.md) |
**Contents**
+ [Scalabilità per cluster Valkey o Redis OSS (Cluster Mode Disabled)](#Scaling.RedisStandalone)
+ [Scalabilità di cluster Valkey o Redis OSS a nodo singolo](#Scaling.RedisStandalone.ScaleUp)
+ [Scalabilità di cluster Valkey o Redis OSS (Cluster Mode Disabled) (Console) a nodo singolo](#Scaling.RedisStandalone.ScaleUp.CON)
+ [Scalabilità di cluster Valkey o Redis OSS a nodo singolo ()AWS CLI](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Scalabilità dei cluster Valkey o Redis OSS (API) a nodo singolo ElastiCache](#Scaling.RedisStandalone.ScaleUp.API)
+ [Ridimensionamento dei cluster Valkey o Redis OSS a nodo singolo](#Scaling.RedisStandalone.ScaleDown)
+ [Ridimensionamento di un cluster Valkey o Redis OSS a nodo singolo (console)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [Ridimensionamento dei cluster Valkey o Redis OSS a nodo singolo ()AWS CLI](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [Ridimensionamento dei cluster Valkey o Redis OSS (API) a nodo singolo ElastiCache](#Scaling.RedisStandalone.ScaleDown.API)
## Scalabilità per cluster Valkey o Redis OSS (Cluster Mode Disabled)
I nodi Valkey o Redis OSS (modalità cluster disabilitata) devono essere sufficientemente grandi da contenere tutti i dati della cache più l'overhead di Valkey o Redis OSS. Per modificare la capacità di dati del cluster Valkey o Redis OSS (modalità cluster disabilitata), è necessario scalare verticalmente; scalare fino a un tipo di nodo più grande per aumentare la capacità dei dati o ridimensionare fino a un tipo di nodo più piccolo per ridurre la capacità dei dati.
Il processo ElastiCache di scalabilità è progettato per fare il massimo sforzo per conservare i dati esistenti e richiede una replica corretta di Valkey o Redis OSS. Per i cluster Valkey o Redis OSS (modalità cluster disabilitata), si consiglia di rendere disponibile una memoria sufficiente per Valkey o Redis OSS.
Non è possibile partizionare i dati su più cluster Valkey o Redis OSS (modalità cluster disabilitata). Tuttavia, se è necessario solo aumentare o diminuire la capacità di lettura del cluster, è possibile creare un cluster Valkey o Redis OSS (modalità cluster disabilitata) con nodi di replica e aggiungere o rimuovere repliche di lettura. Per creare un cluster Valkey o Redis OSS (modalità cluster disabilitata) con nodi di replica utilizzando il cluster Valkey o Redis OSS a nodo singolo come cluster primario, vedi. [Creazione di un cluster Valkey (modalità cluster disabilitata) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
Dopo aver creato il cluster con le repliche, è possibile aumentare la capacità di lettura aggiungendo repliche di lettura. In seguito, se necessario, è possibile ridurre la capacità di lettura rimuovendo le repliche di lettura. Per ulteriori informazioni, consulta [Aumento della capacità di lettura](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleOut) o [Diminuzione della capacità di lettura](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleIn).
Oltre a essere in grado di scalare la capacità di lettura, i cluster Valkey o Redis OSS (modalità cluster disabilitata) con repliche offrono altri vantaggi aziendali. Per ulteriori informazioni, consulta [Alta disponibilità utilizzando gruppi di replica](Replication.md).
**Importante**
Se il tuo gruppo di parametri utilizza `reserved-memory` la memoria per il sovraccarico di Valkey o Redis OSS, prima di iniziare il ridimensionamento assicurati di disporre di un gruppo di parametri personalizzato che riservi la quantità di memoria corretta per il nuovo tipo di nodo. In alternativa, è possibile modificare un gruppo di parametri personalizzato in modo che utilizzi `reserved-memory-percent` e il gruppo di parametri per il nuovo cluster.
Se stai utilizzando `reserved-memory-percent`, questa operazione non è necessaria.
Per ulteriori informazioni, consulta [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md).
**Topics**
+ [Scalabilità di cluster Valkey o Redis OSS a nodo singolo](#Scaling.RedisStandalone.ScaleUp)
+ [Ridimensionamento dei cluster Valkey o Redis OSS a nodo singolo](#Scaling.RedisStandalone.ScaleDown)
### Scalabilità di cluster Valkey o Redis OSS a nodo singolo
Quando si esegue la scalabilità di un cluster Valkey o Redis OSS a nodo singolo, ElastiCache esegue il seguente processo, indipendentemente dal fatto che si utilizzi la console, l'o l' ElastiCache API.AWS CLI ElastiCache
1. Un nuovo cluster con il nuovo tipo di nodo viene avviato nella stessa zona di disponibilità del cluster esistente.
1. I dati della cache nel cluster esistente vengono copiati nel nuovo cluster. La durata di questo processo dipende dal tipo di nodo e dalla quantità di dati presenti nel cluster.
1. Le operazioni di lettura e scrittura vengono ora eseguite utilizzando il nuovo cluster. Poiché gli endpoint del nuovo cluster sono gli stessi del vecchio cluster, non è necessario aggiornare gli endpoint nell'applicazione. Noterai una breve interruzione (qualche secondo) di letture e scritture dal nodo primario mentre la voce DNS viene aggiornata.
1. ElastiCache elimina il vecchio cluster. Noterai una breve interruzione (pochi secondi) di letture e scritture dal vecchio nodo perché le connessioni al vecchio nodo verranno disconnesse.
**Nota**
Per i cluster che eseguono il tipo di nodo r6gd, è possibile dimensionare solo le dimensioni dei nodi all'interno della famiglia di nodi r6gd.
Come illustrato nella tabella seguente, l'operazione di scale-up di Valkey o Redis OSS è bloccata se è previsto un aggiornamento del motore per la prossima finestra di manutenzione. Per ulteriori informazioni sulla manutenzione Windows, consultare [Gestione della manutenzione dei ElastiCache cluster](maintenance-window.md).
**Operazioni Valkey o Redis OSS bloccate**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/scaling-redis-classic.html)
Se hai un'operazione in sospeso che ti blocca, puoi svolgere una delle seguenti operazioni.
+ Pianifica l'operazione di scale-up di Valkey o Redis OSS per la prossima finestra di manutenzione deselezionando la **casella di controllo Applica immediatamente** (uso CLI:, uso API:). `--no-apply-immediately` `ApplyImmediately=false`
+ Attendi la finestra di manutenzione successiva (o successiva) per eseguire l'operazione di scalabilità di Valkey o Redis OSS.
+ Aggiungi l'aggiornamento del motore Valkey o Redis OSS a questa modifica del cluster selezionando la casella di controllo **Applica immediatamente** (uso CLI:`--apply-immediately`, uso API:). `ApplyImmediately=true` In questo modo si sblocca l'operazione di dimensionamento verso l'alto per eseguire immediatamente l'aggiornamento automatico del motore.
È possibile scalare un cluster Valkey o Redis OSS a nodo singolo (modalità cluster disabilitata) utilizzando la ElastiCache console, l'API o.AWS CLI ElastiCache
**Importante**
Se il tuo gruppo di parametri utilizza `reserved-memory` la memoria per il sovraccarico di Valkey o Redis OSS, prima di iniziare il ridimensionamento assicurati di disporre di un gruppo di parametri personalizzato che riservi la quantità di memoria corretta per il nuovo tipo di nodo. In alternativa, è possibile modificare un gruppo di parametri personalizzato in modo che utilizzi `reserved-memory-percent` e il gruppo di parametri per il nuovo cluster.
Se stai utilizzando `reserved-memory-percent`, questa operazione non è necessaria.
Per ulteriori informazioni, consulta [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md).
#### Scalabilità di cluster Valkey o Redis OSS (Cluster Mode Disabled) (Console) a nodo singolo
La procedura seguente descrive come scalare un cluster Valkey o Redis OSS a nodo singolo utilizzando la console di gestione. ElastiCache Durante questo processo, il cluster Valkey o Redis OSS continuerà a soddisfare le richieste con tempi di inattività minimi.
**Per scalare un cluster Valkey o Redis OSS a nodo singolo (console)**
1. Accedi a Console di gestione AWS e apri la console all' ElastiCache indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Dal pannello di navigazione, scegli i cluster **Valkey o Redis OSS**.
1. Dall'elenco dei cluster, scegli il cluster che desideri scalare (deve eseguire il motore Valkey o Redis OSS, non il motore Valkey o Redis OSS in cluster).
1. Scegli **Modifica**.
1. Nella procedura guidata **Modify Cluster (Modifica cluster)**:
1. Scegliere il tipo di nodo a cui dimensionare dall'elenco **Node type (Tipo di nodo)**.
1. Se stai utilizzando `reserved-memory` per gestire la tua memoria, dall'elenco **Parameter Group (Gruppo di parametri)**, seleziona il gruppo di parametri personalizzati che riserva la quantità corretta di memoria per il nuovo tipo di nodo.
1. Per eseguire subito il processo di dimensionamento verso l'alto, scegliere la casella **Apply immediately (Applica immediatamente)**. Se non viene selezionata la casella **Apply immediately (Applica immediatamente)**, il processo di dimensionamento verso l'alto viene eseguito nel corso della successiva finestra di manutenzione del cluster.
1. Scegli **Modifica**.
Se, nel passaggio precedente, è stato scelto **Apply immediately (Applica immediatamente)**, lo stato del cluster diventa *modifica in corso*. Quando lo stato cambia in *disponibile*, la modifica è completa ed è possibile iniziare a utilizzare il nuovo cluster.
#### Scalabilità di cluster Valkey o Redis OSS a nodo singolo ()AWS CLI
La procedura seguente descrive come scalare un cluster Valkey o Redis OSS a nodo singolo utilizzando.AWS CLI Durante questo processo, il cluster Valkey o Redis OSS continuerà a soddisfare le richieste con tempi di inattività minimi.
**Per scalare un cluster Valkey o Redis OSS a nodo singolo ()AWS CLI**
1. Determina i tipi di nodi fino a cui puoi scalare eseguendo il AWS CLI`list-allowed-node-type-modifications` comando con il seguente parametro.
+ `--cache-cluster-id`
Per Linux, macOS o Unix:
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Per Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
L'output del comando in alto è simile al seguente (in formato JSON).
```
{
"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 ",
],
}
```
Per ulteriori informazioni, consulta [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) nella *documentazione di riferimento AWS CLI*.
1. Modifica il cluster esistente specificando il cluster da scalare verso l'alto e il nuovo tipo di nodo più grande, utilizzando il AWS CLI`modify-cache-cluster` comando e i seguenti parametri.
+ `--cache-cluster-id`— Il nome del cluster che stai scalando.
+ `--cache-node-type`— Il nuovo tipo di nodo con cui scalare il cluster. Questo valore deve essere uno dei tipi di nodi restituiti dal comando `list-allowed-node-type-modifications` nella fase 1.
+ `--cache-parameter-group-name` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `--apply-immediately` : Consente di applicare immediatamente il dimensionamento verso l'alto. Per posporre il processo di dimensionamento alla finestra di manutenzione successiva del cluster, utilizzare il parametro `--no-apply-immediately`.
Per Linux, macOS o 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
```
Per 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
```
L'output del comando in alto è simile al seguente (in formato JSON).
```
{
"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"
}
}
```
Per ulteriori informazioni, consulta [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) nella *documentazione di riferimento AWS CLI*.
1. Se hai usato il`--apply-immediately`, controlla lo stato del nuovo cluster usando il AWS CLI`describe-cache-clusters` comando con il seguente parametro. Quando lo stato diventa *disponibile*, puoi iniziare a utilizzare il nuovo cluster più grande.
+ `--cache-cluster-id`— Il nome del cluster Valkey o Redis OSS a nodo singolo. Utilizzate questo parametro per descrivere un particolare cluster anziché tutti i cluster.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
Per ulteriori informazioni, consulta [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) nella *documentazione di riferimento AWS CLI*.
#### Scalabilità dei cluster Valkey o Redis OSS (API) a nodo singolo ElastiCache
La procedura seguente descrive come scalare un cluster Valkey o Redis OSS a nodo singolo utilizzando l'API. ElastiCache Durante questo processo, il cluster Valkey o Redis OSS continuerà a soddisfare le richieste con tempi di inattività minimi.
**Per scalare un cluster (API) Valkey o Redis OSS a nodo singolo ElastiCache**
1. Determina i tipi di nodi fino a cui puoi scalare eseguendo l'`ListAllowedNodeTypeModifications`azione ElastiCache API con il seguente parametro.
+ `CacheClusterId`— Il nome del cluster Valkey o Redis OSS a nodo singolo che desideri scalare.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) consulta *Amazon ElastiCache API Reference*.
1. Modifica il cluster esistente specificando il cluster da scalare verso l'alto e il nuovo tipo di nodo più grande, utilizzando l'azione `ModifyCacheCluster` ElastiCache API e i seguenti parametri.
+ `CacheClusterId`— Il nome del cluster che stai scalando.
+ `CacheNodeType`— Il nuovo tipo di nodo più grande fino a cui desideri scalare il cluster. Questo valore deve essere uno dei tipi di nodo restituiti dall'`ListAllowedNodeTypeModifications`azione nel passaggio precedente.
+ `CacheParameterGroupName` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `ApplyImmediately` : Imposta su `true` per eseguire immediatamente il processo di dimensionamento verso l’alto. Per posporre il processo di dimensionamento alla finestra di manutenzione successiva del cluster, utilizzare `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=
```
Per ulteriori informazioni, [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) consulta *Amazon ElastiCache API Reference*.
1. Se lo hai utilizzato `ApplyImmediately``=true`, controlla lo stato del nuovo cluster utilizzando l'`DescribeCacheClusters`azione ElastiCache API con il seguente parametro. Quando lo stato diventa *disponibile*, puoi iniziare a utilizzare il nuovo cluster più grande.
+ `CacheClusterId`— Il nome del cluster Valkey o Redis OSS a nodo singolo. Utilizzate questo parametro per descrivere un particolare cluster anziché tutti i cluster.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) consulta *Amazon ElastiCache API Reference*.
### Ridimensionamento dei cluster Valkey o Redis OSS a nodo singolo
Le seguenti sezioni illustrano come ridimensionare un cluster Valkey o Redis OSS a nodo singolo fino a un tipo di nodo più piccolo. Garantire che il nuovo tipo di nodo più piccolo sia sufficientemente grande da contenere tutti i dati e il sovraccarico di Valkey o Redis OSS è importante per il successo a lungo termine del nuovo cluster Valkey o Redis OSS. Per ulteriori informazioni, consulta [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md).
**Nota**
Per i cluster che eseguono il tipo di nodo r6gd, è possibile dimensionare solo le dimensioni dei nodi all'interno della famiglia di nodi r6gd.
**Topics**
+ [Ridimensionamento di un cluster Valkey o Redis OSS a nodo singolo (console)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [Ridimensionamento dei cluster Valkey o Redis OSS a nodo singolo ()AWS CLI](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [Ridimensionamento dei cluster Valkey o Redis OSS (API) a nodo singolo ElastiCache](#Scaling.RedisStandalone.ScaleDown.API)
#### Ridimensionamento di un cluster Valkey o Redis OSS a nodo singolo (console)
La procedura seguente illustra come ridimensionare il cluster Valkey o Redis OSS a nodo singolo fino a un tipo di nodo più piccolo utilizzando la console. ElastiCache
**Importante**
Se il tuo gruppo di parametri utilizza `reserved-memory` la memoria per il sovraccarico di Valkey o Redis OSS, prima di iniziare il ridimensionamento assicurati di disporre di un gruppo di parametri personalizzato che riservi la quantità di memoria corretta per il nuovo tipo di nodo. In alternativa, è possibile modificare un gruppo di parametri personalizzato in modo che utilizzi `reserved-memory-percent` e il gruppo di parametri per il nuovo cluster.
Se stai utilizzando `reserved-memory-percent`, questa operazione non è necessaria.
Per ulteriori informazioni, consulta [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md).
**Per ridimensionare il cluster Valkey o Redis OSS a nodo singolo (console)**
1. Verificare che il dimensionamento a un tipo di nodo più piccolo sia adeguato ai dati e all'overhead.
1. Se il tuo gruppo di parametri utilizza `reserved-memory` la memoria per il sovraccarico di Valkey o Redis OSS, assicurati di disporre di un gruppo di parametri personalizzato per mettere da parte la quantità di memoria corretta per il nuovo tipo di nodo.
In alternativa, puoi modificare un gruppo di parametri personalizzato per utilizzare `reserved-memory-percent`. Per ulteriori informazioni, consulta [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md).
1. Accedi a Console di gestione AWS e apri la console all' ElastiCache indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nell'elenco dei cluster, scegliere quello da diminuire. Questo cluster deve eseguire il motore Valkey o Redis OSS e non il motore Valkey o Redis OSS in cluster.
1. Scegli **Modifica**.
1. Nella procedura guidata **Modify Cluster (Modifica cluster)**:
1. Scegliere il tipo di nodo che si desidera diminuire dall'elenco **Node type (Tipo di nodo)**.
1. Se stai utilizzando `reserved-memory` per gestire la tua memoria, dall'elenco **Parameter Group (Gruppo di parametri)**, seleziona il gruppo di parametri personalizzati che riserva la quantità corretta di memoria per il nuovo tipo di nodo.
1. Per eseguire subito il processo di dimensionamento, scegliere la casella **Apply immediately (Applica immediatamente)**. Se non viene selezionata la casella **Apply immediately (Applica immediatamente)**, il processo di dimensionamento viene eseguito nel corso della successiva finestra di manutenzione del cluster.
1. Scegli **Modifica**.
1. Quando lo stato del cluster cambia da *modifica in corso* a *disponibile*, il cluster è stato dimensionato a un nuovo tipo di nodo. Non è necessario aggiornare gli endpoint nell'applicazione.
#### Ridimensionamento dei cluster Valkey o Redis OSS a nodo singolo ()AWS CLI
La procedura seguente descrive come ridimensionare un cluster Valkey o Redis OSS a nodo singolo utilizzando.AWS CLI
**Per ridimensionare un cluster Valkey o Redis OSS a nodo singolo ()AWS CLI**
1. Determina i tipi di nodi a cui puoi ridimensionare eseguendo il AWS CLI`list-allowed-node-type-modifications` comando con il seguente parametro.
+ `--cache-cluster-id`
Per Linux, macOS o Unix:
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Per Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
L'output del comando in alto è simile al seguente (in formato JSON).
```
{
"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 ",
],
}
```
Per ulteriori informazioni, consulta [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) nella *documentazione di riferimento AWS CLI*.
1. Modifica il cluster esistente specificando il cluster da ridimensionare e il nuovo tipo di nodo più piccolo, utilizzando il AWS CLI`modify-cache-cluster` comando e i seguenti parametri.
+ `--cache-cluster-id`— Il nome del cluster che stai ridimensionando.
+ `--cache-node-type`— Il nuovo tipo di nodo con cui scalare il cluster. Questo valore deve essere uno dei tipi di nodi restituiti dal comando `list-allowed-node-type-modifications` nella fase 1.
+ `--cache-parameter-group-name` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `--apply-immediately` : Causa l'applicazione immediata del processo di riduzione verticale Per posporre il processo di dimensionamento alla finestra di manutenzione successiva del cluster, utilizzare il parametro `--no-apply-immediately`.
Per Linux, macOS o 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
```
Per 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
```
L'output del comando in alto è simile al seguente (in formato JSON).
```
{
"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"
}
}
```
Per ulteriori informazioni, consulta [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) nella *documentazione di riferimento AWS CLI*.
1. Se hai usato il`--apply-immediately`, controlla lo stato del nuovo cluster usando il AWS CLI`describe-cache-clusters` comando con il seguente parametro. Quando lo stato diventa *disponibile*, puoi iniziare a utilizzare il nuovo cluster più grande.
+ `--cache-cluster-id`— Il nome del cluster Valkey o Redis OSS a nodo singolo. Utilizzate questo parametro per descrivere un particolare cluster anziché tutti i cluster.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
Per ulteriori informazioni, consulta [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) nella *documentazione di riferimento AWS CLI*.
#### Ridimensionamento dei cluster Valkey o Redis OSS (API) a nodo singolo ElastiCache
La procedura seguente descrive come scalare verso l'alto un cluster Valkey o Redis OSS a nodo singolo utilizzando l'API. ElastiCache
**Per ridimensionare un cluster Valkey o Redis OSS a nodo singolo (API) ElastiCache**
1. Determina i tipi di nodi a cui puoi ridimensionare eseguendo l'`ListAllowedNodeTypeModifications`azione ElastiCache API con il seguente parametro.
+ `CacheClusterId`— Il nome del cluster Valkey o Redis OSS a nodo singolo che desideri ridimensionare.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) consulta *Amazon ElastiCache API Reference*.
1. Modifica il cluster esistente specificando il cluster da scalare verso l'alto e il nuovo tipo di nodo più grande, utilizzando l'azione `ModifyCacheCluster` ElastiCache API e i seguenti parametri.
+ `CacheClusterId`— Il nome del cluster che stai ridimensionando.
+ `CacheNodeType`— Il nuovo tipo di nodo più piccolo a cui vuoi ridimensionare il cluster. Questo valore deve essere uno dei tipi di nodo restituiti dall'`ListAllowedNodeTypeModifications`azione nel passaggio precedente.
+ `CacheParameterGroupName` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `ApplyImmediately` : Imposta su `true` per eseguire immediatamente il processo di dimensionamento verso il basso. Per posporre il processo di dimensionamento alla finestra di manutenzione successiva del cluster, utilizzare `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=
```
Per ulteriori informazioni, [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) consulta *Amazon ElastiCache API Reference*.
1. Se lo hai utilizzato `ApplyImmediately``=true`, controlla lo stato del nuovo cluster utilizzando l'`DescribeCacheClusters`azione ElastiCache API con il seguente parametro. Quando lo stato diventa *disponibile*, puoi iniziare a utilizzare il nuovo cluster più piccolo.
+ `CacheClusterId`— Il nome del cluster Valkey o Redis OSS a nodo singolo. Utilizzate questo parametro per descrivere un particolare cluster anziché tutti i cluster.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) consulta *Amazon ElastiCache API Reference*.
# Scalabilità dei nodi di replica per Valkey o Redis OSS (modalità cluster disabilitata)
Un cluster Valkey o Redis OSS con nodi di replica (chiamato *gruppo di replica* nell'API/CLI) offre un'elevata disponibilità tramite la replica con Multi-AZ con failover automatico abilitato. Un cluster con nodi di replica è una raccolta logica di un massimo di sei nodi Valkey o Redis OSS in cui un nodo, il primario, è in grado di soddisfare richieste di lettura e scrittura. Tutti gli altri nodi nel cluster sono repliche di sola lettura del nodo primario. I dati scritti sul cluster primario vengono replicati in modo asincrono su tutte le repliche di lettura nel cluster. Poiché Valkey o Redis OSS (modalità cluster disabilitata) non supportano il partizionamento dei dati su più cluster, ogni nodo di un gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) contiene l'intero set di dati della cache. I cluster Valkey o Redis OSS (modalità cluster abilitata) supportano il partizionamento dei dati su un massimo di 500 shard.
Per modificare la capacità dei dati per il cluster, è necessario prima dimensionarlo verso l'alto a un nodo più grande o verso il basso a un nodo più piccolo.
Per modificare la capacità di lettura del cluster, aggiungere più repliche di lettura (fino a un massimo di 5) o rimuoverle.
Il processo ElastiCache di scalabilità è progettato per fare il massimo sforzo per conservare i dati esistenti e richiede una replica efficace di Valkey o Redis OSS. Per i cluster Valkey o Redis OSS con repliche, si consiglia di rendere disponibile una memoria sufficiente per Valkey o Redis OSS.
**Topics**
+ [Scalabilità dei cluster Valkey o Redis OSS con repliche](#Scaling.RedisReplGrps.ScaleUp)
+ [Ridimensionamento dei cluster Valkey o Redis OSS con repliche](#Scaling.RedisReplGrps.ScaleDown)
+ [Aumento della capacità di lettura](#Scaling.RedisReplGrps.ScaleOut)
+ [Diminuzione della capacità di lettura](#Scaling.RedisReplGrps.ScaleIn)
**Argomenti correlati**
+ [Alta disponibilità utilizzando gruppi di replica](Replication.md)
+ [Replica: modalità cluster Valkey e Redis OSS disabilitata o abilitata](Replication.Redis-RedisCluster.md)
+ [Riduzione al minimo dei tempi di inattività ElastiCache utilizzando Multi-AZ con Valkey e Redis OSS](AutoFailover.md)
+ [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md)
**Topics**
+ [Scalabilità dei cluster Valkey o Redis OSS con repliche](#Scaling.RedisReplGrps.ScaleUp)
+ [Ridimensionamento dei cluster Valkey o Redis OSS con repliche](#Scaling.RedisReplGrps.ScaleDown)
+ [Aumento della capacità di lettura](#Scaling.RedisReplGrps.ScaleOut)
+ [Diminuzione della capacità di lettura](#Scaling.RedisReplGrps.ScaleIn)
## Scalabilità dei cluster Valkey o Redis OSS con repliche
Amazon ElastiCache fornisce supporto per console, CLI e API per scalare il gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata).
Quando viene avviato il processo di scalabilità verticale, effettua le seguenti operazioni: ElastiCache
1. Avvia un nuovo gruppo di replica utilizzando il nuovo tipo di nodo.
1. Copia tutti i dati da un nodo primario corrente al nuovo nodo primario.
1. Sincronizza le nuove repliche di lettura con il nuovo nodo primario.
1. Aggiorna le voci DNS in modo che puntino ai nuovi nodi. Per questo motivo non è necessario aggiornare gli endpoint nell'applicazione. Per Valkey 7.2 e versioni successive o Redis OSS 5.0.5 e versioni successive, puoi scalare i cluster abilitati al failover automatico mentre il cluster continua a rimanere online e a soddisfare le richieste in arrivo. Nella versione 4.0.10 e precedenti di Redis OSS, è possibile notare una breve interruzione delle operazioni di lettura e scrittura sulle versioni precedenti dal nodo primario durante l'aggiornamento della voce DNS.
1. Elimina i nodi precedenti (CLI/API: gruppo di replica). Noterai una breve interruzione (pochi secondi) di letture e scritture dai vecchi nodi perché le connessioni ai vecchi nodi verranno disconnesse.
La durata di questo processo dipende dal tipo di nodo e dalla quantità di dati presenti nel cluster.
Come illustrato nella tabella seguente, l'operazione di scalabilità verticale di Valkey o Redis OSS è bloccata se è pianificato un aggiornamento del motore per la prossima finestra di manutenzione del cluster.
**Operazioni Valkey o Redis OSS bloccate**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/Scaling.RedisReplGrps.html)
Se hai un'operazione in sospeso che ti blocca, puoi svolgere una delle seguenti operazioni.
+ Pianifica l'operazione di scale-up di Valkey o Redis OSS per la prossima finestra di manutenzione deselezionando la **casella di controllo Applica immediatamente** (uso CLI:, uso API:). `--no-apply-immediately` `ApplyImmediately=false`
+ Attendi la finestra di manutenzione successiva (o successiva) per eseguire l'operazione di scalabilità di Valkey o Redis OSS.
+ Aggiungi l'aggiornamento del motore Valkey o Redis OSS a questa modifica del cluster selezionando la casella di controllo **Applica immediatamente** (uso CLI:`--apply-immediately`, uso API:). `ApplyImmediately=true` In questo modo si sblocca l'operazione di dimensionamento verso l'alto per eseguire immediatamente l'aggiornamento automatico del motore.
Le sezioni seguenti descrivono come scalare il cluster Valkey o Redis OSS con le repliche utilizzando la ElastiCache console, l'API e l'API.AWS CLI ElastiCache
**Importante**
Se il tuo gruppo di parametri utilizza `reserved-memory` la memoria per il sovraccarico di Valkey o Redis OSS, prima di iniziare il ridimensionamento assicurati di disporre di un gruppo di parametri personalizzato che riservi la quantità di memoria corretta per il nuovo tipo di nodo. In alternativa, è possibile modificare un gruppo di parametri personalizzato in modo che utilizzi `reserved-memory-percent` e il gruppo di parametri per il nuovo cluster.
Se stai utilizzando `reserved-memory-percent`, questa operazione non è necessaria.
Per ulteriori informazioni, consulta [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md).
### Scalabilità di un cluster Valkey o Redis OSS con repliche (Console)
Il tempo necessario per dimensionare l'alto a un tipo di nodo più grande varia a seconda del tipo di nodo e della quantità di dati nel cluster corrente.
Il seguente processo ridimensiona il cluster con repliche dal tipo di nodo corrente a un nuovo tipo di nodo più grande utilizzando la console. ElastiCache Durante questo processo, si potrebbe verificare una breve interruzione di letture e scritture per altre versioni del nodo primario mentre la voce DNS viene aggiornata. Si potrebbe verificare un tempo di inattività inferiore al secondo per nodi in esecuzione su versioni 5.0.6 e superiore a qualche secondo per versioni precedenti.
**Per scalare il cluster Valkey o Redis OSS con repliche (console)**
1. Accedi a Console di gestione AWS e apri la console all' ElastiCache indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Dal pannello di navigazione, scegli i cluster **Valkey o i cluster **Redis** OSS**
1. Nell'elenco di cluster, scegliere quello da dimensionare. Questo cluster deve eseguire il motore Valkey o Redis OSS e non il motore Valkey o Redis OSS in cluster.
1. Scegli **Modifica**.
1. Nella procedura guidata **Modify Cluster (Modifica cluster)**:
1. Scegliere il tipo di nodo a cui dimensionare dall'elenco **Node type (Tipo di nodo)**. Si noti che non tutti i tipi di nodo sono disponibili per il dimensionamento.
1. Se stai utilizzando `reserved-memory` per gestire la tua memoria, dall'elenco **Parameter Group (Gruppo di parametri)**, seleziona il gruppo di parametri personalizzati che riserva la quantità corretta di memoria per il nuovo tipo di nodo.
1. Per eseguire subito il processo di dimensionamento verso l'alto, scegliere la casella **Apply immediately (Applica immediatamente)**. Se non viene selezionata la casella **Apply immediately (Applica immediatamente)**, il processo di dimensionamento verso l'alto viene eseguito nel corso della successiva finestra di manutenzione del cluster.
1. Scegli **Modifica**.
1. Quando lo stato del cluster cambia da *modifica in corso* a *disponibile*, il cluster è stato dimensionato a un nuovo tipo di nodo. Non è necessario aggiornare gli endpoint nell'applicazione.
### Scalabilità di un gruppo di replica Valkey o Redis OSS ()AWS CLI
La procedura seguente ridimensiona il gruppo di replica dal tipo di nodo corrente a un nuovo tipo più grande di nodo utilizzando l'AWS CLI. Durante questo processo, ElastiCache aggiorna le voci DNS in modo che puntino ai nuovi nodi. Per questo motivo non è necessario aggiornare gli endpoint nell'applicazione. Per Valkey 7.2 e versioni successive o Redis OSS 5.0.5 e versioni successive, puoi scalare i cluster abilitati al failover automatico mentre il cluster continua a rimanere online e a soddisfare le richieste in arrivo. Sulla versione 4.0.10 e precedenti, si potrebbe verificare una breve interruzione di letture e scritture su versioni precedenti dal nodo primario mentre la voce DNS viene aggiornata.
Il tempo necessario per passare a un tipo di nodo più grande varia a seconda del tipo di nodo e della quantità di dati nel cluster corrente.
**Per scalare un Valkey o Redis OSS Replication Group ()AWS CLI**
1. Determina a quali tipi di nodi puoi scalare eseguendo il AWS CLI`list-allowed-node-type-modifications` comando con il seguente parametro.
+ `--replication-group-id` = il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica particolare piuttosto che tutti i gruppi di replica.
Per Linux, macOS o Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Per Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
L'output di questa operazione è simile al seguente (in formato JSON).
```
{
"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"
]
}
```
Per ulteriori informazioni, consulta [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) nella *documentazione di riferimento AWS CLI*.
1. Ridimensiona il gruppo di replica corrente fino al nuovo tipo di nodo utilizzando il AWS CLI`modify-replication-group` comando con i seguenti parametri.
+ `--replication-group-id` : il nome del gruppo di replica.
+ `--cache-node-type`— il nuovo tipo di nodo più grande dei cluster in questo gruppo di replica. Questo valore deve essere uno dei tipi di istanza restituiti dal `list-allowed-node-type-modifications` comando nel passaggio precedente.
+ `--cache-parameter-group-name` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `--apply-immediately` : Consente di applicare immediatamente il dimensionamento verso l'alto. Per posporre l'operazione di dimensionamento verso l'alto alla finestra di manutenzione successiva, utilizzare `--no-apply-immediately`.
Per Linux, macOS o 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
```
Per 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
```
L'output di questo comando è simile al seguente (in formato JSON).
```
{
"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": {}
}
}
```
Per ulteriori informazioni, consulta [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) nella *documentazione di riferimento AWS CLI*.
1. Se avete utilizzato il `--apply-immediately` parametro, monitorate lo stato del gruppo di replica utilizzando il AWS CLI`describe-replication-group` comando con il seguente parametro. Mentre lo stato è ancora impostato su *modifica in corso*, si potrebbe verificare un tempo di inattività inferiore al secondo per nodi in esecuzione su versioni 5.0.6 e successive e una breve interruzione di letture e scritture per versioni precedenti dal nodo primario mentre la voce DNS viene aggiornata.
+ `--replication-group-id` = il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica particolare piuttosto che tutti i gruppi di replica.
Per Linux, macOS o Unix:
```
aws elasticache describe-replication-groups \
--replication-group-id my-replication-group
```
Per Windows:
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
Per ulteriori informazioni, consulta [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) nella *documentazione di riferimento AWS CLI*.
### Scalabilità di un gruppo di replica (API) Valkey o Redis OSS ElastiCache
Il seguente processo ridimensiona il gruppo di replica dal tipo di nodo corrente a un nuovo tipo di nodo più grande utilizzando l'API. ElastiCache Per Valkey 7.2 e versioni successive o Redis OSS 5.0.5 e versioni successive, puoi scalare i cluster abilitati al failover automatico mentre il cluster continua a rimanere online e a soddisfare le richieste in arrivo. Nella versione Redis OSS 4.0.10 e precedenti, è possibile notare una breve interruzione delle operazioni di lettura e scrittura sulle versioni precedenti dal nodo primario durante l'aggiornamento della voce DNS.
La quantità di tempo necessaria per passare a un tipo di nodo più grande varia a seconda del tipo di nodo e della quantità di dati nel cluster corrente.
**Per scalare un Valkey o un Redis OSS Replication Group (API) ElastiCache**
1. Determina a quali tipi di nodi puoi scalare utilizzando l'`ListAllowedNodeTypeModifications`azione ElastiCache API con il seguente parametro.
+ `ReplicationGroupId` : il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica specifico piuttosto che tutti i gruppi di replica.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) consulta *Amazon ElastiCache API Reference*.
1. Scala il tuo attuale gruppo di replica fino al nuovo tipo di nodo utilizzando l'azione `ModifyReplicationGroup` ElastiCache API e con i seguenti parametri.
+ `ReplicationGroupId` = il nome del gruppo di replica.
+ `CacheNodeType`— il nuovo tipo di nodo più grande dei cluster in questo gruppo di replica. Questo valore deve essere uno dei tipi di istanza restituiti dall'`ListAllowedNodeTypeModifications`azione nel passaggio precedente.
+ `CacheParameterGroupName` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `ApplyImmediately` : Impostato su `true` permette di applicare immediatamente il processo di dimensionamento verso il basso. Per posporre il processo di dimensionamento verticale alla successiva finestra di manutenzione, utilizzare `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=
```
Per ulteriori informazioni, [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) consulta *Amazon ElastiCache API Reference*.
1. Se lo hai utilizzato `ApplyImmediately``=true`, monitora lo stato del gruppo di replica utilizzando l'`DescribeReplicationGroups`azione ElastiCache API con i seguenti parametri. Quando lo stato cambia da *modifica in corso* a *disponibile*, puoi iniziare a scrivere sul nuovo gruppo di replica ingrandito.
+ `ReplicationGroupId` = il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica particolare piuttosto che tutti i gruppi di replica.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) consulta *Amazon ElastiCache API Reference*.
## Ridimensionamento dei cluster Valkey o Redis OSS con repliche
Le sezioni seguenti illustrano come ridimensionare un cluster Valkey o Redis OSS (modalità cluster disabilitata) con nodi di replica fino a un tipo di nodo più piccolo. La garanzia che il nuovo tipo di nodo più piccolo sia abbastanza grande da accogliere tutti i dati e la gestione associata è molto importante per il successo. Per ulteriori informazioni, consulta [Garantire la disponibilità di memoria sufficiente per creare un'istantanea Valkey o Redis OSS](BestPractices.BGSAVE.md).
**Nota**
Per i cluster che eseguono il tipo di nodo r6gd, è possibile dimensionare solo le dimensioni dei nodi all'interno della famiglia di nodi r6gd.
**Importante**
Se il tuo gruppo di parametri utilizza `reserved-memory` la memoria per il sovraccarico di Valkey o Redis OSS, prima di iniziare il ridimensionamento assicurati di disporre di un gruppo di parametri personalizzato che riservi la giusta quantità di memoria per il nuovo tipo di nodo. In alternativa, è possibile modificare un gruppo di parametri personalizzato in modo che utilizzi `reserved-memory-percent` e il gruppo di parametri per il nuovo cluster.
Se stai utilizzando `reserved-memory-percent`, questa operazione non è necessaria.
Per ulteriori informazioni, consulta [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md).
**Topics**
### Ridimensionamento di un cluster Valkey o Redis OSS con repliche (Console)
Il seguente processo ridimensiona il cluster Valkey o Redis OSS con nodi di replica su un tipo di nodo più piccolo utilizzando la console. ElastiCache
**Per ridimensionare un cluster Valkey o Redis OSS con nodi di replica (console)**
1. Verificare che il dimensionamento a un tipo di nodo più piccolo sia adeguato ai dati e all'overhead.
1. Se il tuo gruppo di parametri utilizza `reserved-memory` la memoria per il sovraccarico di Valkey o Redis OSS, assicurati di disporre di un gruppo di parametri personalizzato per mettere da parte la quantità di memoria corretta per il nuovo tipo di nodo.
In alternativa, puoi modificare un gruppo di parametri personalizzato per utilizzare `reserved-memory-percent`. Per ulteriori informazioni, consulta [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md).
1. Accedi a Console di gestione AWS e apri la console all' ElastiCache indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Nell'elenco dei cluster, scegliere quello da diminuire. Questo cluster deve eseguire il motore Valkey o Redis OSS e non il motore Valkey o Redis OSS in cluster.
1. Scegli **Modifica**.
1. Nella procedura guidata **Modify Cluster (Modifica cluster)**:
1. Scegliere il tipo di nodo che si desidera diminuire dall'elenco **Node type (Tipo di nodo)**.
1. Se stai utilizzando `reserved-memory` per gestire la tua memoria, dall'elenco **Parameter Group (Gruppo di parametri)**, seleziona il gruppo di parametri personalizzati che riserva la quantità corretta di memoria per il nuovo tipo di nodo.
1. Per eseguire subito il processo di dimensionamento, scegliere la casella **Apply immediately (Applica immediatamente)**. Se non viene selezionata la casella **Apply immediately (Applica immediatamente)**, il processo di dimensionamento viene eseguito nel corso della successiva finestra di manutenzione del cluster.
1. Scegli **Modifica**.
1. Quando lo stato del cluster cambia da *modifica in corso* a *disponibile*, il cluster è stato dimensionato a un nuovo tipo di nodo. Non è necessario aggiornare gli endpoint nell'applicazione.
### Ridimensionamento di un gruppo di replica Valkey o Redis OSS ()AWS CLI
La procedura seguente ridimensiona il gruppo di replica dal tipo di nodo corrente a un nuovo tipo di nodo di minori dimensioni utilizzando l'AWS CLI. Durante questo processo, ElastiCache aggiorna le voci DNS in modo che puntino ai nuovi nodi. Per questo motivo non è necessario aggiornare gli endpoint nell'applicazione. Per Valkey 7.2 o versioni successive o Redis OSS 5.0.5 e versioni successive, puoi scalare i cluster abilitati al failover automatico mentre il cluster continua a rimanere online e a soddisfare le richieste in arrivo. Sulla versione 4.0.10 e precedenti, si potrebbe verificare una breve interruzione di letture e scritture su versioni precedenti dal nodo primario mentre la voce DNS viene aggiornata.
Tuttavia, le letture dai cluster di replica di lettura continuano senza interruzioni.
La quantità di tempo necessaria per la scalabilità a un tipo di nodo più piccolo varia a seconda del tipo di nodo e della quantità di dati nel cluster corrente.
**Per ridimensionare un Valkey o Redis OSS Replication Group ()AWS CLI**
1. Determina a quali tipi di nodi puoi ridimensionare eseguendo il AWS CLI`list-allowed-node-type-modifications` comando con il seguente parametro.
+ `--replication-group-id` : il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica particolare piuttosto che tutti i gruppi di replica.
Per Linux, macOS o Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Per Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
L'output di questa operazione è simile al seguente (in formato JSON).
```
{
"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"
]
}
```
Per ulteriori informazioni, consulta [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) nella *documentazione di riferimento AWS CLI*.
1. Ridimensiona il gruppo di replica corrente fino al nuovo tipo di nodo utilizzando il AWS CLI`modify-replication-group` comando con i seguenti parametri.
+ `--replication-group-id` : il nome del gruppo di replica.
+ `--cache-node-type`— il nuovo tipo di nodo più piccolo dei cluster in questo gruppo di replica. Questo valore deve essere uno dei tipi di istanza restituiti dal `list-allowed-node-type-modifications` comando nel passaggio precedente.
+ `--cache-parameter-group-name` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `--apply-immediately` : Consente di applicare immediatamente il dimensionamento verso l'alto. Per posporre l'operazione di dimensionamento verso l'alto alla finestra di manutenzione successiva, utilizzare `--no-apply-immediately`.
Per Linux, macOS o 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
```
Per 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
```
L'output di questo comando è simile al seguente (in formato JSON).
```
{"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": {}
}
}
```
Per ulteriori informazioni, consulta [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) nella *documentazione di riferimento AWS CLI*.
1. Se avete utilizzato il `--apply-immediately` parametro, monitorate lo stato del gruppo di replica utilizzando il AWS CLI`describe-replication-group` comando con il seguente parametro. Quando lo stato cambia da *modifica in corso* a *disponibile*, puoi iniziare a scrivere sul nuovo gruppo di replica ridotto.
+ `--replication-group-id` : il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica particolare piuttosto che tutti i gruppi di replica.
Per Linux, macOS o Unix:
```
aws elasticache describe-replication-group \
--replication-group-id my-replication-group
```
Per Windows:
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
Per ulteriori informazioni, consulta [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) nella *documentazione di riferimento AWS CLI*.
### Ridimensionamento di un gruppo di replica (API) Valkey o Redis OSS ElastiCache
Il seguente processo ridimensiona il gruppo di replica dal tipo di nodo corrente a un nuovo tipo di nodo più piccolo utilizzando l'API. ElastiCache Durante questo processo, ElastiCache aggiorna le voci DNS in modo che puntino ai nuovi nodi. Per questo motivo non è necessario aggiornare gli endpoint nell'applicazione. Per Valkey 7.2 e versioni successive o Redis OSS 5.0.5 e versioni successive, puoi scalare i cluster abilitati al failover automatico mentre il cluster continua a rimanere online e a soddisfare le richieste in arrivo. Nella versione 4.0.10 e precedenti di Redis OSS, è possibile notare una breve interruzione delle operazioni di lettura e scrittura sulle versioni precedenti dal nodo primario durante l'aggiornamento della voce DNS. Tuttavia, le letture dai cluster di replica di lettura continuano senza interruzioni.
La quantità di tempo necessaria per la scalabilità a un tipo di nodo più piccolo varia a seconda del tipo di nodo e della quantità di dati nel cluster corrente.
**Per ridimensionare un Valkey o Redis OSS Replication Group (API) ElastiCache**
1. Determina a quali tipi di nodi puoi ridimensionare utilizzando l'`ListAllowedNodeTypeModifications`azione ElastiCache API con il seguente parametro.
+ `ReplicationGroupId` : il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica specifico piuttosto che tutti i gruppi di replica.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) consulta *Amazon ElastiCache API Reference*.
1. Scala il tuo attuale gruppo di replica fino al nuovo tipo di nodo utilizzando l'azione `ModifyReplicationGroup` ElastiCache API e con i seguenti parametri.
+ `ReplicationGroupId` = il nome del gruppo di replica.
+ `CacheNodeType`— il nuovo tipo di nodo più piccolo dei cluster in questo gruppo di replica. Questo valore deve essere uno dei tipi di istanza restituiti dall'`ListAllowedNodeTypeModifications`azione nel passaggio precedente.
+ `CacheParameterGroupName` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `ApplyImmediately` - Impostato su `true` permette di applicare immediatamente il processo di dimensionamento verso il basso. Per posporre il processo di dimensionamento verso il basso alla successiva finestra di manutenzione, utilizzare `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=
```
Per ulteriori informazioni, [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) consulta *Amazon ElastiCache API Reference*.
1. Se lo hai utilizzato `ApplyImmediately``=true`, monitora lo stato del gruppo di replica utilizzando l'`DescribeReplicationGroups`azione ElastiCache API con i seguenti parametri. Quando lo stato cambia da *modifica in corso* a *disponibile*, puoi iniziare a scrivere sul nuovo gruppo di replica ridotto.
+ `ReplicationGroupId` : il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica particolare piuttosto che tutti i gruppi di replica.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) consulta *Amazon ElastiCache API Reference*.
## Aumento della capacità di lettura
Per aumentare la capacità di lettura, aggiungi repliche di lettura (fino a un massimo di cinque) al tuo gruppo di replica Valkey o Redis OSS.
Puoi scalare la capacità di lettura del cluster Valkey o Redis OSS utilizzando la ElastiCache console, l'o l'API.AWS CLI ElastiCache Per ulteriori informazioni, consulta [Aggiungere una replica di lettura per Valkey o Redis OSS (modalità cluster disabilitata)](Replication.AddReadReplica.md).
## Diminuzione della capacità di lettura
Per ridurre la capacità di lettura, elimina una o più repliche di lettura dal cluster Valkey o Redis OSS con repliche (chiamate *gruppo di replica nell'API/CLI*). Se il cluster ha abilitata la funzione Multi-AZ con failover automatico, non puoi eliminare l'ultima replica di lettura senza prima disabilitare la funzione Multi-AZ. Per ulteriori informazioni, consulta [Modifica di un gruppo di replica](Replication.Modify.md).
Per ulteriori informazioni, consulta [Eliminazione di una replica di lettura per Valkey o Redis OSS (modalità cluster disabilitata)](Replication.RemoveReadReplica.md).
# Scalabilità dei cluster Valkey o Redis OSS (Cluster Mode Enabled)
Man mano che la domanda dei cluster cambia, potresti decidere di migliorare le prestazioni o ridurre i costi modificando il numero di shard nel cluster Valkey o Redis OSS (modalità cluster abilitata). Per questa operazione si consiglia di utilizzare il dimensionamento orizzontale online, poiché consente ai cluster di continuare a servire le richieste durante il processo di dimensionamento.
È possibile decidere di ridimensionare il cluster in presenza delle seguenti condizioni:
+ **Utilizzo elevato di memoria:**
Se i nodi nel cluster sono sottoposti a utilizzo elevato di memoria, è possibile decidere di aumentare le dimensioni per disporre delle risorse necessarie per migliorare l'archiviazione dei dati e servire le richieste.
Puoi determinare se i tuoi nodi sono sotto pressione in termini di memoria monitorando le seguenti metriche:, e. *FreeableMemory*SwapUsage*BytesUsedForCache***
+ **Collo di bottiglia della CPU o della rete:**
Se i latency/throughput problemi affliggono il cluster, potrebbe essere necessario eseguire una scalabilità orizzontale per risolverli.
Puoi monitorare i livelli di latenza e velocità effettiva monitorando le seguenti metriche: *CPUUtilization*,,, *NetworkBytesIn*e. *NetworkBytesOut*CurrConnections*NewConnections***
+ **Il cluster è sovradimensionato:**
La domanda corrente sul cluster è tale che la riduzione delle dimensioni non compromette le prestazioni e riduce i costi.
È possibile monitorare l'utilizzo del cluster per determinare se è possibile scalare in sicurezza o meno utilizzando le seguenti metriche: *FreeableMemory*,,, *SwapUsage*, *BytesUsedForCache*CPUUtilization*NetworkBytesIn***, *NetworkBytesOut*e. *CurrConnections*NewConnections**
**Impatto del dimensionamento sulle prestazioni**
Quando si effettua il dimensionamento utilizzando il processo offline, il cluster è offline per una porzione significativa del processo, pertanto non è disponibile per servire le richieste. Quando si effettua il dimensionamento utilizzando il metodo online, poiché il dimensionamento è un'operazione di calcolo intensiva, si registra un peggioramento delle prestazioni ma, nonostante tutto, il cluster continua a servire richieste mediante l'operazione di scalabilità. Il livello di peggioramento riscontrato dipende dall'utilizzo normale della CPU e dai dati.
Esistono due modi per scalare il cluster Valkey o Redis OSS (modalità cluster abilitata): scalabilità orizzontale e verticale.
+ Il ridimensionamento orizzontale permette di modificare il numero di gruppi di nodi (shard) nel gruppo di replica aggiungendo o rimuovendo gruppi di nodi (shard). Il processo di resharding online consente la scalabilità in/out mentre il cluster continua a soddisfare le richieste in arrivo.
Configurare gli slot nel nuovo cluster in modo diverso rispetto a quando si trovavano nel vecchio cluster. Solo metodo offline.
+ Ridimensionamento verticale: ridimensiona il cluster tramite la modifica del tipo di nodo. La scalabilità verticale online consente la scalabilità up/down mentre il cluster continua a soddisfare le richieste in arrivo.
Se state riducendo le dimensioni e la capacità di memoria del cluster, mediante una scalabilità verso l'alto o verso il basso, assicuratevi che la nuova configurazione disponga di memoria sufficiente per i dati e il sovraccarico di Valkey o Redis OSS.
Per ulteriori informazioni, consulta [Scelta delle dimensioni dei nodi](CacheNodes.SelectSize.md).
**Contents**
+ [Resharding offline per Valkey o Redis OSS (modalità cluster abilitata)](#redis-cluster-resharding-offline)
+ [Resharding online per Valkey o Redis OSS (modalità cluster abilitata)](#redis-cluster-resharding-online)
+ [Aggiunta dele partizioni con il resharding online](#redis-cluster-resharding-online-add)
+ [Rimozione dele partizioni con il resharding online](#redis-cluster-resharding-online-remove)
+ [Rimozione dle partizioni (Console)](#redis-cluster-resharding-online-remove-console)
+ [Rimozione dele partizioni (AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [Rimozione degli shard (API) ElastiCache](#redis-cluster-resharding-online-remove-api)
+ [Ribilanciamento dle partizioni online](#redis-cluster-resharding-online-rebalance)
+ [Ribilanciamento dle partizioni online (Console)](#redis-cluster-resharding-online-rebalance-console)
+ [Ribilanciamento dle partizioni online (AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [Rebilanciamento degli shard online (API) ElastiCache](#redis-cluster-resharding-online-rebalance-api)
+ [Ridimensionamento verticale online tramite la modifica del tipo di nodo](redis-cluster-vertical-scaling.md)
+ [Dimensionamento verso l'alto online](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
+ [Scalabilità dei cluster Valkey o Redis OSS (console)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-console)
+ [Scalabilità dei cluster Valkey o Redis OSS ()AWS CLI](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Scalabilità dei cluster Valkey o Redis OSS (API) ElastiCache](redis-cluster-vertical-scaling.md#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [Dimensionamento verso il basso online](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-down)
+ [Ridimensionamento dei cluster Valkey o Redis OSS (console)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-down-console)
+ [Ridimensionamento dei cluster Valkey o Redis OSS ()AWS CLI](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Ridimensionamento dei cluster Valkey o Redis OSS (API) ElastiCache](redis-cluster-vertical-scaling.md#Scaling.Vertical.ScaleDown.API)
## Resharding offline per Valkey o Redis OSS (modalità cluster abilitata)
Il vantaggio principale derivante dalla riconfigurazione degli shard offline è la possibilità di andare oltre la semplice aggiunta o rimozione degli shard dal gruppo di replica. Quando si esegue il reshard e il ribilanciamento offline, oltre a modificare il numero di shard nel gruppo di replica, è possibile effettuare le seguenti operazioni:
**Nota**
Il resharding offline non è supportato sui cluster Valkey o Redis OSS con il tiering dei dati abilitato. Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
+ Cambiare il tipo di nodo per il gruppo di replica.
+ Specificare la zona di disponibilità per ogni nodo nel gruppo di replica.
+ Effettuare l'upgrade a una versione del motore più recente.
+ Specificare il numero dei nodi di replica in ogni shard in modo indipendente.
+ Specificare il keyspace per ogni shard.
Lo svantaggio principale della riconfigurazione shard offline è che il cluster è offline a partire dalla fase di ripristino del processo e continua a essere offline fino agli aggiornamenti degli endpoint nell'applicazione. Il periodo di tempo in cui il cluster rimane offline dipende dalla quantità di dati nel cluster.
**Per riconfigurare i tuoi shard, Valkey o Redis OSS (modalità cluster abilitata), cluster offline**
1. Crea un backup manuale del tuo cluster Valkey o Redis OSS esistente. Per ulteriori informazioni, consulta [Esecuzione di backup manuali](backups-manual.md).
1. Creare un nuovo cluster eseguendo il ripristino dal backup. Per ulteriori informazioni, consulta [Ripristino da un backup in una nuova cache](backups-restoring.md).
1. Aggiornare gli endpoint nell'applicazione agli endpoint del nuovo cluster. Per ulteriori informazioni, consulta [Ricerca degli endpoint di connessione in ElastiCache](Endpoints.md).
## Resharding online per Valkey o Redis OSS (modalità cluster abilitata)
Utilizzando il resharding online e il ribilanciamento degli shard con ElastiCache Valkey 7.2 o versione successiva o Redis OSS versione 3.2.10 o successiva, puoi scalare il tuo cluster Valkey o Redis OSS (abilitata in modalità cluster) in modo dinamico senza tempi di inattività. Questo approccio indica che il cluster può continuare a servire le richieste anche durante il dimensionamento o il ribilanciamento.
È possibile effettuare le seguenti operazioni:
+ **Scalabilità** orizzontale: aumenta la capacità di lettura e scrittura aggiungendo shard (gruppi di nodi) al cluster Valkey o Redis OSS (modalità cluster abilitata) (gruppo di replica).
Se si aggiungono una o più partizioni al gruppo di replica, il numero di nodi nella nuova partizione è lo stesso del numero di nodi nella più piccola delle partizioni esistenti.
+ **Scalabilità integrata**: riduci la capacità di lettura e scrittura, e quindi i costi, rimuovendo gli shard dal cluster Valkey o Redis OSS (abilitata la modalità cluster).
+ **Ribilanciamento**: sposta gli spazi chiave tra gli shard del cluster Valkey o Redis OSS (modalità cluster abilitata) in modo che siano distribuiti il più equamente possibile tra gli shard.
Non puoi eseguire le operazioni indicate di seguito:
+ **Configurare le partizioni in modo indipendente:**
Non è possibile specificare il keyspace per le partizioni in modo indipendente. Per fare ciò, è necessario utilizzare il processo offline.
Attualmente, al resharding e al ribilanciamento online si applicano le seguenti limitazioni: ElastiCache
+ Questi processi richiedono Valkey 7.2 e versioni successive o Redis OSS 3.2.10 o versioni successive. Per ulteriori informazioni sull'aggiornamento della versione del motore, consultare [Gestione delle versioni per ElastiCache](VersionManagement.md).
+ Gli slot, gli spazi chiave e gli elementi grandi prevedono delle limitazioni:
Se alcune chiavi in una partizione contengono un elemento grande, quelle chiavi non possono essere migrate a un nuovo shard durante l'aumento delle dimensioni o il ribilanciamento. Questa caratteristicapuò produrre partizioni non bilanciati.
Se alcune chiavi in una partizione contengono un elemento grande (di dimensioni superiori a 256 MB dopo la serializzazione), quella partizione non viene eliminato se le dimensioni diminuiscono. Con questa caratteristicaalcunle partizioni potrebbero non essere eliminati.
+ Durante il dimensionamento verso l'alto, il numero di nodi in tutte le nuove partizioni è uguale al numero di nodi nella partizione più piccola esistente.
+ Durante l'aumento delle dimensioni, tutti i tag comuni a tutti le partizioni esistenti vengono copiati sui nuovle partizioni.
+ Quando si esegue la scalabilità orizzontale di un cluster Global Data Store, non ElastiCache replicherà automaticamente le funzioni da uno dei nodi esistenti ai nuovi nodi. Consigliamo di caricare le funzioni nelle nuove partizioni dopo aver aumentato orizzontalmente il cluster in modo che tutte le partizioni abbiano le stesse funzioni.
**Nota**
Disponibile ElastiCache per Valkey 7.2 e versioni successive e ElastiCache per Redis OSS versione 7 e successive: durante la scalabilità orizzontale del cluster, ElastiCache replicherà automaticamente le funzioni caricate in uno dei nodi esistenti (selezionati a caso) sui nuovi nodi. Se la tua applicazione utilizza [Functions](https://valkey.io/topics/functions-intro/), ti consigliamo di caricare tutte le funzioni su tutti gli shard prima di eseguire la scalabilità orizzontale, in modo che il cluster non finisca con definizioni di funzioni diverse su shard diversi.
Per ulteriori informazioni, consulta [Ridimensionamento di cluster online](best-practices-online-resharding.md).
È possibile scalare o ribilanciare orizzontalmente i cluster Valkey o Redis OSS (modalità cluster abilitata) utilizzando, the e l'API.Console di gestione AWSAWS CLI ElastiCache
### Aggiunta dele partizioni con il resharding online
È possibile aggiungere shard al cluster Valkey o Redis OSS (modalità cluster abilitata) utilizzando l'API, o.Console di gestione AWSAWS CLI ElastiCache Quando aggiungi shard a un cluster Valkey o Redis OSS (modalità cluster abilitata), tutti i tag sugli shard esistenti vengono copiati nei nuovi shard.
**Topics**
#### Aggiunta dle partizioni (Console)
È possibile utilizzare il Console di gestione AWS per aggiungere uno o più shard al cluster Valkey o Redis OSS (modalità cluster abilitata). Questo processo viene descritto di seguito.
**Per aggiungere shard al cluster Valkey o Redis OSS (modalità cluster abilitata)**
1. Apri la console all' ElastiCache indirizzo. [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Dal pannello di navigazione, scegli i cluster **Valkey o i cluster** **Redis OSS**.
1. Individua e scegli il nome, non la casella a sinistra del nome del cluster, del cluster Valkey o Redis OSS (modalità cluster abilitata) a cui desideri aggiungere gli shard.
**Suggerimento**
****Valkey o Redis OSS (modalità cluster abilitata) mostrano Clustered **Valkey o Clustered** Redis OSS nella colonna Mode****
1. Scegliere **Add shard (Aggiungere partizioni)**.
1. Per **Number of Shards to be added (Numero dle partizioni da aggiungere)**, scegliere il numero dle partizioni che si desidera aggiungere a questo cluster.
1. Per **Availability Zone(s) (Zone di disponibilità)**, scegliere **No preference (Nessuna preferenza)** o **Specify availability zones (Specifica zone di disponibilità)**.
1. Se è stato selezionato **Specify availability zones (Specifica zone di disponibilità)** per ciascun nodo in ognle partizioni seleziona una zona disponibilità del nodo dall'elenco delle zone di disponibilità.
1. Scegliere **Aggiungi**.
#### Aggiunta dle partizioni (AWS CLI)
Il processo seguente descrive come riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) aggiungendo shard utilizzando.AWS CLI
Utilizzare i seguenti parametri con `modify-replication-group-shard-configuration`.
**Parameters**
+ `--apply-immediately` : Obbligatorio Specifica che l'operazione di riconfigurazione dele partizioni deve essere avviata immediatamente.
+ `--replication-group-id` : Obbligatorio Specifica su quale gruppo di replica (cluster) deve essere eseguita l'operazione di riconfigurazione dele partizioni.
+ `--node-group-count` : Obbligatorio Specifica il numero dle partizioni (gruppi di nodi) che deve esistere al completamento dell'operazione. Quando si aggiungono le partizioni, il valore di `--node-group-count` deve essere maggiore del numero corrente dle partizioni.
Facoltativamente, è possibile specificare la zona di disponibilità per ogni nodo nel gruppo di replica, utilizzando `--resharding-configuration`.
+ `--resharding-configuration` : Opzionale. Un elenco di zone di disponibilità preferite per ogni nodo in ognle partizioni nel gruppo di replica. Utilizzare questo parametro solo se il valore di `--node-group-count` è maggiore del numero corrente dle partizioni. Se questo parametro viene omesso durante l'aggiunta di shard, Amazon ElastiCache seleziona le zone di disponibilità per i nuovi nodi.
L'esempio seguente riconfigura gli spazi chiave su quattro shard in un cluster Valkey o Redis OSS (modalità cluster abilitata) denominato. `my-cluster` Specifica inoltre le zone di disponibilità per ogni nodo in ognle partizioni. L'operazione inizia immediatamente.
**Example - Aggiunta dle partizioni**
Per Linux, macOS o 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
```
Per 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
```
[Per ulteriori informazioni, consulta -configuration nella documentazione. modify-replication-group-shard](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html)AWS CLI
#### Aggiungere frammenti (API) ElastiCache
È possibile utilizzare l' ElastiCache API per riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) online utilizzando l'operazione. `ModifyReplicationGroupShardConfiguration`
Utilizzare i seguenti parametri con `ModifyReplicationGroupShardConfiguration`.
**Parameters**
+ `ApplyImmediately=true` : Obbligatorio Specifica che l'operazione di riconfigurazione dele partizioni deve essere avviata immediatamente.
+ `ReplicationGroupId` : Obbligatorio Specifica su quale gruppo di replica (cluster) deve essere eseguita l'operazione di riconfigurazione dele partizioni.
+ `NodeGroupCount` : Obbligatorio Specifica il numero dle partizioni (gruppi di nodi) che deve esistere al completamento dell'operazione. Quando si aggiungono le partizioni, il valore di `NodeGroupCount` deve essere maggiore del numero corrente dle partizioni.
Facoltativamente, è possibile specificare la zona di disponibilità per ogni nodo nel gruppo di replica, utilizzando `ReshardingConfiguration`.
+ `ReshardingConfiguration` : Opzionale. Un elenco di zone di disponibilità preferite per ogni nodo in ognle partizioni nel gruppo di replica. Utilizzare questo parametro solo se il valore di `NodeGroupCount` è maggiore del numero corrente dle partizioni. Se questo parametro viene omesso durante l'aggiunta di shard, Amazon ElastiCache seleziona le zone di disponibilità per i nuovi nodi.
Il processo seguente descrive come riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) aggiungendo shard utilizzando l'API. ElastiCache
**Example - Aggiunta dle partizioni**
L'esempio seguente aggiunge gruppi di nodi al cluster Valkey o Redis OSS (modalità cluster abilitata)`my-cluster`, quindi ci sono un totale di quattro gruppi di nodi al termine dell'operazione. Specifica inoltre le zone di disponibilità per ogni nodo in ognle partizioni. L'operazione inizia immediatamente.
```
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=
```
Per ulteriori informazioni, consulta l'API [ModifyReplicationGroupShardConfiguration](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html)Reference. ElastiCache
### Rimozione dele partizioni con il resharding online
È possibile rimuovere gli shard dal cluster Valkey o Redis OSS (modalità cluster abilitata) utilizzando l'API Console di gestione AWSAWS CLI, o. ElastiCache
**Topics**
+ [Rimozione dle partizioni (Console)](#redis-cluster-resharding-online-remove-console)
+ [Rimozione dele partizioni (AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [Rimozione degli shard (API) ElastiCache](#redis-cluster-resharding-online-remove-api)
#### Rimozione dle partizioni (Console)
Il processo seguente descrive come riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) rimuovendo gli shard utilizzando.Console di gestione AWS
Prima di rimuovere i gruppi di nodi (shard) dal gruppo di replica, assicuratevi che tutti i dati ElastiCache rientrino negli shard rimanenti. Se i dati sono adatti, le partizioni specificati vengono eliminati dal gruppo di replica come richiesto. Se i dati non si adattano ai restanti gruppi di nodi, il processo viene terminato e il gruppo di replica viene lasciato con la stessa configurazione del gruppo di nodi precedente alla richiesta.
È possibile utilizzare il Console di gestione AWS per rimuovere uno o più shard dal cluster Valkey o Redis OSS (modalità cluster abilitata). Non puoi rimuovere tutti le partizioni in un gruppo di replica. Invece, è necessario eliminare il gruppo di replica. Per ulteriori informazioni, consulta [Eliminazione di un gruppo di replica](Replication.DeletingRepGroup.md). La procedura seguente descrive l'eliminazione di una o più partizioni.
**Per rimuovere gli shard dal cluster Valkey o Redis OSS (modalità cluster abilitata)**
1. Apri la console all' ElastiCache indirizzo. [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Dal pannello di navigazione, scegli i cluster **Valkey o i cluster** **Redis OSS**.
1. Individua e scegli il nome, non la casella a sinistra del nome del cluster, del cluster Valkey o Redis OSS (modalità cluster abilitata) da cui desideri rimuovere gli shard.
**Suggerimento**
**I cluster Valkey o Redis OSS (modalità cluster abilitata) hanno un valore pari o superiore a 1 nella colonna Shards.**
1. Dall'elenco dle partizioni, scegliere la casella a sinistra del nome di ognle partizioni da eliminare.
1. Scegliere **Delete shard (Elimina partizione)**.
#### Rimozione dele partizioni (AWS CLI)
Il processo seguente descrive come riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) rimuovendo gli shard utilizzando.AWS CLI
**Importante**
Prima di rimuovere i gruppi di nodi (shard) dal gruppo di replica, assicuratevi che tutti i dati ElastiCache rientrino negli shard rimanenti. Se i dati sono adatti, le partizioni specificati (`--node-groups-to-remove`) vengono eliminati dal gruppo di replica come richiesto e i loro spazi chiave vengono mappati nele partizioni rimanenti. Se i dati non si adattano ai restanti gruppi di nodi, il processo viene terminato e il gruppo di replica viene lasciato con la stessa configurazione del gruppo di nodi precedente alla richiesta.
È possibile utilizzare il AWS CLI per rimuovere uno o più shard dal cluster Valkey o Redis OSS (modalità cluster abilitata). Non puoi rimuovere tutti le partizioni in un gruppo di replica. Invece, è necessario eliminare il gruppo di replica. Per ulteriori informazioni, consulta [Eliminazione di un gruppo di replica](Replication.DeletingRepGroup.md).
Utilizzare i seguenti parametri con `modify-replication-group-shard-configuration`.
**Parameters**
+ `--apply-immediately` : Obbligatorio Specifica che l'operazione di riconfigurazione dele partizioni deve essere avviata immediatamente.
+ `--replication-group-id` : Obbligatorio Specifica su quale gruppo di replica (cluster) deve essere eseguita l'operazione di riconfigurazione dele partizioni.
+ `--node-group-count` : Obbligatorio Specifica il numero dle partizioni (gruppi di nodi) che deve esistere al completamento dell'operazione. Quando si rimuovono le partizioni, il valore di `--node-group-count` deve essere inferiore al numero corrente dle partizioni.
+ `--node-groups-to-remove` : Obbligatorio quando `--node-group-count` è inferiore al numero corrente di gruppi di nodi (partizioni). Un elenco di shard (gruppo di nodi) da rimuovere dal gruppo IDs di replica.
La procedura seguente descrive l'eliminazione di una o più partizioni.
**Example - Rimozione dele partizioni**
L'esempio seguente rimuove due gruppi di nodi dal cluster Valkey o Redis OSS (modalità cluster enabled)`my-cluster`, quindi al termine dell'operazione vi sono un totale di due gruppi di nodi. Gli spazi chiave dale partizioni rimossi sono distribuiti uniformemente tra le partizioni rimanenti.
Per Linux, macOS o 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
```
Per 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
```
#### Rimozione degli shard (API) ElastiCache
È possibile utilizzare l' ElastiCache API per riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) online utilizzando l'operazione. `ModifyReplicationGroupShardConfiguration`
Il processo seguente descrive come riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) rimuovendo gli shard utilizzando l'API. ElastiCache
**Importante**
Prima di rimuovere i gruppi di nodi (shard) dal gruppo di replica, assicurati che tutti i dati ElastiCache rientrino negli shard rimanenti. Se i dati sono adatti, le partizioni specificati (`NodeGroupsToRemove`) vengono eliminati dal gruppo di replica come richiesto e i loro spazi chiave vengono mappati nele partizioni rimanenti. Se i dati non si adattano ai restanti gruppi di nodi, il processo viene terminato e il gruppo di replica viene lasciato con la stessa configurazione del gruppo di nodi precedente alla richiesta.
È possibile utilizzare l' ElastiCache API per rimuovere uno o più shard dal cluster Valkey o Redis OSS (modalità cluster abilitata). Non puoi rimuovere tutti le partizioni in un gruppo di replica. Invece, è necessario eliminare il gruppo di replica. Per ulteriori informazioni, consulta [Eliminazione di un gruppo di replica](Replication.DeletingRepGroup.md).
Utilizzare i seguenti parametri con `ModifyReplicationGroupShardConfiguration`.
**Parameters**
+ `ApplyImmediately=true` : Obbligatorio Specifica che l'operazione di riconfigurazione dele partizioni deve essere avviata immediatamente.
+ `ReplicationGroupId` : Obbligatorio Specifica su quale gruppo di replica (cluster) deve essere eseguita l'operazione di riconfigurazione dele partizioni.
+ `NodeGroupCount` : Obbligatorio Specifica il numero dle partizioni (gruppi di nodi) che deve esistere al completamento dell'operazione. Quando si rimuovono le partizioni, il valore di `NodeGroupCount` deve essere inferiore al numero corrente dle partizioni.
+ `NodeGroupsToRemove` : Obbligatorio quando `--node-group-count` è inferiore al numero corrente di gruppi di nodi (partizioni). Un elenco di shard (gruppo di nodi) da rimuovere dal gruppo IDs di replica.
La procedura seguente descrive l'eliminazione di una o più partizioni.
**Example - Rimozione dele partizioni**
L'esempio seguente rimuove due gruppi di nodi dal cluster Valkey o Redis OSS (modalità cluster enabled)`my-cluster`, quindi al termine dell'operazione vi sono un totale di due gruppi di nodi. Gli spazi chiave dale partizioni rimossi sono distribuiti uniformemente tra le partizioni rimanenti.
```
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=
```
### Ribilanciamento dle partizioni online
È possibile ribilanciare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) utilizzando l'API, o.Console di gestione AWSAWS CLI ElastiCache
**Topics**
+ [Ribilanciamento dle partizioni online (Console)](#redis-cluster-resharding-online-rebalance-console)
+ [Ribilanciamento dle partizioni online (AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [Rebilanciamento degli shard online (API) ElastiCache](#redis-cluster-resharding-online-rebalance-api)
#### Ribilanciamento dle partizioni online (Console)
Il processo seguente descrive come riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) ribilanciando gli shard utilizzando.Console di gestione AWS
**Per ribilanciare gli spazi chiave tra gli shard sul cluster Valkey o Redis OSS (modalità cluster abilitata)**
1. Apri ElastiCache [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)la console all'indirizzo.
1. Dal pannello di navigazione, scegli i cluster **Valkey o i cluster** **Redis OSS**.
1. Scegli il nome, non la casella a sinistra del nome, del cluster Valkey o Redis OSS (modalità cluster abilitata) che desideri ribilanciare.
**Suggerimento**
**I cluster Valkey o Redis OSS (modalità cluster abilitata) hanno un valore pari o superiore a 1 nella colonna Shards.**
1. Scegliere **Rebalance (Ribilancia)**.
1. Quando richiesto, scegliere **Rebalance (Ribilancia)**. Potresti vedere un messaggio simile a questo:. *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)* Se viene visualizzato il messaggio, scegliere **Cancel (Annulla)**.
#### Ribilanciamento dle partizioni online (AWS CLI)
Utilizzare i seguenti parametri con `modify-replication-group-shard-configuration`.
**Parameters**
+ `-apply-immediately` : Obbligatorio Specifica che l'operazione di riconfigurazione dele partizioni deve essere avviata immediatamente.
+ `--replication-group-id` : Obbligatorio Specifica su quale gruppo di replica (cluster) deve essere eseguita l'operazione di riconfigurazione dele partizioni.
+ `--node-group-count` : Obbligatorio Per ribilanciare gli spazi chiave su tutti le partizioni nel cluster, questo valore deve essere lo stesso del numero dle partizioni corrente.
Il processo seguente descrive come riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) ribilanciando gli shard utilizzando.AWS CLI
**Example - Ribilanciamento dele partizioni in un cluster**
L'esempio seguente ribilancia gli slot nel cluster Valkey o Redis OSS (modalità cluster abilitata) in modo che gli slot siano distribuiti nel modo più equo possibile. `my-cluster` Il valore di `--node-group-count` (`4`) rappresenta il numero dle partizioni attualmente nel cluster.
Per Linux, macOS o Unix:
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 4 \
--apply-immediately
```
Per Windows:
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 4 ^
--apply-immediately
```
#### Rebilanciamento degli shard online (API) ElastiCache
È possibile utilizzare l' ElastiCache API per riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) online utilizzando l'operazione. `ModifyReplicationGroupShardConfiguration`
Utilizzare i seguenti parametri con `ModifyReplicationGroupShardConfiguration`.
**Parameters**
+ `ApplyImmediately=true` : Obbligatorio Specifica che l'operazione di riconfigurazione dele partizioni deve essere avviata immediatamente.
+ `ReplicationGroupId` : Obbligatorio Specifica su quale gruppo di replica (cluster) deve essere eseguita l'operazione di riconfigurazione dele partizioni.
+ `NodeGroupCount` : Obbligatorio Per ribilanciare gli spazi chiave su tutti le partizioni nel cluster, questo valore deve essere lo stesso del numero dle partizioni corrente.
Il processo seguente descrive come riconfigurare gli shard nel cluster Valkey o Redis OSS (modalità cluster abilitata) ribilanciando gli shard utilizzando l'API. ElastiCache
**Example - Ribilanciamento di un cluster**
L'esempio seguente ribilancia gli slot nel cluster Valkey o Redis OSS (modalità cluster abilitata) in modo che gli slot siano distribuiti nel modo più equo possibile. `my-cluster` Il valore di `NodeGroupCount` (`4`) rappresenta il numero dle partizioni attualmente nel cluster.
```
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=
```
# Ridimensionamento verticale online tramite la modifica del tipo di nodo
Utilizzando la scalabilità verticale online con Valkey versione 7.2 o successiva o Redis OSS versione 3.2.10 o successiva, è possibile scalare i cluster Valkey o Redis OSS in modo dinamico con tempi di inattività minimi. Ciò consente al cluster Valkey o Redis OSS di soddisfare le richieste anche durante la scalabilità.
**Nota**
Il dimensionamento non è supportato tra un cluster di tiering di dati (ad esempio, un cluster che utilizza un tipo di nodo r6gd) e un cluster che non utilizza il tiering di dati (ad esempio, un cluster che utilizza un tipo di nodo r6g). Per ulteriori informazioni, consulta [Suddivisione dei dati su più livelli in ElastiCache](data-tiering.md).
È possibile effettuare le seguenti operazioni:
+ **Scalabilità verticale: aumenta** la capacità di lettura e scrittura modificando il tipo di nodo del cluster Valkey o Redis OSS per utilizzare un tipo di nodo più grande.
ElastiCache ridimensiona dinamicamente il cluster rimanendo online e soddisfacendo le richieste.
+ **Riduzione verticale** - Riduce la capacità di lettura e scrittura modificando il tipo di nodo affinché utilizzi un nodo più piccolo. Anche in questo caso, ridimensiona ElastiCache dinamicamente il cluster rimanendo online e soddisfacendo le richieste. In questo caso, il ridimensionamento del nodo permette di ridurre i costi.
**Nota**
I processi di dimensionamento verso l'alto e il basso si basano sulla creazione di cluster con i nuovi tipi di nodo selezionati e sulla sincronizzazione dei nuovi nodi con quelli precedenti. Per garantire un up/down flusso scalabile senza intoppi, procedi come segue:
Assicurati di disporre di capacità ENI (Elastic Network Interface) sufficiente. In caso di dimensionamento verso il basso, assicurati che il nodo più piccolo disponga di memoria sufficiente per assorbire il traffico previsto.
Per le best practice da seguire per la gestione della memoria, consultare [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md).
Anche se il processo di ridimensionamento verticale è progettato affinché il cluster rimanga completamente online, esso si basa sulla sincronizzazione dei dati tra il vecchio nodo e il nuovo nodo. Si consiglia di avviare il processo di dimensionamento verso l'alto/il basso durante le ore in cui si prevede che il traffico dati sia al minimo.
Se possibile, testa il comportamento della tua applicazione durante il ridimensionamento in un ambiente di prova.
**Contents**
+ [Dimensionamento verso l'alto online](#redis-cluster-vertical-scaling-scaling-up)
+ [Scalabilità dei cluster Valkey o Redis OSS (console)](#redis-cluster-vertical-scaling-console)
+ [Scalabilità dei cluster Valkey o Redis OSS ()AWS CLI](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Scalabilità dei cluster Valkey o Redis OSS (API) ElastiCache](#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [Dimensionamento verso il basso online](#redis-cluster-vertical-scaling-scaling-down)
+ [Ridimensionamento dei cluster Valkey o Redis OSS (console)](#redis-cluster-vertical-scaling-down-console)
+ [Ridimensionamento dei cluster Valkey o Redis OSS ()AWS CLI](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Ridimensionamento dei cluster Valkey o Redis OSS (API) ElastiCache](#Scaling.Vertical.ScaleDown.API)
## Dimensionamento verso l'alto online
**Topics**
+ [Scalabilità dei cluster Valkey o Redis OSS (console)](#redis-cluster-vertical-scaling-console)
+ [Scalabilità dei cluster Valkey o Redis OSS ()AWS CLI](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Scalabilità dei cluster Valkey o Redis OSS (API) ElastiCache](#VeticalScaling.RedisReplGrps.ScaleUp.API)
### Scalabilità dei cluster Valkey o Redis OSS (console)
La procedura seguente descrive come scalare un cluster Valkey o Redis OSS utilizzando la console di ElastiCache gestione. Durante questo processo, il cluster continuerà a soddisfare le richieste con tempi di inattività minimi.
**Per scalare un cluster Valkey o Redis OSS (console)**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Dal pannello di navigazione, scegli i cluster **Valkey o i cluster** **Redis OSS**.
1. Nell'elenco dei cluster, scegliere quello da ridimensionare.
1. Scegli **Modifica**.
1. Nella procedura guidata **Modify Cluster (Modifica cluster)**:
1. Scegliere il tipo di nodo a cui dimensionare dall'elenco **Node type (Tipo di nodo)**. Per aumentare, scegliere un tipo di nodo più grande del nodo esistente.
1. Per eseguire subito il processo di dimensionamento verso l'alto, scegliere la casella **Apply immediately (Applica immediatamente)**. Se non viene selezionata la casella **Apply immediately (Applica immediatamente)**, il processo di dimensionamento verso l'alto viene eseguito nel corso della successiva finestra di manutenzione del cluster.
1. Scegli **Modifica**.
Se, nel passaggio precedente, è stato scelto **Apply immediately (Applica immediatamente)**, lo stato del cluster diventa *modifica in corso*. Quando lo stato cambia in *disponibile*, la modifica è completa ed è possibile iniziare a utilizzare il nuovo cluster.
### Scalabilità dei cluster Valkey o Redis OSS ()AWS CLI
La procedura seguente descrive come scalare un cluster Valkey o Redis OSS utilizzando.AWS CLI Durante questo processo, il cluster continuerà a soddisfare le richieste con tempi di inattività minimi.
**Per scalare un cluster Valkey o Redis OSS ()AWS CLI**
1. Determina i tipi di nodi fino a cui puoi scalare eseguendo il AWS CLI`list-allowed-node-type-modifications` comando con il seguente parametro.
Per Linux, macOS o Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Per Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
L'output del comando in alto è simile al seguente (in formato JSON).
```
{
"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 "
],
}
```
Per ulteriori informazioni, consulta [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) nella *documentazione di riferimento AWS CLI*.
1. Modifica il gruppo di replica per adattarlo al nuovo tipo di nodo più grande, utilizzando il AWS CLI`modify-replication-group` comando e i seguenti parametri.
+ `--replication-group-id` : Il nome del gruppo di replica che si sta ridimensionando verso l'alto.
+ `--cache-node-type`— Il nuovo tipo di nodo con cui scalare il cluster. Questo valore deve essere uno dei tipi di nodi restituiti dal comando `list-allowed-node-type-modifications` nella fase 1.
+ `--cache-parameter-group-name` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `--apply-immediately` : Consente di applicare immediatamente il dimensionamento verso l'alto. Per posporre il processo di dimensionamento alla finestra di manutenzione successiva del cluster, utilizzare il parametro `--no-apply-immediately`.
Per Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.m3.xlarge \
--apply-immediately
```
Per Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.m3.xlarge ^
--apply-immediately
```
L'output del comando in alto è simile al seguente (in formato JSON).
```
{
"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": {}
}
}
```
Per ulteriori informazioni, consulta [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) nella *documentazione di riferimento AWS CLI*.
1. Se hai usato il`--apply-immediately`, controlla lo stato del cluster usando il AWS CLI`describe-cache-clusters` comando con il seguente parametro. Quando lo stato diventa *disponibile*, puoi iniziare a utilizzare il nuovo nodo cluster più grande.
### Scalabilità dei cluster Valkey o Redis OSS (API) ElastiCache
Il seguente processo ridimensiona il cluster dal tipo di nodo corrente a un nuovo tipo di nodo più grande utilizzando l'API. ElastiCache Durante questo processo, ElastiCache aggiorna le voci DNS in modo che puntino ai nuovi nodi. Per questo motivo non è necessario aggiornare gli endpoint nell'applicazione. Per Valkey 7.2 e versioni successive Redis OSS 5.0.5 e versioni successive, puoi scalare i cluster abilitati al failover automatico mentre il cluster continua a rimanere online e a soddisfare le richieste in arrivo. Nella versione Redis OSS 4.0.10 e precedenti, è possibile notare una breve interruzione delle operazioni di lettura e scrittura sulle versioni precedenti dal nodo primario durante l'aggiornamento della voce DNS.
La quantità di tempo necessaria per passare a un tipo di nodo più grande varia a seconda del tipo di nodo e della quantità di dati nel cluster corrente.
**Per scalare un Valkey o Redis OSS Cache Cluster (API) ElastiCache**
1. Determina a quali tipi di nodi puoi scalare utilizzando l'`ListAllowedNodeTypeModifications`azione ElastiCache API con il seguente parametro.
+ `ReplicationGroupId` : il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica specifico piuttosto che tutti i gruppi di replica.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) consulta *Amazon ElastiCache API Reference*.
1. Scala il tuo attuale gruppo di replica fino al nuovo tipo di nodo utilizzando l'azione `ModifyReplicationGroup` ElastiCache API e con i seguenti parametri.
+ `ReplicationGroupId` = il nome del gruppo di replica.
+ `CacheNodeType`— il nuovo tipo di nodo più grande dei cluster in questo gruppo di replica. Questo valore deve essere uno dei tipi di istanza restituiti dall'`ListAllowedNodeTypeModifications`azione nel passaggio precedente.
+ `CacheParameterGroupName` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `ApplyImmediately` : Impostato su `true` permette di applicare immediatamente il processo di dimensionamento verso il basso. Per posporre il processo di dimensionamento verticale alla successiva finestra di manutenzione, utilizzare `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=
```
Per ulteriori informazioni, [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) consulta *Amazon ElastiCache API Reference*.
1. Se lo hai utilizzato `ApplyImmediately``=true`, monitora lo stato del gruppo di replica utilizzando l'`DescribeReplicationGroups`azione ElastiCache API con i seguenti parametri. Quando lo stato cambia da *modifica in corso* a *disponibile*, puoi iniziare a scrivere sul nuovo gruppo di replica ingrandito.
+ `ReplicationGroupId` = il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica particolare piuttosto che tutti i gruppi di replica.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) consulta *Amazon ElastiCache API Reference*.
## Dimensionamento verso il basso online
**Topics**
+ [Ridimensionamento dei cluster Valkey o Redis OSS (console)](#redis-cluster-vertical-scaling-down-console)
+ [Ridimensionamento dei cluster Valkey o Redis OSS ()AWS CLI](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Ridimensionamento dei cluster Valkey o Redis OSS (API) ElastiCache](#Scaling.Vertical.ScaleDown.API)
### Ridimensionamento dei cluster Valkey o Redis OSS (console)
La procedura seguente descrive come ridimensionare un cluster Valkey o Redis OSS utilizzando la console di ElastiCache gestione. Durante questo processo, il cluster Valkey o Redis OSS continuerà a soddisfare le richieste con tempi di inattività minimi.
**Per ridimensionare un cluster Valkey o Redis OSS (console)**
1. Accedi a Console di gestione AWS e apri la ElastiCache console all'indirizzo. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Dal pannello di navigazione, scegli i cluster **Valkey o i cluster** **Redis OSS**.
1. Nell'elenco dei cluster, scegliere quello da ridimensionare.
1. Scegli **Modifica**.
1. Nella procedura guidata **Modify Cluster (Modifica cluster)**:
1. Scegliere il tipo di nodo a cui dimensionare dall'elenco **Node type (Tipo di nodo)**. Per la riduzione verticale, scegliere un tipo di nodo più piccolo del nodo esistente. Si noti che non tutti i tipi di nodo sono disponibili per il dimensionamento.
1. Per eseguire immediatamente il processo di riduzione verticale, scegliere la casella **Apply immediately (Applica immediatamente)**. Se non viene selezionata la casella **Apply immediately (Applica immediatamente)**, il processo di ridimensionamento verso il basso viene eseguito nel corso della successiva finestra di manutenzione del cluster.
1. Scegli **Modifica**.
Se, nel passaggio precedente, è stato scelto **Apply immediately (Applica immediatamente)**, lo stato del cluster diventa *modifica in corso*. Quando lo stato cambia in *disponibile*, la modifica è completa ed è possibile iniziare a utilizzare il nuovo cluster.
### Ridimensionamento dei cluster Valkey o Redis OSS ()AWS CLI
La procedura seguente descrive come ridimensionare un cluster Valkey o Redis OSS utilizzando.AWS CLI Durante questo processo, il cluster continuerà a soddisfare le richieste con tempi di inattività minimi.
**Per ridimensionare un cluster Valkey o Redis OSS ()AWS CLI**
1. Determina i tipi di nodi a cui puoi ridimensionare eseguendo il AWS CLI`list-allowed-node-type-modifications` comando con il seguente parametro.
Per Linux, macOS o Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Per Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
L'output del comando in alto è simile al seguente (in formato JSON).
```
{
"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"
]
}
```
Per ulteriori informazioni, consulta [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) nella *documentazione di riferimento AWS CLI*.
1. Modifica il gruppo di replica per ridurlo al nuovo tipo di nodo più piccolo, utilizzando il AWS CLI`modify-replication-group` comando e i seguenti parametri.
+ `--replication-group-id` : Il nome del gruppo di replica oggetto della riduzione verticale verso il basso.
+ `--cache-node-type`— Il nuovo tipo di nodo con cui ridimensionare il cluster. Questo valore deve essere uno dei tipi di nodi restituiti dal comando `list-allowed-node-type-modifications` nella fase 1.
+ `--cache-parameter-group-name` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `--apply-immediately` : Consente di applicare immediatamente il dimensionamento verso l'alto. Per posporre il processo di dimensionamento verso il basso alla finestra di manutenzione successiva del cluster, utilizzare il parametro `--no-apply-immediately`.
Per Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.t2.micro \
--apply-immediately
```
Per Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.t2.micro ^
--apply-immediately
```
L'output del comando in alto è simile al seguente (in formato JSON).
```
{
"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": {}
}
}
```
Per ulteriori informazioni, consulta [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) nella *documentazione di riferimento AWS CLI*.
1. Se hai usato il`--apply-immediately`, controlla lo stato del cluster usando il AWS CLI`describe-cache-clusters` comando con il seguente parametro. Quando lo stato diventa *disponibile*, puoi iniziare a utilizzare il nuovo nodo cluster più piccolo.
### Ridimensionamento dei cluster Valkey o Redis OSS (API) ElastiCache
Il seguente processo ridimensiona il gruppo di replica dal tipo di nodo corrente a un nuovo tipo di nodo più piccolo utilizzando l'API. ElastiCache Durante questo processo, il cluster Valkey o Redis OSS continuerà a soddisfare le richieste con tempi di inattività minimi.
Il tempo necessario per la scalabilità a un tipo di nodo più piccolo varia a seconda del tipo di nodo e della quantità di dati nel cluster corrente.
**Scalabilità verso il basso (ElastiCache API)**
1. Determina a quali tipi di nodi puoi ridimensionare utilizzando l'`ListAllowedNodeTypeModifications`azione ElastiCache API con il seguente parametro.
+ `ReplicationGroupId` : il nome del gruppo di replica. Utilizzare questo parametro per descrivere un gruppo di replica specifico piuttosto che tutti i gruppi di replica.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Per ulteriori informazioni, [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) consulta *Amazon ElastiCache API Reference*.
1. Ridimensiona il tuo attuale gruppo di replica fino al nuovo tipo di nodo utilizzando l'azione `ModifyReplicationGroup` ElastiCache API e con i seguenti parametri.
+ `ReplicationGroupId` = il nome del gruppo di replica.
+ `CacheNodeType`— il nuovo tipo di nodo più piccolo dei cluster in questo gruppo di replica. Questo valore deve essere uno dei tipi di istanza restituiti dall'`ListAllowedNodeTypeModifications`azione nel passaggio precedente.
+ `CacheParameterGroupName` – [Facoltativo] Utilizzare questo parametro se si usa `reserved-memory` per gestire la memoria prenotata del cluster. Specificare un gruppo di parametri di cache personalizzato che riserva la quantità di memoria corretta per il nuovo tipo di nodo. Se si sta utilizzando `reserved-memory-percent` è possibile omettere questo parametro.
+ `ApplyImmediately` : Impostato su `true` permette di applicare immediatamente il processo di riduzione verticale. Per posporre il processo di dimensionamento verso il basso alla successiva finestra di manutenzione, utilizzare `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=
```
Per ulteriori informazioni, [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) consulta *Amazon ElastiCache API Reference*.
# Guida introduttiva ai filtri Bloom
ElastiCache supporta la struttura dati del filtro Bloom, che fornisce una struttura dati probabilistica efficiente in termini di spazio per verificare se un elemento fa parte di un set. Quando si utilizzano i filtri Bloom, sono possibili falsi positivi: un filtro può indicare erroneamente l'esistenza di un elemento, anche se quell'elemento non è stato aggiunto al set. Tuttavia, l'utilizzo dei filtri Bloom eviterà i falsi *negativi*, ossia indicazioni errate che un elemento *non* esiste, anche se quell'elemento è stato aggiunto al set.
Puoi impostare la percentuale di potenziali falsi positivi su una frequenza preferita per il tuo carico di lavoro, regolando la frequenza fp. Puoi anche configurare la capacità (il numero di elementi che un filtro Bloom può contenere), le proprietà di ridimensionamento e non ridimensionamento e altro ancora.
Dopo aver creato un cluster con una versione del motore supportata, il tipo di dati Bloom e i comandi associati sono automaticamente disponibili. Il tipo di `bloom` dati è compatibile tramite API con la sintassi dei comandi di filtro Bloom delle librerie client ufficiali di Valkey`valkey-py`, tra cui`valkey-java`, e. `valkey-go` È possibile migrare facilmente le applicazioni Valkey e Redis OSS esistenti basate su Bloom in. ElastiCache Per un elenco completo dei comandi, vedere. [Comandi del filtro Bloom](#SupportedCommandsBloom)
Le metriche relative a Bloom `BloomFilterBasedCmds``BloomFilterBasedCmdsLatency`, e `BloomFilterBasedCmdsECPUs` sono incorporate CloudWatch per monitorare l'utilizzo di questo tipo di dati. Per ulteriori informazioni, consulta [Metriche per Valkey e Redis OSS](CacheMetrics.Redis.md).
**Nota**
Per utilizzare i filtri Bloom, è necessario utilizzare ElastiCache Valkey 8.1 e versioni successive.
Il tipo di dati bloom non è compatibile con RDB con altre offerte bloom non basate su Valkey.
## Panoramica dei tipi di dati dei filtri Bloom
I filtri Bloom sono una struttura di dati probabilistica efficiente in termini di spazio che consente di aggiungere elementi e verificare se esistono elementi. I falsi positivi sono possibili quando un filtro indica erroneamente l'esistenza di un elemento, anche se non è stato aggiunto. Tuttavia, i filtri Bloom garantiscono che non si verifichino falsi negativi (che indicano erroneamente che un elemento non esiste, anche se è stato aggiunto).
La principale fonte di documentazione per i filtri Bloom è disponibile nella pagina della documentazione di valkey.io. Contiene le seguenti informazioni:
+ [Casi d'uso comuni per i filtri Bloom](https://valkey.io/topics/bloomfilters/#common-use-cases-for-bloom-filters)
+ Deduplicazione di pubblicità/eventi
+ Rilevamento di attività fraudolente
+ Filtraggio di contenuti nocivi/spam
+ Rilevamento unico degli utenti
+ [Differenze tra filtri di fioritura scalabili e non scalabili](https://valkey.io/topics/bloomfilters/#scaling-and-non-scaling-bloom-filters)
+ Come decidere tra filtri di fioritura scalabili e non ridimensionanti
+ [Proprietà della fioritura](https://valkey.io/topics/bloomfilters/#bloom-properties)
+ Scopri le proprietà regolabili dei filtri Bloom. Ciò include la frequenza dei falsi positivi, la capacità, le proprietà di scalabilità e non scalabilità e altro ancora.
+ [Prestazioni dei comandi bloom](https://valkey.io/topics/bloomfilters/#performance)
+ [Monitoraggio delle statistiche generali del filtro Bloom](https://valkey.io/topics/bloomfilters/#monitoring)
+ [Gestione di filtri di fioritura di grandi dimensioni](https://valkey.io/topics/bloomfilters/#handling-large-bloom-filters)
+ Consigli e dettagli su come verificare se un filtro Bloom sta raggiungendo il limite di utilizzo della memoria e se è scalabile per raggiungere la capacità desiderata.
+ È possibile controllare in modo specifico la quantità di memoria consumata da un documento con filtro bloom utilizzando il comando [BF.INFO](https://valkey.io/commands/bf.info/).
## Limite di dimensione del fiore
Il consumo di memoria da parte di un singolo oggetto filtro Bloom è limitato a 128 MB. È possibile controllare la quantità di memoria consumata da un filtro Bloom utilizzando il `BF.INFO SIZE` comando.
## Bloom ACLs
Analogamente alle categorie esistenti per tipo di dati (@string, @hash, ecc.), viene aggiunta una nuova categoria @bloom per semplificare la gestione dell'accesso ai comandi e ai dati di Bloom. Nessun altro comando Valkey o Redis OSS esistente è membro della categoria @bloom.
Esistono 3 categorie ACL esistenti che vengono aggiornate per includere i nuovi comandi Bloom: @read, @write e @fast. La tabella seguente indica la mappatura dei comandi Bloom alle categorie appropriate.
| Comando Bloom | @read | @write | @fast | @bloom |
| --- | --- | --- | --- | --- |
| BF.ADD | | y | y | y |
| BF.CARD | y | | y | y |
| BF.ESISTE | y | | y | y |
| BF.INFO | y | | y | y |
| BF.INSERT | | y | y | y |
| BF.MADD | | y | y | y |
| BF.MEXIST | y | | y | y |
| BF.RESERVE | y | | y | y |
## Metriche relative al filtro Bloom
Vengono fornite le seguenti CloudWatch metriche relative alle strutture di dati Bloom:
| Metriche CW | Unità | Senza server/basato su nodi | Description |
| --- | --- | --- | --- |
| BloomFilterBasedCmds | Conteggio | Entrambi | Il numero totale di comandi del filtro Bloom, inclusi i comandi di lettura e scrittura. |
| BloomFilterBasedCmdsLatency | Microsecondi | Autogestito | Latenza di tutti i comandi del filtro Bloom, inclusi i comandi di lettura e scrittura. |
| BloomFilterBasedCmdsECPUs | Conteggio | Serverless | ECPUs utilizzata da tutti i comandi del filtro Bloom, inclusi i comandi di lettura e scrittura. |
## Comandi del filtro Bloom
[I comandi Bloom Filter](https://valkey.io/commands/#bloom) sono documentati sul sito [Valkey.io](https://valkey.io/). Ogni pagina di comando fornisce una panoramica completa dei comandi bloom, inclusi la sintassi, il comportamento, i valori restituiti e le potenziali condizioni di errore.
| Nome | Description |
| --- | --- |
| [BF.ADD](https://valkey.io/commands/bf.add/) | Aggiunge un singolo elemento a un filtro Bloom. Se il filtro non esiste già, viene creato. |
| [BF.CARD](https://valkey.io/commands/bf.card/) | Restituisce la cardinalità di un filtro Bloom. |
| [BF.EXISTS](https://valkey.io/commands/bf.exists/) | Determina se il filtro bloom contiene l'elemento specificato. |
| [BF.INFO](https://valkey.io/commands/bf.info/) | Restituisce le informazioni sull'utilizzo e le proprietà di uno specifico filtro Bloom. |
| [BF.INSERT](https://valkey.io/commands/bf.insert/) | Crea un filtro di fioritura con 0 o più elementi o aggiunge elementi a un filtro di fioritura esistente. |
| [BF.MADD](https://valkey.io/commands/bf.madd/) | Aggiunge uno o più elementi a un filtro di fioritura. |
| [BF.M. ESISTE](https://valkey.io/commands/bf.mexists/) | Determina se il filtro bloom contiene 1 o più elementi. |
| [BF.RESERVE](https://valkey.io/commands/bf.reserve/) | Crea un filtro bloom vuoto con le proprietà specificate. |
**Nota**
**BF.LOAD** non è supportato da. ElastiCache È rilevante solo per l'utilizzo di AOF, che ElastiCache non supporta.
# Guida introduttiva a Watch in Serverless
ElastiCache [supporta il `WATCH` comando, che consente di monitorare le modifiche delle chiavi ed eseguire transazioni condizionali.](https://valkey.io/topics/transactions/) Il `WATCH` comando è particolarmente utile per le applicazioni che richiedono un controllo ottimistico della concorrenza, garantendo che le transazioni vengano eseguite solo se le chiavi monitorate non sono state modificate. Ciò include le modifiche apportate da un client, come i comandi di scrittura, e dalla stessa Valkey, come la scadenza o lo sfratto. Se le chiavi sono state modificate dal momento in cui sono state impostate `WATCH` e al momento `EXEC` della ricezione, l'intera transazione verrà interrotta.
Per ElastiCache Serverless, vengono introdotti i seguenti vincoli:
ElastiCache Serverless `WATCH` è limitato a un singolo slot hash. Ciò significa che solo le chiavi mappate allo stesso slot hash possono essere controllate contemporaneamente dalla stessa connessione e la transazione che segue i comandi di watch può funzionare solo sullo stesso slot hash. Quando un'applicazione tenta di controllare le chiavi di slot hash diversi o di eseguire comandi di transazione che operano su chiavi mappate su uno slot hash diverso da quello delle chiavi controllate, viene restituito un errore. `CROSSSLOT` I [tag hash](https://valkey.io/topics/cluster-spec/#hash-tags) possono essere utilizzati per garantire che più chiavi siano mappate sullo stesso slot hash.
Inoltre, `SCAN` il comando non può essere eseguito all'interno di una connessione con chiavi controllate e restituirà un errore. `command not supported during watch state`
La transazione verrà interrotta (come se le chiavi controllate venissero toccate) quando ElastiCache Serverless non ha la certezza che una chiave sia stata modificata. Ad esempio, quando uno slot è stato migrato e le chiavi controllate non possono essere trovate sullo stesso nodo.
**Codici di esempio**
## Guarda e opera su tasti di slot diversi
Nell'esempio seguente, la chiave controllata e la chiave specificata nel `SET` comando vengono mappate su diversi slot hash. L'esecuzione restituisce un`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
```
## Guarda e opera sui tasti dello stesso slot
L'esempio seguente mostra una transazione riuscita, poiché la chiave impostata `WATCH` non è stata modificata.
```
> WATCH foo:{005119}
OK
> MULTI
OK
> SET bar:{005119} 1234
QUEUED
> EXEC
1) OK
```
## Guarda le chiavi di Different Slots
Nell'esempio seguente, un tentativo di inserire `WATCH` chiavi da slot diversi contemporaneamente all'interno della stessa connessione client restituisce a`CROSSSLOT ERROR`.
```
> WATCH foo:{005119}
OK
> WATCH bar:{123455}
CROSSSLOT Keys in request don't hash to the same slot
```
## Limite di visualizzazione
Ogni connessione client può controllare fino a 1000 chiavi contemporaneamente.
## Comandi supportati relativi a Watch
I comandi [WATCH](https://valkey.io/commands/watch/) [e UNWATCH](https://valkey.io/commands/unwatch/) sono documentati sul sito [Valkey.io](https://valkey.io/). Fornisce una panoramica completa dei comandi, inclusa la sintassi, il comportamento, i valori restituiti e le potenziali condizioni di errore.
# Guida introduttiva alla ricerca vettoriale
Amazon ElastiCache for Valkey supporta la ricerca vettoriale, che consente di archiviare, cercare e aggiornare miliardi di incorporamenti vettoriali ad alta dimensione in memoria con latenze di appena microsecondi e richiami superiori al 99%. ElastiCache for Valkey offre funzionalità per indicizzare, cercare e aggiornare miliardi di incorporamenti vettoriali ad alta dimensione di provider famosi come Amazon Bedrock, Amazon, SageMaker Anthropic o OpenAI per una ricerca e un recupero rapidi. La ricerca vettoriale per Amazon ElastiCache è ideale per i casi d'uso in cui le massime prestazioni e la scalabilità sono i criteri di selezione più importanti. Ciò include la memorizzazione nella cache semantica, la generazione aumentata di recupero, i consigli in tempo reale, la personalizzazione e il rilevamento delle anomalie.
La ricerca vettoriale può essere utilizzata insieme ad altre funzionalità per migliorare le applicazioni. ElastiCache ElastiCache [La ricerca vettoriale di è disponibile nella versione 8.2 di Valkey su cluster basati su nodi in tutte le regioni senza costi aggiuntivi.AWS](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) Per iniziare, crea un nuovo cluster Valkey 8.2 utilizzando, SDK o. [Console di gestione AWS](https://console.aws.amazon.com/elasticache/)AWSAWS CLI[Puoi anche utilizzare la ricerca vettoriale sul tuo cluster esistente eseguendo l'aggiornamento da qualsiasi versione precedente di Valkey o Redis OSS a Valkey 8.2 con pochi clic e senza tempi di inattività.](VersionManagement.HowTo.md)
# Panoramica della ricerca vettoriale
ElastiCache for Valkey offre funzionalità per indicizzare, cercare e aggiornare miliardi di incorporamenti vettoriali ad alta dimensione. La ricerca vettoriale consente di creare, gestire e utilizzare indici secondari per una ricerca efficiente e scalabile. Ogni operazione di ricerca vettoriale si applica a un singolo indice. Le operazioni sull'indice si applicano solo all'indice specificato. È possibile eseguire un numero qualsiasi di operazioni su qualsiasi indice in qualsiasi momento, ad eccezione delle operazioni di creazione ed eliminazione dell'indice. A livello di cluster, possono essere in corso più operazioni su più indici contemporaneamente.
All'interno di questo documento i termini chiave, riga e record sono identici e utilizzati in modo intercambiabile. Allo stesso modo, anche i termini colonna, campo, percorso e membro vengono usati in modo intercambiabile.
Il `FT.CREATE` comando può essere utilizzato per creare un indice per un sottoinsieme di chiavi con i tipi di indice specificati. `FT.SEARCH`esegue interrogazioni sugli indici creati e `FT.DROPINDEX` rimuove un indice esistente e tutti i dati associati. Non esistono comandi speciali per aggiungere, eliminare o modificare i dati indicizzati. I `JSON` comandi esistenti `HASH` o che modificano una chiave presente in un indice aggiornano automaticamente l'indice.
**Topics**
+ [Indici e keyspace Valkey OSS](#indexes-keyspace)
+ [Tipi di campi indice](#index-field-types)
+ [Algoritmi di indice vettoriale](#vector-index-algorithms)
+ [Sicurezza della ricerca vettoriale](#vector-search-security)
## Indici e keyspace Valkey OSS
Gli indici sono costruiti e gestiti su un sottoinsieme dello spazio delle chiavi Valkey OSS. Lo spazio chiave per ogni indice è definito da un elenco di prefissi chiave forniti al momento della creazione dell'indice. L'elenco dei prefissi è facoltativo e, se omesso, l'intero spazio delle chiavi farà parte di quell'indice. Più indici possono scegliere sottoinsiemi disgiunti o sovrapposti dello spazio chiave senza limitazioni.
Gli indici vengono inoltre digitati in quanto coprono solo le chiavi di tipo corrispondente. Attualmente, gli indici sono supportati solo sui tipi e. `JSON` `HASH` Un `HASH` indice indicizza solo le `HASH` chiavi incluse nel suo elenco di prefissi e analogamente un `JSON` indice indicizza solo le `JSON` chiavi che sono incluse nel suo elenco di prefissi. Le chiavi all'interno dell'elenco dei prefissi dello spazio dei tasti di un indice che non hanno il tipo designato vengono ignorate e non influiscono sulle operazioni di ricerca.
Un indice viene aggiornato quando un comando modifica una chiave che si trova all'interno dello spazio chiave dell'indice. Valkey estrae automaticamente i campi dichiarati per ogni indice e aggiorna l'indice con il nuovo valore. Il processo di aggiornamento prevede tre fasi. Nella prima fase, la chiave HASH o JSON viene modificata e il client richiedente viene bloccato. Il secondo passaggio viene eseguito in background e aggiorna ciascuno degli indici che contengono la chiave modificata. Nella terza fase, il client viene sbloccato. Pertanto, per le operazioni di interrogazione eseguite sulla stessa connessione di una mutazione, tale modifica è immediatamente visibile nei risultati della ricerca.
La creazione di un indice è un processo in più fasi. Il primo passo consiste nell'eseguire il comando FT.CREATE che definisce l'indice. L'esecuzione corretta di una creazione avvia automaticamente il secondo passaggio: il backfilling. Il processo di riempimento viene eseguito in un thread in background e analizza lo spazio chiave alla ricerca di chiavi che si trovano all'interno dell'elenco di prefissi del nuovo indice. Ogni chiave trovata viene aggiunta all'indice. Alla fine viene scansionato l'intero keyspace, completando il processo di creazione dell'indice. Nota che mentre il processo di riempimento dell'indice è in esecuzione, le mutazioni delle chiavi indicizzate sono consentite, non ci sono restrizioni e il processo di riempimento dell'indice non verrà completato finché tutte le chiavi non saranno indicizzate correttamente. Le operazioni di interrogazione tentate mentre un indice è in fase di riempimento non sono consentite e vengono terminate con un errore. Il comando FT.INFO restituisce lo stato del processo di backfill nel campo 'backfill\$1status'.
## Tipi di campi indice
Ogni indice ha un tipo specifico che viene dichiarato al momento della creazione dell'indice insieme alla posizione di un campo (colonna) da indicizzare. Per `HASH` le chiavi, la posizione è il nome del campo all'interno di. `HASH` Per `JSON` le chiavi, la posizione è una descrizione del percorso JSON. Quando una chiave viene modificata, i dati associati ai campi dichiarati vengono estratti, convertiti nel tipo dichiarato e memorizzati nell'indice. Se i dati mancano o non possono essere convertiti correttamente nel tipo dichiarato, quel campo viene omesso dall'indice. Esistono tre tipi di campi, come spiegato di seguito:
+ **I campi vettoriali** contengono un vettore di numeri noto anche come incorporamento vettoriale. I campi vettoriali possono essere utilizzati per filtrare i vettori in base a metriche di distanza specifiche che misurano la somiglianza. Per gli `HASH` indici, il campo deve contenere l'intero vettore codificato in formato binario (Little-endian IEEE 754). Per `JSON` le chiavi, il percorso deve fare riferimento a un array della dimensione corretta pieno di numeri. Nota che quando un array JSON viene utilizzato come campo vettoriale, la rappresentazione interna dell'array all'interno della chiave JSON viene convertita nel formato richiesto dall'algoritmo selezionato, riducendo il consumo di memoria e la precisione. Le successive operazioni di lettura che utilizzano i comandi JSON produrranno un valore di precisione ridotto.
+ **I campi numerici** contengono un solo numero. I campi numerici possono essere utilizzati con l'operatore di ricerca per intervalli. Infatti`HASH`, si prevede che il campo contenga il testo ASCII di un numero scritto nel formato standard di numeri a virgola fissa o mobile. Per `JSON` i campi, è necessario seguire le regole numeriche dei numeri JSON. Indipendentemente dalla rappresentazione all'interno della chiave, questo campo viene convertito in un numero a virgola mobile a 64 bit per la memorizzazione all'interno dell'indice. Poiché i numeri sottostanti sono memorizzati in virgola mobile con i relativi limiti di precisione, si applicano le consuete regole sui confronti numerici per i numeri in virgola mobile.
+ **I campi tag** contengono zero o più valori di tag codificati come una singola stringa UTF-8. I campi tag possono essere utilizzati per filtrare le query in base all'equivalenza dei valori dei tag con un confronto con o senza distinzione tra maiuscole e minuscole. La stringa viene analizzata in valori di tag utilizzando un carattere separatore (l'impostazione predefinita è una virgola ma può essere sovrascritta) con gli spazi bianchi iniziali e finali rimossi. Qualsiasi numero di valori di tag può essere contenuto in un singolo campo di tag.
## Algoritmi di indice vettoriale
In Valkey sono supportati due algoritmi di indice vettoriale:
+ **Flat** — L'algoritmo Flat è un'elaborazione lineare a forza bruta di ogni vettore dell'indice, che fornisce risposte esatte entro i limiti della precisione dei calcoli della distanza. Grazie all'elaborazione lineare dell'indice, i tempi di esecuzione di questo algoritmo possono essere molto elevati per indici di grandi dimensioni. Gli indici piatti supportano velocità di ingestione più elevate.
+ **Hierarchical Navigable Small Worlds (HNSW): l'algoritmo HNSW** è un'alternativa che fornisce corrispondenze vettoriali approssimative più vicine in cambio di tempi di esecuzione sostanzialmente inferiori. L'algoritmo è controllato da tre parametri e. `M` `EF_CONSTRUCTION` `EF_RUNTIME` I primi due parametri vengono specificati al momento della creazione dell'indice e non possono essere modificati. Il `EF_RUNTIME` parametro ha un valore predefinito che viene specificato al momento della creazione dell'indice, ma può essere sovrascritto in ogni singola operazione di interrogazione in seguito. Questi tre parametri interagiscono per bilanciare il consumo di memoria e CPU durante le operazioni di inserimento e interrogazione, nonché per controllare la qualità dell'approssimazione di una ricerca KNN esatta (nota come rapporto di richiamo).
In HNSW, il parametro M controlla il numero massimo di vicini a cui ogni nodo può connettersi, determinando la densità dell'indice. Un valore M più alto, ad esempio 32 e superiore, produce un grafo più connesso, migliorando la velocità di richiamo e di interrogazione perché esistono più percorsi per raggiungere i vicini pertinenti. Tuttavia, aumenta la dimensione dell'indice, l'uso della memoria e rallenta l'indicizzazione. Un valore M inferiore, ad esempio 8 e inferiore, produce un faster-to-build indice più piccolo con un minore utilizzo della memoria, ma il richiamo diminuisce e le query possono richiedere più tempo a causa del minor numero di connessioni.
Il parametro EF\$1Construction determina quante connessioni candidate vengono valutate durante la creazione dell'indice. Un EF\$1Construction più elevato, ad esempio 400 e versioni successive, significa che l'indicizzatore considera più percorsi prima di selezionare i vicini, ottenendo un grafico che migliora l'efficienza del richiamo e delle query in un secondo momento, ma a scapito di una indicizzazione più lenta e di un maggiore utilizzo di CPU e memoria durante la costruzione. Un valore EF\$1Construction basso, ad esempio 64-120, accelera l'indicizzazione e riduce l'uso delle risorse, ma il grafico risultante può ridurre il richiamo e rallentare le query anche se EF\$1Runtime è impostato su un valore elevato.
Infine, EF\$1Runtime regola l'ampiezza della ricerca durante l'interrogazione, controllando quanti candidati adiacenti vengono esplorati in fase di esecuzione. Impostarlo su un valore elevato aumenta il richiamo e la precisione, ma a scapito della latenza delle query e dell'uso della CPU. Un EF\$1Runtime basso rende le query più veloci e leggere, ma con un richiamo ridotto. A differenza di M o EF\$1Construction, questo parametro non influisce sulla dimensione dell'indice o sul tempo di compilazione, quindi è il parametro che consente di regolare i compromessi tra richiamo e latenza dopo la creazione di un indice.
Entrambi gli algoritmi di ricerca vettoriale (Flat e HNSW) supportano un parametro opzionale. `INITIAL_CAP` Quando specificato, questo parametro prealloca la memoria per gli indici, con conseguente riduzione del sovraccarico di gestione della memoria e aumento delle velocità di ingestione vettoriale. Gli indici flat supportano velocità di ingestione migliori rispetto a HNSW.
Gli algoritmi di ricerca vettoriale come HNSW potrebbero non gestire in modo efficiente l'eliminazione o la sovrascrittura dei vettori precedentemente inseriti. L'uso di queste operazioni può comportare un consumo eccessivo di memoria indicizzata, un deterioramento della qualità di richiamo. and/or La reindicizzazione è un metodo per ripristinare il recupero ottimale dell'utilizzo della memoria. and/or
## Sicurezza della ricerca vettoriale
I meccanismi di sicurezza [Valkey ACL (Access Control Lists)](https://valkey.io/topics/acl/) per l'accesso ai comandi e ai dati sono estesi per controllare la funzione di ricerca. Il controllo ACL dei singoli comandi di ricerca è completamente supportato. Viene fornita una nuova categoria ACL e molte delle categorie esistenti (`@fast`, `@read``@write`, ecc.) vengono aggiornate per includere i nuovi comandi. `@search` I comandi di ricerca non modificano i dati chiave, il che significa che il meccanismo ACL esistente per l'accesso in scrittura viene preservato. Le regole di accesso `HASH` e le `JSON` operazioni non vengono modificate dalla presenza di un indice; il normale controllo dell'accesso a livello di chiave viene ancora applicato a tali comandi.
L'accesso ai comandi di ricerca con un indice è inoltre controllato tramite ACL. I controlli di accesso vengono eseguiti a livello dell'intero indice, non a livello di chiave. Ciò significa che l'accesso a un indice viene concesso a un utente solo se tale utente è autorizzato ad accedere a tutte le chiavi possibili all'interno dell'elenco dei prefissi dello spazio chiave di quell'indice. In altre parole, il contenuto effettivo di un indice non controlla l'accesso. Piuttosto, sono i contenuti teorici di un indice, come definito dall'elenco dei prefissi, che viene utilizzato per il controllo di sicurezza. Sono possibili situazioni in cui un utente ha accesso in lettura e and/or scrittura a una chiave ma non è in grado di accedere a un indice contenente quella chiave. Tieni presente che per creare o utilizzare un indice è necessario solo l'accesso in lettura allo spazio delle chiavi: la presenza o l'assenza di accesso in scrittura non viene considerata
# Caratteristiche e limiti della ricerca vettoriale
## Disponibilità della ricerca vettoriale
La ricerca vettoriale per Amazon ElastiCache è disponibile con Valkey versione 8.2 su cluster basati su nodi in tutte le AWS regioni senza costi aggiuntivi. [Puoi anche utilizzare la ricerca vettoriale sui cluster esistenti eseguendo l'aggiornamento da qualsiasi versione di Valkey o Redis OSS a Valkey 8.2, in pochi clic e senza tempi di inattività.](VersionManagement.HowTo.md)
La ricerca vettoriale è attualmente disponibile su tutti i tipi di istanze diversi dai nodi con suddivisione in più livelli dei dati. ElastiCache L'utilizzo della ricerca vettoriale su istanze t2, t3 e t4g richiede l'aumento della riserva di memoria ad almeno il 50% per le istanze micro e al 30% per le istanze di piccole dimensioni. Consulta [questa](redis-memory-management.md) pagina per saperne di più.
## Restrizioni parametriche
La tabella seguente mostra i limiti per vari elementi di ricerca vettoriale:
**Limiti di ricerca vettoriale**
| Elemento | Valore massimo |
| --- | --- |
| Numero di dimensioni in un vettore | 32768 |
| Numero di indici che possono essere creati | 10 |
| Numero di campi in un indice | 50 |
| Clausola FT.SEARCH TIMEOUT (millisecondi) | 60000 |
| Numero massimo di prefissi consentiti per indice | 16 |
| Lunghezza massima di un campo di tag | 10000 |
| Lunghezza massima di un campo numerico | 256 |
| Parametro HNSW M | 2000000 |
| Parametro HNSW EF\$1CONSTRUCTION | 4096 |
| Parametro HNSW EF\$1RUNTIME | 4096 |
## Restrizioni operative
### Persistenza e riempimento dell'indice
Il processo di aggiornamento prevede tre fasi. Nella prima fase, la chiave HASH o JSON viene modificata e il client richiedente viene bloccato. Il secondo passaggio viene eseguito in background e aggiorna ciascuno degli indici che contengono la chiave modificata. Nella terza fase, il client viene sbloccato. Pertanto, per le operazioni di interrogazione eseguite sulla stessa connessione di una mutazione, tale modifica è immediatamente visibile nei risultati della ricerca. Tuttavia, l'inserimento o l'aggiornamento di una chiave potrebbe non essere visibile nei risultati di ricerca di altri client per un breve periodo di tempo. Durante i periodi di intenso carico di sistema ( and/or forte mutazione dei dati), il ritardo di visibilità può aumentare.
La funzione di ricerca vettoriale mantiene la definizione degli indici e il contenuto degli indici. Gli indici per i campi vettoriali vengono salvati ma gli indici per TAGS e NUMERIC non vengono salvati, il che significa che devono essere ricostruiti quando vengono caricati esternamente (sincronizzazione completa o ricarica). Ciò significa che durante qualsiasi richiesta o evento operativo che causa l'avvio o il riavvio di un nodo, la definizione dell'indice e il contenuto dei vettori vengono ripristinati dall'istantanea più recente. Non è richiesta alcuna azione da parte dell'utente per avviare questa operazione. Tuttavia, per gli indici TAGS e NUMERIC, la ricostruzione viene eseguita come operazione di riempimento non appena i dati vengono ripristinati. Dal punto di vista funzionale, ciò equivale all'esecuzione automatica da parte del sistema di un comando FT.CREATE per ogni indice definito. Si noti che il nodo diventa disponibile per le operazioni dell'applicazione non appena i dati vengono ripristinati, ma probabilmente prima del completamento del riempimento dell'indice, il che significa che le operazioni di riempimento saranno nuovamente visibili alle applicazioni.
Il completamento del riempimento dell'indice non è sincronizzato tra un primario e una replica. Questa mancanza di sincronizzazione può diventare inaspettatamente visibile alle applicazioni, pertanto è consigliabile che le applicazioni verifichino il completamento del backfill sulle repliche primarie e su tutte le repliche prima di iniziare le operazioni di ricerca.
### Limiti di scalabilità
Durante gli eventi di scalabilità, l'indice può essere sottoposto a riempimento man mano che i dati vengono migrati. Ciò comporterà una riduzione del richiamo per le query di ricerca.
### Istantanea import/export e migrazione in tempo reale
I file RDB di un cluster con indici di ricerca possono essere importati in un altro cluster ElastiCache Valkey con versione 8.2 o successiva. Il nuovo cluster ricostruirà il contenuto dell'indice durante il caricamento del file RDB. Tuttavia, la presenza di indici di ricerca in un file RDB limita la compatibilità di tali dati con le versioni precedenti di Valkey. Il formato degli indici di ricerca definiti dalla funzionalità di ricerca vettoriale è compreso solo da un altro ElastiCache cluster con Valkey versione 8.2 o successiva. Tuttavia, i file RDB che non contengono indici non sono soggetti a restrizioni in questo modo.
### Memoria insufficiente durante il riempimento
Analogamente alle operazioni di scrittura di Valkey OSS, un riempimento dell'indice è soggetto a limitazioni. out-of-memory Se la memoria del motore è piena mentre è in corso un riempimento, tutti i backfill vengono messi in pausa. Se la memoria diventa disponibile, il processo di riempimento viene ripreso. È possibile eliminare un indice quando il riempimento è in pausa a causa dell'esaurimento della memoria.
### Transazioni
I comandi`FT.CREATE`,, `FT.DROPINDEX` `FT.ALIASADD``FT.ALIASDEL`, e `FT.ALIASUPDATE` non possono essere eseguiti in un contesto transazionale, cioè non all'interno di un `MULTI/EXEC` blocco o all'interno di uno script LUA o FUNCTION.
# Scelta della configurazione appropriata
Nell'esperienza della console, ElastiCache offre un modo semplice per scegliere il tipo di istanza giusto in base ai requisiti di memoria e CPU del carico di lavoro vettoriale.
## Consumo di memoria
Il consumo di memoria si basa sul numero di vettori, sul numero di dimensioni, sul valore M e sulla quantità di dati non vettoriali, come i metadati associati al vettore o altri dati memorizzati all'interno dell'istanza. La memoria totale richiesta è una combinazione dello spazio necessario per i dati vettoriali effettivi e dello spazio richiesto per gli indici vettoriali. Lo spazio richiesto per i dati vettoriali viene calcolato misurando la capacità effettiva richiesta per archiviare i vettori all'interno `HASH` delle nostre strutture di `JSON` dati e il sovraccarico nelle lastre di memoria più vicine, per allocazioni di memoria ottimali. Ciascuno degli indici vettoriali utilizza riferimenti ai dati vettoriali memorizzati in queste strutture di dati, nonché una copia aggiuntiva del vettore nell'indice. Si consiglia di pianificare questo consumo di spazio aggiuntivo da parte dell'indice.
Il numero di vettori dipende da come decidi di rappresentare i dati come vettori. Ad esempio, puoi scegliere di rappresentare un singolo documento in più blocchi, in cui ogni blocco rappresenta un vettore. In alternativa, puoi scegliere di rappresentare l'intero documento come un unico vettore. Il numero di dimensioni dei vettori dipende dal modello di incorporamento scelto. Ad esempio, se scegli di utilizzare il modello di incorporamento AWS Titan, il numero di dimensioni sarebbe 1536. Tieni presente che dovresti testare il tipo di istanza per assicurarti che soddisfi i tuoi requisiti.
## Ridimensionamento del carico di lavoro
La ricerca vettoriale supporta tutti e tre i metodi di ridimensionamento: orizzontale, verticale e repliche. Quando si ridimensiona in base alla capacità, la ricerca vettoriale si comporta proprio come un normale Valkey, ovvero aumentando la memoria dei singoli nodi (ridimensionamento verticale) o aumentando il numero di nodi (ridimensionamento orizzontale) si aumenterà la capacità complessiva. In modalità cluster, il `FT.CREATE` comando può essere inviato a qualsiasi nodo primario del cluster e il sistema distribuirà automaticamente la nuova definizione dell'indice a tutti i membri del cluster.
Tuttavia, dal punto di vista delle prestazioni, la ricerca vettoriale si comporta in modo molto diverso dal normale Valkey. L'implementazione multithread della ricerca vettoriale significa un CPUs rendimento aggiuntivo fino ad aumenti lineari del throughput di query e ingestione. Il ridimensionamento orizzontale produce aumenti lineari della velocità di inserimento, ma può ridurre la velocità di trasmissione delle query. Se è richiesta una velocità di trasmissione delle query aggiuntiva, è necessaria la scalabilità tramite repliche o una maggiore velocità di trasmissione. CPUs
# Comandi di ricerca vettoriale
Di seguito è riportato un elenco di comandi supportati per la ricerca vettoriale.
**Topics**
+ [FT.CREATE](vector-search-commands-ft.create.md)
+ [FT.SEARCH](vector-search-commands-ft.search.md)
+ [INDICE FT.DROP](vector-search-commands-ft.dropindex.md)
+ [FT.INFO](vector-search-commands-ft.info.md)
+ [PIEDI. \$1LISTA](vector-search-commands-ft.list.md)
# FT.CREATE
Il `FT.CREATE` comando crea un indice vuoto e avvia il processo di riempimento. Ogni indice è composto da una serie di definizioni di campo. Ogni definizione di campo specifica un nome di campo, un tipo di campo e un percorso all'interno di ciascuna chiave indicizzata per individuare un valore del tipo dichiarato. Alcune definizioni dei tipi di campo hanno identificatori di sottotipo aggiuntivi.
Per gli indici sulle chiavi HASH, il percorso è lo stesso del nome del membro hash. La `AS` clausola opzionale può essere utilizzata per rinominare il campo, se lo si desidera. La ridenominazione dei campi è particolarmente utile quando il nome del membro contiene caratteri speciali.
Per gli indici su chiavi JSON, il percorso è un percorso JSON per i dati del tipo dichiarato. Poiché il percorso JSON contiene sempre caratteri speciali, la clausola è obbligatoria. `AS`
**Sintassi**
```
FT.CREATE
ON HASH | JSON
[PREFIX [...]]
SCHEMA
( [AS ]
| VECTOR [HNSW|FLAT] [])
| TAG [SEPARATOR ] [CASESENSITIVE]
| NUMERIC
)+
```
**(obbligatorio):** Questo è il nome che dai al tuo indice. Se esiste già un indice con lo stesso nome, viene restituito un errore.
**ON HASH \$1 JSON (opzionale):** in questo indice sono incluse solo le chiavi che corrispondono al tipo specificato. Se omesso, viene utilizzato HASH.
**PREFIX (opzionale):** se viene specificata questa clausola, in questo indice verranno incluse solo le chiavi che iniziano con gli stessi byte di uno o più prefissi specificati. Se questa clausola viene omessa, verranno incluse tutte le chiavi del tipo corretto. Un prefisso di lunghezza zero corrisponderebbe anche a tutte le chiavi del tipo corretto.
**Tipi di campo:**
+ TAG: un campo tag è una stringa che contiene uno o più valori di tag.
+ SEPARATORE (opzionale): uno dei caratteri `,.<>{}[]"':;!@#$%^&*()-+=~` utilizzati per delimitare i singoli tag. Se omesso, il valore predefinito è. `,`
+ CASESENSITIVE (opzionale): se presente, i confronti tra tag faranno distinzione tra maiuscole e minuscole. L'impostazione predefinita è che i confronti tra tag NON fanno distinzione tra maiuscole e minuscole.
+ NUMERICO: Un campo numerico contiene un numero.
+ VETTORE: Un campo vettoriale contiene un vettore. Attualmente sono supportati due algoritmi di indicizzazione vettoriale: HNSW (Hierarchical Navigable Small World) e FLAT (forza bruta). Ogni algoritmo ha una serie di attributi aggiuntivi, alcuni obbligatori e altri opzionali.
+ FLAT: L'algoritmo Flat fornisce risposte esatte, ma ha un'autonomia proporzionale al numero di vettori indicizzati e pertanto potrebbe non essere appropriato per set di dati di grandi dimensioni.
+ DIM (obbligatorio): specifica il numero di dimensioni in un vettore.
+ TIPO FLOAT32 (obbligatorio): tipo di dati, attualmente è supportato solo FLOAT32 .
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (obbligatorio): specifica l'algoritmo di distanza.
+ INITIAL\$1CAP (opzionale): dimensione iniziale dell'indice.
+ HNSW: l'algoritmo HNSW fornisce risposte approssimative, ma funziona molto più velocemente di FLAT.
+ DIM (obbligatorio): specifica il numero di dimensioni in un vettore.
+ TIPO FLOAT32 (obbligatorio): tipo di dati, attualmente è supportato solo FLOAT32 .
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (obbligatorio): specifica l'algoritmo di distanza.
+ INITIAL\$1CAP (opzionale): dimensione iniziale dell'indice.
+ M (opzionale): numero massimo di bordi in uscita consentiti per ogni nodo del grafico in ogni livello. Sul livello zero, il numero massimo di spigoli in uscita sarà 2\$1M. Il valore predefinito è 16, il massimo è 512.
+ EF\$1CONSTRUCTION (opzionale): controlla il numero di vettori esaminati durante la costruzione dell'indice. Valori più alti per questo parametro miglioreranno il rapporto di richiamo a scapito di tempi più lunghi di creazione dell'indice. Il valore predefinito è 200. Il valore massimo è 4096.
+ EF\$1RUNTIME (opzionale): controlla il numero di vettori da esaminare durante un'operazione di interrogazione. L'impostazione predefinita è 10 e il massimo è 4096. È possibile impostare questo valore di parametro per ogni query eseguita. Valori più alti aumentano i tempi di interrogazione, ma migliorano il richiamo delle query.
**RISPOSTA:** OK o errore.
# FT.SEARCH
Esegue una ricerca nell'indice specificato. Vengono restituite le chiavi che corrispondono all'espressione della query.
```
FT.SEARCH
[NOCONTENT]
[RETURN ( [AS ])+]
[TIMEOUT timeout]
[PARAMS []]
[LIMIT ]
```
+ (obbligatorio): Il nome dell'indice su cui si desidera eseguire la query.
+ (obbligatorio): La stringa di query, vedi sotto per i dettagli.
+ NOCONTENT (opzionale): quando presente, vengono restituiti solo i nomi delle chiavi risultanti, non vengono inclusi i valori chiave.
+ TIMEOUT (opzionale): consente di impostare un valore di timeout per il comando di ricerca. Deve essere un numero intero in millisecondi.
+ PARAMETRI... (opzionale): `count` indica il numero di argomenti, cioè il doppio del numero di coppie di nomi di valori. Vedi la stringa di query per i dettagli sull'utilizzo.
+ RITORNA ... (opzionale): count è il numero di campi da restituire. Specificate i campi che desiderate recuperare dai documenti, insieme agli eventuali alias per i valori restituiti. Per impostazione predefinita, vengono restituiti tutti i campi a meno che non sia impostata l'opzione NOCONTENT, nel qual caso non viene restituito alcun campo. Se count è impostato su 0, si comporta come NOCONTENT.
+ LIMIT: : Consente di scegliere una parte del risultato. Le prime chiavi vengono ignorate e viene incluso solo un massimo di chiavi. L'impostazione predefinita è LIMIT 0 10, che restituisce al massimo 10 chiavi.
+ PARAMS: due volte il numero di coppie chiave-valore. È possibile fare riferimento alle key/value coppie di parametri dall'interno dell'espressione di query. Per ulteriori informazioni, vedete Espressione di interrogazione di [ricerca vettoriale](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).
+ DIALETTO: (opzionale): specifica il dialetto. L'unico dialetto supportato è il 2.
**RISPOSTA**
Il comando restituisce un array in caso di successo o un errore.
In caso di successo, la prima voce nell'array di risposta rappresenta il conteggio delle chiavi corrispondenti, seguita da una voce dell'array per ogni chiave corrispondente. Nota che se l'`LIMIT`opzione viene specificata, controllerà solo il numero di chiavi restituite e non influirà sul valore della prima voce.
Quando `NOCONTENT` viene specificato, ogni voce nella risposta contiene solo il nome chiave corrispondente. Altrimenti, ogni voce include il nome chiave corrispondente, seguito da una matrice dei campi restituiti. I campi dei risultati per una chiave sono costituiti da un insieme di name/value coppie. La prima name/value coppia è per la distanza calcolata. Il nome di questa coppia è costruito a partire dal nome del campo vettoriale preceduto da «\$1\$1» e aggiunto da «\$1score» e il valore è la distanza calcolata. Le name/value coppie rimanenti sono i membri e i valori della chiave controllati dalla clausola. `RETURN`
La stringa di interrogazione è conforme alla seguente sintassi:
```
=>[ KNN @ $ ]
```
Dove:
+ : È un \$1 o un'espressione di filtro. Un \$1 indica l'assenza di filtri e pertanto la ricerca viene effettuata in tutti i vettori all'interno dell'indice. È possibile fornire un'espressione di filtro per designare un sottoinsieme dei vettori da cercare.
+ : il nome di un campo vettoriale all'interno dell'indice specificato.
+ : il numero di vettori vicini più prossimi da restituire.
+ : un nome PARAM il cui valore corrispondente fornisce il vettore di interrogazione per l'algoritmo KNN. Si noti che questo parametro deve essere codificato come virgola mobile binaria IEEE 754 a 32 bit in formato little-endian.
+ : (Facoltativo) Un elenco di coppie che modificano questa particolare ricerca KNN. keyword/value Attualmente sono supportate due parole chiave:
+ EF\$1RUNTIME: questa parola chiave è accompagnata da un valore intero che sostituisce il valore predefinito di EF\$1RUNTIME specificato al momento della creazione dell'indice.
+ AS: Questa parola chiave è accompagnata da un valore di stringa che diventa il nome del campo di punteggio nel risultato, sostituendo l'algoritmo di generazione dei nomi dei campi di punteggio predefinito.
**Espressione di filtro**
Un'espressione di filtro è costruita come una combinazione logica di operatori di ricerca numerici e tag contenuti tra parentesi.
**Tag**
L'operatore di ricerca per tag viene specificato con una o più stringhe separate dal carattere \$1. Una chiave soddisferà l'operatore di ricerca dei tag se il campo indicato contiene una delle stringhe specificate.
```
@:{}
or
@:{ | }
or
@:{ | | ...}
```
Ad esempio, la seguente query restituirà documenti di colore blu O nero O verde.
`@color:{blue | black | green}`
Come altro esempio, la seguente query restituirà documenti contenenti «hello world» o «hello universe».
`@description:{hello world | hello universe}`
**Intervallo numerico**
L'operatore di intervallo numerico consente di filtrare le query per restituire solo i valori compresi tra un determinato valore iniziale e finale. Sono supportate sia le interrogazioni con intervallo inclusivo che quelle con intervallo esclusivo. Per semplici confronti relazionali, è possibile utilizzare \$1inf, -inf con una query di intervallo. La sintassi per un operatore di ricerca per intervalli è:
```
@:[ [(] [(] ]
```
... dove è un numero o \$1inf o -inf. I limiti senza la parentesi principale aperta sono inclusivi, mentre i limiti con la parentesi principale aperta sono esclusivi.
Utilizza la tabella seguente come guida per mappare le espressioni matematiche alle interrogazioni di filtraggio:
```
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]
```
**Operatori logici**
È possibile utilizzare più tag e operatori di ricerca numerici per creare query complesse utilizzando operatori logici.
**AND logico**
Per impostare un AND logico, utilizzate uno spazio tra i predicati. Esempio:
`query1 query2 query3`
**OR logico**
Per impostare un OR logico, utilizzate uno spazio tra i predicati. Esempio:
`query1 | query2 | query3`
**Negazione logica**
Qualsiasi interrogazione può essere annullata anteponendo il `-` carattere prima di ogni interrogazione. Le query negative restituiscono tutte le voci che non corrispondono alla query. Ciò include anche le chiavi che non dispongono del campo.
Ad esempio, una query negativa su @genre: \$1comedy\$1 restituirà tutti i libri che non sono comici E tutti i libri che non hanno un campo di genere.
La seguente query restituirà tutti i libri di genere «commedia» che non sono stati pubblicati tra il 2015 e il 2024 o che non hanno il campo dell'anno: @genre: [commedia] - @year: [2015 2024]
**Precedenza degli operatori**
Si applicano le tipiche regole di precedenza degli operatori, ad esempio NEGATE logico è la priorità più alta, seguito da AND logico e quindi OR logico con la priorità più bassa. Le parentesi possono essere utilizzate per sovrascrivere le regole di precedenza predefinite.
*Esempi di combinazione di operatori logici*
Gli operatori logici possono essere combinati per formare espressioni di filtro complesse.
La seguente query restituirà tutti i libri di genere «commedia» o «horror» (AND) pubblicati tra il 2015 e il 2024: `@genre:[comedy|horror] @year:[2015 2024]`
La seguente query restituirà tutti i libri di genere «commedia» o «horror» (OR) pubblicati tra il 2015 e il 2024: `@genre:[comedy|horror] | @year:[2015 2024]`
La seguente query restituirà tutti i libri che non hanno un campo di genere o un campo di genere diverso da «commedia», pubblicati tra il 2015 e il 2024: `-@genre:[comedy] @year:[2015 2024]`
# INDICE FT.DROP
**Sintassi**
```
FT.DROPINDEX
```
L'indice specificato viene eliminato. Restituisce OK o restituisce un errore se l'indice non esiste.
+ (obbligatorio): Il nome dell'indice da eliminare.
# FT.INFO
**Sintassi**
```
FT.INFO
```
La ricerca vettoriale amplia il comando [FT.INFO](https://valkey.io/commands/info/) con diverse sezioni aggiuntive di statistiche e contatori. Una richiesta di recupero della sezione SEARCH recupererà tutte le seguenti statistiche:
| Nome chiave | Value type (Tipo di valore) | Description |
| --- | --- | --- |
| nome\$1indice | stringa | Nome dell'indice |
| opzioni\$1indice | stringa | Riservata. Attualmente impostato su «0" |
| index\$1definition | array | Vedi sotto per la definizione di questi elementi dell'array. |
| attributes | matrice di informazioni sugli attributi | Un elemento in questo array per ogni attributo definito, vedi sotto per la definizione delle informazioni sugli attributi. |
| num\$1docs | intero | Numero di chiavi attualmente contenute nell'indice |
| num\$1terms | intero | Riservata. Attualmente impostato su «0". |
| record\$1count | intero | La somma del campo «size» per ogni attributo. |
| hash\$1indexing\$1failures | intero | Numero di volte in cui un attributo non può essere convertito nel tipo di attributo dichiarato. Nonostante il nome, questo vale anche per le chiavi JSON. |
| backfill\$1in\$1progress | intero | Se è attualmente in corso un riempimento, questo sarà un '1', altrimenti sarà uno '0' |
| backfill\$1percent\$1complete | virgola mobile | Stima del completamento del riempimento, un numero frazionario nell'intervallo [0.. 1] |
| mutation\$1queue\$1size | intero | Numero di chiavi in attesa di aggiornamento dell'indice. |
| recent\$1mutations\$1queue\$1delay | intero | Stima del ritardo (in secondi) dell'aggiornamento dell'indice. 0 se non sono in corso aggiornamenti. |
| stato | stringa | Stato di riempimento: «pronto» indica che il riempimento è stato completato correttamente. «backfill\$1in\$1progress» indica che il riempimento è in corso. «backfill\$1paused\$1by\$1oom» significa che il riempimento è stato messo in pausa a causa di una condizione di memoria insufficiente. Una volta risolta la condizione di memoria insufficiente, il backill continuerà. |
La struttura index\$1definition è una matrice di key/value coppie definita come:
| Nome chiave | Value type (Tipo di valore) | Description |
| --- | --- | --- |
| tipo\$1chiave | stringa | O la stringa 'JSON' o la stringa 'HASH' |
| prefissi | array | Ogni elemento dell'array è un prefisso definito per l'indice. Se non è stato specificato alcun prefisso al momento della creazione dell'indice, questo array avrà 0 voci. |
| default\$1score | stringa | Riservata. Attualmente impostato su «1" |
Informazioni sugli attributi: le informazioni sugli attributi sono specifiche del tipo.
Attributi numerici:
| Chiave | Value type (Tipo di valore) | Description |
| --- | --- | --- |
| identificatore | stringa | Posizione dell'attributo all'interno di una chiave. Nome del membro hash o percorso JSON |
| alias | stringa | Nome dell'attributo utilizzato nelle descrizioni delle query. |
| tipo | stringa | La stringa «NUMERIC» |
| formato | intero | Il numero di chiavi con valori numerici validi in questo attributo. |
Attributi dei tag:
| Nome chiave | Value type (Tipo di valore) | Description |
| --- | --- | --- |
| identificatore | stringa | Posizione dell'attributo all'interno di una chiave. Nome del membro hash o percorso JSON |
| alias | stringa | Nome dell'attributo utilizzato nelle descrizioni delle query. |
| tipo | stringa | La stringa «TAG» |
| SEPARATOR | carattere | Il carattere separatore definito al momento della creazione dell'indice |
| DISTINGUE TRA MAIUSCOLE E MINUSCOLE | N/A | Questa chiave non ha alcun valore associato. È presente solo se l'attributo è stato creato con questa opzione. |
| formato | intero | Il numero di chiavi con valori di tag validi in questo attributo |
Attributi vettoriali:
| Nome chiave | Value type (Tipo di valore) | Description |
| --- | --- | --- |
| identificatore | stringa | Posizione dell'attributo all'interno di una chiave. Nome del membro hash o percorso JSON |
| alias | stringa | Nome dell'attributo utilizzato nelle descrizioni delle query. |
| tipo | stringa | La stringa «VECTOR» |
| indice | carattere | Per un'ulteriore descrizione dell'indice vettoriale, vedi sotto. |
Descrizione dell'indice vettoriale:
| Nome chiave | Value type (Tipo di valore) | Description |
| --- | --- | --- |
| capacità | stringa | Capacità attuale dell'indice |
| dimensioni | stringa | Numero di elementi in ogni vettore |
| distance\$1metric | stringa | Uno tra «COSINE», «L2" o «IP» |
| formato | array | Descrizione dell'indice vettoriale, vedi sotto. |
| data\$1type | stringa | Tipo di dati dichiarato. Attualmente è supportato solo FLOAT32 "". |
| Algoritmo | array | Ulteriore descrizione dell'algoritmo di ricerca vettoriale. |
Descrizione dell'algoritmo di ricerca vettoriale FLAT:
| Nome chiave | Value type (Tipo di valore) | Description |
| --- | --- | --- |
| nome | stringa | Nome dell'algoritmo: FLAT |
| block\$1size | numero | Dimensione di un blocco dell'indice FLAT. |
Descrizione dell'indice vettoriale HNSW:
| Nome chiave | Value type (Tipo di valore) | Description |
| --- | --- | --- |
| nome | stringa | Nome dell'algoritmo: HNSW |
| m | numero | Il parametro «M» per HNSW |
| ef\$1construction | numero | Il parametro «ef\$1construction» per HNSW |
| ef\$1runtime | numero | Il parametro «ef\$1runtime» per HNSW. |
# PIEDI. \$1LISTA
Elenca tutti gli indici.
**Sintassi**
```
FT._LIST
```
Restituisce una matrice di stringhe che sono i nomi dell'indice attualmente definito.
# Guida introduttiva a JSON per Valkey e Redis OSS
ElastiCache supporta il formato nativo JavaScript Object Notation (JSON), un modo semplice e senza schemi per codificare set di dati complessi all'interno dei cluster Valkey e Redis OSS. È possibile archiviare e accedere in modo nativo ai dati utilizzando il formato JavaScript Object Notation (JSON) all'interno dei cluster e aggiornare i dati JSON archiviati in tali cluster, senza dover gestire codice personalizzato per serializzarli e deserializzarli.
Oltre a utilizzare le operazioni API Valkey e Redis OSS per le applicazioni che funzionano su JSON, ora puoi recuperare e aggiornare in modo efficiente parti specifiche di un documento JSON senza dover manipolare l'intero oggetto. Ciò può migliorare le prestazioni e ridurre i costi. Puoi cercare anche contenuti del documento JSON utilizzando l’interrogazione `JSONPath` di [tipo Goessner](https://goessner.net/articles/JsonPath/).
Dopo la creazione di un cluster con una versione del motore supportata, il tipo di dati JSON e i comandi associati sono disponibili automaticamente. Compatibile con API e RDB con la versione 2 del modulo JSON, in modo da poter migrare facilmente le applicazioni Valkey e Redis OSS esistenti basate su JSON. ElastiCache Per ulteriori informazioni sui comandi supportati, vedere. [Comandi Valkey e Redis OSS supportatiComandi JSON](json-list-commands.md)
Le metriche `JsonBasedCmds` relative a JSON `JsonBasedCmdsLatency` sono incorporate CloudWatch per monitorare l'utilizzo di questo tipo di dati. Per ulteriori informazioni, consulta [Metrics for](CacheMetrics.Redis.md) Valkey e Redis OSS.
**Nota**
Per utilizzare JSON, è necessario eseguire Valkey 7.2 e versioni successive oppure Redis OSS 6.2.6 o versioni successive.
**Topics**
+ [Panoramica dei tipi di dati JSON](json-document-overview.md)
+ [Comandi Valkey e Redis OSS supportati](json-list-commands.md)
# Panoramica dei tipi di dati JSON
ElastiCache supporta una serie di comandi Valkey e Redis OSS per lavorare con il tipo di dati JSON. Di seguito è riportata una panoramica del tipo di dati JSON e un elenco dettagliato dei comandi supportati.
## Terminology
****
| Termine | Descrizione |
| --- | --- |
| Documento JSON | Si riferisce al valore di una chiave JSON. |
| Valore JSON | Si riferisce a un sottoinsieme di un documento JSON, inclusa la radice che rappresenta l'intero documento. Un valore può essere un container o una voce vuota in un container. |
| Elemento JSON | Equivalente a un valore JSON. |
## Standard JSON supportati
Il formato JSON è compatibile con lo standard di interscambio dati JSON [RFC 7159](https://www.ietf.org/rfc/rfc7159.txt) e [ECMA-404](https://www.ietf.org/rfc/rfc7159.txt). Nel testo JSON è supportato [Unicode](https://www.unicode.org/standard/WhatIsUnicode.html) UTF-8.
## Elemento radice
L'elemento radice può essere qualsiasi tipo di dati JSON. Tieni presente che nello standard RFC 4627 precedente, come valori radice erano consentiti soo oggetti o array. Dopo l'aggiornamento allo standard RFC 7159, la radice di un documento JSON può essere qualunque tipo di dati JSON.
## Limite delle dimensioni del documento
I documenti JSON sono memorizzati internamente in un formato ottimizzato per l’accesso e la modifica rapidi. Questo formato generalmente comporta un consumo di memoria lievemente superiore alla rappresentazione serializzata equivalente dello stesso documento.
Il consumo di memoria di un singolo documento JSON è limitato a 64 MB, cioè la dimensione della struttura dati in memoria, non la stringa JSON. Puoi controllare la quantità di memoria che consuma un documento JSON utilizzando il comando `JSON.DEBUG MEMORY`.
## JSON ACLs
+ Simile alle categorie per tipo di dati esistenti (@string, @hash ecc.), viene aggiunta una nuova categoria @json per semplificare la gestione dell'accesso a comandi e dati JSON. Nessun altro comando Valkey o Redis OSS esistente è membro della categoria @json. Tutti i comandi JSON impongono restrizioni e autorizzazioni per lo spazio delle chiavi o i comandi.
+ Esistono cinque categorie ACL Valkey e Redis OSS esistenti che vengono aggiornate per includere i nuovi comandi JSON: @read, @write, @fast, @slow e @admin. La tabella seguente indica la mappatura dei comandi JSON alle categorie appropriate.
**ACL**
| Comando JSON | @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 | | |
## Limite di profondità di nidificazione
Quando un oggetto o un array JSON ha un elemento che è esso stesso un altro oggetto o array JSON, si dice che tale oggetto o array si nidifica nell'oggetto o nell'array esterno. Il limite massimo di profondità di nidificazione è 128. Qualunque tentativo di creare un documento che contenga una profondità di nidificazione maggiore di 128 verrà rifiutato con un errore.
## Sintassi dei comandi
La maggior parte dei comandi richiede un nome chiave come primo argomento. Alcuni comandi hanno anche un argomento path. L'argomento path per impostazione predefinita è la radice se è facoltativo e non viene fornito.
Notazione:
+ Gli argomenti richiesti sono racchiusi tra parentesi angolari. Esempio:
+ Gli argomenti facoltativi sono racchiusi tra parentesi quadre. Esempio: [path]
+ Argomenti facoltativi supplementari sono indicati da un'ellissi ("…"). Esempio: [json...]
## Sintassi del percorso
JSON Redis supporta due tipi di sintassi del percorso:
+ **Sintassi avanzata**: segue la JSONPath sintassi descritta da [Goessner](https://goessner.net/articles/JsonPath/), come illustrato nella tabella seguente. Abbiamo riordinato e modificato le descrizioni nella tabella per maggiore chiarezza.
+ **Sintassi limitata**: ha limitate capacità di interrogazione.
**Nota**
I risultati di alcuni comandi sono sensibili al tipo di sintassi del percorso utilizzata.
Se un percorso di interrogazione inizia con '\$1', utilizza la sintassi avanzata. In caso contrario, viene utilizzata la sintassi limitata.
**Sintassi avanzata**
****
| Simbolo/espressione | Descrizione |
| --- | --- |
| \$1 | Lelemento radice. |
| . o [] | Operatore figlio. |
| .. | Discesa ricorsiva. |
| \$1 | Carattere jolly. Tutti gli elementi di un oggetto o un array. |
| [] | Operatore pedice di un array. L'indice è basato su 0. |
| [,] | Operatore di unione. |
| [start:end:step] | Operatore di sezionamento di un array. |
| ?() | Applica un'espressione filtro (script) all'array o all'oggetto corrente. |
| () | Espressione filtro. |
| @ | Utilizzato in espressioni filtro che fanno riferimento al nodo corrente in elaborazione. |
| == | Uguale a, utilizzato in espressioni filtro. |
| \$1= | Diverso da, utilizzato in espressioni filtro. |
| > | Maggiore di, utilizzato in espressioni filtro. |
| >= | Maggiore o uguale a, utilizzato in espressioni filtro. |
| < | Minore di, utilizzato in espressioni filtro. |
| <= | Mainore o uguale a, utilizzato in espressioni filtro. |
| && | AND logico, utilizzato per combinare più espressioni filtro. |
| \$1\$1 | OR logico, utilizzato per combinare più espressioni filtro. |
**Examples** (Esempi)
Gli esempi seguenti sono basati su dati XML di esempio di [Goessner](https://goessner.net/articles/JsonPath/), che abbiamo modificato aggiungendo campi supplementari.
```
{ "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
}
}
}
```
****
| Path | Descrizione |
| --- | --- |
| \$1.store.book[\$1].author | Gli autori di tutti i libri del negozio. |
| \$1..author | tutti gli autori. |
| \$1.store.\$1 | Tutti i membri del negozio. |
| \$1["store"].\$1 | Tutti i membri del negozio. |
| \$1.store..price | Il prezzo di ogni cosa nel negozio. |
| \$1..\$1 | Tutti i membri ricorsivi della struttura JSON. |
| \$1..book[\$1] | Tutti i libri. |
| \$1..book[0] | Il primo libro. |
| \$1..book[-1] | L'ultimo libro. |
| \$1..book[0:2] | I primi due libri. |
| \$1..book[0,1] | I primi due libri. |
| \$1..book[0:4] | Libri dall'indice 0 al 3 (l'indice finale escluso). |
| \$1..book[0:4:2] | Libri nell’indice 0, 2. |
| \$1..book[?(@.isbn)] | Tutti i libri con un numero ISBN. |
| \$1..book[?(@.price<10)] | Tutti i libri che costano meno di 10 euro. |
| '\$1..book[?(@.price < 10)]' | Tutti i libri che costano meno di 10 euro. (Il percorso deve essere tra virgolette se contiene spazi vuoti.) |
| '\$1..book[?(@["price"] < 10)]' | Tutti i libri che costano meno di 10 euro. |
| '\$1..book[?(@.["price"] < 10)]' | Tutti i libri che costano meno di 10 euro. |
| \$1..book[?(@.price>=10&&@.price<=100)] | Tutti i libri nella fascia di prezzo da 10 a 100 euro, inclusi. |
| '\$1..book[?(@.price>=10 && @.price<=100)]' | Tutti i libri nella fascia di prezzo da 10 a 100 euro, inclusi. (Il percorso deve essere tra virgolette se contiene spazi vuoti.) |
| \$1..book[?(@.sold==true\$1\$1@.in-stock==false)] | Tutti i libri venduti o esauriti. |
| '\$1..book[?(@.sold == true \$1\$1 @.in-stock == false)]' | Tutti i libri venduti o esauriti. (Il percorso deve essere tra virgolette se contiene spazi vuoti.) |
| '\$1.store.book[?(@.["category"] == "fiction")]' | Tutti i libri della categoria fiction. |
| '\$1.store.book[?(@.["category"] \$1= "fiction")]' | Tutti i libri appartenenti a categorie nonfiction. |
Altri esempi di espressioni filtro:
```
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]"
```
**Sintassi limitata**
****
| Simbolo/espressione | Descrizione |
| --- | --- |
| . o [] | Operatore figlio. |
| [] | Operatore pedice di un array. L'indice è basato su 0. |
**Examples** (Esempi)
****
| Path | Descrizione |
| --- | --- |
| .store.book[0].author | L'autore del primo libro. |
| .store.book[-1].author | L'autore dell’ultimo libro. |
| .address.city | Nome della città. |
| ["store"]["book"][0]["title"] | Il titolo del primo libro. |
| ["store"]["book"][-1]["title"] | Il titolo dell’ultimo libro. |
**Nota**
Tutti i contenuti di [Goessner](https://goessner.net/articles/JsonPath/) citati in questa documentazione sono soggetti alla [Creative Commons License](https://creativecommons.org/licenses/by/2.5/).
## Prefissi di errori comuni
Ogni messaggio di errore ha un prefisso. Di seguito è riportato un elenco di prefissi di errori comuni..
****
| Prefix | Descrizione |
| --- | --- |
| ERR | Un errore generale. |
| LIMIT | Un errore che si verifica quando vengono superati i limiti delle dimensioni. Ad esempio, il limite delle dimensioni del documento o il limite di profondità di nidificazione è stato superato. |
| NONEXISTENT | Una chiave o percorso non esiste. |
| OUTOFBOUNDARIES | Un indice array esterno ai limiti. |
| SYNTAXERR | Errore di sintassi. |
| WRONGTYPE | Tipo di valore errato. |
## Metriche correlate a JSON
Di seguito sono fornite le seguenti metriche di informazioni JSON:
****
| Info | Descrizione |
| --- | --- |
| json\$1total\$1memory\$1bytes | Memoria totale allocata agli oggetti JSON. |
| json\$1num\$1documents | Numero totale di documenti in Valkey o Redis OSS. |
Per interrogare le metriche di base, esegui il seguente comando:
```
info json_core_metrics
```
## In che modo ElastiCache Valkey e Redis OSS interagiscono con JSON
La sezione seguente descrive come ElastiCache Valkey e Redis OSS interagiscono con il tipo di dati JSON.
### Precedenza degli operatori
Durante la valutazione delle espressioni condizionali per il filtro, && hanno la precedenza, quindi vengono valutati \$1\$1, come nella maggior parte dei linguaggi. Operazioni tra parentesi vengono eseguite per prime.
### Comportamento del limite massimo di nidificazione dei percorsi
Il limite massimo di annidamento dei percorsi ElastiCache per Redis OSS è 128. Per cui, un valore come `$.a.b.c.d...` può raggiungere solo 128 livelli.
### Gestione dei valori numerici
JSON non hanno tipi di dati separati per numeri interi e numeri in virgola mobile. Sono tutti definiti “numeri”.
Rappresentazioni numeriche:
Quando un numero JSON viene ricevuto nell’input, viene convertito in una delle due rappresentazioni binarie interne: un numero intero con segno a 64 bit o un numero in virgola mobile a doppia precisione IEEE a 64 bit . La stringa originaria e tutta la formattazione non vengono mantenute. Pertanto, quando un numero viene emesso come parte di una risposta JSON, viene convertito dalla rappresentazione binaria interna in una stringa stampabile che utilizza regole di formattazione generiche. Queste regole potrebbero determinare la generazione di una stringa diversa da quella ricevuta.
Comandi aritmetici `NUMINCRBY` e `NUMMULTBY`:
+ Se entrambi i numeri sono interi e il risultato non rientra nell'intervallo `int64`, diventa automaticamente un numero in virgola mobile a doppia precisione IEEE a 64 bit.
+ Se almeno uno dei numeri è in virgola mobile, il risultato è un numero in virgola mobile a doppia precisione IEEE a 64 bit.
+ Se il risultato supera l'intervallo doppio IEEE a 64 bit, il comando restituisce un errore `OVERFLOW`.
Per un elenco dei comandi disponibili, consulta [Comandi Valkey e Redis OSS supportatiComandi JSON](json-list-commands.md).
### Filtraggio array diretto
ElastiCache per Valkey o Redis OSS filtra direttamente gli oggetti dell'array.
Per dati come `[0,1,2,3,4,5,6]` e una query di percorso come`$[?(@<4)]`, o dati simili `{"my_key":[0,1,2,3,4,5,6]}` e una query di percorso come`$.my_key[?(@<4)]`, ElastiCache restituirebbe [1,2,3] in entrambe le circostanze.
### Comportamento di indicizzazione array
ElastiCache per Valkey o Redis OSS consente indici sia positivi che negativi per gli array. Per un array di lunghezza cinque, 0 interroga il primo elemento, 1 il secondo e così via. I numeri negativi iniziano alla fine dell'array, per cui -1 interroga il quinto elemento, -2 il quarto e così via.
Per garantire un comportamento prevedibile per i clienti, ElastiCache non arrotonda gli indici degli array verso il basso o verso l'alto, quindi se si dispone di un array con una lunghezza di 5, chiamare l'indice 5 o superiore, oppure -6 o inferiore, non produrrebbe alcun risultato.
### Valutazione della sintassi rigida
MemoryDBnon consente percorsi JSON con sintassi non valida, neppure se un sottoinsieme del percorso contiene un percorso valido. Ciò permantenere un comportamento corretto per i nostri clienti.
# Comandi Valkey e Redis OSS supportati
ElastiCache supporta i seguenti comandi JSON Valkey e Redis OSS:
**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
Accoda uno o più valori rispetto ai valori dell'array nel percorso.
Sintassi
```
JSON.ARRAPPEND [json ...]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (richiesto) – Un percorso JSON.
+ json (richiesto) – Il valore JSON da accodare all’array.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di numeri interi che rappresentano la nuova lunghezza dell'array in ogni percorso.
+ Se un valore non è un array, il valore restituito corrispondente è null.
+ Errore `NONEXISTENT` se il percorso non esiste.
Se il percorso è una sintassi limitata:
+ Numero intero, la nuova lunghezza dell'array.
+ Se sono selezionati più valori di matrice, il comando restituisce la nuova lunghezza del primo array aggiornato.
+ Errore `WRONGTYPE` se il valore nel percorso non è un array.
+ Errore `SYNTAXERR` se uno degli argomenti json di input non è una stringa JSON valida.
+ Errore `NONEXISTENT` se il percorso non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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\"]]"
```
Sintassi limitata del percorso:
```
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
Cerca la prima ricorrenza di un valore JSON scalare negli array nel percorso.
+ Gli errori “fuori intervallo” vengono gestiti arrotondando l'indice all'inizio e alla fine dell'array.
+ Se l’inizio è maggiore della fine, restituisce -1 (non trovato).
Sintassi
```
JSON.ARRINDEX [start [end]]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (richiesto) – Un percorso JSON.
+ json-scalar (richiesto) —Il valore scalare per cercare. Lo scalare JSON si riferisce a valori diversi da oggetti o array. Vale a dire che stringa, numero, booleano e null sono valori scalari.
+ start (facoltativo) – L’indice start, incluso. Se non è fornito, viene utilizzata l’impostazione predefinita, 0.
+ end (facoltativo) – L’indice end, escluso. Se non è fornito, viene utilizzata l’impostazione predefinita, 0, cioè viene incluso l'ultimo elemento. 0 o -1 significa che è incluso l'ultimo elemento.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di numeri interi. Ogni valore è l'indice dell'elemento corrispondente nell'array nel percorso. Se non viene trovato, il valore è -1.
+ Se un valore non è un array, il valore restituito corrispondente è null.
Se il percorso è una sintassi limitata:
+ Numero intero, l'indice dell'elemento corrispondente o -1 se non viene trovato.
+ Errore `WRONGTYPE` se il valore nel percorso non è un array.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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
```
Sintassi limitata del percorso:
```
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
Inserisce uno o più valori nei valori dell'array nel percorso prima dell'indice.
Sintassi
```
JSON.ARRINSERT [json ...]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (richiesto) – Un percorso JSON.
+ index (richiesto) —Un indice array prima del quale sono inseriti valori.
+ json (richiesto) – Il valore JSON da accodare all’array.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di numeri interi che rappresentano la nuova lunghezza dell'array in ogni percorso.
+ Se un valore è un array vuoto, il valore restituito corrispondente è null.
+ Se un valore non è un array, il valore restituito corrispondente è null.
+ Errore `OUTOFBOUNDARIES` se l'argomento indice è fuori dai limiti.
Se il percorso è una sintassi limitata:
+ Numero intero, la nuova lunghezza dell'array.
+ Errore `WRONGTYPE` se il valore nel percorso non è un array.
+ Errore `OUTOFBOUNDARIES` se l'argomento indice è fuori dai limiti.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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\"]]"
```
Sintassi limitata del percorso:
```
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
Ottiene la lunghezza dei valori dell'array nel percorso.
Sintassi
```
JSON.ARRLEN [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di numeri interi che rappresentano la lunghezza dell'array in ogni percorso.
+ Se un valore non è un array, il valore restituito corrispondente è null.
+ Null se la chiave del documento non esiste.
Se il percorso è una sintassi limitata:
+ Numero intero, lunghezza dell'array.
+ Se sono selezionati più oggetti, il comando restituisce la lunghezza del primo array.
+ Errore `WRONGTYPE` se il valore nel percorso non è un array.
+ Errore `NONEXISTENT JSON` se il percorso non esiste.
+ Null se la chiave del documento non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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)
```
Sintassi limitata del percorso:
```
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
Rimuove e restituisce un elemento nell'indice dall'array. Il prelievo di un array vuoto restituisce null.
Sintassi
```
JSON.ARRPOP [path [index]]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
+ index (facoltativo) —La posizione nell'array da cui iniziare il prelievo.
+ Viene ripristinato il valore predefinito -1 se non è fornito, ossia l'ultimo elemento.
+ Un valore negativo indica la posizione dall'ultimo elemento.
+ Gli indici fuori limite vengono arrotondati ai rispettivi limiti dell'array.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di stringhe in blocco che che rappresentano i valori prelevati in ogni percorso.
+ Se un valore è un array vuoto, il valore restituito corrispondente è null.
+ Se un valore non è un array, il valore restituito corrispondente è null.
Se il percorso è una sintassi limitata:
+ Stringa in blocco che rappresenta il valore JSON prelevato.
+ Null se l'array è vuoto.
+ Errore `WRONGTYPE` se il valore nel percorso non è un array.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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\"]]"
```
Sintassi limitata del percorso:
```
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
Taglia un array nel percorso in modo che diventi un array secondario [start, end], entrambi inclusi.
+ Se l'array è vuoto, non eseguire nulla, restituire 0.
+ Se start <0, considerarlo come 0.
+ Se end >= size (dimensione dell’array), considerarlo comesize-1.
+ Se start >= size o start > end, svuotare l'array e restituire 0.
Sintassi
```
JSON.ARRTRIM
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (richiesto) – Un percorso JSON.
+ start (richiesto) – L’indice start, incluso.
+ end (richiesto) – L’indice end, incluso.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di numeri interi che rappresentano la nuova lunghezza dell'array in ogni percorso.
+ Se un valore è un array vuoto, il valore restituito corrispondente è null.
+ Se un valore non è un array, il valore restituito corrispondente è null.
+ Errore `OUTOFBOUNDARIES` se un argomento indice è fuori dai limiti.
Se il percorso è una sintassi limitata:
+ Numero intero, la nuova lunghezza dell'array.
+ Null se l'array è vuoto.
+ Errore `WRONGTYPE` se il valore nel percorso non è un array.
+ Errore `OUTOFBOUNDARIES` se un argomento indice è fuori dai limiti.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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\"]]"
```
Sintassi limitata del percorso:
```
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
Cancella gli array o un oggetto nel percorso.
Sintassi
```
JSON.CLEAR [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
**Valori restituiti**
+ Numero intero, il numero di container cancellati.
+ La cancellazione di un oggetto o un array vuoto rappresenta 1 container cancellato.
+ La cancellazione di un valore non container restituisce 0.
**Examples** (Esempi)
```
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
Riporta informazioni. Sottocomandi supportati:
+ MEMORY [path] – Riporta l’utilizzo della memoria in byte di un valore JSON. Se non è fornito, viene ripristinato il percorso predefinito, la radice.
+ FIELDS [path] – Riporta il numero di campi nel percorso del documento specificato. Se non è fornito, viene ripristinato il percorso predefinito, la radice. Ogni valore JSON non container viene conteggiato come un singolo campo. Oggetti e array vengono conteggiati ricorsivamente come singolo campo per ognuno dei loro valori JSON contenenti. Ogni valore container, tranne il container radice, viene conteggiato come un campo aggiuntivo.
+ HELP – Stampa messaggi della guida del comando.
Sintassi
```
JSON.DEBUG
```
Dipende dal sottocomando:
MEMORY
+ Se il percorso è una sintassi avanzata:
+ Restituisce un array di numeri interi che rappresentano la dimensione della memoria (in byte) del valore JSON in ogni percorso.
+ Restituisce un array vuoto se la chiave Valkey o Redis OSS non esiste.
+ Se il percorso è una sintassi limitata:
+ Restituisce un numero intero, le dimensioni della memoria e il valore JSON in byte.
+ Restituisce null se la chiave Valkey o Redis OSS non esiste.
FIELDS
+ Se il percorso è una sintassi avanzata:
+ Restituisce un array di numeri interi che rappresentano il numero di campi del valore JSON in ogni percorso.
+ Restituisce un array vuoto se la chiave Valkey o Redis OSS non esiste.
+ Se il percorso è una sintassi limitata:
+ Restituisce un numero intero, il numero di campi del valore JSON.
+ Restituisce null se la chiave Valkey o Redis OSS non esiste.
HELP – Restituisce un array di messaggi della guida.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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
```
Sintassi limitata del percorso:
```
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
Elimina i valori JSON nel percorso in una chiave del documento. Se il percorso è la radice, equivale a eliminare la chiave da Valkey o Redis OSS.
Sintassi
```
JSON.DEL [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo di documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
**Valori restituiti**
+ Numero di elementi eliminati.
+ 0 se la chiave Valkey o Redis OSS non esiste.
+ 0 se il percorso JSON non è valido o non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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\":[]}"
```
Sintassi limitata del percorso:
```
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 di [JSON.DEL](json-del.md).
# JSON.GET
Restituisce il JSON serializzato in uno o più percorsi.
Sintassi
```
JSON.GET
[INDENT indentation-string]
[NEWLINE newline-string]
[SPACE space-string]
[NOESCAPE]
[path ...]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ INDENT/NEWLINE/SPACE(opzionale) — Controlla il formato della stringa JSON restituita, ovvero «pretty print». Il valore predefinito di ciascuno è una stringa vuota. Può essere sovrascritto in qualunque combinazione. Possono essere specificati in qualunque ordine.
+ NOESCAPE — Facoltativo, presenza consentita per compatibilità legacy senza altri effetti.
+ path (facoltativo) — Zero o più percorsi JSON; il valore predefinito è la radice, se non viene fornito. Gli argomenti del percorso devono essere collocati alla fine.
**Valori restituiti**
Sintassi avanzata del percorso:
Se viene fornito un percorso:
+ Restituisce una stringa serializzata di un array di valori.
+ Se non è selezionato alcun valore, il comando restituisce un array vuoto.
Se vengono forniti più percorsi:
+ Restituisce un oggetto JSON con stringify, in cui ogni percorso è una chiave.
+ in presenza di sintassi mista e avanzata dei percorsi, il risultato è conforme alla sintassi avanzata.
+ Se un percorso non esiste, il valore corrispondente è un array vuoto.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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]"
```
Sintassi limitata del percorso:
```
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
Viene serializzato JSONs nel percorso da più chiavi del documento. Restituisce null per una chiave o percorso JSON inesistente.
**Sintassi**
```
JSON.MGET [key ...]
```
+ chiave (obbligatoria): una o più chiavi Valkey o Redis OSS di tipo documento.
+ path (richiesto) – Un percorso JSON.
**Valori restituiti**
+ Array di stringhe in blocco. La dimensione dell'array è uguale al numero di chiavi nel comando. Ogni elemento dell'array è popolato con a) JSON serializzato come collocato dal percorso o b) null se la chiave non esiste, il percorso non esiste nel documento oppure il percorso non è valido (errore di sintassi).
+ Se una delle chiavi specificate esiste e non è una chiave JSON, il comando restituisce l’errore `WRONGTYPE`.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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\"]"
```
Sintassi limitata del percorso:
```
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
Supportato per Valkey versione 8.1 e successive.
Imposta i valori JSON per più chiavi. L'operazione è atomica. Tutti i valori sono impostati o non ne è impostato nessuno.
**Sintassi**
```
JSON.MSET key path json [ key path json ... ]
```
+ Se il percorso richiede un membro oggetto:
+ Se l'elemento principale non esiste, il comando restituirà l'errore NONEXISTENT.
+ Se l'elemento principale esiste ma non è un oggetto, il comando restituirà ERROR.
+ Se l'elemento padre esiste ed è un oggetto:
+ Se il membro non esiste, un nuovo membro verrà accodato all'oggetto padre se e solo se l'oggetto padre è l'ultimo figlio nel percorso. In caso contrario, il comando restituirà un errore INESISTENTE.
+ Se il membro esiste, il suo valore verrà sostituito dal valore JSON.
+ Se il percorso richiede un indice di array:
+ Se l'elemento principale non esiste, il comando restituirà un errore INESISTENTE.
+ Se l'elemento principale esiste ma non è un array, il comando restituirà ERROR.
+ Se l'elemento principale esiste ma l'indice non è compreso nei limiti, il comando restituirà l'errore OUTOFBOUNDARIES.
+ Se l'elemento padre esiste e l'indice è valido, l'elemento verrà sostituito dal nuovo valore JSON.
+ Se il percorso richiede un oggetto o un array, il valore (oggetto o array) verrà sostituito dal nuovo valore JSON.
**Valori restituiti**
+ Risposta in formato stringa semplice: 'OK' se l'operazione è andata a buon fine.
+ Risposta di errore semplice: se l'operazione non è riuscita.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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]}"
```
Sintassi limitata del percorso:
```
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
Incrementa i valori numerici nel percorso di un determinato numero.
Sintassi
```
JSON.NUMINCRBY
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (richiesto) – Un percorso JSON.
+ numero (richiesto) – Un numero.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di stringhe in blocco che rappresenta il valore risultante in ogni percorso.
+ Se un valore non è un numero, il valore restituito corrispondente è null.
+ Errore `WRONGTYPE` se il numero non può essere analizzato.
+ Errore `OVERFLOW` se il risultato non rientra nell'intervallo del doppio IEEE a 64 bit.
+ `NONEXISTENT` se la chiave del documento non esiste.
Se il percorso è una sintassi limitata:
+ Stringa in blocco che rappresenta il valore risultante.
+ Se sono selezionati più valori array, il comando restituisce il risultato dell’ultimo valore aggiornato.
+ Errore `WRONGTYPE` se il valore nel percorso non è un numero.
+ Errore `WRONGTYPE` se il numero non può essere analizzato.
+ Errore `OVERFLOW` se il risultato non rientra nell'intervallo del doppio IEEE a 64 bit.
+ `NONEXISTENT` se la chiave del documento non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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}}"
```
Sintassi limitata del percorso:
```
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
Moltiplica i valori numerici nel percorso di un determinato numero.
Sintassi
```
JSON.NUMMULTBY
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (richiesto) – Un percorso JSON.
+ numero (richiesto) – Un numero.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di stringhe in blocco che rappresentano il valore risultante in ogni percorso.
+ Se un valore non è un numero, il valore restituito corrispondente è null.
+ Errore `WRONGTYPE` se il numero non può essere analizzato.
+ Errore `OVERFLOW` se il risultato è esterno all’intervallo di numero in virgola mobile a doppia precisione IEEE a 64 bit.
+ `NONEXISTENT` se la chiave del documento non esiste.
Se il percorso è una sintassi limitata:
+ Stringa in blocco che rappresenta il valore risultante.
+ Se sono selezionati più valori array, il comando restituisce il risultato dell’ultimo valore aggiornato.
+ Errore `WRONGTYPE` se il valore nel percorso non è un numero.
+ Errore `WRONGTYPE` se il numero non può essere analizzato.
+ Errore `OVERFLOW` se il risultato è esterno all’intervallo di un doppio IEEE a 64 bit.
+ `NONEXISTENT` se la chiave del documento non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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]"
```
Sintassi limitata del percorso:
```
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
Ottiene il numero di chiavi nei valori oggetto nel percorso.
Sintassi
```
JSON.OBJLEN [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di numeri interi che rappresentano la lunghezza dell’oggetto in ogni percorso.
+ Se un valore non è un oggetto, il valore restituito corrispondente è null.
+ Null se la chiave del documento non esiste.
Se il percorso è una sintassi limitata:
+ Numero intero, numero di chiavi nell'oggetto.
+ Se sono selezionati più oggetti, il comando restituisce la lunghezza del primo oggetto.
+ Errore `WRONGTYPE` se il valore nel percorso non è un oggetto.
+ Errore `NONEXISTENT JSON` se il percorso non esiste.
+ Null se la chiave del documento non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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)
```
Sintassi limitata del percorso:
```
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
Ottiene i nomi chiave nei valori oggetto nel percorso.
Sintassi
```
JSON.OBJKEYS [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di array di stringhe in blocco. Ogni elemento è un array di chiavi in un oggetto corrispondente.
+ Se un valore non è un oggetto, il valore restituito corrispondente è un valore vuoto.
+ Null se la chiave del documento non esiste.
Se il percorso è una sintassi limitata:
+ Array di stringhe in blocco. Ogni elemento è un nome chiave nell'oggetto.
+ Se sono selezionati più oggetti, il comando restituisce le chiavi del primo oggetto.
+ Errore `WRONGTYPE` se il valore nel percorso non è un oggetto.
+ Null se la chiave del documento non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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"
```
Sintassi limitata del percorso:
```
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
Restituisce il valore JSON nel percorso specificato in Valkey o Redis OSS Serialization Protocol (RESP). Se il valore è container, la risposta è un array RESP o un array nidificato.
+ Un valore null JSON è mappato alla stringa in blocco null RESP.
+ I valori booleani JSON sono mappati alle rispettive stringhe semplici RESP.
+ I numeri interi sono mappati a numeri interi RESP.
+ I numeri a virgola mobile doppia IEEE a 64 bit sono mappati a stringhe in blocco RESP.
+ Le stringhe JSON sono mappate a stringhe in blocco RESP.
+ Gli array JSON sono rappresentati come array RESP, dove il primo elemento è la stringa semplice [, seguita dagli elementi dell'array.
+ Gli ooggetti JSONsono rappresentati come array RESP, dove il primo elemento è la stringa semplice \$1, seguita da coppie chiave-valore, ognuna delle quali è una stringa in blocco RESP.
Sintassi
```
JSON.RESP [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo di documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di array. Ogni elemento dell'array rappresenta la forma RESP del valore in un unico percorso.
+ Array vuoto se la chiave del documento non esiste.
Se il percorso è una sintassi limitata:
+ Array che rappresenta la forma RESP del valore nel percorso.
+ Null se la chiave del documento non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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"
```
Sintassi limitata del percorso:
```
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
Imposta valori JSON nel percorso.
Se il percorso richiede un membro oggetto:
+ Se l'elemento padre non esiste, il comando restituisce un errore NONEXISTENT.
+ Se l'elemento padre esiste ma non è un oggetto, il comando restituisce ERROR.
+ Se l'elemento padre esiste ed è un oggetto:
+ Se il membro non esiste, un nuovo membro verrà accodato all'oggetto padre se e solo se l'oggetto padre è l'ultimo figlio nel percorso. In caso contrario, il comando restituisce un errore NONEXISTENT.
+ Se il membro esiste, il suo valore verrà sostituito dal valore JSON.
Se il percorso richiede un indice di array:
+ Se l'elemento padre non esiste, il comando restituisce un errore NONEXISTENT.
+ Se l'elemento padre esiste ma non è un array, il comando restituisce ERROR.
+ Se l'elemento padre esiste ma l'indice è esterno ai limiti, il comando restituisce un errore OUTOFBOUNDARIES.
+ Se l'elemento padre esiste e l'indice è valido, l'elemento verrà sostituito dal nuovo valore JSON.
Se il percorso richiede un oggetto o un array, il valore (oggetto o array) verrà sostituito dal nuovo valore JSON.
Sintassi
```
JSON.SET [NX | XX]
```
[NX \$1 XX] Dove è possibile avere 0 o 1 identificatori [NX \$1 XX].
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (richiesto) – Un percorso JSON. Per una nuova chiave, il percorso JSON deve essere la radice «.».
+ NX (opzionale): se il percorso è la radice, imposta il valore solo se la chiave non esiste. Inserire, cioè, un nuovo documento. Se il percorso non è la radice, impostare il valore solo se il percorso non esiste. Inserire, cioè, un valore nel documento.
+ XX (opzionale): se il percorso è la radice, imposta il valore solo se la chiave esiste. Sostituire, cioè, il documento esistente. Se il percorso non è la radice, impostare il valore solo se il percorso esiste. Aggiornare, cioè, il valore esistente.
**Valori restituiti**
+ Stringa semplice 'OK' se l’esito è positivo.
+ Null se la condizione NX o XX non viene soddisfatta.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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]}"
```
Sintassi limitata del percorso:
```
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
Accoda un elemento stringa alle stringhe JSON nel percorso.
Sintassi
```
JSON.STRAPPEND [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
+ json\$1string (richiesto) – La rappresentazione JSON di una stringa. Tieni presente che una stringa JSON deve essere tra virgolette. Esempio: '"esempio di stringa"'.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di numeri interi che rappresentano la nuova lunghezza della stringa in ogni percorso.
+ Se un valore nel percorso non è una stringa, il valore restituito corrispondente è null.
+ Errore `SYNTAXERR` se l’argomento json di input non è una stringa JSON valida.
+ Errore `NONEXISTENT` se il percorso non esiste.
Se il percorso è una sintassi limitata:
+ Numero intero, la nuova lunghezza della stringa.
+ Se sono selezionati più valori array, il comando restituisce la nuova lunghezza dell'ultima stringa aggiornata.
+ Errore `WRONGTYPE` se il valore nel percorso non è una stringa.
+ Errore `WRONGTYPE` se l’argomento json di input non è una stringa JSON valida.
+ Errore `NONEXISTENT` se il percorso non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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)
```
Sintassi limitata del percorso:
```
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
Ottiene le lunghezze dei valori stringa JSON nel percorso.
Sintassi
```
JSON.STRLEN [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di numeri interi che rappresenta del valore stringa in ogni percorso.
+ Se un valore non è una stringa, il valore restituito corrispondente è null.
+ Null se la chiave del documento non esiste.
Se il percorso è una sintassi limitata:
+ Numero intero, la lunghezza della stringa.
+ Se sono selezionati più valori stringa, il comando restituisce la lunghezza della prima stringa.
+ Errore `WRONGTYPE` se il valore nel percorso non è una stringa.
+ Errore `NONEXISTENT` se il percorso non esiste.
+ Null se la chiave del documento non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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)
```
Sintassi limitata del percorso:
```
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
Alterna valori booleani vero e falso nel percorso.
Sintassi
```
JSON.TOGGLE [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di numeri interi (0 - falso, 1 - vero) che rappresentano valore booleano risultante in ogni percorso.
+ Se un valore non è un valore booleano, il valore restituito corrispondente è null.
+ `NONEXISTENT` se la chiave del documento non esiste.
Se il percorso è una sintassi limitata:
+ Stringa ("true"/"false") che rappresenta il valore booleano risultante.
+ `NONEXISTENT` se la chiave del documento non esiste.
+ Errore `WRONGTYPE` se il valore nel percorso non è un valore booleano.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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)
```
Sintassi limitata del percorso:
```
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
Reports lotipo divalori nel percorso indicato.
Sintassi
```
JSON.TYPE [path]
```
+ key (obbligatorio) — Una chiave Valkey o Redis OSS di tipo documento JSON.
+ path (facoltativo) – Un percorso JSON. Se non è fornito, per impostazione predefinita viene ripristinata la radice.
**Valori restituiti**
Se il percorso è una sintassi avanzata:
+ Array di stringhe che rappresentano il tipo di valore in ogni percorso. Il tipo è uno di \$1"null", "boolean", "string", "number", "integer", "object" e "array"\$1.
+ Se un percorso non esiste, il valore restituito corrispondente è null.
+ Array vuoto se la chiave del documento non esiste.
Se il percorso è una sintassi limitata:
+ Stringa, tipo di valore
+ Null se la chiave del documento non esiste.
+ Null se il percorso JSON non è valido o non esiste.
**Examples** (Esempi)
Sintassi avanzata del percorso:
```
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
```
Sintassi limitata del percorso:
```
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
```
# Taggare le tue risorse ElastiCache
Per aiutarti a gestire i tuoi cluster e altre ElastiCache risorse, puoi assegnare i tuoi metadati a ciascuna risorsa sotto forma di tag. I tag consentono di classificare le AWS risorse in diversi modi, ad esempio per scopo, proprietario o ambiente. Questa caratteristicaè molto utile quando hai tante risorse dello stesso tipo in quanto puoi rapidamente individuare una risorsa specifica in base ai tag assegnati. Questo argomento descrive i tag e mostra come crearli.
**avvertimento**
Come da best practice, è consigliabile non includere dati sensibili nei tag.
## Nozioni di base sui tag
Un tag è un'etichetta che si assegna a una AWS risorsa. Ogni tag è composto da una chiave e da un valore opzionale, entrambi personalizzabili. I tag consentono di classificare le AWS risorse in diversi modi, ad esempio per scopo o proprietario. Ad esempio, puoi definire un set di tag per ElastiCache i cluster del tuo account che ti aiuti a tenere traccia del proprietario e del gruppo di utenti di ogni istanza.
Ti consigliamo di creare un set di chiavi di tag in grado di soddisfare i requisiti di ciascun tipo di risorsa. Con un set di chiavi di tag coerente, la gestione delle risorse risulta semplificata. Puoi cercare e filtrare le risorse in base ai tag aggiunti. Per ulteriori informazioni sulle modalità di implementazione di una strategia efficace di applicazione di tag alle risorse, consulta il [whitepaper AWS Best practice per l'applicazione di tag](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf).
I tag non hanno alcun significato semantico ElastiCache e vengono interpretati rigorosamente come una stringa di caratteri. Inoltre, i tag non vengono assegnati automaticamente alle risorse. Puoi modificare chiavi e valori di tag e rimuovere tag da una risorsa in qualsiasi momento. È possibile impostare il valore di un tag su `null`. Se aggiungi un tag con la stessa chiave di un tag esistente su quella risorsa, il nuovo valore sovrascrive il vecchio valore. Se elimini una risorsa, verranno eliminati anche tutti i tag a essa associati. Inoltre, se si aggiungono o eliminano tag in un gruppo di replica, verranno aggiunti o rimossi anche i tag di tutti i nodi del gruppo di replica.
Puoi lavorare con i tag utilizzando l'Console di gestione AWSAWS CLI, la e l' ElastiCache API.
Se utilizzi IAM, puoi controllare quali utenti del tuo AWS account sono autorizzati a creare, modificare o eliminare i tag. Per ulteriori informazioni, consulta [Autorizzazioni a livello di risorsa](IAM.ResourceLevelPermissions.md).
## Risorse cui è possibile associare tag
Puoi taggare la maggior parte ElastiCache delle risorse già esistenti nel tuo account. Nella tabella seguente sono elencate le risorse che supportano il tagging. Se utilizzi il Console di gestione AWS, puoi applicare tag alle risorse utilizzando il [Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html). Alcune schermate relative alle risorse ti permettono di specificare i tag per una risorsa quando crei la risorsa, ad esempio un tag con la chiave con nome e un valore specificato. Nella maggior parte dei casi, la console applica i tag subito dopo la creazione della risorsa, anziché durante il processo di creazione. La console può organizzare le risorse in base al tag **Name**, ma questo tag non ha alcun significato semantico per il ElastiCache servizio.
Inoltre, alcune operazioni per la creazione di risorse ti consentono di specificare tag per una risorsa durante la sua creazione. Se i tag non possono essere applicati durante la creazione della risorsa, eseguiamo il rollback del processo di creazione della risorsa. Ciò fa sì che le risorse vengano create con i tag oppure che non vengano create affatto, nonché che nessuna risorsa sia mai sprovvista di tag. Il tagging delle risorse in fase di creazione ti permette di evitare di eseguire script di tagging personalizzati dopo la creazione delle risorse.
Se utilizzi l' ElastiCache API Amazon, la AWS CLI o un AWS SDK, puoi utilizzare il `Tags` parametro nell'azione ElastiCache API pertinente per applicare i tag. Questi sono:
+ `CreateServerlessCache`
+ `CreateCacheCluster`
+ `CreateReplicationGroup`
+ `CopyServerlessCacheSnapshot`
+ `CopySnapshot`
+ `CreateCacheParameterGroup`
+ `CreateCacheSecurityGroup`
+ `CreateCacheSubnetGroup`
+ `CreateServerlessCacheSnapshot`
+ `CreateSnapshot`
+ `CreateUserGroup`
+ `CreateUser`
+ `PurchaseReservedCacheNodesOffering`
La tabella seguente descrive le ElastiCache risorse che possono essere etichettate e le risorse che possono essere taggate al momento della creazione utilizzando l' ElastiCache API, la AWS CLI o un AWS SDK.
**Supporto per l'etichettatura delle risorse ElastiCache**
| Risorsa | support dei tag | Supporta l'applicazione di tag in fase di creazione |
| --- | --- | --- |
| serverlesscache | Sì | Sì |
| Gruppo di parametri | Sì | Sì |
| SecurityGroup | Sì | Sì |
| Gruppo di sottoreti | Sì | Sì |
| gruppo di replica | Sì | Sì |
| cluster | Sì | Sì |
| Istanza riservata | Sì | Sì |
| serverlesscachesnapshot | Sì | Sì |
| snapshot | Sì | Sì |
| user | Sì | Sì |
| gruppo utenti | Sì | Sì |
**Nota**
Non è possibile assegnare tag ai Global Datastore.
Puoi applicare autorizzazioni a livello di risorsa basate su tag nelle tue policy IAM alle azioni ElastiCache API che supportano l'etichettatura alla creazione per implementare il controllo granulare sugli utenti e i gruppi che possono taggare le risorse al momento della creazione. Le risorse vengono adeguatamente protette dalla creazione, ovvero tag che vengono applicati immediatamente alle risorse. Pertanto qualsiasi autorizzazione basata su tag a livello di risorsa che controlla l'uso delle risorse risulta immediatamente valida. Le risorse possono essere monitorate e segnalate con maggiore precisione. Puoi applicare l'uso del tagging alle nuove risorse e controllare quali chiavi e valori di tag sono impostati per le risorse.
Per ulteriori informazioni, consulta [Esempio: assegnazione di tag alle risorse](#Tagging-your-resources-example).
Per ulteriori informazioni sul tagging delle risorse per la fatturazione, vedere [Monitoraggio dei costi con i tag di allocazione dei costi](Tagging.md).
## Applicazione di tag a cache e snapshot
Le seguenti regole si applicano alle etichette come parte delle operazioni di richiesta:
+ **CreateReplicationGroup**:
+ Se i `--tags` parametri `--primary-cluster-id` and sono inclusi nella richiesta, i tag di richiesta verranno aggiunti al gruppo di replica e propagati a tutti i cluster del gruppo di replica. Se il cluster primario dispone di tag esistenti, questi verranno sovrascritti con i tag di richiesta per avere tag coerenti su tutti i nodi.
Se non sono presenti tag di richiesta, i tag del cluster primario verranno aggiunti al gruppo di replica e propagati a tutti i cluster.
+ Se si specifica `--snapshot-name` o `--serverless-cache-snapshot-name`:
Se i tag sono inclusi nella richiesta, il gruppo di replica viene contrassegnato solo con tali tag. Se nella richiesta non sono inclusi tag, i tag dello snapshot vengono aggiunti al gruppo di replica.
+ Se il file `--global-replication-group-id` viene fornito:
Se i tag sono inclusi nella richiesta, i tag di richiesta verranno aggiunti al gruppo di replica e si propagheranno a tutti i cluster.
+ **CreateCacheCluster** :
+ Se il file `--replication-group-id` viene fornito:
Se i tag sono inclusi nella richiesta, il cluster verrà taggato solo con tali tag. Se nella richiesta non sono inclusi tag, il cluster erediterà i tag del gruppo di replica anziché i tag del cluster primario.
+ Se il file `--snapshot-name` viene fornito:
Se i tag sono inclusi nella richiesta, il cluster verrà taggato solo con tali tag. Se nella richiesta non sono inclusi tag, i tag snapshot verranno aggiunti al cluster.
+ **CreateServerlessCache** :
+ Se i tag sono inclusi nella richiesta, solo i tag della richiesta vengono aggiunti alla cache serverless.
+ **CreateSnapshot** :
+ Se il file `--replication-group-id` viene fornito:
Se i tag sono inclusi nella richiesta, solo i tag di richiesta verranno aggiunti allo snapshot. Se nella richiesta non sono inclusi tag, i tag del gruppo di replica verranno aggiunti allo snapshot.
+ Se il file `--cache-cluster-id` viene fornito:
Se i tag sono inclusi nella richiesta, solo i tag di richiesta verranno aggiunti allo snapshot. Se nella richiesta non sono inclusi tag, i tag del cluster verranno aggiunti allo snapshot.
+ Snapshot automatiche
I tag verranno propagati dai tag del gruppo di replica.
+ **CreateServerlessCacheSnapshot** :
+ Se i tag sono inclusi nella richiesta, solo i tag della richiesta vengono aggiunti allo snapshot della cache serverless.
+ **CopySnapshot** :
+ Se i tag sono inclusi nella richiesta, solo i tag di richiesta verranno aggiunti allo snapshot. Se nella richiesta non sono inclusi tag, i tag snapshot di fonte verranno aggiunti allo snapshot copiato.
+ **CopyServerlessCacheSnapshot** :
+ Se i tag sono inclusi nella richiesta, solo i tag della richiesta vengono aggiunti allo snapshot della cache serverless.
+ **AddTagsToResource**e **RemoveTagsFromResource**:
+ I tag verranno generati added/removed dal gruppo di replica e l'azione verrà propagata a tutti i cluster del gruppo di replica.
**Nota**
**AddTagsToResource**e **RemoveTagsFromResource**non può essere utilizzato per parametri e gruppi di sicurezza predefiniti.
+ **IncreaseReplicaCount**e **ModifyReplicationGroupShardConfiguration**:
+ A tutti i nuovi cluster aggiunti al gruppo di replica vengono applicati gli stessi tag del gruppo di replica.
## Limitazioni applicate ai tag
Ai tag si applicano le seguenti limitazioni di base:
+ Numero massimo di tag per risorsa: 50
+ Per ogni risorsa, ogni chiave di tag deve essere unica e ogni chiave di tag può avere un solo valore.
+ La lunghezza massima della chiave è 128 caratteri Unicode in formato UTF-8.
+ La lunghezza massima del valore è 256 caratteri Unicode in formato UTF-8.
+ Sebbene ElastiCache consenta qualsiasi carattere nei tag, altri servizi possono essere restrittivi. I caratteri consentiti nei servizi sono: lettere, numeri e spazi rappresentabili in formato UTF-8 e i seguenti caratteri speciali \$1 – = . \$1 : / @.
+ Per le chiavi e i valori dei tag viene fatta la distinzione tra maiuscole e minuscole.
+ Il `aws:` prefisso è riservato all'uso AWS. Se il tag ha una chiave di tag con questo prefisso, non puoi modificare o eliminare la chiave o il valore de tag. I tag con il prefisso `aws:` non vengono conteggiati per il limite del numero di tag per risorsa.
Non puoi interrompere, arrestare o eliminare una risorsa solo sulla base dei relativi tag. Devi specificare il relativo identificatore. Ad esempio, per eliminare gli snapshot associato a una chiave di tag denominata `DeleteMe`, devi utilizzare l'operazione `DeleteSnapshot` con gli identificatori di risorsa degli snapshot, ad esempio `snap-1234567890abcdef0`.
Per ulteriori informazioni sulle ElastiCache risorse che puoi taggare, consulta[Risorse cui è possibile associare tag](#Tagging-your-resources).
## Esempio: assegnazione di tag alle risorse
+ Creazione di una cache serverless utilizzando i tag. Questo esempio utilizza Memcached come motore.
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine memcached
--tags Key="Cost Center", Value="1110001" Key="project",Value="XYZ"
```
+ Aggiunta di tag a una cache serverless
```
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"
```
+ Aggiunta di tag a un gruppo di replica.
```
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"
```
+ Creazione di un cluster di cache con i tag.
```
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"
```
+ Creazione di un cluster di cache con i tag. Questo esempio utilizza Redis come motore.
```
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"
```
+ Creazione di uno snapshot serverless con tag Questo esempio utilizza Memcached come motore.
```
aws elasticache create-serverless-cache-snapshot \
--serverless-cache-name testing-tags \
--serverless-cache-snapshot-name bkp-testing-tags-scs \
--tags Key="work",Value="foo"
```
+ Esempio: creazione di uno snapshot con tag
Le istantanee sono attualmente disponibili solo per Redis. In questo caso, se si aggiungono tag su richiesta, anche se il gruppo di replica contiene tag, lo snapshot riceverà solo i tag di richiesta.
```
aws elasticache create-snapshot \
--replication-group-id testing-tags \
--snapshot-name bkp-testing-tags-rg \
--tags Key="work",Value="foo"
```
## Esempi di policy di controllo degli accessi basati sui tag
1. Consentire l’operazione `AddTagsToResource` a un cluster solo se il cluster ha il tag Project=XYZ.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:cluster:*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "XYZ"
}
}
}
]
}
```
------
1. Consentire l’operazione `RemoveTagsFromResource` da un gruppo di replica se contiene i tag progetto e servizio e le chiavi sono diverse da Project e Service.
------
#### [ 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. Consentire `AddTagsToResource` a qualsiasi risorsa solo se i tag sono diversi da progetto e servizio.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:*:*"
],
"Condition": {
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Service",
"Project"
]
}
}
}
]
}
```
------
1. Negare l’operazione `CreateReplicationGroup` se la richiesta ha `Tag Project=Foo`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "elasticache:CreateReplicationGroup",
"Resource": [
"arn:aws:elasticache:*:*:replicationgroup:*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "Foo"
}
}
}
]
}
```
------
1. Negare l’operazione `CopySnapshot` se lo snapshot di fonte ha tag project=xyz e il tag request è Service=Elasticache.
------
#### [ 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. Rifiuto dell’azione `CreateCacheCluster` se il tag della richiesta `Project` manca o è diverso da `Dev`, `QA` o `Prod`.
------
#### [ 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"
]
}
}
}
]
}
```
------
Per informazioni correlate sulle chiavi di condizione, consulta [Utilizzo delle chiavi di condizione](IAM.ConditionKeys.md).
# Monitoraggio dei costi con i tag di allocazione dei costi
Quando aggiungi tag di allocazione dei costi alle tue risorse in Amazon ElastiCache, puoi tenere traccia dei costi raggruppando le spese sulle fatture in base ai valori dei tag di risorsa.
Un tag di allocazione ElastiCache dei costi è una coppia chiave-valore che definisci e associ a una risorsa. ElastiCache La chiave e il valore fanno distinzione tra maiuscole e minuscole. Puoi utilizzare una chiave di tag per definire una categoria e il valore come una voce di tale categoria. Ad esempio, puoi definire una chiave di tag `CostCenter` e un valore di tag `10010`, a indicare che la risorsa è assegnata al centro di costo 10010. È anche possibile usare i tag per indicare le risorse come risorse utilizzate a scopo di test o produzione tramite una chiave, ad esempio `Environment`, e tramite valori, ad esempio `test` o `production`. È consigliabile utilizzare un set coerente di chiavi di tag per agevolare il monitoraggio dei costi associati alle risorse.
Utilizzate i tag di allocazione dei costi per organizzare la AWS fattura in modo da rispecchiare la vostra struttura dei costi. A tale scopo, registrati per ricevere una fattura sul tuo AWS account con i valori chiave dell'etichetta inclusi. Per visualizzare il costo delle risorse combinate, puoi organizzare le informazioni di fatturazione in base alle risorse con gli stessi valori di chiave di tag. Puoi ad esempio applicare tag a numerose risorse con un nome di applicazione specifico, quindi organizzare le informazioni di fatturazione per visualizzare il costo totale dell'applicazione in più servizi.
Puoi anche combinare i tag per monitorare i costi con un livello di dettagli maggiore. Ad esempio, per monitorare i costi di servizio per regione, puoi utilizzare le chiavi di tag `Service` e `Region`. Su una risorsa potresti avere i valori `ElastiCache` e `Asia Pacific (Singapore)`, mentre su un'altra risorsa potresti avere i valori `ElastiCache` e `Europe (Frankfurt)`. Potrai quindi visualizzare i ElastiCache costi totali suddivisi per regione. Per ulteriori informazioni, consulta la pagina sull'[utilizzo dei tag per l'allocazione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) nella *Guida per l'utente di AWS Billing*.
È possibile aggiungere tag di allocazione ElastiCache dei costi ai cluster basati ElastiCache su nodi. Quando aggiungi, elenchi, modifichi, copi o rimuovi un tag, l'operazione viene applicata solo al cluster specificato.
**Caratteristiche dei tag di allocazione dei costi ElastiCache**
+ I tag di allocazione dei costi vengono applicati alle ElastiCache risorse specificate nelle operazioni CLI e API come ARN. Il tipo di risorsa sarà un cluster.
ARN di esempio: `arn:aws:elasticache::::`
Arn di esempio`arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
+ La chiave di tag corrisponde al nome obbligatorio del tag. Il valore della stringa della chiave può essere composto da 1 a 128 caratteri Unicode e non può avere il prefisso `aws:`. La stringa può contenere solo il set di lettere, numeri, spazi vuoti, caratteri di sottolineatura (\$1), punti (.), virgole (:), barre rovesciate (\$1), segni di uguale (=), più (\$1), trattini (-) o chiocciole (@).
+ Un valore tag è il valore opzionale del tag. Il valore di stringa del valore può essere composto da 1 a 256 caratteri Unicode e non può avere il prefisso `aws:`. La stringa può contenere solo il set di lettere, numeri, spazi vuoti, caratteri di sottolineatura (\$1), punti (.), virgole (:), barre rovesciate (\$1), segni di uguale (=), più (\$1), trattini (-) o chiocciole (@).
+ Una ElastiCache risorsa può avere un massimo di 50 tag.
+ I valori non devono essere necessariamente univoci in un set di tag. Ad esempio, puoi avere un set di tag dove le chiavi `Service` e `Application` hanno entrambe il valore `ElastiCache`.
AWS non applica alcun significato semantico ai tag. I tag vengono interpretati rigorosamente come stringhe di caratteri.AWS non imposta automaticamente alcun tag su nessuna ElastiCache risorsa.
# Gestione dei tag di allocazione dei costi utilizzando AWS CLI
È possibile utilizzare i AWS CLI per aggiungere, modificare o rimuovere i tag di allocazione dei costi.
I tag di allocazione dei costi vengono applicati ai cluster. ElastiCache Il cluster a cui aggiungere tag viene specificato mediante un Amazon Resource Name (ARN).
Arn di esempio`arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [Elencare i tag utilizzando il AWS CLI](#Tagging.Managing.CLI.List)
+ [Aggiungere tag utilizzando il AWS CLI](#Tagging.Managing.CLI.Add)
+ [Modifica dei tag utilizzando il AWS CLI](#Tagging.Managing.CLI.Modify)
+ [Rimuovere i tag utilizzando il AWS CLI](#Tagging.Managing.CLI.Remove)
## Elencare i tag utilizzando il AWS CLI
È possibile utilizzare il AWS CLI per elencare i tag su una ElastiCache risorsa esistente utilizzando l'[list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html)operazione.
Il codice seguente utilizza AWS CLI per elencare i tag sul cluster Memcached `my-cluster` nella regione us-west-2.
Per Linux, macOS o Unix:
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
Per Windows:
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
Il codice seguente utilizza AWS CLI per elencare i tag sul nodo Valkey o Redis OSS `my-cluster-001` nel `my-cluster` cluster nella regione us-west-2.
Per Linux, macOS o Unix:
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
Per Windows:
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
L'output di questa operazione sarà simile al seguente, una lista di tutti i tag sulla risorsa.
```
{
"TagList": [
{
"Value": "10110",
"Key": "CostCenter"
},
{
"Value": "EC2",
"Key": "Service"
}
]
}
```
Se non ci sono tag sulla risorsa, l'output sarà vuoto. TagList
```
{
"TagList": []
}
```
Per ulteriori informazioni, consulta AWS CLI il modulo ElastiCache [list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html).
## Aggiungere tag utilizzando il AWS CLI
È possibile utilizzare AWS CLI per aggiungere tag a una ElastiCache risorsa esistente utilizzando l'operazione [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html) CLI. Se la nuova chiave di tag non esiste sulla risorsa, la chiave e il valore vengono aggiunti alla risorsa. Se la chiave esiste già sulla risorsa, il valore associato a quella chiave viene aggiornato al nuovo valore.
Il codice seguente utilizza AWS CLI per aggiungere le chiavi `Service` e `Region` con i valori `elasticache` e `us-west-2` rispettivamente al nodo `my-cluster-001` nel cluster `my-cluster` nella regione us-west-2.
**Memcached**
Per Linux, macOS o 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
```
Per 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**
Per Linux, macOS o 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
```
Per 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
```
L'output di questa operazione sarà simile al seguente, una lista di tutti i tag sulla risorsa in base all'operazione.
```
{
"TagList": [
{
"Value": "elasticache",
"Key": "Service"
},
{
"Value": "us-west-2",
"Key": "Region"
}
]
}
```
Per ulteriori informazioni, consulta il AWS CLI modulo. ElastiCache [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html)
È inoltre possibile utilizzare il AWS CLI per aggiungere tag a un cluster quando si crea un nuovo cluster utilizzando l'operazione[create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html). Non è possibile aggiungere tag quando si crea un cluster utilizzando la console ElastiCache di gestione. Dopo aver creato il cluster, puoi quindi utilizzare la console per aggiungere i tag al cluster.
## Modifica dei tag utilizzando il AWS CLI
È possibile utilizzare il AWS CLI per modificare i tag su un ElastiCache cluster.
Per modificare i tag:
+ Utilizzare [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html) per aggiungere un nuovo tag e valore o per modificare il valore associato a un tag esistente.
+ Utilizzare [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html) per rimuovere i tag specificati dalla risorsa.
L'output da entrambe le operazioni sarà un elenco di tag e i relativi valori sul cluster specificato.
## Rimuovere i tag utilizzando il AWS CLI
È possibile utilizzare AWS CLI per rimuovere i tag da un cluster ElastiCache for Memcached esistente utilizzando l'[remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html)operazione.
Per Memcached, il codice seguente utilizza AWS CLI per rimuovere i tag con le chiavi `Service` e `Region` dal nodo `my-cluster-001` nel cluster `my-cluster` nella regione us-west-2.
Per Linux, macOS o Unix:
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster \
--tag-keys PM Service
```
Per Windows:
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster ^
--tag-keys PM Service
```
Per Redis OSS, il codice seguente utilizza AWS CLI per rimuovere i tag con le chiavi `Service` e `Region` dal nodo `my-cluster-001` nel cluster `my-cluster` nella regione us-west-2.
Per Linux, macOS o Unix:
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 \
--tag-keys PM Service
```
Per Windows:
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 ^
--tag-keys PM Service
```
L'output di questa operazione sarà simile al seguente, una lista di tutti i tag sulla risorsa in base all'operazione.
```
{
"TagList": []
}
```
Per ulteriori informazioni, consulta il modulo. AWS CLI ElastiCache [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html)
# Gestione dei tag di allocazione dei costi tramite l'API ElastiCache
È possibile utilizzare l' ElastiCache API per aggiungere, modificare o rimuovere i tag di allocazione dei costi.
I tag di allocazione dei costi vengono applicati ai cluster ElastiCache Memcached. Il cluster a cui aggiungere tag viene specificato mediante un Amazon Resource Name (ARN).
Arn di esempio`arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [Elencare i tag utilizzando l'API ElastiCache](#Tagging.Managing.API.List)
+ [Aggiungere tag utilizzando l'API ElastiCache](#Tagging.Managing.API.Add)
+ [Modifica dei tag tramite l'API ElastiCache](#Tagging.Managing.API.Modify)
+ [Rimozione dei tag tramite l' ElastiCache API](#Tagging.Managing.API.Remove)
## Elencare i tag utilizzando l'API ElastiCache
È possibile utilizzare l' ElastiCache API per elencare i tag su una risorsa esistente utilizzando l'[ListTagsForResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListTagsForResource.html)operazione.
Per Memcached, il codice seguente utilizza l' ElastiCache API per elencare i tag sulla risorsa `my-cluster` nella regione us-west-2.
```
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=
```
Per Redis OSS, il codice seguente utilizza l' ElastiCache API per elencare i tag sulla risorsa `my-cluster-001` nella regione us-west-2.
```
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=
```
## Aggiungere tag utilizzando l'API ElastiCache
È possibile utilizzare l' ElastiCache API per aggiungere tag a un ElastiCache cluster esistente utilizzando l'[AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html)operazione. Se la nuova chiave di tag non esiste sulla risorsa, la chiave e il valore vengono aggiunti alla risorsa. Se la chiave esiste già sulla risorsa, il valore associato a quella chiave viene aggiornato al nuovo valore.
Il codice seguente utilizza l' ElastiCache API per aggiungere le chiavi `Service` e `Region` con i valori `elasticache` e `us-west-2` rispettivamente. Per Memcached, questo viene applicato alla risorsa. `my-cluster` Per Redis OSS, questo viene applicato alla risorsa `my-cluster-001` nella regione us-west-2.
**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=
```
Per ulteriori informazioni, [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) consulta *Amazon ElastiCache API Reference*.
## Modifica dei tag tramite l'API ElastiCache
È possibile utilizzare l' ElastiCache API per modificare i tag su un ElastiCache cluster.
Per modificare il valore di un tag:
+ Utilizzare l'operazione [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) per aggiungere un nuovo tag e valore o per modificare il valore associato a un tag esistente.
+ Utilizzare [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) per rimuovere i tag dalla risorsa.
L'output da entrambe le operazioni sarà un elenco di tag e dei relativi valori sulla risorsa specificata.
Utilizzare [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) per rimuovere i tag dalla risorsa.
## Rimozione dei tag tramite l' ElastiCache API
È possibile utilizzare l' ElastiCache API per rimuovere i tag da un cluster ElastiCache for Memcached esistente utilizzando l'[RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html)operazione.
Il codice seguente utilizza l' ElastiCache API per rimuovere i tag con le chiavi `Service` e `Region` dal nodo `my-cluster-001` nel cluster `my-cluster` nella regione us-west-2.
```
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=
```
# Utilizzo dell'obiettivo Amazon ElastiCache Well-Architected
Questa sezione descrive Amazon ElastiCache Well-Architected Lens, una raccolta di principi di progettazione e linee guida per la progettazione di carichi di lavoro ben architettati. ElastiCache
+ The ElastiCache Lens è complementare al [AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) Framework.
+ Ogni pilastro ha una serie di domande per aiutare a iniziare la discussione su un'architettura. ElastiCache
+ Ogni domanda contiene una serie di procedure principali insieme ai relativi punteggi per la segnalazione.
+ *Obbligatorio*: la procedura obbligatoria prima di passare in produzione (se non viene eseguita comporta un alto rischio)
+ *Best practice*: la migliore procedura per un cliente
+ *Consigliato*: la procedura consigliata ai clienti (se non viene eseguita comporta un rischio medio)
+ Terminologia di Well-Architected
+ [Componente](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html): codice, configurazione e AWS risorse che insieme soddisfano un requisito. I componenti interagiscono con altri componenti e spesso equivalgono a un servizio nelle architetture di microservizi.
+ [Carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html): un set di componenti che insieme forniscono valore aziendale. Esempi di carichi di lavoro sono siti Web di marketing, siti Web di e-commerce, il back-end di un'app per dispositivi mobili, piattaforme di analisi e così via.
**Nota**
Questa guida non è stata aggiornata per includere informazioni sulla memorizzazione nella cache ElastiCache serverless e sul nuovo motore Valkey.
**Topics**
+ [Pilastro dell'eccellenza operativa di Amazon ElastiCache Well-Architected Lens](OperationalExcellencePillar.md)
+ [Pilastro della sicurezza delle ElastiCache lenti Amazon Well-Architected](SecurityPillar.md)
+ [Pilastro dell'affidabilità delle ElastiCache lenti Amazon Well-Architected](ReliabilityPillar.md)
+ [Pilastro dell'efficienza delle prestazioni delle lenti Amazon ElastiCache Well-Architected](PerformanceEfficiencyPillar.md)
+ [Pilastro dell'ottimizzazione dei costi delle lenti Amazon ElastiCache Well-Architected](CostOptimizationPillar.md)
# Pilastro dell'eccellenza operativa di Amazon ElastiCache Well-Architected Lens
Il pilastro dell'eccellenza operativa si concentra sull'esecuzione e sul monitoraggio dei sistemi per fornire valore aziendale e migliorare continuamente processi e procedure. Gli argomenti chiave includono l'automazione delle modifiche, la risposta agli eventi e la definizione degli standard per gestire le operazioni quotidiane.
**Topics**
+ [OE 1: Come comprendi e rispondi agli avvisi e agli eventi generati dal tuo cluster? ElastiCache](#OperationalExcellencePillarOE1)
+ [OE 2: Quando e come ridimensionate i cluster esistenti? ElastiCache](#OperationalExcellencePillarOE2)
+ [OE 3: Come gestisci ElastiCache le risorse e la manutenzione del cluster up-to-date?](#OperationalExcellencePillarOE3)
+ [OE 4: Come gestite le connessioni dei clienti ai vostri ElastiCache cluster?](#OperationalExcellencePillarOE4)
+ [OE 5: Come si distribuiscono ElastiCache i componenti per un carico di lavoro?](#OperationalExcellencePillarOE5)
+ [EO 6: come si pianificano e si contengono gli errori?](#OperationalExcellencePillarOE6)
+ [OE 7: Come si risolvono gli eventi del motore Valkey o Redis OSS?](#OperationalExcellencePillarOE7)
## OE 1: Come comprendi e rispondi agli avvisi e agli eventi generati dal tuo cluster? ElastiCache
**Introduzione a livello di domanda:** quando gestisci ElastiCache i cluster, puoi facoltativamente ricevere notifiche e avvisi quando si verificano eventi specifici. ElastiCache, per impostazione predefinita, registra [gli eventi](ECEvents.md) relativi alle risorse, come il failover, la sostituzione dei nodi, le operazioni di scalabilità, la manutenzione programmata e altro ancora. Ogni evento include la data e l'ora, il nome e il tipo di origine e una descrizione.
**Vantaggio della domanda: **la capacità di comprendere e gestire i motivi alla base degli eventi che generano gli avvisi del cluster consente di operare in modo più efficace e di rispondere agli eventi in modo appropriato.
+ **[Obbligatorio]** [Esamina gli eventi generati da ElastiCache sulla ElastiCache console (dopo aver selezionato la regione) o utilizzando il [comando describe-events di Amazon Command Line Interface](https://aws.amazon.com/cli)[(AWS CLI) e l'API](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html). ElastiCache ](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html) Configura ElastiCache l'invio di notifiche per importanti eventi del cluster utilizzando Amazon Simple Notification Service (Amazon SNS). L'uso di Amazon SNS con i tuoi cluster ti consente di intraprendere azioni programmatiche sugli eventi. ElastiCache
+ Esistono due grandi categorie di eventi: eventi attuali e programmati. L'elenco degli eventi correnti include: creazione ed eliminazione delle risorse, operazioni di dimensionamento, failover, riavvio del nodo, creazione di snapshot, modifica dei parametri del cluster, rinnovo del certificato CA, eventi di errore (errore di provisioning del cluster per VPC o ENI, errori di dimensionamento per ENI ed errori di snapshot). L'elenco degli eventi pianificati include: nodo programmato per la sostituzione durante la finestra di manutenzione e sostituzione del nodo riprogrammata.
+ Sebbene non sia necessario reagire immediatamente ad alcuni di questi eventi, è fondamentale esaminare tutti gli eventi di errore:
+ ElastiCache:AddCacheNodeFailed
+ ElastiCache:CacheClusterProvisioningFailed
+ ElastiCache:CacheClusterScalingFailed
+ ElastiCache:CacheNodesRebooted
+ ElastiCache: SnapshotFailed (solo Valkey o Redis OSS)
+ **[Risorse]:**
+ [Gestione delle ElastiCache notifiche Amazon SNS](ECEvents.SNS.md)
+ [Notifiche di eventi Amazon SNS](ElastiCacheSNS.md)
+ **[Ideale]** Per automatizzare le risposte agli eventi, sfrutta le funzionalità di AWS prodotti e servizi come SNS e Lambda Functions. Segui le best practice apportando modifiche piccole, frequenti e reversibili, come codice per migliorare le tue operazioni nel tempo. È necessario utilizzare i CloudWatch parametri di Amazon per monitorare i cluster.
**[Risorse]:** [Monitora ElastiCache (modalità cluster disabilitata) leggi gli endpoint di replica utilizzando AWS Lambda, Amazon Route 53 e Amazon SNS per un caso d'uso che utilizza Lambda e SNS](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/).
## OE 2: Quando e come ridimensionate i cluster esistenti? ElastiCache
**Introduzione a livello di domanda: il corretto** dimensionamento del ElastiCache cluster è un atto di bilanciamento che deve essere valutato ogni volta che vengono apportate modifiche ai tipi di carico di lavoro sottostanti. Il tuo obiettivo è operare con l'ambiente delle dimensioni giuste per il tuo carico di lavoro.
**Vantaggio della domanda: **l'eccessivo utilizzo delle risorse può comportare una latenza elevata e una riduzione complessiva delle prestazioni. Il sottoutilizzo, invece, può comportare un sovradimensionamento delle risorse a fronte di un'ottimizzazione dei costi non ottimale. Dimensionando correttamente gli ambienti, è possibile trovare un equilibrio tra efficienza delle prestazioni e ottimizzazione dei costi. Per rimediare all'utilizzo eccessivo o insufficiente delle risorse, è possibile scalare in due dimensioni. ElastiCache È possibile dimensionare verticalmente aumentando o diminuendo la capacità del nodo. Puoi anche dimensionare orizzontalmente aggiungendo e rimuovendo nodi.
+ **[Obbligatorio]** L'eccessivo utilizzo della CPU e della rete sui nodi primari deve essere risolto determinando e reindirizzando le operazioni di lettura ai nodi di replica. Usa i nodi di replica per le operazioni di lettura per ridurre l'utilizzo dei nodi primari. Questo può essere configurato nella libreria client Valkey o Redis OSS collegandosi all'endpoint del ElastiCache lettore per disattivare la modalità cluster o utilizzando il comando READONLY per abilitare la modalità cluster.
**[Risorse]:**
+ [Ricerca degli endpoint di connessione in ElastiCache](Endpoints.md)
+ [Cluster Right-Sizing](https://aws.amazon.com/blogs/database/five-workload-characteristics-to-consider-when-right-sizing-amazon-elasticache-redis-clusters/)
+ [Comando READONLY](https://valkey.io/commands/readonly)
+ **[Obbligatorio]** Monitora l'utilizzo delle risorse critiche del cluster come CPU, memoria e rete. L'utilizzo di queste risorse specifiche del cluster deve essere monitorato per determinare la decisione e il tipo di operazione di dimensionamento. Se la modalità ElastiCache cluster è disattivata, i nodi primari e di replica possono essere scalati verticalmente. I nodi di replica possono anche dimensionare orizzontalmente da 0 a 5 nodi. Per la modalità cluster abilitata, lo stesso vale per ogni partizione del cluster. Inoltre, puoi aumentare o ridurre il numero di partizioni.
**[Risorse]:**
+ [Monitoraggio delle best practice con ElastiCache l'utilizzo di Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [Scalabilità dei ElastiCache cluster per Valkey e Redis OSS](Scaling.md)
+ [Scalabilità dei cluster per Memcached ElastiCache ](Scaling.md)
+ **[Best practice]** Il monitoraggio delle tendenze nel tempo può aiutarti a rilevare i cambiamenti del carico di lavoro che rimarrebbero inosservati se monitorati solo in un determinato momento. Per rilevare tendenze a lungo termine, utilizza le CloudWatch metriche per scansionare intervalli di tempo più lunghi. Gli insegnamenti derivanti dall'osservazione di lunghi periodi di CloudWatch metriche dovrebbero contribuire alla previsione sull'utilizzo delle risorse del cluster. CloudWatch i punti dati e le metriche sono disponibili per un massimo di 455 giorni.
**[Risorse]:**
+ [Monitoraggio ElastiCache con metriche CloudWatch](CacheMetrics.md)
+ [Monitoraggio di Memcached con metriche CloudWatch ](CacheMetrics.md)
+ [Monitoraggio delle best practice con ElastiCache l'utilizzo di Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Migliore]** Se le ElastiCache risorse sono create con CloudFormation questo, è consigliabile apportare modifiche utilizzando CloudFormation modelli per preservare la coerenza operativa ed evitare modifiche non gestite alla configurazione e derive dello stack.
**[Risorse]:**
+ [ElastiCache riferimento al tipo di risorsa per CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ **[Ideale]** Automatizza le operazioni di scalabilità utilizzando i dati operativi del cluster e definisci le soglie per configurare gli allarmi. CloudWatch Usa CloudWatch Events and Simple Notification Service (SNS) per attivare le funzioni Lambda ed eseguire un' ElastiCache API per scalare automaticamente i cluster. Un esempio potrebbe essere aggiungere una partizione al cluster quando la metrica `EngineCPUUtilization` raggiunge l'80% per un lungo periodo di tempo. Un'altra opzione potrebbe essere utilizzare `DatabaseMemoryUsedPercentages` per una soglia basata sulla memoria.
**[Risorse]:**
+ [Utilizzo di Amazon CloudWatch Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Cosa sono CloudWatch gli eventi Amazon?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Utilizzo AWS Lambda con Amazon Simple Notification Service](https://docs.aws.amazon.com/lambda/latest/dg/with-sns.html)
+ [Riferimento APIElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
## OE 3: Come gestisci ElastiCache le risorse e la manutenzione del cluster up-to-date?
**Introduzione a livello di domanda:** quando si opera su larga scala, è essenziale essere in grado di individuare e identificare tutte le risorse. ElastiCache Quando si implementano nuove funzionalità applicative, è necessario creare una simmetria tra le versioni del cluster in tutti i tipi di ElastiCache ambiente: sviluppo, test e produzione. Gli attributi delle risorse consentono di separare gli ambienti per diversi obiettivi operativi, ad esempio quando si implementano nuove funzionalità e si abilitano nuovi meccanismi di sicurezza.
**Vantaggio della domanda:** la separazione degli ambienti di sviluppo, test e produzione è una best practice operativa. È inoltre consigliabile che ai cluster e ai nodi in tutti gli ambienti vengano applicate le patch software più recenti utilizzando i processi appresi e documentati. Lo sfruttamento delle ElastiCache funzionalità native consente al team di progettazione di concentrarsi sul raggiungimento degli obiettivi aziendali e non sulla ElastiCache manutenzione.
+ **[Ottimale]** Esegui l'ultima versione del motore disponibile e applica gli aggiornamenti self-service non appena sono disponibili. ElastiCache aggiorna automaticamente l'infrastruttura sottostante durante la finestra di manutenzione specificata del cluster. Tuttavia, i nodi in esecuzione nei cluster vengono aggiornati tramite aggiornamenti self-service. Questi aggiornamenti possono essere di due tipi: patch di sicurezza o aggiornamenti software secondari. Assicurati di comprendere la differenza tra i tipi di patch e quando vengono applicate.
**[Risorse]:**
+ [Aggiornamenti self-service in Amazon ElastiCache](Self-Service-Updates.md)
+ [Pagina di aiuto Amazon ElastiCache Managed Maintenance and Service Updates](https://aws.amazon.com/elasticache/elasticache-maintenance/)
+ **[Ottimale]** Organizza ElastiCache le tue risorse utilizzando i tag. Usa i tag sui gruppi di replica e non sui singoli nodi. È possibile configurare i tag in modo che vengano visualizzati quando si eseguono query sulle risorse e utilizzare i tag per eseguire ricerche e applicare filtri. È consigliabile utilizzare i gruppi di risorse per creare e gestire facilmente le raccolte di risorse che condividono set di tag comuni.
**[Risorse]:**
+ [Tagging Best Practices](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf)
+ [ElastiCache riferimento al tipo di risorsa per CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [Gruppi di parametri](ParameterGroups.Engine.md#ParameterGroups.Redis)
## OE 4: Come gestite le connessioni dei clienti ai vostri ElastiCache cluster?
**Introduzione a livello di domanda:** quando si opera su larga scala, è necessario comprendere in che modo i clienti si connettono al ElastiCache cluster per gestire gli aspetti operativi dell'applicazione (come i tempi di risposta).
**Vantaggio della domanda:** la scelta del meccanismo di connessione più appropriato garantisce che l'applicazione non si disconnetta a causa di errori di connettività, come i timeout.
+ **[Obbligatorio]** Separa le operazioni di lettura da quelle di scrittura e connettiti ai nodi di replica per eseguire le operazioni di lettura. Tuttavia, tieni presente che quando separi le scritture dalle letture perderai la capacità di leggere una chiave subito dopo averla scritta a causa della natura asincrona della replica di Valkey e Redis OSS. Il comando WAIT può essere utilizzato per migliorare la sicurezza dei dati nel mondo reale e forzare le repliche a riconoscere le scritture prima di rispondere ai client, a un costo di prestazioni complessivo. L'utilizzo dei nodi di replica per le operazioni di lettura può essere configurato nella libreria ElastiCache client utilizzando l'endpoint reader per la modalità cluster disattivata. ElastiCache Per abilitare la modalità cluster, utilizzare il comando READONLY. Per molte librerie ElastiCache client, READONLY è implementato di default o tramite un'impostazione di configurazione.
**[Risorse]:**
+ [Ricerca degli endpoint di connessione in ElastiCache](Endpoints.md)
+ [READONLY](https://valkey.io/commands/readonly)
+ **[Obbligatorio] **Usa il pool di connessioni. La creazione di una connessione TCP comporta un costo in termini di tempo di CPU sia sul lato client che su quello server e il pool consente di riutilizzare la connessione TCP.
Per ridurre il sovraccarico della connessione, è necessario utilizzare il pool di connessioni. Con un pool di connessioni, l'applicazione può riutilizzare e rilasciare connessioni "secondo le necessità", senza il costo di stabilire la connessione. È possibile implementare il pool di connessioni tramite la libreria ElastiCache client (se supportata), con un Framework disponibile per l'ambiente applicativo, oppure crearlo da zero.
+ **[Best practice]** Assicurati che il timeout del socket del client sia impostato su almeno un secondo (rispetto al tipico valore predefinito "nessuno" in diversi client).
+ L'impostazione di un valore troppo basso può causare possibili timeout quando il carico del server è elevato. Se si imposta un valore troppo alto, l'applicazione può impiegare molto tempo per rilevare i problemi di connessione.
+ Controlla il volume delle nuove connessioni implementando il pool di connessioni nell'applicazione client. Ciò riduce la latenza e l'utilizzo della CPU necessari per aprire e chiudere le connessioni ed eseguire un handshake TLS se TLS è abilitato sul cluster.
**[Risorse]:** [configura ElastiCache per una maggiore](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/) disponibilità
+ **[Positivo]** L'utilizzo delle pipeline (quando i casi d'uso lo consentono) può aumentare significativamente le prestazioni.
+ Con le pipeline si riduce il Round-Trip Time (RTT) tra i client delle applicazioni e il cluster e le nuove richieste possono essere elaborate anche se il client non ha ancora letto le risposte precedenti.
+ Con le pipeline puoi inviare più comandi al server senza attendere le risposte e le conferme. L'aspetto negativo delle pipeline è che quando alla fine recuperi tutte le risposte in blocco, potrebbe essere restituito un errore che non è riscontrabile fino alla fine.
+ Implementa i metodi per riprovare le richieste quando viene restituito un errore che omette la richiesta non valida.
**[Risorse]:** [Redis pipelining](https://valkey.io/topics/pipelining/)
## OE 5: Come si distribuiscono ElastiCache i componenti per un carico di lavoro?
**Introduzione a livello di domanda:** ElastiCache gli ambienti possono essere distribuiti manualmente tramite la AWS console o programmaticamente tramite CLIAPIs, toolkit, ecc. Le best practice dell'eccellenza operativa suggeriscono di automatizzare le implementazioni tramite il codice ogni volta che è possibile. Inoltre, ElastiCache i cluster possono essere isolati in base al carico di lavoro o combinati per ottimizzare i costi.
**Vantaggio a livello di domanda:** la scelta del meccanismo di implementazione più appropriato per i propri ElastiCache ambienti può migliorare Operation Excellence nel tempo. Ti consigliamo di eseguire operazioni sotto forma di codice ogni volta che è possibile per ridurre al minimo l'errore umano e aumentare la ripetibilità, la flessibilità e i tempi di risposta agli eventi.
Comprendendo i requisiti di isolamento del carico di lavoro, puoi scegliere di avere ElastiCache ambienti dedicati per carico di lavoro o combinare più carichi di lavoro in singoli cluster o combinazioni di essi. Comprendere i compromessi può aiutare a trovare un equilibrio tra eccellenza operativa e ottimizzazione dei costi.
+ **[Obbligatorio]** Comprendi le opzioni di implementazione disponibili e automatizza queste procedure quando possibile. ElastiCache Le possibili vie di automazione includono CloudFormation AWS CLI/SDK e. APIs
**[Risorse]: **
+ [Riferimento al tipo di ElastiCache risorsa Amazon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [elasticache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html)
+ [Riferimento alle ElastiCache API Amazon](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
+ **[Obbligatorio]** Per tutti i carichi di lavoro, determina il livello di isolamento del cluster necessario.
+ **[Best practice]:** isolamento elevato, una mappatura 1:1 del carico di lavoro ai cluster. Consente un controllo granulare su accesso, dimensionamento, scalabilità e gestione delle ElastiCache risorse in base al carico di lavoro.
+ **[Consigliato]:** isolamento medio, M:1 isolato per scopo ma forse condiviso tra più carichi di lavoro (ad esempio un cluster dedicato alla memorizzazione nella cache dei carichi di lavoro e un altro dedicato alla messaggistica).
+ **[Positivo]:** isolamento basso, M:1 tutti gli scopi e completamente condiviso. Consigliato per carichi di lavoro in cui è accettabile l'accesso condiviso.
## EO 6: come si pianificano e si contengono gli errori?
**Introduzione a livello di domanda: l'**eccellenza operativa include l'anticipazione dei guasti eseguendo regolarmente esercizi «pre-mortem» per identificare le potenziali fonti di guasto in modo che possano essere rimosse o mitigate. ElastiCache offre un'API di failover che consente la simulazione di eventi di guasto dei nodi a scopo di test.
**Vantaggio della domanda:** testando in anticipo gli scenari di errore, puoi scoprire in che modo influiscono sul tuo carico di lavoro. Ciò ti consente di testare in sicurezza le procedure di risposta e la loro efficacia, oltre a familiarizzare con l'esecuzione.
**[Obbligatorio]** Esegui regolarmente test di failover negli account di sviluppo/test. [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)
## OE 7: Come si risolvono gli eventi del motore Valkey o Redis OSS?
**Introduzione a livello di domanda: l'**eccellenza operativa richiede la capacità di esaminare le informazioni a livello di servizio e a livello di motore per analizzare lo stato e lo stato dei cluster. ElastiCache può emettere i log del motore Valkey o Redis OSS sia su Amazon che su Amazon Kinesis Data CloudWatch Firehose.
**Vantaggio a livello di domanda:** l'abilitazione dei log del motore Valkey o Redis OSS sui cluster fornisce informazioni sugli eventi che influiscono sullo stato e sulle prestazioni ElastiCache dei cluster. I log del motore Valkey o Redis OSS forniscono dati direttamente dal motore che non sono disponibili tramite il meccanismo degli eventi. ElastiCache Attraverso un'attenta osservazione sia degli ElastiCache eventi (vedere la precedente OE-1) che dei registri del motore, è possibile determinare un ordine degli eventi durante la risoluzione dei problemi sia dal punto di vista del servizio che dal punto di vista del motore. ElastiCache
+ **[Obbligatorio]** Assicuratevi che la funzionalità di registrazione del motore Redis OSS sia abilitata, disponibile a partire dalla ElastiCache versione 6.2 per Redis OSS e successive. Questa operazione può essere eseguita durante la creazione del cluster o modificando il cluster dopo la creazione.
+ Determina se Amazon CloudWatch Logs o Amazon Kinesis Data Firehose è la destinazione appropriata per i log del motore Redis OSS.
+ Seleziona un log di destinazione appropriato all'interno di uno CloudWatch o di Kinesis Data Firehose per rendere permanenti i log. Se disponi di più cluster, considera un log di destinazione diverso per ogni cluster, in quanto ciò contribuisce a isolare i dati per la risoluzione dei problemi.
**[Risorse]:**
+ Consegna dei registri: [Consegna dei registri](Log_Delivery.md)
+ Destinazioni di registrazione: [Amazon CloudWatch ](Logging-destinations.md#Destination_Specs_CloudWatch_Logs) Logs
+ Introduzione ad Amazon CloudWatch Logs: [cos'è Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)?
+ Introduzione ad Amazon Kinesis Data Firehose: [What Is Amazon Kinesis Data Firehose?](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
+ **[Migliore]** Se utilizzi Amazon CloudWatch Logs, valuta la possibilità di sfruttare Amazon CloudWatch Logs Insights per interrogare i log del motore Valkey o Redis OSS per ottenere informazioni importanti.
Ad esempio, crea una query sul gruppo CloudWatch Log che contiene i log del motore Valkey o Redis OSS che restituirà eventi con un LogLevel «AVVISO», ad esempio:
```
fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"
```
**[Risorse]:** [analisi dei dati di registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) con Logs Insights CloudWatch
# Pilastro della sicurezza delle ElastiCache lenti Amazon Well-Architected
Il pilastro della sicurezza si concentra sulla protezione delle informazioni e dei sistemi. Gli argomenti chiave includono la riservatezza e l'integrità dei dati, l'identificazione e la gestione di chi può fare cosa mediante la gestione basata su privilegi, la protezione dei sistemi e l'istituzione di controlli per rilevare gli eventi di sicurezza.
**Topics**
+ [SEC 1: Quali misure state adottando per controllare l'accesso autorizzato ai dati? ElastiCache](#SecurityPillarSEC1)
+ [SEC 2: Le vostre applicazioni richiedono un'autorizzazione aggiuntiva rispetto ai ElastiCache controlli basati sulla rete?](#SecurityPillarSEC2)
+ [SIC 3: esiste il rischio che i comandi possano essere eseguiti inavvertitamente, causando la perdita di dati o errori nei dati?](#SecurityPillarSEC3)
+ [SEC 4: Come si garantisce la crittografia inattiva dei dati con ElastiCache](#SecurityPillarSEC4)
+ [SEC 5: Come si crittografano i dati in transito? ElastiCache](#SecurityPillarSEC5)
+ [SIC 6: come si limita l'accesso alle risorse del piano di controllo (control-plane)?](#SecurityPillarSEC6)
+ [SIC 7: come si rileva e si risponde agli eventi di sicurezza?](#SecurityPillarSEC7)
## SEC 1: Quali misure state adottando per controllare l'accesso autorizzato ai dati? ElastiCache
**Introduzione a livello di domanda:** tutti i ElastiCache cluster sono progettati per essere accessibili da istanze di Amazon Elastic Compute Cloud in un VPC, funzioni serverless (AWS Lambda) o contenitori (Amazon Elastic Container Service). Lo scenario più comune consiste nell'accedere a un ElastiCache cluster da un'istanza Amazon Elastic Compute Cloud all'interno dello stesso Amazon Virtual Private Cloud (Amazon Virtual Private Cloud). Prima di poterti connettere a un cluster da un' EC2 istanza Amazon, devi autorizzare l' EC2 istanza Amazon ad accedere al cluster. Per accedere a un ElastiCache cluster in esecuzione in un VPC, è necessario concedere l'accesso alla rete al cluster.
**Vantaggio della domanda: **l'ingresso della rete nel cluster è controllato tramite i gruppi di sicurezza del VPC. Un gruppo di sicurezza funge da firewall virtuale per le EC2 istanze Amazon per controllare il traffico in entrata e in uscita. Le regole in entrata controllano il traffico in entrata verso l'istanza e le regole in uscita controllano il traffico in uscita dall'istanza. Nel caso di ElastiCache, quando si avvia un cluster, è necessario associare un gruppo di sicurezza. In tal modo si garantisce che le regole del traffico in entrata e in uscita siano in atto per tutti i nodi che costituiscono il cluster. Inoltre, ElastiCache è configurato per l'implementazione esclusivamente su sottoreti private in modo che siano accessibili solo tramite la rete privata del VPC.
+ **[Obbligatorio] **Il gruppo di sicurezza associato al cluster controlla l'ingresso e l'accesso della rete al cluster. Per impostazione predefinita, un gruppo di sicurezza non ha alcuna regola in entrata definita e, quindi, nessun percorso di ingresso. ElastiCache Per abilitare ciò, configura una regola in entrata sul gruppo di sicurezza specificando l'indirizzo/intervallo IP di origine, il traffico di tipo TCP e la porta per il ElastiCache cluster (porta predefinita 6379 per Valkey e Redis OSS, ad esempio ElastiCache ). Sebbene sia possibile consentire un set molto ampio di fonti di ingresso, come tutte le risorse all'interno di un VPC (0.0.0.0/0), si consiglia di essere il più granulari possibile nella definizione delle regole in entrata, ad esempio autorizzando solo l'accesso in entrata ai client Valkey o Redis OSS in esecuzione su istanze Amazon Amazon associate a uno specifico gruppo di sicurezza. EC2
**[Risorse]: **
+ [Sottoreti e gruppi di sottoreti](SubnetGroups.md)
+ [Accesso al cluster o gruppo di replica](accessing-elasticache.md)
+ [Controlla il traffico verso le risorse utilizzando gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#DefaultSecurityGroupdefault%20security%20group)
+ [Gruppi di sicurezza Amazon EC2 per istanze Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#creating-your-own-security-groups)
+ **[Obbligatorio]** è possibile assegnare politiche a funzioni che consentono loro di accedere ai dati.AWS Identity and Access Management AWS Lambda ElastiCache Per abilitare questa funzionalità, crea un ruolo di esecuzione IAM con l'`AWSLambdaVPCAccessExecutionRole`autorizzazione, quindi assegna il ruolo alla AWS Lambda funzione.
**[Risorse]:** Configurazione di una funzione Lambda per accedere ad Amazon in un ElastiCache Amazon VPC[: Tutorial: Configurazione di una funzione Lambda per accedere ad Amazon in un](https://docs.aws.amazon.com/lambda/latest/dg/services-elasticache-tutorial.html) Amazon VPC ElastiCache
## SEC 2: Le vostre applicazioni richiedono un'autorizzazione aggiuntiva rispetto ai ElastiCache controlli basati sulla rete?
**Introduzione a livello di domanda:** negli scenari in cui è necessario limitare o controllare l'accesso ai cluster a livello di singolo client, si consiglia di effettuare l'autenticazione tramite il comando AUTH. ElastiCache i token di autenticazione, con gestione opzionale di utenti e gruppi di utenti, consentono di richiedere una password prima di consentire ElastiCache ai client di eseguire comandi e chiavi di accesso, migliorando così la sicurezza del piano dati.
**Vantaggio a livello di domanda:** per contribuire a proteggere i dati, ElastiCache fornisce meccanismi di protezione contro l'accesso non autorizzato ai dati. Ciò include l'applicazione del Role-Based Access Control (RBAC) AUTH o del token AUTH (password) a cui i client devono connettersi prima di eseguire comandi autorizzati. ElastiCache
+ **[Ideale]** Per la ElastiCache versione 6.x e successive per Redis OSS e la ElastiCache versione 7.2 e successive per Valkey, definisci i controlli di autenticazione e autorizzazione definendo gruppi di utenti, utenti e stringhe di accesso. Assegna gli utenti ai gruppi di utenti, quindi assegna i gruppi di utenti ai cluster. Per utilizzare il RBAC, è necessario selezionarlo al momento della creazione del cluster e abilitare la crittografia in transito. Assicurati di utilizzare un client Valkey o Redis OSS che supporti TLS per poter sfruttare RBAC.
**[Risorse]: **
+ [Applicazione di RBAC a un gruppo di replica per ElastiCache](Clusters.RBAC.md#rbac-using)
+ [Specifica delle autorizzazioni mediante una stringa di accesso](Clusters.RBAC.md#Access-string)
+ [ACL](https://valkey.io/topics/acl/)
+ [ ElastiCache Versioni supportate](VersionManagement.md#supported-engine-versions)
+ **[Ideale]** Per ElastiCache le versioni precedenti alla 6.x per Redis OSS, oltre a impostare una politica di password sicura token/password e mantenere una rigida politica di password per AUTH, è consigliabile ruotare la password/il token. ElastiCache può gestire fino a due (2) token di autenticazione in un dato momento. Puoi anche modificare il cluster per richiedere esplicitamente l'uso di token di autenticazione.
**[Risorse]:** [modifica del token AUTH su](auth.md#auth-modifyng-token) un cluster esistente ElastiCache
## SIC 3: esiste il rischio che i comandi possano essere eseguiti inavvertitamente, causando la perdita di dati o errori nei dati?
**Introduzione a livello di domanda: Esistono diversi comandi Valkey o Redis OSS che possono avere un impatto negativo sulle operazioni se eseguiti per errore o da attori malintenzionati**. Questi comandi possono avere conseguenze impreviste dal punto di vista delle prestazioni e della sicurezza dei dati. Ad esempio, uno sviluppatore che esegue regolarmente il comando FLUSHALL in un ambiente di sviluppo potrebbe per errore chiamare inavvertitamente questo comando in un sistema di produzione, con conseguente perdita accidentale di dati.
**Vantaggio a livello di domanda:** a partire dalla ElastiCache versione 5.0.3 per Redis OSS, è possibile rinominare determinati comandi che potrebbero compromettere il carico di lavoro. La ridenominazione dei comandi può aiutare a evitare che vengano eseguiti inavvertitamente sul cluster.
+ **[Obbligatorio] **
**[Risorse]: **
+ [ElastiCache versione 5.0.3 per Redis OSS (obsoleta, usa la versione 5.0.6)](engine-versions.md#redis-version-5-0.3)
+ [ElastiCache versione 5.0.3 per le modifiche ai parametri Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3)
+ [sicurezza Redis OSS](https://redis.io/docs/management/security/)
## SEC 4: Come si garantisce la crittografia inattiva dei dati con ElastiCache
**Introduzione a livello di domanda:** Sebbene ElastiCache si tratti di un archivio dati in memoria, è possibile crittografare tutti i dati che possono essere resi persistenti (in archiviazione) come parte delle operazioni standard del cluster. Ad esempio i backup pianificati e manuali scritti su Amazon S3, nonché i dati salvati nello spazio di archiviazione su disco a seguito di operazioni di sincronizzazione e scambio. I tipi di istanza delle famiglie M6g e R6g offrono anche la crittografia in memoria sempre attiva.
**Vantaggio a livello di domanda:** ElastiCache offre una crittografia opzionale a riposo per aumentare la sicurezza dei dati.
+ **[Obbligatorio]** La crittografia a riposo può essere abilitata su un ElastiCache cluster (gruppo di replica) solo al momento della creazione. Un cluster esistente non può essere modificato per iniziare a crittografare i dati a riposo. Per impostazione predefinita, ElastiCache fornirà e gestirà le chiavi utilizzate nella crittografia at-rest.
**[Risorse]: **
+ [Vincoli di crittografia At-Rest](at-rest-encryption.md#at-rest-encryption-constraints)
+ [Abilitazione della crittografia dei dati inattivi](at-rest-encryption.md#at-rest-encryption-enable)
+ **[Ideale]** Sfrutta i tipi di EC2 istanze Amazon che crittografano i dati mentre sono in memoria (come M6g o R6g). Ove possibile, valuta la possibilità di gestire le chiavi per la crittografia a riposo. Per ambienti di sicurezza dei dati più rigorosi, AWS Key Management Service (KMS) può essere utilizzato per gestire automaticamente le Customer Master Keys (CMK). Grazie ElastiCache all'integrazione con AWS Key Management Service, puoi creare, possedere e gestire le chiavi utilizzate per la crittografia dei dati inattivi per il tuo cluster. ElastiCache
**[Risorse]: **
+ [Utilizzo di chiavi gestite dal cliente da AWS Key Management Service](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security)
+ [AWS Servizio di gestione delle chiavi](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
+ [AWS KMS concepts](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys)
## SEC 5: Come si crittografano i dati in transito? ElastiCache
**Introduzione della domanda: **è un requisito comune per evitare che i dati vengano compromessi durante il transito. Rappresenta i dati all'interno dei componenti di un sistema distribuito, nonché tra i client delle applicazioni e i nodi del cluster. ElastiCache supporta questo requisito consentendo la crittografia dei dati in transito tra client e cluster e tra i nodi del cluster stessi. I tipi di istanza delle famiglie M6g e R6g offrono anche la crittografia in memoria sempre attiva.
**Vantaggio a livello di domanda: la crittografia ElastiCache in transito di Amazon** è una funzionalità opzionale che consente di aumentare la sicurezza dei dati nei punti più vulnerabili, quando sono in transito da una posizione all'altra.
+ **[Obbligatorio]** La crittografia in transito può essere abilitata solo su un cluster (gruppo di replica) al momento della creazione. Tieni presente che, a causa dell'elaborazione aggiuntiva richiesta per la crittografia/decrittografia dei dati, l'implementazione della crittografia in transito avrà un certo impatto sulle prestazioni. Per comprenderne l'impatto, si consiglia di eseguire un benchmark del carico di lavoro prima e dopo l'attivazione. encryption-in-transit
**[Risorse]: **
+ [Panoramica della crittografia dei dati in transito](in-transit-encryption.md#in-transit-encryption-overview)
## SIC 6: come si limita l'accesso alle risorse del piano di controllo (control-plane)?
**Introduzione a livello di domanda:** le policy IAM e l'ARN consentono controlli granulari degli accessi ElastiCache per Valkey e Redis OSS, consentendo un controllo più rigoroso per gestire la creazione, la modifica e l'eliminazione dei cluster.
**Vantaggio a livello di domanda:** la gestione ElastiCache delle risorse Amazon, come gruppi di replica, nodi, ecc., può essere limitata agli AWS account che dispongono di autorizzazioni specifiche basate sulle politiche IAM, migliorando la sicurezza e l'affidabilità delle risorse.
+ **[Obbligatorio]** Gestisci l'accesso alle ElastiCache risorse di Amazon assegnando AWS Identity and Access Management policy specifiche agli AWS utenti, permettendo un controllo più preciso su quali account possono eseguire quali azioni sui cluster.
**[Risorse]: **
+ [Panoramica della gestione delle autorizzazioni di accesso alle tue risorse ElastiCache](IAM.Overview.md)
+ [Utilizzo di politiche basate sull'identità (politiche IAM) per Amazon ElastiCache](IAM.IdentityBasedPolicies.md)
## SIC 7: come si rileva e si risponde agli eventi di sicurezza?
**Introduzione a livello di domanda:**ElastiCache, se distribuito con RBAC abilitato, esporta CloudWatch i parametri per notificare agli utenti gli eventi di sicurezza. Queste metriche aiutano a identificare i tentativi di autenticazione non riusciti, le chiavi di accesso o l'esecuzione di comandi per i quali la connessione degli utenti con il RBAC non è autorizzata.
Inoltre, le risorse relative a AWS prodotti e servizi aiutano a proteggere il carico di lavoro complessivo automatizzando le implementazioni e registrando tutte le azioni e le modifiche per una revisione o un controllo successivi.
**Vantaggio della domanda: **monitorando gli eventi, consenti all'organizzazione di rispondere in base a requisiti, policy e procedure. L'automazione del monitoraggio e delle risposte a questi eventi rafforza il livello generale di sicurezza.
+ **[Obbligatorio]** Acquisisci familiarità con le CloudWatch metriche pubblicate relative agli errori di autenticazione e autorizzazione RBAC.
+ AuthenticationFailures = Tentativi falliti di autenticazione su Valkey o Redis OSS
+ KeyAuthorizationFailures = Tentativi falliti da parte degli utenti di accedere alle chiavi senza autorizzazione
+ CommandAuthorizationFailures = Tentativi falliti da parte degli utenti di eseguire comandi senza autorizzazione
**[Risorse]: **
+ [Metriche per Valkey o Redis OSS](CacheMetrics.Redis.md)
+ **[Best practice] **Ti consigliamo di configurare avvisi e notifiche su queste metriche e rispondere se necessario.
**[Risorse]: **
+ [Utilizzo degli CloudWatch allarmi Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ **[Ottimale]** Usa il comando Valkey o Redis OSS ACL LOG per raccogliere ulteriori dettagli
**[Risorse]: **
+ [ACL LOG](https://valkey.io/commands/acl-log/)
+ **[Migliore]** Acquisisci familiarità con le funzionalità AWS dei prodotti e dei servizi per quanto riguarda il monitoraggio, la registrazione e l'analisi delle implementazioni e degli eventi ElastiCache
**[Risorse]: **
+ [Registrazione delle chiamate ElastiCache API Amazon con AWS CloudTrail](logging-using-cloudtrail.md)
+ [elasticache-redis-cluster-automatic-controllo di backup](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html)
+ [Monitoraggio dell'uso con Metrics CloudWatch ](CacheMetrics.md)
# Pilastro dell'affidabilità delle ElastiCache lenti Amazon Well-Architected
Il pilastro dell'affidabilità si concentra sui carichi di lavoro che svolgono le funzioni previste e su come recuperare rapidamente in caso di mancato soddisfacimento delle richieste. Gli argomenti chiave includono la progettazione di sistemi distribuiti, la pianificazione del ripristino e l'adattamento ai requisiti in evoluzione.
**Topics**
+ [AFF 1: in che modo si supportano le implementazioni di architetture ad alta disponibilità?](#ReliabilityPillarREL1)
+ [REL 2: In che modo state raggiungendo i Recovery Point Objectives (RPOs)? ElastiCache](#ReliabilityPillarREL2)
+ [AFF 3: come si supportano i requisiti di ripristino di emergenza?](#ReliabilityPillarREL3)
+ [AFF 4: come si pianificano i failover in modo efficace?](#ReliabilityPillarREL4)
+ [REL 5: I vostri ElastiCache componenti sono progettati per essere scalabili?](#ReliabilityPillarREL5)
## AFF 1: in che modo si supportano le implementazioni di architetture ad alta disponibilità?
**Introduzione a livello di domanda:** comprendere l'architettura ad alta disponibilità di Amazon ti ElastiCache consentirà di operare in uno stato resiliente durante gli eventi di disponibilità.
**Vantaggio a livello di domanda:** l'architettura dei ElastiCache cluster in modo che siano resilienti ai guasti garantisce una maggiore disponibilità per le distribuzioni. ElastiCache
+ **[Obbligatorio] Determina il livello di affidabilità richiesto** per il tuo cluster. ElastiCache Carichi di lavoro diversi hanno standard di resilienza diversi, da quelli totalmente effimeri a quelli mission critical. Definisci le esigenze per ogni tipo di ambiente in cui gestisci, ad esempio, sviluppo, test e produzione.
Motore di caching: ElastiCache per Memcached rispetto a Valkey e Redis ElastiCache OSS
1. ElastiCache for Memcached non fornisce alcun meccanismo di replica e viene utilizzato principalmente per carichi di lavoro effimeri.
1. ElastiCache per Valkey e Redis OSS offre le funzionalità HA discusse di seguito
+ **[Ideale]** Per i carichi di lavoro che richiedono HA, utilizzalo ElastiCache in modalità cluster con un minimo di due repliche per shard, anche per carichi di lavoro con requisiti di throughput ridotti che richiedono solo uno shard.
1. Con la modalità cluster abilitata, multi-AZ viene impostato automaticamente.
Multi-AZ riduce al minimo i tempi di inattività eseguendo failover automatici dal nodo primario alle repliche, in caso di manutenzione pianificata o non pianificata, mitigando i guasti delle zone di disponibilità.
1. Per i carichi di lavoro suddivisi, un minimo di tre shard offre un ripristino più rapido durante gli eventi di failover, poiché il Valkey o il Redis OSS Cluster Protocol richiedono la disponibilità della maggior parte dei nodi primari per raggiungere il quorum.
1. Configura due o più repliche per la disponibilità.
La presenza di due repliche offre una migliore scalabilità di lettura e anche la disponibilità di lettura in scenari in cui una replica è in fase di manutenzione.
1. Usa i tipi di nodi basati su Graviton2 (nodi predefiniti nella maggior parte delle regioni).
ElastiCache ha aggiunto prestazioni ottimizzate su questi nodi. Di conseguenza, si ottengono migliori prestazioni di replica e sincronizzazione, con conseguente maggiore disponibilità complessiva.
1. Monitora e dimensiona correttamente per far fronte ai picchi di traffico previsti: in caso di carico intenso, il motore potrebbe non rispondere, il che influisce sulla disponibilità. `BytesUsedForCache`e `DatabaseMemoryUsagePercentage` sono buoni indicatori dell'utilizzo della memoria, mentre `ReplicationLag` sono un indicatore dello stato della replica in base alla velocità di scrittura. Puoi utilizzare queste metriche per attivare il dimensionamento dei cluster.
1. Garantisci la resilienza lato client eseguendo test con l'[API di failover prima di un evento di failover di produzione](https://docs.amazonaws.cn/en_us/AmazonElastiCache/latest/APIReference/API_TestFailover.html).
**[Risorse]: **
+ [Configura ElastiCache per Redis OSS per una maggiore disponibilità](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [Alta disponibilità utilizzando gruppi di replica](Replication.md)
## REL 2: In che modo state raggiungendo i Recovery Point Objectives (RPOs)? ElastiCache
**Introduzione a livello di domanda:** Comprendi l'RPO dei carichi di lavoro per prendere decisioni informate sulle strategie di ElastiCache backup e ripristino.
**Vantaggio della domanda: **disporre di una strategia RPO in atto può migliorare la continuità aziendale in caso di scenari di ripristino di emergenza. La progettazione delle politiche di backup e ripristino può aiutarti a raggiungere i Recovery Point Objectives (RPO) per i tuoi dati. ElastiCache ElastiCache offre funzionalità di snapshot archiviate in Amazon S3, insieme a una politica di conservazione configurabile. Questi snapshot vengono acquisiti durante la finestra di backup definita e gestiti automaticamente dal servizio. Se il carico di lavoro richiede una maggiore granularità del backup, hai la possibilità di creare fino a 20 backup manuali al giorno. I backup creati manualmente non hanno una policy di conservazione del servizio e possono essere conservati a tempo indeterminato.
+ **[Obbligatorio]** Comprendi e documenta l'RPO delle tue implementazioni. ElastiCache
+ Tieni presente che Memcached non offre processi di backup.
+ Esamina le funzionalità delle funzionalità di ElastiCache Backup e ripristino.
+ **[Best practice] **Predisponi di una procedura di comunicazione per il backup del cluster.
+ Avvia i backup manuali in base alle necessità.
+ Esamina le policy di conservazione per i backup automatici.
+ Tieni presente che i backup manuali vengono conservati a tempo indeterminato.
+ Pianifica i backup automatici nei periodi di basso utilizzo.
+ Esegui operazioni di backup su repliche di lettura per ridurre al minimo l'impatto sulle prestazioni del cluster.
+ **[Buono]** Sfrutta la funzionalità di backup pianificato ElastiCache per eseguire regolarmente il backup dei dati durante una finestra definita.
+ Esegui periodicamente il test del ripristino dei tuoi backup.
+ **[Risorse]: **
+ [Redis OSS](https://aws.amazon.com/elasticache/faqs/#Redis)
+ [Backup e ripristino per ElastiCache](backups.md)
+ [Creazione di backup manuali](backups-manual.md)
+ [Pianificazione di backup automatici](backups-automatic.md)
+ [ ElastiCache Cluster di backup e ripristino](https://aws.amazon.com/blogs/aws/backup-and-restore-elasticache-redis-nodes/)
## AFF 3: come si supportano i requisiti di ripristino di emergenza?
**Introduzione a livello di domanda:** il disaster recovery è un aspetto importante di qualsiasi pianificazione del carico di lavoro. ElastiCache offre diverse opzioni per implementare il disaster recovery in base ai requisiti di resilienza del carico di lavoro. Con Amazon ElastiCache Global Datastore, puoi scrivere sul tuo cluster in una regione e avere i dati disponibili per la lettura da altri due cluster di replica interregionali, abilitando così letture a bassa latenza e disaster recovery tra le regioni.
**Vantaggio della domanda: **la comprensione e la pianificazione di una varietà di scenari di emergenza possono garantire la continuità aziendale. Le strategie di ripristino di emergenza devono essere bilanciate rispetto ai costi, all'impatto sulle prestazioni e alla potenziale perdita di dati.
+ **[Obbligatorio]** Sviluppa e documenta strategie di DR per tutti i componenti in base ai requisiti del carico di lavoro. ElastiCache ElastiCache è unico in quanto alcuni casi d'uso sono completamente effimeri e non richiedono alcuna strategia di DR, mentre altri si collocano all'estremità opposta e richiedono una strategia di DR estremamente solida. Tutte le opzioni devono essere valutate rispetto all'ottimizzazione dei costi: una maggiore resilienza richiede una maggiore quantità di infrastruttura.
Comprendi le opzioni di ripristino di emergenza disponibili a livello regionale e multiregionale.
+ Le implementazioni multi-AZ sono consigliate per evitare errori di zone di disponibilità. Assicurati di eseguire l'implementazione con Cluster-Mode abilitata nelle architetture Multi-AZ, con un minimo di 3 disponibili. AZs
+ Global Datastore è consigliato per proteggersi dagli errori a livello di regione.
+ **[Best practice] **Abilita Global Datastore per i carichi di lavoro che richiedono resilienza a livello di regione.
+ Prepara un piano di failover nella regione secondaria in caso di degrado di quella primaria.
+ Esegui il test del processo di failover multiregione prima di eseguire un failover in produzione.
+ Monitora la metrica `ReplicationLag` per comprendere il potenziale impatto della perdita di dati durante gli eventi di failover.
+ **[Risorse]: **
+ [Limitazione dell'impatto degli errori](disaster-recovery-resiliency.md#FaultTolerance)
+ [Replica tra regioni utilizzando datastore globali AWS](Redis-Global-Datastore.md)
+ [Ripristino da un backup con ridimensionamento cluster opzionale](backups-restoring.md)
+ [Riduzione al minimo dei tempi di inattività ElastiCache per Valkey e Redis OSS con Multi-AZ](AutoFailover.md)
## AFF 4: come si pianificano i failover in modo efficace?
**Introduzione a livello di domanda:** abilitare Multi-AZ con failover automatici è una best practice. ElastiCache In alcuni casi, ElastiCache per Valkey e Redis OSS sostituisce i nodi primari nell'ambito delle operazioni di servizio. Ad esempio nel caso di eventi di manutenzione programmata e nel caso poco probabile di un errore in un nodo o una zona di disponibilità. I failover riusciti si basano su entrambi ElastiCache e sulla configurazione della libreria client.
**Vantaggio a livello di domanda:** seguire le migliori pratiche per i ElastiCache failover in combinazione con la libreria ElastiCache client specifica consente di ridurre al minimo i potenziali tempi di inattività durante gli eventi di failover.
+ **[Obbligatorio] **Per la modalità cluster disabilitata, utilizza i timeout in modo che i client rilevino se è necessario disconnettersi dal vecchio nodo primario e riconnettersi al nuovo nodo primario, utilizzando l'indirizzo IP dell'endpoint primario aggiornato. Per la modalità cluster abilitata, la libreria client è responsabile del rilevamento delle modifiche nella topologia del cluster sottostante. Ciò viene spesso ottenuto mediante le impostazioni di configurazione nella libreria ElastiCache client, che consentono anche di configurare la frequenza e il metodo di aggiornamento. Ogni libreria client offre le proprie impostazioni e maggiori dettagli sono disponibili nella documentazione corrispondente.
**[Risorse]: **
+ [Riduzione al minimo dei tempi di inattività ElastiCache per Valkey e Redis OSS con Multi-AZ](AutoFailover.md)
+ Consulta le best practice della tua libreria client. ElastiCache
+ **[Obbligatorio] **Il successo dei failover dipende da un ambiente di replica integro tra il nodo primario e quello di replica. Esamina e comprendi la natura asincrona della replica OSS di Valkey e Redis, nonché le CloudWatch metriche disponibili per segnalare il ritardo di replica tra i nodi primari e di replica. Per i casi d'uso che richiedono una maggiore sicurezza dei dati, sfrutta il comando WAIT per forzare le repliche a riconoscere le scritture prima di rispondere ai client connessi.
**[Risorse]: **
+ [Metriche per Valkey o Redis OSS](CacheMetrics.Redis.md)
+ [Monitoraggio delle best practice con ElastiCache l'utilizzo di Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Migliore]** Convalida regolarmente la reattività dell'applicazione durante il failover utilizzando l'API ElastiCache Test Failover.
**[Risorse]: **
+ [Test del failover automatico su una replica di lettura su ElastiCache](https://aws.amazon.com/blogs/database/testing-automatic-failover-to-a-read-replica-on-amazon-elasticache-for-redis/)
+ [Test del failover automatico](AutoFailover.md#auto-failover-test)
## REL 5: I vostri ElastiCache componenti sono progettati per essere scalabili?
**Introduzione a livello di domanda:** Comprendendo le capacità di scalabilità e le topologie di implementazione disponibili, ElastiCache i componenti possono adattarsi nel tempo per soddisfare i mutevoli requisiti del carico di lavoro. ElastiCacheoffre scalabilità a 4 vie: in/out (orizzontale) e (verticale). up/down
**Vantaggio a livello di domanda:** seguire le migliori pratiche per le ElastiCache implementazioni offre la massima flessibilità di scalabilità, oltre a soddisfare il principio Well Architected di scalabilità orizzontale per ridurre al minimo l'impatto dei guasti.
+ **[Obbligatorio] **Comprendi la differenza tra le topologie modalità cluster abilitata e modalità cluster disabilitata. In quasi tutti i casi è consigliabile eseguire l'implementazione con la modalità cluster abilitata in quanto consente una maggiore scalabilità nel tempo. I componenti in modalità cluster disabilitata sono limitati nella capacità di dimensionarsi orizzontalmente per aggiungere repliche di lettura.
+ **[Obbligatorio] **Determina quando e come dimensionare.
+ Per ulteriori READIOPS: aggiungi repliche
+ Per ulteriori WRITEOPS: aggiungi partizioni (dimensionamento orizzontale)
+ Per ulteriori I/O di rete: utilizza istanze ottimizzate per la rete (dimensionamento verticale)
+ **[Ideale]** Implementa ElastiCache i componenti con la modalità cluster abilitata, con una preferenza verso un numero maggiore di nodi più piccoli anziché un numero inferiore di nodi più grandi. In tal modo limiti efficacemente il raggio di applicazione dell'errore di un nodo.
+ **[Best practice] **Includi le repliche nei cluster per una maggiore reattività durante gli eventi di dimensionamento
+ **[Buono] Se** la modalità cluster è disattivata, sfrutta le repliche di lettura per aumentare la capacità di lettura complessiva. ElastiCache supporta fino a 5 repliche di lettura in modalità cluster disattivata, oltre al ridimensionamento verticale.
+ **[Risorse]: **
+ [ElastiCache Scalabilità dei cluster](Scaling.md)
+ [Dimensionamento verso l'alto online](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
# Pilastro dell'efficienza delle prestazioni delle lenti Amazon ElastiCache Well-Architected
Il pilastro dell'efficienza delle prestazioni si concentra sull'uso efficiente delle risorse IT e di calcolo. Gli argomenti chiave includono la selezione delle dimensioni e dei tipi corretti per le risorse in base ai requisiti del carico di lavoro, il monitoraggio delle prestazioni e il processo per prendere decisioni informate e mantenere l'efficienza man mano che le esigenze aziendali cambiano.
**Topics**
+ [PE 1: Come monitorate le prestazioni del vostro ElastiCache cluster Amazon?](#PerformanceEfficiencyPillarPE1)
+ [PE 2: Come state distribuendo il lavoro tra i ElastiCache nodi del cluster?](#PerformanceEfficiencyPillarPE2)
+ [EP 3: come si monitora e si segnala l'efficacia e le prestazioni della cache per i carichi di lavoro con memorizzazione nella cache?](#PerformanceEfficiencyPillarPE3)
+ [EP 4: in che modo il carico di lavoro ottimizza l'uso delle risorse e delle connessioni di rete?](#PerformanceEfficiencyPillarPE4)
+ [PE 5: Come gestite l'eliminazione and/or delle chiavi?](#PerformanceEfficiencyPillarPE5)
+ [PE 6: In che modo modellate e interagite con i dati ElastiCache?](#PerformanceEfficiencyPillarPE6)
+ [PE 7: Come si registrano i comandi a esecuzione lenta nel ElastiCache cluster Amazon?](#PerformanceEfficiencyPillarPE7)
+ [PE8: In che modo l'Auto Scaling aiuta ad aumentare le prestazioni del ElastiCache cluster?](#PerformanceEfficiencyPillarPE8)
## PE 1: Come monitorate le prestazioni del vostro ElastiCache cluster Amazon?
**Introduzione della domanda: **comprendendo le metriche di monitoraggio esistenti è possibile determinare l'utilizzo corrente. Un monitoraggio adeguato può aiutare a individuare i potenziali ostacoli che influiscono sulle prestazioni del cluster.
**Vantaggio della domanda: **la comprensione delle metriche associate al cluster può aiutare nella definizione delle tecniche di ottimizzazione volte a conseguire la riduzione della latenza e l'aumento della velocità di trasmissione effettiva.
+ **[Obbligatorio] **Test delle prestazioni di base utilizzando un sottoinsieme del carico di lavoro.
+ È necessario monitorare le prestazioni del carico di lavoro effettivo utilizzando meccanismi come i test di carico.
+ Monitora le CloudWatch metriche durante l'esecuzione di questi test per comprendere le metriche disponibili e stabilire una base di riferimento delle prestazioni.
+ **[Ideale]** ElastiCache Per i carichi di lavoro Valkey e Redis OSS, rinomina comandi computazionalmente costosi, ad esempio per limitare la capacità degli utenti di eseguire comandi di blocco sui cluster di produzione. `KEYS`
+ ElastiCache i carichi di lavoro che eseguono il motore 6.x per Redis OSS possono sfruttare il controllo degli accessi basato sui ruoli per limitare determinati comandi. L'accesso ai comandi può essere controllato creando utenti e gruppi di utenti con la AWS console o la CLI e associando i gruppi di utenti a un cluster. In Redis OSS 6, quando RBAC è abilitato, possiamo usare «- @dangerous" e non consentirà comandi costosi come KEYS, MONITOR, SORT, ecc. per quell'utente.
+ Per la versione 5.x del motore, rinomina i comandi utilizzando il parametro nel gruppo di parametri del cluster`rename-commands`.
+ **[Consigliato] **Analizza le query lente ed esamina le tecniche di ottimizzazione.
+ ElastiCache Per i carichi di lavoro Valkey e Redis OSS, scopri di più sulle tue query analizzando lo Slow Log. Ad esempio, puoi utilizzare il seguente comando per mostrare gli ultimi 10 comandi che hanno superato `valkey-cli slowlog get 10` le soglie di latenza (10 millisecondi per impostazione predefinita).
+ Alcune query possono essere eseguite in modo più efficiente utilizzando strutture di dati complesse ElastiCache per Valkey e Redis OSS. Ad esempio, per le ricerche con intervalli di numeri, è possibile implementare nell'applicazione semplici indici numerici con i set ordinati. La gestione di questi indici può ridurre le scansioni eseguite sui set e restituire i dati con prestazioni migliori.
+ ElastiCache Per i carichi di lavoro Valkey e Redis OSS, `redis-benchmark` fornisce un'interfaccia semplice per testare le prestazioni di diversi comandi utilizzando input definiti dall'utente come il numero di client e la dimensione dei dati.
+ Poiché Memcached supporta solo semplici comandi a livello di chiave, valuta la possibilità di creare altre chiavi come indici per evitare l'iterazione dello spazio delle chiavi per rispondere alle query dei client.
+ **[Risorse]: **
+ [Monitoraggio dell'uso con Metrics CloudWatch ](CacheMetrics.md)
+ [Utilizzo degli CloudWatch allarmi Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Parametri specifici di Valkey e Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [SLOWLOG](https://valkey.io/commands/slowlog/)
+ [benchmark](https://valkey.io/topics/benchmark/)
## PE 2: Come state distribuendo il lavoro tra i ElastiCache nodi del cluster?
**Introduzione a livello di domanda:** il modo in cui l'applicazione si connette ElastiCache ai nodi Amazon può influire sulle prestazioni e sulla scalabilità del cluster.
**Vantaggio della domanda: **l'uso corretto dei nodi disponibili nel cluster garantisce la distribuzione del lavoro tra le risorse disponibili. Le seguenti tecniche consentono anche di evitare risorse inutilizzate.
+ **[Obbligatorio]** Consenti ai client di connettersi all'endpoint corretto. ElastiCache
+ ElastiCache per Valkey e Redis OSS implementa diversi endpoint in base alla modalità cluster in uso. Se la modalità cluster è abilitata, ElastiCache fornirà un endpoint di configurazione. Per la modalità cluster disattivata, ElastiCache fornisce un endpoint primario, in genere utilizzato per le scritture, e un endpoint di lettura per bilanciare le letture tra le repliche. L'implementazione corretta di questi endpoint si traduce in prestazioni migliori e operazioni di dimensionamento più semplici. Evita di connetterti ai singoli endpoint dei nodi a meno che non vi sia un requisito specifico in tal senso.
+ Per i cluster Memcached multinodo, fornisce un endpoint di configurazione che abilita l'Auto Discovery ElastiCache . Ti consigliamo di utilizzare un algoritmo di hash per distribuire il lavoro in modo uniforme tra i nodi di cache. Molte librerie client Memcached implementano l'hash in modo coerente. Consulta la documentazione della libreria che utilizzi per verificare se supporta l'hashing coerente e ottenere informazioni su come implementarlo. Ulteriori informazioni sull'implementazione di queste funzionalità sono disponibili [qui](BestPractices.LoadBalancing.md).
+ **[Migliore]** Sfrutta i cluster abilitati alla modalità cluster Valkey e Redis OSS ElastiCache per migliorare la scalabilità.
+ ElastiCache per Valkey e Redis OSS (modalità cluster abilitata) i cluster supportano [operazioni di scalabilità online () per aiutare a distribuire i dati in modo dinamico](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) tra gli out/in and up/down shard. L'utilizzo dell'endpoint di configurazione garantisce che i client che supportano il cluster possano adattarsi ai cambiamenti nella topologia del cluster.
+ Puoi anche ribilanciare il cluster spostando gli hashslot tra gli shard disponibili nei cluster ElastiCache for Valkey e Redis OSS (modalità cluster abilitata). In tal modo il lavoro viene distribuito in modo più efficiente tra le partizioni disponibili.
+ **[Consigliato] **Implementa una strategia per identificare e correggere le chiavi hot nel tuo carico di lavoro.
+ Considerate l'impatto delle strutture di dati multidimensionali di Valkey o Redis OSS come elenchi, stream, set, ecc. Queste strutture di dati sono archiviate in singole chiavi, che risiedono su un singolo nodo. Una chiave multidimensionale molto grande può utilizzare più memoria e capacità di rete rispetto ad altri tipi di dati e causare un uso sproporzionato del nodo. Se possibile, progetta il tuo carico di lavoro in modo da distribuire l'accesso ai dati tra molte chiavi discrete.
+ Le chiavi hot del carico di lavoro possono influire sulle prestazioni del nodo in uso. ElastiCache Per i carichi di lavoro Valkey e Redis OSS, è possibile rilevare i tasti di scelta rapida utilizzando `valkey-cli --hotkeys` se è in atto una politica di memoria massima LFU.
+ Prendi in considerazione la replica delle chiavi hot su più nodi per distribuire l'accesso in modo più uniforme. Questo approccio richiede che il client scriva su più nodi primari (lo stesso nodo Valkey o Redis OSS non fornirà questa funzionalità) e mantenga un elenco di nomi di chiave da cui leggere, oltre al nome della chiave originale.
+ ElastiCache [il motore 7.2 per Valkey e versioni successive e la ElastiCache versione 6 per Redis OSS e versioni successive supportano tutti la memorizzazione nella cache lato client assistita dal server.](https://valkey.io/topics/client-side-caching/) Ciò consente alle applicazioni di attendere le modifiche a una chiave prima di effettuare chiamate di rete a. ElastiCache
+ **[Risorse]: **
+ [Configurazione ElastiCache per Valkey e Redis OSS per una maggiore disponibilità](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [Ricerca degli endpoint di connessione in ElastiCache](Endpoints.md)
+ [Best practice per il bilanciamento del carico](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/BestPractices.LoadBalancing.html)
+ [Resharding online per Valkey o Redis OSS (modalità cluster abilitata)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Memorizzazione nella cache lato client in Valkey e Redis OSS](https://valkey.io/topics/client-side-caching/)
## EP 3: come si monitora e si segnala l'efficacia e le prestazioni della cache per i carichi di lavoro con memorizzazione nella cache?
**Introduzione a livello di domanda:** la memorizzazione nella cache è un carico di lavoro comune ElastiCache ed è importante comprendere come gestire l'efficacia e le prestazioni della cache.
**Vantaggio della domanda: **l'applicazione potrebbe mostrare segni di rallentamento delle prestazioni. La capacità di utilizzare metriche specifiche della cache per decidere come aumentare le prestazioni delle app è fondamentale per il carico di lavoro della cache.
+ **[Obbligatorio] **Misura e monitora nel tempo il rapporto dei riscontri della cache. L'efficienza della cache è determinata dal "rapporto di riscontri della cache". Il rapporto di riscontri della cache è definito dal totale dei riscontri delle chiavi diviso per il totale dei riscontri e dei mancati riscontri. Più il rapporto è vicino a 1, più efficace è la cache. Un basso rapporto di riscontri della cache è causato dal volume di mancati riscontri della cache. I mancati riscontri della cache si verificano quando la chiave richiesta non viene trovata nella cache. Una chiave non è nella cache perché è stata rimossa o eliminata, è scaduta o non è mai esistita. Determina il motivo per cui le chiavi non sono nella cache e sviluppa le strategie appropriate per averle nella cache.
**[Risorse]: **
+ [Metriche per Valkey e Redis OSS](CacheMetrics.Redis.md)
+ **[Obbligatorio]** Misura e raccogli le prestazioni della cache delle applicazioni insieme ai valori di latenza e utilizzo della CPU per capire se è necessario apportare modifiche ai componenti dell'applicazione o ad altri componenti dell'applicazione. time-to-live ElastiCache fornisce un set di CloudWatch metriche per le latenze aggregate per ogni struttura di dati. Queste metriche di latenza vengono calcolate utilizzando la statistica commandstats del comando INFO e non includono la rete e il tempo di I/O. Questo è solo il tempo impiegato per elaborare le operazioni. ElastiCache
**[Risorse]: **
+ [Metriche per Valkey e Redis OSS](CacheMetrics.Redis.md)
+ [Monitoraggio delle best practice con ElastiCache l'utilizzo di Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Best practice] **Scegli la strategia di memorizzazione nella cache giusta per le tue esigenze. Un basso rapporto di riscontri della cache è causato dal volume di mancati riscontri della cache. Se il carico di lavoro è progettato per avere un volume ridotto di mancati riscontri della cache (come la comunicazione in tempo reale), è consigliabile esaminare le strategie di memorizzazione nella cache e applicare le risoluzioni più appropriate per il carico di lavoro, ad esempio la strumentazione delle query per misurare la memoria e le prestazioni. Le strategie effettive utilizzate per implementare il popolamento e la gestione della cache dipende dai dati del client che desideri memorizzare nella cache e dai modelli di accesso a tali dati. Ad esempio, è improbabile che utilizzi in un'applicazione di streaming la stessa strategia per i suggerimenti personalizzati e per le notizie più interessanti.
**[Risorse]: **
+ [Strategie di caching per Memcached](Strategies.md)
+ [Caching Best Practices](https://aws.amazon.com/caching/best-practices/)
+ [Prestazioni su larga scala con Amazon ElastiCache Whitepaper](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf)
## EP 4: in che modo il carico di lavoro ottimizza l'uso delle risorse e delle connessioni di rete?
**Introduzione a livello di domanda:** ElastiCache per Valkey, Memcached e Redis OSS sono supportati da molti client applicativi e le implementazioni possono variare. È necessario comprendere la gestione della rete e delle connessioni in uso per analizzare il potenziale impatto sulle prestazioni.
**Vantaggio della domanda: **l'uso corretto delle risorse di rete può migliorare l'efficienza delle prestazioni del cluster. I seguenti suggerimenti possono ridurre le richieste di rete e migliorare la latenza e la velocità di trasmissione effettiva del cluster.
+ **[Obbligatorio]** Gestisci in modo proattivo le connessioni al tuo cluster. ElastiCache
+ Il pool di connessioni dell'applicazione riduce la quantità di sovraccarico sul cluster creato dall'apertura e dalla chiusura delle connessioni. Monitora il comportamento della connessione in Amazon CloudWatch utilizzando `CurrConnections` e`NewConnections`.
+ Evita di perdere le connessioni client chiudendole correttamente, quando opportuno. Le strategie di gestione delle connessioni includono la corretta chiusura delle connessioni non in uso e l'impostazione del timeout delle connessioni.
+ Per i carichi di lavoro Memcached, esiste una quantità di memoria configurabile riservata alla gestione delle connessioni chiamate, `memcached_connections_overhead`.
+ **[Consigliato] **Comprimi gli oggetti di grandi dimensioni per ridurre la memoria e migliorare la velocità di trasmissione effettiva di rete.
+ La compressione dei dati può ridurre la velocità di trasmissione effettiva di rete richiesta (Gbps), ma aumenta la quantità di lavoro dell'applicazione per comprimere e decomprimere i dati.
+ La compressione riduce anche la quantità di memoria consumata dalle chiavi.
+ In base alle esigenze della tua applicazione, considera i compromessi tra rapporto di compressione e velocità di compressione.
+ **[Risorse]: **
+ [ElastiCache - Datastore globale](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [Parametri Memcached specifici](ParameterGroups.Engine.md#ParameterGroups.Memcached)
+ [ElastiCache la versione 5.0.3 per Redis OSS migliora I/O la gestione per aumentare le prestazioni](https://aws.amazon.com/about-aws/whats-new/2019/03/amazon-elasticache-for-redis-503-enhances-io-handling-to-boost-performance/)
+ [Metriche per Valkey e Redis OSS](CacheMetrics.Redis.md)
+ [Configurazione per ElastiCache una maggiore disponibilità](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
## PE 5: Come gestite l'eliminazione and/or delle chiavi?
**Introduzione a livello di domanda:** i carichi di lavoro hanno requisiti e comportamenti previsti diversi quando un nodo del cluster si avvicina ai limiti di consumo di memoria. ElastiCache ha politiche diverse per la gestione di queste situazioni.
**Vantaggio della domanda: **la corretta gestione della memoria disponibile e la comprensione delle policy di espulsione contribuiscono a garantire la consapevolezza del comportamento del cluster quando i limiti di memoria delle istanze vengono superati.
+ **[Obbligatorio] **Strumenta l'accesso ai dati per valutare quale policy applicare. Identifica una policy per la memoria massima appropriata per controllare se e come vengono eseguite le espulsioni sul cluster.
+ L'espulsione si verifica quando viene consumata la memoria massima del cluster e c'è una policy che consente l'operazione. Il comportamento del cluster in questa situazione dipende dalla policy di espulsione specificata. Questa politica può essere gestita utilizzando il gruppo di parametri `maxmemory-policy` on the cluster.
+ La policy predefinita `volatile-lru` libera la memoria espellendo le chiavi con un tempo di scadenza impostato (valore TTL). Le policy per l'utilizzo meno frequente (LFU) e meno recente (LRU) rimuovono le chiavi in base all'utilizzo.
+ Per i carichi di lavoro Memcached, esiste una policy predefinita per LRU che controlla le espulsioni su ogni nodo. Il numero di sfratti sul tuo ElastiCache cluster Amazon può essere monitorato utilizzando la metrica Sfratti su Amazon. CloudWatch
+ **[Best practice] **Standardizza il comportamento di eliminazione per controllare l'impatto sulle prestazioni del cluster ed evitare imprevisti colli di bottiglia delle prestazioni.
+ ElastiCache Per i carichi di lavoro Valkey e Redis OSS, quando si rimuovono esplicitamente le chiavi dal cluster, `UNLINK` è come: rimuove le chiavi specificate. `DEL` Tuttavia, il comando esegue il recupero della memoria effettiva in un thread diverso, quindi non si blocca, contrariamente a `DEL`. La rimozione effettiva avviene successivamente in modo asincrono.
+ Per la ElastiCache versione 6.x per i carichi di lavoro Redis OSS, il comportamento del `DEL` comando può essere modificato nel gruppo di parametri utilizzando il parametro. `lazyfree-lazy-user-del`
+ **[Risorse]: **
+ [Configurazione dei parametri del motore utilizzando gruppi di ElastiCache parametri](ParameterGroups.md)
+ [UNLINK](https://valkey.io/commands/unlink/)
+ [Gestione finanziaria nel cloud con AWS](https://aws.amazon.com/aws-cost-management/)
## PE 6: In che modo modellate e interagite con i dati ElastiCache?
**Introduzione a livello di domanda:** ElastiCache dipende in larga misura dall'applicazione dalle strutture di dati e dal modello di dati utilizzati, ma deve anche considerare l'archivio dati sottostante (se presente). Comprendi le strutture di dati disponibili e assicurati di utilizzare le strutture di dati più appropriate per le tue esigenze.
**Vantaggio a livello di domanda:** la modellazione dei dati ElastiCache ha diversi livelli, tra cui il caso d'uso dell'applicazione, i tipi di dati e le relazioni tra gli elementi di dati. Inoltre, ogni tipo di dati e comando ha le proprie caratteristiche prestazionali ben documentate.
+ **[Best practice] **Una best practice consiste nel ridurre la sovrascrittura involontaria dei dati. Utilizza una convenzione di denominazione che riduca al minimo la sovrapposizione dei nomi delle chiavi. La convenzione di denominazione delle strutture di dati utilizza il metodo gerarchico `APPNAME:CONTEXT:ID`, ad esempio `ORDER-APP:CUSTOMER:123`.
**[Risorse]: **
+ [Key naming](https://docs.gitlab.com/ee/development/redis.html#key-naming)
+ **[ElastiCache Ideale]** perché i comandi OSS di Valkey e Redis hanno una complessità temporale definita dalla notazione Big O. Questa complessità temporale di un comando è una algorithmic/mathematical rappresentazione del suo impatto. Quando si introduce un nuovo tipo di dati nell'applicazione, è necessario esaminare attentamente la complessità temporale dei relativi comandi. I comandi con la complessità temporale O(1) sono costanti nel tempo e non dipendono dalla dimensione dell'input, mentre i comandi con la complessità temporale O(N) sono lineari nel tempo e sono soggetti alla dimensione dell'input. Grazie al design a thread singolo di ElastiCache Valkey e Redis OSS, un volume elevato di operazioni ad alta complessità temporale comporterà una riduzione delle prestazioni e potenziali timeout operativi.
**[Risorse]: **
+ [Comandi](https://valkey.io/commands/)
+ **[Ideale] Utilizzalo** APIs per ottenere visibilità tramite interfaccia grafica sul modello di dati nel cluster.
**[Risorse]: **
+ [Redis OSS Commander](https://www.npmjs.com/package/ElastiCache for Redis-commander)
+ [Browser Redis OSS](https://github.com/humante/redis-browser)
+ [Redsmin](https://www.redsmin.com/)
## PE 7: Come si registrano i comandi a esecuzione lenta nel ElastiCache cluster Amazon?
**Introduzione della domanda: **vantaggi dell'ottimizzazione delle prestazioni attraverso l'acquisizione, l'aggregazione e la notifica di comandi di lunga durata. Comprendendo il tempo necessario per l'esecuzione dei comandi, è possibile determinare quali comandi determinano prestazioni scadenti e quali comandi che impediscono al motore di funzionare in modo ottimale. ElastiCache ha anche la capacità di inoltrare queste informazioni ad Amazon CloudWatch o Amazon Kinesis Data Firehose.
**Vantaggio della domanda: **l'accesso a una posizione permanente dedicata e l'invio di eventi di notifica per i comandi lenti possono aiutare a eseguire un'analisi dettagliata delle prestazioni e possono essere utilizzati per attivare eventi automatizzati.
+ **[Richiesto]** ElastiCache Esecuzione di un motore Valkey 7.2 o versione successiva o di un motore Redis OSS versione 6.0 o successiva, gruppo di parametri configurato correttamente e registrazione SLOWLOG abilitata sul cluster.
+ I parametri richiesti sono disponibili solo quando la compatibilità della versione del motore è impostata su Valkey 7.2 e versioni successive o Redis OSS versione 6.0 o successiva.
+ La registrazione SLOWLOG si verifica quando l'esecuzione di un comando sul server richiede più tempo del valore specificato. Il comportamento del cluster dipende dai parametri `slowlog-log-slower-than` e `slowlog-max-len` del gruppo di parametri associato.
+ Le modifiche diventano effettive immediatamente.
+ **[Migliore]** Sfrutta le nostre funzionalità di CloudWatch Kinesis Data Firehose.
+ Utilizza le funzionalità di filtro e allarme di CloudWatch CloudWatch Logs Insights e Amazon Simple Notification Services per monitorare le prestazioni e notificare gli eventi.
+ Usa le funzionalità di streaming di Kinesis Data Firehose per archiviare i log SLOWLOG in uno spazio di archiviazione permanente o per attivare l'ottimizzazione automatica dei parametri del cluster.
+ Determina se si adatta meglio alle tue esigenze il formato JSON o TEXT normale.
+ Fornisci le autorizzazioni IAM per la pubblicazione su CloudWatch o su Kinesis Data Firehose.
+ **[Consigliato] **Configura `slowlog-log-slower-than` con un valore diverso da quello predefinito.
+ Questo parametro determina per quanto tempo un comando può essere eseguito all'interno del motore Valkey o Redis OSS prima che venga registrato come comando a esecuzione lenta. Il valore predefinito è 10.000 microsecondi (10 millisecondi). Il valore predefinito potrebbe essere troppo alto per alcuni carichi di lavoro.
+ Determina il valore più appropriato per il tuo carico di lavoro in base alle esigenze delle applicazioni e ai risultati dei test, tuttavia considera che un valore troppo basso può generare un volume eccessivo di dati.
+ **[Consigliato] **Lascia `slowlog-max-len` impostato sul valore predefinito.
+ Questo parametro determina il limite superiore per il numero di comandi a esecuzione lenta che vengono acquisiti nella memoria Valkey o Redis OSS in un dato momento. Un valore pari a 0 disabilita l'acquisizione. Più alto è il valore, più elementi verranno archiviati in memoria, riducendo la possibilità che informazioni importanti vengano espulse prima di essere esaminate. Il valore predefinito è 128.
+ Il valore predefinito è appropriato per la maggior parte dei carichi di lavoro. Se è necessario analizzare i dati in una finestra temporale estesa da valkey-cli tramite il comando SLOWLOG, è possibile aumentare questo valore. Ciò consente a più comandi di rimanere nella memoria Valkey o Redis OSS.
Se si inviano dati SLOWLOG a CloudWatch Logs o Kinesis Data Firehose, i dati verranno mantenuti e potranno essere analizzati all'esterno del sistema, riducendo ElastiCache la necessità di archiviare un gran numero di comandi a esecuzione lenta nella memoria Valkey o Redis OSS.
+ **[Risorse]: **
+ [Come si attiva lo Slow log in un cluster?](https://repost.aws/knowledge-center/elasticache-turn-on-slow-log)
+ [Consegna dei registri](Log_Delivery.md)
+ [Parametri specifici del sistema operativo Redis](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: In che modo l'Auto Scaling aiuta ad aumentare le prestazioni del ElastiCache cluster?
**Introduzione a livello di domanda:** implementando la funzionalità di scalabilità automatica Valkey o Redis OSS, ElastiCache i componenti possono adattarsi nel tempo per aumentare o diminuire automaticamente gli shard o le repliche desiderati. Questa operazione può essere eseguita implementando il monitoraggio degli obiettivi o la policy di dimensionamento pianificata.
**Vantaggio a livello di domanda:** la comprensione e la pianificazione dei picchi del carico di lavoro possono garantire prestazioni di caching migliorate e continuità aziendale. ElastiCache Auto Scaling monitora continuamente l'utilizzo della CPU/memoria per assicurarsi che il cluster funzioni ai livelli di prestazioni desiderati.
+ **[Obbligatorio]** Quando si avvia un cluster per Valkey o Redis OSS: ElastiCache
1. Assicurati che la modalità cluster sia abilitata
1. Assicurati che l'istanza faccia parte della famiglia dei tipi e delle dimensioni che supportano il dimensionamento automatico
1. Assicurati che il cluster non sia in esecuzione in datastore globali, Outpost o zone locali
**[Risorse]: **
+ [Scalabilità dei cluster in Valkey e Redis OSS (modalità cluster abilitata)](scaling-redis-cluster-mode-enabled.md)
+ [Utilizzo di Auto Scaling con i shard](AutoScaling-Using-Shards.md)
+ [Utilizzo di Auto Scaling con le repliche](AutoScaling-Using-Replicas.md)
+ **[Best practice] **Determina se il tuo carico di lavoro è pesante in lettura o in scrittura quando definisci la policy di dimensionamento. Per le prestazioni ottimali, utilizza una sola metrica di monitoraggio. Ti consigliamo di evitare l'uso di più policy per una dimensione perché le policy di dimensionamento automatico si dimensionano quando l'obiettivo viene raggiunto, ma si ridimensionano solo quando tutte le policy di monitoraggio degli obiettivi sono pronte per farlo.
**[Risorse]: **
+ [Policy di Auto Scaling](AutoScaling-Policies.md)
+ [Definizione di una policy di dimensionamento](AutoScaling-Scaling-Defining-Policy-API.md)
+ **[Best practice] **Il monitoraggio delle prestazioni nel tempo può aiutarti a rilevare i cambiamenti del carico di lavoro che rimarrebbero inosservati se monitorati solo in un determinato momento. È possibile analizzare le CloudWatch metriche corrispondenti per l'utilizzo del cluster in un periodo di quattro settimane per determinare la soglia del valore target. Se non sei ancora certo del valore da scegliere, ti consigliamo di iniziare con il valore predefinito minimo supportato della metrica.
**[Risorse]: **
+ [Monitoraggio dell'uso con Metrics CloudWatch ](CacheMetrics.md)
+ **[Migliore]** Consigliamo di testare l'applicazione con i carichi di lavoro minimi e massimi previsti, per identificare il numero esatto di quelli shards/replicas necessari al cluster per sviluppare politiche di scalabilità e mitigare i problemi di disponibilità.
**[Risorse]: **
+ [Registrare un target scalabile](AutoScaling-Register-Policy.md)
+ [Registrazione di un target scalabile utilizzando il AWS CLI](AutoScaling-Scaling-Registering-Policy-CLI.md)
# Pilastro dell'ottimizzazione dei costi delle lenti Amazon ElastiCache Well-Architected
Il pilastro dell'ottimizzazione dei costi si concentra sull'evitare costi inutili. Gli argomenti chiave includono la comprensione e il controllo delle spese, la selezione del tipo di nodo più appropriato (utilizza istanze che supportano la suddivisione dei dati su più livelli in base alle esigenze del carico di lavoro), il numero corretto dei tipi di risorse (repliche lette), l'analisi delle spese nel tempo e il dimensionamento per soddisfare le esigenze aziendali senza costi eccessivi.
**Topics**
+ [COSTO 1: Come identificate e tenete traccia dei costi associati alle vostre risorse? ElastiCache Come si sviluppano meccanismi per consentire agli utenti di creare, gestire ed eliminare le risorse create?](#CostOptimizationPillarCOST1)
+ [COSTO 2: Come utilizzate gli strumenti di monitoraggio continuo per ottimizzare i costi associati alle vostre risorse? ElastiCache](#CostOptimizationPillarCOST2)
+ [COSTI 3: è necessario utilizzare un tipo di istanza che supporti la suddivisione dei dati in più livelli? Quali sono i vantaggi di una suddivisione dei dati in più livelli? Quando non utilizzare le istanze di suddivisione dei dati in più livelli?](#CostOptimizationPillarCOST3)
## COSTO 1: Come identificate e tenete traccia dei costi associati alle vostre risorse? ElastiCache Come si sviluppano meccanismi per consentire agli utenti di creare, gestire ed eliminare le risorse create?
**Introduzione della domanda: **la comprensione delle metriche di costo richiede la partecipazione e la collaborazione di più team: ingegneria del software, gestione dei dati, proprietari dei prodotti, finanza e leadership. L'identificazione dei principali fattori di costo richiede che tutte le parti coinvolte comprendano le leve di controllo dell'utilizzo dei servizi e i compromessi di gestione dei costi che spesso è la differenza fondamentale tra le attività di ottimizzazione dei costi efficaci e meno efficaci. Assicurarsi di disporre di processi e strumenti per tenere traccia delle risorse create dallo sviluppo alla produzione e al pensionamento aiuta a gestire i costi associatiElastiCache.
**Vantaggio a livello di domanda:** il monitoraggio continuo di tutti i costi associati al carico di lavoro richiede una profonda comprensione dell'architettura che include ElastiCache come uno dei suoi componenti. Inoltre, è necessario disporre di un piano di gestione dei costi per raccogliere e confrontare l'utilizzo rispetto al budget.
+ **[Obbligatorio]** Istituite un Cloud Center of Excellence (CCoE) con una delle sue carte fondamentali per definire, tracciare e intervenire sulle metriche relative all'utilizzo delle vostre organizzazioni. ElastiCache Se esiste CCo e funziona, assicurati che sappia leggere e tenere traccia dei costi associati. ElastiCache Quando vengono create le risorse, utilizza i ruoli e le policy IAM per verificare che solo i team e i gruppi specifici possano creare istanze delle risorse. In tal modo i costi sono associati ai risultati aziendali e viene stabilita una chiara linea di responsabilità, dal punto di vista dei costi.
1. CCoE dovrebbe identificare, definire e pubblicare metriche di costo aggiornate regolarmente, mensilmente, in merito all' ElastiCache utilizzo dei principali dati categoriali come:
1. Tipi di nodi utilizzati e relativi attributi: istanze standard e ottimizzate per la memoria, istanze on demand e riservate, regioni e zone di disponibilità
1. Tipi di ambienti: gratuito, sviluppo, test e produzione
1. Strategie di backup, archiviazione e conservazione
1. Trasferimento di dati all'interno e tra le regioni
1. Istanze in esecuzione su Amazon Outposts
1. CCoE è composto da un team interfunzionale con una rappresentanza non esclusiva dei team di ingegneria del software, gestione dei dati, team di prodotto, finanza e leadership dell'organizzazione.
**[Risorse]: **
+ [Create a Cloud Center of Excellence](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html)
+ [ ElastiCachePrezzi Amazon](https://aws.amazon.com/elasticache/pricing/)
+ **[Obbligatorio] **Utilizza i tag di allocazione dei costi per tenere traccia dei costi con un basso livello di granularità. Usa AWS Cost Management per visualizzare, comprendere e gestire i AWS costi e l'utilizzo nel tempo.
1. Utilizza i tag per organizzare le risorse e i tag di allocazione dei costi per tenere traccia AWS dei costi a livello dettagliato. Dopo aver attivato i tag di allocazione dei costi, AWS utilizza i tag di allocazione dei costi per organizzare i costi delle risorse nel report di allocazione dei costi, in modo da semplificare la categorizzazione e il monitoraggio dei costi. AWS AWS fornisce due tipi di tag di allocazione dei costi, un tag AWS generato e un tag definito dall'utente. AWS definisce, crea e applica AWS automaticamente i tag generati e tu definisci, crea e applica i tag definiti dall'utente. È necessario attivare entrambi i tipi di tag separatamente per poterli visualizzare in Gestione dei costi o in un report di allocazione dei costi.
1. Utilizzate i tag di allocazione dei costi per organizzare la AWS fattura in modo da rispecchiare la vostra struttura dei costi. Quando aggiungi tag di allocazione dei costi alle tue risorse in Amazon ElastiCache, sarai in grado di tenere traccia dei costi raggruppando le spese sulle fatture in base ai valori dei tag di risorsa. Puoi anche combinare i tag per monitorare i costi con un livello di dettagli maggiore.
**[Risorse]: **
+ [Utilizzo dei tag di AWS allocazione dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [Monitoraggio dei costi con i tag di allocazione dei costi](Tagging.md)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ **[Migliore]** Collega i ElastiCache costi a metriche valide per tutta l'organizzazione.
1. Prendi in considerazione le metriche aziendali e le metriche operative come la latenza: quali concetti del tuo modello di business sono comprensibili in tutti i ruoli? Le metriche devono essere comprensibili per il maggior numero possibile di ruoli all'interno dell'organizzazione.
1. Esempi: utenti serviti simultaneamente, latenza massima e media per operazione e utente, punteggi di coinvolgimento degli utenti, rendimento degli utenti, tasso di abbandonorates/week, session length/user, tasso di accesso alla cache e chiavi tracciate
**[Risorse]: **
+ [Monitoraggio dell'utilizzo con Metrics CloudWatch ](CacheMetrics.md)
+ **[Buono]** Mantieni la visibilità up-to-date architetturale e operativa su metriche e costi per l'intero carico di lavoro utilizzato. ElastiCache
1. Comprendi l'intero ecosistema di soluzioni, ElastiCache tende a far parte di un ecosistema completo di AWS servizi nel loro set tecnologico, dai client all'API Gateway, Redshift QuickSight e agli strumenti di reporting (ad esempio).
1. Mappa i componenti della soluzione (client, connessioni, sicurezza, operazioni in memoria, archiviazione, automazione delle risorse, accesso e gestione dei dati) nel tuo diagramma di architettura. Ogni livello si collega all'intera soluzione e ha le proprie esigenze e funzionalità che si aggiungono per and/or aiutarti a gestire i costi complessivi.
1. Il diagramma dovrebbe includere l'uso di elaborazione, rete, storage, politiche del ciclo di vita, raccolta di metriche, nonché gli elementi operativi e funzionali dell'applicazione ElastiCache
1. È probabile che i requisiti del carico di lavoro si evolvano nel tempo ed è essenziale continuare a mantenere e documentare la comprensione dei componenti sottostanti e dei propri obiettivi funzionali primari per rimanere proattivi nella gestione dei costi del carico di lavoro.
1. Il supporto esecutivo per la visibilità, la responsabilità, la definizione delle priorità e le risorse è fondamentale per disporre di una strategia di gestione dei costi efficace. ElastiCache
## COSTO 2: Come utilizzate gli strumenti di monitoraggio continuo per ottimizzare i costi associati alle vostre risorse? ElastiCache
**Introduzione a livello di domanda:** è necessario puntare a un giusto equilibrio tra i ElastiCache costi e le metriche relative alle prestazioni delle applicazioni. Amazon CloudWatch offre visibilità sulle principali metriche operative che possono aiutarti a valutare se le tue ElastiCache risorse sono utilizzate in modo eccessivo o insufficiente rispetto alle tue esigenze. Dal punto di vista dell'ottimizzazione dei costi, è necessario capire quando si verifica un eccesso di approvvigionamento ed essere in grado di sviluppare meccanismi appropriati per ridimensionare ElastiCache le risorse, mantenendo al contempo le esigenze operative, di disponibilità, resilienza e prestazioni.
**Vantaggio della domanda: **in un ambiente ideale, hai messo a disposizione risorse sufficienti per soddisfare le esigenze operative del tuo carico di lavoro e non disponi di risorse sottoutilizzate che possono portare costi non ottimali. È necessario essere in grado di identificare ed evitare di utilizzare ElastiCache risorse sovradimensionate per lunghi periodi di tempo.
+ **[Obbligatorio]** CloudWatch Utilizzalo per monitorare ElastiCache i cluster e analizzare come queste metriche si relazionano ai dashboard di AWS Cost Explorer.
1. ElastiCache fornisce sia metriche a livello di host (ad esempio, l'utilizzo della CPU) sia metriche specifiche del software del motore di cache (ad esempio, accessi e mancati accessi alla cache). Questi parametri vengono misurati e pubblicati per ogni nodo di cache in intervalli di 60 secondi.
1. ElastiCache le metriche delle prestazioni (CPUUtilization, EngineUtilization SwapUsage CurrConnections, e sfratti) possono indicare che è necessario scalare up/down (utilizzare larger/smaller tipi di nodi di cache) o shard). in/out (add more/less Comprendi le implicazioni in termini di costi delle decisioni di dimensionamento creando una matrice di playbook che stimi i costi aggiuntivi e i tempi minimi e massimi necessari per raggiungere le soglie di prestazioni delle applicazioni.
**[Risorse]: **
+ [Monitoraggio dell'uso con Metrics CloudWatch ](CacheMetrics.md)
+ [Quali parametri è opportuno monitorare?](CacheMetrics.WhichShouldIMonitor.md)
+ [ ElastiCachePrezzi Amazon](https://aws.amazon.com/elasticache/pricing/)
+ **[Obbligatorio] **Comprendi e documenta la tua strategia di backup e le implicazioni in termini di costi.
1. Con ElastiCache, i backup vengono archiviati in Amazon S3, che fornisce uno storage durevole. È necessario comprendere le implicazioni in termini di costi in relazione alla capacità di ripristino in caso di guasti.
1. Abilita i backup automatici che eliminano i file di backup che hanno superato il limite di conservazione.
**[Risorse]: **
+ [Pianificazione di backup automatici](backups-automatic.md)
+ [Prezzi di Amazon S3](https://aws.amazon.com/s3/pricing/)
+ **[Best practice] **Usa i nodi riservati per le tue istanze come strategia deliberata per gestire i costi dei carichi di lavoro che sono ben appresi e documentati. I nodi riservati vengono addebitati un costo anticipato che dipende dal tipo di nodo e dalla durata della prenotazione, ovvero uno o tre anni. Tale addebito è molto inferiore all'addebito orario di utilizzo previsto in caso di nodi on demand.
1. Potrebbe essere necessario far funzionare ElastiCache i cluster utilizzando nodi su richiesta fino a quando non avrai raccolto dati sufficienti per stimare i requisiti delle istanze riservate. Pianifica e documenta le risorse necessarie per soddisfare le tue esigenze e confronta i costi previsti tra i diversi tipi di istanza (on demand o riservata)
1. Valuta regolarmente i nuovi tipi di nodi di cache disponibili e se ha senso, dal punto di vista dei costi e delle metriche operative, migrare il parco istanze a nuovi tipi di nodi di cache
## COSTI 3: è necessario utilizzare un tipo di istanza che supporti la suddivisione dei dati in più livelli? Quali sono i vantaggi di una suddivisione dei dati in più livelli? Quando non utilizzare le istanze di suddivisione dei dati in più livelli?
**Introduzione della domanda: ** la selezione del tipo di istanza appropriato può avere non solo un impatto sulle prestazioni e sul livello di servizio, ma anche un impatto finanziario. I tipi di istanza hanno costi diversi. La selezione di uno o più tipi di istanze di grandi dimensioni in grado di soddisfare tutte le esigenze di archiviazione in memoria potrebbe essere una decisione naturale. Tuttavia, potrebbe avere un impatto significativo sui costi man mano che il progetto matura. Per garantire che sia selezionato il tipo di istanza corretto è necessario un esame periodico del tempo di inattività dell' ElastiCache oggetto.
**Vantaggio della domanda: **una chiara comprensione dell'impatto dei vari tipi di istanze sui costi attuali e futuri. Le modifiche marginali o periodiche del carico di lavoro non devono causare variazioni sproporzionate dei costi. Se il carico di lavoro lo consente, i tipi di istanze che supportano la suddivisione dei dati in più livelli offrono un prezzo migliore per l'archiviazione disponibile. Grazie allo spazio di archiviazione SSD disponibile per istanza, le istanze con suddivisione dei dati in più livelli supportano una capacità totale di dati per istanza molto più elevata.
+ **[Obbligatorio] **Comprendi i limiti delle istanze con suddivisione dei dati in più livelli
1. Disponibile solo ElastiCache per i cluster Valkey o Redis OSS.
1. Solo tipi di istanza limitati supportano la suddivisione dei dati in più livelli.
1. È ElastiCache supportata solo la versione 6.2 per Redis OSS e versioni successive
1. Gli oggetti di grandi dimensioni non vengono sostituiti in SSD. Gli oggetti superiori a 128 MiB vengono conservati in memoria.
**[Risorse]: **
+ [Tiering di dati](data-tiering.md)
+ [ ElastiCachePrezzi Amazon](https://aws.amazon.com/elasticache/pricing/)
+ **[Obbligatorio] **Scopri la percentuale del database che viene regolarmente utilizzata dal carico di lavoro.
1. Le istanze con suddivisione dei dati in più livelli sono ideali per i carichi di lavoro che spesso accedono a una piccola parte del set di dati complessivo ma richiedono comunque un accesso rapido ai dati rimanenti. In altre parole, il rapporto tra dati caldi e caldi è di circa 20:80.
1. Sviluppa il monitoraggio a livello di cluster dei tempi di inattività degli oggetti.
1. Le grandi implementazioni di oltre 500 GB di dati sono buone candidate
+ **[Obbligatorio] **Tieni presente che le istanze con suddivisione dei dati in più livelli non sono opzionali per determinati carichi di lavoro.
1. L'accesso agli oggetti usati meno frequentemente comporta un costo in termini di prestazioni ridotto, poiché questi vengono sostituiti nel SSD locale. Se la tua applicazione è sensibile ai tempi di risposta, verifica l'impatto sul carico di lavoro.
1. Non adatto per cache che memorizzano principalmente oggetti di grandi dimensioni superiori a 128 MiB.
**[Risorse]: **
+ [Limitazioni](data-tiering.md#data-tiering-prerequisites)
+ **[Best practice] **I tipi di istanze riservate supportano la suddivisione dei dati in più livelli. Ciò garantisce il costo più basso in termini di quantità di archiviazione di dati per istanza.
1. Potrebbe essere necessario gestire ElastiCache i cluster utilizzando istanze di tiering non basate sui dati fino a quando non si avrà una migliore comprensione dei requisiti.
1. Analizza il modello di utilizzo dei dati dei ElastiCache cluster.
1. Crea un processo automatico che raccolga periodicamente i tempi di inattività degli oggetti.
1. Se noti che un'alta percentuale (circa l'80%) di oggetti è inattiva per un periodo di tempo ritenuto appropriato per il tuo carico di lavoro, documenta i risultati e suggerisci di migrare il cluster su istanze che supportano la suddivisione dei dati in più livelli.
1. Valuta regolarmente i nuovi tipi di nodi di cache disponibili e se ha senso, dal punto di vista dei costi e delle metriche operative, migrare il parco istanze a nuovi tipi di nodi di cache.
**[Risorse]: **
+ [OBJECT IDLETIME](https://valkey.io/commands/object-idletime/)
+ [ ElastiCachePrezzi Amazon](https://aws.amazon.com/elasticache/pricing/)
# Procedure di risoluzione dei problemi e procedure consigliate comuni con ElastiCache
I seguenti argomenti forniscono consigli per la risoluzione di errori e problemi che potrebbero verificarsi durante l'utilizzo. ElastiCache In caso di problemi non elencati qui di seguito, è possibile utilizzare il pulsante Feedback in questa pagina per segnalarne l’assenza.
Per ulteriori consigli sulla risoluzione dei problemi e risposte alle domande di supporto più comuni, visita il [AWS Knowledge Center](https://aws.amazon.com/premiumsupport/knowledge-center/)
**Topics**
+ [Problemi di connessione](#wwe-troubleshooting.connection)
+ [Errori del client Valkey o Redis OSS](#wwe-troubleshooting.clienterrors)
+ [Risoluzione dei problemi di latenza elevata in Serverless ElastiCache](#wwe-troubleshooting.latency)
+ [Risoluzione dei problemi di limitazione in Serverless ElastiCache](#wwe-troubleshooting.throttling)
+ [Problemi di connessione persistenti](TroubleshootingConnections.md)
+ [Argomenti correlati](#wwe-troubleshooting.related)
## Problemi di connessione
Se non riesci a connetterti alla ElastiCache cache, prendi in considerazione una delle seguenti opzioni:
1. **Utilizzo di TLS:** se si verifica un blocco della connessione durante il tentativo di connessione all' ElastiCache endpoint, è possibile che non si stia utilizzando TLS nel client. Se utilizzi ElastiCache Serverless, la crittografia in transito è sempre abilitata. Assicurati che il tuo client utilizzi TLS per connettersi alla cache. [Scopri di più sulla connessione a una cache abilitata per TLS](connect-tls.md).
1. **VPC:** le ElastiCache cache sono accessibili solo dall'interno di un VPC. Assicurati che l' EC2 istanza da cui accedi alla cache e alla ElastiCache cache siano create nello stesso VPC. In alternativa, devi abilitare il [peering VPC tra](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) il VPC in cui EC2 risiede l'istanza e il VPC in cui stai creando la cache.
1. **Gruppi di sicurezza:** ElastiCache utilizza i gruppi di sicurezza per controllare l'accesso alla cache. Considera i seguenti aspetti:
1. Assicurati che il gruppo di sicurezza utilizzato dalla ElastiCache cache consenta l'accesso in entrata dalla tua EC2 istanza. Vedi [qui](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) per scoprire come configurare correttamente le regole in entrata nel tuo gruppo di sicurezza.
1. Assicurati che il gruppo di sicurezza utilizzato dalla ElastiCache cache consenta l'accesso alle porte della cache (6379 e 6380 per i server senza server e 6379 per impostazione predefinita per i cluster basati su nodi). ElastiCache utilizza queste porte per accettare i comandi Valkey o Redis OSS. [Scopri di più su come configurare l'accesso alle porte qui.](set-up.md#elasticache-install-grant-access-VPN)
Se la connessione continua a essere difficile, consulta [Problemi di connessione persistenti](TroubleshootingConnections.md) gli altri passaggi.
## Errori del client Valkey o Redis OSS
ElastiCache Serverless è accessibile solo tramite client che supportano il protocollo in modalità cluster Valkey o Redis OSS. È possibile accedere ai cluster basati su nodi dai client in entrambe le modalità, a seconda della configurazione del cluster.
Se riscontri errori nel tuo client, considera quanto segue:
1. **Modalità cluster:** se si verificano errori CROSSLOT o errori con il comando [SELECT](https://valkey.io/commands/select/), è possibile che si stia tentando di accedere a una cache Cluster Mode Enabled con un client Valkey o Redis OSS che non supporta il protocollo Cluster. ElastiCache Serverless supporta solo client che supportano il protocollo cluster Valkey o Redis OSS. Se desideri utilizzare Valkey o Redis OSS in «Cluster Mode Disabled» (CMD), devi creare un cluster basato su nodi.
1. **Errori CROSSLOT:** se si verifica l'`ERR CROSSLOT Keys in request don't hash to the same slot`errore, è possibile che si stia tentando di accedere a chiavi che non appartengono allo stesso slot in una cache in modalità Cluster. Come promemoria, ElastiCache Serverless funziona sempre in modalità Cluster. Le operazioni a più chiavi, le transazioni o gli script Lua che coinvolgono più chiavi sono consentite solo se tutte le chiavi coinvolte si trovano nello stesso slot di hash.
[Per ulteriori best practice sulla configurazione dei client Valkey o Redis OSS, consulta questo post sul blog.](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/)
## Risoluzione dei problemi di latenza elevata in Serverless ElastiCache
Se il tuo carico di lavoro sembra presentare un'elevata latenza, puoi analizzare le `SuccessfulWriteRequestLatency` metriche CloudWatch `SuccessfulReadRequestLatency` e per verificare se la latenza è correlata a Serverless. ElastiCache Queste metriche misurano la latenza interna a ElastiCache Serverless: la latenza lato client e i tempi di viaggio di rete tra il client e l'endpoint Serverless non sono inclusi. ElastiCache
**Risoluzione dei problemi di latenza lato client**
Se notate una latenza elevata sul lato client ma nessun aumento corrispondente `` CloudWatch `SuccessfulReadRequestLatency` e `SuccessfulWriteRequestLatency` metriche che misurano la latenza lato server, considerate quanto segue:
+ **Assicurati che il gruppo di sicurezza consenta l'accesso alle porte 6379 e 6380:** ElastiCache Serverless utilizza la porta 6379 per l'endpoint primario e la porta 6380 per l'endpoint del lettore. Alcuni client stabiliscono la connettività a entrambe le porte per ogni nuova connessione, anche se l'applicazione non utilizza la funzionalità Read from Replica. Se il gruppo di sicurezza non consente l'accesso in entrata a entrambe le porte, la creazione della connessione può richiedere più tempo. Scopri di più su come configurare l'accesso alle porte [qui](set-up.md#elasticache-install-grant-access-VPN).
**Risoluzione dei problemi di latenza lato server**
Alcune variabilità e i picchi occasionali non dovrebbero essere motivo di preoccupazione. Tuttavia, se la `Average` statistica mostra un forte aumento e persiste, dovresti controllare la Personal Health Dashboard Health Dashboard e la tua Personal Health Dashboard per ulteriori informazioni. Se necessario, valuta la possibilità di aprire una richiesta di supporto con.Supporto
Prendi in considerazione le seguenti best practice e strategie per ridurre la latenza:
+ **Abilita Read from Replica:** se la tua applicazione lo consente, ti consigliamo di abilitare la funzionalità «Read from Replica» nel tuo client Valkey o Redis OSS per scalare le letture e ottenere una latenza inferiore. Se abilitata, ElastiCache Serverless tenta di indirizzare le richieste di lettura verso i nodi della cache di replica che si trovano nella stessa zona di disponibilità (AZ) del client, evitando così la latenza di rete Cross-AZ. Tieni presente che l'attivazione della funzionalità Read from Replica nel client significa che l'applicazione accetta l'eventuale coerenza dei dati. L'applicazione potrebbe ricevere dati più vecchi per qualche tempo se si tenta di leggere dopo aver scritto su una chiave.
+ **Assicurati che l'applicazione sia distribuita nella AZs stessa cache:** potresti osservare una maggiore latenza lato client se l'applicazione non è distribuita nella AZs stessa cache. Quando si crea una cache serverless, è possibile fornire le sottoreti da cui l'applicazione accederà alla cache e ElastiCache Serverless crea endpoint VPC in tali sottoreti. Assicurati che l'applicazione sia distribuita nella stessa. AZs In caso contrario, l'applicazione potrebbe subire un hop Cross-AZ quando accede alla cache, con conseguente maggiore latenza lato client.
+ **Riutilizza le connessioni: le** richieste ElastiCache serverless vengono effettuate tramite una connessione TCP abilitata per TLS utilizzando il protocollo RESP. L'avvio della connessione (inclusa l'autenticazione della connessione, se configurata) richiede tempo, quindi la latenza della prima richiesta è superiore a quella tipica. Le richieste su una connessione già inizializzata offrono ElastiCache una latenza costantemente bassa. Per questo motivo, dovresti prendere in considerazione l'utilizzo del pool di connessioni o il riutilizzo delle connessioni Valkey o Redis OSS esistenti.
+ **Velocità di scalabilità:** ElastiCache Serverless si ridimensiona automaticamente all'aumentare della frequenza delle richieste. Un aumento improvviso e significativo della frequenza di richieste, superiore alla velocità di scalabilità di ElastiCache Serverless, può comportare una latenza elevata per qualche tempo. ElastiCache In genere, Serverless può aumentare rapidamente la frequenza di richieste supportata, impiegando fino a 10-12 minuti per raddoppiare la frequenza delle richieste.
+ **Ispeziona i comandi a esecuzione prolungata:** alcuni comandi Valkey o Redis OSS, inclusi gli script Lua o i comandi su strutture di dati di grandi dimensioni, possono essere eseguiti a lungo. Per identificare questi comandi, pubblica metriche a livello di comando. ElastiCache Con [ElastiCache Serverless](serverless-metrics-events-redis.md#serverless-metrics) puoi usare le metriche. `BasedECPUs`
+ **Richieste limitate: quando le richieste** vengono limitate in ElastiCache Serverless, è possibile che si verifichi un aumento della latenza lato client nell'applicazione. [Quando le richieste vengono limitate in ElastiCache Serverless, dovresti notare un aumento della metrica Serverless. `ThrottledRequests` ElastiCache ](serverless-metrics-events-redis.md#serverless-metrics) Consulta la sezione seguente per la risoluzione dei problemi relativi alle richieste limitate.
+ **Distribuzione uniforme di chiavi e richieste:** ElastiCache per Valkey e Redis OSS, una distribuzione non uniforme di chiavi o richieste per slot può causare un hot slot che può comportare una latenza elevata. ElastiCache Serverless supporta fino a 30.000 ECPUs/second (90.000 ECPUs/second se si utilizza Read from Replica) su un singolo slot, in un carico di lavoro che esegue comandi semplici. SET/GET Ti consigliamo di valutare la distribuzione delle chiavi e delle richieste tra gli slot e di garantire una distribuzione uniforme se la frequenza delle richieste supera questo limite.
## Risoluzione dei problemi di limitazione in Serverless ElastiCache
Nelle architetture orientate ai servizi e nei sistemi distribuiti, la limitazione della velocità con cui le chiamate API vengono elaborate dai vari componenti del servizio si chiama limitazione (della larghezza di banda della rete). Ciò attenua i picchi, controlla le discrepanze nella velocità di trasmissione dei componenti e consente ripristini più prevedibili in caso di eventi operativi imprevisti. ElastiCache Serverless è progettato per questi tipi di architetture e la maggior parte dei client Valkey o Redis OSS dispone di nuovi tentativi integrati per le richieste limitate. Un certo grado di limitazione (della larghezza di banda della rete) non è necessariamente un problema per l'applicazione, ma una limitazione (della larghezza di banda della rete) persistente di una parte sensibile alla latenza del flusso di lavoro dei dati può influire negativamente sull'esperienza dell'utente e ridurre l'efficienza complessiva del sistema.
[Quando le richieste vengono limitate in Serverless, dovresti notare un aumento della metrica ElastiCache Serverless. `ThrottledRequests` ElastiCache ](serverless-metrics-events-redis.md#serverless-metrics) Se notate un numero elevato di richieste limitate, considerate quanto segue:
+ **Velocità di scalabilità:** ElastiCache Serverless si ridimensiona automaticamente man mano che si acquisiscono più dati o si aumenta la frequenza delle richieste. Se l'applicazione si adatta più velocemente della scalabilità Serverless, le richieste potrebbero essere limitate mentre ElastiCache Serverless si ridimensiona per adattarsi al carico di lavoro. ElastiCache ElastiCache In genere, la modalità serverless consente di aumentare rapidamente le dimensioni di storage, impiegando fino a 10-12 minuti per raddoppiare le dimensioni di archiviazione nella cache.
+ **Distribuzione uniforme di chiavi e richieste:** in ElastiCache Valkey e Redis OSS, una distribuzione non uniforme delle chiavi o delle richieste per slot può causare un hot slot. Un hot slot può comportare una limitazione delle richieste, se la frequenza delle richieste verso un singolo slot supera 30.000 ECPUs/second e si trova in un carico di lavoro che esegue comandi semplici. SET/GET Analogamente, con ElastiCache Memcached, un tasto di scelta rapida può comportare una limitazione delle richieste se la frequenza delle richieste supera 30.000 /secondo. ECPUs
+ **Leggi da Replica:** se l'applicazione lo consente, prendi in considerazione l'utilizzo della funzione «Leggi dalla replica». La maggior parte dei client Valkey o Redis OSS può essere configurata per «scalare le letture» per indirizzare le letture ai nodi di replica. Questa funzionalità consente di scalare il traffico di lettura. Inoltre, ElastiCache Serverless indirizza automaticamente la lettura dalle richieste di replica ai nodi nella stessa zona di disponibilità dell'applicazione, con conseguente riduzione della latenza. Quando Read from Replica è abilitato, è possibile ottenere fino a 90.000 unità ECPUs/second su un singolo slot, per carichi di lavoro con comandi semplici. SET/GET
# Problemi di connessione persistenti
I seguenti elementi devono essere verificati durante la risoluzione dei problemi di connettività persistenti con ElastiCache:
**Topics**
+ [Gruppi di sicurezza](#Security_groups)
+ [Rete ACLs](#Network_ACLs)
+ [Tabelle di instradamento](#Route_tables)
+ [Risoluzione DNS](#DNS_Resolution)
+ [Identificazione dei problemi con la diagnostica lato server](#Diagnostics)
+ [Convalida della connettività di rete](#Connectivity)
+ [Limiti relativi alla rete](#Network-limits)
+ [Utilizzo CPU](#CPU-Usage)
+ [Connessioni terminate dal lato server](#Connections-server)
+ [Risoluzione dei problemi lato client per le istanze Amazon EC2](#Connections-client)
+ [Dissezione del tempo necessario per completare una singola richiesta](#Dissecting-time)
## Gruppi di sicurezza
I gruppi di sicurezza sono firewall virtuali che proteggono il ElastiCache client (EC2 istanza, AWS Lambda funzione, contenitore Amazon ECS, ecc.) e ElastiCache la cache. I gruppi di sicurezza sono dotati di stato, il che significa che dopo che il traffico in entrata o in uscita è consentito, le risposte per tale traffico verranno automaticamente autorizzate nel contesto di tale gruppo di sicurezza specifico.
La funzionalità con stato richiede che il gruppo di sicurezza monitori tutte le connessioni autorizzate ed esiste un limite per le connessioni monitorate. Se il limite viene raggiunto, le nuove connessioni avranno esito negativo. Consulta la sezione dedicata alla risoluzione dei problemi per sapere se il client o ElastiCache il lato client hanno raggiunto i limiti.
È possibile assegnare contemporaneamente un singolo gruppo di sicurezza al client e al ElastiCache cluster o singoli gruppi di sicurezza per ciascuno.
In entrambi i casi, è necessario consentire il traffico TCP in uscita sulla ElastiCache porta dall'origine e il traffico in entrata sulla stessa porta verso. ElastiCache La porta predefinita è 11211 per Memcached e 6379 per Valkey o Redis OSS. Per impostazione predefinita, i gruppi di sicurezza autorizzano tutto il traffico in uscita. In questo caso, è necessaria solo la regola in entrata nel gruppo di sicurezza di destinazione.
Per ulteriori informazioni, consulta [Modelli di accesso per l'accesso a un ElastiCache cluster in un Amazon VPC](elasticache-vpc-accessing.md).
## Rete ACLs
Le liste di controllo degli accessi alla rete (ACLs) sono regole senza stato. Il traffico deve essere consentito in entrambe le direzioni (in entrata e in uscita) per avere esito positivo. ACLs Le reti sono assegnate a sottoreti, non a risorse specifiche. È possibile assegnare lo stesso ACL ElastiCache e la stessa risorsa client, specialmente se si trovano nella stessa sottorete.
Per impostazione predefinita, la rete ACLs consente tutto il traffico. Tuttavia, è possibile personalizzarle per negare o consentire il traffico. Inoltre, la valutazione delle regole delle ACL è sequenziale, ossia la regola con il numero più basso corrispondente al traffico consentirà o negherà tale traffico. La configurazione minima per consentire il traffico Valkey o Redis OSS è:
ACL di rete lato client:
+ **Regole in entrata:**
+ Numero della regola: preferibilmente inferiore a qualsiasi regola di diniego;
+ Tipo: Regola TCP personalizzata;
+ Protocollo: TCP
+ Intervallo porte: 1024-65535
+ Fonte: 0.0.0.0/0 (o crea regole individuali per le sottoreti del cluster) ElastiCache
+ Consenti/Nega: Consenti
+ **Regole in uscita:**
+ Numero della regola: preferibilmente inferiore a qualsiasi regola di diniego;
+ Tipo: Regola TCP personalizzata;
+ Protocollo: TCP
+ Intervallo porte: 6379
+ Fonte: 0.0.0.0/0 (o le sottoreti del cluster. ElastiCache Tieni presente che l'utilizzo di specifiche IPs può creare problemi in caso di failover o scalabilità del cluster)
+ Consenti/Nega: Consenti
ElastiCache ACL di rete:
+ **Regole in entrata:**
+ Numero della regola: preferibilmente inferiore a qualsiasi regola di diniego;
+ Tipo: Regola TCP personalizzata;
+ Protocollo: TCP
+ Intervallo porte: 6379
+ Fonte: 0.0.0.0/0 (o crea regole individuali per le sottoreti del cluster) ElastiCache
+ Consenti/Nega: Consenti
+ **Regole in uscita:**
+ Numero della regola: preferibilmente inferiore a qualsiasi regola di diniego;
+ Tipo: Regola TCP personalizzata;
+ Protocollo: TCP
+ Intervallo porte: 1024-65535
+ Fonte: 0.0.0.0/0 (o le sottoreti del cluster. ElastiCache Tieni presente che l'utilizzo di specifiche IPs può creare problemi in caso di failover o scalabilità del cluster)
+ Consenti/Nega: Consenti
[Per ulteriori informazioni, consulta Rete. ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)
## Tabelle di instradamento
Analogamente alla rete ACLs, ogni sottorete può avere tabelle di routing diverse. Se i client e il ElastiCache cluster si trovano in sottoreti diverse, assicurati che le relative tabelle di routing consentano loro di raggiungersi.
La risoluzione di ambienti più complessi, che richiedono routing dinamico VPCs multiplo o firewall di rete, può diventare difficile da risolvere. Consultare [Convalida della connettività di rete](#Connectivity) per verificare che le impostazioni di rete siano appropriate.
## Risoluzione DNS
ElastiCache fornisce gli endpoint del servizio in base ai nomi DNS. Gli endpoint disponibili sono `Configuration`, `Primary`, `Reader` e`Node`. Per maggiori informazioni, consultare [Trovare gli endpoint di connessione](Endpoints.md).
In caso di failover o di modifica del cluster, l'indirizzo associato al nome dell'endpoint potrebbe cambiare e verrà aggiornato automaticamente.
Le impostazioni DNS personalizzate (ad esempio, che non utilizzano il servizio DNS VPC) potrebbero non essere a conoscenza dei ElastiCache nomi DNS forniti. Assicurati che il tuo sistema sia in grado di risolvere correttamente gli ElastiCache endpoint utilizzando strumenti di sistema come `dig` (come illustrato di seguito) o. `nslookup`
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4
```
È inoltre possibile forzare la risoluzione dei nomi tramite il servizio del DNS VPC:
```
$ 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
```
## Identificazione dei problemi con la diagnostica lato server
CloudWatch le metriche e le informazioni sul tempo di funzionamento del ElastiCache motore sono fonti o informazioni comuni per identificare potenziali fonti di problemi di connessione. Una buona analisi inizia comunemente con i seguenti elementi:
+ Utilizzo della CPU: Valkey e Redis OSS sono applicazioni multithread. Tuttavia, l'esecuzione di ogni comando avviene in un singolo thread (principale). Per questo motivo, ElastiCache fornisce le metriche e. `CPUUtilization` `EngineCPUUtilization` `EngineCPUUtilization`fornisce l'utilizzo della CPU dedicato al processo Valkey o Redis OSS e `CPUUtilization` l'utilizzo in tutti i v. CPUs I nodi con più di una vCPU in genere hanno valori diversi per `CPUUtilization` e `EngineCPUUtilization` il secondo è generalmente più alto. Un elevato `EngineCPUUtilization` può essere causato da un numero elevato di richieste o operazioni complesse che richiedono una notevole quantità di tempo di CPU per il completamento. È possibile identificare entrambi con i seguenti elementi:
+ Numero elevato di richieste: verifica la presenza di aumenti su altri parametri che corrispondono al modello `EngineCPUUtilization`. I parametri utili sono:
+ `CacheHits` e `CacheMisses`: il numero di richieste corrette o richieste che non hanno trovato un elemento valido nella cache. Se il rapporto tra perdite e successi è elevato, l'applicazione sta sprecando tempo e risorse con richieste infruttuose.
+ `SetTypeCmds` e `GetTypeCmds`: questi parametri correlati con `EngineCPUUtilization` possono aiutare a capire se il carico è significativamente più alto per le richieste di scrittura, misurato da `SetTypeCmds`, o letture, misurate da `GetTypeCmds`. Se il carico è prevalentemente di lettura, l'utilizzo di più repliche di lettura può bilanciare le richieste su più nodi e risparmiare il primario per le scritture. Nei cluster disattivati in modalità cluster, è possibile utilizzare le repliche di lettura creando una configurazione di connessione aggiuntiva nell'applicazione utilizzando l'endpoint di lettura. ElastiCache Per maggiori informazioni, consultare [Trovare gli endpoint di connessione](Endpoints.md). Le operazioni di lettura devono essere inviate a questa connessione aggiuntiva. Le operazioni di scrittura verranno eseguite attraverso l'endpoint primario regolare. In modalità cluster abilitata, è consigliabile utilizzare una libreria che supporti le repliche di lettura in modalità nativa. Con i flag giusti, la libreria sarà in grado di scoprire automaticamente la topologia del cluster, i nodi di replica, abilitare le operazioni di lettura tramite il comando READONLY Valkey o Redis OSS e inviare le richieste di [lettura](https://valkey.io/commands/readonly) alle repliche.
+ Elevato numero di connessioni:
+ `CurrConnections` e `NewConnections`: `CurrConnection` è il numero di connessioni stabilite al momento della raccolta dei datapoint, mentre `NewConnections` mostra quante connessioni sono state create nel periodo.
La creazione e la gestione delle connessioni implica un notevole overhead della CPU. Inoltre, l'handshake a tre vie TCP richiesto per creare nuove connessioni influirà negativamente sui tempi di risposta complessivi.
Un ElastiCache nodo con migliaia di dati `NewConnections` al minuto indica che una connessione viene creata e utilizzata con pochi comandi, il che non è ottimale. Mantenere le connessioni stabilite e riutilizzarle per nuove operazioni è una best practice. Ciò è possibile quando l'applicazione client supporta e implementa correttamente il pool di connessioni o le connessioni persistenti. Con il pool di connessioni, il numero di `currConnections` non ha grandi variazioni, e le `NewConnections` dovrebbero essere il più basso possibile. Valkey e Redis OSS offrono prestazioni ottimali con un numero limitato di CurrConnections. Mantenere currConnection nell'ordine di decine o centinaia riduce al minimo l'utilizzo di risorse per supportare singole connessioni come buffer client e cicli CPU per servire la connessione.
+ Velocità effettiva di rete
+ Determina la larghezza di banda: ElastiCache i nodi hanno una larghezza di banda di rete proporzionale alla dimensione del nodo. Poiché le applicazioni hanno caratteristiche diverse, i risultati possono variare in base al carico di lavoro. Ad esempio, le applicazioni con un elevato tasso di richieste di piccole dimensioni tendono a influire di più sull'utilizzo della CPU rispetto alla velocità effettiva di rete, mentre le chiavi più grandi causeranno un maggiore utilizzo della rete. Per questo motivo, è consigliabile testare i nodi con il carico di lavoro effettivo per una migliore comprensione dei limiti.
La simulazione del carico dall'applicazione fornirebbe risultati più accurati. Tuttavia, gli strumenti relativi al valore di riferimento possono dare una buona idea dei limiti.
+ Nei casi in cui le richieste sono prevalentemente letture, l'utilizzo delle repliche per le operazioni di lettura riduce il carico sul nodo primario. Se il caso d'uso è prevalentemente scritture, l'uso di molte repliche amplificerà l'utilizzo della rete. Per ogni byte scritto nel nodo primario, N byte verranno inviati alle repliche, essendo N il numero di repliche. La best practice per i carichi di lavoro con uso intensivo di scrittura è quella di utilizzare ElastiCache Redis OSS con la modalità cluster abilitata, in modo che le scritture possano essere bilanciate su più shard o scalare fino a un tipo di nodo con maggiori funzionalità di rete.
+ I CloudWatchmetrics `NetworkBytesIn` e `NetworkBytesOut` forniscono rispettivamente la quantità di dati in entrata o in uscita dal nodo. `ReplicationBytes`è il traffico dedicato alla replica dei dati.
Per ulteriori informazioni, consulta [Limiti relativi alla rete](#Network-limits).
+ Comandi complessi: i comandi Redis OSS vengono serviti su un singolo thread, il che significa che le richieste vengono servite in sequenza. Un singolo comando lento può influire su altre richieste e connessioni, culminando in time-out. L'uso di comandi che agiscono su più valori, chiavi o tipi di dati deve essere fatto con attenzione. Le connessioni possono essere bloccate o terminate a seconda del numero di parametri o delle dimensioni dei valori di input o output.
Un esempio famigerato è il comando `KEYS`. Esso spazza l'intero keyspace alla ricerca di un dato modello e blocca l'esecuzione di altri comandi durante la sua esecuzione. Redis OSS utilizza la notazione «Big O» per descrivere la complessità dei comandi.
Il comando delle chiavi ha complessità di tempo O(N), dove N è il numero di chiavi presenti nel database. Pertanto, maggiore è il numero di chiavi, più lento sarà il comando. `KEYS` può causare problemi in diversi modi: se non viene utilizzato alcun modello di ricerca, il comando restituirà tutti i nomi delle chiavi disponibili. Nei database con migliaia o milioni di elementi, verrà creato un output enorme e inonderà i buffer di rete.
Se viene utilizzato un modello di ricerca, solo le chiavi corrispondenti al modello torneranno al client. Tuttavia, il motore continua a spazzare l'intero keyspace alla sua ricerca e il tempo necessario per completare il comando sarà lo stesso.
Un'alternativa per `KEYS` è il comando `SCAN`. Si ripete sul keyspace e limita le iterazioni in un numero specifico di elementi, evitando blocchi prolungati sul motore.
La scansione ha il parametro `COUNT`, utilizzato per impostare la dimensione dei blocchi di iterazione. Il valore di default è 10 (10 elementi per iterazione).
A seconda del numero di elementi nel database, piccoli blocci di valori `COUNT` richiedono più iterazioni per completare una scansione completa e valori più grandi manterranno il motore occupato più a lungo ad ogni iterazione. Mentre piccoli valori di conteggio renderanno `SCAN` più lento su database di grandi dimensioni, valori più grandi possono causare gli stessi problemi menzionati per `KEYS`.
Ad esempio, l'esecuzione del comando `SCAN` con valore di conteggio di 10 richiederà 100.000 ripetizioni su un database con 1 milione di chiavi. Se il Round Trip Time medio della rete è di 0,5 millisecondi, verranno spesi circa 50.000 millisecondi (50 secondi) per trasferire le richieste.
D'altra parte, se il valore di conteggio fosse 100.000, sarebbe necessaria una singola iterazione e solo 0,5 ms sarebbero spesi per trasferirla. Tuttavia, il motore sarebbe completamente bloccato per altre operazioni fino a quando il comando non termina di spazzare tutto il keyspace.
Oltre a `KEYS`, molti altri comandi sono potenzialmente dannosi se non utilizzati correttamente. Per visualizzare un elenco di tutti i comandi e la rispettiva complessità temporale, vai ai comandi [Valkey e Redis OSS](https://valkey.io/commands).
Esempi di potenziali problemi:
+ Script Lua: Valkey e Redis OSS forniscono un interprete Lua integrato, che consente l'esecuzione di script sul lato server. Gli script Lua su Valkey e Redis OSS vengono eseguiti a livello di motore e sono atomici per definizione, il che significa che nessun altro comando o script potrà essere eseguito mentre uno script è in esecuzione. Gli script Lua offrono la possibilità di eseguire più comandi, algoritmi decisionali, analisi dei dati e altro direttamente sul motore. Mentre l'atomicità degli script e la possibilità di scaricare l'applicazione sono allettanti, gli script devono essere utilizzati con cura e per piccole operazioni. Attivo ElastiCache, il tempo di esecuzione degli script Lua è limitato a 5 secondi. Gli script che non sono stati scritti nel keyspacei verranno terminati automaticamente dopo un periodo di 5 secondi. Per evitare il danneggiamento dei dati e le incongruenze, il nodo eseguirà il failover se l'esecuzione dello script non è stata completata in 5 secondi e durante l'esecuzione non è stata eseguita alcuna scrittura. [Le transazioni](https://valkey.io/topics/transactions) sono l'alternativa per garantire la coerenza di più modifiche chiave correlate in Redis OSS. Una transazione consente l'esecuzione di un blocco di comandi, osservando le chiavi esistenti per le modifiche. Se una delle chiavi osservate cambia prima del completamento della transazione, tutte le modifiche vengono scartate.
+ Eliminazione di massa di elementi: il comando `DEL` accetta più parametri, che sono i nomi di chiave da eliminare. Le operazioni di eliminazione sono sincrone e richiedono un tempo significativo della CPU se l'elenco dei parametri è grande, o contiene un elenco grande, un set ordinato o un hash (strutture di dati che contengono più sottovoci). In altre parole, anche la cancellazione di una singola chiave può richiedere tempo significativo se ha molti elementi. L'alternativa `DEL` è`UNLINK`, che è un comando asincrono disponibile a partire da Redis OSS 4. `UNLINK`deve essere preferito rispetto a quando possibile. `DEL` A ElastiCache partire da Redis OSS 6x, il `lazyfree-lazy-user-del` parametro fa sì che il `DEL` comando si comporti come `UNLINK` quando è abilitato. Per ulteriori informazioni, consulta Modifiche ai parametri di [Redis OSS 6.0](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
+ Comandi che agiscono su più chiavi: `DEL` è stato menzionato prima come comando che accetta più argomenti e il suo tempo di esecuzione sarà direttamente proporzionale a quello. Tuttavia, Redis OSS fornisce molti altri comandi che funzionano in modo simile. Ad esempio, `MSET` e `MGET` consentono l'inserimento o il recupero di più chiavi di stringa contemporaneamente. Il loro utilizzo può essere utile per ridurre la latenza di rete intrinseca a più comandi `SET` o `GET` individuali. Tuttavia, un ampio elenco di parametri influenzerà l'utilizzo della CPU.
Sebbene l'utilizzo della CPU da solo non sia la causa di problemi di connettività, dedicare troppo tempo all'elaborazione di uno o pochi comandi su più chiavi può causare l’utilizzo fuori limite di altre richieste e aumentare l'utilizzo complessivo della CPU.
Il numero di chiavi e le loro dimensioni influenzeranno la complessità del comando e, di conseguenza, il tempo di completamento.
Altri esempi di comandi che possono agire su più chiavi: `HMGET`, `HMSET`, `MSETNX`, `PFCOUNT`, `PFMERGE`, `SDIFF`, `SDIFFSTORE`, `SINTER`, `SINTERSTORE`, `SUNION`, `SUNIONSTORE`, `TOUCH`, `ZDIFF`, `ZDIFFSTORE`, `ZINTER` o `ZINTERSTORE`.
+ Comandi che agiscono su più tipi di dati: Redis OSS fornisce anche comandi che agiscono su una o più chiavi, indipendentemente dal tipo di dati. ElastiCache for Redis OSS fornisce la metrica `KeyBasedCmds` per monitorare tali comandi. Questo parametro somma l'esecuzione dei seguenti comandi nel periodo selezionato:
+ Complessità O(N):
+ `KEYS`
+ O(1)
+ `EXISTS`
+ `OBJECT`
+ `PTTL`
+ `RANDOMKEY`
+ `TTL`
+ `TYPE`
+ `EXPIRE`
+ `EXPIREAT`
+ `MOVE`
+ `PERSIST`
+ `PEXPIRE`
+ `PEXPIREAT`
+ `UNLINK (O(N)` per recuperare memoria. Tuttavia il processo di recupero della memoria avviene in un thread separato e non blocca il motore
+ Tempi di complessità differenti a seconda del tipo di dati:
+ `DEL`
+ `DUMP`
+ `RENAME` è considerato un comando con complessità O(1), ma esegue `DEL` internamente. Il tempo di esecuzione varia a seconda delle dimensioni della chiave rinominata.
+ `RENAMENX`
+ `RESTORE`
+ `SORT`
+ Big hash: Hash è un tipo di dati che consente una singola chiave con più sottoelementi chiave-valore. Ogni hash può archiviare 4.294.967.295 elementi e le operazioni su hash di grandi dimensioni possono diventare costose. Analogamente a `KEYS`, gli hash hanno il comando `HKEYS` con complessità temporale O(N), dove N è il numero di elementi nell'hash.`HSCAN` deve essere preferito a `HKEYS` per evitare comandi di lunga durata. `HDEL`, `HGETALL`, `HMGET`, `HMSET` e `HVALS` sono comandi che dovrebbero essere usati con cautela su hash di grandi dimensioni.
+ Altre strutture Big Data: oltre agli hash, altre strutture di dati possono richiedere un uso intensivo della CPU. Insiemi, elenchi, insiemi ordinati e hyperloglog possono anche richiedere molto tempo per essere manipolati a seconda delle dimensioni e dei comandi utilizzati. Per ulteriori informazioni su questi comandi, consulta Comandi [Valkey e Redis OSS](https://valkey.io/commands).
## Convalida della connettività di rete
Dopo aver esaminato le configurazioni di rete relative alla risoluzione DNS, ai gruppi di sicurezza, alla rete e alle tabelle di ACLs routing, la connettività può essere convalidata con VPC Reachability Analyzer e gli strumenti di sistema.
Reachability Analyzer verificherà la connettività di rete e confermerà se tutti i requisiti e le autorizzazioni sono soddisfatti. Per i test seguenti è necessario l'ENI ID (Elastic Network Interface Identification) di uno dei ElastiCache nodi disponibili nel tuo VPC. È possibile trovarlo eseguendo le seguenti operazioni:
1. Vai a [https://console.aws.amazon.com/ec2/v2/home? \$1NIC:](https://console.aws.amazon.com/ec2/v2/home?#NIC)
1. Filtra l'elenco delle interfacce in base al nome del ElastiCache cluster o all'indirizzo IP ottenuto dalle convalide DNS precedenti.
1. Annotare o comunque salvare l'ID ENI. Se vengono visualizzate più interfacce, rivedi la descrizione per confermare che appartengano al ElastiCache cluster corretto e scegline una.
1. Passare alla fase successiva.
1. Vuoi creare un percorso di analisi a [https://console.aws.amazon.com/vpc/casa? ](https://console.aws.amazon.com/vpc/home?#ReachabilityAnalyzer)\$1 ReachabilityAnalyzer e scegliete le seguenti opzioni:
+ **Tipo di origine**: scegli l'**istanza** se il tuo ElastiCache client funziona su un' EC2 istanza Amazon o un'**interfaccia di rete** se utilizza un altro servizio, come AWS Fargate Amazon ECS con rete awsvpc AWS Lambda, ecc.) e il rispettivo ID di risorsa (EC2 istanza o ID ENI);
+ **Tipo di destinazione**: Scegliere **Interfaccia di rete** e selezionare il **ENI di ElastiCache**dall'elenco.
+ **Porta di destinazione**: specifica 6379 per Redis OSS o ElastiCache 11211 per Memcached. ElastiCache Queste sono le porte definite con la configurazione di default e questo esempio presuppone che non vengano modificate.
+ **Protocollo**: TCP
Creare il percorso di analisi e attendere alcuni minuti per il risultato. Se lo stato non è raggiungibile, aprire i dettagli dell'analisi ed esaminare **Esplora analisi** per i dettagli in cui le richieste sono state bloccate.
Se i test di raggiungibilità sono stati superati, procedere alla verifica a livello di sistema operativo.
Per convalidare la connettività TCP sulla porta di ElastiCache servizio: su Amazon Linux, `Nping` è disponibile nel pacchetto `nmap` e può testare la connettività TCP sulla ElastiCache porta, oltre a fornire il tempo di andata e ritorno della rete per stabilire la connessione. Usalo per convalidare la connettività di rete e la latenza corrente verso il cluster, come illustrato di seguito: ElastiCache
```
$ 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
```
Per impostazione predefinita, `nping` invia 5 sonde con un ritardo di 1 secondo tra di loro. È possibile utilizzare l'opzione “-c” per aumentare il numero di sonde e “--delay” per cambiare il tempo di invio di un nuovo test.
Se i test con `nping` falliscono e i test del *VPC Reachability Analyzer* passano, chiedere all'amministratore di sistema di esaminare le possibili regole firewall basate su host, regole di routing asimmetriche o qualsiasi altra possibile restrizione a livello di sistema operativo.
Sulla ElastiCache console, controlla se **Encryption in-transit** è abilitata nei dettagli del cluster ElastiCache . Se la crittografia in transito è abilitata, verificare se la sessione della TLS può essere stabilita con il seguente comando:
```
openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379
```
Un output esteso è previsto se la connessione e la negoziazione relativa alla TLS hanno esito positivo. Controllare il codice restituito disponibile nell'ultima riga, il valore deve essere `0 (ok)`. [Se openssl restituisce qualcosa di diverso, controlla il motivo dell'errore su \$1DIAGNOSTICS. https://www.openssl.org/docs/man1.0.2/man1/verify.html](https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS)
Se tutti i test dell'infrastruttura e del sistema operativo sono stati superati ma l'applicazione non è ancora in grado di connettersi ElastiCache, controlla se le configurazioni dell'applicazione sono conformi alle impostazioni. ElastiCache Gli errori più comuni sono:
+ L'applicazione non supporta la modalità ElastiCache cluster e la modalità cluster ElastiCache è abilitata;
+ L'applicazione non supporta TLS/SSL e ElastiCache ha la crittografia in transito abilitata;
+ L'applicazione supporta TLS/SSL ma non dispone dei flag di configurazione corretti o di autorità di certificazione affidabili;
## Limiti relativi alla rete
+ Numero massimo di connessioni: ci sono limiti rigidi per le connessioni simultanee. Ogni ElastiCache nodo consente fino a 65.000 connessioni simultanee su tutti i client. Questo limite può essere monitorato tramite le `CurrConnections` metriche di. CloudWatch Tuttavia, i client hanno anche i loro limiti per le connessioni in uscita. Su Linux, controllare l'intervallo di porte effimere consentito con il comando:
```
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
```
Nell'esempio precedente, saranno consentite 28231 connessioni dalla stessa origine, allo stesso IP (ElastiCache nodo) e porta di destinazione. Il comando seguente mostra quante connessioni esistono per un ElastiCache nodo specifico (IP 1.2.3.4):
```
ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l
```
Se il numero è troppo alto, il sistema potrebbe sovraccaricarsi tentando di elaborare le richieste di connessione. Si consiglia di prendere in considerazione l'implementazione di tecniche come il pool di connessioni o connessioni persistenti per gestire meglio le connessioni. Ogniqualvolta è possibile, configurare il pool di connessioni per limitare il numero massimo di connessioni ad alcune centinaia. Inoltre, la logica di back-off per gestire i timeout o altre eccezioni relative alla connessione sono consigliabili per evitare interruzioni di connessione in caso di problemi.
+ Limiti del traffico di rete: controllate le seguenti [CloudWatch metriche per Redis OSS](CacheMetrics.Redis.md) per identificare i possibili limiti di rete che vengono raggiunti sul nodo: ElastiCache
+ `NetworkBandwidthInAllowanceExceeded` / `NetworkBandwidthOutAllowanceExceeded`: pacchetti di rete sagomati perché la velocità effettiva ha superato il limite di larghezza di banda aggregata.
È importante notare che ogni byte scritto nel nodo primario verrà replicato in N repliche, dove N è il numero di repliche. I cluster con tipi di nodi piccoli, repliche multiple e richieste di scrittura ad alta intensità potrebbero non essere in grado di gestire il backlog di replica. In questi casi, è best practice dimensionare verso l'alto (cambiare il tipo di nodo), aumentare orizzontalmente (aggiungere partizioni in cluster in modalità cluster abilitata), ridurre il numero di repliche o ridurre al minimo il numero di scritture.
+ `NetworkConntrackAllowanceExceeded`: pacchetti sagomati perché è stato superato il numero massimo di connessioni monitorate in tutti i gruppi di sicurezza assegnati al nodo. Le nuove connessioni probabilmente non avranno esito positivo durante questo periodo.
+ `NetworkPackets PerSecondAllowanceExceeded`: Numero massimo di pacchetti al secondo superato. I carichi di lavoro basati su un elevato tasso di richieste molto piccole possono raggiungere questo limite prima della larghezza di banda massima.
I parametri sopra riportati sono il modo ideale per confermare che i nodi raggiungono i loro limiti di rete. Tuttavia, i limiti sono identificabili anche dai plateau sui parametri di rete.
Se i plateau vengono osservati per periodi prolungati, saranno probabilmente seguiti da ritardo di replica, aumento dei byte utilizzati per la cache, calo della memoria liberabile, elevato swap e utilizzo della CPU. EC2 Le istanze Amazon hanno anche limiti di rete che possono essere tracciati tramite i parametri dei [driver ENA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html). Le istanze Linux con supporto di rete avanzato e driver ENA 2.2.10 o versioni successive possono esaminare i contatori del limite con il comando:
```
# ethtool -S eth0 | grep "allowance_exceeded"
```
## Utilizzo CPU
La metrica di utilizzo della CPU è il punto di partenza dell'indagine e i seguenti elementi possono aiutare a restringere i possibili problemi secondari: ElastiCache
+ Redis OSS SlowLogs: la configurazione ElastiCache predefinita mantiene gli ultimi 128 comandi che hanno richiesto più di 10 millisecondi per essere completati. La cronologia dei comandi lenti viene mantenuta durante il tempo di esecuzione del motore e andrà persa in caso di guasto o riavvio. Se l'elenco raggiunge 128 voci, i vecchi eventi verranno rimossi per fare spazio a quelli nuovi. La dimensione dell'elenco degli eventi lenti e il tempo di esecuzione considerato lento può essere modificato tramite i parametri `slowlog-max-len` e `slowlog-log-slower-than` in un [gruppo di parametri personalizzati](ParameterGroups.md). L'elenco dei slow logs può essere recuperato eseguendo `SLOWLOG GET 128` sul motore, in cui 128 sono gli ultimi 128 comandi lenti segnalati. Ogni voce ha i campi riportati di seguito:
```
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
```
L'evento di cui sopra è avvenuto il 26 dicembre, alle 19:26:07 UTC, ha impiegato 4,8 secondi (4,823 ms) per essere completato ed è stato causato dal comando `KEYS` richiesto dal client 1.2.3.4.
Su Linux, la marcatura oraria può essere convertita con la data del comando:
```
$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020
```
Con Python:
```
>>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)
```
Oppure su Windows con: 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
```
Molti comandi lenti in un breve periodo di tempo (stesso minuto o meno) sono motivo di preoccupazione. Esaminare la natura dei comandi e come possono essere ottimizzati (vedere esempi precedenti). Se i comandi con complessità temporale O(1) vengono segnalati frequentemente, controllare gli altri fattori relativamente a un utilizzo elevato della CPU come menzionato in precedenza.
+ Metriche di latenza: ElastiCache per Redis OSS fornisce CloudWatch metriche per monitorare la latenza media per diverse classi di comandi. Il datapoint viene calcolato dividendo il numero totale di esecuzioni di comandi nella categoria per il tempo totale di esecuzione nel periodo. È importante comprendere che i risultati dei parametri di latenza sono un aggregato di più comandi. Un singolo comando può causare risultati imprevisti, come i timeout, senza un impatto significativo sui parametri. In questi casi, gli eventi di slow log sarebbero una fonte di informazioni più accurata. L'elenco seguente contiene i parametri di latenza disponibili e i rispettivi comandi che le riguardano.
+ EvalBasedCmdsLatency: relativo ai comandi Lua Script,,; `eval` `evalsha`
+ GeoSpatialBasedCmdsLatency: `geodist`, `geohash`, `geopos`, `georadius`, `georadiusbymember`, `geoadd`;
+ GetTypeCmdsLatency: comandi di lettura, indipendentemente dal tipo di dati;
+ HashBasedCmdsLatency: `hexists`, `hget`, `hgetall`, `hkeys`, `hlen`, `hmget`, `hvals`, `hstrlen`, `hdel`, `hincrby`, `hincrbyfloat`, `hmset`, `hset`, `hsetnx`;
+ HyperLogLogBasedCmdsLatency: `pfselftest`, `pfcount`, `pfdebug`, `pfadd`, `pfmerge`;
+ KeyBasedCmdsLatency: Comandi che possono agire su diversi tipi di dati: `dump` `exists``keys`,`object`,`pttl`,,`randomkey`,`ttl`,`type`,`del`,`expire`,`expireat`,`move`,`persist`,`pexpire`,`pexpireat`,`rename`,`renamenx`,`restoreK`,`sort`,`unlink`;
+ ListBasedCmdsLatency: lindex, len, orange, blpop, brpop, brpoplpush, linsert, lpop, push, lpushx, lrem, lset, ltrim, rpop, rpoplpush, rpush, rpushx;
+ PubSubBasedCmdsLatency: psubscribe, publish, pubsub, annulla sottoscrizione, sottoscrizione, annullamento dell'iscrizione;
+ SetBasedCmdsLatency: `scard`, `sdiff`, `sinter`, `sismember`, `smembers`, `srandmember`, `sunion`, `sadd`, `sdiffstore`, `sinterstore`, `smove`, `spop`, `srem`, `sunionstore`;
+ SetTypeCmdsLatency: scrivere comandi, indipendentemente dal tipo di dati;
+ 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`;
+ Comandi di runtime Redis OSS:
+ info commandstats: fornisce un elenco di comandi eseguiti dall'avvio del motore, il numero cumulativo di esecuzioni, il tempo totale di esecuzione e il tempo medio di esecuzione per comando;
+ client list: fornisce un elenco di client attualmente connessi e informazioni rilevanti come l'utilizzo dei buffer, l'ultimo comando eseguito, ecc.;
+ Backup e replica: ElastiCache per le versioni Redis OSS precedenti alla 2.8.22, utilizza un processo biforcato per creare backup ed elaborare sincronizzazioni complete con le repliche. Questo metodo può incorrere in un sovraccarico di memoria significativo per casi d'uso intensivi di scrittura.
A partire da ElastiCache Redis OSS 2.8.22, è stato introdotto un metodo di backup e replica senza forkless. AWS Il nuovo metodo potrebbe ritardare le scritture al fine di evitare errori. Entrambi i metodi possono causare periodi di maggiore utilizzo della CPU, portare a tempi di risposta più elevati e di conseguenza portare a timeout client durante la loro esecuzione. Controllare sempre se gli errori del client si verificano durante la finestra di backup o il parametro `SaveInProgress`era 1 nel periodo. Si consiglia di pianificare la finestra di backup per periodi di basso utilizzo per ridurre al minimo la possibilità di problemi con i client o errori di backup.
## Connessioni terminate dal lato server
L'impostazione predefinita ElastiCache per la configurazione Redis OSS mantiene le connessioni client stabilite a tempo indeterminato. Tuttavia, in alcuni casi la terminazione della connessione potrebbe essere auspicabile. Esempio:
+ I bug nell'applicazione client possono causare connessioni da dimenticare e mantenere stabilite con uno stato di inattività. Questo è chiamato “perdita di connessione” e la conseguenza è un costante aumento del numero di connessioni stabilite osservate sul parametro `CurrConnections`. Questo comportamento può comportare una saturazione del client o del lato. ElastiCache Quando una correzione immediata non è possibile dal lato client, alcuni amministratori impostano un valore di «timeout» nel proprio ElastiCache gruppo di parametri. Il timeout è il tempo in secondi consentito per la persistenza delle connessioni inattive. Se il client non invia alcuna richiesta entro il periodo indicato, il motore interromperà la connessione non appena la connessione raggiunge il valore di timeout. Piccoli valori di timeout possono causare disconnessioni non necessarie e i client dovranno gestirle correttamente e riconnettersi, causando ritardi.
+ La memoria utilizzata per memorizzare le chiavi è condivisa con i buffer client. I client lenti con richieste o risposte di grandi dimensioni possono richiedere una quantità significativa di memoria per gestire i buffer. L'impostazione predefinita ElastiCache per le configurazioni Redis OSS non limita la dimensione dei normali buffer di output del client. Se il limite `maxmemory` è raggiunto, il motore tenterà di espellere gli elementi per soddisfare l'utilizzo del buffer. In condizioni di memoria estremamente ridotta, ElastiCache For Redis OSS potrebbe scegliere di disconnettere i client che consumano buffer di output client di grandi dimensioni per liberare memoria e mantenere lo stato del cluster.
È possibile limitare la dimensione dei buffer client con configurazioni personalizzate e i client che raggiungono il limite verranno disconnessi. Tuttavia, i client dovrebbero essere in grado di gestire disconnessioni impreviste. I parametri per gestire le dimensioni dei buffer per i client regolari sono i seguenti:
+ client-query-buffer-limit: dimensione massima di una singola richiesta di input;
+ client-output-buffer-limit-normal-soft-limit: Limite flessibile per le connessioni client. La connessione verrà interrotta se rimane al di sopra del limite libero per più del tempo in secondi definito su client-output-buffer-limit normal-soft-seconds o se raggiunge il limite rigido;
+ client-output-buffer-limit-normal-soft-seconds: Tempo consentito per le connessioni che superano il client-output-buffer-limit -; normal-soft-limit
+ client-output-buffer-limit-normal-hard-limit: Una connessione che raggiunge questo limite verrà immediatamente interrotta.
Oltre ai normali buffer dei client, le seguenti opzioni controllano il buffer per i nodi di replica e i client (Publish/Subscribe): Pub/Sub
+ 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;
## Risoluzione dei problemi lato client per le istanze Amazon EC2
Il carico e la reattività sul lato client possono influire anche sulle richieste di. ElastiCache EC2 i limiti delle istanze e del sistema operativo devono essere esaminati attentamente durante la risoluzione dei problemi di connettività intermittente o di timeout. Alcuni punti chiave da osservare:
+ CPU:
+ EC2 utilizzo della CPU dell'istanza: assicurati che la CPU non sia satura o vicina al 100%. L'analisi storica può essere effettuata tramite CloudWatch, tuttavia, tieni presente che la granularità dei punti dati è di 1 minuto (con il monitoraggio dettagliato abilitato) o di 5 minuti;
+ Se utilizzi [ EC2 istanze espandibili, assicurati che il saldo del credito della CPU non sia esaurito](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html). Queste informazioni sono disponibili sulla metrica. `CPUCreditBalance` CloudWatch
+ Brevi periodi di utilizzo elevato della CPU possono causare timeout senza che ciò comporti un utilizzo al 100%. CloudWatch Tali casi richiedono un monitoraggio in tempo reale con strumenti del sistema operativo come `top`, `ps` e `mpstat`.
+ Rete
+ Verificare se la velocità effettiva di rete è inferiore ai valori accettabili in base alle capacità dell'istanza. Per ulteriori informazioni, consulta [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/)
+ Sulle istanze con `ena` Driver di rete avanzato, controllare le [Statistiche ENA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-ena.html#statistics-ena)per i timeout o i limiti superati. Le seguenti statistiche sono utili per verificare la saturazione dei limiti di rete:
+ `bw_in_allowance_exceeded` / `bw_out_allowance_exceeded`: numero di pacchetti sagomati a causa di una eccessiva velocità effettiva in entrata o in uscita;
+ `conntrack_allowance_exceeded`: numero di pacchetti eliminati a causa dei [Limiti di monitoraggio delle connessioni](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#connection-tracking-throttling) dei gruppi di sicurezza. Le nuove connessioni avranno esito negativo quando questo limite è saturo;
+ `linklocal_allowance_exceeded`: numero di pacchetti eliminati a causa di richieste eccessive per l'istanza di meta-dati, NTP tramite DNS VPC. Il limite è di 1024 pacchetti al secondo per tutti i servizi;
+ `pps_allowance_exceeded`: numero di pacchetti eliminati a causa di un rapporto eccessivo di pacchetti al secondo. Il limite PPS può essere raggiunto quando il traffico di rete è composto da migliaia o milioni di richieste molto piccole al secondo. ElastiCache il traffico può essere ottimizzato per utilizzare meglio i pacchetti di rete tramite pipeline o comandi che eseguono più operazioni contemporaneamente, ad esempio `MGET` anziché. `GET`
## Dissezione del tempo necessario per completare una singola richiesta
+ On the network: `Tcpdump` and `Wireshark` (tshark sulla riga di comando) sono strumenti utili per capire quanto tempo ha impiegato la richiesta a percorrere la rete, avviare il ElastiCache motore e ottenere un ritorno. L'esempio seguente evidenzia una singola richiesta creata con il seguente comando:
```
$ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG
```
In parallelo al comando di cui sopra, tcpdump era in esecuzione ed è stato restituito:
```
$ 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
```
Dall'output di cui sopra possiamo confermare che l'handshake a tre vie TCP è stato completato in 222 microsecondi (918091 - 917869) e che il comando ping è stato inviato e restituito in 173 microsecondi (918295 - 918122).
Ci sono voluti 438 microsecondi (918307 - 917869) dalla richiesta alla chiusura della connessione. Tali risultati confermerebbero che i tempi di risposta della rete e del motore sono buoni e l'indagine può concentrarsi su altri componenti.
+ Nel sistema operativo: `Strace` può aiutare a identificare le lacune temporali a livello di sistema operativo. L'analisi delle applicazioni effettive sarebbe molto più ampia e sono consigliati profiler di applicazioni specializzati o debugger. L'esempio seguente mostra solo se i componenti del sistema operativo di base funzionano come previsto, in caso contrario potrebbero essere necessarie ulteriori indagini. Usando lo stesso `PING` comando Redis OSS con `strace` otteniamo:
```
$ 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 +++
```
Nell'esempio precedente, il comando ha impiegato poco più di 54 millisecondi per essere completato (752110 - 697712 = 54398 microsecondi).
Una quantità significativa di tempo, circa 20 ms, è stata impiegata per istanziare nc ed effettuare la risoluzione dei nomi (da 697712 a 717890), dopodiché sono stati necessari 2 ms per creare il socket TCP (da 745659 a 747858) e 0,4 ms (da 747858 a 748330) per inviare e ricevere la risposta per la richiesta.
## Argomenti correlati
+ [ElastiCache migliori pratiche e strategie di caching](BestPractices.md)