(ترحيل v5.0.1) استعادة إصدارات المستندات

إذا لم تشغّل مطلقًا Server Pro الإصدار 5.0.1 أو Community Edition الإصدار 5.0.1، أو إذا بدأت نسخة جديدة كليًا بالإصدار 5.0.1، فلا تحتاج إلى تشغيل عملية الاستعادة هذه.

• (2024-04-22 13:40 BST): أُضيفت الخطوة “إيقاف دخول تحديثات جديدة إلى النظام وتفريغ جميع التغييرات إلى MongoDB”.
• (2024-04-23 11:45 BST): مراعاة عمليات التفريغ المعطّلة في 5.0.1 وتخطي عمليات التفريغ إذا كان الإصدار 5.0.2 قد شُغّل.

تعتمد مدة الاستعادة على عدد المشاريع وحجمها في نسختك، وعلى واجهة التخزين الخلفية التي يستخدمها مخزن السجل لتخزين الأجزاء (chunks) (كما هو محدد في OVERLEAF_HISTORY_CHUNKS_BUCKET).

ستؤخّر عملية الاستعادة بدء تشغيل التطبيق داخل حاوية Server Pro. وسيظهر الموقع غير متصل خلال تلك المدة. ندعم تشغيل الاستعادة من نسخة واحدة فقط من حاوية Server Pro، ويجب أن تكون جميع عمليات التوسع الأفقي الأخرى (workers) متوقفة.

يمكنك إيقاف عملية الاستعادة واستئنافها عند الحاجة.

بناءً على اختبارات الأداء التي أجريناها، يمكن لعملية الاستعادة معالجة نحو 10 آلاف مشروع صغير في الدقيقة على عتاد حديث (معالج بسرعة 3GHz وتخزين NVMe محلي). على سبيل المثال، بالنسبة لنسخة تضم 100 ألف مشروع، حدد نافذة صيانة تسمح بتوقف لا يقل عن 10+2 دقيقة. استخدم الاستعلام التالي لتقدير عدد المشاريع في نسختك:

$ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()'

يُرجى قراءة خطوات الاستعادة التالية بالكامل قبل البدء. ويُرحَّب بعملاء Server Pro للتواصل مع [e-mail] لأي استفسارات.

​

عملية الاستعادة

1. سحب صور الإصدار

   اسحب صور الإصدار 5.0.3.

2. تحديد بعض المشاريع

   حدد بعض المشاريع بمعرّفاتها التي ينقصها السجل؛ ويُفضَّل أن تكون لديك صلاحية إجراء تغيير على أحدها.

3. جدولة الصيانة

   حدد نافذة صيانة لفترة التوقف.

4. إيقاف جميع العمليات عدا واحدة

   أوقف جميع العمليات (workers) عدا واحدة عند استخدام إعداد التوسع الأفقي.

5. إيقاف التحديثات الجديدة وتفريغ جميع التغييرات إلى MongoDB

   أوقف دخول تحديثات جديدة إلى النظام وفرّغ جميع التغييرات إلى MongoDB:

   1. أغلق المحرر وافصل جميع المستخدمين يدويًا عبر لوحة الإدارة على https://my-server-pro.example.com/admin#open-close-editor في علامة التبويب “Open/Close Editor”.

   2. أوقف خدمة Websocket/real-time.

      $ docker exec sharelatex sv stop real-time-overleaf
      

   3. انتظر حتى تتوقف خدمة real-time، كما يدل على ذلك down:.

      $ docker exec sharelatex sv status real-time-overleaf
      run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
      # wait a little longer...
      
      $ docker exec sharelatex sv status real-time-overleaf
      down: real-time-sharelatex: 7s, normally up
      

   4. أوقف حاوية git-bridge إذا كانت مفعّلة.

      $ docker stop git-bridge
      

   5. إذا لم تشغّل الإصدار 5.0.2 مطلقًا: نفّذ تفريغًا يدويًا لتحديثات المستندات وانتظر حتى ينتهي بنجاح.

      يمكنك تكرار الأمر عند حدوث خطأ. إذا رأيت قيمة غير صفرية لـ failureCount في عمليات تشغيل متتالية، فيُرجى إيقاف الترحيل (استعد الخدمات عبر docker restart git-bridge sharelatex) والتواصل مع الدعم.

      $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /etc/overleaf/env.sh && cd services/document-updater && LOG_LEVEL=info node scripts/flush_all.js'
          ...
          {"name":"default","hostname":"...","pid":324,"level":30,"successCount":...,"failureCount":0,"msg":"finished flushing all projects","time":"...","v":0}
          Done flushing all projects
          
      

   6. إذا لم تشغّل الإصدار 5.0.2 مطلقًا: تأكد من تفريغ جميع التغييرات من redis.

      إذا حصلت على أي مخرجات من redis-cli، فيُرجى إيقاف الترحيل (استعد الخدمات عبر docker restart git-bridge sharelatex) والتواصل مع الدعم.

      $ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
          # no output from redis-cli indicates success, check exit code of redis-cli next, it should be zero
          $ echo $?
          0
          
      

   7. حاول تفريغ أي تغييرات معلّقة في السجل.

      سيكون هذا تفريغًا بأفضل جهد ممكن، إذ إن بعض المشاريع لديها سجلات معطوبة بسبب ترحيل قاعدة البيانات الخاطئ. وستُعالَج أي حالات فشل بإعادة مزامنة السجل في نهاية عملية الاستعادة.

      $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /
          
      
6. أخذ نسخة احتياطية

   فكّر في أخذ نسخة احتياطية متسقة من النسخة.

7. الترقية

   قم بالترقية إلى الإصدار 5.0.3.

8. الاستعادة التلقائية

   تعمل عملية الاستعادة تلقائيًا عند بدء تشغيل الحاوية.

9. متابعة التقدم

   يمكنك متابعة تقدم السكربت من خلال متابعة ملف السجل /var/lib/overleaf/data/history/doc-version-recovery.log. سيطبع إجمالي عدد المشاريع في البداية، وملخصًا بعد معالجة كل 1000 مشروع.

   $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers
   
10. انتظر حتى تنتهي عملية الاستعادة

    انتظر حتى تنتهي عملية الاستعادة، إما بمتابعة ملف السجل أعلاه حتى يُطبع سطر Done.، أو بانتظار طباعة Finished recovery of doc versions. في المخرجات القياسية لحاوية Server Pro.

11. التحقق من عملية الاستعادة

    تحقق من عملية الاستعادة بفتح لوحة السجل لبعض المشاريع التي كان ينقصها السجل سابقًا.

    1. عجّل إعادة المزامنة للمشاريع المراد اختبارها (ستُعالَج في النهاية، لكننا لا نريد انتظار دورها.)

       $ docker exec sharelatex curl -X POST --silent "http://127.0.0.1:3054/project/000000000000000000000000/resync?force=true"
           
       

       (كرّر ذلك مع كل معرّف مشروع تريد اختباره، واستبدل 000000000000000000000000 بمعرّف مشروع واحد في كل مرة.)

    2. افتح محرر المشروع للمشاريع https://my-server-pro.example.com/project/000000000000000000000000

    3. افتح لوحة “History” للمشروع وشاهد أحدث محتوى.

    4. اختياري: أغلق لوحة “History” مرة أخرى. أجرِ تغييرًا في الشيفرة، مثل إضافة تعليق إلى الترويسة.

    5. اختياري: نفّذ إعادة ترجمة لتفعيل تفريغ التغيير المحلي. افتح لوحة “History” مرة أخرى وشاهد التغيير. عند الانتهاء، تراجع عن التغيير.

12. للتوسع الأفقي...

    أعد تشغيل العمليات (workers) الأخرى.

13. أبقِ النسخة قيد التشغيل

    يُرجى إبقاء النسخة التي نفّذت عملية الاستعادة قيد التشغيل. ستعيد مزامنة السجل لجميع المشاريع في الخلفية بدرجة تزامن قدرها 1. وسيؤدي ذلك إلى ارتفاع طفيف في الحمل الأساسي. (يمكنك إعادة تشغيل النسخة، لكنها ستحتاج إلى البدء من جديد في عمليات إعادة المزامنة.)

14. أخبرنا عند الانتهاء

    عملاء Server Pro: يُرجى إبلاغ فريق الدعم عند إكمال عملية الاستعادة.