Utilizzare i gruppi di disponibilità Always On


Questa pagina descrive cosa sono i gruppi di disponibilità Always On in SQL Server e come Datastream li supporta per gli scenari di failover e recupero dei dati.

Panoramica dei gruppi di disponibilità Always On

In SQL Server, i gruppi di disponibilità Always On sono una soluzione di alta affidabilità che consente di preparare i database per gli scenari di ripristino di emergenza.

I gruppi di disponibilità Always On massimizzano la disponibilità dei database per le aziende. I gruppi di disponibilità supportano un ambiente replicato per un insieme selezionato di database, noti come database di disponibilità. Ogni gruppo include un insieme di database principali per le attività di lettura e scrittura e fino a otto insiemi di database secondari corrispondenti. I database secondari possono facoltativamente consentire l'accesso in sola lettura o le operazioni di backup.

Per ulteriori informazioni sui gruppi di disponibilità Always On, consulta Che cos'è un gruppo di disponibilità Always On? nella documentazione di SQL Server.

Per informazioni sui prerequisiti del gruppo di disponibilità Always On per un'istanza di SQL Server, consulta la documentazione di SQL Server.

Configurare Datastream per l'utilizzo con i gruppi di disponibilità Always On

Datastream supporta la modalità di disponibilità synchronous-commit con il metodo CDC delle tabelle delle modifiche. In questa modalità, il database secondario rimane sincronizzato con il database principale corrispondente finché la sincronizzazione dei dati non si interrompe. La conferma di una transazione viene inviata al client solo quando la replica secondaria scrive i record del log delle transazioni in entrata su un disco.

Per informazioni sulle modalità di disponibilità, consulta Differenze tra le modalità di disponibilità per un gruppo di disponibilità Always On.

Per configurare l'istanza di SQL Server per l'utilizzo con i gruppi di disponibilità Always On, devi abilitare l'agente SQL Server per acquisire i log in caso di failover, quindi eseguire un job di pulizia. Prima di poter eseguire questa operazione, devi modificare i passaggi del job dell'agente CDC per verificare se la replica corrente è effettivamente quella principale. Questa operazione viene eseguita utilizzando la funzione sys.fn_hadr_is_primary_replica.

Utilizza i seguenti comandi per configurare l'istanza:

  -- Check if the current replica is a primary for the corresponding database.
  USE [DATABASE_NAME];
  DECLARE @DatabaseName SYSNAME = DB_NAME();
  IF (SELECT sys.fn_hadr_is_primary_replica(@DatabaseName)) = 1
  BEGIN
  -- If the replica isn't a primary, the code block that follows is skipped
  EXECUTE sys.sp_cdc_add_job @job_type = 'capture';
  EXECUTE sys.sp_cdc_add_job @job_type = 'cleanup';
  END

Limitazioni note

Le limitazioni note per l'utilizzo di Datastream con i gruppi di disponibilità Always On includono:

  • Datastream non supporta la risoluzione DNS privata basata sugli indirizzi IP del listener. Devi eseguire manualmente il failover degli indirizzi IP per le repliche.
  • Dopo un failover del gruppo di disponibilità, devi assicurarti manualmente che i job di acquisizione e pulizia dell'agente SQL Server siano in esecuzione sul nuovo database principale. In caso contrario, potrebbero verificarsi perdite di dati se i log delle transazioni vengono troncati prima che Datastream possa leggere le modifiche.
  • Se una replica viene creata prima del database principale, devi aggiungere l'etichetta always_on_availability: true al flusso per evitare problemi di integrità dei dati. Per informazioni sull'aggiunta di etichette al flusso, consulta Definire le impostazioni per il flusso.

Passaggi successivi

  • Scopri di più su come funziona Datastream con le origini SQL Server.