Semplificare la gestione di un database PostgreSQL di produzione

Gli ultimi anni hanno visto una crescente adozione di PostgreSQL. PostgreSQL è un fantastico database relazionale. Dal punto di vista delle funzionalità, è lassù con i migliori, se non i migliori. Ci sono molte cose che mi piacciono:PL/PG SQL, impostazioni predefinite intelligenti, replica (che funziona davvero fuori dagli schemi) e una comunità open source attiva e vivace. Tuttavia, oltre alle sole funzionalità, ci sono altri aspetti importanti di un database che devono essere considerati. Se hai intenzione di creare un'operazione di grandi dimensioni 24 ore su 24, 7 giorni su 7, la possibilità di utilizzare facilmente il database una volta che è in produzione diventa un fattore molto importante. Sotto questo aspetto, PostgreSQL non regge molto bene. In questo post del blog, descriveremo in dettaglio alcune di queste sfide operative con PostgreSQL. Non c'è nulla di fondamentalmente irrisolvibile qui, solo una questione di priorità. Speriamo di poter generare abbastanza interesse nella comunità open source per dare la priorità a queste funzionalità.

1. Nessun rilevamento automatico del driver client del failover principale

Il driver del client PostgreSQL non rileva automaticamente quando si è verificato un failover principale (ed è stato eletto un nuovo master). Per ovviare a questo problema, gli amministratori devono distribuire un livello proxy sul lato server. Le scelte popolari sono mappatura DNS, mappatura IP virtuale, PgPool e HAProxy. Tutte queste opzioni possono essere fatte funzionare bene, ma è necessario un notevole impegno aggiuntivo per l'apprendimento e l'amministratore. Nel caso in cui un proxy venga introdotto nel percorso dei dati, c'è anche un notevole impatto sulle prestazioni. Questa è una funzionalità standard incorporata in molti dei nuovi database NoSQL e PostgreSQL farebbe benissimo a dare un'occhiata ai loro libri quando si tratta di operazioni.

2. Nessun failover automatico integrato tra master e standby

Quando un master PostgreSQL si guasta, uno dei server di standby deve essere scelto come master. Questo meccanismo non è integrato in PostgreSQL. In genere, per gestire questo scenario vengono utilizzati strumenti software di terze parti come Patroni, Pacemaker e così via. Perché non averlo integrato nel server? Questi strumenti di terze parti sembrano ingannevolmente semplici, ma richiedono un notevole sforzo, conoscenza e test da parte dell'amministratore per ottenere questo risultato. Incorporando questo nel database, stai facendo un enorme favore al tuo amministratore del database.

3. Nessun aggiornamento importante per tempi di inattività zero

Non è possibile aggiornare il database PostgreSQL da una versione principale a un'altra senza tempi di inattività. Devi essenzialmente spegnere tutti i tuoi server e usare pg_upgrade per aggiornare i tuoi dati alla versione più recente. Il tempo di inattività non è elevato poiché non è coinvolta la copia dei dati, tuttavia, c'è ancora un tempo di inattività. Se stai eseguendo un'operazione 24 ore su 24, 7 giorni su 7, questa potrebbe non essere un'opzione per te.

Con il rilascio della replica logica, abbiamo un'opzione alternativa per l'aggiornamento online.

1. Crea una nuova configurazione PostgreSQL Master-Standby con la nuova versione.
2. Imposta la replica logica per replicare dalla versione precedente alla versione più recente.
3. Quando sei pronto, cambia la stringa di connessione in modo che punti dalla configurazione precedente alla nuova configurazione.

Ancora una volta, questo può essere fatto funzionare, ma il sovraccarico è enorme. Idealmente, ciò che è necessario qui è un modo per eseguire l'aggiornamento sul posto in modo continuo su una configurazione standby principale. L'aggiornamento di MySQL ti consente di aggiornare i tuoi slave sul posto alla nuova versione e quindi di attivare un failover.

4. Nessun vuoto sul posto PIENO

Autovacuum/VACUUM è molto utile e aiuta a risolvere questo problema in una certa misura. Dovresti esaminare regolarmente il rigonfiamento sui tuoi tavoli per assicurarti che le tue impostazioni di autovuoto siano appropriate e funzionino bene per il tuo tavolo. Tuttavia, l'autovacuum non va fino in fondo:in realtà non finisce per unire ed eliminare le pagine. Se disponi di un numero elevato di aggiornamenti, inserisci ed elimina carichi di lavoro, le tue pagine finiranno per frammentarsi, compromettendo le tue prestazioni. L'unico modo per aggirare questo problema è eseguire VACUUM FULL che sostanzialmente ricostruirà tutte le pagine per eliminare la frammentazione. Tuttavia, questo processo può essere eseguito solo con i tempi di inattività:il tuo tavolo è fermo per la durata del VACUUM FULL. Per set di dati di grandi dimensioni, l'operazione può richiedere diverse ore e non è un'alternativa pratica se si desidera eseguire un'operazione 24 ore su 24, 7 giorni su 7.

Nota:la community ha già iniziato a lavorare sul motore di archiviazione zheap che supera questa limitazione.

Se ci sono altri miglioramenti che ritieni possano essere utili, sentiti libero di lasciare un commento.