Openflow Connector for MySQL: Manutenção¶

Nota

O conector está sujeito aos Termos do conector Snowflake.

Este tópico descreve considerações de manutenção importantes e práticas recomendadas para manter o Openflow Connector for MySQL, como reinstalar o conector ou definir a posição inicial do log binário para carregamento.

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.

Aviso

Para que o conector continue replicando a partir da mesma posição do fluxo CDC em que parou antes da reinstalação, o banco de dados de origem deve reter o log binário por tempo suficiente para abranger o período desde que o conector anterior foi interrompido até o novo conector ser iniciado. Certifique-se de que o parâmetro binlog_expire_logs_seconds do servidor MySQL seja alto o suficiente e mantenha o tempo de reinstalação no mínimo.

O valor de binlog_expire_logs_seconds precisa ser maior que o tempo esperado para reinstalar o conector. Normalmente, o valor de 86.400 segundos (um dia em segundos) é suficiente; no entanto, tempos mais longos podem ser apropriados para garantir o tempo de reinstalação.

Pré-requisitos¶

Revise e anote os valores de contexto dos parâmetros do conector. Se você estiver reinstalando 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.

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 do Openflow, selecione a guia Runtimes.
4. Selecione o tempo de execução que contém o conector.
5. Selecione o conector.
6. Pare a ação Set Tables for Replication do processador mais alto no grupo Snapshot Load.
7. Pare a ação Read MySQL CDC Stream 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 todas as FlowFiles no conector sejam processadas e as filas estejam vazias. Quando todas as FlowFiles forem processadas, o valor Queued no grupo de processadores do conector se tornará zero. Se houver algum item restante nas filas do conector original, talvez haja 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 sem interferir na nova instância, desde que permaneça parado.
Crie uma nova instância do conector. Se você estiver usando o mesmo tempo de execução do conector original, poderá manter os contextos de parâmetros existentes e reutilizar as configurações.
Se você estiver instalando 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 padrões, conforme descrito em Configure o Openflow Connector for MySQL.
Navegue até o contexto de MySQL Ingestion Parameters e defina os seguintes parâmetros:
- Ajuste o parâmetro Ingestion Type para incremental. Para obter mais informações sobre as preocupações, consulte Habilitação de replicação incremental sem instantâneos.
- Ajuste o parâmetro Starting Binlog Position para Earliest. Para obter mais informações e saber sobre as possíveis preocupações, consulte Especificação do carregamento a partir da posição do log binário.
Inicie o novo conector.

Notas de uso¶

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

Especificação do carregamento a partir da posição do log binário¶

O conector Openflow Connector for MySQL permite que você selecione a posição inicial em que os logs binários MySQL são lidos. 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.

Observe que alternar um conector em execução da posição mais recente para a mais antiga faz com que todo o log binário disponível seja lido, processado e aplicado novamente à tabela de destino.

Aviso

Enquanto o log binário está sendo relido, as colunas e 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 seguintes carregamentos de instantâneos de controle de parâmetros estão disponíveis no contexto de Ingestion Parameters:

Parâmetro	Descrição
Posição inicial do log binário	`Mais recente` (padrão): a leitura do fluxo CDC 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 da posição do log binário mais antiga disponível.
Releitura de tabelas no estado	`New` (padrão): ao reler o log binário, somente esses eventos serão processados a partir das novas tabelas adicionadas à replicação após o início da releitura. Outros eventos são descartados até que o conector atinja a posição logo antes do início da releitura. `Any active`: reler e reprocessar eventos de qualquer tabela que está em replicação.

Para determinar se o conector terminou de reler o log binário:

Navegue até a tela do Openflow.
Abra o grupo de processos Incremental Load.
Clique com o botão direito do mouse na ação Read MySQL CDC Stream nomeada do processador mais alto e selecione View state.
Compare as entradas de estado:
- binlog.position.rewind: a última posição que o processador leu antes de a nova leitura do log binário começar.
- binlog.position.dml: a última posição atual lida pelo processador. Desde que esse valor seja menor que o valor de reversão acima, o processador ainda estará relendo o log binário.

Notas de uso¶

Depois que um conector em execução for alternado para ler a partir da posição mais antiga e começar a ser executado, o processo não poderá ser reconfigurado ou cancelado, e continuará até que a posição de leitura atual atinja a posição em que estava antes de começar.
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.
Se o log binário contiver eventos de uma tabela anterior que foi descartada e recriada no banco de dados de origem, a releitura do fluxo reprocessará todos os eventos no destino atual. O conector não distingue entre uma tabela de origem anterior e atual se elas compartilham o mesmo nome.