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.
- 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.
Designar una réplica de recuperación ante desastres
Para llevar a cabo una recuperación ante desastres avanzada, primero debes designar una réplica de recuperación ante desastres entre regiones.
Requisitos de la instancia principal
La instancia principal debe ser una instancia de la edición Enterprise Plus de Cloud SQL y tener una réplica de recuperación ante desastres designada.
Si creas tu instancia de Cloud SQL con un endpoint de escritura de DNS, la instancia principal debe tener la misma configuración SSL que la réplica de recuperación ante desastres designada antes de invocar la operación de cambio o de failover de réplica. Por ejemplo, si configuras tu réplica de recuperación ante desastres 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 o de conmutación por error.
Requisitos de réplica de recuperación ante desastres
La réplica de lectura de recuperación ante desastres designada debe cumplir los siguientes requisitos:
- Debe ser una instancia de la edición Enterprise Plus de Cloud SQL
- Debe ser la misma versión principal y secundaria de la base de datos que la instancia principal, que ejecute MySQL 8.0.31 o una versión posterior.
Debe estar en una región distinta de la de la instancia principal
Debe ser una réplica de lectura directa; no puede ser una réplica en cascada
Además de usar los valores predeterminados, la réplica de recuperación ante desastres no puede tener configuradas las siguientes marcas:
replicate_do_db
replicate_ignore_db
replicate_do_table
replicate_wild_do_table
replicate_ignore_table
replicate_wild_ignore_table
Debe almacenar los registros de transacciones utilizados para PITR en Cloud Storage
No puede ser una réplica externa
Recomendaciones de réplicas de recuperación ante desastres
En esta sección se ofrecen recomendaciones para tu réplica de recuperación ante desastres. Las siguientes recomendaciones pueden ayudarte a evitar problemas de rendimiento en tu implementación:
- Usa el mismo tamaño de disco que la instancia principal o habilita el crecimiento automático.
- Usa una configuración de alta disponibilidad coherente. Si habilitas la alta disponibilidad en la instancia principal, también debes habilitarla en la réplica de recuperación tras desastres.
- Usa una configuración de caché de datos coherente. Si habilitas la caché de datos en la instancia principal, también debes habilitarla en la réplica de recuperación ante desastres.
- Configura las marcas de base de datos adecuadas para tu réplica de recuperación ante desastres antes y después de cualquier operación de cambio o de conmutación por error de la réplica.
- Usa el mismo tipo (nivel) y tamaño de máquina para la instancia principal y la réplica de recuperación ante desastres.
Crear una réplica para cumplir los requisitos de réplica de recuperación tras desastres
Si la instancia principal aún no tiene una réplica de lectura entre regiones que cumpla los requisitos de la réplica de recuperación ante desastres, crea una.
Consola
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca la instancia principal.
- En la columna Acciones, haz clic en el menú Más acciones.
- Selecciona Crear réplica de lectura.
- En el campo ID de instancia, introduce un nombre para la réplica de recuperación ante desastres.
- En el campo Versión de la base de datos, se selecciona la misma versión principal de la instancia principal.
- Si usas MySQL 8.0, en el campo Versión secundaria, mantén la versión secundaria preseleccionada. La réplica de recuperación ante desastres y la instancia principal deben compartir la misma versión secundaria de la base de datos.
- En la sección Choose a region and zonal availability (Elegir una región y la disponibilidad por zonas) de la página,
haga lo siguiente:
- Selecciona una región _diferente_ a la de tu instancia principal.
- Opcional. Selecciona Varias zonas para la réplica de recuperación ante desastres.
- Opcional. Selecciona las zonas principales y secundarias de la réplica de recuperación ante desastres.
- En la sección Personalizar tu instancia de la página, puedes actualizar la configuración de tu réplica de recuperación ante desastres. Para obtener más información sobre cada ajuste, consulta la página Acerca de los ajustes de instancia.
- En Formas de máquina, selecciona el mismo tipo de máquina que tu instancia principal.
- En Flags (Marcas), configura las marcas que necesite tu base de datos.
- Haz clic en Crear réplica.
Cloud SQL crea una copia de seguridad de la instancia principal y crea la réplica. Se te redirige a la página de la instancia principal.
gcloud
Para crear una réplica que cumpla los requisitos de una réplica de recuperación ante desastres, ejecuta el siguiente comando:
gcloud sql instances create REPLICA_NAME \ --master-instance-name=PRIMARY_INSTANCE_NAME \ --region=REPLICA_REGION_NAME \ --database-version=DATABASE_VERSION \ --tier=MACHINE_TYPE \ --availability-type=AVAILABILITY_TYPE --edition="ENTERPRISE_PLUS"
Sustituye las siguientes variables:
- REPLICA_NAME: el nombre de la réplica de recuperación ante desastres.
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
- REPLICA_REGION_NAME: especifica una región diferente a la de la instancia principal.
- DATABASE_VERSION: especifica la cadena de versión que coincide con la versión principal y secundaria de la base de datos de la instancia principal. Por ejemplo:
MYSQL_8_0_31
.Las versiones principales y secundarias de la base de datos deben ser las mismas tanto para la réplica principal como para la de recuperación ante desastres.
- MACHINE_TYPE: especifica el mismo tipo de máquina que la instancia principal. Te recomendamos que el tipo de máquina coincida con el de la instancia principal.
- AVAILABILITY_TYPE: si la instancia principal está configurada para ofrecer alta disponibilidad, le recomendamos que especifique
REGIONAL
para habilitar la alta disponibilidad. - EDITION: especifica
ENTERPRISE_PLUS
.
Terraform
Para crear una réplica de recuperación ante desastres, usa un recurso de Terraform.
REST v1
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
- 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.
- Cadena de versión DATABASE_VERSION: que coincide con la versión principal y secundaria de la base de datos de la instancia principal. Por ejemplo,
MYSQL_8_0_31
. La versión de la base de datos debe ser la misma tanto para la réplica principal como para la de recuperación ante desastres. - REPLICA_NAME: el nombre de la instancia de réplica de recuperación ante desastres que vas a crear.
- REPLICA_REGION: la región de la instancia de réplica de recuperación tras desastres. La región de la réplica debe ser diferente de la región de la instancia principal.
- MACHINE_TYPE: especifica el mismo tipo de máquina que la instancia principal. Te recomendamos que selecciones el mismo tipo de máquina que la instancia principal.
- AVAILABILITY_TYPE: si la instancia principal está configurada para ofrecer alta disponibilidad, te recomendamos que especifiques
REGIONAL
para habilitar la alta disponibilidad.
Método HTTP y URL:
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances
Cuerpo JSON de la solicitud:
{ "masterInstanceName": "PRIMARY_INSTANCE_NAME", "project": "PROJECT_ID", "databaseVersion": "DATABASE_VERSION", "name": "REPLICA_NAME", "region": "REPLICA_REGION", "settings": { "tier": "MACHINE_TYPE", "availabilityType": "AVAILABILITY_TYPE", "settingsVersion": 0, "replicationType": "ASYNCHRONOUS", } }
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:
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
- 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.
- Cadena de versión DATABASE_VERSION: que coincide con la versión principal y secundaria de la base de datos de la instancia principal. Por ejemplo,
MYSQL_8_0_31
. La versión de la base de datos debe ser la misma tanto para la réplica principal como para la de recuperación ante desastres. - REPLICA_NAME: el nombre de la instancia de réplica de recuperación ante desastres que vas a crear.
- REPLICA_REGION: la región de la instancia de réplica de recuperación tras desastres. La región de la réplica debe ser diferente de la región de la instancia principal.
- MACHINE_TYPE: especifica el mismo tipo de máquina que la instancia principal. Te recomendamos que el tamaño del disco coincida con el de la instancia principal.
- AVAILABILITY_TYPE: si la instancia principal está configurada para ofrecer alta disponibilidad, te recomendamos que especifiques
REGIONAL
para habilitar la alta disponibilidad.
Método HTTP y URL:
POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances
Cuerpo JSON de la solicitud:
{ "masterInstanceName": "PRIMARY_INSTANCE_NAME", "project": "PROJECT_ID", "databaseVersion": "DATABASE_VERSION", "name": "REPLICA_NAME", "region": "REPLICA_REGION", "settings": { "tier": "MACHINE_TYPE", "availabilityType": "AVAILABILITY_TYPE", "settingsVersion": 0, "replicationType": "ASYNCHRONOUS", } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Designar la réplica de recuperación tras desastres de la instancia principal
En los siguientes procedimientos se describe cómo designar una de las réplicas entre regiones de una instancia principal como réplica de recuperación ante desastres para la conmutación o la conmutación por error de réplica.
Consola
Para designar una réplica de recuperación ante desastres para una instancia principal, haz lo siguiente:
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca y selecciona la instancia principal. Aparecerá la página Información general de la instancia principal.
- En el menú de navegación, haz clic en Réplicas.
- En la lista de réplicas de lectura, busque la réplica de lectura entre regiones que quiera designar como réplica de recuperación ante desastres.
- En la réplica, haz clic en el botón more_vert Acciones y selecciona Designar como réplica de recuperación ante desastres.
- Haz clic en Confirmar.
gcloud
Para designar una réplica de recuperación ante desastres para una instancia principal, usa el siguiente comando:
gcloud sql instances patch PRIMARY_INSTANCE_NAME \ --failover-dr-replica-name=REPLICA_NAME
Sustituye las siguientes variables:
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
- REPLICA_NAME: el nombre de la réplica de recuperación ante desastres.
Terraform
Para designar una réplica de recuperación ante desastres para una instancia principal, usa un recurso de Terraform.
REST v1
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
- REPLICA_NAME: el nombre de la réplica de recuperación ante desastres.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Cuerpo JSON de la solicitud:
{ "replicationCluster": { "failoverDrReplicaName": "REPLICA_NAME" } }
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:
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
- REPLICA_NAME: el nombre de la réplica de recuperación ante desastres.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Cuerpo JSON de la solicitud:
{ "replicationCluster": { "failoverDrReplicaName": "REPLICA_NAME" } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Cambiar la designación de la réplica de recuperación ante desastres
Si la réplica cumple los requisitos, puede designar otra réplica como réplica de recuperación ante desastres. La réplica de recuperación ante desastres antigua pierde la designación de réplica de recuperación ante desastres.
Consola
Para cambiar la réplica de recuperación ante desastres de una instancia principal, sigue estos pasos:
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca y selecciona la instancia principal. Aparecerá la página Información general de la instancia principal.
- En el menú de navegación, haz clic en Réplicas.
- En la lista de réplicas de lectura, busque la réplica de lectura entre regiones que quiera designar como la nueva réplica de recuperación ante desastres.
- En la réplica, haz clic en el botón more_vert Acciones y selecciona Designar como réplica de recuperación ante desastres.
gcloud
Para cambiar la réplica de recuperación ante desastres, vuelve a ejecutar el comando designate y especifica otra réplica.
REST
Para cambiar la réplica de recuperación ante desastres, vuelve a hacer la solicitud de API designate y especifica otra réplica de recuperación ante desastres.
Ver la designación de la réplica de recuperación ante desastres
Para comprobar qué réplica de recuperación ante desastres se ha asignado a la instancia principal, puedes usar la CLI de gcloud o la API Admin de Cloud SQL. También puedes comprobar si una réplica es una réplica de recuperación ante desastres designada.
Para saber qué réplica de recuperación ante desastres se ha designado para una instancia principal, sigue este procedimiento.
Consola
Para saber qué réplica de lectura es la réplica de recuperación ante desastres designada de una instancia principal, haz lo siguiente:
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca y selecciona la instancia principal. Aparecerá la página Información general de la instancia principal.
- En el menú de navegación, haz clic en Réplicas.
- En la lista de réplicas de lectura, compruebe que
MySQL disaster recovery replica
aparece en la columna Tipo de la réplica de recuperación ante desastres designada.
gcloud
Para saber qué instancia es la réplica de recuperación ante desastres designada de una instancia principal, usa el siguiente comando:
gcloud sql instances describe PRIMARY_INSTANCE_NAME
Sustituye la siguiente variable:
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal
El resultado de este comando contiene el campo llamado failoverDrReplica
, que identifica la réplica de recuperación ante desastres designada.
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 que contiene la instancia.
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
Método HTTP y URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
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 que contiene la instancia.
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
Método HTTP y URL:
GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Para comprobar si una réplica es una réplica de recuperación ante desastres, siga uno de los procedimientos que se indican a continuación.
Consola
Para comprobar si una instancia de réplica es una réplica de recuperación ante desastres, haz lo siguiente:
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca la instancia réplica.
- Verifica que
MySQL disaster recovery replica
aparezca en la columna Tipo de la réplica de recuperación ante desastres designada.
gcloud
Para comprobar si una instancia de réplica es una réplica de recuperación ante desastres, ejecuta el siguiente comando:
gcloud sql instances describe REPLICA_NAME
Sustituye la siguiente variable:
- REPLICA_NAME: el nombre de la réplica de lectura que quieras consultar
Si la réplica es una réplica de recuperación ante desastres, el resultado del comando contiene el campo drReplica=true
.
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 que contiene la instancia.
- REPLICA_NAME: el nombre de la réplica.
Método HTTP y URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir un código de estado que indique que la operación se ha realizado correctamente (2xx) y una respuesta vacía.
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 que contiene la instancia.
- REPLICA_NAME: el nombre de la réplica.
Método HTTP y URL:
GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir un código de estado que indique que la operación se ha realizado correctamente (2xx) y una respuesta vacía.
Eliminar la réplica de recuperación ante desastres
Puedes quitar la designación de réplica de recuperación ante desastres de una instancia principal. Sin embargo, si no se asigna ninguna réplica de recuperación tras fallos a una instancia principal, no podrás realizar una conmutación o una conmutación por error de la réplica.
Consola
Para quitar una réplica de recuperación ante desastres designada de una instancia principal, haga lo siguiente:
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca y selecciona la instancia principal. Aparecerá la página Información general de la instancia principal.
- En el menú de navegación, haz clic en Réplicas.
- En la lista de réplicas de lectura, busca la réplica de lectura entre regiones que quieras eliminar.
- En la réplica, haz clic en el botón more_vert Acciones y selecciona Quitar como réplica de recuperación ante desastres.
- Haz clic en Confirmar.
gcloud
Para quitar la designación de réplica de recuperación ante desastres, ejecuta el siguiente comando en la instancia principal:
gcloud sql instances patch PRIMARY_INSTANCE_NAME \ --clear-failover-dr-replica-name
Sustituye la siguiente variable:
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal de la que quieres quitar la réplica de recuperación ante desastres designada.
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.
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
- Asigna una cadena vacía al campo
failoverDrReplicaName
.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Cuerpo JSON de la solicitud:
{ "replicationCluster": { "failoverDrReplicaName": "" } }
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.
- PRIMARY_INSTANCE_NAME: el nombre de la instancia principal.
- Asigna una cadena vacía al campo
failoverDrReplicaName
.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Cuerpo JSON de la solicitud:
{ "replicationCluster": { "failoverDrReplicaName": "" } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Hacer un cambio
Una vez que hayas designado 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. Una vez que se haya completado esta 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. La cobertura de PITR empieza solo después de que se haya completado esta copia de seguridad. 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:
- Designa una réplica de recuperación ante desastres. Solo puedes hacer un cambio entre la instancia principal y la réplica de recuperación ante desastres designada.
- 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
Consola
Para realizar la operación de cambio, siga estos pasos:
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca la réplica de recuperación ante desastres designada de la instancia principal.
- Haz clic en la instancia de réplica de recuperación ante desastres. Aparecerá la página Resumen de la réplica de recuperación ante desastres.
- Haga clic en el botón Cambiar.
- En la página Perform switchover between the primary and DR replica (Realizar un cambio entre la réplica principal y la de recuperación ante desastres), introduce el nombre de la instancia principal en el campo Instance ID (ID de instancia).
- Haz clic en Cambio.
gcloud
Para realizar la operación de cambio, ejecuta el siguiente comando:
gcloud sql instances switchover REPLICA_NAME [--db-timeout=TIMEOUT_DURATION ]
Sustituye las siguientes variables:
- REPLICA_NAME: el nombre de la réplica de recuperación ante desastres designada con la que quieres que la instancia principal cambie de rol.
- TIMEOUT_DURATION: opcional. Periodo de tiempo de espera para permitir que se completen las operaciones de la base de datos en la instancia.
Si no especificas este parámetro, la operación de cambio incluye un tiempo de espera de 10 minutos.
Puede aumentar el valor de este tiempo de espera especificando el parámetro --db-timeout
. Sustituye TIMEOUT_DURATION por
una duración de hasta 24 horas, incluida la notación inicial del
formato. Por ejemplo, para 30 segundos, especifica 30s
. Para 24 horas, especifica
24h
. También puede especificar unidades fraccionarias de periodo de tiempo
con decimales de hasta 9 posiciones. Por ejemplo, para 30,5 minutos,
especifica 30.5m
.
Si no tienes ninguna operación pendiente, puedes reducir el valor de este tiempo de espera.
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.
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.
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 designada. 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:
- Si aún no lo has hecho, designa una réplica de recuperación ante desastres. Solo puedes realizar una conmutación por error de réplica entre la instancia principal y la réplica de recuperación ante desastres designada.
- Asegúrate de que la réplica de recuperación ante desastres esté online y en buen estado.
Realizar la operación de conmutación por error de la réplica
Consola
Para llevar a cabo la operación de conmutación por error de la réplica, haga lo siguiente:
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca la réplica de recuperación ante desastres designada de la instancia principal.
- Haz clic en la instancia de réplica de recuperación ante desastres. Aparecerá la página Resumen de la réplica de recuperación ante desastres.
- Haz clic en el botón Replica Failover (Conmutación por error de réplica).
- En la página Perform replica failover between the primary and DR replica (Realizar una conmutación por error de la réplica entre la réplica principal y la de recuperación ante desastres), introduzca el nombre de la instancia principal en el campo Instance ID (ID de instancia) para confirmar que quiere continuar con la operación.
- Para iniciar la conmutación por error de la réplica, haz clic en Replica Failover (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 valorfalse
, la API usará el métodopromoteReplica
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 valorfalse
, la API usará el métodopromoteReplica
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.
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:
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca el nombre de la réplica de recuperación ante desastres que has promovido.
- Verifica que MySQL 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
-
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 en el cambio como en la conmutación por error de la réplica, en cuanto la réplica de recuperación ante desastres se convierte en una instancia principal, se producen los siguientes cambios para admitir la copia de seguridad y la recuperación a un momento dado:
- La configuración de la copia de seguridad, incluida la programación de copias de seguridad automáticas, se copia de la instancia principal antigua a la nueva.
- Si se inhabilita, se activa la marca de configuración de binlog para habilitar la restauración a un momento dado.
Se crea una nueva copia de seguridad para admitir PITR en la nueva instancia principal.
La política de conservación de registros de transacciones se copia de la instancia principal antigua a la nueva.
Tanto en el caso de la configuración de la copia de seguridad como en el de las políticas de conservación de registros de transacciones, te recomendamos que verifiques que los ajustes heredados de la instancia principal antigua sean correctos para la nueva instancia principal.
Inicio de la cobertura de PITR
Al final de la operación de cambio, Cloud SQL programa copias de seguridad automáticas y crea la primera copia de seguridad de la nueva instancia principal. Si quieres que la cobertura de PITR empiece cuanto antes, te recomendamos que verifiques que la primera copia de seguridad se ha creado correctamente. La instancia principal recién ascendida tiene cobertura de PITR solo después de que se haya completado correctamente la primera copia de seguridad automática.
Para obtener más información sobre cómo ver las copias de seguridad disponibles de una instancia, consulta Ver una lista de copias de seguridad.
Cobertura de PITR para instancias durante la conmutación y la conmutación por error de réplicas
Cuando una instancia participa en una operación de cambio o de conmutación por error de réplica, la instancia pasa un tiempo como réplica de lectura. PITR y la restauración de una copia de seguridad se admiten durante el periodo en el que la instancia actúa como réplica de lectura y como instancia principal.
Puedes realizar una recuperación a un momento dado anterior al cambio cuando la instancia era una instancia principal. Tanto en las operaciones de cambio como en las de conmutación por error de réplica, Cloud SQL inicia una copia de seguridad con el mejor esfuerzo posible de la nueva instancia principal en cuanto se asciende a la nueva instancia principal. La restauración a un momento dado se habilita en la instancia promocionada solo después de que se complete esta copia de seguridad. Esta copia de seguridad puede tardar entre 5 y 15 minutos en completarse, en función del tamaño del disco.
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
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.
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. |
|
No se puede determinar si no se está produciendo la replicación | Conéctate a la réplica y escribe lo siguiente:
show slave status;
También puede ver el estado de la replicación de las réplicas en el panel de monitorización de Cloud SQL. Para obtener más información, consulta Monitorizar instancias de Cloud SQL. |
Has recibido el siguiente mensaje de error:
|
No puedes realizar una recuperación a un momento dado durante un periodo en el que una instancia haya cambiado a una réplica. Los registros de PITR no están disponibles durante el periodo en el que la instancia era una réplica.
|
Has recibido el siguiente mensaje de error:
|
Tu instancia principal aún no ha cambiado la ubicación de almacenamiento de sus registros de transacciones a Cloud Storage. Puedes volver a intentarlo cuando se haya cambiado la ubicación de almacenamiento de los registros de transacciones o puedes probar a designar una réplica de recuperación ante desastres para otra instancia principal. Para obtener más información sobre cómo cambiar la ubicación de almacenamiento de los registros de transacciones que se usan en la recuperación a un momento dado (PITR), consulta Usar la recuperación a un momento dado (PITR). |
Has recibido el siguiente mensaje de error:
|
Para obtener más información sobre cómo designar una réplica de recuperación ante desastres y la sintaxis correcta del comando, consulta Designar la réplica de recuperación ante desastres de la instancia principal. |
Siguientes pasos
- Consulta todos los Google Cloud servicios disponibles en ubicaciones de todo el mundo.
- Consulta información sobre la observabilidad de bases de datos.
- Monitorizar instancias de Cloud SQL