neounix
11 فبراير 2021، 10:40ص
1
نحن نعمل حاليًا على هذا الإصدار الأخير:
ما زال يعمل في حاوية الإنتاج الخاصة بنا (بدون مشاكل).
أحاول البدء (bootstrap) بناءً على هذا الإصدار:
لقد حاولت عدة مرات اليوم، وفي كل مرة يتوقف عند هذا الحد:
تحققت من السجلات في حاوية البيانات وحاوية التطبيق الاحتياطية (التي نقوم بالبدء منها) ولم أجد أي أخطاء أو مشاكل.
في كل مرة أقوم فيها بالبدء، يتوقف عند هذا السطر:
I, [2021-02-11T10:37:25.133098 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
هل لديكم أي تلميحات حول أين يمكنني البحث للمساعدة في التصحيح؟
لقد تفحصت جميع السجلات التي يمكنني التفكير فيها (في جميع الحاويات) ولم أستطع العثور على مشاكل.
شكرًا لكم.
معلومات إضافية:
في كل مرة يتوقف فيها العملية، وأقوم بالضغط على Ctrl+C للخروج من عملية البدء، يبدو أنه يترك عملية postmaster، والتي يمكنني قتلها لاحقًا.
إليك مثال:
تحديث:
يعمل إعادة البناء بنجاح إذا قمت بإسقاط سطر “db:migrate” في قالب الويب.
هناك مشكلة غريبة مع “rails db:migrate” تتوقف دون أي أخطاء، وهي مشكلة لم أواجهها من قبل.
أتساءل هل هناك خطأ (أو مشكلة أساسية) في هذا الانتقال الأخير؟
committed 02:35AM - 11 Feb 21 UTC
Follow up https://github.com/discourse/discourse/pull/11968
Dismiss all new t… opics using the same DismissTopicService. In addition, MessageBus receives exact topic ids which should be marked as `seen`.
انظر أيضًا:
# frozen_string_literal: true
class MoveNewSinceToNewTable < ActiveRecord::Migration[6.0]
def up
sql = <<~SQL
INSERT INTO dismissed_topic_users (user_id, topic_id, created_at)
SELECT users.id, topics.id, user_stats.new_since
FROM user_stats
JOIN users ON users.id = user_stats.user_id
JOIN user_options ON user_options.user_id = users.id
LEFT JOIN topics ON topics.created_at <= user_stats.new_since
LEFT JOIN topic_users ON topics.id = topic_users.topic_id AND users.id = topic_users.user_id
LEFT JOIN dismissed_topic_users ON dismissed_topic_users.topic_id = topics.id AND users.id = dismissed_topic_users.user_id
WHERE user_stats.new_since IS NOT NULL
AND topic_users.id IS NULL
AND dismissed_topic_users.id IS NULL
AND topics.archetype <> :private_message
AND topics.created_at >= GREATEST(CASE
WHEN COALESCE(user_options.new_topic_duration_minutes, :default_duration) = :always THEN users.created_at
WHEN COALESCE(user_options.new_topic_duration_minutes, :default_duration) = :last_visit THEN COALESCE(users.previous_visit_at,users.created_at)
show original
david
11 فبراير 2021، 12:10م
2
مرحبًا @neounix ، نحن على علم بالمشكلة المتعلقة بالهجرة التي أشرت إليها ونعمل حاليًا على إصلاحها.
إعجابَين (2)
neounix
11 فبراير 2021، 12:13م
3
مرحباً @david
شكراً على ردك!
كنت أراجع عملية الترحيل للتو، وفكرتي الأولى، بصفتي «ليست خبيراً في ترحيل قواعد بيانات Discourse»، هي أن هذا قد يكون هو المشكلة؟
add_index :dismissed_topic_users, %i(user_id topic_id), unique: true
على أي حال، لست مؤهلاً للدخول بعمق أكبر في قضايا ترحيل Discourse، لذا سأعتزل وأبقى على أهبة الاستعداد.
شكراً مرة أخرى!
paresy
11 فبراير 2021، 4:32م
4
هل يمكننا التوقف بأمان عن عملية الهجرة دون فقدان أي بيانات والعودة إلى عدة ترجمات سابقة؟
نجح الأمر.
إعجاب واحد (1)
مرحبًا @neounix ،
نعتذر عن تضمين عملية الترحيل الثقيلة والمعيبة في قاعدة الكود. تم التراجع عن هذه التغييرات، لذا يجب أن يكون النشر الجديد سليمًا:
master ← KrisKotlarek:broken-migration
merged 09:50PM - 11 Feb 21 UTC
Revert of:
https://github.com/discourse/discourse/pull/12018
https://github.co… m/discourse/discourse/pull/12041
4 إعجابات
neounix
12 فبراير 2021، 1:37ص
6
مرحبًا @kris.kotlarek
شكرًا لك على التحديث:
أنا أميل إلى الموافقة على أن هذا “الهجرة الثقيلة” يتطلب على الأرجح مراجعة إضافية واختبارات تطوير صارمة على بيئة اختبار تحتوي على قاعدة بيانات كبيرة قبل دمجه في النواة. لحسن حظ موقعنا، قمت دائمًا بإعداد النظام بشكل متوازٍ مع بيئة الإنتاج، لذا لم نتعرض لأي توقف أثناء فشل الهجرة، فلا داعي للقلق من جانبنا. شكرًا لك على التراجع السريع.
ملاحظة فقط (لأكون دقيقًا تقنيًا، آسف على ذلك…): تفحصت قاعدة البيانات بعد إعادة البناء للتو، وتبين أن عملية “التراجع” لم تقم بحذف الجدول من قاعدة البيانات. لا مشكلة كبيرة، مجرد معلومة إضافية:
discourse=> \d dismissed_topic_users
Table "public.dismissed_topic_users"
Column | Type | Collation | Nullable | Default
------------+-----------------------------+-----------+----------+---------------------------------------------------
id | bigint | | not null | nextval('dismissed_topic_users_id_seq'::regclass)
user_id | integer | | |
topic_id | integer | | |
created_at | timestamp without time zone | | |
Indexes:
"dismissed_topic_users_pkey" PRIMARY KEY, btree (id)
"index_dismissed_topic_users_on_user_id_and_topic_id" UNIQUE, btree (user_id, topic_id)
شكرًا مرة أخرى على جهدك الكبير في هذا الأمر وعلى التراجع السريع عن الهجرة.
إعجابَين (2)
neounix
15 فبراير 2021، 4:06ص
7
هذه الهجرة تعمل بسلاسة الآن، استنادًا إلى آخر التزام:
master ← KrisKotlarek:new-approach-to-dismiss-new-migration
merged 09:50PM - 14 Feb 21 UTC
Original PR was reverted because of broken migration https://github.com/discours… e/discourse/pull/12058
I fixed it by adding this line
```
AND topics.id IN(SELECT id FROM topics ORDER BY created_at DESC LIMIT :max_new_topics)
```
This time it is left joining a limited amount of topics. I tested it on few databases and it worked quite smooth
4 إعجابات
Falco
18 فبراير 2021، 11:00ص
8
تم إغلاق هذا الموضوع تلقائيًا بعد 6 أيام. لم يعد مسموحًا بالردود الجديدة.
