Descripción general del restablecimiento de una instancia

MySQL |PostgreSQL |SQL Server

Cloud SQL te permite restablecer tus instancias desde una copia de seguridad o con la 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 nueva. Para restablecer, 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 diferentes 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.
• No se restablecen las marcas de la instancia de origen. Las marcas que se hayan establecido anteriormente en la instancia de destino se conservarán 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 una instancia con réplicas de lectura, debes borrar todas las réplicas y volver a crearlas después de que se complete la operación de restablecimiento.
• La operación de restablecimiento reinicia la instancia.
• Después de restablecer desde una copia de seguridad, los parámetros de configuración de la copia de seguridad de la instancia de destino se establecen en los valores predeterminados. Si tu instancia de origen tenía parámetros de configuración de copia de seguridad personalizados o usaba copias de seguridad mejoradas, deberás actualizar los parámetros de configuración de copia de seguridad después de que se complete el restablecimiento.

Importante: Cuando se restablece una copia de seguridad en una instancia existente, la instancia de destino debe tener, al menos, la misma cantidad de recursos de procesamiento y memoria (CPU virtual y RAM) que la instancia de origen desde la que se creó la copia de seguridad. Restablecer una copia de seguridad en una instancia con muchos menos recursos puede hacer que la operación de restablecimiento falle debido a restricciones de recursos durante el inicio y la recuperación de la base de datos. Es posible que veas errores como database failed to start after multiple retries.

Restablece los datos 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 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 en una instancia existente
• Restablece una instancia en otro proyecto o región

En caso de una interrupción, puedes recuperar una lista de copias de seguridad en un proyecto específico para restablecerlo.

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

Restablece una instancia habilitada para CMEK con copias de seguridad mejoradas

Cuando usas instancias habilitadas para CMEK con copias de seguridad mejoradas, tus copias de seguridad están protegidas por la misma CMEK que la instancia. Esta puede ser una parte importante de tu plan de copia de seguridad para las instancias que requieren encriptación con CMEK, ya que mantiene tus copias de seguridad encriptadas con CMEK en un proyecto independiente en el que se pueden restablecer correctamente, incluso si el proyecto de carga de trabajo original se ve comprometido o se borra.

Cuando restableces una copia de seguridad mejorada de una instancia habilitada para CMEK en una instancia nueva, puedes elegir cualquiera de las siguientes opciones de encriptación para la instancia nueva:

• Usa la misma clave de Cloud KMS que la instancia original. Este es el comportamiento predeterminado.
• Selecciona una clave de Cloud KMS diferente para la instancia de destino. Para seleccionar una clave diferente, establece la marca --disk-encryption-key en el comando de restablecimiento.
• Revertir a Google-owned and Google-managed encryption keys para la instancia de destino. Para usar GMEK, establece la marca --clear-disk-encryption en el comando de restablecimiento.

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 la pérdida de datos, puedes recuperar el estado de una base de datos antes de que se produjera el error. A diferencia de la restauración con una copia de seguridad, la PITR siempre crea una instancia nueva. No puedes realizar una PITR en una instancia existente. La instancia nueva heredará la configuración de la instancia de origen, de forma similar a cuando creas 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 no quieres que esté habilitada.

Si creas una instancia de Cloud SQL edición Enterprise en la consola de Google Cloud , la PITR está habilitada de forma predeterminada. De lo contrario, si creas la instancia con la gcloud CLI, Terraform o la API de Cloud SQL Admin, la PITR está inhabilitada de forma predeterminada. Para habilitar la PITR en estas instancias, debes habilitarla 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, estos registros de archivo se borran y no estarán disponibles para realizar una PITR. Solo se pueden usar los registros nuevos generados después de que se complete el restablecimiento para la PITR.

El 31 de mayo de 2024, 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 de transacciones que se usan para la 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 31 de mayo de 2024 continúan almacenando sus registros para la PITR en el disco.

• Las instancias de Cloud SQL edición Enterprise creadas con la PITR habilitada antes del 31 de mayo de 2024 seguirán almacenando sus registros para la PITR en el disco.

  Nota: En las instancias que se crearon antes del 31 de mayo de 2024, Cloud SQL cambia la ubicación de los registros de transacciones que se usan para la PITR de forma automática. Puedes usar gcloud CLI o la API de Cloud SQL Admin para comprobar dónde se almacenan los registros de transacciones de tu instancia.

• Si actualizas una instancia de Cloud SQL edición Enterprise después del 31 de mayo 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 edición Enterprise que creas con la PITR habilitada después del 31 de mayo de 2024 almacenan los registros usados para la PITR en Cloud Storage.

Si tu instancia usa Cloud Storage para almacenar registros de transacciones, estos 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 Verifica dónde se almacenan los registros de transacciones de tu instancia.

Para las instancias que almacenan registros de transacciones 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 con 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.

Precaución: Mover los registros de transacciones del disco a Cloud Storage genera varios minutos de tiempo de inactividad y una pérdida de los registros anteriores para la PITR. El tiempo de inactividad se debe a que las instancias deben reiniciarse, y los registros se borran al desactivar PITR.

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.

  Precaución: Si desactivas y vuelves a habilitar la PITR, se borrarán todos los registros existentes y no podrás realizar la PITR antes de la hora en que la volviste a habilitar. Para habilitar y desactivar la PITR, debes reiniciar la base de datos.

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 de transacciones que se usan para la PITR en Cloud Storage, la instancia también mantiene una cantidad menor de registros de transacciones duplicados en el disco para permitir la replicación de los registros en Cloud Storage. De forma predeterminada, cuando creas una instancia con PITR habilitada, la instancia almacena sus registros de transacciones para PITR en Cloud Storage. Cloud SQL también establece el valor de las marcas expire_logs_days y binlog_expire_logs_seconds en el equivalente de un día de forma automática. Esto se traduce en un día de registros en el disco.

En el caso de los registros de transacciones de PITR que se almacenan en el disco, que se cambian a Cloud Storage o que ya se cambiaron a Cloud Storage, Cloud SQL retiene los registros del valor mínimo establecido para uno de los siguientes parámetros de configuración:

• 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 de transacciones se almacenan en el disco, se cambian 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 recomendamos que configures ninguno de los valores de marca como 0. Para obtener más información, consulta Configura marcas de base de datos.

Nota: Si tu instancia tiene una gran cantidad de registros de transacciones en el disco y deseas ahorrar espacio en el disco, te recomendamos que reduzcas lentamente el valor de lo siguiente:

• 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 un día, cada día, durante varios días. Como resultado, Cloud SQL no borra todos los registros de transacciones 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 de transacciones 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 retenidos como parte del parámetro retained-transaction-log-days.

Limitaciones de la PITR

Las siguientes limitaciones se asocian con 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 los registros existentes, por lo que no puedes realizar una operación de PITR antes de la hora en 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.

• No se puede habilitar la recuperación de un momento determinado (PITR) en tu instancia de destino de Cloud SQL si tiene varias bases de datos con el mismo nombre físico.

Instantáneas de bases de datos

No puedes usar instantáneas de la base de datos de SQL Server en ninguna base de datos dentro de una instancia en la que esté habilitada la PITR.

Las instantáneas de la base de datos pueden interferir en la copia de seguridad completa de la base de datos y la copia de seguridad del registro de transacciones en las que se basa la PITR. Esta interferencia puede impedir que se realicen operaciones de PITR exitosas en cualquier base de datos de la instancia.

Modelo de recuperación de la base de datos para la PITR

Si habilitas la PITR en una instancia, Cloud SQL establece de manera automática el modelo de recuperación de las bases de datos existentes y posteriores en el modelo de recuperación completo.

Precaución: Después de habilitar la PITR en tu instancia, no cambies el modelo de recuperación de la base de datos a Simple. Esto puede romper la cadena de copia de seguridad del registro de transacciones, y es posible que no puedas recuperar los datos de la instancia hasta el momento en que el modelo de recuperación se estableció en Simple.

Para obtener más información sobre los modelos de recuperación de SQL Server, consulta la documentación de Microsoft.

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 borrada con la PITR

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

Después de borrar una instancia, los registros de PITR siguen la configuración de retención definida 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 configurada 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 un registro de PITR vence, 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 retenidos 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.

La ventana de recuperación de la PITR se define como los tiempos de recuperación más tempranos y más tardíos disponibles para restablecer tu instancia con la PITR. Para encontrar los tiempos de recuperación más antiguos y más recientes de la instancia borrada, consulta Obtén el tiempo de recuperación más antiguo y más reciente.

Para restablecer una instancia con la PITR después de borrarla, consulta Realiza la PITR en una instancia borrada.

Requisitos para restablecer en una instancia nueva

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

• La instancia de destino debe tener la misma versión y edición de base de datos que la instancia de la que se realizó la copia de seguridad.

• Cuando creas una instancia nueva, la función storageAutoResize está habilitada de forma predeterminada. Cualquier copia de seguridad que se cree posteriormente heredará el mismo parámetro de configuración de storageAutoResize. Esto significa que, ya sea que restablezcas una copia de seguridad en una instancia nueva o existente, la instancia cambiará automáticamente el tamaño de la capacidad de almacenamiento según sea necesario. Las instancias heredadas no tienen habilitada esta función. Para verificar la configuración de la instancia, consulta Visualiza la configuración de la instancia. Este requisito se aplica sin importar si realizas una PITR de una sola base de datos.

• 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 cuenta para esta cuota. Si alcanzas el límite, la operación fallará con un mensaje de error que te indicará cuándo puedes volver a ejecutarla.

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 las 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:

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

• 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?

• Restablece una copia de seguridad
• Usa la recuperación de un momento determinado (PITR)