Replica di un database MySQL remoto su MS SQL Server 2008

Voglio replicare il contenuto di un database MySQL in un database MS SQL Server 2008.

È possibile? Qualcuno può delineare i passaggi necessari per raggiungere questo obiettivo?

Grazie.

Personalmente attingerei al metodo MS SQL rispetto alla spinta dal metodo MySQL. Perché? Bene, Windows ha driver ODBC MySQL a 32 e 64 bit pronti all'uso e la configurazione di un server collegato è banale. Ho molti server MySQL collegati da MS SQL. Inoltre, connettersi a MS SQL da Linux / Unix non è sempre eccezionale e di solito non si è in grado di utilizzare tutte le funzionalità. FreeTDS ha dei limiti; potresti colpirli prima o poi, quindi perché non saltarli. Tutto questo presuppone che tu stia eseguendo MySQL su * nix. In caso contrario, si avvicina un po 'di più a 50/50 ma sceglierei comunque di estrarre da MS SQL in quanto sembra che non sia il database "live", quindi caricare il carico su qualsiasi ETL o l'elaborazione è più ideale. La soluzione GoldenGate sembra interessante, ma sono sicuro che non è gratuita.

Considerando che ho impostato questo tipo di scenario con database MySQL e Oracle replicati in MS SQL, fornirò alcuni suggerimenti che hanno funzionato meglio per me:

1. Se puoi, fai del tuo meglio per determinare come assicurarti di apportare solo modifiche delta. I comandi di unione possono aiutare in questo. Troncare una tabella e quindi reinserirla di nuovo gonfia il registro, utilizza la larghezza di banda della rete e, in genere, fa perdere tempo.
2. Se hai a che fare con molti dati assicurati di interrompere le transazioni in modo da non richiedere un file di registro di massa. Usa commit espliciti o checkpoint quando hai raggiunto un passaggio da cui sai di non dover tornare indietro.
3. Se il db MSSQL sarà solo per la creazione di report, ETL funziona lì per non influire sul server MySQL. Utilizzare un database di gestione temporanea o uno schema + filegroup per semplificare le cose.
4. Suddividere l'importazione dei dati in passaggi. Ciò semplifica il riavvio dell'importazione in caso di errore e / o risoluzione dei problemi. Un approccio tutto o niente diventa fastidioso rapidamente.
5. Utilizzare le variabili ove possibile per aiutare il db remoto con piani di query e utilizzo dell'indice. Prestare inoltre attenzione al tipo di isolamento della transazione in cui ci si trova nella casella host e all'impatto che avranno le query di "replica". Non si desidera bloccare i writer su un db live se si stanno semplicemente recuperando dati per l'utilizzo di report o sandbox.

Spero che i suggerimenti siano d'aiuto!

La stessa domanda è stata posta su StackOverflow qui: replica da MySQL a MSSQL .

Sembra che ci siano alcune soluzioni alternative, ma non una soluzione molto semplice.

Credo che dovresti assolutamente provare a creare un pacchetto SSIS per importare i dati necessari da MySQL DB a MSSQL DB. SSIS consente di importare dati da varie fonti. Quindi dovresti essere in grado di pianificare il pacchetto usando l'utilità di pianificazione di Windows o i lavori sql.

Se per replica intendi la spedizione dei log o qualcosa del genere, credo che tu sia sfortunato. Tuttavia, puoi certamente impostare un database MySQL come server collegato e creare il tuo schema di replica. La cosa più semplice è solo fare istantanee periodiche di tutte le tabelle usando le istruzioni truncate e insert. Aggiungi complessità secondo le tue esigenze.

A tale scopo, puoi utilizzare GoldenGate per MySQL e MS SQL . Dovresti semplicemente installare il prodotto GoldenGate su ciascun lato, quindi procedere come per una replica omogenea.

In alternativa, per una replica "snapshot", è possibile utilizzare uno script Python (o simile) per connettersi semplicemente a entrambe le origini dati (utilizzando UnixODBC e FreeTDS per connettersi a MS SQL), scorrere le tabelle eseguendo SELECTsu un lato, per ogni riga INSERTdall'altra. Poiché MSSQL ha transazioni ed è il tuo obiettivo, puoi avviare una transazione, DELETEtutto da tutte le tabelle, fare la copia, quindi COMMITe apparirà istantaneamente per quanto riguarda gli utenti connessi sulla destinazione, non ci saranno incoerenze (a meno che non esistano sulla fonte ovviamente).