Estamos ejecutando una instalación de Discourse más grande en una configuración VPS que básicamente funciona muy bien para nosotros. En términos de rendimiento de CPU/Memoria, tenemos margen. Sin embargo, el espacio en disco es un problema, no en el día a día, sino cuando se trata de actualizar Postgres, por ejemplo (la actualización de 13-">15 está pendiente por eso), carecemos de espacio y no podemos expandirnos fácilmente.
Sé que hay otras opciones para la actualización de postgres, pero considera esto más como una pregunta general.
Estamos ejecutando en Hetzner, donde el almacenamiento en red está disponible fácilmente para uso temporal.
En nuestro servidor de prueba, ahora estoy jugando con hacerlo funcionar de forma temporal, primero para restaurar una copia de seguridad del sitio en vivo, luego para probar la actualización de Postgres. Hasta ahora no he tenido éxito.
Ya intenté crear enlaces simbólicos, pero noté que no funcionó y también leí aquí en alguna parte que no es la forma recomendada. También intenté mover la carpeta /shared de /var/discourse/shared/standalone a /mnt/ext-storage/standalone y moví los archivos allí, desafortunadamente no sin problemas. Ni siquiera puedo terminar la compilación.
¿Hay alguna manera que funcione para este tipo de casos? Soy consciente de que el rendimiento de la unidad es mucho peor que la unidad local, pero no estoy planeando ejecutar el foro en ella. Realmente me gustaría tener una forma cómoda de usarlo para ciertos escenarios.
Si tu objetivo es hacer la actualización, lo más fácil es iniciar una nueva VM y migrar a ella. Te saltas la necesidad de actualizar la base de datos y obtienes un nuevo sistema operativo en tu VM, lo cual probablemente necesites hacer de todos modos.
Si tus copias de seguridad están en s3, es muy sencillo congelar la antigua, hacer una copia de seguridad y restaurarla en la nueva máquina.
Si hetzner tiene algún tipo de IP permanente que se pueda asignar a diferentes servidores, ni siquiera necesitarás cambiar el DNS.
Querrás saber que puedes construir un nuevo servidor para que, si alguna vez tienes que hacerlo por alguna razón, puedas hacerlo. Esta es una oportunidad perfecta para practicar.
En realidad, esta no es una opción. De todos modos, no se está quedando sin espacio para las necesidades diarias. Además, ahora mismo estamos en un disco de 600 GB y usamos ~50%. No hay una opción más grande, al menos no en Hetzner.
Por eso pregunté explícitamente por el disco externo.
No estaba sugiriendo cambiar a una unidad más grande, solo obtener un servidor nuevo exactamente igual a ese. Instala Discourse, restaura tu base de datos.
Esa es una muy buena pregunta.
Sí. Cada reconstrucción crea un nuevo contenedor y cada uno de ellos ocupa espacio. Si nunca lo has hecho, podrías liberar decenas de GB.
Nuestra guía de actualización incluye una guía para tu caso de uso exacto.
Hemos añadido esta opción para personas que se encuentran en la misma situación que tú. ¡Solo asegúrate de guardar una copia de seguridad fuera del sitio antes de intentar esto!
Puede ser útil mantener tus subidas, o, por ejemplo, /var/discourse/shared/web_only en almacenamiento de red. Necesitas editar el archivo yml para que apunte a él en lugar de usar un enlace simbólico (el enlace simbólico no funciona porque el contenedor no puede acceder al lugar al que apunta tu enlace simbólico).
Luego, si te mudas a una nueva VM, puedes simplemente volver a montar ese almacenamiento de red en lugar de copiarlo.
No recomiendo el almacenamiento de red para la base de datos, ya que es más lento.
Creo que vale la pena desglosar cuál es tu uso. El tamaño real de tu base de datos podría no ser tan grande, si la mayor parte de tu uso son cargas, y es solo la parte de la base de datos la que exige quizás 3 veces más espacio durante la actualización.
Una cosa que puedes comprobar es el tamaño relativo de una copia de seguridad con descargas en comparación con una copia de seguridad sin descargas.
O, usa la línea de comandos. Aquí tienes una salida de mi foro, bastante pequeño:
Debería haber sido más preciso inicialmente, pero no esperaba recibir comentarios tan generalizados.
Nuestras cargas y copias de seguridad están en S3. El tamaño de la base de datos en el sistema en vivo es de aproximadamente 230 GB. Las copias de seguridad comprimidas son de alrededor de 25 GB, creo.
Creo que sí. No tengo claro qué lo activa. Creo que hacer uno adicional no hace daño y podría ahorrarte algo de espacio. Se recomienda hacerlo después de la actualización si la haces en el mismo lugar. He visto que ha limpiado considerable espacio algunas veces.
Si tu base de datos tiene 230 GB, definitivamente la restauraría en un servidor nuevo. El tiempo de inactividad para leer y escribir 230 GB será significativo.