Replicação de bancos de dados e objetos de conta em diversas contas

Este tópico descreve as etapas necessárias para replicar dados e objetos de conta em várias contas Snowflake na mesma organização e manter os objetos e os dados sincronizados. A replicação de contas pode ocorrer em contas Snowflake de diferentes regiões e em plataformas de nuvem.

Nota

Ao atualizar uma conta para Business Critical Edition (ou superior), pode levar até 12 horas até que os recursos de failover fiquem disponíveis.

Neste tópico:

Suporte regional para replicação e failover/failback

Os clientes podem replicar em todas as regiões dentro de um grupo de regiões. Para replicar entre regiões em diferentes Grupos de regiões (por exemplo, de uma região comercial de Snowflake para uma região governamental de Snowflake), entre em contato com o suporte Snowflake para permitir o acesso.

Transição da replicação de banco de dados para a replicação baseada em grupos

Os bancos de dados que foram habilitados para replicação usando ALTER DATABASE devem ter a replicação desabilitada antes de serem adicionados a um grupo de replicação ou failover.

Nota

Execute as instruções SQL nesta seção usando a função ACCOUNTADMIN.

Etapa 1. Desabilitar a replicação para um banco de dados habilitado para replicação

Execute a função SYSTEM$DISABLE_DATABASE_REPLICATION para desativar a replicação de um banco de dados primário, juntamente com bancos de dados secundários ligados a ele, a fim de adicioná-lo a um grupo de replicação ou failover.

Execute a seguinte instrução SQL a partir da conta de origem com o banco de dados primário:

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');
Copy

Etapa 2. Adicionar o banco de dados a um grupo de failover primário e criar um grupo de failover secundário

Uma vez que você tenha desativado com sucesso a replicação para um banco de dados, você pode adicionar o banco de dados primário a um grupo de failover na conta de origem.

Em seguida, crie um grupo de failover secundário na conta de destino. Quando o grupo secundário de failover é atualizado na conta de destino, o banco de dados secundário anterior será automaticamente adicionado como membro do grupo secundário de failover e atualizado com as alterações do banco de dados primário.

Para obter mais detalhes sobre a criação de grupos primários e secundários de failover, consulte Fluxo de trabalho.

Nota

Quando você adiciona um banco de dados previamente replicado a um grupo de replicação ou failover, o Snowflake não replica os dados que já foram replicados para aquele banco de dados. Somente as alterações desde a última atualização são replicadas quando o grupo é atualizado.

Fluxo de trabalho

As seguintes instruções SQL demonstram o fluxo de trabalho para habilitar a replicação de contas e objetos de banco de dados, além de atualizar objetos. Cada etapa é discutida em detalhes abaixo.

Nota

Os exemplos a seguir exigem que a replicação seja habilitada para as contas de origem e destino. Para obter mais detalhes, consulte Pré-requisito: Habilitar a replicação para contas na organização.

Exemplos

Execute as seguintes instruções SQL em seu cliente Snowflake preferido para habilitar a replicação e failover de contas e objetos de banco de dados, além da atualização de objetos.

Executado na conta de origem

  1. Crie uma função e conceda o privilégio CREATE FAILOVER GROUP. Essa etapa é opcional:

    USE ROLE ACCOUNTADMIN;
    
    CREATE ROLE myrole;
    
    GRANT CREATE FAILOVER GROUP ON ACCOUNT
      TO ROLE myrole;
    
    Copy
  2. Crie um grupo de failover na conta de origem e habilite a replicação para contas de destino específicas.

    Nota

    USE ROLE myrole;
    
    CREATE FAILOVER GROUP myfg
      OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES
      ALLOWED_DATABASES = db1, db2
      ALLOWED_ACCOUNTS = myorg.myaccount2, myorg.myaccount3
      REPLICATION_SCHEDULE = '10 MINUTE';
    
    Copy

Executado na conta de destino

  1. Crie uma função na conta de destino e conceda o privilégio CREATE FAILOVER GROUP. Essa etapa é opcional:

    USE ROLE ACCOUNTADMIN;
    
    CREATE ROLE myrole;
    
    GRANT CREATE FAILOVER GROUP ON ACCOUNT
      TO ROLE myrole;
    
    Copy
  2. Crie um grupo de failover na conta de destino como uma réplica do grupo de failover na conta de origem:

    Nota

    Se existirem objetos de conta (por exemplo, usuários ou funções) na conta de destino que não existem na conta de origem, consulte Replicação inicial de usuários e funções antes de criar um grupo secundário.

    USE ROLE myrole;
    
    CREATE FAILOVER GROUP myfg
      AS REPLICA OF myorg.myaccount1.myfg;
    
    Copy
  3. Atualize manualmente o grupo de failover secundário. Esta é uma etapa opcional. Se o grupo de failover primário for criado com um cronograma de replicação, a atualização inicial do grupo de failover secundário será executada automaticamente quando o grupo de failover secundário for criado.

    1. Crie uma função com o privilégio REPLICATE no grupo de failover. Esta etapa é opcional.

      Execute na conta de destino usando uma função com o privilégio OWNERSHIP no grupo de failover:

      GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
      
      Copy
    2. Execute a instrução de atualização usando uma função com o privilégio REPLICATE:

      USE ROLE my_replication_role;
      
      ALTER FAILOVER GROUP myfg REFRESH;
      
      Copy

Replicação de objetos de conta e bancos de dados

As instruções nesta seção explicam como preparar suas contas para replicação, habilitar a replicação de objetos específicos da conta de origem para a conta de destino e sincronizar os objetos na conta de destino.

Importante

As contas de destino não têm Tri-Secret Secure ou conectividade privada ao serviço Snowflake (por exemplo, AWS PrivateLink) ativada por padrão. Se você precisar de conectividade Tri-Secret Secure ou privada para o serviço Snowflake para fins de conformidade, segurança ou outros, é sua responsabilidade configurar e habilitar esses recursos na conta de destino.

Pré-requisito: Habilitar a replicação para contas na organização

O administrador da organização (funçãoORGADMIN) deve habilitar a replicação para as contas de origem e destino.

Para permitir a replicação para contas, um usuário com a função ORGADMIN usa a função SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER para definir o parâmetro ENABLE_ACCOUNT_DATABASE_REPLICATION como true. Observe que várias contas em uma organização podem ser habilitadas para replicação a partir da mesma conta ORGADMIN.

Entre em uma conta ORGADMIN para habilitar a replicação para cada conta de origem e destino em sua organização.

USE ROLE ORGADMIN;

-- View the list of the accounts in your organization
-- Note the organization name and account name for each account for which you are enabling replication
SHOW ORGANIZATION ACCOUNTS;

-- Enable replication by executing this statement for each source and target account in your organization
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');
Copy

Embora a função SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER ofereça suporte ao identificador herdado de localizador de contas, ele causa resultados inesperados quando uma organização tem várias contas que compartilham o mesmo localizador (em regiões diferentes).

Etapa 1: criar uma função com o privilégio CREATE FAILOVER GROUP na conta de origem — Opcional

Crie uma função e conceda o privilégio CREATE FAILOVER GROUP. Essa etapa é opcional. Se você já criou essa função, pule para Etapa 2: criar um grupo primário de failover em uma conta de origem.

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;
Copy

Etapa 2: criar um grupo primário de failover em uma conta de origem

Crie um grupo primário de failover e permita a replicação e o failover de objetos específicos da conta atual (origem) para uma ou mais contas de destino na mesma organização.

Exibição de todas as contas habilitadas para replicação

Para recuperar a lista de contas em sua organização que estão habilitadas para replicação, use SHOW REPLICATION ACCOUNTS.

Execute a seguinte instrução SQL usando a função ACCOUNTADMIN:

SHOW REPLICATION ACCOUNTS;
Copy

Retorna:

+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| snowflake_region | created_on                    | account_name | account_locator | comment         | organization_name | is_org_admin |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_WEST_2    | 2020-07-15 21:59:25.455 -0800 | myaccount1   | myacctlocator1  |                 | myorg             | true         |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_1    | 2020-07-23 14:12:23.573 -0800 | myaccount2   | myacctlocator2  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_2    | 2020-07-25 19:25:04.412 -0800 | myaccount3   | myacctlocator3  |                 | myorg             | false        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

Consulte a lista completa de IDs de região.

Exibição de inscrição de grupo de failover e replicação

Conta, banco de dados e objetos compartilhados têm restrições de inscrição em grupos. Antes de criar novos grupos ou adicionar objetos aos grupos existentes, você pode rever a lista de grupos de failover existentes e os objetos em cada grupo.

Nota

Somente um administrador de conta (usuário com a função ACCOUNTADMIN) ou o proprietário do grupo (função com o privilégio OWNERSHIP sobre o grupo) pode executar as instruções SQL nesta seção.

Veja todos os grupos de failover vinculados à conta atual e os tipos de objetos em cada grupo:

SHOW FAILOVER GROUPS;
Copy

Veja todos os bancos de dados no grupo de failover myfg:

SHOW DATABASES IN FAILOVER GROUP myfg;
Copy

Veja todos os compartilhamentos do grupo de failover myfg:

SHOW SHARES IN FAILOVER GROUP myfg;
Copy

Habilitação da replicação de uma conta de origem para uma conta de destino

Você pode criar um grupo de replicação ou failover usando o Snowsight ou SQL.

Nota

Se você tiver bancos de dados para adicionar a um grupo de replicação ou failover que tenham sido previamente habilitados para replicação de banco de dados usando ALTER DATABASE, siga as instruções Transição da replicação de banco de dados para a replicação baseada em grupos (neste tópico) antes de adicioná-los a um grupo.

Criação de um grupo de replicação ou failover usando o Snowsight

Nota

  • Somente administradores de conta podem criar um grupo de replicação ou failover usando Snowsight (consulte Limitações do uso do Snowsight para configuração de replicação).

  • Você deve estar conectado à conta de destino como um usuário com a função ACCOUNTADMIN. Caso contrário, você será solicitado a fazer login.

    Tanto a conta de origem quanto a conta de destino devem usar o mesmo tipo de conexão (Internet pública). Caso contrário, o login na conta de destino falhará.

Conclua as etapas a seguir para criar um novo grupo de replicação ou failover:

  1. Entre em Snowsight e navegue até Admin » Accounts.

  2. Selecione Replication, selecione Groups.

  3. Selecione + Add Group.

  4. Selecione Target Account e depois selecione Next.

  5. Na caixa Group Name, insira um nome para o grupo que atenda aos seguintes requisitos:

    • Ele deve começar com um caractere alfabético e não pode conter espaços ou caracteres especiais a menos que toda a cadeia de caracteres do identificador esteja entre aspas duplas (por exemplo, “Meu objeto”). Os identificadores delimitados por aspas duplas também diferenciam letras maiúsculas de minúsculas.

      Para obter mais informações, consulte Requisitos para identificadores.

    • Deve ser exclusivo nos grupos de failover e replicação em uma conta.

  6. Escolha Select Objects para adicionar objetos de compartilhamento e conta ao seu grupo.

    Nota

    Os objetos de conta só podem ser adicionados a um grupo de replicação ou failover. Se já existir um grupo de replicação ou failover com algum objeto de conta em sua conta, você não poderá selecionar esses objetos.

  7. Escolha Select Databases para adicionar objetos de banco de dados ao seu grupo.

  8. Selecione Replication Frequency.

  9. Se a conta for Business Critical Edition ou superior, um grupo de failover será criado por padrão. Você pode optar por criar um grupo de replicação. Para criar um grupo de replicação, selecione Advanced Options e desmarque Enable Failover.

  10. Selecione Start Replication para criar o grupo de replicação.

    Se a criação do grupo de replicação não for bem-sucedida, consulte Solução de problemas de criação e edição de grupos de replicação usando Snowsight para erros comuns e como resolvê-los.

Criação de um grupo de failover usando SQL

Crie um grupo de failover de contas e objetos de banco de dados especificados na conta de origem e permita a replicação e o failover para uma lista de contas de destino. Consulte CREATE FAILOVER GROUP para sintaxe.

Por exemplo, permita a replicação de usuários, funções, warehouses, monitores de recursos e bancos de dados db1 e db2 da conta de origem para a conta myaccount2 na mesma organização. Defina o cronograma de replicação para atualizar myaccount2 automaticamente a cada 10 minutos.

Execute a seguinte instrução na conta de origem:

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
    OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES, INTEGRATIONS, NETWORK POLICIES
    ALLOWED_DATABASES = db1, db2
    ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS
    ALLOWED_ACCOUNTS = myorg.myaccount2
    REPLICATION_SCHEDULE = '10 MINUTE';
Copy

Etapa 3: criar uma função com o privilégio CREATE FAILOVER GROUP na conta de destino — Opcional

Crie uma função na conta de destino e conceda o privilégio CREATE FAILOVER GROUP. Essa etapa é opcional. Se você já criou essa função, pule para Etapa 4: criar um grupo de failover secundário na conta de destino.

USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;
Copy

Etapa 4: criar um grupo de failover secundário na conta de destino

Nota

Se existirem objetos de conta (por exemplo, usuários ou funções) na conta de destino que não existem na conta de origem, consulte Replicação inicial de usuários e funções antes de criar um grupo secundário.

Crie um grupo secundário de failover na conta de destino como uma réplica do grupo primário de failover na conta de origem.

Execute uma instrução CREATE FAILOVER GROUP … AS REPLICA OF em cada conta de destino para a qual você habilitou a replicação em Etapa 2: criar um grupo primário de failover em uma conta de origem (neste tópico).

Executado a partir de cada conta de destino:

USE ROLE myrole;

CREATE FAILOVER GROUP myfg
  AS REPLICA OF myorg.myaccount1.myfg;
Copy

Etapa 5. Atualização de um grupo secundário de failover na conta de destino manualmente — Opcional

Para atualizar manualmente os objetos em uma conta de destino, execute o comando ALTER FAILOVER GROUP … REFRESH.

Como prática recomendada, indicamos programar suas atualizações secundárias definindo o parâmetro REPLICATION_SCHEDULE usando CREATE FAILOVER GROUP ou ALTER FAILOVER GROUP.

Nota

Se o usuário que chama a função na conta de destino foi descartado na conta de origem, a operação de atualização falha.

Concessão do privilégio REPLICATE em um grupo de failover a uma função — Opcional

Para executar o comando de atualização de um grupo de failover ou replicação secundária na conta de destino, você deve usar uma função com o privilégio REPLICATE no grupo de failover. O privilégio REPLICATE atualmente não é replicado e deve ser concedido sobre um grupo de failover (ou replicação) tanto na conta de origem quanto na conta de destino.

Execute esta instrução da conta de origem usando uma função com o privilégio OWNERSHIP no grupo:

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
Copy

Execute esta instrução da conta de destino usando uma função com o privilégio OWNERSHIP no grupo:

GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
Copy

Atualização manual de um grupo secundário de failover

Por exemplo, para atualizar os objetos do grupo de failover myfg, execute a seguinte instrução a partir da conta de destino:

USE ROLE my_replication_role;

ALTER FAILOVER GROUP myfg REFRESH;
Copy

Aplicação de IDs globais a objetos criados por scripts em contas de destino

Se você criou objetos de conta, por exemplo, usuários e funções, em sua conta de destino por qualquer meio diferente de replicação (por exemplo, usando scripts), esses usuários e funções não terão um identificador global por padrão. A operação de atualização utiliza identificadores globais para sincronizar esses objetos com os mesmos objetos na conta de origem.

Na maioria dos casos, quando uma conta de destino é atualizada a partir da conta de origem, a operação de atualização descarta qualquer objeto de conta dos tipos na lista OBJECT_TYPES na conta de destino que não tenha um identificador global. No entanto, a replicação inicial de usuários e funções para uma conta de destino pode causar falha na primeira operação de atualização. Para obter detalhes sobre esse comportamento, consulte Replicação inicial de usuários e funções.

Replicação inicial de usuários e funções

O comportamento da operação de atualização inicial para os tipos de objeto USERS e ROLES pode variar dependendo da existência ou não de objetos correspondentes com o mesmo nome na conta de destino.

Nota

  • O comportamento descrito nesta seção se aplica apenas à primeira vez que esses tipos de objeto são replicados para a conta de destino.

  • Os cenários abaixo descrevem a replicação de USERS. O mesmo se aplica à replicação de ROLES.

  • Se houver usuários na conta de destino com o mesmo nome dos usuários na conta de origem, a operação de atualização inicial falhará e descreverá as duas opções que você terá para continuar:

    • Forçar a operação de atualização e permitir que quaisquer na conta de destino sejam descartados. Os usuários da conta de origem serão replicados para a conta de destino.

      Para forçar uma atualização para um grupo, use o parâmetro FORCE para o comando de atualização. Por exemplo, para forçar a atualização de um grupo de failover, execute o seguinte comando:

      ALTER FAILOVER GROUP <fg_name> REFRESH FORCE;
      
      Copy
    • Vincule os objetos de conta por nome. A função SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME vincula usuários com o mesmo nome na conta de destino e na conta de origem. Os usuários vinculados na conta de destino não são excluídos.

      Para vincular objetos de conta por nome, execute o seguinte comando:

      SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('<rg_name>');
      
      Copy

      Nota

      Qualquer usuário na conta de destino que não tenha um usuário correspondente na conta de origem com o mesmo nome será descartado.

  • Se não houver nenhum usuário na conta de destino com nomes correspondentes aos usuários da conta de origem, a operação de atualização inicial na conta de destino descartará todos os usuários. Isso pode resultar na seguinte perda de dados e metadados:

    • Se USERS estiverem incluídos na lista OBJECT_TYPES para um grupo de replicação ou failover:

      • As planilhas são perdidas.

      • O histórico de consultas é perdido.

    • Se USERS estiverem incluídos na lista OBJECT_TYPES, mas ROLES não:

      • As concessões de privilégios aos usuários são perdidas.

    • Se ROLES estiverem incluídos na lista OBJECT_TYPES:

      • Concessões de privilégio para compartilhar objetos são perdidas.

Para evitar descartar usuários ou funções na conta de destino:

  1. Na conta de origem, recrie manualmente quaisquer usuários ou funções que existam somente na conta de destino antes da replicação inicial.

  2. Na conta de destino, vincule objetos correspondentes com o mesmo nome em ambas as contas usando a função SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME.

Configuração do acesso ao armazenamento em nuvem para integrações de armazenamento secundárias

Se você ativar a replicação da integração de armazenamento, deverá executar etapas adicionais depois que a integração de armazenamento for replicada para contas de destino. A integração replicada tem sua própria identidade e entidade de gerenciamento de acesso (IAM) que são diferentes da identidade e entidade IAM da integração primária. Portanto, você deve atualizar as permissões do seu provedor de nuvem para conceder à integração replicada acesso ao seu armazenamento em nuvem.

Você só precisa configurar essa relação de confiança nas contas de destino uma vez.

O processo é semelhante à concessão de acesso na conta de origem. Para obter mais informações, consulte as seguintes páginas:

Configuração de atualização automatizada para tabelas de diretório em estágios secundários

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á seguir etapas para configurar a atualização automática para a tabela de diretórios secundária.

O processo é semelhante à configuração da atualização automática na sua conta de origem. Consulte o seguinte para obter mais informações:

Importante

  • Depois de concluir essas etapas de configuração em sua conta de destino, você deverá realizar uma atualização completa da tabela de diretórios para garantir que nenhuma notificação tenha sido perdida.

  • Para o Google Cloud Storage e o Azure Blob Storage, o nome da integração de notificação em cada conta de destino deve corresponder ao nome da integração de notificação na conta de origem.

Configuração de notificações para canais de ingestão automática secundária

Você deve executar etapas adicionais para configurar notificações de nuvem para canais de ingestão automática secundários antes do failover. Esta seção aborda por que essa configuração adicional é necessária e como concluí-la para cada provedor de nuvem compatível.

Amazon S3

O processo de configuração depende de como você configura as notificações de eventos. Por exemplo, suponha que você tenha um canal de ingestão automática que depende de um tópico do Amazon Simple Notification Service (SNS) para publicar mensagens sobre o local do estágio Snowflake.

Quando você replica o canal para uma conta de destino, o Snowflake cria automaticamente uma nova fila do Amazon Simple Queue Service (SQS). Você deve inscrever esta fila SQS da sua conta de destino no tópico SNS para receber notificações sobre o local do estágio.

Armazenamento de Blobs do Microsoft Azure

Um canal que carrega automaticamente dados de arquivos localizados em um estágio no armazenamento de blobs do Microsoft Azure requer uma assinatura de Event Grid, uma fila de armazenamento e uma integração de notificação vinculada à fila de armazenamento. Um canal secundário em uma conta de destino precisa de um Event Grid separado, uma fila de armazenamento e uma integração de notificação vinculada à fila de armazenamento. O Event Grid nas contas de origem e de destino deve ser configurado como pontos de extremidade para a mesma fonte de armazenamento do Azure.

Consulte o diagrama abaixo para detalhes de configuração:

Replicação de canal para Azure

Crie uma nova assinatura do Event Grid e uma fila de armazenamento. Em seguida, crie uma nova integração de notificação na conta de destino e conceda ao Snowflake acesso à sua fila de armazenamento. Para obter instruções, consulte Configuração da automação com a Event Grid do Azure.

Importante

O nome da integração de notificação em cada conta de destino deve corresponder ao nome da integração de notificação na conta de origem.

Estágio externo para Google Cloud Storage

Um canal que carrega automaticamente dados de arquivos localizados no Google Cloud Storage requer uma assinatura do Google Pub/Sub e uma integração de notificação que faça referência a essa assinatura. Cada canal replicado em uma conta de destino também requer uma assinatura do Google Pub/Sub e uma integração de notificação que faça referência a essa assinatura. A assinatura do Pub/Sub em cada conta de origem e de destino precisa estar inscrita no mesmo tópico do Pub/Sub que recebe notificações da origem do Google Cloud Storage.

Consulte o diagrama abaixo para detalhes de configuração:

Replicação de canais para GCP
Crie uma nova assinatura para seu tópico do Pub/Sub e uma nova integração de notificação em sua conta de destino.

Depois, conceda acesso do Snowflake à assinatura Pub/Sub. Para obter instruções, consulte Configuração da automação usando GCS Pub/Sub.

Importante

O nome da integração de notificação em cada conta de destino deve corresponder ao nome da integração de notificação na conta de origem.

Atualização do serviço remoto para integrações de API

Se você tiver ativado a replicação de integração de API, etapas adicionais serão necessárias após a replicação da integração API para a conta de destino. A integração replicada tem sua própria identidade e gerenciamento de acesso (IAM) que são diferentes da identidade e entidade IAM da integração primária. Portanto, você deve atualizar as permissões do serviço remoto para conceder acesso às funções replicadas. O processo é semelhante à concessão de acesso às funções na conta primária. Consulte os links abaixo para obter mais detalhes:

Monitoramento de replicação

Esta seção fornece informações sobre como monitorar o progresso, o histórico e os custos da replicação de contas.

Monitoramento da replicação usando o Snowsight

Para monitorar o progresso e o status da replicação de grupos de replicação e failover em uma organização, use a página Replication em Snowsight.

Você pode visualizar o status e os detalhes das operações de atualização:

  • Veja o status atual da operação de atualização mais recente.

  • Visualize o tempo de atraso da réplica (tempo desde a última operação de atualização).

  • Veja a distribuição dos tempos de atraso da réplica entre os grupos.

  • Visualize a data e hora da próxima operação de atualização agendada.

Nota

  • Snowsight lista os grupos de replicação e failover para os quais sua função tem o privilégio MONITOR, OWNERSHIP ou REPLICATE ativado.

  • Os detalhes da operação de atualização estão disponíveis apenas para usuários com a função ACCOUNTADMIN ou o privilégio OWNERSHIP no grupo.

  • Você deve estar conectado à conta de destino para visualizar os detalhes da operação de atualização. Caso contrário, você será solicitado a fazer login.

    Tanto a conta de origem quanto a conta de destino devem usar o mesmo tipo de conexão (Internet pública). Caso contrário, o login na conta de destino falhará.

Para visualizar o status de replicação de cada grupo de replicação ou failover, conclua as etapas a seguir:

  1. Entre em Snowsight e navegue até Admin » Accounts.

  2. Selecione Replication e depois selecione Groups.

A página Groups exibe detalhes da operação de atualização para todos os grupos para os quais sua função tem privilégio de visualização. Você pode usar os blocos para filtrar a visualização.

  • Por exemplo, se o bloco Status indicar que há operações de atualização com falha, você poderá selecionar o bloco para investigar o(s) grupo(s) com falhas.

  • O tempo de atraso no bloco Longest Replication lag refere-se à duração desde a última operação de atualização. Esse é o período de tempo que o grupo de failover ou replicação secundária atrasa em relação ao grupo primário. O maior tempo de atraso é o período de tempo desde que o grupo de replicação secundária mais antigo foi atualizado pela última vez.

    Por exemplo, se você tiver três grupos de failover, fg_1, fg_2, fg_3, com programações de replicação independentes de 10 minutos, 2 horas e 12 horas, respectivamente, o tempo de atraso mais longo poderá ser por até 12 horas. No entanto, se fg_3 tiver sido atualizado recentemente na conta de destino, seu tempo de atraso será redefinido para 0 e um grupo de failover diferente poderá ter um tempo de atraso maior.

  • Você pode selecionar uma barra individual no bloco Group Lag Distribution para filtrar os resultados para um grupo individual.

Você também pode filtrar grupos usando o campo de pesquisa ou os menus suspensos:

  • Você pode pesquisar por nome do grupo de replicação ou failover usando a caixa Ícone de pesquisa (pesquisa).

  • Escolha Type para filtrar os resultados por grupo de replicação ou failover.

  • Escolha Replicating para filtrar por grupos primários (selecione To) ou secundários (selecione From).

  • Escolha o menu Ícone da conta (contas) para filtrar os resultados por nome da conta.

  • Escolha Status para filtrar os resultados por status da operação de atualização:

    • Refresh Cancelled

    • Refresh Failed

    • Refresh In Progress

    • Refresh Successful

Você pode ver os seguintes detalhes sobre seus grupos de replicação e failover:

Coluna

Descrição

Name

Nome do grupo de replicação ou failover.

Is Replicating

Indica se o grupo está sendo replicado para uma conta de destino ou de uma conta de origem.

Se esta coluna contiver destinos disponíveis, não haverá grupos de failover ou replicação secundária. O número de destinos disponíveis indica o número de contas de destino para as quais o grupo primário pode ser replicado.

Status

Exibe o status da operação de atualização mais recente.

Você deve estar conectado à conta de destino para acessar os detalhes da replicação. Se você não estiver conectado, selecione Sign in para visualizar o status da operação de atualização do grupo secundário.

Tanto a conta de origem quanto a conta de destino devem usar o mesmo tipo de conexão (Internet pública). Caso contrário, o login na conta de destino falhará.

Replication Lag

O período de tempo desde a última operação de atualização. Esse é o período de tempo que o grupo de replicação secundário fica «atrasado» em relação ao grupo de replicação primário.

Next Refresh

A data e hora da próxima operação de atualização agendada.

Você pode selecionar um grupo de replicação ou failover para visualizar informações detalhadas sobre cada operação de atualização. Para obter mais informações, consulte a sessão sobre o histórico de replicação no Snowsight.

Monitoramento do progresso das operações de atualização

Esta seção fornece informações sobre como monitorar o progresso da replicação para um grupo de replicação ou failover específico.

Monitoramento do progresso das operações de atualização usando o Snowsight

Você pode visualizar o status de uma operação de atualização em andamento e os detalhes do histórico de operações de atualização usando Snowsight.

  1. Entre em Snowsight e navegue até Admin » Accounts.

  2. Selecione Replication, selecione Groups.

  3. Selecione o nome de um grupo de replicação ou failover.

Para obter mais informações sobre a visualização detalhada, consulte a seção sobre histórico de replicação no Snowsight.

Monitoramento do progresso das operações de atualização usando SQL

Para monitorar o progresso de uma atualização de um grupo de replicação ou um grupo de failover, consulte a função de tabela REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB (no Snowflake Information Schema).

Exemplo

Veja o progresso da operação de atualização mais recente para o grupo de failover myfg:

SELECT phase_name, start_time, end_time, progress, details
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('myfg'));
Copy

Visualização do histórico de replicação

Você pode visualizar o histórico de replicação usando Snowsight ou SQL.

Nota

Você pode visualizar o histórico de replicação dos grupos de replicação e failover para os quais sua função tem o privilégio MONITOR, OWNERSHIP ou REPLICATE ativado.

Visualização do histórico de replicação usando o Snowsight

Você pode visualizar o histórico de replicação e os detalhes de cada operação de atualização de um grupo de replicação ou failover específico na página de detalhes do grupo.

  1. Entre em Snowsight e navegue até Admin » Accounts.

  2. Selecione Replication, selecione Groups.

  3. Selecione o nome de um grupo de replicação ou failover.

Você pode então revisar as seguintes informações sobre o grupo:

  • Tipo de grupo (grupo de replicação ou grupo de failover).

  • Programação da replicação (por exemplo, a cada 10 minutos).

  • Duração de cada operação de atualização.

  • Tempo de atraso da réplica (tempo desde a última operação de atualização).

  • Data e hora da próxima operação de atualização agendada.

Você pode filtrar os dados da página por status e período de tempo:

  • Escolha Status para filtrar os resultados por status da operação de atualização:

    • Refresh Cancelled

    • Refresh Failed

    • Refresh In Progress

    • Refresh Successful

  • Escolha Duration para mostrar detalhes da operação de atualização para:

    • Last hour

    • Last 24 hours

    • Last 7 days

    • All

    Selecionar All exibe os últimos 14 dias de operações de atualização.

Os detalhes de cada operação de atualização incluem as seguintes colunas:

Coluna

Descrição

Query ID

ID da consulta da operação de atualização.

Status

Exibe o status da operação de atualização. Os valores válidos incluem Successful, Failed, In Progress.

Ended

Data e hora em que a operação de atualização terminou.

Duration

O tempo que a operação de atualização levou para ser concluída.

O período de duração é dividido e codificado por cores por fase de replicação. A largura de cada segmento colorido indica a porção de tempo gasto naquela fase.

A imagem abaixo é apenas para referência. Este gráfico está disponível quando você seleciona a operação de atualização para obter detalhes adicionais.

Fase e duração da replicação codificadas por cores.

Transferred

O número de bytes replicados.

Objects

O número de objetos replicados.

Selecione uma linha para visualizar detalhes adicionais sobre uma operação de atualização específica, incluindo:

  • Duração de cada fase de replicação.

  • Mensagem de erro (para operações de atualização com falha).

  • Lista de objetos de banco de dados replicados por tipo e número.

  • Número de bancos de dados replicados e nomes de bancos de dados.

Visualização do histórico de replicação usando SQL

Para visualizar o histórico de replicação de um grupo específico de replicação ou failover dentro de um intervalo de datas especificado, consulte uma das seguintes opções:

Exemplos

Consulte a função de tabela REPLICATION_GROUP_REFRESH_HISTORY do Information Schema para exibir o histórico de replicação de contas do grupo de failover myfg nos últimos 7 dias:

SELECT PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM TABLE(information_schema.replication_group_refresh_history('myfg'))
  WHERE START_TIME >= current_date - interval '7 days';
Copy

Consulte a exibição REPLICATION_GROUP_REFRESH_HISTORY do Account Usage para ver o histórico de replicação da conta no mês atual:

SELECT REPLICATION_GROUP_NAME, PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
  FROM snowflake.account_usage.replication_group_refresh_history
  WHERE START_TIME >= date_trunc('month', current_date());
Copy

Monitoramento dos custos de replicação

Para monitorar o uso de crédito para replicação, consulte uma das seguintes opções:

Exemplos

Consulte a função de tabela REPLICATION_GROUP_USAGE_HISTORY para exibir os créditos utilizados para a replicação de contas nos últimos 7 dias:

SELECT start_time, end_time, replication_group_name, credits_used, bytes_transferred
  FROM table(information_schema.replication_group_usage_history(date_range_start=>dateadd('day', -7, current_date())));
Copy

Consulte a exibição REPLICATION_GROUP_USAGE_HISTORY do Account Usage para ver os créditos utilizados pelo grupo de replicação ou failover para o histórico de replicação de contas no mês atual:

SELECT start_time, 
  end_time, 
  replication_group_name, 
  credits_used, 
  bytes_transferred
FROM snowflake.account_usage.replication_group_usage_history
WHERE start_time >= DATE_TRUNC('month', CURRENT_DATE());
Copy

Monitoramento dos custos de replicação para bancos de dados

O custo de replicação para um banco de dados individual incluído em uma replicação ou grupo de failover pode ser calculado recuperando o número de bytes copiados para o banco de dados e associando-o aos créditos utilizados.

Exemplos

Consulta de exibições do Account Usage

Os exemplos seguintes calculam os custos de replicação de banco de dados em um grupo de replicação para os últimos 30 dias.

  1. Consulte a exibição REPLICATION_GROUP_REFRESH_HISTORY do Account Usage e calcule a soma do número de bytes replicados por banco de dados.

    Por exemplo, para calcular a soma do número de bytes replicados para bancos de dados no grupo de replicação myrg nos últimos 30 dias:

    select sum(value:totalBytesToReplicate) as sum_database_bytes
    from snowflake.account_usage.replication_group_refresh_history rh,
        lateral flatten(input => rh.total_bytes:databases)
    where rh.replication_group_name = 'MYRG'
    and rh.start_time >= current_date - interval '30 days';
    
    Copy

    Observe a saída da soma dos bytes do banco de dados:

    +--------------------+
    | SUM_DATABASE_BYTES |
    |--------------------|
    |              22016 |
    +--------------------+
    
    Copy
  2. Consulte a exibição REPLICATION_GROUP_USAGE_HISTORY do Account Usage e calcule a soma do número de créditos usados e a soma dos bytes transferidos para a replicação.

    Por exemplo, para calcular a soma do número de créditos utilizados e a soma dos bytes transferidos para replicação do grupo de replicação myrg nos últimos 30 dias:

    select sum(credits_used) as credits_used, SUM(bytes_transferred) as bytes_transferred
    from snowflake.account_usage.replication_group_usage_history
    where replication_group_name = 'MYRG'
    and start_time >= current_date - interval '30 days';
    
    Copy

    Observe a saída da soma dos créditos utilizados e a soma dos bytes transferidos:

    +--------------+-------------------+
    | CREDITS_USED | BYTES_TRANSFERRED |
    |--------------+-------------------|
    |  1.357923604 |             22013 |
    +--------------+-------------------+
    
    Copy
  3. Calcule os custos de replicação para bancos de dados usando os valores dos bytes transferidos para bancos de dados, a soma dos créditos utilizados e a soma de todos os bytes transferidos para replicação das duas etapas anteriores:

    (<banco_de_dados_bytes_transferidos> / <bytes_transferidos>) * <créditos_usados>

    Por exemplo:

    (22016 / 22013) * 1.357923604 = 1.35810866)

Consulta das funções de tabela Information Schema

Para operações de atualização dentro dos últimos 14 dias, consulte as funções associadas da tabela Information Schema.

  1. Consulte a função da tabela REPLICATION_GROUP_REFRESH_HISTORY para visualizar a soma do número de bytes copiados para replicação do banco de dados para o grupo de replicação myrg:

    select sum(value:totalBytesToReplicate)
      from table(information_schema.replication_group_refresh_history('myrg')) as rh,
      lateral flatten(input => total_bytes:databases)
      where rh.phase_name = 'COMPLETED'
      and rh.start_time >= current_date - interval '14 days';
    
    Copy
  2. Consulte a função da tabela REPLICATION_GROUP_USAGE_HISTORY para ver a soma do número de créditos utilizados e a soma dos bytes transferidos para replicação para o grupo de replicação myrg:

    select sum(credits_used), sum(bytes_transferred)
      from table(information_schema.replication_group_usage_history(
          date_range_start=>dateadd('day', -14, current_date()),
          replication_group_name => 'myrg'
      ));
    
    Copy

Comparação de conjuntos de dados em bancos de dados primários e secundários

Se os objetos de banco de dados forem replicados em um grupo de replicação ou failover, a função HASH_AGG pode ser usada para comparar as linhas em um conjunto aleatório de tabelas em um banco de dados primário e secundário para verificar a consistência dos dados. A função HASH_AGG retorna um valor agregado de hash de 64 bits assinado para o conjunto (não ordenado) de linhas de entrada. Consulte esta função em todas as tabelas ou em um subconjunto aleatório de tabelas em um banco de dados secundário e no banco de dados primário (a partir do carimbo de data/hora do instantâneo do banco de dados primário) e compare a saída.

Exemplo

Nos exemplos abaixo, o banco de dados mydb está incluído no grupo de failover myfg. O banco de dados mydb contém a tabela mytable.

Executado na conta de destino

  1. Consulte a função de tabela REPLICATION_GROUP_REFRESH_PROGRESS (no Snowflake Information Schema). Observe o primarySnapshotTimestamp na coluna DETAILS para a fase PRIMARY_UPLOADING_METADATA. Este é o carimbo de data/hora para o último instantâneo do banco de dados primário.

    SELECT PARSE_JSON(details)['primarySnapshotTimestamp']
      FROM TABLE(information_schema.replication_group_refresh_progress('myfg'))
      WHERE PHASE_NAME = 'PRIMARY_UPLOADING_METADATA';
    
    Copy
  2. Consulte a função HASH_AGG para uma tabela específica no banco de dados secundário. A seguinte consulta retorna um valor de hash para todas as linhas da tabela mytable:

    SELECT HASH_AGG( * ) FROM mytable;
    
    Copy

Executado na conta de origem

  1. Consulte a função HASH_AGG para a mesma tabela no banco de dados primário. Usando o Time Travel, especifique o carimbo de data/hora em que o último instantâneo foi tirado para o banco de dados secundário:

    SELECT HASH_AGG( * ) FROM mytable AT(TIMESTAMP => '<primarySnapshotTimestamp>'::TIMESTAMP);
    
    Copy
  2. Compare os resultados das duas consultas. A saída deve ser idêntica.

Modificação de um grupo de replicação ou failover

Você pode editar o nome, os objetos incluídos e o agendamento de replicação de um grupo de replicação ou de failover usando Snowsight ou SQL.

Modificação de um grupo de replicação ou failover usando o Snowsight

Nota

Somente administradores de conta podem editar um grupo de replicação ou failover usando Snowsight (consulte Limitações do uso do Snowsight para configuração de replicação).

Para editar o nome do grupo, você deve estar conectado à conta de destino. Se você não estiver conectado, a coluna Status exibirá uma mensagem de login em vez do status de atualização.

Tanto a conta de origem quanto a conta de destino devem usar o mesmo tipo de conexão (Internet pública). Caso contrário, o login na conta de destino falhará.

  1. Entre em Snowsight e navegue até Admin » Accounts.

  2. Selecione Replication, selecione Groups.

  3. Localize o grupo de replicação ou failover que você deseja editar. Selecione o menu More () na última coluna da linha.

  4. Selecione Edit.

  5. Para alterar o nome do grupo, insira um novo nome na caixa Group Name que atenda aos seguintes requisitos:

    • Ele deve começar com um caractere alfabético e não pode conter espaços ou caracteres especiais a menos que toda a cadeia de caracteres do identificador esteja entre aspas duplas (por exemplo, “Meu objeto”). Os identificadores delimitados por aspas duplas também diferenciam letras maiúsculas de minúsculas.

      Para obter mais informações, consulte Requisitos para identificadores.

    • Nomes para grupos de failover e grupos de replicação em uma conta devem ser únicos.

  6. Escolha Select Objects para adicionar ou remover objetos de conta e compartilhamento.

    Nota

    Os objetos de conta só podem ser adicionados a um grupo de replicação ou failover. Se já existir um grupo de replicação ou failover com algum objeto de conta em sua conta, você não poderá selecionar esses objetos.

  7. Escolha Select Databases para adicionar ou remover objetos de banco de dados.

  8. Selecione Replication Frequency para alterar a programação de replicação de um grupo.

  9. Selecione Save Changes para atualizar o grupo.

    Se não for possível salvar as alterações no grupo, consulte Solução de problemas de criação e edição de grupos de replicação usando Snowsight para ver erros comuns e como resolvê-los.

Modificação de um grupo de replicação ou failover usando SQL

Você pode modificar as propriedades de um grupo de replicação ou failover usando o comando ALTER REPLICATION GROUP ou ALTER FAILOVER GROUP.

Descarte de um grupo secundário de replicação ou failover

Você pode descartar uma replicação ou failover secundário usando o comando DROP REPLICATION GROUP ou DROP FAILOVER GROUP. Somente o proprietário do grupo de replicação ou failover (ou seja, a função com o privilégio OWNERSHIP sobre o grupo) pode descartar o grupo.

Para descartar um grupo de failover ou replicação secundária usando Snowsight, você deve descartar o grupo na conta de origem. Consulte Descarte de um grupo de replicação ou failover usando o Snowsight.

Descarte de um grupo primário de replicação ou failover

Você pode descartar um grupo de failover ou replicação primária usando Snowsight ou SQL. Se você estiver excluindo um grupo primário usando SQL, primeiro deverá descartar todos os grupos secundários. Consulte Descarte de um grupo secundário de replicação ou failover.

Descarte de um grupo primário de failover ou replicação usando SQL

Um grupo primário de replicação ou failover só pode ser descartado depois que todas as réplicas do grupo (ou seja, grupos secundários de replicação ou failover) tiverem sido descartadas. Como alternativa, você pode promover um grupo de failover secundário para servir como o grupo de failover primário e, em seguida, descartar o antigo grupo de failover primário.

Note que somente o proprietário do grupo pode descartar o grupo.

Descarte de um grupo de replicação ou failover usando o Snowsight

Nota

Somente administradores de conta podem excluir um grupo de replicação ou failover usando Snowsight (consulte Limitações do uso do Snowsight para configuração de replicação).

Você pode excluir um grupo de replicação primária ou de failover e quaisquer grupos secundários vinculados.

  1. Entre em Snowsight e navegue até Admin » Accounts.

  2. Selecione Replication, selecione Groups.

  3. Localize o grupo de replicação ou failover que você deseja excluir. Selecione o menu More () na última coluna da linha.

  4. Selecione Drop e depois selecione Drop Group.

Solução de problemas de criação e edição de grupos de replicação usando Snowsight

Os cenários a seguir podem ajudar você a solucionar problemas comuns que podem ocorrer ao criar ou editar o grupo de replicação ou failover usando Snowsight.

Você não consegue adicionar um banco de dados a um grupo

Erro

Database '<database_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.

Causa

Um banco de dados só pode estar em um grupo de replicação ou failover. Um dos bancos de dados selecionados para o grupo já está incluído em outro grupo de replicação ou failover.

Solução

Escolha Select Databases e desmarque todos os bancos de dados que já estão incluídos em outro grupo.

Erro

Cannot directly add previously replicated object '<database_name>' to a
replication group. Please use the provided system functions to convert
this object first.

Causa

O banco de dados que você deseja adicionar a um grupo de replicação ou failover foi configurado anteriormente para replicação de banco de dados.

Solução

Desabilite a replicação do banco de dados para o banco de dados. Consulte Transição da replicação de banco de dados para a replicação baseada em grupos.

Você não consegue adicionar um compartilhamento a um grupo

Erro

Share '<share_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.

Causa

Um compartilhamento só pode estar em um grupo de replicação ou failover. Um dos compartilhamentos selecionados para o grupo já está incluído em outro grupo de replicação ou failover.

Solução

Escolha Select Objects e desmarque todos os compartilhamentos que já estão incluídos em outro grupo.

Limitações do uso do Snowsight para configuração de replicação

  • Somente um usuário com a função ACCOUNTADMIN pode criar um grupo de replicação ou failover usando Snowsight. Um usuário com uma função com privilégio CREATE REPLICATION GROUP ou CREATE FAILOVER GROUP pode criar um grupo usando os respectivos comandos SQL.

  • Somente um usuário com a função ACCOUNTADMIN pode editar ou descartar um grupo de replicação ou failover usando Snowsight. Um usuário com uma função com privilégio OWNERSHIP em um grupo de replicação ou failover pode editar e descartar grupos usando os respectivos comandos SQL.