DEFREN

Login und Suche



CH Open Sponsoren

MariaDB - Migration der Kassenapplikation V-MaX

MariaDB — Migra­tion der Kas­sen­ap­pli­ka­tion V-​MaX

von Marco Weber, Lei­ter Ver­kaufs­sys­teme Post CH AG | 26.10.2016

Der Bericht fasst das Pro­jekt “MariaDB Migra­tion VMaX” aus der Sicht des Pro­jekt­lei­ters und Appli­ka­ti­ons­ver­ant­wort­li­chen grob zusammen.


Down­load Fall­stu­die als PDF (192kB)

Aus­gangs­lage

Post­stel­len & Ver­kauf (PV) setzt in rund 1400 Post­stel­len in der gesam­ten Schweiz auf mehr als 6500 Cli­ents die Kas­sen­ap­pli­ka­tion genannt V-​MaX ein. V-​MaX ist eine Indi­vi­dual­ent­wick­lung von PV und unter­stützt die Mit­ar­bei­ter an den Post­schal­tern beim Ver­kau­fen und Bera­ten von pos­ta­li­schen Pro­duk­ten wie Brie­fen und Pake­ten sowie beim Ver­kauf von Drittprodukten.

Die Daten­bank­ar­chi­tek­tur wurde bei der Ein­füh­rung von Win­dows 2000 im Jahre 2004 ent­wi­ckelt und hatte sich über viele Jahre hin­weg bewährt. Gewisse Daten­bank­pro­zesse beste­hen sogar seit der Geburts­stunde von V-​MaX im Jahre 1997 mehr oder weni­ger unver­än­dert. Ursprüng­lich ent­schied man sich vor allem auf­grund ver­schie­de­ner Sicher­heits­an­for­de­run­gen wie z.B. der ver­schlüs­sel­ten Daten­über­ta­gung für das Daten­bank­sys­tem von Ora­cle. Wäh­rend der gan­zen Jahre wurde die Daten­bank ste­tig aktua­li­siert, moder­ni­siert und den neuen Anfor­de­run­gen ange­passt.

Pro­jekt Initia­li­sie­rung

Die Idee zur Ablö­sung von Ora­cle durch ein Open Source Pro­dukt besteht seit unge­fähr 2010. Schon seit jeher sind die nicht uner­heb­li­chen Lizenz­kos­ten eine grosse Last für das Finanz­bud­get von PV und das Daten­bank­sys­tem und der Ora­cle Enter­prise Ser­ver für die Anwen­dung als Daten­spei­cher einer Kas­sen­ap­pli­ka­ton ein Over­kill. In einer Stu­die wur­den ver­schie­dene Open­Source und auch kom­mer­zi­elle Daten­bank­sys­teme unter­ein­an­der ver­gli­chen und ein Migra­ti­ons­vor­ge­hen in meh­re­ren Schrit­ten erar­bei­tet. Auf­grund der Tat­sa­che, dass vor der Migra­tion der Daten­bank zuerst das Refac­to­ring der Cli­ent Appli­ka­tion (die Appli­ka­tion wurde über vier Jahre hin­weg von Cen­tura nach Java migriert) abge­schlos­sen wer­den musste, wurde das Pro­jekt jedoch nicht sofort gestartet.

Der Anstoss zum Migra­ti­ons­pro­jekt erfolgte schliess­lich im Jahre 2014 auf­grund von Dis­kus­sio­nen rund um das Lizen­zie­rungs­mo­del von Ora­cle, wel­ches sich in den fol­gen­den Jah­ren ändern sollte. Je nach­dem, für wel­ches Modell man sich ent­schei­den würde (Anz. Instan­zen, Anz. Instal­la­tio­nen, Anz. CPU-​Core), wür­den sich die Lizenz­kos­ten um ein viel­fa­ches erhö­hen.

Eva­lua­tion MariaDB (2011, Refresh 2015)

Das Daten­bank­sys­tem, wel­ches Ora­cle ablö­sen sollte, musste eine Reihe von Kri­te­rien zwin­gend erfül­len. Es sollte sich um eine rela­tio­nale Daten­bank han­deln, wel­che ANSI SQL, ACID, Sub-​Queries, Joins, Func­tions, JDBC sowie Stan­dard Daten­ty­pen unter­stützt. Ebenso wurde dar­auf geach­tet, dass genü­gend Refe­ren­zen vor­han­den waren und eine ent­spre­chende Pra­xis bereits erprobt war. Ent­schei­dend waren auch Kri­te­rien wie Update-​Fähigkeit, Per­for­mance, Doku­men­ta­tion, Com­mu­nity und Open­Source. Und nicht zu ver­ges­sen natür­lich das Lizenz­mo­dell. Denn was man tun­lichst ver­mei­den wollte, war der Wech­sel auf ein ver­meint­li­ches Open­Source Pro­dukt, wel­ches dann in irgend einer beson­de­ren Aus­prä­gung doch wie­der Lizenz­kos­ten mit sich brin­gen würde.

Mehr als 20 ver­schie­dene Pro­dukte wur­den einer theo­re­ti­schen Prü­fung unter­zo­gen und durch Spe­zia­lis­ten bewer­tet. Zum Schluss der ers­ten Eva­lua­tion im Jahre 2011 stan­den drei Pro­dukte zuoberst auf der Liste der poten­zi­el­len Oracle-​Nachfolger: Post­greSQL, MySQL CE und Derby.

Favo­ri­siert wurde sei­ner­zeit Post­greSQL. Nach dem Anstoss zum Migra­ti­ons­pro­jekt im Jahre 2015 wurde die Stu­die (Eva­lua­tion) noch­mals aktua­li­siert, die Pro­dukte noch­mals geprüft. MariaDB als rela­tiv jun­ges Pro­dukt und Able­ger von MySQL kam neu hinzu und erfüllte die Kri­te­rien bes­ser als andere Pro­dukte. Ins­be­son­dere die Leich­tig­keit im Ver­gleich zu Post­greSQL ver­half MariaDB zum Platz eins auf der Rang­liste der Nach­fol­ge­pro­dukte. Zu die­sem Zeit­punkt wurde MariaDB auf Sei­ten der IT bereits auf eini­gen weni­gen Ser­ver Sys­te­men ein­ge­setzt, was den Ent­scheid noch­mals zusätz­lich bekräf­tigte.

Migra­tion

Die Archi­tek­tur von V-​MaX mit einem akti­ven Daten­bank­schema je Cli­ent und einem Ser­ver­schema, wel­ches nur jeweils auf einem Cli­ent einer Post­stelle aktiv ist sowie sehr kom­ple­xer Daten-​Replikations-​Mechanismen zwi­schen die­sen Daten­ban­ken und den zen­tra­len Stamm– und Bewegungsdaten-​Systemen haben uns dazu bewo­gen, die Migra­tion in meh­rere Etap­pen auf­zu­tei­len. Natür­lich hat auch der hohe Migra­ti­ons­auf­wand und die noch feh­lende Erfah­rung mit MariaDB auf Sei­ten der Ent­wick­lung wie auch dem IT Betrieb die­sen Ent­scheid gestützt. Mit einer schritt­wei­sen Migra­tion konn­ten wir das Risiko die Pro­duk­tion zu gefähr­den auf ein Mini­mum redu­zie­ren und so auch die Leute aus dem IT Betrieb in gemäs­sig­tem Tempo an das neue Pro­dukt MariaDB her­an­füh­ren.

Migra­tion, Etappe 1, Früh­ling 2015

In der ers­ten Etappe wurde die Ent­wick­lungs­um­ge­bung auf­ge­baut sowie das Basis­frame­work erstellt. Der grösste Teil des Auf­wands war die Por­tie­rung von PL/​SQL Datenbank-​prozeduren nach Java. Das Nicht­vor­han­den­sein von Daten-​banklinks in MariaDB machte zudem die Neu­kon­zi­pie­rung der Daten­über­tra­gung (Repli­ka­tion) not­wen­dig. Einige Repli­ka­ti­ons­me­cha­nis­men wur­den bereits auf eine Java Imple­men­ta­tion (CETA) umge­schrie­ben und ein­ge­setzt um die Daten der beste­hen­den Ora­cle Cli­ent– und Server-​datenbanken zu repli­zie­ren.

Migra­tion, Etappe 2, Som­mer 2015

Die zweite Etappe fiel auf­grund beschränk­ter Res­sour­cen eher klein aus. Wei­tere Teile der Repli­ka­tion sowie eine Reihe von CleanUp-​Prozessen wur­den neu ent­wi­ckelt.

Migra­tion, Etappe 3, Herbst 2015

In Etappe drei wurde die Cli­ent Daten­bank durch MariaDB ersetzt. Es wurde ein Win­dows Ser­vice ent­wi­ckelt, wel­cher den Zugriff auf die MariaDB durch andere Pro­zesse inner­halb des Netz­wer­kes ermög­licht. Der Ser­vice über­nimmt auch noch wei­tere Funk­tio­nen wie die Repli­ka­tion der Stamm– und Bewe­gungs­da­ten zur Ser­ver Daten­bank (in die­ser Etappe noch Oracle).

Die Ora­cle Cli­ent Daten­bank blieb wäh­rend der Migra­tion wei­ter­hin beste­hen, jedoch wurde diese für die Appli­ka­tion unsicht­bar gemacht. Im Falle eines Roll­backs hätte man so jeder­zeit auf die alte Ora­cle Cli­ent Daten­bank zurück­grei­fen können.

In einer Pilot­phase von rund zwei Mona­ten wurde auf 20 Pilot­post­stel­len der Ein­satz von MariaDB unter Pro­duk­ti­ven Bedin­gun­gen getes­tet. Danach wur­den die rest­li­chen Cli­ents in Tran­chen von 200400 Cli­ents pro Nacht voll­au­to­ma­ti­siert migriert.

Migra­tion, Etappe 4, Herbst 2015

In der vier­ten Etappe konnte die Migra­tion mit der Umstel­lung der Ser­ver Daten­bank abge­schlos­sen wer­den. Die Umstel­lung geschah wie­der in Teil­schrit­ten. Zuerst wur­den die Ser­ver Daten­ban­ken von 20 Pilot­post­stel­len auf MariaDB umge­stellt und wäh­rend zwei Mona­ten beob­ach­tet, bevor man dann die rest­li­chen Ser­ver Daten­ban­ken wie­derum voll­au­to­ma­ti­siert über meh­rere Nächte ver­teilt migrierte.

Betrieb

Die Erfah­run­gen aus dem Betrieb sind durch­wegs posi­tiv. Die Kas­sen­ap­pli­ka­tion läuft auch auf der MariaDB mit der­sel­ben Per­for­mance wie vor­her auf der Ora­cle DB. Der Anwen­der merkt kei­nen Unter­schied. Aus­führ­li­che Pro­zess­zeit­mes­sun­gen bestä­ti­gen dies. Auch die Leich­tig­keit der MariaDB macht sich posi­tiv bemerk­bar. Die leere, kom­pri­mierte DB ist 1.7MB gross (vs. >100MB bei Ora­cle) und lässt sich bei Bedarf sehr schnell neu instal­lie­ren.
Aus Sicht der IT läuft der Betrieb der MariaDB heute rei­bungs­los. Es muss­ten wäh­rend der Migra­tion eine Viel­zahl von Über­wa­chungs– und Ana­ly­se­tools umge­schrie­ben wer­den. Durch die etap­pen­weise Migra­tion blieb dafür jedoch genü­gend Zeit. Natür­lich sind wir mit dem Ein­satz von MariaDB auch auf einige Ein­schrän­kun­gen und Schwie­rig­kei­ten gestos­sen. Hier bei­spiel­haft zwei Erkennt­nisse aus der Umstellung:

  • BIG­DE­CI­MALS, JDBC UND EQUALS
    Im Gegen­satz zum Ora­cle JDBC Trei­ber lie­fert der MariaDB JDBC Trei­ber beim Lesen von Big­De­ci­mals ab Daten­bank immer Werte mit der voll­stän­di­gen Prä­zi­sion gemäss Daten­bank Defi­ni­tion. Diverse Stel­len im beste­hen­den Code muss­ten auf­grund des­sen kon­se­quent ange­passt werden.

  • Cha­rac­ter Set End­co­ding
    Unsere zen­tra­len Ora­cle Daten­ban­ken wer­den mit Cha­rac­ter Set latin1 betrie­ben, die MariaDB Daten­bank wurde direkt mit UTF8 Enco­ding instal­liert. Dies führte zu eini­gen eigen­ar­ti­gen Feh­ler­mel­dun­gen beim Repli­zie­ren von Stamm­da­ten ab Ora­cle Daten­bank zu den MariaDB’s in den Post­stel­len. Die Pro­ble­mur­sa­che konnte schluss­end­lich auf Spe­zi­al­zei­chen im Bereich von Uni­code 0×80 bis 0x9F zurück­ge­führt werden.


Fazit

Obwohl der Auf­wand für die Pla­nung und Durch­füh­rung der Migra­tion sehr gross war, über­wie­gen zum Schluss die dar­aus resul­tie­ren­den Vor­teile. Zum einen sind dies die ein­ge­spar­ten Lizenz­kos­ten, wel­che die Auf­wen­dun­gen inner­halb weni­ger als drei Jah­ren wie­der zu kom­pen­sie­ren ver­mö­gen. Zum ande­ren konn­ten wir diverse Alt­las­ten wäh­rend der Migra­tion ablö­sen und den Zugriff auf die Daten­bank wei­test­ge­hend pro­duk­te­un­ab­hän­gig auf­bauen. Soll­ten wir irgend­wann gezwun­gen sein das Pro­dukt wie­der­er­war­ten wech­seln zu müs­sen, so wird der Auf­wand um ein viel­fa­ches klei­ner sein als bei der Migra­tion auf MariaDB.



Weiterführende Informationen aus dem OSS Directory

MariaDB

Software-Entwicklung / Datenbanken und Filesysteme
7 Firmen, 2 Referenzen


MariaDB ist eine am schnellsten wachsende Datenbank. Geschaffen von den Gründern des legendären MySQL-Projekts, definieren die Personen und Organisationen hinter MariaDB die Datenbank neu, ...

» Mehr
Letzte Aktualisierung: 01.12.2016  -  Anzahl Ansichten seit dem 01. April 2013: 123
Erstellt: 14.01.2014

Mitgliedschaft bei /ch/open

Der Vorstand der /ch/open wird jährlich an der Mitgliederversammlung gewählt und arbeitet vorwiegend ehrenamtlich. Werden Sie Mitglied des Vereins /ch/open und unterstützen Sie die Förderung von Open Source Software in der Schweiz.

Einzelmitgliedschaft
Für alle, die persönlich die Anliegen und Aktivitäten von /ch/open unterstützen und kostenlos an Abendveranstaltungen und am Open Business Lunch teilnehmen möchten.
CHF 100.– pro Jahr

Einzelmitgliedschaft für Personen in Ausbildung
Personen in Ausbildung erhalten eine Ermässigung des Mitgliederbeitrags.
CHF 20.– pro Jahr

Kollektivmitgliedschaft
Für Unternehmen, öffentliche Verwaltung, Schulen und andere juristische Personen: Alle Mitarbeiter solcher Organisationen geniessen die gleichen Möglichkeiten und Vergünstigungen wie Einzelmitglieder. Eine definierte Kontaktperson erhält alle Korrespondenz.
CHF 450.– pro Jahr

Sponsormitgliedschaft
Für Mitglieder, welche die Anliegen der /ch/open besonders unterstützen möchten: Sponsormitglieder können Anfang Jahr am /ch/open Sponsoren-Dinner teilnehmen, werden auf der /ch/open Website und dem Portal www.opensource.ch mit Logo aufgeführt, in allen Mailings namentlich mit Link erwähnt und können beliebig viele Projekte und Referenzen im OSS Directory verlinken.
CHF 1000.– pro Jahr

Die Anmeldung für die Mitgliedschaft, die Vereinsstatuten sowie viele weitere Informationen sind auf der Website zu finden:
http://www.ch-open.ch/anmeldeformular_mitgliedschaft/

Twitter Feed







Links

Über unsNewsletterKontaktNutzungsbedingungenCH Open Initiativen