Déplacer un site Discourse vers un autre VPS avec rsync

Wiki de la communauté Adminsys
,
57

J’ai terminé cela, et Postgres (et Discourse !) semblent satisfaits.

Je les ai nettoyés à la main, en rendant les URL uniques avec des motifs ** appropriés. Il s’agissait peut-être simplement d’un cache inoffensif où j’aurais pu supprimer les doublons, mais je ne voulais pas prendre de risque.

Dans mon cas, il ne s’agissait que d’un seul index, donc la reconstruction de tous les index était probablement excessive, mais honnêtement, je me sentais mieux de savoir que j’avais tout attrapé.

Après quelques tentatives infructueuses de reconstruction, qui prennent environ 30 secondes à chaque fois et signalent un problème unique, voici ma magie SQL pour obtenir instantanément une liste complète des éléments problématiques :

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 éléments problématiques restants dans cette requête, à titre d’exemple.)

Ensuite, j’examinerais chaque publication pour voir ce qu’il y avait et quoi corriger :

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

puis j’en corrigerais une :

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

Jusqu’à ce que je n’aie plus rien à corriger. :slight_smile:

J’aurais probablement pu utiliser une magie d’union interne (ou peut-être un peu de Ruby) pour obtenir tout cela en une seule requête, mais je ne suis pas un expert et cela n’a pas pris des heures pour le faire manuellement. Mais c’était fastidieux, pour être clair. :slight_smile:

Ensuite, j’ai exécuté REINDEX DATABASE discourse; sans CONCURRENTLY juste pour rester simple, j’ai supprimé quelques index ccnew* que j’avais manqués plus tôt, et j’étais prêt à partir.

Le site était en ligne pendant tout ce temps, sans interruption.

Que cela ait été nécessaire ou non, j’ai définitivement l’impression que mes données sont un peu plus en sécurité maintenant, et que je ne me dirige pas vers une catastrophe non annoncée.

Merci de m’avoir mis sur la bonne voie pour résoudre ce problème, @pfaffman !

2 « J'aime »