Considerações sobre a replicação

Este tópico descreve o comportamento de certos recursos do Snowflake em bancos de dados e objetos secundários quando replicados com grupos de replicação e failover ou replicação de banco de dados, e fornece orientação geral para trabalhar com objetos e dados replicados.

Se você tiver ativado anteriormente a replicação de banco de dados para bancos de dados individuais usando o comando ALTER DATABASE … ENABLE REPLICATION TO ACCOUNTS, consulte Considerações sobre a replicação de banco de dados para obter considerações adicionais específicas sobre a replicação de banco de dados.

Neste tópico:

Restrições do grupo de replicação e grupo de failover

As seções a seguir explicam as restrições em torno da adição de objetos de conta, bancos de dados e compartilhamentos a grupos de replicação e failover.

Banco de dados e objetos compartilhados

As seguintes restrições se aplicam ao banco de dados e aos objetos compartilhados:

  • Um objeto só pode estar em um grupo de failover.

  • Um objeto pode estar em vários grupos de replicação desde que cada grupo seja para uma conta de destino diferente.

  • Um objeto não pode estar em um grupo de failover e em um grupo de replicação.

  • Objetos secundários (réplicas) não podem ser adicionados a um grupo primário de replicação ou failover.

Objetos de conta

Uma conta só pode ter um grupo de failover ou replicação que contenha objetos diferentes de bancos de dados ou compartilhamentos.

Privilégios de replicação

Esta seção descreve os privilégios de replicação que estão disponíveis para serem concedidos a funções para especificar as operações que os usuários podem realizar nos objetos do grupo de replicação ou failover no sistema. Para a sintaxe do comando GRANT, consulte GRANT <privilégios>.

Nota

Para a replicação de banco de dados, somente administradores de conta com a função ACCOUNTADMIN podem habilitar e gerenciar a replicação e o failover do banco de dados. Para obter informações adicionais sobre privilégios exigidos para replicação de banco de dados, consulte a tabela de privilégios exigidos em Etapa 6. Atualizar um banco de dados secundário em um cronograma.

Privilégio

Objeto

Uso

Notas

OWNERSHIP

Grupo de replicação

Grupo de failover

Permite excluir, alterar e conceder ou revogar acesso a um objeto.

Pode ser concedido por:

A função ACCOUNTADMIN ou

Uma função que tem o privilégio MANAGE GRANTS ou

Uma função que tem o privilégio OWNERSHIP sobre o grupo.

CREATE REPLICATION GROUP

Conta

Permite criar um grupo de replicação.

Deve ser concedido pela função ACCOUNTADMIN.

CREATE FAILOVER GROUP

Conta

Permite criar um grupo de failover.

Deve ser concedido pela função ACCOUNTADMIN.

FAILOVER

Grupo de failover

Permite promover um grupo secundário de failover para servir como grupo primário de failover.

Pode ser concedido ou revogado por uma função com o privilégio OWNERSHIP sobre o grupo.

REPLICATE

Grupo de replicação

Grupo de failover

Permite atualizar um grupo secundário.

Pode ser concedido ou revogado por uma função com o privilégio OWNERSHIP sobre o grupo.

MODIFY

Grupo de replicação

Grupo de failover

Concede a capacidade de alterar as configurações ou propriedades de um objeto.

Pode ser concedido ou revogado por uma função com o privilégio OWNERSHIP sobre o grupo.

MONITOR

Grupo de replicação

Grupo de failover

Permite ver detalhes dentro de um objeto.

Pode ser concedido ou revogado por uma função com o privilégio OWNERSHIP sobre o grupo.

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.

Replicação e referências entre grupos de replicação

Objetos em um grupo de replicação (ou failover) que têm referências pendentes (ou seja, referências a objetos em outro grupo de replicação ou failover) podem ser replicados com sucesso para uma conta de destino em algumas circunstâncias. Se a operação de replicação resultar em um comportamento na conta de destino consistente com o comportamento que pode ocorrer na conta de origem, a replicação é bem-sucedida.

Por exemplo, se uma coluna em uma tabela em um grupo de failover fg_a faz referência a uma sequência em um grupo de failover fg_b, a replicação de ambos os grupos é bem-sucedida. Se fg_a for replicado antes de fg_b, inserir operações (após o failover) na tabela que faz referência à sequência apresenta falha se fg_b não for replicado. Esse comportamento pode ocorrer em uma conta de origem. Se uma sequência for descartada em uma conta de origem, inserir operações em uma tabela com uma coluna que faz referência à sequência descartada apresenta falha.

Quando a referência pendente é uma política de segurança que protege os dados, o grupo de replicação (ou failover) com a política de segurança deve ser replicado antes que qualquer grupo de replicação que contenha objetos que fazem referência à política seja replicado.

Atenção

Fazer atualizações nas políticas de segurança que protegem os dados em grupos de replicação ou failover separados pode resultar em inconsistências e deve ser feito com cuidado.

Para objetos de banco de dados, você pode visualizar as dependências de objetos no Account Usage Exibição OBJECT_DEPENDENCIES.

Fluxos

Referências pendentes para fluxos fazem com que a replicação falhe com a seguinte mensagem de erro:

Primary database: the source object ''<object_name>'' for this stream ''<stream_name>'' is not included in the replication group.
Stream replication does not support replication across databases in different replication groups. Please see Streams Documentation
https://docs.snowflake.com/en/user-guide/account-replication-considerations#replication-and-streams for options.
Copy

Para evitar erros de referências pendentes:

  • O banco de dados primário deve incluir o fluxo e seu objeto base ou

  • O banco de dados que contém o fluxo e o banco de dados que contém o objeto base referenciado pelo fluxo devem ser incluídos no mesmo grupo de replicação ou failover.

Políticas de rede

Referências pendentes em políticas de redes podem fazer com que a replicação falhe com a seguinte mensagem de erro:

Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities])
Copy

Para evitar referências pendentes, especifique os seguintes tipos de objetos na lista OBJECT_TYPES ao executar o comando CREATE ou ALTER para o grupo de replicação ou failover:

  • Se uma política de redes estiver associada à conta, inclua NETWORK POLICIES e ACCOUNT PARAMETERS na lista OBJECT_TYPES.

  • Se uma política de redes estiver associada ao usuário, inclua USERS na lista OBJECT_TYPES.

Para obter mais detalhes, consulte Políticas de rede no tópico Replicação de integrações de segurança e políticas de redes em múltiplas contas.

Replicação e objetos secundários somente leitura

Todos os objetos secundários em uma conta de destino, incluindo compartilhamentos e bancos de dados secundários, são somente leitura. As alterações em objetos replicados ou tipos de objeto não podem ser feitas localmente em uma conta de destino. Por exemplo, se o tipo de objeto USERS for replicado de uma conta de origem para uma conta de destino, novos usuários não poderão ser criados ou modificados na conta de destino.

Novos bancos de dados e compartilhamentos locais podem ser criados e modificados em uma conta de destino. Se ROLES também forem replicadas para a conta de destino, novas funções não poderão ser criadas ou modificadas nessa conta de destino. Por isso, os privilégios não podem ser concedidos a uma função (ou revogados dela) em um objeto secundário na conta de destino. Entretanto, os privilégios podem ser concedidos a uma função secundária (ou revogados dela) em objetos locais (por exemplo, bancos de dados, compartilhamentos ou grupos de replicação ou failover) criados na conta de destino.

Replicação e objetos em contas de destino

Se você criar objetos de conta, por exemplo, usuários e funções, em sua conta de destino por qualquer forma diferente de replicação (por exemplo, usando scripts), esses usuários e funções não terão um identificador global por padrão. 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.

Para evitar descartar esses objetos, consulte Aplicação de IDs globais a objetos criados por scripts em contas de destino.

Políticas de replicação e segurança

O banco de dados contendo uma política de segurança e as referências (ou seja, atribuições) pode ser replicado usando grupos de replicação e de failover. As políticas de segurança incluem:

Se você estiver usando replicação de banco de dados, consulte Políticas de segurança e replicação de banco de dados.

Políticas de sessão e senhas

As referências da política de sessão e senha para os usuários são replicadas ao especificar o banco de dados contendo a política (ALLOWED_DATABASES = policy_db) e USERS em um grupo de replicação ou grupo de failover.

Se os usuários ou banco de dados da política já tiverem sido replicados para uma conta de destino, atualize o grupo de replicação ou failover na conta de origem para incluir os bancos de dados e os tipos de objetos necessários para replicar com sucesso a política. Em seguida, execute uma operação de atualização para atualizar a conta de destino.

Se as políticas em nível de usuário não estiverem em uso, USERS não precisam ser incluídos no grupo de replicação ou failover.

Nota

A política deve estar na mesma conta que a atribuição da política em nível de conta e a atribuição da política em nível de usuário.

Se você tiver uma política de sessão ou de senhas definida na conta ou um usuário na conta e não atualizar o grupo de replicação ou failover para incluir o policy_db contendo a política e USERS, uma referência pendente ocorre na conta de destino. Neste caso, uma referência pendente significa que o Snowflake não consegue localizar a política na conta de destino porque o nome totalmente qualificado da política aponta para o banco de dados na conta de origem. Consequentemente, a conta ou usuários de destino na conta de destino não são obrigados a cumprir com a política de sessão ou a política de senhas.

Para replicar com sucesso uma política de segurança, verifique se o grupo de replicação ou failover inclui os tipos de objetos e bancos de dados necessários para evitar uma referência pendente.

Replicação e clonagem

Os objetos clonados são replicados fisicamente em vez de logicamente em bancos de dados secundários. Ou seja, tabelas clonadas em um banco de dados padrão não contribuem para o armazenamento geral de dados a menos que ou até que operações DML no clone adicionem ou modifiquem os dados existentes. Entretanto, quando uma tabela clonada é replicada para um banco de dados secundário, os dados físicos também são replicados, aumentando o uso do armazenamento de dados para sua conta.

Replicação e clustering automático

Em um banco de dados primário, o Snowflake monitora tabelas clusterizadas usando Clustering automático e repete o clustering conforme necessário. Como parte de uma operação de atualização, tabelas clusterizadas são replicadas para um banco de dados secundário com a classificação atual de micropartições de tabela. Por isso, o reclustering não é executado novamente nas tabelas clusterizadas no banco de dados secundário, o que seria redundante.

Se um banco de dados secundário contém tabelas clusterizadas e o banco de dados é promovido para se tornar o banco de dados primário, o Snowflake inicia o clustering automático das tabelas neste banco de dados, suspendendo simultaneamente o monitoramento das tabelas clusterizadas no banco de dados primário anterior.

Consulte Replicação e exibições materializadas (neste tópico) para obter mais informações sobre clustering automático para exibições materializadas.

Replicação e tabelas grandes e de alta rotatividade

Quando uma ou mais linhas de uma tabela são atualizadas ou excluídas, todas as micropartições impactadas que armazenam esses dados em um banco de dados primário são recriadas e devem ser sincronizadas com bancos de dados secundários. Para tabelas grandes e de alta rotatividade, os custos de replicação podem ser significativos.

Para tabelas grandes, de alta rotatividade e com custos de replicação significativos, estão disponíveis as seguintes mitigações:

  • Replicar quaisquer bancos de dados primários que armazenem tais tabelas em uma frequência menor.

  • Mudar seu modelo de dados para reduzir a rotatividade.

Para obter mais informações, consulte Gerenciamento de custos para tabelas grandes e de alta rotatividade.

Replicação e Time Travel

Dados do Time Travel e Fail-safe são mantidos independentemente para um banco de dados secundário e não são replicados a partir de um banco de dados primário. Consultar tabelas e exibições em um banco de dados secundário usando o Time Travel pode produzir resultados diferentes dos obtidos ao executar a mesma consulta no banco de dados primário.

Dados históricos

Os dados históricos disponíveis para consulta em um banco de dados primário usando Time Travel não são replicados para bancos de dados secundários.

Por exemplo, suponha que dados sejam carregados continuamente em uma tabela a cada 10 minutos usando o Snowpipe, e um banco de dados secundário é atualizado a cada hora. A operação de atualização replica apenas a última versão da tabela. Embora cada versão horária da tabela dentro da janela de retenção esteja disponível para consulta usando o Time Travel, nenhuma das versões iterativas dentro de cada hora (as cargas individuais do Snowpipe) está disponível.

Período de retenção de dados

O período de retenção de dados para tabelas em um banco de dados secundário começa quando o banco de dados secundário é atualizado com as operações DML (ou seja, alteração ou exclusão de dados) gravadas em tabelas no banco de dados primário.

Nota

O parâmetro do período de retenção de dados, DATA_RETENTION_TIME_IN_DAYS, só é replicado para objetos do banco de dados secundário, não para o próprio banco de dados. Para obter mais detalhes sobre a replicação de parâmetros, consulte Parâmetros.

Replicação e exibições materializadas

Em um banco de dados primário, o Snowflake realiza a manutenção automática em segundo plano de exibições materializadas. Quando uma tabela base muda, todas as exibições materializadas definidas na tabela são atualizadas por um serviço de fundo que utiliza recursos de computação fornecidos pelo Snowflake. Além disso, se o clustering automático estiver habilitado para uma exibição materializada, então a exibição é monitorada e reclusterizada conforme necessário em um banco de dados primário.

Uma operação de atualização replica as definições da exibição materializada para um banco de dados secundário; os dados da exibição materializada não são replicados. A manutenção automática em segundo plano de exibições materializadas em um banco de dados secundário está habilitada por padrão. Se o clustering automático estiver habilitado para uma exibição materializada em um banco de dados primário, o monitoramento automático e o reclustering da exibição materializada no banco de dados secundário também estarão habilitados.

Nota

Os encargos da sincronização automatizada em segundo plano de exibições materializadas são faturados para cada conta que contém um banco de dados secundário.

Replicação e tabelas externas

Tabelas externas em um banco de dados primário

As tabelas externas em um banco de dados primário atualmente fazem com que a operação de replicação ou atualização falhe com a seguinte mensagem de erro:

003906 (55000): SQL execution error:
Primary database contains an external table '<database_name>'. Replication of a database with external table is not supported
Copy

Para evitar este erro, mova as tabelas externas para um banco de dados separado que não seja replicado. Alternativamente, se você estiver migrando seus bancos de dados para outra conta, você pode clonar o banco de dados primário, descartar a tabela externa do clone e então replicar o banco de dados clonado. Depois de promover o banco de dados secundário na conta de destino, você precisa recriar as tabelas externas no banco de dados.

Tabelas externas em um banco de dados secundário

Tabelas externas podem existir em um banco de dados secundário se ele era o banco de dados primário em um tempo anterior e as tabelas externas foram criadas durante esse tempo. Quando outro banco de dados é promovido para ser o banco de dados primário designado, ele se torna um banco de dados secundário. As tabelas externas em um banco de dados secundário atualmente causam a falha da operação de atualização com o seguinte erro:

003958 (55000): SQL execution error:
Secondary database contains an external table '<table_name>'. Replication of a database with external table is not supported.
Copy

Para evitar este erro, mova a tabela externa para um banco de dados separado que não seja um banco de dados secundário replicado.

Replicação e Snowpipe Streaming

Uma tabela preenchida por Snowpipe Streaming em um banco de dados primário é replicada para o banco de dados secundário em uma conta de destino.

No banco de dados primário, as tabelas são criadas e as linhas são inseridas por meio de canais. Tokens offset rastreiam o progresso da ingestão. Uma operação de atualização replica o objeto de tabela, os dados da tabela e os offsets do canal associados à tabela do banco de dados primário para o banco de dados secundário.

  • As operações somente leitura do Snowflake Streaming para recuperar offsets estão disponíveis nas contas de origem e destino:

  • As operações de gravação do Snowflake Streaming estão disponíveis apenas na conta de origem:

Como evitar a perda de dados

Para evitar perda de dados no caso de failover, o tempo de retenção de dados para linhas inseridas com êxito em sua fonte de dados a montante deve ser maior que a frequência de replicação. Se os dados forem inseridos em uma tabela em um banco de dados primário e o failover ocorrer antes que os dados possam ser replicados para o banco de dados secundário, os mesmos dados precisarão ser inseridos na tabela no banco de dados primário recém-promovido. O resultado a seguir é um exemplo de cenário:

  1. A tabela t1 no banco de dados primário repl_db é preenchida com dados com Snowpipe Streaming e o conector Kafka.

  2. O offsetToken é 100 para o canal 1 e 100 para o canal 2 para t1 no banco de dados primário.

  3. Uma operação de atualização é concluída com êxito na conta de destino.

  4. O offsetToken é 100 para o canal 1 e 100 para o canal 2 para o t1 no banco de dados secundário.

  5. Mais linhas são inseridas em t1 no banco de dados primário.

  6. O offsetToken agora é 200 para o canal 1 e 200 para o canal 2 para o t1 no banco de dados primário.

  7. Um failover ocorre antes que as linhas adicionais e os novos offsets de canal possam ser replicados para o banco de dados secundário.

Neste caso, faltam 100 offsets em cada canal para tabela t1 no banco de dados primário recém-promovido. Para inserir os dados que faltam, consulte Reabertura de canais ativos para Snowpipe Streaming na conta de origem recém-promovida.

Requisitos

O suporte à replicação do Snowpipe Streaming requer as seguintes versões mínimas:

  • Snowflake Ingest SDK versão 1.1.1 e posterior

  • Se você estiver usando o conector Kafka: conector Kafka versão 1.9.3 e posterior

Limitações

A replicação com fluxos em tabelas Snowflake preenchidas por Snowpipe Streaming não está habilitada. Se você deseja replicar fluxos em tabelas Snowflake preenchidas por Snowpipe Streaming, entre em contato com o suporte Snowflake.

Replicação de procedimentos armazenados e funções definidas pelo usuário (UDFs)

Os procedimentos armazenados e UDFs são replicados de um banco de dados primário para bancos de dados secundários.

Note que a replicação do estágio ainda não é suportada. Se um procedimento armazenado ou UDF depender de arquivos em um estágio (por exemplo, se o procedimento armazenado for definido em código Python que é carregado de um estágio), você deve replicar manualmente o estágio e seus arquivos para o banco de dados secundário.

Por exemplo, se um banco de dados primário tem um UDF de Python in-line que importa qualquer código armazenado em um estágio, o UDF é replicado para um banco de dados secundário, mas não funciona até que o estágio e o código importado sejam replicados manualmente no banco de dados secundário.

Replicação e fluxos

Esta seção descreve práticas recomendadas e áreas potenciais de preocupação ao replicar fluxos em Replicação de bancos de dados em várias contas ou Replicação de contas e Failover/Failback.

Objetos de origem compatíveis com fluxos

Os fluxos replicados podem rastrear com sucesso os dados de alteração para tabelas e exibições no mesmo banco de dados.

Atualmente, os seguintes tipos de objetos de origem não têm suporte:

  • Tabelas de diretório

  • Tabelas externas

  • Tabelas ou exibições em bancos de dados separados dos bancos de dados do fluxo.

    Note que esse design funciona se tanto o banco de dados do fluxo quanto o banco de dados que armazena o objeto de origem estão incluídos no mesmo grupo de replicação ou failover.

  • Tabelas ou exibições em bancos de dados compartilhados (ou seja, bancos de dados compartilhados a partir das contas de provedor para sua conta)

Uma operação de atualização ou replicação de banco de dados falha se o banco de dados primário incluir um fluxo com um objeto de origem incompatível. A operação também falha se o objeto de origem para qualquer fluxo tiver sido descartado.

Como evitar a duplicação de dados

Nota

Além do cenário descrito nesta seção, os fluxos em um banco de dados secundário podem retornar linhas duplicadas na primeira vez em que são incluídos em uma operação de atualização. Nesse caso, linhas duplicadas referem-se a uma única linha com vários valores de coluna METADATA$ACTION.

Após a operação inicial de atualização, é improvável você encontrar esse problema específico em um banco de dados secundário.

A duplicação de dados ocorre quando operações DML gravam os mesmos dados de alteração de um fluxo várias vezes sem uma verificação de exclusividade. Isso pode ocorrer se um fluxo e uma tabela de destino para os dados de alteração de fluxo forem armazenados em bancos de dados separados, e esses bancos de dados não passarem por uma replicação e failover no mesmo grupo.

Por exemplo, suponha que você insira regularmente dados de alteração de fluxo s na tabela dt. (Para este exemplo, o objeto de origem do fluxo não importa). Bancos de dados separados armazenam o fluxo e a tabela de destino.

  1. No carimbo de data/hora t1, uma linha é inserida na tabela de origem para o fluxo s, criando uma nova versão da tabela. O fluxo armazena o offset para essa versão de tabela.

  2. No carimbo de data/hora t2, o banco de dados secundário que armazena o fluxo é atualizado. O fluxo replicado s agora armazena o offset.

  3. No carimbo de data/hora t3, os dados de alteração do fluxo s são inseridos na tabela dt.

  4. No carimbo de data/hora t4, o banco de dados secundário que armazena o fluxo s passa por um failover.

  5. No carimbo de data/hora t5, os dados de alteração do fluxo s são inseridos novamente na tabela dt.

Para evitar essa situação, faça a replicação e o failover, juntos, dos bancos de dados que armazenam os fluxos e suas tabelas de destino.

Referências de fluxo na cláusula WHEN da tarefa

Para evitar um comportamento inesperado ao executar tarefas replicadas que se referem a fluxos na cláusula WHEN boolean_expr, recomendamos que você:

  • Crie as tarefas e fluxos no mesmo banco de dados, ou

  • Se os fluxos forem armazenados em um banco de dados diferente das tarefas que os referenciam, inclua ambos os bancos de dados no mesmo grupo de failover.

Se uma tarefa faz referência a um fluxo em um banco de dados separado, e ambos os bancos de dados não estão incluídos no mesmo grupo de failover, então o banco de dados que contém a tarefa pode passar por um failover sem o banco de dados que contém o fluxo. Nesse cenário, quando a tarefa é retomada no banco de dados com failover, ela registra um erro quando tenta executar e não consegue encontrar o fluxo referenciado. Esse problema pode ser resolvido com o failover do banco de dados que contém o fluxo ou com a recriação do banco de dados e do fluxo na mesma conta que o banco de dados com failover que contém a tarefa.

Desatualização de fluxo

Se um fluxo no banco de dados primário se tornou desatualizado, o fluxo replicado em um banco de dados secundário também está desatualizado e não pode ser consultado nem seus dados de alteração consumidos. Para resolver isso, recrie o fluxo no banco de dados primário (usando CREATE OR REPLACE STREAM). Quando o banco de dados secundário é atualizado, o fluxo replicado fica legível novamente.

Observe que o offset para um fluxo recriado é a versão atual da tabela por padrão. Você pode recriar um fluxo que aponta para uma versão anterior da tabela usando o Time Travel; no entanto, o fluxo replicado permaneceria ilegível. Para obter mais informações, consulte Replicação de fluxo e Time Travel (neste tópico).

Replicação de fluxo e Time Travel

Após o failover de um banco de dados primário, se um fluxo no banco de dados usar o Time Travel para ler uma versão de tabela para o objeto de origem a partir de um ponto no tempo antes do último carimbo de data/hora da atualização, o fluxo replicado não pode ser consultado nem os dados de alteração consumidos. Da mesma forma, consultar os dados de alteração de um objeto de origem a partir de um ponto no tempo antes do último carimbo de data/hora da atualização usando a cláusula CHANGES para as instruções SELECT apresenta falha com um erro.

Isso porque uma operação de atualização reúne o histórico da tabela em uma única versão de tabela. As versões de tabelas iterativas criadas antes do carimbo de data/hora da atualização não são preservadas no histórico da tabela para os objetos de origem replicados.

Considere o seguinte exemplo:

Stream replication and Time Travel
  1. A tabela t1 é criada no banco de dados primário com o rastreamento de alterações ativado (versão da tabela tv0). As transações DML subsequentes criam as versões de tabela tv1 e tv2.

  2. Um banco de dados secundário que contém a tabela t1 é atualizado. A versão de tabela para essa tabela replicada é tv2; entretanto, o histórico da tabela não é replicado.

  3. Um fluxo é criado no banco de dados primário com seu offset definido para a versão de tabela tv1 usando o Time Travel.

  4. O banco de dados secundário passa por um failover, tornando-se o banco de dados primário.

  5. A consulta do fluxo s1 retorna um erro, porque a versão de tabela tv1 não está no histórico da tabela.

Observe que quando uma transação DML subsequente na tabela t1 itera a versão da tabela para tv3, o offset para o fluxo s1 é avançado. O fluxo fica legível novamente.

Como evitar a perda de dados

A perda de dados pode ocorrer quando a mais recente operação de atualização de um banco de dados secundário não é concluída antes da operação de failover. Recomendamos atualizar frequentemente seus bancos de dados secundários para minimizar o risco.

Replicação e tarefas

Esta seção descreve a replicação de tarefas em Replicação de bancos de dados em várias contas ou Replicação de contas e Failover/Failback.

Cenários de replicação

A tabela a seguir descreve diferentes cenários de tarefas e especifica se as tarefas são replicadas ou não. Exceto onde observado, os cenários dizem respeito tanto a tarefas independentes quanto a tarefas em um DAG:

Cenário

Replicado

Notas

A tarefa foi criada e retomada ou executada manualmente (usando EXECUTE TASK). A retomada ou execução de uma tarefa cria uma versão inicial da tarefa.

A tarefa foi criada, mas nunca foi retomada ou executada.

A tarefa foi recriada (usando CREATE OR REPLACE TASK, mas nunca foi retomada ou executada.

A última versão antes de a tarefa ter sido recriada é replicada.

Retomar ou executar manualmente a tarefa confirma uma nova versão. Quando o banco de dados é replicado novamente, a nova versão, ou a mais recente, é replicada para o banco de dados secundário.

A tarefa foi criada e retomada ou executada, posteriormente modificada (usando ALTER TASK), mas não retomada ou executada novamente.

Retomar ou executar manualmente uma tarefa confirma uma nova versão que inclui mudanças nos parâmetros da tarefa. Como as novas mudanças nunca foram confirmadas, a última versão antes de a tarefa ter sido suspensa e modificada é replicada.

Observe que se a tarefa modificada não for retomada dentro de um período de retenção (atualmente 30 dias), a última versão da tarefa é descartada. Após esse período, a tarefa não é replicada para um banco de dados secundário, a menos que seja retomada novamente.

A tarefa independente foi criada e retomada ou executada, mas posteriormente descartada.

A tarefa raiz em um DAG foi criada e retomada ou executada, mas foi posteriormente suspensa e descartada.

O DAG inteiro não é replicado para um banco de dados secundário.

A tarefa secundária em um DAG é criada e retomada ou executada, mas é subsequentemente suspensa e descartada.

A última versão do DAG (antes que a tarefa fosse suspensa e descartada) é replicada para um banco de dados secundário.

Estado retomado ou suspenso das tarefas replicadas

Se todas as condições seguintes forem cumpridas, uma tarefa é replicada para um banco de dados secundário em estado retomado:

  • Uma tarefa independente ou tarefa raiz está em um estado retomado no banco de dados primário quando a operação de replicação ou de atualização começa até que a operação seja concluída. Se uma tarefa estiver em um estado retomado durante apenas parte desse período, ela ainda poderá ser replicada em um estado retomado.

    Uma tarefa secundária está em um estado retomado na última versão da tarefa.

  • O banco de dados primário foi replicado para a conta de destino juntamente com objetos de função no mesmo, ou em um diferente, grupo de replicação ou failover.

    Após as funções e o banco de dados serem replicados, você deve atualizar os objetos na conta de destino, executando ALTER REPLICATION GROUP … REFRESH or ALTER FAILOVER GROUP … REFRESH, respectivamente. Se você atualizar o banco de dados executando ALTER DATABASE … REFRESH, o estado das tarefas no banco de dados é alterado para suspenso.

    Uma operação de replicação ou atualização inclui a concessão de privilégios para uma tarefa que era atual quando a última versão da tabela foi confirmada. Para obter mais informações, consulte Tarefas replicadas e concessões de privilégios (neste tópico).

Se essas condições não forem cumpridas, a tarefa é replicada para um banco de dados secundário em estado suspenso.

Nota

Todas as tarefas secundárias são suspensas, independentemente de seu state. Para obter mais detalhes, consulte Execuções de tarefas após um failover

Tarefas replicadas e concessões de privilégios

Se o banco de dados primário foi replicado para uma conta de destino juntamente com objetos de função no mesmo grupo de replicação ou failover, ou em um grupo diferente, os privilégios concedidos sobre as tarefas no banco de dados também são replicados.

A lógica a seguir determina quais privilégios de tarefa são replicados em uma operação de replicação ou de atualização:

  • Se o atual proprietário da tarefa (ou seja, a função que tem o privilégio OWNERSHIP sobre uma tarefa) tem a mesma função de quando a tarefa foi retomada por último, então todas as concessões atuais sobre a tarefa são replicadas para o banco de dados secundário.

  • Se o atual proprietário da tarefa não tem a mesma função de quando a tarefa foi retomada por último, então apenas o privilégio OWNERSHIP concedido à função do proprietário na versão da tarefa é replicado para o banco de dados secundário.

  • Se a função atual do proprietário da tarefa não estiver disponível (por exemplo, uma tarefa secundária é descartada, mas uma nova versão da tarefa DAG ainda não está confirmada), então apenas o privilégio OWNERSHIP concedido à função do proprietário na versão da tarefa é replicado para o banco de dados secundário.

Execuções de tarefas após um failover

Depois que um grupo secundário de failover é promovido para servir como grupo primário, as tarefas retomadas em bancos de dados dentro do grupo de failover são programadas gradualmente. O tempo necessário para restaurar a programação normal de todas as tarefas independentes retomadas e DAGs depende do número de tarefas retomadas em um banco de dados.

Replicação e tags

As tags e suas atribuições podem ser replicadas de uma conta de origem para uma conta de destino.

As atribuições de tags não podem ser modificadas na conta de destino após a replicação inicial a partir da conta de origem. Por exemplo, não é permitido colocar uma tag em um banco de dados secundário (por exemplo, replicado). Para modificar as atribuições de tags na conta de destino, modifique-as na conta de origem e replique-as na conta de destino.

Para replicar as tags com sucesso, certifique-se de que o grupo de replicação ou failover inclua:

  • O banco de dados que contém as tags na propriedade ALLOWED_DATABASES.

  • Outros objetos de nível de conta que tenham uma tag na propriedade OBJECT_TYPES (por exemplo ROLES, WAREHOUSES).

    Para obter mais detalhes, consulte CREATE REPLICATION GROUP e CREATE FAILOVER GROUP.

Dados de uso histórico

Os dados de uso histórico para a atividade em um banco de dados primário não são replicados para bancos de dados secundários. Cada conta tem seu próprio histórico de consultas, histórico de login, etc.

Os dados de uso histórico incluem os dados de consulta retornados pelas seguintes funções de tabela do Snowflake Information Schema ou exibições de Account Usage:

  • COPY_HISTORY

  • LOGIN_HISTORY

  • QUERY_HISTORY

  • etc.