Svenska Orienteringsförbundet

Inlägg i OLA > MySQL OLAx2

  • Magnus Johansson
    torsdag 9 april 2015 klockan 14:24

    Att säkra sin data är viktigt, det håller jag med om!

    Tyvärr är inget av de två sätten att görra detta på (skript som automatiskt körs regelbundet eller replikering) helt enkelt att få till bra. Det är oftast inte överdrivet svårt att sätta upp från början, men man bör ha väl genomtänkta rutiner för hur man återställer data från backupen eller fortsätter jobba med den replikerade databasen om något har hänt. Det är oftast här det brister.

    Med backupskript som körs automatiskt var tionde minut så kan man ju relativt enkelt komma tillbaka till det state man var i när senaste backupen kördes. För att sedan återskapa den data som tillkommit i systemet under tiden mellan senaste backupen och databaskraschen får man läsa in loggfilerna från de klienter där man läst av löparbrickor. Om man dessutom har vanan att skriva ned alla ändringar som sekretariatet gör i tävlingsdatabasen (t ex brickändringar, godkänna stämplingar i kartan osv) på papper så går det att återskapa även detta.

    Om man använder sig av databasreplikering slipper man som regel ifrån detta, men jag vill påstå att för den som inte är expert på MySQL så är det snäppet svårare att sätta upp. Dessutom vill jag avråda från att ha en OLA-server igång mot repliken "utifall att". Databasrepliken bör vara skrivskyddad för att hindra att någon gör ändringar i den, vilket kan leda till att replikeringen inte längre fungerar. Om man har en OLA-server ansluten mot en skrivskyddad databas riskerar man att få en massa felmeddelanden om "databasfel" i OLA om man är ansluten mot den servern, vilket kostar mer i förvirring än vad man tjänar på tiden det tar att starta en OLA-server när den behövs. Dessutom behöver ju alla klienter koppla ned från den ordinarie OLA-servern och koppla upp sig mot reserven om man använder sig av det förfarandet. Om man istället tillfälligt stoppar sin ordinarie OLA-server, pekar om den mot databasrepliken och så startar den igen så kan klienterna fortsätta där de var utan att behöva starta om eller ändra inställningar.

    Databasreplikering skyddar heller inte mot felaktiga skrivningar, t ex på grund av en bugg i OLA. Dessa sprid ju till repliken också. Så om man använder sig av replikering så tycker jag att man bör ha automatiska backupskript också, för att ha ett heltäckande skydd. Om man vet vad man gör så går det något snabbare att återställa driften till en databasreplik än om man behöver läsa in backuper.

    Med tanke på komplexiteten i replikering tycker jag att det är något som man kan lämna till de större/viktigare tävlingarna. Hit räknar jag Swedish League, SM, O-ringen och de stora stafetterna. Övriga klarar sig bra med regelbunden automatisk backup och en reservserver med installerad MySQL som man kan läsa in backupen till om så behövs.

  • Erik Engvall
    onsdag 8 april 2015 klockan 14:04

    Ok det kan ju vara en bra idé att köra två OLA-servrar mot samma databas om det är där prestandaflaskhalsen sitter. 

    Däremot tycker jag inte att backup till extern enhet med jämna mellanrum ger ett tillfredsställande skydd. Låt säga att du har 10 min mellanrum mellan backuper och att mysqlservern går ner 9 min efter senaste backup. Låt oss också anta att detta sker när det är hög genomströmning genom utstämplingen samtidigt som många kommer och ändrar bricknummer m.m. Jag tycker att du riskerar att tappa för mycket data vilket kan ge mycket extrajobb om det ens är möjligt att återskapa. Går det inte riskerar man att behöva stryka delar av tävlingen. Jag vet, jag låter som en olyckskorp och det är inte så sannolikt att detta sker, däremot är konsekvenserna för stora. En bra uppsatt replikering löser detta till stor del. Du kan naturligtvis sätta ner intervallet lägre än 10 min också men jag tilltalas ändå inte riktigt av lösningen. 

    Ur ett datasäkerhetsperspektiv tycker jag att det är bättre att du satsar på att  med hjälp av replikering eller script säkra ditt data, tappar du det så spelar det ingen roll om du har en OLA-server i backup. Så, mitt förslag är:

    1. Se till att säkra datat på mysqlservern kontinuerligt.

    2. Förbered en backupserver där du antingen kan läsa in din usbpinne eller kör en replikering.

    3. Kör du replikering kan du ha en OLA-server igång mot backupdatabasen kontinuerligt och är då snabbt uppe igen.

     

  • Magnus Johansson
    onsdag 8 april 2015 klockan 12:07

    Jo, så kan man göra. Då får man skydd mot att en OLA-server av någon anledning slutar att fungera och man fördelar belastningen på ett bra sätt.

    Du får dock INTE skydd mot att något händer med MySQL-servern. För att få till det så behöver du antingen replikering av mysql-databasen, eller ett backupskript som körs automatiskt med jämna mellanrum (och kopierar backupfilen till usb-minne!) så att du kan återställa till en annan mysql-server.

     

  • Christoffer Olsson
    onsdag 8 april 2015 klockan 11:54

    Okej Magnus

    Vi sätter upp två OLA servrar på olika datorer. Server 1 körs mot Mysql som finns lokalt på serverdatorn, IP-nr 192.168.0.1. Server 2 där vi enbart har OLA server ändrar vi i databasinställningarna så den ska köra Mysql och mot 192.168.0.1:3306/. Denna server har IP-adress 192.168.0.2.

    Händer det något med server 1 så kopplar man om alla klienter så man kör mot server 2? Kanske är bättre att ha tre olika enheter så Mysql och OLA server inte körs på samma så om en ola sever1 kraschar så rullar Mysql och server 2 så kan man koppla upp sig mot den?

    Tänker jag helt rätt?

  • Magnus Johansson
    tisdag 7 april 2015 klockan 14:02

    Det enklaste är att köra två OLA-servrar men att koppla dem mot samma MySQL-databas. Om då en OLA-server kraschar så kan man enkelt låta klienterna gå mot den andra OLA-servern. Dock har man ju då inget skydd mot att databasen stannar.

    Det finns inget enkelt sätt att sätta upp automatisk "fail-over", utan man får manuellt ställa om OLA-servrar att peka mot en fungerande databas, eller OLA-klienter att peka mot en fungerande server om olyckan är frammet.

    Replikering av databaser är inte jättesvårt att sätta upp, men man bör ha sett till att testat ordentligt innan tävlingen så man inte vaggas in i falsk trygghet. Prova att koppla ur nätverkskabeln till den dator där du kör MySQL och se att du kan få fart på OLA igen med den replikerade databasen.

    Vill man ha bättre prestanda så är bästa tipset enligt min erfarenhet att starta en extra OLA-server på en annan dator och låta den gå mot samma databas. Det sätt som Erik föreslår nedan ger också förbättrad prestanda, men det ger också risk för en del bekymmer. För att hålla data konsistent mellan huvuddatabasen och den replikerade kopian kan man inte tillåta ändringar i kopian. Det gör att om man under tävlingen kommer på att man vill ändra något från en av speakerns datorer så går inte det om de kör mot en egen databaskopia.

    "Men speakern ska ju bara visa data, inte göra ändringar" tänker någon då. Jo, i den bästa av världar är det så. Ofta inser man dock när tävlingen börjat att man behöver justera någon inställning för en onlinekontroll eller ändra ett felstavat löparnamn. Om man då sitter i speakervagnen är det ganska irriterande att behöva starta e ny OLA-klient som är kopplad mot rätt server och databas, eller att behöva springa över till sekretariatet och hitta en ledig dator där. Bättre är då att göra det möjligt att göra ändringar från alla datorer. Det är ju ofta också någon av speakern datorer som tar emot målstämplingar, varför de klienterna måste kunna skriva till databasen.

    OLA Server fungerar som en cache och tar udden av belastningen på databasen, så det är sällan databasbelastningen som är källan till att det går långsamt, utan det brukar som regel bli bra bara med en extra OLA Server.

  • Erik Engvall
    torsdag 2 april 2015 klockan 15:20

    Googla 'mysql replicating slave'. För mig är första träffen en länk in till Mysqls sida om hur man sätter upp replikering mellan två databaser. Dokumentationen beskriver replikering från A till B, dvs man ska bara läsa från B. Sedan bara att starta en OLA-server på backupdatorn som kör mot sin egen databas. Kraschar ordinare server ber man klienter att köra mot backupen istället.

    Eller, om man vill åt prestanda, låt speaker bara köra mot replikerade datat. Då slipper du en massa pollande därifrån och håller övriga nätet fritt.

  • Christoffer Olsson
    tisdag 31 mars 2015 klockan 3:25

    Vet någon hur man sätter upp så man kör med två OLA serverar som man kör på Oringen. Antar att det är typ en klient som ligger och kör så om den datorn skulle krascha så kan den andra gå in och köra.

    Är det något som man ställer in i workbench?

Annonser

Bagheera