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

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

  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

    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

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

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

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.

-- Execute the following SQL statements using the ACCOUNTADMIN role:
USE ROLE ACCOUNTADMIN;

CREATE ROLE myrole;

GRANT CREATE FAILOVER GROUP ON ACCOUNT
    TO ROLE myrole;
Copy

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

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

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

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

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

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

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

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

Aplicação de IDs globais a objetos criados por scripts em contas de destino

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.

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:

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

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:

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

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

Monitoramento dos custos de replicação

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

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

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

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.

  1. 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';
    
    Copy

    Observe a saída da soma dos bytes do banco de dados:

    +--------------------+
    | SUM_DATABASE_BYTES |
    |--------------------|
    |              22016 |
    +--------------------+
    
    Copy
  2. 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';
    
    Copy

    Observe a saída da soma dos créditos utilizados e a soma dos bytes transferidos:

    +--------------+-------------------+
    | CREDITS_USED | BYTES_TRANSFERRED |
    |--------------+-------------------|
    |  1.357923604 |             22013 |
    +--------------+-------------------+
    
    Copy
  3. 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.

  1. 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';
    
    Copy
  2. 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'
      ));
    
    Copy

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

  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

  1. 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
  2. Compare os resultados das duas consultas. A saída deve ser idêntica.

Descarte de um grupo secundário de replicação ou failover

Você pode descartar uma replicação ou failover secundário usando o comando DROP REPLICATION GROUP ou DROP FAILOVER GROUP. Somente o proprietário do grupo de replicação ou failover (ou seja, a função com o privilégio OWNERSHIP sobre o grupo) pode descartar o grupo.

Descarte de um grupo primário de replicação ou failover

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.