Come posso aggiornare senza problemi la versione principale di un database postgres AWS RDS?

Questa mattina sono stato coinvolto nell'aggiornamento di un database PostgreSQL su AWS RDS. Volevamo passare dalla versione 9.3.3 alla versione 9.4.4. Avevamo "testato" l'aggiornamento su un database di gestione temporanea, ma il database di gestione temporanea è molto più piccolo e non utilizza Multi-AZ. Si è scoperto che questo test era abbastanza inadeguato.

Il nostro database di produzione utilizza Multi-AZ. Abbiamo effettuato aggiornamenti di versione minori in passato e in questi casi RDS aggiornerà prima lo standby e poi lo promuoverà al master. Pertanto, l'unico tempo di inattività sostenuto è ~ 60s durante il failover.

Presumemmo che lo stesso sarebbe accaduto per l'aggiornamento della versione principale, ma oh quanto ci sbagliavamo.

Alcuni dettagli sulla nostra configurazione:

• db.m3.large
• Provisioning IOPS (SSD)
• 300 GB di memoria, di cui 139 GB utilizzati
• Avevamo aggiornamenti del sistema operativo RDS in sospeso, volevamo eseguire il batch con questo aggiornamento per ridurre al minimo i tempi di fermo

Ecco gli eventi RDS registrati durante l'esecuzione dell'aggiornamento:

La CPU del database è stata al massimo tra le 08:44 e le 10:27. Molto di questo tempo sembrava essere occupato da RDS che realizzava uno snapshot pre-aggiornamento e post-aggiornamento.

I documenti AWS non avvertono di tali ripercussioni, anche se dalla loro lettura è chiaro che un difetto evidente nel nostro approccio è che non abbiamo creato una copia del database di produzione nell'impostazione Multi-AZ e abbiamo cercato di aggiornarlo come una corsa di prova

In generale è stato molto frustrante perché RDS ci ha fornito pochissime informazioni su ciò che stava facendo e quanto tempo ci sarebbe voluto. (Ancora una volta, fare una corsa di prova avrebbe aiutato ...)

A parte questo, vogliamo imparare da questo incidente, quindi ecco le nostre domande:

• Questo genere di cose è normale quando si esegue un aggiornamento della versione principale su RDS?
• Se in futuro volessimo effettuare un aggiornamento della versione principale con tempi di inattività minimi, come potremmo procedere? Esiste un modo intelligente di usare la replica per renderla più fluida?

Questa è una buona domanda, a volte
lavorare in un ambiente cloud è complicato.

È possibile utilizzare il pg_dumpall -f dump.sqlcomando, che scaricherà l'intero database in un formato di file SQL, in modo da poterlo ricostruire da zero puntando ad altri endpoint. Usando psql -h endpoint-host.com.br -f dump.sqlin breve.

Ma per farlo, avrai bisogno di qualche istanza EC2 con uno spazio ragionevole nel disco (per adattarsi al dump del database). Inoltre, dovrai eseguire l'installazione yum install postgresql94.x86_64per poter eseguire il dump e il ripristino dei comandi.

Vedi esempi in PG Dumpall DOC .

Ricordare che per mantenere l'integrità dei dati, si consiglia (in alcuni casi sarà obbligatorio) di arrestare i sistemi che si connettono al database durante questa finestra di manutenzione.

Inoltre, se avete bisogno di accelerare le cose, è possibile utilizzare pg_dumpinvece pg_dumpall, sfruttando il parallelismo ( -j njobsparametri), quando si determina il numero di CPU coinvolta nel processo, ad esempio -j 8userà fino a 8 CPU. Per impostazione predefinita, il comportamento di pg_dumpallo pg_dumpè solo l'uso 1. L'unico vantaggio di utilizzare pg_dumpinvece pg_dumpallè che sarà necessario eseguire il comando per ciascun database in uso e scaricare i ROLES (gruppi e utenti) separati.

Vedi esempi su PG Dump DOC e PG Restore DOC .