(Міграція 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.

Тривалість відновлення залежить від кількості та розміру проєктів у вашому екземплярі, а також від бекенду сховища, який сховище історії використовує для фрагментів (визначено в OVERLEAF_HISTORY_CHUNKS_BUCKET).

Процес відновлення затримує запуск застосунку всередині контейнера Server Pro. Протягом цього часу сайт буде недоступним. Ми підтримуємо запуск відновлення лише з одного екземпляра контейнера Server Pro; усі інші воркери горизонтального масштабування мають бути вимкнені.

За потреби процес відновлення можна зупинити та відновити.

За нашими тестами продуктивності, процес відновлення може обробляти приблизно 10 тис. невеликих проєктів за хвилину на сучасному обладнанні (CPU з тактовою частотою 3 ГГц і локальне сховище 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. Визначте кілька проєктів

   Визначте за id кілька проєктів, у яких відсутня історія; бажано, щоб у вас були права вносити зміни в один із них.

3. Заплануйте обслуговування

   Заплануйте вікно обслуговування для простою.

4. Зупиніть усі воркери, крім одного

   Якщо використовується горизонтальне масштабування, зупиніть усі воркери, крім одного.

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., або чекайте, доки у стандартний вивід контейнера Server Pro не буде виведено Finished recovery of doc versions..

11. Перевірте процес відновлення

    Перевірте результат відновлення, відкривши панель історії для кількох проєктів, у яких раніше була відсутня історія.

    1. Пришвидшіть повторну синхронізацію проєктів для перевірки (зрештою їх буде оброблено, але ми не хочемо чекати їхньої черги).

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

       (Повторіть для кожного project-id, який потрібно перевірити, замінюючи 000000000000000000000000 на один project-id за раз.)

    2. Відкрийте редактор проєкту для проєктів https://my-server-pro.example.com/project/000000000000000000000000

    3. Відкрийте панель “History” для проєкту й перегляньте найновіший вміст.

    4. Необов’язково: знову закрийте панель “History”. Внесіть зміну в код, наприклад додайте коментар у заголовок.

    5. Необов’язково: запустіть повторну компіляцію, щоб ініціювати скидання локальної зміни. Знову відкрийте панель “History” і перегляньте зміну. Після завершення скасуйте зміну.

12. Для горизонтального масштабування...

    Знову запустіть інші воркери.

13. Залиште екземпляр запущеним

    Будь ласка, залиште запущеним екземпляр, який виконував процес відновлення. Він у фоновому режимі повторно синхронізуватиме історію всіх проєктів із паралельністю 1. Це призведе до дещо підвищеного базового навантаження. (Екземпляр можна перезапустити, але тоді повторні синхронізації почнуться спочатку.)

14. Повідомте нас, коли завершите

    Клієнти Server Pro: будь ласка, повідомте команду підтримки, коли завершите процес відновлення.