Cadere le partizioni storiche che non sono più richieste durante la replica P2P

Question

L'azienda che lavoro per ha un insieme di database (più grande appena sotto 1tb) su server diversi - 2 negli Stati Uniti, 2 in Europa.

Eseguiamo la replica completa peer-to-peer per database tra i 4 nodi - in modo che tutti possano prendere transazioni (inserimento / aggiornamento / eliminazione) e tutti hanno i dati che gli altri nodi sono stati raccolti (all'interno di una latenza variabile - peggiore La connessione è in media circa 30-40 secondi).

Il più grande database trasporta i dati all'inizio del 2008 a oggi. Tutti questi dati vengono ulteriormente replicati a segnalare i nodi che contengono tutti i dati.

Ho bisogno di rimuovere i dati sui nodi transazionali, fino al 2013, per rimuovere il deficit di spazio sull'unità ai nodi transazionali, e quindi i dati storici saranno disponibili solo nei nodi di reporting.

Qual è il modo migliore per farlo? I dati sono relativamente gestibili in quanto è ben partizionato (mensile - per partizione, e quindi annualmente in file / filegroup separati). Tuttavia, c'è il problema di non essere in grado di abbandonare le partizioni mentre sono coinvolti nella replicazione e la lettura sulla commutazione della partizione - questo non è consentito neanche questo. ( partizioni di commutazione Prerequisiti - Punto 18 )

Come ambiente di produzione completo che sto cercando di evitare tutto ciò che influenzerà la replica - compresa la risincronizzazione (molti dati da Resync, su grandi distanze).

Qualcuno ha buoni suggerimenti per come eseguire questo compito?

Answer 1

Quindi, nessuna risposta da qui, ma dopo una certa quantità di discussione e pensiero, ho inventato un piano alcuni mesi fa.

Farò conciso questa risposta per questo forum (potresti non essere d'accordo sul fatto che io abbia!), Per cercare di aiutare chiunque abbia bisogno di eseguire un compito simile in futuro, sentiti libero di fare domande se mi manca qualcosa - Anche se il metodo è diretto.

Quindi, la preoccupazione primaria è rimuovere i dati senza un impatto significativo sul traffico di produzione ai nodi che stiamo replicando / da. Il modo più semplice per farlo è separare un nodo che si desidera lavorare, rimuovendo i dati da quel nodo lasciando tutti gli altri inalterati (compresi i nodi di segnalazione).

Modo migliore per farlo (ricordare che non è possibile rilasciare le partizioni e qualsiasi / la maggior parte delle operazioni viene replicata e quindi creare una grande quantità di traffico e una grande quantità di modifiche a riga), è creare una nuova SP e configurazione di una pubblicazione intorno a questo sp. Dovrebbe quindi essere disponibile in tutti i nodi. Il bit importante è impostare la replica per replicare l'esecuzione della SP - non il risultato (I.e. Replicare la chiamata EXEG SP_Delete non è Elimina dove ID= 1, Elimina dove ID= 2 - Livello di riga). Questo è impostato fai clic con il tasto destro del mouse sulla nuova pubblicazione (prima di impostare gli altri nodi nella topologia)> Proprietà> Articoli> Fare clic su Sp_Delete Hai impostato> Pulsante Proprietà dell'articolo> Impostare le proprietà della procedura memorizzata evidenziata Articolo> Replicate Line= Esecuzione del Procedura memorizzata. Completa la tua topologia P2P.

Ma MHSQLDBA, potresti dire, che per eliminerà separatamente le righe in ogni nodo tramite la SP. - Questo è il motivo per cui hai impostato la SP per fare solo le delezioni:

Se @@ servername= 'Il server corrente che si desidera influire "

Seguilo con la tua procedura Elimina.

Pertanto, quando questa chiamata EXEC viene rilevata sul server (s) che non si desidera eseguire le eliminazioni, verrà ignorato come @@ ServerName non sarà uguale al server che hai selezionato.

Puoi pensare - perché non solo creare uno SP solo sul server a cui sei interessato e eseguito? - Questo perché se lo fai, la replica scomparirà le modifiche su come influenzano le righe dell'articolo (tabella) e replicheranno le modifiche effettive - è necessario replicare la SP in modo da poter specificare che l'exec della SP sia replicato piuttosto che i cambiamenti risultanti.

Questo è l'ordine suggerito degli eventi a mio avviso / esperienza:

.
1. Crea SP con codice di eliminazione che specifica che eseguirà solo il codice di eliminazione se @@ servername= il server desiderato
2. Impostare una nuova pubblicazione che replica questo 1 SP con la replica= esecuzione della procedura memorizzata all'interno delle proprietà dell'articolo
3. Esegui la SP al tuo server desiderato ed essere felice di non aver portato giù tutta la proprietà con migliaia di comandi di cancellazione replicati

Punti di nota:

.
1. Questo è ancora un compito laborioso. Usando questo metodo hai diminuito il tuo effetto su tutti i server a parte quello che stai lavorando. Non hai diminuito il carico di lavoro per te, infatti hai fatto peggiore - dovrai correre questo stesso SP in ogni nodo (con la linea IF modificata nel server che stai prendendo di mira), aumentando efficacemente il lavoro che hai Per fare, dal numero di server che devi influenzare. E 'molto più sicuro anche se avrai un effetto minimo su tutti gli altri nodi (presumo che tu abbia fallito il traffico dal nodo che stai lavorando ovviamente!)
2. Utilizzando questo metodo, hai creato incoerenza tra i tuoi nodi - è davvero necessario essere sicuri che i dati che stai rimuovendo non cambino prima di poter finire di eseguire la stessa operazione su tutti i nodi che richiedono il lavoro. Se una riga che hai eliminato a 1 nodo viene modificato nel resto della proprietà, si terrà con errori di coerenza.
3. PRESARE PRESARE LA TUA NORMA NORMALE REPLICAZIONE PREVISTA DI SLA Dietro dalla quantità di tempo che serve per eseguire le elimine al nodo che stai lavorando (consiglio vivamente di leggere su Duty the Deletes) - Pertanto è necessario Per essere consapevoli del fatto che una volta completata l'operazione, non avrai indietro il nodo in azione fino a quando la normale replica è stata presa il backup dopo il rilascio dei blocchi di Elimina operazione. Se si sta replicando su elevate linee di latenza, ti suggerisco seriamente di controllare utilizzando gli agenti di tiro anziché premere - fa una differenza umida.

C'è probabilmente un modo migliore per spostare i dati nella SP rispetto all'utilizzo dell'eliminazione - magari spostarlo su un'altra tabella che non è coinvolto nella replica e quindi rilasciando la tabella "nuova" - o il contrario, se i dati Vuoi mantenere è inferiore alla quantità da eliminare, sposta i dati che vuoi tenere a una nuova tabella, rilascia il vecchio, quindi rinominare la tua nuova tabella - c'è un sacco di consigli là fuori da queste prospettive - lavoro in un ambiente in cui Era più facile combattere per la cancellazione che promuovere un concetto che

Qualche personale non capirà, quindi sto descrivendo il modo doloroso ma fondamentale.

Disclaimer: tutto quanto sopra è pericoloso.Se fatto in fretta senza opportuno pretendere, puoi seriamente rovinare una topologia di replica, i dati della tua azienda e probabilmente il tuo impiego.Si prega di prendere il metodo di cui sopra e sviluppare il proprio battleplan - Creare un ambiente di prova per dimostrare il concetto, il test del test e il ripetere, non prendere leggermente questa attività.Con una considerazione sufficiente otterrete il tuo compito - ma non vale la pena fare il venerdì pomeriggio dopo un paio di birre di pranzo.Fallo bene, fallo una volta (per il test reale il più possibile), fallo correttamente.

Spero che questo aiuti qualcun altro.- Sto aggiungendo questo bit come è quello che avrei cercato se volessi questa risposta:

Elimina una grande quantità di dati da una topologia di replica peer-to-peer