La scorsa settimana, sono stato al Nordic PGDay 2018 e ho avuto alcune conversazioni sullo strumento che ho scritto, ovvero pglupgrade , per automatizzare gli aggiornamenti della versione principale di PostgreSQL in una configurazione del cluster di replica. Sono stato abbastanza felice che sia stato ascoltato e alcune altre persone in diverse comunità hanno tenuto discorsi a meetup e altre conferenze su aggiornamenti con tempi di inattività prossimi allo zero utilizzando la replica logica. Dato che c'è un discorso che ho tenuto al PGDAY'17 Russia, PGConf.EU 2017 a Varsavia e infine al FOSDEM PGDay 2018 a Bruxelles, ho pensato che fosse meglio creare un post sul blog per mantenere questa presentazione a disposizione delle persone che potrebbero non partecipare a nessuna delle conferenze di cui sopra. Se vuoi parlare direttamente e saltare la lettura di questo post del blog, ecco il tuo link:Aggiornamenti automatizzati con tempi di inattività vicini allo zero dei cluster PostgreSQL nel cloud
La motivazione principale alla base dello sviluppo di questo strumento è stata quella di proporre una soluzione per ridurre al minimo i tempi di inattività durante i principali aggiornamenti di versione che sfortunatamente colpiscono quasi tutti coloro che utilizzano PostgreSQL. Al momento, non disponiamo di uno strumento che consenta agli utenti di PostgreSQL di aggiornare i propri database senza tempi di inattività ed è chiaramente un punto dolente per molti utenti, in particolare le aziende. E, se vogliamo risolvere il problema dell'aggiornamento, dovremmo pensare a più di un server (da ora in poi verrà indicato come un cluster), semplicemente perché non molte persone usano più un solo server di database. Lo scenario più comune prevede la configurazione della replica dello streaming fisico per scopi di alta disponibilità o per il ridimensionamento delle query di lettura.
Aggiornamenti del database
Prima di immergerci nella soluzione, discutiamo un po' su come funzionano gli aggiornamenti del database in generale. Esistono quattro possibili approcci principali agli aggiornamenti del database:
- Il primo approccio sarebbe che i database mantengano il loro formato di archiviazione uguale o almeno compatibile tra le versioni. Tuttavia, questo è difficile da garantire a lungo termine poiché le nuove funzionalità potrebbero richiedere modifiche al modo in cui i dati vengono archiviati o aggiungere più informazioni sui metadati per funzionare correttamente. Inoltre, le prestazioni vengono spesso migliorate ottimizzando le strutture dei dati.
- Il secondo approccio consiste nel fare una copia logica (dump) del vecchio server e caricarlo nel nuovo server. Questo è l'approccio più tradizionale che richiede al vecchio server di non ricevere alcun aggiornamento durante il processo e si traduce in tempi di inattività prolungati di ore o addirittura giorni su database di grandi dimensioni.
- La terza opzione è convertire i dati dal vecchio formato al nuovo. Questa operazione può essere eseguita al volo mentre il nuovo sistema è in esecuzione, ma comporta una riduzione delle prestazioni che è difficile da prevedere poiché dipende dai modelli di accesso ai dati, oppure può essere eseguita offline mentre i server sono inattivi, causando ancora una volta prolungamento tempi di fermo (sebbene spesso più breve del secondo metodo).
- Il quarto metodo consiste nell'utilizzare il dump logico per salvare e ripristinare il database durante l'acquisizione delle modifiche che si verificano nel frattempo e replicandoli logicamente nel nuovo database una volta terminato il ripristino iniziale. Questo metodo richiede l'orchestrazione di diversi componenti ma riduce anche la quantità di tempo in cui il database non può rispondere alle query.
Aggiorna i metodi in PostgreSQL
Gli aggiornamenti di PostgreSQL possono essere abbinati ai quattro metodi sopra elencati. Ad esempio, le versioni secondarie di PostgreSQL, che non contengono nuove funzionalità ma solo correzioni, non modificano il formato dei dati esistente e si adattano al primo approccio. Per il secondo approccio, PostgreSQL fornisce strumenti chiamati pg_dump e pg_restore che eseguono il backup logico e il ripristino. C'è anche lo strumento pg_upgrade (era un modulo contrib e spostato nell'albero principale in PostgreSQL 9.5) che esegue la conversione offline (i server non sono in esecuzione) dalla vecchia directory dei dati a quella nuova, che può adattarsi alla terza opzione. Per il quarto approccio, esistono soluzioni basate su trigger di terze parti come Slony per l'aggiornamento, ma presentano alcuni avvertimenti che tratteremo in seguito.
I metodi tradizionali di aggiornamento possono solo aggiornare il server primario mentre i server di replica devono essere ricostruiti dopo (conversione offline) . Ciò comporta ulteriori problemi sia con la disponibilità che con la capacità del cluster, aumentando così di fatto il tempo di inattività percepito del database sia dal punto di vista delle applicazioni che degli utenti. La replica logica consente la replica mentre il sistema è attivo e funzionante e lo sforzo di test può essere gestito nel frattempo (conversione online) .
Esistono diversi metodi di aggiornamento applicabili per diversi ambienti. Ad esempio, pg_dump consente l'aggiornamento da versioni molto precedenti (ad esempio 7.0) alle versioni recenti, quindi se stai eseguendo una versione antica di PostgreSQL, il metodo migliore è usare pg_dump/restore (e meglio farlo ora!). Se la tua versione di PostgreSQL è 8.4 e successive puoi usare pg_upgrade . Se utilizzi PostgreSQL 9.4 e versioni successive questo significa che hai una "Decodifica logica" in-core e puoi usare il pglogical estensione come mezzo di aggiornamento. Infine, se stai usando PostgreSQL 10 , avrai la possibilità di aggiornare il tuo database a PostgreSQL 11 e versioni successive (una volta disponibili) utilizzando la "Replica logica" interna (sì!).
Replica logica per gli aggiornamenti
Dov'è l'idea di aggiornare PostgreSQL utilizzando la replica logica proveniente da?Chiaramente, pglogical non rivendica apertamente lo scopo dell'aggiornamento come pg_upgrade fa (questo era un argomento contro pglogical alla festa della conferenza ), ma questo non significa che non possiamo utilizzare lo strumento per gli aggiornamenti. Infatti, quando è stato progettato pglogical, gli aggiornamenti con tempi di inattività prossimi allo zero sono stati considerati uno dei casi d'uso previsti dagli sviluppatori dell'estensione.
A differenza della replica fisica, che acquisisce le modifiche ai dati grezzi su disco, la replica logica acquisisce le modifiche logiche ai singoli record nel database e le replica. I record logici funzionano in tutte le versioni principali , quindi la replica logica può essere utilizzata per l'aggiornamento da un rilascio all'altro. L'idea di utilizzare la replica logica come mezzo di aggiornamento della versione è tutt'altro che nuova, gli strumenti di replica basati su trigger hanno eseguito gli aggiornamenti in modo logico catturando e inviando le modifiche tramite trigger (perché i trigger possono funzionare anche indipendentemente dalle versioni del database! ).
Se puoi utilizzare soluzioni di replica basate su trigger per aggiornamenti minimi dei tempi di inattività, perché dovresti preferire invece la replica logica? In un meccanismo basato su trigger, tutte le modifiche vengono acquisite utilizzando i trigger e scritte nelle tabelle di coda. Questa procedura raddoppia le operazioni di scrittura, raddoppia i file di registro e rallenta il sistema poiché tutte le modifiche devono essere scritte due volte; con conseguente maggiore I/O del disco e carico sul server di origine. Al contrario, la replica logica interna (lo stesso vale per l'estensione pglogica) si basa sulla decodifica logica. La decodifica logica è un meccanismo che estrae le informazioni dai file WAL in modifiche logiche (INSERT/UPDATE/DELETE). Poiché i dati del meccanismo WAL vengono utilizzati per la decodifica dei registri delle transazioni, non vi è nessuna amplificazione in scrittura come nel caso delle soluzioni di replica basate su trigger, quindi questo metodo funziona meglio . Di conseguenza, le soluzioni basate sulla decodifica logica hanno semplicemente un impatto minore sul sistema rispetto alle soluzioni basate su trigger.
Conclusione
In questo post introduttivo, volevo dare un'idea del motivo per cui dovremmo considerare l'utilizzo della replica logica per ottenere tempi di inattività minimi durante gli aggiornamenti delle versioni principali. Continueremo con i dettagli dell'architettura e dell'implementazione dello strumento nel prossimo post.
