Skip to main content

Migrace binárních souborů

Nadcházející hlavní verze 6.0 Server Pro a Community Edition sníží využití úložiště binárními soubory na polovinu. Ve verzi 5.5.7 je zahrnuta online migrace, která umožňuje minimální výpadek během upgradu. Od Server Pro 4.x jsou binární soubory ukládány dvakrát: v úložišti aktivních souborů ve „filestore“ a v systému úplné historie projektů. Nadále bude každý soubor uložen jen v jedné kopii v systému úplné historie projektů. Migrace na sjednocený úložný systém se skládá ze dvou částí: nového příznaku pro řízení fáze migrace a skriptu, který zpracuje všechny aktivní a měkce smazané projekty. Fáze:
  • OVERLEAF_FILESTORE_MIGRATION_LEVEL=0 (výchozí): soubory se čtou z filestore a zapisují do něj. Do historie se soubory zapisují asynchronně.
  • OVERLEAF_FILESTORE_MIGRATION_LEVEL=1 : soubory se čtou z historie se záložním čtením z filestore a zapisují se do filestore i do historie. Návrat na OVERLEAF_FILESTORE_MIGRATION_LEVEL=0 je možný.
  • OVERLEAF_FILESTORE_MIGRATION_LEVEL=2: soubory se čtou a zapisují pouze do historie. Návrat na OVERLEAF_FILESTORE_MIGRATION_LEVEL=1 není možný, pokud migrace neproběhla „offline“.
Pokud ukládáte data v S3 a používáte samostatné servisní účty pro filestore (OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID) a historii (OVERLEAF_HISTORY_S3_ACCESS_KEY_ID): Udělte prosím uživateli filestore přístup pro čtení k bucketu historie pro bloby OVERLEAF_HISTORY_PROJECT_BLOBS_BUCKET . Služba filestore bude nadále obsluhovat čtení pro službu kompilátoru.
Důrazně doporučujeme provést migraci binárních souborů nejprve v neprodukčním/testovacím prostředí.
Standardní licence Server Pro vám umožňuje provozovat aplikaci v produkčním prostředí a také v jednom neprodukčním/testovacím prostředí; důrazně doporučujeme zřídit si pro testování neprodukční prostředí.
Pokud upgradujete na Server Pro/CE verze 6.0 a později se rozhodnete vrátit k dřívější verzi, měli byste obnovit data z úplné zálohy systému.

Postup migrace

1

Vytvoření zálohy

Vytvořte úplnou zálohu své instance s konzistentním snímkem adresářů mongo, redis a sharelatex.
2

Aktualizace

Toolkit: Pomocí skriptu $ bin/upgrade aktualizujte toolkit na nejnovější verzi. Až budete dotázáni, výzvu Upgrade image? nepotvrzujte — místo toho ručně upravte soubor config/version a nastavte hodnotu na 5.5.7.Starší docker-compose.yml: Aktualizujte verzi služby sharelatex na 5.5.7.
3

Odhad počtu dotčených projektů

Příklad výstupu:
4

Vyprázdnění front historie projektů

Vyprazdňování opakujte, dokud nebudou vyprázdněny všechny projekty ("project_ids":0).
Pokud „failedProjects“ není nula, obraťte se prosím na podporu a v migraci binárních souborů nepokračujte.
5

Posunutí fáze migrace na 1

Toolkit: Nastavte OVERLEAF_FILESTORE_MIGRATION_LEVEL=1 v config/variables.env.Starší docker-compose.yml: Nastavte OVERLEAF_FILESTORE_MIGRATION_LEVEL: '1' v sekci environment služby sharelatex.
6

Použití změny konfigurace a spuštění instance

Toolkit: bin/up -dStarší docker-compose.yml: docker compose up -d
7

Ověření přístupu k binárním souborům

Otevřete projekt v editoru Overleafu v prohlížeči a vyberte binární soubor, například obrázek.
8

Spuštění migračního skriptu

Pokud ukládáte logy mimo kontejner sharelatex, ujistěte se, že vlastníkem adresáře logů je uživatel www-data (uid=33), aby bylo možné vytvořený soubor logu zapsat.
Výstup by měl vypadat takto:
Pokud je migrace úspěšná, dostanete návratový kód 0 a poslední řádky nebudou uvádět žádná selhání:
Soubor logu bude vypadat takto (použijte cestu, kterou vypsal skript):
9

Zastavení instance

Toolkit: bin/stop sharelatexStarší docker-compose.yml: docker compose stop sharelatex
10

Znepřístupnění starých souborů aplikaci

Nyní můžete staré soubory přesunout na sekundární úložiště. Doporučujeme soubory ještě nějakou dobu ponechat pro případ, že by se později objevily problémy.
11

Posunutí fáze migrace na 2

Toolkit: Nastavte OVERLEAF_FILESTORE_MIGRATION_LEVEL=2 v config/variables.env.Starší docker-compose.yml: Nastavte OVERLEAF_FILESTORE_MIGRATION_LEVEL: '2' v sekci environment služby sharelatex.
12

Použití změny konfigurace a spuštění instance

Toolkit: bin/up -dStarší docker-compose.yml: docker compose up -d
13

Ověření přístupu k binárním souborům

Otevřete projekt v editoru Overleafu v prohlížeči a vyberte binární soubor, například obrázek.

Offline migrace

Pokud chcete uživatelům zabránit v přihlášení, dokud běží skript migrace binárních souborů, postupujte podle těchto kroků:
  • Přihlaste se do své instance Overleafu administrátorským účtem
  • Klikněte na tlačítko Admin a zvolte Manage Site
  • Klikněte na záložku Open/Close Editor
  • Klikněte na tlačítko Close Editor
  • Klikněte na tlačítko Disconnect all users
Poté budou všichni přihlášení uživatelé přesměrováni na stránku údržby a noví uživatelé, kteří navštíví přihlašovací stránku, uvidí stránku údržby a nebudou se moci přihlásit. Tyto kroky je nutné zopakovat při restartu instance. Pro opětovné otevření webu stačí instanci restartovat.

Online migrace

Migrační skripty je možné spustit i za běhu aplikace. Je třeba vzít v úvahu několik aspektů:
  • Proces migrace je náročný na I/O, proto byste měli během běhu skriptu sledovat využití prostředků.
  • Při vysoké souběžnosti zpracování může v event loopu služby filestore docházet k blokování, což by zhoršilo uživatelský zážitek. Doporučujeme začít s výchozími hodnotami --concurrency=10 a --concurrent-batches=1 .
  • Skript můžete kdykoli zastavit. Po opětovném spuštění ověří předchozí projekty a přeskočí již zpracované soubory. To se hodí, pokud dáváte přednost spuštění migrace v méně vytížených hodinách (např. v noci).
Doporučujeme uzavřít web a spustit migraci offline v okně údržby, pokud máte méně než 1000 projektů (viz výstup migračního skriptu při spuštění s --report). Pokud je projektů mnoho, můžete skript spustit, sledovat jeho průběh a podle konkrétní situace se rozhodnout, zda v něm pokračovat online, nebo offline.

Vyčištění starých dat binárních souborů

Jakmile migraci dokončíte a ověříte, že projekty mají stále přístup ke všem svým souborům, můžete odstranit staré úložiště souborů v /var/lib/overleaf/data/user_files. Důrazně doporučujeme tyto soubory ještě nějakou dobu ponechat — nejprve je můžete aplikaci znepřístupnit přejmenováním složky.

Řešení problémů

Rady k řešení problémů budeme doplňovat sem. Upozorňujeme, že ačkoli běžně poskytujeme podporu pouze zákazníkům Server Pro, vzhledem k povaze této migrace se budeme snažit pomoci i zákazníkům CE, kteří narazí na problémy specifické pro migraci binárních souborů. Pokud skript migrace binárních souborů selže (tj. skončí chybou nebo vypíše nenulový počet neúspěšných projektů), pošlete prosím našemu týmu podpory e-mail na support+filestoremigration@overleaf.com s těmito údaji: Předmět: Binary file migration problem Text:
  • Typ instance: CE nebo Server Pro (nehodící se škrtněte)
  • Typ instalace: Overleaf toolkit nebo docker-compose.yml nebo jiný (nehodící se škrtněte)
  • Verze: 5.5.x (toolkit: $ cat config/version)
  • Výstup migračního skriptu (měl by být v kontejneru v /var/log/overleaf)
  • Report: (spusťte migrační skript s --report)
  • Zpracované projekty: (podle posledního běhu skriptu)
  • Doba trvání migrace:
  • Výstup bin/doctor (při použití toolkitu)
  • Verze toolkitu: $ git rev-parse HEAD (při použití Toolkitu)
Zvažte připojení souborů logu služby filestore k e-mailu. Najdete je v /var/log/overleaf/filestore.log uvnitř kontejneru sharelatex a exportovat je můžete takto:
Před připojením prosím z logů odstraňte veškeré citlivé informace.

Chybějící soubory

Starší verze Server Pro/CE vytvářely položky stromu souborů ještě před dokončením nahrávání uživatelem, což mohlo vést k tomu, že se při neúspěšném nahrání soubory jevily jako chybějící. Několik takových případů můžete najít nahlášených jako chyby při zpracování všech stromů souborů. Pokud je chybějících souborů málo, zvažte ruční kontrolu těchto případů a jejich smazání v editoru v prohlížeči. Pokud je chybějících souborů mnoho, zvažte kontaktování podpory, viz šablona e-mailu výše.

Hledání poškozených stromů souborů

Migrace může selhat u projektů s chybně utvořeným stromem souborů (například s prázdnými názvy souborů). Seznam těchto problémů zjistíte pomocí skriptu find_malformed_filetrees, který zkontroluje všechny projekty v databázi:
Chcete-li neplatné cesty opravit, použijte skript fix_malformed_filetree a spusťte příkaz jednou pro každou chybnou cestu:
Naposledy změněno 5. října 2026