Usar la recuperación ante desastres (DR) avanzada

MySQL |PostgreSQL |SQL Server

En esta página, se describe cómo usar la recuperación ante desastres (DR) avanzada. La DR avanzada proporciona dos capacidades principales:

• La conmutación por error de réplica te permite conmutar por error la instancia principal a la réplica de DR de inmediato en caso de una falla regional. En el caso de Cloud SQL para SQL Server, la réplica de DR es una réplica que se puede aplicar en cascada.
• El cambio te permite revertir las funciones de la instancia principal y una réplica de DR sin pérdida de datos. Puedes usar el cambio para restablecer una implementación a su estado de implementación original después de la conmutación por error de la réplica o puedes usar el cambio para probar la DR.

La DR avanzada solo es compatible con las instancias de edición de Cloud SQL Enterprise Plus.

Nota: En esta página, se incluyen funciones relacionadas con las ediciones de Cloud SQL. Para obtener más información sobre las ediciones de Cloud SQL, consulta Introducción a las ediciones de Cloud SQL.

Antes de comenzar

Si planeas usar el SDK de Google Cloud, debes usar la versión 502.0.0 o una posterior. Para verificar 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 Instala la CLI de gcloud.

Crea una réplica de DR

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

Realiza un cambio

Una vez que hayas designado una réplica de DR, puedes realizar la operación de cambio. Sin embargo, se recomienda evitar realizar la operación de cambio en las siguientes circunstancias:

• La instancia principal se en uso de forma activa.
• Las operaciones de administrador están en curso, como la copia de seguridad automática, la habilitación o inhabilitación de la alta disponibilidad (HA).

Para evitar el tiempo de espera, considera realizar un cambio cuando el volumen de transacciones sea bajo.

Cuando se completa el cambio, la operación realiza una copia de seguridad de la nueva instancia principal (la réplica de DR anterior) en cuanto se asciende la nueva instancia principal. Una vez que se complete esta copia de seguridad, la recuperación de un momento determinado (PITR) está habilitada por completo en la instancia principal nueva. Esta copia de seguridad puede tardar entre 5 y 15 minutos en completarse según el tamaño del disco. La cobertura de la PITR comienza solo después de que se completa esta copia de seguridad. Para obtener más información sobre las consideraciones del uso de la PITR con DR avanzada, consulta Usa la PITR con DR avanzada.

Una vez que se complete la operación de cambio, verás que se revierte la dirección de replicación.

Después de que tu instancia principal anterior se vuelva a configurar como una réplica de lectura, el extremo de escritura de DNS, que antes se resolvía en la instancia principal anterior, se resuelve en la instancia principal nueva.

Antes de comenzar

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

• Si aún no lo hiciste, crea una réplica de DR.
• Verifica que la instancia principal y la réplica de DR estén en línea.
• Si usas un extremo de escritura de DNS, verifica que la configuración de SSL de la instancia principal y la réplica de DR sean las mismas. Por ejemplo, si la réplica de DR está configurada para aplicar la encriptación SSL, pero la instancia principal permite conexiones sin encriptar, los clientes no podrán conectarse a la nueva instancia principal después de que se complete la operación de cambio.
• Realiza una copia de seguridad a pedido de la instancia principal. Esta copia de seguridad es una medida de precaución en caso de que necesites recuperarlas ante cualquier falla inesperada.

Nota: Para que Cloud SQL actualice un extremo de escritura y lo dirija a la instancia correcta, asegúrate de que la réplica esté en la nueva arquitectura de red antes de que se realice la operación de cambio. Si la instancia no se crea con esta arquitectura, puedes actualizarla a la nueva arquitectura de red.

Realiza la operación de cambio

gcloud

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

gcloud sql instances switchover REPLICA_NAME

Reemplaza las siguientes variables:

• REPLICA_NAME: Es el nombre de la réplica de DR con la que deseas que cambie la instancia principal.

REST v1

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

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

Método HTTP y URL:

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

Para enviar tu solicitud, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Nota: Con el siguiente comando, se supone que accediste a la CLI de gcloud con tu cuenta de usuario a través de la ejecución de gcloud init o gcloud auth login, o a través del uso de Cloud Shell, que accede de forma automática a la CLI de gcloud. Para comprobar la cuenta activa actual, ejecuta gcloud auth list.

Ejecuta el siguiente comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell (Windows)

Nota: El siguiente comando supone que accediste a la CLI de gcloud con tu cuenta de usuario mediante la ejecución de gcloud init o gcloud auth login. Para comprobar la cuenta activa actual, ejecuta gcloud auth list.

Ejecuta el siguiente comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

Deberías recibir una respuesta JSON similar a la que se muestra a continuación:

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

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

Método HTTP y URL:

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

Para enviar tu solicitud, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Nota: Con el siguiente comando, se supone que accediste a la CLI de gcloud con tu cuenta de usuario a través de la ejecución de gcloud init o gcloud auth login, o a través del uso de Cloud Shell, que accede de forma automática a la CLI de gcloud. Para comprobar la cuenta activa actual, ejecuta gcloud auth list.

Ejecuta el siguiente comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

PowerShell (Windows)

Nota: El siguiente comando supone que accediste a la CLI de gcloud con tu cuenta de usuario mediante la ejecución de gcloud init o gcloud auth login. Para comprobar la cuenta activa actual, ejecuta gcloud auth list.

Ejecuta el siguiente comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

Deberías recibir una respuesta JSON similar a la que se muestra a continuación:

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Realiza una DR con la invocación de una conmutación por error de réplica

En caso de una falla regional o un desastre, puedes realizar la DR si invocas una operación de conmutación por error de réplica a la réplica de DR designada. Para realizar una conmutación por error de réplica, debes ascender la réplica de DR. A diferencia del cambio, la promoción de la réplica de DR es inmediata.

Dado que la réplica de DR asume la función de la instancia principal de inmediato, es posible que la réplica no tenga todos los datos de la instancia principal anterior por el retraso de la replicación. Por esta razón, una conmutación por error de réplica puede generar la pérdida de datos.

Como parte del proceso de promoción, la conmutación por error de réplica realiza una copia de seguridad de la nueva instancia principal (la réplica de DR anterior) justo después de que esta se convierta en la nueva instancia principal. Una vez que se completa esta copia de seguridad, la recuperación de un momento determinado (PITR) está habilitada por completo en la instancia principal nueva. Esta copia de seguridad puede tardar entre 5 y 15 minutos en completarse, según el tamaño del disco de la instancia principal nueva (y anterior). Durante este período de copia de seguridad, la PITR no está disponible.

Cuando la instancia principal anterior vuelve a estar en línea, el proceso de conmutación por error de la réplica realiza una copia de seguridad. Después de realizar esta copia de seguridad, la instancia principal anterior se vuelve a crear como una réplica de lectura de la instancia principal nueva.

Para obtener más información sobre las consideraciones del uso de la PITR con DR avanzada, consulta Usa la PITR con DR avanzada.

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

Antes de comenzar

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

• Si aún no lo hiciste, crea una réplica de DR.
• Asegúrate de que la réplica de DR esté en línea y en buen estado.

Nota: Para que Cloud SQL actualice un extremo de escritura y lo dirija a la instancia correcta, asegúrate de que la réplica esté en la nueva arquitectura de red antes de que se produzca la operación de conmutación por error de la réplica. Si la instancia no se crea con esta arquitectura, puedes actualizarla a la nueva arquitectura de red.

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

gcloud

Para invocar una conmutación por error de réplica en la réplica de DR, usa el siguiente comando:

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

Reemplaza la siguiente variable:

• REPLICA_NAME: Es el nombre de la réplica de DR.

REST v1

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

• PROJECT_ID: Es el ID o número del proyecto de Google Cloud de la instancia principal y la réplica de DR.
• REPLICA_NAME: Es el nombre de la réplica de DR.
• ENABLE_REPLICA_FAILOVER: Se establece en true para usar la conmutación por error de réplica. Si lo estableces en 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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Nota: Con el siguiente comando, se supone que accediste a la CLI de gcloud con tu cuenta de usuario a través de la ejecución de gcloud init o gcloud auth login, o a través del uso de Cloud Shell, que accede de forma automática a la CLI de gcloud. Para comprobar la cuenta activa actual, ejecuta gcloud auth list.

Ejecuta el siguiente comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell (Windows)

Nota: El siguiente comando supone que accediste a la CLI de gcloud con tu cuenta de usuario mediante la ejecución de gcloud init o gcloud auth login. Para comprobar la cuenta activa actual, ejecuta gcloud auth list.

Ejecuta el siguiente comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

Deberías recibir una respuesta JSON similar a la que se muestra a continuación:

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Antes de usar cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

• PROJECT_ID: Es el ID o número del proyecto de Google Cloud de la instancia principal y la réplica de DR.
• REPLICA_NAME: Es el nombre de la réplica de DR.
• ENABLE_REPLICA_FAILOVER: Se establece en true para usar la conmutación por error de réplica. Si lo estableces en 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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Nota: Con el siguiente comando, se supone que accediste a la CLI de gcloud con tu cuenta de usuario a través de la ejecución de gcloud init o gcloud auth login, o a través del uso de Cloud Shell, que accede de forma automática a la CLI de gcloud. Para comprobar la cuenta activa actual, ejecuta gcloud auth list.

Ejecuta el siguiente comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell (Windows)

Nota: El siguiente comando supone que accediste a la CLI de gcloud con tu cuenta de usuario mediante la ejecución de gcloud init o gcloud auth login. Para comprobar la cuenta activa actual, ejecuta gcloud auth list.

Ejecuta el siguiente comando:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

Deberías recibir una respuesta JSON similar a la que se muestra a continuación:

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "[e-mail]",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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

La conmutación por error de réplicas ocurre en dos fases. La primera fase es el ascenso de la réplica de DR. La segunda fase es la recreación de la instancia principal anterior como una réplica de lectura.

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

1. Verifica el estado de la primera fase.

   Console

   Para verificar si la réplica de DR se ascendió a una instancia independiente, haz lo siguiente:

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

      Ir a Instancias de Cloud SQL

   2. Busca el nombre de la réplica de DR que promoviste.
   3. Verifica que SQL Server VERSION aparezca en la columna Tipo para la instancia principal nueva.

   gcloud

   Para verificar el estado, ejecuta el siguiente comando:

   gcloud sql instances describe DR_REPLICA_NAME

   Reemplaza la siguiente variable:

   • DR_REPLICA_NAME: el nombre de la réplica de DR que se ascendió

   En el resultado, verifica que aparezca el siguiente campo y que la réplica se haya convertido en una instancia principal de Cloud SQL independiente:

   instanceType: CLOUD_SQL_INSTANCE
   

2. Para verificar la finalización de la segunda fase, comprueba el registro de operaciones en la instancia para el mensaje RECONFIGURE_OLD_PRIMARY.

   La apariencia de este mensaje depende del momento en que la instancia principal anterior se muestra en línea, lo que puede tardar minutos o días en caso de que ocurra un desastre.

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

Usa la PITR con DR avanzada

Con el cambio y la conmutación por error de réplica, cuando la réplica de DR se asciende a una instancia principal, se producen los siguientes cambios para admitir la copia de seguridad y PITR:

• La configuración de copia de seguridad, incluida cualquier programación de copia de seguridad automática, se copia de la instancia principal anterior a la nueva.

• Se realiza una copia de seguridad nueva para admitir la PITR en la instancia principal nueva.

• La política de retención de registros de transacciones se copia de la instancia principal anterior a la nueva instancia principal.

Para la configuración de copia de seguridad y las políticas de retención de registros de transacciones, te recomendamos que verifiques que la configuración heredada de la instancia principal anterior sea correcta para la nueva instancia principal.

Inicia la cobertura de la PITR

Al final de la operación de cambio, Cloud SQL programa copias de seguridad automáticas y realiza la primera copia de seguridad de la instancia principal nueva. Si deseas que la cobertura de la PITR comience más temprano que tarde, te recomendamos que verifiques que la primera copia de seguridad se realice de forma correcta. La instancia principal que se acaba de ascender tiene cobertura de la PITR solo después de que la primera copia de seguridad automática se haya completado de forma correcta.

Si quieres obtener más información sobre cómo ver las copias de seguridad disponibles para una instancia, consulta Visualiza una lista de copias de seguridad.

Cobertura de la PITR para las instancias durante el cambio y la conmutación por error de réplica

Cuando una instancia participa en un cambio o en una operación de conmutación por error de réplica, la instancia pasa tiempo como réplica de lectura. La PITR y el restablecimiento de una copia de seguridad son compatibles durante el período que la instancia pasa como réplica de lectura y como instancia principal.

Puedes realizar la PITR en un momento anterior al cambio, cuando la instancia era una instancia principal. Para las operaciones de cambio y conmutación por error de réplica, Cloud SQL inicia una copia de seguridad del mejor esfuerzo para la instancia principal nueva en cuanto se asciende. La PITR se habilita en la instancia promocionada solo después de que se completa esta copia de seguridad. Esta copia de seguridad puede tardar entre 5 y 15 minutos en completarse, según el tamaño del disco.

Cerebro dividido durante la conmutación por error de réplica

Es posible que se produzca un cerebro dividido cuando la instancia principal siga aceptando operaciones de escritura mientras se asciende una réplica con la conmutación por error de réplicas. Una vez que la réplica asciende, cuando la instancia principal anterior vuelve a estar disponible, se vuelve a compilar como una réplica de la instancia ascendida y se realiza una copia de seguridad final. Esta copia de seguridad se puede usar para recuperar los datos de cerebro dividido que no se escribieron en la réplica promocionada.

Nota: El cerebro dividido no puede ocurrir en las operaciones de cambio.

Borra copias de seguridad y registros de transacciones en réplicas

Si una instancia principal que se habilitó con la PITR y las copias de seguridad se convierte en una réplica de lectura, se conserva la última política de copia de seguridad y retención de la PITR de su tiempo como instancia principal y se aplica durante su tiempo como réplica. Aunque la instancia principal nueva no realiza copias de seguridad, las copias de seguridad y los registros de transacciones antiguos que se usaron para PITR se borran en 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 convierte en una réplica de lectura, todo lo que tenga más de 7 días se borra una vez al día.

Si necesitas borrar las copias de seguridad antes, puedes quitarlas de forma manual. Para obtener más información, consulta Borra una copia de seguridad.

Nota: No puedes modificar la configuración de la copia de seguridad mientras la instancia es una réplica.

Limitaciones

• La DR avanzada no es compatible con las instancias de Cloud SQL que usan Private Service Connect. La DR avanzada sí admite el acceso privado a servicios.

• No puedes designar una instancia de réplica de lectura de Cloud SQL Enterprise Plus como réplica de DR si la instancia principal almacena sus registros de transacciones para la recuperación de un momento determinado (PITR) en el disco. Si quieres verificar dónde almacena una instancia sus registros para la PITR, consulta Verifica la ubicación de almacenamiento de los registros de transacciones que se usan para la PITR.

• No puedes designar una réplica externa como una réplica de DR.

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

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

Solucionar problemas

Problema	Soluciona problemas
No se pudo realizar la operación de cambio.	Asegúrate de que la instancia cumpla con todos los requisitos de réplica de DR (réplicas en cascada) establecidos. Verifica el volumen de transacciones en la base de datos. Si el volumen de transacciones es alto, la operación puede agotar el tiempo de espera. Considera volver a intentar realizar la operación cuando la carga de la transacción sea menor.
La operación de cambio falló y la instancia principal está atascada en modo de solo lectura.	Realiza un reinicio de la base de datos para que la instancia principal vuelva al modo de escritura.
Se completó la operación de cambio, pero la consola de Google Cloud no muestra los nuevos roles revertidos para las instancias.	Actualiza el navegador para mostrar la topología actualizada.
Falló la operación de conmutación por error de réplica.	Asegúrate de haber creado una réplica de DR para la instancia principal y de que la réplica de DR esté en línea. Si falla la conmutación por error de réplica de DR, asciende a una réplica de lectura normal (que no sea de DR).

¿Qué sigue?

• Descubre todos los servicios de Google Cloud disponibles en ubicaciones de todo el mundo.
• Lee sobre la observabilidad de la base de datos.
• Supervisa instancias de Cloud SQL