Recuperar uma transmissão

É possível recuperar uma transmissão que falhou permanentemente sem precisar criar uma nova. Para isso, especifique a posição a partir da qual o Datastream tenta para retomar a leitura das alterações na origem.

Visão geral da recuperação de stream

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

Para recuperar uma transmissão com falha permanente, configure-a para ignorar o erro e continue lendo os eventos em andamento em vez de recriar o stream e preencher os dados históricos. Para recuperar um fluxo com falha permanente, redefina a replicação para começar a leitura em uma posição diferente. Cada um tipo de origem tem sua própria definição do que é uma posição de replicação:

  • Para origens do Oracle, uma posição de replicação é um arquivo de registro redo no banco de dados e o número de alteração do sistema (SCN) nesse arquivo.
  • Para origens 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 origens do SQL Server, uma posição de replicação é o número de sequência do registro. (LSN) nos registros de transações ou nas tabelas de alterações.
  • Para fontes PostgreSQL (incluindo AlloyDB para PostgreSQL), uma posição de replicação é o número de sequência de registro (LSN, na sigla em inglês) no slot de replicação. Durante a recuperação, o stream começa a ler a partir do primeiro LSN no slot de replicação.

Recuperar um stream de uma origem MySQL ou Oracle

Para recuperar um fluxo de uma origem MySQL 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 streaming falhou pela última vez. Primeiro, você precisa corrigir o arquivo de registro ou recuperá-lo 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 dos arquivos de registro ausentes são perdidas, mas podem ser recuperadas com a execução de um preenchimento.

  • Pular a posição atual e transmitir da posição mais recente: se um ou mais arquivos de registro estiverem faltando, selecione esta opção para ignorar esses arquivos e retomar o streaming da posição mais recente no arquivo de registro mais atualizado. As mudanças dos 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 essa opção. para retomar o stream em um arquivo e em uma posição de registro específicos. Algumas mudanças podem serão perdidas se a posição do registro especificada não se sobrepuser ou não se sobrepor seguir a posição de registro perdida. É possível recuperar essas alterações realizando um preenchimento.

Para recuperar um stream com falha permanente para uma fonte MySQL ou Oracle, execute as seguintes etapas:

  1. Acesse a página Streams no 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 Escolha uma estratégia de recuperação será aberto. Selecione uma opção. Se você selecionar Retomar na posição e no arquivo de streaming de sua preferência, digite o seguinte:

    • Para uma origem do MySQL: o nome do arquivo do 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 fluxo será retomado na primeira posição do 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 Recuperado na página Transmissões.

Recuperar um stream de uma origem do PostgreSQL

Para recuperar um stream de uma origem PostgreSQL, você precisa fornecer a replicação nome do slot. 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 stream com falha ou diferente:

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

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

    Para mais informações sobre slots de replicação, consulte Configure 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 serão perdidos. É possível recuperar essas mudanças fazendo um preenchimento.

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

  1. Acesse a página Streams no 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, insira o nome de uma nova replicação do qual o stream tentará se recuperar. Se você tiver recriado a replicação com o mesmo nome ou reutilizar o especificado ao configurou sua origem, deixe este campo em branco.

  5. Clique em Aplicar.

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

Também é possível recuperar transmissões permanentemente com falha na página Detalhes do stream. Para fazer isso, clique em Recuperar transmissão ao conferir informações detalhadas sobre a transmissão.

Recuperar uma transmissão de uma origem do SQL Server

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

  • Retomar na primeira posição disponível: selecione esta opção se o registro tiver sido truncado ou com alguns registros faltando nas tabelas de alterações e quiser retomar desde o primeiro evento disponível. Os eventos ausentes são perdidos, mas você pode recuperá-los realizando um preenchimento.

  • Retomar do seu número de sequência de registro (LSN) 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 seguir imediatamente o último LSN que o Datastream conseguiu recuperar. É possível recuperar esses eventos realizando um preenchimento.

    O LSN nos registros de transação e nas tabelas de mudança contém 20 caracteres hexadecimais, mas, para registros de transação, ele é separado por um delimitador. Exemplo:

    • LSN nos registros de transações: 0000123C:0000BA78:0004
    • LSN nas tabelas de alteração: 0000123C0000BA780004

Para recuperar uma transmissão com falha permanente de uma origem do SQL Server, siga estas etapas:

  1. Acesse a página Streams no 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 Recuperado na página Transmissões.

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

É possível realizar um failover manual e usar a recuperação de fluxo para evitar a recriação dos fluxos do zero durante a manutenção ou falha da instância principal. Geralmente, o Datastream não aceita failovers para réplicas porque eles quebram a continuidade do binlog, mas você pode seguir estas etapas para recuperar os e garantir que seus 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 da origem. Para mais informações, consulte Monitorar uma transmissão.
  3. Falha na nova instância do banco de dados.
  4. Se necessário, atualize o perfil de conexão do stream para a nova instância do banco de dados Por exemplo, talvez seja necessário alterar 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 stream de uma posição específica na instância de failover para garantir a continuidade da CDC.

A seguir