En esta página, se presenta la recuperación ante desastres en Cloud SQL.
Descripción general
En Google Cloud, la recuperación ante desastres (DR) de base de datos trata de proporcionar continuidad del procesamiento, en especial cuando una región falla o deja de estar disponible. Cloud SQL es un servicio regional (cuando Cloud SQL se configura para la alta disponibilidad (HA)). Por lo tanto, si la región de Google Cloud que aloja una base de datos de Cloud SQL deja de estar disponible, la base de datos de Cloud SQL también dejará de estar disponible.
Para continuar con el procesamiento, debes hacer que la base de datos esté disponible en una región secundaria lo antes posible. El plan de DR requiere que configures una réplica de lectura entre regiones en Cloud SQL. También es posible realizar una conmutación por error basada en la exportación/importación o en una copia de seguridad/restablecimiento, pero este enfoque tarda más, en especial, en bases de datos grandes.
Los siguientes casos comerciales son ejemplos que garantizan una configuración de conmutación por error entre regiones:
- El Acuerdo de Nivel de Servicio de la aplicación empresarial es mayor que el Acuerdo de Nivel de Servicio de Cloud SQL regional (disponibilidad del 99.99% según la edición de Cloud SQL). Con la conmutación por error a otra región, puedes mitigar una interrupción.
- Todos los niveles de la aplicación empresarial ya son multirregionales y pueden continuar con el procesamiento cuando se genera una interrupción de la región. La configuración de conmutación por error entre regiones garantiza la disponibilidad continua de una base de datos.
- El objetivo de tiempo de recuperación (RTO) requerido y el objetivo del punto de recuperación (RPO) se expresan en minutos en lugar de horas. Conmutar por error a otra región es más rápido que recrear una base de datos.
En general, hay dos variantes para el proceso de DR:
- Una base de datos conmuta por error a una región secundaria. Una vez que una aplicación está lista y usa la base de datos, se convierte en la nueva base de datos principal y permanece en la base de datos principal.
- Una base de datos se conmuta por error a una región secundaria, pero recurre a la región principal después de que esta se recupere de su falla.
En esta descripción general de la recuperación ante desastres de la base de datos de Google Cloud SQL, se describe la segunda variante: cuando se recupera una base de datos con errores y recurre a la región principal. Esta variante del proceso de DR es especialmente relevante para bases de datos que deben ejecutarse en la región principal debido a la latencia de la red, o porque algunos recursos están disponibles solo en la región principal. Con esta variante, la base de datos se ejecuta en la región secundaria solo por la duración de la interrupción en la región principal.
Arquitectura de recuperación ante desastres
En el siguiente diagrama, se muestra la arquitectura mínima que admite la DR de base de datos para una instancia de Cloud SQL de HA:
La arquitectura funciona de la siguiente manera:
- Dos instancias de Cloud SQL (una instancia principal y una instancia en espera) se encuentran en dos zonas separadas dentro de una sola región (la región principal). Las instancias se sincronizan mediante discos persistentes regionales.
- Una instancia de Cloud SQL (la réplica de lectura entre regiones) se encuentra en una segunda región (la región secundaria). Para DR, la réplica de lectura entre regiones se configura a fin de sincronizarse (mediante la replicación asíncrona) con la instancia principal mediante una configuración de réplica de lectura.
Las instancias principal y en espera comparten el mismo disco regional, por lo que sus estados son idénticos.
Debido a que esta configuración usa la replicación asíncrona, es posible que la réplica de lectura entre regiones retrase la instancia principal. Como resultado, cuando ocurre una conmutación por error, es probable que el RPO de réplica de lectura entre regiones no sea cero.
Proceso de recuperación ante desastres (DR)
El proceso de recuperación ante desastres (DR) comienza cuando la región principal deja de estar disponible. Para reanudar el procesamiento en una región secundaria, debes activar una conmutación por error de la instancia principal ascendiendo una réplica de lectura entre regiones. El proceso de DR prepara los pasos operativos que deben realizarse, manual o automáticamente, para mitigar la falla regional y establecer una instancia principal en ejecución en una región secundaria.
En el siguiente diagrama, se muestra el proceso de DR:
El proceso de DR consta de los siguientes pasos:
- La región principal (R1), que ejecuta la instancia principal, deja de estar disponible.
- El equipo de operaciones reconoce y confirma de manera formal el desastre y decide si se requiere una conmutación por error.
- Si se requiere una conmutación por error, puedes ascender la réplica de lectura entre regiones en la región secundaria (R2) para que sea la nueva instancia principal.
- Las conexiones de clientes se vuelven a configurar para reanudar el procesamiento en la nueva instancia principal y acceder a la instancia principal en R2.
Este proceso básico vuelve a establecer la base de datos principal en funcionamiento. Sin embargo, no establece una arquitectura de DR completa, en la que la instancia principal nueva tiene una instancia en espera y una réplica de lectura entre regiones.
Un proceso completo de DR garantiza que la instancia única, la instancia principal nueva, esté habilitada para HA y tenga una réplica de lectura entre regiones. Un proceso completo de DR también proporciona un resguardo para la implementación original en la región original principal.
Conmutar por error a una región secundaria
Un proceso completo de DR extiende el proceso básico de DR mediante la adición de pasos para establecer una arquitectura de DR completa luego de una conmutación por error. En el siguiente diagrama, se muestra una arquitectura completa de DR de la base de datos después de la conmutación por error:
El proceso completo de DR de la base de datos consta de los pasos siguientes:
- La región principal (R1), que ejecuta la base de datos principal, deja de estar disponible.
- El equipo de operaciones reconoce y confirma de manera formal el desastre y decide si se requiere una conmutación por error.
- Si se requiere una conmutación por error, puedes ascender la réplica de lectura entre regiones en la región secundaria (R2) para que sea la nueva instancia principal.
- Las conexiones del cliente se vuelven a configurar para acceder y procesar en la instancia principal nueva (R2).
- Se crea y se inicia una instancia en espera nueva en R2 y se agrega a la instancia principal. La instancia en espera está en una zona diferente que la principal. Ahora, la instancia principal tiene alta disponibilidad porque se creó una instancia en espera.
- En una tercera región (R3), se crea una nueva réplica de lectura entre regiones y se adjunta a la instancia principal. En este punto, se vuelve a crear y también funciona una arquitectura completa de recuperación ante desastres.
Si la región principal original (R1) está disponible antes de implementar el paso 6, la réplica de lectura entre regiones se puede colocar en la región R1, en lugar de en la región R3, de inmediato. En este caso, el resguardo de la región principal original (R1) es menos complejo y requiere menos pasos.
Evita el estado de cerebro dividido
Una falla de la región principal (R1) no significa que la instancia principal original y su instancia en espera se cierran automáticamente, se quitan o no se puede acceder a ella de otra forma cuando R1 vuelve a estar disponible. Si R1 está disponible, los clientes pueden leer y escribir datos (incluso por accidente) en la instancia principal original. En este caso, una situación de cerebro dividido puede desarrollarse, en la que algunos clientes acceden a los datos obsoletos en la base de datos principal anterior y otros clientes acceden a los datos actualizados en la nueva base de datos principal, que conduce a problemas en tu empresa.
Para evitar una situación de cerebro dividido, debes asegurarte de que los clientes ya no puedan acceder a la instancia principal original después de que R1 esté disponible. Lo ideal es que la instancia principal original sea inaccesible antes de que los clientes comiencen a usar la instancia principal nueva y, luego, borre la instancia principal original justo después de que sea inaccesible.
Establece una copia de seguridad inicial después de la conmutación por error
Cuando promueves la réplica de lectura entre regiones para que sea la nueva instancia principal en una conmutación por error, es posible que las transacciones de la nueva instancia principal no se sincronicen por completo con las transacciones de la instancia principal original. Por lo tanto, esas transacciones no están disponibles en la instancia nueva.
Como práctica recomendada, te recomendamos que hagas una copia de seguridad inmediata de la nueva instancia principal al comienzo de la conmutación por error y antes de que los clientes accedan a la base de datos. Esta copia de seguridad representa un estado coherente y conocido en el momento de la conmutación por error. Esas copias de seguridad pueden ser importantes para fines regulatorios o a fin de recuperar a un estado conocido si los clientes tienen problemas para acceder a la nueva instancia principal.
Resguarda a la región principal original
Como se describió antes, en este instructivo, se proporcionan los pasos para volver a la región original (R1). Hay dos versiones diferentes del proceso de resguardo.
- Si creaste la réplica de lectura entre regiones nueva en una región terciaria (R3), debes crear otra réplica de lectura entre regiones (segundo) en la región principal (R1).
- Si creaste la réplica de lectura entre regiones nueva en la región principal (R1), no es necesario crear otra réplica de lectura entre regiones adicionales en R1.
Después de que exista la réplica de lectura entre regiones en R1, la instancia de Cloud SQL puede recurrir a R1. Debido a que este resguardo se activa de forma manual y no se basa en una interrupción, puedes elegir el día y la hora apropiados para esta actividad de mantenimiento.
Por lo tanto, para lograr una DR completa que tenga una réplica de lectura principal, en espera y entre regiones, necesitas dos conmutaciones por error. La primera conmutación por error se activa por la interrupción (una conmutación por error verdadera) y la segunda conmutación por error restablece la implementación inicial (un resguardo o cambio).
El resguardo de la región principal original (R1) consta de los siguientes pasos:
- Promociona la réplica entre regiones recién creada en la región principal original (R1).
- Si la instancia ascendida no se creó originalmente como una réplica con alta disponibilidad, habilitala en la instancia para obtener protección contra fallas zonales.
- Reconfigura tus aplicaciones para conectarte a la nueva instancia principal.
- Crea una réplica entre regiones para la instancia principal nueva en la región de DR (R2).
- (Opcional) Para evitar ejecutar varias instancias principales independientes, limpia la instancia principal en la región de DR (R2).