Considerações sobre a replicação¶

Objetos de compartilhamento e banco de dados¶

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.

Você só pode replicar compartilhamentos de saída. A replicação de compartilhamentos de entrada (compartilhamentos de provedores) não é suportada.

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.

Políticas de sessão e funções secundárias¶

Para obter mais detalhes, consulte Políticas de sessão com funções secundárias.

Referências pendentes e 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])

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 usar uma regra de rede, inclua o banco de dados que contém o esquema onde a regra de rede foi criada.

• 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 NETWORK POLICIES e USERS na lista OBJECT_TYPES.

Para obter mais detalhes, consulte Replicação de políticas de redes.

Referências pendentes e políticas de pacotes¶

Se houver uma política de pacotes definida na conta, o seguinte erro de referências pendentes ocorrerá durante a operação de atualização para um grupo de replicação ou failover que contém objetos de conta:

003131 (55000): Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities]):
POLICY '<policy_db>.<policy_schema>.<packages_policy_name>' <- [ACCOUNT '<account_locator>']

Para evitar referências pendentes, replique o banco de dados que contém a política de pacotes para a conta de destino. O banco de dados que contém a política pode estar no mesmo ou em um grupo de replicação ou failover diferente.

Referências pendentes e segredos¶

Para obter mais detalhes, consulte Replicação e segredos.

Referências pendentes e 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.

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.

Objetos recriados em contas de destino¶

Se um objeto existente na conta de origem for substituído usando uma instrução CREATE OR REPLACE, o objeto existente será descartado e, em seguida, um novo objeto com o mesmo nome será criado em uma única transação. Por exemplo, se você executar uma instrução CREATE OR REPLACE para uma tabela existente t1, a tabela t1 será descartada e, em seguida, uma nova tabela t1 será criada. Para obter mais informações, consulte as notas de uso para CREATE TABLE para.

Quando os objetos são substituídos na conta de destino, as instruções DROP e CREATE não são executadas atomicamente durante uma operação de atualização. Isso significa que o objeto pode desaparecer brevemente da conta de destino enquanto está sendo recriado como um novo objeto.

Políticas de sessão, senhas e autenticação¶

As referências da política de sessão, senha e autenticação 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.

Políticas de privacidade¶

Considere o seguinte ao replicar políticas de privacidade e tabelas e exibições protegidas por privacidade associadas à privacidade diferencial:

• Se uma política de privacidade for atribuída a uma tabela ou exibição na conta de origem, a política precisará ser replicada na conta de destino.

• A perda cumulativa de privacidade para um orçamento de privacidade não é replicada.

• A perda cumulativa de privacidade nas contas de destino e de origem é rastreada separadamente.

• Os administradores na conta de destino não podem ajustar o orçamento de privacidade replicado. O orçamento de privacidade é sincronizado com o da conta de origem.

• Se um analista tiver acesso à tabela ou exibição protegida por privacidade na conta de origem e na conta de destino, ele poderá incorrer no dobro da perda de privacidade antes de atingir o limite do orçamento de privacidade.

• Os domínios de privacidade definidos nas colunas também são replicados.

Políticas de sessão com funções secundárias¶

Se estiver usando políticas de sessão com funções secundárias, você deverá especificar o banco de dados da política no mesmo grupo de replicação que contém as funções. Por exemplo:

CREATE REPLICATION GROUP myrg
  OBJECT_TYPES = DATABASES, ROLES, USERS
  ALLOWED_DATABASES = session_policy_db
  ALLOWED_ACCOUNTS = myorg.myaccount
  REPLICATION_SCHEDULE = '10 MINUTE';

Se você especificar o banco de dados da política de sessão que faz referência a funções secundárias em um grupo de replicação ou failover diferente (rg2) do grupo de replicação ou failover que contém objetos em nível de conta (myrg) e você replicar ou fazer failover de rg2 primeiro, ocorrerá uma referência pendente. Uma mensagem de erro informa para você colocar o banco de dados da política de sessão no grupo de replicação ou grupo de failover que contém as funções. Esse comportamento ocorre quando a política de sessão é definida na conta ou nos usuários.

Se a política de sessão e os objetos no nível da conta estiverem em grupos de replicação diferentes e a política de sessão não estiver definida na conta ou nos usuários, você poderá replicar e atualizar a conta de destino. Certifique-se de atualizar primeiro o grupo de replicação que contém os objetos de nível de conta.

Se você atualizar a conta de destino após replicar ou executar failover da política de sessão com funções secundárias e objetos de função, a conta de destino refletirá o comportamento da política de sessão e das funções secundárias na conta de origem.

Além disso, quando você atualiza o banco de dados na conta de destino e o banco de dados contém uma política de sessão que faz referência a funções secundárias, ALLOWED_SECONDARY_ROLES sempre avalia como [ALL].

Replicação lógica de clones¶

Se a tabela original e a clonada estiverem inclusas no mesmo grupo de replicação ou failover, a tabela clonada poderá ser replicada logicamente para a conta de destino.

Por exemplo, se a tabela t2 no banco de dados db2 for um clone da tabela t1 no banco de dados db1 e ambos os bancos de dados estiverem inclusos no grupo de replicação rg1, a tabela t2 será criada como um clone lógico na conta de destino.

Um objeto clonado pode ser clonado para criar clones adicionais do objeto original. O objeto original e os objetos clonados fazem parte do mesmo grupo de clones. Por exemplo, se a tabela t3 no banco de dados db3 for criada como um clone de t2, ela estará no mesmo grupo de clones que a tabela original t1 e a tabela clonada t2.

Se o banco de dados db3 for adicionado posteriormente ao grupo de replicação rg1, a tabela t3 será criada na conta de destino como um clone lógico da tabela t1.

CREATE REPLICATION GROUP myrg
    OBJECT_TYPES = DATABASES
    ALLOWED_DATABASES = db1, db2
    ALLOWED_ACCOUNTS = myorg.myaccount2
    REPLICATION_SCHEDULE = '10 MINUTE';

Tabelas dinâmicas e grupos de replicação¶

Um banco de dados que contém uma tabela dinâmica pode ser replicado usando um grupo de replicação. Não é necessário que o(s) objeto(s) de origem do qual ele depende estejam no mesmo grupo de replicação.

Os objetos replicados em cada conta de destino são chamados de objetos secundários e são réplicas dos objetos primários na conta de origem. Os objetos secundários são somente leitura na conta de destino. Se um grupo de replicação secundário for descartado em uma conta de destino, os bancos de dados que estavam inclusos no grupo se tornarão de leitura/gravação. No entanto, quaisquer tabelas dinâmicas incluídas em um grupo de replicação permanecem somente leitura mesmo depois que o grupo secundário é descartado na conta de destino. Nenhuma atualização de DML ou tabela dinâmica pode ocorrer nessas tabelas dinâmicas somente leitura.

Tabelas dinâmicas e grupos de failover¶

Um banco de dados que contém uma tabela dinâmica pode ser replicado usando um grupo de failover. Se uma tabela dinâmica fizer referência a objetos de origem fora do grupo de failover ou da replicação do banco de dados, ela ainda poderá ser replicada. Após um failover, a tabela dinâmica resolve os objetos de origem usando a resolução de nomes durante a atualização. A atualização pode ser bem-sucedida ou falhar, dependendo do estado dos objetos de origem. Se for bem-sucedida, a tabela dinâmica será reinicializada com os dados mais recentes dos objetos de origem.

As tabelas dinâmicas secundárias são somente leitura e não são atualizadas. Após ocorrer um failover e uma tabela dinâmica secundária ser promovida a tabela dinâmica primária, a primeira atualização será uma reinicialização seguida por atualizações incrementais se a tabela dinâmica estiver configurada para atualização incremental de dados.

Exemplo: falha na atualização devido à falta de objetos de origem

Se uma tabela dinâmica depender de uma tabela de origem fora do grupo de failover, ela não poderá ser atualizada após um failover. No diagrama acima, a tabela dinâmica dt na conta primária é replicada para a conta secundária. dt depende de source_table, que não está inclusa no mesmo grupo de failover que a conta primária. Após o failover, a atualização na conta secundária falha porque source_table não pode ser resolvida.

Exemplo: atualização bem-sucedida quando os objetos de origem existem na conta secundária por meio de replicação separada

No diagrama acima, a tabela dinâmica dt depende de source_table. Tanto a dt quanto a source_table na conta primária são replicadas para a conta secundária por meio de grupos de failover independentes. Após a replicação e o failover, quando a dt é atualizada na conta secundária, a atualização é bem-sucedida porque a source_table pode ser encontrada por meio da resolução de nomes.

Exemplo: atualização bem-sucedida quando os objetos de origem existem localmente na conta secundária

No diagrama acima, a tabela dinâmica dt depende da source_table e é replicada por meio de um grupo de failover da conta primária para a conta secundária. Uma source_table é criada localmente na conta secundária. Após o failover, quando a dt1 é atualizada na conta secundária, a atualização pode ser bem-sucedida porque a source_table pode ser encontrada por meio da resolução de nomes.

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 upstream deve ser maior que o cronograma de replicação configurado. 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

O tempo de retenção de dados para linhas inseridas com êxito em sua fonte de dados upstream deve ser maior que o cronograma de replicação configurado. Se você estiver usando o conector Kafka, certifique-se de que a configuração de log.retention esteja definida com buffer suficiente.

Procedimentos armazenados e UDFs e estágios¶

Se um procedimento armazenado ou UDF depender de arquivos em um estágio (por exemplo, se o procedimento armazenado for definido no código Python que é carregado de um estágio), você deverá replicar manualmente o estágio e seus arquivos para o banco de dados secundário. Para obter mais informações sobre replicação de estágios, consulte Replicação de histórico de carregamento, canal e estágio.

Por exemplo, se um banco de dados primário tiver uma UDF de Python inline que importe qualquer código armazenado em um estágio, a UDF não funcionará a menos que o estágio e seu código importado sejam replicados no banco de dados secundário.

Procedimentos armazenados e UDFs e acesso à rede externa¶

Se um procedimento armazenado ou UDF depender do acesso a um local de rede externo, você deverá replicar os seguintes objetos:

• EXTERNALACCESSINTEGRATIONS devem ser incluídos na lista allowed_integration_types para o grupo de replicação ou failover.

• O banco de dados que contém a regra de rede.

• O banco de dados que contém o segredo que armazena as credenciais para autenticação no local de rede externo.

• Se o objeto secreto fizer referência a uma integração de segurança, você deverá incluir SECURITY INTEGRATIONS na lista allowed_integration_types do grupo de replicação ou failover.

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 externas

• Tabelas ou exibições nos bancos de dados separados dos banco de dados do fluxo, a menos que ambos os bancos de dados de fluxo e o banco de dados que armazena o objeto de origem estejam 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)

A replicação de fluxos em tabelas de diretório é suportada quando você ativa Replicação de histórico de carregamento, canal e estágio.

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.

Os fluxos somente de anexação não são suportados em objetos de origem replicados.

Como evitar a duplicação de dados¶

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:

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.

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 quando indicado, os cenários dizem respeito tanto a tarefas autônomas quanto a tarefas em um gráfico de tarefas:

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.

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 do gráfico da tarefa 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 e gráficos da tarefa retomados depende do número de tarefas retomadas em um banco de dados.