Visión general de la alta disponibilidad y la recuperación tras desastre para Databases for MongoDB
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. En el caso de los servicios, la disponibilidad se define en el Acuerdo de Nivel de Servicio. La disponibilidad incluye tanto los eventos planificados como los no planificados, como el mantenimiento, los fallos y las catástrofes. (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 MongoDB es un servicio regional que cumple los Objetivos de Nivel de Servicio(SLO ) definidos con los planes Standard y Enterprise. Para más información, véase Acuerdo de nivel de servicio(SLA). Para más información sobre las regiones y centros de datos disponibles en IBM Cloud para Databases for MongoDB, consulte Disponibilidad de servicios e infraestructuras por ubicación.
Arquitectura de alta disponibilidad
Databases for MongoDB 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 tres miembros de datos: uno primario y dos secundarios. El conjunto de réplicas de dos miembros se mantiene actualizado mediante replicación asíncrona. Se utiliza un mecanismo de consenso distribuido para mantener el estado del clúster y gestionar los fallos. Si el primario no está disponible, el conjunto de réplicas elige a un secundario para que sea el primario y continúa con el funcionamiento normal. El primario antiguo se vuelve a unir al conjunto cuando está disponible. Los miembros primarios y secundarios siempre estarán en zonas diferentes de un MZR. Si un miembro falla en una zona, la nueva réplica se creará en una zona superviviente.
Funciones de alta disponibilidad
Databases for MongoDB admite las siguientes funciones de alta disponibilidad.
| Característica | Descripción |
|---|---|
| Conmutación automática | Estándar en todos los clústeres y resistente frente al fallo de una zona o de un único miembro. |
| Número de miembros | Mínimo 3 miembros. Por defecto es un despliegue estándar de tres miembros. Un clúster de tres miembros se recuperará automáticamente de un fallo de una sola instancia o zona (con pérdida de datos hasta el umbral de retardo). |
| Réplica asíncrona | Los secundarios replican las operaciones del primario y las aplican a sus conjuntos de datos de forma asíncrona. Al hacer que los conjuntos de datos de los secundarios reflejen el conjunto de datos del primario, el conjunto de réplica puede seguir funcionando a pesar del fallo de uno o más miembros. |
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 siguiente MongoDB 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. Se puede crear una nueva base de datos utilizando la función de punto en el tiempo para el plan Enterprise, si la base de datos de producción está disponible.
Funciones de recuperación en caso de catástrofe
Databases for MongoDB 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. |
| Restauración de punto en el tiempo | Cree una base de datos a partir de la producción en vivo utilizando la recuperación puntual. | Esto sólo es posible para el plan Enterprise y si la base de datos activa está disponible y el RPO (desastre) cae dentro de la ventana soportada. No es útil si el clúster de producción no está disponible. 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) | IBM proporciona una base de datos resistente a un único punto de fallo de hardware dentro de una zona, sin necesidad de configuración. |
| error de zona | Conmutación automática. Los miembros de la base de datos se distribuyen entre las zonas. La configuración de tres miembros proporcionará resistencia adicional ante fallos de varias 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.
Restauración puntual. 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. |
| Fracaso regional | Restaurar copia de seguridad. Utilice la base de datos restaurada en producción. |
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.
Las aplicaciones deben estar diseñadas de modo que gestionen las interrupciones temporales en la base de datos, implementen el manejo de errores para los mandatos anómalos de la base de datos e implementen la lógica de reintento para recuperarse de una interrupción temporal.
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.
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. La promoción de una réplica de lectura a un clúster tendrá un impacto similar, aunque las partes existentes de sólo lectura de la carga de trabajo no se verán afectadas.
Una base de datos recuperada también puede necesitar las mismas dependencias creadas por el cliente de la base de datos del desastre - asegúrese de que los siguientes y otros servicios existen 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. Consulte la documentación de las copias de seguridad de las FAQ para obtener detalles específicos sobre los procedimientos de recuperación de bases de datos.
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. Considere un script usando IBM Cloud® Code Engine- Trabajando con el productor de eventos Periodic timer(cron) para crear copias de seguridad adicionales bajo demanda para mejorar el RPO si la criticidad y el tamaño de la base de datos lo permiten.
- 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.
- Restauración de punto en el tiempo
- Verifique los procedimientos descritos anteriormente.
- Compruebe que la copia de seguridad deseada aparece en la ventana.
Para más información sobre la propiedad de responsabilidades entre el cliente y IBM Cloud para el uso de Databases for MongoDB, consulte Responsabilidades compartidas para 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 planificado, los anuncios y las notas de la versión relacionados con este servicio, consulte Seguimiento de las notificaciones y el estado. Además, revise periódicamente la Política de versiones para conocer las últimas actualizaciones sobre versiones y fechas de fin de vida útil.