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

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');

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.

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.

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 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');

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;

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.

SHOW REPLICATION ACCOUNTS;

+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| 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        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

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';

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;

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

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;

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.

Etapa 6. Concessão do privilégio FAILOVER em um grupo de failover a uma função — Opcional¶

Para executar o comando de failover de um grupo de failover secundário em uma conta de destino, você deve usar uma função com o privilégio FAILOVER no grupo de failover. O privilégio FAILOVER atualmente não é replicado e deve ser concedido em cada conta de origem e destino.

Para obter mais informações, consulte Replicação de funções e concessões.

Por exemplo, para conceder o privilégio FAILOVER à função my_failover_role no grupo de failover my_fg, execute a seguinte instrução na conta de destino usando uma função com o privilégio OWNERSHIP no grupo:

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

Para instruções sobre como criar uma função personalizada com um conjunto específico de privilégios, consulte Criação de funções personalizadas.

Para informações gerais sobre concessões de funções e privilégios para executar ações de SQL em objetos protegíveis, consulte Visão geral do controle de acesso.

Uso de SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME() para aplicar IDs globais¶

Você pode evitar a perda de alguns tipos de objetos vinculando objetos correspondentes com o mesmo nome nas contas de origem e de destino. A função SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME adiciona um identificador global aos objetos de conta na conta de destino.

Aplique identificadores globais aos objetos de conta na conta de destino dos tipos incluídos na lista object_types para o grupo de failover myfg:

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

SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');

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.

• 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.

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.

• Se você usar o Amazon S3 Event Notifications com o Amazon Simple Queue Service (SQS), siga as instruções em Etapa 4: configurar notificações de eventos.

  Importante

  Para garantir que o canal não tenha perdido nenhuma notificação, você deve atualizá-lo após mudar para a nova fila SQS.

  Você também pode migrar de SQS para SNS. Para obter mais informações, consulte Migração para Amazon Simple Notification Service (SNS).

• Se você usar o Amazon Simple Notification Service (SNS), consulte Inscrição na fila Snowflake SQS em seu tópico SNS.

• Se você usar Amazon EventBridge, consulte Opção 3: configuração do Amazon EventBridge para automatizar o Snowpipe.

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:

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.

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:

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.

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.

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 (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 (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:

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.

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

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

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

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.
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.

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';

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());

Monitoramento dos custos de replicação¶

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

• Exibição REPLICATION_GROUP_USAGE_HISTORY (em Account Usage).

• Função de tabela REPLICATION_GROUP_USAGE_HISTORY (no Snowflake Information Schema).

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())));

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());

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.

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.

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

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 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¶

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.

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

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

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

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

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