[MontelLUG] Lamentazioni su cluster Postgresql

[Denis Gasparin]

Ciao!

@Samuele: sempre in ascolto... anche se partecipo pochissimo alla lista 😇

Dal punto di vista della replica, ma anche di altre funzionalità
"sistemistiche" (backup ad esempio), PostgreSQL ha da sempre messo a
disposizione gli strumenti di base (nella caso della replica WAL, comandi
di archiviazione, etc) lasciando la libertà a chi inserisce PostgreSQL
nella propria infrastruttura di gestire la cosa in autonomia oppure
rivolgendosi a prodotti commerciali sviluppati on top.
Questo ha consentito a moltissime aziende o di sviluppare dei prodotti
opensource (vedi Patroni o repmgr, barman per il backup) su cui poi fornire
supporto oppure di creare delle vere e proprie versioni del database con
caratteristiche simili a quelle che citavi per Oracle/SQL Server (vedi ad
esempio EnterpriseDB).

Denis


Il giorno sab 25 mar 2023 alle ore 23:43 Samuele via montellug <
montellug a montellug.it> ha scritto:

> Visto che si parla di riattivare questa lista, resoconto un po' di
> impressioni che ho avuto sta settimana.
> Se qualcuno ha voglia di interagine nella discussione ben venga.
> Nonostante abbia scritto "lamentazioni" lo stile della mail non sarà
> quello di Asbesto (anche se l'esperienza potrebbe sembrare uscita da uno
> dei suoi racconti).
> Non so se ci sia ancora Denis in ascolto su questa ml ed ha delle
> soluzioni per i miei mal di pancia.
>
> Premetto che in passato ho utilizzato Postgresql in passato in modo
> abbastanza semplice, mai in configurazioni in cui gli si tirava il
> collo. Diversamente la mia esperienza è stata quasi esclusivamente con
> SQL Server.
>
> Mi è stato chiesto di tirar su un cluster di database. Inizialmente in
> modalità master-master, salvo poi convincere il richiedente che non era
> il caso. L'unico motore di database in grado di fare questo in modo
> serio a quanto ne so dovrebbe essere Oracle, ma non l'ho sperimentato.
> Quindi configurazone master-slave. Ho scelto Postgresql perché in ambito
> open, è l'unica scelta sensata.
>
> Vado a vedermi la documentazione su come si mette in piedi il tutto e...
> tante belle parole... sembra fare quello che mi serve... gestisce il
> travaso in tempo reale del transaction log dal nodo master allo slave...
> cerco esempi di configurazione... ma... manca tutta la parte di gestione
> del cluster automatizzata.
> Cioè bisogna delegarla a strumenti esterni. Ma perché?!? SQL Server
> gestisce in modo pulito tutto da solo. Si integra nativamente con WFC.
> Non bisogna inventarsi script alla buona.
> Nel caso di Postgresql, c'è Percona, repmgr, svariati progetti su github
> che sai quando sono nati, ma non sai se e per quanto verranno mantenuti
> E SE funzionano realmente o solo nella testa dello sviluppatore (o come
> amava dire il Potta: notabug funziona sul mio computer).
> Come ca$$o faccio a proporre una soluzione ufficiale e supportata?
> (leggesi, se il cluster va in malora e qualcuno si mette alla ricerca di
> qualcun altro da mettere a pecorella, poter dimostrare di aver fatto
> tutto a regola d'arte e non fare la fine della pecorella).
> Scelgo repmgr che mi sembra il più semplice e minimale (meno roba
> superflua c'è, meno probabilità c'è che qualcosa si rompa). Anche perché
> con Percona ho sentito svariata gente Porconare in passato.
> Tiro su il cluster, la documentazione in qualche punto è un po' vaga, ma
> parte. Poi provo a fare lo spostamento del master da un nodo all'altro
> e... va in errore... e non è che faccia il rollback in automatico
> ritornando ad una situazione consistente... no, i due nodi restano
> inebetiti. E tra una boia ed un comando, un comando ed una boia, ci
> scappa la risincronizzare di brutto della replica pur di venirne fuori.
> Dopo alcune ore di rumamento di forum, trovo che un tizio ha risolto
> settando un parametro. Che nel frattempo ha cambiato nome ed unità di
> misura. Con quello risolvo. Nel frattempo ho testato varie condizioni di
> incongruenza tra i nodi del cluster.
> E poi devi configurare a mano sudo, e se ci hai RedHat in un modo, se
> chi hai Ubuntu in un altro, se hai systemdmerda tra i coglioni in un
> altro... e poi aggiungere il PATH per pg_rewind... ecc. ecc.
> E comunque l'impressione è di una teiera di porcellana in una savana di
> elefanti.
> Poi la gestione dell'ip flottante è affidata a keepalived. Ok,
> l'equivalente di WFC nel caso di SQL Server. Ma... uno pensa che
> keepalived e Postgresql comunichino in modo nativo ed efficiente, magari
> usando un qualche plugin di Postgresql per keepalived. No. Keepalived,
> ogni 2 secondi (o a seconda del tempo che impostate) fa un fork di una
> shell che lancia uno script bash il quale forka prima psql, il quale
> apre una nuova connessione verso il db (cosa computazionalmente
> onerosa), esegue una query il cui risultato viene sparato in output e
> parsato da un grep anch'esso forkato dalla precedente shell. Poi
> keepalived guarda se tutto sto circo acrobatico ha generato come
> risposta uno zero od un uno. Casso che efficiensa. Quasi quasi scrivo a
> Greta lamentando lo spreco di energia per tutta sta roba.
> Dico, fare in modo che Postgresql comunichi tramite socket con
> keepalived no?
>
> Boh, alla fine in una giornata ho tirato su tutta la baracca, ma resta
> sempre l'impressione che sia tutto in equilibrio precario. Anche perché
> potrebbero aggiornare Postgresql e rompere la compatibilità con repmgr,
> oppure cambiare l'outupt della query eseguita da keepalive.
>
> Ora corro a dormire che sta notte riattivano la fottuta ora legale.
>
> --
> Il messaggio e' stato analizzato alla ricerca di virus o
> contenuti pericolosi da MailScanner, ed e'
> risultato non infetto.
>
> _______________________________________________
> montellug mailing list
> montellug a montellug.it
> https://mail.montellug.it/mailman/listinfo/montellug
>

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://mail.montellug.it/pipermail/montellug/attachments/20230327/3de03be1/attachment.htm>