Log Shipping e replicazione (SQL Server)

Si applica a:SQL Server

Il log shipping coinvolge due copie di un unico database che in genere risiedono in computer diversi. In un momento dato solo una copia del database risulta disponibile per i client. Questa copia è nota come database primario. Gli aggiornamenti al database primario apportati dai client vengono propagati attraverso il log shipping all'altra copia del database, nota come database secondario. Il processo di log shipping prevede l'applicazione nel database secondario del log delle transazioni relativo a ogni operazione di inserimento, aggiornamento o eliminazione eseguita sul database primario.

Il log shipping può essere utilizzato congiuntamente alla replicazione, con il comportamento seguente:

• La replicazione non continua dopo un failover del log shipping. Se si verifica il failover, gli agenti di replica non si connettono al server secondario. In questo modo le transazioni non vengono replicate nei Sottoscrittori. Se viene eseguito un failback al server primario, la replica riprende. Tutte le transazioni copiate durante il log shipping dal server secondario a quello primario vengono replicate nei Sottoscrittori.

• Se il database primario viene perso definitivamente, è possibile rinominare il database secondario affinché la replica possa continuare. Nella parte restante dell'argomento vengono descritti i requisiti e le procedure necessari in questo caso. L'esempio fornito è il database di pubblicazione, che è il database più comune su cui applicare il log shipping, ma un processo simile può essere applicato anche ai database di sottoscrizione e di distribuzione.

Per informazioni sul recupero di database oggetto di replica senza dover riconfigurare la replica, vedere Backup e ripristino di database replicati.

Requisiti e procedure per la replica dal database secondario se quello primario viene perso

Tenere presenti i requisiti e le considerazioni seguenti:

• Se nel server primario sono inclusi più database di pubblicazione, distribuire i log per tutti i database di pubblicazione allo stesso server secondario.

• Il percorso di installazione dell'istanza del server secondario deve corrispondere a quello dell'istanza del server primario. I percorsi dei database utente nel server secondario devono corrispondere a quelli nel server primario.

• Eseguire il backup della chiave master del servizio nel server primario. La chiave verrà ripristinata nel server secondario. Per altre informazioni, vedere BACKUPSERVICEBACKUP SERVICE MASTER KEY (Transact-SQL).

• Il log shipping non costituisce una garanzia completa contro la perdita di dati. Un errore nel database primario può provocare la perdita di dati di cui non è ancora stato eseguito il backup o di copie di backup andate perse quando si è verificato l'errore.

Log Shipping con replica transazionale

Nel caso della replica transazionale, il funzionamento del log shipping dipende dall'opzione sync with backup . Questa opzione può essere impostata sul database di pubblicazione e sul database di distribuzione; nel log shipping per il Publisher, solo l'impostazione sul database di pubblicazione è rilevante.

L'impostazione di questa opzione nel database di pubblicazione garantisce che le transazioni vengano recapitate al database di distribuzione solo dopo che è stato eseguito il backup nel database di pubblicazione. L'ultimo backup del database di pubblicazione può quindi essere ripristinato sul server secondario senza alcuna possibilità che il database di distribuzione contenga transazioni non presenti nel database di pubblicazione ripristinato. Questa opzione garantisce la consistenza tra server di pubblicazione, server di distribuzione e Sottoscrittori in caso di failover del server di pubblicazione in un server secondario. L'impostazione di questa opzione ha effetto sulla latenza e sulla velocità effettiva in quanto le transazioni non possono essere recapitate al database di distribuzione finché non ne viene eseguito il backup nel server di pubblicazione. Se l'applicazione in uso consente questa latenza, è consigliabile impostare l'opzione nel database di pubblicazione. Se l'opzione sync with backup non è impostata, i Sottoscrittori potrebbero ricevere modifiche che non sono più incluse nel database recuperato nel server secondario. Per altre informazioni, vedere Strategie per il backup e il ripristino della replica snapshot e della replica transazionale.

Per configurare la replica transazionale e il log shipping con l'opzione di sincronizzazione con il backup

1. Se l'opzione sync with backup non è impostata nel database di pubblicazione, eseguire sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'. Per altre informazioni, vedere sp_replicationdboption (Transact-SQL).

2. Configurare il log shipping per il database di pubblicazione. Per altre informazioni, vedere Configurare il Log Shipping (SQL Server).

3. Se il Publisher ha un errore, ripristinare l'ultimo log delle transazioni del database sul server secondario, usando l'opzione KEEP_REPLICATION di RESTORE LOG. In questo modo vengono mantenute tutte le impostazioni di replica per il database. Per altre informazioni, vedere Passare a un database secondario del log shipping (SQL Server) e RESTORE (Transact-SQL).

4. Ripristinare i database msdb e master dal server primario al server secondario. Per altre informazioni, vedere Backup e ripristino di Database di sistema (SQL Server). Se il server primario è anche un server di distribuzione, ripristinare il database di distribuzione dal server primario a quello secondario.

   Le impostazioni e la configurazione di replica di questi database devono essere consistenti con quelle del database di pubblicazione nel server primario.

5. Nel server secondario rinominare il computer e quindi l'istanza di SQL Server in modo che i nuovi nomi corrispondano al nome del server primario. Per informazioni sulla ridenominazione di un computer, vedere la documentazione di Windows. Per informazioni sulla ridenominazione del server, vedere Rinominare un computer che ospita un'istanza autonoma di SQL Server e Ridenominare un'istanza del cluster di failover di SQL Server.

6. Nel server secondario ripristinare la chiave master del servizio di cui è stato eseguito il backup dal server primario. Per altre informazioni, vedere RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

Per configurare la replica transazionale e il log shipping senza l'opzione di sincronizzazione con il backup

1. Configurare il log shipping per il database di pubblicazione. Per altre informazioni, vedere Configurare il Log Shipping (SQL Server).

2. Se il Publisher ha un errore, ripristinare l'ultimo log delle transazioni del database sul server secondario, usando l'opzione KEEP_REPLICATION di RESTORE LOG. In questo modo vengono mantenute tutte le impostazioni di replica per il database. Per altre informazioni, vedere Passare a un database secondario del log shipping (SQL Server) e RESTORE (Transact-SQL).

3. Ripristinare i database msdb e master dal server primario al server secondario. Per altre informazioni, vedere Backup e ripristino di Database di sistema (SQL Server). Se il server primario è anche un server di distribuzione, ripristinare il database di distribuzione dal server primario a quello secondario.

   Le impostazioni e la configurazione di replica di questi database devono essere consistenti con quelle del database di pubblicazione nel server primario.

4. Nel server secondario rinominare il computer e quindi l'istanza di SQL Server in modo che i nuovi nomi corrispondano al nome del server primario. Per informazioni sulla ridenominazione di un computer, vedere la documentazione di Windows. Per informazioni sulla ridenominazione del server, vedere Rinominare un computer che ospita un'istanza autonoma di SQL Server e Ridenominare un'istanza del cluster di failover di SQL Server.

   È possibile che venga visualizzato un messaggio di errore dell'agente di lettura log che informa l'utente che il database di pubblicazione e il database di distribuzione non sono sincronizzati.

5. Nel server secondario ripristinare la chiave master del servizio di cui è stato eseguito il backup dal server primario. Per altre informazioni, vedere RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

6. Eseguire sp_replrestart. Questa stored procedure può essere usata per forzare il Log Reader Agent a ignorare tutte le transazioni replicate precedenti nel log del database di pubblicazione. Le transazioni applicate dopo il completamento della procedura memorizzata vengono elaborate dall'Agente di lettura log. Per altre informazioni, vedere sp_replrestart (Transact-SQL).

7. Riavviare l'Agente di lettura log dopo che la stored procedure è stata eseguita correttamente. Per altre informazioni, vedere Avviare e arrestare un agente di replica (SQL Server Management Studio).

8. Le transazioni già distribuite al Sottoscrittore potrebbero essere applicate presso il server di pubblicazione. Per evitare che l'agente di distribuzione abbia esito negativo con un errore quando tenta di riapplicare queste transazioni presso un Sottoscrittore, specificare il profilo dell'agente denominato Continua in caso di errori di coerenza dei dati.

Log shipping con replica di tipo merge

Eseguire la procedura seguente per configurare la replica di tipo merge e il log shipping.

Per configurare la replica di tipo merge e il log shipping

1. Configurare il log shipping per il database di pubblicazione. Per altre informazioni, vedere Configurare il Log Shipping (SQL Server).

2. Se il server di pubblicazione non è disponibile, sul server secondario rinominare il computer e quindi l'istanza di SQL Server in modo che corrispondano al nome del server primario. Per informazioni sulla ridenominazione di un computer, vedere la documentazione di Windows. Per informazioni sulla ridenominazione del server, vedere Rinominare un computer che ospita un'istanza autonoma di SQL Server e Ridenominare un'istanza del cluster di failover di SQL Server.

3. Ripristinare l'ultimo log del database sul server secondario, usando l'opzione KEEP_REPLICATION di RESTORE LOG. In questo modo vengono mantenute tutte le impostazioni di replica per il database. Per altre informazioni, vedere Passare a un database secondario del log shipping (SQL Server) e RESTORE (Transact-SQL).

4. Ripristinare i database msdb e master dal server primario al server secondario. Per altre informazioni, vedere Backup e ripristino di Database di sistema (SQL Server). Se il server primario è anche un server di distribuzione, ripristinare il database di distribuzione dal server primario a quello secondario.

   Le impostazioni e la configurazione di replica di questi database devono essere consistenti con quelle del database di pubblicazione nel server primario.

5. Nel server secondario ripristinare la chiave master del servizio di cui è stato eseguito il backup dal server primario. Per altre informazioni, vedere RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

6. Sincronizzare il database di pubblicazione con uno o più database di sottoscrizione. In questo modo è possibile caricare le modifiche già apportate nel database di pubblicazione, ma non ancora incluse nella copia di backup ripristinata. I dati che è possibile caricare dipendono dal modo in cui una pubblicazione è filtrata:

   • Se la pubblicazione non è filtrata, sarà possibile aggiornare il database di pubblicazione eseguendo la sincronizzazione con il Sottoscrittore più aggiornato.

   • Se la pubblicazione è filtrata, l'aggiornamento del database di pubblicazione potrebbe non essere possibile. Considerare una tabella partizionata in modo che ogni sottoscrizione riceva i dati relativi ai clienti solo per una singola area: Nord, Est, Sud e Ovest. Se per ogni partizione di dati è disponibile almeno un Sottoscrittore, la sincronizzazione con un Sottoscrittore per ogni partizione dovrebbe consentire di aggiornare il database di pubblicazione. Tuttavia, se i dati nella partizione Ovest, ad esempio, non sono stati replicati ad alcun Sottoscrittore, questi dati presso l'Editore non possono essere aggiornati. In questo caso è consigliabile reinizializzare tutte le sottoscrizioni in modo da garantire la convergenza dei dati nel server di pubblicazione e nei Sottoscrittori. Per altre informazioni, vedere Reinizializzare le sottoscrizioni.

   Se si esegue la sincronizzazione con un sottoscrittore che esegue una versione di SQL Server precedente a SQL Server 2005 (9.x), la sottoscrizione non può essere anonima. Deve essere una sottoscrizione client o una sottoscrizione server (dette anche sottoscrizioni locali e sottoscrizioni globali nelle versioni precedenti). Per altre informazioni, vedere Sincronizzare i dati.

Vedi anche

Replica di SQL Server
Informazioni sul log shipping (SQL Server)Configurare la replica con i gruppi di disponibilità Always On