Principales diferencias de comportamiento y compatibilidad de las versiones del motor con Redis OSS - Amazon ElastiCache
Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 7.0Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 6.2Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 6.0Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 5.0Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 4.0EOL anterior

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.

Principales diferencias de comportamiento y compatibilidad de las versiones del motor con Redis OSS

importante

La siguiente página está estructurada para indicar todas las diferencias de incompatibilidad entre las versiones e informarle de las consideraciones que debe tener en cuenta al actualizar a versiones más recientes. Esta lista incluye cualquier problema de incompatibilidad de versiones que pueda encontrar al actualizar.

Puede actualizar directamente desde la versión actual de Redis OSS a la última versión de Redis OSS disponible, sin necesidad de realizar actualizaciones secuenciales. Por ejemplo, puede actualizar directamente desde la versión 3.0 de Redis OSS a la versión 7.0.

Las versiones de Redis OSS se identifican con una versión semántica que incluye un componente principal, uno secundario y un parche. Por ejemplo, en Redis OSS 4.0.10, la versión principal es 4, la versión secundaria 0 y la versión del parche es 10. Por lo general, estos valores se incrementan en función de las siguientes convenciones:

  • Las versiones principales son para cambios incompatibles con la API

  • Las versiones secundarias son para nuevas funcionalidades añadidas de forma compatible con versiones anteriores

  • Las versiones de parche son para corregir errores compatibles con versiones anteriores y realizar cambios no funcionales

Recomendamos utilizar siempre la última versión del parche dentro de una versión principal o secundaria determinada para disponer de las últimas mejoras de rendimiento y estabilidad. A partir de la ElastiCache versión 6.0 para Redis OSS, ElastiCache ofreceremos una única versión para cada versión secundaria de Redis OSS en lugar de ofrecer varias versiones de parches. ElastiCachegestionará automáticamente la versión de parche de los clústeres de caché en ejecución, lo que garantizará un rendimiento y una seguridad mejorados.

También recomendamos actualizar periódicamente a la última versión principal, ya que la mayoría de las mejoras importantes no se transfieren a versiones anteriores. A medida que ElastiCache se amplía la disponibilidad a una nueva AWS región, ElastiCache el OSS de Redis es compatible con las dos versiones principales y secundarias más recientes de la nueva región en ese momento. Por ejemplo, si se lanza una nueva AWS región y las últimas versiones principales o secundarias de Redis OSS son 7.0 y 6.2, ElastiCache serán compatibles con ElastiCache las versiones 7.0 y 6.2 de Redis OSS en la nueva región. AWS A medida que se publiquen nuevas versiones principales o secundarias de Redis OSS, se ElastiCache seguirá añadiendo soporte ElastiCache para las versiones más recientes. Para obtener más información sobre cómo elegir regiones ElastiCache, consulte Elegir regiones y zonas de disponibilidad.

Cuando realice una actualización que abarque versiones principales o secundarias, tenga en cuenta la siguiente lista, que incluye el comportamiento y los cambios incompatibles con versiones anteriores publicados con Redis OSS a lo largo del tiempo.

Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 7.0

Para obtener una lista completa de los cambios, consulte Redis OSS 7.0 release notes.

  • SCRIPT LOAD y SCRIPT FLUSH ya no se propagan a réplicas. Si necesita algo de durabilidad para los scripts, le recomendamos que considere utilizar funciones de Redis OSS.

  • Los canales de pubsub ahora están bloqueados de forma predeterminada para los nuevos usuarios de ACL.

  • El comando STRALGO se sustituyó por el comando LCS.

  • El formato de ACL GETUSER ha cambiado para que todos los campos muestren el patrón de cadena de acceso estándar. Si utilizaba la automatización mediante ACL GETUSER, debe comprobar que maneje cualquiera de los formatos.

  • Las categorías de ACL para SELECT, WAIT, ROLE, LASTSAVE, READONLY, READWRITE y ASKING han cambiado.

  • El comando INFO ahora muestra las estadísticas de los comandos por subcomando en lugar de en los comandos del contenedor de nivel superior.

  • Los valores devueltos de los comandos LPOP, RPOP, ZPOPMIN y ZPOPMAX han cambiado en determinados casos límite. Si utiliza estos comandos, debe consultar las notas de la versión y evaluar si se ve afectado.

  • Los comandos SORT y SORT_RO ahora requieren acceso a todo el espacio de claves para poder utilizar los argumentos GET y BY.

Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 6.2

Para obtener una lista completa de los cambios, consulte Redis OSS 6.2 release notes.

  • Los indicadores de ACL de los comandos TIME, ECHO, ROLE y LASTSAVE se cambiaron. Esto puede provocar que se rechacen los comandos previamente permitidos y viceversa.

    nota

    Ninguno de estos comandos modifica ni da acceso a los datos.

  • Al actualizar desde Redis OSS 6.0, se cambia el orden de los pares clave/valor devueltos por una respuesta de mapa a un script de lua. Si sus scripts utilizan redis.setresp() o devuelven un mapa (nueva funcionalidad en Redis OSS 6.0), tenga en cuenta las implicaciones de que el script deje de funcionar en las actualizaciones.

Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 6.0

Para obtener una lista completa de los cambios, consulte Redis OSS 6.0 release notes.

  • El número máximo de bases de datos permitidas se ha reducido de 1,2 millones a 10 mil. El valor predeterminado es 16 y no recomendamos el uso de valores mucho mayores, ya que hemos detectado problemas de rendimiento y memoria.

  • Defina el AutoMinorVersionUpgrade parámetro en sí y ElastiCache gestionará la actualización de la versión secundaria mediante actualizaciones de autoservicio. Esto se gestionará a través de canales de notificación estándar a los clientes mediante una campaña de actualización de autoservicio. Para obtener más información, consulte Actualizaciones de autoservicio en. ElastiCache

Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 5.0

Para obtener una lista completa de los cambios, consulte Redis OSS 5.0 release notes.

  • Los scripts se replican por efectos en lugar de volver a ejecutar el script en la réplica. Por lo general, esto mejora el rendimiento, pero puede aumentar la cantidad de datos replicados entre los principales y las réplicas. Existe una opción para volver al comportamiento anterior que solo está disponible en la ElastiCache versión 5.0 para Redis OSS.

  • Si está actualizando desde Redis OSS 4.0, algunos comandos de los scripts de LUA devolverán los argumentos en un orden diferente al de las versiones anteriores. En Redis OSS 4.0, Redis ordenaba algunas respuestas de forma lexográfica para hacer que fueran deterministas; este orden no se aplica cuando los scripts se replican por efectos.

  • En Redis OSS 5.0.3 y versiones posteriores, ElastiCache el OSS de Redis descargará parte del trabajo de E/S a núcleos en segundo plano en los tipos de instancias con más de 4. VCPUs Esto puede cambiar las características de rendimiento de Redis OSS y los valores de algunas métricas. Para obtener más información, consulte ¿Qué métricas debo monitorear? para saber si necesita cambiar las métricas que ve.

Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 4.0

Para obtener una lista completa de los cambios, consulte Redis OSS 4.0 release notes.

  • El registro lento ahora registra dos argumentos adicionales, el nombre y la dirección del cliente. Este cambio debe ser compatible con versiones anteriores a menos que dependa explícitamente de cada entrada de registro lento que contenga 3 valores.

  • El comando CLUSTER NODES ahora devuelve un formato ligeramente diferente, que no es compatible con versiones anteriores. Recomendamos que los clientes no usen este comando para obtener información sobre los nodos presentes en un clúster y que, en su lugar, usen CLUSTER SLOTS.

EOL anterior

Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 3.2

Para obtener una lista completa de los cambios, consulte Redis OSS 3.2 release notes.

  • No hay cambios de compatibilidad que destacar para esta versión.

Para obtener más información, consulte ElastiCache calendario de fin de vida de las versiones para Redis OSS.

Cambios de comportamiento e incompatibles con versiones anteriores de Redis OSS 2.8

Para obtener una lista completa de los cambios, consulte Redis OSS 2.8 release notes.

  • A partir de la versión 2.8.22 de Redis OSS, el AOF de Redis OSS ya no es compatible con Redis OSS. ElastiCache Recomendamos usar MemoryDB cuando sea necesario conservar los datos de forma duradera.

  • A partir de la versión 2.8.22 de Redis OSS, el OSS de Redis ya no permite adjuntar ElastiCache réplicas a las unidades principales alojadas en ellas. ElastiCache Durante la actualización, las réplicas externas se desconectarán y no podrán volver a conectarse. Recomendamos utilizar el almacenamiento en caché en el cliente, disponible en Redis OSS 6.0, como alternativa a las réplicas externas.

  • Los comandos TTL y PTTL ahora devuelven -2 si la clave no existe y -1 si existe pero no tiene fecha de caducidad asociada. En Redis OSS 2.6 y versiones anteriores, se devolvía -1 para ambas condiciones.

  • SORT con ALPHA ahora ordena según la configuración regional de intercalación local si no se utiliza la opción STORE.

Para obtener más información, consulte ElastiCache calendario de fin de vida de las versiones para Redis OSS.