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
