Recuperación ante desastres de Cloud SQL para MySQL: Un proceso completo de conmutación por error y resguardo

---

Nota: En este documento o sección, se incluyen referencias a uno o más términos que Google considera ofensivos o irrespetuosos. Los términos se usan porque son palabras clave en el software que se describe en el documento.

En este instructivo, se describe una conmutación por error completa de recuperación ante desastres (DR) y un proceso de resguardo en Cloud SQL para MySQL mediante réplicas de lectura entre regiones.

En este instructivo, configurarás una instancia de Cloud SQL para MySQL de alta disponibilidad para DR y simula una interrupción. Luego, realizarás el proceso de DR a fin de recuperar tu implementación inicial después de que se haya resuelto la interrupción.

Importante: Este instructivo se aplica solo a la recuperación ante desastres (DR) general, que está disponible para todas las instancias de Cloud SQL para MySQL. Si usas la edición Cloud SQL Enterprise Plus, tienes la opción de usar la recuperación ante desastres (DR) avanzada. Para obtener más información sobre la DR avanzada, consulta Recuperación avanzada ante desastres y Usa la recuperación ante desastres (DR) avanzada. La DR avanzada se encuentra en Vista previa.

Este instructivo está dirigido a ingenieros, administradores y arquitectos de bases de datos.

Para leer una descripción general de cómo funciona la recuperación ante desastres de SQL, consulta Información sobre la recuperación ante desastres en Cloud SQL.

Objetivos

• Crear una instancia Cloud SQL para MySQL de HA.
• Implementar una réplica de lectura entre regiones en Google Cloud con Cloud SQL para MySQL.
• Simula un desastre y una conmutación por error con Cloud SQL para MySQL.
• Comprende los pasos para recuperar la implementación inicial mediante un resguardo con Cloud SQL para MySQL.

Este documento se centra solo en los procesos de conmutación por error y resguardo de DR entre regiones. Para obtener información sobre un proceso de conmutación por error con alta disponibilidad de una sola región, consulta Descripción general de la configuración de HA.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• Cloud SQL

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices las tareas que se describen en este documento, puedes borrar los recursos que creaste para evitar que continúe la facturación. Para obtener más información, consulta Cómo realizar una limpieza.

Antes de comenzar

1. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.

   Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

   Ir al selector de proyectos

2. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

3. En la consola de Google Cloud, activa Cloud Shell.

   Activar Cloud Shell

Fase 1: Configura una instancia de base de datos de alta disponibilidad para DR

Las siguientes fases (de 1 a 3) te guiarán a través de un proceso de conmutación por error y resguardo completo. Para ejecutar todos los comandos, usa el comando gcloud en Cloud Shell. Para simplificar el proceso, en el instructivo se usa la configuración predeterminada cuando sea posible (por ejemplo, la versión predeterminada de Cloud SQL). En tu entorno de producción, puedes agregar otras opciones de configuración.

Configure las variables de entorno

En esta sección, se proporcionan ejemplos de variables de entorno que definen los distintos nombres y regiones que se requieren para los comandos que ejecutarás en este instructivo. Puedes ajustar estas variables de ejemplo para que se adapten a tus necesidades.

En las siguientes tablas, se describen los nombres de instancias, sus funciones y sus regiones de implementación para cada fase del proceso de DR y resguardo de este instructivo. También puedes proporcionar tus propios nombres y regiones.

Fase inicial
Nombre de la instancia	Función	Región
instance-1	Principal	us-west1
instance-2	En suspensión	us-west1
instance-3	Réplica de lectura entre regiones	us-west2

Fase de desastre
Nombre de la instancia	Función	Región
instance-3	Principal	us-west2
instance-4	En suspensión	us-west2
instance-5	Réplica de lectura entre regiones	us-west3
instance-6	Réplica de lectura entre regiones	us-west1

Fase de resguardo (final)
Nombre de la instancia	Función	Región
instance-6	Principal	us-west1
instance-7	En suspensión	us-west1
instance-8	Réplica de lectura entre regiones	us-west2

Nota: No uses los nombres instance-2 instance-4, instance-7 para crear las instancias de Cloud SQL. Esas instancias se crearán de forma automática cuando se habilite la alta disponibilidad en instance-1, instance-3 y en instance-6. El motivo por el que se proporcionan los nombres adicionales es que puedes hacer referencia a las instancias de alta disponibilidad creadas automáticamente y tener un esquema de nombres coherente que corresponda a las instancias de Cloud SQL reales que se crean.

Los nombres de instancia en las tablas anteriores no están codificados con sus funciones. En una situación de DR, la función de una instancia puede cambiar, por ejemplo, una réplica puede convertirse en la principal. Si el nombre de la instancia principal nueva contiene la palabra replica, puede haber conflictos y confusión. Por lo tanto, recomendamos que no codifiques nombres de instancias con la función que realicen.

En las tablas anteriores, se enumeran los nombres de instancias en espera. Aunque en este instructivo no se produce una conmutación por error de HA, en el instructivo se incluyen los nombres de instancias en espera para su finalización.

La fase de resguardo vuelve a crear la implementación original de la fase inicial en las mismas regiones originales. Sin embargo, en una reserva, los nombres de las instancias deben cambiar porque los nombres originales no están disponibles de inmediato, incluso después de que se borre la instancia original. Para admitir la creación rápida de instancias en la fase de resguardo, debes usar nombres de instancia que no coincidan con los nombres usados en la fase inicial.

• En Cloud Shell, configura las variables de entorno que se basen en las especificaciones de las tablas anteriores:

  export primary_name=instance-1
  export primary_tier=db-n1-standard-2
  export primary_region=us-west1
  export primary_root_password=my-root-password
  export primary_backup_start_time=22:00
  export cross_region_replica_name=instance-3
  export cross_region_replica_region=us-west2
  

  Si deseas usar un nivel diferente para la instancia principal, enumera los niveles disponibles y, luego, asigna un valor diferente a primary_tier:

  gcloud sql tiers list
  

  Para obtener una lista de regiones donde puedes implementar Cloud SQL, consulta Configuración de instancias.

Crea una instancia de base de datos principal

1. En Cloud Shell, crea una sola instancia de Cloud SQL:

   gcloud sql instances create $primary_name \
       --tier=$primary_tier \
       --region=$primary_region
   

   El comando gcloud se detiene hasta que se crea la instancia.

2. Configura la contraseña raíz:

   gcloud sql users set-password root \
       --host=% \
       --instance $primary_name \
       --password $primary_root_password
   

Crea una base de datos principal

1. En Cloud Shell, accede a la shell de MySQL y escribe la contraseña raíz en el mensaje:

   gcloud sql connect $primary_name --user=root
   

2. En el cuadro de MySQL, crea una base de datos y sube datos de prueba:

   CREATE DATABASE guestbook;
   
   USE guestbook;
   
   CREATE TABLE entries (guestName VARCHAR(255), content VARCHAR(255), entryID INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(entryID));
   
   INSERT INTO entries (guestName, content) values ("first guest", "I got here!");
   INSERT INTO entries (guestName, content) values ("second guest", "Me too!");
   

3. Verifica que los datos se hayan confirmado correctamente.

   SELECT * FROM entries;
   

   Verifica que se muestren dos filas de datos.

4. Sal de la shell de MySQL:

   exit;
   

En este punto, tienes una sola base de datos que incluye una tabla y algunos datos de prueba.

Cambia la instancia principal a una instancia de base de datos de HA

Solo puedes configurar Cloud SQL como un sistema de HA regional, no como un sistema interregional. (Configurar una réplica de lectura entre regiones es diferente a configurar Cloud SQL como un sistema interregional). Si deseas obtener más información, consulta Habilita o inhabilita la alta disponibilidad en una instancia.

• En Cloud Shell, crea una instancia de Cloud SQL habilitada para HA:

  gcloud sql instances patch $primary_name \
      --availability-type REGIONAL \
      --enable-bin-log \
      --backup-start-time=$primary_backup_start_time
  

Agrega una réplica de lectura entre regiones para la DR con actualización automática

Los siguientes pasos son suficientes para crear una réplica de lectura entre regiones en este instructivo:

1. En Cloud Shell, configura una réplica de lectura entre regiones:

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

2. (Opcional) Para verificar que la base de datos se haya replicado, en la consola de Google Cloud, ve a la página Instancias de Cloud SQL.

   Ir a Instancias

   

   La consola de Google Cloud muestra que la instancia principal (instance-1) está habilitada para la alta disponibilidad y que existe una réplica de lectura entre regiones (instance-3).

3. Mediante la misma contraseña raíz para la instancia principal, accede a la réplica de lectura entre regiones:

   gcloud sql connect $cross_region_replica_name --user=root
   

4. Cuando aparezca el cuadro de MySQL, selecciona los datos para asegurarte de que la replicación funciona:

   USE guestbook;
   
   SELECT * FROM entries;
   

5. Sal de la shell de MySQL:

   exit;
   

Si deseas obtener detalles para configurar una réplica de lectura entre regiones completa, consulta la documentación de Cloud SQL.

Para bases de datos grandes en un entorno de producción, te recomendamos que hagas una copia de seguridad de la base de datos principal y crees la réplica de lectura entre regiones a partir de la copia de seguridad. Este paso ayuda a reducir el tiempo que lleva la réplica de lectura en sincronizarse con la base de datos principal. Este proceso se describe en la siguiente sección. Sin embargo, puedes optar por omitir este paso y continuar con la Fase 2.

Agrega una réplica de lectura entre regiones según un archivo de volcado

Una forma de optimizar la creación de una réplica de lectura entre regiones es sincronizar la réplica de un estado de base de datos principal anterior y coherente, en lugar de sincronizar la instancia nueva cuando ya no pudo acceder. Esta optimización requiere la creación de un archivo de volcado que la réplica usa como estado de inicio.

Para conocer los pasos a fin de crear una réplica basada en un archivo de volcado, consulta Replica desde un servidor externo a Cloud SQL (v1.1). Este enfoque puede ser útil para bases de datos de producción grandes. Sin embargo, en este instructivo se omite este paso, ya que el conjunto de datos de prueba es lo suficientemente pequeño como para llevar a cabo una replicación completa.

Fase 2: Simula un desastre (interrupción de la región)

En esta fase, debes simular la interrupción de una región principal en una configuración de producción, ya que hace que la base de datos principal no esté disponible.

Verifica el retraso de réplica de lectura entre regiones

En los pasos siguientes, determinarás el retraso de replicación de la réplica de lectura entre regiones:

1. En la consola de Google Cloud, ve a la página Instancias de Cloud SQL.

   Ir a Instancias

2. Haz clic en la réplica de lectura (instance-3).

3. En la lista desplegable de métricas, haz clic en Retraso de la replicación:

   

   La métrica cambia a Retraso de la replicación. El grafo no muestra retrasos:

   

Lo ideal es que el retraso de la replicación sea cero cuando se produce una interrupción de la región principal, ya que una demora de cero garantiza que todas las transacciones se repliquen. Si no es cero, es posible que algunas transacciones no se repliquen. En este caso, la réplica de lectura entre regiones no contendrá todas las transacciones confirmadas en la instancia principal.

Haz que la instancia principal no esté disponible

En los siguientes pasos, debes simular un desastre mediante la detención de la instancia principal. Si se adjunta una réplica de lectura entre regiones a la instancia principal, primero debes desconectar la réplica; de lo contrario, no podrás detener la instancia de Cloud SQL.

1. En Cloud Shell, quita la réplica de lectura entre regiones de la principal:

   gcloud sql instances patch $cross_region_replica_name \
       --no-enable-database-replication
   

   Cuando se te solicite, acepta la opción para continuar.

2. Detén la instancia de la base de datos principal:

   gcloud sql instances patch $primary_name --activation-policy NEVER
   

Implementa la DR

1. En Cloud Shell, promueve la réplica de lectura entre regiones a una instancia independiente:

   gcloud sql instances promote-replica $cross_region_replica_name
   

   Cuando se te solicite, acepta la opción para continuar. La página de Instancias de Cloud SQL muestra la réplica de lectura anterior entre regiones (instance-3 ) como la instancia principal nueva y la anterior (instance-1 ) como detenida:

   

   Luego de promover la réplica de lectura entre regiones como la nueva instancia principal, la habilitas para HA. Como práctica recomendada, debes actualizar las variables de entorno con una denominación adecuada.

2. Actualice las variables de entorno:

   export former_primary_name=$primary_name
   export primary_name=$cross_region_replica_name
   export primary_tier=db-n1-standard-2
   export primary_region=$cross_region_replica_region
   export primary_root_password=my-root-password
   export primary_backup_start_time=22:00
   export cross_region_replica_name=instance-5
   export cross_region_replica_region=us-west3
   

3. Inicia la instancia principal nueva:

   gcloud sql instances patch $primary_name --activation-policy ALWAYS
   

4. Habilita la instancia principal nueva como una instancia regional de HA:

   gcloud sql instances patch $primary_name \
       --availability-type REGIONAL \
       --enable-bin-log \
       --backup-start-time=$backup_start_time
   

5. Crea una réplica de lectura entre regiones en una tercera región:

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

   En un paso anterior, estableciste la variable de entorno cross_region_replica_region en us-west3.

   Una vez que se completa la conmutación por error, la página Instancias de Cloud SQL en la consola de Google Cloud muestra que la nueva instancia principal (instance-3) está habilitada como HA y tiene una réplica de lectura entre regiones (instance-5):

   

6. Si tienes copias de seguridad regulares, sigue el proceso que se describió antes para sincronizar la versión principal nueva con la última versión de copia de seguridad (opcional).

7. Si usas un proxy de Cloud SQL, configura el proxy para que use la instancia principal nueva a fin de reanudar el procesamiento de la aplicación (opcional).

Controla una interrupción de región de corta duración

Es posible que la interrupción que activa una conmutación por error se resuelva antes de que se complete la conmutación por error. En este caso, tendría sentido cancelar el proceso de conmutación por error y seguir usando la instancia principal de Cloud SQL original en la región donde se produjo la interrupción.

Según el estado específico del proceso de conmutación por error, la réplica de lectura entre regiones ya podría haberse promocionado. En este caso, debes borrarlo y volver a crear una réplica de lectura entre regiones.

Borra la instancia principal original para evitar una situación de cerebro dividido

Para evitar una situación de cerebro dividido, debes borrar la principal original (o hacer que sea inaccesible para los clientes de la base de datos).

Después de una conmutación por error, una situación de cerebro dividido puede ocurrir cuando los clientes escriben en la base de datos principal original y en la nueva base de datos principal al mismo tiempo. En este caso, el contenido de las dos bases de datos no es coherente. Después de una conmutación por error, la base de datos principal original está desactualizada y no debe recibir tráfico de lectura o escritura.

• En Cloud Shell, borra el original principal:

  gcloud sql instances delete $former_primary_name
  

  Cuando se te solicite, acepta la opción para continuar.

  En la consola de Google Cloud, la página Instancias de Cloud SQL ya no muestra la instancia principal original (instance-1) como parte de la implementación:

  

Fase 3: Implementa un resguardo

Para implementar un resguardo en tu región original (R1), una vez que esté disponible, sigue el mismo proceso que se describe en la Fase 2. Este proceso se resume de la siguiente manera:

1. Crea una segunda réplica de lectura entre regiones en la región original (R1). En este punto, la instancia principal tiene dos réplicas de lectura entre regiones: una en la región R3 y otra en la región R1.

2. Promover la réplica de lectura entre regiones en R1 como la instancia principal final.

3. Habilita la HA para la instancia principal final.

4. Crea una réplica de lectura entre regiones de la instancia principal final en us-west2.

5. Para evitar una situación de cerebro dividido, borra todas las instancias que ya no sean necesarias (la principal original y la réplica de lectura entre regiones en R3).

Como se explicó antes, se recomienda crear una copia de seguridad inicial que contenga el estado de inicio definido para la nueva base de datos principal.

La implementación final ahora tiene una instancia principal de alta disponibilidad (con el nombre instance-6) y una réplica de lectura entre regiones (con el nombre instance-8).

Comparación de las ventajas y desventajas de una DR automática y una automática

En la siguiente tabla, se analizan las ventajas y las desventajas de implementar un proceso de DR de forma manual o automática. El objetivo no es determinar un enfoque correcto frente a incorrecto, sino también proporcionar criterios con el fin ayudarte a determinar el mejor enfoque para tus necesidades.

Ejecución manual	Ejecución automática
Ventajas: Tienes control estricto sobre cada paso. Puedes ver, abordar y documentar de inmediato cualquier problema en el proceso. Puedes ver y revisar cada paso del proceso durante una conmutación por error.	Ventajas: Puedes implementar y probar los procesos de conmutación por error. La automatización ofrece la implementación más rápida y minimiza los retrasos. La implementación es independiente de los operadores humanos, su conocimiento y su disponibilidad.
Desventajas: La implementación manual de los pasos del proceso ralentiza el proceso. Los errores de escritura humana pueden introducir problemas. Por lo general, probar el proceso implica varias funciones y tiempo, lo que puede desalentar las pruebas regulares.	Desventajas: Si se produce un error inesperado, debes realizar una depuración durante la conmutación por error de producción. Si encuentras errores durante el proceso, necesitas secuencias de comandos para recoger (recuperar) en las que el proceso se detuvo. Se requiere el conocimiento suficiente de la secuencia de comandos y su implementación para comprender su comportamiento, en especial en situaciones de error.

Como práctica recomendada, te sugerimos que comiences con una implementación manual. Luego, ejecuta la implementación con regularidad (preferentemente en producción) para garantizar que el proceso manual funcione y que todos los miembros del equipo conozcan sus funciones y responsabilidades. Te recomendamos que definas tu proceso manual en un documento de proceso paso a paso. Después de cada implementación, debes confirmar o definir mejor el documento del proceso.

Después de ajustar el proceso y asegurarte de que sea confiable, determinas si deseas automatizar el proceso. Si seleccionas y, luego, implementas un proceso automatizado, debes probar el proceso de forma periódica en producción para asegurarte de que puedas implementarlo de manera confiable.

Limpia

Para evitar que se apliquen cargos a la cuenta de Google Cloud por los recursos que se usaron en este instructivo, puedes borrar el proyecto de Google Cloud que creaste para este instructivo.

Borra el proyecto

Precaución: Borrar un proyecto tiene estas consecuencias:

• Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

1. En la consola de Google Cloud, ve a la página Administrar recursos.

   Ir a Administrar recursos

2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?

• Lee sobre la recuperación ante desastres de Cloud SQL.
• Lee sobre la recuperación ante desastres para MySQL en Compute Engine.
• Obtén información sobre las arquitecturas de recuperación ante desastres para interrupciones de la infraestructura de nube.
• Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.