Por favor, ¿podrías indicarnos qué archivo debemos editar en el archivo de respaldo tar?
Hay un archivo dump.sql incluido dentro de los archivos comprimidos. Debes modificarlo y luego volver a empaquetar la versión modificada. También resolví mis otros problemas modificándolo: eliminé algunos campos personalizados problemáticos que causaban cierres inesperados después del inicio de sesión.
Gracias.
Intentaré descargar la copia de seguridad, descomprimirla y modificar ese archivo siguiendo tus instrucciones.
Da bastante miedo tener que hacer todo eso para restaurar una copia de seguridad.
Supongo que es un error de la nueva versión.
Pero las copias de seguridad y su restauración son piedras angulares de un plan de recuperación ante desastres.
Deberían ser lo más robustas posible, y un error en esos procesos tiene un gran impacto.
Bueno, pude realizar la restauración sin cambiar nada en el archivo de copia de seguridad.
Solo lo intenté varias veces y, curiosamente, en una de ellas la restauración se realizó sin errores.
Me expulsaron de Discourse y no funcionó hasta que creé una aplicación de reconstrucción del lanzador.
Pero ahora funciona correctamente.
Un problema extraño.
Esto todavía me está dando problemas al restaurar mi foro desde la copia de seguridad. Han pasado varias semanas y la función de restauración desde copia de seguridad parece seguir fallando.
¿Hay alguna solución para esto?
Por lo que puedo ver, se alterna entre actualizar, verificar el formato de las tablas, asegurarse de que todo sea similar entre el origen y el servidor, y observar cómo falla varias veces; y eso podría o no funcionar sin algunas ediciones menores en la base de datos.
He migrado con éxito 2 de 3 sitios y me veo obligado a dedicar menos de una hora al día a esto por mi propia tranquilidad. He comenzado a hablar con los clientes sobre los problemas que esto podría causar en el futuro en situaciones similares. encogerse de hombros
Simplemente insisto en restaurar y logré que funcionara.
El error se queja de una columna que no existe en la tabla de perfil de usuario.
Pero debe tratarse de un error de tiempo de espera o algo similar en el lado de la base de datos, quizás un bug en el lado de PostgreSQL. Si la columna no existe, no se crea por sí sola cuando insistes en restaurar.
Jaromir dice que cambiar el script soluciona el problema.
Nadie de los desarrolladores de Discourse aquí parece haberse preocupado por este problema, pero es un error extraño y muy inquietante, ya que afecta tu plan de recuperación ante desastres.
Quizás el tema haya pasado desapercibido entre los demás.
No ha pasado desapercibido. Será lo primero que revisaré mañana.
Y estoy empezando a trabajar en mejorar las copias de seguridad y la restauración, porque nadie debería tener que preocuparse por esos aspectos en caso de un desastre o simplemente cuando desee migrar a un nuevo servidor.
Genial. Gracias.
Me alegra saberlo.
Gracias, Gerhard. No sé si ahora te interese, pero también estoy teniendo problemas con un sitio que usa PG 11 con GCP. Podría valer la pena revisarlo, ya que podría afectar la futura migración a PG12, que, según tengo entendido, debería ocurrir este otoño.
Acabo de actualizar dos instancias que comparten un bucket de copias de seguridad en S3. Ejecuté una copia de seguridad en una e intenté restaurarla en la otra, pero obtuve:
No hay migración con el número de versión 20191007140446.
PostgreSQL 11 y 12 no son compatibles actualmente.
Vale, he instalado la última versión de Discourse (tests-passed) en un droplet y la restauración de copias de seguridad (incluidas las cargas, sin usar S3 para ello) funcionó sin problemas.
Si aún tienes problemas durante una restauración, sigue estos pasos:
-
Reconstruye el contenedor:
cd /var/discourse git pull ./launcher rebuild app -
Restaura la copia de seguridad mediante la interfaz web o la línea de comandos:
cd /var/discourse ./launcher enter app discourse enable_restore discourse restore <filename>
Si no funciona, publica el número de versión del archivo de copia de seguridad que intentas restaurar, así como el mensaje de error que ves durante la restauración.
Ambos sitios están en la versión 2.4.0.beta6 (8fc0cc9aaa). Las copias de seguridad (pero no las cargas) están en S3.
discourse restore devuelve:
Starting restore: wonderful-community-2019-10-10-184822-v20191007140446.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2019-10-10-211121 exists...
Downloading archive to tmp directory...
Unzipping archive, this may take a while...
EXCEPTION: Compression::Strategy::ExtractFailed
/var/www/discourse/lib/compression/gzip.rb:49:in `block in extract_file'
/var/www/discourse/lib/compression/gzip.rb:45:in `open'
/var/www/discourse/lib/compression/gzip.rb:45:in `extract_file'
Por supuesto, y creo que ese sitio se conformará con copias de seguridad directas de la base de datos en GCP de todos modos, pero en algún momento Sam dijo que estaba ejecutando PG 11 en su sitio de desarrollo y que le interesaría saber sobre problemas con PG11.
@pfaffman Por favor, aumenta la configuración del sitio decompressed_file_max_size_mb (está oculta). Actualmente, el valor predeterminado es de 1 GB.
Tengo una PR lista para aumentar el valor predeterminado a 100 GB, pero aún no se ha fusionado:
Gracias, @Roman. Bueno, eso resolvió ese problema.
Pero ahora tengo un montón de invalid command \N (y llenaron el búfer antes de que pudiera ver lo que venía antes), pero quizás
ERROR: error de sintaxis cerca de "Shiny"
LINE 1: Shiny contest submission 2019-01-07 20:00:05.570573 2019-01-...
^
EXCEPTION: psql falló
/var/www/discourse/lib/backup_restore/restorer.rb:324:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
es lo que necesitas saber.
Sí, creo que eso es causado por PG11.
¡Si fuera la instancia pg11, estaría de acuerdo! Pero esta es una instalación estándar de 2 contenedores.
¡Espera! Hay una incompatibilidad de versiones.
root@community:/var/discourse# ./launcher enter data root@staging-data:/# psql --version
psql (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)
¡El que estoy restaurando es la versión 10.9! Apuesto a que es eso. (Creo que pg11 falla de manera similar, pero en ese caso estoy intentando restaurar en la misma instancia).
Mañana actualizaré los contenedores de datos y te avisaré. Gracias por tu ayuda.
Bueno, actualicé ambos a 10.10 (usando las plantillas de datos estándar), pero aún así obtuve los mensajes de invalid command.
Cuando comenzaron los errores de invalid command, forcé la finalización del script de restauración. Los intentos posteriores de restaurar (para obtener el primer error antes de los mensajes de invalid command) resultaron en:
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: la relación "theme_fields" no existe
Luego ejecuté un rake db:migrate en ambas instancias, realicé una nueva copia de seguridad y la restauración tuvo éxito. ¿Quizás se pasó por alto alguna migración en algún momento?
(Después de cambiar la configuración mencionada anteriormente, aquí están las instrucciones completas para quienes puedan necesitarlas en el breve lapso de tiempo antes de que sean innecesarias)
./launcher enter app
rails c
SiteSetting.decompressed_file_max_size_mb=1000000
Acabo de tener otro fallo. En este caso, ambos son 2.4.0.beta6 (uno es 2c011252f1, el otro puede ser un poco más reciente).
Estoy restaurando desde S3. He probado tanto con como sin subidas. Ambos parecían funcionar y luego fallaron así:
...
COPY 11871
COPY 3689
COPY 0
COPY 36550
COPY 0
COPY 14736
/usr/local/bin/discourse: línea 2: 3232 Terminado RAILS_ENV=production sudo -H -E -u discourse bundle exec script/discourse "$@"
¿Es este el único mensaje que estás recibiendo?
¿Qué pasa si intentas eliminar cualquier dependencia de S3 y copiar primero el archivo de copia de seguridad a tu equipo local?
@pfaffman, podría ser útil saber que los dos (o tres) problemas de restauración que has publicado en este tema no son casos del error sobre el que se trataba originalmente este tema (el problema PG::UndefinedColumn: ERROR). Podrías considerar abrir nuevos temas para estos, ya que son claramente problemas diferentes.