Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Descripción de cómo replicar en MemoryDB MemoryDB implementa la reproducción con datos particionados en hasta 500 particiones. Cada partición de un clúster tiene un nodo principal de lectura/escritura y hasta 5 nodos de réplica de solo lectura. Cada nodo principal puede soportar hasta 100 MB/s. Puede crear un clúster con un mayor número de particiones y un menor número de réplicas con un total de hasta 500 nodos por clúster. Esta configuración de clúster puede variar desde 500 particiones y 0 réplicas hasta 100 particiones y 4 réplicas, que es el número máximo de réplicas permitido. # Coherencia En MemoryDB, los nodos principales son muy consistentes. Las operaciones de escritura correctas se almacenan de forma duradera en registros transaccionales distribuidos en zonas de disponibilidad múltiples (Multi-AZ) antes de devolverlas a los clientes. Las operaciones de lectura en los archivos primarios siempre devuelven los datos más actualizados, lo que refleja los efectos de todas las operaciones de escritura anteriores que se realizaron correctamente. Esta sólida coherencia se mantiene en todas las conmutaciones por error principales. En MemoryDB, los nodos de réplica son eventualmente consistentes. Es posible que las operaciones de lectura de réplicas (mediante comandos de `READONLY`) no siempre reflejen los efectos de las operaciones de escritura más recientes que se realizaron correctamente, ya que las métricas de retardo se publican en CloudWatch. Sin embargo, las operaciones de lectura de una única réplica son coherentes secuencialmente. Las operaciones de escritura correctas tienen efecto en cada réplica en el mismo orden en que se ejecutaron en la principal. ## Replicación en un clúster Cada réplica de lectura de una partición mantiene una copia de los datos del nodo principal de la partición. Se utilizan mecanismos de replicación asíncronos mediante registros de transacciones para mantener las réplicas de lectura sincronizadas con el principal. Las aplicaciones pueden leer de cualquier nodos del clúster. Las aplicaciones pueden escribir únicamente en los nodos. Las réplicas de lectura mejoran la escalabilidad de lectura. Como MemoryDB almacena los datos en registros de transacciones duraderos, no hay riesgo de que los datos se pierdan. Los datos están particionados en las distintas particiones del clúster de MemoryDB. Las aplicaciones utilizan el *punto de conexión del clúster* de MemoryDB para conectarse a los nodos del clúster. Para obtener más información, consulte [Búsqueda de puntos de conexión](endpoints.md). Los clústeres de MemoryDB son regionales y solo pueden contener nodos de una región. Para mejorar la tolerancia a errores, puede aprovisionar tanto los principales como las réplicas de lectura en varias zonas de disponibilidad dentro de esa región. Se recomienda encarecidamente utilizar la replicación, que proporciona Multi-AZ, para todos los clústeres de MemoryDB. Para obtener más información, consulte [Minimización del tiempo de inactividad en MemoryDB con Multi-AZ](autofailover.md). # Minimización del tiempo de inactividad en MemoryDB con Multi-AZ Hay varias situaciones en las que MemoryDB puede necesitar reemplazar un nodo principal. Entre ellas se incluyen determinados tipos de mantenimiento planificado y el caso poco probable de que se produzca un error en el nodo principal o en la zona de disponibilidad. La respuesta al fallo del nodo depende del nodo que haya fallado. Sin embargo, en todos los casos, MemoryDB garantiza que no se pierdan datos durante la sustitución de nodos o la conmutación por error. Por ejemplo, si una réplica falla, el nodo fallido se reemplaza y los datos se sincronizan desde el registro de transacciones. Si el nodo principal falla, se desencadena una conmutación por error a una réplica coherente, lo que garantiza que no se pierdan datos durante la conmutación por error. Las escrituras ahora se realizan desde el nuevo nodo principal. A continuación, el nodo principal anterior se reemplaza y se sincroniza desde el registro de transacciones. Si un nodo principal falla en una partición de un solo nodo (sin réplicas), MemoryDB deja de aceptar escrituras hasta que se sustituya el nodo principal y se sincronice desde el registro de transacciones. El reemplazo de un nodo produce un tiempo de inactividad para el clúster, pero si Multi-AZ se encuentra activo, el tiempo de inactividad es mínimo. El rol del nodo principal tendrá una conmutación por error automática en una de las réplicas. No es necesario crear ni aprovisionar un nodo principal nuevo, ya que MemoryDB se encargará de esto de forma clara. Esta conmutación por error y promoción de réplica garantizan la posibilidad de reanudar la escritura en la réplica principal tan pronto como se complete la promoción. En caso de que se inicien sustituciones de nodos planeadas debido a actualizaciones de mantenimiento o actualizaciones de servicio, tenga en cuenta que las sustituciones de nodos planeadas se completan mientras el clúster atiende las solicitudes de escritura entrantes. Las zonas de disponibilidad múltiples en los clústeres de MemoryDB mejoran la tolerancia a los errores. Esto es cierto especialmente en los casos en que el nodo principal del clúster deja de estar accesible o de funcionar por cualquier motivo. La función Multi-AZ en los clústeres de MemoryDB requiere que cada partición tenga más de un nodo y se habilita automáticamente. **Topics** + [Escenarios de error con respuestas de Multi-AZ](#autofailover.scenarios) + [Prueba de la conmutación por error automática](#auto-failover-test) ## Escenarios de error con respuestas de Multi-AZ Si Multi-AZ está activo, un nodo principal que produce error conmuta por error a una réplica disponible. La réplica se sincroniza automáticamente con el registro de transacciones y pasa a ser principal, lo que es mucho más rápido que crear y volver a aprovisionar un nodo principal nuevo. Este proceso suele tardar tan solo unos segundos hasta que se puede escribir de nuevo en el clúster. Cuando Multi-AZ está activo, MemoryDB monitorea continuamente el estado del nodo principal. Si se produce un error en el nodo principal, se realiza una de las siguientes acciones en función del tipo de error. **Topics** + [Escenarios de error cuando solo se produce un error en el nodo principal](#autofailover.scenarios.primaryonly) + [Escenarios de error cuando el nodo principal y algunas réplicas producen un error](#autofailover.scenarios.primaryandeplicas) + [Escenarios de error cuando se produce un error en todo el clúster](#autofailover.scenarios.allfail) ### Escenarios de error cuando solo se produce un error en el nodo principal Si solo se produce un error en el nodo principal, la réplica se convertirá automáticamente en principal. A continuación, se crea una réplica de reemplazo y se aprovisiona en la misma zona de disponibilidad que el principal ha producido un error. Cuando solo se produce un error en el nodo principal, Multi-AZ de MemoryDB hace lo siguiente: 1. El nodo principal con error se desconecta (sin conexión). 1. Una up-to-date réplica se convierte automáticamente en principal. Las operaciones de escritura se pueden reanudar tan pronto como se haya completado el proceso de conmutación por error, por lo general, en tan solo unos segundos. 1. Una réplica de reemplazo se lanza y aprovisiona. La réplica de reemplazo se lanza en la zona de disponibilidad en la que estaba el nodo principal con error, por lo que se mantiene la distribución de los nodos. 1. La réplica se sincroniza con el registro de transacciones. Para obtener información acerca de la búsqueda de los puntos de conexión de un clúster, consulte los temas siguientes: + [Búsqueda del punto de conexión para un clúster de MemoryDB (API de MemoryDB)](endpoints.md#endpoints.find.api.clusters)   ### Escenarios de error cuando el nodo principal y algunas réplicas producen un error Si la réplica principal y al menos una de ellas fallan, la up-to-date réplica pasa a ser un clúster principal. Las nuevas réplicas también se crean y se aprovisionan en las mismas zonas de disponibilidad que las de los nodos con error. Cuando el nodo principal y algunas réplicas producen un error, Multi-AZ de MemoryDB hace lo siguiente: 1. El nodo principal y las réplicas con error se desconectan. 1. Una réplica disponible se convertirá en el nodo principal. Las operaciones de escritura se pueden reanudar en cuanto se haya completado el proceso de conmutación por error, por lo general, en tan solo unos segundos. 1. Las réplicas de reemplazo se crean y se aprovisionan. Las réplicas de reemplazo se crean en las zonas de disponibilidad de los nodos con error para, de este modo, conservar la distribución de los nodos. 1. Todos los nodos se sincronizan con el registro de transacciones. Para obtener información acerca de la búsqueda de los puntos de conexión de un clúster, consulte los temas siguientes: + [Búsqueda del punto de conexión para un clúster de MemoryDB (CLI de AWS)](endpoints.md#endpoints.find.cli) + [Búsqueda del punto de conexión para un clúster de MemoryDB (API de MemoryDB)](endpoints.md#endpoints.find.api.clusters)   ### Escenarios de error cuando se produce un error en todo el clúster Si el error es general, todos los nodos se volverán a crear y a aprovisionar en las mismas zonas de disponibilidad que las de los nodos originales. No hay pérdida de datos en este escenario, ya que los datos se conservaban en el registro de transacciones. Cuando se produce un error en todo el clúster, Multi-AZ de MemoryDB hace lo siguiente: 1. El nodo principal y las réplicas se desconectan. 1. Se crea y aprovisiona un nodo principal de reemplazo, que se sincroniza con el registro de transacciones. 1. Se crean y aprovisionan réplicas de reemplazo, sincronizándolas con el registro de transacciones. Los reemplazos se crean en las zonas de disponibilidad de los nodos con error para, de este modo, conservar la distribución de los nodos. Para obtener información acerca de la búsqueda de los puntos de conexión de un clúster, consulte los temas siguientes: + [Búsqueda del punto de conexión para un clúster de MemoryDB (CLI de AWS)](endpoints.md#endpoints.find.cli) + [Búsqueda del punto de conexión para un clúster de MemoryDB (API de MemoryDB)](endpoints.md#endpoints.find.api.clusters) ## Prueba de la conmutación por error automática Puede probar la conmutación por error automática mediante la consola de MemoryDB, la AWS CLI y la API de MemoryDB. Cuando realice las pruebas, tenga en cuenta lo siguiente: + Puede utilizar esta operación hasta cinco veces en un periodo de 24 horas. + Si realiza una llamada a esta operación en particiones de distintos clústeres, puede realizar las llamadas de forma simultánea. + En algunos casos, es posible llamar a esta operación varias veces en particiones diferentes del mismo clúster de MemoryDB. En tales casos, la sustitución del primer nodo debe completarse antes de que se pueda realizar una llamada posterior. + Para determinar si la sustitución del nodo se ha completado, compruebe los eventos mediante la consola MemoryDB AWS CLI, la o la API MemoryDB. Busque los siguientes eventos relacionados con `FailoverShard`, que se indican a continuación por orden de incidencia: 1. mensaje de clúster: `FailoverShard API called for shard ` 1. mensaje de clúster: `Failover from primary node to replica node completed` 1. mensaje de clúster: `Recovering nodes ` 1. mensaje de clúster: `Finished recovery for nodes ` Para obtener más información, consulte los siguientes temas: + [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)*en la referencia de la API de MemoryDB* + Esta API se ha diseñado para probar el comportamiento de la aplicación en caso de conmutación por error de MemoryDB. No está diseñado para ser una herramienta operativa para iniciar una conmutación por error para solucionar un problema con el clúster. Además, en determinadas condiciones, como eventos operativos a gran escala, AWS puede bloquear esta API. **Topics** + [Probar la conmutación por error automática mediante el Consola de administración de AWS](#auto-failover-test-con) + [Probar la conmutación por error automática mediante el AWS CLI](#auto-failover-test-cli) + [Prueba de la conmutación por error automática mediante la API de MemoryDB](#failovershard-test-api) ### Probar la conmutación por error automática mediante el Consola de administración de AWS Utilice el procedimiento siguiente para probar la conmutación por error automática con la consola. **** 1. Inicie sesión en la consola de MemoryDB Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) 1. Seleccione el botón de opción situado a la izquierda al clúster que desea probar. Este clúster debe tener al menos un nodo de réplica. 1. En el área **Details**, asegúrese de que este clúster tiene habilitadas Multi-AZ. Si el clúster no tiene habilitado Multi-AZ, elija un clúster distinto o modifique este clúster para habilitar Multi-AZ. Para obtener más información, consulte [Modificación de un clúster de MemoryDB](clusters.modify.md). 1. Elija el nombre del clúster. 1. En la página **Particiones y nodos**, elija el nombre de la partición en la que desea probar la conmutación por error. 1. Para el nodo, elija **Realizar conmutación por error del nodo principal**. 1. Elija **Continue** para realizar la conmutación por error al nodo principal, o bien **Cancel** para cancelar la operación y no realizar la conmutación por error al nodo principal. Durante el proceso de conmutación por error, la consola seguirá mostrando el estado del nodo como *disponible*. Para realizar un seguimiento del progreso de la prueba de la conmutación por error, elija **Events** en el panel de navegación de la consola. En la pestaña **Eventos**, consulte los eventos que indican que la conmutación por error se ha iniciado (`FailoverShard API called`) y completado (`Recovery completed`).   ### Probar la conmutación por error automática mediante el AWS CLI [Puede probar la conmutación por error automática en cualquier clúster habilitado para zonas de disponibilidad múltiples mediante la partición de conmutación por error de AWS CLI operación.](https://docs.aws.amazon.com/cli/latest/reference/memorydb/failover-shard.html) **Parameters** + `--cluster-name`: obligatorio. El clúster que se va a probar. + `--shard-name`: obligatorio. Nombre de la partición en la que desea probar la conmutación por error automática. Puede probar un máximo de cinco particiones en un periodo de 24 horas. En el siguiente ejemplo, se utiliza AWS CLI para llamar a la partición del clúster `failover-shard` de MemoryDB. `0001` `my-cluster` Para Linux, macOS o Unix: ``` aws memorydb failover-shard \ --cluster-name my-cluster \ --shard-name 0001 ``` Para Windows: ``` aws memorydb failover-shard ^ --cluster-name my-cluster ^ --shard-name 0001 ``` Para realizar un seguimiento del progreso de la conmutación por error, utilice la operación. AWS CLI `describe-events` Devuelve la siguiente respuesta JSON: ``` { "Events": [ { "SourceName": "my-cluster", "SourceType": "cluster", "Message": "Failover to replica node my-cluster-0001-002 completed", "Date": "2021-08-22T12:39:37.568000-07:00" }, { "SourceName": "my-cluster", "SourceType": "cluster", "Message": "Starting failover for shard 0001", "Date": "2021-08-22T12:39:10.173000-07:00" } ] } ``` Para obtener más información, consulte los siguientes temas: + [failover-shard](https://docs.aws.amazon.com/cli/latest/reference/memorydb/failover-shard.html) + [describe-events](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html)   ### Prueba de la conmutación por error automática mediante la API de MemoryDB En el siguiente ejemplo, se realiza una llamada a `FailoverShard` en la partición `0003` del clúster `memorydb00`. **Example Prueba de la conmutación por error automática** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=FailoverShard &ShardName=0003 &ClusterName=memorydb00 &Version=2021-01-01 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20210801T192317Z &X-Amz-Credential= ``` Para realizar un seguimiento del progreso de la conmutación por error, use la operación `DescribeEvents` de la API de MemoryDB. Para obtener más información, consulte los siguientes temas: + [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html) + [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html) # Cambio del número de réplicas Puede aumentar o disminuir dinámicamente el número de réplicas de lectura del clúster de MemoryDB mediante la Consola de administración de AWS, la AWS CLI o la API de MemoryDB. Todas las particiones deben tener el mismo número de réplicas. ## Aumento del número de réplicas de un clúster Puede aumentar el número de réplicas de un clúster de MemoryDB hasta un máximo de cinco por partición. Para ello, utilice la Consola de administración de AWS, la AWS CLI o la API de MemoryDB. **Topics** + [Uso de Consola de administración de AWS](#increase-replica-count-con) + [Uso de AWS CLI](#increase-replica-count-cli) + [Uso de la API de MemoryDB](#increase-replica-count-api) ### Uso de Consola de administración de AWS Para aumentar el número de réplicas en un clúster de MemoryDB (consola), consulte [Agregar/eliminar nodos de un clúster](clusters.deletenode.md). ### Uso de AWS CLI Para aumentar el número de réplicas de un clúster de MemoryDB, utilice el comando `update-cluster` con los parámetros siguientes: + `--cluster-name`: obligatorio. Identifica el clúster en el que desea aumentar el número de réplicas. + `--replica-configuration`: obligatorio. Le permite establecer el número de réplicas. Para aumentar el número de réplicas, establezca la propiedad `ReplicaCount` en el número de réplicas que desea incluir en la partición al final de la operación. **Example** En el siguiente ejemplo, se aumenta el número de réplicas del clúster `my-cluster` a 2. Para Linux, macOS o Unix: ``` aws memorydb update-cluster \ --cluster-name my-cluster \ --replica-configuration \ ReplicaCount=2 ``` Para Windows: ``` aws memorydb update-cluster ^ --cluster-name my-cluster ^ --replica-configuration ^ ReplicaCount=2 ``` Devuelve la siguiente respuesta JSON: ``` { "Cluster": { "Name": "my-cluster", "Status": "updating", "NumberOfShards": 1, "ClusterEndpoint": { "Address": "clustercfg.my-cluster.xxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 }, "NodeType": "db.r6g.large", "EngineVersion": "6.2", "EnginePatchVersion": "6.2.6", "ParameterGroupName": "default.memorydb-redis6", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "DataTiering": "false", "AutoMinorVersionUpgrade": true } } ``` Para ver los detalles del clúster actualizado una vez que su estado cambie de *actualizado* a *disponible*, utilice el siguiente comando: Para Linux, macOS o Unix: ``` aws memorydb describe-clusters \ --cluster-name my-cluster --show-shard-details ``` Para Windows: ``` aws memorydb describe-clusters ^ --cluster-name my-cluster --show-shard-details ``` Devuelve la siguiente respuesta JSON: ``` { "Clusters": [ { "Name": "my-cluster", "Status": "available", "NumberOfShards": 1, "Shards": [ { "Name": "0001", "Status": "available", "Slots": "0-16383", "Nodes": [ { "Name": "my-cluster-0001-001", "Status": "available", "AvailabilityZone": "us-east-1a", "CreateTime": "2021-08-21T20:22:12.405000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } }, { "Name": "my-cluster-0001-002", "Status": "available", "AvailabilityZone": "us-east-1b", "CreateTime": "2021-08-21T20:22:12.405000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } }, { "Name": "my-cluster-0001-003", "Status": "available", "AvailabilityZone": "us-east-1a", "CreateTime": "2021-08-22T12:59:31.844000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } } ], "NumberOfNodes": 3 } ], "ClusterEndpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 }, "NodeType": "db.r6g.large", "EngineVersion": "6.2", "EnginePatchVersion": "6.2.6", "ParameterGroupName": "default.memorydb-redis6", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "ACLName": "my-acl", "DataTiering": "false", "AutoMinorVersionUpgrade": true } ] } ``` Para obtener más información acerca de cómo aumentar el número de réplicas mediante la CLI, consulte [update-cluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) en la *Referencia de comandos de la AWS CLI*. ### Uso de la API de MemoryDB Para aumentar el número de réplicas de una partición de MemoryDB, utilice la acción `UpdateCluster` con los parámetros siguientes: + `ClusterName`: obligatorio. Identifica el clúster en el que desea aumentar el número de réplicas. + `ReplicaConfiguration`: obligatorio. Le permite establecer el número de réplicas. Para aumentar el número de réplicas, establezca la propiedad `ReplicaCount` en el número de réplicas que desea incluir en la partición al final de la operación. **Example** En el siguiente ejemplo, se aumenta el número de réplicas del clúster `sample-cluster` a tres. Al finalizar el ejemplo, existirán tres réplicas en cada partición. Este número se aplica tanto si se trata de un clúster de MemoryDB con una única partición como de un clúster de MemoryDB con varias particiones. ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateCluster &ReplicaConfiguration.ReplicaCount=3 &ClusterName=sample-cluster &Version=2021-01-01 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20210802T192317Z &X-Amz-Credential= ``` Para obtener más información acerca de cómo aumentar el número de réplicas mediante la API, consulte [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html). ## Reducción del número de réplicas de un clúster Puede reducir el número de réplicas de una partición de MemoryDB. Puede reducir el número de réplicas a cero, pero no puede realizar una conmutación por error a una réplica si el nodo principal falla. Puede utilizar la Consola de administración de AWS, la AWS CLI o la API de MemoryDB para reducir el número de réplicas de un clúster. **Topics** + [Uso de Consola de administración de AWS](#decrease-replica-count-con) + [Uso de AWS CLI](#decrease-replica-count-cli) + [Uso de la API de MemoryDB](#decrease-replica-count-api) ### Uso de Consola de administración de AWS Para reducir el número de réplicas en un clúster de MemoryDB (consola), consulte [Agregar/eliminar nodos de un clúster](clusters.deletenode.md). ### Uso de AWS CLI Para reducir el número de réplicas de un clúster de MemoryDB, utilice el comando `update-cluster` con los parámetros siguientes: + `--cluster-name`: obligatorio. Identifica el clúster en el que se desea reducir el número de réplicas. + `--replica-configuration`: obligatorio. `ReplicaCount`: defina esta propiedad para especificar el número de nodos de réplica que desea. **Example** En el siguiente ejemplo, se utiliza `--replica-configuration` para reducir el número de réplicas del clúster `my-cluster` al valor especificado. Para Linux, macOS o Unix: ``` aws memorydb update-cluster \ --cluster-name my-cluster \ --replica-configuration \ ReplicaCount=1 ``` Para Windows: ``` aws memorydb update-cluster ^ --cluster-name my-cluster ^ --replica-configuration ^ ReplicaCount=1 ^ ``` Devuelve la siguiente respuesta JSON: ``` { "Cluster": { "Name": "my-cluster", "Status": "updating", "NumberOfShards": 1, "ClusterEndpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 }, "NodeType": "db.r6g.large", "EngineVersion": "6.2", "EnginePatchVersion": "6.2.6", "ParameterGroupName": "default.memorydb-redis6", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "DataTiering": "false", "AutoMinorVersionUpgrade": true } } ``` Para ver los detalles del clúster actualizado una vez que su estado cambie de *actualizado* a *disponible*, utilice el siguiente comando: Para Linux, macOS o Unix: ``` aws memorydb describe-clusters \ --cluster-name my-cluster --show-shard-details ``` Para Windows: ``` aws memorydb describe-clusters ^ --cluster-name my-cluster --show-shard-details ``` Devuelve la siguiente respuesta JSON: ``` { "Clusters": [ { "Name": "my-cluster", "Status": "available", "NumberOfShards": 1, "Shards": [ { "Name": "0001", "Status": "available", "Slots": "0-16383", "Nodes": [ { "Name": "my-cluster-0001-001", "Status": "available", "AvailabilityZone": "us-east-1a", "CreateTime": "2021-08-21T20:22:12.405000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } }, { "Name": "my-cluster-0001-002", "Status": "available", "AvailabilityZone": "us-east-1b", "CreateTime": "2021-08-21T20:22:12.405000-07:00", "Endpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 } } ], "NumberOfNodes": 2 } ], "ClusterEndpoint": { "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com", "Port": 6379 }, "NodeType": "db.r6g.large", "EngineVersion": "6.2", "EnginePatchVersion": "6.2.6", "ParameterGroupName": "default.memorydb-redis6", "ParameterGroupStatus": "in-sync", "SubnetGroupName": "my-sg", "TLSEnabled": true, "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster", "SnapshotRetentionLimit": 0, "MaintenanceWindow": "wed:03:00-wed:04:00", "SnapshotWindow": "04:30-05:30", "ACLName": "my-acl", "DataTiering": "false", "AutoMinorVersionUpgrade": true } ] } ``` Para obtener más información acerca de cómo reducir el número de réplicas mediante la CLI, consulte [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) en la *Referencia de comandos de la AWS CLI*. ### Uso de la API de MemoryDB Para reducir el número de réplicas de un clúster de MemoryDB, utilice la acción `UpdateCluster` con los parámetros siguientes: + `ClusterName`: obligatorio. Identifica el clúster en el que se desea reducir el número de réplicas. + `ReplicaConfiguration`: obligatorio. Le permite establecer el número de réplicas. `ReplicaCount`: defina esta propiedad para especificar el número de nodos de réplica que desea. **Example** En el siguiente ejemplo, se utiliza `ReplicaCount` para reducir el número de réplicas del clúster `sample-cluster` a una. Al finalizar el ejemplo, existirá una réplica en cada partición. Este número se aplica tanto si se trata de un clúster de MemoryDB con una única partición como de un clúster de MemoryDB con varias particiones. ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateCluster &ReplicaConfiguration.ReplicaCount=1 &ClusterName=sample-cluster &Version=2021-01-01 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20210802T192317Z &X-Amz-Credential= ``` Para obtener más información acerca de cómo reducir el número de réplicas mediante la API, consulte [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).