Sesynchronizování databází
Koncem loňského roku jsem dělal shodou okolností hned v několika notesových systémech synchronizaci databází. Znáte to: po několika měsících až letech provozu se databáze, přestože jsou pravidelně replikovány, "rozjedou" - mají různý počet dokumentů. Běžný uživatel nemusí nic poznat, ale administrátor by rád měl vše v pořádku, tak jak má být. A mít stejný počet dokumentů u jednotlivých replik mezi to patři.
Přestože některé úkony se provádí celkem rutinně, pokusím se zde vyjmenovat co nejvíce postupů, jak dosáhnout kýženého stavu. Po každém kroku spusťte znovu plnou replikaci a prověřte, zda se počet dokumentů nesrovnal.
- Ověřte si, zda repliky mají mít opravdu stejný počet dokumentů. V některých případech může být žádoucí, že jednotlivé instance jedné databáze nemají být úplně stejné: například existují různé repliky na několika pobočkách a v centrále je potom sjednocení všech dat, nebo na webový serveru se replikuje jen část dokumentů (pro veřejné užití) a podobně.
- Zakázaná replikace. Jenom pro jistotu - podívejte se, jestli některá z replik nemá zakázanou replikaci (Replication Settings - Other).
- Odstraňování dokumentů. Některé databáze mohou mít nastaveno pravidlené odmazávání dokumentů, pomocí nastavení v Replication Settings - Space Servers. Takto smazané dokumenty nenechávají po sobě deletion stub, takže zpráva o vymazání se nešíří na další servery. Problém může nastat, pokud každá replika má toto jinak nastaveno: na jednom serveru bude nastaveno odmazávání po 90 dnech, na druhém serveru nic. První replika bude potom vykazovat nižší počet dokumentů.
- Smažte replikační historii a to na obou serverech. Nejjednodušší a nejpoužívanější způsob.
- Smažte cut-off date. Jedná se o uložené konkrétní datum a čas (asi čtvrt roku starý), od kterého replikační proces porovnává seznamy ID dokumentů, aby nemusel procházet celou databázi. Údaj můžete upravit/smazat přes Replication Settings - Other. Smazání tohoto pole způsobí rovněž smazání replikační historie!
- Zkontrolujte ACL. V optimálním případě budou mít oba servery alespoň editorská práva a ACL bude na obou stranách stejné. Jinak mohou nastat tyto případy (a jejich kombinace):
- Nízká přístupová práva. Jeden ze serverů (zpravidla "vnější" nebo "pobočkový") má autorská nebo nižší práva. V tomto případě zkontrolujte, kde podle procesu vznikají dokumenty a zda se změny správně šíří ze serveru s vyššími právy na server s nižšími právy (vztaženo proti sobě navzájem).
- Nekonzistentní ACL. Není nutno mít zrovna zaškrtnuto Enforce a consitent ACL, stačí se podívat, zda ACL jsou na obou stranách stejná, zejména co se týče práv pro problémové servery (nebo skupiny, ve kterých jsou).
- Prověřte role. Readers a authors pole mohou s počty dokumentů při replikování také pěkně zamávat. Platí, že server čte z druhého serveru jenom to, co "vidí", tedy kde je uveden v poli Readers, pokud existuje (platí vždy). Stejně tak může na protější serveru přenést změnu jen toho dokumentu, kde je uveden v poli Authors, pokud existuje (platí jen, pokud má úroveň přístupu Author).
- Selektivní replikace - dobrý sluha ale zlý pán. Může se stát, že na jeden server se replikuje pouze část dokumentů druhého serveru. Ověřte si v Replication settings - Advanced.
- Nereplikování výmazů. Z jakéhokoliv důvodu může mít jedna replika zakázáno přijímat deletion stubs, informace o smazaných dokumentech. V takovém případě bude mít tato replika více dokumentů, než replika na partnerském serveru, kde se dokumenty odmazávají normálně. nastavuje se opět v Replication settings - Advanced.
Předchozí: Chyba #04:06
Následující: Komprese síťového spojení