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

Debes habilitar la recuperación a un momento dado (PITR) en la instancia principal. Para habilitar PITR, consulta Usar la recuperación a un momento dado (PITR).

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 de la base de datos que la instancia principal y ejecutar PostgreSQL 12 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

  • Si se configura con una marca que requiere que la réplica tenga un valor igual o superior al de la instancia principal, la marca debe configurarse con un valor igual al de la instancia principal. Ten en cuenta que, en función del tipo de máquina (nivel) y del tamaño de la instancia de la réplica de recuperación ante desastres, los valores predeterminados pueden ser diferentes aunque no los hayas definido explícitamente. Estas marcas son las siguientes:

    • max_connections
    • max_worker_processes
    • max_wal_senders
    • max_prepared_transactions
    • max_parallel_workers
    • max_locks_per_transaction
    • max_parallel_maintenance_workers
    • max_parallel_workers_per_gather

  • No se puede configurar la marca cloudsql.logical_decoding; no se pueden configurar ranuras lógicas ni replicación lógica

  • 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

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

    Ir a Instancias de Cloud SQL

  2. Busca la instancia principal.
  3. En la columna Acciones, haz clic en el menú Más acciones.
  4. Selecciona Crear réplica de lectura.
  5. En el campo ID de instancia, introduce un nombre para la réplica de recuperación ante desastres.
  6. En el campo Versión de la base de datos, se selecciona la misma versión principal de la instancia principal.
  7. 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.
  8. 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.
  9. En Formas de máquina, selecciona el mismo tipo de máquina que tu instancia principal.
  10. En Flags (Marcas), configura las marcas que necesite tu base de datos.
  11. 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: POSTGRES_16.

    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.

resource "google_sql_database_instance" "original-primary" {
  name   = "postgres-original-primary-instance"
  region = "us-east1"
  # Specify a database version that supports Cloud SQL Enterprise Plus edition.
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  settings {
    # Specify a tier that supports Cloud SQL Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # You must enable automated backups and point-in-time-recovery (PITR).
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

resource "google_sql_database_instance" "dr-replica" {
  name = "postgres-dr-replica-instance"
  # DR replica must be in a different region than the region of the primary instance.
  region = "us-west2"
  # DR replica must be the same database version as the primary instance.
  database_version = "POSTGRES_12"
  instance_type    = "READ_REPLICA_INSTANCE"
  # Specify the primary instance as the master instance.
  master_instance_name = google_sql_database_instance.original-primary.name

  settings {
    # DR replica must be in the same tier as your primary instance and support Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

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.
  • DATABASE_VERSION: Cadena de versión que coincide con la versión de la base de datos de la instancia principal. Por ejemplo, POSTGRES_16. 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.
  • DATABASE_VERSION: Cadena de versión que coincide con la versión de la base de datos de la instancia principal. Por ejemplo, POSTGRES_16. 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:

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

    Ir a Instancias de Cloud SQL

  2. Busca y selecciona la instancia principal. Aparecerá la página Información general de la instancia principal.
  3. En el menú de navegación, haz clic en Réplicas.
  4. 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.
  5. En la réplica, haz clic en el botón more_vert Acciones y selecciona Designar como réplica de recuperación ante desastres.
  6. 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.

data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    # Designate the DR replica.
    # The format for setting the DR replica is `project-id:dr-replica-name`.
    failover_dr_replica_name = "${data.google_project.default.project_id}:postgres-dr-replica-instance"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name                 = "postgres-dr-replica-instance"
  region               = "us-west2"
  database_version     = "POSTGRES_12"
  instance_type        = "READ_REPLICA_INSTANCE"
  master_instance_name = google_sql_database_instance.original-primary.name

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

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

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:

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

    Ir a Instancias de Cloud SQL

  2. Busca y selecciona la instancia principal. Aparecerá la página Información general de la instancia principal.
  3. En el menú de navegación, haz clic en Réplicas.
  4. 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.
  5. 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:

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

    Ir a Instancias de Cloud SQL

  2. Busca y selecciona la instancia principal. Aparecerá la página Información general de la instancia principal.
  3. En el menú de navegación, haz clic en Réplicas.
  4. En la lista de réplicas de lectura, compruebe que PostgreSQL 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:

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

    Ir a Instancias de Cloud SQL

  2. Busca la instancia réplica.
  3. Verifica que PostgreSQL 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 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.
  • 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 una respuesta JSON similar a la siguiente:

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:

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

    Ir a Instancias de Cloud SQL

  2. Busca y selecciona la instancia principal. Aparecerá la página Información general de la instancia principal.
  3. En el menú de navegación, haz clic en Réplicas.
  4. En la lista de réplicas de lectura, busca la réplica de lectura entre regiones que quieras eliminar.
  5. En la réplica, haz clic en el botón more_vert Acciones y selecciona Quitar como réplica de recuperación ante desastres.
  6. 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.
  • Asegúrate de que la réplica de recuperación ante desastres tenga la misma versión de la base de datos que la instancia principal (PostgreSQL 12 o una versión posterior).
  • Asegúrate de que la recuperación a un momento dado esté habilitada en la instancia principal. Para habilitar PITR, consulta Usar la recuperación a un momento dado (PITR).
  • Asegúrate de que la instancia principal y la réplica de recuperación ante desastres no tengan configurada la marca cloudsql.logical_decoding. Ninguna de las instancias puede tener configuradas réplicas lógicas ni ranuras lógicas.
  • 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:

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

    Ir a Instancias de Cloud SQL

  2. Busca la réplica de recuperación ante desastres designada de la instancia principal.
  3. 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.
  4. Haga clic en el botón Cambiar.
  5. 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).
  6. 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.

#
# This sample provides the first part of the switchover operation and turns the DR replica
# into the new primary instance.
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:postgres-dr-replica-instance"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "postgres-dr-replica-instance"
  region           = "us-west2"
  database_version = "POSTGRES_12"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  # Remove or comment out the master_instance_name from the DR replica.
  # master_instance_name = google_sql_database_instance.original-primary.name
  # Add the original primary instance to a list of replicas for the new primary.
  replica_names = [google_sql_database_instance.original-primary.name]

  # Designate the original primary instance as the DR replica of the new primary instance.
  # The format for setting the DR replica is `project-id:dr-replica-name`.
  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Add a backup configuration section to enable automated backups and point-in-time-recovery (PITR) for the new primary instance.
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

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.

# This sample provides the second part of the switchover operation and makes the original primary instance
# a replica of the new primary instance. After you run `terraform apply` for this sample, you'll see
# the following message:
#
# "No changes. Your infrastructure matches the configuration.
#
# Terraform has compared your real infrastructure against your configuration and found no differences,
# so no changes are needed.
#
# Apply complete! Resources: 0 added, 0 changed, 0 destroyed."
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  # Change instance type for the original primary from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  # Set master_instance_name to the the new primary instance, the old DR replica.
  master_instance_name = "postgres-dr-replica-instance"
  # replica_names = [] # If you previously defined a replica_names field in your template, then delete the DR replica
  # (new primary) from the list of replicas.  Don't delete the entire replica_names field.
  # Instead set the field to an empty string. For example, replica_names = [""].

  replication_cluster {
    # This instance no longer requires a designated DR replica since it's a replica.
    # Remove the DR replica designation by setting the field to an empty string.
    failover_dr_replica_name = ""
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Disable automated backups and PITR because this instance is now a replica.
      enabled                        = false
      point_in_time_recovery_enabled = false
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "postgres-dr-replica-instance"
  region           = "us-west2"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"
  replica_names    = [google_sql_database_instance.original-primary.name]


  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

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.
  • Asegúrate de que la réplica de recuperación ante desastres tenga la misma versión de la base de datos que la instancia principal (PostgreSQL 12 o una versión posterior).
  • Asegúrate de que la recuperación a un momento dado esté habilitada en la instancia principal. Para habilitar PITR, consulta Usar la recuperación a un momento dado (PITR).
  • Asegúrate de que la instancia principal y la réplica de recuperación ante desastres no tengan configurada la marca cloudsql.logical_decoding. Ninguna de las instancias puede tener configurados slots lógicos ni replicación lógica. Si invocas la conmutación por error de la réplica y la instancia principal original tiene habilitada la decodificación lógica, cuando la instancia principal original se convierta en una réplica de lectura, se perderán todos los espacios lógicos configurados en la instancia principal original.

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:

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

    Ir a Instancias de Cloud SQL

  2. 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.
  3. Haz clic en el botón Replica Failover (Conmutación por error de réplica).
  4. 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.
  5. 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 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 PostgreSQL VERSION aparezca 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 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.

  • 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.
  • Comprueba el volumen de transacciones de la base de datos. Si el volumen de transacciones es alto, es posible que se agote el tiempo de espera de la operación. Intenta repetir la operación cuando la carga de transacciones sea menor.
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.
  • 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