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ódusának fejlődésének lépései olvashatók, mysql adatbázison.
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
@ -16,8 +16,39 @@ A vpn kiváltható egy adatkapcsolati réteg elhelyezésével az adatbázis föl
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 igyényel, ráadásul a munkaállomásokon futó szolgákat nehéz felügyelni.
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.
