Mover un sitio de Discourse a otro VPS con rsync

Wiki de la comunidad Administradores de sistemas
,
21

¡Hola!

Estoy intentando seguir los pasos de @scottfsmith. Logro hacer rsync. No me importa obtener los cambios más recientes a través de rsync, ya que solo estoy probando una nueva versión de Linux con mi sitio existente para ver si todos mis complementos funcionan. Así que no estoy haciendo la segunda ejecución de rsync. Luego, intentar ./launcher rebuild app produce errores.

2022-12-13 14:43:01.974 UTC [59] LOG:  la base de datos se interrumpió; última vez conocida en 2022-12-13 10:23:29 UTC
2022-12-13 14:43:02.075 UTC [59] LOG:  registro de punto de control primario no válido
2022-12-13 14:43:02.075 UTC [59] PANIC:  no se pudo localizar un registro de punto de control válido
2022-12-13 14:43:03.137 UTC [56] LOG:  el proceso de inicio (PID 59) fue terminado por la señal 6: Abortado
2022-12-13 14:43:03.137 UTC [56] LOG:  iniciando aborto debido a fallo del proceso de inicio
2022-12-13 14:43:03.231 UTC [56] LOG:  el sistema de base de datos está apagado
I, [2022-12-13T14:43:06.699692 #1]  INFO -- : 
I, [2022-12-13T14:43:06.711862 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
createdb: error: no se pudo conectar a la base de datos template1: no se pudo conectar al servidor: No existe tal archivo o directorio
	¿Está el servidor ejecutándose localmente y aceptando
	conexiones en el socket de dominio Unix \"/var/run/postgresql/.s.PGSQL.5432\"?
I, [2022-12-13T14:43:06.917008 #1]  INFO -- : 
I, [2022-12-13T14:43:06.917421 #1]  INFO -- : > su postgres -c 'psql discourse -c \"create user discourse;\"' || true
psql: error: no se pudo conectar al servidor: No existe tal archivo o directorio
	¿Está el servidor ejecutándose localmente y aceptando
	conexiones en el socket de dominio Unix \"/var/run/postgresql/.s.PGSQL.5432\"?
I, [2022-12-13T14:43:07.007654 #1]  INFO -- : 
I, [2022-12-13T14:43:07.008155 #1]  INFO -- : > su postgres -c 'psql discourse -c \"grant all privileges on database discourse to discourse;\"' || true
psql: error: no se pudo conectar al servidor: No existe tal archivo o directorio
	¿Está el servidor ejecutándose localmente y aceptando
	conexiones en el socket de dominio Unix \"/var/run/postgresql/.s.PGSQL.5432\"?
I, [2022-12-13T14:43:07.087098 #1]  INFO -- : 
I, [2022-12-13T14:43:07.087319 #1]  INFO -- : > su postgres -c 'psql discourse -c \"alter schema public owner to discourse;\"'
psql: error: no se pudo conectar al servidor: No existe tal archivo o directorio
	¿Está el servidor ejecutándose localmente y aceptando
	conexiones en el socket de dominio Unix \"/var/run/postgresql/.s.PGSQL.5432\"?
I, [2022-12-13T14:43:07.167221 #1]  INFO -- : 
I, [2022-12-13T14:43:07.168041 #1]  INFO -- : Terminando procesos asíncronos

No puedo entender lo suficiente de esto para encontrar una solución. Algunas búsquedas sugieren que el contenedor necesita ser detenido, pero no está iniciado. ¿Alguna idea?

Gracias
David

22

Me gustaría configurar un servidor de preparación para resolver tu problema particular.

Por esos errores, parece que la base de datos está rota. Necesitas detener la base de datos para poder obtener un conjunto de datos válido para que funcione. El segundo rsync no es opcional.

1 me gusta
23

¡Guau!

¡Un hilo de cuatro años y una respuesta en 3 minutos! :slight_smile:

De todos modos, básicamente es un servidor de staging al que me dirijo y estoy usando este método rsync. Pero, ¿recomiendas no hacerlo de esta manera con rsync sino usar una copia de seguridad? Recuerdo no haber obtenido toda la configuración de Personalización de un servidor de staging anterior que configuré, pero tal vez me equivoque.

Gracias

1 me gusta
24

Eso es lo que describe ese enlace.

Todo, excepto los plugins (que están en tu app.yml), está en la copia de seguridad; la base de datos y las cargas son todo lo que hay.

1 me gusta
25

Por mis pruebas de este método, parece ser suficiente con ./launcher stop app antes del rsync inicial. Por supuesto, una de las razones para usar este método parece ser mantener el foro en funcionamiento en el servidor antiguo el mayor tiempo posible, en cuyo caso, obviamente, es necesario ejecutar el segundo rsync para mantener la coherencia. Pero para el proceso relativamente común de mover un foro a un servidor y/o host diferente donde un breve tiempo de inactividad es aceptable, realmente me gusta la simplicidad y portabilidad de este método.

1 me gusta
26

Correcto.

Correcto.

Mi método preferido es hacer el rsync de las cosas de let’s encrypt y ssl, poner el servidor antiguo en modo de solo lectura, hacer una copia de seguridad, restaurar en el nuevo servidor y luego cambiar el DNS (o mejor, una IP estática cuando el nuevo servidor esté listo).

Pero si no te importa un poco de tiempo de inactividad, tu manera es genial.

2 Me gusta
27

Planeo migrar a un nuevo VPS en enero después de algunos problemas recientes al actualizar Discourse en mi antiguo Ubuntu.

Mis preguntas sobre la migración de un antiguo droplet de Digital Ocean a un nuevo droplet de Digital Ocean son:

  • Planeo reducir el TTL del registro DNS A el día antes de mi migración a algo pequeño, como 5 minutos. ¿Suena razonable?

  • La primera publicación en este hilo se editó por última vez en junio de 2016. ¿Sigue siendo válida y correcta?

  • ¿Este método rsync también copiará toda la base de datos del VPS antiguo al VPS nuevo?
    – Estamos en una instalación estándar

  • ¿Se copiará también el certificado SSL existente de Let’s Encrypt? ¿El certificado SSL está vinculado o relacionado de alguna manera con una dirección IP? ¿Continuará renovándose automáticamente? ¿Alguna advertencia aquí?

  • ¿En qué momento debo cambiar el registro DNS A público para que apunte al nuevo VPS?
    – Y también cambiar el TTL de nuevo a algo más alto

28

Todo eso es correcto.

Si está utilizando algo que permite tener una IP permanente que se puede asignar a varias máquinas virtuales, entonces puede hacerlo para no depender del DNS para realizar el cambio.

La única precaución que agregaría es apagar el sitio antiguo para el rsync final y luego reiniciarlo en modo de solo lectura mientras el nuevo se reconstruye.

29

La primera publicación todavía muestra la ruta incorrecta /var/discourse/:

¿Podrías editar/actualizar por favor?

30

@Richie, @JammyDodger ahora ha convertido esto en una wiki :+1:

2 Me gusta
31

Hoy migré a un nuevo VPS y pensé en compartir mis experiencias, ya que parece que últimamente bastantes personas se encuentran con el bloqueo del sistema operativo de versión antigua en sus actualizaciones :blush:

Estoy en Digital Ocean, así que creé un nuevo droplet.

VPS antiguo = Ubuntu Server 18.04.6 LTS

Nuevo VPS = Ubuntu Server 23.10

Hice el mantenimiento habitual en el nuevo VPS; edita según tus necesidades:

Apt-get update

Apt-get upgrade

Apt-get install fail2ban

ufw default deny incoming

ufw default allow outgoing

ufw allow ssh

ufw allow http

ufw allow https

ufw enable

Luego creé un nuevo directorio vacío para Discourse:

sudo mkdir -p /var/discourse

Entonces instalé Docker:

wget -qO- https://get.docker.com/ | sh

Luego cambié el TTL de mi DNS de 30 minutos a 10 minutos (el mínimo que permite GoDaddy).

En mi servidor antiguo, descargué una copia local de la copia de seguridad de la base de datos de Discourse de anoche (nunca se tienen suficientes copias de seguridad locales). También descargué una copia de app.yml a mi PC local.

Como sugirieron algunas personas anteriormente, hice un rsync de “root a root”. Usé la dirección IP en lugar del nombre de host, para evitar confusiones de DNS. También, como se sugirió anteriormente, usé los modificadores -avz:

rsync -avz root@old.ip.address.here:/var/discourse /var

Como referencia, mi carpeta de Discourse tiene 25 GB.

Tardó ~25 minutos en sincronizarse con rsync desde el servidor antiguo al nuevo. Esto fue simplemente entre dos droplets de Digital Ocean en la misma región LON1. Tus experiencias pueden variar.

Después de sincronizar con rsync e intentar una reconstrucción, me encontré con el mismo error que @piratdavid encontró sobre postgres database system is shut down.

Así que luego detuve la aplicación en el VPS antiguo:

./launcher stop app

E hice otro rsync, solo para los cambios esta vez:

rsync -avz --delete root@old.ip.address.here:/var/discourse /var

Luego volví a iniciar la aplicación de Discourse antigua y muy rápidamente la puse en Modo de Mantenimiento; esto es para que la gente todavía pueda acceder a ella y vea el mensaje de advertencia de mantenimiento habitual.

Esto también me da tiempo para trabajar en el nuevo VPS :blush:

Actualicé mi archivo HOSTS en mi PC local para poder acceder a Discourse en el nuevo VPS sin advertencias/problemas del navegador.

En el nuevo VPS, ejecuté:

./discourse-setup

Esto fue para que pudiera actualizar la configuración de RAM y CPU en el archivo app.yml automáticamente.

Luego hice una reconstrucción de la aplicación en el nuevo VPS:

./launcher rebuild app

Hice algunas pruebas de humo, todo bien.

DNS actualizado - trabajo hecho.

Gracias por el tema detallado, a todos :smiley:

3 Me gusta
32

Gracias chicos, la primera publicación se actualizó con las rutas de /var/discourse.

1 me gusta
33

Si alguien tiene problemas para hacer rsync de raíz a raíz porque tal vez deshabilitó el inicio de sesión de root en el servidor antiguo, o simplemente quiere hacerlo como un usuario que no es root, encontré esta publicación útil para averiguar cómo usar sudo en el servidor remoto: https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

Digamos que tienes un usuario, discourse, en ambos lados que tiene privilegios de sudo. En la máquina remota, editarás el archivo /etc/sudoers con sudo visudo. Añadirás la línea:

discours TODOS=NOPASSWD:/usr/bin/rsync

Luego, en la nueva máquina, ejecutarás (como tu usuario no root):

sudo rsync -avz --delete --rsync-path="sudo rsync" discourse@old.ip.address.here:/var/discourse /var

Esto te permitirá ejecutar todo lo descrito aquí como usuarios no root. Si mantienes el servidor antiguo, volvería al archivo /etc/sudoers y eliminaría la línea que acabas de agregar.

1 me gusta
34

Si entiendo correctamente, esto permite que la mayor parte de la transferencia ocurra mientras Discourse está en funcionamiento. La estrategia de restauración a partir de una copia de seguridad requiere al menos acceso de solo lectura para la copia de seguridad y mover la copia de seguridad al nuevo servidor (o transferir a través de un bucket S3). Para sitios grandes, esto puede resultar en un tiempo considerable de solo lectura que la estrategia rsync evita de manera ordenada.

Podría ser posible exprimir un poco más de tiempo de actividad evitando apagar PostgreSQL en el sistema antiguo y “arreglando” el problema en el nuevo sistema con pg_resetwal. NB: No he probado esto y dejar que la base de datos se apague correctamente es casi con certeza una mejor idea.

Me pregunto si hay alguna forma de iniciar Discourse en modo de solo lectura. Sospecho que la forma más rápida es a través de la línea de comandos después de que el contenedor esté en funcionamiento.

En cualquier caso, ¡gracias por compartir tu experiencia! Parece un proceso útil para tener a mano. :slight_smile:

35

Muchísimo.

Tan útil de hecho, que me tienta a hacerlo todo de nuevo para crear un entorno de staging (en un VPS de menor especificación), solo para probar y anticipar cualquier problema antes de implementar cualquier cambio en producción.

1 me gusta
37

Hola,

Estoy intentando seguir este proceso en una instancia de Discourse más antigua que ahora soy responsable de mantener, migrando de Ubuntu EOL a algo más reciente porque cualquier actualización falla si la intento in situ. Aunque el rsync fue exitoso, postgres no se inicia citando problemas de propiedad de archivos. Ejecutar el rsync como root con las opciones de preservación de propiedad no corrigió esto (la propiedad y los permisos de los archivos ahora coinciden con la fuente, lo comprobé), y debido a que el bootstrap ha fallado y no tengo un contenedor en ejecución, no puedo intentar solucionarlo como se describe en Update failed (postgresql) - #7 by noezDE.

¿Cuál es la mejor manera de normalizar lo que sea que postgres esté esperando?

38

¿Puedes chown los archivos fuera del contenedor? Debería ser posible si tienes permisos de root/sudo.

39

Claro, ¿pero a qué? Desde fuera del contenedor, los permisos son correctos y también son un sinsentido aullante.

Fuente (funcionando):

root@ip-[...]:/var/discourse/shared/standalone# ls
total 54492
drwxr-xr-x 15 root       root         4096 Oct 22  2021 .
drwxr-xr-x  3 root       root         4096 Feb 28  2017 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Feb 28  2017 backups
-rw-r--r--  1 root       root     55730645 Mar 15  2017 discussion.json
drwx------  7 root       root         4096 Mar  6  2017 letsencrypt
drwxr-xr-x  4 root       root         4096 Feb 28  2017 log
drwxr-xr-x  2 _apt       netdev       4096 Feb 28  2017 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:39 postgres_data
drwx------ 20 _apt       netdev       4096 Oct 22  2021 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Apr  5  2018 postgres_data_older
drwxrwsr-x  5 _apt       netdev       4096 Sep 15 04:39 postgres_run
drwxr-xr-x  2 lxd        lxd          4096 Sep 16 01:03 redis_data
drwxr-xr-x  2 root       root         4096 Mar  6  2017 ssl
drwxr-xr-x  4 root       root         4096 Feb 28  2017 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:39 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Apr 13  2017 uploads

Destino (roto):

root@ip-[...]:/var/discourse/shared/standalone# ls -al
total 54488
drwxr-xr-x 15 root       root         4096 Sep 15 04:31 .
drwxr-xr-x  3 root       root         4096 Sep 15 04:27 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Sep 15 04:27 backups
-rw-r--r--  1 root       root     55730645 Sep 15 04:27 discussion.json
drwx------  7 root       root         4096 Sep 15 04:27 letsencrypt
drwxr-xr-x  4 root       root         4096 Sep 15 04:27 log
drwxr-xr-x  2 _apt       netdev       4096 Sep 15 04:27 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:27 postgres_data
drwx------ 20 _apt       netdev       4096 Sep 15 04:30 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Sep 15 04:31 postgres_data_older
drwxrwsr-x  5 messagebus tss          4096 Sep 15 04:31 postgres_run
drwxr-xr-x  2 uuidd      _ssh         4096 Sep 15 04:38 redis_data
drwxr-xr-x  2 root       root         4096 Sep 15 04:32 ssl
drwxr-xr-x  4 root       root         4096 Sep 15 04:31 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:31 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Sep 15 04:31 uploads

Supongo que estos IDs tendrían más sentido dentro del contenedor, ¿quizás?

40

Sí, intenté forzar las ID numéricas de ls -aln y todavía obtengo el mismo error.

2024-09-16 01:21:27.237 UTC [36] FATAL: data directory "/shared/postgres_data" has wrong ownership

No sé qué es lo que quiere.

41

Creo que tuve un error similar recientemente.

Una suposición es que el contenedor antiguo y el nuevo tienen diferentes entradas en /etc/passwd. Podrías comparar esos archivos, supongo.

Creo que tu mejor opción puede ser restaurar desde una copia de seguridad. No recuerdo si lo hice o si v hizo algo 777.