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. 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 para archivar 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 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 la edición 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.
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 la edición Cloud SQL Enterprise que crees con la PITR habilitada después del 31 de mayo de 2024 almacenarán los registros que se usan 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 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 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.
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 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 la PITR habilitada, la instancia almacena sus registros de transacciones 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 de transacciones 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_daysobinlog_expire_logs_seconds
Cloud SQL no establece ningún valor para estas marcas si los registros de transacciones 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 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 que se conservan como parte del parámetro retained-transaction-log-days.
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.
Instantáneas de la base 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 la base 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 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.
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 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_timelog_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. 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.