バックアップのインポートエラー：「一意のインデックスを作成できませんでした」

[glynhudson]

こんにちは。

フォーラムを新しいサーバーに移行しようとしています。両方のサーバーは最新バージョンの Discourse Docker を実行しています。コマンドライン経由でバックアップをインポートしようとすると、次のエラーが発生します。

ERROR:  could not create unique index "index_incoming_referers_on_path_and_incoming_domain_id"
DETAIL:  Key (path, incoming_domain_id)=(/search/, 418) is duplicated.
EXCEPTION: psql failed: DETAIL:  Key (path, incoming_domain_id)=(/search/, 418) is duplicated.

これは、上記のスレッドで報告されているものと同じか類似のエラーのようです。

Restore fails - could not create unique index

I have a duplicate key issue also, is there a documented fix? discourse=# REINDEX SCHEMA CONCURRENTLY public; ERROR: could not create unique index "index_incoming_referers_on_path_and_incoming_domain_id_ccnew" DETAIL: Key (path, incoming_domain_id)=(/search/, 1905) is duplicated. [1] pry(main)> IncomingReferer.where(path: "/m/search") => [#<IncomingReferer:0x0000557176d3f210 id: 44231, path: "/m/search", incoming_domain_id: 4>, #<IncomingReferer:0x0000557176d925c8 id: 42228, path: "/m/…

ただし、私の場合は、リンクされたスレッドで報告されている /m/search ではなく、/search/ パスで重複レコードが発生しています。

古いサーバーのコンテナに接続し (./launcher enter app)、Rails コンソール (rails c) で次のコマンドを使用して重複レコードを検索しようとしました。

IncomingReferer.where(path: "/search")
および
IncomingReferer.where("path LIKE '%/search%'")

しかし、これらは数百件のレコードを表示します。重複しているレコードをどのように特定し、安全に削除して再構築するにはどうすればよいでしょうか？フォーラムは古いサーバーでは現在正常に動作していますが、新しいハードウェアに移行する必要があります。

[IAmGav (Gavin Perch)]

Have you tried using the Admin GUI ?

[glynhudson]

No, I assumed importing via the GUI would be invoking the same import process? I’ll try that now.

[pfaffman (Jay Pfaffman)]

I suspect this means that you have a corrupt index. What version of Postgres are you running?

something like:

cd /var/discourse
cat shared/standalone/postgres_data/PG*

(I can’t quite remember the postgres filename).

You can search here for “postgres corrupt index” and find a topic that I once wrote about how to track down those bad records and delete them.

You basically try to rebuild that index and delete the records that it complains about then try to rebuild the index again until it rebuilds.

[glynhudson]

Just tried importing via the GUI, with exactly the same result:

@pfaffman

What version of Postgres are you running?

The old server doesn’t have a file called PG_VERSION, how can I tell what version its running? I’ve updated the docket install to the latest version today.

The new server (newly bootstrapped) is running postgres V13

cat shared/standalone/postgres_data/PG_VERSION
13

@pfaffman

You can search here for “postgres corrupt index” and find a topic that I once wrote about how to track down those bad records and delete them.

You basically try to rebuild that index and delete the records that it complains about then try to rebuild the index again until it rebuilds.

Is there a recommended procedure on how to do this?

[pfaffman (Jay Pfaffman)]

I had a topic that had some hints, but I don’t see it anymore. It’s been close to a year since the postgres 12 upgrade.

  reindex index index_incoming_referers_on_path_and_incoming_domain_id;

And

 ActiveRecord::Base.connection.execute('reindex index index_incoming_referers_on_path_and_incoming_domain_id;')

Are ways to try to rebuild the index. It’ll give you an error and you can then go and delete the errant records. You’ll need to include both the path and the ID.

[glynhudson]

Ok, I’ve fixed it. I did the following

Enter container

./launcher enter app

Connect to database

su postgres -c 'psql discourse'

Try to find duplicates

discourse=# select * from incoming_referers where path LIKE '%/search/' ORDER BY incoming_domain_id;`

  id  |    path    | incoming_domain_id
------+------------+--------------------
 3339 | /search/   |                 33
 6257 | /search/   |                 91
 1567 | /search/   |                298
 1777 | /search/   |                341
 3010 | /search/   |                418
 6247 | /search/   |                418
 4293 | /search/   |                644
 2899 | /search/   |                653
 3447 | /search/   |                793
 3696 | /search/   |                852
 4395 | /a/search/ |               1050
 6968 | /search/   |               1305
 5634 | /search/   |               1387
 5834 | /search/   |               1437
 6519 | /search/   |               1637
 7127 | /search/   |               1787
 7280 | /search/   |               1827
(17 rows)

Delete duplicate

DELETE FROM incoming_referers WHERE path LIKE '%/search/' AND id IN (6247);

Then rebuild

discourse=# REINDEX SCHEMA CONCURRENTLY public;
WARNING:  cannot reindex invalid index "public.incoming_referers_pkey_ccnew" concurrently, skipping
WARNING:  cannot reindex invalid index "public.index_incoming_referers_on_path_and_incoming_domain_id_ccnew" concurrently, skipping
WARNING:  cannot reindex invalid index "pg_toast.pg_toast_20732_index_ccnew" concurrently, skipping
REINDEX

Then I took another backup, copied it to the new server, and it imported successfully

It would be nice if the backup process could spot duplicates to avoid any issues, I was luckily that I had access to the original server which was still running. If I was restoring a cold backup, this would probably have been more of an issue>

Thanks a lot for your help.