Perché il clone del cluster Amazon Aurora DB, il ripristino di un'istantanea o il ripristino di un punto nel tempo richiedono molto tempo?

Breve descrizione

Le tecniche di backup e ripristino continui di Amazon Aurora sono ottimizzate per evitare variazioni nei tempi di ripristino. Inoltre, aiutano il volume di archiviazione del cluster a raggiungere le massime prestazioni non appena il cluster diventa disponibile. I lunghi tempi di ripristino sono generalmente causati da transazioni di lunga durata nel database di origine al momento dell'esecuzione del backup.

Risoluzione

Nota: Se ricevi errori durante l'esecuzione dei comandi AWS Command Line Interface (AWS CLI), assicurati di utilizzare la versione più recente dell'interfaccia a riga di comando di AWS.

Amazon Aurora esegue il backup delle modifiche del volume del cluster in modo automatico e continuo. I backup vengono conservati per la durata del periodo di conservazione dei backup. Questo backup continuo consente di ripristinare i dati su un nuovo cluster, in qualsiasi momento entro il periodo di conservazione specificato. Questo evita la necessità di un lungo processo di roll-forward del binlog. Poiché si crea un nuovo cluster, non vi è alcun impatto sulle prestazioni o sulle interruzioni del database originale.

Quando avvii un clone, uno snapshot o un ripristino point-in time, Amazon Relational Database Service (Amazon RDS) chiama le seguenti API per tuo conto:

• O RestoreDBClusterFromSnapshot o RestoreDBClusterToPointInTime. Queste API creano un nuovo cluster e ripristinano il volume da Amazon Simple Storage Service (Amazon S3). Il completamento di questa operazione può richiedere fino a qualche ora. Quando ripristini i dati su un cluster Aurora, tutti i dati vengono trasferiti in parallelo da Amazon S3 alle sei copie delle tue tre zone di disponibilità.
• La clonazione del volume di archiviazione del cluster è una variante di RestoreDBClusterToPointInTime. Utilizza il protocollo copy-on-write e di solito si completa in pochi minuti.

Al termine di questo passaggio, il cluster passa allo stato Disponibile. Puoi controllare lo stato del cluster aggiornando la console o controllando con l'interfaccia a riga di comando di AWS.

Il processo di creazione dell'istanza inizia solo quando il cluster è disponibile. Ciò avviene in due fasi: impostazione della configurazione dell'istanza e ripristino da crash del database.

Puoi verificare se l'API ha completato la configurazione dell'istanza cercando il file di registro degli errori MySQL. È possibile eseguire questa operazione anche se l'istanza è in fase di creazione. Se il file di registro degli errori è disponibile per il download, l'istanza è configurata e il motore sta eseguendo il ripristino in caso di crash. Il file di registro degli errori è anche la risorsa migliore per verificare l'avanzamento del ripristino da crash del database, insieme ai parametri di Amazon CloudWatch.

Nota: Se utilizzi l'interfaccia a riga di comando o l'API di AWS per eseguire un'operazione di ripristino, devi richiamare la chiamata CreateDBInstance perché non è automatica.

Verifica la presenza di operazioni di scrittura di lunga durata sul database di origine

È consigliabile verificare che non vi siano operazioni di scrittura di lunga durata sul database di origine al momento dell'istantanea, del point-in-time o della clonazione. Qualsiasi DCL, DDL o DML (transazioni di scrittura aperte) di lunga durata potrebbe allungare il tempo necessario affinché il database ripristinato diventi disponibile.

Ad esempio, si attiva il log binario per un cluster Aurora e ciò aumenta il tempo necessario per eseguire un ripristino. Questo perché InnoDB controlla automaticamente i log ed esegue un roll-forward del database al presente. Quindi ripristina tutte le transazioni non confermate presenti al momento del ripristino. Per ulteriori informazioni su InnoDB crash recovery, consulta Innodb recovery.

Quando l'istanza termina i processi di creazione e ripristino, il cluster e l'istanza sono pronti ad accettare le connessioni in ingresso.

Nota: Aurora non richiede il log binario. È consigliabile disattivarlo a meno che non sia necessario. Per la replica tra regioni, puoi invece valutare i database globali Aurora. Inoltre, i database globali Aurora non richiedono log binari.

Informazioni correlate

Archiviazione e affidabilità di Amazon Aurora

Ripristino da un'istantanea del cluster di database