Compartir vía


Configurar la persistencia de datos para una instancia de Azure Managed Redis (versión preliminar)

La persistencia de Redis te permite persistir los datos almacenados en la instancia de caché. Si hay una falla de hardware, la instancia de caché se rehidrata con datos del archivo de persistencia cuando vuelve a estar en línea. La capacidad de conservar datos es una forma importante de aumentar la durabilidad de una instancia de caché porque todos los datos de caché se almacenan en la memoria. La pérdida de datos es posible si ocurre una falla cuando los nodos de caché están inactivos. La persistencia debe ser una parte clave de su estrategia de alta disponibilidad y recuperación ante desastres con Azure Managed Redis (versión preliminar).

Importante

La persistencia de datos está pensada para proporcionar resistencia ante fallos inesperados del nodo Redis, pero no es una función de copia de seguridad de datos ni de recuperación puntual (PITR). Si los datos dañados se escriben en la instancia de Redis, estos también se conservarán. Para hacer copias de seguridad de su instancia de Redis, utilice la característica de exportación.

Ámbito de disponibilidad

Nivel Memoria optimizada, equilibrada, optimizado para proceso Optimizado para flash
Disponible

Tipos de persistencia de datos en Redis

Tiene dos opciones para la persistencia con Azure Managed Redis: el formato de Base de datos Redis (RDB) y el formato Anexar solo archivo (AOF):

  • Persistencia RDB: cuando utiliza la persistencia RDB, Azure Managed Redis persiste una instantánea de su caché en formato binario. La instantánea se guarda en un disco administrado montado en la instancia de Redis. La frecuencia de copia de seguridad configurable determina la frecuencia con la que se conserva la instantánea. Si se produce un evento catastrófico que deshabilita tanto el primario como la réplica, la caché se reconstruye automáticamente utilizando la instantánea más reciente. Más información sobre las ventajas y desventajas de la persistencia de RDB.
  • Persistencia AOF: cuando se utiliza la persistencia AOF, Azure Managed Redis guarda cada operación de escritura en un registro. El registro se guarda una vez por segundo en un disco administrado montado en la instancia de Redis. Si ocurre un evento catastrófico que deshabilita las cachés principal y de réplica, la caché se reconstruye automáticamente mediante las operaciones de escritura almacenadas. Más información sobre las ventajas y desventajas de la persistencia de AOF.

Importante

Las funciones de persistencia de Azure Managed Redis están pensadas para restaurar datos automáticamente en la misma caché tras una pérdida de datos. Los usuarios no pueden acceder a los archivos de datos persistentes RDB/AOF ni importarlos a una caché nueva o existente. Para mover datos entre cachés, usa la función Importar y exportar. Para obtener más información, consulte Importar y exportar datos en Azure Managed Redis.

Para generar copias de seguridad de los datos que pueden agregarse a una nueva caché, puede escribir scripts automatizados mediante PowerShell o Azure CLI que exporten los datos periódicamente.

Requisitos previos y limitaciones

Las características de persistencia están diseñadas para usarse para restaurar datos en la misma memoria caché después de la pérdida de datos.

  • Los archivos de datos persistentes RDB/AOF no se pueden importar a una memoria caché existente o nueva. En su lugar, usa la característica Import/Export.
  • La persistencia no es compatible con las cachés que utilizan la replicación geográfica activa.
  • El disco administrado que contiene los archivos de datos persistentes se cifra utilizando claves administradas por Microsoft (MMK) por defecto, pero también se pueden utilizar claves administradas por el cliente (CMK). Para obtener más información, consulta administrar el cifrado de datos.

Configurar la persistencia de datos mediante el Azure Portal

  1. Inicie sesión en Azure Portal y empiece a seguir las instrucciones de la Guía de inicio rápido de Azure Managed Redis.

  2. Cuando llegue a la pestaña Avanzado, seleccione las opciones RDB o AOF en la sección Persistencia de datos.

    Captura de pantalla que muestra la pestaña Avanzado de nivel Enterprise y la persistencia de datos resaltada con un cuadro rojo.

  3. Para habilitar la persistencia de RDB, seleccione RDB y configure las opciones.

    Configuración Valor sugerido Descripción
    Frecuencia de copia de seguridad Usar la lista desplegable y seleccionar un intervalo de copia de seguridad. Las opciones incluyen 60 minutos, 6 horas y 12 horas. Este intervalo empieza la cuenta atrás cuando se completa correctamente la operación de copia de seguridad anterior. Cuando finaliza, se inicia una nueva copia de seguridad.
  4. Para habilitar la persistencia de AOF, seleccione AOF. Solo hay disponible una opción de frecuencia de copia de seguridad.

  5. Termine de crear la caché siguiendo el resto de las instrucciones de la Guía de inicio rápido de Azure Managed Redis.

Nota:

Puede agregar persistencia a una instancia de Azure Managed Redis previamente creada en cualquier momento navegando a la Configuración avanzada en el menú de recursos.

Cómo configurar la persistencia de datos mediante PowerShell y la CLI de Azure

Mediante PowerShell

El comando New-AzRedisEnterpriseCache se puede utilizar para crear una nueva instancia de Azure Managed Redis utilizando la persistencia de datos. Usar los parámetros RdbPersistenceEnabled, RdbPersistenceFrequency, AofPersistenceEnabledy AofPersistenceFrequency para configurar la configuración de persistencia. Este ejemplo crea una nueva instancia de Balanced B10 utilizando la persistencia RDB con una frecuencia de una hora:

New-AzRedisEnterpriseCache -Name "MyCache" -ResourceGroupName "MyGroup" -Location "West US" -Sku "Balanced_B10" -RdbPersistenceEnabled -RdbPersistenceFrequency "1h"

Las memorias caché existentes se pueden actualizar mediante el comando Update-AzRedisEnterpriseCacheDatabase. Este ejemplo agrega persistencia RDB con frecuencia de 12 horas a una instancia existente:

Update-AzRedisEnterpriseCacheDatabase -Name "MyCache" -ResourceGroupName "MyGroup" -RdbPersistenceEnabled -RdbPersistenceFrequency "12h"

Uso de la CLI de Azure

El comando crear az redisenterprise se puede utilizar para crear una nueva instancia de Azure Managed Redis utilizando la persistencia de datos. Usar los parámetros rdb-enabled, rdb-frequency, aof-enabledy aof-frequency para configurar la configuración de persistencia. Este ejemplo crea una nueva instancia de Balanced B10 utilizando la persistencia RDB con una frecuencia de una hora:

az redisenterprise create --cluster-name "cache1" --resource-group "rg1" --location "East US" --sku "Balanced_B10" --persistence rdb-enabled=true rdb-frequency="1h" 

Las cachés existentes se pueden actualizar mediante el comando az redisenterprise database update. En este ejemplo se agrega persistencia de RDB con una frecuencia de 12 horas a una instancia de caché existente:

az redisenterprise database update --cluster-name "cache1" --resource-group "rg1" --persistence rdb-enabled=true rdb-frequency="12h" 

Administración del cifrado de datos

Dado que la persistencia de Redis crea datos en reposo, el cifrado de estos datos es una preocupación importante para muchos usuarios. En Azure Managed Redis, los datos se almacenan en un disco administrado montado en la instancia de caché. De forma predeterminada, el disco que contiene los datos de persistencia y el disco del sistema operativo se cifran con claves administradas por Microsoft. También se puede usar una clave administrada por el cliente (CMK) para controlar el cifrado de datos. Consulte Cifrado de datos en Azure Managed Redis para obtener instrucciones.

P+F de persistencia

La siguiente lista contiene respuestas a las preguntas más frecuentes sobre la persistencia de Azure Redis administrado.

Persistencia de RDB

Persistencia de AOF

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

Sí, la persistencia se puede configurar tanto en la creación de la caché como en las instancias existentes de Azure Managed Redis.

¿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?

Si habilitas la persistencia de datos, la replicación geográfica no se puede habilitar para su caché. Esto se debe a que la replicación geográfica activa proporciona una mayor capacidad de recuperación que la persistencia de datos en caso de interrupción regional. Si necesita exportar una copia de sus datos como copia de seguridad, utilice la característica de exportación.

¿Qué modelo de persistencia debería elegir?

La persistencia AOF guarda cada escritura en un registro, lo que puede tener un efecto significativo en el rendimiento. La persistencia RDB guarda copias de seguridad basadas en el intervalo de copia de seguridad configurado con un efecto mínimo en el rendimiento. Elija la persistencia de AOF si el objetivo principal es minimizar la pérdida de datos y si puede controlar un menor rendimiento de la memoria caché. Elija la persistencia de RDB si quiere mantener un rendimiento óptimo en la memoria caché pero todavía quiere un mecanismo para la recuperación de datos.

Para más información sobre el rendimiento al usar la persistencia de AOF, consulta ¿Afecta la persistencia de AOF a la productividad, la latencia o el rendimiento de la memoria caché?

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

El uso de la persistencia AOF afecta al rendimiento. AOF se ejecuta en todos los procesos primarios, por lo tanto se ve una mayor carga de CPU y de servidor para una caché con persistencia AOF que una caché idéntica sin persistencia 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. La contrapartida es que AOF requiere más proceso.

¿Qué sucede si he escalado a otro tamaño y se restaura una copia de seguridad realizada antes de la operación de escalado?

Para la persistencia de RDB y AOF:

  • Si ha escalado a un tamaño mayor, no hay ningún efecto.
  • 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 desde la última copia de seguridad, las claves se expulsarán durante el proceso de restauración. Normalmente, las claves se expulsan mediante la directiva de expulsión allkeys-lru.

¿Se me cobrará por el disco administrado que se utiliza en la persistencia de datos?

No se le cobra por el almacenamiento en disco administrado. Está incluido en el precio.

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

Sí, puedes cambiar la frecuencia de la copia de seguridad para la persistencia de RDB mediante Azure Portal, la CLI o 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 realiza un proceso de copia de seguridad en 15 minutos para completarse, la siguiente copia de seguridad no se iniciará hasta pasados 75 minutos 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.

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

Cuando el archivo AOF es lo suficientemente grande, en la memoria caché se pone en cola automáticamente una reescritura. 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 ocurren con menos frecuencia a medida que el archivo AOF se hace más grande, pero toma una cantidad significativa de tiempo cuando sucede.

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

Si el archivo AOF en el momento del escalado es grande, es de esperar que la operación de escalado tarde más de lo normal, ya que vuelve a cargar el archivo una vez finalizado el escalado.

Para más información sobre el escalado, vea ¿Qué sucede si he escalado a otro tamaño y se restaura una copia de seguridad realizada antes de la operación de escalado?

Pasos siguientes