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

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 em uma conta de origem usando o Snowsight¶

Para executar essas ações, é necessário estar conectado à conta de origem. Se você não estiver conectado, a coluna Status exibirá uma mensagem de login em vez do status de atualização.

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

2. Selecione Replication e depois selecione Groups.

3. Localize o grupo de replicação ou failover que deseja editar e 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:

   • Deve começar com um caractere alfabético e não pode conter espaços ou caracteres especiais, a menos que a cadeia de caracteres do identificador esteja entre aspas duplas (por exemplo, «My object»). 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 em uma conta de origem 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.

Como pausar ou retomar um cronograma de replicação em uma conta de destino usando o Snowsight¶

Para pausar ou retomar um cronograma de replicação, é necessário estar conectado à conta de destino.

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

2. Selecione Replication e depois selecione Groups.

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

4. Selecione Pause ou Resume.

Como pausar ou retomar um cronograma de replicação em uma conta de destino usando SQL¶

É possível pausar ou retomar um cronograma de replicação em uma conta de destino usando o comando ALTER REPLICATION GROUP ou ALTER FAILOVER GROUP. Para pausar, especifique o parâmetro SUSPEND. Para retomar, especifique o parâmetro RESUME.

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