Beim Versuch, eine Website durch Wiederherstellen eines Backups von einem vorhandenen Deploy zu migrieren, schlägt die Wiederherstellung aufgrund von Schema-Inkompatibilitäten fehl (Quelle ist neuer als Ziel).
Nun überprüfe ich die Endpunkte admin/plugins beider Deploys. Sie stimmen für die aufgelisteten überein, ebenso wie ihr Status und ihre Version, daher bin ich etwas ratlos. Ich habe auch versucht, alle Themes und Komponenten wiederherzustellen, falls das die Ursache ist, aber es gab keine Änderung. Beide Websites laufen auf App 3.1.3, das scheint also in diesem Fall nicht die Hauptursache zu sein.
Ich vermute, dass ein Plugin auf der Website installiert war, dann die Instanz neu bereitgestellt und die Datenbank ohne dieses Plugin beibehalten wurde, aber das ist nur eine Vermutung. Gibt es eine deterministische Methode, anhand einer Instanz oder Datenbank festzustellen, was zu den Schema-Abweichungen geführt hat? Und gibt es eine Möglichkeit, eine “Downgrade” durchzuführen, oder ist die einzige Methode, die Ziel-Website anzupassen oder zu überschreiben?
Könnte es sein, dass die alte Version eine Beta-Version war oder Tests bestanden hat und nicht stabil war, sodass die neueste stabile Version tatsächlich älter ist?
Ich würde prüfen, ob die Commit-Nummern übereinstimmen (wenn möglich).
Das Backup ist von der Datenbank, daher bezweifle ich, dass die Plugin-Population eine Rolle spielt. Es wird einfach die Plugin-Daten hinzufügen, aber sie nicht tatsächlich verwenden …
Ich glaube nicht, aber es ist eine Entwicklungsumgebung, also ist alles möglich, schätze ich.
Gibt es in der Tabelle schema_migrations (oder im geklonten Code des Containers) etwas, das ich manuell überprüfen und die Schemaversion mit einer Änderung korrelieren könnte?
Das Umbenennen der Datei kann dazu führen, dass Dinge über die Benutzeroberfläche hochgeladen werden, aber ich habe den Merger verwendet, der basierend auf max(schema_migrations) blockiert, und ich versuche wirklich, nicht zu viel zu hacken.
Einiges davon greift den operativen Aufgaben voraus, bei denen Diskrepanzen bei der Migrationversion auftreten könnten. Besser verstehen, wie man die Migrationversion auf Änderungen zurückverfolgt, damit ich, wenn dies wieder vorkommt, hoffentlich einen Runbook zur Abstimmung finden kann.
Ja, ich sehe die maximale schema_migration (auch wenn ich nur den Dateinamen eines Backups betrachte), aber ich habe die Tabelle überprüft und es ist nur der Datumswert. Keine Hinweise, woher er stammt.
Zum Beispiel ist das „gute“ 20230823100627 und die Seite ist 20231022224833. Ich kann nicht einmal Dateien für „20231022“ im Ordner post_migrate (oder anderswo im Repository) finden.
Ich bin sicher, es starrt mich an. Und ja, ich durchforste vergangene Änderungen und E-Mails, um herauszufinden, ob ich eine Aktion nach August abgleichen kann, bei der möglicherweise eine fehlerhafte Version eingeschlichen ist.
In diesem Fall ist es die Dev-Instanz zu einer neu bereitgestellten „Merge“-Instanz, die ich dann mit Merger verwenden werde, um eine weitere Dev-Instanz als Test für eine laufende Instanzkonsolidierungsbemühung zu importieren. Die Synchronisierung der Schema-Migrationsversion ist eine Voraussetzung (nicht überraschend). In diesem Fall befindet sich die Zielumgebung auf 1022 und die Quelle auf 0823. In allen 3.1.3er-Versionen, die ich habe, sind wir 0823, daher war es ein Rätsel, woher 1022 kam, und das versuche ich herauszufinden, aber ich kann keine Spur finden.
Idealerweise sollten Sie keine Daten in der Entwicklung behalten müssen und die Datenbank einfach löschen und die Migrationen erneut ausführen können.
Um zwei divergierende Entwicklungsumgebungen zusammenzuführen, würden Sie normalerweise den Code, einschließlich der Migrationen, zusammenführen und dann eine neue Instanz von Grund auf neu erstellen?
Dies ist teilweise der Grund, warum es eine nette Rake-Aufgabe gibt, um einige Fixtures vorab zu füllen, damit etwas zum Arbeiten vorhanden ist: rake dev:populate
Wir haben eine Datenbank mit allen Migrations-IDs für über 400 Plugins, sodass wir sie leicht einem Plugin zuordnen können. Dieses hier stammt von discourse-automation.
Heh ja, alle Farmtiere sind vor einiger Zeit aus dem Stall ausgebrochen, also versuche ich, alle wieder in den Stall zu bekommen. Oder zumindest herauszufinden, ob es überhaupt machbar ist.
Und wir haben das fehlende Teil gefunden, als wir uns das Dateisystem der Instanz angesehen haben.
Die Leute hatten sich mit Automatisierung beschäftigt, aber in den anderen Umgebungen hatten sie sie nie aktiviert, sodass sie in der Plugin-Liste verfügbar war und keine Schemaänderung vorgenommen worden war. Also weit davon entfernt, ideal zu sein, aber der Hinweis für mich bei dieser Arbeit ist, die Repositories aller installierten Plugins zu überprüfen, auch wenn sie deaktiviert sind, da sie vielleicht irgendwann einmal aktiviert waren.
Wir führen einen erneuten Deploy durch, bei dem einige dieser F&E-Plugins entfernt werden, und behalten die Plugin-/DB-Einträge viel genauer im Auge und führen dort eine bessere Aufzeichnung.
Ja, wir haben es auch endlich herausgefunden, indem wir uns die Instanzlaufzeit selbst angesehen haben, aber weit davon entfernt, ideal zu sein. Lektion gelernt für ein operatives Runbook, falls wir es brauchen. Ich habe einfach nicht das Automatisierungs-Repository in der Organisation überprüft, da es deaktiviert zu sein schien und niemand es benutzte. Eine schlechte Annahme meinerseits.
@RGJ besteht die Chance, dass die Datenbank irgendwo öffentlich zugänglich ist? Die Verwendung des Instanzdateisystems „funktioniert“, wird aber unordentlicher, als ich es bevorzugen würde.
Ja, ich habe im Discourse-Repository selbst gesucht, anstatt die ganze Welt zu durchsuchen, da ich mir nicht sicher war, ob es überhaupt angezeigt würde. Die Suche ohne Bereich ist zu teuer, aber ich habe nicht die Organisation durchsucht, um zu sehen, ob es Treffer für offizielle Discourse-Bemühungen gab.
Wir haben 3 oder 4 Discourse-Instanzen, die unabhängige Teams gestartet haben, um ein gemeinsames Geschäftsproblem zu lösen, und wir prüfen, ob wir alle in eine einzige Instanz bringen können, ohne ihre bisherige Arbeit zu verlieren.
Ich kann nicht glauben, dass es eine gute Praxis ist, sich auf die Speicherung von Daten in der Entwicklung zu verlassen.
Wenn die Daten wichtig sind, sollte diese Arbeit wahrscheinlich unter kontrollierteren Umständen in der Produktion stattfinden.
Ich kenne die genaue Natur dessen, was Sie zu tun versuchen, nicht, aber wenn ich eine Meinung abgeben müsste, sollten Lösungen fast sicher Plugins sein, die überall bereitgestellt werden können und nicht einmal vollständig von einer bestimmten Version von Discourse abhängen müssen, noch sich darum kümmern müssen, ob bestimmte Daten außerhalb der Seedung ihrer eigenen Fixtures vorab gefüllt sind.
In diesem Fall prüfen wir die Machbarkeit dieser Zusammenführungsoperationen für die Prod-Instanzen unter Verwendung einiger Dev-Instanzen. Wenn wir das Runbook solide gestalten können, werden alle Daten und Instanzen auf Prod-Niveau sein, aber bisher von unabhängigen Teams gepflegt worden sein. Zu wissen, was die Blocker für eine erfolgreiche Zusammenführung sind, ist also das, woran ich jetzt arbeite. Und die Schemaversion ist eindeutig eine Schlüsselkomponente, und sowohl Apps als auch Plugins können die „Zusammenführbarkeit“ beeinflussen und werden dies auch tun. Glücklicherweise haben die Prod-Instanzen 0823 gezeigt, sodass dieses spezielle Problem bei einem Prod-Lauf nicht auftreten würde, aber zu wissen, wie man eine Schemaabweichung analysiert, war notwendig und wird unsere Opdocs wirklich verbessern.
Habe eine weitere Nuance von Schemata entdeckt. Wir haben also das Automatisierungs-Plugin aus der Bereitstellung entfernt und neu bereitgestellt. Dann bemerkte ich, dass schema_migration anscheinend wieder auf 0823 als neueste zurückgesetzt wurde. Ich dachte also, ich könnte ohne die Installation des Automatisierungs-Plugins in der Instanz, die ich zusammenführe, weitermachen. Als ich einen weiteren Importlauf durchführte, erhielt ich einen PG::UndefinedTable: ERROR: relation "discourse_automation_automations" does not exist-Fehler, sodass, obwohl die Migrationsversion zurückgesetzt wurde, die damit verbundenen Schemaänderungen in der tatsächlichen Datenbank anscheinend noch vorhanden waren.
(was Sie mit 
