Data replikering mysql lar deg ha en eksakt kopi av databasen fra én server - masterserveren (ledende server) på en eller flere andre servere (slaveserver). Som standard er Mysql-replikering asynkron.
Noe som betyr at masterserveren ikke har kontroll og ikke vet om slaveserverne leser loggfilen og om de gjør det riktig.
Det finnes også andre typer synkronisering, synkron og semi-synkron, hvor disse prosessene styres.
Avhengig av innstillingene kan du replikere både hele databaser og individuelle databasetabeller.

Hva kan du bruke replikering til:
1. Lastfordeling mellom verter for å forbedre ytelsen.
I et slikt opplegg vil masternoden utføre lese- og skriveoperasjoner, noder som har et abonnement på masternoden vil gi en base for lesing, dermed vil vi avlaste masterserveren fra leseoperasjoner
2. Datasikkerhet og enkel vedlikehold, siden slavenoden inneholder skrivebeskyttede data, vil endringer i dataene på abonnenten være begrenset, enkel vedlikehold - muligheten til å kjøre prosesser som betjener databasen uten å avbryte driften av applikasjoner
3. Distribusjon av data over lange avstander. Du kan lage en kopi av data på hvilken som helst vert, uavhengig av plasseringen
mysql støtter følgende replikeringsmetoder:
Tradisjonell – metoden er basert på replikering av hendelser fra masterens binære loggfil og krever loggfiler. Posisjonene mellom master- og slaveservere må synkroniseres.
Metode som bruker globale transaksjonsidentifikatorer GTID-er (transaksjonsmetode)
mysql støtter følgende typer synkronisering:
asynkron (enveis synkronisering)
semi-synkron (delvis kontroll av abonnenter)
synkron (full kontroll over abonnenter)

Sette opp Mysql database replikering tradisjonell metode

Prinsipp for operasjon
Hovedserveren inneholder bin loggfiler, som registrerer alle endringer som skjer i hoveddatabasen, en fil som beskriver navnene bin filer, samt posisjonen i loggen hvor siste stamdata ble registrert
Slavenoden mottar data fra masteren som har informasjon om navnene bin filer og posisjon i loggfilen.

Veiviseroppsett
min.ini må inneholde en unik identifikator - et tall fra 1 til 2 til 32. potens - 1, server-id.
Som standard server-id=0, som betyr at du ikke aksepterer abonnementer fra slaveservere

log-bin=mysql-bin
server-id=1
Disse to linjene er nok til å starte
Merk: Men hvis InnoDB brukes, anbefales det i tillegg å legge til
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Og du må sjekke at muligheten til å jobbe med nettverket ikke er deaktivert og at parameteren for skip-nettverk er satt
Slaveserveren kobler seg til masteren ved hjelp av brukernavn og passord, så vi oppretter først en bruker på masterserveren
OPPRETT BRUKER repl@%.mydomain.com IDENTIFISERT AV slavepass;
GI REPLIKASJONSSLAVE PÅ *.* TIL repl@%.mydomain.com;
La oss se på tilstanden
VIS MASTERSTATUS
Hvis prosedyren for å lage binære logger allerede er lansert, må du for InnoDB-tabeller først låse tabellene i en av øktene
SKYLLE BORD MED LESESLÅS;
Hvis du avslutter økten, frigjøres bordlåsen automatisk
I en annen økt får vi navneverdiene bin logg og posisjon
Begge verdiene representerer replikeringskoordinatene der slaveserveren må begynne å lese fra filen på ønsket sted for å starte replikering.
Neste trinn avhenger av om det er data på slaveserveren, data fra masteren
Hvis de eksisterer, lar vi tabellene være låst og oppretter dump(dette er den anbefalte måten når du bruker InnoDB)
Du kan finne ut databasetypen med kommandoen
mysqlshow -u mysql_user -p -i databasenavn
Hvis databasen er lagret i binære filer, kan de kopieres fra masteren til slaveserveren
La oss gjøre dump
mysqldump --alle-databaser --masterdata dbdump.db
å velge baser mysqldump --databases --master-data dbdump.db
masterdata-parameter, legges til automatisk ENDRE MESTER TIL på en slavenode, hvis parameteren ikke er lagt til, må alle tabeller i økten låses manuelt
Låse opp
LÅS OPP BORD;

Konfigurasjon av slavenode EN
Legge til min.ini server-id fra personlig fra masteren og fra andre noder

server-id=2
Opprett et abonnement
ENDRE MESTER TIL
MASTER_HOST=master_host_name,
MASTER_USER=replikeringsbrukernavn,
MASTER_PASSWORD=replikeringspassord,
MASTER_LOG_FILE=registrert_logg_filnavn,
MASTER_LOG_POS=registrert_loggposisjon;
Når du setter opp replikering med eksisterende data, må du overføre et øyeblikksbilde fra masteren til slaven før replikeringen starter
Vi bruker mysqldump
1.Start slavenoden med --hopp over-slave-start parameter for å forhindre at replikering starter
2.Importer dumpfilen
mysql fulldb.dump
3. Start abonnementsprosessen
START SLAVE;
Kontrollerer replikeringsstatusen
VIS SLAVESTATUS\G
Slave_IO_State: - gjeldende tilstand for slaveenheten
Slave_IO_Running: - om datastrømmen leses fra masteren
Slave_SQL_Running: - kjører de? sql-spørringer, bør være ja

Eksempel La oss konfigurere Master (master) serveren – ip 11.11.11.10 V min.ini
[ mysqld] log-bin=mysql-bin server-id=1
Opprett en bruker mysql -u root -p GI REPLIKASJONSSLAVE PÅ *.* TIL replica@% IDENTIFISERT AV passord; SPILLE PRIVILEGIER;
Deretter låser vi alle tabeller i databasen SKYLLE BORD MED LESESLÅS;
Vi ser på status VIS MASTERSTATUS; Vi husker filnavnet og posisjonen, vi vil bruke dem på slaveserveren for abonnement

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

Begrepet replikering brukes for å referere til en mekanisme for synkronisering av flere kopier av data, noe som øker informasjonssikkerhet, feiltoleranse og systemytelse. Et slående eksempel er databasereplikering mellom to servere.

Master-Slave MySQL-replikering

I Master-Slave-terminologi er masteren den primære serveren med databasen; den skriver til databasen, men lesing fordeles mellom master og slave avhengig av belastningen på systemet, noe som øker feiltoleransen og ytelsen. I tillegg, takket være denne tilnærmingen, er en kopi av databasen alltid tilgjengelig og kan gjenopprettes hvis en av serverne svikter.

I hvilke situasjoner kan en slaveserver være nødvendig? For eksempel, når et stort utvalg av data kommer for å skrives til databasen og masterserveren rett og slett ikke har tid til å lese og klienten må vente på slutten av skrivingen, noe som kan unngås takket være slaveserveren.

Situasjoner er mulig når masterserveren svikter; i dette tilfellet overtar slaveserveren alle funksjonene til masteren og fungerer alene til den er gjenopprettet. Klienten vil mest sannsynlig ikke merke noe, og han vil absolutt ikke vente en time eller to eller tre på at teknikeren skal fikse det.

Å sette opp replikering er slett ikke vanskelig, siden mekanismen ble bygget inn i MySQL helt fra begynnelsen.

Oppsett på masterserveren

La oss starte med å redigere konfigurasjonsfilen my.cnf, som oftest ligger på /etc/mysql/my.cnf. Du må finne og avkommentere (fjerne #), eller skrive slike linjer.

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

Viktig! Hvis bind-adressen allerede er registrert, må den endres, ellers vil det ikke være mulig å etablere en forbindelse mellom serverne.

Umiddelbart etter dette vil vi starte databasen på nytt på serveren.

/etc/init.d/mysql omstart

Nå må vi opprette en bruker med rettigheter til å replikere databasen vår, dette kan gjøres fra root inn MySQL-konsoll ved å bruke kommandoen

GI REPLIKASJONSSLAVE PÅ *.* TIL "slave_user"@"%" IDENTIFISERT AV "slave_password"; SPILLE PRIVILEGIER;

Hvor du i stedet for "slave_user" og "slave_password" må skrive innlogging og passord for slaven.

La oss nå se på masterdataene

VIS MASTERSTATUS;

Kolonneverdier Fil Og Posisjon du må huske, de vil bli brukt til å sette opp slaven, som er det vi går videre til nå.

Oppsett på slaveserveren

Det første trinnet er å lage en database med samme navn som den vi skal replikere. Dette er et viktig skritt og bør ikke neglisjeres. Deretter går du til konfigurasjonsfilen som allerede er kjent for oss min.cnf og skriv innstillingene.

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

Viktig! I bin-log skrives banen til bin-loggen på mesterserveren . Server-ID-en må være forskjellig fra master-IDen, det er praktisk å sette den til 1 til.

CHANGE MASTER TO 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;

Der host er masterens IP-adresse, pålogging og passord tilsvarer de vi opprettet på masteren, master_log_file og master_log_pos er fylt med informasjon fra det siste elementet for å konfigurere hovedserveren .

Fra dette øyeblikket vil alle endringer i databasen bli overført fra masteren til slaven.

Sjekker replikeringsstatus

I tillegg til kommandoen SHOW MASTER STATUS; Det er en lignende for slaven VIS SLAVESTATUS\G, som vil vise en tabell med informasjon. Hovedtegnet på at serverne har koblet til og fungerer som de skal, er tilstedeværelsen av slike linjer

Replikering- en teknikk som brukes i arkitekturen til systemer som opererer under belastning, hvis resultat er fordelingen av belastningen når du arbeider med en database på tvers av flere servere. MySQL MASTER SLAVE replikering brukes oftere, men en annen type replikering brukes også - Master-Master.

Hva er MySQL MASTER SLAVE replikering og hva brukes det til?

Replikering Mester-slave involverer duplisering av data til en slave MySQL-server; slik duplisering utføres hovedsakelig for å sikre pålitelighet. Hvis masterserveren svikter, byttes funksjonene til slaven.

Replikering kan også utføres for å forbedre systemytelsen, men ytelsen er nesten alltid sekundær her.
Når en applikasjon fungerer med en database, er de hyppigste operasjonene PLUKKE UT- forespørsler om å lese data, endre data - forespørsler SLETT, SETT INN, OPPDATER, ENDRE Statistisk sett skjer det mye sjeldnere.

For å forhindre tap av data hvis en av serverne svikter, blir operasjoner for å endre informasjon i tabeller alltid behandlet av hovedserveren. Endringene blir deretter replikert til slaven. Lesing kan gjøres fra en server som spiller rollen som slave.
På grunn av dette kan du få en gevinst i ytelse sammen med pålitelighet.

Løsningen er populær, men ikke alltid aktuelt siden det kan oppstå forsinkelser under replikering - hvis dette skjer, må informasjonen også leses fra Master-serveren.

Direkte forespørsler av en bestemt type til en bestemt databaseserver er uansett implementert på applikasjonsnivå.

Hvis du gjør deling VELG søk og alle de andre på programnivå, sender dem til ønsket server når en av dem mislykkes, vil applikasjonen som infrastrukturen betjener være ubrukelig. For at dette skal fungere, må du yte mer kompleks krets og reservere hver av serverne.

Replikering er for feiltoleranse, ikke for skalering.

MySQL MASTER SLAVE replikering - oppsett på Debian

Vi vil bruke to servere med adresser:

• Hovedserver 192.168.0.1
• Slaveserver 192.168.0.2

For demonstrasjon brukes VDS koblet til et lokalt nettverk.
For alltid å vite sikkert på hvilken server vi utfører denne eller den kommandoen, vil vi redigere /etc/hosts-filene på begge serverne

192.168.0.1 mester

192.168.0.2 slave

La oss erstatte de eksisterende verdiene i /etc/hostname med henholdsvis master og slave, slik at endringene trer i kraft og starter serveren på nytt.

1. Vi gjør innstillinger på masterserveren.

root@master:/#

Redigerer den viktigste konfigurasjonsfil databaseserver

mcedit /etc/mysql/my.cnf

Velg server-ID - du kan spesifisere et hvilket som helst tall, standard er 1 - bare avkommenter linjen

server-id = 1

Angi banen til den binære loggen - også spesifisert som standard, fjern kommentaren

Angi navnet på databasen som vi skal replikere til en annen server

binlog_do_db = db1

Start Mysql på nytt slik at konfigurasjonsfilen leses på nytt og endringene trer i kraft:

/etc/init.d/mysql omstart

2. Angi brukerens nødvendige rettigheter

Gå til databaseserverkonsollen:

Vi gir brukeren på slaveserveren de nødvendige rettighetene:

GI REPLIKASJONSSLAVE PÅ *.* TIL "slave_user"@"%" IDENTIFISERT AV "123";

Låser alle tabeller i databasen

SKYLLE BORD MED LESESLÅS;

Sjekke statusen til hovedserveren:

+——————+———-+—————+——————+
| Fil | Stilling | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+—————+——————+
| mysql-bin.000001 | 327 | db1 | |
+——————+———-+—————+——————+
1 rad i sett (0,00 sek)

3. Opprett en databasedump på serveren

Opprett en databasedump:

mysqldump -u rot -p db1 > db1.sql

Lås opp tabeller i mysql-konsollen:

4. Overfør databasedumpen til slaveserveren

scp db1.sql [e-postbeskyttet]:/hjem

Vi utfører ytterligere handlinger på slaveserveren

root@slave:/#

5. Opprette en database

Laster dumpen:

mysql -u rot -p db1< db1.sql

6. Gjør endringer i my.cnf

mcedit /etc/mysql/my.cnf

Vi tildeler en ID ved å øke verdien som er satt på masterserveren

server-id = 2

Angi banen til reléloggen

relay-log = /var/log/mysql/mysql-relay-bin.log

og banen til bin-loggen på hovedserveren

log_bin = /var/log/mysql/mysql-bin.log

Spesifiser basen

binlog_do_db = db1

Starter tjenesten på nytt

/etc/init.d/mysql omstart

7. Sett opp en tilkobling til hovedserveren

CHANGE MASTER TO MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;

Vi starter replikering på slaveserveren:

Du kan sjekke driften av replikering på slaven med følgende forespørsel:

************************* 1. rad ******************** * *****
Slave_IO_State: Venter på at master skal sende hendelse
Master_Host: 192.168.0.1
Master_User: slave_user
Master_Port: 3306
Koble til_Prøv på nytt: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Ja
Slave_SQL_Running: Ja
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 555
Until_Condition: Ingen
Until_Log_File:
Inntil_Log_Pos: 0
Master_SSL_Allowed: Nei
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: Nei
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 rad i sett (0,00 sek)

Siden det ikke oppsto noen feil, kan vi konkludere med at replikering er riktig konfigurert.

Er godt verktøy skalering, men den største ulempen er desynkronisering av datakopiering og forsinkelser, noe som kan være kritisk.

Ved å bruke en mer moderne løsning kan du unngå dem helt. Det er enkelt å sette opp, pålitelig og eliminerer behovet for manuelt å kopiere databasedumper.

visp 8. april 2009 kl. 11:10

Grunnleggende om MySQL-replikering

• MySQL

Jeg ble relativt nylig kjent med replikering av MySQL-servere, og etter hvert som jeg utførte ulike eksperimenter med konfigurasjonen, skrev jeg ned hva som fungerte for meg. Da jeg hadde samlet ganske mye materiale, kom ideen om å skrive denne artikkelen. Jeg har prøvd å samle tips og løsninger på noen av de mest grunnleggende problemene jeg har støtt på. Jeg kommer med lenker til dokumentasjon og andre kilder underveis. Jeg kan ikke late som å beskrive det fullstendig, men jeg håper artikkelen vil være nyttig.

En kort introduksjon

Replikering (fra latin repliko - jeg gjentar) er replikering av dataendringer fra hoveddatabasetjeneren til en eller flere avhengige servere. Vi ringer hovedserveren herre, og avhengig - kopier.
Dataendringer som skjer på masteren, gjentas på replikaene (men ikke omvendt). Derfor utføres spørringer for å endre data (INSERT, UPDATE, DELETE, etc.) kun på masteren, mens spørringer for å lese data (med andre ord SELECT) kan utføres på både replikaer og masteren. Replikeringsprosessen på en av kopiene påvirker ikke driften av andre replikaer, og påvirker praktisk talt ikke mesterens arbeid.
Replikering utføres ved hjelp av binære logger vedlikeholdt på masteren. De lagrer alle spørringer som fører (eller potensielt fører) til endringer i databasen (spørringer lagres ikke eksplisitt, så hvis du vil se på dem, må du bruke mysqlbinlog-verktøyet). Binloggene overføres til replikaene (binloggen som er lastet ned fra masteren kalles en "relay binlog") og de lagrede spørringene utføres fra en bestemt posisjon. Det er viktig å forstå at under replikering er det ikke de endrede dataene i seg selv som overføres, men bare forespørslene som forårsaker endringene.
Med replikering dupliseres innholdet i databasen på flere servere. Hvorfor er det nødvendig å ty til duplisering? Det er flere grunner:

• ytelse og skalerbarhet. Én server kan kanskje ikke håndtere belastningen forårsaket av samtidige lese- og skriveoperasjoner i databasen. Fordelene ved å lage replikaer vil være større jo flere lesere per skriv du har på systemet ditt.
• feiltoleranse. I tilfelle replikafeil kan alle leseforespørsler trygt overføres til masteren. Hvis masteren mislykkes, kan skriveforespørsler overføres til replikaen (etter at masteren er gjenopprettet, kan den ta over rollen til replikaen).
• Data backup. Replikaen kan "bremses" en stund for å utføre mysqldump, men masteren kan ikke.
• utsatte beregninger. Tunge og langsomme SQL-spørringer kan utføres på en separat replika uten frykt for å forstyrre normal drift av hele systemet.

I tillegg er det noen andre interessante funksjoner. Siden det ikke er selve dataene som overføres til replikaene, men spørringene som gjør at de endres, kan vi bruke ulike tabellstrukturer på masteren og replikaene. Spesielt kan typen tabell (motor) eller sett med indekser variere. For å utføre fulltekstsøk kan vi for eksempel bruke MyISAM-tabelltypen på replikaen, til tross for at masteren vil bruke InnoDB.

Sette opp replikering

La oss si at vi har en fungerende database MySQL-data, allerede fylt med data og inkludert i arbeidet. Og av en av grunnene beskrevet ovenfor, skal vi aktivere replikering av serveren vår. Våre første data:

• Hoved-IP-adressen er 192.168.1.101, kopiene er 192.168.1.102.
• MySQL installert og konfigurert
• du må konfigurere testdb-databasereplikering
• vi kan sette veiviseren på pause en stund
• vi har selvfølgelig root på begge maskinene

Veiviserinnstillinger

Sørg for å angi den unike server-IDen, banen for binære logger og navnet på databasen for replikering i delen:
server-id = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb
Sørg for at du har nok diskplass for binære logger.

La oss legge til replikeringsbrukeren, under hvis rettigheter replikering skal utføres. "replikeringsslave"-privilegiet vil være tilstrekkelig:
mysql@master> GIL replikeringsslave PÅ "testdb".* TIL "replikasjon"@"192.168.1.102" IDENTIFISERT VED "passord";

Start MySQL på nytt for at endringene i konfigurasjonen skal tre i kraft:
root@master# service mysqld omstart

Hvis alt gikk bra, skulle kommandoen "vis masterstatus" vise noe slikt:
mysql@master>VIS MASTER STATUS\G
Fil: mysql-bin.000003
Stilling: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Posisjonsverdien bør øke etter hvert som endringer gjøres i databasen på masteren.

Replikainnstillinger

La oss spesifisere server-IDen, navnet på databasen for replikering og banen til relébinloggene i konfigurasjonsdelen, og last deretter inn MySQL på nytt:
server-id = 2
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-do-db = testdb

Root@replica# service mysqld omstart

Overføring av data

Her må vi låse databasen for skriving. For å gjøre dette kan du enten stoppe applikasjonene eller bruke read_only-flagget på masteren (obs: dette flagget har ingen effekt på brukere med SUPER-privilegiet). Hvis vi har MyISAM-tabeller, la oss også "tømme tabeller":
mysql@master> SKYL TABELLER MED LESE-LÅS;
mysql@master> SET GLOBAL read_only = PÅ;

La oss se masterens status med kommandoen "vis masterstatus" og huske fil- og posisjonsverdiene (etter å ha blokkert masteren, bør de ikke endres):
Fil: mysql-bin.000003
Stilling: 98

Vi dumper databasen, og etter at operasjonen er fullført, fjerner vi masterens lås:
mysql@master> SET GLOBAL read_only = AV;

Vi overfører dumpen til kopien og gjenoppretter data fra den.
Til slutt starter vi replikering med kommandoene "endre master til" og "start slave" og se om alt gikk bra:
mysql@replica> ENDRE MASTER TIL MASTER_HOST = "192.168.1.101", MASTER_USER = "replikering", MASTER_PASSWORD = "passord", MASTER_LOG_FILE = "mysql-bin.000003", MASTER_LOG_POS = 98;
mysql@replica> start slave;
Vi tar verdiene til MASTER_LOG_FILE og MASTER_LOG_POS fra masteren.

La oss se hvordan replikering går med kommandoen "vis slavestatus":
mysql@replica> VIS SLAVESTATUS\G
Slave_IO_State: Venter på at master skal sende hendelse
Master_Host: 192.168.1.101
Master_User: replikering
Master_Port: 3306
Koble til_Prøv på nytt: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 98
Relay_Log_File: mysql-relay-bin.001152
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Ja
Slave_SQL_Running: Ja
Replicate_Do_DB: testdb,testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: Ingen
Until_Log_File:
Inntil_Log_Pos: 0
Master_SSL_Allowed: Nei
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 5

Jeg har fremhevet de mest interessante verdiene nå. Hvis replikering starter vellykket, bør verdiene deres være omtrent de samme som i oppføringen (se beskrivelsen av kommandoen "vis slavestatus" i dokumentasjonen). Seconds_Behind_Master-verdien kan være et hvilket som helst heltall.
Hvis replikeringen er normal, vil replikaen følge masteren (loggnummeret i Master_Log_File og Exec_Master_Log_Pos-posisjonen vil øke). Lagtiden til replikaen fra masteren (Seconds_Behind_Master), ideelt sett bør være lik null. Hvis den ikke avtar eller vokser, er det mulig at belastningen på kopien er for høy - den har rett og slett ikke tid til å gjenta endringene som skjer på masteren.
Hvis Slave_IO_State er tom og Seconds_Behind_Master er NULL, har ikke replikering startet. Se MySQL-loggen for å finne årsaken, eliminer den og start replikering på nytt:
mysql@replica> start slave;

Gjennom disse enkle trinnene får vi en replika hvis data er identiske med dataene på masteren.
Tiden masteren er blokkert er forresten tiden dumpen opprettes. Hvis det tar uakseptabelt lang tid å lage, kan du prøve dette:

• blokker skriving til masteren med read_only-flagget, husk posisjonen og stopp MySQL.
• etter det kopierer du databasefilene til replikaen og aktiverer masteren.
• starte replikering på vanlig måte.

Det er flere måter å lage en kopi uten å stoppe masteren i det hele tatt, men de fungerer ikke alltid.

Legger til kopier

Anta at vi allerede har en fungerende mester og en kopi, og vi må legge til en til dem. Dette er enda enklere å gjøre enn å legge til den første kopien til masteren. Og det som er mye bedre er at det ikke er nødvendig å stoppe mesteren for dette.
Først, la oss konfigurere MySQL på den andre replikaen og sørge for at vi har lagt inn de nødvendige parameterne i konfigurasjonen:
server-id = 3
replicate-do-db = testdb

La oss nå stoppe replikeringen på den første kopien:
mysql@replica-1> stopp slave;

Replikaen vil fortsette å fungere normalt, men dataene på den vil ikke lenger være oppdaterte. La oss se på statusen og huske hovedposisjonen som replikaen nådde før replikeringen stoppet:
mysql@replica-1> VIS SLAVESTATUS\G

Verdiene vi trenger vil være Master_Log_File og Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155

La oss lage en databasedump og fortsette replikering på den første replikaen:
mysql@replica-1> START SLAVE;

La oss gjenopprette dataene fra dumpen på den andre replikaen. Aktiver deretter replikering:
mysql@replica-2> ENDRE MASTER TIL MASTER_HOST = "192.168.1.101", MASTER_USER = "replikering", MASTER_PASSWORD = "passord", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155;
mysql@replica-2> START SLAVE;

MASTER_LOG_FILE- og MASTER_LOG_POS-verdiene er henholdsvis Master_Log_File- og Exec_Master_Log_Pos-verdiene fra resultatet av kommandoen "vis slavestatus" på den første replikaen.
Replikering må begynne fra posisjonen der den første replikaen ble stoppet (og følgelig opprettes en dump). Dermed vil vi ha to replikaer med identiske data.

Slår sammen kopier

Noen ganger oppstår følgende situasjon: det er to databaser på masteren, hvorav den ene er replikert på en replika og den andre på en annen. Hvordan sette opp replikering av to databaser på begge replikaene uten å dumpe dem på masteren eller slå den av? Ganske enkelt ved å bruke kommandoen "start slave til".
Så vi har en master med databasene testdb1 og testdb2, som er replikert på replikaene replica-1 og replica-2, henholdsvis. La oss konfigurere replikering av begge databasene til replica-1 uten å stoppe masteren.
Stopp replikering på replica-2 med kommandoen og husk posisjonen til masteren:
mysql@replica-2> STOPP SLAVE;
mysql@replica-2> VIS SLAVESTATUS\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231

La oss lage en dump av testdb2-databasen og gjenoppta replikering (dette fullfører manipulasjonene med replica-2). Vi vil gjenopprette dumpen til replika-1.

Situasjonen på replica-1 er denne: testdb1-databasen er på én hovedposisjon og fortsetter å replikere, testdb2-databasen har blitt gjenopprettet fra en dump fra en annen posisjon. La oss synkronisere dem.

La oss stoppe replikering og huske mesterens posisjon:
mysql@replica-1> STOPP SLAVE;
mysql@replica-1> VIS SLAVESTATUS\G
Exec_Master_Log_Pos: 501

La oss sørge for at i konfigurasjonen for replica-1 er navnet på den andre databasen angitt i delen:
replicate-do-db = testdb2

La oss starte MySQL på nytt for at endringene i konfigurasjonen skal tre i kraft. Det var forresten mulig å ganske enkelt starte MySQL på nytt uten å stoppe replikering - fra loggen ville vi vite på hvilken posisjon i masterreplikeringen stoppet.

La oss nå replikere fra posisjonen der replica-2 ble satt på pause til posisjonen der vi nettopp stoppet replikering:
mysql@replica-1> ENDRE MASTER TIL MASTER_HOST = "192.168.1.101", MASTER_USER = "replikering", MASTER_PASSWORD = "passord", MASTER_LOG_FILE = "mysql-bin.000015", MASTER_LOG_POS = 231;
mysql@replica-1> start slave til MASTER_LOG_FILE = "mysql-bin.000016 ", MASTER_LOG_POS = 501;

Replikering vil avsluttes så snart replikaen når den spesifiserte posisjonen i til-delen, hvoretter begge databasene våre vil tilsvare den samme masterposisjonen (der vi stoppet replikering på replica-1). La oss sørge for dette:
mysql@replica-1> VIS SLAVESTATUS\G
mysql@replica-1> START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

La oss legge til navnene på begge databasene til konfigurasjonen for replica-1 i delen:
replicate-do-db = testdb1
replicate-do-db = testdb2

Viktig: hver database må være oppført på en egen linje.
Start MySQL på nytt og fortsett replikering:
mysql@replica-1> ENDRE MASTER TIL MASTER_HOST = "192.168.1.101", MASTER_USER = "replikering", MASTER_PASSWORD = "passord", MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;
Etter at replica-1 fanger opp masteren, vil innholdet i databasen deres være identisk. Du kan slå sammen databasen til replica-2 enten på lignende måte, eller ved å lage en fullstendig dump av replica-1.

Slottsmester og replika

Det kan være nødvendig å bytte en replika til mastermodus, for eksempel i tilfelle en masterfeil eller når du utfører en teknisk arbeid. For å gjøre en slik bryter mulig, må du konfigurere replikaen som masteren, eller lage den passiv mester.

La oss aktivere binær logging (i tillegg til relébinlogger) i konfigurasjonen i seksjonen:
log-bin = /var/lib/mysql/mysql-bin

Og legg til en bruker for replikering:
mysql@master> GIL replikeringsslave PÅ 'testdb'.* TIL 'replikasjon'@'192.168.1.101′ IDENTIFISERT AV "passord";

Den passive masteren utfører replikering som en vanlig replika, men i tillegg lager den binære logier - det vil si at vi kan starte replikering fra den. La oss bekrefte dette med kommandoen "vis masterstatus":
mysql@replica> VIS MASTER STATUS\G
Fil: mysql-bin.000001
Plassering: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Nå, for å bytte den passive masteren til aktiv modus, må du stoppe replikering på den og aktivere replikering på den tidligere aktive masteren. For å sikre at data ikke går tapt ved bytte, aktiv mester må være skrivelåst.
mysql@master> SKYLL TABELLER MED LESELÅS
mysql@master> SET GLOBAL read_only = PÅ;
mysql@replica> STOPP SLAVE;
mysql@replica> VIS MASTER STATUS;
Fil: mysql-bin.000001
Plassering: 61
mysql@master> CHANGE MASTER TO MASTER_HOST = "192.168.1.102", MASTER_USER = "replikering", MASTER_PASSWORD = "passord", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 61;
mysql@master> start slave;
Det var det, så vi endret den aktive mesteren. Du kan fjerne blokken fra den tidligere masteren.

Konklusjon

Vi har lært litt om hvordan du setter opp replikering i MySQL og utfører noen grunnleggende operasjoner. Dessverre forblir følgende viktige spørsmål utenfor rammen av denne artikkelen:

• eliminering av enkeltpunkter for feil (SPF, Single Points of Failure). Når du bruker den eneste MySQL-server, dens feil førte til svikt i hele systemet. Når du bruker flere servere, vil feil på en av dem resultere i en systemfeil med mindre vi spesifikt tar oss av dette. Vi må sørge for å håndtere situasjonen med svikt i master og replika. Et av de eksisterende verktøyene er MMM, men det krever modifikasjon med en fil.
• lastbalansering. Når du bruker flere kopier, vil vi gjerne bruke en gjennomsiktig balanseringsmekanisme, spesielt hvis ytelsen til kopiene er ujevn. Under Linux er det mulig å bruke en standardløsning - LVS.
• endre applikasjonens logikk. I en ideell situasjon bør forespørsler om å lese data sendes til replikaer, og forespørsler om å endre data skal sendes til masteren. På grunn av mulig etterslep av replikaer er imidlertid et slikt opplegg ofte ineffektivt, og det er nødvendig å identifisere slike leseforespørsler som fortsatt må utføres på masteren.

Jeg håper å dekke disse problemene i fremtidige artikler.
Takk for din oppmerksomhet!

Tagger:

• mysql
• replikering

Legg til merkelapper

For ikke lenge siden ble jeg bedt om å snakke om replikering i MySQL. Jeg bestemte meg for at dette emnet kunne være nyttig for mange, så i denne artikkelen vil jeg snakke om hva er replikering i MySQL, når er det nødvendig og hvordan du konfigurerer det.

Hovedoppgaven med replikering er kombinere kraften til flere servere. La oss si at nettstedet ditt har en dedikert server, men over tid blir det veldig besøkt og tåler ikke belastningen lenger. Som et resultat begynner serveren å bremse og krasje regelmessig. Den enkleste måten er å kjøpe en kraftigere server, og det er dette folk flest gjør. Men før eller senere kommer det en tid da kostnadene ved å øke prisen på en server ikke samsvarer med økningen i ytelsen, så det er mer lønnsomt å kjøpe 2 forskjellige servere for mindre penger.

Som et resultat vil databasen din være på to servere samtidig. Når en hovedserver (også kjent som hovedserveren) ikke lenger kan klare seg, bytter den til en reserveserver.

Alle databaseoppdateringsforespørsler går alltid til hovedserveren. Etter å ha oppdatert hovedserveren, plasserer den informasjon om dette egen fil, hvor slaveserverne henter all informasjonen. Men samplingsoperasjoner, som vanligvis er de fleste, og de er de tregeste, kan allerede overføres til slaveservere, siden dataene er de samme i begge.

La oss nå finne ut av det hvordan konfigurere replikering i MySQL:

1. Installer mest siste versjoner av MySQL til alle servere.
2. Opprett en bruker med rettigheten på hovedserveren BYTTER SLAVE. For adressen som den kan koble til, spesifiser " Alle".
3. Stopp alle servere.
4. I innstillinger MySQL(i fil min.cnf) I kapittel legg til følgende linjer: log-bin
   server-id=1 Vær oppmerksom på at server-id må være forskjellig på alle servere. Faktisk er det dette som skiller en server fra en annen.
5. På slaveservere, legg til innstillinger MySQL følgende linjer: master-host=master_host_name
   master-user=innlogging til opprettet_bruker
   master-password=passordet til opprettet_brukeren
   master-port=port_for_connecting_to_the_master_server
   server-id=id_of_this_slave_server
6. Flytt alle baser fra hovedserveren til slavene.
7. Løpe hovedserveren, deretter alle slavene.