Realtime Compute for Apache Flink:FAQ and solutions for ingestion

Sintoma

• O job reinicia repetidamente durante a fase de snapshot.

• Os logs do JobManager contêm um stack trace de OutOfMemoryError (OOM).

• Na aba Alarm, as métricas Num of remaining SnapshotSplits e Num of processed SnapshotSplits apresentam valores excepcionalmente altos.

Causa

Durante a fase de snapshot, o source do MySQL persiste todos os metadados de shard das tabelas no estado do job Flink. Se o job processar um grande volume de dados ou utilizar tamanhos de shard muito pequenos, o JobManager cria uma quantidade excessiva de shards e esgota a memória disponível.

Solução

1. Aumente os recursos de memória alocados ao JobManager.

2. Ajuste os seguintes parâmetros para aumentar a memória heap e off-heap do JobManager:

   • jobmanager.memory.heap.size

   • jobmanager.memory.off-heap.size

Sintoma

• O TaskManager fica sem memória no final da fase de snapshot, geralmente quando resta apenas um pequeno número de shards.

• Ao pesquisar using select statement nos logs do TaskManager, nota-se que a última consulta ilimitada envolve um volume de dados muito grande.

Causa

A leitura prolongada de dados durante a fase de snapshot faz com que dados incrementais se acumulem nos shards finais. O TaskManager esgota a memória ao processar esses grandes shards acumulados.

Solução

1. Defina a seguinte opção:

      scan.incremental.snapshot.unbounded-chunk-first.enabled: true

2. Execute o snapshot novamente.

Sintoma

• O job entra na fase incremental, mas falha durante a restauração do estado.

• Os logs do JobManager indicam um OOM.

Causa

O VVR 11.1 e versões anteriores podem não limpar adequadamente as informações de schema de tabela persistidas no estado do job após a transição para a fase incremental. Esses dados residuais de schema se acumulam e causam um OOM quando o job é restaurado a partir de um checkpoint.

Solução

1. Atualize para o VVR 11.2 ou posterior.

Sintoma

• O job continua em execução sem reiniciar após uma alteração de schema de tabela sem bloqueio.

• A métrica CurrentFetchTimeLag avança conforme o esperado, indicando que os dados estão sendo buscados.

• O source do MySQL para de produzir novos dados e a métrica CurrentEmitTimeLag deixa de ser atualizada.

Causa

O VVR 11.1 e versões anteriores não conseguem processar corretamente eventos DDL gerados por ferramentas de alteração de schema sem bloqueio, como pt-osc, o que paralisa o pipeline de dados.

Solução

1. Atualize para o VVR 11.2 ou posterior.

2. Defina a seguinte opção:

      scan.parse.online.schema.changes.enabled: true

Sintoma

• O job reinicia inesperadamente após uma alteração de schema de tabela sem bloqueio (por exemplo, usando pt-osc).

• Os logs do operador Transform indicam um erro de incompatibilidade de tipo de coluna.

Causa

No VVR 11.1, se um volume significativo de dados for inserido em uma tabela durante uma alteração de schema sem bloqueio, o mecanismo pode gerar um evento não analisável.

Solução

1. Atualize para o VVR 11.2 ou posterior.

2. Reinicie o job com estado a partir de um savepoint criado antes da alteração de schema sem bloqueio.

Sintoma

• Falha ao reiniciar o job com estado a partir de um savepoint criado antes de uma alteração de schema de tabela.

• A mensagem de erro indica uma exceção de incompatibilidade de schema de tabela durante o consumo de logs binários.

Causa

O VVR 11.1 e versões anteriores não suportam reinicializações com estado a partir de savepoints que contenham um schema de tabela incompatível.

Solução

1. Atualize para o VVR 11.2 ou posterior.

2. Após a atualização, reinicie o job a partir de um savepoint anterior à alteração de schema.