Clone système

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 4 minutes de lecture

    • Utilisez l’application de clone système pour copier tout ce qui se trouve dans une base de données d’une instance à une autre.

    Le clonage est généralement utilisé pour copier une instance de production vers une instance de pré-production afin de tester les changements. Le clonage des données provient de la sauvegarde nocturne la plus récente.

    Remarque :
    Une nouvelle expérience administrateur unifiée basée sur le moteur de clonage existant est désormais disponible dans .Console d'administrateur de clones La console d’administration de clones offre une visibilité améliorée pour le clonage de données entre les instances, l’une de nos automatisations les plus utilisées, ainsi qu’un certain nombre d’autres améliorations.
    Figure 1. Cloner le processus

    Vue d’ensemble du processus de clonage
    En réponse à une demande de clone, la ServiceNow plateforme effectue les tâches suivantes :
    1. Génère un fichier pour conserver les données opérationnelles sur le serveur cible.
      Remarque :
      Ce fichier contient les données conservées par les conservateurs de données.
    2. Copie le schéma de base de données de l’instance source vers l’instance cible.
    3. Crée des tables dans la base de données de l’instance cible en utilisant les définitions de table d’instance source.
    4. Copie les données de la dernière copie de sauvegarde nocturne de l’instance source vers la base de données de l’instance cible.
      Remarque :
      Certaines exclusions sont automatiques, les grandes tables sont normalement exclues. Il s’agit notamment des tables d’audit, de journal et d’e-mail. MetricBase Les tables ne sont pas exclues par défaut.
    5. Désactive brièvement le trafic d’interface utilisateur et les demandes au serveur d’instance cible.
    6. Affiche le message Clonage en cours... pour n’importe quel utilisateur accédant à l’instance cible.
    7. Restaure les données opérationnelles préservées à partir de l’instance cible.
    8. Exécute tous les scripts de nettoyage post-clone sur l’instance cible.
    9. Interrompt brièvement toutes les fonctions de messagerie sur l’instance cible.
    10. Met en file d’attente un événement pour régénérer les index de texte.
    11. Active le trafic et les demandes de l’interface utilisateur au serveur d’instance cible.

    Au cours d’un clone, l’instance cible peut être indisponible par intermittence. Une fois le clone terminé, vous avez jusqu’à 24 heures pour contacter Service et assistance client l’instance cible et demander sa restauration à son état antérieur au clone. Vous êtes averti lorsque la restauration est terminée.

    Remarque :
    Si l’instance source a un niveau de profondeur de clone de >=5, le clone n’est pas autorisé.

    Si l’objectif de l’instance source est DART (Data Access for Responsible Training), le clone n’est pas autorisé et un message d’erreur s’affiche.

    Cloner vers une instance sur une autre version

    L’application de clone système peut cibler une instance exécutant une version d’instance différente de la source.

    Un service Web central contrôle le traitement des clones et modifie automatiquement la version de l’instance cible pour qu’elle corresponde à la version de l’instance source. Ce processus de correspondance commence jusqu’à 8 heures avant l’heure spécifiée dans le champ Date et heure du formulaire de clone système. Ce service Web garantit également qu’il y a suffisamment d’espace disque sur l’instance cible pour que le clone puisse continuer.

    Lors du clonage à partir d’une sauvegarde, l’instance cible n’a pas besoin de plus de temps pour effectuer la mise à niveau ou la rétrogradation. La ServiceNow plateforme effectue tout changement de version pendant une brève fenêtre où l’instance cible n’est pas disponible, après avoir copié les données à partir de la copie de sauvegarde de l’instance source.

    Cloner à partir d’une sauvegarde

    utilise Now Platform les données de la copie de sauvegarde nocturne la plus récente de l’instance source lors du clonage. Les sauvegardes utilisées pour le clonage ont un maximum de 36 heures. Le clone système commence la préparation initiale, y compris la sélection de la dernière sauvegarde à utiliser, uniquement à la date et à l’heure planifiées pour le début du traitement.

    Si le clonage à partir d’une sauvegarde source échoue, le système utilise le moteur de clone hérité à la place. Le moteur de clone hérité ne peut pas conserver les données des tables étendues, des relations, des hiérarchies entre les tables et des requêtes de remontée pas à pas. Vous pouvez restaurer l’instance cible à partir d’une sauvegarde, puis replanifier le clone dans ce cas.

    Après le clonage à partir d’une copie de sauvegarde, l’instance cible n’est pas disponible pendant plusieurs minutes avant que le clone ne soit marqué comme terminé dans l’instance source. Si les instances source et cible se trouvent sur des versions différentes de , Now Platforml’instance cible est modifiée pour correspondre à la version de l’instance source pendant cette période.

    Lors du démarrage d’un clone à partir d’une sauvegarde, la date et l’heure auxquelles la sauvegarde a été effectuée, ainsi que les messages de progression périodiques, apparaissent dans la liste connexe Journal de clonage .

    Figure 2. Journal de sauvegarde du clone système
    Enregistrement de la copie de sauvegarde du journal de clonage

    Cloner les instances de production

    Tant que la propriété système est définie sur TRUE, glide.db.clone.allow_clone_target une instance peut servir de clone. La modification des données sur l’instance source au cours d’un clone peut entraîner une incohérence de données entre les enregistrements ou des entrées d’enregistrement en double.