Prise en charge des annonces dans le cadre de la continuité des activités et de la reprise après sinistre¶
Les fournisseurs peuvent inclure des annonces et leurs dépendances, telles que des partages et des bases de données, dans les groupes de réplication et de basculement de compte. Grâce à ces groupes de basculement, en cas de dégradation du service ou de panne, l’annonce s’appuie sur ces groupes pour la réplication des données et la reprise après sinistre.
Note
Cette fonctionnalité est uniquement disponible pour les annonces pour lesquelles :doc:`l’exécution automatique </collaboration/provider-listings-auto-fulfillment>`est activé.
Consultez la section Comportement, considérations et contraintes avant d’utiliser cette fonctionnalité.
Conditions¶
Annonces principales : Annonces dans le groupe de basculement principal
Annonces secondaires : Annonces dans le groupe de basculement secondaire
Comprendre la nécessité de la continuité des activités et de la reprise après sinistre¶
En cas de panne dans la région principale, la continuité des activités et la reprise après sinistre (BCDR ) sont essentielles pour les fournisseurs.
Les fournisseurs doivent continuer à assurer la disponibilité de leurs produits de données avec un minimum d’interruptions en cas de panne.
Les fournisseurs doivent respecter les accords de niveau de service (SLAs) concernant le RTO (objectif de temps de reprise) et le RPO (objectif de point de reprise) pour éviter les conséquences financières.
Les fournisseurs doivent conserver des répliques de leurs données dans des régions secondaires en cas de panne.
Configuration manuelle pour le basculement et la reprise¶
Les fournisseurs qui n’ajoutent pas d’annonces à leurs groupes de basculement présentent des délais de reprise plus longs et fournissent des informations obsolètes à leurs clients. Sans BCDR, les fournisseurs doivent recréer des annonces dans les régions secondaires après le basculement. Les consommateurs doivent ensuite se référer aux nouvelles URLs d’annonce. Cette réplication manuelle entraîne des perturbations importantes au niveau des pipelines ETL et des applications, ce qui se traduit par des temps d’indisponibilité prolongés pour les utilisateurs et des coûts supplémentaires de transfert de données pour les fournisseurs.
Basculement et reprise automatisés¶
La fonctionnalité BCDR pour les annonces améliore la préparation de l’entreprise et réduit l’impact d’une panne.
La fonctionnalité BCDR pour les annonces élimine l’obligation pour les fournisseurs de recréer des annonces après un basculement.
La nouvelle région principale ne se réplique pas à nouveau vers les comptes de la zone de partage sécurisée (SSA), ce qui permet de réduire les coûts de transfert de données, car seules les modifications incrémentielles sont répliquées vers les comptes SSA.
Avec la prise en charge BCDR pour les annonces, après un basculement :
Les consommateurs ont toujours accès aux données des fournisseurs sans temps d’arrêt.
Les fournisseurs peuvent desservir de nouvelles régions consommatrices à partir de la nouvelle région principale.
Les fournisseurs peuvent toujours répondre aux exigences d’actualisation des données des consommateurs, car l’annonce s’actualise à partir de la nouvelle annonce principale.
Workflow BCDR pour les annonces¶
Un workflow BCDR pour les annonces typique est le suivant :
Une panne atteint la région, affectant la région principale.
Pendant que la région principale est en panne, les annonces des régions consommatrices ne peuvent pas s’actualiser. Par conséquent, les consommateurs se basent sur des données obsolètes.
L’administrateur chargé de la récupération des données met en œuvre le guide d’intervention de l’organisation.
L’administrateur obtient l’approbation pour basculer vers la région secondaire.
Cette région secondaire devient la nouvelle région principale.
La réplique dans le groupe de basculement devient la nouvelle source d’informations pour tous les objets.
L’administrateur actualise la nouvelle région principale avec les dernières mises à jour des sources de données, telles que les tables externes et les pipelines ETL.
L’administrateur prend un instantané des objets de la nouvelle région principale afin de vérifier qu’elle dispose des données les plus récentes.
L’administrateur audite la nouvelle région principale pour confirmer si elle est prête pour la production.
Une fois le basculement terminé, l’exécution automatique recommence à fonctionner à l’intervalle d’actualisation suivant de la nouvelle région principale.
Note
L’administrateur peut utiliser la commande SHOW LISTINGS IN FAILOVER GROUP pour confirmer que les annonces sont prêtes pour la production.
Critères de sélection BCDR¶
La fonctionnalité BCDR n’est pas pris en charge quand :
L’annonce est à l’état de brouillon.
L’annonce est soutenue par une zone de préparation.
L’annonce est une annonce payante.
L’exécution automatique de l’annonce n’est pas activée.
L’annonce est une annonce Snowflake Native App.
Comportement, considérations et contraintes¶
Consultez les sections ci-dessous pour comprendre le comportement, les considérations et les contraintes de la fonctionnalité BCDR pour les annonces.
Comportement¶
Si un groupe de basculement secondaire est supprimé, les annonces secondaires du groupe de basculement sont automatiquement supprimées.
Considérations¶
Le basculement des tables Iceberg gérées en externe n’est pas pris en charge à l’heure actuelle, même si celles-ci sont prises en charge pour l’exécution automatique. Le basculement des tables Iceberg gérées est actuellement en mode Aperçu public.
Certaines fonctionnalités peuvent ne pas être prises en charge pour le basculement au niveau de la base de données, mais peuvent l’être au niveau de l’annonce. Les objets non pris en charge seront ignorés lors de la réplication.
Contraintes¶
Assurez-vous de bien comprendre les contraintes suivantes avant de configurer la fonctionnalité BCDR pour les annonces :
Contraintes de sous-ensembles complets (règle du tout ou rien)
Exigences en matière de types d’objets de groupe de basculement
Contraintes de la configuration de l’exécution automatique des annonces
Contraintes de sous-ensembles complets (règle du tout ou rien)¶
Lors de l’ajout d’un objet à un groupe de basculement, si un objet est référencé par une annonce pour laquelle l’exécution automatique est activée, tous les objets référencés par cette même annonce doivent être inclus dans le même groupe de basculement.
Lors de la suppression d’un objet d’un groupe de basculement, si un objet est référencé par une annonce pour laquelle l’exécution automatique est activée, tous les objets référencés par cette même annonce doivent être supprimés ensemble.
Exigences en matière de types d’objets de groupe de basculement¶
Lorsqu’un groupe de basculement contient des bases de données ou des partages qui sont référencés par des annonces pour lesquelles la réplication automatique est activée, le groupe de basculement doit inclure LISTINGS dans son paramètre OBJECT_TYPES. Par exemple :
Contraintes de la configuration de l’exécution automatique des annonces¶
Avant d’activer l’exécution automatique sur une annonce ou de publier une annonce pour laquelle l’exécution automatique est activée, toutes les dépendances des annonces (y compris les partages et les bases de données) doivent être configurées dans un groupe de basculement qui inclut le type d’objet
LISTINGS.L’exécution automatique doit être activée manuellement sur le compte secondaire (si elle n’est pas déjà activée). Pour plus d’informations, voir SYSTEM$ENABLE_GLOBAL_DATA_SHARING_FOR_ACCOUNT.
Lorsque le privilège REFERENCE_USAGE est utilisé par les annonces, il peut y avoir des objets qui ne sont pas directement liés à l’annonce, mais qui sont également comptés comme faisant partie du sous-ensemble dans la contrainte de sous-ensemble complet.
Contraintes liées aux annonces de Marketplace interne¶
Les contraintes suivantes s’appliquent aux annonces sur le Marketplace interne (annonces organisationnelles) :
Workflow d’approbation des demandes¶
Si un consommateur envoie une demande concernant une annonce d’organisation qui n’a pas encore été approuvée et que le système bascule vers un déploiement secondaire, le fournisseur de réplique ne verra pas la demande du consommateur. En effet, les demandes sont liées au déploiement dans lequel elles ont été initialement créées. Le consommateur doit renouveler sa demande d’annonce.
La tentative d’annulation de la publication de l’annonce après le retour à la région principale échouera dans le scénario suivant :
Un consommateur demande une annonce qui se trouve dans une région principale et dans ses régions de basculement, et
Le consommateur demande à nouveau l’annonce, qui a été approuvée alors qu’elle se trouvait dans la région secondaire.
Cet échec se produit car la demande en attente d’origine est conservée. Pour que la désactivation soit effective, le fournisseur doit rejeter explicitement la requête initiale, puis relancer l’opération de désactivation.
Dictionnaire de données¶
Les objets à la une ne font pas partie du processus de réplication de basculement. Par conséquent, les objets à la une sélectionnés dans l’instance principale ne seront pas reflétés sur l’instance secondaire après un basculement. Le fournisseur doit réinitialiser manuellement ces objets après un basculement. Si le fournisseur ne réinitialise pas les objets à la une, le consommateur verra un dictionnaire de données obsolète, même s’il ajoute de nouvelles tables. En effet, la tâche d’arrière-plan ignore cette annonce. La tâche d’arrière-plan sélectionnera cette annonce une fois les objets à la une définis.
Si des modifications sont apportées aux objets à la une alors que le système fonctionne en tant que réplique, ces modifications ne seront pas synchronisées avec l’instance principale d’origine après la restauration.
Aperçu des données¶
Les informations d’aperçu des données ne sont pas répliquées dans des régions secondaires. Par conséquent, après un basculement, les consommateurs ne verront aucun fichier d’aperçu des données. Sur la région secondaire, le fournisseur doit régénérer les fichiers d’aperçu des données.
Comme pour le dictionnaire de données, toutes les modifications apportées à l’aperçu des données lors d’un état de basculement ne seront pas synchronisées avec l’élément principal d’origine après la restauration. Le fournisseur peut réinitialiser les informations d’aperçu des données sur la région principale d’origine après la restauration.
Profils d’organisation¶
Le fournisseur principal et le fournisseur secondaire doivent tous deux utiliser un profil permettant de publier l’annonce.
Contraintes liées à la réplication des profils¶
Si les profils ne sont pas répliqués par un groupe de basculement, les annonces du compte secondaire continuent de fonctionner sans profil joint.
Si les profils ne sont pas répliqués par un groupe de basculement, les profils du compte principal d’origine resteront inchangés après l’actualisation du basculement et de la restauration.
Les profils du compte secondaire sont en lecture seule jusqu’à ce que le basculement se produise. Après le basculement, le nouveau compte principal peut créer, modifier ou supprimer des profils.
Si le compte secondaire possède un profil local existant, l’actualisation du groupe de basculement initial échouera intentionnellement afin d’éviter la perte de données potentielle. Suivez les étapes indiquées dans le message de résultat de la requête pour continuer.
Les demandes d’approbation des profils ne sont pas répliquées. Si une demande d’approbation est en attente sur le compte principal d’origine, le nouveau compte principal peut, après le basculement, soumettre à nouveau cette demande d’approbation.
Contraintes des annonces secondaires en lecture seule¶
Les annonces secondaires ne peuvent pas être modifiées directement. Toutes les opérations d’écriture, par exemple ALTER et DROP, doivent être exécutées sur l’annonce principale.