Failover di un gruppo di disponibilità Always On in Linux

  • Articolo

Si applica a:SQL Server - Linux

Nel contesto di un gruppo di disponibilità, il ruolo primario e il ruolo secondario delle repliche di disponibilità sono generalmente intercambiabili in un processo noto come failover. Sono disponibili tre tipi di failover: failover automatico (senza perdita di dati), failover manuale pianificato (senza perdita di dati) e failover manuale forzato (con possibile perdita di dati), in genere chiamato failover forzato. Il failover automatico e il failover manuale pianificato consentono di conservare tutti i dati. Per un gruppo di disponibilità, il failover avviene a livello di replica di disponibilità. In pratica, il failover di un gruppo di disponibilità viene eseguito in una delle relative repliche secondarie, ovvero la destinazione di failover corrente.

Per informazioni di base sul failover, vedere Failover e modalità di failover.

Failover manuale

Usare gli strumenti per la gestione di cluster per eseguire il failover di un gruppo di disponibilità gestito tramite un modulo di gestione cluster esterno. Se, ad esempio, una soluzione usa Pacemaker per gestire un cluster Linux, usare pcs per eseguire failover manuali in RHEL o Ubuntu. In SLES usare crm.

Importante

In condizioni normali, non eseguire il failover con Transact-SQL o con gli strumenti di gestione di SQL Server come SSMS o PowerShell. Quando CLUSTER_TYPE = EXTERNAL, l'unico valore accettabile per FAILOVER_MODE è EXTERNAL. Con queste impostazioni, tutte le azioni di failover manuale o automatico vengono eseguite dal modulo di gestione cluster esterno. Per istruzioni su come forzare il failover con potenziale perdita di dati, vedere Forzare il failover.

Passaggi per il failover manuale

Per eseguire il failover, la replica secondaria che diventerà primaria deve essere sincrona. Se una replica secondaria è asincrona, modificare la modalità di disponibilità.

Il failover manuale prevede due passaggi.

Prima di tutto, si esegue manualmente il failover spostando la risorsa del gruppo di disponibilità dal nodo del cluster proprietario delle risorse in un nuovo nodo.

Il cluster esegue il failover della risorsa del gruppo di disponibilità e aggiunge un vincolo di posizione. Con questo vincolo, la risorsa viene configurata per l'esecuzione nel nuovo nodo. Il vincolo deve essere rimosso per una corretta esecuzione del failover in futuro.

Successivamente, si rimuove il vincolo di posizione.

Passaggio 1: Eseguire manualmente il failover spostando la risorsa del gruppo di disponibilità

Per eseguire manualmente il failover di una risorsa del gruppo di disponibilità denominata ag_cluster in un nodo del cluster denominato nodeName2, eseguire il comando appropriato per la distribuzione:

  • Esempio di RHEL/Ubuntu

    sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S

  • Esempio di SLES

    crm resource migrate ag_cluster nodeName2 --lifetime=30S

Importante

Quando si usa l'opzione --lifetime, il vincolo di posizione creato per spostare la risorsa è di natura temporanea ed è valido per 30 secondi nell'esempio precedente. Il vincolo temporaneo non viene cancellato automaticamente e può essere visualizzato nell'elenco dei vincoli, ma come vincolo scaduto. I vincoli scaduti non influiscono sul comportamento di failover del cluster pacemaker. Se non si usa l'opzione --lifetime durante lo spostamento della risorsa, è necessario rimuovere un vincolo di posizione aggiunto automaticamente come indicato di seguito.

Passaggio 2. Rimuovere il vincolo di posizione

Durante un failover manuale, il comando pcsmove o il comando crmmigrate aggiunge un vincolo di posizione per consentire il posizionamento della risorsa nel nuovo nodo di destinazione. Per visualizzare il nuovo vincolo, eseguire il comando seguente dopo aver spostato manualmente la risorsa:

  • Esempio di RHEL/Ubuntu

    sudo pcs constraint list --full

  • Esempio di SLES

    crm config show

Ecco un esempio di vincolo creato per effetto di un failover manuale. Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

Nota

Il nome della risorsa del gruppo di disponibilità nei cluster Pacemaker in Red Hat Enterprise Linux 8. x e Ubuntu 18.04 potrebbe essere simile ag_cluster-clone poiché la nomenclatura relativa alle risorse è passata all'uso di risorse clone promotable.

  • Esempio di RHEL/Ubuntu

    Nel comando seguente cli-prefer-ag_cluster-master è l'ID del vincolo che deve essere rimosso. sudo pcs constraint list --full restituisce questo ID.

    sudo pcs resource clear ag_cluster-master

    O

    sudo pcs constraint remove cli-prefer-ag_cluster-master

    In alternativa, è possibile eseguire lo spostamento e la cancellazione dei vincoli generati automaticamente in un'unica riga come descritto di seguito. L'esempio seguente usa la terminologia delle risorse clone in base a Red Hat Enterprise Linux 8.x.

    sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone

  • Esempio di SLES

    Nel comando seguente cli-prefer-ms-ag_cluster è l'ID del vincolo. crm config show restituisce questo ID.

    crm configure
delete cli-prefer-ms-ag_cluster 
commit

Nota

Il failover automatico non comporta l'aggiunta di un vincolo di posizione, quindi non è necessaria alcuna operazione di pulizia.

Per altre informazioni:

Forzare il failover

Il failover forzato è destinato essenzialmente al ripristino di emergenza. In questo caso non è possibile eseguire il failover con gli strumenti per la gestione di cluster perché il data center principale non è attivo. Se si forza il failover in una replica secondaria non sincronizzata, è possibile che vengano persi alcuni dati. Forzare il failover solo se è necessario ripristinare immediatamente il servizio nel gruppo di disponibilità e si è disposti a rischiare la perdita di dati.

Se non è possibile usare gli strumenti per la gestione di cluster per interagire con il cluster, ad esempio se il cluster non risponde a causa di un evento di emergenza nel data center primario, potrebbe essere necessario forzare il failover in modo da ignorare il modulo di gestione cluster esterno. Questa procedura è sconsigliata per le normali operazioni perché comporta il rischio di perdita di dati. Adottarla quando gli strumenti per la gestione di cluster non riescono a eseguire l'azione di failover. Dal punto di vista funzionale, questa procedura è simile all'esecuzione di un failover manuale forzato su un gruppo di disponibilità in Windows.

La procedura per forzare il failover illustrata di seguito è specifica di SQL Server in Linux.

  1. Verificare che la risorsa del gruppo di disponibilità non sia più gestita dal cluster.

    • Impostare la risorsa in modalità non gestita nel nodo del cluster di destinazione. Questo comando segnala all'agente di arrestare il monitoraggio e la gestione della risorsa. Ad esempio:
    sudo pcs resource unmanage <resourceName>
    • Se il tentativo di impostare la risorsa in modalità non gestita non riesce, eliminare la risorsa. Ad esempio:
    sudo pcs resource delete <resourceName>

    Nota

    Quando si elimina una risorsa, vengono eliminati anche tutti i vincoli associati.

  2. Nell'istanza di SQL Server che ospita la replica secondaria, impostare la variabile del contesto della sessione external_cluster.

    EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';

  3. Eseguire il failover del gruppo di disponibilità con Transact-SQL. Nell'esempio seguente sostituire <MyAg> con il nome del gruppo di disponibilità. Connettersi all'istanza di SQL Server che ospita la replica secondaria di destinazione ed eseguire il comando seguente:

    ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;

  4. Dopo un failover forzato, ripristinare lo stato integro del gruppo di disponibilità prima di riavviare il monitoraggio e la gestione delle risorse cluster o di creare nuovamente la risorsa del gruppo di disponibilità. Rivedere Attività essenziali dopo un failover forzato.

  5. Riavviare il monitoraggio e la gestione delle risorse cluster:

Per riavviare il monitoraggio e la gestione delle risorse cluster, eseguire il comando seguente:

sudo pcs resource manage <resourceName>
sudo pcs resource cleanup <resourceName>

Se la risorsa cluster è stata eliminata, crearla di nuovo. Per creare nuovamente la risorsa cluster, seguire le istruzioni in Creare una risorsa del gruppo di disponibilità.

Importante

Non usare i passaggi precedenti per le esercitazioni sul ripristino di emergenza perché comportano il rischio di perdita di dati. In alternativa, modificare la replica asincrona in sincrona e seguire le istruzioni per il failover manuale normale.

Monitoraggio a livello di database e trigger di failover

Per CLUSTER_TYPE=EXTERNAL, la semantica del trigger di failover è diversa rispetto al cluster WSFC. Quando il gruppo di disponibilità si trova in un'istanza di SQL Server in un cluster WSFC, la disattivazione dello stato ONLINE del database ha l'effetto di generare un errore di integrità del gruppo di disponibilità. In risposta a questa situazione, il modulo di gestione cluster attiva un'azione di failover. In Linux, l'istanza di SQL Server non è in grado di comunicare con il cluster. Il monitoraggio dell'integrità del database viene eseguito dall'esterno verso l'interno. Se l'utente ha acconsentito esplicitamente al monitoraggio e al failover a livello di database (impostando l'opzione DB_FAILOVER=ON durante la creazione del gruppo di disponibilità), il cluster verificherà se lo stato del database è ONLINE ogni volta che eseguirà un'azione di monitoraggio. Il cluster esegue una query sullo stato in sys.databases. Per qualsiasi stato diverso da ONLINE, verrà attivato automaticamente un failover (se le condizioni di failover automatico sono soddisfatte). Il tempo effettivo del failover dipende dalla frequenza dell'azione di monitoraggio e dallo stato di aggiornamento del database in sys.databases.

Il failover automatico richiede almeno una replica sincrona.

Contenuto correlato

Contribuire alla documentazione di SQL

Il contenuto SQL può essere modificato. L'autore delle modifiche contribuirà a migliorare la documentazione e verrà accreditato come collaboratore alla realizzazione della pagina.

Per altre informazioni, vedere Come contribuire alla documentazione di SQL Server