Sto cercando di ripristinare da un server recente a uno creato oggi. Fallisce con questo errore. Non vedo nulla di simile nel codice di Discourse o nel codice dei plugin.
Non sono sicuro di cosa fare dopo.
[20/9694]
ERRORE: la funzione discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() non esiste
ECCEZIONE: psql fallito: ERRORE: la funzione discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() non esiste
/var/www/discourse/lib/backup_restore/database_restorer.rb:92:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:51:in `run'
script/discourse:157:in `restore'
/var/www/discourse/vendor/bundle/ruby/3.
Stesso errore qui quando si tenta di ripristinare su una nuova installazione, poiché ho provato a spostare il mio discourse su un altro server. Nessuna soluzione trovata.
Sono fortunato che il vecchio server sia ancora in funzione. Quindi ho ricostruito l’app del launcher per portare il vecchio server alla stessa versione della nuova installazione. Poi ho fatto un altro backup tramite riga di comando. Ripristinando questo backup sulla nuova installazione, tutto è andato bene. Dovresti provare questo. @pfaffman
Accidenti, mi è successo anche questo. Sto cercando di ripristinare da un sistema di produzione a sandbox/dev. Ho anche ricontrollato che tutti gli stessi plugin siano installati.
Quale altro plugin lo utilizza? Sto per controllare il codice sorgente…
Assicurati che la cartella /var/discourse/shared fosse vuota, o spostata in una nuova posizione nel caso avessimo bisogno di ripristinare.
Ho inizializzato una nuova istanza di Discourse usando ./launcher bootstrap <app>
Ho riprovato il ripristino e ancora fallito con lo stesso messaggio di errore.
Poi, quando ho fatto un dump della mia istanza Discourse funzionante, ho trovato il comando effettivo che crea la funzione. È:
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;
Poi ho riprovato il ripristino, e tutto è andato bene!
Ora, avevo il log dove era fallito e pensavo di poterci tornare in seguito, ma i log vengono resettati ad ogni funzionalità di Backup/Ripristino.
ENHANCEMENT: Sarebbe bello avere una cronologia dei backup/ripristini. Forse ce n’è una e non so dove si trovi.
DISCLAIMER: Non sono una persona di supporto di Discourse, quindi non entrerò nei dettagli su come accedere al prompt dei comandi psql per eseguire i comandi sopra. :
Il problema è che una migrazione con un timestamp precedente è stata sottoposta a commit in tests-passed in seguito (@nbianca FYI), e questo non viene rilevato dai metadati di versione nel backup. Ne ho accennato qui.
Questa è la soluzione. Quindi, o devi ottenere l’hash del commit dal server dell’istanza e creare la tua nuova istanza con quel commit, oppure aggiornare l’istanza esistente all’ultima versione, che eseguirà quella migrazione, e quindi effettuare un nuovo backup.
Sì, ma a volte non sarai in grado di aggiornare l’istanza di origine. E in tal caso dovrai mettere la destinazione sullo stesso commit dell’origine. Quindi questa è un’eccezione alla situazione normale in cui puoi sempre eseguire una migrazione in avanti implicita durante il ripristino.
Lo testerò oggi, ma la mia ipotesi attuale è che il ripristino funzioni non appena il sito di destinazione è completamente aggiornato.
Sembra che il problema sia che il controllo della versione all’inizio del ripristino non rileva che la sorgente avesse in realtà uno schema DB più recente della destinazione.
Corretto, e questo sta accadendo perché la migrazione non ha il timestamp del momento in cui è stata eseguita, ma il timestamp del momento in cui è stata generata. La maggior parte delle volte non ha importanza, ma in questo caso ci sono state 7 settimane tra quei due momenti.
Sì, questo è un caso limite sfortunato. Possiamo provare a evitarlo in futuro o a trovare una soluzione retrocompatibile per evitare che accada di nuovo. Tuttavia, non credo che possiamo fare nulla per risolverlo in questo caso. Quella nave è salpata. Qualunque cosa faremo, richiederà sempre ai proprietari del sito di aggiornare il loro sito di destinazione all’ultima versione.
Corretto, questo è un problema con questo tipo di tecniche in generale, è un problema generico per Ruby on Rails e anche per altre implementazioni AR come PHP Laravel. E come hai detto, non succede molto spesso, e una volta che ti rendi conto di cosa sta succedendo è facile aggirarlo durante il ripristino.
Quindi, nel mio scenario, il mio ambiente di ripristino era più recente di un paio di versioni rispetto all’assicurazione che era stata sottoposta a backup. Non dovrebbe funzionare allora?
