Descripción general del restablecimiento de una instancia

Cloud SQL te permite restablecer tus instancias desde una copia de seguridad o realizar una recuperación de un momento determinado (PITR). Esto te permite recuperar una instancia en un período o momento específico, ya sea restableciendo la copia de seguridad en una instancia existente o en una instancia nueva. Para restablecerla, puedes usar la copia de seguridad de una instancia activa o borrada. La operación de restablecimiento toma la configuración, las bases de datos y los usuarios de la instancia de origen, y los establece en la instancia de destino que elijas.

Cuando restableces a una instancia nueva, la instancia de destino puede estar en una región o un proyecto diferente de la instancia de origen. La instancia de destino también puede usar una cantidad diferente de núcleos o de memoria que la instancia de origen.

Cloud SQL siempre establece la capacidad de almacenamiento de la instancia de destino en el valor máximo del tamaño del disco configurado y del disco de copia de seguridad. El disco de copia de seguridad es el tamaño del disco cuando se realiza la copia de seguridad.

Cuando realices un restablecimiento en una instancia, ten en cuenta lo siguiente:

  • La operación de restablecimiento reemplaza todos los datos en la instancia de destino.
  • Las marcas de la instancia de origen no se restablecen. Todas las marcas establecidas con anterioridad en la instancia de destino se conservan después del restablecimiento.
  • La instancia de destino no podrá establecer conexiones durante la operación de restablecimiento; se perderán las conexiones existentes.
  • Si restableces a una instancia con réplicas de lectura, debes borrar todas las réplicas y volver a crearlas luego de que se complete la operación de restablecimiento.
  • La operación de restablecimiento reinicia la instancia.
  • Después de restablecer una copia de seguridad, la configuración de copias de seguridad de la instancia de destino se establece en los valores predeterminados. Si tu instancia de origen tenía configuraciones de copia de seguridad personalizadas o usaba copias de seguridad mejoradas, deberás actualizar las configuraciones de copia de seguridad después de que se complete el restablecimiento.

Restablece el dispositivo con una copia de seguridad

Cloud SQL te permite restablecer una instancia con una copia de seguridad. Puedes usar una copia de seguridad de una instancia activa o borrada, y usarla para restablecer una instancia nueva o existente. Puedes usar cualquier copia de seguridad disponible para restablecer la instancia. Para obtener más información sobre cómo funcionan las copias de seguridad en Cloud SQL, consulta la Descripción general de las copias de seguridad.

Cuando restableces una instancia con una copia de seguridad, puedes hacer lo siguiente:

  • Restablecer en una instancia nueva
  • Restablece a una instancia existente
  • Restablece una instancia en otro proyecto o región

En caso de interrupción, de todas maneras puedes recuperar una lista de copias de seguridad en un proyecto en particular para restablecerlo.

Para restablecer tu instancia con una copia de seguridad, consulta Restablece una instancia con una copia de seguridad.

Recuperación de un momento determinado (PITR)

La PITR te permite restablecer tu instancia a un momento específico de la base de datos. Por ejemplo, si un error provoca una pérdida de datos, puedes recuperar el estado de una base de datos antes de que se produjera el error. A diferencia del restablecimiento con una copia de seguridad, la PITR siempre crea una instancia nueva. No puedes realizar una PITR a una instancia existente. La instancia nueva hereda la configuración de la instancia de origen, de forma similar a cuando crea un clon.

Si creas una instancia de la edición Enterprise Plus de Cloud SQL, la PITR está habilitada de forma predeterminada. Debes inhabilitar la función de forma manual.

Si creas una instancia de la edición de Cloud SQL Enterprise en la Google Cloud consola, la PITR está habilitada de forma predeterminada. Si creas una instancia de Cloud SQL para MySQL con la alta disponibilidad habilitada, la PITR también se habilita de forma predeterminada. De lo contrario, si creas la instancia con la CLI de gcloud, Terraform o la API de Cloud SQL Admin, la PITR estará inhabilitada de forma predeterminada. Para habilitar la PITR en estas instancias, debes hacerlo de forma manual.

Si quieres obtener instrucciones paso a paso para realizar la PITR, consulta Usa la recuperación de un momento determinado (PITR).

Almacenamiento de registros para PITR

La PITR usa el registro binario para archivar los registros. Cuando restableces una instancia existente con una copia de seguridad, se borran estos registros de archivo y no estarán disponibles para realizar una PITR. Solo los registros nuevos que se generen después de que se complete el restablecimiento se pueden usar 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 la edición 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 11 de agosto de 2023 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 tu instancia usa Cloud Storage para almacenar registros binarios, los registros se almacenan en la misma región que la instancia principal. Estos registros se almacenan durante un máximo de 35 días para la edición Cloud SQL Enterprise Plus y 7 días para la edición Cloud SQL Enterprise, y no generan costos adicionales por instancia.

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 cómo verificar dónde se almacenan los registros de transacciones de tu instancia.

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.

Para asegurarte de que los registros de tu instancia se almacenen en Cloud Storage en lugar de en el disco, completa las siguientes acciones:

  • Verifica la arquitectura de red de la instancia. Si la instancia está en la arquitectura de red anterior, actualízala a la nueva arquitectura de red.

  • Si el tamaño de los registros en el disco causa problemas de rendimiento en la instancia, desactiva la PITR y vuelve a habilitarla. Esta acción garantiza que los registros nuevos se almacenen en Cloud Storage en lugar de en el disco.

Período de retención de registros

Cloud SQL retiene los registros de transacciones en Cloud Storage hasta el valor establecido en el parámetro de 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 para 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.

En el caso de los registros binarios de la PITR que se almacenan en el disco, que se están cambiando 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 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. Mientras se cambia la ubicación de almacenamiento de registros a Cloud Storage, no puedes modificar los valores de las marcas. Tampoco te recomendamos que configures ninguno de los valores de la marca como 0. Para obtener más información, consulta Configura marcas de base de datos.

  • Parámetro de configuración de transactionLogRetentionDays
  • Marca de base de datos expire_logs_days
  • Marca de base de datos binlog_expire_logs_seconds

Por ejemplo, para evitar problemas de rendimiento, reduce el valor de las marcas en un día cada día durante varios días. Como resultado, Cloud SQL no borra todos los registros binarios de forma simultánea.

En el caso de las instancias que tienen habilitada la clave de encriptación administrada por el cliente (CMEK), los registros binarios se encriptan con la versión más reciente de la CMEK. Para realizar un restablecimiento, se requiere la versión de clave más reciente para todos los días que se conservan como parte del parámetro retained-transaction-log-days.

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. 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 devuelve el tamaño de los binlogs 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 los registros binarios genera un problema en la instancia, haz lo siguiente:

For more information about PITR, see Point-in-time recovery (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 para la PITR después del cambio y cómo liberar espacio en el disco, consulta Registros después del cambio a Cloud Storage.

Limitaciones de la PITR

Las siguientes limitaciones están asociadas con el hecho de que tu instancia tenga habilitada la PITR y el tamaño de los registros de transacciones en el disco cause un problema para la instancia:

  • Puedes desactivar la PITR y volver a habilitarla para asegurarte de que Cloud SQL almacene los registros en Cloud Storage en la misma región que la instancia. Sin embargo, Cloud SQL borra todos los registros existentes, por lo que no puedes realizar una operación de PITR antes del momento en el que volviste a habilitar la PITR.
  • Puedes aumentar el tamaño de almacenamiento de la instancia, pero el aumento del tamaño de tu registro de transacciones con respecto al uso del disco puede ser temporal.
  • Para evitar problemas de almacenamiento inesperados, te recomendamos que habilites el aumento automático de almacenamiento. Esta recomendación se aplica solo si tu instancia tiene habilitada la PITR y tus registros se almacenan en el disco.
  • Si deseas borrar registros y recuperar 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.

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

Si quieres obtener instrucciones paso a paso para realizar la PITR, consulta [Usa la recuperación de un momento determinado (PITR)][perform-pitr].

Restablece una instancia no disponible

Puedes usar la PITR para restablecer una instancia de Cloud SQL que no esté disponible. Por lo general, la PITR ofrece un objetivo de punto de recuperación (RPO) de cinco minutos o menos.

Si la instancia no está disponible, puedes usar la API para obtener el tiempo de recuperación más reciente y más antiguo al que puedes restablecer la instancia y realizar la recuperación en ese momento. Si no se puede acceder a la zona en la que se configuró la instancia, puedes restablecer la instancia en una zona primaria o secundaria diferente si proporcionas valores para las zonas preferidas.

Supongamos que una instancia de Cloud SQL deja de estar disponible a las 4 p.m. (hora del este). Si el tiempo de recuperación más reciente es a las 3:55 p.m. (hora del este), puedes recuperar la instancia hasta este momento.

Restablece una instancia borrada con la PITR

Puedes usar la PITR para restablecer una instancia de Cloud SQL después de su eliminación. Para usar esta función, tu instancia debe tener habilitadas las funciones de PITR y copias de seguridad retenidas antes de que se borre la instancia. Cuando se habilita, los registros de la PITR se conservan después de que borras la instancia.

Después de que se borra una instancia, los registros de la PITR siguen los parámetros de configuración de retención definidos por la instancia cuando estaba activa. Los registros de PITR vencen según la configuración de retención de forma continua después de que se borra la instancia. El período continuo se define en función del período de retención de la PITR establecido en la instancia antes de la eliminación. Por ejemplo, si tu instancia de la edición Cloud SQL Enterprise Plus tiene la retención de PITR establecida en 14 días, el registro de PITR más reciente se borrará 14 días después de que se borre la instancia. Cuando vence un registro de PITR, no se puede recuperar.

Dado que los nombres de las instancias se pueden volver a usar después de que se borra una instancia en Cloud SQL, los registros de PITR conservados se pueden identificar en Google Cloud con los siguientes campos:

  • instance_deletion_time
  • log_retention_days

Estos campos te permiten identificar si un registro de PITR pertenece a una instancia borrada.

El período de recuperación de la PITR se define como los horarios de recuperación más antiguos y más recientes disponibles para restablecer tu instancia con la PITR. Para encontrar las horas de recuperación más temprana y más reciente de tu instancia borrada, consulta Cómo obtener la hora de recuperación más temprana y más reciente.

Para restablecer una instancia con la PITR después de que se borró, consulta Realiza la PITR en una instancia borrada.

Requisitos para restablecer a una instancia nueva

Cuando restablezcas tu instancia en una instancia nueva, ten en cuenta los siguientes requisitos:

  • La instancia de destino debe tener la misma versión de base de datos que la instancia desde la que se tomó la copia de seguridad.

  • La capacidad de almacenamiento de la instancia de destino debe ser al menos tan grande como la capacidad de la instancia de la que se realiza la copia de seguridad. No importa la cantidad de almacenamiento que se utiliza. Puedes ver la capacidad de almacenamiento de la instancia en la página de instancias de Cloud SQL en la consola.

  • La instancia de destino debe tener el estado RUNNABLE.

Límites de frecuencia para los restablecimientos

Puedes tener un máximo de tres operaciones de restablecimiento cada 30 minutos por instancia y por región por proyecto. Si una operación de restablecimiento falla, no se considera en esta cuota. Si alcanzas el límite, la operación falla con un mensaje de error que te indica cuándo puedes volver a ejecutar la operación.

Cloud SQL usa tokens de un bucket para determinar cuántas operaciones de restablecimiento están disponibles a la vez. Por cada copia de seguridad, hay un bucket para cada proyecto y región de destino. Las instancias de destino del mismo proyecto comparten un bucket si están en la misma región. Hay un máximo de tres tokens en cada bucket que puedes usar para operaciones de restablecimiento. Cada 10 minutos, se agrega un token nuevo al bucket. Si el bucket está lleno, el token se desborda.

Cada vez que emites una operación de restablecimiento, se otorga un token al bucket. Si la operación se realiza correctamente, el token se quita del bucket. Si falla, el token se muestra en el bucket. En el siguiente diagrama, se puede ver cómo funciona:

Cómo funcionan los tokens

Por ejemplo, en la siguiente figura, Backup1, Backup2 y Backup3 son las copias de seguridad de la misma instancia de origen.

Tokens para el límite de frecuencia de operaciones de restablecimiento

  • Cada copia de seguridad (Backup1, Backup2 y Backup3) tienen su propio bucket de tokens para operaciones de restablecimiento que se orientan a diferentes instancias en el Proyecto 1 de la Región A (Bucket11A, Bucket21A y Bucket31A). Debido a que cada copia de seguridad tiene su propio bucket, puedes restablecer cada copia de seguridad en la misma instancia tres veces cada treinta minutos.
  • Cada copia de seguridad tiene un bucket para un proyecto y una región diferentes. Por ejemplo, si hay cinco proyectos en una región, hay cinco buckets para esa copia de seguridad en esa región, uno en cada proyecto. En la figura anterior, tenemos dos proyectos en la región A: Proyecto 1 y Proyecto n.
    • Backup1 tiene dos buckets de tokens para las operaciones de restablecimiento en la región A. Un bucket para el Proyecto 1 (Bucket11A) y otro para el Proyecto n (Bucket1nA).
    • Del mismo modo, Backup3 tiene dos buckets para las operaciones de restablecimiento en la región A. Uno para el Proyecto 1 (Bucket31A) y otro para el Proyecto n (Bucket3nA).
  • Backup3 tiene un bucket en la región B, para el proyecto 1, porque todas las instancias en el mismo proyecto de destino y la misma región de destino comparten un bucket.

¿Qué sigue?