Openflow Connector for SQL Server: Manutenção

Nota

O conector está sujeito aos Termos do conector Snowflake.

Este tópico descreve as considerações de manutenção e as práticas recomendadas para o Openflow Connector for SQL Server, como reinstalar o conector ou definir a posição inicial do rastreamento de alterações.

Essas operações são frequentemente usadas em conjunto com a replicação incremental com instantâneos.

Reinstalação do conector

Esta seção apresenta instruções de como reinstalar o conector e continuar replicando dados das mesmas tabelas sem precisar criar um instantâneo delas novamente. Ela aborda situações em que o novo conector é instalado no mesmo tempo de execução e também movido para um novo tempo de execução.

Pré-requisitos

Revise e anote os valores de contexto dos parâmetros do conector. Se você reinstalar o conector no mesmo tempo de execução, poderá reutilizar o contexto existente. Se a nova instância estiver localizada em um tempo de execução diferente, você deverá inserir novamente todos os parâmetros.

  1. Finalize o processamento de todas as FlowFiles em andamento no conector existente e pare o conector.

    1. Faça login no Snowsight.

    2. No menu de navegação, selecione Ingestion » Openflow.

    3. No painel Openflow, selecione a guia Runtimes.

    4. Selecione o tempo de execução que contém o conector.

    5. Selecione o conector.

    6. Pare o processador mais alto Set Tables for Replication no grupo Snapshot Load.

    7. Pare a ação Read SQLServer Change Tracking tables do processador mais alto no grupo Incremental Load.

    8. Se você alterou o valor do parâmetro Merge Task Schedule CRON, reverta-o para * * * * * ?; caso contrário, as filas não serão esvaziadas até a próxima execução agendada.

      Aguarde até que todos os FlowFiles do conector tenham sido processados e todas as filas estejam vazias. Quando todos os FlowFiles tiverem sido processados, o valor de Queued no grupo de processadores do conector se tornará zero. Se houver itens restantes nas filas do conector original, poderá haver lacunas de dados quando o novo conector for iniciado.

    9. Pare todos os processadores e os serviços do controlador no conector.

    Cuidado

    O conector existente pode permanecer no tempo de execução e não interferir na nova instância, desde que permaneça parado.

  2. Crie uma nova instância do conector. Se você usar o mesmo tempo de execução do conector original, poderá manter os contextos de parâmetros existentes e reutilizar as configurações.

  3. Se você instalar em um tempo de execução diferente ou tiver excluído os contextos de parâmetros anteriores, insira as definições de configuração nos novos contextos de parâmetros, incluindo os nomes das tabelas e os padrões, conforme descrito em Configure o Openflow Connector for SQL Server.

  4. Navegue até o contexto de SQLServer Ingestion Parameters e defina os seguintes parâmetros:

  5. Inicie o novo conector.

Notas de uso

O novo conector usa as tabelas de destino existentes criadas pelo conector original, mas cria novas tabelas de diário.

Especificar o carregamento a partir da posição da tabela de rastreamento de alterações

O conector Openflow Connector for SQL Server permite que você selecione a posição inicial em que as tabelas de rastreamento de alterações são lidas. Por padrão, o conector lê a partir da última posição disponível. Como alternativa, você pode escolher a posição mais antiga disponível na instância de origem. É comum começar da posição mais antiga ao reinstalar o conector. Isso permite que a nova instância se atualize e continue replicando as tabelas existentes sem precisar tirar instantâneos de cada uma novamente.

Mudar um conector em execução da posição mais recente para a mais antiga faz com que o conteúdo das tabelas de rastreamento de alterações seja relido, reprocessado e reaplicado à tabela de destino.

Aviso

Enquanto as tabelas de rastreamento de alterações estão sendo relidas, os dados nas tabelas de destino afetadas podem ficar fora de sincronia com as respectivas fontes até que todos os eventos tenham sido reprocessados e mesclados.

Os parâmetros a seguir estão disponíveis no contexto Ingestion Parameters:

Parâmetro

Descrição

Posição inicial de rastreamento de alterações

  • Latest (padrão): a leitura da tabela de rastreamento de alterações começa na última posição disponível e continua a partir daí.

  • Earliest: alterna o carregamento incremental para iniciar ou reiniciar a leitura a partir das posições da tabela de rastreamento de alterações mais antigas disponíveis.

Releitura de tabelas no estado

  • New (padrão): somente novas tabelas, adicionadas após a posição inicial ter sido mudada para Earliest, terão suas tabelas de rastreamento de alterações lidas a partir das posições mais antigas disponíveis. As tabelas que iniciaram a replicação antes da mudança de configuração continuarão lendo a partir de suas últimas posições.

  • Any active: reler e reprocessar alterações de qualquer tabela que está em replicação.

Para determinar se o conector terminou de reler as tabelas de rastreamento de alterações:

  1. Navegue até a tela do Openflow.

  2. Abra o grupo de processos Incremental Load.

  3. Clique com o botão direito do mouse na ação Read SQLServer Change Tracking tables nomeada do processador mais alto e selecione View state.

  4. Verifique as entradas de estado de cada tabela com chaves começando com position.. Se um valor for 0/0, o conector ainda não terminou de reler as alterações dessa tabela.

Notas de uso

  • Depois que você mudar um conector em execução para ler as posições mais antigas e iniciá-lo, não será possível reconfigurar ou cancelar o processo, e ele continuará até que as posições lidas atualmente atinjam os valores mais recentes.

  • Alternar para a posição mais antiga em um conector em execução, para quaisquer tabelas que forem reprocessadas, concluirá seus diários existentes e criará novas tabelas de diário.

Linguagem: Português