HELP: backup di mysql su server esterno

[mariana]

Ciao a tutti,

ho bisogno del vostro supporto per capire come risolvere nel migliori dei modi (con un okkio anche ai costi) il seguente problema:

devo realizzare un applicativo web con database mysql e devo cercare di garantire il corretto funzionamento dell’applicativo e del server h24 7g su 7.

Ho gia’ preso un server dedicato abbastanza performante.
Pensavo (e qui che vorrei un vostro consiglio) di acquistare un secondo server (piu’ economico) o anche un spazio hosting cmq entrambi in un'altra web farm da utilizzare come backup progressivo (magari se c’e’ qualcosa che sul server principale che mi avvia uno schedule che ad una certa ora della notte mi trasferisce i db mysql ed una cartellina che conterrà un bel po’ di fotografie).
Vorrei essere tranquillizzata che questa procedura possa funzionare sempre anche se il db iniziasse a diventare veramente grosso (tipo 1gb), ecco perchè volevo sapere anche se esistesse qualche procedura di backup incrementale.

Insomma il tutto perche’ se magari dovesse succedere qualcosa al server principale con un cambio veloce di dns posso avere la calma di risolvere (o far risolvere) il problema senza recare un disservizio troppo lungo al cliente.
Cosa mi consigliate?
Ovvio che questa e’ una precauzione per me….ma sento proprio di dovermene creare una.

Ciao e grazie


PS e se in fase di insert o update facessi la stessa operazione sul server di backup? ma questo comporterebbe l'apertura della porta 3306 compromettendo la sicurezza del server, c'è una soluzione per salvare capra e cavoli?

[deleted_29]

ci sono vari approcci

1) master-slave, replicazione quindi nel tuo caso a livello di statement
2) dump-e-restore. non è molto efficiente, telematicamente, anche se comprimi molto i file da spedire
3) rsync per tabelle myisam. più veloce, in quanto la gestione di rsync "blocchetta" i file. però richiede il blocco (se vuoi la certezza) del server durante la copia
4) -se hai il supporto del sistema operativo- snapshot brutale ed invio (anche hot, qui il tempo è dell'ordine di pochi secondi di blocco del server)
5) le foto... son dolorose, essendo già compresse. lì si va di rsync in generale
6) soluzione"sticazzi", replicazione a livello di blocco ZFS. praticamente è come un "raid-1" tra due macchine remote

Quindi gli aspetti da stabilire sono
1) è possibile avere copie non immediate (per modo di dire)?
2) il backup può bloccare il sito?
3) quanto tempo può essere bloccato?
4) qual'è la velocità della connessione?
5) si vuole una soluzione LAN o WAN? O LAN+WAN?
6) ordine di grandezza del budget

[daniele_dll]

per ridurre al minimo i tempi di ripristino e massimizzare la sicurezza la soluzione migliore sarebbe avere 2 server dedicati, il secondo meno potente, collegati su rete interna con sun una combinazione di:
- drbd
- macchine virtuali
- hearthbeat
- lvm su disco

benché questa soluzione è più "lenta" di un sistema liscio o di una replicazione con master/slave, ma è veramente MOLTO più sicura ... inoltre la lentezza può essere eliminata aumentando l'hardware (qui c'è comunque da fare un discorso a parte perché oggi come oggi le macchine virtuali hanno appositi driver/moduli per lavorare direttamente a livello nativo introducendo dei rallentamenti nell'ordine del 3/4% nelle operazioni di io/rete)

questa soluzione è molto più sicura perché:
- il vero sistema, quello che contiene l'applicativo con tutto quanto, gira dentro una macchina virtuale e non è su server fisico
- essendo una macchina virtuale è replicata PERFETTAMENTE anche nel server slave (grazie a drbd)
- il nodo secondario, se il primo esplode, in automatico torna su o torna giù (ovviamente a risincronizzazione terminata)
- drbd opera a livello di disco, quindi il sistema sa PER CERTO che il dato scritto ... è scritto, mysql ovviamente non può saperlo (e per scritto intendo fisicamente sul disco, la modalità di scrittura diretta O_DIRECT non è in grado di disabilitare la cache interna del disco stesso o del controller stesso esclude semplicemente la cache dei file del sistema operativo, per assicurarsi che i dati scritti siano scritti DRBD utilizza il meccanismo di barriere presenti nel kernel)
- se l'applicativo web lavora con file uploadati, scaricati da servizi esterni o generati, drbd ti permette di avere una copia in tempo reale anche di questi
- se il disco si danneggia, il controller di rete scoppia e via dicendo, drdb gestisce la situazione in modo trasparente risincronizzandosi nel momento in cui tutto torna su ... senza farti perdere niente

se a questo ci aggiungi dei backup fatti 1/2 volte al giorno sei coperto sia in caso di totale crash della macchina sia nel caso di corruzione di dati

ovviamente è una soluzione più complessa che va implementata da un sistemista esperto o da un'azienda che fa quello che sa

la soluzione alternativa sarebbe stata probabilmente acquistare un servizio di cloud ridondata (per il disco) così da avere lo stesso risultato finale

ripeto, è più lenta di una semplice master/slave, ma da la certezza della consistenza dei dati!

PS: ho implementato decine di sistemi che sfruttano queste tecnologie e, la cosa meravigliosa, è che per l'attestazione del corretto funzionamento bastava staccare la corrente all'improvviso ad una macchina per vedere, nell'arco di 60 secondi, il sistema di riserva operativo con tutti i dati aggiornati già a lavoro
PS2: certo, la soluzione migliore sarebbe 2 server per le macchine virtuali più 2 server per lo storage, così da separare i compiti e ridurre lo stress delle macchine ... ma praticamente vuol dire metter su una cloud

[deleted_29]

non sono particolarmente d'accordo, o meglio è una soluzione per sistemi che non richiedono particolari cure.

una situazione LAN (personalmente prediligo di gran lunga la duplicazione ZFS, decisamente più veloce di drdb, oltre che col supporto di deduplicazione che consente di avere SAN con più macchine virtuali praticamente a costo zero (=>mi riferisco ai costi di hosting per lo storage)) espone a vari problemi

1) si guasta uno switch o un apparato di rete => giù
2) un problema software (es. aggiornamento inopinato) => giù
3) s'incendia la farm => giù
---
Ecco perchè è importante stabilire, prima, se si vuol avere una ridondanza LAN o WAN.

Stabilito quello si può in seguito dettagliare come procedere

[daniele_dll]

Originariamente inviato da franzauker
non sono particolarmente d'accordo, o meglio è una soluzione per sistemi che non richiedono particolari cure.

una situazione LAN (personalmente prediligo di gran lunga la duplicazione ZFS, decisamente più veloce di drdb, oltre che col supporto di deduplicazione che consente di avere SAN con più macchine virtuali praticamente a costo zero (=>mi riferisco ai costi di hosting per lo storage)) espone a vari problemi

la duplicazione zfs per mysql è sicuramente una buona soluzione se hai un server con solo il db su perché altrimenti che fai, un po di roba la replichi ed il resto no?

se ti riferisci invece al supporto per la replicazione direttamente su zfs, più che della velocità, che al 95% dipende dalla rete e dall'hardware, mi preoccuperei più del supporto perché ZFS (benché assolutamente MAGNIFICO) significa usare Solaris o meglio significa usare un sistema operativo che supporti tutte le varie features, e linux non rientra tra questi, di conseguenza significa, praticamente, metter su un dedicato con Solaris.
Visto che difficilmente le normali server farm permettono l'installazione del sistema da remoto, deve essere selezionabile tra quelli da loro supportati cosa non sempre vera.

Ripeto, ZFS è assolutamente magnifico, ma necessita di Solaris, magari altri SO lo supportano ma visto che non sono implementazioni stabili che hanno anni di attività alle spalle direi che non è una facile opzione.

1) si guasta uno switch o un apparato di rete => giù
2) un problema software (es. aggiornamento inopinato) => giù
3) s'incendia la farm => giù

1) si tratta di una server farm, generalmente gli apparati sono ridondati e/o vengono sostituiti in tempi rapidi visto che non è un server che viene "bloccato" ma sono, in genere, una 37/38 a salire ... tra l'altro, proprio a sicurezza di questo, ci sono le garanzie sulla rete e sui down quindi se l'operatore, per contratto, ti offre il *99.9% di uptime vuol dire che è tranquillo del fatto suo.

* Generalmente sono riferiti al mese e non all'anno, ma nel peggiore dei casi il 99.9% di un mese significa, in media, poco più di 40 minuti ...

2) non vedo questo cosa abbia a che fare direttamente con il problema esposto, qualsiasi sistema operativo/distribuzione/combinazione software soffre dei problemi che crea il sistemista stesso

3) ... famo prima a dire che se cade un meteorite e muoriamo tutti ...*

* E' vero che è successo, sono anche esplose intere sale, ma si tratta di casi pochi avvenuti nell'ultimo decennio ed anche meno prima e tra l'altro se dobbiamo andare con quest'ottica i server vanno presi entrambi in italia vicine al MIX.

Ecco perchè è importante stabilire, prima, se si vuol avere una ridondanza LAN o WAN.

Stabilito quello si può in seguito dettagliare come procedere

da quello che si capisce, ha acquistato un server dedicato "per avere più sicurezza" , ovvero per non stare in un hosting codiviso e poter gestire tutta la situazione in autonomia tenendola sotto controllo.

tra l'altro -> server già acquistato -> poche probabilità che solaris sia tra i sistemi operativi supportati dal suo fornitore di servizi

@mariana
riguardo ai costi, guarda, l'hoster a cui mi appoggio io non è italiano, anche se ha sede legale e supporto tecnico, con uffici, anche in italia, e con meno di 2500€ iva esclusa hai 2 server di fascia media (i5-2400, 16gb di memoria, 2x2tb di disco su controller raid hardware, kvm su ip, reinstallazione e reboot da remoto, vmware 4.1 esxi controllabile da remoto con vshpere, un blocco di 3/4 ip riassegnabile dal pannello di controllo, api per la gestione da remoto dei propri servizi acquistati e tanta altra roba)

volendo offrono anche meno (e secondo me per te andrebbe comunque bene visto che al massimo ti serve 1 macchina virtuale), verrebbe meno di 2000€ iva esclusa

ovviamente hai già un server dedicato e quindi c'è poco che fare, però se non lo hai preso per un anno intero puoi fare passaggio alla scadenza, od in alternativa puoi fare questo "salto" verso la scadenza del contratto

[deleted_29]

Originariamente inviato da daniele_dll
la duplicazione zfs per mysql è sicuramente una buona soluzione se hai un server con solo il db su perché altrimenti che fai, un po di roba la replichi ed il resto no?

replichi l'intero pool, quindi l'intero sistema

...linux non rientra tra questi, di conseguenza significa, praticamente, metter su un dedicato con Solaris.

BSD

Visto che difficilmente le normali server farm permettono l'installazione del sistema da remoto, deve essere selezionabile tra quelli da loro supportati cosa non sempre vera.

BSD mi risulta supportato praticamente da tutte le farm.
In realtà spesso con release non proprio aggiornate, ma tant'è

Ripeto, ZFS è assolutamente magnifico, ma necessita di Solaris, magari altri SO lo supportano ma visto che non sono implementazioni stabili che hanno anni di attività alle spalle direi che non è una facile opzione.

FreeBSD lo supporta da anni, la "vera" differenza riguarda le prestazioni (maggiori per solaris per il suo ottimo supporto multithread)

1) si tratta di una server farm, generalmente gli apparati sono ridondati e/o vengono sostituiti in tempi rapidi visto che non è un server che viene "bloccato" ma sono, in genere, una 37/38 a salire ... tra l'altro, proprio a sicurezza di questo, ci sono le garanzie sulla rete e sui down quindi se l'operatore, per contratto, ti offre il *99.9% di uptime vuol dire che è tranquillo del fatto suo.

L'esperienza prova il contrario.
Soprattutto nel caso di guasti "strani", per i quali non è che si spengono i led di uno switch e bon.
Bensì del tipo che inizi a perdere una gran % di pacchetti.
Attacco DOS? Problema hardware? Problema del server? Problema del software?
E così via

2) non vedo questo cosa abbia a che fare direttamente con il problema esposto, qualsiasi sistema operativo/distribuzione/combinazione software soffre dei problemi che crea il sistemista stesso

ha a che fare direttamente, perchè se adotti un sistema di replicazione "raid-1" (implementato come vuoi), un problema software su un sistema verrà replicato sull'altro, immediatamente (o quasi).
In strutture "a ridondanza estesa" è normale avere due sistemi diversi, ma diversi in tutto

3) ... famo prima a dire che se cade un meteorite e muoriamo tutti ...*

Sarà che per mestiere vedo sinistri di tutti i tipi, ma incendi, allagamenti dal basso, dall'alto, affumicazioni, fulmini etc ne ho visti letteralmente a centinaia.
Ho visto perfino un rack di server con... tetto e grondaia
Per quanto riguarda poi l'esperienza recentissima di Aruba poi non parliamo.

tra l'altro -> server già acquistato -> poche probabilità che solaris sia tra i sistemi operativi supportati dal suo fornitore di servizi

FreeBSD, che solaris?

@mariana
riguardo ai costi, guarda, l'hoster a cui mi appoggio io non è italiano, anche se ha sede legale e supporto tecnico, con uffici, anche in italia, e con meno di 2500€...

AIAIAIAIIII... occhio al regolamento!


---
Tornando al tema ribadisco che qualsiasi progetto deve partire dalla decisione-chiave, ossia LAN oppure WAN, coi relativi pregi e difetti.
Per ridurre i costi al minimo la scelta è tipicamente WAN MA se e solo se si ha banda in abbondanza e già pagata.
Nella valutazione complessiva, infatti, va ricordato che spesso si acquistano "pacchetti" di dati, occhio quindi a trasferimenti massivi di dati che consumano il plafond (ammesso che esista)

[daniele_dll]

Originariamente inviato da franzauker
replichi l'intero pool, quindi l'intero sistema
BSD
BSD mi risulta supportato praticamente da tutte le farm.
In realtà spesso con release non proprio aggiornate, ma tant'è
FreeBSD lo supporta da anni, la "vera" differenza riguarda le prestazioni (maggiori per solaris per il suo ottimo supporto multithread)

L'esperienza prova il contrario.
Soprattutto nel caso di guasti "strani", per i quali non è che si spengono i led di uno switch e bon.
Bensì del tipo che inizi a perdere una gran % di pacchetti.
Attacco DOS? Problema hardware? Problema del server? Problema del software?
E così via

ti rendi conto, vero, che le problematiche da te sollevate sono ASSOLUTAMENTE estranee al tipo di soluzione da adottare ... zfs, drbd, rsy, master/slave o qualsiasi altra soluzione ... anche l'accesso del server stesso è soggetto a queste problematiche che, ovviamente vanno tenute in considerazione, ma non deve diventare una fobia

tra l'altro, trattandosi in questo caso un sistema attivo/passivo, anche se dovesse totalmente saltare la sincronizzazione non succederebbe nulla di grave in quanto il passivo tornerebbe a sincronizzarsi subito dopo

ha a che fare direttamente, perchè se adotti un sistema di replicazione "raid-1" (implementato come vuoi), un problema software su un sistema verrà replicato sull'altro, immediatamente (o quasi).

In strutture "a ridondanza estesa" è normale avere due sistemi diversi, ma diversi in tutto

si, ma quindi che fai, non aggiorni o non usi questi sistemi?

personalmente fare uno bello snapshot lvm a caldo e risolverei il problema così che, in caso di catastrofe, non succede nulla

tra l'altro, logica vuole, che sistema e app/dati stiano su partizioni/volumi separati così che, l'unico inconveniente del ripristinare uno snapshot sarà solo il brevissimo down ... fine lì

inoltre, il concetto di ridondanza estesa, che senso ha? tu stai ridondando l'hardware e, per sicurezza, acquisti hardware da fornitori diversi così da prendere componentistiche che non facciano parte dello stesso lotto originario (un difetto di produzione sarebbe presente in tutto l'hardware acquistato) ... ma quello che stai affermando rispetto al software è invece poco sensato in quanto non è evitando una replicazione di tipo "raid-1" che risolvi il problema ... se va giù il primario a causa di un'aggiornamento che fai ... reinstalli tutto?

no ... snapshot e ripristini il sistema al volo

Sarà che per mestiere vedo sinistri di tutti i tipi, ma incendi, allagamenti dal basso, dall'alto, affumicazioni, fulmini etc ne ho visti letteralmente a centinaia.
Ho visto perfino un rack di server con... tetto e grondaia
Per quanto riguarda poi l'esperienza recentissima di Aruba poi non parliamo.

non consiglieri a nessuno, nemmeno a quelli a cui voglio a male, di rivolgersi ad aruba per le proprie necessità

FreeBSD, che solaris?

non uso freebsd attivamente, tanto meno zfs, quindi non conoscevo ^^

AIAIAIAIIII... occhio al regolamento!

infatti non ho citato ne l'hoster ne ho dato importi precisi, solo indicativi

ci sono state svariate discussioni sulla tipologia di servizio e/o server (feature incluse, hardware, costi in generale), fin quando non si fanno nomi e/o confronti tra vari fornitori di servizi problemi non c'è ne sono

Tornando al tema ribadisco che qualsiasi progetto deve partire dalla decisione-chiave, ossia LAN oppure WAN, coi relativi pregi e difetti.
Per ridurre i costi al minimo la scelta è tipicamente WAN MA se e solo se si ha banda in abbondanza e già pagata.
Nella valutazione complessiva, infatti, va ricordato che spesso si acquistano "pacchetti" di dati, occhio quindi a trasferimenti massivi di dati che consumano il plafond (ammesso che esista)

mettere una replicazione (indipendentemente dal tipo) su server che non sono collocati nella stessa server farm ha costi abnormi, soprattutto in italia sia per via della banda sia per via della latenza

inoltre una replicazione come quella di drbd di classe c (e la rispettiva per zfs) sarebbe improponibile per via delle latenze troppo elevate

[deleted_29]

Originariamente inviato da daniele_dll
ti rendi conto, vero, che le problematiche da te sollevate sono ASSOLUTAMENTE estranee al tipo di soluzione da adottare ... zfs, drbd, rsy, master/slave o qualsiasi altra soluzione ... anche l'accesso del server stesso è soggetto a queste problematiche che, ovviamente vanno tenute in considerazione, ma non deve diventare una fobia

Al contrario li ritengo i primissimi requisiti di progetto.
Che è poi sempre quello: LAN o WAN

tra l'altro, trattandosi in questo caso un sistema attivo/passivo, anche se dovesse totalmente saltare la sincronizzazione non succederebbe nulla di grave in quanto il passivo tornerebbe a sincronizzarsi subito dopo

si, ma quindi che fai, non aggiorni o non usi questi sistemi?...tu stai ridondando l'hardware e, per sicurezza, acquisti hardware da fornitori diversi così da prendere componentistiche che non facciano parte dello stesso lotto originario (un difetto di produzione sarebbe presente in tutto l'hardware acquistato) ... ma quello che stai affermando rispetto al software è invece poco sensato in quanto non è evitando una replicazione di tipo "raid-1" che risolvi il problema ... se va giù il primario a causa di un'aggiornamento che fai ... reinstalli tutto?

no ... snapshot e ripristini il sistema al volo

La replicazione zfs opera sui pool: se la fai su quella di sistema ottieni una sorta di RAID-1, se la fai sui dati puoi effettuarla tra sistemi totalmente diversi, anzi addirittura tra pool del tutto diversi.
Qualcosa di simile a una copia dei file (es. del tablespace mysql).
Puoi benissimo (in generale ci sono) avere più pool diversi, e decidere quali sincronizzare (es. quella di sistema una volta al mese, o magari mai, a richiesta dell'operatore, quella dati ogni ora etc)

non uso freebsd attivamente, tanto meno zfs, quindi non conoscevo ^^

male

mettere una replicazione (indipendentemente dal tipo) su server che non sono collocati nella stessa server farm ha costi abnormi, soprattutto in italia sia per via della banda sia per via della latenza

inoltre una replicazione come quella di drbd di classe c (e la rispettiva per zfs) sarebbe improponibile per via delle latenze troppo elevate

ahem... parlo di zfs... no, o meglio ni.

---
descrivo brutalmente come funziona alla grossa, così da dare un'idea (ammesso che sia interessante) di pregi e difetti.
dato un pool zfs (facendo finta di sapere cos'è, in pratica una sorta di partizione-finta dentro un finto-file) puoi farne uno snapshot.
e fin qui tutto bene.
la cosa "bella" è che lo snapshot è un file che puoi brutalmente inviare "da qualche altra parte" (ad esempio con ssh, comprimendolo etc).
Dall' "altra parte" prendi lo snapshot e "magicamente" l'appendi al tuo pool, da cui puoi attingere.

In sostanza, invece di operare a livello di blocco del disco lavora a livello di... blocco zfs.
Le cose "belle" sono altre 2:
- l'invio di snapshot successivi incrementali. in pratica alla prima "mandata" spedisce una copia intera, successivamente solo le modifiche apportate (=installi le due macchine, sincronizzi tutto su LAN, porti la seconda "lontano" e mandi gli snapshot incrementali, oppure aspetti pazientemente)
- puoi "intercettare" gli snapshot e mandarli ad esempio su un NAS (LAN) per avere un backup storico "da-sempre-a-sempre".

Ecco quindi il "difetto" che non è una replicazione diciamo così tipo "dd" del disco, che sincronizza diciamo come una sorta di RAID-1 ogni singolo settore del disco, mentre il "pregio" è proprio quello... di non esserlo, perchè zfs è così flessibile che in realtà è il contenuto (coi metadati) a essere rilevante, e non la posizione sul disco, i settori etc (la situazione "fisica").

Spero di aver dato un'idea almeno alla grossa.
---
Tornando al tema, per come la vedo io, è fondamentale stabilire "quanto" cambiano i dati.
Se i cambiamenti sono numerosi => non si può che operare su LAN, sia per questione di costi, sia proprio di banda massima trasmissibile (non ipotizzo neppure una connessione dedicata)
Se i cambiamenti son pochi io, personalmente, mi orienterei su due macchine fisicamente distinte, magari addirittura in due paesi diversi, trasferendo via ssh i dump del database (così da averne nel contempo i backup)

EDIT: in realtà, per completezza, con zfs si può perfino fare la replicazione a livello di blocco, nel senso di creare un block-device formattato come si vuole su un normale pool, ma francamente... non l'ho mai fatto
penso che possa avere un vago senso (teorico) nel caso in cui si voglia metterci un filesystem diverso (magari senza snapshot) per poi... snapshottarlo ugualmente
Questo thread mi fa venire idee... se trovo il tempo magari provo un NTFS su zfs

[daniele_dll]

Originariamente inviato da franzauker


Al contrario li ritengo i primissimi requisiti di progetto.
Che è poi sempre quello: LAN o WAN

si, ma ti ripeto, ti rendi conto che le problematiche da te sollevate (e mi riferisco prettamente a quanto quotato prima) sono assolutamente indipendenti dalle tecniche e/o tipologie adottate?

Cosa pensi che cambi se il sistema gira su LAN o su WAN quando lo switch a cui è attaccato a questo tipo di problemi?

Se è in LAN smette di parlarsi con l'altro/gli altri server della lan, se è in WAN non arriva neanche al router

quindi, ti ripeto, sono problemi che prescindono qualsiasi tipologia di sistema adottata

non vedo come tu possa essere confuso o non comprendere quello che ho scritto.

Se lo switch impazzisce e salta la sincronizzazione tra le macchine, nel momento in cui il sistema torna ad operare correttamente verrà rieffettuata la sincronizzazione

e siccome è un sistema ove solo una macchina risponde e l'altra e quella di "riserva" che deve partire in caso di crisi esistenziali, non succede nulla di drammatico ... partirà quella di riserva per come deve e la primaria si risincronizzerà con la secondaria che avrà i dati più aggiornati visto che la primaria (nel momento in cui salta uno switch) non può più svolgere i suoi compiti

La replicazione zfs opera sui pool: se la fai su quella di sistema ottieni una sorta di RAID-1, se la fai sui dati puoi effettuarla tra sistemi totalmente diversi, anzi addirittura tra pool del tutto diversi.
Qualcosa di simile a una copia dei file (es. del tablespace mysql).
Puoi benissimo (in generale ci sono) avere più pool diversi, e decidere quali sincronizzare (es. quella di sistema una volta al mese, o magari mai, a richiesta dell'operatore, quella dati ogni ora etc)

mmm, la stessa cosa la puoi fare con DRBD, non sei necessariamente legato a dover esportare tutto il sistema, però è ovvio che usare delle macchine virtuali aumenta l'efficenza del sistema

per altro sei anche più al sicuro: se la tua preoccupazione sono gli aggiornamenti puoi fare una hot-copy della VM, installarli li su e vedere se ci sono problemi ... se tutto va bene poi fai uno snapshot del sistema e aggiorni la VM che risponde alle richieste

un sistema che non usa VM non ha questi vantaggi, al massimo fai lo snapshot del filesystem prima di far partire l'aggiornamento, ma se qualcosa va storto COMUNQUE dovrai fare un down ... usare una VM per testare gli aggiornamenti prima di passarli in produzione ti permette di portare la percentuale, già bassa, abbastanza vicino allo zero

male
ahem... parlo di zfs... no, o meglio ni.

non è ni ... è si ... se il tuo DB scrive 1GB di dati ... un gb di dati verrà trasmesso sia con ZFS, che opera a livello dei suoi blocchi, sia con DRBD, che opera a livello di "settori" del disco.

zfs è più efficente, questo si, ma la quantità di dati trasmessa, se varia, varia di poco perché può variare la quantità di metadati trasmessi ma non certo la quantità di dati scritti trasmessi

descrivo brutalmente come funziona alla grossa, così da dare un'idea (ammesso che sia interessante) di pregi e difetti.
dato un pool zfs (facendo finta di sapere cos'è, in pratica una sorta di partizione-finta dentro un finto-file) puoi farne uno snapshot.
e fin qui tutto bene.
la cosa "bella" è che lo snapshot è un file che puoi brutalmente inviare "da qualche altra parte" (ad esempio con ssh, comprimendolo etc).
Dall' "altra parte" prendi lo snapshot e "magicamente" l'appendi al tuo pool, da cui puoi attingere.

apparte il poter "appendere" lo snapshot ad un altro pool (non so se si può fare) con lvm fai più o meno tutto quello descritto su ^^

In sostanza, invece di operare a livello di blocco del disco lavora a livello di... blocco zfs.
Le cose "belle" sono altre 2:
- l'invio di snapshot successivi incrementali. in pratica alla prima "mandata" spedisce una copia intera, successivamente solo le modifiche apportate (=installi le due macchine, sincronizzi tutto su LAN, porti la seconda "lontano" e mandi gli snapshot incrementali, oppure aspetti pazientemente)

qualsiasi sistema di replicazione opera così, mica drbd ti invia ogni volta tutto il contenuto del disco

ovviamente lavora in modo incrementale

- puoi "intercettare" gli snapshot e mandarli ad esempio su un NAS (LAN) per avere un backup storico "da-sempre-a-sempre".

-> LVM

Ecco quindi il "difetto" che non è una replicazione diciamo così tipo "dd" del disco, che sincronizza diciamo come una sorta di RAID-1 ogni singolo settore del disco, mentre il "pregio" è proprio quello... di non esserlo, perchè zfs è così flessibile che in realtà è il contenuto (coi metadati) a essere rilevante, e non la posizione sul disco, i settori etc (la situazione "fisica").

Spero di aver dato un'idea almeno alla grossa.

non è propriamente un difetto, ma semplicemente DRBD ti da la possibilità di utilizzare sistemi che operano anche senza filesystem perché è un layer aggiuntivo (ad esempio un DB che lavora direttamente su una "partizione", senza bisogno del filesystem)

Tornando al tema, per come la vedo io, è fondamentale stabilire "quanto" cambiano i dati.
Se i cambiamenti sono numerosi => non si può che operare su LAN, sia per questione di costi, sia proprio di banda massima trasmissibile (non ipotizzo neppure una connessione dedicata)
Se i cambiamenti son pochi io, personalmente, mi orienterei su due macchine fisicamente distinte, magari addirittura in due paesi diversi, trasferendo via ssh i dump del database (così da averne nel contempo i backup)

indubbiamente, un sistema dislocato geograficamente ha i suoi vantaggi, ma anche i suoi enormi svantaggi svantaggi

inoltre "trasferire i dump" ha il grosso problema che i dati non sono aggiornati in tempo reali, se oltre a mysql ci sono dati su disco sei comunque bloccato, ed il tempo di ripristino del sistema è consistente visto che dopo il primario va giù devi aggiornare il secondario ... e dopo che il primario torna su devi stoppare il secondario, dumpare il db e trasferirlo, trasferire i file, e riattivare il primario

la soluzione DRBD + LVM + VM serve proprio ad evitare questi problemi ... e a livello di aggiornamenti, basta farsi un hotcopy per testarli (se c'è questa preoccupazione) e poi fare uno snapshot prima di farli partire ... fine lì

il sistema che gestisce la virtualizzazione difficilmente andrà aggiornato (anche perché userei un vmware esxi ad esempio, quindi di aggiornare c'è veramente poco)

[deleted_29]

Originariamente inviato da daniele_dll
...quindi, ti ripeto, sono problemi che prescindono qualsiasi tipologia di sistema adottata

E invece no.
Perchè se la sede primaria ha problemi, per qualsiasi motivo, la fanculizzo e attivo la sede di backup, solo al costo di una propagazione DNS.
Scomodo, senza dubbio, ma lasciando stare superscriptoni automatici (improbabili in questo caso), basta programmare una sorta di "heartbeat" sul secondario che ti manda un SMS sul cellulare quando perde la comunicazione.

Se lo switch impazzisce e salta la sincronizzazione tra le macchine, nel momento in cui il sistema torna ad operare correttamente verrà rieffettuata la sincronizzazione

Nel momento in cui... significa... nel momento in cui "qualcuno" nella farm capisce qual'è il problema (cosa per nulla scontata), gli viene voglia di risolverlo, acquista il materiale (la legge di murphy dice che l'apparato rotto è l'unico disponibile, perchè tutti gli altri di riserva sono stati usati ieri, e che si è nella notte di natale) e così via.

Continuo a mantenere fermi i dubbi riguardo alla fruibilità effettivamente a prova di "problemi" di una ESCLUSIVAMENTE installazione singola, basati essenzialmente sull'esperienza.

...la stessa cosa la puoi fare con DRBD...

Se parliamo di deduplicazione non mi risulta esistere nulla di simile nel mondo Linux (btrfs escluso, non l'ho mai montato, non ti so dire)

...un sistema che non usa VM non ha questi vantaggi, al massimo fai lo snapshot del filesystem prima di far partire l'aggiornamento, ma se qualcosa va storto COMUNQUE dovrai fare un down ... usare una VM per testare gli aggiornamenti prima di passarli in produzione ti permette di portare la percentuale, già bassa, abbastanza vicino allo zero

diciamo che neppure le VM sono immuni dai problemi di backup, e di snapshot e di gestione dischi, soprattutto nel caso di "presentazione" delle LUN, e che talvolta neppure i guru VMware (intesi della casa madre) riescono a risolvere.
E che è normale (almeno per me) provare almeno le modifiche su una VM locale (locale nel senso del mio studio)
Cerco di non andare troppo OT e fermo il discorso, tranne ricordare che - ecco un vantaggio oggettivo di solaris rispetto a bsd - gli snapshot appaiono... all'avvio di grub sotto ai vari kernel.
Non so quale sia la procedura con LVM, ma con solaris riavvii la macchina => scegli "fanculizza il sistema e torna allo snapshot" dal menù grub => avvio.

non è ni ... è si ... se il tuo DB scrive 1GB di dati ... un gb di dati verrà trasmesso sia con ZFS, che opera a livello dei suoi blocchi, sia con DRBD, che opera a livello di "settori" del disco.

zfs è più efficente, questo si, ma la quantità di dati trasmessa, se varia, varia di poco perché può variare la quantità di metadati trasmessi ma non certo la quantità di dati scritti trasmessi

In realtà c'è una differenza. Mentre zfs "sa" cosa spedisce, perchè "sa" come funziona il filesystem, drdb no, non lo sa, proprio perchè è "ubiquo", nel senso di sostanzialmente slegato dal filesystem soprastante.
Nella mia esperienza, in sintesi, zfs è più efficiente nell'inviare "davvero" la quantità minima di informazioni per ricostruire i dati (che a loro volta possono essere deduplicati e compressi).
Questo è importante in un ambiente WAN, molto meno in uno LAN.
Certamente però non è "magia", è solo più efficiente.

apparte il poter "appendere" lo snapshot ad un altro pool (non so se si può fare) con lvm fai più o meno tutto quello descritto su ^^

Bhè LVM è stato proprio pensato come un tentativo di portare metodi da server "vero" nel mondo Linux, non è quindi sorprendente che riprenda alcune modalità.
Non sono molto esperto di LVM, sono anni che prediligo BSD a Linux (non in via esclusiva) come piattaforma server.

qualsiasi sistema di replicazione opera così, mica drbd ti invia ogni volta tutto il contenuto del disco

ovviamente lavora in modo incrementale

Ho spiegato sopra il perchè la conoscenza del fs consente l'impacchettamento massimo.
Esempio scemo: se hai due cartelle identiche, ne spedisce una sola (come dati).
Ciò capita di frequente nell'amministrazione dei server, dove è "normale" fare una copia delle cartelle con le applicazioni prima di "smucinarle", magari cambiando solo 5 file su 1000, e "giusto per andare sul sicuro" si copia comunque tutto quanto.
O fare un ulteriore backup "giusto per sicurezza" che è all'80% uguale al backup fatto ieri.

indubbiamente, un sistema dislocato geograficamente ha i suoi vantaggi, ma anche i suoi enormi svantaggi

Sono d'accordo, infatti continuo a sostenere che "tutto" deriva da questa decisione strategica

inoltre "trasferire i dump" ha il grosso problema che i dati non sono aggiornati in tempo reali, se oltre a mysql ci sono dati su disco sei comunque bloccato, ed il tempo di ripristino del sistema è consistente visto che dopo il primario va giù devi aggiornare il secondario ... e dopo che il primario torna su devi stoppare il secondario, dumpare il db e trasferirlo, trasferire i file, e riattivare il primario

???
Nel primo post ho segnalato le varie possibilità, che comprendono (situazione normale) una replicazione master-slave che, al netto dell'inevitabile ritardo dovuto a una replicazione su statement, può sincronizzare tranquillamente (e relativamente in modo rapido) senza bisogno di fare alcunchè.

MA c'è un MA, ossia la necessità di una certa esperienza nella gestione mysql.

Porre una domanda come quella del thread implica automaticamente non avere una gran esperienza, ecco perchè un cron dump->comprimi->rsync su ssh la ritengo [anche considerato l'invio delle immagini, che quindi richiede il medesimo meccanismo] ragionevole, si può fare diciamo in un quarto d'ora, mezz'ora al massimo.
Nel "backup" basta decomprimere il dump e ricaricarlo, anche automaticamente. In realtà si perde il "riscaldamento" del server mysql (la faccio breve qui si apre un mondo), però in emergenza può andare bene.
Per lo stesso motivo non ho neppure accennato ai log binari per il ripristino, nè a "diffare" i dump prima di inviarli etc.

la soluzione DRBD + LVM + VM serve proprio ad evitare questi problemi ... e a livello di aggiornamenti, basta farsi un hotcopy per testarli (se c'è questa preoccupazione) e poi fare uno snapshot prima di farli partire ... fine lì

E' sempre una soluzione per configurazione LAN
---
Riassunto breve: stabilito se si vuol fare LAN o WAN (o magari LAN+WAN) si può ragionare "come" operare, visto anche il vincolo stringente di budget indicato.
Almeno questo è il mio giudizio