Mysql-replikering af individuelle tabeller. Opsætning af Master-Slave-replikering i MySQL

Min rapport er beregnet til de mennesker, der kender ordet "replikering", endda ved, at MySQL har det, og måske har de oprettet det én gang, brugt 15 minutter og glemt det. De ved ikke andet om hende.

Rapporten vil ikke indeholde:

Alt dette er på internettet, der er ingen mening i at forstå syntaksen.

Vi vil gennemgå teorien lidt, forsøge at forklare, hvordan det hele fungerer indeni, og derefter kan du selv dykke ned i dokumentationen med tredobbelt styrke.

Hvad er replikation i princippet? Dette kopierer ændringer. Vi har en kopi af databasen, vi vil have en anden kopi til et eller andet formål.

Replikering kommer i forskellige typer. Forskellige sammenligningsakser:

• grad af synkronisering af ændringer (synkronisering, asynkron, semisync);
• antal optageservere (M/S, M/M);
• ændre format (udsagnsbaseret (SBR), rækkebaseret (RBR), blandet);
• teoretisk set en model til at overføre ændringer (push, pull).

Sjovt faktum - hvis du tænker lidt over det, hjælper replikering os teoretisk med at skalere læsning af grundlæggende årsager. Her er en noget ikke-indlysende konklusion. Dette skyldes, at hvis vi skal uploade et vist antal ændringer til den samme kopi af data, og denne specifikke kopi af data serveres af den samme server, så er denne server i stand til at modstå et vist antal opdateringer pr. sekund, og nej mere vil blive uploadet der. Serveren er i stand til at opdatere 1000 poster i sekundet, men ikke 2000. Hvad vil ændre sig, hvis du placerer en replika til denne server, uanset i master-slave eller master-master mode? Vil du være i stand til at hælde to tusinde opdateringer på denne replika? Det rigtige svar er nej.

Selvfølgelig kan du tilføje yderligere opdateringer til en replika i master-master-tilstand, men en anden ting er, at når de ikke ankommer til den første master og forsøger at lave to tusinde opdateringer på den, vil kapaciteten ikke længere være nok . Du skal forstå og ikke forveksle to næsten indlysende punkter, at replikering handler om én ting, men at data skal opdeles, og hvis du skal skalere ikke at læse, men at skrive, så bliver du nødt til at gøre noget andet, og replikering vil ikke hjælpe meget.

De der. replikering handler mere om læsning.

Om synkronisering.

Synkronisering er en garanti for tilgængelighed og tilgængelighed. Tilgængelighed i den forstand, at vores commit er bestået, transaktionen er begået, alt er i orden, disse data er synlige for en eller flere noder i klyngen, de kan deltage i følgende anmodninger. Tilgængelighed betyder, at dataene i princippet er på mere end én server, men måske er transaktionen ikke gået tabt og ikke tilgængelig.

Der er ingen "forpligtelse lykkedes, hvad betyder det?"-afståelse her. Synchronous commit betyder, at vores lokale og eksterne (mindst på én replika) er afsluttet, dvs. vi har forpligtet noget til maskinen, hvis vi har synkron replikeringstilstand, så blev disse ændringer gennemført, de er synlige for efterfølgende anmodninger på den lokale maskine, og de er også synlige på den eksterne maskine (mindst én). Det betyder, at hvis der opstår en standard nødsituation, dvs. et koben fløj ind i en af ​​serverne og gennemborede alt lige igennem - fra processoren til selve skruen, så på trods af dette bliver dataene ikke kun kopieret til en bestemt fjernserver, men kan desuden øjeblikkeligt uden evt. yderligere forsinkelser, deltage i efterfølgende transaktioner.

Dette er alt sammen generel terminologi og har absolut intet at gøre med MySQL. I ethvert distribueret system vil det blive arrangeret sådan.

Asynkron commit - ingen yderligere garantier, afhængigt af dit held.

Semi-synkron commit er en fin mellemløsning, det er når vores lokale commit er bestået, intet vides om remote commit - måske indhentede slaven, eller måske gjorde den det ikke, men i det mindste fik vi bekræftet at disse data er et eller andet sted så fløj de væk og blev accepteret der og sandsynligvis tilmeldte sig.

Om optagelsesservere. Hvilke typer replikering er der?

Master-slave classic, ændringer hældes alle på én server, hvorefter de kopieres til en masse replikaer.

Mester-mester sand - når ændringer strømmer ind på en flok mestre samtidigt og på en eller anden måde fra den ene til den anden, fra en anden til en tredje og mellem dem alle, hvilket giver anledning til både en række glæder og en række automatiske problemer. Det er klart, at når du har én "gyldne kopi" og flere replikaer fra den, som (ideelt - øjeblikkeligt) skal gentage denne "gyldne kopi", så er alt relativt enkelt med hensyn til, hvordan man kører data frem og tilbage og hvad gør på hver specifik kopi. Med master-master begynder en interessant "hovedpine", og jeg understreger, ikke specifikt i tilfældet med MySQL, men rent teoretisk. Hvad skal man gøre, hvis de på to noder på samme tid forsøgte at køre den samme transaktion, hvilket ændrer de samme data, og for eksemplets skyld ændrer det på forskellige måder. Det er klart, at vi ikke kan anvende disse to ændringer på samme tid. I det øjeblik, hvor vi begynder at ændre noget på en node, er der endnu intet på den anden node. Konflikt. En af transaktionerne skal rulles tilbage. Derudover begynder separate "danse" med at tjekke ure osv.

Et interessant punkt - selv muligheden, hvor alle ændringer fra alle mastere gradvist skal spredes overalt, vil stadig ikke hjælpe med den samme skrivebåndbredde. Det er ærgerligt, men sådan er det.

En god mulighed kaldes "Master-slave + routing requests". Det er rart, fordi det er nemt at programmere indeni, du har én hovedkopi, du kopierer den til en masse maskiner. Dette er meget enklere end i et master-master-miljø, hvor alle har lige rettigheder osv., men set fra et applikationssynspunkt ser det stadig ud til, at du har mange skrivepunkter. Du kommer til en hvilken som helst node, den ved, hvor den skal rute dig, og ruter dig med succes. Nå, aflæsninger skaleres - det er glæden ved replikation. Du kan altid læse alt fra alle punkter.

Nu tættere på databaser, "magiske" sætningsbaserede, rækkebaserede osv. formater. Om formatet af ændringer.

Hvad kan du gøre? Du kan sende selve forespørgslerne, eller du kan kun overføre de ændrede rækker. Jeg understreger, at selvom vi endnu ikke er dykket ned i MySQL-junglen, kan dette gøres af enhver DBMS, der har forespørgsler, der genererer et stort (eller ikke særlig stort) antal ændringer, dvs. opdatering af en masse data. Spørgsmålet opstår - hvad præcist vil vi kopiere? Du kan sende selve anmodningerne frem og tilbage mellem noder, eller du kan kun sende de ændrede data. Det er interessant, at begge veje er meget dårlige! Du kan stadig prøve at blande.

Endnu et punkt om, hvilke typer af replikationer der er. Om distributionsmodellen. Sandsynligvis et eller andet sted er den Push-baserede model endnu ikke helt uddød, når den node, der har lavet ændringerne, er forpligtet til at sende dem til alle andre noder. Fra et synspunkt om programmerings- og sporingstilstande er dette stadig et besvær. Det er derfor Pull-baserede regler. At tage opdateringer fra en eller anden node er meget nemmere at programmere end at overvåge en kaotisk klynge af dens replikaer på én node.

Nogle generelle udtryk blev introduceret. Lad os gå videre til, hvordan vi gjorde det i MySQL.

MySQL er i sig selv en slags bedrag. Der er et logisk lag kaldet MySQL, som beskæftiger sig med alle mulige generelle ting, der er isoleret fra datalagring - netværk, optimering, caches mv. Det specifikke fysiske lag, som er ansvarlig for lagring af data, ligger en etage under. Der er flere indbyggede, og nogle er installeret af plugins. Men selv den indbyggede MyISAM, InnoDB osv. leve på det fysiske lag. Plugin-arkitektur er cool, du kan hente en ny motor, men der opstår straks en vis suboptimalitet. I princippet ville transaktionsskrivningslog" og (WAL), som det fysiske lagerlag skriver alligevel, være gode at bruge til replikering, og hvis systemet ved, at der er et bestemt fysisk lag, eller er godt nok koblet til dette. fysisk lag , så ville det være muligt ikke at skrive en separat log på det logiske niveau, men at bruge samme WAL... Men med MySQL er dette konceptuelt umuligt, eller hvis man ændrer interfacet i PSE, så det bliver muligt konceptuelt , så bliver der meget arbejde.

Replikering implementeres på selve MySQL-niveau. Det er der også godt i - udover én log i form af dybt interne data i lagermotoren, er der en mere eller mindre logisk log, måske på sætningsniveau, som vedligeholdes adskilt fra denne motor.Og dette er "ekstra" sikkerhed osv. plus, da der ikke er nogen interne begrænsninger, kan du gøre enhver kreativ ting som at udskifte motoren i farten.

I disse vilkår implementerede MySQL 4.1: master-slave, pull-baseret, strengt asynkron og strengt SBR. Hvis du sidder fast i den ældgamle 4.x-æra, så er tingene sandsynligvis dårlige for dig. Versioner 5.x er allerede næsten 10 år gamle - det er tid til at opdatere.

Det er sjovt at følge versionerne af, hvordan folk trådte på alle slags river, og når intet kunne gøres, skruede de nye river på disse river, så livet ikke ville være så smertefuldt. Så i version 5.1 tilføjede de RBR for at kompensere for de uundgåelige problemer med SBR og tilføjede en blandet tilstand. I version 5.6 tilføjede vi nogle flere fine ting: semi-synkronisering, forsinket slave, GTID.

En ting mere. Da MySQL på den ene side er en slags fælles lag og en masse pluggbare motorer på den anden side, inklusive indbyggede, er der fra et vist punkt en guddommelig NDB-klynge, som de siger fede ting om. Der er fuldstændig synkron master-master-replikering, en meget tilgængelig database i hukommelsen... Men der er en advarsel - så snart du begynder at lede efter folk, der bruger NDB-klynge i produktionen, er der meget få sådanne mennesker.

Hvad gør masteren, når du beslutter dig for at aktivere replikering? Der foregår en del ekstra bevægelser i masteren. Som sædvanlig modtager vi anmodninger over netværket, analyserer dem, sender transaktioner, registrerer dem osv. Ud over dette, på det logiske niveau af MySQL, begynder mesteren at vedligeholde en binær log - en fil, ikke helt en tekst, som alle ændringer hældes i. Masteren kan også sende disse logfiler over netværket. Det hele er meget enkelt og ser ud til at virke.

Hvad laver en slave? Det er bedre ikke at sende ændringer til slaven, for du kan komme ind i noget uforståeligt. Slaven har lidt mere arbejde. Udover at holde en ekstra log og sende den ud efter anmodning, er der også en tråd, der går til en remote master, måske endda mere end én, og downloader en binær log derfra Løsningen er "lad os gå til og fra flere remote masters "downloading different logs" er tvetydigt. På den ene side er det ikke dårligt, men på den anden side er der en øjeblikkelig uoverensstemmelse. Du kan ikke bare fysisk kopiere filer via SCP, du får allerede en log på serveren, den indeholder dine egne positioner, lokalt trækker vi dem langs gitteret, lægger dem i en separat log, der kører også en separat tråd og forsøger at spille disse lokale logs. Det mest helvede efter min mening er, at indtil version 5.6, identifikation af en bestemt transaktion i loggen skete ved filnavnet og positionen på masteren. En interessant løsning.

Her er skrivestien, som en simpel indsættelse tager uden replikering:

Applikationen sluttede til serveren, læg den i tabellen og afslut.

Med replikering er der flere yderligere trin:

Writer-applikationen går til masteren på samme måde, men derudover ender disse data i en eller anden form i den binære log, downloades derefter over netværket til relæloggen, hvorefter den gradvist afspilles fra relæloggen. (hvis vi er heldige og slaven ikke halter, afspilles straks) ind i en tabel på slaven, hvorefter alt er tilgængeligt i læseren.

Hvad der præcist ender i den binære log afhænger af SBR/RBR/mixede indstillinger. Hvor vokser alt dette fra? Lad os forestille os os selv som en database. Vi modtog en simpel anmodning "opdater en specifik post" - OPDATER brugere SET x=123 WHERE id=456

Hvad skal man skrive til binær log? I princippet er det hele det samme, egentlig. Vi kan skrive en kort anmodning ned, eller (og han opdaterede en post) vi kan skrive ændringen ned på en eller anden måde i et eller andet format.

En anden situation. Lad os forestille os, at vi modtog den samme anmodning, som i sig selv er lille, men ændrer en masse data - OPDATERING brugere SET bonus=bonus+100

Der er kun én effektiv mulighed - at skrive selve anmodningen, fordi anmodningen er præcis 32 bytes, og den kan opdatere et vilkårligt antal poster - 1000, 100.000, 1.000.000, så mange du vil... Det er ineffektivt at skrive ændrede poster til loggen.

Hvad sker der, hvis vi sætter sådan en simpel anmodning i loggen: "lad os deaktivere alle brugere, der ikke har logget på i lang tid" - OPDATERING brugere SET disabled=1 WHERE last_login

Pludselig sætter rædselen ind. Problemet er, at hvis selve anmodningen er ideelt replikeret, så er tiden for det første aldrig synkron mellem de to noder, desuden på grund af det faktum, at optagestien er så lang, på tidspunktet for genafspilning af dette "NU" vil afvige. Replikaen afviger pludselig fra mesteren, og alle efterfølgende ændringer, formelt set, er ikke længere sikre og kan føre til hvad som helst.

Generelt set, for sådanne forespørgsler, uanset mængden af ​​ændrede data, ville det ideelt set være nødvendigt at kopiere selve linjerne. I dette særlige tilfælde kan du ikke kopiere selve linjerne, men rette konstanten og skrive i loggen ikke "NU", men det specifikke tidsstempel, der blev brugt af masteren på replikeringstidspunktet.

Sjove fakta, du ved et uheld lærer, mens du dykker ind i replikationsjunglen. Desuden kan du dykke lavvandet - du støder på dem med det samme. I tilfældig rækkefølge er de:

• Masteren er flertrådet, men slaven er det ikke. Det er klart, at hvis masteren hælder en belastning i fire kerner, har slaven ikke tid til at hælde denne belastning i en kerne. Det hele er ret dårligt;
• Slavens tilstand bestemmes af navnet på positionen i masterfilen. Tænk over det - tilstanden af ​​en node i klyngen bestemmes af navnet på filen og positionen i denne fil på en anden node i klyngen, med hvilken alt kan ske uanset årsag!
• "gemmer" RBR. Det viser sig, at der som standard skrives de fulde før/efter rækkebilleder der, dvs. vi ændrede en kolonne i en fem-kilobyte streng, ups! – 10 KB trafik og 20-40 bytes overhead for denne linje, så ups! - der er sådan en fed linje fra den tidligere version, ups! – herefter er der en version med nye værdier. Administratorer hyler i kor! Dette er dog bare fantastisk set fra nogle perverterede applikationers synspunkt, for eksempel eksterne læsere, der forsøger at tilslutte sig MySQL-serveren, trække data fra den og gøre noget med dem, for eksempel sætte den i en fuld- tekstindeks. Så slemt som det er set fra databaseadministrationens synspunkt, hvor en ændring pr. tre bytes genererer 10 KB trafik på skruen og derefter 10 KB netværkstrafik for hver slave, så er det lige så godt for alle systemer som f.eks. som fuldtekstsøgning, som Sphinx, hvor der ikke er nogen lokal kopi af dataene, og der ikke er noget ønske om at implementere MySQL fra bunden. I MySQL 5.6 indså de det og lavede binlog_row_image (men som standard fuld, ikke minimal eller noblob).

Kort sagt, alt er ikke smart arrangeret - en pind, et reb, en log, en anden log. Og selv i denne log er "barndoms" sygdomme ret sjove:

For en person, der har brugt replikation i to dage, er alt dette skræmmende og svært. Men ved, hvor enkelt det er, i princippet, er det klart, hvordan man skal leve med det:

• Først og fremmest tror vi ikke på misligholdelser;
• Vi kigger nøje på indstillingerne, tænker over, hvad vi ønsker - SBR, RBR mv.

Og det er bedre at sætte det op med det samme, så du ikke behøver at sortere den mærkelige fars fra senere.

I situationen "loggen er beskadiget, positionen er divergeret, det vides ikke, hvad der sker," er der en vis værktøjskasse - vi ser på begivenheder, forsøger at forstå, hvilken transaktion der allerede er gået igennem, hvilken ikke har, om dette det hele kan gemmes eller gendannes osv. Hvis GTID “Hvis du nåede at tænde den på forhånd, så bliver livet lettere.

Et andet punkt i at observere replikation. Det er interessant at se, hvordan den interne skæve struktur provokerer ikke kun konkurrence, men skabelsen af ​​yderligere produkter. Den "magiske" Tungsten Replicator, siger de, løser godt problemet kaldet "en enkelt-trådet slave er dårlig", og hvis ikke for de iboende vanskeligheder, ville der ikke være noget yderligere produkt, der giver dig mulighed for at bruge denne mekanisme, overføre data til andre systemer på den ene side og samtidig løse en række problemer indbygget i det eksisterende system på den anden side.

Som sædvanlig er det umuligt at give råd. Det hjælper nogle, andre vil spytte meget. Men de siger, at der er situationer, hvor Tungsten klarer det uundgåelige enkelttrådede lag godt. Jeg er sikker på, at der er andre interessante tricks derude, men en intern single-threaded slave er svær.

Hvad skal du gøre, hvis du af en eller anden grund brugte replikaer som backup? Jeg synes, man skal banke hovedet mod væggen, for en replika og en backup er to forskellige ting. Men hvis du er kreative fyre og bruger en ret ny version, vil forsinket replikering redde dig på den ene side, men på den anden side, hvis du ikke laver fuld backup, vil intet redde dig alligevel.

Dernæst er et andet element af kreativitet. Det er ikke svært at forestille sig en situation, hvor masteren fyldte hele 10 PB cloud disken med logfiler eller fyldte hele netværket ved at sende disse logs, mens vi ikke har brug for 90% af disse opdateringer, fordi vi er interesserede i at replikere, for eksempel én tabel på syne eller én database på syne, og som standard hælder alt ind i den binære log - alle ændringer på tværs af alle databaser, på tværs af alle tabeller, på tværs af alt. Løsningen forbløffer igen med sin kreativitet. På den ene side er der fire indstillinger - (binlog|replicate)_(do|ignore)_db, som giver dig mulighed for at filtrere på masteren, hvad der vil blive skrevet til loggen, og hvad der vil blive ignoreret. På slaven giver det dig derfor mulighed for at gøre det samme. De der. på masteren kan vi filtrere, hvad der går ind i den binære log - ind i denne tragt, som så flettes ind i netværket, og på slaven kan vi følgelig sætte et indgående filter på, hvad der kommer fra netværket. Eller skriv kun en del af dataene til disken, og afspil derefter igen kun en del af dataene på slaven. Pludselig, selv i denne simple historie, sætter rædsel ind, fordi kombinationen - vi bruger en database og opdaterer tabellen i en anden database ved hjælp af en interessant syntaks - den opfører sig på en eller anden måde... Og hvordan den præcis vil opføre sig er ukendt, fordi forskellige filtre udløses på forskellige tidspunkter.

Der er ingen indbyggede pæne ting, der kaldes "genvalg af mesteren, hvis han pludselig dør", du skal hæve det med dine hænder. Manglen på værktøjer til klyngeledelse - det er efter min mening godt - giver anledning til konkurrence, giver anledning til skabelse af yderligere produkter. Faktisk, hvis den meget seje master-master replikering fungerede perfekt i almindelig MySQL, eller i det mindste automatisk gendannelse efter fejl, hvorfor skulle alle Galera, Percona/MariaDB Cluster osv. så være nødvendige?

Et par flere tricks. En interessant implementering er replikering, som er så simpelt som pind og reb, uden nogen kontrol på den ene side og uden nogen værktøjer til at gøre det mere behageligt at styre klyngen af ​​en replikerende slave, på den anden side. Det her er slemt. Men du kan manuelt forme så interessante konfigurationer ud fra dette, at alle, der senere kommer og skiller det ad for dig, vil gyse.

Konfiguration nr. 1. En master-master "på knæet" i MySQL-stil udføres sådan:

Det skræmmende er, hvor mange idioter der er i verden! Google "Master-master MySQL-replikering" - hvert andet link er sådan her. Helvede og Holocaust.

Fokus nr. 2 – catch-all slave – er mere behagelig. Der er ingen unødvendige kontroller - hvad flyver fra hvem, hvem får det, og hvad skal man gøre med det. På grund af dette kan du lave sjove ting som en slave, hvorpå enten en del af data fra en flok servere er præcist flettet sammen, eller alle data fra alle servere er præcist flettet - en server med alle backups. Men, jeg gentager, der er replikation, dvs. Der er et bestemt grundlæggende værktøj, der kopierer tabel A i stedet for B, og det er det.

Og endelig trick nr. 3 – vi udskifter alt. Lad os huske, at replikering lever på det logiske niveau, hvilket på ingen måde er forbundet med det fysiske lagerniveau. På grund af dette kan du skabe ekstremt interessante underlige ting. Du kan ændre motoren "on the fly" til uklare formål - her er en sand historie, at, de siger, replikering fra InnoDB-databaser til MyISAM-tabeller, bare så fuldtekstsøgning fungerer på en eller anden måde. Der er et kreativt trick kaldet "skemaændring via replikering". Jeg nægter at forstå, hvad fedtet er, men der er sådanne tricks. Nå, der er en klar og interessant funktionsmåde kaldet "paranoid versionsopgradering gennem replikering."

I løbet af rapporten lærte vi:

Ikke desto mindre kan du leve med dette helvede, hvis du i det mindste nogenlunde forstår, hvordan det fungerer.

Hovedbudskabet er:

I 2015 læste Andrey Aksenov på HighLoad++ Junior-konferencen en ny version af sin rapport om replikeringsenheden i MySQL. Vi har også tydet det på vores blog.

Udtrykket replikering bruges til at henvise til en mekanisme til synkronisering af flere kopier af data, hvilket øger informationssikkerheden, fejltolerancen og systemets ydeevne. Et slående eksempel er databasereplikering mellem to servere.

Master-Slave MySQL-replikering

I Master-Slave-terminologi er masteren den primære server med databasen; den skriver til databasen, men læsningen fordeles mellem masteren og slaven afhængigt af belastningen på systemet, hvilket øger fejltolerancen og ydeevnen. Takket være denne tilgang er der desuden altid en kopi af databasen ved hånden og kan gendannes, hvis en af ​​serverne svigter.

I hvilke situationer kan der være behov for en slaveserver? For eksempel, når en stor række af data ankommer for at blive skrevet til databasen, og masterserveren simpelthen ikke har tid til at læse, og klienten skal vente på slutningen af ​​skrivningen, hvilket kan undgås takket være slaveserveren.

Situationer er mulige, når masterserveren fejler; i dette tilfælde overtager slaveserveren alle masterens funktioner og arbejder alene, indtil den er gendannet. Klienten vil højst sandsynligt ikke bemærke noget, og han vil bestemt ikke vente en time eller to eller tre på, at teknikeren fikser det.

Opsætning af replikering er slet ikke svært, da mekanismen var indbygget i MySQL helt fra begyndelsen.

Opsætning på masterserveren

Lad os starte med at redigere konfigurationsfilen my.cnf, som oftest er placeret på /etc/mysql/my.cnf. Du skal finde og fjerne kommentarer (fjern #), eller skrive sådanne linjer.

Bind-adresse = 0.0.0.0 server-id = 1 log_bin = /var/log/mysql/mysql-bin.log

Vigtig! Hvis bind-adressen allerede er registreret, skal den ændres, ellers vil det ikke være muligt at etablere forbindelse mellem serverne.

Umiddelbart herefter genstarter vi databasen på serveren.

/etc/init.d/mysql genstart

Nu skal vi oprette en bruger med rettigheder til at replikere vores database; dette kan gøres fra root i MySQL-konsollen ved hjælp af kommandoen

GIV REPLIKATION SLAVE PÅ *.* TIL "slave_user"@"%" IDENTIFICERET AF "slave_password"; SKYLLE PRIVILEGIER;

Hvor du i stedet for "slave_user" og "slave_password" skal skrive login og adgangskode til slaven.

Lad os nu se på stamdataene

VIS MASTER STATUS;

Kolonneværdier Fil Og Position du skal huske, de vil blive brugt til at oprette slaven, hvilket er det, vi går videre til nu.

Opsætning på slaveserveren

Det første trin er at oprette en database med samme navn som den, vi skal replikere. Dette er et vigtigt skridt og bør ikke forsømmes. Gå derefter til den konfigurationsfil, der allerede er kendt for os min.cnf og skriv indstillingerne.

Server-id = 2 relay-log = /var/log/mysql/mysql-relay-bin.log bin-log = /var/log/mysql/mysql-bin.log

Vigtig! I bin-log skrives stien til bin-log på mesterserveren . Server-id'et skal være forskelligt fra master-id'et, det er praktisk at indstille det til 1 mere.

SKIFT MASTER TIL MASTER_HOST="1.1.1.1", MASTER_USER="slave_user", MASTER_PASSWORD="slave_password", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 107; START SLAVE;

Hvor host er masterens IP-adresse, login og adgangskode svarer til dem vi oprettede på masteren, master_log_file og master_log_pos er fyldt med informationer fra det sidste element til konfiguration af masterserveren .

Fra dette øjeblik vil alle ændringer i databasen blive overført fra masteren til slaven.

Kontrol af replikeringsstatus

Ud over kommandoen SHOW MASTER STATUS; Der er en lignende for slaven VIS SLAVE STATUS\G, som vil vise en tabel med information. Hovedtegnet på, at serverne har tilsluttet sig og fungerer korrekt, er tilstedeværelsen af ​​sådanne linjer

For ikke længe siden blev jeg bedt om at tale om replikering i MySQL. Jeg besluttede, at dette emne kunne være nyttigt for mange, så i denne artikel vil jeg tale om hvad er replikering i MySQL, hvornår er det nødvendigt, og hvordan man konfigurerer det.

Hovedopgaven med replikering er kombinere kraften fra flere servere. Lad os sige, at din hjemmeside har en dedikeret server, men med tiden bliver den meget besøgt og kan ikke længere holde til belastningen. Som et resultat begynder serveren at sænke farten og går ned regelmæssigt. Den nemmeste måde er at købe en mere kraftfuld server, og det er det, de fleste gør. Men før eller siden kommer der et tidspunkt, hvor omkostningerne ved at øge prisen på en server ikke svarer til stigningen i dens ydeevne, så det er mere rentabelt at købe 2 forskellige servere for færre penge.

Som et resultat vil din database være på to servere på én gang. Når en hovedserver (alias hovedserveren) ikke længere kan klare det, skifter den til en reserve.

Alle databaseopdateringsanmodninger går altid til hovedserveren. Efter opdatering af headserveren placerer den information om dette i en separat fil, hvorfra slaveserverne tager al information. Men samplingsoperationer, som normalt er de fleste, og de er de langsomste, kan allerede overføres til slaveservere, da dataene er de samme i begge.

Lad os nu finde ud af det hvordan man konfigurerer replikering i MySQL:

1. Installer mest seneste versioner af MySQL til alle servere.
2. Opret en bruger med privilegiet på hovedserveren UDSKIFTNING AF SLAVEN. For den adresse, hvorfra den kan oprette forbindelse, skal du angive " Alle".
3. Stop alle servere.
4. I indstillinger MySQL(i fil min.cnf) I kapitel tilføje følgende linjer: log-bin
   server-id=1 Bemærk venligst at server-id skal være forskellig på alle servere. Det er faktisk det, der adskiller en server fra en anden.
5. Føj til indstillinger på slaveservere MySQL følgende linjer: master-host=master_host_name
   master-user=login på den oprettede_bruger
   master-password=adgangskode for den oprettede_bruger
   master-port=port_for_connecting_to_the_master_server
   server-id=id_of_this_slave_server
6. Flyt alle baser fra hovedserveren til slaverne.
7. Løb hovedserveren, derefter alle slaverne.

Replikering er en mekanisme til at synkronisere indholdet af flere kopier af et objekt. Denne proces refererer til kopiering af data fra én kilde til mange andre og omvendt.

Betegnelser:

• master - hovedserveren, hvis data skal duplikeres;
• replika - en repareret server, der gemmer en kopi af stamdataene

For at opsætte replikering i MySQL skal du følge rækkefølgen af ​​handlinger beskrevet nedenfor, men dette er ikke et dogme, og parametrene kan ændre sig afhængigt af omstændighederne.

Rediger my.cnf-filen på hovedserveren og tilføj følgende linjer til mysqld-sektionen:

Server-id = log-bin = mysql-bin log-bin-index = mysql-bin.index log-error = mysql-bin.err relay-log = relay-bin relay-log-info-file = relay-bin. info relay-log-index = relay-bin.index expire_logs_days=7 binlog-do-db =

• - unik MySQL-server-id, nummer i området 2 (0-31)
• - navnet på databasen, information om hvilken vil blive skrevet til den binære log; hvis der er flere databaser, kræver hver en separat linje med parameteren binlog_do_db

På slaven skal du redigere my.cnf-filen og tilføje følgende linjer til mysqld-sektionen:

Server-id = master-host = master master-user = replikering master-adgangskode = adgangskode master-port = 3306 relay-log = relay-bin relay-log-info-file = relay-log.info relay-log-index = relay-log.index replicate-do-db =

På hovedserveren skal du tilføje replikeringsbrugeren med datareplikeringsrettigheder:

GRAANT REPLIKATIONSSLAVE PÅ *.* TIL "replikation"@"replika" IDENTIFICERET MED "adgangskode"

Lad os blokere replikerede databaser på hovedserveren fra at ændre data, programmatisk eller ved at bruge MySQL-funktionaliteten:

Mysql@master> SKYL TABELLER MED LÆSELÅS; mysql@master> SET GLOBAL read_only = TIL;

For at låse op, brug kommandoen:

Mysql@master> SET GLOBAL read_only = FRA;

Lad os lave sikkerhedskopier af alle databaser på hovedserveren (eller dem, vi har brug for):

Root@master# tar -czf mysqldir.tar.gz /var/lib/mysql/

eller ved at bruge mysqldump-værktøjet:

Root@master# mysqldump -u root -p --lock-all-tables > dbdump.sql

Lad os stoppe begge servere (i nogle tilfælde kan du undvære det):

Root@master# mysqlamdin -u root -p shutdown root@replica# mysqlamdin -u root -p shutdown

Lad os gendanne replikerede databaser på slaveserveren ved at kopiere mappen. Før replikering begynder, skal databaserne være identiske:

Root@replica# cd /var/lib/mysql root@replica# tar -xzf mysqldir.tar.gz

eller mysql-funktionalitet, så var der ingen grund til at stoppe mysql på slaveserveren:

Root@replica# mysql -u root -p< dbdump.sql

Lad os køre mysql på masterserveren (og derefter på slaveserveren, hvis det er nødvendigt):

Root@master# /etc/init.d/mysql start root@replica# /etc/init.d/mysql start

Lad os tjekke driften af ​​master- og slaveserverne:

Mysql@replica> start slave; mysql@replica> VIS SLAVESTATUS\G mysql@master> VIS MASTERSTATUS\G

På slaveserveren skal du kontrollere loggene i master.info filen, den skal indeholde anmodninger om at ændre data i databasen. Så denne binære fil skal først konverteres til tekstformat:

Root@replica# mysqlbinlog master.info > master_info.sql

Hvis der opstår fejl, kan du bruge kommandoerne:

Mysql@replica> stop slave; mysql@replica> NULSTIL SLAVE; mysql@master> NULSTIL MASTER;

og gentag alle trin startende med at blokere databaserne.

For at tilføje replikeringsservere kan du bruge følgende syntaks:

Mysql@replica> VIS SLAVESTATUS\G mysql@master> VIS MASTERSTATUS\G mysql@replica-2> SKIFT MASTER TIL MASTER_HOST = "master", MASTER_USER ="replikering", MASTER_PASSWORD = "adgangskode", MASTER_LOG_FILE ="mysql- bin.000004 ", MASTER_LOG_POS = 155; mysql@replica-2> START SLAVE;

Information fra statusserne vil vise positionen og navnet på den aktuelle logfil.

Med asynkron replikering spredes en opdatering fra én replika til andre efter nogen tid, snarere end i den samme transaktion. Således introducerer asynkron replikering en latenstid eller ventetid, hvor individuelle replikaer muligvis ikke er effektivt identiske. Men denne type replikering har også positive aspekter: masterserveren behøver ikke bekymre sig om datasynkronisering; du kan blokere databasen (for eksempel for at lave en sikkerhedskopi) på en slavemaskine uden problemer for brugerne.

Liste over anvendte kilder

1. Habrahabr.ru - Grundlæggende om replikering i MySQL (http://habrahabr.ru/blogs/mysql/56702/)
2. Wikipedia (http://ru.wikipedia.org/wiki/Replication_(computing_technology))

Når du bruger materiale fra webstedet helt eller delvist, skal du tydeligt angive et link til som kilde.

Data replikering mysql giver dig mulighed for at have en nøjagtig kopi af databasen fra én server - masterserveren (ledende server) på en eller flere andre servere (slaveserver). Som standard er Mysql-replikering asynkron.
Hvilket betyder at masterserveren ikke har nogen kontrol og ikke ved om slaveserverne læser logfilen og om de gør det korrekt.
Der findes også andre typer synkronisering, synkron og semi-synkron, hvor disse processer styres.
Afhængigt af indstillingerne kan du replikere både hele databaser og individuelle databasetabeller.

Hvad kan du bruge replikering til:
1. Belastningsfordeling mellem værter for at forbedre ydeevnen.
I et sådant skema vil masterknuden udføre læse- og skriveoperationer, knudepunkter, der har et abonnement på masterknuden, vil give en base for læsning, således vil vi fritage masterserveren fra læseoperationer
2. Datasikkerhed og nem vedligeholdelse, da slavenoden indeholder skrivebeskyttede data, vil ændringer af data på abonnenten være begrænset, let vedligeholdelse - muligheden for at køre processer, der betjener databasen uden at afbryde driften af ​​applikationer
3. Distribution af data over lange afstande. Du kan oprette en kopi af data på enhver vært, uanset dens placering
mysql understøtter følgende replikeringsmetoder:
Traditionel - metoden er baseret på replikering af hændelser fra masterens binære logfil og kræver logfiler. Positionerne mellem master- og slaveservere skal synkroniseres.
Metode, der bruger Global Transaction Identifiers GTID'er (Transactional Method)
mysql understøtter følgende typer synkronisering:
asynkron (envejssynkronisering)
semi-synkron (delvis kontrol af abonnenter)
synkron (fuld kontrol over abonnenter)

Opsætning af Mysql-databasereplikering traditionel metode

Funktionsprincip
Master server indeholder beholder logfiler, som registrerer alle ændringer, der sker i masterdatabasen, en fil, der beskriver navnene beholder filer, samt den position i loggen, hvor de sidste stamdata blev registreret
Slaveknuden modtager data fra masteren med information om navnene beholder filer og position i logfilen.

Opsætning af guiden
min.ini skal indeholde en unik identifikator - et tal fra 1 til 2 til 32. potens - 1, server-id.
Som standard server-id=0, hvilket betyder, at du ikke accepterer abonnementer fra slaveservere

log-bin=mysql-bin
server-id=1
Disse to linjer er nok til at starte
Bemærk: Hvis InnoDB bruges, anbefales det dog yderligere at tilføje
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Og du skal kontrollere, at evnen til at arbejde med netværket ikke er deaktiveret, og at spring-netværksparameteren er indstillet
Slaveserveren opretter forbindelse til masteren ved hjælp af et brugernavn og password, så vi opretter først en bruger på masterserveren
OPRET BRUGER repl@%.mydomain.com IDENTIFICERET AF slavepass;
TILDEL REPLIKATION SLAVE PÅ *.* TIL repl@%mydomain.com;
Lad os se på tilstanden
VIS MASTER STATUS
Hvis proceduren til oprettelse af binære logfiler allerede er blevet lanceret, skal du for InnoDB-tabeller først låse tabellerne i en af ​​sessionerne
SKYL BORDE MED LÆSELÅS;
Hvis du afslutter sessionen, udløses bordlåsen automatisk
I en anden session får vi navneværdierne beholder log og position
Begge værdier repræsenterer replikeringskoordinaterne, hvor slaveserveren skal begynde at læse fra filen på det ønskede sted for at begynde replikering.
Næste trin afhænger af om der er data på slaveserveren, data fra masteren
Hvis de findes, så lader vi tabellerne være låste og opretter losseplads(dette er den anbefalede måde, når du bruger InnoDB)
Du kan finde ud af databasetypen med kommandoen
mysqlshow -u mysql_user -p -i databasenavn
Hvis databasen er gemt i binære filer, kan de kopieres fra masteren til slaveserveren
Lad os gøre det losseplads
mysqldump --alle-databaser --masterdata dbdump.db
at vælge baser mysqldump --databases --master-data dbdump.db
master-data parameter, tilføjes automatisk SKIFT MASTER TIL på en slaveknude, hvis parameteren ikke tilføjes, skal alle tabeller i sessionen låses manuelt
Lås op
LÅS BORDE OP;

Konfiguration af slaveknude EN
Tilføj til min.ini server-id fra personlig fra masteren og fra andre noder

server-id=2
Opret et abonnement
SKIFT MASTER TIL
MASTER_HOST=master_host_name,
MASTER_USER=replikeringsbrugernavn,
MASTER_PASSWORD=replikeringsadgangskode,
MASTER_LOG_FILE=registreret_log_fil_navn,
MASTER_LOG_POS=registreret_log_position;
Når du opsætter replikering med eksisterende data, skal du overføre et snapshot fra masteren til slaven, før replikeringen begynder
Vi bruger mysqldump
1.Start slavenoden vha -- skip-slave-start parameter for at forhindre replikering i at starte
2. Importer dumpfilen
mysql fulldb.dump
3. Start abonnementsprocessen
START SLAVE;
Kontrollerer replikeringsstatus
VIS SLAVESTATUS\G
Slave_IO_State: - nuværende tilstand for slaveenheden
Slave_IO_Running: - om datastrømmen læses fra masteren
Slave_SQL_Running: - uanset om sql-forespørgsler kører, skal det være ja

Eksempel Lad os konfigurere Master (master) serveren – ip 11.11.11.10 V min.ini
[ mysqld] log-bin=mysql-bin server-id=1
Opret en bruger mysql -u root -p GIV REPLIKATIONSSLAVE PÅ *.* TO replica@% IDENTIFICERET VED adgangskode; SKYLLE PRIVILEGIER;
Dernæst låser vi alle tabeller i databasen SKYL BORDE MED LÆSELÅS;
Vi ser på status VIS MASTER STATUS; Vi husker filnavnet og positionen, vi vil bruge dem på slaveserveren til abonnement

På slave B min.ini
log-bin=mysql-bin server-id=2
Opret et abonnement SKIFT MASTER TIL MASTER_HOST=11.11.11.10, MASTER_PORT=3306,
MASTER_USER=replika, MASTER_PASSWORD=adgangskode,
MASTER_LOG_FILE=server-mysql-bin.000002,
MASTER_LOG_POS=1151664, MASTER_CONNECT_RETRY=10;
START SLAVE;
Replikeringsstatus VIS SLAVESTATUS\G