[MontelLUG] Lamentazioni su cluster Postgresql

[Samuele]

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.