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 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 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 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 deseas restablecer 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 desde una copia de seguridad, la configuración de la copia 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 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 a 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
• Restablecer en una instancia existente
• Restablecer en 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 en particular para restablecer.

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 pérdida de datos, puedes restablecer la base de datos al estado en que se encontraba 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 creas un clon.

Si creas una instancia de Cloud SQL Enterprise Plus, 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 Enterprise en la Google Cloud consola, la PITR está habilitada 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 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 para archivar 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 para la PITR los registros nuevos que se generen después de que se complete el restablecimiento.

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 Cloud SQL Enterprise Plus almacenan sus registros de transacciones 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 31 de mayo de 2024 continúan almacenando sus registros para la PITR en el disco.

• Las instancias de Cloud SQL 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 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 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, los registros se almacenan en la misma región que la instancia principal. Estos registros se almacenan hasta por 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.

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

**Precaución:** Mover 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, entonces 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 transactionLogRetentionDays configuración de la PITR. 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 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 una de las siguientes configuraciones:

• El parámetro de configuración de copia de seguridad transactionLogRetentionDays
• La marca expire_logs_days o la marca 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 la ubicación de almacenamiento de registros se cambia a Cloud Storage, no puedes modificar los valores de las marcas. Tampoco te recomendamos que configures ningún valor de marca en 0. Para obtener más información, consulta Configura marcas de bases 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 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 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 PITR

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

• Puedes desactivar la PITR y volver a habilitarla para asegurarte de que Cloud SQL almacene 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 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.
• Te recomendamos que habilites el aumento automático de almacenamiento para evitar problemas inesperados relacionados con el 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 bases 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 bases de datos pueden interferir con 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 correctas para cualquier base de datos en la instancia.

Modelo de recuperación de base de datos para PITR

Cuando 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 interrumpir 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, tu instancia debe tener la PITR y las copias de seguridad retenidas habilitada antes de que se borre la instancia. Cuando está habilitada, los registros de PITR se retienen después de que borras la instancia.

Después de borrar una instancia, los registros de PITR continúan siguiendo 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 según el período de retención de PITR establecido en la instancia antes de la eliminación. Por ejemplo, si tu instancia de 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 la eliminación de 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 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.

El período de recuperación de PITR se define como los tiempos de recuperación más antiguos y más recientes disponibles para restablecer tu instancia con la PITR. Para encontrar los tiempos de recuperación más antiguos y más recientes de tu 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 a una instancia nueva

Cuando restableces tu instancia a 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.

• Cuando se crea una instancia nueva, la función storageAutoResize está habilitada de forma predeterminada. Cualquier copia de seguridad creada posteriormente hereda el mismo parámetro 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 tu instancia, consulta Ve 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 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:

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)