¿Por qué estos procesos tardan tanto?

Descripción corta

Las técnicas de copia de seguridad y restauración continuas de Amazon Aurora están optimizadas para que no se produzcan variaciones en los tiempos de restauración. También ayudan a que el volumen de almacenamiento del clúster alcance su máximo rendimiento tan pronto como el clúster esté disponible. Los tiempos de restauración prolongados suelen deberse a transacciones de larga ejecución en la base de datos de origen en el momento en que se realiza la copia de seguridad.

Resolución

Nota: Si recibe errores al ejecutar comandos de la AWS Command Line Interface (AWS CLI), asegúrese de utilizar la versión más reciente de AWS CLI.

Amazon Aurora realiza copias de seguridad de los cambios en el volumen de su clúster de forma automática y continua. Las copias de seguridad se conservan durante el periodo de conservación de las copias de seguridad. Esta copia de seguridad continua le permite restaurar sus datos en un nuevo clúster, a cualquier momento dado del periodo de conservación especificado. De este modo, no es necesario recorrer a un largo proceso de restauración por progresión del registro binario. Como está creando un clúster nuevo, el rendimiento de la base de datos original no se ve afectado ni se interrumpe su funcionamiento queda interrumpido.

Al iniciar una restauración a partir de un clon, de una instantánea o a un momento dado, Amazon Relational Database Service (Amazon RDS) llama a las siguientes API en su nombre:

• RestoreDBClusterFromSnapshot o RestoreDBClusterToPointInTime. Estas API crean un nuevo clúster y restauran el volumen desde Amazon Simple Storage Service (Amazon S3). Este proceso puede tardar unas horas en completarse. Al restaurar datos en un clúster de Aurora, todos los datos se transfieren en paralelo de Amazon S3 a las seis copias de sus tres zonas de disponibilidad.
• La clonación de volúmenes de almacenamiento en clústeres es una variación de RestoreDBClusterToPointInTime. Utiliza el protocolo de copiar y escribir y, por lo general, se completa en unos minutos.

Al finalizar este paso, el clúster pasa al estado Disponible. Para comprobar el estado del clúster, actualice la consola o compruébelo con la AWS CLI.

El proceso de creación de instancias empieza cuando el clúster está disponible. y sucede en dos etapas: se configura la configuración de la instancia y se recupera el bloqueo de la base de datos.

Puedes comprobar si la API ha terminado de configurar la instancia buscando el archivo de registro de errores de MySQL. Puede hacerlo incluso si la instancia está en estado En creación. Si el archivo de registro de errores está disponible para descargarse, la instancia está configurada y el motor está realizando la recuperación de fallos. El archivo del registro de errores también es el mejor recurso para comprobar el progreso de la recuperación del bloqueo de la base de datos, junto con las métricas de Amazon CloudWatch.

Nota: Si utiliza AWS CLI o la API para realizar una operación de restauración, debe invocar la llamada CreateDBInstance porque no es automática.

Comprobar si hay operaciones de escritura de larga ejecución en la base de datos de origen

Se recomienda confirmar que no hay operaciones de escritura que se ejecuten durante mucho tiempo en la base de datos de origen en el momento de realizar la recuperación a partir de una instantánea, de un clon o a un momento dado. Cualquier transacción de escritura abierta (DCL, DDL o DML) que se ejecute durante mucho tiempo podría alargar el tiempo que tarda la base de datos restaurada en estar disponible.

Por ejemplo, al activar el registro binario de un clúster de Aurora, aumenta el tiempo necesario para realizar la recuperación. Esto se debe a que InnoDB comprueba automáticamente los registros y realiza una transferencia de la base de datos al presente. A continuación, anula todas las transacciones no comprometidas que estén presentes en el momento de la recuperación. Para obtener más información sobre la recuperación de fallos de InnoDB, consulte Recuperación de Innodb.

Cuando la instancia termina los procesos de creación y recuperación, el clúster y la instancia estarán listos para aceptar conexiones entrantes.

Nota: Aurora no requiere el registro binario. Se recomienda desactivarlo a menos que sea necesario. Para la replicación entre regiones, puede optar por evaluar las bases de datos globales de Aurora . Las bases de datos globales de Aurora tampoco requieren registros binarios.

Información relacionada

Almacenamiento y fiabilidad de Amazon Aurora

Restaurar desde una instantánea de clúster de base de datos