Se usó la API de Cloud Translation para traducir esta página.

Usa la recuperación de un momento determinado (PITR)

En esta página, se describe cómo usar la recuperación de un momento determinado (PITR) para restablecer la instancia principal de Cloud SQL.

Para obtener más información sobre PITR, consulta Recuperación de un momento determinado (PITR).

De forma predeterminada, la PITR se habilita cuando creas una instancia de edición de Cloud SQL Enterprise Plus, sin importar si creas la instancia con la consola de Google Cloud, gcloud CLI, Terraform o la API de Cloud SQL Admin

Si creas una instancia de Cloud SQL Enterprise en la consola de Google Cloud, la PITR está habilitada de forma predeterminada. De lo contrario, si creas la instancia mediante la CLI de gcloud, Terraform o la API de Cloud SQL Admin, debes habilitar la PITR de forma manual.

Almacenamiento de registros para PITR

Cloud SQL usa registros binarios para la PITR.

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

Todas las instancias de edición de Cloud SQL Enterprise Plus almacenan sus registros binarios que se usan para PITR en Cloud Storage. Solo las instancias de Cloud SQL Enterprise Plus que actualizaste de la edición Cloud SQL Enterprise antes del 1 de abril de 2024 y que tenían habilitada la PITR antes del 11 de agosto de 2023 continúan almacenando sus registros para la PITR en el disco.
Las instancias de Cloud SQL Enterprise creadas con la PITR habilitada antes del 11 de agosto de 2023 seguirán almacenando sus registros para la PITR en el disco.

Nota: En las instancias que se crearon antes del 11 de agosto de 2023, Cloud SQL cambia la ubicación de los registros de transacciones que se usan para la PITR de forma automática. Puedes usar gcloud CLI o la API de Cloud SQL Admin para comprobar dónde se almacenan los registros de transacciones de tu instancia.
Si actualizas una instancia de Cloud SQL Enterprise después del 1 de abril de 2024 que almacena registros de transacciones para PITR en el disco a la edición Cloud SQL Enterprise Plus, el proceso de actualización cambia la ubicación de almacenamiento de los registros de transacciones que se usan para la PITR en Cloud Storage por ti. Para obtener más información, consulta Actualiza una instancia a la edición Cloud SQL Enterprise Plus mediante la actualización in situ.
Todas las instancias de Cloud SQL Enterprise que creas con la PITR habilitada después del 11 de agosto de 2023 almacenan los registros usados para la PITR en Cloud Storage.

Si quieres obtener más información para verificar la ubicación de almacenamiento de los registros de transacciones que se usan en PITR, consulta Verifica la ubicación de almacenamiento de los registros de transacciones que se usan para PITR.

Para 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 PITR del disco a Cloud Storage mediante gcloud CLI o la API de Cloud SQL Admin. Para obtener más información, consulta Cambia el almacenamiento de registros de transacciones a Cloud Storage.

Período de retención de registros

Cloud SQL retiene los registros de transacciones en Cloud Storage hasta el valor establecido en la configuración de la PITR transactionLogRetentionDays. Este valor puede variar de 1 a 35 días para la edición de Cloud SQL Enterprise Plus y de 1 a 7 días para la edición de Cloud SQL Enterprise. Si no se configura un valor para este parámetro, el período predeterminado de retención de registros de transacciones es de 14 días para las instancias de edición de Cloud SQL Enterprise Plus y 7 días para las instancias de Cloud SQL Enterprise. Para obtener más información sobre cómo configurar los días de retención de registros de transacciones, consulta Configura la retención del registro de transacciones.

Aunque una instancia almacena los registros binarios que se usan para PITR en Cloud Storage, la instancia también mantiene una cantidad 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 habilitada, la instancia almacena sus registros binarios para PITR en Cloud Storage. Cloud SQL también establece el valor de las marcas expire_logs_days y binlog_expire_logs_seconds en el equivalente de un día de forma automática. 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 cambiarán a Cloud Storage o que ya se cambiaron a Cloud Storage, Cloud SQL retiene los registros del valor mínimo establecido para una de las siguientes configuraciones:

El parámetro de configuración de la copia de seguridad transactionLogRetentionDays
La marca expire_logs_days o binlog_expire_logs_seconds

Cloud SQL no establece ningún valor para estas marcas si los registros binarios se almacenan en el disco, se están cambiando a Cloud Storage o ya se cambiaron a Cloud Storage. Cuando los registros se almacenan en el disco, modificar los valores de estas marcas puede afectar el comportamiento de la recuperación de PITR y la cantidad de días de registros que se almacenan en el disco. No puedes modificar estos valores mientras la ubicación de almacenamiento de registros está en proceso de cambio a Cloud Storage. Tampoco te recomendamos que configures el valor de ninguna de estas marcas en 0. Para obtener más información sobre las marcas, consulta Configura marcas de base de datos.

En el caso de las instancias que tienen habilitada la clave de encriptación administrada por el cliente (CMEK), los registros de escritura binarios se encriptan con la versión más reciente de la CMEK. A fin de realizar un restablecimiento, todas las versiones de la clave que fueron más recientes para la cantidad de días que configuraste para el parámetro retained-transaction-log-days deben estar disponibles.

Registros y uso del disco

Los registros se generan con regularidad y usan espacio de almacenamiento. Los registros binarios y la copia de seguridad automática que se asocia a ellos se borran de manera automática. Por lo general, esto ocurre luego de que se cumple el valor establecido para transactionLogRetentionDays.

Para saber cuánto disco usan los registros binarios, consulta la métrica bytes_used_by_data_type de la instancia. El valor del tipo de datos binlog muestra el tamaño de los registros binarios en el disco. En el caso de las instancias que almacenan registros de transacciones que se usan para la PITR en el disco, Cloud SQL borra definitivamente los datos del disco a diario para cumplir con la configuración de la PITR transactionLogRetentionDays, como se describe en Copia de seguridad automática. y retención del registro de transacciones. Sin embargo, si configuras la marca expire_logs_days o binlog_expire_logs_seconds en un valor inferior a los días de retención de registros de transacciones, Cloud SQL puede borrar definitivamente los registros binarios antes.

Si el tamaño de tus registros binarios genera un problema en la instancia, haz lo siguiente:

Verifica si tu instancia almacena registros en el disco. Puedes cambiar la ubicación de almacenamiento de los registros que se usan para la PITR del disco a Cloud Storage sin tiempo de inactividad mediante gcloud CLI o la API de Cloud SQL Admin. Si usas Cloud SQL Enterprise, también puedes actualizar a la edición Cloud SQL Enterprise Plus para cambiar la ubicación de almacenamiento de tus registros de PITR.
Puedes aumentar el tamaño del almacenamiento de la instancia, pero el aumento del tamaño de tu registro binario con respecto al uso del disco puede ser temporal.
Te recomendamos que habilites el aumento automático de almacenamiento para evitar problemas inesperados.
Si deseas borrar registros y recuperar espacio de almacenamiento en el disco, puedes desactivar la PITR sin volver a habilitarlo. Sin embargo, disminuir el almacenamiento en uso no reduce el tamaño del disco aprovisionado para la instancia.
Los registros se borran definitivamente una vez al día, no de forma continua. Configurar la retención de registros en dos días implica que se retengan al menos dos días de registros y, como máximo, tres días de registros. Recomendamos configurar la cantidad de copias de seguridad en un día más que los días de retención de registros.

Por ejemplo, si especificas 7 para el valor del parámetro transactionLogRetentionDays, para el parámetro backupRetentionSettings, establece la cantidad de retainedBackups en 8.

Para obtener más información sobre la PITR, consulta Recuperación de un momento determinado (PITR).

Después de completar el cambio de la ubicación de almacenamiento de los registros de transacciones a Cloud Storage, puedes liberar espacio en el disco si reduces los valores de las marcas expire_logs_days y binlog_expire_logs_seconds. Para verificar el estado del interruptor, consulta Verifica la ubicación de almacenamiento de los registros de transacciones que se usan para la PITR. Si deseas que haya registros adicionales disponibles en el disco (por ejemplo, para explorar los registros binarios con la utilidad mysqlbinlog), aumenta los valores de estas marcas. Cloud SQL retiene los registros binarios en el disco durante el mínimo de los días de retención del registro de transacciones o el valor establecido 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 el disco, consulta Registros después del cambio a Cloud Storage.

Habilita la PITR

Cuando creas una instancia nueva en la consola de Google Cloud, las copias de seguridad automáticas y Habilitar la recuperación de un momento determinado están habilitadas de forma automática.

Con el siguiente procedimiento, se habilita la PITR en una instancia principal existente.

Console

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

Ir a Instancias de Cloud SQL
Abre el menú de más acciones para la instancia en la que deseas habilitar PITR y haz clic en Editar.
En Personaliza tu instancia, expande la sección Protección de datos.
Selecciona la casilla de verificación Habilitar la recuperación de un momento determinado.
En el campo Días de registros, ingresa la cantidad de días que se conservarán los registros, de 1 a 35 para la edición de Cloud SQL Enterprise Plus o de 1 a 7 para la edición de Cloud SQL Enterprise.
Haz clic en Guardar.

gcloud

Muestra la descripción general de la instancia:
```
gcloud sql instances describe INSTANCE_NAME
```
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
```
Debes especificar el parámetro backup-start-time mediante el formato de 24 horas en la zona horaria UTC±00.
Habilita la PITR:
```
gcloud sql instances patch INSTANCE_NAME \
--enable-bin-log
```
Si habilitas PITR en una instancia principal, también puedes configurar la cantidad de días para los que deseas conservar los registros de transacciones. Para ello, agrega el siguiente parámetro:
```
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
```
Confirma los cambios:
```
gcloud sql instances describe INSTANCE_NAME
```
En la sección backupConfiguration, verás binaryLogEnabled: true si se realizó correctamente el cambio.

Terraform

Para habilitar la 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"
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Aplique los cambios

Para aplicar tu configuración de Terraform en un proyecto de Google Cloud, completa los pasos de las siguientes secciones.

Prepara Cloud Shell

Inicia Cloud Shell
Establece el proyecto de Google Cloud predeterminado en el que deseas aplicar tus configuraciones de Terraform.

Solo necesitas ejecutar este comando una vez por proyecto y puedes ejecutarlo en cualquier directorio.
```
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
```
Las variables de entorno se anulan si configuras valores explícitos en el archivo de configuración de Terraform.

Prepara el directorio

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

En Cloud Shell, crea un directorio y un archivo nuevo dentro de ese directorio. El nombre del archivo debe tener la extensión .tf, por ejemplo, main.tf. En este instructivo, el archivo se denomina main.tf.
```
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
```
Si sigues un instructivo, puedes copiar el código de muestra en cada sección o paso.

Copia el código de muestra en el main.tf recién creado.

De manera opcional, copia el código de GitHub. Esto se recomienda cuando el fragmento de Terraform es parte de una solución de extremo a extremo.
Revisa y modifica los parámetros de muestra que se aplicarán a tu entorno.
Guarda los cambios.
Inicializa Terraform. Solo debes hacerlo una vez por directorio.
```
terraform init
```
De manera opcional, incluye la opción -upgrade para usar la última versión del proveedor de Google:
```
terraform init -upgrade
```

Aplica los cambios

Revisa la configuración y verifica que los recursos que creará o actualizará Terraform coincidan con tus expectativas:
```
terraform plan
```
Corrige la configuración según sea necesario.
Para aplicar la configuración de Terraform, ejecuta el siguiente comando y, luego, escribe yes cuando se te solicite:
```
terraform apply
```
Espera hasta que Terraform muestre el mensaje “¡Aplicación completa!”.
Abre tu proyecto de Google Cloud para ver los resultados. En la consola de Google Cloud, navega a tus recursos en la IU para asegurarte de que Terraform los haya creado o actualizado.

Borra los cambios

Para borrar tus cambios, haz lo siguiente:

Para inhabilitar la protección contra la eliminación, en tu archivo de configuración de Terraform, establece el argumento deletion_protection en false.
```
deletion_protection =  "false"
```
Para aplicar la configuración actualizada de Terraform, ejecuta el siguiente comando y, luego, ingresa yes cuando se te solicite:
```
terraform apply
```

Quita los recursos que se aplicaron antes con tu configuración de Terraform a través de la ejecución del siguiente comando y, luego, ingresa yes cuando se te solicite:
```
terraform destroy
```

REST v1

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

PROJECT_ID: el ID o el número del proyecto de Google Cloud que contiene la instancia
INSTANCE_NAME: el nombre de la instancia principal o de réplica de lectura que configuras para obtener alta disponibilidad
START_TIME: el tiempo (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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

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

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

PowerShell (Windows)

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

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

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

PROJECT_ID: el ID o el número del proyecto de Google Cloud que contiene la instancia
INSTANCE_NAME: el nombre de la instancia principal o de réplica de lectura que configuras para obtener alta disponibilidad
START_TIME: el tiempo (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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Realizar PITR mediante una marca de tiempo

Using a timestamp is the recommended approach for performing PITR. Cloud SQL usa la utilidad mysqlbinlog para restablecer instancias hasta un momento específico. Si deseas 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:

Registro binario y copias de seguridad habilitados para la instancia, con registros binarios continuos desde la última copia de seguridad antes del evento del que deseas recuperarte. Para obtener más información, consulta Habilita el registro binario.
Es una marca de tiempo para definir el punto de recuperación. Los eventos que ocurren en esta marca de tiempo y después de ella no se reflejan en la instancia nueva.

Console

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

Ir a Instancias de Cloud SQL
Abre el menú de más acciones para la instancia que deseas recuperar y haz clic en Crear clonación.
De manera opcional, en la página Crear una clonación, actualiza el ID de la clonación nueva.
Selecciona Clonar desde un momento anterior.
Ingresa un tiempo de PITR.
Haz clic en Crear clon.

gcloud

Crea un clon con PITR.

Reemplaza lo siguiente:

SOURCE_INSTANCE_NAME: Es el nombre de la instancia desde la que restableces.
NEW_INSTANCE_NAME: Es el nombre para el clon.
TIMESTAMP: Es la zona horaria UTC para 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 cualquiera de los datos de solicitud a continuación, realiza los siguientes reemplazos:

project-id: El ID del proyecto
target-instance-id: El ID de la instancia de destino
source-instance-id: El ID de la instancia de origen
restore-timestamp El momento al que se restablecerá

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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

project-id: El ID del proyecto
target-instance-id: El ID de la instancia de destino
source-instance-id: El ID de la instancia de origen
restore-timestamp El momento al que se restablecerá

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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Desactiva PITR

Console

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

Ir a Instancias de Cloud SQL
Abre el menú de más acciones para la instancia que deseas inhabilitar y selecciona Editar.
En Personaliza tu instancia, expande la sección Protección de datos.
Desmarca la opción Habilitar la recuperación de un momento determinado.
Haz clic en Guardar.

gcloud

Desactiva la recuperación de un momento determinado:

gcloud sql instances patch INSTANCE_NAME \
--no-enable-bin-log

Confirma los cambios:
```
gcloud sql instances describe INSTANCE_NAME
```
En la sección backupConfiguration, verás binaryLogEnabled: false si se realizó correctamente el cambio.

REST v1

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

project-id: el ID del proyecto
instance-id: Es el ID de la 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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id"

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

project-id: el ID del proyecto
instance-id: Es el ID de la 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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id"

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Verifica la ubicación de almacenamiento de los registros de transacciones que se usan para la PITR

Puedes verificar dónde tu instancia de Cloud SQL almacena los registros de transacciones que se usan para la PITR.

gcloud

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

   gcloud sql instances describe INSTANCE_NAME

Reemplaza INSTANCE_NAME por el nombre de la instancia.

También puedes verificar la ubicación de almacenamiento de los registros de transacciones para varias instancias en el mismo proyecto. 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 para la instancia. Los posibles estados de almacenamiento de registros de transacciones son los siguientes:

DISK: la instancia almacena los registros de transacciones que se usan para la PITR en el disco. Si actualizas una instancia de Cloud SQL Enterprise a la edición Cloud SQL Enterprise Plus, el proceso de actualización también cambia la ubicación de almacenamiento de registros a Cloud Storage automáticamente. Para obtener más información, consulta Actualiza una instancia a la edición Cloud SQL Enterprise Plus mediante la actualización in situ. También puedes cambiar la ubicación de almacenamiento con gcloud CLI o la API de Cloud SQL Admin sin actualizar la edición de tu instancia y sin incurrir en ningún tiempo de inactividad. Para obtener más información, consulta Cómo cambiar el almacenamiento de registros de transacciones a Cloud Storage.
SWITCHING_TO_CLOUD_STORAGE: la instancia cambia la ubicación de almacenamiento de los registros de transacciones de la PITR a Cloud Storage.
SWITCHED_TO_CLOUD_STORAGE: La instancia completó el cambio de la ubicación de almacenamiento de los registros de transacciones de la PITR del disco a Cloud Storage.
CLOUD_STORAGE: la instancia almacena los registros de transacciones que se usan para la PITR en Cloud Storage.

Cambia el almacenamiento de registros de transacciones a Cloud Storage

Si tu instancia almacena sus registros de transacciones usados para la PITR en el disco, puedes cambiar la ubicación de almacenamiento a Cloud Storage sin tiempo de inactividad. El proceso general de cambiar la ubicación de almacenamiento tarda aproximadamente la duración del período de retención de registros de transacciones (días) en completarse. En cuanto comiences el cambio, los registros de transacciones comenzarán a acumularse en Cloud Storage. Durante la operación, puedes verificar el estado del proceso general con el comando que se indica en Verifica la ubicación de almacenamiento de los registros de transacciones que se usan para la PITR.

Una vez que se completa el proceso general de cambio a Cloud Storage, Cloud SQL usa los registros de transacciones de Cloud Storage para la PITR.

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

Reemplaza INSTANCE_NAME por el nombre de la instancia. La instancia debe ser una principal y no una de réplica. La respuesta es similar al ejemplo a continuación:

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 muestra un error, consulta Cómo solucionar problemas relacionados con el cambio a Cloud Storage para conocer los posibles pasos a seguir.

REST v1

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

PROJECT_ID: El ID del proyecto.
INSTANCE_ID: El ID de la instancia. La instancia debe ser una principal y no una de 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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Si la solicitud muestra un error, consulta Cómo solucionar problemas relacionados con el cambio a Cloud Storage para conocer los posibles pasos a seguir.

REST v1beta4

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

PROJECT_ID: El ID del proyecto.
INSTANCE_ID: El ID de la instancia. La instancia debe ser una principal y no una de 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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Si la solicitud muestra un error, consulta Cómo solucionar problemas relacionados con el cambio a Cloud Storage para conocer los posibles pasos a seguir.

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

Una vez que se completa el proceso de cambio a Cloud Storage de una instancia, Cloud SQL aún retiene copias de los registros binarios en el disco para fines de replicación. Almacenar registros binarios en el disco puede ser útil si deseas explorarlos con la utilidad mysqlbinlog.

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

Después del cambio, ya que los registros binarios que se usan para realizar la 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 retiene registros en el disco para el valor mínimo de uno de los siguientes:

el parámetro de configuración de la PITR transactionLogRetentionDays anterior al cambio El valor predeterminado para este parámetro es de 7 días.
las marcas expire_logs_days o binlog_expire_logs_seconds que estableciste en tu instancia de forma manual

Si deseas ahorrar espacio en el disco, después de que se complete 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 de disco asignado y los costos de almacenamiento en disco. Para obtener más información sobre el almacenamiento de registros de transacciones y la PITR, consulta Almacenamiento de registros para la PITR.

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

Configura la retención del registro de transacciones

Para establecer la cantidad de días que se retendrán los registros de objetos binarios, haz lo siguiente:

Console

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

Ir a Instancias de Cloud SQL
Abre el menú de más acciones para la instancia en la que deseas establecer el registro de transacciones y selecciona Editar.
En Personaliza tu instancia, expande la sección Protección de datos.
En la sección Habilitar la recuperación de un momento determinado, expande Opciones avanzadas.
Ingresa la cantidad de días que se retendrán los registros, entre 1 y 35 para la edición Cloud SQL Enterprise Plus o 1-7 para la edición Cloud SQL Enterprise.
Haz clic en Guardar.

gcloud

Edita la instancia para establecer la cantidad de días que se retendrán los registros binarios.

Reemplaza lo siguiente:

INSTANCE_NAME: Es el nombre de la instancia en la que deseas configurar el registro de transacciones.
DAYS_TO_RETAIN: Es la cantidad de días de registros de transacciones que se conservarán. Para la edición Enterprise Plus de Cloud SQL, el rango válido es de entre 1 y 35 días, con un valor predeterminado de 14 días. Para la edición Enterprise de Cloud SQL, el rango válido es de entre 1 y 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 PITR. Para conservar más días de registros de transacciones, se requiere un tamaño de almacenamiento mayor.

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

REST v1

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

PROJECT_ID: El ID del proyecto.
INSTANCE_ID: El ID de la instancia.
DAYS_TO_RETAIN: Es la cantidad de días que se retendrán los registros de transacciones. Para la edición Enterprise Plus de Cloud SQL, el rango válido es de entre 1 y 35 días, con un valor predeterminado de 14 días. Para la edición Enterprise de Cloud SQL, el rango válido es de entre 1 y 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 PITR. Para conservar más días de registros de transacciones, se requiere un tamaño de almacenamiento mayor.

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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

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

PROJECT_ID: El ID del proyecto.
INSTANCE_ID: El ID de la instancia.
DAYS_TO_RETAIN: Es la cantidad de días que se retendrán los registros de transacciones. Para la edición Enterprise Plus de Cloud SQL, el rango válido es de entre 1 y 35 días, con un valor predeterminado de 14 días. Para la edición Enterprise de Cloud SQL, el rango válido es de entre 1 y 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 PITR. Para conservar más días de registros de transacciones, se requiere un tamaño de almacenamiento mayor.

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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Realiza PITR mediante posiciones de registros binarios

Si bien te recomendamos que realices una PITR mediante marcas de tiempo como se describe en Realiza PITR con una marca de tiempo, también puedes realizar PITR si proporcionas una posición de registro binario específica en un archivo de registro binario.

Para obtener más información sobre PITR con posiciones de registros binarios, consulta la referencia de MySQL, PITR mediante el registro binario.

Antes de comenzar

Para llevar a cabo esta tarea, debes contar con lo siguiente:

Registro binario y copias de seguridad habilitados para la instancia, con registros binarios continuos desde la última copia de seguridad antes del evento del que deseas recuperarte. Para obtener más información, consulta Habilita el registro binario.
The binary logs must be available on disk for you to browse them for events. To check the retention length of your binary logs on disk, see Log retention period. You can't browse binary logs that are stored in Cloud Storage with the mysqlbinlog utility.
Un nombre de archivo de un registro binario y la posición del evento del que deseas recuperarte (ese evento y todos los posteriores no se reflejarán en la nueva instancia). Para obtener más información, consulta Identifica la posición del registro binario.

Después de identificar el nombre del archivo de registro binario y la posición, realiza PITR mediante posiciones de eventos del registro binario.

Identifica la posición de recuperación

Usa el cliente MySQL a fin de conectarte a la instancia que deseas restablecer.

Para hacerlo, usa Cloud Shell o la máquina cliente local. Si deseas obtener más información, consulta Opciones de conexión para aplicaciones externas.
Muestra los archivos de registro binarios para la instancia:
```
SHOW BINARY LOGS;
```
Muestra los primeros 100 eventos en el archivo de registro binario más reciente:
```
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;
```
Puedes ajustar la cantidad de filas que se muestran, pero no muestres todos los eventos en el archivo hasta que sepas cuál es el tamaño del archivo. Mostrar una gran cantidad de eventos puede afectar el rendimiento del sistema.
Si el evento que buscas no aparece, usa la última posición que se muestra como punto de partida para buscar el siguiente conjunto de eventos:
```
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
```
Cuando encuentres el evento que marca el momento al que deseas restablecerte, registra la posición (se muestra como Pos) y el nombre del archivo de registro binario.

El nombre de archivo del registro binario y la posición son los valores que debes usar para PITR.

A continuación, se muestra un ejemplo del 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 restablecer hasta la declaración DROP TABLE, en negrita, debes usar “865” en “mysql-bin.000011” como posición de recuperación. La declaración DROP TABLE y todas las operaciones posteriores no se reflejan en la nueva instancia.

Realiza PITR mediante posiciones de eventos del registro binario

gcloud

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

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

Reemplaza lo siguiente:
- SOURCE_INSTANCE_NAME: Es el nombre de la instancia desde la que restableces.
- NEW_INSTANCE_NAME: El nombre de la clonación.
- BINLOG_FILE_NAME: Nombre para el registro binario, como mysql-bin.187288.
- POSITION: La posición en el registro binario al que se debe restablecer, 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 puede ser similar al siguiente:
```
gcloud sql instances clone instance1 \
instance1-clone \
--bin-log-file-name=mysql-bin.0000031 \
--bin-log-position=107 \
```
Usa el ID de operación que muestra el comando clone para verificar el estado de la operación de restablecimiento.
```
gcloud sql operations describe OPERATION_ID
```
Cuando la operación está en curso, se muestra el estado RUNNING. Cuando se completa la operación, se muestra el estado DONE.

REST v1

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

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

project-id: El ID del proyecto
target-instance-id: El ID de la instancia de destino
source-instance-id: El ID de la instancia de origen
binary-log-file-name: El nombre del archivo de registro binario
binary-log-position: La posición dentro del 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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

REST v1beta4

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

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

project-id: El ID del proyecto
target-instance-id: El ID de la instancia de destino
source-instance-id: El ID de la instancia de origen
binary-log-file-name: El nombre del archivo de registro binario
binary-log-position: La posición dentro del 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, expande una de estas opciones:

curl (Linux, macOS o Cloud Shell)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone"

PowerShell (Windows)

Guarda el cuerpo de la solicitud en un archivo llamado request.json y ejecuta el siguiente comando:

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

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone" | Select-Object -Expand Content

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

Respuesta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/target-instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "CREATE",
  "name": "operation-id",
  "targetId": "target-instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Solucionar problemas

Problema Soluciona problemas

Problema	Soluciona 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 proporcionaste 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 proporcionaste se debe a una hora en la que no se pudieron encontrar las copias de seguridad o las coordenadas binlog.

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

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 proporcionaste no es válida.

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

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

La marca de tiempo que proporcionaste se debe a una hora en la que no se pudieron encontrar las copias de seguridad o las coordenadas binlog.

Soluciona problemas relacionados con el cambio a Cloud Storage

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

Problema	Soluciona 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 realizar la solicitud a la API en una instancia de Cloud SQL para MySQL o Cloud SQL para PostgreSQL. No se admite cambiar la ubicación de almacenamiento de los registros de transacciones con gcloud CLI o la API de Cloud SQL Admin para Cloud SQL para SQL Server.
`MySQL transactional logging is not enabled on this instance.`	MySQL usa el registro binario como los registros de transacciones para la recuperación de un momento determinado (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 Habilita la PITR.
`This command is not supported on replica instances. Run the command on the primary instance instead.`	Asegúrate de especificar una instancia principal cuando ejecutes el comando o realices la solicitud a 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 Verifica la ubicación de almacenamiento de los registros de transacciones que se usan para la 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 en Verifica la ubicación de almacenamiento de los registros de transacciones que se usan para la PITR.

¿Qué sigue?

Configura marcas en tu clonación.