O erro mais perigoso do CDC na recuperação ocorre após o fracasso.

Quando um sistema de distribuição de alimentos e bebidas do CDC falha, o instinto é automático: fazê-lo funcionar novamente. Rapidamente.

Entretanto, a fonte pode ainda estar processando transações. O acúmulo de solicitações pode continuar crescendo. Relatórios, aplicativos e processos subsequentes podem já estar trabalhando com dados desatualizados.

E, mais cedo ou mais tarde, alguém pergunta: Podemos simplesmente reiniciar?

Geralmente é nesse momento que a recuperação fica mais difícil.

Porque o verdadeiro problema muitas vezes não é a falha em si, mas sim tudo o que aconteceu enquanto a replicação não estava em execução.

• O que aconteceu durante esse intervalo?
• Podemos retomar com segurança de onde paramos?
• Precisamos de uma resincronização ou de uma reinicialização completa?
• Como podemos ter certeza de que nada passou despercebido?

Uma reinicialização bem-sucedida prova apenas uma coisa: a replicação está funcionando novamente.

Isso não comprova que o alvo esteja completo, atualizado ou correto.

As falhas mais perigosas do CDC nem sempre são aquelas em que a replicação para. São aquelas em que a replicação recomeça e ninguém consegue explicar o que aconteceu durante a interrupção ou provar que os dados recuperados são confiáveis.

O objetivo não é simplesmente reiniciar o mais rápido possível. É evitar que uma falha se transforme em uma recuperação mais difícil. Uma tarefa de replicação interrompida não significa automaticamente que as transações foram perdidas. E uma reinicialização bem-sucedida não significa automaticamente que o destino esteja correto.

Como verificar se uma falha no pipeline do CDC causou perda de dados e se é possível reiniciá-lo com segurança.

O primeiro passo não é clicar em Reiniciar.

As diretrizes atuais do NIST para resposta a incidentes separam detecção, resposta, recuperação e melhoria contínua. Essa disciplina mais ampla apoia o estabelecimento do que aconteceu e a preservação de contexto suficiente para tomar uma decisão de recuperação defensável antes de alterar o ambiente.*

Serve para estabelecer onde o processamento parou, o que continuou acontecendo na origem, qual o estado atual para a recuperação e quais evidências serão necessárias posteriormente.

Consideradas em ordem, as sete perguntas abaixo ajudarão você a percorrer esse processo.

O que exatamente falhou e quando?

"Replicação interrompida" não é específico o suficiente para escolher um caminho de recuperação.

Primeiro, determine onde ocorreu o problema. Foi replicação?

• completamente parado?
• Ainda em andamento, mas ficando para trás?
• Capturar as alterações, mas não conseguir implementá-las?
• Não foi possível aplicar as alterações no destino?
• afetado por um evento do sistema de origem?
• afetado pelo alvo, pela rede ou por outra parte do ambiente?

Em seguida, estabeleça a cronologia. O momento em que alguém percebeu o problema pode não ser o momento em que o problema começou.

Verificar

• Quando ocorreu a última atividade de replicação bem-sucedida confirmada?
• A captura da fonte ainda está em andamento?
• O processamento subsequente está progredindo?
• O processo de candidatura está em andamento?
• A fonte continuou processando transações?
• O alvo está disponível?
• Houve alguma alteração nesse mesmo período — esquema, configuração, segurança, infraestrutura, manutenção ou carga de trabalho?

Por que isso importa

Uma falha de captura, uma falha de aplicação, um acúmulo crescente de tarefas e uma interrupção do sistema de destino são problemas diferentes. Eles podem exigir equipes diferentes e ações de recuperação diferentes. Você estará pronto para prosseguir quando puder dizer: "Foi aqui que o processamento parou, foi aqui que aconteceu e isto é o que foi afetado". Não simplesmente: "A replicação está interrompida em algum lugar".

Onde a replicação pode ser retomada com segurança?

Essa é uma das questões mais importantes na recuperação. As plataformas de replicação podem armazenar o estado do processo ou de reinicialização, o que ajuda a determinar de onde o processamento pode ser retomado após uma interrupção.

Dependendo da fonte e da plataforma, você poderá encontrar termos como:

• Estado de reinicialização
• Ponto de verificação
• Adicionar aos favoritos
• Posição do registro
• Resumir posição
• Outra coordenada de recuperação específica da fonte

Não assuma que esses termos signifiquem exatamente a mesma coisa em todas as plataformas. A questão importante é se você consegue identificar onde o processamento foi interrompido e se essa informação é confiável o suficiente para permitir a recuperação.

Marcadores de recuperação CDC para mainframe: estado de reinicialização, posições de log e Db2 para z/OS RBA/LRSN

Dependendo da origem e da plataforma de replicação, as equipes podem encontrar diferentes marcadores de recuperação e terminologia de posição de processamento. Para ambientes Db2 para z/OS, esses conceitos podem incluir RBA ou LRSN.

A questão importante é se existem informações de recuperação salvas válidas e se a equipe entende o que essas informações representam. Para processos de Captura de Dados de Alteração (CDC) do RDRS compatíveis, as informações de status salvas permitem que o processamento continue na posição correta específica da origem após a reinicialização. A posição e a terminologia dependem da tecnologia de origem.

Verificar

• O estado de reinicialização/processo salvo está disponível?
• O que exatamente esse estado representa?
• Quando foi atualizado pela última vez?
• Corresponde ao estado de processamento que você espera?
• O histórico da fonte relevante ainda está disponível?
• Aconteceu alguma coisa no alvo que altere as previsões de recuperação?

Por que isso importa

Ter uma posição conhecida no processo é muito diferente de reconstruir onde você acha que o pipeline parou durante um incidente. Você está pronto para prosseguir quando a equipe tem um estado de reinicialização/processo identificável e entende o que isso significa para essa origem e destino.

O que aconteceu enquanto a replicação estava inativa e o histórico de origem necessário ainda está disponível?

Se a origem continuasse em execução, as transações poderiam ter prosseguido enquanto o destino parava de receber alterações. Isso significa que a equipe precisa entender tanto a lacuna de replicação quanto o impacto subsequente.

Verifique a lacuna

• Há quanto tempo o alvo está atrasado?
• Qual o tamanho da lista de espera?
• A lista de espera está aumentando, estável ou diminuindo?
• Que histórico de fontes permanece disponível para o período afetado?
• Ocorreram inserções, atualizações, exclusões ou alterações de esquema suportadas?
• A plataforma oferece um caminho de recuperação compatível para essa combinação de origem e destino?

Para CDC baseado em logs, verifique a retenção de logs de origem e o histórico arquivado. Em alguns ambientes de CDC baseado em logs, os logs de origem retidos ou arquivados podem ser relevantes para processar alterações acumuladas durante uma interrupção. Os pré-requisitos exatos variam de acordo com:

• fonte
• plataforma
• configuração
• histórico retido
• topologia
• duração e natureza da interrupção

Não assuma que a existência de logs arquivados significa automaticamente que todos os caminhos de recuperação permanecem disponíveis. Confirme o que a plataforma suporta para o ambiente específico. Verifique quem já está usando o destino:

• Quais aplicações, relatórios, análises, APIs ou processos operacionais dependem disso?
• Eles ainda estão consumindo os dados?
• Será que essas equipes sabem que isso pode estar ultrapassado?
• Está se aproximando um prazo limite para liquidação, relatórios, lotes, clientes ou outras atividades comerciais?

Por que isso importa

Um pipeline ainda pode ser tecnicamente recuperável, mesmo que dados desatualizados a jusante já estejam se tornando um problema para o negócio. Você estará pronto para seguir em frente quando entender o que aconteceu durante a lacuna, o quanto você está atrasado e quem já pode ter sido afetado.

Reiniciar o ponto de verificação ou resincronizar completamente: qual caminho de recuperação se aplica?

É aqui que as equipes frequentemente sentem a pressão de tomar uma decisão rápida. Dependendo da plataforma, o estado de recuperação salvo pode ser chamado de ponto de verificação, marcador, estado de reinicialização, posição de processamento ou algo semelhante.

O que importa é se existe um caminho de recuperação compatível com o cenário de falha em questão. Às vezes, a replicação pode ser retomada a partir de um estado salvo e recuperar o atraso. Outras vezes, é necessária uma comparação ou ressincronização mais direcionada. E, em alguns casos, uma reinicialização mais abrangente é apropriada.

Dependendo da origem, do destino, da configuração, do histórico retido e do cenário de falha, os caminhos disponíveis podem incluir:

• Reiniciar a partir do estado de processo salvo
• O processo manteve as alterações históricas.
• Compare a origem e o destino para identificar as diferenças.
• Repare ou resincronize os dados afetados usando um método apropriado.
• Ressincronizar parcialmente os conjuntos de dados afetados.
• Execute uma resincronização mais abrangente ou uma recarga completa.

Como reiniciar um pipeline de CDC após uma falha sem uma carga inicial completa

Em alguns ambientes, uma carga inicial completa pode não ser necessária. A possibilidade de recuperação sem carga depende de condições como:

• Estado de reinicialização/processo utilizável
• Histórico de origem necessário ainda disponível
• O estado do alvo
• Comportamento de origem e destino suportado
• O tipo de falha
• Mecanismos de recuperação documentados da plataforma de replicação

O objetivo não é evitar uma reinicialização a todo custo. É determinar se uma reinicialização suportada ou um caminho de recuperação é apropriado para este incidente.

Verificar

• O estado de reinicialização/processo salvo está disponível e é compreendido?
• O histórico de origem necessário para a recuperação proposta ainda está disponível?
• O alvo está em um estado que favorece a recuperação?
• Ocorreu algum evento na origem ou no destino que altere as premissas de recuperação?
• Uma comparação pode ajudar a determinar se apenas parte dos dados foi afetada?
• Quanto tempo se prevê que leve para recuperar o atraso?
• Os sistemas subsequentes conseguem tolerar esse período de estagnação?
• Quais caminhos de recuperação a plataforma suporta para essa configuração exata de origem/destino?

Por que isso importa

Os profissionais descrevem a alternativa dolorosa de forma muito clara: "recarregamento completo" ou até mesmo "ressincronização do zero". A questão a ser respondida é: quando podemos nos recuperar sem recomeçar do zero e quando não podemos? Você estará pronto para prosseguir quando a equipe puder explicar por que o caminho de recuperação selecionado se adequa a este incidente específico.

O que pode estar faltando, duplicado, excluído, desatualizado ou fora de ordem?

Uma reinicialização bem-sucedida não prova, por si só, que o objetivo está correto. Dependendo dos dados e da arquitetura, as equipes devem procurar por:

• Alterações ausentes
• Alterações duplicadas ou reprocessadas
• Exclusões ausentes
• Valores obsoletos
• Inconsistências parciais ou relacionadas nos registros
• Questões de ordenação onde a sequência importa
• Alterações de esquema suportadas que ocorreram em torno do incidente

Um problema particularmente fácil de passar despercebido é a exclusão. Um pipeline pode parecer íntegro enquanto um registro que foi excluído na origem ainda permanece no destino.

Verificar

• Que comportamento de transação/alteração a plataforma documenta para esta origem e destino?
• O que acontece durante uma nova tentativa ou reprocessamento?
• Como são tratadas as exclusões de origem?
• Quais cenários de alteração de esquema são suportados?
• Quais comportamentos de organização são importantes para sua carga de trabalho?
• O que uma verificação de status normal poderia deixar de detectar?

Por que isso importa

A frase “Tudo está funcionando novamente” não indica se algo passou despercebido no processo. Você estará pronto para seguir em frente quando souber quais modos de falha são relevantes em seu ambiente e quais evidências podem expô-los.

Como vamos provar que nada foi perdido?

Não espere até a recuperação para decidir como validá-la. Antes de reiniciar, defina quais evidências serão necessárias para que as equipes subsequentes sejam informadas de que o sistema está pronto para uso novamente. Dependendo do ambiente, a validação pode envolver:

• Comparação suportada entre origem e destino
• Registros ou chaves comerciais
• Contagens
• Hashes ou somas de verificação, quando apropriado.
• Carimbos de data/hora ou posições de processamento
• Diagnóstico da plataforma de replicação
• Exemplos de transações críticas para os negócios
• Validação a jusante

Nenhum método isolado prova tudo. A questão importante em qualquer verificação de validação é:

O que isso prova — e o que isso não prova?

Perguntar

• Qual o período de recuperação abrangido?
• Quais dados precisam ser verificados?
• Quais verificações abordam os riscos identificados na Pergunta 5?
• Que discrepâncias exigiriam uma investigação mais aprofundada?
• Quem precisa revisar o resultado?
• Que provas devem ser preservadas?

Por que isso importa

O erro que as equipes de recuperação frequentemente cometem é presumir que "A replicação está funcionando novamente" e "O destino pode ser confiável novamente" são a mesma conclusão.

Não são.

Uma delas diz respeito à saúde do sistema. A outra, à integridade dos dados. A recuperação só estará completa quando houver evidências para ambas. Você estará pronto para prosseguir quando a equipe tiver uma abordagem de validação adequada à origem, ao destino, ao incidente e ao risco para o negócio.

Como podemos ter certeza de que a recuperação está realmente completa?

Um pipeline pode estar em execução enquanto ainda há pendências. Pode estar sendo processado enquanto os dados subsequentes permanecem desatualizados. E pode apresentar um estado de processo saudável enquanto questões sobre os dados recuperados permanecem sem resposta. Antes de encerrar o incidente, verifique tanto o processo quanto o resultado.

Verificar

• O atraso está voltando ao intervalo esperado?
• A lista de espera está realmente diminuindo?
• A replicação continua a avançar?
• Ainda estão ocorrendo erros ou novas tentativas?
• Os dados relevantes para o alvo foram validados?
• Os proprietários de imóveis a jusante afetados foram informados sobre o que é seguro usar?
• Ainda existem discrepâncias ou exceções em aberto?
• O estado do incidente foi documentado?
• Entendemos o suficiente sobre o que aconteceu para reagir melhor caso ocorra novamente?

Por que isso importa

Encerrar um incidente prematuramente pode deixar questões não resolvidas sobre dados, validação ou impactos subsequentes, ocultas por trás de um status de processo aparentemente saudável. O incidente deve ser encerrado quando a equipe puder afirmar que a replicação está estável, os dados relevantes foram validados, as equipes subsequentes compreendem o estado atual e podemos explicar o que aconteceu.

Planejamento de recuperação versus validação de recuperação

As sete perguntas deste artigo ajudam a identificar o que poderia ter dado errado e do que depende a recuperação. Elas não comprovam que o alvo recuperado esteja correto. Após a recuperação, o próximo passo é determinar se algum desses riscos realmente ocorreu e se o alvo é confiável.

Recurso relacionado: O pipeline está funcionando novamente. Você pode confiar nos dados?

A decisão que você está realmente tomando.

Estas sete perguntas não são sobre se você pode apertar o botão Reiniciar. Elas são sobre se você consegue responder: Onde podemos retomar? O que aconteceu durante a interrupção? Podemos nos recuperar sem recomeçar do zero? E como vamos provar que nada foi perdido?

Essa é a diferença entre colocar o oleoduto em funcionamento novamente e recuperá-lo para um estado em que você possa confiar.

Lista de verificação para tomada de decisão de recuperação do CDC

Quando um problema de recuperação se torna um problema de plataforma

Todas as plataformas do CDC eventualmente sofrerão falhas, interrupções ou eventos de recuperação.

A questão não é se os incidentes acontecem. A questão é o esforço, a incerteza e o risco envolvidos quando eles acontecem.

Um incidente negativo isolado não significa automaticamente que você precise de uma plataforma diferente do CDC. Mas a dor recorrente da recuperação exige uma conversa diferente.

Pergunte se você está vendo repetidamente:

• Um acúmulo crescente na fonte
• Recarregamentos completos ou resincronizações abrangentes, pois nenhum outro caminho de recuperação é confiável.
• Recuperação que depende de uma ou duas pessoas conhecerem os passos corretos
• Horas gastas tentando descobrir se o problema está na origem, na camada de replicação ou no destino.
• Validação manual ou inconsistente da origem ao destino
• Incerteza sobre se alterações ou exclusões foram omitidas.
• Visibilidade deficiente do estado do oleoduto ou da recuperação.
• Impacto do sistema de origem durante o processamento normal ou de recuperação
• Questões recorrentes a jusante questionam a confiabilidade dos dados.

Para ambientes mainframe onde Db2 para z/OS, VSAM, IMS ou ADABAS são sistemas de registro, o comportamento de recuperação deve ser avaliado para a fonte específica — e não presumido a partir de uma alegação genérica de "suporte a mainframe".

Nesse ponto, a pergunta muda de "Como resolvemos esse incidente?" para "Nossa abordagem atual de replicação está nos dando a capacidade de recuperação e a visibilidade de que realmente precisamos?"

Onde o Rocket Data Replicate & Sync se encaixa

A recuperação é uma das capacidades mais importantes a serem avaliadas em qualquer plataforma do CDC.

O Rocket Data Replicate & Sync (RDRS) gerencia a replicação corporativa entre ambientes mainframe e plataformas modernas distribuídas e em nuvem.

Se você estiver avaliando o RDRS para um ambiente como o descrito acima, aplique o mesmo padrão que aplicaria a qualquer plataforma de replicação.

As sete perguntas deste artigo: o que falhou, onde podemos retomar, o que aconteceu durante a interrupção, qual caminho de recuperação se aplica, o que pode estar errado, como vamos provar isso e como saberemos que terminamos, são as mesmas perguntas que devem ser respondidas sobre qualquer plataforma, incluindo o RDRS, antes de confiar em um alvo recuperado.

Solicite uma demonstração de como a recuperação funciona na sua configuração específica de origem e destino:

• Onde o processamento pode ser retomado após uma interrupção.
• O que acontece com as mudanças que se acumulam durante o intervalo?
• O que os operadores podem observar durante o processo de recuperação e retomada.
• Quais são as opções disponíveis quando uma reinicialização normal não é suficiente?
• Quais são as capacidades de comparação ou validação entre origem e destino disponíveis?
• O que acontece com o impacto no sistema de origem durante a operação normal e a recuperação?
• Que evidências a equipe pode usar antes de informar aos usuários subsequentes que os dados estão prontos novamente?

A possibilidade de recuperar uma falha específica sem uma resincronização mais ampla ou uma reinicialização completa depende da origem, do destino, da topologia, do histórico retido, da configuração e da natureza da falha.

A pergunta mais útil não é: "A plataforma suporta recuperação?"

É o seguinte: "Mostre-nos como a recuperação funciona nos cenários de falha que nosso ambiente realmente enfrenta."

*NIST SP 800-61 Rev. 3: Recomendações e Considerações para Resposta a Incidentes

A seguir: Comprovar a recuperação

Retomar a replicação é apenas parte do trabalho. A próxima questão é:

Como podemos provar que os dados recuperados estão completos?

Aprenda como definir a janela de recuperação, determinar quais evidências estão disponíveis, investigar discrepâncias e estabelecer quando o alvo está pronto para uso posterior.