Compartir a través de

Persistencia de datos en Azure Cache for Redis

  • Se aplica a: ✅ Azure Cache for Redis

Si se produce un error en la caché de Azure Cache for Redis, la pérdida de datos es posible cuando los nodos están inactivos. La persistencia de Redis permite conservar los datos almacenados en instancias de caché. Si se produce un error de hardware, la instancia de caché se rehidrata con datos del archivo de persistencia cuando vuelve a estar en línea.

En este artículo se describe la persistencia de Redis y cómo configurar y administrar la persistencia de datos en las instancias de Azure Redis Cache de nivel Premium y Enterprise. La característica de persistencia de datos no está disponible en los niveles Básico o Estándar y está en versión preliminar en los niveles Enterprise y Enterprise Flash.

La capacidad de conservar datos es una manera importante de aumentar la durabilidad de una instancia de caché, ya que almacena todos los datos de caché en la memoria. La persistencia debe ser una parte clave de la estrategia de alta disponibilidad y recuperación ante desastres de Azure Redis.

Importante

La funcionalidad de persistencia de datos proporciona resistencia para errores inesperados de nodo de Redis. La persistencia de datos no es una característica de copia de seguridad de datos ni de recuperación a un momento dado (PITR). Si los datos dañados se escriben en la instancia de Redis, también se conservan los datos dañados. Para realizar copias de seguridad de la instancia de Redis, use la característica Exportar .

Importante

Si está utilizando la persistencia en el nivel Premium, verifique si la cuenta de almacenamiento tiene habilitada la eliminación temporal antes de usar la función de persistencia de datos. El uso de la persistencia de datos con eliminación temporal provoca costos de almacenamiento muy altos. Para obtener más información, consulte ¿Debo habilitar la eliminación temporal?

Ámbito de disponibilidad

Nivel Básico y Estándar De primera calidad Enterprise o Enterprise Flash
Disponible No Sí Sí (versión preliminar)

Tipos de persistencia de datos de Redis

Azure Redis ofrece dos tipos de persistencia de datos, el formato de base de datos de Redis (RDB) y el formato de archivo de solo anexión (AOF).

  • La persistencia de RDB conserva una instantánea de la memoria caché en un formato binario y la guarda en una cuenta de Azure Storage. Configure la frecuencia de copia de seguridad para determinar la frecuencia de conservación de la instantánea. Si se produce un evento catastrófico que deshabilita la memoria caché principal y de réplica, la memoria caché se reconstruye automáticamente mediante la instantánea más reciente. Para obtener más información, consulte Ventajas de RDB y desventajas de RDB.

  • La persistencia de AOF guarda todas las operaciones de escritura en un registro y guarda el registro una vez por segundo en una cuenta de Azure Storage. Si se produce un evento catastrófico que deshabilita las memorias caché principal y de réplica, la memoria caché se reconstruye automáticamente mediante las operaciones de escritura almacenadas. Para obtener más información, consulte Ventajas de AOF y desventajas de AOF.

Requisitos y limitaciones

  • La funcionalidad de persistencia de datos proporciona resistencia para errores inesperados en los nodos de Redis. La persistencia de datos no es una característica de copia de seguridad o PITR de datos. Si los datos dañados se escriben en la instancia de Redis, los datos dañados también se conservan. Para realizar una copia de seguridad de la instancia de Redis, use la característica Exportar .

  • Las características de persistencia de Azure Cache for Redis están diseñadas para restaurar datos automáticamente en la misma caché después de la pérdida de datos. No se pueden importar archivos de datos persistentes a una caché nueva o existente.

    • Para mover datos entre cachés, use las características importar y exportar datos .

    • Para generar copias de seguridad de datos que se pueden agregar a una nueva caché, puede usar scripts automatizados mediante PowerShell o la CLI de Azure que exporten datos periódicamente.

  • La persistencia no se admite con cachés que usan la replicación geográfica pasiva o la replicación geográfica activa.

  • En el nivel Premium, los datos se conservan directamente en una cuenta de Azure Storage que posee y administra.

  • La cuenta de almacenamiento para la persistencia de datos de nivel Premium debe estar en la misma región que la instancia de caché. Sin embargo, puede usar una cuenta de almacenamiento en una suscripción diferente para conservar los datos si usa la identidad administrada para conectarse a la cuenta de almacenamiento.

  • Es mejor deshabilitar la característica de eliminación temporal en la cuenta de almacenamiento que usa para la persistencia de datos de nivel Premium. El uso de la persistencia de datos con eliminación temporal provoca costos de almacenamiento muy altos. Para obtener más información, consulte Precios y facturación y ¿Debo habilitar la eliminación temporal?

  • Se realiza una copia de seguridad de los archivos RDB en el almacenamiento en forma de blobs en páginas. Los blobs de página no se admiten en las cuentas de almacenamiento con el espacio de nombres jerárquico (HNS) habilitado, como Azure Data Lake Storage Gen2, por lo que el almacenamiento persistente tiende a fallar en esas cuentas de almacenamiento.

  • En el nivel Premium, no se admite la persistencia de AOF con varias réplicas.

Cifrado de datos

Dado que la persistencia de Redis crea datos en reposo, es importante cifrar estos datos. Las opciones de cifrado varían en función del nivel de Azure Redis que use.

Para el nivel Premium, los datos fluyen directamente desde la instancia de caché a Azure Storage al iniciarse la persistencia. Azure Storage cifra automáticamente los datos al conservarlos, pero puede usar varios métodos de cifrado, incluidas las claves administradas por Microsoft (MMK), las claves administradas por el cliente (CMK) y las claves proporcionadas por el cliente. Para más información, consulte Cifrado de Azure Storage para datos en reposo y claves administradas por el cliente para el cifrado de Azure Storage.

Configuración de la persistencia de datos

Puede usar Azure Portal, plantillas de Azure Resource Manager (ARM), PowerShell o la CLI de Azure para crear y configurar la persistencia de datos para cachés de Azure Redis de nivel Premium o Enterprise.

Prerrequisitos

  • Para crear y agregar persistencia a las cachés de Azure Redis, necesita acceso de escritura y permisos para crear cachés de nivel Premium o Enterprise en una suscripción de Azure.
  • Para las memorias caché de nivel Premium, necesita una cuenta de Azure Storage en la misma región que la memoria caché para almacenar los datos de caché. Si usa la identidad administrada como método de autenticación, puede usar una cuenta de almacenamiento en una suscripción diferente de la caché.
  • Para los procedimientos de Azure PowerShell, necesita Azure PowerShell instalado, o utilice Azure Cloud Shell con el entorno de PowerShell en el portal de Azure.
  • Para los procedimientos de la CLI de Azure, necesita tener la CLI de Azure instalada o usar Azure Cloud Shell con el entorno de Bash en el portal de Azure.

Configuración de la persistencia de datos en Azure Portal

En Azure Portal, puede configurar la persistencia de datos al crear la instancia de caché de Nivel Enterprise o Redis Premium de Azure.

Nota:

También puede agregar persistencia a una memoria caché creada anteriormente; para ello, vaya a Persistencia de datos en Configuración en el menú de navegación izquierdo de la memoria caché.

  1. Para crear una caché Premium en Azure Portal, siga las instrucciones de Inicio rápido: Creación de una caché de Redis de código abierto y seleccione Premium para la SKU de caché en la pestaña Aspectos básicos .

    Captura de pantalla que muestra un formulario para crear un recurso de Azure Cache for Redis.

  2. Al rellenar la pestaña Opciones avanzadas , seleccione RDB o persistencia de AOF para el archivo de copia de seguridad en Persistencia de datos y configure las opciones pertinentes.

    Captura de pantalla que muestra la configuración de la persistencia de datos RDB.

    • Para RDB, configure estos valores:

      Parámetro Importancia Descripción
      Método de autenticación Seleccione Identidad administrada o clave de almacenamiento. El uso de la identidad administrada permite usar una cuenta de almacenamiento en una suscripción diferente de la caché.
      Suscripción Seleccione la suscripción que contiene su identidad administrada. Este elemento solo aparece si eligió la autenticación de identidad administrada .
      Frecuencia de copia de seguridad Seleccione un intervalo de copia de seguridad: 15 minutos, 30 minutos, 60 minutos, 6 horas, 12 horas o 24 horas. Este intervalo empieza la cuenta atrás cuando se completa correctamente la operación de copia de seguridad anterior. Cuando transcurre el intervalo, se inicia una nueva copia de seguridad.
      Cuenta de almacenamiento Seleccione la cuenta de almacenamiento. La cuenta de almacenamiento debe estar en la misma región que la caché. Se recomienda una cuenta de Premium Storage porque tiene un mayor rendimiento.
      Clave de almacenamiento Seleccione la clave principal o la clave secundaria que se va a usar. Este elemento solo aparece si eligió autenticación de clave de almacenamiento . Si se vuelve a generar la clave de almacenamiento para la cuenta de almacenamiento de persistencia, debe volver a configurar la clave en la lista desplegable Clave de almacenamiento .

    • Para AOF, configure estas opciones:

      Parámetro Importancia Descripción
      Método de autenticación Seleccione Identidad administrada o clave de almacenamiento. El uso de la identidad administrada permite usar una cuenta de almacenamiento en una suscripción diferente de la caché.
      Suscripción Seleccione la suscripción que contiene su identidad administrada. Este elemento solo aparece si eligió la autenticación de identidad administrada .
      Primera cuenta de almacenamiento Seleccione la cuenta de almacenamiento. La cuenta de almacenamiento debe estar en la misma región que la caché. Se recomienda una cuenta de Premium Storage porque tiene un mayor rendimiento.
      Primera clave de almacenamiento Seleccione la clave principal o la clave secundaria que se va a usar. Este elemento solo aparece si eligió autenticación de clave de almacenamiento . Si se vuelve a generar la clave de almacenamiento, debe volver a configurar la clave en la lista desplegable Clave de almacenamiento .
      Segunda cuenta de almacenamiento Opcionalmente, seleccione una cuenta de almacenamiento secundaria. Si configura una cuenta de almacenamiento secundaria, las escrituras en la caché de réplicas se conservan en esta segunda cuenta de almacenamiento.
      Segunda clave de almacenamiento Elija la clave principal o la clave secundaria que se va a usar. Este elemento solo aparece si eligió autenticación de clave de almacenamiento . Si se vuelve a generar la clave de almacenamiento, debe volver a configurar esta.

  3. Complete todas las pestañas y termine de crear la memoria caché siguiendo el resto de las instrucciones de Inicio rápido: Creación de una caché de Redis de código abierto.

Con la persistencia de RDB, la primera copia de seguridad se inicia una vez transcurrido el intervalo de frecuencia de copia de seguridad.

Con la persistencia de AOF, las operaciones de escritura en la memoria caché se guardan en la cuenta o cuentas de almacenamiento con nombre. Si se produce un error catastrófico que elimina las memorias caché principal y de réplica, el registro de AOF almacenado se usa para recompilar la memoria caché.

Configuración de la persistencia de datos mediante Azure PowerShell

Puede usar Azure PowerShell para configurar la persistencia de datos al crear una caché de Azure Redis Premium o de nivel Enterprise, o para agregar persistencia a una caché creada anteriormente.

Puede usar el comando New-AzRedisCache para crear una nueva caché de nivel Premium de Azure Redis que use la persistencia de datos.

Para actualizar las memorias caché existentes para usar la persistencia de datos, ejecute el comando Set-AzRedisCache . Para obtener instrucciones, consulte Adición de persistencia a una caché existente.

Configuración de la persistencia de datos mediante la CLI de Azure

Puede usar la CLI de Azure para configurar la persistencia de datos al crear una caché de Azure Redis Premium o de nivel Enterprise, o para agregar persistencia a una caché creada anteriormente.

Puede usar el comando az redis create para crear una nueva caché de nivel Premium que use la persistencia de datos. Por ejemplo:

az redis create --location westus2 --name MyRedisCache --resource-group MyResourceGroup --sku Premium --vm-size p1 --redis-configuration @"config_rdb.json"

Para actualizar una caché existente, use el comando az redis update . Por ejemplo:

az redis update --name MyRedisCache --resource-group MyResourceGroup --set "redisConfiguration.rdb-storage-connection-string"="BlobEndpoint=https//..." "redisConfiguration.rdb-backup-enabled"="true" "redisConfiguration.rdb-backup-frequency"="15" "redisConfiguration.rdb-backup-max-snapshot-count"="1"

P+F de persistencia

Esta sección contiene respuestas a preguntas más frecuentes sobre la persistencia de Azure Redis Cache.

Persistencia de RDB

Persistencia de AOF

¿Puedo habilitar la persistencia en una memoria caché creada anteriormente?

Sí, puede configurar la persistencia en la creación de caché y en las cachés Premium, Enterprise o Enterprise Flash existentes.

¿Puedo habilitar la persistencia de AOF y RDB al mismo tiempo?

No, puede habilitar RDB o AOF, pero no ambos a la vez.

¿Cómo funciona la persistencia con la replicación geográfica?

La persistencia de datos no funciona con la replicación geográfica habilitada.

¿Qué modelo de persistencia debería elegir?

La persistencia AOF escribe en un registro una vez por segundo, mientras que la persistencia RDB guarda copias de seguridad en función del intervalo de tiempo de copia de seguridad configurado. La persistencia de RDB tiene menos efecto en el rendimiento de transferencia y en el rendimiento en general que la persistencia de AOF.

Elija la persistencia de AOF si el objetivo principal es minimizar la pérdida de datos y puede controlar un menor rendimiento para la memoria caché. Elija persistencia de RDB si desea mantener un rendimiento óptimo en la memoria caché, pero desea un mecanismo para la recuperación de datos.

Para obtener más información, consulte ventajas de RDB, desventajas de RDB, ventajas de AOF y desventajas de AOF.

¿Afecta la persistencia de AOF a la productividad, la latencia o el rendimiento de la memoria caché?

La persistencia de AOF afecta al rendimiento de procesamiento. Dado que AOF se ejecuta en el proceso principal y de réplica, verá una mayor carga de CPU y servidor para una caché con persistencia de AOF que en una caché idéntica sin persistencia de AOF. AOF ofrece la mejor coherencia con los datos en memoria porque cada escritura y eliminación se conserva con solo unos segundos de retraso. El inconveniente es que AOF es más intensivo en cuanto a procesamiento.

Siempre que la CPU y la carga del servidor sean inferiores a 90%, hay una penalización en el rendimiento, pero la memoria caché funciona normalmente. Por encima del 90 % de la CPU y la carga del servidor, la penalización del rendimiento puede ser mucho mayor y la latencia de todos los comandos procesados por la memoria caché aumenta. La latencia aumenta porque la persistencia de AOF se ejecuta tanto en el proceso principal como en el de réplica, lo que aumenta la carga en el nodo en uso y pone la persistencia en la ruta crítica de los datos.

¿Qué ocurre si se escala a un tamaño diferente y se restaura una copia de seguridad que se realizó antes de la operación de escalado?

  • Si ha escalado a un tamaño mayor, no hay ningún efecto.
  • Si ha escalado a un tamaño menor y tiene una configuración de bases de datos personalizada mayor que el límite de bases de datos para el nuevo tamaño, no se restauran los datos de esas bases de datos. Para obtener más información, consulte ¿Se ve afectada la configuración de mis bases de datos personalizadas durante el escalado?
  • Si ha escalado a un tamaño menor y no hay suficiente espacio en el tamaño más pequeño para contener todos los datos de la última copia de seguridad, las claves se expulsan durante el proceso de restauración. Normalmente, las claves se expulsan mediante la directiva de expulsión allkeys-lru.

¿Puedo usar la misma cuenta de almacenamiento para la persistencia de dos memorias caché diferentes?

No, debe usar cuentas de almacenamiento diferentes. Cada caché debe tener su propia cuenta de almacenamiento para configurar la persistencia.

Importante

Use también cuentas de almacenamiento independientes para la persistencia y realizar operaciones de exportación periódicas en una memoria caché.

¿Se me cobra por el almacenamiento que se usa en la persistencia de datos?

  • En el caso de las cachés Premium, se le cobra por el almacenamiento usado por el modelo de precios de la cuenta de almacenamiento.
  • En el caso de las memorias caché de Enterprise y Enterprise Flash, el almacenamiento en disco administrado se incluye en el precio y no incurre en cargos adicionales.

¿Con qué frecuencia escribe la persistencia de RDB y AOF en mis blobs y debo habilitar la eliminación temporal?

La persistencia de RDB y AOF pueden escribir en los blobs de almacenamiento con tanta frecuencia como cada hora, cada pocos minutos o cada segundo. La eliminación temporal se vuelve cara rápidamente con los tamaños de datos típicos de un caché que también realiza operaciones de escritura cada segundo. Habilitar la eliminación temporal en una cuenta de almacenamiento también significa que Azure Redis no puede minimizar los costos de almacenamiento mediante la eliminación de los datos de copia de seguridad antiguos.

Es mejor evitar habilitar la eliminación temporal en las cuentas de almacenamiento que use para la persistencia de datos de nivel Premium de Azure Redis. Para obtener más información sobre los costos de eliminación suave, consulte Precios y facturación.

¿Puedo cambiar la frecuencia de copia de seguridad de RDB después de crear la memoria caché?

Sí, puede cambiar la frecuencia de copia de seguridad de la persistencia de RDB mediante Azure Portal, la CLI de Azure o Azure PowerShell.

¿Por qué hay más de 60 minutos entre copias de seguridad cuando tengo una frecuencia de copia de seguridad de RDB de 60 minutos?

El intervalo de frecuencia de copia de seguridad de la persistencia de RDB no se inicia hasta que el proceso de copia de seguridad anterior se ha completado correctamente. Si la frecuencia de copia de seguridad es de 60 minutos y tarda 15 minutos en completarse, la siguiente copia de seguridad no se inicia hasta 75 minutos después de la hora de inicio de la copia de seguridad anterior.

¿Qué ocurre con las copias de seguridad de RDB antiguas cuando se realiza una nueva copia de seguridad?

Todas las copias de seguridad de persistencia de RDB excepto la más reciente se eliminan automáticamente. Es posible que esta eliminación no se produzca inmediatamente, pero las copias de seguridad anteriores no se guardan de manera indefinida. Si usa el nivel Premium para la persistencia y la eliminación suave está activada para la cuenta de almacenamiento, las copias de seguridad existentes seguirán residiendo en el estado de eliminación suave.

¿Cuándo debo usar una segunda cuenta de almacenamiento?

Use una segunda cuenta de almacenamiento para la persistencia de AOF cuando se espere tener operaciones SET superiores a las habituales en la memoria caché. El uso de la cuenta de almacenamiento secundaria ayuda a garantizar que la memoria caché no alcanza los límites de ancho de banda de almacenamiento. Esta opción solo está disponible para las memorias caché de nivel Premium.

¿Cómo puedo quitar la segunda cuenta de almacenamiento?

Puede quitar la cuenta de almacenamiento secundaria de persistencia de AOF si establece la segunda cuenta de almacenamiento de modo que sea la misma que la primera cuenta de almacenamiento. Para cambiar la configuración de las cachés existentes, seleccione Persistencia de datos en Configuración en el menú de navegación izquierdo de la página de caché. Para deshabilitar la persistencia por completo, seleccione Deshabilitado en la página Persistencia de datos .

¿Qué es una reescritura y cómo afecta a la memoria caché?

Cuando un archivo AOF se vuelve lo suficientemente grande, una reescritura se pone automáticamente en cola en la memoria caché. La reescritura cambia el tamaño del archivo AOF con el conjunto mínimo de operaciones necesario para crear el conjunto de datos actual.

Durante las operaciones de reescritura, puede esperar que se alcancen los límites de rendimiento antes, especialmente cuando se trabaja con grandes conjuntos de datos. Las reescrituras se producen con menos frecuencia a medida que el archivo AOF es mayor, pero tardan mucho tiempo en producirse.

¿Qué debo esperar al escalar una memoria caché con AOF habilitado?

Si el archivo AOF en el momento del escalado es grande, espere que la operación de escalado tarde más de lo habitual, ya que vuelve a cargar el archivo después de que finalice el escalado. Consulte también ¿Qué ocurre si se escala a un tamaño diferente y se restaura una copia de seguridad que se realizó antes de la operación de escalado?

¿Cómo se organizan los datos de AOF en el almacenamiento?

Al usar el nivel Premium, los datos almacenados en archivos AOF se dividen en varios blob en páginas por partición. De forma predeterminada, la mitad de los blobs se guardan en la cuenta de almacenamiento principal y la mitad se guardan en la cuenta de almacenamiento secundaria. Dividir los datos en varios blobs de página y en dos cuentas de almacenamiento diferentes mejora el rendimiento.

Si la tasa máxima de escrituras en la memoria caché no es alta, es posible que este rendimiento adicional no sea necesario. En ese caso, se puede quitar la configuración de la cuenta de almacenamiento secundaria y todos los archivos AOF almacenados en la única cuenta de almacenamiento principal. En la tabla siguiente se muestra el número total de blobs en páginas que usa cada plan de tarifa.

Nivel Premium Datos BLOB
P1 8 por partición
P2 16 por partición
P3 32 por partición
P4 40 por partición

Cuando se habilita la agrupación en clústeres, cada partición de la memoria caché tiene su propio conjunto de blobs en páginas, según la tabla anterior. Por ejemplo, una caché P2 con tres particiones distribuye su archivo AOF entre 48 blobs en páginas: dieciséis blobs por partición, con tres particiones.

Después de una reescritura, hay dos conjuntos de archivos AOF en el almacenamiento. Las reescrituras se producen en segundo plano y se asocian al primer conjunto de archivos. Operaciones SET enviadas a la memoria caché durante la reescritura se anexan al segundo conjunto de archivos.

Si se produce un error durante una reescritura, se almacena temporalmente una copia de seguridad. La copia de seguridad se elimina rápidamente una vez finalizada la reescritura. Si la eliminación temporal está activada para la cuenta de almacenamiento, se aplica la configuración de la eliminación temporal y las copias de seguridad existentes siguen residiendo en el estado de eliminación temporal.

¿Tener excepciones de firewall en la cuenta de almacenamiento afecta a la persistencia del almacenamiento?

Sí. Para la persistencia en el nivel Premium, el uso de la configuración del firewall en la cuenta de almacenamiento puede impedir que la característica de persistencia funcione.

Para comprobar si hay errores en los datos persistentes, vea la métrica Errores. Esta métrica indica si la memoria caché no puede conservar los datos debido a restricciones de firewall en la cuenta de almacenamiento u otros problemas.

Para usar la persistencia de datos con una cuenta de almacenamiento que tenga un firewall configurado, use la autenticación basada en identidad administrada para conectarse al almacenamiento. El uso de la identidad administrada agrega la instancia de caché a la lista de servicios de confianza, lo que facilita la aplicación de excepciones de firewall. Si autoriza el acceso a la cuenta de almacenamiento mediante una clave en lugar de una identidad administrada, configurar excepciones en el firewall en la cuenta de almacenamiento tiende a interrumpir el proceso de persistencia.

¿Puedo tener habilitada la persistencia de AOF si tengo más de una réplica?

Con el nivel Premium, no puede usar la persistencia de AOF con varias réplicas. En los niveles Enterprise y Enterprise Flash, la arquitectura de réplica es más complicada, pero la persistencia de AOF se admite cuando se usan cachés empresariales en implementaciones con redundancia de zona.

¿Cómo comprobar si la eliminación temporal está habilitada en mi cuenta de almacenamiento?

En Azure Portal, seleccione la cuenta de almacenamiento que usa la memoria caché para la persistencia y seleccione Protección de datos en Administración de datos en el menú de navegación izquierdo. En la página Protección de datos, compruebe si Habilitar la eliminación suave para blobs está activada. Para más información sobre la eliminación temporal en cuentas de Azure Storage, consulte Habilitación de la eliminación temporal para blobs.

¿Puedo usar una cuenta de almacenamiento en una suscripción diferente de la que se encuentra mi caché?

Puede elegir una cuenta de almacenamiento en otra suscripción solo si usa la identidad administrada como método de autenticación de la cuenta de almacenamiento.

Contenido relacionado

Más información sobre las características de Azure Cache for Redis.