Newsgroup: it.comp.os.linux.sys
Titolo: Sync DB MySQL

Ciao a tutti
 
  stavo cercando un modo scriptabile per sincronizzare in maniera 
intelligente delle tabelle su due DB MySQL senza usare la replica nativa 
di MySQL.
Le tabelle possono (anche se raramente) essere modificate nella loro 
struttura ed ovviamente i dati sono variabili.
La cosa vorrebbe essere una sorta di mysqldump blablabla | mysql 
blablabla fatta magari con un po' pi� di finezza.
 
Sapete se esiste qualcosa ready-to-use?
Grazie
 
Beppe

 blablabla fatta magari con un po' più di finezza.
 
Mysqldump non ti fa la replica in tempo reale e ti fa il lock delle 
tabelle .. quindi su DB grossi puoi avere dei problemi se lo scheduli di 
frequente.
 
Se non vuoi usare le repliche, puoi usare DRBD e sincronizzare la 
partizione di MYSQL.
 
-- Yena --
 

 partizione di MYSQL.
 
No no cercavo proprio qualcosa di scriptabile, DRDB � troppo per quel 
che mi serve. Considera che devono essere sincronizzate solo alcune tabelle
 
Grazie comunque :-)
 

 giorno ad esempio.
 
 
Se non mi sbaglio mysql offre la possibilita' di fare il log di tutte le 
operazioni eseguite.. basta poi applicare le stesse operazioni al 
secondo db.
Ciao diego

 giorno ad esempio.
 
Se la tabella ha una chiave primaria ed almeno un campo con la data
ultima modifica del record, basta un banale script sql.
 
In alternativa, sulle tabelle, nei trigger di insert/update/delete
scrivi il comando sql per fare la insert/update/delete sulla tabella
dall'altra parte.

 Ciao diego
 
Grazie ciao ciao
Beppe

 dall'altra parte.
 
Questo è un ottimo metodo e lo uso anche su tabelle federate, mi ha 
salvato il "bottom" insieme all'engine blackhole in un progetto dove 
dovevo replicare le insert da una a più tabelle :-) senza poter usare la 
replica di MySQL
 
Grazie mille per il brainstorming :-)
 

 Sapete se esiste qualcosa ready-to-use?
 
Brutale:
 
 - Sync del file system e del db;
 - Snapshot LVM;
 - Copia dei datafile da un server all'altro tramite rsync;
 - Rimozione dello snapshot.
 
Se hai tabelle MyISAM puoi farlo solo per la tabella impattata (non so come 
si comporta InnoDB con la direttiva one file per table attiva nel fare la 
stessa attivita`;
 
Enrico

  - Rimozione dello snapshot.
 
Brrrrrrr...

 stessa attivita`;
 
Purtroppo l'engine č InnoDB e anche se ho attivato la direttiva one file 
per table non mi sentirei di provare... Oltretutto il metodo che proponi 
ha un difetto, presuppone un down o un freeze del destinatario o sbaglio?
Grazie comunque a buon rendere (spero!)
 

 ha un difetto, presuppone un down o un freeze del destinatario o sbaglio?
 
Si, ma se ti interessa un sync non in tempo reale, allora non lo vedo un 
problema
 
Enrico

 problema
 
 
Forse ho omesso (anche) questo punto. Il DB di destinazione è live e 
deve rimanerci :-)
 
Grazie comunque

 Questo � anche un buon metodo di backup con l'aggiunta di un bel tar :-)
 
Ma ricordo male o avevano aggiunto anche su mysql un metodo umano di
fare il backup a caldo come ce l'hanno tutti i motori di database seri?

 fare il backup a caldo come ce l'hanno tutti i motori di database seri?
 
Mysqldump e` a caldo, ma non e` per nulla umano
 
Enrico
P.S. per inciso, mi piace far notare che di peggio ha fatto solo mongodb, 
mentre postgresql ha decisamente migliorato da questo punto di vista (non 
che prima facesse schifo, eh)

 deve rimanerci :-)
 
La tua e` una situazione decisamente strana, hai un db che dev'essere 
sincronizzato ad intervalli regolari con un altro db ma non puoi metterlo in 
down nemmeno per qualche minuto? A 'sto punto mi viene da dire che i dati 
contenuti nella tabella vengono usati per eseguire successive analisi da 
mostrare all'utente, ovvero il db di destinazione e` un datawarehouse. Se 
fosse cosi`, ti consiglio di mettere in piedi un ETL esterno, in modo da 
ottimizzare anche il passaggio dei dati da una macchina all'altra. Per fare 
cio`, puoi usare Talend o Pentaho, che sono veloci, o in alternativa uno 
script Python
 
Enrico
P.S. stai attento, fare un DW con MySQL puo` rivelarsi decisamente un calcio 
alle palle

Sapete se esiste qualcosa ready-to-use?
 
L'esigenza massima mi pare di aver capito sia di "isolare" il server primario
da qualsiasi sfiga, rallentamento e malocchio.
 
Una possibile soluzione e' quella di usare MySQL Proxy e inviare le query sia
al server principale (che non subisce rallentamenti, e non si accorge neanche
di nulla) sia, tutte tranne le SELECT pure, ad un secondo server. In mezzo ci
si dovra' mettere un ring buffer.
 
Questo secondo server B puo' essere il master di una coppia B-C.
 
In questo modo, il server A e' quello di produzione, B e' sincronizzato ad A,
e *DI SOLITO* C e' sincronizzato con B.
 
Quando ti servono i dati, per tuo uso esclusivo, sganci C da B (questo non ha
alcun effetto su A), lo massacri di OLAP, poi lo puoi anche razzare e, quando
hai finito, lo riattacchi. RESET MASTER/FLUSH TABLES READ LOCK/SHOW STATUS su
B, mysqldump verso C (nel frattempo il ring buffer mantiene lo stato verso B)
che e' stoppato, poi UNLOCK TABLES (B ritorna disponibile)/RESET SLAVE/CHANGE
MASTER/START SLAVE.
 
Costoso e farraginoso, ma se non puoi usare la replicazione...
 
Leonardo
 
-- 
 
Then felt I like some watcher of the skies, when a new planet swims into his ken;
Or like stout Cortez when with eagle eyes, he star'd at the Pacific; and all his men
Look'd at each other with a wild surmise - silent, upon a peak in Darien.