Tempo di inattività dell'istanza RDS AWS

Question

Ho alcune domande sull'aggiornamento dell'istanza RDS.

1. Qual è il tempo di inattività durante l'aggiornamento dell'istanza, diciamo da piccolo a grande. Il tempo di inattività è relativamente simile quando si va e si modifica qualsiasi tipo di istanza (piccolo, grande, xlarge) o ci sono fattori determinanti come la dimensione del database che alterano i tempi.
2. Qualcuno può condividere una tecnica su come aggiornare il tipo di istanza evitando i tempi di inattività utilizzando RDS? È anche possibile in RDS. Non deve essere in grande dettaglio solo alcune note di scogliera/immagini di grandi dimensioni.
3. C'è un tempo di inattività quando si assegna più spazio sul disco?

Answer 1

non credo che questa è una domanda in argomento per StackOverflow a tutti, ma alcune informazioni comunque:

1. È significativo e dipende dalla dimensione del database. Ho avuto bisogno di un'ora o più alcune volte. Ho anche avuto la creazione di istantanee, il ripristino da istantanee, e la creazione di multi-az richiede circa due ore prima.

2. Dipende da come si configurano le cose ora. Se Multi-AZ è già abilitato, un aggiornamento dell'istanza si verificherà effettivamente sullo slave, quindi si verificherà un failover, quindi il nuovo slave verrà aggiornato. Ciò comporta circa 1 o 2 minuti di tempo di inattività effettivo. L'aggiornamento dell'istanza sullo slave richiede in genere circa 10 o 20 minuti, ma non ci sono tempi di inattività in questa configurazione. Si noti che quando esegue il failover, Amazon esegue uno scambio DNS internamente in modo che l'endpoint RDS punti al computer corretto, quindi potrebbe essere necessario riavviare i processi Web che puntano al DB in modo che si riconnettano al DB e inseriscano il nuovo IP da una nuova ricerca DNS.

Answer 2

1, per esperienza personale ci vuole poco meno di un'ora, per essere precisi 57min per 15 GB di istanza di esempio da piccolo a grande. Che non mi aspettavo di essere così lungo per essere onesto. Aggiornamento : appena appreso che il punto di commutazione nel backup del tempo prima dell'aggiornamento accelera significativamente il processo

2, direi che creare MULTI AZ prima di eseguire l'aggiornamento farebbe il trucco, si spera che non abbia anche tempi di inattività. La domanda è esse consentono di aggiornare uno senza altra ...

3, sì, ma non sono sicuro al 100% se

Answer 3

db.t1.micro>db.m1.small: 8m30s

Engine: mysql 
Storage: 6GiB 
Backups: Yes 
Multi A-Z: No 

La dimensione/tipo di database non sembra influenzare in modo significativo il tempo di inattività.