Share via

  • Articolo

Procedura: Configurazione della replica transazionale peer-to-peer (programmazione Transact-SQL della replica)

In questo argomento viene descritto come configurare e gestire una topologia di replica peer-to-peer utilizzando stored procedure. Viene innanzitutto illustrato come creare una topologia a tre nodi e quindi viene spiegato come aggiungere e connettere un nuovo nodo. Sono inoltre riportate procedure separate per l'aggiunta di un nodo che esegue SQL Server 2005 e l'aggiunta di un nodo che esegue SQL Server 2008 o una versione più recente di SQL Server. In questo argomento non sono incluse informazioni sui parametri utilizzati per il rilevamento dei conflitti nella replica peer-to-peer. Per informazioni sul rilevamento di conflitti, vedere Procedura: Configurazione del rilevamento di conflitti per la replica transazionale peer-to-peer (programmazione Transact-SQL della replica).

La configurazione della topologia è molto simile alla configurazione di una serie di pubblicazioni e sottoscrizioni transazionali standard. È essenziale notare la modalità di inizializzazione dei nodi e i valori specificati per il parametro @sync_type di sp_addsubscription:

  • Il primo nodo di una topologia include il database di pubblicazione originale, pertanto non deve essere inizializzato con lo schema e i dati. Specificare quindi il valore replication support only per le sottoscrizioni che replicano nel primo nodo dati di altri nodi. Questa opzione garantisce che gli oggetti richiesti dalla replica vengano copiati nel primo nodo.

  • Dopo aver configurato il primo nodo, i nodi vengono in genere inizializzati da un backup del primo nodo. Specificare quindi il valore initialize with backup o replication support only per le sottoscrizioni che replicano in altri nodi dati del primo nodo. È possibile utilizzare il valore replication support only se nel sistema non è in corso nessuna attività. È invece richiesto il valore initialize with backup se il sistema è attivo. Se si specifica initialize with backup, tutte le transazioni attinenti verranno replicate in un nuovo nodo.

  • Dopo aver inizializzato un nodo, le sottoscrizioni che replicano dati da altri nodi non devono inizializzare nuovamente il nodo. Specificare quindi il valore replication support only o initialize from lsn. È possibile utilizzare il valore replication support only se nel sistema non è in corso nessuna attività. È invece richiesto il valore initialize from lsn se il sistema è attivo. Se si specifica initialize from lsn, tutte le transazioni attinenti verranno replicate in un nuovo nodo.

    Il valore initialize from lsn non è supportato in SQL Server 2005. Se una topologia include nodi SQL Server 2005, è possibile connettere un nuovo nodo a un nodo esistente, ma per connettersi a più di un nodo è necessario mettere in stato di inattività il sistema. Mettere in stato di inattività un sistema significa interrompere le attività sulle tabelle pubblicate in tutti i nodi e verificare che ogni nodo abbia ricevuto tutte le modifiche dagli altri nodi: Questo processo viene descritto in dettaglio nell'ultima sezione di questo argomento.

Procedura

Se si intende configurare una topologia per database attivi, utilizzare la procedura seguente per aggiungere il primo e il secondo nodo (Nodo A e Nodo B). Utilizzare quindi la procedura successiva per il Nodo C e per eventuali nodi aggiuntivo. Nella procedura successiva viene utilizzato il valore initialize from lsn per @sync_type. Questa opzione consente di configurare una topologia mentre il sistema è attivo senza nessuna perdita di transazioni.

Per configurare la replica peer-to-peer tra tre nodi

  1. Configurare ogni nodo come server di pubblicazione e associarlo a un server di distribuzione locale o remoto. Se si utilizza un server di distribuzione remoto, è consigliabile evitare di ricorrere allo stesso per tutti i nodi, poiché ciò potrebbe rappresentare un singolo punto di errore. Per ulteriori informazioni, vedere Procedura: Configurazione della pubblicazione e della distribuzione (programmazione Transact-SQL della replica).

  2. Nel Nodo A eseguire sp_addpublication. Specificare il valore true per @enabled_for_p2p, il valore active per @status e il valore true per @allow_initialize_from_backup. Per aggiungere articoli alla pubblicazione, eseguire sp_addarticle.

  3. I dati iniziali devono essere presenti in ogni nodo prima che la topologia venga configurata. Utilizzare la funzionalità di backup e ripristino di SQL Server per inizializzare i dati per la pubblicazione in ogni nodo della topologia. Il backup deve provenire dal primo nodo configurato, in questo caso il Nodo A e deve essere eseguito dopo che la pubblicazione del Nodo A è stata creata e attivata per la replica peer-to-peer. In questo argomento si presuppone che non vengano eseguite attività in nessuno dei nuovi nodi prima dell'aggiunta di tutti i nodi. Pertanto, è possibile utilizzare lo stesso backup per inizializzare ogni nodo.

    Se vengono eseguite attività in uno dei nuovi nodi prima dell'aggiunta di tutti i nodi, è necessario prelevare un nuovo backup dopo che ogni nodo viene aggiunto e viene sincronizzato almeno una volta con il Nodo A. In questo modo ci si assicura che il backup del Nodo A contenga i metadati relativi a tutti gli altri nodi. Ad esempio, se si aggiungono il Nodo B e il Nodo C mentre in questi nodi sono in corso attività, inizializzare il Nodo B con un backup del Nodo A, configurare e sincronizzare il Nodo B, prelevare un nuovo backup dal Nodo A, inizializzare il Nodo C con il nuovo backup, quindi configurare e sincronizzare il Nodo C.

    Per ulteriori informazioni su come eseguire il backup e il ripristino di database, vedere Backup e ripristino di database in SQL Server.

    Nota importanteImportante

    Durante il ripristino del database, non specificare l'opzione KEEP_REPLICATION (per Transact-SQL) o Mantieni le impostazioni di replica (per SQL Server Management Studio). Il database verrà configurato in modo appropriato dalla replica quando verrà eseguita la Configurazione guidata topologia peer-to-peer.

    Un backup contiene l'intero database. Per questo motivo, ogni database peer inizializzato contiene una copia completa del database di pubblicazione. Il backup può includere tabelle non specificate come articoli per la pubblicazione. È compito dell'amministratore o dell'applicazione rimuovere gli oggetti o i dati indesiderati dopo il ripristino del backup. Durante le sincronizzazioni successive le modifiche ai dati verranno replicate solo se si applicano a tabelle specificate come articoli.

  4. Nel Nodo A eseguire sp_addsubscription. Specificare il nome della pubblicazione creata nel Nodo A come @publication, il nome del Nodo B come @subscriber, il nome del database di destinazione nel Nodo B come @destination_db, il valore initialize with backup per @sync_type e valori appropriati per i parametri @backupdevicetype e @backupdevicename.

  5. Nel Nodo A eseguire nuovamente sp_addsubscription. Questa volta specificare il nome della pubblicazione come @publication, il nome del Nodo C come @subscriber, il nome del database di destinazione nel Nodo C come @destination_db, il valore initialize with backup per @sync_type e valori appropriati per i parametri @backupdevicetype e @backupdevicename.

  6. Nel Nodo B eseguire sp_addpublication. Specificare il nome della pubblicazione per @publication, il valore true per @enabled_for_p2p, il valore active per @status e il valore true per @allow_initialize_from_backup. Per aggiungere articoli alla pubblicazione, eseguire sp_addarticle.

  7. Nel Nodo B eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo A come @subscriber, il nome del database di destinazione nel Nodo A come @destination_db e il valore replication support only per @sync_type.

  8. Nel Nodo B eseguire nuovamente sp_addsubscription. Questa volta specificare il nome della pubblicazione come @publication, il nome del Nodo C come @subscriber, il nome del database di destinazione nel Nodo C come @destination_db e il valore replication support only per @sync_type.

  9. Nel Nodo C eseguire sp_addpublication. Specificare il nome della pubblicazione per @publication, il valore true per @enabled_for_p2p, il valore active per @status e il valore true per @allow_initialize_from_backup. Per aggiungere articoli alla pubblicazione, eseguire sp_addarticle.

  10. Nel Nodo C eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo A come @subscriber, il nome del database di destinazione nel Nodo A come @destination_db e il valore replication support only per @sync_type.

  11. Nel Nodo C eseguire nuovamente sp_addsubscription. Questa volta specificare il nome della pubblicazione come @publication, il nome del Nodo B come @subscriber, il nome del database di destinazione nel Nodo B come @destination_db e il valore replication support only per @sync_type.

  12. Se nelle tabelle pubblicate sono presenti colonne Identity, dopo il ripristino l'intervallo di valori Identity assegnato alle tabelle nel Nodo A verrà utilizzato anche nelle tabelle nel Nodo B e nel Nodo C. È necessario utilizzare DBCC CHECKIDENT per reinizializzare le tabelle nel Nodo B e nel Nodo C, in modo da garantire che per ogni server venga utilizzato un intervallo diverso.

    Per ulteriori informazioni sulla gestione di intervalli di valori Identity, vedere la sezione relativa all'assegnazione degli intervalli per la gestione manuale degli intervalli di valori Identity in Replica di colonne Identity.

Utilizzare la procedura seguente per aggiungere uno o più nodi a una topologia composta da nodi che eseguono SQL Server 2008 o versioni più recenti di SQL Server.

Per aggiungere alla topologia un nodo che esegue SQL Server 2008 o una versione più recente

  1. Configurare il Nodo D come server di pubblicazione e associarlo a un server di distribuzione locale o remoto.

  2. Ripristinare un backup dal Nodo A al Nodo D.

  3. Nel Nodo D eseguire sp_addpublication. Specificare il nome della pubblicazione per @publication, il valore true per @enabled_for_p2p, il valore active per @status e il valore true per @allow_initialize_from_backup. Per aggiungere articoli alla pubblicazione, eseguire sp_addarticle.

  4. Nel Nodo D eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo A come @subscriber, il nome del database di destinazione nel Nodo A come @destination_db e il valore replication support only per @sync_type.

  5. Nel Nodo A eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo D come @subscriber, il nome del database di destinazione nel Nodo D come @destination_db, il valore initialize with backup per @sync_type e valori appropriati per i parametri @backupdevicetype e @backupdevicename.

    Il Nodo D ha ricevuto potenzialmente transazioni dal Nodo B e dal Nodo C tramite il Nodo A. Queste transazioni verranno considerate nel passaggio successivo.

  6. Nel Nodo D eseguire una query sulla tabella MSpeer_lsns. Utilizzare le colonne originator e originator_lsn per determinare il numero di sequenza del file di log (LSN) della transazione più recente che il Nodo D ha ricevuto dal Nodo B.

  7. Nel Nodo D eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo B come @subscriber, il nome del database di destinazione nel Nodo B come @destination_db e il valore replication support only per @sync_type.

  8. Nel Nodo B eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo D come @subscriber, il nome del database di destinazione nel Nodo D come @destination_db, il valore initialize from lsn per @sync_type e il numero di sequenza del file di log (LSN) recuperato per il Nodo B per @subscriptionlsn.

  9. Nel Nodo D eseguire una query sulla tabella MSpeer_lsns. Utilizzare le colonne originator e originator_lsn per determinare il numero di sequenza del file di log (LSN) della transazione più recente che il Nodo D ha ricevuto dal Nodo C.

  10. Nel Nodo D eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo C come @subscriber, il nome del database di destinazione nel Nodo C come @destination_db e il valore replication support only per @sync_type.

  11. Nel Nodo C eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo D come @subscriber, il nome del database di destinazione nel Nodo D come @destination_db, il valore initialize from lsn per @sync_type e il numero di sequenza del file di log (LSN) recuperato per il Nodo C per @subscriptionlsn.

  12. Se nelle tabelle pubblicate sono presenti colonne Identity, dopo il ripristino l'intervallo di valori Identity assegnato alle tabelle nel Nodo A verrà utilizzato anche nelle tabelle nel Nodo D. È necessario utilizzare DBCC CHECKIDENT per reinizializzare le tabelle nel Nodo D, in modo da garantire che per ogni server venga utilizzato un intervallo diverso.

    Per ulteriori informazioni sulla gestione di intervalli di valori Identity, vedere la sezione relativa all'assegnazione degli intervalli per la gestione manuale degli intervalli di valori Identity in Replica di colonne Identity.

Come accennato nell'introduzione di questo argomento, la differenza principale tra l'aggiunta di un nodo SQL Server 2005 e l'aggiunta di un nodo che esegue una versione più recente di SQL Server è che in SQL Server 2005 è necessario mettere in stato di inattività il sistema per connettere il nuovo nodo a tutti i nodi esistenti. Nella procedura seguente vengono illustrate le diverse fasi dell'aggiunta di un nodo SQL Server 2005 alla topologia esistente:

  • La fase uno è illustrata nei passaggi da 1 a 5. La fase uno implica la connessione parziale del Nodo D alla topologia tramite la creazione di sottoscrizioni tra il Nodo A e il Nodo D. In questo modo, le modifiche continuano a essere applicate al Nodo A, al Nodo B e al Nodo C. Le modifiche al Nodo D possono iniziare in seguito alla creazione di sottoscrizioni tra il Nodo A e il Nodo D. Le modifiche del Nodo B e del Nodo C vengono replicate nel Nodo D tramite il Nodo A.

  • La fase due è illustrata nei passaggi da 6 a 9. La fase due implica la connessione completa del Nodo D alla topologia tramite la creazione di sottoscrizioni tra il Nodo B e il Nodo D e tra il Nodo C e il Nodo D. Per questa fase è necessario mettere in stato di inattività il sistema.

    La fase due non è obbligatoria, ma garantisce una maggiore tolleranza di errore rispetto a una connessione singola tra il Nodo A e il Nodo D.

Per aggiungere un nodo SQL Server 2005 alla topologia

  1. Configurare il Nodo D come server di pubblicazione e associarlo a un server di distribuzione locale o remoto.

  2. Ripristinare un backup dal Nodo A al Nodo D.

  3. Nel Nodo D eseguire sp_addpublication. Specificare il nome della pubblicazione per @publication, il valore true per @enabled_for_p2p, il valore active per @status e il valore true per @allow_initialize_from_backup. Per aggiungere articoli alla pubblicazione, eseguire sp_addarticle.

  4. Nel Nodo D eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo A come @subscriber, il nome del database di destinazione nel Nodo A come @destination_db e il valore replication support only per @sync_type.

  5. Nel Nodo A eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo D come @subscriber, il nome del database di destinazione nel Nodo D come @destination_db, il valore initialize with backup per @sync_type e valori appropriati per i parametri @backupdevicetype e @backupdevicename.

  6. Per mettere in stato di inattività la topologia, eseguire le operazioni seguenti:

    1. Interrompere qualsiasi attività in tutte le tabelle pubblicate nella topologia peer-to-peer.

    2. Eseguire sp_requestpeerresponse nel database in Server A, Server B, Server C e Server D, quindi recuperare il parametro di output @request_id.

    3. Per impostazione predefinita, l'agente di distribuzione è impostato per l'esecuzione continua. I token dovrebbero pertanto essere inviati automaticamente a tutti i nodi. Se l'agente di distribuzione non viene eseguito in modalità continua, eseguire l'agente. Per ulteriori informazioni, vedere Concetti di base relativi ai file eseguibili dell'agente di replica o Procedura: Avvio e interruzione di un agente di replica (SQL Server Management Studio).

    4. Eseguire sp_helppeerresponses, specificando il valore @request_id recuperato nel passaggio 2. Attendere finché tutti i nodi indicano di avere ricevuto la richiesta peer.

    5. Se necessario, assegnare nuovi intervalli di valori Identity al Nodo D. Sarà quindi possibile connettere completamente la topologia aggiungendo le sottoscrizioni rimanenti.

  7. Nel Nodo D eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo B come @subscriber, il nome del database di destinazione nel Nodo B come @destination_db e il valore replication support only per @sync_type.

  8. Nel Nodo D eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo C come @subscriber, il nome del database di destinazione nel Nodo C come @destination_db e il valore replication support only per @sync_type.

  9. Nel Nodo B eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo D come @subscriber, il nome del database di destinazione nel Nodo D come @destination_db e il valore replication support only per @sync_type.

  10. Nel Nodo C eseguire sp_addsubscription. Specificare il nome della pubblicazione come @publication, il nome del Nodo D come @subscriber, il nome del database di destinazione nel Nodo D come @destination_db e il valore replication support only per @sync_type.