Quindi, ho un backup di Discourse dal nostro server iniziale e stiamo cercando di spostare il sistema su un nuovo sistema.
Sfortunatamente, ci sono due problemi:
Durante il ripristino, dice che 71 dei 1073 caricamenti non sono stati migrati su S3 e quindi fallisce durante il processo di ripristino.
Tentando di risolvere questo problema sull’istanza principale ribattendo, ecc. i post, indica che alcuni caricamenti non sono ancora stati migrati su S3, anche quando provo a utilizzare il meccanismo rake uploads:migrate_to_s3.
C’è un modo per ottenere informazioni dettagliate da migrate_to_s3 su quali caricamenti non sono stati migrati, in modo da poterli correggere manualmente? È anche possibile che si riferiscano a un repository S3 morto/fallito da cui stavamo caricando inizialmente, tranne che le cose sono esplose a quel punto e abbiamo semplicemente cambiato meccanismi S3 (a MinIO ovviamente), e c’erano ancora vecchie cose che giacevano sul lato AWS S3. Cosa che non credo di poter migrare facilmente alla nostra istanza MinIO.
In alternativa, esiste un modo per disabilitare il controllo dei caricamenti su S3 del meccanismo di ripristino perché ho già forzato la migrazione dei caricamenti da solo?
OK, quindi, l’ho capito dopo un’immersione profonda nel DB. Sembrano avanzi (71 upload) dall’ambiente S3 originale, ormai defunto da tempo (o meglio, in questo caso, ambiente S3 disponibile ma non utilizzato principalmente, perché non sarebbe stato conveniente).
Ho finito per fare questo:
Dal server di origine:
./launcher enter app
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%'
(sostituisci ExpectedS3DomainGoesHere con l’URL effettivo che utilizzi per la tua configurazione S3)
Questo ti fornirà gli URL su cui lavorare, perché dobbiamo fare alcune cose.
Dove gli URL provengono da bucket più vecchi su URL diversi, utilizza il client Amazon S3 (o il client del tuo backend di archiviazione S3) e:
a. Sincronizza i bucket con URL imprevisti, se disponibili, sullo storage locale.
b. Sincronizza gli elementi da locale al nuovo bucket.
discourse remap VECCHIO-URL-DAL-DB NUOVO-URL-DAL-DB
Sebbene sia stato suggerito qui di utilizzare DbHelper.remap, la funzione remap di discourse ha funzionato bene.
Assicurati che i dati siano migrati. rails uploads:migrate_to_s3
Tempo di rebake! rails posts:rebake
Backup del sito di nuovo sulla macchina/server di ‘origine’. Scarica quell’ultimo aggiornamento.
Dal nuovo server di destinazione:
Configura Discourse come previsto, copia app.yml e simili dal server di origine al nuovo server in /var/discourse/containers/ per assicurarti che la ricostruzione colpisca i plugin appropriati, ecc. necessari.
Assicurati di commentare tutte le voci DISCOURSE_BACKUP_LOCATION: s3 in app.yml, se stai lavorando con copie di backup locali. Ho avuto alcuni problemi con S3 che si comportava in modo strano con file di backup troncati, quindi ho optato per l’approccio locale per un ripristino.
È stato doloroso per me risolverlo, ma è stato risolto una volta che ho approfondito la tabella degli upload nel DB. MA, questo sembra aver funzionato, quindi…
Ciò che spesso funziona in questi tipi di situazioni è disabilitare temporaneamente i caricamenti s3 sull’istanza originale prima di eseguire un backup. Dopo il ripristino, puoi riabilitare s3.