---
title: "Pracovní proces spadl. Synchronizace ne."
description: "Ukončete pracovní proces uprostřed dávky a sledujte jeden kontakt: který kurzor se uložil, proč se opakovaný zápis neprovede dvakrát a komu synchronizace patří během restartu. A pak dva incidenty, které ukázaly, že obnova je jen polovina práce."
url: https://tajo.io/cz/blog/worker-died-sync-didnt/
markdown: https://tajo.io/cz/blog/worker-died-sync-didnt.md
lang: cs-CZ
author: "Set Noa"
author_url: https://tajo.io/cz/set-noa/
published: 2026-11-05
updated: 2026-11-05
alternates: {en-US: /blog/worker-died-sync-didnt.md, bg-BG: /bg/blog/worker-died-sync-didnt.md, de-DE: /de/blog/worker-died-sync-didnt.md, da-DK: /dk/blog/worker-died-sync-didnt.md, es-ES: /es/blog/worker-died-sync-didnt.md, fr-FR: /fr/blog/worker-died-sync-didnt.md, el-GR: /gr/blog/worker-died-sync-didnt.md, hi-IN: /hi/blog/worker-died-sync-didnt.md, id-ID: /in/blog/worker-died-sync-didnt.md, hr-HR: /hr/blog/worker-died-sync-didnt.md, hu-HU: /hu/blog/worker-died-sync-didnt.md, it-IT: /it/blog/worker-died-sync-didnt.md, ja-JP: /jp/blog/worker-died-sync-didnt.md, ko-KR: /kr/blog/worker-died-sync-didnt.md, ar-SA: /ar/blog/worker-died-sync-didnt.md, nl-NL: /nl/blog/worker-died-sync-didnt.md, no-NO: /no/blog/worker-died-sync-didnt.md, pl-PL: /pl/blog/worker-died-sync-didnt.md, pt-BR: /pt/blog/worker-died-sync-didnt.md, ro-RO: /ro/blog/worker-died-sync-didnt.md, ru-RU: /ru/blog/worker-died-sync-didnt.md, sv-SE: /se/blog/worker-died-sync-didnt.md, zh-CN: /zh-cn/blog/worker-died-sync-didnt.md, sl-SI: /sl/blog/worker-died-sync-didnt.md, sr-Latn-RS: /sr/blog/worker-died-sync-didnt.md, th-TH: /th/blog/worker-died-sync-didnt.md, tr-TR: /tr/blog/worker-died-sync-didnt.md, ur-PK: /ur/blog/worker-died-sync-didnt.md, vi-VN: /vi/blog/worker-died-sync-didnt.md, sk-SK: /sk/blog/worker-died-sync-didnt.md}
---

[Synchronizace dat](https://tajo.io/cz/blog/?category=data-sync)

# Pracovní proces spadl. Synchronizace ne.

Ukončete pracovní proces uprostřed dávky a sledujte jeden kontakt: který kurzor se uložil, proč se opakovaný zápis neprovede dvakrát a komu synchronizace patří během restartu. A pak dva incidenty, které ukázaly, že obnova je jen polovina práce.

obnova synchronizace po výpadku

Co se stane s běžící synchronizací, když pracovní proces spadne uprostřed dávky?

Kurzor se posune až na konci čisté dávky, takže pracovní proces ukončený uprostřed dávky ho nechá na jejím začátku a další běh načte stejnou stránku. Doručovací klíč každého záznamu se odvozuje z kurzoru stránky a jeho pozice a sedmidenní registr dokončených zápisů zajistí, že se opakování nezapíše dvakrát. Jeden dočasný zámek na synchronizaci brání tomu, aby dva běhy pracovaly současně. To byla ta snadná polovina. Jedna synchronizace selhávala běh za během, než ji cokoli pozastavilo, a jeden pracovní prostor zůstal tichý, s chybami a bez jediného úspěchu, než si toho cokoli všimlo. Proto teď existuje jistič, který po pěti po sobě jdoucích selháních synchronizaci pozastaví, a hodinová kontrola, která upozorní po dvaceti čtyřech hodinách bez úspěchu.

[Zjistit více](https://tajo.io/cz/blog/worker-died-sync-didnt/#sledujte-jeden-kontakt)

V [přednášce, kterou 3. října 2026 zveřejnil AI Engineer](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=701s), spouští specialista na vztahy s vývojáři ze společnosti Crusoe tréninkovou úlohu PyTorch na dvou uzlech A100. Pak oznámí vlastnímu monitorovacímu systému ukázky, že jedna GPU vyhodila chybu XID 79. Uzel je označen jako nedostupný a úloha zrušena. Proces dostane SIGTERM a „[až dvě minuty na zpracování toho SIGTERM, abyste uložili kontrolní body nebo vyprázdnili logy](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=633s)“. Nastoupí náhradní uzel a „[úloha slurm se restartuje. Načte kontrolní bod a bude pokračovat v tréninku tam, kde skončila](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=769s)“. Celé to trvá necelých patnáct minut. Nikoho nebylo potřeba volat na pohotovost.

Synchronizace je mnohem menší zvíře než tréninkový běh. Otázka je ale stejná. Co běh potřebuje, aby ukončení pracovního procesu stálo minuty a žádné duplicity?

Tady je odpověď pro [vlastní synchronizační systém Tajo](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/), vyčtená z kódu, ne z brožury. [Reverse ETL](https://tajo.io/cz/blog/what-is-reverse-etl/) popisuje tvar té práce. Tento článek popisuje, co se stane, když ta práce zemře.

## Sledujte jeden kontakt

Běh čte zdroj stránku po stránce od uloženého kurzoru. Kurzor stránky nazvěme `c3` a náš kontakt 212. záznamem na této stránce. Než se cokoli zapíše, platí o tomto kontaktu tři věci.

Zaprvé má doručovací klíč. Klíč je hash identifikátoru synchronizace, zdroje, kurzoru stránky, pozice na stránce a samotného záznamu. Kurzor a záznam vstupují do hashe a nikdy nejsou do klíče vloženy, takže klíč nenese [žádnou e-mailovou adresu](https://tajo.io/cz/resources/help/getting-started/understanding-data-sync/).

Zadruhé zápis jde přes [registr](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger), ne přímo do cíle. Než se cíl zavolá, klíč se zabere ve stavu čekající. Když zápis uspěje, řádek se označí jako dokončený a uchová se po dobu sedmi dnů.

Zatřetí se kurzor neposunul. Posouvá se jen na konci dávky, jen pokud dorazil každý záznam v této dávce, a jen poté, co běh prokázal, že synchronizaci stále vlastní.

Teď ukončete pracovní proces mezi zápisem a kontrolním bodem.

Po SIGTERM každý pracovní proces fronty dokončuje rozpracované úlohy v rámci jednoho společného patnáctisekundového limitu a proces skončí po dvaceti pěti sekundách bez ohledu na to, co ještě běží; systemd mu dá čtyřicet pět, než ho ukončí násilím. Běh, který v tomto okně neskončil, je stále označen jako probíhající a další pracovní proces ho převezme díky obnově zaseknutých úloh ve frontě. Při tvrdém ukončení žádné dokončování není. Tak či onak platí stejná dvě fakta. Cíl má náš kontakt. Náš [kurzor](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#cursor) stále ukazuje `c3`.

## Opakování

Další běh začne na `c3`, načte stejnou stránku, odvodí pro 212. záznam stejný klíč a zeptá se registru. Registr odpoví: dokončeno. Cíl se nevolá; uložený výsledek se přehraje a běh pokračuje dál. Na hromadné cestě, kde importní endpoint Brevo přijímá celou stránku v jednom volání, proběhne stejná kontrola pro každý klíč ještě před sestavením požadavku. Stránka, ve které je každý klíč již dokončený, neodešle nic.

V tom je celý trik a stojí za to říct, proč funguje. Klíč se odvozuje z kurzoru stránky na začátku dávky, ne z běhu, který se zrovna prováděl. Pád, opakovaný pokus o šedesát sekund později i plánovaný běh zítra [odvodí pro stejný záznam stejný klíč](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger). Registru je jedno, který z nich se ptá.

Teď cena. [Registr po sedmi dnech zapomíná](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger). Komentář v kódu říká, že sedm dní pokryje opožděný opakovaný pokus a krátký výpadek, a nic víc netvrdí. Opakování od kurzoru staršího než sedm dní zapisuje znovu. A běh, který byl přerušen tvrdě, může čekat. Dočasný zámek mrtvého běhu platí až patnáct minut a u plánované synchronizace se běh, jehož zámek je volný, [uklidí a znovu naplánuje až tehdy, když začal před více než hodinou](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#stuck-runs). Ukázka Crusoe [je zpět za méně než patnáct minut](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=753s). Ta naše ne vždy.

## Komu patří synchronizace během restartu

Synchronizaci vlastní v daném okamžiku jeden běh. Běh si v Redis vezme [dočasný zámek](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#lease) s vlastním tokenem, patnáctiminutovou platností a obnovou každých pět minut. Před každým kontrolním bodem ověří, že zámek stále drží. Pokud ne, zastaví se. Běh se zaznamená [prostou větou, kterou si člověk přečte](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures): „The run lost its slot part-way through and stopped to avoid writing twice.“ (Běh v průběhu ztratil svůj slot a zastavil se, aby nezapisoval dvakrát.) Druhý běh, který narazí na živého vlastníka, se neopakuje. [Skončí zprávou](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures) „Another run of this sync was already in progress“ (jiný běh této synchronizace již probíhal) a další plánovaný běh začne normálně.

Kdo opravu vlastní, je také zapsáno. Každý [kód selhání](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures) odpovídá jedné větě o tom, co se stalo, jedné o tom, co udělat dál, a vlastníkovi: Vy, nebo Tajo. Cíl, který odmítl každý záznam, protože je mapování chybné, je Váš. [Ztracený zámek je náš](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures). Stránka běhu ukazuje další krok; [průvodce obnovou synchronizace](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures) uvádí, o který případ jde.

Zatím je to ta snadná polovina. Pád stojí jedno opakování a nic se nezapíše dvakrát. Druhou polovinu nás naučily dva incidenty.

## Selhání za selháním

Jedna synchronizace selhávala znovu a znovu. Ne v těsné smyčce: jednou za interval plánovače, běh za během, pokaždé se stejnou zprávou, že vlastní identifikátor nesmí obsahovat dvojtečku. Běh se nikdy nedostal k cíli. Zemřel už při zařazování do fronty, dřív než ho jakýkoli spouštěč uviděl, takže upozornění navázané na spouštěč nikdy nemělo na co reagovat.

Tu sérii nic nehlídalo. To je celé zjištění.

Opravou je jistič. Po každém zaznamenaném selhání načte posledních pět dokončených běhů synchronizace od její poslední změny. Pokud je všech pět chybových, synchronizaci pozastaví, zapíše jeden auditní řádek s důvodem `circuit_breaker_tripped` a odešle jedno kritické upozornění. Série se odvozuje z uložených běhů, ne z počítadla v pracovním procesu. Počítá se selhání zaznamenané jakoukoli cestou, včetně selhání při zařazování do fronty, které incident způsobilo. Komentář v kódu říká, že by ten incident zastavil u pátého běhu. Jeden úspěch sérii vynuluje. Zrušení pozastavení jistič znovu aktivuje, místo aby ho znovu vyhodilo na starých řádcích. [Průvodce konektorem Shopify](https://tajo.io/cz/docs/ecommerce-platforms/shopify/) říká totéž jednou větou: po pěti po sobě jdoucích neúspěšných bězích se synchronizace sama pozastaví a její stránka ukáže poslední chybu.

Jistič ale nic neopraví. Crusoe vymění uzel a restartuje úlohu bez ptaní. Tajo se zastaví a zeptá: pozastavená synchronizace zůstane pozastavená, dokud člověk neodstraní příčinu a [znovu ji nepublikuje](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#pause). Opatrné výchozí chování je záměrné: automatický opakovaný pokus synchronizace, která zapisuje do zákaznických záznamů, je sám o sobě zápis.

## Ticho, kterého si nikdo nevšiml

Námitka je férová a zní takto: „Jistič, který pozastaví po pěti selháních, by zachytil i druhý incident. Proč stavět druhého hlídače?“ Protože druhý incident nevypadal jako selhání. Dlouhou dobu měl jeden pracovní prostor aktivní synchronizaci, rostoucí hromadu chybových řádků a ani jeden úspěch, nikdy, a nic neupozornilo. Každý existující signál byl navázaný na aktivitu: běh selhal, přišel webhook, byl překročen rozpočet. Nula úspěchů není událost. Je to absence události a jistič se spustí jen tehdy, když se zaznamená selhání. Mrtvý plánovač, zaseknutá fronta, pracovní proces, který nikdy nenastartuje: nic z toho nic nezaznamená a jistič se nikdy neprobudí.

Zařízení bdělosti v lokomotivě funguje obráceně. Strojvedoucí ho musí průběžně potvrzovat a ticho vlak zastaví. Verze pro synchronizaci [běží jednou za hodinu](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check), třináct minut po celé. Každému pracovnímu prostoru s aktivní synchronizací položí jednu otázku: uspěl za posledních dvacet čtyři hodin nějaký běh? Pracovní prostor, jehož nejstarší aktivní synchronizace byla zapnuta před méně než dnem, se nechá být; ještě neměl den na to, aby uspěl. Starší prostor, který mlčí, dostane jedno kritické upozornění. Upozornění říká, o jaké ticho jde: běhy se zaznamenávají, ale žádný neuspěje, nebo nebyl zaznamenán vůbec žádný běh. Spustí se jednou na incident. Značka v Redis ho drží zavřené až do prvního úspěšného běhu, pak se smaže, takže další incident znovu upozorní.

Oba hlídači přibyli v jednom commitu, až dodatečně. Komentář jističe říká, že by první incident zastavil u pátého běhu. Komentář kontroly bdělosti říká, že synchronizace zapnutá dávno a s nulou běhů musí upozornit. Ani jeden neexistoval, když byl potřeba. Napsali jsme je až potom a oba incidenty jsme zapsali do hlavičky souboru, aby nikdo nezapomněl proč.

## Co je hotové a co ne

Hotové v době psaní:

- Kurzor se ukládá na konci každé čisté dávky a znovu při pádu.
- Doručovací klíč každého záznamu se odvozuje z kurzoru stránky a jeho pozice a před každým voláním cíle se ověřuje v [sedmidenním registru](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger).
- Jeden [dočasný zámek](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#lease) na synchronizaci s patnáctiminutovou platností.
- Pět [pokusů](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#retries) na běh s odstupem, který začíná na šedesáti sekundách a postupně roste.
- [Jistič](https://tajo.io/cz/resources/help/getting-started/understanding-data-sync/), který po pěti po sobě jdoucích selháních synchronizaci pozastaví a zaznamená proč.
- [Hodinová kontrola](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check), která upozorní po dvaceti čtyřech hodinách bez úspěchu.

Co hotové není a co stojí za to vědět, než se na to spolehnete:

- Kontrola bdělosti hlídá pracovní prostor, ne synchronizaci. Jedna zdravá synchronizace skryje tichou sousední synchronizaci ve stejném pracovním prostoru.
- Její upozornění [dorazí k operátorům Tajo](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check): vždy jako řádek logu a tam, kde je to nastaveno, také do Sentry, na webhook nebo e-mailem. Na stránce synchronizace se neobjeví. Pozastavení jističem ano.
- Nic pozastavenou synchronizaci nerestartuje. Udělá to člověk.
- Obnova po tvrdém ukončení není rychlá. Dočasný zámek může platit patnáct minut a [úklidová kontrola čeká hodinu](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#stuck-runs).
- Obě prahové hodnoty, pět selhání a dvacet čtyři hodin, jsou [nastavení nasazení](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#limits). Pro jednotlivou synchronizaci je nastavit nemůžete.

[I dlouhý řetězec téměř dokonalých kroků selhává](https://tajo.io/cz/blog/almost-perfect-steps-unreliable-chain/); cestou ven je definovat konečný stav a kontrolovat ho. Tento článek je provozní polovinou téhož. Definujte, co po sobě nechá mrtvý běh, a kontrolujte to nic, které po sobě nechá ticho.

Závěrečná věta Crusoe zněla, že „[selhání jsou nevyhnutelná](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=955s)“. Naše jde o krok dál. Pád byl tou snadnou polovinou, protože po sobě nechal řádky. Ticho bylo tou polovinou, kterou jsme museli jít hledat.

## Často Kladené Otázky

**Co se stane s běžící synchronizací, když pracovní proces spadne uprostřed dávky?**

Kurzor stále ukazuje na začátek přerušené dávky, protože Tajo ho posune až poté, co se dávka zapíše bez chyb. Další běh znovu načte stejnou stránku. Každý záznam nese doručovací klíč odvozený z kurzoru stránky a své pozice a registr uchovává každý dokončený zápis po dobu sedmi dnů, takže již zapsané záznamy se přehrají z registru, místo aby se do cíle odeslaly podruhé.

**Proč opakovaná synchronizace nezapíše stejný kontakt dvakrát?**

Před každým voláním cíle běh ověří doručovací klíč záznamu v registru. Klíč je hash synchronizace, zdroje, kurzoru stránky, pozice na stránce a samotného záznamu, takže pád, opakovaný pokus o minutu později i plánovaný běh následující den odvodí pro stejný záznam stejný klíč. Klíč, který je v sedmidenním okně již označen jako dokončený, se znovu neodešle.

**Co je upozornění bdělosti u synchronizace?**

Kontrola, která se spouští při absenci, ne při selhání. Jednou za hodinu Tajo projde každý pracovní prostor s aktivní synchronizací a upozorní, když za posledních dvacet čtyři hodin žádný běh neuspěl, včetně případu, kdy nebyl zaznamenán vůbec žádný běh. Spustí se jednou na incident a znovu se aktivuje po prvním úspěšném běhu. Existuje proto, že upozornění na selhání vidí jen selhání, která byla zaznamenána.

## Související články

### [Šest pravidel pro synchronizaci, která běží, když se nikdo nedívá](https://tajo.io/cz/blog/six-rules-unattended-sync/)

6\. 11. 2026 · 7 min čtení

7 sekcí

### [Pracovní postup mezi políčky](https://tajo.io/cz/blog/the-workflow-between-the-boxes/)

8\. 10. 2026 · 3 min čtení

Záznam obchodu → Oprava operátora → E-mailový cíl

### [Integrace Brevo: vyberte ověřitelné propojení](https://tajo.io/cz/blog/brevo-connector-guide/)

19\. 8. 2026 · 3 min čtení

6 sekcí