Así que tengo una copia de seguridad de Discourse de nuestro servidor inicial y estamos intentando mover el sistema a un nuevo sistema.
Desafortunadamente, hay dos problemas:
Durante la restauración, dice que 71 de 1073 cargas no se migraron a S3 y, por lo tanto, falla rotundamente durante el proceso de restauración.
Al intentar solucionar esto en la instancia principal rebakeando, etc. las publicaciones, indica que algunas cargas aún no se han migrado a S3, incluso cuando intento usar el mecanismo de rake uploads:migrate_to_s3.
¿Hay alguna forma de obtener información detallada de migrate_to_s3 sobre qué cargas no se migraron, para poder solucionarlo manualmente? También es posible que se refieran a un repositorio S3 muerto/fallido desde donde estábamos subiendo inicialmente, excepto que las cosas explotaron en ese momento y simplemente cambiamos los mecanismos de S3 (a MinIO, por supuesto), y todavía había cosas antiguas en el lado S3 de AWS. Lo que no creo que pueda migrar fácilmente a nuestra instancia de MinIO.
Alternativamente, ¿hay alguna forma de deshabilitar el verificador de cargas en S3 del mecanismo de restauración porque ya forcé la migración de las cargas yo mismo?
OK, así que lo descubrí después de una inmersión profunda en la base de datos. Parece que quedan restos (71 cargas) del entorno S3 original, que ya no funciona (o, en este caso, un entorno S3 disponible pero no utilizado principalmente, porque no iba a ser rentable).
Terminé haciendo esto:
Desde el servidor de origen:
./launcher enter app
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%'
(reemplaza ExpectedS3DomainGoesHere con la URL real que usas para tu configuración S3)
Esto te dará las URL con las que trabajar, porque necesitamos hacer algunas cosas.
Donde las URL provienen de buckets más antiguos en diferentes URL, usa el cliente Amazon S3 (o el cliente para tu backend de almacenamiento S3), y:
a. Sincroniza los buckets de URL inesperadas si están disponibles a almacenamiento local.
b. Sincroniza los elementos de Local al nuevo Bucket.
discourse remap OLD-URL-FROM-DB NEW-URL-FROM-DB
Aunque se sugirió aquí usar DbHelper.remap, la función remap de discourse funcionó bien.
Asegúrate de que los datos se migren. rails uploads:migrate_to_s3
¡Hora de rebake! rails posts:rebake
Haz una copia de seguridad del sitio de nuevo en la máquina/servidor de ‘origen’. Descarga esa última actualización.
Desde el nuevo servidor de destino:
Configura Discourse como se espera, copia app.yml y demás del servidor de origen al nuevo servidor en /var/discourse/containers/ para asegurarte de que la reconstrucción incluya los plugins adecuados, etc. necesarios.
Asegúrate de comentar cualquier entrada de DISCOURSE_BACKUP_LOCATION: s3 en el app.yml, si estás trabajando con copias de seguridad locales. Tuve algunos problemas con S3 que actuaba de forma extraña con archivos de copia de seguridad truncados, así que opté por el enfoque local para una restauración.
Sigue los pasos en Restore a backup from the command line para introducir la copia de seguridad en tu servidor y restaurarla. Incluyendo los pasos de reconstrucción.
Esto fue doloroso para mí de resolver, pero se resolvió una vez que me sumergí en la tabla de uploads en la base de datos. PERO, esto parece haber funcionado, así que…
Lo que a menudo funciona en este tipo de situaciones es deshabilitar temporalmente las cargas de s3 en la instancia original antes de realizar una copia de seguridad. Después de restaurar, puede volver a habilitar s3.