Visión general de la alta disponibilidad y la recuperación tras desastre para Databases for MySQL
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 MySQL es un servicio regional que cumple los Objetivos de Nivel de Servicio(OEN ) definidos con el plan estándar. Para más información, consulte el 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 MySQL, consulte Disponibilidad de servicios e infraestructuras por ubicación.
Arquitectura de alta disponibilidad
Databases for MySQL 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: un líder y dos réplicas. Todos los miembros contienen una copia de los datos, donde se utiliza Orchestrator para manejar las migraciones tras error. Si el líder se vuelve inalcanzable, el clúster inicia una conmutación por error, una réplica es promovida a líder, una nueva réplica se reincorpora al clúster como réplica, y su clúster continúa funcionando normalmente. El líder y las réplicas están siempre en zonas diferentes de un MZR. Si la réplica falla, se crea una nueva réplica. Si un miembro falla en una zona, la nueva réplica se crea en una zona superviviente.
Puede ampliar aún más la alta disponibilidad mediante el aprovisionamiento de réplicas de sólo lectura para la conmutación por error entre regiones o la descarga de lectura.
Revise la documentación de MySQL sobre técnicas de replicación para comprender las limitaciones y compensaciones asociadas a la estrategia de replicación semisíncrona.
Las cargas de trabajo que acceden mediante programación al clúster deben seguir la lógica de reintento de disponibilidad del cliente para mantener la disponibilidad.
Databases for MySQL a veces realiza conmutaciones controladas en funcionamiento normal. Estas conmutaciones son eventos sin pérdida de datos que provocan el restablecimiento de las conexiones activas. Hay un periodo de hasta 15 segundos en el que las reconexiones pueden fallar. En ocasiones, pueden producirse fallos no planificados debido a acontecimientos imprevistos en el entorno operativo. Pueden tardar hasta 45 segundos, pero generalmente menos de 30 segundos. El mantenimiento del servicio, por ejemplo, desencadena una conmutación por error controlada.
Funciones de alta disponibilidad
Databases for MySQL admite las siguientes funciones de alta disponibilidad:
| Característica | Descripción | Consideració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 | Un despliegue de tres miembros. Un clúster de tres miembros se recuperará automáticamente de un único fallo de una instancia o zona, con la posibilidad de que se produzca un retraso de los datos durante el proceso de recuperación. Una réplica es ascendida a líder en caso de fallo, y el clúster sigue funcionando con normalidad. | |
| réplica de solo lectura | Las réplicas de sólo lectura pueden proporcionar acceso local en regiones remotas, mejorando la disponibilidad ante posibles problemas de latencia o conectividad de la red. | Todas las solicitudes de escritura deben dirigirse exclusivamente al clúster de lectura-escritura asociado a la réplica de lectura. |
Arquitectura de recuperación en caso de catástrofe
La estrategia general para la recuperación de desastres consiste en crear una nueva base de datos, como la base de datos 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 si la base de datos de producción está disponible.
Funciones de recuperación en caso de catástrofe
Databases for MySQL admite las siguientes funciones de recuperación ante desastres:
| Característica | Descripción | Consideración |
|---|---|---|
| Restauración de copias de seguridad | Crear una base de datos a partir de una copia de seguridad creada previamente. Para obtener más información, 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 si la base de datos activa está disponible y el RPO (desastre) entra 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. |
| Promover la réplica de lectura | Cree una réplica de sólo lectura cuando planifique un desastre en la misma región o en una región remota. Promover la réplica de sólo lectura para recuperarse de un desastre. | La réplica de lectura creada previamente debe estar 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 por error (#mysql-high-availability). 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.
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.
Promover la réplica de lectura. Promover una réplica de sólo lectura a una base de datos de lectura/escritura. Utilizar 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.
Dado que Databases for MySQL es un servicio gestionado, las actualizaciones periódicas y el mantenimiento de la base de datos forman parte de las operaciones normales. Si se pierden ambas réplicas, las escrituras en el líder se cuelgan, debido a que el proceso de replicación semisíncrona no tiene un seguidor. Para más información, consulte Replicación semisíncrona. Este escenario ocasiona ocasionalmente intervalos cortos en los que su base de datos no está disponible. También puede hacer que la base de datos desencadene una migración tras error, 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. Para minimizar las interrupciones, las actualizaciones se aplican primero a las réplicas y después al líder.
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.
límites de conexiones
Databases for MySQL establece el número máximo de conexiones a la base de datos MySQL en 200. Deje algunas conexiones disponibles, ya que algunas se reservan internamente para mantener el estado y la integridad de la base de datos. Una vez alcanzado el límite de conexiones, cualquier intento de iniciar una nueva conexión produce un error. Para evitar saturar despliegue con conexiones, utilice agrupación de conexiones o reduzca el despliegue y aumente el límite de conexiones. Para más información, consulte Gestión de conexiones MySQL.
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 estos y otros servicios existen en la región recuperada:
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
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 las Preguntas frecuentes sobre copias de seguridad para obtener información específica 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. Para obtener más información, consulte Gestión de copias de seguridad en Cloud Databases. 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. Sin embargo, dadas las capacidades de MySQL's PITR, evalúe cuidadosamente la necesidad de copias de seguridad adicionales.
- 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.
- Promover la réplica de lectura
- Compruebe que existe una réplica de lectura en la región de recuperación.
- Practique el proceso de promoción: cree una réplica de lectura temporal en la región deseada. La réplica temporal puede ser promovida a lectura/escritura y algunas pruebas realizadas con poco impacto en la producción.
Para saber más sobre la propiedad de la responsabilidad entre el cliente y IBM Cloud por el uso de Databases for MySQL, 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.