Resumo de Requisitos para Captura e Entrega de Bancos de Dados em um Grupo de Disponibilidade Sempre Ativo

O Oracle GoldenGate for SQL Server suporta captura de uma réplica principal ou de uma réplica secundária de modo síncrono somente leitura de um Grupo de Disponibilidade Always On e entrega para a réplica principal.

Ao capturar a partir de uma réplica principal ou secundária em um Grupo de Disponibilidade Sempre Ativo, é importante entender que o processo de captura só deve ler transações reforçadas do log e que não há potencial de perda de dados entre qualquer banco de dados de réplica do qual o Oracle GoldenGate seja ou venha a ser capturado.

Conexão do Banco de Dados

Para Extract e Replicat, é recomendável criar uma conexão de banco de dados que use o Listener do Grupo de Disponibilidade Sempre Ativo para a conexão.

• Para o Replicat, a conexão com o Listener permite que o Replicat se reconecte se a réplica principal executar um failover para uma nova instância, sem precisar editar manualmente as definições de conexão para apontar para o novo principal.

• Para a conexão do Extract com o Listener, não só permite a reconexão com o principal sem editar a conexão para apontar para a nova instância, mas também fornece a capacidade opcional de executar os procedimentos armazenados de extração de dados do Extract, em um secundário somente leitura.

• Para os processos Extract e Replicat conectados a um ambiente Always On, use o parâmetro AUTORESTART do Manager para reiniciar os processos após um failover.

• Para rotear as consultas de extração de dados do Extract para um secundário somente para leitura, certifique-se de que a conexão use o Listener, que você tenha uma ou mais réplicas secundárias somente para leitura configuradas para tratar o roteamento somente para leitura e que o Extract seja executado com o parâmetro TRANLOGOPTIONS ALWAYSONREADONLYROUTING.

  Consulte a seguinte documentação da Microsoft sobre como configurar o roteamento somente leitura: 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 Complementar

O registro em log complementar deve ser ativado por meios normais (ADD TRANDATA) usando o Admin Client ou a interface Web conectada à réplica principal e não em uma réplica secundária.

• Crie um DSN para a réplica principal ou para o Listener do Grupo de Disponibilidade Sempre Ativo, para estabelecer conexão usando DBLOGIN para executar ADD TRANDATA.

• Ao ativar o registro em log complementar no banco de dados de réplica principal, o job Captura de Dados de Alteração do SQL Server não é criado automaticamente em nenhuma réplica secundária. Após o failover de um primário para um secundário, você deve criar manualmente o job Captura de Dados de Alteração do SQL Server e o job Limpeza do Oracle CDC, se estiver em uso, na nova réplica principal.

  EXECUTE sys.sp_cdc_add_job N'capture

  • Ao criar o trabalho Captura de CDC do SQL Server no novo primário, as definições de configuração padrão são implementadas. Portanto, se você tiver modificado anteriormente os valores padrão na réplica primária anterior, precisará executar sys.sp_cdc_change_job no novo principal e definir os valores de acordo. Observação: Consulte a documentação da Microsoft sobre como ativar o job de Captura do CDC para Réplicas Secundárias AlwaysOn para obter mais informações.

Requisitos e considerações operacionais

• Quando uma instância não é mais a instância principal, mas tem o trabalho de captura CDC do SQL Server instalado, o trabalho deixa de ser executado após algum tempo e não tenta reiniciar. No failover de volta para essa instância, o job não é iniciado automaticamente, portanto, ele deve ser iniciado manualmente.

• Se os bancos de dados de réplica secundários não estiverem em sincronia com o banco de dados de réplica principal, o job de captura CDC não avançará no log e, portanto, nenhum registro será capturado por um Extract, até que as réplicas principal e secundária sejam sincronizadas. Veja este artigo da Microsoft para mais detalhes:

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

  Observação: ao capturar de uma réplica principal ou secundária em um Grupo de Disponibilidade Sempre Ativo, é importante entender que o processo de captura só deve ler transações reforçadas do log e que não há potencial de perda de dados entre nenhum banco de dados de réplica do qual o Oracle GoldenGate seja ou venha a ser capturado.

• Ao executar um Extract em um servidor Windows ou Linux de camada intermediária, defina a data, a hora e o fuso horário do servidor de camada intermediária para a mesma da réplica principal.

• Se o Extract estiver configurado para capturar a partir de uma réplica secundária legível, mas não estiver configurado com roteamento somente leitura, o job Captura CDC do SQL Server deverá ser criado com base na réplica secundária antes de iniciar o Extract, pois o Extract verificará se o job existe. Para criar o job do SQL Server CDC Capture, qualquer secundário em potencial que tenha um Extract conectado a ele deve, em algum momento, ser definido como um banco de dados Primário gravável e, em seguida, seguir as etapas acima, em log complementar, para adicionar manualmente o job do SQL Server CDC Capture.

• Se você estiver desinstalando o Oracle GoldenGate e desativando a Captura de Dados de Alteração em um banco de dados que faça parte de um grupo de disponibilidade Always On, siga as etapas extras fornecidas em Desativando a Captura de Dados de Alteração.