Usar la recuperación tras fallos avanzada

En esta página se describe cómo usar la recuperación tras desastres avanzada. La recuperación ante desastres avanzada ofrece dos funciones principales:

  • La conmutación por error de réplica te permite conmutar por error tu instancia principal a la réplica de recuperación tras fallos inmediatamente en caso de que se produzca un fallo en la región. En Cloud SQL para SQL Server, la réplica de recuperación tras desastres es una réplica en cascada.
  • La conmutación te permite invertir los roles de la instancia principal y de una réplica de recuperación tras desastres sin perder datos. Puedes usar el cambio para restaurar una implementación a su estado original después de una conmutación por error de réplica, o bien para probar la recuperación ante desastres.

La recuperación ante desastres avanzada solo se admite en instancias de la edición Enterprise Plus de Cloud SQL.

Antes de empezar

Si tienes previsto usar el SDK de Google Cloud, debes usar la versión 502.0.0 o una posterior. Para comprobar la versión del SDK de Google Cloud, ejecuta gcloud --version. Para actualizar el SDK de Google Cloud, ejecuta gcloud components update.

Para instalar el SDK de Google Cloud, consulta el artículo sobre cómo instalar la CLI de gcloud.

Crear una réplica de recuperación ante desastres

Antes de usar la recuperación ante desastres avanzada, crea una réplica en cascada de la instancia principal en una región diferente a la de la instancia principal.

Hacer un cambio

Una vez que hayas creado una réplica de recuperación ante desastres, podrás realizar la operación de cambio. Sin embargo, como práctica recomendada, no realice la operación de cambio en las siguientes circunstancias:

  • La instancia principal se está usando de forma activa.
  • Se están llevando a cabo operaciones de administrador, como la creación de copias de seguridad automáticas o la habilitación o inhabilitación de la alta disponibilidad.

Para evitar que se agote el tiempo de espera, considera la posibilidad de realizar el cambio cuando el volumen de transacciones sea bajo.

Cuando se completa el cambio, la operación crea una copia de seguridad de la nueva instancia principal (la antigua réplica de recuperación ante desastres) en cuanto se promueve la nueva instancia principal. Esta copia de seguridad puede tardar entre 5 y 15 minutos en completarse, en función del tamaño del disco. Una vez que se haya completado esta copia de seguridad, si quieres usar PITR en la instancia promocionada, debes habilitar PITR manualmente. Para obtener más información sobre las consideraciones que debes tener en cuenta al usar PITR con la recuperación ante desastres avanzada, consulta Usar PITR con la recuperación ante desastres avanzada.

Una vez que se haya completado la operación de cambio, verás que la dirección de la replicación se ha invertido.

Una vez que la antigua instancia principal se haya reconfigurado como réplica de lectura, el endpoint de escritura de DNS, que antes se resolvía en la antigua instancia principal, se resolverá en la nueva instancia principal.

Antes de empezar

Antes de realizar la operación de cambio, haga lo siguiente:

  • Si aún no lo has hecho, crea una réplica de recuperación ante desastres.
  • Verifica que la instancia principal y la réplica de recuperación ante desastres estén online.
  • Si usas un endpoint de escritura de DNS, verifica que la configuración SSL de la instancia principal y de la réplica de recuperación ante desastres sea la misma. Por ejemplo, si la réplica de recuperación ante desastres está configurada para aplicar el cifrado SSL, pero la instancia principal permite conexiones sin cifrar, los clientes no podrán conectarse a la nueva instancia principal una vez que se haya completado la operación de cambio.
  • Crea una copia de seguridad bajo demanda de la instancia principal. Esta copia de seguridad es una precaución por si necesitas recuperarte de algún fallo inesperado.

Realizar la operación de cambio

gcloud

Para realizar la operación de cambio, ejecuta el siguiente comando:

gcloud sql instances switchover REPLICA_NAME

Sustituye las siguientes variables:

  • REPLICA_NAME: el nombre de la réplica de recuperación ante desastres con la que quieres que la instancia principal cambie de rol.

Terraform

Para iniciar la operación de cambio, usa un recurso de Terraform. Para convertir la réplica de recuperación ante desastres en la nueva instancia principal, utiliza el primer ejemplo. El ejemplo contiene comentarios sobre los cambios de configuración de Terraform que debes hacer para cambiar la instancia principal y la réplica de recuperación ante desastres.

resource "google_sql_database_instance" "original-primary" {
  name             = "sqlserver-primary-instance-name"
  region           = "us-east1"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  instance_type    = "CLOUD_SQL_INSTANCE"
  root_password    = "INSERT-PASSWORD-HERE"
  replica_names    = ["sqlserver-replica-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name = "sqlserver-replica-instance-name"
  # Remove or comment out the master_instance_name
  # master_instance_name = google_sql_database_instance.original-primary.name
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  # Remove or comment out the replica_configuration section
  # replica_configuration {
  #  cascadable_replica = true
  # }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

Cuando hayas acabado de hacer los cambios, actualiza la réplica principal y la de recuperación ante desastres ejecutando terraform plan. Comprueba que el resultado incluya Plan: 0 to add, 1 to change, 0 to destroy. Para realizar el cambio, ejecuta terraform apply.

En este punto, la instancia principal original es una réplica de la nueva instancia principal. Sin embargo, ese cambio no se refleja automáticamente en tu estado de Terraform. Para convertir la instancia principal original en una réplica de la nueva instancia principal en tu estado de Terraform, usa el segundo ejemplo. El segundo ejemplo proporciona comentarios que describen los cambios que debes hacer después de ejecutar el primer ejemplo.

resource "google_sql_database_instance" "original-primary" {
  name = "sqlserver-primary-instance-name"
  # Set master_instance_name to the new primary instance, the original DR replica.
  master_instance_name = "sqlserver-replica-instance-name"
  region               = "us-east1"
  database_version     = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Remove  values from the replica_names field, but don't remove the field itself.
  replica_names = []
  # Add replica_configuration section and set cascadable_replica to true.
  replica_configuration {
    cascadable_replica = true
  }
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name             = "sqlserver-replica-instance-name"
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

Si el estado de Terraform se actualiza correctamente, cuando ejecute terraform plan en la segunda muestra, aparecerá un mensaje similar al siguiente:

No changes. Your infrastructure matches the configuration.

Si ejecutas terraform apply, recibirás un mensaje similar al siguiente:

Resources: 0 added, 0 changed, 0 destroyed.

REST v1

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • PROJECT_ID: el ID o el número de proyecto del Google Cloud proyecto de la instancia principal y la réplica de recuperación ante desastres.
  • REPLICA_NAME: el nombre de la réplica de recuperación ante desastres.

Método HTTP y URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

Para enviar tu solicitud, despliega una de estas opciones:

Deberías recibir una respuesta JSON similar a la siguiente:

REST v1beta4

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • PROJECT_ID: el ID o el número de proyecto del Google Cloud proyecto de la instancia principal y la réplica de recuperación ante desastres.
  • REPLICA_NAME: el nombre de la réplica de recuperación ante desastres.

Método HTTP y URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

Para enviar tu solicitud, despliega una de estas opciones:

Deberías recibir una respuesta JSON similar a la siguiente:

Realizar la recuperación tras desastres invocando una conmutación por error de réplica

En caso de fallo o desastre en una región, puedes llevar a cabo la recuperación tras fallos invocando una operación de conmutación por error de réplica en la réplica de recuperación tras fallos designada. Para llevar a cabo una conmutación por error de réplica, debes promover la réplica de recuperación ante desastres. A diferencia del cambio, la promoción de la réplica de recuperación ante desastres es inmediata.

Como la réplica de recuperación ante desastres asume el rol de la instancia principal inmediatamente, es posible que no tenga todos los datos de la instancia principal anterior debido al intervalo de replicación. Por este motivo, una conmutación por error de réplica puede provocar una pérdida de datos.

Como parte del proceso de promoción, la conmutación por error de la réplica crea una copia de seguridad de la nueva instancia principal (la antigua réplica de recuperación ante desastres) justo después de que la réplica de recuperación ante desastres se convierta en la nueva instancia principal. Una vez que se haya completado la copia de seguridad, la recuperación a un momento dado (PITR) estará totalmente habilitada en la nueva instancia principal. Esta copia de seguridad puede tardar entre 5 y 15 minutos en completarse, en función del tamaño del disco de la instancia principal nueva (y antigua). Durante este periodo de copia de seguridad, PITR no está disponible.

Cuando la antigua instancia principal vuelve a estar online, el proceso de conmutación por error de la réplica crea una copia de seguridad. Una vez creada esta copia de seguridad, la antigua instancia principal se vuelve a crear como réplica de lectura de la nueva instancia principal.

Para obtener más información sobre las consideraciones que debes tener en cuenta al usar PITR con la recuperación ante desastres avanzada, consulta Usar PITR con la recuperación ante desastres avanzada.

Después de invocar la operación de conmutación por error de la réplica, el endpoint de escritura de DNS, que antes se resolvía en la instancia principal antigua, se resuelve en la nueva instancia principal.

Antes de empezar

Antes de poder realizar una conmutación por error de réplica, haz lo siguiente:

Realizar la operación de conmutación por error de la réplica

gcloud

Para invocar una conmutación por error de la réplica a la réplica de recuperación ante desastres, usa el siguiente comando:

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

Sustituye la siguiente variable:

  • REPLICA_NAME: el nombre de la réplica de recuperación ante desastres

REST v1

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • PROJECT_ID: el ID o el número de proyecto del Google Cloud proyecto de la instancia principal y la réplica de recuperación ante desastres.
  • REPLICA_NAME: el nombre de la réplica de recuperación ante desastres.
  • ENABLE_REPLICA_FAILOVER: asigna el valor true para usar la conmutación por error de la réplica. Si le asignas el valor false, la API usará el método promoteReplica normal sin conmutación por error de réplica.

Método HTTP y URL: 

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

Para enviar tu solicitud, despliega una de estas opciones:

Deberías recibir una respuesta JSON similar a la siguiente:

REST v1beta4

Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

  • PROJECT_ID: el ID o el número de proyecto del Google Cloud proyecto de la instancia principal y la réplica de recuperación ante desastres.
  • REPLICA_NAME: el nombre de la réplica de recuperación ante desastres.
  • ENABLE_REPLICA_FAILOVER: asigna el valor true para usar la conmutación por error de la réplica. Si le asignas el valor false, la API usará el método promoteReplica normal sin conmutación por error de réplica.

Método HTTP y URL: 

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

Para enviar tu solicitud, despliega una de estas opciones:

Deberías recibir una respuesta JSON similar a la siguiente:

Comprobar el estado de una conmutación por error de réplica

La conmutación por error de réplicas se produce en dos fases. La primera fase es la promoción de la réplica de recuperación ante desastres. La segunda fase consiste en recrear la antigua instancia principal como réplica de lectura.

Para comprobar el estado de la conmutación por error de la réplica, compruebe el estado de cada fase.

  1. Comprueba el estado de la primera fase.

    Consola

    Para comprobar si la réplica de recuperación ante desastres se ha convertido en una instancia independiente, haz lo siguiente:

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

      Ir a Instancias de Cloud SQL

    2. Busca el nombre de la réplica de recuperación ante desastres que has promovido.
    3. Verifica que SQL Server VERSION aparece en la columna Tipo de la nueva instancia principal.

    gcloud

    Para comprobar el estado, ejecuta el siguiente comando:

    gcloud sql instances describe DR_REPLICA_NAME

    Sustituye la siguiente variable:

    • DR_REPLICA_NAME: el nombre de la réplica de recuperación ante desastres promocionada

    En el resultado, comprueba que aparece el siguiente campo y que la réplica se ha convertido en una instancia principal de Cloud SQL independiente:

    instanceType: CLOUD_SQL_INSTANCE

  2. Para verificar que se ha completado la segunda fase, consulta el registro de operaciones de la instancia para ver el mensaje RECONFIGURE_OLD_PRIMARY.

    La aparición de este mensaje depende de cuándo vuelva a estar online la instancia principal antigua, lo que puede tardar minutos o días en caso de desastre.

    Para obtener más información sobre cómo consultar los registros de operaciones de una instancia, consulta Ver los registros de una instancia.

Usar PITR con recuperación ante desastres avanzada

Tanto si se trata de un cambio como de una conmutación por error de réplica, si la réplica de recuperación ante desastres se convierte en una instancia principal y quieres usar PITR en la instancia ascendida, debes habilitar PITR manualmente.

Una vez habilitada la restauración a un momento dado, se aplican las políticas de configuración de la copia de seguridad y de conservación del registro de transacciones. Si no especifica valores para estos ajustes, se aplicará el valor predeterminado de 14 días.

Para obtener más información, consulta Usar PITR.

Una vez que la recuperación a un momento dado esté habilitada en la nueva instancia principal, podrás restaurar la instancia a cualquier momento en el que sea una instancia principal activa.

Split-brain durante la conmutación por error de la réplica

Es posible que se produzca una división de cerebro cuando la instancia principal siga aceptando escrituras mientras se promueve una réplica mediante la conmutación por error de réplica. Una vez que se haya ascendido la réplica, cuando la instancia principal antigua vuelva a estar disponible, se volverá a compilar como réplica de la instancia ascendida y se creará una copia de seguridad final. Esta copia de seguridad se puede usar para recuperar los datos de split-brain que no se hayan escrito en la réplica ascendida.

Eliminación de copias de seguridad y registros de transacciones en réplicas

Si una instancia principal en la que se habían habilitado PITR y las copias de seguridad se convierte en una réplica de lectura, se conservarán y se aplicarán la última copia de seguridad y la política de retención de PITR de cuando era una instancia principal durante el tiempo que sea una réplica. Aunque la nueva instancia principal no crea copias de seguridad, las copias de seguridad antiguas y los registros de transacciones que se usan para PITR se eliminan de la réplica de lectura según la última política configurada.

Por ejemplo, si la instancia está configurada para tener copias de seguridad automáticas diarias y conservar 7 copias de seguridad con 7 días de registros de PITR, cuando esta instancia se convierta en una réplica de lectura, se eliminará una vez al día todo lo que tenga más de 7 días.

Si necesitas eliminar copias de seguridad antes, puedes hacerlo manualmente. Para obtener más información, consulta Eliminar una copia de seguridad.

Limitaciones

  • La recuperación ante desastres avanzada no se admite en las instancias de Cloud SQL que usan Private Service Connect. La recuperación ante desastres avanzada admite el acceso a servicios privados.

  • No puedes designar una instancia de réplica de lectura de Cloud SQL Enterprise Plus como réplica de recuperación ante desastres si la instancia principal almacena sus registros de transacciones para la recuperación a un momento dado (PITR) en el disco. Para comprobar dónde almacena una instancia sus registros para PITR, consulta Comprobar la ubicación de almacenamiento de los registros de transacciones usados para PITR.

  • No puedes designar una réplica externa como réplica de recuperación ante desastres.

  • Terraform no es compatible con las operaciones de conmutación por error de réplicas.

  • No puedes usar la consola Google Cloud para realizar operaciones de conmutación por error o de cambio de réplica.

Solucionar problemas

Problema Solución de problemas
No se ha podido realizar el cambio.
La operación de cambio ha fallado y la instancia principal se ha quedado en modo de solo lectura. Reinicia la base de datos para que la instancia principal vuelva al modo de escritura.
La operación de cambio se ha completado, pero la consola no muestra los nuevos roles invertidos de las instancias. Google Cloud Actualiza el navegador para ver la topología actualizada.
No se ha podido realizar la operación de conmutación por error de la réplica.
  • Asegúrate de haber creado una réplica de recuperación ante desastres para la instancia principal y de que la réplica esté online.
  • Si la conmutación por error a la réplica de recuperación ante desastres ha fallado, asciende a una réplica de lectura normal (no de recuperación ante desastres).

Siguientes pasos