MSSQL és PGSQL adatok szinkronban tartása

Adatbázis: SQL, XML DB

Sziasztok,

A következő szituáció megoldása lenne a feladatom, melyre igazi átfogó ötlet még nem született a fejemben. Remélem Ti tudtok segíteni.

Adott két szerver:
1) Win + MSSQL
2) Linux + PGSQL

Jelenleg az 1)-es szerver szolgálja ki a cég vállalatirányítási rendszerét, pontosabban az ahhoz szükséges adatbázist. Itt egy kb 2Gb-s adatbázisról beszélünk, melyben a kb 60 alkalmazott napi 8 órában folyamatosan dolgozik (számlázás, megrendelések kezelése stb.).
A cég a vállalatirányítási rendszer újraírását tűzte ki célul. Az új rendszert a 2)-es szerver fogja kiszolgálni.

Az átállás modularizált lesz, tehát nem lesz minden alkalmazott orra alá odadugva az új vállalatirányítási rendszer, hanem szép fokozatosan fog áttérni mindenki az új rendszerre. Éppen ezért elengedhetetlen, hogy az adatok a két adatbázisban tökéletesen azonosak legyenek.

Van arra mód és lehetőség, hogy a két adatbázist szinkronban tartsam valahogy? A dolog szépsége, hogy bár az adatok ugyan azok, de az adatbázis felépítése nem minden ponton egyezik meg, mivel a régi rendszer tartalmazott néhány tervezési hibát. Többek között ezért is döntött a cég a váltás mellett.

Félek erre nem igazán létezik megoldás, úgy viszont érdekelne, hogy mégis hogyan szokás egy ilyen átállást megoldani. Az teljesen nyilván való, hogy egyik napról a másikra nem lehet kihúzni az 1)-es szervert és a 2)-est üzembe állítani, mert az új rendszer tartalmazhat rejtett hibákat, amelyek a cég szempontjából érzékeny adatokat (készlet stb) érzékenyen érinthetik, ami nem elfogadható. Tehát nem volna jó, hogyha minden részlegen egyszerre átállna az új rendszerre mindenki, mert az komoly kockázatot jelentene. Mégis mi lehet ilyen esetben a megoldás? Tudom... Olyan programkódot kell csinálni, ami már nem tartalmaz gyermek betegségeket, vagy tesz adatokon tesztelni kell a rendszert. Ezzel nincs is gond, de aki programozott már valaha az tudja, hogy ilyet lehetetlen készíteni. A hibák előfordulását és az okozott kárt jó teszt unitokkal minimalizálni lehet, de 100%osan kizárni nem.

Remélem csinált már valaki hasonlót és tud segíteni, hogy a lehető leghatékonyabban elvégezhető legyen az átállás.
Köszi mindenki!!

  • 10066 megtekintés

( gabrielakos v | 2013. 01. 03., cs – 14:04 )

Ha tranzakció szinten akarod a szinkronizációt megcsinálni akkor két utat látok:

- összekötöd a két adatbázist és triggereket írsz minden táblához, minden dml művelethez (eszetlen meló)
- írsz egy alkalmazást (mondjuk java-ban) amely egy message queue-t implementál, egyik oldalon dobálod bele a változásokat másik oldalon meg veszed ki, itt mondjuk az esetleges konverziókat talán még egyszerűbb megcsinálni

Ha elég ritkábban szinkronizálni akkor mondjuk éjjel leáll, export-import, restart.

Egyébként ez egy eszetlen nagy meló, ráadásul nagyjából feleslegesen.
Kb. összemérhető a költsége azzal, minthogy pár napig az alkalmazottak mindkét rendszerbe bevigyenek mindent, esetleg túlórával.

--
Gábriel Ákos
http://i-logic.hu

[off]
A témában az első válasz: 2013. január 3., csütörtök - 15:04 érkezett. Nálam most az idő 14:14. Tehát a jövőből érkezett a válasz. :)
[tech]némi gond van a szerver idővel hupéknál[/tech]
[/off]

A trigger írás szinte lehetetlen vállalkozás, mert rengeteg akcióról beszélünk. Azt mindet letriggerelni lehetetlen.
A második megoldás már jobb ötletnek tűnik.

Azért még várok, mert szerintem nem én egyedül kerültem hasonló szituba. Hátha másnak már van tapasztalata.

A kérdés az, hogy mennyi adatot akarsz szinkronizálni, mert egyébként szinkronizáció fejlesztésének hibalehetősége összemérhető, az új alkalmazás hibalehetőségével, tehát nem nyersz vele semmit, csak lesz két inkonzisztens adatbázisod. Ha az alkalmazás moduláris, akkor jó esetben a modulok nem írnak egymás adataiba, és akkor csak egy irányba kell megcsinálni a szinkronizációt, ami egy select -> insert párossal könnyen megoldható, a lényeg, hogy a régi modulok a régi táblákba írnak, az újak meg az újba, közte meg megy a szinkronizáció.

Már csak azért is kötelező célszerű a mindkét rendszerben ugyanazok rögzítése, mert így tudod érdemben ellenőrizni, hogy a riportok/zárások eredménye azonos-e, ui. ha nem így csinálod, azt is bizonyítanod kell, hogy az esetleges eltérések nem az adatszinkronizálás miatt adódnak-e.

Dupla rögzítésnél te mutogathatsz a felhasználóra, szinkronizálásnál a felhasználó fog rád, ha nem minden százas. Nagy lamúr semmiképpen nem lesz.

( zeller | 2013. 01. 03., cs – 14:58 )

Az új alkalmazásban implementálni egy adatbázis kezelőtől független réteget, ami az adatokat a megadott DB-be írja, illetve onnan olvassa? Mindenki dolgozik az MSSQL-be, egészen addig, amíg mindent nem implementálnak az új rendszerben - ekkor mssql-ből adatok ki, pgsql-be adatok be, tesztkörnyezetben a pgsql-re átkonfigurálni a cuccot, tesztelés ezerrel, aztán ha minden klappol, akkor lehet élez pgsql db-t is építeni az mssql-ből kinyert adatokból. Ha a DB-be is akartok sok okosságot rakni, akkor ez nem járható út, ha csak az MSSQL kiváltása a célja az újraírásnak, akkor viszont meg lehet csinálni.

Még két azonos DB szinkronban tartása sem egyszerű feladat aktív/aktív felállás esetén, neked meg az aktív/aktív mellé két hótt eltérő DB-d van...

A probléma, hogy nem csak a DB szerver eltérő, de még a táblák sem mindenhol ugyan azok. Továbbá sok minden másképp van/lesz megoldva, mint az MSSQL-be volt. (pl: triggerek stb.)

Ez és az ezt megelőző javaslatok mindegyike azt erősíti meg bennem, hogy a júzerek rögzítsék az adatokat két helyre. Csak a gond ezzel az, hogy rengeteg ellenségre fogok szert tenni, ha ezt az ötletet vázolom.
Abban viszont igazatok van, hogyha a szinkronizációs mechanizmusban valami hiba marad, akkor ott a kérdés, hogy az új program rossz, vagy a szinkronizáció hibázott.

Ne te dönts (nem tudom, megteheted-e), hanem előnyökkel és hátrányokkal (értsd: veszélyekkel, azokat pirossal aláhúzva) add le választásra a lehetőségeket a döntésre hivatottaknak... legrosszabb esetben visszadobják a döntés "jogát".

Az ájtít meg úgyis helyből rühellik, mert mindig plusz munkát ad (kivéve amikor hülye krixkraxokkal két perc alatt megoldanak egyheti melót), meg mindenfélét tesz a gépre, amitől az lassabb, meg mókanélküli lesz, meg minden - szokj hozzá... a lényeg, hogy ne a főnök meg a főnök főnöke rühelljen leginkább.

( ssikiss | 2013. 01. 03., cs – 15:26 )

Ki kell dolgozni egy módszertant az új rendszer szállítójának a problémára - ha még nincs ilyen. Vagy kit akartok megbízni a migrációval?

Partvonalról láttam ilyet. Rengeteg idő/energia ment a meglévő adatok migrációjára (megtisztítására!, konvertálására, új struktúrába bevitelére). Ez a kiinduló állapot. Az új rendszer beindítása után kiemelt támogatással javítottunk programot, de legtöbbször inkább adatot. Megjegyzem, újonnan fejlesztett rendszernél egyébként sem úszod meg a kezdeti relatív több programhibát.
A két rendszer közti szinkronizáció egyirányú volt, vagyis a régi rendszer küldte az újba az adatokat, de az újban felvetteket már csak ott lehetett kezelni (nem is lehetett volna visszatolni, annyira más volt a struktúra és adattípusok).
Az integrációs technológia a lehető legegyszerűbb volt, a régi rendszer adatbázisából időzítetten futó segédalkalmazás emelte át a változásokat az újba. Aztán amikor sikerült mindenkit betanítani/minden funciót kidolgozni az új rendszerre, akkor kikapcs régi.

Itt van a gond... Ugyanis a készlet nyilvántartást nem elég bizonyos időközönként szinkronizálni, mert ha a régi rendszerben úgy látják, hogy van még a termékből, az újban meg már úgy, hogy nincs, vagy fordítva, akkor ott oltári nagy keveredések lesznek. De persze ez csak a készletre és még egy-két hasonló adatra igaz. A többinél nincs gond az időzített szinkronizációval.

Én akkor vágnék bele a két db szinkronba tartásának, ha hosszabb távon nincs biztosíték rá, h az új rendszer produktívan tud működni. Egyébként ez tényleg nem üzemeltetési feladat, egyértelműen a szállító/fejlesztő felel érte. Gondolj csak bele az eltérő adatstruktúrákba meg az erre épülő üzleti logikára (Ahogy írtad, az a szándékotok, hogy a régi rendszerben lévő dolgokat átalakítva készüljön el az új.)
Rá kell szánni egy, két hétvégét meg éjszakát, pár napig hallgatni az anyázást és menni fog :). Viccet félretéve a migráció illetve az egyes munkafázisok felelősségi köreinek tisztázása legyen az első IMO.

( hal | 2013. 01. 03., cs – 15:42 )

Ez az új rendszer fejlesztőjének/szállítójának a feladata, egyértelműen nem az üzemeltetésé.

( Arbiter | 2013. 01. 03., cs – 16:19 )

Szia!

--OFF--
SZŰZMÁRIAÉDESANYÁM!
--OFF--

Én másutt fognám meg a problémát:

Azt gondolom, hogy ha üzemeltető vagy, a környezet megteremtésén (pl. OS/DB telepítése, konfigurálása, hozzáférés és kapacitás biztosítása, üzemeltetés megszervezése) kívül nincs más dolgod.
Amit kérnek tőled, az egy adatmigrációs feladat, az adott szoftver szállítója/fejlesztője lesz szíves megoldani, ő ismeri a saját termékét, annak felépítését.
Már megbocsáss, de menedzsmentre nézve nevetséges, hogy tőled, üzemeltetőtől várják el, hogy a két eltérő adatstruktúra között te teremts és tarts fent szinkront, amíg lezajlik az átállás. Az új szoftver rendszertervében (van ilyen egyáltalán?) illene szerepelnie egy migrációs tervnek is.
Ha nincs, akkor a fejlesztők, vagy a projekt vezetője keressen másik foglalkozást, mert ez is része a munkájának, amit ezek szerint nem tud/akar elvégezni. :(

( Zsugabubus | 2013. 01. 03., cs – 16:22 )

Ez egy szopó téma, előző munkahelyemen volt próbálkozás hasonló dologra, nem túl nagy sikerrel :)

( dii | 2013. 01. 03., cs – 17:21 )

Láttam már vállalatirányítási rendszert közelről, meg adatbázist is, véleményem szerint ezt így ne csináld. Nem azt mondom hogy nem lehet, hanem azt hogy ne tedd.

Technikai megoldást tudsz rá barkácsolni, de eltérő az SQL logika már az adatbáziskezelők szintjén is. Plusz még különböző tábla struktúrák is, aminek megint sajátos logikája van az egyikből a másikba és a másikból az egyikbe. Egy jó programozó csapat megcsinálja neked, annyi pénzért amennyit nem fog a cég bevállalni és akkor sem lesz konzisztens, lesznek hibák, különbségek. Rengeteg munka ezt jól megcsinálni, ja és mindkét program működését teljes mértékben érteni kell.

Ha hasonló helyzetben lennék, meg sem próbálnám megígérni erre a megoldást. Ha erőltetnék, akkor benyőgnék egy olyan számot + konzultációs céget, amit biztos nem fizetnének ki. A megoldás bizony az ugrás az ismeretlenbe. Az új progit annyira le kell tesztelni, hogy egészen biztos elérje a minimális működési elvárást, mégha bugos is lesz, és egy fájdalmas lépésben váltani rá. Aztán kb 1 év mire eléri azt a szintet amit a cég elvár. Ez az ára, ha tetszik ha nem.

Ezt a moduláris átállást jóval nagyobb helyeken sem láttam még hogy bevállalta volna valaki. Esetleg ha mindkét proginak van kitesztelt APIja, és mondjuk X funkcióra elkezded használni az új megoldásodat, de mondjuk Y funkciót meg tudsz hívni még a régi rendszeren valami jól működő interfacen keresztül. Pl az újba készítesz árajánlatot, de a régibe küldöd még el a számlát és az egyik progi meg tudja hívni a másikat. Talán.

Ne haragudj, hogy nem megoldást írtam a problémára, javaslom, hogy nagyon alaposan gondold át mit lépsz, mert nagyon sok időt és pénzt dobhattok ki az ablakon, ha most rossz irányba léptek.

( pepelopez | 2013. 01. 03., cs – 19:53 )

Mi egyszer a elosztott verziókezelők ihlette adatbázis-kezelést valósítottunk meg.
Mindenki a saját lokális adatbázisán dolgozgatott és időnként beszinkronizált a központba.
Persze ez nem volt ilyen kritikus rendszer, és az ütközések feloldását rá lehetett bízni a kezelőkre.

Mind két adatbázisban "changelog" készítése mondjuk triggerekkel.
A két adatbázis changelogját egy alkalmazás aktualizálja a két adatbázisban,
és a feloldhatatlan ütközéseknél felhívja a rendszergazdát. :)))

( NoMan | 2013. 01. 03., cs – 22:55 )

Itt nem elsősorban az a gond, hogy a fejlesztő cég nem vállalja az adatmigrációt. Mint írtam 2GB-s (remélem írtam) adatbázisról beszélünk. Azt kézzel ember nincs, aki felverné az adatbázisba. Ebből kifolyólag a migráció nem kérdéses.

Sokkal inkább az a probléma, hogy a cég az átállást mielőbb szeretné megkezdeni bizonyos területeken, de vannak sarkalatos pontok, amit viszont az alapos és mindenre kitérő tesztelésig várni szeretne. De úgy látom, hogy ez egy halott ügy. A cég nem azt várja el tőlem, mint üzemeltetőtől, hogy csináljam meg a fejlesztő cég munkáját, csak mivel a két adatbázis struktúra között nem sok eltérés van - de van -, így reméltem lesz valami átfogó ötlet arra, hogy meg tudjam oldani szikronizációt legalább az egyik irányba. De úgy látom, hogy kivétel nélkül mindenki azt mondja, hogy ha már úgyis mindenki utálja az IT osztályt, akkor legalább adjak rá valós okot és ne engedjek a nyomásnak, tehát a program elkészültéig ki kell várni, majd pedig egyszerre áttérni.

Bevallom kicsit sajnálom, hogy a holnapi meetingen ezzel kell előállnom, de végülis teljesen igazatok van.

Nagyon nagy migrációknál az szokott lenni, hogy több, kezelhető méretű és bonyolultságú lépcsőre bontják a migrációt.
Minden egyes lépcsőhöz készül átállási terv, tesztelési terv (ami alapján eldöntik, hogy a lépcsőt sikerült-e meglépni), és egy visszaállási terv (ha a teszt nem nyert). Ezen tervek egyik megalkotási paramétere, hogy az átállás + teszt + esetleges visszaállás együttes ideje mekkora leállási ablakba fér bele, hiszen ezalatt az idő alatt ugye nem megy a szolgáltatás a rendszeren. Sokszor az a kialakítandó lépcsők beosztásának egyik szempontja, hogy az ügyfél által tolerált leállási ablakba beférjen egy-egy lépcső.
Ezek a tervek jellemzően nem az üzemeltetés által készülnek, hanem a migrációt végző vállalkozó által, aki jellemzően az új rendszer fejlesztője vagy szállítója. Az üzemeltetés általában nincs abban a helyzetben, hogy egy ilyen műveletet megtervezzen, a napi üzemeltetési rutin nem szokott elegendő lenni az ilyen speciális beavatkozásokhoz, míg a fejlesztő/szállító ezt általában sokszor szokta művelni.

Nem azért, de ha nem sok eltérés van, akkor én használnám a régi struktúrát, arra ráfejleszteném az új rendszert, aztán ha megvan minden funkcionalitás, akkor raknám át Postgresre. Valamivel hosszabb út, de lehet a két rendszert párhuzamosan használni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ha reggel volt a meeting, akkor már késő, de azért néhány gondolat:
- feltételezem, hogy az új rendszer szállítója más mint a régi rendszeré, de ezt nem láttam, hogy írtad volna. Nagy kérdés, hogy a régi rendszer szállítója pl. a DB sémát mint a rendszer külső interfészét definiálta-e, tehát van-e erre vonatkozó specifikáció, hogy mit hogyan tárol, vagy csak a "megnéztem, és szerintem ez a mező ezt csinálja" jellegű a dolog. Első esetben is kockázatos közvetlenül a DB-ben mókolni, második esetben orosz rulett. Ha nincs DB spec, akkor szerintem a migrációt csak a specifikált import / export megoldáson keresztül kéne csinálni, ha van rá mód.

- többször írod, hogy csak kis különbségek vannak a régi és az új rendszer által követelt DB séma között. Nekem rögtön az jutott az eszembe, hogy ha tényleg kicsik a különbségek, akkor miért nem csinál a T. újrendszerfejlesztő pár viewt, esetleg adatkonverzióhoz pár triggert. Így gyakorlatilag a régi rendszer DB-jét tudná az új rendszer is használni az átállás során, illetve a lépcsős átálláskor könnyebb visszaállni a régi rendszerre gond esetén, mert a DB-ben (jó esetben) nem történik visszafordíthatatlan beavatkozás. Nyilván ez is csak akkor járható, ha a régi rendszerhez van DB specifikáció, de a régi rendszerre a támogatást jó eséllyel elvesztitek. (Ez igaz a kétirányú syncelő megoldásra is egyébként.)

- Ha nem lehet pár viewval megoldani a két séma kompatibilissá tételét, akkor üzemeltetési és migrációs szempontból lényegtelen, hogy vannak hasonlóságok, úgy kell kezelni, hogy teljesen különbözők a sémák. Az téged nem boldogít, hogy a fejlesztőnek esetleg könnyebb dolga lesz a konverzió során.

- Ha mégis a két DB syncelése az egyetlen megoldás az átálláshoz, akkor erre az új rendszert fejlesztő cégnek kell az adott helyzetnek megfelelő speciális megoldást találnia, nem neked. Neked csak a megoldást kell véleményezned.

- Minden problémája ellenére a lépcsőzetes átállásnak szerintem nagyobb az esélye a sikerre, mint a big bang jellegű átállásnak. Amit esetleg spórolsz a big bang elsődleges költségein, azt elbukod azon, amit a másik kolléga írt, hogy kb. 1 év mire a big bang után minden a helyére kerül (KDE4 szindróma). Közben a felhasználók többsége megutálja az új rendszert, és fúrni fogják ahol érik.

- Az ilyen átállásoknál a felhasználók az egyik, sokszor elfeledett kritikus pont. Ha valóban megértik, hogy szükséges az átállás, és személy szerint a munkájuk könnyebb lesz utána, akkor könnyebben elviselik a kényelmetlenségeket, pl. akár egyes dolgok (de azért nem minden!) dupla rögzítését.

- Ezért akár olyan "félautomata" megoldás is működhet, hogy berögzíti a felhasználó a régi rendszerbe az adatot, majd átmegy az új rendszerbe, és megnyomja a nagy piros "IMPORTÁLJ!" feliratú gombot, ami a régi rendszerből az adott felhasználó által rögzített adatrekordokat áthúzza, és valamilyen felületen megmutatja a felhasználónak, aki esetleg javít benne, végül elfogadja. Így a kézzel berögzített adatok migrációja megoldódhat viszonylag kevés kényelmetlenséggel / alacsony kockázattal. Nyilván ez egy supermarket pénztáránál nem működik ... :)

Persze a pontos részletek ismerete nélkül a fentiek csak általánosságok.

Üdv,
Gergely

( tbs v | 2013. 01. 04., p – 10:04 )

Az év vége felé csináltam egy hasonlót, szintén átállási kényszer miatt 1 nagyságrenddel (~180M) kisebb db-vel:
MSSQL -> PGSQL :DDD

Gyártottam egy tcp "proxit" a db elé és pár 7ig figyeltem milyen sql-ek jönnekmennek. Oszt ezt a proxy-t lecseréltem egy okoskára, ami az sql-eket 2 irányba jdbc-zte (kézzel template-eket írtam, szerencsére megszámlálható mennyiségű van/volt) -> az eredeti az eredeti MSSQL-be és egy másolat új struktúrában (EAV, mert általános migrálnivaló lesz) Postgres-be. A júzerek (mint a tizenX :D ) nem panaszkodtak lassulásra.

Nem egy vállalatirányítási rendszer, de jönnek-mennek a bitek. Amúgy ritka nagy gányolásnak tűnik így visszatekintve... :DDD

Igen képes. Egyrészt egy XML konfig fájl tartalmazza az egyes adatbázis kezelők közötti típus konverziós definíciókat, ami módosítható. Ezen felül Tcl nyelven scriptelhető, amivel a következő funkciókat valósíthatod meg.

Customize or convert target column datatypes.
Perform advanced filtering of source data to apply to the target system.
Perform mathematical operations on target data.
Generate customized key values.
Split a source column into multiple target columns.
Perform aggregation functions on target data.
Perform advanced logging during a data replication job.
Execute SQL statements on the target database during a data replication job.
Use a variety of functions for advanced text processing.

Data Replication supports Tcl scripts for all types of Data Replication jobs, including continuous replication.

( n.balazs v | 2013. 01. 04., p – 20:20 )

A többiek már sok hasznos tanácsot leírtak, így csak kiegészíthetem őket.
Először is nagyon fontos, hogy a fejlesztő, illetve a bevezetést végző cég megfelelő tudással rendelkezzen mind a saját rendszeréről, mind a migrációról. Enélkül veszett fejsze nyele az egész projekt. Sok múlik az új rendszerrel szembeni elvárásokon.
Üzemeltetési oldalról a fenti problémát nem érdemes így megfognod. Nem érdemes egyből küldeni az adatokat az új rendszerbe is, amikor még például 1 gomb lenyomásától is homokórázni kezd, majd összeomlik az új rendszer. Ráadásul nem is megoldható, bár vannak rá célszoftverek.
Érdemes a felhasználókat aktívan bevonni az új rendszer készítésébe, tesztelésébe. Például 1-1 nap egyszerre bevinni az adatokat mindkét rendszerbe párhuzamosan. Így ők is jobban el fogják tudni fogadni az újat, te/ti is le tudjátok vonni a tanulságokat. A pilot projektet semmi esetre se hagyd ki.
A bevezetést pedig érdemes hirtelen meglépni, de NE béta állapotú rendszert vezessetek be és hagyjátok kiforrni az egészet. A hirtelent itt úgy értem, hogy 1-1 területre nézve egyszerre történjen a bevezetés, de területenként/telephelyenként/modulonként etc. bontsd lépcsőkre a teljes bevezetést. Pl: AD bevezetésnél a 30-40 gépet egy napon léptettem be a tartományba, nem húztam napokig-hetekig. Viszont a login script testreszabásánál csak 1-1 gépen/felhasználón kísérleteztem és ha ott bevált, akkor terítettem a rendszerben (először 5-6 gépen, ha minden oké, akkor az összesen).

U.i: Én pont mostanság "oltok tüzet"(részben) egy olyan rendszerben, ahol újat vezettek be, de nem végiggondolva. Mindenki csak nyűglődik vele, holott a régi rendszer legalább működött 1-2 hiányossággal, skálázhatósági problémákkal.

( pityulaman1983 v | 2013. 04. 25., cs – 10:46 )

SQL Server Integration Services, ha nem kell online.

-----------
"640GB sokmindenre elég"