Hola a todos,
Vi la guía de actualización a PostgreSQL 18 para Discourse autoalojado:
Se menciona que el proceso de actualización requiere una cantidad significativa de espacio adicional en disco, así que comencé a revisar el uso de mi disco y el tamaño de la base de datos antes de intentar la migración.
Mi uso actual de disco:
/dev/sda1 97G 44G 54G 45% /
El tamaño de mi base de datos de Discourse es de aproximadamente 21 GB. Descubrí que la mayor parte del espacio no está ocupado por publicaciones, sino por varias tablas de estadísticas y registros.
Las tablas más grandes son:
topic_views 5.2 GB
post_timings 1.9 GB
browser_pageview_events 1.8 GB
ai_api_audit_logs 1.6 GB
incoming_links 1.5 GB
user_auth_token_logs 1.2 GB
Para comparar:
posts 844 MB
Verifiqué los rangos de datos:
topic_views:
2015-04-03 ~ 2026-08-03
incoming_links:
2015-04-09 ~ 2026-08-03
user_auth_token_logs:
2021-08-15 ~ 2026-08-03
ai_api_audit_logs:
2026-02-04 ~ 2026-08-03
browser_pageview_events:
2026-05-28 ~ 2026-08-03
Entiendo que estas tablas tienen propósitos diferentes, pero no estoy seguro de qué períodos de retención se consideran razonables para una instancia de Discourse en producción.
Mis preguntas:
-
Para
user_auth_token_logs, ¿cuánto tiempo suelen conservar los registros?- ¿6 meses?
- ¿1 año?
- ¿Más tiempo para auditorías de seguridad?
-
Para tablas como
incoming_links,topic_viewsypost_timings, ¿suelen conservar todos los datos históricos o eliminan periódicamente los registros más antiguos? -
¿Existe algún procedimiento de limpieza o mantenimiento recomendado antes de una actualización mayor de PostgreSQL?
Hasta ahora, no he eliminado nada. Solo ejecuté:
vacuumdb --analyze discourse
Mi objetivo es liberar espacio en disco innecesario antes de actualizar a PostgreSQL 18, manteniendo la funcionalidad normal de Discourse y la información de auditoría útil.
Agradecería cualquier recomendación o experiencia práctica de personas que gestionan sitios de Discourse autoalojados.
¡Gracias!