Actualización de PostgreSQL 12

:warning: ¡ADVERTENCIA! Si tu base de datos es muy grande, necesitarás mucho espacio adicional en el disco (2x el tamaño de la base de datos) y debes tener mucho cuidado con esta actualización.

Acabamos de implementar la tan esperada actualización mayor de PostgreSQL. Cualquier administrador de sitio que reconstruya Discourse desde la línea de comandos será actualizado de PostgreSQL 10 a PostgreSQL 12.

Hemos estado ejecutando esta nueva versión durante un tiempo en Meta y todo funciona correctamente. PostgreSQL 12 trae muchas mejoras que Discourse aprovechará automáticamente.

Actualización

Guía de instalación oficial (contenedor único)

En tu próxima reconstrucción, verás este mensaje al final:

Actualización completada
----------------

Para completar la actualización, vuelve a reconstruir usando:

./launcher rebuild app
-------------------------------------------------------------------------------------

¡Eso significa que todo salió bien en la actualización! Solo necesitas ejecutar una nueva reconstrucción para que tu sitio vuelva a funcionar.

Instalación con contenedor de datos

Si estás ejecutando una configuración con un contenedor de datos dedicado basado en la muestra proporcionada en nuestro repositorio discourse_docker, debes asegurarte de apagar PostgreSQL de manera segura y limpia.

Actualmente, tenemos trabajos en segundo plano ejecutando consultas que duran varios minutos, por lo que apagar el contenedor web ayudará a que el contenedor de datos se apague de manera segura.

./launcher stop web_only
./launcher stop data
./launcher rebuild data
./launcher rebuild data
./launcher rebuild web_only

Antes de ejecutar la primera reconstrucción en el contenedor de datos, puedes seguir el registro de PostgreSQL para ver si se apagó correctamente.

Ejecutar tail -f shared/data/log/var-log/postgres/current debería mostrar el siguiente registro si fue limpio:

2020-05-13 18:33:33.457 UTC [36] LOG:  received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG:  worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG:  shutting down
2020-05-13 18:33:33.479 UTC [36] LOG:  database system is shut down

Realizar una actualización manual / entornos con espacio limitado

:warning::warning::warning:
DEBES HACER UNA COPIA DE SEGURIDAD DE POSTGRES_DATA ANTES DE INTENTAR ESTO
:warning::warning::warning:

Si te encuentras en un entorno con espacio limitado y no tienes forma de obtener más espacio, puedes probar lo siguiente:

./launcher stop app #(o ambos web_only y data si ese es tu caso)
mkdir -p /var/discourse/shared/standalone/postgres_data_new
docker run --rm \
	-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/10/data \
	-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/12/data \
	tianon/postgres-upgrade:10-to-12
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
./launcher rebuild app #(o primero data y luego web_only si ese es tu caso)

En mis pruebas, este procedimiento requiere menos de 1x el tamaño actual de tu base de datos en espacio libre.

Posponer la actualización

Si necesitas posponer la actualización durante tu próxima reconstrucción, puedes intercambiar la plantilla de PostgreSQL en tu archivo app.yml cambiando \"templates/postgres.template.yml\" por \"templates/postgres.10.template.yml\".

Esto no se recomienda, ya que algunos administradores de sitios podrían olvidar revertir el cambio después.

Tareas opcionales posteriores a la actualización

Optimización de estadísticas de PostgreSQL

Después de la actualización, el nuevo PostgreSQL no tendrá estadísticas de tabla a mano. Puedes generarlas usando:

cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
VACUUM VERBOSE ANALYZE;
\q
exit
exit

O esta versión de una sola línea de la anterior:

/var/discourse/launcher run app "echo 'vacuum verbose analyze;' | su postgres -c 'psql discourse'"

Limpieza de datos antiguos

Para una instalación estándar, puedes eliminar los datos antiguos en formato PG10 con el siguiente comando:

cd /var/discourse
./launcher cleanup

Si tienes un contenedor de datos separado, necesitarás eliminar la copia de respaldo de esta manera:

rm -fr /var/discourse/shared/data/postgres_data_old/

Preguntas frecuentes

El clúster de origen no se apagó limpiamente

Si recibes un error de actualización con el mensaje anterior, puedes probar un enfoque más sencillo para devolverlo a un estado mejor.

Reinicia el contenedor antiguo con ./launcher start app. Espera unos minutos hasta que vuelva a estar activo.

Ahora apágalo nuevamente con ./launcher stop app. Después, sigue los registros para ver si fue una limpieza adecuada:

tail -f shared/data/log/var-log/postgres/current
2020-05-13 18:33:33.457 UTC [36] LOG:  received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG:  worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG:  shutting down
2020-05-13 18:33:33.479 UTC [36] LOG:  database system is shut down

Si los registros se ven como arriba, ahora puedes intentar actualizar nuevamente usando ./launcher rebuild app.

Los valores de lc_collate para la base de datos “postgres” no coinciden

Este error ocurre si estás utilizando configuraciones regionales no predeterminadas para tu base de datos. Se ha reportado que necesitas 3 variables para que tenga éxito. Asegúrate de que la sección env: de tu archivo app.yml tenga las 3 líneas:

  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8

Cambiando en_US.UTF-8 por tu configuración regional.

Cada reconstrucción realiza la actualización nuevamente, es decir, bucle de actualización

Cuando esto ocurre, tus registros de actualización contendrán:

mv: cannot move '/shared/postgres_data' to '/shared/postgres_data_old/postgres_data': Directory not empty
mv: cannot move '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new': Directory not empty

Esto significa que todavía hay archivos de la última actualización pendientes. Mueve esos archivos a otro lugar antes de continuar.

68 Me gusta
Update failed (postgresql)
Trouble with latest update
Discourse Update Probs. Help please
Cant backup because of version mismatch on aws
User profile page and other features page not available
Error after Upgrading
SAML error after upgrade
Updated to latest version: ./analyze_new_cluster.sh message
Discourse 2.5.0.beta5 Release Notes
Problem with upgrading the latest version
UPGRADE OF POSTGRES FAILED - I've tried everything
Trouble with postgre(maybe)
Postgres upgrade success loop due to prior postgres 8 to 10 migration
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade
Failed upgrade from 2.5.0beta4 to 2.5.0beta5
Corrupt indexes in PG12, how do I fix?
PostgreSQL 13 update
Fixing discourse after disk full
LDAP Auth Missing from Plugins
Today error when upgrade from 2.5.1 to 2.5.2, discourse-assign
Discourse for Teams (Alpha Testing summer 2020)
Issue Rebuilding App Failing on Postgres Upgrade
How hard is it to handle Discourse after installation
Primary Postgres database process (postmaster) eating all CPU
Discourse failing to connect to port 3000
Upgrade of postgres failed
Search 502 errors in 2.5.0.beta6
2.6.0 beta 3 update failed on disk and/or memory space
How to backup and restore a whole /var/discourse app folder?
PostgreSQL update wrecked my forum. Please help!
Instead of auto-deleting old replies, make them auto-hide?
Add print CSS for front page and category page?
Site down after failed update: permission denied to create extension "unaccent"
Migrate quickly to separate web and data containers
Rebuild failed - FAILED TO BOOTSTRAP
Old Postgres on Docker Image with two containers: web and data
Can't rebuild due to failed postgres 12 upgrade
Should I also rebuild my data container when upgrading
Old Postgres on Docker Image with two containers: web and data
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade
UPGRADE OF POSTGRES FAILED - I've tried everything
PostgreSQL 15 update
Help! Problem with firewall/permissions and postgre?
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade
Problem with upgrading the latest version
Restore failed at "EXCEPTION: x of y uploads are not migrated to S3. S3 migration failed for db 'default'."
Trouble with latest update
Can't upgrade due to old docker version
Database migration chokes on huge value of a "calendar-details" item in table "post_custom_fields"
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade