Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Un determinato database può essere sottoposto a mirroring o a log shipping; può anche essere sottoposto contemporaneamente a mirroring e a log shipping. Per scegliere l'approccio da usare, considerare quanto segue:
Quanti server di destinazione sono necessari?
Se è necessario un solo database di destinazione, il mirroring del database è la soluzione consigliata.
Se sono necessari più database di destinazione, è necessario usare il log shipping, da solo o con il mirroring del database. La combinazione di questi approcci offre i vantaggi del mirroring del database insieme al supporto per più destinazioni fornite dal log shipping.
Se è necessario ritardare il ripristino del log nel database di destinazione (in genere, per proteggersi da errori logici), usare il log shipping, da solo o con il mirroring del database.
In questo argomento vengono illustrate le considerazioni relative alla combinazione di log shipping e mirroring del database.
Annotazioni
Per introduzione a queste tecnologie, vedere Mirroring del database (SQL Server) e Informazioni su Log Shipping (SQL Server).
Combinazione del log shipping e del mirroring del database
Il database principale in una sessione di mirroring può fungere anche da database primario in una configurazione di log shipping o viceversa, perché la condivisione di backup del log shipping è intatta. La sessione di mirroring del database viene eseguita in qualsiasi modalità operativa, sia sincrona (con sicurezza delle transazioni impostata su FULL) sia asincrona (con sicurezza delle transazioni impostata su OFF).
Annotazioni
Per usare il mirroring del database in un database, è sempre necessario il modello di recupero completo.
In genere, quando si combina il log shipping e il mirroring del database, la sessione di mirroring viene stabilita prima del log shipping, anche se questa operazione non è necessaria. Il database principale corrente viene quindi configurato come primario per il log shipping (database principale/primario), insieme a uno o più database secondari remoti. Inoltre, il database mirror deve essere configurato come primario per il log shipping (database mirror/primario). I database secondari per il log shipping devono trovarsi in istanze del server diverse rispetto al server principale/primario o al server mirror/primario.
Annotazioni
Le impostazioni di distinzione tra maiuscole e minuscole dei server coinvolti nel log shipping devono corrispondere.
Durante una sessione di log shipping, i processi di backup nel database primario creano backup del log in una cartella di backup. Da qui, i backup vengono copiati dai processi di copia dei server secondari. Affinché i processi di backup e i processi di copia abbiano esito positivo, devono avere accesso alla cartella di backup per il log shipping. Per ottimizzare la disponibilità del server primario, è consigliabile stabilire la cartella di backup in un percorso di backup condiviso in un computer host separato. Assicurarsi che tutti i server di log shipping, incluso il server mirror/primario, possano accedere al percorso di backup condiviso (noto come condivisione di backup).
Per consentire la continuazione del log shipping dopo il failover del mirroring del database, è necessario configurare anche il server mirror come server primario, usando la stessa configurazione usata per il database primario nel database principale. Il database mirror è nello stato di ripristino, che impedisce ai processi di backup di eseguire il backup del log nel database mirror. In questo modo, il database mirror/primario non interferisce con il database principale/primario i cui backup del log sono attualmente copiati dai server secondari. Per evitare avvisi spuri, dopo l'esecuzione del processo di backup nel database mirror/primario, il processo di backup registra un messaggio alla tabella log_shipping_monitor_history_detail e il processo dell'agente restituisce uno stato di esito positivo.
Il database mirror/primario è inattivo nella sessione di log shipping. Tuttavia, se il mirroring esegue il failover, il precedente database mirror diventa operativo come database principale. A questo punto, tale database diventa attivo anche come database primario per il log shipping. I processi di backup di log shipping che in precedenza non erano in grado di spedire il log su quel database iniziano a spedire i log. Viceversa, un failover fa sì che il database principale/primario precedente diventi il nuovo database mirror/primario e entri nello stato di ripristino e i processi di backup in tale database cessano di eseguire il backup del log.
Annotazioni
In caso di failover automatico, il passaggio al ruolo di mirror si verifica quando il precedente database principale si unisce nuovamente alla sessione di mirroring.
Per l'esecuzione in modalità a sicurezza elevata con failover automatico, la sessione di mirroring è configurata con un'istanza del server aggiuntiva nota come witness. Se il database principale viene perso per qualsiasi ragione dopo la sincronizzazione del database e se il server mirror e il witness possono comunque comunicare tra loro, si verifica il failover automatico. Un failover automatica permette al server mirror di assumere il ruolo principale e portare online il suo database come database principale. Se il percorso di backup per il log shipping è accessibile al nuovo server principale/primario, i processi di backup iniziano a spedire i backup del log in tale percorso. La modalità sincrona del mirroring del database garantisce che la catena di log non sia influenzata da un failover di mirroring e che venga ripristinato solo il log valido. I server secondari continuano a copiare i backup del log senza sapere che un'istanza del server diversa è diventata il server primario.
Quando si usa un monitoraggio di log shipping locale, non sono necessarie considerazioni speciali per soddisfare questo scenario. Per informazioni sull'uso di un'istanza di monitoraggio remoto con questo scenario, vedere "Impatto del mirroring del database in un'istanza di monitoraggio remoto" più avanti in questo argomento.
Passaggio dal database principale al database mirror
La figura seguente mostra come il log shipping e il mirroring del database lavorano insieme quando il mirroring è in modalità di alta sicurezza con failover automatico. Inizialmente, Server_A è il server principale per il mirroring e il server primario per il log shipping. Server_B è il server mirror ed è configurato anche come server primario, che è attualmente inattivo. Server_C e Server_D sono server secondari per il log shipping. Per ottimizzare la disponibilità della sessione di log shipping, il percorso di backup si trova in una directory condivisa su un computer host separato.
Dopo un failover di mirroring, il nome del server primario definito nel server secondario rimane invariato. .
Impatto del mirroring del database in un'istanza di monitoraggio remoto
Quando il log shipping viene usato con un'istanza di monitoraggio remoto, la combinazione della sessione di log shipping e del mirroring del database influisce sulle informazioni nelle tabelle di monitoraggio. Le informazioni sul database primario sono una combinazione di quella configurata nel server principale/primario e nel monitoraggio configurato in ogni database secondario.
Per mantenere il monitoraggio il più facile possibile, quando si usa un monitoraggio remoto, è consigliabile specificare il nome primario originale durante la configurazione del database primario nel database secondario. Questo approccio facilita anche la modifica della configurazione del log shipping da Microsoft SQL Server Agent. Per altre informazioni sul monitoraggio, vedere Monitorare il log shipping (Transact-SQL).
Configurazione del mirroring e del log shipping insieme
Per configurare insieme il mirroring del database e il log shipping, sono necessari i passaggi seguenti:
Ripristinare i backup del database principale/primario con NORECOVERY in un'altra istanza del server da usare successivamente come database mirroring del database per il database principale/primario. Per altre informazioni, vedere Preparazione di un database mirror per il mirroring (SQL Server).
Configurare il mirroring del database. Per altre informazioni, vedere Stabilire una sessione di mirroring del database usando l'autenticazione di Windows (SQL Server Management Studio) o la configurazione del mirroring del database (SQL Server).
Ripristinare i backup del database principale/primario su altre istanze del server per utilizzarli successivamente come database secondari per il log shipping del database principale.
Configurare il log shipping nel database principale come database primario per uno o più database secondari.
È necessario configurare una singola condivisione come directory di backup (una condivisione di backup). In questo modo, dopo il passaggio del ruolo tra i server principale e mirror, i processi di backup continuano a scrivere nella stessa directory di prima. È consigliabile assicurarsi che questa condivisione si trovi in un server fisico diverso dai server che ospitano i database coinvolti nel mirroring e nel log shipping.
Per ulteriori informazioni, vedere Configurare il trasferimento dei log (SQL Server).
Esegui il failover manuale dal principale al mirror.
Per eseguire un failover manuale:
Configurare il log shipping sul nuovo principale (precedentemente specchio) come database primario.
Importante
Non eseguire alcuna configurazione da un database secondario.
È necessario usare la stessa condivisione di backup usata nel passaggio 4.
L'interfaccia per il log shipping delle transazioni in SQL Server Management Studio supporta un solo database primario per ogni configurazione di log shipping. Pertanto, è necessario utilizzare stored procedure per configurare la nuova entità come primaria.
Eseguire un altro failover manuale per eseguire il failback all'entità originale.