Usar la recuperación ante desastres (DR) avanzada

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.

Antes de comenzar

Si planeas usar el SDK de Google Cloud, debes usar la versión 470.0.0 o una posterior y los comandos de gcloud beta. Para verificar la versión del SDK de Google Cloud, ejecuta gcloud --version. Para inicializar el SDK de Google Cloud, debes ejecutar 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 de 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.

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.
• 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.

Realiza la operación de cambio

gcloud beta sql instances switchover REPLICA_NAME

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

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"

$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

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "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"
}

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

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"

$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

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "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. En este proceso, la instancia principal anterior pierde todos los registros de transacciones de la PITR antiguos que aún no se guardaron en Cloud Storage. Por lo tanto, la conmutación por error de réplicas no garantiza que se conserven todos los registros de transacciones que se usaron para PITR en la instancia principal anterior.

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

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.

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

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

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

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"

$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

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "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"
}

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

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

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

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

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/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.
• Si se inhabilita, la marca de configuración de binlog se activa para habilitar la PITR.
• 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. Si deseas realizar la PITR en un momento determinado antes de que ocurra el evento de cambio (cuando la instancia era principal), puedes emitir el comando de clonación para orientarte al momento en que la instancia era principal. No puedes solicitar la PITR a una hora en la que la instancia era una réplica de lectura.

Si no puedes realizar la PITR porque la instancia principal era una réplica de lectura en el momento del interés, debes intentar realizar la solicitud de la PITR en la instancia que era la instancia principal que actuaba en el momento del interés.

Del mismo modo, puedes restablecer una copia de seguridad que se realizó en un momento en el que la réplica era una instancia principal. Si bien la instancia es una réplica, el comando de restablecimiento debe orientarse a una instancia independiente diferente y no se puede restablecer en la réplica.

Para determinar qué instancia usar para la solicitud de la PITR, usa la lista de operaciones. La lista de operaciones de una instancia puede ayudar a determinar cuándo una instancia se sometió a operaciones de cambio o réplica de conmutación por error.

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.

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.

Limitaciones

• La DR avanzada no es compatible con las instancias de Cloud SQL que usan Private Service Connect.
• 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.

Solucionar problemas

¿Qué sigue?

• Lee sobre la observabilidad de la base de datos.
• Supervisa instancias de Cloud SQL