Newsgroup: it.comp.os.linux.software
Titolo: Spostamento "live" DB PostgreSQL

Ciao a tutti,
devo migrare diversi siti da un server a un altro senza alcuna 
interruzione di servizi, soprattutto su un database postgres di utenti 
abbastanza importanti, che devono poter continuare a iscriversi e a 
modificare i propri dati anche durante la migrazione.
E purtroppo non di tutto ho il controllo del DNS.
La situazione: vecchio server Debian Lenny, con PostgreSQL 8.3.11 (server 
A), nuovo server Debian Squeeze, con PostgreSQL 8.4.4.
La mia idea era di:
- copiare i siti da A a B
- tirare su una replica (master-master?) di postgres su B che si 
sincronizza con A
- nel frattempo configurare i siti in B perche` accedano al DB in A (via 
Internet, con opportuno firewall sull'IP)
- cambiare i DNS, in modo che inizino a "lavorare" i siti in B al posto 
di quelli in A.
- quando la "migrazione dei DNS" e` completa e non ho piu` accessi ad A, 
cambiare i siti in B perche` accedano al DB locale
- disattivare la replica dei DB
Forse basta anche una master-slave, visto il contorno.
La domanda e`: dove posso trovare documentazione esaustiva e "for 
dummies", magari anche orientata a Debian, per farlo?
Mi preoccupa principalmente la differenza di versione di psql.
Grazie.
Bye.

 tutto ho il controllo del DNS.
Postgres non ha repliche multi-master (a meno di non pagare per altri 
prodotti simili e compatibili).
Switchare a tali prodotti però ti comporterebbe comunque un down.
Risposta sintetica: 
non puoi farlo.

 Switchare a tali prodotti però ti comporterebbe comunque un down.
E prevedendo un down di qualche minuto, massimo mezz'ora?
Posso avere un postgres slave che si sincronizza per (diciamo) 2-3 
settimane, e che poi "disconnetto" dal master per farlo diventare 
standalone?
A me interessa soprattutto evitare il tempo di down dovuto a fermatutto-
backup-trasferimento-restore-riaccenditutto e limitarlo al minimo.
Bye.

 backup-trasferimento-restore-riaccenditutto e limitarlo al minimo.
Fai il setup completo del/dei server su cui devi spostare la roba, fai un 
dump del database con pg_dump e testi tutto con un dump non aggiornato.
Poi, prima di spostare, spegni i servizi vecchi, pg_dumpall seguito da  
una reimportazione ed hai finito.
Tempi di down dipendenti da quanti dati devi spostare: partendo da 1 
minuto circa.

 standalone?
Premetto che non conosco postgres.
Sembrerebbe sensato, ma le applicazioni puntano a un nome logico, che 
switcherai contestualmente, quando lo farai diventare master?
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 una reimportazione ed hai finito.
Appunto quello che volevo evitare. :/
I dati sono parecchi. Un dump all, piu` il trasferimento e il restore 
potrebbero portarmi via tranquillamente 3-4 ore, che e` troppo.
Per quello cercavo un sistema di "sincronizzazione continua".
L'alternativa e` che mi metta a farlo alle 2 di mattina (il sito ha 
utenti quasi solo italiani), ma avrei preferito evitarlo.
Bye.

 switcherai contestualmente, quando lo farai diventare master?
No, puntano a un ip, che normalmente e` localhost, ma posso cambiarlo 
modificando solo un file .ini per ognuna. Meno di 5 minuti.
Bye.

 I dati sono parecchi. 
Quantifica.
Per metterci 3/4 ore deve trattarsi di almeno una 50 di giga di dump, su 
una macchina recente e mi pare alquanto strano.


beh, Ale non ha scritto da nessuna parte che lavora su una connessione 
gigabit. Può anche trattarsi di macchine su internet, dove una delle due 
ha una banda massima di 1Mb....


 ha una banda massima di 1Mb....
Esatto. Le due macchine sono in datacenter diversi. La banda massima e` 
intorno ai 4-5 Mbit.
I dati, in totale, sono circa 25 GB, anche se in realta` circa 20 di 
questi vengono aggiornati con uno script che posso disabilitare per 24-48 
ore, quindi da trasferire velocemente sarebbero circa 5 GB.
Ho intravisto slony che, a una prima occhiata, potrebbe fare quello che 
mi serve, ma devo studiarmelo un po' nei prossimi giorni.
Bye.

 mi serve, ma devo studiarmelo un po' nei prossimi giorni.
Ancora non ci sei arrivato eh...
1) slony non è postgres.
Devi usare un postgres patchato
2) slony è master-slave ma devi usare la stessa versione sua sul master 
che sullo slave, quindi niente upgrade all'8.4
3) non risolvi il problema del downtime.
4) piuttosto backportati postgres 9 che supporta nativamente il master-
slave ma, con connessioni come la tua, è comunque una cosa che 
personalmente eviterei.
La mia conclusione, poi non dirò più nulla:
evita questi accrocchi, fallo a mezzanotte e vivi contento.
Ci metti meno tempo e rischi di fare meno danni.

 mi serve, ma devo studiarmelo un po' nei prossimi giorni.
e allora Slony: non ci sono paragoni ^_^



minchia però.... a parte le vare tecniche di intervento relative a 
questo caso, questo mirabolante rdbms, alla resa dei conti, tanto 
mirabolante è.
L'invettiva che veniva reiterata in continuazione su mysql è che 
prendeva qualsiasi cosa nella tabelle, ignorando gli errori e non 
notificando ............... salvo alterare il parametro "SQL Mode" per 
modificare questo comportamento.
Certo che ne ho sentita di fuffa in questi ultimi mesi. Non da te, ma in 
generale nei gruppi.


 e allora Slony: non ci sono paragoni ^_^
Rieccolo.
- Premettendo che hai detto che non sai nulla di postgres
- Supponendo che tu non sappia nulla nemmeno di slony, altrimenti 
conosceresti postgres
- Analizzando la tua reputazione sul forum in fatto a competenze
Su che basi ti azzardi a dare un consiglio del genere ?

 meno danni.
Amen, mi sa che mi tocchera`. :(
Bye.

 generale nei gruppi.
Postgres è infinitamente migliore di mysql per tutto.
Non hai sentito fuffa da me perchè non c'erano discussioni serie su cui 
intervenire.
Personalmente, migliore di postgres ho trovato solo Oracle e le sue 
repliche (con postgres 9 la storia sarà diversa).
Non essendo una discussione seria su postgres, considerando oltretutto 
che l'interlocutore (tu) non ha alcun titolo per parlarne, visto che non 
lo conosce, evito di scrivere altra fuffa.


non dico una parola su postgres, visto che non lo conosco.
L'unica cosa che mi sono permesso di dire è quanto dedotto da quel che 
tu hai scritto:
- da un parte abbiamo un rdbms che fa replice master-master, repliche 
circolari e repliche master-slave.
- dall'altra parte abbiamo un rdbms che "dalla versione 9" fa repliche 
master slave.
Ne convieni che il fatto di dire
<Quote CtRiX>
Postgres è infinitamente migliore di mysql per tutto.
</Quote CtRiX>
inizia a ridimensionarsi un po'?
Comunque, ho solo detto che chi lamentava il problema degli inserimenti 
dove non viene fatto il check dei dati, come il peggiore dei problemi, 
evidentemente non consosce MySQL, non sa che è possibile modificare 
questo comportamente con un tuning molto fine, e non capisce che in un 
DB che viene usato per i CMS i dati vengono scritti da una applicazione 
che normalmente "sa quel che deve scrivere". (Ovviamente, se elimini il 
check guadagni in performance).



non è un problema quello di azzardarsi e sbagliare. Tanto non ho le mani 
"sul pezzo", non sto toccando nulla e quindi non rischio catastrofi. 
Rischio solo di scrivere una cosa che tu, giustissimamente, fai notare 
che è sbagliata.
Tu come ti azzardi a scrivere in una frase due cose in netto contrasto:
"è migliore su TUTTO.... non supporta repliche".


 "è migliore su TUTTO.... non supporta repliche".
Esperienza ?
(stiamo parlando di DB opensource, ovviamente)

 check guadagni in performance).
Fico.
Quindi tu sei esperto anche in database (non postgres) ed in CMS.
Prendo atto e continuo a ridere, però chiudo qui questa discussione con 
te che non ha senso.


Fico.
Hai scoperto la posizione lavorativa che ricopro attualemente:
MySQL DBA at Xxxxx (+ dell'altro).
CMS (con php, jboss e tomcat) sono "l'altro" di cui mi occupo. Però non 
sono uno specialista sui CMS.


 sono uno specialista sui CMS.
ROTFL!


"è migliore su TUTTO.... non supporta repliche".
scusami, ma il ROTFL è mio e me lo tengo io.


 mio e me lo tengo io.
Il mio rotfl non era riferito a mysql, ovviamente.


allora un pezzo di ROTFL te lo lascio.
Non sono in grado di operare confronti, causa la mia scarsa conoscenza 
della concorrenza.
Certo che però, se tu stesso mi esponi i limiti, io non poso fare a meno 
di notarli.
Inoltre, parte delle cose che sono state scritte nei gruppi su MySQL 
sono estrema fuffa e questo invece mi sento di poterlo dire.



vedi qual è il problema (tuo e di qualcun altro)?
Non c'è nessun motivo al mondo per rispondere così.
- Parti dal presupporto che pure tu sei niente mischiato con nessuno e 
butta fuori un po' di aria che a furia di gonfiarti come un pallone 
rischi solo di esplodere. Magari valessi un decimo degli sivluppatori di 
postgres o di mysql, allora potrei anche tollerare questi modi.
- E' ovvio che chi non conosce un prodotto in maniera dettagliata, gira, 
va a tentoni, cerca su internet, poi magari si accorge che la cosa non 
va bene. Ma è così che funziona.


 si accorge che la cosa non va bene. Ma è così che funziona.
No, il problema è che "quando si vede che esiste un prodotto che si 
chiama slony che fa al caso mio" ma non si legge cosa fa e come funziona 
e non si scopre che non va bene, pur avendo la pagina sotto gli occhi, 
bisogna pur ribadire quanto già espresso no ?
In quanto al mio valore, io non valgo nemmeno 1 centesimo degli 
sviluppatori di postgres, mysql, oracle e quello che preferisci.
Premesso questo, mi preoccuperei per quanto vali tu.
Il culo davanti alla pedata ce l'hai già messo decine di volte, cerca 
questa volta di non farlo.

 bisogna pur ribadire quanto già espresso no ?
scusami, ma guarda il contesto in cui si è sviluppata questa discussione.
Da un minuto all'altro si sono avvicendate le risposte.
E' evidente che lui ha scritto su Google "replica postgres" e ha trovato 
quel prodotto.
E' evidente che in un minuto non può aver letto la documentazione del 
prodotto.
E' normale che tu - che conosci il prodotto - gli fai notare il problema.
La prosopopea, invece, non ti incazzare, ma rompe le palle.


 bisogna pur ribadire quanto già espresso no ?
In realta` ho scritto "ho INTRAVISTO slony che FORSE POTREBBE FARE AL 
CASO MIO".
E il punto e` che ho scritto oggi ben conoscendo i tempi dei newsgroup. 
Mi aspettavo una discussione di 2-3 giorni, o di 2 settimane come quella 
sul RAID in .sys. :)
Non dovro` metterci le mani prima del 6-7 settembre, a questa migrazione, 
ma cercavo di arrivarci preparato, quindi ho chiesto per tempo dove 
andare a cercare informazioni (e se fosse possibile fare come avevo 
pensato).
Oggi (e ieri e domani) sono impegnato a programmare backend per due siti, 
quindi la pagina di slony l'ho aperta, letto gli slogan, bookmarkata e 
chiusa, ripromettendomi di guardarla giovedi` o venerdi` con piu` calma.
Grazie comunque per le informazioni. Daro` comunque un'occhiata a slony, 
ma almeno so cosa guardare.
Bye.

 [...]
Ciao   Manlio

 
Scusa, in questo messaggio stavi chiedendo un'altra cosa.
pgupgrade vale solo nel caso in cui tu voglia migrare una instanza di 
PostgreSQL sulla stessa macchina.
Il mio consiglio è, se puoi, aspettare PostgreSQL 9, aggiornare la tua 
instanza originale dalla 8.3.x alla 9, ed usare lo streaming replication:
http://wiki.postgresql.org/wiki/Streaming_Replication
per attivare una nuova instanza su un server diverso.
Ti consiglio anche di scrivere sulla mailing list postgresql-it.
Ciao  Manlio

 seriamente in ambiti di produzione con molto traffico e dati?
Guarda, ho visto ed ho lavorato sull'ultima versione presente in Lenny e 
posso tranquillamente affermare che si, PostgreSQL e` infinitamente 
migliore di MySQL :)
Enrico


ma forse qui si era messo in dubbio più che altro il "su tutto", anche 
perché su alcune cose in particolare non si può nemmeno iniziare la 
discussione. Cioè, come fai a stabilire su quale dei due funziona meglio 
la replica master? :)
Quanto a stabilire qual è migliore, fa tanto da discussione da osteria, 
e non si capisce nemmeno perché Facebook avrebbe deciso di usare un dbms 
peggiore *su tutto*, ma proprio *su tutto*.
Perché non usarne uno migliore *su tutto*?
Last: ultimamente mysql, oltre a essere sviluppato dal team di oracle, è 
patchato anche da facebook, e le patch di facebook sono di dominio 
pubblico e vanno a finire tutte nel mainstream.
very-last: con MySQL 6.0 e con i nuovi storage engines, il *su tutto* si 
trasformerà in *su niente*, ma proprio niente :-)


 A), nuovo server Debian Squeeze, con PostgreSQL 8.4.4.
Hai già provato a chiedere sulla ML di postgresql ?
postgr...@lists.psql.it
ciao
Mauro

 cosa vuol dire "infinitamente migliore per tutto")
L'ultima è la 5.1.qualcosa.
mi rimane solo un grosso sito, con grosso traffico e dati piuttosto 
complessi che si basa (per ragioni storiche) su mysql, sviluppato quando 
mysql faceva il suo dovere (3.23.XX) e postgres era alla 6.0 (leggasi, 
infinitamente più lento di mysql).
"Infinitamente meglio in tutto" è un discorso che comincia quando avvio 
il database e finisce quando lo devo riavviare perchè crasha o ha 
problemi seri.
Con postgres non mi è mai successo, con mysql succede regolarmente sotto 
carico. Purtroppo su quel sito ci devo convivere perchè convertire 1.2M 
linee di codice e di scripts vari di backend sarebbe un costo 
mostruosamente elevato per il cliente.
"infinitamente meglio" è un discorso che coinvolge anche lo sviluppo che, 
dopo il passaggio a Sun e poi Oracle e alcuni Fork (i.e. Maria), mi 
lascia con qualche perplessità che non vorrei avere (basta il kernel di 
linux a "perplimermi").
Il tutto senza scendere nel tecnico sulle funzionalità o altre cose, ma 
meglio non approfondire.
Max


Approfondisci che mi interessa..
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 pensi.
Per carità, lungi da me dal dire che mysql non deve essere usato.
Sto solo affermando che postgres è meglio e, soprattutto è più affidabile.
Ha senso migrare su postgres per una tonnellata di motivi che per quanto 
mi riguarda avevano a che fare con:
- affidabilità
- performance
- integrità referenziale vera e non fittizia
- possibilità di utilizzare funzionalità che per certe applicazioni mysql 
non può supportare.
Ovvio che per wordpress o joomla non ha senso alcuna migrazione, anche 
sqlite andrebbe bene.
Quell'unico progetto che mi rimane su mysql avrebbe molto senso migrarlo 
su postgres. Ho già fatto alcuni test e il sistema sarebbe più 
performante. Non ha senso solo per motivi economici che, effettivamente, 
talvolta sono più importanti dei motivi tecnici.
Allo stato attuale, però, per me non esiste alcun buon motivo per 
cominciare nessun nuovo progetto utilizzando mysql piuttosto che postgres.
Max

 Approfondisci che mi interessa..
Roberto, famo sta cena di Fiorentini che parliamo di questo ed altro :-D
Max

 e relativi reply) come lo usa (storage di 
dati statici)

 dati statici)
Non mi è stato spiegato niente. Il fatto che ci siano pure cassandra e 
memcached non è un segreto e lo sappiamo tutti.
E io non ho mai detto che, visto che lo usa Facebook, allora è 
certamente figo. Sarebbe sciocco. La questione va intesa in maniera 
leggermente diversa: se è questa merdaccia, come dicono i detrattori, 
perché viene usato in un progetto di così ampie dimensioni? Possibile 
che tutto lo scibile sia in questi forum e che nessuno degli ingegneri 
che hanno progettato Facebook conoscesse Postgres?
Oppure, perché non hanno usato postgres, se come dici tu è addirittura 
più veloce?
Fatti venire questo dubbi almeno. E per finire, al contrario vostro ("su 
tutto") io non la metto sul piano del "c'è la più lungo". Dico che è di 
gran lunga meno pessimo di come voi provate a dipingerlo.
Ad oggi mi risulta che postgres scali meglio in maniera verticale, ma 
quando il progetto è troppo grande finisci sempre per dover scalare 
orizzontalmente.
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di 
discussione"

 voglia di cercare)?
Cosa cazzo è plony ?


il fratello di slony :-)


 Cosa cazzo è plony ?
http://en.wikipedia.org/wiki/Plony
 :)
Enrico



ROTFL

 che hanno progettato Facebook conoscesse Postgres?
Il problema non e` dove arrivi, ma come parti. Come e` gia` stato detto, 
molte volte passare da una tecnologia ad un'altra richiede costi non 
indifferenti, tanto che spesso conviene superare le limitazioni per mezzo di 
altre vie. Ed e` quello che ha fatto Facebook (o Google) scrivendo patch 
apposite per MySQL, in modo da evitare i problemi che esso riportava nel 
normale utilizzo. E, se vogliamo allargare il discorso, si puo` dire che 
Facebook ha adottato la stessa tecnica per PHP creando HipHop for PHP
Enrico
P.S. vorrei ricordarti che Facebook e` nato piu` per gioco che per reale 
necessita`, di conseguenza dubito che ci sia stata una iniziale 
progettazione (ovvero, php e mysql sono stati scelti come al solito per la 
loro popolarita` e non per le loro caratteristiche tecniche, mentre gli 
altri pezzi sono stati aggiunti in corsa)


infatti, mi riferico al fratello polacco :)


 progettazione
Questa č una ipotesi.
Cioč, l'ipotesi č che sia stato messo in piedi da gente che non 
frequentava I.C.O.L. dove si decantano lodi solo su postgres :)
-- 
Wikipedia Admin: "wikipedia non č un blog"


 frequentava I.C.O.L. dove si decantano lodi solo su postgres :)
Si dovrebbe smettere di usare la giustificazione "Facebook usa mysql" 
perchè lascia il tempo che trova.
Personalmente non ho mai sentito dire o letto in giro "skype usa postgres 
e ha rilasciato pure lei della patch per farlo scalare meglio", pure se è 
vero.
Sarà una questione di maturità ?

 Sarà una questione di maturità ?
eh te pareva: i DBA posgres mo' sono pure più maturi di quelli MySQL :)
-- 
Wikipedia Admin: "wikipedia non è un blog"
