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:
- Asciende la réplica entre regiones recién creada en la región principal original (R1).
- 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).
Réplicas en cascada
Cloud SQL te permite crear réplicas para pruebas ante desastres y situaciones de recuperación entre regiones. Puedes crear una réplica con la marca cascadable-replica en una región diferente a la de su instancia principal. Si hay un desastre en la región de la instancia principal, debes iniciar la conmutación por error a la réplica en cascada.
Una vez que la instancia principal original vuelva a estar en línea y funcione como una réplica en buen estado, puedes usar la operación de cambio para volver a la instancia principal original.
Una réplica en cascada tiene dos capacidades adicionales que no tienen otras réplicas de lectura:
- Puedes adjuntar réplicas de lectura adicionales (réplicas en cascada) a la réplica de lectura escalable. Cloud SQL envía el tráfico de replicación entre regiones a la réplica escalable solo una vez y, luego, la réplica escalable reenvía el tráfico a sus réplicas en la región. Esta arquitectura puede ahorrar en costos de transferencia de datos de red entre regiones cuando necesitas tener varias réplicas en otra región.
- Puedes usar la réplica de lectura con capacidad de cascada como objetivo para las operaciones de cambio y conmutación por error en situaciones de recuperación ante desastres entre regiones. Estas operaciones reconfiguran la réplica que se puede escalar para que sea la instancia primaria en un clúster.
Puedes probar la recuperación ante desastres de una de las siguientes maneras:
- Promoción de tu réplica
- Recuperación ante desastres avanzada
Recuperación ante desastres (DR) avanzada
Si usas la edición Cloud SQL Enterprise Plus, puedes aprovechar la DR avanzada. Esta simplifica la recuperación y el resguardo después de una conmutación por error interregional. Como se describe en el proceso de recuperación ante desastres, cuando realizas la DR, quitas la conexión entre la región con errores de la instancia principal antigua y la región operativa de la instancia principal nueva. Con la DR, para restablecer las conexiones a la región de implementación original y recuperar tu instancia principal anterior, debes realizar una serie de pasos de resguardo manuales.
Con la DR avanzada, cuando ocurre una falla regional, puedes invocar una conmutación por error de réplica.
Con la conmutación por error de réplicas, debes promover una réplica de lectura entre regiones similar a la recuperación ante desastres normal, excepto que asciendas la réplica de recuperación ante desastres (DR) designada.
En Cloud SQL para SQL Server, debes crear una réplica de DR mediante la creación de una réplica entre regiones de la instancia principal con la marca cascadable-replica. El ascenso de la réplica de DR es inmediato.
Además, cuando creas una instancia principal nueva o designas una réplica de DR para una instancia principal existente, Cloud SQL crea un extremo de escritura.
Un extremo de escritura es un nombre de DNS que se resuelve en la dirección IP de la instancia principal.
Cuando se promueve la réplica de DR, el extremo de escritura se actualiza para apuntar a la instancia principal recientemente promovida. Esto garantiza que todas las aplicaciones que intenten conectarse con el extremo de escritura se redireccionen a la instancia promocionada.
En lugar de quitar la instancia principal anterior, la instancia sigue siendo parte de la topología de replicación asíncrona de Cloud SQL. La instancia principal anterior (instancia A) se convierte en una réplica de su réplica de DR (instancia B) después de que esta se haya ascendido a la nueva instancia principal.
Una vez que la instancia principal (A) anterior se convierta en una réplica, puedes realizar el paso final de la DR avanzada. Puedes volver a la implementación de Cloud SQL a su estado original y restablecer la instancia principal (A) anterior a su rol previo como la instancia principal sin pérdida de datos. Para realizar este restablecimiento sin pérdida de datos de la instancia principal anterior (A), puedes usar la operación de conmutación. Cuando realizas un cambio, no hay pérdida de datos porque la instancia principal (B) permanece en modo de solo lectura hasta que su réplica de DR designada (A) se actualice con la instancia principal (B). Después de que la réplica de DR (A) haya recibido todas sus actualizaciones de replicación, la réplica de DR (A) asume el rol de la instancia principal, mientras que la instancia principal anterior (B) se reconfigura automáticamente como la réplica de DR de la instancia principal actual (A). Las instancias se devuelven a sus roles originales, lo que muestra la topología a su estado original antes de la conmutación por error de la DR y la réplica.
Durante la DR avanzada, todas las instancias involucradas en las operaciones de conmutación por error y cambio de réplica conservan sus direcciones IP.
También puedes usar la operación de cambio de la DR avanzada así puedes realizar simulacros de DR de rutina con el objetivo de probar y preparar tu topología de Cloud SQL para la conmutación por error interregional antes de que ocurra un desastre. Si ocurre un desastre real, puedes realizar la conmutación por error de réplica entre regiones que ya probaste.
Réplica de recuperación ante desastres (DR)
Como componente obligatorio de la DR avanzada, la réplica de DR tiene las siguientes características:
cascadable-replica. Para actuar como una réplica de DR, esta debe estar en una región independiente de la instancia principal.Además, para reducir el RTO después de usar la DR avanzada, te recomendamos que hagas lo siguiente:
- Configura la réplica de DR con el mismo tamaño que la instancia principal.
- Si la instancia principal tiene habilitada la alta disponibilidad, te recomendamos que también la habilites en la réplica de DR. Para ello, primero verifica que el elemento principal tenga habilitada la HA. Luego, realiza el cambio a la réplica de DR. Una vez completada la operación de cambio, habilita la alta disponibilidad en la instancia principal nueva. Luego, puedes volver a la instancia principal anterior. La réplica de DR retiene su configuración de HA incluso después de volver a ser una réplica.
Conmutación por error de la réplica
Una conmutación por error de réplica consta de los siguientes pasos:
- Antes de realizar una conmutación por error de réplica, ya asignaste una réplica de DR a la instancia principal y, posiblemente, probaste el proceso mediante un cambio.
- La región principal, que ejecuta la base de datos principal, deja de estar disponible.
- El equipo de operaciones decide que se requiere una recuperación ante desastres.
- Realizas una conmutación por error de réplica a tu réplica de DR.
- La réplica de DR se convierte en la instancia principal de inmediato y empieza a aceptar lecturas y escrituras entrantes.
- Se actualiza el extremo de escritura y empieza a apuntar a la nueva instancia principal.
- Después de que se promocione la réplica, Cloud SQL comprobará de forma periódica si la instancia principal original volvió a estar en línea. Si la instancia principal original está en línea, Cloud SQL reconfigura la instancia principal anterior como una réplica de la instancia promovida. La instancia principal anterior conserva su dirección IP.
- Si la instancia principal anterior no está activa durante 24 horas, Cloud SQL la quita de la topología de replicación para garantizar que el registro de transacciones de la instancia principal nueva y sus otras réplicas no crezca sin límites.
Después de realizar una conmutación por error de réplica, puedes realizar la operación de cambio para restablecer la instancia principal en tu región original. De esta forma, se revierte el mismo par de instancia principal y réplica de DR.
Cambiar
Un cambio consiste en los siguientes pasos:
- Antes de comenzar la operación de cambio, debes asignar una réplica de DR a la instancia principal.
- Verifica que la instancia principal esté en buen estado. Solo puedes realizar un cambio cuando la instancia principal y la réplica de DR estén en línea.
- Inicia el cambio. Cuando inicias un cambio, la replicación a la réplica de DR cambia al modo síncrono.
- La réplica de DR se pone al día con la instancia principal y cambia su estado a sincronizada.
- La réplica de DR se pone al día con la instancia principal y cambia su estado a sincronizada.
- Cuando el retraso de replicación disminuye a cero, la réplica de DR asciende como la instancia principal nueva. La instancia principal nueva empieza a aceptar conexiones entrantes, incluidas las operaciones de lectura y escritura de la aplicación.
- La instancia principal anterior se reconfigura como una réplica de lectura.
- Se actualiza el extremo de escritura y empieza a apuntar a la nueva instancia principal.
- La PITR se habilita automáticamente para la instancia principal nueva. La PITR solo es posible después de la primera copia de seguridad automática.
Extremo de escritura
El extremo de escritura es un nombre de servicio de nombre de dominio (DNS) que se resuelve en la dirección IP de la instancia principal. Este extremo redirecciona las conexiones entrantes a la instancia principal automáticamente en caso de una operación de conmutación por error de réplica o de cambio. Puedes usar el extremo de escritura en una cadena de conexión de SQL en lugar de una dirección IP. Si usas un extremo de escritura, puedes evitar tener que realizar cambios en la conexión de la aplicación cuando se produce una interrupción regional.
Un extremo de escritura requiere que la API de Cloud DNS esté habilitada en el proyecto en el que creas o tienes tu instancia principal existente de la edición de Cloud SQL Enterprise Plus.
Cuando creas una instancia de la edición de Cloud SQL Enterprise Plus con una dirección IP privada y redes autorizadas, Cloud SQL genera un extremo de escritura para la instancia automáticamente. Si ya tienes una instancia principal de la edición de Cloud SQL Enterprise Plus, Cloud SQL genera el extremo de escritura cuando creas la réplica de DR (una réplica entre regiones que creas con una marca cascadable-replica).
Si la instancia principal cambia debido a una operación de cambio o conmutación por error de réplica, Cloud SQL asigna el extremo de escritura a la réplica de DR cuando esta se convierte en la nueva instancia principal.
Para obtener más información sobre cómo obtener el extremo de escritura de la instancia, consulta Cómo ver la información de la instancia. Para obtener más información sobre el uso del extremo de escritura para conectarte a la instancia, consulta Cómo conectarse con un extremo de escritura.
¿Qué sigue?
- Usa la recuperación ante desastres (DR) avanzada.
- Explora arquitecturas de referencia, diagramas, instructivos y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.