من فضلك، هل يمكنك تزويدنا بتوجيهات حول الملف الذي يجب تعديله في نسخة احتياطية بصيغة tar؟
يوجد ملف dump.sql مضغوط داخل الأرشيفات. تحتاج إلى تعديله ثم إعادة ضغط النسخة المعدلة مرة أخرى. لقد حللت مشاكلي الأخرى أيضًا عن طريق تعديله - قمت بإزالة بعض الحقول المخصصة الخاطئة التي كانت تسبب انهيار النظام بعد تسجيل الدخول.
شكرًا لك.
سأحاول تنزيل النسخة الاحتياطية، وفك ضغطها، وتعديل الملف وفقًا لتعليماتك.
من المقلق حقًا الاضطرار إلى القيام بكل هذا لاستعادة نسخة احتياطية.
أعتقد أن هذا خلل في الإصدار الجديد.
لكن النسخ الاحتياطي والاستعادة هما حجر الزاوية في خطة التعافي من الكوارث.
يجب أن يكونا قويين قدر الإمكان، وأن يكون للخلل في هذه العمليات تأثير كبير.
إعجاب واحد (1)
حسنًا، تمكنت من استعادة النسخة الاحتياطية دون إجراء أي تغييرات في ملفها.
لقد جربت الأمر عدة مرات، وغريبًا بما فيه الكفاية، نجحت عملية الاستعادة مرة واحدة دون أي أخطاء.
تم طردي من منصة Discourse ولم تعمل حتى قمت بإنشاء تطبيق لإعادة بناء المشغل.
لكن الآن تعمل بشكل صحيح.
مشكلة غريبة.
لا يزال هذا يسبب لي مشكلة في استعادة منتداي من النسخة الاحتياطية. لقد مرّت عدة أسابيع ولا يزال وظيفة الاستعادة من النسخة الاحتياطية تبدو معطلة.
هل هناك أي حل لهذا؟
بحسب ما أستطيع استنتاجه، الأمر يتطلب التبديل بين التحديث، والتحقق من تنسيق الجداول، والتأكد من تطابق كل شيء بين المصدر والمضيف، ومراقبة الفشل عدة مرات، وقد ينجح ذلك أو لا ينجح دون إجراء بعض التعديلات البسيطة على قاعدة البيانات.
لقد نجحت في نقل موقعين من أصل ثلاثة، وأنا مضطر لقضاء أقل من ساعة يوميًا في هذا العمل للحفاظ على راحتي النفسية. لقد بدأت في مناقشة العملاء حول المشكلات التي قد تسببها هذه الحالة في المستقبل في أي موقف مماثل. رفع كتف
أنا أصر ببساطة على استعادة النسخة الاحتياطية وقد تمكنت من جعلها تعمل.
الخطأ يشير إلى عمود غير موجود في جدول ملف تعريف المستخدم.
لكن يجب أن يكون خطأً في المهلة الزمنية أو شيء مشابه على جانب قاعدة البيانات، ربما يكون هناك خلل في جانب PostgreSQL. إذا لم يكن العمود موجودًا، فلن يتم إنشاؤه تلقائيًا عند الإصرار على الاستعادة.
يقول جارومير إن تغيير السكربت يحل المشكلة.
لا يبدو أن أيًا من مطوري Discourse هنا قد اهتم بهذه المشكلة، لكنها خطأ غريب ومقلق للغاية، إذ يؤثر على خطة التعافي من الكوارث.
ربما لم يُلاحظ هذا الموضوع وسط المواضيع الأخرى.
لم يمر مرور الكرام. سيكون أول ما سأبحث فيه غدًا.
وأنا أبدأ في العمل على تحسين النسخ الاحتياطية والاستعادة، لأنه لا ينبغي على أحد أن يقلق بشأن هذه الأمور في حالة وقوع كارثة أو عندما ترغب ببساطة في الانتقال إلى خادم جديد.
11 إعجابًا
عظيم. شكرًا لك.
يسعدني سماع ذلك.
شكرًا لك، غيرهارد. لا أعرف ما إذا كنت تهتم الآن، لكنني أيضًا أواجه مشكلة في موقع يستخدم PG 11 مع GCP. قد يكون من الجيد التحقق من ذلك، حيث قد يؤثر على الانتقال المستقبلي إلى PG12 الذي أفهم أنه من المقرر أن يحدث في وقت لاحق من هذا الخريف.
لقد قمت مؤخرًا بترقية نسختين تشاركان سلة نسخ احتياطي على S3. قمت بتشغيل نسخة احتياطية على واحدة وحاولت استعادتها على الأخرى، وحصلت على الرسالة التالية:
لا توجد هجرة برقم إصدار 20191007140446.
لا يتم دعم PostgreSQL 11 و 12 حاليًا.
4 إعجابات
حسناً، قمت بتثبيت أحدث إصدار من Discourse (tests-passed) على Droplet، وتمت عملية استعادة النسخ الاحتياطية (بما في ذلك الملفات المرفوعة، دون استخدام S3 للملفات) دون أي مشاكل.
إذا كنت لا تزال تواجه مشاكل أثناء الاستعادة، يرجى اتباع الخطوات التالية:
-
إعادة بناء الحاوية:
cd /var/discourse git pull ./launcher rebuild app -
استعادة النسخة الاحتياطية إما عبر واجهة الويب أو سطر الأوامر:
cd /var/discourse ./launcher enter app discourse enable_restore discourse restore <filename>
إذا لم تنجح العملية، يرجى نشر رقم إصدار ملف النسخة الاحتياطية الذي تحاول استعادته، بالإضافة إلى رسالة الخطأ التي تظهر أثناء الاستعادة.
6 إعجابات
كلا الموقعين يعملان على الإصدار 2.4.0.beta6 (8fc0cc9aaa). النسخ الاحتياطية (وليس الملفات المرفوعة) موجودة على S3.
discourse restore يعيد النتيجة التالية:
Starting restore: wonderful-community-2019-10-10-184822-v20191007140446.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2019-10-10-211121 exists...
Downloading archive to tmp directory...
Unzipping archive, this may take a while...
EXCEPTION: Compression::Strategy::ExtractFailed
/var/www/discourse/lib/compression/gzip.rb:49:in `block in extract_file'
/var/www/discourse/lib/compression/gzip.rb:45:in `open'
/var/www/discourse/lib/compression/gzip.rb:45:in `extract_file'
بالطبع، وأعتقد أن ذلك الموقع سيرضى بنسخ احتياطية مباشرة لقاعدة البيانات على GCP على أي حال، ولكن في مرحلة ما قال سام إنه يشغل PG 11 على موقعه التجريبي وأنه سيكون مهتمًا بمعرفة أي مشاكل تتعلق بـ PG11.
@pfaffman يرجى زيادة إعداد الموقع decompressed_file_max_size_mb (وهو مخفي). القيمة الافتراضية مضبوطة حاليًا على 1 جيجابايت.
لدي طلب دمج جاهز لرفع القيمة الافتراضية إلى 100 جيجابايت، لكنه لم يُدمج بعد:
7 إعجابات
شكرًا لك، @Roman. حسنًا، تم حل هذه المشكلة.
لكن الآن لدي الكثير من رسائل الخطأ invalid command \N (وامتلأ المخزن المؤقت قبل أن أتمكن من معرفة ما جاء قبلها)، ولكن ربما
ERROR: syntax error at or near "Shiny"
LINE 1: Shiny contest submission 2019-01-07 20:00:05.570573 2019-01-...
^
EXCEPTION: psql failed
/var/www/discourse/lib/backup_restore/restorer.rb:324:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
هو ما تحتاج إلى معرفته.
نعم، أعتقد أن ذلك سببه PG11.
إعجابَين (2)
لو كان الأمر يتعلق بـ pg11 لوافقتك الرأي! لكن هذا تثبيت قياسي يتكون من حاويتين.
انتظر! هناك عدم تطابق في الإصدار.
root@community:/var/discourse# ./launcher enter data root@staging-data:/# psql --version
psql (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)
الإصدار الذي أعيد تهيئته عليه هو 10.9! أعتقد أن هذا هو السبب. (أظن أن pg11 يفشل بطريقة مماثلة، لكنني في تلك الحالة أحاول الاستعادة على نفس المثيل).
سأقوم بترقية حاويات البيانات غدًا وأبلغك بالأمر. شكرًا على مساعدتك.
3 إعجابات
حسنًا، قمت بترقية كلا النظامين إلى الإصدار 10.10 (باستخدام قوالب البيانات القياسية)، لكنني ما زلت أواجه رسائل “أمر غير صالح”.
عندما بدأت أخطاء “أمر غير صالح” في الظهور، قمت بإنهاء سكريبت الاستعادة قسرًا. أدت المحاولات اللاحقة للاستعادة (للحصول على الخطأ الأول قبل رسائل “أمر غير صالح”) إلى ما يلي:
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "theme_fields" does not exist
ثم قمت بتشغيل rake db:migrate على كلا النظامين، وقمت بنسخ احتياطي مرة أخرى، ونجح الاستعادة. ربما تم تخطي عملية هجرة ما في مرحلة ما من العملية؟
(بعد تغيير الإعداد المذكور أعلاه—إليك تعليمات كاملة لأولئك الذين قد يحتاجونها في الوقت القليل جدًا قبل أن تصبح غير ضرورية)
./launcher enter app
rails c
SiteSetting.decompressed_file_max_size_mb=1000000
إعجاب واحد (1)
لقد فشلت محاولة أخرى للتو. كلا الإصدارين هما 2.4.0.beta6 (إحداهما 2c011252f1، والأخرى قد تكون أحدث قليلاً).
أقوم بالاستعادة عبر S3. جربت كلا الخيارين مع الملفات المرفقة وبدونها. بدا أن كلاهما يعملان ثم فشلا بهذه الطريقة:
...
COPY 11871
COPY 3689
COPY 0
COPY 36550
COPY 0
COPY 14736
/usr/local/bin/discourse: line 2: 3232 Killed RAILS_ENV=production sudo -H -E -u discourse bundle exec script/discourse "$@"
هل هذه هي الرسالة الوحيدة التي تتلقاها؟
ماذا لو حاولت إزالة أي اعتماد على S3 ونسخ ملف النسخة الاحتياطية إلى الجهاز المحلي أولاً؟
@pfaffman، قد يكون من الجيد معرفة أن مشكلتي (أو ثلاث مشكلات) الاستعادة التي نشرتها في هذا الموضوع ليست من حالات الخطأ الذي كان هذا الموضوع يتحدث عنه في الأصل (مشكلة PG::UndefinedColumn: ERROR). قد تفكر في فتح مواضيع جديدة لهذه المشكلات لأنها مختلفة بوضوح.
4 إعجابات