Move a Discourse site to another VPS with rsync

コミュニティWiki システム管理者
,
57

これを完了し、Postgres（およびDiscourse！）は満足しているようです。

URLを適切な**パターンで一意にし、手動でクリーンアップしました。単に重複を削除できたキャッシュかもしれませんが、リスクを冒したくありませんでした。

私の場合は、インデックスは1つだけだったので、すべてのインデックスを再構築するのはやりすぎだったかもしれませんが、正直なところ、すべてを把握できたので安心しました。

再構築を数回試行して失敗した後（毎回約30秒かかり、1つの問題が報告されました）、問題のあるアイテムの完全なリストを即座に取得するためのSQLマジックは次のとおりです。

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つの問題アイテムが残っています。）

次に、各投稿を確認して、何があり、何を修正する必要があるかを確認しました。

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

そして、そのうちの1つを修正しました。

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

修正するものがなくなるまで。 :slight_smile:

おそらく、インナー結合マジック（またはRuby）を使用して、これを1つのクエリで取得できたかもしれませんが、私は専門家ではなく、手動で行うのに何時間もかからなかったことがわかりました。しかし、はっきり言って、それは退屈でした。 :slight_smile:

その後、単純にするためにCONCURRENTLYなしでREINDEX DATABASE discourse;を実行し、見逃していたいくつかのccnew*インデックスを削除し、すべて完了しました。

サイトは常に稼働しており、ダウンタイムはありませんでした。

これが必要だったかどうかはわかりませんが、データが少し安全になったと感じており、突然の将来の災害に向かって暴走しているわけではありません。

この問題を解決するように促してくれてありがとう、@pfaffman！

「いいね！」 2