الاستعادة تفشل مع وظيفة chat_mention المفقودة

خلل
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 إعجابات
2

لقد رأيت هذا الخطأ الآن في هذا التثبيت القياسي الجديد وكذلك في موقع مستضاف تجاريًا.

إعجابَين (2)
5

لقد رفعت إشارة الخفاش الداخلية، وسننظر في هذا خلال الأيام القليلة القادمة.

4 إعجابات
8

نفس الخطأ هنا عند محاولة الاستعادة في تثبيت جديد، حيث حاولت نقل “ديسكورس” إلى خادم آخر. لم يتم العثور على حل.

إعجاب واحد (1)
9

أوه، في الواقع لقد وجدت حلاً.

أنا محظوظ لأن الخادم القديم لا يزال قيد التشغيل. لذلك قمت بإعادة بناء التطبيق من خلال المشغل للحصول على الخادم القديم بنفس الإصدار تمامًا مثل التثبيت الجديد. ثم قمت بعمل نسخة احتياطية أخرى عبر سطر الأوامر. عند استعادة هذه النسخة الاحتياطية على التثبيت الجديد، سار كل شيء على ما يرام. يجب أن تجرب هذا. @pfaffman

إعجابَين (2)
10

هذا يمكن أن يحل مشكلتي في مكان واحد. شكراً!

11

يسرني أن أكون قد ساعدت!

إعجاب واحد (1)
12

لقد واجهت هذا أيضًا. أحاول الاستعادة من نظام إنتاج إلى نظام اختبار/تطوير. لقد تحققت أيضًا من تثبيت جميع الإضافات نفسها.
ما هي الإضافة الأخرى التي تستخدم هذا؟ سأتحقق من المصدر الآن…

13

حسنًا، إليك ما فعلته:

  1. تأكد من أن مجلد /var/discourse/shared كان فارغًا، أو تم نقله إلى موقع جديد في حال احتجنا إلى استعادته.
  2. قمت بتهيئة نسخة جديدة من discourse باستخدام ./launcher bootstrap <app>.
  3. حاولت الاستعادة مرة أخرى وفشلت بنفس رسالة الخطأ.
  4. بعد ذلك، عندما قمت بعمل نسخة احتياطية من نسخة 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;

ثم حاولت الاستعادة مرة أخرى، وسارت الأمور على ما يرام!

الآن، كان لدي السجل حيث فشلت واعتقدت أنه يمكنني العودة إليه لاحقًا، ولكن السجلات يتم إعادة تعيينها مع كل ميزة نسخ احتياطي/استعادة.

تحسين: سيكون من الجيد وجود سجل للنسخ الاحتياطي/الاستعادة. ربما يوجد واحد ولا أعرف أين هو.

إخلاء مسؤولية: أنا لست شخص دعم من Discourse، لذلك لن أخوض في كيفية الدخول إلى سطر أوامر psql لتشغيل الأوامر المذكورة أعلاه. :slight_smile:

17

المشكلة هي أنه تم الالتزام بـ ترحيل بختم تاريخ أقدم في tests-passed لاحقًا (@nbianca للعلم)، وهذا لا يتم اكتشافه بواسطة بيانات التعريف للإصدار في النسخة الاحتياطية. لقد ذكرت ذلك هنا.

هذا هو الحل. لذا، إما أن تحتاج إلى الحصول على تجزئة الالتزام من خادم المثيل وبناء المثيل الجديد الخاص بك باستخدام هذا الالتزام، أو تحديث المثيل الحالي إلى أحدث إصدار، والذي سيقوم بتشغيل هذا الترحيل، ثم أخذ نسخة احتياطية جديدة.

إعجابَين (2)
18

هل تقصد أن الحل (الحالي؟) بشكل دائم هو استعادة نفس الالتزام (أو في الواقع الترحيل) الذي تم منه النسخ الاحتياطي؟

أم إذا تجاوز كلا الإصدارين الالتزام الخاطئ فهل سنكون بخير؟

19

نعم، ولكن في بعض الأحيان لن تتمكن من تحديث المصدر. وفي هذه الحالة، ستحتاج إلى وضع الوجهة على نفس الالتزام مثل المصدر. لذا فهذه استثناء للحالة العادية حيث يمكنك دائمًا إجراء ترحيل ضمني إلى الأمام أثناء الاستعادة.

إعجاب واحد (1)
20

سأقوم باختبار هذا اليوم، لكن افتراضي الحالي هو أن الاستعادة تعمل بمجرد أن يصبح الموقع الوجهة محدثًا بالكامل.

يبدو أن المشكلة هي أن فحص الإصدار في بداية الاستعادة لا يكتشف أن المصدر كان لديه مخطط قاعدة بيانات أحدث من الوجهة.

نعم، أعتقد أن هذا صحيح.

21

صحيح، ويحدث هذا لأن الترحيل لا يحتوي على الطابع الزمني للحظة التي تم فيها الالتزام به، بل الطابع الزمني للحظة التي تم إنشاؤه فيها. في معظم الأحيان لا يهم ذلك ولكن في هذه الحالة كانت هناك 7 أسابيع بين هاتين اللحظتين.

إعجاب واحد (1)
22

نعم، هذه حالة هامشية مؤسفة. يمكننا محاولة تجنبها في المستقبل أو محاولة التوصل إلى حل متوافق مع الإصدارات السابقة لمنع حدوثها مرة أخرى. ومع ذلك، لا أعتقد أنه يمكننا فعل أي شيء لإصلاحها في هذه الحالة. لقد فات الأوان. مهما فعلنا، سيتطلب دائمًا من مالكي المواقع ترقية موقعهم الوجهة إلى أحدث إصدار.

إعجاب واحد (1)
23

صحيح، هذه مشكلة مع هذا النوع من التقنيات بشكل عام، إنها مشكلة عامة لـ Ruby on Rails وأيضًا لتطبيقات AR الأخرى مثل PHP Laravel. وكما قلت، لا يحدث هذا كثيرًا، وبمجرد أن تدرك ما يحدث، يكون من السهل التعامل معه أثناء الاستعادة.

إعجابَين (2)
24

وفي بعض الأحيان لا ترغب في ذلك ببساطة.

إذًا يبدو أنه إذا قمت بترقية الموقعين المصدرين اللذين أعمل عليهما، فسأكون في وضع جيد.

شكرًا مرة أخرى يا ريتشارد!

إعجاب واحد (1)
25

إذًا، في السيناريو الخاص بي، كانت بيئة الاستعادة الخاصة بي أحدث ببضع إصدارات من التأمين الذي تم نسخه احتياطيًا. ألا ينبغي أن ينجح هذا إذن؟

26

كم عمر النسخة التي قمت بعمل نسخة احتياطية منها؟

27

كان هذا شيئًا كنت سأبحث فيه! لحظة واحدة. كنت أتمنى لو احتفظنا بسجل للنسخ الاحتياطية السابقة، أم أننا فعلنا؟

نظرًا لأن هذا هو صندوق الرمل الذي نستعيده إليه، فقد بدأته مرة أخرى. هذا استعادة من بيئة الإنتاج – إلى صندوق الرمل:

هذه هي الأرقام من سجل الاستعادة:

[2024-10-21 19:49:59]   الإصدار الحالي: 20241018031851
[2024-10-21 19:49:59]   الإصدار المستعاد: 20241011054348