Recuperar uma transmissão

É possível recuperar um stream com falha permanente sem precisar criar um novo. Para isso, especifique a posição em que o Datastream tenta retomar a leitura das mudanças na origem.

Visão geral da recuperação de stream

Um stream em execução pode encontrar alguns erros irrecuperáveis e mudar o estado para FAILED_PERMANENTLY. Esses erros impedem que o stream continue sendo executado e podem causar perda de dados.

É possível recuperar um stream com falha permanente definindo-o para ignorar o erro e continuar lendo os eventos em andamento, em vez de recriar o stream e preencher os dados históricos. Para recuperar um stream que falhou permanentemente, redefina a replicação para começar a ler de uma posição de replicação diferente. Cada tipo de origem compatível tem sua própria definição de posição de replicação:

  • Para fontes do Oracle, uma posição de replicação é um arquivo de redo log no banco de dados e o número de alteração do sistema (SCN) nesse arquivo.
  • Para fontes do MySQL, uma posição de replicação é o arquivo de registro binário (binlog) do banco de dados e a posição nesse arquivo (para replicação baseada em binlog) ou um conjunto de identificadores de transação global chamado conjunto de GTID (para replicação baseada em GTID, compatível apenas com a API Datastream).
  • Para fontes do SQL Server, uma posição de replicação é o número de sequência do registro (LSN) nos registros de transação ou nas tabelas de alterações.
  • Para fontes do PostgreSQL (incluindo o AlloyDB para PostgreSQL), uma posição de replicação é o número de sequência de registros (LSN) no slot de replicação. Durante a recuperação, o stream começa a ler do primeiro LSN no slot de replicação.
  • Para fontes do MongoDB, uma posição de replicação é um carimbo de data/hora no registro de operações (oplog) do MongoDB.

Recuperar um stream para uma origem MySQL ou Oracle

Para recuperar um fluxo de uma origem MySQL (replicação baseada em binlog) ou Oracle, você tem as seguintes opções:

  • Tentar novamente na posição atual (recomendado): selecione essa opção para tentar fazer streaming na posição atual, onde o stream falhou pela última vez. Primeiro, corrija ou recupere o arquivo de log do backup. Essa é a opção recomendada.

  • Pular a posição atual e fazer streaming na próxima posição disponível: se um ou mais arquivos de registro estiverem ausentes, selecione essa opção para ignorá-los e retomar o streaming na primeira posição no arquivo seguinte disponível. As mudanças nos arquivos de registro ausentes são perdidas, mas podem ser recuperadas com a execução de um preenchimento.

  • Pular a posição atual e fazer o streaming na posição mais recente: se um ou mais arquivos de registro estiverem ausentes, selecione essa opção para ignorá-los e retomar o streaming na posição mais recente no arquivo de registro mais atualizado. As mudanças nos arquivos de registro ausentes são perdidas, mas podem ser recuperadas com a execução de um preenchimento.

  • Retomar na posição e no arquivo de streaming de sua preferência: selecione esta opção para retomar o stream em um arquivo de registro e em uma posição de registro específicos. Algumas mudanças podem ser perdidas se a posição do registro especificada não se sobrepuser ou não seguir imediatamente a posição perdida. É possível recuperar essas mudanças com um preenchimento.

Para recuperar um fluxo com falha permanente de uma origem MySQL ou Oracle, siga estas etapas:

  1. Acesse a página Streams em Google Cloud.

    Acessar a página "Mural"

  2. Clique em Recuperar na linha com o nome do stream que você quer recuperar.

  3. O painel Escolher uma estratégia de recuperação é aberto. Selecione uma opção. Se você selecionar Retomar na posição e no arquivo de streaming de sua preferência, insira o seguinte:

    • Para uma origem MySQL: o nome do arquivo de registro no campo Nome do arquivo e a posição do registro no campo Posição. Se você não especificar a posição, o stream será retomado da primeira posição no arquivo de registro indicado.
    • Para uma origem do Oracle: o número de alteração do sistema (SCN) no campo Número de alteração do sistema (SCN). Este campo é obrigatório.

  4. Clique em Aplicar.

  5. Quando a transmissão é recuperada, um carimbo de data/hora aparece na coluna Recuperada da página Transmissões.

Recuperar um fluxo para uma origem do PostgreSQL

Para recuperar um stream de uma origem do PostgreSQL, você precisa fornecer o nome do slot de replicação. O servidor usa esse slot de replicação para enviar eventos ao Datastream. O nome do slot de replicação pode ser o mesmo do slot usado para o fluxo com falha ou diferente:

  • Se o novo slot de replicação tiver um nome diferente, forneça o novo nome ao Datastream.

  • Se você não fornecer um nome de slot de replicação, o Datastream vai usar o nome especificado na configuração de origem.

    Para mais informações sobre slots de replicação, consulte Configurar um banco de dados PostgreSQL de origem.

Todos os eventos de alteração na origem que ocorreram entre a perda de posição do registro e o primeiro LSN no novo slot de replicação são perdidos. Você pode recuperar essas mudanças com um preenchimento.

Para recuperar um fluxo com falha permanente de uma origem do PostgreSQL, siga estas etapas:

  1. Acesse a página Streams em Google Cloud.

    Acessar a página "Mural"

  2. Clique em Recuperar na linha com o nome do stream que você quer recuperar.

  3. O painel Definir um novo slot de replicação é aberto.

  4. No campo Nome do slot de replicação, forneça o nome de um novo slot de replicação do qual o stream vai tentar se recuperar. Se você recriou o slot de replicação usando o mesmo nome ou quer reutilizar o slot especificado ao configurar a origem, deixe esse campo em branco.

  5. Clique em Aplicar.

  6. Quando a transmissão é recuperada, um carimbo de data/hora aparece na coluna Recuperada da página Transmissões.

Também é possível recuperar streams que falharam permanentemente na página Detalhes do stream. Para fazer isso, clique em Recuperar stream ao visualizar informações detalhadas sobre seu stream.

Recuperar um fluxo de uma fonte do SQL Server

Para recuperar um fluxo de uma origem do SQL Server, você tem as seguintes opções:

  • Retomar da primeira posição disponível: selecione essa opção se o registro foi truncado ou se há registros faltando nas tabelas de alteração e você quer retomar do primeiro evento disponível. Os eventos ausentes são perdidos, mas podem ser recuperados com um preenchimento.

  • Retomar do seu número de sequência de registro (LSN, na sigla em inglês) preferido: selecione esta opção para retomar o fluxo de um LSN específico nos registros de transação ou nas tabelas de alterações. Alguns eventos podem ser perdidos se o LSN especificado não se sobrepuser ou não seguir imediatamente o último LSN que o Datastream conseguiu recuperar. É possível recuperar esses eventos com um preenchimento.

    O LSN nos registros de transações e nas tabelas de mudanças contém 20 caracteres hexadecimais, mas, nos registros de transações, ele é separado por um delimitador. Exemplo:

    • LSN nos registros de transações: 0000123C:0000BA78:0004
    • LSN nas tabelas de mudança: 0000123C0000BA780004

Para recuperar um fluxo com falha permanente de uma origem do SQL Server, siga estas etapas:

  1. Acesse a página Streams em Google Cloud.

    Acessar a página "Mural"

  2. Clique em Recuperar na linha com o nome do stream que você quer recuperar.

  3. O painel Escolher uma estratégia de recuperação é aberto. Selecione uma opção.

  4. Clique em Aplicar.

  5. Quando a transmissão é recuperada, um carimbo de data/hora aparece na coluna Recuperada da página Transmissões.

Recuperar um fluxo para uma origem do MongoDB

A recuperação de stream para fontes do MongoDB está disponível usando a API do Datastream. É possível recuperar um fluxo do MongoDB usando as seguintes opções:

  • Posição de início mais recente: selecione essa opção se quiser retomar seu fluxo de dados do carimbo de data/hora atual no oplog do MongoDB. Os eventos ausentes são perdidos, mas podem ser recuperados com um preenchimento.

  • Posição inicial específica: selecione essa opção para retomar o stream de um carimbo de data/hora selecionado. O carimbo de data/hora usado na solicitação precisa ser válido. Isso significa que ele não pode ser anterior à primeira posição disponível no oplog do MongoDB nem estar no futuro.

Para informações sobre como criar uma solicitação para recuperar um fluxo do MongoDB, consulte a documentação de referência da API Datastream .

Para informações sobre o registro de operações do MongoDB, consulte a documentação do MongoDB.

Usar a recuperação de stream para uma origem do MySQL em um cenário de failover manual

É possível fazer um failover manual e usar a recuperação de stream para evitar a recriação dos streams do zero durante a manutenção ou falha da instância principal. Em geral, o Datastream não oferece suporte a failovers para réplicas porque eles interrompem a continuidade do binlog. No entanto, siga estas etapas para recuperar o stream e garantir que os dados de mudança sejam capturados:

  1. Interrompa todas as gravações na instância principal.
  2. Verifique se a métrica de atualização de dados está definida como 0. Isso significa que o Datastream capturou todas as mudanças e não há novos eventos para ler na origem. Para mais informações, consulte Monitorar um fluxo.
  3. Faça failover para a nova instância de banco de dados.
  4. Se necessário, atualize o perfil de conexão do fluxo para a nova instância de banco de dados. Por exemplo, talvez seja necessário mudar o nome do host ou o endereço IP do banco de dados. Para mais informações, consulte Modificar perfis de conexão.
  5. Recupere o fluxo de uma posição específica na instância de failover para garantir a continuidade da CDC.

A seguir