Condividi tramite

Replica, rilevamento modifiche e Change Data Capture per i gruppi di disponibilità Always On

Si applica a:SQL Server

Le funzionalità di replica, di rilevamento delle modifiche (CT, Change Tracking) e Change Data Capture (CDC) di SQL Server sono supportate in Gruppi di disponibilità Always On. Con Gruppi di disponibilità Always On vengono fornite disponibilità elevata e altre funzionalità di ripristino del database.

Panoramica della replica con i gruppi di disponibilità

Reindirizzamento del server di pubblicazione

Se un database pubblicato è compatibile con Gruppi di disponibilità Always On, il database di distribuzione tramite cui viene fornito agli agenti l'accesso al database di pubblicazione viene configurato con le voci redirected_publishers. Tramite queste voci la coppia server di pubblicazione/database configurata originariamente viene reindirizzata, usando un nome del listener del gruppo di disponibilità per connettersi al server e al database di pubblicazione. Le connessioni stabilite tramite il nome del listener del gruppo di disponibilità hanno esito negativo in caso di failover. Quando l'agente di replica viene riavviato dopo il failover, la connessione viene reindirizzata automaticamente al nuovo database primario.

In un gruppo di disponibilità (AG), un database secondario non può essere un server di pubblicazione. La ripubblicazione è supportata solo quando la replica transazionale è combinata con Gruppi di disponibilità Always On.

Se un database pubblicato è membro di un gruppo di disponibilità e il server di pubblicazione viene reindirizzato, è necessario reindirizzarlo a un nome del listener del gruppo di disponibilità associato al gruppo di disponibilità. Potrebbe non essere reindirizzato a un nodo esplicito.

Nota

Dopo il failover in una replica secondaria, Monitoraggio replica non è in grado di modificare il nome dell'istanza di pubblicazione di SQL Server e continua a visualizzare le informazioni di replica con il nome dell'istanza primaria originale di SQL Server. Dopo il failover, non è possibile immettere un token di traccia usando Monitoraggio replica, ma un token di traccia immesso nel nuovo server di pubblicazione tramite Transact-SQL è visibile in Monitoraggio replica.

Modifiche generali apportate agli agenti di replica per supportare i gruppi di disponibilità

Sono stati modificati tre agenti di replica per supportare Gruppi di disponibilità Always On. Gli agenti di lettura log, snapshot e di merge sono stati modificati in modo da eseguire query sul database di distribuzione per il server di pubblicazione reindirizzato e usare il nome del listener del gruppo di disponibilità restituito, se è stato dichiarato un server di pubblicazione reindirizzato, per connettersi al server di pubblicazione del database.

Per impostazione predefinita, quando gli agenti eseguono una query sul server di distribuzione per determinare se il server di pubblicazione originale è stato reindirizzato, l'idoneità della destinazione o del reindirizzamento corrente viene verificata prima di restituire l'host reindirizzato all'agente. Questo è il comportamento consigliato. Tuttavia, se l'avvio dell'agente si verifica spesso il sovraccarico associato alla stored procedure di convalida potrebbe essere considerato troppo costoso. Una nuova opzione della riga di comando, BypassPublisherValidation, è stata aggiunta agli agenti di lettura log, snapshot e merge. Quando viene usata l'opzione, il server di pubblicazione reindirizzato viene restituito immediatamente all'agente e l'esecuzione della stored procedure di convalida viene ignorata.

Gli errori restituiti dalla stored procedure di convalida vengono registrati nei log della cronologia degli agenti. Tali errori con gravità maggiore o uguale a 16 causano l'interruzione degli agenti. Gli agenti includono ora alcune funzionalità per effettuare nuovi tentativi in modo da gestire la disconnessione prevista da un database pubblicato in caso di failover su un nuovo database primario.

Modifiche dell'agente di lettura log

L'agente di lettura log presenta le modifiche seguenti.

  • Coerenza del database replicata

    Quando un database pubblicato è membro di un gruppo di disponibilità, per impostazione predefinita il lettore di log non elabora i record di log che non sono già stati sottoposti a protezione avanzata in tutte le repliche secondarie del gruppo di disponibilità. In questo modo, viene garantito che al failover tutte le righe replicate a un sottoscrittore siano anche presenti nel nuovo database primario.

    Quando il server di pubblicazione ha solo due repliche di disponibilità (una primaria e una secondaria) e si verifica un failover, la replica primaria originale rimane inattiva perché il lettore di log non si sposta in avanti finché tutti i database secondari non vengono portati online o finché le repliche secondarie non riuscite non vengono rimosse dal gruppo di disponibilità. Il lettore di log, ora in esecuzione sul database secondario, non procede in avanti perché il gruppo di disponibilità non può rafforzare le modifiche apportate a qualsiasi database secondario. Per consentire all'agente di lettura log di procedere e mantenere la funzionalità di ripristino di emergenza, rimuovere la replica primaria originale dal gruppo di disponibilità usando ALTER AVAILABITY GROUP <nome_gruppo> REMOVE REPLICA. Successivamente, aggiungere una nuova replica secondaria al gruppo di disponibilità.

  • Flag di traccia 1448

    Il flag di traccia 1448 consente al lettore del registro di replica di procedere anche se le repliche secondarie asincrone non hanno riconosciuto la ricezione di una modifica. Anche se questo flag di traccia è abilitato, il lettore di log attende sempre le repliche secondarie sincrone (potrebbero diventare modalità di commit asincrona, come documentato qui, in modo che il lettore di log possa procedere). Il lettore di log non va oltre il minimo delle repliche secondarie sincrone. Questo flag di traccia si applica all'istanza di SQL Server, non solo a un gruppo di disponibilità, a un database di disponibilità o a un'istanza di lettura log. Questo flag di traccia deve essere abilitato nell'istanza del server di pubblicazione. Diventa effettivo immediatamente senza un riavvio. Può essere attivato anticipatamente o quando si verifica un errore in una replica secondaria asincrona.

Stored procedure che supportano i gruppi di disponibilità

  • sp_redirect_publisher

    La stored procedure sp_redirect_publisher viene usata per specificare un server di pubblicazione reindirizzato per una coppia server di pubblicazione/database esistente. Se il server di pubblicazione appartiene a un gruppo di disponibilità, il server di pubblicazione reindirizzato è il nome del listener del gruppo di disponibilità.

  • sp_get_redirected_publisher

    La stored procedure sp_get_redirected_publisher viene usata dagli agenti di replica per eseguire una query su un database di distribuzione allo scopo di determinare se per una coppia server di pubblicazione/database è definito un server di pubblicazione reindirizzato. Questa stored procedure ha due scopi. Innanzitutto, consente all'agente di determinare se il server di pubblicazione originale è stato reindirizzato. In secondo luogo, potrebbe anche avviare un'esecuzione di stored procedure di convalida nel server di distribuzione (sp_validate_redirected_publisher) che verifica l'idoneità del nodo di destinazione del reindirizzamento da usare come server di pubblicazione per il database denominato.

    Per eseguire questa stored procedure è necessario che il chiamante sia membro del ruolo del server sysadmin , del ruolo del database db_owner per il database di distribuzione o di un elenco di accesso alla pubblicazione per una pubblicazione definita associata al server di pubblicazione.

  • sp_validate_redirected_publisher

    Questa stored procedure tenta di convalidare la capacità del server di pubblicazione corrente di ospitare il database pubblicato. Può essere chiamata in qualsiasi momento per verificare che l'host corrente per il database pubblicato sia in grado di supportare la replica.

  • sp_validate_replicate_hosts_as_publishers

    Sebbene sia utile per gli agenti garantire che il server di pubblicazione di replica corrente possa funzionare come server di pubblicazione di replica per un database di pubblicazione, è necessaria una funzionalità di convalida più generale per stabilire la validità di un'intera topologia di replica in un database del gruppo di disponibilità. La stored procedure sp_validate_replica_hosts_as_publishers è progettata per soddisfare questa esigenza.

    Questa stored procedure viene sempre eseguita manualmente. Il chiamante deve avere il ruolo di sysadmin nel database di distribuzione, dbowner nel database di distribuzione o deve essere membro dell' elenco di accesso alla pubblicazione di una pubblicazione del server di pubblicazione. Inoltre, l'accesso del chiamante deve essere valido per tutti gli host di replica di disponibilità e devono essere disponibili privilegi selezionati nel database di disponibilità associato al server di pubblicazione.

Cattura delle modifiche ai dati

Nei database abilitati per Change Data Capture (CDC) è possibile sfruttare Gruppi di disponibilità Always On non solo per assicurare che il database rimanga disponibile in caso di errore, ma anche per fare in modo che le modifiche apportate alle tabelle del database continuino a essere monitorate e depositate nelle tabelle delle modifiche CDC. L'ordine in cui sono configurati i gruppi di disponibilità CDC e Always On non è importante. I database abilitati per CDC possono essere aggiunti ai gruppi di disponibilità AlwaysOn e i database che sono membri di un gruppo di disponibilità possono essere abilitati per CDC. In entrambi i casi, tuttavia, la configurazione di CDC viene sempre eseguita nella replica corrente o progettata. CDC usa l'agente di lettura log e presenta le stesse limitazioni descritte nella sezione Modifiche dell'agente di lettura log in precedenza in questo articolo.

  • Raccolta di modifiche per Change Data Capture senza replica

    Se CDC è abilitato per un database, ma la replica non è , il processo di acquisizione usato per raccogliere le modifiche dal log e depositarle nelle tabelle delle modifiche CDC viene eseguito nell'host CDC come proprio processo di SQL Agent.

    Per riprendere la raccolta delle modifiche dopo il failover, è necessario eseguire la stored procedure sp_cdc_add_job nel nuovo database primario per creare il processo di acquisizione locale.

    Nell'esempio seguente viene creato il processo di acquisizione.

    EXECUTE sys.sp_cdc_add_job @job_type = 'capture';

  • Raccolta di modifiche per Change Data Capture con la replica

    Se sia CDC sia la replica sono abilitati per un database, tramite la lettura log viene gestito il popolamento delle tabelle delle modifiche CDC. In questo caso, le tecniche usate dalla replica per usare i gruppi di disponibilità AlwaysOn assicurano che le modifiche continuino a essere raccolte dal log e depositate nelle tabelle delle modifiche CDC dopo il failover. Non è necessario aggiungere alcuna azione in questa configurazione di CDC per assicurare che le tabelle delle modifiche vengano popolate.

  • Pulizia di Change Data Capture

    Per assicurare l'esecuzione della pulizia appropriata nel nuovo database primario, è necessario creare sempre un processo di pulizia locale. Nell'esempio seguente viene creato il processo di pulizia.

    EXECUTE sys.sp_cdc_add_job @job_type = 'cleanup';

    Nota

    È necessario creare i processi nella nuova replica primaria dopo il failover. Quando il database locale diventa un database secondario, è necessario disabilitare i processi CDC in esecuzione nel database primario precedente. Se la replica originale diventa nuovamente primaria, è necessario riabilitare i processi CDC nella replica di tale replica. Per disabilitare e abilitare i processi, usare l'opzione @enabled di sp_update_job. Per altre informazioni sulla creazione di processi CDC, vedere sys.sp_cdc_add_job.

  • Aggiunta di ruoli CDC a una replica di database primaria

    Quando una tabella è abilitata per CDC, è possibile associare un ruolo del database all'istanza di acquisizione. Se viene specificato un ruolo, l'utente che desidera usare le funzioni con valori di tabella di CDC per accedere alle modifiche della tabella deve non solo disporre dell'accesso SELECT alle colonne della tabella con rilevamento, ma essere anche un membro del ruolo denominato. Se il ruolo specificato non esiste già, viene creato il ruolo. Quando i ruoli del database vengono aggiunti automaticamente a un database primario in un gruppo di disponibilità, i ruoli vengono propagati anche ai database secondari del gruppo di disponibilità.

  • Applicazioni client che accedono ai dati delle modifiche cdc e ai gruppi di disponibilità

    Le applicazioni client che usano le funzioni con valori di tabella o server collegati per accedere ai dati delle tabelle delle modifiche devono poter essere in grado di individuare un host CDC appropriato dopo il failover. Il nome del listener del gruppo di disponibilità è il meccanismo fornito da Gruppi di disponibilità Always On per consentire in modo trasparente il reindirizzamento di una connessione a un host diverso. Quando un nome del listener del gruppo di disponibilità è associato a un gruppo di disponibilità, è disponibile per essere usato nelle stringhe di connessione TCP. Due diversi scenari di connessione sono supportati tramite il nome del listener del gruppo di disponibilità.

    • In uno si assicura che le richieste di connessione vengano sempre indirizzate alla replica primaria corrente.
    • Nell'altro si garantisce che le richieste di connessione vengano indirizzate a una replica secondaria di sola lettura.

    Se usato per individuare una replica secondaria di sola lettura, è necessario anche definire un elenco di routing di sola lettura per il gruppo di disponibilità. Per altre informazioni sul routing dell'accesso ai database secondari leggibili, vedere Configurare il routing di sola lettura per un gruppo di disponibilità AlwaysOn.

    Nota

    Si verifica un ritardo di propagazione associato alla creazione di un nome del listener del gruppo di disponibilità e al relativo uso da parte delle applicazioni client per accedere a una replica di database del gruppo di disponibilità.

    Usare la query seguente per determinare se un nome del listener del gruppo di disponibilità è stato definito per il gruppo di disponibilità che ospita un database CDC. La query restituisce il nome del listener del gruppo di disponibilità se ne è stato creato uno.

    SELECT dns_name
FROM sys.availability_group_listeners AS l
     INNER JOIN sys.availability_databases_cluster AS d
         ON l.group_id = d.group_id
WHERE d.database_name = N'MyCDCDB';

  • Reindirizzamento del caricamento della query a una replica secondaria leggibile

    Anche se in molti casi un'applicazione client vuole sempre connettersi alla replica primaria corrente, questo non è l'unico modo per usare i gruppi di disponibilità AlwaysOn. Se un gruppo di disponibilità viene configurato per supportare repliche secondarie leggibili, è possibile raggruppare i dati delle modifiche anche dai nodi secondari.

    Quando viene configurato un gruppo di disponibilità, l'attributo ALLOW_CONNECTIONS associato a SECONDARY_ROLE viene usato per specificare il tipo di accesso secondario supportato. Se configurata come ALL, tutte le connessioni al database secondario sono consentite, ma solo quelle che richiedono l'accesso in sola lettura hanno esito positivo. Se configurata come READ_ONLY, è necessario specificare la finalità di sola lettura quando si effettua la connessione al database secondario affinché la connessione abbia esito positivo. Per altre informazioni, vedere Configurare l'accesso in sola lettura a una replica secondaria di un gruppo di disponibilità AlwaysOn.

    La query seguente può essere usata per determinare se la finalità di sola lettura è necessaria per connettersi a una replica secondaria leggibile.

    SELECT g.name AS AG,
          replica_server_name,
          secondary_role_allow_connections_desc
FROM sys.availability_replicas AS r
     INNER JOIN sys.availability_groups AS g
          ON r.group_id = g.group_id
WHERE g.name = N'MY_AG_NAME';

    Per individuare la replica secondaria è possibile usare il nome del listener del gruppo di disponibilità o il nome del nodo esplicito. Se viene usato il nome del listener del gruppo di disponibilità, l'accesso viene indirizzato a qualsiasi replica secondaria appropriata.

    Quando sp_addlinkedserver viene usato per creare un server collegato per accedere al database secondario, il parametro @datasrc viene usato per il nome del listener del gruppo di disponibilità o il nome del server esplicito e il parametro @provstr viene usato per specificare la finalità di sola lettura.

    EXECUTE sp_addlinkedserver
    @server = N'linked_svr',
    @srvproduct = N'SqlServer',
    @provider = N'MSOLEDBSQL',
    @datasrc = N'AG_Listener_Name',
    @provstr = N'ApplicationIntent=ReadOnly',
    @catalog = N'MY_DB_NAME';

  • Accesso client ai dati delle modifiche cdc e agli account di accesso al dominio

    In generale, è consigliabile usare gli account di accesso al dominio per l'accesso client ai dati delle modifiche che risiedono nei database membri dei gruppi di disponibilità. Per garantire l'accesso continuo ai dati delle modifiche dopo il failover, l'utente del dominio deve disporre dei privilegi di accesso per tutti gli host che supportano le repliche del gruppo di disponibilità. Se un utente di database viene aggiunto a un database in una replica primaria e l'utente è associato a un account di accesso al dominio, tale utente viene propagato nei database secondari e continua a essere associato all'account di accesso al dominio specificato. Se il nuovo utente del database è associato a un account di accesso di autenticazione di SQL Server, l'utente nei database secondari viene propagato senza un account di accesso. Mentre l'accesso con autenticazione SQL Server associato potrebbe essere usato per accedere ai dati delle modifiche nel database primario dove l'utente del database è stato definito originariamente, il nodo è il solo in cui sarebbe possibile l'accesso. L'account di accesso per l'autenticazione di SQL Server non sarà in grado di accedere ai dati da qualsiasi database secondario, né da nuovi database primari diversi dal database originale in cui è stato definito l'utente del database.

  • Disabilitazione di Change Data Capture

    Se è necessario disabilitare Change Data Capture (CDC) in un database che fa parte di un gruppo di disponibilità e si usa SQL Server 2016 SP2 o versione successiva, non è necessario eseguire passaggi aggiuntivi per il troncamento automatico del log. Se si usa una versione precedente a SQL Server 2016 SP2 e si disabilita CDC in un database che fa parte di un gruppo di disponibilità, sarà necessario implementare uno dei passaggi seguenti per impedire il troncamento del log bloccante dopo la disabilitazione di CDC:

    • Riavviare il servizio SQL Server in ogni istanza di replica secondaria.

    • Rimuovere il database da tutte le istanze di replica secondaria del gruppo di disponibilità, quindi riaggiungerlo a ciascuna istanza di replica del gruppo di disponibilità con seeding automatico o manuale.

Tracciamento delle modifiche

Un database abilitato per il rilevamento delle modifiche (CT) può far parte di un gruppo di disponibilità. Non è necessaria alcuna configurazione aggiuntiva. Le applicazioni client di rilevamento delle modifiche che usano le funzioni con valori di tabella CDC per accedere ai dati delle modifiche devono poter individuare la replica primaria dopo il failover. Se l'applicazione client si connette tramite il nome del listener del gruppo di disponibilità, le richieste di connessione vengono sempre indirizzate in modo appropriato alla replica primaria corrente.

I dati del rilevamento modifiche devono sempre essere ottenuti dalla replica primaria. Un tentativo di accesso ai dati delle modifiche da una replica secondaria genera l'errore seguente:

Msg 22117, Level 16, State 1, Line 1

Per i database membri di una replica secondaria( ovvero per i database secondari), il rilevamento delle modifiche non è supportato. In alternativa all'esecuzione di query di rilevamento delle modifiche sulla replica primaria, è possibile creare uno snapshot di un database del gruppo di disponibilità dalla replica secondaria e quindi usarlo per eseguire query sui dati di modifica. Uno snapshot del database è una visualizzazione statica di sola lettura di un database di SQL Server (database di origine), quindi i dati di rilevamento delle modifiche nello snapshot del database sono del momento in cui lo snapshot è stato acquisito nel database del gruppo di disponibilità dalla replica secondaria.

Nota

Quando si verifica un failover in un database con rilevamento delle modifiche abilitato, il tempo di ripristino nella nuova replica primaria può richiedere più tempo del solito perché il rilevamento delle modifiche richiede un riavvio completo del database.

Prerequisiti, restrizioni e considerazioni per l'uso della replica

In questa sezione vengono descritte le considerazioni per la distribuzione della replica con la funzionalità Gruppi di disponibilità Always On, inclusi i prerequisiti, le restrizioni e le raccomandazioni.

Prerequisiti

  • Quando si usa la replica transazionale e il database di pubblicazione si trova in un gruppo di disponibilità, sia il server di pubblicazione che il database di distribuzione devono eseguire almeno SQL Server 2012 (11.x). Il sottoscrittore può invece usare un livello inferiore di SQL Server.

  • Quando si usano la replica di tipo merge e il database di pubblicazione è in un gruppo di disponibilità:

    • Sottoscrizione push: sia il server di pubblicazione che il server di distribuzione devono eseguire almeno SQL Server 2012 (11.x).

    • Sottoscrizione pull: il server di pubblicazione, il server di distribuzione e i database sottoscrittore devono eseguire almeno SQL Server 2012 (11.x). Ciò è dovuto al fatto che l'agente di merge nel sottoscrittore deve comprendere il modo in cui in un gruppo di disponibilità può essere eseguito il failover sul secondario.

  • Le istanze del server di pubblicazione soddisfano tutti i prerequisiti necessari per partecipare a un gruppo di disponibilità. Per altre informazioni, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn.

Restrizioni

Combinazioni di replica supportate in Gruppi di disponibilità Always On:

Replica Publisher Server di distribuzione 1 Sottoscrittore
Transazionale Sì

Nota: non include il supporto per la replica transazionale bidirezionale e reciproca.		 Sì Sì
Peer-to-peer2 Sì Sì 3 Sì
Unione Sì No No
Snapshot Sì No Sì
Sottoscrizioni aggiornabili: per la replica transazionale No No No

1 Il database di distribuzione non è supportato per l'uso con il mirroring del database.

2 Richiede SQL Server 2019 CU 13 o versioni successive.

3 Richiede SQL Server 2019 CU 17 o versioni successive.

Considerazioni

  • Il database di distribuzione non è supportato per l'uso con il mirroring del database, ma è supportato con i gruppi di disponibilità AlwaysOn soggetti a determinate limitazioni. Per altre informazioni, vedere Configurare il gruppo di disponibilità di distribuzione. La configurazione della replica è associata all'istanza di SQL Server in cui è configurato il server di distribuzione; pertanto il database di distribuzione non può essere sottoposto a mirroring o replicato. È anche possibile offrire disponibilità elevata per il server di distribuzione usando un cluster di failover di SQL Server. Per altre informazioni, vedere Istanze del cluster di failover Always On (SQL Server).

  • Il failover del Sottoscrittore in un database secondario, se supportato, è una procedura manuale per Sottoscrittori della replica di tipo merge. La procedura è essenzialmente identica al metodo usato per il failover a un database sottoscrittore con mirroring. I sottoscrittori di replica transazionale non necessitano di una gestione speciale durante la partecipazione ai gruppi di disponibilità AlwaysOn. Per partecipare a un gruppo di disponibilità, i sottoscrittori devono eseguire SQL Server 2012 (11.x) o versioni successive. Per altre informazioni, vedere Sottoscrittori di replica e gruppi di disponibilità AlwaysOn (SQL Server)

  • I metadati e gli oggetti presenti all'esterno del database non vengono propagati alle repliche secondarie, inclusi account di accesso, processi, server collegati. Se i metadati e gli oggetti sono necessari nel nuovo database primario dopo il failover, è necessario copiarli manualmente. Per altre informazioni, vedere Gestire gli account di accesso per i processi usando i database in un gruppo di disponibilità AlwaysOn.

Gruppi di disponibilità distribuiti

Il server di pubblicazione o il database di distribuzione in un gruppo di disponibilità non può essere configurato come parte di un gruppo di disponibilità distribuito. Il database del server di pubblicazione in un gruppo di disponibilità e il database di distribuzione in un gruppo di disponibilità richiedono entrambi un endpoint listener per la configurazione e l'utilizzo appropriati. Non è tuttavia possibile configurare un endpoint del listener per un gruppo di disponibilità distribuito.

Replica

Cattura delle modifiche ai dati

Tracciamento delle modifiche

Contenuti correlati

  • Last updated on