Sottoscrittori della replica e gruppi di disponibilità AlwaysOn (SQL Server)

Articolo
03/07/2024

Si applica a:SQL Server

Quando un gruppo di disponibilità AlwaysOn (AG) esegue il failover e contiene un database che è un sottoscrittore della replica, la sottoscrizione della replica potrebbe avere esito negativo. Per i sottoscrittori push della replica transazionale, l'agente di distribuzione continuerà a replicare automaticamente dopo un failover se la sottoscrizione è stata creata usando il nome del listener del gruppo di disponibilità. Per i sottoscrittori pull della replica transazionale, l'agente di distribuzione continuerà a replicare automaticamente dopo un failover se la sottoscrizione è stata creata usando il nome del listener del gruppo di disponibilità e il server sottoscrizione originale è attivo e in esecuzione. Questo avviene perché i processi dell'agente di distribuzione vengono creati solo nel sottoscrittore originale (replica primaria del gruppo di disponibilità). Per i sottoscrittori di merge, un amministratore di replica deve riconfigurare manualmente il sottoscrittore ricreando la sottoscrizione.

Elementi supportati

La replica di SQL Server supporta il failover automatico del server di pubblicazione e il failover automatico dei sottoscrittori transazionali. I sottoscrittori della replica di tipo merge possono far parte di un gruppo di disponibilità, tuttavia sono necessarie azioni manuali per configurare il nuovo sottoscrittore dopo un failover. Non è possibile combinare i gruppi di disponibilità con gli scenari WebSync e SQL Server Compact.

Creare una sottoscrizione transazionale in un gruppo di disponibilità

Per la replica transazionale, usare i passaggi seguenti per configurare un gruppo di disponibilità del sottoscrittore e impostarne il failover:

Prima di creare la sottoscrizione, aggiungere il database sottoscrittore al gruppo di disponibilità appropriato.
Aggiungere il listener del gruppo di disponibilità del sottoscrittore come server collegato a tutti i nodi del gruppo di disponibilità. Questa operazione assicura che tutti i partner di failover potenziali siano in grado di riconoscere e connettersi al listener.
Utilizzando lo script riportato nella sezione Creare una sottoscrizione push di una replica transazionale, creare la sottoscrizione con il nome del listener del gruppo di disponibilità del sottoscrittore. Dopo un failover, il nome del listener rimane sempre valido, mentre il nome del server effettivo del sottoscrittore dipenderà dal nodo effettivo diventato il nuovo nodo primario.

Nota

La sottoscrizione deve essere creata usando uno script Transact-SQL e non può essere creata con Management Studio.
Per creare una sottoscrizione pull:
1. Utilizzando lo script di esempio riportato nella sezione Creare una sottoscrizione pull di una replica transazionale, creare la sottoscrizione con il nome del listener del gruppo di disponibilità del sottoscrittore.
2. Dopo un failover, creare il processo dell'agente di distribuzione nella nuova replica primaria usando la stored procedure sp_addpullsubscription_agent.

Quando si crea una sottoscrizione pull con il database di sottoscrizione in un gruppo di disponibilità, dopo ogni failover è consigliabile disabilitare il processo dell'agente di distribuzione nella replica primaria precedente e abilitare il processo nella nuova replica primaria.

Creare una sottoscrizione push di una replica transazionale

-- commands to execute at the publisher, in the publisher database:
USE [<publisher database name>];
GO

EXEC sp_addsubscription @publication = N'<publication name>',
    @subscriber = N'<AG listener name>',
    @destination_db = N'<subscriber database name>',
    @subscription_type = N'Push',
    @sync_type = N'automatic',
    @article = N'all',
    @update_mode = N'read only',
    @subscriber_type = 0;
GO
  
EXEC sp_addpushsubscription_agent @publication = N'<publication name>',
    @subscriber = N'<AG listener name>',
    @subscriber_db = N'<subscriber database name>',
    @job_login = NULL,
    @job_password = NULL,
    @subscriber_security_mode = 1;
GO

Creare una sottoscrizione pull di una replica transazionale

-- commands to execute at the subscriber, in the subscriber database:
USE [<subscriber database name>];
GO

EXEC sp_addpullsubscription @publisher = N'<publisher name>',
    @publisher_db = N'<publisher database name>',
    @publication = N'<publication name>',
    @subscription_type = N'pull';
GO

EXEC sp_addpullsubscription_agent @publisher = N'<publisher name>',
    @subscriber = N'<AG listener name>',
    @distributor = N'<distributor AG listener name>', -- this parameter should only be used if the distribution database is part of an AG.
    @publisher_db = N'<publisher database name>',
    @publication = N'<publication name>',
    @job_login = NULL,
    @job_password = NULL,
    @subscriber_security_mode = 1;
GO

Nota

Quando si esegue sp_addpullsubscription_agent per un sottoscrittore che fa parte di un gruppo di disponibilità, è necessario passare il valore del parametro @Subscriber alla stored procedure come nome del listener del gruppo di disponibilità. Se si esegue SQL Server 2016 (13.x) e versioni precedenti o SQL Server 2017 (14.x) precedente alla versione CU 16, la stored procedure non farà riferimento al nome del listener del gruppo di disponibilità, ma verrà creata con il nome del server sottoscrittore in cui viene eseguito il comando. Per risolvere questo problema, aggiornare manualmente il parametro @Subscriber nel processo dell'agente di distribuzione con il valore del nome del listener del gruppo di disponibilità.

Riprendere gli agenti di merge dopo il failover del gruppo di disponibilità del sottoscrittore

Per eseguire il merge della replica, un relativo amministratore deve riconfigurare manualmente il sottoscrittore attenendosi alla procedura seguente:

Per rimuovere la sottoscrizione precedente del sottoscrittore eseguire sp_subscription_cleanup. Effettuare questa operazione nella nuova replica primaria, che precedentemente era la secondaria.
Ricreare la sottoscrizione creando una nuova sottoscrizione a partire da un nuovo snapshot.

Nota

Il processo corrente non è pratico per i sottoscrittori della replica di tipo merge. Tuttavia, lo scenario principale per la replica di tipo merge è composto da utenti disconnessi (desktop, portatili, dispositivi palmari) che non utilizzeranno i gruppi di disponibilità sul sottoscrittore.

Share via