Mysql-replikering av flera databaser. Vad är replikering i MySQL? Vi utför ytterligare åtgärder på slavservern
Data replikering mysql låter dig ha en exakt kopia av databasen från en server - masterservern (ledande server) på en eller flera andra servrar (slavserver). Som standard är Mysql-replikering asynkron.
Vilket innebär att masterservern inte har någon kontroll och inte vet om slavservrarna läser loggfilen och om de gör det korrekt.
Det finns även andra typer av synkronisering, synkron och semi-synkron, där dessa processer styrs.
Beroende på inställningarna kan du replikera både hela databaser och enskilda databastabeller.
Vad kan du använda replikering för:
1. Lastfördelning mellan värdar för att förbättra prestandan.
I ett sådant schema kommer masternoden att utföra läs- och skrivoperationer, noder som har ett abonnemang på masternoden kommer att tillhandahålla en bas för läsning, så vi kommer att befria masterservern från läsoperationer
2. Datasäkerhet och enkel underhåll, eftersom slavnoden innehåller skrivskyddad data, kommer ändringar av data på abonnenten att begränsas, lätt underhåll - möjligheten att köra processer som betjänar databasen utan att avbryta driften av applikationer
3. Distribution av data över långa avstånd. Du kan skapa en kopia av data på vilken värd som helst, oavsett var den befinner sig
mysql stöder följande replikeringsmetoder:
Traditionell – metoden bygger på replikering av händelser från masterns binära loggfil och kräver loggfiler. Positionerna mellan master- och slavservrar måste synkroniseras.
Metod som använder globala transaktionsidentifierare GTID (transaktionsmetod)
mysql stöder följande typer av synkronisering:
asynkron (envägssynkronisering)
halvsynkron (delvis kontroll av abonnenter)
synkron (full kontroll över abonnenter)
Konfigurera Mysql-databasreplikering traditionell metod
Funktionsprincip
Huvudservern innehåller bin loggfiler, som registrerar alla ändringar som sker i huvuddatabasen, en fil som beskriver namnen bin filer, samt platsen i loggen där den senaste stamdatan registrerades
Slavnoden tar emot data från mastern som har information om namnen bin filer och position i loggfilen.
Installation av guiden
min.ini måste innehålla en unik identifierare - ett nummer från 1 till 2 till 32:a potensen - 1, server-id.
Som standard server-id=0, vilket betyder att du inte accepterar prenumerationer från slavservrar
log-bin=mysql-bin
server-id=1
Dessa två rader räcker för att börja
Notera: om InnoDB används, rekommenderas det dessutom att lägga till
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Och du måste kontrollera att förmågan att arbeta med nätverket inte är inaktiverad och att parametern hoppa över nätverk är inställd
Slavservern ansluter till mastern med ett användarnamn och lösenord, så vi skapar först en användare på masterservern
SKAPA ANVÄNDARE repl@%.mydomain.com IDENTIFIERAD AV slavepass;
BIDRAG REPLIKATIONSSLAV PÅ *.* TILL repl@%.mydomain.com;
Låt oss titta på tillståndet
VISA MASTER STATUS
Om proceduren för att skapa binära loggar redan har lanserats måste du för InnoDB-tabeller först låsa tabellerna i en av sessionerna
SPOLA BORD MED LÄSSLÅS;
Om du avslutar sessionen frigörs bordslåset automatiskt
I en annan session får vi namnvärdena bin stock och position
Båda värdena representerar replikeringskoordinaterna vid vilka slavservern måste börja läsa från filen på önskad plats för att börja replikera.
Nästa steg beror på om det finns data på slavservern, data från mastern
Om de finns lämnar vi tabellerna låsta och skapar dumpa(detta är det rekommenderade sättet när du använder InnoDB)
Du kan ta reda på databastypen med kommandot
mysqlshow -u mysql_user -p -i databasnamn
Om databasen är lagrad i binära filer kan de kopieras från mastern till slavservern
Låt oss göra dumpa
mysqldump --all-databases --master-data dbdump.db
för att välja baser mysqldump --databases --master-data dbdump.db
master-data parameter, läggs till automatiskt BYT MASTER TILL på en slavnod, om parametern inte läggs till, måste alla tabeller i sessionen låsas manuellt
Låsa upp
LÅS UPP BORD;
Konfiguration av slavnod A
Lägg till min.ini server-id från personlig från mastern och från andra noder
server-id=2
Skapa ett abonnemang
BYT MASTER TILL
MASTER_HOST=master_host_name,
MASTER_USER=replication_user_name,
MASTER_PASSWORD=replikeringslösenord,
MASTER_LOG_FILE=registrerad_loggfil_namn,
MASTER_LOG_POS=inspelad_loggposition;
När du ställer in replikering med befintliga data måste du överföra en ögonblicksbild från mastern till slaven innan replikeringen påbörjas
Vi använder mysqldump
1.Starta slavnoden med --hoppa-slav-start parameter för att förhindra replikering från att starta
2.Importera dumpfilen
mysql fulldb.dump
3. Starta prenumerationsprocessen
STARTA SLAV;
Kontrollerar replikeringsstatusen
VISA SLAVSTATUS\G
Slave_IO_State: - aktuellt tillstånd för slavenheten
Slave_IO_Running: - om dataströmmen läses från mastern
Slave_SQL_Running: - kör de? sql-frågor, borde vara ja
Exempel Låt oss konfigurera Master (master) server – ip 11.11.11.10 V min.ini
[
mysqld] log-bin=mysql-bin server-id=1
Skapa en användare mysql -u root -p GE REPLIKATIONSSLAV PÅ *.* TO replica@% IDENTIFIERAD MED lösenord; SPOLA PRIVILEGIER;
Därefter låser vi alla tabeller i databasen SPOLA BORD MED LÄSSLÅS;
Vi tittar på status VISA MASTER STATUS;
Vi kommer ihåg filnamnet och positionen, vi kommer att använda dem på slavservern för prenumeration
På Slave B min.ini
log-bin=mysql-bin server-id=2
Skapa ett abonnemang ÄNDRA MASTER TILL MASTER_HOST=11.11.11.10, MASTER_PORT=3306,
MASTER_USER=replika, MASTER_PASSWORD=lösenord,
MASTER_LOG_FILE=server-mysql-bin.000002,
MASTER_LOG_POS=1151664, MASTER_CONNECT_RETRY=10;
STARTA SLAV;
Replikeringsstatus VISA SLAVSTATUS\G
Termen replikering används för att hänvisa till en mekanism för att synkronisera flera kopior av data, vilket ökar informationssäkerheten, feltoleransen och systemets prestanda. Ett slående exempel är databasreplikering mellan två servrar.
Master-Slave MySQL-replikering
I Master-Slave-terminologi är mastern den primära servern med databasen, den skriver till databasen, men läsningen fördelas mellan master och slav beroende på belastningen på systemet, vilket ökar feltoleransen och prestanda. Dessutom, tack vare detta tillvägagångssätt, finns en kopia av databasen alltid till hands och kan återställas om en av servrarna misslyckas.
I vilka situationer kan en slavserver behövas? Till exempel när en stor mängd data anländer för att skrivas till databasen och masterservern helt enkelt inte hinner läsa och klienten måste vänta på slutet av skrivningen, vilket kan undvikas tack vare slavservern.
Situationer är möjliga när masterservern misslyckas, i det här fallet tar slavservern över alla funktioner hos mastern och arbetar ensam tills den återställs. Kunden kommer sannolikt inte att märka något, och han kommer definitivt inte att vänta en timme eller två eller tre på att teknikern ska fixa det.
Att ställa in replikering är inte alls svårt, eftersom mekanismen var inbyggd i MySQL från första början.
Konfiguration på masterservern
Låt oss börja med att redigera konfigurationsfilen my.cnf, som oftast finns på /etc/mysql/my.cnf. Du måste hitta och avkommentera (ta bort #), eller skriva sådana rader.
Bind-adress = 0.0.0.0 server-id = 1 log_bin = /var/log/mysql/mysql-bin.log
Viktig! Om bind-adress redan har registrerats måste den ändras, annars går det inte att upprätta en anslutning mellan servrarna.
Omedelbart efter detta kommer vi att starta om databasen på servern.
/etc/init.d/mysql starta om
Nu måste vi skapa en användare med rättigheter att replikera vår databas, detta kan göras från root in MySQL-konsol med hjälp av kommandot
BILJA REPLIKATIONSSLAV PÅ *.* TILL "slave_user"@"%" IDENTIFIERAD AV "slave_password"; SPOLA PRIVILEGIER;
Där istället för "slave_user" och "slave_password" måste du skriva inloggning och lösenord för slaven.
Låt oss nu titta på masterdata
VISA MASTER STATUS;
Kolumnvärden Fil Och Placera du måste komma ihåg att de kommer att användas för att ställa in slaven, vilket är vad vi går vidare till nu.
Konfigurera på slavservern
Det första steget är att skapa en databas med samma namn som den vi ska replikera. Detta är ett viktigt steg och bör inte försummas. Gå sedan till konfigurationsfilen som redan är bekant för oss min.cnf och skriv inställningarna.
Server-id = 2 relay-log = /var/log/mysql/mysql-relay-bin.log bin-log = /var/log/mysql/mysql-bin.log
Viktig! I bin-log skrivs sökvägen till bin-loggen på mesterservern . Server-ID:t måste skilja sig från huvud-ID:t, det är bekvämt att ställa in det på 1 till.
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; STARTA SLAV;
Där host är masterns IP-adress, login och lösenord motsvarar de vi skapade på mastern, master_log_file och master_log_pos fylls med information från det sista objektet för att konfigurera huvudservern .
Från och med detta ögonblick kommer alla ändringar i databasen att överföras från mastern till slaven.
Kontrollerar replikeringsstatus
Förutom kommandot SHOW MASTER STATUS; Det finns en liknande för slaven VISA SLAVSTATUS\G, som visar en tabell med information. Det främsta tecknet på att servrarna har anslutit och fungerar korrekt är förekomsten av sådana linjer
Replikering- en teknik som används i arkitekturen för system som arbetar under belastning, vars resultat är fördelningen av belastningen när man arbetar med en databas över flera servrar. MySQL MASTER SLAVE replikering används oftare, men en andra typ av replikering används också - Master-Master.
Vad är MySQL MASTER SLAVE replikering och vad används det till?
Replikering Mästare-Slav involverar duplicering av data till en slav MySQL-server; sådan duplicering utförs mest för att säkerställa tillförlitlighet. Om masterservern misslyckas växlas dess funktioner till slav.
Replikering kan också utföras för att förbättra systemets prestanda, men prestandan är nästan alltid sekundär här.
När en applikation arbetar med en databas är de vanligaste operationerna VÄLJ- förfrågningar om att läsa data, modifiera data - förfrågningar RADERA, FÖRA IN, UPPDATERING, ÄNDRA Statistiskt sett händer det mycket mindre ofta.
För att förhindra dataförlust om en av servrarna misslyckas, bearbetas åtgärder för att ändra information i tabeller alltid av huvudservern. Ändringarna replikeras sedan till slaven. Läsning kan göras från en server som spelar rollen som slav.
På grund av detta kan du få en vinst i prestanda tillsammans med tillförlitlighet.
Lösningen är populär, men inte alltid tillämpbar eftersom det kan uppstå förseningar under replikering - om detta händer måste informationen också läsas från Master-servern.
Att rikta förfrågningar av en viss typ till en viss databasserver implementeras i alla fall på applikationsnivå.
Om du gör uppdelningen VÄLJ frågor och alla andra på programnivå, skicka dem till önskad server när en av dem misslyckas, applikationen som infrastrukturen betjänar kommer att vara inoperabel. För att detta ska fungera måste du ge mer komplex krets och reservera var och en av servrarna.
Replikering är för feltolerans, inte för skalning.
MySQL MASTER SLAVE replikering - inställning på Debian
Vi kommer att använda två servrar med adresser:
- Huvudserver 192.168.0.1
- Slavserver 192.168.0.2
För demonstration används VDS ansluten till ett lokalt nätverk.
För att alltid veta säkert på vilken server vi kör det eller det kommandot, kommer vi att redigera /etc/hosts-filerna på båda servrarna
192.168.0.1 mästare
192.168.0.2 slav
Låt oss ersätta de befintliga värdena i /etc/hostname med master respektive slav så att ändringarna träder i kraft och startar om servern.
1. Vi gör inställningar på masterservern.
root@master:/#
Redigerar den huvudsakliga konfigurationsfil databasserver
mcedit /etc/mysql/my.cnf
Välj server-ID - du kan ange vilket nummer som helst, standard är 1 - avkommentera bara raden
server-id = 1
Ställ in sökvägen till den binära loggen - även angiven som standard, avkommentera den
Ställ in namnet på databasen som vi ska replikera till en annan server
binlog_do_db = db1
Starta om Mysql så att konfigurationsfilen läses om och ändringarna träder i kraft:
/etc/init.d/mysql starta om
2. Ställ in användarens nödvändiga rättigheter
Gå till databasserverns konsol:
Vi ger användaren på slavservern de nödvändiga rättigheterna:
BILJA REPLIKATIONSSLAV PÅ *.* TILL "slave_user"@"%" IDENTIFIERAD AV "123";
Låser alla tabeller i databasen
SPOLA BORD MED LÄSSLÅS;
Kontrollera status för masterservern:
+——————+———-+—————+——————+
| Arkiv | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+—————+——————+
| mysql-bin.000001 | 327 | db1 | |
+——————+———-+—————+——————+
1 rad i set (0,00 sek)
3. Skapa en databasdump på servern
Skapa en databasdump:
mysqldump -u root -p db1 > db1.sql
Lås upp tabeller i mysql-konsolen:
4. Överför databasdumpen till slavservern
scp db1.sql [e-postskyddad]:/Hem
Vi utför ytterligare åtgärder på slavservern
root@slave:/#
5. Skapa en databas
Laddar soptippen:
mysql -u rot -p db1< db1.sql
6. Gör ändringar i my.cnf
mcedit /etc/mysql/my.cnf
Vi tilldelar ett ID genom att öka värdet som ställts in på masterservern
server-id = 2
Ställ in sökvägen till reläloggen
relay-log = /var/log/mysql/mysql-relay-bin.log
och sökvägen till bin-loggen på huvudservern
log_bin = /var/log/mysql/mysql-bin.log
Ange basen
binlog_do_db = db1
Startar om tjänsten
/etc/init.d/mysql starta om
7. Skapa en anslutning till huvudservern
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 startar replikering på slavservern:
Du kan kontrollera replikeringen på slaven med följande begäran:
************************** 1. rad ******************** * ******
Slave_IO_State: Väntar på att master ska skicka händelse
Master_Host: 192.168.0.1
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 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
Till_Log_File:
Till_Log_Pos: 0
Master_SSL_Allowed: Nej
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: Nej
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 set (0,00 sek)
Eftersom inga fel inträffade kan vi dra slutsatsen att replikeringen är korrekt konfigurerad.
Är bra verktyg skalning, men den största nackdelen är avsynkronisering av datakopiering och fördröjningar, vilket kan vara kritiskt.
Genom att använda en mer modern lösning kan du helt undvika dem. Det är lätt att installera, pålitligt och eliminerar behovet av att manuellt kopiera databasdumpar.
vispa 8 april 2009 kl 11:10
Grunderna i MySQL-replikering
- MySQL
Jag blev bekant med replikeringen av MySQL-servrar relativt nyligen, och när jag genomförde olika experiment med konfigurationen skrev jag ner vad som fungerade för mig. När jag hade samlat på mig ganska mycket material kom idén att skriva den här artikeln. Jag har försökt samla tips och lösningar på några av de mest grundläggande problemen jag har stött på. Jag kommer att tillhandahålla länkar till dokumentation och andra källor längs vägen. Jag kan inte låtsas beskriva det helt, men jag hoppas att artikeln kommer att vara användbar.
En kort introduktion
Replikering (från latinets replik - jag upprepar) är replikering av dataändringar från huvuddatabasservern till en eller flera beroende servrar. Vi kommer att anropa huvudservern bemästra, och beroende - repliker.Dataändringar som sker på mastern upprepas på replikerna (men inte vice versa). Därför exekveras frågor för att ändra data (INSERT, UPPDATERA, DELETE, etc.) endast på mastern, medan frågor för att läsa data (med andra ord SELECT) kan köras på både repliker och master. Replikeringsprocessen på en av replikerna påverkar inte driften av andra repliker och påverkar praktiskt taget inte befälhavarens arbete.
Replikering utförs med hjälp av binära loggar som underhålls på mastern. De lagrar alla frågor som leder (eller potentiellt leder) till ändringar i databasen (frågor sparas inte explicit, så om du vill titta på dem måste du använda verktyget mysqlbinlog). Binloggarna överförs till replikerna (binloggen som laddas ner från mastern kallas en "reläbinlog") och de lagrade frågorna exekveras med start från en viss position. Det är viktigt att förstå att under replikering är det inte den ändrade datan i sig som överförs, utan bara förfrågningarna som orsakar ändringarna.
Med replikering dupliceras innehållet i databasen på flera servrar. Varför är det nödvändigt att ta till dubbelarbete? Det finns flera anledningar:
- prestanda och skalbarhet. En server kanske inte kan hantera belastningen som orsakas av samtidiga läs- och skrivoperationer i databasen. Fördelarna med att skapa repliker blir större ju fler läsningar per skrivning du har på ditt system.
- feltolerans. I händelse av ett replikfel kan alla läsbegäranden säkert överföras till mastern. Om mastern misslyckas kan skrivbegäranden överföras till repliken (efter att mastern har återställts kan den ta över rollen som repliken).
- säkerhetskopiering av data. Repliken kan "bromsas ner" ett tag för att utföra mysqldump, men mastern kan inte.
- uppskjutna beräkningar. Tunga och långsamma SQL-frågor kan köras på en separat replik utan rädsla för att störa den normala driften av hela systemet.
Konfigurera replikering
Låt oss säga att vi har en fungerande databas MySQL-data, redan fylld med data och inkluderad i arbetet. Och av en av anledningarna som beskrivs ovan kommer vi att aktivera replikering av vår server. Våra första uppgifter:- Huvud-IP-adressen är 192.168.1.101, replikerna är 192.168.1.102.
- MySQL installerat och konfigurerat
- du måste konfigurera testdb-databasreplikering
- vi kan pausa guiden ett tag
- vi har såklart root på båda maskinerna
Inställningar för guiden
Se till att ange det unika server-ID, sökvägen för binära loggar och namnet på databasen för replikering i avsnittet:server-id = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb
Se till att du har tillräckligt med diskutrymme för binära loggar.
Låt oss lägga till replikeringsanvändaren, under vars rättigheter replikering kommer att utföras. Behörigheten "replikeringsslav" kommer att räcka:
mysql@master> BEHANDLA replikeringsslav PÅ "testdb".* TILL "replikation"@"192.168.1.102" IDENTIFIERAD MED "lösenord";
Starta om MySQL för att ändringarna i konfigurationen ska träda i kraft:
root@master# service mysqld omstart
Om allt gick bra bör kommandot "visa masterstatus" visa något så här:
mysql@master>VISA MASTERSTATUS\G
Fil: mysql-bin.000003
Position: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Positionsvärdet bör öka när ändringar görs i databasen på mastern.
Replikinställningar
Låt oss specificera server-ID, namnet på databasen för replikering och sökvägen till reläbinloggarna i konfigurationssektionen och ladda sedan om MySQL: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# tjänst mysqld starta om
Överföra data
Här måste vi låsa databasen för skrivning. För att göra detta kan du antingen stoppa applikationerna eller använda read_only-flaggan på mastern (obs: denna flagga har ingen effekt på användare med SUPER-privilegiet). Om vi har MyISAM-tabeller, låt oss också "spola tabeller":mysql@master> SPOLA TABELLER MED LÄSSLÅS;
mysql@master> SET GLOBAL read_only = PÅ;
Låt oss se masterns status med kommandot "visa masterstatus" och komma ihåg fil- och positionsvärdena (efter att ha lyckats blockera mastern bör de inte ändras):
Fil: mysql-bin.000003
Position: 98
Vi dumpar databasen och efter att operationen är klar tar vi bort masterns lås:
mysql@master> SET GLOBAL read_only = AV;
Vi överför dumpen till repliken och återställer data från den.
Slutligen startar vi replikering med kommandona "change master to" och "start slave" och se om allt gick bra:
mysql@replica> ÄNDRA MASTER TILL MASTER_HOST = "192.168.1.101", MASTER_USER = "replikering", MASTER_PASSWORD = "lösenord", MASTER_LOG_FILE = "mysql-bin.000003", MASTER_LOG_POS = 98;
mysql@replika> starta slav;
Vi tar värdena för MASTER_LOG_FILE och MASTER_LOG_POS från mastern.
Låt oss se hur replikeringen går med kommandot "visa slavstatus":
mysql@replica> VISA SLAVSTATUS\G
Slave_IO_State: Väntar på att master ska skicka händelse
Master_Host: 192.168.1.101
Master_User: replikering
Master_Port: 3306
Connect_Retry: 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:
Till_Log_Pos: 0
Master_SSL_Allowed: Nej
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 5
Jag har lyft fram de mest intressanta värdena nu. Om replikeringen startar framgångsrikt, bör deras värden vara ungefär desamma som i listan (se beskrivningen av kommandot "visa slavstatus" i dokumentationen). Seconds_Behind_Master-värdet kan vara vilket heltal som helst.
Om replikeringen är normal kommer repliken att följa mastern (loggnumret i Master_Log_File och Exec_Master_Log_Pos-positionen kommer att öka). Fördröjningstiden för repliken från mastern (Seconds_Behind_Master) bör helst vara lika med noll. Om den inte minskar eller växer är det möjligt att belastningen på repliken är för hög - den har helt enkelt inte tid att upprepa förändringarna som sker på mastern.
Om Slave_IO_State är tom och Seconds_Behind_Master är NULL, har replikeringen inte startat. Se MySQL-loggen för att ta reda på orsaken, eliminera den och starta om replikering:
mysql@replika> starta slav;
Genom dessa enkla steg får vi en replika vars data är identisk med data på mastern.
Förresten, den tid då mastern blockeras är den tid då dumpen skapas. Om det tar oacceptabelt lång tid att skapa kan du prova detta:
- blockera skrivning till mastern med flaggan read_only, kom ihåg positionen och stoppa MySQL.
- efter det kopierar du databasfilerna till repliken och aktiverar mastern.
- starta replikering på vanligt sätt.
Lägger till repliker
Anta att vi redan har en fungerande mästare och en replik, och vi behöver lägga till en till till dem. Detta är ännu lättare att göra än att lägga till den första repliken till mastern. Och vad som är mycket trevligare är att det inte finns något behov av att stoppa mästaren för detta.Låt oss först konfigurera MySQL på den andra repliken och se till att vi har angett nödvändiga parametrar i konfigurationen:
server-id = 3
replicate-do-db = testdb
Låt oss nu stoppa replikeringen på den första repliken:
mysql@replica-1> stoppa slav;
Repliken kommer att fortsätta att fungera normalt, men informationen på den kommer inte längre att vara aktuell. Låt oss titta på statusen och komma ihåg huvudpositionen som repliken nådde innan replikeringen stoppades:
mysql@replica-1> VISA SLAVSTATUS\G
Värdena vi behöver är Master_Log_File och Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155
Låt oss skapa en databasdump och fortsätta replikeringen på den första repliken:
mysql@replica-1> STARTA SLAV;
Låt oss återställa data från dumpen på den andra repliken. Aktivera sedan replikering:
mysql@replica-2> ÄNDRA MASTER TILL MASTER_HOST = "192.168.1.101", MASTER_USER = "replikering", MASTER_PASSWORD = "lösenord", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155;
mysql@replica-2> STARTA SLAV;
MASTER_LOG_FILE- och MASTER_LOG_POS-värdena är Master_Log_File- respektive Exec_Master_Log_Pos-värdena från resultatet av kommandot "visa slavstatus" på den första repliken.
Replikering måste börja från den position där den första repliken stoppades (och följaktligen skapas en dump). Således kommer vi att ha två repliker med identiska data.
Slår ihop repliker
Ibland uppstår följande situation: det finns två databaser på mastern, varav en replikeras på en replik och den andra på en annan. Hur ställer man in replikering av två databaser på båda replikerna utan att dumpa dem på mastern eller stänga av den? Helt enkelt genom att använda kommandot "start slave tills".Så vi har en master med databaserna testdb1 och testdb2, som replikeras på replica replica-1 respektive replica-2. Låt oss konfigurera replikering av båda databaserna till replica-1 utan att stoppa mastern.
Stoppa replikering på replica-2 med kommandot och kom ihåg masterns position:
mysql@replica-2> STOPPA SLAV;
mysql@replica-2> VISA SLAVSTATUS\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231
Låt oss skapa en dump av testdb2-databasen och återuppta replikering (detta slutför manipulationerna med replica-2). Vi kommer att återställa dumpningen till replika-1.
Situationen på replica-1 är denna: testdb1-databasen är på en huvudposition och fortsätter att replikera, testdb2-databasen har återställts från en dump från en annan position. Låt oss synkronisera dem.
Låt oss stoppa replikeringen och komma ihåg befälhavarens position:
mysql@replica-1> STOPPA SLAV;
mysql@replica-1> VISA SLAVSTATUS\G
Exec_Master_Log_Pos: 501
Låt oss se till att namnet på den andra databasen i konfigurationen för replica-1 anges i avsnittet:
replicate-do-db = testdb2
Låt oss starta om MySQL för att ändringarna i konfigurationen ska träda i kraft. Förresten, det var möjligt att helt enkelt starta om MySQL utan att stoppa replikeringen - från loggen skulle vi veta vid vilken position i masterreplikeringen stoppade.
Låt oss nu replikera från positionen där replica-2 pausades till positionen där vi precis pausade replikering:
mysql@replica-1> ÄNDRA MASTER TILL MASTER_HOST = "192.168.1.101", MASTER_USER = "replikering", MASTER_PASSWORD = "lösenord", MASTER_LOG_FILE = "mysql-bin.000015", MASTER_LOG_POS = 231;
mysql@replica-1> starta slav tills MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;
Replikeringen kommer att avslutas så snart repliken når den angivna positionen i till-sektionen, varefter båda våra databaser kommer att motsvara samma masterposition (där vi stoppade replikeringen på replica-1). Låt oss se till detta:
mysql@replica-1> VISA SLAVSTATUS\G
mysql@replica-1> STARTA SLAV;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501
Låt oss lägga till namnen på båda databaserna till konfigurationen för replica-1 i avsnittet:
replicate-do-db = testdb1
replicate-do-db = testdb2
Viktigt: varje databas måste listas på en separat rad.
Starta om MySQL och fortsätt replikering:
mysql@replica-1> ÄNDRA MASTER TILL MASTER_HOST = "192.168.1.101", MASTER_USER = "replikering", MASTER_PASSWORD = "lösenord", MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;
När replica-1 kommer ikapp mastern kommer innehållet i deras databas att vara identiskt. Du kan slå samman databasen till replica-2 antingen på liknande sätt eller genom att göra en fullständig dumpning av replica-1.
Slottsmästare och replika
Det kan vara nödvändigt att byta en replik till masterläge, till exempel i händelse av ett masterfel eller när du utför en tekniskt arbete. För att göra en sådan switch möjlig måste du konfigurera repliken som mastern, eller göra den passiv mästare.Låt oss aktivera binär loggning (utöver reläbinloggar) i konfigurationen i avsnittet:
log-bin = /var/lib/mysql/mysql-bin
Och lägg till en användare för replikering:
mysql@master> BEHANDLA replikeringsslav PÅ 'testdb'.* TILL 'replikation'@'192.168.1.101′ IDENTIFIERAD MED "lösenord";
Den passiva mastern utför replikering som en vanlig replik, men dessutom skapar den binära logier – det vill säga vi kan starta replikering från den. Låt oss verifiera detta med kommandot "visa masterstatus":
mysql@replica> VISA MASTER STATUS\G
Fil: mysql-bin.000001
Position: 61
Binlog_Do_DB:
Binlog_Ignore_DB:
Nu, för att växla den passiva mastern till aktivt läge, måste du stoppa replikering på den och aktivera replikering på den tidigare aktiva mastern. För att säkerställa att data inte går förlorade vid tidpunkten för byte, aktiv mästare måste vara skrivlåst.
mysql@master> SPOLA TABELLER MED LÄSSLÅS
mysql@master> SET GLOBAL read_only = PÅ;
mysql@replica> STOPPA SLAV;
mysql@replica> VISA MASTERSTATUS;
Fil: mysql-bin.000001
Position: 61
mysql@master> ÄNDRA MASTER TILL MASTER_HOST = "192.168.1.102", MASTER_USER = "replikering", MASTER_PASSWORD = "lösenord", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 61;
mysql@master> starta slav;
Det var det, så vi bytte den aktiva mästaren. Du kan ta bort blocket från den tidigare mästaren.
Slutsats
Vi har lärt oss lite om hur man ställer in replikering i MySQL och utför några grundläggande operationer. Tyvärr ligger följande viktiga frågor utanför ramen för denna artikel:
- eliminering av enstaka felpunkter (SPF, Single Points of Failure). När du använder den enda MySQL-server, dess misslyckande ledde till att hela systemet misslyckades. När du använder flera servrar kommer fel på någon av dem att resultera i ett systemfel om vi inte specifikt tar hand om detta. Vi måste sörja för att hantera situationen med fel på master och replik. Ett av de befintliga verktygen är MMM, men det kräver modifiering med en fil.
- lastbalansering. När du använder flera repliker skulle vi vilja använda en transparent balanseringsmekanism, speciellt om replikernas prestanda är ojämn. Under Linux är det möjligt att använda en standardlösning - LVS.
- ändrar applikationens logik. I en idealisk situation bör förfrågningar om att läsa data skickas till repliker och förfrågningar om att ändra data ska skickas till mastern. Men på grund av den möjliga fördröjningen av repliker är ett sådant schema ofta ineffektivt och det är nödvändigt att identifiera sådana läsbegäranden som fortfarande måste exekveras på mastern.
Tack för din uppmärksamhet!
Taggar:
- mysql
- replikering
För inte länge sedan blev jag ombedd att prata om replikering i MySQL. Jag bestämde mig för att detta ämne kan vara användbart för många, så i den här artikeln kommer jag att prata om vad är replikering i MySQL, när behövs det och hur man konfigurerar det.
Huvuduppgiften för replikering är kombinera kraften hos flera servrar. Låt oss säga att din webbplats har en dedikerad server, men med tiden blir den mycket besökt och klarar inte längre belastningen. Som ett resultat börjar servern sakta ner och krascha regelbundet. Det enklaste sättet är att köpa en mer kraftfull server, och det är vad de flesta gör. Men förr eller senare kommer det en tid då kostnaden för att höja priset på en server inte motsvarar ökningen av dess prestanda, så det är mer lönsamt att köpa 2 olika servrar för mindre pengar.
Som ett resultat kommer din databas att finnas på två servrar samtidigt. När en huvudserver (aka huvudservern) inte längre klarar sig, byter den till en reserv.
Allt Begäran om databasuppdatering går alltid till huvudservern. Efter att ha uppdaterat huvudservern placerar den information om detta i separat fil, varifrån slavservrarna får all information. Men samplingsoperationer, som vanligtvis är de flesta, och de är de långsammaste, kan redan överföras till slavservrar, eftersom data är samma i båda.
Nu ska vi ta reda på det hur man konfigurerar replikering i MySQL:
- Installera mest senaste versionerna av MySQL till alla servrar.
- Skapa en användare med privilegiet på huvudservern BYTER SLAV. För adressen från vilken den kan ansluta, ange " Allt".
- Stoppa alla servrar.
- I inställningar MySQL(i fil min.cnf) I kapitel
lägg till följande rader: log-bin
server-id=1 Observera att server-id måste vara olika på alla servrar. Det är faktiskt detta som skiljer en server från en annan. - På slavservrar, lägg till i inställningar MySQL följande rader: master-host=master_host_name
master-user=inloggning för den skapade_användaren
master-password=lösenord för den skapade_användaren
master-port=port_for_connecting_to_the_master_server
server-id=id_of_this_slave_server - Flytta alla baser från huvudservern till slavarna.
- Springa huvudservern, sedan alla slavar.
