muppy.io
  • ⛏️Qu'est ce que muppy.io ?
  • ⚒️Concepts Muppy
  • Quickstarts
    • ✏️Introduction
  • Guides
    • ⛏️Muppy Core
      • Hosts
        • Création et enrôlement d'un Host
          • ✏️Server Types
          • ✏️Configuration réseaux spécifiques
        • ⚒️Host's Users
        • ⚒️Host's Network information
        • ⚒️Host's Metrics
      • Tasks et Fact Collectors
        • ⚒️Exécution des Tasks (Task Runs)
          • ⚒️Exécution asynchrone des Tasks (Launch as Job)
        • ⚒️Synchronisation des Tasks et Scripts
        • ⚒️Liste des Scripts
        • ⚒️Liste des Tasks
        • ⚒️Création de Task "Shell Script"
        • ⚒️Liste des Fact Definitions
      • ⛏️Firewall UFW
        • Désactiver UFW globalement
        • ✏️Page 1
      • SSH Keys
        • Gestion des SSH Keys
        • Gestion des "authorized_keys"
        • Extraction Clef Privée d'un User User
      • ⚒️Systemd Service Units
        • ⚙️Liste des Systemd Units
        • ➕Création de Systemd Units
        • 📰Systemctl status et log
        • ✏️Edition des Systemd Units
    • 🐘PostgreSQL
      • PostgreSQL Base
        • Installation de PostgreSQL
        • Gestion des Clusters
          • Création
          • Configuration
          • Contrôle
          • Administration (basique)
        • Backup, Restore et Copy de Databases
          • Databases Backups (pg_dump)
          • PostgreSQL Backup
          • pg_dump Restore
          • Database Copy
          • pg_restore Callback Task
        • Backups Planifiés
        • Gestion rétention des Backups
      • PostgreSQL Replication
        • Créer un RCS
        • Visualiser un RCS
        • Suivre la Replication
        • Ajouter des Standbys
        • Restructurer un RCS
        • Intégration d'un RCS
        • Reconfigurer un RCS
      • PostgreSQL HA
        • Configuration
        • Activation et Désactivation
        • Monitoring
        • pglookout Heartbeat
      • PostgreSQL PITR
        • Configuration de WAL-G
        • Lancement des Clusters Backups
        • Liste des Clusters Backups (WAL-G)
        • Purge des fichiers de Backup PITR
        • Monitoring du PITR
        • Objets S3 stockés par WAL-G
        • Restauration PITR
      • PostgreSQL Tools
        • pgBadger - log analysis
    • Muppy Pack
      • ⛏️Packs
      • Concepts
      • ⛏️Muppy Cluster
        • Cluster Security
        • PostgreSQL Cluster Resources
      • ⛏️Reverse Proxy
    • ✏️Configuration
      • 👫Gestion des Users Muppy
      • 🏬S3 Buckets
      • 💬Notifications Teams
      • ✏️Notifications Slack
    • ⛏️Odizy
      • Odizy Workflow
        • Test Servers
      • Accéder à vos serveurs
      • Restaurer un backup sur le serveur de staging
      • Activer un serveur Standby
      • ⛏️Configuration LXC CI/CD
      • Activate and Launch remote Code-Server (VS Code from coder.com)
    • ⚒️Kubernetes
      • ⚒️Installer Tailscale
      • ⚒️Installer un cluster microk8s
      • ⚒️Installer PostgrSQL
      • ⚒️Installer les packages d'infrastructures
  • 📡Muppy Enterprise
    • Introduction
    • ⛏️Configuer une Instance Muppy Enterprise
    • 🌡️Monitoring Muppy Enterprise
  • ⛏️Work in progress
    • ⛏️Code Server
    • ⛏️Muppy Development Servers
      • Move Development Server
Powered by GitBook
On this page
  • Présentation
  • Exemple de pg_restore Callback Task
  • Mise en oeuvre
  1. Guides
  2. PostgreSQL
  3. PostgreSQL Base
  4. Backup, Restore et Copy de Databases

pg_restore Callback Task

Présentation

Muppy vous permet de modifier le processus de restauration des pg_dumps à l'aide de Task d'un type particulier nommé pg_restore Callback Task.

Ces callbacks ont été conçues pour permettre d'automatiser le type d'opérations suivantes:

  • Modifier les caractéristiques d'un User juste après sa création

  • Modifier un schéma après la création de la base et avant la restauration

  • Anonymiser une base de données juste après la restauration

Les pg_restore Callback Task sont des Muppy Tasks qui sont appelées à chaque étape du processus de restauration des Databases.

Les pg_restore Callback Task ont une signature particulière, un paramètre step permet d'indiquer à quelle étape du processus de restauration elles sont invoquées.

Exemple de pg_restore Callback Task

@fabric_task()
def template_pg_restore_callback(
        cnx, host_obj,
        step:str,
        pg_cluster_obj:OdooModelType,
        pg_dump_obj:OdooModelType=None,
        pg_dump_file_path:str=None,
        db_name:str=None,
        db_comment:str=None,
        db_owner:str=None,
        _imq_logger=None
    ):
    """ Template pg_restore callback 
    :param step: The pg_restore step whose end triggered this task:
       any of 's3_download', 'create_user', 'drop_db', 'create_db', 'pg_restore'.
    :param pg_cluster_obj: Cluster on which the dump will be restored.
    :param pg_dump_obj: The Muppy pg_dump object that will be restored.
    :param pg_dump_file_path: Full path of the pg_dump that will be restored.
    :param db_name: Name of the database to restore.
    :param db_comment: Comment that will be set at restore.
    :param db_owner: User owner of the database.

    :returns: something or False
    """
    odoo_env = host_obj.env
    _task_logger = _imq_logger or _logger
    # ...

Mise en oeuvre

Les callbacks peuvent être définies à différents niveaux:

  • L'objet "PostgreSQL Database" permet de définir un callback qui sera proposée comme valeur par défaut dans le Wizard "Backup Databases".

  • Le Wizard "Backup Databases" permet de définir un callback qui sera stockée dans l'objet pg_dump et qui sera proposée comme valeur par défaut lors de la restauration d'un pg_dump.

  • Le Wizard "Restore PostgreSQL Databases" permet de forcer la callback à utiliser lors du Restore. Si aucun Callback n'est précisée au niveau du Wizard, c'est le Callback définie au niveau du pg_dump qui est utilisée.

  • Le Wizard "Copy Databases (using pg_dump)" permet de définir le callback qui sera utilisée lors du Restore.

PreviousDatabase CopyNextBackups Planifiés

Last updated 3 years ago

🐘