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 OSS de Valkey, Memcached y Redis.

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 de software secundaria y de parche a la memoria caché, sin que la aplicación se vea afectada ni se produzca ningún tiempo de inactividad. No tiene que hacer nada.

Cuando haya una nueva versión principal 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 última versión principal modificando la memoria caché mediante la consola, la CLI o la API y seleccionando la versión más reciente del motor. Al igual que las actualizaciones menores y los parches, las actualizaciones de las versiones principales se realizan sin que la aplicación se interrumpa.

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 últimas versiones principales, secundarias y de parche disponibles. 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 clúster de Valkey o Redis OSS 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 en el caso de Redis, las versiones de OSS se identifican con una versión semántica que consta de un componente principal y uno secundario. Por ejemplo, en Redis OSS 6.2, la versión principal es 6 y la versión secundaria es 2. Cuando se utilizan clústeres de diseño propio, en el ElastiCache caso de Redis OSS también se expone el componente del parche, por ejemplo, Redis OSS 6.2.1, y la versión del parche es la 1.

  Las versiones principales son para cambios incompatibles con la API y las versiones secundarias son para nuevas funcionalidades añadidas de forma compatible con versiones anteriores. Las versiones de parche sirven para corregir errores compatibles con versiones anteriores y realizar cambios no funcionales.

Con Valkey y Redis OSS, para iniciar la actualización de las versiones del motor en el clúster o el grupo de replicación, modifíquelo y especifique 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 su cluster de caché y especificar la nueva versión del motor que desea utilizar. 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 Serverless. ElastiCache

Consideraciones sobre Valkey y Redis OSS

Cuando actualice un clúster de autodiseño de Valkey o Redis OSS, 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 al 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 la ElastiCache versión 7.2 para Valkey y la ElastiCache versión 6.0 para Redis OSS, ElastiCache ofrecerá 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 del motor de Redis OSS, puede actualizar la versión del 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 involucrado es el mismo, pero puede incurrir en un tiempo de conmutación por error más largo durante la propagación de DNS (de 30 s a 1 m).

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

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

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

• No puede actualizar directamente de Valkey o Redis OSS (modo de clúster deshabilitado) a Valkey o Redis OSS (modo de clúster habilitado) cuando actualiza su motor. El siguiente procedimiento muestra cómo actualizar de Valkey o Redis OSS (modo de clúster deshabilitado) a Valkey o Redis OSS (modo de clúster habilitado).

  Actualización de una versión de motor de Valkey o Redis OSS (modo de clúster deshabilitado) a la versión del motor de Valkey o Redis OSS (modo de clúster habilitado)

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

  2. Utilice la copia de seguridad para crear y propagar un clúster de Valkey o Redis OSS (modo de clúster habilitado) con una partición (grupo de nodo). 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: inicialización de datos en un nuevo clúster de autodiseño con una copia de seguridad creada externamente.

  3. Elimine el clúster o el grupo de replicación de Valkey o Redis OSS (modo de clúster deshabilitado) anterior. 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 grupo de replicación o clúster de Valkey o Redis OSS (modo de clúster habilitado) al número de particiones (grupos de nodo) que necesita. Para obtener más información, consulte Escalado de clústeres en Valkey o Redis OSS (modo de clúster habilitado)

• 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 clústeres de Redis OSS sencillos y clústeres con multi-AZ deshabilitado, recomendamos disponer de suficiente memoria para Redis OSS, tal y como se describe en Forma de garantizar que dispone de memoria suficiente para crear 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.

• Para clústeres de Redis OSS con multi-AZ habilitado, también recomendamos que programe actualizaciones del motor durante los periodos de poco tráfico entrante. Cuando se actualiza a Redis OSS 5.0.6 o a una versión posterior, el clúster principal sigue disponible para atender solicitudes 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

Cuando actualice un clúster de autodiseño de Memcached, 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 al 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.