Checkpointing, Recuperação e Semântica de Entrega

Saiba mais sobre o checkpoint, a recuperação e a entrega na configuração de fluxos de dados.

O contrato público pos

Por padrão, cada registro DML ou DDL não de metadados inclui um token pos opaco. Internamente, o token transporta informações de posicionamento GoldenGate suficientes para identificar um registro, incluindo informações de commit ou sequência, identidade da transação e sequenciamento de registro. Sua codificação não é um formato de coordenada de origem pública e pode variar de acordo com o tipo de origem e a versão.

Executar Não
Armazene a string exata após o processamento bem-sucedido. Faça o parse para obter um Oracle SCN, PostgreSQL LSN, coordenada binlog MySQL, SQL Server LSN ou qualquer outro deslocamento específico da origem.
Escopo para o Fluxo de Dados, contrato de trilha de origem e consumidor. Compare posições lexicamente ou numericamente para determinar a ordem.
Codifique-o em porcentagem quando usado como begin em um URL. Reduzir, normalizar, concatenar, descriptografar ou reescrevê-lo.
Use campos separados csn, xid, opSeqno e transInd para diagnóstico ou análise de transação. Reutilizar uma posição de outro fluxo, um contrato de filtro diferente ou outro ambiente.

Portabilidade de origem: O algoritmo de recuperação do cliente é intencionalmente o mesmo para o Oracle, PostgreSQL, MySQL, SQL Server e outras origens suportadas: persista o opaco pos e retorne-o inalterado. A análise de coordenadas específicas da origem não é necessária nem suportada pelo contrato do cliente do Data Streams.

Um ponto de verificação deve representar o último registro cujo efeito comercial é durável. Salvar antes da gravação do negócio pode perder dados após uma falha. Salvar após uma gravação não-idempotente em uma transação separada pode produzir uma duplicata após uma falha.

Padrões de ponta a ponta exatamente uma vez

Padrão Como funciona Usar quando
Pia atômica e transação de checkpoint Grave o registro de negócios e o novo pos na mesma transação de banco de dados. O sumidouro e o ponto de verificação podem compartilhar um armazenamento de dados transacional.
Chave de idempotência Use pos, ou uma chave de negócios mais a identidade da operação, como uma chave exclusiva; a repetição do mesmo registro se torna um no-op. A pia suporta singularidade ou gravações condicionais.
Log de preparação durável Anexe o registro e pos atomicamente a um log durável e processe o log de forma independente. O processamento de negócios é lento, com várias etapas ou abrange sistemas.
Pelo menos uma vez com reconciliação Aceitar duplicatas, desduplicar periodicamente e reconciliar contagens ou somas de verificação. O caso de uso tolera eventuais correções.

OBSERVAÇÃO: o Fluxo de Dados exactlyOnce descreve a supressão e a resposta de recuperação duplicadas do lado do serviço. Ele não produz um efeito colateral arbitrário downstream exatamente uma vez porque o protocolo WebSocket não tem confirmação transacional por registro com o cliente.

Qualidade de serviço

Consulte as diretrizes de Qualidade de Serviço da seguinte tabela:

Modo Duplicado Posição salva indisponível Uso recomendado
exactlyOnce Suprime duplicações reconhecidas durante a recuperação e o tratamento de reinício/abertura da trilha de origem. Falha na conexão com um erro. Padrão para processamento de negócios durável. Emparelhar com lógica de consumidor atômica ou idempotente.
atLeastOnce Não suprime duplicações durante a recuperação e o tratamento de reinício/abertura da trilha de origem. Falha na conexão com um erro. Use quando a repetição for preferida e o consumidor for projetado para deduplicar.
atMostOnce Suprime duplicatas reconhecidas. O serviço localiza o próximo registro disponível e continua, o que pode ignorar dados. Use somente quando a perda de dados for explicitamente aceitável e o progresso futuro for mais importante do que a integridade.

Metadados e ordenação da transação

Consulte a seguinte tabela para obter metadados de transação e requisitos de ordenação:

Campo Finalidade Limitações
xid Agrupa registros associados a uma transação de origem. O formato é dependente da origem e deve ser tratado como uma string.
csn Expõe o número de sequência de confirmação de origem quando configurado. Significado e formato são dependentes da origem; não use como token de reinicialização.
opSeqno Número de sequência do registro na transação. Ative e renomeie-o explicitamente.
transInd B first, M middle, E last ou W transação de operação inteira/única. A filtragem pode remover registros e tornar a sequência observada incompleta. O processamento coordenado também pode reduzir a utilidade.
pos Posição de recuperação exclusiva para o registro. Opaco; não classifique nem derive limites de transação de seu texto.

Não suponha que uma conexão sempre comece em um limite de transação. Uma consulta de carimbo de data/hora ou um limite de trilha retida pode começar depois que operações anteriores não estiverem mais disponíveis. Se o aplicativo exigir transações de origem completas, crie um buffer de transação, defina limites para transações grandes e especifique o que fazer quando o início de uma transação estiver indisponível.

Quando uma posição salva está indisponível

Para verificar uma posição salva que se torna indisponível, verifique o seguinte:

Planejamento de retenção de trilhas

Defina a retenção da trilha para exceder o objetivo do ponto de recuperação mais a detecção operacional e o tempo de resposta. Por exemplo, um consumidor que pode ficar off-line por 24 horas e requer 12 horas para que a resposta a incidentes precise de mais de 36 horas de trilha disponível, com margem adicional para grandes backlogs e manutenção. O bufferSize não estende a retenção de trilha.