خطأ في الترقية - rake db:migrate فهرس على theme_field_id

[Joshua_Lyon]

في ملاحظات الإصدار (3.2.0.beta1) الأخيرة، لاحظت إضافة discourse-ai التي لم أرها من قبل، لذا حاولت إضافة هذه الإضافة وترقية مثيل Discourse الخاص بي في نفس الوقت.

كما هو مذكور في العنوان، أرى حاليًا خطأ في عملية التهيئة حيث تفشل rake db:migrate في إنشاء فهرس فريد على theme_field_id. إليك بعض التفاصيل حول كيفية وصولي إلى هذه النقطة…

محاولة الترقية الأولية (خطأ patch-package)

أنا أستخدم تثبيتًا مقسمًا للحاويات، لذا قمت بما يلي:

• عدلت ملف web_only.yml الخاص بي لإضافة إضافة discourse-ai الجديدة

  مثال. تمت إضافة سطر إضافي إلى خطافات الإضافات

  ## Plugins go here
  ## see https://meta.discourse.org/t/19157 for details
  hooks:
    after_code:
      - exec:
          cd: $home/plugins
          cmd:
            - sudo -E -u discourse git clone https://github.com/discourse/docker_manager.git
            - sudo -E -u discourse git clone https://github.com/discourse/discourse-voting.git
            - sudo -E -u discourse git clone https://github.com/discourse/discourse-ai.git
  

• شغلت ./launcher bootstrap web_only

  تعطلت برسالة حول عدم العثور على patch-package.

Git Pull → bootstrap (خطأ pg-vector)

اعتقدت أنني سأتأكد من حصولي على آخر تحديثات المشغل لأن ذلك لن يضر قبل إعادة المحاولة:

• شغلت git pull للتأكد من حصولي على آخر التحديثات المتعلقة بالمشغل
• شغلت ./launcher bootstrap web_only مرة أخرى

هذه المرة تلقيت رسائل خطأ متعلقة بـ pg-vector.

مقتطف سجل من التهيئة مع discourse-ai

لقد سجلت إصدارات PostgreSQL الخاصة بي حتى أحتفظ بها لسجلاتي عندما أقرر إعادة زيارة إضافة discourse-ai.

• web_only:
  • العميل: psql (PostgreSQL) 13.10 (Debian 13.10-1.pgdg110+1)
• data:
  • الخادم: PostgreSQL 13.9 (Debian 13.9-1.pgdg110+1)

إزالة إضافة discourse-ai → Bootstrap

ثم قمت بإزالة إضافة discourse-ai من ملف web_only.yml وشغلت التهيئة مرة أخرى.

لدهشتي، كنت لا أزال أرى أخطاء، ولكن هذه المرة يبدو أنها متعلقة بفشل rake db:migrate في إنشاء فهرس فريد index_javascript_caches_on_theme_field_id مع التفاصيل: Key (theme_field_id)=(3) is duplicated.

مقتطف سجل من التهيئة بدون discourse-ai

مساعدتكم؟

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

للمرجع، لدي الإصدار 3.2.0.beta1-dev (993ed10cf0 ~ 9 أغسطس) مثبتًا.

وبينما لا أعتقد أن هذا مرتبط بهذا، أعتقد أنه لا يضر ذكر أنني قمت بالترحيل بين أجهزة المضيف في بداية هذا العام… على الرغم من أنني قمت بالعديد من تحديثات Discourse عبر واجهة المسؤول منذ ذلك الحين.

نهج الترحيل

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

[JammyDodger]

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

السطر الموجود فوق rake aborted! مباشرة في السجلات يذكر أن discourse-voting أصبح الآن discourse-topic-voting. يمكنك محاولة تحديث الرابط في قسم المكون الإضافي إلى الرابط الحالي ومعرفة ما إذا كان ذلك سيساعد؟

[Joshua_Lyon]

@JammyDodger

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

هل يمكنك توضيح المورد الذي تشير إليه على أنه يحتوي على معرف مكرر؟ لم أكن متأكدًا بالضبط مما يشير إليه theme_field_id.

للتسجيل، لم أقم بإيقاف تشغيل حاوية web_only. عادةً ما أقوم بتمهيد الحاوية أولاً لتقليل نافذة الانقطاع:

@sam

./launcher bootstrap web_only

بدء الانقطاع

./launcher destroy web_only
./launcher start web_only

نهاية الانقطاع

–

@JammyDodger

يذكر أن discourse-voting أصبح الآن discourse-topic-voting. يمكنك محاولة تحديث الرابط في قسم المكون الإضافي إلى الرابط الحالي ومعرفة ما إذا كان ذلك سيساعد؟

سأجرب ذلك. أشك في أن هذا سيساعد لأنني أعتقد أن GitHub يعيد توجيه الأشياء بصمت خلف الكواليس وهو مجرد تحذير من جانب Discourse. :ابتسامة:

[JammyDodger]

@Joshua_Lyon

هل يمكنك توضيح المورد الذي تشير إليه على أنه يحتوي على معرف مكرر؟ لم أكن متأكدًا بالضبط مما يشير إليه theme_field_id.

إذا كان لديك موقع يعمل مع تثبيت مستكشف البيانات، أعتقد أنه يمكنك إلقاء نظرة على ما قد يشير إليه ذلك باستخدام هذا الاستعلام:

SELECT *
FROM theme_fields
WHERE id = 3

[Joshua_Lyon]

لم أكن على علم بهذا المكون الإضافي - هذا رائع! لم أقم بتثبيته، لكن يمكنني إدخال حاوية البيانات وتشغيل الاستعلامات.

هذه معلومة رائعة! إذا كنت أقرأ رسالة الخطأ بشكل صحيح، فلا أعتقد أنها تتعلق بجدول theme_fields لأن هذا الجدول المحدد لا يحتوي على theme_field_id. لم أتحقق من الكود المصدري، لكنني سأخمن أن الوسيط الأول لـ add_index() هو اسم الجدول والثاني هو العمود.

بناءً على ذلك، يبدو أنه سيكون جدول javascript_caches.

== 20230817174049 EnsureJavascriptCacheIsUniquePerTheme: migrating ===========
-- remove_index(:javascript_caches, :theme_id)
   -> 0.0208s
-- add_index(:javascript_caches, :theme_id, {:unique=>true})
   -> 0.0079s
-- remove_index(:javascript_caches, :theme_field_id)
   -> 0.0026s
-- add_index(:javascript_caches, :theme_field_id, {:unique=>true})

لذلك، قمت بفحص بنية هذا الجدول ويحتوي على عمود theme_field_id:

discourse=# \d javascript_caches
                                          Table "public.javascript_caches"
     Column     |            Type             | Collation | Nullable |                    Default
----------------+-----------------------------+-----------+----------+-----------------------------------------------
 id             | bigint                      |           | not null | nextval('javascript_caches_id_seq'::regclass)
 theme_field_id | bigint                      |           |          |
 digest         | character varying           |           |          |
 content        | text                        |           | not null |
 created_at     | timestamp without time zone |           | not null |
 updated_at     | timestamp without time zone |           | not null |
 theme_id       | bigint                      |           |          |
 source_map     | text                        |           |          |
Indexes:
    "javascript_caches_pkey" PRIMARY KEY, btree (id)
    "index_javascript_caches_on_digest" btree (digest)
    "index_javascript_caches_on_theme_field_id" btree (theme_field_id)
    "index_javascript_caches_on_theme_id" btree (theme_id)
Check constraints:
    "enforce_theme_or_theme_field" CHECK (theme_id IS NOT NULL AND theme_field_id IS NULL OR theme_id IS NULL AND theme_field_id IS NOT NULL)
Foreign-key constraints:
    "fk_rails_58f94aecc4" FOREIGN KEY (theme_id) REFERENCES themes(id) ON DELETE CASCADE
    "fk_rails_ed33506dbd" FOREIGN KEY (theme_field_id) REFERENCES theme_fields(id) ON DELETE CASCADE

تمكنت من الاستعلام عن هذا الجدول (مع اختصار حقول المحتوى حتى أتمكن من قراءتها فعليًا) ويمكنني رؤية التكرارات. لكنني لست متأكدًا من تداعيات هذه التكرارات.

discourse=# select id, theme_field_id, digest, substring(content from 1 for 64) as content_64, created_at, updated_at, theme_id, substring(source_map from 1 for 64) as source_64 from javascript_caches where theme_field_id = 3;
 id | theme_field_id |                  digest                  |                            content_64                            |         created_at         |         updated_at         | theme_id |                            source_64
----+----------------+------------------------------------------+------------------------------------------------------------------+----------------------------+----------------------------+----------+------------------------------------------------------------------
  1 |              3 | d0b6ec642d5649064ff0501cadc775a9217b16e0 | "define"in window&&define("discourse/theme-3/initializers/theme- | 2019-02-25 01:26:56.606537 | 2023-08-18 20:47:19.596923 |          | {"version":3,"sources":["discourse/initializers/theme-field-3-co
  2 |              3 | 7fd74ecf4448afccdbcd9ccde87acddb4ec6f514 | "define"in window&&define("discourse/theme-3/initializers/theme- | 2019-02-25 01:26:58.228209 | 2023-08-18 20:50:41.049209 |          | {"version":3,"sources":["discourse/initializers/theme-field-3-co

بدا المحتوى مألوفًا، لذا ذهبت إلى Customize → Theme → My Theme → Common → Head، وأجريت تعديلاً بسيطًا وحفظت، ويمكنني رؤية أنه تم تحديث أحد الإدخالات وظل أحدها قديمًا…

discourse=# select id, theme_field_id, digest, substring(content from 1 for 64) as content_64, created_at, updated_at, theme_id, substring(source_map from 1 for 64) as source_64 from javascript_caches where theme_field_id = 3;
 id | theme_field_id |                  digest                  |                            content_64                            |         created_at         |         updated_at         | theme_id |                            source_64
----+----------------+------------------------------------------+------------------------------------------------------------------+----------------------------+----------------------------+----------+------------------------------------------------------------------
  2 |              3 | 7fd74ecf4448afccdbcd9ccde87acddb4ec6f514 | "define"in window&&define("discourse/theme-3/initializers/theme- | 2019-02-25 01:26:58.228209 | 2023-08-18 20:50:41.049209 |          | {"version":3,"sources":["discourse/initializers/theme-field-3-co
  1 |              3 | 7f4132b1f9ced1b90b8f8fc24812cc11e81fea8d | "define"in window&&define("discourse/theme-3/initializers/theme- | 2019-02-25 01:26:56.606537 | 2023-09-13 21:56:56.312263 |          | {"version":3,"sources":["discourse/initializers/theme-field-3-co
(2 rows)

مرة أخرى، لست متأكدًا من تداعيات هذه التكرارات، وما إذا كان من الآمن حذف الإدخال “القديم”، أو ما إذا كانت هناك طريقة أخرى “لإعادة بناء” ذاكرة التخزين المؤقت التي من شأنها تنظيف هذا؟

[JammyDodger]

بصراحة، أنا 0/2 حتى الآن، لذا من المحتمل أنني لست أفضل مصدر للمعلومات بخصوص هذا الأمر.

هناك موضوعان سابقان حدث فيهما شيء مشابه لـ index_tags_on_name إذا كانا قد يكونان مفيدين؟ على سبيل المثال.

Error upgrading from 3.0.1 to 3.1.0

Hello! Here’s are my log details: I, [2023-03-28T15:29:11.675436 #1] INFO -- : Terminating async processes I, [2023-03-28T15:29:11.675493 #1] INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 42 I, [2023-03-28T15:29:11.675526 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 103 10…

[pfaffman (Jay Pfaffman)]

أعد بناء حاوية البيانات الخاصة بك. تتطلب إضافة الذكاء الاصطناعي امتدادًا ليس لديك بعد.

[Joshua_Lyon]

@JammyDodger

بصراحة، أنا 0/2 حتى الآن لذا من المحتمل ألا أكون أفضل مصدر للمعلومات لهذا الأمر.

أقدر مساعدتك! يبدو أنك قمت بتوجيهي في المسار الصحيح.

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

@pfaffman

أعد بناء حاوية البيانات الخاصة بك. يتطلب المكون الإضافي للذكاء الاصطناعي امتدادًا لا تملكه بعد.

شكرًا للتأكيد! كنت أعتقد أنني قد أحتاج إلى تحديث حاوية البيانات (أو الحصول على pgvector مثبتًا بطريقة أخرى). كنت أؤجل القيام بذلك لأنني لم أرغب في التعامل مع وقت التوقف.

من سلسلة مناقشات discourse-ai، يبدو أن PG15 على وشك الظهور، لذا قد أنتظر قليلاً لذلك.

يبدو أن الاعتماد على pgvector قد يكون لميزة Embeddings التي لم أخطط لاستخدامها، ولكن للأسف يبدو أن كل شيء مجمع معًا. كنت أرغب بشكل أساسي في تجربة بعض ميزات إعادة الكتابة السحرية لـ OpenAI / ChatGPT، لذا ربما يكون هذا سببًا آخر للانتظار حتى التحديث الكبير التالي لحاوية البيانات.

[pfaffman (Jay Pfaffman)]

@Joshua_Lyon

من سلسلة discourse-ai، يبدو أن PG15 على وشك الظهور، لذا قد أنتظر قليلاً من أجل ذلك.

يمكنك الانتظار إذا أردت، ولكن مستخدمي الحاوية الواحدة (وهم الغالبية العظمى من المستضيفين الذاتيين) يقومون بترقية قاعدة بيانات بوستجريس الخاصة بهم ربما في كل مرة يقومون فيها بالترقية، لذلك لا يوجد سبب كبير للانتظار بخلاف بضع دقائق إضافية من وقت التعطل. ستحتاج إلى إعادة بناء (أو ربما فقط تدمير وبدء) حاوية الويب فقط بعد إعادة بناء قاعدة البيانات.

[Joshua_Lyon]

@pfaffman

بضع دقائق إضافية من وقت التعطل

هذا هو السبب الرئيسي. حتى لو كان بضع دقائق فقط، أفضل تقليل ذلك إذا لم يكن الأمر بالغ الأهمية.

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

لقد تابعت بشكل غير رسمي بعض المناقشات حول ترقيات “وقت التعطل الصفري”. ربما تكون مجرد نظارات وردية تنظر إلى التاريخ الحديث، لكن يبدو أنني تمكنت من استخدام /admin/upgrade لمعظم التحديثات على مدار العام الماضي، لذلك ركزت على المشاريع الأكثر أهمية في الوقت الحالي وفقدت الاهتمام بنهج وقت التعطل الصفري.

عندما انتقلت إلى مضيف أكبر في يناير، كان “وقت تعطل صفري” بمعنى أن المستخدمين يمكنهم الاستمرار في الوصول إلى المحتوى الموجود على الموقع، ولكن كانت هناك فترة وجيزة كانت فيها الأمور للقراءة فقط أثناء انتقالنا. أفترض أنه يمكنني استخدام هذا النهج لترقية حاوية data كبيرة إذا كنت أرغب حقًا في تقليل وقت التعطل أثناء الترقية الكبيرة التالية لـ data.

ملاحظة: لقد قرأت الكثير من مشاركاتك في المجتمع هنا على مر السنين. شكراً جزيلاً لجهودك في دعم المجتمع!

[pfaffman (Jay Pfaffman)]

@Joshua_Lyon

يبدو أنني تمكنت من استخدام /admin/upgrade لمعظم التحديثات خلال العام الماضي،

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