Ho una piccola istanza RDS di MySQL come parte del mio sistema di produzione e voglio aggiornarla a un'istanza media con IOPS fornito.

Come DBA della vecchia scuola sono a conoscenza del metodo "aggiungi slave; promuovi al master; cambia client", ma AWS promette di fornire un magico percorso di aggiornamento con un clic, ovvero "istanza di aggiornamento", "aggiungi IOPS forniti".

Ho provato questo sull'istanza RDS di prova, i tempi di inattività sono troppo lunghi, IMHO: circa 5 minuti per l'aggiornamento piccolo-> medio e 30 minuti (!!!) per passare agli IOPS forniti.

• Questo comportamento è normale?
• Esiste un modo per eseguire l'aggiornamento su RDS di produzione senza tempi di inattività?
• Consiglieresti "stop; crea uno snapshot; ripristina dallo snapshot all'istanza più grande"?

L'aggiornamento di un'istanza in RDS significa che RDS migrerà fisicamente il database in una nuova istanza, probabilmente su un host fisico diverso, quindi i tempi di inattività non sarebbero evitabili. La migrazione a IOPS con provisioning significherebbe probabilmente che i tuoi dati verrebbero migrati su un nuovo volume EBS (e che anche il server potrebbe essere migrato verso una nuova istanza con questa modifica, a seconda che, internamente, le macchine in grado di accedere ai volumi EBS con IOPS con provisioning siano fisicamente separati da macchine che non lo sono, in modo che possano trovarsi su una diversa classe di hardware di rete), quindi i tempi di inattività sarebbero nuovamente inevitabili.

Sembra esserci un modo per evitare questa interruzione: una distribuzione Multi-AZ, che crea una replica invisibile e inaccessibile (a te) in un'altra zona di disponibilità all'interno della regione.

Nel caso di aggiornamenti di sistema come patch del sistema operativo o ridimensionamento dell'istanza DB, queste operazioni vengono applicate prima in standby, prima del failover automatico. Di conseguenza, l'impatto sulla disponibilità è limitato solo al tempo necessario per il completamento del failover automatico.

^{- http://aws.amazon.com/rds/multi-az/}

Ciò dovrebbe fornire un percorso di migrazione rapido e senza interruzioni, anche se non ho avuto occasione di testare questa funzionalità. Appare "Modifica" nella console per consentire di convertire un'istanza in Multi-AZ. Presumibilmente, ciò comporterebbe un breve blocco I / O man mano che l'istanza viene clonata, quindi ovviamente consiglierei di testare tutte queste funzionalità prima di provarlo.

In alternativa, RDS supporta un meccanismo interno che dovrebbe consentire di emulare l'operazione "Aggiungi slave; Promuovi al master; Cambia client" e ciò dovrebbe anche consentire di ottenere una conversione dei tempi di inattività quasi zero:

• Creare una replica di lettura RDS effettiva del database con la classe di istanza desiderata
• Attendi che la replica venga online e sincronizzata con il master
• Modificare la configurazione della replica per aggiungere IOPS con provisioning
• Attendi che la replica venga online e sincronizzata con il master
• Verificare che entrambi i sistemi abbiano dati identici utilizzando strumenti di terze parti
• Disconnetti l'applicazione dal vecchio master
• Verificare le coordinate binlog corrispondenti su master e replica per assicurarsi che tutte le scritture dell'applicazione siano state replicate
• Dividi i sistemi con "Promuovi lettura replica" sulla nuova replica in RDS
• Connetti la tua applicazione al nuovo master

http://aws.amazon.com/about-aws/whats-new/2012/10/11/amazon-rds-mysql-rr-promotion/

Anche con un ambiente multi-AZ, si avrà un'interruzione di 60-120 secondi. Questo è stato il caso in cui ho colpito ripetutamente le nostre istanze RDS mentre eseguivo un aggiornamento da un PostbreSQL db.m3.medium a un db.m3.large.

È inoltre POSSIBILE evitare eventuali tempi di fermo durante l'aggiornamento. Il modo per farlo è quello di avviare brevemente un nuovo RDS da un'istantanea della replica di lettura e configurarlo come replica master / master attiva / attiva. Una volta configurato, è possibile cambiare il traffico dell'applicazione un server APP alla volta senza tempi di inattività. Utilizziamo l'approccio ogni volta che AWS annuncia manutenzioni RDS per evitare tempi di inattività nonché durante le nostre manutenzioni programmate.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

Ecco i dettagli:

M1 - Maestro originale

R1 - Leggi la replica della M1

SNAP1 - Istantanea di R1

M2 - Nuovo maestro

Sequenza di creazione M2: M1 → R1 → SNAP1 → M2

• Dato che non possiamo usare il privilegio SUPER su RDS, non usiamo mysqldump con l' — master_data2opzione sull'M1. Invece, lanciamo R1 per ottenere la posizione binlog di M1 da esso. Quindi creare uno snapshot (SNAP1) da R1 e quindi avviare M2 da SNAP1.

• Creare due gruppi di parametri RDS separati con i seguenti offset per evitare conflitti PK:

  M1: auto_increment_ increment = 4 and auto_increment_offset = 1

  M2: auto_increment_ increment = 4 and auto_increment_offset = 2

• Crea un utente di replica su M1

  GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;

1. Creare R1 da M1

-- Connect to the R1 and stop replication
   CALL mysql.rds_stop_replication;
-- Obtain M1’s (!!) current binlog file and position 
        `mysql> show slave status\G
             Master_Log_File: mysql-bin.000622
             Exec_Master_Log_Pos: 9135555

2. Creare SNAP1 da R1

• Creare M2 da SNAP1 con gli attributi ottenuti da M1

• Assegnare un gruppo di parametri a M2 con un offset auto_increment_ diverso da M1 per evitare conflitti con la chiave di replica M / M

4. Configurare la replica M / M

-- Configure M2 as a slave of M1
CALL mysql.rds_set_external_master (‘m1.xyxy24.us-east-1.rds.amazonaws.com’, 3306, ‘repl’, ‘mypassword’, ‘mysql-bin.000622, 9135555, 0);
CALL mysql.rds_start_replication;
-- Connect to M2 and obtain its current binlog file and position
         mysql> show master status\G
            File: mysql-bin.004444
            Position: 6666622
-- Connect to M1 and configure it to be a slave of the M2
CALL mysql.rds_set_external_master (‘m2.xyxy24.us-east-1.rds.amazonaws.com’, 3306 , ‘repl’, ‘mypassword’, ‘mysql-bin.004444, 6666622, 0);
CALL mysql.rds_start_replication;

5. Eliminare R1 e SNAP1 poiché non sono più necessari

6. Aggiorna M2 tramite AWS Console

Utilizzare la procedura standard per modificare l'istanza in base alle proprie esigenze.

7. Esegui il passaggio grazioso a M2

Una volta che la replica M / M è stata impostata correttamente, siamo pronti per procedere con la manutenzione del DB senza tempi di inattività, cambiando graziosamente i server delle app uno alla volta.

Ecco ulteriori dettagli su come funziona.

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

Ciò funzionerebbe, tuttavia è necessario assicurarsi che gli endpoint dell'istanza RDS non siano configurati nell'applicazione come una voce statica. Lo scambio di RDS cambierà gli endpoint.