Perché il ripristino delle istantanee del mio cluster di database compatibile con Aurora MySQL impiega così tanto tempo?

Breve descrizione

Il processo di ripristino delle istantanee per i cluster DB Edition compatibili con Amazon Aurora MySQL include una serie di attività importanti. Ad esempio, durante questo processo viene creato un cluster Aurora, così come il volume del cluster ad alta disponibilità. Processi come il controllo dello stato, l'archiviazione e l'allocazione dell'hardware e la scrittura di volumi di dati influiscono sul tempo necessario per il ripristino di un'istantanea.

Il tempo di ripristino delle istantanee è influenzato da una serie di fattori:

• Per i cluster Aurora, un cluster singolo è distribuito in tre zone di disponibilità (AZ) per fornire un'elevata disponibilità. Quando il cluster Aurora esegue il ripristino dall'istantanea, fornisce spazio di archiviazione in queste tre AZ. Una volta che il cluster diventa disponibile, crea altre sei copie all'interno del volume del cluster per l'archiviazione dei dati. Il volume di archiviazione è distribuito su centinaia di nodi di storage e distribuito su tre diverse AZ.
• Dopo la creazione del cluster Aurora, il cluster scarica i dati da Amazon Simple Storage Solution S3 (Amazon S3) nei nodi di storage. Il cluster esegue questa operazione prima che i dati diventino disponibili. A differenza del processo di ripristino per Amazon Relational Database Service (Amazon RDS) per istanze MySQL, il caricamento lento non si verifica dopo il ripristino.
• I ripristini Aurora non sono lineari. Ad esempio, potresti ripristinare due cluster separati, uno con 1 GB di dati e l'altro con 10 GB di dati. Invece di impiegare dieci volte più tempo, il ripristino di un set di dati più grande richiede solo un po' più di tempo rispetto al set di dati più piccolo.
• Altri processi all'interno del ripristino includono il controllo dello stato, l'allocazione dello storage e dell'hardware e la scrittura di volumi di dati. Tutti questi processi richiedono tempo, ma devono essere eseguiti con precisione per ottenere le migliori prestazioni.

Risoluzione

È possibile utilizzare la funzione di clonazione del cluster Aurora o la funzione di backtrack quando si apportano modifiche ai database Aurora, a seconda del caso d'uso.

Clone del cluster Aurora

L'utilizzo della funzione di clonazione del cluster Aurora è il modo più veloce per creare una copia identica del cluster corrente. Dopo aver creato il cluster clonato, è possibile testare le modifiche rispetto al cluster clonato senza influire sul cluster originale. Se il test viene superato, è possibile applicare delle modifiche al cluster originale.

Nota: è comunque consigliabile scattare un'istantanea del cluster prima di apportare modifiche a un database.

Ecco alcuni casi d'uso comuni per la clonazione di un cluster Aurora esistente:

• È bene sperimentare e valutare l'impatto di modifiche come le modifiche allo schema o le modifiche ai gruppi di parametri.
• È bene eseguire operazioni che richiedono un carico di lavoro intensivo, come l'esportazione di dati o l'esecuzione di interrogazioni analitiche.
• È bene creare una copia di un cluster DB di produzione in un ambiente non di produzione per lo sviluppo o il test.

Funzione di backtracking Aurora

Puoi anche utilizzare la funzionalità di backtracking per i tuoi cluster Aurora. Il backtracking consente di annullare rapidamente gli errori eseguendo un rewind diretto dei dati. Il backtracking di un cluster di database non richiede la creazione di un nuovo cluster di database, quindi sono necessari solo pochi minuti per completare l’operazione.

Tuttavia, ci sono dei limiti di questa funzionalità. Innanzitutto, è disponibile solo nei cluster creati con la funzionalità attivata. Quindi, se il tuo cluster non ha questa funzionalità attivata, devi eseguire un ripristino istantaneo per attivare il backtracking. Inoltre, il backtracking non supporta la replica dei log binari e la replica tra regioni deve essere disattivata prima di poter configurare o utilizzare il backtracking. Il limite per una finestra di backtrack è di 72 ore.

Considerazioni

Le funzionalità di clonazione e quella di backtrack del cluster Aurora sono state introdotte per migliorare i tempi di ripristino di Aurora in alcuni casi d'uso. Tuttavia, scattare istantanee regolari è comunque una buona pratica ed è consigliabile adottare questo approccio prima di apportare qualsiasi modifica pianificata a un database.

Inoltre, assicurati che non siano in esecuzione operazioni di scrittura di lunga durata sul database di origine al momento dell’istantanea, del point-in-time o del clone. Qualsiasi DCL, DDL o DML (transazioni di scrittura aperte) con esecuzione prolungata può aumentare il tempo necessario affinché il database ripristinato diventi disponibile.

Informazioni correlate

Clonazione di un volume per un cluster DB Amazon Aurora

Backtracking di un cluster Aurora DB

---