Modifications du schéma de base de données pendant que les workflows n8n sont encore en cours d'exécution

Questions
1

J’ai plusieurs workflows n8n qui peuvent s’exécuter pendant 10 à 30 minutes, et ils utilisent tous les mêmes tables PostgreSQL.
Je dois modifier le schéma de la base de données, mais certaines exécutions de workflows plus anciennes peuvent toujours utiliser l’ancienne structure au moment de la migration.
Par exemple, je pourrais renommer ou supprimer une colonne :
ALTER TABLE orders
DROP COLUMN legacy_status;
Un workflow qui a commencé avant la migration pourrait toujours s’attendre à ce que cette colonne existe.
Devriez-vous conserver l’ancienne colonne temporairement, déployer le nouveau workflow d’abord, attendre la fin des exécutions existantes, puis supprimer l’ancien schéma ?
Ou existe-t-il une meilleure stratégie de migration pour les workflows n8n longue durée ?

Décrivez le problème/l’erreur/la question

Quel est le message d’erreur (le cas échéant) ?

Veuillez partager votre workflow

(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)

Partagez la sortie renvoyée par le dernier nœud

Informations sur votre configuration n8n

  • Version n8n :
  • Base de données (par défaut : SQLite) :
  • Paramètre EXECUTIONS_PROCESS de n8n (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
  • Système d’exploitation :
2

Salut @Roseline L’approche la plus sûre est de faire en sorte que la base de données supporte les deux versions pendant un certain temps.

Par exemple, au lieu de supprimer immédiatement legacy_status, j’ajouterais d’abord le remplacement :


ALTER TABLE orders
ADD COLUMN status_v2 TEXT;

Ensuite, déployez le workflow mis à jour afin que les nouvelles exécutions utilisent status_v2, tandis que les anciennes exécutions peuvent continuer à utiliser legacy_status.

Ajouter une nouvelle colonne

Déployer le nouveau workflow

Les anciennes et nouvelles versions s’exécutent en toute sécurité

Attendre les anciennes exécutions

Migrer les données restantes

Supprimer l’ancienne colonne

Pour les changements plus importants, je garderais également une trace de la version du schéma/workflow :

ALTER TABLE orders
ADD COLUMN schema_version INTEGER NOT NULL DEFAULT 1;

Cela peut être utile lors du dépannage des enregistrements créés par différentes versions de workflow.

Évitez également de compter uniquement sur une période d’attente fixe. Avant de supprimer l’ancienne colonne, vérifiez qu’il n’y a pas d’exécutions actives ou de processus qui en dépendent encore.

L’idée principale est de ne pas faire de la migration et du déploiement du workflow un seul changement qui casse tout. Rendez d’abord le schéma rétrocompatible, déplacez les workflows, vérifiez que tout utilise la nouvelle structure, et ce n’est qu’ensuite que vous nettoyez l’ancienne colonne.

3

Oui, conservez l’ancienne colonne jusqu’à ce que rien ne puisse plus l’utiliser. Incluez les exécutions en pause sur un nœud Wait et les nouvelles tentatives utilisant l’ancien workflow, pas seulement les exécutions actuellement en cours. Si vous supprimez uniquement legacy_status, vous n’avez pas besoin de colonne de remplacement.

Pour un renommage, une chose à modifier dans la séquence ci-dessus : remplissez d’abord la nouvelle colonne et maintenez les écritures synchronisées AVANT de basculer les lectures vers celle-ci. Sinon, le nouveau workflow peut lire des valeurs vides ou obsolètes.

Mise à jour de deux colonnes uniquement dans le nouveau workflow ne couvrira pas les exécutions plus anciennes qui écrivent toujours legacy_status. Vous pouvez conserver cette colonne comme source d’écriture temporairement et utiliser un déclencheur PostgreSQL pour synchroniser le remplacement. Une fois que les anciennes exécutions et la fenêtre de restauration sont effacées, basculez également les écritures, puis supprimez l’ancienne colonne et la synchronisation temporaire.

4

Les membres de la communauté @Anshul_Namdev et @Emmas ont tous deux donné des conseils corrects et conformes aux normes de l’industrie. Dans n8n, les exécutions actives ou mises en pause (comme celles au niveau d’un nœud Wait) conservent leur configuration d’origine en cours d’exécution. La modification du schéma de base de données pendant l’exécution entraînera l’échec de ces tâches longue durée.
Voici la stratégie de migration combinée et détaillée écrite dans une séquence concise :

Étape 1 : Ajouter la nouvelle colonne sans modification de rupture. Exécutez une commande ALTER TABLE pour ajouter la nouvelle colonne à votre base de données, en gardant l’ancienne colonne complètement intacte.

Étape 2 : Configurer un déclencheur de base de données pour la synchronisation. Créez un déclencheur PostgreSQL pour copier automatiquement toutes les données écrites dans l’ancienne colonne vers la nouvelle colonne. Cela protège les flux de travail longue durée qui sont encore actifs et qui écrivent dans l’ancien schéma.

Étape 3 : Remplir vos données existantes. Exécutez un script pour copier les données historiques de l’ancienne colonne vers la nouvelle colonne pour tous les enregistrements existants.

Étape 4 : Déployer votre flux de travail n8n mis à jour. Mettez à jour et publiez votre nouveau flux de travail n8n afin que toutes les exécutions récentes ciblent nativement la nouvelle colonne.

Étape 5 : Surveiller et attendre la fin de vos exécutions actives. Vérifiez le panneau Exécutions de n8n. Attendez que toutes les exécutions antérieures, les nouvelles tentatives et les nœuds Wait en pause aient complètement terminé leur exécution.

Étape 6 : Supprimer en toute sécurité la colonne héritée. Supprimez le déclencheur de base de données temporaire et supprimez l’ancienne colonne de votre schéma de base de données une fois qu’aucun trafic ne l’utilise plus.