Restaurer et supprimer la récupération

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

    • Avec les contextes de restauration, vous pouvez restaurer certaines actions telles que la mise à niveau d’un correctif, l’activation d’un module d’extension et l’exécution de scripts en arrière-plan. Vous pouvez également récupérer les suppressions d’enregistrements et tous les changements associés.

    Les fonctionnalités de restauration et de suppression sont disponibles sur les instances qui utilisent les bases de données MySQL et MariaDB. Les instances qui utilisent des bases de données Oracle prennent uniquement en charge la restauration. Les instances qui utilisent SQL Server ne prennent pas en charge la restauration ou la suppression de la récupération.
    Tableau 1. Prise en charge de la restauration et de la suppression de la base de données de récupération
    Type de base de données Restaurer Supprimer la récupération
    MySQL yes yes
    MariaDB yes yes
    Oracle yes no

    Module Enregistrements supprimés

    Ce module fonctionne sur des enregistrements dans des tables auditées. La récupération des enregistrements supprimés en cascade doit être effectuée dans les sept jours suivant la suppression de l’enregistrement. Au bout de sept jours, seuls les enregistrements de données et les références sur les tables dont il est nécessaire de vérifier les suppressions peuvent être récupérés, ce qui correspond aux fonctionnalités des versions précédentes.

    Pour trouver ce module, accédez à Définition du système > Enregistrements supprimés.

    Supprimer le module de récupération

    Ce module fonctionne pour tout enregistrement supprimé. Cette récupération doit être effectuée dans les sept jours suivant la suppression de l’enregistrement.

    Pour trouver ce module, accédez à Restauration et reprise > Supprimer la détection.

    Module Historique des exécutions de script

    Ce module fonctionne sur les scripts exécutés à l’aide du module Scripts - Arrière-plan . Cet historique ne comprend que sept jours d’exécutions de scripts.

    Pour trouver ce module, accédez à Restauration et reprise > Historique des exécutions de script.

    Contextes de restauration

    Les contextes de restauration contiennent tout ce qui est nécessaire pour restaurer une mise à niveau de logiciel ou l’activation d’un module d’extension. Il s’agit notamment des enregistrements supprimés, des mises à jour de correctifs, des exécutions de scripts en arrière-plan, des actions de base de données et des activations de plug-ins. Un contexte de restauration est créé pour chaque mise à niveau de correctif au sein d’une famille et chaque activation de module d’extension, à condition que le module d’extension prenne en charge les contextes de restauration.

    Pour utiliser des contextes de restauration, activez les modules d’extension Restaurer les enregistrements supprimés (com.snc.undelete) et Supprimer la récupération (com.glide.delete_recovery).

    Les restaurations sont généralement effectuées sur des instances de pré-production où la fonctionnalité doit être restaurée avant que vous puissiez trouver la cause première d’un problème dans la mise à niveau. La restauration supprime les données, ce qui peut souvent rendre difficile, voire impossible, la découverte du problème qui a rendu la restauration nécessaire.

    Un contexte de restauration est créé lorsque :
    • GlideRecord.delete() ou GlideRecord.deleteMultiple() supprimer des enregistrements.
    • Il y a une mise à niveau de correctif.
    • Vous activez un module d’extension qui prend en charge les contextes de restauration.
    • Un script s’exécute à l’aide du module Scripts - Arrière-plan et la restauration a été activée en cochant la case Enregistrer pour la restauration ? .

    Les restaurations n’ont pas d’impact sur les autres activités de base de données. Si une activité de base de données modifie un enregistrement qui fait partie d’un contexte de restauration, la restauration n’affecte pas cet enregistrement.

    Étant donné que les contextes de restauration contiennent une quantité importante de données, les contextes de restauration sont supprimés après 10 jours. Par conséquent, les restaurations doivent avoir lieu dans les 10 jours suivant la dernière mise à niveau ou activation du module d’extension. Pour ce faire, vous pouvez conserver un contexte de restauration pendant plus de 10 jours en ajoutant une propriété système. Consultez Propriétés du contexte de restauration.

    Remarque :
    Ne restaurez pas un contexte de restauration avant d’avoir vérifié avec Service et assistance client. Une restauration supprime les données et peut supprimer la preuve du problème de mise à niveau ou d’activation, empêchant ainsi le débogage du problème.

    Pour trouver ce module, accédez à Restauration et reprise > Contextes de restauration.

    Si l’une des opérations suivantes se produit pendant une restauration, aucun contexte de restauration n’est créé :

    • Les tables ou colonnes sont supprimées du schéma.
      Remarque :
      Les baisses d’index sont acceptables.
    • Une table est tronquée.
    • Une table ou une colonne est renommée.
    • Une colonne change de parent ou est promue.
    • Un type de colonne change.
    • La largeur d’une colonne est réduite.
    Le processus de restauration activé Now Support effectue les opérations suivantes :
    • Met à jour le WAR signalé vers la version restaurée et le WAR affecté reste défini sur la version antérieure à la restauration.
    • Définit la propriété glide.war.no_upgrade sur l’instance à la version antérieure à la restauration.
    • Affiche le message suivant : « La guerre souhaitée correspond à la guerre inversée spécifiée par la propriété [glide.war.no_upgrade]. Le script de mise à niveau ne s’exécutera PAS ».
    • Bascule l’état sur Expiré et la restauration purge toutes les données stockées.