Ich versuche, von einem aktuellen Server auf einen heute erstellten wiederherzustellen. Es schlägt mit dieser Fehlermeldung fehl. Ich sehe das nirgendwo im Discourse-Code oder im Plugin-Code.
Ich bin mir nicht sicher, was ich als Nächstes tun soll.
Gleicher Fehler hier, wenn ich versuche, bei einer Neuinstallation wiederherzustellen, da ich versucht habe, mein Discourse auf einen anderen Server zu verschieben. Keine Lösung gefunden.
Ich hatte Glück, dass der alte Server noch lief. Also habe ich die App neu aufgebaut, um den alten Server auf die exakt gleiche Version wie die Neuinstallation zu bringen. Dann habe ich über die Kommandozeile ein weiteres Backup erstellt. Als ich dieses Backup auf der Neuinstallation wiederhergestellt habe, hat alles geklappt. Das solltest du auch versuchen. @pfaffman
Autsch, das ist mir auch schon passiert. Ich versuche, von einem Produktionssystem auf eine Sandbox/Entwicklungsumgebung wiederherzustellen. Ich habe auch überprüft, ob alle Plugins installiert sind.
Welches andere Plugin verwendet dies? Ich werde mir jetzt den Quellcode ansehen…
Stellen Sie sicher, dass der Ordner /var/discourse/shared leer war oder an einen neuen Ort verschoben wurde, falls wir wiederherstellen müssen.
Eine neue Discourse-Instanz mit ./launcher bootstrap <app> initialisiert.
Versuchte die Wiederherstellung erneut, und sie schlug immer noch mit derselben Fehlermeldung fehl.
Dann, als ich einen Dump meiner funktionierenden Discourse-Instanz machte, fand ich den eigentlichen Befehl, der die Funktion erstellt. Er lautet:
CREATE FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
RAISE EXCEPTION 'Discourse: old_notification_id in chat_mention_notifications is readonly';
END
$$;
ALTER FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() OWNER TO discourse;
Dann habe ich die Wiederherstellung erneut versucht, und alles lief gut!
Jetzt hatte ich das Protokoll, bei dem es fehlschlug, und dachte, ich könnte später darauf zurückkommen, aber die Protokolle werden mit jeder Backup/Restore-Funktion zurückgesetzt.
VERBESSERUNG: Es wäre schön, eine Historie von Backups/Restores zu haben. Vielleicht gibt es eine, und ich weiß nicht, wo sie ist.
HAFTUNGSAUSSCHLUSS: Ich bin kein Support-Mitarbeiter von Discourse, daher werde ich nicht darauf eingehen, wie man zur psql-Befehlszeile gelangt, um die obigen Befehle auszuführen. :
Das Problem ist, dass eine Migration mit einem älteren Zeitstempel später in tests-passed committet wurde (@nbianca FYI), und dies wird von den Metadaten der Version im Backup nicht erkannt. Ich habe das hier erwähnt.
Das ist die Lösung. Sie müssen entweder den Commit-Hash vom Instanzserver abrufen und Ihre neue Instanz mit diesem Commit erstellen oder die vorhandene Instanz auf die neueste Version aktualisieren, die diese Migration ausführt, und dann ein neues Backup erstellen.
Sagen Sie damit, dass die (aktuelle?) Lösung auf Dauer darin besteht, nur auf denselben Commit (oder tatsächlich auf dieselbe Migration) wiederherzustellen, der das Backup erstellt hat?
Oder wenn beide Versionen über den fehlerhaften Commit hinausgehen, werden wir dann in Ordnung sein?
Ja, aber manchmal können Sie die Quellinstanz nicht aktualisieren. In diesem Fall müssen Sie das Ziel auf denselben Commit wie die Quelle setzen. Dies ist also eine Ausnahme von der regulären Situation, in der Sie bei der Wiederherstellung immer eine implizite Vorwärtsmigration durchführen können.
Ich werde das heute testen, aber meine aktuelle Annahme ist, dass die Wiederherstellung funktioniert, sobald die Zielseite vollständig auf dem neuesten Stand ist.
Es scheint, dass das Problem darin besteht, dass die Versionsprüfung zu Beginn der Wiederherstellung nicht erkennt, dass die Quelle tatsächlich ein neueres DB-Schema als das Ziel hatte.
Korrekt, und das passiert, weil die Migration nicht den Zeitstempel des Moments hat, in dem sie committet wurde, sondern den Zeitstempel des Moments, in dem sie generiert wurde. Meistens spielt das keine Rolle, aber in diesem Fall lagen 7 Wochen zwischen diesen beiden Momenten.
Ja, das ist ein unglücklicher Grenzfall. Wir können versuchen, ihn in Zukunft zu vermeiden oder eine abwärtskompatible Lösung zu finden, um zu verhindern, dass er erneut auftritt. Ich glaube jedoch nicht, dass wir in diesem Fall etwas tun können, um ihn zu beheben. Das Schiff ist abgefahren. Was auch immer wir tun, es wird immer erfordern, dass Websitebesitzer ihre Ziel-Website auf die neueste Version aktualisieren.
Korrekt, dies ist ein Problem mit dieser Art von Techniken im Allgemeinen, es ist ein generelles Problem für Ruby on Rails und auch für andere AR-Implementierungen wie PHP Laravel. Und wie Sie sagten, passiert es nicht sehr oft, und sobald man merkt, was vor sich geht, ist es einfach, während der Wiederherstellung damit umzugehen.
Also, in meinem Szenario war meine Wiederherstellungsumgebung ein paar Versionen neuer als die versicherte, die gesichert wurde. Sollte das dann nicht funktionieren?
