こんにちは、
サーバー移行のため、新しい Discourse インスタンスにバックアップを復元しようとしています。しかし、残念ながら以下のエラーが発生します：
これについて以下の記事を読んで、インデックスを削除しました。
その後、以下のコマンドを実行しました：
[2] pry(main)> IncomingReferer.where(path: "/m/search")
=> []
結果が返ってきませんでした。
これで、別のサーバーにバックアップを取得して復元しても問題ないでしょうか？
よろしくお願いいたします。
サム
残念ながら、これは役に立たず、復元時に引き続きこのメッセージが表示されます。
[2021-07-03 16:53:41] ERROR: could not create unique index "index_incoming_referers_on_path_and_incoming_domain_id"
[2021-07-03 16:53:41] DETAIL: Key (path, incoming_domain_id)=(/search, 4502) is duplicated.
[2021-07-03 16:53:41] EXCEPTION: psql failed: DETAIL: Key (path, incoming_domain_id)=(/search, 4502) is duplicated.
これをどう修正すればよいか見当がつかない状況です。
IncomingReferer.where("path LIKE '%/m/search%'")でさらに重複が見つかったため、これらのインデックスについてもdestroyを実行しました。しかし、現在はインスタンスが全く動作しなくなっており、古いサーバーでも同様です。そのため、再構築を試みる予定です。
Sam
まだ何か問題があります。以下のエラーが発生しています：
[2021-07-03 17:28:53] ERROR: could not create unique index "index_incoming_referers_on_path_and_incoming_domain_id"
[2021-07-03 17:28:53] DETAIL: Key (path, incoming_domain_id)=(/osmc/osmc, 2939) is duplicated.
[2021-07-03 17:28:53] EXCEPTION: psql failed: DETAIL: Key (path, incoming_domain_id)=(/osmc/osmc, 2939) is duplicated.
新しいバックアップを復元しようとした際に表示されました。
しかし、コンソールでは実行中のサーバー上のインスタンスをクリーンアップしたことが確認できます（再構築後に現在は復旧しています）：
[1] pry(main)> IncomingReferer.where(path: "/m/search")
=> []
[2] pry(main)> IncomingReferer.where("path LIKE '%/m/search%'")
=> []
データベースを修正して、別のマシンで復元できるようにするために何を行うべきか、ご教示いただけますでしょうか？
よろしくお願いいたします。
Sam
Can't restore due to corrupt indexes (with some clues on how to deal with corrupt indexes) がいくつかの手がかりを提供するかもしれません。
ありがとうございます。
これについては読みましたが、私の問題を解決するためにどのコマンドやクエリを実行すればよいか分かりません。
Sam
基本的には、インデックスを再構築しようとして、再インデックスできるようになるまで削除を繰り返す必要があります。あなたは正しい手順を踏んでいるようですが、重複するすべてのエントリに対してそれを続ける必要があります。
予算に関する質問であれば、Marketplace チャンネルに投稿してください。
こんにちは、Jay さん。
英国では、これらの問題を解決するために第三者に当社のデータベースを公開することは法的に認められていません。また、たとえ可能だったとしても、ユーザーのプライバシー保護の観点から、そのようなことは行いたくありません。
私もオープンソースのメンテナーとして活動していますが、これを Marketplace に持ち込むという考え方はがっかりさせられます。特に、これらの問題が Discourse が Docker コンテナにバンドルした Postgres の更新によって引き起こされたものであるという暗黙の認識があるにもかかわらず、です。私たちは Discourse を Docker コンテナで利用していますが、それは密結合した依存関係を理解しており、バージョン管理や依存関係の管理を Discourse チームの専門知識に委ねたいと考えているからです。
これは Postgres 12 の回帰現象であるという見方が一般的で、いくつかの軽減策も提案されています。しかし、最初の報告は1年以上前に寄せられており、今後バックアップを復元しようとするユーザーが増えるにつれて、さらに影響を受ける人が出ることは確実です。
私は、この問題を Discourse の上流側で修正するための開発時間をスポンサーすることを優先したいと考えています。そうすれば、他の人々もその恩恵を受けられるからです。当面の間、当社のフォーラムは機能していないため、Postgres の DBA 知識を持つ誰かの助けを借りる必要があります。
よろしくお願いいたします。
Sam
サム、こんにちは。
ご自身で問題を解決できるよう、十分な指示ができず申し訳ありませんでした。ただ、そう聞こえてしまったのかもしれません。フォーラムを再びオンライン化する方法が他にもあることは、がっかりすることではなく、むしろほっとする情報だと考えたのですが。
では、また。
こんにちは、Jay さん
全く問題ありません。私に対して何かを義務付けられているわけではありません。ただ、あなたの投稿履歴を拝見し、すぐに解決策があるかと期待していました。また、あなたの投稿が決定的な回答のように見え、トピックが閉じられていたため、私が何か見落としているのだろうと推測していました。
その後、どうなったかお知らせしますね。
では、
Sam
残念ながら、これは依然として私たちの課題であり、サーバー移行もできず、かなり懸念されています。
解決のために誰かに支払う用意はありますが、この問題と、フォーラムで明確な解決策を示さずに何度も認識が示されたことを受け、本格的に Flarum などの別のフォーラムソフトウェアへの移行を検討しています。Discourse ほど多機能ではないかもしれませんが、LAMP 環境であり、私のような Web 開発者ではない人間でも中身を把握できます。
Discourse の Docker コンテナを使用していた際、サポートがあるものと期待していました。すべてを個別にデプロイし、独自の Postgres バージョンを使用していたなら、その対応も理解できたでしょう。しかし、これまで行ってきたのは、あなたが推奨し、提供している環境を使用しただけです。その結果、新しいサーバーへの移行について非常に窮地に立たされています（期限が迫っています）。
現時点での最善策は、Docker ボリュームのバックアップとリストアですが、Discourse のバックアップは使用できません。これも懸念材料です。毎日バックアップが取られていますが、新しい Discourse 環境に実際に復元できないのです。今後、どれほど多くのユーザーがこのような問題に直面することになるのか疑問に思います。
Sam
Postgres には、インデックス破損の原因となるバグがいくつか存在しました。それらのほとんどは Postgres 13.x で修正されたと考えています。