Replica transazionale peer-to-peer

Articolo
12/15/2008

Data aggiornamento: 12 dicembre 2006

La replica transazionale peer-to-peer è progettata per le applicazioni che devono leggere o modificare i dati di qualsiasi database che partecipa alla replica. Un'applicazione per gli acquisti in linea, ad esempio, è adatta alla replica peer-to-peer poiché le prestazioni dell'applicazione possono essere migliorate estendendo le query che consentono di leggere i dati a più database. Se uno dei server che ospita i database non è disponibile, l'applicazione può inoltre essere programmata in modo da eseguire il routing del traffico agli altri server, che dispongono di copie identiche dei dati. Le prestazioni di lettura vengono migliorate in quanto l'attività può essere distribuita tra tutti i nodi. Le prestazioni delle operazioni di aggiornamento, inserimento ed eliminazione aggregate per la topologia sono simili a quelle di un unico nodo poiché tutte le modifiche vengono propagate a tutti i nodi.

Tutti i nodi in una topologia peer-to-peer sono peer, ovvero ogni nodo pubblica e sottoscrive gli stessi schemi e dati. Le modifiche, quali inserimenti, aggiornamenti ed eliminazioni, possono essere apportate a tutti i nodi. La replica è in grado di stabilire quando una modifica è stata applicata a un determinato nodo, impedendo che le modifiche passino da un nodo all'altro più volte.

[!NOTA] Le applicazioni personalizzate che accedono e apportano modifiche ai dati devono garantire che gli inserimenti, gli aggiornamenti e le eliminazioni siano partizionati, pertanto le modifiche a una determinata riga che hanno origine in un nodo devono essere sincronizzate con tutti gli altri database della topologia prima che la riga venga modificata da un altro nodo. Se un'applicazione esegue modifiche simultanee in conflitto in una determinata riga su più nodi, utilizzare la replica di tipo merge poiché è particolarmente adatta alla gestione dei conflitti. Per ulteriori informazioni sulla replica di tipo merge, vedere Panoramica della replica di tipo merge.

La replica transazionale standard si basa su Sottoscrittori di sola lettura e presenta una struttura gerarchica, ovvero un singolo server di pubblicazione in genere pubblica i dati in uno o più Sottoscrittori. Nella replica transazionale standard è inoltre supportata una gerarchia di ripubblicazione che prevede il recapito degli aggiornamenti da un server di pubblicazione a un set di Sottoscrittori di ripubblicazione, i quali a loro volta recapitano gli aggiornamenti al set finale di Sottoscrittori del nodo foglia. L'aggiornamento delle sottoscrizioni offre ai Sottoscrittori la possibilità di trasmettere le modifiche al server di pubblicazione, ma la disposizione resta gerarchica poiché le modifiche seguono la struttura gerarchica nel passaggio dai Sottoscrittori ai server di pubblicazione. Diversamente dalla replica transazionale di sola lettura e dalla replica transazionale con sottoscrizioni ad aggiornamento, le relazioni tra i nodi in una topologia di replica peer-to-peer sono relazioni tra peer anziché gerarchiche, pertanto ogni nodo dispone di schemi e dati identici.

[!NOTA] Sebbene gli aggiornamenti possano essere eseguiti in più database partecipanti, è importante comprendere che le topologie peer-to-peer non richiedono né consentono le opzioni di pubblicazione ad aggiornamento immediato o in coda. Per ulteriori informazioni sull'aggiornamento immediato e in coda, vedere Sottoscrizioni aggiornabili per la replica transazionale.

Topologie peer-to-peer

Negli scenari seguenti vengono illustrati gli utilizzi tipici della replica peer-to-peer.

Topologia con due database

Replica peer-to-peer, due nodi

In entrambe le figure precedenti vengono illustrati due database partecipanti e il traffico di dati utente viene diretto ai database tramite un server applicazioni. Questa configurazione può essere utilizzata per numerose applicazioni diverse, dai siti Web alle applicazioni per gruppi di lavoro e offre i vantaggi seguenti:

Migliori prestazioni di lettura, poiché le operazioni di lettura sono distribuite a due server.
Maggiore disponibilità in caso di manutenzione o di errore in uno dei nodi.

In entrambe le figure il carico dell'attività di lettura è bilanciato tra i database partecipanti, mentre gli aggiornamenti sono gestiti diversamente:

A sinistra, gli aggiornamenti vengono partizionati tra due server. Ad esempio, se nel database fosse disponibile un catalogo dei prodotti, un'applicazione personalizzata potrebbe dirigere gli aggiornamenti al nodo "A" per i prodotti con nomi che iniziano per A-M e al nodo "B" per i prodotti con nomi che iniziano per N-Z. Gli aggiornamenti verrebbero quindi replicati all'altro nodo.
A destra tutti gli aggiornamenti vengono diretti al nodo "B" e da questo nodo vengono quindi replicati al nodo "A". Se "B" non è in linea, ad esempio per manutenzione, il server applicazioni può dirigere tutte le attività al nodo "A". Quando "B" sarà nuovamente in linea, potrà essere raggiunto dagli aggiornamenti e il server applicazioni potrà spostare tutti gli aggiornamenti a "B" o continuare a dirigerli ad "A".

La replica peer-to-peer può supportare entrambi gli approcci, ma l'esempio di aggiornamento centrale illustrato a destra viene spesso utilizzato nella replica transazionale standard.

Topologie con tre o più database

Replica peer-to-peer in posizioni diverse

Nella figura precedente vengono illustrati tre database partecipanti che rappresentano il back-end per un'organizzazione di assistenza software internazionale, con uffici a Los Angeles, Londra e Taipei. I tecnici del supporto tecnico in tutti gli uffici ricevono le chiamate dei clienti e immettono o aggiornano informazioni su ogni chiamata. I fusi orari dei tre uffici sono separati da un intervallo di otto ore, quindi non si verificano sovrapposizioni nella giornata lavorativa. Quando l'ufficio di Taipei chiude, quello di Londra apre. Se è in corso una chiamata al momento della chiusura di un ufficio, la chiamata viene trasferita all'operatore dell'altro ufficio.

Ogni sede dispone di un database e di un server applicazioni, che vengono utilizzati dai tecnici del supporto tecnico per l'immissione e l'aggiornamento delle informazioni sulle chiamate dei clienti. La topologia viene partizionata in base al tempo, pertanto gli aggiornamenti vengono eseguiti solo nel nodo in uso e successivamente vengono distribuiti agli altri database coinvolti. Questa topologia offre i vantaggi seguenti:

Indipendenza senza isolamento: ogni ufficio può inserire, aggiornare o eliminare dati in modo indipendente e, al contempo, condividere i dati poiché essi vengono replicati in tutti gli altri database coinvolti.
Maggiore disponibilità in caso di errore o manutenzione in uno dei database coinvolti.

Nella figura precedente viene illustrata l'aggiunta di un nodo alla topologia a tre nodi. L'aggiunta di un nodo è consentita nello scenario seguente:

All'apertura di un altro ufficio.
Per garantire maggiore disponibilità in caso di manutenzione o per incrementare la tolleranza di errore in caso di errori irreversibili.
Si noti che nelle topologie a tre e quattro nodi tutti i database pubblicano e sottoscrivono dati in tutti gli altri database, garantendo così la massima disponibilità in caso di manutenzione o di errore in uno o più nodi. In seguito all'aggiunta di nodi, è necessario bilanciare le esigenze di disponibilità e scalabilità in base alle prestazioni e alla complessità della distribuzione e dell'amministrazione.

Configurazione della replica peer-to-peer

La configurazione di una topologia di replica peer-to-peer è molto simile alla configurazione di una serie di pubblicazioni e sottoscrizioni transazionali standard. La procedura descritta nell'argomento seguente illustra la configurazione di un sistema a tre nodi, simile alla configurazione illustrata nel diagramma precedente a sinistra.

Per configurare la replica transazionale peer-to-peer

SQL Server Management Studio: Procedura: Configurazione della replica transazionale peer-to-peer (SQL Server Management Studio)
Programmazione Transact-SQL della replica: How to: Configure Peer-to-Peer Transactional Replication (Replication Transact-SQL Programming)

Considerazioni per l'utilizzo della replica peer-to-peer

Quando si utilizza la replica peer-to-peer è opportuno tenere presente le considerazioni seguenti:

Considerazioni generali

La replica peer-to-peer è disponibile solo in SQL Server 2005 Enterprise Edition.
Tutti i database partecipanti devono disporre di schemi e dati identici:
- I nomi di oggetti, gli schemi oggetti e i nomi delle pubblicazioni devono essere identici in tutti i database partecipanti.
- Le pubblicazioni devono consentire la replica delle modifiche dello schema (valore 1 per la proprietà della pubblicazione replicate_ddl, che corrisponde all'impostazione predefinita). Per ulteriori informazioni, vedere Modifiche allo schema nei database di pubblicazione.
- Non è supportata l'applicazioni di filtri alle righe e alle colonne.
È consigliabile configurare la replica in modo che ogni nodo utilizzi un database di distribuzione specifico. In questo modo si evita il rischio che si verifichi un singolo punto di errore.
Non è possibile includere tabelle e altri oggetti in più pubblicazioni peer-to-peer all'interno di un singolo database di pubblicazione.
Per poter creare sottoscrizioni, è necessario abilitare una pubblicazione per la replica peer-to-peer.
Le sottoscrizioni devono essere inizializzate mediante una copia di backup o tramite l'opzione Solo supporto replica. Per ulteriori informazioni, vedere Inizializzazione di una sottoscrizione transazionale senza uno snapshot.
Il rilevamento e la risoluzione dei conflitti non sono previsti. Gli aggiornamenti a una determinata riga devono essere eseguiti solo in un database fino alla sincronizzazione con gli altri database peer. Per ottenere questo risultato è possibile, ad esempio, configurare l'applicazione affinché diriga gli aggiornamenti per un set di righe a un determinato nodo.
L'utilizzo di colonne Identity non è consigliato. Quando si utilizzano valori Identity, è necessario unire manualmente gli intervalli assegnati alle tabelle in ogni database coinvolto. Per ulteriori informazioni, vedere la sezione relativa all'assegnazione di intervalli per la gestione manuale degli intervalli di valori Identity in Replica di colonne Identity.

Limitazioni delle funzionalità

La replica peer-to-peer supporta le funzionalità di base della replica transazionale. Non sono supportate le opzioni descritte di seguito.

Inizializzazione e reinizializzazione con uno snapshot.
Filtri di riga e colonna.
Colonne di tipo timestamp.
Server di pubblicazione e Sottoscrittori non SQL Server.
Aggiornamento immediato e sottoscrizioni ad aggiornamento in coda.
Sottoscrizioni anonime.
Sottoscrizioni parziali.
Sottoscrizioni collegabili e trasformabili (entrambe obsolete in SQL Server 2005).
Agenti di distribuzione condivisi.
Il parametro -SubscriptionStreams dell'agente di distribuzione e il parametro -MaxCmdsInTran dell'agente di lettura log.
Le proprietà di articolo @destination_owner e @destination_table.

Per le proprietà indicate di seguito sono presenti considerazioni speciali:

La proprietà di pubblicazione @allow_initialize_from_backup richiede il valore "true".
La proprietà di articolo @replicate_ddl richiede il valore "true", @identityrangemanagementoption richiede il valore "manual" e @status richiede che l'opzione "24" sia impostata.
Il valore delle proprietà di articolo @ins_cmd, @del_cmd e @upd_cmd non possono essere impostate su "SQL".
La proprietà di sottoscrizione @sync_type richiede il valore "none" o "automatic".

Considerazioni relative alla manutenzione

Per le operazioni seguenti è necessario mettere il sistema in stato di inattività, ovvero sospendere le attività sulle tabelle pubblicate in tutti i nodi e verificare che ogni nodo abbia ricevuto tutte le modifiche dagli altri nodi:
- Aggiunta di un nodo a una topologia esistente
- Aggiunta di un articolo a una pubblicazione esistente
- Esecuzione di modifiche nello schema
- Ripristino di un nodo dal backup
  Per ulteriori informazioni, vedere Procedura: Configurazione della replica transazionale peer-to-peer (SQL Server Management Studio), How to: Quiesce a Replication Topology (Replication Transact-SQL Programming) e How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming).
Se si aggiunge un nuovo nodo a una topologia peer-to-peer, è necessario eseguire il ripristino solo da copie di backup create dopo l'aggiunta del nuovo nodo. Per ulteriori informazioni, vedere Procedura: Configurazione della replica transazionale peer-to-peer (SQL Server Management Studio).
Non è possibile reinizializzare sottoscrizioni in una topologia peer-to-peer. Se è necessario accertarsi che un nodo disponga di una nuova copia dei dati, ripristinare un backup del nodo.

Cronologia modifiche

Versione	Cronologia
12 dicembre 2006	Contenuto modificato: Aggiunta un'indicazione esplicita per segnalare che questa funzionalità è disponibile solo in SQL Server 2005 Enterprise Edition.
17 luglio 2006	Contenuto modificato: Aggiornamento delle informazioni sulle funzionalità della replica transazionale che possono essere utilizzate con la replica peer-to-peer.

Vedere anche

Condividi tramite