Suporte à listagem em continuidade dos negócios e recuperação de desastres¶
Os provedores podem incluir listagens e suas dependências, como compartilhamentos e bancos de dados, nos grupos de failover e replicação de conta. Com grupos de failover, se ocorrer uma degradação ou interrupção do serviço, a listagem depende de grupos de failover para replicação de dados e recuperação de desastres.
Nota
Este recurso está disponível apenas para listagens que tenham habilitado o preenchimento automático.
Consulte a seção Comportamento, considerações e restrições antes de usar esse recurso.
Termos¶
Listagens primárias: listagens no grupo de failover primário
Listagens secundárias: listagens no grupo de failover secundário
Explicando a necessidade da continuidade dos negócios e recuperação de desastres¶
Em caso de interrupção na região primária, a continuidade dos negócios e a recuperação de desastres (Business Continuity and Disaster Recovery, BCDR) se torna crucial para os provedores.
Os provedores devem continuar oferecendo suporte a seus produtos de dados com interrupções mínimas durante uma interrupção.
Os provedores devem cumprir os contratos de nível de serviço (Service Level Agreements, SLAs) em relação a RTO (objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação) para evitar penalizações financeiras.
Os provedores devem manter réplicas de seus dados em regiões secundárias para o caso de uma interrupção.
Configuração manual de failover e recuperação¶
Os provedores que não adicionam listagens a seus grupos de failover têm tempos de recuperação mais altos e informações obsoletas para os consumidores. Sem a BCDR, os provedores deverão recriar as listagens nas regiões secundárias após o failover. Depois disso, os consumidores deverão fazer uma nova montagem para os URLs da nova listagem. Essa replicação manual causa enormes interrupções em pipelines e aplicativos ETL, estendendo o tempo de inatividade para os consumidores e aumentando os custos de transferência de dados para os provedores.
Failover e recuperação automatizados¶
A BCDR para listagens melhora a prontidão corporativa e diminui a interrupção causada por uma falha.
A BCDR para listagens elimina a exigência de que os provedores recriem listagens após um failover.
A nova região primária não é replicada para as contas de área de compartilhamento segura (Secure Share Area, SSA), o que economiza custos de transferência de dados porque apenas alterações incrementais são replicadas para as contas SSA.
Com o suporte da BCDR para listagens, após um failover:
Os consumidores ainda terão acesso aos dados do provedor sem tempo de inatividade.
Os provedores poderão atender novas regiões de consumidores a partir da nova região primária.
Os provedores ainda poderão atender aos requisitos de atualização de dados do consumidor porque a listagem é atualizada a partir da nova região primária.
Fluxo de trabalho de BCDR para listagens¶
Veja a seguir um fluxo de trabalho de BCDR comum para listagens:
Uma interrupção atinge a região, afetando a região primária.
Enquanto a região primária está inativa, as listagens nas regiões do consumidor não podem ser atualizadas. Como resultado, os consumidores operam com dados obsoletos.
O administrador de recuperação de dados inicia o runbook da organização.
O administrador obtém aprovação para fazer failover para a região secundária.
A região secundária passa a ser a nova região primária.
A réplica no grupo de failover se torna a nova fonte de informações para todos os objetos.
O administrador atualiza a nova região primária com as últimas atualizações das fontes de dados, como tabelas externas e pipelines ETL.
O administrador obtém um instantâneo dos objetos na nova região primária para verificar se ela tem os dados mais atualizados.
O administrador faz auditoria da nova região primária para confirmar se ela está pronta para produção.
Após a conclusão do failover, o preenchimento automático começa a funcionar novamente no próximo intervalo de atualização da nova região primária.
Nota
O administrador pode usar o comando SHOW LISTINGS IN FAILOVER GROUP para confirmar que as listagens estão prontas para produção.
Critérios de seleção da BCDR¶
Não há suporte para BCDR quando:
A lista está em estado de rascunho.
A listagem está vinculada a uma área de preparação.
A listagem é paga.
A listagem não tem o preenchimento automático habilitado.
A listagem é do Snowflake Native App.
Comportamento, considerações e restrições¶
Revise as seções abaixo para entender o comportamento, as considerações e as restrições da BCDR para listagens.
Comportamento¶
Se um grupo de failover secundário for removido, as listagens secundárias nele serão automaticamente descartadas.
Considerações¶
O failover de tabelas Iceberg gerenciadas externamente não é compatível no momento, mesmo que elas sejam compatíveis com preenchimento automático. O failover de tabelas Iceberg gerenciadas está em Versão preliminar pública.
Alguns recursos podem não ser compatíveis com failover no banco de dados, mas podem ser compatíveis com failover na listagem. Os objetos incompatíveis serão ignorados durante a replicação.
Restrições¶
Você precisa entender as seguintes restrições antes de configurar a BCDR para listagens:
Restrições de subconjunto completo (regra «tudo ou nada»)¶
Ao adicionar um objeto a um grupo de failover, se algum objeto for referenciado por uma listagem que tenha o preenchimento automático habilitado, todos os objetos referenciados por essa mesma listagem deverão ser incluídos no mesmo grupo de failover.
Ao remover um objeto de um grupo de failover, se algum objeto for referenciado por uma listagem que tenha o preenchimento automático habilitado, todos os objetos referenciados por essa mesma listagem deverão ser removidos juntos.
Requisitos de tipo de objeto do grupo de failover¶
Quando um grupo de failover contém bancos de dados ou compartilhamentos referenciados por listagens com o preenchimento automático habilitado, o grupo de failover deve incluir LISTINGS em seu parâmetro OBJECT_TYPES. Por exemplo:
Listando as restrições de configuração do preenchimento automático¶
Antes de habilitar o preenchimento automático em uma listagem ou de publicar uma listagem que tenha o preenchimento automático habilitado, todas as dependências da listagem, incluindo compartilhamentos e bancos de dados, devem ser configuradas em um grupo de failover que inclua o tipo de objeto
LISTINGS.O preenchimento automático deve ser habilitado manualmente na conta secundária (se ainda não estiver habilitado). Para obter mais informações, consulte SYSTEM$ENABLE_GLOBAL_DATA_SHARING_FOR_ACCOUNT.
Quando o privilégio REFERENCE_USAGE é usado por listagens, pode haver objetos que não estejam diretamente relacionados à listagem, mas que também foram contados como parte do subconjunto na restrição do subconjunto completo.
Restrições de listagens do Internal Marketplace¶
As seguintes restrições se aplicam às listagens no Internal Marketplace (listagens organizacionais):
Fluxo de trabalho de aprovação de solicitação¶
Se um consumidor enviar uma solicitação para uma listagem organizacional que não foi aprovada, e o sistema executar failover para uma implantação secundária, o provedor de réplica não verá a solicitação do consumidor. Isso ocorre porque as solicitações estão vinculadas à implantação em que as solicitações foram feitas originalmente. O consumidor precisa solicitar a listagem novamente.
A tentativa de cancelar a publicação da listagem após o failback para a região primária falhará no seguinte cenário:
Um consumidor solicita uma listagem que está em uma região primária e em suas regiões de failover e;
O consumidor solicita novamente a listagem, que foi aprovada enquanto estava na região secundária.
Essa falha ocorre porque a solicitação pendente original permanece. Para cancelar a publicação com sucesso, o provedor deve rejeitar explicitamente a solicitação original e, depois disso, tentar novamente a operação de cancelamento da publicação.
Data Dictionary¶
Os objetos em destaque não fazem parte do processo de replicação de failover. Como resultado, todos os objetos em destaque selecionados na instância primária não serão refletidos na instância secundária após um failover. O provedor deve redefinir manualmente esses objetos após um failover. Se o provedor não redefinir os objetos em destaque, o consumidor verá um Data Dictionary obsoleto, mesmo que adicione novas tabelas. Isso ocorre porque o trabalho em segundo plano ignora a listagem. O trabalho em segundo plano selecionará a listagem depois que os objetos em destaque forem definidos.
Se alguma modificação for feita nos objetos em destaque enquanto o sistema estiver operando como réplica, as alterações não serão sincronizadas de volta para a instância primária original após o failback.
Versão preliminar de dados¶
As informações da Versão preliminar de dados não são replicadas para regiões secundárias. Como resultado, após um failover, os consumidores não verão arquivos da Versão preliminar de dados. Na região secundária, o provedor deve gerar novamente os arquivos da Versão preliminar de dados.
Semelhante ao Data Dictionary, todas as alterações feitas na Versão preliminar de dados durante um estado de failover não serão sincronizadas de volta para a região primária original após o failback. O provedor pode redefinir as informações da versão preliminar de dados na região primária original após o failback.
Perfis da organização¶
Os provedores tanto primário quanto secundário devem usar um perfil que possa publicar a listagem.
Restrições de replicação de perfil¶
Se os perfis não forem replicados por um grupo de failover, as listagens na conta secundária continuarão a funcionar sem perfis anexados.
Se os perfis não forem replicados por um grupo de failover, os perfis da conta primária original permanecerão inalterados após uma atualização de failover e failback.
Os perfis da conta secundária serão somente leitura até que o failover ocorra. Após o failover, a nova conta primária poderá criar, alterar ou descartar perfis.
Se a conta secundária tiver um perfil local existente, a atualização inicial do grupo de failover falhará intencionalmente para evitar possível perda de dados. Siga as etapas na mensagem de resultado da consulta para prosseguir.
As solicitações de aprovação de perfil não são replicadas. Se houver uma solicitação de aprovação pendente na conta primária original, a nova conta primária poderá solicitar novamente a aprovação após o failover.
Restrições de listagem secundária somente leitura¶
As listagens secundárias não podem ser modificadas diretamente. Todas as operações de gravação, como ALTER e DROP, devem ser realizadas na listagem primária.