Acerca de la persistencia de RDB

En esta página se ofrece una descripción general de la persistencia de RDB (base de datos de Redis) en Memorystore para Redis Cluster.

Para saber cómo habilitar, inhabilitar y monitorizar la persistencia de RDB, consulta Gestionar la persistencia.

Para obtener información sobre las prácticas recomendadas para la persistencia de RDB, consulta Prácticas recomendadas de persistencia.

La función de persistencia de RDB protege tus datos guardando capturas de tus datos en un almacenamiento duradero. Puedes elegir la frecuencia de estas copias seleccionando un intervalo de copias que va desde un mínimo de 1 hora hasta un máximo de 24 horas. Si se producen fallos en los nodos, los datos se recuperan incluso en los casos en los que no es posible realizar una conmutación por error.

Los nodos con réplicas priorizan la recuperación de datos de la réplica. Sin embargo, si tanto la principal como la réplica fallan simultáneamente, los nodos se recuperan a partir de la instantánea más reciente.

La persistencia de RDB no añade ningún coste adicional a la facturación de tu instancia. Esta función es ideal para casos prácticos en los que se acepta un pequeño grado de obsolescencia de los datos después de la recuperación. Como Memorystore usa capturas para la recuperación automática, las capturas no están disponibles para las restauraciones manuales. También debes tener en cuenta que solo se conserva la instantánea correcta más reciente.

Memorystore for Redis Cluster también admite la persistencia AOF, pero debes elegir entre el modo de persistencia AOF o RDB, ya que no se pueden habilitar ambos al mismo tiempo. Para obtener información sobre cómo elegir entre los dos modos de persistencia, consulta la descripción general de la persistencia. Para conseguir la mejor disponibilidad posible, te recomendamos que uses una instancia de alta disponibilidad además de habilitar la persistencia.

Programación de capturas

La programación de las capturas se determina mediante dos ajustes: la hora de inicio de la captura y el intervalo de la captura. Los intervalos que puedes definir son 1h, 6h, 12h y 24h. Por ejemplo, si defines la hora de inicio a las 4:00 y el intervalo en una hora, las instantáneas empezarán a las 4:00 del día en que se habiliten y continuarán cada hora a partir de ese momento.

Las programaciones de las copias de seguridad se evalúan en la zona horaria UTC, por lo que las zonas horarias locales con cambios al horario de verano experimentarán ajustes en la programación. Por ejemplo, al principio y al final del horario de verano en EE. UU., las horas de inicio locales de tus trabajos programados de creación de copias se adelantan o se retrasan una hora si tu zona horaria respeta los cambios del horario de verano.

Pausar las capturas

Puede que te encuentres en situaciones en las que quieras pausar temporalmente la creación de copias de seguridad de RDB durante un periodo determinado. Esto puede deberse a que se quiere asegurar que no haya repercusiones en el rendimiento durante eventos críticos o a que se quieren inhabilitar temporalmente las copias para solucionar problemas de rendimiento.

Para pausar las capturas, debes definir una hora de inicio posterior a la actual. Si lo haces, se conservará la última instantánea y se usará en caso de recuperación. Para reanudar las capturas, ajusta la programación de capturas para que se haga la siguiente cuando quieras. Para obtener más información sobre cómo ajustar las programaciones de capturas, consulta Ajustar el intervalo de capturas de RDB.

Comportamiento de recuperación

Los nodos de Memorystore for Redis Cluster conmutan por error a las réplicas como mecanismo de recuperación principal, en lugar de cargar desde una instantánea. Sin embargo, si un nodo falla y no se puede recuperar de una réplica, se recupera a partir de una instantánea.

Coherencia de los datos en la recuperación

Si la persistencia de RDB está habilitada, se hará todo lo posible para que las copias de seguridad se creen en el intervalo especificado. Las capturas pueden fallar por varios motivos. Si la creación de la instantánea falla de forma consecutiva en varios intervalos, la última copia de seguridad disponible puede estar obsoleta.

En el peor de los casos, la antigüedad de los datos de una recuperación a partir de una captura es la suma del intervalo especificado desde que se inició la última captura correcta y el tiempo necesario para guardar la siguiente captura en el almacenamiento. En caso de que se produzca un incidente de recuperación, utilice la métrica rdb_save_ages para ver el periodo de obsolescencia de los datos.

Tiempo de recuperación

Si un nodo falla y necesita recuperar datos de una instantánea, no estará disponible durante la recuperación. El tiempo de recuperación depende del tamaño de la instantánea.

Error de creación de la captura

Las instantáneas fallidas se vuelven a intentar inmediatamente con un tiempo de espera exponencial de entre 5 y 300 segundos. Si se producen errores consecutivos en las capturas, los datos estarán más obsoletos en caso de recuperación.

Error de recuperación

Los errores de recuperación son poco frecuentes, pero pueden producirse. Si se produce un error de recuperación, el nodo lo reintenta repetidamente hasta que se recupera correctamente.

Monitorizar capturas

Es importante monitorizar las capturas y configurar alertas para las que no se hayan podido crear. Para obtener información sobre las prácticas recomendadas de persistencia de RDB, consulta Prácticas recomendadas de persistencia de RDB. Las copias fallidas pueden indicar que los nodos están sobrecargados y que pueden seguir teniendo dificultades para recuperarse de la copia.

Para ver una lista de las métricas disponibles para monitorizar las instantáneas, consulta Métricas de persistencia.

Gestionar el impacto en el rendimiento

Para monitorizar el impacto que tiene una instantánea en el rendimiento de su instancia de Memorystore, puede consultar las métricas disponibles en Cloud Monitoring, como el uso de CPU y el uso de memoria.