Replicação de objetos de conta¶

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

   • Se você tiver bancos de dados para adicionar a um grupo de replicação ou failover que tenham sido previamente habilitados para failover e 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.

   • Para adicionar um banco de dados a um grupo de failover, a função ativa deve ter o privilégio MONITOR sobre o banco de dados. Para obter mais detalhes sobre privilégios de banco de dados, consulte Privilégios de banco de dados (em um tópico separado).

   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

   Atenção

   Se existem objetos de conta (por exemplo, usuários ou funções) na conta de destino que você não deseja descartar durante a replicação, não inclua o parâmetro REPLICATION_SCHEDULE quando você criar um grupo de replicação ou failover. Para obter mais detalhes, consulte Aplicação de IDs globais a objetos criados por scripts em contas de destino.

Executado na conta de destino¶

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

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

   USE ROLE myrole;
   
   CREATE FAILOVER GROUP myfg
     AS REPLICA OF myorg.myaccount1.myfg;
   

   Copy

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

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 the following SQL statements using the ACCOUNTADMIN role:
SHOW REPLICATION ACCOUNTS;

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

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.

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

Habilitar a replicação de contas e objetos de banco de dados de uma conta de origem para uma conta de destino¶

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.

Executado na conta de origem:

use role myrole;

-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
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';

Conceder o privilégio REPLICATE sobre 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

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

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

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

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

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

Exemplos¶

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¶

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

4. Compare os resultados das duas consultas. A saída deve ser idêntica.