Recuperación tras fallos de Cloud SQL para MySQL: proceso completo de conmutación por error y de recuperación

En este tutorial se describe un proceso completo de conmutación por error y de recuperación tras fallos (DR) en Cloud SQL para MySQL mediante réplicas de lectura entre regiones.

En este tutorial, configurarás una instancia de Cloud SQL para MySQL de alta disponibilidad para recuperación ante desastres y simularás una interrupción. A continuación, sigues el proceso de recuperación ante desastres para restaurar la implementación inicial una vez que se haya resuelto la interrupción.

Este tutorial está dirigido a arquitectos, administradores e ingenieros de bases de datos.

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

Objetivos

  • Crea una instancia de Cloud SQL para MySQL con alta disponibilidad.
  • Despliega 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.
  • Descubre los pasos para recuperar tu implementación inicial mediante una alternativa con Cloud SQL para MySQL.

Este documento se centra únicamente en los procesos de conmutación por error y de recuperación tras fallos entre regiones. Para obtener información sobre el proceso de conmutación por error de alta disponibilidad de una sola región, consulta el artículo Descripción general de la configuración de alta disponibilidad.

Costes

En este documento, se utilizan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Los usuarios nuevos Google Cloud pueden disfrutar de una prueba gratuita.

Cuando termines las tareas que se describen en este documento, puedes evitar que se te siga facturando eliminando los recursos que has creado. Para obtener más información, consulta la sección Limpiar.

Antes de empezar

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    Fase 1: Configurar una instancia de base de datos de alta disponibilidad para la recuperación tras desastres

    En las siguientes fases (de la 1 a la 3) se explica cómo realizar un proceso completo de conmutación por error y de recuperación. Para ejecutar todos los comandos, usa el comando gcloud en Cloud Shell. Para simplificar el proceso, en el tutorial se utilizan los ajustes predeterminados siempre que sea posible (por ejemplo, la versión predeterminada de Cloud SQL). En tu entorno de producción, puedes añadir otras configuraciones.

    Establece variables de entorno:

    En esta sección se proporcionan ejemplos de variables de entorno que definen los distintos nombres y regiones necesarios para los comandos que ejecutas en este tutorial. Puedes ajustar estas variables de ejemplo para que se adapten a tus necesidades.

    En las siguientes tablas se describen los nombres de las instancias, sus roles y sus regiones de implementación en cada fase del proceso de recuperación ante desastres y de fallback de este tutorial. También puedes proporcionar tus propios nombres y regiones.

    Fase inicial
    Nombre de la instancia Role Region
    instance-1 Principal us-west1
    instance-2 En espera us-west1
    instance-3 Réplica de lectura entre regiones us-west2
    Fase de catástrofe
    Nombre de la instancia Role Region
    instance-3 Principal us-west2
    instance-4 En espera us-west2
    instance-5 Réplica de lectura entre regiones us-west3
    instance-6 Réplica de lectura entre regiones us-west1
    Fase de respaldo (final)
    Nombre de la instancia Role Region
    instance-6 Principal us-west1
    instance-7 En espera us-west1
    instance-8 Réplica de lectura entre regiones us-west2

    Los nombres de las instancias de las tablas anteriores no están codificados con sus roles. En una situación de recuperación ante desastres, la función de una instancia puede cambiar. Por ejemplo, una réplica puede convertirse en la principal. Si el nombre del nuevo principal contiene la palabra replica, puede haber confusiones y conflictos. Por lo tanto, recomendamos no codificar los nombres de las instancias con la función o el rol que desempeñan.

    En las tablas anteriores se muestran los nombres de las instancias de espera. Aunque en este tutorial no se realiza una conmutación por error de alta disponibilidad, se incluyen los nombres de las instancias de espera para que esté completo.

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

    • En Cloud Shell, define las variables de entorno que se basan 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 quiere usar otro nivel para su instancia principal, consulte los niveles que tiene disponibles y, a continuación, asigne un valor diferente a primary_tier:

      gcloud sql tiers list

      Para ver una lista de las regiones en las que puedes implementar Cloud SQL, consulta Configuración de instancias.

    Crear 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 pausa hasta que se crea la instancia.

    2. Define la contraseña raíz:

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

    Crear una base de datos principal

    1. En Cloud Shell, inicia sesión en el shell de MySQL e introduce la contraseña raíz en la petición:

      gcloud sql connect $primary_name --user=root

    2. En el prompt 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. Comprueba que los datos se hayan confirmado correctamente:

      SELECT * FROM entries;

      Verifica que se devuelvan dos filas de datos.

    4. Sal del shell de MySQL:

      exit;

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

    Cambiar la instancia principal a una instancia de base de datos de alta disponibilidad

    Solo puedes configurar Cloud SQL como un sistema de alta disponibilidad regional, no como un sistema multirregional. (Configurar una réplica de lectura entre regiones es diferente de configurar Cloud SQL como un sistema entre regiones). Para obtener más información, consulta el artículo Habilitar e inhabilitar la alta disponibilidad en una instancia.

    • En Cloud Shell, crea una instancia de Cloud SQL con alta disponibilidad habilitada:

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

    Añadir una réplica de lectura entre regiones para la recuperación ante desastres con actualización automática

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

    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 comprobar que la base de datos se ha replicado, en laGoogle Cloud consola, ve a la página Instancias de Cloud SQL.

      Ir a Instancias

      En la página Instancias se muestran la instancia principal con alta disponibilidad y la réplica de lectura.

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

    3. Usa la misma contraseña raíz que la de la réplica de lectura entre regiones para iniciar sesión en ella:

      gcloud sql connect $cross_region_replica_name --user=root

    4. En la petición de MySQL, selecciona los datos para asegurarte de que la replicación funciona:

      USE guestbook;

SELECT * FROM entries;

    5. Sal del shell de MySQL:

      exit;

    Para obtener información sobre cómo configurar una réplica de lectura completa entre regiones, consulta la documentación de Cloud SQL.

    En el caso de las bases de datos grandes en un entorno de producción, te recomendamos que crees una copia de seguridad de la base de datos principal y que crees la réplica de lectura entre regiones a partir de esa copia. Este paso ayuda a reducir el tiempo que tarda 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 saltarte este paso y continuar con la fase 2.

    Añadir una réplica de lectura entre regiones basada en un archivo de volcado

    Una forma de optimizar la creación de una réplica de lectura entre regiones es sincronizar la réplica a partir de un estado anterior y coherente de la base de datos principal, en lugar de sincronizarla en el momento de acceder a la nueva principal. Esta optimización requiere crear un archivo de volcado que la réplica use como estado inicial.

    Para ver los pasos que debes seguir para crear una réplica basada en un archivo de volcado, consulta Replicar desde un servidor externo a Cloud SQL (versión 1.1). Este enfoque puede ser útil en el caso de bases de datos de producción de gran tamaño. Sin embargo, en este tutorial se omite este paso porque el conjunto de datos de prueba es lo suficientemente pequeño como para que se pueda replicar por completo.

    Fase 2: Simulación de un desastre (interrupción del servicio en una región)

    En esta fase, simularás una interrupción de una región principal en un entorno de producción haciendo que la base de datos principal no esté disponible.

    Comprobar la latencia de las réplicas de lectura entre regiones

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

    1. En la Google Cloud consola, 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, haga clic en Latencia de replicación:

      En la lista desplegable de métricas se muestran varias opciones, entre las que se incluye Retraso de la réplica.

      La métrica cambia a Latencia de replicación. El gráfico no muestra ningún retraso:

      El gráfico de latencia de replicación tiene opciones de visualización que van desde una hora hasta 30 días.

    Lo ideal es que la latencia de replicación sea cero cuando se produzca una interrupción en una región principal, ya que un retraso de cero garantiza que se repliquen todas las transacciones. 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 que se hayan confirmado en la principal.

    Inhabilitar la instancia principal

    En los siguientes pasos, simularás un desastre deteniendo el servidor principal. Si hay una réplica de lectura entre regiones conectada a la principal, primero debes desconectar la réplica. De lo contrario, no podrás detener la instancia de Cloud SQL.

    1. En Cloud Shell, elimina 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 pida, acepta la opción para continuar.

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

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

    Implementar la recuperación ante desastres

    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 pida, acepta la opción para continuar. En la página Instancias de Cloud SQL, se muestra la antigua réplica de lectura interregional (instance-3) como la nueva principal y la antigua principal (instance-1) como detenida:

      En la página Instancias se muestra el estado de dos instancias: la principal original y la nueva principal.

      Después de promocionar la réplica de lectura entre regiones como la nueva principal, habilítala para la alta disponibilidad. Te recomendamos que actualices las variables de entorno con los nombres adecuados.

    2. Actualiza 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 el nuevo principal:

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

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

      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, has definido la variable de entorno cross_region_replica_region como us-west3.

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

      En la página Instancias se muestra la nueva instancia principal habilitada para alta disponibilidad y una nueva réplica de lectura.

    6. (Opcional) Si tienes copias de seguridad periódicas, sigue el proceso descrito anteriormente para sincronizar la nueva principal con la versión de copia de seguridad más reciente.

    7. (Opcional) Si usas un proxy de Cloud SQL, configura el proxy para que use el nuevo principal y así reanudar el procesamiento de la aplicación.

    Gestionar una interrupción breve de una región

    Es posible que la interrupción que activa una conmutación por error se resuelva antes de que se complete. En este caso, puede ser conveniente cancelar el proceso de conmutación por error y seguir usando la instancia principal original de Cloud SQL en la región en la que se ha producido la interrupción.

    En función del estado específico del proceso de conmutación por error, es posible que la réplica de lectura entre regiones ya se haya ascendido. En ese caso, debes eliminarla y volver a crear una réplica de lectura entre regiones.

    Eliminar la réplica principal original para evitar una situación de cerebro dividido

    Para evitar una situación de cerebro dividido, debes eliminar la réplica principal original (o hacer que los clientes de la base de datos no puedan acceder a ella).

    Después de una conmutación por error, puede producirse una situación de cerebro dividido 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á obsoleta y no debe recibir tráfico de lectura ni de escritura.

    • En Cloud Shell, elimina la réplica principal original:

      gcloud sql instances delete $former_primary_name

      Cuando se te pida, 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:

      En la página Instancias solo se muestran la nueva instancia principal y la réplica de lectura.

    Fase 3: Implementar una alternativa

    Para implementar una alternativa a tu región original (R1) cuando esté disponible, sigue el mismo proceso que se describe en la fase 2. El 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. Promociona la réplica de lectura entre regiones de R1 como instancia principal final.

    3. Habilita la alta disponibilidad para la instancia principal final.

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

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

    Como hemos comentado anteriormente, es una práctica recomendada crear una copia de seguridad inicial que contenga el estado inicial definido de la nueva base de datos principal.

    La implementación final ahora tiene un elemento 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 la recuperación ante desastres manual y automática

    En la siguiente tabla se analizan las ventajas y desventajas de implementar un proceso de recuperación ante desastres de forma manual o automática. El objetivo no es determinar si un enfoque es correcto o incorrecto, sino proporcionar criterios que te ayuden a determinar el mejor enfoque para tus necesidades.

    Ejecución manual Ejecución automática
    Ventajas:
    • Tienes un control total sobre cada paso.
    • Puedes ver, abordar y documentar cualquier problema del proceso de inmediato.
    • Puede ver y revisar cada paso del proceso durante una conmutación por error.
    		 Ventajas:
    • Puedes implementar y probar 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, sus conocimientos y su disponibilidad.
    Desventajas:
    • Si implementas los pasos del proceso manualmente, se ralentizará.
    • Los errores de escritura humanos pueden provocar problemas.
    • Probar el proceso suele implicar varios roles y tiempo, lo que puede disuadir de realizar pruebas periódicas.
    		 Desventajas:
    • Si se produce un error imprevisto, tendrás que depurar durante la conmutación por error de producción.
    • Si se producen errores durante el proceso, necesitas secuencias de comandos para reanudar el proceso en el punto en el que se interrumpió.
    • Para entender el comportamiento de la secuencia de comandos, especialmente en situaciones de error, es necesario tener conocimientos suficientes sobre ella y su implementación.

    Como práctica recomendada, te aconsejamos que empieces con una implementación manual. A continuación, lleva a cabo la implementación de forma voluntaria con regularidad (preferiblemente en producción) para asegurarte de que el proceso manual funciona y de que todos los miembros del equipo conocen 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 mejorar el documento del proceso.

    Una vez que hayas optimizado el proceso y estés seguro de que es fiable, podrás decidir si lo automatizas. Si seleccionas e implementas un proceso automatizado, debes probarlo periódicamente en producción para asegurarte de que puedes implementarlo de forma fiable.

    Limpieza

    Para evitar que se apliquen cargos en tu Google Cloud cuenta por los recursos utilizados en este tutorial, puedes eliminar el Google Cloud proyecto que has creado para este tutorial.

    Eliminar el proyecto

    1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

    2. In the project list, select the project that you want to delete, and then click Delete.
    3. In the dialog, type the project ID, and then click Shut down to delete the project.

    Siguientes pasos