> 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/pt/suporte/support-guides/full-project-history-migration.md). # (Migração v3.5.13) Migração do histórico completo do projeto ## Migração completa do histórico do projeto O `3.5.x` a versão da Community Edition inclui a [funcionalidade Histórico Completo do Projeto](https://www.overleaf.com/learn/latex/Using_the_History_feature) que já está disponível na nossa oferta SaaS, [overleaf.com](http://overleaf.com/) Depois de atualizar a sua instância para o Overleaf CE `3.5.13`, todos os novos projetos usarão o Histórico Completo do Projeto por defeito. Os projetos existentes continuarão a usar o sistema de Histórico legado, até serem migrados. {% hint style="info" %} Se atualizar para `3.5.13` e decidir fazer downgrade para uma versão anterior, então deverá restaurar a partir de uma cópia de segurança completa do sistema. O histórico dos projetos criados em `3.5.13` não é compatível com versões anteriores do Overleaf CE. {% endhint %} O novo Histórico Completo do Projeto traz várias melhorias para os utilizadores: * Acompanha as alterações em ficheiros binários, o que não é suportado no sistema legado. * Há suporte para versões com rótulos. * O sistema é, em geral, mais robusto; há menos hipótese de perda de dados. Consulte [documentação do Histórico Completo do Projeto](https://www.overleaf.com/learn/latex/Using_the_History_feature) para mais informações sobre o histórico completo do projeto. ### Migrando projetos existentes {% stepper %} {% step %} #### Criar uma cópia de segurança Criar uma cópia de segurança completa [cópia de segurança](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) da sua instância com uma snapshot consistente dos **mongo**, **redis** e **sharelatex** diretórios. {% endstep %} {% step %} #### Atualize Atualize a versão da imagem sharelatex/sharelatex para 3.5.13. Toolkit: Use o `$ bin/upgrade` script para atualizar o toolkit para a versão mais recente e edite **config/version** para 3.5.13. {% endstep %} {% step %} #### Inicie a instância Idealmente, deverá impedir que os utilizadores acedam à sua instância enquanto a migração decorre, para evitar perda de dados caso precise de restaurar a cópia de segurança. Consulte [migração offline](https://github.com/overleaf/overleaf/wiki/Full-Project-History-Migration/#offline-migration) para mais informações sobre como fazer isto. {% endstep %} {% step %} #### Espere até que todos os serviços estejam ativos e em execução Espere até que todos os serviços estejam ativos e em execução (veja o comando abaixo) {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "curl http://localhost:3000/status" web sharelatex está ativo (api)% ``` {% endcode %} {% endstep %} {% step %} #### Execute o script de migração {% code overflow="wrap" %} ```bash # Utilizadores do 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" # utilizadores do 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` limpa os dados do histórico do projeto parcialmente migrados no novo sistema; isto permite voltar a tentar a migração de projetos individuais que tenham falhado em tentativas anteriores; `--fix-invalid-characters` substitui caracteres não imprimíveis que não são suportados pelo novo sistema de histórico; `--convert-large-docs-to-file` converte documentos acima do limite de 2 MB de tamanho editável em ficheiros não editáveis) A saída deverá ter um aspeto semelhante a este: ```bash Projetos migrados : 1 Total de projetos : 51 Projetos restantes : 51 Total de registos de histórico a migrar: 98 A iniciar a migração... A migrar o projeto: 63d29b5772dd80015a81bffe resultado da migração { upgraded: true, historyType: 'NoneWithoutConversion' } A migrar o projeto: 63d29c2e72dd80015a81c0a2 resultado da migração { upgraded: true, historyType: 'NoneWithoutConversion' } // … Migração concluída ================== Projetos migrados: 51 Projetos com falha: 0 Concluído. ``` Se a migração for bem-sucedida, obterá um código de saída de `0`, e as últimas linhas indicam que não houve falhas: ```bash Projetos com falha: 0 Concluído. ``` Pode reabrir o acesso para os seus utilizadores (veja o próximo passo). Se houver falhas, consulte a secção de resolução de problemas abaixo. Ainda pode reabrir o site se os problemas não forem resolvidos imediatamente, e os projetos não migrados permanecerão no sistema de histórico legado. {% endstep %} {% step %} #### Reabrir o site Se tiver escolhido realizar uma migração offline, então terá de reabrir o site. Se ainda tiver sessão iniciada, terá de: 1. Clique no **Administração** botão e escolha **Gerir site** 2. Clique no **Abrir/Fechar editor** separador 3. Clique no **Reabrir editor** botão Se tiver fechado o seu navegador, então terá de reiniciar o site com `$ bin/up`. {% endstep %} {% endstepper %} #### migração offline Para impedir que os utilizadores consigam iniciar sessão enquanto o script de migração do histórico está em execução, siga estes passos: * Inicie sessão na sua instância Overleaf com uma conta de administrador * Clique no **Administração** botão e escolha **Gerir site** * Clique no **Abrir/Fechar editor** separador * Clique no **Fechar editor** botão * Clique no **Desligar todos os utilizadores** botão Depois de isto ser feito, se houver utilizadores com sessão iniciada, estes serão redirecionados para a página de manutenção, e quaisquer novos utilizadores que visitem a página de início de sessão verão a página de manutenção e **não** conseguirão iniciar sessão. #### Migração online É possível executar os scripts de migração enquanto a aplicação ainda está em execução. Há algumas considerações a ter em conta: * O processo de migração é intensivo em CPU; deverá monitorizar a utilização de recursos enquanto o script estiver em execução. * Com um `--concurrency` elevado, o event loop em alguns serviços (`track-changes` em particular) poderá sofrer algum bloqueio, o que levaria a uma experiência de utilizador degradada. Recomendamos começar com o valor predefinido `--concurrency=1` . * Pode parar o script a qualquer momento. Iniciá-lo novamente retomará a migração no ponto em que ficou. Isto é útil caso prefira executar a migração em horas de menor movimento (por exemplo, à noite). A nossa recomendação é fechar o site e executar a migração offline numa janela de manutenção quando a sua contagem de projetos for inferior a 1000 projetos (`db.projects.count()`). Se o número de projetos for grande, pode executar o script e monitorizar o progresso; depois decidir se continua a executá-lo online ou offline, com base no seu caso específico. #### Limpar dados do histórico legado Foi adicionado no Server Pro um script para limpar os dados do histórico legado `3.5.6`, `4.0.6` e `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 %} O script pode ser executado depois de todos os projetos terem sido migrados. Também pode ser usado para libertar algum espaço durante uma migração online. {% hint style="info" %} No Server Pro antes da versão 3.5.13, o script apaga o conteúdo de `docHistory` e `docHistoryIndex` das coleções. O MongoDB não liberta espaço em disco depois de apagar documentos; em vez disso, reutilizará esse espaço para documentos futuros na mesma coleção. Nada voltará a escrever nestas coleções após a migração do histórico, pelo que o espaço em disco permanecerá por usar. Se quiser disponibilizar novamente o espaço em disco, pode atualizar para o Server Pro 3.5.13 (ainda usando a versão 3.x) ou Server Pro 4.2.5 (usando a versão 4.x) e voltar a executar o script de limpeza. O script de limpeza, tal como incluído no Server Pro nas versões de patch mais recentes de `3.5.x` e na versão mais recente `4.x.x` elimina as coleções como etapa final. É seguro voltar a executar o script de limpeza. {% endhint %} ### Resolução de problemas Adicionaremos aqui conselhos de resolução de problemas. Note que, embora normalmente ofereçamos suporte apenas a clientes do Server Pro, dada a natureza desta migração, também faremos o nosso melhor para apoiar clientes CE que tenham problemas específicos da migração do histórico completo do projeto. Se o script de migração do histórico completo do projeto falhar (isto é, terminar com um erro ou imprimir um número não nulo de projetos com falha), envie os seguintes detalhes por email à nossa equipa de suporte [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), detalhando: Assunto: Problema na migração do histórico completo do projeto * Tipo de instância: CE ou Server Pro (apagar conforme apropriado) * Tipo de instalação: Overleaf toolkit ou `docker-compose.yml` ou outro (apagar conforme apropriado) * Versão: 3.5.x (toolkit: `$ cat config/version`) * Saída do script de migração (que deve estar localizada no contentor em `/overleaf/services/web`) * Projetos migrados: (conforme a saída do script de migração) * Total de projetos: (conforme a saída do script de migração) * Projetos restantes: (conforme a saída do script de migração) * Duração da migração: * `bin/doctor` saída (ao usar o toolkit) * Versão do toolkit: `$ git rev-parse HEAD` (ao usar o Toolkit) Considere anexar os ficheiros de registo dos `history-v1`, `project-history` e `track-changes` serviços ao email. Pode encontrá-los em `/var/log/sharelatex` dentro do `sharelatex` contentor e exportá-los assim: ```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 ``` Remova qualquer informação sensível dos ficheiros de registo antes de os anexar. #### Encontrar árvores de ficheiros corrompidas A migração pode falhar para projetos que tenham uma árvore de ficheiros malformada (por exemplo, onde os nomes dos ficheiros estejam vazios). Pode encontrar uma lista destes problemas usando o `find_malformed_filetrees` script que verifica todos os projetos na base de dados: {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/find_malformed_filetrees.js" CAMINHO INVÁLIDO: 123456789012345678901234 rootFolder.0.1.2.3 CAMINHO INVÁLIDO: 123456789012345678901234 rootFolder.0.4.5.6 ... ``` {% endcode %} Para corrigir os caminhos inválidos, use o `fix_malformed_filetree` script, executando o comando uma vez para cada caminho inválido: {% 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 %} #### Fazer downgrade dos projetos de histórico completo do projeto para histórico legado Se houver um projeto que tenha sido migrado para o histórico completo do projeto, mas quiser voltar ao histórico legado, use o `downgrade_project` script da seguinte forma: {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; PROJECT_ID=SEU ``` {% 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/pt/suporte/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.