Log shipping e replica (SQL Server)

Articolo
04/12/2023

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.

Quando il log shipping viene utilizzato in combinazione con la replica, si noti quanto segue:

La replica non continua in caso di failover del server 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 si verifica il failback nel server primario, la replica viene ripresa. 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. Nell'esempio seguente viene utilizzato il database di pubblicazione, ovvero il database più comune per cui eseguire il log shipping. Le operazioni possono tuttavia essere eseguite nei 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.

Nota

Utilizzare i gruppi di disponibilità Always On, anziché il log shipping, per garantire disponibilità al database di pubblicazione. Per altre informazioni, consultare Configurare la replica con i gruppi di disponibilità Always On.

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 BACKUP 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 nel database di pubblicazione e nel database di distribuzione. Nel caso del log shipping per il server di pubblicazione, è importante che l'opzione sia impostata nel database di pubblicazione.

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 nel server secondario. In questo modo il database di distribuzione avrà le stesse transazioni del 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 sync with backup

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).
Configurare il log shipping per il database di pubblicazione. Per altre informazioni, vedere Configurare il log shipping (SQL Server).
Se si verifica un errore nel server di pubblicazione, ripristinare l'ultimo log del database nel server secondario mediante l'opzione KEEP_REPLICATION di RESTORE LOG. In questo modo vengono mantenute tutte le impostazioni di replica per il database. Per altre informazioni, vedere Failover su un database secondario per il log shipping (SQL Server) e RESTORE (Transact-SQL).
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.
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.
Nel server secondario ripristinare la chiave master del servizio di cui è stato eseguito il backup dal server primario. Per altre informazioni, vedere RESTORE SERVICE MASTER KEY (Transact-SQL).

Per configurare la replica transazionale e il log shipping senza l'opzione sync with backup

Configurare il log shipping per il database di pubblicazione. Per altre informazioni, vedere Configurare il log shipping (SQL Server).
Se si verifica un errore nel server di pubblicazione, ripristinare l'ultimo log del database nel server secondario mediante l'opzione KEEP_REPLICATION di RESTORE LOG. In questo modo vengono mantenute tutte le impostazioni di replica per il database. Per altre informazioni, vedere Failover su un database secondario per il log shipping (SQL Server) e RESTORE (Transact-SQL).
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.
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.
Nel server secondario ripristinare la chiave master del servizio di cui è stato eseguito il backup dal server primario. Per altre informazioni, vedere RESTORE SERVICE MASTER KEY (Transact-SQL).
Eseguire sp_replrestart. Questa stored procedure consente di forzare l'agente di lettura log in modo che le transazioni già replicate nel log del database di pubblicazione vengano ignorate. Le transazioni applicate dopo il completamento della stored procedure vengono elaborate dall'agente di lettura log. Per altre informazioni, vedere sp_replrestart (Transact-SQL).
Dopo aver eseguito la stored procedure, riavviare l'agente di lettura log. Per altre informazioni, vedere Avviare e arrestare un agente di replica (SQL Server Management Studio).
Le transazioni che sono già state distribuite al Sottoscrittore possono essere applicate al server di pubblicazione. Affinché non si verifichi un errore dell'agente di distribuzione durante il tentativo di riapplicazione di tali transazioni al Sottoscrittore, specificare il profilo agente 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

Configurare il log shipping per il database di pubblicazione. Per altre informazioni, vedere Configurare il log shipping (SQL Server).
In caso di errore del server di pubblicazione, 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.
Ripristinare l'ultimo log del database nel server secondario mediante l'opzione KEEP_REPLICATION di RESTORE LOG. In questo modo vengono mantenute tutte le impostazioni di replica per il database. Per altre informazioni, vedere Failover su un database secondario per il log shipping (SQL Server) e RESTORE (Transact-SQL).
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.
Nel server secondario ripristinare la chiave master del servizio di cui è stato eseguito il backup dal server primario. Per altre informazioni, vedere RESTORE SERVICE MASTER KEY (Transact-SQL).
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 ad esempio i dati nella partizione Ovest non sono stati replicati in alcun Sottoscrittore, questi dati nel server di pubblicazione non potranno 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