Visión general de la alta disponibilidad y la recuperación tras desastre para Databases for Redis
La alta disponibilidadCapacidad de un servicio o carga de trabajo para soportar fallos y seguir proporcionando capacidad de procesamiento de acuerdo con algún nivel de servicio predefinido. (HA) es la capacidad de un servicio de permanecer operativo y accesible ante fallos inesperados. La recuperación de desastresCapacidad de un servicio o carga de trabajo para recuperarse de incidentes graves poco frecuentes y fallos a gran escala, como la interrupción del servicio. Esto incluye un desastre físico que afecte a toda una región, la corrupción de una base de datos o la pérdida de un servicio que contribuya a una carga de trabajo. El impacto supera la capacidad del diseño de alta disponibilidad para gestionarlo. es el proceso de recuperación de la instancia de servicio a un estado de funcionamiento.
Databases for Redis es un servicio regional que cumple los Objetivos de Nivel de Servicio(OEN ) definidos con el plan estándar.
Para más información sobre las regiones y centros de datos disponibles en IBM Cloud para Databases for Redis, consulte Disponibilidad de servicios e infraestructuras por ubicación.
Arquitectura de alta disponibilidad
Databases for Redis proporciona funciones de replicación, conmutación por error y alta disponibilidad para proteger sus bases de datos y datos del mantenimiento de la infraestructura, las actualizaciones y algunos fallos. Los despliegues contienen un clúster con dos miembros de datos en una configuración de primario más réplica. La réplica se mantiene actualizada mediante replicación asíncrona. La alta disponibilidad se controla y gestiona con tres centinelas Redis
Por defecto, la persistencia de datos está activada en todas las implantaciones y sus datos se escriben en disco. Databases for Redis utiliza una combinación de instantáneas RDB y AOF(Append Only File) para persistir los datos en disco. El intervalo para que Databases for Redis escriba en disco (fsync) se establece en una vez cada segundo para equilibrar durabilidad y rendimiento.
Puede desactivar la persistencia de datos, lo cual es útil para configurar Redis como una memoria caché.
Funciones de alta disponibilidad
Databases for Redis admite las siguientes funciones de alta disponibilidad:
| Característica | Descripción | Consideración |
|---|---|---|
| Conmutación automática | De serie en todos los clústeres y resistente a fallos de zona o de un único miembro | |
| Número de miembros | Mínimo - 2 miembros. Por defecto es un clúster estándar de dos miembros en una configuración de primario y réplica. Un clúster de dos miembros se recuperará automáticamente de un fallo de una sola instancia o zona (con pérdida de datos hasta el umbral de retardo). | Tres nodos Sentinel para supervisar la salud del clúster y coordinar las conmutaciones por error. |
| Réplica asíncrona | Permite la replicación de primario a réplica sin bloquear la ruta de escritura, garantizando una alta disponibilidad con baja latencia. Consulte Replicación asíncrona. | Puede provocar la pérdida de datos durante la conmutación por error debido al retraso en la replicación (RPO > 0). No es adecuado cuando se requiere una durabilidad estricta de los datos. |
Replicación asíncrona para Databases for Redis
Por defecto, Databases for Redis utiliza la replicación asíncrona, en la que el nodo primario no espera a que la réplica confirme las escrituras. Esto garantiza una baja latencia y un alto rendimiento, lo que hace que Databases for Redis sea ideal para el almacenamiento en caché y las cargas de trabajo sensibles al rendimiento. Sin embargo, en caso de fallo del primario, el retraso en la replicación puede provocar la pérdida de datos, ya que la réplica puede no haber recibido las escrituras más recientes.
Databases for Redis la replicación está diseñada para una alta disponibilidad, no para una durabilidad estricta. La conmutación por error se activa automáticamente si el primario se vuelve inalcanzable, promoviendo la réplica a líder. Dado que la replicación es asíncrona, algunas escrituras comprometidas pueden perderse durante este proceso. Este retraso en la replicación define el objetivo de punto de recuperación (RPO) de las implantaciones de Databases for Redis.
Para reducir el riesgo de pérdida de datos, Databases for Redis admite mecanismos de persistencia como las instantáneas RDB y AOF(Append Only File), que escriben los datos en el disco independientemente del proceso de replicación. Deben configurarse cuidadosamente en función de los requisitos de la carga de trabajo.
La replicación asíncrona en Databases for Redis garantiza un rendimiento rápido, pero no elimina la posibilidad de pérdida de datos durante los eventos de conmutación por error. Se recomienda para cargas de trabajo en las que la velocidad y la disponibilidad pesan más que la coherencia estricta de los datos.
Arquitectura de recuperación en caso de catástrofe
La estrategia general para la recuperación en caso de desastre consiste en crear una nueva base de datos, como la que se muestra a continuación en Restore. El contenido de la nueva base de datos puede ser una copia de seguridad
de la base de datos de origen creada antes de la catástrofe.
Funciones de recuperación en caso de catástrofe
Databases for Redis admite las siguientes funciones de recuperación ante desastres:
| Característica | Descripción | Consideración |
|---|---|---|
| Restauración de copias de seguridad | Cree una base de datos a partir de una copia de seguridad creada previamente; consulte Gestión de copias de seguridad en Cloud Databases. | Las nuevas cadenas de conexión para la base de datos restaurada deben referenciarse en toda la carga de trabajo. |
Planificación de la recuperación tras desastre
Las medidas de recuperación en caso de catástrofe deben practicarse con regularidad. Cuando elabore su plan, tenga en cuenta los siguientes escenarios de fracaso y resoluciones.
| Anomalía | Resolución |
|---|---|
| Fallo de hardware (punto único) | (Ejemplo) IBM proporciona una base de datos resistente a un único punto de fallo de hardware dentro de una zona. No requiere configuración por parte del cliente. |
| error de zona | Conmutación automática. Los miembros de la base de datos se distribuyen entre las zonas. |
| Corrupción de datos | Restaurar copia de seguridad. Utilice la base de datos restaurada en producción o para datos de origen para corregir la corrupción en la base de datos restaurada. |
Alta disponibilidad a nivel de aplicación
Las aplicaciones que se comunican a través de redes y servicios en la nube están sujetas a errores de conexión transitorios. Desea diseñar las aplicaciones de modo que reintenten las conexiones cuando los errores están causados por una pérdida temporal de la conectividad con el despliegue o con IBM Cloud.
Dado que Databases for Redis es un servicio gestionado, las actualizaciones periódicas y el mantenimiento de la base de datos forman parte de las operaciones normales. Esto puede hacer que, ocasionalmente durante intervalos cortos, la base de datos no esté disponible. También puede hacer que la base de datos desencadene una migración tras error de forma ordenada, vuelva a intentarlo y vuelva a conectarse. La base de datos tarda poco tiempo en determinar qué miembro es una réplica y cuál es el líder, por lo que también puede darse una breve interrupción de la conexión. La migración tras error suele tardar menos de 30 segundos.
Sus aplicaciones deben estar diseñadas para gestionar interrupciones temporales de la base de datos, implementar el tratamiento de errores para comandos fallidos de la base de datos e implementar la lógica de reintento para recuperarse de una interrupción temporal interruption.Use IOREDIS, NODEREDIS o cualquier otro paquete de su elección para garantizar la continuidad de su application.For más información, consulte la entrada de blog Detección y tratamiento de errores con Redis.
No se esperan faltas de disponibilidad de base de datos ni interrupciones de conexión de varios minutos. Abre un caso de soporte con detalles si tienes periodos de más de un minuto sin conectividad para que podamos investigar.
límites de conexiones
Databases for Redis establece un máximo de 10.000 conexiones simultáneas por implantación. Este límite garantiza la estabilidad del rendimiento y la gestión de recursos en su entorno Redis. Sin embargo, no todas las 10.000 conexiones están disponibles para los clientes: una parte se reserva internamente para operaciones que mantienen el estado y la integridad del despliegue. Una vez alcanzado el límite de conexiones, cualquier intento de iniciar una nueva conexión produce un error. Para más información, consulte Gestión de conexiones Redis.
Sus responsabilidades en HA y DR
La siguiente información puede ayudarle a crear y practicar continuamente su plan de HA y DR.
Cuando se restaura una base de datos a partir de copias de seguridad o se utiliza la restauración puntual, se crea una nueva base de datos con nuevas cadenas de conexión. Las cargas de trabajo y los procesos existentes deben ajustarse para consumir las nuevas cadenas de conexión.
Una base de datos recuperada también puede necesitar las mismas dependencias creadas por el cliente de la base de datos siniestrada. Garantizar la existencia de este y otros servicios en la región recuperada:
- IBM® Key Protect for IBM Cloud®
Recuerda que al borrar una base de datos también se borran sus copias de seguridad asociadas. Sin embargo, las bases de datos borradas pueden recuperarse en un plazo limitado. Para más información, consulte Preguntas frecuentes sobre copias de seguridad.
No es posible copiar copias de seguridad fuera de IBM Cloud, por lo que se recomienda utilizar las herramientas específicas de la base de datos para realizar copias de seguridad adicionales. Puede ser necesario para recuperarse de la eliminación maliciosa de una base de datos seguida de una recuperación-eliminación de una base de datos. Una gestión cuidadosa del acceso IAM a las bases de datos puede ayudar a reducir la exposición a este problema.
La siguiente lista de comprobación asociada a cada característica puede ayudarle a crear y poner en práctica su plan.
- Restauración de copias de seguridad
- Verificar que las copias de seguridad están disponibles con la frecuencia deseada para cumplir los requisitos de RPO. La gestión de las copias de seguridad de Cloud Databases documenta la frecuencia de las copias de seguridad.
- Existen algunas restricciones en las regiones de restauración de bases de datos - verifique que sus objetivos de restauración pueden ser alcanzados leyendo la gestión de copias de seguridad Cloud Databases.
- Compruebe que el periodo de conservación de las copias de seguridad cumple sus requisitos.
- Programe restauraciones de prueba con regularidad para verificar que los tiempos de restauración reales cumplen el RTO definido. Recuerda que el tamaño de la base de datos influye significativamente en el tiempo de restauración. Considera estrategias para minimizar los tiempos de restauración, como dividir las bases de datos grandes en unidades más pequeñas y manejables y purgar los datos no utilizados.
- Verifique el servicio Key Protect.
Para saber más sobre la propiedad de la responsabilidad entre el cliente y IBM Cloud por el uso de Databases for Redis, consulte Responsabilidades compartidas en Cloud Databases.
Manténgase informado: IBM notificaciones
Las actualizaciones que afectan a las cargas de trabajo de los clientes se comunican a través de las notificaciones de IBM Cloud. Para mantenerse informado sobre el mantenimiento previsto, los anuncios y las notas de la versión relacionadas con este servicio, consulte la página de notificaciones y estado de la supervisión. Además, revise periódicamente la página Política de versiones para conocer las últimas actualizaciones sobre versiones y fechas de fin de vida útil.