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.
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
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)
-
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.
-
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.
-
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.
-
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.
