Administración de versiones para ElastiCache

Gestione la forma en que desea actualizar sus ElastiCache cachés y los clústeres de diseño propio actualizados para los motores Valkey, Redis y Memcached. OSS

Administración de versiones para ElastiCache Serverless Cache

Administre si se actualiza la caché ElastiCache sin servidor y cuándo, y realice las actualizaciones de versión según sus propios términos y plazos.

ElastiCache Serverless aplica automáticamente la última versión MINOR y la versión de PATCH software a la memoria caché, sin que la aplicación se vea afectada ni se produzca un tiempo de inactividad. No tiene que hacer nada.

Cuando haya una nueva MAJOR versión disponible, ElastiCache Serverless le enviará una notificación en la consola y un evento en ella. EventBridge Puede optar por actualizar la memoria caché a la versión principal más reciente modificando la memoria caché mediante la consola o API seleccionando la última versión del motor. CLI

Administración de versiones para clústeres de diseño propio ElastiCache

Al trabajar con ElastiCache clústeres de diseño propio, puede controlar si el software que alimenta el clúster de caché se actualiza a las nuevas versiones compatibles con ellas. ElastiCache Puede controlar cuándo actualizar la memoria caché a las versiones y PATCH versiones más recientes disponiblesMAJOR. MINOR Para iniciar la actualización de las versiones del motor en el clúster o el grupo de reproducción, modifíquelo y especifique una nueva versión del motor.

Puede controlar si el software compatible con el protocolo que alimenta su clúster de caché se actualiza a las nuevas versiones compatibles con ellas y cuándo. ElastiCache Este nivel de control permite mantener la compatibilidad con versiones concretas, probar nuevas versiones con la aplicación antes de implementarlas en producción y realizar actualizaciones de versiones en los horarios y los plazos que más le convengan.

Como las actualizaciones de versión pueden conllevar algunos riesgos de compatibilidad, no se producen automáticamente. Debe iniciarlas.

Clústeres de Valkey y Redis OSS

nota

• Si un OSS clúster de Valkey o Redis se replica en una o más regiones, la versión del motor se actualiza para las regiones secundarias y, después, para la región principal.

• ElastiCache Las versiones (RedisOSS) se identifican con una versión semántica que incluye un componente y. MAJOR MINOR Por ejemplo, en Redis OSS 6.2, la versión principal es la 6 y la versión secundaria es 2. Cuando se utilizan clústeres de diseño propio, ElastiCache (RedisOSS) también expone el PATCH componente, por ejemplo, Redis OSS 6.2.1, y la versión del parche es la 1.

  MAJORlas versiones son para cambios API incompatibles y MINOR las versiones son para nuevas funcionalidades añadidas de forma compatible con versiones anteriores. PATCHlas versiones son para correcciones de errores compatibles con versiones anteriores y cambios no funcionales.

Con Valkey y RedisOSS, puede iniciar las actualizaciones de las versiones del motor de su clúster o grupo de replicación modificándolo y especificando una nueva versión del motor. Para obtener más información, consulte Modificación de un grupo de reproducción.

Memcached

Con Memcached, para actualizar a una versión más reciente, debe modificar el clúster de caché y especificar la nueva versión del motor que desea usar. La actualización a una nueva versión de Memcached es un proceso destructivo: perderá los datos y deberá comenzar con una caché nueva. Para obtener más información, consulte Modificación de un ElastiCache clúster.

Debe tener en cuenta los requisitos siguientes a la hora de actualizar de una versión antigua de Memcached a la versión 1.4.33 o posterior. Se produce un error con CreateCacheCluster y ModifyCacheCluster en las condiciones que se describen a continuación:

• Si slab_chunk_max > max_item_size.

• Si max_item_size modulo slab_chunk_max != 0.

• Si max_item_size > ((max_cache_memory - memcached_connections_overhead) / 4).

  El valor (max_cache_memory - memcached_connections_overhead) es la memoria útil del nodo para los datos. Para obtener más información, consulte Capacidad adicional para conexiones de Memcached.

Consideraciones sobre la actualización al trabajar con clústeres de autodiseño

nota

Las siguientes consideraciones solo son aplicables al actualizar clústeres de autodiseño. No se aplican a ElastiCache Serverless.

Consideraciones sobre Valkey y Redis OSS

Al actualizar un OSS clúster de Valkey o Redis de diseño propio, tenga en cuenta lo siguiente.

• La administración de la versión del motor está diseñada para que pueda tener el mayor control posible sobre cómo se produce la aplicación de parches. Sin embargo, ElastiCache se reserva el derecho de parchear el clúster en su nombre en el improbable caso de que se produzca una vulnerabilidad de seguridad crítica en el sistema o en el software de la memoria caché.

• A partir de Valkey 7.2 y Redis OSS 6.0, ElastiCache ofreceremos una única versión para cada versión menor, en lugar de ofrecer varias versiones de parches.

• A partir de la versión 5.0.6 OSS del motor Redis, puede actualizar la versión de clúster con un tiempo de inactividad mínimo. El clúster está disponible para operaciones de lectura durante toda la actualización y para operaciones de escritura durante la mayoría del proceso, excepto durante la operación de conmutación por error, que dura unos segundos.

• También puede actualizar sus ElastiCache clústeres con versiones anteriores a la 5.0.6. El proceso es el mismo, pero es posible que se prolongue el tiempo de conmutación por error durante la DNS propagación (30 segundos a 1 minuto).

• A partir de Redis OSS 7, ElastiCache permite cambiar entre Valkey o Redis (modo de clúster desactivado) y Valkey o Redis OSS (modo de clúster activado). OSS

• El proceso de actualización del motor Amazon ElastiCache (RedisOSS) está diseñado para hacer todo lo posible por conservar los datos existentes y requiere una replicación correcta de RedisOSS.

• Al actualizar el motor, ElastiCache finalizará las conexiones de los clientes existentes. Para minimizar el tiempo de inactividad durante las actualizaciones del motor, le recomendamos que implemente las mejores prácticas para OSS los clientes de Redis, con reintentos de error y retrasos exponenciales, así como las mejores prácticas para minimizar el tiempo de inactividad durante el mantenimiento.

• No puede actualizar directamente de Valkey o Redis OSS (modo de clúster desactivado) a Valkey o Redis OSS (modo de clúster activado) al actualizar el motor. El siguiente procedimiento muestra cómo actualizar de Valkey o Redis OSS (modo de clúster desactivado) a Valkey o Redis (modo de clúster activado). OSS

  Para actualizar de una versión de motor Valkey o Redis OSS (modo de clúster desactivado) a una versión de motor de Valkey o OSS Redis (modo de clúster activado)

  1. Haga una copia de seguridad de su clúster o grupo de replicación de Valkey o Redis OSS (modo de clúster desactivado). Para obtener más información, consulte Copias de seguridad manuales.

  2. Utilice la copia de seguridad para crear e inicializar un clúster de Valkey o Redis OSS (modo de clúster activado) con un fragmento (grupo de nodos). Especifique la nueva versión de motor y habilite el modo de clúster al crear el clúster o grupo de reproducción. Para obtener más información, consulte Tutorial: Sembrar un nuevo clúster de diseño propio con una copia de seguridad creada externamente.

  3. Elimine el clúster o grupo de replicación anterior de Valkey o Redis OSS (modo de clúster desactivado). Para obtener más información, consulte Eliminar un clúster en ElastiCache o Eliminación de un grupo de reproducción.

  4. Escale el nuevo clúster o grupo de replicación de Valkey o Redis OSS (modo de clúster activado) en función del número de fragmentos (grupos de nodos) que necesite. Para obtener más información, consulte Escalar clústeres en Valkey o Redis OSS (modo de clúster activado)

• Cuando actualiza las versiones principales del motor, por ejemplo de 5.0.6 a 6.0, debe seleccionar un grupo de parámetros nuevo que sea compatible con la versión del motor nueva.

• Para los clústeres de Redis individuales y OSS los clústeres con Multi-AZ deshabilitados, recomendamos que Redis disponga de memoria suficiente, tal y como se describe en. OSS Asegurarse de tener suficiente memoria para hacer una instantánea de Valkey o Redis OSS En estos casos, el nodo principal no está disponible para las solicitudes de servicio durante el proceso de actualización.

• En el caso de OSS los clústeres de Redis con zonas de disponibilidad múltiples (Multi-AZ) habilitadas, también recomendamos programar las actualizaciones del motor durante los períodos de bajo tráfico de escritura entrante. Al actualizar a Redis OSS 5.0.6 o una versión posterior, el clúster principal seguirá estando disponible para atender las solicitudes de servicio durante el proceso de actualización.

  Los clústeres y grupos de reproducción con varias particiones se procesan y se aplican parches de la siguiente manera:

  • Todas las particiones se procesan en paralelo. Solo se realiza una operación de actualización en una partición a la vez.

  • En cada partición, todas las réplicas se procesan antes que el principal. Si hay menos réplicas en una partición, el principal de esa partición podrá procesarse antes que las réplicas de otras particiones terminen de procesarse.

  • En todas las particiones, los nodos principales se procesan en series. Solo se actualiza un nodo principal a la vez.

• Si el cifrado se encuentra habilitado en su grupo de reproducción o clúster actual, no puede actualizar a una versión del motor que no admita cifrado, como de la versión 3.2.6 a la 3.2.10.

Consideraciones sobre Memcached

Al actualizar un clúster de Memcached de diseño propio, tenga en cuenta lo siguiente.

• La administración de la versión del motor está diseñada para que pueda tener el mayor control posible sobre cómo se produce la aplicación de parches. Sin embargo, ElastiCache se reserva el derecho de aplicar parches a su clúster en su nombre en el improbable caso de que se produzca una vulnerabilidad de seguridad crítica en el sistema o en el software de la memoria caché.

• Puesto que el motor de Memcached no es compatible con la persistencia, las actualizaciones de versión del motor de Memcached son siempre un proceso disruptivo que borra todos los datos de caché del clúster.