Mover un sitio de Discourse a otro VPS con rsync

Lo he conseguido, y Postgres (¡y Discourse!) parecen estar contentos.

Los limpié manualmente, haciendo las URL únicas con patrones ** según correspondía. Podría ser solo una caché inofensiva donde podría haber eliminado los duplicados, pero no quería arriesgarme.

En mi caso, solo era un índice, por lo que reconstruir todos los índices probablemente fue excesivo, pero sinceramente me sentí mejor sabiendo que había detectado todo.

Después de algunas ejecuciones fallidas de reconstrucción, que tardan unos 30 segundos cada vez e informan de un solo problema, esta fue mi magia SQL para obtener una lista completa de elementos problemáticos al instante:

discourse=# select topic_id, post_id, url, COUNT(*) from topic_links GROUP BY topic_id, post_id, url HAVING COUNT(*) > 1 order by topic_id, post_id;
 topic_id | post_id |                          url                          | count 
----------+---------+-------------------------------------------------------+-------
    19200 |   88461 | http://hg.libsdl.org/SDL/rev/**533131e24aeb           |     2
    19207 |   88521 | http://hg.libsdl.org/SDL/rev/44a2e00e7c66             |     2
    19255 |   88683 | http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org |     2
    19255 |   88683 | http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org |     2
    19523 |   90003 | http://twitter.com/Ironcode_Gaming                    |     2
(5 rows)

(5 elementos problemáticos restantes en esta consulta, a modo de ejemplo).

Luego miraría cada publicación para ver qué había y qué arreglar:

select * from topic_links where topic_id=19255 and post_id=88683

y luego arreglaría uno de ellos:

update public.topic_links set url='http://lists.libsdl.org/__listinfo.cgi/**sdl-libsdl.org' where id=275100;

Hasta que me quedé sin cosas que arreglar. :slight_smile:

Probablemente podría haber hecho algo de magia de inner-join (o tal vez un poco de Ruby) para obtener todo esto en una sola consulta, pero no soy un experto y resultó que no fueron horas de trabajo hacerlo manualmente. Pero sí fue tedioso, para ser claros. :slight_smile:

Luego ejecuté REINDEX DATABASE discourse; sin CONCURRENTLY solo para mantenerlo simple, eliminé algunos índices ccnew* que había pasado por alto antes, y estuve listo para empezar.

El sitio estuvo en línea todo el tiempo, sin tiempo de inactividad.

Ya sea que esto fuera necesario o no, definitivamente siento que mis datos están un poco más seguros ahora, y no me estoy precipitando hacia algún desastre no anunciado en el futuro.

Gracias por darme la dirección correcta para resolver esto, @pfaffman!

2 Me gusta