Gestione di un aggiornamento Postgres critico per l'azienda

[Versione italiana di seguito]

Disclaimer: Many of our customers have confidentiality agreements safeguarding their brand names from commercial purposes. Hence, you may encounter references such as “Client Name Confidential”, or the customer’s industry instead of the customer’s brand name.

Hello everybody, i'm Luca Antonini from the Datacloud Ops Sircle and i'm here to tell you a story of success with our customer [Client Name Confidential]

MPS involved us in an important activity concerning a critical part of their business: an upgrade of 35 postgres instances from the unsupported version 9.46 to the latest supported at that time, version 12

Along with the support version 12 comes with new important features such as major enhancements to partitioning performances, B-tree indexes and allowing re-indexing during writes and multi-factor authentication.

Those Postgres instances were the databases behind [Client Name Confidential]'s digital banking application, therefore they held high importance and had to be upgraded with as minimal downtime as possible

Most of the strategies commonly used with upgrades can involve risk or significant downtimes: the backup and restore of SQL dumps using pg_dump involves a necessary downtime that becomes longer and longer with large amounts of data and the the other common way, pg_upgrade, is considered dangerous in a production environment and could lead to data loss.

Both those two solutions were deemed infeasible.

The strategy we proposed instead was to create multiple logical replicas of those instances: those standby replicas were created with the desired version 12 and received data directly from the older nodes, until they were up-to-date. At that point a simple failover was executed: the older node dismissed and the newer one became the master. in this way the upgrade could be done easily, safely and with the low downtime that the customer required.

The activity was coordinated and executed by our senior DBA Lorenzo Farioli, supported by me and our junior DBA Omar Locatelli. This represented a great opportunity of professional growth for Omar, as it was his first time working in a business-critical production environment.

The only minor difficulty we encountered was with the backup application Barman: it stopped working during the nightly updates but Lorenzo was able to fix it within the terms of the SLA

The customer was fully satisfied with our work: those 35 instances are now managed by our NGMS and this activity allowed us new opportunities, such as managing Postgres's security and the renewal of the NGMS support contract.

Avviso: Molti dei nostri clienti hanno stipulato accordi di riservatezza che tutelano i loro marchi da scopi commerciali. Pertanto potresti incontrare diciture come “Nome Cliente Riservato” oppure vedrai riportato il settore del cliente invece del suo nome.

Salve a tutti, sono Luca Antonini della Datacloud Ops Sircle e sono qui per raccontarvi una storia di successo con il nostro cliente [Nome Cliente Riservato].

MPS ci ha coinvolto in un'attività importante che riguardava una parte critica della loro attività: un aggiornamento di 35 istanze postgres dalla versione 9.46, non supportata, all'ultima supportata in quel momento, la versione 12.

Oltre al supporto, la versione 12 include nuove importanti funzionalità, come i principali miglioramenti alle prestazioni del partizionamento, gli indici B-tree e la possibilità che durante il re- indexing (reindicizzaione) le scritture e l'autenticazione a più fattori (multi-factor) .

Queste istanze Postgres erano i database alla base dell'applicazione di digital banking di [Nome Cliente Riservato], quindi avevano un'importanza elevata e dovevano essere aggiornate con il minor tempo di inattività possibile.

La maggior parte delle strategie comunemente utilizzate per gli aggiornamenti può comportare rischi o tempi di inattività significativi: il backup e il ripristino dei dump SQL utilizzando pg-dump comporta un tempo di inattività necessario che diventa sempre più lungo con grandi quantità di dati e l'altro metodo comune, pg_upgrade, è considerato pericoloso in un ambiente di produzione e potrebbe portare alla perdita di dati.

Entrambe le soluzioni sono state ritenute non praticabili.

La strategia che abbiamo proposto è stata invece quella di creare più repliche logiche di quelle istanze: le repliche in standby sono state create con la versione 12 desiderata e hanno ricevuto i dati direttamente dai nodi più vecchi, fino a quando non sono state aggiornate. A quel punto è stato eseguito un semplice failover: il nodo più vecchio è stato dismesso e quello più recente è diventato il master. in questo modo l'aggiornamento è stato eseguito in modo semplice, sicuro e con il basso tempo di inattività richiesto dal cliente.

L'attività è stata coordinata ed eseguita dal nostro DBA senior Lorenzo Farioli, supportato da me e dal nostro DBA junior Omar Locatelli. Per Omar si è trattato di una grande opportunità di crescita professionale, poiché era la prima volta che lavorava in un ambiente di produzione business-critical.

L'unica piccola difficoltà che abbiamo incontrato è stata con l'applicazione di backup Barman: ha smesso di funzionare durante gli aggiornamenti notturni, ma Lorenzo è stato in grado di risolvere il problema entro i termini dello SLA.

Il cliente è stato pienamente soddisfatto del nostro lavoro: quelle 35 istanze sono ora gestite dal nostro NGMS e questa attività ci ha permesso di cogliere nuove opportunità, come la gestione della sicurezza di Postgres e il rinnovo del contratto di assistenza NGMS.