Configurare un gruppo di disponibilità distribuito Always On

  • Articolo

Si applica a: SQL Server

Per creare un gruppo di disponibilità distribuito, è necessario creare due gruppi di disponibilità ognuno con il proprio listener. È quindi possibile combinare questi gruppi di disponibilità in un gruppo di disponibilità distribuito. La procedura seguente illustra un esempio di base in Transact-SQL. Questo esempio non descrive in dettaglio la creazione di gruppi di disponibilità e listener, ma mette in rilievo i requisiti principali.

Per una panoramica tecnica dei gruppi di disponibilità distribuiti, vedere Gruppi di disponibilità distribuiti.

Prerequisiti

Per configurare un gruppo di disponibilità distribuito, è necessario disporre di quanto segue:

Nota

Se il listener è stato configurato per il gruppo di disponibilità in SQL Server nella macchina virtuale di Azure usando un nome di rete distribuito (DNN), la configurazione di un gruppo di disponibilità distribuito al di sopra del gruppo di disponibilità non è supportata. Per altre informazioni, vedere Interoperabilità di SQL Server sulla macchina virtuale Azure con il gruppo di disponibilità e listener DNN.

Impostare i listener di endpoint in ascolto per tutti gli indirizzi IP

Assicurarsi che gli endpoint possano comunicare tra i vari gruppi di disponibilità nel gruppo di disponibilità distribuito. Se un gruppo di disponibilità è impostato su una rete specifica dell'endpoint, il gruppo di disponibilità distribuito non funzionerà correttamente. In ogni server che ospita una replica nel gruppo di disponibilità distribuito, configurare il listener per l'ascolto su tutti gli indirizzi IP (LISTENER_IP = ALL).

Creare un endpoint per l'ascolto di tutti gli indirizzi IP

Ad esempio, lo script seguente crea un endpoint del listener sulla porta TCP 5022 in ascolto su tutti gli indirizzi IP.

CREATE ENDPOINT [aodns-hadr] 
    STATE=STARTED
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING (
   ROLE = ALL, 
   AUTHENTICATION = WINDOWS NEGOTIATE,
   ENCRYPTION = REQUIRED ALGORITHM AES
)
GO

Modificare un endpoint per l'ascolto di tutti gli indirizzi IP

Ad esempio, lo script seguente modifica un endpoint del listener per l'ascolto di tutti gli indirizzi IP.

ALTER ENDPOINT [aodns-hadr] 
    AS TCP (LISTENER_IP = ALL)
GO

Creare un primo gruppo di disponibilità

Creare il gruppo di disponibilità primario nel primo cluster

Creare un gruppo di disponibilità nel primo cluster di failover di Windows Server (WSFC). In questo esempio il gruppo di disponibilità è denominato ag1 per il database db1. La replica primaria del gruppo di disponibilità primario è nota come server primario globale in un gruppo di disponibilità distribuito. Server1 è il server primario globale in questo esempio.

CREATE AVAILABILITY GROUP [ag1]   
FOR DATABASE db1   
REPLICA ON N'server1' WITH (ENDPOINT_URL = N'TCP://server1.contoso.com:5022',  
    FAILOVER_MODE = AUTOMATIC,  
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,   
    BACKUP_PRIORITY = 50,   
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),   
    SEEDING_MODE = AUTOMATIC),   
N'server2' WITH (ENDPOINT_URL = N'TCP://server2.contoso.com:5022',   
    FAILOVER_MODE = AUTOMATIC,   
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,   
    BACKUP_PRIORITY = 50,   
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),   
    SEEDING_MODE = AUTOMATIC);   
GO

Nota

L'esempio precedente usa il seeding automatico, dove SEEDING_MODE è impostato su AUTOMATIC per le repliche e il gruppo di disponibilità distribuito. Questa configurazione imposta le repliche secondarie e il gruppo di disponibilità secondario in modo che vengano popolati automaticamente senza richiedere alcun backup e ripristino manuale del database primario.

Creare un join delle repliche secondarie al gruppo di disponibilità primario

È necessario creare un join tra tutte le repliche secondarie al gruppo di disponibilità tramite ALTER AVAILABILITY GROUP con l'opzione JOIN. Dal momento che in questo esempio viene usato il seeding automatico, è necessario chiamare anche ALTER AVAILABILITY GROUP con l'opzione GRANT CREATE ANY DATABASE. Questa impostazione consente al gruppo di disponibilità di creare il database e avviare il seeding automatico dalla replica primaria.

In questo esempio i seguenti comandi vengono eseguiti sulla replica secondaria, server2, per creare un join del gruppo di disponibilità ag1. Il gruppo di disponibilità può quindi creare database sulla replica secondaria.

ALTER AVAILABILITY GROUP [ag1] JOIN   
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE  
GO

Nota

Quando il gruppo di disponibilità crea un database in una replica secondaria, imposta il proprietario del database come l'account che ha eseguito l'istruzione ALTER AVAILABILITY GROUP per concedere l'autorizzazione per la creazione di qualsiasi database. Per informazioni complete, vedere Concedere le autorizzazioni di creazione di database sulla replica secondaria al gruppo di disponibilità.

Creare un listener per il gruppo di disponibilità primario

Successivamente aggiungere un listener per il gruppo di disponibilità primario sul primo WSFC. In questo esempio il listener viene denominato ag1-listener. Per istruzioni dettagliate sulla creazione di un listener, vedere Creare o configurare un listener del gruppo di disponibilità (SQL Server).

ALTER AVAILABILITY GROUP [ag1]    
    ADD LISTENER 'ag1-listener' ( 
        WITH IP ( ('2001:db88:f0:f00f::cf3c'),('2001:4898:e0:f213::4ce2') ) , 
        PORT = 60173);    
GO

Creare un secondo gruppo di disponibilità

Creare quindi un secondo gruppo di disponibilità, ag2, nel secondo WSFC. In questo caso il database non è specificato, perché viene eseguito il seeding automatico del database stesso dal gruppo di disponibilità primario. La replica primaria del gruppo di disponibilità secondario è nota come server di inoltro in un gruppo di disponibilità distribuito. In questo esempio server3 è il server d'inoltro.

CREATE AVAILABILITY GROUP [ag2]   
FOR   
REPLICA ON N'server3' WITH (ENDPOINT_URL = N'TCP://server3.contoso.com:5022',   
    FAILOVER_MODE = MANUAL,   
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,   
    BACKUP_PRIORITY = 50,   
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),   
    SEEDING_MODE = AUTOMATIC),   
N'server4' WITH (ENDPOINT_URL = N'TCP://server4.contoso.com:5022',   
    FAILOVER_MODE = MANUAL,   
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,   
    BACKUP_PRIORITY = 50,   
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),   
    SEEDING_MODE = AUTOMATIC);   
GO

Nota

Il gruppo di disponibilità secondario deve usare lo stesso endpoint del mirroring del database (in questo esempio la porta 5022). In caso contrario, la replica verrà interrotta dopo un failover locale.

Creare un join delle repliche secondarie al gruppo di disponibilità secondario

In questo esempio i seguenti comandi vengono eseguiti sulla replica secondaria, server4, per creare un join del gruppo di disponibilità ag2. Il gruppo di disponibilità può quindi creare database sulla replica secondaria per supportare il seeding automatico.

ALTER AVAILABILITY GROUP [ag2] JOIN   
ALTER AVAILABILITY GROUP [ag2] GRANT CREATE ANY DATABASE  
GO

Creare un listener per il gruppo di disponibilità secondario

Successivamente aggiungere un listener per il gruppo di disponibilità secondario sul secondo WSFC. In questo esempio il listener viene denominato ag2-listener. Per istruzioni dettagliate sulla creazione di un listener, vedere Creare o configurare un listener del gruppo di disponibilità (SQL Server).

ALTER AVAILABILITY GROUP [ag2]    
    ADD LISTENER 'ag2-listener' ( WITH IP ( ('2001:db88:f0:f00f::cf3c'),('2001:4898:e0:f213::4ce2') ) , PORT = 60173);    
GO

Creare un gruppo di disponibilità distribuito nel primo cluster

Creare un gruppo di disponibilità distribuito nel primo WSFC (in questo esempio denominato distributedag ). Usare il comando CREATE AVAILABILITY GROUP con l'opzione DISTRIBUTED. Il parametro AVAILABILITY GROUP ON specifica i gruppi di disponibilità membri, ag1 e ag2.

Per creare il gruppo di disponibilità distribuito usando il seeding automatico, usare il seguente codice Transact-SQL:

CREATE AVAILABILITY GROUP [distributedag]  
   WITH (DISTRIBUTED)   
   AVAILABILITY GROUP ON  
      'ag1' WITH    
      (   
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      ),   
      'ag2' WITH    
      (   
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      );    
GO

Nota

Il parametro LISTENER_URL specifica il listener per ogni gruppo di disponibilità insieme all'endpoint del mirroring del database del gruppo di disponibilità. Questo esempio riguarda la porta 5022 (non la porta 60173 usata per creare il listener). Se si usa un bilanciamento del carico, ad esempio in Azure, aggiungere una regola per il bilanciamento del carico per la porta del gruppo di disponibilità distribuito. Aggiungere la regola per la porta del listener, oltre che alla porta dell'istanza di SQL Server.

Annullare il seeding automatico al server d'inoltro

Se per qualsiasi motivo è necessario annullare l'inizializzazione del server d'inoltro prima che i due gruppi di disponibilità siano sincronizzati, modificare (ALTER) il gruppo di disponibilità distribuito impostando il parametro SEEDING_MODE del server di inoltro su MANUAL e annullare immediatamente il seeding. Eseguire il comando nel database primario globale:

-- Cancel automatic seeding​.  Connect to global primary but specify DAG AG2
ALTER AVAILABILITY GROUP [distributedag] ​  
   MODIFY ​ 
   AVAILABILITY GROUP ON ​ 
   'ag2' WITH ​ 
   ( ​ SEEDING_MODE = MANUAL ​ ); ​

Aggiungere un gruppo di disponibilità distribuito nel secondo cluster

Creare quindi un join del gruppo di disponibilità distribuito nel secondo WSFC.

Per creare un join con il gruppo di disponibilità distribuito usando il seeding automatico, usare il seguente codice Transact-SQL:

ALTER AVAILABILITY GROUP [distributedag]   
   JOIN   
   AVAILABILITY GROUP ON  
      'ag1' WITH    
      (   
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      ),   
      'ag2' WITH    
      (   
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      );    
GO

Creare un join del database alla replica secondaria del secondo gruppo di disponibilità

Se il secondo gruppo di disponibilità è stato configurato per l'uso del seeding automatico, andare al passaggio 2.

  1. Se il secondo gruppo di disponibilità usa il seeding manuale, ripristinare il backup eseguito sul database primario globale nel database secondario del secondo gruppo di disponibilità:
RESTORE DATABASE [db1] 
FROM DISK = '<full backup location>' WITH NORECOVERY
RESTORE LOG [db1] FROM DISK = '<log backup location>' WITH NORECOVERY
  1. Quando il database nella replica secondaria del secondo gruppo di disponibilità è in uno stato di ripristino, è necessario aggiungerlo manualmente al gruppo di disponibilità.
ALTER DATABASE [db1] SET HADR AVAILABILITY GROUP = [ag2];

Eseguire il failover di un gruppo di disponibilità distribuito

Poiché SQL Server 2022 (16.x) ha introdotto il supporto del gruppo di disponibilità distribuito per l'impostazione REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, le istruzioni per il failover di una disponibilità distribuita sono diverse per SQL Server 2022 e versioni successive rispetto a sql Server 2019 e versioni precedenti.

Per un gruppo di disponibilità distribuito, l'unico tipo di failover supportato è un manuale avviato dall'utente FORCE_FAILOVER_ALLOW_DATA_LOSS. Pertanto, per evitare la perdita di dati, è necessario eseguire passaggi aggiuntivi (descritti in dettaglio in questa sezione) per assicurarsi che i dati vengano sincronizzati tra le due repliche prima di avviare il failover.

In caso di emergenza in cui la perdita di dati è accettabile, è possibile avviare un failover senza garantire la sincronizzazione dei dati eseguendo:

ALTER AVAILABILITY GROUP distributedag FORCE_FAILOVER_ALLOW_DATA_LOSS

È possibile usare lo stesso comando per eseguire il failover al server d'inoltro, nonché eseguire il failback nel database primario globale.

In SQL Server 2022 (16.x) e versioni successive è possibile configurare l'impostazione REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT per un gruppo di disponibilità distribuito, progettato per garantire nessuna perdita di dati quando viene eseguito il failover di un gruppo di disponibilità distribuito. Se questa impostazione è configurata, seguire la procedura descritta in questa sezione per eseguire il failover del gruppo di disponibilità distribuito. Se non si vuole usare l'impostazione REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, seguire le istruzioni per eseguire il failover di un gruppo di disponibilità distribuito in SQL Server 2019 e versioni precedenti.

Per assicurarsi che non si verifichi alcuna perdita di dati, assicurarsi di:

  1. Per assicurarsi che non si verifichino perdite di dati, arrestare tutte le transazioni nei database primari globali, ovvero i database del gruppo di disponibilità primario
  2. Impostare il gruppo di disponibilità distribuito su commit sincrono.
  3. Attendere che il gruppo di disponibilità distribuito sia sincronizzato e che abbia lo stesso last_hardened_lsn per ogni database.

Dopo la sincronizzazione dei dati, è possibile eseguire il failover del gruppo di disponibilità distribuito:

  1. Nella replica primaria globale, impostare il ruolo del gruppo di disponibilità distribuito su SECONDARY, che rende il gruppo di disponibilità distribuito non disponibile.
  2. Impostare l'impostazione del gruppo REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT di disponibilità distribuito su 1 usando ALTER AVAILABILITY GROUP.
  3. Verificare la conformità del failover.
  4. Eseguire il failover del gruppo di disponibilità primario usando ALTER AVAILABILITY GROUP con FORCE_FAILOVER_ALLOW_DATA_LOSS.
  5. Impostare REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT del gruppo di disponibilità distribuito su 0.

Gli esempi Transact-SQL seguenti illustrano i passaggi dettagliati per il failover del gruppo di disponibilità distribuito denominato distributedag:

  1. Per assicurarsi che non si verifichino perdite di dati, arrestare tutte le transazioni nei database primari globali, ovvero i database del gruppo di disponibilità primario. Impostare quindi il gruppo di disponibilità distribuito per il commit sincrono eseguendo il codice seguente sia nel server primario globale che nel server d'inoltro.

     -- sets the distributed availability group to synchronous commit 
 ALTER AVAILABILITY GROUP [distributedag] 
 MODIFY 
 AVAILABILITY GROUP ON
 'ag1' WITH 
    ( 
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
    ), 
  'ag2' WITH  
    ( 
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
    );
 -- verifies the commit state of the distributed availability group
 select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, 
     ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag  
     join sys.availability_replicas ar on ag.group_id=ar.group_id
     left join sys.dm_hadr_availability_replica_states ars
     on ars.replica_id=ar.replica_id
     where ag.is_distributed=1
 GO

    Nota

    In un gruppo di disponibilità distribuito, lo stato di sincronizzazione tra i due gruppi di disponibilità dipende dalla modalità di disponibilità di entrambe le repliche. Per la modalità con commit sincrono, il gruppo di disponibilità primario corrente e quello secondario corrente devono essere entrambi configurati con la modalità di disponibilità SYNCHRONOUS_COMMIT. Per questo motivo, è necessario eseguire lo script precedente nella replica primaria globale e nel server di inoltro.

  2. Attendere che lo stato del gruppo di disponibilità distribuito diventi SYNCHRONIZED e che tutte le repliche abbiano lo stesso last_hardened_lsn (per ogni database). Eseguire la query seguente sia nel database primario globale, che è la replica primaria del gruppo di disponibilità primario, che nel server di inoltro per controllare i valori synchronization_state_desc e last_hardened_lsn:

    -- Run this query on the Global Primary and the forwarder
-- Check the results to see if synchronization_state_desc is SYNCHRONIZED, and the last_hardened_lsn is the same per database on both the global primary and  forwarder 
-- If not rerun the query on both side every 5 seconds until it is the case
--
SELECT ag.name
         , drs.database_id
         , db_name(drs.database_id) as database_name
         , drs.group_id
         , drs.replica_id
         , drs.synchronization_state_desc
         , drs.last_hardened_lsn  
FROM sys.dm_hadr_database_replica_states drs 
INNER JOIN sys.availability_groups ag on drs.group_id = ag.group_id;

    Proseguire quando il valore synchronization_state_desc del gruppo di disponibilità è SYNCHRONIZED e il valore last_hardened_lsn è uguale per ogni database sia nel database primario globale che nel server di inoltro. Se synchronization_state_desc non è SYNCHRONIZED o last_hardened_lsn è diverso, eseguire il comando ogni cinque secondi fino a quando questi valori non vengono modificati. Non continuare fino a quando i valori synchronization_state_desc = SYNCHRONIZED e last_hardened_lsn non sono uguali per ogni database.

  3. Nel server primario globale impostare il ruolo del gruppo di disponibilità distribuito su SECONDARY.

    ALTER AVAILABILITY GROUP distributedag SET (ROLE = SECONDARY);

    A questo punto, il gruppo di disponibilità distribuito non è disponibile.

  4. In SQL Server 2022 (16.x) e versione successiva, impostare REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

    ALTER AVAILABILITY GROUP distributedag 
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

  5. Verificare la conformità del failover. Eseguire la query seguente sia nel database primario globale che nel server di inoltro:

     -- Run this query on the Global Primary and the forwarder
 -- Check the results to see if the last_hardened_lsn is the same per database on both the global primary and forwarder 
 -- The availability group is ready to fail over when the last_hardened_lsn is the same for both availability groups per database
 --
 SELECT ag.name, 
     drs.database_id, 
     db_name(drs.database_id) as database_name,
     drs.group_id, 
     drs.replica_id,
     drs.last_hardened_lsn
 FROM sys.dm_hadr_database_replica_states drs
 INNER JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;

    Il gruppo di disponibilità è pronto per il failover quando il valore last_hardened_lsn è uguale per entrambi i gruppi di disponibilità per ogni database. Se last_hardened_lsn non diventa uguale dopo un periodo di tempo, per evitare la perdita di dati, eseguire il failback nel database primario globale eseguendo questo comando nel database primario globale e quindi ricominciare dal secondo passaggio:

    -- If the last_hardened_lsn is not the same after a period of time, to avoid data loss, 
-- we need to fail back to the global primary by running this command on the global primary 
-- and then start over from the second step:

ALTER AVAILABILITY GROUP distributedag FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Failover dal gruppo di disponibilità primaria al gruppo di disponibilità secondaria. Eseguire il comando seguente nel server di inoltro, ovvero l'istanza di SQL Server che ospita la replica primaria del gruppo di disponibilità secondario.

    -- Once the last_hardened_lsn is the same per database on both sides
-- We can Fail over from the primary availability group to the secondary availability group. 
-- Run the following command on the forwarder, the SQL Server instance that hosts the primary replica of the secondary availability group.

ALTER AVAILABILITY GROUP distributedag FORCE_FAILOVER_ALLOW_DATA_LOSS;

    Dopo questo passaggio, il gruppo di disponibilità distribuito sarà disponibile.

  7. Per SQL Server 2022 (16.x) e versioni successive, cancellare il gruppo REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT di disponibilità distribuito .

    ALTER AVAILABILITY GROUP distributedag 
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);

Dopo aver completato questi passaggi, si verifica il failover del gruppo di disponibilità distribuito senza perdita di dati. Se i gruppi di disponibilità si trovano a una distanza geografica che provoca latenza, reimpostare la modalità di disponibilità su ASYNCHRONOUS_COMMIT.

Rimuovere un gruppo di disponibilità distribuito

L'istruzione Transact-SQL seguente rimuove un gruppo di disponibilità distribuito denominato distributedag:

DROP AVAILABILITY GROUP [distributedag]

Creare un gruppo di disponibilità distribuito in istanze del cluster di failover

È possibile creare un gruppo di disponibilità distribuito usando un gruppo di disponibilità in un'istanza del cluster di failover. In questo caso, non è necessario un listener del gruppo di disponibilità. Usare il nome di rete virtuale (VNN) per la replica primaria dell'istanza FCI. L'esempio seguente illustra un gruppo di disponibilità distribuito denominato SQLFCIDAG. Un gruppo di disponibilità è SQLFCIAG. SQLFCIAG ha due repliche FCI. Il nome di rete virtuale per la replica primaria FCI è SQLFCIAG-1 e il nome di rete virtuale per la replica FCI secondaria è SQLFCIAG-2. Il gruppo di disponibilità distribuito include anche SQLAG-DR, per il ripristino di emergenza.

Gruppo di disponibilità AlwaysOn distribuito

Il DDL seguente crea questo gruppo di disponibilità distribuito.

CREATE AVAILABILITY GROUP [SQLFCIDAG]  
   WITH (DISTRIBUTED)   
   AVAILABILITY GROUP ON  
  'SQLFCIAG' WITH    
    (   
        LISTENER_URL = 'tcp://SQLFCIAG-1.contoso.com:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC
      ),   
  'SQLAG-DR' WITH    
       (   
         LISTENER_URL = 'tcp://SQLAG-DR.contoso.com:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC
      );

L'URL del listener è il nome di rete virtuale dell'istanza FCI primaria.

Eseguire il failover manuale di FCI in un gruppo di disponibilità distribuito

Per eseguire manualmente il failover del gruppo di disponibilità FCI, aggiornare il gruppo di disponibilità distribuito in modo da riflettere la modifica dell'URL del listener. Ad esempio, eseguire il DDL seguente sia nel gruppo primario globale del gruppo di disponibilità distribuito sia nel server di inoltro del gruppo di disponibilità distribuito di SQLFCIDAG:

ALTER AVAILABILITY GROUP [SQLFCIDAG]  
   MODIFY AVAILABILITY GROUP ON  
 'SQLFCIAG' WITH    
    (   
        LISTENER_URL = 'tcp://SQLFCIAG-2.contoso.com:5022'
    )

Passaggi successivi

CREATE AVAILABILITY GROUP (Transact-SQL)
ALTER AVAILABILITY GROUP (Transact-SQL)