Replicação de bancos de dados em várias contas¶

Gerenciamento de bancos de dados primários¶

1. Entre em Snowsight com uma conta Snowflake que contenha um banco de dados primário.

2. Selecione o menu suspenso no canto superior esquerdo (ao lado de seu nome de login) » Switch Role » ACCOUNTADMIN.

3. Selecione Data » Databases no painel de navegação à esquerda. Selecione um banco de dados primário no navegador de objetos de banco de dados. A página de detalhes do banco de dados é aberta.

   Como alternativa, para visualizar apenas os bancos de dados que foram habilitados para replicação, use o filtro Replication Status » Primary para listar os bancos de dados primários na conta. Selecione um banco de dados na lista para abrir a página de detalhes.

   Nota

   O filtro Replication Status só estará disponível se uma conta for de origem ou de destino para replicação de banco de dados.

4. Selecione » Enable Replication. A caixa de diálogo Enable replication é aberta.

   Escolha a ação que deseja realizar:

   • Ativar o failover. Este recurso requer uma Business Critical Edition (ou superior).

   • Criar um banco de dados secundário em uma ou mais contas de destino.

     Se um banco de dados primário em outra conta estiver habilitado para replicação na conta atual, você poderá criar um banco de dados secundário na conta atual. Para adicionar contas de destino adicionais, use o comando ALTER DATABASE na conta de origem para atualizar o banco de dados primário.

   • Renovar cada banco de dados secundário uma vez, após a sua criação.

5. Para cada conta de destino deste banco de dados, verifique as opções para criar um banco de dados secundário e atualize o banco de dados.

6. Entre na conta de destino como um usuário a quem foi previamente concedida a função ACCOUNTADMIN nessa conta.

   O Snowflake executa as ações solicitadas e exibe uma caixa de diálogo de sucesso.

   Gerencie a replicação para este banco de dados a partir da guia Replication nos detalhes do banco de dados.

Gerenciamento de bancos de dados secundários¶

1. Entre em Snowsight com uma conta Snowflake que contenha um banco de dados secundário.

2. Selecione o menu suspenso no canto superior esquerdo (ao lado de seu nome de login) » Switch Role » ACCOUNTADMIN.

3. Selecione Data » Databases no painel de navegação à esquerda.

   As seguintes ações estão disponíveis no botão de ações (…) no canto superior direito da página:

   • Crie um banco de dados secundário.

     Nota

     Esta opção só estará disponível se uma conta for uma conta de origem ou de destino para replicação de banco de dados.

     Se um banco de dados primário em outra conta estiver habilitado para replicação na conta atual, você poderá criar um banco de dados secundário na conta atual. Para adicionar contas de destino adicionais, use o comando ALTER DATABASE na conta de origem para atualizar o banco de dados primário.

4. Selecione um banco de dados secundário no navegador de objetos do banco de dados. A página de detalhes do banco de dados é aberta.

5. Selecione a guia Replication.

   As seguintes ações estão disponíveis no botão de ações (…) no canto superior direito da página:

   • Promova o banco de dados secundário para servir como o banco de dados primário. Este recurso requer uma Business Critical Edition (ou superior).

     Nota

     Para promover um banco de dados secundário para servir como primário, o banco de dados primário deve ter o failover ativado para a conta de destino onde o banco de dados secundário está localizado.

     Se esta opção não estiver disponível, você poderá usar o comando ALTER DATABASE na conta de origem para ativar o failover do banco de dados primário para a conta de destino. Para obter mais informações, consulte Etapa 3: habilitar o failover para um banco de dados primário.

   • Atualize o banco de dados secundário.

   • Copie um modelo para criar uma tarefa que atualize o banco de dados secundário em um cronograma. Cole o modelo em uma planilha do Snowsight e edite-a para especificar o cronograma desejado.

Etapa 1: exibir todas as contas em sua organização¶

Recupere a lista de contas em sua organização nas quais a replicação foi habilitada. Qualquer banco de dados permanente ou transitório existente nestas contas pode ser modificado para servir como um banco de dados primário. As réplicas de um banco de dados primário (ou seja, bancos de dados secundários) só podem ser criadas nessas contas.

Para ver a lista de contas em sua organização, consulte SHOW REPLICATION ACCOUNTS.

SHOW REPLICATION ACCOUNTS;

+------------------+---------------------------------+---------------+------------------+---------+-------------------+
| snowflake_region | created_on                      | account_name  | account_locator  | comment | organization_name |
|------------------+---------------------------------+---------------+------------------+---------+-------------------|
| AWS_US_WEST_2    | 2018-11-19 16:11:12.720 -0700   | ACCOUNT1      | MYACCOUNT1       |         | MYORG             |
| AWS_US_EAST_1    | 2019-06-02 14:12:23.192 -0700   | ACCOUNT2      | MYACCOUNT2       |         | MYORG             |
+------------------+---------------------------------+---------------+------------------+---------+-------------------+

Consulte a lista completa de IDs de região.

Etapa 2: promover um banco de dados local para servir como um banco de dados primário¶

Modifique um banco de dados permanente ou transitório existente para servir como banco de dados primário usando uma instrução ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS. Forneça uma lista de contas separadas por vírgulas em sua organização que possam armazenar uma réplica deste banco de dados (ou seja, um banco de dados secundário), permitindo que os usuários nessas contas consultem objetos no banco de dados secundário.

ALTER DATABASE mydb1 ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;

Etapa 3: habilitar o failover para um banco de dados primário¶

Habilite o failover para um banco de dados primário para uma ou mais contas em sua organização usando uma instrução ALTER DATABASE … ENABLE FAILOVER TO ACCOUNTS. A réplica deste banco de dados primário em qualquer uma destas contas (ou seja, um banco de dados secundário) pode ser promovida para servir como banco de dados primário.

Note que a habilitação de failover para um banco de dados primário pode ser feita antes de ou após uma réplica do banco de dados primário ter sido criada em uma conta especificada.

-- Executed from primary account
ALTER DATABASE mydb1 ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;

Etapa 4: criar um banco de dados secundário¶

Crie uma réplica de um banco de dados primário existente na mesma conta que armazena o banco de dados primário, ou em uma conta diferente (na mesma região ou em uma região diferente). Note que você só pode criar um banco de dados secundário em uma conta especificada na instrução ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS na Etapa 2: Promover um banco de dados local para servir como um banco de dados primário.

Execute uma instrução CREATE DATABASE … AS REPLICA OF em cada conta de destino para criar uma réplica do banco de dados primário especificado.

Para visualizar a lista de bancos de dados primários e secundários em sua organização, consulte SHOW REPLICATION DATABASES. Após a criação de um banco de dados secundário, um administrador de contas pode transferir a propriedade do banco de dados para outra função (usando GRANT OWNERSHIP).

-- Log into the ACCOUNT2 account.

-- Query the set of primary and secondary databases in your organization.
-- In this example, the MYORG.ACCOUNT1 primary database is available to replicate.
SHOW REPLICATION DATABASES;

+------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------+
| snowflake_region | created_on                    | account_name    | name     | comment | is_primary | primary                    | replication_allowed_to_accounts | failover_allowed_to_accounts | organization_name | account_locator |
|------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------|
| AWS_US_WEST_2    | 2019-11-15 00:51:45.473 -0700 | ACCOUNT1        | MYDB1    | NULL    | true       | MYORG.ACCOUNT1.MYDB1       | MYORG.ACCOUNT2, MYORG,ACCOUNT1  | MYORG.ACCOUNT1               | MYORG             | MYACCOUNT1      |
+------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------+

-- Create a replica of the 'mydb1' primary database
-- If the primary database has the DATA_RETENTION_TIME_IN_DAYS parameter set to a value other than the default value,
-- set the same value for the parameter on the secondary database.
CREATE DATABASE mydb1
  AS REPLICA OF myorg.account1.mydb1
  DATA_RETENTION_TIME_IN_DAYS = 10;

-- Verify the secondary database
SHOW REPLICATION DATABASES;

+------------------+-------------------------------+---------------+----------+---------+------------+-------------------------+---------------------------------+------------------------------+-------------------+-----------------+
| snowflake_region | created_on                    | account_name  | name     | comment | is_primary | primary                 | replication_allowed_to_accounts | failover_allowed_to_accounts | organization_name | account_locator |
|------------------+-------------------------------+---------------+----------+---------+------------+------------------------------------------+----------------+------------------------------+-------------------------------------|
| AWS_US_WEST_2    | 2019-11-15 00:51:45.473 -0700 | ACCOUNT1      | MYDB1    | NULL    | true       | MYORG.ACCOUNT1.MYDB1    | MYORG.ACCOUNT2, MYORG.ACCOUNT1  | MYORG.ACCOUNT1               | MYORG             | MYACCOUNT1      |
| AWS_US_EAST_1    | 2019-08-15 15:51:49.094 -0700 | ACCOUNT2      | MYDB1    | NULL    | false      | MYORG.ACCOUNT1.MYDB1    |                                 |                              | MYORG             | MYACCOUNT2      |
+------------------+-------------------------------+---------------+----------+---------+------------+-------------------------+---------------------------------+------------------------------+-------------------+-----------------+

Etapa 5. Atualização de cada banco de dados secundário¶

As instruções nesta seção explicam como atualizar um banco de dados secundário a partir de um instantâneo de seu banco de dados primário (usando ALTER DATABASE … REFRESH). Um instantâneo inclui alterações nos objetos e dados. Para a replicação inicial de um banco de dados primário muito grande, recomendamos aumentar o tempo limite da instrução.

Observe que o proprietário do banco de dados secundário (função com o privilégio OWNERSHIP no banco de dados) possui quaisquer novos objetos adicionados como resultado de uma atualização do banco de dados.

Para verificar a região atual após fazer login em uma conta, consulte a função CURRENT_REGION.

ALTER DATABASE mydb1 REFRESH;

Você também pode atualizar um banco de dados secundário interface da Web.

Etapa 6. Atualização de um banco de dados secundário em um cronograma¶

Como melhor prática, recomendamos agendar suas atualizações do banco de dados secundário. Esta seção fornece instruções para iniciar uma atualização automática do banco de dados em um horário especificado.

A frequência com que você atualiza um banco de dados secundário depende do objetivo de ponto de recuperação (RPO) para os dados do banco de dados secundário. Por exemplo, se os aplicativos que dependem dos dados podem tolerar até 1 hora de perda de dados, então você deve atualizar os dados pelo menos a cada hora. Se a tolerância à perda de dados for de 5 minutos, então atualize o banco de dados secundário pelo menos a cada 5 minutos.

Complete as etapas desta seção para iniciar uma atualização automática do banco de dados em um horário especificado.

Pré-requisitos

Os seguintes objetos Snowflake são necessários na conta que armazena o banco de dados secundário:

• O banco de dados secundário.

• Um banco de dados separado para armazenar os novos objetos criados nesta seção. Como os bancos de dados secundários são somente leitura, esse banco de dados deve ser separado do banco de dados secundário. Este banco de dados também deve incluir os seguintes objetos:

  • Esquema. Use o esquema PUBLIC, ou crie um novo esquema usando CREATE SCHEMA.

  • Warehouse. Qualquer warehouse pode ser fornecido aqui para atender à exigência de sintaxe, mas não é utilizado para a atualização do banco de dados. Crie um novo warehouse usando CREATE WAREHOUSE.

  • Tarefa que atualiza o banco de dados secundário em um cronograma.

Privilégios obrigatórios

As etapas desta seção exigem uma função com os seguintes privilégios na conta em que o banco de dados secundário é atualizado:

Tipo de objeto	Objeto	Privilégio	Notas
Conta	Conta que armazena o banco de dados secundário	EXECUTE TASK	Necessário para executar a nova tarefa.
Banco de dados	Banco de dados secundário	OWNERSHIP	Necessário para atualizar o banco de dados secundário.
Banco de dados	Banco de dados que armazena a nova tarefa	USAGE
Esquema	Esquema que armazena a nova tarefa	USAGE, CREATE TASK
Tarefa		OWNERSHIP	A função que cria a tarefa é, por padrão, proprietária do objeto. A propriedade pode ser transferida para uma função diferente usando GRANT privileges … TO ROLE.
Warehouse	Warehouse utilizado para configurar a tarefa	USAGE	A especificação de um warehouse é necessária para configurar a tarefa, porém o warehouse não é utilizado para executar a tarefa ou para a operação de atualização.

Etapas

Complete as seguintes etapas para cada banco de dados secundário que você deseja atualizar segundo um cronograma:

1. Crie uma tarefa que inicie a atualização do banco de dados segundo um cronograma (usando CREATE TASK). Observe que embora a sintaxe CREATE TASK para especificar um cronograma de replicação requeira um warehouse, o warehouse não é utilizado para replicação.

   Por exemplo, crie uma tarefa chamada refresh_mydb1_task que atualiza um banco de dados secundário chamado mydb1 a cada 10 minutos com um tempo limite de 4 horas. A tarefa é configurada utilizando o warehouse existente mywh:

   CREATE TASK refresh_mydb1_task
     WAREHOUSE = mywh
     SCHEDULE = '10 minute'
     USER_TASK_TIMEOUT_MS = 14400000
   AS
     ALTER DATABASE mydb1 REFRESH;
   

   Copy

2. Uma tarefa é suspensa por padrão quando é criada. Retome a tarefa para permitir que ela seja executada com base nos parâmetros especificados na definição da tarefa:

ALTER TASK refresh_mydb1_task RESUME;

Copy

Exemplo¶

Execute as seguintes instruções SQL em seu cliente Snowflake preferido para permitir replicação e failover, faça uma atualização inicial do banco de dados e configure as atualizações programadas.

-- The commands below are executed from the source account

-- View replication enabled accounts
SHOW REPLICATION ACCOUNTS;

ALTER DATABASE mydb ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;
ALTER DATABASE mydb ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;

-- The commands below are executed from each target account

-- View replication enabled databases
-- Note the primary column of the source database for the CREATE DATABASE statement below
SHOW REPLICATION DATABASES;

-- If the primary database has the DATA_RETENTION_TIME_IN_DAYS parameter set to a value other than the default value,
-- set the same value for the parameter on the secondary database.
CREATE DATABASE mydb
  AS REPLICA OF myorg.account1.mydb
  DATA_RETENTION_TIME_IN_DAYS = 10;

-- Increase statement timeout for initial refresh
-- Optional but recommended for initial refresh of a large database
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
-- If you have an active warehouse in current session, update warehouse statement timeout
SELECT CURRENT_WAREHOUSE();
ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
-- Reset warehouse statement timeout after initial refresh
ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;

-- Refresh a secondary database
ALTER DATABASE mydb REFRESH;

-- Create task
-- Set up refresh schedule for each secondary database using a separate database
USE DATABASE my_db2;

-- Create a task and RESUME the task for each secondary database
-- Edit the task schedule and timeout for your specific use case
CREATE TASK my_refresh_task
  WAREHOUSE = my_wh
  SCHEDULE = '10 minute'
  USER_TASK_TIMEOUT_MS = 14400000
AS
  ALTER DATABASE mydb REFRESH;

-- Start task
ALTER TASK my_refresh_task RESUME;

Uso do localizador de contas herdado¶

Embora o formato herdado snowflake_region.account_locator tenha suporte atualmente para identificar uma conta em comandos de replicação e failover, seu uso não é recomendado, pois pode parar de funcionar no futuro.

Executado no banco de dados secundário¶

1. No banco de dados secundário, consulte a função da tabela DATABASE_REFRESH_PROGRESS (no Snowflake Information Schema). Observe o snapshot_transaction_timestamp na coluna DETAILS para a fase PRIMARY_UPLOADING_DATA. Este é o carimbo de data/hora para o último instantâneo do banco de dados primário.

   select parse_json(details)['snapshot_transaction_timestamp']
   from table(information_schema.database_refresh_progress(mydb))
   where phase_name = 'PRIMARY_UPLOADING_DATA';
   

   Copy

2. Consulte a função HASH_AGG para uma tabela específica. A seguinte consulta retorna um valor de hash para todas as linhas da tabela mytable:

   SELECT HASH_AGG( * ) FROM mytable;
   

   Copy

Executado no banco de dados primário¶

3. No banco de dados primário, consulte a função HASH_AGG para a mesma tabela. 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 => '<snapshot_transaction_timestamp>'::TIMESTAMP);
   

   Copy

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