Clone système

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 clone existant est désormais disponible dans le Console d'administrateur de clones. La console d’administration du clone offre une visibilité améliorée pour le clonage des 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

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 à l’aide des définitions de table de l’instance source.
4. Copie les données de la copie de sauvegarde nocturne la plus récente 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 vers le serveur d’instance cible.
6. Affiche le message Clone en cours... à tout utilisateur accédant à l’instance cible.
7. Restaure les données opérationnelles conservées de l’instance cible.
8. Exécute tous les scripts de nettoyage post-clone sur l’instance cible.
9. Suspend brièvement toutes les fonctions d’e-mail 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 d’interface utilisateur et les demandes vers le serveur d’instance cible.

Lors 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 et demander une restauration de l’instance cible à 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 d’une version différente

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 du clone 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’à huit heures avant l’heure spécifiée dans le champ Date et heure du formulaire de clone système. Ce service Web confirme é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 copie de sauvegarde, l’instance cible n’a pas besoin de temps supplémentaire pour effectuer une mise à niveau ou une version antérieure. La ServiceNow plateforme effectue tout changement de version pendant une brève période où l’instance cible n’est pas disponible, après avoir copié les données de la copie de sauvegarde de l’instance source.

Cloner à partir d’une copie de sauvegarde

Le clone utilise les données de la copie de sauvegarde nocturne la plus récente de l’instance source lors du clonage. Les copies de sauvegarde utilisées pour le clonage datent de 36 heures maximum. Le clone système commence la préparation initiale, y compris la sélection de la dernière copie de sauvegarde à utiliser, uniquement à la date et à l’heure auxquelles le traitement doit commencer.

Si le clonage à partir d’une sauvegarde source échoue, le système utilise le moteur de clonage hérité à la place. Le moteur 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 type « remontée pas à pas ». Vous pouvez restaurer l’instance cible à partir d’une copie de sauvegarde, puis replanifier le clone dans de tels cas.

Après le clonage à partir d’une copie de sauvegarde, l’instance cible est indisponible 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 copie de sauvegarde, la date et l’heure de la sauvegarde, ainsi que les messages de progression périodiques, apparaissent dans la liste connexe Journal des clones .

Figure 2. Journal de copie de sauvegarde du clone système

Cloner sur les instances de production

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

Options de clone déconseillées

La case à cocher de l’option de clone Conserver les utilisateurs et les tables connexes a été supprimée des options de clone dans la version Utah. Dans certains cas, les personnalisations passées de la page de demande de clone ou liées au clonage peuvent faire en sorte que ce champ reste sur votre formulaire.

Important :

La vérification de ce champ obsolète n’aura aucun effet sur l’utilisateur, le rôle ou les tables connexes pendant votre clone.

.