Sync DB MySQL

[Beppe]

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

[Yena]

Il 16/09/2013 10:41, Beppe ha scritto:
> 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.

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 --

[Beppe]

On 16/09/2013 12:20, Yena wrote:
>
> 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.

Bhe il mio problema non � fare la replica in real-time (in effetti avevo
omesso questo punto) dovrei sincronizzare alcune tabelle un volta al
giorno ad esempio.

> Se non vuoi usare le repliche, puoi usare DRBD e sincronizzare la
> 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 :-)

[Diego x80]

Il 16/09/2013 14:16, Beppe ha scritto:
> On 16/09/2013 12:20, Yena wrote:
>>
>> 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.
>

> Bhe il mio problema non è fare la replica in real-time (in effetti avevo

> omesso questo punto) dovrei sincronizzare alcune tabelle un volta al
> 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

[Sam]

On 16/09/2013 14:16, Beppe wrote:
> On 16/09/2013 12:20, Yena wrote:
>>
>> 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.
>
> Bhe il mio problema non � fare la replica in real-time (in effetti avevo
> omesso questo punto) dovrei sincronizzare alcune tabelle un volta al
> 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.

[Beppe]

On 16/09/2013 18:09, Diego x80 wrote:
>
> 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.

Potrebbe essere una possibilit�, ma diventa parecchio dispersivo visto
che vengono fatte molte update sugli stessi record, vero � che si pu�
sempre prendere l'ultimo update fatto ogni signolo record ma a quel
punto se dovessi scrivere io il codice da zero (cos� come accadr� mi sa'
:-) ) ci impiegherei una vita e di sicuro non ottimizzerei molto.
Grazie comunque per l'idea


> Ciao diego

Grazie ciao ciao
Beppe

[Beppe]

On 16/09/2013 21:55, Sam wrote:
> On 16/09/2013 14:16, Beppe wrote:


> Se la tabella ha una chiave primaria ed almeno un campo con la data
> ultima modifica del record, basta un banale script sql.

Alla fine credo procederò facendomi uno script SQL e via

> 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.

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 :-)

[Enrico 'Henryx' Bianchi]

Beppe wrote:

> 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

[Sam]

On 19/09/2013 21:02, Enrico 'Henryx' Bianchi wrote:
> Beppe wrote:
>
>> 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.

Brrrrrrr...

[Beppe]

On 19/09/2013 21:02, Enrico 'Henryx' Bianchi wrote:

> Brutale:
>
> - Sync del file system e del db;
> - Snapshot LVM;
> - Copia dei datafile da un server all'altro tramite rsync;
> - Rimozione dello snapshot.
>

Questo č anche un buon metodo di backup con l'aggiunta di un bel tar :-)

> 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`;

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!)

[Enrico 'Henryx' Bianchi]

Beppe wrote:

> Oltretutto il metodo che proponi
> 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

[Beppe]

On 22/09/2013 16:54, Enrico 'Henryx' Bianchi wrote:

> Si, ma se ti interessa un sync non in tempo reale, allora non lo vedo un
> problema

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

Grazie comunque

[Sam]

On 20/09/2013 09:48, Beppe wrote:
> On 19/09/2013 21:02, Enrico 'Henryx' Bianchi wrote:
>
>> Brutale:
>>
>> - Sync del file system e del db;
>> - Snapshot LVM;
>> - Copia dei datafile da un server all'altro tramite rsync;
>> - Rimozione dello snapshot.
>>
>

> 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?

[Enrico 'Henryx' Bianchi]

Sam wrote:

> 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?

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)

[Enrico 'Henryx' Bianchi]

Beppe wrote:

> Forse ho omesso (anche) questo punto. Il DB di destinazione è live e
> 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

[Leonardo Serni]

On Mon, 16 Sep 2013 10:41:33 +0200, Beppe <be...@fakemail.com> wrote:

>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?

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.