Replicação de histórico de carregamento, canal e estágio

Este tópico fornece informações sobre o suporte à replicação para objetos de pipeline de dados e metadados relacionados, incluindo estágios, integrações de armazenamento, canais e histórico de carregamento. Você pode replicar esses objetos para configurar o failover para ingestão e pipelines ETL em regiões e em plataformas de nuvem.

Antes de começar, recomendamos que você esteja familiarizado com o suporte Snowflake para replicação e failover/failback. Para obter mais informações, consulte Introdução à replicação e failover em várias contas.

Requisitos

Importante

Se um banco de dados em uma conta de destino que você planeja usar contiver estágios e canais, recomendamos que você entre em contato com o suporte antes de ativar a replicação. Quando um grupo de replicação ou failover na sua conta de origem inclui esse banco de dados, todos os estágios e canais pré-existentes são eliminados do banco de dados.

Antes de replicar objetos de pipeline de dados, você deve ativar a replicação ETL. O suporte para replicação ETL faz parte do pacote 2024_02 BCR. Você pode ativar o pacote 2024_02 BCR executando a seguinte instrução:

SELECT SYSTEM$ENABLE_BEHAVIOR_CHANGE_BUNDLE('2024_02');
Copy

Nota

A replicação ETL fazia parte do pacote 2024_01, mas foi movida para o pacote 2024_02.

Para replicar quaisquer estágios externos que usam uma integração de armazenamento, você também deve configurar seu grupo de replicação ou failover para replicar STORAGE INTEGRATIONS. Caso contrário, os estágios externos serão replicados sem a integração de armazenamento associada.

Você pode usar uma instrução ALTER REPLICATION GROUP ou ALTER FAILOVER GROUP para modificar essas propriedades de um grupo existente.

Se você adicionar INTEGRATIONS à lista OBJECT_TYPES em sua instrução ALTER, inclua quaisquer outros objetos existentes na lista para evitar descartar esses objetos na conta de destino. O mesmo se aplica se você adicionar STORAGE INTEGRATIONS à lista ALLOWED_INTEGRATION_TYPES.

Por exemplo:

ALTER FAILOVER GROUP my_failover_group SET
  OBJECT_TYPES = ROLES, INTEGRATIONS
  ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS, STORAGE INTEGRATIONS;
Copy

Nota

Seu provedor de armazenamento em nuvem pode limitar a replicação de objetos de pipeline de dados entre regiões de nuvem comerciais e governamentais. Para evitar limitações de replicação de dados na nuvem governamental, configure os seus recursos de failover em qualquer região acessível à sua região de nuvem governamental. Para obter mais informações sobre as limitações da nuvem governamental, consulte a documentação do seu provedor de armazenamento em nuvem.

Replicação e estágios

Esta seção descreve o nível atual de funcionalidade de replicação compatível com o Snowflake para diferentes tipos de estágios.

Replicação de estágios internos

A tabela a seguir descreve como funciona a replicação para cada tipo de estágio interno.

Tipo

Descrição do suporte de replicação

Estágio da tabela

Os estágios de tabela vazia são criados para tabelas em um banco de dados replicado. Os arquivos nos estágios da tabela não são replicados.

Estágio do usuário

A replicação do usuário e do estágio do usuário requer Business Critical Edition (ou superior).

Estágios de usuário vazios são criados para usuários replicados. Os arquivos nos estágios do usuário não são replicados.

Estágio nomeado

Os estágios internos nomeados são replicados quando você replica um banco de dados.

O estágio deve ter uma tabela de diretórios habilitada para replicar os arquivos no estágio.

Replicação de estágios externos

Nota

Snowflake não replica arquivos em um estágio externo. O URL do armazenamento em nuvem aponta para o mesmo local para estágios externos em bancos de dados primários e secundários.

A tabela a seguir descreve como funciona a replicação para cada tipo de estágio externo.

Tipo

Descrição do suporte de replicação

Estágio nomeado sem credenciais (local de armazenamento público)

Os estágios externos nomeados são replicados quando você replica um banco de dados. Os arquivos em um estágio externo não são replicados.

Estágio nomeado com credenciais (local de armazenamento privado)

Os estágios replicados incluem as credenciais do provedor de nuvem, como chaves secretas ou tokens de acesso.

Estágio nomeado com integração de armazenamento (local de armazenamento privado)

A replicação de integração de armazenamento exige Business Critical Edition (ou superior).

O grupo de replicação ou failover deve incluir STORAGE INTEGRATIONS na lista ALLOWED_INTEGRATION_TYPES. Para obter mais informações, consulte CREATE FAILOVER GROUP.

Você também deve tomar medidas para configurar as relações de confiança para seu armazenamento em nuvem nas contas de destino. Para obter mais informações, consulte Configuração do acesso ao armazenamento em nuvem para integrações de armazenamento secundárias.

Nota

Para associar um estágio ou canal secundário a um local de armazenamento em nuvem diferente daquele associado ao objeto primário, entre em contato com a equipe de suporte. Por exemplo, você pode escolher um local em outra região.

Considerações

As seguintes restrições se aplicam a objetos de preparação:

  • Atualmente, o Snowflake oferece suporte à replicação de estágio como parte da replicação baseada em grupo (grupos de replicação e failover). A replicação de estágio não é suportada para replicação de banco de dados.

  • Você pode replicar um estágio externo. Entretanto, os arquivos em um estágio externo não são replicados.

  • Você pode replicar um estágio interno. Para replicar os arquivos em um estágio interno, você deve ativar uma tabela de diretórios no estágio. O Snowflake replica apenas os arquivos mapeados pela tabela de diretórios.

  • Ao replicar um estágio interno com uma tabela de diretórios, não é possível desativar a tabela de diretórios no estágio primário ou secundário. A tabela de diretórios contém informações críticas sobre arquivos replicados e arquivos carregados usando uma instrução COPY.

  • Uma operação de atualização falhará se a tabela de diretórios em um estágio interno contiver um arquivo maior que 5GB. Para contornar essa limitação, mova todos os arquivos maiores que 5GB para um estágio diferente.

    Não é possível desativar a tabela de diretórios em um estágio primário ou secundário ou em qualquer estágio que tenha sido replicado anteriormente. Siga estas etapas antes de adicionar o banco de dados que contém o estágio a um grupo de replicação ou failover.

    1. Desative a tabela de diretórios no estágio primário.

    2. Mova os arquivos maiores que 5GB para outro estágio que não tenha uma tabela de diretórios ativada.

    3. Depois de mover os arquivos para outro estágio, reative a tabela de diretórios no estágio primário.

  • Os arquivos nos estágios de usuário e de tabela não são replicados.

  • Para estágios externos nomeados que usam uma integração de armazenamento, você deve configurar a relação de confiança para integrações de armazenamento secundário em suas contas de destino antes do failover. Para obter mais informações, consulte Configuração do acesso ao armazenamento em nuvem para integrações de armazenamento secundárias.

  • Se você replicar um estágio externo com uma tabela de diretórios e tiver configurado a atualização automática para a tabela de diretórios de origem, deverá configurar a atualização automática para a tabela de diretórios secundária antes do failover. Para obter mais informações, consulte Configuração de atualização automatizada para tabelas de diretório em estágios secundários.

  • Um comando de cópia poderá demorar mais que o esperado se a tabela de diretórios em um estágio replicado não for consistente com os arquivos replicados no estágio. Para tornar uma tabela de diretórios consistente, atualize-a com uma instrução ALTER STAGE … REFRESH. Para verificar o status de consistência de uma tabela de diretórios, use a função SYSTEM$GET_DIRECTORY_TABLE_STATUS.

Replicação e canais

Esta seção descreve o nível atual de funcionalidade de replicação com suporte para diferentes tipos de canais.

Snowflake oferece suporte à replicação para o seguinte:

  • Objetos de canal, incluindo ingestão automática e canais do ponto de extremidade REST que carregam dados de estágios externos.

  • Parâmetros de nível de canal.

  • Concessões de privilégios em objetos de canal.

Nota

Para associar um estágio ou canal secundário a um local de armazenamento em nuvem diferente daquele associado ao objeto primário, entre em contato com a equipe de suporte. Por exemplo, você pode escolher um local em outra região.

Canais em bancos de dados secundários

Os canais em um banco de dados secundário estão em um estado de execução READ_ONLY e recebem notificações, mas não carregam dados até que você promova o banco de dados secundário a primário. Depois de promover um banco de dados secundário, os canais farão a transição para um estado de execução FAILING_OVER. Depois que o failover for concluído, os canais deverão estar em um estado de execução RUNNING e começam a carregar todos os dados que estão disponíveis desde a última atualização (ou seja, a última vez que o antigo banco de dados primário foi atualizado).

Replicação de canais de ingestão automática

No caso de um failover, um canal de ingestão automática replicado se torna o novo canal primário e pode fazer o seguinte:

  • Carregar todos os dados que ainda não foram carregados. Isso inclui quaisquer dados novos desde a última atualização do banco de dados primário recém-promovido.

  • Continuar recebendo notificações quando o estágio tiver novos arquivos para carregar e carregar dados desses arquivos.

    Nota

    Para receber notificações, você deve configurar um canal secundário de ingestão automática em uma conta de destino antes do failover. Para obter mais informações, consulte Configuração de notificações para canais de ingestão automática secundária.

Replicação de canais de ponto de extremidade REST

Para canais que usam o Snowpipe REST API para carregar dados, o Snowflake replica os canais e seus metadados de histórico de carregamento para cada conta de destino especificada. Não há etapas de configuração adicionais que você precise realizar nas contas de destino. Para obter uma lista detalhada de metadados do histórico de carregamento, consulte Metadados de carregamento.

Para continuar o carregamento de dados no caso de um failover, chame REST API da conta de origem recém-promovida.

Considerações

As seguintes restrições se aplicam a objetos de canal:

  • Atualmente, o Snowflake oferece suporte à replicação de canal como parte da replicação baseada em grupo (grupos de replicação e failover). A replicação de canal não é suportada para replicação de banco de dados.

  • O Snowflake replica o histórico de cópias de um canal somente quando o canal pertence ao mesmo grupo de replicação que sua tabela de destino.

  • A replicação de integrações de notificação não é suportada.

  • O Snowflake apenas replica o histórico de carregamento após o último truncamento da tabela.

  • Para receber notificações, você deve configurar um canal secundário de ingestão automática em uma conta de destino antes do failover. Para obter mais informações, consulte Configuração de notificações para canais de ingestão automática secundária.

  • Use a função SYSTEM$PIPE_STATUS para resolver quaisquer canais que não estejam no estado de execução esperado após o failover.

Exemplo 1: replicar um estágio interno nomeado

Este exemplo demonstra como funciona a replicação para estágios internos. Em especial, o exemplo mostra como a tabela de diretórios é a única fonte de verdade para os metadados do estágio antes e depois da replicação.

A primeira parte do exemplo conclui as tarefas a seguir em uma conta de origem.

  1. Crie um estágio interno chamado my_int_stage com uma tabela de diretórios habilitada para replicar os arquivos no estágio. Em seguida, copie os dados de uma tabela chamada my_table para os arquivos do estágio.

    Nota

    O exemplo atualiza a tabela de diretórios após carregar file1 e file2 no estágio para sincronizar os metadados da tabela com o conjunto mais recente de arquivos na definição do estágio para as tabelas de diretórios. No entanto, nenhuma operação de atualização ocorre após o carregamento de file3.

    CREATE OR REPLACE STAGE my_stage
      DIRECTORY = (ENABLE = TRUE);
    
    COPY INTO @my_stage/folder1/file1 from my_table;
    COPY INTO @my_stage/folder2/file2 from my_table;
    ALTER STAGE my_stage REFRESH;
    
    COPY INTO @my_stage/folder3/file3 from my_table;
    
    Copy
  2. Criação de um grupo de failover:

    CREATE FAILOVER GROUP my_stage_failover_group
      OBJECT_TYPES = DATABASES
      ALLOWED_DATABASES = my_database_1
      ALLOWED_ACCOUNTS = myorg.my_account_2;
    
    Copy

A segunda parte do exemplo conclui o processo de replicação e failover em uma conta de destino:

  1. Crie um grupo de failover como uma réplica do grupo de failover na conta de origem, atualize os objetos no novo grupo de failover e promova a conta de destino para servir como conta de origem.

    CREATE FAILOVER GROUP my_stage_failover_group
      AS REPLICA OF myorg.my_account_1.my_stage_failover_group;
    
    ALTER FAILOVER GROUP my_stage_failover_group REFRESH;
    
    ALTER FAILOVER GROUP my_stage_failover_group PRIMARY;
    
    Copy
  2. Em seguida, atualize a tabela de diretórios no estágio replicado e copie todos os arquivos rastreados pela tabela de diretórios em my_stage para uma tabela chamada my_table.

    Nota

    A instrução COPY INTO carrega file1 e file2 na tabela, mas não file3. Isso ocorre porque a tabela de diretórios não foi atualizada após adicionar file3 na conta de origem.

    ALTER STAGE my_stage REFRESH;
    
    COPY INTO my_table FROM @my_stage;
    
    Copy

Exemplo 2: replicar um estágio externo e integração de armazenamento

Este exemplo fornece um fluxo de trabalho de amostra para replicar um estágio externo e integração de armazenamento para uma conta de destino.

O exemplo pressupõe que você já tenha concluído o seguinte: Configuração do acesso seguro ao seu bucket Amazon S3.

A primeira parte do exemplo conclui as tarefas a seguir em uma conta de origem.

  1. Crie uma integração de armazenamento para um bucket Amazon S3 no banco de dados my_database_2.

    CREATE STORAGE INTEGRATION my_storage_int
      TYPE = external_stage
      STORAGE_PROVIDER = 's3'
      STORAGE_ALLOWED_LOCATIONS = ('s3://mybucket/path')
      STORAGE_BLOCKED_LOCATIONS = ('s3://mybucket/blockedpath')
      ENABLED = true;
    
    Copy
  2. Crie um estágio externo no banco de dados my_database_2 usando a integração de armazenamento my_storage_int.

    CREATE STAGE my_ext_stage
      URL = 's3://mybucket/path'
      STORAGE_INTEGRATION = my_storage_int
    
    Copy
  3. Crie um grupo de failover e inclua o banco de dados my_database_2 e objetos de integração de armazenamento.

    CREATE FAILOVER GROUP my_external_stage_fg
      OBJECT_TYPES = databases, integrations
      ALLOWED_INTEGRATION_TYPES = storage integrations
      ALLOWED_DATABASES = my_database_2
      ALLOWED_ACCOUNTS = myorg.my_account_2;
    
    Copy

A segunda parte do exemplo conclui o processo de replicação e failover em uma conta de destino:

  1. Crie um grupo de failover como uma réplica do grupo de failover na conta de origem e atualize.

    CREATE FAILOVER GROUP my_external_stage_fg
      AS REPLICA OF myorg.my_account_1.my_external_stage_fg;
    
    ALTER FAILOVER GROUP my_external_stage_fg REFRESH;
    
    Copy
  2. Depois de replicar a integração de armazenamento para a conta de destino, você deverá executar etapas adicionais para atualizar as permissões do seu provedor de nuvem para conceder acesso ao seu armazenamento em nuvem à integração de replicação. Para obter mais informações, consulte Configuração do acesso ao armazenamento em nuvem para integrações de armazenamento secundárias.

Exemplo 3: replicar um canal de ingestão automática

Este exemplo fornece um fluxo de trabalho de amostra para replicar um canal que usa um tópico do Amazon Simple Notification Service (SNS) com o Amazon Simple Queue Service (SQS) para automatizar o Snowpipe.

O exemplo pressupõe que você já tenha concluído as seguintes tarefas:

Comece com as tarefas a seguir em uma conta de origem.

  1. Use o comando CREATE PIPE para criar um canal com ingestão automática habilitada que carregue dados do estágio externo em uma tabela chamada mytable.

    CREATE PIPE snowpipe_db.public.mypipe AUTO_INGEST=TRUE
     AWS_SNS_TOPIC='<topic_arn>'
     AS
       COPY INTO snowpipe_db.public.mytable
       FROM @snowpipe_db.public.my_s3_stage
       FILE_FORMAT = (TYPE = 'JSON');
    
    Copy
  2. Atualize o canal com uma instrução ALTER PIPE para carregar dados do estágio dos últimos 7 dias.

    ALTER PIPE mypipe REFRESH;
    
    Copy
  3. Por fim, use CREATE FAILOVER GROUP para criar um grupo de failover que permita a replicação de integrações de armazenamento.

    CREATE FAILOVER GROUP my_pipe_failover_group
      OBJECT_TYPES = DATABASES, INTEGRATIONS
      ALLOWED_INTEGRATION_TYPES = STORAGE INTEGRATIONS
      ALLOWED_DATABASES = snowpipe_db
      ALLOWED_ACCOUNTS = myorg.my_account_2;
    
    Copy

A segunda parte do exemplo conclui o processo de replicação e failover em uma conta de destino:

  1. Crie um grupo de failover como uma réplica do grupo de failover na conta de origem:

    CREATE FAILOVER GROUP my_pipe_failover_group
      AS REPLICA OF myorg.my_account_1.my_pipe_failover_group;
    
    Copy
  2. Execute uma instrução DESCRIBE INTEGRATION para recuperar o ARN do usuário AWS IAM da sua conta Snowflake na implantação secundária.

    Use ARN para conceder ao usuário IAM permissões para acessar seu bucket S3. Consulte a Etapa 5: conceder ao usuário IAM permissões de usuário para acessar objetos de bucket.

    DESC INTEGRATION my_s3_storage_int;
    
    Copy
  3. Chame a função do sistema SYSTEM$GET_AWS_SNS_IAM_POLICY para gerar uma política IAM que conceda à nova fila SQS permissão para assinar seu tópico SNS. O Snowflake criou a nova fila SQS na sua conta de destino quando você replicou o grupo de failover da sua conta de origem.

    SELECT SYSTEM$GET_AWS_SNS_IAM_POLICY('<topic_arn>');
    
    Copy

    topic_arn é o Amazon Resource Name (ARN) do tópico SNS que você criou para o canal original na sua conta de origem.

    Em seguida, Inscreva-se na nova fila da Amazon SQS em seu tópico SNS.

  4. Atualize os objetos no seu novo grupo de failover.

    ALTER FAILOVER GROUP my_pipe_failover_group REFRESH;
    
    Copy
  5. Por fim, promova a conta de destino para servir como conta de origem com o comando ALTER FAILOVER GROUP.

    ALTER FAILOVER GROUP my_pipe_failover_group PRIMARY;
    
    Copy

    O canal mypipe começará a carregar todos os dados disponibilizados desde a última vez que o grupo de failover foi atualizado na conta de origem.

    Para verificar se o canal replicado está funcionando, consulte a tabela da instrução COPY do canal.

    SELECT * FROM mytable;
    
    Copy

Migração para Amazon Simple Notification Service (SNS)

Esta seção aborda como migrar do envio de notificações de eventos do Amazon S3 diretamente para uma fila do Amazon Simple Queue Service (SQS) para o uso de um tópico do Amazon Simple Notification Service (SNS) para os seguintes cenários:

Quando você replica uma tabela de diretório ou canal, o Snowflake cria uma nova fila do SQS na sua conta de destino para lidar com a automação. Você pode configurar um único tópico do SNS para entregar notificações de eventos do seu bucket S3 para todas as filas do SQS em várias contas. Ao transmitir sua(s) notificação(ões) de eventos S3 para cada fila do SQS, você reduz o risco de perder notificações e dados após o failover.

Nota

Se você já usar o SNS, a migração não é necessária. Em vez disso, siga as etapas normais para configurar a automação com SNS para tabelas de diretórios secundários ou canais de ingestão automática antes do failover.

Pré-requisitos

Para migrar, você deve atender às seguintes condições:

Migração para um tópico do SNS

  1. Crie um tópico do SNS em sua conta AWS. Para instruções, consulte o tópico Criação de um tópico do Amazon SNS na documentação do AWS SNS.

  2. Inscreva seus destinos alvo (por exemplo, outras filas de SQS ou cargas de trabalho Lambda do AWS) para sua(s) notificação(ões) de evento S3 em seu tópico do SNS. O SNS publica notificações de eventos para seu bucket para todos os assinantes do tópico. Para instruções, consulte a documentação do AWS SNS.

  3. Atualize a política de acesso do seu tópico com as seguintes permissões:

    • Permita que o usuário Snowflake IAM inscreva a fila SQS que está em sua conta de destino para seu tópico.

    • Permita que o Amazon S3 publique notificações de eventos do seu bucket no tópico do SNS.

    Para obter instruções, consulte Etapa 1: Inscreva a fila SQS do Snowflake no tópico do SNS.

  4. Em sua conta Snowflake de destino, chame a função SYSTEM$CONVERT_PIPES_SQS_TO_SNS. A função inscreve a fila de SQS em sua conta de destino no seu tópico SNS sem interromper a sincronização de metadados ou o trabalho de ingestão.

    Especifique o nome do bucket S3 e o ARN do tópico do SNS.

    SELECT SYSTEM$CONVERT_PIPES_SQS_TO_SNS('s3_mybucket', 'arn:aws:sns:us-west-2:001234567890:MySNSTopic')
    
    Copy
  5. Atualize suas notificações de bucket S3 para usar seu tópico do SNS como destino. Para obter instruções, consulte o Guia do usuário do Amazon S3.

Depois de concluir essas etapas, a fila do SQS será automaticamente desvinculada de sua(s) notificação(ões) de evento S3. Todas as tabelas de diretório e canais que usam o bucket S3 especificado começarão a usar o SNS como origem de notificações.