Miglioramento della disponibilità
La replica può essere utilizzata per replicare dati a un server di standby, che garantisce maggiore disponibilità in caso di interruzioni del sistema pianificate o non pianificate. È consigliabile utilizzare la replica per offrire una modalità di standby a caldo (warm standby) se i dati necessari nel server di standby sono un subset dei dati necessari nel server primario. È inoltre opportuno valutare gli aspetti seguenti:
Se l'applicazione richiede dati da più siti per incrementare la scalabilità e la disponibilità, vedere Miglioramento della scalabilità e della disponibilità.
Se l'applicazione richiede la disponibilità di un intero database in un server di standby, utilizzare il mirroring del database anziché la replica. Il mirroring del database è più appropriato se l'intero database deve essere sincronizzato e non è necessario utilizzare il server secondario per le query. Per ulteriori informazioni, vedere Amministrazione del mirroring del database.
Nella figura seguente viene illustrato un server primario e un singolo server di standby, con un subset dei dati del server primario disponibile nel server secondario.
.gif "Replica dei dati in un server di standby")
[!NOTA]
La replica non offre un meccanismo di failover da un server a un altro server di standby. Tutte le applicazioni che accedono a un determinato server devono essere programmate per l'utilizzo di un altro server qualora il primo non fosse disponibile.
Esempio Adventure Works Cycles
Adventure Works Cycles è un'azienda manifatturiera fittizia utilizzata per esemplificare concetti e scenari relativi ai database. Per ulteriori informazioni, vedere Database di esempio AdventureWorks.
Adventure Works Cycles dispone di un certo numero di server disposti nelle strutture di produzione che raccolgono dati sui difetti rilevati nelle linee di produzione. La replica viene utilizzata in questo contesto per garantire la disponibilità di questi server. È stato creato un codice che consente di reindirizzare le query a un server di standby a caldo (warm standby) durante i periodi di interruzione pianificata o non pianificata del server.
Requisiti comuni per questo scenario
Le applicazioni che utilizzano la replica per migliorare la disponibilità in genere presentano i requisiti seguenti, che devono essere presi in considerazione da una soluzione di replica appropriata:
È necessario che nel sistema venga mantenuta la consistenza delle transazioni.
La latenza del sistema deve essere bassa, poiché gli aggiornamenti eseguiti in un server devono raggiungere rapidamente gli altri server.
La velocità effettiva del sistema deve essere elevata, perché il sistema deve essere in grado di gestire la replica di un numero elevato di transazioni.
L'elaborazione delle repliche deve causare un overhead minimo.
I dati richiesti in un server secondario possono essere un subset dei dati disponibili nel server primario (vedere la prima figura sopra riportata).
Tipo di replica da utilizzare per questo scenario
Microsoft In SQL Server viene utilizzata una metafora basata sul settore dell'editoria per la descrizione dei componenti del sistema di replica. I componenti includono il server di pubblicazione, Sottoscrittori, pubblicazioni, articoli e sottoscrizioni.
Nella figura sopra riportata il server primario è rappresentato dal server di pubblicazione. I dati disponibili nel server primario vengono inclusi in parte o interamente nella pubblicazione e ogni tabella di dati costituisce un articolo (gli articoli possono inoltre essere altri oggetti di database, come le stored procedure). Il server di standby è un Sottoscrittore della pubblicazione che riceve schemi e dati sotto forma di sottoscrizione. Per ulteriori informazioni sui componenti del sistema, vedere Panoramica del modello di pubblicazione della replica.
SQL Server supporta diversi tipi di replica per soddisfare diverse esigenze applicative, ovvero la replica snapshot, transazionale e di tipo merge. Per ottenere i migliori risultati nell'implementazione di questo scenario, è consigliabile utilizzare la replica transazionale, essendo la più appropriata per la gestione dei requisiti descritti nella sezione precedente. Per ulteriori informazioni sulla replica transazionale, vedere Panoramica della replica transazionale e Funzionamento della replica transazionale.
Le caratteristiche di progettazione tipiche della replica transazionale la rendono il tipo di replica ideale per soddisfare i requisiti principali di questo scenario:
Consistenza delle transazioni
Bassa latenza
Velocità effettiva elevata
Overhead minimo
La principale opzione da valutare per questo scenario è il filtraggio dei dati. La replica transazionale consente di filtrare le colonne e le righe, pertanto le tabelle nei Sottoscrittori contengono solo i dati richiesti dall'applicazione. Per ulteriori informazioni, vedere Applicazione di filtri ai dati pubblicati.
Passaggi per l'implementazione dello scenario
Per l'implementazione di questo scenario, è innanzitutto necessario creare una pubblicazione e le sottoscrizioni, quindi inizializzare ogni sottoscrizione. Fare clic sui collegamenti seguenti per ulteriori informazioni su ogni passaggio:
Dopo l'inizializzazione della sottoscrizione e l'attivazione del flusso di dati tra il server di pubblicazione e i Sottoscrittori, potrebbe essere utile consultare gli argomenti seguenti per raccogliere ulteriori informazioni sulle attività più comuni di amministrazione e monitoraggio: