---
title: "Delovni proces je padel. Sinhronizacija ni."
description: "Ustavite delovni proces sredi paketa in sledite enemu stiku: kateri kazalec je bil shranjen, zakaj ponovljeni vpis ne pristane dvakrat in komu pripada sinhronizacija med ponovnim zagonom. Nato še dva incidenta, ki sta pokazala, da je obnova le polovica dela."
url: https://tajo.io/sl/blog/worker-died-sync-didnt/
markdown: https://tajo.io/sl/blog/worker-died-sync-didnt.md
lang: sl-SI
author: "Set Noa"
author_url: https://tajo.io/sl/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, cs-CZ: /cz/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, 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}
---

[Sinhronizacija podatkov](https://tajo.io/sl/blog/?category=data-sync)

# Delovni proces je padel. Sinhronizacija ni.

Ustavite delovni proces sredi paketa in sledite enemu stiku: kateri kazalec je bil shranjen, zakaj ponovljeni vpis ne pristane dvakrat in komu pripada sinhronizacija med ponovnim zagonom. Nato še dva incidenta, ki sta pokazala, da je obnova le polovica dela.

obnova sinhronizacije po napaki

Kaj se zgodi s tekočo sinhronizacijo, ko delovni proces pade sredi paketa?

Kazalec se premakne šele na koncu čistega paketa, zato delovni proces, ustavljen sredi paketa, kazalec pusti na začetku tega paketa, naslednji zagon pa prebere isto stran. Ključ dostave vsakega zapisa je izpeljan iz kazalca strani in njegovega položaja, sedemdnevna evidenca dokončanih vpisov pa prepreči, da bi ponovitev pristala dvakrat. En zakup na sinhronizacijo prepreči, da bi dva zagona delala hkrati. To je bila lažja polovica. Ena sinhronizacija je odpovedovala zagon za zagonom, preden jo je karkoli zaustavilo, en delovni prostor pa je ostal tiho, z napakami in brez enega samega uspeha, preden je to karkoli opazilo. Zato zdaj obstaja varovalka, ki sinhronizacijo zaustavi po petih zaporednih napakah, in urno opozorilo po štiriindvajsetih urah brez uspeha.

[Izvedite več](https://tajo.io/sl/blog/worker-died-sync-didnt/#sledite-enemu-stiku)

V [predavanju, ki ga je 3. oktobra 2026 objavil AI Engineer](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=701s), strokovnjak za odnose z razvijalci pri podjetju Crusoe zažene učenje PyTorch na dveh vozliščih A100. Nato lastnemu nadzornemu sistemu predstavitve sporoči, da je en GPU vrnil napako XID 79. Vozlišče je označeno kot nedosegljivo, opravilo pa preklicano. Proces prejme SIGTERM in „[do dve minuti, da obdelate ta SIGTERM in shranite kontrolne točke ali izpraznite dnevnike](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=633s)“. Vstopi rezervno vozlišče in „[opravilo slurm se bo znova zagnalo. Naložilo bo kontrolno točko in nadaljevalo učenje tam, kjer se je ustavilo](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=769s)“. Od začetka do konca nekaj manj kot petnajst minut. Nikogar ni bilo treba poklicati na dežurstvo.

Sinhronizacija je precej manjša žival kot zagon učenja. Vprašanje pa je enako. Kaj zagon potrebuje, da ustavitev delovnega procesa stane minute in nobenih dvojnikov?

To je odgovor za [Tajov lastni izvajalnik sinhronizacij](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/), prebran iz kode in ne iz brošure. [Reverse ETL](https://tajo.io/sl/blog/what-is-reverse-etl/) opisuje obliko tega dela. Tukaj je opisano, kaj se zgodi, ko to delo umre.

## Sledite enemu stiku

Zagon bere vir stran za stranjo, od shranjenega kazalca naprej. Kazalec strani poimenujmo `c3`, naš stik pa naj bo 212. zapis na tej strani. Preden se karkoli vpiše, za ta stik veljajo tri stvari.

Prvič, ima ključ dostave. Ključ je zgoščena vrednost identifikatorja sinhronizacije, vira, kazalca strani, položaja na strani in samega zapisa. Kazalec in zapis gresta v zgoščeno vrednost in nikoli nista vgrajena v ključ, zato ključ ne nosi [nobenega e-poštnega naslova](https://tajo.io/sl/resources/help/getting-started/understanding-data-sync/).

Drugič, vpis gre skozi [evidenco](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger) in ne naravnost v cilj. Preden je cilj poklican, je ključ prevzet s stanjem v čakanju. Ko vpis uspe, je vrstica označena kot dokončana in se hrani sedem dni.

Tretjič, kazalec se ni premaknil. Premakne se le na koncu paketa, le če je pristal vsak zapis v tem paketu, in šele potem, ko je zagon dokazal, da je sinhronizacija še vedno njegova.

Zdaj ustavite delovni proces med vpisom in kontrolno točko.

Ob SIGTERM vsak delovni proces čakalne vrste dokonča tekoče delo v enem skupnem petnajstsekundnem roku, proces pa se konča po petindvajsetih sekundah, ne glede na to, kaj še teče; systemd mu da petinštirideset, preden ga prisilno ustavi. Zagon, ki se v tem oknu ni končal, je še vedno označen kot tekoč, naslednji delovni proces pa ga prevzame prek obnove zastalih opravil v čakalni vrsti. Ob trdi ustavitvi ni nobenega dokončevanja. Tako ali drugače veljata isti dve dejstvi. Cilj ima naš stik. Naš [kazalec](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#cursor) še vedno kaže `c3`.

## Ponovitev

Naslednji zagon začne pri `c3`, prebere isto stran, za 212. zapis izpelje isti ključ in vpraša evidenco. Evidenca odgovori: dokončano. Cilj ni poklican; shranjeni rezultat se ponovi in zagon gre naprej. Na množični poti, kjer uvozna končna točka Brevo sprejme celo stran v enem klicu, se ista kontrola izvede za vsak ključ, še preden je zahteva sestavljena. Stran, na kateri je vsak ključ že dokončan, ne pošlje ničesar.

To je ves trik in vredno je povedati, zakaj deluje. Ključ je izpeljan iz kazalca strani na začetku paketa in ne iz zagona, ki se je takrat slučajno izvajal. Zrušitev, ponovni poskus šestdeset sekund pozneje in načrtovani zagon jutri za isti zapis [izpeljejo isti ključ](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger). Evidenci je vseeno, kateri od njih sprašuje.

Zdaj cena. [Evidenca po sedmih dneh pozabi](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger). Komentar v kodi pravi, da sedem dni pokrije zapozneli ponovni poskus in kratek izpad, in nič več ne trdi. Ponovitev od kazalca, starejšega od tega, vpisuje znova. In zagon, ki je bil trdo prekinjen, lahko čaka. Zakup mrtvega zagona velja do petnajst minut, pri načrtovani sinhronizaciji pa je zagon, katerega zakup je prost, [pometen in znova načrtovan šele, ko se je začel pred več kot eno uro](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#stuck-runs). Predstavitev podjetja Crusoe je [nazaj v manj kot petnajstih minutah](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=753s). Naša ne vedno.

## Komu pripada sinhronizacija med ponovnim zagonom

Sinhronizacija ima naenkrat enega lastnika: en zagon. Zagon v Redis vzame [zakup](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#lease) z lastnim žetonom, petnajstminutno veljavnostjo in podaljšanjem vsakih pet minut. Pred vsako kontrolno točko preveri, ali zakup še drži. Če ga ne, se ustavi. Zagon je zabeležen s [preprostim stavkom, ki ga bo prebral človek](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures): „The run lost its slot part-way through and stopped to avoid writing twice.“ (Zagon je med izvajanjem izgubil svoje mesto in se ustavil, da ne bi vpisal dvakrat.) Drugi zagon, ki trči ob živega lastnika, se ne ponovi. [Konča se s sporočilom](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures) „Another run of this sync was already in progress“ (drug zagon te sinhronizacije je že potekal), naslednji načrtovani zagon pa se začne normalno.

Zapisano je tudi, kdo je lastnik popravka. Vsaka [koda napake](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures) ima en stavek o tem, kaj se je zgodilo, enega o tem, kaj storiti naprej, in lastnika: vas ali Tajo. Cilj, ki je zavrnil vsak zapis, ker je preslikava napačna, je vaš. [Izgubljen zakup je naš](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures). Stran zagona pokaže naslednji korak; [vodnik za obnovitev sinhronizacije](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures) navaja, za kateri primer gre.

Zaenkrat je to lažja polovica. Zrušitev stane eno ponovitev in nič ne pristane dvakrat. Drugo polovico sta nas naučila dva incidenta.

## Napaka za napako

Ena sinhronizacija je odpovedovala vedno znova. Ne v tesni zanki: enkrat na interval razporejevalnika, zagon za zagonom, vsakič z enakim sporočilom, da identifikator po meri ne sme vsebovati dvopičja. Zagon nikoli ni prišel do cilja. Umrl je že med uvrščanjem v čakalno vrsto, preden ga je videl katerikoli izvajalnik, zato opozorilo, vezano na izvajalnik, nikoli ni imelo na kaj reagirati.

Tega niza ni nič spremljalo. To je celotna ugotovitev.

Popravek je varovalka. Po vsaki zabeleženi napaki prebere zadnjih pet končanih zagonov sinhronizacije od njene zadnje spremembe. Če je vseh pet napak, sinhronizacijo zaustavi, vpiše eno revizijsko vrstico z razlogom `circuit_breaker_tripped` in sproži eno kritično opozorilo. Niz je izpeljan iz shranjenih zagonov in ne iz števca v delovnem procesu. Šteje napaka, zabeležena po katerikoli poti, vključno z napako pri uvrščanju v čakalno vrsto, ki je povzročila incident. Komentar v kodi pravi, da bi ta incident ustavila pri petem zagonu. En uspeh niz ponastavi. Ko zaustavitev odpravite, se varovalka znova aktivira, namesto da bi se znova sprožila na starih vrsticah. [Vodnik za povezovalnik Shopify](https://tajo.io/sl/docs/ecommerce-platforms/shopify/) pove isto v enem stavku: po petih zaporednih neuspešnih zagonih se sinhronizacija sama zaustavi, njena stran pa pokaže zadnjo napako.

Varovalka pa ničesar ne popravi. Crusoe zamenja vozlišče in znova zažene opravilo, ne da bi vprašal. Tajo se ustavi in vpraša: zaustavljena sinhronizacija ostane zaustavljena, dokler človek ne odpravi vzroka in je [znova ne objavi](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#pause). Previdna privzeta nastavitev je namerna: samodejni ponovni poskus sinhronizacije, ki vpisuje v zapise strank, je sam po sebi vpis.

## Tišina, ki je nihče ni videl

Ugovor je upravičen in se glasi: „Varovalka, ki zaustavi po petih napakah, bi ujela tudi drugi incident. Zakaj graditi drugega čuvaja?“ Ker drugi incident ni bil videti kot napaka. Dolgo časa je imel en delovni prostor aktivno sinhronizacijo, naraščajoč kup vrstic z napakami in niti enega uspeha, nikoli, in nič ni sprožilo opozorila. Vsak obstoječi signal je bil vezan na dejavnost: zagon je odpovedal, prispel je webhook, presežen je bil proračun. Ničelno število uspehov ni dogodek. Je odsotnost dogodka, varovalka pa teče le, ko je zabeležena napaka. Mrtev razporejevalnik, zataknjena čakalna vrsta, delovni proces, ki se nikoli ne zažene: nič od tega ničesar ne zabeleži in varovalka se nikoli ne zbudi.

Naprava za budnost v lokomotivi deluje ravno obratno. Strojevodja jo mora ves čas potrjevati, tišina pa ustavi vlak. Različica za sinhronizacijo [teče enkrat na uro](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check), trinajst minut čez polno uro. Za vsak delovni prostor z aktivno sinhronizacijo postavi eno vprašanje: ali je v zadnjih štiriindvajsetih urah uspel katerikoli zagon? Delovni prostor, katerega najstarejša aktivna sinhronizacija je bila vklopljena pred manj kot enim dnem, ostane pri miru; še ni imel dneva, da bi uspel. Starejši in tihi dobi eno kritično opozorilo. Opozorilo pove, za katero tišino gre: zagoni so zabeleženi, a noben ne uspe, ali pa ni bil zabeležen sploh noben zagon. Sproži se enkrat na incident. Oznaka v Redis ga drži zaprtega do prvega uspešnega zagona, nato se počisti, zato naslednji incident znova sproži opozorilo.

Oba čuvaja sta prišla v enem commitu, naknadno. Komentar varovalke pravi, da bi prvi incident ustavila pri petem zagonu. Komentar preverjanja budnosti pravi, da mora sinhronizacija, vklopljena davno in brez enega samega zagona, sprožiti opozorilo. Nobeden od njiju ni obstajal, ko je bil potreben. Napisali smo ju pozneje in oba incidenta zapisali v glavo datoteke, da nihče ne pozabi, zakaj.

## Kaj je zgrajeno in kaj ni

Zgrajeno v času pisanja:

- Kazalec se shrani na koncu vsakega čistega paketa in znova ob zrušitvi.
- Ključ dostave vsakega zapisa je izpeljan iz kazalca strani in njegovega položaja ter pred vsakim klicem cilja preverjen v [sedemdnevni evidenci](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger).
- En [zakup](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#lease) na sinhronizacijo s petnajstminutno veljavnostjo.
- Pet [poskusov](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#retries) na zagon z razmikom, ki se začne pri šestdesetih sekundah in narašča.
- [Varovalka](https://tajo.io/sl/resources/help/getting-started/understanding-data-sync/), ki po petih zaporednih napakah zaustavi sinhronizacijo in zabeleži razlog.
- [Urno opozorilo](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check) po štiriindvajsetih urah brez uspeha.

Ni zgrajeno, in to je vredno vedeti, preden se na to zanesete:

- Preverjanje budnosti spremlja delovni prostor, ne sinhronizacije. Ena zdrava sinhronizacija skrije tiho sosednjo sinhronizacijo v istem delovnem prostoru.
- Njegovo opozorilo [doseže operaterje Tajo](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check): vedno kot vrstica v dnevniku, kjer je nastavljeno, pa tudi v Sentry, prek webhooka ali po e-pošti. Na strani sinhronizacije se ne prikaže. Zaustavitev z varovalko se.
- Nič ne zažene zaustavljene sinhronizacije znova. To stori človek.
- Obnova po trdi ustavitvi ni hitra. Zakup lahko drži petnajst minut, [čistilni pregled pa čaka eno uro](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#stuck-runs).
- Oba praga, pet napak in štiriindvajset ur, sta [nastavitvi namestitve](https://tajo.io/sl/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#limits). Za posamezno sinhronizacijo ju ne morete nastaviti.

[Dolga veriga skoraj popolnih korakov vseeno odpove](https://tajo.io/sl/blog/almost-perfect-steps-unreliable-chain/); izhod je v tem, da določite končno stanje in ga preverjate. Ta članek je operativna polovica istega. Določite, kaj za seboj pusti mrtev zagon, in preverjajte tisti nič, ki ga za seboj pusti tišina.

Sklepni stavek podjetja Crusoe je bil, da so „[napake neizogibne](https://www.youtube.com/watch?v=bRGyYaE0lxI&t=955s)“. Naš gre korak dlje. Zrušitev je bila lažja polovica, ker je za seboj pustila vrstice. Tišina je bila polovica, ki smo jo morali iti iskat.

## Pogosto Zastavljena Vprašanja

**Kaj se zgodi s tekočo sinhronizacijo, ko delovni proces pade sredi paketa?**

Kazalec še vedno kaže na začetek prekinjenega paketa, ker ga Tajo premakne šele, ko paket pristane brez napak. Naslednji zagon znova prebere isto stran. Vsak zapis nosi ključ dostave, izpeljan iz kazalca strani in svojega položaja, evidenca pa sedem dni hrani vsak dokončan vpis, zato se že vpisani zapisi ponovijo iz evidence, namesto da bi bili v cilj poslani še drugič.

**Zakaj ponovljena sinhronizacija istega stika ne vpiše dvakrat?**

Pred vsakim klicem cilja zagon preveri ključ dostave zapisa v evidenci. Ključ je zgoščena vrednost (hash) sinhronizacije, vira, kazalca strani, položaja na strani in samega zapisa, zato zrušitev, ponovni poskus minuto pozneje in načrtovani zagon naslednji dan za isti zapis izpeljejo isti ključ. Ključ, ki je v sedemdnevnem oknu že označen kot dokončan, se ne pošlje znova.

**Kaj je opozorilo budnosti pri sinhronizaciji?**

Preverjanje, ki se sproži ob odsotnosti in ne ob napaki. Enkrat na uro Tajo pregleda vsak delovni prostor z aktivno sinhronizacijo in sproži opozorilo, ko v zadnjih štiriindvajsetih urah ni uspel noben zagon, vključno s primerom, ko ni bil zabeležen sploh noben zagon. Sproži se enkrat na incident in se znova aktivira po prvem uspešnem zagonu. Obstaja zato, ker opozorilo o napaki vidi le napake, ki so bile zabeležene.

## Sorodni članki

### [Šest pravil za sinhronizacijo, ki teče, ko je nihče ne gleda](https://tajo.io/sl/blog/six-rules-unattended-sync/)

6\. nov. 2026 · 7 min branja

7 razdelkov

### [Potek dela med polji na diagramu](https://tajo.io/sl/blog/the-workflow-between-the-boxes/)

8\. okt. 2026 · 4 min branja

Zapis trgovine → Popravek izvajalca → Ciljni e-poštni sistem

### [Integracije Brevo: izberite povezavo, ki jo lahko preverite](https://tajo.io/sl/blog/brevo-connector-guide/)

19\. avg. 2026 · 4 min branja

6 razdelkov