غيرت عنوان URL لموقع Discourse الخاص بي، وأتبع التعليمات الموجودة في Change the domain name or rename your Discourse. عند محاولة تشغيل remap، أتلقى الخطأ التالي بشكل متكرر. يستمر في إخباري بإعادة تشغيل النص البرمجي، لكن نفس الخطأ يحدث في كل مرة.[1]
لا أعرف ما هي خطوتي التالية هنا، وسأكون ممتنًا للتوجيه. شكرًا مقدماً!
root@digitallysovereign:/var/discourse# ./launcher enter app
x86_64 arch detected.
root@digitallysovereign-app:/var/www/discourse# discourse remap discourse.tobiaseigen.org digitallysovereign.org
Rewriting all occurrences of discourse.tobiaseigen.org to digitallysovereign.org
WILL RUN ON 'default' DB
THIS TASK WILL REWRITE DATA, ARE YOU SURE (type YES): YES
Remapping tables on default...
ai_api_audit_logs=919
ai_secrets=1
backup_metadata=1
browser_pageview_events=3664
Error: ERROR: duplicate key value violates unique constraint "idx_bprd_rollups_date_referrer_unique"
DETAIL: Key (date, normalized_referrer)=(2026-07-01, digitallysovereign.org) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
root@digitallysovereign-app:/var/www/discourse# discourse remap discourse.tobiaseigen.org digitallysovereign.org
Rewriting all occurrences of discourse.tobiaseigen.org to digitallysovereign.org
WILL RUN ON 'default' DB
THIS TASK WILL REWRITE DATA, ARE YOU SURE (type YES): YES
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "idx_bprd_rollups_date_referrer_unique"
DETAIL: Key (date, normalized_referrer)=(2026-07-01, digitallysovereign.org) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
root@digitallysovereign-app:/var/www/discourse# discourse remap discourse.tobiaseigen.org digitallysovereign.org
Rewriting all occurrences of discourse.tobiaseigen.org to digitallysovereign.org
WILL RUN ON 'default' DB
THIS TASK WILL REWRITE DATA, ARE YOU SURE (type YES): YES
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "idx_bprd_rollups_date_referrer_unique"
DETAIL: Key (date, normalized_referrer)=(2026-07-01, digitallysovereign.org) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
أعلم أن تعريف الجنون هو تكرار نفس الشيء مرارًا وتكرارًا والتوقع حدوث نتيجة مختلفة! ↩︎
يبدو أن هناك تصادمًا في قيود جدول التحليلات في PostgreSQL. قاعدة بياناتك تحتوي بالفعل على سجلات للمجال الجديد في تواريخ محددة، لذا فمن المرجح أن أداة إعادة التعيين (remap tool) تنشئ نسخًا مكررة، ويقوم PostgreSQL برفضها.
أقترح أن تحاول حذف سجلات المجال القديم من الجدول المحدد فقط للتواريخ التي يحتوي فيها المجال الجديد بالفعل على بيانات، وذلك للحفاظ على البيانات التاريخية وإلغاء حظر أداة إعادة التعيين. لكن قم بعمل نسخة احتياطية أولاً.
جرب هذا:
cd /var/discourse
./launcher enter app
# إنشاء نسخة احتياطية
discourse backup
# الدخول إلى وحدة تحكم قاعدة البيانات
sudo -u postgres psql discourse
/* العثور على اسم الجدول الدقيق المرتبط بهذا الفهرس */
SELECT tablename
FROM pg_indexes
WHERE indexname = 'idx_bprd_rollups_date_referrer_unique';
بافتراض أن الاستعلام أعلاه يعيد browser_pageview_rollup_details، استخدم اسم الجدول هذا في الاستعلام التالي
/* حذف سجلات التحليلات المتصادمة */
DELETE FROM browser_pageview_rollup_details
WHERE normalized_referrer = 'discourse.tobiaseigen.org'
AND date IN (
SELECT date
FROM browser_pageview_rollup_details
WHERE normalized_referrer = 'digitallysovereign.org'
);
/* الخروج من PostgreSQL */
\q
ما أفعله هو أخذ نسخة احتياطية من قاعدة البيانات، وتغيير الرابط، ثم استعادة النسخة والسماح لأداة إعادة التوجيه في Discourse بالقيام بالمهمة. يتم استخدام هذا الكود من قبل استضافة Discourse، وإذا فشل، سيلاحظ ذلك شخص يمكنه إصلاحه.
لكن نعم، روابط الإحالة هذه تسببت في أنواع مختلفة من المشاكل.
الأمر discourse db لا يعمل معي - أنا أستخدم sudo -u postgres psql discourse.
كان الجدول الذي إرجعته الاستعلام الأول هو في الواقع browser_pageview_referrer_daily_rollups، لذا استخدمته في الاستعلام الثاني.
الآن أواجه خطأً مختلفاً. عند تشغيل الاستعلام الثاني مرة أخرى، فإنه لا يقوم بحذف أي شيء.
خطأ: ERROR: قيمة المفتاح المكررة تنتهك قيد التسمية الفريدة "idx_bprd_rollups_date_referrer_unique"
التفاصيل: المفتاح (date, normalized_referrer)=(2026-06-30, digitallysovereign.org/c/members/32) موجود بالفعل.
تم تطبيق إعادة التعيين جزئياً فقط بسبب الخطأ أعلاه. يرجى إعادة تشغيل النص البرمجي مرة أخرى.
حسناً، أعتقد أن الاستعلام الأولي كان يستخدم التطابق الحرفي، لذا فاتته جميع الصفوف التي تحتوي على مسارات مرفقة. سأحاول استخدام استعلام SQL هذا (لا يمكنني حقاً اختبار أي من هذا لأنني لا أحتاج إلى تغيير اسم النطاق على خادم الأسماء الخاص بي).
DELETE FROM browser_pageview_referrer_daily_rollups old_table
WHERE old_table.normalized_referrer LIKE '%discourse.tobiaseigen.org%'
AND EXISTS (
SELECT 1
FROM browser_pageview_referrer_daily_rollups new_table
WHERE new_table.date = old_table.date
AND new_table.normalized_referrer = REPLACE(old_table.normalized_referrer, 'discourse.tobiaseigen.org', 'digitallysovereign.org')
);
\q
إذا نجح ذلك دون أخطاء، فقم بتشغيل أداة إعادة التعيين (remap tool) ومهمة إعادة الخبز (rebake rake task) التي قمت بنشرها أعلاه.
لقد قمت بنقل منتدى إلى خادم جديد واسم نطاق جديد قبل بضعة أشهر، لكن أداة إعادة التعيين (remap tool) عملت بشكل مثالي بالنسبة لي في المرة الأولى.
أبدو أنني أتقدم ببطء عبر قاعدة البيانات. تم حذف 24 سجلًا! والآن أنا عند unique_post_links.
root@digitallysovereign-app:/var/www/discourse# discourse remap discourse.tobiaseigen.org digitallysovereign.org
إعادة كتابة جميع حالات discourse.tobiaseigen.org إلى digitallysovereign.org
سيتم التشغيل على قاعدة البيانات 'default'
هذه المهمة ستعيد كتابة البيانات، هل أنت متأكد (اكتب YES): yes
إعادة تعيين الجداول على default...
browser_pageview_referrer_daily_rollups=1466
categories=2
chat_message_links=4
chat_message_search_data=4
chat_messages=5
discourse_activity_pub_collections=1
discourse_activity_pub_objects=1
drafts=4
email_logs=797
group_histories=2
groups=2
incoming_emails=21
moved_posts=2
notifications=10
post_localizations=51
post_revisions=31
post_search_data=226
posts=774
site_settings=1
stylesheet_cache=1168
خطأ: خطأ: قيمة المفتاح المكرر تنتهك قيد الفريدة "unique_post_links"
التفاصيل: المفتاح (topic_id, post_id, url)=(581, 3696, https://digitallysovereign.org) موجود بالفعل.
تم تطبيق إعادة التعيين جزئيًا فقط بسبب الخطأ أعلاه. يرجى إعادة تشغيل البرنامج النصي مرة أخرى.
SELECT tablename
FROM pg_indexes
WHERE indexname = 'unique_post_links';
هل يجب أن يعيد topic_links؟ إذن هذه هي الخطوة المنطقية التالية:
DELETE FROM topic_links old_link
WHERE old_link.url LIKE '%discourse.tobiaseigen.org%'
AND EXISTS (
SELECT 1
FROM topic_links new_link
WHERE new_link.topic_id = old_link.topic_id
AND new_link.post_id = old_link.post_id
AND new_link.url = REPLACE(old_link.url, 'discourse.tobiaseigen.org', 'digitallysovereign.org')
);
\q
أعتقد أننا اقتربنا من نهاية مخطط قاعدة البيانات، لذا من المرجح أن يكون هذا هو العقبة الأخيرة (أتمنى ذلك) قبل تشغيل عملية إعادة التعيين ومهمة rake التي قمت بنشرها أعلاه…
root@digitallysovereign-app:/var/www/discourse# discourse remap discourse.tobiaseigen.org digitallysovereign.org
إعادة كتابة جميع حالات discourse.tobiaseigen.org إلى digitallysovereign.org
سيتم التشغيل على قاعدة بيانات 'default'
هذه المهمة ستعيد كتابة البيانات، هل أنت متأكد (اكتب YES): yes
إعادة تعيين الجداول على default...
topic_links=1449
topic_search_data=11
topics=11
user_auth_token_logs=5
user_histories=131
تم
كنت أتذكر الأمر بشكل خاطئ لأن من النادر أن أقوم بهذا النوع من استعلامات SQL داخل الحاوية. كنت أعتقد حقاً أن هذه هي الأوامر الصحيحة. أعتقد أن السبب هو أن Discourse يأتي بأوامر مدمجة مثل discourse backup وdiscourse remap.
حسنًا، فقط من باب التجربة، قمت بإنشاء طلب سحب (PR) سريع لملف script/discourse لاستخدام أمر discourse db. لست متأكدًا حقًا مما إذا كانت الفريق يريد إضافة هذا، لكنه يسهل بالفعل الدخول إلى وحدة تحكم sql داخل الحاوية.
↩︎
