Kõike MySQL-ist ja MariaDB-st

MySQL replikatsiooni juhend: seadistus, tõrkeotsing, haldus

Edasijõudnutele
目次

1. Mis on MySQL replikatsioon? Ülevaade ja kasutusvaldkonnad

MySQL replikatsioon on funktsioon, mis võimaldab andmebaasi koopiaid reaalajas teistele serveritele sünkroniseerida. Sellega saab suurendada andmebaasi redundantsust ja jõudlust. Järgnevalt selgitame üksikasjalikult, millistes olukordades MySQL replikatsiooni kasutatakse ja kuidas see toimib.

MySQL replikatsiooni ülevaade

MySQL replikatsioon jagab andmebaasi sisu mitme serveri vahel, kasutades master-serverit ja slave-serverit. Täpsemalt loeb slave-server master-serveri binaarlogisse salvestatud andmeuuendused ja rakendab need, võimaldades andmete sünkroniseerimist. Sellega saab, kui master-serveris tekib rike, teenust jätkata, lülitades üle slave-serverile.

MySQL replikatsiooni kasutusvaldkonnad

MySQL replikatsiooni kasutatakse laialdaselt järgmistes olukordades.
  • Kõrge kättesaadavuse tagamine: kasutades slave-serverit rikke korral, saab vähendada seisakuaega minimaalsele tasemele.
  • Koormuse jaotamine: suunates ainult lugemiseks mõeldud päringud slave-serverile, jaotatakse master-serveri koormust.
  • Andmete säilitamine ja varundamine: replikatsioon kopeerib andmeid reaalajas, mistõttu seda saab kasutada ka varundusena.

Replikatsiooni tüübid

MySQL replikatsioonil on andmete sünkroonimise viisi järgi järgmised tüübid.
  • Asünkroonne replikatsioon: master jätkab töötlemist ilma ootamata, kuni slave on saanud uuendusinfo, mis võimaldab kiiret vastust. Kuid rikke korral võib osa andmetest slave’ile jõuda.
  • Pool-sünkroonne replikatsioon: enne töötlemise jätkamist kontrollitakse, et andmed on slave’is kajastatud, mis teeb selle usaldusväärsemaks kui asünkroonne, kuid vastuse kiirus on veidi aeglasem.
Järgnevas jaotises selgitame MySQL replikatsiooni põhimõisteid, nagu binaarlogi ja GTID.

2. MySQL replikatsiooni põhilised kontseptsioonid

MySQL replikatsiooni mõistmiseks on oluline mõista replikatsioonis olulist rolli mängivaid binaarlogi ja GTID (Global Transaction ID) rolli. Need elemendid on andmete täpseks kopeerimiseks aluseks.

Peaserveri ja alaserveri rollid

MySQL replikatsioonis täidavad peaserver ja alaserver erinevaid rolle. Peaserver salvestab andmete uuendused binaarlogi ja edastab selle alaserverile. Alaserver rakendab peaserverist saadud logi ja uuendab andmeid. Sellega suudab alaserver hoida sama sisu kui peaserveri uusimad andmed.

Binaarlogi ja relaylogi

MySQL replikatsiooni aluseks kasutatakse järgmisi kahte logi.
  1. Binaarlogi（Binary Log）
  • Binaarlogi salvestab peaserveris toimunud andmete uuendused (INSERT、UPDATE、DELETE jne). Sellega saab alaserver hoida sama andmeolekut nagu peaserver.
  1. Relaylogi（Relay Log）
  • Relaylogi on alaserveri poolt peaserverist saadud binaarlogi salvestamine oma süsteemi. Alaserveri SQL-lõim rakendab seda relaylogi järjestikku, kajastades andmete muudatusi.

GTID (Global Transaction ID) on

GTID on mehhanism, mis määrab igale tehingule unikaalse ID, aidates säilitada mitme alaserveri sünkroonimise terviklikkust. GTID kasutamisega ei ole vaja binaarlogi positsiooni määrata ning saab automaatselt rakendada ainult need tehingud, mida peaserver ei ole veel kätte saanud, mis lihtsustab haldamist märkimisväärselt.

GTID eelised

  • Unikaalne identifitseerimine: Iga tehingule omistatakse unikaalne GTID, mis teeb selgeks, millised tehingud on rakendatud.
  • Taastamine on lihtne: GTID kasutamisega, isegi kui peaserver või alaserver taaskäivitub, rakendatakse ainult need tehingud, mis pole veel rakendatud.
  • Operatiivse halduse tõhustamine: Ka suurtel keskkondadel, kus on mitu alaserverit, on võimalik tehingute terviklikkust säilitades haldust lihtsasti korraldada.
GTID kasutamiseks on vajalikud seaded gtid_mode=ON ja enforce_gtid_consistency=ON. Peaserveris ja alaserveris nende seadistamisega saab GTID-põhise replikatsiooni aktiveerida. Järgmises sektsioonis selgitatakse MySQL replikatsiooni konkreetseid seadistamise samme.

3. MySQL replikatsiooni seadistamise juhised

Siin selgitame üksikasjalikult MySQL replikatsiooni seadistamise samme. Järgides allolevaid juhiseid, saate luua põhikonfiguratsiooni master- ja slave-serverite vahel ning saavutada andmete reaalajas sünkroonimise.

Master-serveri seadistamine

Esiteks redigeerige master-serveri seadistusfaili (tavaliselt my.cnf või my.ini), et lubada binaarlogi ja määrata serveri ID.
  • Lisage järgmised seaded [mysqld] sektsiooni ja määrake serveri ID unikaalseks väärtuseks (näiteks 1).
   [mysqld]
   server-id=1
   log-bin=mysql-bin
  • server-id peab iga serveri puhul olema erinev unikaalne number ning log-bin tähendab binaarlogi lubamist.
  1. Replikatsiooni kasutaja loomine
  • Looge master-serveris replikatsiooniks mõeldud kasutaja ja andke talle vajalikud õigused.
   CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
   GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
   FLUSH PRIVILEGES;
  • See kasutaja on vajalik, et slave-server saaks juurdepääsu masteri andmetele.
  1. Masteri oleku kontroll
  • Kontrollige praegust binaarlogifaili ja positsiooni (logi asukoht). See teave on vajalik slave-serveri seadistamisel.
   SHOW MASTER STATUS;
  • Selle käsu väljundis kuvatavad File (logifaili nimi) ja Position (asukoht) kasutatakse slave-i seadistamisel.

Slave-serveri seadistamine

Seejärel redigeerige slave-serveri seadistusfaili, et määrata serveri ID ja masteri teave.
  1. Seadistusfaili redigeerimine
  • Ka slave-serveril tuleb server-id määrata unikaalseks (näiteks 2). Serveri ID peab olema erinev master-serveri ID-st.
   [mysqld]
   server-id=2
  • Andmete kirjutamise vältimiseks slave-serveris on tavaliselt seadistatud read_only=ON.
  1. Masteri teabe seadistamine slave-is
  • Käivitage slave-serveris järgmine käsk, et määrata masteri hostinimi, kasutaja, binaarlogifaili nimi ja positsioon.
   CHANGE MASTER TO
       MASTER_HOST='master_host',
       MASTER_USER='repl',
       MASTER_PASSWORD='password',
       MASTER_LOG_FILE='mysql-bin.000001',
       MASTER_LOG_POS=123;
  • MASTER_LOG_FILE ja MASTER_LOG_POS väärtused tuleb sisestada, kasutades masteris eelnevalt kontrollitud väärtusi.
  1. Replikatsiooni käivitamine
  • Käivitage slave-serveris järgmine käsk, et alustada replikatsiooni.
   START SLAVE;

Replikatsiooni oleku kontroll

Kontrollige, kas masteri ja slave’i vahel on replikatsioon õigesti seadistatud.
  • Masteri oleku kontroll
  SHOW MASTER STATUS;
  • Slave’i oleku kontroll
  SHOW SLAVE STATUSG;
  • Kui Slave_IO_Running ja Slave_SQL_Running näitavad Yes, siis replikatsioon töötab korralikult.
Järgmises sektsioonis käsitleme MySQL replikatsiooni edasijõudnud seadistusmeetodeid. Räägime asünkroonse ja pool-sünkroonse replikatsiooni erinevustest ning GTID-i kasutamisest seadistamise juhistes.

4. Replikatsiooni tüübid ja rakendused

MySQL replikatsioonis on andmete sünkroonimismeetodi põhjal asünkroonne replikatsioon ja pool-sünkroonne replikatsioon kaks tüüpi. Nende omaduste ja kasutusstsenaariumide põhjal valikukriteeriumide mõistmine võimaldab süsteemi jõudlust ja usaldusväärsust parandada. Samuti selgitame siin GTID (Global Transaction Identifier) kasutamise eeliseid replikatsiooni seadistamisel.

Asünkroonse replikatsiooni ja pool-sünkroonse replikatsiooni erinevused

1. Asünkroonne replikatsioon

Asünkroonne replikatsioon tagastab kliendile kohe vastuse, kui master-server on tehingu lõpetanud. See tähendab, et isegi kui andmete sünkroonimine-serveriga viibib, saab master uusi päringuid töödelda. Seetõttu on see suurepärane vastuse kiiruse poolest ja sobib koormuse jaotamise eesmärgiga süsteemidele. Kuid tuleb tähele panna, et rikete korral võib masteris olev, slave’ile veel mitte edastatud andmed kaduda.

2. Pool-sünkroonne replikatsioon

Pool-sünkroonne replikatsioon tagastab kliendile vastuse alles siis, kui master on kinnitanud, et andmete edastamine slave-serverile on lõpetatud. See parandab andmete terviklikkust, kuid kuna oodatakse slave’i kinnitamist, võib tehingu vastamise aeg pikeneda. Pool-sünkroonne replikatsioon sobib süsteemidele, kus nõutakse kõrget andmete terviklikkust või kus andmete usaldusväärsus on esmatähtis.

GTID kasutamisega replikatsioon

GTID (Global Transaction Identifier) lisab igale tehingule unikaalse ID, mis võimaldab master- ja slave-serveritel tehingute terviklikkust säilitada. GTID kasutuselevõtt muudab replikatsiooni haldamise lihtsamaks võrreldes traditsioonilise binaarlogi positsioonipõhise replikatsiooniga.

GTID eelised

  • Andmete terviklikkuse parandamine: GTID võimaldab slave’i poolel automaatselt tuvastada rakendamata tehingud, mis teeb andmete terviklikkuse säilitamise lihtsamaks.
  • Replikatsiooni haldamise lihtsustamine: GTID kasutamisel saab master- ja slave-serverite vahetust ning taastamist tõhusamalt teha. Binaarlogi positsiooni määramine ei ole enam vajalik, mis muudab haldamise lihtsamaks.

GTID replikatsiooni seadistamine

GTID kasutamiseks tuleb master- ja slave-serverite seadistusfailidesse lisada järgmised valikud ja need aktiveerida. Master-serveri seadistus
[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON
Slave-serveri seadistus
[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON
GTID lubatud keskkonnas piisab, kui slave’ile kasutatakse CHANGE MASTER TO käsku masteri teabe seadistamiseks, et GTID-põhine replikatsioon toimiks automaatselt. Järgmises sektsioonis selgitame MySQL replikatsiooni hooldusmeetodeid ja operatiivse haldamise jälgimispunkte.

5. Replikatsiooni hooldus ja jälgimine

MySQL replikatsiooni nõuetekohaseks kasutamiseks on regulaarne hooldus ja jälgimine hädavajalik. Selles sektsioonis selgitame käske, millega kontrollida, kas replikatsioon töötab korralikult, ning tavapäraste vigade lahendamise meetodeid.

Replikatsiooni oleku kontrollimise meetod

Replikatsiooni oleku mõistmiseks kasutage allolevaid käske, et kontrollida masteri ja alammasina (slave) sünkroonimise olukorda.

Masteri oleku kontroll

Masteri serveri replikatsiooni olekut saab kontrollida käsuga SHOW MASTER STATUS. See käsk näitab praeguse binaarlogifaili nime ja positsiooni (asukohta), võimaldades kontrollida viimaseid uuendusi, mis peaksid alamm edastama.
SHOW MASTER STATUS;
Selle käsu väljund sisaldab järgmisi elemente:
  • File: Masteri praeguse binaarlogifaili nimi
  • Position: Praegune positsioon binaarlogis
  • Binlog_Do_DB ja Binlog_Ignore_DB: Replikatsiooni sihtandmebaasid

Alammasina (slave) oleku kontroll

Alammasina serveri replikatsiooni olukorda saab kontrollida käsuga SHOW SLAVE STATUS. Selle käsu tulemus sisaldab teavet, millega hinnata, kas alammasina server töötab korralikult.
SHOW SLAVE STATUSG;
Oluliste elementidena on järgmised:
  • Slave_IO_Running ja Slave_SQL_Running: Kui mõlemad on Yes, näitab see, et alammasina töötab korralikult.
  • Seconds_Behind_Master: Näitab, mitu sekundit alammasina masterist maha jääb. Ideaalis peaks see väärtus olema 0.

Replikatsiooni tõrkeotsing

Replikatsiooni kasutamise ajal esinevad tavalised probleemid hõlmavad ühenduse vigu ja andmete ebaühtsust. Allpool on toodud levinud veateated ja nende lahendused.

1. Ühenduse viga

Kui Slave_IO_Running on No, tähendab see, et alammasina ei suuda masteriga ühenduda. Proovige järgmist lahendust.
  • Masteri serveri hostinime või IP-aadressi kontroll: Veenduge, et masteri aadress on õige.
  • Firewalli seadistuste kontroll: Veenduge, et vajalikud pordid (tavaliselt 3306) on avatud.

2. Andmete ebaühtsus

Kui Last_Error sisaldab veateadet, võib masteri ja alammasina vahel esineda andmete ebaühtsus. Kui see juhtub, tuleb alammasina peatada ja seejärel parandada.
STOP SLAVE;
# Pärast parandamist jätkamine
START SLAVE;

3. Viivituste kõrvaldamine

Alammasina viivituste põhjuseks võivad olla alammasina riistvaravõimekus või võrgu probleemid. Vajadusel saab alammasina konfiguratsiooni tugevdamisega olukorda parandada. Järgmises sektsioonis süveneme replikatsiooni probleemide üksikasjadesse ja nende lahendustesse.

6. Sageli esinevad probleemid ja nende lahendamise viisid

MySQL replikatsioonis võib kasutamise käigus tekkida mitmesuguseid probleeme. Siin selgitame üksikasjalikult sageli esinevaid probleeme ja nende lahendamise viise. Probleemide varajane avastamine ja õigeaegne lahendamine võimaldab säilitada süsteemi stabiilset tööd.

1. Kui Slave_IO_Running on peatatud

Ilmnemine: SHOW SLAVE STATUS käsu väljund näitab, et Slave_IO_Running on No, siis see näitab, et alamsõlm (slave) ei suuda masteriga ühendust luua. Põhjused ja lahendused:
  • Võrgu probleem: Kui võrguühenduses on probleeme, ei saa alamsõlm masteriga ühendust. Kontrolli tulemüüri seadeid ja veendu, et master on ligipääsetav.
  • Masteri hostinime või IP-aadressi vale seadistus: Kontrolli, et CHANGE MASTER TO käsus määratud hostinimi või IP-aadress oleks õige.
  • Kasutajaõiguste probleem: Kui masteris seadistatud replikatsioonikasutajal ei ole piisavaid õigusi, ebaõnnestub ühendus. Veendu, et GRANT REPLICATION SLAVE on õiged õigused andnud.

2. Alamsõlme andmete ebakõla

Ilmnemine: Kui alamsõlme ja masteri andmed ei kattu, võib alamsõlme andmed olla ebakõlas. Põhjused ja lahendused:
  • Andmete käsitsi parandamine: Kui tekib ebakõla, peata alamsõlm ja paranda probleemne tehing käsitsi. Pärast parandamist käivita alamsõlm uuesti, et replikatsioon taastada. STOP SLAVE; # Vajadusel andmeid parandada START SLAVE;
  • Andmete taasünkroniseerimine: Kui tekib suur ebakõla, tee masterist täiskopeering ja tee alamsõlme taasünkroniseerimine, et probleem lahendada.

3. Replikatsiooni viivitus

Ilmnemine: Kui SHOW SLAVE STATUS väljund näitab, et Seconds_Behind_Master ei ole 0, siis alamsõlm on masterist viibinud. Tavaliselt on väiksem väärtus parem. Põhjused ja lahendused:
  • Alamsõlme riistvaraline jõudlus: Kui alamsõlme serveri spetsifikatsioonid on madalad, ei jõua töötlus sammu pidada, mis põhjustab viivitusi. Riistvara uuendamine on tõhus lahendus.
  • Päringute optimeerimine: Kui masterist saadetud päringute täitmine alamsõlmes võtab palju aega, tekib viivitus. Indeksite lisamine ja päringute optimeerimine aitab tööaega vähendada.

4. Replikatsioonikasutaja õiguste viga

Ilmnemine: Kui Last_Error näitab õigustega seotud veateadetõlmel puududa masteriga ühendamiseks vajalikud õigused. Põhjused ja lahendused:
  • Õiguste andmine uuesti seadistamise kaudu: Veendu, et masteris on loodud kasutaja, kellel on vajalikud õigused, ja vajadusel tee uuesti seadistamine. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_aadress'; FLUSH PRIVILEGES;

5. Binaarlogide kasv

Ilmnemine: Masteri binaarlogid võivad kasvada, koormates serveri kettaruumi. Põhjused ja lahendused:
  • Binaarlogide rotatsioon: Regulaarne binaarlogide kustutamine või arhiveerimine takistab nende kasvu. expire_logs_days seadistamisega saab automaatselt kustutada kindla aja möödudes logid. SET GLOBAL expire_logs_days = 7; # Kustuta logid, mis vanemad kui 7 päeva
Nii saadades, kui mõistad MySQL replikatsiooni esinevaid probleeme ja nende lahendusi, on võimalik sujuvat haldust tagada. Järgnevas sektsioonis võetakse kokku artikli kokkuvõte ja vaadatakse üle replikatsiooni haldamise peamised punktid.

7. Kokkuvõte

MySQL replikatsioon on oluline funktsioon, mis aitab parandada andmete terviklikkust ja süsteemi usaldusväärsust. Selles artiklis käsitlesime MySQL replikatsiooni põhitõdesid, seadistamise samme, jälgimist ja tõrkeotsingut operatiivhalduse käigus. Lõpuks võtsime kokku replikatsiooni operatiivhalduse olulised punktid.

Oluliste punktide ülevaade

  1. Replikatsiooni tüübid ja valik
  • Asünkroonne replikatsioon pakub suurepärast reageerimiskiirust ja sobib hästi koormuse jaotamiseks, kuid kui on vaja usaldusväärsust, on sobiv pool‑sünkroonne replikatsioon. Valige süsteemi nõuetele vastav meetod.
  1. GTID kasutamine
  • GTID kasutamisega ei ole vaja binaarlogi positsiooni määrata, mis võimaldab sujuvat tehingute haldamist. See on eriti kasulik keskkondades, kus on mitu alamsõlme, või süsteemides, kus on oluline tõrke taastamine.
  1. Regulaarne oleku kontroll
  • SHOW MASTER STATUS ja SHOW SLAVE STATUS käskude kasutamine on oluline, et regulaarselt jälgida masteri ja alamsõlme tööolekut. Kui tuvastatakse kõrvalekaldeid, tuleb kiiresti reageerida, et minimeerida andmete ebatäpsuse ja viivituste riski.
  1. Üldiste tõrkeotsingu oskuste omandamine
  • Alamsõlme ühenduse vead, andmete ebatäpsus, viivitused jne on MySQL replikatsiooni spetsiifilised probleemid. Nende probleemide põhiliste lahenduste mõistmine aitab operatsiooni ajal tõrkeid sujuvalt lahendada.
  1. Binaarlogi haldamine
  • Kuna binaarlogi kasvamine koormab serveri kettaruumi, soovitatav on kasutada expire_logs_days seadet automaatseks kustutamiseks ja regulaarselt hooldust teha.
MySQL replikatsioon ei lõpe pärast ühekordset seadistamist; igapäevane jälgimine ja õige hooldus on hädavajalikud. Regulaarne oleku kontroll ja vajadusel seadistuste ülevaatamine võimaldavad luua ja säilitada usaldusväärset andmebaasisüsteemi. Loodame, et see artikkel aitab teil mõista ja rakendada MySQL replikatsiooni. Soovime, et teie tulevane replikatsiooni haldus oleks sujuv.