Material från Linux Wiki

Konfigurera replikering

Master server

min.cnf på huvudservern:

[mySQL]# Server-ID. På varje gäng servrar (både på masters och på slavar) måste det vara unikt. # Är ett tal i intervallet från 1 till 4294967295 (2 ^32 -1 ) server-id = 1 # Sökväg till de binära loggarna, som sparar alla ändringar i huvudserverdatabasen. Det måste finnas tillräckligt med utrymme för dessa loggar log-bin = /var/lib/mysql/mysql-bin # Hur många dagar för att lagra binära loggar på mastern. På något sätt avgör detta också hur mycket slaven kan släpa efter master # expire_logs_days = 10 # Storlek på binlogfilen (varje enskild fil) # max_binlog_size = 1024M # Aktivera komprimering av loggar som skickas till slaven slave_compressed_protocol = 1 # Namn på databasen för vilken denna replikering ska utföras. Om du behöver replikera flera databaser, upprepa alternativet med önskat databasnamn replicate-do-db = testdb # Utöver detta alternativ finns det andra alternativ "omvänt val"- för att utesluta databasval # replicate-ignore-db= database_name # samt alternativ för replikering av individuella tabeller (på liknande sätt - välj en/flera ; exkludera en/flera, samt definiera namn med jokertecken)# Det här alternativet behövs om den här masterservern är en slav i förhållande till en annan - så att slaven för denna master (underslav till huvudmastern) också får uppdateringar # Kan vara användbart när du replikerar en mastermaster med en slav # log-slave -uppdateringar

Vi ger slavservern rättigheter att replikera från denna. För att göra detta, i mysql-konsolen utfärdar vi kommandot:

mysql> GRANTA replikeringsslav PÅ * .* TILL "repluser" @"replhost" IDENTIFIERAD AV "replpass" ;

återköpare- användarnamn för att ansluta. Användaren skapas när kommandot körs.
replhost- IP-adress eller domän för slavservervärden som kommer att ansluta till denna master och importera ändringar från den.
replpass- lösenord för anslutning

Begränsningen av basen för replikering i beviljande replikering verkar inte fungera - det vill säga vi tillåter allt, men i konfigurationen anger vi bara basen / baserna som behövs

Vi startar om servern, varefter du kan köra kommandot i konsolen

mysql> VISA MASTER STATUS ;

som kommer att visa den binära loggfilen som mastern för närvarande arbetar med och den aktuella positionen i loggen, samt databasen/baserna för vilka replikering görs.

Slavserver

Lägg till de nödvändiga alternativen i konfigurationen min.cnf på slavservern:

[mySQL]# Serveridentifierare för denna länk av servrar - se beskrivningen ovan server-id = 2 # Reläloggar - loggar hämtade från masterservern # Ange sökvägen för dessa loggar ; Det bör finnas tillräckligt med utrymme för att förvara dem.# relä-logg = /var/lib/mysql/mysql-relay-bin# relä-logg-index = /var/lib/mysql/mysql-relay-bin.index# Namn på databasen som vi kommer att replikera replicate-do-db = testdb # Aktivera komprimering av loggar som skickas till Slave slave_compressed_protocol = 1

Starta om servern för att tillämpa ändringarna

Startar replikering

På mastern låser vi tabellerna för att skriva för att få en helt korrekt dump:

mysql> SPOLA TABELLER MED LÄSSLÅS ; mysql> SET GLOBAL read_only = PÅ ;

Vi slår samman dumpningen från servern. På vissa ställen brukar de skriva att du måste titta på positionen och namnet på loggen på mastern - detta är inte nödvändigt och kan lösas med nyckeln --basdata för mysqldump, som kommer att skriva den nödvändiga informationen till själva dumpen:

mysqldump --master-data -hmasterhost -umasteruser -pmasterpass masterdbname > dump.sql

Efter det sätter vi guiden igång:

mysql> SET GLOBAL read_only = AV;

(även om tanken uppstår - är det verkligen nödvändigt att låsa databasen vid dumpning? Så fort dumpningen börjar med --master-data, slängs loggnamnet och positionen in i den, och tabellerna låses automatiskt för inspelning - d.v.s. allt är sig likt, bara i automatiskt läge)

mysql -hslavehost -uslaveuser -pslavepass slavedbname< dump.sql

I I detta fall slavedbname = masterdbname, men om du vill kan du göra databasen replikerad under ett annat namn.

Vi anger för slaven adressen till masterservern:

mysql> CHANGE MASTER TO MASTER_HOST = "masterip" , MASTER_USER = "repluser" , MASTER_PASSWORD = "replpass" ;

Var masterip- IP-adress eller domän för masterservern, och de återstående alternativen är de som angavs ovan när mastern konfigurerades. Loggfilens namn och position tas från dumpen, men om så önskas kan de specificeras manuellt med alternativen MASTER_LOG_FILE = "log_name", MASTER_LOG_POS = position

Efter detta kommando sparas information om mastern i filen master.info i databaskatalogen mysql-data-servrar. Om så önskas kan du ange dessa alternativ i slavserverns konfiguration:

master-host = masterip master-user = repluser master-lösenord = replpass master-port = 3306

Efter detta startar vi slavservern via mysql-konsolen:

mysql> STARTA SLAV;

Nu kan du kontrollera statusen för slavservern med kommandot

mysql> VISA SLAVSTATUS ;

Av intressant information kan det finnas fält:

Slave_IO_State: Väntar på att master ska skicka händelse, Slave_IO_Running: Ja Och Slave_SQL_Running: Ja- allt fungerar bra :)
Seconds_Behind_Master- hur mycket slaven är bakom husbonden. I normalt läge ska det vara 0, men med en rejäl fördröjning kan det bli 0 om det görs många ändringar på mastern, och kanalen mellan mastern och slaven är smal och den senare har inte tid att ladda ner binlogs från mästaren. I det här fallet är "0" korrekt, men bara för det som redan har laddats ner från loggarna.

Och annan aktuell information som frånvaro av fel, aktuell position och namn på serverloggen, slavlogg, etc.

Diverse

För mysqldump finns det två alternativ för att ange loggnamnet och positionen i dumpfilen: --basdata Och --dump-slav. Den andra är inte tillgänglig överallt:

root@import:~# mysqldump --hjälp | grep "dump-slave" root@import:~# mysqldump --version mysqldump Ver 10.13 Distrib 5.1.61, för portbld-freebsd8.2 (amd64)

Dump-slave[=värde] Det här alternativet liknar --master-data förutom att det används för att dumpa en replikeringsslavserver för att skapa en dumpfil som kan användas för att ställa in en annan server som en slav som har samma master som den dumpade servern. Det gör att dumputgången inkluderar en CHANGE MASTER TO-sats som indikerar de binära loggkoordinaterna (filnamn och position) för den dumpade slavens master (snarare än koordinaterna för den dumpade servern, som görs av --master- dataalternativ). Dessa är masterserverkoordinaterna från vilka slaven ska börja replikera. Detta alternativ lades till i MySQL 5.5.3.

Följaktligen är ett alternativ för att klona en slav, det andra är att skapa en subslav. Med andra ord låter dump-slav dig skapa (med hjälp av slav1) ytterligare en slav1 i master-slave1-slave2-kedjan (positionen i loggen och loggfilen i förhållande till masterloggarna kommer att skrivas till dumpen) , master-data låter dig skapa slave2 - positionen / kommer att skrivas till dumploggen i förhållande till slave1 binlogs.

Replikeringsfel

Fel kan uppstå under replikering av någon anledning, till exempel manuell inmatning av data på slavservern.

Lösningsalternativ.

Konfigurera MySQL-replikering utan att stoppa guiden.

1. Konfigurera huvudservern:

Låt oss titta på var konfigurationen ska vara.

# ps aux | grep my.cnf

mysql 51189 0,0 0,0 17064 1912 — Är 18:35 0:00.05 /bin/sh /usr/local/bin/mysqld_safe —defaults-extra-file= /var/db/mysql/my.cnf—user=mysql —datadir=/var/db/mysql

Om filen saknas kan du kopiera den från exemplet.

# cp /usr/local/share/mysql/my-small.cnf /var/db/mysql/my.cnf

Eller skapa en tom.

# tryck på /var/db/mysql/my.cnf

I den skapade konfigurationen i avsnittet vi skriver.

#Unikt server-ID. Mastern måste ha en replik nedan och inte dupliceras

server - id = 1

#Loggformat

binlog - format = blandat

#Sökväg där binloggen kommer att finnas (Som standard är storleken på en logg 1g)

#Binloglagringstid

expire_logs_days = 30

replicate-do-db = databas_1

replicate-do-db = databas_2

replicate-do-db = databas_3

replicate-do-db = databas_4

#Felloggen

Detta avslutar redigeringen och startar om MySQL med en ny konfiguration.

# /usr/local/etc/rc.d/mysql-server omstart

Nu måste vi lägga till en användare till Master för slavservern.

För replikering räcker REPLIKATIONSSLAV-rättigheterna. Logga in som root på MySQL-servern.

# mysql -uroot -s

Skapa en användare:

mysql> använd mysql;

mysql>SKAPA ANVÄNDARE 'replika'@'ip_address_slave_server';

mysql>BEHANDLA REPLIKATIONSSLAV PÅ*.* TO 'replica'@'ip_address_slave_server' IDENTIFIERAD AV "lösenord_för_användare_replik";

Nu kan du antingen starta om servern eller säga

mysql>SPOLA PRIVILEGIER;

2. Skapa en dump av de nödvändiga databaserna:

Alla baser.

# mysqldump -uroot -p —hoppa över-låsningstabeller —enkeltransaktion —flush-loggar —hex-blob —master-data=2 -A > /usr/home/Timur/dump.sql

Specifika baser.

# mysqldump -uroot -p —hoppa över-låsningstabeller —single-transaction —flush-logs —hex-blob —master-data=2 -B DATABAS DATABAS1 DATABAS2 DATABAS3 > /usr/home/Timur/dump.sql

3. Låt oss titta på vilken binlog vi ska använda och dess position:

# head -n80 /usr/home/Timur/dump.sql | grep "MASTER_LOG_POS"

— ÄNDRA MASTER TILL MASTER_LOG_FILE=' mysql-bin.000049’, MASTER_LOG_POS= 107 ;

Det är tillrådligt att skriva ner det!!!

4. Klicka på dumpen och överför den till slavservern:

# gzip /usr/home/Timur/dump.sql

Vi bokar om.

# scp /usr/home/Timur/dump.sql.gz _address_slave_server:/usr/home/Timur

5. Slavuppställning server (my.cnf).

server - id =2

binlog - format = blandat

log-bin=/var/log/mysql/mysql-bin

expire_logs_days = 30

#Binglogs slav

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

#Instruerar slaven att hålla ett register över uppdateringar som sker på slaven i en binär logg. Som standard är detta alternativ inaktiverat. Det bör vara aktiverat om du vill koppla ihop dina slavservrar.

log-slave-uppdateringar = 1

#Ställ in databaserna på skrivskyddade. För superanvändare detta alternativ gäller inte!!!

skrivskyddad = 1

#Hoppa över dubblettposter. När Seconds_Behind_Master har blivit 0, kommentera och starta om SLAVE

slav-skip-fel=alla

#Ange vilka databaser vi behöver replikera

replicate-do-db = databas_1

replicate-do-db = databas_2

replicate-do-db = databas_3

replicate-do-db = databas_4

#Felloggen

log-error=/var/log/mysql/mysqld-error.log

#För att förhindra slav från att starta när servern startar. Du kan starta den manuellt STARTA SLAVE;

skip-slave-start = På

Starta om servern (MySQL).

6. Ladda upp dumpen till slaven och starta replikering:

Låt oss packa upp det.

# gunzip /usr/local/Timur/dump.sql.gz

Ladda upp dumpningen.

# mysql -uroot -s< /usr/local/Timur/dump.sql

Vi talar om för Slave var data ska hämtas ifrån och börjar. MASTER_LOG_FILE och MASTER_LOG_POS vi tar det vi skrev när vi dumpade databaserna på Master 😉

mysql>ÄNDRA MASTER TILL MASTER_HOST= ‘<>' , MASTER_USER = 'replika' , MASTER_PASSWORD = "lösenord_för_användare_replik", MASTER_LOG_FILE = ‘mysql-bin.000049‘ , MASTER_LOG_POS = 107 ; STARTA SLAVEN ;

Låt oss titta som ett lag VISA SLAVSTATUS\G Har allt börjat för oss?

mysql>VISA SLAVSTATUS\G
**************************** 1. rad ******************** *******
Slave_IO_State: Väntar på att master ska skicka händelse
Master_Host: Här är adressen till masterservern
Master_User: replika
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000049
Read_Master_Log_Pos: 1919771
Relay_Log_File: mysql-relay.000050
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000049
Slave_IO_Running: Ja
Slave_SQL_Running: Ja
Replicate_Do_DB: databas_1,databas_2,databas_3,databas_4,databas_1,databas_2,databas_3,databas_4
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: 1919771
Relay_Log_Space: 3125
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: 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: 5
1 rad i set (0,00 sek)

Allt startade.

Exec_Master_Log_Pos bör öka: 1919771

Om ett fel visas kan du hoppa över det genom att köra:

mysql> STOP SLAVE;SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;START SLAVE;

Här är en kort beskrivning av hur du ställer in fullständig replikering av din MySQL-server. Det antas att alla databaser kommer att replikeras och replikering har inte tidigare konfigurerats. För att slutföra stegen som anges här måste du en kort tid stoppa huvudservern.

Detta är det enklaste sättet att installera en slavserver, men det är inte det enda sättet. Till exempel, om det redan finns en bild av masterservern, masterservern redan har ställt in server-ID och loggar, kan slavservern installeras utan att stoppa masterservern eller ens ställa in uppdateringslås (för mer information, se avsnitt 4.10.7 Vanliga frågor om replikering.

För att bli en äkta MySQL-replikeringsguru rekommenderar vi att du först lär dig, förstår och provar alla kommandon som nämns i Se avsnitt 4.10.6 SQL-kommandon relaterade till replikering. Du bör också granska alternativen för att starta replikering från filen `my.cnf' i Se avsnitt 4.10.5 Replikeringsalternativ från filen `my.cnf'.

Se till att den senaste versionen av MySQL är installerad på master- och slavservern. Använd version 3.23.29 eller senare. Tidigare utgåvor använde ett annat binärt loggformat och innehöll buggar som har fixats i nyare utgåvor. En stor begäran: skicka inte in felrapporter utan att kontrollera om felet finns i den senaste versionen.
Konfigurera en separat replikeringsanvändare på huvudservern med FILE-privilegiet (i MySQL-versioner tidigare än 4.0.2) eller REPLIKATIONSSLAV i nyare MySQL-versioner. Denna användare måste också ha behörighet att ansluta från alla slavservrar. Om användaren endast kommer att utföra replikering (rekommenderas), behöver han inte beviljas några ytterligare privilegier. Till exempel, för att skapa en användare som heter repl som kan komma åt huvudservern från vilken värd som helst, kan du använda följande kommando: mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY " ";
Komplett MySQL-arbete på huvudservern. mysqladmin -u root -p avstängning
Skapa en bild av all data på huvudservern. Det enklaste sättet att göra detta (på Unix) är att skapa tjära arkiv av hela din datakatalog. Den exakta platsen för datakatalogen beror på din installation. tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir Windows-användare kan använda WinZIP eller ett annat liknande program för att skapa ett datakatalogarkiv.
I my.cnf på huvudservern, lägg till poster i postsektionen log-bin och server-id=unikt nummer till sektionen och starta om servern. Det är mycket viktigt att slavserverns ID skiljer sig från masterserverns ID. Vi kan anse att server-id spelar rollen som en IP-adress - det identifierar servern unikt bland replikeringsdeltagare. log-bin server-id=1
Starta om MySQL på huvudservern.
Lägg till följande till my.cnf på slavservrarna: master-host= master-user= master-password= master-port= server-id= ersätt värdena i med de värden som är lämpliga för ditt system . Server-id-värdena måste vara olika på varje server som deltar i replikering. Om server-id-värdet inte är definierat kommer det att sättas till 1, om master-host-värdet inte heller är definierat kommer det att sättas till 2. Observera att om server-id-värdet utelämnas, då master-servern kommer att neka anslutning till alla slavservrar och slavservern vägrar att ansluta till huvudservern. Därför kan du bara utelämna att ställa in server-id-värdet om du säkerhetskopierar med en binär logg.
Kopiera ögonblicksbildsdata till datakatalogen på slavservern(arna). Se till att fil- och katalogbehörigheterna är korrekta. Användaren som kör MySQL måste kunna läsa och skriva data till dem på samma sätt som på huvudservern.
Starta om slavservrarna.

Efter att ha slutfört dessa steg måste slavservern/slavservrarna ansluta till masterservern och justera dess data till eventuella ändringar som inträffade på masterservern efter att bilden accepterades.

Om server-id för slavservern inte är inställt, kommer följande fel att loggas i felloggfilen:

Varning: man bör ställa in server_id till ett värde som inte är 0 om master_host är inställt. Servern kommer inte att fungera som en slav. (Varning: Om master_host anges ska server_id ställas in på ett värde som inte är noll. Servern kommer inte att fungera som en slavserver.)

Om huvudserverns ID inte är inställt kommer slavservrar inte att kunna ansluta till huvudservern.

Om en slavserver av någon anledning inte kan replikera, kan felmeddelanden hittas i felloggen på slavservern.

Efter att slavservern börjar replikera, kommer en `master.info'-fil att visas i samma katalog som felloggen. Filen `master.info' används av slavservern för att spåra vilka binära loggposter från masterservern bearbetas. Ta inte bort eller redigera den här filen om du inte är säker på att det är nödvändigt. Även om du har ett sådant självförtroende är det fortfarande bättre att använda kommandot CHANGE MASTER TO.

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 den andra typen 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 på en slav MySQL-server, sådan dubbelarbete 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å prestandavinster 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å genom att skicka dem till nödvändig server Om en av dem misslyckas kommer applikationen som infrastrukturen betjänar att inte fungera. För att detta ska fungera måste du tillhandahålla ett mer komplext schema 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:

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
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: 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 avsynkroniseringen av datakopiering och förseningar, vilket kan vara kritiskt.

De kan helt undvikas genom att använda mer modern lösning. Det är lätt att installera, pålitligt och eliminerar behovet av att manuellt kopiera databasdumpar.

Dessa dagar används MySQL-databasen nästan överallt som möjligt. Det är omöjligt att föreställa sig en webbplats som skulle fungera utan MySQL. Naturligtvis finns det några undantag, men huvuddelen av marknaden upptas av detta databassystem. Och den mest populära implementeringen är MariaDB. När projektet är litet räcker det med en server för att köra det, på vilken alla tjänster finns: webbserver, databasserver och Mejl server. Men när projektet blir större kan du behöva allokera en separat server för varje tjänst eller till och med dela upp en tjänst i flera servrar, till exempel MySQL.

För att upprätthålla ett synkront tillstånd för databaser på alla servrar samtidigt måste du använda replikering. I den här artikeln kommer vi att titta på hur man konfigurerar MySQL-replikering med MariaDB Galera Cluster.

VAD ÄR MARIADB GALERA?

MariaDB Galera är klustersystem för MariaDB master-master typ. Sedan MariaDB 10.1 programvara Galera Server och MariaDB Server kommer i ett paket, så att du får all programvara du behöver direkt. På det här ögonblicket MariaDB Galera kan bara fungera med InnoDB och XtraDB databasmotorer. En av fördelarna med att använda replikering är tillägget av redundans till webbplatsdatabasen. Om en av databaserna misslyckas kan du omedelbart byta till en annan. Alla servrar upprätthåller ett synkroniserat tillstånd med varandra och säkerställer att det inte finns några förlorade transaktioner.

Viktiga funktioner i MariaDB Galera:

Replikering med konstant synkronisering;
Automatisk sammanslagning av noder;
Möjlighet att ansluta flera masternoder;
Stöd för inspelning till någon av noderna;
Transparent parallell replikering;
Läs- och skrivskalbarhet, minimal latens;
Noder som misslyckas kopplas automatiskt bort från klustret;
Du kan inte blockera åtkomst till tabeller.

KONFIGURERA MYSQL REPLIKATION

I denna handledning kommer vi att använda Ubuntu 16.04 och MariaDB version 10.1 som exempel. Innan du börjar, uppdatera ditt system helt:

sudo apt-get uppdatering-y
sudo apt-get upgrade -y

Eftersom vi kommer att distribuera vår konfiguration till flera noder, måste vi utföra uppdateringsåtgärder på dem alla. Om MariaDB-databasservern inte redan är installerad måste du installera den. Lägg först till förvaret och dess nyckel:

sudo apt-key adv --recv-nycklar --nyckelserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

sudo add-apt-repository "deb http://ftp.utexas.edu/mariadb/repo/10.1/ubuntu xenial main"

sudo apt-get update -y

När uppdateringen av paketlistan är klar, installera MariaDB med kommandot:

sudo apt installera mariadb-server rsync -y

Vi kommer att behöva rsync-paketet för att utföra direkt synkronisering. När installationen är klar måste du säkra databasen med skriptet mysql_secure_installation:

sudo mysql_secure_installation

Som standard är gästinloggning tillåten, det finns en testdatabas och inget lösenord är inställt för rotanvändaren. Allt detta måste fixas. Läs mer i artikeln. Kortfattat måste du svara på några frågor:

Ange nuvarande lösenord för root (enter för ingen):
Ändra root-lösenordet? n
Ta bort anonyma användare? Y
Vill du inte tillåta root-inloggning på distans? Y
Ta bort testdatabasen och få tillgång till den? Y
Ladda om privilegietabeller nu? Y

När allt är klart kan du fortsätta med att ställa in noderna mellan vilka mysql-databaser ska replikeras. Låt oss först titta på hur vi ställer in den första noden. Du kan lägga in alla inställningar i my.cnf, men det skulle vara bättre att skapa separat fil för dessa ändamål i mappen /etc/mysql/conf.d/.

Lägg till dessa rader:

binlog_format=RAD

innodb_autoinc_lock_mode=2
bind-adress=0.0.0.0

wsrep_on=PÅ

wsrep_sst_method=rsync
# Galera Node Configuration
wsrep_node_address="192.168.56.101"
wsrep_node_name="Nod1"

Här är adressen 192.168.56.101 adressen till den aktuella noden. Gå sedan till en annan server och skapa samma fil där:

sudo vi /etc/mysql/conf.d/galera.cnf

binlog_format=RAD
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-adress=0.0.0.0
# Galera Provider Configuration
wsrep_on=PÅ
wsrep_provider=/usr/lib/galera/libgalera_smm.so
# Galera Cluster Configuration
wsrep_cluster_name="galera_cluster"
wsrep_cluster_address="gcomm://192.168.56.101,192.168.56.102"
# Galera Synchronization Configuration
wsrep_sst_method=rsync
# Galera Node Configuration
wsrep_node_address="192.168.56.102"
wsrep_node_name="Nod2"

På liknande sätt är nodadressen här 192.168.0.103. Låt oss fokusera på ett exempel med två servrar, eftersom detta är tillräckligt för att demonstrera systemets funktion, och du kan lägga till en annan server genom att ange ytterligare en IP-adress i fältet wsrep_cluster_address. Låt oss nu titta på vad värdena för huvudparametrarna betyder och gå vidare till lanseringen:

binlog_format- loggformatet i vilket frågorna kommer att sparas, radvärdet indikerar att binär data kommer att lagras där;
standard-lagringsmotor- motor SQL-tabeller som vi kommer att använda;
innodb_autoinc_lock_mode- driftläge för värdegeneratorn AUTO_INCREMENT;
bind-adress- IP-adress på vilken programmet kommer att lyssna efter anslutningar, i vårt fall alla IP-adresser;
wsrep_on- möjliggör replikering;
wsrep_provider- bibliotek med vilket replikering kommer att utföras;
wsrep_cluster_name - klusternamn måste matcha på alla noder;
wsrep_cluster_address- lista över serveradresser mellan vilka mysql-databaser kommer att replikeras, separerade med kommatecken;
wsrep_sst_method- transport som kommer att användas för dataöverföring;
wsrep_node_address- IP-adress för den aktuella noden;
wsrep_node_name- namnet på den aktuella noden.

MySQL-replikeringsinställningen är nästan klar. Det sista steget som återstår innan start är att konfigurera brandväggen. Aktivera först iptables-regelhanteringsverktyget i Ubuntu - UFW:

Öppna sedan följande portar:

sudo ufw tillåter 3306/tcp
sudo ufw tillåter 4444/tcp
sudo ufw tillåter 4567/tcp
sudo ufw tillåter 4568/tcp
sudo ufw tillåter 4567/udp

LANSERAR MARIADB GALERA

Efter att ha lyckats konfigurera alla noder behöver vi bara starta Galera-klustret på den första noden. Innan vi kan starta klustret måste du se till att MariaDB-tjänsten är stoppad på alla servrar:

sudo galera_new_cluster