Diferencias principales de compatibilidad y comportamiento de versiones

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 su 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 de 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 consta de un componente MAYOR, UNO MENOR y UN COMPONENTE PATCH. Por ejemplo, en Redis OSS 4.0.10, la versión principal es la 4, la versión secundaria es 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 funciones agregadas de manera compatible con versiones anteriores.

• Las versiones PARCHE son para correcciones de errores compatibles con versiones anteriores y cambios no funcionales.

Recomendamos mantener siempre la última versión del parche dentro de una versión PRINCIPAL.SECUNDARIO determinada para tener las últimas mejoras de rendimiento y estabilidad. A partir de Redis OSS 6.0, ElastiCache (Redis OSS) ofrecerá una única versión para cada versión secundaria de Redis OSS, en lugar de ofrecer varias versiones de parches. ElastiCache (Redis OSS) gestionará automáticamente la versión parcheada de los clústeres de caché en ejecución, lo que garantizará un mejor rendimiento y una mayor seguridad.

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 amplía la disponibilidad a una nueva AWS región, ElastiCache (Redis OSS) es compatible con las dos versiones MAJOR.MINOR más recientes en ese momento para la nueva región. Por ejemplo, si se lanza una nueva AWS región y las últimas versiones de MAJOR.MINOR ElastiCache (Redis OSS) son 7.0 y 6.2, ElastiCache (Redis OSS) admitirá las versiones 7.0 y 6.2 en la nueva región. AWS A medida que se publiquen nuevas versiones MAJOR.MINOR de ElastiCache (Redis OSS), se ElastiCache seguirá añadiendo soporte para las versiones más recientes (Redis OSS). ElastiCache Para obtener más información sobre cómo elegir regiones ElastiCache, consulte Elegir regiones y zonas de disponibilidad.

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

El comportamiento de Redis OSS 7.0 y los cambios incompatibles con versiones anteriores

Para obtener una lista completa de cambios, consulte las notas de la versión de Redis OSS 7.0.

• SCRIPT LOAD y SCRIPT FLUSH ya no se propagan a réplicas. Si necesita que los scripts tengan cierta durabilidad, le recomendamos que considere la posibilidad de utilizar las 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.

El comportamiento de Redis OSS 6.2 y los cambios incompatibles con versiones anteriores

Para obtener una lista completa de cambios, consulte las notas de la versión 6.2 de Redis OSS.

• 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 lua. Si sus scripts utilizan redis.setresp() o devuelven un mapa (nuevo en Redis OSS 6.0), tenga en cuenta las implicaciones que el script podría fallar en las actualizaciones.

El comportamiento de Redis OSS 6.0 y los cambios incompatibles con versiones anteriores

Para obtener una lista completa de cambios, consulte las notas de la versión de Redis OSS 6.0.

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

• Establezca el AutoMinorVersionUpgrade parámetro en sí y ElastiCache (Redis OSS) 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

El comportamiento de Redis OSS 5.0 y los cambios incompatibles con versiones anteriores

Para obtener una lista completa de cambios, consulte las notas de la versión de Redis OSS 5.0.

• 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 ElastiCache (Redis OSS) 5.0.

• 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 OSS ordenaba algunas respuestas de forma lexográfica para hacerlas deterministas; este orden no se aplica cuando los scripts se replican mediante efectos.

• En Redis OSS 5.0.3 y versiones posteriores, ElastiCache (Redis OSS) transferirá parte del trabajo de E/S a núcleos en segundo plano en tipos de instancias con más de 4 CPU virtuales. Esto puede cambiar las características de rendimiento de Redis OSS y cambiar 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.

El comportamiento de Redis OSS 4.0 y los cambios incompatibles con versiones anteriores

Para obtener una lista completa de los cambios, consulte las notas de la versión de Redis OSS 4.0.

• 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

El comportamiento de Redis OSS 3.2 y los cambios incompatibles con versiones anteriores

Para obtener una lista completa de cambios, consulte las notas de la versión 3.2 de Redis OSS.

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

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

El comportamiento de Redis OSS 2.8 y los cambios incompatibles con versiones anteriores

Para obtener una lista completa de cambios, consulte las notas de la versión 2.8 de Redis OSS.

• A partir de Redis OSS 2.8.22, 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 Redis OSS 2.8.22, ElastiCache (Redis OSS) ya no permite adjuntar 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é del lado del 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. Redis OSS 2.6 y las versiones anteriores solían devolver -1 en 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 Calendario de fin de vida de las versiones de Redis OSS.