> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/uk/pidtrimka/support-guides/full-project-history-migration.md). # (Міграція v3.5.13) Міграція повної історії проєкту ## Перенесення повної історії проєкту Поле `3.5.x` випуск Community Edition включає [функцію повної історії проєкту](https://www.overleaf.com/learn/latex/Using_the_History_feature) яка вже доступна в нашій SaaS-пропозиції, [overleaf.com](http://overleaf.com/) Після оновлення вашого екземпляра до Overleaf CE `3.5.13`, усі нові проєкти за замовчуванням використовуватимуть Повну історію проєкту. Наявні проєкти й надалі використовуватимуть застарілу систему історії, доки їх не буде перенесено. {% hint style="info" %} Якщо ви оновитеся до `3.5.13` і вирішите понизити версію до попередньої, тоді слід відновити систему з повної резервної копії. Історія проєктів, створених у `3.5.13` несумісна з попередніми версіями Overleaf CE. {% endhint %} Нова Повна історія проєкту приносить кілька покращень для користувачів: * Вона відстежує зміни в бінарних файлах, що не підтримується в застарілій системі. * Є підтримка позначених версій. * Загалом система є більш надійною, ризик втрати даних нижчий. Перегляньте [документацію з Повної історії проєкту](https://www.overleaf.com/learn/latex/Using_the_History_feature) щоб дізнатися більше про повну історію проєкту. ### Міграція наявних проєктів {% stepper %} {% step %} #### Створіть резервну копію Створіть повну [резервну копію](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) вашого екземпляра з узгодженим знімком **mongo**, **redis** та **контейнера sharelatex** каталогів. {% endstep %} {% step %} #### Оновіть Оновіть версію образу sharelatex/sharelatex до 3.5.13. Toolkit: Використайте `$ bin/upgrade` скрипт для оновлення toolkit до найновішої версії та відредагуйте **config/version** до 3.5.13. {% endstep %} {% step %} #### Запустити екземпляр В ідеалі, варто не дозволяти користувачам отримувати доступ до вашого екземпляра, поки триває міграція, щоб уникнути втрати даних у разі, якщо вам знадобиться відновити резервну копію. Див. [Офлайн-міграція](https://github.com/overleaf/overleaf/wiki/Full-Project-History-Migration/#offline-migration) для отримання додаткової інформації про те, як це зробити. {% endstep %} {% step %} #### Зачекайте, доки всі служби запустяться та працюватимуть Зачекайте, доки всі служби запустяться та працюватимуть (див. команду нижче) {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "curl http://localhost:3000/status" web sharelatex працює (api)% ``` {% endcode %} {% endstep %} {% step %} #### Запустіть скрипт міграції {% code overflow="wrap" %} ```bash # Користувачі Overleaf Toolkit: $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file" # користувачі legacy docker-compose.yml: $ docker exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file" ``` {% endcode %} `--force-clean` очищає частково перенесені дані історії проєктів у новій системі; це дає змогу повторити міграцію для окремих проєктів, що не вдалися під час попередніх спроб; `--fix-invalid-characters` замінює недруковані символи, які не підтримуються новою системою історії; `--convert-large-docs-to-file` перетворює документи, розмір яких перевищує поріг редагованого розміру 2 МБ, на не редагований файл) Вивід має виглядати так: ```bash Мігровані проєкти : 1 Усього проєктів : 51 Залишилося проєктів : 51 Загальна кількість записів історії для міграції: 98 Початок міграції... Міграція проєкту: 63d29b5772dd80015a81bffe результат міграції { upgraded: true, historyType: 'NoneWithoutConversion' } Міграція проєкту: 63d29c2e72dd80015a81c0a2 результат міграції { upgraded: true, historyType: 'NoneWithoutConversion' } // … Міграцію завершено ================== Мігровано проєктів: 51 Проєктів з помилками: 0 Готово. ``` Якщо міграція успішна, ви отримаєте код завершення `0`, а останні рядки вказуватимуть на відсутність помилок: ```bash Проєктів з помилками: 0 Готово. ``` Ви можете знову відкрити доступ для своїх користувачів (див. наступний крок). Якщо є помилки, будь ласка, див. розділ усунення неполадок нижче. Ви все ще можете знову відкрити сайт, якщо проблеми не будуть усунуті негайно, а проєкти, що не були перенесені, залишаться в застарілій системі історії. {% endstep %} {% step %} #### Знову відкрити сайт Якщо ви обрали офлайн-міграцію, вам потрібно буде знову відкрити сайт. Якщо ви все ще увійшли, вам потрібно буде: 1. Натисніть кнопку **Адмін** кнопку і виберіть **Керувати сайтом** 2. Натисніть кнопку **Відкрити/закрити редактор** вкладку 3. Натисніть кнопку **Знову відкрити редактор** кнопку Якщо ви закрили браузер, тоді вам потрібно перезапустити сайт за допомогою `$ bin/up`. {% endstep %} {% endstepper %} #### Офлайн-міграція Щоб запобігти можливості входу користувачів, поки виконується скрипт міграції історії, виконайте такі кроки: * Увійдіть до вашого екземпляра Overleaf за допомогою облікового запису адміністратора * Натисніть кнопку **Адмін** кнопку і виберіть **Керувати сайтом** * Натисніть кнопку **Відкрити/закрити редактор** вкладку * Натисніть кнопку **Закрити редактор** кнопку * Натисніть кнопку **Від’єднати всіх користувачів** кнопку Після цього, якщо будь-які користувачі вже увійшли, їх буде перенаправлено на сторінку технічного обслуговування, а будь-які нові користувачі, які відвідають сторінку входу, побачать сторінку технічного обслуговування і **не зможуть** увійти. #### Онлайн-міграція Можна запускати скрипти міграції, поки застосунок ще працює. Є кілька моментів, які слід врахувати: * Процес міграції є ресурсоємним для CPU; слід відстежувати використання ресурсів під час виконання скрипта. * За високого значення `--concurrency` у деяких службах (`track-changes` зокрема) `може виникати певне блокування циклу подій, що призведе до погіршення UX. Рекомендуємо починати з типового` --concurrency=1 * значення. Ми рекомендуємо закрити сайт і виконати міграцію офлайн під час вікна технічного обслуговування, коли кількість ваших проєктів менша за 1000 (`db.projects.count()`). Якщо кількість проєктів велика, ви можете запустити скрипт і спостерігати за його прогресом, а потім вирішити, чи продовжувати виконання онлайн чи офлайн залежно від вашого конкретного випадку. #### Очищення застарілих даних історії Скрипт для очищення застарілих даних історії було додано в Server Pro `3.5.6`, `4.0.6` та `4.1.0`. {% code overflow="wrap" %} ```bash bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/history/clean_sl_history_data.js" ``` {% endcode %} Скрипт можна запускати після того, як усі проєкти буде перенесено. Його також можна використати, щоб звільнити трохи місця під час виконання онлайн-міграції. {% hint style="info" %} У Server Pro до версії 3.5.13 скрипт видаляє вміст `docHistory` та `docHistoryIndex` колекцій. MongoDB не звільняє місце на диску після видалення документів, натомість повторно використовує це місце для майбутніх документів у тій самій колекції. Після міграції історії до цих колекцій більше нічого не записуватиметься, тож місце на диску залишиться невикористаним. Якщо ви хочете знову зробити місце на диску доступним, ви можете оновитися до Server Pro 3.5.13 (якщо ви досі використовуєте випуск 3.x) або Server Pro 4.2.5 (якщо ви використовуєте випуск 4.x) і повторно запустити скрипт очищення. Скрипт очищення, який включено в Server Pro у найновіших патч-випусках `3.5.x` і найновіших `4.x.x` видаляє колекції на фінальному кроці. Безпечно запускати скрипт очищення повторно. {% endhint %} ### Усунення неполадок Ми додамо тут поради з усунення неполадок. Зверніть увагу, що хоча зазвичай ми надаємо підтримку лише клієнтам Server Pro, з огляду на характер цієї міграції ми також зробимо все можливе, щоб підтримати клієнтів CE, які зіткнулися з проблемами, специфічними для міграції на повну історію проєкту. Якщо скрипт міграції повної історії проєкту завершується збоєм (тобто завершується з помилкою або виводить ненульову кількість проєктів із помилками), будь ласка, надішліть такі відомості нашій службі підтримки електронною поштою [support+historymigration@overleaf.com](mailto:support+historymigration@overleaf.com?subject=Full%20project%20history%20migration%20problem\&body=Instance%20Type%3A%20CE%20or%20Server%20Pro%20%28delete%20as%20appropriate%29%0A%0AInstallation%20Type%3A%20Overleaf%20toolkit%20or%20docker-compose.yml%20or%20other%20%28delete%20as%20appropriate%29%0A%0AScript%20output%3A%0A%0Abin%2Fdoctor%20output%20%28if%20using%20toolkit%29%3A%0A), вказавши: Тема: Проблема з міграцією повної історії проєкту * Тип екземпляра: CE або Server Pro (видаліть, якщо не підходить) * Тип встановлення: Overleaf toolkit або `docker-compose.yml` або інше (видаліть, якщо не підходить) * Версія: 3.5.x (toolkit: `$ cat config/version`) * Вивід скрипта міграції (який має бути розташований у контейнері в `/overleaf/services/web`) * Мігровані проєкти: (як у виводі скрипта міграції) * Усього проєктів: (як у виводі скрипта міграції) * Залишилося проєктів: (як у виводі скрипта міграції) * Тривалість міграції: * `bin/doctor` вивід (під час використання toolkit) * Версія toolkit: `$ git rev-parse HEAD` (під час використання Toolkit) Розгляньте можливість долучення файлів журналів для `history-v1`, `project-history` та `track-changes` служб до електронного листа. Ви можете знайти їх у `/var/log/sharelatex` всередині `контейнера sharelatex` контейнера та експортувати їх так: ```bash $ docker cp sharelatex:/var/log/sharelatex/history-v1.log history-v1.log $ docker cp sharelatex:/var/log/sharelatex/project-history.log project-history.log $ docker cp sharelatex:/var/log/sharelatex/track-changes.log track-changes.log ``` Будь ласка, замажте будь-яку конфіденційну інформацію у файлах журналів перед їх долученням. #### Пошук пошкоджених дерев файлів Міграція може завершитися невдачею для проєктів із неправильним деревом файлів (наприклад, коли імена файлів порожні). Ви можете знайти перелік цих проблем за допомогою `find_malformed_filetrees` скрипта, який перевіряє всі проєкти в базі даних: {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/find_malformed_filetrees.js" ПОГАНИЙ ШЛЯХ: 123456789012345678901234 rootFolder.0.1.2.3 ПОГАНИЙ ШЛЯХ: 123456789012345678901234 rootFolder.0.4.5.6 ... ``` {% endcode %} Щоб виправити неправильні шляхи, використайте `fix_malformed_filetree` скрипт, запускаючи команду один раз для кожного поганого шляху: {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.1.2.3" $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.4.5.6" ... ``` {% endcode %} #### Пониження проєктів із повної історії проєкту до застарілої історії Якщо є проєкт, який було перенесено на повну історію проєкту, але ви хочете повернутися до застарілої історії, використайте `downgrade_project` скрипт так: {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; PROJECT_ID=YOUR ``` {% endcode %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ayakaleaf-pro.ayaka.space/on-premises/uk/pidtrimka/support-guides/full-project-history-migration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.