Sto cercando di migrare un sito ripristinando un backup da un’installazione esistente. Il ripristino fallisce a causa di una discrepanza nello schema (sorgente più recente della destinazione).
Ora sto esaminando l’endpoint admin/plugins di entrambe le installazioni, corrispondono per quelli elencati, il loro stato e la loro versione, quindi sono un po’ perplesso. Ho anche provato a ripristinare tutti i temi e i componenti per sicurezza, ma non è cambiato nulla. Entrambi i siti sono all’app 3.1.3, quindi questo non sembra essere la causa principale in questo caso.
Suppongo che sia stato installato un plugin sul sito, poi l’istanza è stata ridistribuita e il database preservato senza questo plugin installato, ma questa è solo un’ipotesi. Esiste un modo deterministico, dato un’istanza o un database, per capire cosa ha contribuito alla discrepanza dello schema? Ed esiste un modo per “retrocedere” o l’unico metodo è far corrispondere o sovrascrivere il sito di destinazione?
Potrebbe essere che il vecchio fosse in beta o che i test siano stati superati e non stabili, quindi la versione stabile più recente è in realtà più vecchia?
Controllerei che i numeri di commit corrispondano (se possibile).
Il backup è del database, quindi dubito che la popolazione dei plugin sia importante, aggiungerà semplicemente i dati del plugin ma non li utilizzerà effettivamente…
Non credo, ma è un ambiente di sviluppo, quindi tutto è possibile, immagino.
C’è qualcosa che conosci nella tabella schema_migrations (o nel codice clonato del container) che potrei controllare manualmente e correlare la versione dello schema a qualche modifica?
Il cambio di nome del file può far caricare le cose tramite l’interfaccia utente, ma stavo usando il merger che si blocca in base a max(schema_migrations) e sto davvero cercando di evitare di manomettere troppo le cose.
Alcune di queste cose vanno oltre qualsiasi attività operativa in cui potrebbero comparire discrepanze nella versione di migrazione. È meglio capire come risalire alla versione di migrazione per apportare modifiche, in modo che quando questo accadrà di nuovo, spero di poter definire un runbook per la riconciliazione.
Sì, riesco a vedere la schema_migration massima (anche solo guardando il nome di un file di backup), ma ho controllato la tabella e contiene solo il valore della data. Nessuna indicazione su da dove provenga.
Ad esempio, il “buono” è 20230823100627 e il sito è 20231022224833. Non riesco nemmeno a trovare file per “20231022” nella cartella post_migrate (o altrove nel repository).
Sono sicuro che mi sta fissando. E sì, sto analizzando le modifiche passate e le email per cercare di capire se riesco a trovare un’azione dopo agosto in cui una versione errata potrebbe essersi insinuata.
In questo caso si tratta dell’istanza Dev che passa a una nuova istanza “Merge” appena creata, che userò poi per importare un’altra istanza Dev come sforzo di consolidamento delle istanze che stiamo portando avanti. La versione della migrazione dello schema in sincronia è un prerequisito (non mi sorprende). In questo caso, l’ambiente di destinazione è su 1022 e l’origine è 0823. In tutte le versioni 3.1.3 che ho, siamo a 0823, quindi è stato un grattacapo capire da dove provenisse 1022 ed è quello che sto cercando di ricostruire, ma non riesco a trovare alcuna traccia.
Idealmente non dovresti conservare dati in dev e dovresti essere in grado di semplicemente eliminare il database e rieseguire le migrazioni.
Per unire due istanze dev divergenti, normalmente uniresti il codice dei branch, comprese le migrazioni, quindi creeresti una nuova istanza da zero?
Questo è in parte il motivo per cui esiste una bella attività rake per pre-caricare alcuni fixture in modo che ci sia qualcosa con cui lavorare: rake dev:populate
Abbiamo un database con tutti gli ID di migrazione per oltre 400 plugin, quindi possiamo associarli facilmente a un plugin. Questo proviene da discourse-automation.
Heh sì, tutti gli animali della fattoria sono scappati dal fienile un po’ di tempo fa, quindi sto cercando di riportarli tutti nel recinto. O almeno capire se è anche solo fattibile.
La gente aveva guardato automate, ma sugli altri ambienti non l’avevano mai attivato, quindi era disponibile nell’elenco dei plugin e non era stata apportata alcuna modifica allo schema. Quindi, lungi dall’essere l’ideale, ma il suggerimento per me su questo lavoro è di controllare i repository di tutti i plugin installati, anche se sono disabilitati, poiché forse sono stati abilitati a un certo punto.
Stiamo facendo un redeploy rimuovendo alcuni di questi plugin R&D e tenendo d’occhio molto più da vicino le voci dei plugin /db e facendo una migliore tenuta dei registri lì.
Sì, alla fine l’abbiamo capito anche noi guardando il runtime dell’istanza stessa, ma ben lontano dall’ideale. Lezione imparata per un runbook operativo, se ne avremo bisogno. Semplicemente non ho controllato il repository di automazione nell’organizzazione poiché sembrava disabilitato e non c’era traccia di nessuno che lo utilizzasse. Cattiva supposizione da parte mia.
@RGJ c’è la possibilità che quel database sia accessibile pubblicamente da qualche parte? Usare il file system dell’istanza “funziona”, ma diventa più complicato di quanto preferirei.
Sì, stavo cercando nel repository di discourse stesso invece di scansionare il mondo, dato che non ero sicuro che sarebbe nemmeno apparso. La ricerca senza uno scope è troppo costosa, ma non sono uscito nell’organizzazione per vedere se c’erano successi per gli sforzi ufficiali di Discourse.
Abbiamo 3 o 4 istanze di Discourse che team indipendenti hanno avviato per risolvere un problema aziendale comune e stiamo verificando se possiamo portare tutti in un’unica istanza senza perdere il loro lavoro precedente.
Non riesco a credere che sia una buona prassi fare affidamento sulla conservazione dei dati in dev.
Se i dati sono importanti, quel lavoro dovrebbe probabilmente esistere in Produzione in circostanze più controllate.
Non conosco la natura completa di ciò che stai cercando di fare, ma essendo opinabile, le soluzioni dovrebbero quasi certamente essere plugin che possono essere distribuiti ovunque e non devono nemmeno fare pieno affidamento su una versione specifica di Discourse, né preoccuparsi se dati specifici sono pre-popolati al di fuori del seeding dei propri fixture.
In questo caso stiamo valutando la fattibilità di queste operazioni di merge per le istanze Prod utilizzando un paio di istanze Dev. Se riusciamo a rendere solido il runbook, allora tutti i dati e le istanze saranno a livello di produzione, ma finora sono stati gestiti da team indipendenti. Quindi, capire quali sono gli ostacoli per un merge di successo è ciò su cui sto lavorando ora. E la versione dello schema è chiaramente una chiave e sia l’app che i plugin possono e influenzeranno la “mergability”. Fortunatamente le istanze di produzione hanno mostrato 0823, quindi questo problema specifico non si verificherebbe in un’esecuzione di produzione, ma sapere come analizzare una deriva dello schema era necessario e aiuterà davvero i nostri opdocs.
Ho scoperto un’altra sfumatura degli schemi. Abbiamo rimosso il plugin di automazione dal deployment e ridistribuito. Poi ho notato che schema_migration sembrava essere tornato a 0823 come ultimo. Quindi ho pensato che andasse bene senza installare il plugin di automazione nell’istanza che sto unendo. Bene, quando ho eseguito un’altra importazione, ho ricevuto un errore PG::UndefinedTable: ERROR: relation \"discourse_automation_automations\" does not exist, quindi anche se la versione delle migrazioni è tornata indietro, le modifiche allo schema ad essa collegate nel database effettivo sembrano essere ancora presenti.
(che puoi ottenere con 
