As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Trabalhando com ElastiCache
Nesta seção, você pode encontrar detalhes sobre como gerenciar os vários componentes da sua ElastiCache implementação.
**Topics**
+ [Snapshots e restauração](backups.md)
+ [Versões e atualizações do motor em ElastiCache](engine-versions.md)
+ [Práticas recomendadas e estratégias de armazenamento em cache do ElastiCache](BestPractices.md)
+ [Gerenciando seu cluster baseado em nós no ElastiCache](manage-self-designed-cluster.md)
+ [Conectar uma instância do EC2 e um cache do ElastiCache automaticamente](compute-connection.md)
+ [Dimensionamento ElastiCache](Scaling.md)
+ [Conceitos básicos do filtro Bloom](BloomFilters.md)
+ [Introdução ao Watch em Serverless](ServerlessWatch.md)
+ [Conceitos básicos de pesquisa vetorial](vector-search.md)
+ [Conceitos básicos do JSON para Valkey e Redis OSS](json-gs.md)
+ [Marcando seus recursos ElastiCache](Tagging-Resources.md)
+ [Usar a Lente do Well-Architected para o Amazon ElastiCache](WellArchitechtedLens.md)
+ [Etapas comuns de solução de problemas e melhores práticas com ElastiCache](wwe-troubleshooting.md)
# Snapshots e restauração
ElastiCache Os caches da Amazon que executam Valkey, Redis OSS ou Serverless Memcached podem fazer backup de seus dados criando um snapshot. É possível usar o backup para restaurar um cache ou propagar dados para um novo cache. O backup consiste nos metadados do cache com todos os dados no cache. Todos os backups são gravados no Amazon Simple Storage Service (Amazon S3), que fornece armazenamento durável. A qualquer momento, você pode restaurar os dados criando um novo cache do Valkey, Redis OSS ou Memcached de tecnologia sem servidor e o preenchendo com dados de um backup. Com ElastiCache, você pode gerenciar backups usando o Console de gerenciamento da AWS, o AWS Command Line Interface(AWS CLI) e a ElastiCache API.
Se quiser excluir um cache e for importante preservar os dados, você poderá tomar uma precaução extra. Para isso, crie um backup manual primeiro, verifique se o status está *disponível* e, em seguida, exclua o cluster. Isso garante que, se o backup falhar, você ainda terá os dados do cache disponíveis. Você pode tentar um backup novamente, seguindo as práticas recomendadas descritas anteriormente.
**Topics**
+ [Restrições do backup](#backups-constraints)
+ [Impacto sobre o desempenho dos backups de clusters baseados em nós](#backups-performance)
+ [Programação de backups automáticos](backups-automatic.md)
+ [Realização de backups manuais](backups-manual.md)
+ [Criação de um backup final](backups-final.md)
+ [Descrição de backups](backups-describing.md)
+ [Copiar backups](backups-copying.md)
+ [Exportação de um backup](backups-exporting.md)
+ [Restauração de um backup para um novo cache](backups-restoring.md)
+ [Exclusão de um backup](backups-deleting.md)
+ [Marcação de backups](backups-tagging.md)
+ [Tutorial: propagação de um novo cluster baseado em nós com um backup criado externamente](backups-seeding-redis.md)
## Restrições do backup
Considere as seguintes restrições ao planejar ou fazer backups:
+ O backup e a restauração são suportados apenas para caches executados no Valkey, Redis OSS ou Memcached de tecnologia sem servidor.
+ Para clusters do Valkey ou Redis OSS (modo cluster desabilitado), não há suporte para backup e restauração em nós `cache.t1.micro`. Todos os outros tipos de nó de cache têm suporte.
+ Para clusters do Valkey ou Redis OSS (modo cluster habilitado), o backup e a restauração têm suporte para todos os tipos de nó.
+ Durante qualquer período contíguo de 24 horas, você não pode criar mais de 24 backups manuais por cache de tecnologia sem servidor. Para clusters baseados em nós do Valkey e Redis OSS, você não pode criar mais de 20 backups manuais por nó do cluster.
+ O Valkey ou Redis OSS (modo cluster habilitado) oferece suporte apenas para backups no nível do cluster (para a API ou CLI, no nível do grupo de replicação). O Valkey ou Redis OSS (modo cluster habilitado) não oferece suporte à execução de backups no nível do fragmento (para a API ou CLI, no nível do grupo de nós).
+ Durante o processo de backup, não é possível executar outra operação de API ou CLI no cache de tecnologia sem servidor. Você pode executar operações de API ou CLI em um cluster baseado em nós durante o backup.
+ Se você estiver usando caches do Valkey ou Redis OSS com classificação de dados em níveis, não será possível exportar um backup para o Amazon S3.
+ Só é possível restaurar um backup de um cluster usando o tipo de nó r6gd para clusters que estejam usando o tipo de nó r6gd.
## Impacto sobre o desempenho dos backups de clusters baseados em nós
Os backups em caches sem servidor são transparentes para a aplicação, sem impacto sobre o desempenho. No entanto, durante a criação de backups para clusters baseados em nós, é possível que haja algum impacto sobre o desempenho, dependendo da memória reservada disponível. Os backups para clusters baseados em nós não estão disponíveis com ElastiCache o Memcached, mas estão disponíveis com ElastiCache o Redis OSS.
Estas são as diretrizes a fim de melhorar o desempenho do backup para clusters baseados em nós.
+ Definir o `reserved-memory-percent` parâmetro — Para reduzir a paginação excessiva, recomendamos que você defina o *reserved-memory-percent*parâmetro. Esse parâmetro impede que o Valkey e Redis OSS consumam toda a memória disponível do nó e pode ajudar a reduzir a quantidade de paginação. Você também pode ver melhorias de desempenho simplesmente usando um nó maior. Para obter mais informações sobre a *memória reservada* e *reserved-memory-percent*os parâmetros, consulte. [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md)
+ Crie backups a partir de uma réplica de leitura: se você estiver executando o Valkey ou Redis OSS em um grupo de nós com mais de um nó, será possível fazer um backup do nó primário ou de uma das réplicas de leitura. Devido aos recursos do sistema necessários durante um BGSAVE, recomendamos que você crie backups de uma das réplicas de leitura. Enquanto o backup está sendo criado da réplica, o nó primário permanece inalterado pelos requisitos de recursos de BGSAVE. O nó primário pode continuar a atender solicitações sem ficar lento.
Para fazer isso, consulte [Criação de um backup manual (console)](backups-manual.md#backups-manual-CON), e no campo **Cluster Name** (Nome do cluster) na janela **Create Backup** (Criar backup), escolha uma réplica em vez do nó primário padrão.
Se você excluir um grupo de replicação e solicitar um backup final, ElastiCache sempre fará o backup do nó primário. Isso garante que você capture os dados mais recentes do Valkey ou Redis OSS antes que o grupo de replicação seja excluído.
# Programação de backups automáticos
É possível habilitar backups automáticos para qualquer cache de tecnologia sem servidor do Valkey ou Redis OSS ou para qualquer cluster baseado em nós. Quando os backups automáticos estão habilitados, ElastiCache cria um backup do cache diariamente. Não há impacto sobre o cache, e a alteração é imediata. Os backups automáticos podem ajudar a proteger contra a perda de dados. Em caso de falha, você pode criar um cache e restaurar os dados usando o backup mais recente. O resultado é um cache inicializado a quente, pré-carregado com os dados e pronto para uso. Para obter mais informações, consulte [Restauração de um backup para um novo cache](backups-restoring.md).
É possível ativar backups automáticos para qualquer cache de tecnologia sem servidor do Memcached. Quando os backups automáticos estão habilitados, ElastiCache cria um backup do cache diariamente. Não há impacto sobre o cache, e a alteração é imediata. Os backups automáticos podem ajudar a proteger contra a perda de dados. Em caso de falha, você pode criar um cache e restaurar os dados usando o backup mais recente. O resultado é um cache inicializado a quente, pré-carregado com os dados e pronto para uso. Para obter mais informações, consulte [Restauração de um backup para um novo cache](backups-restoring.md).
Ao agendar backups automáticos, você deve planejar as seguintes configurações:
+ **Hora de início do backup** — Uma hora do dia em que ElastiCache começa a criar um backup. É possível definir a janela de backup para qualquer momento quando mais prático. Se você não especificar uma janela de backup, ElastiCache atribuirá uma automaticamente.
+ **Backup retention limit** (Limite de retenção de backup): o número de dias em que o backup é mantido no Amazon S3. Por exemplo, se o limite de retenção for definido como 5, um backup feito hoje será mantido por 5 dias. Quando o limite de retenção expirar, o backup será excluído automaticamente.
O limite máximo de retenção de backups é de 35 dias. Se o limite de retenção do backup for definido como 0, os backups automáticos serão desabilitados para o cache.
Quando você agendar backups automáticos, ElastiCache começará a criar o backup. É possível definir a janela de backup para qualquer momento quando mais prático. Se você não especificar uma janela de backup, ElastiCache atribuirá uma automaticamente.
Você pode ativar ou desativar os backups automáticos ao criar um novo cache ou atualizar um cache existente usando o ElastiCache console AWS CLI, o ou a ElastiCache API. Para Valkey e Redis OSS, isso é feito marcando a caixa **Ativar backups automáticos** na seção **Configurações avançadas do Valkey** ou **Configurações avançadas do Redis OSS**. Para Memcached, isso é feito marcando a caixa **Ativar backups automáticos** na seção **Configurações avançadas do Memcached**.
# Realização de backups manuais
Além dos backups automáticos, você pode criar um backup *manual* a qualquer momento. Ao contrário dos backups automáticos, que são excluídos automaticamente após um período de retenção especificado, os backups manuais não têm um período de retenção após o qual são excluídos automaticamente. Mesmo se você excluir o cache, todos os backups manuais desse cache são retidos. Caso não queira mais manter um backup manual, você deverá excluí-lo explicitamente por conta própria.
Além de criar diretamente um backup manual, você pode criar um backup manual de uma das seguintes maneiras:
+ [Copiar backups](backups-copying.md). Não importa se o backup de origem foi criado automática ou manualmente.
+ [Criação de um backup final](backups-final.md). Crie imediatamente um backup antes de excluir um cluster ou nó.
Você pode criar um backup manual de um cache usando a Console de gerenciamento da AWSAWS CLI, a ou a ElastiCache API.
Você pode gerar backups manuais a partir de réplicas com o modo de cluster habilitado e o modo de cluster desabilitado.
## Criação de um backup manual (console)
**Para criar um backup de um cache (console)**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Caches do Valkey**, **Caches do Redis OSS** ou **Caches do Memcached**, dependendo da sua preferência.
1. Selecione a caixa à esquerda do nome do cache do qual você deseja fazer backup.
1. Escolha **Backup**.
1. No diálogo **Criar backup**, digite um nome para seu backup na caixa **Nome do backup**. Recomendamos que o nome indique o cluster do backup e a data e hora de criação do backup.
As restrições de nomenclatura de cluster são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
1. Escolha **Create Backup**.
O status do cluster muda para *snapshotting*.
## Criação de um backup manual (AWS CLI)
**Backup manual de um cache sem servidor com o AWS CLI**
Para criar um backup manual de um cache usando o AWS CLI, use a `create-serverless-snapshot`AWS CLI operação com os seguintes parâmetros:
+ `--serverless-cache-name`: o nome do cache sem servidor do qual você está fazendo backup.
+ `--serverless-cache-snapshot-name` - Nome do snapshot a ser criado.
Para Linux, macOS ou Unix:
+
```
aws elasticache create-serverless-snapshot \
--serverless-cache-name CacheName \
--serverless-cache-snapshot-name bkup-20231127
```
Para Windows:
+
```
aws elasticache create-serverless-snapshot ^
--serverless-cache-name CacheName ^
--serverless-cache-snapshot-name bkup-20231127
```
**Backup manual de um cluster baseado em nós com o AWS CLI**
Para criar um backup manual de um cluster baseado em nós usando o AWS CLI, use a `create-snapshot`AWS CLI operação com os seguintes parâmetros:
+ `--cache-cluster-id`
+ Se o cluster do qual você está fazendo backup não tiver nós de réplica, `--cache-cluster-id` é o nome do cluster do qual você está fazendo backup, por exemplo. *mycluster*
+ Se o cluster do backup tiver um ou mais nós de réplica, `--cache-cluster-id` será o nome do nó no cluster que você deseja usar para o backup. Por exemplo, o nome pode ser*mycluster-002*.
Use este parâmetro somente ao fazer backup de um cluster do Valkey ou Redis OSS (modo cluster desabilitado).
+ `--replication-group-id`: nome do cluster do Valkey ou Redis OSS (modo cluster habilitado) (CLI/API: um grupo de replicação) para usar como fonte para o backup. Use este parâmetro ao fazer backup de um cluster do Valkey ou Redis OSS (modo cluster habilitado).
+ `--snapshot-name` - Nome do snapshot a ser criado.
As restrições de nomenclatura de cluster são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
### Exemplo 1: backup de um cluster do Valkey ou Redis OSS (modo cluster desabilitado) que não tem nós de réplicas
A AWS CLI operação a seguir cria o backup `bkup-20150515` do cluster Valkey ou Redis OSS (modo de cluster desativado) `myNonClusteredRedis` que não tem réplicas de leitura.
Para Linux, macOS ou Unix:
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis \
--snapshot-name bkup-20150515
```
Para Windows:
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis ^
--snapshot-name bkup-20150515
```
### Exemplo 2: backup de um cluster do Valkey ou Redis OSS (modo cluster desabilitado) com nós de réplicas
A AWS CLI operação a seguir cria o backup `bkup-20150515` do cluster Valkey ou Redis OSS (modo de cluster desativado). `myNonClusteredRedis` Esse backup tem uma ou mais réplicas de leitura.
Para Linux, macOS ou Unix:
```
aws elasticache create-snapshot \
--cache-cluster-id myNonClusteredRedis-001 \
--snapshot-name bkup-20150515
```
Para Windows:
```
aws elasticache create-snapshot ^
--cache-cluster-id myNonClusteredRedis-001 ^
--snapshot-name bkup-20150515
```
**Saída do exemplo: backup de um cluster do Valkey ou Redis OSS (modo cluster desabilitado) com nós de réplicas**
A saída da operação é semelhante à seguinte.
```
{
"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"
}
}
```
### Exemplo 3: backup de um cluster do Valkey ou Redis OSS (modo cluster habilitado)
A AWS CLI operação a seguir cria o backup `bkup-20150515` do cluster Valkey ou Redis OSS (modo de cluster ativado). `myClusteredRedis` Observe o uso de `--replication-group-id` no lugar de `--cache-cluster-id` para identificar a origem. Observe também que ElastiCache faz o backup usando o nó de réplica quando presente e usará como padrão o nó primário se um nó de réplica não estiver disponível.
Para Linux, macOS ou Unix:
```
aws elasticache create-snapshot \
--replication-group-id myClusteredRedis \
--snapshot-name bkup-20150515
```
Para Windows:
```
aws elasticache create-snapshot ^
--replication-group-id myClusteredRedis ^
--snapshot-name bkup-20150515
```
**Saída do exemplo: backup de um cluster do Valkey ou Redis OSS (modo cluster habilitado)**
A saída dessa operação é semelhante à seguinte.
```
{
"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"
}
}
```
### Tópicos relacionados
Para obter mais informações, consulte [create-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-snapshot.html) na *Referência de comandos da AWS CLI*.
## Criando um backup usando CloudFormation
Você pode usar CloudFormation para criar um backup do seu cache ElastiCache Redis OSS ou Valkey, usando as `AWS::ElastiCache::ServerlessCache` propriedades ou. `AWS::ElastiCache::ReplicationGroup`
**Usar o recurso `AWS::ElastiCache::ServerlessCache`**
Use isso para criar um backup usando o AWS::ElastiCache::ServerlessCache recurso:
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ServerlessCache
Properties:
...
ServerlessCacheName: "your-cache-name"
Engine: "redis"
CacheUsageLimits
```
**Usando o AWS::ElastiCache::ReplicationGroup recurso**
Use o recurso `AWS::ElastiCache::ReplicationGroup`:
```
Resources:
iotCatalog:
Type: AWS::ElastiCache::ReplicationGroup
Properties:
...
ReplicationGroupDescription: "Description of your replication group"
Engine: "redis"
CacheNodeType
NumCacheClusters
AutomaticFailoverEnabled
AtRestEncryptionEnabled
```
# Criação de um backup final
Você pode criar um backup final usando o ElastiCache console AWS CLI, o ou a ElastiCache API.
## Criação de um backup final (console)
Você pode criar um backup final ao excluir um cache sem servidor Valkey, Memcached ou Redis OSS, ou um cluster baseado em nós Valkey ou Redis OSS, usando o console. ElastiCache
Para criar um backup final ao excluir um cache, na caixa de diálogo, escolha **Sim**, em **Criar backup** e dê um nome ao backup.
**Tópicos relacionados**
+ [Usando o Console de gerenciamento da AWS](Clusters.Delete.md#Clusters.Delete.CON)
+ [Exclusão de um grupo de replicação (Console)](Replication.DeletingRepGroup.md#Replication.DeletingRepGroup.CON)
## Criação de um backup final (AWS CLI)
Você pode criar um backup final ao excluir um cache usando a AWS CLI.
**Topics**
+ [Ao excluir um cache do Valkey, cache de tecnologia sem servidor do Memcached ou cache do Redis OSS](#w2aac24b7c29b7b1b7)
+ [Ao excluir um cluster do Valkey ou Redis OSS sem réplicas de leitura](#w2aac24b7c29b7b1b9)
+ [Ao excluir um cluster do Valkey ou Redis OSS com réplicas de leitura](#w2aac24b7c29b7b1c11)
### Ao excluir um cache do Valkey, cache de tecnologia sem servidor do Memcached ou cache do Redis OSS
Para criar um backup final, use a `delete-serverless-cache`AWS CLI operação com os seguintes parâmetros.
+ `--serverless-cache-name`: nome do cache que está sendo excluído.
+ `--final-snapshot-name` – Nome do backup.
O código a seguir cria o backup final `bkup-20231127-final` ao excluir o cache `myserverlesscache`.
Para Linux, macOS ou Unix:
```
aws elasticache delete-serverless-cache \
--serverless-cache-name myserverlesscache \
--final-snapshot-name bkup-20231127-final
```
Para Windows:
```
aws elasticache delete-serverless-cache ^
--serverless-cache-name myserverlesscache ^
--final-snapshot-name bkup-20231127-final
```
Para obter mais informações, consulte [delete-serverless-cache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache.html) na *Referência de comandos da AWS CLI*.
### Ao excluir um cluster do Valkey ou Redis OSS sem réplicas de leitura
Para criar um backup final para um cluster baseado em nós sem réplicas de leitura, use a `delete-cache-cluster`AWS CLI operação com os parâmetros a seguir.
+ `--cache-cluster-id`: nome do cluster que está sendo excluído.
+ `--final-snapshot-identifier` – Nome do backup.
O código a seguir cria o backup final `bkup-20150515-final` ao excluir o cluster `myRedisCluster`.
Para Linux, macOS ou Unix:
```
aws elasticache delete-cache-cluster \
--cache-cluster-id myRedisCluster \
--final-snapshot-identifier bkup-20150515-final
```
Para Windows:
```
aws elasticache delete-cache-cluster ^
--cache-cluster-id myRedisCluster ^
--final-snapshot-identifier bkup-20150515-final
```
Para obter mais informações, consulte [delete-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-cache-cluster.html) na *Referência de comandos da AWS CLI*.
### Ao excluir um cluster do Valkey ou Redis OSS com réplicas de leitura
Para criar um backup final ao excluir um grupo de replicação, use a `delete-replication-group`AWS CLI operação, com os seguintes parâmetros:
+ `--replication-group-id` – Nome do grupo de replicação que está sendo excluído.
+ `--final-snapshot-identifier` – Nome do backup final.
O código a seguir usa o backup final `bkup-20150515-final` ao excluir o grupo de replicação `myReplGroup`.
Para Linux, macOS ou Unix:
```
aws elasticache delete-replication-group \
--replication-group-id myReplGroup \
--final-snapshot-identifier bkup-20150515-final
```
Para Windows:
```
aws elasticache delete-replication-group ^
--replication-group-id myReplGroup ^
--final-snapshot-identifier bkup-20150515-final
```
Para obter mais informações, consulte [delete-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-replication-group.html) na *Referência de comandos da AWS CLI*.
# Descrição de backups
Os procedimentos a seguir mostram como exibir uma lista dos seus backups. Se desejar, você também pode visualizar os detalhes de um backup específico.
## Descrição de backups (console)
**Para exibir backups usando o Console de gerenciamento da AWS**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Backups**.
1. Para ver os detalhes de um backup específico, escolha a caixa à esquerda do nome do backup.
## Descrição dos backups sem servidor (AWS CLI)
Para exibir uma lista de backups sem servidor e, como opção, detalhes sobre um backup específico, use a operação `describe-serverless-cache-snapshots` da CLI.
**Exemplos**
A seguinte operação usa o parâmetro `--max-records` para listar até 20 backups associados à sua conta. Omitir o parâmetro `--max-records` lista até 50 backups.
```
aws elasticache describe-serverless-cache-snapshots --max-records 20
```
A operação a seguir usa o parâmetro `--serverless-cache-name` para só listar os backups associados ao cache `my-cache`.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-name my-cache
```
A operação a seguir usa o parâmetro `--serverless-cache-snapshot-name` para exibir os detalhes do backup `my-backup`.
```
aws elasticache describe-serverless-cache-snapshots --serverless-cache-snapshot-name my-backup
```
Para obter mais informações, consulte [describe-serverless-cache-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-serverless-cache-snapshots.html)na Referência de AWS CLI Comandos.
## Descrever backups de cluster baseados em nós (AWS CLI)
Para exibir uma lista de backups de cluster baseados em nós e, opcionalmente, detalhes sobre um backup específico, use a operação `describe-snapshots` da CLI.
**Exemplos**
A seguinte operação usa o parâmetro `--max-records` para listar até 20 backups associados à sua conta. Omitir o parâmetro `--max-records` lista até 50 backups.
```
aws elasticache describe-snapshots --max-records 20
```
A operação a seguir usa o parâmetro `--cache-cluster-id` para listar apenas os backups associados ao cluster `my-cluster`.
```
aws elasticache describe-snapshots --cache-cluster-id my-cluster
```
A operação a seguir usa o parâmetro `--snapshot-name` para exibir os detalhes do backup `my-backup`.
```
aws elasticache describe-snapshots --snapshot-name my-backup
```
Para obter mais informações, consulte [describe-snapshots](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-snapshots.html) na Referência de Comandos.AWS CLI
# Copiar backups
É possível fazer uma cópia de qualquer backup, seja ele criado automática ou manualmente. Você também pode exportar seu backup para acessá-lo de fora ElastiCache. Para obter orientação sobre como exportar o backup, consulte [Exportação de um backup](backups-exporting.md).
As etapas a seguir mostram como copiar um backup.
## Cópia de backups (console)
**Para copiar um backup (console)**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Para ver uma lista dos seus backups, no painel de navegação esquerdo, escolha **Backups**.
1. Na lista de backups, escolha a caixa à esquerda do nome do backup que você deseja copiar.
1. Escolha **Ações** e **Copiar**.
1. Na caixa **New backup name**, digite um nome para seu novo backup.
1. Escolha **Copiar**.
## Cópia de um backup sem servidor (AWS CLI)
Para copiar um backup de um cache sem servidor, use a operação `copy-serverless-cache-snapshot`.
**Parâmetros**
+ `--source-serverless-cache-snapshot-name` - Nome do backup a ser copiado.
+ `--target-serverless-cache-snapshot-name` - Nome da cópia do backup.
O exemplo a seguir faz uma cópia de um backup automático.
Para Linux, macOS ou 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
```
Para 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
```
Para ter mais informações, consulte [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) no *AWS CLI*.
## Copiar um backup de cluster baseado em nós (AWS CLI)
Para copiar um backup de um cluster baseado em nós, use a operação `copy-snapshot`.
**Parâmetros**
+ `--source-snapshot-name` - Nome do backup a ser copiado.
+ `--target-snapshot-name` - Nome da cópia do backup.
+ `--target-bucket`: reservado para exportação de um backup. Não use esse parâmetro ao fazer uma cópia de um backup. Para obter mais informações, consulte [Exportação de um backup](backups-exporting.md).
O exemplo a seguir faz uma cópia de um backup automático.
Para Linux, macOS ou Unix:
```
aws elasticache copy-snapshot \
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 \
--target-snapshot-name amzn-s3-demo-bucket
```
Para Windows:
```
aws elasticache copy-snapshot ^
--source-snapshot-name automatic.my-redis-primary-2014-03-27-03-15 ^
--target-snapshot-name amzn-s3-demo-bucket
```
Para ter mais informações, consulte [https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/elasticache/copy-snapshot.html) no *AWS CLI*.
# Exportação de um backup
A Amazon ElastiCache suporta a exportação de seu backup do OSS ElastiCache para Redis para um bucket do Amazon Simple Storage Service (Amazon S3), que dá acesso externo a ele. ElastiCache Você pode exportar um backup usando o ElastiCache console AWS CLI, o ou a ElastiCache API.
Exportar um backup pode ser útil se você precisar iniciar um cluster em outra AWS região. Você pode exportar seus dados em uma AWS região, copiar o arquivo.rdb para a nova AWS região e, em seguida, usar esse arquivo.rdb para alimentar o novo cache em vez de esperar que o novo cluster seja preenchido por meio do uso. Para obter informações sobre como criar um novo cluster, consulte [Tutorial: propagação de um novo cluster baseado em nós com um backup criado externamente](backups-seeding-redis.md). Outra razão pela qual você pode querer exportar os dados do seu cache é para usar o arquivo .rdb para processamento off-line.
**Importante**
O ElastiCache backup e o bucket do Amazon S3 para o qual você deseja copiá-lo devem estar na mesma AWS região.
Embora os backups copiados para um bucket do Amazon S3 sejam criptografados, recomendamos que você não conceda a outras pessoas acesso ao bucket do Amazon S3 no qual deseja armazená-los.
A exportação de um backup para o Amazon S3 não é compatível com clusters que usam classificação de dados em níveis. Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
A exportação de um backup está disponível para: clusters Valkey baseados em nós, clusters Redis OSS baseados em nós e caches com tecnologia sem servidor do Valkey, Memcached e Redis OSS. A exportação de um backup não está disponível para clusters baseados em nós do Memcached.
Antes de exportar um backup para um bucket do Amazon S3, você deve ter um bucket do Amazon S3 na AWS mesma região do backup. Conceda ElastiCache acesso ao bucket. As duas primeiras etapas mostram como fazer isso.
## Crie um bucket Amazon S3
As etapas a seguir usam o console do Amazon S3 para criar um bucket do Amazon S3 onde você exporta e armazena seu backup. ElastiCache
**Como criar um bucket do Amazon S3**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Escolha **Criar bucket**.
1. Em **Create a Bucket - Select a Bucket Name and Region**, faça o seguinte:
1. Em **Bucket Name** (Nome do bucket), digite um nome para o bucket do Amazon S3.
O nome do bucket do Amazon S3 deve estar em conformidade com o DNS. Caso contrário, não ElastiCache conseguirá acessar seu arquivo de backup. As regras para a conformidade de DNS são:
+ Os nomes devem ter no mínimo 3 e no máximo 63 caracteres de extensão.
+ Os nomes devem ser uma série de um ou mais rótulos separados por um ponto (.) em que cada rótulo:
+ Começa com uma letra minúscula ou um número.
+ Termina com uma letra minúscula ou um número.
+ Contém somente letras minúsculas, números e traços.
+ Os nomes não podem ser formatado como um endereço IP (por exemplo, 192.0.2.0).
1. Na lista de **regiões**, escolha uma AWS região para seu bucket do Amazon S3. Essa AWS região deve ser a mesma AWS região do ElastiCache backup que você deseja exportar.
1. Escolha **Criar**.
Para obter mais informações sobre como criar um bucket do Amazon S3, consulte [Criação de um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html), no *Guia do usuário do Amazon Simple Storage Service*.
## Conceda ElastiCache acesso ao seu bucket Amazon S3
ElastiCache Para poder copiar um snapshot em um bucket do Amazon S3, você deve atualizar sua política de bucket do IAM para ElastiCache conceder acesso ao bucket.
**Atenção**
Mesmo que os backups copiados em um bucket do Amazon S3 sejam criptografados, seus dados podem ser acessados por qualquer pessoa com acesso ao seu bucket do Amazon S3. Portanto, recomendamos que você configure políticas do IAM para impedir o acesso não autorizado a esse bucket do Amazon S3. Para obter mais informações, consulte [Gerenciamento de acesso](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) no *Guia do usuário do Amazon S3*.
Para criar as permissões adequadas em um bucket do Amazon S3, siga as etapas descritas abaixo.
**Para conceder ElastiCache acesso a um bucket do S3**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Escolha o nome do bucket do Amazon S3 para o qual você deseja copiar o backup. Esse deve ser o bucket do S3 que você criou em [Crie um bucket Amazon S3](#backups-exporting-create-s3-bucket).
1. Selecione a guia **Permissions** (Permissões) e, em **Permissions** (Permissões), escolha **Access control list (ACL)** (Lista de controle de acesso (ACL)) e, depois, **Edit** (Editar).
1. Adicionar ID canônico do beneficiário `540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353` com as seguintes opções:
+ **Objetos: listar, gravar**
+ **ACL de bucket: ler, gravar**
**nota**
Para a GovCloud região PDT, o ID canônico é. `40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6`
Para a GovCloud região OSU, o ID canônico é. `c54286759d2a83da9c480405349819c993557275cf37d820d514b42da6893f5c`
1. Escolha **Salvar**.
## Exportar e ElastiCache fazer backup
Agora você criou seu bucket do S3 e concedeu ElastiCache permissões para acessá-lo. Em seguida, você pode usar o ElastiCache console, a AWS CLI ou a ElastiCache API para exportar seu snapshot para ele.
Veja a seguir um exemplo de como a política atualizada pode parecer.
------
#### [ 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/*"
]
}
]
}
```
------
Para escolher regiões, veja a seguir um exemplo da aparência da política atualizada do IAM para o bucket do S3. O exemplo usa a região Ásia-Pacífico (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/*"
]
}
]
}
```
------
### Exportação de um ElastiCache backup (console)
As etapas a seguir usam o ElastiCache console para exportar um backup para um bucket do Amazon S3 para que você possa acessá-lo de fora. ElastiCache O bucket do Amazon S3 deve estar na mesma AWS região do ElastiCache backup.
**Para exportar um ElastiCache backup para um bucket do Amazon S3**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Para ver uma lista dos seus backups, no painel de navegação esquerdo, escolha **Backups**.
1. Na lista de backups, escolha a caixa à esquerda do nome do backup que você deseja exportar.
1. Escolha **Copiar**.
1. Em **Create a Copy of the Backup?** (Criar uma cópia do backup?), faça o seguinte:
1. Na caixa **New backup name** (Novo nome de backup), digite um nome para seu novo backup.
O nome deve ter entre 1 e 1.000 caracteres e pode ser codificado em UTF-8.
ElastiCache adiciona um identificador de instância e `.rdb` ao valor que você insere aqui. Por exemplo, se você inserir `my-exported-backup`, ElastiCache criará `my-exported-backup-0001.rdb`.
1. Na lista **Target S3 Location** (Local do S3 de destino), escolha o nome do bucket do Amazon S3 para o qual você deseja copiar seu backup (o bucket que você criou em [Crie um bucket Amazon S3](#backups-exporting-create-s3-bucket)).
O **local de destino do S3** deve ser um bucket do Amazon S3 na região AWS do backup com as seguintes permissões para que o processo de exportação seja bem-sucedido.
+ Acesso ao objeto: **Ler** e **Escrever**.
+ Permissões de acesso: **Ler**.
Para obter mais informações, consulte [Conceda ElastiCache acesso ao seu bucket Amazon S3](#backups-exporting-grant-access).
1. Escolha **Copiar**.
**nota**
Se seu bucket do S3 não tiver as permissões necessárias ElastiCache para exportar um backup para ele, você receberá uma das seguintes mensagens de erro. Retorne para [Conceda ElastiCache acesso ao seu bucket Amazon S3](#backups-exporting-grant-access) a fim de adicionar as permissões especificadas e tente exportar o backup novamente.
ElastiCache não recebeu permissões READ %s no S3 Bucket.
**Solução:** adicione permissões de Leitura no bucket.
ElastiCache não recebeu permissões de GRAVAÇÃO %s no S3 Bucket.
**Solução:** adicione permissões de Gravação no bucket.
ElastiCache não recebeu as permissões READ\$1ACP %s no S3 Bucket.
**Solução:** adicione permissão de acesso de **Leitura** no bucket.
Se você quiser copiar seu backup para outra AWS região, use o Amazon S3 para copiá-lo. Para obter mais informações, consulte [Cópia de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MakingaCopyofanObject.html) no *Guia do usuário do Amazon Simple Storage Service*.
### Exportação de um ElastiCache backup sem servidor ()AWS CLI
**Exportação de um backup de um cache sem servidor**
Exporte o backup para um bucket do Amazon S3 usando a operação `export-serverless-cache-snapshot` da CLI com os seguintes parâmetros:
**Parâmetros**
+ `--serverless-cache-snapshot-name` - Nome do backup a ser copiado.
+ `--s3-bucket-name`: nome do bucket do Amazon S3 no qual você deseja exportar o backup. Uma cópia do backup é feita no bucket especificado.
`--s3-bucket-name`Deve ser um bucket do Amazon S3 na AWS região do backup com as seguintes permissões para que o processo de exportação seja bem-sucedido.
+ Acesso ao objeto: **Ler** e **Escrever**.
+ Permissões de acesso: **Ler**.
A operação a seguir copia um backup para my-s3-bucket.
Para Linux, macOS ou Unix:
```
aws elasticache export-serverless-cache-snapshot \
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 \
--s3-bucket-name my-s3-bucket
```
Para Windows:
```
aws elasticache export-serverless-cache-snapshot ^
--serverless-cache-snapshot-name automatic.my-redis-2023-11-27 ^
--s3-bucket-name my-s3-bucket
```
### Exportando um backup de ElastiCache cluster baseado em nós ()AWS CLI
**Exportar um backup de um cluster baseado em nós**
Exporte o backup para um bucket do Amazon S3 usando a operação `copy-snapshot` da CLI com os seguintes parâmetros:
**Parâmetros**
+ `--source-snapshot-name` - Nome do backup a ser copiado.
+ `--target-snapshot-name` - Nome da cópia do backup.
O nome deve ter entre 1 e 1.000 caracteres e pode ser codificado em UTF-8.
ElastiCache adiciona um identificador de instância e `.rdb` ao valor inserido aqui. Por exemplo, se você inserir `my-exported-backup`, ElastiCache criará `my-exported-backup-0001.rdb`.
+ `--target-bucket`: nome do bucket do Amazon S3 no qual você deseja exportar o backup. Uma cópia do backup é feita no bucket especificado.
`--target-bucket`Deve ser um bucket do Amazon S3 na AWS região do backup com as seguintes permissões para que o processo de exportação seja bem-sucedido.
+ Acesso ao objeto: **Ler** e **Escrever**.
+ Permissões de acesso: **Ler**.
Para obter mais informações, consulte [Conceda ElastiCache acesso ao seu bucket Amazon S3](#backups-exporting-grant-access).
A operação a seguir copia um backup para my-s3-bucket.
Para Linux, macOS ou 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
```
Para 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
```
# Restauração de um backup para um novo cache
Você pode restaurar um backup existente do Valkey em um novo cache do Valkey ou cluster baseado em nós e restaurar um backup existente do Redis OSS em um novo cache do Redis OSS ou cluster baseado em nós. Você também pode restaurar um backup existente de cache de tecnologia sem servidor do Memcached em um novo cache de tecnologia sem servidor do Memcached.
## Restauração de um backup para um cache sem servidor (console)
**nota**
ElastiCache O Serverless suporta arquivos RDB compatíveis com Valkey 7.2 e superior e versões do Redis OSS entre 5.0 e a versão mais recente disponível.
**Para restaurar um backup para um cache sem servidor (console)**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Backups**.
1. Na lista de backups, escolha a caixa à esquerda do nome do backup que você deseja restaurar.
1. Escolha **Ações** e **Restaurar**
1. Insira um nome para o novo cache sem servidor e uma descrição opcional.
1. Clique em **Criar** para criar o novo cache e importar dados do backup.
## Restauração de um backup para um cluster baseado em nós (console)
**Para restaurar um backup para um cluster baseado em nós (console)**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Backups**.
1. Na lista de backups, escolha a caixa à esquerda do nome do backup do qual você deseja restaurar.
1. Escolha **Ações** e **Restaurar**
1. Escolha **Cache baseado em nós** e personalize as configurações do cluster, como tipo de nó, tamanhos, número de fragmentos, réplicas, posicionamento AZ e configurações de segurança.
1. Escolha **Criar** para criar o novo cluster baseado em nós e importar dados do backup.
## Restauração de um backup para um cache sem servidor (AWS CLI)
**nota**
ElastiCache O Serverless suporta arquivos RDB compatíveis com Valkey 7.2 e superior e versões do Redis OSS entre 5.0 e a versão mais recente disponível.
**Para restaurar um backup para um cache sem servidor novo (AWS CLI)**
O AWS CLI exemplo a seguir cria um novo cache usando `create-serverless-cache` e importa dados de um backup.
Para Linux, macOS ou Unix:
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine redis
--snapshot-arns-to-restore Snapshot-ARN
```
Para Windows:
```
aws elasticache create-serverless-cache ^
--serverless-cache-name CacheName ^
--engine redis ^
--snapshot-arns-to-restore Snapshot-ARN
```
# Exclusão de um backup
Um backup automático é excluído automaticamente quando o limite de retenção expira. Se você excluir um cluster, todos os seus backups automáticos também serão excluídos. Se você excluir um grupo de replicação, todos os backups automáticos dos clusters desse grupo também serão excluídos.
ElastiCache fornece uma operação de API de exclusão que permite excluir um backup a qualquer momento, independentemente de o backup ter sido criado automática ou manualmente. Como os backups manuais não possuem um limite de retenção, a exclusão manual é a única maneira de removê-los.
Você pode excluir um backup usando o ElastiCache console AWS CLI, o ou a ElastiCache API.
## Exclusão de um backup (console)
O procedimento a seguir exclui um backup usando o ElastiCache console.
**Para excluir um backup**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, selecione **Backups**.
A tela Backups aparece com uma lista dos seus backups.
1. Escolha a caixa à esquerda do nome do backup que você deseja excluir.
1. Escolha **Excluir**.
1. Se você quiser excluir esse backup, escolha **Excluir** na tela de confirmação **Excluir backup**. O status muda para *deleting*.
## Exclusão de um backup sem servidor (AWS CLI)
Use a AWS CLI operação delete-snapshot com o parâmetro a seguir para excluir um backup sem servidor.
+ `--serverless-cache-snapshot-name` - Nome do backup a ser excluído.
O código a seguir exclui o backup `myBackup`.
```
aws elasticache delete-serverless-cache-snapshot --serverless-cache-snapshot-name myBackup
```
Para obter mais informações, consulte [delete-serverless-cache-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-serverless-cache-snapshot.html) na *Referência de comandos da AWS CLI*.
## Excluir um backup de cluster baseado em nós (AWS CLI)
Use a AWS CLI operação delete-snapshot com o parâmetro a seguir para excluir um backup de cluster baseado em nós.
+ `--snapshot-name` - Nome do backup a ser excluído.
O código a seguir exclui o backup `myBackup`.
```
aws elasticache delete-snapshot --snapshot-name myBackup
```
Para obter mais informações, consulte [delete-snapshot](https://docs.aws.amazon.com/cli/latest/reference/elasticache/delete-snapshot.html) na *Referência de comandos da AWS CLI*.
# Marcação de backups
Você pode atribuir os próprios metadados a cada backup na forma de tags. As tags permitem categorizar seus backups de diferentes formas (como por finalidade, por proprietário ou por ambiente). Isso é útil quando você tem muitos recursos do mesmo tipo. É possível identificar rapidamente um recurso específico baseado nas tags que você atribuiu a ele. Para obter mais informações, consulte [Recursos que podem ser marcados](Tagging-Resources.md#Tagging-your-resources).
Tags de alocação de custos são um meio de rastrear seus custos em vários serviços da AWS, agrupando suas despesas em faturas por valores de tag. Para saber mais sobre alocação de custos, consulte [Usar tags de alocação de custos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html).
Usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache, você pode adicionar, listar, modificar, remover ou copiar tags de alocação de custos em seus backups. Para obter mais informações, consulte [Monitoramento de custos com tags de alocação de custos](Tagging.md).
# Tutorial: propagação de um novo cluster baseado em nós com um backup criado externamente
Ao criar um novo cluster baseado em nós do Valkey ou Redis OSS, você pode propagá-lo com dados de um arquivo de backup .rdb do Valkey ou Redis OSS. A semeadura do cluster é útil se você atualmente gerencia uma instância Valkey ou Redis OSS fora ElastiCache e deseja preencher seu novo ElastiCache cluster baseado em nós do Redis OSS com seus dados existentes do Valkey ou do Redis OSS.
Para implantar um novo cluster baseado em nós Valkey ou Redis OSS a partir de um backup Valkey ou Redis OSS criado na Amazon, consulte. ElastiCache [Restauração de um backup para um novo cache](backups-restoring.md)
Ao usar um arquivo .rdb do Valkey ou Redis OSS para propagar um novo cluster baseado em nós, você pode fazer o seguinte:
+ Atualização de um cluster não particionado para um cluster baseado em nós do Valkey ou Redis OSS (modo cluster habilitado) que execute o Redis OSS versão 3.2.4.
+ Especifique um número de fragmentos (chamados de grupos de nós na API ou na CLI) no novo cluster baseado em nós. Esse número pode ser diferente do número de fragmentos no cluster baseado em nós que foi usado para criar o arquivo de backup.
+ Especificar um tipo de nó diferente para o novo cluster baseado em nós, maior ou menor que o usado no cluster que fez o backup. Se você escalar para um tipo de nó menor, certifique-se de que o novo tipo de nó tenha memória suficiente para seus dados e a sobrecarga do Valkey ou Redis OSS. Para obter mais informações, consulte [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md).
+ Distribua suas chaves nos slots do novo cluster do Valkey ou Redis OSS (modo cluster habilitado) de forma diferente do que no cluster que foi usado para criar o arquivo de backup.
**nota**
Não é possível propagar um cluster do Valkey ou Redis OSS (modo cluster desabilitado) a partir de um arquivo .rdb criado a partir de um cluster do Valkey ou Redis OSS (modo cluster habilitado).
**Importante**
É necessário garantir que seus dados de backup do Valkey ou Redis OSS não excedam os recursos do nó. Por exemplo, você não pode fazer upload de um arquivo .rdb com 5 GB de dados do Valkey ou Redis OSS em um nó cache.m3.medium que tenha 2,9 GB de memória.
Se o backup for muito grande, o cluster resultante terá um status de `restore-failed`. Se isso acontecer, você deverá excluir o cluster e começar de novo.
Para obter uma lista completa dos tipos e especificações de nós, consulte os [recursos [Parâmetros específicos de node-type do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific) e detalhes dos ElastiCache produtos da Amazon](https://aws.amazon.com/elasticache/details/).
Só é possível criptografar um arquivo .rdb do Valkey ou Redis OSS com a criptografia do lado do servidor do Amazon S3 (SSE-S3). Para obter mais informações, consulte [Proteger dados usando a criptografia no lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html).
A seguir, você encontrará tópicos que orientam você na migração do seu cluster de fora do Valkey ou do Redis OSS ElastiCache para o Redis OSS. ElastiCache
**Topics**
+ [Etapa 1: criar um backup do Valkey ou Redis OSS](#backups-seeding-redis-create-backup)
+ [Etapa 2: criar um bucket e uma pasta no Amazon S3](#backups-seeding-redis-create-s3-bucket)
+ [Etapa 3: carregar seu backup no Amazon S3](#backups-seeding-redis-upload)
+ [Etapa 4: conceder acesso de ElastiCache leitura ao arquivo.rdb](#backups-seeding-redis-grant-access)
**Topics**
+ [Etapa 1: criar um backup do Valkey ou Redis OSS](#backups-seeding-redis-create-backup)
+ [Etapa 2: criar um bucket e uma pasta no Amazon S3](#backups-seeding-redis-create-s3-bucket)
+ [Etapa 3: carregar seu backup no Amazon S3](#backups-seeding-redis-upload)
+ [Etapa 4: conceder acesso de ElastiCache leitura ao arquivo.rdb](#backups-seeding-redis-grant-access)
## Etapa 1: criar um backup do Valkey ou Redis OSS
**Para criar o backup do Valkey ou do Redis OSS para alimentar sua ElastiCache instância do Redis OSS**
1. Conecte-se à sua instância do Valkey ou Redis OSS existente.
1. Execute a operação `BGSAVE` ou `SAVE` para criar um backup. Observe onde seu arquivo .rdb está localizado.
`BGSAVE` é assíncrono e não bloqueia outros clientes durante o processamento. Para obter mais informações, consulte [BGSAVE](https://valkey.io/commands/bgsave) no site do Valkey.
`SAVE` é síncrono e bloqueia outros processos até terminar. Para obter mais informações, consulte [SAVE](https://valkey.io/commands/save) no site do Valkey.
Para obter informações adicionais sobre como criar um backup, consulte [Persistência](https://valkey.io/topics/persistence) no site do Valkey.
## Etapa 2: criar um bucket e uma pasta no Amazon S3
Quando você tiver criado o arquivo de backup, precisará carregá-lo em uma pasta dentro de um bucket do Amazon S3. Para fazer isso, primeiro você deve ter um bucket do Amazon S3 e uma pasta dentro desse bucket. Se você já possui um bucket do Amazon S3 e uma pasta com as permissões apropriadas, poderá pular para [Etapa 3: carregar seu backup no Amazon S3](#backups-seeding-redis-upload).
**Como criar um bucket do Amazon S3**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Para criar um bucket do Amazon S3, siga as instruções em [Criação de um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html) no *Guia do usuário do Amazon Simple Storage Service*.
O nome do bucket do Amazon S3 deve estar em conformidade com o DNS. Caso contrário, não ElastiCache conseguirá acessar seu arquivo de backup. As regras para a conformidade de DNS são:
+ Os nomes devem ter no mínimo 3 e no máximo 63 caracteres de extensão.
+ Os nomes devem ser uma série de um ou mais rótulos separados por um ponto (.) em que cada rótulo:
+ Começa com uma letra minúscula ou um número.
+ Termina com uma letra minúscula ou um número.
+ Contém somente letras minúsculas, números e traços.
+ Os nomes não podem ser formatado como um endereço IP (por exemplo, 192.0.2.0).
Você deve criar seu bucket Amazon S3 na mesma AWS região do seu novo cluster OSS ElastiCache para Redis. Essa abordagem garante a maior velocidade de transferência de dados ao ElastiCache ler seu arquivo.rdb do Amazon S3.
**nota**
Para manter seus dados da forma mais segura possível, restrinja ao máximo as permissões em seu bucket do Amazon S3. Ao mesmo tempo, as permissões ainda precisam permitir que o bucket e seu conteúdo seja usado para propagar o novo cluster do Valkey ou Redis OSS.
**Para adicionar uma pasta a um bucket do Amazon S3**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Escolha o nome do bucket para o qual deseja fazer upload do arquivo .rdb.
1. Selecione **Criar pasta**.
1. Insira um nome para a nova pasta.
1. Escolha **Salvar**.
Anote o nome do bucket e o nome da pasta.
## Etapa 3: carregar seu backup no Amazon S3
Agora, faça upload do arquivo .rdb criado em [Etapa 1: criar um backup do Valkey ou Redis OSS](#backups-seeding-redis-create-backup). Carregue-o no bucket e na pasta do Amazon S3 que você criou em [Etapa 2: criar um bucket e uma pasta no Amazon S3](#backups-seeding-redis-create-s3-bucket). Para obter mais informações sobre essa tarefa, consulte [Adicionar um objeto a um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html). Entre as etapas 2 e 3, escolha o nome da pasta que você criou.
**Para carregar seu arquivo .rdb em uma pasta do Amazon S3**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Escolha o nome do bucket do Amazon S3 criado na Etapa 2.
1. Escolha o nome da pasta que você criou na Etapa 2.
1. Escolha **Carregar**.
1. Escolha **Adicionar arquivos**.
1. Navegue para encontrar um ou mais arquivos que deseja carregar e depois escolha esses arquivos. Para escolher vários arquivos, mantenha pressionada a tecla Ctrl enquanto escolhe o nome de cada arquivo.
1. Escolha **Open (Abrir)**.
1. Confirme se os arquivos corretos estão listados na caixa de diálogo **Upload** e depois escolha **Upload**.
Anote o caminho para o arquivo .rdb. Por exemplo, se o nome do bucket for `myBucket` e o caminho for `myFolder/redis.rdb`, insira `myBucket/myFolder/redis.rdb`. Você precisa desse caminho para propagar o novo cluster com os dados neste backup.
Para obter mais informações, consulte [Restrições e limitações de bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/BucketRestrictions.html) no *Guia do usuário do Amazon Simple Storage Service*.
## Etapa 4: conceder acesso de ElastiCache leitura ao arquivo.rdb
Agora, conceda acesso de ElastiCache leitura ao seu arquivo de backup .rdb. Você concede ElastiCache acesso ao seu arquivo de backup de uma forma diferente, dependendo se seu bucket está em uma AWS região padrão ou em uma AWS região opcional.
AWS As regiões introduzidas antes de 20 de março de 2019 estão habilitadas por padrão. Você pode começar a trabalhar nessas AWS regiões imediatamente. As regiões introduzidas após 20 de março de 2019, como Ásia-Pacífico (Hong Kong) e Oriente Médio (Bahrein), são desabilitadas por padrão. Você deve habilitar ou escolher essas regiões para poder usá-las, conforme descrito em [Gerenciar regiões da AWS](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) na *Referência geral da AWS*.
Escolha sua abordagem de acordo com sua AWS região:
+ Para uma região padrão, use o procedimento em [Conceder acesso de ElastiCache leitura ao arquivo.rdb em uma região padrão](#backups-seeding-redis-default-region).
+ Para uma região opcional, use o procedimento em [Conceda acesso de ElastiCache leitura ao arquivo.rdb em uma região opcional](#backups-seeding-opt-in-region).
### Conceder acesso de ElastiCache leitura ao arquivo.rdb em uma região padrão
AWS As regiões introduzidas antes de 20 de março de 2019 estão habilitadas por padrão. Você pode começar a trabalhar nessas AWS regiões imediatamente. As regiões introduzidas após 20 de março de 2019, como Ásia-Pacífico (Hong Kong) e Oriente Médio (Bahrein), são desabilitadas por padrão. Você deve habilitar ou escolher essas regiões para poder usá-las, conforme descrito em [Gerenciar regiões da AWS](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) na *Referência geral da AWS*.
**Para conceder acesso de ElastiCache leitura ao arquivo de backup em uma AWS região ativada por padrão**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Escolha o nome do bucket do S3 que contém seu arquivo .rdb.
1. Escolha o nome da pasta que contém seu arquivo .rdb.
1. Escolha o nome do seu arquivo de backup .rdb. O nome do arquivo selecionado aparece acima das guias na parte superior da página.
1. Escolha **Permissões**.
1. Se **aws-scs-ssomente 3 leituras** ou uma das canônicas IDs na lista a seguir não estiver listada como usuário, faça o seguinte:
1. Em **Acesso para outras AWS contas**, escolha **Adicionar favorecido**.
1. Na caixa, adicione a ID canônica da AWS região conforme mostrado a seguir:
+ AWS GovCloud Região (Oeste dos EUA):
```
40fa568277ad703bd160f66ae4f83fc9dfdfd06c2f1b5060ca22442ac3ef8be6
```
**Importante**
O backup deve estar localizado em um bucket S3 AWS GovCloud (US) para que você possa baixá-lo em um cluster Valkey ou Redis OSS em.AWS GovCloud (US)
+ AWS Regiões ativadas por padrão:
```
540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353
```
1. Defina as permissões no bucket escolhendo **Yes (Sim)** para o seguinte:
+ **Objeto de lista/gravação**
+ **Permissões ACL de objetos de leitura/gravação**
1. Escolha **Salvar**.
1. Escolha **Overview** (Visão geral) e escolha **Download** (Fazer download).
### Conceda acesso de ElastiCache leitura ao arquivo.rdb em uma região opcional
AWS As regiões introduzidas antes de 20 de março de 2019 estão habilitadas por padrão. Você pode começar a trabalhar nessas AWS regiões imediatamente. As regiões introduzidas após 20 de março de 2019, como Ásia-Pacífico (Hong Kong) e Oriente Médio (Bahrein), são desabilitadas por padrão. Você deve habilitar ou escolher essas regiões para poder usá-las, conforme descrito em [Gerenciar regiões da AWS](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) na *Referência geral da AWS*.
Agora, conceda acesso de ElastiCache leitura ao seu arquivo de backup .rdb.
**Para conceder acesso de ElastiCache leitura ao arquivo de backup**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)
1. Escolha o nome do bucket do S3 que contém seu arquivo .rdb.
1. Escolha o nome da pasta que contém seu arquivo .rdb.
1. Escolha o nome do seu arquivo de backup .rdb. O nome do arquivo selecionado aparece acima das guias na parte superior da página.
1. Escolha a guia **Permissões**.
1. Em **Permissões**, escolha **Política de bucket** e, em seguida, **Editar**.
1. Atualize a política para conceder as permissões ElastiCache necessárias para realizar operações:
+ Adicione `[ "Service" : "region-full-name.elasticache-snapshot.amazonaws.com" ]` a `Principal`.
+ Adicione as seguintes permissões necessárias para exportar um snapshot para o bucket do Amazon S3:
+ `"s3:GetObject"`
+ `"s3:ListBucket"`
+ `"s3:GetBucketAcl"`
Veja a seguir um exemplo de como a política atualizada pode parecer.
------
#### [ 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. Escolha **Salvar alterações**.
### Semeie o ElastiCache cluster com os dados do arquivo.rdb
Agora você está pronto para criar um ElastiCache cluster e plantá-lo com os dados do arquivo.rdb. Para criar o cluster, siga as instruções em [Criação de um cluster do Valkey ou Redis OSS](Clusters.Create.md) ou [Criação de um grupo de replicação do Valkey ou Redis OSS do início](Replication.CreatingReplGroup.NoExistingCluster.md). Certifique-se de escolher o Valkey ou Redis OSS como seu mecanismo de cluster.
O método usado para saber ElastiCache onde encontrar o backup que você enviou para o Amazon S3 depende do método usado para criar o cluster:
**Prepare o ElastiCache cluster ou grupo de replicação do for Redis OSS com os dados do arquivo.rdb**
+ **Usando o ElastiCache console**
Ao selecionar **Cluster settings** (Configurações de cluster), escolha **Restore from backups** (Restaurar de backups) como seu método de criação de cluster e escolha **Other backups** (Outros backups) como sua **Source** (Origem) na seção **Backup source** (Origem de backup). Na caixa **Propagar local S3 do arquivo RDB**, digite o caminho do Amazon S3 para o(s) arquivo(s). Se você tiver vários arquivos .rdb, digite o caminho para cada um em uma lista separada por vírgulas. O caminho do Amazon S3 parece-se com `myBucket/myFolder/myBackupFilename.rdb`.
+ **Usando o AWS CLI**
Se você usar a operação `create-cache-cluster` ou `create-replication-group`, use o parâmetro `--snapshot-arns` para especificar um ARN totalmente qualificado para cada arquivo .rdb. Por exemplo, .`arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb` O ARN deve ser resolvido para os arquivos de backup que você armazenou no Amazon S3.
+ **Usando a ElastiCache API**
Se você usar a operação `CreateCacheCluster` ou a `CreateReplicationGroup` ElastiCache API, use o parâmetro `SnapshotArns` para especificar um ARN totalmente qualificado para cada arquivo.rdb. Por exemplo, .`arn:aws:s3:::myBucket/myFolder/myBackupFilename.rdb` O ARN deve ser resolvido para os arquivos de backup que você armazenou no Amazon S3.
**Importante**
Ao propagar um cluster do Valkey ou Redis OSS (modo cluster habilitado), você precisa configurar cada grupo de nós (fragmento) no novo cluster ou grupo de replicação. Use o parâmetro `--node-group-configuration` (API: `NodeGroupConfiguration`) para fazer isso. Para saber mais, consulte:
CLI: [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)na referência AWS CLI
API: [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)na referência da ElastiCache API
Durante o processo de criação do cluster, os dados no backup do Valkey ou Redis OSS são gravados no cluster. Você pode monitorar o progresso visualizando as mensagens do ElastiCache evento. Para fazer isso, consulte o ElastiCache console e escolha **Eventos de cache**. Você também pode usar a interface de linha de AWS ElastiCache comando ou a ElastiCache API para obter mensagens de eventos. Para obter mais informações, consulte [Visualizando ElastiCache eventos](ECEvents.Viewing.md).
# Versões e atualizações do motor em ElastiCache
Esta seção aborda os mecanismos Valkey, Memcached e Redis OSS aceitos e como realizar atualizações. Observe que todos os atributos disponíveis com o Redis OSS 7.2 estão disponíveis no Valkey 7.2 e posteriores, por padrão. Você também pode fazer o upgrade de alguns mecanismos existentes ElastiCache do Redis OSS para um mecanismo Valkey.
# Atualização das versões do mecanismo, incluindo atualizações de mecanismos cruzados
**Valkey e Redis OSS**
Com Valkey e Redis OSS, você inicia atualizações de versão no seu cluster ou grupo de replicação modificando-o com o uso do console do ElastiCache, da AWS CLI ou da API do ElastiCache e especificando uma versão mais nova do mecanismo.
Você também pode fazer uma atualização cruzada do Redis OSS para o Valkey. Para obter mais informações sobre como fazer atualizações cruzadas, consulte [Como atualizar do Redis OSS para o Valkey](#VersionManagement.HowTo.cross-engine-upgrade).
**Topics**
+ [Como atualizar do Redis OSS para o Valkey](#VersionManagement.HowTo.cross-engine-upgrade)
+ [Resolver bloqueios de atualização do mecanismo Valkey ou Redis OSS](#resolving-blocked-engine-upgrades)
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Memcached**
Com o Memcached, para iniciar as atualizações de versão no seu cluster, modifique-o e especifique uma versão mais recente do mecanismo. Faça isso usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache:
+ Para usar a Console de gerenciamento da AWS, consulte - [Uso do Console de gerenciamento da AWS do ElastiCache](Clusters.Modify.md#Clusters.Modify.CON).
+ Para usar a AWS CLI, consulte [Uso da AWS CLI com o ElastiCache](Clusters.Modify.md#Clusters.Modify.CLI).
+ Para usar a API do ElastiCache, consulte [Uso da API do ElastiCache](Clusters.Modify.md#Clusters.Modify.API).
## Como atualizar do Redis OSS para o Valkey
O Valkey foi projetado como um substituto imediato para o Redis OSS 7. Você pode atualizar do Redis OSS para o Valkey usando o Console, a API ou a CLI, especificando o novo mecanismo e a versão principal do mecanismo. O endereço IP do endpoint e todos os outros aspectos do aplicativo não serão alterados pela atualização. Ao atualizar do Redis OSS 5.0.6 e superior, você não terá tempo de inatividade.
**nota**
**Requisitos da versão CLI da AWS para atualizações do Redis OSS para Valkey:**
Para CLI da AWS v1: versão mínima exigida 1.35.2 (versão atual: 1.40.22)
Para CLI da AWS v2: versão mínima exigida 2.18.2 (versão atual: 2.27.22)
**nota**
Ao atualizar de versões anteriores do Redis OSS 5.0.6, você pode experimentar um tempo de failover de 30 a 60 segundos durante a propagação do DNS.
Para atualizar um cluster de nó único Redis OSS (modo cluster desabilitado) existente para o mecanismo Valkey, primeiro siga estas etapas: [Criação de um grupo de replicação usando um cluster existente](Replication.CreatingReplGroup.ExistingCluster.md). Depois que o cluster de nó único Redis OSS (modo cluster desabilitado) tiver sido adicionado a um grupo de replicação, você pode fazer atualização cruzada entre mecanismos para o Valkey.
### Atualização de um grupo de replicação do Redis OSS para o Valkey
Se você tiver um grupo de replicação Redis OSS existente que esteja usando o grupo de parâmetros de cache padrão, poderá atualizar para o Valkey especificando o novo mecanismo e a versão do mecanismo com a API modify-replication-group.
Para Linux, macOS ou Unix:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0
```
Para Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0
```
Se você tiver um grupo de parâmetros de cache personalizado aplicado ao grupo de replicação do Redis OSS existente que deseja atualizar, também será necessário passar um grupo de parâmetros de cache personalizado do Valkey na solicitação. O grupo de parâmetros personalizados de entrada do Valkey deve ter os mesmos valores de parâmetros estáticos do Redis OSS que o grupo de parâmetros personalizados do Redis OSS existente.
Para Linux, macOS ou Unix:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--engine valkey \
--engine-version 8.0 \
--cache-parameter-group-name myParamGroup
```
Para Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--engine valkey ^
--engine-version 8.0 ^
--cache-parameter-group-name myParamGroup
```
### Atualização de um cache de tecnologia sem servidor Redis OSS para Valkey com a CLI
Para Linux, macOS ou Unix:
```
aws elasticache modify-serverless-cache \
--serverless-cache-name myCluster \
--engine valkey \
--major-engine-version 8
```
Para Windows:
```
aws elasticache modify-serverless-cache ^
--serverless-cache-name myCluster ^
--engine valkey ^
--major-engine-version 8
```
### Atualização do Redis OSS para o Valkey com o Console
**Atualização do Redis OSS 5 para o Valkey**
1. Selecione o cache do Redis OSS para atualizar.
1. Uma janela **Atualizar para o Valkey** deve aparecer. Selecione o botão **Atualizar para o Valkey**.
1. Acesse **Configurações de cache** e selecione **Versão do mecanismo**. A versão mais recente do Valkey é recomendada.
1. Se esse cache for de tecnologia sem servidor, você precisará atualizar o grupo de parâmetros. Vá para a área **Grupos de parâmetros** das **Configurações de cache** e selecione um grupo de parâmetros apropriado, como *default.valkey8*.
1. Selecione **Atualizar**.
Esse cache agora será listado na área Valkey do console.
**nota**
A atualização diretamente do Redis OSS 4 ou inferior para o Valkey pode incluir um tempo de failover maior de 30 a 60 segundos durante a propagação do DNS.
### Como fazer o downgrade do Valkey para o Redis OSS
Se, por algum motivo, você desejar reverter seu cluster atualizado, o Amazon ElastiCache é compatível com a reversão de um cache do Valkey 7.2 para o Redis OSS 7.1. Você pode realizar uma reversão usando as mesmas etapas de console, API ou CLI de uma atualização do mecanismo e especificando o Redis OSS 7.1 como a versão do mecanismo de destino. As reversões usam os mesmos processos de uma atualização. O endereço IP do endpoint e todos os outros aspectos do aplicativo não serão alterados pela reversão e você não terá tempo de inatividade.
Além disso, você pode restaurar um instantâneo criado a partir do cache do Valkey 7.2 como um cache do Redis OSS 7.1. Ao restaurar a partir de um snapshot, você pode especificar o Redis OSS 7.1 como a versão do mecanismo de destino. Ao usar essa opção, um novo cache será criado a partir do instantâneo. A restauração a partir de um instantâneo não tem efeito no cache do Valkey a partir do qual o instantâneo foi criado.
Os seguintes requisitos e limitações se aplicam ao realizar uma reversão:
+ O ElastiCache só é compatível com a reversão do Valkey 7.2 para o Redis OSS 7.1. Isso é verdade mesmo se você tiver atualizado para o Valkey 7.2 de uma versão anterior ao Redis OSS 7.1.
+ Qualquer grupo de usuários e usuários associados ao grupo de replicação ou ao cache com tecnologia sem servidor que está sendo revertido devem ser configurados com o tipo de mecanismo `REDIS`.
## Resolver bloqueios de atualização do mecanismo Valkey ou Redis OSS
Conforme mostrado na tabela a seguir, a operação de atualização do mecanismo Valkey ou Redis OSS será bloqueada se você tiver uma operação pendente de aumento vertical da escala.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/VersionManagement.HowTo.html)
**Para resolver uma atualização bloqueada do mecanismo do Redis OSS**
+ Execute um destes procedimentos:
+ Planeje sua operação de atualização do mecanismo Redis OSS ou Valkey para a próxima janela de manutenção, desmarcando a caixa de seleção **Apply immediately (Aplicar imediatamente)**.
Com a CLI, use `--no-apply-immediately`. Com a API, use `ApplyImmediately=false`.
+ Aguarde até sua próxima janela de manutenção (ou depois) para realizar sua operação de atualização do mecanismo Redis OSS.
+ Adicione a operação de aumento vertical da escala do Redis OSS a essa modificação de cluster com a caixa de seleção **Apply Immediately (Aplicar imediatamente)** marcada.
Com a CLI, use `--apply-immediately`. Com a API, use `ApplyImmediately=true`.
Essa abordagem cancela efetivamente a atualização do mecanismo durante a próxima janela de manutenção, executando-a imediatamente.
# Suporte estendido do ElastiCache
Com o suporte estendido do ElastiCache, é possível continuar executando o cache em uma versão principal do mecanismo após a data de término do suporte padrão por um custo adicional. Se você não fizer o upgrade após o término da data de suporte padrão, você será cobrado.
O Suporte estendido fornece as seguintes atualizações e suporte técnico:
+ Atualizações de segurança para CVEs críticos e altos para seu cache e mecanismo de cache
+ Correções de erros e patches para problemas críticos
+ A capacidade de abrir casos de suporte e receber ajuda para solução de problemas dentro do acordo de serviço padrão do ElastiCache
Essa oferta paga oferece a você mais tempo para atualizar para uma versão principal compatível do mecanismo.
Por exemplo, a data de término do suporte padrão do ElastiCache para o Redis OSS 4.0.10 é 31 de janeiro de 2026. Se você não estiver pronto para atualizar manualmente para o Valkey ou para o Redis OSS 6 ou posterior até essa data, o ElastiCache inscreverá automaticamente seus caches no Suporte estendido e você poderá continuar executando o Redis OSS 4.0.10. A partir do primeiro dia do mês após o término do suporte padrão, 1º de fevereiro de 2026, o ElastiCache cobra automaticamente pelo Suporte estendido.
O Suporte estendido para uma versão principal do mecanismo ficará disponível até três anos após a data de término do suporte padrão. Para as versões 4 e 5 do Elasticache para Redis OSS, isso será em 31 de janeiro de 2029. Após essa data, todos os caches que ainda executam as versões 4 e 5 do Redis OSS serão automaticamente atualizados para a versão mais recente do Valkey.
Quando o período de suporte de um mecanismo terminar, os caches que continuarem executando essa versão antiga passarão automaticamente para o Suporte estendido. Você será notificado antes da data de início dos preços do Suporte estendido para que, em vez disso, você possa atualizar sua instância. Você também pode cancelar explicitamente a qualquer momento fazendo o upgrade para as versões compatíveis.
Para ter mais informações sobre as datas de fim do suporte padrão e do Suporte estendido, consulte [ElastiCache versões para o cronograma de fim de vida útil do Redis OSS](engine-versions.md#deprecated-engine-versions) para Valkey, Memcached ou Redis OSS.
**Topics**
+ [Cobranças do Suporte estendido do ElastiCache](extended-support-charges.md)
+ [Versões com o Suporte estendido do ElastiCache](extended-support-versions.md)
+ [ElastiCache e responsabilidades do cliente com o Suporte estendido do ElastiCache](extended-support-responsibilities.md)
# Cobranças do Suporte estendido do ElastiCache
Você pagará por todos os mecanismos inscritos no Suporte estendido do ElastiCache desde o dia seguinte à data de término do suporte padrão. Para saber a data de término do suporte padrão do ElastiCache, consulte [Versões com o Suporte estendido do ElastiCache](extended-support-versions.md).
A cobrança adicional pelo Suporte estendido do ElastiCache é interrompida automaticamente ao realizar uma das seguintes ações:
+ Atualizar para uma versão do mecanismo coberta pelo suporte padrão.
+ Excluir o cache que está executando uma versão principal após a data de fim do suporte padrão do ElastiCache.
As cobranças serão reiniciadas se a versão do mecanismo de destino entrar no Suporte estendido no futuro.
Por exemplo, digamos que o ElastiCache versão 4 para Redis OSS entre no Suporte estendido em 1º de fevereiro de 2026 e você atualize seus caches da v4 para a v6 em 1º de janeiro de 2027. Você só será cobrado por 11 meses de Suporte estendido, no ElastiCache versão 4 para Redis OSS. Se você continuar executando o ElastiCache versão 6 para Redis OSS após a data de fim do suporte padrão de 31 de janeiro de 2027, esses caches voltarão a incorrer em cobranças de Suporte estendido a partir de 1º de fevereiro de 2027.
Você pode evitar a cobrança pelo Suporte do ElastiCacheExtended impedindo que o ElastiCache crie ou restaure um cache após a data de fim do suporte padrão do ElastiCache.
Para obter mais informações, consulte [Definição de preço Amazon ElastiCache](https://aws.amazon.com/elasticache/pricing/).
# Versões com o Suporte estendido do ElastiCache
As versões 4 e 5 do Redis Open Source Software (OSS) atingiram o fim da vida útil da comunidade em 2020 e 2022, respectivamente. Isso significa que a comunidade não lançará mais atualizações, correções de erros ou patches de segurança. O suporte padrão para as versões 4 e 5 do ElastiCache Redis OSS no ElastiCache terminará em 31 de janeiro de 2026. Continuar usando versões não suportadas do Redis OSS pode deixar seus dados vulneráveis a [vulnerabilidades e exposições comuns](https://nvd.nist.gov/vuln-metrics/cvss) (CVEs) conhecidas.
A partir de 1º de fevereiro de 2026, os caches do ElastiCache ainda em execução nas versões 4 e 5 do Redis OSS serão automaticamente registrados no Suporte estendido, para fornecer disponibilidade e segurança contínuas. Embora o Suporte estendido ofereça flexibilidade, recomendamos tratar o fim do suporte padrão como um marco de planejamento para suas workloads de produção. Recomendamos fortemente que você atualize seus caches do Redis OSS v4 e v5 para o ElastiCache for Valkey ou o Redis OSS v6 ou posterior, antes do fim do suporte padrão.
A tabela a seguir resume a data de fim do suporte padrão e as datas de Suporte estendido do Amazon ElastiCache.
**Suporte estendido e cronograma de fim de vida**
| Versão principal do mecanismo | Fim do suporte padrão | Início do Suporte estendido premium do ano 1 | Início do Suporte estendido premium do ano 2 | Início do Suporte estendido premium do ano 3 | Fim do Suporte estendido e versão EOL |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 31/1/2026 | 1/2/2026 | 1/2/2027 | 1/2/2028 | 1/31/2029 |
| Redis OSS v5 | 31/1/2026 | 1/2/2026 | 1/2/2027 | 1/2/2028 | 1/31/2029 |
| Redis OSS v6 | 1/31/2027 | 1/2/2027 | 1/2/2028 | 1/2/2029 | 1/31/2030 |
O Suporte estendido só será oferecido para a versão de patch mais recente compatível com cada versão principal do Redis OSS. Quando o Suporte estendido começar em 1º de fevereiro de 2026, se seus clusters do Redis OSS v4 e v5 ainda não estiverem nas versões de patch mais recentes, eles serão automaticamente atualizados para v4.0.10 para Redis OSS v4 e v5.0.6 para Redis OSS v5, antes de serem inscritos no Suporte estendido. Isso garante que você receba atualizações de segurança e correções de bugs por meio do Suporte estendido. Você não precisa realizar nenhuma ação para atualizar para essas versões de patch mais recentes como parte da transição do Suporte estendido.
# ElastiCache e responsabilidades do cliente com o Suporte estendido do ElastiCache
A seguir estão as responsabilidades do Amazon ElastiCache e suas responsabilidades com o Suporte estendido do ElastiCache.
**Responsabilidades do Amazon ElastiCache**
Após a data de término do suporte padrão do ElastiCache, o Amazon ElastiCache fornecerá patches, correções de erros e atualizações para mecanismos inscritos no Suporte estendido do ElastiCache. Isso ocorrerá por até três anos ou até que você pare de usar os mecanismos no Suporte estendido, o que ocorrer primeiro.
**Suas responsabilidades**
Você é responsável por aplicar os patches, correções de erros e atualizações fornecidos para caches no Suporte estendido do ElastiCache. O Amazon ElastiCache reserva-se o direito de alterar, substituir ou retirar esses patches, correções de erros e atualizações a qualquer momento. Caso seja necessário um patch para resolver problemas críticos de segurança ou estabilidade, o Amazon ElastiCache reserva-se o direito de atualizar seus caches com o patch ou exigir que você instale o patch.
Você também é responsável por atualizar o mecanismo para uma versão mais nova antes da data de término do Suporte estendido do ElastiCache. A data de término do Suporte estendido do ElastiCache normalmente é três anos após a data de término do suporte padrão do ElastiCache.
Se você não atualizar o mecanismo, após o fim do Suporte estendido do ElastiCache, o Amazon ElastiCache tentará atualizá-lo para a versão mais recente aceita pelo suporte padrão do ElastiCache. Se a atualização falhar, o Amazon ElastiCache se reserva o direito de excluir o cache que está executando o mecanismo após a data de término do suporte padrão do ElastiCache. No entanto, antes de fazer isso, o Amazon ElastiCache preservará os dados desse mecanismo.
# Gerenciamento de versões para ElastiCache
Gerencie como você gostaria de atualizar seus ElastiCache caches e clusters baseados em nós atualizados para os mecanismos OSS Valkey, Memcached e Redis.
## Gerenciamento de versões para ElastiCache cache sem servidor
Gerencie se e quando o cache ElastiCache sem servidor é atualizado e realize atualizações de versão de acordo com seus próprios termos e cronogramas.
ElastiCache O Serverless aplica automaticamente a versão mais recente do software secundário e de patch ao seu cache, sem nenhum impacto ou tempo de inatividade em seu aplicativo. Não é necessária nenhuma ação de sua parte.
Quando uma nova versão principal estiver disponível, o ElastiCache Serverless enviará uma notificação no console e um evento no. EventBridge Você pode optar por atualizar o cache para a versão principal mais recente modificando o cache usando o console, a CLI ou a API e selecionando a versão mais recente do mecanismo. Semelhante às atualizações secundárias e de patch, as atualizações da versão principal são realizadas sem tempo de inatividade do seu aplicativo.
## Gerenciamento de versões para clusters baseados em nós ElastiCache
Ao trabalhar com ElastiCache clusters baseados em nós, você pode controlar quando o software que alimenta seu cluster é atualizado para novas versões suportadas pelo. ElastiCache É possível controlar quando atualizar o cache para as versões MAJOR, MINOR e PATCH mais recentes disponíveis. Você inicia atualizações de versão do mecanismo no seu cluster ou grupo de replicação, modificando-o e especificando uma nova versão do mecanismo.
Você pode controlar se e quando o software compatível com o protocolo que alimenta seu cluster é atualizado para novas versões suportadas pelo. ElastiCache Esse nível de controle permite que você mantenha a compatibilidade com versões específicas, teste novas versões com seu aplicativo antes de implantar em produção e realize atualizações de versão em seus próprios termos e cronogramas.
Como as atualizações de versões podem envolver algum risco de compatibilidade, elas não ocorrem automaticamente. Você deve iniciá-las.
**Clusters Valkey e Redis OSS**
**nota**
Se um cluster Valkey ou Redis OSS for replicado em uma ou mais regiões, a versão do mecanismo será atualizada para regiões secundárias e depois para a região primária.
ElastiCache para Redis, as versões OSS são identificadas com uma versão semântica que compreende um componente maior e um menor. Por exemplo, no Redis OSS 6.2, a versão principal é a 6, a versão secundária é a 2. Ao operar clusters baseados em nós, ElastiCache para Redis OSS também expõe o componente de patch, por exemplo, Redis OSS 6.2.1, e a versão do patch é 1.
As versões principais são para alterações incompatíveis da API e as versões secundárias são para novas funcionalidades adicionadas de forma compatível com as versões anteriores. As versões do patch são para correções de bugs compatíveis com versões anteriores e mudanças não funcionais.
Com o Valkey e Redis OSS, você inicia atualizações de versão do mecanismo no seu cluster ou grupo de replicação, modificando-o e especificando uma nova versão do mecanismo. Para obter mais informações, consulte [Modificação de um grupo de replicação](Replication.Modify.md).
**Memcached**
Com o Memcached, para atualizar para uma versão mais recente, você deve modificar seu cluster e especificar a nova versão do mecanismo que deseja usar. Atualizar para uma versão do Memcached mais recente é um processo destrutivo. Você perde seus dados e começa com um cache frio. Para obter mais informações, consulte [Modificação de um cluster do ElastiCache](Clusters.Modify.md).
Você deve estar ciente dos seguintes requisitos ao atualizar de uma versão mais antiga do Memcached para o Memcached versão 1.4.33 ou posterior. `CreateCacheCluster` e `ModifyCacheCluster` falham nas seguintes condições:
+ 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)`.
O valor `(max_cache_memory - memcached_connections_overhead)` é a memória do nó utilizável para dados. Para obter mais informações, consulte [Sobrecarga de conexões do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached.Overhead).
## Mecanismos e versões compatíveis
ElastiCache caches sem servidor oferecem suporte à ElastiCache versão 7.2 para Valkey e superior, ElastiCache versão 1.6 para Memcached e superior e 7.0 para Redis OSS e ElastiCache superior.
ElastiCache Os clusters baseados em nós oferecem suporte à ElastiCache versão 7.2 para Valkey e superior, ElastiCache versão 1.4.5 para Memcached e superior e 4.0.10 para Redis OSS e ElastiCache superior.
**Topics**
+ [Versões compatíveis do Valkey](#supported-engine-versions.valkey)
+ [Vale 8.2](#valkey-version-8.2)
+ [Vale 8.1](#valkey-version-8.1)
+ [Vale 8.0](#valkey-version-8)
+ [ElastiCache versão 7.2.6 para Valkey](#valkey-version-7.2.6)
### Versões compatíveis do Valkey
Versões compatíveis do Valkey abaixo. Observe que o Valkey oferece suporte à maioria dos recursos disponíveis na ElastiCache versão 7.2 para Redis OSS por padrão.
+ Você também pode atualizar seus ElastiCache clusters com versões anteriores à 5.0.6. O processo envolvido é o mesmo, mas pode incorrer em tempo de failover mais longo durante a propagação do DNS (30 s a 1 m).
+ A partir do Redis OSS 7, ElastiCache oferece suporte à alternância entre Valkey ou Redis OSS (modo de cluster desativado) e Valkey ou Redis OSS (modo de cluster ativado).
+ O processo de atualização do mecanismo Amazon ElastiCache for Redis OSS foi projetado para fazer o melhor esforço para reter seus dados existentes e requer uma replicação bem-sucedida do Redis OSS.
+ Ao atualizar o mecanismo, ElastiCache encerrará as conexões existentes do cliente. Para minimizar o tempo de inatividade durante as atualizações do mecanismo, recomendamos implementar [as práticas recomendadas para clientes do Redis OSS](BestPractices.Clients.redis.md) com novas tentativas de erro e recuo exponencial e as práticas recomendadas para [minimizar o tempo de inatividade durante a manutenção](BestPractices.MinimizeDowntime.md).
+ Não é possível atualizar diretamente do Valkey ou Redis OSS (modo cluster desabilitado) para o Valkey ou Redis OSS (modo cluster habilitado) ao atualizar seu mecanismo. O procedimento a seguir mostra como atualizar do Valkey ou Redis OSS (modo cluster desabilitado) para o Valkey ou Redis OSS (modo cluster habilitado).
**Para atualizar de uma versão de mecanismo Valkey ou Redis OSS (modo cluster desabilitado) para Valkey ou Redis OSS (modo cluster habilitado)**
1. Faça um backup do seu cluster do Valkey ou Redis OSS (modo cluster desabilitado) ou do grupo de replicação. Para obter mais informações, consulte [Realização de backups manuais](backups-manual.md).
1. Use o backup para criar e propagar um cluster do Valkey ou Redis OSS (modo cluster habilitado) com um fragmento (grupo de nós). Especifique a nova versão do mecanismo e habilite o modo de cluster ao criar o cluster ou o grupo de replicação. Para obter mais informações, consulte [Tutorial: propagação de um novo cluster baseado em nós com um backup criado externamente](backups-seeding-redis.md).
1. Exclua o antigo cluster do Valkey ou Redis OSS (modo cluster desabilitado) ou o grupo de replicação. Para acessar mais informações, consulte [Excluindo um cluster no ElastiCache](Clusters.Delete.md) ou [Exclusão de um grupo de replicação](Replication.DeletingRepGroup.md).
1. Escale o novo cluster ou grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) para o número de fragmentos (grupos de nós) que você precisa. Para obter mais informações, consulte [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md).
+ Ao atualizar as principais versões do mecanismo, por exemplo, de 5.0.6 para 6.0, também é necessário selecionar um novo grupo de parâmetros que seja compatível com a nova versão do mecanismo.
+ Para clusters Redis OSS de nó único e clusters Redis individuais com o Multi-AZ desabilitado, recomendamos que seja disponibilizada memória suficiente para o Redis OSS, conforme descrito em [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md). Nesses casos, o primário não está disponível para solicitações de serviço durante o processo de atualização.
+ Para clusters Redis OSS com o Multi-AZ habilitado, também recomendamos que você programe atualizações do mecanismo durante períodos de baixo tráfego de gravações recebidas. Ao atualizar para o Redis OSS 5.0.6 ou posterior, o cluster primário continua disponível para solicitações de serviço durante o processo de atualização.
Os clusters e os grupos de replicação com vários fragmentos são processados e corrigidos da seguinte forma:
+ Todos os estilhaços são processados em paralelo. Somente uma operação de atualização é realizada em um estilhaço por vez.
+ Em cada fragmento, todas as réplicas são processadas antes do processamento da primária. Caso haja menos réplicas em um fragmento, a primária nesse fragmento pode ser processada antes da conclusão do processamento das réplicas em outros fragmentos.
+ Em todos os fragmentos, os nós primários são processados em série. Somente um nó primário é atualizado por vez.
+ Caso a criptografia esteja habilitada no cluster ou no grupo de replicação atual, não será possível atualizar para uma versão de mecanismo que não ofereça suporte à criptografia, como de 3.2.6 a 3.2.10.
**Considerações sobre o Memcached**
Ao atualizar um cluster Memcached baseado em nós, considere o seguinte.
+ O gerenciamento da versão do mecanismo foi desenvolvido para que você possa ter o máximo controle possível sobre a execução de patches. No entanto, ElastiCache se reserva o direito de corrigir seu cluster em seu nome no caso improvável de uma vulnerabilidade crítica de segurança no sistema ou no software de cache.
+ Como o mecanismo Memcached não oferece suporte para persistência, as atualizações de versão do mecanismo Memcached são sempre um processo disruptivo que limpa todos os dados do cache no cluster.
### ElastiCache versão 8.2 para Valkey
Aqui estão alguns dos novos recursos introduzidos no Valkey 8.2 (em comparação com o ElastiCache Valkey 8.1):
+ Compatibilidade nativa para [pesquisa vetorial](vector-search.md), permitindo o armazenamento, a indexação, pesquisa e atualização de bilhões de incorporações vetoriais de alta dimensão na memória com latências de até microssegundos.
Para ter mais informações sobre o Valkey, consulte [Valkey](https://valkey.io/).
Para saber mais sobre a versão 8.2 do Valkey, introduzindo a pesquisa vetorial, consulte [Valkey Search](https://github.com/valkey-io/valkey-search).
### ElastiCache versão 8.1 para Valkey
Aqui estão alguns dos novos recursos introduzidos no Valkey 8.1 (em comparação com o ElastiCache Valkey 8.0):
+ Uma [nova implementação de tabela de hash](https://valkey.io/blog/new-hash-table/) que reduz a sobrecarga de memória para reduzir o uso de memória em até 20% para padrões comuns key/value .
+ Compatibilidade nativa para [filtros Bloom](https://valkey.io/topics/bloomfilters/), um novo tipo de dados que permite realizar pesquisas usando até 98% menos memória em comparação com o uso do tipo de dados Set.
+ Novo comando [COMMANDLOG](https://valkey.io/commands/commandlog-get/) que registra execuções lentas, solicitações grandes e respostas grandes.
+ Novo suporte de atualização condicional para o comando SET usando o argumento IFEQ.
+ Melhorias de desempenho, incluindo latência até 45% menor para o comando ZRANK, desempenho até 12x mais rápido para PFMERGE e PFCOUNT e throughput até 514% maior para BITCOUNT.
Para ter mais informações sobre o Valkey, consulte [Valkey](https://valkey.io/).
Para saber mais sobre a versão 8.1 do Valkey, consulte [Notas de versão do Valkey 8.1](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES)
### ElastiCache versão 8.0 para Valkey
Aqui estão alguns dos novos recursos introduzidos no Valkey 8.0 (em comparação com o ElastiCache Valkey 7.2.6):
+ Melhorias na eficiência da memória, permitindo que os usuários armazenem até 20% mais dados por nó sem nenhuma alteração no aplicativo.
+ Infraestrutura de métricas por slot recém-introduzida para clusters baseados em nós, fornecendo visibilidade detalhada do desempenho e do uso de recursos de slots individuais.
+ ElastiCache O Serverless for Valkey 8.0 pode dobrar as solicitações suportadas por segundo (RPS) a cada 2-3 minutos, atingindo 5 milhões de RPS por cache de zero em menos de 13 minutos, com latência de leitura p50 consistente abaixo de um milissegundo.
Para ter mais informações sobre o Valkey, consulte [Valkey](https://valkey.io/).
Para obter mais informações sobre a versão 8 do Valkey, consulte [Notas de versão do Valkey 8](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES)
### ElastiCache versão 7.2.6 para Valkey
Em 10 de outubro de 2024, a ElastiCache versão 7.2.6 do Valkey foi lançada. Aqui estão alguns dos novos recursos introduzidos na versão 7.2 (em comparação com a ElastiCache versão 7.1 do Redis OSS):
+ Otimizações de desempenho e memória para vários tipos de dados: otimização de memória para chaves de tipo de lista e conjunto, otimização de velocidade para comandos de conjuntos ordenados, otimização de desempenho para comandos com várias teclas no modo de cluster, melhorias de pub/sub desempenho, otimização de desempenho para comandos SCAN, SSCAN, HSCAN, ZSCAN e várias outras otimizações menores.
+ Nova opção WITHSCORE para os comandos ZRANK e ZREVRANK
+ CLIENT NO-TOUCH para que os clientes executem comandos sem afetar LRU/LFU as teclas.
+ Novo comando CLUSTER MYSHARDID que retorna o ID do fragmento do nó para agrupar logicamente os nós no modo de cluster com base na replicação.
Para ter mais informações sobre o Valkey, consulte [Valkey](https://valkey.io/).
Para obter mais informações sobre a ElastiCache versão 7.2 para a versão Valkey, consulte as [notas de lançamento do Redis OSS 7.2.4](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (a versão 7.2 para Valkey inclui todas as alterações da ElastiCache versão 7.1 para Redis OSS até a ElastiCache versão 7.2.4 para Redis OSS). ElastiCache [Notas de lançamento do Valkey 7.2](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) no Valkey on. GitHub
## ElastiCache versão 8.2 para Valkey
Aqui estão alguns dos novos recursos introduzidos no Valkey 8.2 (em comparação com o ElastiCache Valkey 8.1):
+ Compatibilidade nativa para [pesquisa vetorial](vector-search.md), permitindo o armazenamento, a indexação, pesquisa e atualização de bilhões de incorporações vetoriais de alta dimensão na memória com latências de até microssegundos.
Para ter mais informações sobre o Valkey, consulte [Valkey](https://valkey.io/).
Para saber mais sobre a versão 8.2 do Valkey, introduzindo a pesquisa vetorial, consulte [Valkey Search](https://github.com/valkey-io/valkey-search).
## ElastiCache versão 8.1 para Valkey
Aqui estão alguns dos novos recursos introduzidos no Valkey 8.1 (em comparação com o ElastiCache Valkey 8.0):
+ Uma [nova implementação de tabela de hash](https://valkey.io/blog/new-hash-table/) que reduz a sobrecarga de memória para reduzir o uso de memória em até 20% para padrões comuns key/value .
+ Compatibilidade nativa para [filtros Bloom](https://valkey.io/topics/bloomfilters/), um novo tipo de dados que permite realizar pesquisas usando até 98% menos memória em comparação com o uso do tipo de dados Set.
+ Novo comando [COMMANDLOG](https://valkey.io/commands/commandlog-get/) que registra execuções lentas, solicitações grandes e respostas grandes.
+ Novo suporte de atualização condicional para o comando SET usando o argumento IFEQ.
+ Melhorias de desempenho, incluindo latência até 45% menor para o comando ZRANK, desempenho até 12x mais rápido para PFMERGE e PFCOUNT e throughput até 514% maior para BITCOUNT.
Para ter mais informações sobre o Valkey, consulte [Valkey](https://valkey.io/).
Para saber mais sobre a versão 8.1 do Valkey, consulte [Notas de versão do Valkey 8.1](https://github.com/valkey-io/valkey/blob/8.1/00-RELEASENOTES)
## ElastiCache versão 8.0 para Valkey
Aqui estão alguns dos novos recursos introduzidos no Valkey 8.0 (em comparação com o ElastiCache Valkey 7.2.6):
+ Melhorias na eficiência da memória, permitindo que os usuários armazenem até 20% mais dados por nó sem nenhuma alteração no aplicativo.
+ Infraestrutura de métricas por slot recém-introduzida para clusters baseados em nós, fornecendo visibilidade detalhada do desempenho e do uso de recursos de slots individuais.
+ ElastiCache O Serverless for Valkey 8.0 pode dobrar as solicitações suportadas por segundo (RPS) a cada 2-3 minutos, atingindo 5 milhões de RPS por cache de zero em menos de 13 minutos, com latência de leitura p50 consistente abaixo de um milissegundo.
Para ter mais informações sobre o Valkey, consulte [Valkey](https://valkey.io/).
Para obter mais informações sobre a versão 8 do Valkey, consulte [Notas de versão do Valkey 8](https://github.com/valkey-io/valkey/blob/8.0/00-RELEASENOTES)
## ElastiCache versão 7.2.6 para Valkey
Em 10 de outubro de 2024, a ElastiCache versão 7.2.6 do Valkey foi lançada. Aqui estão alguns dos novos recursos introduzidos na versão 7.2 (em comparação com a ElastiCache versão 7.1 do Redis OSS):
+ Otimizações de desempenho e memória para vários tipos de dados: otimização de memória para chaves de tipo de lista e conjunto, otimização de velocidade para comandos de conjuntos ordenados, otimização de desempenho para comandos com várias teclas no modo de cluster, melhorias de pub/sub desempenho, otimização de desempenho para comandos SCAN, SSCAN, HSCAN, ZSCAN e várias outras otimizações menores.
+ Nova opção WITHSCORE para os comandos ZRANK e ZREVRANK
+ CLIENT NO-TOUCH para que os clientes executem comandos sem afetar LRU/LFU as teclas.
+ Novo comando CLUSTER MYSHARDID que retorna o ID do fragmento do nó para agrupar logicamente os nós no modo de cluster com base na replicação.
Para ter mais informações sobre o Valkey, consulte [Valkey](https://valkey.io/).
Para obter mais informações sobre a ElastiCache versão 7.2 para a versão Valkey, consulte as [notas de lançamento do Redis OSS 7.2.4](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (a versão 7.2 para Valkey inclui todas as alterações da ElastiCache versão 7.1 para Redis OSS até a ElastiCache versão 7.2.4 para Redis OSS). ElastiCache [Notas de lançamento do Valkey 7.2](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) no Valkey on. GitHub
## Versões compatíveis do mecanismo do Redis OSS
ElastiCache Caches sem servidor e clusters baseados em nós oferecem suporte a todas as versões 7.1 e anteriores do Redis OSS.
+ [ElastiCache versão 7.1 para Redis OSS (aprimorada)](#redis-version-7.1)
**Topics**
+ [ElastiCache versão 7.1 para Redis OSS (aprimorada)](#redis-version-7.1)
+ [ElastiCache versão 7.0 para Redis OSS (aprimorada)](#redis-version-7.0)
+ [ElastiCache versão 6.2 para Redis OSS (aprimorada)](#redis-version-6.2)
+ [ElastiCache versão 6.0 para Redis OSS (aprimorada)](#redis-version-6.0)
+ [ElastiCache versão 5.0.6 para Redis OSS (aprimorada)](#redis-version-5-0.6)
+ [ElastiCache versão 5.0.5 para Redis OSS (obsoleta, use a versão 5.0.6)](#redis-version-5-0.5)
+ [ElastiCache versão 5.0.4 para Redis OSS (obsoleta, use a versão 5.0.6)](#redis-version-5-0.4)
+ [ElastiCache versão 5.0.3 para Redis OSS (obsoleta, use a versão 5.0.6)](#redis-version-5-0.3)
+ [ElastiCache versão 5.0.0 para Redis OSS (obsoleta, use a versão 5.0.6)](#redis-version-5-0)
+ [ElastiCache versão 4.0.10 para Redis OSS (aprimorada)](#redis-version-4-0-10)
+ [Versões que ultrapassaram o fim de vida útil (EOL) (3.x)](#redis-version-3-2-10-scheduled-eol)
+ [Versões que ultrapassaram o fim de vida útil (EOL) (2.x)](#redis-version-2-x-eol)
### ElastiCache versão 7.1 para Redis OSS (aprimorada)
Esta versão contém melhorias de desempenho que permitem que as cargas de trabalho aumentem a produtividade e reduzam as latências de operação. ElastiCache [a versão 7.1 para Redis OSS apresenta dois aprimoramentos principais:](https://aws.amazon.com/blogs/database/achieve-over-500-million-requests-per-second-per-cluster-with-amazon-elasticache-for-redis-7-1/)
Estendemos a funcionalidade aprimorada de I/O threads para também lidar com a lógica da camada de apresentação. Por camada de apresentação, queremos dizer que os threads de E/S aprimorados agora não estão apenas lendo a entrada do cliente, mas também analisando a entrada no formato de comando binário do Redis OSS. Em seguida, isso é encaminhado para o thread principal para execução, o que proporciona um ganho de desempenho. Padrão de acesso à memória do Redis OSS aprimorado. As etapas de execução de muitas operações da estrutura de dados são intercaladas, para garantir acesso paralelo à memória e reduzir a latência do acesso à memória. Ao executar ElastiCache em Graviton3 `R7g.4xlarge` ou maior, os clientes podem atingir mais de 1 milhão de solicitações por segundo por nó. Com as melhorias de desempenho do Redis OSS v7.1, os clientes podem obter até 100% mais taxa de transferência e 50% menos latência P99 em relação ao Redis OSS v7.0. ElastiCache ElastiCache Esses aprimoramentos são habilitados em tamanhos de nós com pelo menos oito núcleos físicos (`2xlarge` no Graviton e `4xlarge` no x86), independentemente do tipo de CPU, e não exigem alterações no cliente.
**nota**
ElastiCache A v7.1 é compatível com o Redis OSS v7.0.
### ElastiCache versão 7.0 para Redis OSS (aprimorada)
ElastiCache para Redis, o OSS 7.0 adiciona uma série de melhorias e suporte para novas funcionalidades:
+ [Funções](https://valkey.io/topics/functions-intro/): ElastiCache para Redis, o OSS 7 adiciona suporte às funções do Redis OSS e fornece uma experiência gerenciada que permite que os desenvolvedores executem [scripts LUA](https://valkey.io/topics/eval-intro/) com a lógica do aplicativo armazenada no ElastiCache cluster, sem exigir que os clientes reenviem os scripts para o servidor a cada conexão.
+ [Melhorias na ACL](https://valkey.io/topics/acl/): o Valkey e o Redis OSS 7 adicionam suporte para a próxima versão das listas de controle de acesso (). ACLs Os clientes agora podem especificar vários conjuntos de permissões em chaves ou espaços de chave específicos no Valkey e Redis OSS.
+ [Sharded Pub/Sub](https://valkey.io/topics/pubsub/): ElastiCache para Valkey e Redis, o OSS 7 adiciona suporte para executar Pub/Sub functionality in a sharded way when running ElastiCache in Cluster Mode Enabled (CME). Pub/Sub recursos que permitem que os editores enviem mensagens para qualquer número de inscritos em um canal. Os canais são vinculados a um fragmento no ElastiCache cluster, eliminando a necessidade de propagar as informações do canal entre os fragmentos, resultando em maior escalabilidade.
+ I/O Multiplexação aprimorada: ElastiCache para Valkey e Redis, o OSS 7 introduz a multiplexação de E/S aprimorada, que oferece maior taxa de transferência e latência reduzida para cargas de trabalho de alto rendimento que têm muitas conexões simultâneas de clientes com um cluster. ElastiCache Por exemplo, ao usar um cluster de nós r6g.xlarge e executar 5200 clientes simultâneos, você pode obter um aumento de até 72% na taxa de transferência (operações de leitura e gravação por segundo) e uma redução de até 71% na latência P99, em comparação com a versão 6 do Redis OSS. ElastiCache
Para ter mais informações sobre o Valkey, consulte [Valkey](https://valkey.io/). Para obter mais informações sobre a versão 7.0 do Redis OSS, consulte as notas de lançamento do [Redis OSS 7.0 em Redis OSS](https://github.com/redis/redis/blob/7.0/00-RELEASENOTES) on. GitHub
### ElastiCache versão 6.2 para Redis OSS (aprimorada)
ElastiCache para Redis, o OSS 6.2 inclui melhorias de desempenho para clusters habilitados para TLS usando tipos de nós x86 com 8 v CPUs ou mais ou tipos de nós Graviton2 com 4 v ou mais. CPUs Esses aprimoramentos melhoram a taxa de transferência e reduzem o tempo de estabelecimento da conexão do cliente, transferindo a criptografia para outros v. CPUs Com o Redis OSS 6.2, você também pode gerenciar o acesso aos canais do Pub/Sub com as regras da Lista de Controle de Acesso (ACL).
Com essa versão, também introduzimos suporte para armazenamento de dados em camadas em nós de cluster contendo NVMe SSD conectado localmente. Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
A versão 6.2.6 do mecanismo Redis OSS também introduz suporte ao formato nativo de notação de JavaScript objeto (JSON), uma maneira simples e sem esquemas de codificar conjuntos de dados complexos dentro dos clusters do Redis OSS. Com o suporte a JSON, você pode aproveitar o desempenho e o Redis OSS APIs para aplicativos que operam em JSON. Para obter mais informações, consulte [Conceitos básicos do JSON](json-gs.md). Também estão incluídas métricas relacionadas ao JSON `JsonBasedCmds` e`JsonBasedCmdsLatency`, que são incorporadas CloudWatch para monitorar o uso desse tipo de dados. Para obter mais informações, consulte [Métricas para o Valkey e Redis OSS](CacheMetrics.Redis.md).
Você especifica a versão do mecanismo usando 6.2. ElastiCache invocará automaticamente a versão de patch preferida do Redis OSS 6.2 que está disponível. Por exemplo, ao criar/modificar um cluster, você define o parâmetro `--engine-version` como 6.2. O cluster será lançado com a versão atual de patch preferencial disponível do Redis OSS 6.2 no momento. creation/modification Especificar a versão 6.x do mecanismo na API resultará na versão secundária mais recente do Redis OSS 6.
Para clusters 6.0 existentes, você pode optar pela próxima atualização automática da versão secundária definindo o `AutoMinorVersionUpgrade` parâmetro como `yes` em `CreateCacheCluster``ModifyCacheCluster`, `CreateReplicationGroup` ou. `ModifyReplicationGroup` APIs ElastiCache atualizará a versão secundária de seus clusters 6.0 existentes para 6.2 usando atualizações de autoatendimento. Para obter mais informações, consulte [Atualizações de autoatendimento na Amazon ElastiCache](Self-Service-Updates.md).
Ao chamar a DescribeCacheEngineVersions API, o valor do `EngineVersion` parâmetro será definido como 6.2 e a versão real do mecanismo com a versão do patch será retornada no `CacheEngineVersionDescription` campo.
Para obter mais informações sobre a versão 6.2 do Redis OSS, consulte as notas de lançamento do [Redis OSS 6.2 em Redis OSS](https://github.com/redis/redis/blob/6.2/00-RELEASENOTES) on. GitHub
### ElastiCache versão 6.0 para Redis OSS (aprimorada)
A Amazon ElastiCache apresenta a próxima versão do ElastiCache mecanismo Redis OSS, que inclui [autenticação de usuários com controle de acesso baseado em funções](Clusters.RBAC.md), armazenamento em cache do lado do cliente e melhorias operacionais significativas.
A partir do Redis OSS 6.0, ElastiCache oferecerá uma única versão para cada versão secundária do Redis OSS, em vez de oferecer várias versões de patch. ElastiCache gerenciará automaticamente a versão de patch de seus clusters em execução, garantindo melhor desempenho e segurança aprimorada.
Você também pode optar pela próxima atualização automática da versão secundária definindo o `AutoMinorVersionUpgrade` parâmetro como `yes` e ElastiCache gerenciará a atualização da versão secundária, por meio de atualizações de autoatendimento. Para obter mais informações, consulte [Atualizações de serviço em ElastiCache](Self-Service-Updates.md).
Você especifica a versão do mecanismo usando`6.0`. ElastiCache invocará automaticamente a versão de patch preferida do Redis OSS 6.0 que está disponível. Por exemplo, quando você é create/modify um cluster, você define o `--engine-version` parâmetro como 6.0. O cluster será iniciado com a versão de patch preferencial atual disponível do Redis OSS 6.0 no momento da criação/modificação. Qualquer solicitação com um valor específico de versão de patch será rejeitada, uma exceção será lançada e o processo falhará.
Ao chamar a DescribeCacheEngineVersions API, o valor do `EngineVersion` parâmetro será definido como 6.0 e a versão real do mecanismo com a versão do patch será retornada no `CacheEngineVersionDescription` campo.
Para obter mais informações sobre a versão 6.0 do Redis OSS, consulte as notas de lançamento do [Redis OSS 6.0 em Redis OSS](https://github.com/redis/redis/blob/6.0/00-RELEASENOTES) on. GitHub
### ElastiCache versão 5.0.6 para Redis OSS (aprimorada)
A Amazon ElastiCache apresenta a próxima versão do ElastiCache mecanismo Redis OSS, que inclui correções de bugs e as seguintes atualizações cumulativas:
+ Garantia de estabilidade do mecanismo em condições especiais.
+ Tratamento aprimorado de erros do Hyperloglog.
+ Comandos de handshake aprimorados para a replicação confiável.
+ Rastreamento de entrega de mensagens consistente pelo comando `XCLAIM`.
+ Gerenciamento do campo `LFU ` aprimorado nos objetos.
+ Gerenciamento de transações aprimorado ao usar `ZPOP`.
+ Capacidade de renomear comandos: um parâmetro denominado `rename-commands` que permite renomear comandos do Redis OSS possivelmente perigosos e caros que podem causar a perda acidental de dados, como `FLUSHALL` ou `FLUSHDB`. Isso é semelhante à configuração rename-command no Redis OSS de software livre. No entanto, ElastiCache melhorou a experiência ao fornecer um fluxo de trabalho totalmente gerenciado. As alterações de nomes de comando são aplicadas imediatamente e propagadas automaticamente em todos os nós no cluster que contêm a lista de comandos. Não há nenhuma intervenção necessária de sua parte, como a reinicialização de nós.
Os exemplos a seguir demonstram como modificar os grupos de parâmetros existentes. Eles incluem o parâmetro `rename-commands`, que é uma lista separada por espaços de comandos que você deseja renomear:
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall'" --region region
```
Neste exemplo, o parâmetro *rename-commands* é usado para renomear o comando `flushall` como `restrictedflushall`.
Para renomear vários comandos, use o seguinte:
```
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
```
Para reverter qualquer alteração, execute novamente o comando e exclua qualquer valor renomeado na lista `ParameterValue` que você deseja manter, conforme mostrado a seguir:
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall restrictedflushall'" --region region
```
Nesse caso, o comando `flushall` é renomeado para `restrictedflushall` e qualquer outro comando renomeado revertido para seus nomes de comando originais.
**nota**
Ao renomear comandos, você está restrito às seguintes limitações:
Todos os comandos renomeados devem ser alfanuméricos.
O tamanho máximo de novos nomes de comando é de 20 caracteres alfanuméricos.
Ao renomear comandos, certifique-se de que você atualize o grupo de parâmetros associado ao seu cluster.
Para evitar totalmente o uso de um comando, use a palavra-chave `blocked`, conforme mostrado a seguir:
```
aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
--parameter-name-values "ParameterName=rename-commands, ParameterValue='flushall blocked'" --region region
```
Para obter mais informações sobre as alterações de parâmetro e uma lista de comandos que são qualificados para serem renomeados, consulte [Alterações de parâmetros do Redis OSS 5.0.3](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3).
+ Redis OSS Streams: essa opção modela uma estrutura de dados de log que permite que os produtores anexem novos itens em tempo real. Também permite que os consumidores leiam mensagens com ou sem bloqueio. Os fluxos também permitem grupos de consumidores, que representam um grupo de clientes para cooperativamente consumir diferentes partes do mesmo fluxo de mensagens, semelhante ao [Apache Kafka](https://kafka.apache.org/documentation/). Para obter mais informações, consulte [Fluxos](https://valkey.io/topics/streams-intro).
+ Oferece suporte para uma família de comandos de fluxo, como os `XADD`, `XRANGE` e `XREAD`. Para obter mais informações, consulte [Comandos dos fluxos](https://valkey.io/commands/#stream).
+ Diversos parâmetros novos e renomeados. Para obter mais informações, consulte [Alterações de parâmetros do Redis OSS 5.0.0](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0).
+ Uma nova métrica do Redis OSS, `StreamBasedCmds`.
+ Tempo de snapshot um pouco mais rápido para nós Redis OSS.
**Importante**
ElastiCache retrocedeu duas correções de bugs críticos da versão 5.0.1 de [código aberto do Redis OSS.](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) Eles estão listados a seguir:
RESTAURAR resposta incompatível quando determinadas chaves já expiraram.
O comando `XCLAIM` pode retornar uma entrada errada ou dessincronizar o protocolo.
Ambas as correções de bugs estão incluídas no suporte do Redis OSS ElastiCache para a versão 5.0.0 do mecanismo Redis OSS e são consumidas em futuras atualizações da versão.
Para obter mais informações, consulte as [notas de lançamento do Redis OSS 5.0.6](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) em Redis OSS on. GitHub
### ElastiCache versão 5.0.5 para Redis OSS (obsoleta, use a versão 5.0.6)
A Amazon ElastiCache apresenta a próxima versão do motor ElastiCache Redis OSS;. Ele inclui alterações de configuração on-line para clusters ElastiCache de failover automático durante todas as operações planejadas. Agora é possível escalonar seu cluster, atualizar a versão do mecanismo Redis OSS e aplicar patches e atualizações de manutenção enquanto o cluster permanece online e continua atendendo às solicitações recebidas. Ela também inclui correções de erros.
Para obter mais informações, consulte as [notas de lançamento do Redis OSS 5.0.5](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) em Redis OSS on. GitHub
### ElastiCache versão 5.0.4 para Redis OSS (obsoleta, use a versão 5.0.6)
A Amazon ElastiCache apresenta a próxima versão do mecanismo Redis OSS compatível com. ElastiCache Ele inclui as melhorias a seguir:
+ Garantia de estabilidade do mecanismo em condições especiais.
+ Tratamento aprimorado de erros do Hyperloglog.
+ Comandos de handshake aprimorados para a replicação confiável.
+ Rastreamento de entrega de mensagens consistente pelo comando `XCLAIM`.
+ Gerenciamento do campo `LFU ` aprimorado nos objetos.
+ Gerenciamento de transações aprimorado ao usar `ZPOP`.
Para obter mais informações, consulte as [notas de lançamento do Redis OSS 5.0.4](https://github.com/redis/redis/blob/5.0/00-RELEASENOTES) em Redis OSS on. GitHub
### ElastiCache versão 5.0.3 para Redis OSS (obsoleta, use a versão 5.0.6)
A Amazon ElastiCache apresenta a próxima versão do ElastiCache mecanismo Redis OSS, que inclui correções de bugs.
### ElastiCache versão 5.0.0 para Redis OSS (obsoleta, use a versão 5.0.6)
A Amazon ElastiCache apresenta a próxima versão principal do mecanismo ElastiCache Redis OSS. ElastiCache A versão 5.0.0 para Redis OSS oferece suporte para as seguintes melhorias:
+ Redis OSS Streams: essa opção modela uma estrutura de dados de log que permite que os produtores anexem novos itens em tempo real. Também permite que os consumidores leiam mensagens com ou sem bloqueio. Os fluxos também permitem grupos de consumidores, que representam um grupo de clientes para cooperativamente consumir diferentes partes do mesmo fluxo de mensagens, semelhante ao [Apache Kafka](https://kafka.apache.org/documentation/). Para obter mais informações, consulte [Fluxos](https://valkey.io/topics/streams-intro).
+ Oferece suporte para uma família de comandos de fluxo, como os `XADD`, `XRANGE` e `XREAD`. Para obter mais informações, consulte [Comandos dos fluxos](https://valkey.io/commands/#stream).
+ Diversos parâmetros novos e renomeados. Para obter mais informações, consulte [Alterações de parâmetros do Redis OSS 5.0.0](ParameterGroups.Engine.md#ParameterGroups.Redis.5.0).
+ Uma nova métrica do Redis OSS, `StreamBasedCmds`.
+ Tempo de snapshot um pouco mais rápido para nós Redis OSS.
### ElastiCache versão 4.0.10 para Redis OSS (aprimorada)
A Amazon ElastiCache apresenta a próxima versão principal do mecanismo ElastiCache Redis OSS. ElastiCache a versão 4.0.10 para Redis OSS traz suporte para as seguintes melhorias:
+ Redimensionamento e criptografia de clusters on-line em uma única ElastiCache versão. Para saber mais, consulte:
+ [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md)
+ [Refragmentação online para o Valkey ou o Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Segurança de dados no Amazon ElastiCache](encryption.md)
+ Diversos novos parâmetros. Para obter mais informações, consulte [Alterações de parâmetros do Redis OSS 4.0.10](ParameterGroups.Engine.md#ParameterGroups.Redis.4-0-10).
+ Suporte para a família de comandos de memória, como `MEMORY`. Para obter mais informações, consulte [Comandos](https://valkey.io/commands) (pesquisar em MEMÓRIA).
+ Suporte para desfragmentação de memória online, permitindo assim a utilização mais eficiente da memória e uma quantidade maior de memória disponível para seus dados.
+ Support para descargas e exclusões assíncronas. ElastiCache para Redis, o OSS suporta comandos como`UNLINK`, `FLUSHDB` e `FLUSHALL` para execução em um encadeamento diferente do encadeamento principal. Fazer isso ajuda a melhorar o desempenho e os tempos de resposta dos aplicativos, liberando a memória de maneira assíncrona.
+ Uma nova métrica do Redis OSS, `ActiveDefragHits`. Para obter mais informações, consulte [Métricas do Redis OSS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CacheMetrics.Redis.html).
Usuários do Redis OSS (modo de cluster desativado) que executam a ElastiCache versão 3.2.10 para Redis OSS podem usar o console para atualizar seus clusters por meio de upgrade online.
**Comparando o suporte ao redimensionamento e criptografia de ElastiCache clusters**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/engine-versions.html)
### Versões que ultrapassaram o fim de vida útil (EOL) (3.x)
#### ElastiCache versão 3.2.10 para Redis OSS (aprimorada)
A Amazon ElastiCache apresenta a próxima versão principal do mecanismo ElastiCache Redis OSS. ElastiCache a versão 3.2.10 para Redis OSS (aprimorada) introduz o redimensionamento on-line do cluster para adicionar ou remover fragmentos do cluster enquanto ele continua atendendo às solicitações recebidas. I/O ElastiCache para Redis OSS 3.2.10, os usuários têm todas as funcionalidades das versões anteriores do Redis OSS, exceto a capacidade de criptografar seus dados. Esse recurso está atualmente disponível apenas na versão 3.2.6.
**Comparando ElastiCache as versões 3.2.6 e 3.2.10 para Redis OSS**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/engine-versions.html)
Para saber mais, consulte:
+ [Refragmentação online para o Valkey ou o Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Redimensionamento de cluster on-line](best-practices-online-resharding.md)
#### ElastiCache versão 3.2.6 para Redis OSS (aprimorada)
A Amazon ElastiCache apresenta a próxima versão principal do mecanismo ElastiCache Redis OSS. ElastiCache A versão 3.2.6 para usuários do Redis OSS tem acesso a todas as funcionalidades das versões anteriores do Redis OSS, além da opção de criptografar seus dados. Para saber mais, consulte:
+ [ElastiCache criptografia em trânsito (TLS)](in-transit-encryption.md)
+ [Criptografia em repouso em ElastiCache](at-rest-encryption.md)
+ [Validação de conformidade para a Amazon ElastiCache](elasticache-compliance.md)
#### ElastiCache versão 3.2.4 para Redis OSS (aprimorada)
A ElastiCache versão 3.2.4 da Amazon apresenta a próxima versão principal do mecanismo ElastiCache Redis OSS. ElastiCache *3.2.4 Os usuários têm todas as funcionalidades das versões anteriores do Redis OSS disponíveis, além da opção de execução no modo cluster ou no *modo não cluster*.* A tabela a seguir fornece um resumo.
**Comparação do Redis OSS 3.2.4 modo cluster e modo sem cluster**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/engine-versions.html)
**Observações:**
+ **Particionamento**: a capacidade de dividir seus dados em 2 a 500 grupos de nós (fragmentos) com suporte de replicação para cada grupo de nós.
+ **Indexação geoespacial**: o Redis OSS 3.2.4 oferece suporte para a indexação geoespacial por meio de seis comandos GEO. Para obter mais informações, consulte a documentação dos comandos GEO\$1 do Redis OSS [Comandos: GEO](http://valkey.io/commands#geo), na página Valkey Commands (filtrada por GEO).
Para obter informações sobre recursos adicionais do Redis OSS 3, consulte as [notas de versão do Redis OSS 3.2](https://github.com/redis/redis/blob/3.2/00-RELEASENOTES) e as [notas de release do Redis OSS 3.0](https://github.com/redis/redis/blob/3.0/00-RELEASENOTES).
O Valkey ou Redis OSS atualmente ElastiCache gerenciado (modo de cluster ativado) não oferece suporte aos seguintes recursos do Redis OSS 3.2:
+ Migração de réplica
+ Rebalanceamento do cluster
+ Depurador Lua
ElastiCache desativa os seguintes comandos de gerenciamento do 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`
Para obter informações sobre os parâmetros do Redis OSS 3.2.4, consulte [Alterações de parâmetros do Redis OSS 3.2.4](ParameterGroups.Engine.md#ParameterGroups.Redis.3-2-4).
### Versões que ultrapassaram o fim de vida útil (EOL) (2.x)
#### ElastiCache versão 2.8.24 para Redis OSS (aprimorada)
Melhorias do Redis OSS adicionadas desde a versão 2.8.23 incluem correções de bugs e o registro em log de endereços incorretos de acesso à memória. Para obter mais informações, consulte as [Notas de release do Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
#### ElastiCache versão 2.8.23 para Redis OSS (aprimorada)
Melhorias do Redis adicionadas desde a versão 2.8.22 incluem correções de bugs. Para obter mais informações, consulte as [Notas de release do Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES). Esta versão também inclui suporte para o novo parâmetro `close-on-slave-write` que, se ativado, desconecta clientes que tentam gravar em uma réplica somente leitura.
Para obter mais informações sobre os parâmetros do Redis OSS 2.8.23, consulte [Parâmetros adicionados do Redis OSS 2.8.23 (aprimorado)](ParameterGroups.Engine.md#ParameterGroups.Redis.2-8-23) o Guia do usuário. ElastiCache
#### ElastiCache versão 2.8.22 para Redis OSS (aprimorada)
Melhorias do Redis OSS adicionadas desde a versão 2.8.21 incluem o seguinte:
+ Suporte para backups e sincronizações sem garantia que permite alocar menos memória para despesas gerais de backup e mais para o seu aplicativo. Para obter mais informações, consulte [Como a sincronização e o backup são implementados](Replication.Redis.Versions.md). O processo sem bifurcação pode afetar tanto a latência quanto o throughput. No caso de alto throughput de gravação, quando uma réplica se sincronizar de novo, ela poderá ficar inacessível durante todo o tempo durante a sincronização.
+ Se houver um failover, os grupos de replicação agora se recuperarão mais rapidamente, pois as réplicas realizam sincronizações parciais com o primário em vez de sincronizações completas sempre que possível. Além disso, tanto o primário quanto as réplicas não usam mais o disco durante as sincronizações, proporcionando ganhos de velocidade adicionais.
+ Support para duas novas CloudWatch métricas.
+ `ReplicationBytes` - O número de bytes que o cluster primário de um grupo de replicação está enviando às réplicas de leitura.
+ `SaveInProgress` - Um valor binário que indica se há ou não um processo de salvamento em segundo plano em execução.
Para obter mais informações, consulte [Monitorando o uso com CloudWatch métricas](CacheMetrics.md).
+ Uma série de correções críticas de bugs no comportamento PSYNC de replicação. Para obter mais informações, consulte as [Notas de release do Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
+ Para manter o desempenho aprimorado da replicação em grupos de replicação Multi-AZ e para aumentar a estabilidade do cluster, não há mais suporte para não ElastiCache réplicas.
+ Para melhorar a consistência de dados entre o cluster primário e as réplicas em um grupo de replicação, as réplicas não removem mais as chaves independentemente do cluster primário.
+ As variáveis de configuração do Redis OSS `appendonly` e `appendfsync` não são compatíveis com o Redis OSS versão 2.8.22 e posteriores.
+ Em situações de pouca memória, os clientes com um grande buffer de saída podem ser desconectados de um cluster de réplicas. Se desconectado, o cliente deverá se reconectar. Essas situações são mais prováveis para clientes PUBSUB.
#### ElastiCache versão 2.8.21 para Redis OSS
Melhorias do Redis OSS adicionadas desde a versão 2.8.19 incluem várias correções de bugs. Para obter mais informações, consulte as [Notas de release do Redis OSS 2.8](https://github.com/redis/redis/blob/2.8/00-RELEASENOTES).
#### ElastiCache versão 2.8.19 para Redis OSS
Melhorias do Redis OSS adicionadas desde a versão 2.8.6 incluem o seguinte:
+ Support for HyperLogLog. Para obter mais informações, consulte a [nova estrutura de dados do Redis OSS](http://antirez.com/news/75):. HyperLogLog
+ Agora, o tipo de dados de conjunto classificado oferece suporte para consultas de intervalo lexicográfico com os novos comandos `ZRANGEBYLEX`, `ZLEXCOUNT` e `ZREMRANGEBYLEX`.
+ Para evitar que um nó primário envie dados obsoletos para nós de réplica, a SYNC mestre falhará se um processo filho de salvamento (`bgsave`) for anulado.
+ Support para a *HyperLogLogBasedCommands* CloudWatchmétrica. Para obter mais informações, consulte [Métricas para o Valkey e Redis OSS](CacheMetrics.Redis.md).
#### ElastiCache versão 2.8.6 para Redis OSS
Melhorias do Redis OSS adicionadas desde a versão 2.6.13 incluem o seguinte:
+ Resistência aprimorada e tolerância a falhas para réplicas de leitura.
+ Suporte para ressincronização parcial.
+ Suporte para o número mínimo de réplicas de leitura definido pelo usuário que deve estar disponível em todos os momentos.
+ Suporte total para pub/sub-notificação de clientes sobre eventos no servidor.
+ Detecção automática de uma falha do nó primário e failover do seu nó primário para um nó secundário.
#### ElastiCache versão 2.6.13 para Redis OSS
ElastiCache a versão 2.6.13 para Redis OSS foi a versão inicial do Redis OSS compatível ElastiCache . O Multi-AZ não é compatível com a ElastiCache versão 2.6.13 do Redis OSS.
## ElastiCache versões para o cronograma de fim de vida útil do Redis OSS
Esta seção define as datas de fim de vida útil (EOL) para as versões principais mais antigas à medida que são anunciadas. Ela ajudará você a tomar decisões sobre versões e atualizações no futuro.
**nota**
ElastiCache as versões de 5.0.0 a 5.0.5 para Redis OSS estão obsoletas. Use as versões 5.0.6 ou superior.
A tabela a seguir mostra o cronograma do [Extended Support](extended-support.md) ElastiCache para mecanismos Redis OSS.
**Suporte estendido e cronograma de fim da vida útil**
| Versão principal do mecanismo | Fim do suporte padrão | Início do Suporte estendido premium do ano 1 | Início do Suporte estendido premium do ano 2 | Início do Suporte estendido premium do ano 3 | Fim do Suporte estendido e versão EOL |
| --- | --- | --- | --- | --- | --- |
| Redis OSS v4 | 31/01/2026 | 01/02/2026 | 01/02/2027 | 2/1/2028 | 31/01/2029 |
| Redis OSS v5 | 31/01/2026 | 01/02/2026 | 01/02/2027 | 2/1/2028 | 31/01/2029 |
| Redis OSS v6 | 31/01/2027 | 01/02/2027 | 2/1/2028 | 01/02/2029 | 31/01/2030 |
A tabela a seguir resume cada versão e sua data de EOL anunciada, bem como a versão de destino de atualização recomendada.
**EOL passado**
| Versão principal de origem | Versões secundárias de origem | Destino de atualização recomendado | Data de EOL |
| --- | --- | --- | --- |
| Versão 3 | 3.2.4, 3.2.6 e 3.2.10 | Versão 6.2 ou superior Para as regiões US-ISO-EAST US-ISO-WEST -1, -1 e US-ISOB-EAST -1, recomendamos a versão 5.0.6 ou superior. | 31 de julho de 2023 |
| Versão 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 | Versão 6.2 ou superior Para as regiões US-ISO-EAST US-ISO-WEST -1, -1 e US-ISOB-EAST -1, recomendamos a versão 5.0.6 ou superior. | 13 de janeiro de 2023 |
## Compatível com ElastiCache versões do Memcached
ElastiCache oferece suporte às seguintes versões do Memcached e à atualização para versões mais recentes. Ao atualizar para uma versão mais recente, fique atento à condições que, caso não sejam atendidas, farão com que a atualização falhe.
**Topics**
+ [ElastiCache versão 1.6.22 para Memcached](#memcached-version-1-6-22)
+ [ElastiCache versão 1.6.17 para Memcached](#memcached-version-1-6-17)
+ [ElastiCache versão 1.6.12 para Memcached](#memcached-version-1-6-12)
+ [ElastiCache versão 1.6.6 para Memcached](#memcached-version-1-6-6)
+ [ElastiCache versão 1.5.16 para Memcached](#memcached-version-1-5-16)
+ [ElastiCache versão 1.5.10 para Memcached](#memcached-version-1-5-10)
+ [ElastiCache versão 1.4.34 para Memcached](#memcached-version-1-4-34)
+ [ElastiCache versão 1.4.33 para Memcached](#memcached-version-1-4-33)
+ [ElastiCache versão 1.4.24 para Memcached](#memcached-version-1-4-24)
+ [ElastiCache versão 1.4.14 para Memcached](#memcached-version-1-4-14)
+ [ElastiCache versão 1.4.5 para Memcached](#memcached-version-1-4-5)
### ElastiCache versão 1.6.22 para Memcached
ElastiCache para Memcached versão 1.6.22 para Memcached adiciona suporte para Memcached versão 1.6.22. Não inclui novos recursos, mas inclui correções de erros e atualizações cumulativas do [Memcached 1.6.18](https://github.com/memcached/memcached/wiki/ReleaseNotes1618).
Para obter mais informações, consulte [ReleaseNotes1622](https://github.com/memcached/memcached/wiki/ReleaseNotes1622) em Memcached on. GitHub
### ElastiCache versão 1.6.17 para Memcached
ElastiCache para Memcached versão 1.6.17 for Memcached adiciona suporte para a versão 1.6.17 do mecanismo Memcached. Não inclui novos recursos, mas inclui correções de erros e atualizações cumulativas do [Memcached 1.6.17](https://github.com/memcached/memcached/wiki/ReleaseNotes1617).
Para obter mais informações, consulte [ReleaseNotes1617](https://github.com/memcached/memcached/wiki/ReleaseNotes1617) em Memcached on. GitHub
### ElastiCache versão 1.6.12 para Memcached
ElastiCache para Memcached, a versão 1.6.12 para Memcached adiciona suporte ao mecanismo Memcached 1.6.12 e criptografia em trânsito. Ele inclui correções de erros e atualizações cumulativas do [Memcached 1.6.6](https://github.com/memcached/memcached/wiki/ReleaseNotes166).
Para obter mais informações, consulte [ReleaseNotes1612](https://github.com/memcached/memcached/wiki/ReleaseNotes1612) em Memcached on. GitHub
### ElastiCache versão 1.6.6 para Memcached
ElastiCache para Memcached versão 1.6.6 for Memcached adiciona suporte para Memcached versão 1.6.6. Ele não inclui novos recursos, mas inclui correções de erros e atualizações cumulativas do [Memcached](https://github.com/memcached/memcached/wiki/ReleaseNotes1.5.16) 1.5.16. ElastiCache [para Memcached não inclui suporte para Extstore.](https://memcached.org/extstore)
Para obter mais informações, consulte [ReleaseNotes166](https://github.com/memcached/memcached/wiki/ReleaseNotes166) em Memcached on. GitHub
### ElastiCache versão 1.5.16 para Memcached
ElastiCache a versão 1.5.16 para Memcached adiciona suporte para a versão 1.5.16 do Memcached. Não inclui novos recursos, mas inclui correções de erros e atualizações cumulativas de [Memcached 1.5.14](https://github.com/memcached/memcached/wiki/ReleaseNotes1514) e [Memcached 1.5.15](https://github.com/memcached/memcached/wiki/ReleaseNotes1515).
Para obter mais informações, consulte as [notas de lançamento do Memcached 1.5.16](https://github.com/memcached/memcached/wiki/ReleaseNotes1516) em Memcached on. GitHub
### ElastiCache versão 1.5.10 para Memcached
ElastiCache A versão 1.5.10 para Memcached oferece suporte aos seguintes recursos do Memcached:
+ Rebalanceamento de slab automatizado.
+ Pesquisas de tabela de hash mais rápidas com o algoritmo `murmur3`.
+ Algoritmo LRU segmentado.
+ Crawler de LRU para memória de recuperação do plano de fundo.
+ `--enable-seccomp`: uma opção de tempo de compilação.
Ele também apresenta os parâmetros `no_modern` e `inline_ascii_resp`. Para obter mais informações, consulte [Alterações de parâmetros do Memcached 1.5.10](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-5-10).
Os aprimoramentos do Memcached adicionados desde a ElastiCache versão 1.4.34 para o Memcached incluem o seguinte:
+ Correções cumulativas, como os multigets ASCII, CVE-2017-9951 e limites de crawls para o `metadumper`.
+ Melhor gerenciamento de conexão ao fechar as conexões no limite da conexão.
+ Gerenciamento do tamanho do item aprimorado para tamanho do item acima de 1MB.
+ Melhor desempenho e melhorias de sobrecarga da memória reduzindo os requisitos de memória por item por alguns bytes.
Para obter mais informações, consulte as [notas de lançamento do Memcached 1.5.10](https://github.com/memcached/memcached/wiki/ReleaseNotes1510) em Memcached on. GitHub
### ElastiCache versão 1.4.34 para Memcached
ElastiCache a versão 1.4.34 para Memcached não adiciona novos recursos à versão 1.4.33. A versão 1.4.34 é uma versão da correção de bugs maior que a versão usual.
Para obter mais informações, consulte as [notas de lançamento do Memcached 1.4.34](https://github.com/memcached/memcached/wiki/ReleaseNotes1434) em Memcached on. GitHub
### ElastiCache versão 1.4.33 para Memcached
Melhorias adicionadas desde a versão 1.4.24 incluem o seguinte:
+ Capacidade de despejar todos os metadados de uma classe de slab específica, uma lista de classes de slab ou todas as classes de slab. Para obter mais informações, consulte o documento [Notas de release do Memcached 1.4.31](https://github.com/memcached/memcached/wiki/ReleaseNotes1431).
+ Melhor suporte para itens grandes acima do padrão de 1 megabyte. Para obter mais informações, consulte o documento [Notas de release do Memcached 1.4.29](https://github.com/memcached/memcached/wiki/ReleaseNotes1429).
+ Capacidade de especificar por quanto tempo um cliente pode estar ocioso antes de ser solicitado a fechar.
Capacidade de aumentar dinamicamente a quantidade de memória disponível para o Memcached sem ter que reiniciar o cluster. Para obter mais informações, consulte o documento [Notas de release do Memcached 1.4.27](https://github.com/memcached/memcached/wiki/ReleaseNotes1427).
+ Agora há suporte para o registro em log de `fetchers`, `mutations` e `evictions`. Para obter mais informações, consulte o documento [Notas de release do Memcached 1.4.26](https://github.com/memcached/memcached/wiki/ReleaseNotes1426).
+ A memória liberada pode ser recuperada para um grupo global e reatribuída a novas classes de slab. Para obter mais informações, consulte o documento [Notas de release do Memcached 1.4.25](https://github.com/memcached/memcached/wiki/ReleaseNotes1425).
+ Diversas correções de bugs.
+ Alguns novos comandos e parâmetros. Para ver uma lista, consulte [Parâmetros adicionados do Memcached 1.4.33](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-33).
### ElastiCache versão 1.4.24 para Memcached
Melhorias adicionadas desde a versão 1.4.14 incluem o seguinte:
+ Gerenciamento de LRUs (menos utilizados recentemente) usando um processo em segundo plano.
+ Adição da opção de usar o *jenkins* ou o *murmur3* como algoritmo de hash.
+ Alguns novos comandos e parâmetros. Para ver uma lista, consulte [Parâmetros adicionados do Memcached 1.4.24](ParameterGroups.Engine.md#ParameterGroups.Memcached.1-4-24).
+ Diversas correções de bugs.
### ElastiCache versão 1.4.14 para Memcached
Melhorias adicionadas desde a versão 1.4.5 incluem o seguinte:
+ Maior capacidade de rebalanceamento de slabs.
+ Melhoria de desempenho e escalabilidade.
+ Introdução do comando *touch* para atualizar o tempo de expiração de um item existente sem buscá-lo.
+ Descoberta automática: a capacidade de programas clientes determinarem automaticamente todos os nós do cache em um cluster e iniciarem e manterem conexões com todos esses nós.
### ElastiCache versão 1.4.5 para Memcached
ElastiCache a versão 1.4.5 para Memcached foi o mecanismo inicial e a versão suportados pela Amazon ElastiCache para Memcached.
# Principais diferenças de comportamento e compatibilidade do mecanismo da versão com o Valkey
O Valkey 7.2.6 tem diferenças de compatibilidade semelhantes às versões anteriores do Redis OSS 7.2.4. Para a versão compatível mais recente do Valkey, consulte [Mecanismos e versões compatíveis](VersionManagement.md#supported-engine-versions).
Para ter mais informações sobre o Valkey versão 7.2, consulte [Redis OSS 7.2.4 Release Notes](https://github.com/valkey-io/valkey/blob/d2c8a4b91e8c0e6aefd1f5bc0bf582cddbe046b7/00-RELEASENOTES) (o Valkey 7.2 inclui todas as alterações do Redis OSS até a versão 7.2.4) e [Valkey 7.2 release notes](https://github.com/valkey-io/valkey/blob/7.2/00-RELEASENOTES) no repositório do Valkey no GitHub.
Aqui estão as mudanças de comportamento que podem causar interrupção entre o Valkey 7.2 e o Redis OSS 7.1 (ou 7.0):
+ A amostragem de tempo de congelamento ocorre durante a execução do comando e nos scripts.
+ Um comando de fluxo bloqueado que é lançado quando a chave não existe mais carrega um código de erro diferente (-NOGROUP ou -WRONGTYPE em vez de -UNBLOCKED).
+ O rastreamento do lado do cliente para scripts agora rastreia as chaves que são lidas pelo script, em vez das chaves declaradas pelo chamador de EVAL/FCALL.
# Principais diferenças de comportamento e compatibilidade do mecanismo da versão com o Redis OSS
**Importante**
A página a seguir é estruturada para indicar todas as diferenças de incompatibilidade entre versões e informar você sobre quaisquer considerações que deva fazer ao atualizar para versões mais recentes. Essa lista inclui todos os problemas de incompatibilidade de versão que você possa encontrar ao atualizar.
Você pode fazer o upgrade diretamente da sua versão atual do Redis OSS para a versão mais recente disponível, sem a necessidade de atualizações sequenciais. Por exemplo, você pode atualizar diretamente da versão 3.0 do Redis OSS para a versão 7.0.
As versões do Redis OSS são identificadas com uma versão semântica que compreende um componente MAJOR, MINOR e PATCH. Por exemplo, no Redis OSS 4.0.10, a versão principal é a 4, a versão secundária é a 0 e a versão do patch é a 10. Esses valores geralmente são incrementados com base nas seguintes convenções:
+ As versões principais são para alterações incompatíveis com a API
+ As versões secundárias são para novas funcionalidades adicionadas de forma compatível com as versões anteriores
+ As versões do patch são para correções de bugs compatíveis com versões anteriores e mudanças não funcionais
Recomendamos sempre permanecer na versão mais recente do patch dentro de uma determinada versão **major.minor** para obter as melhorias mais recentes de performance e estabilidade. A partir da ElastiCache versão 6.0 para Redis OSS, ElastiCache oferecerá uma única versão para cada versão secundária do Redis OSS, em vez de oferecer várias versões de patch. ElastiCachegerenciará automaticamente a versão de patch de seus clusters em execução, garantindo melhor desempenho e segurança aprimorada.
Também recomendamos atualizar periodicamente para a versão principal mais recente, já que a maioria das melhorias principais não são transferidas para versões mais antigas. À medida que ElastiCache expande a disponibilidade para uma nova AWS região, o OSS ElastiCache para Redis oferece suporte às duas versões **major.minor** mais recentes da época para a nova região. ****Por exemplo, se uma nova AWS região for lançada e as ElastiCache versões major.minor mais recentes do Redis OSS forem **7.0 e 6.2, ElastiCache oferecerá suporte às versões 7.0** **e 6.2** do Redis OSS na nova região.****AWSÀ medida que novas versões major.minor do ElastiCache for Redis OSS forem lançadas, ElastiCache continuaremos adicionando suporte às versões recém-lançadas. Para saber mais sobre como escolher regiões para ElastiCache, consulte [Escolha de regiões e zonas de disponibilidade](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/RegionsAndAZs.html#SupportedRegions).
Ao fazer uma atualização que abrange versões principais ou secundárias, considere a lista a seguir, que inclui comportamento e alterações incompatíveis com versões anteriores lançadas com o Redis OSS ao longo do tempo.
## Alterações de comportamento do Redis OSS 7.0 e alterações incompatíveis com versões anteriores
Para obter uma lista completa de alterações, consulte as [Notas de versão do Redis OSS 7.0](https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES).
+ `SCRIPT LOAD` e `SCRIPT FLUSH` não são mais propagados para réplicas. Se você precisar ter alguma durabilidade para scripts, recomendamos que você considere usar as [funções do Redis OSS](https://valkey.io/topics/functions-intro/).
+ Os canais Pubsub agora estão bloqueados por padrão para novos usuários de ACL.
+ O comando `STRALGO` foi substituído pelo comando `LCS`.
+ O formato de `ACL GETUSER` foi alterado para que todos os campos mostrem o padrão de cadeia de caracteres de acesso padrão. Se você teve automação usando `ACL GETUSER`, verifique se ela funcionará com qualquer um dos formatos.
+ As categorias de ACL para `SELECT`, `WAIT`, `ROLE`, `LASTSAVE`, `READONLY`, `READWRITE` e `ASKING` foram alteradas.
+ O comando `INFO` agora mostra estatísticas de comando por subcomando, em vez de nos comandos do contêiner de nível superior.
+ Os valores de retorno dos comandos `LPOP`, `RPOP`, `ZPOPMIN` e `ZPOPMAX` foram alterados em determinados casos de borda. Se você usar esses comandos, verifique as notas de release e avalie se foi afetado.
+ Os comandos `SORT` e `SORT_RO` agora exigem acesso a todo o espaço de teclas para usar os argumentos `GET` e `BY`.
## Alterações de comportamento do Redis OSS 6.2 e alterações incompatíveis com versões anteriores
Para obter uma lista completa de alterações, consulte as [Notas de versão do Redis OSS 6.2](https://raw.githubusercontent.com/redis/redis/6.2/00-RELEASENOTES).
+ Os sinalizadores ACL dos comandos `TIME`, `ECHO`, `ROLE` e `LASTSAVE` foram alterados. Isso pode fazer com que comandos que antes tinham permissão sejam rejeitados e vice-versa.
**nota**
Nenhum desses comandos modifica ou concede acesso aos dados.
+ Ao atualizar do Redis OSS 6.0, a ordem dos key/value pares retornados de uma resposta do mapa para um script lua é alterada. Se os seus scripts usarem `redis.setresp()` ou retornarem um mapa (novo no Redis OSS 6.0), considere as implicações que o script pode quebrar nas atualizações.
## Alterações de comportamento do Redis OSS 6.0 e alterações incompatíveis com versões anteriores
Para obter uma lista completa de alterações, consulte as [Notas de versão do Redis OSS 6.0](https://raw.githubusercontent.com/redis/redis/6.0/00-RELEASENOTES).
+ O número máximo de bancos de dados permitidos foi reduzido de 1,2 milhão para 10 mil. O valor padrão é 16, e desencorajamos o uso de valores muito maiores do que isso, pois encontramos problemas de performance e memória.
+ Defina o `AutoMinorVersionUpgrade` parâmetro como sim e ElastiCache gerenciará a atualização da versão secundária por meio de atualizações de autoatendimento. Isso será tratado por meio de canais padrão de notificação do cliente por meio de uma campanha de atualização de autoatendimento. Para obter mais informações, consulte [Atualizações de autoatendimento em ElastiCache](Self-Service-Updates.md).
## Alterações de comportamento do Redis OSS 5.0 e alterações incompatíveis com versões anteriores
Para obter uma lista completa de alterações, consulte as [Notas de versão do Redis OSS 5.0](https://raw.githubusercontent.com/redis/redis/5.0/00-RELEASENOTES).
+ Os scripts são replicados por efeitos em vez de reexecutar o script na réplica. Isso geralmente melhora a performance, mas pode aumentar a quantidade de dados replicados entre os primários e as réplicas. Há uma opção para voltar ao comportamento anterior que só está disponível na ElastiCache versão 5.0 para Redis OSS.
+ Se você estiver atualizando a partir do Redis OSS 4.0, alguns comandos em scripts LUA retornarão argumentos em uma ordem diferente daquela em versões anteriores. No Redis OSS 4.0, o Redis OSS ordenaria algumas respostas lexigraficamente para tornar as respostas determinísticas, essa ordem não é aplicada quando os scripts são replicados por efeitos.
+ No Redis OSS 5.0.3 e superior, ElastiCache para o Redis, o OSS descarregará parte do trabalho de E/S para núcleos em segundo plano em tipos de instância com mais de 4. VCPUs Isso pode alterar as características de performance do Redis OSS e alterar os valores de algumas métricas. Para obter mais informações, consulte [Que métricas devo monitorar?](CacheMetrics.WhichShouldIMonitor.md) para entender se você precisa alterar quais métricas você assiste.
## Alterações de comportamento do Redis OSS 4.0 e alterações incompatíveis com versões anteriores
Para obter uma lista completa de alterações, consulte as [Notas de versão do Redis OSS 4.0](https://raw.githubusercontent.com/redis/redis/4.0/00-RELEASENOTES).
+ O log lento agora registra dois argumentos adicionais, o nome e o endereço do cliente. Essa alteração deve ser compatível com versões anteriores, a menos que você confie explicitamente em cada entrada de log lenta contendo 3 valores.
+ O `CLUSTER NODES` agora retorna um formato ligeiramente diferente, que não é compatível com versões anteriores. Recomendamos que os clientes não usem esse comando para aprender sobre os nós presentes em um cluster e, em vez disso, eles usem `CLUSTER SLOTS`.
## EOL passado
### Alterações de comportamento do Redis OSS 3.2 e alterações incompatíveis com versões anteriores
Para obter uma lista completa de alterações, consulte as [Notas de versão do Redis OSS 3.2](https://raw.githubusercontent.com/redis/redis/3.2/00-RELEASENOTES).
+ Não há mudanças de compatibilidade a serem destacadas para esta versão.
Para obter mais informações, consulte [ElastiCache versões para o cronograma de fim de vida útil do Redis OSS](engine-versions.md#deprecated-engine-versions).
### Alterações de comportamento do Redis OSS 2.8 e alterações incompatíveis com versões anteriores
Para obter uma lista completa de alterações, consulte as [Notas de versão do Redis OSS 2.8](https://raw.githubusercontent.com/redis/redis/2.8/00-RELEASENOTES).
+ A partir do Redis OSS 2.8.22, o Redis OSS AOF não é mais suportado no Redis OSS. ElastiCache Recomendamos o uso do MemoryDB quando os dados precisam ser persistidos de forma duradoura.
+ A partir do Redis OSS 2.8.22, ElastiCache para Redis, o OSS não suporta mais a anexação de réplicas às primárias hospedadas nele. ElastiCache Durante a atualização, as réplicas externas serão desconectadas e não poderão se reconectar. Recomendamos usar o cache do lado do cliente, disponibilizado no Redis OSS 6.0 como uma alternativa às réplicas externas.
+ Os comandos `TTL` e `PTTL` agora retornarão -2 se a chave não existir e -1 se existir, mas não tiver expiração associada. O Redis OSS 2.6 e as versões anteriores costumavam retornar -1 para ambas as condições.
+ O `SORT` com `ALPHA` agora classificará de acordo com o local de agrupamento local, se nenhuma opção `STORE` for usada.
Para obter mais informações, consulte [ElastiCache versões para o cronograma de fim de vida útil do Redis OSS](engine-versions.md#deprecated-engine-versions).
# Considerações sobre atualização ao trabalhar com clusters baseados em nós
**nota**
As considerações a seguir só se aplicam ao atualizar clusters baseados em nós. Eles não se aplicam ao ElastiCache Serverless.
**Considerações sobre Valkey e Redis OSS**
Ao atualizar um cluster baseado em nós, leve em consideração o seguinte.
+ O gerenciamento da versão do mecanismo foi desenvolvido para que você possa ter o máximo controle possível sobre a execução de patches. No entanto, ElastiCache se reserva o direito de corrigir seu cluster em seu nome no caso improvável de uma vulnerabilidade crítica de segurança no sistema ou no software de cache.
+ Começando com a ElastiCache versão 7.2 para Valkey e a ElastiCache versão 6.0 para Redis OSS, ElastiCache oferecerá uma única versão para cada versão secundária, em vez de oferecer várias versões de patch.
+ A partir do mecanismo Redis OSS versão 5.0.6, você pode atualizar a versão do cluster com o mínimo de tempo de inatividade. O cluster estará disponível para leituras durante todo o processo de atualização e para gravações durante a maior parte da atualização, exceto durante a operação de failover que dura alguns segundos.
+ Você também pode atualizar seus ElastiCache clusters com versões anteriores à 5.0.6. O processo envolvido é o mesmo, mas pode incorrer em tempo de failover mais longo durante a propagação do DNS (30 s a 1 m).
+ A partir do Redis OSS 7, ElastiCache oferece suporte à alternância entre Valkey ou Redis OSS (modo de cluster desativado) e Valkey ou Redis OSS (modo de cluster ativado).
+ O processo de atualização do mecanismo Amazon ElastiCache for Redis OSS foi projetado para fazer o melhor esforço para reter seus dados existentes e requer uma replicação bem-sucedida do Redis OSS.
+ Ao atualizar o mecanismo, ElastiCache encerrará as conexões existentes do cliente. Para minimizar o tempo de inatividade durante as atualizações do mecanismo, recomendamos implementar [as práticas recomendadas para clientes do Redis OSS](BestPractices.Clients.redis.md) com novas tentativas de erro e recuo exponencial e as práticas recomendadas para [minimizar o tempo de inatividade durante a manutenção](BestPractices.MinimizeDowntime.md).
+ Não é possível atualizar diretamente do Valkey ou Redis OSS (modo cluster desabilitado) para o Valkey ou Redis OSS (modo cluster habilitado) ao atualizar seu mecanismo. O procedimento a seguir mostra como atualizar do Valkey ou Redis OSS (modo cluster desabilitado) para o Valkey ou Redis OSS (modo cluster habilitado).
**Para atualizar de uma versão de mecanismo Valkey ou Redis OSS (modo cluster desabilitado) para Valkey ou Redis OSS (modo cluster habilitado)**
1. Faça um backup do seu cluster do Valkey ou Redis OSS (modo cluster desabilitado) ou do grupo de replicação. Para obter mais informações, consulte [Realização de backups manuais](backups-manual.md).
1. Use o backup para criar e propagar um cluster do Valkey ou Redis OSS (modo cluster habilitado) com um fragmento (grupo de nós). Especifique a nova versão do mecanismo e habilite o modo de cluster ao criar o cluster ou o grupo de replicação. Para obter mais informações, consulte [Tutorial: propagação de um novo cluster baseado em nós com um backup criado externamente](backups-seeding-redis.md).
1. Exclua o antigo cluster do Valkey ou Redis OSS (modo cluster desabilitado) ou o grupo de replicação. Para acessar mais informações, consulte [Excluindo um cluster no ElastiCache](Clusters.Delete.md) ou [Exclusão de um grupo de replicação](Replication.DeletingRepGroup.md).
1. Escale o novo cluster ou grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) para o número de fragmentos (grupos de nós) que você precisa. Para obter mais informações, consulte [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md).
+ Ao atualizar as principais versões do mecanismo, por exemplo, de 5.0.6 para 6.0, também é necessário selecionar um novo grupo de parâmetros que seja compatível com a nova versão do mecanismo.
+ Para clusters Redis OSS de nó único e clusters Redis individuais com o Multi-AZ desabilitado, recomendamos que seja disponibilizada memória suficiente para o Redis OSS, conforme descrito em [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md). Nesses casos, o primário não está disponível para solicitações de serviço durante o processo de atualização.
+ Para clusters Redis OSS com o Multi-AZ habilitado, também recomendamos que você programe atualizações do mecanismo durante períodos de baixo tráfego de gravações recebidas. Ao atualizar para o Redis OSS 5.0.6 ou posterior, o cluster primário continua disponível para solicitações de serviço durante o processo de atualização.
Os clusters e os grupos de replicação com vários fragmentos são processados e corrigidos da seguinte forma:
+ Todos os estilhaços são processados em paralelo. Somente uma operação de atualização é realizada em um estilhaço por vez.
+ Em cada fragmento, todas as réplicas são processadas antes do processamento da primária. Caso haja menos réplicas em um fragmento, a primária nesse fragmento pode ser processada antes da conclusão do processamento das réplicas em outros fragmentos.
+ Em todos os fragmentos, os nós primários são processados em série. Somente um nó primário é atualizado por vez.
+ Caso a criptografia esteja habilitada no cluster ou no grupo de replicação atual, não será possível atualizar para uma versão de mecanismo que não ofereça suporte à criptografia, como de 3.2.6 a 3.2.10.
**Considerações sobre o Memcached**
Ao atualizar um cluster Memcached baseado em nós, considere o seguinte.
+ O gerenciamento da versão do mecanismo foi desenvolvido para que você possa ter o máximo controle possível sobre a execução de patches. No entanto, ElastiCache se reserva o direito de corrigir seu cluster em seu nome no caso improvável de uma vulnerabilidade crítica de segurança no sistema ou no software de cache.
+ Como o mecanismo Memcached não oferece suporte para persistência, as atualizações de versão do mecanismo Memcached são sempre um processo disruptivo que limpa todos os dados do cache no cluster.
# Práticas recomendadas e estratégias de armazenamento em cache do ElastiCache
Abaixo, é possível encontrar práticas recomendadas para o Amazon ElastiCache. Seguir essas práticas melhora o desempenho e aumenta a confiabilidade do cache.
**Topics**
+ [Práticas recomendadas gerais](WorkingWithRedis.md)
+ [Práticas recomendadas para usar réplicas de leitura](ReadReplicas.md)
+ [Comandos Valkey, Memcached e Redis OSS compatíveis e restritos](SupportedCommands.md)
+ [Configuração e limites do Valkey e Redis OSS](RedisConfiguration.md)
+ [Exemplos de clientes IPv6 para Valkey, Memcached e Redis OSS](network-type-best-practices.md)
+ [Práticas recomendadas para clientes (Valkey e Redis OSS)](BestPractices.Clients.redis.md)
+ [Práticas recomendadas para clientes (Memcached)](BestPractices.Clients.memcached.md)
+ [Clusters do ElastiCache de pilha dupla habilitados para TLS](#network-type-configuring-tls-enabled-dual-stack)
+ [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md)
+ [Práticas recomendadas ao trabalhar com clusters baseados em nós do Valkey e Redis OSS](BestPractices.SelfDesigned.md)
+ [Estratégias de armazenamento em cache para Memcached](Strategies.md)
# Práticas recomendadas gerais
Abaixo, você pode encontrar informações sobre as melhores práticas para usar as interfaces Valkey, Memcached e Redis OSS. ElastiCache
+ **Use configurações habilitadas para o modo de cluster — o modo de cluster ativado** permite que o cache seja dimensionado horizontalmente para obter maior armazenamento e taxa de transferência do que uma configuração desativada no modo de cluster. ElastiCache serverless só está disponível em uma configuração habilitada para o modo de cluster.
+ **Usar conexões de longa duração**: a criação de uma nova conexão é cara e consome tempo e recursos de CPU do cache. Reutilize conexões quando possível (por exemplo, com agrupamento de conexões) para amortizar esse custo em muitos comandos.
+ **Leia a partir de réplicas** — se você estiver usando réplicas de leitura ElastiCache sem servidor ou provisionadas (clusters baseados em nós), direcione as leituras para as réplicas para obter melhor escalabilidade e menor latência. and/or As leituras de réplicas acabarão sendo consistentes com a primária.
Em um cluster baseado em nós, evite direcionar solicitações de leitura para uma única réplica de leitura, pois as leituras talvez não estejam temporariamente disponíveis em caso de falha no nó. Configure o cliente para direcionar solicitações de leitura para pelo menos duas réplicas de leitura ou direcione as leituras para uma única réplica e a primária.
ElastiCache Sem servidor, a leitura da porta de réplica (6380) direcionará as leituras para a zona de disponibilidade local do cliente quando possível, reduzindo a latência de recuperação. Ele vai acabar fazendo fallback automaticamente para os outros nós durante as falhas.
+ **Evite comandos caros** — Evite executar operações computacionais e I/O intensivas, como os comandos `KEYS` e. `SMEMBERS` Sugerimos essa abordagem porque essas operações aumentam a carga no cluster e geram impacto no desempenho do cluster. Em vez disso, use os comandos `SCAN` e `SSCAN`.
+ **Siga as práticas recomendadas do Lua**: evite scripts Lua de longa execução e sempre declare antecipadamente as chaves usadas em scripts Lua. Recomendamos essa abordagem para determinar se o script Lua não está usando comandos entre slots. Certifique-se de que as chaves usadas em scripts Lua pertencem ao mesmo slot.
+ **Use pub/sub fragmentado** — Ao usar o Valkey ou o Redis OSS para oferecer suporte a pub/sub cargas de trabalho com alta taxa de transferência, recomendamos que você use o [pub/sub fragmentado](https://valkey.io/topics/pubsub/) (disponível com o Valkey e com o Redis OSS 7 ou posterior). Os clusters tradicionais habilitados para o modo de cluster pub/sub transmitem mensagens para todos os nós do cluster, o que pode resultar em alta. `EngineCPUUtilization` Observe isso em ElastiCache comandos tradicionais pub/sub commands internally use sharded pub/sub sem servidor.
**Topics**
# Práticas recomendadas para usar réplicas de leitura
Muitos aplicativos, como armazenamentos de sessões, tabelas de classificação e mecanismos de recomendação, exigem alta disponibilidade e processam uma quantidade significativamente maior de operações de leitura do que de operações de gravação. Em geral, esses aplicativos podem tolerar dados um pouco obsoletos (consistência eventual). Isso significa que é aceitável que usuários diferentes vejam, por alguns instantes, versões ligeiramente diferentes dos mesmos dados. Por exemplo:
+ Os resultados das consultas em cache geralmente podem tolerar dados um pouco obsoletos, especialmente para padrões de armazenamento em cache, nos quais a fonte da verdade é externa.
+ Em uma tabela de classificação de jogos, alguns segundos de atraso nas pontuações atualizadas geralmente não afetam significativamente a experiência do usuário.
+ Para armazenamentos de sessões, alguns pequenos atrasos na propagação dos dados da sessão entre réplicas raramente afetam a funcionalidade do aplicativo.
+ Os mecanismos de recomendação costumam usar análise de dados históricos, portanto, a consistência em tempo real é menos crítica.
A consistência eventual significa que todos os nós de réplica eventualmente retornarão os mesmos dados quando o processo de replicação for concluído, normalmente em milissegundos. Para esses casos de uso, implementar réplicas de leitura é uma estratégia eficaz para reduzir a latência ao ler da sua ElastiCache instância.
O uso de réplicas de leitura na Amazon ElastiCache pode oferecer benefícios significativos de desempenho por meio de:
**Escalabilidade de leitura aprimorada**
+ Distribui as operações de leitura em vários nós de réplica
+ Descarrega o tráfego de leitura do nó primário
+ Reduz a latência de leitura ao atender solicitações de réplicas geograficamente mais próximas
**Desempenho otimizado do nó primário**
+ Dedica recursos do nó primário às operações de gravação
+ Reduz a sobrecarga de conexão no nó primário
+ Melhora o desempenho de gravação e mantém melhores tempos de resposta durante os períodos de pico de tráfego
## Usando a leitura da réplica sem servidor ElastiCache
ElastiCache O serverless fornece dois endpoints diferentes, para diferentes requisitos de consistência. Os dois endpoints usam o mesmo nome de DNS, mas portas diferentes. Para usar a read-from-replica porta, você deve autorizar o acesso às duas portas do seu aplicativo cliente [configurando os grupos de segurança e as listas de controle de acesso à rede da sua VPC](set-up.md#elasticache-install-grant-access-VPN).
**Endpoint primário (porta 6379)**
+ Use para operações que exigem consistência imediata
+ Garante a leitura da maioria dos up-to-date dados
+ Ideal para transações críticas e operações de gravação
+ Necessário para operações de gravação
+ Exemplo: `test-12345.serverless.use1.cache.amazonaws.com:6379`
**Endpoint otimizado para latência (porta 6380)**
+ Otimizado para operações de leitura que podem tolerar uma eventual consistência
+ Quando possível, o ElastiCache serverless encaminha automaticamente as solicitações de leitura para o nó de réplica na zona de disponibilidade local do cliente. Essa otimização fornece menor latência ao evitar a latência adicional de rede resultante da recuperação de dados de um nó em uma zona de disponibilidade diferente.
+ ElastiCache serverless seleciona automaticamente os nós disponíveis em outras zonas se um nó local não estiver disponível
+ Exemplo: `test-12345.serverless.use1.cache.amazonaws.com:6380`
+ Clientes como Glide e Lettuce detectarão e rotearão automaticamente as leituras para o endpoint com latência otimizada se você fornecer a leitura da configuração da réplica. Se seu cliente não é compatível com a configuração de roteamento (por exemplo, valkey-java e versões mais antigas do jedis), será necessário definir a porta e a configuração do cliente corretas para ler as réplicas.
## Conectando-se a réplicas de leitura em ElastiCache Serverless - Valkey and Glide
O trecho de código a seguir mostra como você pode configurar a leitura da réplica para ElastiCache Serverless na biblioteca Valkey glide. Não é preciso especificar a porta para leitura das réplicas, mas sim configurar a configuração de roteamento `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());
}
}
}
}
}
```
# Comandos Valkey, Memcached e Redis OSS compatíveis e restritos
## Comandos compatíveis do Valkey e do Redis OSS
**Comandos compatíveis do Valkey e do Redis OSS**
Os comandos do Valkey e Redis OSS a seguir são compatíveis com caches com tecnologia sem servidor. Além desses comandos, estes [Comandos compatíveis do Valkey e do Redis OSSComandos JSON](json-list-commands.md) também são compatíveis.
Para obter informações sobre os comandos do filtro Bloom, consulte [Comandos de filtro Bloom](BloomFilters.md#SupportedCommandsBloom)
**Comandos de bitmap**
+ `BITCOUNT`
Conta o número de bits definidos (contagem de população) em uma string.
[Saiba mais](https://valkey.io/commands/bitcount/)
+ `BITFIELD`
Realiza operações arbitrárias de inteiro de campo de bits em strings.
[Saiba mais](https://valkey.io/commands/bitfield/)
+ `BITFIELD_RO`
Realiza operações arbitrárias de inteiro somente leitura de campo de bits em strings.
[Saiba mais](https://valkey.io/commands/bitfield_ro/)
+ `BITOP`
Realiza operações bit a bit em várias strings e armazena o resultado.
[Saiba mais](https://valkey.io/commands/bitop/)
+ `BITPOS`
Encontra o primeiro bit definido (1) ou apagado (0) em uma string.
[Saiba mais](https://valkey.io/commands/bitpos/)
+ `GETBIT`
Retorna um valor de bit por deslocamento.
[Saiba mais](https://valkey.io/commands/getbit/)
+ `SETBIT`
Define ou apaga o bit no deslocamento do valor da string. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/setbit/)
**Comandos de gerenciamento de clusters**
+ `CLUSTER COUNTKEYSINSLOT`
Retorna o número de chaves em um slot de hash.
[Saiba mais](https://valkey.io/commands/cluster-countkeysinslot/)
+ `CLUSTER GETKEYSINSLOT`
Retorna os nomes de chave em um slot de hash.
[Saiba mais](https://valkey.io/commands/cluster-getkeysinslot/)
+ `CLUSTER INFO`
Retorna informações sobre o estado de um nó. Em um cache sem servidor, retorna o estado sobre o único “fragmento” virtual exposto ao cliente.
[Saiba mais](https://valkey.io/commands/cluster-info/)
+ `CLUSTER KEYSLOT`
Retorna o slot de hash de uma chave.
[Saiba mais](https://valkey.io/commands/cluster-keyslot/)
+ `CLUSTER MYID`
Retorna o ID de um nó. Em um cache sem servidor, retorna o estado sobre o único “fragmento” virtual exposto ao cliente.
[Saiba mais](https://valkey.io/commands/cluster-myid/)
+ `CLUSTER NODES`
Retorna a configuração do cluster de um nó. Em um cache sem servidor, retorna o estado sobre o único “fragmento” virtual exposto ao cliente.
[Saiba mais](https://valkey.io/commands/cluster-nodes/)
+ `CLUSTER REPLICAS`
Lista os nós de réplica de um nó principal. Em um cache sem servidor, retorna o estado sobre o único “fragmento” virtual exposto ao cliente.
[Saiba mais](https://valkey.io/commands/cluster-replicas/)
+ `CLUSTER SHARDS`
Retorna o mapeamento de slots de cluster para fragmentos. Em um cache sem servidor, retorna o estado sobre o único “fragmento” virtual exposto ao cliente.
[Saiba mais](https://valkey.io/commands/cluster-shards/)
+ `CLUSTER SLOTS`
Retorna o mapeamento de slots de cluster para nós. Em um cache sem servidor, retorna o estado sobre o único “fragmento” virtual exposto ao cliente.
[Saiba mais](https://valkey.io/commands/cluster-slots/)
+ `CLUSTER SLOT-STATS`
Permite o rastreamento de métricas por slot para contagem de chaves, utilização da CPU, entrada de bytes de rede e saída de bytes de rede.
[Saiba mais](https://valkey.io/commands/cluster-slot-stats/)
+ `READONLY`
Permite consultas somente leitura para uma conexão com um nó de réplica do Valkey ou Redis OSS Cluster.
[Saiba mais](https://valkey.io/commands/readonly/)
+ `READWRITE`
Permite consultas de leitura e gravação para uma conexão com um nó de réplica do Valkey ou Redis OSS Cluster.
[Saiba mais](https://valkey.io/commands/readwrite/)
+ `SCRIPT SHOW`
Retorna o código-fonte original de um script no cache do script.
[Saiba mais](https://valkey.io/commands/script-show/)
**Comandos de gerenciamento da conexão**
+ `AUTH`
Autentica a conexão.
[Saiba mais](https://valkey.io/commands/auth/)
+ `CLIENT GETNAME`
Retorna o nome da conexão.
[Saiba mais](https://valkey.io/commands/client-getname/)
+ `CLIENT REPLY`
Instrui o servidor se deve responder aos comandos.
[Saiba mais](https://valkey.io/commands/client-reply/)
+ `CLIENT SETNAME`
Define o nome da conexão.
[Saiba mais](https://valkey.io/commands/client-setname/)
+ `ECHO`
Retorna a string indicada.
[Saiba mais](https://valkey.io/commands/echo/)
+ `HELLO`
Cumprimenta o servidor do Valkey ou Redis OSS.
[Saiba mais](https://valkey.io/commands/hello/)
+ `PING`
Retorna a resposta de atividade do servidor.
[Saiba mais](https://valkey.io/commands/ping/)
+ `QUIT`
Fecha a conexão.
[Saiba mais](https://valkey.io/commands/quit/)
+ `RESET`
Redefine a conexão.
[Saiba mais](https://valkey.io/commands/reset/)
+ `SELECT`
Altera o banco de dados selecionado.
[Saiba mais](https://valkey.io/commands/select/)
**Comandos genéricos**
+ `COPY`
Copia o valor de uma chave para uma nova chave.
[Saiba mais](https://valkey.io/commands/copy/)
+ `DEL`
Exclui uma ou mais chaves.
[Saiba mais](https://valkey.io/commands/del/)
+ `DUMP`
Retorna uma representação serializada do valor armazenado em uma chave.
[Saiba mais](https://valkey.io/commands/dump/)
+ `EXISTS`
Determina se existe uma ou mais chaves.
[Saiba mais](https://valkey.io/commands/exists/)
+ `EXPIRE`
Define o tempo de expiração de uma chave em segundos.
[Saiba mais](https://valkey.io/commands/expire/)
+ `EXPIREAT`
Define o tempo de expiração de uma chave como um carimbo de data e hora Unix.
[Saiba mais](https://valkey.io/commands/expireat/)
+ `EXPIRETIME`
Retorna o tempo de expiração de uma chave como um carimbo de data e hora Unix.
[Saiba mais](https://valkey.io/commands/expiretime/)
+ `PERSIST`
Remove o tempo de expiração de uma chave.
[Saiba mais](https://valkey.io/commands/persist/)
+ `PEXPIRE`
Define o tempo de expiração de uma chave em milissegundos.
[Saiba mais](https://valkey.io/commands/pexpire/)
+ `PEXPIREAT`
Define o tempo de expiração de uma chave como um carimbo de data e hora Unix em milissegundos.
[Saiba mais](https://valkey.io/commands/pexpireat/)
+ `PEXPIRETIME`
Retorna o tempo de expiração de uma chave como um carimbo de data e hora Unix em milissegundos.
[Saiba mais](https://valkey.io/commands/pexpiretime/)
+ `PTTL`
Define o tempo de expiração de uma chave em milissegundos.
[Saiba mais](https://valkey.io/commands/pttl/)
+ `RANDOMKEY`
Retorna um nome de chave aleatório do banco de dados.
[Saiba mais](https://valkey.io/commands/randomkey/)
+ `RENAME`
Renomeia uma chave e substitui o destino.
[Saiba mais](https://valkey.io/commands/rename/)
+ `RENAMENX`
Só renomeia uma chave quando o nome da chave de destino não existe.
[Saiba mais](https://valkey.io/commands/renamenx/)
+ `RESTORE`
Cria uma chave a partir da representação serializada de um valor.
[Saiba mais](https://valkey.io/commands/restore/)
+ `SCAN`
Itera os nomes de chaves no banco de dados.
[Saiba mais](https://valkey.io/commands/scan/)
+ `SORT`
Classifica os elementos em uma lista, conjunto ou conjunto classificado, armazenando o resultado como opção.
[Saiba mais](https://valkey.io/commands/sort/)
+ `SORT_RO`
Retorna os elementos classificados de uma lista, um conjunto ou um conjunto classificado.
[Saiba mais](https://valkey.io/commands/sort_ro/)
+ `TOUCH`
Retornará o número de chaves existentes dentre as especificadas depois de atualizar a hora em que foram acessadas pela última vez.
[Saiba mais](https://valkey.io/commands/touch/)
+ `TTL`
Retorna o tempo de expiração de uma chave em segundos.
[Saiba mais](https://valkey.io/commands/ttl/)
+ `TYPE`
Determina o tipo de valor armazenado em uma chave.
[Saiba mais](https://valkey.io/commands/type/)
+ `UNLINK`
Exclui de maneira assíncrona uma ou mais chaves.
[Saiba mais](https://valkey.io/commands/unlink/)
**Comandos geoespaciais**
+ `GEOADD`
Adiciona um ou mais membros a um índice geoespacial. A chave será criada se não existir.
[Saiba mais](https://valkey.io/commands/geoadd/)
+ `GEODIST`
Retorna a distância entre dois membros de um índice geoespacial.
[Saiba mais](https://valkey.io/commands/geodist/)
+ `GEOHASH`
Retorna membros de um índice geoespacial como strings geohash.
[Saiba mais](https://valkey.io/commands/geohash/)
+ `GEOPOS`
Retorna a longitude e a latitude de membros de um índice geoespacial.
[Saiba mais](https://valkey.io/commands/geopos/)
+ `GEORADIUS`
Consulta um índice geoespacial para membros a uma distância de uma coordenada e, como opção, armazena o resultado.
[Saiba mais](https://valkey.io/commands/georadius/)
+ `GEORADIUS_RO`
Retorna membros de um índice geoespacial que estejam a uma distância de uma coordenada.
[Saiba mais](https://valkey.io/commands/georadius_ro/)
+ `GEORADIUSBYMEMBER`
Consulta um índice geoespacial para membros a uma distância de um membro e, como opção, armazena o resultado.
[Saiba mais](https://valkey.io/commands/georadiusbymember/)
+ `GEORADIUSBYMEMBER_RO`
Retorna membros de um índice geoespacial que estejam a uma distância de um membro.
[Saiba mais](https://valkey.io/commands/georadiusbymember_ro/)
+ `GEOSEARCH`
Consulta um índice geoespacial para membros dentro de uma área de uma caixa ou círculo.
[Saiba mais](https://valkey.io/commands/geosearch/)
+ `GEOSEARCHSTORE`
Consulta um índice geoespacial para membros dentro de uma área de uma caixa ou círculo e, como opção, armazena o resultado.
[Saiba mais](https://valkey.io/commands/geosearchstore/)
**Comandos de hash**
+ `HDEL`
Exclui um ou mais campos e os valores de um hash. Exclui o hash se nenhum campo permanecer.
[Saiba mais](https://valkey.io/commands/hdel/)
+ `HEXISTS`
Determina se existe um campo em um hash.
[Saiba mais](https://valkey.io/commands/hexists/)
+ `HGET`
Retorna o valor de um campo em um hash.
[Saiba mais](https://valkey.io/commands/hget/)
+ `HGETALL`
Retorna todos os campos e valores em um hash.
[Saiba mais](https://valkey.io/commands/hgetall/)
+ `HINCRBY`
Incrementa o valor inteiro de um campo em um hash por um número. Usará 0 como valor inicial se o campo não existir.
[Saiba mais](https://valkey.io/commands/hincrby/)
+ `HINCRBYFLOAT`
Incrementa o valor de ponto flutuante de um campo por um número. Usará 0 como valor inicial se o campo não existir.
[Saiba mais](https://valkey.io/commands/hincrbyfloat/)
+ `HKEYS`
Retorna todos os campos em um hash.
[Saiba mais](https://valkey.io/commands/hkeys/)
+ `HLEN`
Retorna o número de chaves em um hash.
[Saiba mais](https://valkey.io/commands/hlen/)
+ `HMGET`
Retorna os valores de todos os campos em um hash.
[Saiba mais](https://valkey.io/commands/hmget/)
+ `HMSET`
Define os valores de vários campos.
[Saiba mais](https://valkey.io/commands/hmset/)
+ `HRANDFIELD`
Retorna um ou mais campos aleatórios de um hash.
[Saiba mais](https://valkey.io/commands/hrandfield/)
+ `HSCAN`
Itera campos e valores de um hash.
[Saiba mais](https://valkey.io/commands/hscan/)
+ `HSET`
Cria ou modifica o valor de um campo em um hash.
[Saiba mais](https://valkey.io/commands/hset/)
+ `HSETNX`
Só define o valor de um campo em um hash quando o campo não existe.
[Saiba mais](https://valkey.io/commands/hsetnx/)
+ `HSTRLEN`
Retorna o tamanho do valor de um campo.
[Saiba mais](https://valkey.io/commands/hstrlen/)
+ `HVALS`
Retorna todos os valores em um hash.
[Saiba mais](https://valkey.io/commands/hvals/)
**HyperLogLog Comandos**
+ `PFADD`
Adiciona elementos a uma HyperLogLog chave. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/pfadd/)
+ `PFCOUNT`
Retorna a cardinalidade aproximada do (s) conjunto (s) observado (s) pela (s) HyperLogLog chave (s).
[Saiba mais](https://valkey.io/commands/pfcount/)
+ `PFMERGE`
Mescla um ou mais HyperLogLog valores em uma única chave.
[Saiba mais](https://valkey.io/commands/pfmerge/)
**Comandos de lista**
+ `BLMOVE`
Extrai um elemento de uma lista, o envia para outra lista e o retorna. Bloqueia até que um elemento esteja disponível de outra forma. Exclui a lista se o último elemento tiver sido movido.
[Saiba mais](https://valkey.io/commands/blmove/)
+ `BLMPOP`
Extrai o primeiro elemento de uma das várias listas. Bloqueia até que um elemento esteja disponível de outra forma. Exclui a lista se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/blmpop/)
+ `BLPOP`
Remove e devolva o primeiro elemento em uma lista. Bloqueia até que um elemento esteja disponível de outra forma. Exclui a lista se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/blpop/)
+ `BRPOP`
Remove e devolva o último elemento em uma lista. Bloqueia até que um elemento esteja disponível de outra forma. Exclui a lista se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/brpop/)
+ `BRPOPLPUSH`
Extrai um elemento de uma lista, o envia para outra lista e o retorna. Bloqueia até que um elemento esteja disponível de outra forma. Exclui a lista se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/brpoplpush/)
+ `LINDEX`
Retorna um elemento de uma lista pelo índice.
[Saiba mais](https://valkey.io/commands/lindex/)
+ `LINSERT`
Insere um elemento antes ou depois de outro elemento em uma lista.
[Saiba mais](https://valkey.io/commands/linsert/)
+ `LLEN`
Retorna o tamanho de uma lista.
[Saiba mais](https://valkey.io/commands/llen/)
+ `LMOVE`
Retorna um elemento depois de extraí-lo de uma lista e enviá-lo para outra. Exclui a lista se o último elemento tiver sido movido.
[Saiba mais](https://valkey.io/commands/lmove/)
+ `LMPOP`
Retornará vários elementos de uma lista depois de removê-los. Exclui a lista se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/lmpop/)
+ `LPOP`
Retornará os primeiros elementos em uma lista depois de removê-la. Exclui a lista se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/lpop/)
+ `LPOS`
Retorna o índice de elementos correspondentes em uma lista.
[Saiba mais](https://valkey.io/commands/lpos/)
+ `LPUSH`
Anexa um ou mais elementos a uma lista. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/lpush/)
+ `LPUSHX`
Só anexa um ou mais elementos a uma lista quando a lista existe.
[Saiba mais](https://valkey.io/commands/lpushx/)
+ `LRANGE`
Retorna um intervalo de elementos de uma lista.
[Saiba mais](https://valkey.io/commands/lrange/)
+ `LREM`
Remove elementos de uma lista. Exclui a lista se o último elemento tiver sido removido.
[Saiba mais](https://valkey.io/commands/lrem/)
+ `LSET`
Define o valor de um elemento em uma lista pelo índice.
[Saiba mais](https://valkey.io/commands/lset/)
+ `LTRIM`
Remove elementos de ambas as extremidades de uma lista. Exclui a lista se todos os elementos tiverem sido cortados.
[Saiba mais](https://valkey.io/commands/ltrim/)
+ `RPOP`
Retorna e remove os últimos elementos de uma lista. Exclui a lista se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/rpop/)
+ `RPOPLPUSH`
Retorna o último elemento de uma lista depois de removê-lo e enviá-lo para outra lista. Exclui a lista se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/rpoplpush/)
+ `RPUSH`
Acrescenta um ou mais elementos a uma lista. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/rpush/)
+ `RPUSHX`
Acrescenta um elemento a uma lista somente quando a lista existe.
[Saiba mais](https://valkey.io/commands/rpushx/)
**Comandos Pub/Sub**
**nota**
Os comandos PUBSUB usam internamente o PUBSUB fragmentado, logo, os nomes de canais serão misturados.
+ `PUBLISH`
Publica uma mensagem em um canal.
[Saiba mais](https://valkey.io/commands/publish/)
+ `PUBSUB CHANNELS`
Retorna os canais ativos.
[Saiba mais](https://valkey.io/commands/pubsub-channels/)
+ `PUBSUB NUMSUB`
Retorna uma contagem de assinantes nos canais.
[Saiba mais](https://valkey.io/commands/pubsub-numsub/)
+ `PUBSUB SHARDCHANNELS`
Retorna os canais de fragmento ativos.
[Saiba mais](https://valkey.io/commands/pubsub-shardchannels/)
+ `PUBSUB SHARDNUMSUB`
Retorna a contagem de assinantes de canais de fragmento.
[Saiba mais](https://valkey.io/commands/pubsub-shardnumsub/)
+ `SPUBLISH`
Publicar uma mensagem em um canal de fragmento
[Saiba mais](https://valkey.io/commands/spublish/)
+ `SSUBSCRIBE`
Recebe mensagens publicadas em canais de fragmento.
[Saiba mais](https://valkey.io/commands/ssubscribe/)
+ `SUBSCRIBE`
Recebe mensagens publicadas em canais publicados.
[Saiba mais](https://valkey.io/commands/subscribe/)
+ `SUNSUBSCRIBE`
Deixa de receber mensagens publicadas em canais de fragmento.
[Saiba mais](https://valkey.io/commands/sunsubscribe/)
+ `UNSUBSCRIBE`
Deixa de receber mensagens publicadas em canais.
[Saiba mais](https://valkey.io/commands/unsubscribe/)
**Comandos de script**
+ `EVAL`
Executa um script Lua do lado do servidor.
[Saiba mais](https://valkey.io/commands/eval/)
+ `EVAL_RO`
Executa um script Lua do lado do servidor somente leitura.
[Saiba mais](https://valkey.io/commands/eval_ro/)
+ `EVALSHA`
Executa um script Lua do lado do servidor por resumo. SHA1
[Saiba mais](https://valkey.io/commands/evalsha/)
+ `EVALSHA_RO`
Executa um script Lua do lado do servidor somente para leitura por digest. SHA1
[Saiba mais](https://valkey.io/commands/evalsha_ro/)
+ `SCRIPT EXISTS`
Determina se os scripts Lua do lado do servidor existem no cache de scripts.
[Saiba mais](https://valkey.io/commands/script-exists/)
+ `SCRIPT FLUSH`
Atualmente, um cache de scripts no-op é gerenciado pelo serviço.
[Saiba mais](https://valkey.io/commands/script-flush/)
+ `SCRIPT LOAD`
Carrega um script Lua do lado do servidor no cache de scripts.
[Saiba mais](https://valkey.io/commands/script-load/)
**Comandos do gerenciamento de clusters**
**nota**
Ao usar ElastiCache clusters baseados em nós para Valkey e Redis OSS, os comandos flush devem ser enviados a cada primário pelo cliente para liberar todas as chaves. ElastiCache O Serverless for Valkey e Redis OSS funciona de forma diferente, pois abstrai a topologia subjacente do cluster. O resultado é que, no ElastiCache Serverless, `FLUSHDB` os `FLUSHALL` comandos sempre liberarão todas as chaves no cluster. Por esse motivo, os comandos de liberação não podem ser incluídos em uma transação com tecnologia sem servidor.
+ `ACL CAT`
Lista as categorias ACL ou os comandos dentro de uma categoria.
[Saiba mais](https://valkey.io/commands/acl-cat/)
+ `ACL GENPASS`
Gera uma senha pseudoaleatória e segura que pode ser usada para identificar usuários ACL.
[Saiba mais](https://valkey.io/commands/acl-genpass/)
+ `ACL GETUSER`
Lista as regras ACL de um usuário.
[Saiba mais](https://valkey.io/commands/acl-getuser/)
+ `ACL LIST`
Despeja as regras efetivas em formato de arquivo ACL.
[Saiba mais](https://valkey.io/commands/acl-list/)
+ `ACL USERS`
Lista todos os usuários ACL.
[Saiba mais](https://valkey.io/commands/acl-users/)
+ `ACL WHOAMI`
Retorna o nome de usuário autenticado da conexão atual.
[Saiba mais](https://valkey.io/commands/acl-whoami/)
+ `DBSIZE`
Retorna o número de chaves no banco de dados selecionado no momento. Não é garantido que essa operação seja atômica em todos os slots.
[Saiba mais](https://valkey.io/commands/dbsize/)
+ `COMMAND`
Retorna informações detalhadas sobre todos os comandos.
[Saiba mais](https://valkey.io/commands/command/)
+ `COMMAND COUNT`
Retorna uma contagem de comandos.
[Saiba mais](https://valkey.io/commands/command-count/)
+ `COMMAND DOCS`
Retorna informações documentais sobre um, vários ou todos os comandos.
[Saiba mais](https://valkey.io/commands/command-docs/)
+ `COMMAND GETKEYS`
Extrai os nomes de chaves de um comando arbitrário.
[Saiba mais](https://valkey.io/commands/command-getkeys/)
+ `COMMAND GETKEYSANDFLAGS`
Extrai os nomes das chaves e os sinalizadores de acesso de um comando arbitrário.
[Saiba mais](https://valkey.io/commands/command-getkeysandflags/)
+ `COMMAND INFO`
Retorna informações sobre um, vários ou todos os comandos.
[Saiba mais](https://valkey.io/commands/command-info/)
+ `COMMAND LIST`
Retorna uma lista de nomes de comando.
[Saiba mais](https://valkey.io/commands/command-list/)
+ `COMMANDLOG`
Um contêiner para comandos de log de comandos.
[Saiba mais](https://valkey.io/commands/commandlog/)
+ `COMMANDLOG GET`
Retorna as entradas do log de comandos especificado.
[Saiba mais](https://valkey.io/commands/commandlog-get/)
+ `COMMANDLOG HELP`
Mostre um texto útil sobre os diferentes subcomandos.
[Saiba mais](https://valkey.io/commands/commandlog-help/)
+ `COMMANDLOG LEN`
Retorna o número de entradas no tipo de log de comandos especificado.
[Saiba mais](https://valkey.io/commands/commandlog-len/)
+ `COMMANDLOG RESET`
Limpa todas as entradas do tipo de log de comandos especificado.
[Saiba mais](https://valkey.io/commands/commandlog-reset/)
+ `FLUSHALL`
Remove todas as chaves de todos os bancos de dados. Não é garantido que essa operação seja atômica em todos os slots.
[Saiba mais](https://valkey.io/commands/flushall/)
+ `FLUSHDB`
Remove todas as chaves do banco de dados atual. Não é garantido que essa operação seja atômica em todos os slots.
[Saiba mais](https://valkey.io/commands/flushdb/)
+ `INFO`
Retorna informações e estatísticas sobre o servidor.
[Saiba mais](https://valkey.io/commands/info/)
+ `LOLWUT`
Exibe arte por computador e a versão do Valkey ou Redis OSS.
[Saiba mais](https://valkey.io/commands/lolwut/)
+ `ROLE`
Retorna a função de replicação.
[Saiba mais](https://valkey.io/commands/role/)
+ `TIME`
Retorna a hora do servidor.
[Saiba mais](https://valkey.io/commands/time/)
**Comandos de conjunto**
+ `SADD`
Adiciona um ou mais membros a um conjunto. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/sadd/)
+ `SCARD`
Retorna o número de membros em um conjunto.
[Saiba mais](https://valkey.io/commands/scard/)
+ `SDIFF`
Retorna a diferença de vários conjuntos.
[Saiba mais](https://valkey.io/commands/sdiff/)
+ `SDIFFSTORE`
Armazena a diferença de vários conjuntos em uma chave.
[Saiba mais](https://valkey.io/commands/sdiffstore/)
+ `SINTER`
Retorna a interseção de vários conjuntos.
[Saiba mais](https://valkey.io/commands/sinter/)
+ `SINTERCARD`
Retorna o número de membros da interseção de vários conjuntos.
[Saiba mais](https://valkey.io/commands/sintercard/)
+ `SINTERSTORE`
Armazena a interseção de vários conjuntos em uma chave.
[Saiba mais](https://valkey.io/commands/sinterstore/)
+ `SISMEMBER`
Determina se um membro pertence a um conjunto.
[Saiba mais](https://valkey.io/commands/sismember/)
+ `SMEMBERS`
Retorna todos os membros de um conjunto.
[Saiba mais](https://valkey.io/commands/smembers/)
+ `SMISMEMBER`
Determina se vários membros pertencem a um conjunto.
[Saiba mais](https://valkey.io/commands/smismember/)
+ `SMOVE`
Move um membro de um conjunto para outro.
[Saiba mais](https://valkey.io/commands/smove/)
+ `SPOP`
Retorna um ou mais membros aleatórios de um conjunto depois de removê-los. Exclui o conjunto se o último membro tiver sido extraído.
[Saiba mais](https://valkey.io/commands/spop/)
+ `SRANDMEMBER`
Obtenha um ou vários membros aleatórios de um conjunto
[Saiba mais](https://valkey.io/commands/srandmember/)
+ `SREM`
Remove um ou mais membros de um conjunto. Exclui o conjunto se o último membro tiver sido removido.
[Saiba mais](https://valkey.io/commands/srem/)
+ `SSCAN`
Itera membros de um conjunto.
[Saiba mais](https://valkey.io/commands/sscan/)
+ `SUNION`
Retorna a união de vários conjuntos.
[Saiba mais](https://valkey.io/commands/sunion/)
+ `SUNIONSTORE`
Armazena a união de vários conjuntos em uma chave.
[Saiba mais](https://valkey.io/commands/sunionstore/)
**Comandos de conjunto classificado**
+ `BZMPOP`
Remove e retorna um membro por pontuação de um ou mais conjuntos classificados. Bloqueia até que um membro esteja disponível de outra forma. Exclui o conjunto classificado se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/bzmpop/)
+ `BZPOPMAX`
Remove e retorna o membro com a pontuação mais alta de um ou mais conjuntos classificados. Bloqueia até que um membro esteja disponível de outra forma. Exclui o conjunto classificado se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/bzpopmax/)
+ `BZPOPMIN`
Remove e retorna o membro com a pontuação mais baixa de um ou mais conjuntos classificados. Bloqueia até que um membro esteja disponível de outra forma. Exclui o conjunto classificado se o último elemento tiver sido extraído.
[Saiba mais](https://valkey.io/commands/bzpopmin/)
+ `ZADD`
Adiciona um ou mais membros a um conjunto classificado ou atualiza as pontuações. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/zadd/)
+ `ZCARD`
Retorna o número de membros em um conjunto classificado.
[Saiba mais](https://valkey.io/commands/zcard/)
+ `ZCOUNT`
Retorna a contagem de membros em um conjunto classificado que tenham pontuações dentro de um intervalo.
[Saiba mais](https://valkey.io/commands/zcount/)
+ `ZDIFF`
Retorna a diferença entre vários conjuntos classificados.
[Saiba mais](https://valkey.io/commands/zdiff/)
+ `ZDIFFSTORE`
‘Armazena a diferença de vários conjuntos classificados em uma chave.
[Saiba mais](https://valkey.io/commands/zdiffstore/)
+ `ZINCRBY`
Incrementa a pontuação de um membro em um conjunto classificado.
[Saiba mais](https://valkey.io/commands/zincrby/)
+ `ZINTER`
Retorna a interseção de vários conjuntos classificados.
[Saiba mais](https://valkey.io/commands/zinter/)
+ `ZINTERCARD`
Retorna o número de membros da interseção de vários conjuntos classificados.
[Saiba mais](https://valkey.io/commands/zintercard/)
+ `ZINTERSTORE`
Armazena a interseção de vários conjuntos classificados em uma chave.
[Saiba mais](https://valkey.io/commands/zinterstore/)
+ `ZLEXCOUNT`
Retorna o número de membros em um conjunto classificado dentro de um intervalo lexicográfico.
[Saiba mais](https://valkey.io/commands/zlexcount/)
+ `ZMPOP`
Retorna os membros com maior ou menor pontuação de um ou mais conjuntos classificados depois de removê-los. Exclui o conjunto classificado se o último membro tiver sido extraído.
[Saiba mais](https://valkey.io/commands/zmpop/)
+ `ZMSCORE`
Retorna a pontuação de um ou mais membros em um conjunto classificado.
[Saiba mais](https://valkey.io/commands/zmscore/)
+ `ZPOPMAX`
Retorna os membros com maior pontuação de um conjunto classificado depois de removê-los. Exclui o conjunto classificado se o último membro tiver sido extraído.
[Saiba mais](https://valkey.io/commands/zpopmax/)
+ `ZPOPMIN`
Retorna os membros com menor pontuação de um conjunto classificado depois de removê-los. Exclui o conjunto classificado se o último membro tiver sido extraído.
[Saiba mais](https://valkey.io/commands/zpopmin/)
+ `ZRANDMEMBER`
Retorna um ou mais membros aleatórios de um conjunto classificado.
[Saiba mais](https://valkey.io/commands/zrandmember/)
+ `ZRANGE`
Retorna membros em um conjunto classificado dentro de um intervalo de índices.
[Saiba mais](https://valkey.io/commands/zrange/)
+ `ZRANGEBYLEX`
Retorna membros em um conjunto classificado dentro de um intervalo lexicográfico.
[Saiba mais](https://valkey.io/commands/zrangebylex/)
+ `ZRANGEBYSCORE`
Retorna membros em um conjunto classificado dentro de um intervalo de índices.
[Saiba mais](https://valkey.io/commands/zrangebyscore/)
+ `ZRANGESTORE`
Armazena um intervalo de membros do conjunto classificado em uma chave.
[Saiba mais](https://valkey.io/commands/zrangestore/)
+ `ZRANK`
Retorna o índice de um membro em um conjunto classificado ordenado por pontuações crescentes.
[Saiba mais](https://valkey.io/commands/zrank/)
+ `ZREM`
Remove um ou mais membros de um conjunto classificado. Exclui o conjunto classificado se todos os membros tiverem sido removidos.
[Saiba mais](https://valkey.io/commands/zrem/)
+ `ZREMRANGEBYLEX`
Remove membros em um conjunto classificado dentro de um intervalo lexicográfico. Exclui o conjunto classificado se todos os membros tiverem sido removidos.
[Saiba mais](https://valkey.io/commands/zremrangebylex/)
+ `ZREMRANGEBYRANK`
Remove membros em um conjunto classificado dentro de um intervalo de índices. Exclui o conjunto classificado se todos os membros tiverem sido removidos.
[Saiba mais](https://valkey.io/commands/zremrangebyrank/)
+ `ZREMRANGEBYSCORE`
Remove membros em um conjunto classificado dentro de um intervalo de pontuações. Exclui o conjunto classificado se todos os membros tiverem sido removidos.
[Saiba mais](https://valkey.io/commands/zremrangebyscore/)
+ `ZREVRANGE`
Retorna membros em um conjunto classificado dentro de um intervalo de índices em ordem inversa.
[Saiba mais](https://valkey.io/commands/zrevrange/)
+ `ZREVRANGEBYLEX`
Retorna membros em um conjunto classificado dentro de um intervalo lexicográfico em ordem inversa.
[Saiba mais](https://valkey.io/commands/zrevrangebylex/)
+ `ZREVRANGEBYSCORE`
Retorna membros em um conjunto classificado dentro de um intervalo de classificações em ordem inversa.
[Saiba mais](https://valkey.io/commands/zrevrangebyscore/)
+ `ZREVRANK`
Retorna o índice de um membro em um conjunto classificado ordenado por pontuações decrescentes.
[Saiba mais](https://valkey.io/commands/zrevrank/)
+ `ZSCAN`
Itera membros e pontuações de um conjunto classificado.
[Saiba mais](https://valkey.io/commands/zscan/)
+ `ZSCORE`
Retorna a pontuação de um membro em um conjunto classificado.
[Saiba mais](https://valkey.io/commands/zscore/)
+ `ZUNION`
Retorna a união de vários conjuntos classificados.
[Saiba mais](https://valkey.io/commands/zunion/)
+ `ZUNIONSTORE`
Armazena a união de vários conjuntos classificados em uma chave.
[Saiba mais](https://valkey.io/commands/zunionstore/)
**Comandos de fluxo**
+ `XACK`
Retorna o número de mensagens que foram confirmadas com êxito pelo membro do grupo de consumidores de um fluxo.
[Saiba mais](https://valkey.io/commands/xack/)
+ `XADD`
Acrescenta uma nova mensagem a um fluxo. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/xadd/)
+ `XAUTOCLAIM`
Altera, ou adquire, a propriedade de mensagens em um grupo de consumidores, como se as mensagens tivessem sido entregues como membro do grupo de consumidores.
[Saiba mais](https://valkey.io/commands/xautoclaim/)
+ `XCLAIM`
Altera, ou adquire, a propriedade de uma mensagem em um grupo de consumidores, como se a mensagem tivesse sido entregue como membro do grupo de consumidores.
[Saiba mais](https://valkey.io/commands/xclaim/)
+ `XDEL`
Retorna o número de mensagens depois de removê-las de um fluxo.
[Saiba mais](https://valkey.io/commands/xdel/)
+ `XGROUP CREATE`
Cria um grupo de consumidores.
[Saiba mais](https://valkey.io/commands/xgroup-create/)
+ `XGROUP CREATECONSUMER`
Cria um consumidor em um grupo de consumidores.
[Saiba mais](https://valkey.io/commands/xgroup-createconsumer/)
+ `XGROUP DELCONSUMER`
Exclui um consumidor de um grupo de consumidores.
[Saiba mais](https://valkey.io/commands/xgroup-delconsumer/)
+ `XGROUP DESTROY`
Destrói um grupo de consumidores.
[Saiba mais](https://valkey.io/commands/xgroup-destroy/)
+ `XGROUP SETID`
Define o ID entregue mais recentemente de um grupo de consumidores.
[Saiba mais](https://valkey.io/commands/xgroup-setid/)
+ `XINFO CONSUMERS`
Retorna uma lista dos consumidores em um grupo de consumidores.
[Saiba mais](https://valkey.io/commands/xinfo-consumers/)
+ `XINFO GROUPS`
Retorna uma lista dos grupos de consumidores de um fluxo.
[Saiba mais](https://valkey.io/commands/xinfo-groups/)
+ `XINFO STREAM`
Retorna informações sobre um fluxo.
[Saiba mais](https://valkey.io/commands/xinfo-stream/)
+ `XLEN`
Retorna o número de mensagens em um fluxo.
[Saiba mais](https://valkey.io/commands/xlen/)
+ `XPENDING`
Retorna as informações e as entradas da lista de entradas pendentes de um grupo de consumidores do fluxo.
[Saiba mais](https://valkey.io/commands/xpending/)
+ `XRANGE`
Retorna as mensagens de um fluxo dentro de um intervalo de IDs.
[Saiba mais](https://valkey.io/commands/xrange/)
+ `XREAD`
Retorna mensagens de vários fluxos com IDs mais do que as solicitadas. Bloqueia até que uma mensagem esteja disponível de outra forma.
[Saiba mais](https://valkey.io/commands/xread/)
+ `XREADGROUP`
Retorna mensagens novas ou históricas de um fluxo para um consumidor em um grupo. Bloqueia até que uma mensagem esteja disponível de outra forma.
[Saiba mais](https://valkey.io/commands/xreadgroup/)
+ `XREVRANGE`
Retorna as mensagens de um fluxo dentro de um intervalo de IDs na ordem inversa.
[Saiba mais](https://valkey.io/commands/xrevrange/)
+ `XTRIM`
Exclui mensagens do início de um fluxo.
[Saiba mais](https://valkey.io/commands/xtrim/)
**Comandos de string**
+ `APPEND`
Acrescenta uma string ao valor de uma chave. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/append/)
+ `DECR`
Diminui o valor inteiro de uma chave em um. Usará 0 como valor inicial se a chave não existir.
[Saiba mais](https://valkey.io/commands/decr/)
+ `DECRBY`
Diminui um número do valor inteiro de uma chave. Usará 0 como valor inicial se a chave não existir.
[Saiba mais](https://valkey.io/commands/decrby/)
+ `GET`
Retorna o valor da string de uma chave.
[Saiba mais](https://valkey.io/commands/get/)
+ `GETDEL`
Retorna o valor da string de uma chave depois de excluir a chave.
[Saiba mais](https://valkey.io/commands/getdel/)
+ `GETEX`
Retorna o valor da string de uma chave depois de definir o tempo de expiração.
[Saiba mais](https://valkey.io/commands/getex/)
+ `GETRANGE`
Retorna uma substring da string armazenada em uma chave.
[Saiba mais](https://valkey.io/commands/getrange/)
+ `GETSET`
Retorna o valor da string anterior de uma chave depois de defini-la como um novo valor.
[Saiba mais](https://valkey.io/commands/getset/)
+ `INCR`
Incrementa o valor inteiro de uma chave em um. Usará 0 como valor inicial se a chave não existir.
[Saiba mais](https://valkey.io/commands/incr/)
+ `INCRBY`
Incrementa o valor inteiro de uma chave por um número. Usará 0 como valor inicial se a chave não existir.
[Saiba mais](https://valkey.io/commands/incrby/)
+ `INCRBYFLOAT`
Incrementa o valor de ponto flutuante de uma chave por um número. Usará 0 como valor inicial se a chave não existir.
[Saiba mais](https://valkey.io/commands/incrbyfloat/)
+ `LCS`
Encontra a substring comum mais longa.
[Saiba mais](https://valkey.io/commands/lcs/)
+ `MGET`
Retorna atomicamente os valores de string de uma ou mais chaves.
[Saiba mais](https://valkey.io/commands/mget/)
+ `MSET`
Cria ou modifica atomicamente os valores de string de uma ou mais chaves.
[Saiba mais](https://valkey.io/commands/mset/)
+ `MSETNX`
Só modifica atomicamente os valores de string de uma ou mais chaves quando todas as chaves não existem.
[Saiba mais](https://valkey.io/commands/msetnx/)
+ `PSETEX`
Define o valor de string e o tempo de expiração de uma chave em milissegundos. A chave será criada se não existir.
[Saiba mais](https://valkey.io/commands/psetex/)
+ `SET`
Define o valor de string de uma chave, ignorando o tipo. A chave será criada se não existir.
[Saiba mais](https://valkey.io/commands/set/)
+ `SETEX`
Define o valor de string e o tempo de expiração de uma chave. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/setex/)
+ `SETNX`
Só define o valor de string de uma chave quando a chave não existir.
[Saiba mais](https://valkey.io/commands/setnx/)
+ `SETRANGE`
Substitui uma parte do valor de uma string por outra por um deslocamento. Cria a chave, caso ela não exista.
[Saiba mais](https://valkey.io/commands/setrange/)
+ `STRLEN`
Retorna o tamanho do valor de uma string.
[Saiba mais](https://valkey.io/commands/strlen/)
+ `SUBSTR`
Retorna uma substring de um valor de string.
[Saiba mais](https://valkey.io/commands/substr/)
**Comandos de transação**
+ `DISCARD`
Descarta uma transação.
[Saiba mais](https://valkey.io/commands/discard/)
+ `EXEC`
Executa todos os comandos em uma transação.
[Saiba mais](https://valkey.io/commands/exec/)
+ `MULTI`
Inicia uma transação.
[Saiba mais](https://valkey.io/commands/multi/)
## Comandos restritos do Valkey e do Redis OSS
Para oferecer uma experiência de serviço gerenciado, ElastiCache restringe o acesso a determinados comandos específicos do mecanismo de cache que exigem privilégios avançados. Para caches executando o Redis OSS, os seguintes comandos não estão disponíveis:
+ `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`
Além disso, os seguintes comandos não estão disponíveis para caches sem servidor:
+ `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`
## Comandos do Memcached compatíveis
ElastiCache O Serverless for Memcached oferece suporte a todos os [comandos](https://github.com/memcached/memcached/wiki/Commands) memcached no memcached 1.6 de código aberto, exceto os seguintes:
+ Como as conexões cliente exigem TLS, o protocolo UDP não é compatível.
+ O protocolo binário não é compatível, pois está oficialmente [obsoleto](https://github.com/memcached/memcached/wiki/ReleaseNotes160) no memcached 1.6.
+ Os comandos `GET/GETS` são limitados a 16 KB para evitar possíveis ataques de DoS ao servidor com a busca de um grande número de chaves.
+ O comando `flush_all` atrasado será rejeitado com `CLIENT_ERROR`.
+ Comandos que configuram o mecanismo ou revelam informações internas sobre o estado ou os logs do mecanismo não são compatíveis, como:
+ Para comando `STATS`, só `stats` e `stats reset` são compatíveis. Outras variações vão retornar `ERROR`
+ `lru / lru_crawler`: modificação das configurações de crawler LRU e LRU
+ `watch`: observa os logs de servidor do memcached
+ `verbosity`: configura o nível de log do servidor
+ `me`: o comando meta debug (me) não é compatível
# Configuração e limites do Valkey e Redis OSS
Cada um dos mecanismos Valkey e Redis OSS fornece vários parâmetros de configuração, alguns dos quais são modificáveis no Redis OSS e outros não são modificáveis ElastiCache para fornecer desempenho e confiabilidade estáveis.
## Caches sem servidor
Para caches de tecnologia sem servidor, grupos de parâmetros não são usados e todas as configurações do Valkey e do Redis OSS não são modificáveis. Os seguintes parâmetros do Valkey e do Redis OSS estão em vigor:
****
| Nome | Detalhes | Description |
| --- | --- | --- |
| acl-pubsub-default | `allchannels` | Permissões de canal pubsub padrão para usuários ACL no cache. |
| client-output-buffer-limit | `normal 0 0 0` `pubsub 32mb 8mb 60` | Clientes normais não têm limite de buffer. PUB/SUB os clientes serão desconectados se violarem o backlog de 32 MiB ou violarem o backlog de 8 MiB por 60s. |
| client-query-buffer-limit | 15 GiB | O tamanho máximo de um único buffer de consulta do cliente. Além disso, os clientes não podem emitir uma solicitação com mais de 3.999 argumentos. |
| cluster-allow-pubsubshard-when-down | yes | Isso permite que o cache ofereça tráfego pubsub enquanto o cache está parcialmente inativo. |
| cluster-allow-reads-when-down | yes | Isso permite que o cache ofereça tráfego de leitura enquanto o cache está parcialmente inativo. |
| cluster-enabled | yes | Todos os caches sem servidor estão habilitados para o modo de cluster, o que permite particionar os dados de maneira transparente em vários fragmentos de back-end. Todos os slots são apresentados aos clientes como pertencentes a um único nó virtual. |
| cluster-require-full-coverage | no | Quando o espaço de chaves estiver parcialmente inativo (ou seja, pelo menos um slot de hash estiver inacessível), o cache continuará aceitando consultas para a parte do espaço de chaves que ainda está coberta. Todo o espaço de chaves sempre será “coberto” por um único nó virtual em cluster slots. |
| lua-time-limit | 5000 | O tempo máximo de execução de um script Lua, em milissegundos, antes de ElastiCache agir para interromper o script. Se `lua-time-limit` for excedido, todos os comandos do Valkey e do Redis OSS poderão retornar um erro no formato *\$1\$1\$1\$1-BUSY*. Como esse estado pode causar interferência em muitas operações essenciais do Valkey ou do Redis OSS, primeiro ElastiCache emitirá um comando *SCRIPT* KILL. Se isso não for bem-sucedido, ElastiCache reiniciará forçosamente o Valkey ou o Redis OSS. |
| maxclients | 65000 | O número máximo de clientes que podem ser conectados ao cache ao mesmo tempo. Mais conexões estabelecidas podem ou não ser bem-sucedidas. |
| maxmemory-policy | volatile-lru | Os itens com um conjunto TTL são despejados após a estimativa least-recently-used (LRU) quando o limite de memória do cache é atingido. |
| notify-keyspace-events | (uma string vazia) | No momento, os eventos do espaço de chaves não são compatíveis com caches sem servidor. |
| port | Porta primária: 6379 Porta de leitura: 6380 | Os caches sem servidor anunciam duas portas com o mesmo nome de host. A porta primária permite gravações e leituras, e a porta de leitura permite leituras finais consistentes de latência mais baixa usando o comando READONLY. |
| proto-max-bulk-len | 50 MiB | O tamanho máximo de uma única solicitação de elemento. |
| timeout | 0 | Os clientes não são desconectados de maneira forçada em um tempo de inatividade específico, mas podem ser desconectados durante o estado estacionário para fins de balanceamento de carga. |
Além disso, os seguintes limites estão em vigor:
****
| Nome | Detalhes | Description |
| --- | --- | --- |
| Tamanho por cache | 5.000 GiB | Quantidade máxima de dados que podem ser armazenados por cache com tecnologia sem servidor. |
| Tamanho por slot | 32 GiB | O tamanho máximo de um único slot de hash do Valkey ou Redis OSS. Os clientes que tentarem definir mais dados do que isso em um único slot do Valkey ou Redis OSS vão disparar a política de remoção no slot e, se nenhuma chave for removível, receberão um erro de falta de memória (OOM). |
| ECPU por cache | 15.000.000 ECPU/segundo | ElastiCache Métrica de unidades de processamento (ECPU). O número de solicitações ECPUs consumidas por suas solicitações depende do tempo gasto pela vCPU e da quantidade de dados transferidos. |
| ECPU por slot | 30K - 90K ECPU/segundo | Máximo de 30K ECPUs/second por slot ou 90K ECPUs/second ao usar Read from Replica usando conexões READONLY. |
| Argumentos por solicitação | 3.999 | Número máximo de argumentos por solicitação. Os clientes que fizerem mais argumentos por solicitação receberão um erro. |
| Tamanho do nome da chave | 8 KiB | O tamanho máximo de uma única chave do Valkey ou do Redis OSS ou nome de canal. Os clientes que fizerem referência a chaves maiores do que isso receberão um erro. |
| Tamanho do script Lua | 50 MiB | O tamanho máximo de um único script Lua do Valkey ou Redis OSS. As tentativas de carregar um script Lua maior do que isso receberão um erro. |
## Clusters baseados em nós
Para clusters baseados em nós, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis) em busca dos valores padrão dos parâmetros de configuração e quais são configuráveis. Os valores padrão costumam ser recomendados, a menos que você tenha um caso de uso específico que exija que eles sejam substituídos.
# Exemplos de clientes IPv6 para Valkey, Memcached e Redis OSS
O ElastiCache é compatível com Valkey, Memcached e Redis OSS. Isso significa que os clientes que aceitam conexões IPv6 devem conseguir se conectar a clusters do ElastiCache para Memcached habilitados para IPv6. Há algumas ressalvas que vale a pena observar ao interagir com recursos habilitados para IPv6.
Você pode ver a publicação [Práticas recomendadas para clientes Valkey e Redis](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) no blog de banco de dados da AWS para obter recomendações sobre como configurar clientes Valkey e Redis OSS para recursos do ElastiCache.
Veja a seguir as práticas recomendadas para interagir com recursos do ElastiCache habilitados para IPv6 com bibliotecas de cliente de código aberto comumente usadas.
## Clientes validados com Valkey e Redis OSS
O ElastiCache é compatível com o Valkey e com o Redis OSS de código aberto. Isso significa que os clientes Redis OSS de código aberto e Valkey que oferecem suporte a conexões IPv6 devem conseguir se conectar a clusters do ElastiCache para Redis OSS habilitados para IPv6. Além disso, vários dos clientes Python e Java mais populares foram especificamente testados e validados para funcionar com todas as configurações de tipo de rede compatíveis (somente IPv4, somente IPv6 e pilha dupla)
Os clientes a seguir foram validados especificamente para funcionar com todas as configurações de tipo de rede compatíveis com o Valkey e o Redis OSS.
Clientes validados:
+ [Redis Py ()](https://github.com/redis/redis-py) – [4.1.2](https://github.com/redis/redis-py/tree/v4.1.2)
+ [Lettuce](https://lettuce.io/) – [Version: 6.1.6.RELEASE](https://github.com/lettuce-io/lettuce-core/tree/6.1.6.RELEASE)
+ [Jedis](https://github.com/redis/jedis) – [Versão: 3.6.0](https://github.com/redis/jedis/tree/jedis-3.6.0)
# Práticas recomendadas para clientes (Valkey e Redis OSS)
Aprenda as práticas recomendadas para cenários comuns e acompanhe exemplos de código de algumas das bibliotecas de cliente Valkey e Redis OSS de código aberto mais populares (redis-py, PHPRedis e Lettuce), bem como as práticas recomendadas para interagir com recursos do ElastiCache com bibliotecas de cliente Memcached de código aberto comumente usadas.
**Topics**
+ [Grande número de conexões (Valkey e Redis OSS)](BestPractices.Clients.Redis.Connections.md)
+ [Descoberta de cliente do cluster e recuo exponencial (Valkey e Redis OSS)](BestPractices.Clients.Redis.Discovery.md)
+ [Configurar um tempo limite do lado do cliente (Valkey e Redis OSS)](BestPractices.Clients.Redis.ClientTimeout.md)
+ [Configurar um tempo limite de inatividade do lado do servidor (Valkey e Redis OSS)](BestPractices.Clients.Redis.ServerTimeout.md)
+ [Scripts Lua](BestPractices.Clients.Redis.LuaScripts.md)
+ [Armazenamento de itens compostos grandes (Valkey e Redis OSS)](BestPractices.Clients.Redis.LargeItems.md)
+ [Configuração do cliente do Lettuce (Valkey e Redis OSS)](BestPractices.Clients-lettuce.md)
+ [Configurar um protocolo preferencial para clusters de pilha dupla (Valkey e Redis OSS)](#network-type-configuring-dual-stack-redis)
# Grande número de conexões (Valkey e Redis OSS)
Caches com tecnologia sem servidor e nós do ElastiCache para Redis OSS individuais dão suporte a até 65 mil conexões de cliente simultâneas. No entanto, para otimizar o desempenho, recomendamos que as aplicações cliente não funcionem de maneira constante nesse nível de conexões. O Valkey e o Redis OSS têm um processo de thread único baseado em um loop de eventos no qual as solicitações de cliente recebidas são processadas sequencialmente. Isso significa que o tempo de resposta de um determinado cliente aumenta à medida que o número de clientes conectados aumenta.
É possível realizar o seguinte conjunto de ações para evitar um gargalo de conexões em um servidor Valkey ou Redis OSS:
+ Realize operações de leitura a partir das réplicas de leitura. Isso pode ser feito usando-se os endpoints de leitor do ElastiCache em modo cluster desabilitado ou usando réplicas para leituras em modo de cluster habilitado, inclusive um cache sem servidor.
+ Distribua tráfego de gravação em vários nós primários. É possível fazer isso de duas maneiras. É possível usar um cluster multifragmentado do Valkey ou Redis OSS com um cliente compatível com o modo cluster. Também é possível gravar em vários nós primários em modo de cluster desabilitado com fragmentação do lado do cliente. Isso é feito automaticamente em um cache sem servidor.
+ Use um pool de conexões quando disponível na biblioteca cliente.
Em geral, criar uma conexão TCP é uma operação cara em termos computacionais em comparação com os comandos típicos do Valkey ou Redis OSS. Por exemplo, lidar com uma solicitação SET/GET é uma ordem de magnitude mais rápida ao reutilizar uma conexão existente. O uso de um pool de conexões de clientes com um tamanho finito reduz a sobrecarga do gerenciamento de conexões. Isso também limita o número de conexões de entrada simultâneas da aplicação cliente.
O seguinte exemplo de código do PHPRedis mostra que uma nova conexão é criada para cada nova solicitação do usuário:
```
$redis = new Redis();
if ($redis->connect($HOST, $PORT) != TRUE) {
//ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
Comparamos esse código em um loop em uma instância do Amazon Elastic Compute Cloud (Amazon EC2) conectada a um nó Graviton2 (m6g.2xlarge) do ElastiCache para o Redis OSS. Colocamos o cliente e o servidor na mesma zona de disponibilidade. A latência média de toda a operação foi de 2,82 milissegundos.
Quando atualizamos o código e usamos conexões persistentes e um pool de conexões, a latência média de toda a operação foi de 0,21 milissegundo:
```
$redis = new Redis();
if ($redis->pconnect($HOST, $PORT) != TRUE) {
// ERROR: connection failed
return;
}
$redis->set($key, $value);
unset($redis);
$redis = NULL;
```
Configurações de redis.ini necessárias:
+ `redis.pconnect.pooling_enabled=1`
+ `redis.pconnect.connection_limit=10`
O seguinte código é um exemplo de um [pool de conexões do Redis-py](https://redis.readthedocs.io/en/stable/):
```
conn = Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
conn.set(key, value)
```
O seguinte código é um exemplo de um [pool de conexões do 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);
}
```
# Descoberta de cliente do cluster e recuo exponencial (Valkey e Redis OSS)
Ao se conectar a um cluster do ElastiCache Valkey ou Redis OSS em modo cluster habilitado, a biblioteca cliente correspondente deve estar ciente do cluster. Os clientes devem obter um mapa dos slots de hash para os nós correspondentes no cluster para enviar solicitações aos nós certos e evitar a sobrecarga de desempenho de processar redirecionamentos de cluster. Dessa forma, o cliente deve descobrir uma lista completa de slots e dos nós mapeados em duas situações diferentes:
+ O cliente é inicializado e deve preencher a configuração de slots inicial
+ Um redirecionamento MOVED é recebido do servidor, como na situação de um failover, quando todos os slots atendidos pelo nó primário anterior são assumidos pela réplica, ou de refragmentação quando slots são movidos do nó primário de origem para o nó primário de destino
A descoberta de cliente costuma ser feita por meio da emissão de um comando CLUSTER SLOT ou CLUSTER NODE para o servidor Valkey ou Redis OSS. Recomendamos o método CLUSTER SLOT porque ele retorna o conjunto de intervalos de slots e os nós primários e de réplica reassociados ao cliente. Isso não exige análise adicional do cliente e é mais eficiente.
Dependendo da topologia do cluster, o tamanho da resposta para o comando CLUSTER SLOT pode variar com base no tamanho do cluster. Clusters maiores com mais nós produzem uma resposta maior. Assim, é importante garantir que o número de clientes que fazem a descoberta da topologia do cluster não cresça de maneira ilimitada. Por exemplo, quando a aplicação cliente é inicializada ou perde a conexão do servidor e precisa realizar a descoberta de cluster, um erro comum é que a aplicação cliente dispara várias solicitações de reconexão e descoberta sem adicionar um recuo exponencial ao tentar novamente. Isso pode fazer o servidor Valkey ou Redis OSS não responder por um período prolongado, com a utilização da CPU em 100%. A interrupção será prolongada se cada comando CLUSTER SLOT precisar processar um número grande de nós no barramento do cluster. Observamos várias interrupções de cliente por causa desse comportamento em várias linguagens diferentes, inclusive Python (redis-py-cluster) e Java (Lettuce e Redisson).
Em um cache sem servidor, muitos dos problemas são atenuados automaticamente porque a topologia do cluster anunciada é estática e consiste em duas entradas: um endpoint de gravação e um endpoint de leitura. A descoberta de cluster também é distribuída automaticamente por vários nós durante o uso do endpoint de cache. No entanto, as recomendações a seguir continuam sendo úteis.
Para mitigar o impacto causado por um fluxo repentino de solicitações de conexão e descoberta, recomendamos o seguinte:
+ Implemente um pool de conexões do cliente com um tamanho finito para limitar o número de conexões de entrada simultâneas da aplicação cliente.
+ Quando o cliente se desconectar do servidor por causa do tempo limite, tente novamente com recuo exponencial com instabilidade. Isso ajuda a evitar que vários clientes sobrecarreguem o servidor ao mesmo tempo.
+ Use o guia em [Encontrar endpoints de conexão no ElastiCache](Endpoints.md) para encontrar o endpoint do cluster a fim de realizar a descoberta do cluster. Ao fazer isso, você distribui a carga de descoberta em todos os nós do cluster (até 90) em vez de atingir alguns nós propagados codificados no cluster.
Estes são alguns exemplos de código para a lógica de nova tentativa de recuo exponencial em redis-py, phpRedis e Lettuce.
**Exemplo 1 da lógica de recuo: redis-py**
O redis-py tem um mecanismo de nova tentativa integrado repetido uma vez logo depois de uma falha. Esse mecanismo pode ser habilitado por meio do argumento `retry_on_timeout` fornecido ao criar um objeto do [Redis OSS](https://redis.readthedocs.io/en/stable/examples/connection_examples.html#redis.Redis). Aqui, demonstramos um mecanismo de nova tentativa personalizado com recuo exponencial e instabilidade. Enviamos uma solicitação pull para implementar nativamente o recuo exponencial em [redis-py (\$11494)](https://github.com/andymccurdy/redis-py/pull/1494). No futuro, talvez não seja necessário implementar 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
```
É possível acabar usando o seguinte código para definir um valor:
```
client = redis.Redis(connection_pool=redis.BlockingConnectionPool(host=HOST, max_connections=10))
res = run_with_backoff(lambda: client.set("key", "value"))
print(res)
```
Dependendo da workload, talvez você queira alterar o valor de recuo base de 1 segundo para algumas dezenas ou centenas de milissegundos para workloads sensíveis à latência.
**Exemplo 2 da lógica de recuo: PHPRedis**
O PHPRedis tem um mecanismo de nova tentativa integrado que repete um máximo (não configurável) de dez vezes. Há um atraso configurável entre as tentativas (com uma instabilidade a partir da segunda tentativa). Para obter mais informações, consulte o [código de exemplo](https://github.com/phpredis/phpredis/blob/b0b9dd78ef7c15af936144c1b17df1a9273d72ab/library.c#L335-L368). Enviamos uma solicitação pull para implementar nativamente o recuo exponencial em [phpRedis (\$11986)](https://github.com/phpredis/phpredis/pull/1986), que já foi mesclado e [documentado](https://github.com/phpredis/phpredis/blob/develop/README.md#retry-and-backoff). Para aqueles que estão na versão mais recente do PHPRedis, não será necessário implementar manualmente, mas incluímos aqui a referência para aqueles nas versões anteriores. Por enquanto, este é um exemplo de código que configura o atraso do mecanismo de nova tentativa:
```
$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);
```
**Exemplo 3 da lógica de recuo: Lettuce**
O Lettuce tem mecanismos de nova tentativa integrados com base nas estratégias de recuo exponencial baseado na publicação [Recuo exponencial e instabilidade](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/). Este é um trecho de código que mostra a abordagem de instabilidade completa:
```
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();
}
}
}
```
# Configurar um tempo limite do lado do cliente (Valkey e Redis OSS)
**Configuração do tempo limite do lado do cliente**
Configure devidamente o tempo limite do lado do cliente a fim de permitir que o servidor tenha tempo suficiente para processar a solicitação e gerar a resposta. Isso também permitirá antecipar-se à falha se a conexão com o servidor não puder ser estabelecida. Determinados comandos do Valkey ou Redis OSS podem ser mais caros do que outros em termos computacionais. Por exemplo, scripts Lua ou transações MULTI/EXEC que contenham vários comandos que devem ser executados de maneira atômica. Em geral, um tempo limite do lado do cliente maior é recomendado para evitar um tempo limite do cliente antes que a resposta seja recebida do servidor, inclusive o seguinte:
+ Execução de comandos em várias teclas
+ Execução de transações MULTI/EXEC ou scripts Lua que consistem em vários comandos individuais do Valkey ou Redis OSS
+ Leitura de valores grandes
+ Realização de operações de bloqueio, como BLPOP
No caso de uma operação de bloqueio, como BLPOP, a prática recomendada é definir o tempo limite do comando como um número menor que o tempo limite do soquete.
Estes são exemplos de código para implementar um tempo limite do lado do cliente em redis-py, PHPRedis e Lettuce.
**Exemplo 1 de configuração do tempo limite: redis-py**
Este é um exemplo de código com 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)
```
**Exemplo 2 de configuração do tempo limite: PHPRedis**
Este é um exemplo de código com 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
```
**Exemplo 3 de configuração do tempo limite: Lettuce**
Este é um exemplo de código com 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();
}
}
}
```
# Configurar um tempo limite de inatividade do lado do servidor (Valkey e Redis OSS)
Observamos casos nos quais a aplicação de um cliente tem um grande número de clientes ociosos conectados, mas não está enviando comandos ativamente. Nesses cenários, você pode esgotar todas as 65.000 conexões com um grande número de clientes inativos. Para evitar esses cenários, defina a configuração de tempo limite da maneira indicada no servidor por meio de [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis). Isso garante que o servidor desconecte ativamente os clientes ociosos para evitar um aumento no número de conexões. Essa configuração não está disponível em caches sem servidor.
# Scripts Lua
O Valkey e o Redis OSS aceitam mais de 200 comandos, inclusive aqueles para executar scripts Lua. No entanto, quando o assunto são scripts Lua, existem diversas armadilhas que podem afetar a memória e a disponibilidade do Valkey ou do Redis OSS.
**Scripts Lua não parametrizados**
Cada script Lua é armazenado em cache no servidor Valkey ou Redis OSS antes de ser executado. Os scripts Lua não parametrizados são exclusivos, o que pode fazer com que o servidor Valkey ou Redis OSS armazene um número grande de scripts Lua e consuma mais memória. Para mitigar isso, certifique-se de que todos os scripts Lua estejam parametrizados e execute regularmente o SCRIPT FLUSH para limpar scripts Lua em cache, se necessário.
Também esteja ciente de que as chaves devem ser fornecidas. Se um valor para o parâmetro KEY não for fornecido, o script falhará. Por exemplo, o seguinte não funciona:
```
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.
```
Isso funcionará:
```
serverless-test-lst4hg.serverless.use1.cache.amazonaws.com:6379> eval 'return redis.call("get", KEYS[1])' 1 mykey-2
"myvalue-2"
```
O exemplo a seguir mostra como usar scripts parametrizados: Primeiro, temos um exemplo de uma abordagem não parametrizada que resulta em três scripts Lua em cache diferentes e não é recomendada:
```
eval "return redis.call('set','key1','1')" 0
eval "return redis.call('set','key2','2')" 0
eval "return redis.call('set','key3','3')" 0
```
Em vez disso, use o seguinte padrão para criar um único script capaz de aceitar parâmetros passados:
```
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
```
**Scripts Lua de longa duração**
Os scripts Lua podem executar vários comandos atomicamente, logo, podem demorar mais para serem concluídos do que um comando normal do Valkey ou Redis OSS. Se o script Lua só executar operações somente leitura, você poderá pará-lo no meio. No entanto, assim que executa uma operação de gravação, o script Lua se torna imortal e deve ser executado até a conclusão. Um script Lua de longa execução que esteja sofrendo mutação pode fazer com que o servidor Valkey ou Redis OSS deixe de responder por um longo tempo. Para mitigar esse problema, evite scripts Lua de longa duração e teste o script em um ambiente de pré-produção.
**Script Lua com gravações furtivas**
Existem algumas maneiras pelas quais um script Lua pode continuar gravando novos dados no Valkey ou Redis OSS mesmo quando o Valkey ou Redis OSS estiver acima de `maxmemory`:
+ O script começa quando o servidor Valkey ou Redis OSS está abaixo de `maxmemory` e contém várias operações de gravação dentro
+ O primeiro comando de gravação do script não está consumindo memória (como DEL), seguido de mais operações de gravação que consumam memória
+ Você pode mitigar esse problema configurando uma política de remoção adequada no servidor Valkey ou Redis OSS diferente de `noeviction`. Isso permite que o Redis OSS remova itens e libere memória entre os scripts Lua.
# Armazenamento de itens compostos grandes (Valkey e Redis OSS)
Em alguns cenários, uma aplicação pode armazenar itens compostos grandes no Valkey ou Redis OSS (como um conjunto de dados hash de vários GB). Não se trata de uma prática recomendada porque ela normalmente acarreta problemas de desempenho no Valkey ou Redis OSS. Por exemplo, o cliente pode executar um comando HGETALL para recuperar toda a coleção hash de vários GB. Isso pode gerar uma pressão de memória significativa para o servidor Valkey ou Redis OSS, armazenando em buffer o item grande no buffer de saída do cliente. Além disso, para migração de slots em modo de cluster, o ElastiCache não migra slots que contenham itens com tamanho serializado maior que 256 MB.
Para resolver os problemas de itens grandes, temos as seguintes recomendações:
+ Divida o item composto grande em vários itens menores. Por exemplo, divida uma coleção de hash grande em campos de valor-chave individuais com um esquema de nome de chave que reflita da maneira indicada a coleção, como o uso de um prefixo comum no nome da chave para identificar a coleção de itens. Se precisar acessar vários campos na mesma coleção atomicamente, você poderá usar o comando MGET para recuperar vários valores-chave no mesmo comando.
+ Se você tiver avaliado todas as opções e ainda não tiver conseguido dividir o conjunto de dados da coleção grande, tente usar comandos que operem em um subconjunto dos dados na coleção, e não em toda a coleção. Evite ter um caso de uso que exija que você recupere atomicamente toda a coleção de vários GB no mesmo comando. Um exemplo é usar os comandos HGET ou HMGET em vez de HGETALL em coleções de hash.
# Configuração do cliente do Lettuce (Valkey e Redis OSS)
Esta seção descreve as opções de configuração recomendadas de Java e Lettuce e como elas se aplicam aos clusters do ElastiCache.
As recomendações nesta seção foram testadas com o Lettuce versão 6.2.2.
**Topics**
+ [Exemplo: configuração do Lettuce para modo de cluster, TLS habilitado](BestPractices.Clients-lettuce-cme.md)
+ [Exemplo: configuração do Lettuce para modo de cluster desabilitado, TLS habilitado](BestPractices.Clients-lettuce-cmd.md)
**TTL de cache de DNS do Java**
A JVM armazena em cache pesquisas de nome DNS. Ao resolver um nome de host para um endereço IP, a JVM armazena em cache o endereço IP para um período especificado, conhecido como *Time-To-Live* (TTL – Tempo de duração).
A escolha de um valor TTL envolve um equilíbrio entre latência e capacidade de resposta a mudança. Com TTLs mais curtos, os resolvedores de DNS percebem atualizações no DNS do cluster com maior rapidez. Isso pode fazer com que sua aplicação responda com maior rapidez às substituições ou a outros fluxos de trabalho pelos quais seu cluster passa. No entanto, se o TTL for muito baixo, ele aumentará o volume da consulta, o que pode aumentar a latência de sua aplicação. Embora não exista um valor TTL correto, vale a pena considerar o tempo que você pode esperar para que uma alteração seja implementada ao definir o TTL.
Como os nós do ElastiCache utilizam entradas de nome de DNS que podem mudar, recomendamos configurar a JVM com um valor TTL de cinco a dez segundos. Isso garante que, quando o endereço IP de um nó mudar, a aplicação poderá receber e usar o novo endereço IP do recurso consultando novamente a entrada DNS.
Em algumas configurações do Java, o TTL padrão da JVM é definido de maneira que jamais atualizará entradas DNS até a JVM ser reiniciada.
Para obter detalhes sobre como definir seu TTL da JVM, consulte [Como definir o TTL da JVM](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html#how-to-set-the-jvm-ttl).
**Versão do Lettuce**
Recomendamos o Lettuce versão 6.2.2 ou posterior.
**Endpoints**
Quando você estiver usando clusters habilitados para o modo de cluster, defina o `redisUri` como o endpoint de configuração do cluster. A pesquisa de DNS para esse URI retorna uma lista de todos os nós disponíveis no cluster e é resolvida aleatoriamente para um deles durante a inicialização do cluster. Para obter mais detalhes sobre como a atualização de topologia funciona, consulte *dynamicRefreshResources* mais adiante neste tópico.
**SocketOption**
Habilite o [KeepAlive](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.KeepAliveOptions.html). Quando habilitada, essa opção reduz a necessidade de lidar com falhas nas conexões durante o runtime de comando.
Defina [Tempo limite de conexão](https://lettuce.io/core/release/api/io/lettuce/core/SocketOptions.Builder.html#connectTimeout-java.time.Duration-) com base nos requisitos da aplicação e na workload. Para ter mais informações, consulte “Tempos limite” posteriormente neste tópico.
**ClusterClientOption: opções do cliente habilitadas para o modo de cluster**
Habilite [AutoReconnect](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#autoReconnect-boolean-) quando a conexão for perdida.
Defina [CommandTimeout](https://lettuce.io/core/release/api/io/lettuPrce/core/RedisURI.html#getTimeout--). Para obter mais detalhes, consulte a seção “Tempos limite” mais adiante neste tópico.
Defina [nodeFilter](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterClientOptions.Builder.html#nodeFilter-java.util.function.Predicate-) para filtrar os nós com falha da topologia. O Lettuce salva todos os nós encontrados na saída “nós de cluster” (como nós com o status PFAIL/FAIL) nas “partições” do cliente (também conhecidas como fragmentos). Durante o processo de criação da topologia do cluster, ele tenta se conectar a todos os nós da partição. Esse comportamento do Lettuce ao adicionar nós com falha pode causar erros de conexão (ou avisos) quando os nós são substituídos por algum motivo.
Por exemplo, depois que um failover é concluído e o cluster inicia o processo de recuperação, enquanto a topologia do cluster é atualizada, o mapa de nós de barramento do cluster tem um curto período em que o nó inativo é listado como um nó com o status FAIL antes de ser completamente removido da topologia. Durante esse período, o cliente do Lettuce o considera um nó íntegro e se conecta de forma contínua a ele. Isso causa uma falha após o término da nova tentativa.
Por exemplo:
```
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**
A filtragem de nós é mais bem utilizada com DynamicRefreshSources definido como verdadeiro. Do contrário, se a visualização da topologia for obtida de um único nó inicial problemático, que vê um nó primário de algum fragmento com o status de falha, ela filtrará esse nó primário, o que causará a falta de cobertura dos slots. Ter vários nós iniciais (quando DynamicRefreshSources é verdadeiro) reduz a probabilidade de ocorrência desse problema, pois pelo menos alguns dos nós iniciais devem ter uma visualização de topologia atualizada após um failover com o primário recém-promovido.
**ClusterTopologyRefreshOptions: opções para controlar a atualização da topologia do cluster do cliente Habilitado no modo do cluster**
**nota**
Os clusters com modo de cluster desabilitado não dão suporte a comandos de descoberta do cluster nem são compatíveis com a funcionalidade de descoberta da topologia dinâmica de todos os clientes.
O modo de cluster desabilitado com o ElastiCache não é compatível com `MasterSlaveTopologyRefresh` do Lettuce. Em vez disso, para o modo de cluster desabilitado, você pode configurar um `StaticMasterReplicaTopologyProvider` e fornecer os endpoints de leitura e gravação do cluster.
Para obter mais informações sobre a conexão com clusters no modo de cluster desabilitado, consulte [Localização de endpoints de um cluster do Valkey ou do Redis OSS (modo cluster desabilitado) (console)](Endpoints.md#Endpoints.Find.Redis).
Se quiser usar a funcionalidade de descoberta da topologia dinâmica do Lettuce, você poderá criar um cluster com modo de cluster habilitado com a mesma configuração de fragmento do cluster existente. No entanto, para clusters habilitados no modo de cluster, recomendamos configurar pelo menos três fragmentos com no mínimo uma réplica para oferecer compatibilidade com failover rápido.
Habilite [enablePeriodicRefresh](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enablePeriodicRefresh-java.time.Duration-). Isso possibilita atualizações periódicas da topologia do cluster para que o cliente a atualize nos intervalos do refreshPeriod (padrão: 60 segundos). Quando desabilitado, o cliente atualiza a topologia do cluster somente quando ocorrem erros ao tentar executar comandos no cluster.
Com essa opção habilitada, você pode reduzir a latência associada à atualização da topologia do cluster adicionando esse trabalho a uma tarefa em segundo plano. Embora a atualização da topologia seja executada em um trabalho em segundo plano, ela pode ser um pouco lenta para clusters com muitos nós. Isso ocorre porque todos os nós estão sendo consultados para obter a visualização mais atualizada do cluster. Se você executa um cluster grande, é recomendável aumentar o período.
Habilite [enableAllAdaptiveRefreshTriggers](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#enableAllAdaptiveRefreshTriggers--). Isso possibilita a atualização adaptativa da topologia que usa todos os [acionadores](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. Os acionadores de atualização adaptável iniciam atualizações de visualização da topologia com base em eventos que ocorrem durante as operações de cluster do Valkey ou Redis OSS. Quando habilitada, essa opção ocasiona uma atualização imediata da topologia quando ocorre um dos acionadores anteriores. As atualizações adaptáveis acionadas têm uma taxa limitada usando um tempo limite porque os eventos podem ocorrer em grande escala (tempo limite padrão entre as atualizações: 30).
Habilite [closeStaleConnections](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#closeStaleConnections-boolean-). Isso possibilita fechar conexões obsoletas ao atualizar a topologia do cluster. Ela só entrará em vigor se [ClusterTopologyRefreshOptions.isPeriodicRefreshEnabled()](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.html#isPeriodicRefreshEnabled--) for verdadeiro. Quando habilitado, o cliente pode fechar conexões obsoletas e criar outras em segundo plano. Isso reduz a necessidade de lidar com falhas nas conexões durante o runtime de comando.
Habilite [dynamicRefreshResources](https://lettuce.io/core/release/api/io/lettuce/core/cluster/ClusterTopologyRefreshOptions.Builder.html#dynamicRefreshSources-boolean-). Recomendamos habilitar a opção dynamicRefreshResources para clusters pequenos e desabilitá-la para clusters grandes. A opção dynamicRefreshResources possibilita descobrir nós de cluster com base no nó inicial fornecido (por exemplo, endpoint de configuração de cluster). Ele usa todos os nós descobertos como fontes para atualizar a topologia do cluster.
A atualização dinâmica consulta todos os nós descobertos para a topologia do cluster e tenta escolher a visualização mais precisa do cluster. Se for definido como falso, somente os nós iniciais serão usados como fontes para a descoberta da topologia e o número de clientes será obtido apenas para os nós iniciais. Quando desabilitado, se o endpoint de configuração do cluster for resolvido em um nó com falha, a tentativa de atualizar a visualização do cluster falhará e causará exceções. Esse cenário pode ocorrer porque demora até que a entrada de um nó com falha seja removida do endpoint de configuração do cluster. Portanto, o endpoint de configuração ainda pode ser resolvido aleatoriamente em um nó com falha por um curto período.
No entanto, quando está habilitado, usamos todos os nós do cluster recebidos da visualização do cluster para consultar a visualização atual. Como filtramos os nós com falha nessa visualização, a atualização da topologia será bem-sucedida. No entanto, quando dynamicRefreshSources é verdadeiro, o Lettuce consulta todos os nós para obter a visualização do cluster e, depois, compara os resultados. Portanto, isso pode ser caro para clusters com muitos nós. Sugerimos que você desabilite esse recurso para clusters com muitos nós.
```
final ClusterTopologyRefreshOptions topologyOptions =
ClusterTopologyRefreshOptions.builder()
.enableAllAdaptiveRefreshTriggers()
.enablePeriodicRefresh()
.dynamicRefreshSources(true)
.build();
```
**ClientResources**
Configure [DnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#dnsResolver-io.lettuce.core.resource.DnsResolver-) com [DirContextDnsResolver](https://lettuce.io/core/release/api/io/lettuce/core/resource/DirContextDnsResolver.html). O resolvedor de DNS é baseado em com.sun.jndi.dns.DnsContextFactory do Java.
Configure [reconnectDelay](https://lettuce.io/core/release/api/io/lettuce/core/resource/DefaultClientResources.Builder.html#reconnectDelay-io.lettuce.core.resource.Delay-) com recuo exponencial e oscilação total. O Lettuce tem mecanismos de repetição integrados com base nas estratégias de recuo exponencial. Para obter detalhes, consulte a publicação [Recuo exponencial e oscilação](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter) no Blog de arquitetura da AWS. Para ter mais informações sobre a importância de tentar novamente uma estratégia de recuo, consulte as seções de lógica de recuo da [publicação do blog sobre práticas recomendadas](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/) no Blog de bancos de dados da 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();
```
**Tempos limite **
Use um valor de tempo limite de conexão menor do que o tempo limite do comando. O Lettuce utiliza uma conexão preguiçosa. Portanto, se o tempo limite de conexão for maior do que o tempo limite do comando, você poderá ter um período de falha persistente após uma atualização da topologia se o Lettuce tentar se conectar a um nó não íntegro e o tempo limite do comando sempre for excedido.
Utilize um tempo limite de comando dinâmico para comandos diferentes. Recomendamos definir o tempo limite do comando com base na duração esperada do comando. Por exemplo, utilize um tempo limite maior para comandos que iteram em várias teclas, como scripts FLUSHDB, FLUSHALL, KEYS, SMEMBERS ou Lua. Utilize tempos limite mais curtos para comandos de tecla única, como SET, GET e HSET.
**nota**
Os tempos limite configurados no exemplo a seguir são para testes que executaram comandos SET/GET com chaves e valores de até 20 bytes. O tempo de processamento pode ser maior quando os comandos são complexos ou quando as chaves e os valores são maiores. Você deve definir os tempos limite com base no caso de uso de sua aplicação.
```
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();
```
# Exemplo: configuração do Lettuce para modo de cluster, TLS habilitado
**nota**
Os tempos limite no exemplo a seguir são para testes que executaram comandos SET/GET com chaves e valores de até 20 bytes. O tempo de processamento pode ser maior quando os comandos são complexos ou quando as chaves e os valores são maiores. Você deve definir os tempos limite com base no caso de uso de sua aplicação.
```
// 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();
```
# Exemplo: configuração do Lettuce para modo de cluster desabilitado, TLS habilitado
**nota**
Os tempos limite no exemplo a seguir são para testes que executaram comandos SET/GET com chaves e valores de até 20 bytes. O tempo de processamento pode ser maior quando os comandos são complexos ou quando as chaves e os valores são maiores. Você deve definir os tempos limite com base no caso de uso de sua aplicação.
```
// 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);
```
## Configurar um protocolo preferencial para clusters de pilha dupla (Valkey e Redis OSS)
Para clusters do Valkey ou Redis OSS de modo cluster habilitado, você pode controlar o protocolo que os clientes usarão para se conectar aos nós no cluster com o parâmetro de descoberta de IP. O parâmetro de descoberta de IP pode ser definido como IPv4 ou IPv6.
Para clusters do Valkey ou Redis OSS, o parâmetro de descoberta de IP define o protocolo IP usado na saída de [cluster slots ()](https://valkey.io/commands/cluster-slots/), [cluster shards ()](https://valkey.io/commands/cluster-shards/) e [cluster nodes ()](https://valkey.io/commands/cluster-nodes/). Esses comandos são usados pelos clientes para descobrir a topologia do cluster. Os clientes usam os IPs nesses comandos para se conectar aos outros nós no cluster.
Alterar a descoberta de IP não resultará em nenhum tempo de inatividade para os clientes conectados. No entanto, as alterações levarão algum tempo para se propagar. Para determinar quando as alterações foram completamente propagadas para um cluster do Valkey ou Redis OSS, monitore a saída de `cluster slots`. Depois que todos os nós retornados pelo comando cluster slots relatam IPs com o novo protocolo, as alterações terminam de se propagar.
Exemplo com 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)
```
Exemplo com 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;
}));
```
# Práticas recomendadas para clientes (Memcached)
Conheça as práticas recomendadas para cenários comuns com os clusters do ElastiCache para Memcached.
**Topics**
+ [Configurando seu ElastiCache cliente para balanceamento de carga eficiente (Memcached)](BestPractices.LoadBalancing.md)
+ [Clientes validados com Memcached](network-type-validated-clients-memcached.md)
+ [Configurar um protocolo preferencial para clusters de pilha dupla (Memcached)](network-type-configuring-dual-stack-memcached.md)
# Configurando seu ElastiCache cliente para balanceamento de carga eficiente (Memcached)
**nota**
Esta seção se aplica a clusters Memcached de vários nós baseado em nós.
Para usar com eficiência vários nós do ElastiCache Memcached, você precisa ser capaz de distribuir suas chaves de cache pelos nós. Uma maneira simples de balancear a carga de um cluster com *n* nós é calcular o hash da chave do objeto e modificar o resultado por *n*: `hash(key) mod n`. O valor resultante (de 0 a *n*-1) é o número do nó em que você coloca o objeto.
Essa abordagem é simples e funcionará bem desde que o número de nós (*n*) seja constante. No entanto, sempre que você adiciona ou remove um nó do cluster, o número de chaves que precisam ser movidas é *(n - 1) / n* (em que *n* é o novo número de nós). Assim, essa abordagem resulta em um grande número de chaves movidas, o que se converte em um grande número de perdas no cache inicial, especialmente porque o número de nós fica grande. A escala de 1 para 2 nós resulta na movimentação de (2-1)/2 (50%) das chaves, o melhor caso. A escala de 9 a 10 nós resulta na movimentação de (10-1)/10 (90%) das chaves. Se você estiver aumentado a escala devido a um pico no tráfego, não convém ter um grande número de perdas no cache. Um grande número de perdas no cache resulta em acertos no banco de dados, que já está sobrecarregado devido ao pico no tráfego.
A solução para esse dilema é o hashing consistente. O hashing consistente usa um algoritmo, de modo que, sempre que um nó é adicionado ou removido a/de um cluster, o número de chaves que devem ser movidas é de aproximadamente *1/n* (onde *n* é o novo número de nós). A escala de 1 para 2 nós resulta na movimentação de 1/2 (50%) das chaves, o pior caso. Escalar de 9 a 10 nós resulta na movimentação de 1/10 (10%) das chaves.
Como usuário, você controla qual algoritmo de hashing é usado para clusters de vários nós. Recomendamos configurar os clientes para usar o hashing consistente. Felizmente, existem muitas bibliotecas de cliente Memcached na maioria das linguagens populares que implementam o hashing consistente. Verifique a documentação da biblioteca que você está usando para ver se ela oferece suporte para hashing consistente e como implementá-lo.
Se você estiver trabalhando em Java, PHP ou .NET, recomendamos que você use uma das bibliotecas de ElastiCache cliente da Amazon.
## Hash consistente usando o Java
O cliente Java ElastiCache Memcached é baseado no cliente Java spymemcached de código aberto, que tem recursos de hashing consistentes incorporados. A biblioteca inclui uma KetamaConnectionFactory classe que implementa um hashing consistente. Por padrão, o hashing consistente está desativado em spymemcached.
Para obter mais informações, consulte a KetamaConnectionFactory documentação em [KetamaConnectionFactory](https://github.com/RTBHOUSE/spymemcached/blob/master/src/main/java/net/spy/memcached/KetamaConnectionFactory.java).
## Hash consistente usando o PHP com o Memcached
O cliente PHP ElastiCache Memcached é um invólucro da biblioteca PHP integrada do Memcached. Por padrão, o hashing consistente é desativado pela biblioteca PHP Memcached.
Use o código a seguir para ativar o hashing consistente.
```
$m = new Memcached();
$m->setOption(Memcached::OPT_DISTRIBUTION, Memcached::DISTRIBUTION_CONSISTENT);
```
Além do código anterior, recomendamos que você também ative `memcached.sess_consistent_hash` no seu arquivo php.ini.
[Para obter mais informações, consulte a documentação de configuração em tempo de execução do Memcached PHP em http://php. net/manual/en/memcached.configuração.php](http://php.net/manual/en/memcached.configuration.php). Observe especificamente o parâmetro `memcached.sess_consistent_hash`.
## Hash consistente usando o .NET com o Memcached
O cliente ElastiCache Memcached .NET é um invólucro do Enyim Memcached. Por padrão, o hashing consistente é ativado pelo cliente Enyim Memcached.
Para obter mais informações, consulte a `memcached/locator` documentação em [https://github.com/enyim/EnyimMemcached/wiki/MemcachedClient-Configuration\$1 user-content-memcachedlocator](https://github.com/enyim/EnyimMemcached/wiki/MemcachedClient-Configuration#user-content-memcachedlocator).
# Clientes validados com Memcached
Os seguintes clientes foram validados especificamente para funcionar com todas as configurações de tipo de rede aceitas pelo Memcached.
Clientes validados:
+ [AWS ElastiCache Cluster Client Memcached for Php](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php), [Versão \$13.6.2](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php/tree/v3.2.0)
+ [AWS Elasticache Cluster Client Memcached for Java](https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-java) – O mestre mais recente no Github
# Configurar um protocolo preferencial para clusters de pilha dupla (Memcached)
Para clusters Memcached, você pode controlar o protocolo que os clientes usarão para se conectar aos nós no cluster com o parâmetro de descoberta de IP. O parâmetro de descoberta de IP pode ser definido como IPv4 ou IPv6.
O parâmetro de descoberta de IP controla o protocolo IP usado na saída do cluster config get. O que, por sua vez, determinará o protocolo IP usado pelos clientes que oferecem suporte à descoberta automática de clusters do ElastiCache para Memcached.
Alterar a descoberta de IP não resultará em nenhum tempo de inatividade para os clientes conectados. No entanto, as alterações levarão algum tempo para se propagar.
Monitore a saída de `getAvailableNodeEndPoints` para Java e para Php monitore a saída de`getServerList`. Depois que a saída dessas funções relata IPs de todos os nós do cluster que usam o protocolo atualizado, as alterações terminam de se propagar.
Exemplo de 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;
}));
```
Exemplo de 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);
```
Qualquer conexão de cliente existente que tenha sido criada antes da atualização da descoberta de IP ainda será conectada usando o protocolo antigo. Todos os clientes validados se reconectarão automaticamente ao cluster usando o novo protocolo IP assim que as alterações forem detectadas na saída dos comandos de descoberta do cluster. No entanto, isso depende da implementação do cliente.
## Clusters do ElastiCache de pilha dupla habilitados para TLS
Quando o TLS está habilitado para clusters do ElastiCache, as funções de descoberta de cluster (`cluster slots`, `cluster shards`, e `cluster nodes` para o Redis) ou `config get cluster` para o Memcached retornam nomes de host em vez de IPs. Os nomes de host são então usados em vez de IPs para se conectar ao cluster do ElastiCache e realizar um handshake de TLS. Isso significa que os clientes não serão afetados pelo parâmetro de descoberta de IP. Para clusters habilitados para TLS, o parâmetro de descoberta de IP não tem efeito no protocolo IP preferencial. Em vez disso, o protocolo IP usado será determinado pelo protocolo IP que o cliente prefere ao resolver nomes de host DNS.
**Clientes Java**
Ao se conectar de um ambiente Java que oferece suporte a IPv4 e IPv6, o Java, por padrão, prefere IPv4 em vez de IPv6 para compatibilidade com versões anteriores. No entanto, a preferência do protocolo IP é configurável por meio dos argumentos da JVM. Para preferir IPv4, a JVM aceita `-Djava.net.preferIPv4Stack=true` e prefere o conjunto IPv6 `-Djava.net.preferIPv6Stack=true`. A configuração `-Djava.net.preferIPv4Stack=true` significa que a JVM não fará mais nenhuma conexão IPv6. **Para Valkey ou Redis OSS, isso inclui aquelas para outras aplicações não Valkey e não Redis OSS.**
**Preferências de nível de host**
Em geral, se o runtime do cliente ou o cliente não fornecer opções de configuração para definir uma preferência de protocolo IP, ao executar a resolução de DNS, o protocolo IP dependerá da configuração do host. Por padrão, a maioria dos hosts prefere IPv6 em vez de IPv4, mas essa preferência pode ser configurada no nível do host. Isso afetará todas as solicitações de DNS desse host, não apenas aquelas para clusters do ElastiCache.
**Hosts Linux**
Para Linux, uma preferência de protocolo IP pode ser configurada modificando o arquivo do `gai.conf`. O arquivo do `gai.conf` pode ser encontrado em `/etc/gai.conf`. Se não houver `gai.conf` especificado, um exemplo deve estar disponível em `/usr/share/doc/glibc-common-x.xx/gai.conf`, o qual pode ser copiado em `/etc/gai.conf`, e a configuração padrão não deverá ser comentada. Para atualizar a configuração para preferir IPv4 ao se conectar a um cluster do ElastiCache, atualize a precedência do intervalo CIDR que abrange os IPs do cluster para estar acima da precedência das conexões IPv6 padrão. Por padrão, as conexões IPv6 têm uma precedência de 40. Por exemplo, supondo que o cluster esteja localizado em uma sub-rede com o CIDR 172.31.0.0:0/16, a configuração abaixo faria com que os clientes preferissem conexões IPv4 a esse cluster.
```
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
```
Mais detalhes sobre `gai.conf` estão disponíveis na [página principal do Linux](https://man7.org/linux/man-pages/man5/gai.conf.5.html)
**Hosts do Windows**
O processo para hosts do Windows é semelhante. Para hosts do Windows, você pode executar `netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL`. Isso tem o mesmo resultado que modificar o arquivo `gai.conf` em hosts Linux.
Isso atualizará as políticas de preferência para preferir conexões IPv4 em vez de conexões IPv6 para o intervalo CIDR especificado. Por exemplo, supondo que o cluster esteja em uma sub-rede com o CIDR 172.31.0.0:0/16, a execução de `netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15` resultaria na seguinte tabela de precedência, o que faria com que os clientes preferissem IPv4 ao se conectarem ao cluster.
```
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
```
# Gerenciamento de memória reservada para Valkey e Redis OSS
A memória reservada é a memória reservada para o uso não relacionado a dados. Ao executar um backup ou failover, o Valkey e o Redis OSS usam a memória disponível para registrar operações de gravação no seu cluster enquanto os dados do cluster estão sendo gravados no arquivo .rdb. Se você não tiver memória suficiente disponível para todas as gravações, o processo falhará. A seguir, você encontrará informações sobre opções para gerenciar memória reservada para o ElastiCache para Redis OSS e como aplicar essas opções.
**Topics**
+ [De quanta memória reservada você precisa?](#redis-memory-management-need)
+ [Parâmetros para gerenciar memória reservada](#redis-memory-management-parameters)
+ [Especificação do parâmetro de gerenciamento de memória reservada](#redis-reserved-memory-management-change)
## De quanta memória reservada você precisa?
Se você estiver executando uma versão do Redis OSS anterior à 2.8.22, reserve mais memória para backups e failover do que se estiver executando o Redis OSS 2.8.22 ou posterior. Este requisito é devido às diferentes maneiras como o ElastiCache para Redis OSS implementa o processo de backup. A regra geral é reservar metade do valor `maxmemory` de um tipo de nó para a sobrecarga do Redis OSS para versões anteriores à 2.8.22 e um quarto para o Redis OSS versão 2.8.22 e posterior.
Devido às diferentes maneiras pelas quais o ElastiCache implementa o processo de backup e replicação, a regra geral é reservar 25% do valor `maxmemory` de um tipo de nó usando o parâmetro `reserved-memory-percent`. Este é o valor padrão e recomendado para a maioria dos casos.
Quando os tipos de instância micro e pequena com capacidade de intermitência estão operando perto dos limites de `maxmemory`, eles podem experimentar o uso de troca. Para melhorar a confiabilidade operacional desses tipos de instância durante o backup, a replicação e o tráfego intenso, recomendamos aumentar o valor do parâmetro `reserved-memory-percent` em até 30% nos tipos de instâncias pequenas e até 50% nos tipos de instâncias micro.
Para workloads com uso intenso de gravação em clusters do ElastiCache com classificação de dados em níveis, recomendamos aumentar `reserved-memory-percent` para até 50% da memória disponível do nó.
Para obter mais informações, consulte:
+ [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md)
+ [Como a sincronização e o backup são implementados](Replication.Redis.Versions.md)
+ [Classificação de dados em níveis no ElastiCache](data-tiering.md)
## Parâmetros para gerenciar memória reservada
Desde 16 de março de 2017, o Amazon ElastiCache fornece dois parâmetros mutuamente exclusivos para gerenciar memória do Valkey ou Redis OSS, `reserved-memory` e `reserved-memory-percent`. Nenhum desses parâmetros faz parte da distribuição do Valkey ou Redis OSS.
Dependendo de quando você se tornou cliente do ElastiCache, um desses dois parâmetros será o parâmetro de gerenciamento de memória padrão. Esse parâmetro se aplica quando você cria um novo grupo de replicação ou cluster do Valkey ou Redis OSS e usa um grupo de parâmetros padrão.
+ Para clientes que iniciaram antes de 16 de março de 2017, quando você criar um grupo de replicação ou cluster do Redis OSS usando o grupo de parâmetros padrão, o parâmetro de gerenciamento de memória será `reserved-memory`. Nesse caso, zero (0) bytes de memória são reservados.
+ Para clientes que iniciaram de 16 de março de 2017 em diante, quando você criar um grupo de replicação ou cluster do Valkey ou Redis OSS usando o grupo de parâmetros padrão, o parâmetro de gerenciamento de memória será `reserved-memory-percent`. Nesse caso, 25% do valor `maxmemory` dos seus nós será reservado para fins não de dados.
Depois de ler sobre os dois parâmetros de gerenciamento de memória do Valkey ou Redis OSS, você pode preferir usar aquele que não é o padrão, ou com valores não padrão. Se esse for o caso, você poderá alterar para o outro parâmetro de gerenciamento de memória reservada.
Para alterar o valor desse parâmetro, você pode criar um grupo de parâmetros personalizado e modificá-lo para usar o parâmetro e o valor de gerenciamento de memória preferidos. Você pode usar o grupo de parâmetros personalizado sempre que criar um novo cluster ou grupo de replicação do Valkey ou Redis OSS. Para clusters ou grupos de replicação existentes, você pode modificá-los para usar o parameter group personalizado.
Para obter mais informações, consulte:
+ [Especificação do parâmetro de gerenciamento de memória reservada](#redis-reserved-memory-management-change)
+ [Criação de um grupo de parâmetros do ElastiCache](ParameterGroups.Creating.md)
+ [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md)
+ [Modificação de um cluster do ElastiCache](Clusters.Modify.md)
+ [Modificação de um grupo de replicação](Replication.Modify.md)
### O parâmetro reserved-memory
Antes de 16 de março de 2017, todo o gerenciamento de memória reservado do ElastiCache para Redis OSS era feito com o uso do parâmetro `reserved-memory`. O valor padrão de `reserved-memory` é 0. Este padrão não reserva memória para a sobrecarga do Valkey ou Redis OSS e permite que o Valkey ou Redis OSS consuma toda a memória de um nó com dados.
A alteração do parâmetro `reserved-memory` para que você tenha memória suficiente disponível para backups e failovers requer que você crie um parameter group personalizado. Neste grupo de parâmetros personalizado, você define `reserved-memory` como um valor apropriado para a versão do Valkey ou Redis OSS executada no seu cluster e o tipo de nó do cluster. Para obter mais informações, consulte . [De quanta memória reservada você precisa?](#redis-memory-management-need)
O parâmetro `reserved-memory` é específico do ElastiCache e não faz parte da distribuição geral do Redis OSS.
O procedimento a seguir mostra como usar `reserved-memory` para gerenciar a memória no seu cluster do Valkey ou Redis OSS.
**Para reservar memória usando reserved-memory**
1. Crie um parameter group personalizado especificando a família de parameter groups que corresponde à versão do mecanismo que você está executando, por exemplo, especificando a família de parameter groups `redis2.8`. Para obter mais informações, consulte [Criação de um grupo de parâmetros do ElastiCache](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. Calcule quantos bytes de memória reservar para a sobrecarga do Valkey ou Redis OSS. Você pode encontrar o valor de `maxmemory` para o seu tipo de nó em [Parâmetros específicos de node-type do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).
1. Modifique o parameter group personalizado para que o parâmetro `reserved-memory` seja o número de bytes que você calculou na etapa anterior. O seguinte exemplo da AWS CLI supõe que você esteja executando uma versão do Redis OSS anterior à 2.8.22 e precisa reservar metade da `maxmemory` do nó. Para obter mais informações, consulte [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis28-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=7130316800"
```
Observe que você precisa de um grupo de parâmetros personalizado separado para cada tipo de nó utilizado, pois cada tipo de nó possui um valor de `maxmemory` diferente. Assim, cada tipo de nó precisa de um valor diferente para `reserved-memory`.
1. Modifique seu cluster ou grupo de replicação do Redis OSS para usar seu grupo de parâmetros personalizado.
O exemplo de CLI a seguir modifica o cluster ` my-redis-cluster` para começar a usar imediatamente o parameter group `redis28-m3xl`. Para obter mais informações, consulte [Modificação de um cluster do ElastiCache](Clusters.Modify.md).
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
O exemplo de CLI a seguir modifica o grupo de replicação `my-redis-repl-grp` para começar a usar imediatamente o parameter group `redis28-m3xl`. Para obter mais informações, [Modificação de um grupo de replicação](Replication.Modify.md).
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-m3xl \
--apply-immediately
```
### O parâmetro reserved-memory-percent
Em 16 de março de 2017, o Amazon ElastiCache introduziu o parâmetro `reserved-memory-percent` e o disponibilizou em todas as versões do ElastiCache para Redis OSS. O objetivo de `reserved-memory-percent` é simplificar o gerenciamento da memória reservada em todos os seus clusters. Ele faz isso permitindo que você tenha um único parameter group para cada família de parameter groups (como `redis2.8`) para gerenciar a memória reservada dos seus clusters, independentemente do tipo de nó. O valor padrão para `reserved-memory-percent` é 25 (25%).
O parâmetro `reserved-memory-percent` é específico do ElastiCache e não faz parte da distribuição geral do Redis OSS.
Se o cluster estiver usando um tipo de nó da família r6gd e o uso de memória atingir 75%, a classificação de dados em níveis será acionada automaticamente. Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
**Para reservar memória usando reserved-memory-percent**
Para usar `reserved-memory-percent` para gerenciar a memória no seu cluster do ElastiCache para Redis OSS, siga um destes procedimentos:
+ Se você estiver executando o Redis OSS 2.8.22 ou posterior, atribua o grupo de parâmetros padrão ao cluster. O padrão de 25 por cento deve ser adequado. Caso contrário, siga as etapas descritas a seguir para alterar o valor.
+ Se você estiver executando uma versão do Redis OSS anterior à 2.8.22, provavelmente precisará reservar mais memória do que o padrão de 25% de `reserved-memory-percent`. Para fazer isso, use o procedimento a seguir.
**Para alterar o valor percentual de reserved-memory-percent**
1. Crie um parameter group personalizado especificando a família de parameter groups que corresponde à versão do mecanismo que você está executando, por exemplo, especificando a família de parameter groups `redis2.8`. Um grupo de parâmetros personalizado é necessário, pois você não pode modificar um grupo de parâmetros padrão. Para obter mais informações, consulte [Criação de um grupo de parâmetros do ElastiCache](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
```
Como `reserved-memory-percent` reserva a memória como uma porcentagem da `maxmemory` de um nó, você não precisa de um parameter group personalizado para cada tipo de nó.
1. Modifique o parameter group personalizado para que `reserved-memory-percent` seja 50 (50%). Para obter mais informações, consulte [Modificação de um grupo de parâmetros do ElastiCache](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. Use esse grupo de parâmetros personalizado para qualquer cluster ou grupo de replicação do Redis OSS que esteja executando uma versão do Redis OSS anterior à 2.8.22.
O exemplo da CLI a seguir modifica o cluster do Redis OSS `my-redis-cluster` para começar a usar imediatamente o grupo de parâmetros `redis28-50`. Para obter mais informações, consulte [Modificação de um cluster do ElastiCache](Clusters.Modify.md).
```
aws elasticache modify-cache-cluster \
--cache-cluster-id my-redis-cluster \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
O exemplo da CLI a seguir modifica o grupo de replicação do Redis OSS `my-redis-repl-grp` para começar a usar imediatamente o grupo de parâmetros `redis28-50`. Para obter mais informações, consulte [Modificação de um grupo de replicação](Replication.Modify.md).
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-repl-grp \
--cache-parameter-group-name redis28-50 \
--apply-immediately
```
## Especificação do parâmetro de gerenciamento de memória reservada
Se você já era cliente ativo do ElastiCache em 16 de março de 2017, seu parâmetro de gerenciamento de memória reservada padrão é `reserved-memory` com zero (0) byte de memória reservada. Se você se tornou cliente do ElastiCache depois de 16 de março de 2017, seu parâmetro de gerenciamento de memória reservada padrão é `reserved-memory-percent`, com 25 por cento da memória do nó reservada. Isso se aplica sempre que você cria um cluster ou grupo de replicação do ElastiCache para Redis OSS. Entretanto, você pode alterar seu parâmetro de gerenciamento de memória reservada usando a AWS CLI ou a API do ElastiCache.
Os parâmetros `reserved-memory` e `reserved-memory-percent` são mutuamente exclusivos. Um grupo de parâmetros sempre terá um, mas nunca os dois. Você pode alterar o parâmetro usado por um parameter group para o gerenciamento da memória reservada, modificando o parameter group. O grupo de parâmetros deve ser personalizado, pois não é possível modificar grupos de parâmetros padrão. Para obter mais informações, consulte [Criação de um grupo de parâmetros do ElastiCache](ParameterGroups.Creating.md).
**Para especificar reserved-memory-percent**
Para usar `reserved-memory-percent` como o parâmetro de gerenciamento de memória reservada, modifique um grupo de parâmetros usando o comando `modify-cache-parameter-group`. Use o parâmetro `parameter-name-values` para especificar `reserved-memory-percent` e um valor para ele.
O seguinte exemplo de CLI modifica o parameter group personalizado `redis32-cluster-on` para que ele use `reserved-memory-percent` para gerenciar a memória reservada. Um valor deve ser atribuído a `ParameterValue` para que o grupo de parâmetros use o parâmetro `ParameterName` para gerenciamento de memória reservada. Para obter mais informações, consulte [Modificação de um grupo de parâmetros do ElastiCache](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"
```
**Para especificar reserved-memory**
Para usar `reserved-memory` como o parâmetro de gerenciamento de memória reservada, modifique um grupo de parâmetros usando o comando `modify-cache-parameter-group`. Use o parâmetro `parameter-name-values` para especificar `reserved-memory` e um valor para ele.
O seguinte exemplo de CLI modifica o parameter group personalizado `redis32-m3xl` para que ele use `reserved-memory` para gerenciar a memória reservada. Um valor deve ser atribuído a `ParameterValue` para que o grupo de parâmetros use o parâmetro `ParameterName` para gerenciamento de memória reservada. Como a versão do mecanismo é mais recente do que 2.8.22, definimos o valor como `3565158400`, que equivale a 25% da `cache.m3.xlarge` de um `maxmemory`. Para obter mais informações, consulte [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md).
```
aws elasticache modify-cache-parameter-group \
--cache-parameter-group-name redis32-m3xl \
--parameter-name-values "ParameterName=reserved-memory, ParameterValue=3565158400"
```
# Práticas recomendadas ao trabalhar com clusters baseados em nós do Valkey e Redis OSS
O uso do Multi-AZ, ter memória suficiente, redimensionar clusters e minimizar o tempo de inatividade são conceitos úteis a serem considerados ao trabalhar com clusters baseados em nós no Valkey ou Redis OSS. É recomendável analisar e seguir essas práticas recomendadas.
**Topics**
+ [Minimização do tempo de inatividade com multi-AZ](multi-az.md)
+ [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md)
+ [Redimensionamento de cluster on-line](best-practices-online-resharding.md)
+ [Minimização do tempo de inatividade durante a manutenção](BestPractices.MinimizeDowntime.md)
# Minimização do tempo de inatividade com multi-AZ
Há várias instâncias em que o ElastiCache Valkey ou Redis OSS pode precisar substituir um nó primário; elas incluem certos tipos de manutenção planejada e o evento improvável de falha em um nó primário ou zona de disponibilidade.
Essa substituição resulta em algum tempo de inatividade do cluster, mas se o multi-AZ estiver habilitado, o tempo de inatividade será minimizado. A função do nó primário fará failover automaticamente para uma das réplicas de leitura. Não há necessidade de criar e provisionar um novo nó primário, porque o ElastiCache lidará com isso de forma transparente. O failover e a promoção de réplica garantem que você possa continuar a gravar no novo primário assim que a promoção estiver concluída.
Para saber mais sobre o Multi-AZ e a minimização do tempo de inatividade, consulte [Minimizar o tempo de inatividade no ElastiCache usando o Multi-AZ com Valkey e Redis OSS](AutoFailover.md).
# Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS
**Snapshots e sincronizações no Valkey 7.2 e posterior e no Redis OSS versão 2.8.22 e posterior**
O Valkey tem suporte padrão para snapshots e sincronizações. O Redis OSS 2.8.22 apresenta um processo de salvamento sem bifurcação que permite alocar mais da sua memória ao uso do seu aplicativo sem incorrer em um maior uso de permuta durante sincronizações e salvamentos. Para obter mais informações, consulte [Como a sincronização e o backup são implementados](Replication.Redis.Versions.md).
**Snapshots e sincronizações do Redis OSS antes da versão 2.8.22**
Quando você trabalha com o ElastiCache para Redis OSS, o Redis OSS chama um comando de gravação em segundo plano em vários casos:
+ Ao criar um snapshot para um backup.
+ Ao sincronizar réplicas com o primário em um grupo de replicação.
+ Ao habilitar o atributo de arquivo somente de acréscimo (AOF) para o Redis OSS.
+ Ao promover uma réplica para primário (o que causa uma sincronização entre o primário/réplica).
Sempre que o Redis OSS executa um processo de gravação em segundo plano, você deve ter memória disponível suficiente para acomodar a sobrecarga de processos. A falta de memória suficiente disponível faz com que o processo falhe. Por isso, é importante escolher um tipo de instância de nó que tenha memória suficiente ao criar seu cluster do Redis OSS.
## Processo de gravação em segundo plano e uso de memória com o Valkey e Redis OSS
Sempre que um processo de gravação em segundo plano é chamado, o Valkey e Redis OSS bifurcam seu processo (lembre-se, esses mecanismos são single-threaded). Uma bifurcação persiste seus dados no disco em um arquivo de snapshot .rdb do Redis OSS. A outra bifurcação atende a todas as operações de leitura e gravação. Para garantir que seu snapshot seja um snapshot de ponto no tempo, todas as atualizações e adições de dados são gravadas em uma área de memória disponível separada da área de dados.
Enquanto você tiver memória suficiente disponível para registrar todas as operações de gravação durante a manutenção dos dados no disco, não haverá problemas de memória insuficiente. É provável que você experimente problemas de memória insuficiente se uma das seguintes condições for verdadeira:
+ Seu aplicativo realiza muitas operações de gravação, exigindo assim uma grande quantidade de memória disponível para aceitar os dados novos ou atualizados.
+ Você tem pouca memória disponível para gravar dados novos ou atualizados.
+ Você tem um grande conjunto de dados que demora muito para persistir no disco, exigindo um grande número de operações de gravação.
O diagrama a seguir ilustra o uso da memória ao executar um processo de gravação em segundo plano.
![\[Imagem: diagrama de uso de memória durante uma gravação em segundo plano.\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-bgsaveMemoryUseage.png)
Para obter informações sobre o impacto de fazer um backup sobre o desempenho, consulte [Impacto sobre o desempenho dos backups de clusters baseados em nós](backups.md#backups-performance).
Para obter mais informações sobre como o Valkey e Redis OSS realizam snapshots, consulte [http://valkey.io](http://valkey.io).
Para obter mais informações sobre regiões e zonas de disponibilidade, consulte [Seleção de regiões e zonas de disponibilidade para o ElastiCache](RegionsAndAZs.md).
## Evitando memória insuficiente ao executar uma gravação em segundo plano
Sempre que um processo de gravação em segundo plano, como `BGSAVE` ou `BGREWRITEAOF`, é chamado, para evitar que o processo falhe, você deve ter mais memória disponível do que será consumida por operações de gravação durante o processo. O cenário de pior caso é aquele em que, durante a operação de gravação em segundo plano, cada registro é atualizado e alguns novos registros são adicionados ao cache. Por conta disso, recomendamos que você defina `reserved-memory-percent` como 50 (50 por cento) para versões do Redis OSS anteriores à 2.8.22 ou como 25 (25 por cento) para o Valkey e todas as versões do Redis OSS 2.8.22 e posteriores.
O valor `maxmemory` indica a memória disponível para dados e sobrecargas operacionais. Como você não pode modificar o parâmetro `reserved-memory` no parameter group padrão, deve criar um parameter group personalizado para o cluster. O valor padrão para `reserved-memory` é 0, o que permite que o Redis OSS consuma todo o *maxmemory* com dados, potencialmente deixando pouca memória para outros usos, como um processo de gravação em segundo plano. Para valores `maxmemory` por tipo de instância de nó, consulte [Parâmetros específicos de node-type do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).
Você também pode usar o parâmetro `reserved-memory` para reduzir a quantidade de memória usada na caixa.
Para obter mais informações sobre parâmetros específicos do Valkey e Redis no ElastiCache, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
Para obter informações sobre como criar e modificar parameter groups, consulte [Criação de um grupo de parâmetros do ElastiCache](ParameterGroups.Creating.md) e [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md).
# Redimensionamento de cluster on-line
A *refragmentação* consiste na adição e remoção de fragmentos ou nós de seu cluster bem como na redistribuição de espaços importantes. Como resultado, vários itens têm impacto na operação de refragmentação, como a carga no cluster, a utilização de memória e o tamanho geral dos dados. Para obter a melhor experiência, recomendamos que você siga as práticas gerais recomendadas de cluster para distribuição padrão uniforme de workload. Além disso, recomendamos as etapas a seguir.
Antes de iniciar a refragmentação, recomendamos o seguinte:
+ **Teste sua aplicação**: teste o comportamento da sua aplicação durante a refragmentação em um ambiente de preparação, se possível.
+ **Receba uma notificação prévia de problemas de escalabilidade**: a refragmentação é uma operação que demanda uso intensivo de computação. Por esse motivo, recomendamos manter a utilização da CPU abaixo de 80% em instâncias de vários núcleos e abaixo de 50% em instâncias de núcleo único durante a refragmentação. Monitore as métricas do ElastiCache para Redis OSS e inicie a refragmentação antes que a sua aplicação comece a observar problemas de escalabilidade. As métricas úteis para acompanhar são `CPUUtilization`, `NetworkBytesIn`, `NetworkBytesOut`, `CurrConnections`, `NewConnections`, `FreeableMemory`, `SwapUsage` e `BytesUsedForCacheItems`.
+ **Garanta memória livre suficiente disponível antes da redução de escala na horizontal**: se você estiver reduzindo a escala na horizontal, garanta que a memória livre disponível nos fragmentos a serem retidos é, pelo menos, 1,5 vez maior do que a memória usada nos fragmentos que você planeja remover.
+ **Inicie a refragmentação em horários fora de pico**: essa prática ajuda a reduzir a latência e o impacto de throughput no cliente durante a operação de refragmentação. Ela também ajuda a concluir a refragmentação com mais rapidez à medida que mais recursos podem ser usados na redistribuição de slots.
+ **Analise o comportamento de tempo limite do cliente**: alguns clientes podem observar maior latência durante o redimensionamento de cluster online. Configurar sua biblioteca de cliente com um tempo limite maior pode ajudar dando tempo para o sistema se conectar mesmo em condições de carga maiores no servidor. Em algum casos, você pode abrir um grande número de conexões com o servidor. Nesses casos, considere adicionar o recuo exponencial para uma nova conexão lógica. Fazer isso pode ajudar a evitar uma intermitência de novas conexões acessando o servidor ao mesmo tempo.
+ **Carregue suas funções em cada fragmento**: ao aumentar a escala horizontalmente do cluster, o ElastiCache replicará automaticamente as funções carregadas em um dos nós existentes (selecionados aleatoriamente) para os novos nós. Se seu cluster tiver o Valkey 7.2 ou posterior, ou Redis OSS 7.0 ou posterior, e sua aplicação usar [Funções](https://valkey.io/topics/functions-intro/), recomendamos carregar todas as suas funções em todos os fragmentos antes de aumentar a escala horizontalmente para que seu cluster não tenha funções diferentes em fragmentos diferentes.
Após a refragmentação, observe o seguinte:
+ A redução da escala horizontalmente pode ser parcialmente bem-sucedida se não houver memória suficiente disponível nos fragmentos de destino. Se isso ocorrer, analise a memória disponível e refaça a operação, se necessário. Os dados nos fragmentos de destino não serão excluídos.
+ Os comandos `FLUSHALL` e `FLUSHDB` não são compatíveis em scripts Lua durante uma operação de reestilhaçamento. Antes do Redis OSS 6, o comando `BRPOPLPUSH` não é compatível caso opere no slot que está sendo migrado.
# Minimização do tempo de inatividade durante a manutenção
A configuração do modo de cluster tem a melhor disponibilidade durante operações gerenciadas e não gerenciadas. Recomendamos usar um cliente compatível com o modo de cluster que se conecta ao endpoint de descoberta de cluster. Para o modo de cluster desabilitado recomendamos usar o endpoint principal para todas as operações de gravação.
Para atividades de leitura, os aplicativos também podem se conectar a qualquer nó no cluster. Ao contrário do endpoint primário, endpoints de nó são resolvidos para endpoints específicos. Se você fizer uma alteração no cluster, como adicionar ou excluir uma réplica, deverá atualizar os endpoints de nó no seu aplicativo. É por isso que, para o modo de cluster desabilitado, recomendamos que você use o endpoint do leitor para a atividade de leitura.
Se o failover automático estiver habilitado no cluster, o nó primário poderá ser alterado. Portanto, o aplicativo deve confirmar a função do nó e atualizar todos os endpoints de leitura. Fazer isso ajuda a garantir que não haja sobrecarga no nó principal. Com o failover automático desabilitado, a função do nó não é alterada. No entanto, o tempo de inatividade em operações gerenciadas ou não gerenciadas é maior em comparação ao dos clusters com failover automático habilitado.
Evite direcionar solicitações de leitura para um único nó de réplica de leitura, pois a indisponibilidade pode causar uma interrupção na leitura. Faça o fallback para a leitura pelo primário ou garanta que você tenha pelo menos duas réplicas de leitura para evitar qualquer interrupção de leitura durante a manutenção.
# Estratégias de armazenamento em cache para Memcached
No tópico a seguir, você pode encontrar estratégias para preencher e manter seu cache do Memcached.
Que estratégias implementar para preencher e manter seu cache dependem de quais dados você está armazenando em cache e dos padrões de acesso a eles. Por exemplo, você provavelmente não quer usar a mesma estratégia para um placar dos 10 primeiros colocados em um site de jogos e em notícias atuais. No restante desta seção, discutiremos estratégias comuns de manutenção de cache, suas vantagens e suas desvantagens.
**Topics**
+ [Réplicas de leitura](#Strategies.ReadReplicas)
+ [Carregamento lento](#Strategies.LazyLoading)
+ [Gravação simultânea](#Strategies.WriteThrough)
+ [Adicionar o TTL](#Strategies.WithTTL)
+ [Tópicos relacionados](#Strategies.SeeAlso)
## Réplicas de leitura
Muitas vezes, você pode melhorar significativamente o desempenho dos caches com tecnologia sem servidor do ElastiCache criando réplicas e lendo-as em vez do nó de cache primário. Para obter mais informações, consulte [Práticas recomendadas para usar réplicas de leitura](ReadReplicas.md).
## Carregamento lento
Como o nome indica, o *carregamento lento* é uma estratégia de cache que carrega dados no cache apenas quando necessário. Ele funciona como descrito a seguir.
O Amazon ElastiCache é um repositório de chaves-valores na memória entre a aplicação e o armazenamento de dados (banco de dados) que ele acessa. Sempre que a sua aplicação solicita dados, ela primeiro faz a solicitação ao cache do ElastiCache. Se os dados existirem no cache e forem atuais, o ElastiCache os retornará à sua aplicação. Se os dados não existirem no cache ou tiverem expirado, sua aplicação solicitará os dados do seu armazenamento de dados. Seu armazenamento de dados retorna os dados para sua aplicação. Sua aplicação, em seguida, grava os dados recebidos do armazenamento no cache. Dessa forma, eles podem ser recuperados mais rapidamente na próxima vez que forem solicitados.
Um *acerto de cache* ocorre quando os dados estão no cache e não estão expirados:
1. A aplicação solicita dados do cache.
1. O cache retorna os dados à aplicação.
Uma *perda de cache* ocorre quando os dados não estão no cache ou estão expirados:
1. Sua aplicação solicita dados do cache.
1. O cache não possui os dados solicitados e, portanto, retorna `null`.
1. Sua aplicação solicita e recebe os dados do banco de dados.
1. A aplicação atualiza o cache com os novos dados.
### Vantagens e desvantagens do carregamento lento
As vantagens do carregamento lento são as seguintes:
+ Apenas dados solicitados são armazenados em cache.
Como a maioria dos dados nunca é solicitada, o carregamento lento evita o preenchimento do cache com dados que não são solicitados.
+ Falhas de nó não são fatais para sua aplicação.
Quando um nó falha e é substituído por um novo nó vazio, sua aplicação continua a funcionar, embora com latência aumentada. À medida que as solicitações são feitas para o novo nó, cada perda de cache resulta em uma consulta do banco de dados. Ao mesmo tempo, a cópia de dados é adicionada ao cache para que as solicitações subsequentes sejam recuperadas do cache.
As desvantagens do carregamento lento são as seguintes:
+ Existe uma penalidade de ausência no cache. A perda de cache resulta em 3 viagens,
1. Solicitação inicial de dados do cache
1. Consulta do banco de dados para os dados
1. Gravação de dados no cache
Essas perdas podem causar um atraso observável na obtenção dos dados para a aplicação.
+ Dados obsoletos.
Se os dados forem gravados no cache somente quando houver uma perda de cache, os dados no cache poderão ficar obsoletos. Esse resultado ocorre porque não há atualizações para o cache quando os dados são alterados no banco de dados. Para resolver esse problema, você pode usar as estratégias [Gravação simultânea](#Strategies.WriteThrough) e [Adicionar o TTL](#Strategies.WithTTL).
### Exemplo de pseudocódigo de carregamento lento
O código a seguir é um exemplo de pseudocódigo de lógica de carregamento 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
```
Para este exemplo, o código da aplicação que obtém os dados é o seguinte.
```
customer_record = get_customer(12345)
```
## Gravação simultânea
A estratégia de gravação simultânea adiciona dados ou atualiza dados no cache sempre que eles são gravados no banco de dados.
### Vantagens e desvantagens da gravação simultânea
As vantagens da gravação simultânea são as seguintes:
+ Os dados no cache nunca são obsoletos.
Como os dados no cache são atualizados sempre que são escritos no banco de dados, eles sempre estão atualizados.
+ Penalidade de gravação versus penalidade de leitura.
Cada gravação envolve duas viagens:
1. Uma gravação no cache
1. Uma gravação no banco de dados
Que acrescenta latência ao processo. Dito isto, os usuários finais geralmente são mais tolerantes à latência ao atualizarem dados do que ao recuperarem dados. Existe um sentido inerente de que as atualizações são mais trabalhosas e, portanto, demoram mais.
As desvantagens da gravação simultânea são as seguintes:
+ Dados ausentes.
Se você cria um novo nó, seja devido a uma falha de nó ou ao aumento de escala na horizontal, haverá dados ausentes. Esses dados continuam ausentes até que sejam adicionados ou atualizados no banco de dados. Você pode minimizar isso implementando [carregamento lento](#Strategies.LazyLoading) com gravação simultânea.
+ Rotatividade do cache.
A maioria dos dados nunca é lida, o que é um desperdício de recursos. Ao [adicionar um valor de tempo de vida (TTL)](#Strategies.WithTTL), você pode minimizar o espaço desperdiçado.
### Exemplo de pseudocódigo de gravação simultânea
O código a seguir é um exemplo de pseudocódigo da lógica de gravação simultânea.
```
// *****************************************
// 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
```
Para este exemplo, o código da aplicação que obtém os dados é o seguinte.
```
save_customer(12345,{"address":"123 Main"})
```
## Adicionar o TTL
O carregamento lento permite dados obsoletos, mas não falha com nós vazios. A gravação simultânea garante que os dados sempre sejam atuais, mas pode falhar com nós vazios e pode preencher o cache com dados supérfluos. Ao adicionar um valor de tempo de vida (TTL) a cada gravação, você pode ter as vantagens de cada estratégia. Ao mesmo tempo, você pode em grande parte evitar desordenar o cache com dados adicionais.
*O Time to live (TTL) (Tempo de vida)* é um valor inteiro que especifica o número de segundos até a chave expirar. O Valkey ou Redis OSS pode especificar segundos ou milissegundos para este valor. O Memcached especifica este valor em segundos. Quando uma aplicação tenta ler uma chave expirada, isso é tratado como se a chave não fosse encontrada. O banco de dados é consultado para a chave e o cache é atualizado. Essa abordagem não garante que um valor não esteja obsoleto. Contudo, isso impede que os dados fiquem obsoletos demais e exige que os valores no cache sejam ocasionalmente atualizados a partir do banco de dados.
Para obter mais informações, consulte [os comandos Valkey ou Redis OSS](https://valkey.io/commands) ou os [comandos Memcached `set`](https://www.tutorialspoint.com/memcached/memcached_set_data.htm).
### Exemplos de pseudocódigo de TTL
O código a seguir é um exemplo de pseudocódigo da lógica de gravação simultânea com 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
```
O código a seguir é um exemplo de pseudocódigo de lógica de carregamento lento com 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
```
Para este exemplo, o código da aplicação que obtém os dados é o seguinte.
```
save_customer(12345,{"address":"123 Main"})
```
```
customer_record = get_customer(12345)
```
## Tópicos relacionados
+ [Armazenamento de dados na memória](elasticache-use-cases.md#elasticache-use-cases-data-store)
+ [Escolha de um mecanismo e versão](SelectEngine.md)
+ [Dimensionamento ElastiCache](Scaling.md)
# Gerenciando seu cluster baseado em nós no ElastiCache
ElastiCache oferece duas opções de implantação, caches sem servidor e clusters baseados em nós. Cada um tem suas próprias capacidades e requisitos.
Esta seção contém tópicos para ajudar você a gerenciar clusters baseados em nós.
**nota**
Esses tópicos não se aplicam ao ElastiCache Serverless.
**Topics**
+ [Auto Scaling de clusters Valkey e Redis OSS](AutoScaling.md)
+ [Modificar o modo de cluster](modify-cluster-mode.md)
+ [Replicação entre AWS regiões usando datastores globais](Redis-Global-Datastore.md)
+ [Alta disponibilidade com o uso de grupos de replicação](Replication.md)
+ [Gerenciamento de manutenção de cluster do ElastiCache](maintenance-window.md)
+ [Configuração de parâmetros do mecanismo usando grupos de parâmetros do ElastiCache](ParameterGroups.md)
# Auto Scaling de clusters Valkey e Redis OSS
## Pré-requisitos
ElastiCache O Auto Scaling está limitado ao seguinte:
+ Clusters Valkey ou Redis OSS (modo cluster habilitado) que executem o Valkey 7.2 em diante ou que executem o Redis OSS 6.0 em diante
+ Clusters em camadas de dados (modo cluster habilitado) que executem o Valkey 7.2 em diante ou que executem o Redis OSS 7.0.7 em diante
+ Tamanhos de instância - Grande XLarge, 2 XLarge
+ Famílias de tipo de instância: R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn
+ O Auto Scaling in não ElastiCache é compatível com clusters executados em datastores globais, Outposts ou Locais Zones.
## Gerenciando a capacidade automaticamente com o ElastiCache Auto Scaling com Valkey ou Redis OSS
ElastiCache o escalonamento automático com Valkey ou Redis OSS é a capacidade de aumentar ou diminuir automaticamente os fragmentos ou réplicas desejados em seu serviço. ElastiCache ElastiCache aproveita o serviço Application Auto Scaling para fornecer essa funcionalidade. Para obter mais informações, consulte [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html). Para usar o escalonamento automático, você define e aplica uma política de escalabilidade que usa CloudWatch métricas e valores-alvo que você atribui. ElastiCache o auto scaling usa a política para aumentar ou diminuir o número de instâncias em resposta às cargas de trabalho reais.
Você pode usar o Console de gerenciamento da AWS para aplicar uma política de escalabilidade com base em uma métrica predefinida. Uma `predefined metric` é definida em uma enumeração, para que você possa especificá-la por nome no código ou usá-la no Console de gerenciamento da AWS. As métricas personalizadas não estão disponíveis para seleção ao usar o Console de gerenciamento da AWS. Como alternativa, você pode usar a API Application Auto Scaling AWS CLI ou a Application Auto Scaling para aplicar uma política de escalabilidade com base em uma métrica predefinida ou personalizada.
ElastiCache para Valkey e Redis, o OSS suporta escalabilidade para as seguintes dimensões:
+ **Fragmentos**: adicionar/remover fragmentos automaticamente no cluster semelhantes à refragmentação manual online. Nesse caso, o escalonamento ElastiCache automático aciona o escalonamento em seu nome.
+ **Réplicas** — add/remove replicas in the cluster similar to manual Increase/Decrease replica operations. ElastiCache auto scaling for Valkey and Redis OSS adds/removes replica automaticamente de maneira uniforme em todos os fragmentos do cluster.
ElastiCache para Valkey e Redis, o OSS oferece suporte aos seguintes tipos de políticas de escalabilidade automática:
+ [Políticas de escalabilidade de rastreamento de destino](AutoScaling-Scaling-Policies-Target.md)— Aumente ou diminua o número de shards/replicas execuções do seu serviço com base em um valor alvo para uma métrica específica. Isso é semelhante à forma como o termostato mantém a temperatura da casa. Você seleciona a temperatura, e o termostato faz o resto.
+ [Escalabilidade programada para seu aplicativo.](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) — ElastiCache para Valkey e Redis, o escalonamento automático do OSS pode aumentar ou diminuir o número shards/replicas de execuções do seu serviço com base na data e hora.
![\[Imagem de escalonamento automático ElastiCache para Valkey e Redis OSS\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/Auto-scaling.png)
As etapas a seguir resumem o ElastiCache processo de escalonamento automático do Valkey e do Redis OSS, conforme mostrado no diagrama anterior:
1. Você cria uma política de escalabilidade ElastiCache automática para seu grupo de replicação.
1. ElastiCache o auto scaling cria um par de CloudWatch alarmes em seu nome. Cada par representa seus limites superiores e inferiores para métricas. Esses CloudWatch alarmes são acionados quando a utilização real do cluster se desvia da utilização desejada por um longo período de tempo. Agora, é possível visualizar os alarmes no console.
1. Se o valor da métrica configurada exceder sua meta de utilização (ou ficar abaixo da meta) por um período de tempo específico, CloudWatch acionará um alarme que invoca o escalonamento automático para avaliar sua política de escalabilidade.
1. ElastiCache o auto scaling emite uma solicitação de modificação para ajustar a capacidade do cluster.
1. ElastiCache processa a solicitação de modificação, aumentando (ou diminuindo) dinamicamente a Shards/Replicas capacidade do cluster para que ela se aproxime da utilização desejada.
Para entender como o ElastiCache Auto Scaling funciona, suponha que você tenha um cluster chamado. `UsersCluster` Ao monitorar as CloudWatch métricas`UsersCluster`, você determina o máximo de fragmentos que o cluster exige quando o tráfego está no pico e o mínimo de fragmentos quando o tráfego está no ponto mais baixo. Você também decide um valor-alvo para a utilização da CPU no `UsersCluster` cluster. ElastiCache o auto scaling usa seu algoritmo de rastreamento de metas para garantir que os fragmentos provisionados de `UsersCluster` sejam ajustados conforme necessário para que a utilização permaneça no valor alvo ou próximo dele.
**nota**
O escalonamento pode levar um tempo perceptível e exigirá recursos extras do cluster para que os fragmentos se rebalanceiem. ElastiCache O Auto Scaling modifica as configurações de recursos somente quando a carga de trabalho real permanece elevada (ou deprimida) por um período sustentado de vários minutos. O algoritmo de monitoramento do objetivo do ajuste de escala automático procura manter a utilização pretendida no valor escolhido ou próximo a ele em longo prazo.
# Políticas de Auto Scaling
Uma política de escalabilidade tem os seguintes componentes:
+ Uma métrica de destino: a métrica do CloudWatch que o ajuste de escala automático do ElastiCache para Valkey e Redis OSS usa para determinar o momento e a quantidade a escalar.
+ Capacidade mínima e máxima: o número mínimo e máximo de fragmentos a ser usado para a escalabilidade.
**Importante**
Ao criar a política de Auto Scaling, se a capacidade atual for maior do que a capacidade máxima configurada, reduzimos a escala na horizontal até MaxCapacity durante a criação da política. Da mesma forma, se a capacidade atual for menor do que a capacidade mínima configurada, aumentamos a escala na horizontal até MinCapacity.
+ Um período de desaquecimento: a quantidade de tempo, em segundos, que outra ação de aumento ou redução de escala na horizontal deve aguardar antes de ser iniciada, após a conclusão de uma ação de expansão ou redução.
+ Uma função vinculada a serviços: uma função do Identity and Access Management (IAM) da AWS vinculada a um serviço AWS específico. Uma função vinculada ao serviço inclui todas as permissões que o serviço exige para chamar todos os outros serviços da AWS em seu nome. O ajuste de escala automático do ElastiCache gera automaticamente essa função, `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG`, para você.
+ Habilitar ou desabilitar atividades de redução de escala na horizontal: capacidade de habilitar ou desabilitar atividades de redução de escala na horizontal para uma política.
**Topics**
+ [Métrica de destino para o Auto Scaling](#AutoScaling-TargetMetric)
+ [Capacidades mínima e máxima](#AutoScaling-MinMax)
+ [Período de desaquecimento](#AutoScaling-Cooldown)
+ [Habilitar ou desabilitar atividades de redução](#AutoScaling-enable-disable-scale-in)
## Métrica de destino para o Auto Scaling
Neste tipo de política, uma métrica predefinida ou personalizada e um valor de destino dessa métrica são especificados na configuração de uma política de escalabilidade de rastreamento de destino. O ajuste de escala automático do ElastiCache para Valkey e Redis OSS cria e gerencia os alarmes do CloudWatch que acionam a política de escalabilidade e calculam o ajuste de escalabilidade com base na métrica e no valor de destino. A política de escalabilidade adiciona ou remove fragmentos/réplicas conforme necessário para manter a métrica no valor de destino especificado ou próxima a ele. Além de manter a métrica próxima ao valor de destino, uma política de escalabilidade de rastreamento de destino também se ajusta às flutuações na métrica, devido a workloads variáveis. Essas políticas também minimizam flutuações rápidas no número de fragmentos/réplicas disponíveis para seu cluster.
Por exemplo, considere uma política de escalabilidade que use a métrica predefinida de média `ElastiCachePrimaryEngineCPUUtilization`. Essa política pode manter a utilização da CPU a um percentual de utilização específico, por exemplo, 70 por cento, ou próximo a isso.
**nota**
Para cada cluster, você pode criar somente uma política de Auto Scaling para cada métrica de destino.
## Capacidades mínima e máxima
**Fragmentos**
Você pode especificar o número máximo de fragmentos que podem ser escalados pelo ajuste de escala automático do ElastiCache para Valkey e Redis OSS. Esse valor deve ser menor que ou igual a 250, com um mínimo de 1. Você também pode especificar o número mínimo de fragmentos a serem gerenciados pelo ajuste de escala automático. O valor mínimo é 1, e deve ser menor ou igual ao valor especificado para o número máximo de fragmentos de 250.
**Réplicas**
Você pode especificar o número máximo de réplicas a serem gerenciadas pelo ajuste de escala automático do ElastiCache para Valkey e Redis OSS. Esse valor deve ser igual ou menor que 5. Você também pode especificar o número mínimo de réplicas a serem gerenciadas pelo ajuste de escala automático. O valor mínimo é 1, e deve ser menor ou igual ao valor especificado para o número máximo de réplicas de 5.
Para determinar o número mínimo e máximo de fragmentos/réplicas que você precisa para um tráfego típico, teste a configuração do Auto Scaling com a taxa esperada de tráfego para o modelo.
**nota**
As políticas de escalabilidade automática do ElastiCache aumentam a capacidade do cluster até atingir o tamanho máximo definido ou até que os limites do serviço sejam aplicados. Para solicitar um aumento de limite, consulte [Limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e selecione o tipo de limite **Nodes per cluster per instance type** (Nós por cluster por tipo de instância).
**Importante**
Redução de escala na horizontal quando não há tráfego Se o tráfego de uma variante atingir zero, o ElastiCache automaticamente reduz a escala na horizontal para o número mínimo de instâncias especificado.
## Período de desaquecimento
Você pode ajustar a responsividade das políticas de escalabilidade com monitoramento do objetivo, adicionando períodos de desaquecimento que afetam a escalabilidade de seu cluster. Um desaquecimento bloqueia solicitações subsequentes de redução ou expansão até o período expirar. Isso atrasa as exclusões de fragmentos/réplicas no cluster do ElastiCache para Valkey e Redis OSS para solicitações de redução de escala horizontal e a criação de fragmentos/réplicas para solicitações de aumento de escala horizontal. Você pode especificar os seguintes desaquecimentos:
+ A atividade de redução de escala horizontal diminui o número de fragmentos/réplicas em seu cluster. Um desaquecimento de redução especifica a quantidade de tempo, em segundos, após a conclusão de uma ação de redução antes que quaisquer outras atividades de redução possam iniciar.
+ A atividade de aumento de escala horizontal aumenta o número de fragmentos/réplicas em seu cluster. Um desaquecimento de expansão especifica a quantidade de tempo, em segundos, após a conclusão de uma ação de expansão antes que quaisquer outras atividades de expansão possam iniciar.
Quando o período de desaquecimento de redução ou aumento de escala na horizontal não é especificado, o padrão para o aumento é de 600 segundos, e para a redução, 900 segundos.
## Habilitar ou desabilitar atividades de redução
Você pode habilitar ou desabilitar atividades de redução para as políticas. Habilitar atividades de redução de escala na horizontal permite que as políticas de escalabilidade excluam fragmentos/réplicas. Quando as atividades de redução são habilitadas, o desaquecimento de redução na política de escalabilidade aplica-se a atividades de redução. Desabilitar atividades de redução de escala na horizontal evita que as políticas de escalabilidade excluam fragmentos/réplicas.
**nota**
As atividades de aumento de escala na horizontal são habilitadas para que a política de escalabilidade possa criar fragmentos ou réplicas do ElastiCache, conforme o necessário.
## Permissões do IAM necessárias para o Auto Scaling
ElastiCache para Valkey e Redis, o OSS Auto Scaling é possível graças a uma combinação do ElastiCache,, e do Application CloudWatch Auto Scaling. APIs Os clusters são criados e atualizados com ElastiCache, os alarmes são criados com CloudWatch e as políticas de escalabilidade são criadas com o Application Auto Scaling. Além das permissões padrão do IAM para criar e atualizar clusters, o usuário do IAM que acessa as configurações do ElastiCache Auto Scaling deve ter as permissões apropriadas para os serviços que oferecem suporte ao escalonamento dinâmico. Nessa política mais recente, adicionamos suporte à escalabilidade vertical do Memcached, com a ação `elasticache:ModifyCacheCluster`. Os usuários do IAM precisam ter as permissões para usar as ações exibidas na política de exemplo a seguir:
------
#### [ 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"
}
]
}
```
------
## Perfil vinculado a serviço
O serviço de escalonamento automático OSS ElastiCache para Valkey e Redis também precisa de permissão para descrever seus clusters CloudWatch e alarmes, além de permissões para modificar ElastiCache sua capacidade alvo em seu nome. Se você ativar o Auto Scaling em seu cluster, ele criará uma função vinculada ao serviço chamada `AWSServiceRoleForApplicationAutoScaling_ElastiCacheRG`. Essa função vinculada ao serviço concede permissão de escalonamento ElastiCache automático para descrever os alarmes de suas políticas, monitorar a capacidade atual da frota e modificar a capacidade da frota. A função vinculada ao serviço é a função padrão para o escalonamento ElastiCache automático. Para obter mais informações, consulte [Funções vinculadas a serviços ElastiCache para o escalonamento automático do Redis OSS no Guia do usuário do Application](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) Auto Scaling.
## Práticas recomendadas de escalabilidade automática
Antes de se registrar no Auto Scaling, recomendamos o seguinte:
1. **Use apenas uma métrica de monitoramento**: identifique se o cluster tem workloads com uso intenso da CPU ou de dados e use uma métrica predefinida correspondente para definir a política de ajuste de escala.
+ CPU do mecanismo: `ElastiCachePrimaryEngineCPUUtilization` (dimensão fragmentada) ou `ElastiCacheReplicaEngineCPUUtilization` (dimensão da réplica)
+ Uso do banco de dados: `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` essa política de ajuste de escala funciona melhor com maxmemory-policy definido como noeviction no cluster.
Recomendamos que você evite várias políticas por dimensão no cluster. ElastiCache para Valkey e Redis OSS, o Auto Scaling expandirá a meta escalável se alguma política de rastreamento de alvos estiver pronta para ser expandida, mas será ampliada somente se todas as políticas de rastreamento de alvos (com a parte de expansão ativada) estiverem prontas para serem ampliadas. Se várias políticas instruírem o destino escalável a aumentar ou reduzir a escala na horizontal ao mesmo tempo, ele escalará com base na política que forneça a maior capacidade tanto para reduzir quanto para aumentar a escala na horizontal.
1. **Métricas personalizadas para monitoramento do objetivo**: seja cauteloso ao usar métricas personalizadas para o monitoramento do objetivo, pois o ajuste de escala automático é mais adequado para aumentar/reduzir a escala horizontalmente de modo proporcional às alterações nas métricas escolhidas para a política. Se essas métricas não forem alteradas proporcionalmente às ações de ajuste de escala usadas para a criação de políticas, elas poderão aumentar ou reduzir a escala horizontalmente das ações de forma contínua, o que pode afetar a disponibilidade ou o custo.
Para clusters de armazenamento de dados em camadas (tipos de instância da família r6gd), evite usar métricas baseadas em memória para ajuste de escala.
1. **Escalabilidade programada** — Se você identificar que sua carga de trabalho é determinística (atinge high/low em um horário específico), recomendamos usar a escalabilidade programada e configurar sua capacidade alvo de acordo com a necessidade. O monitoramento do objetivo é mais adequado para workloads não determinísticas e para o cluster operar na métrica de destino necessária, aumentando a escala horizontalmente quando você precisar de mais recursos e reduzindo a escala horizontalmente quando precisar de menos recursos.
1. **Desative o escalonamento** — O escalonamento automático no Target Tracking é mais adequado para clusters com cargas increase/decrease de trabalho graduais, pois as métricas podem acionar oscilações consecutivas de spikes/dip escala/aumento. Para evitar tais oscilações, é possível começar com a opção de reduzir a escala horizontalmente desabilitada e, mais tarde, você pode reduzir a escala horizontalmente manualmente de acordo com sua necessidade.
1. **Teste seu aplicativo** — Recomendamos que você teste seu aplicativo com suas Min/Max cargas de trabalho estimadas para determinar o mínimo e o máximo absolutos shards/replicas necessários para o cluster enquanto cria políticas de escalabilidade para evitar problemas de disponibilidade. A autoescalabilidade pode aumentar a escala horizontalmente até o máximo e reduzir a escala horizontalmente até o mínimo limite configurado para o destino.
1. **Definindo o valor-alvo** — Você pode analisar CloudWatch as métricas correspondentes para a utilização do cluster em um período de quatro semanas para determinar o limite do valor-alvo. Se você ainda não tem certeza de qual valor escolher, recomendamos começar com o valor mínimo de métrica predefinida compatível.
1. AutoScaling on Target Tracking é mais adequado para clusters com distribuição uniforme de cargas de trabalho em todas as shards/replicas dimensões. Ter distribuição não uniforme pode levar a:
+ Dimensionamento quando não é necessário devido à carga de trabalho spike/dip em alguns fragmentos/réplicas quentes.
+ Não escalar quando necessário devido à média geral perto do destino, mesmo tendo fragmentos/réplicas quentes.
**nota**
Ao escalar seu cluster, ElastiCache replicará automaticamente as funções carregadas em um dos nós existentes (selecionados aleatoriamente) para o (s) novo (s) nó (s). Se seu cluster tiver o Valkey ou Redis OSS 7.0 ou posterior e sua aplicação usar [Funções](https://valkey.io/topics/functions-intro/), recomendamos carregar todas as suas funções em todos os fragmentos antes de aumentar a escala horizontalmente para que seu cluster não tenha funções diferentes em fragmentos diferentes.
Depois de se registrar AutoScaling, observe o seguinte:
+ Há limitações nas configurações compatíveis com a autoescalabilidade. Portanto, recomendamos que não altere a configuração de um grupo de replicação registrado para escalabilidade automática. Veja os exemplos a seguir:
+ Modificação manual do tipo de instância para tipos sem suporte.
+ Associação do grupo de replicação a um datastore global.
+ Alteração do parâmetro `ReservedMemoryPercent`.
+ increasing/decreasing shards/replicas beyond the Min/MaxCapacidade configurada manualmente durante a criação da política.
# Uso do Auto Scaling com fragmentos
Com o Auto Scaling do ElastiCache, você pode usar políticas programadas e de monitoramento com seu mecanismo Valkey ou Redis OSS.
O tópico seguinte fornece detalhes sobre o monitoramento do objetivo e as políticas programadas e como aplicá-las usando o Console de gerenciamento da AWS, a AWS CLI e APIs.
**Topics**
+ [Políticas de escalabilidade de rastreamento de destino](AutoScaling-Scaling-Policies-Target.md)
+ [Adicionar uma política de escalabilidade](AutoScaling-Scaling-Adding-Policy-Shards.md)
+ [Registro de um destino escalável](AutoScaling-Scaling-Registering-Policy-CLI.md)
+ [Definir uma política de escalabilidade](AutoScaling-Scaling-Defining-Policy-API.md)
+ [Desabilitar a atividade de redução](AutoScaling-Scaling-Disabling-Scale-in.md)
+ [Aplicar uma política de escalabilidade](AutoScaling-Scaling-Applying-a-Scaling-Policy.md)
+ [Editar uma política de escalabilidade](AutoScaling-Scaling-Editing-a-Scaling-Policy.md)
+ [Excluir uma política de escalabilidade](AutoScaling-Scaling-Deleting-a-Scaling-Policy.md)
+ [Use CloudFormation para políticas do Auto Scaling](AutoScaling-with-Cloudformation-Shards.md)
+ [Escalabilidade programada](AutoScaling-with-Scheduled-Scaling-Shards.md)
# Políticas de escalabilidade de rastreamento de destino
Com as políticas de dimensionamento com monitoramento do objetivo, você seleciona uma métrica e define um valor pretendido. O Auto Scaling do ElastiCache para Valkey e Redis OSS cria e gerencia os alarmes do CloudWatch que acionam a política de escalabilidade e calculam o ajuste de escalabilidade com base na métrica e no valor de destino. A política de escalabilidade adiciona ou remove fragmentos conforme necessário para manter a métrica no valor de destino especificado ou próxima a ele. Além de manter a métrica próxima ao valor de destino, uma política de escalabilidade de rastreamento de destino também se ajusta às flutuações na métrica, devido a um padrão de carga de flutuação, e minimiza as flutuações rápidas na capacidade da frota.
Por exemplo, considere uma política de escalabilidade que use a métrica predefinida de média `ElastiCachePrimaryEngineCPUUtilization` com valor de destino configurado. Essa política pode manter a utilização da CPU em, ou próxima do valor de destino especificado.
## Métricas predefinidas
Uma métrica predefinida é uma estrutura que se refere a um nome, dimensão e estatística (`average`) específicos de uma determinada métrica do CloudWatch. Sua política de ajuste de escala automático define as seguintes métricas predefinidas para seu cluster:
****
| Nome da métrica predefinida | Nome da métrica do CloudWatch | Diimensão da métrica do CloudWatch. | Tipos de instância inelegíveis |
| --- | --- | --- | --- |
| ElastiCachePrimaryEngineCPUUtilization | `EngineCPUUtilization` | ReplicationGroupId, Função = primária | Nenhum |
| ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage | `DatabaseCapacityUsageCountedForEvictPercentage` | Métricas do grupo de replicação do Valkey ou Redis OSS | Nenhum |
| ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage | `DatabaseMemoryUsageCountedForEvictPercentage` | Métricas do grupo de replicação do Valkey ou Redis OSS | R6gd |
Os tipos de instância em camadas de dados não podem usar `ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage`, pois esses tipos de instância armazenam dados na memória e no SSD. O caso de uso previsto para instâncias em camadas de dados é usar 100% de memória e preencher o SSD conforme necessário.
## Critérios do Auto Scaling para fragmentos
Quando o serviço detectar que sua métrica predefinida é igual ou maior que a configuração de destino, ele aumentará automaticamente a capacidade dos fragmentos. O ElastiCache para Valkey e Redis OSS aumenta a escala na horizontal dos fragmentos do seu cluster em uma contagem igual à maior de dois números: variação percentual do objetivo e 20% dos fragmentos atuais. Para reduzir a escala horizontalmente, o ElastiCache não fará a redução da escala na horizontal automaticamente a menos que o valor geral da métrica seja inferior a 75% do seu objetivo definido.
Para um exemplo de aumento de escala na horizontal, se você tiver 50 fragmentos e
+ se o seu objetivo violar em 30%, o ElastiCache aumentará a escala na horizontal em 30%, o que resultará em 65 fragmentos por cluster.
+ Se o seu objetivo violar em 10%, o ElastiCache aumentará a escala na horizontal em um mínimo padrão de 20%, o que resultará em 60 fragmentos por cluster.
Para um exemplo de redução de escala na horizontal, se você selecionou um valor de objetivo de 60%, o ElastiCache não reduzirá a escala na horizontal automaticamente até que a métrica seja menor ou igual a 45% (25% abaixo do objetivo de 60%).
## Considerações sobre o Auto Scaling
Lembre-se das seguintes considerações:
+ Uma política de escalabilidade de rastreamento de destino pressupõe que ela deve aumentar a escalabilidade quando a métrica especificada estiver acima do valor de destino. Você não pode usar uma política de escalabilidade de rastreamento de destino para expandir quando a métrica especificada estiver abaixo do valor de destino. O ElastiCache para Valkey e Redis OSS aumenta a escala na horizontal de fragmentos em um desvio mínimo de 20% do objetivo dos fragmentos existentes no cluster.
+ Uma política de escalabilidade de rastreamento de destino não escala quando a métrica especificada tem dados insuficientes. Ela não reduz a escala horizontalmente, porque não interpreta dados insuficientes como baixa utilização.
+ É possível ver lacunas entre o valor de destino e os pontos de dados de métrica reais. Isso ocorre porque o Auto Scaling do ElastiCache funciona de maneira segura por arredondamento para cima ou para baixo, quando ele determina a capacidade a ser adicionada ou removida. Isso evita que ele adicione capacidade insuficiente ou remova muita capacidade.
+ Para garantir a disponibilidade da aplicação, o serviço aumenta a escala na horizontal proporcionalmente à métrica o mais rápido possível, mas é reduz a escala na horizontal de forma mais conservadora.
+ Você pode ter várias políticas de escalabilidade com monitoramento do objetivo para um cluster do ElastiCache para Valkey e Redis OSS, desde que cada uma delas use uma métrica diferente. A intenção do ajuste de escala automático do ElastiCache é sempre priorizar a disponibilidade. Portanto, seu comportamento será diferente, se as políticas de monitoramento do objetivo estiverem prontas ou não para aumentar ou reduzir a escala horizontalmente. Ele vai aumentar o serviço se qualquer uma das políticas de monitoramento do objetivo estiverem prontas para aumentar, mas vai reduzir somente se todas as políticas de monitoramento do objetivo (com a parte de redução habilitada) estiverem prontas para reduzir.
+ Não edite nem exclua os alarmes do CloudWatch que o ajuste de escala automático do ElastiCache gerencia para uma política de escalabilidade com monitoramento do destino. O Auto Scaling do ElastiCache exclui os alarmes automaticamente quando você exclui a política de escalabilidade.
+ O Auto Scaling do ElastiCache não impede a modificação manual de fragmentos do cluster. Esses ajustes manuais não afetam alarmes existentes do CloudWatch que estejam conectados à política de escalabilidade, mas podem afetar métricas que possam acionar esses alarmes do CloudWatch.
+ Esses alarmes do CloudWatch gerenciados pelo Auto Scaling são definidos na métrica do AVG em todos os fragmentos do cluster. Assim, ter fragmentos quentes pode resultar em qualquer cenário de:
+ escalabilidade quando não for necessário devido à carga em alguns fragmentos quentes que acionam um alarme do CloudWatch
+ não escalar quando necessário devido ao AVG agregado em todos os fragmentos que afetam o alarme não violarem.
+ Os limites padrão do ElastiCache em nós por cluster ainda se aplicam. Então, ao optar pelo Auto Scaling, se você espera que os nós máximos sejam mais do que o limite padrão, solicite um aumento de limite em [Limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e escolha o tipo de limite **Nós por cluster por tipo de instância**.
+ Certifique-se de que você tenha ENIs (interfaces de rede elásticas) suficientes disponíveis em sua VPC, que são necessárias durante o aumento de escala na horizontal. Para obter mais informações, consulte [Interfaces de rede elástica](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html).
+ Se não houver capacidade suficiente disponível do EC2, o Auto Scaling do ElastiCache não ajustará a escala e atrasará até que a capacidade esteja disponível.
+ O Auto Scaling do ElastiCache para Redis OSS, durante a redução de escala na horizontal, não removerá fragmentos com slots com um tamanho de item maior que 256 MB pós-serialização.
+ Durante a redução de escala na horizontal, ele não removerá fragmentos se houver memória insuficiente disponível na configuração de fragmento resultante.
# Adicionar uma política de escalabilidade
Você pode adicionar uma política de escalabilidade usando o Console de gerenciamento da AWS.
**Para adicionar uma política do Auto Scaling a um cluster do ElastiCache para Valkey e Redis OSS**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS**.
1. Selecione o cluster ao qual você deseja adicionar uma política (escolha o botão à esquerda do nome do cluster).
1. Selecione a guia **Auto Scaling policies** (Políticas do Auto Scaling).
1. Escolha **add dynamic scaling** (adicionar escalabilidade dinâmica).
1. Em **Policy Name** (Nome da política), insira um nome para a política.
1. Em **Scalable Dimension** (Dimensão escalável), escolha **shards** (fragmentos).
1. Quanto à métrica de destino, escolha uma das seguintes opções:
+ **Primary CPU Utilization** (Utilização da CPU primária) para criar uma política com base na utilização média da CPU.
+ **Memory** (Memória) para criar uma política com base na memória média do banco de dados.
+ **Capacidade** de criar uma política com base no uso médio da capacidade do banco de dados. A métrica de capacidade inclui a utilização de memória e SSD para instâncias em camadas de dados e a utilização da memória para todos os outros tipos de instância.
1. Para o valor alvo, escolha um valor maior ou igual a 35 e menor ou igual a 70. O ajuste de escala automático manterá esse valor para a métrica de destino selecionada em seus fragmentos do ElastiCache:
+ **Utilização primária da CPU**: mantém o valor alvo da métrica `EngineCPUUtilization` nos nós primários.
+ **Memória**: mantém o valor alvo da métrica `DatabaseMemoryUsageCountedForEvictPercentage`
+ **Capacidade**: mantém o valor alvo da métrica `DatabaseCapacityUsageCountedForEvictPercentage`
Os fragmentos do cluster serão adicionados ou removidos para manter a métrica próxima ao valor especificado.
1. (Opcional) Não há suporte do console para os períodos de desaquecimento de redução ou aumento de escala na horizontal. Use a AWS CLI para modificar os valores de desaquecimento.
1. Em **Capacidade mínima**, insira o número mínimo de fragmentos que a política do Auto Scaling do ElastiCache é solicitada a manter.
1. Em **Capacidade máxima**, insira o número máximo de fragmentos que a política do Auto Scaling do ElastiCache é solicitada a manter. Esse valor deve ser igual ou menor que 250.
1. Escolha **Criar**.
# Registro de um destino escalável
Antes de poder usar o Auto Scaling com um cluster do ElastiCache para Valkey e Redis OSS, você deve registrar seu cluster no ajuste de escala automático do ElastiCache. Faça isso para definir a dimensão de escalabilidade e os limites a serem aplicados no cluster. O ajuste de escala automático do ElastiCache escala dinamicamente o cluster ao longo da dimensão escalável `elasticache:replication-group:NodeGroups`, que representa o número de fragmentos de cluster.
**Como usar a AWS CLI**
Para registrar o cluster do ElastiCache para Valkey e Redis OSS, use o comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) com os seguintes parâmetros:
+ `--service-namespace`: defina o valor como `elasticache`
+ `--resource-id`: o identificador do recurso para o cluster. Para este parâmetro, o tipo de recurso é `ReplicationGroup` e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ `--scalable-dimension`: defina este valor como `elasticache:replication-group:NodeGroups`.
+ `--max-capacity `: o número máximo de fragmentos a serem gerenciados pelo ajuste de escala automático do ElastiCache. Para obter informações sobre a relação entre `--min-capacity`, `--max-capacity` e o número de fragmentos em seu cluster, consulte [Capacidades mínima e máxima](AutoScaling-Policies.md#AutoScaling-MinMax).
+ `--min-capacity `: o número mínimo de fragmentos a serem gerenciados pelo ajuste de escala automático do ElastiCache. Para obter informações sobre a relação entre `--min-capacity`, `--max-capacity` e o número de fragmentos em seu cluster, consulte [Capacidades mínima e máxima](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
No exemplo a seguir, registre um cluster do ElastiCache de nome `myscalablecluster`. O registro indica que o cluster deve ser escalado dinamicamente para ter de um a dez fragmentos.
Para Linux, macOS ou 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 \
```
Para 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 ^
```
**Usar a API**
Para registrar o cluster do ElastiCache, use o comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) com os seguintes parâmetros:
+ ServiceNamespace: defina este valor como elasticache.
+ ResourceID: o identificador de recursos para o cluster do ElastiCache. Para este parâmetro, o tipo de recurso é ReplicationGroup e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ ScalableDimension: defina este valor como `elasticache:replication-group:NodeGroups`.
+ MinCapacity: o número mínimo de fragmentos a serem gerenciados pelo ajuste de escala automático do ElastiCache. Para obter informações sobre a relação entre --min-capacity, --max-capacity e o número de réplicas no cluster, consulte [Capacidades mínima e máxima](AutoScaling-Policies.md#AutoScaling-MinMax).
+ MaxCapacity: o número máximo de fragmentos a serem gerenciados pelo ajuste de escala automático do ElastiCache. Para obter informações sobre a relação entre --min-capacity, --max-capacity e o número de réplicas no cluster, consulte [Capacidades mínima e máxima](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
No exemplo a seguir, registre um cluster do ElastiCache chamado `myscalablecluster` na API do Application Auto Scaling. Este registro indica que o cluster deve ser escalado dinamicamente para ter de uma a 5 réplicas.
```
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
}
```
# Definir uma política de escalabilidade
Uma configuração de política de escalabilidade de rastreamento de destino é representada por um bloco JSON no qual as métricas e valores de destino são definidos. Você pode salvar uma configuração de política de escalabilidade como um bloco JSON em um arquivo de texto. Você pode usar esse arquivo de texto ao invocar a AWS CLI ou a API do Application Auto Scaling. Para obter mais informações sobre a sintaxe de configuração de política, consulte [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) na Referência da API do Application Auto Scaling.
As seguintes opções estão disponíveis para definir uma configuração de política de escalabilidade com monitoramento do objetivo:
**Topics**
+ [Uso de uma métrica predefinida](#AutoScaling-Scaling-Predefined-Metric)
+ [Uso de uma métrica personalizada](#AutoScaling-Scaling-Custom-Metric)
+ [Uso de períodos de desaquecimento](#AutoScaling-Scaling-Cooldown-periods)
## Uso de uma métrica predefinida
Com o uso de métricas predefinidas, você pode definir rapidamente uma política de escalabilidade com monitoramento do objetivo para um cluster do ElastiCache para Valkey e Redis OSS que funcione com o monitoramento do objetivo no ajuste de escala automático do ElastiCache.
Atualmente, o ElastiCache oferece suporte às seguintes métricas predefinidas no Auto Scaling do NodeGroup:
+ **ElastiCachePrimaryEngineCPUUtilization**: o valor médio da métrica `EngineCPUUtilization` no CloudWatch em todos os nós primários no cluster.
+ **ElastiCacheDatabaseMemoryUsageCountedForEvictPercentage**: o valor médio da métrica `DatabaseMemoryUsageCountedForEvictPercentage` no CloudWatch em todos os nós primários no cluster.
+ **ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage**: o valor médio da métrica `ElastiCacheDatabaseCapacityUsageCountedForEvictPercentage` no CloudWatch em todos os nós primários no cluster.
Para ter mais informações sobre as métricas `EngineCPUUtilization`, `DatabaseMemoryUsageCountedForEvictPercentage` e `DatabaseCapacityUsageCountedForEvictPercentage`, consulte [Monitorando o uso com CloudWatch métricas](CacheMetrics.md). Para usar uma métrica predefinida em sua política de escalabilidade, crie uma configuração de rastreamento de destino para sua política de escalabilidade. Essa configuração deve incluir uma `PredefinedMetricSpecification` para a métrica predefinida e um TargetValue para o valor de destino dessa métrica.
**Example**
O exemplo a seguir descreve uma configuração de política típica para a escalabilidade com monitoramento do objetivo para um cluster do ElastiCache para Valkey e Redis OSS. Nessa configuração, a métrica predefinida `ElastiCachePrimaryEngineCPUUtilization` é usada para ajustar o cluster com base em uma utilização média da CPU de 40 por cento em todos os nós primários no cluster.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
}
}
```
## Uso de uma métrica personalizada
Com o uso de métricas personalizadas, você pode definir uma política de escalabilidade de rastreamento de destino que atenda a suas exigências personalizadas. Você pode definir uma métrica personalizada com base em qualquer métrica do ElastiCache que mude na proporção da escalabilidade. Nem todas as métricas do ElastiCache funcionam para o monitoramento do objetivo. A métrica deve ser de utilização válida e descrever o quão ocupada uma instância está. O valor da métrica deve aumentar ou diminuir na proporção do número de fragmentos no cluster. Essa aumento ou redução proporcional é necessário para usar os dados da métrica para expandir ou reduzir proporcionalmente o número de fragmentos.
**Example**
O exemplo a seguir descreve uma configuração de rastreamento de destino para uma política de escalabilidade. Nessa configuração, uma métrica personalizada ajusta um cluster do ElastiCache for Redis OSS com base na utilização média de uma CPU em 50 por centro em todos os fragmentos em um cluster chamado `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"
}
}
```
## Uso de períodos de desaquecimento
Você pode especificar um valor, em segundos, para `ScaleOutCooldown` a fim de adicionar um desaquecimento para expandir seu cluster. De forma similar, você pode adicionar um valor, em segundos, para `ScaleInCooldown` a fim de adicionar um período de desaquecimento para reduzir a escala na horizontal do seu cluster. Para obter mais informações, consulte [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) na Referência da API do Application Auto Scaling.
O exemplo a seguir descreve uma configuração de rastreamento de destino para uma política de escalabilidade. Nessa configuração, a métrica predefinida `ElastiCachePrimaryEngineCPUUtilization` é usada para ajustar um cluster do ElastiCache para Redis OSS com base em uma utilização média da CPU de 40 por cento em todos os nós primários do cluster. A configuração fornece um período de espera de 10 minutos para reduzir a escala horizontalmente, e um período de espera de 5 minutos para aumentar a escala horizontalmente.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
# Desabilitar a atividade de redução
Você pode evitar que a configuração da política de escalabilidade com monitoramento de objetivo reduza a escala na horizontal de seu cluster desabilitando a atividade de redução de escala horizontal. Desabilitar a atividade de redução de escala na horizontal impede que a política de escalabilidade exclua fragmentos, enquanto permite ao mesmo tempo que a política de escalabilidade crie-os conforme necessário.
Você pode especificar um valor booleano para `DisableScaleIn` a fim de permitir ou evitar a atividade de redução de escala na horizontal no seu cluster. Para obter mais informações, consulte [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) na Referência da API do Application Auto Scaling.
O exemplo a seguir descreve uma configuração de rastreamento de destino para uma política de escalabilidade. Nessa configuração, a métrica predefinida `ElastiCachePrimaryEngineCPUUtilization` ajusta um cluster do ElastiCache para Valkey e Redis OSS com base em uma utilização média da CPU de 40 por cento em todos os nós primários do cluster. A configuração desativa a atividade de redução para a política de escalabilidade.
```
{
"TargetValue": 40.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ElastiCachePrimaryEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
# Aplicar uma política de escalabilidade
Após registrar seu cluster com o ajuste de escala automático do ElastiCache para Valkey e Redis OSS e definir uma política de escalabilidade, aplique a política de escalabilidade ao cluster registrado. Para aplicar uma política de escalabilidade a um cluster do ElastiCache para Redis OSS, você pode usar a AWS CLI ou a API do Application Auto Scaling.
## Aplicação de uma política de escalabilidade usando a AWS CLI
Para aplicar uma política de escalabilidade a seu cluster do ElastiCache para Valkey e Redis OSS, use o comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) com os seguintes parâmetros:
+ **--policy-name**: o nome da política de escalabilidade.
+ **--policy-type**: defina este valor como `TargetTrackingScaling`.
+ **--resource-id**: o identificador do recurso. Para este parâmetro, o tipo de recurso é `ReplicationGroup` e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ **--service-namespace**: defina este valor como `elasticache`.
+ **--scalable-dimension**: defina este valor como `elasticache:replication-group:NodeGroups`.
+ **--target-tracking-scaling-policy-configuration**: a configuração da política de escalabilidade com monitoramento do objetivo a ser usada para o cluster.
No exemplo a seguir, é aplicada uma política de escalabilidade com monitoramento do objetivo chamada `myscalablepolicy` a um cluster do ElastiCache para Valkey e Redis OSS chamado `myscalablecluster` com o ajuste de escala automático do ElastiCache. Para fazer isso, use uma configuração de política salva em um arquivo chamado `config.json`.
Para Linux, macOS ou 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
```
Para 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
```
## Aplicação de uma política de escalabilidade usando a API
Para aplicar uma política de escalabilidade a seu cluster do ElastiCache para Valkey e Redis OSS, use o comando da AWS CLI [PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) com os seguintes parâmetros:
+ **--policy-name**: o nome da política de escalabilidade.
+ **--resource-id**: o identificador do recurso. Para este parâmetro, o tipo de recurso é `ReplicationGroup` e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ **--service-namespace**: defina este valor como `elasticache`.
+ **--scalable-dimension**: defina este valor como `elasticache:replication-group:NodeGroups`.
+ **--target-tracking-scaling-policy-configuration**: a configuração da política de escalabilidade com monitoramento do objetivo a ser usada para o cluster.
No exemplo a seguir, aplique a política de escalabilidade com monitoramento do objetivo chamada `myscalablepolicy` para um cluster do ElastiCache chamado `myscalablecluster` com a escalabilidade automática do ElastiCache. Use uma configuração de política com base na métrica predefinida `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"
}
}
}
```
# Editar uma política de escalabilidade
Você pode editar uma política de escalabilidade usando o Console de gerenciamento da AWS, a AWS CLI ou a API do Application Auto Scaling.
## Editar uma política de escalabilidade usando o Console de gerenciamento da AWS
**Para editar uma política de ajuste de escala automático em um cluster do ElastiCache para Valkey e Redis OSS**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, selecione o mecanismo apropriado.
1. Selecione o cluster ao qual você deseja adicionar uma política (escolha o botão à esquerda do nome do cluster).
1. Selecione a guia **Auto Scaling policies** (Políticas do Auto Scaling).
1. Em **Scaling policies** (Políticas de escalabilidade), escolha o botão à esquerda da política de autoescalabilidade que você deseja alterar e selecione **Modify** (Modificar).
1. Faça as alterações necessárias na política.
1. Escolha **Modificar**.
## Edição de uma política de escalabilidade usando a AWS CLI e a API
Você pode usar a AWS CLI ou a API do Application Auto Scaling para editar uma política de escalabilidade da mesma forma que você aplica uma política de escalabilidade:
+ Ao usar a AWS CLI, especifique o nome da política que você deseja editar no parâmetro `--policy-name`. Especifique novos valores para os parâmetros que você deseja alterar.
+ Ao usar a API do Application Auto Scaling, especifique o nome da política que você deseja editar no parâmetro `PolicyName`. Especifique novos valores para os parâmetros que você deseja alterar.
Para obter mais informações, consulte [Aplicar uma política de escalabilidade](AutoScaling-Scaling-Applying-a-Scaling-Policy.md).
# Excluir uma política de escalabilidade
Você pode excluir uma política de escalabilidade usando o Console de gerenciamento da AWS, a AWS CLI ou a API do Application Auto Scaling.
## Excluir uma política de escalabilidade usando o Console de gerenciamento da AWS
**Para excluir uma política do Auto Scaling de um cluster do ElastiCache para Redis OSS**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS**.
1. Escolha o cluster cuja política de autoescalabilidade você deseja editar (selecione o nome do cluster, e não o botão à esquerda).
1. Selecione a guia **Auto Scaling policies** (Políticas do Auto Scaling).
1. Na seção **Auto scaling policies** (Políticas de autoescalabilidade), escolha a respectiva política e selecione **Delete** (Excluir).
## Excluir uma política de escalabilidade usando o AWS CLI
Para excluir uma política de escalabilidade do seu cluster do ElastiCache para Valkey e Redis OSS, use o comando [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI com os seguintes parâmetros:
+ **--policy-name**: o nome da política de escalabilidade.
+ **--resource-id**: o identificador do recurso. Para este parâmetro, o tipo de recurso é `ReplicationGroup` e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ **--service-namespace**: defina este valor como `elasticache`.
+ **--scalable-dimension**: defina este valor como `elasticache:replication-group:NodeGroups`.
No exemplo a seguir, a política de escalabilidade com monitoramento do objetivo chamada `myscalablepolicy` é excluída de um cluster chamado `myscalablecluster`.
Para Linux, macOS ou Unix:
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:NodeGroups
```
Para Windows:
```
aws application-autoscaling delete-scaling-policy ^
--policy-name myscalablepolicy ^
--resource-id replication-group/myscalablecluster ^
--service-namespace elasticache ^
--scalable-dimension elasticache:replication-group:NodeGroups
```
## Exclusão de uma política de escalabilidade usando a API
Para excluir uma política de escalabilidade do seu cluster do ElastiCache para Valkey e Redis OSS, use o comando [DeleteScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-scaling-policy.html) AWS CLI com os seguintes parâmetros:
+ **--policy-name**: o nome da política de escalabilidade.
+ **--resource-id**: o identificador do recurso. Para este parâmetro, o tipo de recurso é `ReplicationGroup` e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ **--service-namespace**: defina este valor como `elasticache`.
+ **--scalable-dimension**: defina este valor como `elasticache:replication-group:NodeGroups`.
No exemplo a seguir, a política de escalabilidade com monitoramento do objetivo chamada `myscalablepolicy` é excluída de um cluster chamado `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"
}
```
# Use CloudFormation para políticas do Auto Scaling
Este trecho mostra como criar uma política com monitoramento do objetivo e aplicá-la a um recurso [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html) usando o recurso [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html). Ela usa as funções intrínsecas [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) para construir a propriedade `ResourceId` com o nome lógico do recurso `AWS::ElastiCache::ReplicationGroup` especificado no mesmo modelo.
```
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
```
# Escalabilidade programada
A escalabilidade com base em uma programação permite que você dimensione sua aplicação em resposta a alterações de demanda. Para usar a escalabilidade programada, você deve criar ações programadas, que instruem o ElastiCache para Valkey e Redis OSS a executar ações de escalabilidade em momentos específicos. Quando você cria uma ação programada, especifica um cluster existente, quando a ação de escalabilidade deve ocorrer, a capacidade mínima e a capacidade máxima. É possível criar ações programadas para escalar uma única vez ou de forma programada.
Você só pode criar uma ação programada para clusters que já existam. Você não pode criar uma ação programada ao mesmo tempo em que você cria um cluster.
Para obter mais informações sobre terminologia para criação, gerenciamento e exclusão de ações programadas, consulte [Comandos normalmente usados para criação, gerenciamento e exclusão de ações programadas](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)
**Para criar em uma programação recorrente:**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS**.
1. Escolha o cluster ao qual você deseja adicionar uma política.
1. Escolha **Manage Auto Scaling policies** (Gerenciar políticas do Auto Scaling) no menu suspenso **Actions** (Ações).
1. Escolha a guia **Auto Scaling policies** (Políticas do Auto Scaling).
1. Na seção **Auto Scaling policies** (Políticas de Auto Scaling), a caixa de diálogo **Add Scaling policy** (Adicionar política de escalabilidade) será exibida. Escolha **Scheduled scaling** (Escalabilidade programada).
1. Em **Policy Name** (Nome da política), insira um nome para a política.
1. Em **Scalable Dimension** (Dimensão escalável), escolha **Shards** (Fragmentos).
1. Em **Target Shards** (Fragmentos de destino), escolha o valor.
1. Em **Recurrence** (Recorrência), escolha **Recurring** (Recorrente).
1. Em **Frequency** (Frequência), escolha o respectivo valor.
1. Em **Start Date** (Data de início) e **Start time** (Horário de início), escolha o horário a partir do qual a política entrará em vigor.
1. Escolha **Add policy** (Adicionar política).
**Para criar uma ação programada para executar uma única vez:**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS**.
1. Escolha o cluster ao qual você deseja adicionar uma política.
1. Escolha **Manage Auto Scaling policies** (Gerenciar políticas do Auto Scaling) no menu suspenso **Actions** (Ações).
1. Escolha a guia **Auto Scaling policies** (Políticas do Auto Scaling).
1. Na seção **Auto Scaling policies** (Políticas de Auto Scaling), a caixa de diálogo **Add Scaling policy** (Adicionar política de escalabilidade) será exibida. Escolha **Scheduled scaling** (Escalabilidade programada).
1. Em **Policy Name** (Nome da política), insira um nome para a política.
1. Em **Scalable Dimension** (Dimensão escalável), escolha **Shards** (Fragmentos).
1. Em **Target Shards** (Fragmentos de destino), escolha o valor.
1. Em **Recurrence** (Recorrência), escolha **One Time** (Uma vez).
1. Em **Start Date** (Data de início) e **Start time** (Horário de início), escolha o horário a partir do qual a política entrará em vigor.
1. Em **End Date** (Data de término), escolha a data até quando a política estará em vigor.
1. Escolha **Add policy** (Adicionar política).
**Para excluir uma ação programada**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS**.
1. Escolha o cluster ao qual você deseja adicionar uma política.
1. Escolha **Manage Auto Scaling policies** (Gerenciar políticas do Auto Scaling) no menu suspenso **Actions** (Ações).
1. Escolha a guia **Auto Scaling policies** (Políticas do Auto Scaling).
1. Na seção **Auto scaling policies** (Políticas do Auto Scaling), escolha a política do Auto Scaling e depois escolha **Delete** (Excluir) na caixa de diálogo **Actions** (Ações).
**Para gerenciar a escalabilidade programada usando o AWS CLI **
Use as seguintes APIs de application-autoscaling:
+ [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)
## Use CloudFormation para criar uma ação programada
Este trecho mostra como criar uma política com monitoramento do objetivo e aplicá-la a um recurso [AWS::ElastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html) usando o recurso [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html). Ela usa as funções intrínsecas [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) para construir a propriedade `ResourceId` com o nome lógico do recurso `AWS::ElastiCache::ReplicationGroup` especificado no mesmo modelo.
```
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 * * ? *)'
```
# Usar o ajuste de escala automático com réplicas
Um grupo de replicação do ElastiCache pode configurar um ou mais caches para funcionar como um único nó lógico.
O tópico seguinte fornece detalhes sobre o monitoramento do objetivo e as políticas programadas e como aplicá-las usando o Console de gerenciamento da AWS, a AWS CLI e APIs.
# Políticas de escalabilidade de rastreamento de destino
Com as políticas de dimensionamento com monitoramento do objetivo, você seleciona uma métrica e define um valor pretendido. O Auto Scaling do ElastiCache para Valkey e Redis OSS cria e gerencia os alarmes do CloudWatch que acionam a política de escalabilidade e calculam o ajuste de escalabilidade com base na métrica e no valor de destino. A política de escalabilidade adiciona ou remove réplicas uniformemente ao longo de todos os fragmentos conforme necessário para manter a métrica no valor de destino especificado ou próxima a ele. Além de manter a métrica próxima ao valor de destino, uma política de escalabilidade de rastreamento de destino também se ajusta às flutuações na métrica, devido a um padrão de carga de flutuação, e minimiza as flutuações rápidas na capacidade da frota.
## Critérios do Auto Scaling para réplicas
Sua política do Auto Scaling define a seguinte métrica predefinida para seu cluster:
`ElastiCacheReplicaEngineCPUUtilization`: o limite de utilização de AVG EngineCPU agregado em todas as réplicas usadas pelo ElastiCache para acionar uma operação de ajuste de escala automático. Você pode definir a meta de utilização entre 35% e 70%.
Quando o serviço detectar que sua métrica `ElastiCacheReplicaEngineCPUUtilization` é igual ou maior que a configuração de destino, ele aumentará automaticamente as réplicas nos fragmentos. O ElastiCache aumenta a escala na horizontal das réplicas do seu cluster em uma contagem igual ao maior de dois números: variação percentual do objetivo e uma réplica. Para reduzir a escala horizontalmente, o ElastiCache não fará a redução da escala na horizontal automaticamente a menos que o valor geral da métrica seja inferior a 75% do seu objetivo definido.
Para um exemplo de aumento de escala na horizontal, se você tiver 5 fragmentos e 1 réplica cada:
Se o seu objetivo for violado em 30%, o ElastiCache para Valkey e Redis OSS aumentará a escala horizontalmente em 1 réplica (máximo (0,3, padrão 1)) em todos os fragmentos, o que resulta em 5 fragmentos com 2 réplicas cada.
Para um exemplo de redução de escala na horizontal, se você selecionou um valor de objetivo de 60%, o ElastiCache para Valkey e Redis OSS não reduzirá a escala na horizontal automaticamente até que a métrica seja menor ou igual a 45% (25% abaixo do objetivo de 60%).
### Considerações sobre o Auto Scaling
Lembre-se das seguintes considerações:
+ Uma política de escalabilidade de rastreamento de destino pressupõe que ela deve aumentar a escalabilidade quando a métrica especificada estiver acima do valor de destino. Você não pode usar uma política de escalabilidade de rastreamento de destino para expandir quando a métrica especificada estiver abaixo do valor de destino. O ElastiCache para Valkey e Redis OSS aumenta a escala na horizontal de réplicas em um máximo de (% de desvio arredondado do objetivo, padrão 1) de réplicas existentes em todos os fragmentos no cluster.
+ Uma política de escalabilidade de rastreamento de destino não escala quando a métrica especificada tem dados insuficientes. Ela não aumenta a escalabilidade porque não interpreta dados insuficientes como baixa utilização.
+ É possível ver lacunas entre o valor de destino e os pontos de dados de métrica reais. Isso ocorre porque o Auto Scaling do ElastiCache funciona de maneira segura por arredondamento para cima ou para baixo, quando ele determina a capacidade a ser adicionada ou removida. Isso evita que ele adicione capacidade insuficiente ou remova muita capacidade.
+ Para garantir a disponibilidade da aplicação, o serviço aumenta a escala na horizontal proporcionalmente à métrica o mais rápido possível, mas reduz a escala na horizontal mais gradualmente, com redução máxima de escala de 1 réplica ao longo dos fragmentos no cluster.
+ Você pode ter várias políticas de escalabilidade com monitoramento do objetivo para um cluster do ElastiCache para Valkey e Redis OSS, desde que cada uma delas use uma métrica diferente. A intenção do Auto Scaling é sempre priorizar a disponibilidade. Portanto, seu comportamento será diferente, se as políticas de monitoramento do objetivo estiverem prontas ou não para aumentar ou reduzir a escala horizontalmente. Ele vai aumentar o serviço se qualquer uma das políticas de monitoramento do objetivo estiverem prontas para aumentar, mas vai reduzir somente se todas as políticas de monitoramento do objetivo (com a parte de redução habilitada) estiverem prontas para reduzir.
+ Não edite nem exclua os alarmes do CloudWatch que o ajuste de escala automático do ElastiCache gerencia para uma política de escalabilidade com monitoramento do destino. O Auto Scaling exclui os alarmes automaticamente quando você exclui a política de escalabilidade ou exclui o cluster.
+ O ajuste de escala automático do ElastiCache não impede a modificação manual de réplicas nos fragmentos. Esses ajustes manuais não afetam alarmes existentes do CloudWatch que estejam conectados à política de escalabilidade, mas podem afetar métricas que possam acionar esses alarmes do CloudWatch.
+ Esses alarmes do CloudWatch gerenciados pelo Auto Scaling são definidos na métrica do AVG em todos os fragmentos do cluster. Assim, ter fragmentos quentes pode resultar em qualquer cenário de:
+ escalabilidade quando não for necessário devido à carga em alguns fragmentos quentes que acionam um alarme do CloudWatch
+ não escalar quando necessário devido ao AVG agregado em todos os fragmentos que afetam o alarme não violarem.
+ Os limites padrão do ElastiCache em nós por cluster ainda se aplicam. Então, ao optar pelo Auto Scaling, se você espera que os nós máximos sejam mais do que o limite padrão, solicite um aumento de limite em [Limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e escolha o tipo de limite **Nós por cluster por tipo de instância**.
+ Certifique-se de que você tenha ENIs (interfaces de rede elásticas) suficientes disponíveis em sua VPC, que são necessárias durante o aumento de escala na horizontal. Para obter mais informações, consulte [Interfaces de rede elástica](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html).
+ Se não houver capacidade suficiente disponível no EC2, o ajuste de escala automático do ElastiCache não aumentará a escala na horizontal até que a capacidade esteja disponível ou se você modificar manualmente o cluster para os tipos de instância que têm capacidade suficiente.
+ O ajuste de escala automático do ElastiCache não oferece suporte à escalabilidade de réplicas com um cluster tendo `ReservedMemoryPercent` menos que 25%. Para obter mais informações, consulte [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md).
# Adicionar uma política de escalabilidade
Você pode adicionar uma política de escalabilidade usando o Console de gerenciamento da AWS.
**Adicionar uma política de escalabilidade usando o Console de gerenciamento da AWS**
Para adicionar uma política de ajuste de escala automático ao ElastiCache para Valkey e Redis OSS
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS**.
1. Selecione o cluster ao qual você deseja adicionar uma política (escolha o botão à esquerda do nome do cluster).
1. Selecione a guia **Auto Scaling policies** (Políticas do Auto Scaling).
1. Escolha **add dynamic scaling** (adicionar escalabilidade dinâmica).
1. Em **Scaling Policies** (Políticas de escalabilidade), escolha **Add dnynamic scaling** (Adicionar escalabilidade dinâmica).
1. Em **Policy Name** (Nome da política), insira um nome para a política.
1. Em **Scalable Dimension** (Dimensão escalável), selecione **Replicas** (Réplicas) na caixa de diálogo.
1. Para o valor de destino, digite o percentual médio de utilização da CPU que você deseja manter nas réplicas do ElastiCache. Esse valor deve ser >=35 e <=70. As réplicas do cluster serão adicionadas ou removidas por manter a métrica próxima ao valor especificado.
1. (Opcional) Não há suporte do console para os períodos de desaquecimento de redução ou aumento de escala na horizontal. Use a AWS CLI para modificar os valores de desaquecimento.
1. Em **Minimum capacity** (Capacidade mínima), insira o número mínimo de réplicas que o ajuste de escala automático do ElastiCache é solicitado a manter.
1. Em **Maximum capacity** (Capacidade máxima), insira o número máximo de réplicas que o ajuste de escala automático do ElastiCache é solicitado a manter. Esse valor deve ser >=5.
1. Escolha **Criar**.
# Registro de um destino escalável
Você pode aplicar uma política de escalabilidade com base em uma métrica predefinida ou personalizada. Para fazer isso, você pode usar a AWS CLI ou a API do Application Auto Scaling. A primeira etapa é registrar seu grupo de replicação do ElastiCache para Valkey e Redis OSS no ajuste de escala automático.
Antes de poder usar o ajuste de escala automático do ElastiCache com um cluster, você deve registrar seu cluster no ajuste de escala automático do ElastiCache. Faça isso para definir a dimensão de escalabilidade e os limites a serem aplicados no cluster. O ajuste de escala automático do ElastiCache escala dinamicamente o cluster ao longo da dimensão escalável `elasticache:replication-group:Replicas`, que representa o número de réplicas por fragmento de cluster.
**Usar a CLI**
Para registrar o cluster do ElastiCache, use o comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) com os seguintes parâmetros:
+ --service-namespace: defina este valor como elasticache.
+ --resource-id: o identificador de recursos para o cluster do ElastiCache. Para este parâmetro, o tipo de recurso é ReplicationGroup e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ --scalable-dimension: defina este valor como `elasticache:replication-group:Replicas`.
+ --min-capacity: o número mínimo de fragmentos a serem gerenciados pela escalabilidade automática do ElastiCache. Para obter informações sobre a relação entre --min-capacity, --max-capacity e o número de réplicas no cluster, consulte [Capacidades mínima e máxima](AutoScaling-Policies.md#AutoScaling-MinMax).
+ --max-capacity: o número máximo de fragmentos a serem gerenciados pela escalabilidade automática do ElastiCache. Para obter informações sobre a relação entre --min-capacity, --max-capacity e o número de réplicas no cluster, consulte [Capacidades mínima e máxima](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
No exemplo a seguir, registre um cluster do ElastiCache de nome `myscalablecluster`. O registro indica que o cluster deve ser escalado dinamicamente para ter de uma a 5 réplicas.
Para Linux, macOS ou 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 \
```
Para 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 ^
```
**Usar a API**
Para registrar o cluster do ElastiCache, use o comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) com os seguintes parâmetros:
+ ServiceNamespace: defina este valor como elasticache.
+ ResourceID: o identificador de recursos para o cluster do ElastiCache. Para este parâmetro, o tipo de recurso é ReplicationGroup e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ ScalableDimension: defina este valor como `elasticache:replication-group:Replicas`.
+ MinCapacity: o número mínimo de réplicas a serem gerenciadas pela escalabilidade automática do ElastiCache. Para obter informações sobre a relação entre --min-capacity, --max-capacity e o número de réplicas no cluster, consulte [Capacidades mínima e máxima](AutoScaling-Policies.md#AutoScaling-MinMax).
+ MaxCapacity: o número máximo de réplicas a serem gerenciadas pela escalabilidade automática do ElastiCache. Para obter informações sobre a relação entre --min-capacity, --max-capacity e o número de réplicas no cluster, consulte [Capacidades mínima e máxima](AutoScaling-Policies.md#AutoScaling-MinMax).
**Example**
No exemplo a seguir, um cluster chamado `myscalablecluster` é registrado na API do Application Auto Scaling. Este registro indica que o cluster deve ser escalado dinamicamente para ter de uma a 5 réplicas.
```
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
}
```
# Definir uma política de escalabilidade
Uma configuração de política de escalabilidade de rastreamento de destino é representada por um bloco JSON no qual as métricas e valores de destino são definidos. Você pode salvar uma configuração de política de escalabilidade como um bloco JSON em um arquivo de texto. Você pode usar esse arquivo de texto ao invocar a AWS CLI ou a API do Application Auto Scaling. Para obter mais informações sobre a sintaxe de configuração de política, consulte [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) na *Referência da API do Application Auto Scaling*.
As seguintes opções estão disponíveis para definir uma configuração de política de escalabilidade com monitoramento do objetivo:
**Topics**
+ [Uso de uma métrica predefinida](#AutoScaling-Predefined-Metric)
+ [Editar uma política de escalabilidade](AutoScaling-Editing-Policy.md)
+ [Excluir uma política de escalabilidade](AutoScaling-Deleting-Policy.md)
+ [Use CloudFormation para políticas do Auto Scaling](AutoScaling-with-Cloudformation.md)
+ [Escalabilidade programada](AutoScaling-with-Scheduled-Scaling-Replicas.md)
## Uso de uma métrica predefinida
Uma configuração de política de escalabilidade de rastreamento de destino é representada por um bloco JSON no qual as métricas e valores de destino são definidos. Você pode salvar uma configuração de política de escalabilidade como um bloco JSON em um arquivo de texto. Você pode usar esse arquivo de texto ao invocar a AWS CLI ou a API do Application Auto Scaling. Para obter mais informações sobre a sintaxe de configuração de política, consulte [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) na *Referência da API do Application Auto Scaling*.
As seguintes opções estão disponíveis para definir uma configuração de política de escalabilidade com monitoramento do objetivo:
**Topics**
+ [Uso de uma métrica predefinida](#AutoScaling-Predefined-Metric)
+ [Uso de uma métrica personalizada](#AutoScaling-Custom-Metric)
+ [Uso de períodos de desaquecimento](#AutoScaling-Using-Cooldowns)
+ [Desabilitar a atividade de redução](#AutoScaling-Disabling-Scalein)
+ [Aplicação de uma política de escalabilidade a um cluster do ElastiCache para Valkey e Redis OSS](#AutoScaling-Applying-Policy)
### Uso de uma métrica predefinida
Com o uso de métricas predefinidas, você pode definir rapidamente uma política de escalabilidade com monitoramento do objetivo para um cluster do ElastiCache para Valkey e Redis OSS que funcione com o monitoramento do objetivo no ajuste de escala automático do ElastiCache. Atualmente, o ElastiCache dá suporte à seguinte métrica predefinida no Auto Scaling do ElastiCache:
`ElastiCacheReplicaEngineCPUUtilization`: o valor médio da métrica EngineCPUUtilization no CloudWatch em todas as réplicas no cluster. Você pode encontrar o valor da métrica agregada no CloudWatch em ElastiCache `ReplicationGroupId, Role` para ReplicationGroupId e réplica de função obrigatórios.
Para usar uma métrica predefinida em sua política de escalabilidade, crie uma configuração de rastreamento de destino para sua política de escalabilidade. Essa configuração deve incluir uma `PredefinedMetricSpecification` para a métrica predefinida e um `TargetValue` para o valor de destino dessa métrica.
### Uso de uma métrica personalizada
Com o uso de métricas personalizadas, você pode definir uma política de escalabilidade de rastreamento de destino que atenda a suas exigências personalizadas. Você pode definir uma métrica personalizada com base em qualquer métrica do ElastiCache para Valkey e Redis OSS que mude na proporção da escalabilidade. Nem todas as métricas do ElastiCache funcionam para o monitoramento do objetivo. A métrica deve ser de utilização válida e descrever o quão ocupada uma instância está. O valor da métrica deve aumentar ou diminuir na proporção do número de réplicas no cluster. Essa aumento ou redução proporcional é necessário para usar os dados da métrica para expandir ou reduzir proporcionalmente o número de réplicas.
**Example**
O exemplo a seguir descreve uma configuração de rastreamento de destino para uma política de escalabilidade. Nessa configuração, uma métrica personalizada ajusta um cluster com base em uma utilização média da CPU de 50 por centro em todas as réplicas em um cluster chamado `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"
}
}
```
### Uso de períodos de desaquecimento
Você pode especificar um valor, em segundos, para `ScaleOutCooldown` a fim de adicionar um desaquecimento para expandir seu cluster. De forma similar, você pode adicionar um valor, em segundos, para `ScaleInCooldown` a fim de adicionar um período de desaquecimento para reduzir a escala na horizontal do seu cluster. Para obter mais informações sobre `ScaleInCooldown` e `ScaleOutCooldown`, consulte [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) na *Referência da API do Application Auto Scaling*. O exemplo a seguir descreve uma configuração de rastreamento de destino para uma política de escalabilidade. Nessa configuração, a métrica predefinida `ElastiCacheReplicaEngineCPUUtilization` é usada para ajustar um cluster com base em uma utilização média da CPU de 40 por cento em todas as réplicas nesse cluster. A configuração fornece um desaquecimento de redução de 10 minutos e em um desaquecimento de expansão de 5 minutos.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"ScaleInCooldown": 600,
"ScaleOutCooldown": 300
}
```
### Desabilitar a atividade de redução
Você pode impedir que a configuração da política de escalabilidade com monitoramento do objetivo reduza a escala horizontalmente de seu cluster do ElastiCache para Valkey e Redis OSS desabilitando a atividade de redução de escala horizontal. Desabilitar a atividade de redução de escala na horizontal impede que a política de escalabilidade exclua réplicas, enquanto permite ao mesmo tempo que a política de escalabilidade adicione-as conforme necessário.
Você pode especificar um valor booleano para `DisableScaleIn` a fim de permitir ou evitar a atividade de redução de escala na horizontal no seu cluster. Para obter mais informações sobre `DisableScaleIn`, consulte [TargetTrackingScalingPolicyConfiguration](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_TargetTrackingScalingPolicyConfiguration.html) na *Referência da API do Application Auto Scaling*.
**Example**
O exemplo a seguir descreve uma configuração de rastreamento de destino para uma política de escalabilidade. Nessa configuração, a métrica predefinida `ElastiCacheReplicaEngineCPUUtilization` ajusta um cluster com base em uma utilização média da CPU de 40 por cento em todas as réplicas nesse cluster. A configuração desativa a atividade de redução para a política de escalabilidade.
```
{"TargetValue": 40.0,
"PredefinedMetricSpecification":
{"PredefinedMetricType": "ElastiCacheReplicaEngineCPUUtilization"
},
"DisableScaleIn": true
}
```
### Aplicação de uma política de escalabilidade a um cluster do ElastiCache para Valkey e Redis OSS
Após registrar seu cluster com o ajuste de escala automático do ElastiCache para Valkey e Redis OSS e definir uma política de escalabilidade, aplique a política de escalabilidade ao cluster registrado. Para aplicar uma política de escalabilidade a um cluster do ElastiCache para Valkey e Redis OSS, você pode usar a AWS CLI ou a API do Application Auto Scaling.
**Como usar o AWS CLI**
Para aplicar uma política de escalabilidade a seu cluster do ElastiCache para Valkey e Redis OSS, use o comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) com os seguintes parâmetros:
+ --policy-name: o nome da política de escalabilidade.
+ --policy-type: defina este valor como `TargetTrackingScaling`.
+ --resource-id: o identificador do recurso para o cluster. Para este parâmetro, o tipo de recurso é ReplicationGroup e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ --service-namespace: defina este valor como elasticache.
+ --scalable-dimension: defina este valor como `elasticache:replication-group:Replicas`.
+ --target-tracking-scaling-policy-configuration: a configuração da política de escalabilidade com monitoramento do objetivo a ser usada para o cluster.
**Example**
No exemplo a seguir, aplique a política de escalabilidade com monitoramento do objetivo chamada `myscalablepolicy` a um cluster chamado `myscalablecluster` com o ajuste de escala automático do ElastiCache. Para fazer isso, use uma configuração de política salva em um arquivo chamado `config.json`.
Para Linux, macOS ou 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
}
```
Para 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
```
**Usar a API**
Para aplicar a política de escalabilidade em seu cluster do ElastiCache com a API do Application Auto Scaling, use a operação [PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html) da API do Application Auto Scaling com os seguintes parâmetros:
+ PolicyName: o nome da política de escalabilidade.
+ PolicyType: defina este valor como `TargetTrackingScaling`.
+ ResourceID: o identificador de recursos para o cluster. Para este parâmetro, o tipo de recurso é ReplicationGroup e o identificador exclusivo é nome do cluster do ElastiCache para Redis OSS, por exemplo `replication-group/myscalablecluster`.
+ ServiceNamespace: defina este valor como elasticache.
+ ScalableDimension: defina este valor como `elasticache:replication-group:Replicas`.
+ TargetTrackingScalingPolicyConfiguration: a configuração da política de escalabilidade com monitoramento do objetivo a ser usada para o cluster.
**Example**
No exemplo a seguir, aplique a política de escalabilidade com monitoramento do objetivo chamada `scalablepolicy` a um cluster chamado `myscalablecluster` com o ajuste de escala automático do ElastiCache com Valkey ou Redis OSS. Use uma configuração de política com base na métrica predefinida `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"
}
}
}
```
# Editar uma política de escalabilidade
Você pode editar uma política de escalabilidade usando o Console de gerenciamento da AWS, a AWS CLI ou a API do Application Auto Scaling.
**Editar uma política de escalabilidade usando o Console de gerenciamento da AWS**
Você só pode editar políticas com métricas do tipo Predefined (Predefinidas) usando o Console de gerenciamento da AWS
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS**
1. Selecione o cluster ao qual você deseja adicionar uma política (escolha o botão à esquerda do nome do cluster).
1. Selecione a guia **Auto Scaling policies** (Políticas do Auto Scaling).
1. Em **Scaling policies** (Políticas de escalabilidade), escolha o botão à esquerda da política de autoescalabilidade que você deseja alterar e selecione **Modify** (Modificar).
1. Faça as alterações necessárias na política.
1. Escolha **Modificar**.
1. Faça as alterações na política.
1. Escolha **Modificar**.
**Edição de uma política de escalabilidade usando a AWS CLI ou a API do Application Auto Scaling**
Você pode usar a AWS CLI ou a API do Application Auto Scaling para editar uma política de escalabilidade da mesma forma que você aplica uma política de escalabilidade:
+ Ao usar a API do Application Auto Scaling, especifique o nome da política que você deseja editar no parâmetro `PolicyName`. Especifique novos valores para os parâmetros que você deseja alterar.
Para obter mais informações, consulte [Aplicação de uma política de escalabilidade a um cluster do ElastiCache para Valkey e Redis OSS](AutoScaling-Defining-Policy.md#AutoScaling-Applying-Policy).
# Excluir uma política de escalabilidade
Você pode excluir uma política de escalabilidade usando o Console de gerenciamento da AWS, a AWS CLI ou a API do Application Auto Scaling.
**Excluir uma política de escalabilidade usando o Console de gerenciamento da AWS**
Você só pode editar políticas com métricas do tipo Predefined (Predefinidas) usando o Console de gerenciamento da AWS
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS**
1. Escolha o cluster cuja política do Auto Scaling você deseja excluir.
1. Escolha a guia **Auto Scaling policies** (Políticas do Auto Scaling).
1. Na seção **Auto scaling policies** (Políticas de autoescalabilidade), escolha a respectiva política e selecione **Delete** (Excluir).
**Exclusão de uma política de escalabilidade usando a AWS CLI ou a API do Application Auto Scaling**
Você pode usar a AWS CLI ou a API do Application Auto Scaling para excluir uma política de escalabilidade de um cluster do ElastiCache.
**CLI**
Para excluir uma política de escalabilidade do seu cluster do ElastiCache para Valkey e Redis OSS, use o comando [delete-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html) com os seguintes parâmetros:
+ --policy-name: o nome da política de escalabilidade.
+ --resource-id: o identificador do recurso para o cluster. Para este parâmetro, o tipo de recurso é ReplicationGroup e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ --service-namespace: defina este valor como elasticache.
+ --scalable-dimension: defina este valor como `elasticache:replication-group:Replicas`.
**Example**
No exemplo a seguir, a política de escalabilidade com monitoramento do objetivo chamada `myscalablepolicy` é excluída de um cluster do ElsatiCache chamado `myscalablecluster`.
Para Linux, macOS ou Unix:
```
aws application-autoscaling delete-scaling-policy \
--policy-name myscalablepolicy \
--resource-id replication-group/myscalablecluster \
--service-namespace elasticache \
--scalable-dimension elasticache:replication-group:Replicas \
```
Para 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**
Para excluir uma política de escalabilidade do seu cluster do ElastiCache para Valkey e Redis OSS, use a operação da API do Application Auto Scaling [DeleteScalingPolicy](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_DeleteScalingPolicy.html) com os seguintes parâmetros:
+ PolicyName: o nome da política de escalabilidade.
+ ResourceID: o identificador de recursos para o cluster. Para este parâmetro, o tipo de recurso é ReplicationGroup e o identificador exclusivo é nome do cluster, por exemplo `replication-group/myscalablecluster`.
+ ServiceNamespace: defina este valor como elasticache.
+ ScalableDimension: defina este valor como `elasticache:replication-group:Replicas`.
No exemplo a seguir, a política de escalabilidade com monitoramento do objetivo chamada `myscalablepolicy` é excluída de um cluster chamado `myscalablecluster` com a API do 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"
}
```
# Use CloudFormation para políticas do Auto Scaling
Este trecho mostra como criar uma ação programada e aplicá-la a um recurso [AWS::ELastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html) usando o recurso [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html). Ela usa as funções intrínsecas [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) para construir a propriedade `ResourceId` com o nome lógico do recurso `AWS::ElastiCache::ReplicationGroup` especificado no mesmo modelo.
```
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
```
# Escalabilidade programada
A escalabilidade com base em uma programação permite que você dimensione sua aplicação em resposta a alterações de demanda. Para usar a escalabilidade programada, você deve criar ações programadas, que instruem o ElastiCache para Valkey e Redis OSS a executar ações de escalabilidade em momentos específicos. Ao criar uma ação programada, você especifica um cluster existente do ElastiCache, quando a ação de escalabilidade deve ocorrer, a capacidade mínima e a capacidade máxima. É possível criar ações programadas para escalar uma única vez ou de forma programada.
Você só pode criar uma ação programada para clusters do ElastiCache que já existam. Você não pode criar uma ação programada ao mesmo tempo em que você cria um cluster.
Para obter mais informações sobre terminologia para criação, gerenciamento e exclusão de ações programadas, consulte [Comandos normalmente usados para criação, gerenciamento e exclusão de ações programadas](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html#scheduled-scaling-commonly-used-commands)
**Para criar uma ação programada para executar uma única vez:**
Semelhante à dimensão do fragmento. Consulte [Escalabilidade programada](AutoScaling-with-Scheduled-Scaling-Shards.md).
**Para excluir uma ação programada**
Semelhante à dimensão do fragmento. Consulte [Escalabilidade programada](AutoScaling-with-Scheduled-Scaling-Shards.md).
**Para gerenciar a escalabilidade programada usando o AWS CLI **
Use as seguintes APIs de application-autoscaling:
+ [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)
## Use CloudFormation para criar políticas do Auto Scaling
Este trecho mostra como criar uma ação programada e aplicá-la a um recurso [AWS::ELastiCache::ReplicationGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticache-replicationgroup.html) usando o recurso [AWS::ApplicationAutoScaling::ScalableTarget](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html). Ela usa as funções intrínsecas [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) para construir a propriedade `ResourceId` com o nome lógico do recurso `AWS::ElastiCache::ReplicationGroup` especificado no mesmo modelo.
```
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 * * ? *)'
```
# Modificar o modo de cluster
O Valkey e o Redis OSS são bancos de dados em memória distribuídos que oferecem suporte à fragmentação e à replicação. Os clusters do ElastiCache Valkey e Redis OSS são a implementação distribuída que permite que os dados sejam particionados em vários nós. Um cluster do ElastiCache para Redis OSS tem dois modos de operação: o modo de cluster ativado (CME) e o modo de cluster desativado (CMD). No CME, um mecanismo Valkey e Redis OSS funciona como um banco de dados distribuído com vários fragmentos e nós, enquanto no CMD, o Valkey e o Redis OSS funcionam como um único nó.
Antes de migrar do CMD para o CME, as seguintes condições devem ser atendidas:
**Importante**
A configuração do modo de cluster só pode ser alterada do modo de cluster desativado para o modo cluster ativado. Não é possível reverter essa configuração.
+ O cluster só pode ter chaves no banco de dados 0.
+ As aplicações devem usar um cliente Valkey ou Redis OSS que seja capaz de usar o protocolo Cluster e um endpoint de configuração.
+ O failover automático deve ser ativado no cluster com no mínimo uma réplica.
+ A versão mínima do mecanismo necessária para a migração é o Valkey 7.2 e posteriores ou o Redis OSS 7.0 e posteriores.
Para migrar do CMD para o CME, a configuração do modo de cluster deve ser alterada do modo de cluster desativado para o modo cluster ativado. Esse é um procedimento de duas etapas que garante a disponibilidade do cluster durante o processo de migração.
**nota**
Você precisa fornecer um grupo de parâmetros com configuração habilitada para cluster, ou seja, o parâmetro habilitado para cluster deve estar definido como `yes`. Se você estiver usando um grupo de parâmetros padrão, o ElastiCache para Redis OSS escolherá automaticamente o grupo de parâmetros padrão correspondente com uma configuração habilitada para cluster. O valor do parâmetro habilitado para cluster é definido como `no` para um cluster CMD. Conforme o cluster passa para o modo compatível, o valor do parâmetro habilitado para cluster é atualizado para `yes` como parte da ação de modificação.
Para obter mais informações, consulte . [Configuração de parâmetros do mecanismo usando grupos de parâmetros do ElastiCache](ParameterGroups.md)
1. **Preparar-se**: crie um cluster CME de teste e certifique-se de que sua pilha esteja pronta para trabalhar com ele. O ElastiCache para Redis OSS não tem como verificar sua prontidão. Para obter mais informações, consulte [Criação de um cluster do Valkey ou Redis OSS](Clusters.Create.md).
1. **Modificar a configuração existente do cluster CMD para compatível com o modo cluster**: nesse modo, haverá um único fragmento implantado e o ElastiCache para Redis OSS funcionará como um único nó, mas também como um único cluster de fragmento. O modo compatível significa que o aplicativo cliente pode usar qualquer um dos protocolos para se comunicar com o cluster. Nesse modo, as aplicações devem ser reconfigurados para começar a usar o protocolo de cluster do Valkey ou do Redis OSS e o endpoint de configuração. Para alterar o modo cluster do Valkey ou do Redis OSS para o modo cluster compatível, siga as etapas abaixo:
**nota**
No modo compatível, outras operações de modificação, como ajuste de escala e versionamento do mecanismo, não são permitidas para o cluster. Além disso, os parâmetros (exceto `cacheParameterGroupName`) não podem ser modificados ao definir o parâmetro do modo de cluster na solicitação [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html).
1. Usando o Console de gerenciamento da AWS, consulte [Modificação de um grupo de replicação](Replication.Modify.md) e defina o modo de cluster como **Compatível**
1. Usando a API, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) e atualize o parâmetro `ClusterMode` para `compatible`.
1. Usando a AWS CLI, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) e atualize o parâmetro `cluster-mode` para `compatible`.
Depois de alterar o modo cluster do Valkey ou Redis OSS para o modo cluster compatível, a API [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) retornará o endpoint de configuração do cluster ElastiCache para Redis OSS. O endpoint de configuração do cluster é um endpoint único que pode ser usado pelos aplicativos para se conectar ao cluster. Para obter mais informações, consulte [Encontrar endpoints de conexão no ElastiCache](Endpoints.md).
1. **Modificar a configuração do cluster para o modo cluster ativado**: depois que o modo de cluster for definido como compatível com o modo de cluster, a segunda etapa é modificar a configuração do cluster para o modo cluster ativado. Nesse modo, um único fragmento está em execução, e os clientes agora podem ajustar a escala dos seus clusters ou modificar outras configurações de cluster.
Para alterar o modo de cluster para ativado, siga estas etapas:
Antes de começar, certifique-se de que seus clientes Valkey ou Redis OSS tenham migrado para o protocolo de cluster e que o endpoint de configuração do cluster não esteja em uso.
1. Usando o Console de gerenciamento da AWS, consulte [Modificação de um grupo de replicação](Replication.Modify.md) e defina o modo de cluster como **Habilitado**.
1. Usando a API, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) e atualize o parâmetro `ClusterMode` para `enabled`.
1. Usando a AWS CLI, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) e atualize o parâmetro `cluster-mode` para `enabled`.
Depois de alterar o modo cluster para habilitado, os endpoints serão configurados de acordo com a especificação do cluster do Valkey ou Redis OSS. A API [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) retornará o parâmetro do modo de cluster como `enabled` e os endpoints do cluster que agora estão disponíveis para serem usados pelos aplicativos para se conectar ao cluster.
Observe que os endpoints do cluster mudarão quando o modo de cluster for alterado para ativado. Certifique-se de atualizar seus aplicativos com os novos endpoints.
Você também pode optar por voltar ao modo de cluster desativado (CMD) usando o modo de cluster compatível e preservar as configurações originais.
**Modificar a configuração do cluster para o modo de cluster desativado usando o modo de cluster compatível**
1. Usando o Console de gerenciamento da AWS, consulte [Modificação de um grupo de replicação](Replication.Modify.md) e defina o modo de cluster como **Desabilitado**.
1. Usando a API, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) e atualize o parâmetro `ClusterMode` para `disabled`.
1. Usando a AWS CLI, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) e atualize o parâmetro `cluster-mode` para `disabled`.
Depois de alterar o modo de cluster para desativado, a API [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) retornará o parâmetro do modo de cluster como `disabled`.
# Replicação entre AWS regiões usando datastores globais
**nota**
No momento, o Global Datastore só está disponível para clusters baseados em nós.
Ao usar o recurso Global Datastore, você pode trabalhar com a replicação de clusters Valkey ou Redis OSS totalmente gerenciada, rápida, confiável e segura em todas as regiões.AWS Usando esse recurso, você pode criar clusters de réplicas de leitura entre regiões para permitir leituras de baixa latência e recuperação de desastres em todas as regiões.AWS
Nas seções a seguir, você pode encontrar uma descrição de como trabalhar com datastores globais.
**Topics**
+ [Visão geral do](#Redis-Global-Data-Stores-Overview)
+ [Pré-requisitos e limitações](Redis-Global-Datastores-Getting-Started.md)
+ [Uso de datastores globais (console)](Redis-Global-Datastores-Console.md)
+ [Uso de datastores globais (CLI)](Redis-Global-Datastores-CLI.md)
## Visão geral do
Cada *datastore global* é uma coleção de um ou mais clusters que são replicados entre si.
Um datastore global consiste no seguinte:
+ **Cluster primário (ativo)**: um cluster primário aceita gravações que são replicadas para todos os clusters dentro do datastore global. Um cluster primário também aceita solicitações de leitura.
+ **Cluster secundário (passivo)**: um cluster secundário só aceita solicitações de leitura e replica as atualizações de dados de um cluster primário. Um cluster secundário precisa estar em uma AWS região diferente do cluster primário.
Quando você cria um armazenamento de dados global ElastiCache para Valkey ou Redis OSS, ele replica automaticamente seus dados do cluster primário para o cluster secundário. Você escolhe a AWS região em que os dados do Valkey ou do Redis OSS devem ser replicados e, em seguida, cria um cluster secundário nessa região.AWS ElastiCache em seguida, configura e gerencia a replicação automática e assíncrona de dados entre os dois clusters.
O uso de um datastore global para Valkey ou Redis OSS oferece as seguintes vantagens:
+ **Desempenho geolocal** — ao configurar clusters de réplicas remotas em AWS regiões adicionais e sincronizar seus dados entre elas, você pode reduzir a latência do acesso aos dados nessa região.AWS Um armazenamento de dados global pode ajudar a aumentar a capacidade de resposta do seu aplicativo fornecendo leituras geolocais de baixa latência em todas as regiões.AWS
+ **Recuperação de desastres** se o cluster primário em um datastore global sofrer degradação, você poderá promover um cluster secundário como seu novo cluster primário. Você pode fazer isso conectando-se a qualquer AWS região que contenha um cluster secundário.
O diagrama a seguir mostra como os datastores globais podem funcionar.
![\[Datastore global\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/Global-DataStore.png)
# Pré-requisitos e limitações
Ao começar a usar datastores globais, lembre-se do seguinte:
+ Os datastores globais são compatíveis com as seguintes regiões da AWS:
+ **África**: Cidade do Cabo
+ **Ásia-Pacífico**: Hong Kong, Hyderabad, Jacarta, Malásia, Melbourne, Mumbai, Osaka, Seul, Cingapura, Sydney, Tailândia e Tóquio
+ **Canadá**: Central do Canadá e Oeste do Canadá (Calgary)
+ **China**: Pequim e Ningxia
+ **Europa**: Frankfurt, Londres, Irlanda, Milão, Paris, Espanha, Estocolmo e Zurique
+ **AWS GovCloud**: Oeste dos EUA e Leste dos EUA
+ **Israel**: Tel Aviv
+ **Oriente Médio**: Bahrein e Emirados Árabes Unidos
+ **Leste dos EUA** (Norte da Virgínia e Ohio) e Oeste dos EUA (Norte da Califórnia e Oregon)
+ **América do Sul**: México (Centro) e São Paulo
+ Todos os clusters (primário e secundário) datastore global devem ter o mesmo número de nós primários, tipo de nó, versão do mecanismo e número de fragmentos (caso o modo cluster esteja habilitado). Cada cluster no datastore global pode ter um número diferente de réplicas de leitura para acomodar o tráfego de leitura local para esse cluster.
A replicação deve ser habilitada se você planejar usar um cluster de nó único existente.
+ Os datastores globais são compatíveis com instâncias de tamanho grande ou superior.
+ É possível configurar a replicação de um cluster primário de uma região da AWS para um cluster secundário em até duas outras regiões da AWS.
**nota**
A exceção a isso são regiões China (Pequim) e China (Ningxia), onde a replicação só pode ocorrer entre as duas regiões.
+ É possível trabalhar com datastores globais somente em clusters de VPC. Para obter mais informações, consulte [Padrões de acesso para acessar um cache do ElastiCache em um Amazon VPC](elasticache-vpc-accessing.md). Os datastores globais não são compatíveis ao usar o EC2-Classic. Para obter mais informações, consulte [EC2-Classic](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-classic-platform.html) no *Guia do usuário do Amazon EC2*.
**nota**
No momento, você não pode usar datastores globais no [Uso de zonas locais com o ElastiCache](Local_zones.md).
+ O ElastiCache não oferece suporte ao failover automático de uma região da AWS para outra. Quando necessário, você pode promover um cluster secundário manualmente. Para obter um exemplo, consulte [Promoção do cluster secundário para primário](Redis-Global-Datastores-Console.md#Redis-Global-Datastores-Console-Promote-Secondary).
+ Para a inicialização com os dados existentes, use um cluster existente como primário para criar um datastore global. Não oferecemos suporte à adição de um cluster existente como secundário. O processo de adição do cluster como secundário limpa os dados, o que pode resultar em perda de dados.
+ As atualizações de parâmetros são aplicadas a todos os clusters quando você modifica um grupo de parâmetros local de um cluster pertencente a um datastore global.
+ Você pode dimensionar clusters regionais verticalmente (dimensionando para cima e para baixo) e horizontalmente (reduzindo e ampliando). Você pode dimensionar os clusters modificando o datastore global. Todos os clusters regionais no datastore global são depois dimensionados sem interrupção. Para obter mais informações, consulte [Dimensionamento ElastiCache](Scaling.md).
+ Os datastores globais oferecem suporte à [criptografia em repouso](at-rest-encryption.md), à [criptografia em trânsito](in-transit-encryption.md) e ao [AUTH](auth.md).
+ Os datastores globais não oferecem suporte ao Protocolo de Internet versão 6 (IPv6).
+ Suporte a chaves de AWS KMS de datastores globais. Para obter mais informações, consulte [Conceitos do serviço de gerenciamento de chaves da AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys) no *Guia do desenvolvedor do AWS Key Management Service*.
**nota**
Os datastores globais oferecem suporte ao [sistema de mensagens pub/sub](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/elasticache-use-cases.html#elasticache-for-redis-use-cases-messaging) com as seguintes estipulações:
No modo de cluster desabilitado, pub/sub é totalmente compatível. Os eventos publicados no cluster primário da região primária da AWS são propagados para regiões secundárias da AWS.
No modo de cluster habilitado, o seguinte se aplica:
Para eventos publicados que não estejam em um espaço de chaves, apenas os assinantes na mesma região da AWS recebem os eventos.
Em eventos de espaço de chaves publicados, os assinantes em todas as regiões da AWS recebem esses eventos.
# Uso de datastores globais (console)
Para criar um datastore global usando o console, siga este processo de duas etapas:
1. Crie um cluster primário, usando um cluster existente ou criando um cluster. O mecanismo deve ser o Valkey 7.2 ou posterior ou o Redis OSS 5.0.6 ou posterior.
1. Adicione até dois clusters secundários em diferentes regiões da AWS, novamente usando o Valkey 7.2 ou posterior ou o Redis OSS 5.0.6 ou posterior.
Os procedimentos a seguir orientam você a criar um datastore global do Valkey ou Redis OSS e executar outras operações usando o console do ElastiCache.
**Topics**
+ [Criar um datastore global usando um cluster existente](#Redis-Global-Datastores-Console-Create-Primary)
+ [Criação de um datastore global usando um novo cluster primário](#Redis-Global-Datastores-Create-From-Scratch)
+ [Visualização de detalhes do datastore global](#Redis-Global-Datastores-Console-Details)
+ [Adição de uma região a um datastore global](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Modificação de um datastore global](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
+ [Promoção do cluster secundário para primário](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Remoção de uma região de um datastore global](#Redis-Global-Datastore-Console-Remove-Region)
+ [Exclusão de um datastore global](#Redis-Global-Datastores-Console-Delete-GlobalDatastore)
## Criar um datastore global usando um cluster existente
Neste cenário, você usa um cluster existente para servir como o primário do novo datastore global. Em seguida, você cria um cluster secundário somente leitura em uma região da AWS separada. Esse cluster secundário recebe atualizações automáticas e assíncronas do cluster primário.
**Importante**
O cluster existente deve usar um mecanismo Valkey 7.2 ou posterior ou o Redis OSS 5.0.6 ou posterior.
**Como criar um datastore global usando um cluster existente**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Datastores globais** e, em seguida, escolha **Criar datastore global**.
1. Na página **Configurações do cluster primário**, faça o seguinte:
+ No campo **Informações do datastore global**, insira um nome para o novo datastore global.
+ (Opcional) Insira um valor para **Description (Descrição)**.
1. Em **Cluster regional**, selecione **Usar cluster regional existente**.
1. Em **Cluster existente**, selecione o cluster existente que você deseja usar.
1. Mantenha as seguintes opções como estão. Elas são pré-preenchidas para corresponder à configuração do cluster primário, você não pode alterá-las.
+ Versão do mecanismo
+ Tipo de nó
+ Grupo de parâmetros
**nota**
O ElastiCache gera automaticamente um grupo de parâmetros com os valores do grupo de parâmetros fornecido e aplica o novo grupo de parâmetros ao cluster. Use esse novo grupo de parâmetros para modificar parâmetros em um datastore global. Cada grupo de parâmetros gerado automaticamente está associado a um, e apenas a um, cluster e, portanto, apenas a um datastore global.
+ Número de fragmentos
+ Encryption at rest (Criptografia em repouso): permite a criptografia de dados armazenados em disco. Para obter mais informações, consulte [Criptografia em repouso](at-rest-encryption.md).
**nota**
Se deseja fornecer uma chave de criptografia diferente, selecione **Chave do AWS KMS gerenciada pelo cliente** e escolha a chave. Para mais informações, consulte [Uso de chaves do AWS KMS gerenciadas pelo cliente](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ Encryption in-transit (Criptografia em trânsito): permite a criptografia de dados na conexão. Para obter mais informações, consulte [Criptografia em trânsito](in-transit-encryption.md). Para o Valkey 7.2 e posteriores, e Redis OSS versão 6.0 e posteriores, ao habilitar a criptografia em trânsito, você será solicitado a especificar uma das seguintes opções de **Controle de acesso**:
+ **No Access Control** (Sem controle de acesso): essa é a configuração padrão. Isso indica que não há restrições.
+ **User Group Access Control List** (Lista de controle de acesso do grupo de usuários): escolha um grupo de usuários com um conjunto definido de usuários e permissões nas operações disponíveis. Para obter mais informações, consulte [Gerenciamento de grupos de usuários com o console e a CLI](Clusters.RBAC.md#User-Groups).
+ **Usuário padrão AUTH**: um mecanismo de autenticação para um servidor Valkey ou Redis OSS. Para obter mais informações, consulte [AUTH](auth.md).
1. (Opcional) Conforme necessário, atualize as configurações restantes do cluster secundário. Elas são pré-preenchidas com os mesmos valores das do cluster primário, mas você pode atualizá-las para atender aos requisitos específicos para esse cluster.
+ Porta
+ Número de réplicas
+ Grupo de sub-rede
+ Zona(s) de disponibilidade preferencial(is)
+ Grupos de segurança
+ Gerenciada pelo cliente (chave do KMS da AWS)
+ Token AUTH
+ Habilitar backups automáticos
+ Backup retention period (Período de retenção de backup)
+ Janela de backup
+ Maintenance window
+ Tópico para notificação do SNS
1. Escolha **Criar**. Fazer isso define o status do datastore global como **Creating** (Criando). As transições de status para **Modifying** (Modificando) depois que o cluster primário é associado ao datastore global e o cluster secundário está no status **Associating** (Associando).
Depois que o cluster primário e os clusters secundários estão associados ao datastore global, o status muda para **Available** (Disponível). Neste ponto, você tem um cluster primário, que aceita leituras e gravações, e clusters secundários, que aceitam leituras replicadas do cluster primário.
A página é atualizada para indicar se um cluster faz parte de um datastore global, incluindo:
+ **Global Datastore** (Datastore global): o nome datastore global ao qual o cluster pertence.
+ **Global Datastore Role** (Função do datastore global): a função do cluster, primário ou secundário.
Você pode adicionar até um cluster secundário a uma região da AWS diferente. Para obter mais informações, consulte [Adição de uma região a um datastore global](#Redis-Global-Datastores-Console-Create-Secondary).
## Criação de um datastore global usando um novo cluster primário
Se você optar por criar um datastore global com um novo cluster, use o procedimento a seguir.
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Datastores globais** e, em seguida, escolha **Criar datastore global**.
1. Em **Primary cluster settings** (Configurações do cluster primário), faça o seguinte:
1. Em **Cluster mode** (Modo cluster), escolha **Enabled** (Habilitado) ou **Disabled** (Desabilitado).
1. Em **Global Datastore info** (Informações do datastore global), insira um valor para **Name** (Nome). O ElastiCache usa o sufixo para gerar um nome exclusivo para o datastore global. Você pode pesquisar o datastore global usando o sufixo especificado aqui.
1. (Opcional) Insira um valor para **Global Datastore Description (Descrição do datastore global)**.
1. Em **Regional cluster** (Cluster regional):
1. Em **Region** (Região), escolha uma Região da AWS disponível.
1. Selecione **Create new regional cluster** (Criar cluster regional) ou **Use existing regional cluster** (Usar cluster regional existente)
1. Se escolher **Create new regional cluster** (Criar cluster regional), em **Cluster info** (Informações sobre o cluster), insira um nome e uma descrição opcional do cluster.
1. Em **Location** (Localização), recomendamos que você aceite as configurações padrão de **Multi-AZ** e **Auto-failover** (Failover automático).
1. Em **Cluster settings** (Configurações do cluster)
1. Em **Engine version** (Versão do mecanismo), escolha uma versão disponível, que é 5.0.6 ou posterior.
1. Em **Port** (Porta), use a porta padrão, 6379. Se você tiver um motivo para usar uma porta diferente, insira o número da porta.
1. Em **Grupo de parâmetro** (Parameter group), escolha um grupo de parâmetro ou crie um novo. Os grupo de parâmetros controlam os parâmetros de tempo de execução do seu cluster. Para obter mais informações sobre grupo de parâmetros, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis) e [Criação de um grupo de parâmetros do ElastiCache](ParameterGroups.Creating.md).
**nota**
Quando você seleciona um grupo de parâmetros para definir os valores de configuração do mecanismo, esse grupo de parâmetros é aplicado a todos os clusters no datastore global. Na página **Parameter Groups** (Grupos de parâmetros), o atributo **Global** indica se um grupo de parâmetros faz parte de um datastore global.
1. Para **Node type** (Tipo de nó), escolha a seta para baixo (![\[Downward-pointing triangle icon, typically used to indicate a dropdown menu.\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-DnArrow.png)). Na caixa de diálogo **Change node type** (Alterar tipo de nó), escolha um valor para a **Instance family** (Família de instâncias) para o tipo de nó desejado. Depois disso, escolha o tipo de nó que deseja usar para este cluster e escolha **Save** (Salvar).
Para obter mais informações, consulte [Escolha do tamanho do nó](CacheNodes.SelectSize.md).
Se você escolher um tipo de nó r6gd, a classificação de dados em níveis será ativada automaticamente. Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
1. Se você estiver criando um cluster do Valkey ou Redis OSS (modo cluster desabilitado):
Em **Number of replicas** (Número de réplicas), escolha o número de réplicas desejado para esse cluster.
1. Se você estiver criando um cluster do Valkey ou Redis OSS (modo cluster habilitado):
1. Em **Número de fragmentos**, escolha o número de fragmentos (partições/grupos de nós) desejado para este cluster do Valkey ou Redis OSS (modo cluster habilitado).
Para algumas versões do Valkey ou Redis OSS (modo cluster habilitado), é possível alterar dinamicamente o número de fragmentos no cluster:
+ **Redis OSS 3.2.10 e posteriores**: se o cluster estiver executando o Redis OSS 3.2.10 ou versões posteriores, será possível alterar dinamicamente o número de fragmentos no cluster. Para obter mais informações, consulte [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md).
+ **Outras versões do Redis OSS**: se o cluster estiver executando uma versão do Redis OSS anterior à versão 3.2.10, há outra abordagem. Para alterar o número de fragmentos no cluster nesse caso, crie um novo cluster com o novo número de fragmentos. Para obter mais informações, consulte [Restauração de um backup para um novo cache](backups-restoring.md).
1. Em **Réplicas por fragmento**, escolha o número de nós de réplica de leitura desejados em cada fragmento.
As restrições a seguir existem para o Valkey ou Redis OSS (modo cluster habilitado).
+ Se você tiver o Multi-AZ habilitado, verifique se tem pelo menos uma réplica por fragmento.
+ O número de réplicas é o mesmo para cada fragmento ao criar o cluster usando o console.
+ O número de réplicas de leitura por fragmento é fixo e não pode ser alterado. Se você achar que precisa de mais ou menos réplicas por fragmento (API/CLI: grupo de nós), deverá criar um novo cluster com o novo número de réplicas. Para obter mais informações, consulte [Tutorial: propagação de um novo cluster baseado em nós com um backup criado externamente](backups-seeding-redis.md).
1. Em **Subnet group settings** (Configurações de grupo de sub-redes), escolha a sub-rede que você deseja aplicar a esse cluster. O ElastiCache fornece um grupo de sub-redes IPv4 padrão ou é possível optar por criar um novo. Para o IPv6, é necessário criar um grupo de sub-rede com um bloco CIDR do IPv6. Se você escolher **dual stack** (pilha dupla), deverá selecionar um tipo de IP de descoberta: IPv6 ou IPv4.
Para obter mais informações, consulte [Criar uma sub-rede na sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet).
1. Em **Availability zone placements** (Posicionamentos de zona de disponibilidade), você tem duas opções:
+ **No preference** (Sem preferência): o ElastiCache escolhe a zona de disponibilidade.
+ **Specify availability zones** (Especificar zonas de disponibilidade): você especifica a zona de disponibilidade para cada cluster.
Se optar por especificar as zonas de disponibilidade, para cada cluster em cada fragmento, escolha a zona de disponibilidade na lista.
Para obter mais informações, consulte [Seleção de regiões e zonas de disponibilidade para o ElastiCache](RegionsAndAZs.md).
![\[Imagem: especificar espaços de chaves e zonas de disponibilidade\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-ClusterOn-Slots-AZs.png)
*Especificar espaços de chaves e zonas de disponibilidade*
1. Escolha **Next** (Próximo)
1. Em **Configurações avançadas do Valkey e do Redis OSS**
1. Para **Security** (Segurança):
1. Para criptografar seus dados, você tem as seguintes opções:
+ **Criptografia em repouso**: permite a criptografia de dados armazenados em disco. Para obter mais informações, consulte [Criptografia em repouso](at-rest-encryption.md).
**nota**
Você tem a opção de fornecer uma chave de criptografia diferente, escolhendo **Customer Managed KMS key** (Chave do AWS KMS gerenciada pelo cliente) e escolhendo a chave. Para obter mais informações, consulte [Usar chaves gerenciadas pelo cliente do AWS KMS](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ **Encryption in-transit** (Criptografia em trânsito): permite a criptografia de dados na conexão. Para obter mais informações, consulte [criptografia em trânsito](in-transit-encryption.md). Para o Valkey 7.2 e posteriores e Redis OSS 6.0 e posteriores, se você habilitar a Criptografia em trânsito, você será solicitado a especificar uma das seguintes opções de **Controle de acesso**:
+ **No Access Control** (Sem controle de acesso): essa é a configuração padrão. Isso indica que não há restrições no acesso do usuário ao cluster.
+ **User Group Access Control List** (Lista de controle de acesso de grupo de usuários): selecione um grupo de usuários com um conjunto definido de usuários que possam acessar o cluster. Para obter mais informações, consulte [Gerenciamento de grupos de usuários com o console e a CLI](Clusters.RBAC.md#User-Groups).
+ **Usuário padrão AUTH**: um mecanismo de autenticação para um servidor Valkey ou Redis OSS. Para obter mais informações, consulte [AUTH](auth.md).
+ **AUTH**: um mecanismo de autenticação para um servidor Valkey ou Redis OSS. Para obter mais informações, consulte [AUTH](auth.md).
**nota**
Para versões do Redis OSS 3.2.6 e posteriores, excluindo a versão 3.2.10, o AUTH é a única opção.
1. Em **Grupos de segurança**, escolha os grupos de segurança desejados para esse cluster. Um *grupo de segurança* atua como um firewall para controlar o acesso à rede ao cluster. É possível usar o grupo de segurança padrão para sua VPC ou criar um novo.
Para obter mais informações sobre grupos de segurança, consulte [Grupos de segurança para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) no *Guia do usuário da Amazon VPC*.
1. Para backups automáticos agendados regularmente, selecione **Enable automatic backups** (Habilitar backups automáticos) e insira o número de dias que deseja que cada backup automático seja mantido antes de ser excluído automaticamente. Se não quiser backups automáticos agendados regularmente, desmarque a caixa de seleção **Enable automatic backups** (Habilitar backups automáticos). Em ambos os casos, você sempre tem a opção de criar backups manuais.
Para obter mais informações sobre backup e restauração, consulte [Snapshots e restauração](backups.md).
1. (Opcional) Especifique uma janela de manutenção. A *maintenance window* (janela de manutanção) é o tempo, geralmente uma hora de duração, a cada semana quando o ElastiCache programa a manutenção do sistema para seu cluster. É possível permitir que o ElastiCache escolha o dia e a hora da sua janela de manutenção (*No preference* (Sem preferência)) ou é possível escolher o dia, a hora e a duração por conta própria (*Specify maintenance window* (Especificar janela de manutenção)). Se você escolher *Especificar janela de manutenção*, nas listas, escolha *Dia de início*, *Hora de início* e *Duração* (em horas) para sua janela de manutenção. Todos os horários são em UCT.
Para obter mais informações, consulte [Gerenciamento de manutenção de cluster do ElastiCache](maintenance-window.md).
1. (Opcional) Para **Logs**:
+ Em **Log format** (Formato do log), escolha **Text** (Texto) ou **JSON**.
+ Em **Destination Type** (Tipo de destino), escolha **CloudWatch Logs** (Logs do CloudWatch) ou **Kinesis Firehose**.
+ Em **Destino do log**, escolha **Criar novo** e insira o nome do grupo de logs do CloudWatch Logs ou o nome do stream do Firehose, ou escolha **Selecionar existente** e escolha o nome do grupo de logs do CloudWatch Logs ou o nome do stream do Firehose,
1. Em **tags**, para ajudar você a gerenciar seus clusters e outros recursos do ElastiCache, é possível atribuir seus próprios metadados a cada recurso na forma de tags. Para obter mais informações, consulte [Marcando seus recursos ElastiCache](Tagging-Resources.md).
1. Revise todas as suas entradas e opções e faça as correções necessárias. Quando estiver pronto, selecione **Avançar**.
1. Depois de configurar o cluster nas etapas anteriores, agora você vai configurar os detalhes do cluster secundário.
1. Em **Regional cluster** (Cluster regional), escolha a Região da AWS onde o cluster está localizado.
1. Em **Cluster info** (Informações sobre o cluster), insira um nome e uma descrição opcional do cluster.
1. As opções seguintes são pré-preenchidas para corresponder à configuração do cluster primário e não podem ser alteradas:
+ Local
+ Versão do mecanismo
+ Tipo de instância
+ Tipo de nó
+ Número de fragmentos
+ Grupo de parâmetros
**nota**
O ElastiCache gera automaticamente um grupo de parâmetros com os valores do grupo de parâmetros fornecido e aplica o novo grupo de parâmetros ao cluster. Use esse novo grupo de parâmetros para modificar parâmetros em um datastore global. Cada grupo de parâmetros gerado automaticamente está associado a um, e apenas a um, cluster e, portanto, apenas a um datastore global.
+ Encryption at rest (Criptografia em repouso): permite a criptografia de dados armazenados em disco. Para obter mais informações, consulte [Criptografia em repouso](at-rest-encryption.md).
**nota**
Se deseja fornecer uma chave de criptografia diferente, selecione **Chave do AWS KMS gerenciada pelo cliente** e escolha a chave. Para mais informações, consulte [Uso de chaves do AWS KMS gerenciadas pelo cliente](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security).
+ Encryption in-transit (Criptografia em trânsito): permite a criptografia de dados na conexão. Para obter mais informações, consulte [Criptografia em trânsito](in-transit-encryption.md). Para o Valkey 7.2 e posteriores e Redis OSS 6.4 e posteriores, se você habilitar a criptografia em trânsito, você será solicitado a especificar uma das seguintes opções de **Controle de acesso**:
+ **No Access Control** (Sem controle de acesso): essa é a configuração padrão. Isso indica que não há restrições no acesso do usuário ao cluster.
+ **User Group Access Control List** (Lista de controle de acesso de grupo de usuários): escolha um grupo de usuários com um conjunto definido de usuários que possam acessar o cluster. Para obter mais informações, consulte [Gerenciamento de grupos de usuários com o console e a CLI](Clusters.RBAC.md#User-Groups).
+ **Usuário padrão AUTH**: um mecanismo de autenticação para um servidor Valkey ou Redis OSS. Para obter mais informações, consulte [AUTH](auth.md).
**nota**
Para versões do Redis OSS entre 4.0.2, quando houve suporte para a criptografia em trânsito pela primeira vez, e 6.0.4, o AUTH é a única opção.
As configurações de cluster secundário restantes são pré-preenchidas com os mesmos valores que o cluster primário, mas o seguinte pode ser atualizado para atender aos requisitos específicos para esse cluster:
+ Porta
+ Número de réplicas
+ Grupo de sub-rede
+ Zona(s) de disponibilidade preferencial(is)
+ Grupos de segurança
+ Gerenciada pelo cliente (chave do KMS da AWS)
+ Token AUTH
+ Habilitar backups automáticos
+ Backup retention period (Período de retenção de backup)
+ Janela de backup
+ Maintenance window
+ Tópico para notificação do SNS
1. Escolha **Create**. Isso define o status do datastore global como **Creating** (Criando). Depois que o cluster primário e os clusters secundários estão associados ao datastore global, o status muda para **Available** (Disponível). Você tem um cluster primário que aceita leituras e gravações e um cluster secundário que aceita leituras replicadas do cluster primário.
A página também é atualizada para indicar se um cluster faz parte de um datastore global, incluindo o seguinte:
+ **Global Datastore** (Datastore global): o nome datastore global ao qual o cluster pertence.
+ **Global Datastore Role** (Função do datastore global): a função do cluster, primário ou secundário.
Você pode adicionar até um cluster secundário a uma região da AWS diferente. Para obter mais informações, consulte [Adição de uma região a um datastore global](#Redis-Global-Datastores-Console-Create-Secondary).
## Visualização de detalhes do datastore global
Você pode visualizar os detalhes dos datastores globais existentes e também modificá-los na página **Datastores globais**.
**Como visualizar os detalhes do datastore global**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Datastores globais** e escolha um datastore global disponível.
Depois, você pode examinar as seguintes propriedades do datastore global:
+ **Global Datastore Name:** o nome do datastore global
+ **Descrição:** uma descrição do datastore global
+ **Status:** as opções incluem:
+ Criando
+ Modificar
+ Available (Disponível)
+ Excluindo
+ Somente primário - esse status indica que o datastore global contém apenas um cluster primário. Todos os clusters secundários são excluídos ou não são criados com êxito.
+ **Modo de cluster:** habilitado ou desabilitado
+ **Versão do mecanismo:** a versão do mecanismo Valkey ou Redis OSS que executa o datastore global
+ **Tipo de nó de instância:** o tipo de nó usado para o datastore global
+ **Criptografia em repouso:** habilitada ou desabilitada
+ **Criptografia em trânsito:** Habilitada ou desabilitada
+ **AUTH:** habilitada ou desabilitada
Você pode fazer as seguintes alterações no datastore global:
+ [Adição de uma região a um datastore global](#Redis-Global-Datastores-Console-Create-Secondary)
+ [Remoção de uma região de um datastore global](#Redis-Global-Datastore-Console-Remove-Region)
+ [Promoção do cluster secundário para primário](#Redis-Global-Datastores-Console-Promote-Secondary)
+ [Modificação de um datastore global](#Redis-Global-Datastores-Console-Modify-Regional-Clusters)
A página Global Datastore (Datastore global) também lista os clusters individuais que compõem o datastore global e as seguintes propriedades de cada um:
+ **Region** (Região): a região da AWS em que o cluster está armazenado
+ **Role (Função)** - primária ou secundária
+ **Cluster name (Nome do cluster)** - o nome do cluster
+ **Status** - as opções incluem:
+ **Associating (Associando)** - o cluster está em processo de ser associado ao datastore global
+ **Associated (Associado)** - o cluster está associado ao datastore global
+ **Disassociating (Desassociando)** - o processo de remoção de um cluster secundário do datastore global que usa o nome do datastore global. Depois disso, o cluster secundário não recebe mais atualizações do cluster primário, mas permanece como um cluster independente nessa região da AWS.
+ **Disassociated** (Desassociado): o cluster secundário foi removido do datastore global e agora é um cluster independente em sua região da AWS.
+ **Global Datastore Replica lag** (Atraso da réplica do datastore global): mostra um valor por região secundária da AWS no datastore global. Esse é o atraso entre o nó primário da região secundária e o nó primário da região primária. Para o Valkey ou Redis OSS habilitado para modo cluster, o atraso indica o atraso máximo, em segundos, entre os fragmentos.
## Adição de uma região a um datastore global
Você pode adicionar até uma região adicional da AWS a um datastore global existente. Nesse cenário, você está criando um cluster somente leitura em uma região separada da AWS que recebe atualizações automáticas e assíncronas do cluster primário.
**Para adicionar uma região da AWSa um datastore global**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Datastores globais** e selecione um datastore global existente.
1. Escolha **Adicionar cluster regional** e escolha a região da AWS em que o cluster secundário deve residir.
1. Em **Informações do cluster**, insira um valor para **Nome** e, opcionalmente, para **Descrição** do cluster.
1. Mantenha as seguintes opções como estão. Elas são pré-preenchidas para corresponder à configuração do cluster primário, e você não pode alterá-las.
+ Versão do mecanismo
+ Tipo de instância
+ Tipo de nó
+ Número de fragmentos
+ Grupo de parâmetros
**nota**
O ElastiCache gera automaticamente um grupo de parâmetros com os valores do grupo de parâmetros fornecido e aplica o novo grupo de parâmetros ao cluster. Use esse novo grupo de parâmetros para modificar parâmetros em um datastore global. Cada grupo de parâmetros gerado automaticamente está associado a um, e apenas a um, cluster e, portanto, apenas a um datastore global.
+ Criptografia em repouso
**nota**
Se deseja fornecer uma chave de criptografia diferente, selecione **Chave do AWS KMS gerenciada pelo cliente** e escolha a chave.
+ Criptografia em trânsito
+ AUTH
1. (Opcional) Atualize as configurações restantes do cluster secundário. Elas são pré-preenchidas com os mesmos valores das do cluster primário, mas é possível atualizá-las para atender aos requisitos específicos para esse cluster:
+ Porta
+ Número de réplicas
+ Grupo de sub-rede
+ Zona(s) de disponibilidade preferencial(is)
+ Grupos de segurança
+ Chave do KMS da AWS gerenciada pelo cliente
+ Token AUTH
+ Habilitar backups automáticos
+ Backup retention period (Período de retenção de backup)
+ Janela de backup
+ Maintenance window
+ Tópico para notificação do SNS
1. Escolha **Add** (Adicionar).
## Modificação de um datastore global
É possível modificar propriedades de clusters regionais. Somente uma operação de modificação pode estar em andamento em um datastore global, com exceção da promoção de um cluster secundário para primário. Para obter mais informações, consulte [Promoção do cluster secundário para primário](#Redis-Global-Datastores-Console-Promote-Secondary).
**Como modificar um datastore global**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Datastores globais** e, em **Nome do datastore global**, escolha um datastore global.
1. Escolha **Modify (Modificar)** e escolha entre as seguintes opções:
+ **Modify description** (Modificar descrição): atualiza a descrição do datastore global
+ **Modificar versão do mecanismo**: somente o Valkey 7.2 e posteriores ou Redis OSS 5.0.6 e posteriores estão disponíveis.
+ **Modify node type** (Modificar tipo de nó): escale clusters regionais tanto verticalmente (aumentando e reduzindo a escala vertical) quanto horizontalmente (aumentando e reduzindo a escala horizontal). As opções incluem as famílias de nós R5 e M5. Para obter mais informações sobre tipos de nós, consulte [Tipos de nó compatíveis](CacheNodes.SupportedTypes.md).
+ **Modify Automatic Failover** (Modificar failover automático): ativa ou desativa o failover automático. Quando você habilita o failover e os nós primários em clusters regionais são encerrados inesperadamente, o ElastiCache faz failover para uma das réplicas regionais. Para obter mais informações, consulte [Failover automático](AutoFailover.md).
Para clusters do Valkey ou Redis OSS com modo cluster habilitado:
+ **Add shards** (Adicionar fragmentos): insira o número de fragmentos a serem adicionados e, opcionalmente, especifique uma ou mais zonas de disponibilidade.
+ **Delete shards** (Excluir fragmentos): escolha os fragmentos a serem excluídos em cada região da AWS.
+ **Rebalance shards** (Rebalancear fragmentos): reequilibre a distribuição do slot para garantir uma distribuição uniforme entre fragmentos existentes no cluster.
Para modificar os parâmetros de um datastore global, modifique o grupo de parâmetros de qualquer cluster membro para o datastore global. O ElastiCache aplica essa alteração a todos os clusters dentro desse datastore global automaticamente. Para modificar o grupo de parâmetros desse cluster, use o console do Valkey ou do Redis OSS ou a operação da API [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html). Para obter mais informações, consulte [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md). Quando você modifica o grupo de parâmetros de qualquer cluster contido em um datastore global, ele é aplicado a todos os clusters dentro desse datastore global.
Para redefinir um grupo de parâmetros inteiro ou parâmetros específicos, use a operação de API [ResetCacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ResetCacheParameterGroup.html).
## Promoção do cluster secundário para primário
Se o cluster primário ou a região da AWS se tornar indisponível ou estiver enfrentando problemas de performance, você poderá promover um cluster secundário para primário. A promoção é permitida a qualquer momento, mesmo que outras modificações estejam em andamento. Você também pode emitir várias promoções em paralelo e o datastore global será resolvido para um primário eventualmente. Se você promover vários clusters secundários simultaneamente, o ElastiCache não garantirá qual deles será resolvido como primário.
**Como promover um cluster secundário para primário**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Datastores globais**.
1. Selecione o nome do datastore global para visualizar os detalhes
1. Escolha o cluster **Secondary** (Secundário)
1. Escolha **Promote to primary (Promover para principal)**.
Depois, você será solicitado a confirmar sua decisão com o seguinte aviso: ` 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. Escolha **Confirm (Confirmar)** se quiser continuar a promoção ou, caso contrário, escolha **Cancel (Cancelar)**.
Se você optar por confirmar, o datastore global será movido para um estado **Modifying (Modificando)** e ficará indisponível até que a promoção seja concluída.
## Remoção de uma região de um datastore global
Você pode remover uma região da AWS de um datastore global usando o procedimento a seguir.
**Como remover uma região da AWS de um datastore global**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Datastores globais**.
1. Escolha um datastore global.
1. Escolha a **Region (Região)** que deseja remover.
1. Escolha **Remove region (Remover região)**.
**nota**
Essa opção só está disponível para clusters secundários.
Depois, você será solicitado a confirmar sua decisão com o seguinte aviso: ` 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. Escolha **Confirm (Confirmar)** se quiser continuar a promoção ou, caso contrário, escolha **Cancel (Cancelar)**.
Se você escolher confirmar, a região da AWS será removida, e o cluster secundário não receberá mais atualizações de replicação.
## Exclusão de um datastore global
Para excluir um datastore global, primeiro remova todos os clusters secundários. Para obter mais informações, consulte [Remoção de uma região de um datastore global](#Redis-Global-Datastore-Console-Remove-Region). Fazer isso deixa o datastore global no status **primary-only (somente primário)**.
**Como excluir um datastore global**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Datastores globais**.
1. Em **Global Datastore Name (Nome do datastore global)** escolha o datastore global desejado e escolha **Delete (Excluir)**.
Depois, você será solicitado a confirmar sua decisão com o seguinte aviso: `Are you sure you want to delete this Global Datastore?`
1. Escolha **Excluir**.
O datastore global faz a transição para o status **Deleting (Excluindo)**.
# Uso de datastores globais (CLI)
Você pode usar a AWS Command Line Interface (AWS CLI) para controlar vários serviços da AWS via linha de comando e automatizá-los usando scripts. Você pode usar a CLI da AWS para operações ad hoc (únicas).
## Download e configuração da AWS CLI
A AWS CLI é executada no Windows, no macOS ou no Linux. Use o procedimento a seguir para fazer download e configurá-la.
**Como fazer download, instalar e configurar a CLI**
1. Baixe a CLI da AWS na página [Interface de linha de comando da AWS](https://aws.amazon.com/cli).
1. Siga as instruções para instalação da CLI da AWS e configurar a CLI da AWS no *Guia do usuário da AWS Command Line Interface*.
## Uso da CLI da AWS com datastores globais
Use as seguintes operações da CLI para trabalhar com datastores globais:
+ [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
```
O Amazon ElastiCache aplica automaticamente um prefixo ao ID do datastore global quando ele é criado. Cada região da AWS tem seu próprio prefixo. Por exemplo, um ID de datastore global criado na região Oeste dos EUA (Norte da Califórnia) começa com "virxk" junto com o nome do sufixo fornecido. O sufixo, combinado com o prefixo gerado automaticamente, garante a exclusividade do nome do datastore global em várias regiões.
A tabela a seguir lista cada região da AWS e seu prefixo de ID de datastore global.
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/Redis-Global-Datastores-CLI.html)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html): use esta operação para criar clusters secundários para um datastore global fornecendo o nome do datastore global ao parâmetro `--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
```
Ao chamar esta operação e passar um valor `--global-replication-group-id`, o ElastiCache irá inferir os valores do grupo de replicação principal do grupo de replicação global para os seguintes parâmetros. Não passe valores para estes parâmetros:
`"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
```
**Atualização entre mecanismos do Redis OSS para Valkey para ElastiCache GlobalDataStore**
Você pode atualizar um grupo de replicação global do Redis OSS existente para o Valkey usando o Console, a API ou a CLI.
Se você tiver um grupo de replicação global do Redis OSS existente, poderá fazer a atualização para o Valkey especificando o novo mecanismo e a versão do mecanismo com a API modify-global-replication-group.
Para Linux, macOS ou Unix:
```
aws elasticache modify-global-replication-group \
--global-replication-group-id myGlobalReplGroup \
--engine valkey \
--apply-immediately \
--engine-version 8.0
```
Para Windows:
```
aws elasticache modify-global-replication-group ^
--global-replication-group-id myGlobalReplGroup ^
--engine valkey ^
--apply-immediately ^
--engine-version 8.0
```
Se você tiver um grupo de parâmetros de cache personalizado aplicado ao grupo de replicação global do Redis OSS existente que deseja atualizar, também será necessário passar um grupo de parâmetros de cache personalizado do Valkey na solicitação. O grupo de parâmetros personalizados Valkey de entrada deve ter os mesmos valores de parâmetros estáticos do Redis OSS que o grupo de parâmetros personalizados do Redis OSS existente.
Para Linux, macOS ou 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
```
Para 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-replication-group](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
```
Use a ajuda para listar todos os comandos disponíveis para o ElastiCache para Valkey ou Redis OSS.
```
aws elasticache help
```
Você também pode usar a ajuda para descrever um comando específico e saber mais sobre seu uso:
```
aws elasticache create-global-replication-group help
```
# Alta disponibilidade com o uso de grupos de replicação
Os clusters do Valkey e Redis OSS do Amazon ElastiCache de nó único são entidades na memória com serviços de proteção de dados limitados (AOF). Se o seu cluster falhar por qualquer motivo, você perderá todos os dados do cluster. No entanto, se você estiver executando o mecanismo Valkey ou Redis OSS, poderá agrupar de 2 a 6 nós em um cluster com réplicas em que 1 a 5 nós somente leitura contêm dados replicados do único nó primário de leitura/gravação do grupo. Nesse cenário, se um nó falhar por qualquer motivo, você não perderá todos os seus dados, pois eles serão replicados em um ou mais outros nós. Devido à latência de replicação, alguns dados podem ser perdidos se a falha ocorrer no nó primário de leitura/gravação.
Conforme visto no gráfico a seguir, a estrutura de replicação está contida dentro de um fragmento (chamado de *grupo de nós* na API/CLI) que está contido dentro de um cluster do Valkey ou Redis OSS. Clusters do Valkey ou Redis OSS (modo cluster desabilitado) sempre têm um fragmento. Clusters do Valkey ou Redis OSS (modo cluster habilitado) podem ter até 500 fragmentos, com os dados do cluster particionados nos fragmentos. É possível criar um cluster com alto número de fragmentos e baixo número de réplicas totalizando até 90 nós por cluster. Essa configuração do cluster pode variar de 90 fragmentos e 0 réplicas para 15 fragmentos e 5 réplicas, que é o número máximo de réplicas permitidas.
O limite de nó ou fragmento pode ser aumentado para um máximo de 500 por cluster com o ElastiCache para Valkey e com o ElastiCache versão 5.0.6 ou superior para Redis OSS. Por exemplo, você pode optar por configurar um cluster de 500 nós que varia entre 83 fragmentos (uma primária e 5 réplicas por fragmento) e 500 fragmentos (primário único e sem réplicas). Verifique se existem endereços IP disponíveis suficientes para acomodar o aumento. As armadilhas comuns incluem as sub-redes no grupo de sub-redes têm um intervalo CIDR muito pequeno ou as sub-redes são compartilhadas e fortemente usadas por outros clusters. Para obter mais informações, consulte [Criação de um grupo de sub-redes](SubnetGroups.Creating.md).
Para versões abaixo de 5.0.6, o limite é 250 por cluster.
Para solicitar um aumento de limite, consulte [Limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e selecione o tipo de limite **Nodes per cluster per instance type** (Nós por cluster por tipo de instância).
![\[Imagem: Cluster do Valkey ou Redis OSS (modo cluster desabilitado) tem um fragmento e de 0 a 5 nós de réplicas\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Cluster do Valkey ou Redis OSS (modo cluster desabilitado) tem um fragmento e de 0 a 5 nós de réplicas*
Se o cluster com réplicas tiver o Multi-AZ habilitado e o nó primário falhar, esse nó primário executará failover em uma réplica de leitura. Como os dados são atualizados nos nós de réplica de forma assíncrona, pode haver alguma perda de dados devido à latência na atualização dos nós de réplica. Para obter mais informações, consulte [Mitigar falhas ao executar o Valkey ou Redis OSS](disaster-recovery-resiliency.md#FaultTolerance.Redis).
**Topics**
+ [Entendendo a replicação do Valkey e do Redis OSS](Replication.Redis.Groups.md)
+ [Replicação: Modo de cluster Valkey e Redis OSS desativado versus ativado](Replication.Redis-RedisCluster.md)
+ [Minimizar o tempo de inatividade no ElastiCache usando o Multi-AZ com Valkey e Redis OSS](AutoFailover.md)
+ [Como a sincronização e o backup são implementados](Replication.Redis.Versions.md)
+ [Criação de um grupo de replicação do Valkey ou Redis OSS](Replication.CreatingRepGroup.md)
+ [Visualização dos detalhes de um grupo de replicação](Replication.ViewDetails.md)
+ [Localização de endpoints de grupo de replicação](Replication.Endpoints.md)
+ [Modificação de um grupo de replicação](Replication.Modify.md)
+ [Exclusão de um grupo de replicação](Replication.DeletingRepGroup.md)
+ [Alteração do número de réplicas](increase-decrease-replica-count.md)
+ [Promoção de uma réplica de leitura a primário, para grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado)](Replication.PromoteReplica.md)
# Entendendo a replicação do Valkey e do Redis OSS
O Redis OSS implementa a replicação de duas formas:
+ Com um único fragmento que contém todos os dados do cluster em cada nó: Valkey ou Redis OSS (modo cluster desabilitado)
+ Com dados particionados em até 500 fragmentos: Valkey ou Redis OSS (modo cluster habilitado)
Cada fragmento em um grupo de replicação tem um único nó primário de leitura/gravação e até 5 nós de réplica somente de leitura. É possível criar um cluster com alto número de fragmentos e baixo número de réplicas totalizando até 90 nós por cluster. Essa configuração do cluster pode variar de 90 fragmentos e 0 réplicas para 15 fragmentos e 5 réplicas, que é o número máximo de réplicas permitidas.
O limite de nó ou fragmento pode ser aumentado para um máximo de 500 por cluster se a versão do mecanismo Redis OSS for 5.0.6 ou superior. Por exemplo, você pode optar por configurar um cluster de 500 nós que varia entre 83 fragmentos (uma primária e 5 réplicas por fragmento) e 500 fragmentos (primário único e sem réplicas). Verifique se existem endereços IP disponíveis suficientes para acomodar o aumento. As armadilhas comuns incluem as sub-redes no grupo de sub-redes têm um intervalo CIDR muito pequeno ou as sub-redes são compartilhadas e fortemente usadas por outros clusters. Para obter mais informações, consulte [Criação de um grupo de sub-redes](SubnetGroups.Creating.md).
Para versões abaixo de 5.0.6, o limite é 250 por cluster.
Para solicitar um aumento de limite, consulte [Limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e selecione o tipo de limite **Nodes per cluster per instance type** (Nós por cluster por tipo de instância).
**Topics**
+ [Valkey ou Redis OSS (modo cluster desabilitado)](#Replication.Redis.Groups.Classic)
+ [Valkey ou Redis OSS (modo cluster habilitado)](#Replication.Redis.Groups.Cluster)
## Valkey ou Redis OSS (modo cluster desabilitado)
Um cluster do Valkey ou Redis OSS (modo cluster desabilitado) tem um único fragmento, dentro do qual há uma coleção de nós; um nó de leitura/gravação primário e até cinco nós de réplica secundários somente de leitura. Cada réplica de leitura mantém uma cópia dos dados do nó primário do cluster. Mecanismos de replicação assíncronos são usados para manter as réplicas de leitura sincronizadas com a primária. Os aplicativos podem ler a partir de qualquer nó no cluster. Os aplicativos podem apenas gravar no nó primário. Réplicas de leitura melhoram o throughput de leitura e protegem contra a perda de dados nos casos de falha de um nó.
![\[Imagem: Cluster do Valkey ou Redis OSS (modo cluster desabilitado) com um único fragmento e nós de réplicas\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-Redis-Replicas.png)
*Cluster do Valkey ou Redis OSS (modo cluster desabilitado) com um único fragmento e nós de réplicas*
Você pode usar clusters do Valkey ou Redis OSS (modo cluster desabilitado) com réplicas de nós para escalar sua solução para o ElastiCache de modo a lidar com aplicações de leitura intensiva ou para oferecer suporte a um grande número de clientes que leiam simultaneamente do mesmo cluster.
Todos os nós em um cluster do Valkey ou Redis OSS (modo cluster desabilitado) devem residir na mesma região.
Quando você adiciona uma réplica de leitura a um cluster, todos os dados do primário são copiados para o novo nó. A partir desse momento, sempre que os dados são gravados no primário, as alterações são propagadas de forma assíncrona em todas as réplicas de leitura.
Para melhorar a tolerância a falhas e reduzir o tempo de gravação, habilitar o recurso multi-AZ com failover automático para o seu cluster do Valkey ou Redis OSS (modo cluster desabilitado) com réplicas. Para obter mais informações, consulte [Minimizar o tempo de inatividade no ElastiCache usando o Multi-AZ com Valkey e Redis OSS](AutoFailover.md).
Você pode alterar as funções dos nós dentro do cluster do Valkey ou Redis OSS (modo cluster desabilitado) com o primário e uma das réplicas trocando funções. Você pode decidir fazer isso por motivos de ajuste de desempenho. Por exemplo, com um aplicativo Web que possui uma intensa atividade de gravação, você pode escolher o nó que tenha a menor latência da rede. Para obter mais informações, consulte [Promoção de uma réplica de leitura a primário, para grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado)](Replication.PromoteReplica.md).
## Valkey ou Redis OSS (modo cluster habilitado)
Um cluster do Valkey ou Redis OSS (modo cluster habilitado) é composto de 1 a 500 fragmentos (API/CLI: grupos de nós). Cada fragmento tem um nó primário e até cinco nós de réplica de leitura. A configuração pode variar de 90 fragmentos e 0 réplicas para 15 fragmentos e 5 réplicas, que é o número máximo de réplicas permitidas.
O limite de nós ou fragmentos pode ser aumentado para um máximo de 500 por cluster se a versão do mecanismo for Valkey 7.2 e posteriores ou Redis OSS 5.0.6 e posteriores. Por exemplo, você pode optar por configurar um cluster de 500 nós que varia entre 83 fragmentos (uma primária e 5 réplicas por fragmento) e 500 fragmentos (primário único e sem réplicas). Verifique se existem endereços IP disponíveis suficientes para acomodar o aumento. As armadilhas comuns incluem as sub-redes no grupo de sub-redes têm um intervalo CIDR muito pequeno ou as sub-redes são compartilhadas e fortemente usadas por outros clusters. Para obter mais informações, consulte [Criação de um grupo de sub-redes](SubnetGroups.Creating.md).
Para versões abaixo de 5.0.6, o limite é 250 por cluster.
Para solicitar um aumento de limite, consulte [Limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e selecione o tipo de limite **Nodes per cluster per instance type** (Nós por cluster por tipo de instância).
Cada réplica de leitura em um fragmento mantém uma cópia dos dados do primário do fragmento. Mecanismos de replicação assíncronos são usados para manter as réplicas de leitura sincronizadas com a primária. Os aplicativos podem ler a partir de qualquer nó no cluster. Os aplicativos podem apenas gravar nos nós primários. Réplicas de leitura melhoram a escalabilidade de leitura e protegem contra a perda de dados. Os dados são particionados em todos os fragmentos em um cluster do Valkey ou Redis OSS (modo cluster habilitado).
As aplicações usam o *endpoint de configuração* do cluster do Valkey ou Redis OSS (modo cluster habilitado) para se conectar aos nós no cluster. Para obter mais informações, consulte [Encontrar endpoints de conexão no ElastiCache](Endpoints.md).
![\[Imagem: Cluster do Valkey ou Redis OSS (modo cluster habilitado) com vários fragmentos e nós de réplicas\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCacheClusters-CSN-RedisClusters.png)
*Cluster do Valkey ou Redis OSS (modo cluster habilitado) com vários fragmentos e nós de réplica*
Todos os nós em um cluster do Valkey ou Redis OSS (modo cluster habilitado) devem residir na mesma região. Para melhorar a tolerância a falhas, você pode provisionar primários e réplicas de leitura em várias zonas de disponibilidade dentro dessa região.
Atualmente, os recursos Valkey ou Redis OSS (modo cluster habilitado) têm algumas limitações.
+ Você não pode promover manualmente nenhum nó de réplica para primário.
# Replicação: Modo de cluster Valkey e Redis OSS desativado versus ativado
Começando com o Valkey 7.2 e o Redis OSS versão 3.2, você pode criar um dos dois tipos distintos de clusters (API/CLI: grupos de replicação). Um cluster do Valkey ou Redis OSS (modo cluster desabilitado) sempre possui um único fragmento (API/CLI: grupo de nós) com até 5 nós de réplicas de leitura. Um cluster do Valkey ou Redis OSS (modo cluster habilitado) tem até 500 fragmentos de 1 a 5 nós de réplicas de leitura em cada.
![\[Imagem: Clusters do Valkey ou Redis OSS (modo cluster desabilitado) e do Valkey ou Redis OSS (modo cluster habilitado)\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-NodeGroups.png)
*Clusters do Valkey ou Redis OSS (modo cluster desabilitado) e do Redis OSS (modo cluster habilitado)*
A tabela a seguir resume diferenças importantes entre os clusters do Valkey ou Redis OSS (modo cluster desabilitado) e do Valkey ou Redis OSS (modo cluster habilitado).
**Comparação de clusters do Valkey ou Redis OSS (modo cluster desabilitado) e do Valkey ou Redis OSS (modo cluster habilitado)**
| Recurso | Valkey ou Redis OSS (modo cluster desabilitado) | Valkey ou Redis OSS (modo cluster habilitado) |
| --- | --- | --- |
| Modificável | Sim. Oferece suporte para adicionar e excluir nós de réplica e aumentar a escala verticalmente do tipo de nó. | Limitado. Para obter mais informações, consulte [Gerenciamento de versões para ElastiCache](VersionManagement.md) e [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md). |
| Particionamento de dados | Não | Sim |
| Estilhaços | 1 | 1 a 500 |
| Réplicas de leitura | 0 – 5 Se você não tiver réplicas e o nó falhar, ocorrerá uma perda total de dados. | 0 a 5 por fragmento. Se você não tiver réplicas e um nó falhar, ocorrerá uma perda de todos os dados nesse estilhaço. |
| Multi-AZ | Sim, com pelo menos 1 réplica. Opcional. Ativado por padrão. | SimOpcional. Ativado por padrão. |
| Snapshots (Backups) | Sim, criando um único arquivo .rdb. | Sim, criando um arquivo .rdb exclusivo para cada estilhaço. |
| Restaurar | Sim, usando um único arquivo .rdb de um cluster do Valkey ou Redis OSS (modo cluster desabilitado). | Sim, usando arquivos .rdb de um cluster do Valkey ou Redis OSS (modo cluster desabilitado) ou do Valkey ou Redis OSS (modo cluster habilitado). |
| Com suporte por | Todas as versões do Valkey e Redis OSS | Todas as versões do Valkey e Redis OSS 3.2 e seguintes |
| Mecanismo atualizável | Sim, com alguns limites. Para obter mais informações, consulte [Gerenciamento de versões para ElastiCache](VersionManagement.md). | Sim, com alguns limites. Para obter mais informações, consulte [Gerenciamento de versões para ElastiCache](VersionManagement.md). |
| Criptografia | Versões 3.2.6 (programadas para EOL, consulte [Cronograma de fim de vida útil das versões do Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e posteriores. | Versões 3.2.6 (programadas para EOL, consulte [Cronograma de fim de vida útil das versões do Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e posteriores. |
| Elegível para HIPAA | Versões 3.2.6 (programadas para EOL, consulte [Cronograma de fim de vida útil das versões do Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e posteriores. | Versões 3.2.6 (programadas para EOL, consulte [Cronograma de fim de vida útil das versões do Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e posteriores. |
| Compatível com PCI DSS | Versões 3.2.6 (programadas para EOL, consulte [Cronograma de fim de vida útil das versões do Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e posteriores. | Versões 3.2.6 (programadas para EOL, consulte [Cronograma de fim de vida útil das versões do Redis OSS](engine-versions.md#deprecated-engine-versions)) e 4.0.10 e posteriores. |
| Reestilhaçamento online | N/D | Versão 3.2.10 (programada para EOL, consulte [Cronograma de fim de vida útil das versões do Redis OSS](engine-versions.md#deprecated-engine-versions)) e posterior. |
## Qual devo escolher?
Ao escolher entre Valkey ou Redis OSS (modo cluster desabilitado) ou Valkey ou Redis OSS (modo cluster habilitado), considere os seguintes fatores:
+ **Escalabilidade versus particionamento**: os negócios precisam mudar. Você precisa fornecer provisão para demanda máxima ou escalar conforme a demanda sofre alterações. O Valkey ou Redis OSS (modo cluster desabilitado) oferece suporte a escalabilidade. Você pode dimensionar a capacidade de leitura adicionando ou excluindo nós de réplica ou pode dimensionar a capacidade aumentando para um tipo de nó maior. Ambas as operações exigem tempo. Para obter mais informações, consulte [Escalar nós de réplica para Valkey ou Redis OSS (modo cluster desativado)](Scaling.RedisReplGrps.md).
O Valkey ou Redis OSS (modo cluster habilitado) oferece suporte para o particionamento dos seus dados em até 500 grupos de nós. Você pode alterar dinamicamente o número de estilhaços à medida que suas necessidades de negócios mudam. Uma vantagem do particionamento é que você espalha sua carga em um número maior de endpoints que reduz o afunilamento de acesso durante a demanda de pico. Além disso, você pode acomodar um conjunto de dados maior, pois os dados podem ser distribuídos em vários servidores. Para obter informações sobre como escalar suas partições, consulte [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md).
+ **Tamanho do nó versus número de nós**: como um cluster do Valkey ou Redis OSS (modo cluster desabilitado) tem apenas um fragmento, o tipo de nó deve ser grande o suficiente para acomodar todos os dados do cluster mais a sobrecarga necessária. Por outro lado, como você pode particionar seus dados em vários fragmentos ao usar um cluster do Valkey ou Redis OSS (modo cluster habilitado), os tipos de nós podem ser menores, embora você precise de mais deles. Para obter mais informações, consulte [Escolha do tamanho do nó](CacheNodes.SelectSize.md).
+ **Leituras versus gravações**: se a carga principal no seu cluster for de aplicações que leiam dados, você poderá escalar um cluster do Valkey ou Redis OSS (modo cluster habilitado) adicionando e excluindo réplicas de leitura. No entanto, há um máximo de 5 réplicas de leitura. Se a carga no seu cluster for de escrita pesada, você poderá se beneficiar dos endpoints de gravação adicionais de um cluster do Valkey ou Redis OSS (modo cluster habilitado) com vários fragmentos.
Seja qual for o tipo de cluster que você optar por implementar, certifique-se de escolher um tipo de nó que seja adequado para suas necessidades atuais e futuras.
# Minimizar o tempo de inatividade no ElastiCache usando o Multi-AZ com Valkey e Redis OSS
Há várias instâncias em que o ElastiCache para Valkey e Redis OSS pode precisar substituir um nó primário; elas incluem certos tipos de manutenção planejada e o evento improvável de falha em um nó primário ou zona de disponibilidade.
Essa substituição resulta em algum tempo de inatividade do cluster, mas se o multi-AZ estiver habilitado, o tempo de inatividade será minimizado. A função do nó primário fará failover automaticamente para uma das réplicas de leitura. Não há necessidade de criar e provisionar um novo nó primário, porque o ElastiCache lidará com isso de forma transparente. O failover e a promoção de réplica garantem que você possa continuar a gravar no novo primário assim que a promoção estiver concluída.
O ElastiCache também propaga o nome do DNS (Serviço de Nomes de Domínio) da réplica promovida. Isso ocorre porque, em seguida, se o seu aplicativo estiver gravando no endpoint primário, nenhuma alteração nesse endpoint será necessária no seu aplicativo. Se estiver lendo de endpoints individuais, altere o endpoint de leitura da réplica promovida a primária para o endpoint da nova réplica.
No caso de substituições de nó planejadas, iniciadas devido a atualizações de manutenção ou atualizações de autoatendimento, esteja ciente do seguinte:
+ Para clusters do Valkey e Redis OSS, as substituições de nó planejadas são concluídas enquanto o cluster atende às solicitações de gravação recebidas.
+ Para clusters desabilitados do modo de cluster do Valkey e Redis OSS com o Multi-AZ habilitado que são executados no mecanismo 5.0.6 ou posterior, as substituições de nó planejadas são concluídas enquanto o cluster atende às solicitações de gravação recebidas.
+ Para clusters desabilitados do modo de cluster do Valkey e Redis OSS com o Multi-AZ habilitado que são executados no mecanismo 4.0.10 ou anterior, é possível notar uma breve interrupção de gravação associada às atualizações de DNS. Essa interrupção pode levar até alguns segundos. Esse processo é muito mais rápido do que recriar e provisionar um novo primário, que será o caso se você não habilitar o multi-AZ.
É possível habilitar o multi-AZ usando o console de gerenciamento do ElastiCache, a AWS CLI ou a API do ElastiCache.
Habilitar o Multi-AZ do ElastiCache no cluster do Valkey ou Redis OSS (na API e CLI ou no grupo de replicação) melhora a tolerância a falhas. Isso é verdade, especialmente nos casos em que o cluster primário de leitura/gravação do seu cluster se torna inacessível ou falha por qualquer motivo. O Multi-AZ só é aceito em clusters do Valkey e Redis OSS com mais de um nó em cada fragmento.
**Topics**
+ [Habilitar Multi-AZ](#AutoFailover.Enable)
+ [Cenários de falha com respostas do multi-AZ](#AutoFailover.Scenarios)
+ [Teste do failover automático](#auto-failover-test)
+ [Limitações no Multi-AZ](#AutoFailover.Limitations)
## Habilitar Multi-AZ
É possível habilitar o multi-AZ ao criar ou modificar um cluster (API, CLI ou grupo de replicação) usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache.
É possível habilitar o Multi-AZ somente em clusters do Valkey ou Redis OSS (modo cluster desabilitado) que têm pelo menos uma réplica de leitura disponível. Clusters sem réplicas de leitura não fornece alta disponibilidade ou tolerância a falhas. Para obter informações sobre como criar um cluster com replicação, consulte [Criação de um grupo de replicação do Valkey ou Redis OSS](Replication.CreatingRepGroup.md). Para obter informações sobre como adicionar uma réplica de leitura a um cluster com replicação, consulte [Adição de uma réplica de leitura do Valkey ou do Redis OSS (modo cluster desabilitado)](Replication.AddReadReplica.md).
**Topics**
+ [Habilitação do multi-AZ (console)](#AutoFailover.Enable.Console)
+ [Habilitar o recurso multi-AZ (AWS CLI)](#AutoFailover.Enable.CLI)
+ [Habilitação do multi-AZ (API do ElastiCache)](#AutoFailover.Enable.API)
### Habilitação do multi-AZ (console)
É possível habilitar o Multi-AZ usando o console do ElastiCache ao criar um novo cluster do Valkey ou Redis OSS ou modificando um cluster existente com replicação.
O Multi-AZ é habilitado por padrão em clusters do Valkey ou Redis OSS (modo cluster habilitado).
**Importante**
O ElastiCache habilitará automaticamente o multi-AZ somente se o cluster contiver pelo menos uma réplica em uma zona de disponibilidade diferente da principal em todos os fragmentos.
#### Habilitação do multi-AZ ao criar um cluster usando o console do ElastiCache
Para obter mais informações sobre esse processo, consulte [Criação de um cluster do Valkey (modo cluster desabilitado) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs). Tenha uma ou mais réplicas e habilite o Multi-AZ.
#### Habilitação do multi-AZ em um cluster existente (console)
Para obter mais informações sobre esse processo, consulte Modificação de um cluster [Uso do Console de gerenciamento da AWS do ElastiCache](Clusters.Modify.md#Clusters.Modify.CON).
### Habilitar o recurso multi-AZ (AWS CLI)
O exemplo de código a seguir usa a AWS CLI para habilitar o Multi-AZ para o grupo de replicação `redis12`.
**Importante**
O grupo de replicação `redis12` já deve existir e ter pelo menos uma réplica de leitura disponível.
Para Linux, macOS ou Unix:
```
aws elasticache modify-replication-group \
--replication-group-id redis12 \
--automatic-failover-enabled \
--multi-az-enabled \
--apply-immediately
```
Para Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id redis12 ^
--automatic-failover-enabled ^
--multi-az-enabled ^
--apply-immediately
```
A saída JSON desse comando deve ser semelhante ao seguinte.
```
{
"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": {}
}
}
```
Para obter mais informações, consulte estes tópicos na *AWS CLI Referência de comandos*:
+ [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) na *AWS CLI Referência de comandos.*
### Habilitação do multi-AZ (API do ElastiCache)
O exemplo de código a seguir usa a API do ElastiCache para habilitar o multi-AZ para o grupo de replicação `redis12`.
**nota**
Para usar esse exemplo, o grupo de replicação `redis12` já deve existir e ter pelo menos uma réplica de leitura disponível.
```
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=
```
Para obter mais informações, veja estes tópicos na *Referência da API do 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)
## Cenários de falha com respostas do multi-AZ
Antes da introdução do multi-AZ, o ElastiCache detectava e substituía os nós com falha de um cluster recriando e reprovisionando esses nós. Se você habilitar o Multi-AZ, um nó primário com falha fará failover para a réplica com o menor atraso de replicação. A réplica selecionada é promovida automaticamente para primário, o que é muito mais rápido do que criar e reprovisionar um novo nó primário. Esse processo normalmente demora apenas alguns segundos até que você possa gravar novamente no cluster.
Quando o multi-AZ está habilitado, o ElastiCache monitora continuamente o estado do nó primário. Se o nó primário falhar, uma das seguintes ações será realizada, dependendo do tipo da falha.
**Topics**
+ [Cenários de falha quando somente o nó primário falha](#AutoFailover.Scenarios.PrimaryOnly)
+ [Cenários de falha quando o nó primário e algumas réplicas de leitura falham](#AutoFailover.Scenarios.PrimaryAndReplicas)
+ [Cenários de falha quando cluster inteiro falha](#AutoFailover.Scenarios.AllFail)
### Cenários de falha quando somente o nó primário falha
Se somente o nó primário falhar, a réplica de leitura com o menor atraso de replicação será promovida a primária. Depois disso, uma réplica de leitura de substituição é criada e provisionada na mesma zona de disponibilidade que o primário com falha.
Quando somente o nó primário falha, o recurso multi-AZ do ElastiCache faz o seguinte:
1. O nó primário com falha é colocado offline.
1. A réplica de leitura com o menor atraso de replicação é promovida a primário.
As gravações poderão ser retomadas assim que o processo de promoção estiver concluído, normalmente depois de apenas alguns segundos. Se a sua aplicação estiver gravando no endpoint primário, não será necessário alterar o endpoint para gravações ou leituras. O ElastiCache propaga o nome do DNS da réplica promovida.
1. Uma réplica de leitura de substituição é executada e provisionada.
A réplica de leitura de substituição é executada na Zona de disponibilidade em que o nó primário com falha se encontrava, para que a distribuição de nós seja mantida.
1. As réplicas são sincronizadas com o novo nó primário.
Depois que a nova réplica estiver disponível, lembre-se dos seguintes efeitos:
+ **Endpoint primário**: não faça alterações na sua aplicação, pois o nome do DNS do novo nó primário é propagado para o endpoint primário.
+ **Endpoint leitor**: o endpoint leitor é atualizado automaticamente para apontar para os novos nós de réplica.
Para obter informações sobre como encontrar os endpoints de um cluster, consulte os seguintes tópicos:
+ [Localização de endpoints de um cluster do Valkey ou do Redis OSS (modo cluster desabilitado) (console)](Endpoints.md#Endpoints.Find.Redis)
+ [Localização de endpoints para grupos de replicação do Valkey ou Redis OSS (AWS CLI)](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Localização de endpoints para grupos de replicação do Valkey ou Redis OSS (API do ElastiCache)](Endpoints.md#Endpoints.Find.API.ReplGroups)
### Cenários de falha quando o nó primário e algumas réplicas de leitura falham
Se o primário e pelo menos uma réplica de leitura falhar, a réplica disponível com o menor atraso de replicação será promovida a cluster primário. Novas réplicas de leitura também são criadas e provisionadas nas mesmas Zonas de disponibilidade que os nós com falha e a réplica que foi promovida a primário.
Quando o nó primário e algumas réplicas de leitura falham, o multi-AZ do ElastiCache faz o seguinte:
1. O nó primário com falha e as réplicas de leitura com falha são colocadas offline.
1. A réplica disponível com o menor atraso de replicação é promovida a nó primário.
As gravações poderão ser retomadas assim que o processo de promoção estiver concluído, normalmente depois de apenas alguns segundos. Se a sua aplicação estiver gravando no endpoint primário, não será necessário alterar o endpoint para gravações. O ElastiCache propaga o nome do DNS da réplica promovida.
1. Réplicas de substituição são criadas e provisionadas.
As réplicas de substituição são criadas nas Zonas de disponibilidade dos nós com falha, de modo que a distribuição de nós seja mantida.
1. Todos os clusters são sincronizados com o novo nó primário.
Faça as seguintes alterações no seu aplicativo depois que os novos nós estiverem disponíveis:
+ **Endpoint primário**: não faça alterações em sua aplicação. O nome de DNS do novo nó primário é propagado para o endpoint primário.
+ **Endpoint leitor**: o endpoint leitor é atualizado automaticamente para apontar para os novos nós de réplica.
Para obter informações sobre como encontrar os endpoints de um grupo de replicação, consulte os seguintes tópicos:
+ [Localização de endpoints de um cluster do Valkey ou do Redis OSS (modo cluster desabilitado) (console)](Endpoints.md#Endpoints.Find.Redis)
+ [Localização de endpoints para grupos de replicação do Valkey ou Redis OSS (AWS CLI)](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Localização de endpoints para grupos de replicação do Valkey ou Redis OSS (API do ElastiCache)](Endpoints.md#Endpoints.Find.API.ReplGroups)
### Cenários de falha quando cluster inteiro falha
Se tudo falhar, todos os nós serão recriados e provisionados nas mesmas Zonas de disponibilidade que os nós originais.
Nesse cenário, todos os dados do cluster são perdidos devido à falha de cada nó no cluster. Essa ocorrência é rara.
Quando o cluster inteiro falha, o multi-AZ do ElastiCache faz o seguinte:
1. O nó primário e as réplicas de leitura com falha são colocados offline.
1. Um nó primário de substituição é criado e provisionado.
1. Réplicas de substituição são criadas e provisionadas.
As substituição são criadas nas Zonas de disponibilidade dos nós com falha, de modo que a distribuição de nós seja mantida.
Como o cluster inteiro falhou, os dados são perdidos, e todos os novos nós são iniciados a frio.
Como cada um dos nós de substituição tem o mesmo endpoint que o nó que ele está substituindo, não é necessário fazer alterações de endpoint no seu aplicativo.
Para obter informações sobre como encontrar os endpoints de um grupo de replicação, consulte os seguintes tópicos:
+ [Localização de endpoints de um cluster do Valkey ou do Redis OSS (modo cluster desabilitado) (console)](Endpoints.md#Endpoints.Find.Redis)
+ [Localização de endpoints para grupos de replicação do Valkey ou Redis OSS (AWS CLI)](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Localização de endpoints para grupos de replicação do Valkey ou Redis OSS (API do ElastiCache)](Endpoints.md#Endpoints.Find.API.ReplGroups)
Recomendamos que você crie o nó primário e as réplicas de leitura em diferentes Zonas de disponibilidade para aumentar o nível de tolerância a falhas.
## Teste do failover automático
Depois de habilitar o failover automático, é possível testá-lo usando o console do ElastiCache, a AWS CLI e a API do ElastiCache.
Ao testar, observe o seguinte:
+ Você pode usar essa operação para testar o failover automático em até 15 fragmentos (chamados de grupos de nós na API do ElastiCache e na AWS CLI) em qualquer período contínuo de 24 horas.
+ Se você chamar essa operação em estilhaços em clusters diferentes (chamados grupos de replicação na API e CLI), poderá fazer as chamadas simultaneamente.
+ Em alguns casos, é possível chamar essa operação várias vezes em diferentes fragmentos no mesmo grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado). Nesses casos, a substituição do primeiro nó deve ser concluída antes que uma chamada subsequente possa ser feita.
+ Para determinar se a substituição do nó está completa, verifique os eventos usando o console do Amazon ElastiCache, a AWS CLI ou a API do ElastiCache. Procure pelos seguintes eventos relacionados ao failover automático, listados aqui em ordem de ocorrência:
1. Mensagem do grupo de replicação: `Test Failover API called for node group `
1. Mensagem do cluster de cache: `Failover from primary node to replica node completed`
1. Mensagem do grupo de replicação: `Failover from primary node to replica node completed`
1. Mensagem do cluster de cache: `Recovering cache nodes `
1. Mensagem do cluster de cache: `Finished recovery for cache nodes `
Para obter mais informações, consulte:
+ [Visualizando ElastiCache eventos](ECEvents.Viewing.md) no *Guia do usuário do ElastiCache*
+ [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html) na * Referência da API do ElastiCache*
+ [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) na *AWS CLI Referência de comandos.*
+ Essa API foi projetada para testar o comportamento de sua aplicação em caso de failover do ElastiCache. Ela não foi projetado para ser uma ferramenta operacional para iniciar um failover a fim de resolver um problema com o cluster. Além disso, sob determinadas condições, como eventos operacionais de grande escala, a AWS pode bloquear essa API.
**Topics**
+ [Teste do failover automático usando o Console de gerenciamento da AWS](#auto-failover-test-con)
+ [Teste do failover automático usando o AWS CLI](#auto-failover-test-cli)
+ [Teste do failover automático usando a API do ElastiCache](#auto-failover-test-api)
### Teste do failover automático usando o Console de gerenciamento da AWS
Use o procedimento a seguir para testar o failover automático com o console.
**Para testar o failover automático**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS**.
1. Na lista de clusters, escolha a caixa à esquerda do cluster que deseja testar. Esse cluster deve ter pelo menos um nó de réplica de leitura.
1. Na área **Details**, confirme se esse cluster está habilitado para Multi-AZ. Se o cluster não estiver habilitado para o Multi-AZ, escolha um cluster diferente ou modifique esse cluster para habilitar o Multi-AZ. Para obter mais informações, consulte [Uso do Console de gerenciamento da AWS do ElastiCache](Clusters.Modify.md#Clusters.Modify.CON).
![\[Imagem: área Detalhes de um cluster habilitado para Multi-AZ\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-AutoFailover-MultiAZ-Enabled.png)
1. Para o Valkey ou Redis OSS (modo cluster desabilitado), escolha o nome do cluster.
Para o Valkey ou Redis OSS (modo cluster habilitado), faça o seguinte:
1. Escolha o nome do cluster.
1. Na página **Shards**, para o estilhaço (chamado de grupo de nó na API e na CLI) no qual você deseja testar o failover, escolha o nome do estilhaço.
1. Na página Nodes, escolha **Failover Primary**.
1. Escolha **Continue** para fazer failover do primário ou **Cancel** para cancelar a operação e não fazer failover do nó primário.
Durante o processo de failover, o console continua a mostrar o status do nó como *disponível*. Para acompanhar o progresso do seu teste de failover, escolha **Events** no painel de navegação do console. Na guia **Eventos**, observe os eventos que indicam que o failover foi iniciado (`Test Failover API called`) e concluído (`Recovery completed`).
### Teste do failover automático usando o AWS CLI
É possível testar o failover automático em qualquer cluster habilitado para Multi-AZ usando a operação da AWS CLI `test-failover`.
**Parâmetros**
+ `--replication-group-id`: obrigatório. O grupo de replicação (no console, cluster) que deve ser testado.
+ `--node-group-id`: obrigatório. O nome do grupo de nós nos quais você deseja testar o failover automático. Você pode testar um máximo de 15 grupos de nós em um período contínuo de 24 horas.
O exemplo a seguir usa a AWS CLI para testar o failover automático no grupo de nós `redis00-0003` do cluster do Valkey ou Redis OSS (modo cluster habilitado) `redis00`.
**Example Teste de failover automático**
Para Linux, macOS ou Unix:
```
aws elasticache test-failover \
--replication-group-id redis00 \
--node-group-id redis00-0003
```
Para Windows:
```
aws elasticache test-failover ^
--replication-group-id redis00 ^
--node-group-id redis00-0003
```
A saída do comando precedente é semelhante ao seguinte.
```
{
"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": {}
}
}
```
Para acompanhar o progresso do failover, use a operação da AWS CLI `describe-events`.
Para obter mais informações, consulte:
+ [test-failover](https://docs.aws.amazon.com/cli/latest/reference/elasticache/test-failover.html) na *AWS CLI Referência de comandos.*
+ [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) na *AWS CLI Referência de comandos.*
### Teste do failover automático usando a API do ElastiCache
É possível testar o failover automático em qualquer cluster habilitado com multi-AZ usando a operação de API do ElastiCache `TestFailover`.
**Parâmetros**
+ `ReplicationGroupId`: obrigatório. O grupo de replicação (no console ou cluster) a ser testado.
+ `NodeGroupId`: obrigatório. O nome do grupo de nós nos quais você deseja testar o failover automático. Você pode testar um máximo de 15 grupos de nós em um período contínuo de 24 horas.
O exemplo a seguir testa o failover automático no grupo de nós `redis00-0003` no grupo de replicação (no console, cluster) `redis00`.
**Example Teste do failover automático**
```
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=
```
Para acompanhar o progresso do failover, use a operação de API do ElastiCache `DescribeEvents`.
Para obter mais informações, consulte:
+ [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html) na *Referência da API do ElastiCache*
+ [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html) na *Referência da API do ElastiCache*
## Limitações no Multi-AZ
Esteja ciente das seguintes limitações para o Multi-AZ:
+ O Multi-AZ é compatível com Valkey e com Redis OSS versão 2.8.6 e posteriores.
+ O Multi-AZ não é aceito em tipos de nós T1.
+ A replicação do Valkey e Redis OSS é assíncrona. Portanto, quando um nó primário faz failover em uma réplica, uma pequena quantidade de dados pode ser perdida devido ao atraso da replicação.
Ao escolher a réplica a ser promovida a primária, o ElastiCache escolhe a réplica com o menor atraso de replicação. Em outras palavras, ele escolha a réplica que é mais atual. Isso ajuda a minimizar a quantidade de dados perdidos. A réplica com o atraso de replicação mínimo pode estar na mesma zona de disponibilidade ou em outra em relação ao nó primário com falha.
+ Ao promover manualmente réplicas de leitura para primárias em clusters do Valkey ou Redis OSS com o modo cluster desabilitado, você só poderá fazer isso quando o Multi-AZ e o failover automático estiverem desabilitados. Para promover uma réplica de leitura para primário, execute as seguintes etapas:
1. Desabilite o Multi-AZ no cluster.
1. Desabilite o failover automático no cluster. Isso pode ser feito por meio do console desmarcando a caixa de seleção **Failover automático** para o grupo de replicação. Também é possível fazer isso usando a AWS CLI definindo a propriedade `AutomaticFailoverEnabled` como `false` ao chamar a operação `ModifyReplicationGroup`.
1. Promova a réplica de leitura para primário.
1. Habilite novamente o Multi-AZ.
+ O multi-AZ do ElastiCache for Redis OSS e o arquivo somente de acréscimo (AOF) são mutuamente exclusivos. Se você habilitar um, não é possível habilitar o outro.
+ Uma falha de um nó pode ser causada pelo evento raro de falha total de uma zona de disponibilidade. Neste caso, a réplica que substitui o primário com falha é criada somente quando a zona de disponibilidade volta a ficar ativa. Por exemplo, considere um grupo de replicação com o primário em AZ-a e réplicas em AZ-b e AZ-c. Se o primário falhar, a réplica com o menor atraso de replicação será promovida a cluster primário. O ElastiCache criará uma nova réplica em AZ-a (onde o primário com falha estava localizado) somente quando AZ-a voltar a ficar ativa e disponível.
+ Uma reinicialização iniciada pelo cliente de um primário não aciona o failover automático. Outras reinicializações e falhas desencadeiam o failover automático.
+ Quando o primário é reiniciado, seus dados são limpos quando ele volta a ficar online. Quando as réplicas de leitura veem o cluster primário limpo, elas limpam suas cópias dos dados, o que causa perda de dados.
+ Depois que uma réplica de leitura foi promovida, as outras réplicas se sincronizam com o novo primário. Após a sincronização inicial, o conteúdo das réplicas é excluído, e eles sincronizam os dados do novo primário. Esse processo de sincronização causa uma breve interrupção, durante a qual as réplicas não são acessíveis. O processo de sincronização também causa um aumento de carga temporário no primário durante a sincronização com as réplicas. Esse comportamento é nativo do Valkey e do Redis OSS e não é exclusivo do Multi-AZ do ElastiCache. Para obter detalhes sobre esse comportamento, consulte [Replicação](http://valkey.io/topics/replication) no site do Valkey.
**Importante**
Para Valkey 7.2.6 e posterior ou Redis OSS versão 2.8.22 e posterior, não é possível criar réplicas externas.
Para versões do Redis OSS anteriores à 2.8.22, recomendamos que você não conecte uma réplica externa a um cluster do ElastiCache que esteja habilitado para Multi-AZ. Essa configuração sem suporte pode criar problemas que impedem que o ElastiCache realize corretamente o processo de failover e recuperação. Para conectar uma réplica externa a um cluster do ElastiCache, verifique se o multi-AZ não está habilitado antes de fazer a conexão.
# Como a sincronização e o backup são implementados
Todas as versões com suporte do Valkey ou Redis OSS oferecem suporte para backup e sincronização entre os nós primário e de réplica. No entanto, a forma como o backup e a sincronização são implementados varia de acordo com a versão.
## Redis OSS versão 2.8.22 e posterior
Para a replicação Redis OSS, nas versões 2.8.22 e posteriores, escolha um dos dois métodos de backup. Para obter mais informações, consulte [Versões do Redis OSS anteriores a 2.8.22](#Replication.Redis.Earlier2-8-22) e [Snapshots e restauração](backups.md).
Durante o processo sem permissão, se as cargas de gravação forem pesadas, as gravações no cluster serão atrasadas para garantir que você não acumule muitas mudanças e, assim, evite um snapshot bem-sucedido.
## Versões do Redis OSS anteriores a 2.8.22
O backup e a sincronização do Redis OSS nas versões anteriores a 2.8.22 é um processo de três etapas.
1. A bifurcação e, no processo em segundo plano, serializam os dados do cluster no disco. Isso cria um snapshot de ponto no tempo.
1. Em primeiro plano, acumule um log de alterações no *buffer de saída do cliente*.
**Importante**
Se o log de alterações exceder o tamanho do *buffer de saída do cliente*, o backup ou a sincronização falhará. Para obter mais informações, consulte [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md).
1. Por fim, transmita os dados do cache e, em seguida, o log de alterações para o nó de réplica.
# Criação de um grupo de replicação do Valkey ou Redis OSS
Você tem as seguintes opções para criar um cluster com nós de réplica. Uma delas se aplica quando você já tem um cluster do Valkey ou Redis OSS (modo cluster desabilitado) disponível não associado a nenhum cluster que possua réplicas a serem usadas como o nó primário. A outra é aplicada quando você precisa criar um nó primário com o cluster e as réplicas de leitura. Atualmente, um cluster do Valkey ou Redis OSS (modo cluster habilitado) deve ser criado do zero.
**Opção 1 1: [Criação de um grupo de replicação usando um cluster existente](Replication.CreatingReplGroup.ExistingCluster.md)**
Use essa opção para aproveitar um cluster de nó único já existente do Valkey ou Redis OSS (modo cluster desabilitado). Você especifica esse nó existente como o nó primário no novo cluster e, em seguida, adiciona individualmente de 1 a 5 réplicas de leitura ao cluster. Se o cluster existente estiver ativo, as réplicas de leitura serão sincronizadas com ele enquanto forem criadas. Consulte [Criação de um grupo de replicação usando um cluster existente](Replication.CreatingReplGroup.ExistingCluster.md).
Não é possível criar um cluster do Valkey ou Redis OSS (modo cluster habilitado) usando um cluster existente. Para criar um cluster do Valkey ou Redis OSS (modo cluster habilitado) (API/CLI: grupo de replicação) usando o console do ElastiCache, consulte [Criação de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster).
**Opção 2 2: [Criação de um grupo de replicação do Valkey ou Redis OSS do início](Replication.CreatingReplGroup.NoExistingCluster.md)**
Use essa opção se você ainda não tiver um cluster do Valkey ou Redis OSS (modo cluster desabilitado) disponível a ser usado como nó primário do cluster, ou se quiser criar um cluster do Valkey ou Redis OSS (modo cluster habilitado). Consulte [Criação de um grupo de replicação do Valkey ou Redis OSS do início](Replication.CreatingReplGroup.NoExistingCluster.md).
# Criação de um grupo de replicação usando um cluster existente
O procedimento a seguir adiciona um grupo de replicação ao cluster de nó único do Valkey ou Redis OSS (modo cluster desabilitado). Ele é necessário para atualizar seu cluster para a versão mais recente do Valkey. Esse é um procedimento local que envolve zero tempo de inatividade e zero perda de dados. Quando você cria um grupo de replicação para seu cluster de nó único, o nó do cluster se torna o nó primário no novo cluster. Se você não tiver um cluster do Valkey ou Redis OSS (modo cluster desabilitado) que possa usar como primário do novo cluster, consulte [Criação de um grupo de replicação do Valkey ou Redis OSS do início](Replication.CreatingReplGroup.NoExistingCluster.md).
Um cluster disponível é um cluster do Valkey ou Redis OSS existente de um único nó. Atualmente, o Valkey ou o Redis OSS (modo cluster habilitado) não oferecem suporte para criar um cluster com réplicas usando um cluster de um único nó disponível. Se você quiser criar um cluster do Valkey ou Redis OSS (modo cluster habilitado), consulte [Criação de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON).
## Criação de um grupo de replicação usando um cluster existente (console)
Consulte o tópico [Usando o ElastiCache Console de gerenciamento da AWS](Clusters.AddNode.md#Clusters.AddNode.CON).
## Criação de um grupo de replicação usando um cluster do Valkey ou Redis OSS disponível (AWS CLI)
Existem duas etapas para criar um grupo de replicação com réplicas de leitura ao usar um cluster de cache do Valkey ou Redis OSS disponível para o primário ao usar a AWS CLI.
Ao usar o,AWS CLI você cria um grupo de replicação especificando o nó autônomo disponível como o nó principal do cluster `--primary-cluster-id` e o número de nós que você deseja no cluster usando o comando CLI,. `create-replication-group` Inclua os seguintes parâmetros.
**--replication-group-id**
O nome do grupo de replicação que você está criando. O valor desse parâmetro é usado como a base para os nomes dos nós adicionados com um número sequencial de 3 dígitos acrescentados ao final de `--replication-group-id`. Por exemplo, .`sample-repl-group-001`
As restrições de nomenclatura do grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
**--replication-group-description**
Descrição do grupo de replicação.
**--num-node-groups**
O número de nós desejados neste cluster. Esse valor inclui o nó primário. Esse parâmetro tem um valor máximo de seis.
**--primary-cluster-id**
O nome do cluster do Valkey ou Redis OSS (modo cluster desabilitado) disponível que você deseja que seja o nó primário nesse grupo de replicação.
O comando a seguir cria o grupo de replicação `sample-repl-group` usando o cluster do Valkey ou Redis OSS (modo cluster desabilitado) disponível `redis01` como o nó primário do grupo de replicação. Ele cria 2 novos nós que são réplicas de leitura. As configurações de `redis01` (ou seja, grupo de parâmetros, grupo de segurança, tipo de nó, versão do mecanismo, etc.) serão aplicadas a todos os nós no grupo de replicações.
Para Linux, macOS ou 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
```
Para 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
```
Para obter informações e parâmetros adicionais que você talvez queira usar, consulte o AWS CLI tópico[create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html).
**Em seguida, adicione réplicas de leitura ao grupo de replicação**
Após a criação do grupo de replicação, adicione de uma a cinco réplicas de leitura usando o comando `create-cache-cluster`, certificando-se de incluir os seguintes parâmetros.
**--cache-cluster-id**
O nome do cluster que você está adicionando ao grupo de replicação.
As restrições de nomenclatura de cluster são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
**--replication-group-id**
O nome do grupo de replicação ao qual você está adicionando esse cluster.
Repita esse comando para cada réplica de leitura que você deseja adicionar ao grupo de replicação, alterando apenas o valor do parâmetro `--cache-cluster-id`.
**nota**
Lembre-se de que um grupo de replicação não pode ter mais de cinco réplicas de leitura. Se você tentar adicionar uma réplica de leitura a um grupo de replicação que já possui cinco réplicas de leitura, a operação falhará.
O código a seguir adiciona a réplica de leitura `my-replica01` ao grupo de replicação `sample-repl-group`. As configurações do cluster primário (grupo de parâmetros, grupo de segurança, tipo de nó etc.) serão aplicadas aos nós como foram adicionadas ao grupo de replicação.
Para Linux, macOS ou Unix:
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-replica01 \
--replication-group-id sample-repl-group
```
Para Windows:
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-replica01 ^
--replication-group-id sample-repl-group
```
A saída desse comando será semelhante a esta.
```
{
"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": {}
}
}
```
Para obter informações adicionais, consulte os AWS CLI tópicos:
+ [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)
## Adicionar réplicas a um cluster (API) autônomo Valkey ou Redis OSS (modo de cluster desativado) ElastiCache
Ao usar a ElastiCache API, você cria um grupo de replicação especificando o nó autônomo disponível como o nó principal do cluster `PrimaryClusterId` e o número de nós que você deseja no cluster usando o comando CLI,. `CreateReplicationGroup` Inclua os seguintes parâmetros.
**ReplicationGroupId**
O nome do grupo de replicação que você está criando. O valor desse parâmetro é usado como a base para os nomes dos nós adicionados com um número sequencial de 3 dígitos acrescentados ao final de `ReplicationGroupId`. Por exemplo, .`sample-repl-group-001`
As restrições de nomenclatura do grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
**ReplicationGroupDescription**
Descrição do cluster com réplicas.
**NumCacheClusters**
O número de nós desejados neste cluster. Esse valor inclui o nó primário. Esse parâmetro tem um valor máximo de seis.
**PrimaryClusterId**
O nome do cluster do Valkey ou Redis OSS (modo cluster desabilitado) disponível que você deseja que seja o nó primário nesse cluster.
O comando a seguir cria o cluster com réplicas `sample-repl-group` usando o cluster do Valkey ou Redis OSS (modo cluster desabilitado) disponível `redis01` como o nó primário do grupo de replicação. Ele cria 2 novos nós que são réplicas de leitura. As configurações de `redis01` (ou seja, grupo de parâmetros, grupo de segurança, tipo de nó, versão do mecanismo, etc.) serão aplicadas a todos os nós no grupo de replicações.
```
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=
```
Para obter informações adicionais, consulte os tópicos do ElastiCache APL:
+ [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html)
+ [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
**Em seguida, adicione réplicas de leitura ao grupo de replicação**
Após a criação do grupo de replicação, adicione de uma a cinco réplicas de leitura usando a operação `CreateCacheCluster`, certificando-se de incluir os seguintes parâmetros.
**CacheClusterId**
O nome do cluster que você está adicionando ao grupo de replicação.
As restrições de nomenclatura de cluster são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
**ReplicationGroupId**
O nome do grupo de replicação ao qual você está adicionando esse cluster.
Repita essa operação para cada réplica de leitura que você deseja adicionar ao grupo de replicação, alterando apenas o valor do parâmetro `CacheClusterId`.
O código a seguir adiciona a réplica de leitura `myReplica01` ao grupo de replicação `myReplGroup`. As configurações do cluster primário (grupo de parâmetros, grupo de segurança, tipo de nó etc.) serão aplicadas a nós conforme eles forem adicionados ao grupo de replicação.
```
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]
```
Para obter informações e parâmetros adicionais que você talvez queira usar, consulte o tópico ElastiCache da API[CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html).
# Criação de um grupo de replicação do Valkey ou Redis OSS do início
Veja a seguir como criar um grupo de replicação do Valkey ou Redis OSS sem usar um cluster do Valkey ou Redis OSS existente como primário. Você pode criar um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) ou do Valkey ou Redis OSS (modo cluster habilitado) do início usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache.
Antes de continuar, decida se deseja criar um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) ou do Valkey ou Redis OSS (modo cluster habilitado). Para obter orientação nessa decisão, consulte [Replicação: Modo de cluster Valkey e Redis OSS desativado versus ativado](Replication.Redis-RedisCluster.md).
**Topics**
+ [Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) do início](Replication.CreatingReplGroup.NoExistingCluster.Classic.md)
+ [Criação de um grupo de replicação no Valkey ou Redis OSS (modo cluster habilitado) do início](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md)
# Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) do início
Você pode criar um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) a partir do início usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache. Um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) sempre possui um grupo de nó, um cluster primário e até cinco réplicas de leitura. Os grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado) não são compatíveis com o particionamento dos seus dados.
**nota**
O limite de nó/fragmento pode ser aumentado para um máximo de 500 por cluster. Para solicitar um aumento de limite, consulte [Limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e inclua o tipo de instância na solicitação.
Para criar um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) do início, siga uma das seguintes abordagens:
## Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) do início (AWS CLI)
O procedimento a seguir cria um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) usando a AWS CLI.
Ao criar um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) do início, você cria o grupo de replicação e todos os seus nós com uma única chamada para o comando `create-replication-group` da AWS CLI. Inclua os seguintes parâmetros.
**--replication-group-id**
O nome do grupo de replicação que você está criando.
As restrições de nomenclatura do grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
**--replication-group-description**
Descrição do grupo de replicação.
**--num-cache-clusters**
O número de nós que você deseja criar com esse grupo de replicação, com réplicas primárias e de leitura combinadas.
Se você habilitar o Multi-AZ (`--automatic-failover-enabled`), o valor de `--num-cache-clusters` deverá ser pelo menos 2.
**--cache-node-type**
O tipo de nó para cada nó no grupo de replicação.
Os tipos de nó a seguir são compatíveis com o ElastiCache. Em linhas gerais, os tipos da geração atual fornecem mais memória e poder computacional a um custo mais baixo em comparação aos equivalentes das geração anteriores.
Para obter mais informações sobre detalhes de performance para cada tipo de nó, consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Defina esse parâmetro se estiver usando um tipo de nó r6gd. Se não quiser classificação de dados em níveis, defina `--no-data-tiering-enabled`. Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
**--cache-parameter-group**
Especifique um grupo de parâmetros que corresponda à versão do seu mecanismo. Se estiver executando o Redis OSS 3.2.4 ou posterior, especifique o grupo de parâmetros `default.redis3.2` ou um grupo de parâmetros de `default.redis3.2` para criar um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado). Para obter mais informações, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
**--network-type**
`ipv4`, `ipv6` ou `dual-stack`. Se você escolher pilha dupla, deverá definir o parâmetro `--IpDiscovery` como`ipv4` ou `ipv6`.
**--engine**
redis
**--engine-version**
Para ter o conjunto mais amplo de recursos, escolha a versão mais recente do mecanismo.
Os nomes dos nós serão derivados do nome do grupo de replicação depois de adicionar `-00`*\$1* ao nome do grupo de replicação. Por exemplo, usando o nome do grupo de replicação `myReplGroup`, o nome para o primário será `myReplGroup-001` e as réplicas de leitura `myReplGroup-002` e `myReplGroup-006`.
Se você quiser habilitar a criptografia em trânsito ou em repouso neste grupo de replicação, adicione um ou ambos os parâmetros `--transit-encryption-enabled` ou `--at-rest-encryption-enabled` e cumpra as seguintes condições.
+ Seu grupo de replicação deve estar executando o Redis OSS versão 3.2.6 ou 4.0.10.
+ O grupo de replicação precisa ser criado em uma Amazon VPC.
+ Você também deve incluir o parâmetro `--cache-subnet-group`.
+ Você também deve incluir o parâmetro `--auth-token` com o valor de string especificado pelo cliente para o token AUTH (senha) necessário para realizar operações neste grupo de replicação.
A seguinte operação cria um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) `sample-repl-group` com três nós, um primário e duas réplicas.
Para Linux, macOS ou 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
```
Para 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
```
A saída desse comando é semelhante a esta.
```
{
"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": {}
}
}
```
Para obter informações adicionais e parâmetros que você queira usar, consulte o tópico da AWS CLI [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html).
## Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) do início (API do ElastiCache)
O procedimento a seguir cria um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) usando a API do ElastiCache.
Ao criar um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) do início, você cria o grupo de replicação e todos os seus nós com uma única chamada para a operação `CreateReplicationGroup` da API do ElastiCache. Inclua os seguintes parâmetros.
**ReplicationGroupId**
O nome do grupo de replicação que você está criando.
As restrições de nomenclatura do grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
**ReplicationGroupDescription**
Sua descrição do grupo de replicação.
**NumCacheClusters**
O número total de nós que você deseja criar com esse grupo de replicação, com réplicas primárias e de leitura combinadas.
Se você habilitar o Multi-AZ (`AutomaticFailoverEnabled=true`), o valor de `NumCacheClusters` deverá ser pelo menos 2.
**CacheNodeType**
O tipo de nó para cada nó no grupo de replicação.
Os tipos de nó a seguir são compatíveis com o ElastiCache. Em linhas gerais, os tipos da geração atual fornecem mais memória e poder computacional a um custo mais baixo em comparação aos equivalentes das geração anteriores.
Para obter mais informações sobre detalhes de performance para cada tipo de nó, consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Defina esse parâmetro se estiver usando um tipo de nó r6gd. Se não quiser classificação de dados em níveis, defina `--no-data-tiering-enabled`. Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
**CacheParameterGroup**
Especifique um grupo de parâmetros que corresponda à versão do seu mecanismo. Se estiver executando o Redis OSS 3.2.4 ou posterior, especifique o grupo de parâmetros `default.redis3.2` ou um grupo de parâmetros de `default.redis3.2` para criar um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado). Para obter mais informações, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
**--network-type**
`ipv4`, `ipv` ou `dual-stack`. Se você escolher pilha dupla, deverá definir o parâmetro `--IpDiscovery` como `ipv4` ou `ipv6`.
**Mecanismo**
redis
**EngineVersion**
6.0
Os nomes dos nós serão derivados do nome do grupo de replicação depois de adicionar `-00`*\$1* ao nome do grupo de replicação. Por exemplo, usando o nome do grupo de replicação `myReplGroup`, o nome para o primário será `myReplGroup-001` e as réplicas de leitura `myReplGroup-002` e `myReplGroup-006`.
Se você quiser habilitar a criptografia em trânsito ou em repouso neste grupo de replicação, adicione um ou ambos os parâmetros `TransitEncryptionEnabled=true` ou `AtRestEncryptionEnabled=true` e cumpra as seguintes condições.
+ Seu grupo de replicação deve estar executando o Redis OSS versão 3.2.6 ou 4.0.10.
+ O grupo de replicação precisa ser criado em uma Amazon VPC.
+ Você também deve incluir o parâmetro `CacheSubnetGroup`.
+ Você também deve incluir o parâmetro `AuthToken` com o valor de string especificado pelo cliente para o token AUTH (senha) necessário para realizar operações neste grupo de replicação.
A seguinte operação cria o grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) `myReplGroup` com três nós, um primário e duas réplicas.
```
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=
```
Para obter informações adicionais e parâmetros que você queira usar, consulte o tópico sobre a API do ElastiCache [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html).
# Criação de um grupo de replicação no Valkey ou Redis OSS (modo cluster habilitado) do início
Você pode criar um cluster do Valkey ou Redis OSS (modo cluster habilitado) (API/CLI: *grupo de replicação*) usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache. Um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) tem de 1 a 500 fragmentos (API/CLI: grupos de nós), um nó primário em cada fragmento e até 5 réplicas de leitura em cada fragmento. É possível criar um cluster com alto número de fragmentos e baixo número de réplicas totalizando até 90 nós por cluster. Essa configuração do cluster pode variar de 90 fragmentos e 0 réplicas para 15 fragmentos e 5 réplicas, que é o número máximo de réplicas permitidas.
O limite de nó ou fragmento pode ser aumentado para um máximo de 500 por cluster se a versão do mecanismo Valkey ou Redis OSS for 5.0.6 ou posterior. Por exemplo, você pode optar por configurar um cluster de 500 nós que varia entre 83 fragmentos (uma primária e 5 réplicas por fragmento) e 500 fragmentos (primário único e sem réplicas). Verifique se existem endereços IP disponíveis suficientes para acomodar o aumento. As armadilhas comuns incluem as sub-redes no grupo de sub-redes têm um intervalo CIDR muito pequeno ou as sub-redes são compartilhadas e fortemente usadas por outros clusters. Para obter mais informações, consulte [Criação de um grupo de sub-redes](SubnetGroups.Creating.md).
Para versões abaixo de 5.0.6, o limite é 250 por cluster.
Para solicitar um aumento de limite, consulte [Limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e selecione o tipo de limite **Nodes per cluster per instance type** (Nós por cluster por tipo de instância).
**Topics**
+ [Uso do console do ElastiCache](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CON)
+ [Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) do início (AWS CLI)](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CLI)
+ [Criação de um grupo de replicação no Valkey ou Redis OSS (modo cluster habilitado) do início (API do ElastiCache)](#Replication.CreatingReplGroup.NoExistingCluster.Cluster.API)
## Criação de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)
Para criar um cluster do Valkey ou Redis OSS (modo cluster habilitado), consulte [Criação de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster). Certifique-se de habilitar o modo de cluster, **Cluster Mode enabled (Scale Out)**, e especifique pelo menos dois fragmentos e um nó de réplica em cada.
## Criação de um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) do início (AWS CLI)
O procedimento a seguir cria um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) usando a AWS CLI.
Ao criar um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) do início, você cria o grupo de replicação e todos os seus nós com uma única chamada para o comando `create-replication-group` da AWS CLI. Inclua os seguintes parâmetros.
**--replication-group-id**
O nome do grupo de replicação que você está criando.
As restrições de nomenclatura do grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
**--replication-group-description**
Descrição do grupo de replicação.
**--cache-node-type**
O tipo de nó para cada nó no grupo de replicação.
Os tipos de nó a seguir são compatíveis com o ElastiCache. Em linhas gerais, os tipos da geração atual fornecem mais memória e poder computacional a um custo mais baixo em comparação aos equivalentes das geração anteriores.
Para obter mais informações sobre detalhes de performance para cada tipo de nó, consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Defina esse parâmetro se estiver usando um tipo de nó r6gd. Se não quiser classificação de dados em níveis, defina `--no-data-tiering-enabled`. Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
**--cache-parameter-group**
Especifique o grupo de parâmetros `default.redis6.x.cluster.on` ou um grupo de parâmetros derivado de `default.redis6.x.cluster.on` para criar um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado). Para obter mais informações, consulte [Alterações de parâmetros do Redis OSS 6.x](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
**--engine**
redis
**--engine-version**
3.2.4
**--num-node-groups**
O número de grupos de nós neste grupo de replicação. Os valores válidos são 1 a 500.
O limite de nó/fragmento pode ser aumentado para um máximo de 500 por cluster. Para solicitar um aumento do limite, consulte [Limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) e selecione o tipo de limite "Nodes per cluster per instance type" (Nós por cluster por tipo de instância).
**--replicas-per-node-group**
O número de nós de réplica em cada grupo de nós. Os valores válidos são 0 a 5.
**--network-type**
`ipv4`, `ipv` ou `dual-stack`. Se você escolher pilha dupla, deverá definir o parâmetro `--IpDiscovery` como `ipv4` ou `ipv6`.
Se você quiser habilitar a criptografia em trânsito ou em repouso neste grupo de replicação, adicione um ou ambos os parâmetros `--transit-encryption-enabled` ou `--at-rest-encryption-enabled` e cumpra as seguintes condições.
+ Seu grupo de replicação deve estar executando o Redis OSS versão 3.2.6 ou 4.0.10.
+ O grupo de replicação precisa ser criado em uma Amazon VPC.
+ Você também deve incluir o parâmetro `--cache-subnet-group`.
+ Você também deve incluir o parâmetro `--auth-token` com o valor de string especificado pelo cliente para o token AUTH (senha) necessário para realizar operações neste grupo de replicação.
A seguinte operação cria o grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) `sample-repl-group` com três grupos de nós/fragmentos (--num-node-groups), cada um com três nós, uma réplica primária e duas réplicas de leitura (--replicas-per-node-group).
Para Linux, macOS ou 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>
```
Para 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>
```
O comando anterior gera a seguinte saída.
```
{
"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 você cria um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) do início, você pode configurar cada fragmento do cluster usando o parâmetro `--node-group-configuration`, como mostra o exemplo a seguir, que configura dois grupos de nós (console: fragmentos). O primeiro fragmento tem dois nós: um primário e uma réplica de leitura. O segundo fragmento tem três nós: um primário e duas réplicas de leitura.
**--node-group-configuration**
A configuração para cada grupo de nós. O parâmetro `--node-group-configuration` consiste nos seguintes campos.
+ `PrimaryAvailabilityZone`: a zona de disponibilidade onde o nó primário desse grupo de nós está localizado. Se esse parâmetro for omitido, o ElastiCache escolherá a zona de disponibilidade para o nó primário.
**Exemplo:** us-west-2a.
+ `ReplicaAvailabilityZones`: uma lista separada por vírgulas de zonas de disponibilidade em que as réplicas de leitura estão localizadas. O número de Zonas de disponibilidade nessa lista deve corresponder ao valor de `ReplicaCount`. Se esse parâmetro for omitido, o ElastiCache escolherá as zonas de disponibilidade para os nós de réplica.
**Exemplo:** "us-west-2a,us-west-2b,us-west-2c"
+ `ReplicaCount`: o número de nós de réplica nesse grupo de nós.
+ `Slots`: uma string que especifica o espaço de chaves para o grupo de nós. A string está no formato `startKey-endKey`. Se esse parâmetro for omitido, o ElastiCache alocará as chaves igualmente entre os grupos de nós.
**Exemplo:** "0-4999"
A operação a seguir cria o grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) `new-group` com dois grupos de nós/fragmentos (`--num-node-groups`). Ao contrário do exemplo anterior, cada grupo de nós está configurado de forma diferente do outro grupo de nós (`--node-group-configuration`).
Para Linux, macOS ou 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'"
```
Para 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'"
```
A operação anterior gera a seguinte saída.
```
{
"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": {}
}
}
```
Para obter informações adicionais e parâmetros que você queira usar, consulte o tópico sobre a AWS CLI [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html).
## Criação de um grupo de replicação no Valkey ou Redis OSS (modo cluster habilitado) do início (API do ElastiCache)
O procedimento a seguir cria um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) usando a API do ElastiCache.
Ao criar um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) do início, você cria o grupo de replicação e todos os seus nós com uma única chamada para a operação `CreateReplicationGroup` da API do ElastiCache. Inclua os seguintes parâmetros.
**ReplicationGroupId**
O nome do grupo de replicação que você está criando.
As restrições de nomenclatura do grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) são as seguintes:
+ Devem conter 1 a 40 caracteres alfanuméricos ou hifens.
+ Deve começar com uma letra.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
**ReplicationGroupDescription**
Descrição do grupo de replicação.
**NumNodeGroups**
O número de grupos de nós que você deseja criar com esse grupo de replicação. Os valores válidos são 1 a 500.
**ReplicasPerNodeGroup**
O número de nós de réplica em cada grupo de nós. Os valores válidos são 1 a 5.
**NodeGroupConfiguration**
A configuração para cada grupo de nós. O parâmetro `NodeGroupConfiguration` consiste nos seguintes campos.
+ `PrimaryAvailabilityZone`: a zona de disponibilidade onde o nó primário desse grupo de nós está localizado. Se esse parâmetro for omitido, o ElastiCache escolherá a zona de disponibilidade para o nó primário.
**Exemplo:** us-west-2a.
+ `ReplicaAvailabilityZones`: uma lista de zonas de disponibilidade em que as réplicas de leitura estão localizadas. O número de Zonas de disponibilidade nessa lista deve corresponder ao valor de `ReplicaCount`. Se esse parâmetro for omitido, o ElastiCache escolherá as zonas de disponibilidade para os nós de réplica.
+ `ReplicaCount`: o número de nós de réplica nesse grupo de nós.
+ `Slots`: uma string que especifica o espaço de chaves para o grupo de nós. A string está no formato `startKey-endKey`. Se esse parâmetro for omitido, o ElastiCache alocará as chaves igualmente entre os grupos de nós.
**Exemplo:** "0-4999"
**CacheNodeType**
O tipo de nó para cada nó no grupo de replicação.
Os tipos de nó a seguir são compatíveis com o ElastiCache. Em linhas gerais, os tipos da geração atual fornecem mais memória e poder computacional a um custo mais baixo em comparação aos equivalentes das geração anteriores.
Para obter mais informações sobre detalhes de performance para cada tipo de nó, consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
**--data-tiering-enabled**
Defina esse parâmetro se estiver usando um tipo de nó r6gd. Se não quiser classificação de dados em níveis, defina `--no-data-tiering-enabled`. Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
**CacheParameterGroup**
Especifique o grupo de parâmetros `default.redis6.x.cluster.on` ou um grupo de parâmetros derivado de `default.redis6.x.cluster.on` para criar um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado). Para obter mais informações, consulte [Alterações de parâmetros do Redis OSS 6.x](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
**--network-type**
`ipv4`, `ipv` ou `dual-stack`. Se você escolher pilha dupla, deverá definir o parâmetro `--IpDiscovery` como `ipv4` ou `ipv6`.
**Mecanismo**
redis
**EngineVersion**
6.0
Se você quiser habilitar a criptografia em trânsito ou em repouso neste grupo de replicação, adicione um ou ambos os parâmetros `TransitEncryptionEnabled=true` ou `AtRestEncryptionEnabled=true` e cumpra as seguintes condições.
+ Seu grupo de replicação deve estar executando o Redis OSS versão 3.2.6 ou 4.0.10.
+ O grupo de replicação precisa ser criado em uma Amazon VPC.
+ Você também deve incluir o parâmetro `CacheSubnetGroup`.
+ Você também deve incluir o parâmetro `AuthToken` com o valor de string especificado pelo cliente para o token AUTH (senha) necessário para realizar operações neste grupo de replicação.
As quebras de linha foram adicionadas para legibilidade.
```
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=
```
Para obter informações adicionais e parâmetros que você queira usar, consulte o tópico sobre a API do ElastiCache [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html).
# Visualização dos detalhes de um grupo de replicação
Há momentos em que você pode querer visualizar os detalhes de um grupo de replicação. Você pode usar o console do ElastiCache, a AWS CLI para o ElastiCache ou a API do ElastiCache. O processo do console é diferente para Valkey ou Redis OSS (modo cluster desabilitado) e Valkey ou Redis OSS (modo cluster habilitado).
**Contents**
+ [Visualização de um Valkey ou Redis OSS (modo cluster desabilitado) com réplicas](Replication.ViewDetails.Redis.md)
+ [Uso do console do ElastiCache](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CON)
+ [Como usar o AWS CLI](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.CLI)
+ [Uso da API do ElastiCache](Replication.ViewDetails.Redis.md#Replication.ViewDetails.Redis.API)
+ [Visualização de um grupo de replicação: Valkey ou Redis OSS (modo cluster habilitado)](Replication.ViewDetails.RedisCluster.md)
+ [Uso do console do ElastiCache](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CON)
+ [Como usar o AWS CLI](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.CLI)
+ [Uso da API do ElastiCache](Replication.ViewDetails.RedisCluster.md#Replication.ViewDetails.RedisCluster.API)
+ [Visualização dos detalhes de um grupo de replicação (AWS CLI)](Replication.ViewDetails.CLI.md)
+ [Visualização dos detalhes de um grupo de replicação (API do ElastiCache)](Replication.ViewDetails.API.md)
# Visualização de um Valkey ou Redis OSS (modo cluster desabilitado) com réplicas
Você pode visualizar os detalhes de um cluster do Valkey ou Redis OSS (modo cluster desabilitado) com réplicas (API/CLI: *grupo de replicação*) usando o console do ElastiCache, a AWS CLI para o ElastiCache ou a API do ElastiCache.
**Contents**
+ [Uso do console do ElastiCache](#Replication.ViewDetails.Redis.CON)
+ [Como usar o AWS CLI](#Replication.ViewDetails.Redis.CLI)
+ [Uso da API do ElastiCache](#Replication.ViewDetails.Redis.API)
## Visualização de detalhes de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) (console)
Para ver os detalhes de um cluster do Valkey ou Redis OSS (modo cluster desabilitado) com réplicas usando o console do ElastiCache, consulte o tópico [Visualização dos detalhes do Valkey ou Redis OSS (modo cluster desabilitado) (console)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.Redis).
## Visualização de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) (AWS CLI)
Para um exemplo de AWS CLI que exibe os detalhes de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado), consulte [Visualização dos detalhes de um grupo de replicação (AWS CLI)](Replication.ViewDetails.CLI.md).
## Visualização de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) (API do ElastiCache)
Para um exemplo da API do ElastiCache que exibe os detalhes de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado), consulte [Visualização dos detalhes de um grupo de replicação (API do ElastiCache)](Replication.ViewDetails.API.md).
# Visualização de um grupo de replicação: Valkey ou Redis OSS (modo cluster habilitado)
## Visualização de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)
Para ver os detalhes de um cluster do Valkey ou Redis OSS (modo cluster habilitado) usando o console do ElastiCache, consulte [Visualização de detalhes de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (console)](Clusters.ViewDetails.md#Clusters.ViewDetails.CON.RedisCluster).
## Visualização de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (AWS CLI)
Para um exemplo da CLI do ElastiCache que exibe os detalhes de um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado), consulte [Visualização dos detalhes de um grupo de replicação (AWS CLI)](Replication.ViewDetails.CLI.md).
## Visualização de um cluster do Valkey ou Redis OSS (modo cluster habilitado) (API do ElastiCache)
Para um exemplo da API do ElastiCache que exibe os detalhes de um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado), consulte [Visualização dos detalhes de um grupo de replicação (API do ElastiCache)](Replication.ViewDetails.API.md).
# Visualização dos detalhes de um grupo de replicação (AWS CLI)
É possível visualizar os detalhes de um grupo detalhes replicação usando o comando AWS CLI da `describe-replication-groups`. Use os seguintes parâmetros opcionais para refinar a listagem. A omissão dos parâmetros retorna os detalhes de até 100 grupos de replicação.
**Parâmetros opcionais**
+ `--replication-group-id`: use este parâmetro para listar os detalhes de um grupo de replicação específico. Se o grupo de replicação especificado tiver mais de um grupo de nós, os resultados serão retornados agrupados por grupo de nós.
+ `--max-items`: use este parâmetro para limitar o número de grupos de replicação listados. O valor de `--max-items` não pode ser inferior a 20 ou superior a 100.
**Example**
O código a seguir lista os detalhes para até 100 grupos de replicação.
```
aws elasticache describe-replication-groups
```
O código a seguir lista os detalhes para `sample-repl-group`.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
O código a seguir lista os detalhes para `sample-repl-group`.
```
aws elasticache describe-replication-groups --replication-group-id sample-repl-group
```
O código a seguir lista os detalhes para até 25 grupos de replicação.
```
aws elasticache describe-replication-groups --max-items 25
```
O resultado dessa operação deve ser semelhante a este (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
}
]
}
```
Para obter mais informações, consulte a AWS CLI para o tópico do ElastiCache [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html).
# Visualização dos detalhes de um grupo de replicação (API do ElastiCache)
Você pode visualizar os detalhes de uma replicação usando a operação AWS CLI `DescribeReplicationGroups`. Use os seguintes parâmetros opcionais para refinar a listagem. A omissão dos parâmetros retorna os detalhes de até 100 grupos de replicação.
**Parâmetros opcionais**
+ `ReplicationGroupId`: use este parâmetro para listar os detalhes de um grupo de replicação específico. Se o grupo de replicação especificado tiver mais de um grupo de nós, os resultados serão retornados agrupados por grupo de nós.
+ `MaxRecords`: use este parâmetro para limitar o número de grupos de replicação listados. O valor de `MaxRecords` não pode ser inferior a 20 ou superior a 100. O padrão é 100.
**Example**
O código a seguir lista os detalhes para até 100 grupos de replicação.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
O código a seguir lista os detalhes para `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=
```
O código a seguir lista os detalhes para até 25 clusters.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&MaxRecords=25
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte o tópico de referência da API do ElastiCache [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html).
# Localização de endpoints de grupo de replicação
Um aplicativo pode se conectar a qualquer nó em um grupo de replicação, desde que tenha o endpoint DNS e o número da porta desse nó. Dependendo de você estar executando um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) ou do Valkey ou Redis OSS (modo cluster habilitado), você estará interessado em diferentes endpoints.
**Valkey ou Redis OSS (modo cluster desabilitado)**
Os clusters Valkey ou Redis OSS (modo cluster desabilitado) com réplicas têm três tipos de endpoints: o *endpoint primário*, o *endpoint leitor* e os *endpoints de nó*. O endpoint primário é um nome DNS que sempre é resolvido para o nó primário no cluster. O endpoint primário é imune às alterações no seu cluster, como promover uma réplica de leitura para a função primária. Para atividades de gravação, recomendamos que suas aplicações se conectem ao endpoint primário.
Um endpoint de leitor divide uniformemente as conexões de entrada no endpoint entre todas as réplicas de leitura em um cluster do ElastiCache. Fatores adicionais, como quando o aplicativo cria as conexões ou como o aplicativo (re)usa as conexões determinarão a distribuição do tráfego. Os endpoints de leitor acompanham as alterações do cluster em tempo real à medida que réplicas são adicionadas ou removidas. Você pode colocar várias réplicas de leitura do seu cluster do ElastiCache para Redis OSS em diferentes zonas de disponibilidade da AWS (AZ) para garantir a alta disponibilidade dos endpoints leitores.
**nota**
Um endpoint leitor não é um balanceador de carga. É um registro DNS que vai resolver para um endereço IP de um dos nós de réplica em uma forma round robin.
Para atividades de leitura, os aplicativos também podem se conectar a qualquer nó no cluster. Ao contrário do endpoint primário, endpoints de nó são resolvidos para endpoints específicos. Se você fizer uma alteração no cluster, como adicionar ou excluir uma réplica, deverá atualizar os endpoints de nó no seu aplicativo.
**Valkey ou Redis OSS (modo cluster habilitado)**
Clusters do Valkey ou Redis OSS (modo cluster habilitado) com réplicas, como eles têm vários fragmentos (API/CLI: grupos de nós), o que significa que também possuem vários nós primários, possuem uma estrutura de endpoint diferente dos clusters do Valkey ou Redis OSS (modo cluster desabilitado). O Valkey ou Redis OSS (modo cluster habilitado) tem um *endpoint de configuração* que "conhece" todos os endpoints primários e de nó no cluster. Seu aplicativo conecta-se ao endpoint de configuração. Sempre que seu aplicativo grava ou lê no/do endpoint de configuração do cluster, o Valkey ou Redis OSS, nos bastidores, determina a qual fragmento a chave pertence e qual endpoint nesse fragmento deve ser usado. O processo é bastante transparente para o seu aplicativo.
Você pode localizar os endpoints de um cluster usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache.
**Localizar endpoints de grupo de replicação**
Para localizar os endpoints do seu grupo de replicação, consulte um dos seguintes tópicos:
+ [Localização de endpoints de um cluster do Valkey ou do Redis OSS (modo cluster desabilitado) (console)](Endpoints.md#Endpoints.Find.Redis)
+ [Localização de endpoints para um cluster do Valkey ou do Redis OSS (modo cluster habilitado) (console)](Endpoints.md#Endpoints.Find.RedisCluster)
+ [Localização de endpoints para grupos de replicação do Valkey ou Redis OSS (AWS CLI)](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Localização de endpoints para grupos de replicação do Valkey ou Redis OSS (API do ElastiCache)](Endpoints.md#Endpoints.Find.API.ReplGroups)
# Modificação de um grupo de replicação
**Restrições importantes**
Atualmente, ElastiCache oferece suporte a modificações limitadas de um grupo de replicação Valkey ou Redis OSS (modo de cluster ativado), por exemplo, alterando a versão do mecanismo usando a operação de API (`ModifyReplicationGroup`CLI:). `modify-replication-group` Você pode modificar o número de fragmentos (grupos de nós) em um cluster do Valkey ou Redis OSS (modo cluster habilitado) com a operação da 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)). Para obter mais informações, consulte [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md).
Outras modificações em um cluster do Valkey ou Redis OSS (modo cluster habilitado) exigem que você o crie novamente com o novo cluster que incorpore as alterações.
Você pode atualizar os clusters e grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado) e Valkey ou Redis OSS (modo cluster habilitado) para versões mais recentes do mecanismo. No entanto, você não pode fazer downgrade para versões anteriores do mecanismo, exceto excluindo o cluster existente ou grupo de replicação e criando-o novamente. Para obter mais informações, consulte [Gerenciamento de versões para ElastiCache](VersionManagement.md).
Você pode atualizar um cluster OSS existente ElastiCache para Valkey ou Redis que usa o modo de cluster desativado para usar o modo de cluster ativado, usando o console, a [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)API ou o comando [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)CLI, conforme mostrado no exemplo abaixo. Ou você pode seguir as etapas em [Modificar o modo de cluster](modify-cluster-mode.md).
Você pode modificar as configurações de um cluster Valkey ou Redis OSS (modo de cluster desativado) usando o ElastiCache console AWS CLI, o ou a API. ElastiCache Atualmente, ElastiCache oferece suporte a um número limitado de modificações em um grupo de replicação Valkey ou Redis OSS (modo de cluster ativado). Outras modificações exigem que você crie um backup do grupo de replicação e, em seguida, use esse backup para propagar um novo grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado).
**Topics**
+ [Usando o Console de gerenciamento da AWS](#Replication.Modify.CON)
+ [Usando o AWS CLI](#Replication.Modify.CLI)
+ [Usando a ElastiCache API](#Replication.Modify.API)
## Usando o Console de gerenciamento da AWS
Para modificar um cluster do Valkey ou Redis OSS (modo cluster desabilitado), consulte [Modificação de um cluster do ElastiCache](Clusters.Modify.md).
## Usando o AWS CLI
Veja a seguir AWS CLI exemplos do `modify-replication-group` comando. Você pode usar o mesmo comando para fazer outras modificações em um grupo de replicação.
**Ativar multi-AZ em um grupo de replicação do Valkey ou Redis OSS existente:**
Para Linux, macOS ou Unix:
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--multi-az-enabled = true
```
Para Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--multi-az-enabled
```
**Modifique o modo de cluster de desativado para ativado:**
Para modificar o modo de cluster de *desativado* para *ativado*, você deve primeiro definir o modo de cluster como *compatível*. O modo compatível permite que seus clientes Valkey ou Redis OSS se conectem usando o modo de cluster habilitado e o modo de cluster desabilitado. Depois de migrar todos os clientes Valkey ou Redis OSS para usar o modo cluster habilitado, você poderá concluir a configuração do modo cluster e definir o modo cluster como *Habilitado*.
Para Linux, macOS ou Unix:
Defina o modo de cluster como *compatível*.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cache-parameter-group-name myParameterGroupName \
--cluster-mode compatible
```
Defina o modo de cluster como *ativado*.
```
aws elasticache modify-replication-group \
--replication-group-id myReplGroup \
--cluster-mode enabled
```
Para Windows:
Defina o modo de cluster como *compatível*.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cache-parameter-group-name myParameterGroupName ^
--cluster-mode compatible
```
Defina o modo de cluster como *ativado*.
```
aws elasticache modify-replication-group ^
--replication-group-id myReplGroup ^
--cluster-mode enabled
```
Para obter mais informações sobre o AWS CLI `modify-replication-group` comando, consulte [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) ou [Modificando o modo de cluster]() no Guia do *ElastiCache usuário do Redis OSS.*
## Usando a ElastiCache API
A operação de ElastiCache API a seguir habilita o Multi-AZ em um grupo de replicação Valkey ou Redis OSS existente. Você pode usar a mesma operação para fazer outras modificações em um grupo de replicação.
```
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=
```
Para obter mais informações sobre a `ModifyReplicationGroup` operação ElastiCache da API, consulte[ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html).
# Exclusão de um grupo de replicação
Se você não precisar mais de um dos seus clusters com réplicas (chamados de *grupos de replicação* na API/CLI), poderá excluí-lo. Quando você exclui um grupo de replicação, o ElastiCache exclui todos os nós nesse grupo.
Depois de ter iniciado essa operação, ela não poderá ser interrompida ou cancelada.
**Atenção**
Ao excluir um cluster do ElastiCache for Redis OSS, seus snapshots manuais são retidos. Você também poderá criar um snapshot final antes da exclusão do cluster. Os snapshots de cache automáticos não são retidos.
É necessário ter a permissão `CreateSnapshot` para criar um snapshot final. Sem essa permissão, a chamada de API falhará com uma exceção `Access Denied`.
## Exclusão de um grupo de replicação (Console)
Para excluir um cluster que possui réplicas, consulte [Excluindo um cluster no ElastiCache](Clusters.Delete.md).
## Excluir um grupo de replicação (AWS CLI)
Use o comando [delete-replication-group](https://docs.aws.amazon.com/AmazonElastiCache/latest/CommandLineReference/CLIReference-cmd-DeleteReplicationGroup.html) para excluir um grupo de replicação.
```
aws elasticache delete-replication-group --replication-group-id my-repgroup
```
Um prompt solicita que você confirme sua decisão. Insira *y* (sim) para iniciar a operação imediatamente. Após o início do processo, ele é irreversível.
```
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
```
## Exclusão de um grupo de replicação (API do ElastiCache)
Chame [DeleteReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteReplicationGroup.html) com o parâmetro `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 você definir o parâmetro `RetainPrimaryCluster` como `true`, todas as réplicas de leitura serão excluídas, mas o cluster primário será mantido.
# Alteração do número de réplicas
Você pode aumentar ou diminuir dinamicamente o número de réplicas de leitura no grupo de replicação do Valkey ou Redis OSS usando o Console de gerenciamento da AWS, a AWS CLI ou a API do ElastiCache. Caso seu grupo de replicação seja um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado), você pode escolher de quais fragmentos (grupos de nós) aumentar ou diminuir o número de réplicas.
Para alterar dinamicamente o número de réplicas no grupo de replicação, escolha a operação na tabela a seguir que se adapte à situação.
| Para fazer isso | Para Valkey ou Redis OSS (modo cluster habilitado) | Para Valkey ou Redis OSS (modo cluster desabilitado) |
| --- | --- | --- |
| Adicionar réplicas | [Aumento do número de réplicas em um fragmento](increase-replica-count.md) | [Aumento do número de réplicas em um fragmento](increase-replica-count.md) [Adição de uma réplica de leitura do Valkey ou do Redis OSS (modo cluster desabilitado)](Replication.AddReadReplica.md) |
| Excluir réplicas | [Diminuição do número de réplicas em um fragmento](decrease-replica-count.md) | [Diminuição do número de réplicas em um fragmento](decrease-replica-count.md) [Exclusão de uma réplica de leitura do Valkey ou do Redis OSS (modo cluster desabilitado)](Replication.RemoveReadReplica.md) |
# Aumento do número de réplicas em um fragmento
Você pode aumentar o número de réplicas em um fragmento do Valkey ou Redis OSS (modo cluster habilitado) ou grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) até um máximo de cinco. Você pode fazer isso usando o Console de gerenciamento da AWS, a AWS CLI ou a API do ElastiCache.
**Topics**
+ [Utilização do Console de gerenciamento da AWS](#increase-replica-count-con)
+ [Como usar o AWS CLI](#increase-replica-count-cli)
+ [Uso da API do ElastiCache](#increase-replica-count-api)
## Utilização do Console de gerenciamento da AWS
O procedimento a seguir usa o console para aumentar o número de réplicas em um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado).
**Para aumentar o número de réplicas em fragmentos**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS** e o nome do grupo de replicação ao qual você deseja adicionar réplicas.
1. Escolha a caixa de cada estilhaço a que você deseja adicionar réplicas.
1. Escolha **Add replicas (Adicionar réplicas)**.
1. Conclua a página **Add Replicas to Shards (Adicionar réplicas a estilhaços)**:
+ Em **New number of replicas/shard (Novo número de réplicas/estilhaço)**, informe o número de réplicas que todos os estilhaços selecionados devem ter. Esse valor deve ser maior que ou igual a **Current Number of Replicas per shard (Número atual de réplicas por estilhaço)** e menor que ou igual a cinco. Recomendamos pelo menos duas réplicas para trabalho mínimo.
+ Em **Availability Zones** (Zonas de disponibilidade), escolha **No preference** (Sem preferência) para o ElastiCache escolher uma zona de disponibilidade para cada nova réplica, ou **Specify Availability Zones** (Especificar zonas de disponibilidade) a fim de escolher uma zona de disponibilidade para cada nova réplica.
Caso você escolha **Specify Availability Zones (Especificar zonas de disponibilidade)**, para cada nova réplica, especifique uma zona de disponibilidade usando a lista.
1. Escolha **Add (Adicionar)** a fim de adicionar as réplicas ou **Cancel (Cancelar)** a fim de cancelar a operação.
## Como usar o AWS CLI
Para aumentar o número de réplicas em um fragmento do Valkey ou Redis OSS, use o comando `increase-replica-count` com os seguintes parâmetros:
+ `--replication-group-id`: obrigatório. Identifica em qual grupo de replicação você deseja aumentar o número de réplicas.
+ `--apply-immediately` ou `--no-apply-immediately`: obrigatório. Especifica se é necessário aumentar a contagem de réplicas imediatamente (`--apply-immediately`) ou na próxima janela de manutenção (`--no-apply-immediately`). Atualmente, `--no-apply-immediately` não é suportado.
+ `--new-replica-count`: opcional. Especifica o número de nós de réplica que você deseja concluir, até um máximo de cinco. Use este parâmetro em grupos de replicação do Valkey ou do Redis OSS (modo cluster desabilitado) nos quais haja apenas um grupo de nós ou o grupo do Valkey ou do Redis OSS (modo cluster habilitado), ou onde você deseja que todos os grupos de nós tenham o mesmo número de réplicas. Caso esse valor não seja maior que o número atual de réplicas no grupo de nós, a chamada falha com uma exceção.
+ `--replica-configuration`: opcional. Permite definir o número de réplicas e as zonas de disponibilidade de cada grupo de nós independentemente. Use este parâmetro em grupos do Valkey ou Redis OSS (modo cluster habilitado) onde você deseja configurar cada grupo de nós independentemente.
`--replica-configuration` tem três membros opcionais:
+ `NodeGroupId`: o ID de quatro dígitos do grupo de nós que você está configurando. Para grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado), o ID de fragmento é sempre `0001`. Para encontrar o ID de um grupo de nós (fragmento) do Valkey ou Redis OSS (modo cluster habilitado), consulte [Localização de um ID de fragmento](Shards.md#shard-find-id).
+ `NewReplicaCount`: o número de réplicas que você deseja nesse grupo de nós ao final desta operação. O valor deve ser maior que o número atual de réplicas, até um máximo de cinco. Caso esse valor não seja maior que o número atual de réplicas no grupo de nós, a chamada falha com uma exceção.
+ `PreferredAvailabilityZones`: uma lista de strings de `PreferredAvailabilityZone` que especificam em quais zonas de disponibilidade os nós do grupo de replicação devem estar. O número de valores `PreferredAvailabilityZone` deve ser igual ao valor de `NewReplicaCount` mais 1 para contabilizar o nó primário. Caso esse membro de `--replica-configuration` seja omitido, o ElastiCache para Redis OSS escolherá a zona de disponibilidade para cada uma das novas réplicas.
**Importante**
Você deve incluir o parâmetro `--new-replica-count` ou `--replica-configuration`, mas não ambos, na chamada.
**Example**
O exemplo a seguir aumenta o número de réplicas no grupo de replicação `sample-repl-group` para três. Quando o exemplo é concluído, existem três réplicas em cada grupo de nós. Esse número se aplica caso este seja um grupo do Valkey ou Redis OSS (modo cluster desabilitado) com um grupo de nós único ou um grupo do Valkey ou Redis OSS (modo cluster habilitado) com vários grupos de nós.
Para Linux, macOS ou Unix:
```
aws elasticache increase-replica-count \
--replication-group-id sample-repl-group \
--new-replica-count 3 \
--apply-immediately
```
Para Windows:
```
aws elasticache increase-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 3 ^
--apply-immediately
```
O exemplo a seguir aumenta o número de réplicas no grupo de replicação `sample-repl-group` para o valor especificado para os dois grupos de nós especificados. Como há vários grupos de nós, este é um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado). Durante a especificação do `PreferredAvailabilityZones` opcional, o número de zonas de disponibilidade listadas deve ser igual ao valor de `NewReplicaCount` mais 1. Essa abordagem contabiliza o nó primário do grupo identificado por `NodeGroupId`.
Para Linux, macOS ou 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
```
Para 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
```
Para obter mais informações sobre como aumentar o número de réplicas usando a CLI, consulte [increase-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/increase-replica-count.html) na *Referência da linha de comando do Amazon ElastiCache*.
## Uso da API do ElastiCache
Para aumentar o número de réplicas em um fragmento do Valkey ou Redis OSS, use a ação `IncreaseReplicaCount` com os seguintes parâmetros:
+ `ReplicationGroupId`: obrigatório. Identifica em qual grupo de replicação você deseja aumentar o número de réplicas.
+ `ApplyImmediately`: obrigatório. Especifica se é necessário aumentar a contagem de réplicas imediatamente (`ApplyImmediately=True`) ou na próxima janela de manutenção (`ApplyImmediately=False`). Atualmente, `ApplyImmediately=False` não é suportado.
+ `NewReplicaCount`: opcional. Especifica o número de nós de réplica que você deseja concluir, até um máximo de cinco. Use este parâmetro em grupos de replicação do Valkey ou do Redis OSS (modo cluster desabilitado) nos quais haja apenas um grupo de nós, ou grupos do Valkey ou do Redis OSS (modo cluster habilitado) onde você deseja que todos os grupos de nós tenham o mesmo número de réplicas. Caso esse valor não seja maior que o número atual de réplicas no grupo de nós, a chamada falha com uma exceção.
+ `ReplicaConfiguration`: opcional. Permite definir o número de réplicas e as zonas de disponibilidade de cada grupo de nós independentemente. Use este parâmetro em grupos do Valkey ou Redis OSS (modo cluster habilitado) onde você deseja configurar cada grupo de nós independentemente.
`ReplicaConfiguraion` tem três membros opcionais:
+ `NodeGroupId`: o ID de quatro dígitos do grupo de nós que você está configurando. Para grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado), o ID do grupo de nós (fragmento) é sempre `0001`. Para encontrar o ID de um grupo de nós (fragmento) do Valkey ou Redis OSS (modo cluster habilitado), consulte [Localização de um ID de fragmento](Shards.md#shard-find-id).
+ `NewReplicaCount`: o número de réplicas que você deseja nesse grupo de nós ao final desta operação. O valor deve ser maior que o número atual de réplicas e um máximo de cinco. Caso esse valor não seja maior que o número atual de réplicas no grupo de nós, a chamada falha com uma exceção.
+ `PreferredAvailabilityZones`: uma lista de strings de `PreferredAvailabilityZone` que especificam em quais zonas de disponibilidade os nós do grupo de replicação devem estar. O número de valores `PreferredAvailabilityZone` deve ser igual ao valor de `NewReplicaCount` mais 1 para contabilizar o nó primário. Caso esse membro de `ReplicaConfiguration` seja omitido, o ElastiCache para Redis OSS escolherá a zona de disponibilidade para cada uma das novas réplicas.
**Importante**
Você deve incluir o parâmetro `NewReplicaCount` ou `ReplicaConfiguration`, mas não ambos, na chamada.
**Example**
O exemplo a seguir aumenta o número de réplicas no grupo de replicação `sample-repl-group` para três. Quando o exemplo é concluído, existem três réplicas em cada grupo de nós. Esse número se aplica caso este seja um grupo do Valkey ou Redis OSS (modo cluster desabilitado) com um grupo de nós único, ou um grupo do Valkey ou Redis OSS (modo cluster habilitado) com vários grupos de nós.
```
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=
```
O exemplo a seguir aumenta o número de réplicas no grupo de replicação `sample-repl-group` para o valor especificado para os dois grupos de nós especificados. Como há vários grupos de nós, este é um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado). Durante a especificação do `PreferredAvailabilityZones` opcional, o número de zonas de disponibilidade listadas deve ser igual ao valor de `NewReplicaCount` mais 1. Essa abordagem contabiliza o nó primário do grupo identificado por `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=
```
Para obter mais informações sobre como aumentar o número de réplicas usando a API, consulte [IncreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_IncreaseReplicaCount.html) na *Referência da API do Amazon ElastiCache*.
# Diminuição do número de réplicas em um fragmento
Você pode reduzir o número de réplicas em um fragmento do Valkey ou do Redis OSS (modo cluster habilitado) ou em um grupo de replicação do Valkey ou do Redis OSS (modo cluster desabilitado):
+ Para o Valkey ou Redis OSS (modo cluster desabilitado), é possível reduzir o número de réplicas para um, caso o multi-AZ esteja habilitado, e para zero, caso ele não esteja habilitado.
+ Para o Valkey ou Redis OSS (modo cluster habilitado), você pode diminuir o número de réplicas para zero. No entanto, você não pode fazer failover para uma réplica, caso o nó primário falhe.
Você pode usar o Console de gerenciamento da AWS, a AWS CLI ou a API do ElastiCache para reduzir o número de réplicas em um grupo de nós (fragmento) ou em um grupo de replicação.
**Topics**
+ [Utilização do Console de gerenciamento da AWS](#decrease-replica-count-con)
+ [Como usar o AWS CLI](#decrease-replica-count-cli)
+ [Uso da API do ElastiCache](#decrease-replica-count-api)
## Utilização do Console de gerenciamento da AWS
O procedimento a seguir usa o console para reduzir o número de réplicas em um grupo de replicação do Valkey ou do Redis OSS (modo cluster habilitado).
**Para diminuir o número de réplicas em um fragmento do Valkey ou Redis OSS**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey** ou **Redis OSS** e o nome do grupo de replicação do qual você deseja excluir réplicas.
1. Escolha a caixa de cada estilhaço de que você deseja excluir um nó de réplica.
1. Escolha **Delete replicas (Excluir réplicas)**.
1. Conclua a página **Delete Replicas from Shards (Excluir réplicas de estilhaços)**:
1. Em **New number of replicas/shard (Novo número de réplicas/estilhaço)**, informe o número de réplicas que os estilhaços selecionados devem ter. Esse número deve ser maior que ou igual a 1. Recomendamos pelo menos duas réplicas por estilhaço para trabalho mínimo.
1. Escolha **Delete (Excluir)** a fim de excluir as réplicas ou **Cancel (Cancelar)** a fim de cancelar a operação.
**Importante**
Caso você não especifique os nós de réplica a serem excluídos, o ElastiCache para Redis OSS selecionará automaticamente os nós de réplica para exclusão. Ao fazer isso, o ElastiCache para Redis OSS tenta manter a arquitetura multi-AZ do grupo de replicação seguido preservando réplicas com atraso de replicação mínimo em relação ao principal.
Não é possível excluir o primário ou os nós primários em um grupo de replicação. Se você especificar o nó primário para exclusão, a operação falhará com um evento de erro indicando que o nó primário foi selecionado para exclusão.
## Como usar o AWS CLI
Para diminuir o número de réplicas em um fragmento do Valkey ou Redis OSS, use o comando `decrease-replica-count` com os seguintes parâmetros:
+ `--replication-group-id`: obrigatório. Identifica em qual grupo de replicação você deseja diminuir o número de réplicas.
+ `--apply-immediately` ou `--no-apply-immediately`: obrigatório. Especifica se é necessário diminuir a contagem de réplicas imediatamente (`--apply-immediately`) ou na próxima janela de manutenção (`--no-apply-immediately`). Atualmente, `--no-apply-immediately` não é suportado.
+ `--new-replica-count`: opcional. Especifica o número de nós de réplica desejado. O valor de `--new-replica-count` deve ser um valor válido menos o número atual de réplicas nos grupos de nós. Para valores permitidos mínimos, consulte [Diminuição do número de réplicas em um fragmento](#decrease-replica-count). Caso o valor de `--new-replica-count` não atenda a esse requisito, a chama falha.
+ `--replicas-to-remove`: opcional. Contém uma lista de IDs de nó que especificam os nós de réplica a serem removidos.
+ `--replica-configuration`: opcional. Permite definir o número de réplicas e as zonas de disponibilidade de cada grupo de nós independentemente. Use este parâmetro em grupos do Valkey ou Redis OSS (modo cluster habilitado) onde você deseja configurar cada grupo de nós independentemente.
`--replica-configuration` tem três membros opcionais:
+ `NodeGroupId`: o ID de quatro dígitos do grupo de nós que você está configurando. Para grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado), o ID de fragmento é sempre `0001`. Para encontrar o ID de um grupo de nós (fragmento) do Valkey ou Redis OSS (modo cluster habilitado), consulte [Localização de um ID de fragmento](Shards.md#shard-find-id).
+ `NewReplicaCount`: um parâmetro opcional que especifica o número de nós de réplica desejado. O valor de `NewReplicaCount` deve ser um valor válido menos o número atual de réplicas nos grupos de nós. Para valores permitidos mínimos, consulte [Diminuição do número de réplicas em um fragmento](#decrease-replica-count). Caso o valor de `NewReplicaCount` não atenda a esse requisito, a chama falha.
+ `PreferredAvailabilityZones`: uma lista de strings de `PreferredAvailabilityZone` que especificam em quais zonas de disponibilidade os nós do grupo de replicação estão. O número de valores `PreferredAvailabilityZone` deve ser igual ao valor de `NewReplicaCount` mais 1 para contabilizar o nó primário. Caso esse membro de `--replica-configuration` seja omitido, o ElastiCache para Redis OSS escolherá a zona de disponibilidade para cada uma das novas réplicas.
**Importante**
Você deve incluir um, e somente um, parâmetro `--new-replica-count`, `--replicas-to-remove`, ou `--replica-configuration`.
**Example**
O exemplo a seguir usa `--new-replica-count` para diminuir o número de réplicas no grupo de replicação `sample-repl-group` para um. Quando o exemplo é concluído, existe uma réplica em cada grupo de nós. Esse número se aplica caso este seja um grupo do Valkey ou Redis OSS (modo cluster desabilitado) com um grupo de nós único ou um grupo do Valkey ou Redis OSS (modo cluster habilitado) com vários grupos de nós.
Para Linux, macOS ou Unix:
```
aws elasticache decrease-replica-count
--replication-group-id sample-repl-group \
--new-replica-count 1 \
--apply-immediately
```
Para Windows:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--new-replica-count 1 ^
--apply-immediately
```
O exemplo a seguir diminui o número de réplicas no grupo de replicação `sample-repl-group` removendo duas réplicas especificadas (`0001` e `0003`) do grupo de nós.
Para Linux, macOS ou Unix:
```
aws elasticache decrease-replica-count \
--replication-group-id sample-repl-group \
--replicas-to-remove 0001,0003 \
--apply-immediately
```
Para Windows:
```
aws elasticache decrease-replica-count ^
--replication-group-id sample-repl-group ^
--replicas-to-remove 0001,0003 \
--apply-immediately
```
O exemplo a seguir usa `--replica-configuration` a fim de diminuir o número de réplicas no grupo de replicação `sample-repl-group` para o valor especificado para os dois grupos de nós especificados. Como há vários grupos de nós, este é um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado). Durante a especificação do `PreferredAvailabilityZones` opcional, o número de zonas de disponibilidade listadas deve ser igual ao valor de `NewReplicaCount` mais 1. Essa abordagem contabiliza o nó primário do grupo identificado por `NodeGroupId`.
Para Linux, macOS ou 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
```
Para 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
```
Para obter mais informações sobre como reduzir o número de réplicas usando a CLI, consulte [decrease-replica-count](https://docs.aws.amazon.com/cli/latest/reference/elasticache/decrease-replica-count.html) na *Referência da linha de comando do Amazon ElastiCache*.
## Uso da API do ElastiCache
Para diminuir o número de réplicas em um fragmento do Valkey ou Redis OSS, use a ação `DecreaseReplicaCount` com os seguintes parâmetros:
+ `ReplicationGroupId`: obrigatório. Identifica em qual grupo de replicação você deseja diminuir o número de réplicas.
+ `ApplyImmediately`: obrigatório. Especifica se é necessário diminuir a contagem de réplicas imediatamente (`ApplyImmediately=True`) ou na próxima janela de manutenção (`ApplyImmediately=False`). Atualmente, `ApplyImmediately=False` não é suportado.
+ `NewReplicaCount`: opcional. Especifica o número de nós de réplica desejado. O valor de `NewReplicaCount` deve ser um valor válido menos o número atual de réplicas nos grupos de nós. Para valores permitidos mínimos, consulte [Diminuição do número de réplicas em um fragmento](#decrease-replica-count). Caso o valor de `--new-replica-count` não atenda a esse requisito, a chama falha.
+ `ReplicasToRemove`: opcional. Contém uma lista de IDs de nó que especificam os nós de réplica a serem removidos.
+ `ReplicaConfiguration`: opcional. Contém uma lista de grupos de nós que permite definir o número de réplicas e as zonas de disponibilidade de cada grupo de nós independentemente. Use este parâmetro em grupos do Valkey ou Redis OSS (modo cluster habilitado) onde você deseja configurar cada grupo de nós independentemente.
`ReplicaConfiguraion` tem três membros opcionais:
+ `NodeGroupId`: o ID de quatro dígitos do grupo de nós que você está configurando. Para grupos de replicação do Valkey ou do Redis OSS (modo cluster desabilitado), o ID do grupo de nós é sempre `0001`. Para encontrar o ID de um grupo de nós (fragmento) do Valkey ou Redis OSS (modo cluster habilitado), consulte [Localização de um ID de fragmento](Shards.md#shard-find-id).
+ `NewReplicaCount`: o número de réplicas que você deseja nesse grupo de nós ao final desta operação. O valor deve ser menor que o número atual de réplicas até um mínimo de 1, caso o Multi-AZ esteja habilitado ou 0 caso o Multi-AZ com failover automático não esteja habilitado. Caso esse valor não seja menor que o número atual de réplicas no grupo de nós, a chamada falha com uma exceção.
+ `PreferredAvailabilityZones`: uma lista de strings de `PreferredAvailabilityZone` que especificam em quais zonas de disponibilidade os nós do grupo de replicação estão. O número de valores `PreferredAvailabilityZone` deve ser igual ao valor de `NewReplicaCount` mais 1 para contabilizar o nó primário. Caso esse membro de `ReplicaConfiguration` seja omitido, o ElastiCache para Redis OSS escolherá a zona de disponibilidade para cada uma das novas réplicas.
**Importante**
Você deve incluir um, e somente um, parâmetro `NewReplicaCount`, `ReplicasToRemove`, ou `ReplicaConfiguration`.
**Example**
O exemplo a seguir usa `NewReplicaCount` para diminuir o número de réplicas no grupo de replicação `sample-repl-group` para um. Quando o exemplo é concluído, existe uma réplica em cada grupo de nós. Esse número se aplica caso este seja um grupo do Valkey ou Redis OSS (modo cluster desabilitado) com um grupo de nós único ou um grupo do Valkey ou Redis OSS (modo cluster habilitado) com vários grupos de nós.
```
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=
```
O exemplo a seguir diminui o número de réplicas no grupo de replicação `sample-repl-group` removendo duas réplicas especificadas (`0001` e `0003`) do grupo de nós.
```
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=
```
O exemplo a seguir usa `ReplicaConfiguration` a fim de diminuir o número de réplicas no grupo de replicação `sample-repl-group` para o valor especificado para os dois grupos de nós especificados. Como há vários grupos de nós, este é um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado). Durante a especificação do `PreferredAvailabilityZones` opcional, o número de zonas de disponibilidade listadas deve ser igual ao valor de `NewReplicaCount` mais 1. Essa abordagem contabiliza o nó primário do grupo identificado por `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=
```
Para obter mais informações sobre como reduzir o número de réplicas usando a API, consulte [DecreaseReplicaCount](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DecreaseReplicaCount.html) na *Referência da API do Amazon ElastiCache*.
# Adição de uma réplica de leitura do Valkey ou do Redis OSS (modo cluster desabilitado)
As informações no tópico a seguir só se aplicam a grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado).
À medida que seu tráfego de leitura aumentar, talvez você queira espalhar essas leituras em mais nós e reduzir a pressão de leitura em qualquer nó. Neste tópico, você pode descobrir como adicionar uma réplica de leitura a um cluster do Valkey ou Redis OSS (modo cluster desabilitado).
Um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) pode ter no máximo cinco réplicas de leitura. Se você tentar adicionar uma réplica de leitura a um grupo de replicação que já tenha cinco réplicas de leitura, a operação falhará.
Para obter informações sobre como adicionar réplicas a um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado), consulte o seguinte:
+ [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md)
+ [Aumento do número de réplicas em um fragmento](increase-replica-count.md)
Você pode adicionar uma réplica de leitura a um cluster do Valkey ou Redis OSS (modo cluster desabilitado) usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache.
**Tópicos relacionados**
+ [Adicionar nós a um ElastiCache cluster](Clusters.AddNode.md)
+ [Adição de uma réplica de leitura a um grupo de replicação (AWS CLI)](#Replication.AddReadReplica.CLI)
+ [Adição de uma réplica de leitura a um grupo de replicação usando a API](#Replication.AddReadReplica.API)
## Adição de uma réplica de leitura a um grupo de replicação (AWS CLI)
Para adicionar uma réplica de leitura a um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado), use o comando `create-cache-cluster` da AWS CLI com o parâmetro `--replication-group-id` para especificar a qual grupo de replicação adicionar o cluster (nó).
O exemplo a seguir cria o cluster `my-read replica` e o adiciona ao grupo de replicação `my-replication-group`. Os tipos de nós, os grupos de parâmetros, os grupos de segurança, as janelas de manutenção e outras configurações da réplica de leitura são os mesmos dos outros nós em `my-replication-group`.
Para Linux, macOS ou Unix:
```
aws elasticache create-cache-cluster \
--cache-cluster-id my-read-replica \
--replication-group-id my-replication-group
```
Para Windows:
```
aws elasticache create-cache-cluster ^
--cache-cluster-id my-read-replica ^
--replication-group-id my-replication-group
```
Para obter mais informações sobre como adicionar uma réplica de leitura usando a CLI, consulte [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html) na *Referência da linha de comando do Amazon ElastiCache.*
## Adição de uma réplica de leitura a um grupo de replicação usando a API
Para adicionar uma réplica de leitura a um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado), use a operação `CreateCacheCluster` do ElastiCache com o parâmetro `ReplicationGroupId` para especificar a qual grupo de replicação adicionar o cluster (nó).
O exemplo a seguir cria o cluster `myReadReplica` e o adiciona ao grupo de replicação `myReplicationGroup`. Os tipos de nós, os grupos de parâmetros, os grupos de segurança, as janelas de manutenção e outras configurações da réplica de leitura são os mesmos dos outros nós `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=
```
Para obter mais informações sobre como adicionar uma réplica de leitura usando a API, consulte [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html) na *Referência da API do Amazon ElastiCache.*
# Exclusão de uma réplica de leitura do Valkey ou do Redis OSS (modo cluster desabilitado)
As informações no tópico a seguir só se aplicam a grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado).
À medida que o tráfego de leitura no seu grupo de replicação Valkey ou Redis OSS mudar, talvez você queira adicionar ou remover réplicas de leitura. Remover um nó de um grupo de replicação é o mesmo que simplesmente excluir um cluster, embora existam restrições:
+ Não é possível remover o primário de um grupo de replicação. Se quiser excluir o primário, você deverá fazer o seguinte:
1. Promover uma réplica de leitura para primário. Para obter mais informações sobre como promover uma réplica de leitura para primário, consulte [Promoção de uma réplica de leitura a primário, para grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado)](Replication.PromoteReplica.md).
1. Exclua o primário antigo. Para uma restrição nesse método, consulte o próximo ponto.
+ Se o recurso Multi-AZ estiver habilitado em um grupo de replicação, você não poderá remover a última réplica de leitura do grupo de replicação. Nesse caso, faça o seguinte:
1. Modifique o grupo de replicação desabilitando o Multi-AZ. Para obter mais informações, consulte [Modificação de um grupo de replicação](Replication.Modify.md).
1. Exclua a réplica de leitura.
Você pode remover uma réplica de leitura de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) usando o console do ElastiCache, a AWS CLI para o ElastiCache ou a API do ElastiCache.
Para obter orientações sobre como excluir um cluster de um grupo de replicação Valkey ou Redis OSS, consulte o seguinte:
+ [Usando o Console de gerenciamento da AWS](Clusters.Delete.md#Clusters.Delete.CON)
+ [Usando o AWS CLI para excluir um ElastiCache cluster](Clusters.Delete.md#Clusters.Delete.CLI)
+ [Usando a ElastiCache API](Clusters.Delete.md#Clusters.Delete.API)
+ [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md)
+ [Diminuição do número de réplicas em um fragmento](decrease-replica-count.md)
# Promoção de uma réplica de leitura a primário, para grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado)
As informações no tópico a seguir só se aplicam a grupos de replicação do Valkey ou Redis OSS (modo cluster desabilitado).
Você pode promover uma réplica de leitura de um cluster do Valkey ou Redis OSS (modo cluster desabilitado) a primário usando o Console de gerenciamento da AWS, a AWS CLI ou a API do ElastiCache. Você não pode promover uma réplica de leitura para primária enquanto Multi-AZ com failover automático estiver habilitado no grupo de replicação . Para promover uma réplica do Valkey ou Redis OSS (modo cluster desabilitado) para primário em um grupo de replicação habilitado para multi-AZ, faça o seguinte:
1. Modifique o grupo de replicação para desabilitar Multi-AZ (isso não requer que todos os clusters estejam na mesma zona de disponibilidade). Para obter mais informações, consulte [Modificação de um grupo de replicação](Replication.Modify.md).
1. Promova a réplica de leitura para primário.
1. Modifique o grupo de replicação para reabilitar o Multi-AZ.
O Multi-AZ não está disponível em grupos de replicação que executam o Valkey ou Redis OSS 2.6.13 ou anterior.
## Utilização do Console de gerenciamento da AWS
O procedimento a seguir usa o console para promover um nó de réplica para primária.
**Para promover uma réplica de leitura para primário (console)**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Se a réplica que você quiser promover for membro de um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) em que o multi-AZ estiver habilitado, modifique o grupo de replicação para desabilitar o multi-AZ para continuar. Para obter mais informações, consulte [Modificação de um grupo de replicação](Replication.Modify.md).
1. Escolha **Valkey** ou **Redis OSS**, na lista de clusters, escolha o grupo de replicação que você deseja modificar. Esse grupo de replicação deve estar executando o mecanismo "Redis", e não o mecanismo "Clustered Redis", e deve ter dois ou mais nós.
1. Na lista de nós, escolha o nó de réplica que você deseja promover para primária, em **Actions (Ações)**, escolha **Promote (Promover)**.
1. Na caixa de diálogo **Promote Read Replica (Promover réplica de leitura)**, faça o seguinte:
1. Em **Apply Immediately (Aplicar imediatamente)**, escolha **Yes (Sim)** para promover a réplica de leitura imediatamente, ou **No (Não)** para promovê-la na próxima janela de manutenção do cluster.
1. Escolha **Promote** para promover a réplica de leitura ou **Cancel** para cancelar a operação.
1. Caso o cluster tenha Multi-AZ habilitado antes de você começar o processo de promoção, aguarde o status do grupo de replicação estar **available (disponível)**, modifique o cluster para reabilitar Multi-AZ. Para obter mais informações, consulte [Modificação de um grupo de replicação](Replication.Modify.md).
## Usar a AWS CLI
Você não pode promover uma réplica de leitura para primária caso o grupo de replicação esteja habilitado para Multi-AZ. Em alguns casos, a réplica que você deseja promover pode ser um membro de um grupo de replicação onde o recurso do Multi-AZ está habilitado. Nesses casos, você deve modificar o grupo de replicação para desabilitar o recurso do Multi-AZ antes de continuar. Isso não requer que todos os clusters estejam na mesma zona de disponibilidade. Para obter mais informações sobre como modificar um grupo de replicação, consulte [Modificação de um grupo de replicação](Replication.Modify.md).
O seguinte comando AWS CLI modifica o grupo de replicação `sample-repl-group`, tornando a réplica de leitura `my-replica-1` o primário no grupo de replicação.
Para Linux, macOS ou Unix:
```
aws elasticache modify-replication-group \
--replication-group-id sample-repl-group \
--primary-cluster-id my-replica-1
```
Para Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id sample-repl-group ^
--primary-cluster-id my-replica-1
```
Para obter mais informações sobre como modificar um grupo de replicação, consulte [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) na *Referência da linha de comando do Amazon ElastiCache.*
## Uso da API do ElastiCache
Você não pode promover uma réplica de leitura para primária caso o grupo de replicação esteja habilitado para Multi-AZ. Em alguns casos, a réplica que você deseja promover pode ser um membro de um grupo de replicação onde o recurso do Multi-AZ está habilitado. Nesses casos, você deve modificar o grupo de replicação para desabilitar o recurso do Multi-AZ antes de continuar. Isso não requer que todos os clusters estejam na mesma zona de disponibilidade. Para obter mais informações sobre como modificar um grupo de replicação, consulte [Modificação de um grupo de replicação](Replication.Modify.md).
A seguinte ação da API do ElastiCache modifica o grupo de replicação `myReplGroup`, tornando a réplica de leitura `myReplica-1` o primário no grupo de replicação.
```
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=
```
Para obter mais informações sobre como modificar um grupo de replicação, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) na *Referência da API do Amazon ElastiCache.*
# Gerenciamento de manutenção de cluster do ElastiCache
Cada cluster tem uma janela de manutenção semanal durante a qual todas as alterações do sistema são aplicadas. Com o Valkey e o Redis OSS, os grupos de replicação têm essa mesma janela de manutenção semanal. Se você não especificar uma janela de manutenção preferencial ao criar ou modificar um cluster ou grupo de replicação, o ElastiCache atribuirá uma janela de manutenção de 60 minutos dentro da janela de manutenção de sua região em um dia da semana escolhido aleatoriamente.
A janela de manutenção de 60 minutos é escolhida aleatoriamente entre um período de 8 horas por região. A tabela a seguir lista os blocos de tempo de cada região dos quais as janelas de manutenção padrão são atribuídas. Você pode escolher uma janela de manutenção preferida fora do bloco de janelas de manutenção da região.
| Código da região | Nome da Região | Janela de manutenção da região |
| --- | --- | --- |
| ap-northeast-1 | Região Ásia-Pacífico (Tóquio) | 13h às 21h (UTC) |
| ap-northeast-2 | Região Ásia-Pacífico (Seul) | 12h às 20h (UTC) |
| ap-northeast-3 | Região Ásia-Pacífico (Osaka) | 12h às 20h (UTC) |
| ap-southeast-3 | Região Ásia-Pacífico (Jacarta) | Das 14:00 às 22:00 (UTC) |
| ap-south-1 | Região Ásia-Pacífico (Mumbai) | 17h30 à 1h30 UTC |
| ap-southeast-1 | Região Ásia-Pacífico (Singapura) | Das 14:00 às 22:00 (UTC) |
| cn-north-1 | Região China (Pequim) | 14h às 22h (UTC) |
| cn-northwest-1 | Região China (Ningxia) | Das 14:00 às 22:00 (UTC) |
| ap-east-1 | Região Ásia-Pacífico (Hong Kong) | Das 13h às 21h (UTC) |
| ap-southeast-2 | Ásia-Pacífico (Sydney) | 12h às 20h (UTC) |
| eu-west-3 | Região Europa (Paris) | De 23:59 a 07:29 UTC |
| af-south-1 | Região África (Cidade do Cabo) | Das 13h às 21h (UTC) |
| eu-central-1 | Região Europa (Frankfurt) | 23h às 7h (UTC) |
| eu-west-1 | Região Europa (Irlanda) | 22h às 6h (UTC) |
| eu-west-2 | Região Europa (Londres) | 23h às 7h (UTC) |
| me-south-1 | Região Oriente Médio (Bahrein) | Das 13h às 21h (UTC) |
| me-central-1 | Região do Oriente Médio (Emirados Árabes Unidos) | Das 13h às 21h (UTC) |
| eu-south-1 | Região Europa (Milão) | Das 21:00 às 05:00 (UTC) |
| sa-east-1 | Região América do Sul (São Paulo) | 1h às 9h UTC |
| us-east-1 | Região Leste dos EUA (Norte da Virgínia) | 3h às 7h (UTC) |
| us-east-2 | Região Leste dos EUA (Ohio) | 5h às 12h UTC |
| us-gov-west-1 | AWS GovCloud (US) region | 6h às 14h (UTC) |
| us-west-1 | Região Oeste dos EUA (Norte da Califórnia) | 6h às 14h (UTC) |
| us-west-2 | Região Oeste dos EUA (Oregon) | 6h às 14h (UTC) |
**Como alterar a janela de manutenção do cluster ou grupo de replicação**
A janela de manutenção deve ser definida no horário de menor utilização e, portanto, talvez precise ser modificada de vez em quando. Você pode modificar o cluster ou grupo de replicação para especificar um intervalo de tempo de até 24 horas de duração durante o qual todas as atividades de manutenção solicitadas devem ocorrer. Todas as modificações de cluster diferidas ou pendentes que você tiver solicitado ocorrem durante esse período.
**nota**
Se você quiser aplicar modificações de tipo de nó e/ou atualizações de mecanismo imediatamente usando o Console de gerenciamento da AWS, selecione a caixa **Aplicar agora**. Do contrário, essas modificações serão aplicadas durante o próximo período de manutenção programada. Para usar a API, consulte [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) ou [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html).
**Mais informações**
Para obter informações sobre sua janela de manutenção e substituição de nó, consulte:
+ [Manutenção do ElastiCache](https://aws.amazon.com/elasticache/elasticache-maintenance/): perguntas frequentes sobre manutenção e substituição de nó
+ [Substituição de nós (Memcached)](CacheNodes.NodeReplacement-mc.md): gerenciamento de substituição de nó para o Memcached
+ [Modificação de um cluster do ElastiCache](Clusters.Modify.md): Alteração da janela de manutenção de um cluster
+ [Substituição de nós (Valkey e Redis OSS)](CacheNodes.NodeReplacement.md): Gerenciamento de substituição de nó
+ [Modificação de um grupo de replicação](Replication.Modify.md): Alteração da janela de manutenção de um grupo de replicação
# Configuração de parâmetros do mecanismo usando grupos de parâmetros do ElastiCache
O Amazon ElastiCache usa parâmetros para controlar as propriedades de tempo de execução de seus nós e clusters. Geralmente, as versões mais recentes do mecanismo incluem parâmetros adicionais para dar suporte à funcionalidade mais recente. Para tabelas de parâmetros do Memcached, consulte [Parâmetros específicos do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached). Para tabelas de parâmetros do Valkey e do Redis OSS, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
Como seria de se esperar, alguns valores de parâmetros, como `maxmemory`, são determinados pelo mecanismo e tipo de nó. Para acessar uma tabela desses valores de parâmetro do Memcached por tipo de nó, consulte [Parâmetros específicos do tipo de nó do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached.NodeSpecific). Para acessar uma tabela desses valores de parâmetros do Valkey e do Redis OSS por tipo de nó, consulte [Parâmetros específicos de node-type do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).
**nota**
Para obter uma lista de parâmetros específicos do Memcached, consulte [Parâmetros específicos de Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached).
**Topics**
+ [Gerenciamento de parâmetros no ElastiCache](ParameterGroups.Management.md)
+ [Camadas do grupo de parâmetros de cache no ElastiCache](ParameterGroups.Tiers.md)
+ [Criação de um grupo de parâmetros do ElastiCache](ParameterGroups.Creating.md)
+ [Listagem de grupos de parâmetros do ElastiCache por nome](ParameterGroups.ListingGroups.md)
+ [Listagem dos valores de um grupo de parâmetros do ElastiCache](ParameterGroups.ListingValues.md)
+ [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md)
+ [Exclusão de um grupo de parâmetros do ElastiCache](ParameterGroups.Deleting.md)
+ [Parâmetros específicos do mecanismo](ParameterGroups.Engine.md)
# Gerenciamento de parâmetros no ElastiCache
Os parâmetros do ElastiCache são agrupados em grupos de parâmetros nomeados para facilitar o gerenciamento de parâmetros. Um parameter group representa uma combinação de valores específicos para os parâmetros que são transmitidos ao software do mecanismo durante a inicialização. Esses valores determinam como o processo do mecanismo em cada nó se comportará em runtime. Os valores dos parâmetros em um parameter group específico aplicam-se a todos os nós associados ao grupo, independentemente do cluster ao qual eles pertencem.
Para ajustar o desempenho do cluster, você pode modificar alguns valores de parâmetros ou alterar o parameter group do cluster.
+ Não é possível modificar ou excluir os parameter groups padrão. Se você precisar de valores de parâmetros personalizados, deverá criar um parameter group personalizado.
+ Para o Memcached, a família do grupo de parâmetros e o cluster ao qual você a está atribuindo devem ser compatíveis. Por exemplo, se seu cluster estiver executando o Memcached versão 1.4.8, você só poderá usar parameter groups, padrão ou personalizados, da família Memcached 1.4.
Para o Redis OSS, a família do grupo de parâmetros e o cluster ao qual você a está atribuindo devem ser compatíveis. Por exemplo, se seu cluster estiver executando o Redis OSS versão 3.2.10, você só poderá usar grupos de parâmetros, padrão ou personalizados, da família Redis OSS 3.2.
+ Se você alterar o parameter group de um cluster, os valores de qualquer parâmetro modificável condicionalmente deverão ser os mesmos nos parameter groups atuais e novos.
+ Para o Memcached, quando você altera os parâmetros de um cluster, a alteração é aplicada ao cluster imediatamente. Isso é verdadeiro se você alterar o próprio grupo de parâmetro do cluster ou um valor do parâmetro dentro do grupo do parâmetro do cluster. Para determinar quando uma alteração de parâmetro específica é aplicada, consulte a coluna **As alterações terão efeito** nas tabelas para [Parâmetros específicos do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached). Para obter informações sobre como reinicializar nós de um cluster, consulte [Rebooting clusters](Clusters.html#Rebooting).
+ Para o Redis OSS, quando você altera parâmetros de um cluster, a alteração é aplicada no cluster imediatamente ou, com as exceções indicadas adiante, após os nós do cluster serem reinicializados. Isso é verdadeiro se você alterar o próprio grupo de parâmetro do cluster ou um valor do parâmetro dentro do grupo do parâmetro do cluster. Para determinar quando uma alteração de parâmetro específica é aplicada, consulte a coluna **As alterações terão efeito** nas tabelas para [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
Para obter mais informações sobre a reinicialização de nós do Valkey ou Redis OSS, consulte [Reinicialização de nós](nodes.rebooting.md).
**Alterações de parâmetro do Valkey ou Redis OSS (modo cluster habilitado)**
Se você fizer alterações nos parâmetros a seguir em um cluster do Valkey ou Redis OSS (modo cluster habilitado), siga as etapas a seguir.
activerehashing
bancos de dados
Crie um backup manual do seu cluster. Consulte [Realização de backups manuais](backups-manual.md).
Excluir o cluster. Consulte [Deleting clusters](Clusters.html#Delete).
Restaure o cluster usando o parameter group alterado e o backup para propagar o novo cluster. Consulte [Restauração de um backup para um novo cache](backups-restoring.md).
Alterações em outros parâmetros não exigem isso.
+ Você pode associar grupos de parâmetros a datastores globais do Valkey e do Redis OSS. Os *datastores globais* são uma coleção de um ou mais clusters que abrangem regiões da AWS. Nesse caso, o grupo de parâmetros é compartilhado por todos os clusters que compõem o datastore global. Quaisquer modificações no grupo de parâmetros do cluster primário são replicadas para todos os clusters restantes no datastore global. Para obter mais informações, consulte [Replicação entre AWS regiões usando datastores globais](Redis-Global-Datastore.md).
Você pode verificar se um grupo de parâmetros faz parte de um datastore global procurando nestes locais:
+ No console do ElastiCache, na página **Parameter Groups** (Grupos de parâmetros), o atributo **Global** yes/no (sim/não).
+ A propriedade `IsGlobal` yes/no (sim/não) da operação da API [CacheParameterGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CacheParameterGroup.html)
# Camadas do grupo de parâmetros de cache no ElastiCache
O Amazon ElastiCache tem três níveis de grupos de parâmetros de cache, como mostrado a seguir.
![\[Imagem: Camadas do grupo de parâmetros do Amazon ElastiCache\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-ParameterGroups-Tiers.png)
*Camadas do grupo de parâmetros do Amazon ElastiCache*
**Padrão global**
O grupo de parâmetros raiz de nível superior para todos os clientes do Amazon ElastiCache na região.
O parameter group de cache padrão global:
+ É reservado para o ElastiCache e não está disponível para o cliente.
**Padrão do cliente**
Uma cópia do parameter group de cache padrão global que é criado para uso do cliente.
O parameter group de cache padrão do cliente:
+ É criado e de propriedade do ElastiCache.
+ Está disponível ao cliente para ser usado como um parameter group de cache para quaisquer clusters executando uma versão do mecanismo com suporte por esse parameter group de cache.
+ Não pode ser editado pelo cliente.
**Propriedade do cliente**
Uma cópia do parameter group de cache padrão do cliente. Um parameter group de cache do cliente é criado sempre que o cliente cria um parameter group de cache.
O parameter group de cache do cliente mantido:
+ É criado e de propriedade do cliente.
+ Pode ser atribuído a qualquer um dos clusters compatíveis com o cliente.
+ Pode ser modificado pelo cliente para criar um parameter group de cache personalizado.
Nem todos os valores dos parâmetros podem ser modificados. Para obter mais informações sobre valores do Memcached, consulte [Parâmetros específicos do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached). Para obter mais informações sobre valores do Valkey e do Redis OSS, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
# Criação de um grupo de parâmetros do ElastiCache
Você precisará criar um novo parameter group se houver um ou mais valores de parâmetros que você deseja alterar a partir dos valores padrão. Você pode criar um grupo de parâmetros usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache.
## Criação de um grupo de parâmetros do ElastiCache (console)
O procedimento a seguir mostra como criar um grupo de parâmetros usando o console do ElastiCache.
**Para criar um grupo de parâmetros usando o console do ElastiCache**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Para ver uma lista de todos os parameter groups disponíveis, no painel de navegação à esquerda, escolha **Parameter Groups**.
1. Para criar um parameter group, escolha **Create Parameter Group**.
A tela **Create Parameter Group** (Criar grupo de parâmetros) será exibida.
1. Na lista **Family**, escolha a família de parameter groups que será o modelo para o seu parameter group.
A família de grupo de parâmetros, como *memcached1.4* ou *redis3.2*, define os parâmetros efetivos em seu grupo de parâmetros, além de seus valores iniciais. A família de parameter groups deve corresponder ao mecanismo e à versão do cluster.
1. Na caixa **Name**, digite um nome exclusivo para esse parameter group.
Ao criar um cluster ou modificar o parameter group de um cluster, você escolherá o parameter group pelo seu nome. Portanto, recomendamos que o nome seja informativo e de alguma forma identifique a família do parameter group.
As limitações de nomenclatura de grupo de parâmetros são as seguintes:
+ Deve começar com uma letra ASCII.
+ Pode conter apenas letras ASCII, dígitos e hífens.
+ Deve ter entre 1 e 255 caracteres.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
1. Na caixa **Description**, digite uma descrição para o parameter group.
1. Para criar o parameter group, escolha **Create**.
Para encerrar o processo sem criar o parameter group, escolha **Cancel**.
1. Quando o parameter group for criado, ele terá os valores padrão da família. Para alterar os valores padrão, você deve modificar o parameter group. Para obter mais informações, consulte [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md).
## Criação de um grupo de parâmetros do ElastiCache (AWS CLI)
Para criar um grupo de parâmetros usando a AWS CLI, use o comando `create-cache-parameter-group` com esses parâmetros.
+ `--cache-parameter-group-name`: O nome do grupo de parâmetros.
As limitações de nomenclatura de grupo de parâmetros são as seguintes:
+ Deve começar com uma letra ASCII.
+ Pode conter apenas letras ASCII, dígitos e hífens.
+ Deve ter entre 1 e 255 caracteres.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
+ `--cache-parameter-group-family`: o mecanismo e a família de versões para o grupo de parâmetros.
+ `--description`: uma descrição fornecida pelo usuário para o grupo de parâmetros.
**Example**
O exemplo a seguir cria um parameter group chamado *myMem14* usando a família memcached1.4 como modelo.
Para Linux, macOS ou Unix:
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myMem14 \
--cache-parameter-group-family memcached1.4 \
--description "My first parameter group"
```
Para Windows:
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myMem14 ^
--cache-parameter-group-family memcached1.4 ^
--description "My first parameter group"
```
A saída desse comando deve ser semelhante a esta.
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
}
```
**Example**
O exemplo a seguir cria um parameter group chamado *myRed28* usando a família redis2.8 como modelo.
Para Linux, macOS ou Unix:
```
aws elasticache create-cache-parameter-group \
--cache-parameter-group-name myRed28 \
--cache-parameter-group-family redis2.8 \
--description "My first parameter group"
```
Para Windows:
```
aws elasticache create-cache-parameter-group ^
--cache-parameter-group-name myRed28 ^
--cache-parameter-group-family redis2.8 ^
--description "My first parameter group"
```
A saída desse comando deve ser semelhante a esta.
```
{
"CacheParameterGroup": {
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
}
```
Quando o parameter group for criado, ele terá os valores padrão da família. Para alterar os valores padrão, você deve modificar o parameter group. Para obter mais informações, consulte [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md).
Para obter mais informações, consulte [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).
## Criação de um grupo de parâmetros do ElastiCache (API do ElastiCache)
Para criar um grupo de parâmetros usando a API do ElastiCache, use a ação `CreateCacheParameterGroup` com esses parâmetros.
+ `ParameterGroupName`: O nome do grupo de parâmetros.
As limitações de nomenclatura de grupo de parâmetros são as seguintes:
+ Deve começar com uma letra ASCII.
+ Pode conter apenas letras ASCII, dígitos e hífens.
+ Deve ter entre 1 e 255 caracteres.
+ Não podem conter dois hifens consecutivos.
+ Não podem terminar com um hífen.
+ `CacheParameterGroupFamily`: o mecanismo e a família de versões para o grupo de parâmetros. Por exemplo, `memcached1.4`.
+ `CacheParameterGroupFamily`: o mecanismo e a família de versões para o grupo de parâmetros. Por exemplo, `redis2.8`.
+ `Description`: uma descrição fornecida pelo usuário para o grupo de parâmetros.
**Example**
O exemplo a seguir cria um parameter group chamado *myMem14* usando a família memcached1.4 como modelo.
```
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=
```
A resposta dessa ação deve ser algo semelhante ao seguinte.
```
myMem14memcached1.4My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
**Example**
O exemplo a seguir cria um parameter group chamado *myRed28* usando a família redis2.8 como modelo.
```
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=
```
A resposta dessa ação deve ser algo semelhante ao seguinte.
```
myRed28redis2.8My first parameter groupd8465952-af48-11e0-8d36-859edca6f4b8
```
Quando o parameter group for criado, ele terá os valores padrão da família. Para alterar os valores padrão, você deve modificar o parameter group. Para obter mais informações, consulte [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md).
Para obter mais informações, consulte [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheParameterGroup.html).
# Listagem de grupos de parâmetros do ElastiCache por nome
Você pode listar os grupos de parâmetros usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache.
## Listagem de grupos de parâmetros por nome (console)
O procedimento a seguir mostra como visualizar uma lista dos grupos de parâmetros usando o console do ElastiCache.
**Para listar grupos de parâmetros usando o console do ElastiCache**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Para ver uma lista de todos os parameter groups disponíveis, no painel de navegação à esquerda, escolha **Parameter Groups**.
## Listagem de grupos de parâmetros do ElastiCache por nome (AWS CLI)
Para gerar uma lista de grupos de parâmetros usando a AWS CLI, use o comando `describe-cache-parameter-groups`. Se você fornecer um nome de parameter group, somente esse parameter group será listado. Se você não fornecer o nome de um parameter group, até `--max-records` parameter groups serão listados. Em ambos os casos, o nome, a família e a descrição do parameter group estão listados.
**Example**
O código de exemplo a seguir lista o parameter group *myMem14*.
Para Linux, macOS ou Unix:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myMem14
```
Para Windows:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myMem14
```
A saída desse comando será algo assim, listando o nome, a família e a descrição do parameter group.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myMem14",
"CacheParameterGroupFamily": "memcached1.4",
"Description": "My first parameter group"
}
]
}
```
**Example**
O código de exemplo a seguir lista o parameter group *myRed28*.
Para Linux, macOS ou Unix:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed28
```
Para Windows:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed28
```
A saída desse comando será algo assim, listando o nome, a família e a descrição do parameter group.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed28",
"CacheParameterGroupFamily": "redis2.8",
"Description": "My first parameter group"
}
]
}
```
**Example**
O código de exemplo a seguir lista o grupo de parâmetros *myRed56* para grupos de parâmetros em execução no mecanismo Redis OSS versão 5.0.6 e posteriores. Se o grupo de parâmetros fizer parte de um [Replicação entre AWS regiões usando datastores globais](Redis-Global-Datastore.md), o valor da propriedade `IsGlobal` retornado na saída será `Yes`.
Para Linux, macOS ou Unix:
```
aws elasticache describe-cache-parameter-groups \
--cache-parameter-group-name myRed56
```
Para Windows:
```
aws elasticache describe-cache-parameter-groups ^
--cache-parameter-group-name myRed56
```
A saída desse comando será algo semelhante ao seguinte: listagem de nome, família, isGlobal e descrição do grupo de parâmetros.
```
{
"CacheParameterGroups": [
{
"CacheParameterGroupName": "myRed56",
"CacheParameterGroupFamily": "redis5.0",
"Description": "My first parameter group",
"IsGlobal": "yes"
}
]
}
```
**Example**
O código de exemplo a seguir lista até 10 parameter groups.
```
aws elasticache describe-cache-parameter-groups --max-records 10
```
A saída JSON desse comando será algo semelhante ao seguinte, listagem de nome, família, descrição e, no caso do redis5.6, se o grupo de parâmetros faz parte de um datastore global (isGlobal), para cada grupo de parâmetros.
```
{
"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"
},
]
}
```
Para obter mais informações, consulte [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).
## Listagem de grupos de parâmetros do ElastiCache por nome (API do ElastiCache)
Para gerar uma lista de grupos de parâmetros usando a API do ElastiCache, use a ação `DescribeCacheParameterGroups`. Se você fornecer um nome de parameter group, somente esse parameter group será listado. Se você não fornecer o nome de um parameter group, até `MaxRecords` parameter groups serão listados. Em ambos os casos, o nome, a família e a descrição do parameter group estão listados.
**Example**
O código de exemplo a seguir lista o parameter group *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=
```
A resposta dessa ação parecerá algo semelhante ao seguinte, listando o nome, a família e a descrição de cada parameter group.
```
myMem14memcached1.4My custom Memcached 1.4 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
O código de exemplo a seguir lista até 10 parameter groups.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheParameterGroups
&MaxRecords=10
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&Version=2015-02-02
&X-Amz-Credential=
```
A resposta dessa ação será semelhante ao seguinte, listagem do nome, família, descrição e, no caso do redis5.6, se o grupo de parâmetros pertence a um datastore (isGlobal), para cada grupo de parâmetros.
```
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**
O código de exemplo a seguir lista o parameter group *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=
```
A resposta dessa ação será semelhante ao seguinte: listagem do nome, família e descrição.
```
myRed28redis2.8My custom Redis 2.8 parameter group3540cc3d-af48-11e0-97f9-279771c4477e
```
**Example**
O código de exemplo a seguir lista o grupo de parâmetros *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=
```
A resposta desta ação será semelhante ao seguinte, listagem do nome, família, descrição e se o grupo de parâmetros faz parte de um datastore global (isGlobal).
```
myRed56redis5.0My custom Redis 5.6 parameter groupyes3540cc3d-af48-11e0-97f9-279771c4477e
```
Para obter mais informações, consulte [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameterGroups.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameterGroups.html).
# Listagem dos valores de um grupo de parâmetros do ElastiCache
Você pode listar os parâmetros e seus valores para um grupo de parâmetros usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache.
## Listagem dos valores de um grupo de parâmetros do ElastiCache (console)
O procedimento a seguir mostra como listar os parâmetros e seus valores para um grupo de parâmetros usando o console do ElastiCache.
**Para listar os parâmetros de um grupo e seus valores usando o console do ElastiCache**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Para ver uma lista de todos os parameter groups disponíveis, no painel de navegação à esquerda, escolha **Parameter Groups**.
1. Escolha o parameter group para o qual você deseja listar os parâmetros e os valores, escolhendo a caixa à esquerda do nome do parameter group.
Os parâmetros e seus valores serão listados na parte inferior da tela. Devido ao número de parâmetros, talvez seja necessário rolar para cima e para baixo para encontrar o parâmetro de interesse.
## Listagem dos valores de um grupo de parâmetros (AWS CLI)
Para listar os parâmetros de um grupo de parâmetros e seus valores usando a AWS CLI, use o comando `describe-cache-parameters`.
**Example**
O código de exemplo a seguir lista todos os parâmetros do Memcached e seus valores para o grupo de parâmetros *myMem14*.
Para Linux, macOS ou Unix:
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myMem14
```
Para Windows:
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myMem14
```
**Example**
O código de exemplo a seguir lista todos os parâmetros e seus valores para o parameter group *myRedis28*.
Para Linux, macOS ou Unix:
```
aws elasticache describe-cache-parameters \
--cache-parameter-group-name myRedis28
```
Para Windows:
```
aws elasticache describe-cache-parameters ^
--cache-parameter-group-name myRed28
```
Para obter mais informações, consulte [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).
## Listagem dos valores de um grupo de parâmetros (API do ElastiCache)
Para listar os parâmetros de um grupo de parâmetros e seus valores usando a API do ElastiCache, use a ação `DescribeCacheParameters`.
**Example**
O código de exemplo a seguir lista todos os parâmetros do Memcached para o grupo de parâmetros *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=
```
A resposta dessa ação será semelhante a esta. Essa resposta foi truncada.
```
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**
O código de exemplo a seguir lista todos os parâmetros para o parameter group *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=
```
A resposta dessa ação será semelhante a esta. Essa resposta foi truncada.
```
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
```
Para obter mais informações, consulte [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameters.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheParameters.html).
# Modificação de um grupo de parâmetros do ElastiCache
**Importante**
Não é possível modificar um parameter group padrão.
Você pode modificar alguns valores de parâmetros em um parameter group. Esses valores de parâmetros são aplicados a clusters associados ao parameter group. Para obter mais informações sobre quando uma mudança no valor do parâmetro é aplicada a um parameter group, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis) e [Parâmetros específicos do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached).
## Modificação de um grupo de parâmetros (console)
O procedimento a seguir mostra como alterar o valor do parâmetro `cluster-enabled` usando o console do ElastiCache. Você usaria o mesmo procedimento para alterar o valor de qualquer parâmetro.
**Para alterar o valor de um parâmetro usando o console do ElastiCache**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Para ver uma lista de todos os parameter groups disponíveis, no painel de navegação à esquerda, escolha **Parameter Groups**.
1. Escolha o parameter group que você deseja modificar, marcando a caixa à esquerda do nome do parameter group.
Os parâmetros do parameter group serão listados na parte inferior da tela. Talvez você precise paginar pela lista para ver todos os parâmetros.
1. Para modificar um ou mais parâmetros, escolha **Edit Parameters**.
1. Na tela **Edit Parameter Group:**, percorra usando as setas esquerda e direita até encontrar o parâmetro `binding_protocol`. Em seguida, digite `ascii` na coluna **Value**.
1. Escolha **Salvar alterações**.
1. Para o Memcached, para localizar o nome do parâmetro que você alterou, consulte [Parâmetros específicos do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached). Se alterações no parâmetro ocorrerem depois da reinicialização (*After restart*), reinicialize todos os clusters que usam esse parameter group. Para obter mais informações, consulte [Rebooting clusters](Clusters.html#Rebooting).
1. Com Valkey e Redis OSS, para localizar o nome do parâmetro que você alterou, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis). Se você tiver um cluster do Valkey ou Redis OSS (modo cluster desabilitado) e fizer alterações nos parâmetros a seguir, é preciso reinicializar os nós no cluster:
+ activerehashing
+ bancos de dados
Para obter mais informações, consulte [Reinicialização de nós](nodes.rebooting.md).
**Alterações de parâmetro do Valkey ou Redis OSS (modo cluster habilitado)**
Se você fizer alterações nos parâmetros a seguir em um cluster do Valkey ou Redis OSS (modo cluster habilitado), siga as etapas a seguir.
activerehashing
bancos de dados
Com o Redis OSS, você pode criar um backup manual do cluster. Consulte [Realização de backups manuais](backups-manual.md).
Excluir o cluster. Consulte [Deleting clusters](Clusters.html#Delete).
Restaure o cluster usando o parameter group alterado e o backup para propagar o novo cluster. Consulte [Restauração de um backup para um novo cache](backups-restoring.md).
Alterações em outros parâmetros não exigem isso.
## Modificação de um grupo de parâmetros (AWS CLI)
Para alterar o valor de um parâmetro usando a AWS CLI, use o comando `modify-cache-parameter-group`.
**Example**
Com o Memcached, para localizar o nome e os valores permitidos do parâmetro que você deseja alterar, consulte [Parâmetros específicos do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached)
O código de exemplo a seguir define o valor de dois parâmetros, *chunk\$1size* e *chunk\$1size\$1growth\$1fact* no parameter group `myMem14`.
Para Linux, macOS ou 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
```
Para 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
```
A saída desse comando será semelhante a esta.
```
{
"CacheParameterGroupName": "myMem14"
}
```
**Example**
Com o Valkey e Redis OSS, para localizar o nome e os valores permitidos do parâmetro que você deseja alterar, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
O código de exemplo a seguir define o valor de dois parâmetros, *reserved-memory-percent* e *cluster-enabled* no parameter group `myredis32-on-30`. Definimos *reserved-memory-percent* como `30` (30%) e *cluster-enabled* como `yes` para que o grupo de parâmetros possa ser usado com clusters do Valkey ou Redis OSS (modo cluster habilitado) (grupos de replicação).
Para Linux, macOS ou 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
```
Para 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
```
A saída desse comando será semelhante a esta.
```
{
"CacheParameterGroupName": "my-redis32-on-30"
}
```
Para obter mais informações, consulte [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).
Para localizar o parâmetro que você alterou, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).
Se você tiver um cluster do Valkey ou Redis OSS (modo cluster desabilitado) e fizer alterações nos parâmetros a seguir, é preciso reinicializar os nós no cluster:
+ activerehashing
+ bancos de dados
Para obter mais informações, consulte [Reinicialização de nós](nodes.rebooting.md).
**Alterações de parâmetro do Valkey ou Redis OSS (modo cluster habilitado)**
Se você fizer alterações nos parâmetros a seguir em um cluster do Valkey ou Redis OSS (modo cluster habilitado), siga as etapas a seguir.
activerehashing
bancos de dados
Crie um backup manual do seu cluster. Consulte [Realização de backups manuais](backups-manual.md).
Excluir o cluster. Consulte [Deleting clusters](Clusters.html#Delete).
Restaure o cluster usando o parameter group alterado e o backup para propagar o novo cluster. Consulte [Restauração de um backup para um novo cache](backups-restoring.md).
Alterações em outros parâmetros não exigem isso.
## Modificação de um grupo de parâmetros (API do ElastiCache)
Para alterar os valores dos parâmetros de um grupo usando a API do ElastiCache, use a ação `ModifyCacheParameterGroup`.
**Example**
Com o Memcached, para localizar o nome e os valores permitidos do parâmetro que você deseja alterar, consulte [Parâmetros específicos do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached)
O código de exemplo a seguir define o valor de dois parâmetros, *chunk\$1size* e *chunk\$1size\$1growth\$1fact* no parameter group `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**
Com o Valkey e Redis OSS, para localizar o nome e os valores permitidos do parâmetro que você deseja alterar, consulte [Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
O código de exemplo a seguir define o valor de dois parâmetros, *reserved-memory-percent* e *cluster-enabled* no parameter group `myredis32-on-30`. Definimos *reserved-memory-percent* como `30` (30%) e *cluster-enabled* como `yes` para que o grupo de parâmetros possa ser usado com clusters do Valkey ou Redis OSS (modo cluster habilitado) (grupos de replicação).
```
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=
```
Para obter mais informações, consulte [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheParameterGroup.html).
Se você tiver um cluster do Valkey ou Redis OSS (modo cluster desabilitado) e fizer alterações nos parâmetros a seguir, é preciso reinicializar os nós no cluster:
+ activerehashing
+ bancos de dados
Para obter mais informações, consulte [Reinicialização de nós](nodes.rebooting.md).
**Alterações de parâmetro do Valkey ou Redis OSS (modo cluster habilitado)**
Se você fizer alterações nos parâmetros a seguir em um cluster do Valkey ou Redis OSS (modo cluster habilitado), siga as etapas a seguir.
activerehashing
bancos de dados
Crie um backup manual do seu cluster. Consulte [Realização de backups manuais](backups-manual.md).
Excluir o cluster. Consulte [Excluindo um cluster no ElastiCache](Clusters.Delete.md).
Restaure o cluster usando o parameter group alterado e o backup para propagar o novo cluster. Consulte [Restauração de um backup para um novo cache](backups-restoring.md).
Alterações em outros parâmetros não exigem isso.
# Exclusão de um grupo de parâmetros do ElastiCache
Você pode excluir um grupo de parâmetros personalizado usando o console do ElastiCache, a AWS CLI ou a API do ElastiCache.
Não será possível excluir um parameter group se ele estiver associado a qualquer cluster. Você também não pode excluir nenhum dos parameter groups padrão.
## Exclusão de um grupo de parâmetros (console)
O procedimento a seguir mostra como excluir um grupo de parâmetros usando o console do ElastiCache.
**Para excluir um grupo de parâmetros usando o console do ElastiCache**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Para ver uma lista de todos os parameter groups disponíveis, no painel de navegação à esquerda, escolha **Parameter Groups**.
1. Escolha os parameter groups que você deseja excluir marcando a caixa à esquerda do nome do parameter group.
O botão **Delete** ficará ativo.
1. Escolha **Excluir**.
A tela de confirmação **Delete Parameter Groups** será exibida.
1. Para excluir os parameter groups, na tela de confirmação **Delete Parameter Groups**, escolha **Delete**.
Para manter os parameter groups, escolha **Cancel**.
## Exclusão de um grupo de parâmetros (AWS CLI)
Para excluir um grupo de parâmetros usando a AWS CLI, use o comando `delete-cache-parameter-group`. Para o parameter group a ser excluído, o parameter group especificado por `--cache-parameter-group-name` não pode ter nenhum cluster associado a ele, nem pode ser um parameter group padrão.
O código de exemplo a seguir exclui o parameter group *myMem14*.
**Example**
Para Linux, macOS ou Unix:
```
aws elasticache delete-cache-parameter-group \
--cache-parameter-group-name myRed28
```
Para Windows:
```
aws elasticache delete-cache-parameter-group ^
--cache-parameter-group-name myRed28
```
Para obter mais informações, consulte [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).
## Exclusão de um grupo de parâmetros (API do ElastiCache)
Para excluir um grupo de parâmetros usando a API do ElastiCache, use a ação `DeleteCacheParameterGroup`. Para o parameter group a ser excluído, o parameter group especificado por `CacheParameterGroupName` não pode ter nenhum cluster associado a ele, nem pode ser um parameter group padrão.
**Example**
Com o Memcached, o código de exemplo a seguir exclui o grupo de parâmetros *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**
O código de exemplo a seguir exclui o parameter group *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=
```
Para obter mais informações, consulte [https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteCacheParameterGroup.html](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DeleteCacheParameterGroup.html).
# Parâmetros específicos do mecanismo
**Valkey e Redis OSS**
A maioria dos parâmetros do Valkey 8 é compatível com os parâmetros do Redis OSS 7.1. Os parâmetros do Valkey 7.2 são iguais aos parâmetros do Redis OSS 7.
Se você não especificar um grupo de parâmetros para seu cluster do Valkey ou Redis OSS, será usado um grupo de parâmetros padrão apropriado à versão de seu mecanismo. Não é possível alterar os valores de nenhum parâmetro em um grupo de parâmetros padrão. No entanto, é possível criar um grupo de parâmetros personalizado e atribui-lo ao seu cluster a qualquer momento, desde que os valores de parâmetros condicionalmente modificáveis sejam os mesmos nos dois grupos de parâmetros. Para obter mais informações, consulte [Criação de um grupo de parâmetros do ElastiCache](ParameterGroups.Creating.md).
**Topics**
+ [Parâmetros do Valkey e do Redis OSS](#ParameterGroups.Redis)
+ [Parâmetros específicos do Memcached](#ParameterGroups.Memcached)
## Parâmetros do Valkey e do Redis OSS
**Topics**
+ [Alterações de parâmetros do Valkey 8.2](#ParameterGroups.Valkey.8.2)
+ [Alterações de parâmetros do Valkey 8.1](#ParameterGroups.Valkey.8.1)
+ [Alterações de parâmetros do Valkey 8.0](#ParameterGroups.Valkey.8)
+ [Alterações nos parâmetros do Valkey 7.2 e Redis OSS 7](#ParameterGroups.Redis.7)
+ [Alterações de parâmetros do Redis OSS 6.x](#ParameterGroups.Redis.6-x)
+ [Alterações de parâmetros do Redis OSS 5.0.3](#ParameterGroups.Redis.5-0-3)
+ [Alterações de parâmetros do Redis OSS 5.0.0](#ParameterGroups.Redis.5.0)
+ [Alterações de parâmetros do Redis OSS 4.0.10](#ParameterGroups.Redis.4-0-10)
+ [Alterações de parâmetros do Redis OSS 3.2.10](#ParameterGroups.Redis.3-2-10)
+ [Alterações de parâmetros do Redis OSS 3.2.6](#ParameterGroups.Redis.3-2-6)
+ [Alterações de parâmetros do Redis OSS 3.2.4](#ParameterGroups.Redis.3-2-4)
+ [Parâmetros adicionados do Redis OSS 2.8.24 (aprimorado)](#ParameterGroups.Redis.2-8-24)
+ [Parâmetros adicionados do Redis OSS 2.8.23 (aprimorado)](#ParameterGroups.Redis.2-8-23)
+ [Parâmetros adicionados do Redis OSS 2.8.22 (aprimorado)](#ParameterGroups.Redis.2-8-22)
+ [Parâmetros adicionados do Redis OSS 2.8.21](#ParameterGroups.Redis.2-8-21)
+ [Parâmetros adicionados do Redis OSS 2.8.19](#ParameterGroups.Redis.2-8-19)
+ [Parâmetros adicionados do Redis OSS 2.8.6](#ParameterGroups.Redis.2-8-6)
+ [Parâmetros do Redis OSS 2.6.13](#ParameterGroups.Redis.2-6-13)
+ [Parâmetros específicos de node-type do Redis OSS](#ParameterGroups.Redis.NodeSpecific)
### Alterações de parâmetros do Valkey 8.2
**Família de grupos de parâmetros: valkey8**
**nota**
As alterações dos parâmetros do Valkey 8.2 não se aplicam ao Valkey 8.1
Os grupos de parâmetros do Valkey 8.0 e superiores são incompatíveis com o Redis OSS 7.2.4.
No Valkey 8.2, os seguintes comandos não estão disponíveis para caches de tecnologia sem servidor: `commandlog`, `commandlog get`, `commandlog help`, `commandlog len` e `commandlog reset.`
**Novos grupos de parâmetros no Valkey 8.2**
| Nome | Detalhes | Description |
| --- | --- | --- |
| search-fanout-target-mode (adicionado em 8.2) | Padrão: cliente Tipo: string Modificável: sim As alterações entram em vigor: imediatamente | O parâmetro search-fanout-target-mode de configuração controla como as consultas de pesquisa são distribuídas entre os nós em um ambiente de cluster Valkey. Essa configuração aceita dois valores: “throughput”, que otimiza o throughput máximo distribuindo aleatoriamente as consultas de pesquisa em todos os nós do cluster, independentemente do tipo de cliente ou do status READONLY, e “client”, que respeita as características da conexão do cliente ao rotear aleatoriamente clientes não READONLY para nós primários, clientes READONLY em conexões de réplica somente para nós de réplica e clientes READONLY em conexões primárias aleatoriamente em todos os nós. O comportamento padrão é o modo “client”, o que significa que o sistema respeitará os tipos de conexão do cliente e o status READONLY para decisões de roteamento de consultas. Use o modo de taxa de transferência para cargas de trabalho de pesquisa de alto volume, onde a utilização máxima dos recursos do cluster é desejada, e o modo cliente, quando quiser manter a read/write separação e respeitar os padrões de conexão READONLY em nível de aplicativo. |
| search-default-timeout-ms | Padrão: 50000 Valores permitidos: 1 a 60000 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | O tempo limite padrão de consulta de pesquisa do Valkey (em milissegundos). |
| search-enable-partial-results | Padrão: sim Valores permitidos: sim, não Tipo: booliano Modificável: sim As alterações entram em vigor: imediatamente | Configura o comportamento da falha de consulta para a pesquisa do Valkey. Quando ativadas, as consultas de pesquisa retornarão resultados parciais se houver tempos limite em um ou mais fragmentos. Quando desativado, qualquer tempo limite de fragmento fará com que toda a consulta de pesquisa falhe e retorne um erro. |
### Alterações de parâmetros do Valkey 8.1
**Família de grupos de parâmetros: valkey8**
**nota**
As alterações dos parâmetros do Valkey 8.1 não se aplicam ao Valkey 8.0
Os grupos de parâmetros do Valkey 8.0 e superiores são incompatíveis com o Redis OSS 7.2.4.
No Valkey 8.1, os seguintes comandos não estão disponíveis para caches de tecnologia sem servidor: `commandlog`, `commandlog get`, `commandlog help`, `commandlog len` e `commandlog reset.`
**Novos grupos de parâmetros no Valkey 8.1**
| Nome | Detalhes | Description |
| --- | --- | --- |
| commandlog-large-request-max-len (adicionado em 8.1) | Padrão: 1048576 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | O tamanho máximo, em bytes, das solicitações a serem registradas pelo atributo Valkey Command Log. |
| commandlog-large-request-max-len (adicionado em 8.1) | Padrão: 128 Valores permitidos: 0-1024 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | O comprimento máximo do log de comandos do Valkey para solicitações. |
| commandlog-reply-larger-than (adicionado em 8.1) | Padrão: 1048576 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | O tamanho máximo, em bytes, das respostas a serem registradas pelo atributo Valkey Command Log. |
| commandlog-large-reply-max-len (adicionado em 8.1) | Padrão: 128 Valores permitidos: 0-1024 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | O comprimento máximo do log de comandos do Valkey para respostas. |
### Alterações de parâmetros do Valkey 8.0
**Família de grupos de parâmetros: valkey8**
**nota**
O Redis OSS 7.2.4 é incompatível com os grupos de parâmetros Valkey 8 e superiores.
**Mudanças de parâmetros específicos no Valkey 8.0**
| Nome | Detalhes | Description |
| --- | --- | --- |
| repl-backlog-size | Padrão: 10485760 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | O tamanho, em bytes, do buffer de backlog do nó primário. O backlog é usado para registrar atualizações de dados no nó primário. Quando uma réplica de leitura se conecta ao primário, ela tenta executar uma sincronização parcial (psync), onde aplica dados do backlog para chegar ao mesmo nível do nó primário. Se psync falhar, será necessária uma sincronização completa. O valor mínimo para esse parâmetro é 16384. Observação: a partir do Redis OSS 2.8.22, esse parâmetro se aplica ao cluster primário, bem como às réplicas de leitura. |
| maxmemory-samples | Padrão: 3 Valores permitidos: 1 a 64 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | Para cálculos least-recently-used (LRU) e time-to-live (TTL), esse parâmetro representa o tamanho amostral das chaves a serem verificadas. Por padrão, o Redis OSS escolhe três chaves e usa a que foi usada menos recentemente. |
**Novos grupos de parâmetros no Valkey 8.0**
| Nome | Detalhes | Description |
| --- | --- | --- |
| extended-redis-compatibility | Valores permitidos: sim, não Padrão: sim Tipo: booliano Modificável: sim As alterações ocorrem: imediatamente | O modo de compatibilidade estendida do Redis OSS faz com que o Valkey finja ser o Redis OSS 7.2. Ative essa opção somente se você tiver problemas com ferramentas ou clientes. Impactos para o cliente: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
**Grupos de parâmetros removidos no Valkey 8.0**
| Nome | Detalhes | Description |
| --- | --- | --- |
| lazyfree-lazy-eviction | Valores permitidos: sim, não Padrão: não Tipo: booliano Modificável: sim As alterações ocorrem: imediatamente | Realiza uma exclusão assíncrona em remoções. |
| lazyfree-lazy-expire | Valores permitidos: sim, não Padrão: não Tipo: booliano Modificável: sim As alterações ocorrem: imediatamente | Realiza uma exclusão assíncrona em chaves expiradas. |
| lazyfree-lazy-server-del | Valores permitidos: sim, não Padrão: não Tipo: booliano Modificável: sim As alterações ocorrem: imediatamente | Realiza uma exclusão assíncrona para comandos que atualizam valores. |
| lazyfree-lazy-user-del | Padrão: não Tipo: string Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Quando o valor é definido como yes (sim), o comando DEL funciona da mesma forma que UNLINK. |
| replica-lazy-flush | Padrão: sim Tipo: booliano Modificável: não Nome anterior: slave-lazy-flush | Realiza um flushDB assíncrono durante a sincronização da réplica. |
### Alterações nos parâmetros do Valkey 7.2 e Redis OSS 7
**Família de grupos de parâmetros:** valkey7
Os grupos de parâmetros padrão do Valkey 7.2 são os seguintes:
+ `default.valkey7`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey (modo cluster desabilitado).
+ `default.valkey7.cluster.on`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey (modo cluster habilitado).
**Família de grupo de parâmetros:** redis7
Os grupos de parâmetros padrão do Redis OSS 7 são os seguintes:
+ `default.redis7`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Redis OSS (modo cluster desabilitado).
+ `default.redis7.cluster.on`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Redis OSS (modo cluster habilitado).
**Alterações específicas de parâmetros**
Os parâmetros adicionados no Redis OSS 7 são os seguintes. O Valkey 7.2 também aceita esses parâmetros.
| Nome | Detalhes | Description |
| --- | --- | --- |
| cluster-allow-pubsubshard-when-down | Valores permitidos: `yes`, `no` Padrão: `yes` Tipo: string Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Quando definido como padrão de yes (sim), permite que os nós forneçam tráfego fragmentado do pubsub enquanto o cluster está inativo, desde que acredite que possui os slots. |
| cluster-preferred-endpoint-type | Valores permitidos: `ip`, `tls-dynamic` Padrão: `tls-dynamic` Tipo: string Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Esse valor controla qual endpoint é retornado para solicitações MOVED/ASKING, bem como o campo do endpoint para `CLUSTER SLOTS` e `CLUSTER SHARDS`. Quando o valor for definido como ip, o nó anunciará seu endereço IP. Quando o valor é definido como tls-dynamic, o nó anunciará um nome de host quando encryption-in-transit estiver habilitado e, caso contrário, um endereço IP. |
| latency-tracking | Valores permitidos: `yes`, `no` Padrão: `no` Tipo: string Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Quando definido como yes (sim), rastreia as latências por comando e permite exportar a distribuição de percentil por meio do comando de estatísticas de latência do `INFO` e as distribuições de latência cumulativa (histogramas) por meio do comando `LATENCY`. |
| hash-max-listpack-entries | Valores permitidos: `0+` Padrão: `512` Tipo: inteiro Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | O número máximo de entradas de hash para que o conjunto de dados seja compactado. |
| hash-max-listpack-value | Valores permitidos: `0+` Padrão: `64` Tipo: inteiro Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | O limite das maiores entradas de hash para que o conjunto de dados seja compactado. |
| zset-max-listpack-entries | Valores permitidos: `0+` Padrão: `128` Tipo: inteiro Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | O número máximo de entradas do conjunto classificado para que o conjunto de dados seja compactado. |
| zset-max-listpack-value | Valores permitidos: `0+` Padrão: `64` Tipo: inteiro Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | O limite das maiores entradas do conjunto classificado para que o conjunto de dados seja compactado. |
Os parâmetros alterados no Redis OSS 7 são os seguintes.
| Nome | Detalhes | Description |
| --- | --- | --- |
| activerehashing | Permite modificação: `no`. No Redis OSS 7, esse parâmetro está oculto e ativado por padrão. Para desativá-lo, você precisa criar um [caso de suporte](https://console.aws.amazon.com/support/home). | Permite modificação era Sim. |
Os parâmetros removidos no Redis OSS 7 são os seguintes.
| Nome | Detalhes | Description |
| --- | --- | --- |
| hash-max-ziplist-entries | Valores permitidos: `0+` Padrão: `512` Tipo: inteiro Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Use `listpack` em vez de `ziplist` para representar uma pequena codificação de hash |
| hash-max-ziplist-value | Valores permitidos: `0+` Padrão: `64` Tipo: inteiro Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Use `listpack` em vez de `ziplist` para representar uma pequena codificação de hash |
| zset-max-ziplist-entries | Valores permitidos: `0+` Padrão: `128` Tipo: inteiro Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Use `listpack` em vez de `ziplist` para representar uma pequena codificação de hash. |
| zset-max-ziplist-value | Valores permitidos: `0+` Padrão: `64` Tipo: inteiro Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Use `listpack` em vez de `ziplist` para representar uma pequena codificação de hash. |
| list-max-ziplist-size | Valores permitidos: Padrão: `-2` Tipo: inteiro Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | O número de entradas permitidas por nó interno da lista. |
### Alterações de parâmetros do Redis OSS 6.x
**Família de grupo de parâmetros:** redis6.x
Os grupos de parâmetros padrão do Redis OSS 6.x são os seguintes:
+ `default.redis6.x`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey ou Redis OSS (modo cluster desabilitado).
+ `default.redis6.x.cluster.on`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey ou Redis OSS (modo cluster habilitado).
**nota**
No mecanismo Redis OSS versão 6.2, quando a família de nós r6gd foi introduzida para uso com [Classificação de dados em níveis no ElastiCache](data-tiering.md), somente as políticas max-memory *noeviction*, *volatile-lru* e *allkeys-lru* são compatíveis com os tipos de nó r6gd.
Para obter mais informações, consulte [ElastiCache versão 6.2 para Redis OSS (aprimorada)](engine-versions.md#redis-version-6.2) e [ElastiCache versão 6.0 para Redis OSS (aprimorada)](engine-versions.md#redis-version-6.0).
Os parâmetros adicionados no Redis OSS 6.x são os seguintes.
| Detalhes | Description |
| --- | --- |
| acl-pubsub-default (added in 6.2) | Valores permitidos: `resetchannels`, `allchannels` Padrão: `allchannels` Tipo: string Modificável: sim Entrada das alterações em vigor: os usuários existentes do Redis OSS associados ao cluster continuarão a ter as permissões existentes. Atualize os usuários ou reinicialize o cluster para atualizar os usuários existentes do Redis OSS. | Permissões de canal pubsub padrão para usuários de ACL implantados neste cluster. |
| cluster-allow-reads-when-down (added in 6.0) | Padrão: não Tipo: string Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Quando definido como sim, um grupo de replicação do Redis OSS (modo cluster habilitado) continua a processar comandos de leitura mesmo quando um nó não é capaz de alcançar um quórum de primários. Quando definido como o padrão de no (não), o grupo de replicação rejeita todos os comandos. Recomendamos definir esse valor como yes (sim) se você estiver usando um cluster com menos de três grupos de nós ou sua aplicação pode lidar com leituras obsoletas com segurança. |
| tracking-table-max-keys (added in 6.0) | Padrão: 1.000.000 Tipo: número Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Para ajudar o cache do lado do cliente, o Redis OSS oferece suporte ao monitoramento de quais clientes acessaram quais chaves. Quando a chave monitorada é modificada, mensagens de invalidação são enviadas a todos os clientes para notificá-los que seus valores armazenados em cache não são mais válidos. Esse valor permite que você especifique o limite superior desta tabela. Depois que esse valor de parâmetro é excedido, são enviadas invalidações aos clientes aleatoriamente. Esse valor deve ser ajustado para limitar o uso da memória, enquanto ainda mantém o controle de chaves suficientes. As chaves também são invalidadas em condições de pouca memória. |
| acllog-max-len (added in 6.0) | Padrão: 128 Tipo: número Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Esse valor corresponde ao número máximo de entradas no log da ACL. |
| active-expire-effort (added in 6.0) | Padrão: 1 Tipo: número Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | O Redis OSS exclui chaves que excederam seu tempo de vida por dois mecanismos. Em um, uma chave é acessada e se descobre que ela está expirada. No outro, um trabalho periódico amostra as chaves e faz com que aquelas que excederam seu tempo de vida expirem. Esse parâmetro define a quantidade de esforço que o Redis OSS usa para expirar itens no trabalho periódico. O valor padrão de 1 tenta evitar ter mais de 10 por cento das chaves expiradas ainda na memória. Ele também tenta evitar consumir mais de 25% da memória total e adicionar latência ao sistema. Você pode aumentar esse valor até 10 para aumentar a quantidade de esforço gasto em chaves expirando. A compensação é mais CPU e latência potencialmente maior. Recomendamos um valor de 1, a menos que você esteja vendo alto uso de memória e possa tolerar um aumento na utilização da CPU. |
| lazyfree-lazy-user-del (added in 6.0) | Padrão: não Tipo: string Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Quando o valor é definido como yes (sim), o comando `DEL` funciona da mesma forma que `UNLINK`. |
Os parâmetros removidos no Redis OSS 6.x são os seguintes.
| Nome | Detalhes | Description |
| --- | --- | --- |
| lua-replicate-commands | Valores permitidos: sim/não Padrão: sim Tipo: booliano Modificável: sim As alterações entram em vigor: imediatamente | Sempre habilite ou não a replicação de efeito Lua em scripts Lua |
### Alterações de parâmetros do Redis OSS 5.0.3
**Família de grupo de parâmetros:** redis5.0
Grupos de parâmetros padrão do Redis OSS 5.0
+ `default.redis5.0`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey ou Redis OSS (modo cluster desabilitado).
+ `default.redis5.0.cluster.on`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey ou Redis OSS (modo cluster habilitado).
**Parâmetros adicionados no Redis OSS 5.0.3**
| Nome | Detalhes | Description |
| --- | --- | --- |
| rename-commands | Padrão: nenhum Tipo: string Modificável: sim As alterações entrarão em vigor: imediatamente em todos os nós no cluster. | Uma lista separada por espaços de comandos Redis OSS renomeados. Veja a seguir uma lista restrita de comandos disponíveis para renomear: `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` |
Para obter mais informações, consulte [ElastiCache versão 5.0.6 para Redis OSS (aprimorada)](engine-versions.md#redis-version-5-0.6).
### Alterações de parâmetros do Redis OSS 5.0.0
**Família de grupo de parâmetros:** redis5.0
Grupos de parâmetros padrão do Redis OSS 5.0
+ `default.redis5.0`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey ou Redis OSS (modo cluster desabilitado).
+ `default.redis5.0.cluster.on`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey ou Redis OSS (modo cluster habilitado).
**Parâmetros adicionados no Redis OSS 5.0**
| Nome | Detalhes | Description |
| --- | --- | --- |
| stream-node-max-bytes | Valores permitidos: 0\$1 Padrão: 4096 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | A estrutura do fluxo de dados é uma árvore radix de nós que codifica vários itens dentro. Use esta configuração para especificar o tamanho máximo de um nó único em uma árvore radix em bytes. Se definido como 0, o tamanho do nó da árvore é ilimitado. |
| stream-node-max-entries | Valores permitidos: 0\$1 Padrão: 100 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | A estrutura do fluxo de dados é uma árvore radix de nós que codifica vários itens dentro. Use essa configuração para especificar o número máximo de itens que um único nó pode conter antes de alternar para um novo nó ao anexar novas entradas de fluxo. Se definido como 0, o número de itens no nó da árvore é ilimitado |
| active-defrag-max-scan-fields | Valores permitidos: 1 a 1000000 Padrão: 1000 Tipo: inteiro Modificável: sim As alterações entram em vigor: imediatamente | Número máximo de set/hash/zset/list campos que serão processados a partir da verificação do dicionário principal |
| lua-replicate-commands | Valores permitidos: sim/não Padrão: sim Tipo: booliano Modificável: sim As alterações entram em vigor: imediatamente | Sempre habilite ou não a replicação de efeito Lua em scripts Lua |
| replica-ignore-maxmemory | Padrão: sim Tipo: booliano Modificável: não | Determina se a réplica ignora a configuração maxmemory ao não remover itens independentes do primário |
O Redis OSS renomeou vários parâmetros na versão 5.0 do mecanismo em resposta ao feedback da comunidade. Para obter mais informações, consulte [O que há de novo no Redis OSS 5?](https://aws.amazon.com/redis/Whats_New_Redis5/) A tabela a seguir lista os novos nomes e como eles mapeiam para versões anteriores.
**Parâmetros renomeados no Redis OSS 5.0**
| Nome | Detalhes | Description |
| --- | --- | --- |
| replica-lazy-flush | Padrão: sim Tipo: booliano Modificável: não Nome anterior: slave-lazy-flush | Realiza um flushDB assíncrono durante a sincronização da réplica. |
| client-output-buffer-limit-replica-hard-limit | Padrão: para valores, consulte [Parâmetros específicos de node-type do Redis OSS](#ParameterGroups.Redis.NodeSpecific) Tipo: inteiro Modificável: não Nome anterior: client-output-buffer-limit - slave-hard-limit | Para réplicas de leitura do Redis OSS: se o buffer de saída de um cliente atingir o número especificado de bytes, o cliente será desconectado. |
| client-output-buffer-limit-replica-soft-limit | Padrão: para valores, consulte [Parâmetros específicos de node-type do Redis OSS](#ParameterGroups.Redis.NodeSpecific) Tipo: inteiro Modificável: não Nome anterior: client-output-buffer-limit - slave-soft-limit | Para réplicas de leitura do Redis OSS: se o buffer de saída de um cliente atingir o número especificado de bytes, o cliente será desconectado, mas somente se essa condição persistir por client-output-buffer-limit-replica-soft-seconds. |
| client-output-buffer-limit-replica-soft-seconds | Padrão: 60 Tipo: inteiro Modificável: não Nome anterior: client-output-buffer-limit - slave-soft-seconds | Para réplicas de leitura do Redis OSS: se o buffer de saída de um cliente permanecer em client-output-buffer-limit-replica-soft-limit bytes por mais tempo que esse número de segundos, o cliente será desconectado. |
| replica-allow-chaining | Padrão: não Tipo: string Modificável: não Nome anterior: slave-allow-chaining | Determina se uma réplica de leitura no Redis OSS pode ter réplicas de leitura próprias. |
| min-replicas-to-write | Padrão: 0 Tipo: inteiro Modificável: sim Nome anterior: min-slaves-to-write As alterações terão efeito: imediatamente | O número mínimo de réplicas de leitura que devem estar disponíveis para que o nó primário aceite gravações de clientes. Se o número de réplicas disponíveis cair abaixo desse número, o nó primário não aceitará mais solicitações de gravação. Se esse parâmetro ou min-replicas-max-lag for 0, o nó primário sempre aceitará solicitações de gravação, mesmo que nenhuma réplica esteja disponível. |
| min-replicas-max-lag | Padrão: 10 Tipo: inteiro Modificável: sim Nome anterior: min-slaves-max-lag As alterações terão efeito: imediatamente | O número de segundos em que o nó primário deve receber uma solicitação de ping de uma réplica de leitura. Se essa quantidade de tempo passar, e o primário não receber um ping, a réplica não será mais considerada disponível. Se o número de réplicas disponíveis cair abaixo min-replicas-to-write, a primária deixará de aceitar gravações nesse momento. Se esse parâmetro ou min-replicas-to-write for 0, o nó primário sempre aceitará solicitações de gravação, mesmo que nenhuma réplica esteja disponível. |
| close-on-replica-write | Padrão: sim Tipo: booliano Modificável: sim Nome anterior: close-on-slave-write As alterações terão efeito: imediatamente | Se ativado, os clientes que tentarem gravar em uma réplica somente leitura serão desconectados. |
**Parâmetros removidos no Redis OSS 5.0**
| Nome | Detalhes | Description |
| --- | --- | --- |
| repl-timeout | Padrão: 60 Modificável: não | O parâmetro não está disponível nesta versão. |
### Alterações de parâmetros do Redis OSS 4.0.10
**Família de grupo de parâmetros:** redis4.0
Grupos de parâmetros padrão do Redis OSS 4.0.x
+ `default.redis4.0`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey ou Redis OSS (modo cluster desabilitado).
+ `default.redis4.0.cluster.on`: use este grupo de parâmetros, ou um grupo derivado dele, para grupos de replicação e clusters do Valkey ou Redis OSS (modo cluster habilitado).
**Parâmetros alterados no Redis OSS 4.0.10**
| Nome | Detalhes | Description |
| --- | --- | --- |
| maxmemory-policy | Valores permitidos: `allkeys-lru`, `volatile-lru`, **allkeys-lfu**, **volatile-lfu**, `allkeys-random`, `volatile-random`, `volatile-ttl`, `noeviction` Padrão: volatile-lru Tipo: string Modificável: sim As alterações ocorrem: imediatamente | maxmemory-policy foi adicionado na versão 2.6.13. Na versão 4.0.10 foram adicionados dois novos valores permitidos: allkeys-lfu, que excluirá qualquer chave que esteja usando LFU aproximado, e volatile-lfu, que excluirá o uso de LFU aproximado entre as chaves com um conjunto de expiração. Na versão 6.2, quando a família de nós r6gd foi introduzida para uso com classificação de dados em níveis, somente as políticas noeviction, volatile-lru e allkeys-lru são compatíveis com os tipos de nó r6gd. |
**Parâmetros adicionados no Redis OSS 4.0.10**
| Nome | Detalhes | Description |
| --- |--- |--- |
| **Parâmetros de exclusão assíncrona** |
| --- |
| lazyfree-lazy-eviction | Valores permitidos: sim/não Padrão: não Tipo: booliano Modificável: sim As alterações ocorrem: imediatamente | Realiza uma exclusão assíncrona em remoções. |
| lazyfree-lazy-expire | Valores permitidos: sim/não Padrão: não Tipo: booliano Modificável: sim As alterações ocorrem: imediatamente | Realiza uma exclusão assíncrona em chaves expiradas. |
| lazyfree-lazy-server-del | Valores permitidos: sim/não Padrão: não Tipo: booliano Modificável: sim As alterações ocorrem: imediatamente | Realiza uma exclusão assíncrona para comandos que atualizam valores. |
| slave-lazy-flush | Valores permitidos: N/D Padrão: não Tipo: booliano Modificável: não As alterações ocorrem: N/D | Realiza um flushDB assíncrono durante a sincronização subordinada. |
| **Parâmetros de LFU** |
| --- |
| lfu-log-factor | Valores permitidos: qualquer inteiro > 0 Padrão: 10 Tipo: inteiro Modificável: sim As alterações ocorrem: imediatamente | Defina o fator de log, que determina o número de hits de chave para saturar o contador de chaves. |
| lfu-decay-time | Valores permitidos: qualquer inteiro Padrão: 1 Tipo: inteiro Modificável: sim As alterações ocorrem: imediatamente | O tempo em minutos para diminuir o contador de chaves. |
| **Parâmetros de desfragmentação ativa** |
| --- |
| activedefrag | Valores permitidos: sim/não Padrão: não Tipo: booliano Modificável: sim As alterações ocorrem: imediatamente | Habilita a desfragmentação ativa. Nas versões 7.0 e superiores do Valkey e Redis OSS,AWS pode executar automaticamente a desfragmentação quando operacionalmente necessário, independentemente dessa configuração. |
| active-defrag-ignore-bytes | Valores permitidos: 10485760-104857600 Padrão: 104857600 Tipo: inteiro Modificável: sim As alterações ocorrem: imediatamente | Quantidade mínima de desperdício de fragmentação para iniciar a desfragmentação ativa. |
| active-defrag-threshold-lower | Valores permitidos: 1-100 Padrão: 10 Tipo: inteiro Modificável: sim As alterações ocorrem: imediatamente | Porcentagem mínima de fragmentação para iniciar a desfragmentação ativa. |
| active-defrag-threshold-upper | Valores permitidos: 1-100 Padrão: 100 Tipo: inteiro Modificável: sim As alterações ocorrem: imediatamente | Porcentagem máxima de fragmentação em que usamos o esforço máximo. |
| active-defrag-cycle-min | Valores permitidos: 1-75 Padrão: 25 Tipo: inteiro Modificável: sim As alterações ocorrem: imediatamente | Esforço mínimo para desfragmentação em porcentagem de CPU. |
| active-defrag-cycle-max | Valores permitidos: 1-75 Padrão: 75 Tipo: inteiro Modificável: sim As alterações ocorrem: imediatamente | Esforço máximo para desfragmentação em porcentagem de CPU. |
| **Parâmetros de buffer de saída do cliente** |
| --- |
| client-query-buffer-limit | Valores permitidos: 1048576-1073741824 Padrão: 1073741824 Tipo: inteiro Modificável: sim As alterações ocorrem: imediatamente | Tamanho máximo de um único buffer de consulta do cliente. |
| proto-max-bulk-len | Valores permitidos: 1048576-536870912 Padrão: 536870912 Tipo: inteiro Modificável: sim As alterações ocorrem: imediatamente | Tamanho máximo de uma única solicitação de elemento. |
### Alterações de parâmetros do Redis OSS 3.2.10
**Família de grupo de parâmetros:** redis3.2
ElastiCache para o Redis OSS 3.2.10, não há suporte a parâmetros adicionais.
### Alterações de parâmetros do Redis OSS 3.2.6
**Família de grupo de parâmetros:** redis3.2
Para o Redis OSS 3.2.6, não há parâmetros adicionais com suporte.
### Alterações de parâmetros do Redis OSS 3.2.4
**Família de grupo de parâmetros:** redis3.2
Começando com o Redis OSS 3.2.4, existem dois grupo de parâmetros padrão.
+ `default.redis3.2`: ao executar o Redis OSS 3.2.4, especifique este grupo de parâmetros, ou um derivado dele, se quiser criar um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) e ainda usar os atributos adicionais do Redis OSS 3.2.4.
+ `default.redis3.2.cluster.on`: especifique este grupo de parâmetros, ou um derivado dele, quando quiser criar um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado).
**Topics**
+ [Novos parâmetros para o Redis OSS 3.2.4](#ParameterGroups.Redis.3-2-4.New)
+ [Parâmetros alterados no Redis OSS 3.2.4 (aprimorado)](#ParameterGroups.Redis.3-2-4.Changed)
#### Novos parâmetros para o Redis OSS 3.2.4
**Família de grupo de parâmetros:** redis3.2
Para o Redis OSS 3.2.4, há suporte para os seguintes parâmetros adicionais.
****
| Nome | Detalhes | Description |
| --- | --- | --- |
| list-max-ziplist-size | Padrão: -2 Tipo: inteiro Modificável: não | As listas são codificadas de forma especial para economizar espaço. O número de entradas permitidas por nó de lista interno pode ser especificado como um tamanho máximo fixo ou um número máximo de elementos. Para um tamanho máximo fixo, use de -5 a -1, significando: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| list-compress-depth | Padrão: 0 Tipo: inteiro Modificável: sim As alterações terão efeito: imediatamente | As listas também podem ser compactadas. A profundidade de compactação é o número de nós ziplist de lista rápida de cada lado da lista a serem excluídos da compactação. O início e o final cauda da lista são sempre descompactados para operações Push e Pop rápidas. As configurações são: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
| cluster-enabled | Padrão: no/yes \$1 Tipo: string Modificável: não | Indica se este é um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) no modo cluster (sim) ou um grupo de replicação do Valkey ou Redis OSS (modo cluster habilitado) no modo sem cluster (não). Grupos de replicação do Valkey ou Redis OSS (modo cluster habilitado) no modo cluster podem particionar seus dados em até 500 grupos de nós. \$1 O Redis OSS 3.2.*x* tem dois grupo de parâmetros padrão. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html). |
| cluster-require-full-coverage | Padrão: não Tipo: booliano Modificável: sim As alterações terão efeito: imediatamente | Quando estão definidos como `yes`, os nós do Valkey ou Redis OSS (modo cluster habilitado) no modo cluster param de aceitar consultas quando detectam pelo menos um slot de hash descoberto (nenhum nó disponível que o sirva). Dessa forma, se o cluster estiver parcialmente inativo, ele ficará indisponível. Ele voltará a ficar disponível automaticamente assim que todos os slots forem novamente cobertos. No entanto, às vezes você deseja que o subconjunto do cluster que está trabalhando continue a aceitar consultas para a parte do espaço de chaves que ainda está coberto. Para fazer isto, basta configurar a opção `cluster-require-full-coverage` como `no`. |
| hll-sparse-max-bytes | Padrão: 3000 Tipo: inteiro Modificável: sim As alterações terão efeito: imediatamente | HyperLogLog limite de bytes de representação esparsa. O limite inclui o cabeçalho de 16 bytes. Quando o HyperLogLog uso da representação esparsa ultrapassa esse limite, ele é convertido na representação densa. Não é recomendado um valor superior a 16000, porque, nesse ponto, a representação densa é mais eficiente em termos de memória. Recomendamos um valor de 3000 para ter os benefícios da codificação eficiente do espaço sem diminuir demais o PFADD, que é O(N) com a codificação esparsa. O valor pode ser aumentado para \$1 10000 quando a CPU não é uma preocupação, mas o espaço é, e o conjunto de dados é composto por muitos HyperLogLogs com cardinalidade na faixa de 0 a 15000. |
| reserved-memory-percent | Padrão: 25 Tipo: inteiro Modificável: sim As alterações terão efeito: imediatamente | A porcentagem da memória de um nó reservada para o uso não de dados. Por padrão, a área de dados do Redis OSS cresce até consumir toda a memória do nó. Se isso ocorrer, o desempenho do nó provavelmente sofrerá devido a uma paginação de memória excessiva. Ao reservar memória, você pode separar uma parte da memória disponível para fins não Redis OSS, a fim de ajudar a reduzir a quantidade de paginação. Esse parâmetro é específico e não faz parte da distribuição padrão do Redis OSS. ElastiCache Para obter mais informações, consulte `reserved-memory` e [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md). |
#### Parâmetros alterados no Redis OSS 3.2.4 (aprimorado)
**Família de grupo de parâmetros:** redis3.2
Para o Redis OSS 3.2.4, os parâmetros a seguir foram alterados.
****
| Nome | Detalhes | Alteração |
| --- | --- | --- |
| activerehashing | Modificável: Sim se o grupo de parâmetros não estiver associado a nenhum cluster. Do contrário, não. | Modificável era Não. |
| databases | Modificável: Sim se o grupo de parâmetros não estiver associado a nenhum cluster. Do contrário, não. | Modificável era Não. |
| appendonly | Padrão: desativado Modificável: não | Se quiser atualizar de uma versão anterior do Redis OSS, primeiro você deve desativar `appendonly`. |
| appendfsync | Padrão: desativado Modificável: não | Se quiser atualizar de uma versão anterior do Redis OSS, primeiro você deve desativar `appendfsync`. |
| repl-timeout | Padrão: 60 Modificável: não | Agora, ele não é modificável com um padrão de 60. |
| tcp-keepalive | Padrão: 300 | O padrão era 0. |
| list-max-ziplist-entries | | O parâmetro não está mais disponível. |
| list-max-ziplist-value | | O parâmetro não está mais disponível. |
### Parâmetros adicionados do Redis OSS 2.8.24 (aprimorado)
**Família de grupo de parâmetros:** redis2.8
Para o Redis OSS 2.8.24, não há parâmetros adicionais com suporte.
### Parâmetros adicionados do Redis OSS 2.8.23 (aprimorado)
**Família de grupo de parâmetros:** redis2.8
Para o Redis OSS 2.8.23, o parâmetro adicional a seguir tem suporte.
****
| Nome | Detalhes | Description |
| --- | --- | --- |
| close-on-slave-write | Padrão: sim Tipo: string (sim/não) Modificável: sim As alterações terão efeito: imediatamente | Se ativado, os clientes que tentarem gravar em uma réplica somente leitura serão desconectados. |
#### Como a close-on-slave-write funciona
O `close-on-slave-write` parâmetro é introduzido pela Amazon ElastiCache para dar a você mais controle sobre como seu cluster responde quando um nó primário e um nó de réplica de leitura trocam de funções devido à promoção de uma réplica de leitura para primária.
![\[Imagem: close-on-replica-write, tudo funcionando bem\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-01.png)
Se o cluster de réplica de leitura for promovido para primário por qualquer motivo que não seja o failover de um grupo de replicação habilitado para Multi-AZ, o cliente continuará tentando gravar no endpoint A. Como o endpoint A é agora o endpoint de uma réplica de leitura, essas gravações falharão. Esse é o comportamento do Redis OSS antes da ElastiCache introdução `close-on-replica-write` e o comportamento se você desabilitar. `close-on-replica-write`
![\[Imagem: close-on-slave-write, falha na gravação\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-02.png)
Com `close-on-replica-write` habilitado, a qualquer momento que um cliente tentar gravar em uma réplica de leitura, a conexão do cliente com o cluster será encerrada. Sua lógica de aplicativo deve detectar a desconexão, verificar a tabela DNS e reconectar-se ao endpoint primário, que agora seria o endpoint B.
![\[Imagem: close-on-slave-write, gravando no novo cluster primário\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-close-on-slave-write-03.png)
#### Quando você pode desativar close-on-replica-write
Se desabilitar `close-on-replica-write` resulta na falha do cluster, por que você deseja desabilitar `close-on-replica-write`?
Conforme mencionado anteriormente, com `close-on-replica-write` habilitado, a qualquer momento que um cliente tentar gravar em uma réplica de leitura, a conexão do cliente com o cluster será encerrada. Estabelecer uma nova conexão com o nó leva tempo. Assim, desconectar e reconectar devido a uma solicitação de gravação para a réplica também afeta a latência das solicitações de leitura que são veiculadas pela mesma conexão. Esse efeito permanece em vigor até uma nova conexão ser estabelecida. Se seu aplicativo for especialmente pesado em termos de leitura ou muito sensível à latência, convém manter seus clientes conectados para evitar degradar o desempenho de leitura.
### Parâmetros adicionados do Redis OSS 2.8.22 (aprimorado)
**Família de grupo de parâmetros:** redis2.8
Para o Redis OSS 2.8.22, não há parâmetros adicionais com suporte.
**Importante**
A partir do Redis OSS versão 2.8.22, `repl-backlog-size` aplica-se ao cluster primário, bem como a clusters de réplica.
A partir do Redis OSS versão 2.8.22, o parâmetro `repl-timeout` não tem suporte. Se for alterado, ElastiCache substituirá pelo padrão (60s), como fazemos com`appendonly`.
Os seguintes parâmetros não têm mais suporte.
+ *appendonly*
+ *appendfsync*
+ *repl-timeout*
### Parâmetros adicionados do Redis OSS 2.8.21
**Família de grupo de parâmetros:** redis2.8
Para o Redis OSS 2.8.21, não há parâmetros adicionais com suporte.
### Parâmetros adicionados do Redis OSS 2.8.19
**Família de grupo de parâmetros:** redis2.8
Para o Redis OSS 2.8.19, não há parâmetros adicionais com suporte.
### Parâmetros adicionados do Redis OSS 2.8.6
**Família de grupo de parâmetros:** redis2.8
Para o Redis OSS 2.8.6, há suporte para os seguintes parâmetros adicionais.
****
| Nome | Detalhes | Description |
| --- | --- | --- |
| min-slaves-max-lag | Padrão: 10 Tipo: inteiro Modificável: sim As alterações terão efeito: imediatamente | O número de segundos em que o nó primário deve receber uma solicitação de ping de uma réplica de leitura. Se essa quantidade de tempo passar, e o primário não receber um ping, a réplica não será mais considerada disponível. Se o número de réplicas disponíveis cair abaixo min-slaves-to-write, a primária deixará de aceitar gravações nesse momento. Se esse parâmetro ou min-slaves-to-write for 0, o nó primário sempre aceitará solicitações de gravação, mesmo que nenhuma réplica esteja disponível. |
| min-slaves-to-write | Padrão: 0 Tipo: inteiro Modificável: sim As alterações terão efeito: imediatamente | O número mínimo de réplicas de leitura que devem estar disponíveis para que o nó primário aceite gravações de clientes. Se o número de réplicas disponíveis cair abaixo desse número, o nó primário não aceitará mais solicitações de gravação. Se esse parâmetro ou min-slaves-max-lag for 0, o nó primário sempre aceitará solicitações de gravação, mesmo que nenhuma réplica esteja disponível. |
| notify-keyspace-events | Padrão: (uma string vazia) Tipo: string Modificável: sim As alterações terão efeito: imediatamente | Os tipos de eventos de espaço de chaves sobre os quais o Redis OSS pode notificar os clientes. Cada tipo de evento é representado por uma única letra: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) Você pode ter qualquer combinação desses tipos de eventos. Por exemplo, *AKE* significa que o Redis OSS pode publicar notificações de todos os tipos de eventos. Não use nenhum caractere diferente dos listados acima. Se isso for feito, mensagens de erro serão geradas. Por padrão, esse parâmetro é definido como uma string vazia, o que significa que a notificação de eventos de espaço de chaves está desabilitada. |
| repl-backlog-size | Padrão: 1048576 Tipo: inteiro Modificável: sim As alterações terão efeito: imediatamente | O tamanho, em bytes, do buffer de backlog do nó primário. O backlog é usado para registrar atualizações de dados no nó primário. Quando uma réplica de leitura se conecta ao primário, ela tenta executar uma sincronização parcial (`psync`), onde aplica dados do backlog para chegar ao mesmo nível do nó primário. Se `psync` falhar, será necessária uma sincronização completa. O valor mínimo para esse parâmetro é 16384. A partir do Redis OSS 2.8.22, esse parâmetro se aplica ao cluster primário, bem como às réplicas de leitura. |
| repl-backlog-ttl | Padrão: 3600 Tipo: inteiro Modificável: sim As alterações terão efeito: imediatamente | O número de segundos que o nó primário manterá o buffer de backlog. A partir do momento em que o último nó de réplica tiver sido desconectado, os dados no backlog permanecerão intactos até `repl-backlog-ttl` expirar. Se a réplica não tiver se conectado ao primário dentro desse tempo, o primário liberará o buffer de backlog. Quando a réplica eventualmente se reconectar, ela terá que executar uma sincronização completa com o primário. Se esse parâmetro estiver definido como 0, o buffer de backlog nunca será liberado. |
| repl-timeout | Padrão: 60 Tipo: inteiro Modificável: sim As alterações terão efeito: imediatamente | Representa o período de tempo limite, em segundos, para: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html) |
### Parâmetros do Redis OSS 2.6.13
**Família de grupo de parâmetros:** redis2.6
O Redis OSS 2.6.13 foi a primeira versão do Redis OSS suportada pelo. ElastiCache A tabela a seguir mostra os parâmetros do Redis OSS 2.6.13 compatíveis. ElastiCache
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/ParameterGroups.Engine.html)
**nota**
Se você não especificar um grupo de parâmetros para seu cluster do Redis OSS 2.6.13, um grupo de parâmetros padrão (`default.redis2.6`) será usado. Não é possível alterar os valores de parâmetros no grupo de parâmetros padrão. No entanto, você sempre pode criar um grupo de parâmetros personalizado e atribuí-lo ao seu cluster a qualquer momento.
### Parâmetros específicos de node-type do Redis OSS
Embora a maioria dos parâmetros tenha um valor único, alguns parâmetros têm valores diferentes dependendo do tipo de nó usado. A tabela a seguir mostra os valores padrão para os parâmetros `maxmemory`, `client-output-buffer-limit-slave-hard-limit` e `client-output-buffer-limit-slave-soft-limit` para cada tipo de nó. O valor de `maxmemory` é o número máximo de bytes disponíveis para uso, dados e outros usos no nó. Para obter mais informações, consulte [Available memory](https://aws.amazon.com/premiumsupport/knowledge-center/available-memory-elasticache-redis-node/) (Memória disponível).
**nota**
O parâmetro `maxmemory` não pode ser modificado.
| Tipo de nó | Maxmemory | C lient-output-buffer-limit - slave-hard-limit | C lient-output-buffer-limit - slave-soft-limit |
| --- | --- | --- | --- |
| cache.t1.micro | 142606336 | 14260633 | 14260633 |
| cache.t2.micro | 581959680 | 58195968 | 58195968 |
| cache.t2.small | 1665138688 | 166513868 | 166513868 |
| cache.t2.medium | 3461349376 | 346134937 | 346134937 |
| cache.t3.micro | 536870912 | 53687091 | 53687091 |
| cache.t3.small | 1471026299 | 147102629 | 147102629 |
| cache.t3.medium | 3317862236 | 331786223 | 331786223 |
| cache.t4g.micro | 536870912 | 53687091 | 53687091 |
| cache.t4g.small | 1471026299 | 147102629 | 147102629 |
| cache.t4g.medium | 3317862236 | 331786223 | 331786223 |
| cache.m1.small | 943718400 | 94371840 | 94371840 |
| cache.m1.medium | 3093299200 | 309329920 | 309329920 |
| cache.m1.large | 7025459200 | 702545920 | 702545920 |
| cache.m1.xlarge | 14889779200 | 1488977920 | 1488977920 |
| cache.m2.xlarge | 17091788800 | 1709178880 | 1709178880 |
| cache.m2.2xlarge | 35022438400 | 3502243840 | 3502243840 |
| cache.m2.4xlarge | 70883737600 | 7088373760 | 7088373760 |
| cache.m3.medium | 2988441600 | 309329920 | 309329920 |
| cache.m3.large | 6501171200 | 650117120 | 650117120 |
| cache.m3.xlarge | 14260633600 | 1426063360 | 1426063360 |
| cache.m3.2xlarge | 29989273600 | 2998927360 | 2998927360 |
| cache.m4.large | 6892593152 | 689259315 | 689259315 |
| cache.m4.xlarge | 15328501760 | 1532850176 | 1532850176 |
| cache.m4.2xlarge | 31889126359 | 3188912636 | 3188912636 |
| cache.m4.4xlarge | 65257290629 | 6525729063 | 6525729063 |
| cache.m4.10xlarge | 166047614239 | 16604761424 | 16604761424 |
| cache.m5.large | 6854542746 | 685454275 | 685454275 |
| cache.m5.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m5.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m5.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m5.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m5.24xlarge | 337500562842 | 33750056284 | 33750056284 |
| cache.m6g.large | 6854542746 | 685454275 | 685454275 |
| cache.m6g.xlarge | 13891921715 | 1389192172 | 1389192172 |
| cache.m6g.2xlarge | 27966669210 | 2796666921 | 2796666921 |
| cache.m6g.4xlarge | 56116178125 | 5611617812 | 5611617812 |
| cache.m6g.8xlarge | 111325552312 | 11132555231 | 11132555231 |
| cache.m6g.12xlarge | 168715971994 | 16871597199 | 16871597199 |
| cache.m6g.16xlarge | 225000375228 | 22500037523 | 22500037523 |
| cache.c1.xlarge | 6501171200 | 650117120 | 650117120 |
| cache.r3.large | 14470348800 | 1468006400 | 1468006400 |
| cache.r3.xlarge | 30513561600 | 3040870400 | 3040870400 |
| cache.r3.2xlarge | 62495129600 | 6081740800 | 6081740800 |
| cache.r3.4xlarge | 126458265600 | 12268339200 | 12268339200 |
| cache.r3.8xlarge | 254384537600 | 24536678400 | 24536678400 |
| cache.r4.large | 13201781556 | 1320178155 | 1320178155 |
| cache.r4.xlarge | 26898228839 | 2689822883 | 2689822883 |
| cache.r4.2xlarge | 54197537997 | 5419753799 | 5419753799 |
| cache.r4.4xlarge | 108858546586 | 10885854658 | 10885854658 |
| cache.r4.8xlarge | 218255432090 | 21825543209 | 21825543209 |
| cache.r4.16xlarge | 437021573120 | 43702157312 | 43702157312 |
| cache.r5.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r5.xlarge | 28261849702 | 2826184970 | 2826184970 |
| cache.r5.2xlarge | 56711183565 | 5671118356 | 5671118356 |
| cache.r5.4xlarge | 113609865216 | 11360986522 | 11360986522 |
| cache.r5.12xlarge | 341206346547 | 34120634655 | 34120634655 |
| cache.r5.24xlarge | 682485973811 | 68248597381 | 68248597381 |
| cache.r6g.large | 14037181030 | 1403718103 | 1403718103 |
| cache.r6g.xlarge | 28261849702 | 2826184970 | 2826184970 |
| 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**
Todos os tipos de instâncias da geração atual são criados em uma Amazon Virtual Private Cloud VPC por padrão.
As instâncias T1 não oferecem suporte a Multi-AZ.
As instâncias T1 e T2 não oferecem suporte ao AOF do Redis OSS.
As variáveis de configuração do Redis OSS `appendonly` e `appendfsync` não são compatíveis com o Redis OSS versão 2.8.22 e posteriores.
## Parâmetros específicos do Memcached
**Memcached**
Se você não especificar um parameter group para seu cluster Memcached, será usado um parameter group padrão apropriado. Não é possível alterar os valores de nenhum parâmetro em um grupo de parâmetros padrão. No entanto, é possível criar um grupo de parâmetros personalizado e atribui-lo ao cluster a qualquer momento. Para obter mais informações, consulte [Criação de um grupo de parâmetros do ElastiCache](ParameterGroups.Creating.md).
**Topics**
+ [Mudanças no Memcached 1.6.17](#ParameterGroups.Memcached.1.6.17)
+ [Parâmetros adicionados do Memcached 1.6.6](#ParameterGroups.Memcached.1-6-6)
+ [Alterações de parâmetros do Memcached 1.5.10](#ParameterGroups.Memcached.1-5-10)
+ [Parâmetros adicionados do Memcached 1.4.34](#ParameterGroups.Memcached.1-4-34)
+ [Parâmetros adicionados do Memcached 1.4.33](#ParameterGroups.Memcached.1-4-33)
+ [Parâmetros adicionados do Memcached 1.4.24](#ParameterGroups.Memcached.1-4-24)
+ [Parâmetros adicionados do Memcached 1.4.14](#ParameterGroups.Memcached.1-4-14)
+ [Parâmetros com suporte do Memcached 1.4.5](#ParameterGroups.Memcached.1-4-5)
+ [Sobrecarga de conexões do Memcached](#ParameterGroups.Memcached.Overhead)
+ [Parâmetros específicos do tipo de nó do Memcached](#ParameterGroups.Memcached.NodeSpecific)
### Mudanças no Memcached 1.6.17
A partir do Memcached 1.6.17, não oferecemos mais suporte a estes comandos administrativos: `lru_crawler`, `lru` e `slabs`. Com essas mudanças, você não poderá fazer isso enable/disable `lru_crawler` em tempo de execução por meio de comandos. enable/disable `lru_crawler`Por favor, modificando seu grupo de parâmetros personalizado.
### Parâmetros adicionados do Memcached 1.6.6
Para o Memcached 1.6.6, não há suporte para parâmetros adicionais.
**Família de grupos de parâmetros:** memcached1.6
### Alterações de parâmetros do Memcached 1.5.10
Para o Memcached 1.5.10, há suporte para os seguintes parâmetros adicionais.
**Família de parameter groups:** memcached1.5
| Nome | Detalhes | Description |
| --- | --- | --- |
| no\$1modern | Padrão: 1 Tipo: booliano Modificável: sim Valores permitidos: 0,1 As alterações terão efeito: na execução | Um alias para desabilitar comandos `slab_reassign`, `lru_maintainer_thread`, `lru_segmented` e `maxconns_fast`. Ao usar o Memcached 1.5 e posteriores, `no_modern` também define o hash\$1algorithm como `jenkins`. Além disso, ao usar o Memcached 1.5.10, `inline_ascii_reponse` é controlado pelo parâmetro `parallelly`. Isso significa que, se `no_modern` estiver desabilitado, `inline_ascii_reponse` estará desabilitado. Do mecanismo Memcached 1.5.16 em diante, o parâmetro `inline_ascii_response` não se aplica mais, portanto, `no_modern` estar habilitado ou desabilitado não tem efeito sobre `inline_ascii_reponse`. Se `no_modern` estiver desabilitado, então `slab_reassign`, `lru_maintainer_thread`, `lru_segmented` e `maxconns_fast` ESTARÃO habilitados. Como os parâmetros `slab_automove` e `hash_algorithm` não são parâmetros SWITCH, sua configuração é baseada nas configurações do grupo de parâmetros. Se você quiser desabilitar `no_modern` e reverter para `modern`, é preciso configurar um grupo de parâmetros personalizado para desabilitar esse parâmetro e, em seguida, reinicializar para que essas alterações entrem em vigor. O valor padrão de configuração para esse parâmetro foi alterado de 0 para 1 a partir de 20 de agosto de 2021. O valor padrão atualizado será automaticamente coletado por novos ElastiCache usuários em cada região após 20 de agosto de 2021. ElastiCache Os usuários existentes nas regiões antes de 20 de agosto de 2021 precisam modificar manualmente seus grupos de parâmetros personalizados para aceitar essa nova alteração. |
| inline\$1ascii\$1resp | Padrão: 0 Tipo: booliano Modificável: sim Valores permitidos: 0,1 As alterações terão efeito: na execução | Armazena números da resposta `VALUE`, dentro de um item, usando até 24 bytes. Pequena desaceleração para os conjuntos do ASCII `get`, `faster`. |
Para a versão 1.5.10 do Memcached, os parâmetros seguintes foram removidos.
| Nome | Detalhes | Description |
| --- | --- | --- |
| expirezero\$1does\$1not\$1evict | Padrão: 0 Tipo: booliano Modificável: sim Valores permitidos: 0,1 As alterações terão efeito: na execução | Não é mais compatível nesta versão. |
| modern | Padrão: 1 Tipo: booliano Modificável: sim (requer reinicialização se definido para `no_modern`) Valores permitidos: 0,1 As alterações terão efeito: na execução | Não é mais compatível nesta versão. A partir desta versão, o `no-modern` é ativado por padrão com cada inicialização ou reinicialização. |
### Parâmetros adicionados do Memcached 1.4.34
Para o Memcached 1.4.34, não há suporte para parâmetros adicionais.
**Família de parameter groups:** memcached1.4
### Parâmetros adicionados do Memcached 1.4.33
Para o Memcached 1.4.33, há suporte para os seguintes parâmetros adicionais.
**Família de parameter groups:** memcached1.4
| Nome | Detalhes | Description |
| --- | --- | --- |
| modern | Padrão: habilitado Tipo: booliano Modificável: sim As alterações terão efeito: na execução | Um alias para vários recursos. Habilitar `modern` equivale a ativar os seguintes comandos e usar um algoritmo de hash murmur3: `slab_reassign`, `slab_automove`, `lru_crawler`, `lru_maintainer`, `maxconns_fast` e `hash_algorithm=murmur3`. |
| watch | Padrão: habilitado Tipo: booliano Modificável: sim As alterações terão efeito: imediatamente Logs podem ser descartados se o usuário atingir seus limites de `watcher_logbuf_size` e `worker_logbuf_size`. | Buscas, remoções ou mutações de logs. Quando, por exemplo, o usuário ativa `watch`, ele pode ver logs quando ocorre `get`, `set`, `delete` ou `update`. |
| idle\$1timeout | Padrão: 0 (desabilitado) Tipo: inteiro Modificável: sim As alterações terão efeito: na execução | O número mínimo de segundos que um cliente terá permissão para ficar ocioso antes que o seu fechamento seja solicitado. Faixa de valores: 0 a 86400. |
| track\$1sizes | Padrão: desabilitado Tipo: booliano Modificável: sim As alterações terão efeito: na execução | Mostra os tamanhos que cada grupo de slabs consumiu. Habilitar `track_sizes` permite que você execute `stats sizes` sem a necessidade de executar `stats sizes_enable`. |
| watcher\$1logbuf\$1size | Padrão: 256 (KB) Tipo: inteiro Modificável: sim As alterações terão efeito: na execução | O comando `watch` ativa o registro em log de streams para o Memcached. No entanto, `watch` poderá descartar logs se a taxa de remoções, mutações ou buscas for alta o suficiente para fazer com que o buffer de registro em log fique cheio. Nessas situações, os usuários podem aumentar o tamanho do buffer para reduzir a chance de perdas de log. |
| worker\$1logbuf\$1size | Padrão: 64 (KB) Tipo: inteiro Modificável: sim As alterações terão efeito: na execução | O comando `watch` ativa o registro em log de streams para o Memcached. No entanto, `watch` poderá descartar logs se a taxa de remoções, mutações ou buscas for alta o suficiente para fazer com que o buffer de registro em log fique cheio. Nessas situações, os usuários podem aumentar o tamanho do buffer para reduzir a chance de perdas de log. |
| slab\$1chunk\$1max | Padrão: 524288 (bytes) Tipo: inteiro Modificável: sim As alterações terão efeito: na execução | Especifica o tamanho máximo de um slab. A configuração de tamanho de slab menor usa a memória de forma mais eficiente. Itens com mais de `slab_chunk_max` são divididos em vários slabs. |
| lru\$1crawler metadump [all\$11\$12\$13] | Padrão: desabilitado Tipo: booliano Modificável: sim As alterações terão efeito: imediatamente | se lru\$1crawler estiver habilitado, esse comando despejará todas as chaves. `all\|1\|2\|3` - todos os slab, ou especifique um número específico de slab |
### Parâmetros adicionados do Memcached 1.4.24
Para o Memcached 1.4.24, há suporte para os seguintes parâmetros adicionais.
**Família de parameter groups:** memcached1.4
| Nome | Detalhes | Description |
| --- | --- | --- |
| disable\$1flush\$1all | Padrão: 0 (desabilitado) Tipo: booliano Modificável: sim As alterações terão efeito: na execução | Adicione o parâmetro (`-F`) para desabilitar flush\$1all. Útil se você nunca quiser ser capaz de executar uma liberação total em instâncias de produção. Valores: 0, 1 (o usuário pode fazer `flush_all` quando o valor é 0). |
| hash\$1algorithm | Padrão: jenkins Tipo: string Modificável: sim As alterações terão efeito: na execução | O algoritmo de hash a ser usado. Valores permitidos: murmur3 e jenkins. |
| lru\$1crawler | Padrão: 0 (desabilitado) Tipo: booliano Modificável: sim As alterações terão efeito: após a reinicialização Você pode habilitar `lru_crawler` temporariamente em tempo de execução a partir da linha de comando. Para obter mais informações, consulte a coluna Descrição. | Limpa as classes de itens de slabs que expiraram. Este é um processo de baixo impacto que é executado em segundo plano. Atualmente, ele exige iniciar um rastreamento usando um comando manual. Para habilitar temporariamente, execute `lru_crawler enable` na linha de comando. `lru_crawler 1,3,5` rastreia as classes de slab 1, 3 e 5, procurando itens expirados para adicionar à lista livre. Valores: 0,1 Habilitar `lru_crawler` na linha de comando habilita o crawler até que ele seja desabilitado na linha de comando ou na próxima reinicialização. Para habilitar permanentemente, você deve modificar o valor do parâmetro. Para obter mais informações, consulte [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md). |
| lru\$1maintainer | Padrão: 0 (desabilitado) Tipo: booliano Modificável: sim As alterações terão efeito: na execução | Uma linha de fundo que embaralha os itens entre eles à LRUs medida que as capacidades são atingidas. Valores: 0, 1. |
| expirezero\$1does\$1not\$1evict | Padrão: 0 (desabilitado) Tipo: booliano Modificável: sim As alterações terão efeito: na execução | Quando usado com `lru_maintainer`, faz com que itens com um tempo de expiração de 0 não possam ser removidos. Isso pode lotar a memória disponível para outros itens removíveis. Pode ser configurado para desconsiderar `lru_maintainer`. |
### Parâmetros adicionados do Memcached 1.4.14
Para o Memcached 1.4.14, há suporte para os seguintes parâmetros adicionais.
**Família de parameter groups:** memcached1.4
**Parâmetros adicionados no Memcached 1.4.14**
| Nome | Detalhes | Description |
| --- | --- | --- |
| config\$1max | Padrão: 16 Tipo: inteiro Modificável: não | O número máximo de entradas de ElastiCache configuração. |
| config\$1size\$1max | Padrão: 65536 Tipo: inteiro Modificável: não | O tamanho máximo das entradas de configuração, em bytes. |
| hashpower\$1init | Padrão: 16 Tipo: inteiro Modificável: não | O tamanho inicial da tabela de ElastiCache hash, expresso como uma potência de dois. O padrão é 16 (2^16) ou 65536 chaves. |
| maxconns\$1fast | Padrão: 0 (false) Tipo: booliano Modificável: sim As alterações terão efeito: após a reinicialização | Altera o modo como novas solicitações de conexão são tratadas quando o limite máximo de conexão é atingido. Se esse parâmetro estiver definido como 0 (zero), novas conexões serão adicionadas à fila de backlog e aguardarão até que outras conexões sejam encerradas. Se o parâmetro for definido como 1, ElastiCache envia um erro ao cliente e fecha imediatamente a conexão. |
| slab\$1automove | Padrão: 0 Tipo: inteiro Modificável: sim As alterações terão efeito: após a reinicialização | Ajusta o algoritmo de movimentação automática de slabs: se esse parâmetro estiver definido como 0 (zero), o algoritmo de movimentação automática será desabilitado. Se estiver definido como 1, o ElastiCache usará uma abordagem lenta e conservadora para mover slabs automaticamente. Se estiver definido como 2, move ElastiCache agressivamente as placas sempre que houver um despejo. (Esse modo não é recomendado, exceto para fins de teste.) |
| slab\$1reassign | Padrão: 0 (false) Tipo: booliano Modificável: sim As alterações terão efeito: após a reinicialização | Habilite ou desabilite a reatribuição de slabs. Se esse parâmetro estiver definido como 1, você poderá usar o comando "slabs reassign" para reatribuir a memória manualmente. |
### Parâmetros com suporte do Memcached 1.4.5
**Família de parameter groups:** memcached1.4
Para o Memcached 1.4.5, há suporte para os seguintes parâmetros.
**Parâmetros adicionados no Memcached 1.4.5**
| Nome | Detalhes | Description |
| --- | --- | --- |
| backlog\$1queue\$1limit | Padrão: 1024 Tipo: inteiro Modificável: não | O limite de fila de backlog. |
| binding\$1protocol | Padrão: automático Tipo: string Modificável: sim As alterações terão efeito: após a reinicialização | O protocolo de associação. Os valores permitidos são: `ascii` e `auto`. Para obter orientação sobre como modificar o valor de `binding_protocol`, consulte [Modificação de um grupo de parâmetros do ElastiCache](ParameterGroups.Modifying.md). |
| cas\$1disabled | Padrão: 0 (false) Tipo: booliano Modificável: sim As alterações terão efeito: após a reinicialização | Se 1 (true), as operações Verificar e Definir (CAS) serão desabilitadas, e os itens armazenados consumirão 8 bytes a menos do que quando essas operações estão habilitadas. |
| chunk\$1size | Padrão: 48 Tipo: inteiro Modificável: sim As alterações terão efeito: após a reinicialização | O valor mínimo, em bytes, de espaço para alocar para a chave, o valor e os sinalizadores do menor item. |
| chunk\$1size\$1growth\$1factor | Padrão: 1.25 Tipo: flutuante Modificável: sim As alterações terão efeito: após a reinicialização | O fator de crescimento que controla o tamanho de cada bloco Memcached sucessivo; cada bloco será chunk\$1size\$1growth\$1factor vezes maior que o bloco anterior. |
| error\$1on\$1memory\$1exhausted | Padrão: 0 (false) Tipo: booliano Modificável: sim As alterações terão efeito: após a reinicialização | Se 1 (true), quando não há mais memória para armazenar itens, o Memcached retornará um erro em vez de remover itens. |
| large\$1memory\$1pages | Padrão: 0 (false) Tipo: booliano Modificável: não | Se 1 (verdadeiro), ElastiCache tentará usar páginas de memória grandes. |
| lock\$1down\$1paged\$1memory | Padrão: 0 (false) Tipo: booliano Modificável: não | Se 1 (verdadeiro), ElastiCache bloqueará toda a memória paginada. |
| max\$1item\$1size | Padrão: 1048576 Tipo: inteiro Modificável: sim As alterações terão efeito: após a reinicialização | O tamanho, em bytes, do maior item que pode ser armazenado no cluster. |
| max\$1simultaneous\$1connections | Padrão: 65000 Tipo: inteiro Modificável: não | O número máximo de conexões simultâneas. |
| maximize\$1core\$1file\$1limit | Padrão: 0 (false) Tipo: booliano Permite modificação: As alterações terão efeito: após a reinicialização | Se 1 (verdadeiro), ElastiCache maximizará o limite do arquivo principal. |
| memcached\$1connections\$1overhead | Padrão: 100 Tipo: inteiro Modificável: sim As alterações terão efeito: após a reinicialização | A quantidade de memória a ser reservada para conexões Memcached e outras sobrecargas diversas. Para obter informações sobre esse parâmetro, consulte [Sobrecarga de conexões do Memcached](#ParameterGroups.Memcached.Overhead). |
| requests\$1per\$1event | Padrão: 20 Tipo: inteiro Modificável: não | O número máximo de solicitações por evento para uma determinada conexão. Este limite é necessário para evitar o esgotamento de recursos. |
### Sobrecarga de conexões do Memcached
Em cada nó, a memória disponibilizada para armazenar itens é a memória total disponível nesse nó (que é armazenada no parâmetro `max_cache_memory`) menos a memória usada para conexões e outras sobrecargas (que é armazenada no parâmetro `memcached_connections_overhead`). Por exemplo, um nó do tipo `cache.m1.small` tem um `max_cache_memory` de 1300 MB. Com o valor padrão `memcached_connections_overhead` de 100 MB, o processo Memcached terá 1200 MB disponíveis para armazenar itens.
Os valores padrão para o parâmetro `memcached_connections_overhead` satisfazem a maioria dos casos de uso. No entanto, a quantidade necessária de alocação para sobrecarga de conexão pode variar dependendo de vários fatores, entre eles a taxa de solicitação, o tamanho da carga útil e o número de conexões.
Você pode alterar o valor de `memcached_connections_overhead` para melhor atender às necessidades do seu aplicativo. Por exemplo, aumentar o valor do parâmetro `memcached_connections_overhead` reduzirá a quantidade de memória disponível para armazenar itens e fornecerá um buffer maior para a sobrecarga de conexões. Diminuir o valor do parâmetro `memcached_connections_overhead` fornecerá mais memória para armazenar itens, mas pode aumentar seu risco de uso de permuta e desempenho degradado. Se você observar uso de permuta e desempenho degradado, tente aumentar o valor do parâmetro `memcached_connections_overhead`.
**Importante**
Para o tipo de nó `cache.t1.micro`, o valor para `memcached_connections_overhead` é determinado da seguinte forma:
Se o cluster estiver usando o grupo de parâmetros padrão, ElastiCache definirá o valor `memcached_connections_overhead` para 13 MB.
Se o seu cluster estiver usando um parameter group que você criou, será possível definir o valor de `memcached_connections_overhead` como um valor de sua escolha.
### Parâmetros específicos do tipo de nó do Memcached
Embora a maioria dos parâmetros tenha um valor único, alguns parâmetros têm valores diferentes dependendo do tipo de nó usado. A tabela a seguir mostra os valores padrão para os parâmetros `max_cache_memory` e `num_threads` para cada tipo de nó. Os valores nesses parâmetros não podem ser modificados.
| Tipo de nó | max\$1cache\$1memory (em megabytes) | 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**
Todas as instâncias T2 são criadas em uma Amazon Virtual Private Cloud (Amazon VPC).
# Conectar uma instância do EC2 e um cache do ElastiCache automaticamente
Você pode usar o console do ElastiCache para simplificar a configuração de uma conexão entre uma instância do Amazon Elastic Compute Cloud (Amazon EC2) e um cache do ElastiCache. Geralmente, seu cache está em uma sub-rede privada e sua instância do EC2 está em uma sub-rede pública em uma VPC. Você pode utilizar um cliente SQL em sua instância do EC2 para se conectar ao seu cache do ElastiCache. A instância do EC2 também pode executar servidores web ou aplicações que acessam seu cache privado do ElastiCache.
![\[Conectar automaticamente um cache do ElastiCache com uma instância do EC2.\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ec2-elasticache-connect-network_diagram.png)
**Topics**
+ [Conectividade automática com uma instância do EC2](#ec2-elc-connect-overview)
+ [Visualizar recursos computacionais conectados](#ec2-elc-connect-viewing)
## Conectividade automática com uma instância do EC2
Quando você configura uma conexão entre uma instância do EC2 e um cache do ElastiCache, o ElastiCache automaticamente configura o grupo de segurança da VPC para sua instância do EC2 e para seu cache do ElastiCache.
Confira a seguir os requisitos para conectar uma instância do EC2 ao cache do ElastiCache:
+ A instância do EC2 deve existir na mesma VPC do cache do ElastiCache.
Se não houver nenhuma instância do EC2 na mesma VPC, o console fornecerá um link para que você crie uma.
+ O usuário que configura a conectividade deve ter permissões para realizar as seguintes operações do Amazon EC2. Essas permissões geralmente são adicionadas às contas do EC2 quando elas são criadas. Para obter mais informações sobre permissões do EC2, consulte [Como conceder as permissões necessárias para os recursos do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/ec2-api-permissions.html).
+ `ec2:AuthorizeSecurityGroupEgress`
+ `ec2:AuthorizeSecurityGroupIngress`
+ `ec2:CreateSecurityGroup`
+ `ec2:DescribeInstances`
+ `ec2:DescribeNetworkInterfaces`
+ `ec2:DescribeSecurityGroups`
+ `ec2:ModifyNetworkInterfaceAttribute`
+ `ec2:RevokeSecurityGroupEgress`
Quando você configura uma conexão com uma instância do EC2, o ElastiCache atua de acordo com a configuração atual dos grupos de segurança associados ao cache do ElastiCache e à instância do EC2, conforme descrito na tabela a seguir.
****
| Configuração atual do grupo de segurança do ElastiCache | Configuração atual do grupo de segurança do EC2 | Ação do ElastiCache |
| --- | --- | --- |
| Há um ou mais grupos de segurança associados ao cache do ElastiCache com um nome correspondente ao padrão `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Um grupo de segurança que corresponde ao padrão não foi modificado. Esse grupo de segurança tem apenas uma regra de saída com o grupo de segurança da VPC da instância do EC2 como origem. | Há um ou mais grupos de segurança associados à instância do EC2 com um nome que corresponde ao padrão `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Um grupo de segurança que corresponde ao padrão não foi modificado. Esse grupo de segurança tem apenas uma regra de saída com o grupo de segurança da VPC do cache do ElastiCache como origem. | O ElastiCache não realiza nenhuma ação. Uma conexão já foi configurada automaticamente entre a instância do EC2 e o cache do ElastiCache. Como já existe uma conexão entre a instância do EC2 e o cache do ElastiCache, os grupos de segurança não são modificados. |
| Qualquer uma das seguintes condições se aplica: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/compute-connection.html) | Qualquer uma das seguintes condições se aplica: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/compute-connection.html) | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| Há um ou mais grupos de segurança associados ao cache do ElastiCache com um nome correspondente ao padrão `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Um grupo de segurança que corresponde ao padrão não foi modificado. Esse grupo de segurança tem apenas uma regra de saída com o grupo de segurança da VPC da instância do EC2 como origem. | Há um ou mais grupos de segurança associados à instância do EC2 com um nome que corresponde ao padrão `elasticache-ec2-${cacheId}:${ec2InstanceId}`. No entanto, o ElastiCache não pode usar nenhum desses grupos de segurança para a conexão com o cache do ElastiCache. O ElastiCache não pode usar um grupo de segurança que não tenha uma regra de saída no grupo de segurança da VPC do cache do ElastiCache como origem. O ElastiCache também não pode usar um grupo de segurança que tenha sido modificado. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
| Há um ou mais grupos de segurança associados ao cache do ElastiCache com um nome correspondente ao padrão `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Um grupo de segurança que corresponde ao padrão não foi modificado. Esse grupo de segurança tem apenas uma regra de saída com o grupo de segurança da VPC da instância do EC2 como origem. | Existe um grupo de segurança do EC2 válido para a conexão, mas ele não está associado à instância do EC2. Esse grupo de segurança tem um nome que corresponde ao padrão `ec2-elasticache-${ec2InstanceId}:${cacheId}`. Não foi modificado. Ele tem apenas uma regra de saída com o grupo de segurança da VPC do cache do ElastiCache como origem. | [ELC action: associate EC2 security group](#elc-action-associate-ec2-security-group) |
| Qualquer uma das seguintes condições se aplica: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/compute-connection.html) | Há um ou mais grupos de segurança associados à instância do EC2 com um nome que corresponde ao padrão `ec2-elasticache-${ec2InstanceId}:${cacheId}`. Um grupo de segurança que corresponde ao padrão não foi modificado. Esse grupo de segurança tem apenas uma regra de saída com o grupo de segurança da VPC do cache do ElastiCache como origem. | [ELC action: create new security groups](#elc-action-create-new-security-groups) |
**Ação do ElastiCache: criar novos grupos de segurança**
O ElastiCache realiza as seguintes ações:
+ Cria um grupo de segurança que corresponde ao padrão `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Esse grupo de segurança tem uma regra de entrada com o grupo de segurança da VPC da instância do EC2 como origem. Esse grupo de segurança está associado ao cache do ElastiCache e permite que a instância do EC2 o acesse.
+ Cria um grupo de segurança que corresponde ao padrão `elasticache-ec2-${cacheId}:${ec2InstanceId}`. Esse grupo de segurança tem uma regra de saída com o grupo de segurança da VPC do cache do ElastiCache como destino. Esse grupo de segurança está associado à instância do EC2 e permite que ela envie tráfego ao cache do ElastiCache.
**Ação do ElastiCache: associar o grupo de segurança do EC2**
O ElastiCache associa o grupo de segurança do EC2 existente e válido à instância do EC2. Esse grupo de segurança permite que a instância do EC2 envie tráfego ao cache do ElastiCache.
## Visualizar recursos computacionais conectados
Você pode usar o Console de gerenciamento da AWS para visualizar os recursos computacionais conectados a um cache do ElastiCache. Os recursos mostrados incluem conexões de recursos computacionais que foram configuradas automaticamente. Por exemplo, você pode permitir que um recurso computacional acesse um cache manualmente adicionando uma regra ao grupo de segurança da VPC associado ao cache. Esses recursos não aparecerão na lista de recursos computacionais conectados.
Para que um recurso computacional seja listado, as mesmas condições devem ser atendidas quando conectar automaticamente uma instância do EC2 e um cache do ElastiCache.
**Para visualizar recursos computacionais conectados a um cache do ElastiCache**
1. Faça login no Console de gerenciamento da AWS e abra o console do ElastiCache
1. No painel de navegação, escolha **Cache** e, em seguida, escolha um cache do Valkey ou Redis OSS.
1. Na guia **Connectivity & security** (Conectividade e segurança), veja os recursos computacionais em **Set up compute connection** (Configurar conexão de computação).
![\[Recursos computacionais conectados.\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ec2-elasticache-connected_resources.png)
# Dimensionamento ElastiCache
Você pode escalar seu ElastiCache cache para atender às suas necessidades. Caches com tecnologia sem servidor e clusters baseados em nós oferecem várias opções de escalabilidade diferentes.
## Dimensionamento sem servidor ElastiCache
ElastiCache O Serverless acomoda automaticamente seu tráfego de carga de trabalho à medida que ele aumenta ou diminui. Para cada cache ElastiCache sem servidor, rastreia ElastiCache continuamente a utilização de recursos como CPU, memória e rede. Quando qualquer um desses recursos está restrito, o ElastiCache Serverless se expande adicionando um novo fragmento e redistribuindo os dados ao novo fragmento, sem nenhum tempo de inatividade para seu aplicativo. Você pode monitorar os recursos consumidos pelo seu cache CloudWatch monitorando a `BytesUsedForCache` métrica para armazenamento de dados em cache e `ElastiCacheProcessingUnits` (ECPU) para uso de computação.
## Definição dos limites de escalabilidade para gerenciar custos
Você pode optar por configurar um uso máximo no armazenamento de dados em cache e no seu cache ECPU/second para controlar os custos do cache. Isso vai garantir que o uso do cache jamais exceda o máximo configurado.
Se você definir uma escala máxima, a aplicação pode apresentar um desempenho de cache reduzido quando o cache atinge o máximo. Quando você define um máximo de armazenamento de dados em cache e seu armazenamento de dados em cache atinge o máximo, ElastiCache começará a despejar dados em seu cache que tenham um Time-To-Live (TTL) definido, usando a lógica LRU. Se não houver dados que possam ser removidos, as solicitações de gravação de dados adicionais receberão uma mensagem de erro de falta de memória (OOM). Quando você define um ECPU/second máximo e a utilização computacional de sua carga de trabalho excede esse valor, ElastiCache começará a limitar as solicitações.
Se você configurar um limite máximo em `BytesUsedForCache` ou`ElastiCacheProcessingUnits`, é altamente recomendável configurar um CloudWatch alarme com um valor inferior ao limite máximo para que você seja notificado quando seu cache estiver operando perto desses limites. É recomendável definir um alarme em 75% do limite máximo definido. Consulte a documentação sobre como configurar CloudWatch alarmes.
## Pré-escalonamento com Serverless ElastiCache
**ElastiCache Pré-escalonamento sem servidor**
Com o pré-escalonamento, também chamado de pré-aquecimento, você pode definir limites mínimos suportados para seu cache. ElastiCache Você pode definir esses mínimos para unidades ElastiCache de processamento (ECPUs) por segundo ou armazenamento de dados. Isso pode ser útil na preparação para eventos de escalonamento previstos. Por exemplo, se uma empresa de jogos espera um aumento de 5 vezes nos logins no primeiro minuto de lançamento do novo jogo, ela pode preparar seu cache para esse aumento significativo no uso.
Você pode realizar o pré-escalonamento usando o ElastiCache console, a CLI ou a API. ElastiCache O Serverless atualiza o que está disponível ECPUs/second no cache em 60 minutos e envia uma notificação de evento quando a atualização do limite mínimo é concluída.
**Como funciona a pré-escalabilidade**
Quando o limite mínimo ECPUs/second ou o armazenamento de dados são atualizados por meio do console, da CLI ou da API, esse novo limite fica disponível em 1 hora. ElastiCache O Serverless suporta 30K ECPUs/second em um cache vazio e até 90K ECPUs/sec ao usar o recurso Ler da réplica. ElastiCache O Serverless for Valkey 8.0 pode dobrar as solicitações suportadas por segundo (RPS) a cada 2-3 minutos, atingindo 5 milhões de RPS por cache de zero em menos de 13 minutos, com latência de leitura p50 consistente abaixo de um milissegundo. Se você prevê que um próximo evento de escalabilidade possa exceder essa taxa, recomendamos definir o mínimo ECPUs/second para o pico ECPUs/sec esperado pelo menos 60 minutos antes do evento de pico. Caso contrário, o aplicativo poderá apresentar latência elevada e limitação de solicitações.
Quando a atualização do limite mínimo for concluída, o ElastiCache Serverless começará a medir o novo mínimo ECPUs por segundo ou o novo armazenamento mínimo. Isso ocorre mesmo se o aplicativo não estiver executando solicitações no cache ou se o uso do armazenamento de dados estiver abaixo do mínimo. Quando você reduz o limite mínimo da configuração atual, a atualização é imediata, então o ElastiCache Serverless começará a medir o novo limite mínimo imediatamente.
**nota**
Ao definir um limite mínimo de uso, você é cobrado por esse limite, mesmo que seu uso real seja menor que o limite mínimo de uso. O uso de ECPU ou armazenamento de dados que exceda o limite mínimo de uso é cobrado de acordo com a taxa normal. Por exemplo, se você definir um limite mínimo de uso de 100.000 ECPUs/second , será cobrado pelo menos 1,224 USD por hora (usando os preços de ECPU em us-east-1), mesmo que seu uso seja inferior ao mínimo definido.
ElastiCache O Serverless suporta a escala mínima solicitada em um nível agregado no cache. ElastiCache O Serverless também suporta um máximo de 30K ECPUs/second por slot (90K ECPUs/second ao usar Read from Replica usando conexões READONLY). Como prática recomendada, seu aplicativo deve garantir que a distribuição de chaves nos slots Valkey ou Redis OSS e o tráfego entre chaves sejam o mais uniformes possível.
## Definindo limites de escala usando o console e AWS CLI
*Definindo limites de escala usando o console AWS*
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha o mecanismo em execução no cache que você deseja modificar.
1. É exibida uma lista de caches que executam o mecanismo escolhido.
1. Escolha o cache a ser modificado selecionando o botão de opção à esquerda do nome do cache.
1. Escolha **Ações** e **Modificar**.
1. Em **Limites de uso**, defina os limites de **Memória** ou **Computar** adequados.
1. Clique em **Previsualizar alterações** e em **Salvar alterações**.
**Definindo limites de escala usando o AWS CLI**
Para alterar os limites de escalabilidade usando a CLI, use modify-serverless-cache a API.
**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}'
```
**Remoção dos limites de escala usando a CLI**
Para remover limites de escala usando a CLI, defina os parâmetros de limite mínimo e máximo como 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}'
```
# Dimensionamento de clusters baseados em nós
A quantidade de dados que o seu aplicativo precisa processar é raramente estática. Ela aumenta e diminui à medida que sua empresa cresce ou passa por flutuações normais na demanda. Se você gerenciar automaticamente seu cache, você precisará provisionar hardware suficiente para seus picos de demanda, o que pode ser caro. Ao usar a Amazon, ElastiCache você pode escalar para atender à demanda atual, pagando somente pelo que você usa. ElastiCache permite que você escale seu cache para atender à demanda.
**nota**
Se um cluster Valkey ou Redis OSS for replicado em uma ou mais regiões, essas regiões serão escalonadas em ordem. Ao aumentar a escala verticalmente, as regiões secundárias são dimensionadas primeiro e depois a região primária. Ao reduzir a escala verticalmente, a região primária é a primeira e, em seguida, todas as regiões secundárias.
Ao atualizar a versão do mecanismo, a ordem é Região secundária e, em seguida, Região primária.
**Topics**
+ [Escalar sob demanda clusters para o Memcached](Scaling-self-designed.mem-heading.md)
+ [Escalabilidade manual para clusters do Memcached](Scaling.Memcached.manually.md)
+ [Escalonamento para Valkey ou Redis OSS (modo cluster desabilitado)](scaling-redis-classic.md)
+ [Escalar nós de réplica para Valkey ou Redis OSS (modo cluster desativado)](Scaling.RedisReplGrps.md)
+ [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md)
# Escalar sob demanda clusters para o Memcached
ElastiCache for Memcached oferece um serviço de cache em memória totalmente gerenciado que implanta, opera e escala verticalmente o Memcached na nuvem.AWS
**Escalabilidade vertical sob demanda**
Com o escalonamento vertical, o ElastiCache for Memcached fornece um sistema de cache de memória distribuído de alto desempenho, amplamente usado para acelerar aplicativos dinâmicos, aliviando a carga do banco de dados. Ele armazena dados e objetos na RAM, reduzindo a necessidade de leitura de fontes de dados externas.
Você pode aplicar a escalabilidade vertical aos clusters existentes baseados em nós, bem como aos novos. Essa ação pode proporcionar mais flexibilidade na alocação de recursos, permitindo que os usuários se adaptem com eficiência às mudanças nas workloads sem alterar a arquitetura do cluster. Essa capacidade de escalar melhora o desempenho aumentando a capacidade do cache durante os períodos de alta demanda e diminuindo a escala para otimizar os custos durante os períodos de baixa demanda. Isso simplifica as operações, elimina a necessidade de criar novos clusters para mudar os requisitos de recursos e permite respostas rápidas às flutuações do tráfego. No geral, a escalabilidade vertical para clusters baseados em nós do Memcached pode ajudar a aumentar a eficiência de custos, melhorar a utilização de recursos e até mesmo permitir que os usuários alterem o tipo de instância do Memcached. Tudo isso facilitando que os usuários alinhem sua infraestrutura de cache às necessidades reais do aplicativo.
**nota**
As modificações do tipo de nó só estão disponíveis para clusters do Memcached baseados em nós com as versões 1.5 ou posteriores do mecanismo.
O Auto Discovery deve ser habilitado para que seja possível usar a escalabilidade vertical.
## Configuração da escalabilidade vertical sob demanda para clusters do Memcached baseados em nós
Você pode configurar a escalabilidade vertical sob demanda para o Memcached com `scale-config`, que contém dois parâmetros:
1. **ScaleIntervalMinutes:** Tempo (em minutos) entre os lotes de escalabilidade durante o processo de atualização do Memcached
1. **ScalePercentage:** Porcentagem de nós a serem escalados simultaneamente durante o processo de atualização do Memcached
**Convertendo um tipo de nó existente do Memcached em um cache que pode ser escalado verticalmente por meio da CLI**
Para converter um cluster existente baseado em nós do Memcached em um cache que pode ser escalado verticalmente, você pode usar `elasticache modify-cache-cluster` por meio da CLI.
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config \
--apply-immediately
```
**Configuração da escalabilidade vertical com a CLI**
Para configurar a escalabilidade vertical para um cluster Memcached baseado em nós por meio da CLI, use `elasticache modify-cache-cluster` com `scale-config` e seus parâmetros `ScalePercentage` e `ScaleIntervalMinutes`.
+ **scale-interval-minutes:** isso define o tempo (em minutos) entre os lotes de escalonamento. Essa configuração pode variar de 2 a 30 minutos. Se nenhum valor for especificado, será aplicado o valor padrão de 5 minutos.
+ **porcentagem de escala:** especifica a porcentagem de nós a serem escalados simultaneamente em cada lote. Essa configuração pode variar de 10 a 100. A configuração é arredondada ao dividir. Por exemplo, se o resultado for 49,5, será aplicada uma configuração de 50. Se nenhum valor for especificado, será aplicado o valor padrão de 20.
Essas opções de configuração permitirão que você ajuste o processo de escalabilidade de acordo com suas necessidades específicas, equilibrando entre minimizar a interrupção do cluster e otimizar a velocidade de escalabilidade. O parâmetro scale-config será aplicável somente aos tipos de mecanismos Memcached e será ignorado para outros mecanismos de cache, garantindo compatibilidade com versões anteriores do uso atual da API em outros clusters.
**Chamada de API**
```
aws elasticache modify-cache-cluster \
--cache-cluster-id \
--cache-node-type \
--scale-config '{
"ScalePercentage": 30,
"ScaleIntervalMinutes": 2
}'
--apply-immediately
```
**Resultado:**
Retorna o ID do cluster e a alteração pendente.
```
{
"CacheCluster": {
"CacheNodeType": "old_insance_type",
...
...
"PendingModifiedValues": {
"CacheNodeType": "new_instance_type"
},
}
}
```
**Listar sua configuração de escalabilidade vertical do cache do Memcached**
Você pode recuperar as opções de escalabilidade para os caches do Memcached e ver quais são as opções atuais para a escalabilidade vertical.
**Chamada de API**
```
aws elasticache list-allowed-node-type-modifications --cache-cluster-id
```
**Resultado:**
```
{
"ScaleUpModifications": [
"cache.x.xxxx",
"cache.x.xxxx"
],
"ScaleDownModifications": [
"cache.x.xxxx",
"cache.x.xxxx",
"cache.x.xxxx"
]
}
```
**Dimensionamento vertical para Memcached com o Console de gerenciamento da AWS**
Siga estas etapas para usar o Console de gerenciamento da AWS para converter um cluster Memcached baseado em nós em um cluster escalável verticalmente.
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Selecione o cluster do Memcached a ser convertido.
1. Selecione a guia **Modify (Modificar)**.
1. Vá até a seção **Configurações de cache** e selecione o **tipo de nó** desejado.
1. Selecione **Visualizar alterações** e revise as alterações.
1. Selecione **Modify**.
## Escalabilidade horizontal automatizada para Memcached
ElastiCache agora se integra ao serviço AWS Application Auto Scaling (AAS) para incluir escalabilidade horizontal automatizada para clusters Memcached. Você pode definir políticas de escalabilidade por meio do serviço AWS Application Auto Scaling e ajustar automaticamente o número de nós nos clusters do Memcached conforme necessário, com base em métricas ou cronogramas predefinidos.
**nota**
No momento, a escalabilidade horizontal automatizada não está disponível nas regiões Pequim e Ningxia.
Esses são os métodos disponíveis para escalar horizontal e automaticamente seus clusters baseados em nós.
+ **Escalabilidade programada:** a escalabilidade com base em uma programação permite que você defina sua própria programação de escalabilidade para alterações de carga previsíveis. Por exemplo, toda semana o tráfego para seu aplicativo web começa a aumentar na quarta-feira, permanece alto na quinta-feira e começa a diminuir na sexta-feira. É possível configurar o recurso Auto Scaling para aumentar a capacidade na quarta-feira e diminuir a capacidade na sexta-feira.
+ **Monitoramento do objetivo:** com as políticas de dimensionamento com monitoramento do objetivo, você seleciona uma métrica de escalabilidade e define um valor pretendido. O Application Auto Scaling cria e gerencia os CloudWatch alarmes que acionam a política de escalabilidade e calcula o ajuste de escalabilidade com base na métrica e no valor alvo. A política de escalabilidade adiciona ou remove capacidade conforme necessário para manter a métrica no valor de destino especificado ou próxima a ele.
**Como configurar a escalabilidade horizontal para um cluster Memcached baseado em nós por meio da CLI**
Ao escalar horizontalmente um cluster do Memcached baseado em nós, você pode usar uma política de monitoramento do objetivo, uma política programada ou ambas.
1. **Registre um recurso como alvo escalável**
Chame a `RegisterScalableTarget` API no AWS Application Auto Scaling para registrar o destino da dimensão escalável. `elasticache:cache-cluster:Nodes`
**API: ApplicationAutoScaling. RegisterScalableTarget**
Entrada:
```
{
"ScalableDimension": "elasticache:cache-cluster:Nodes",
"ResourceId": "cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"MinCapacity": 20,
"MaxCapacity": 50
}
```
1. **Criar uma política de escalabilidade com monitoramento do objetivo**
Em seguida, você pode criar uma política de escalabilidade de rastreamento do objetivo para o recurso chamando a API put scaling policy.
1. **Métrica pré-definida**
A seguir está uma política que se expande de acordo com a dimensão do nó de cache, usando a métrica predefinida ` ElastiCacheCPUUtilization`, definida como 50 para o cluster test-cluster-1. Ao excluir nós para aumentar a escala, os últimos n nós serão removidos.
API: ApplicationAutoScaling. PutScalingPolicy
Entrada:
```
{
"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"
}
```
Saída:
```
{
"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. **Métrica personalizada**
Também é possível definir uma política de escalabilidade por dimensão usando uma porcentagem personalizada baseada na métrica do Cloudwatch.
Entrada:
```
{
"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. **Ações programadas**
Quando precisar aumentar a escala horizontalmente para um evento específico e depois reduzir a escala horizontalmente depois do evento, você pode criar duas ações agendadas chamando a API `PutScheduledAction`.
**Política 1: aumentar a escala horizontalmente**
O comando `at` em `--schedule` programa a ação para ser executada uma vez em uma data e hora especificadas no futuro. O campo de programação também é compatível com taxa (minuto, hora, dia etc.) e cron (para expressão cron).
Na data e hora especificadas, o Application Auto Scaling atualiza os valores `MinCapacity` e `MaxCapacity`. O Application Auto Scaling se expande MinCapacity para colocar os nós de cache em 70.
**API: ApplicationAutoScaling. PutScheduledAction**
Entrada:
```
{
"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",
}
```
**Política 2: Reduzir a escala horizontalmente**
Na data e hora especificadas, o Application Auto Scaling atualiza a `MinCapacity` e a `MaxCapacity` da tabela e reduz a escala na horizontal para `MaxCapacity`, para retornar os nós de cache para 60.
**API: ApplicationAutoScaling. PutScheduledAction**
Entrada:
```
{
"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. **Visualizar as atividades de escalabilidade**
Você pode visualizar as atividades de escalabilidade usando a API `DescribeScalingActivities`.
**API: ApplicationAutoScaling. DescribeScalingActivities**
Saída:
```
{
"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. **Editar/excluir política de escalabilidade**
Você pode editar ou excluir políticas chamando a API `PutScalingPolicy` novamente ou chamando a ação `DeleteScalingPolicy` ou `DeleteScheduled`.
1. **Cancelar registro de destinos dimensionáveis**
Você pode cancelar o registro de destinos dimensionáveis por meio da API `DeregisterScalableTarget`. O cancelamento do registro de um destino dimensionável exclui as políticas de escalabilidade e as ações programadas associadas a ele.
**API: ApplicationAutoScaling. DeregisterScalableTarget**
Entrada:
```
{
"ResourceId": "elasticache/cache-cluster/test-cluster-1",
"ServiceNamespace": "elasticache",
"ScalableDimension": "elasticache:cache-cluster:Nodes"
}
```
1. **Limpeza de políticas de escalabilidade**
1. **Várias políticas de escalabilidade**
Você pode criar várias políticas de escalabilidade. A seguir estão os principais textos explicativos sobre o comportamento do [rastreamento de destinos do Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html).
+ Você pode ter várias políticas de escalabilidade de rastreamento de destino para um destino escalável, desde que cada uma delas use uma métrica diferente.
+ A intenção do Application Auto Scaling é sempre priorizar a disponibilidade, portanto, seu comportamento será diferente dependendo se as políticas de monitoramento do objetivo estão prontas para aumentar ou reduzir a escala. Ele vai expandir o destino dimensionável se qualquer uma das políticas de rastreamento de destino estiverem prontas para expandir, mas vai reduzir somente se todas as políticas de rastreamento de destino (com a parte de redução habilitada) estiverem prontas para reduzir
+ Se várias políticas instruírem o destino escalável a expandir ou reduzir ao mesmo tempo, o Application Auto Scaling fará a escalabilidade com base na política que fornece a maior capacidade tanto para expandir como para reduzir. Isso oferece maior flexibilidade para cobrir vários cenários e garante que sempre haja capacidade suficiente para processar suas cargas de trabalho de aplicativos.
**nota**
AWS O Application Auto Scaling não coloca políticas de escalabilidade em fila. O Application Auto Scaling aguardará a conclusão do primeiro escalonamento, depois esfriará e repetirá o algoritmo acima.
**Dimensione horizontalmente automaticamente um cluster Memcached baseado em nós por meio do Console de gerenciamento da AWS**
Siga estas etapas para usar o Console de gerenciamento da AWS para converter um cluster Memcached existente baseado em nós em um cluster escalável horizontalmente.
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Selecione o cache do Memcached a ser convertido.
1. Acesse a guia **Autoscaling (Escalonamento automático)**.
1. Selecione a política de escalabilidade a ser aplicada selecionando **Add dynamic scaling (Adicionar escalabilidade dinâmica)** ou **Add scheduled scaling (Adicionar escalabilidade programada)**.
1. Preencha os detalhes da política selecionada conforme o necessário.
1. Clique em **Criar**.
# Escalabilidade manual para clusters do Memcached
Escalar horizontal ou verticalmente um cluster do Memcached é tão fácil quanto adicionar ou remover nós do cluster. Os clusters do Memcached são compostos de 1 a 60 nós.
Como você pode particionar seus dados em todos os nós em um cluster Memcached, raramente é necessário expandir para um tipo de nó com mais memória. No entanto, como o mecanismo Memcached não mantém a persistência de dados, se você dimensionar um tipo de nó diferente, seu novo cluster Memcached começará vazio, a menos que seu aplicativo o preencha.
Crie um novo cluster para escalabilidade manual e vertical do cluster do Memcached. Os clusters Memcached sempre começam vazios, a menos que seu aplicativo o preencha.
**Escalar manualmente clusters do Memcached**
| Ação | Tópico |
| --- | --- |
| Aumento de escala | [Adição de nós a um cluster](Clusters.html#AddNode) |
| Redução de escala | [Exclusão de nós de um cluster](Clusters.html#DeleteNode) |
| Alteração nos tipos de nó | [Escalar manual e verticalmente clusters do Memcached baseados em nós](#Scaling.Memcached.Vertically) |
**Topics**
+ [Escalar manualmente um cluster do Memcached baseado em nós horizontalmente](#Scaling.Memcached.Horizontally)
+ [Escalar manual e verticalmente clusters do Memcached baseados em nós](#Scaling.Memcached.Vertically)
## Escalar manualmente um cluster do Memcached baseado em nós horizontalmente
O mecanismo Memcached oferece suporte para particionar seus dados em vários nós. Por isso, os clusters Memcached escalam horizontalmente com facilidade. Para dimensionar horizontalmente seu cluster Memcached, basta adicionar ou remover nós.
Os tópicos a seguir detalham como escalar seu cluster Memcached inserindo ou removendo nós.
+ [Adição de nós a um cluster](Clusters.html#AddNode)
+ [Exclusão de nós do cluster](Clusters.html#AddNode)
Cada vez que você altera o número de nós no seu cluster Memcached, você deve remapear pelo menos alguns dos seus espaços de chaves para que ele seja mapeado para o nó correto. Para obter informações mais detalhadas sobre o balanceamento de carga do cluster Memcached, consulte [Configurando seu ElastiCache cliente para balanceamento de carga eficiente (Memcached)](BestPractices.LoadBalancing.md).
Se você usar a descoberta automática no seu cluster Memcached, não precisará alterar os endpoints em seu aplicativo à medida que você adiciona ou remove nós. Para obter mais informações sobre a descoberta automática, consulte [Identificar automaticamente nós no seu cluster (Memcached)](AutoDiscovery.md) Se você não usar a descoberta automática, cada vez que você alterar o número de nós no seu cluster Memcached, deverá atualizar os endpoints no seu aplicativo.
## Escalar manual e verticalmente clusters do Memcached baseados em nós
Quando você escala ou reduz seu cluster Memcached manualmente, deve criar um novo cluster. Os clusters Memcached sempre começam vazios, a menos que seu aplicativo o preencha.
**Importante**
Se você estiver dimensionando para um tipo de nó menor, certifique-se de que o tipo de nó menor seja adequado para seus dados e despesas gerais. Para obter mais informações, consulte [Escolha do tamanho do nó](CacheNodes.SelectSize.md).
**Topics**
+ [Escalar verticalmente um cluster do Memcached baseado em nós (console)](#Scaling.Memcached.Vertically.CON)
+ [Escalar verticalmente um cluster do Memcached baseado em nós (AWS CLI)](#Scaling.Memcached.Vertically.CLI)
+ [Dimensionando verticalmente um cluster Memcached baseado em nós (API) ElastiCache](#Scaling.Memcached.Vertically.API)
### Escalar verticalmente um cluster do Memcached baseado em nós (console)
O procedimento a seguir demonstra passo a passo como escalar um cluster do Memcached baseado em nós verticalmente usando o Console de gerenciamento da AWS.
1. Crie um novo cluster com o novo tipo de nó. Para obter mais informações, consulte [Criação de um cluster do Memcached (console)](Clusters.Create-mc.md#Clusters.Create.CON.Memcached).
1. No seu aplicativo, atualize os endpoints para os endpoints do novo cluster. Para obter mais informações, consulte [Localização de endpoints de um cluster (console) (Memcached)](Endpoints.md#Endpoints.Find.Memcached).
1. Exclua o cluster antigo. Para obter mais informações, consulte [Deleting a new node in Memcached](Clusters.html#Delete.CON.Memcached).
### Escalar verticalmente um cluster do Memcached baseado em nós (AWS CLI)
O procedimento a seguir demonstra passo a passo como escalar um cluster do Memcached baseado em nós verticalmente usando o AWS CLI.
1. Crie um novo cluster com o novo tipo de nó. Para obter mais informações, consulte [Criar um cluster (AWS CLI)](Clusters.Create.md#Clusters.Create.CLI).
1. No seu aplicativo, atualize os endpoints para os endpoints do novo cluster. Para obter mais informações, consulte [Localizar endpoints (AWS CLI)](Endpoints.md#Endpoints.Find.CLI).
1. Exclua o cluster antigo. Para obter mais informações, consulte [Usando o AWS CLI para excluir um ElastiCache cluster](Clusters.Delete.md#Clusters.Delete.CLI).
### Dimensionando verticalmente um cluster Memcached baseado em nós (API) ElastiCache
O procedimento a seguir mostra como escalar verticalmente um cluster Memcached baseado em nós usando a API. ElastiCache
1. Crie um novo cluster com o novo tipo de nó. Para obter mais informações, consulte [Criação de um cluster para Memcached (API) ElastiCache](Clusters.Create-mc.md#Clusters.Create.API.mem-heading).
1. No seu aplicativo, atualize os endpoints para os endpoints do novo cluster. Para obter mais informações, consulte [Localização de endpoints (API do ElastiCache)](Endpoints.md#Endpoints.Find.API).
1. Exclua o cluster antigo. Para obter mais informações, consulte [Usando a ElastiCache API](Clusters.Delete.md#Clusters.Delete.API).
# Escalonamento para Valkey ou Redis OSS (modo cluster desabilitado)
Os clusters do Valkey ou Redis OSS (modo cluster desabilitado) podem ser um cluster de nó único com 0 fragmentos ou clusters de vários nós com 1 fragmento. Os clusters de nó único usam esse único nó para leituras e gravações. Clusters de vários nós sempre têm 1 nó como nó read/write principal com 0 a 5 nós de réplica somente para leitura.
**Topics**
+ [Escalonamento para Valkey ou Redis OSS (modo cluster desabilitado)](#Scaling.RedisStandalone)
**Escalonamento de clusters Valkey ou Redis OSS**
| Ação | Valkey ou Redis OSS (modo cluster desabilitado) | Valkey ou Redis OSS (modo cluster habilitado) |
| --- | --- | --- |
| Redução de escala | [Removendo nós de um ElastiCache cluster](Clusters.DeleteNode.md) | [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md) |
| Aumento de escala | [Adição de nós a um cluster](Clusters.html#AddNode) | [Refragmentação online para o Valkey ou o Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) |
| Alteração nos tipos de nó | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/scaling-redis-classic.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/scaling-redis-classic.html) | [Escalabilidade vertical online com modificação do tipo de nó](redis-cluster-vertical-scaling.md) |
| Alteração do número de grupos de nós | Não há suporte para clusters do Valkey ou Redis OSS (modo cluster desabilitado) | [Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md) |
**Contents**
+ [Escalonamento para Valkey ou Redis OSS (modo cluster desabilitado)](#Scaling.RedisStandalone)
+ [Aumento de escala vertical de clusters do Valkey ou Redis OSS de nó único](#Scaling.RedisStandalone.ScaleUp)
+ [Aumento de escala vertical de clusters de nó único do Valkey ou Redis OSS (modo cluster desabilitado) (console)](#Scaling.RedisStandalone.ScaleUp.CON)
+ [Aumento de escala vertical de clusters do Valkey ou Redis OSS de nó único (AWS CLI)](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Escalando clusters OSS (API) Valkey ou Redis de nó único ElastiCache](#Scaling.RedisStandalone.ScaleUp.API)
+ [Redução de escala vertical de clusters do Valkey ou Redis OSS de nó único](#Scaling.RedisStandalone.ScaleDown)
+ [Redução de escala vertical de um cluster do Valkey ou Redis OSS de nó único (console)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [Redução de escala vertical de clusters do Valkey ou Redis OSS de nó único (AWS CLI)](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [Reduzindo a escala de clusters Valkey ou Redis OSS (API) de nó único ElastiCache](#Scaling.RedisStandalone.ScaleDown.API)
## Escalonamento para Valkey ou Redis OSS (modo cluster desabilitado)
Nós do Valkey ou Redis OSS (modo cluster desabilitado) devem ser suficientemente grandes para conter todos os dados do cache mais a sobrecarga do Valkey ou Redis OSS. Para alterar a capacidade de dados do seu cluster do Valkey ou Redis OSS (modo cluster desabilitado), você deve escalar verticalmente, aumentando a escala verticalmente para um tipo de nó maior para aumentar a capacidade de dados ou reduzindo para um tipo de nó menor para diminuir a capacidade de dados.
O processo ElastiCache de escalabilidade foi projetado para fazer o melhor esforço para reter seus dados existentes e requer uma replicação bem-sucedida do Valkey ou do Redis OSS. Para clusters do Valkey ou Redis OSS (modo de cluster desabilitado), recomendamos que seja disponibilizada memória suficiente para o Valkey ou Redis OSS.
Não é possível particionar seus dados em vários clusters Valkey ou Redis OSS (modo cluster desabilitado). No entanto, se você só precisa aumentar ou diminuir a capacidade de leitura do seu cluster, pode criar um cluster do Valkey ou Redis OSS (modo cluster desabilitado) com nós de réplica e adicionar ou remover réplicas de leitura. Para criar um cluster do Valkey ou Redis OSS (modo cluster desabilitado) com nós de réplica usando seu cluster Valkey ou Redis OSS de um único nó como cluster primário, consulte [Criação de um cluster do Valkey (modo cluster desabilitado) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs).
Depois de criar o cluster com réplicas, você pode aumentar a capacidade de leitura adicionando réplicas de leitura. Mais tarde, se precisar, você pode reduzir a capacidade de leitura removendo réplicas de leitura. Para acessar mais informações, consulte [Aumento da capacidade de leitura](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleOut) ou [Redução da capacidade de leitura](Scaling.RedisReplGrps.md#Scaling.RedisReplGrps.ScaleIn).
Além de poderem escalonar a capacidade de leitura, clusters do Valkey ou Redis OSS (modo cluster desabilitado) com réplicas fornecem outras vantagens comerciais. Para obter mais informações, consulte [Alta disponibilidade com o uso de grupos de replicação](Replication.md).
**Importante**
Se o seu parameter group usar `reserved-memory` para reservar a memória para a sobrecarga do Valkey ou Redis OSS, antes de iniciar a escalabilidade, certifique-se de ter um parameter group personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Como alternativa, você pode modificar um parameter group personalizado para que ele use `reserved-memory-percent` e usar esse parameter group para seu novo cluster.
Se você estiver usando `reserved-memory-percent`, não será necessário fazer isso.
Para obter mais informações, consulte [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md).
**Topics**
+ [Aumento de escala vertical de clusters do Valkey ou Redis OSS de nó único](#Scaling.RedisStandalone.ScaleUp)
+ [Redução de escala vertical de clusters do Valkey ou Redis OSS de nó único](#Scaling.RedisStandalone.ScaleDown)
### Aumento de escala vertical de clusters do Valkey ou Redis OSS de nó único
Ao escalar um cluster Valkey ou Redis OSS de nó único, ElastiCache executa o processo a seguir, independentemente de você usar o ElastiCache console, o ou a API AWS CLI. ElastiCache
1. Um novo cluster com o novo tipo de nó é ativado na mesma zona de disponibilidade que o cluster existente.
1. Os dados do cache no cluster existente são copiados para o novo cluster. A duração desse processo depende do tipo de nó e da quantidade de dados no cluster.
1. As leituras e as gravações são atendidas com o novo cluster. Como os endpoints do novo cluster são os mesmos do que para o cluster antigo, você não precisa atualizar os endpoints no seu aplicativo. Você perceberá uma breve interrupção (alguns segundos) das leituras e gravações no nó primário enquanto a entrada do DNS for atualizada.
1. ElastiCache exclui o cluster antigo. Você perceberá uma breve interrupção (alguns segundos) das leituras e gravações no nó antigo porque as conexões ao nó antigo serão desconectadas.
**nota**
Para clusters que executam o tipo de nó r6gd, você só pode escalar para tamanhos de nó dentro da família de nós r6gd.
Conforme mostrado na tabela a seguir, sua operação de expansão do Valkey ou Redis OSS será bloqueada se você tiver uma atualização do mecanismo programada para a próxima janela de manutenção. Para obter mais informações sobre janelas de manutenção, consulte [Gerenciamento de manutenção de cluster do ElastiCache](maintenance-window.md).
**Operações bloqueadas do Valkey ou do Redis OSS**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/scaling-redis-classic.html)
Se você tiver uma operação pendente que está bloqueando você, será possível tomar uma destas providências.
+ Planeje sua operação de expansão do Valkey ou Redis OSS para a próxima janela de manutenção, desmarcando a caixa de seleção **Apply immediately** (CLI use: `--no-apply-immediately`, API use: `ApplyImmediately=false`).
+ Aguarde até sua próxima janela de manutenção (ou depois) para realizar sua operação de expansão do Valkey ou Redis OSS.
+ Adicione a atualização do mecanismo Valkey ou Redis OSS a essa modificação de cluster com a caixa de seleção **Apply Immediately** (Aplicar imediatamente) marcada (CLI use: `--apply-immediately`, API use: `ApplyImmediately=true`). Isso desbloqueia sua operação de expansão, fazendo com que a atualização do mecanismo seja realizada imediatamente.
Você pode escalar um cluster Valkey ou Redis OSS de nó único (modo de cluster desativado) usando o ElastiCache console, o ou a AWS CLI API. ElastiCache
**Importante**
Se o seu parameter group usar `reserved-memory` para reservar a memória para a sobrecarga do Valkey ou Redis OSS, antes de iniciar a escalabilidade, certifique-se de ter um parameter group personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Como alternativa, você pode modificar um parameter group personalizado para que ele use `reserved-memory-percent` e usar esse parameter group para seu novo cluster.
Se você estiver usando `reserved-memory-percent`, não será necessário fazer isso.
Para obter mais informações, consulte [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md).
#### Aumento de escala vertical de clusters de nó único do Valkey ou Redis OSS (modo cluster desabilitado) (console)
O procedimento a seguir descreve como escalar um cluster OSS Valkey ou Redis de nó único usando o Management Console. ElastiCache Durante esse processo, o cluster do Valkey ou Redis OSS continuará a atender solicitações com tempo de inatividade mínimo.
**Para aumentar a escala vertical de um cluster Valkey ou Redis OSS de nó único (console)**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Valkey or Redis OSS clusters** (Clusters do Valkey ou Redis OSS).
1. Na lista de clusters, escolha o cluster que você deseja expandir (ele deve estar executando o mecanismo Valkey ou Redis OSS, e não o mecanismo clustered Valkey ou Redis OSS).
1. Escolha **Modificar**.
1. No assistente **Modify Cluster**:
1. Na lista **Node type**, escolha o tipo de nó a partir do qual você deseja escalar.
1. Se você estiver usando `reserved-memory` para gerenciar sua memória, na lista **Parameter Group**, escolha o parameter group personalizado que reserva a quantidade correta de memória para o seu novo tipo de nó.
1. Se quiser executar o processo de expansão imediatamente, escolha a caixa **Apply immediately**. Se a caixa **Apply immediately** não for escolhida, o processo de expansão será realizado durante a próxima janela de manutenção desse cluster.
1. Escolha **Modificar**.
Se você escolheu **Apply immediately** na etapa anterior, o status do cluster mudará para *modifying*. Quando o status mudar para *available*, a modificação estará completa, e você poderá começar a usar o novo cluster.
#### Aumento de escala vertical de clusters do Valkey ou Redis OSS de nó único (AWS CLI)
O procedimento a seguir descreve como expandir um cluster Valkey ou Redis OSS de um único nó usando a AWS CLI. Durante esse processo, o cluster do Valkey ou Redis OSS continuará a atender solicitações com tempo de inatividade mínimo.
**Para aumentar a escala verticalmente de um cluster Valkey ou Redis OSS de um único nó (AWS CLI)**
1. Determine os tipos de nós para os quais você pode escalar executando o AWS CLI`list-allowed-node-type-modifications` comando com o parâmetro a seguir.
+ `--cache-cluster-id`
Para Linux, macOS ou Unix:
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Para Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
A saída do comando acima é semelhante a esta (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 ",
],
}
```
Para obter mais informações, consulte [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) na *AWS CLI Referência*.
1. Modifique seu cluster existente especificando o cluster a ser expandido e o novo tipo de nó maior, usando o AWS CLI`modify-cache-cluster` comando e os parâmetros a seguir.
+ `--cache-cluster-id`: o nome do cluster que você está aumentando.
+ `--cache-node-type`: o novo tipo de nó para o qual você deseja escalar o cluster. Esse valor deve ser um dos tipos de nós retornados pelo comando `list-allowed-node-type-modifications` na etapa 1.
+ `--cache-parameter-group-name` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `--apply-immediately`: faz com que o processo de aumento de escala vertical seja aplicado imediatamente. Para adiar o processo de expansão para a próxima janela de manutenção do cluster, use o parâmetro `--no-apply-immediately`.
Para Linux, macOS ou 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
```
Para 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
```
A saída do comando acima é semelhante a esta (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"
}
}
```
Para obter mais informações, consulte [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) na *AWS CLI Referência*.
1. Se você usou o`--apply-immediately`, verifique o status do novo cluster usando o AWS CLI`describe-cache-clusters` comando com o parâmetro a seguir. Quando o status mudar para *available*, você poderá começar a usar o novo cluster maior.
+ `--cache-cluster-id`: o nome do cluster do Valkey ou Redis OSS de nó único. Use esse parâmetro para descrever um cluster específico em vez de todos os clusters.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
Para obter mais informações, consulte [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) na *AWS CLI Referência*.
#### Escalando clusters OSS (API) Valkey ou Redis de nó único ElastiCache
O procedimento a seguir descreve como escalar um cluster OSS Valkey ou Redis de nó único usando a API. ElastiCache Durante esse processo, o cluster do Valkey ou Redis OSS continuará a atender solicitações com tempo de inatividade mínimo.
**Para escalar um cluster OSS (API) Valkey ou Redis de nó único ElastiCache**
1. Determine os tipos de nós para os quais você pode escalar executando a `ListAllowedNodeTypeModifications` ação da ElastiCache API com o parâmetro a seguir.
+ `CacheClusterId`: o nome do cluster Valkey ou Redis OSS de nó único que você deseja aumentar a escala verticalmente.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) a *Amazon ElastiCache API Reference*.
1. Modifique seu cluster existente especificando o cluster a ser expandido e o novo tipo de nó maior, usando a ação da `ModifyCacheCluster` ElastiCache API e os parâmetros a seguir.
+ `CacheClusterId`: o nome do cluster que você está aumentando.
+ `CacheNodeType`: o novo tipo de nó maior para o qual você deseja aumentar a escala vertical do cluster. Esse valor deve ser um dos tipos de nós retornados pela ação `ListAllowedNodeTypeModifications` na etapa anterior.
+ `CacheParameterGroupName` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `ApplyImmediately`: defina como `true` para fazer com que o processo de expansão seja executado imediatamente. Para adiar o processo de expansão para a próxima janela de manutenção do cluster, use `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=
```
Para obter mais informações, consulte [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) a *Amazon ElastiCache API Reference*.
1. Se você usou `ApplyImmediately``=true`, verifique o status do novo cluster usando a `DescribeCacheClusters` ação da ElastiCache API com o parâmetro a seguir. Quando o status mudar para *available*, você poderá começar a usar o novo cluster maior.
+ `CacheClusterId`: o nome do cluster do Valkey ou Redis OSS de nó único. Use esse parâmetro para descrever um cluster específico em vez de todos os clusters.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) a *Amazon ElastiCache API Reference*.
### Redução de escala vertical de clusters do Valkey ou Redis OSS de nó único
As seções a seguir demonstram como reduzir um cluster Valkey ou Redis OSS de nó único para um tipo de nó menor. Garantir que o novo tipo de nó menor seja suficientemente grande para acomodar todos os dados e a sobrecarga do Valkey ou Redis OSS é importante para o sucesso a longo prazo do seu novo cluster Valkey ou Redis OSS. Para obter mais informações, consulte [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md).
**nota**
Para clusters que executam o tipo de nó r6gd, você só pode escalar para tamanhos de nó dentro da família de nós r6gd.
**Topics**
+ [Redução de escala vertical de um cluster do Valkey ou Redis OSS de nó único (console)](#Scaling.RedisStandalone.ScaleDown.CON)
+ [Redução de escala vertical de clusters do Valkey ou Redis OSS de nó único (AWS CLI)](#Scaling.RedisStandalone.ScaleUpDown-Modify.CLI)
+ [Reduzindo a escala de clusters Valkey ou Redis OSS (API) de nó único ElastiCache](#Scaling.RedisStandalone.ScaleDown.API)
#### Redução de escala vertical de um cluster do Valkey ou Redis OSS de nó único (console)
O procedimento a seguir mostra como escalar seu cluster OSS Valkey ou Redis de nó único para um tipo de nó menor usando o console. ElastiCache
**Importante**
Se o seu parameter group usar `reserved-memory` para reservar a memória para a sobrecarga do Valkey ou Redis OSS, antes de iniciar a escalabilidade, certifique-se de ter um parameter group personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Como alternativa, você pode modificar um parameter group personalizado para que ele use `reserved-memory-percent` e usar esse parameter group para seu novo cluster.
Se você estiver usando `reserved-memory-percent`, não será necessário fazer isso.
Para obter mais informações, consulte [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md).
**Para reduzir a escala vertical do seu cluster do Valkey ou Redis OSS de nó único (console)**
1. Certifique-se de que o tipo de nó menor seja adequado para suas necessidades de dados e sobrecarga.
1. Se o seu parameter group usar `reserved-memory` para reservar memória para a sobrecarga do Valkey ou Redis OSS, certifique-se de ter um parameter group personalizado para reservar a quantidade correta de memória para o seu novo tipo de nó.
Alternativamente, você pode modificar seu parameter group personalizado para usar `reserved-memory-percent`. Para obter mais informações, consulte [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md).
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Na lista de clusters, escolha o cluster que você deseja reduzir. Esse cluster deve estar executando o mecanismo Valkey ou Redis OSS, e não o mecanismo clustered Valkey ou Redis OSS.
1. Escolha **Modificar**.
1. No assistente **Modify Cluster**:
1. Na lista **Node type (Tipo de nó)**, escolha o tipo de nó para o qual deseja reduzir.
1. Se você estiver usando `reserved-memory` para gerenciar sua memória, na lista **Parameter Group**, escolha o parameter group personalizado que reserva a quantidade correta de memória para o seu novo tipo de nó.
1. Se desejar executar o processo de redução imediatamente, escolha a caixa de seleção **Apply immediately (Aplicar imediatamente)**. Se a caixa de seleção **Apply immediately (Aplicar imediatamente)** não for escolhida, o processo de redução será realizado durante a próxima janela de manutenção desse cluster.
1. Escolha **Modificar**.
1. Quando o status do cluster muda de *modifying* para *available*, significa que o seu cluster foi escalonado para o novo tipo de nó. Não é necessário atualizar os endpoints no seu aplicativo.
#### Redução de escala vertical de clusters do Valkey ou Redis OSS de nó único (AWS CLI)
O procedimento a seguir descreve como reduzir um cluster Valkey ou Redis OSS de um único nó usando a AWS CLI.
**Para reduzir a escala verticalmente de um cluster Valkey ou Redis OSS de um único nó (AWS CLI)**
1. Determine os tipos de nós para os quais você pode reduzir executando o AWS CLI`list-allowed-node-type-modifications` comando com o parâmetro a seguir.
+ `--cache-cluster-id`
Para Linux, macOS ou Unix:
```
aws elasticache list-allowed-node-type-modifications \
--cache-cluster-id my-cache-cluster-id
```
Para Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--cache-cluster-id my-cache-cluster-id
```
A saída do comando acima é semelhante a esta (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 ",
],
}
```
Para obter mais informações, consulte [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) na *AWS CLI Referência*.
1. Modifique seu cluster existente especificando o cluster a ser reduzido e o novo tipo de nó menor, usando o AWS CLI`modify-cache-cluster` comando e os parâmetros a seguir.
+ `--cache-cluster-id`: o nome do cluster para o qual você está reduzindo a escala verticalmente.
+ `--cache-node-type`: o novo tipo de nó para o qual você deseja escalar o cluster. Esse valor deve ser um dos tipos de nós retornados pelo comando `list-allowed-node-type-modifications` na etapa 1.
+ `--cache-parameter-group-name` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `--apply-immediately`: faz com que o processo de redução da escala vertical seja aplicado imediatamente. Para adiar o processo de expansão para a próxima janela de manutenção do cluster, use o parâmetro `--no-apply-immediately`.
Para Linux, macOS ou 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
```
Para 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
```
A saída do comando acima é semelhante a esta (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"
}
}
```
Para obter mais informações, consulte [modify-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-cache-cluster.html) na *AWS CLI Referência*.
1. Se você usou o`--apply-immediately`, verifique o status do novo cluster usando o AWS CLI`describe-cache-clusters` comando com o parâmetro a seguir. Quando o status mudar para *available*, você poderá começar a usar o novo cluster maior.
+ `--cache-cluster-id`: o nome do cluster do Valkey ou Redis OSS de nó único. Use esse parâmetro para descrever um cluster específico em vez de todos os clusters.
```
aws elasticache describe-cache-clusters --cache-cluster-id my-redis-cache-cluster
```
Para obter mais informações, consulte [describe-cache-clusters](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-cache-clusters.html) na *AWS CLI Referência*.
#### Reduzindo a escala de clusters Valkey ou Redis OSS (API) de nó único ElastiCache
O procedimento a seguir descreve como aumentar a escala de um cluster Valkey ou Redis OSS de nó único usando a API. ElastiCache
**Para reduzir um cluster OSS (API) Valkey ou Redis de nó único ElastiCache**
1. Determine os tipos de nós para os quais você pode reduzir executando a `ListAllowedNodeTypeModifications` ação da ElastiCache API com o parâmetro a seguir.
+ `CacheClusterId`: o nome do cluster de cache do Valkey ou Redis OSS de nó único que você deseja reduzir a escala vertical.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) a *Amazon ElastiCache API Reference*.
1. Modifique seu cluster existente especificando o cluster a ser expandido e o novo tipo de nó maior, usando a ação da `ModifyCacheCluster` ElastiCache API e os parâmetros a seguir.
+ `CacheClusterId`: o nome do cluster para o qual você está reduzindo a escala verticalmente.
+ `CacheNodeType`: o novo tipo de nó menor para o qual você deseja reduzir a escala vertical do cluster. Esse valor deve ser um dos tipos de nós retornados pela ação `ListAllowedNodeTypeModifications` na etapa anterior.
+ `CacheParameterGroupName` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `ApplyImmediately`: defina como `true` para fazer com que o processo de redução de escala vertical seja executado imediatamente. Para adiar o processo de expansão para a próxima janela de manutenção do cluster, use `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=
```
Para obter mais informações, consulte [ModifyCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyCacheCluster.html) a *Amazon ElastiCache API Reference*.
1. Se você usou `ApplyImmediately``=true`, verifique o status do novo cluster usando a `DescribeCacheClusters` ação da ElastiCache API com o parâmetro a seguir. Quando o status mudar para *available (disponível)*, você poderá começar a usar o novo cluster menor.
+ `CacheClusterId`: o nome do cluster do Valkey ou Redis OSS de nó único. Use esse parâmetro para descrever um cluster específico em vez de todos os clusters.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeCacheClusters
&CacheClusterId=MyRedisCacheCluster
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [DescribeCacheClusters](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeCacheClusters.html) a *Amazon ElastiCache API Reference*.
# Escalar nós de réplica para Valkey ou Redis OSS (modo cluster desativado)
Um cluster Valkey ou Redis OSS com nós de réplica (chamado de *grupo de replicação* na API/CLI) fornece alta disponibilidade por meio de uma replicação que possui o recurso Multi-AZ com failover automático habilitado. Um cluster com nós de réplica é um conjunto lógico de até seis clusters Valkey ou Redis OSS em que um nó, o primário, pode atender a solicitações de leitura e gravação. Todos os outros nós do cluster são réplicas somente leitura do primário. Os dados escritos no primário são replicados de forma assíncrona para todas as réplicas de leitura no cluster. Como o Valkey ou Redis OSS (modo cluster desabilitado) não oferece suporte ao particionamento dos seus dados em vários clusters, cada nó em um grupo de replicação do Valkey ou Redis OSS (modo cluster desabilitado) contém todo o conjunto de dados do cache. Clusters do Valkey ou Redis OSS (modo cluster habilitado) oferecem suporte para o particionamento dos seus dados até 500 fragmentos.
Para alterar a capacidade de dados do seu cluster, você deve expandi-lo para um tipo de nó maior ou reduzi-lo para um tipo de nó menor.
Para alterar a capacidade de leitura do seu cluster, adicione mais réplicas de leitura, até um máximo de 5, ou remova réplicas de leitura.
O processo ElastiCache de escalabilidade foi projetado para fazer o melhor esforço para reter seus dados existentes e requer uma replicação bem-sucedida do Valkey ou do Redis OSS. Para clusters Valkey ou Redis OSS com réplicas, recomendamos que uma memória suficiente seja disponibilizada para o Valkey ou Redis OSS.
**Topics**
+ [Aumento de escala vertical de clusters do Valkey ou Redis OSS com réplicas](#Scaling.RedisReplGrps.ScaleUp)
+ [Redução de escala vertical de clusters do Valkey ou Redis OSS com réplicas](#Scaling.RedisReplGrps.ScaleDown)
+ [Aumento da capacidade de leitura](#Scaling.RedisReplGrps.ScaleOut)
+ [Redução da capacidade de leitura](#Scaling.RedisReplGrps.ScaleIn)
**Related Topics**
+ [Alta disponibilidade com o uso de grupos de replicação](Replication.md)
+ [Replicação: Modo de cluster Valkey e Redis OSS desativado versus ativado](Replication.Redis-RedisCluster.md)
+ [Minimizar o tempo de inatividade no ElastiCache usando o Multi-AZ com Valkey e Redis OSS](AutoFailover.md)
+ [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md)
**Topics**
+ [Aumento de escala vertical de clusters do Valkey ou Redis OSS com réplicas](#Scaling.RedisReplGrps.ScaleUp)
+ [Redução de escala vertical de clusters do Valkey ou Redis OSS com réplicas](#Scaling.RedisReplGrps.ScaleDown)
+ [Aumento da capacidade de leitura](#Scaling.RedisReplGrps.ScaleOut)
+ [Redução da capacidade de leitura](#Scaling.RedisReplGrps.ScaleIn)
## Aumento de escala vertical de clusters do Valkey ou Redis OSS com réplicas
ElastiCache A Amazon fornece suporte de console, CLI e API para escalar seu grupo de replicação Valkey ou Redis OSS (modo de cluster desativado).
Quando o processo de aumento de escala é iniciado, ElastiCache faça o seguinte:
1. Executa um grupo de replicação usando o novo tipo de nó.
1. Copia todos os dados do nó primário atual para o novo nó primário.
1. Sincroniza as novas réplicas de leitura com o novo nó primário.
1. Atualiza as entradas do DNS para que elas apontem para os novos nós. Por isso, você não precisa atualizar os endpoints no seu aplicativo. Para o Valkey 7.2 e superiores ou Redis OSS 5.0.5 e superiores, você pode escalar clusters habilitados para failover automático enquanto o cluster continua on-line e atendendo a solicitações recebidas. No Redis OSS versão 4.0.10 e anteriores, você perceberá uma breve interrupção de leituras e gravações em versões anteriores do nó primário enquanto a entrada de DNS é atualizada.
1. Exclui os nós antigos (CLI/API: grupo de replicação). Você perceberá uma breve interrupção (alguns segundos) nas leituras e gravações dos nós antigos porque as conexões aos nós antigos serão desconectadas.
O tempo necessário para esse processo depende do tipo de nó e da quantidade de dados no seu cluster.
Conforme mostrado na tabela a seguir, sua operação de expansão do Valkey ou Redis OSS será bloqueada se você tiver uma atualização do mecanismo programada para a próxima janela de manutenção do cluster.
**Operações bloqueadas do Valkey ou do Redis OSS**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/Scaling.RedisReplGrps.html)
Se você tiver uma operação pendente que está bloqueando você, será possível tomar uma destas providências.
+ Planeje sua operação de expansão do Valkey ou Redis OSS para a próxima janela de manutenção, desmarcando a caixa de seleção **Apply immediately** (CLI use: `--no-apply-immediately`, API use: `ApplyImmediately=false`).
+ Aguarde até sua próxima janela de manutenção (ou depois) para realizar sua operação de expansão do Valkey ou Redis OSS.
+ Adicione a atualização do mecanismo Valkey ou Redis OSS a essa modificação de cluster com a caixa de seleção **Apply Immediately** (Aplicar imediatamente) marcada (CLI use: `--apply-immediately`, API use: `ApplyImmediately=true`). Isso desbloqueia sua operação de expansão, fazendo com que a atualização do mecanismo seja realizada imediatamente.
As seções a seguir descrevem como escalar seu cluster OSS Valkey ou Redis com réplicas usando o ElastiCache console, o e a API AWS CLI. ElastiCache
**Importante**
Se o seu parameter group usar `reserved-memory` para reservar a memória para a sobrecarga do Valkey ou Redis OSS, antes de iniciar a escalabilidade, certifique-se de ter um parameter group personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Como alternativa, você pode modificar um parameter group personalizado para que ele use `reserved-memory-percent` e usar esse parameter group para seu novo cluster.
Se você estiver usando `reserved-memory-percent`, não será necessário fazer isso.
Para obter mais informações, consulte [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md).
### Aumento de escala vertical de um cluster do Valkey ou Redis OSS com réplicas (console)
O tempo necessário para expandir para um tipo de nó maior varia dependendo do tipo de nó e da quantidade de dados no seu cluster atual.
O processo a seguir escala seu cluster com réplicas do tipo de nó atual para um novo tipo de nó maior usando o ElastiCache console. Durante esse processo, poderá haver uma breve interrupção de leituras e gravações de outras versões do nó primário enquanto a entrada de DNS é atualizada. Talvez você observe menos de 1 segundo de tempo de inatividade para os nós executados nas versões 5.0.5 e posteriores e alguns segundos para as versões mais antigas.
**Para aumentar a escala vertical de um cluster do Valkey ou Redis OSS com réplicas (console)**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Clusters do Valkey** ou **Clusters do Redis OSS**
1. Na lista de clusters, escolha o cluster que você deseja expandir. Esse cluster deve estar executando o mecanismo Valkey ou Redis OSS, e não o mecanismo clustered Valkey ou Redis OSS.
1. Escolha **Modificar**.
1. No assistente **Modify Cluster**:
1. Na lista **Node type**, escolha o tipo de nó a partir do qual você deseja escalar. Observe que nem todos os tipos de nó estão disponíveis para redução.
1. Se você estiver usando `reserved-memory` para gerenciar sua memória, na lista **Parameter Group**, escolha o parameter group personalizado que reserva a quantidade correta de memória para o seu novo tipo de nó.
1. Se quiser executar o processo de expansão imediatamente, escolha a caixa de seleção **Apply immediately**. Se a caixa de seleção **Apply immediately** não for escolhida, o processo de expansão será realizado durante a próxima janela de manutenção desse cluster.
1. Escolha **Modificar**.
1. Quando o status do cluster muda de *modifying* para *available*, significa que o seu cluster foi escalonado para o novo tipo de nó. Não é necessário atualizar os endpoints no seu aplicativo.
### Aumento de escala vertical de um grupo de replicação do Valkey ou Redis OSS (AWS CLI)
O processo a seguir dimensiona o grupo de replicação do tipo de nó atual para um novo tipo de nó maior usando a AWS CLI. Durante esse processo, ElastiCache atualiza as entradas de DNS para que elas apontem para os novos nós. Por isso, você não precisa atualizar os endpoints no seu aplicativo. Para o Valkey 7.2 e superiores ou Redis OSS 5.0.5 e superiores, você pode escalar clusters habilitados para failover automático enquanto o cluster continua on-line e atendendo a solicitações recebidas. Nas versões 4.0.10 e anteriores, você perceberá uma breve interrupção de leituras e gravações em versões anteriores do nó primário enquanto a entrada de DNS é atualizada.
O tempo necessário para aumentar a escala verticalmente até um tipo de nó maior varia, dependendo do tipo de nó e da quantidade de dados no seu cluster atual.
**Para aumentar a escala verticalmente de um grupo de replicação Valkey ou Redis OSS (AWS CLI)**
1. Determine para quais tipos de nós você pode escalar executando o AWS CLI`list-allowed-node-type-modifications` comando com o parâmetro a seguir.
+ `--replication-group-id` - o nome do grupo de replicação. Use esse parâmetro para descrever um grupo de replicação específico em vez de todos os grupos de replicação.
Para Linux, macOS ou Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Para Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
O resultado dessa operação é semelhante a este (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"
]
}
```
Para obter mais informações, consulte [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) na *AWS CLI Referência*.
1. Dimensione seu grupo de replicação atual até o novo tipo de nó usando o AWS CLI`modify-replication-group` comando com os parâmetros a seguir.
+ `--replication-group-id` - o nome do grupo de replicação.
+ `--cache-node-type`: o novo tipo de nó maior dos clusters nesse grupo de replicação. Esse valor deve ser um dos tipos de instância retornados pelo comando `list-allowed-node-type-modifications` na etapa anterior.
+ `--cache-parameter-group-name` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `--apply-immediately`: faz com que o processo de aumento de escala vertical seja aplicado imediatamente. Para adiar a operação de expansão para a próxima janela de manutenção, use `--no-apply-immediately`.
Para Linux, macOS ou 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
```
Para 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
```
O resultado desse comando é semelhante a este (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": {}
}
}
```
Para obter mais informações, consulte [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) na *AWS CLI Referência*.
1. Se você usou o `--apply-immediately` parâmetro, monitore o status do grupo de replicação usando o AWS CLI`describe-replication-group` comando com o parâmetro a seguir. Enquanto o status ainda for *modifying* (em modificação), você poderá observar menos de 1 segundo de tempo de inatividade para os nós executados nas versões 5.0.6 e posteriores, e uma breve interrupção de leituras e gravações para as versões mais antigas do nó primário enquanto a entrada do DNS é atualizada.
+ `--replication-group-id` - o nome do grupo de replicação. Use esse parâmetro para descrever um grupo de replicação específico em vez de todos os grupos de replicação.
Para Linux, macOS ou Unix:
```
aws elasticache describe-replication-groups \
--replication-group-id my-replication-group
```
Para Windows:
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
Para obter mais informações, consulte [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) na *AWS CLI Referência*.
### Escalando um grupo de replicação (API) Valkey ou Redis OSS ElastiCache
O processo a seguir escala seu grupo de replicação do tipo de nó atual para um novo tipo de nó maior usando a ElastiCache API. Para o Valkey 7.2 e superiores ou Redis OSS 5.0.5 e superiores, você pode escalar clusters habilitados para failover automático enquanto o cluster continua on-line e atendendo a solicitações recebidas. No Redis OSS versão 4.0.10 e anteriores, você pode notar uma breve interrupção de leituras e gravações em versões anteriores do nó primário enquanto a entrada do DNS é atualizada.
O tempo necessário para aumentar a escala verticalmente até um tipo de nó maior varia, dependendo do tipo de nó e da quantidade de dados no seu cluster atual.
**Para escalar um grupo de replicação (API) Valkey ou Redis OSS ElastiCache**
1. Determine para quais tipos de nós você pode escalar usando a `ListAllowedNodeTypeModifications` ação da ElastiCache API com o parâmetro a seguir.
+ `ReplicationGroupId` - o nome do grupo de replicação. Use esse parâmetro para descrever um determinado grupo de replicação em vez de todos os grupos de replicação.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) a *Amazon ElastiCache API Reference*.
1. Dimensione seu grupo de replicação atual até o novo tipo de nó usando a ação da `ModifyReplicationGroup` ElastiCache API e com os parâmetros a seguir.
+ `ReplicationGroupId` - o nome do grupo de replicação.
+ `CacheNodeType`: o novo tipo de nó maior dos clusters nesse grupo de replicação. Esse valor deve ser um dos tipos de instância retornados pela ação `ListAllowedNodeTypeModifications` na etapa anterior.
+ `CacheParameterGroupName` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `ApplyImmediately`: defina como `true` para fazer com que o processo de aumento de escala vertical seja aplicado imediatamente. Para adiar o processo de expansão para a próxima janela de manutenção, use `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=
```
Para obter mais informações, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) a *Amazon ElastiCache API Reference*.
1. Se você usou `ApplyImmediately``=true`, monitore o status do grupo de replicação usando a `DescribeReplicationGroups` ação da ElastiCache API com os parâmetros a seguir. Quando o status mudar de *modifying* para *available*, você poderá começar a gravar no seu novo grupo de replicação expandido.
+ `ReplicationGroupId` - o nome do grupo de replicação. Use esse parâmetro para descrever um grupo de replicação específico em vez de todos os grupos de replicação.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) a *Amazon ElastiCache API Reference*.
## Redução de escala vertical de clusters do Valkey ou Redis OSS com réplicas
As seções a seguir demonstram passo a passo o processo de reduzir a escala vertical de um cluster Valkey ou Redis OSS (modo cluster desabilitado) com nós de réplica para um tipo de nó menor. Garantir que o novo tipo de nó menor seja suficientemente grande para acomodar todos os dados e a sobrecarga é muito importante para o sucesso. Para obter mais informações, consulte [Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS](BestPractices.BGSAVE.md).
**nota**
Para clusters que executam o tipo de nó r6gd, você só pode escalar para tamanhos de nó dentro da família de nós r6gd.
**Importante**
Se o seu parameter group usar `reserved-memory` para reservar a memória para a sobrecarga do Valkey ou Redis OSS, antes de iniciar a escalabilidade, certifique-se de ter um parameter group personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Como alternativa, você pode modificar um parameter group personalizado para que ele use `reserved-memory-percent` e usar esse parameter group para seu novo cluster.
Se você estiver usando `reserved-memory-percent`, não será necessário fazer isso.
Para obter mais informações, consulte [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md).
**Topics**
### Redução de escala vertical de um cluster do Valkey ou Redis OSS com réplicas (console)
O processo a seguir dimensiona seu cluster OSS Valkey ou Redis com nós de réplica para um tipo de nó menor usando o console. ElastiCache
**Para reduzir a escala vertical um cluster do Valkey ou Redis OSS com nós de réplica (console)**
1. Certifique-se de que o tipo de nó menor seja adequado para suas necessidades de dados e sobrecarga.
1. Se o seu parameter group usar `reserved-memory` para reservar memória para a sobrecarga do Valkey ou Redis OSS, certifique-se de ter um parameter group personalizado para reservar a quantidade correta de memória para o seu novo tipo de nó.
Alternativamente, você pode modificar seu parameter group personalizado para usar `reserved-memory-percent`. Para obter mais informações, consulte [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md).
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Na lista de clusters, escolha o cluster que você deseja reduzir. Esse cluster deve estar executando o mecanismo Valkey ou Redis OSS, e não o mecanismo clustered Valkey ou Redis OSS.
1. Escolha **Modificar**.
1. No assistente **Modify Cluster**:
1. Na lista **Node type (Tipo de nó)**, escolha o tipo de nó para o qual deseja reduzir.
1. Se você estiver usando `reserved-memory` para gerenciar sua memória, na lista **Parameter Group**, escolha o parameter group personalizado que reserva a quantidade correta de memória para o seu novo tipo de nó.
1. Se desejar executar o processo de redução imediatamente, escolha a caixa de seleção **Apply immediately (Aplicar imediatamente)**. Se a caixa de seleção **Apply immediately (Aplicar imediatamente)** não for escolhida, o processo de redução será realizado durante a próxima janela de manutenção desse cluster.
1. Escolha **Modificar**.
1. Quando o status do cluster muda de *modifying* para *available*, significa que o seu cluster foi escalonado para o novo tipo de nó. Não é necessário atualizar os endpoints no seu aplicativo.
### Redução de escala vertical de um grupo de replicação do Valkey ou Redis OSS (AWS CLI)
O processo a seguir dimensiona grupo de replicação do tipo de nó atual para um novo tipo de nó menor usando a AWS CLI. Durante esse processo, ElastiCache atualiza as entradas de DNS para que elas apontem para os novos nós. Por isso, você não precisa atualizar os endpoints no seu aplicativo. Para o Valkey 7.2 e superiores ou Redis OSS 5.0.5 e superiores, você pode escalar clusters habilitados para failover automático enquanto o cluster continua on-line e atendendo a solicitações recebidas. Nas versões 4.0.10 e anteriores, você perceberá uma breve interrupção de leituras e gravações em versões anteriores do nó primário enquanto a entrada de DNS é atualizada.
No entanto, as leituras dos clusters de réplica de leitura continuam ininterruptas.
O tempo necessário para reduzir a escala verticalmente até um tipo de nó menor varia, dependendo do tipo de nó e da quantidade de dados no seu cluster atual.
**Para reduzir a escala verticalmente de um grupo de replicação do Valkey ou Redis OSS (AWS CLI)**
1. Determine para quais tipos de nós você pode reduzir executando o AWS CLI`list-allowed-node-type-modifications` comando com o parâmetro a seguir.
+ `--replication-group-id` - o nome do grupo de replicação. Use esse parâmetro para descrever um grupo de replicação específico em vez de todos os grupos de replicação.
Para Linux, macOS ou Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-repl-group
```
Para Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-repl-group
```
O resultado dessa operação é semelhante a este (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"
]
}
```
Para obter mais informações, consulte [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) na *AWS CLI Referência*.
1. Dimensione seu grupo de replicação atual até o novo tipo de nó usando o AWS CLI`modify-replication-group` comando com os parâmetros a seguir.
+ `--replication-group-id` - o nome do grupo de replicação.
+ `--cache-node-type`: o novo tipo de nó menor dos clusters nesse grupo de replicação. Esse valor deve ser um dos tipos de instância retornados pelo comando `list-allowed-node-type-modifications` na etapa anterior.
+ `--cache-parameter-group-name` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `--apply-immediately`: faz com que o processo de aumento de escala vertical seja aplicado imediatamente. Para adiar a operação de expansão para a próxima janela de manutenção, use `--no-apply-immediately`.
Para Linux, macOS ou 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
```
Para 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
```
O resultado desse comando é semelhante a este (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": {}
}
}
```
Para obter mais informações, consulte [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) na *AWS CLI Referência*.
1. Se você usou o `--apply-immediately` parâmetro, monitore o status do grupo de replicação usando o AWS CLI`describe-replication-group` comando com o parâmetro a seguir. Quando o status mudar de *modifying (modificando)* para *available (disponível)*, você poderá começar a gravar no seu novo grupo de replicação reduzido.
+ `--replication-group-id` - o nome do grupo de replicação. Use esse parâmetro para descrever um grupo de replicação específico em vez de todos os grupos de replicação.
Para Linux, macOS ou Unix:
```
aws elasticache describe-replication-group \
--replication-group-id my-replication-group
```
Para Windows:
```
aws elasticache describe-replication-groups ^
--replication-group-id my-replication-group
```
Para obter mais informações, consulte [describe-replication-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-replication-groups.html) na *AWS CLI Referência*.
### Reduzindo um grupo de replicação (API) do Valkey ou do Redis OSS ElastiCache
O processo a seguir escala seu grupo de replicação do tipo de nó atual para um novo tipo de nó menor usando a ElastiCache API. Durante esse processo, ElastiCache atualiza as entradas de DNS para que elas apontem para os novos nós. Por isso, você não precisa atualizar os endpoints no seu aplicativo. Para o Valkey 7.2 e superiores ou Redis OSS 5.0.5 e superiores, você pode escalar clusters habilitados para failover automático enquanto o cluster continua on-line e atendendo a solicitações recebidas. No Redis OSS versão 4.0.10 e anteriores, você perceberá uma breve interrupção de leituras e gravações em versões anteriores do nó primário enquanto a entrada de DNS é atualizada. No entanto, as leituras dos clusters de réplica de leitura continuam ininterruptas.
O tempo necessário para reduzir a escala verticalmente até um tipo de nó menor varia, dependendo do tipo de nó e da quantidade de dados no seu cluster atual.
**Para reduzir um grupo de replicação (API) Valkey ou Redis OSS ElastiCache**
1. Determine quais tipos de nós você pode reduzir usando a `ListAllowedNodeTypeModifications` ação da ElastiCache API com o parâmetro a seguir.
+ `ReplicationGroupId` - o nome do grupo de replicação. Use esse parâmetro para descrever um determinado grupo de replicação em vez de todos os grupos de replicação.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) a *Amazon ElastiCache API Reference*.
1. Dimensione seu grupo de replicação atual até o novo tipo de nó usando a ação da `ModifyReplicationGroup` ElastiCache API e com os parâmetros a seguir.
+ `ReplicationGroupId` - o nome do grupo de replicação.
+ `CacheNodeType`: o novo tipo de nó menor dos clusters nesse grupo de replicação. Esse valor deve ser um dos tipos de instância retornados pela ação `ListAllowedNodeTypeModifications` na etapa anterior.
+ `CacheParameterGroupName` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `ApplyImmediately`: defina como `true` para fazer com que o processo de aumento de escala vertical seja aplicado imediatamente. Para adiar o processo de redução até a próxima janela de manutenção, use `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=
```
Para obter mais informações, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) a *Amazon ElastiCache API Reference*.
1. Se você usou `ApplyImmediately``=true`, monitore o status do grupo de replicação usando a `DescribeReplicationGroups` ação da ElastiCache API com os parâmetros a seguir. Quando o status mudar de *modifying (modificando)* para *available (disponível)*, você poderá começar a gravar no seu novo grupo de replicação reduzido.
+ `ReplicationGroupId` - o nome do grupo de replicação. Use esse parâmetro para descrever um grupo de replicação específico em vez de todos os grupos de replicação.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) a *Amazon ElastiCache API Reference*.
## Aumento da capacidade de leitura
Para aumentar a capacidade de leitura, adicione réplicas de leitura (até um máximo de cinco) ao seu grupo de replicação Valkey ou Redis OSS.
Você pode escalar a capacidade de leitura do cluster Valkey ou Redis OSS usando o ElastiCache console AWS CLI, o ou a API. ElastiCache Para obter mais informações, consulte [Adição de uma réplica de leitura do Valkey ou do Redis OSS (modo cluster desabilitado)](Replication.AddReadReplica.md).
## Redução da capacidade de leitura
Para diminuir a capacidade de leitura, exclua uma ou mais réplicas de leitura do seu cluster Valkey ou Redis OSS com réplicas (chamado de *grupo de replicação* na API/CLI). Se o cluster for habilitado para Multi-AZ com failover automático, não será possível excluir a última réplica de leitura sem primeiro desabilitar o Multi-AZ. Para obter mais informações, consulte [Modificação de um grupo de replicação](Replication.Modify.md).
Para obter mais informações, consulte [Exclusão de uma réplica de leitura do Valkey ou do Redis OSS (modo cluster desabilitado)](Replication.RemoveReadReplica.md).
# Escalabilidade de clusters no Valkey ou Redis OSS (modo cluster habilitado)
À medida que a demanda nos clusters muda, você pode optar por aumentar a performance ou reduzir os custos alterando o número de fragmentos no seu cluster do Valkey ou Redis OSS (modo cluster habilitado). Recomendamos o uso da escalabilidade horizontal online para esse ajuste, pois permite que o seu cluster continue a atender às solicitações durante o processo de escalabilidade.
As condições sob as quais você pode decidir redimensionar seu cluster incluem o seguinte:
+ **Uso intenso de memória:**
Se os nós no cluster estão sob uso intenso da memória, você pode optar por aumentar a escala e ter mais recursos para melhor armazenar dados e atender a solicitações.
Você pode determinar se seus nós estão sob pressão de memória monitorando as seguintes métricas: *FreeableMemory*SwapUsage**, *BytesUsedForCache*e.
+ **CPU ou gargalo de rede:**
Se os latency/throughput problemas estiverem afetando seu cluster, talvez seja necessário escalar para resolvê-los.
Você pode monitorar seus níveis de latência e taxa de transferência monitorando as seguintes métricas: *CPUUtilization*, *NetworkBytesIn*, *NetworkBytesOut*CurrConnections**, e. *NewConnections*
+ **Seu cluster está acima da escala:**
A demanda atual no cluster permite que haja uma redução na escala sem afetar o desempenho e proporcionando corte de custos.
Você pode monitorar o uso do seu cluster para determinar se você pode ou não escalar com segurança usando as seguintes métricas: *FreeableMemory*SwapUsage*BytesUsedForCache*CPUUtilization****, *NetworkBytesIn*, *NetworkBytesOut*, *CurrConnections*,, *NewConnections*e.
**Impacto da escalabilidade no desempenho**
Quando você altera a escala usando o processo offline, seu cluster fica offline para uma parte significativa do processo e, por conseguinte, não é capaz de atender a solicitações. Quando você altera a escala usando o método online, como a escalabilidade é uma operação com uso intensivo de computação, há queda no desempenho, mas ainda assim seu cluster continua atendendo a solicitações durante a operação de escalabilidade. O quanto o desempenho é afetado depende do seu uso normal da CPU e dos seus dados.
Existem duas maneiras de escalar seu cluster do Valkey ou Redis OSS (modo cluster desabilitado): com escalabilidade horizontal e vertical.
+ A escalabilidade horizontal permite alterar o número de grupos de nós (estilhaços) no grupo de replicação adicionando ou removendo grupos de nós (estilhaços). O processo de refragmentação on-line permite a escalabilidade in/out enquanto o cluster continua atendendo às solicitações recebidas.
Configurar os slots em seu novo cluster de forma diferente como que eles foram configurados no cluster antigo. Apenas no método offline.
+ Escalabilidade vertical — altere o tipo de nó para redimensionar o cluster. O escalonamento vertical on-line permite o escalonamento up/down enquanto o cluster continua atendendo às solicitações recebidas.
Se estiver reduzindo o tamanho e a capacidade de memória do cluster, reduzindo ou expandindo, garanta que a nova configuração tenha memória suficiente para seus dados e a sobrecarga do Valkey ou Redis OSS.
Para obter mais informações, consulte [Escolha do tamanho do nó](CacheNodes.SelectSize.md).
**Contents**
+ [Refragmentação offline para o Valkey ou o Redis OSS (modo cluster habilitado)](#redis-cluster-resharding-offline)
+ [Refragmentação online para o Valkey ou o Redis OSS (modo cluster habilitado)](#redis-cluster-resharding-online)
+ [Adição de fragmentos com refragmentação online](#redis-cluster-resharding-online-add)
+ [Remoção de fragmentos com refragmentação online](#redis-cluster-resharding-online-remove)
+ [Remoção de fragmentos (console)](#redis-cluster-resharding-online-remove-console)
+ [Remoção de fragmentos (AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [Removendo fragmentos (ElastiCacheAPI)](#redis-cluster-resharding-online-remove-api)
+ [Rebalanceamento de frgamentos online](#redis-cluster-resharding-online-rebalance)
+ [Rebalanceamento de fragmentos online (Console)](#redis-cluster-resharding-online-rebalance-console)
+ [Rebalanceamento de fragmentos online (AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [Rebalanceamento de fragmentos on-line (API) ElastiCache](#redis-cluster-resharding-online-rebalance-api)
+ [Escalabilidade vertical online com modificação do tipo de nó](redis-cluster-vertical-scaling.md)
+ [Aumento de escala vertical online](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
+ [Aumento de escala na vertical de clusters do Valkey ou Redis OSS (console)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-console)
+ [Aumento da escala na vertical de clusters do Valkey ou Redis OSS (AWS CLI)](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Ampliando clusters OSS Valkey ou Redis (API) ElastiCache](redis-cluster-vertical-scaling.md#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [Redução de escala vertical online](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-down)
+ [Redução de escala na vertical de clusters do Valkey ou Redis OSS (console)](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-down-console)
+ [Redução de escala na vertical de clusters do Valkey ou Redis OSS (AWS CLI)](redis-cluster-vertical-scaling.md#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Reduzindo a escala de clusters OSS Valkey ou Redis (API) ElastiCache](redis-cluster-vertical-scaling.md#Scaling.Vertical.ScaleDown.API)
## Refragmentação offline para o Valkey ou o Redis OSS (modo cluster habilitado)
A principal vantagem de obter a reconfiguração de estilhaços offline é que você pode fazer mais do que simplesmente adicionar ou remover estilhaços do seu grupo de replicação. Quando você faz a refragmentação e o rebalanceamento offline, além de alterar o número de fragmentos no seu grupo de replicação, é possível fazer o seguinte:
**nota**
A refragmentação offline não é compatível com clusters do Valkey ou Redis OSS que tenham a classificação de dados em níveis ativada. Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
+ Alterar o tipo de nó do seu grupo de replicação.
+ Especificar a zona de disponibilidade para cada nó no grupo de replicação.
+ Fazer o upgrade para uma versão mais recente do mecanismo.
+ Especificar o número de nós de réplica em cada estilhaço de forma independente.
+ Especificar o espaço de chaves para cada estilhaço.
A principal desvantagem da reconfiguração de fragmentos offline é que o cluster fica offline começando com a parte de restauração do processo e continua até você atualizar os endpoints no aplicativo. O tempo em que o cluster fica offline depende da quantidade de dados no seu cluster.
**Para reconfigurar seus fragmentos offline no cluster do Valkey ou Redis OSS (modo cluster habilitado)**
1. Crie um backup manual do seu cluster Valkey ou Redis OSS existente. Para obter mais informações, consulte [Realização de backups manuais](backups-manual.md).
1. Crie um novo cluster fazendo a restauração a partir do backup. Para obter mais informações, consulte [Restauração de um backup para um novo cache](backups-restoring.md).
1. Atualize os endpoints no seu aplicativo para os endpoints do novo cluster. Para obter mais informações, consulte [Encontrar endpoints de conexão no ElastiCache](Endpoints.md).
## Refragmentação online para o Valkey ou o Redis OSS (modo cluster habilitado)
Ao usar a refragmentação on-line e o rebalanceamento de fragmentos com o ElastiCache Valkey 7.2 ou mais recente, ou o Redis OSS versão 3.2.10 ou mais recente, você pode escalar dinamicamente seu cluster Valkey ou Redis OSS (modo de cluster ativado) sem tempo de inatividade. Essa abordagem significa que seu cluster pode continuar atendendo a solicitações mesmo durante a escalabilidade ou o rebalanceamento.
Você pode fazer o seguinte:
+ **Aumentar a escala horizontalmente**: aumente a capacidade de leitura e gravação adicionando fragmentos (grupos de nós) ao seu cluster do Valkey ou Redis OSS (modo cluster habilitado) (grupo de replicação).
Se você adicionar um ou mais fragmentos ao grupo de replicação, o número de nós em cada novo fragmento será o mesmo que o número de nós no menor dos fragmentos existentes.
+ **Reduzir a escala horizontalmente**: reduza de capacidade de leitura e gravação e, por conseguinte, os custos, removendo fragmentos do cluster do Valkey ou Redis OSS (modo cluster habilitado).
+ **Rebalancear**: mova os espaços de chave entre os fragmentos em seu cluster do Valkey ou Redis OSS (modo cluster habilitado) a fim de que eles sejam distribuídos de modo uniforme entre os fragmentos.
Você não pode fazer o seguinte:
+ **Configurar os fragmentos de forma independente:**
Não é possível especificar o espaço de chave para os fragmentos de forma independente. Para fazer isso, você deve usar o processo offline.
Atualmente, as seguintes limitações se aplicam à fragmentação e ao rebalanceamento ElastiCache on-line:
+ Esses processos exigem o Valkey 7.2 ou mais recente ou Redis OSS 3.2.10 ou mais recente. Para obter informações sobre como atualizar sue versão de mecanismo, consulte [Gerenciamento de versões para ElastiCache](VersionManagement.md).
+ Há limitações em relação a slots ou espaços de chave e itens grandes:
Se qualquer uma das chaves em um fragmento contiver um item grande, essa chave não será migrada para um novo fragmento durante o aumento da escala ou o rebalanceamento. Essa funcionalidade pode resultar em fragmentos desbalanceados.
Se qualquer uma das chaves em um fragmento contiver um item grande (itens maiores do que 256 MB após a serialização), o fragmento não será excluído na redução da escala. Essa funcionalidade pode resultar na não exclusão de alguns fragmentos.
+ Ao aumentar a escala, o número de nós em novos fragmentos fica igual ao número de nós no menor dos fragmentos existentes.
+ No aumento de escala, qualquer tag comum a todos os fragmentos existentes é copiada para os novos fragmentos.
+ Ao escalar um cluster de armazenamento de dados global, não ElastiCache replicará automaticamente as funções de um dos nós existentes para o (s) novo (s) nó (s). Recomendamos carregar suas funções nos novos fragmentos depois de aumentar a escala horizontalmente do seu cluster para que todos os fragmentos tenham as mesmas funções.
**nota**
No ElastiCache Valkey 7.2 e superior e no Redis OSS versão 7 e ElastiCache superior: ao escalar seu cluster, ElastiCache replicará automaticamente as funções carregadas em um dos nós existentes (selecionados aleatoriamente) para o (s) novo (s) nó (s). Se sua aplicação usa [Functions](https://valkey.io/topics/functions-intro/) (Funções), recomendamos carregar todas as suas funções em todos os fragmentos antes de aumentar a escala horizontalmente, para que seu cluster do não tenha definições de função diferentes em fragmentos diferentes.
Para obter mais informações, consulte [Redimensionamento de cluster on-line](best-practices-online-resharding.md).
Você pode escalar ou reequilibrar horizontalmente seus clusters Valkey ou Redis OSS (modo de cluster ativado) usando a Console de gerenciamento da AWS, a e a API.AWS CLI ElastiCache
### Adição de fragmentos com refragmentação online
Você pode adicionar fragmentos ao seu cluster Valkey ou Redis OSS (modo de cluster ativado) usando a API Console de gerenciamento da AWS,AWS CLI ou. ElastiCache Quando você adiciona fragmentos a um cluster do Valkey ou Redis OSS (modo cluster habilitado), qualquer tag nos fragmentos existentes é copiada para os novos fragmentos.
**Topics**
#### Adição de fragmentos (console)
Você pode usar o Console de gerenciamento da AWS para adicionar um ou mais fragmentos ao seu cluster Valkey ou Redis OSS (modo de cluster ativado). O procedimento a seguir descreve o processo.
**Como adicionar fragmentos ao seu cluster do Valkey ou Redis OSS (modo cluster habilitado)**
1. Abra o ElastiCache console em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Clusters do Valkey** ou **Clusters do Redis OSS**.
1. Localize e escolha o nome, não a caixa à esquerda do nome do cluster, do cluster do Valkey ou Redis OSS (modo cluster habilitado) ao qual você deseja adicionar fragmentos.
**dica**
O Valkey ou Redis OSS (modo cluster habilitado) exibe **Clustered Valkey** ou **Clustered Redis OSS** na coluna **Mode** (Modo)
1. Escolha **Add shard** (Adicionar fragmento).
1. Para **Number of shards to be added**, escolha o número de fragmentos que deseja adicionar a este cluster.
1. Para **Availability zone(s)** (Zonas de disponibilidade), escolha **No preference** (Sem preferência) ou **Specify availability zones** (Especificar zonas de disponibilidade).
1. Se você optar por **Specify availability zones** (Especificar zonsa de disponibilidade), para cada nó em cada fragmento, selecione a zona de disponibilidade do nó na lista de zonas de disponibilidade.
1. Escolha **Add** (Adicionar).
#### Adição de fragmentos (AWS CLI)
O processo a seguir descreve como reconfigurar os fragmentos no seu cluster do Valkey ou Redis OSS (modo cluster habilitado) adicionando fragmentos por meio da AWS CLI.
Use os parâmetros a seguir com `modify-replication-group-shard-configuration`.
**Parâmetros**
+ `--apply-immediately`: obrigatório. Especifica que a operação de reconfiguração de fragmento começará imediatamente.
+ `--replication-group-id`: obrigatório. Especifica em qual grupo de replicação (cluster) a operação de reconfiguração de fragmento será executada.
+ `--node-group-count`: obrigatório. Especifica o número de fragmentos (grupos de nós) que devem existir quando a operação for concluída. Ao adicionar fragmentos, o valor de `--node-group-count` deve ser maior que o número atual de fragmentos.
Como opção, você pode especificar a zona de disponibilidade para cada nó no grupo de replicação usando `--resharding-configuration`.
+ `--resharding-configuration`: opcional. Uma lista de zonas de disponibilidade preferenciais para cada nó em cada fragmento no grupo de replicação. Use este parâmetro somente se o valor de `--node-group-count` for maior que o número atual de fragmentos. Se esse parâmetro for omitido ao adicionar fragmentos, a Amazon ElastiCache selecionará as zonas de disponibilidade para os novos nós.
O exemplo a seguir reconfigura os espaços de chave em quatro fragmentos em um cluster do Valkey ou Redis OSS (modo cluster habilitado) `my-cluster`. O exemplo também especifica a zona de disponibilidade para cada nó em cada fragmento. A operação começa imediatamente.
**Example Adicionar fragmentos**
Para Linux, macOS ou 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
```
Para 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
```
Para obter mais informações, consulte [modify-replication-group-shard-configuration](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group-shard-configuration.html) na AWS CLI documentação.
#### Adicionar fragmentos (ElastiCache API)
Você pode usar a ElastiCache API para reconfigurar os fragmentos em seu cluster Valkey ou Redis OSS (modo de cluster ativado) on-line usando a operação. `ModifyReplicationGroupShardConfiguration`
Use os parâmetros a seguir com `ModifyReplicationGroupShardConfiguration`.
**Parâmetros**
+ `ApplyImmediately=true`: obrigatório. Especifica que a operação de reconfiguração de fragmento começará imediatamente.
+ `ReplicationGroupId`: obrigatório. Especifica em qual grupo de replicação (cluster) a operação de reconfiguração de fragmento será executada.
+ `NodeGroupCount`: obrigatório. Especifica o número de fragmentos (grupos de nós) que devem existir quando a operação for concluída. Ao adicionar fragmentos, o valor de `NodeGroupCount` deve ser maior que o número atual de fragmentos.
Como opção, você pode especificar a zona de disponibilidade para cada nó no grupo de replicação usando `ReshardingConfiguration`.
+ `ReshardingConfiguration`: opcional. Uma lista de zonas de disponibilidade preferenciais para cada nó em cada fragmento no grupo de replicação. Use este parâmetro somente se o valor de `NodeGroupCount` for maior que o número atual de fragmentos. Se esse parâmetro for omitido ao adicionar fragmentos, a Amazon ElastiCache selecionará as zonas de disponibilidade para os novos nós.
O processo a seguir descreve como reconfigurar os fragmentos em seu cluster Valkey ou Redis OSS (modo de cluster ativado) adicionando fragmentos usando a API. ElastiCache
**Example Adicionar fragmentos**
O exemplo a seguir adiciona grupos de nós ao cluster do Valkey ou Redis OSS (modo cluster habilitado) `my-cluster` de modo que haja um total de quatro grupos de nós quando a operação for concluída. O exemplo também especifica a zona de disponibilidade para cada nó em cada fragmento. A operação começa imediatamente.
```
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=
```
Para obter mais informações, consulte [ModifyReplicationGroupShardConfiguration](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroupShardConfiguration.html)a Referência ElastiCache da API.
### Remoção de fragmentos com refragmentação online
Você pode remover fragmentos do seu cluster Valkey ou Redis OSS (modo de cluster ativado) usando a API Console de gerenciamento da AWS,AWS CLI ou. ElastiCache
**Topics**
+ [Remoção de fragmentos (console)](#redis-cluster-resharding-online-remove-console)
+ [Remoção de fragmentos (AWS CLI)](#redis-cluster-resharding-online-remove-cli)
+ [Removendo fragmentos (ElastiCacheAPI)](#redis-cluster-resharding-online-remove-api)
#### Remoção de fragmentos (console)
O processo a seguir descreve como reconfigurar os fragmentos no seu cluster do Valkey ou Redis OSS (modo cluster habilitado) removendo fragmentos por meio da Console de gerenciamento da AWS.
Antes de remover grupos de nós (fragmentos) do seu grupo de replicação, certifique-se ElastiCache de que todos os seus dados caibam nos fragmentos restantes. Se os dados couberem, os fragmentos especificados serão excluídos do grupo de replicação como solicitado. Se os dados não couberem nos grupos de nós restantes, o processo será encerrado e o grupo de replicação será deixado com a mesma configuração do grupo de nós anterior à solicitação.
Você pode usar o Console de gerenciamento da AWS para remover um ou mais fragmentos do seu cluster Valkey ou Redis OSS (modo de cluster ativado). Não é possível remover todos os fragmentos de um grupo de replicação. Nesse caso, você deve excluir o grupo de replicação. Para obter mais informações, consulte [Exclusão de um grupo de replicação](Replication.DeletingRepGroup.md). O procedimento a seguir descreve o processo para excluir um ou mais fragmentos.
**Para remover fragmentos do seu cluster do Valkey ou Redis OSS (modo cluster habilitado)**
1. Abra o ElastiCache console em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Clusters do Valkey** ou **Clusters do Redis OSS**.
1. Localize e escolha o nome, não a caixa à esquerda do nome do cluster, do cluster do Valkey ou Redis OSS (modo cluster habilitado) do qual você deseja remover fragmentos.
**dica**
Os clusters do Valkey ou Redis OSS (modo cluster habilitado) têm um valor igual ou superior a 1 na coluna **Shards** (Fragmentos).
1. Na lista de fragmentos, escolha a caixa à esquerda do nome de cada fragmento que você gostaria de excluir.
1. Escolha **Delete shard** (Excluir fragmento).
#### Remoção de fragmentos (AWS CLI)
O processo a seguir descreve como reconfigurar os fragmentos no seu cluster do Valkey ou Redis OSS (modo cluster habilitado) removendo fragmentos por meio da AWS CLI.
**Importante**
Antes de remover grupos de nós (fragmentos) do seu grupo de replicação, certifique-se ElastiCache de que todos os seus dados caibam nos fragmentos restantes. Se os dados couberem, os fragmentos especificados (`--node-groups-to-remove`) serão excluídos do grupo de replicação como solicitado e seus espaços de chave serão mapeados para os fragmentos restantes. Se os dados não couberem nos grupos de nós restantes, o processo será encerrado e o grupo de replicação será deixado com a mesma configuração do grupo de nós anterior à solicitação.
Você pode usar o AWS CLI para remover um ou mais fragmentos do seu cluster Valkey ou Redis OSS (modo de cluster ativado). Não é possível remover todos os fragmentos de um grupo de replicação. Nesse caso, você deve excluir o grupo de replicação. Para obter mais informações, consulte [Exclusão de um grupo de replicação](Replication.DeletingRepGroup.md).
Use os parâmetros a seguir com `modify-replication-group-shard-configuration`.
**Parâmetros**
+ `--apply-immediately`: obrigatório. Especifica que a operação de reconfiguração de fragmento começará imediatamente.
+ `--replication-group-id`: obrigatório. Especifica em qual grupo de replicação (cluster) a operação de reconfiguração de fragmento será executada.
+ `--node-group-count`: obrigatório. Especifica o número de fragmentos (grupos de nós) que devem existir quando a operação for concluída. Ao remover fragmentos, o valor de `--node-group-count` deve ser menor que o número atual de fragmentos.
+ `--node-groups-to-remove`: obrigatório quando `--node-group-count` for menor do que o número atual de grupos de nós (fragmentos). Uma lista de fragmentos (grupo de nós) IDs a serem removidos do grupo de replicação.
O procedimento a seguir descreve o processo para excluir um ou mais fragmentos.
**Example Remover fragmentos**
O exemplo a seguir remove dois grupos de nós do cluster do Valkey ou Redis OSS (modo cluster habilitado) `my-cluster` de modo que haja um total de dois grupos de nós quando a operação for concluída. Os espaços de chave dos fragmentos removidos são distribuídos uniformemente entre os fragmentos restantes.
Para Linux, macOS ou 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
```
Para 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
```
#### Removendo fragmentos (ElastiCacheAPI)
Você pode usar a ElastiCache API para reconfigurar os fragmentos em seu cluster Valkey ou Redis OSS (modo de cluster ativado) on-line usando a operação. `ModifyReplicationGroupShardConfiguration`
O processo a seguir descreve como reconfigurar os fragmentos em seu cluster Valkey ou Redis OSS (modo de cluster ativado) removendo fragmentos usando a API. ElastiCache
**Importante**
Antes de remover grupos de nós (fragmentos) do seu grupo de replicação, certifique-se ElastiCache de que todos os seus dados caibam nos fragmentos restantes. Se os dados couberem, os fragmentos especificados (`NodeGroupsToRemove`) serão excluídos do grupo de replicação como solicitado e seus espaços de chave serão mapeados para os fragmentos restantes. Se os dados não couberem nos grupos de nós restantes, o processo será encerrado e o grupo de replicação será deixado com a mesma configuração do grupo de nós anterior à solicitação.
Você pode usar a ElastiCache API para remover um ou mais fragmentos do seu cluster Valkey ou Redis OSS (modo de cluster ativado). Não é possível remover todos os fragmentos de um grupo de replicação. Nesse caso, você deve excluir o grupo de replicação. Para obter mais informações, consulte [Exclusão de um grupo de replicação](Replication.DeletingRepGroup.md).
Use os parâmetros a seguir com `ModifyReplicationGroupShardConfiguration`.
**Parâmetros**
+ `ApplyImmediately=true`: obrigatório. Especifica que a operação de reconfiguração de fragmento começará imediatamente.
+ `ReplicationGroupId`: obrigatório. Especifica em qual grupo de replicação (cluster) a operação de reconfiguração de fragmento será executada.
+ `NodeGroupCount`: obrigatório. Especifica o número de fragmentos (grupos de nós) que devem existir quando a operação for concluída. Ao remover fragmentos, o valor de `NodeGroupCount` deve ser menor que o número atual de fragmentos.
+ `NodeGroupsToRemove`: obrigatório quando `--node-group-count` for menor do que o número atual de grupos de nós (fragmentos). Uma lista de fragmentos (grupo de nós) IDs a serem removidos do grupo de replicação.
O procedimento a seguir descreve o processo para excluir um ou mais fragmentos.
**Example Remover fragmentos**
O exemplo a seguir remove dois grupos de nós do cluster do Valkey ou Redis OSS (modo cluster habilitado) `my-cluster` de modo que haja um total de dois grupos de nós quando a operação for concluída. Os espaços de chave dos fragmentos removidos são distribuídos uniformemente entre os fragmentos restantes.
```
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=
```
### Rebalanceamento de frgamentos online
Você pode reequilibrar os fragmentos em seu cluster Valkey ou Redis OSS (modo de cluster ativado) usando a Console de gerenciamento da AWS API, ou.AWS CLI ElastiCache
**Topics**
+ [Rebalanceamento de fragmentos online (Console)](#redis-cluster-resharding-online-rebalance-console)
+ [Rebalanceamento de fragmentos online (AWS CLI)](#redis-cluster-resharding-online-rebalance-cli)
+ [Rebalanceamento de fragmentos on-line (API) ElastiCache](#redis-cluster-resharding-online-rebalance-api)
#### Rebalanceamento de fragmentos online (Console)
O processo a seguir descreve como reconfigurar os fragmentos no seu cluster do Valkey ou Redis OSS (modo cluster habilitado) rebalanceando fragmentos por meio da Console de gerenciamento da AWS.
**Para rebalancear os espaços de chave entre os fragmentos no seu cluster do Valkey ou Redis OSS (modo cluster habilitado)**
1. Abra o ElastiCache console em [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Clusters do Valkey** ou **Clusters do Redis OSS**.
1. Escolha o nome do cluster (não a caixa à esquerda do nome do cluster) do Valkey ou Redis OSS (modo cluster habilitado) que você gostaria de rebalancear.
**dica**
Os clusters do Valkey ou Redis OSS (modo cluster habilitado) têm um valor igual ou superior a 1 na coluna **Shards** (Fragmentos).
1. Escolha **Rebalance** (Rebalancear).
1. Quando solicitado, escolha **Rebalance** (Rebalancear). Você pode ver uma mensagem semelhante a esta:*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 isso acontecer, escolha **Cancel** (Cancelar).
#### Rebalanceamento de fragmentos online (AWS CLI)
Use os parâmetros a seguir com `modify-replication-group-shard-configuration`.
**Parâmetros**
+ `-apply-immediately`: obrigatório. Especifica que a operação de reconfiguração de fragmento começará imediatamente.
+ `--replication-group-id`: obrigatório. Especifica em qual grupo de replicação (cluster) a operação de reconfiguração de fragmento será executada.
+ `--node-group-count`: obrigatório. Para rebalancear os espaços de chave entre todos os fragmentos no cluster, esse valor deve ser igual ao número atual de fragmentos.
O processo a seguir descreve como reconfigurar os fragmentos no seu cluster do Valkey ou Redis OSS (modo cluster habilitado) rebalanceando fragmentos por meio da AWS CLI.
**Example - Rebalanceando os fragmentos em um cluster**
O exemplo a seguir rebalanceia os slots no cluster do Valkey ou Redis OSS (modo cluster habilitado) `my-cluster` de modo que os slots sejam distribuídos da forma mais uniforme possível. O valor de `--node-group-count` (`4`) é o número de fragmentos atualmente no cluster.
Para Linux, macOS ou Unix:
```
aws elasticache modify-replication-group-shard-configuration \
--replication-group-id my-cluster \
--node-group-count 4 \
--apply-immediately
```
Para Windows:
```
aws elasticache modify-replication-group-shard-configuration ^
--replication-group-id my-cluster ^
--node-group-count 4 ^
--apply-immediately
```
#### Rebalanceamento de fragmentos on-line (API) ElastiCache
Você pode usar a ElastiCache API para reconfigurar os fragmentos em seu cluster Valkey ou Redis OSS (modo de cluster ativado) on-line usando a operação. `ModifyReplicationGroupShardConfiguration`
Use os parâmetros a seguir com `ModifyReplicationGroupShardConfiguration`.
**Parâmetros**
+ `ApplyImmediately=true`: obrigatório. Especifica que a operação de reconfiguração de fragmento começará imediatamente.
+ `ReplicationGroupId`: obrigatório. Especifica em qual grupo de replicação (cluster) a operação de reconfiguração de fragmento será executada.
+ `NodeGroupCount`: obrigatório. Para rebalancear os espaços de chave entre todos os fragmentos no cluster, esse valor deve ser igual ao número atual de fragmentos.
O processo a seguir descreve como reconfigurar os fragmentos em seu cluster Valkey ou Redis OSS (modo de cluster ativado) reequilibrando os fragmentos usando a API. ElastiCache
**Example - Rebalanceamento do cluster**
O exemplo a seguir rebalanceia os slots no cluster do Valkey ou Redis OSS (modo cluster habilitado) `my-cluster` de modo que os slots sejam distribuídos da forma mais uniforme possível. O valor de `NodeGroupCount` (`4`) é o número de fragmentos atualmente no 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=
```
# Escalabilidade vertical online com modificação do tipo de nó
Ao usar a escalabilidade vertical on-line com o Valkey versão 7.2 ou mais recente, ou Redis OSS versão 3.2.10 ou mais recente, você pode escalar clusters do Valkey ou Redis OSS dinamicamente com tempo de inatividade mínimo. Isso permite que o cluster do Valkey ou Redis OSS veicule solicitações mesmo ao ser escalado.
**nota**
Não há compatibilidade com escalabilidade entre um cluster de classificação de dados em níveis (p. ex., um cluster que use um tipo de nó r6gd) e um cluster sem classificação de dados em níveis (p. ex., um cluster que use um tipo de nó r6g). Para obter mais informações, consulte [Classificação de dados em níveis no ElastiCache](data-tiering.md).
Você pode fazer o seguinte:
+ **Aumentar a escala verticalmente**: aumente a capacidade de leitura e gravação ajustando o tipo de nó do cluster do Valkey ou Redis OSS para usar um tipo de nó maior.
ElastiCache redimensiona dinamicamente seu cluster enquanto permanece on-line e atende às solicitações.
+ **Redução de escala vertical**: reduza a capacidade de leitura e gravação ajustando o tipo de nó para usar um nó menor. Novamente, redimensiona ElastiCache dinamicamente seu cluster enquanto permanece on-line e atende às solicitações. Nesse caso, você reduz os custos diminuindo o nó.
**nota**
Os processos de expansão e redução dependem da criação de clusters com tipos de nó recém-selecionados e da sincronização dos novos nós com os anteriores. Para garantir um up/down fluxo de escala suave, faça o seguinte:
Verifique se você tem capacidade suficiente de ENI (interface de rede elástica). Se estiver reduzindo, garanta que o nó menor tenha memória suficiente para absorver o tráfego esperado.
Para ver as melhores práticas para o gerenciamento da memória, consulte [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md).
Embora o processo de escalabilidade vertical seja desenvolvido para permanecer totalmente online, ele depende da sincronização dos dados entre o nó antigo e o novo nó. Recomendamos iniciar a expansão/redução no horário em que você acredita que o tráfego de dados seja mínimo.
Teste o comportamento de seu aplicativo durante a escalabilidade em um ambiente de preparação, se possível.
**Contents**
+ [Aumento de escala vertical online](#redis-cluster-vertical-scaling-scaling-up)
+ [Aumento de escala na vertical de clusters do Valkey ou Redis OSS (console)](#redis-cluster-vertical-scaling-console)
+ [Aumento da escala na vertical de clusters do Valkey ou Redis OSS (AWS CLI)](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Ampliando clusters OSS Valkey ou Redis (API) ElastiCache](#VeticalScaling.RedisReplGrps.ScaleUp.API)
+ [Redução de escala vertical online](#redis-cluster-vertical-scaling-scaling-down)
+ [Redução de escala na vertical de clusters do Valkey ou Redis OSS (console)](#redis-cluster-vertical-scaling-down-console)
+ [Redução de escala na vertical de clusters do Valkey ou Redis OSS (AWS CLI)](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Reduzindo a escala de clusters OSS Valkey ou Redis (API) ElastiCache](#Scaling.Vertical.ScaleDown.API)
## Aumento de escala vertical online
**Topics**
+ [Aumento de escala na vertical de clusters do Valkey ou Redis OSS (console)](#redis-cluster-vertical-scaling-console)
+ [Aumento da escala na vertical de clusters do Valkey ou Redis OSS (AWS CLI)](#Scaling.RedisStandalone.ScaleUp.CLI)
+ [Ampliando clusters OSS Valkey ou Redis (API) ElastiCache](#VeticalScaling.RedisReplGrps.ScaleUp.API)
### Aumento de escala na vertical de clusters do Valkey ou Redis OSS (console)
O procedimento a seguir descreve como escalar um cluster OSS Valkey ou Redis usando o ElastiCache Management Console. Durante esse processo, o cluster continuará a atender solicitações com tempo de inatividade mínimo.
**Para aumentar a escala verticalmente de um cluster do Valkey ou Redis OSS (console)**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Clusters do Valkey** ou **Clusters do Redis OSS**.
1. Na lista de clusters, escolha o cluster.
1. Escolha **Modificar**.
1. No assistente **Modify Cluster**:
1. Na lista **Node type**, escolha o tipo de nó a partir do qual você deseja escalar. Para expandir, selecione um tipo de nó maior do que o nó existente.
1. Se quiser executar o processo de expansão imediatamente, escolha a caixa **Apply immediately (Aplicar imediatamente)**. Se a caixa **Apply immediately** não for escolhida, o processo de expansão será realizado durante a próxima janela de manutenção desse cluster.
1. Escolha **Modificar**.
Se você escolheu **Apply immediately** na etapa anterior, o status do cluster mudará para *modifying*. Quando o status mudar para *available*, a modificação estará completa, e você poderá começar a usar o novo cluster.
### Aumento da escala na vertical de clusters do Valkey ou Redis OSS (AWS CLI)
O procedimento a seguir descreve como aumentar a escala verticalmente de um cluster do Valkey ou Redis OSS usando a AWS CLI. Durante esse processo, o cluster continuará a atender solicitações com tempo de inatividade mínimo.
**Como aumentar a escala verticalmente de um cluster do Valkey ou Redis OSS (AWS CLI)**
1. Determine os tipos de nós para os quais você pode escalar executando o AWS CLI`list-allowed-node-type-modifications` comando com o parâmetro a seguir.
Para Linux, macOS ou Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Para Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
A saída do comando acima é semelhante a esta (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 "
],
}
```
Para obter mais informações, consulte [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) na *AWS CLI Referência*.
1. Modifique seu grupo de replicação para escalar até o novo tipo de nó maior usando o AWS CLI`modify-replication-group` comando e os parâmetros a seguir.
+ `--replication-group-id`: o nome do grupo de replicação que você está aumentando a escala vertical.
+ `--cache-node-type`: o novo tipo de nó para o qual você deseja escalar o cluster. Esse valor deve ser um dos tipos de nós retornados pelo comando `list-allowed-node-type-modifications` na etapa 1.
+ `--cache-parameter-group-name` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `--apply-immediately`: faz com que o processo de aumento de escala vertical seja aplicado imediatamente. Para adiar o processo de expansão para a próxima janela de manutenção do cluster, use o parâmetro `--no-apply-immediately`.
Para Linux, macOS ou Unix:
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.m3.xlarge \
--apply-immediately
```
Para Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.m3.xlarge ^
--apply-immediately
```
A saída do comando acima é semelhante a esta (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": {}
}
}
```
Para obter mais informações, consulte [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) na *AWS CLI Referência*.
1. Se você usou o`--apply-immediately`, verifique o status do cluster usando o AWS CLI`describe-cache-clusters` comando com o parâmetro a seguir. Quando o status mudar para *available*, você poderá começar a usar o novo nó de cluster maior.
### Ampliando clusters OSS Valkey ou Redis (API) ElastiCache
O processo a seguir escala seu cluster do tipo de nó atual para um novo tipo de nó maior usando a ElastiCache API. Durante esse processo, ElastiCache atualiza as entradas de DNS para que elas apontem para os novos nós. Por isso, você não precisa atualizar os endpoints no seu aplicativo. Para o Valkey 7.2 e superiores, Redis OSS 5.0.5 e superiores, você pode escalar clusters habilitados para failover automático enquanto o cluster continua on-line e atendendo a solicitações recebidas. No Redis OSS versão 4.0.10 e anteriores, você pode notar uma breve interrupção de leituras e gravações em versões anteriores do nó primário enquanto a entrada do DNS é atualizada.
O tempo necessário para aumentar a escala verticalmente até um tipo de nó maior varia, dependendo do tipo de nó e da quantidade de dados no seu cluster atual.
**Para escalar um cluster de cache (API) Valkey ou Redis OSS ElastiCache**
1. Determine para quais tipos de nós você pode escalar usando a `ListAllowedNodeTypeModifications` ação da ElastiCache API com o parâmetro a seguir.
+ `ReplicationGroupId` - o nome do grupo de replicação. Use esse parâmetro para descrever um determinado grupo de replicação em vez de todos os grupos de replicação.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) a *Amazon ElastiCache API Reference*.
1. Dimensione seu grupo de replicação atual até o novo tipo de nó usando a ação da `ModifyReplicationGroup` ElastiCache API e com os parâmetros a seguir.
+ `ReplicationGroupId` - o nome do grupo de replicação.
+ `CacheNodeType`: o novo tipo de nó maior dos clusters nesse grupo de replicação. Esse valor deve ser um dos tipos de instância retornados pela ação `ListAllowedNodeTypeModifications` na etapa anterior.
+ `CacheParameterGroupName` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `ApplyImmediately`: defina como `true` para fazer com que o processo de aumento de escala vertical seja aplicado imediatamente. Para adiar o processo de expansão para a próxima janela de manutenção, use `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=
```
Para obter mais informações, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) a *Amazon ElastiCache API Reference*.
1. Se você usou `ApplyImmediately``=true`, monitore o status do grupo de replicação usando a `DescribeReplicationGroups` ação da ElastiCache API com os parâmetros a seguir. Quando o status mudar de *modifying* para *available*, você poderá começar a gravar no seu novo grupo de replicação expandido.
+ `ReplicationGroupId` - o nome do grupo de replicação. Use esse parâmetro para descrever um grupo de replicação específico em vez de todos os grupos de replicação.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=DescribeReplicationGroups
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [DescribeReplicationGroups](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeReplicationGroups.html) a *Amazon ElastiCache API Reference*.
## Redução de escala vertical online
**Topics**
+ [Redução de escala na vertical de clusters do Valkey ou Redis OSS (console)](#redis-cluster-vertical-scaling-down-console)
+ [Redução de escala na vertical de clusters do Valkey ou Redis OSS (AWS CLI)](#Scaling.RedisStandalone.ScaleDown.CLI)
+ [Reduzindo a escala de clusters OSS Valkey ou Redis (API) ElastiCache](#Scaling.Vertical.ScaleDown.API)
### Redução de escala na vertical de clusters do Valkey ou Redis OSS (console)
O procedimento a seguir descreve como reduzir um cluster OSS Valkey ou Redis usando o ElastiCache Management Console. Durante esse processo, o cluster do Valkey ou Redis OSS continuará a atender solicitações com tempo de inatividade mínimo.
**Para reduzir a escala verticalmente de um cluster do Valkey ou Redis OSS (console)**
1. Faça login no Console de gerenciamento da AWS e abra o ElastiCache console em [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. No painel de navegação, escolha **Clusters do Valkey** ou **Clusters do Redis OSS**.
1. Na lista de clusters, escolha seu cluster preferido.
1. Escolha **Modificar**.
1. No assistente **Modify Cluster**:
1. Na lista **Node type**, escolha o tipo de nó a partir do qual você deseja escalar. Para reduzir, selecione um tipo de nó menor do que o nó existente. Observe que nem todos os tipos de nó estão disponíveis para redução.
1. Se quiser executar o processo de redução imediatamente, escolha a caixa **Apply immediately (Aplicar imediatamente)**. Se a caixa **Apply immediately (Aplicar imediatamente)** não for escolhida, o processo de redução será realizado durante a próxima janela de manutenção desse cluster.
1. Escolha **Modificar**.
Se você escolheu **Apply immediately** na etapa anterior, o status do cluster mudará para *modifying*. Quando o status mudar para *available*, a modificação estará completa, e você poderá começar a usar o novo cluster.
### Redução de escala na vertical de clusters do Valkey ou Redis OSS (AWS CLI)
O procedimento a seguir descreve como reduzir a escala verticalmente de um cluster do Valkey ou Redis OSS usando a AWS CLI. Durante esse processo, o cluster continuará a atender solicitações com tempo de inatividade mínimo.
**Como reduzir a escala verticalmente de um cluster do Valkey ou Redis OSS (AWS CLI)**
1. Determine os tipos de nós para os quais você pode reduzir executando o AWS CLI`list-allowed-node-type-modifications` comando com o parâmetro a seguir.
Para Linux, macOS ou Unix:
```
aws elasticache list-allowed-node-type-modifications \
--replication-group-id my-replication-group-id
```
Para Windows:
```
aws elasticache list-allowed-node-type-modifications ^
--replication-group-id my-replication-group-id
```
A saída do comando acima é semelhante a esta (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"
]
}
```
Para obter mais informações, consulte [list-allowed-node-type-modifications](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-allowed-node-type-modifications.html) na *AWS CLI Referência*.
1. Modifique seu grupo de replicação para reduzi-lo ao novo tipo de nó menor, usando o AWS CLI`modify-replication-group` comando e os parâmetros a seguir.
+ `--replication-group-id`: o nome do grupo de replicação que você está reduzindo a escala na vertical.
+ `--cache-node-type`: o novo tipo de nó para o qual você deseja escalar o cluster. Esse valor deve ser um dos tipos de nós retornados pelo comando `list-allowed-node-type-modifications` na etapa 1.
+ `--cache-parameter-group-name` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `--apply-immediately`: faz com que o processo de aumento de escala vertical seja aplicado imediatamente. Para adiar o processo de redução para a próxima janela de manutenção do cluster, use o parâmetro `--no-apply-immediately`.
Para Linux, macOS ou Unix:
```
aws elasticache modify-replication-group \
--replication-group-id my-redis-cluster \
--cache-node-type cache.t2.micro \
--apply-immediately
```
Para Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id my-redis-cluster ^
--cache-node-type cache.t2.micro ^
--apply-immediately
```
A saída do comando acima é semelhante a esta (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": {}
}
}
```
Para obter mais informações, consulte [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html) na *AWS CLI Referência*.
1. Se você usou o`--apply-immediately`, verifique o status do cluster usando o AWS CLI`describe-cache-clusters` comando com o parâmetro a seguir. Quando o status mudar para *available*, você poderá começar a usar o novo nó de cluster menor.
### Reduzindo a escala de clusters OSS Valkey ou Redis (API) ElastiCache
O processo a seguir escala seu grupo de replicação do tipo de nó atual para um novo tipo de nó menor usando a ElastiCache API. Durante esse processo, o cluster do Valkey ou Redis OSS continuará a atender solicitações com tempo de inatividade mínimo.
O tempo necessário para reduzir a escala verticalmente até um tipo de nó menor varia, dependendo do tipo de nó e da quantidade de dados no seu cluster atual.
**Redução de escala (ElastiCache API)**
1. Determine quais tipos de nós você pode reduzir usando a `ListAllowedNodeTypeModifications` ação da ElastiCache API com o parâmetro a seguir.
+ `ReplicationGroupId` - o nome do grupo de replicação. Use esse parâmetro para descrever um determinado grupo de replicação em vez de todos os grupos de replicação.
```
https://elasticache.us-west-2.amazonaws.com/
?Action=ListAllowedNodeTypeModifications
&ReplicationGroupId=MyReplGroup
&Version=2015-02-02
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20150202T192317Z
&X-Amz-Credential=
```
Para obter mais informações, consulte [ListAllowedNodeTypeModifications](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListAllowedNodeTypeModifications.html) a *Amazon ElastiCache API Reference*.
1. Reduza seu grupo de replicação atual para o novo tipo de nó usando a ação da `ModifyReplicationGroup` ElastiCache API e com os parâmetros a seguir.
+ `ReplicationGroupId` - o nome do grupo de replicação.
+ `CacheNodeType`: o novo tipo de nó menor dos clusters nesse grupo de replicação. Esse valor deve ser um dos tipos de instância retornados pela ação `ListAllowedNodeTypeModifications` na etapa anterior.
+ `CacheParameterGroupName` – [Opcional] Use esse parâmetro se estiver usando `reserved-memory` para gerenciar a memória reservada do cluster. Especifique um parameter group de cache personalizado que reserve a quantidade correta de memória para o seu novo tipo de nó. Se estiver usando `reserved-memory-percent`, você poderá omitir esse parâmetro.
+ `ApplyImmediately`: defina como `true` para fazer com que o processo de redução seja aplicado imediatamente. Para adiar o processo de redução até a próxima janela de manutenção, use `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=
```
Para obter mais informações, consulte [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html) a *Amazon ElastiCache API Reference*.
# Conceitos básicos do filtro Bloom
ElastiCache suporta a estrutura de dados do filtro Bloom, que fornece uma estrutura de dados probabilística eficiente em termos de espaço para verificar se um elemento é membro de um conjunto. Ao usar filtros Bloom, falsos positivos são possíveis: um filtro pode indicar incorretamente que um elemento existe, mesmo que esse elemento não tenha sido adicionado ao conjunto. No entanto, o uso de filtros Bloom evitará falsos *negativos*, indicações incorretas de que um elemento *não* existe, mesmo que esse elemento tenha sido adicionado ao conjunto.
Você pode definir a porcentagem de possíveis falsos positivos como uma taxa preferencial para sua workload, ajustando a taxa de fp. Você também pode configurar a capacidade (o número de itens que um filtro Bloom pode conter), propriedades escaláveis e não escaláveis e muito mais.
Depois que você criar um cluster com uma versão de mecanismo compatível, o tipo de dados do Bloom e os comandos associados estarão disponíveis automaticamente. O tipo de dados `bloom` é compatível com a API com a sintaxe do comando de filtro Bloom das bibliotecas de cliente oficiais da Valkey, incluindo `valkey-py`, `valkey-java` e `valkey-go`. Você pode migrar facilmente os aplicativos Valkey e Redis OSS existentes baseados em Bloom para o. ElastiCache Para obter uma lista completa de comandos, consulte [Comandos de filtro Bloom](#SupportedCommandsBloom).
As métricas relacionadas ao Bloom`BloomFilterBasedCmds`,`BloomFilterBasedCmdsLatency`, e `BloomFilterBasedCmdsECPUs` são incorporadas CloudWatch para monitorar o uso desse tipo de dados. Para obter mais informações, consulte [Métricas para o Valkey e Redis OSS](CacheMetrics.Redis.md).
**nota**
Para usar os filtros Bloom, você deve estar executando o ElastiCache Valkey 8.1 e versões posteriores.
O tipo de dados bloom não é compatível com RDB com outras ofertas de bloom não baseadas em Valkey.
## Visão geral do tipo de dados do filtro Bloom
Os filtros Bloom são uma estrutura de dados probabilística eficiente em termos de espaço que permite adicionar elementos e verificar se existem elementos. Falsos positivos são possíveis quando um filtro indica incorretamente que um elemento existe, mesmo que ele não tenha sido adicionado. No entanto, os filtros Bloom garantem que falsos negativos (indicando incorretamente que um elemento não existe, mesmo que tenha sido adicionado) não ocorram.
A principal fonte de documentação dos filtros bloom pode ser encontrada na página de documentação do valkey.io. Ela contém as seguintes informações:
+ [Casos de uso comuns para filtros bloom](https://valkey.io/topics/bloomfilters/#common-use-cases-for-bloom-filters)
+ Desduplicação de anúncios e eventos
+ Detecção de fraudes
+ Filtro de conteúdo nocivo/spam
+ Detecção exclusiva de usuários
+ [Diferenças entre filtros bloom escaláveis e não escaláveis](https://valkey.io/topics/bloomfilters/#scaling-and-non-scaling-bloom-filters)
+ Como decidir entre filtros bloom escaláveis e não escaláveis
+ [Propriedades do Bloom](https://valkey.io/topics/bloomfilters/#bloom-properties)
+ Saiba mais sobre as propriedades ajustáveis dos filtros Bloom. Isso inclui a taxa de falsos positivos, a capacidade, as propriedades de escalabilidade e não escalabilidade e muito mais.
+ [Desempenho dos comandos bloom](https://valkey.io/topics/bloomfilters/#performance)
+ [Monitoração das estatísticas gerais do filtro bloom](https://valkey.io/topics/bloomfilters/#monitoring)
+ [Manipulação de grandes filtros bloom](https://valkey.io/topics/bloomfilters/#handling-large-bloom-filters)
+ Recomendações e detalhes sobre como verificar se um filtro bloom está atingindo seu limite de uso de memória e se ele pode ser dimensionado para atingir a capacidade desejada.
+ É possível verificar a quantidade de memória usada por um documento do filtro bloom usando o comando [BF.INFO](https://valkey.io/commands/bf.info/).
## Limite de tamanho do bloom
O consumo de memória por um único objeto de filtro Bloom é limitado a 128 MB. É possível verificar a quantidade de memória consumida por um filtro JSON usando o comando `BF.INFO SIZE`.
## Bloom ACLs
Semelhante às categorias existentes por tipo de dados (@string, @hash etc.), uma nova categoria @bloom foi adicionada para simplificar o gerenciamento do acesso a comandos e dados do JSON. Nenhum outro comando do Valkey ou Redis OSS existente é membro da categoria @bloom.
Existem 3 categorias existentes de ACL que são atualizadas para incluir os novos comandos Bloom: @read, @write e @fast. A tabela a seguir indica o mapeamento de comandos Bloom para as categorias apropriadas.
| Comando Bloom | @read | @write | @fast | @bloom |
| --- | --- | --- | --- | --- |
| BF.ADD | | y | y | y |
| BF.CARD | y | | y | y |
| BF.EXISTS | y | | y | y |
| BF.INFO | y | | y | y |
| BF.INSERT | | y | y | y |
| BF.MADD | | y | y | y |
| BF.MEXISTS | y | | y | y |
| BF.RESERVE | y | | y | y |
## Métricas relacionadas ao filtro Bloom
As seguintes CloudWatch métricas relacionadas às estruturas de dados do Bloom são fornecidas:
| Métricas do CW | Unidade | Tecnologia sem servidor/baseado em nós | Description |
| --- | --- | --- | --- |
| BloomFilterBasedCmds | Contagem | Ambos | O número total de comandos Bloom, incluindo comandos de leitura e gravação. |
| BloomFilterBasedCmdsLatency | Microssegundos | Autogerenciado | Latência de todos os comandos de filtro Bloom, incluindo comandos de leitura e gravação. |
| BloomFilterBasedCmdsECPUs | Contagem | Sem servidor | ECPUs consumido por todos os comandos do filtro Bloom, incluindo comandos de leitura e gravação. |
## Comandos de filtro Bloom
Os [comandos de filtro Bloom](https://valkey.io/commands/#bloom) estão documentados no site [Valkey.io.](https://valkey.io/) Cada página de comando fornece uma visão geral abrangente dos comandos bloom, incluindo sua sintaxe, comportamento, valores de retorno e possíveis condições de erro.
| Name (Nome) | Description |
| --- | --- |
| [BF.ADD](https://valkey.io/commands/bf.add/) | Adiciona um único item a um filtro bloom. Se o filtro ainda não existir, ele será criado. |
| [BF.CARD](https://valkey.io/commands/bf.card/) | Retorna a cardinalidade de um filtro bloom. |
| [BF.EXISTS](https://valkey.io/commands/bf.exists/) | Determina se o filtro bloom contém o item especificado. |
| [BF.INFO](https://valkey.io/commands/bf.info/) | Retorna informações de uso e propriedades de um filtro bloom específico. |
| [BF.INSERT](https://valkey.io/commands/bf.insert/) | Cria um filtro bloom com 0 ou mais itens ou adiciona itens a um filtro bloom existente. |
| [BF.MADD](https://valkey.io/commands/bf.madd/) | Adiciona um ou mais itens a um filtro bloom. |
| [BF.MEXISTS](https://valkey.io/commands/bf.mexists/) | Determina se o filtro bloom contém 1 ou mais itens. |
| [BF.RESERVE](https://valkey.io/commands/bf.reserve/) | Cria um filtro bloom vazio com as propriedades especificadas. |
**nota**
**O BF.LOAD** não é suportado pelo. ElastiCache É relevante apenas para o uso do AOF, que ElastiCache não oferece suporte.
# Introdução ao Watch em Serverless
ElastiCache suporta o `WATCH` comando, que permite monitorar as chaves em busca de alterações e executar [transações](https://valkey.io/topics/transactions/) condicionais. O `WATCH` comando é particularmente útil para aplicativos que exigem controle otimista de simultaneidade, garantindo que as transações sejam executadas somente se as chaves monitoradas não tiverem sido modificadas. Isso inclui modificações feitas por um cliente, como comandos de gravação, e pelo próprio Valkey, como expiração ou despejo. Se as chaves forem modificadas a partir do momento em que foram configuradas `WATCH` e no momento em `EXEC` que foram recebidas, toda a transação será abortada.
Para ElastiCache Serverless, as seguintes restrições são introduzidas -
ElastiCache O Serverless `WATCH` tem como escopo um único slot de hash. Isso significa que somente as chaves mapeadas para o mesmo slot de hash podem ser monitoradas ao mesmo tempo pela mesma conexão, e a transação que segue os comandos de observação só pode operar no mesmo slot de hash. Quando um aplicativo tenta monitorar chaves de diferentes slots de hash ou executar comandos de transação que operam em chaves mapeadas para um slot de hash diferente do das chaves monitoradas, um `CROSSSLOT` erro será retornado. [As tags de hash](https://valkey.io/topics/cluster-spec/#hash-tags) podem ser usadas para garantir que várias chaves sejam mapeadas no mesmo slot de hash.
Além disso, `SCAN` o comando não pode ser executado dentro de uma conexão com teclas monitoradas e retornará `command not supported during watch state` um erro.
A transação será abortada (como se as teclas monitoradas tivessem sido tocadas) quando a ElastiCache Serverless não tiver certeza se uma chave foi modificada. Por exemplo, quando um slot foi migrado e as chaves monitoradas não podem ser encontradas no mesmo nó.
**Exemplos de código**
## Observe e opere teclas de diferentes slots
No exemplo a seguir, a chave monitorada e a chave especificada no `SET` comando mapeiam para diferentes slots de hash. A execução retorna um`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
```
## Observe e opere as teclas do mesmo slot
O exemplo a seguir mostra uma transação bem-sucedida, pois a chave definida `WATCH` não foi alterada.
```
> WATCH foo:{005119}
OK
> MULTI
OK
> SET bar:{005119} 1234
QUEUED
> EXEC
1) OK
```
## Observe as teclas de diferentes slots
No exemplo a seguir, uma tentativa de `WATCH` digitar chaves de slots diferentes simultaneamente na mesma conexão de cliente retorna `CROSSSLOT ERROR` a.
```
> WATCH foo:{005119}
OK
> WATCH bar:{123455}
CROSSSLOT Keys in request don't hash to the same slot
```
## Limite do relógio
Cada conexão de cliente pode assistir até 1000 teclas ao mesmo tempo.
## Comandos suportados relacionados ao Watch
Os comandos [WATCH](https://valkey.io/commands/watch/) e [UNWATCH](https://valkey.io/commands/unwatch/) estão documentados no site [Valkey.io](https://valkey.io/). Ele fornece uma visão geral abrangente dos comandos, incluindo sua sintaxe, comportamento, valores de retorno e possíveis condições de erro.
# Conceitos básicos de pesquisa vetorial
O Amazon ElastiCache for Valkey oferece suporte à pesquisa vetorial, permitindo que você armazene, pesquise e atualize bilhões de incorporações vetoriais de alta dimensão na memória com latências de até microssegundos e recuperação superior a 99%. ElastiCache for Valkey fornece recursos para indexar, pesquisar e atualizar bilhões de incorporações vetoriais de alta dimensão de fornecedores populares como Amazon Bedrock, SageMaker Amazon, Anthropic ou OpenAI para busca e recuperação rápidas. A pesquisa vetorial da Amazon ElastiCache é ideal para casos de uso em que desempenho e escalabilidade máximos são os critérios de seleção mais importantes. Isso inclui geração cache semântico, aumentada de recuperação, recomendações em tempo real, personalização e detecção de anomalias.
A pesquisa vetorial pode ser usada em conjunto com outros ElastiCache recursos para aprimorar seus aplicativos. A pesquisa vetorial por ElastiCache está disponível na versão 8.2 do Valkey em clusters baseados em nós em todas as [AWS regiões](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/), sem custo adicional. Para começar, crie um novo cluster Valkey 8.2 usando o [Console de gerenciamento da AWS](https://console.aws.amazon.com/elasticache/),AWS SDK ou.AWS CLI Também é possível usar a pesquisa vetorial no cluster existente atualizando de qualquer versão anterior do Valkey ou Redis OSS para o Valkey 8.2 em [alguns cliques, sem tempo de inatividade.](VersionManagement.HowTo.md)
# Visão geral sobre a pesquisa vetorial
ElastiCache for Valkey fornece recursos para indexar, pesquisar e atualizar bilhões de incorporações vetoriais de alta dimensão. A pesquisa vetorial permite criar, manter e usar índices secundários para uma pesquisa eficiente e escalável. Cada operação de pesquisa vetorial se aplica a um único índice. As operações de índice se aplicam somente ao índice especificado. Qualquer número de operações pode ser emitido contra qualquer índice a qualquer momento, com exceção das operações de criação e exclusão de índices. No nível do cluster, várias operações em vários índices podem estar em andamento simultaneamente.
Neste documento, os termos chave, linha e registro são idênticos e usados de maneira intercambiável. Da mesma forma, os termos coluna, campo, caminho e membro também são usados de maneira intercambiável.
O comando `FT.CREATE` pode ser usado para criar um índice para um subconjunto de chaves com os tipos de índice especificados. O comando `FT.SEARCH` realiza consultas nos índices criados e `FT.DROPINDEX` remove um índice existente e todos os dados associados. Não há comandos especiais para adicionar, excluir ou modificar dados indexados. Os comandos `HASH` ou `JSON` existentes que modificam uma chave em um índice atualizam automaticamente esse índice.
**Topics**
+ [Índices e o espaço de chaves do Valkey OSS](#indexes-keyspace)
+ [Tipos de campos de índice](#index-field-types)
+ [Algoritmos de índice vetorial](#vector-index-algorithms)
+ [Segurança da pesquisa vetorial](#vector-search-security)
## Índices e o espaço de chaves do Valkey OSS
Índices são construídos e mantidos em um subconjunto do espaço de chaves do Valkey OSS. O espaço de chaves para cada índice é definido por uma lista de prefixos de chave que são fornecidos quando esse índice é criado. A lista de prefixos é opcional e, se omitida, todo o espaço de chaves fará parte desse índice. Vários índices podem escolher subconjuntos separados ou sobrepostos do espaço de chaves, sem limitação.
Os índices também são digitados, pois cobrem apenas as chaves que têm um tipo correspondente. Atualmente, apenas há suporte para índices dos tipos `JSON` e `HASH`. Um índice `HASH` indexa somente as chaves `HASH` cobertas por sua lista de prefixos e, da mesma maneira, um índice `JSON` indexa somente as chaves `JSON` cobertas por sua lista de prefixos. As chaves na lista de prefixos do espaço de chaves de um índice que não têm o tipo designado são ignoradas e não afetam as operações de pesquisa.
Um índice é atualizado quando um comando modifica qualquer chave que está dentro de um espaço de chaves de um índice. O Valkey extrai automaticamente os campos declarados para cada índice e atualiza o índice com o novo valor. O processo de atualização tem três etapas. Na primeira etapa, a chave HASH ou JSON é modificada e o cliente solicitante é bloqueado. A segunda etapa é executada em segundo plano e atualiza cada um dos índices que contêm a chave modificada. Na terceira etapa, o cliente é desbloqueado. Assim, para operações de consulta realizadas na mesma conexão de uma mutação, essa alteração é imediatamente visível nos resultados da pesquisa.
A criação de um índice é um processo em várias etapas. A primeira delas é executar o comando FT.CREATE, que define o índice. A execução bem-sucedida de uma criação inicia automaticamente a segunda etapa: o preenchimento. O processo de preenchimento é executado em um thread em segundo plano e verifica o espaço de chaves em busca de chaves que estejam na lista de prefixos do novo índice. Cada chave encontrada é adicionada ao índice. Por fim, todo o espaço de chaves é verificado, concluindo o processo de criação do índice. Enquanto o processo de preenchimento está em execução, são permitidas mutações das chaves indexadas, não há restrições, e o processo de preenchimento do índice não será concluído até que todas as chaves estejam devidamente indexadas. Tentativas de operações de consulta feitas enquanto um índice está sendo preenchido não são permitidas e serão encerradas com um erro. O comando FT.INFO retorna o status do processo de preenchimento no campo 'backfill\$1status'.
## Tipos de campos de índice
Cada índice tem um tipo específico que é declarado quando esse índice é criado junto com um local de um campo (coluna) para ser indexado. Para chaves `HASH`, a localização é o nome do campo dentro do `HASH`. Para chaves `JSON`, a localização é uma descrição do caminho do JSON. Quando uma chave é modificada, os dados associados aos campos declarados são extraídos, convertidos no tipo declarado e armazenados no índice. Se os dados estiverem ausentes ou não puderem ser convertidos com êxito no tipo declarado, esse campo será omitido do índice. Há três tipos de campos, conforme explicado a seguir:
+ **Campos vetoriais** contêm um vetor de números, também conhecido como incorporação de vetores. Os campos vetoriais podem ser usados para filtrar vetores com base em métricas de distância especificadas que medem a similaridade. No caso de índices `HASH`, o campo deve conter todo o vetor codificado em formato binário (little-endian IEEE 754). No caso de chaves `JSON`, o caminho deve fazer referência a uma matriz do tamanho correto preenchida com números. Quando uma matriz JSON é usada como um campo vetorial, a representação interna dessa matriz na chave JSON é convertida no formato exigido pelo algoritmo selecionado, reduzindo o consumo e a precisão da memória. Operações de leitura subsequentes usando os comandos JSON produzirão o valor de precisão reduzido.
+ **Campos numéricos** contêm um único número. Campos numéricos podem ser usados com o operador de pesquisa de intervalo. Para `HASH`, espera-se que o campo contenha o texto ASCII de um número escrito no formato padrão para números fixos ou de pontos flutuantes. Para campos `JSON`, devem ser seguidas as regras numéricas de números JSON. Independentemente da representação na chave, esse campo é convertido em um número de pontos flutuantes de 64 bits para armazenamento no índice. Como os números subjacentes são armazenados em ponto flutuante com suas limitações de precisão, as regras comuns sobre comparações numéricas para números de pontos flutuantes são aplicáveis.
+ **Campos de etiqueta** contêm zero ou mais valores de etiqueta codificados como uma única string UTF-8. Campos de etiquetas podem ser usados para filtrar consultas de equivalência de valores de etiquetas com comparação com ou sem distinção entre maiúsculas e minúsculas. A string é analisada em valores de etiquetas usando um caractere separador (o padrão é uma vírgula, mas pode ser substituído) com espaços em branco à esquerda e à direita removidos. Qualquer número de valores de etiquetas pode estar contido em um único campo de etiqueta.
## Algoritmos de índice vetorial
Dois algoritmos de índice vetorial são compatíveis no Valkey:
+ **Flat**: o algoritmo Flat é um processamento linear por força bruta de cada vetor no índice, produzindo respostas exatas dentro dos limites da precisão dos cálculos de distância. Devido ao processamento linear do índice, os tempos de execução desse algoritmo podem ser muito altos para índices grandes. Índices planos são compatíveis com velocidades de ingestão mais altas.
+ **HNSW (Hierarchical Navigable Small Worlds)**: o algoritmo HNSW é uma alternativa que fornece uma aproximação da resposta mais próxima em troca de tempos de execução substancialmente menores. O algoritmo é controlado por três parâmetros: `M`, `EF_CONSTRUCTION` e `EF_RUNTIME`. Os dois primeiros parâmetros são especificados no momento da criação do índice e não podem ser alterados. O parâmetro `EF_RUNTIME` tem um valor padrão que é especificado no momento da criação do índice, mas pode ser substituído mais tarde em qualquer operação de consulta individual. Esses três parâmetros interagem para equilibrar o consumo de memória e CPU durante operações de ingestão e consulta, bem como para controlar a qualidade da aproximação de uma pesquisa KNN exata (conhecida como taxa de recall).
No HNSW, o parâmetro M controla o número máximo de vizinhos aos quais cada nó pode se conectar, moldando a densidade do índice. Um M maior, como 32 e superior, produz um gráfico mais conectado, melhorando a velocidade de recuperação e consulta porque existem mais caminhos para alcançar vizinhos relevantes. No entanto, ele aumenta o tamanho do índice, o uso da memória e retarda a indexação. Um M menor, como 8 ou menos, gera um faster-to-build índice menor com menor uso de memória, mas o recall diminui e as consultas podem demorar mais devido ao menor número de conexões.
O parâmetro EF\$1construction determina quantas conexões candidatas são avaliadas ao criar o índice. Um EF\$1construction mais alto, como 400 e superior, significa que o indexador considera mais caminhos antes de selecionar vizinhos, resultando em um gráfico que melhora a eficiência da recuperação e da consulta posteriormente, mas ao custo de uma indexação mais lenta e maior uso de CPU e memória durante a construção. Um EF\$1construction baixo, como 64-120, acelera a indexação e reduz o uso de recursos, mas o gráfico resultante pode reduzir a recuperação e retardar as consultas, mesmo se o EF\$1runtime estiver definido como alto.
Por fim, o EF\$1runtime controla a amplitude da pesquisa durante a consulta, controlando quantos vizinhos candidatos são explorados em tempo de execução. Defini-la como alta aumenta a recuperação e a precisão, mas às custas da latência da consulta e do uso da CPU. Um EF\$1runtime baixo torna as consultas mais rápidas e leves, mas com recuperação reduzida. Ao contrário de M ou EF\$1construction, esse parâmetro não afeta o tamanho do índice ou o tempo de construção, tornando-o o parâmetro para ajustar as compensações de recuperação versus latência após a criação de um índice.
Ambos os algoritmos de pesquisa vetorial (Flat e HNSW) aceitam um parâmetro opcional `INITIAL_CAP`. Quando especificado, esse parâmetro pré-aloca memória para os índices, resultando na redução da sobrecarga de gerenciamento de memória e no aumento das taxas de ingestão de vetores. Índices planos oferecem melhores velocidades de ingestão do que o HNSW.
Algoritmos de pesquisa vetorial, como o HNSW, podem não lidar de maneira eficiente com a exclusão ou substituição de vetores inseridos anteriormente. O uso dessas operações pode resultar em consumo excessivo de memória de índice, and/or degradando a qualidade de recall. A reindexação é um método para restaurar a recuperação ideal do uso da memória. and/or
## Segurança da pesquisa vetorial
Os mecanismos de segurança de [Valkey ACL (listas de controle de acesso)](https://valkey.io/topics/acl/) para acesso a comandos e dados são estendidos para controlar o recurso de pesquisa. Há suporte total para o controle de ACL de comandos de pesquisa individuais. É fornecida uma nova categoria de ACL, `@search`, e muitas das categorias existentes (`@fast`, `@read`, `@write` etc.) são atualizadas para incluir os novos comandos. Os comandos de pesquisa não modificam os dados de chaves, o que significa que o mecanismo de ACL existente para acesso de gravação é preservado. As regras de acesso para operações `HASH` e `JSON` não são modificadas pela presença de um índice. O controle normal de acesso em nível de chave ainda é aplicado a esses comandos.
Comandos de pesquisa com um índice também têm o acesso controlado por meio da ACL. Verificações de acesso são realizadas no nível do índice inteiro, e não no nível por chave. Isso significa que o acesso a um índice será concedido a um usuário somente se este tiver permissão para acessar todas as chaves possíveis na lista de prefixos do espaço de chaves desse índice. Em outras palavras, o conteúdo real de um índice não controla o acesso. Pelo contrário, é o conteúdo teórico de um índice, conforme definido pela lista de prefixos, que é usado para a verificação de segurança. Situações em que um usuário tem acesso de leitura e and/or gravação a uma chave, mas não consegue acessar um índice contendo essa chave, são possíveis. Observe que somente o acesso para leitura ao espaço de chaves é necessário para criar ou usar um índice: a presença ou ausência do acesso para gravação não é levada em consideração.
# Atributos e limites da pesquisa vetorial
## Disponibilidade da pesquisa vetorial
A pesquisa vetorial da Amazon ElastiCache está disponível com a versão 8.2 do Valkey em clusters baseados em nós em todas as AWS regiões, sem custo adicional. Você também pode usar a pesquisa vetorial nos clusters existentes atualizando de qualquer versão do Valkey ou do Redis OSS para o Valkey 8.2, em [alguns cliques, sem tempo de inatividade](VersionManagement.HowTo.md).
Atualmente, a pesquisa vetorial está disponível em todos os tipos de ElastiCache instância, exceto nós com classificação de dados em camadas. O uso da pesquisa vetorial em instâncias t2, t3 e t4g exige aumentar a reserva de memória para pelo menos 50% para instâncias micro e 30% para instâncias pequenas. Consulte [esta página](redis-memory-management.md) para saber mais.
## Restrições paramétricas
A tabela a seguir mostra os limites de vários itens de pesquisa vetorial:
**Limites da pesquisa vetorial**
| Item | Valor máximo |
| --- | --- |
| Número de dimensões em um vetor | 32768 |
| Número de índices que podem ser criados | 10 |
| Número de campos em um índice | 50 |
| Cláusula TIMEOUT de FT.SEARCH (milissegundos) | 60000 |
| Número máximo de prefixos permitidos por índice | 16 |
| O tamanho máximo de um campo de tag | 10000 |
| O tamanho máximo de um campo numérico | 256 |
| Parâmetro HNSW M | 2000000 |
| Parâmetro HNSW EF\$1CONSTRUCTION | 4096 |
| Parâmetro HNSW EF\$1RUNTIME | 4096 |
## Restrições operacionais
### Persistência e preenchimento de índices
O processo de atualização tem três etapas. Na primeira etapa, a chave HASH ou JSON é modificada e o cliente solicitante é bloqueado. A segunda etapa é executada em segundo plano e atualiza cada um dos índices que contêm a chave modificada. Na terceira etapa, o cliente é desbloqueado. Assim, para operações de consulta realizadas na mesma conexão de uma mutação, essa alteração é imediatamente visível nos resultados da pesquisa. No entanto, a inserção ou atualização de uma chave pode não ficar visível nos resultados da pesquisa para outros clientes por um curto período. Durante períodos de grande carga do sistema (mutação and/or intensa de dados), o atraso na visibilidade pode se tornar maior.
O atributo de pesquisa vetorial mantém a definição de índices e o conteúdo dos índices. Os índices para campos vetoriais são salvos, mas os índices para TAGS e NUMERIC não são salvos, o que significa que eles devem ser reconstruídos quando carregados externamente (sincronização completa ou recarga). Isso significa que, durante qualquer solicitação ou evento operacional que faça com que um nó seja iniciado ou reiniciado, a definição e o conteúdo do índice para vetores são restaurados com base no snapshot mais recente. Nenhuma ação do usuário é necessária para iniciar isso. No entanto, para índices TAGS e NUMERIC, a reconstrução é executada como uma operação de preenchimento assim que os dados são restaurados. Isso é funcionalmente equivalente ao sistema executar automaticamente um comando FT.CREATE para cada índice definido. Observe que o nó fica disponível para operações do aplicativo assim que os dados são restaurados, mas provavelmente antes da conclusão do preenchimento do índice, o que significa que as operações de preenchimentos voltarão a ficar visíveis para as aplicações.
A conclusão do preenchimento do índice não é sincronizada entre um primário e uma réplica. Essa falta de sincronização pode se tornar inesperadamente visível para as aplicações e, portanto, é recomendável que estas verifiquem a conclusão do preenchimento nos primários e em todas as réplicas antes de iniciar as operações de pesquisa.
### Limites de escala
Durante eventos de escalabilidade, o índice pode ser preenchido conforme os dados são migrados. Isso resultará em um recall reduzido para consultas de pesquisa.
### Instantâneo import/export e migração ao vivo
Os arquivos RDB de um cluster com índices de pesquisa podem ser importados para outro cluster ElastiCache Valkey com a versão 8.2 ou superior. O novo cluster reconstruirá o conteúdo do índice ao carregar o arquivo RDB. No entanto, a presença de índices de pesquisa em um arquivo RDB limita a compatibilidade desses dados com versões anteriores do Valkey. O formato dos índices de pesquisa definidos pela funcionalidade de pesquisa vetorial só é compreendido por outro ElastiCache cluster com Valkey versão 8.2 ou superior. No entanto, arquivos RDB que não contêm índices não são restritos dessa maneira.
### Sem memória durante o preenchimento
Semelhante às operações de gravação do Valkey OSS, um preenchimento de índice está sujeito a limitações. out-of-memory Se a memória do mecanismo ficar cheia enquanto um preenchimento estiver em andamento, todos os preenchimentos serão pausados. Se a memória ficar disponível, o processo de preenchimento será retomado. É possível excluir um índice quando o preenchimento é pausado devido à falta de memória.
### Transações
Os comandos `FT.CREATE`, `FT.DROPINDEX`, `FT.ALIASADD`, `FT.ALIASDEL` e `FT.ALIASUPDATE` não podem ser executados em um contexto transacional, ou seja, não dentro de um bloco `MULTI/EXEC` ou dentro de um script LUA ou FUNCTION.
# Escolher a configuração apropriada
Na experiência do console, ElastiCache oferece uma maneira fácil de escolher o tipo de instância certo com base nos requisitos de memória e CPU da sua carga de trabalho vetorial.
## Consumo de memória
O consumo de memória é baseado no número de vetores, no número de dimensões, no valor M e na quantidade de dados não vetoriais, como metadados associados ao vetor ou outros dados armazenados na instância. A memória total necessária é uma combinação do espaço necessário para os dados vetoriais reais e o espaço necessário para os índices de vetores. O espaço necessário para dados vetoriais é calculado medindo a capacidade real necessária para armazenar vetores em estruturas de dados `HASH` ou `JSON` e a sobrecarga até as placas de memória mais próximas, para alocações de memória ideais. Cada um dos índices de vetores usa referências aos dados vetoriais armazenados nessas estruturas de dados, bem como uma cópia adicional do vetor no índice. É aconselhável planejar esse consumo adicional de espaço pelo índice.
O número de vetores depende de como você decide representar os dados como vetores. Por exemplo, você pode optar por representar um único documento em vários blocos, onde cada um representa um vetor. Como alternativa, você pode optar por representar o documento inteiro como um único vetor. O número de dimensões dos vetores depende do modelo de incorporação escolhido. Por exemplo, se você optar por usar o modelo de incorporação AWS Titan, o número de dimensões seria 1536. Observe que você deve testar o tipo de instância para garantir que ela atenda aos seus requisitos.
## Escalar a workload
A pesquisa vetorial é compatível com todos os três métodos de dimensionamento: horizontal, vertical e réplicas. Ao escalar a capacidade, a pesquisa vetorial se comporta exatamente como o Valkey normal, ou seja, aumentar a memória de nós individuais (escalabilidade vertical) ou aumentar o número de nós (escalabilidade horizontal) aumentará a capacidade geral. No modo de cluster, o comando `FT.CREATE` pode ser enviado para qualquer nó primário do cluster e o sistema distribuirá automaticamente a nova definição de índice para todos os membros do cluster.
No entanto, do ponto de vista do desempenho, a pesquisa vetorial se comporta de maneira muito diferente do Valkey normal. A implementação multisegmentada da pesquisa vetorial significa um CPUs rendimento adicional de até aumentos lineares na taxa de transferência de consulta e ingestão. A escalabilidade horizontal gera aumentos lineares no throughput de ingestão, mas pode reduzir o throughput de consultas. Se for necessária uma taxa de transferência adicional de consultas, é necessário escalar por meio de réplicas ou mais CPUs .
# Comandos de pesquisa vetorial
Veja a seguir uma lista dos comandos compatíveis com a pesquisa vetorial.
**Topics**
+ [FT.CREATE](vector-search-commands-ft.create.md)
+ [FT.SEARCH](vector-search-commands-ft.search.md)
+ [FT.DROPINDEX](vector-search-commands-ft.dropindex.md)
+ [FT.INFO](vector-search-commands-ft.info.md)
+ [FT.\$1LIST](vector-search-commands-ft.list.md)
# FT.CREATE
O comando `FT.CREATE` cria um índice vazio e inicia o processo de preenchimento. Cada índice consiste em várias definições de campo. Cada definição de campo especifica um nome de campo, um tipo de campo e um caminho dentro de cada chave indexada para localizar um valor do tipo declarado. Algumas definições de tipo de campo têm especificadores de subtipo adicionais.
Para índices em chaves HASH, o caminho é igual ao nome do membro do hash. A cláusula `AS` opcional pode ser usada para renomear o campo, se desejado. A renomeação de campos é especialmente útil quando o nome do membro contém caracteres especiais.
Em índices em chaves JSON, o caminho é um caminho JSON para os dados do tipo declarado. Como o caminho JSON sempre contém caracteres especiais, a cláusula `AS` é obrigatória.
**Sintaxe**
```
FT.CREATE
ON HASH | JSON
[PREFIX [...]]
SCHEMA
( [AS ]
| VECTOR [HNSW|FLAT] [])
| TAG [SEPARATOR ] [CASESENSITIVE]
| NUMERIC
)+
```
** (obrigatório):** esse é o nome que você dá ao seu índice. Um erro será retornado se já houver um índice com o mesmo nome.
**ON HASH \$1 JSON (opcional):** somente as chaves que correspondem ao tipo especificado são incluídas nesse índice. Se omitido, o HASH é assumido.
**PREFIX (opcional):** se essa cláusula for especificada, somente as chaves que começam com os mesmos bytes de um ou mais dos prefixos especificados serão incluídas nesse índice. Se essa cláusula for omitida, todas as chaves do tipo correto serão incluídas. Um prefixo de comprimento zero também corresponderia a todas as chaves do tipo correto.
**Tipos de campo:**
+ TAG: um campo de tag é uma string que contém um ou mais valores de tag.
+ SEPARATOR (opcional): um dos caracteres `,.<>{}[]"':;!@#$%^&*()-+=~` usados para delimitar tags individuais. Se for omitido, o padrão será `,`.
+ CASESENSITIVE (opcional): se presentes, as comparações de tags farão distinção entre maiúsculas e minúsculas. O padrão é que as comparações de tags NÃO façam distinção entre maiúsculas e minúsculas.
+ NUMERIC: um campo que contém um número.
+ VECTOR: um campo que contém um vetor. Atualmente, dois algoritmos de indexação vetorial são compatíveis: HNSW (Hierarchical Navigable Small World) e FLAT (força bruta). Cada algoritmo tem um conjunto de atributos adicionais, alguns obrigatórios e outros opcionais.
+ FLAT: o algoritmo Flat fornece respostas exatas, mas tem runtime proporcional ao número de vetores indexados e, portanto, pode não ser apropriado para grandes conjuntos de dados.
+ DIM (obrigatório): especifica o número de dimensões em um vetor.
+ TIPO FLOAT32 (obrigatório): Tipo de dados, atualmente somente FLOAT32 é suportado.
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (obrigatório): especifica o algoritmo de distância.
+ INITIAL\$1CAP (opcional): tamanho inicial do índice.
+ HNSW: o algoritmo HNSW fornece respostas aproximadas, mas opera substancialmente mais rápido que o FLAT.
+ DIM (obrigatório): especifica o número de dimensões em um vetor.
+ TIPO FLOAT32 (obrigatório): Tipo de dados, atualmente somente FLOAT32 é suportado.
+ DISTANCE\$1METRIC [L2 \$1 IP \$1 COSINE] (obrigatório): especifica o algoritmo de distância.
+ INITIAL\$1CAP (opcional): tamanho inicial do índice.
+ M (opcional): número máximo de bordas de saída permitidas para cada nó no gráfico em cada camada. Na camada zero, o número máximo de bordas de saída será 2\$1M. O padrão é 16, o máximo é 512.
+ EF\$1CONSTRUCTION (opcional): controla o número de vetores examinados durante a construção do índice. Valores mais altos para esse parâmetro melhorarão a taxa de recall às custas de tempos mais longos de criação do índice. O valor padrão é 200. O valor máximo é 4096.
+ EF\$1RUNTIME (opcional): controla o número de vetores a serem examinados durante uma operação de consulta. O valor padrão é 10 e o máximo é 4096. Você pode definir esse valor de parâmetro para cada consulta executada. Valores mais altos aumentam os tempos de consulta, mas melhoram a recuperação da consulta.
**RESPOSTA:** OK ou erro.
# FT.SEARCH
Executa uma pesquisa no índice especificado. As chaves que correspondem à expressão da consulta são retornadas.
```
FT.SEARCH
[NOCONTENT]
[RETURN ( [AS ])+]
[TIMEOUT timeout]
[PARAMS []]
[LIMIT ]
```
+ (obrigatório): o nome do índice que você deseja consultar.
+ (obrigatório): a string de consulta, veja abaixo para obter detalhes.
+ NOCONTENT (opcional): quando presente, somente os nomes de chave resultantes são retornados, nenhum valor de chave é incluído.
+ TIMEOUT (opcional): permite definir um valor de tempo limite para o comando de pesquisa. Deve ser um número inteiro em milissegundos.
+ PARAMS ... (opcional): `count` é do número de argumentos, ou seja, duas vezes o número de pares de nomes de valores. Consulte a string de consulta para obter detalhes de uso.
+ RETURN ... (opcional): contagem é o número de campos a serem retornados. Especifica os campos que você deseja recuperar dos seus documentos, junto com quaisquer aliases para os valores retornados. Por padrão, todos os campos são retornados, a menos que a opção NOCONTENT seja definida. Nesse caso, nenhum campo será retornado. Se a contagem for definida como 0, ela se comportará da mesma forma que NOCONTENT.
+ LIMIT : permite escolher uma parte do resultado. As primeiras chaves são ignoradas e apenas um máximo de chaves é incluído. O padrão é LIMIT 0 10, que retorna no máximo 10 chaves.
+ PARAMS: duas vezes o número de pares de valores-chave. Os key/value pares de parâmetros podem ser referenciados de dentro da expressão de consulta. Para obter mais informações, consulte [Expressão de consulta de pesquisa vetorial](https://docs.aws.amazon.com/memorydb/latest/devguide/vector-search-overview.html#vector-search-query-expression).
+ DIALECT: (opcional): especifica seu dialeto. O único dialeto compatível é 2.
**RESPONSE**
O comando retorna uma matriz em caso de sucesso ou um erro.
Em caso de sucesso, a primeira entrada na matriz de resposta representa a contagem de chaves correspondentes, seguida por uma entrada de matriz para cada chave correspondente. Observe que, se a opção `LIMIT` for especificada, ela controlará apenas o número de chaves retornadas e não afetará o valor da primeira entrada.
Quando `NOCONTENT` é especificado, cada entrada na resposta contém somente o nome de chave correspondente. Caso contrário, cada entrada inclui o nome de chave correspondente, seguido por uma matriz dos campos retornados. Os campos de resultado de uma chave consistem em um conjunto de name/value pares. O primeiro name/value par é para a distância calculada. O nome desse par é construído a partir do nome do campo vetorial prefixado com “\$1\$1” e anexado com “\$1score” e o valor é a distância calculada. Os name/value pares restantes são os membros e valores da chave, conforme controlado pela `RETURN` cláusula.
A string de consulta está em conformidade com esta sintaxe:
```
=>[ KNN @ $ ]
```
Em que:
+ : é um \$1 ou uma expressão de filtro. Um \$1 indica que não há filtragem e, portanto, todos os vetores dentro do índice são pesquisados. Uma expressão de filtro pode ser fornecida para designar um subconjunto dos vetores a serem pesquisados.
+ : o nome de um campo vetorial dentro do índice especificado.
+ : o número de vetores vizinhos mais próximos a serem retornados.
+ : um nome de PARAM cujo valor correspondente fornece o vetor de consulta para o algoritmo KNN. Observe que esse parâmetro deve ser codificado como um ponto flutuante binário IEEE 754 de 32 bits no formato little-endian.
+ : (Opcional) Uma lista de keyword/value pares que modificam essa pesquisa KNN específica. Atualmente, há compatibilidade para duas palavras-chave:
+ EF\$1RUNTIME: essa palavra-chave é acompanhada por um valor inteiro que substitui o valor padrão de EF\$1RUNTIME especificado quando o índice foi criado.
+ AS: essa palavra-chave é acompanhada por um valor de string que se torna o nome do campo de pontuação no resultado, substituindo o algoritmo padrão de geração do nome do campo de pontuação.
**Expressão de filtro**
Uma expressão de filtro é construída como uma combinação lógica dos operadores de pesquisa de tags e numéricos contidos entre parênteses.
**Tag**
O operador de pesquisa de tags é especificado com uma ou mais cadeias de caracteres separadas pelo caractere \$1. Uma chave satisfará o operador de pesquisa de tags se o campo indicado contiver qualquer uma das cadeias de caracteres especificadas.
```
@:{}
or
@:{ | }
or
@:{ | | ...}
```
Por exemplo, a consulta a seguir retornará documentos com a cor azul OU preta OU verde.
`@color:{blue | black | green}`
Como outro exemplo, a consulta a seguir retornará documentos contendo “hello world” ou “hello universe”.
`@description:{hello world | hello universe}`
**Intervalo numérico**
O operador de intervalo numérico permite filtrar consultas para retornar somente valores que estejam entre um determinado valor inicial e final. Tanto consultas de intervalo inclusivas quanto exclusivas são suportadas. Para comparações relacionais simples, \$1inf, -inf pode ser usado com uma consulta de intervalo. A sintaxe para um operador de pesquisa de intervalo é:
```
@:[ [(] [(] ]
```
... em que é um número \$1inf ou -inf. Os limites sem um pai aberto principal são inclusivos, enquanto os limites com o pai aberto principal são exclusivos.
Use a tabela a seguir como guia para mapear expressões matemáticas para filtrar consultas:
```
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]
```
**Operadores lógicos**
Várias tags e operadores de pesquisa numérica podem ser usados para criar consultas complexas usando operadores lógicos.
**Lógico AND**
Para definir um AND lógico, use um espaço entre os predicados. Por exemplo:
`query1 query2 query3`
**OR lógico**
Para definir um OR lógico, use um espaço entre os predicados. Por exemplo:
`query1 | query2 | query3`
**Negação lógica**
Qualquer consulta pode ser negada colocando o caractere `-` antes de cada consulta. As consultas negativas retornam todas as entradas que não correspondem à consulta. Isso também inclui chaves que não têm o campo.
Por exemplo, uma consulta negativa em @genre:\$1comedy\$1 retornará todos os livros que não são de comédia E todos os livros que não têm um campo de gênero.
A consulta a seguir retornará todos os livros do gênero “comédia” que não foram publicados entre 2015 e 2024 ou que não têm campo de ano: @genre:[comedy] - @year:[2015 2024]
**Precedência do operador**
As regras típicas de precedência do operador se aplicam, ou seja, NEGATE lógico é a prioridade mais alta, seguido pelo AND lógico e depois OR lógico com a prioridade mais baixa. Os parênteses podem ser usados para substituir a precedência padrão.
*Exemplos de combinação de operadores lógicos*
Os operadores lógicos podem ser combinados para formar expressões de filtro complexas.
A consulta a seguir retornará todos os livros do gênero “comédia” ou “terror” (AND) publicados entre 2015 e 2024: `@genre:[comedy|horror] @year:[2015 2024]`
A consulta a seguir retornará todos os livros do gênero “comédia” ou “terror” (OR) publicados entre 2015 e 2024: `@genre:[comedy|horror] | @year:[2015 2024]`
A consulta a seguir retornará todos os livros que não têm um campo de gênero ou têm um campo de gênero diferente de “comédia”, publicados entre 2015 e 2024: `-@genre:[comedy] @year:[2015 2024]`
# FT.DROPINDEX
**Sintaxe**
```
FT.DROPINDEX
```
O índice especificado é excluído. Retorna OK ou um erro se esse índice não existir.
+ (obrigatório): o nome do índice a ser excluído.
# FT.INFO
**Sintaxe**
```
FT.INFO
```
A pesquisa vetorial aumenta o comando [FT.INFO](https://valkey.io/commands/info/) com várias seções adicionais de estatísticas e contadores. Uma solicitação para recuperar a seção SEARCH recuperará todas as estatísticas a seguir:
| Nome da chave | Tipo de valor | Description |
| --- | --- | --- |
| nome\$1índice | string | Nome do índice |
| index\$1options | string | Reservado. Atualmente definido como “0" |
| index\$1definition | array | Veja abaixo a definição desses elementos da matriz. |
| attributes | matriz de informações de atributos | Um elemento nessa matriz para cada atributo definido, veja abaixo a definição das informações do atributo. |
| num\$1docs | integer | Número de chaves atualmente contidas no índice |
| num\$1terms | integer | Reservado. Definido atualmente como “0". |
| record\$1count | integer | A soma do campo “tamanho” para cada atributo. |
| hash\$1indexing\$1failures | integer | Número de vezes que um atributo não pôde ser convertido para o tipo de atributo declarado. Apesar do nome, isso também se aplica às chaves JSON. |
| backfill\$1in\$1progress | integer | Se um preenchimento estiver em andamento, será um '1', caso contrário, será um '0' |
| backfill\$1percent\$1complete | flutuação | Estimativa da conclusão do preenchimento, um número fracionário na faixa [0..1] |
| mutation\$1queue\$1size | integer | Número de chaves esperando para atualizar o índice. |
| recent\$1mutations\$1queue\$1delay | integer | Estimativa do atraso (em segundos) da atualização do índice. Será 0 se nenhuma atualização estiver em andamento. |
| estado | string | Estado de preenchimento: “ready” indica que o preenchimento foi concluído com sucesso. O estado “backfill\$1in\$1progress” indica que o preenchimento está em andamento; “backfill\$1paused\$1by\$1oom” significa que o preenchimento foi pausado devido a uma condição de pouca memória. Depois que a condição de pouca memória for resolvida, o preenchimento continuará. |
A estrutura index\$1definition é uma matriz de key/value pares definidos como:
| Nome da chave | Tipo de valor | Description |
| --- | --- | --- |
| key\$1type | string | Ou a string 'JSON' ou a string 'HASH' |
| prefixos | array | Cada elemento na matriz é um prefixo definido para o índice. Se nenhum prefixo foi especificado quando o índice foi criado, essa matriz terá 0 entradas. |
| default\$1score | string | Reservado. Atualmente definido como “1” |
Informações do atributo: as informações do atributo são específicas do tipo.
Atributos numéricos:
| Chave | Tipo de valor | Description |
| --- | --- | --- |
| Identifier | string | Localização do atributo em uma chave. Nome do membro de hash ou caminho JSON |
| alias | string | Nome do atributo usado nas descrições da consulta. |
| type | string | A string “NUMERIC” |
| size | integer | O número de chaves com valores numéricos válidos nesse atributo. |
Atributos de tags:
| Nome da chave | Tipo de valor | Description |
| --- | --- | --- |
| Identifier | string | Localização do atributo em uma chave. Nome do membro de hash ou caminho JSON |
| alias | string | Nome do atributo usado nas descrições da consulta. |
| type | string | A string “TAG” |
| SEPARATOR | caractere | O caractere separador definido quando o índice foi criado |
| CASESENSITIVE | n/a | Essa chave não tem valor associado. Ela estará presente somente se o atributo tiver sido criado com essa opção. |
| size | integer | O número de chaves com valores de tag válidos nesse atributo |
Atributos de vetores:
| Nome da chave | Tipo de valor | Description |
| --- | --- | --- |
| Identifier | string | Localização do atributo em uma chave. Nome do membro de hash ou caminho JSON |
| alias | string | Nome do atributo usado nas descrições da consulta. |
| type | string | A string “VECTOR” |
| índice | caractere | Para uma descrição mais detalhada do índice vetorial, veja abaixo. |
Descrição do índice vetorial:
| Nome da chave | Tipo de valor | Description |
| --- | --- | --- |
| capacidade | string | Capacidade atual do índice |
| dimensões | string | Número de elementos em cada vetor |
| distance\$1metric | string | Um dos seguintes: "COSINE", "L2" ou "IP" |
| size | array | Descrição do índice vetorial, veja abaixo. |
| data\$1type | string | Tipo de dados declarado. Somente "FLOAT32" é suportado atualmente. |
| algoritmo | array | Descrição adicional do algoritmo de pesquisa vetorial. |
Descrição do algoritmo de pesquisa vetorial FLAT:
| Nome da chave | Tipo de valor | Description |
| --- | --- | --- |
| name | string | Nome do algoritmo: FLAT |
| block\$1size | número | Tamanho de um bloco do índice FLAT. |
Descrição do índice vetorial HNSW:
| Nome da chave | Tipo de valor | Description |
| --- | --- | --- |
| name | string | Nome do algoritmo: HNSW |
| m | número | O parâmetro “M” para HNSW |
| ef\$1construction | número | O parâmetro "ef\$1construction" para HNSW |
| ef\$1runtime | número | O parâmetro “ef\$1runtime” para HNSW. |
# FT.\$1LIST
Liste todos os índices.
**Sintaxe**
```
FT._LIST
```
Retorna uma matriz de strings que são os nomes do índice atualmente definido.
# Conceitos básicos do JSON para Valkey e Redis OSS
O ElastiCache é compatível com o formato JavaScript Object Notation (JSON), que é uma maneira simples e sem esquema de codificar conjuntos de dados complexos em clusters do Valkey e Redis OSS. É possível armazenar e acessar dados nativamente usando o formato JavaScript Object Notation (JSON) dentro dos clusters e atualizar dados do JSON armazenados nesses clusters, sem precisar gerenciar código personalizado para serializá-los e desserializá-los.
Além de usar as operações de API do Valkey e do Redis OSS para aplicações que operam em JSON, agora é possível recuperar e atualizar com eficiência partes específicas de um documento JSON sem precisar manipular todo o objeto. Isso pode melhorar a performance e reduzir os custos. Também é possível pesquisar o conteúdo do seu documento JSON usando a consulta `JSONPath` [Goessner-style](https://goessner.net/articles/JsonPath/) (estilo Goessner).
Depois que você criar um cluster com uma versão de mecanismo compatível, o tipo de dados do JSON e os comandos associados estarão disponíveis automaticamente. Compatível com a API e o RDB com a versão 2 do módulo JSON, para que você possa migrar facilmente as aplicações baseadas em JSON do Valkey e Redis OSS para o ElastiCache. Para obter mais informações sobre os comandos compatíveis, consulte [Comandos compatíveis do Valkey e do Redis OSSComandos JSON](json-list-commands.md).
As métricas relacionadas ao JSON `JsonBasedCmds` e `JsonBasedCmdsLatency` são incorporadas ao CloudWatch para monitorar o uso desse tipo de dados. Para obter mais informações, consulte [Métricas do Valkey e Redis OSS](CacheMetrics.Redis.md).
**nota**
Para usar o JSON, é necessário estar executando o Valkey 7.2 e posteriores ou Redis OSS 6.2.6 ou posteriores.
**Topics**
+ [Visão geral do tipo de dados do JSON](json-document-overview.md)
+ [Comandos compatíveis do Valkey e do Redis OSS](json-list-commands.md)
# Visão geral do tipo de dados do JSON
O ElastiCache é compatível com vários comandos do Valkey e do Redis OSS para trabalhar com o tipo de dados do JSON. Veja a seguir uma visão geral do tipo de dados do JSON e uma lista detalhada dos comandos que são compatíveis.
## Terminologia
****
| Prazo | Descrição |
| --- | --- |
| Documento JSON | Refere-se ao valor de uma chave do JSON. |
| Valor JSON | Refere-se a um subconjunto de um documento JSON, incluindo a raiz que representa o documento inteiro. Um valor poderia ser um contêiner ou uma entrada dentro de um contêiner. |
| Elemento JSON | Equivalente ao valor JSON. |
## Padrão compatível com JSON
O formato JSON é compatível com os padrão de intercâmbio de dados do JSON [RFC 7159](https://www.ietf.org/rfc/rfc7159.txt) e [ECMA-404](https://www.ietf.org/rfc/rfc7159.txt). O padrão UTF-8 [Unicode](https://www.unicode.org/standard/WhatIsUnicode.html) é compatível com texto do JSON.
## Elemento raiz
O elemento raiz pode ser de qualquer tipo de dados do JSON. Observe que na RFC 4627 anterior, somente objetos ou matrizes eram permitidos como valores raiz. Desde a atualização para o RFC 7159, a raiz de um documento JSON pode ser de qualquer tipo de dados do JSON.
## Limite de tamanho de documentos
Os documentos JSON são armazenados internamente em um formato que é otimizado para rápido acesso e modificação. Esse formato normalmente resulta no consumo um pouco maior de memória do que a representação serializada equivalente do mesmo documento.
O consumo de memória por um único documento JSON é limitado a 64 MB, que é o tamanho da estrutura de dados na memória, não a string JSON. É possível verificar a quantidade de memória consumida por um documento JSON usando o comando `JSON.DEBUG MEMORY`.
## ACLs JSON
+ Semelhante às categorias existentes por tipo de dados (@string, @hash etc.), uma nova categoria @json foi adicionada para simplificar o gerenciamento do acesso a comandos e dados do JSON. Nenhum outro comando do Valkey ou Redis OSS existente é membro da categoria @json. Todos os comandos JSON impõem restrições e permissões de keyspace ou de comando.
+ Existem cinco categorias existentes de ACL do Valkey e do Redis OSS que foram atualizadas para incluir os novos comandos JSON: @read, @write, @fast, @slow e @admin. A tabela a seguir indica o mapeamento de comandos JSON para as categorias apropriadas.
**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 de profundidade de aninhamento
Quando um objeto ou matriz JSON tem um elemento que é outro objeto ou matriz JSON, diz-se que esse objeto interno ou matriz se “aninha” dentro do objeto ou matriz externa. O limite máximo de profundidade de aninhamento é 128. Qualquer tentativa de criar um documento que contenha uma profundidade de aninhamento maior que 128 será rejeitada com um erro.
## Sintaxe de comando
A maioria dos comandos exige um nome de chave como primeiro argumento. Alguns comandos também têm um argumento path (caminho). O argumento path (caminho) será padronizado para a raiz se for opcional e não fornecido.
Notação:
+ Os argumentos obrigatórios são colocados entre colchetes angulares. Por exemplo:
+ Os argumentos opcionais são colocados dentro de colchetes. Por exemplo: [path]
+ Os argumentos opcionais adicionais são indicados por reticências (“...”). Por exemplo: [json...]
## Sintaxe de caminho
O JSON do Redis oferece suporte a dois tipos de sintaxes de path:
+ **Sintaxe aprimorada**: veja abaixo a sintaxe JSONPath descrita por [Goessner](https://goessner.net/articles/JsonPath/), conforme mostrado na tabela a seguir. Reordenamos e modificamos as descrições na tabela para maior clareza.
+ **Sintaxe restrita** - Tem recursos de consulta limitados.
**nota**
Os resultados de alguns comandos são sensíveis ao tipo de sintaxe de caminho usado.
Se um caminho de consulta começar com '\$1', ele usará a sintaxe aprimorada. Caso contrário, a sintaxe restrita será usada.
Sintaxe aprimorada
****
| Símbolo/Expressão | Descrição |
| --- | --- |
| \$1 | O elemento raiz. |
| . ou [] | Operador filho. |
| .. | Descida recursiva. |
| \$1 | Curinga. Todos os elementos em um objeto ou matriz. |
| [] | Operador subscrito de matriz. O índice é baseado em 0. |
| [,] | Operador da união. |
| [start:end:step] | Operador de matriz slice. |
| ?() | Aplica uma expressão de filtro (script) à matriz ou objeto atual. |
| () | Expressão de filtro. |
| @ | Usado em expressões de filtro que consultam o nó atual que está sendo processado. |
| == | Igual a, usado em expressões de filtro. |
| \$1= | Não é igual a, usado em expressões de filtro. |
| > | Maior que, usado em expressões de filtro. |
| >= | Maior que ou igual a, usado em expressões de filtro. |
| < | Menor que, usado em expressões de filtro. |
| <= | Menor que ou igual a, usado em expressões de filtro. |
| && | AND lógico, usado para combinar várias expressões de filtro. |
| \$1\$1 | OR lógico, usado para combinar várias expressões de filtro. |
**Exemplos**
Os exemplos a seguir têm como base o exemplo de dados XML de [Goessner](https://goessner.net/articles/JsonPath/), que modificamos acrescentando campos adicionais.
```
{ "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
}
}
}
```
****
| Caminho | Descrição |
| --- | --- |
| \$1.store.book[\$1].author | Os autores de todos os livros da loja. |
| \$1..author | Todos os autores. |
| \$1.store.\$1 | Todos os membros da loja. |
| \$1["store"].\$1 | Todos os membros da loja. |
| \$1.store..price | O preço de tudo na loja. |
| \$1..\$1 | Todos os membros recursivos da estrutura JSON. |
| \$1..book[\$1] | Todos os livros. |
| \$1..book[0] | O primeiro livro. |
| \$1..book[-1] | O último livro. |
| \$1..book[0:2] | Os dois primeiros livros. |
| \$1..book[0,1] | Os dois primeiros livros. |
| \$1..book[0:4] | Livros do índice 0 a 3 (o índice final não é inclusivo). |
| \$1..book[0:4:2] | Livros no índice 0, 2. |
| \$1..book[?(@.isbn)] | Todos os livros com um número ISBN. |
| \$1..book[?(@.price<10)] | Todos os livros mais baratos que US\$1 10. |
| '\$1..book[?(@.price < 10)]' | Todos os livros são mais baratos do que US\$1 10. (O caminho deverá estar entre aspas se contiver espaços em branco.) |
| '\$1..book[?(@["price"] < 10)]' | Todos os livros mais baratos que US\$1 10. |
| '\$1..book[?(@.["price"] < 10)]' | Todos os livros mais baratos que US\$1 10. |
| \$1..book[?(@.price>=10&&@.price<=100)] | Todos os livros na faixa de preço entre US\$1 10 a US\$1 100, inclusive. |
| '\$1..book[?(@.price>=10 && @.price<=100)]' | Todos os livros na faixa de preço entre US\$1 10 a US\$1 100, inclusive. (O caminho deverá estar entre aspas se contiver espaços em branco.) |
| \$1..book[?(@.sold==true\$1\$1@.in-stock==false)] | Todos os livros vendidos ou esgotados. |
| '\$1..book[?(@.sold == true \$1\$1 @.in-stock == false)]' | Todos os livros vendidos ou esgotados. (O caminho deverá estar entre aspas se contiver espaços em branco.) |
| '\$1.store.book[?(@.["category"] == "fiction")]' | Todos os livros na categoria ficção. |
| '\$1.store.book[?(@.["category"] \$1= "fiction")]' | Todos os livros nas categorias não ficção. |
Exemplos adicionais de expressões de 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]"
```
**Sintaxe restrita**
****
| Símbolo/Expressão | Descrição |
| --- | --- |
| . ou [] | Operador filho. |
| [] | Operador subscrito de matriz. O índice é baseado em 0. |
**Exemplos**
****
| Caminho | Descrição |
| --- | --- |
| .store.book[0].author | O autor do primeiro livro. |
| .store.book[-1].author | O autor do último livro. |
| .address.city | Nome da cidade. |
| ["store"]["book"][0]["title"] | O título do primeiro livro. |
| ["store"]["book"][-1]["title"] | O título do último livro. |
**nota**
Todo conteúdo de [Goessner](https://goessner.net/articles/JsonPath/) citado nesta documentação está sujeito à [Licença da Creative Commons](https://creativecommons.org/licenses/by/2.5/).
## Prefixos de erro comuns
Cada mensagem de erro tem um prefixo. Veja a seguir uma lista de prefixos de erro comuns.
****
| Prefixo | Descrição |
| --- | --- |
| ERR | Um erro geral. |
| LIMIT | Um erro que ocorre quando o limite de tamanho é excedido. Por exemplo, o limite de tamanho do documento ou limite de profundidade de aninhamento estava excedido. |
| NONEXISTENT | Uma chave ou caminho não existe. |
| OUTOFBOUNDARIES | Índice de matriz fora dos limites. |
| SYNTAXERR | Erro de sintaxe. |
| WRONGTYPE | Tipo de valor errado. |
## Métricas relacionadas ao JSON
As seguintes métricas de informações JSON são fornecidas:
****
| Informações | Descrição |
| --- | --- |
| json\$1total\$1memory\$1bytes | Memória total alocada para objetos JSON. |
| json\$1num\$1documents | Número total de documentos no Valkey ou Redis OSS. |
Para consultar as métricas principais, execute o seguinte comando:
```
info json_core_metrics
```
## Como o ElastiCache para Valkey e Redis OSS interage com JSON
A seção a seguir descreve como o ElastiCache para Valkey e Redis OSS interage com o tipo de dados do JSON.
### Precedência do operador
Ao avaliar expressões condicionais para filtragem, &&s têm precedência primeiro e, em seguida, \$1\$1s são avaliadas, como é comum na maioria das linguagens. As operações dentro de parênteses são executadas primeiro.
### Comportamento do limite máximo de aninhamento de caminho
O limite máximo de aninhamento de caminho no ElastiCache para Redis OSS é 128. Por isso, um valor como `$.a.b.c.d...` só pode atingir 128 níveis.
### Processamento de valores numéricos
O JSON não tem tipos de dados separados para números inteiros e de ponto flutuante. Todos eles são chamados de números.
Representações numéricas:
Quando um número JSON é recebido na entrada, ele é convertido em uma das duas representações binárias internas: um valor inteiro com sinal de 64 bits ou um ponto flutuante de fluxo de precisão dupla de IEEE de 64 bits. A string original e toda a sua formatação não serão retidas. Dessa forma, quando um número é gerado como parte de uma resposta JSON, ele é convertido da representação binária interna para uma string imprimível que usa regras genéricas de formatação. Essas regras podem resultar em uma string diferente da que foi recebida.
Comandos aritméticos `NUMINCRBY` e `NUMMULTBY`:
+ Se ambos os números forem inteiros e o resultado estiver fora da faixa de `int64`, ele se tornará automaticamente um número IEEE de ponto flutuante de precisão dupla de 64 bits.
+ Se pelo menos um dos números for um ponto flutuante, o resultado será um número IEEE ponto flutuante de precisão dupla de 64 bits.
+ Se o resultado exceder a faixa de 64 bits IEEE dupla, o comando `OVERFLOW` retornará um erro.
Para obter uma lista detalhada dos comandos disponíveis, consulte [Comandos compatíveis do Valkey e do Redis OSSComandos JSON](json-list-commands.md).
### Filtragem direta de matriz
O ElastiCache para Valkey ou Redis OSS filtra objetos de matriz diretamente.
Para dados como `[0,1,2,3,4,5,6]` e uma consulta de caminho como `$[?(@<4)]`, ou dados como `{"my_key":[0,1,2,3,4,5,6]}` e uma consulta de caminho como `$.my_key[?(@<4)]`, o ElastiCache retornaria [1,2,3] em ambas as circunstâncias.
### Comportamento de indexação de matriz
O ElastiCache para Valkey ou Redis OSS permite tanto os índices positivo quanto negativo para matrizes. Para uma matriz de comprimento cinco, 0 consultaria o primeiro elemento, 1 o segundo, e assim por diante. Números negativos começam no fim da matriz, então -1 consultaria o quinto elemento, -2 o quarto elemento e assim por diante.
Para garantir um comportamento previsível para os clientes, o ElastiCache não arredonda os índices de matriz para baixo ou para cima, portanto, se você tiver uma matriz com um comprimento de 5, chamar o índice 5 ou superior, ou -6 ou menor, não produzirá um resultado.
### Avaliação estrita da sintaxe
MemoryDB não permite caminhos JSON com sintaxe inválida, mesmo que um subconjunto do caminho contenha um caminho válido. Isso acontece para manter o comportamento correto para nossos clientes.
# Comandos compatíveis do Valkey e do Redis OSS
O ElastiCache é compatível com os seguintes comandos JSON do Valkey e do 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
Anexa um ou mais valores aos valores da matriz no caminho.
Sintaxe
```
JSON.ARRAPPEND [json ...]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (obrigatório): um caminho JSON.
+ json (obrigatório) - O valor JSON a ser anexado à matriz.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de inteiros que representam o novo comprimento da matriz em cada caminho.
+ Se um valor não for uma matriz, seu valor de retorno correspondente será nulo.
+ `NONEXISTENT`Erro se o caminho não existir.
Se o caminho for uma sintaxe restrita:
+ Inteiro, o novo comprimento da matriz.
+ Se vários valores de matriz forem selecionados, o comando retornará o novo comprimento da primeira matriz atualizada.
+ Erro `WRONGTYPE` se o valor no caminho não for uma matriz.
+ Erro `SYNTAXERR` se um dos argumentos de entradas json não for uma string JSON válida.
+ `NONEXISTENT` erro se o caminho não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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\"]]"
```
Sintaxe do caminho restrita:
```
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
Procura a primeira ocorrência de um valor escalar JSON nas matrizes no caminho.
+ Erros fora do intervalo são tratados arredondando o índice para o início e o fim da matriz.
+ Se início > fim, retorna -1 (não encontrado).
Sintaxe
```
JSON.ARRINDEX [start [end]]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (obrigatório): um caminho JSON.
+ json-scalar (obrigatório) - O valor escalar a ser pesquisado. JSON escalar se refere a valores que não são objetos ou matrizes. Ou seja, sstring, número, bbooleano, e nulo são valores escalares.
+ início (opcional) - O índice inicial, inclusive. Assumirá o padrão de 0 se não for fornecido.
+ fim (opcional) - O índice final, exclusivo. Assumirá o padrão de 0 se não for fornecido, o que significa que o último elemento está incluído. 0 ou -1 significa que o último elemento está incluído.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de números inteiros. Cada valor é o índice do elemento correspondente na matriz no caminho. O valor é -1, se não encontrado.
+ Se um valor não for uma matriz, seu valor de retorno correspondente será nulo.
Se o caminho for uma sintaxe restrita:
+ Inteiro, o índice do elemento correspondente ou -1 se não for encontrado.
+ Erro `WRONGTYPE` se o valor no caminho não for uma matriz.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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
```
Sintaxe do caminho restrita:
```
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
Insere um ou mais valores nos valores da matriz no caminho antes do índice.
Sintaxe
```
JSON.ARRINSERT [json ...]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (obrigatório): um caminho JSON.
+ índice (obrigatório) -Um índice de matriz antes do qual os valores são inseridos.
+ json (obrigatório) - O valor JSON a ser anexado à matriz.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de inteiros que representam o novo comprimento da matriz em cada caminho.
+ Se um valor for uma matriz vazia, seu valor de retorno correspondente será nulo.
+ Se um valor não for uma matriz, seu valor de retorno correspondente será nulo.
+ Erro `OUTOFBOUNDARIES` se o argumento índice estiver fora dos limites.
Se o caminho for uma sintaxe restrita:
+ Inteiro, o novo comprimento da matriz.
+ Erro `WRONGTYPE` se o valor no caminho não for uma matriz.
+ Erro `OUTOFBOUNDARIES` se o argumento índice estiver fora dos limites.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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\"]]"
```
Sintaxe do caminho restrita:
```
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
Obtém o comprimento dos valores da matriz no caminho.
Sintaxe
```
JSON.ARRLEN [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de inteiros que representam o comprimento da matriz em cada caminho.
+ Se um valor não for uma matriz, seu valor de retorno correspondente será nulo.
+ Nulo se a chave do documento não existir.
Se o caminho for uma sintaxe restrita:
+ Inteiro, comprimento da matriz.
+ Se vários objetos forem selecionados, o comando retornará o comprimento da primeira matriz.
+ Erro `WRONGTYPE` se o valor no caminho não for uma matriz.
+ `NONEXISTENT JSON` erro se o caminho não existir.
+ Nulo se a chave do documento não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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)
```
Sintaxe do caminho restrita:
```
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
Remove e retorna elemento no índice da matriz. Exibir uma matriz vazia retorna nulo.
Sintaxe
```
JSON.ARRPOP [path [index]]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
+ índice (opcional) -A pposição na matriz a partir da qual começar a exibir.
+ O padrão é -1 se não é fornecido, o que significa o último elemento.
+ O valor negativo significa posição do último elemento.
+ Os índices fora do limite são arredondados para seus respectivos limites de matriz.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de strings em massa que representam os valores exibidos em cada caminho.
+ Se um valor for uma matriz vazia, seu valor de retorno correspondente será nulo.
+ Se um valor não for uma matriz, seu valor de retorno correspondente será nulo.
Se o caminho for uma sintaxe restrita:
+ String em massa que representa o valor JSON exibido.
+ Nulo se a matriz estiver vazia.
+ Erro `WRONGTYPE` se o valor no caminho não for uma matriz.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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\"]]"
```
Sintaxe do caminho restrita:
```
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
Reduz uma matriz no caminho para que ela se torne uma subarray [start, end], ambos inclusivos.
+ Se a matriz estiver vazia, não faça nada, retorne 0.
+ Se início for < 0, trate-a como 0.
+ Se fim for >= tamanho (tamanho da matriz), trate-a como tamanho-1.
+ Se início for >= tamanho ou início for > fim, esvazie a matriz e retorne 0.
Sintaxe
```
JSON.ARRTRIM
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (obrigatório): um caminho JSON.
+ início (obrigatório) - O índice inicial, inclusive.
+ fim (obrigatório) - O índice final, inclusive.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de inteiros que representam o novo comprimento da matriz em cada caminho.
+ Se um valor for uma matriz vazia, seu valor de retorno correspondente será nulo.
+ Se um valor não for uma matriz, seu valor de retorno correspondente será nulo.
+ Erro `OUTOFBOUNDARIES` se um argumento índice estiver fora dos limites.
Se o caminho for uma sintaxe restrita:
+ Inteiro, o novo comprimento da matriz.
+ Nulo se a matriz estiver vazia.
+ Erro `WRONGTYPE` se o valor no caminho não for uma matriz.
+ Erro `OUTOFBOUNDARIES` se um argumento índice estiver fora dos limites.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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\"]]"
```
Sintaxe do caminho restrita:
```
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
Limpa as matrizes ou um objeto no caminho.
Sintaxe
```
JSON.CLEAR [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
**Return**
+ Inteiro, o número de contêineres limpos.
+ Limpar uma matriz ou objeto vazio conta como 1 contêiner limpo.
+ Limpar um valor que não seja do contêiner retorna 0.
**Examples**
```
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
Informações de relatório. Os subcomandos compatíveis são:
+ MEMORY [path] - Informa o uso de memória em bytes de um valor JSON. O caminho assumirá o padrão da raiz se não for fornecido.
+ FIELDS [path] - Informa o número de campos no caminho do documento especificado. O caminho assumirá o padrão da raiz se não for fornecido. Cada valor JSON não contêiner conta como um campo. Objetos e matrizes contam recursivamente como um campo para cada um dos valores JSON que contêm. Cada valor de contêiner, exceto o contêiner raiz, conta como um campo adicional.
+ HELP - Imprime mensagens de ajuda referentes ao comando.
Sintaxe
```
JSON.DEBUG
```
Depende do subcomando:
MEMORY
+ Se o caminho for uma sintaxe aprimorada:
+ Retorna uma matriz de inteiros que representa o tamanho da memória (em bytes) do valor JSON em cada caminho.
+ Retornará uma matriz vazia se a chave do Valkey ou Redis OSS não existir.
+ Se o caminho for uma sintaxe restrita:
+ Retorna um número inteiro, tamanho da memória eo valor de JSON em bytes.
+ Retornará nulo se a chave do Valkey ou Redis OSS não existir.
FIELDS
+ Se o caminho for uma sintaxe aprimorada:
+ Retorna uma matriz de inteiros que representam o número de campos do valor JSON em cada caminho.
+ Retornará uma matriz vazia se a chave do Valkey ou Redis OSS não existir.
+ Se o caminho for uma sintaxe restrita:
+ Retorna um número inteiro, número de campos do valor JSON.
+ Retornará nulo se a chave do Valkey ou Redis OSS não existir.
HELP - Retorna uma série de mensagens de ajuda.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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
```
Sintaxe do caminho restrita:
```
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
Excluios valores JSON no caminho em uma chave de documento. Se o caminho é a raiz, é equivalente a excluir a chave do Valkey ou Redis OSS.
Sintaxe
```
JSON.DEL [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
**Return**
+ Número de elementos excluídos.
+ 0 se a chave do Valkey ou Redis OSS não existir.
+ 0 se o caminho JSON for inválido ou não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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\":[]}"
```
Sintaxe do caminho restrita:
```
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
Um alias de [JSON.DEL](json-del.md).
# JSON.GET
Retorna o JSON serializado em um ou vários caminhos.
Sintaxe
```
JSON.GET
[INDENT indentation-string]
[NEWLINE newline-string]
[SPACE space-string]
[NOESCAPE]
[path ...]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ INDENT/NEWLINE/SPACE (opcional) —Controla o formato da string do JSON retornada, isto é, "formatado para impressão". O valor padrão é uma string vazia. Ele pode ser anulado em qualquer combinação. Eles podem ser especificados em qualquer ordem.
+ NOESCAPE - Opcional, permitido estar presente para compatibilidade com legado e não tem outro efeito.
+ path (opcional): zero ou mais caminhos JSON, assumirá o padrão de raiz se nenhum for fornecido. Os argumentos do caminho devem ser colocados no final.
**Return**
Sintaxe do caminho aprimorada:
Se um caminho for fornecido:
+ Retornará a string serializada de uma matriz de valores.
+ Se nenhum valor for selecionado, o comando retornará uma matriz vazia.
Se vários caminhos forem fornecidos:
+ Retornará um objeto JSON em formato de string, no qual cada caminho é uma chave.
+ Se houver sintaxe mista de caminho aprimorado e restrito, o resultado estará de acordo com a sintaxe aprimorada.
+ Se um caminho não existir, seu valor correspondente será uma matriz vazia.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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]"
```
Sintaxe do caminho restrita:
```
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
Obtém JSONs serializados no caminho a partir de várias chaves de documento. Ele retorna nulo para uma chave ou caminho JSON não existente .
**Sintaxe**
```
JSON.MGET [key ...]
```
+ chave (obrigatório): uma ou mais chaves do Valkey ou Redis OSS do tipo documento.
+ path (obrigatório): um caminho JSON.
**Return**
+ Matriz de strings em massa. O tamanho da matriz é igual ao número de chaves no comando. Cada elemento da matriz será preenchido com (a) o JSON serializado conforme localizado pelo caminho ou ( b)nulo se a chave não existir, o caminho não existir no documento ou o caminho for inválido (erro de sintaxe).
+ Se alguma das chaves especificadas existir e não for uma chave JSON, o comando retornará o erro `WRONGTYPE`.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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\"]"
```
Sintaxe do caminho restrita:
```
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
Compatível com Valkey versão 8.1 e superior.
Defina valores JSON para várias chaves. A operação é atômica. Todos os valores estão definidos ou nenhum está definido.
**Sintaxe**
```
JSON.MSET key path json [ key path json ... ]
```
+ Se o caminho exigir um membro do objeto:
+ Se o elemento pai não existir, o comando retornará o erro NONEXISTENT.
+ Se o elemento pai existir, mas não for um objeto, o comando retornará ERROR.
+ Se o elemento pai existir e for um objeto:
+ Se o membro não existir, um novo membro será anexado ao objeto pai se e somente se o objeto pai for o último filho no caminho. Caso contrário, o comando retornará o erro NONEXISTENT.
+ Se o membro existir, seu valor será substituído pelo valor JSON.
+ Se o caminho exigir um índice de matriz:
+ Se o elemento pai não existir, o comando retornará o erro NONEXISTENT.
+ Se o elemento pai existir, mas não for uma matriz o comando retornará ERROR.
+ Se o elemento pai existir, mas o índice estiver fora dos limites, o comando retornará o erro OUTOFBOUNDARIES.
+ Se o elemento pai existir e o índice for válido, o elemento será substituído pelo novo valor JSON.
+ Se o caminho solicitar um objeto ou matriz, o valor (objeto ou matriz) será substituído pelo novo valor JSON.
**Return**
+ Resposta de sequência de caracteres simples: 'OK' se a operação foi bem-sucedida.
+ Resposta de erro simples: se a operação falhar.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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]}"
```
Sintaxe do caminho restrita:
```
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 os valores numéricos no caminho por um determinado número.
Sintaxe
```
JSON.NUMINCRBY
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (obrigatório): um caminho JSON.
+ número (obrigatório) - Um número.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de strings em massa que representam os valores resultantes em cada caminho.
+ Se um valor não for um número, seu valor de retorno correspondente será nulo.
+ Erro `WRONGTYPE` se o número não puder ser analisado.
+ Erro `OVERFLOW` se o resultado estiver fora do intervalo de duplo IEEE de 64 bits.
+ `NONEXISTENT` se a chave do documento não existir.
Se o caminho for uma sintaxe restrita:
+ Matriz de strings em massa que representam os valores resultantes em cada caminho.
+ Se vários valores forem selecionados, o comando retornará o resultado do último valor atualizado.
+ Erro `WRONGTYPE` se o valor no caminho não for um número.
+ Erro `WRONGTYPE` se o número não puder ser analisado.
+ Erro `OVERFLOW` se o resultado estiver fora do intervalo de duplo IEEE de 64 bits.
+ `NONEXISTENT` se a chave do documento não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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}}"
```
Sintaxe do caminho restrita:
```
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
Multiplica os valores numéricos no caminho por um determinado número.
Sintaxe
```
JSON.NUMMULTBY
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (obrigatório): um caminho JSON.
+ número (obrigatório) - Um número.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de strings em massa que representam o valor resultante em cada caminho.
+ Se um valor não for um número, seu valor de retorno correspondente será nulo.
+ Erro `WRONGTYPE` se o número não puder ser analisado.
+ Erro `OVERFLOW` se o resultado estiver fora do intervalo de um número IEEE de 64 bits do ponto flutuante de precisão dupla.
+ `NONEXISTENT` se a chave do documento não existir.
Se o caminho for uma sintaxe restrita:
+ Matriz de strings em massa que representam os valores resultantes em cada caminho.
+ Se vários valores forem selecionados, o comando retornará o resultado do último valor atualizado.
+ Erro `WRONGTYPE` se o valor no caminho não for um número.
+ Erro `WRONGTYPE` se o número não puder ser analisado.
+ Erro `OVERFLOW` se o resultado estiver fora do intervalo de um número IEEE de 64 bits duplo.
+ `NONEXISTENT` se a chave do documento não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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]"
```
Sintaxe do caminho restrita:
```
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
Obtém o número de chaves nos valores do objeto no caminho.
Sintaxe
```
JSON.OBJLEN [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de inteiros que representam o comprimento do objeto em cada caminho.
+ Se um valor não for um objeto, seu valor de retorno correspondente será nulo.
+ Nulo se a chave do documento não existir.
Se o caminho for uma sintaxe restrita:
+ Inteiro, número de chaves no objeto.
+ Se vários objetos forem selecionados, o comando retornará o comprimento do primeiro objeto.
+ Erro `WRONGTYPE` se o valor no caminho não for um objeto.
+ `NONEXISTENT JSON` erro se o caminho não existir.
+ Nulo se a chave do documento não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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)
```
Sintaxe do caminho restrita:
```
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
Obtém nomes de chave nos valores de objeto no caminho.
Sintaxe
```
JSON.OBJKEYS [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de matriz de strings em massa. Cada elemento é uma matriz de chaves em um objeto correspondente.
+ Se um valor não for um objeto, seu valor de retorno correspondente será vazio.
+ Nulo se a chave do documento não existir.
Se o caminho for uma sintaxe restrita:
+ Matriz de strings em massa. Cada elemento é um nome de chave no objeto.
+ Se vários objetos forem selecionados, o comando retornará as chaves do primeiro objeto.
+ Erro `WRONGTYPE` se o valor no caminho não for um objeto.
+ Nulo se a chave do documento não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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"
```
Sintaxe do caminho restrita:
```
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
Retorna o valor JSON em um determinado caminho no protocolo de Serialização do Valkey ou Redis OSS (RESP). Se o valor for contêiner, a resposta será uma matriz RESP ou matriz aninhada.
+ JSON nulo é mapeado para o RESP Null Bulk String.
+ Valores booleanos JSON são associados às respectivas strings simples RESP.
+ Os números inteiros são mapeados para números inteiros RESP.
+ Os números de ponto flutuante duplo IEEE de 64 bits são mapeados para RESP Bulk Strings.
+ As strings JSON são mapeadas para RESP Bulk Strings.
+ As matrizes JSON são representados como matrizes RESP, onde o primeiro elemento é a string simples [, seguida pelos elementos da matriz.
+ Os objetos JSON são representados como matrizes RESP, onde o primeiro elemento é a string simples \$1, seguida por pares de valores-chave, cada um dos quais é uma string RESP em massa.
Sintaxe
```
JSON.RESP [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de matrizes. Cada elemento da matriz representa a forma RESP do valor em um caminho.
+ Matriz vazia se a chave do documento não existir.
Se o caminho for uma sintaxe restrita:
+ Matriz representa a forma RESP do valor em um caminho.
+ Nulo se a chave do documento não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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"
```
Sintaxe do caminho restrita:
```
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
Define os valores JSON no caminho.
Se o caminho exigir um membro do objeto:
+ Se o elemento pai não existir, o comando retornará um erro INEXISTENT.
+ Se o elemento pai não existir, o comando retornará ERROR.
+ Se o elemento pai existir e for um objeto:
+ Se o membro não existir, um novo membro será anexado ao objeto pai se e somente se o objeto pai for o último filho no caminho. Caso contrário, o comandoretornará um erro INEXISTENT.
+ Se o membro existir, seu valor será substituído pelo valor JSON.
Se o caminho exigir um índice de matriz:
+ Se o elemento pai não existir, o comando retornará um erro INEXISTENT.
+ Se o elemento pai existir, mas não for uma matriz o comando retornará ERROR.
+ Se o elemento pai existir, mas o índice estiver fora dos limites, o comandoretornará um erro OUTOFBOUNDARIES.
+ Se o elemento pai existir e o índice for válido, o elemento será substituído pelo novo valor JSON.
Se o caminho solicitar um objeto ou matriz, o valor (objeto ou matriz) será substituído pelo novo valor JSON.
Sintaxe
```
JSON.SET [NX | XX]
```
[NX \$1 XX] Onde é possível ter 0 ou 1 de identificadores [NX \$1 XX].
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (obrigatório): um caminho JSON. Para uma nova chave, o caminho JSON deve ser a raiz “.”.
+ NX (opcional): se o caminho for a raiz, defina o valor somente se a chave não existir. Isto é, insira um novo documento. Se o caminho não for a raiz, defina o valor somente se a chave Redis não existir. Isto é, insira um valor no documento.
+ XX (opcional): se o caminho for a raiz, defina o valor somente se a chave existir. Isto é, substitua o documento existente. Se o caminho não for a raiz, defina o valor somente se a chave Redis existir. Isto é, atualize o valor existente.
**Return**
+ String simples 'OK' em caso de sucesso.
+ Nulo se a condição NX ou XX não for atendida.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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]}"
```
Sintaxe do caminho restrita:
```
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
Anexa uma string às strings JSON no caminho.
Sintaxe
```
JSON.STRAPPEND [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
+ json\$1string (obrigatório) - A representação JSON de uma string. Observe que uma string JSON deve estar entre aspas. Por exemplo: '"exemplo de string"'.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de inteiros que representam o novo comprimento da matriz em cada caminho.
+ Se um valor não for uma string, seu valor de retorno correspondente será nulo.
+ `SYNTAXERR`Erro se o argumento da entrada json não for uma string JSON válida.
+ `NONEXISTENT`Erro se o caminho não existir.
Se o caminho for uma sintaxe restrita:
+ Inteiro, o novo comprimento da string.
+ Se vários valores de string forem selecionados, o comando retornará o novo comprimento da última string atualizada.
+ Erro `WRONGTYPE` se o valor no caminho não for uma string.
+ Erro `WRONGTYPE` se o argumento da entrada json não for uma string JSON válida.
+ `NONEXISTENT`Erro se o caminho não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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)
```
Sintaxe do caminho restrita:
```
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
Obtém o comprimento dos valores da string JSON no caminho.
Sintaxe
```
JSON.STRLEN [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de inteiros que representam o comprimento do valor da string em cada caminho.
+ Se um valor não for uma string, seu valor correspondente será nulo.
+ Nulo se a chave do documento não existir.
Se o caminho for uma sintaxe restrita:
+ Inteiro, o comprimento da string.
+ Se vários valores de string forem selecionados, o comando retornará o comprimento da primeira string.
+ Erro `WRONGTYPE` se o valor no caminho não for uma string.
+ `NONEXISTENT` erro se o caminho não existir.
+ Nulo se a chave do documento não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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)
```
Sintaxe do caminho restrita:
```
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 valores booleanos entre verdadeiro e falso no caminho.
Sintaxe
```
JSON.TOGGLE [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de inteiros (0 - falso, 1 - verdadeiro) que representam o valor booleano resultante em cada caminho.
+ Se um valor não for um valor booleano, seu valor de retorno correspondente será nulo.
+ `NONEXISTENT` se a chave do documento não existir.
Se o caminho for uma sintaxe restrita:
+ String (“verdadeiro”/"falso”) que representa o valor booleano resultante.
+ `NONEXISTENT` se a chave do documento não existir.
+ Erro `WRONGTYPE` se o valor no caminho não for um valor booliano.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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)
```
Sintaxe do caminho restrita:
```
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
Informa o tipo de valores em um determinado caminho.
Sintaxe
```
JSON.TYPE [path]
```
+ chave (obrigatório): uma chave do Valkey ou Redis OSS do tipo de documento JSON.
+ path (opcional): um caminho JSON. Assumirá o padrão da raiz se não for fornecido.
**Return**
Se o caminho for uma sintaxe aprimorada:
+ Matriz de strings que representam o tipo de valor em cada caminho. O tipo é um destes \$1"null”, “boolean”, “string”, “number”, “integer”, “object” e “array"\$1.
+ Se um caminho não existir, seu valor de retorno correspondente será nulo.
+ Matriz vazia se a chave do documento não existir.
Se o caminho for uma sintaxe restrita:
+ String, tipo do valor
+ Nulo se a chave do documento não existir.
+ Nulo se o caminho JSON for inválido ou não existir.
**Exemplos**
Sintaxe do caminho aprimorada:
```
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
```
Sintaxe do caminho restrita:
```
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
```
# Marcando seus recursos ElastiCache
Para ajudar você a gerenciar seus clusters e outros ElastiCache recursos, você pode atribuir seus próprios metadados a cada recurso na forma de tags. As tags permitem que você categorize seus AWS recursos de maneiras diferentes, por exemplo, por finalidade, proprietário ou ambiente. Isso é útil quando você tem muitos recursos do mesmo tipo. É possível identificar rapidamente um recurso específico baseado nas tags que você atribuiu a ele. Este tópico descreve tags e mostra a você como criá-las.
**Atenção**
Como uma prática recomendada, sugerimos que você não inclua dados confidenciais nas suas tags.
## Conceitos Básicos de Tags
Uma tag é um rótulo que você atribui a um AWS recurso. Cada tag consiste de uma chave e um valor opcional, que podem ser definidos. As tags permitem que você categorize seus AWS recursos de maneiras diferentes, por exemplo, por finalidade ou proprietário. Por exemplo, você pode definir um conjunto de tags para os ElastiCache clusters da sua conta que ajuda a rastrear o proprietário e o grupo de usuários de cada instância.
Recomendamos que você desenvolva um conjunto de chave de tags que atenda suas necessidades para cada tipo de recurso. Usar um conjunto consistente de chaves de tags facilita para você gerenciar seus recursos. É possível pesquisar e filtrar os recursos de acordo com as tags que adicionar. Para obter mais informações sobre como implementar uma estratégia eficaz de marcação de recursos, consulte o [whitepaper da AWS, Práticas recomendadas de marcação](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf).
As tags não têm nenhum significado semântico ElastiCache e são interpretadas estritamente como uma sequência de caracteres. Além disso, as tags não são automaticamente atribuídas aos seus recursos. É possível editar chaves de tags e valores e é possível remover as tags de um recurso a qualquer momento. É possível definir o valor de uma tag como `null`. Ao adicionar uma tag que tenha a mesma chave de uma tag existente nesse recurso, o novo valor substituirá o antigo. Caso exclua um recurso, todas as respectivas tags também serão excluídas. Além disso, se você adicionar ou excluir tags em um grupo de replicação, todos os nós nesse grupo de replicação também terão suas tags adicionadas ou removidas.
Você pode trabalhar com tags usando a Console de gerenciamento da AWSAWS CLI, a e a ElastiCache API.
Se você estiver usando o IAM, você pode controlar quais usuários AWS da sua conta têm permissão para criar, editar ou excluir tags. Para obter mais informações, consulte [Permissões em nível de recurso](IAM.ResourceLevelPermissions.md).
## Recursos que podem ser marcados
Você pode marcar a maioria dos ElastiCache recursos que já existem na sua conta. A tabela a seguir lista os recursos compatíveis com o uso de tags. Se você estiver usando o Console de gerenciamento da AWS, você pode aplicar tags aos recursos usando o [Editor de tags](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html). Algumas telas de recursos permitem que você especifique tags para um recurso ao criá-lo; por exemplo, uma tag com uma chave de nome e um valor que você especificar. Na maioria dos casos, o console aplicará as tags imediatamente depois de o recurso ser criado (em vez de durante a criação de recursos). O console pode organizar os recursos de acordo com a tag **Name**, mas essa tag não tem nenhum significado semântico para o ElastiCache serviço.
Além disso, algumas ações de criação de recursos permitem que você especifique tags para um recurso quando ele é criado. Se as tags não puderem ser aplicadas durante a criação dos recursos, nós reverteremos o processo de criação de recursos. Isso garante que os recursos sejam criados com tags ou, então, não criados, e que nenhum recurso seja deixado sem tags. Ao marcar com tags os recursos no momento da criação, você elimina a necessidade de executar scripts personalizados de uso de tags após a criação do recurso.
Se você estiver usando a ElastiCache API da Amazon, a AWS CLI ou um AWS SDK, poderá usar o `Tags` parâmetro na ação relevante da ElastiCache API para aplicar tags. Eles são:
+ `CreateServerlessCache`
+ `CreateCacheCluster`
+ `CreateReplicationGroup`
+ `CopyServerlessCacheSnapshot`
+ `CopySnapshot`
+ `CreateCacheParameterGroup`
+ `CreateCacheSecurityGroup`
+ `CreateCacheSubnetGroup`
+ `CreateServerlessCacheSnapshot`
+ `CreateSnapshot`
+ `CreateUserGroup`
+ `CreateUser`
+ `PurchaseReservedCacheNodesOffering`
A tabela a seguir descreve os ElastiCache recursos que podem ser marcados e os recursos que podem ser marcados na criação usando a ElastiCache API, a AWS CLI ou um AWS SDK.
**Suporte de marcação para recursos ElastiCache**
| Recurso | Compatível com tags | Oferece suporte à marcação na criação |
| --- | --- | --- |
| serverlesscache | Sim | Sim |
| parametergroup | Sim | Sim |
| SecurityGroup | Sim | Sim |
| SubnetGroup | Sim | Sim |
| Replicationgroup | Sim | Sim |
| cluster | Sim | Sim |
| reserved-instance | Sim | Sim |
| serverlesscachesnapshot | Sim | Sim |
| snapshot | Sim | Sim |
| usuário | Sim | Sim |
| usergroup | Sim | Sim |
**nota**
Não é possível marcar Datastores globais.
Você pode aplicar permissões em nível de recurso baseadas em tags em suas políticas do IAM às ações da ElastiCache API que oferecem suporte à marcação na criação para implementar um controle granular sobre os usuários e grupos que podem marcar recursos na criação. Seus recursos estão devidamente protegidos a partir da criação. As tags são aplicadas imediatamente aos recursos. Portanto, todas as permissões em nível de recurso baseadas em tags que controlam o uso de recursos entram imediatamente em vigor. Seus recursos podem ser rastreados e relatados com mais precisão. É possível obrigar o uso de marcação com tags nos novos recursos e controlar quais chaves e valores de tag são definidos nos seus recursos.
Para obter mais informações, consulte [Exemplo de marcação de recursos](#Tagging-your-resources-example).
Para obter mais informações sobre como marcar os seus recursos para o faturamento, consulte [Monitoramento de custos com tags de alocação de custos](Tagging.md).
## Marcação de caches e snapshots
As seguintes regras se aplicam à marcação como parte das operações de solicitação:
+ **CreateReplicationGroup**:
+ Se os parâmetros `--primary-cluster-id` e `--tags` forem incluídos na solicitação, as tags de solicitação serão adicionadas ao grupo de replicação e propagadas para todos os clusters no grupo de replicação. Se o cluster primário tiver tags existentes, elas serão substituídas pelas tags de solicitação para ter tags consistentes em todos os nós.
Se não houver tags de solicitação, as tags de cluster primário serão adicionadas ao grupo de replicação e propagadas para todos os clusters.
+ Se o `--snapshot-name` ou o `--serverless-cache-snapshot-name` for fornecido:
Se as tags forem incluídas na solicitação, o grupo de replicações será marcado somente com essas tags. Se nenhuma tag for incluída na solicitação, as tags de snapshot serão adicionadas ao grupo de replicações.
+ Se o `--global-replication-group-id` for fornecido:
Se as tags forem incluídas na solicitação, as tags de solicitação serão adicionadas ao grupo de replicação e propagadas para todos os clusters.
+ **CreateCacheCluster** :
+ Se o `--replication-group-id` for fornecido:
Se as tags forem incluídas na solicitação, o cluster será marcado somente com essas tags. Se nenhuma tag for incluída na solicitação, o cluster herdará as tags de grupo de replicação em vez das tags do cluster primário.
+ Se o `--snapshot-name` for fornecido:
Se as tags forem incluídas na solicitação, o cluster será marcado somente com essas tags. Se nenhuma tag for incluída na solicitação, as tags de snapshot serão adicionadas ao cluster.
+ **CreateServerlessCache** :
+ Se as tags forem incluídas na solicitação, somente as tags de solicitação serão adicionadas ao cache sem servidor.
+ **CreateSnapshot** :
+ Se o `--replication-group-id` for fornecido:
Se as tags forem incluídas na solicitação, somente as tags de solicitação serão adicionadas ao snapshot. Se nenhuma tag for incluída na solicitação, as tags de grupo de replicação\$1serão adicionadas ao cluster de cache.
+ Se o `--cache-cluster-id` for fornecido:
Se as tags forem incluídas na solicitação, somente as tags de solicitação serão adicionadas ao snapshot. Se nenhuma tag for incluída na solicitação, as tags de cluster de cache serão adicionadas ao snapshot.
+ Para snapshots automáticos:
As tags serão propagadas a partir das tags do grupo de replicação.
+ **CreateServerlessCacheSnapshot** :
+ Se as tags forem incluídas na solicitação, somente as tags de solicitação serão adicionadas ao snapshot de cache sem servidor.
+ **CopySnapshot** :
+ Se as tags forem incluídas na solicitação, somente as tags de solicitação serão adicionadas ao snapshot. Se nenhuma tag for incluída na solicitação, as tags de snapshot da origem serão adicionadas ao snapshot copiado.
+ **CopyServerlessCacheSnapshot** :
+ Se as tags forem incluídas na solicitação, somente as tags de solicitação serão adicionadas ao snapshot de cache sem servidor.
+ **AddTagsToResource**e **RemoveTagsFromResource**:
+ As tags serão added/removed do grupo de replicação e a ação será propagada para todos os clusters no grupo de replicação.
**nota**
**AddTagsToResource**e **RemoveTagsFromResource**não pode ser usado para parâmetros e grupos de segurança padrão.
+ **IncreaseReplicaCount** e **ModifyReplicationGroupShardConfiguration**:
+ Todos os novos clusters adicionados ao grupo de replicação terão as mesmas tags aplicadas como o grupo de replicação.
## Restrições de tags
As restrições básicas a seguir se aplicam a tags:
+ Número máximo de tags por recurso –- 50
+ Em todos os recursos, cada chave de tag deve ser exclusiva e possuir apenas um valor.
+ Comprimento máximo da chave – 128 caracteres Unicode em UTF-8.
+ Comprimento máximo do valor – 256 caracteres Unicode em UTF-8.
+ Embora ElastiCache permita qualquer caractere em suas tags, outros serviços podem ser restritivos. Os caracteres permitidos nos serviços são: letras, números e espaços representáveis em UTF-8 e os seguintes caracteres: \$1 - = . \$1 : / @
+ As chaves e os valores de marcas diferenciam maiúsculas de minúsculas.
+ O `aws:` prefixo está reservado para AWS uso. Não é possível editar nem excluir a chave ou o valor de uma tag quando ela tem uma chave de tag com esse prefixo. As tags com o prefixo `aws:` não contam para as tags por limite de recurso.
Você não pode encerrar, parar ou excluir um recurso baseado unicamente em suas tags; será preciso especificar o identificador de recursos. Por exemplo, para excluir snapshots marcados com uma chave de tag chamada `DeleteMe`, use a ação `DeleteSnapshot` com os identificadores de recursos dos snapshots, como `snap-1234567890abcdef0`.
Para obter mais informações sobre ElastiCache recursos que você pode marcar, consulte[Recursos que podem ser marcados](#Tagging-your-resources).
## Exemplo de marcação de recursos
+ Criar um cache com tecnologia sem servidor usando tags. Este exemplo usa o Memcached como mecanismo.
```
aws elasticache create-serverless-cache \
--serverless-cache-name CacheName \
--engine memcached
--tags Key="Cost Center", Value="1110001" Key="project",Value="XYZ"
```
+ Adicionar tags a um cache sem servidor
```
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"
```
+ Adição de tags a um grupo de replicação.
```
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"
```
+ Criação de um cluster de cache usando tags.
```
aws elasticache create-cache-cluster \
--cluster-id testing-tags \
--cluster-description cluster-test \
--cache-subnet-group-name test \
--cache-node-type cache.t2.micro \
--engine valkey \
--tags Key="project",Value="XYZ" Key="Elasticache",Value="Service"
```
+ Criação de um cluster de cache usando tags. Este exemplo usa o Redis como mecanismo.
```
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"
```
+ Criação de um snapshot sem servidor com tags. Este exemplo usa o Memcached como mecanismo.
```
aws elasticache create-serverless-cache-snapshot \
--serverless-cache-name testing-tags \
--serverless-cache-snapshot-name bkp-testing-tags-scs \
--tags Key="work",Value="foo"
```
+ Criação de um snapshot com tags.
No momento, os snapshots estão disponíveis apenas para Redis. Para esse caso, se você adicionar tags sob solicitação, mesmo que o grupo de replicação contenha tags, o snapshot receberá somente as tags da solicitação.
```
aws elasticache create-snapshot \
--replication-group-id testing-tags \
--snapshot-name bkp-testing-tags-rg \
--tags Key="work",Value="foo"
```
## Exemplos de políticas de controle de acesso baseadas em tags
1. Permissão de ação `AddTagsToResource` para um cluster somente se o cluster tiver a 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. Permissão de ação `RemoveTagsFromResource` de um grupo de replicação se ele contém as tags Project (Projeto) e Service (Serviço) e as chaves são diferentes de Project (Projeto) e Service (Serviço).
------
#### [ 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. Permissão de `AddTagsToResource` para qualquer recurso somente se as tags forem diferentes de Project (Projeto) e Service (Serviço).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "elasticache:AddTagsToResource",
"Resource": [
"arn:aws:elasticache:*:*:*:*"
],
"Condition": {
"ForAnyValue:StringNotEqualsIgnoreCase": {
"aws:TagKeys": [
"Service",
"Project"
]
}
}
}
]
}
```
------
1. Negação da ação `CreateReplicationGroup` se a solicitação tiver `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. Negação da ação `CopySnapshot` se o snapshot de origem tiver a tag Project=XYZ e a tag de solicitação for 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. Negar ação `CreateCacheCluster` se a tag de solicitação `Project` estiver faltando ou não for igual a `Dev`, `QA` ou `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"
]
}
}
}
]
}
```
------
Para obter informações relacionadas sobre chaves de condição, consulte [Uso de chaves de condição](IAM.ConditionKeys.md).
# Monitoramento de custos com tags de alocação de custos
Ao adicionar etiquetas de alocação de custos aos seus recursos na Amazon ElastiCache, você pode rastrear os custos agrupando as despesas em suas faturas por valores de etiquetas de recursos.
Uma tag de alocação de ElastiCache custos é um par de valores-chave que você define e associa a um recurso. ElastiCache A chave e o valor diferenciam maiúsculas de minúsculas. Você pode usar uma chave de tag para definir uma categoria, e o valor da tag pode ser um item nessa categoria. Por exemplo, você pode definir uma chave de tag de `CostCenter` e um valor de tag de `10010`, indicando que o recurso está atribuído ao centro de custo 10010. Você também pode usar tags para designar recursos como sendo usados para teste ou produção, usando uma chave como `Environment` e valores como `test` ou `production`. Recomendamos que você use um conjunto consistente de chaves de tag para facilitar o rastreamento dos custos associados aos seus recursos.
Use etiquetas de alocação de custos para organizar sua AWS fatura de forma a refletir sua própria estrutura de custos. Para fazer isso, inscreva-se para receber a fatura AWS da sua conta com os valores-chave da tag incluídos. Então, para ver o custo de recursos combinados, organize suas informações de faturamento de acordo com recursos com os mesmos valores de chave de tags. Por exemplo, é possível marcar vários recursos com um nome de aplicação específico, e depois organizar suas informações de faturamento para ver o custo total daquela aplicação em vários serviços.
Você também pode combinar tags para rastrear custos com um maior nível de detalhes. Por exemplo, para rastrear seus custos de serviços por região, você pode usar as chaves de tag `Service` e `Region`. Em um recurso, você pode ter os valores `ElastiCache` e `Asia Pacific (Singapore)` e, em outro recurso, os valores `ElastiCache` e `Europe (Frankfurt)`. Em seguida, você pode ver seus ElastiCache custos totais divididos por região. Para saber mais, consulte [ Usar tags de alocação de custos ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) no *Guia do usuário do AWS Billing*.
Você pode adicionar tags de alocação de ElastiCache custos a clusters baseados em ElastiCache nós. Ao adicionar, listar, modificar, copiar ou remover uma tag, a operação é aplicada somente ao cluster especificado.
**Características das etiquetas de alocação de ElastiCache custos**
+ As tags de alocação de custos são aplicadas aos ElastiCache recursos especificados nas operações da CLI e da API como um ARN. O tipo de recurso será um "cluster".
ARN de exemplo: `arn:aws:elasticache::::`
Amostra de ARN: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
+ A chave de tags é o nome obrigatório da tag. O valor da string da chave pode ser de 1 a 128 caracteres Unicode e não pode ser prefixado com `aws:`. A string pode conter apenas o conjunto de letras Unicode, dígitos, espaços em branco, sublinhados (\$1), pontos finais (.), dois-pontos (:), barras invertidas (\$1), sinais de igualdade (=), sinais de adição (\$1), hífens (-) ou sinais de arroba (@).
+ O valor da tag é o valor opcional da tag. O valor da string do valor pode ser de 1 a 256 caracteres Unicode e não pode ser prefixado com `aws:`. A string pode conter apenas o conjunto de letras Unicode, dígitos, espaços em branco, sublinhados (\$1), pontos finais (.), dois-pontos (:), barras invertidas (\$1), sinais de igualdade (=), sinais de adição (\$1), hífens (-) ou sinais de arroba (@).
+ Um ElastiCache recurso pode ter no máximo 50 tags.
+ Os valores não têm que ser exclusivos em um conjunto de tags. Por exemplo, você pode ter um conjunto de tags no qual as chaves `Service` e `Application` têm ambas o valor `ElastiCache`.
AWS não aplica nenhum significado semântico às suas tags. As tags são interpretadas estritamente como cadeias de caracteres.AWS não define automaticamente nenhuma tag em nenhum ElastiCache recurso.
# Gerenciamento das suas tags de alocação de custos usando a AWS CLI
Você pode usar a AWS CLI para adicionar, modificar ou remover tags de alocação de custos.
Tags de alocação de custos são aplicadas em clusters do ElastiCache. O cluster que receberá tag é especificado usando um ARN (Nome de recurso da Amazon).
Amostra de ARN: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [Listagem de tags usando a AWS CLI](#Tagging.Managing.CLI.List)
+ [Adição de tags usando a AWS CLI](#Tagging.Managing.CLI.Add)
+ [Modificação de tags usando a AWS CLI](#Tagging.Managing.CLI.Modify)
+ [Remoção der tags usando a AWS CLI](#Tagging.Managing.CLI.Remove)
## Listagem de tags usando a AWS CLI
Você pode usar a AWS CLI para listar tags em um recurso do ElastiCache existente usando a operação [list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html).
O código a seguir usa a AWS CLI para listar as tags no cluster Memcached `my-cluster` na região us-west-2.
Para Linux, macOS ou Unix:
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
Para Windows:
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster
```
O código a seguir usa a AWS CLI para listar as tags no nó `my-cluster-001` do Valkey ou Redis OSS no cluster `my-cluster` na região us-west-2.
Para Linux, macOS ou Unix:
```
aws elasticache list-tags-for-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
Para Windows:
```
aws elasticache list-tags-for-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001
```
A saída dessa operação será semelhante a uma lista de todas as tags no recurso.
```
{
"TagList": [
{
"Value": "10110",
"Key": "CostCenter"
},
{
"Value": "EC2",
"Key": "Service"
}
]
}
```
Se não houver tags no recurso, a saída será uma TagList vazia.
```
{
"TagList": []
}
```
Para obter mais informações, consulte a AWS CLI sobre o ElastiCache [list-tags-for-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/list-tags-for-resource.html).
## Adição de tags usando a AWS CLI
Você pode usar a AWS CLI para adicionar tags a um recurso do ElastiCache existente usando a operação da CLI [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html). Se a chave de tag não existir no recurso, a chave e o valor serão adicionados ao recurso. Se a chave já existir no recurso, o valor associado a essa chave será atualizado para o novo valor.
O código a seguir usa a AWS CLI para adicionar as chaves `Service` e `Region` com os valores `elasticache` e `us-west-2`, respectivamente, ao nó `my-cluster-001` no cluster `my-cluster` na região us-west-2.
**Memcached**
Para Linux, macOS ou 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
```
Para 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 do**
Para Linux, macOS ou 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
```
Para 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
```
A saída dessa operação será semelhante a uma lista de todas as tags no recurso após a operação, conforme mostrado a seguir.
```
{
"TagList": [
{
"Value": "elasticache",
"Key": "Service"
},
{
"Value": "us-west-2",
"Key": "Region"
}
]
}
```
Para obter mais informações, consulte a AWS CLI sobre o ElastiCache [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html).
Você também pode usar a AWS CLI para adicionar tags a um cluster ao criar um novo cluster usando a operação [create-cache-cluster](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html). Não é possível adicionar tags ao criar um cluster usando o console de gerenciamento do ElastiCache. Depois que o cluster é criado, você pode usar o console para adicionar tags ao cluster.
## Modificação de tags usando a AWS CLI
Você pode usar a AWS CLI para modificar as tags em um cluster do ElastiCache.
Para modificar tags:
+ Use [add-tags-to-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/add-tags-to-resource.html) para adicionar uma nova tag e um valor ou para alterar o valor associado a uma tag existente.
+ Use [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html) para remover tags especificadas do recurso.
A saída de qualquer operação será uma lista de tags e seus valores no cluster especificado.
## Remoção der tags usando a AWS CLI
Você pode usar a AWS CLI para remover tags de um cluster do ElastiCache for Memcached existente usando a operação [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html).
Para o Memcached, o código a seguir usa a AWS CLI para remover as etiquetas com as chaves `Service` e `Region` do nó `my-cluster-001` no cluster `my-cluster` na região us-west-2.
Para Linux, macOS ou Unix:
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster \
--tag-keys PM Service
```
Para Windows:
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster ^
--tag-keys PM Service
```
Para o Redis OSS, o código a seguir usa a AWS CLI para remover as etiquetas com as chaves `Service` e `Region` do nó `my-cluster-001` no cluster `my-cluster` na região us-west-2.
Para Linux, macOS ou Unix:
```
aws elasticache remove-tags-from-resource \
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 \
--tag-keys PM Service
```
Para Windows:
```
aws elasticache remove-tags-from-resource ^
--resource-name arn:aws:elasticache:us-west-2:0123456789:cluster:my-cluster-001 ^
--tag-keys PM Service
```
A saída dessa operação será semelhante a uma lista de todas as tags no recurso após a operação, conforme mostrado a seguir.
```
{
"TagList": []
}
```
Para obter mais informações, consulte a AWS CLI sobre o ElastiCache [remove-tags-from-resource](https://docs.aws.amazon.com/cli/latest/reference/elasticache/remove-tags-from-resource.html).
# Gerenciamento das suas tags de alocação de custos usando a API do ElastiCache
Você pode usar a API do ElastiCache para adicionar, modificar ou remover tags de alocação de custos.
Tags de alocação de custos são aplicadas em clusters do ElastiCache for Memcached. O cluster que receberá tag é especificado usando um ARN (Nome de recurso da Amazon).
Amostra de ARN: `arn:aws:elasticache:us-west-2:1234567890:cluster:my-cluster`
**Topics**
+ [Listagem de tags usando a API do ElastiCache](#Tagging.Managing.API.List)
+ [Adição de tags usando a API do ElastiCache](#Tagging.Managing.API.Add)
+ [Modificação de tags usando a API do ElastiCache](#Tagging.Managing.API.Modify)
+ [Remoção de tags usando a API do ElastiCache](#Tagging.Managing.API.Remove)
## Listagem de tags usando a API do ElastiCache
Você pode usar a API do ElastiCache para listar tags em um recurso existente usando a operação [ListTagsForResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ListTagsForResource.html).
Para o Memcached, o código a seguir usa a API do ElastiCache para listar as tags no recurso `my-cluster` na região 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=
```
Para o Redis OSS, o código a seguir usa a API do ElastiCache para listar as tags no recurso `my-cluster-001` na região 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=
```
## Adição de tags usando a API do ElastiCache
Você pode usar a API do ElastiCache para adicionar tags a um cluster do ElastiCache existente usando a operação [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html). Se a chave de tag não existir no recurso, a chave e o valor serão adicionados ao recurso. Se a chave já existir no recurso, o valor associado a essa chave será atualizado para o novo valor.
O código a seguir usa a API do ElastiCache para adicionar as chaves `Service` e `Region` com os valores `elasticache` e `us-west-2` respectivamente. Para o Memcached, isso é aplicado ao recurso `my-cluster`. Para o Redis OSS, isso é aplicado ao recurso `my-cluster-001` na região 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 do**
```
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=
```
Para obter mais informações, consulte [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) na *Referência da API do Amazon ElastiCache*.
## Modificação de tags usando a API do ElastiCache
Você pode usar a API do ElastiCache para modificar as tags em um cluster do ElastiCache.
Para modificar o valor de uma tag:
+ Use a operação [AddTagsToResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_AddTagsToResource.html) para adicionar uma nova tag e um valor ou para alterar o valor de uma tag existente.
+ Use [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) para remover tags do recurso.
A saída de qualquer operação será uma lista de tags e seus valores no recurso especificado.
Use [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html) para remover tags do recurso.
## Remoção de tags usando a API do ElastiCache
Você pode usar a API do ElastiCache para remover tags de um cluster do ElastiCache for Memcached existente usando a operação [RemoveTagsFromResource](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_RemoveTagsFromResource.html).
O código a seguir usa a API do ElastiCache para remover as tags com as chaves `Service` e `Region` do nó `my-cluster-001` no cluster `my-cluster` na região 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=
```
# Usar a Lente do Well-Architected para o Amazon ElastiCache
Esta seção descreve o recurso Lente do Well-Architected para o Amazon ElastiCache, um conjunto de princípios de design e orientações para projetar workloads bem arquitetadas do ElastiCache.
+ A Lente para o ElastiCache é um aditivo ao [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html).
+ Cada pilar tem um conjunto de perguntas para ajudar a iniciar a discussão sobre uma arquitetura do ElastiCache.
+ Cada pergunta tem várias práticas principais, além de suas pontuações para fins de relatório.
+ *Obrigatório*: necessário antes de entrar em produção (a ausência representa alto risco).
+ *Ideal*: o melhor estado possível em que um cliente pode estar.
+ *Bom*: o que recomendamos para os clientes (a ausência representa risco médio).
+ Terminologia do Well-Architected
+ [Componente](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html): código, configuração e recursos da AWS que, juntos, atendem a um requisito. Os componentes interagem com outros componentes e geralmente são equivalentes a um serviço em arquiteturas de microsserviços.
+ [Workload](https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html): um conjunto de componentes que, juntos, agregam valor comercial. Exemplos de workloads são sites de marketing, sites de comércio eletrônico, back-ends de aplicações móveis, plataformas de análises etc.
**nota**
Este guia não foi atualizado para incluir informações sobre o cache com tecnologia sem servidor do ElastiCache e o novo mecanismo Valkey.
**Topics**
+ [Pilar Excelência operacional da Lente do Well-Architected para o Amazon ElastiCache](OperationalExcellencePillar.md)
+ [Pilar Segurança da Lente do Well-Architected para o Amazon ElastiCache](SecurityPillar.md)
+ [Pilar Confiabilidade da Lente do Well-Architected para o Amazon ElastiCache](ReliabilityPillar.md)
+ [Pilar de ElastiCache eficiência de desempenho da lente Amazon Well-Architected](PerformanceEfficiencyPillar.md)
+ [Pilar Otimização de custos da Lente do Well-Architected para o Amazon ElastiCache](CostOptimizationPillar.md)
# Pilar Excelência operacional da Lente do Well-Architected para o Amazon ElastiCache
O foco do pilar Excelência operacional está na execução e no monitoramento de sistemas para agregar valor empresarial e melhorar continuamente processos e procedimentos. Os principais tópicos incluem automatizar mudanças, responder a eventos e definir padrões para gerenciar operações diárias.
**Topics**
+ [EO 1: Como você entende e responde aos alertas e eventos acionados pelo seu cluster do ElastiCache?](#OperationalExcellencePillarOE1)
+ [EO 2: Quando e como você dimensiona seus clusters existentes do ElastiCache?](#OperationalExcellencePillarOE2)
+ [EO 3: Como você gerencia os recursos do seu cluster do ElastiCache e mantém o cluster atualizado?](#OperationalExcellencePillarOE3)
+ [EO 4: Como você gerencia as conexões de clientes aos seus clusters do ElastiCache?](#OperationalExcellencePillarOE4)
+ [EO 5: Como você implanta componentes do ElastiCache para uma workload?](#OperationalExcellencePillarOE5)
+ [EO 6: Como você planeja e mitiga falhas?](#OperationalExcellencePillarOE6)
+ [EO 7: como solucionar problemas em eventos do mecanismo Valkey ou Redis OSS?](#OperationalExcellencePillarOE7)
## EO 1: Como você entende e responde aos alertas e eventos acionados pelo seu cluster do ElastiCache?
**Introdução: **ao operar clusters do ElastiCache, você tem a opção de receber notificações e alertas quando eventos específicos ocorrerem. Por padrão, o ElastiCache registra em log [eventos](ECEvents.md) relacionados aos seus recursos, como um failover, substituição de nó, operação de ajuste de escala, manutenção programada e muito mais. Cada evento inclui a data e hora, o nome e tipo da origem e uma descrição.
**Benefício: **ser capaz de entender e gerenciar os motivos subjacentes aos eventos que acionam os alertas gerados pelo seu cluster permite que você opere com mais eficiência e responda aos eventos de forma adequada.
+ **[Obrigatório]** Analise os eventos gerados pelo ElastiCache no console do ElastiCache (depois de selecionar sua região) ou usando o comando [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html) da [Amazon Command Line Interface](https://aws.amazon.com/cli) (AWS CLI) e a [API do ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html). Configure o ElastiCache para enviar notificações sobre eventos de cluster importantes usando o Amazon Simple Notification Service (Amazon SNS). Usar o Amazon SNS com seus clusters permite que você realize ações programáticas em eventos do ElastiCache.
+ Há duas grandes categorias de eventos: eventos atuais e programados. A lista de eventos atuais inclui: criação e exclusão de recursos, operações de ajuste de escala, failover, reinicialização de nó, criação de snapshot, modificação de parâmetros do cluster, renovação do certificado de CA, eventos de falha (falha no provisionamento do cluster [VPC ou ENI], falhas de ajuste de escala [ENI] e falhas de snapshot). A lista de eventos programados inclui: nó programado para substituição durante a janela de manutenção e substituição de nó reagendada.
+ Embora talvez você não precise reagir imediatamente a alguns desses eventos, é fundamental examinar primeiro todos os eventos de falha:
+ ElastiCache:AddCacheNodeFailed
+ ElastiCache:CacheClusterProvisioningFailed
+ ElastiCache:CacheClusterScalingFailed
+ ElastiCache:CacheNodesRebooted
+ ElastiCache:SnapshotFailed (somente Valkey ou Redis OSS)
+ **[Recursos]:**
+ [Gerenciando ElastiCache notificações do Amazon SNS](ECEvents.SNS.md)
+ [Notificações de eventos e o Amazon SNS](ElastiCacheSNS.md)
+ **[Ideal]** Para automatizar as respostas a eventos, utilize os recursos dos produtos e serviços da AWS, como o SNS e as funções do Lambda. Siga as práticas recomendadas ao fazer alterações pequenas, frequentes e reversíveis, como código para evoluir suas operações ao longo do tempo. Você deve usar as métricas do Amazon CloudWatch para monitorar seus clusters.
**[Recursos]:** [monitorar endpoints de réplica de leitura do ElastiCache (modo cluster desabilitado) usando o AWS Lambda, Amazon Route 53 e Amazon 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/) para um caso de uso do Lambda e SNS.
## EO 2: Quando e como você dimensiona seus clusters existentes do ElastiCache?
**Introdução: **o dimensionamento correto do cluster do ElastiCache é um ato de equilíbrio que precisa ser avaliado sempre que houver alterações nos tipos de workload subjacentes. Seu objetivo é operar com o ambiente do tamanho certo para sua workload.
**Benefício: **a utilização excessiva de seus recursos pode resultar em latência elevada e diminuição geral da performance. Por outro lado, a subutilização pode resultar em provisionamento excessivo de recursos com uma otimização de custos não ideal. Ao dimensionar corretamente seus ambientes, você pode encontrar um equilíbrio entre eficiência de performance e otimização de custos. Para remediar o excesso ou a subutilização de recursos, o ElastiCache pode ter a escala ajustada em duas dimensões. Você pode ajustar a escala verticalmente ao aumentar ou diminuir a capacidade dos nós. Também pode ajustar a escala horizontalmente ao adicionar e remover nós.
+ **[Obrigatório]** O excesso de utilização da CPU e da rede nos nós primários deve ser resolvido descarregando e redirecionando as operações de leitura para os nós de réplica. Use nós de réplica para operações de leitura a fim de reduzir a utilização do nó primário. Isso pode ser configurado em sua biblioteca de cliente do Valkey ou Redis OSS conectando-se ao endpoint leitor do ElastiCache para modo cluster desabilitado ou usando o comando READONLY para modo cluster habilitado.
**[Recursos]:**
+ [Encontrar endpoints de conexão no ElastiCache](Endpoints.md)
+ [Dimensionar um cluster corretamente](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)
+ **[Obrigatório]** Monitore a utilização de recursos críticos do cluster, como CPU, memória e rede. A utilização desses recursos específicos do cluster precisa ser monitorada para informar sua decisão de ajustar a escala e do tipo de operação de ajuste. Com o modo de cluster do ElastiCache desabilitado, o nó primário e os nós de réplica podem escalar verticalmente. Os nós de réplica também podem escalar horizontalmente, de 0 a 5 nós. Com o modo de cluster habilitado, o mesmo se aplica a cada fragmento do cluster. Além disso, você pode aumentar ou reduzir o número de fragmentos.
**[Recursos]:**
+ [Monitorar as práticas recomendadas com o ElastiCache usando o Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ [Escalar clusters do ElastiCache para Valkey e Redis OSS](Scaling.md)
+ [Escalar clusters do ElastiCache para Memcached](Scaling.md)
+ **[Ideal]** O monitoramento da performance ao longo do tempo pode ajudar você a detectar mudanças na workload que passariam despercebidas se monitoradas em momentos específicos. Para detectar tendências de longo prazo, use as métricas do CloudWatch a fim de verificar intervalos de tempo mais longos. O aprendizado da observação de longos períodos de métricas do CloudWatch deve informar sua previsão sobre a utilização de recursos do cluster. Os pontos de dados e métricas do CloudWatch ficam disponíveis por até 455 dias.
**[Recursos]:**
+ [Monitorar o ElastiCache com métricas do CloudWatch](CacheMetrics.md)
+ [Monitorar o Memcached com métricas do CloudWatch](CacheMetrics.md)
+ [Monitorar as práticas recomendadas com o ElastiCache usando o Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Ideal]** Se seus recursos do ElastiCache forem criados com o CloudFormation, uma prática recomendada é realizar alterações usando modelos do CloudFormation para preservar a consistência operacional e evitar alterações de configuração não gerenciadas e desvios de pilha.
**[Recursos]:**
+ [Referência de tipos de recurso do ElastiCache para o CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ **[Ideal]** Automatize suas operações de ajuste de escala usando dados operacionais de cluster e defina limites no CloudWatch para configurar alarmes. Use o CloudWatch Events e o Simple Notification Service (SNS) para acionar funções do Lambda e executar uma API do ElastiCache a fim de ajustar a escala dos clusters automaticamente. Um exemplo seria adicionar um fragmento ao cluster quando a métrica `EngineCPUUtilization` atingir 80% por um longo período. Outra opção seria usar `DatabaseMemoryUsedPercentages` para um limite baseado em memória.
**[Recursos]:**
+ [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [O que são os eventos do Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Como usar o AWS Lambda com o Amazon Simple Notification Service](https://docs.aws.amazon.com/lambda/latest/dg/with-sns.html)
+ [Referência da API do ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
## EO 3: Como você gerencia os recursos do seu cluster do ElastiCache e mantém o cluster atualizado?
**Introdução: **ao operar em grande escala, é essencial que você seja capaz de localizar e identificar todos os seus recursos do ElastiCache. Ao lançar novos atributos da aplicação, você precisa criar simetria entre as versões do cluster em todos os tipos de ambiente do ElastiCache: desenvolvimento, teste e produção. Os atributos de recursos permitem que você separe ambientes para objetivos operacionais diferentes, como ao implantar novos atributos e ativar novos mecanismos de segurança.
**Benefício: **separar os ambientes de desenvolvimento, teste e produção é uma prática operacional recomendada. Também é uma prática recomendada que seus clusters e nós em todos os ambientes tenham os patches de software mais recentes aplicados usando processos bem compreendidos e documentados. Aproveitar os atributos nativos do ElastiCache permite que sua equipe de engenharia se concentre em cumprir os objetivos de negócios e não na manutenção do ElastiCache.
+ **[Ideal]** Execute na versão mais recente do mecanismo disponível e aplique as atualizações de autoatendimento assim que estiverem disponíveis. O ElastiCache atualiza automaticamente sua infraestrutura subjacente durante a janela de manutenção especificada do cluster. No entanto, os nós em execução em seus clusters são atualizados por meio de atualizações de autoatendimento. Essas atualizações podem ser de dois tipos: patches de segurança ou pequenas atualizações de software. Compreenda a diferença entre os tipos de patches e quando eles são aplicados.
**[Recursos]:**
+ [Atualizações de autoatendimento no Amazon ElastiCache](Self-Service-Updates.md)
+ [Página de ajuda sobre manutenção gerenciada e atualizações de serviços do Amazon ElastiCache](https://aws.amazon.com/elasticache/elasticache-maintenance/)
+ **[Ideal]** Organize seus recursos do ElastiCache usando etiquetas. Use etiquetas em grupos de replicação e não em nós individuais. Você pode configurar etiquetas para serem exibidas ao consultar recursos e usar etiquetas para realizar pesquisas e aplicar filtros. Você deve usar grupos de recursos para criar e manter facilmente coleções de recursos que compartilham conjuntos comuns de etiquetas.
**[Recursos]:**
+ [Práticas recomendadas de marcação](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf)
+ [Referência de tipos de recurso do ElastiCache para o CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [Grupos de parâmetros](ParameterGroups.Engine.md#ParameterGroups.Redis)
## EO 4: Como você gerencia as conexões de clientes aos seus clusters do ElastiCache?
**Introdução: **ao operar em grande escala, você precisa entender como seus clientes se conectam ao cluster do ElastiCache para gerenciar os aspectos operacionais da aplicação (como tempos de resposta).
**Benefício: **escolher o mecanismo de conexão mais adequado vai garantir que sua aplicação não se desconecte devido a erros de conectividade, como tempos limite.
+ **[Obrigatório]** Separe as operações de leitura e gravação e conecte-se aos nós de réplica para executar as operações de leitura. No entanto, esteja ciente de que, ao separar as gravações das leituras, você perderá a capacidade de ler uma chave logo depois de gravá-la devido à natureza assíncrona da replicação do Valkey e do Redis OSS. O comando WAIT pode ser usado para aumentar a segurança dos dados no mundo real e forçar as réplicas a reconhecer as gravações antes de responder aos clientes, com um custo geral de performance. O uso de nós de réplica para operações de leitura pode ser configurado em sua biblioteca de cliente do ElastiCache usando o endpoint de leitor do ElastiCache para o modo de cluster desabilitado. Para habilitar o modo de cluster, use o comando READONLY. Para muitas das bibliotecas de cliente do ElastiCache, o READONLY é implementado por padrão ou por meio de uma configuração.
**[Recursos]:**
+ [Encontrar endpoints de conexão no ElastiCache](Endpoints.md)
+ [READONLY](https://valkey.io/commands/readonly)
+ **[Obrigatório] **Use o agrupamento de conexões. Estabelecer uma conexão TCP tem um custo de tempo de CPU nos lados do cliente e do servidor, e o agrupamento permite que você reutilize a conexão TCP.
Para reduzir a sobrecarga da conexão, use o agrupamento de conexões. Com um grupo de conexões, sua aplicação pode reutilizar e liberar conexões “à vontade”, sem o custo de estabelecer a conexão. Você pode implementar o agrupamento de conexões por meio de sua biblioteca de cliente do ElastiCache (se compatível), com um framework disponível para o ambiente da sua aplicação, ou criá-lo do zero.
+ **[Ideal]** Certifique-se de que o tempo limite do soquete do cliente esteja definido para pelo menos um segundo (em vez do padrão típico de “nenhum” em vários clientes).
+ Definir um valor de tempo limite muito baixo pode fazer com que o tempo limite seja atingido quando a carga do servidor estiver alta. Defini-lo muito alto pode fazer com que a aplicação demore muito para detectar problemas de conexão.
+ Controle o volume de novas conexões implementando o agrupamento de conexões em sua aplicação de cliente. Isso reduz a latência e a utilização da CPU necessárias para abrir e fechar conexões e realizar um handshake de TLS, caso o TLS esteja habilitado no cluster.
**[Recursos]:** [configurar o ElastiCache para aumentar a disponibilidade](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ **[Bom]** Usar pipelines (quando seus casos de uso permitirem) pode aumentar significativamente a performance.
+ Com pipelines, você reduz o tempo de ida e volta (RTT) entre os clientes da aplicação e o cluster, e novas solicitações podem ser processadas mesmo que o cliente ainda não tenha lido as respostas anteriores.
+ Com pipelines, você pode enviar vários comandos para o servidor sem esperar por respostas ou confirmações. A desvantagem dos pipelines é que, quando você finalmente obtém todas as respostas em lote, pode ter ocorrido um erro que só será detectado no final.
+ Implemente métodos para repetir as solicitações quando for retornado um erro que omite a solicitação incorreta.
**[Recursos]:** [Pipelines](https://valkey.io/topics/pipelining/)
## EO 5: Como você implanta componentes do ElastiCache para uma workload?
**Introdução: **os ambientes do ElastiCache podem ser implantados manualmente por meio do Console da AWS ou programaticamente por meio de APIs, CLI, kits de ferramentas etc. As práticas recomendadas de Excelência operacional sugerem que as implantações sejam automatizadas por meio de código sempre que possível. Além disso, os clusters do ElastiCache podem ser isolados por workload ou combinados para fins de otimização de custos.
**Benefício: **escolher o mecanismo de implantação mais adequado para seus ambientes do ElastiCache pode melhorar a excelência operacional ao longo do tempo. É recomendável realizar operações como código sempre que possível para minimizar a quantidade de erros humanos e aumentar a repetibilidade, a flexibilidade e o tempo de resposta aos eventos.
Ao entender os requisitos de isolamento da workload, você pode optar por ter ambientes dedicados do ElastiCache por workload ou combinar várias workloads em clusters únicos, ou combinações dessas estratégias. Compreender as vantagens e desvantagens pode ajudar a encontrar um equilíbrio entre Excelência operacional e Otimização de custos.
+ **[Obrigatório]** Entenda as opções de implantação disponíveis para o ElastiCache e automatize esses procedimentos sempre que possível. Os possíveis caminhos de automação incluem CloudFormation, AWS CLI/SDK e APIs.
**[Recursos]: **
+ [Referência de tipos de recurso do Amazon ElastiCache](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ElastiCache.html)
+ [elasticache](https://docs.aws.amazon.com/cli/latest/reference/elasticache/index.html)
+ [Referência da API do Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html)
+ **[Obrigatório]** Para todas as workloads, determine o nível de isolamento do cluster necessário.
+ **[Ideal]** Isolamento alto: mapeamento 1:1 entre workload e cluster. Permite o melhor controle sobre o acesso, o dimensionamento, a escalabilidade e o gerenciamento dos recursos do ElastiCache por workload.
+ **[Melhor]** Isolamento médio: M:1 isolado por finalidade, mas talvez compartilhado entre várias workloads (por exemplo, um cluster dedicado a armazenar workloads em cache e outro dedicado a mensagens).
+ **[Bom]** Isolamento baixo: M:1 multiuso, totalmente compartilhado. Recomendado para workloads em que o acesso compartilhado é aceitável.
## EO 6: Como você planeja e mitiga falhas?
**Introdução: **a Excelência operacional inclui a antecipação de falhas por meio da realização de exercícios regulares “pré-mortem” a fim de identificar possíveis fontes de falha para que elas possam ser removidas ou mitigadas. O ElastiCache oferece uma API de failover que permite simular eventos de falha de nós, para fins de teste.
**Benefício: **ao testar cenários de falha com antecedência, você pode aprender como eles afetam sua workload. Isso permite testar com segurança os procedimentos de resposta e sua eficácia, além de familiarizar sua equipe com sua execução.
**[Obrigatório]** Realize regularmente testes de failover em contas de dev/teste. [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)
## EO 7: como solucionar problemas em eventos do mecanismo Valkey ou Redis OSS?
**Introdução: **a Excelência operacional exige a capacidade de investigar as informações do serviço e do mecanismo para analisar a integridade e o status dos clusters. O ElastiCache pode emitir logs do mecanismo Valkey ou Redis OSS para o Amazon CloudWatch e o Amazon Kinesis Data Firehose.
**Benefício: **habilitar os logs do mecanismo Valkey ou Redis OSS nos clusters do ElastiCache fornece informações sobre eventos que afetam a integridade e desempenho dos clusters. Os logs do mecanismo Valkey ou Redis OSS fornecem dados diretamente do mecanismo que não estão disponíveis por meio do mecanismo de eventos do ElastiCache. Por meio da observação cuidadosa dos eventos do ElastiCache (consulte a pergunta EO 1 anterior) e dos logs do mecanismo, é possível determinar a ordem dos eventos ao solucionar problemas, tanto da perspectiva do serviço ElastiCache quanto da perspectiva do mecanismo.
+ **[Obrigatório]** Certifique-se de que a funcionalidade de registro em log do mecanismo Redis OSS esteja habilitada. Ela está disponível no ElastiCache para Redis OSS versão 6.2 e posteriores. Isso pode ser feito durante a criação do cluster ou modificando o cluster depois da criação.
+ Determine se o Amazon CloudWatch Logs ou o Amazon Kinesis Data Firehose são o destino apropriado para os logs do mecanismo Redis OSS.
+ Selecione um log de destino apropriado no CloudWatch ou no Kinesis Data Firehose para manter os logs. Se você tiver vários clusters, considere usar um log de destino diferente para cada cluster, pois isso ajudará a isolar os dados ao solucionar problemas.
**[Recursos]:**
+ Entrega de logs: [Entrega de logs](Log_Delivery.md)
+ Destinos de registro em log: [Amazon CloudWatch Logs](Logging-destinations.md#Destination_Specs_CloudWatch_Logs)
+ Introdução ao Amazon CloudWatch Logs: [O que é o Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ Introdução ao Amazon Kinesis Data Firehose: [O que é o Amazon Kinesis Data Firehose?](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
+ **[Ideal]** Se estiver usando o Amazon CloudWatch Logs, considere usar o Amazon CloudWatch Logs Insights para consultar o log do mecanismo Valkey ou Redis OSS a fim de obter informações importantes.
Como exemplo, crie uma consulta ao grupo de logs do CloudWatch que contém os logs do mecanismo Valkey ou Redis OSS que retornarão eventos com um LogLevel de “WARNING”, como:
```
fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"
```
**[Recursos]:** [Analisar dados de logs com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
# Pilar Segurança da Lente do Well-Architected para o Amazon ElastiCache
O foco do pilar Segurança está na proteção de informações e sistemas. Os principais tópicos incluem confidencialidade e integridade dos dados, identificação e gerenciamento de quem pode fazer o quê com o gerenciamento baseado em privilégios, proteção de sistemas e estabelecimento de controles para detectar eventos de segurança.
**Topics**
+ [SEG 1: Quais etapas você está tomando para controlar o acesso autorizado aos dados do ElastiCache?](#SecurityPillarSEC1)
+ [SEG 2: Suas aplicações exigem autorização adicional para o ElastiCache além dos controles baseados em rede?](#SecurityPillarSEC2)
+ [SEG 3: Existe o risco de que os comandos possam ser executados acidentalmente, causando perda ou falha de dados?](#SecurityPillarSEC3)
+ [SEG 4: Como garantir a criptografia de dados em repouso com o ElastiCache?](#SecurityPillarSEC4)
+ [SEG 5: Como criptografar dados em trânsito com o ElastiCache?](#SecurityPillarSEC5)
+ [SEG 6: Como restringir o acesso aos recursos do ambiente de gerenciamento?](#SecurityPillarSEC6)
+ [SEG 7: Como detectar e responder a eventos de segurança?](#SecurityPillarSEC7)
## SEG 1: Quais etapas você está tomando para controlar o acesso autorizado aos dados do ElastiCache?
**Introdução: **todos os clusters do ElastiCache são projetados para serem acessados de instâncias do Amazon Elastic Compute Cloud em uma VPC, de funções sem servidor (AWS Lambda) ou de contêineres (Amazon Elastic Container Service). O cenário mais comum é acessar um cluster do ElastiCache de uma instância do Amazon Elastic Compute Cloud na mesma Amazon VPC (Amazon Virtual Private Cloud). Antes de poder se conectar a um cluster usando uma instância do Amazon EC2, você deve autorizar a instância do Amazon EC2 a acessar o cluster. Para acessar um cluster do ElastiCache em execução em uma VPC, é necessário conceder entrada de rede ao cluster.
**Benefício: **a entrada de rede no cluster é controlada por meio de grupos de segurança da VPC. Um grupo de segurança atua como firewall virtual para as instâncias do Amazon EC2 a fim de controlar o tráfego de entrada e saída. As regras de entrada controlam o tráfego de entrada para a instância e as regras de saída controlam o tráfego de saída da instância. No caso do ElastiCache, ao iniciar um cluster é necessário associar um grupo de segurança. Isso garante que as regras de tráfego de entrada e saída estejam em vigor para todos os nós que compõem o cluster. Além disso, o ElastiCache está configurado para ser implantado exclusivamente em sub-redes privadas, de forma que elas só possam ser acessadas por meio de redes privadas da VPC.
+ **[Obrigatório] **O grupo de segurança associado ao seu cluster controla a entrada na rede e o acesso ao cluster. Por padrão, um grupo de segurança não terá nenhuma regra de entrada definida e, portanto, nenhum caminho de entrada para o ElastiCache. Para habilitar isso, configure uma regra de entrada no grupo de segurança especificando o endereço/intervalo de IP de origem, o tráfego do tipo TCP e a porta do cluster do ElastiCache (porta padrão 6379 para o ElastiCache para Valkey e Redis OSS, por exemplo). Embora seja possível permitir um conjunto muito amplo de origens de entrada, como todos os recursos em uma VPC (0.0.0.0/0), é recomendável ser o mais granular possível ao definir as regras de entrada, como autorizar somente o acesso de entrada a clientes Valkey ou Redis OSS em execução em instâncias do Amazon EC2 associadas a um grupo de segurança específico.
**[Recursos]: **
+ [Sub-redes e grupos de sub-redes](SubnetGroups.md)
+ [Acessar um cluster ou grupo de replicação](accessing-elasticache.md)
+ [Controlar o tráfego para recursos usando grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#DefaultSecurityGroupdefault%20security%20group)
+ [Grupos de segurança do Amazon Elastic Compute Cloud para instâncias do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#creating-your-own-security-groups)
+ **[Obrigatório] **As políticas do AWS Identity and Access Management podem ser atribuídas a funções do AWS Lambda que permitam acessar os dados do ElastiCache. Para habilitar esse atributo, crie uma função de execução do IAM com a permissão `AWSLambdaVPCAccessExecutionRole` e atribua o perfil à função AWS Lambda.
**[Recursos]: **Configurar uma função do Lambda para acessar o Amazon ElastiCache em uma Amazon VPC: [Tutorial: Configurar uma função do Lambda para acessar o Amazon ElastiCache em uma Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/services-elasticache-tutorial.html)
## SEG 2: Suas aplicações exigem autorização adicional para o ElastiCache além dos controles baseados em rede?
**Introdução: **em cenários em que é necessário restringir ou controlar o acesso aos clusters individualmente para cada cliente, é recomendável fazer a autenticação por meio do comando AUTH. Os tokens de autenticação do ElastiCache, com gerenciamento opcional de usuários e grupos de usuários, possibilitam que o ElastiCache exija uma senha antes de permitir que os clientes executem comandos e chaves de acesso, aumentando assim a segurança do plano de dados.
**Benefício: **para ajudar a manter os dados em segurança, o ElastiCache fornece mecanismos de proteção contra o acesso não autorizado aos dados. Isso inclui impor que o AUTH do controle de acesso baseado em perfil (RBAC) ou um token de AUTH (senha) sejam usados pelos clientes para que se conectem ao ElastiCache antes de executar comandos autorizados.
+ **[Ideal] **No ElastiCache versão 6.x e superior para Redis OSS, e ElastiCache versão 7.2 e superior para Valkey, defina os controles de autenticação e autorização definindo grupos de usuários, usuários e strings de acesso. Atribua usuários a grupos de usuários, depois atribua grupos de usuários a clusters. Para utilizar o RBAC, ele deve ser selecionado na criação do cluster e a criptografia em trânsito deve estar habilitada. Use um cliente Valkey ou Redis OSS compatível com TLS para poder aproveitar o RBAC.
**[Recursos]: **
+ [Aplicação do RBAC a um grupo de replicação para o ElastiCache](Clusters.RBAC.md#rbac-using)
+ [Especificação de permissões usando uma string de acesso](Clusters.RBAC.md#Access-string)
+ [ACL](https://valkey.io/topics/acl/)
+ [Versões aceitas do ElastiCache](VersionManagement.md#supported-engine-versions)
+ **[Ideal] **Em versões do ElastiCache anteriores à 6.x para Redis OSS, além de definir token/senha fortes e manter uma política de senha rígida para AUTH, a prática recomendada é alternar a senha/token. O ElastiCache pode gerenciar até dois (2) tokens de autenticação por vez. Você também pode modificar o cluster para exigir explicitamente o uso de tokens de autenticação.
**[Recursos]: **[Modificação do token AUTH em um cluster existente do ElastiCache](auth.md#auth-modifyng-token)
## SEG 3: Existe o risco de que os comandos possam ser executados acidentalmente, causando perda ou falha de dados?
**Introdução: **há vários comandos do Valkey ou Redis OSS que podem ter impactos adversos nas operações se executados por engano ou por agentes mal-intencionados. Esses comandos podem ter consequências não intencionais do ponto de vista da performance e da segurança dos dados. Por exemplo, um desenvolvedor pode chamar rotineiramente o comando FLUSHALL em um ambiente de desenvolvimento e, devido a um erro, pode tentar inadvertidamente chamar esse comando em um sistema de produção, resultando em perda acidental de dados.
**Benefício: **a partir do ElastiCache versão 5.0.3 para Redis OSS, é possível renomear certos comandos que podem atrapalhar sua workload. Renomear os comandos pode ajudar a evitar que sejam executados acidentalmente no cluster.
+ **[Obrigatório] **
**[Recursos]: **
+ [ElastiCache versão 5.0.3 para Redis OSS (obsoleto, use a versão 5.0.6)](engine-versions.md#redis-version-5-0.3)
+ [ElastiCache versão 5.0.3 para alterações de parâmetros do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.5-0-3)
+ [Segurança do Redis OSS](https://redis.io/docs/management/security/)
## SEG 4: Como garantir a criptografia de dados em repouso com o ElastiCache?
**Introdução: **embora o ElastiCache seja um datastore em memória, é possível criptografar qualquer dado que possa ser persistido (no armazenamento) como parte das operações padrão do cluster. Isso inclui backups programados e manuais gravados no Amazon S3, bem como dados salvos no armazenamento em disco como resultado de operações de sincronização e troca. Os tipos de instância nas famílias M6g e R6g também oferecem criptografia sempre ativa em memória.
**Benefício: **o ElastiCache fornece criptografia em repouso opcional para aumentar a segurança dos dados.
+ **[Obrigatório] **A criptografia em repouso só pode ser habilitada em um cluster do ElastiCache (grupo de replicação) durante sua criação. Um cluster existente não pode ser modificado para começar a criptografar dados em repouso. Por padrão, o ElastiCache fornecerá e gerenciará as chaves usadas na criptografia em repouso.
**[Recursos]: **
+ [Restrições da criptografia em repouso](at-rest-encryption.md#at-rest-encryption-constraints)
+ [Ativar criptografia em repouso](at-rest-encryption.md#at-rest-encryption-enable)
+ **[Ideal] **Utilize os tipos de instância do Amazon EC2 que criptografam dados enquanto eles estão na memória (como M6g ou R6g). Sempre que possível, considere gerenciar suas próprias chaves para criptografia em repouso. Para ambientes de segurança de dados mais rigorosos, o AWS Key Management Service (KMS) pode ser usado para autogerenciar as chaves mestras de cliente (CMK). Por meio da integração do ElastiCache com o AWS Key Management Service, você pode criar, possuir e gerenciar as chaves usadas para criptografia de dados em repouso em seu cluster do ElastiCache.
**[Recursos]: **
+ [Uso de chaves gerenciadas pelo cliente do AWS Key Management Service](at-rest-encryption.md#using-customer-managed-keys-for-elasticache-security)
+ [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
+ [Conceitos do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys)
## SEG 5: Como criptografar dados em trânsito com o ElastiCache?
**Introdução: **é um requisito comum evitar que os dados sejam comprometidos em trânsito. Isso representa dados dentro de componentes de um sistema distribuído, bem como entre clientes de aplicações e nós de cluster. O ElastiCache oferece suporte a esse requisito ao permitir a criptografia de dados em trânsito entre clientes e cluster e entre os próprios nós do cluster. Os tipos de instância nas famílias M6g e R6g também oferecem criptografia sempre ativa em memória.
**Benefício: **a criptografia em trânsito do Amazon ElastiCache é um atributo opcional que permite aumentar a segurança de seus dados nos pontos mais vulneráveis: quando estão em trânsito de um local para outro.
+ **[Obrigatório] **A criptografia em trânsito só pode ser habilitada em um cluster (grupo de replicação) durante sua criação. Observe que, devido ao processamento adicional necessário para criptografar/descriptografar dados, a implementação da criptografia em trânsito vai afetar a performance. Para entender o impacto, é recomendável comparar a workload antes e depois de ativar a criptografia em trânsito.
**[Recursos]: **
+ [Visão geral da criptografia em trânsito](in-transit-encryption.md#in-transit-encryption-overview)
## SEG 6: Como restringir o acesso aos recursos do ambiente de gerenciamento?
**Introdução: **as políticas do IAM e o ARN habilitam controles de acesso refinados no ElastiCache para Valkey e Redis OSS, permitindo um controle mais rígido para gerenciar a criação, modificação e exclusão de clusters do ElastiCache para Redis.
**Benefício: **o gerenciamento dos recursos do Amazon ElastiCache, como grupos de replicação, nós etc., pode ser restrito a contas da AWS que têm permissões específicas com base nas políticas do IAM, aumentando a segurança e a confiabilidade dos recursos.
+ **[Obrigatório] **Gerencie o acesso aos recursos do Amazon ElastiCache atribuindo políticas do AWS Identity and Access Management específicas aos usuários da AWS, viabilizando um controle mais preciso sobre quais contas podem realizar quais ações nos clusters.
**[Recursos]: **
+ [Visão geral do gerenciamento de permissões de acesso aos recursos do ElastiCache](IAM.Overview.md)
+ [Uso de políticas baseadas em identidade (políticas do IAM) para o Amazon ElastiCache](IAM.IdentityBasedPolicies.md)
## SEG 7: Como detectar e responder a eventos de segurança?
**Introdução: **quando implantado com o RBAC habilitado, o ElastiCache exporta métricas do CloudWatch para notificar os usuários sobre eventos de segurança. Essas métricas ajudam a identificar tentativas fracassadas de autenticação, acesso a chaves ou execução de comandos para os quais os usuários do RBAC não têm autorização.
Além disso, os recursos de produtos e serviços da AWS ajudam a proteger a workload geral automatizando as implantações e registrando em log todas as ações e modificações para revisão/auditoria posterior.
**Benefício: **ao monitorar eventos, sua organização consegue responder de acordo com seus requisitos, políticas e procedimentos. Automatizar o monitoramento e as respostas a esses eventos de segurança fortalece sua postura geral de segurança.
+ **[Obrigatório] **Familiarize-se com as métricas publicadas do CloudWatch relacionadas às falhas de autenticação e autorização do RBAC.
+ AuthenticationFailures = tentativas fracassadas de autenticação no Valkey ou Redis OSS
+ KeyAuthorizationFailures = tentativas fracassadas de usuários para acessar chaves sem permissão
+ CommandAuthorizationFailures = tentativas fracassadas de usuários para executar comandos sem permissão
**[Recursos]: **
+ [Métricas para o Valkey ou Redis OSS](CacheMetrics.Redis.md)
+ **[Ideal] **É recomendável configurar alertas e notificações sobre essas métricas e responder conforme necessário.
**[Recursos]: **
+ [Usar alarmes do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ **[Ideal] **Use o comando ACL LOG do Valkey ou Redis OSS para obter mais detalhes
**[Recursos]: **
+ [ACL LOG](https://valkey.io/commands/acl-log/)
+ **[Ideal] **Familiarize-se com os recursos de produtos e serviços da AWS relacionados ao monitoramento, registro e análise de implantações e eventos do ElastiCache.
**[Recursos]: **
+ [Logs das chamadas de API do Amazon ElastiCache com o AWS CloudTrail](logging-using-cloudtrail.md)
+ [elasticache-redis-cluster-automatic-backup-check](https://docs.aws.amazon.com/config/latest/developerguide/elasticache-redis-cluster-automatic-backup-check.html)
+ [Monitorar o uso com métricas do CloudWatch](CacheMetrics.md)
# Pilar Confiabilidade da Lente do Well-Architected para o Amazon ElastiCache
O pilar de confiabilidade se concentra nas workloads que executam as funções pretendidas e em como se recuperar rapidamente de falhas para atender às demandas. Os principais tópicos incluem projeto de sistema distribuído, planejamento de recuperação e adaptação às mudanças de requisitos.
**Topics**
+ [CONF 1: Como você está oferecendo suporte a implantações de arquitetura de alta disponibilidade (HA)?](#ReliabilityPillarREL1)
+ [CONF 2: Como você está cumprindo seus objetivos de ponto de recuperação (RPOs) com o ElastiCache?](#ReliabilityPillarREL2)
+ [CONF 3: Como você oferece suporte aos requisitos de recuperação de desastres (DR)?](#ReliabilityPillarREL3)
+ [CONF 4: Como se planejar efetivamente para os failovers?](#ReliabilityPillarREL4)
+ [CONF 5: Seus componentes do ElastiCache foram projetados para escalar?](#ReliabilityPillarREL5)
## CONF 1: Como você está oferecendo suporte a implantações de arquitetura de alta disponibilidade (HA)?
**Introdução: **compreender a arquitetura de alta disponibilidade do Amazon ElastiCache permitirá que você opere em um estado resiliente durante eventos de disponibilidade.
**Benefício: **arquitetar seus clusters do ElastiCache para que sejam resilientes a falhas garante maior disponibilidade para suas implantações do ElastiCache.
+ **[Obrigatório] **Determine o nível de confiabilidade necessário para seu cluster do ElastiCache. Workloads diferentes têm padrões de resiliência diferentes, desde workloads totalmente efêmeras até workloads essenciais à missão. Defina as necessidades de cada tipo de ambiente que você opera, como desenvolvimento, teste e produção.
Mecanismo de armazenamento em cache: ElastiCache para Memcached versus ElastiCache para Valkey e Redis OSS
1. O ElastiCache para Memcached não fornece nenhum mecanismo de replicação e é usado principalmente para workloads efêmeras.
1. O ElastiCache para Redis OSS oferece os atributos de HA discutidos abaixo.
+ **[Ideal] **Para workloads que exigem HA, use o ElastiCache no modo de cluster com no mínimo duas réplicas por fragmento, mesmo para workloads com requisitos de throughput baixa que exijam apenas um fragmento.
1. Com o modo de cluster habilitado, o multi-AZ é habilitado automaticamente.
O multi-AZ minimiza o tempo de inatividade realizando failovers automáticos do nó primário para as réplicas, em caso de manutenção planejada ou não planejada, além de mitigar falhas em AZ.
1. Para workloads fragmentadas, uma quantidade mínima de três fragmentos fornece uma recuperação mais rápida durante eventos de failover, pois o protocolo de cluster do Valkey ou Redis OSS exige que a maioria dos nós primários esteja disponível para ter quórum.
1. Configure duas ou mais réplicas em toda a disponibilidade.
Ter duas réplicas proporciona maior escalabilidade de leitura e também disponibilidade de leitura em cenários em que uma réplica passa por manutenção.
1. Use tipos de nó baseados em Graviton2 (nós padrão na maioria das regiões).
O ElastiCache apresenta desempenho otimizado nesses nós. Como resultado, você obtém melhor performance de replicação e sincronização, resultando em maior disponibilidade geral.
1. Monitore e ajuste o tamanho certo para lidar com picos de tráfego previstos: sob carga pesada, o mecanismo pode deixar de responder, o que afeta a disponibilidade. `BytesUsedForCache`e `DatabaseMemoryUsagePercentage` são bons indicadores do uso da memória, enquanto `ReplicationLag` é um indicador da integridade de replicação com base na taxa de gravação. Você pode usar essas métricas para acionar o ajuste de escala do cluster.
1. Garanta a resiliência do lado do cliente testando com a [API de failover antes de um evento de failover na produção](https://docs.amazonaws.cn/en_us/AmazonElastiCache/latest/APIReference/API_TestFailover.html).
**[Recursos]: **
+ [Configurar o ElastiCache para Redis OSS para aumentar a disponibilidade](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [Alta disponibilidade com o uso de grupos de replicação](Replication.md)
## CONF 2: Como você está cumprindo seus objetivos de ponto de recuperação (RPOs) com o ElastiCache?
**Introdução: **entenda o RPO da workload para embasar as decisões sobre estratégias de backup e recuperação do ElastiCache.
**Benefício: **ter uma estratégia de RPO em vigor pode melhorar a continuidade dos negócios nos cenários de recuperação de desastres. Projetar políticas de backup e restauração pode ajudar você a atingir seus objetivos de ponto de recuperação (RPO) para seus dados do ElastiCache. O ElastiCache oferece recursos de snapshot que são armazenados no Amazon S3, com uma política de retenção configurável. Esses instantâneos são gerados durante uma janela de backup definida e gerenciados automaticamente pelo serviço. Se sua workload exigir granularidade de backup adicional, você tem a opção de criar até 20 backups manuais por dia. Os backups criados manualmente não têm uma política de retenção de serviços e podem ser mantidos indefinidamente.
+ **[Obrigatório] **Entenda e documente o RPO de suas implantações do ElastiCache.
+ Lembre-se de que o Memcached não oferece nenhum processo de backup.
+ Analise a capacidade dos atributos de backup e restauração do ElastiCache.
+ **[Ideal] **Implemente um processo bem comunicado para fazer backup do cluster.
+ Inicie backups manuais conforme necessário.
+ Analise as políticas de retenção para backups automáticos.
+ Observe que os backups manuais serão mantidos indefinidamente.
+ Agende seus backups automáticos durante períodos de baixo uso.
+ Execute operações de backup em réplicas de leitura para garantir a minimização do impacto na performance do cluster.
+ **[Bom] **Aproveite o atributo de backup agendado do ElastiCache para fazer backup regular de seus dados durante uma janela definida.
+ Teste periodicamente as restaurações de seus backups.
+ **[Recursos]: **
+ [Redis OSS](https://aws.amazon.com/elasticache/faqs/#Redis)
+ [Backup e restauração do ElastiCache](backups.md)
+ [Criação de backups manuais](backups-manual.md)
+ [Programação de backups automáticos](backups-automatic.md)
+ [Backup e restauração de clusters do ElastiCache](https://aws.amazon.com/blogs/aws/backup-and-restore-elasticache-redis-nodes/)
## CONF 3: Como você oferece suporte aos requisitos de recuperação de desastres (DR)?
**Introdução: **a recuperação de desastres é um aspecto importante do planejamento de qualquer workload. O ElastiCache oferece várias opções para implementar a recuperação de desastres com base nos requisitos de resiliência da workload. Com o Amazon ElastiCache Global Datastore, você pode gravar em seu cluster em uma região e disponibilizar os dados para leitura em outros dois clusters de réplica entre regiões, viabilizando leituras de baixa latência e recuperação de desastres em várias regiões.
**Benefício: **compreender e se planejar para uma variedade de cenários de desastre pode garantir a continuidade dos negócios. As estratégias de DR devem equilibrar custo, impacto na performance e potencial de perda de dados.
+ **[Obrigatório] **Desenvolva e documente estratégias de DR para todos os seus componentes do ElastiCache com base nos requisitos da workload. O ElastiCache é único porque alguns casos de uso são totalmente efêmeros e não exigem nenhuma estratégia de DR, enquanto outros estão na extremidade oposta do espectro e exigem uma estratégia de DR extremamente robusta. Todas as opções devem ser ponderadas em relação à otimização de custos: maior resiliência requer mais recursos de infraestrutura.
Entenda as opções de DR disponíveis em nível regional e multirregional.
+ As implantações multi-AZ são recomendadas para evitar falhas de AZ. Realize a implantação com o modo de cluster habilitado em arquiteturas multi-AZ, com um mínimo de 3 AZs disponíveis.
+ O Global Datastore é recomendado para se proteger contra falhas regionais.
+ **[Ideal] **Habilite o Global Datastore para workloads que exigem resiliência por região.
+ Tenha um plano para realizar failover para a região secundária em caso de degradação da primária.
+ Teste o processo de failover multirregional antes de um failover na produção.
+ Monitore a métrica `ReplicationLag` para entender o impacto potencial da perda de dados durante eventos de failover.
+ **[Recursos]: **
+ [Atenuar falhas](disaster-recovery-resiliency.md#FaultTolerance)
+ [Replicação entre regiões da AWS usando datastores globais](Redis-Global-Datastore.md)
+ [Restauração de um backup com redimensionamento opcional do cluster](backups-restoring.md)
+ [Minimizar o tempo de inatividade no ElastiCache para Valkey e Redis OSS usando o Multi-AZ](AutoFailover.md)
## CONF 4: Como se planejar efetivamente para os failovers?
**Introdução: **habilitar o multi-AZ com failovers automáticos é uma prática recomendada do ElastiCache. Em certos casos, o ElastiCache para Valkey e Redis OSS substitui os nós primários como parte das operações de serviço. Exemplos incluem eventos de manutenção planejada e o caso improvável de falha em um nó ou problema em zona de disponibilidade. Os failovers bem-sucedidos dependem da configuração do ElastiCache e da sua biblioteca de cliente.
**Benefício: **seguir as práticas recomendadas para failovers do ElastiCache em conjunto com sua biblioteca de cliente específica do ElastiCache ajuda a minimizar o tempo de inatividade potencial durante eventos de failover.
+ **[Obrigatório] **Com o modo de cluster desabilitado, use tempos limite para que seus clientes detectem se precisam se desconectar do nó primário antigo e se reconectar ao novo nó primário, usando o endereço IP do endpoint primário atualizado. Com o modo de cluster habilitado, a biblioteca de cliente é responsável por detectar alterações na topologia subjacente do cluster. Isso é feito com mais frequência por meio de configurações na biblioteca de cliente do ElastiCache, que também permitem definir a frequência e o método de atualização. Cada biblioteca de cliente oferece configurações próprias e mais detalhes estão disponíveis na documentação correspondente.
**[Recursos]: **
+ [Minimizar o tempo de inatividade no ElastiCache para Valkey e Redis OSS usando o Multi-AZ](AutoFailover.md)
+ Analise as práticas recomendadas da sua biblioteca de cliente do ElastiCache.
+ **[Obrigatório] **Os failovers bem-sucedidos dependem de um ambiente de replicação saudável entre o nó primário e os nós de réplica. Analise e compreenda a natureza assíncrona da replicação do Valkey e Redis OSS, bem como as métricas do CloudWatch disponíveis para relatar o atraso na replicação entre o nó primário e os nós de réplica. Para casos de uso que exigem maior segurança de dados, use o comando WAIT para forçar as réplicas a reconhecerem as gravações antes de responder aos clientes conectados.
**[Recursos]: **
+ [Métricas para o Valkey ou Redis OSS](CacheMetrics.Redis.md)
+ [Monitorar as práticas recomendadas com o ElastiCache usando o Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Ideal] **Valide regularmente a capacidade de resposta da aplicação durante o failover usando a API Test Failover do ElastiCache.
**[Recursos]: **
+ [Testar o failover automático para uma réplica de leitura no ElastiCache](https://aws.amazon.com/blogs/database/testing-automatic-failover-to-a-read-replica-on-amazon-elasticache-for-redis/)
+ [Teste do failover automático](AutoFailover.md#auto-failover-test)
## CONF 5: Seus componentes do ElastiCache foram projetados para escalar?
**Introdução: **quando você entende os recursos de ajuste de escala e as topologias de implantação disponíveis, seus componentes do ElastiCache podem se ajustar ao longo do tempo para atender às mudanças nos requisitos da workload. O ElastiCache oferece ajuste de escala em quatro direções: aumento/redução na horizontal e na vertical.
**Benefício: **seguir as práticas recomendadas para implantações do ElastiCache oferece a maior flexibilidade para ajuste de escala, além de atender ao princípio do Well Architected de ajuste horizontal da escala para minimizar o impacto das falhas.
+ **[Obrigatório] **Entenda a diferença entre topologias com modo de cluster habilitado e desabilitado. Em quase todos os casos, é recomendável realizar a implantação com o modo de cluster habilitado, pois isso aumenta a escalabilidade ao longo do tempo. Os componentes com modo de cluster desabilitado têm capacidade limitada de escalar horizontalmente com a adição de réplicas de leitura.
+ **[Obrigatório] **Entenda quando e como escalar.
+ Para mais READIOPS: adicione réplicas.
+ Para mais WRITEOPS: adicione fragmentos (aumentar a escala horizontalmente).
+ Para mais E/S de rede: use instâncias otimizadas para rede (aumentar a escala verticalmente).
+ **[Ideal] **Implante seus componentes do ElastiCache com o modo de cluster habilitado, com uma tendência para mais nós menores, em vez de menos nós maiores. Isso limita o raio de alcance de uma falha de nó.
+ **[Ideal] **Inclua réplicas em seus clusters para melhorar a capacidade de resposta durante eventos de ajuste de escala.
+ **[Bom] **Com o modo de cluster desabilitado, utilize as réplicas de leitura para aumentar a capacidade geral de leitura. O ElastiCache oferece suporte a até 5 réplicas de leitura com o modo de cluster desabilitado, além de ajuste vertical da escala.
+ **[Recursos]: **
+ [Escalar clusters do ElastiCache](Scaling.md)
+ [Aumento de escala vertical on-line](redis-cluster-vertical-scaling.md#redis-cluster-vertical-scaling-scaling-up)
# Pilar de ElastiCache eficiência de desempenho da lente Amazon Well-Architected
O pilar Eficiência de performance enfoca o uso eficiente dos recursos de TI e computação. Os principais tópicos incluem a seleção dos tipos e tamanhos certos de recursos com base nos requisitos da workload, o monitoramento da performance e a tomada de decisões informadas para manter a eficiência à medida que as necessidades dos negócios evoluem.
**Topics**
+ [PE 1: Como você monitora o desempenho do seu ElastiCache cluster Amazon?](#PerformanceEfficiencyPillarPE1)
+ [PE 2: Como você está distribuindo o trabalho entre os nós ElastiCache do cluster?](#PerformanceEfficiencyPillarPE2)
+ [EP 3: Para workloads de armazenamento em cache, como você monitora e relata a eficácia e a performance do cache?](#PerformanceEfficiencyPillarPE3)
+ [EP 4: Como sua workload otimiza o uso de recursos e conexões de rede?](#PerformanceEfficiencyPillarPE4)
+ [PE 5: Como você gerencia o and/or despejo por exclusão de chaves?](#PerformanceEfficiencyPillarPE5)
+ [PE 6: Como você modela e interage com os dados ElastiCache?](#PerformanceEfficiencyPillarPE6)
+ [PE 7: Como você registra comandos de execução lenta no seu ElastiCache cluster da Amazon?](#PerformanceEfficiencyPillarPE7)
+ [PE8: Como o Auto Scaling ajuda a aumentar o desempenho do ElastiCache cluster?](#PerformanceEfficiencyPillarPE8)
## PE 1: Como você monitora o desempenho do seu ElastiCache cluster Amazon?
**Introdução: **ao entender as métricas de monitoramento existentes, você pode identificar a utilização atual. O monitoramento adequado pode ajudar a identificar possíveis gargalos que afetam a performance de um cluster.
**Benefício: **a compreensão das métricas associadas ao seu cluster pode ajudar a orientar técnicas de otimização que podem levar à redução da latência e ao aumento do throughput.
+ **[Obrigatório] **Teste de referência da performance usando um subconjunto da workload.
+ Você deve monitorar a performance da workload real usando mecanismos, como testes de carga.
+ Monitore as CloudWatch métricas durante a execução desses testes para obter uma compreensão das métricas disponíveis e estabelecer uma linha de base de desempenho.
+ **[Melhor]** ElastiCache Para cargas de trabalho do Valkey e do Redis OSS, renomeie comandos computacionalmente caros`KEYS`, como para limitar a capacidade dos usuários de executar comandos de bloqueio em clusters de produção.
+ ElastiCache cargas de trabalho que executam o engine 6.x para Redis OSS podem aproveitar o controle de acesso baseado em funções para restringir determinados comandos. O acesso aos comandos pode ser controlado criando usuários e grupos de usuários com o AWS console ou a CLI e associando os grupos de usuários a um cluster. No Redis OSS 6, quando o RBAC está habilitado, podemos usar “-@dangerous” para não permitir que determinado usuário execute comandos caros, como KEYS, MONITOR, SORT etc.
+ Para o mecanismo versão 5.x, renomeie os comandos usando o parâmetro `rename-commands` no grupo de parâmetros do cluster.
+ **[Melhor] **Analise consultas lentas e procure técnicas de otimização.
+ ElastiCache Para cargas de trabalho do Valkey e do Redis OSS, saiba mais sobre suas consultas analisando o Slow Log. Por exemplo, você pode usar o comando `valkey-cli slowlog get 10` para mostrar os últimos 10 comandos que excederam o limite de latência (10 milissegundos por padrão).
+ Certas consultas podem ser realizadas com mais eficiência usando estruturas de dados complexas ElastiCache para Valkey e Redis OSS. Como exemplo, para pesquisas de intervalo de estilo numérico, uma aplicação pode implementar índices numéricos simples com conjuntos ordenados. O gerenciamento desses índices pode reduzir as verificações realizadas no conjunto de dados e retornar dados com maior eficiência de performance.
+ ElastiCache Para cargas de trabalho Valkey e Redis OSS, `redis-benchmark` fornece uma interface simples para testar o desempenho de diferentes comandos usando entradas definidas pelo usuário, como número de clientes e tamanho dos dados.
+ Como o Memcached só oferece suporte a comandos simples em nível de chave, considere criar chaves adicionais como índices para evitar a iteração no espaço de chaves a fim de atender às consultas do cliente.
+ **[Recursos]: **
+ [Monitorando o uso com CloudWatch métricas](CacheMetrics.md)
+ [Usando CloudWatch alarmes da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Parâmetros específicos do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis)
+ [SLOWLOG](https://valkey.io/commands/slowlog/)
+ [comparativo](https://valkey.io/topics/benchmark/)
## PE 2: Como você está distribuindo o trabalho entre os nós ElastiCache do cluster?
**Introdução em nível de pergunta:** A forma como seu aplicativo se conecta aos ElastiCache nós da Amazon pode afetar o desempenho e a escalabilidade do cluster.
**Benefício: **o uso adequado dos nós disponíveis no cluster garantirá que o trabalho seja distribuído entre os recursos disponíveis. As técnicas a seguir também ajudam a evitar recursos ociosos.
+ **[Obrigatório]** Faça com que os clientes se conectem ao ElastiCache endpoint adequado.
+ ElastiCache para Valkey e Redis, o OSS implementa endpoints diferentes com base no modo de cluster em uso. Para o modo de cluster ativado, ElastiCache fornecerá um endpoint de configuração. Para o modo de cluster desativado, ElastiCache fornece um endpoint primário, normalmente usado para gravações, e um endpoint de leitura para balancear leituras entre réplicas. A implementação correta desses endpoints resultará em melhor performance e operações de escalabilidade mais fáceis. Evite conectar-se a endpoints de nós individuais, a menos que haja um requisito específico que justifique isso.
+ Para clusters Memcached de vários nós, ElastiCache fornece um endpoint de configuração que permite a descoberta automática. É recomendável usar um algoritmo de hash para distribuir o trabalho uniformemente entre os nós de cache. Muitas bibliotecas de clientes do Memcached implementam hash consistente. Verifique a documentação da biblioteca que você está usando para ver se ela oferece suporte para hashing consistente e como implementá-lo. Você pode encontrar mais informações sobre a implementação desses atributos [aqui](BestPractices.LoadBalancing.md).
+ **[Melhor]** Aproveite os clusters habilitados ElastiCache para o modo de cluster Valkey e Redis OSS para melhorar a escalabilidade.
+ ElastiCache para Valkey e Redis OSS (modo de cluster ativado), os clusters oferecem suporte a [operações de escalabilidade on-line](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online) (out/in and up/down) para ajudar a distribuir dados dinamicamente entre fragmentos. O uso do endpoint de configuração vai garantir que os clientes com reconhecimento de cluster possam se ajustar às mudanças na topologia do cluster.
+ Você também pode reequilibrar o cluster movendo os hashslots entre os fragmentos disponíveis em seu cluster ElastiCache for Valkey e Redis OSS (modo de cluster ativado). Isso ajuda a distribuir o trabalho de modo mais eficiente entre os fragmentos disponíveis.
+ **[Melhor] **Implemente uma estratégia para identificar e corrigir chaves “hot” na workload.
+ Considere o impacto das estruturas de dados multidimensionais do Valkey ou Redis OSS, como listas, fluxos, conjuntos etc. Essas estruturas de dados são armazenadas em chaves únicas, que residem em um único nó. Uma chave multidimensional muito grande tem o potencial de utilizar mais capacidade de rede e memória do que outros tipos de dados e pode provocar um uso desproporcional desse nó. Se possível, projete sua workload para distribuir o acesso aos dados entre várias chaves distintas.
+ As chaves “hot” na workload podem afetar a performance do nó em uso. ElastiCache Para cargas de trabalho Valkey e Redis OSS, você pode detectar teclas de atalho usando `valkey-cli --hotkeys` se uma política de memória máxima de LFU estiver em vigor.
+ Considere replicar chaves “hot” entre vários nós para distribuir o acesso a eles de forma mais uniforme. Essa abordagem exige que o cliente grave em vários nós primários (o próprio nó do Valkey ou Redis OSS não fornecerá essa funcionalidade) e mantenha uma lista de nomes de chaves para leitura, além do nome da chave original.
+ ElastiCache [O motor 7.2 para Valkey e superior e a ElastiCache versão 6 para Redis OSS e superior oferecem suporte ao cache do lado do cliente assistido pelo servidor.](https://valkey.io/topics/client-side-caching/) Isso permite que os aplicativos aguardem alterações em uma chave antes de fazer chamadas de rede de volta paraElastiCache.
+ **[Recursos]: **
+ [Configure ElastiCache para Valkey e Redis OSS para maior disponibilidade](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
+ [Encontrar endpoints de conexão no ElastiCache](Endpoints.md)
+ [Práticas recomendadas para balanceamento de carga](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/BestPractices.LoadBalancing.html)
+ [Refragmentação online para o Valkey ou o Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md#redis-cluster-resharding-online)
+ [Armazenamento em cache do lado do cliente no Valkey e Redis OSS](https://valkey.io/topics/client-side-caching/)
## EP 3: Para workloads de armazenamento em cache, como você monitora e relata a eficácia e a performance do cache?
**Introdução em nível de pergunta:** O armazenamento em cache é uma carga de trabalho comum ElastiCache e é importante que você entenda como gerenciar a eficácia e o desempenho do cache.
**Benefício: **sua aplicação pode mostrar sinais de performance lenta. Sua capacidade de usar métricas específicas de cache para informar sua decisão sobre como aumentar a performance da aplicação é essencial para sua workload de cache.
+ **[Obrigatório] **Meça e acompanhe a taxa de acertos de cache ao longo do tempo. A eficiência do seu cache é determinada pela “taxa de acertos de cache”. A taxa de acertos de cache é definida pelo total de acertos de chave dividido pelo total de acertos e erros. Quanto mais próxima de 1 for a taxa, mais eficaz será o cache. Uma taxa de acertos de cache baixa é decorrente do volume de erros de cache. Os erros de cache ocorrem quando a chave solicitada não é encontrada no cache. Uma chave não está no cache porque ela foi removida ou excluída, expirou ou nunca existiu. Entenda por que as chaves não estão no cache e desenvolva estratégias apropriadas para incluí-las no cache.
**[Recursos]: **
+ [Métricas para o Valkey e Redis OSS](CacheMetrics.Redis.md)
+ **[Obrigatório]** Meça e colete o desempenho do cache do aplicativo em conjunto com os valores de latência e utilização da CPU para entender se você precisa fazer ajustes no seu time-to-live ou em outros componentes do aplicativo. ElastiCache fornece um conjunto de CloudWatch métricas para latências agregadas para cada estrutura de dados. Essas métricas de latência são calculadas usando a estatística commandstats do comando INFO e não incluem o tempo de rede e E/S. Esse é apenas o tempo consumido ElastiCache para processar as operações.
**[Recursos]: **
+ [Métricas para o Valkey e Redis OSS](CacheMetrics.Redis.md)
+ [Monitorando as melhores práticas com ElastiCache o uso da Amazon CloudWatch](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)
+ **[Ideal] **Escolha a estratégia de cache certa para suas necessidades. Uma taxa de acertos de cache baixa é decorrente do volume de erros de cache. Se sua workload foi projetada para ter um baixo volume de erros de cache (como comunicação em tempo real), é melhor realizar análises de suas estratégias de armazenamento em cache e aplicar as resoluções mais apropriadas para sua workload, como instrumentação de consulta para medir a memória e a performance. As estratégias implementadas para preencher e manter seu cache dependem de quais dados seus clientes precisam armazenar em cache e dos padrões de acesso a esses dados. Por exemplo, é improvável que você use a mesma estratégia para recomendações personalizadas em uma aplicação de streaming e para notícias em alta.
**[Recursos]: **
+ [Estratégias de armazenamento em cache para Memcached](Strategies.md)
+ [Práticas recomendadas de armazenamento em cache](https://aws.amazon.com/caching/best-practices/)
+ [Desempenho em grande escala com o ElastiCache Whitepaper da Amazon](https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf)
## EP 4: Como sua workload otimiza o uso de recursos e conexões de rede?
**Introdução em nível de pergunta:** ElastiCache para Valkey, Memcached e Redis, o OSS é suportado por muitos clientes de aplicativos, e as implementações podem variar. Você precisa entender o gerenciamento de redes e conexões em vigor para analisar o impacto potencial na performance.
**Benefício: **o uso eficiente dos recursos de rede pode melhorar a eficiência da performance do seu cluster. As recomendações a seguir podem reduzir as demandas de rede e melhorar a latência e o throughput do cluster.
+ **[Obrigatório]** Gerencie proativamente as conexões com seu ElastiCache cluster.
+ O agrupamento de conexões na aplicação reduz a sobrecarga criada no cluster devido à abertura e ao encerramento de conexões. Monitore o comportamento da conexão na Amazon CloudWatch usando `CurrConnections` `NewConnections` e.
+ Evite a fuga de conexões ao encerrar adequadamente as conexões de clientes, quando apropriado. As estratégias de gerenciamento de conexões incluem o encerramento adequado das conexões que não estão em uso e a definição de tempo limite para conexões.
+ Para workloads do Memcached, há uma quantidade configurável de memória reservada para lidar com conexões chamada `memcached_connections_overhead`.
+ **[Melhor] **Compacte objetos grandes para reduzir a memória e melhorar o throughput da rede.
+ A compactação de dados pode reduzir a quantidade necessária de throughput de rede (Gbps), mas aumenta a quantidade de trabalho na aplicação para compactar e descompactar dados.
+ A compactação também reduz a quantidade de memória consumida pelas chaves.
+ Com base nas necessidades da sua aplicação, considere as diferenças entre taxa de compressão e velocidade de compressão.
+ **[Recursos]: **
+ [ElastiCache - Armazenamento de dados global](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [Parâmetros específicos do Memcached](ParameterGroups.Engine.md#ParameterGroups.Memcached)
+ [ElastiCache a versão 5.0.3 para Redis OSS aprimora o manuseio para aumentar o desempenho I/O ](https://aws.amazon.com/about-aws/whats-new/2019/03/amazon-elasticache-for-redis-503-enhances-io-handling-to-boost-performance/)
+ [Métricas para o Valkey e Redis OSS](CacheMetrics.Redis.md)
+ [Configure ElastiCache para maior disponibilidade](https://aws.amazon.com/blogs/database/configuring-amazon-elasticache-for-redis-for-higher-availability/)
## PE 5: Como você gerencia o and/or despejo por exclusão de chaves?
**Introdução em nível de pergunta:** as cargas de trabalho têm requisitos e comportamentos esperados diferentes quando um nó de cluster está se aproximando dos limites de consumo de memória. ElastiCache tem políticas diferentes para lidar com essas situações.
**Benefício: **o gerenciamento adequado da memória disponível e a compreensão das políticas de remoção vão ajudar a garantir o conhecimento do comportamento do cluster quando os limites de memória da instância forem excedidos.
+ **[Obrigatório] **Instrumente o acesso aos dados para avaliar qual política aplicar. Identifique uma política de memória máxima apropriada para controlar se e como as remoções são realizadas no cluster.
+ A remoção ocorre quando a memória máxima do cluster é consumida e há uma política em vigor para permitir a remoção. O comportamento do cluster nessa situação depende da política de remoção especificada. Essa política pode ser gerenciada usando `maxmemory-policy` no grupo de parâmetros de cluster.
+ A política padrão `volatile-lru` libera memória ao remover chaves com um prazo de validade definido (valor de TTL). As políticas menos usadas (LFU) e menos usadas recentemente (LRU) removem as chaves com base no uso.
+ Para workloads do Memcached, existe uma política LRU padrão que controla as remoções em cada nó. O número de despejos em seu ElastiCache cluster da Amazon pode ser monitorado usando a métrica de despejos na Amazon. CloudWatch
+ **[Melhor] **Padronize o comportamento de exclusão para controlar o impacto na performance de seu cluster e evitar gargalos de performance inesperados.
+ ElastiCache Para cargas de trabalho do Valkey e do Redis OSS, ao remover explicitamente as chaves do cluster, `UNLINK` é como`DEL`: ele remove as chaves especificadas. No entanto, o comando executa a recuperação real da memória em um thread diferente, portanto não bloqueio, enquanto `DEL` bloqueia. A remoção real ocorrerá posteriormente de forma assíncrona.
+ Para a ElastiCache versão 6.x para cargas de trabalho do Redis OSS, o comportamento do `DEL` comando pode ser modificado no grupo de parâmetros usando o parâmetro. `lazyfree-lazy-user-del`
+ **[Recursos]: **
+ [Configuração de parâmetros do mecanismo usando grupos de parâmetros do ElastiCache](ParameterGroups.md)
+ [UNLINK](https://valkey.io/commands/unlink/)
+ [Gerenciamento financeiro em nuvem com AWS](https://aws.amazon.com/aws-cost-management/)
## PE 6: Como você modela e interage com os dados ElastiCache?
**Introdução em nível de pergunta:** ElastiCache depende muito do aplicativo das estruturas de dados e do modelo de dados usados, mas também precisa considerar o armazenamento de dados subjacente (se presente). Entenda as estruturas de dados disponíveis e garanta que você esteja usando as estruturas de dados mais adequadas às suas necessidades.
**Benefício em nível de pergunta:** a modelagem de dados ElastiCache tem várias camadas, incluindo casos de uso de aplicativos, tipos de dados e relacionamentos entre elementos de dados. Além disso, cada tipo de dado e comando tem suas próprias assinaturas de performance bem documentadas.
+ **[Ideal] **Uma das práticas recomendadas é reduzir a substituição não intencional de dados. Use uma convenção de nomenclatura que minimize a sobreposição de nomes de chave. A nomenclatura convencional de suas estruturas de dados usa um método hierárquico, como `APPNAME:CONTEXT:ID` e `ORDER-APP:CUSTOMER:123`.
**[Recursos]: **
+ [Nomenclatura de chaves](https://docs.gitlab.com/ee/development/redis.html#key-naming)
+ **[Melhor]** ElastiCache para Valkey e Redis, os comandos OSS têm uma complexidade de tempo definida pela notação Big O. Desta vez, a complexidade de um comando é uma algorithmic/mathematical representação de seu impacto. Ao introduzir um novo tipo de dado em sua aplicação, você precisa analisar cuidadosamente a complexidade temporal dos comandos relacionados. Os comandos com uma complexidade temporal de O(1) são constantes no tempo e não dependem do tamanho da entrada, enquanto os comandos com uma complexidade temporal de O(N) são lineares no tempo e estão sujeitos ao tamanho da entrada. Devido ao design de thread único do Valkey e do ElastiCache Redis OSS, um grande volume de operações de alta complexidade de tempo resultará em menor desempenho e em possíveis tempos limite de operação.
**[Recursos]: **
+ [Comandos](https://valkey.io/commands/)
+ **[Melhor]** Use APIs para obter visibilidade da GUI no modelo de dados em seu cluster.
**[Recursos]: **
+ [Comandante do Redis OSS](https://www.npmjs.com/package/ElastiCache for Redis-commander)
+ [Navegador do Redis OSS](https://github.com/humante/redis-browser)
+ [Redsmin](https://www.redsmin.com/)
## PE 7: Como você registra comandos de execução lenta no seu ElastiCache cluster da Amazon?
**Introdução: **benefícios do ajuste de performance por meio da captura, agregação e notificação de comandos de longa execução. Ao entender quanto tempo leva para que os comandos sejam executados, você pode determinar quais comandos resultam em baixo desempenho, bem como os comandos que impedem o desempenho ideal do mecanismo. ElastiCache também tem a capacidade de encaminhar essas informações para a Amazon CloudWatch ou o Amazon Kinesis Data Firehose.
**Benefício: **manter um log em um local permanente dedicado e fornecer eventos de notificação para comandos lentos podem ajudar na análise detalhada da performance e podem servir para acionar eventos automatizados.
+ **[Obrigatório]** ElastiCache executando um mecanismo Valkey 7.2 ou mais recente, ou executando um mecanismo Redis OSS versão 6.0 ou mais recente, grupo de parâmetros configurado corretamente e registro do SLOWLOG ativado no cluster.
+ Os parâmetros necessários só estarão disponíveis quando a compatibilidade da versão do mecanismo estiver definida como Valkey 7.2 e posterior, ou Redis OSS versão 6.0 ou posterior.
+ O registro em log SLOWLOG ocorre quando o tempo de execução de um comando pelo servidor é maior que um valor especificado. O comportamento do cluster depende dos parâmetros do grupo de parâmetros associado, que são `slowlog-log-slower-than` e `slowlog-max-len`.
+ As alterações terão efeito imediatamente.
+ **[Melhor]** Aproveite nossos recursos do CloudWatch Kinesis Data Firehose.
+ Use os recursos de filtragem e alarme do CloudWatch CloudWatch Logs Insights e do Amazon Simple Notification Services para obter monitoramento de desempenho e notificação de eventos.
+ Use os recursos de streaming do Kinesis Data Firehose para arquivar logs SLOWLOG no armazenamento permanente ou para acionar o ajuste automático de parâmetros do cluster.
+ Determine qual formato atende melhor às suas necessidades, JSON ou texto simples.
+ Forneça permissões do IAM para publicar no CloudWatch ou no Kinesis Data Firehose.
+ **[Melhor] **Configure `slowlog-log-slower-than` com um valor diferente do padrão.
+ Esse parâmetro determina por quanto tempo um comando pode ser executado no mecanismo Valkey ou Redis OSS antes de ser registrado em log como um comando lento. O valor padrão é 10.000 microssegundos (10 milissegundos). O valor padrão pode ser muito alto para algumas workloads.
+ Determine um valor que seja mais adequado para sua workload com base nas necessidades da aplicação e nos resultados dos testes, mas lembre-se de que um valor muito baixo pode gerar dados em excesso.
+ **[Melhor] **Mantenha o valor padrão de `slowlog-max-len`.
+ Esse parâmetro determina o limite superior de quantos comandos lentos são capturados na memória do Valkey ou Redis OSS por vez. O valor 0 desabilita a captura. Quanto maior o valor, mais entradas serão armazenadas na memória, reduzindo a chance de informações importantes serem removidas antes que possam ser revisadas. O valor padrão é 128.
+ O valor padrão é adequado para a maioria das workloads. Se houver necessidade de analisar dados em uma janela de tempo expandida a partir de valkey-cli por meio do comando SLOWLOG, considere aumentar esse valor. Isso permite que mais comandos permaneçam na memória do Valkey ou Redis OSS.
Se você estiver emitindo os dados do SLOWLOG para o CloudWatch Logs ou para o Kinesis Data Firehose, os dados persistirão e poderão ser analisados fora do sistema, reduzindo ElastiCache a necessidade de armazenar um grande número de comandos de execução lenta na memória Valkey ou Redis OSS.
+ **[Recursos]: **
+ [Como ativo o log lento em um cluster?](https://repost.aws/knowledge-center/elasticache-turn-on-slow-log)
+ [Entrega de logs](Log_Delivery.md)
+ [Parâmetros específicos do Redis OSS](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: Como o Auto Scaling ajuda a aumentar o desempenho do ElastiCache cluster?
**Introdução em nível de pergunta: ao** implementar o recurso de escalonamento automático Valkey ou Redis OSS, ElastiCache seus componentes podem se ajustar com o tempo para aumentar ou diminuir automaticamente os fragmentos ou réplicas desejados. Isso pode ser feito implementando a política de rastreamento de metas ou de ajuste de escala programado.
**Benefício em nível de pergunta:** compreender e planejar os picos na carga de trabalho pode garantir um desempenho aprimorado do armazenamento em cache e a continuidade dos negócios. ElastiCache O Auto Scaling monitora continuamente a utilização da CPU/memória para garantir que o cluster esteja operando nos níveis de desempenho desejados.
+ **[Obrigatório]** Ao iniciar um cluster ElastiCache para Valkey ou Redis OSS:
1. Verifique se o modo de cluster está habilitado.
1. Verifique se a instância pertence a uma família de determinado tipo e tamanho compatíveis com o ajuste de escala automático.
1. Verifique se o cluster não está sendo executado em datastores globais, Outposts ou zonas locais.
**[Recursos]: **
+ [Escalabilidade de clusters no Valkey e Redis OSS (modo cluster habilitado)](scaling-redis-cluster-mode-enabled.md)
+ [Usar o ajuste de escala automático com fragmentos](AutoScaling-Using-Shards.md)
+ [Usar o ajuste de escala automático com réplicas](AutoScaling-Using-Replicas.md)
+ **[Ideal] **Identifique se sua workload exige muita leitura ou gravação para definir a política de ajuste de escala. Para obter a melhor performance, use apenas uma métrica de rastreamento. É recomendável evitar várias políticas para cada dimensão, pois as políticas de ajuste de escala automático aumentam a escala horizontalmente quando a meta é atingida, mas só aumentam a escala verticalmente quando todas as políticas de rastreamento de metas estiverem prontas para aumentar a escala verticalmente.
**[Recursos]: **
+ [Políticas de ajuste de escala automático](AutoScaling-Policies.md)
+ [Definir uma política de ajuste de escala](AutoScaling-Scaling-Defining-Policy-API.md)
+ **[Ideal] **O monitoramento da performance ao longo do tempo pode ajudar você a detectar mudanças na workload que passariam despercebidas se monitoradas em momentos específicos. Você pode analisar as CloudWatch métricas correspondentes para a utilização do cluster em um período de quatro semanas para determinar o limite do valor-alvo. Se você ainda não tiver certeza de qual valor escolher, recomendamos começar com o valor mínimo de métrica predefinido compatível.
**[Recursos]: **
+ [Monitorando o uso com CloudWatch métricas](CacheMetrics.md)
+ **[Melhor]** Recomendamos testar seu aplicativo com as cargas de trabalho mínimas e máximas esperadas, para identificar o número exato de cargas de trabalho shards/replicas necessárias para que o cluster desenvolva políticas de escalabilidade e mitigue problemas de disponibilidade.
**[Recursos]: **
+ [Registrar uma meta escalável](AutoScaling-Register-Policy.md)
+ [Registrando um alvo escalável usando o AWS CLI](AutoScaling-Scaling-Registering-Policy-CLI.md)
# Pilar Otimização de custos da Lente do Well-Architected para o Amazon ElastiCache
O foco do pilar Otimização de custos é evitar custos desnecessários. Os principais tópicos incluem entender e controlar onde o dinheiro está sendo gasto, selecionar o tipo de nó mais adequado (usar instâncias que compatíveis com a hierarquização de dados com base nas necessidades da workload), a quantidade certa de tipos de recurso (quantidade de réplicas de leitura), a análise de gastos ao longo do tempo e a escalabilidade para atender às necessidades da empresa sem gastos excessivos.
**Topics**
+ [CUSTOS 1: Como você identifica e monitora os custos associados aos seus recursos do ElastiCache? Como você desenvolve mecanismos para permitir que os usuários criem, gerenciem e descartem os recursos criados?](#CostOptimizationPillarCOST1)
+ [CUSTOS 2: Como você usa ferramentas de monitoramento contínuo para ajudar a otimizar os custos associados aos seus recursos do ElastiCache?](#CostOptimizationPillarCOST2)
+ [CUSTOS 3: Você deve usar um tipo de instância que ofereça suporte à hierarquização de dados? Quais são as vantagens de uma hierarquização de dados? Quando não usar instâncias de hierarquização de dados?](#CostOptimizationPillarCOST3)
## CUSTOS 1: Como você identifica e monitora os custos associados aos seus recursos do ElastiCache? Como você desenvolve mecanismos para permitir que os usuários criem, gerenciem e descartem os recursos criados?
**Introdução: **entender as métricas de custo requer a participação e a colaboração de várias equipes: engenharia de software, gerenciamento de dados, proprietários de produtos, finanças e liderança. A identificação dos principais fatores de custo exige que todas as partes envolvidas compreendam as alavancas de controle do uso do serviço e as vantagens e desvantagens do gerenciamento de custos, e essa costuma ser a principal diferença entre ações bem-sucedidas e não tão bem-sucedidas de otimização de custos. Garantir que você tenha processos e ferramentas em vigor para monitorar os recursos criados desde o desenvolvimento até a produção e a retirada ajuda a gerenciar os custos associados ao ElastiCache.
**Benefício: **o acompanhamento contínuo de todos os custos associados à workload exige uma compreensão profunda da arquitetura que inclui o ElastiCache como um de seus componentes. Além disso, você deve ter um plano de gerenciamento de custos para coletar e comparar o uso com seu orçamento.
+ **[Obrigatório] **Institua um Centro de Excelência da Nuvem (CCoE) com um de seus estatutos fundadores para definir, monitorar e agir com base nas métricas relacionadas ao uso do ElastiCache em suas organizações. Se existir um CCoE funcional, garanta que ele saiba como ler e acompanhar os custos associados ao ElastiCache. Ao criar recursos, use políticas e perfis do IAM para validar que somente equipes e grupos específicos possam instanciar recursos. Isso vai garantir que os custos estejam associados aos resultados comerciais e que uma linha clara de responsabilidade seja estabelecida, do ponto de vista dos custos.
1. O CCoE deve identificar, definir e publicar métricas de custo que são atualizadas mensalmente sobre o uso principal do ElastiCache em dados categóricos, como:
1. Tipos de nó usados e seus atributos: instâncias padrão versus instâncias otimizadas para memória, instâncias sob demanda versus instâncias reservadas, regiões e zonas de disponibilidade
1. Tipos de ambiente: gratuito, desenvolvimento, teste e produção
1. Estratégias de backup, armazenamento e retenção
1. Transferência de dados dentro de uma região e entre regiões
1. Instâncias em execução no Amazon Outposts
1. O CCoE consiste em uma equipe multifuncional com representação não exclusiva das equipes de engenharia de software, gerenciamento de dados, produtos, finanças e liderança em sua organização.
**[Recursos]: **
+ [Criar um Centro de Excelência da Nuvem](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html)
+ [Preço do Amazon ElastiCache](https://aws.amazon.com/elasticache/pricing/)
+ **[Obrigatório] **Use etiquetas de alocação de custos para monitorar os custos em um baixo nível de granularidade. Use o Gerenciamento de Custos da AWS para visualizar, entender e gerenciar seus custos e uso da AWS ao longo do tempo.
1. Use etiquetas para organizar seus recursos e etiquetas de alocação de custos para monitorar os custos da AWS em detalhes. Depois de ativar as etiquetas de alocação de custos, a AWS as utiliza para organizar seus custos de recursos no relatório de alocação de custos para facilitar a categorização e o controle dos seus custos na AWS. A AWS fornece dois tipos de etiquetas de alocação de custos: etiquetas geradas pela AWS e etiquetas definidas por usuário. A AWS define, cria e aplica as etiquetas geradas pela AWS para você, enquanto você define, cria e aplica as etiquetas definidas por usuário. É necessário ativar os dois tipos de etiquetas separadamente para que elas possam ser exibidas no Gerenciamento de Custos ou em um relatório de alocação de custos.
1. Use tags de alocação de custos para organizar sua fatura da AWS para refletir sua própria estrutura de custos. Quando você adiciona etiquetas de alocação de custos aos seus recursos no Amazon ElastiCache, pode acompanhar os custos agrupando as despesas nas suas faturas por valores de etiqueta de recursos. Considere combinar etiquetas para monitorar os custos com um maior nível de detalhes.
**[Recursos]: **
+ [Usar etiquetas de alocação de custos da AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [Monitorar os custos com etiquetas de alocação de custos](Tagging.md)
+ [Explorador de Custos da AWS](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ **[Ideal] **Conecte o custo do ElastiCache às métricas que abrangem toda a organização.
1. Considere as métricas de negócios e as métricas operacionais, como latência: quais conceitos em seu modelo de negócios são compreensíveis em todas as funções? As métricas precisam ser compreensíveis pelo maior número possível de funções na organização.
1. Exemplos: usuários atendidos simultaneamente, latência máxima e média por operação e usuário, pontuações de engajamento do usuário, taxas de retorno do usuário/semana, duração da sessão/usuário, taxa de abandono, taxa de acertos de cache e chaves monitoradas.
**[Recursos]: **
+ [Monitorar o uso com métricas do CloudWatch](CacheMetrics.md)
+ **[Bom] **Mantenha uma visibilidade arquitetônica e operacional atualizada sobre métricas e custos em toda a workload que usa o ElastiCache.
1. Entenda todo o seu ecossistema de soluções. O ElastiCache tende a fazer parte de um ecossistema completo de serviços da AWS em seu conjunto de tecnologias, desde clientes até API Gateway, Redshift e QuickSight para ferramentas de geração de relatórios (por exemplo).
1. Mapeie os componentes da sua solução, desde clientes, conexões, segurança, operações em memória, armazenamento, automação de recursos, acesso e gerenciamento de dados, em seu diagrama de arquitetura. Cada camada se conecta a toda a solução e tem suas próprias necessidades e recursos que aumentam e/ou ajudam a gerenciar o custo geral.
1. Seu diagrama deve incluir o uso de políticas de computação, rede, armazenamento, ciclo de vida, coleta de métricas, bem como os elementos operacionais e funcionais do ElastiCache da sua aplicação.
1. É provável que os requisitos de uma workload evoluam com o tempo e é essencial que você continue a manter e documentar sua compreensão dos componentes subjacentes, bem como de seus principais objetivos funcionais, a fim de manter a proatividade no gerenciamento de custos da workload.
1. O suporte executivo para visibilidade, responsabilização, priorização e recursos é crucial para que você tenha uma estratégia eficaz de gerenciamento de custos para o ElastiCache.
## CUSTOS 2: Como você usa ferramentas de monitoramento contínuo para ajudar a otimizar os custos associados aos seus recursos do ElastiCache?
**Introdução: **você precisa buscar um equilíbrio adequado entre os custos do ElastiCache e as métricas de performance da aplicação. O Amazon CloudWatch fornece visibilidade das principais métricas operacionais que podem te ajudar a avaliar se seus recursos do ElastiCache estão sendo usados em excesso ou subutilizados em relação às suas necessidades. Do ponto de vista da otimização de custos, você precisa entender quando há excesso de provisionamento e ser capaz de desenvolver mecanismos apropriados para redimensionar seus recursos do ElastiCache, ao mesmo tempo em que mantém suas necessidades de operação, disponibilidade, resiliência e performance.
**Benefício: **em um estado ideal, você terá provisionado recursos suficientes para atender às necessidades operacionais de sua workload e não terá recursos subutilizados que possam levar a um estado de custo abaixo do ideal. Você precisa ser capaz de identificar e evitar a operação de recursos superdimensionados do ElastiCache por longos períodos.
+ **[Obrigatório] **Use o CloudWatch para monitorar seus clusters do ElastiCache e analisar como essas métricas se relacionam com seus painéis do Explorador de custos da AWS.
1. O ElastiCache fornece métricas em nível de host (por exemplo, uso da CPU) e métricas que são específicas do software do mecanismo de cache (por exemplo, obtenções e ausências no cache). Essas métricas são medidas e publicadas para cada nó de cache em intervalos de 60 segundos.
1. As métricas de performance do ElastiCache (CPUUtilization, EngineUtilization, SwapUsage, CurrConnections e Evictions) podem indicar que você precisa aumentar/diminuir a escala verticalmente (usar tipos de nó de cache maiores/menores) ou aumentar/diminuir a escala horizontalmente (adicionar mais/menos fragmentos). Entenda as implicações de custo das decisões de ajuste de escala criando uma matriz de playbook que estima o custo adicional e os períodos mínimo e máximo necessários para atingir os limites de performance de sua aplicação.
**[Recursos]: **
+ [Monitorar o uso com métricas do CloudWatch](CacheMetrics.md)
+ [Quais métricas devo monitorar?](CacheMetrics.WhichShouldIMonitor.md)
+ [Preço do Amazon ElastiCache](https://aws.amazon.com/elasticache/pricing/)
+ **[Obrigatório] **Entenda e documente sua estratégia de backup e as implicações de custo.
1. Com o ElastiCache, os backups são armazenados no Amazon S3, que fornece armazenamento durável. Você precisa entender as implicações de custo em relação à sua capacidade de se recuperar de falhas.
1. Ative backups automáticos que vão excluir os arquivos de backup que ultrapassaram o limite de retenção.
**[Recursos]: **
+ [Programação de backups automáticos](backups-automatic.md)
+ [Preços do Amazon Simple Storage Service](https://aws.amazon.com/s3/pricing/)
+ **[Ideal] **Use nós reservados para suas instâncias como uma estratégia deliberada para gerenciar custos de workloads que sejam bem compreendidas e documentadas. Para nós reservados, é necessário pagar uma taxa adiantada que depende do tipo de nó e da duração da reserva, um ou três anos. Essa cobrança é muito menor do que a cobrança de uso por hora dos nós sob demanda.
1. Talvez seja necessário operar os clusters do ElastiCache usando nós sob demanda até reunir dados suficientes para estimar os requisitos da instância reservada. Planeje e documente os recursos necessários para atender às suas necessidades e compare os custos esperados em todos os tipos de instância (sob demanda versus reservada)
1. Avalie regularmente os novos tipos de nó de cache disponíveis e avalie se faz sentido, do ponto de vista das métricas de operação e custo, migrar sua frota de instâncias para novos tipos de nó de cache.
## CUSTOS 3: Você deve usar um tipo de instância que ofereça suporte à hierarquização de dados? Quais são as vantagens de uma hierarquização de dados? Quando não usar instâncias de hierarquização de dados?
**Introdução:** selecionar o tipo de instância apropriado pode afetar não só a performance e o serviço, mas também as finanças. Cada tipo de instância tem custos diferentes. Selecionar um ou alguns tipos de instâncias grandes que possam acomodar todas as necessidades de armazenamento em memória pode ser uma decisão natural. No entanto, isso pode afetar significativamente os custos à medida que o projeto amadurece. Garantir que o tipo de instância correto seja selecionado exige uma avaliação periódica do tempo de inatividade do objeto do ElastiCache.
**Benefício: **você deve ter uma compreensão clara de como os vários tipos de instância afetam seus custos no presente e no futuro. Mudanças marginais ou periódicas na workload não devem provocar mudanças desproporcionais nos custos. Se a workload permitir, os tipos de instância compatíveis com a hierarquização de dados oferecem um preço melhor por armazenamento disponível. Devido à disponibilidade por instância de armazenamento SSD, as instâncias com hierarquização de dados oferecem suporte a uma capacidade total de dados muito maior por instância.
+ **[Obrigatório] **Entenda as limitações das instâncias com hierarquização de dados.
1. Disponível somente para clusters do ElastiCache para Valkey ou Redis OSS.
1. Somente alguns tipos de instância oferecem suporte à hierarquização de dados.
1. Somente o ElastiCache versão 6.2 para Redis e superior é compatível.
1. Itens grandes não são trocados para SSD. Objetos com mais de 128 MiB são mantidos na memória.
**[Recursos]: **
+ [Hierarquização de dados](data-tiering.md)
+ [Preço do Amazon ElastiCache](https://aws.amazon.com/elasticache/pricing/)
+ **[Obrigatório] **Entenda qual porcentagem do seu banco de dados é acessada regularmente pela workload.
1. As instâncias com hierarquização de dados são ideais para workloads que geralmente acessam uma pequena parte do conjunto geral de dados, mas que ainda exigem acesso rápido aos dados restantes. Em outras palavras, a proporção de dados quentes para mornos é de cerca de 20:80.
1. Desenvolva o monitoramento do tempo ocioso do objeto no cluster.
1. Grandes implementações de mais de 500 Gb de dados são boas candidatas.
+ **[Obrigatório] **Entenda que as instâncias com hierarquização de dados não são opcionais para determinadas workloads.
1. Há um pequeno custo de performance para acessar objetos usados com menos frequência, pois eles são trocados para um SSD local. Se sua aplicação for sensível ao tempo de resposta, teste o impacto na workload.
1. Não é adequado para caches que armazenam principalmente objetos grandes com mais de 128 MiB.
**[Recursos]: **
+ [Limitações](data-tiering.md#data-tiering-prerequisites)
+ **[Ideal] **Os tipos de instância reservada oferecem suporte à hierarquização de dados. Isso garante o menor custo em termos de quantidade de armazenamento de dados por instância.
1. Talvez seja necessário operar seus clusters do ElastiCache usando instâncias sem hierarquização de dados até ter uma melhor compreensão de seus requisitos.
1. Analise seu padrão de uso de dados de clusters do ElastiCache.
1. Crie um trabalho automatizado que colete periodicamente o tempo ocioso do objeto.
1. Se você perceber que uma grande porcentagem (cerca de 80%) dos objetos fica ociosa por um período considerado apropriado para sua workload, documente as descobertas e sugira a migração do cluster para instâncias compatíveis com a hierarquização de dados.
1. Avalie regularmente os novos tipos de nó de cache disponíveis e avalie se faz sentido, do ponto de vista das métricas de operação e custo, migrar sua frota de instâncias para novos tipos de nó de cache.
**[Recursos]: **
+ [OBJECT IDLETIME](https://valkey.io/commands/object-idletime/)
+ [Preço do Amazon ElastiCache](https://aws.amazon.com/elasticache/pricing/)
# Etapas comuns de solução de problemas e melhores práticas com ElastiCache
Os tópicos a seguir fornecem dicas de solução de problemas para erros e problemas que você pode encontrar ao usar ElastiCache. Se encontrar um problema que não esteja listado aqui, você poderá usar o botão de feedback desta página para relatá-lo.
Para obter mais orientações sobre solução de problemas e respostas a perguntas comuns de suporte, acesse a [Central de Conhecimento da AWS](https://aws.amazon.com/premiumsupport/knowledge-center/)
**Topics**
+ [Problemas de conexão](#wwe-troubleshooting.connection)
+ [Erros do cliente Valkey ou Redis OSS](#wwe-troubleshooting.clienterrors)
+ [Solução de problemas de alta latência no Serverless ElastiCache](#wwe-troubleshooting.latency)
+ [Solução de problemas de limitação no Serverless ElastiCache](#wwe-troubleshooting.throttling)
+ [Problemas de conexão persistentes](TroubleshootingConnections.md)
+ [Related Topics](#wwe-troubleshooting.related)
## Problemas de conexão
Se você não conseguir se conectar ao ElastiCache cache, considere uma das seguintes opções:
1. **Usando o TLS:** se você estiver com uma conexão interrompida ao tentar se conectar ao seu ElastiCache endpoint, talvez não esteja usando o TLS no seu cliente. Se você estiver usando o ElastiCache Serverless, a criptografia em trânsito estará sempre ativada. Certifique-se de que seu cliente esteja usando o TLS para se conectar ao cache. [Saiba mais sobre como se conectar a um cache habilitado para TLS](connect-tls.md).
1. **VPC:** ElastiCache os caches só podem ser acessados de dentro de uma VPC. Certifique-se de que a EC2 instância a partir da qual você está acessando o cache e o ElastiCache cache sejam criados na mesma VPC. Como alternativa, você deve ativar o [emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) entre a VPC em que sua instância EC2 reside e a VPC em que você está criando seu cache.
1. **Grupos de segurança:** ElastiCache usa grupos de segurança para controlar o acesso ao seu cache. Considere o seguinte:
1. Certifique-se de que o grupo de segurança usado pelo seu ElastiCache cache permita acesso de entrada a ele a partir da sua EC2 instância. Veja [aqui](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) para saber como configurar corretamente as regras de entrada em seu grupo de segurança.
1. Certifique-se de que o grupo de segurança usado pelo ElastiCache cache permita acesso às portas do cache (6379 e 6380 para clusters sem servidor e 6379 por padrão para clusters baseados em nós). ElastiCache usa essas portas para aceitar comandos Valkey ou Redis OSS. Saiba mais sobre como configurar o acesso à porta [aqui](set-up.md#elasticache-install-grant-access-VPN).
Se a conexão continuar sendo difícil, consulte [Problemas de conexão persistentes](TroubleshootingConnections.md) para outras etapas.
## Erros do cliente Valkey ou Redis OSS
ElastiCache O Serverless só pode ser acessado usando clientes que oferecem suporte ao protocolo de modo de cluster Valkey ou Redis OSS. Clusters baseados em nós podem ser acessados de clientes em qualquer um dos modos, dependendo da configuração do cluster.
Se você estiver enfrentando erros no seu cliente, considere o seguinte:
1. **Modo de cluster:** se você estiver enfrentando erros de CROSSLOT ou erros com o comando [SELECT](https://valkey.io/commands/select/), talvez esteja tentando acessar um cache habilitado para o modo de cluster com um cliente Valkey ou Redis OSS que não suporta o protocolo Cluster. ElastiCache O Serverless só oferece suporte a clientes que oferecem suporte ao protocolo de cluster Valkey ou Redis OSS. Se você quiser usar o Valkey ou Redis OSS no “Modo de cluster desabilitado” (CMD), será necessário criar um cluster baseado em nós.
1. **Erros de CROSSLOT: **Se você estiver enfrentando o erro `ERR CROSSLOT Keys in request don't hash to the same slot`, talvez esteja tentando acessar chaves que não pertencem ao mesmo slot em um cache do modo de cluster. Como lembrete, o ElastiCache Serverless sempre opera no Modo Cluster. Operações com várias chaves, transações ou scripts Lua envolvendo várias chaves são permitidos somente se todas as chaves envolvidas estiverem no mesmo slot de hash.
Para obter mais práticas recomendadas sobre a configuração de clientes Valkey ou Redis OSS, consulte esta [ postagem no blog](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/).
## Solução de problemas de alta latência no Serverless ElastiCache
Se sua carga de trabalho parecer estar com alta latência, você pode analisar as `SuccessfulWriteRequestLatency` métricas CloudWatch `SuccessfulReadRequestLatency` e para verificar se a latência está relacionada ao Serverless. ElastiCache Essas métricas medem a latência interna ao ElastiCache Serverless - a latência do lado do cliente e os tempos de viagem da rede entre seu cliente e o endpoint ElastiCache Serverless não estão incluídos.
**Solução de problemas de latência do lado do cliente**
Se você notar uma latência elevada no lado do cliente, mas nenhum aumento correspondente nas `` CloudWatch `SuccessfulReadRequestLatency` `SuccessfulWriteRequestLatency` métricas que medem a latência do lado do servidor, considere o seguinte:
+ **Verifique se o grupo de segurança permite acesso às portas 6379 e 6380:** o ElastiCache Serverless usa a porta 6379 para o endpoint primário e a porta 6380 para o endpoint do leitor. Alguns clientes estabelecem conectividade com as duas portas para cada nova conexão, mesmo que seu aplicativo não esteja usando o recurso Ler da réplica. Se o grupo de segurança não permitir acesso de entrada às duas portas, o estabelecimento da conexão poderá levar mais tempo. Saiba mais sobre como configurar o acesso à porta [aqui](set-up.md#elasticache-install-grant-access-VPN).
**Solução de problemas de latência do lado do servidor**
Alguma variabilidade e picos ocasionais não devem ser motivo de preocupação. No entanto, se a `Average` estatística mostrar um aumento acentuado e persistir, você deve verificar o Personal Health Dashboard Health Dashboard e o Personal Health Dashboard para obter mais informações. Se necessário, considere abrir um caso de suporte com Suporte.
Considere as seguintes práticas recomendadas e estratégias para reduzir a latência:
+ **Habilitar leitura da réplica: **se seu aplicativo permitir essa opção, recomendamos habilitar o recurso “Ler da réplica” em seu cliente Valkey ou Redis OSS para escalar as leituras e obter menor latência. Quando ativado, o ElastiCache Serverless tenta rotear suas solicitações de leitura para nós de cache de réplica que estão na mesma zona de disponibilidade (AZ) do seu cliente, evitando assim a latência de rede entre AZ. Observe que, ao ativar o recurso Ler da réplica em seu cliente, seu aplicativo aceitará uma eventual consistência nos dados. Seu aplicativo talvez receba dados mais antigos por algum tempo se você tentar ler depois de gravar em uma chave.
+ **Certifique-se de que seu aplicativo seja implantado da AZs mesma forma que seu cache:** você pode observar uma maior latência do lado do cliente se seu aplicativo não for implantado da AZs mesma forma que seu cache. Ao criar um cache sem servidor, você pode fornecer as sub-redes de onde seu aplicativo acessará o cache, e o Serverless ElastiCache cria VPC Endpoints nessas sub-redes. Certifique-se de que seu aplicativo seja implantado no mesmo AZs. Caso contrário, seu aplicativo poderá sofrer um salto entre AZ ao acessar o cache, resultando em maior latência do lado do cliente.
+ **Conexões de reutilização: as** solicitações ElastiCache sem servidor são feitas por meio de uma conexão TCP habilitada para TLS usando o protocolo RESP. Iniciar a conexão (incluindo a autenticação da conexão, se configurada) leva tempo, então a latência da primeira solicitação é maior que o normal. Solicitações em uma conexão já inicializada oferecem ElastiCache baixa latência consistente. Por esse motivo, você deve considerar o uso do pool de conexões ou a reutilização das conexões OSS Valkey ou Redis existentes.
+ **Velocidade de escalonamento:** o ElastiCache Serverless é escalado automaticamente à medida que sua taxa de solicitações aumenta. Um grande aumento repentino na taxa de solicitações, mais rápido do que a velocidade na qual o ElastiCache Serverless é escalado, pode resultar em latência elevada por algum tempo. ElastiCache Normalmente, o Serverless pode aumentar rapidamente a taxa de solicitações suportadas, levando de 10 a 12 minutos para dobrar a taxa de solicitações.
+ **Inspecione comandos de longa execução: **alguns comandos do Valkey ou do Redis OSS, incluindo scripts Lua ou comandos em grandes estruturas de dados, podem ser executados por muito tempo. Para identificar esses comandos, ElastiCache publica métricas de nível de comando. Com o [ElastiCache Serverless](serverless-metrics-events-redis.md#serverless-metrics), você pode usar as `BasedECPUs` métricas.
+ **Solicitações limitadas:** quando as solicitações são limitadas no ElastiCache Serverless, você pode experimentar um aumento na latência do lado do cliente em seu aplicativo. [Quando as solicitações são limitadas no ElastiCache Serverless, você deve ver um aumento na métrica Serverless. `ThrottledRequests` ElastiCache ](serverless-metrics-events-redis.md#serverless-metrics) Consulte a seção abaixo para solucionar problemas em solicitações com controle de utilização.
+ **Distribuição uniforme de chaves e solicitações:** no ElastiCache Valkey e no Redis OSS, uma distribuição desigual de chaves ou solicitações por slot pode resultar em um hot slot, o que pode resultar em latência elevada. ElastiCache O Serverless suporta até 30.000 ECPUs/second (90.000 ECPUs/second ao usar Read from Replica) em um único slot, em uma carga de trabalho que executa comandos simples. SET/GET Recomendamos avaliar a distribuição da chave e da solicitação em todos os slots e garantir uma distribuição uniforme se a taxa de solicitação exceder esse limite.
## Solução de problemas de limitação no Serverless ElastiCache
Em arquiteturas orientadas a serviços e sistemas distribuídos, a limitação da taxa na qual as chamadas de API são processadas por vários componentes do serviço é chamada de controle de utilização. Isso suaviza os picos, controla as incompatibilidades na produtividade dos componentes e permite recuperações mais previsíveis quando há um evento operacional inesperado. ElastiCache O Serverless foi projetado para esses tipos de arquiteturas, e a maioria dos clientes Valkey ou Redis OSS tem novas tentativas incorporadas para solicitações limitadas. Algum grau de controle de utilização não é necessariamente um problema para a aplicação, mas o controle de utilização persistente de uma parte sensível à latência do fluxo de trabalho de dados pode afetar negativamente a experiência do usuário e reduzir a eficiência geral do sistema.
[Quando as solicitações são limitadas no ElastiCache Serverless, você deve ver um aumento na métrica Serverless. `ThrottledRequests` ElastiCache ](serverless-metrics-events-redis.md#serverless-metrics) Se você está percebendo um grande número de solicitações com controle de utilização, considere o seguinte:
+ **Velocidade de escalabilidade:** o ElastiCache Serverless é escalado automaticamente à medida que você ingere mais dados ou aumenta sua taxa de solicitações. Se seu aplicativo for dimensionado mais rápido do que a velocidade com que o Serverless é escalado, suas solicitações podem ser limitadas, enquanto o ElastiCache Serverless é escalado para acomodar sua carga de trabalho. ElastiCache ElastiCache Normalmente, a tecnologia sem servidor pode aumentar o tamanho do armazenamento rapidamente, levando de 10 a 12 minutos para dobrar o tamanho do armazenamento em seu cache.
+ **Distribuição uniforme de chaves e solicitações:** no ElastiCache Valkey e no Redis OSS, uma distribuição desigual de chaves ou solicitações por slot pode resultar em um hot slot. Um hot slot pode resultar na limitação de solicitações, se a taxa de solicitações para um único slot exceder 30.000 ECPUs/second e estiver em uma carga de trabalho que executa comandos simples. SET/GET Da mesma forma, com ElastiCache o Memcached, uma tecla de atalho pode resultar na limitação de solicitações se a taxa de solicitação exceder 30.000 por segundo. ECPUs
+ **Ler da réplica: **se sua aplicação permitir, considere usar o recurso “Ler da réplica”. A maioria dos clientes Valkey ou Redis OSS pode ser configurada para “escalar leituras” para direcionar as leituras para os nós de réplica. Esse recurso permite que você escale o tráfego de leitura. Além disso, o ElastiCache Serverless encaminha automaticamente a leitura das solicitações de réplica para os nós na mesma zona de disponibilidade do seu aplicativo, resultando em menor latência. Quando a opção Ler da réplica está ativada, você pode alcançar até 90.000 ECPUs/second em um único slot, para cargas de trabalho com comandos simples. SET/GET
# Problemas de conexão persistentes
Os seguintes itens devem ser verificados ao solucionar problemas persistentes de conectividade com o ElastiCache:
**Topics**
+ [Grupos de segurança](#Security_groups)
+ [Network ACLs](#Network_ACLs)
+ [Tabelas de rotas](#Route_tables)
+ [Resolução do DNS](#DNS_Resolution)
+ [Identificação de problemas com o diagnóstico do lado do servidor](#Diagnostics)
+ [Validação da conectividade de rede](#Connectivity)
+ [Limites relacionados à rede](#Network-limits)
+ [Uso da CPU](#CPU-Usage)
+ [Conexões sendo encerradas do lado do servidor](#Connections-server)
+ [Solução de problemas no lado do cliente para instâncias do Amazon EC2](#Connections-client)
+ [Dissecação do tempo necessário para concluir uma única solicitação](#Dissecting-time)
## Grupos de segurança
Os grupos de segurança são firewalls virtuais que protegem o cliente do ElastiCache (instância do EC2, função AWS Lambda, contêiner do Amazon ECS etc.) e cache do ElastiCache. Os grupos de segurança têm estado, o que significa que depois que o tráfego de entrada ou saída é permitido, as respostas para esse tráfego serão automaticamente autorizadas no contexto desse grupo de segurança específico.
O recurso stateful (com estado) requer que o grupo de segurança mantenha o controle de todas as conexões autorizadas e há um limite para conexões controladas. Se o limite for atingido, as novas conexões apresentarão falha. Consulte a seção de solução de problemas para obter ajuda sobre como identificar se os limites foram atingidos do lado do cliente ou do ElastiCache.
Você pode ter um único grupo de segurança atribuído ao mesmo tempo ao cliente e ao cluster do ElastiCache, ou grupos de segurança individuais para cada um.
Em ambos os casos, você precisa permitir o tráfego de saída TCP na porta do ElastiCache da origem e o tráfego de entrada na mesma porta para o ElastiCache. A porta padrão é 11211 para Memcached e 6379 para Valkey ou Redis OSS. Por padrão, os grupos de segurança permitem todo o tráfego de saída. Nesse caso, somente a regra de entrada no grupo de segurança de destino é necessária.
Para obter mais informações, consulte [Padrões de acesso para acessar um cluster do ElastiCache em uma Amazon VPC](elasticache-vpc-accessing.md).
## Network ACLs
As listas de controle de acesso à rede (ACLs) são regras sem estado. O tráfego deve ser permitido em ambas as direções (entrada e saída) para ter êxito. As ACLs de rede são atribuídas a sub-redes, não a recursos específicos. É possível ter a mesma ACL atribuída ao ElastiCache e ao recurso do cliente, especialmente se eles estiverem na mesma sub-rede.
Por padrão, as ACLs de rede permitem todo o tráfego. No entanto, é possível personalizá-las para negar ou permitir tráfego. Além disso, a avaliação das regras da ACL é sequencial, o que significa que a regra com o menor número correspondente ao tráfego irá permiti-lo ou negá-lo. A configuração mínima para permitir o tráfego Valkey ou Redis OSS é:
ACL de rede do lado do cliente:
+ **Regras de entrada:**
+ Número da regra: preferencialmente inferior a qualquer regra de negação;
+ Type: Custom TCP Rule;
+ Protocolo: TCP
+ Port Range: 1024-65535
+ Source: 0.0.0.0/0 (ou criar regras individuais para as sub-redes do cluster do ElastiCache)
+ Allow/Deny: Allow
+ **Regras de saída:**
+ Número da regra: preferencialmente inferior a qualquer regra de negação;
+ Type: Custom TCP Rule;
+ Protocolo: TCP
+ Port Range: 6379
+ Source 0.0.0.0/0 (ou as sub-redes do cluster do ElastiCache. Tenha em mente que o uso de IPs específicos pode criar problemas em caso de failover ou escalabilidade do cluster)
+ Allow/Deny: Allow
ACL de rede do ElastiCache:
+ **Regras de entrada:**
+ Número da regra: preferencialmente inferior a qualquer regra de negação;
+ Type: Custom TCP Rule;
+ Protocolo: TCP
+ Port Range: 6379
+ Source: 0.0.0.0/0 (ou criar regras individuais para as sub-redes do cluster do ElastiCache)
+ Allow/Deny: Allow
+ **Regras de saída:**
+ Número da regra: preferencialmente inferior a qualquer regra de negação;
+ Type: Custom TCP Rule;
+ Protocolo: TCP
+ Port Range: 1024-65535
+ Source 0.0.0.0/0 (ou as sub-redes do cluster do ElastiCache. Tenha em mente que o uso de IPs específicos pode criar problemas em caso de failover ou escalabilidade do cluster)
+ Allow/Deny: Allow
Para obter mais informações, consulte [ACLs de rede](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html).
## Tabelas de rotas
Da mesma forma que as ACLs de rede, cada sub-rede pode ter tabelas de rota diferentes. Se os clientes e o cluster do ElastiCache estiverem em sub-redes diferentes, certifique-se de que suas tabelas de rota permitam que eles cheguem uns aos outros.
Ambientes mais complexos, envolvendo várias VPCs, roteamento dinâmico ou firewalls de rede, podem se tornar difíceis para a solução de problemas. Consulte [Validação da conectividade de rede](#Connectivity) para confirmar se as configurações de rede são apropriadas.
## Resolução do DNS
O ElastiCache fornece os endpoints de serviço com base em nomes do DNS. Os endpoints disponíveis são os endpoints `Configuration`, `Primary`, `Reader`, e `Node`. Para obter mais informações, consulte [Encontrar endpoints de conexão](Endpoints.md).
Em caso de failover ou modificação de cluster, o endereço associado ao nome do endpoint pode mudar e será atualizado automaticamente.
Configurações de DNS personalizadas (ou seja, não usando o serviço de DNS da VPC) podem não estar cientes dos nomes de DNS fornecidos pelo ElastiCache. Certifique-se de que seu sistema possa resolver com êxito os endpoints do ElastiCache usando ferramentas do sistema como o `dig` (como mostrado a seguir) ou o `nslookup`.
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4
```
Você também pode forçar a resolução de nomes por meio do serviço de DNS da 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
```
## Identificação de problemas com o diagnóstico do lado do servidor
As métricas do CloudWatch e as informações de tempo de execução do mecanismo ElastiCache são fontes ou informações comuns para identificar potenciais fontes de problemas de conexão. Uma boa análise geralmente começa com os seguintes itens:
+ Uso da CPU: Valkey e Redis OSS são aplicativos multithread. No entanto, a execução de cada comando ocorre em um único thread (principal). Por esse motivo, o ElastiCache fornece as métricas `CPUUtilization` e `EngineCPUUtilization`. `EngineCPUUtilization` fornece a utilização da CPU dedicada ao processo do Valkey ou Redis OSS, e `CPUUtilization`, o uso em todas as vCPUs. Os nós com mais de uma vCPU geralmente têm valores diferentes para `CPUUtilization` e `EngineCPUUtilization`, sendo o segundo comumente maior. Um `EngineCPUUtilization` alto pode ser causado por um número elevado de solicitações ou operações complexas que levem uma quantidade significativa de tempo da CPU para ser concluída. Você pode identificar ambos com o seguinte:
+ Número elevado de solicitações: verifique se há aumentos em outras métricas que correspondam ao padrão `EngineCPUUtilization`. As métricas úteis são:
+ `CacheHits` e `CacheMisses`: o número de solicitações ou solicitações bem-sucedidas que não encontraram um item válido no cache. Se a proporção de erros em comparação com acertos for alta, a aplicação está desperdiçando tempo e recursos com solicitações infrutíferas.
+ `SetTypeCmds` e `GetTypeCmds`:eEssas métricas correlacionadas com `EngineCPUUtilization` podem ajudar a entender se a carga é significativamente maior para solicitações de gravação, medida por `SetTypeCmds`, ou leituras, medido por `GetTypeCmds`. Se a carga for predominantemente de leituras, o uso de várias réplicas de leitura pode equilibrar as solicitações em vários nós e poupar o primário para gravações. Em clusters com modo cluster desabilitado, o uso de réplicas de leitura pode ser feito criando uma configuração de conexão adicional na aplicação usando o endpoint leitor do ElastiCache. Para obter mais informações, consulte [Encontrar endpoints de conexão](Endpoints.md). As operações de leitura devem ser enviadas para essa conexão adicional. As operações de gravação serão feitas através do endpoint primário regular. No modo cluster habilitado, é aconselhável usar uma biblioteca com suporte a réplicas de leitura nativamente. Com os sinalizadores certos, a biblioteca será capaz de descobrir automaticamente a topologia do cluster, os nós de réplica, habilitar as operações de leitura através do comando [READONLY](https://valkey.io/commands/readonly) do Valkey Redis OSS e enviar as solicitações de leitura para as réplicas.
+ Número elevado de conexões:
+ `CurrConnections` e `NewConnections`: `CurrConnection` é o número de conexões estabelecidas no momento da coleta de pontos de dados, enquanto `NewConnections` mostra quantas conexões foram criadas no período.
Criar e manipular conexões implica em sobrecarga significativa da CPU. Além disso, o handshake de três vias de TCP necessário para criar novas conexões afetará negativamente os tempos de resposta gerais.
Um nó do ElastiCache com milhares de `NewConnections` por minuto indica que uma conexão é criada e usada por apenas alguns comandos, o que não é ideal. Manter as conexões estabelecidas e reutilizá-las para novas operações é uma prática recomendada. Isso é possível quando a aplicação cliente oferece suporte e implementa corretamente o grupo de conexões ou as conexões persistentes. Com o grupo de conexões, o número de `currConnections` não tem grandes variações, e o `NewConnections` deve ser o mais baixo possível. Valkey e Redis OSS oferecem desempenho ideal com um pequeno número de currConnections. Manter currConnection na ordem de dezenas ou centenas minimiza o uso de recursos para suportar conexões individuais, como buffers de cliente e ciclos de CPU para servir a conexão.
+ Throughput da rede
+ Determine a largura de banda: os nós do ElastiCache têm largura de banda proporcional ao tamanho do nó. Como as aplicações têm características diferentes, os resultados podem variar de acordo com a workload. Como exemplos, aplicações com alta taxa de pequenas solicitações tendem a afetar mais o uso da CPU do que o throughput da rede, enquanto chaves maiores causarão maior utilização da rede. Por esse motivo, é aconselhável testar os nós com a workload real para uma melhor compreensão dos limites.
A simulação da carga da aplicação forneceria resultados mais precisos. No entanto, as ferramentas de benchmark podem dar uma boa ideia dos limites.
+ Para casos em que as solicitações são predominantemente leituras, o uso de réplicas para operações de leitura aliviará a carga no nó primário. Se o caso de uso for predominantemente gravações, o uso de muitas réplicas amplificará o uso da rede. Para cada byte gravado no nó primário, N bytes serão enviados para as réplicas, sendo N o número de réplicas. A prática recomendada para workloads intensas de gravação é usar o ElastiCache para Redis OSS com modo cluster habilitado para que as gravações possam ser balanceadas em vários fragmentos ou haver aumento de escala vertical para um tipo de nó com mais recursos de rede.
+ As métricas `NetworkBytesIn` e `NetworkBytesOut` do Cloudwatch fornecem a quantidade de dados que entram ou saem do nó, respectivamente. `ReplicationBytes` é o tráfego dedicado à replicação de dados.
Para obter mais informações, consulte [Limites relacionados à rede](#Network-limits).
+ Comandos complexos: os comandos do Redis OSS são servidos em um único thread, o que significa que as solicitações são atendidas sequencialmente. Um único comando lento pode afetar outras solicitações e conexões, culminando em tempos limite. O uso de comandos que atuem sobre vários valores, chaves ou tipos de dados deve ser feito com cuidado. As conexões podem ser bloqueadas ou terminadas dependendo do número de parâmetros ou do tamanho de seus valores de entrada ou saída.
Um exemplo notório é o comando `KEYS`. Ele varre todo o keyspace procurando por um determinado padrão e bloqueia a execução de outros comandos durante sua execução. O Redis OSS usa a notação "Big O" para descrever sua complexidade de comandos.
O comando Keys tem complexidade de tempo O(N), sendo N o número de chaves no banco de dados. Portanto, quanto maior o número de chaves, mais lento será o comando. `KEYS` pode causar problemas de maneiras diferentes: se nenhum padrão de pesquisa for usado, o comando retornará todos os nomes de chaves disponíveis. Em bancos de dados com milhares ou milhões de itens, uma enorme saída será criada e inundará os buffers de rede.
Se um padrão de pesquisa for usado, somente as chaves correspondentes ao padrão retornarão ao cliente. No entanto, o mecanismo ainda varrerá todo o keyspace procurando por ele, e o tempo para concluir o comando será o mesmo.
Uma alternativa a `KEYS` é o comando `SCAN`. Ele itera sobre o keyspace e limita as iterações em um número específico de itens, evitando bloqueios prolongados no mecanismo.
A varredura tem o parâmetro `COUNT`, usado para definir o tamanho dos blocos de iteração. O valor padrão é 10 (10 itens por iteração).
Dependendo do número de itens no banco de dados, blocos com pequenos valores de `COUNT` irão exigir mais iterações para concluir uma verificação completa, e valores maiores manterão o mecanismo ocupado por mais tempo em cada iteração. Enquanto pequenos valores de contagem farão `SCAN` mais lento em grandes bancos de dados, valores maiores podem causar os mesmos problemas mencionados para `KEYS`.
Como exemplo, a execução do comando `SCAN` com valor de contagem de 10 vai requer 100.000 repetições em um banco de dados com 1 milhão de chaves. Se o tempo médio de ida e volta da rede for de 0,5 milissegundos, aproximadamente 50.000 milissegundos (50 segundos) serão gastos transferindo solicitações.
Por outro lado, se o valor da contagem fosse 100.000, uma única iteração seria necessária e apenas 0,5 ms seriam gastos transferindo-a. No entanto, o mecanismo seria totalmente bloqueado para outras operações até que o comando terminasse de varrer todo o keyspace.
Além de `KEYS`, vários outros comandos são potencialmente prejudiciais se não forem usados corretamente. Para ver uma lista de todos os comandos e suas respectivas complexidades de tempo, acesse [Comandos Valkey e Redis OSS](https://valkey.io/commands).
Exemplos de possíveis problemas:
+ Scripts Lua: o Valkey e Redis OSS fornecem um interpretador Lua incorporado, permitindo a execução de scripts no lado do servidor. Os scripts Lua no Valkey e no Redis OSS são executados no nível do mecanismo e são atômicos por definição, o que significa que nenhum outro comando ou script terá execução permitida enquanto um script estiver em execução. Os scripts Lua fornecem a possibilidade de executar vários comandos, algoritmos de tomada de decisão, análise de dados e outros diretamente no mecanismo. Embora a atomicidade dos scripts e a chance de descarregar a aplicação sejam tentadoras, os scripts devem ser usados com cuidado e para pequenas operações. No ElastiCache, o tempo de execução dos scripts Lua é limitado a 5 segundos. Scripts que não forem gravados no keyspace serão encerrados automaticamente após o período de 5 segundos. Para evitar a corrupção de dados e inconsistências, o nó fará failover se a execução do script não tiver sido concluída em 5 segundos e tiver qualquer gravação durante sua execução. [Transações](https://valkey.io/topics/transactions) são a alternativa para garantir a consistência de múltiplas modificações de chaves relacionadas no Redis OSS. Uma transação permite a execução de um bloco de comandos, observando as chaves existentes para modificações. Se qualquer uma das chaves observadas mudar antes da conclusão da transação, todas as modificações serão descartadas.
+ Exclusão em massa de itens: o comando `DEL` aceita vários parâmetros, que são os nomes das chaves a serem excluídas. As operações de exclusão são síncronas e gastarão um tempo significativo da CPU se a lista de parâmetros for grande ou contiver uma grande lista, conjunto, conjunto ordenado ou hash (estruturas de dados contendo vários subitens). Em outras palavras, até mesmo a exclusão de uma única chave pode levar um tempo significativo se tiver muitos elementos. A alternativa a `DEL` é `UNLINK`, que é um comando assíncrono disponível desde o Redis OSS 4. `UNLINK` deve ter preferência sobre `DEL` sempre que possível. Começando no ElastiCache para Redis OSS 6x, o parâmetro `lazyfree-lazy-user-del` faz com que o parâmetro `DEL` se comporte como `UNLINK` quando habilitado. Para mais informações, consulte [Alterações de parâmetro do Redis OSS 6.0](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x).
+ Comandos que atuam sobre várias chaves: `DEL` foi mencionado anteriormente como um comando que aceita vários argumentos e seu tempo de execução será diretamente proporcional a isso. No entanto, o Redis OSS fornece muitos outros comandos que funcionam de forma semelhante. Como exemplos, `MSET` e `MGET` permitem a inserção ou recuperação de várias chaves de string ao mesmo tempo. Seu uso pode ser benéfico para reduzir a latência de rede inerente a vários comandos individuais `SET` ou `GET`. No entanto, uma extensa lista de parâmetros afetará o uso da CPU.
Embora a utilização da CPU por si só não seja a causa de problemas de conectividade, gastar muito tempo para processar um único ou poucos comandos através de várias chaves pode causar falha de outras solicitações e aumentar a utilização geral da CPU.
O número de chaves e seu tamanho afetarão a complexidade do comando e, consequentemente, o tempo de conclusão.
Outros exemplos de comandos que podem atuar sobre várias chaves: `HMGET`, `HMSET`, `MSETNX`, `PFCOUNT`, `PFMERGE`, `SDIFF`, `SDIFFSTORE`, `SINTER`, `SINTERSTORE`, `SUNION`, `SUNIONSTORE`, `TOUCH`, `ZDIFF`, `ZDIFFSTORE`, `ZINTER` ou `ZINTERSTORE`.
+ Comandos atuando sobre vários tipos de dados: o Redis OSS também fornece comandos que atuam em uma ou várias chaves, independentemente do tipo de dados. O ElastiCache para Redis OSS fornece a métrica `KeyBasedCmds` para monitorar esses comandos. Essa métrica soma a execução dos seguintes comandos no período selecionado:
+ Complexidade de O(N):
+ `KEYS`
+ O(1)
+ `EXISTS`
+ `OBJECT`
+ `PTTL`
+ `RANDOMKEY`
+ `TTL`
+ `TYPE`
+ `EXPIRE`
+ `EXPIREAT`
+ `MOVE`
+ `PERSIST`
+ `PEXPIRE`
+ `PEXPIREAT`
+ `UNLINK (O(N)` para recuperar memória. No entanto, a tarefa de recuperação de memória ocorre em um thread separado e não bloqueia o mecanismo
+ Diferentes tempos de complexidade dependendo do tipo de dados:
+ `DEL`
+ `DUMP`
+ `RENAME` é considerado um comando com complexidade O(1), mas executa `DEL` Internamente. O tempo de execução varia de acordo com o tamanho da chave renomeada.
+ `RENAMENX`
+ `RESTORE`
+ `SORT`
+ Hashes grandes: hash é um tipo de dado que permite uma única chave com vários subitens de valor-chave. Cada hash pode armazenar 4.294.967.295 itens e operações em hashes grandes podem se tornar caras. Da mesma forma que `KEYS`, hashes têm o comando `HKEYS` com complexidade de tempo O(N), N sendo o número de itens no hash. `HSCAN` deve ter preferência sobre `HKEYS` para evitar comandos de longa execução. `HDEL`, `HGETALL`, `HMGET`, `HMSET` e `HVALS` são comandos que devem ser usados com cautela em hashes grandes.
+ Outras estruturas grandes de dados: além de hashes, outras estruturas de dados podem ser intensas em CPU. Conjuntos, listas, conjuntos classificados e HyperLogLogs também podem levar um tempo significativo para serem manipulados, dependendo do tamanho e dos comandos usados. Para obter mais informações sobre esses comandos, consulte [Comandos Valkey e Redis OSS](https://valkey.io/commands).
## Validação da conectividade de rede
Depois de analisar as configurações de rede relacionadas à resolução de DNS, grupos de segurança, ACLs de rede e tabelas de rota, a conectividade pode ser validada com o VPC Reachability Analyzer e as ferramentas do sistema.
O Reachability Analyzer testará a conectividade de rede e confirmará se todos os requisitos e permissões estão satisfeitos. Para os testes abaixo, você precisará do ID da ENI (Identificação de interface de rede elástica) de um dos nós do ElastiCache disponíveis em sua VPC. É possível fazer isso da seguinte maneira:
1. Acesse [https://console.aws.amazon.com/ec2/v2/home?\$1NIC:](https://console.aws.amazon.com/ec2/v2/home?#NIC)
1. Filtre a lista de interfaces pelo nome do cluster do ElastiCache ou pelo endereço IP obtido das validações de DNS anteriormente.
1. Anote ou salve o ID da ENI. Se várias interfaces forem exibidas, revise a descrição para confirmar que elas pertencem ao cluster correto do ElastiCache e escolha uma delas.
1. Prossiga para a próxima etapa.
1. Crie um caminho de análise em [https://console.aws.amazon.com/vpc/home?\$1ReachabilityAnalyzer](https://console.aws.amazon.com/vpc/home?#ReachabilityAnalyzer) e escolha as seguintes opções:
+ **Source Type** (Tipo de origem): escolha **Instance** (Instância) se seu cliente ElastiCache for executado em uma instância do Amazon EC2, ou **Network Interface** (Interface de rede) se ele usar outro serviço, como o Amazon ECS AWS Fargate com rede awsvpc, AWS Lambda, etc.), e o respectivo ID de recurso (instância EC2 ou ID da ENI);
+ **Destination Type** (Tipo de destino): escolha **Network Interface** (Interface de rede) e selecione a **ElastiCache ENI** (ENI do ElastiCache) na lista.
+ **Destination port** (Porta de destino): especifique 6379 para o ElastiCache para Redis OSS ou 11211 para o ElastiCache para Memcached. Essas são as portas definidas com a configuração padrão e este exemplo pressupõe que elas não foram alteradas.
+ **Protocolo**: TCP
Crie o caminho de análise e aguarde alguns instantes para o resultado. Se o status estiver inacessível, abra os detalhes da análise e revise **Analysis Explorer** (Explorador da análise) para obter detalhes sobre onde as solicitações foram bloqueadas.
Se os testes de acessibilidade forem aprovados, avance para a verificação no nível do sistema operacional.
Para validar a conectividade de TCP na porta de serviço do ElastiCache: no Amazon Linux, `Nping` está disponível no pacote `nmap` e pode testar a conectividade de TCP na porta do ElastiCache, além de fornecer o tempo de ida e volta da rede para estabelecer a conexão. Use isso para validar a conectividade de rede e a latência atual para o cluster do ElastiCache, conforme mostrado a seguir:
```
$ 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
```
Por padrão,`nping` envia 5 testes com um atraso de 1 segundo entre eles. Você pode usar a opção "-c" para aumentar o número de testes e “--delay“ para alterar o tempo de envio de um novo teste.
Se os testes com `nping` falharem e os testes do *VPC Reachability Analyzer* forem aprovados, peça ao administrador do sistema para revisar possíveis regras de firewall baseadas em host, regras de roteamento assimétricas ou qualquer outra restrição possível no nível do sistema operacional.
No console do ElastiCache, verifique se **Encryption in-transit** (Criptografia em trânsito) está habilitada nos detalhes do cluster do ElastiCache. Se a criptografia em trânsito estiver habilitada, confirme se a sessão de TLS pode ser estabelecida com o seguinte comando:
```
openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379
```
Uma saída extensa é esperada se a conexão e a negociação de TLS forem bem-sucedidas. Verifique o código de retorno disponível na última linha, o valor deve ser de `0 (ok)`. Se o openssl retornar algo diferente, verifique o motivo do erro em [https://www.openssl.org/docs/man1.0.2/man1/verify.html\$1DIAGNOSTICS](https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS).
Se todos os testes de infraestrutura e sistema operacional forem aprovados, mas sua aplicação ainda não conseguir se conectar ao ElastiCache, verifique se as configurações da aplicação estão em conformidade com as configurações do ElastiCache. Erros comuns são:
+ Sua aplicação não suporta o modo de cluster do ElastiCache e o ElastiCache tem modo cluster habilitado;
+ Sua aplicação não oferece suporte a TLS/SSL e o ElastiCache possui criptografia em trânsito habilitada;
+ A aplicação suporta TLS/SSL, mas não possui os sinalizadores de configuração corretos ou autoridades de certificação confiáveis;
## Limites relacionados à rede
+ Número máximo de conexões: há limites rígidos para conexões simultâneas. Cada nó do ElastiCache permite até 65.000 conexões simultâneas em todos os clientes. Este limite pode ser monitorado através das métricas `CurrConnections` métricas no CloudWatch. No entanto, os clientes também têm seus limites para conexões de saída. No Linux, verifique o intervalo de portas efêmeras permitido com o comando:
```
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
```
No exemplo anterior, 28231 conexões serão permitidas da mesma origem, para o mesmo IP de destino (nó ElastiCache) e porta. O comando a seguir mostra quantas conexões existem para um nó do ElastiCache específico (IP 1.2.3.4):
```
ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l
```
Se o número for muito alto, seu sistema pode ficar sobrecarregado tentando processar as solicitações de conexão. É aconselhável considerar a implementação de técnicas como grupo de conexões ou conexões persistentes para lidar melhor com as conexões. Sempre que possível, configure o grupo de conexões para limitar o número máximo de conexões a algumas centenas. Além disso, a lógica de recuo para lidar com tempo limite ou outras exceções de conexão seria aconselhável para evitar rotatividade de conexão em caso de problemas.
+ Limites de tráfego de rede: verifique as seguintes [métricas do CloudWatch para o Redis OSS](CacheMetrics.Redis.md) para identificar possíveis limites de rede que estejam sendo atingidos no nó do ElastiCache:
+ `NetworkBandwidthInAllowanceExceeded`/`NetworkBandwidthOutAllowanceExceeded`: pacotes de rede modelados porque o throughput excedeu o limite de largura de banda agregada.
É importante observar que cada byte gravado no nó primário será replicado para N réplicas, sendo N o número de réplicas. Clusters com tipos de nó pequenos, várias réplicas e solicitações de gravação intensiva podem não conseguir lidar com o backlog de replicação. Nesses casos, é uma prática recomendada aumentar a escala vertical (alterar o tipo de nó), aumentar a escala horizontal (adicionar fragmentos em clusters com modo cluster habilitado), reduzir o número de réplicas ou minimizar o número de gravações.
+ `NetworkConntrackAllowanceExceeded`: pacotes modelados porque o número máximo de conexões monitoradas em todos os grupos de segurança atribuídos ao nó foi excedido. Novas conexões provavelmente falharão durante esse período.
+ `NetworkPackets PerSecondAllowanceExceeded`: número máximo de pacotes por segundo excedido. Workloads baseadas em uma alta taxa de solicitações muito pequenas podem atingir esse limite antes da largura de banda máxima.
As métricas acima são a maneira ideal de confirmar que os nós atingem seus limites de rede. No entanto, os limites também são identificáveis por platôs em métricas de rede.
Se os platôs forem observados por períodos prolongados, eles provavelmente serão seguidos por atraso de replicação, aumento de bytes usados para cache, queda de memória livre, alto swap e uso da CPU. As instâncias do Amazon EC2 também têm limites de rede que podem ser rastreados por meio de [Métricas do driver ENA](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html). Instâncias do Linux com suporte de rede aprimorado e drivers ENA 2.2.10 ou mais recentes podem revisar os contadores de limite com o comando:
```
# ethtool -S eth0 | grep "allowance_exceeded"
```
## Uso da CPU
A métrica de uso da CPU é o ponto de partida da investigação, e os seguintes itens podem ajudar a reduzir possíveis problemas no lado do ElastiCache:
+ SlowLogs do Redis OSS: a configuração padrão do ElastiCache retém os últimos 128 comandos que levaram mais de 10 milissegundos para serem concluídos. O histórico de comandos lentos é mantido durante o tempo de execução do mecanismo e será perdido em caso de falha ou reinicialização. Se a lista atingir 128 entradas, eventos antigos serão removidos para abrir espaço para novas entradas. O tamanho da lista de eventos lentos e o tempo de execução considerado lento podem ser modificados através dos parâmetros `slowlog-max-len` e `slowlog-log-slower-than` em um [grupo de parâmetros personalizado](ParameterGroups.md). A lista de logs lentos pode ser recuperada executando `SLOWLOG GET 128` no mecanismo, 128 sendo os últimos 128 comandos lentos relatados. Cada entrada tem os seguintes campos:
```
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
```
O evento acima aconteceu em 26 de dezembro, às 19:26:07 UTC, levou 4,8 segundos (4,823 ms) para ser concluído e foi causado pelo comando `KEYS` solicitado pelo cliente 1.2.3.4.
No Linux, o carimbo de data/hora pode ser convertido com a data do comando:
```
$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020
```
Com Python:
```
>>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)
```
Ou no Windows com a 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
```
Muitos comandos lentos em um curto período de tempo (mesmo minuto ou menos) são motivo de preocupação. Revise a natureza dos comandos e como eles podem ser otimizados (consulte exemplos anteriores). Se comandos com complexidade de tempo O(1) são frequentemente relatados, verifique os outros fatores para o alto uso da CPU mencionado anteriormente.
+ Métricas de latência: o ElastiCache para Redis OSS fornece métricas do CloudWatch para monitorar a latência média de diferentes classes de comandos. O ponto de dados é calculado dividindo o número total de execuções de comandos na categoria pelo tempo total de execução no período. É importante entender que os resultados da métrica de latência são um agregado de vários comandos. Um único comando pode causar resultados inesperados, como tempos limite, sem impacto significativo nas métricas. Para tais casos, os eventos de log lento seriam uma fonte de informação mais precisa. A lista a seguir contém as métricas de latência disponíveis e os respectivos comandos que as afetam.
+ EvalBasedCmdsLatency: relacionado a comandos de scripts Lua, `eval`, `evalsha`;
+ GeoSpatialBasedCmdsLatency: `geodist`, `geohash`, `geopos`, `georadius`, `georadiusbymember`, `geoadd`;
+ GetTypeCmdsLatency: comandos de leitura, independentemente do tipo de dados;
+ HashBasedCmdsLatency: `hexists`, `hget`, `hgetall`, `hkeys`, `hlen`, `hmget`, `hvals`, `hstrlen`, `hdel`, `hincrby`, `hincrbyfloat`, `hmset`, `hset`, `hsetnx`;
+ HyperLogLogBasedCmdsLatency: `pfselftest`, `pfcount`, `pfdebug`, `pfadd`, `pfmerge`;
+ KeyBasedCmdsLatency: comandos que podem atuar em diferentes tipos de dados: `dump`, `exists`, `keys`, `object`, `pttl`, `randomkey`, `ttl`, `type`, `del`, `expire`, `expireat`, `move`, `persist`, `pexpire`, `pexpireat`, `rename`, `renamenx`, `restoreK`, `sort`, `unlink`;
+ ListBasedCmdsLatency: lindex, llen, lrange, blpop, brpop, brpoplpush, linsert, lpop, lpush, lpushx, lrem, lset, ltrim, rpop, rpoplpush, rpush, rpushx;
+ PubSubBasedCmdsLatency: psubscribe, publish, pubsub, punsubscribe, subscribe, unsubscribe;
+ SetBasedCmdsLatency: `scard`, `sdiff`, `sinter`, `sismember`, `smembers`, `srandmember`, `sunion`, `sadd`, `sdiffstore`, `sinterstore`, `smove`, `spop`, `srem`, `sunionstore`;
+ SetTypeCmdsLatency: comandos de gravação, independentemente do tipo de dados;
+ 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`;
+ Comandos de runtime do Redis OSS:
+ info commandstats: fornece uma lista de comandos executados desde que o mecanismo foi iniciado, seu número de execuções cumulativas, tempo total de execução e tempo médio de execução por comando;
+ client list: fornece uma lista de clientes atualmente conectados e informações relevantes como o uso de buffers, último comando executado, etc.;
+ Backup e replicação: as versões do ElastiCache para Redis OSS anteriores à 2.8.22 usam um processo bifurcado para criar backups e processar sincronizações completas com as réplicas. Esse método pode incorrer em sobrecarga de memória significativa para casos de uso intensivo de gravação.
Começando com ElastiCache Redis OSS 2.8.22, a AWS introduziu um método de backup e replicação sem bifurcação. O novo método pode atrasar as gravações para evitar falhas. Ambos os métodos podem causar períodos de maior utilização da CPU, levar a tempos de resposta mais altos e, consequentemente, levar a estouro de limites de tempo do cliente durante a execução. Sempre verifique se as falhas do cliente acontecem durante a janela de backup ou a métrica `SaveInProgress` foi 1 no período. É aconselhável agendar a janela de backup para períodos de baixa utilização para minimizar a possibilidade de problemas com clientes ou falhas de backup.
## Conexões sendo encerradas do lado do servidor
A configuração padrão do ElastiCache para Redis OSS mantém as conexões do cliente estabelecidas indefinidamente. No entanto, em alguns casos, o encerramento da conexão pode ser desejável. Por exemplo:
+ Bugs na aplicação do cliente podem fazer com que as conexões sejam esquecidas e mantidas estabelecidas com um estado ocioso. Isso é chamado de "vazamento de conexão", e a conseqüência é um aumento constante no número de conexões estabelecidas observadas na métrica `CurrConnections`. Esse comportamento pode resultar em saturação no lado do cliente ou do ElastiCache. Quando uma correção imediata não é possível do lado do cliente, alguns administradores definem um valor de "tempo limite" em seu grupo de parâmetros do ElastiCache. O tempo limite é o tempo em segundos permitido para que as conexões ociosas persistam. Se o cliente não enviar qualquer solicitação no período, o mecanismo encerrará a conexão assim que a conexão atingir o valor de tempo limite. Pequenos valores de tempo limite podem resultar em desconexões desnecessárias e os clientes precisarão lidar com eles corretamente e reconectar, causando atrasos.
+ A memória usada para armazenar chaves é compartilhada com buffers do cliente. Clientes lentos com grandes solicitações ou respostas podem exigir uma quantidade significativa de memória para lidar com seus buffers. As configurações padrão do ElastiCache para Redis OSS não restringem o tamanho dos buffers de saída do cliente regulares. Se o limite `maxmemory` for atingido, o mecanismo tentará despejar itens para cumprir o uso do buffer. Em condições de memória extremamente baixa, o ElastiCache para Redis OSS pode optar por desconectar clientes que consumam grandes buffers de saída de cliente para liberar memória e reter a integridade do cluster.
É possível limitar o tamanho dos buffers do cliente com configurações personalizadas e os clientes que atingirem o limite serão desconectados. No entanto, os clientes devem ser capazes de lidar com desconexões inesperadas. Os parâmetros para lidar com o tamanho de buffers para clientes regulares são os seguintes:
+ cliente-query-buffer-limit: tamanho máximo de uma única solicitação de entrada;
+ client-output-buffer-limit-normal-soft-limit: limite flexível para conexões de clientes. A conexão será encerrada se permanecer acima do limite flexível por mais do que o tempo em segundos definido em client-output-buffer-limit-normal-soft-seconds ou se atingir o limite rígido;
+ client-output-buffer-limit-normal-soft-seconds: tempo permitido para as ligações que excedem o client-output-buffer-limit-normal-soft-limit;
+ client-output-buffer-limit-normal-hard-limit: uma conexão que atinge esse limite será imediatamente encerrada.
Além dos buffers de cliente regulares, as seguintes opções controlam o buffer para nós de réplica e clientes Pub/Sub (Publish/Subscribe):
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-replica-soft-seconds;
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-pubsub-soft-limit;
+ client-output-buffer-limit-pubsub-soft-seconds;
+ client-output-buffer-limit-pubsub-hard-limit;
## Solução de problemas no lado do cliente para instâncias do Amazon EC2
A carga e a capacidade de resposta no lado do cliente também podem afetar as solicitações ao ElastiCache. Os limites de instância e sistema operacional do EC2 precisam ser cuidadosamente revisados ao solucionar problemas de conectividade intermitente ou tempo limite. Alguns pontos-chave a observar:
+ CPU:
+ Uso da CPU da instância do EC2: verifique se a CPU não está saturada ou perto de 100%. A análise histórica pode ser feita via CloudWatch, no entanto, tenha em mente que a granularidade dos pontos de dados é de 1 minuto (com monitoramento detalhado ativado) ou 5 minutos;
+ Se estiver usando as [instâncias do EC2 com intermitência](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html), certifique-se de que o saldo de crédito da CPU não tenha se esgotado. Essas informações estão disponíveis na métrica `CPUCreditBalance` do CloudWatch
+ Períodos curtos de alto uso da CPU podem causar estouros de tempos limite sem refletir em 100% de utilização no CloudWatch. Tais casos exigem monitoramento em tempo real com ferramentas do sistema operacional como `top`, `ps` e `mpstat`.
+ Rede
+ Verifique se o throughput de rede está abaixo de valores aceitáveis de acordo com os recursos da instância. Para obter mais informações, consulte [Tipos de instâncias do Amazon EC2](https://aws.amazon.com/ec2/instance-types/)
+ Em instâncias com o Driver de rede aprimorado `ena`, verifique as [estatísticas do ena](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-ena.html#statistics-ena) sobre tempo limite ou limites excedidos. As estatísticas a seguir são úteis para confirmar a saturação de limites de rede:
+ `bw_in_allowance_exceeded` / `bw_out_allowance_exceeded`: número de pacotes modelados devido ao throughput excessivo de entrada ou saída;
+ `conntrack_allowance_exceeded`: número de pacotes descartados devido a [limites de monitoramento de conexão](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#connection-tracking-throttling) de grupos de segurança. Novas conexões falharão quando esse limite estiver saturado;
+ `linklocal_allowance_exceeded`: número de pacotes descartados devido a solicitações excessivas de metadados de instâncias, NTP via VPC DNS. O limite é de 1024 pacotes por segundo para todos os serviços;
+ `pps_allowance_exceeded`: número de pacotes descartados devido à proporção excessiva de pacotes por segundo. O limite de PPS pode ser atingido quando o tráfego de rede consistir em milhares ou milhões de solicitações muito pequenas por segundo. O tráfego do ElastiCache pode ser otimizado para fazer melhor uso de pacotes de rede por meio de pipelines ou comandos que façam várias operações ao mesmo tempo, como `MGET` em vez de `GET`.
## Dissecação do tempo necessário para concluir uma única solicitação
+ Na rede: `Tcpdump` e `Wireshark` (tshark na linha de comando) são ferramentas úteis para entender quanto tempo a solicitação levou para viajar pela rede, bater no mecanismo do ElastiCache e obter um retorno. O exemplo a seguir destaca uma única solicitação criada com o seguinte comando:
```
$ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG
```
Paralelamente ao comando acima, tcpdump estava em execução e retornou:
```
$ 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
```
A partir da saída acima, podemos confirmar que o handshake de três vias do TCP foi concluído em 222 microssegundos (918091 - 917869) e o comando ping foi enviado e retornado em 173 microssegundos (918295 - 918122).
Demorou 438 microssegundos (918307 - 917869) da solicitação ao fechamento da conexão. Esses resultados confirmam que os tempos de resposta da rede e do mecanismo são bons e que a investigação pode concentrar-se em outros componentes.
+ No sistema operacional: `Strace` pode ajudar a identificar intervalos de tempo no nível do sistema operacional. A análise de aplicações reais seria muito mais extensa, e profilers ou depuradores especializados de aplicações são aconselhados. O exemplo a seguir mostra apenas se os componentes básicos do sistema operacional estão funcionando como esperado, caso contrário, investigações adicionais podem ser necessárias. Usando do mesmo comando `PING` do Redis OSS com `strace`, obtemos:
```
$ 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 +++
```
No exemplo acima, o comando levou um pouco mais de 54 milissegundos para ser concluído (752110 - 697712 = 54398 microssegundos).
Um tempo significativo, aproximadamente 20 ms, foi levado para instanciar nc e fazer a resolução do nome (de 697712 a 717890), depois disso, 2ms foram necessários para criar o soquete de TCP (745659 a 747858), e 0,4 ms (747858 a 748330) para enviar e receber a resposta para a solicitação.
## Related Topics
+ [Práticas recomendadas e estratégias de armazenamento em cache do ElastiCache](BestPractices.md)