Replica e log shipping
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 viene definita database primario. Gli aggiornamenti al database primario apportati dai client vengono propagati attraverso il log shipping all'altra copia del database, definita 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 dei database replicati.
[!NOTA]
Per garantire la disponibilità del database di pubblicazione è consigliabile utilizzare il mirroring del database invece del log shipping. Per ulteriori informazioni, vedere Replica e mirroring del database.
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 ulteriori 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 dell'opzione nel database di pubblicazione garantisce che le transazioni vengano recapitate al database di distribuzione solo dopo che ne è 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 ulteriori 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 ulteriori informazioni, vedere sp_replicationdboption (Transact-SQL).
Configurare il log shipping per il database di pubblicazione. Per ulteriori informazioni, vedere Distribuzione del log shipping.
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 ulteriori informazioni, vedere Failover su un database secondario per il log shipping e RESTORE (Transact-SQL).
Ripristinare i database msdb e master dal server primario al server secondario. Per ulteriori informazioni, vedere Considerazioni sul ripristino dei database model e msdb e Considerazioni sul ripristino del Database master. 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 MicrosoftSQL 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 di un server, vedere Procedura: Ridenominazione di un computer che ospita un'istanza autonoma di SQL Server e Procedura: Ridenominazione di 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 ulteriori 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 ulteriori informazioni, vedere Distribuzione del log shipping.
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 ulteriori informazioni, vedere Failover su un database secondario per il log shipping e RESTORE (Transact-SQL).
Ripristinare i database msdb e master dal server primario al server secondario. Per ulteriori informazioni, vedere Considerazioni sul ripristino dei database model e msdb e Considerazioni sul ripristino del Database master. 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 di un server, vedere Procedura: Ridenominazione di un computer che ospita un'istanza autonoma di SQL Server e Procedura: Ridenominazione di 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 ulteriori informazioni, vedere RESTORE SERVICE MASTER KEY (Transact-SQL).
Eseguire sp_replrestart. Questa stored procedure consente di impostare l'agente di lettura log in modo che le transazioni già replicate nel log del database di distribuzione vengano ignorate. Le transazioni applicate dopo il completamento della stored procedure vengono elaborate dall'agente di lettura log. Per ulteriori informazioni, vedere sp_replrestart (Transact-SQL).
Dopo aver eseguito la stored procedure, riavviare l'agente di lettura log. Per ulteriori informazioni, vedere Procedura: Avvio e interruzione di 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 consistenza dei dati. Per ulteriori informazioni, vedere Errori da ignorare nella replica transazionale.
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 ulteriori informazioni, vedere Distribuzione del log shipping.
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 ulteriori informazioni, vedere Failover su un database secondario per il log shipping e RESTORE (Transact-SQL).
Ripristinare i database msdb e master dal server primario al server secondario. Per ulteriori informazioni, vedere Considerazioni sul ripristino dei database model e msdb e Considerazioni sul ripristino del Database master. 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 di un server, vedere Procedura: Ridenominazione di un computer che ospita un'istanza autonoma di SQL Server e Procedura: Ridenominazione di 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 ulteriori 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. La modalità di filtro applicata alla pubblicazione determina i dati che è possibile caricare:
Se alla pubblicazione non è stato applicato alcun filtro, è possibile aggiornare il database di pubblicazione sincronizzandolo con il Sottoscrittore più aggiornato.
Se alla pubblicazione è stato applicato un filtro, potrebbe non essere possibile aggiornare il database di pubblicazione. 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 esiste almeno un Sottoscrittore per ogni partizione di dati, la sincronizzazione con il Sottoscrittore di ogni partizione consente di aggiornare il database di pubblicazione. Tuttavia, se i dati nella partizione Ovest non sono stati replicati in alcun Sottoscrittore, non sarà possibile aggiornarli nel server di pubblicazione. In questo caso è consigliabile reinizializzare tutte le sottoscrizioni in modo da garantire la convergenza dei dati nel server di pubblicazione e nei Sottoscrittori. Per ulteriori informazioni, vedere Reinizializzazione di una sottoscrizione.
Se si esegue la sincronizzazione con un Sottoscrittore che esegue una versione di SQL Server precedente a SQL Server 2005, la sottoscrizione non può essere anonima, ma deve essere una sottoscrizione client o una sottoscrizione server (chiamate sottoscrizioni locali e sottoscrizioni globali nelle versioni precedenti del prodotto). Per ulteriori informazioni, vedere Sincronizzazione dei dati.
Vedere anche