(Миграция 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. Следите за ходом выполнения

   Следить за ходом выполнения скрипта можно, просматривая в режиме tail файл журнала /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"
           
       

       (Повторите для каждого проверяемого id проекта, заменяя 000000000000000000000000 по очереди на один id проекта.)

    2. Откройте редактор проекта https://my-server-pro.example.com/project/000000000000000000000000

    3. Откройте панель «History» проекта и убедитесь, что отображается последнее содержимое.

    4. Необязательно: снова закройте панель «History». Внесите изменение в код, например добавьте комментарий в заголовок.

    5. Необязательно: запустите повторную компиляцию, чтобы инициировать сброс локального изменения. Снова откройте панель «History» и убедитесь, что изменение отображается. По завершении отмените изменение.

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

    Снова запустите остальные воркеры.

13. Не останавливайте экземпляр

    Пожалуйста, не останавливайте экземпляр, который выполнил процесс восстановления. Он будет в фоновом режиме повторно синхронизировать историю всех проектов с параллелизмом 1. Это приведёт к незначительному повышению базовой нагрузки. (Экземпляр можно перезапустить, но тогда повторную синхронизацию придётся начинать заново.)

14. Сообщите нам о завершении

    Клиенты Server Pro: пожалуйста, сообщите команде поддержки, когда завершите процесс восстановления.