Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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 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 effettivo del server del sottoscrittore dipende dal nodo effettivo che è diventato il nuovo primario.
Nota
Per creare la sottoscrizione, è necessario usare uno script Transact-SQL. Non è possibile usare Management Studio.
Per creare una sottoscrizione pull:
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.
Dopo un failover, creare il processo dell'agente di distribuzione nella nuova replica primaria usando la stored procedure
sp_addpullsubscription_agent.
Quando si crea un pull subscription con il database di sottoscrizione in un gruppo di disponibilità, dopo che si verifica un failover, è necessario disabilitare il processo dell'agente di distribuzione sulla replica primaria precedente e abilitare il processo sulla 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 or alias>',
@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
Requisito dell'ascoltatore del gruppo di disponibilità
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) prima della versione CU 16, la stored procedure non fa riferimento al nome del listener del gruppo di disponibilità. Crea la sottoscrizione con il nome del server sottoscrittore in cui viene eseguito il comando. Per risolvere questo problema, aggiornare manualmente il parametro @subscriber nell'Agente di Distribuzione della Replica con il valore del nome del listener del gruppo di disponibilità (AG).
Se il listener del gruppo di disponibilità (AG) del sottoscrittore usa una porta non predefinita, specificare il numero di porta come parte del nome del listener del gruppo di disponibilità nel parametro @subscriber non è supportato in Windows. Come soluzione alternativa, è possibile creare un Alias per il listener e la porta sui server di pubblicazione, distribuzione e sottoscrizione utilizzando Alias (Gestione configurazione SQL Server) o l'Utilità di rete client di SQL Server (cliconfg) per SQL Server 2022 (16.x) e versioni successive, e passare l'Alias come valore del parametro @subscriber.
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
Questo processo non è pratico per i sottoscrittori della replica di tipo merge. Tuttavia, lo scenario principale per la replica di tipo merge riguarda gli utenti disconnessi (desktop, portatili, dispositivi portatili) che non utilizzano gruppi di disponibilità sul sottoscrittore.