Riepilogo dei requisiti per l'acquisizione e la distribuzione dei database in un gruppo di disponibilità Sempre attivo

Oracle GoldenGate per SQL Server supporta l'acquisizione da una replica primaria o da una replica secondaria in modalità sincrona di sola lettura di un gruppo di disponibilità Sempre attivo e la consegna alla replica primaria.

Quando si acquisisce da una replica primaria o secondaria in un gruppo di disponibilità Sempre attiva, è importante comprendere che il processo di acquisizione deve solo leggere le transazioni protette dal log e che non vi è alcun potenziale di perdita di dati tra qualsiasi database di replica da cui Oracle GoldenGate è o acquisterà.

Connessione al database

Per Extract e Replicat, si consiglia di creare una connessione al database che utilizzi il listener del gruppo di disponibilità Sempre attivo per la connessione.

• Per Replicat, la connessione al listener consente al Replicat di riconnettersi se la replica primaria esegue un failover a una nuova istanza, senza dover modificare manualmente le impostazioni di connessione per puntare al nuovo primario.

• Per l'estrazione che si connette al listener non solo consente di riconnettersi al primario senza modificare la connessione per puntare alla nuova istanza, ma fornisce anche la possibilità facoltativa di eseguire le stored procedure di estrazione dati dell'estrazione, rispetto a un secondario di sola lettura.

• Per Extract e Replicat connessi a un ambiente Always On, utilizzare il parametro AUTORESTART per Manager per riavviare i processi dopo un failover.

• Per instradare le query di estrazione dati di Extract a un database secondario di sola lettura, assicurarsi che la connessione utilizzi il listener, che siano presenti una o più repliche secondarie di sola lettura configurate per gestire l'instradamento di sola lettura e che Extract venga eseguito con il parametro TRANLOGOPTIONS ALWAYSONREADONLYROUTING.

  Fare riferimento alla documentazione Microsoft riportata di seguito per la configurazione dell'instradamento di sola lettura: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/configure-read-only-routing-for-an-availability-group-sql-server?view=sql-server-2017

Log supplementare

La registrazione supplementare deve essere abilitata in modo normale (ADD TRANDATA) utilizzando il client di amministrazione o l'interfaccia Web connessa alla replica primaria e non a una replica secondaria.

• Creare un DSN nella replica primaria o nel listener del gruppo di disponibilità Sempre attivo per connettersi utilizzando DBLOGIN per eseguire ADD TRANDATA.

• Quando si abilita il log supplementare per il database di replica primario, il job SQL Server Change Data Capture non viene creato automaticamente sulle repliche secondarie. Dopo il failover da un primario a un secondario, è necessario creare manualmente il job SQL Server Change Data Capture e il job Oracle CDC Cleanup, se in uso, nella nuova replica primaria.

  EXECUTE sys.sp_cdc_add_job N'capture

  • Quando si crea il job di acquisizione CDC di SQL Server sul nuovo primario, vengono impostate le impostazioni di configurazione predefinite. Pertanto, se in precedenza sono stati modificati i valori predefiniti nella precedente replica primaria, è necessario eseguire sys.sp_cdc_change_job sul nuovo database primario e impostare i valori di conseguenza. Nota: per ulteriori informazioni, consultare la documentazione di Microsoft su come abilitare il job di acquisizione CDC per le repliche secondarie AlwaysOn.

Requisiti operativi e considerazioni

• Quando un'istanza non è più l'istanza primaria ma il job SQL Server CDC Capture è installato, l'esecuzione del job non viene più eseguita dopo un certo periodo di tempo e non viene eseguito alcun tentativo di riavvio. Quando il failover torna a quell'istanza, il job non viene avviato automaticamente, quindi deve essere avviato manualmente.

• Se i database di replica secondari non sono sincronizzati con il database di replica primario, il job di acquisizione CDC non avanzerà nel log e pertanto nessun record verrà acquisito da Extract fino a quando le repliche primarie e secondarie non verranno sincronizzate. Vedi questo articolo di Microsoft per maggiori dettagli:

  https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/replicate-track-change-data-capture-always-on-availability?view=sql-server-2017

  Nota: quando si acquisisce da una replica primaria o secondaria in un gruppo di disponibilità Sempre attivo, è importante comprendere che il processo di acquisizione deve solo leggere le transazioni protette dal log e che non vi è alcuna possibilità di perdita di dati tra qualsiasi database di replica da cui Oracle GoldenGate è o acquisterà.

• Quando si esegue Extract da un server Windows o Linux di livello intermedio, impostare la data, l'ora e il fuso orario del server di livello intermedio sullo stesso livello della replica primaria.

• Se Extract è configurato per l'acquisizione da una replica secondaria leggibile, ma non è configurato con l'instradamento di sola lettura, il job di acquisizione CDC di SQL Server deve essere creato sulla replica secondaria prima di avviare l'estrazione, poiché l'estrazione controllerà se il job esiste. Per creare il job di acquisizione CDC di SQL Server, qualsiasi potenziale secondario a cui sarà connesso un processo Extract deve essere impostato su un database primario scrivibile e quindi seguire i passi precedenti, sotto log supplementare, per aggiungere manualmente il job di acquisizione CDC di SQL Server.

• Se si disinstalla Oracle GoldenGate e si disabilita Change Data Capture in un database che fa parte di un gruppo di disponibilità Always On, attenersi alla procedura aggiuntiva fornita in Disabilitazione di Change Data Capture.