Mirroring e replicazione del database (SQL Server)

Si applica a:SQL Server

Per migliorare la disponibilità del database di pubblicazione è possibile utilizzare il mirroring del database in combinazione con la replica. Il mirroring del database 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 il database principale. Gli aggiornamenti apportati dai client al database principale vengono applicati all'altra copia del database, definita database mirror. Il processo di mirroring prevede l'applicazione nel database mirror del log delle transazioni relativo a ogni operazione di inserimento, aggiornamento o eliminazione eseguita sul database principale.

Il failover della replica su un server mirror è supportato completamente per i database di pubblicazione e parzialmente per i database di sottoscrizione. Il mirroring del database non è supportato per il database di distribuzione. Per informazioni sul recupero di un database di distribuzione o di un database di sottoscrizione senza che sia necessario riconfigurare la replica, vedere Backup e ripristino di database replicati.

Nota

Dopo un failover, il server mirror diventa il server principale. In questo argomento "principale" e "mirror" si riferiscono sempre al server principale originale e al server mirror.

Requisiti e considerazioni per l'utilizzo della replica con il mirroring del database

Prendere in considerazione i requisiti e le considerazioni seguenti quando si utilizza la replica con il mirroring del database:

  • I server principale e mirror devono condividere un server di distribuzione. È consigliabile che quest'ultimo sia un server di distribuzione remoto, in quanto garantisce una maggiore tolleranza di errore nel caso si verifichi un failover non pianificato sul server di pubblicazione.

  • Il mirroring del database di pubblicazione è supportato nella replica di tipo merge e nella replica transazionale con Sottoscrittori di sola lettura o Sottoscrittori ad aggiornamento in coda. Non sono supportati i sottoscrittori con aggiornamento immediato, i server di pubblicazione Oracle, i server di pubblicazione in una topologia peer-to-peer e la ripubblicazione.

  • I metadati e gli oggetti esterni al database, ad esempio account di accesso, processi, server collegati e così via, non vengono copiati nel database mirror. Se i metadati e gli oggetti sono necessari nel database mirror, è necessario copiarli manualmente. Per altre informazioni, vedere Gestione di account di accesso e di processi dopo un cambio di ruolo (SQL Server).

Configurazione della replicazione con il mirroring del database

Per configurare la replica e il mirroring del database è necessario eseguire cinque operazioni. Ogni operazione è descritta in dettaglio nella sezione seguente.

  1. Configurare il Publisher.

  2. Configurare il mirroring del database.

  3. Configurare il database mirror in modo che utilizzi lo stesso server di distribuzione del database principale.

  4. Configurare gli agenti di replica per il failover.

  5. Aggiungere il database principale e il database mirror a Monitoraggio della replica.

Le operazioni ai passaggi 1 e 2 possono anche essere eseguite in ordine inverso.

Per configurare il mirroring di un database di pubblicazione

  1. Configurare il server di pubblicazione:

    1. È consigliabile utilizzare un server di distribuzione remoto. Per altre informazioni sulla configurazione della distribuzione, vedere Configurare la distribuzione.

    2. È possibile abilitare un database per pubblicazioni snapshot e transazionali e/o pubblicazioni di tipo merge. Nel caso di database con mirroring che includono più tipi di pubblicazione, è necessario abilitare il database per entrambi i tipi in corrispondenza dello stesso nodo usando sp_replicationdboption. È ad esempio possibile eseguire le chiamate di stored procedure seguenti nel server principale:

      exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true;  
      exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true;  
      

      Per altre informazioni sulla creazione di pubblicazioni, vedere Pubblicare dati e oggetti di database.

  2. Configurare il mirroring del database. Per altre informazioni, vedere Stabilire una sessione di mirroring del database tramite autenticazione di Windows (SQL Server Management Studio) e Impostazione del mirroring del database (SQL Server).

  3. Configurare la distribuzione per il server mirror. Assegnare al database mirror lo stesso nome del server di pubblicazione e specificare lo stesso server di distribuzione e la stessa cartella snapshot utilizzati dal database principale. Se ad esempio si configura la replica con stored procedure, eseguire sp_adddistpublisher nel server di distribuzione e quindi sp_adddistributor nel mirror. Per sp_adddistpublisher:

    • Impostare il valore del parametro @publisher sul nome di rete del server mirror.

    • Impostare il valore del parametro @working_directory sulla cartella snapshot usata dal server principale.

  4. Specificare il nome del database mirror per il parametro dell'agente -PublisherFailoverPartner. Agente Questo parametro è necessario ai seguenti agenti per identificare il mirror dopo il failover:

    • Agente di snapshot (per tutte le pubblicazioni)

    • Agente di lettura del log (per tutte le pubblicazioni transazionali)

    • Agente di lettura della coda (per le pubblicazioni transazionali che supportano le sottoscrizioni di aggiornamento in coda)

    • Agente di merge (per le sottoscrizioni di tipo merge)

    • Listener di replica di SQL Server (replisapi.dll: per le sottoscrizioni merge sincronizzate tramite sincronizzazione Web)

    • Controllo ActiveX SQL Merge (per le sottoscrizioni merge sincronizzate con il controllo)

    L'agente di distribuzione e il controllo ActiveX Distribuzione non dispongono di questo parametro perché non si connettono al server di pubblicazione.

    Le modifiche apportate al parametro dell'agente verranno applicate al successivo avvio dell'agente. Se l'agente è in esecuzione continua, è necessario arrestarlo e riavviarlo. I parametri possono essere specificati nei profili agenti e al prompt dei comandi. Per altre informazioni, vedi:

    È consigliabile aggiungere il parametro -PublisherFailoverPartner a un profilo agente e quindi specificare il nome del database mirror nel profilo. Ad esempio, se si configura la replica con le stored procedure:

    -- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles.  
    -- Select the profile id of the profile that needs to be updated from the result set.  
    -- In the agent_type column returned by sp_help_agent_profile:   
    -- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.  
    
    exec sp_help_agent_profile;  
    
    -- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1).  
    -- Execute sp_add_agent_parameter in the context of the distribution database.  
    exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';  
    
    -- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6).  
    -- Execute sp_add_agent_parameter in the context of the distribution database.  
    exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';  
    
  5. Aggiungere il database principale e il database mirror a Monitoraggio della replica. Per ulteriori informazioni, vedere Aggiungere e rimuovere server di pubblicazione in Monitoraggio replica.

Manutenzione di un database di pubblicazione mirrorato

La gestione di un database di pubblicazione con mirroring è sostanzialmente analoga a quella di un database senza mirroring, con le considerazioni seguenti:

  • L'amministrazione e il monitoraggio devono essere eseguiti sul server attivo. In SQL Server Management Studio le pubblicazioni sono incluse nella cartella Pubblicazioni locali solo per il server attivo. Se si esegue ad esempio il failover sul database mirror, le pubblicazioni vengono visualizzate nel database mirror e non più nel database principale. Se il database esegue il failover nel database mirror, potrebbe essere necessario aggiornare manualmente Management Studio e Replication Monitor affinché la modifica venga visualizzata.

  • In Monitoraggio replica vengono visualizzati i nodi del server di pubblicazione nell'albero degli oggetti per il server principale e il server mirror. Se il server principale è il server attivo, le informazioni relative alla pubblicazione vengono visualizzate solo nel nodo principale in Monitoraggio replica.

    Se il server mirror è il server attivo:

    • Se un agente presenta un errore, l'errore è indicato solo sul nodo principale, non sul nodo speculare.

    • Se il server principale non è disponibile, i nodi principale e mirror visualizzano elenchi di pubblicazioni identici. Il monitoraggio deve essere eseguito sulle pubblicazioni sotto il nodo mirror.

  • Quando si usano stored procedure o Replication Management Objects (RMO) per amministrare la replica nel mirror, nei casi in cui si specifica il nome del Publisher, è necessario specificare il nome dell'istanza in cui il database è stato abilitato per la replica. Per determinare il nome appropriato, utilizzare la funzione publishingservername.

    Quando si esegue il mirroring di un database di pubblicazione, i metadati della replica archiviati nel database con mirroring sono identici a quelli archiviati nel database principale. Ne consegue che, per i database di pubblicazione abilitati per la replica nel database principale, il nome dell'istanza del server di pubblicazione archiviato in tabelle di sistema nel database mirror equivale al nome del database principale e non a quello del database mirror. Ciò influisce sulla manutenzione e sulla configurazione della replica se viene eseguito il failover del database di pubblicazione sul server mirror. Se, ad esempio, si sta configurando la replica con stored procedure sul database mirror dopo un failover e si vuole aggiungere una sottoscrizione pull a un database di pubblicazione abilitato sul database principale, è necessario specificare il nome del server principale invece del nome del server mirror per il parametro @publisher di sp_addpullsubscription o sp_addmergepullsubscription.

    Se si abilita un database di pubblicazione sul server mirror dopo che è stato eseguito il failover sul server mirror, il nome dell'istanza del server di pubblicazione archiviato in tabelle di sistema equivale al nome del server mirror. In questo caso, per il parametro @publisher è necessario usare il nome del database mirror.

    Nota

    In alcuni casi, ad esempio se si usa sp_addpublication, il parametro @publisher è supportato solo per server di pubblicazione non SQL Server. Non è quindi rilevante per il mirroring del database di SQL Server.

  • Per sincronizzare una sottoscrizione in Management Studio dopo un failover: sincronizzare le sottoscrizioni pull nel Sottoscrittore; e sincronizzare le sottoscrizioni push nell’Editore attivo.

Funzionamento della replica dopo l'eliminazione del mirroring

Se si elimina il mirroring da un database pubblicato tenere presente quanto segue:

  • Se il database di pubblicazione sul server principale non è più sottoposto a mirroring, la replica continua a funzionare invariata rispetto al database principale originale.

  • Se viene eseguito il failover del database di pubblicazione dal server principale sul server mirror e la relazione di mirroring viene disabilitata o eliminata, gli agenti di replica non funzioneranno sul database mirror. Se il database principale è definitivamente perso, disattivare e quindi riconfigurare la replica specificando il server mirror come server di pubblicazione.

  • Se il mirroring del database viene eliminato completamente, il database mirror si trova in stato di recupero e deve essere ripristinato affinché funzioni. Il funzionamento del database recuperato in relazione alla replica dipende dall'impostazione dell'opzione KEEP_REPLICATION. Questa opzione indica che durante il ripristino di un database pubblicato in un server diverso da quello in cui è stato creato il backup le impostazioni di replica devono essere mantenute inalterate. Utilizzare l'opzione KEEP_REPLICATION solo quando l'altro database di pubblicazione non è disponibile. L'opzione non è supportata se l'altro database di pubblicazione è ancora intatto e viene replicato. Per altre informazioni sulle KEEP_REPLICATION, vedere RESTORE (Transact-SQL).

Comportamento dell'agente di lettura dei log

Nella tabella seguente viene descritto il funzionamento dell'agente di lettura log per le diverse modalità operative del mirroring del database.

Modalità operativa Funzionamento dell'agente di lettura log quando il database mirror non è disponibile
Modalità a sicurezza elevata con failover automatico Se il database mirror non è disponibile, l'agente di lettura log propaga i comandi al database di distribuzione. Non è possibile eseguire il failover dal server principale al server mirror finché il server mirror non è nuovamente online e non ha ricevuto tutte le transazioni dal server principale.
Modalità a prestazioni elevate Se il database mirror non è disponibile, il database principale viene eseguito senza protezione, ovvero senza mirroring. Tuttavia, l'agente di lettura log replica solo le transazioni salvate nel database mirror. Se si forza il servizio e il server mirror assume il ruolo del server principale, il Log Reader Agent opererà sul mirror e inizierà a rilevare le nuove transazioni.

Tenere presente che la latenza di replica aumenterà se il server mirror rimane indietro rispetto al server principale.
Modalità a sicurezza elevata senza failover automatico Tutte le transazioni di cui è stato eseguito il commit vengono salvate su disco nel database mirror. L'agente di lettura log replica solo le transazioni salvate nel server mirror. Se il server mirror non è disponibile, il server principale non consente alcuna operazione nel database. L'agente di lettura log non può pertanto replicare alcuna transazione.

Vedi anche

Replica di SQL Server
Log Shipping e replicazione (SQL Server)