J’essaie de migrer un site en restaurant une sauvegarde d’un déploiement existant. La restauration échoue en raison d’une incompatibilité de schéma (la source est plus récente que la cible).
J’examine actuellement le point de terminaison admin/plugins des deux déploiements ; ils correspondent pour ceux qui sont listés, leur statut et leur version, donc je me gratte la tête un peu. J’ai également essayé de remettre tous les thèmes et composants au cas où, mais sans changement. Les deux sites sont à l’application 3.1.3, donc cela ne semble pas être la cause profonde dans ce cas.
Je suppose qu’un plugin a été installé sur le site, puis l’instance a été redéployée et la base de données préservée sans ce plugin installé, mais ce n’est qu’une supposition. Existe-t-il un moyen déterministe, étant donné une instance ou une base de données, de déterminer ce qui a contribué à la dérive du schéma ? Et existe-t-il un moyen de “rétrograder” ou la seule méthode consiste-t-elle à faire correspondre ou à surclasser le site cible ?
Se pourrait-il que l’ancien site soit en version bêta ou que des tests soient passés et non stables, de sorte que la dernière version stable soit en fait plus ancienne ?
Je vérifierais que les numéros de commit correspondent (si possible).
La sauvegarde concerne la base de données, donc je doute que la population des plugins soit pertinente, elle ajoutera simplement les données du plugin sans réellement les utiliser…
Je ne pense pas, mais c’est un environnement de développement donc tout est possible, je suppose.
Y a-t-il quelque chose que je puisse vérifier manuellement dans la table schema_migrations (ou le code cloné du conteneur) et corréler la version du schéma avec un changement quelconque ?
Le renommage du fichier permet de téléverser des éléments via l’interface utilisateur, mais j’utilisais le merger qui bloque en fonction du max(schema_migrations) et j’essaie vraiment d’éviter de bidouiller les choses.
Certaines de ces choses anticipent toute tâche opérationnelle où des incohérences de version de migration pourraient apparaître. Mieux comprendre comment retracer la version de migration jusqu’aux changements afin que lorsque cela se reproduira, je puisse espérer trouver un guide pour la réconciliation.
depuis la ligne de commande dans le répertoire discourse… mais si vous n’avez pas restauré, cela pourrait ne pas aider…
ou depuis psql :
SELECT * FROM schema_migrations ORDER BY version DESC LIMIT 1;
Vous pourriez ensuite rechercher cela sur Github pour faire correspondre le commit…
par exemple : https://github.com/search?q=repo%3Adiscourse%2Fdiscourse+20231222030024&type=code
Parcourez le fichier de migration, puis notez le commit lorsqu’il a été ajouté pour confirmer la date, etc.
NB : ce n’est pas nécessairement la même chose que le commit de code, évidemment ! Il pourrait être plus ancien (ce que vous pouvez obtenir avec git log -1).
Oui, je peux voir la schema_migration maximale (même en regardant juste le nom d’un fichier de sauvegarde), mais j’ai vérifié la table et il n’y a que la valeur de la date. Aucune indication de l’origine.
Par exemple, le « bon » est 20230823100627 et le site est 20231022224833. Je ne trouve même pas de fichiers pour « 20231022 » dans le dossier post_migrate (ou ailleurs dans le dépôt).
Je suis sûr que c’est sous mes yeux. Et oui, je vais examiner les changements passés et les e-mails pour essayer de trouver une action après août où une version non conforme aurait pu s’infiltrer.
Dans ce cas, il s’agit de l’instance Dev vers une instance « Merge » nouvellement provisionnée que j’utiliserai ensuite pour importer une autre instance Dev afin de tester un effort de consolidation d’instances en cours. La version de migration de schéma étant synchronisée est une condition préalable (sans surprise). Dans ce cas, l’environnement cible est sur 1022 et la source est 0823. Dans toutes les versions 3.1.3 que j’ai, nous sommes en 0823, donc cela a été une énigme de savoir d’où venait 1022 et c’est ce que j’essaie de comprendre, mais je ne trouve aucune trace.
Idéalement, vous ne devriez pas avoir à conserver de données en développement et devriez pouvoir simplement supprimer la base de données et réexécuter les migrations.
Pour fusionner deux instances de développement divergentes, vous fusionneriez normalement le code des branches, y compris les migrations, puis créeriez une nouvelle instance à partir de zéro ?
C’est en partie pourquoi il existe une jolie tâche rake pour pré-remplir des fixtures afin qu’il y ait quelque chose avec quoi travailler : rake dev:populate
Nous avons une base de données avec tous les identifiants de migration pour plus de 400 plugins, nous pouvons donc les mapper facilement à un plugin. Celui-ci provient de discourse-automation.
Heh ouais, tous les animaux de la ferme se sont échappés de la grange il y a un moment, alors j’essaie de les ramener dans l’enclos. Ou du moins, de déterminer si c’est même faisable.
Les gens avaient regardé automate, mais sur les autres environnements, ils ne l’avaient jamais activé, donc il était disponible dans la liste des plugins et aucun changement de schéma n’avait été effectué. Donc, loin d’être idéal, mais l’indice pour moi sur ce travail est de vérifier les dépôts de tous les plugins installés, même s’ils sont désactivés, car ils ont peut-être été activés à un moment donné.
Nous effectuons un redéploiement en supprimant certains de ces plugins R&D, tout en surveillant de plus près les entrées de plugins / db et en y tenant une meilleure comptabilité.
Oui, nous avons finalement trouvé aussi en examinant le temps d’exécution de l’instance elle-même, mais loin d’être idéal. Leçon apprise pour un runbook opérationnel si nous en avons besoin. Je n’ai tout simplement pas vérifié le dépôt d’automatisation dans l’organisation car il semblait désactivé et personne ne l’utilisait. Mauvaise supposition de ma part.
@RGJ y a-t-il une chance que cette base de données soit accessible publiquement quelque part ? L’utilisation du système de fichiers de l’instance « fonctionne » mais devient plus compliquée que je ne le souhaiterais.
Oui, je cherchais dans le dépôt discourse lui-même au lieu de balayer le monde, car je n’étais pas sûr que cela apparaisse même. La recherche sans portée est trop coûteuse, mais je n’ai pas cherché dans l’organisation pour voir s’il y avait des succès pour les efforts officiels de Discourse.
Nous avons 3 ou 4 instances Discourse que des équipes indépendantes ont lancées pour résoudre un problème commercial commun et nous cherchons à savoir si nous pouvons rassembler tout le monde dans une seule instance tout en ne perdant pas leur travail précédent.
Je n’arrive pas à croire que ce soit une bonne pratique de se fier à la conservation des données en environnement de développement.
Si les données sont importantes, ce travail devrait probablement exister en production dans des circonstances plus contrôlées.
Je ne connais pas la nature complète de ce que vous essayez de faire, mais pour être catégorique, les solutions devraient presque certainement être des plugins qui peuvent être déployés n’importe où et ne pas même avoir à dépendre entièrement d’une version spécifique de Discourse, ni se soucier si des données spécifiques sont pré-remplies en dehors de l’initialisation de leurs propres fixtures.
Dans ce cas, nous évaluons la faisabilité de ces opérations de fusion pour les instances de production en utilisant quelques instances de développement. Si nous pouvons rendre le runbook solide, alors toutes les données et instances seront au niveau de production, mais elles ont été maintenues par des équipes indépendantes jusqu’à présent. Donc, savoir quels sont les obstacles à une fusion réussie est ce sur quoi je travaille maintenant. Et la version du schéma est clairement un élément clé, et l’application ainsi que les plugins peuvent et affecteront la « fusionnabilité ». Heureusement, les instances de production ont montré 0823, donc ce problème spécifique ne se produirait pas lors d’une exécution en production, mais savoir comment analyser une dérive de schéma était nécessaire et aidera vraiment nos opdocs.
J’ai découvert une autre nuance des schémas. Nous avons donc supprimé le plugin d’automatisation du déploiement et redéployé. Ensuite, j’ai remarqué que schema_migration semblait revenir à 0823 comme dernière version. J’ai donc pensé que je pouvais continuer sans installer le plugin d’automatisation dans l’instance que je fusionne. Eh bien, lorsque j’ai effectué une autre exécution de l’importation, j’ai obtenu une erreur PG::UndefinedTable: ERROR: relation "discourse_automation_automations" does not exist, donc même si la version des migrations a été annulée, les modifications de schéma qui y sont liées dans la base de données réelle semblaient toujours présentes.
(ce que vous pouvez obtenir avec 
