SqLite Adatbázisok Szinkronizálása

Adatok kezelése során, amint egynél több kezelőnek, vagy egy kezelőnek több munkaállomásról kell elérni az adatokat, a helyben létrehozott adatbázis lesz a korlátozó tényező, felmerül a kérdés, hogyan lehet azt a korlátot átlépni. Az adatbázisban kezelt adatok jellegüket tekintve gyakorlatilag bármilyenek lehetnek, készletnyilvántartás, archívum dokumentumok vagy képek számára, számlázási vagy mérési adatok, üzenetek, stb., a lista szinte végtelen.

A továbbiakban egy nagyméretű adatokat (2-300 MB pdf dokumentum) is tároló rendszer tárolási metódusa fejlődésének lépései olvashatók, mysql adatbázison.

Központi adatbázis

A probléma megoldásának kézenfekvő eszköze a helyben tárolt adatbázis áthelyezése központi kiszolgálóra. Ez addig jó megoldás, amíg pl. egy irodán belül kell több helyről elérni az adatokat, a sávszélesség gyors, egyszerű adatbázis kapcsolattal megvalósítható. Az adatbázis elérését nyilvánossá tenni nem szerencsés, így a helyi hálózaton kívülről már vpn felépítése szükséges, ami viszont már lassítja az elérést.

Adatkapcsolati réteg

A vpn kiváltható egy adatkapcsolati réteg elhelyezésével az adatbázis fölé, pl. rest api kapcsolaton keresztüli eléréssel, a vpn kiépítése nem szükséges, de távolról ugyanúgy lassú lesz.

Elosztott adatbázis

Több elérési pont hozható létre az adatbázis replikáció használatával, pl telephelyenként,. Ez adatbiztonság és rendelkezésre állás tekintetében is előnyös, viszont a nem belső hálózatról történő elérés ebben az esetben is vpn-en vagy rest api-n keresztül lehetséges.

A másik megoldás, hogy multi master replikáció kerül megvalósításra, így minden munkaállomás a saját helyben tárolt adatbázisába dolgozik, az adatok pedig a replikáció útján eljutnak mindenkihez. Ez a megoldás rengeteg beállítást igényel, ráadásul a munkaállomásokon futó szolgákat nehéz felügyelni.

Hibrid megoldás

A fenti tapasztalatok felhasználásával készült egy megoldás, ami a helyben tárolt sqlite adatbázisokat rest api-n elérhető szerveren keresztül szinkronizálja.

A probléma

Adatbázisok szinkronizálásánál az adattáblák elsődleges kulcsát úgy kell kezelni, hogy ne keletkezhessen ütközés. A mysql erre megoldást nyújt a konfigurációjában beállítható változók segítségével.

server-id                   = 1
auto-increment-offset       = 1
auto-increment-increment    = 10

A replikációban résztvevő adatbáziok mindegyikének egyedi azonosítója van a server-id, a másik két változó az auto_increment típusú mezők (az elsődleges kulcs ilyen, ha az adatbázis kezelőre bízzuk a kezelését) képzésének a szabályait írja le. Az auto-increment-offset az alapértéktől való eltolást határozza meg, az auto-increment-increment pedig az eltolt érték növelésének mértékét.

A fenti esetben egy üres táblában az elsődleges kulcsok rendre az 1, 11, 21, 31, 41 ... értékeket veszik fel.

A 2-es szerveren a fenti beállítások így néznének ki:

server-id                   = 2
auto-increment-offset       = 2
auto-increment-increment    = 10

Ebben az esetben az elsődleges kulcsok a 2, 12, 22, 32, 42 ... értékeket veszik fel. Az auto-increment-increment azt is meghatározza, hogy hány szerver vehet részt a replikációban (mivel a fenti három változó egyike sem lehet 0, így ebben az esetben 9 adatbázis vehet részt a replikációban).

A megoldás

A lokális adatbázisban keletkező elsődleges kulcsok képzését meg lehetne oldani a mysql replikációnál használt megoldással, de az további adminisztrációt eredményezne, minden résztvevő kliensnek egyedi sorszámmal kellene rendelkeznie, előre kellene tudni a résztvevő adatbázisok számát, és, ha az mégis kevésnek bizonyul, az összes adatbázison újra kellene konfigurálni az elsődleges kulcsokat és azok képzését is.

Inkább az a megoldás lett használva, hogy a helyi adatbázisokban keletkezett elsődleges kulcsok nem kerülnek szinkronizálásra.