Newsgroup: it.comp.os.linux.sys
Titolo: Continuous backup MySQL

Qualche tool preconfezionato che mi faccia un backup continuo di un server mysql utilizzando il binlog ?
 
In pratica, dump ogni X minuti/ore/giorni/settimane/etc (giusto
per avere un dump completo e evitare di ripristinare da decine di binlog) 
e, parallelamente, un bel
 
mysqlbinlog --read-from-remote-server --host=x --stop-never --user=x --password='y' mysql-bin.000001
 
O qualunque altro sistema che faccia un backup in continuazione di un mysql.
 
Idee o me lo devo scrivere da per me ?

 Idee o me lo devo scrivere da per me ?
 
Ricordo che Max Adamo sfruttava gli snapshot di ZFS per un backup orario di
MySQL. In alternativa, puoi abilitare una replica master/slave da fermare ogni
tot minuti per fare il backup
 
Enrico

 tot minuti per fare il backup
 
Che è grossomodo quello che fa mysqlbinlog, senza però dover scomodare un
ulteriore server mysql da configurare come slave. Il vantaggio del
"mysqlbinlog" è che ti crea un binary log analogo a quello originale, quindi
in caso di restore posso partire da un dump completo per poi fare reply del
binary log.
 
Cercavo però qualcosa di già preconfezionato.
Aggiungo dei requisiti, dato che in precedenza non li ho scritti:
 
1) indipendente dal tipo di FS
2) non deve richiedere un ulteriore server MySQL sul backup server
 
Cercando su google, sembra incredibile che nessuno abbia pensato ad un
tool di continuous-backup per mysql che faccia uso del binary log.
 
Non trovo nulla di utile....

 farebbe perdere 100 ordini di botto, in caso di restore.
 
a questo punto non ti serve un backup, ma un sistema in cluster in HA. 
Perchè comunque un backup continuo ti fa perdere il tempo utile a fare 
il backup.

 farebbe perdere 100 ordini di botto, in caso di restore.
 
C'entra solo in modo tangenziale, e probabilmente non è applicabile al 
tuo caso, visto che cambia l'architettura dell'applicazione, ma per 
questo tipo di esigenze si sta affermando l'uso di sistemi CQRS+ES, 
storando gli eventi in un (o più) DB append-only e poi applicandoli per 
salvare il risultato in SQL.
 
Il restore lo fai riapplicando gli eventi in ordine su un nuovo DB.
 
Per il tuo caso, credo che esista qualcosa in Go da qualche parte, 
perché noi abbiamo usato una libreria fatta apposta per simulare uno 
slave MySQL che parsa i binlog. Nel nostro caso serviva per migrare dati 
in real-time, ma penso che in origine fosse pensata per quello che serve 
a te.
 
https://github.com/siddontang/go-mysql
 
 
Magari partendo dalla lib riesci a trovare qualcosa che la usa.
 
Bye.

farebbe perdere 100 ordini di botto, in caso di restore.
 
Un problema così, temporibus illis, lo affrontai con mysqlproxy.
 
Sostanzialmente, in caso di crash potevo fare un restore dell'ultimo backup
e poi fare un playback delle query da quell'istante fino al crash. Il tutto
era molto leggero, le query venivano loggate su un file su un altro server.
 
Leonardo
-- 
 
"You all presumably know why" :-) :-(

 il backup.
 
Ammetto di non aver capito cosa intendi con tempo utile per fare il backup.
 
Non mi serve HA. Mi serve *non* perdere dati, non la continuità del servizio.
 

 a te.
 
AFAIK, questo richiede la configurazione del master in modalità
master per consentire la connessioni degli slave. Vorrei evitare.
 
Come scritto in precedenza, devo fare una cosa concettualmente molto
semplice: dei dump completi ad intervalli regolari e, parallelamente,
salvarmi il binlog in realtime (che lo fa "mysqlbinlog" in modalità --stop-never)


ore 00:00 inizio a fare il backup
ore 00:10 finisco di fare il backup
ore 00:10 inizio a fare il backup
....
 
si guasta alle 00:05, hai perso come minimo 5 minuti e forse 15.
 
Quindi se anche un minuto ti genera 100 ordini, a te serve fare HA. 
Perchè i backup avranno sempre un delta, anche se continui.

 Perchè i backup avranno sempre un delta, anche se continui.
 
Per questo parlavo di mysqlbinlog, che non ha nessun delta.
In pratica riceve, in realtime, tutte le query e le replica in 
un file locale (il binlog appunto)
 
Hai presente la replica di MySQL? Funziona allo stesso modo, con la
differenza che non devo avviare un ulteriore server mysql sul quale
replicare ma ci pensa lui a salvare lo stream in locale.
 
Immaginala come una replica ma senza MySQL in esecuzione.
 
Quindi:
 
ore 23:50 avvio mysqlbinlog in --stop-never (lui si sincronizza in realtime)
ore 00:00 inizio a fare il backup completo
ore 00:10 finisco di fare il backup completo
ore 00:10 inizio a fare il backup completo
 
Se alle 00:15 ho un crash, ripristino dal backup completo delle 00:10
poi faccio il replay del binary log dalle 00:15 fino all'ultima riga.


si, questo era il tool creato dal collega:
https://github.com/eBayClassifiedsGroup/znappy
 
 
 
Un'altra alternativa e' percona xtrabackup che ho usato qui: 
https://forge.puppet.com/maxadamo/galera_proxysql
 (ma la parte backup del 
modulo, onestamente non e' nulla di speciale...)
 
-- 
Massimiliano Adamo

 
 
E quindi chi ti vieta di usare lo slave a questo punto? 
 
Te lo dico io perché? Perche' il problema non è quello che vedi tu. 
Tu parli di picco di 100 ordini al minuto, ma lo slave ed il tuo backup 
continuo, sono asincroni. 
Esiste una modalità di replica semi-sincrona, ma per come descrivi la 
situazione, rischi comunque di perderti ordini per strada. 
 
Se parli di ordini, quindi di soldi che vanno in fumo, le soluzioni 
potrebbero essere le seguenti: 
 
1) quella fornita da Leonardo Serni, davvero interessante e non sapevo 
che il proxy loggasse tutto. Considera che oggi proxysql di Percona è 
stabile. MariaDB MaxScale mi ha lasciato un po' perplesso. 
 
2) Galera, che e' l'unica modalita' 100% sincrona, ed e' l'unico modo per 
garantire che i record su nodo A, siano gli stessi presenti su nodo B. 
Problema: richiede un numero di nodi dispari e maggiore di due.... e mi 
pare di capire che tu non vuoi perdere soldi, ma senza spendere soldi :)
 
 
-- 
Massimiliano Adamo