[Løst] Beste måte å synkronisere MySQL på "live"-serveren uten å miste data?

[WillY-]

Hvilke metoder er vanlig for å synkronisere database fra produksjons-serveren til "live"-serveren når den er i bruk?

 

Først, hvordan synkronisere i det hele tatt? Med synkronisering tenker jeg da på endring av kolonner og tabeller som er gjort på utviklingsdelen. Før så pleide jeg å bare ta en mysql dump, og importere det til den andre serveren. Men dette vil jo selvsagt ikke gå når det er masse brukerdata som må ivaretas. Gjorde også et forsøk med "Toad for MySQL" sin Schema Compare, men da ble all brukerdata (rows) slettet.

Er det kanskje vanlig at man må lage scripts for hver oppdatering?

 

Et annet problem er jo å oppdatere når brukerne faktisk er på serveren og genererer data! Hvordan løser f.eks Facebook dette? Vet at de roller-ut oppdateringer prosentvis til brukere, men hvordan de gjør dette er et mysterium for meg

[Kiff]

På et sted jeg har vært med på sånt laget utviklerene en releaseplan som bl.a inneholdt alle sql endringer som måtte gjøres og så ble dette pastet inn i mysql klienten under oppgraderingen.

 

Bruk lock tables for å hindre at noen skriver til dem mens du gjør endringer: http://dev.mysql.com...ock-tables.html

Endret 9. mai 2012 av Kiff

[kalkulatoren]

Det verktøyet for MS-Sqlserver jeg har vært mest fornøyd med er Sql Examiner.

 

Ser at de også har støtte for Mysql, men jeg har ikke hatt anledning til å teste det

.

Bruker det på den måten at jeg sammenligner skjema og lager et skript som deretter kjøres på databasene som skal oppgraderes. En må uansett se litt gjennom hvilke endringer som er blitt gjort.

 

Husk backup

[Jonas]

Sett på mysql-diff? Fungerer veldig fint i små tilfeller, men er det er snakk om et stort prosjekt, så ville jeg kanskje sett litt de to øverste svarene.

[WillY-]

, men er det er snakk om et stort prosjekt, så ville jeg kanskje sett litt de to øverste svarene.

 

Likte veldig godt den løsningen der! Må nok gjøre noe sånt etterhvert. Som han ene spurte om.. er det mulig å execute en .sql fil med PHP..? Kunne jo bare tatt en file_get_contents uansett..

 

Jeg har titta litt mer på Toad for MySQL, og den sletter faktisk ikke dataen min som jeg trodde (tabellene var visst tomme fra før av ). Så Schema Compare og Data Compare i Toad er absolutt noe å anbefale!

Du kan edite sql scriptet som generes for syncing, og f.eks legge in lock tables før man executer oppdateringen.

[WillY-]

Så det var jo MySQL. Men åssen er det med PHP? Hele sida kan jo ende opp med å breake for en bruker som holder på, i mens man gjør oppdateringer på backend!

[Bolson]

For Facebook sin del ligger mye av dette i arkitekturen på løsningen. En godt designa løsning er relativt enkel å legge til ny funksjonalitet i og oppgradere funksjonalitet uten at det er stor risiko for at noe går galt. Facebook (og andre) vet også når på døgnet det har "minst" belastning i de ulike tidssonene (servere mater ofte ulike tidsoner) og kan implementere ut fra det. Og de bruker sikkert mange andre teknikker også.

 

Bruker selv en løsning hvor jeg kan oppdatere moduler, hele systemet etc på et "live system" uten at brukere oppdager at jeg gjør det (annet enn at de plutselig får ny funksjonalitet). Men det krever at man har testet godt nok - og at man faktisk har satt opp løsningen korrekt i utgangspunktet.

 

Dog velger jeg ved større oppdateringer å sperre funksjonalitet som kan medføre problemer og gjøre jobben når trafikken er svært lav. Da får man heller ikke problemer med PHP. Som oftest tar ikke slike oppdateringer mer enn 15 - 30 minutter uansett. Er jeg svært usikker på om en oppgradering går bra selv etter testing - så kjører jeg kopi og replikering/sync. Jeg lager da en kopi av eksisterende installasjon som jeg synker databasen på - gjør så alle endringer/oppgraderinger og synker databasen på nytt (+ filrepository), tester, synker på nytt og så endrer jeg bare virtual host i Apache. Før siste synk låser jeg muligheten for oppdatering av database på gammel produksjon. Siste synk og endre virtual host tar for en installasjon på 2 - 5 GB ca 2 - 5 minutter. For en ca 20 - 25 GB ca 15 - 20 minutter. Fordelen med denne måten å gjøre det på er at om det allikevel skulle vise seg at det går galt - så er det svært raskt å stille tilbake til tidligere versjon. Verktøy som brukes er rsync og SQLyog (eventuelt innebygd replikering i MySQL). Men det primære er her at jeg hele tiden utvikler på en eksakt kopi av produksjonsserver når det gjelder databasen sitt innhold (samme gjelder filrepository).

[The Red Devil]

Det kommer vel igrunnen an på størrelsen av det du utvikler mot. På mindre prosjekter er det mange løysninger man kan bruke uten at det fører til større nedetid for databasen/serveren.

 

Når du jobber mot større systemer kor det vil ta opp mot ein dag å tilbakeføre backup image til master/master og slave databasene så er det viktigt at alt blir gjort riktigt.

 

Det eg vil anbefale er at dere starter med å lage .sql filer for alle oppdateringene som blir gjort mot databasen. Ein fil for kvar "oppdatering", i.e. å legge til 4 ekstra tables er ein oppdatering osv.

 

Deretter må dere bare vite kva for nokre oppdateringer som må kjøres mot databasen for dei nye funksjonene som skal gjøres live.

 

Først kjører du oppdateringene, og deretter venter du til at dette er syncet til alle slavene, før du oppdaterer filene på web serverene (gjør dette server for server, og ikkje alle på ein gang).

 

NB. Såfremt det er muligt så er det anbefalt å ikkje modifisere i.e. les fjerne tables eller kolonner før etter at du har verifisert at alle web serverene har blitt oppdatert med dei nye filene. I.e. du fjerner gammel data etter at systemet har stoppet å bruke denne dataen.

 

I tilfelle du må modifisere data i databasen, gjør dette med SQL kommandoer eller stored procedures når det er muligt, pga. dette er fleire ganger raskere enn å modifisere det gjennom PHP. Dog. stored procedures er treigere enn PHP vist me snakker om større matte/algorithme operasjoner.

 

Når du gjør det denne veien så er det muligt å kjøre større oppdateringer "live".

 

Edit:

Angående PHP oppdateringer, vist dette er oppdateringer som "fjerner" gammel funksjonalitet, så hadde eg tatt ein og ein web server offline og deretter oppdatert, før dei er lagt tilbake til load balanceren.

 

Vist internett siden kjører på bare ein server, så legg oppdateringen opp slik at du kan kjøre den på ein gang. For eks. med å legge alle nye/oppdaterte filer i ein folder over server path. Deretter lager du ein ny kopi av config filen som inkluderer tvungen lasting av "server maintainance" siden.

 

Alt du trenger å gjøre nå er å kjøre tre move kommandoer, og du har ein maksimal nedetid på opp mot eit minutt, alt etter kor raskt du skriver.

 

Ein annen mulighet er vist du kjører cache systemer, og ingen av dei trenger å oppdateres akkurat då er å utvide kor lenge dei er aktive + tvinge systemet til å lage ein for kvar side. Deretter kan du oppdatere filene før du clearer cachen etterpå.

Endret 23. mai 2012 av The Red Devil

[WillY-]

Okay, takk for tips!!

Akkurat nå, i et så tidlig stadie, så vil det ikke ikke være noe problem med noen minutters nedetid. Men det er greit å være forberedt med andre metoder når det trengs.

Absolutt viktigste akkurat nå er å ikke miste noe data.

 

Apropos load balancer, åssen gjøres det? Bruker man et program? På en egen server?

 

Facebook har en ganske heftig prosess på det

http://www.facebook....?v=778890205865

Endret 24. mai 2012 av WillY-

[The Red Devil]

Apropos load balancer, åssen gjøres det? Bruker man et program? På en egen server?

Du trenger nok ikkje bekymre deg for dette på ein stund. Når du når opp i eit par hundre tusen unike besøkende til dagen bør du starte og vurdere dette. Som regel setter du opp ein dedikert database server løysning før du trenger fleire web servere med ein load balancer.

 

 

Du kan få load balancer software, men også dedikerte hardware løysninger. Det kan være forskjeller mellom software og hardware alt etter kva modeller web hosten har tilgjengeligt. For eksempel sender den SSL request direkte gjennom, eller åpner/leser og deretter krypterer det igjen før det er sent til web serveren osv. Hvordan dei distribuerer brukere osv. Så du bør vurdere dei opp mot kva dere trenger av funksjonalitet.

 

Som regel blir "load balancing" mellom database master servere og slave servere handert på eit kode level ved at du deler opp databasen i "stykker" også populart kalt "sharding". Det vil sei at når database størrelsen vokser, så deler du den opp over fleire servere. Dette kan du gjør både med å bare fordele tables, eller/også ved å fordele eit table over fleire servere. Deretter bestemmer den interne koden kva server(e) du trenge å koble til.

 

Problemet med "sharding" er jo selvfølgeligt at vist systemet ikkje blei skrevet med dette i bakhodet fra starten så må dere gjør eit par forandringer. Men dette kan også løysest fra database handler koden, dog mot ein prossessrings kostnad (trenger meir tid/ressurser siden du kjører regex mot queriene for å finne ut kor du skal sende den).

 

Lykke til med oppdateringene du skal kjøre, det viktigste er vist det er muligt å teste oppdateringene på eit likt oppsett. I.e. samme database, filer osv. Når du har større databaser, masse servere osv. blir dette vanskeligt og det er da TDD/Unittesting osv. blir til ein stor hjelp.