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 la PITR, consulta 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 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.
  • 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 la PITR, consulta Verifica la ubicación de almacenamiento de los registros de transacciones que se usan para PITR.

En las instancias que almacenan registros binarios solo en el disco, también puedes mover los registros del disco a Cloud Storage si primero desactivas y vuelves a habilitar la PITR.

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 la PITR en Cloud Storage, la instancia también mantiene una cantidad menor de registros binarios duplicados en el disco a fin de permitir la replicación de los registros en Cloud Storage. De forma predeterminada, cuando creas una instancia con la PITR habilitada, la instancia almacena sus registros binarios para la 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.

Mediante la reducción de los valores de estas opciones de configuración de marcas, Cloud SQL te ayuda a ahorrar en costos de uso del disco. Sin embargo, 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.

En el caso de los registros binarios que se usan para la PITR que se almacenan en el disco, Cloud SQL retiene los registros del valor mínimo establecido para una de las siguientes configuraciones:

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

    Modificar los valores de estas marcas puede afectar el comportamiento de la recuperación de la PITR y la cantidad de días de registros que se almacenan en el disco. No recomendamos que configures el valor de ninguna de estas marcas como 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 nuevos 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. Esto sucede después de que se cumple el valor establecido para transactionLogRetentionDays.

Para saber cuánto disco usan los registros binarios, verifica 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 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 mover los registros que se usan para la PITR del disco a Cloud Storage si desactivas y vuelves a habilitar la PITR. Esta operación genera unos minutos de tiempo de inactividad, pero libera espacio en el disco. 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 los registros y recuperar el almacenamiento, puedes desactivar la PITR sin volver a habilitarla. 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 para garantizar un mínimo de días específicos de retención.

Para obtener más información sobre la PITR, consulta PITR.

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

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

    Ir a Instancias de Cloud SQL

  2. Abre el menú de más acciones Ícono de más acciones. para la instancia en la que deseas habilitar la PITR y haz clic en Editar.
  3. En Personaliza tu instancia, expande la sección Protección de datos.
  4. Selecciona la casilla de verificación Habilitar la recuperación de un momento determinado.
  5. Expande Opciones avanzadas.
  6. Ingresa la cantidad de días que se retendrán los registros, entre el 1 y el 35 de la edición de Cloud SQL Enterprise Plus o del 1 al 7 de la edición de Cloud SQL Enterprise.
  7. Haz clic en Guardar.

gcloud

  1. Muestra la descripción 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
    

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

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

    Si habilitas la 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
    
  4. 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
}

Aplica 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

  1. Inicia Cloud Shell
  2. 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).

  1. 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
  2. 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.

  3. Revisa y modifica los parámetros de muestra que se aplicarán a tu entorno.
  4. Guarda los cambios.
  5. Inicialice 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

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

  2. 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!”.

  3. 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:

  1. 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"
  2. Para aplicar la configuración actualizada de Terraform, ejecuta el siguiente comando y, luego, ingresa yes cuando se te solicite:
    terraform apply
  1. 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)

HTTP method and 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:

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

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)

HTTP method and 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:

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

Realiza una PITR mediante una marca de tiempo

El uso de una marca de tiempo es el enfoque recomendado para realizar la PITR. Cloud SQL usa la utilidad mysqlbinlog para restablecer 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:

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

Console

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

    Ir a Instancias de Cloud SQL

  2. Abre el menú de más acciones Ícono de más acciones. para la instancia que deseas recuperar y haz clic en Crear clonación.
  3. De manera opcional, en la página Crear una clonación, actualiza el ID de la clonación nueva.
  4. Selecciona Clonar desde un momento anterior.
  5. Ingresa una hora de PITR.
  6. Haz clic en Crear clon.

gcloud

Crea una clonación 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:

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

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:

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

Inhabilita la PITR

Console

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

    Ir a Instancias de Cloud SQL

  2. Abre el menú de más acciones Ícono de más acciones para la instancia que deseas inhabilitar y selecciona Editar.
  3. En Personaliza tu instancia, expande la sección Protección de datos.
  4. Desmarca la opción Habilitar la recuperación de un momento determinado.
  5. Haz clic en Guardar.
  6. En la página Descripción general de la instancia, en Configuración, la configuración de PITR aparece como inhabilitada.

gcloud

  1. Inhabilita la recuperación de un momento determinado:
    gcloud sql instances patch INSTANCE_NAME \
    --no-enable-bin-log
  2. 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: 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:

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

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

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:

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

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 PITR en el disco o Cloud Storage, usa el siguiente comando:

   gcloud sql instances describe INSTANCE_NAME
   

Reemplaza INSTANCE_NAME por el nombre de la instancia.

En el resultado del comando, el campo transactionalLogStorageState proporciona 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. Para obtener más información, consulta Actualiza una instancia a la edición Cloud SQL Enterprise Plus mediante la actualización in situ.
  • 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 ubicación de almacenamiento para los registros de transacciones de PITR del disco a Cloud Storage.
  • CLOUD_STORAGE: la instancia almacena los registros de transacciones que se usan para la PITR en Cloud Storage.

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:

Consola

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

    Ir a Instancias de Cloud SQL

  2. Abre el menú de más acciones Ícono de más acciones para la instancia en la que deseas establecer el registro de transacciones y selecciona Editar.
  3. En Personaliza tu instancia, expande la sección Protección de datos.
  4. En la sección Habilitar la recuperación de un momento determinado, expande Opciones avanzadas.
  5. 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.
  6. 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 usará el valor predeterminado. Solo es válido cuando la PITR está habilitada. 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:

  • days-to-retain: es la cantidad de días que se retendrán los registros de transacciones, de 1 a 7
  • project-id: El ID del proyecto
  • instance-id: 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":
    {
      "transactionLogRetentionDays": "days-to-retain"
    }
  }
}

Para enviar tu solicitud, expande una de estas opciones:

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

REST v1beta4

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

  • days-to-retain: es la cantidad de días que se retendrán los registros de transacciones, de 1 a 7
  • project-id: El ID del proyecto
  • instance-id: 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":
    {
      "transactionLogRetentionDays": "days-to-retain"
    }
  }
}

Para enviar tu solicitud, expande una de estas opciones:

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

Realiza una PITR mediante posiciones de registros binarios

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

Para obtener más información sobre la PITR mediante posiciones de registro 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.

  • Los registros binarios deben estar disponibles en el disco para que los explores en busca de eventos. Para verificar la longitud de retención de tus registros binarios en el disco, consulta Período de retención de registros. No puedes explorar registros binarios almacenados en Cloud Storage con la utilidad mysqlbinlog.

  • 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 la PITR mediante posiciones de eventos del registro binario.

Identifica la posición de recuperación

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

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

    SHOW BINARY LOGS;
    
  3. 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.

  4. 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;
    
  5. 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 la 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 una 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.

  1. 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 \
  2. 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:

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

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:

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

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

¿Qué sigue?