(Migrasi v5.0.1) Pemulihan versi dokumen

Jika Anda tidak pernah menjalankan Server Pro versi 5.0.1 atau Community Edition versi 5.0.1, atau Anda memulai instans yang benar-benar baru dengan 5.0.1, Anda tidak perlu menjalankan proses pemulihan ini.

• (2024-04-22 13:40 BST): Menambahkan langkah “Hentikan pembaruan baru agar tidak masuk ke sistem dan flush semua perubahan ke MongoDB”.
• (2024-04-23 11:45 BST): Memperhitungkan flush yang rusak di 5.0.1 dan melewati flush jika 5.0.2 pernah dijalankan.

Durasi pemulihan akan bergantung pada jumlah dan ukuran proyek di instans Anda serta backend penyimpanan yang digunakan oleh history store untuk chunk (sebagaimana didefinisikan di OVERLEAF_HISTORY_CHUNKS_BUCKET).

Proses pemulihan akan menunda start aplikasi di dalam kontainer Server Pro. Situs akan tampak offline selama waktu tersebut. Kami hanya mendukung menjalankan pemulihan dari satu instans kontainer Server Pro; semua worker horizontal scaling lainnya harus dalam keadaan offline.

Anda dapat menghentikan dan melanjutkan proses pemulihan jika diperlukan.

Berdasarkan uji performa kami, proses pemulihan dapat memproses sekitar 10 ribu proyek kecil per menit pada perangkat keras modern (kecepatan clock CPU 3GHz dan penyimpanan NVMe lokal). Sebagai contoh, untuk instans dengan 100 ribu proyek, jadwalkan jendela pemeliharaan yang memungkinkan downtime setidaknya 10+2 menit. Gunakan kueri berikut untuk memperkirakan jumlah proyek di instans Anda:

$ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()'

Harap baca langkah-langkah pemulihan berikut secara lengkap sebelum Anda memulai. Pelanggan Server Pro dipersilakan menghubungi [e-mail] jika ada pertanyaan.

​

Proses pemulihan

1. Tarik image rilis

   Tarik image rilis 5.0.3.

2. Identifikasi beberapa proyek

   Identifikasi beberapa proyek berdasarkan id yang kehilangan riwayat; idealnya Anda memiliki izin untuk melakukan perubahan pada salah satunya.

3. Jadwalkan pemeliharaan

   Jadwalkan jendela pemeliharaan untuk downtime.

4. Hentikan semua worker kecuali satu

   Hentikan semua worker kecuali satu jika menggunakan penyiapan horizontal scaling.

5. Hentikan pembaruan baru dan flush semua perubahan ke MongoDB

   Hentikan pembaruan baru agar tidak masuk ke sistem dan flush semua perubahan ke MongoDB:

   1. Tutup editor dan putuskan koneksi semua pengguna secara manual melalui panel admin di https://my-server-pro.example.com/admin#open-close-editor pada tab “Open/Close Editor”.

   2. Hentikan layanan Websocket/real-time.

      $ docker exec sharelatex sv stop real-time-overleaf
      

   3. Tunggu hingga layanan real-time berhenti, yang ditandai dengan 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. Hentikan kontainer git-bridge jika diaktifkan.

      $ docker stop git-bridge
      

   5. Jika Anda tidak pernah menjalankan 5.0.2: Lakukan flush manual untuk pembaruan dokumen dan tunggu hingga selesai dengan sukses.

      Anda dapat mengulangi perintah jika terjadi error. Jika Anda melihat failureCount yang tidak nol pada beberapa kali percobaan berturut-turut, harap hentikan migrasi (pulihkan layanan melalui docker restart git-bridge sharelatex) dan hubungi dukungan.

      $ 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. Jika Anda tidak pernah menjalankan 5.0.2: Pastikan semua perubahan telah di-flush dari redis.

      Jika Anda mendapatkan output apa pun dari redis-cli, harap hentikan migrasi (pulihkan layanan melalui docker restart git-bridge sharelatex) dan hubungi dukungan.

      $ 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. Coba flush semua perubahan riwayat yang tertunda.

      Flush ini bersifat upaya terbaik (best effort) karena beberapa proyek memiliki riwayat yang rusak akibat migrasi database yang buruk. Setiap kegagalan akan ditangani dengan sinkronisasi ulang riwayat di akhir proses pemulihan.

      $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /
          
      
6. Buat backup

   Pertimbangkan untuk membuat backup yang konsisten dari instans.

7. Upgrade

   Upgrade ke versi 5.0.3.

8. Pemulihan otomatis

   Proses pemulihan berjalan secara otomatis saat kontainer dimulai.

9. Pantau progres

   Anda dapat memantau progres skrip dengan melakukan tail pada file log /var/lib/overleaf/data/history/doc-version-recovery.log. Skrip akan mencetak jumlah total proyek di awal dan ringkasan setiap kali 1000 proyek selesai diproses.

   $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers
   
10. Tunggu hingga proses pemulihan selesai

    Tunggu hingga proses pemulihan selesai, baik dengan melakukan tail pada file log di atas hingga baris Done. dicetak, atau dengan menunggu hingga Finished recovery of doc versions. dicetak ke standard output kontainer Server Pro.

11. Validasi proses pemulihan

    Validasi proses pemulihan dengan membuka panel riwayat untuk beberapa proyek yang sebelumnya kehilangan riwayat.

    1. Percepat resync untuk proyek yang akan diuji (Proyek-proyek tersebut pada akhirnya akan diproses, tetapi kita tidak ingin menunggu gilirannya.)

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

       (Ulangi untuk setiap project-id yang akan diuji, ganti 000000000000000000000000 dengan satu project-id setiap kali.)

    2. Buka editor proyek untuk proyek tersebut https://my-server-pro.example.com/project/000000000000000000000000

    3. Buka panel “History” untuk proyek tersebut dan lihat konten terbaru.

    4. Opsional: Tutup kembali panel “History”. Lakukan perubahan kode, misalnya menambahkan komentar pada header.

    5. Opsional: Lakukan kompilasi ulang untuk memicu flush perubahan lokal. Buka kembali panel “History” dan lihat perubahannya. Setelah selesai, batalkan perubahan tersebut.

12. Untuk horizontal scaling...

    Jalankan kembali worker lainnya.

13. Biarkan instans tetap berjalan

    Harap biarkan instans yang menjalankan proses pemulihan tetap berjalan. Instans ini akan melakukan resync riwayat untuk semua proyek di latar belakang dengan konkurensi 1. Hal ini akan menyebabkan beban dasar sedikit meningkat. (Anda dapat memulai ulang instans, tetapi proses resync harus dimulai dari awal lagi.)

14. Beri tahu kami setelah selesai

    Pelanggan Server Pro: Harap beri tahu tim dukungan setelah Anda menyelesaikan proses pemulihan.