Estamos ejecutando PostgreSQL v12, ya que la actualización a v13 requiere demasiado espacio en disco. Parece que la compatibilidad con v12 podría haberse roto. ¿Es esto intencional? De ser así, significa que nunca podremos volver a actualizar Discourse.
Ejecutar ./launcher start app nos devolvió la conectividad, así que por ahora no es un problema en producción, pero no poder actualizar ni siquiera por razones de seguridad sería muy grave para nosotros.
En app.yml:
- "templates/postgres.12.template.yml"
Al ejecutar ./launcher rebuild app:
FAILED
--------------------
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/13/main/pg_hba.conf
Ubicación del fallo: /pups/lib/pups/replace_command.rb:8:in `read'
replace failed with the params {"filename"=>"\/etc\/postgresql\/13\/main\/pg_hba.conf", "from"=>"\/^host.*all.*all.*::1\\\\/128.*$/", "to"=>"host all all ::\/0 md5"}
0ba8112e6efa1ac2dd75af8a1da8eea0937e7aefbca2df28b22d27e9608d1479
** FALLO AL INICIAR ** por favor, desplázate hacia arriba y busca mensajes de error anteriores; puede haber más de uno.
./discourse-doctor puede ayudar a diagnosticar el problema.
Actualmente estamos ejecutando la versión 2.8.0.beta4 75b0d6df93.
¿Por qué no haces una copia de seguridad, creas una instancia completamente nueva de Discourse (que debería tener Postgres 13 por defecto), restauras la copia de seguridad y reasignas el servidor en DNS?
Es menos aterrador que un trabajo molesto que preferiría evitar, combinado con tener que decir a mi foro que perderán un día o dos de publicaciones. Idealmente, me gustaría que los chicos de Discourse digan: “Por supuesto que seguimos trabajando en PG12, eso es solo un error, lo solucionaremos”.
Dicho esto, ya no ejecutamos PG12, por lo que podríamos introducir alguna sintaxis SQL exclusiva de PG13+ en el núcleo en cualquier momento, así que sería una buena idea programar la actualización algún día.
Lo revisaré en cuanto tome otra instantánea de mi máquina virtual.
Es realmente molesto que PG requiera una gran cantidad de espacio en disco para actualizar. No tengo este problema con Oracle ni con MySQL; ellos simplemente actualizan en el mismo lugar.
pg_upgrade ofrece una única bandera --link para permitir actualizaciones en el mismo lugar.
Decidimos no usarla en nuestro script de actualización de lanzamiento “amigable para principiantes”, ya que el 99% de las instalaciones se ejecutan en una máquina virtual en la nube que puede ampliar el tamaño del disco de manera fácil y económica.
Sin embargo, está disponible como una opción para quienes prefieren realizar la actualización manualmente para ahorrar espacio en el disco durante el proceso.
Se proporcionaron 2 soluciones; según recuerdo, una necesitaba básicamente el triple del tamaño de toda la base de datos y la otra necesitaba como el doble. Si se puede hacer in situ, documentarlo sería muy útil.
