En esta página se proporciona información que debes revisar antes de restaurar una instancia a partir de una copia de seguridad o de realizar una recuperación a un momento dado (PITR).
¿Qué ocurre durante una restauración?
En las ediciones Enterprise y Enterprise Plus de Cloud SQL, puedes restaurar una instancia a partir de una copia de seguridad. También puedes restaurar copias de seguridad en instancias de diferentes ediciones.
Cuando restauras una instancia, se restauran los siguientes datos de la instancia principal en la nueva instancia:
- Bases de datos
- Usuarios
La operación de restauración provoca que la instancia se reinicie.
Recuperación a un momento dado (PITR)
La recuperación a un momento dado (PITR) te ayuda a recuperar una instancia a un momento dado. 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.
PITR siempre crea una nueva instancia. No puedes realizar una recuperación a un momento dado en una instancia que ya exista. La nueva instancia hereda la configuración de la instancia de origen, de forma similar a como funciona la creación de clones.
Cuando creas una instancia de Cloud SQL en la Google Cloud consola, PITR está habilitado de forma predeterminada.La recuperación a un momento dado usa el archivado de registros de escritura previa (WAL). De forma predeterminada, PITR está habilitado en las instancias de la edición Enterprise Plus de Cloud SQL.
Si restauras una copia de seguridad en una instancia de Cloud SQL antes de habilitar PITR, perderás los registros archivados que te permiten usar PITR. Si el tamaño de los registros de escritura anticipada en el disco está provocando problemas de rendimiento en tu instancia, desactiva PITR y vuelve a habilitarla. De esta forma, los nuevos registros se almacenarán en Cloud Storage en lugar de en el disco.Para ver instrucciones detalladas sobre cómo realizar una recuperación a un momento dado, consulta Usar la recuperación a un momento dado (PITR).
Restaurar una instancia no disponible
Puedes usar PITR para restaurar una instancia de Cloud SQL que no esté disponible. PITR suele ofrecer un objetivo de punto de recuperación (RPO) de cinco minutos o menos.
Si la instancia no está disponible, puedes usar la API para consultar la hora más reciente a la que puedes restaurar la instancia y realizar la recuperación a esa hora. Si no se puede acceder a la zona en la que está configurada la instancia, puedes restaurarla en otra zona principal o secundaria proporcionando valores para las zonas preferidas.
Supongamos que una instancia de Cloud SQL deja de estar disponible a las 16:00 (EST). Si la última hora de recuperación es las 15:55 (EST), puedes recuperar la instancia hasta esa hora.
Consejos generales sobre cómo realizar una restauración
Al restaurar una instancia desde una copia de seguridad, ya sea a la misma instancia o a una instancia diferente, se deben tener en cuenta los siguientes elementos:
- La operación de restauración sobrescribe todos los datos en la instancia de destino.
- La instancia de destino no está disponible para las conexiones durante la operación de restauración; se pierden las conexiones existentes.
- Si vas a restaurar una instancia con réplicas de lectura, debes eliminar todas las réplicas y volver a crearlas una vez que se haya completado la operación de restauración.
- La operación de restauración reinicia la instancia.
Para obtener instrucciones detalladas sobre cómo realizar una restauración, consulta los siguientes artículos:
Consejos y requisitos para restaurar a una instancia diferente
Cuando estás restaurando una copia de seguridad en una instancia diferente, ten en cuenta las siguientes restricciones y prácticas recomendadas:
La instancia de destino debe tener la misma versión de base de datos que la instancia de la que se tomó la copia de seguridad.
Cloud SQL siempre asigna a la instancia de destino la capacidad de almacenamiento máxima del tamaño del disco configurado y del disco de copia de seguridad. El tamaño del disco de copia de seguridad es el tamaño del disco cuando se realiza la copia de seguridad.
La capacidad de almacenamiento de la instancia de destino debe ser al menos igual que la capacidad de la instancia de la que se va a crear la copia de seguridad. La cantidad de almacenamiento utilizado no importa. Puedes ver la capacidad de almacenamiento de la instancia en la página de instancias de Cloud SQL de la consola.
La instancia de destino debe tener en el estado
RUNNABLE.La instancia de destino puede tener un número de núcleos o una cantidad de memoria diferentes a los de la instancia desde la que se tomó la copia de seguridad.
La instancia de destino puede estar en una región diferente a la de la instancia de origen.
Durante una interrupción, puedes seguir obteniendo una lista de copias de seguridad de un proyecto concreto. Consulta Ver copias de seguridad durante una interrupción del servicio.
Restaurar las limitaciones de frecuencia
Puedes realizar un máximo de tres operaciones de restauración cada 30 minutos por instancia, región y proyecto. Si falla una operación de restauración, no se tiene en cuenta para esta cuota. Si alcanzas el límite, la operación fallará y se mostrará un mensaje de error que te indicará cuándo podrás volver a ejecutarla.
Veamos cómo limita la frecuencia Cloud SQL en las restauraciones.
Cloud SQL usa tokens de un contenedor para determinar cuántas operaciones de restauración están disponibles en un momento dado. En cada copia de seguridad, hay un contenedor para cada proyecto y región de destino. Las instancias de destino del mismo proyecto comparten un segmento si están en la misma región. Puedes usar un máximo de tres tokens en cada contenedor para las operaciones de restauración. Cada 10 minutos, se añade un nuevo token al contenedor. Si el contenedor está lleno, el token se desborda.
Cada vez que emites una operación de restauración, se concede un token del contenedor. Si la operación se realiza correctamente, el token se elimina del segmento. Si falla, el token se devuelve al contenedor. En el siguiente diagrama se muestra cómo funciona:
Por ejemplo, en la siguiente figura, Copia de seguridad 1, Copia de seguridad 2 y Copia de seguridad 3 son copias de seguridad de la misma instancia de origen.
- Cada copia de seguridad (Copia de seguridad 1, Copia de seguridad 2 y Copia de seguridad 3) tiene su propio segmento de tokens para las operaciones de restauración que se dirigen a diferentes instancias del proyecto 1 en la región A (Segmento11A, Segmento21A y Segmento31A). Como cada copia de seguridad tiene su propio contenedor, puedes restaurar cada copia de seguridad en la misma instancia tres veces cada 30 minutos.
- Cada copia de seguridad tiene un contenedor para un proyecto y una región independientes.
Por ejemplo, si hay cinco proyectos en una región, habrá cinco segmentos 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 cubos de tokens para las operaciones de restauración en la región A. Un segmento para el proyecto 1 (Segmento11A) y otro para el proyecto n (Segmento1nA).
- Del mismo modo, Backup3 tiene dos cubos para las operaciones de restauración en la región A. Una para el proyecto 1 (Bucket31A) y otra para el proyecto n (Bucket3nA).
- Backup3 tiene un segmento en la región B para Project1, ya que todas las instancias del mismo proyecto y de la misma región de destino comparten un segmento.