Eseguire un failover manuale pianificato di un gruppo di disponibilità Always On (SQL Server)

  • Articolo

Si applica a:SQL Server

Questo argomento descrive come eseguire un failover manuale senza perdita di dati (un failover manuale pianificato) in un gruppo di disponibilità Always On usando SQL Server Management Studio, Transact-SQL o PowerShell in SQL Server. Per un gruppo di disponibilità il failover si verifica al livello di una replica di disponibilità. Un failover manuale pianificato, come un failover del gruppo di disponibilità Always On, comporta il passaggio della replica primaria precedente al ruolo secondario. Il failover attualmente comporta il passaggio della replica primaria precedente al ruolo secondario.

Un failover manuale pianificato è supportato solo quando la replica principale e la replica secondaria di destinazione sono in esecuzione in modalità commit sincrono e sono attualmente sincronizzate. Un failover manuale pianificato mantiene tutti i dati presenti nei database secondari associati al gruppo di disponibilità nella replica secondaria di destinazione. Dopo che la replica primaria precedente è passata al ruolo secondario, i relativi database diventano database secondari. Iniziano quindi a eseguire la sincronizzazione con i nuovi database primari. Dopo la transizione di tutti i database allo stato SYNCHRONIZED, la nuova replica secondaria diventa idonea a fungere da destinazione di un futuro failover manuale pianificato.

Nota

Se la replica primaria e le repliche secondarie sono configurate per la modalità di failover automatico, dopo la sincronizzazione, la replica secondaria può anche fungere da destinazione per un failover automatico. Per altre informazioni, vedere Modalità di disponibilità (gruppi di disponibilità Always On).

Operazioni preliminari

Importante

Esistono procedure specifiche per eseguire il failover di un gruppo di disponibilità per la scalabilità in lettura senza usare uno strumento di gestione cluster. Quando un gruppo di disponibilità contiene CLUSTER_TYPE = NONE, seguire le procedure descritte in Eseguire il failover di una replica primaria in un gruppo di disponibilità per scalabilità in lettura.

Limitazioni e restrizioni

  • Un comando del failover viene restituito non appena la replica secondaria di destinazione ha accettato il comando. Tuttavia, il recupero del database si verifica in modo asincrono dopo che il gruppo di disponibilità ha completato il failover.

  • La coerenza tra i database all'interno del gruppo di disponibilità potrebbe non essere mantenuta nel failover.

    Nota

    Il supporto delle transazioni distribuite e tra database varia in base alle versioni di SQL Server e del sistema operativo. Per altre informazioni, vedere Transazioni tra database e transazioni distribuite per gruppi di disponibilità Always On e mirroring del database (SQL Server).

Prerequisiti e restrizioni

  • La replica secondaria di destinazione e la replica primaria devono essere entrambe in esecuzione in modalità di disponibilità con commit sincrono.

  • La replica secondaria di destinazione deve essere attualmente sincronizzata con la replica primaria. Per tutti i database secondari della replica secondaria deve esser creato un join al gruppo di disponibilità. Devono essere sincronizzati anche con i database primari corrispondenti (ovvero i database secondari locali devono essere SINCRONIZZATI).

    Suggerimento

    Per determinare la conformità del failover di una replica secondaria, eseguire una query della colonna is_failover_ready nella DMV sys.dm_hadr_database_replica_cluster_states. Oppure è possibile esaminare la colonna Conformità Failover del dashboard del gruppo Always On.

  • Questa attività è supportata solo nella replica secondaria di destinazione. È necessario essere connessi all'istanza del server che ospita la replica secondaria di destinazione.

Sicurezza

Autorizzazioni

È necessaria l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità. È necessaria anche l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP oppure l'autorizzazione CONTROL SERVER.

Usare SQL Server Management Studio

Per eseguire manualmente il failover di un gruppo di disponibilità:

  1. In Esplora oggetti connettersi a un'istanza del server che ospita una replica secondaria del gruppo di disponibilità di cui eseguire il failover. Espandere l'albero di server.

  2. Espandere il nodo Disponibilità elevata AlwaysOn e il nodo Gruppi di disponibilità.

  3. Fare clic con il pulsante destro del mouse sul gruppo di disponibilità di cui eseguire il failover e selezionare Failover.

  4. Avvio della procedura guidata Gruppo di disponibilità di failover. Per altre informazioni, vedere Usare la procedura guidata Failover gruppo di disponibilità (SQL Server Management Studio).

Usare Transact-SQL

Per eseguire manualmente il failover di un gruppo di disponibilità:

  1. Connettersi all'istanza del server che ospita la replica secondaria di destinazione.

  2. Utilizzare l'istruzione ALTER AVAILABILITY GROUP , come indicato di seguito:

    ALTER AVAILABILITY GROUP nome_gruppo FAILOVER

    Nell'istruzione nome_gruppo è il nome del gruppo di disponibilità.

    Nell'esempio seguente viene eseguito il failover manuale del gruppo di disponibilità MyAg alla replica secondaria connessa:

    ALTER AVAILABILITY GROUP MyAg FAILOVER;

Utilizzare PowerShell

Per eseguire manualmente il failover di un gruppo di disponibilità:

  1. Cambiare la directory (cd) impostandola sull'istanza del server che ospita la replica secondaria di destinazione.

  2. Usare il cmdlet Switch-SqlAvailabilityGroup .

    Nota

    Per visualizzare la sintassi di un cmdlet, usare il cmdlet Get-Help nell'ambiente SQL Server PowerShell. Per altre informazioni, vedere la guida SQL Server PowerShell.

    Nell'esempio seguente viene eseguito il failover manuale del gruppo di disponibilità MyAg alla replica secondaria con il percorso specificato:

    Switch-SqlAvailabilityGroup -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg

    Per impostare e usare il provider PowerShell per SQL Server:

Completamento: dopo il failover manuale su un gruppo di disponibilità

Se è stato eseguito il failover al di fuori del set di failover automatico del gruppo di disponibilità, modificare i voti del quorum dei nodi di clustering di failover Windows Server per riflettere la nuova configurazione del gruppo di disponibilità. Per altre informazioni, vedere Clustering di failover Windows Server (WSFC) con SQL Server.

Eseguire il failover della replica primaria in un gruppo di disponibilità per scalabilità in lettura

Ogni gruppo di disponibilità include solo una replica primaria, che consente operazioni di lettura e scrittura. Per modificare la replica primaria, è possibile effettuare il failover. In un gruppo di disponibilità tipico il processo di failover è automatizzato da Gestione cluster. In un gruppo di disponibilità con tipo di cluster NONE, il processo di failover è manuale.

Esistono due modi per effettuare il failover della replica primaria in un gruppo di disponibilità con tipo di cluster NONE:

  • Failover manuale senza perdita di dati
  • Failover manuale forzato con perdita di dati

Failover manuale senza perdita di dati

Usare questo metodo quando la replica primaria è disponibile, ma è necessario modificare temporaneamente o definitivamente l'istanza che ospita la replica primaria. Per evitare una potenziale perdita di dati, prima di effettuare il failover manuale, verificare che la replica secondaria di destinazione sia aggiornata.

Per effettuare il failover manuale senza perdita di dati:

  1. Impostare la replica primaria corrente e la replica secondaria di destinazione come SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [AGRScale] 
     MODIFY REPLICA ON N'<node2>' 
     WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

  2. Per verificare che per le transazioni attive venga eseguito il commit della replica primaria e di almeno una replica secondaria sincrona, eseguire la query seguente:

    SELECT ag.name, 
   drs.database_id, 
   drs.group_id, 
   drs.replica_id, 
   drs.synchronization_state_desc, 
   ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
WHERE drs.group_id = ag.group_id;

    La replica secondaria è sincronizzata quando synchronization_state_desc è SYNCHRONIZED.

  3. Aggiornare REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT su 1.

    Lo script seguente imposta REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT su 1 in un gruppo di disponibilità denominato ag1. Prima di eseguire lo script seguente, sostituire ag1 con il nome del gruppo di disponibilità:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

    Questa impostazione assicura che per ogni transazione attiva venga eseguito il commit della replica primaria e di almeno una replica secondaria sincrona.

    Nota

    Questa impostazione non è specifica del failover e deve essere impostata in base ai requisiti dell'ambiente.

  4. Impostare la replica primaria e le repliche secondarie che non partecipano al failover offline per prepararsi alla modifica del ruolo:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Alzare il livello della replica secondaria di destinazione a replica primaria.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Aggiornare il ruolo della replica primaria precedente e di altre precedenti in SECONDARY, quindi eseguire il comando seguente nell'istanza di SQL Server che ospita la replica primaria precedente:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY);

    Nota

    Per eliminare un gruppo di disponibilità, usare DROP AVAILABILITY GROUP. Per un gruppo di disponibilità creato con il tipo di cluster NONE o EXTERNAL, eseguire il comando su tutte le repliche che fanno parte del gruppo di disponibilità.

  7. Riprendere lo spostamento dati, eseguire il comando seguente per ogni database nel gruppo di disponibilità nell'istanza di SQL Server che ospita la replica primaria:

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Ricreare ogni listener creato a scopo di scalabilità in lettura e che non rientra nella gestione cluster. Se il listener originale punta alla replica primaria precedente, rimuoverlo e ricrearlo in modo che punti a quella nuova.

Failover manuale forzato con perdita di dati

Se la replica primaria non è disponibile e non può essere ripristinata immediatamente, è necessario forzare un failover nella replica secondaria con perdita di dati. Tuttavia, se la replica primaria originale viene ripristinata dopo il failover, assumerà il ruolo primario. Per evitare che ogni replica si trovi in uno stato diverso, rimuovere la replica primaria originale dal gruppo di disponibilità dopo un failover forzato con perdita di dati. Quando la replica primaria originale torna online, rimuovere completamente il gruppo di disponibilità.

Per forzare un failover manuale con perdita di dati dalla replica primaria N1 alla replica secondaria N2, seguire questa procedura:

  1. Nella replica secondaria (N2) avviare il failover forzato:

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. Nella nuova replica primaria (N2) rimuovere la replica primaria originale (N1):

    ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';

  3. Verificare che tutto il traffico dell'applicazione punti al listener e/o alla nuova replica primaria.

  4. Se la replica primaria originale (N1) torna online, portare immediatamente offline AGRScale del gruppo di disponibilità nella replica primaria originale (N1):

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Se sono presenti dati o modifiche non sincronizzate, conservare questi dati tramite backup o altre opzioni di replica dei dati adatte alle esigenze aziendali.

  6. Rimuovere quindi il gruppo di disponibilità dalla replica primaria originale (N1):

    DROP AVAILABILITY GROUP [AGRScale];

  7. Eliminare il database del gruppo di disponibilità nella replica primaria originale (N1):

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Facoltativo) Se lo si desidera, è ora possibile aggiungere di nuovo N1 come nuova replica secondaria ad AGRScale del gruppo di disponibilità.

Vedi anche