Re: clonazione a caldo [clonazione db]
Il giorno ven 1 mag 2020 alle ore 22:08 Piviul ha scritto: > > Il 01/05/20 16:04, Mauro ha scritto > > credo che questo giochino ti esponga a rischi di corruzione terribili. I > > motori di db, tutti, tengono in memoria quanta piu' roba possibile, > > soprattutto indici e riferimenti aggiornandoli continuamente rispetto a > > quanto sta su disco. Anche se utilizzi il sync prima di rsync i dati non > > sono effettivamente staticizzati, perche' diverse cose possono benissimo > > essere ancora in memoria (commit non eseguiti, attivita' sugli indici e > > tanta altra roba). Se non fermi il db, rischi comunque di trasferire un > > database corretto per carita', ma incompleto rispetto alle ultime > > operazioni effettuato dal motore stesso. > > > > Diciamo che ti potrebbe andare bene 9 volte, alla decima, il giorno > > della sfiga, ti ritrovi con una copia corrotta. > ma il mio problema come dicevo non è la clonazione a caldo del db, bene > o male funziona e i tempi sono molto rapidi (magari faccio prima una > clonazione a caldo del db poi un'altra clonazione a freddo); insomma non > capisco perché se clono /etc/postgresql e /var/lib/postgresql (a > servizio attivo o meno poco importa) tutto funziona ma se copio anche le > altre dir escludendo l'elenco che ho fatto precedentemente il db non > funziona più anche se ri-clono successivamente /etc/postgresql e > /var/lib/postgresql e non capisco proprio il perché. Se qualcuno potesse > illuminarmi... se non vuoi fermare il DB, durante la clonazione (e comunque, nel caso tu voglia clonare l'intero sistema on the fly), devi avviare uno snapshot del sistema, a questo punto puoi clonare buona parte delle informazioni di sistema, senza che queste vengano corrotte da scritture, mentre fai la copia, e se fai la copia di tutto o quasi il sistema, non c'è solo il DB che potrebbe essere modificato e quindi generare un file corrotto. naturalmente vuol dire che le due macchine non saranno mai perfettamente uguali (lo sono a meno delle differenze che poi vengono registrate alla chiusura dello snapshot), ma saranno sicuramente uguali e stabili fino all'attivazione dello snapshot. mi rimane il dubbio sulla macchina ricevente, presumo che questa macchina in qualche modo non sia effettivamente attiva, altrimenti la sincronizzazione tra due DB che sono contemporanemante attivi, devono seguire altre vie, perché uno corromperebbe i dati dall'altro sistematicamente. se fai una procedura di attivazione/copia/disattivazione degli snapshot automatizzata, con tempi prestabiliti (per esempio ogni tot ore), puoi essere sicuro che la differenza tra le due macchine è sempre di almeno tot ore... Byez -- Gollum1 - http://www.gollumone.it Tesoro, dov'é il mio teoro...
Re: clonazione a caldo [clonazione db]
On 01/05/20 22:07, Piviul wrote: non capisco perché se clono /etc/postgresql e /var/lib/postgresql (a servizio attivo o meno poco importa) tutto funziona ma se copio anche le altre dir escludendo l'elenco che ho fatto precedentemente il db non funziona più anche se ri-clono successivamente /etc/postgresql e /var/lib/postgresql e non capisco proprio il perché potrebbe essere una questione di tempi: se copi tutto deve copiare più dati e tra quando inizia a copiare i dati di postgres e quando finisce passa più tempo. Di sicuro, più tempo passa e maggiori sono le probabilità di avere un database corrotto. Comunque io ti consiglio di leggerti la documentazione che ti ho segnalato e capire da quella come puoi fare quello che vuoi senza rischiare... Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Motivi per non comprare/usare ms-windows-vista: http://badvista.fsf.org/ Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: clonazione a caldo [clonazione db]
Il 01/05/20 16:04, Mauro ha scritto credo che questo giochino ti esponga a rischi di corruzione terribili. I motori di db, tutti, tengono in memoria quanta piu' roba possibile, soprattutto indici e riferimenti aggiornandoli continuamente rispetto a quanto sta su disco. Anche se utilizzi il sync prima di rsync i dati non sono effettivamente staticizzati, perche' diverse cose possono benissimo essere ancora in memoria (commit non eseguiti, attivita' sugli indici e tanta altra roba). Se non fermi il db, rischi comunque di trasferire un database corretto per carita', ma incompleto rispetto alle ultime operazioni effettuato dal motore stesso. Diciamo che ti potrebbe andare bene 9 volte, alla decima, il giorno della sfiga, ti ritrovi con una copia corrotta. ma il mio problema come dicevo non è la clonazione a caldo del db, bene o male funziona e i tempi sono molto rapidi (magari faccio prima una clonazione a caldo del db poi un'altra clonazione a freddo); insomma non capisco perché se clono /etc/postgresql e /var/lib/postgresql (a servizio attivo o meno poco importa) tutto funziona ma se copio anche le altre dir escludendo l'elenco che ho fatto precedentemente il db non funziona più anche se ri-clono successivamente /etc/postgresql e /var/lib/postgresql e non capisco proprio il perché. Se qualcuno potesse illuminarmi... Piviul
Re: clonazione a caldo [clonazione db]
Il 01/05/2020 09:01, Piviul ha scritto: > Ho provato prima a copiare solo i db con rsync, a caldo, senza nemmeno > stoppare come dicevo il db sorgente e tutto funziona. credo che questo giochino ti esponga a rischi di corruzione terribili. I motori di db, tutti, tengono in memoria quanta piu' roba possibile, soprattutto indici e riferimenti aggiornandoli continuamente rispetto a quanto sta su disco. Anche se utilizzi il sync prima di rsync i dati non sono effettivamente staticizzati, perche' diverse cose possono benissimo essere ancora in memoria (commit non eseguiti, attivita' sugli indici e tanta altra roba). Se non fermi il db, rischi comunque di trasferire un database corretto per carita', ma incompleto rispetto alle ultime operazioni effettuato dal motore stesso. Diciamo che ti potrebbe andare bene 9 volte, alla decima, il giorno della sfiga, ti ritrovi con una copia corrotta.
Re: clonazione a caldo [clonazione db]
On 01/05/20 09:01, Piviul wrote: Anzitutto dalle prove da me fatte sia per postgres che per mysql non è necessario stoppare il db da clonare prima di un rsync. in generale un database può essere copiato o fatto il backup "a caldo", ma occorre, di solito, eseguire altre operazioni per evitare di avere una copia corrotta. Se fai solo la copia fisica, secondo me, o sei molto fortunato o hai una copia corrotta. Non sono un esperto, ma facendo una ricerca rapida ho trovato questo: https://www.postgresql.org/docs/12/continuous-archiving.html e questa risposta: The best approach avoiding any downtime is to: rsync the file system(s) containing the database directory and transaction logs (pg_xlog) to the clone location, call pg_start_backup(), rsync the file system(s) containing the database directory and transaction logs (pg_xlog) to the clone location again — this should take a much shorter period of time than the first rsync, and finally call pg_stop_backup(). Now if you start up PostgreSQL on the clone, it will automatically recover the cloned database and transaction log and start accepting queries. I am not aware of a way to manually apply the transaction log. che trovi qui: https://stackoverflow.com/questions/24784042/cloning-postgresql-8-3-7 In ogni caso ti conviene leggere un po' di documentazione del database specifico per vedere le soluzioni che ti offre per quello che vuoi fare. Io partirei da qui: https://www.postgresql.org/docs/12/high-availability.html https://www.postgresql.org/docs/12/logical-replication.html per postgresql, e poi cercherei qualcosa di simile sulla documentazione di mysql (poi io ti consiglierei di usare mariadb, visto che Oracle sta trasformando mysql in un qualcosa che diverrà sempre più proprietaria... guarda cosa sta facendo con Java, infatti moltissimi stanno abbandonando Java). Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Sistema operativo: http://www.debian.org GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
clonazione a caldo [clonazione db]
Ciao a tutti, riprendo questo thread ma con un focus leggermente diverso, nel senso che come dicevo vorrei copiare tutta la macchina e non solo il db. Anzitutto dalle prove da me fatte sia per postgres che per mysql non è necessario stoppare il db da clonare prima di un rsync. Per postgres basta copiare /etc/postgresql e /var/lib/postgresql mentre per mysql /etc/mysql/ e /var/lib/mysql. Partendo da 2 pc con la stessa versione di debian e gli stessi pacchetti installati, io vorrei vedere se è possibile copiare a caldo un pc sull'altro, non proprio un clone nel senso che vorrei che poi potessero convivere nella stessa network dopo la copia. Lo strumento che vorrei utilizzare è rsync. Ho provato prima a copiare solo i db con rsync, a caldo, senza nemmeno stoppare come dicevo il db sorgente e tutto funziona. Poi ho preparato una lista delle directory che non devono essere clonate perché altrimenti poi i pc se si chiamano tutte e due allo stesso modo o hanno lo stesso ip non possono convivere nella stessa rete così escludo /etc/hostname, /etc/hosts, /etc/network/ e /etc/mailname; poi i 2 pc potrebbero avere una configurazione hardware differente lato storage quindi escludo /etc/fstab, /etc/blk.id... in summa per farla breve questo è il contenuto del file exclude da dare in pasto a rsync: etc/blkid.tab etc/cron.*/ etc/crontab etc/email-addresses etc/exim4/update-exim4.conf.conf etc/fstab etc/hostname etc/hosts etc/lvm/ etc/mailname etc/network/ etc/ssh/ etc/ssl/ home root/ tmp/ var/log/ var/run/ Ora se eseguo: # rsync -avx --exclude-from rsync_clone_exclude.list root@$src_hostname:/ / Sembra vada tutto bene ma poi i db non partono più. Posso ora clonare quanto voglio /etc/postgresql e /var/lib/postgresql o le dir relative di mysql ma i db non partono più. Evidentemente bisogna escludere qualche altra dir... Voi avete idea di possano essere? Grazie Piviul
Re: clonazione db
On 27/04/20 19:12, Piviul wrote: script che faceva tutto (stoppava in entrambi i server postgres, faceva l'rsync e poi riavviava postgres) e mentre postgres si avviava correttamente nel server remoto di origine poi falliva nel server clonato. Dopo però una breve attesa se si avvia nuovamente postgres sul server clonato poi parte... strano no? io direi che sta finendo di copiare i file. Bisogna capire se i dati sono già sul PC locale (in cache), ma non ancora tutti salvati su file e quindi dovresti provare a eseguire $ sync prima di far partire Postgres O il processo di copia è ancora in esecuzione, ma il controllo è stato passato da rsync, che ha completato il suo lavoro, ad un processo interno che si occupa del trasferimento di dati. In questo caso penso che sync non funzioni. Un po' come accade quando scrivi sulla penna USB, che a riga di comando ti dice che ha finito, però se provi a smontarla ti dice di attendere un attimo per completare l'operazione. Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Strumenti per l'ufficio: https://www.libreoffice.org GNU/Linux User: 302090: http://counter.li.org Non autorizzo la memorizzazione del mio indirizzo su outlook
Re: clonazione db
Il 26/04/20 14:22, Giuseppe Sacco ha scritto: se copi da un computer ad un altro un database postgres, a patto che i due computer abbiano installato lo stesso software e che su entrambi il database sia spento, non dovresti avere problemi. Magari non stai copiando tutte le directory. Ad esempio, per copiare un cluster postgresql devi copiare sia la directory /var/lib/postgresql/*versione*/*nome*/ sia la directory /etc/postgresql/*versione*/*nome*/ Poi magari dovrai aggiornare la configurazione se vi hai messo indirizzo IP o altro. in effetti funziona ma pensavo non funzionasse perché avevo fatto uno script che faceva tutto (stoppava in entrambi i server postgres, faceva l'rsync e poi riavviava postgres) e mentre postgres si avviava correttamente nel server remoto di origine poi falliva nel server clonato. Dopo però una breve attesa se si avvia nuovamente postgres sul server clonato poi parte... strano no? Piviul
Re: clonazione db
Ciao Piviul, Il giorno sab, 25/04/2020 alle 15.37 +0200, Piviul ha scritto: [...] > Questo perché stavo provando a clonare un pc a caldo con rsync > (escludendo qualche dir) e funziona tutto bene tranne i db che poi non > ripartono finita la clonazione... se copi da un computer ad un altro un database postgres, a patto che i due computer abbiano installato lo stesso software e che su entrambi il database sia spento, non dovresti avere problemi. Magari non stai copiando tutte le directory. Ad esempio, per copiare un cluster postgresql devi copiare sia la directory /var/lib/postgresql/*versione*/*nome*/ sia la directory /etc/postgresql/*versione*/*nome*/ Poi magari dovrai aggiornare la configurazione se vi hai messo indirizzo IP o altro. Ciao, Giuseppe
Re: clonazione db
Ciao, Per myisam puoi copiare i files usando rsync, ma se ricordo bene, per innodb non basta copiare i files dei dati, qua c'e un post che spiega bene la cosa https://dba.stackexchange.com/questions/41667/is-it-okay-to-use-rsync-on-innodb-database-if-the-mysql-server-is-shutdown Il giorno dom 26 apr 2020 alle ore 06:53 Paolo Redaelli < paolo.redae...@gmail.com> ha scritto: > > > Il 25 aprile 2020 15:37:04 CEST, Piviul ha scritto: > >Ciao a tutti, mi chiedevo se c'era un modo per clonare un db (postgres > >o > >mysql) copiando direttamente il file system (con rsync). Ho provato > >stoppando sia il db sorgente che destinazione ma poi quello di > >destinazione non riparte, si lamenta ma non tanto da capirne il motivo. > > > >Questo perché stavo provando a clonare un pc a caldo con rsync > >(escludendo qualche dir) e funziona tutto bene tranne i db che poi non > >ripartono finita la clonazione... > > Copiare I file di una base dati mentre funziona è sicuramente inutile come > hai scoperto. > Mi stupisce un po' che a processi fermi non funzioni, perché dal punto di > vista della base dati non ci sarebbe modo di accorgersene. > Che tipo di errore ti da? > Magari è un "questi archivi son di pippo.miodominio ed io sono > topolino.miodominio!" > > -- > Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. > > -- .~. /V\ // \\ /( )\ ^`~'^
Re: clonazione db
Il 25 aprile 2020 15:37:04 CEST, Piviul ha scritto: >Ciao a tutti, mi chiedevo se c'era un modo per clonare un db (postgres >o >mysql) copiando direttamente il file system (con rsync). Ho provato >stoppando sia il db sorgente che destinazione ma poi quello di >destinazione non riparte, si lamenta ma non tanto da capirne il motivo. > >Questo perché stavo provando a clonare un pc a caldo con rsync >(escludendo qualche dir) e funziona tutto bene tranne i db che poi non >ripartono finita la clonazione... Copiare I file di una base dati mentre funziona è sicuramente inutile come hai scoperto. Mi stupisce un po' che a processi fermi non funzioni, perché dal punto di vista della base dati non ci sarebbe modo di accorgersene. Che tipo di errore ti da? Magari è un "questi archivi son di pippo.miodominio ed io sono topolino.miodominio!" -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
clonazione db
Ciao a tutti, mi chiedevo se c'era un modo per clonare un db (postgres o mysql) copiando direttamente il file system (con rsync). Ho provato stoppando sia il db sorgente che destinazione ma poi quello di destinazione non riparte, si lamenta ma non tanto da capirne il motivo. Questo perché stavo provando a clonare un pc a caldo con rsync (escludendo qualche dir) e funziona tutto bene tranne i db che poi non ripartono finita la clonazione... Grazie! Piviul
