pfaffman
2024 年 10 月 17 日午後 3:18
1
サーバーから本日構築されたサーバーに復元しようとしていますが、このエラーで失敗します。これは Discourse コードまたはプラグイン コードのどこにも見当たりません。
次に何をすべきかわかりません。
[20/9694]
ERROR: function discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() does not exist
EXCEPTION: psql failed: ERROR: function discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() does not exist
/var/www/discourse/lib/backup_restore/database_restorer.rb:92:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:51:in `run'
script/discourse:157:in `restore'
/var/www/discourse/vendor/bundle/ruby/3.
「いいね！」 4
pfaffman
2024 年 10 月 17 日午後 10:22
2
この新しい標準インストールと、ビジネスホスティングサイトの両方でこのエラーが発生しました。
「いいね！」 2
sam
2024 年 10 月 18 日午前 1:55
5
内部のバットシグナルを上げました。数日間かけて対応します。
「いいね！」 4
ここでも、ディスコースを別のサーバーに移行しようとしたときに、新規インストールで復元しようとすると同じエラーが発生しました。解決策は見つかりませんでした。
「いいね！」 1
ああ、実は解決策が見つかりました。
古いサーバーがまだ稼働していてラッキーでした。そのため、ランチャーを再構築して、古いサーバーを新しいインストールと同じバージョンにしました。その後、コマンドライン経由で別のバックアップを作成しました。このバックアップを新しいインストールに復元したところ、すべてうまくいきました。試してみてください。@pfaffman
「いいね！」 2
pfaffman
2024 年 10 月 18 日午後 6:15
10
それが一箇所で問題を解決してくれるかもしれません。ありがとうございます！
私も同じ問題に遭遇しました。本番システムからサンドボックス/開発環境に復元しようとしています。すべてのプラグインがインストールされていることも再確認しました。
他にこのプラグインを使用しているものはありますか？ソースコードを確認します…
承知いたしました。以下に実施した内容を記載します。
/var/discourse/shared フォルダが空であることを確認したか、または復元が必要な場合に備えて新しい場所に移動しました。./launcher bootstrap <app> を使用して新しい Discourse インスタンスを初期化しました。再度リストアを試みましたが、同じエラーメッセージで失敗しました。
その後、正常な Discourse インスタンスのダンプを実行したところ、関数を作成する実際のコマンドが見つかりました。それは以下の通りです。
CREATE FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
RAISE EXCEPTION 'Discourse: old_notification_id in chat_mention_notifications is readonly';
END
$$;
ALTER FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() OWNER TO discourse;
その後、リストアを再試行したところ、すべて正常に完了しました。
バックアップ/リストア機能ではログがリセットされるため、失敗した際のログを確認して後で参照しようと思っていましたが、できませんでした。
ENHANCEMENT: バックアップ/リストアの履歴があると便利です。もし存在していて、私が知らないだけかもしれませんが。
DISCLAIMER: 私は Discourse のサポート担当者ではないため、上記のコマンドを実行するために psql コマンドラインプロンプトに入る方法については説明しません。
RGJ
2024 年 10 月 21 日午前 8:33
17
問題は、古いタイムスタンプのマイグレーション が後で tests-passed にコミットされ (@nbianca FYI)、これがバックアップのバージョンメタデータで検出されないことです。これは ここに 記載したようなことです。
これが解決策です。そのため、インスタンスサーバーからコミットハッシュを取得して、そのコミットで新しいインスタンスを構築するか、既存のインスタンスを最新バージョンに更新してそのマイグレーションを実行し、新しいバックアップを取得する必要があります。
「いいね！」 2
pfaffman
2024 年 10 月 21 日午後 1:24
18
Richard - Communiteq:
これが解決策です
（現在の？）恒久的な解決策は、バックアップを作成したのと同じコミット（または実際にはマイグレーション）にのみ復元することだと言っていますか？
それとも、両方のバージョンが問題のあるコミットを超えている場合、問題ありませんか？
RGJ
2024 年 10 月 21 日午後 1:45
19
はい、ただし、ソースインスタンスを更新できない場合があります。その場合は、宛先をソースと同じコミットにする必要があります。したがって、これは、復元中に常に暗黙的な前方移行ができる通常の状況に対する例外です。
「いいね！」 1
gerhard
2024 年 10 月 21 日午後 1:46
20
本日これをテストする予定ですが、現在の私の仮説では、宛先サイトが完全に最新の状態になった時点で復元が機能するはずです。
問題は、復元の開始時のバージョンチェックで、ソースが宛先よりも実際には新しいDBスキーマを持っていたことを検出していないようです。
はい、その通りだと思います。
RGJ
2024 年 10 月 21 日午後 1:50
21
はい、その通りです。これは、マイグレーションがコミットされた瞬間のタイムスタンプではなく、生成された瞬間のタイムスタンプを持っているために発生しています。ほとんどの場合、それは問題になりませんが、この場合はその2つの瞬間の間に7週間の開きがありました。
「いいね！」 1
gerhard
2024 年 10 月 21 日午後 1:56
22
はい、それは残念なエッジケースです。将来的に回避するか、再発防止のための後方互換性のあるソリューションを考案することができます。しかし、このケースでは何もできないと思います。もう手遅れです。どのような対応をとっても、サイトオーナーは常に最新バージョンにデスティネーションサイトをアップグレードする必要があります。
「いいね！」 1
RGJ
2024 年 10 月 21 日午後 1:59
23
はい、これは一般的な問題であり、Ruby on Rails や PHP Laravel のような他の AR 実装でも同様です。そして、おっしゃる通り、頻繁に発生するわけではなく、何が起こっているのかを理解すれば、復元中に簡単に回避できます。
「いいね！」 2
pfaffman
2024 年 10 月 21 日午後 2:03
24
そして、したくない場合もあります。
ですから、私が取り組んでいる2つのソースサイトをアップグレードするだけで、問題が解決するということのようですね。
リチャード、改めてありがとう！
「いいね！」 1
ですので、私のシナリオでは、復元環境はバックアップされた保険の数バージョン新しいものでした。それでも機能するはずですよね？
それは私が調べようとしていたことでした！少々お待ちください。以前のバックアップのログを残しておけばよかったのに、あるいは残っていますか？
これはサンドボックスに復元しているので、再度開始しました。これは本番環境からサンドボックスへの復元です。
復元ログからの数字は以下の通りです。
[2024-10-21 19:49:59] 現在のバージョン: 20241018031851
[2024-10-21 19:49:59] 復元されたバージョン: 20241011054348
