Schema per l'aggiornamento dei database slave SQL Server 2008 da un master, riducendo al minimo le interruzioni

Question

Abbiamo un'applicazione web ASP.NET ospitata da una web farm di molte istanze che utilizzano SQL Server 2008 in cui eseguiamo aggregazione e pre-elaborazione di dati da più origini in un formato ottimizzato per prestazioni veloci delle query degli utenti finali (producendo 5 -10 milioni di righe in alcune tabelle). L'aggregazione e l'ottimizzazione vengono eseguite da un servizio su un server back-end che vogliamo quindi distribuire a più copie di sola lettura front-end utilizzate dalle istanze dell'applicazione Web per facilitare la massima scalabilità.

La mia domanda riguarda il modo migliore per ottenere questi dati da un database back-end alle copie front-end di sola lettura in modo tale da non comprometterne le prestazioni durante il processo. Le istanze delle applicazioni Web front-end saranno sottoposte a carico elevato costante e dovranno avere una buona reattività in ogni momento.

Il database back-end viene costantemente aggiornato, quindi sospetto che la replica transazionale non sia l'approccio migliore, poiché il flusso costante di aggiornamenti alle copie ne pregiudicherà le prestazioni.

La staleness dei dati non è un grosso problema, quindi la replica dell'istantanea potrebbe essere la strada da percorrere, ma ciò comporterà prestazioni scadenti durante i periodi di replica.

Eseguendo un drop e l'inserimento in blocco comporteranno periodi senza dati per le query degli utenti.

Non voglio davvero scrivere un approccio al cluster complesso in cui eliminiamo le copie dal cluster durante l'aggiornamento: esiste qualcosa in tal senso che possiamo fare senza troppi sforzi o esiste un'alternativa migliore?

Answer 1

In realtà esiste una tecnologia integrata in SQL Server 2005 (e 2008) progettata per risolvere questo tipo di problemi. Service Broker (fare riferimento più avanti come SSB). Il problema è che ha una curva di apprendimento molto ripida.

So che MySpace è diventato pubblico come usa SSB per gestire il proprio parco di server SQL: MySpace utilizza il broker di servizi SQL Server per proteggere l'integrità di 1 petabyte di dati . Conosco molti altri siti (principali) che usano schemi simili ma sfortunatamente non sono diventati pubblici, quindi non posso fare riferimento a nomi. Sono stato coinvolto personalmente in alcuni progetti relativi a questa tecnologia (sono un ex membro del team di SQL Server).

Ora tieni presente che SSB non è una tecnologia di trasferimento dati dedicata come la replica. Di conseguenza, non troverai nulla di simile alle procedure guidate di pubblicazione e alle semplici opzioni di distribuzione di Replication (controlla una tabella e viene trasferita). SSB è una tecnologia di messaggistica affidabile e come tale le sue primitive si fermano a livello di scambio di messaggi, dovresti scrivere il codice che sfrutta acquisizione della modifica dei dati , li comprime come messaggi e anche scompattando il messaggio in tabelle relazionali a destinazione.

Perché alcune aziende preferiscono SSB alla replica in un'attività come la descrivi è perché SSB ha una storia molto migliore quando si tratta di affidabilità e scalabilità. Conosco progetti che scambiano dati tra oltre 1500 siti, ben oltre le capacità di replica. Anche SSB viene estratto dalla topologia fisica: è possibile spostare database, rinominare i computer, ricostruire i server senza modificare l'applicazione. Perché il flusso di dati si verifica su route logiche l'applicazione può aggiungere al volo nuove topologie. SSB resiste anche a lunghi periodi di disinserimento e downtime, essendo in grado di riprendere il flusso di dati dopo ore, giorni e persino mesi di disconnessione. L'elevata produttività ottenuta dall'integrazione del motore (SSB fa parte del motore SQL stesso, non è una raccolta di applicazioni e processi satellitari come la replica) significa che l'arretrato di modifiche può essere un processo in tempi ragionevoli (conosco i siti che stanno attraversando la metà un milione transazioni al minuto). Le applicazioni SSB in genere si basano su Attivazione interna per elaborare i dati in entrata. SSB ha anche alcune caratteristiche uniche come bilanciamento del carico (tramite route) con semantica di sessione appiccicosa, supporto per elaborazione correlata specifica per l'applicazione gratuita deadlock , consegna priorità , supporto specifico per il mirroring del database, autenticazione basata su certificato per operazioni tra domini, integrata timer persistenti e molti altri.

Questa non è una risposta specifica 'come spostare i dati dalla tabella T sul server A al server B'. È più una tecnologia generica su come "scambiare dati tra il server A e il server B".

Answer 2

Non ho mai avuto a che fare con questo scenario prima, ma ho trovato una possibile soluzione per questo. Fondamentalmente, richiederebbe una modifica nella struttura del database principale. Invece di archiviare i dati, dovresti tenere un registro delle modifiche di questi dati. Pertanto, se viene aggiunto un record, memorizzi " Tabella X, inserisci un nuovo record con questi valori: ... " Con le modifiche, è sufficiente memorizzare la tabella, il campo e il valore modificato. Con le eliminazioni, è sufficiente memorizzare il record che viene eliminato. Ogni modifica verrà memorizzata con un timestamp.

I sistemi client manterrebbero le loro copie locali del database e chiederanno regolarmente tutte le modifiche al database dopo una certa data / ora. Quindi si eseguono tali modifiche sul database locale e sarà nuovamente aggiornato.

E il back-end? Bene, manterrebbe solo un elenco di modifiche e forse una tabella con i dati di base. Mantenere solo le modifiche significa anche tenere traccia della cronologia, consentendoti di chiedere al sistema come era un anno fa.

Il livello di efficacia di ciò dipende dal numero di modifiche nel database back-end. Ma se richiedi le modifiche ogni 15 minuti, non dovrebbero essere sempre tanti dati.

Ma ancora una volta, non ho mai avuto la possibilità di risolverlo in una vera applicazione, quindi è ancora un principio teorico per me. Sembra veloce ma molto lavoro sarà richiesto.

Answer 3

Opzione 1 : scrivi un'app per trasferire i dati utilizzando transazioni a livello di riga. Potrebbe richiedere più tempo ma non comporterebbe l'interruzione del sito utilizzando i dati perché le righe sono presenti prima e dopo la lettura, solo con nuovi dati. Questa elaborazione avverrebbe su un server separato per ridurre al minimo il carico.

In sql server 2008 è possibile impostare READ_COMMITTED_SNAPSHOT su ON per assicurarsi che la riga in fase di aggiornamento non causi il blocco.

Ma sostanzialmente questa app non fa altro che leggere i nuovi dati in quanto sono disponibili da un database e nell'altro.

Opzione 2 : sposta i dati (tabelle o intero database) dal server di aggregazione al server front-end. Automatizza questo se possibile. Quindi passare all'applicazione Web in modo che punti al nuovo database o alle tabelle per richieste future. Funziona ma richiede il controllo dell'app Web, che potresti non avere.

Opzione 3 : se stavi parlando di un singolo tavolo (o questo potrebbe funzionare con molti) ciò che puoi fare è uno scambio di vista. Quindi scrivi il tuo codice su una vista sql che punta alla tabella A. Lavori sulla tabella B e quando è pronto aggiorni la vista per puntare alla tabella B. Puoi anche scrivere una funzione che determina la tabella attiva e automatizzare l'intera cosa di scambio.

Opzione 4 : potresti essere in grado di utilizzare qualcosa come la replica a livello di byte del server. Sembra spaventoso però. Che in pratica sta copiando il server dal punto A al punto B esattamente fino ai byte stessi. Viene utilizzato principalmente in situazioni di DR che sembra che potrebbe essere una sorta di situazione di DR, ma non proprio.

Opzione 5 : rinuncia e impara a vendere l'assicurazione. :)