[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: clonazione a caldo [clonazione db]



Il giorno ven 1 mag 2020 alle ore 22:08 Piviul <piviul@riminilug.it> 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
Tesssssoro, dov'é il mio tessssoro...


Reply to: