Spostamento di database in nuovi datacenter

La mia azienda sta spostando la nostra infrastruttura in un nuovo data center e sto cercando di capire il modo migliore per mantenere il database sul nuovo server sincronizzato con il database di produzione corrente fino a quando i nuovi ambienti non saranno pronti per essere pubblicati. Non essendo un DBA a tempo pieno, ho fatto qualche ricerca e da quello che ho letto, sembra che una configurazione di replica transnazionale soddisfi al meglio le nostre esigenze.

Alcuni dettagli: il DB di produzione ha una dimensione di circa 90 GB e usando Robocopy ci sono volute circa 9 ore per spostarne una copia su uno dei nuovi server. L'attuale database di produzione dovrà rimanere online e accessibile durante l'intero processo di migrazione. È in semplice recupero, quindi il mirroring del database non è disponibile.

Una replica transazionale è il metodo migliore per mantenere sincronizzati i database?

Il mio piano:

1. (Fine) Trasferire il database corrente e accedere al nuovo server e collegarlo alla nuova istanza di SQL Server
2. Installa un distributore sul nostro computer del database di sviluppo e pubblicalo dal database di produzione
3. Creare un abbonato sul nuovo computer di database che accetti gli aggiornamenti che vengono inviati dal distributore, una volta ogni notte

Ci sono due cose per la testa. La replica transazionale richiede che ogni tabella pubblicata abbia una chiave primaria e che molte tabelle nel database di produzione non abbiano chiavi primarie definite. Non penso che questo sarà un grosso problema poiché la mia preoccupazione principale è solo quella di sincronizzare i database. Testeremo le diverse applicazioni che utilizzano il database in un secondo momento, ma vorrei assicurarmi che non si tratti di un problema serio. In secondo luogo, devo spostare anche i DB di sistema associati dall'istanza originale, come master? Stiamo passando a una configurazione di Active Directory nel nuovo ambiente, quindi non mi interessano gli utenti e simili, ma non sono sicuro della necessità dei DB di sistema.

E proprio in generale, sto afferrando questi concetti correttamente?

La tua situazione attuale:

• Database da 90 GB che si desidera spostare in un nuovo data center.
• Il database è in semplice recupero.
• Stai pensando di utilizzare T-Rep per mantenere sincronizzati i dati.
• Esistono molte tabelle nel database che non dispongono di chiave primaria: questo è un requisito per qualsiasi tabella da pubblicare.
• Hai già un backup copiato nel data center di destinazione.

Vedo molti svantaggi nel tuo approccio:

• T-Rep non è facile da configurare rispetto ad altre tecnologie. Se sono presenti modifiche allo schema, è necessario un nuovo snapshot.
• Se si utilizza T-REP, è necessario apportare modifiche allo schema: aggiungere la chiave primaria alle tabelle che non sono disponibili.
• Apportando qualsiasi modifica al database esistente, l'applicazione deve essere completamente testata per evitare comportamenti imprevisti.
• Se il database presenta un numero elevato di transazioni e dipende dalla larghezza di banda della rete tra i 2 datacenter, ci sarà anche la latenza della replica.

Sulla base della mia esperienza, di seguito è la mia raccomandazione:

• Cambia il tuo database in pieno recupero. Questo non ha un grande impatto rispetto alla creazione di PK.
• Fornisci il backup completo del database di origine: esegui il backup con compressione e abilita l'inizializzazione istantanea dei file. Ciò ti aiuterà a ridurre i tempi di ripristino nel data center di destinazione.
• Ripristina database sul server di destinazione WITH NORECOVERY.
• Implementare Logshipping e inizializzarlo dal backup.
• Fare in modo che il log shipping spedisca i log ogni 1 minuto.
• Durante il giorno del failover, eseguire un ultimo backup del registro di coda sull'origine e ripristinarlo sulla destinazione utilizzando WITH RECOVERY. Questo porterà il database di destinazione online.
• Una volta che il database di destinazione è online, devi sincronizzare gli utenti .
• È necessario modificare web.config per puntarlo al nuovo server.

Non è necessario spostare alcun database di sistema. Assicurati di fare tutto il lavoro di preparazione prima di tutto - esegui lo scripting di accessi, lavori, pacchetti ssis, ecc. E creali sul server di destinazione.

Fare riferimento a questa risposta per i passaggi successivi al ripristino e altre best practice .

Nota: è anche possibile implementare il mirroring del database (SYNC o ASYNC a seconda dell'edizione del server sql che si sta utilizzando), ma il log shipping è solo semplice da implementare e se lo si verifica, non vi deluderà. Ho spostato con successo il database terabyte da un datacenter a un altro utilizzando la tecnica sopra e funziona perfettamente.

L'attuale database di produzione dovrà rimanere online e accessibile durante l'intero processo di migrazione.

Ci sarà sempre un tempo morto e devi programmarlo. Anche se investi pagando ingenti somme di denaro in soluzioni come il clustering, in caso di failover ci saranno dei tempi di inattività. Devi bilanciare quanto la tua azienda può investire in tempi di inattività quasi pari a zero rispetto a quelli disponibili con tempi di inattività accettabili.

Non ho avuto la possibilità di usarlo da solo e penso che sia ancora in anteprima, ma SQL Data Sync sulla piattaforma Azure potrebbe essere un'opzione potenziale:

https://azure.microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/

Funziona con database SQL di Azure e on-premise e sembra uno strumento utile per mantenere sincronizzati i database.