sincronizzazione tra database

[nomorelogic]

ciao a tutti

ho una necessità che è quella di sincronizzare 2 database (MsSql o Postgres o altro) remoti.
La replicazione è di tipo Master/Slave ma, per qualche tabella, è lo Slave che diventa Master.

In quanto DB remoti tra di loro, la sincronizzazione dovrebbe avvenire tramite protocollo TCP.
La particolarità è che le lo schema delle tabelle dei 2 RDBMS può essere diverso e che ci potrebbero essere da sincronizzare anche 1.000.000 di record per 4 o 5 tabelle su un totale di 50 o 60 tabelle.
Dopo la prima sincronizzazione, servirebbe una sincronizzazione differenziale da lanciare tipo ogni 5 minuti per il riallineamento.

Scenario abbastanza complesso insomma.
Qualcuno di voi ha qualche consiglio su tool esistenti che potrebbero essermi utili?

Grazie

nomorelogic

[DragoRosso]

Cioè hai:

- 2 database (speriamo almeno della stessa famiglia) remoti,
- tabelle con schemi diversi,
- 5 tabelle da sincronizzare su 60 presenti nei database,
- intervallo di tempo di cinque minuti per un totale plausibile di 1.000.000 di record,
- il tutto via TCP/IP;

Bhe dai, provo un attimo a chiamare la fata turchina, magari con la bacchetta magica risolve la situazione ... 

A parte gli scherzi non ho idea di tool che possano fare simili cose (però non sono un professionista del settore). Almeno non di tool a portata di noi poveri mortali, magari Oracle piuttosto che IBM li hanno.

Un differenziale di 1 milione di record ogni 5 minuti non è cosa proprio così normale, sopratutto se parliamo in termini differenziali ....

Se trovi qualcosa o escogiti una soluzione fai un rimando anche qui, è sempre e comunque interessante analizzare soluzioni nuove.

Ciao e auguri.

[nomorelogic]

mi sono spiegato male

le tabelle potenzialmente con 1.000.000 record sono 4 o 5
50 o 60 sono tutte le tabelle che devo sincronizzare

cmq i database non sono della stessa famiglia

ho dato un'occhiata a qualche ETL tipo penthao kettle ma non ho molta esperienza con questi strumenti

ho paura che per dare una mano alla fata turchina, tocca chiamare Gandalf (il bianco) con Mago Merlino e Maga Magò...

vi tengo aggiornati
ma se avete idee dite pure

[nomorelogic]

vabbè comunque quella era una valutazione pessimistica, bisogna prevedere il futuro

la situazione attuale è
- 3 tabelle con circa 600.000 record
- 40 tabelle da sincronizzare
- aggiornamento va bene anche ogni 10 minuti

in realtà non è che cambi poi molto   

[DragoRosso]

Avevo dato una occhiata a strumenti ETL, però legati diciamo alla "programmazione" in generale (nè ho accennato in un altro topic). Sono strumenti generalmente costosi e complessi, oltre a necessitare di una infrastuttura "importante".

Nel passato, sulla replica dei database ho sempre lasciato fare ad altri, semplicemente (tra virgolette  ) acquisendo il "già fatto". Ci sono moltepli problematiche nel fare quelle operazioni, e sono sopratutto legate alla coerenza poi dei dati trasferiti: è molto improbabile che si possano "travasare" tutti quei dati in una singola transazione, da qui le possibili incongruenze.

Se poi non sono strumenti propri del motore RDB (tipo funzioni di replica), allora tanti auguri.
Se senti Gandalf digli se mi manda Arwen, che ho un dolorino alla spalla ...... 

Ciao ciao.

[nomorelogic]

si avevo visto il tuo accenno agli ETL, sono un mondo a parte è vero

con la replicazione ho una esperienza con IBReplicator per Firebird e con la replicazione di MsSql ma tutti e 2 replicano verso un DB dello stesso tipo e tutti e 2 con sistema a log.
A me servono DB diversi ed inoltre la replicazione tramite log, che ha il pregio di essere veloce, ha il difetto che se un client non si connette per un po' di tempo... il log del DB master riempie il disco del server...

[DragoRosso]

Ai miei tempi il log non era totalmente affidabile per diversi motivi (non stò qui a spiegarli). A seconda del meccanismo di "elaborazione", si potevano avere dei conflitti nelle transaction e quindi disallineamento tra i DB replicati.

MSSql ha un suo meccanismo interno di replica e si basa su un doppio server DB, quello Master (chiamato mi pare di "Pubblicazione") e quello replicato chiamato di "Distribuzione". Da qui poi si possono avere "n" server di BACKUP (chiamiamoli così) che nel linguaggio Microsoft vengono chiamati "Sottoscrittori".

La tecnica è basata sul LOG delle transazioni (del server di Pubblicazione), e da due agenti (di fatto dei servizi) che si occupano di alimentare il DB di Distribuzione e gli eventuali DB di Sottoscrizione.

La tecnica funziona ed è uno standard ormai decennale.

Implementando tale tecnica potrebbe essere possibile fare ciò che chiedi. Ovviamente ci dovrà essere una transcodifica per allineare i campi e le tabelle con schemi diversi rispetto al DB Master.

A me servono DB diversi ed inoltre la replicazione tramite log, che ha il pregio di essere veloce, ha il difetto che se un client non si connette per un po' di tempo... il log del DB master riempie il disco del server...

Di questo non avevo notizia ..... probabilmente è un baco inserito apposta dai costruttori di Hard Disk per vender più device .... 

Ciao

[bonmario]

ho dato un'occhiata a qualche ETL tipo penthao kettle ma non ho molta esperienza con questi strumenti

L'ho usato parecchio tempo fa, e non mi ci ero trovato bene ...
Tra l'altro se non sbaglio, è anche stato dismesso.

Ciao, Mario

[nomorelogic]

A me servono DB diversi ed inoltre la replicazione tramite log, che ha il pregio di essere veloce, ha il difetto che se un client non si connette per un po' di tempo... il log del DB master riempie il disco del server...

Di questo non avevo notizia ..... probabilmente è un baco inserito apposta dai costruttori di Hard Disk per vender più device .... 

E' successo che un ns cliente aveva una replicazione con MsSql su una sede distaccata.
Il log lo tiene il server per ogni slave sottoscrittore finché il sottoscrittore non si collega e lo scarica per applicare le transazioni per se stesso.

Fatto sta che un giorno dismettono il server sulla sede distaccata dove stava il sottoscrittore ma non ci dicono nulla...
Il server master ha incrementato i log fino a saturare l'HD.

Senza contare che il sistema dei log si basa sul fatto che, dopo la sincronizzazione iniziale, lo slave non abbia alterato i record per conto suo.
Nel qual caso si verifica il disallineamento.

[nomorelogic]

ho dato un'occhiata a qualche ETL tipo penthao kettle ma non ho molta esperienza con questi strumenti

L'ho usato parecchio tempo fa, e non mi ci ero trovato bene ...
Tra l'altro se non sbaglio, è anche stato dismesso.

Ciao, Mario

bene...
almeno guardo qualcos'altro

[DragoRosso]

E' successo che un ns cliente aveva una replicazione con MsSql su una sede distaccata.
Il log lo tiene il server per ogni slave sottoscrittore finché il sottoscrittore non si collega e lo scarica per applicare le transazioni per se stesso.

Fatto sta che un giorno dismettono il server sulla sede distaccata dove stava il sottoscrittore ma non ci dicono nulla...
Il server master ha incrementato i log fino a saturare l'HD.

A questo si può ovviare monitorando lo spazio su disco, o ancora meglio le "frequenze" di connessione ....
Io quando ho qualcosa (anche di terze parti come un DB un Datat Logger o altro) che scrive su disco inserisco sempre un monitoraggio, non si sà mai ....

Senza contare che il sistema dei log si basa sul fatto che, dopo la sincronizzazione iniziale, lo slave non abbia alterato i record per conto suo.
Nel qual caso si verifica il disallineamento.

Bhè questa è storia. I DB replicati vengono usati per backup o per visualizzazioni o ricerche, non certo per lavorarci sopra  .

Però effettivamente, direi che usando un tool che legge i log del DB Master, eseguire una replica su un database diverso non dovrebbe essere estremamente complesso (fatto salvo la transcodifica ....). Quello che vedo apparentemente più complesso è tutta l'elaborazione di milioni di record in un tempo relativamente "stretto" e tramite TCP/IP.

Anche ammettendo di fare un trasferimento di 10K record al secondo, per 10kk record servono 1000 secondi, oltre 15 minuti.
Poi magari mi sbaglio nelle prestazioni, magari si riescono a traferire 1kk record al secondo o anche più.

Ciao ciao.

[DragoRosso]

Questi sono dei tools a pagamento per maneggiare il log di un MSSQL:

https://www.apexsql.com/

https://www.quest.com/products/toad-for-sql-server/

Ciao

[nomorelogic]

E' successo che un ns cliente aveva una replicazione con MsSql su una sede distaccata.
Il log lo tiene il server per ogni slave sottoscrittore finché il sottoscrittore non si collega e lo scarica per applicare le transazioni per se stesso.

Fatto sta che un giorno dismettono il server sulla sede distaccata dove stava il sottoscrittore ma non ci dicono nulla...
Il server master ha incrementato i log fino a saturare l'HD.

A questo si può ovviare monitorando lo spazio su disco, o ancora meglio le "frequenze" di connessione ....
Io quando ho qualcosa (anche di terze parti come un DB un Datat Logger o altro) che scrive su disco inserisco sempre un monitoraggio, non si sà mai ....

Senza contare che il sistema dei log si basa sul fatto che, dopo la sincronizzazione iniziale, lo slave non abbia alterato i record per conto suo.
Nel qual caso si verifica il disallineamento.

Bhè questa è storia. I DB replicati vengono usati per backup o per visualizzazioni o ricerche, non certo per lavorarci sopra  .

Però effettivamente, direi che usando un tool che legge i log del DB Master, eseguire una replica su un database diverso non dovrebbe essere estremamente complesso (fatto salvo la transcodifica ....). Quello che vedo apparentemente più complesso è tutta l'elaborazione di milioni di record in un tempo relativamente "stretto" e tramite TCP/IP.

Anche ammettendo di fare un trasferimento di 10K record al secondo, per 10kk record servono 1000 secondi, oltre 15 minuti.
Poi magari mi sbaglio nelle prestazioni, magari si riescono a traferire 1kk record al secondo o anche più.

Ciao ciao.

chiaramente non conta la prima volta ma le differenziali