Qual è l'impatto della modifica della mia istanza Single-AZ di Amazon RDS ad un'istanza Multi-AZ e viceversa?

Breve descrizione

In una configurazione Single-AZ, un'istanza database Amazon RDS e uno o più volumi di archiviazione Amazon Elastic Block Store (Amazon EBS) vengono implementati in un'unica zona di disponibilità. In una configurazione Multi-AZ, le istanze database e i volumi di archiviazione EBS vengono implementati in due zone di disponibilità.

Quando abiliti Multi-AZ sulla tua istanza, Amazon RDS mantiene una copia in standby ridondante e coerente dei dati utilizzando la replica sincrona dell'archiviazione. Amazon RDS rileva e si ripristina quindi automaticamente dagli scenari di guasto dell'infrastruttura più comuni per le implementazioni Multi-AZ. Questi rilevamento e ripristino si verificano in modo da poter riprendere le operazioni del database il più rapidamente possibile. Per ulteriori informazioni, consulta Alta disponibilità (Multi-AZ) per Amazon RDS.

Per modificare un'istanza database da una implementazione Single-AZ a una implementazione Multi-AZ e viceversa, consulta Modifica di un'istanza Amazon RDS.

Risoluzione

Impatto della modifica di un'istanza Single-AZ su un'istanza Multi-AZ

Quando modifichi l'istanza Single-AZ in un'istanza Multi-AZ, non si verificano tempi di inattività sull'istanza. Durante la modifica, Amazon RDS crea uno snapshot dei volumi dell'istanza. Quindi, questo snapshot viene utilizzato per creare nuovi volumi in un'altra zona di disponibilità. Sebbene questi nuovi volumi siano immediatamente disponibili per l'uso, potrebbe risentirsi un impatto sulle prestazioni. Questo impatto si verifica perché i dati del nuovo volume vengono comunque caricati da Amazon Simple Storage Service (Amazon S3). Nel frattempo, l'istanza database continua a caricare i dati in background. Questo processo, chiamatolazy loading, potrebbe comportare una latenza di scrittura elevata e un impatto sulle prestazioni durante e dopo il processo di modifica.

La portata dell'impatto sulle prestazioni è in funzione del tipo di volume, del carico di lavoro, dell'istanza e delle dimensioni del volume. L'impatto potrebbe essere significativo per le istanze database di grandi dimensioni a uso intensivo di scrittura durante le ore di punta delle operazioni. Di conseguenza, è una best practice testare l'impatto su un'istanza di test prima di eseguire questa modifica in produzione. È inoltre una best practice completare questa modifica in una finestra di manutenzione o a bassa produttività.

Ridurre la durata del caricamento

Per ridurre in modo proattivo la durata e l'impatto del carico, procedi come segue:

1. Modifica il tipo di storage dell'istanza database in IOPS con provisioning. Assicurati di effettuare il provisioning di una quantità di IOPS sostanzialmente superiore a quella richiesta dal carico di lavoro.
   Nota: questo passaggio può causare un breve periodo di inattività se l'istanza utilizza un gruppo di parametri personalizzato.
2. Modifica l'istanza in Multi-AZ.
3. Avvia un failover sulla tua istanza per assicurarti che la nuova zona di disponibilità sia la zona di disponibilità primaria.
4. Esegui un dump completo dei dati sulla tua istanza. Oppure, esegui query di scansione di tabelle complete sulle tabelle più attive per accelerare il caricamento dei dati nei volumi.
5. Verifica che la latenza di scrittura sia tornata ai livelli normali esaminando il parametro WriteLatency in Amazon CloudWatch.
6. Modifica il tipo di archiviazione dell’istanza o gli IOPS dell'istanza riportandoli alla configurazione precedente.
   Nota: questo passaggio non richiede tempi di inattività.

Ridurre la latenza se l'istanza è già Multi-AZ

Per ridurre la latenza se è già stata modificata l'istanza in Multi-AZ, procedi come segue:

1. Avvia un failover sulla tua istanza per assicurarti che la nuova zona di disponibilità sia la zona di disponibilità primaria.
2. Modifica il tipo di storage dell'istanza database in IOPS con provisioning. Assicurati di effettuare il provisioning di una quantità di IOPS sostanzialmente superiore a quella richiesta dal carico di lavoro.
   Nota: questo passaggio non richiede tempi di inattività.
3. Esegui un dump completo dei dati sulla tua istanza. Oppure, esegui query di scansione di tabelle complete sulle tabelle più attive per accelerare il caricamento dei dati nei volumi.
4. Verifica che la latenza di scrittura sia tornata ai livelli normali esaminando il parametro WriteLatency in Amazon CloudWatch.
5. Modifica il tipo di archiviazione dell’istanza o gli IOPS dell'istanza riportandoli alla configurazione precedente.
   Nota: questo passaggio non richiede tempi di inattività.

Se modifichi un'istanza database da Single-AZ a Multi-AZ, viene creata una nuova istanza standby con la stessa configurazione in un'altra zona di disponibilità. Ciò comporta costi aggiuntivi. Inoltre, poiché Multi-AZ utilizza la replica sincrona, le scritture sono leggermente più lente di quelle in Single-AZ.

Impatto della modifica di un'istanza Multi-AZ su un'istanza Single-AZ

Quando cambi istanza da Multi-AZ a Single-AZ, non si verificano tempi di inattività sull'istanza. Durante la modifica, Amazon RDS elimina solo l'istanza e i volumi secondari e l'istanza principale non ne risente.

Ecco alcuni aspetti da considerare prima di modificare l'istanza dall’implementazione da Multi-AZ a Single-AZ:

• Con l’implementazione Multi-AZ, Amazon RDS passa automaticamente a una replica in standby in un'altra zona di disponibilità durante un'interruzione pianificata o non pianificata dell'istanza database. Tuttavia, in un'istanza Single-AZ, potrebbe essere necessario avviare un'operazione di ripristino point-in-time. Il completamento di questa operazione può richiedere diverse ore. Eventuali aggiornamenti dei dati che si verificano dopo l'ultimo periodo di ripristino non saranno disponibili. Pertanto, potrebbe verificarsi un ulteriore tempo di inattività su un'istanza di Single-AZ in caso di fallimento.
• In un'istanza Multi-AZ, i backup automatici vengono creati dall'istanza secondaria durante la finestra di backup automatico. Per Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for Oracle e Amazon RDS for PostgreSQL, l'attività di I/O non viene sospesa sull'istanza primaria durante il backup per le implementazioni Multi-AZ, perché il backup viene prelevato dal secondario. Per Amazon RDS for SQL Server, l'attività di I/O viene sospesa brevemente durante il backup per le implementazioni Multi-AZ. Il processo di backup su un'istanza database Single-AZ comporta una breve sospensione dell'I/O che può durare da pochi secondi a pochi minuti, a seconda delle dimensioni e della classe dell'istanza database. La quantità di tempo dipende dalle dimensioni e dalla classe dell'istanza database.
• Nelle implementazioni Multi-AZ, la manutenzione del sistema operativo viene applicata all'istanza secondaria. La seconda istanza viene promossa a primaria, quindi la manutenzione viene eseguita sul vecchio primario, che diventa il nuovo standby. Il tempo di inattività durante alcuni patch del sistema operativo in un'istanza Multi-AZ è quindi minimo.
• Se stai ridimensionando l'istanza Multi-AZ, il tempo di inattività è minimo. Questo perché l'istanza secondaria viene modificata per prima. L'istanza secondaria viene promossa a primaria. Quindi, l’istanza primaria meno recente, ora secondaria, viene modificata. Un'istanza Single-AZ non è disponibile durante l'operazione di ridimensionamento.

---

Informazioni correlate

Implementazioni Multi-AZ di Amazon RDS