> 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/es/soporte/support-guides/doc-version-recovery.md). # (Migración v5.0.1) Recuperación de la versión del documento {% hint style="info" %} Si nunca ejecutaste Server Pro versión 5.0.1 o Community Edition versión 5.0.1, o si iniciaste una instancia completamente nueva con 5.0.1, no necesitas ejecutar este proceso de recuperación. {% endhint %} **Actualizaciones de esta página:** * (2024-04-22 13:40 BST): Se añadió el paso "Detener la entrada de nuevas actualizaciones al sistema y volcar todos los cambios a MongoDB". * (2024-04-23 11:45 BST): Tener en cuenta los vaciados fallidos en 5.0.1 y omitir los vaciados cuando se inició 5.0.2. La duración de la recuperación dependerá del número y el tamaño de los proyectos en tu instancia y del backend de almacenamiento utilizado por el almacén de historial para los fragmentos (como se define en `OVERLEAF_HISTORY_CHUNKS_BUCKET`). El proceso de recuperación retrasará el inicio de la aplicación dentro del contenedor de Server Pro. El sitio aparecerá fuera de línea durante ese tiempo. Solo admitimos ejecutar la recuperación desde una única instancia del contenedor de Server Pro; todos los demás workers de escalado horizontal deben estar desconectados. Puedes detener y reanudar el proceso de recuperación si es necesario. Según nuestras pruebas de rendimiento, el proceso de recuperación puede procesar aproximadamente 10 mil proyectos pequeños por minuto en hardware moderno (frecuencia de CPU de 3 GHz y almacenamiento NVMe local). Como ejemplo, para una instancia con 100 mil proyectos, programa una ventana de mantenimiento que permita al menos 10+2 min de inactividad. Usa la siguiente consulta para estimar el número de proyectos en tu instancia: {% code overflow="wrap" %} ```bash $ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()' ``` {% endcode %} Por favor, lee por completo los siguientes pasos de recuperación antes de empezar. Los clientes de Server Pro pueden ponerse en contacto con si tienen alguna pregunta. ### Proceso de recuperación {% stepper %} {% step %} #### Descargar las imágenes de la versión Descarga las `5.0.3` imágenes de la versión. {% endstep %} {% step %} #### Identifica algunos proyectos Identifica algunos proyectos por ID que no tengan historial; idealmente, tienes permiso para hacer un cambio en uno de ellos. {% endstep %} {% step %} #### Programar mantenimiento Programa una ventana de mantenimiento para el tiempo de inactividad. {% endstep %} {% step %} #### Detener todos los workers excepto uno Detén todos los workers excepto uno cuando uses una configuración de escalado horizontal. {% endstep %} {% step %} #### Detener nuevas actualizaciones y volcar todos los cambios a MongoDB Detén la entrada de nuevas actualizaciones al sistema y volca todos los cambios a MongoDB: 1. Cierra el editor y desconecta manualmente a todos los usuarios a través del panel de administración en `https://my-server-pro.example.com/admin#open-close-editor` en la pestaña "Open/Close Editor". 2. Detén el servicio WebSocket/tiempo real. ```bash $ docker exec sharelatex sv stop real-time-overleaf ``` 3. Espera a que el servicio de tiempo real se cierre, como se indica en `inactivo:`. ```bash $ docker exec sharelatex sv status real-time-overleaf run: real-time-sharelatex: (pid 394) 50s, se esperaba inactivo, recibió TERM # espera un poco más... $ docker exec sharelatex sv status real-time-overleaf inactivo: real-time-sharelatex: 7s, normalmente activo ``` 4. Detén el contenedor git-bridge si está habilitado. ```bash $ docker stop git-bridge ``` 5. Si nunca ejecutaste 5.0.2: inicia un vaciado manual de las actualizaciones de documentos y espera a que finalice correctamente. Puedes repetir el comando si hay un error. En caso de que veas un `failureCount` en ejecuciones sucesivas, por favor detén la migración (restaura los servicios mediante `docker restart git-bridge sharelatex`) y ponte en contacto con soporte. 
$ 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":"terminó de vaciar todos los proyectos","time":"...","v":0}
   Vaciado de todos los proyectos completado
6. Si nunca ejecutaste 5.0.2: asegúrate de que todos los cambios se hayan vaciado de Redis. Si obtienes alguna salida de `redis-cli`, por favor detén la migración (restaura los servicios mediante `docker restart git-bridge sharelatex`) y ponte en contacto con soporte. 
$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # no tener salida de redis-cli indica éxito; a continuación, comprueba el código de salida de redis-cli, debería ser cero
   $ echo $?
   0
7. Intenta vaciar cualquier cambio de historial pendiente. Esto tendrá que ser un vaciado de mejor esfuerzo, ya que algunos proyectos tienen historiales dañados debido a la mala migración de la base de datos. Cualquier fallo se abordará con una resincronización del historial al final del proceso de recuperación. 
$ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /
{% endstep %} {% step %} #### Haz una copia de seguridad Considera hacer [copia de seguridad coherente](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) una copia de seguridad de la instancia. {% endstep %} {% step %} #### Actualizar Actualizar a la versión `5.0.3`. {% endstep %} {% step %} #### Recuperación automática El proceso de recuperación se ejecuta automáticamente al iniciar el contenedor. {% endstep %} {% step %} #### Seguir el progreso Puedes seguir el progreso del script consultando el archivo de registro `/var/lib/overleaf/data/history/doc-version-recovery.log`. Imprimirá el número total de proyectos al inicio y un resumen después de cada 1000 proyectos procesados. {% code overflow="wrap" %} ```bash $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers ``` {% endcode %} {% endstep %} {% step %} #### Espera a que finalice el proceso de recuperación Espera a que finalice el proceso de recuperación consultando el archivo de registro anterior hasta que se `Terminado.` haya impreso una línea o esperando a `Finalizó la recuperación de las versiones de documentos.` que se imprima en la salida estándar del contenedor de Server Pro. {% endstep %} {% step %} #### Validar el proceso de recuperación Valida el proceso de recuperación abriendo el panel de historial de algunos de los proyectos que antes no tenían historial. 1. Acelera la resincronización de los proyectos de prueba (se procesarán eventualmente, pero no queremos esperar a que les llegue su turno.) 
$ docker exec sharelatex curl -X POST --silent "http://127.0.0.1:3054/project/000000000000000000000000/resync?force=true"
(Repite con cada uno de los IDs de proyecto a probar, sustituye `000000000000000000000000` con un ID de proyecto a la vez.) 2. Abre el editor de proyectos para los proyectos `https://my-server-pro.example.com/project/000000000000000000000000` 3. Abre el panel "History" del proyecto y comprueba el contenido más reciente. 4. Opcional: cierra de nuevo el panel "History". Haz un cambio en el código, como añadir un comentario al encabezado. 5. Opcional: ejecuta una recompilación para desencadenar un vaciado del cambio local. Abre de nuevo el panel "History" y comprueba el cambio. Cuando termines, deshaz el cambio. {% endstep %} {% step %} #### Para el escalado horizontal... Inicia de nuevo los demás workers. {% endstep %} {% step %} #### Mantén la instancia en ejecución Por favor, mantén en ejecución la instancia que ejecutó el proceso de recuperación. Resincronizará el historial de todos los proyectos en segundo plano con una concurrencia de 1. Esto provocará una carga base ligeramente mayor. (Puedes reiniciar la instancia, pero tendrá que volver a empezar con las resincronizaciones.) {% endstep %} {% step %} #### Avísanos cuando hayas terminado Clientes de Server Pro: por favor, avisen al equipo de soporte cuando hayan completado el proceso de recuperación. {% endstep %} {% endstepper %} --- # 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/es/soporte/support-guides/doc-version-recovery.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.