Replicação de objetos de conta¶
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.
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');
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¶
Crie uma função e conceda o privilégio CREATE FAILOVER GROUP. Essa etapa é opcional:
-- Execute the following SQL statements using the ACCOUNTADMIN role: USE ROLE ACCOUNTADMIN; CREATE ROLE myrole; GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;
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; -- 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 ALLOWED_DATABASES = db1, db2 ALLOWED_ACCOUNTS = myorg.myaccount2, myorg.myaccount3 REPLICATION_SCHEDULE = '10 MINUTE';
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 Etapa 5. Aplicar IDs globais a objetos criados por scripts em contas de destino — Opcional.
Executado na conta de destino¶
Crie uma função na conta de destino e conceda o privilégio CREATE FAILOVER GROUP. Essa etapa é opcional:
-- Execute the following SQL statements using the ACCOUNTADMIN role: USE ROLE ACCOUNTADMIN; CREATE ROLE myrole; GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;
Crie um grupo de failover na conta de destino como uma réplica do grupo de failover 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 AS REPLICA OF myorg.myaccount1.myfg;
Aplique IDs globais aos objetos. Essa é uma etapa opcional para qualquer objeto de conta não criado via replicação.
-- Execute the following SQL statements using the ACCOUNTADMIN role: SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');
Atenção
Essa etapa deve ser executada se houver objetos de conta (por exemplo, usuários ou funções) na conta de destino que você não deseja descartar durante a replicação. Pular essa etapa pode resultar na perda de planilhas de usuário ou concessões de privilégios a funções em objetos (por exemplo, compartilhamentos). Para obter mais detalhes, consulte Etapa 5. Aplicar IDs globais a objetos criados por scripts em contas de destino — Opcional.
Atualização de um grupo secundário manualmente¶
Para atualizar manualmente um grupo secundário de failover na conta de destino, consulte Atualização de um grupo secundário de failover em uma conta de destino manualmente (neste tópico).
Nota
Como prática recomendada, o Snowflake indica a programação de atualizações automáticas usando o parâmetro REPLICATION_SCHEDULE. Consulte Cronograma de replicação (neste tópico).
Replicação de objetos de contas 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.
-- Assume the ORGADMIN role
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');
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).
Habilitação da versão preliminar de replicação de fluxo e tarefa — Opcional¶
Para ativar a versão preliminar de replicação do fluxo e replicação de tarefas para uma conta, banco de dados ou grupo de replicação ou failover, defina o parâmetro ENABLE_STREAM_TASK_REPLICATION como true
para a conta de origem ou objeto principal.
Exemplos¶
Os exemplos a seguir devem ser executados na conta de origem.
Habilitar replicação de fluxo e tarefa para um banco de dados mydb
:
alter database mydb set ENABLE_STREAM_TASK_REPLICATION = true;
Habilitar replicação de fluxo e tarefa para um grupo de replicação myrg
:
alter replication group myrg set ENABLE_STREAM_TASK_REPLICATION = true;
Habilitar replicação de fluxo e tarefa para conta myaccount
na organização myorg
:
alter account myorg.myaccount set ENABLE_STREAM_TASK_REPLICATION = true;
Nota
O parâmetro não pode ser definido para um banco de dados se o banco de dados estiver incluído em um grupo de replicação ou de failover.
Se o parâmetro for explicitamente definido em um objeto de banco de dados que não esteja incluído em um grupo de replicação ou failover, você deverá desajustar o parâmetro antes de adicioná-lo a um grupo de replicação ou failover, caso contrário, a operação de replicação falhará.
Os parâmetros definidos no banco de dados, grupo de replicação ou grupo de failover substituem os parâmetros definidos na conta. Para obter mais detalhes, consulte Parameter Hierarchy and Types e Object Parameters.
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.
-- Execute the following SQL statements using the ACCOUNTADMIN role:
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.
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.
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;
Veja todos os bancos de dados no grupo de failover myfg
:
SHOW DATABASES IN FAILOVER GROUP myfg;
Veja todos os compartilhamentos do grupo de failover myfg
:
SHOW SHARES IN FAILOVER GROUP myfg;
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.
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.
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';
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 Etapa 5. Aplicar IDs globais a objetos criados por scripts em contas de destino — Opcional.
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.
-- Execute the following SQL statements using the ACCOUNTADMIN role:
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;
-- Execute the following SQL statement using a role with the CREATE FAILOVER GROUP privilege:
CREATE FAILOVER GROUP myfg
AS REPLICA OF myorg.myaccount1.myfg;
Etapa 5. Aplicar IDs globais a objetos criados por scripts em contas de destino — Opcional¶
Atenção
Essa etapa deve ser executada se houver objetos de conta (por exemplo, usuários ou funções) na conta de destino que você não deseja descartar durante a replicação. Pular essa etapa pode resultar na perda de planilhas de usuário ou concessões de privilégios a funções em objetos (por exemplo, compartilhamentos).
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. 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
(por exemplo, users
ou roles
) na conta de destino que não tenha um identificador global.
Criação de grupos de replicação ou failover sem um cronograma de replicação¶
Quando uma replicação secundária ou grupo de failover é criado como uma réplica de uma replicação primária ou grupo de failover com um cronograma de replicação, uma atualização inicial do grupo secundário é executada automaticamente quando a replicação secundária ou grupo de failover é criado. A fim de evitar que isso aconteça antes que você possa executar as seguintes instruções, crie a replicação primária ou grupo de failover sem definir o parâmetro REPLICATION_SCHEDULE
.
Após a criação do grupo secundário na conta de destino, use a função SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME para adicionar identificadores globais aos objetos de conta na conta de destino. Para objetos de conta que existem somente na conta de destino, replique-os manualmente na conta de origem antes de chamar essa função.
Após aplicar identificadores globais aos objetos na conta de destino, ou recriá-los manualmente na conta de origem, use o comando ALTER REPLICATION GROUP ou ALTER FAILOVER GROUP para definir o cronograma de replicação para o grupo primário de replicação ou failover.
Usar SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME() para aplicar IDs globais¶
Nota
Os identificadores globais são adicionados apenas aos objetos de conta que estão incluídos em um grupo de replicação ou failover para os seguintes tipos de objetos:
RESOURCE_MONITOR
ROLE
USER
WAREHOUSE
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 the following SQL statements using the ACCOUNTADMIN role:
SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');
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:
Amazon Web Services Definir a relação de confiança entre o Snowflake e a nova função IAM.
Google Cloud Platform: criar uma política de segurança do GCP para o serviço de proxy.
Microsoft Azure:
Etapa 2. Criar uma política Validar JWT
Atualização de um grupo secundário de failover em uma conta de destino manualmente¶
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.
Conceder o privilégio REPLICATE sobre um grupo de failover a uma função — Opcional¶
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.
Executado a partir da conta de origem:
-- Execute the following SQL statements using a role with the OWNERSHIP privilege on the group: GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;Executado a partir da conta de destino:
-- Execute the following SQL statements using a role with the OWNERSHIP privilege on the group: GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
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; -- Execute the following SQL statements using a role with the REPLICATE privilege: ALTER FAILOVER GROUP myfg REFRESH;
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.
Monitorar o progresso de uma atualização de um grupo de replicação ou um grupo de failover¶
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'));
Histórico de replicação¶
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:
Função de tabela REPLICATION_GROUP_REFRESH_HISTORY (no Snowflake Information Schema).
Exibição REPLICATION_GROUP_REFRESH_HISTORY (em Account Usage).
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());
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).
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());
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.
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';
Observe a saída da soma dos bytes do banco de dados:
+--------------------+ | SUM_DATABASE_BYTES | |--------------------| | 22016 | +--------------------+
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';
Observe a saída da soma dos créditos utilizados e a soma dos bytes transferidos:
+--------------+-------------------+ | CREDITS_USED | BYTES_TRANSFERRED | |--------------+-------------------| | 1.357923604 | 22013 | +--------------+-------------------+
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.
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';
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' ));
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¶
Consulte a função de tabela REPLICATION_GROUP_REFRESH_PROGRESS (no Snowflake Information Schema). Observe o
primarySnapshotTimestamp
na colunaDETAILS
para a fasePRIMARY_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';
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;
Executado na conta de origem¶
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);
Compare os resultados das duas consultas. A saída deve ser idêntica.