En esta página se describe cómo usar la recuperación a un momento dado (PITR) para restaurar tu instancia principal de Cloud SQL.
Para obtener más información sobre la PITR, consulta el artículo Recuperación a un momento dado (PITR).
Si creas una instancia de la edición Enterprise Plus de Cloud SQL, PITR se habilita de forma predeterminada, independientemente del método que utilices para crearla. Si quieres inhabilitar la función, debes hacerlo manualmente.
Si creas una instancia de la edición Enterprise de Cloud SQL en la Google Cloud consola, la recuperación a un momento dado estará habilitada de forma predeterminada. De lo contrario, si creas la instancia con la interfaz de línea de comandos de gcloud, Terraform o la API Cloud SQL Admin, la restauración a un momento dado estará inhabilitada de forma predeterminada. En este caso, si quieres habilitar la función, debes hacerlo manualmente.
Almacenamiento de registros para PITR
Cloud SQL usa registros binarios para la recuperación a un momento dado.El 11 de agosto del 2023, lanzamos el almacenamiento de registros de transacciones para PITR en Cloud Storage. Desde este lanzamiento, se aplican las siguientes condiciones:
- Todas las instancias de la edición Cloud SQL Enterprise Plus almacenan sus registros binarios, que se usan para PITR, en Cloud Storage. Solo las instancias de la edición Cloud SQL Enterprise Plus que actualizaste desde la edición Cloud SQL Enterprise antes del 1 de abril del 2024 y que tenían habilitada la recuperación a un momento dado antes del 11 de agosto del 2023 siguen almacenando sus registros para la recuperación a un momento dado en el disco.
Las instancias de la edición Enterprise de Cloud SQL creadas con PITR habilitado antes del 11 de agosto del 2023 seguirán almacenando sus registros para PITR en el disco.
.Si actualizas a la edición Enterprise Plus de Cloud SQL una instancia de la edición Enterprise de Cloud SQL después del 1 de abril del 2024 que almacena registros de transacciones para la recuperación a un momento dado en el disco, el proceso de actualización cambiará la ubicación de almacenamiento de los registros de transacciones utilizados para la recuperación a un momento dado a Cloud Storage. Para obtener más información, consulta el artículo Actualizar una instancia a la edición Enterprise Plus de Cloud SQL mediante una actualización in situ.
Todas las instancias de la edición Enterprise de Cloud SQL que crees con PITR habilitado después del 11 de agosto del 2023 almacenan los registros utilizados para PITR en Cloud Storage.
Para obtener más información sobre cómo comprobar la ubicación de almacenamiento de los registros de transacciones que se usan en la restauración a un momento dado, consulta Comprobar la ubicación de almacenamiento de los registros de transacciones que se usan en la restauración a un momento dado.
En las instancias que almacenan registros binarios solo en el disco, puedes cambiar la ubicación de almacenamiento de los registros de transacciones que se usan para la restauración a un momento dado del disco a Cloud Storage mediante la CLI de gcloud o la API Admin de Cloud SQL sin incurrir en ningún tiempo de inactividad. Para obtener más información, consulta Cambiar el almacenamiento de los registros de transacciones a Cloud Storage.
Periodo de conservación de los registros
Cloud SQL conserva los registros de transacciones en Cloud Storage durante un periodo máximo igual al valor definido en el ajuste de configuración transactionLogRetentionDays
PITR.
Este valor puede oscilar entre 1 y 35 días en la edición Cloud SQL Enterprise Plus, y entre 1 y 7 días en la edición Cloud SQL Enterprise. Si no se define ningún valor para este parámetro, el periodo de conservación predeterminado de los registros de transacciones es de 14 días para las instancias de la edición Enterprise Plus de Cloud SQL y de 7 días para las instancias de la edición Enterprise de Cloud SQL. Para obtener más información sobre cómo definir los días de conservación del registro de transacciones, consulta Definir la conservación del registro de transacciones.
Aunque una instancia almacena los registros binarios que se usan para la PITR en Cloud Storage, la instancia también conserva un número menor de registros binarios duplicados en el disco para permitir la replicación de los registros en Cloud Storage. De forma predeterminada, cuando creas una instancia con PITR habilitado, la instancia almacena sus registros binarios para PITR en Cloud Storage. Cloud SQL también define automáticamente el valor de las marcas expire_logs_days
y binlog_expire_logs_seconds
en el equivalente a un día. Esto se traduce en un día de registros en el disco.
En el caso de los registros binarios de PITR que se almacenan en el disco, que se están cambiando a Cloud Storage o que ya se han cambiado a Cloud Storage, Cloud SQL conserva los registros durante el valor mínimo establecido para una de las siguientes configuraciones:
- El ajuste de configuración de copia de seguridad
transactionLogRetentionDays
- La marca
expire_logs_days
obinlog_expire_logs_seconds
Cloud SQL no asigna ningún valor a estas marcas si los registros binarios se almacenan en el disco, se están cambiando a Cloud Storage o ya se han cambiado a Cloud Storage. Cuando los registros se almacenan en el disco, modificar los valores de estas marcas puede afectar al comportamiento de la recuperación PITR y al número de días de registros que se almacenan en el disco. Mientras se cambia la ubicación de almacenamiento de los registros a Cloud Storage, no puedes modificar los valores de las marcas.
Tampoco le recomendamos que configure ninguno de los valores de las marcas como 0
. Para obtener más información, consulta el artículo sobre cómo configurar marcas de bases de datos.
En las
instancias con claves de cifrado gestionadas por el cliente (CMEK), los registros binarios se cifran con la versión más reciente de la CMEK. Para realizar una restauración, deben estar disponibles todas las versiones de la clave que hayan sido las más recientes durante el número de días que hayas configurado en el parámetro
retained-transaction-log-days
.
Registros y uso del disco
Los registros se generan periódicamente y usan espacio de almacenamiento. Los registros binarios se eliminan automáticamente junto con su copia de seguridad automática asociada, lo que ocurre cuando se alcanza el valor definido para transactionLogRetentionDays
.
Para saber cuánto espacio en disco están usando los registros binarios, consulta la métrica bytes_used_by_data_type
de la instancia. El valor del tipo de datos binlog
devuelve el tamaño de los archivos de registro binario en el disco. En las instancias que almacenan registros de transacciones usados para PITR en el disco, Cloud SQL purga los datos del disco a diario para cumplir el ajuste de transactionLogRetentionDays
PITR, tal como se describe en Retención de copias de seguridad automáticas y registros de transacciones.
Sin embargo, si asignas a las marcas expire_logs_days
o binlog_expire_logs_seconds
un valor inferior a los días de conservación de los registros de transacciones, Cloud SQL puede purgar los registros binarios antes.
Si el tamaño de los registros binarios está causando un problema en tu instancia, haz lo siguiente:
- Comprueba si tu instancia almacena registros en el disco. Puedes cambiar la ubicación de almacenamiento de los registros que usa Cloud SQL para la recuperación a un momento dado del disco a Cloud Storage sin tiempo de inactividad mediante la CLI de gcloud o la API Admin de Cloud SQL. Si usas la edición Enterprise de Cloud SQL, también puedes actualizar a la edición Enterprise Plus de Cloud SQL para cambiar la ubicación de almacenamiento de tus registros de PITR.
Puedes aumentar el tamaño del almacenamiento de la instancia. Sin embargo, el aumento del tamaño del registro binario en el uso del disco puede ser temporal.
Le recomendamos que habilite el aumento automático del almacenamiento para evitar problemas inesperados con el almacenamiento.
Si quieres eliminar los registros y recuperar espacio de almacenamiento en disco, puedes desactivar PITR sin volver a habilitarlo. Sin embargo, reducir el almacenamiento utilizado no disminuye el tamaño del disco aprovisionado para la instancia.
Los registros se purgan una vez al día, no de forma continua. Si se establece la retención de registros en dos días, se conservarán al menos dos días de registros y, como máximo, tres. Te recomendamos que definas el número de copias de seguridad como uno más que los días de conservación de registros.
Por ejemplo, si especifica
7
como valor del parámetrotransactionLogRetentionDays
, en el parámetrobackupRetentionSettings
, defina el número deretainedBackups
en8
.
Para obtener más información sobre la recuperación a un momento dado, consulta Recuperación a un momento dado (PITR).
Una vez que hayas cambiado la ubicación de almacenamiento de los registros de transacciones a Cloud Storage, puedes liberar espacio en disco reduciendo los valores de las marcas expire_logs_days
o binlog_expire_logs_seconds
. Para comprobar el estado del interruptor, consulta Comprobar la ubicación de almacenamiento de los registros de transacciones utilizados para la restauración a un momento dado.
Si quieres que haya más registros disponibles en el disco (por ejemplo, para consultar los registros binarios con la utilidad mysqlbinlog
), aumenta los valores de estas marcas. Cloud SQL conserva los registros binarios en el disco durante el número mínimo de días de conservación de los registros de transacciones o los valores definidos para las marcas. Para obtener más información sobre cómo se almacenan los registros de PITR después del cambio y cómo liberar espacio en disco, consulta Registros después del cambio a Cloud Storage.
Habilitar PITR
Cuando creas una instancia en la consola Google Cloud , las opciones Copias de seguridad automatizadas y Habilitar recuperación a un momento dado se habilitan automáticamente.El siguiente procedimiento habilita PITR en una instancia principal ya creada.
Consola
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Abre el menú de más acciones
de la instancia en la que quieras habilitar PITR y haz clic en Editar.
- En Personalizar tu instancia, amplía la sección Protección de datos.
- Selecciona la casilla Habilitar recuperación a un momento dado.
- En el campo Días de registros, introduce el número de días que quieres conservar los registros (de 1 a 35 en la edición Enterprise Plus de Cloud SQL o de 1 a 7 en la edición Enterprise de Cloud SQL).
- Haz clic en Guardar.
gcloud
- Muestra la vista general de la instancia:
gcloud sql instances describe INSTANCE_NAME
- Si ves
enabled: false
en la secciónbackupConfiguration
, habilita las copias de seguridad programadas:gcloud sql instances patch INSTANCE_NAME \ --backup-start-time=HH:MM
Especifica el parámetro
backup-start-time
con el formato de 24 horas en la zona horaria UTC±00. - Habilita PITR:
gcloud sql instances patch INSTANCE_NAME \ --enable-bin-log
Si habilitas PITR en una instancia principal, también puedes configurar el número de días durante los que quieres conservar los registros de transacciones añadiendo el siguiente parámetro:
--retained-transaction-log-days=RETAINED_TRANSACTION_LOG_DAYS
- Confirma tu cambio:
gcloud sql instances describe INSTANCE_NAME
En la sección
backupConfiguration
, verásbinaryLogEnabled: true
si el cambio se ha realizado correctamente.
Terraform
Para habilitar PITR, usa un recurso de Terraform.
Aplica los cambios
Para aplicar la configuración de Terraform en un proyecto, sigue los pasos que se indican en las siguientes secciones. Google Cloud
Preparar Cloud Shell
- Abre Cloud Shell.
-
Define el Google Cloud proyecto Google Cloud predeterminado en el que quieras aplicar tus configuraciones de Terraform.
Solo tiene que ejecutar este comando una vez por proyecto y puede hacerlo en cualquier directorio.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Las variables de entorno se anulan si defines valores explícitos en el archivo de configuración de Terraform.
Preparar el directorio
Cada archivo de configuración de Terraform debe tener su propio directorio (también llamado módulo raíz).
-
En Cloud Shell, crea un directorio y un archivo nuevo en ese directorio. El nombre del archivo debe tener la extensión
.tf
. Por ejemplo,main.tf
. En este tutorial, nos referiremos al archivo comomain.tf
.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
Si estás siguiendo un tutorial, puedes copiar el código de ejemplo de cada sección o paso.
Copia el código de ejemplo en el archivo
main.tf
que acabas de crear.También puedes copiar el código de GitHub. Se recomienda cuando el fragmento de Terraform forma parte de una solución integral.
- Revisa y modifica los parámetros de ejemplo para aplicarlos a tu entorno.
- Guarda los cambios.
-
Inicializa Terraform. Solo tienes que hacerlo una vez por directorio.
terraform init
Si quieres usar la versión más reciente del proveedor de Google, incluye la opción
-upgrade
:terraform init -upgrade
Aplica los cambios
-
Revisa la configuración y comprueba que los recursos que va a crear o actualizar Terraform se ajustan a tus expectativas:
terraform plan
Haga las correcciones necesarias en la configuración.
-
Aplica la configuración de Terraform ejecutando el siguiente comando e introduciendo
yes
en la petición:terraform apply
Espera hasta que Terraform muestre el mensaje "Apply complete!".
- Abre tu Google Cloud proyecto para ver los resultados. En la Google Cloud consola, ve a tus recursos en la interfaz de usuario para asegurarte de que Terraform los ha creado o actualizado.
Eliminar los cambios
Para eliminar los cambios, sigue estos pasos:
- Para inhabilitar la protección contra la eliminación, en el archivo de configuración de Terraform, asigna el valor
false
al argumentodeletion_protection
.deletion_protection = "false"
- Aplica la configuración de Terraform actualizada ejecutando el siguiente comando e introduciendo
yes
en la petición:terraform apply
-
Para quitar los recursos que se hayan aplicado anteriormente con tu configuración de Terraform, ejecuta el siguiente comando e introduce
yes
en la petición:terraform destroy
REST v1
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID o el número de proyecto del Google Cloud proyecto que contiene la instancia
- INSTANCE_NAME: el nombre de la instancia principal o de réplica de lectura que estás configurando para la alta disponibilidad
- START_TIME: la hora (en horas y minutos)
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME
Cuerpo JSON de la solicitud:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "binaryLogEnabled": true } } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
REST v1beta4
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID o el número de proyecto del Google Cloud proyecto que contiene la instancia
- INSTANCE_NAME: el nombre de la instancia principal o de réplica de lectura que estás configurando para la alta disponibilidad
- START_TIME: la hora (en horas y minutos)
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME
Cuerpo JSON de la solicitud:
{ "settings": { "backupConfiguration": { "startTime": "START_TIME", "enabled": true, "binaryLogEnabled": true } } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Realizar PITR en una instancia no disponible
Consola
Puede que quieras recuperar una instancia que no esté disponible en otra zona por los siguientes motivos:
- No se puede acceder a la zona en la que está configurada la instancia. Esta
instancia tiene el estado
FAILED
. - Se está realizando el mantenimiento de la instancia. Esta instancia tiene el estado
MAINTENANCE
.
Para recuperar una instancia no disponible, sigue estos pasos:
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Busca la fila de la instancia que quieras clonar.
- En la columna Acciones, haz clic en el menú Más acciones.
- Haz clic en Crear clon.
- En la página Crear una clonación, haz lo siguiente:
- En el campo ID de instancia, actualice el ID de instancia si es necesario.
- Haz clic en Clonar desde un momento anterior.
- En el campo Punto en el tiempo, selecciona la fecha y la hora a partir de las que quieras clonar los datos. De esta forma, se recupera el estado de la instancia a partir de ese momento.
- Haz clic en Crear clon.
Mientras se inicializa el clon, se te redirige a la página de la lista de instancias.
gcloud
Puede que quieras recuperar una instancia que no esté disponible en otra zona porque no se puede acceder a la zona en la que está configurada la instancia.
gcloud sql instances clone SOURCE_INSTANCE_NAME TARGET_INSTANCE_NAME \ --point-in-time DATE_AND_TIME_STAMP \ --preferred-zone ZONE_NAME \ --preferred-secondary-zone SECONDARY_ZONE_NAME
El usuario o la cuenta de servicio que ejecute el comando gcloud sql instances clone
debe tener el permiso cloudsql.instances.clone
. Para obtener más información sobre los permisos necesarios para ejecutar comandos de gcloud CLI, consulta Permisos de Cloud SQL.
REST v1
Puede que quieras recuperar una instancia que no esté disponible en otra zona porque no se puede acceder a la zona en la que está configurada.
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID del proyecto
- SOURCE_INSTANCE_ID: el ID de instancia de la fuente
- TARGET_INSTANCE_ID: el ID de instancia de destino
Método HTTP y URL:
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone
Cuerpo JSON de la solicitud:
{ "cloneContext": { "destinationInstanceName": "TARGET_INSTANCE_ID" } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
El usuario o la cuenta de servicio que use el método de la API instances.clone
debe tener el permiso cloudsql.instances.clone
. Para obtener más información sobre los permisos necesarios para usar los métodos de la API, consulta Permisos de Cloud SQL.
REST v1beta4
Puede que quieras recuperar una instancia que no esté disponible en otra zona porque no se puede acceder a la zona en la que está configurada.
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID del proyecto
- SOURCE_INSTANCE_ID: el ID de instancia de la fuente
- TARGET_INSTANCE_ID: el ID de instancia de destino
Método HTTP y URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/SOURCE_INSTANCE_NAME/clone
Cuerpo JSON de la solicitud:
{ "cloneContext": { "destinationInstanceName": "TARGET_INSTANCE_ID" } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
El usuario o la cuenta de servicio que use el método de la API instances.clone
debe tener el permiso cloudsql.instances.clone
. Para obtener más información sobre los permisos necesarios para usar los métodos de la API, consulta Permisos de Cloud SQL.
Si intentas crear un clon de PITR en un momento posterior a la última hora recuperable, se mostrará el siguiente mensaje de error:
The timestamp for point-in-time recovery is after the latest recovery time of Timestamp of latest recovery time. Clone the instance with a time that's earlier than this recovery time.
Obtener el tiempo de recuperación más reciente
En una instancia disponible, puedes realizar PITR hasta la hora más reciente. Si la instancia no está disponible y los registros de la instancia se almacenan en Cloud Storage, puedes obtener la hora de recuperación más reciente y realizar la restauración a un momento dado hasta esa hora. En ambos casos, puede restaurar la instancia en otra zona principal o secundaria proporcionando valores para las zonas preferidas.
gcloud
Obtén la hora más reciente a la que puedes recuperar una instancia de Cloud SQL que no está disponible.
Sustituye INSTANCE_NAME por el nombre de la instancia que estás consultando.
gcloud sql instances get-latest-recovery-time INSTANCE_NAME
REST v1
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID del proyecto
- INSTANCE_NAME: el nombre de la instancia de la que quieres consultar la hora de recuperación más reciente
Método HTTP y URL:
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
{ "kind": "sql#getLatestRecoveryTime", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
REST v1beta4
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID del proyecto
- INSTANCE_NAME: el nombre de la instancia de la que quieres consultar la hora de recuperación más reciente
Método HTTP y URL:
GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME/getLatestRecoveryTime
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
{ "kind": "sql#getLatestRecoveryTime", "latestRecoveryTime": "2023-06-20T17:23:59.648821586Z" }
Realizar una recuperación a un momento dado mediante una marca de tiempo
Se recomienda usar una marca de tiempo para realizar una restauración a un momento dado.
Cloud SQL usa la utilidad mysqlbinlog
para restaurar instancias hasta un momento específico. Para obtener más información sobre la utilidad mysqlbinlog
, consulta la documentación de referencia de MySQL.
Para completar la siguiente tarea, debes tener lo siguiente:
- El registro binario y las copias de seguridad están habilitados en la instancia, con registros binarios continuos desde la última copia de seguridad anterior al evento del que quieras recuperarte. Para obtener más información, consulta Habilitar el registro binario.
- Marca de tiempo que define el punto de recuperación. Los eventos que se produzcan en esta marca de tiempo y después no se reflejarán en la nueva instancia.
Consola
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Abre el menú de más acciones
de la instancia que quieras recuperar y haz clic en Crear clon.
- Opcionalmente, en la página Crear un clon, actualiza el ID del nuevo clon.
- Selecciona Clonar desde un momento anterior.
- Introduce una hora de PITR.
- Haz clic en Crear clon.
gcloud
Crea un clon mediante PITR.
Haz los cambios siguientes:
- SOURCE_INSTANCE_NAME: nombre de la instancia desde la que vas a restaurar.
- NEW_INSTANCE_NAME: nombre del clon.
- TIMESTAMP: zona horaria UTC de la instancia de origen en formato RFC 3339. Por ejemplo, 2012-11-15T16:19:00.094Z.
gcloud sql instances clone SOURCE_INSTANCE_NAME \ NEW_INSTANCE_NAME \ --point-in-time 'TIMESTAMP'
REST v1
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- project-id: el ID del proyecto
- target-instance-id: ID de la instancia de destino
- source-instance-id: ID de la instancia de origen.
- restore-timestamp El momento dado hasta el que se debe restaurar
Método HTTP y URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone
Cuerpo JSON de la solicitud:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
REST v1beta4
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- project-id: el ID del proyecto
- target-instance-id: ID de la instancia de destino
- source-instance-id: ID de la instancia de origen.
- restore-timestamp El momento dado hasta el que se debe restaurar
Método HTTP y URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone
Cuerpo JSON de la solicitud:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "pointInTime": "restore-timestamp" } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Realizar una PITR con el almacén de copias de seguridad
Si tu instancia de Cloud SQL tiene habilitadas las copias de seguridad mejoradas, puedes realizar una recuperación a un momento dado de tu instancia mediante el archivo de copias de seguridad.
Consola
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
Abre el menú de más acciones
de la instancia que quieras recuperar y haz clic en Crear clon.
Selecciona Clonar desde un momento anterior.
Introduce una hora de PITR.
Haz clic en Crear clon.
gcloud
Para realizar una recuperación a un momento dado en una instancia desde el almacén de copias de seguridad, tendrás que buscar el data-source
de la copia de seguridad más cercana a la hora en la que quieras realizar la recuperación. Para encontrar la copia de seguridad, consulta Lista de todas las copias de seguridad del almacén de copias de seguridad de una instancia. Una vez que hayas identificado la copia de seguridad, ejecuta el siguiente comando para realizar la restauración a un momento dado:
gcloud sql instances point-in-time-restore DATA_SOURCE
PITR_TIMESTAMP
--project=TARGET_PROJECT
Haz los cambios siguientes:
- DATA_SOURCE: ruta del
data-source
de la copia de seguridad más cercana a la marca de tiempo de PITR que quieras recuperar. - PITR_TIMESTAMP: marca de tiempo UTC del registro PITR de la instancia de origen a la que quieres restaurar tu instancia, en formato RFC 3339. Por ejemplo, 2012-11-15T16:19:00.094Z.
- TARGET_PROJECT: el ID de proyecto de tu instancia de Cloud SQL.
REST v1
REST v1beta4
Desactivar PITR
Consola
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Abre el menú de más acciones
de la instancia que quieras desactivar y selecciona Editar.
- En Personalizar tu instancia, amplía la sección Protección de datos.
- Desmarca Habilitar recuperación a un momento dado.
- Haz clic en Guardar.
gcloud
- Desactiva la recuperación a un momento dado:
gcloud sql instances patch INSTANCE_NAME \ --no-enable-bin-log
- Confirma tu cambio:
gcloud sql instances describe INSTANCE_NAME
En la sección
backupConfiguration
, verásbinaryLogEnabled: false
si el cambio se ha realizado correctamente.
REST v1
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- project-id: el ID del proyecto
- instance-id: el ID de instancia.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
Cuerpo JSON de la solicitud:
{ "settings": { "backupConfiguration": { "enabled": false, "binaryLogEnabled": false } } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
REST v1beta4
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- project-id: el ID del proyecto
- instance-id: el ID de instancia.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id
Cuerpo JSON de la solicitud:
{ "settings": { "backupConfiguration": { "enabled": false, "binaryLogEnabled": false } } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Comprobar la ubicación de almacenamiento de los registros de transacciones usados para PITR
Puedes comprobar dónde almacena tu instancia de Cloud SQL los registros de transacciones que se usan para la recuperación a un momento dado.
gcloud
Para determinar si tu instancia almacena registros de PITR en el disco o en Cloud Storage, usa el siguiente comando:
gcloud sql instances describe INSTANCE_NAME
Sustituye INSTANCE_NAME por el nombre de la instancia.
Si hay varias instancias en el mismo proyecto, también puedes consultar la ubicación de almacenamiento de los registros de transacciones. Para determinar la ubicación de varias instancias, usa el siguiente comando:
gcloud sql instances list --show-transactional-log-storage-state
Respuesta de ejemplo:
NAME DATABASE_VERSION LOCATION TRANSACTIONAL_LOG_STORAGE_STATE my_01 MYSQL_8_0 us-central-1 DISK my_02 MYSQL_8_0 us-central-1 CLOUD_STORAGE ...
En el resultado del comando, el campo transactionalLogStorageState
o la columna TRANSACTIONAL_LOG_STORAGE_STATE
proporcionan
información sobre dónde se almacenan los
registros de transacciones de PITR de la instancia.
Los posibles estados de almacenamiento del registro de transacciones son los siguientes:
DISK
: la instancia almacena los registros de transacciones que se usan para la recuperación a un momento dado en el disco. Si actualizas una instancia de la edición Enterprise de Cloud SQL a la edición Enterprise Plus, el proceso de actualización cambiará automáticamente la ubicación del almacenamiento de registros a Cloud Storage. Para obtener más información, consulta el artículo Actualizar una instancia a la edición Enterprise Plus de Cloud SQL mediante una actualización in situ. También puedes cambiar la ubicación de almacenamiento con la interfaz de línea de comandos gcloud o la API Cloud SQL Admin sin actualizar la edición de tu instancia y sin que se produzca ningún tiempo de inactividad. Para obtener más información, consulta Cambiar el almacenamiento de los registros de transacciones a Cloud Storage.SWITCHING_TO_CLOUD_STORAGE
: la instancia está cambiando la ubicación de almacenamiento de los registros de transacciones de PITR a Cloud Storage.SWITCHED_TO_CLOUD_STORAGE
: la instancia ha completado el cambio de la ubicación de almacenamiento de los registros de transacciones de PITR del disco a Cloud Storage.CLOUD_STORAGE
: la instancia almacena los registros de transacciones que se usan para PITR en Cloud Storage.
Cambiar el almacenamiento de los registros de transacciones a Cloud Storage
Si tu instancia almacena en disco los registros de transacciones que se usan para la recuperación a un momento dado, puedes cambiar la ubicación de almacenamiento a Cloud Storage sin que se produzca ningún tiempo de inactividad. El proceso general de cambio de la ubicación de almacenamiento tarda aproximadamente lo que dure el periodo de conservación del registro de transacciones (en días) en completarse. En cuanto inicies el cambio, los registros de transacciones empezarán a acumularse en Cloud Storage. Durante la operación, puedes comprobar el estado general del proceso mediante el comando que se indica en Comprobar la ubicación de almacenamiento de los registros de transacciones usados para PITR.
Una vez que se haya completado el proceso general de cambio a Cloud Storage, Cloud SQL usará los registros de transacciones de Cloud Storage para la recuperación a un momento dado.
gcloud
Para cambiar la ubicación de almacenamiento a Cloud Storage, usa el siguiente comando:
gcloud sql instances patch INSTANCE_NAME \ --switch-transaction-logs-to-cloud-storage
Sustituye INSTANCE_NAME por el nombre de la instancia. La instancia debe ser una instancia principal y no una instancia de réplica. La respuesta es similar a la siguiente:
The following message is used for the patch API method. {"name": "INSTANCE_NAME", "project": "PROJECT_NAME", "switchTransactionalLogsToCloudStorageEnabled": "true"} Patching Cloud SQL instance...done. Updated [https://sqladmin.prod.googleapis.com/v1/projects/PROJECT_NAME/instances/INSTANCE_NAME].
Si el comando devuelve un error, consulta la sección Solucionar problemas al cambiar a Cloud Storage para ver los posibles pasos siguientes.
REST v1
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID del proyecto.
- INSTANCE_ID: el ID de instancia. La instancia debe ser una instancia principal y no una instancia réplica.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Cuerpo JSON de la solicitud:
{ "switchTransactionLogsToCloudStorageEnabled": true }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Si la solicitud devuelve un error, consulta Solucionar problemas al cambiar a Cloud Storage para ver los posibles pasos siguientes.
REST v1beta4
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID del proyecto.
- INSTANCE_ID: el ID de instancia. La instancia debe ser una instancia principal y no una instancia réplica.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Cuerpo JSON de la solicitud:
{ "switchTransactionLogsToCloudStorageEnabled": true }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Si la solicitud devuelve un error, consulta Solucionar problemas al cambiar a Cloud Storage para ver los posibles pasos siguientes.
Almacenamiento y configuración de registros de transacciones después del cambio
Para la replicación, Cloud SQL sigue conservando copias de los registros binarios en el disco.
Si quieres consultar los registros binarios con la utilidad mysqlbinlog
, es útil almacenarlos en el disco.
Si configuraste las marcas expire_logs_days
o binlog_expire_logs_seconds
en tu instancia antes del cambio, los valores configurados se mantendrán.
Después del cambio, como los registros binarios que se usan para realizar PITR ahora se almacenan en Cloud Storage, asegúrate de que los valores de las marcas reflejen la retención de los registros de transacciones en el disco que esperas. Cloud SQL solo conserva los registros en el disco durante el valor mínimo de uno de los siguientes:
- la
transactionLogRetentionDays
configuración de PITR antes del cambio. El valor predeterminado de este ajuste es 7 días. - las marcas
expire_logs_days
obinlog_expire_logs_seconds
que hayas definido manualmente en tu instancia.
Si quieres ahorrar espacio en disco, una vez que se haya completado el proceso de cambio, configura el valor de las marcas expire_logs_days
o binlog_expire_logs_seconds
en 1 día para reducir el tamaño del disco asignado y los costes de almacenamiento en disco. Para obtener más información sobre el almacenamiento de registros de transacciones y la recuperación a un punto en el tiempo, consulta Almacenamiento de registros para la recuperación a un punto en el tiempo.
Para obtener más información sobre cómo comprobar el uso del disco, consulta Registros y uso del disco.
Definir la retención de registros de transacciones
Para definir el número de días que se conservarán los registros binarios, sigue estos pasos:
Consola
-
En la Google Cloud consola, ve a la página Instancias de Cloud SQL.
- Abre el menú de más acciones
de la instancia en la que quieras activar el registro de transacciones y selecciona Editar.
- En Personalizar tu instancia, amplía la sección Protección de datos.
- En la sección Habilitar recuperación a un momento dado, despliega Opciones avanzadas.
- Introduce el número de días que quieres conservar los registros (entre 1 y 35 para la edición Enterprise Plus de Cloud SQL, o entre 1 y 7 para la edición Enterprise de Cloud SQL).
- Haz clic en Guardar.
gcloud
Edita la instancia para definir el número de días que se conservarán los registros binarios.
Haz los cambios siguientes:
- INSTANCE_NAME: el nombre de la instancia en la que quieras definir el registro de transacciones.
DAYS_TO_RETAIN: número de días que se conservarán los registros de transacciones. En la edición Enterprise Plus de Cloud SQL, el intervalo válido es de entre 1 y 35 días, con un valor predeterminado de 14 días. En la edición Enterprise de Cloud SQL, el intervalo válido es de 1 a 7 días, con un valor predeterminado de 7 días.
Si no especifica ningún valor, Cloud SQL usará el valor predeterminado. Esto solo es válido cuando se habilita la recuperación a un momento dado. Para conservar los registros de transacciones durante más días, se necesita un mayor tamaño de almacenamiento.
gcloud sql instances patch INSTANCE_NAME
--retained-transaction-log-days=DAYS_TO_RETAIN
REST v1
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID del proyecto.
- INSTANCE_ID: el ID de instancia.
DAYS_TO_RETAIN: número de días que se conservarán los registros de transacciones. En la edición Enterprise Plus de Cloud SQL, el intervalo válido es de entre 1 y 35 días, con un valor predeterminado de 14 días. En la edición Enterprise de Cloud SQL, el intervalo válido es de 1 a 7 días, con un valor predeterminado de 7 días.
Si no se especifica ningún valor, se usa el valor predeterminado. Esto solo es válido cuando se habilita la recuperación a un momento dado. Para conservar los registros de transacciones durante más días, se necesita más espacio de almacenamiento.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID
Cuerpo JSON de la solicitud:
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
REST v1beta4
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- PROJECT_ID: el ID del proyecto.
- INSTANCE_ID: el ID de instancia.
DAYS_TO_RETAIN: número de días que se conservarán los registros de transacciones. En la edición Enterprise Plus de Cloud SQL, el intervalo válido es de entre 1 y 35 días, con un valor predeterminado de 14 días. En la edición Enterprise de Cloud SQL, el intervalo válido es de 1 a 7 días, con un valor predeterminado de 7 días.
Si no se especifica ningún valor, se usa el valor predeterminado. Esto solo es válido cuando se habilita la recuperación a un momento dado. Para conservar los registros de transacciones durante más días, se necesita más espacio de almacenamiento.
Método HTTP y URL:
PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID
Cuerpo JSON de la solicitud:
{ "settings": { "backupConfiguration": { "transactionLogRetentionDays": "DAYS_TO_RETAIN" } } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Realizar una recuperación a un momento dado mediante posiciones de registro binario
Aunque le recomendamos que realice la restauración a un momento dado mediante marcas de tiempo, tal como se describe en Restaurar a un momento dado mediante una marca de tiempo, también puede hacerlo proporcionando una posición específica del registro binario o una posición de evento en un archivo de registro binario.
Para obtener más información sobre la restauración a un momento dado mediante posiciones de registro binario, consulta Restauración a un momento dado mediante el registro binario.
Antes de empezar
Antes de empezar esta tarea, es necesario lo siguiente:
El registro binario y las copias de seguridad están habilitados en la instancia, con registros binarios continuos desde la última copia de seguridad anterior al evento del que quieres recuperarte. Para obtener más información, consulta Habilitar el registro binario.
Los registros binarios deben estar disponibles en el disco para que puedas buscar eventos en ellos. Para consultar la duración de la retención de los registros binarios en el disco, consulta Periodo de retención de registros. No puedes consultar los registros binarios almacenados en Cloud Storage con la utilidad
mysqlbinlog
.Nombre de archivo de registro binario y posición del evento que quieres recuperar (ese evento y todos los que se produjeron después no se reflejan en la nueva instancia). Para obtener más información, consulta Identificar la posición del registro binario.
Una vez que hayas identificado el nombre del archivo de registro binario y la posición, realiza la recuperación a un momento dado mediante las posiciones de los eventos del registro binario.
Identificar la posición de recuperación
Usa el cliente MySQL para conectarte a la instancia en la que quieras restaurar la base de datos.
Para ello, usa Cloud Shell o tu máquina cliente local. Para obtener más información, consulta Opciones de conexión para aplicaciones externas.
Muestra los archivos de registro binarios de la instancia:
SHOW BINARY LOGS;
Muestra los primeros 100 eventos del archivo de registro binario más reciente:
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' LIMIT 100;
Puedes ajustar el número de filas que se mostrarán, pero no muestres todos los eventos del archivo hasta que sepas el tamaño del archivo. Mostrar un gran número de eventos puede afectar al rendimiento del sistema.
Si no aparece el evento que buscas, usa la última posición mostrada como punto de partida para buscar el siguiente conjunto de eventos:
SHOW BINLOG EVENTS IN '<BINARY_LOG_FILE>' FROM <POSITION> LIMIT 100;
Cuando encuentre el evento que marca el momento hasta el que quiere restaurar, anote la posición (que se muestra como
Pos
) y el nombre del archivo de registro binario.El nombre del archivo de registro binario y la posición son los valores que se utilizan para la recuperación a un momento dado.
A continuación, se muestra un ejemplo de resultado del comando SHOW BINLOG EVENTS
:
+------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ | mysql-bin.000011 | 4 | Format_desc | 88955285 | 120 | Server ver: 5.6.30-log, Binlog ver: 4 | | mysql-bin.000011 | 120 | Query | 88955285 | 211 | create database db1 | | mysql-bin.000011 | 211 | Query | 88955285 | 310 | use `db1`; CREATE TABLE t (c CHAR(20)) | | mysql-bin.000011 | 310 | Query | 88955285 | 381 | BEGIN | | mysql-bin.000011 | 381 | Table_map | 88955285 | 426 | table_id: 18 (db1.t) | | mysql-bin.000011 | 310 | Query | 88955285 | 381 | BEGIN | | mysql-bin.000011 | 426 | Write_rows | 88955285 | 464 | table_id: 18 flags: STMT_END_F | | mysql-bin.000011 | 464 | Xid | 88955285 | 495 | COMMIT /* xid=56 */ | | mysql-bin.000011 | 495 | Query | 88955285 | 566 | BEGIN | | mysql-bin.000011 | 566 | Table_map | 88955285 | 611 | table_id: 18 (db1.t) | | mysql-bin.000011 | 611 | Write_rows | 88955285 | 649 | table_id: 18 flags: STMT_END_F | | mysql-bin.000011 | 649 | Xid | 88955285 | 680 | COMMIT /* xid=57 */ | | mysql-bin.000011 | 680 | Query | 88955285 | 751 | BEGIN | | mysql-bin.000011 | 751 | Table_map | 88955285 | 796 | table_id: 18 (db1.t) | | mysql-bin.000011 | 796 | Write_rows | 88955285 | 834 | table_id: 18 flags: STMT_END_F | | mysql-bin.000011 | 834 | Xid | 88955285 | 865 | COMMIT /* xid=58 */ | | mysql-bin.000011 | 865 | Query | 88955285 | 977 | use `db1`; DROP TABLE `t` /* generated by server */ | +------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ 16 rows in set (0.04 sec)
Para restaurar hasta la instrucción DROP TABLE
, que aparece en negrita en el ejemplo anterior, usarías 865
en mysql-bin.000011
como posición de recuperación. La instrucción DROP TABLE
y todas las operaciones posteriores no se reflejan en la nueva instancia.
Realizar una recuperación a un momento dado usando posiciones de eventos de registro binario
gcloud
Usa el comando
gcloud sql instances clone
con las marcas
--bin-log-file-name
y --bin-log-position
.
-
Crea la nueva instancia con el nombre del archivo de registro binario y la posición de recuperación.
Haz los cambios siguientes:
- SOURCE_INSTANCE_NAME: nombre de la instancia desde la que vas a restaurar.
- NEW_INSTANCE_NAME: nombre de la clonación.
- BINLOG_FILE_NAME: nombre del registro binario, como
mysql-bin.187288
. - POSITION: la posición del registro binario hasta la que se va a restaurar, como
50001356
.
gcloud sql instances clone SOURCE_INSTANCE_NAME \ NEW_INSTANCE_NAME \ --bin-log-file-name="BINLOG_FILE_NAME" \ --bin-log-position=POSITION
Por ejemplo, un comando
gcloud sql instances clone
podría tener un aspecto similar al siguiente:gcloud sql instances clone instance1 \ instance1-clone \ --bin-log-file-name=mysql-bin.0000031 \ --bin-log-position=107 \
- Usa el ID de operación devuelto por el comando
clone
para comprobar el estado de la operación de restauración.gcloud sql operations describe OPERATION_ID
Cuando la operación está en curso, se devuelve el estado
RUNNING
. Cuando se completa la operación, se devuelve el estadoDONE
.
REST v1
Crea la nueva instancia con el nombre del archivo de registro binario y la posición de recuperación que has identificado:
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- project-id: el ID del proyecto
- target-instance-id: ID de la instancia de destino
- source-instance-id: ID de la instancia de origen.
- binary-log-file-name Nombre del archivo de registro binario
- binary-log-position La posición en el archivo de registro binario
Método HTTP y URL:
POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/source-instance-id/clone
Cuerpo JSON de la solicitud:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "binLogCoordinates": { "kind": "sql#binLogCoordinates", "binLogFileName": "binary-log-file-name", "binLogPosition": "binary-log-position" } } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
REST v1beta4
Crea la nueva instancia con el nombre del archivo de registro binario y la posición de recuperación que has identificado:
Antes de usar los datos de la solicitud, haz las siguientes sustituciones:
- project-id: el ID del proyecto
- target-instance-id: ID de la instancia de destino
- source-instance-id: ID de la instancia de origen.
- binary-log-file-name Nombre del archivo de registro binario
- binary-log-position La posición en el archivo de registro binario
Método HTTP y URL:
POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/source-instance-id/clone
Cuerpo JSON de la solicitud:
{ "cloneContext": { "kind": "sql#cloneContext", "destinationInstanceName": "target-instance-id", "binLogCoordinates": { "kind": "sql#binLogCoordinates", "binLogFileName": "binary-log-file-name", "binLogPosition": "binary-log-position" } } }
Para enviar tu solicitud, despliega una de estas opciones:
Deberías recibir una respuesta JSON similar a la siguiente:
Solucionar problemas
Problema | Solución de problemas |
---|---|
O
|
La marca de tiempo que has proporcionado no es válida. |
O
|
La marca de tiempo que has proporcionado corresponde a un momento en el que no se han podido encontrar copias de seguridad ni coordenadas de binlog. |
Solucionar problemas al cambiar a Cloud Storage
En la siguiente tabla se enumeran los posibles errores que pueden devolverse con el código INVALID REQUEST
al cambiar la ubicación de almacenamiento de los registros de transacciones del disco a Cloud Storage.
Problema | Solución de problemas |
---|---|
Switching the storage location of the transaction logs
used for PITR is not supported for instances with database type %s.
|
Asegúrate de ejecutar el comando gcloud CLI o de hacer la solicitud de API en una instancia de Cloud SQL para MySQL o Cloud SQL para PostgreSQL. No se puede cambiar la ubicación de almacenamiento de los registros de transacciones mediante la CLI de gcloud o la API Cloud SQL Admin en Cloud SQL para SQL Server. |
MySQL transactional logging is not enabled on this instance.
|
MySQL usa el registro binario como registros de transacciones para la recuperación a un momento dado (PITR). Para admitir PITR, MySQL requiere que habilites el registro binario en la instancia. Para obtener más información sobre cómo habilitar el registro binario, consulta Habilitar PITR. |
This command is not supported on replica instances.
Run the command on the primary instance instead.
|
Asegúrese de especificar una instancia principal al ejecutar el comando o al hacer la solicitud de la API. |
This instance is already storing transaction logs used for PITR in
Cloud Storage
|
Para verificar la ubicación de almacenamiento de los registros de transacciones, ejecuta el comando que se indica en Comprobar la ubicación de almacenamiento de los registros de transacciones utilizados para PITR. |
The instance is already switching transaction logs used for PITR from disk
to Cloud Storage.
|
Espera a que se complete la operación de cambio. Para verificar el estado de la operación y la ubicación de almacenamiento de los registros de transacciones, ejecuta el comando que se indica en Comprobar la ubicación de almacenamiento de los registros de transacciones utilizados para la recuperación a un momento dado. |
Siguientes pasos
- Configurar las marcas en tu clon