Usar la recuperación a un momento dado (PITR)

En esta página se describe cómo usar la recuperación a un momento dado (PITR) para restaurar tu instancia principal de Cloud SQL.

Para obtener más información sobre la PITR, consulta el artículo Recuperación a un momento dado (PITR).

Si creas una instancia de la edición Enterprise Plus de Cloud SQL, PITR se habilita de forma predeterminada, independientemente del método que utilices para crearla. Si quieres inhabilitar la función, debes hacerlo manualmente.

Si creas una instancia de la edición Enterprise de Cloud SQL en la Google Cloud consola, la recuperación a un momento dado estará habilitada de forma predeterminada. De lo contrario, si creas la instancia con la interfaz de línea de comandos de gcloud, Terraform o la API Cloud SQL Admin, la restauración a un momento dado estará inhabilitada de forma predeterminada. En este caso, si quieres habilitar la función, debes hacerlo manualmente.

Almacenamiento de registros para PITR

Cloud SQL usa registros binarios para la recuperación a un momento dado.

El 11 de agosto del 2023, lanzamos el almacenamiento de registros de transacciones para PITR en Cloud Storage. Desde este lanzamiento, se aplican las siguientes condiciones:

  • Todas las instancias de la edición Cloud SQL Enterprise Plus almacenan sus registros binarios, que se usan para PITR, en Cloud Storage. Solo las instancias de la edición Cloud SQL Enterprise Plus que actualizaste desde la edición Cloud SQL Enterprise antes del 1 de abril del 2024 y que tenían habilitada la recuperación a un momento dado antes del 11 de agosto del 2023 siguen almacenando sus registros para la recuperación a un momento dado en el disco.
  • Las instancias de la edición Enterprise de Cloud SQL creadas con PITR habilitado antes del 11 de agosto del 2023 seguirán almacenando sus registros para PITR en el disco.

    .
  • Si actualizas a la edición Enterprise Plus de Cloud SQL una instancia de la edición Enterprise de Cloud SQL después del 1 de abril del 2024 que almacena registros de transacciones para la recuperación a un momento dado en el disco, el proceso de actualización cambiará la ubicación de almacenamiento de los registros de transacciones utilizados para la recuperación a un momento dado a Cloud Storage. Para obtener más información, consulta el artículo Actualizar una instancia a la edición Enterprise Plus de Cloud SQL mediante una actualización in situ.

  • Todas las instancias de la edición Enterprise de Cloud SQL que crees con PITR habilitado después del 11 de agosto del 2023 almacenan los registros utilizados para PITR en Cloud Storage.

Para obtener más información sobre cómo comprobar la ubicación de almacenamiento de los registros de transacciones que se usan en la restauración a un momento dado, consulta Comprobar la ubicación de almacenamiento de los registros de transacciones que se usan en la restauración a un momento dado.

En las instancias que almacenan registros binarios solo en el disco, puedes cambiar la ubicación de almacenamiento de los registros de transacciones que se usan para la restauración a un momento dado del disco a Cloud Storage mediante la CLI de gcloud o la API Admin de Cloud SQL sin incurrir en ningún tiempo de inactividad. Para obtener más información, consulta Cambiar el almacenamiento de los registros de transacciones a Cloud Storage.

Periodo de conservación de los registros

Cloud SQL conserva los registros de transacciones en Cloud Storage durante un periodo máximo igual al valor definido en el ajuste de configuración transactionLogRetentionDays PITR. Este valor puede oscilar entre 1 y 35 días en la edición Cloud SQL Enterprise Plus, y entre 1 y 7 días en la edición Cloud SQL Enterprise. Si no se define ningún valor para este parámetro, el periodo de conservación predeterminado de los registros de transacciones es de 14 días para las instancias de la edición Enterprise Plus de Cloud SQL y de 7 días para las instancias de la edición Enterprise de Cloud SQL. Para obtener más información sobre cómo definir los días de conservación del registro de transacciones, consulta Definir la conservación del registro de transacciones.

Aunque una instancia almacena los registros binarios que se usan para la PITR en Cloud Storage, la instancia también conserva un número menor de registros binarios duplicados en el disco para permitir la replicación de los registros en Cloud Storage. De forma predeterminada, cuando creas una instancia con PITR habilitado, la instancia almacena sus registros binarios para PITR en Cloud Storage. Cloud SQL también define automáticamente el valor de las marcas expire_logs_days y binlog_expire_logs_seconds en el equivalente a un día. Esto se traduce en un día de registros en el disco.

En el caso de los registros binarios de PITR que se almacenan en el disco, que se están cambiando a Cloud Storage o que ya se han cambiado a Cloud Storage, Cloud SQL conserva los registros durante el valor mínimo establecido para una de las siguientes configuraciones:

  • El ajuste de configuración de copia de seguridad transactionLogRetentionDays
  • La marca expire_logs_days o binlog_expire_logs_seconds

Cloud SQL no asigna ningún valor a estas marcas si los registros binarios se almacenan en el disco, se están cambiando a Cloud Storage o ya se han cambiado a Cloud Storage. Cuando los registros se almacenan en el disco, modificar los valores de estas marcas puede afectar al comportamiento de la recuperación PITR y al número de días de registros que se almacenan en el disco. Mientras se cambia la ubicación de almacenamiento de los registros a Cloud Storage, no puedes modificar los valores de las marcas. Tampoco le recomendamos que configure ninguno de los valores de las marcas como 0. Para obtener más información, consulta el artículo sobre cómo configurar marcas de bases de datos.

En las instancias con claves de cifrado gestionadas por el cliente (CMEK), los registros binarios se cifran con la versión más reciente de la CMEK. Para realizar una restauración, deben estar disponibles todas las versiones de la clave que hayan sido las más recientes durante el número de días que hayas configurado en el parámetro retained-transaction-log-days.

Registros y uso del disco

Los registros se generan periódicamente y usan espacio de almacenamiento. Los registros binarios se eliminan automáticamente junto con su copia de seguridad automática asociada, lo que ocurre cuando se alcanza el valor definido para transactionLogRetentionDays.

Para saber cuánto espacio en disco están usando los registros binarios, consulta la métrica bytes_used_by_data_type de la instancia. El valor del tipo de datos binlog devuelve el tamaño de los archivos de registro binario en el disco. En las instancias que almacenan registros de transacciones usados para PITR en el disco, Cloud SQL purga los datos del disco a diario para cumplir el ajuste de transactionLogRetentionDaysPITR, tal como se describe en Retención de copias de seguridad automáticas y registros de transacciones. Sin embargo, si asignas a las marcas expire_logs_days o binlog_expire_logs_seconds un valor inferior a los días de conservación de los registros de transacciones, Cloud SQL puede purgar los registros binarios antes.

Si el tamaño de los registros binarios está causando un problema en tu instancia, haz lo siguiente:

  • Comprueba si tu instancia almacena registros en el disco. Puedes cambiar la ubicación de almacenamiento de los registros que usa Cloud SQL para la recuperación a un momento dado del disco a Cloud Storage sin tiempo de inactividad mediante la CLI de gcloud o la API Admin de Cloud SQL. Si usas la edición Enterprise de Cloud SQL, también puedes actualizar a la edición Enterprise Plus de Cloud SQL para cambiar la ubicación de almacenamiento de tus registros de PITR.
  • Puedes aumentar el tamaño del almacenamiento de la instancia. Sin embargo, el aumento del tamaño del registro binario en el uso del disco puede ser temporal.

  • Le recomendamos que habilite el aumento automático del almacenamiento para evitar problemas inesperados con el almacenamiento.

  • Si quieres eliminar los registros y recuperar espacio de almacenamiento en disco, puedes desactivar PITR sin volver a habilitarlo. Sin embargo, reducir el almacenamiento utilizado no disminuye el tamaño del disco aprovisionado para la instancia.

  • Los registros se purgan una vez al día, no de forma continua. Si se establece la retención de registros en dos días, se conservarán al menos dos días de registros y, como máximo, tres. Te recomendamos que definas el número de copias de seguridad como uno más que los días de conservación de registros.

    Por ejemplo, si especifica 7 como valor del parámetro transactionLogRetentionDays, en el parámetro backupRetentionSettings, defina el número de retainedBackups en 8.

Para obtener más información sobre la recuperación a un momento dado, consulta Recuperación a un momento dado (PITR).

Una vez que hayas cambiado la ubicación de almacenamiento de los registros de transacciones a Cloud Storage, puedes liberar espacio en disco reduciendo los valores de las marcas expire_logs_days o binlog_expire_logs_seconds. Para comprobar el estado del interruptor, consulta Comprobar la ubicación de almacenamiento de los registros de transacciones utilizados para la restauración a un momento dado. Si quieres que haya más registros disponibles en el disco (por ejemplo, para consultar los registros binarios con la utilidad mysqlbinlog), aumenta los valores de estas marcas. Cloud SQL conserva los registros binarios en el disco durante el número mínimo de días de conservación de los registros de transacciones o los valores definidos para las marcas. Para obtener más información sobre cómo se almacenan los registros de PITR después del cambio y cómo liberar espacio en disco, consulta Registros después del cambio a Cloud Storage.

Habilitar PITR

Cuando creas una instancia en la consola Google Cloud , las opciones Copias de seguridad automatizadas y Habilitar recuperación a un momento dado se habilitan automáticamente.

El siguiente procedimiento habilita PITR en una instancia principal ya creada.

Consola

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

    Ir a Instancias de Cloud SQL

  2. Abre el menú de más acciones Icono de acciones adicionales. de la instancia en la que quieras habilitar PITR y haz clic en Editar.
  3. En Personalizar tu instancia, amplía la sección Protección de datos.
  4. Selecciona la casilla Habilitar recuperación a un momento dado.
  5. En el campo Días de registros, introduce el número de días que quieres conservar los registros (de 1 a 35 en la edición Enterprise Plus de Cloud SQL o de 1 a 7 en la edición Enterprise de Cloud SQL).
  6. Haz clic en Guardar.

gcloud

  1. Muestra la vista general de la instancia:
    gcloud sql instances describe INSTANCE_NAME
  2. Si ves enabled: false en la sección backupConfiguration, habilita las copias de seguridad programadas:
    gcloud sql instances patch INSTANCE_NAME \
    --backup-start-time=HH:MM

    Especifica el parámetro backup-start-time con el formato de 24 horas en la zona horaria UTC±00.

  3. Habilita PITR:
    gcloud sql instances patch INSTANCE_NAME \
    --enable-bin-log

    Si habilitas PITR en una instancia principal, también puedes configurar el número de días durante los que quieres conservar los registros de transacciones añadiendo el siguiente parámetro:

    --retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
  4. Confirma tu cambio:
    gcloud sql instances describe INSTANCE_NAME

    En la sección backupConfiguration, verás binaryLogEnabled: true si el cambio se ha realizado correctamente.

Terraform

Para habilitar PITR, usa un recurso de Terraform.

resource "google_sql_database_instance" "default" {
  name             = "mysql-instance-pitr"
  region           = "asia-northeast1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-f1-micro"
    backup_configuration {
      enabled                        = true
      binary_log_enabled             = true
      start_time                     = "20:55"
      transaction_log_retention_days = "3"
    }
  }
}

Aplica los cambios

Para aplicar la configuración de Terraform en un proyecto, sigue los pasos que se indican en las siguientes secciones. Google Cloud

Preparar Cloud Shell

  1. Abre Cloud Shell.
  2. Define el Google Cloud proyecto Google Cloud predeterminado en el que quieras aplicar tus configuraciones de Terraform.

    Solo tiene que ejecutar este comando una vez por proyecto y puede hacerlo en cualquier directorio.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Las variables de entorno se anulan si defines valores explícitos en el archivo de configuración de Terraform.

Preparar el directorio

Cada archivo de configuración de Terraform debe tener su propio directorio (también llamado módulo raíz).

  1. En Cloud Shell, crea un directorio y un archivo nuevo en ese directorio. El nombre del archivo debe tener la extensión .tf. Por ejemplo, main.tf. En este tutorial, nos referiremos al archivo como main.tf.
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf
  2. Si estás siguiendo un tutorial, puedes copiar el código de ejemplo de cada sección o paso.

    Copia el código de ejemplo en el archivo main.tf que acabas de crear.

    También puedes copiar el código de GitHub. Se recomienda cuando el fragmento de Terraform forma parte de una solución integral.

  3. Revisa y modifica los parámetros de ejemplo para aplicarlos a tu entorno.
  4. Guarda los cambios.
  5. Inicializa Terraform. Solo tienes que hacerlo una vez por directorio.
    terraform init

    Si quieres usar la versión más reciente del proveedor de Google, incluye la opción -upgrade:

    terraform init -upgrade

Aplica los cambios

  1. Revisa la configuración y comprueba que los recursos que va a crear o actualizar Terraform se ajustan a tus expectativas:
    terraform plan

    Haga las correcciones necesarias en la configuración.

  2. Aplica la configuración de Terraform ejecutando el siguiente comando e introduciendo yes en la petición:
    terraform apply

    Espera hasta que Terraform muestre el mensaje "Apply complete!".

  3. Abre tu Google Cloud proyecto para ver los resultados. En la Google Cloud consola, ve a tus recursos en la interfaz de usuario para asegurarte de que Terraform los ha creado o actualizado.

Eliminar los cambios

Para eliminar los cambios, sigue estos pasos:

  1. Para inhabilitar la protección contra la eliminación, en el archivo de configuración de Terraform, asigna el valor false al argumento deletion_protection.
    deletion_protection =  "false"
  2. Aplica la configuración de Terraform actualizada ejecutando el siguiente comando e introduciendo yes en la petición:
    terraform apply
  1. Para quitar los recursos que se hayan aplicado anteriormente con tu configuración de Terraform, ejecuta el siguiente comando e introduce yes en la petición:

    terraform destroy

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
  • INSTANCE_NAME: el nombre de la instancia principal o de réplica de lectura que estás configurando para la alta disponibilidad
  • START_TIME: la hora (en horas y minutos)

Método HTTP y URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

Cuerpo JSON de la solicitud:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

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
  • INSTANCE_NAME: el nombre de la instancia principal o de réplica de lectura que estás configurando para la alta disponibilidad
  • START_TIME: la hora (en horas y minutos)

Método HTTP y URL:

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

Cuerpo JSON de la solicitud:

{
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

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

Realizar PITR en una instancia no disponible

Consola

Puede que quieras recuperar una instancia que no esté disponible en otra zona por los siguientes motivos:

  • No se puede acceder a la zona en la que está configurada la instancia. Esta instancia tiene el estado FAILED.
  • Se está realizando el mantenimiento de la instancia. Esta instancia tiene el estado MAINTENANCE.

Para recuperar una instancia no disponible, 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 la fila de la instancia que quieras clonar.
  3. En la columna Acciones, haz clic en el menú Más acciones.
  4. Haz clic en Crear clon.
  5. En la página Crear una clonación, haz lo siguiente:
    1. En el campo ID de instancia, actualice el ID de instancia si es necesario.
    2. Haz clic en Clonar desde un momento anterior.
    3. En el campo Punto en el tiempo, selecciona la fecha y la hora a partir de las que quieras clonar los datos. De esta forma, se recupera el estado de la instancia a partir de ese momento.
    4. Haz clic en Crear clon.
  6. Mientras se inicializa el clon, se te redirige a la página de la lista de instancias.

gcloud

Puede que quieras recuperar una instancia que no esté disponible en otra zona porque no se puede acceder a la zona en la que está configurada la instancia.

gcloud sql instances clone SOURCE_INSTANCE_NAME TARGET_INSTANCE_NAME \
--point-in-time DATE_AND_TIME_STAMP \
--preferred-zone ZONE_NAME \
--preferred-secondary-zone SECONDARY_ZONE_NAME

El usuario o la cuenta de servicio que ejecute el comando gcloud sql instances clone debe tener el permiso cloudsql.instances.clone. Para obtener más información sobre los permisos necesarios para ejecutar comandos de gcloud CLI, consulta Permisos de Cloud SQL.

REST v1

Puede que quieras recuperar una instancia que no esté disponible en otra zona porque no se puede acceder a la zona en la que está configurada.

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

  • PROJECT_ID: el ID del proyecto
  • SOURCE_INSTANCE_ID: el ID de instancia de la fuente
  • TARGET_INSTANCE_ID: el ID de instancia de destino

Método HTTP y URL:

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone

Cuerpo JSON de la solicitud:

{
  "cloneContext":
  {
    "destinationInstanceName": "TARGET_INSTANCE_ID"
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

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

El usuario o la cuenta de servicio que use el método de la API instances.clone debe tener el permiso cloudsql.instances.clone. Para obtener más información sobre los permisos necesarios para usar los métodos de la API, consulta Permisos de Cloud SQL.

REST v1beta4

Puede que quieras recuperar una instancia que no esté disponible en otra zona porque no se puede acceder a la zona en la que está configurada.

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

  • PROJECT_ID: el ID del proyecto
  • SOURCE_INSTANCE_ID: el ID de instancia de la fuente
  • TARGET_INSTANCE_ID: el ID de instancia de destino

Método HTTP y URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone

Cuerpo JSON de la solicitud:

{
  "cloneContext":
  {
    "destinationInstanceName": "TARGET_INSTANCE_ID"
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

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

El usuario o la cuenta de servicio que use el método de la API instances.clone debe tener el permiso cloudsql.instances.clone. Para obtener más información sobre los permisos necesarios para usar los métodos de la API, consulta Permisos de Cloud SQL.

Si intentas crear un clon de PITR en un momento posterior a la última hora recuperable, se mostrará el siguiente mensaje de error:

The timestamp for point-in-time recovery is after the latest recovery time of
Timestamp of latest recovery time. Clone the instance with a time
that's earlier than this recovery time.

Obtener el tiempo de recuperación más reciente

En una instancia disponible, puedes realizar PITR hasta la hora más reciente. Si la instancia no está disponible y los registros de la instancia se almacenan en Cloud Storage, puedes obtener la hora de recuperación más reciente y realizar la restauración a un momento dado hasta esa hora. En ambos casos, puede restaurar la instancia en otra zona principal o secundaria proporcionando valores para las zonas preferidas.

gcloud

Obtén la hora más reciente a la que puedes recuperar una instancia de Cloud SQL que no está disponible.

Sustituye INSTANCE_NAME por el nombre de la instancia que estás consultando.

gcloud sql instances get-latest-recovery-time INSTANCE_NAME

REST v1

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

  • PROJECT_ID: el ID del proyecto
  • INSTANCE_NAME: el nombre de la instancia de la que quieres consultar la hora de recuperación más reciente

Método HTTP y URL:

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime

Para enviar tu solicitud, despliega una de estas opciones:

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

{
  "kind": "sql#getLatestRecoveryTime",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

REST v1beta4

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

  • PROJECT_ID: el ID del proyecto
  • INSTANCE_NAME: el nombre de la instancia de la que quieres consultar la hora de recuperación más reciente

Método HTTP y URL:

GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime

Para enviar tu solicitud, despliega una de estas opciones:

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

{
  "kind": "sql#getLatestRecoveryTime",
  "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z"
}

Realizar una recuperación a un momento dado mediante una marca de tiempo

Se recomienda usar una marca de tiempo para realizar una restauración a un momento dado. Cloud SQL usa la utilidad mysqlbinlog para restaurar instancias hasta un momento específico. Para obtener más información sobre la utilidad mysqlbinlog, consulta la documentación de referencia de MySQL.

Para completar la siguiente tarea, debes tener lo siguiente:

  • El registro binario y las copias de seguridad están habilitados en la instancia, con registros binarios continuos desde la última copia de seguridad anterior al evento del que quieras recuperarte. Para obtener más información, consulta Habilitar el registro binario.
  • Marca de tiempo que define el punto de recuperación. Los eventos que se produzcan en esta marca de tiempo y después no se reflejarán en la nueva instancia.

Consola

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

    Ir a Instancias de Cloud SQL

  2. Abre el menú de más acciones Icono de acciones adicionales. de la instancia que quieras recuperar y haz clic en Crear clon.
  3. Opcionalmente, en la página Crear un clon, actualiza el ID del nuevo clon.
  4. Selecciona Clonar desde un momento anterior.
  5. Introduce una hora de PITR.
  6. Haz clic en Crear clon.

gcloud

Crea un clon mediante PITR.

Haz los cambios siguientes:

  • SOURCE_INSTANCE_NAME: nombre de la instancia desde la que vas a restaurar.
  • NEW_INSTANCE_NAME: nombre del clon.
  • TIMESTAMP: zona horaria UTC de la instancia de origen en formato RFC 3339. Por ejemplo, 2012-11-15T16:19:00.094Z.
gcloud sql instances clone SOURCE_INSTANCE_NAME \
NEW_INSTANCE_NAME \
--point-in-time 'TIMESTAMP'

REST v1

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

  • project-id: el ID del proyecto
  • target-instance-id: ID de la instancia de destino
  • source-instance-id: ID de la instancia de origen.
  • restore-timestamp El momento dado hasta el que se debe restaurar

Método HTTP y URL:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone

Cuerpo JSON de la solicitud:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "pointInTime": "restore-timestamp"
  }
}

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 del proyecto
  • target-instance-id: ID de la instancia de destino
  • source-instance-id: ID de la instancia de origen.
  • restore-timestamp El momento dado hasta el que se debe restaurar

Método HTTP y URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone

Cuerpo JSON de la solicitud:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "pointInTime": "restore-timestamp"
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

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

Realizar una PITR con el almacén de copias de seguridad

Si tu instancia de Cloud SQL tiene habilitadas las copias de seguridad mejoradas, puedes realizar una recuperación a un momento dado de tu instancia mediante el archivo de copias de seguridad.

Consola

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

    Ir a Instancias de Cloud SQL

  2. Abre el menú de más acciones Icono de acciones adicionales. de la instancia que quieras recuperar y haz clic en Crear clon.

  3. Selecciona Clonar desde un momento anterior.

  4. Introduce una hora de PITR.

  5. Haz clic en Crear clon.

gcloud

Para realizar una recuperación a un momento dado en una instancia desde el almacén de copias de seguridad, tendrás que buscar el data-source de la copia de seguridad más cercana a la hora en la que quieras realizar la recuperación. Para encontrar la copia de seguridad, consulta Lista de todas las copias de seguridad del almacén de copias de seguridad de una instancia. Una vez que hayas identificado la copia de seguridad, ejecuta el siguiente comando para realizar la restauración a un momento dado:

gcloud sql instances point-in-time-restore DATA_SOURCE
PITR_TIMESTAMP
--project=TARGET_PROJECT

Haz los cambios siguientes:

  • DATA_SOURCE: ruta del data-source de la copia de seguridad más cercana a la marca de tiempo de PITR que quieras recuperar.
  • PITR_TIMESTAMP: marca de tiempo UTC del registro PITR de la instancia de origen a la que quieres restaurar tu instancia, en formato RFC 3339. Por ejemplo, 2012-11-15T16:19:00.094Z.
  • TARGET_PROJECT: el ID de proyecto de tu instancia de Cloud SQL.

REST v1

REST v1beta4

Desactivar PITR

Consola

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

    Ir a Instancias de Cloud SQL

  2. Abre el menú de más acciones Icono de acciones adicionales. de la instancia que quieras desactivar y selecciona Editar.
  3. En Personalizar tu instancia, amplía la sección Protección de datos.
  4. Desmarca Habilitar recuperación a un momento dado.
  5. Haz clic en Guardar.

gcloud

  1. Desactiva la recuperación a un momento dado:
    gcloud sql instances patch INSTANCE_NAME \
    --no-enable-bin-log
  2. Confirma tu cambio:
    gcloud sql instances describe INSTANCE_NAME

    En la sección backupConfiguration, verás binaryLogEnabled: false si el cambio se ha realizado correctamente.

REST v1

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

  • project-id: el ID del proyecto
  • instance-id: el ID de instancia.

Método HTTP y URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

Cuerpo JSON de la solicitud:

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

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 del proyecto
  • instance-id: el ID de instancia.

Método HTTP y URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

Cuerpo JSON de la solicitud:

{
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": false
    }
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

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

Comprobar la ubicación de almacenamiento de los registros de transacciones usados para PITR

Puedes comprobar dónde almacena tu instancia de Cloud SQL los registros de transacciones que se usan para la recuperación a un momento dado.

gcloud

Para determinar si tu instancia almacena registros de PITR en el disco o en Cloud Storage, usa el siguiente comando:

   gcloud sql instances describe INSTANCE_NAME
   

Sustituye INSTANCE_NAME por el nombre de la instancia.

Si hay varias instancias en el mismo proyecto, también puedes consultar la ubicación de almacenamiento de los registros de transacciones. Para determinar la ubicación de varias instancias, usa el siguiente comando:

   gcloud sql instances list --show-transactional-log-storage-state
   

Respuesta de ejemplo:

NAME  DATABASE_VERSION LOCATION       TRANSACTIONAL_LOG_STORAGE_STATE
my_01 MYSQL_8_0        us-central-1     DISK
my_02 MYSQL_8_0        us-central-1     CLOUD_STORAGE
...
   

En el resultado del comando, el campo transactionalLogStorageState o la columna TRANSACTIONAL_LOG_STORAGE_STATE proporcionan información sobre dónde se almacenan los registros de transacciones de PITR de la instancia. Los posibles estados de almacenamiento del registro de transacciones son los siguientes:

  • DISK: la instancia almacena los registros de transacciones que se usan para la recuperación a un momento dado en el disco. Si actualizas una instancia de la edición Enterprise de Cloud SQL a la edición Enterprise Plus, el proceso de actualización cambiará automáticamente la ubicación del almacenamiento de registros a Cloud Storage. Para obtener más información, consulta el artículo Actualizar una instancia a la edición Enterprise Plus de Cloud SQL mediante una actualización in situ. También puedes cambiar la ubicación de almacenamiento con la interfaz de línea de comandos gcloud o la API Cloud SQL Admin sin actualizar la edición de tu instancia y sin que se produzca ningún tiempo de inactividad. Para obtener más información, consulta Cambiar el almacenamiento de los registros de transacciones a Cloud Storage.
  • SWITCHING_TO_CLOUD_STORAGE: la instancia está cambiando la ubicación de almacenamiento de los registros de transacciones de PITR a Cloud Storage.
  • SWITCHED_TO_CLOUD_STORAGE: la instancia ha completado el cambio de la ubicación de almacenamiento de los registros de transacciones de PITR del disco a Cloud Storage.
  • CLOUD_STORAGE: la instancia almacena los registros de transacciones que se usan para PITR en Cloud Storage.

Cambiar el almacenamiento de los registros de transacciones a Cloud Storage

Si tu instancia almacena en disco los registros de transacciones que se usan para la recuperación a un momento dado, puedes cambiar la ubicación de almacenamiento a Cloud Storage sin que se produzca ningún tiempo de inactividad. El proceso general de cambio de la ubicación de almacenamiento tarda aproximadamente lo que dure el periodo de conservación del registro de transacciones (en días) en completarse. En cuanto inicies el cambio, los registros de transacciones empezarán a acumularse en Cloud Storage. Durante la operación, puedes comprobar el estado general del proceso mediante el comando que se indica en Comprobar la ubicación de almacenamiento de los registros de transacciones usados para PITR.

Una vez que se haya completado el proceso general de cambio a Cloud Storage, Cloud SQL usará los registros de transacciones de Cloud Storage para la recuperación a un momento dado.

gcloud

Para cambiar la ubicación de almacenamiento a Cloud Storage, usa el siguiente comando:

   gcloud sql instances patch INSTANCE_NAME \
      --switch-transaction-logs-to-cloud-storage
   

Sustituye INSTANCE_NAME por el nombre de la instancia. La instancia debe ser una instancia principal y no una instancia de réplica. La respuesta es similar a la siguiente:

The following message is used for the patch API method.
{"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"}

Patching Cloud SQL instance...done.
Updated
[https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].
   

Si el comando devuelve un error, consulta la sección Solucionar problemas al cambiar a Cloud Storage para ver los posibles pasos siguientes.

REST v1

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

  • PROJECT_ID: el ID del proyecto.
  • INSTANCE_ID: el ID de instancia. La instancia debe ser una instancia principal y no una instancia réplica.

Método HTTP y URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

Cuerpo JSON de la solicitud:

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

Para enviar tu solicitud, despliega una de estas opciones:

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

Si la solicitud devuelve un error, consulta Solucionar problemas al cambiar a Cloud Storage para ver los posibles pasos siguientes.

REST v1beta4

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

  • PROJECT_ID: el ID del proyecto.
  • INSTANCE_ID: el ID de instancia. La instancia debe ser una instancia principal y no una instancia réplica.

Método HTTP y URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

Cuerpo JSON de la solicitud:

{
   "switchTransactionLogsToCloudStorageEnabled": true
}

Para enviar tu solicitud, despliega una de estas opciones:

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

Si la solicitud devuelve un error, consulta Solucionar problemas al cambiar a Cloud Storage para ver los posibles pasos siguientes.

Almacenamiento y configuración de registros de transacciones después del cambio

Para la replicación, Cloud SQL sigue conservando copias de los registros binarios en el disco.

Si quieres consultar los registros binarios con la utilidad mysqlbinlog, es útil almacenarlos en el disco.

Si configuraste las marcas expire_logs_days o binlog_expire_logs_seconds en tu instancia antes del cambio, los valores configurados se mantendrán.

Después del cambio, como los registros binarios que se usan para realizar PITR ahora se almacenan en Cloud Storage, asegúrate de que los valores de las marcas reflejen la retención de los registros de transacciones en el disco que esperas. Cloud SQL solo conserva los registros en el disco durante el valor mínimo de uno de los siguientes:

  • la transactionLogRetentionDaysconfiguración de PITR antes del cambio. El valor predeterminado de este ajuste es 7 días.
  • las marcas expire_logs_days o binlog_expire_logs_seconds que hayas definido manualmente en tu instancia.

Si quieres ahorrar espacio en disco, una vez que se haya completado el proceso de cambio, configura el valor de las marcas expire_logs_days o binlog_expire_logs_seconds en 1 día para reducir el tamaño del disco asignado y los costes de almacenamiento en disco. Para obtener más información sobre el almacenamiento de registros de transacciones y la recuperación a un punto en el tiempo, consulta Almacenamiento de registros para la recuperación a un punto en el tiempo.

Para obtener más información sobre cómo comprobar el uso del disco, consulta Registros y uso del disco.

Definir la retención de registros de transacciones

Para definir el número de días que se conservarán los registros binarios, sigue estos pasos:

Consola

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

    Ir a Instancias de Cloud SQL

  2. Abre el menú de más acciones Icono de acciones adicionales. de la instancia en la que quieras activar el registro de transacciones y selecciona Editar.
  3. En Personalizar tu instancia, amplía la sección Protección de datos.
  4. En la sección Habilitar recuperación a un momento dado, despliega Opciones avanzadas.
  5. Introduce el número de días que quieres conservar los registros (entre 1 y 35 para la edición Enterprise Plus de Cloud SQL, o entre 1 y 7 para la edición Enterprise de Cloud SQL).
  6. Haz clic en Guardar.

gcloud

Edita la instancia para definir el número de días que se conservarán los registros binarios.

Haz los cambios siguientes:

  • INSTANCE_NAME: el nombre de la instancia en la que quieras definir el registro de transacciones.
  • DAYS_TO_RETAIN: número de días que se conservarán los registros de transacciones. En la edición Enterprise Plus de Cloud SQL, el intervalo válido es de entre 1 y 35 días, con un valor predeterminado de 14 días. En la edición Enterprise de Cloud SQL, el intervalo válido es de 1 a 7 días, con un valor predeterminado de 7 días.

    Si no especifica ningún valor, Cloud SQL usará el valor predeterminado. Esto solo es válido cuando se habilita la recuperación a un momento dado. Para conservar los registros de transacciones durante más días, se necesita un mayor tamaño de almacenamiento.

  gcloud sql instances patch INSTANCE_NAME 
--retained-transaction-log-days=DAYS_TO_RETAIN

REST v1

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

  • PROJECT_ID: el ID del proyecto.
  • INSTANCE_ID: el ID de instancia.
  • DAYS_TO_RETAIN: número de días que se conservarán los registros de transacciones. En la edición Enterprise Plus de Cloud SQL, el intervalo válido es de entre 1 y 35 días, con un valor predeterminado de 14 días. En la edición Enterprise de Cloud SQL, el intervalo válido es de 1 a 7 días, con un valor predeterminado de 7 días.

    Si no se especifica ningún valor, se usa el valor predeterminado. Esto solo es válido cuando se habilita la recuperación a un momento dado. Para conservar los registros de transacciones durante más días, se necesita más espacio de almacenamiento.

Método HTTP y URL:

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

Cuerpo JSON de la solicitud:

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "DAYS_TO_RETAIN"
    }
  }
}

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 del proyecto.
  • INSTANCE_ID: el ID de instancia.
  • DAYS_TO_RETAIN: número de días que se conservarán los registros de transacciones. En la edición Enterprise Plus de Cloud SQL, el intervalo válido es de entre 1 y 35 días, con un valor predeterminado de 14 días. En la edición Enterprise de Cloud SQL, el intervalo válido es de 1 a 7 días, con un valor predeterminado de 7 días.

    Si no se especifica ningún valor, se usa el valor predeterminado. Esto solo es válido cuando se habilita la recuperación a un momento dado. Para conservar los registros de transacciones durante más días, se necesita más espacio de almacenamiento.

Método HTTP y URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

Cuerpo JSON de la solicitud:

{
  "settings":
  {
    "backupConfiguration":
    {
      "transactionLogRetentionDays": "DAYS_TO_RETAIN"
    }
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

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

Realizar una recuperación a un momento dado mediante posiciones de registro binario

Aunque le recomendamos que realice la restauración a un momento dado mediante marcas de tiempo, tal como se describe en Restaurar a un momento dado mediante una marca de tiempo, también puede hacerlo proporcionando una posición específica del registro binario o una posición de evento en un archivo de registro binario.

Para obtener más información sobre la restauración a un momento dado mediante posiciones de registro binario, consulta Restauración a un momento dado mediante el registro binario.

Antes de empezar

Antes de empezar esta tarea, es necesario lo siguiente:

  • El registro binario y las copias de seguridad están habilitados en la instancia, con registros binarios continuos desde la última copia de seguridad anterior al evento del que quieres recuperarte. Para obtener más información, consulta Habilitar el registro binario.

  • Los registros binarios deben estar disponibles en el disco para que puedas buscar eventos en ellos. Para consultar la duración de la retención de los registros binarios en el disco, consulta Periodo de retención de registros. No puedes consultar los registros binarios almacenados en Cloud Storage con la utilidad mysqlbinlog.

  • Nombre de archivo de registro binario y posición del evento que quieres recuperar (ese evento y todos los que se produjeron después no se reflejan en la nueva instancia). Para obtener más información, consulta Identificar la posición del registro binario.

    Una vez que hayas identificado el nombre del archivo de registro binario y la posición, realiza la recuperación a un momento dado mediante las posiciones de los eventos del registro binario.

Identificar la posición de recuperación

  1. Usa el cliente MySQL para conectarte a la instancia en la que quieras restaurar la base de datos.

    Para ello, usa Cloud Shell o tu máquina cliente local. Para obtener más información, consulta Opciones de conexión para aplicaciones externas.

  2. Muestra los archivos de registro binarios de la instancia:

    SHOW BINARY LOGS;
    
  3. Muestra los primeros 100 eventos del archivo de registro binario más reciente:

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;
    

    Puedes ajustar el número de filas que se mostrarán, pero no muestres todos los eventos del archivo hasta que sepas el tamaño del archivo. Mostrar un gran número de eventos puede afectar al rendimiento del sistema.

  4. Si no aparece el evento que buscas, usa la última posición mostrada como punto de partida para buscar el siguiente conjunto de eventos:

    SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
    
  5. Cuando encuentre el evento que marca el momento hasta el que quiere restaurar, anote la posición (que se muestra como Pos) y el nombre del archivo de registro binario.

    El nombre del archivo de registro binario y la posición son los valores que se utilizan para la recuperación a un momento dado.

A continuación, se muestra un ejemplo de resultado del comando SHOW BINLOG EVENTS:

+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
| mysql-bin.000011 |   4 | Format_desc |  88955285 |         120 | Server ver: 5.6.30-log, Binlog ver: 4               |
| mysql-bin.000011 | 120 | Query       |  88955285 |         211 | create database db1                                 |
| mysql-bin.000011 | 211 | Query       |  88955285 |         310 | use `db1`; CREATE TABLE t (c CHAR(20))              |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |
| mysql-bin.000011 | 381 | Table_map   |  88955285 |         426 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 310 | Query       |  88955285 |         381 | BEGIN                                               |

| mysql-bin.000011 | 426 | Write_rows  |  88955285 |         464 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 464 | Xid         |  88955285 |         495 | COMMIT /* xid=56 */                                 |
| mysql-bin.000011 | 495 | Query       |  88955285 |         566 | BEGIN                                               |
| mysql-bin.000011 | 566 | Table_map   |  88955285 |         611 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 611 | Write_rows  |  88955285 |         649 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 649 | Xid         |  88955285 |         680 | COMMIT /* xid=57 */                                 |
| mysql-bin.000011 | 680 | Query       |  88955285 |         751 | BEGIN                                               |
| mysql-bin.000011 | 751 | Table_map   |  88955285 |         796 | table_id: 18 (db1.t)                                |
| mysql-bin.000011 | 796 | Write_rows  |  88955285 |         834 | table_id: 18 flags: STMT_END_F                      |
| mysql-bin.000011 | 834 | Xid         |  88955285 |         865 | COMMIT /* xid=58 */                                 |
| mysql-bin.000011 | 865 | Query       |  88955285 |         977 | use `db1`; DROP TABLE `t` /* generated by server */ |
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+
16 rows in set (0.04 sec)

Para restaurar hasta la instrucción DROP TABLE, que aparece en negrita en el ejemplo anterior, usarías 865 en mysql-bin.000011 como posición de recuperación. La instrucción DROP TABLE y todas las operaciones posteriores no se reflejan en la nueva instancia.

Realizar una recuperación a un momento dado usando posiciones de eventos de registro binario

gcloud

Usa el comando gcloud sql instances clone con las marcas --bin-log-file-name y --bin-log-position.

  1. Crea la nueva instancia con el nombre del archivo de registro binario y la posición de recuperación.

    Haz los cambios siguientes:

    • SOURCE_INSTANCE_NAME: nombre de la instancia desde la que vas a restaurar.
    • NEW_INSTANCE_NAME: nombre de la clonación.
    • BINLOG_FILE_NAME: nombre del registro binario, como mysql-bin.187288.
    • POSITION: la posición del registro binario hasta la que se va a restaurar, como 50001356.
    gcloud sql instances clone SOURCE_INSTANCE_NAME \
    NEW_INSTANCE_NAME \
    --bin-log-file-name="BINLOG_FILE_NAME" \
    --bin-log-position=POSITION

    Por ejemplo, un comando gcloud sql instances clone podría tener un aspecto similar al siguiente:

    gcloud sql instances clone instance1 \
    instance1-clone \
    --bin-log-file-name=mysql-bin.0000031 \
    --bin-log-position=107 \
  2. Usa el ID de operación devuelto por el comando clone para comprobar el estado de la operación de restauración.
    gcloud sql operations describe OPERATION_ID

    Cuando la operación está en curso, se devuelve el estado RUNNING. Cuando se completa la operación, se devuelve el estado DONE.

REST v1

Crea la nueva instancia con el nombre del archivo de registro binario y la posición de recuperación que has identificado:

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

  • project-id: el ID del proyecto
  • target-instance-id: ID de la instancia de destino
  • source-instance-id: ID de la instancia de origen.
  • binary-log-file-name Nombre del archivo de registro binario
  • binary-log-position La posición en el archivo de registro binario

Método HTTP y URL:

POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone

Cuerpo JSON de la solicitud:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

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

REST v1beta4

Crea la nueva instancia con el nombre del archivo de registro binario y la posición de recuperación que has identificado:

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

  • project-id: el ID del proyecto
  • target-instance-id: ID de la instancia de destino
  • source-instance-id: ID de la instancia de origen.
  • binary-log-file-name Nombre del archivo de registro binario
  • binary-log-position La posición en el archivo de registro binario

Método HTTP y URL:

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone

Cuerpo JSON de la solicitud:

{
  "cloneContext":
  {
    "kind": "sql#cloneContext",
    "destinationInstanceName": "target-instance-id",
    "binLogCoordinates":
    {
      "kind": "sql#binLogCoordinates",
      "binLogFileName": "binary-log-file-name",
      "binLogPosition": "binary-log-position"
    }
  }
}

Para enviar tu solicitud, despliega una de estas opciones:

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

Solucionar problemas

Problema Solución de problemas

argument --point-in-time: Failed to parse date/time:
Unknown string format: 2021-0928T30:54:03.094;
received: 2021-0928T30:54:03.094Z

O

Invalid value at 'body.clone_context.point_in_time'
(type.googleapis.com/google.protobuf.Timestamp), Field 'pointInTime',
Invalid time format: Failed to parse input,

La marca de tiempo que has proporcionado no es válida.

HTTP Error 400: Successful backup required for carrying out the operation was not found.

O

Successful backup required for carrying out the operation was not found. or Time where no backups can be found.

La marca de tiempo que has proporcionado corresponde a un momento en el que no se han podido encontrar copias de seguridad ni coordenadas de binlog.

Solucionar problemas al cambiar a Cloud Storage

En la siguiente tabla se enumeran los posibles errores que pueden devolverse con el código INVALID REQUEST al cambiar la ubicación de almacenamiento de los registros de transacciones del disco a Cloud Storage.

Problema Solución de problemas
Switching the storage location of the transaction logs used for PITR is not supported for instances with database type %s. Asegúrate de ejecutar el comando gcloud CLI o de hacer la solicitud de API en una instancia de Cloud SQL para MySQL o Cloud SQL para PostgreSQL. No se puede cambiar la ubicación de almacenamiento de los registros de transacciones mediante la CLI de gcloud o la API Cloud SQL Admin en Cloud SQL para SQL Server.
MySQL transactional logging is not enabled on this instance. MySQL usa el registro binario como registros de transacciones para la recuperación a un momento dado (PITR). Para admitir PITR, MySQL requiere que habilites el registro binario en la instancia. Para obtener más información sobre cómo habilitar el registro binario, consulta Habilitar PITR.
This command is not supported on replica instances. Run the command on the primary instance instead. Asegúrese de especificar una instancia principal al ejecutar el comando o al hacer la solicitud de la API.
This instance is already storing transaction logs used for PITR in Cloud Storage Para verificar la ubicación de almacenamiento de los registros de transacciones, ejecuta el comando que se indica en Comprobar la ubicación de almacenamiento de los registros de transacciones utilizados para PITR.
The instance is already switching transaction logs used for PITR from disk to Cloud Storage.

Espera a que se complete la operación de cambio.

Para verificar el estado de la operación y la ubicación de almacenamiento de los registros de transacciones, ejecuta el comando que se indica en Comprobar la ubicación de almacenamiento de los registros de transacciones utilizados para la recuperación a un momento dado.

Siguientes pasos