Dejar que Discourse lo gestione. Esto requiere tres veces el espacio en disco. Así que, si tu base de datos es de 100 GB, necesitarías 200 GB libres adicionales para realizar la actualización. Obviamente, esto representa un gran problema para quienes tienen instalaciones grandes.
Seguir su procedimiento de “actualización manual”. Esto requiere dos veces el espacio en disco, por lo que si tu base de datos es de 100 GB, necesitarías 100 GB libres adicionales. Esto también es un gran problema para algunos.
En este mensaje, @Falco sugirió usar la opción --link para realizar la actualización en el mismo lugar utilizando enlaces duros. El contenedor de Docker que sugieren usar soporta ese argumento, pero los desarrolladores de Discourse no lo recomiendan en el mensaje.
Entonces, mi pregunta es la siguiente: ¿debería la opción 3 ser:
Ejecutar el comando a continuación, que requeriría una cantidad muy pequeña de espacio en disco adicional. Así que, si tu base de datos es de 100 GB, podría requerir, digamos, 10 GB adicionales. ¿Y de ser así, es este un procedimiento recomendado por los desarrolladores de Discourse, y alguien lo ha hecho realmente antes y ha sobrevivido para contarlo?
Nuevo comando para actualizar en el mismo lugar:
docker run --rm \
-v DIR:/var/discourse/shared/standalone/postgres_data:/var/lib/postgresql \
tianon/postgres-upgrade:12-to-13 \
--link
En comparación con el antiguo comando para actualizar en un nuevo directorio (que requiere el doble de espacio):
P.D.: Habría respondido directamente a ese hilo de actualización a PG13, pero borra los mensajes después de 7 días. ¿Por qué lo tienen configurado así? Sé que hubo mucha discusión cuando esto surgió por primera vez que habría sido útil como referencia.
Si lo han hecho, no lo mencionaron aquí. La mayoría de las instrucciones aquí intentan ser lo más a prueba de errores posible y requieren el menor conocimiento de administración de sistemas. La mayoría de la gente aquí prefiere hacer algo de la forma más segura y probada posible, en lugar de un método diseñado para ahorrar unos pocos dólares.
Si te funciona, puedes actualizar la actualización a PostgreSQL 13 en consecuencia, pero antes de hacerlo, ¿te sientes cómodo recomendando a alguien que no sabe qué es bash que lo haga de esa manera? ¿Estás seguro de que no arruinará su base de datos y que su sitio quedará arruinado para siempre?
La idea es que, si se presenta otra información útil, esta se añada a la publicación original en lugar de pedirle a la gente que lea a través de un año de publicaciones que probablemente sean inútiles o incorrectas.
No, no estoy seguro. No tengo mucha experiencia con PostgreSQL y esperaba que alguno de los desarrolladores de Discourse pudiera garantizar que funcionaría.
Incluso si sí funciona, tampoco lo recomendaría como el procedimiento de actualización predeterminado, ya que el método anterior mantiene una copia separada de la base de datos para permitir la reversión. Sin embargo, si funciona, sería una excelente opción para entornos con restricciones de espacio.
Otra forma sencilla es iniciar un nuevo servidor, migrar los datos y apagar el antiguo. Si es imprescindible utilizar el antiguo, realiza la actualización en un servidor temporal, de modo que puedas hacer una instalación limpia en el servidor original (que probablemente necesite una actualización del sistema operativo) y luego volver a moverlo.
Es seguro, sencillo y está bien documentado. Cientos de personas lo han hecho así.
Sí, pero eso llevaría un día o dos. Durante ese tiempo, podríamos: a) informar a los usuarios que sus publicaciones de este período se perderán, o b) poner el foro en modo solo lectura. Ninguna es una solución ideal.
No creo que el servidor esté caído mucho más tiempo que durante la reconstrucción. Y si te mudas al nuevo servidor y te quedas allí, puedes dejar el servidor antiguo en modo de solo lectura mientras realizas la migración. Si tu preocupación es el tiempo de inactividad, mudarse a un nuevo servidor será mucho, mucho mejor.
Tenemos un foro bastante grande, pero nunca he intentado restaurar una copia de seguridad, así que no sé cuánto tiempo tomaría. De hecho, si lo hiciéramos, nos quedaríamos en el nuevo proveedor. Preferiría evitarlo si es posible, debido al trabajo adicional y las molestias que conlleva.
Otra forma de resolver el problema de la actualización con espacio limitado es hacer una copia de seguridad, eliminar el directorio de postgres con rm -r, reconstruir y luego restaurar la copia de seguridad. Hice esto en un sitio la semana pasada.
No, nunca lo actualicé. Eliminar la base de datos y restaurar la copia de seguridad suena bastante arriesgado. Básicamente, necesitamos que la actualización in situ funcione.
Estamos ejecutando Ubuntu 18.04, que dejará de tener soporte en 2023, así que supongo que en ese momento no tendremos más remedio que migrar a un nuevo host de todos modos, y planeamos afrontar el problema entonces, montar un nuevo host con Ubuntu 22.04 LTS y restaurar desde la copia de seguridad.
Hmm. Podría ser un fracaso. Creo que con el modelo de respaldo, una de las copias está comprimida, ¿lo que podría marcar la diferencia? Y el sitio en el que lo hice tenía copias de seguridad en S3. Y era un sitio de prueba, por lo que las apuestas eran bajas si había algún problema.
Excepto que las copias de seguridad se usan mucho más a menudo en muchas más situaciones que la actualización in situ. Lo considero mucho más seguro.
Quizás, pero no tengo mucha experiencia con postgres y no me siento cómodo haciéndolo. Restaurar todo el sitio desde una copia de seguridad en una VM completamente diferente, eso sí me siento cómodo haciéndolo, sin embargo, significaría perder publicaciones durante las horas que lleve restaurar, así que tampoco estoy muy entusiasmado con eso. Pero como 18.04 está dejando de recibir soporte, no tendré muchas opciones el próximo año.
A menos que tu base de datos sea de decenas de gigabytes, no tardará horas. Y pondrás el foro en modo de solo lectura antes de hacer una copia de seguridad y restaurar, por lo que no perderás ninguna publicación. No es tan difícil de hacer con prácticamente ningún tiempo de inactividad, solo tiempo de solo lectura.
root@forum-app:/shared/postgres_data# du -sh
97G .
No lo pondría en modo de solo lectura, pondría un aviso diciendo a la gente que sus publicaciones de hoy son efímeras. Mejor dejar que hablen de ello aunque esas publicaciones se pierdan, en mi opinión.
Para entonces, también tendrás acceso al chat integrado de Discourse, una función que se lanzará en la versión 2.9 (posiblemente desactivada por defecto, pero en beta y compatible para su uso).