Introduzione alla replica

  • Articolo

Di Andrea Benedetti - Microsoft MVP

Spesso, gestendo informazioni, si ha la necessità di distribuire dati (o parte di essi), metterli a disposizione ad utenti e/o applicazioni distanti tra loro o mantenere copie aggiornate per soluzioni di disaster recovery / fault tolerance.

SQL Server fornisce diversi strumenti per rispondere a queste esigenze: clustering, log shipping, database mirroring, linked server, transazioni distribuite, integration services, backup / restore, replica…

In questo articolo ci soffermeremo sulla replica, introducendo le varie tipologie a disposizione, valutando cosa potrebbe essere meglio utilizzare nei vari scenari e presentando alcune delle novità che la nuova versione di SQL Server ha portato.

In questa pagina

Introduzione Introduzione
Gli attori in scena Gli attori in scena
Tipolgie disponibili Tipolgie disponibili
Le novità di SQL Server 2005 Le novità di SQL Server 2005

Introduzione

La replica viene utilizzata frequentemente in applicazioni in cui viene richiesto il consolidamento di dati da uno o più database distinti in un unico server (esempio classico: sedi periferiche – sede centrale), oppure in ambienti dove è necessario sincronizzare i dati dopo aver effettuato operazioni su di essi (venditore in visita al cliente – sincronizzazione serale con l’ufficio centrale).

Uno scenario di replica può anche essere scelto per migliorare performance di lettura dei nostri dati (si pensi, ad esempio, ad ambienti di reportistica ed analisi) spostando il carico di molti utenti da un unico server a più macchine (2000 utenti su un unico server sono sicuramente un carico maggiore di 500 utenti su quattro differenti macchine).

La replica può essere utilizzata per consolidare dati centralmente o per replicare dati da un SQL Server ad un altro, oppure verso SQL CE (la versione mobile di SQL Server), o ancora verso altri RDBMS.

 

Gli attori in scena

In uno scenario di replica entrano in gioco diversi soggetti. Vediamo di capire chi sono e quale sia il loro ruolo:

  • Pubblicatore: è il server sorgente, ovvero chi ha i dati e li mette a disposizione

  • Articolo: è l’unità pubblicata. Può essere una tabella (per intero, soltanto alcune colonne, soltanto alcune righe), una stored procedure (T-SQL o SQLCLR), una vista, …

  • Pubblicazione: è l’insieme degli articoli pubblicati

  • Sottoscrittore: è colui che sottoscrive e che riceve schema e dati dal pubblicatore

  • Distributore: è un SQL Server che ha il compito di distribuire i dati, gli schema, le transazioni dal pubblicatore al sottoscrittore. Spesso il pubblicatore ed il distributore coincidono (sono la stessa macchina). Cuore del distributore è il database “distribution” che contiene, al suo interno, tutte le informazioni relative alla storia della replica: chi ha preso cosa / quando / cosa devo dare, …

Se volessi utilizzare il paradigma dell’edicola potremmo dire che:

  • Pubblicatore: è la casa editrice, che mette a disposizione le notizie

  • Articolo: come in un giornale, è l’insieme delle notizie rese note

  • Pubblicazione: è il giornale stesso, l’insieme degli articoli

  • Sottoscrittore: chi vuole leggere il giornale e quindi “recepire” tutti gli articoli di quella data pubblicazione.

  • Distributor: è l’edicola

Possiamo definire una pubblicazione, come avviene con le pubblicazioni reali, in modo che sia il sottoscrittore a venire in edicola a prenderla: modalità PULL; oppure che sia la pubblicazione stessa a raggiungere il sottoscrittore (come con un abbonamento ricevo nella mia cassetta delle lettere il magazine preferito): modalità PUSH.

Entrambe le possibilità offrono dei pro e dei contro, in generale è consigliabile utilizzare una modalità PUSH quando:

  • Si ha un piccolo numero di sottoscrittori

  • Si vuole un unico punto centrale di amministrazione

  • Si replica attraverso LAN o WAN

Mentre è preferibile una modalità PULL quando:

  • Si ha un alto numero di sottoscrittori

  • Posso avere sottoscrittori anonimi

  • Non ho la necessità di un unico punto di amministrazione

SQL Server offre, nativamente, diverse tipologie di replica per differenti scenari e necessità.

Vediamo di analizzarle nel dettaglio.

 

Tipolgie disponibili

Tre sono le tipologie di replica disponibili:

  • snapshot: è come un’istantanea, distribuisce i dati così come appaiono in determinato momento

  • transazionale: modifiche ai dati vengono applicate al Sottoscrittore nello stesso ordine e negli stessi limiti della transazione con cui vengono eseguite nel server di pubblicazione

  • merge: modifiche dei dati e dello schema apportate successivamente nel server di pubblicazione e nei Sottoscrittori vengono rilevate tramite trigger. Consente di lavorare a tutti i db in modo autonomo ed unire gli aggiornamenti gestendo eventuali conflitti (lo stesso record aggiornato da più parti)

La replica Snapshot è, quindi, un point in time, una fotografia istantanea, dei dati che viene utilizzata da tutte le altre tipologie per generare l’allineamento iniziale.

Questa tipologia è indicata in tutti quegli scenari in cui abbiamo molti dati che vengono modificati in un’unica volta ed in maniera poco frequente.

La replica Transazionale utilizza il transaction log per generare le transazioni da replicare ai sottoscrittori.

I tempi di latenza che possiamo avere con la replica snapshot, dove il sottoscrittore si trova sincronizzato solo quando riceve uno snapshot, sono tipicamente molto alti.

Nella transazionale invece, dove le modifiche vengono continuamente inviate ed applicate al sottoscrittore, sono assolutamente molto più bassi.

La replica transazionale è costituita da tre componenti:

  • snapshot agent: genera lo schema degli oggetti da replicare, i dati e tutte le informazioni necessarie a tracciare il processo di replica. Questo agent è lo stesso per tutte le tre tipologie di replica (condiviso)

  • distribution agent: distribuisce gli snapshot inziali e tutti i comandi successivi ai sottoscrittori

  • log reader: legge le transazioni marcate per la replica all’interno del transaction log e copia le transazioni nel database di distribuzione (distribution)

La replica merge è stata pensata per tutti quegli scenari in cui i client sono frequentemente offline.

Lavorando tramite trigger che vengono aggiunti in tutte le tabelle coinvolte nella replica e tramite colonne GUID (global unique identifier) in grado di identificare univocamente qualsiasi riga proveniente da qualsiasi tabella di qualsiasi database, consente di lavorare allo stesso modo su entrambi i database (pubblicatore e sottoscrittore) e di effettuare la sincronizzazione dei dati (l’operazione di merge).

Le principali caratteristiche della merge replication sono:

  • possibilità di tracciare i cambiamenti

  • possibilità di risolvere (e tracciare in un log) i conflitti

utilizzo di poche risorse e poca banda

*

Quando viene effettuata una modifica, questa viene registrata in una tabella che contiene la lista dei GUID corrispondenti a tutte le righe modificate all’interno del database che partecipa allo scenario di replica.

Quando il merge agent girerà, tramite questa lista, sarà in grado di conoscere i record che hanno subito una variazione e che devono quindi essere inviati ai vari sottoscrittori.

Nel caso in cui lo stesso GUID fosse stato modificato da entrambe le parti (sia sul pubblicatore, sia sul sottoscrittore) l’agent identifica il conflitto e lo risolve secondo la specifica fornitagli in fase di creazione di replica: di default vince il pubblicatore.

I componenti di replica vengono distribuiti con tutte le versioni di SQL Server, ad eccezione delle versioni Express e Mobile, che potranno soltanto sottoscrivere pubblicazioni di dati (SQL CE potrà esserlo solo di pubblicazioni di tipo merge).

 

Le novità di SQL Server 2005

SQL Server 2005 fornisce anche altre tipologie di replica che sono, in realtà, delle opzioni delle tre principali:

  • Replica peer-to-peer: è un’opzione della replica transazionale. Tutti i nodi coinvolti mantengono una copia identica dei dati, sottoscrivendo e pubblicando da e verso tutti gli altri database. Una transazione che ha avuto origine in un nodo qualsiasi verrà replicata in tutti gli altri presenti nella soluzione.

  • Replica eterogenea: è possibile configurare Oracle come pubblicatore (solo repliche snapshot o transazionali) e utilizzare SQL Server 2005 come sottoscrittore e/o distributore. Il wizard andrà ad inserire dei trigger all’interno delle tabelle Oracle in grado di tracciare le modifiche ed inviarle ai sottoscrittori.

Molte altre novità sono state introdotte con la nuova versione di SQL Server, tra queste:

  • Replica di istruzioni DDL: già in SQL Server 2000 era possibile effettuare delle modifiche di schema ad oggetti interessati dalla replica. Tali modifiche però non venivano “passate” in maniera automatica ai sottoscrittori ma si dovevano utilizzare stored procedure di sistema come la “Sp_repladdcolumn” o la “Sp_repldropcolumn”. Oggi, invece, la modifica viene inviata direttamente agli altri server coinvolti tramite l’utilizzo di trigger DDL (un’altra novità di SQL Server 2005) grazie al parametro di default “@replicate_ddl”:

    • sp_addpublication @replicate\_ddl = 1

  • replica di indici full-text: è sufficiente abilitare nel sottoscrittore l’indicizzazione full-text e verificare, nelle proprietà dell’articolo pubblicato, che la proprietà “Copy Full-Text” sia selezionata (true)

  • Partizioni precalcolate: anche in SQL Server 2000 il meccanismo di replica era in grado di capire chi stava chiedendo i dati e quindi di fornire solo i dati necessari (filtrati) per quel preciso sottoscrittore. Oggi, SQL Server 2005, non esegue più questa operazione all’atto della richiesta ma mantiene queste informazioni già pronte (appunto: partizioni precalcolate). Quando un sottoscrittore farà richiesta dei suoi dati SQL Server avrà già la sua corretta partizione pronta, risparmiando tutto il tempo necessario a costruirla

  • Download only articles: è possibile definire articoli come “in sola lettura”. In questo modo tutte le eventuali modifiche che potrebbero essere fatte sui sottoscrittori non saranno replicate sul pubblicatore (i dati si spostano solo dal pubblicatore al sottoscrittore)

  • Replication Monitor: completamente ridisegnato e fornito come console separata (sqlmonitor.exe), è il punto centrale di amministrazione delle nostre repliche

SQL Server 2005 fornisce, per poter costruire scenari di replica, comodi e funzionali wizard attivabili dal Management Studio.

Anche queste procedure guidate, già presenti con le versioni precedenti, sono stati notevolmente migliorati (sia dal punto di vista di step, sia dal punto di vista dell’usabilità).

Il consiglio è quello di provare a scrivere un piccolo database (con una sola tabella?) già nell’ottica di volerlo replicare e provare, giocando con i wizard, a realizzare la prima replica.

Questa tecnica è sicuramente affascinante e sicuramente non è semplicissima, procedendo per gradi, però, ci si potrà divertire parecchio!