Hei!
Jeg prøver å sette opp unison (synkronisering mellom tre servere) for å synkronisere filer mellom tre servere.

Men mitt problem er:
Når jeg først lager en tabell, lager den jo noen filer i /var/lib/mysql/databasenavn, og da blir det synkronisert til de andre serverne. Det fungerer jo flott.

MEN:
Når jeg inni tabellen oppdaterer noe, ser det ikke ut som "Dato endret" blir oppdatert i det hele tatt. Derfor synkroniserer heller ikke unison filene.

Ja, jeg vet at jeg kan sette opp replikering, men det er ikke aktuelt her, da det også gjelder andre mapper, som f.eks. /var/www, /var/vmail osv osv.

Noen som vet hva som egentlig skjer?

Uhm, det slår meg at det å synkronisere databasefiler på den måten du prøver er egna til å lage katastrofe. Kva om du forsøker å synkronisere midt i ein skriveoperasjon, slik at fila vert korrupt? Som eit minimum bør vel databasetenaren ikkje køyre i det du kopierer filene. Bruk mysql sine replikeringsmekanismer?

Det du gjør nå er heller ikke aktuelt, bare slutt med tanken først som sist. Nekter du å bruke replikering får du nesten heller dumpe databasen og så importere dumpen igjen på slavene.

slashdot har faktisk rett her, jeg tok det for gitt at unison sjekket om filene var låste eller ikke først. Men hensikten forsvinner jo når databasen får større og større trafikk (dvs, flere spørringer, dvs, fila blir "aldri" ledig).

Men så kommer vi til problemet hvor jeg i dette tilfellet MÅ sette opp master-master-master replication, noe som ikke er mulig. master-master derimot.

Og når vi tenker på circular replication har vi også et problem:
Hvis en server går ned og er nede i f.eks. 1 time, vil ikke den oppdatere seg etter de to andre serverne som er oppe når den rebooter.

Kan med glede fortelle dere at det løste seg ved å sette opp circular replication. Det var bare å sette opp offset på alle serverne, slik at ingen oppføringer får samme ID

Du har ikke bruk for master-master-master, så enkelt er det. Hvis du har behov for high availability så vil en master-master, med slaves være et godt alternativ. MySQL og replikering er litt black magic, og du risikerer ganske fort split brain om du ikke holder tunga rett i munnen. For skalering vil det være bedre å benytte seg av slave-noder som kun leser data.

Men så er meningen her at serverne skal stå i et cluster. Dvs, samme faen hvilken man bruker, endringen blir gjort overalt.

Yep, men du burde nok lese litt om alle faremomentene ved bruk av master-master replikering, spesielt når det er snakk om flere enn to. Du kan gjøre mye fancy med offset, men det er et ganske kjent fenomen at det bare dør på seg selv, helt uten videre. Hva gjør du om du har nettverksbrudd mellom nodene f.eks? Er det noe som også forteller applikasjonen å slutte å bruke serveren som de andre to tror er nede?

Heisann!
Så vidt jeg har oppfattet det, om jeg har oppfattet ting riktig:

Starter med siste spørsmål:
DNS. Det er oppført flere servere i DNS. Hvis en server ikke svarer, vil den jo automatisk gå videre til neste oppføring, og da vil den svare.

Første spørsmål:
Man kan derfor legge inn informasjon i MySQL, og når tilkoblingen er gjenopprettet vil den serveren som gikk ned automatisk oppdatere seg etter dens master.

Men så er det jo et problemscenario her:
Hvis en av nodene går ned, blir jo det slik:

- Man legger inn data enten på en av de to andre serverne.
- Da blir det bare en server som inneholder den korrekte informasjonen, mens nr 2 og nr 3 ikke vil bli replikert, fordi nr 2 er nede, og nr 3 mottar jo informasjon fra nr 2, som igjen mottar informasjon fra nr 1.
Det vil si at dersom en bruker er "uheldig" og aksesserer nr 3, vil han ikke ha den oppdaterte informasjonen.

DERFOR har jeg laget et skript som gjør følgende:
Ping-tester serveren 3 ganger, ved svar, prøv å nå MySQL-serveren. Hvis OK, fortsett. Hvis ping feiler, venter den 30 sekunder før den prøver igjen. Feiler den igjen da, går også master-serveren til den som er nede også ned. Det betyr at kun en server er oppe i det tilfellet. Når de andre går opp igjen, oppdaterer de seg etter den ene som er oppe.

Du lurer på poenget ved det hele?
Poenget:
Hvis det er en kritisk feil, som f.eks. harddiskkrasj på en av serverne, vil ikke det bli merket, og en server kan derfor være oppe til jeg fikser det.

Håper bare dette ble forstått.

Er åpen for synspunkter på dette oppsettet også, forresten.

Problemene oppstår når selve replikeringen tryner, og du har et split brain-problem, hvor flere noder sier de har nyeste data. Du kan motvirke dette problemet i MySQL med å sette replication offset, men det har vist seg litt for mange ganger å bare dø på seg selv helt uten videre. Hvis du skal gjøre dette på en sikker måte så vil det være bedre å forholde seg til en master og flere slaver. Du vil aldri kunne sikre deg helt for nedetid, og slik replikering som du driver med nå kan fort føre med seg langt mer nedetid eller direkte tav av data om du er virkelig uheldig.

Heisann!
Det er konfigurert replication offset, ja

Problemet mitt med å ha kun en master er at dersom noen oppdaterer noe på slavene, vil ikke masteren bli oppdatert etter slaven, og da forsvinner egentlig hele poenget med redundans. Eller har jeg misforstått noe? (Ja, har testet, slaven oppdaterer ikke til master)

nei, du har ikke misforstått, slaver leser kun fra master og ikke motsatt.

Om du vil ha redundans setter du opp to servere i en master-master-konfigurasjon, dersom du får ytelsesproblemer fordi du "bare" har to dbservere setter du i tillegg opp en pool med slaver som leser fra master-serverne

I tillegg sørger du for å implementere et eller annet backup-script slik at du ikke mister for mye data den dagen noe går til helvete

Det fine med et "master-slaver" er at du ganske fort kan ta failover til en slave, slik at den blir en master, og med fornuftig overvåking vil det gi deg minimal nedetid, samtidig som du sørger for integreteten til dataen din. Slik oppsettet ditt er i dag så er det bare et tidsspørsmål får det hele dør på seg, og da måler du ikke nedetid i minutter, men hvor fort du klarer å manuelt lese binloggene dine.

Det er egentlig bare en avveiing du må ta, kan du takle et par minutter nedetid hvis det er hardware-relaterte problemer, eller kan du takle å miste all data som har blitt skrevet siden sist gang du tok backup? Jeg vet hva jeg ville valgt.

Du kan automatisere det med f.eks. heartbeat, men automatisering har et nytt sett med problemstillinger, så god varsling og manuell failover vil være det beste alternativet, med mindre du har ekstreme behov for oppetid.

OK, tusen takk for dine bidrag gjennom tråden

Har nå funnet ut av en genial konfigurasjon, skal oppdatere tråden med resultatet når jeg er 100% ferdig