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 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 de su versión actual de Redis a la última OSS versión de Redis OSS disponible, sin necesidad de realizar actualizaciones secuenciales. Por ejemplo, puede actualizar directamente de la OSS versión 3.0 de Redis a la versión 7.0.
OSSLas versiones de Redis se identifican con una versión semántica que consta de un componente MAJOR yMINOR. PATCH Por ejemplo, en Redis OSS 4.0.10, la versión principal es la 4, la versión secundaria 0 y la versión del parche es la 10. Por lo general, estos valores se incrementan en función de las siguientes convenciones:
-
MAJORlas versiones son para cambios incompatibles API
-
MINORlas 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
Recomendamos utilizar siempre la última versión del parche dentro de un período determinado. MAJOR MINORversión para disponer de las últimas mejoras de rendimiento y estabilidad. A partir de Redis OSS 6.0, ElastiCache (RedisOSS) ofrecerá una única versión para cada versión OSS secundaria de Redis, en lugar de ofrecer varias versiones de parches. ElastiCache (RedisOSS) gestionará automáticamente la versión de parche 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 (RedisOSS) es compatible con las dos más recientes. MAJOR MINORversiones en ese momento para la nueva región. Por ejemplo, si se lanza una nueva AWS región y la últimaMAJOR. MINOR ElastiCache Las versiones (RedisOSS) son 7.0 y 6.2, ElastiCache (RedisOSS) admitirá las versiones 7.0 y 6.2 en la nueva AWS región. Como más reciente. MAJOR MINORSe han publicado versiones de ElastiCache (RedisOSS) y ElastiCache se seguirá añadiendo soporte para las versiones ElastiCache (RedisOSS) recién publicadas. 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 a OSS lo largo del tiempo.
El comportamiento de Redis OSS 7.0 y los cambios incompatibles con las versiones anteriores
Para obtener una lista completa de cambios, consulte las notas de la versión OSS 7.0 de Redis
-
SCRIPT LOADySCRIPT FLUSHya 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 por defecto para los nuevos ACL usuarios.
-
El comando
STRALGOse sustituyó por el comandoLCS. -
El formato de
ACL GETUSERha cambiado para que todos los campos muestren el patrón de cadena de acceso estándar. Si utilizaba la automatización medianteACL GETUSER, debe comprobar que maneje cualquiera de los formatos. -
Las ACL categorías de
SELECT,WAIT,ROLELASTSAVE,READONLYREADWRITE, yASKINGhan cambiado. -
El comando
INFOahora 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,ZPOPMINyZPOPMAXhan 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
SORTySORT_ROahora requieren acceso a todo el espacio de claves para poder utilizar los argumentosGETyBY.
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 OSS 6.2 de Redis
-
Se cambiaron los ACL indicadores de los
LASTSAVEcomandosTIMEECHOROLE,, y. 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 del 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 de que el script pueda 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 OSS 6.0 de Redis
-
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
AutoMinorVersionUpgradeparámetro en sí y ElastiCache (RedisOSS) 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 los cambios, consulte las notas de la versión OSS 5.0 de Redis
-
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 (RedisOSS) 5.0.
-
Si está actualizando desde Redis OSS 4.0, algunos comandos de los LUA scripts 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 convertirlas en deterministas; este orden no se aplica cuando los efectos replican los scripts.
-
En Redis OSS 5.0.3 y versiones posteriores, ElastiCache (RedisOSS) transferirá 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 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 OSS 4.0 de Redis
-
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 NODESahora 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, usenCLUSTER SLOTS.
¿Pasado EOL
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 OSS 3.2 de Redis
-
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 OSS 2.8 de Redis
-
A partir de la versión OSS 2.8.22 de Redis, Redis ya no OSS AOF es compatible con (Redis). ElastiCache OSS Recomendamos usar MemoryDB cuando sea necesario conservar los datos de forma duradera.
-
A partir de Redis OSS 2.8.22, ElastiCache (RedisOSS) 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 6.0, como alternativa a las réplicas externas. OSS
-
Los comandos
TTLyPTTLahora 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. -
SORTconALPHAahora ordena según la configuración regional de intercalación local si no se utiliza la opciónSTORE.
Para obtener más información, consulte Calendario de fin de vida de las versiones de Redis OSS.
