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 ofrece funciones de replicación, conmutación por error y alta disponibilidad para proteger sus bases de datos y sus datos frente al mantenimiento de la infraestructura, las actualizaciones y algunos fallos. Las implementaciones contienen un clúster con tres miembros de datos: un líder y dos réplicas. Las réplicas se mantienen actualizadas mediante la replicación asíncrona. Todos los miembros contienen una copia de los datos, donde se utiliza Orchestrator para manejar las migraciones tras error. El líder y las réplicas siempre se encuentran en zonas diferentes de una región multizona. Si el líder se vuelve inaccesible o se encuentra con un problema crítico, el servicio primero intenta recuperar automáticamente el líder existente. Si no se puede recuperar el líder, se realiza una conmutación por error y se promueve una réplica a líder, una nueva réplica se vuelve a unir al clúster como réplica y el clúster continúa funcionando con normalidad. 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 las ventajas e inconvenientes asociados con la replicación asíncrona.
Aunque la versión 8.0 utiliza la replicación semisíncrona y la versión 8.4 introduce la tecnología asíncrona, los comportamientos básicos de alta disponibilidad y recuperación ante desastres permanecen fundamentalmente inalterados.
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 suelen ser operaciones en las que no se pierden datos y que dan lugar al restablecimiento de las conexiones activas. Hay un periodo de hasta 15 segundos en el que las reconexiones pueden fallar. En ocasiones, pueden producirse conmutaciones de emergencia no planificadas debido a acontecimientos imprevistos en el entorno operativo. Esto puede tardar hasta 2 minutos, ya que la instancia puede tardar un tiempo en asignar un nodo operativo como líder. 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 |
|---|---|---|
| Comportamiento de conmutación por error | Estándar en todos los clústeres y resistente frente al fallo de una zona o de un único miembro. Si el líder se vuelve inestable o inaccesible, el servicio intenta recuperarlo automáticamente. Si no se puede recuperar el líder, se realiza una conmutación por error y se promueve una réplica para restaurar la disponibilidad de escritura. | Para minimizar el retraso de réplica entre el líder y las réplicas, siga las prácticas recomendadas, como la lógica de reintento, la gestión de conexiones y la implementación de claves primarias. |
| Número de miembros | Un despliegue de tres miembros. Un clúster de tres miembros puede recuperarse de un único fallo de una instancia o zona, con un posible retraso en 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 por error (#mysql-alta disponibilidad). 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 se realizan como parte de las operaciones habituales. Si se pierden ambas réplicas, las escrituras en el líder se bloquean, ya que el proceso de replicación semisincrónica no tiene ningún seguidor. Para más información, consulte Replicación semisíncrona. Esta situación provoca, en ocasiones, breves periodos en los que la 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. Si tienes periodos de más de un minuto sin conexión, abre un ticket de asistencia con los detalles para que podamos investigarlo.
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 establecer una nueva conexión dará lugar a 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 este 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 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.