Gestire i gruppi di disponibilità Always On in Linux

  • Articolo

Si applica a:SQL Server - Linux

Aggiornare un gruppo di disponibilità

Prima di aggiornare un gruppo di disponibilità, rivedere i modelli e le procedure in Aggiornare le repliche del gruppo di disponibilità.

Le sezioni seguenti illustrano come eseguire un aggiornamento in sequenza relativo a istanze di SQL Server in Linux con gruppi di disponibilità.

Procedura di aggiornamento in Linux

Quando le repliche del gruppo di disponibilità si trovano su istanze di SQL Server in Linux, il tipo di cluster del gruppo di disponibilità è EXTERNAL o NONE. Un gruppo di disponibilità controllato da un modulo di gestione cluster diverso da WSFC (Windows Server Failover Cluster) è di tipo EXTERNAL. Pacemaker con Corosync è un esempio di modulo di gestione cluster esterno. Il tipo di cluster di un gruppo di disponibilità senza modulo di gestione cluster è NONE. La procedura di aggiornamento descritta di seguito riguarda specificamente i gruppi di disponibilità con tipo di cluster EXTERNAL o NONE.

L'ordine in cui si aggiornano le istanze dipende dal fatto che il loro ruolo sia secondario e che ospitino o meno repliche sincrone o asincrone. Si aggiornano prima le istanze di SQL Server che ospitano repliche secondarie asincrone e dopo quelle che ospitano repliche secondarie sincrone.

Nota

Se un gruppo di disponibilità ha solo repliche asincrone, per evitare perdite di dati impostarne una come sincrona e attendere che venga sincronizzata. Aggiornare quindi questa replica.

Prima di iniziare, eseguire il backup di ogni database.

  1. Arrestare la risorsa nel nodo che ospita la replica secondaria a cui è destinato l'aggiornamento.

    Prima di eseguire il comando di aggiornamento, arrestare la risorsa per evitare che venga monitorata dal cluster e che ne venga eseguito inutilmente il failover. L'esempio seguente aggiunge al nodo un vincolo di posizione che determina l'arresto della risorsa. Aggiornare ag_cluster-master con il nome della risorsa e nodeName1 con il nodo che ospita la replica a cui è destinato l'aggiornamento.

    pcs constraint location ag_cluster-master avoids nodeName1

  2. Aggiornare SQL Server sulla replica secondaria.

    L'esempio seguente aggiorna i pacchetti mssql-server e mssql-server-ha.

    sudo yum update mssql-server
sudo yum update mssql-server-ha

  3. Rimuovere il vincolo di posizione.

    Prima di eseguire il comando di aggiornamento, arrestare la risorsa per evitare che venga monitorata dal cluster e che ne venga eseguito inutilmente il failover. L'esempio seguente aggiunge al nodo un vincolo di posizione che determina l'arresto della risorsa. Aggiornare ag_cluster-master con il nome della risorsa e nodeName1 con il nodo che ospita la replica a cui è destinato l'aggiornamento.

    pcs constraint remove location-ag_cluster-master-rhel1--INFINITY

    Come procedura consigliata, assicurarsi che la risorsa sia avviata (tramite il comando pcs status) e che la replica secondaria sia connessa e sincronizzata dopo l'aggiornamento.

  4. Al termine dell'aggiornamento di tutte le repliche secondarie, eseguire manualmente il failover in una delle repliche secondarie sincrone.

    Per i gruppi di disponibilità con tipo di cluster EXTERNAL, eseguire il failover usando gli strumenti per la gestione di cluster. Per il failover dei gruppi di disponibilità con tipo di cluster NONE, è necessario usare Transact-SQL.
    L'esempio seguente esegue il failover di un gruppo di disponibilità con gli strumenti per la gestione di cluster. Sostituire <targetReplicaName> con il nome della replica secondaria sincrona che diventerà primaria:

    sudo pcs resource move ag_cluster-master <targetReplicaName> --master

    Importante

    I passaggi seguenti si applicano solo ai gruppi di disponibilità che non dispongono di un modulo di gestione cluster.

    Se il tipo di cluster per il gruppo di disponibilità è NONE, eseguire il failover manualmente. Completare i passaggi seguenti nell'ordine indicato:

    a. Il comando seguente imposta la replica primaria come secondaria. Sostituire AG1 con il nome del gruppo di disponibilità. Eseguire il comando Transact-SQL nell'istanza di SQL Server che ospita la replica primaria.

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

    b. Il comando seguente imposta una replica secondaria sincrona come primaria. Eseguire il comando Transact-SQL seguente nell'istanza di destinazione di SQL Server, ovvero l'istanza che ospita la replica secondaria sincrona.

    ALTER AVAILABILITY GROUP [ag1] FAILOVER;

  5. Dopo il failover, eseguire l'aggiornamento di SQL Server nella replica primaria precedente ripetendo la procedura riportata sopra.

    L'esempio seguente aggiorna i pacchetti mssql-server e mssql-server-ha.

    # add constraint for the resource to stop on the upgraded node
# replace 'nodename2' with the name of the cluster node targeted for upgrade
pcs constraint location ag_cluster-master avoids nodeName2
sudo yum update mssql-server
sudo yum update mssql-server-ha

    # upgrade mssql-server and mssql-server-ha packages
sudo yum update mssql-server
sudo yum update mssql-server-ha

    # remove the constraint; make sure the resource is started and replica is connected and synchronized
pcs constraint remove location-ag_cluster-master-rhel1--INFINITY

  6. Per i gruppi di disponibilità con un modulo di gestione cluster esterno, dove il tipo di cluster è EXTERNAL, rimuovere il vincolo di posizione causato dal failover manuale.

    sudo pcs constraint remove cli-prefer-ag_cluster-master

  7. Riprendere lo spostamento dei dati per la replica secondaria appena aggiornata, ovvero la replica primaria precedente. Questo passaggio è necessario quando un'istanza di SQL Server con una versione più recente trasferisce i blocchi di log a un'istanza con una versione precedente in un gruppo di disponibilità. Eseguire il comando seguente sulla nuova replica secondaria (la replica primaria precedente).

    ALTER DATABASE database_name SET HADR RESUME;

Dopo l'aggiornamento di tutti i server, è possibile eseguire il failback. Eseguire nuovamente il failover nel database primario originale, se necessario.

Eliminare un gruppo di disponibilità

Per eliminare un gruppo di disponibilità, eseguire DROP AVAILABILITY GROUP. Se il tipo di cluster è EXTERNAL o NONE, eseguire il comando su ogni istanza di SQL Server che ospita una replica. Ad esempio, per eliminare un gruppo di disponibilità denominato group_name, eseguire il comando seguente:

DROP AVAILABILITY GROUP group_name

Contenuto correlato