Datu replikācija mysqlļauj iegūt precīzu datu bāzes kopiju no viena servera - galvenā servera (vadošā servera) vienā vai vairākos citos serveros (vergu serveris). Pēc noklusējuma Mysql replikācija ir asinhrona.
Tas nozīmē, ka galvenajam serverim nav kontroles un tas nezina, vai pakārtotie serveri lasa žurnāla failu un vai viņi to dara pareizi.
Ir arī citi sinhronizācijas veidi, sinhronā un daļēji sinhronā, kur šie procesi tiek kontrolēti.
Atkarībā no iestatījumiem varat replicēt gan visas datu bāzes, gan atsevišķas datu bāzes tabulas.

Kādiem nolūkiem varat izmantot replikāciju:
1. Slodzes sadalījums starp saimniekiem, lai uzlabotu veiktspēju.
Šādā shēmā galvenais mezgls veiks lasīšanas un rakstīšanas operācijas, mezgli, kuriem ir galvenā mezgla abonements, nodrošinās lasīšanas bāzi, tādējādi atbrīvosim galveno serveri no lasīšanas operācijām
2. Datu drošība un apkopes vienkāršība, jo vergu mezglā ir tikai lasāmi dati, izmaiņas datos par abonentu būs ierobežotas, apkopes vienkāršība - iespēja palaist datu bāzi apkalpojošos procesus, nepārtraucot aplikāciju darbību
3. Datu izplatīšana lielos attālumos. Varat izveidot datu kopiju jebkurā resursdatorā neatkarīgi no tā atrašanās vietas
mysql atbalsta šādas replikācijas metodes:
Tradicionālā - metode ir balstīta uz notikumu replikāciju no galvenā binārā žurnālfaila, un tai ir nepieciešami žurnālfaili. Pozīcijām starp galveno un pakārtoto serveriem jābūt sinhronizētām.
Metode, kurā tiek izmantoti globālie darījumu identifikatori GTID (transakciju metode)
mysql atbalsta šādus sinhronizācijas veidus:
asinhrona (vienvirziena sinhronizācija)
daļēji sinhrons (daļēja abonentu kontrole)
sinhrons (pilna abonentu kontrole)

Mysql datu bāzes replikācijas tradicionālās metodes iestatīšana

Darbības princips
Galvenais serveris satur atkritumu tvertnežurnālfaili, kas reģistrē visas izmaiņas, kas notiek galvenajā datu bāzē, fails, kas apraksta nosaukumus atkritumu tvertne failus, kā arī vietu žurnālā, kurā tika ierakstīti pēdējie pamatdati
Vergu mezgls saņem datus no galvenā, kam ir informācija par nosaukumiem atkritumu tvertne failus un atrašanās vietu žurnālfailā.

Vedņa iestatīšana
my.ini jāsatur unikāls identifikators - skaitlis no 1 līdz 2 līdz 32. pakāpei - 1, servera ID.
Pēc noklusējuma server-id=0, kas nozīmē nepieņemt abonementus no vergu serveriem

log-bin=mysql-bin
servera-id=1
Ar šīm divām rindām pietiek, lai sāktu
Piezīme: tomēr, ja tiek izmantots InnoDB, ieteicams papildus pievienot
innodb_flush_log_at_trx_commit=1
sync_binlog=1
Un jums ir jāpārbauda, ​​​​vai iespēja strādāt ar tīklu nav atspējota un ir iestatīts tīkla izlaišanas parametrs
Vergu serveris savienojas ar galveno serveri, izmantojot lietotājvārdu un paroli, tāpēc vispirms mēs izveidojam lietotāju galvenajā serverī
IZVEIDOT LIETOTĀJU repl@%.mydomain.com, ATTIECĪBĀ UZ slavepass;
GRANT REPLICATION SLAVE ON *.* UZ repl@%.mydomain.com;
Apskatīsim stāvokli
RĀDĪT MASTER STATUS
Ja bināro žurnālu izveides procedūra jau ir uzsākta, tad InnoDB tabulām vispirms ir jābloķē tabulas vienā no sesijām
IZSKALOT TABULU AR LASĪŠANAS BLOĶĒJUMU;
Ja izejat no sesijas, galda bloķēšana tiek automātiski atbrīvota
Citā sesijā mēs iegūstam nosaukumu vērtības atkritumu tvertnežurnāls un pozīcija
Abas vērtības atspoguļo replikācijas koordinātas, pēc kurām vergu serverim jāsāk nolasīt no faila vēlamajā vietā, lai sāktu replikāciju.
Nākamais solis ir atkarīgs no tā, vai uz vergu servera ir dati, dati no galvenā
Ja tādas eksistē, tad atstājam tabulas aizslēgtas un veidojam izgāztuve(tas ir ieteicamais veids, lietojot InnoDB)
Jūs varat uzzināt datu bāzes veidu ar komandu
mysqlshow -u mysql_user -p -i datu bāzes nosaukums
Ja datu bāze tiek glabāta bināros failos, tad tos var kopēt no galvenā uz vergu serveri
Daram izgāztuve
mysqldump --all-databases --master-data dbdump.db
lai izvēlētos bāzes mysqldump --databases --master-data dbdump.db
parametrs master-data, tiek automātiski pievienots MAINĪT MASTER UZ vergu mezglā, ja parametrs nav pievienots, tad visas sesijas tabulas ir jābloķē manuāli
Atbloķēt
ATbloķēt galdus;

Vergu mezgla konfigurācija A
Pievienot my.ini servera ID no personīgā no galvenā un no citiem mezgliem

servera-id=2
Izveidojiet abonementu
MAINĪT MASTER UZ
MASTER_HOST=master_host_name,
MASTER_USER=replication_user_name,
MASTER_PASSWORD=replication_password,
MASTER_LOG_FILE=recorded_log_file_name,
MASTER_LOG_POS=ierakstīts_log_pozīcija;
Iestatot replikāciju ar esošiem datiem, pirms replikācijas sākuma ir jāpārsūta momentuzņēmums no galvenā uz vergu.
Mēs izmantojam mysqldump
1. Palaidiet vergu mezglu, izmantojot --skip-slave-start parametrs, lai novērstu replikācijas sākšanos
2. Importējiet izgāztuves failu
mysql fulldb.dump
3. Sāciet abonēšanas procesu
START SLAVE;
Replikācijas statusa pārbaude
RĀDĪT VERGU STATUSU\G
Slave_IO_State: - vergu ierīces pašreizējais stāvoklis
Slave_IO_Running: - vai datu straume tiek nolasīta no galvenā
Slave_SQL_Running: - vai tie darbojas? sql vaicājumi, vajadzētu būt jā

Piemērs Konfigurēsim galveno (galveno) serveri – ip 11.11.11.10 V my.ini
[ mysqld] log-bin=mysql-bin server-id=1
Izveidojiet lietotāju mysql -u root -p PIEŠĶIRT REPLIKĀCIJAS VERGU IESLĒGTS *.* uz replica@% Identificēts PĒC paroles; FLUSH PRIVILĒĢIJAS;
Tālāk mēs bloķējam visas tabulas datu bāzē IZSKALOT TABULU AR LASĪŠANAS BLOĶĒJUMU;
Mēs skatāmies uz stāvokli RĀDĪT MASTER STATUS; Mēs atceramies faila nosaukumu un pozīciju, mēs tos izmantosim Slave serverī abonēšanai

Par vergu B my.ini
log-bin=mysql-bin server-id=2
Izveidojiet abonementu MAINĪT MASTER UZ MASTER_HOST=11.11.11.10, MASTER_PORT=3306,
MASTER_USER=reprodukcija, MASTER_PASSWORD=parole,
MASTER_LOG_FILE=serveris-mysql-bin.000002,
MASTER_LOG_POS=1151664, MASTER_CONNECT_RETRY=10;
START SLAVE;
Replikācijas statuss RĀDĪT SLAVE STATUSU\G

Termins replikācija tiek lietots, lai apzīmētu mehānismu vairāku datu kopiju sinhronizēšanai, kas palielina informācijas drošību, kļūdu toleranci un sistēmas veiktspēju. Spilgts piemērs ir datu bāzes replikācija starp diviem serveriem.

Master-Slave MySQL replikācija

Master-Slave terminoloģijā galvenais serveris ir primārais serveris ar datu bāzi; tas raksta datu bāzē, bet lasīšana tiek sadalīta starp galveno un slaveno serveri atkarībā no sistēmas slodzes, kas palielina kļūdu toleranci un veiktspēju. Turklāt, pateicoties šai pieejai, datu bāzes kopija vienmēr ir pie rokas un to var atjaunot, ja kāds no serveriem neizdodas.

Kādās situācijās var būt nepieciešams vergu serveris? Piemēram, kad pienāk liels datu masīvs, ko rakstīt datu bāzē, un galvenajam serverim vienkārši nav laika lasīt un klientam ir jāgaida rakstīšanas beigas, no kā var izvairīties, pateicoties vergu serverim.

Ir iespējamas situācijas, kad galvenais serveris neizdodas; šajā gadījumā vergu serveris pārņem visas galvenā servera funkcijas un strādā viens, līdz tas tiek atjaunots. Klients, visticamāk, neko nepamanīs, un viņš noteikti negaidīs stundu vai divas vai trīs, līdz tehniķis to izlabos.

Replikācijas iestatīšana nepavisam nav grūta, jo mehānisms MySQL tika iebūvēts jau no paša sākuma.

Iestatīšana galvenajā serverī

Sāksim ar konfigurācijas faila my.cnf rediģēšanu, kas visbiežāk atrodas /etc/mysql/my.cnf. Jums ir jāatrod un jāizņem komentārs (noņemt #) vai jāraksta šādas rindas.

Saistīšanas adrese = 0.0.0.0 servera ID = 1 log_bin = /var/log/mysql/mysql-bin.log

Svarīgs! Ja saistīšanas adrese jau ir reģistrēta, tā ir jāmaina, pretējā gadījumā nebūs iespējams izveidot savienojumu starp serveriem.

Tūlīt pēc tam mēs restartēsim datu bāzi serverī.

/etc/init.d/mysql restart

Tagad mums ir jāizveido lietotājs ar tiesībām replicēt mūsu datu bāzi, to var izdarīt no saknes MySQL konsole izmantojot komandu

PIEŠĶIRT REPLIKĀCIJAS VERGU *.* LIETOŠANAI "slave_user"@"%" ATTIECĪBĀ UZ "slave_password"; FLUSH PRIVILĒĢIJAS;

Kur “slave_user” un “slave_password” vietā ir jāieraksta vergu pieteikšanās vārds un parole.

Tagad apskatīsim pamatdatus

RĀDĪT MASTER STATUS;

Kolonnu vērtības Fails Un Pozīcija jums ir jāatceras, ka tie tiks izmantoti verga iestatīšanā, pie kā mēs tagad pārejam.

Iestatīšana Slave serverī

Pirmais solis ir izveidot datubāzi ar tādu pašu nosaukumu kā tai, kuru mēs gatavojamies replicēt. Tas ir svarīgs solis, un to nevajadzētu atstāt novārtā. Pēc tam dodieties uz konfigurācijas failu, kas mums jau ir pazīstams my.cnf un ierakstiet iestatījumus.

Servera ID = 2 relay-log = /var/log/mysql/mysql-relay-bin.log bin-log = /var/log/mysql/mysql-bin.log

Svarīgs! bin-log tiek ierakstīts ceļš uz bin-log mester serverī . Servera ID ir jāatšķiras no galvenā ID, ir ērti iestatīt to uz 1 vairāk.

MAINĪT MASTER UZ 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;

Ja resursdators ir galvenā IP adrese, pieteikšanās vārds un parole atbilst tiem, ko izveidojām galvenajā ierīcē, master_log_file un master_log_pos tiek aizpildīti ar informāciju no pēdējais vienums galvenā servera konfigurēšanai .

No šī brīža visas izmaiņas datu bāzē tiks pārsūtītas no galvenā uz vergu.

Pārbauda replikācijas statusu

Papildus komandai SHOW MASTER STATUS; Līdzīga ir arī vergam SHOW SLAVE STATUS\G, kas parādīs tabulu ar informāciju. Galvenā pazīme, ka serveri ir savienoti un darbojas pareizi, ir šādu līniju klātbūtne

Replikācija- paņēmiens, ko izmanto slodzes sistēmu arhitektūrā, kuras rezultāts ir slodzes sadalījums, strādājot ar vienu datu bāzi pa vairākiem serveriem. Biežāk tiek izmantota MySQL MASTER SLAVE replikācija, taču tiek izmantots arī otrs replikācijas veids - Master-Master.

Kas ir MySQL MASTER SLAVE replikācija un kādam nolūkam to izmanto?

Replikācija Master-Slave ietver datu dublēšanu uz vergu MySQL serveri; šāda dublēšana galvenokārt tiek veikta, lai nodrošinātu uzticamību. Ja galvenais serveris neizdodas, tā funkcijas tiek pārslēgtas uz Slave.

Replicēšanu var veikt arī, lai uzlabotu sistēmas veiktspēju, taču veiktspēja šeit gandrīz vienmēr ir sekundāra.
Kad lietojumprogramma darbojas ar datu bāzi, visbiežāk tiek veiktas darbības ATLASĪT- pieprasījumi nolasīt datus, modificēt datus - pieprasījumi DZĒST, IEVIETOT, ATJAUNINĀT, ALTER Statistiski tas notiek daudz retāk.

Lai novērstu datu zudumu, ja kāds no serveriem neizdodas, darbības, lai mainītu informāciju tabulās, vienmēr apstrādā galvenais serveris. Pēc tam izmaiņas tiek replicētas Slave. Lasīšanu var veikt no servera, kas spēlē Slave lomu.
Pateicoties tam, jūs varat palielināt veiktspēju un uzticamību.

Risinājums ir populārs, taču ne vienmēr piemērojams, jo replikācijas laikā var būt aizkave - ja tā notiek, informācija ir jānolasa arī no galvenā servera.

Noteikta veida pieprasījumu novirzīšana uz konkrētu datu bāzes serveri jebkurā gadījumā tiek realizēta lietojumprogrammu līmenī.

Ja jūs veicat sadalīšanu ATLASĪT vaicājumus un viss pārējais programmas līmenī, nosūtot tos uz vēlamo serveri, kad kāds no tiem neizdodas, programma, kuru apkalpo infrastruktūra, nedarbosies. Lai tas darbotos, jums ir jānodrošina vairāk sarežģīta ķēde un rezervēt katru no serveriem.

Replikācija ir paredzēta kļūdu pielaidei, nevis mērogošana.

MySQL MASTER SLAVE replikācija — iestatīšana Debian

Mēs izmantosim divus serverus ar adresēm:

• Galvenais serveris 192.168.0.1
• Vergu serveris 192.168.0.2

Demonstrēšanai tiek izmantoti VDS, kas savienoti ar vietējo tīklu.
Lai vienmēr droši zinātu, kurā serverī mēs izpildām šo vai citu komandu, mēs rediģēsim /etc/hosts failus abos serveros

192.168.0.1 meistars

192.168.0.2 vergs

Aizstāsim esošās vērtības mapē /etc/hostname ar attiecīgi galveno un slave, lai izmaiņas stātos spēkā un restartētu serveri.

1. Mēs veicam iestatījumus galvenajā serverī.

root@master:/#

Galvenā rediģēšana konfigurācijas fails datu bāzes serveris

mcedit /etc/mysql/my.cnf

Atlasiet servera ID — varat norādīt jebkuru numuru, noklusējuma vērtība ir 1 — vienkārši noņemiet rindiņas komentāru

servera ID = 1

Iestatiet ceļu uz bināro žurnālu — arī norādīts pēc noklusējuma, noņemiet komentāru

Iestatiet tās datu bāzes nosaukumu, kuru mēs replicēsim citā serverī

binlog_do_db = db1

Restartējiet Mysql, lai konfigurācijas fails tiktu atkārtoti lasīts un izmaiņas stātos spēkā:

/etc/init.d/mysql restart

2. Iestatiet lietotājam nepieciešamās tiesības

Dodieties uz datu bāzes servera konsoli:

Mēs piešķiram lietotājam vergu serverī nepieciešamās tiesības:

PIEŠĶIRT REPLIKĀCIJAS VERGU IESLĒGTS *.* UZ "slave_user"@"%", KO ATZĪST AR "123";

Visu datu bāzē esošo tabulu bloķēšana

IZSKALOT TABULU AR LASĪŠANAS BLOĶĒJUMU;

Galvenā servera statusa pārbaude:

+——————+———-+—————+——————+
| Fails | Pozīcija | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+—————+——————+
| mysql-bin.000001 | 327 | db1 | |
+——————+———-+—————+——————+
1 rinda komplektā (0,00 s)

3. Izveidojiet datu bāzes izgāztuves serverī

Izveidojiet datu bāzes izgāztuvi:

mysqldump -u root -p db1 > db1.sql

Atbloķējiet tabulas mysql konsolē:

4. Pārsūtiet datu bāzes izdruku uz Slave serveri

scp db1.sql [aizsargāts ar e-pastu]:/mājas

Mēs veicam turpmākās darbības Slave serverī

root@slave:/#

5. Datu bāzes izveide

Izgāztuves ielāde:

mysql -u sakne -p db1< db1.sql

6. Veiciet izmaiņas failā my.cnf

mcedit /etc/mysql/my.cnf

Mēs piešķiram ID, palielinot galvenajā serverī iestatīto vērtību

servera ID = 2

Iestatiet ceļu uz releja žurnālu

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

un ceļš uz bin žurnālu galvenajā serverī

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

Norādiet bāzi

binlog_do_db = db1

Pakalpojuma restartēšana

/etc/init.d/mysql restart

7. Iestatiet savienojumu ar galveno serveri

MAINĪT MASTER UZ MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;

Mēs sākam replikāciju vergu serverī:

Varat pārbaudīt replikācijas darbību Slave ar šādu pieprasījumu:

****************************** 1. rinda ******************** * ******
Slave_IO_State: gaida, līdz galvenais nosūtīs notikumu
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: Jā
Slave_SQL_Running: Jā
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
Līdz_nosacījums: nav
Until_Log_File:
Līdz_Log_Pos: 0
Master_SSL_Allowed: Nē
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Sekundes_Behind_Master: 0
Master_SSL_Verify_Server_Cert: Nē
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Galvenā_servera_ID: 1
1 rinda komplektā (0,00 s)

Tā kā kļūdu nav, mēs varam secināt, ka replikācija ir pareizi konfigurēta.

Ir labs instruments mērogošana, bet galvenais trūkums ir datu kopēšanas un aizkaves desinhronizācija, kas var būt kritiska.

Mūsdienīgāka risinājuma izmantošana ļauj no tiem pilnībā izvairīties. To ir viegli iestatīt, tas ir uzticams un novērš nepieciešamību manuāli kopēt datu bāzes izgāztuves.

noslaucīt 2009. gada 8. aprīlī plkst. 11:10

MySQL replikācijas pamati

• MySQL

Ar MySQL serveru replikāciju iepazinos salīdzinoši nesen un, veicot dažādus eksperimentus ar konfigurāciju, pierakstīju, kas man der. Kad biju savācis diezgan daudz materiālu, radās doma uzrakstīt šo rakstu. Esmu mēģinājis apkopot padomus un risinājumus par dažām visvienkāršākajām problēmām, ar kurām esmu saskāries. Es sniegšu saites uz dokumentāciju un citiem avotiem. Es nevaru izlikties, ka to pilnībā aprakstu, bet es ceru, ka raksts būs noderīgs.

Īss ievads

Replikācija (no latīņu valodas repliko — atkārtoju) ir datu izmaiņu replikācija no galvenā datu bāzes servera uz vienu vai vairākiem atkarīgiem serveriem. Mēs izsauksim galveno serveri meistars, un atkarīgs - replikas.
Datu izmaiņas, kas notiek galvenajā ierīcē, atkārtojas replikās (bet ne otrādi). Tāpēc datu maiņas vaicājumi (INSERT, UPDATE, DELETE u.c.) tiek izpildīti tikai galvenajā ierīcē, savukārt vaicājumus datu nolasīšanai (citiem vārdiem sakot, SELECT) var izpildīt gan replikās, gan galvenajā. Replikācijas process vienā no replikām neietekmē citu kopiju darbību un praktiski neietekmē kapteiņa darbu.
Replikācija tiek veikta, izmantojot bināros žurnālus, kas tiek uzturēti galvenajā ierīcē. Tie saglabā visus vaicājumus, kas noved (vai potenciāli noved pie izmaiņām) datu bāzē (vaicājumi netiek tieši saglabāti, tādēļ, ja vēlaties tos apskatīt, jums būs jāizmanto mysqlbinlog utilīta). Binlogs tiek pārsūtīts uz replikām (no galvenā faila lejupielādētais binlog tiek saukts par "releja binlog"), un saglabātie vaicājumi tiek izpildīti, sākot no noteiktas pozīcijas. Ir svarīgi saprast, ka replikācijas laikā netiek pārsūtīti paši mainītie dati, bet gan tikai pieprasījumi, kas izraisa izmaiņas.
Izmantojot replikāciju, datu bāzes saturs tiek dublēts vairākos serveros. Kāpēc ir nepieciešams ķerties pie dublēšanās? Ir vairāki iemesli:

• veiktspēju un mērogojamību. Viens serveris var nespēt izturēt slodzi, ko rada vienlaicīgas lasīšanas un rakstīšanas darbības datu bāzē. Reprodukciju izveides priekšrocības būs lielākas, jo vairāk lasīšanas reizes būsiet savā sistēmā.
• kļūdu tolerance. Replikas kļūmes gadījumā visus lasīšanas pieprasījumus var droši pārsūtīt uz galveno. Ja kapteinis neizdodas, rakstīšanas pieprasījumus var pārsūtīt uz repliku (pēc galvenā faila atjaunošanas tas var pārņemt replikas lomu).
• datu dublēšana. Lai veiktu mysqldump, repliku var kādu laiku “palēnināt”, bet galvenais nevar.
• atliktie aprēķini. Smagus un lēnus SQL vaicājumus var izpildīt atsevišķā replikā, nebaidoties traucēt visas sistēmas normālu darbību.

Turklāt ir dažas citas interesantas funkcijas. Tā kā uz replikām tiek pārsūtīti nevis paši dati, bet gan vaicājumi, kas izraisa to izmaiņas, mēs varam izmantot dažādas tabulu struktūras galvenajā un replikās. Jo īpaši var atšķirties tabulas (dzinēja) vai indeksu kopas veids. Piemēram, lai veiktu pilna teksta meklēšanu, mēs varam izmantot MyISAM tabulas tipu replikā, neskatoties uz to, ka galvenais izmantos InnoDB.

Replikācijas iestatīšana

Pieņemsim, ka mums ir strādājoša datu bāze MySQL dati, jau aizpildīts ar datiem un iekļauts darbā. Un viena no iepriekš aprakstītajiem iemesliem mēs iespējosim sava servera replikāciju. Mūsu sākotnējie dati:

• Galvenā IP adrese ir 192.168.1.101, kopijas ir 192.168.1.102.
• MySQL instalēts un konfigurēts
• jums ir jākonfigurē testdb datu bāzes replikācija
• mēs varam uz brīdi apturēt vedņa darbību
• mums, protams, ir root abās mašīnās

Vedņa iestatījumi

Noteikti norādiet unikālo servera ID, bināro žurnālu ceļu un replikācijas datu bāzes nosaukumu sadaļā:
servera ID = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb
Pārliecinieties, vai diskā ir pietiekami daudz vietas binārajiem žurnāliem.

Pievienosim replikācijas lietotāju, ar kura tiesībām tiks veikta replikācija. Pietiks ar "replikācijas vergu" privilēģiju:
mysql@master> GRANT replikācijas vergu ON "testdb".* UZ "replication"@"192.168.1.102" Identificē "parole";

Restartējiet MySQL, lai konfigurācijas izmaiņas stātos spēkā:
root@master# pakalpojums mysqld restart

Ja viss noritēja labi, komandai "show master status" vajadzētu parādīt kaut ko līdzīgu:
mysql@master>PARĀDĪT PAMATA STATUSU\G
Fails: mysql-bin.000003
Pozīcija: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Pozīcijas vērtībai ir jāpalielinās, tiklīdz tiek veiktas izmaiņas galvenajā datu bāzē.

Replikas iestatījumi

Konfigurācijas sadaļā norādīsim servera ID, datu bāzes nosaukumu replikācijai un ceļu uz releja binlogs, pēc tam restartējiet MySQL:
servera 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 restart

Datu pārsūtīšana

Šeit mums būs jābloķē datubāze rakstīšanai. Lai to izdarītu, varat apturēt lietojumprogrammas vai izmantot tikai lasāmo karodziņu uz galvenā datora (uzmanību: šis karogs neietekmē lietotājus ar SUPER privilēģiju). Ja mums ir MyISAM tabulas, tad arī "izskalosim tabulas":
mysql@master> FLUSH TABLES AR READ LOCK;
mysql@master> SET GLOBAL read_only = ON;

Apskatīsim kapteiņa statusu ar komandu “show master status” un atcerēsimies faila un pozīcijas vērtības (pēc veiksmīgas galvenā bloķēšanas tām nevajadzētu mainīties):
Fails: mysql-bin.000003
Pozīcija: 98

Mēs izlādējam datu bāzi un pēc operācijas pabeigšanas noņemam galveno bloķēšanu:
mysql@master> SET GLOBAL read_only = OFF;

Mēs pārsūtām izgāztuvi uz repliku un atjaunojam datus no tā.
Visbeidzot, mēs sākam replikāciju ar komandām "mainīt galveno uz" un "startēt slave" un pārbaudīt, vai viss noritēja labi:
mysql@replica> MAINĪT MASTER UZ MASTER_HOST = "192.168.1.101", MASTER_USER = "replikācija", MASTER_PASSWORD = "parole", MASTER_LOG_FILE = "mysql-bin.000003", MASTER_LOG_POS.
mysql@replica> sākt vergu;
Mēs ņemam MASTER_LOG_FILE un MASTER_LOG_POS vērtības no galvenā.

Apskatīsim, kā notiek replikācija ar komandu "show slave status":
mysql@replica> RĀDĪT VERGU STATUSU\G
Slave_IO_State: gaida, līdz galvenais nosūtīs notikumu
Master_Host: 192.168.1.101
Master_User: replikācija
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: Jā
Slave_SQL_Running: Jā
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
Līdz_nosacījums: nav
Until_Log_File:
Līdz_Log_Pos: 0
Master_SSL_Allowed: Nē
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 5

Tagad esmu izcēlis interesantākās vērtības. Ja replikācija sākas veiksmīgi, to vērtībām ir jābūt aptuveni tādām pašām kā sarakstā (skatiet komandas "rādīt vergu statusu" aprakstu dokumentācijā). Seconds_Behind_Master vērtība var būt jebkurš vesels skaitlis.
Ja replikācija ir normāla, replika sekos galvenajam (žurnāla numurs Master_Log_File un Exec_Master_Log_Pos pozīcija palielināsies). Ideālā gadījumā replikas aizkaves laikam no galvenā (Seconds_Behind_Master) vajadzētu būt vienādam ar nulli. Ja tas nesamazinās vai nepalielinās, iespējams, ka kopijas slodze ir pārāk liela - tai vienkārši nav laika atkārtot galvenās izmaiņas.
Ja Slave_IO_State ir tukšs un Seconds_Behind_Master ir NULL, replikācija nav sākta. Skatiet MySQL žurnālu, lai noskaidrotu iemeslu, novērstu to un restartētu replikāciju:
mysql@replica> sākt vergu;

Veicot šīs vienkāršās darbības, mēs iegūstam kopiju, kuras dati ir identiski datiem par galveno.
Starp citu, laiks, kad galvenais ir bloķēts, ir laiks, kad tiek izveidota izgāztuve. Ja izveide prasa nepieņemami ilgu laiku, varat izmēģināt šo:

• bloķēt rakstīšanu kapteinim ar tikai lasāmu karogu, atcerieties pozīciju un apturiet MySQL.
• pēc tam kopējiet datu bāzes failus replikā un iespējojiet galveno.
• sāciet replikāciju parastajā veidā.

Ir vairāki veidi, kā izveidot kopiju, neapturot meistaru vispār, taču tie ne vienmēr darbojas.

Tiek pievienotas kopijas

Pieņemsim, ka mums jau ir strādājošs meistars un kopija, un mums tiem jāpievieno vēl viens. To izdarīt ir pat vienkāršāk, nekā pievienot galveno kopiju. Un vēl patīkamāk ir tas, ka par to nav nepieciešams apturēt meistaru.
Vispirms konfigurēsim MySQL otrajā replikā un pārliecināsimies, ka konfigurācijā esam ievadījuši nepieciešamos parametrus:
servera ID = 3
replicate-do-db = testdb

Tagad pārtrauksim replikāciju pirmajā reprodukcijā:
mysql@replica-1> apturēt vergu;

Replika turpinās darboties kā parasti, taču tajā esošie dati vairs nebūs aktuāli. Apskatīsim statusu un atcerēsimies galveno pozīciju, kuru replika sasniedza pirms replikācijas pārtraukšanas:
mysql@replica-1> RĀDĪT VERGU STATUSU\G

Mums vajadzīgās vērtības būs Master_Log_File un Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155

Izveidosim datu bāzes izdruku un turpināsim replikāciju pirmajā replikā:
mysql@replica-1> START SLAVE;

Atjaunosim datus no izgāztuves otrajā reprodukcijā. Pēc tam iespējojiet replikāciju:
mysql@replica-2> MAINĪT MASTER UZ MASTER_HOST = "192.168.1.101", MASTER_USER = "replikācija", MASTER_PASSWORD = "parole", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_5P OSTER_15_5
mysql@replica-2> START SLAVE;

Vērtības MASTER_LOG_FILE un MASTER_LOG_POS ir attiecīgi Master_Log_File un Exec_Master_Log_Pos vērtības no komandas “show slave status” rezultāta pirmajā replikā.
Replikācija jāsāk no vietas, kur tika apturēta pirmā replika (un attiecīgi tiek izveidota izgāztuve). Tādējādi mums būs divas kopijas ar identiskiem datiem.

Reprodukciju sapludināšana

Dažreiz rodas šāda situācija: galvenajā datorā ir divas datu bāzes, no kurām viena ir replicēta vienā, bet otrā citā. Kā iestatīt divu datu bāzu replikāciju abās replikās, neizlaižot tās galvenajā vai neizslēdzot to? Vienkārši, izmantojot komandu "sākt vergu līdz".
Tātad, mums ir galvenais ar datu bāzēm testdb1 un testdb2, kuras tiek replicētas attiecīgi replica-1 un replica-2. Konfigurēsim abu datu bāzu replikāciju uz replica-1, neapturot galveno.
Apturiet replikāciju replica-2 ar komandu un atcerieties galvenā atrašanās vietu:
mysql@replica-2> STOP SLAVE;
mysql@replica-2> RĀDĪT VERGU STATUSU\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231

Izveidosim testdb2 datu bāzes izgāztuvi un atsāksim replikāciju (tas pabeidz manipulācijas ar replica-2). Mēs atjaunosim izgāztuves reprodukciju-1.

Situācija replica-1 ir šāda: testdb1 datu bāze atrodas vienā galvenajā pozīcijā un turpina replicēt, testdb2 datu bāze ir atjaunota no izgāztuves no citas pozīcijas. Sinhronizēsim tos.

Pārtrauksim replikāciju un atcerēsimies kapteiņa pozīciju:
mysql@replica-1> STOP SLAVE;
mysql@replica-1> RĀDĪT VERGU STATUSU\G
Exec_Master_Log_Pos: 501

Pārliecināsimies, ka replica-1 konfigurācijā ir norādīts otrās datu bāzes nosaukums sadaļā:
replicate-do-db = testdb2

Restartēsim MySQL, lai konfigurācijas izmaiņas stātos spēkā. Starp citu, bija iespējams vienkārši restartēt MySQL, nepārtraucot replikāciju – no žurnāla mēs zinātu, kurā pozīcijā galvenā replikācija apstājās.

Tagad replicēsim no pozīcijas, kurā replica-2 tika apturēta, uz pozīciju, kurā mēs tikko apturējām replikāciju:
mysql@replica-1> MAINĪT MASTER UZ MASTER_HOST = "192.168.1.101", MASTER_USER = "replikācija", MASTER_PASSWORD = "parole", MASTER_LOG_FILE = "mysql-bin.000015", MASTER_LOG_1POSTER_231;
mysql@replica-1> sākt vergu līdz MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;

Replikācija beigsies, tiklīdz replika sasniegs norādīto pozīciju sadaļā līdz, un pēc tam abas mūsu datu bāzes atbildīs vienai un tai pašai galvenajai pozīcijai (kurā mēs pārtraucām replikāciju 1. reprodukcijā). Pārliecināsimies par to:
mysql@replica-1> RĀDĪT VERGU STATUSU\G
mysql@replica-1> START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Pievienosim abu datu bāzu nosaukumus konfigurācijai replica-1 sadaļā:
replicate-do-db = testdb1
replicate-do-db = testdb2

Svarīgi: katrai datubāzei jābūt norādītai atsevišķā rindā.
Restartējiet MySQL un turpiniet replikāciju:
mysql@replica-1> MAINĪT MASTER UZ MASTER_HOST = "192.168.1.101", MASTER_USER = "replikācija", MASTER_PASSWORD = "parole", MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_1;
Kad replika-1 panāks galveno, viņu datu bāzes saturs būs identisks. Varat sapludināt datu bāzi ar replica-2 vai nu līdzīgā veidā, vai arī veicot pilnīgu replica-1 dump.

Castling meistars un replika

Var būt nepieciešams pārslēgt repliku uz galveno režīmu, piemēram, galvenā kļūmes gadījumā vai veicot tehniskais darbs. Lai šādu pārslēgšanu padarītu iespējamu, jums ir jākonfigurē replika kā galvenais vai jāizveido tā pasīvais meistars.

Iespējosim bināro reģistrēšanu (papildus releju binlogiem) konfigurācijā sadaļā:
log-bin = /var/lib/mysql/mysql-bin

Un pievienojiet lietotāju replikācijai:
mysql@master> PIEŠĶIRT replikācijas vergu ON 'testdb'.* UZ 'replication'@'192.168.1.101′ Identificē "parole";

Pasīvais meistars veic replikāciju kā parastu repliku, bet papildus izveido binārās loģikas - tas ir, mēs varam sākt replikāciju no tā. Pārbaudīsim to ar komandu "show master status":
mysql@replica> RĀDĪT MASTER STATUS\G
Fails: mysql-bin.000001
Pozīcija: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Tagad, lai pārslēgtu pasīvo galveno ierīci uz aktīvo režīmu, jums jāpārtrauc tā replikācija un jāiespējo replikācija iepriekšējā aktīvajā galvenajā režīmā. Lai nodrošinātu, ka pārslēgšanas laikā dati netiek zaudēti, aktīvs meistars jābūt rakstīšanas bloķētam.
mysql@master> IZskalo TABULAS AR LASĪŠANAS BLOĶĒJUMU
mysql@master> SET GLOBAL read_only = ON;
mysql@replica> STOP SLAVE;
mysql@replica> RĀDĪT MASTER STATUS;
Fails: mysql-bin.000001
Pozīcija: 61
mysql@master> MAINĪT MASTER UZ MASTER_HOST = "192.168.1.102", MASTER_USER = "replikācija", MASTER_PASSWORD = "parole", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 61;
mysql@master> sākt vergu;
Tas arī viss, tāpēc nomainījām aktīvo meistaru. Jūs varat noņemt bloku no bijušā meistara.

Secinājums

Mēs esam iemācījušies mazliet par to, kā iestatīt replikāciju MySQL un veikt dažas pamata darbības. Diemžēl tālāk minētie svarīgi jautājumi paliek ārpus šī raksta darbības jomas.

• atsevišķu atteices punktu (SPF, Single Points of Failure) likvidēšana. Lietojot vienīgo MySQL serveris, tā kļūme izraisīja visas sistēmas atteici. Izmantojot vairākus serverus, jebkura no tiem atteices rezultātā radīsies sistēmas kļūme, ja vien mēs par to īpaši neparūpēsimies. Mums ir jāparedz situācijas risināšana ar kapteiņa un kopijas kļūmi. Viens no esošajiem rīkiem ir MMM, taču tam nepieciešama modifikācija ar failu.
• slodzes balansēšana. Izmantojot vairākas kopijas, mēs vēlamies izmantot caurspīdīgu līdzsvarošanas mehānismu, īpaši, ja kopiju veiktspēja ir nevienmērīga. Zem Linux ir iespējams izmantot standarta risinājumu - LVS.
• mainot lietojumprogrammas loģiku. Ideālā situācijā datu nolasīšanas pieprasījumi jānosūta uz replikām, bet datu maiņas pieprasījumi jānosūta kapteinim. Tomēr iespējamās repliku aizkavēšanās dēļ šāda shēma bieži ir neefektīva, un ir nepieciešams identificēt tādus lasīšanas pieprasījumus, kas joprojām ir jāizpilda galvenajā ierīcē.

Es ceru, ka šie jautājumi tiks aplūkoti turpmākajos rakstos.
Paldies par jūsu uzmanību!

Tagi:

• mysql
• replikācija

Pievienojiet atzīmes

Pirms neilga laika man lūdza runāt par replikācija MySQL. Es nolēmu, ka šī tēma varētu būt noderīga daudziem, tāpēc šajā rakstā es par to runāšu kas ir replikācija MySQL, kad tā ir nepieciešama un kā to konfigurēt.

Galvenais replikācijas uzdevums ir apvienot vairāku serveru jaudu. Pieņemsim, ka jūsu vietnei ir īpašs serveris, taču laika gaitā tā kļūst ļoti apmeklēta un vairs nevar izturēt slodzi. Tā rezultātā serveris sāk palēnināties un regulāri avarē. Vienkāršākais veids ir iegādāties jaudīgāku serveri, un to dara lielākā daļa cilvēku. Bet agri vai vēlu pienāk brīdis, kad servera cenas paaugstināšanas izmaksas neatbilst tā veiktspējas pieaugumam, tāpēc ir izdevīgāk pirkt 2 dažādi serveri par mazāku naudu.

Rezultātā jūsu datu bāze vienlaikus būs divos serveros. Kad viens galvenais serveris (pazīstams arī kā galvenais serveris) vairs netiek galā, tas pārslēdzas uz rezerves serveri.

Visi datu bāzes atjaunināšanas pieprasījumi vienmēr tiek nosūtīti uz galveno serveri. Pēc galvenā servera atjaunināšanas tas ievieto informāciju par to atsevišķu failu, no kurienes vergu serveri iegūst visu informāciju. Bet izlases operācijas, kuras parasti ir lielākā daļa un tās ir vislēnākās, jau var pārsūtīt uz vergu serveriem, jo ​​abos dati ir vienādi.

Tagad izdomāsim kā konfigurēt replikāciju MySQL:

1. Instalējiet visvairāk jaunākās MySQL versijas uz visiem serveriem.
2. Izveidojiet lietotāju ar privilēģijām galvenajā serverī VERGU NOMAINĪŠANA. Adresei, no kuras var izveidot savienojumu, norādiet " Visi".
3. Apturēt visus serverus.
4. Iestatījumos MySQL(failā my.cnf) Nodaļā pievienojiet šādas rindas: log-bin
   server-id=1 Lūdzu, ņemiet vērā, ka servera ID jābūt atšķirīgam visos serveros. Faktiski tas atšķir vienu serveri no cita.
5. Vergu serveros pievienojiet iestatījumiem MySQLšādas rindas: master-host=master_host_name
   master-user=izveidotā_lietotāja pieteikšanās
   master-password=izveidotā_lietotāja parole
   master-port=port_for_connecting_to_the_master_server
   servera-id=šī_slavena_servera_id_id
6. Pārvietojiet visas pamatnes no galvenā servera līdz vergiem.
7. Skrien galvenais serveris, tad visi vergi.