Image
18.5.2016 0 Comments

Databázy III / 6.časť

Späť na úvod >> Späť na seriál

Tentoraz sa budeme venovať málo používanej , ale zato veľmi efektívnej činnosti MySQL servera - replikácii. Tak ako sme si spomenuli v predchádzajúcich dvoch častiach, replikácia tesne súvisí s bezpečnosťou  - ochranou a obnovou dát. MySQL sa dopracovala do štádiá, keď dokáže sama vykonávať tzv. one - way replikáciu.
Ale ešte predtým, ako budeme naše databáze replikovať, povieme si niečo o binárnom logovaní.
BINÁRNY UPDATE LOG. Spomínate si, ako sme robili (pevne verím, že od tej doby aj všetci stále robíme) inkrementačné zálohy? Spustili sme server s parametrom --log-update. Tým sa do logovacieho súboru zaznamenávali všetky zmeny  v našich dátach. Po „vyfľusnutí“ sme tieto súbory odkladali na horšie časy. MySQL server zavádza nový typ logovania zmien, a to v binárnej forme.
Binárny update log, ako by sme toto mohli nazývať, obsahuje všetky informácie ako v klasickom update logu, ale v podstatne výkonnejšej forme. Okrem iného obsahuje informácie o tom, ako dlho každý dopyt, upravujúci dáta v tabuľke, trval.  Binárny update log bol zavedený hlavne kvôli replikácii.
To, čo sme si povedali a naučili sme sa o činnosti a úlohe textového update logu, platí aj pre tento nový binárny typ. Aby sme stanovili serveru, že má zapisovať všetky zmeny dát do binárneho update logu, spustíme ho s parametrom --log-bin, teda

- v linuxe:                     safe_mysqld --log-bin [=meno_ súboru] &
- vo Windows9X:          mysqld --log-bin [=meno_ súboru]

Ak nezadáme žiadne meno_súboru, systém sám zvolí meno podľa mena servera a doplní ho príponou -bin, na ktorom daný MySQL beží. Ak sa teda môj počítač volá mior, systém vytvorí nový binárny logovací súbor s menom mior-bin.001. Ak zadáme meno súboru v relatívnej ceste, teda bez presného určenia, kde sa má daný súbor vytvoriť, tak sa tento súbor vytvorí v adresári, kde sú uložené dáta serveru MySQL.
Už sme povedali, že všetky pravidlá pre prácu s logovaním pomocou --log-update platia aj pre prácu s --log-bin. Takže všetky činnosti okolo rotovania súborov, vyprázdňovania keše a podobne uplatníme aj tu. Preto sa nimi už nebudeme zaoberať.
Okrem súboru mior-bin.00x, v ktorom sú zaznamenané vykonané zmeny a ostatné príslušné údaje, systém vytvorí ešte jeden, takzvaný indexový súbor, ktorý sa bude volať mior-bin.index. V tomto súbore sú uložené poznámky o vytvorení rotovacích logov. Tento súbor je veľmi dôležitý pri samotnej replikácii.
Zmena nastáva pri obnovovaní dát z uložených logovacích súborov.
Vtedy sme používali príkaz
mysql -u root -pheslo kniznica < mior.001

To sme mohli použiť preto, lebo súbor mior.001 bol v textovej forme.
Ak sa však pozrieme do súboru mior-bin.001, uvidíme, že to nie je čistý textový súbor a tak nemôžeme na obnovenie dát z tohto súboru použiť vyššie spomenutý príkaz.
Pre používanie binárnych súborov je MySQL k dispozícii program mysqlbinlog. Ak chceme obnoviť dáta z binárneho logu, použijeme príkaz:
mysqlbinlog log_súbor | mysql -h meno_servera

teda v našom prípade
mysqlbinlog mior-bin.001| mysql -h mior

Môžeme tiež použiť mysqlbinlog na čítanie binárnych logov priamo zo vzdialených MySQL súborov.
Ak spustíme príkaz
mysqlbinlog mior-bin.001

dozvieme sa z výpisu na obrazovke obsah súboru, aké zmeny a kedy nastali a ako bol tento súbor zrotovaný:

# at 4
#020928  9:30:53 server id  1      Start: binlog v 2, server v 4.0.1-alpha-max-debug-log created 020928  9:30:53
# at 79
#020928  9:42:31 server id  1      Query thread_id=2 exec_time=0      error_code=0
use test;
SET TIMESTAMP=1033198951;
DELETE FROM articles WHERE id=1;
# at 145
#020928 10:04:47 server id  1      Rotate to mior-bin.002pos=4
# at 184
#020928 10:04:47 server id  1      Stop

V prípade, že by sme sa chceli dozvedieť viac o možnostiach samotného príkazu mysqlbinlog, spustíme ho s parametrom --help.
REPLIKÁCIA V MYSQL. One - way (jednosmerná) replikácia v MySQL je pomerne dobre vypracovaná, robustná a rýchla. Na jej činnosť potrebujeme minimálne dva servery MySQL, teda dva počítače, kde jeden bude master (pán) a tie ostatné budú v roli slave (sluha), ktoré preberú úlohu mastera, keď na ňom nastanú problémy.
Od verzie 3.23.15, MySQL podporuje one - way replikáciu interne. Master server vytvára binárny update log súbor a indexový súbor. Slave na základe spojenia s masterom ho informuje, že dohonil zmeny, ktoré prebehli na mastrovi a čaká na ďalšie oznámenie zmien v databázach na mastrovi.
One - way replikácia znamená, že zmeny, ktoré prebehnú na masterovi, budú vykonané aj na slave-ovi. Naopak to však nie je možné. Skutočne sa jedná o replikáciu iba jedným smerom!
PRINCÍP ČINNOSTI. MySQL one - way replikácia je založená na tom, že master server zaznamenáva všetky zmeny v dátach svojich tabuliek a databáz do binárneho logu. Servery typu slave čítajú uložené zmeny z tohto binárneho logu a vykonajú tie isté zmeny na svojich dátach.
Z toho vyplýva, že pred spustením samotnej replikácie je veľmi dôležité mať presnú kópiu dát ako na masteri, tak aj na jednotlivých slavoch. Ak by sme nezabezpečili identické kópie, je pochopiteľné, že by sme na slavoch získavali neidentické údaje!
ROZDIELNOSŤ POUŽITÝCH VERZIÍ. Ak chceme používať one - way replikáciu, bolo by veľmi dobré, ak by sme mali na obidvoch systémoch, teda na master-ovi aj slave-ovi rovnakú verziu MySQL. Ak to však z určitých dôvodov nie je možné, platia tieto pravidlá:
Slave verzie 4.0.0 nevie komunikovať s mastrom verzie 3.23.
Slave verzie 4.0.1 a vyššie už dokáže komunikovať s mastrom verzie 3.23.
Slave verzie 3.23  nedokáže komunikovať s masterom verzie 4.0.

Aby sme mohli používať one - way replikáciu, všetky tabuľky musia byť typu MyISAM!
NASTAVENIE REPLIKÁCIE. Teraz si popíšeme postup, ako nastavíme master-a a slave-a na výkon one - way replikácie:

1. Presvedčíme sa, či máme vhodné verzie MySQL na obidvoch stranách. Odporúča sa použiť verzie od 3.23.29 a vyššie. Staršie verzie mali chyby v binárnych logoch a nefungovali korektne.
2. V systéme MySQL na masterovi vytvoríme nového používateľa, ktorý bude mať privilégiá FILE a možnosť pristupovať z požadovaných počítačov, ktoré budú zastávať úlohu slave. Najvhodnejšie je vytvoriť takého používateľa, ktorý bude vykonávať iba replikáciu, aby nemal povolené iné možnosti v MySQL. Pre ukážku vytvorme používateľa s menom repl, s heslom „karol“, ktorý môže pristupovať z rôznych počítačov typu slave. Príkaz na vytvorenie potom bude:

GRANT FILE ON *.* TO repl@”%” IDENTIFIED BY ‘karol’;

3. Vypnime server MySQL na strane master:
mysqladmin -u root -p shutdown

4. Vytvorme kópie všetkých tabuliek a databáz na strane master. Ak používame na masterovi a slaveovi tú istú verziu MySQL, môžeme jednoducho preniesť systémové súbory MySQL. Ak nie, použijeme na prenos spôsob popísaný pri archivovaní dát.

5. V súbore my.cnf na strane master pridáme do sekcie [mysqld] tieto dve položky:

[mysqld]
log-bin
server-id=1

Položka server-id=1 je veľmi dôležitá! Je to unikátne číslo, ktoré identifikuje “adresu” mastera, podobne ako IP adresa.

6. eštartujeme server na strane master.

7. Na strane slave pridáme do súboru my.cnf tieto položky:

master-host=<meno_mastera>
master-user=<meno_replikačného_používateľa>
master-password=<heslo_replikačného_používateľa>
master-port=<TCP/IP port mastera>
server-id=<unikátne číslo medzi 2 až 2^32 - 1>

Za uvedené hodnoty dosadíme požadované údaje, teda za meno_mastera dáme mior, za meno_replikačného_používateľa dosadíme repl, za heslo_ replikačného_používateľa dosadíme karol.
TCP/IP port mastera býva 3306, ak sme ho nezmenili.
server-id na strane slave musí byť odlišné od server-id na strane master!
Ak zabudneme nastaviť server-id na strane slave, dostaneme takúto chybovú hlášku v súbore error.log:

Warning: one should set server_id to a non-0 value if master_host is set.
The server will not act as a slave.

Ak toto zabudneme urobiť na strane master, počítače typu slave sa nebudú schopné pripojiť na mastra.
Len čo sa bude slave replikovať, nájdeme súbor s názvom master.info v tom istom adresári, ako error.log. Nemažme ani needitujme tento súbor!

8. Na strane slave vytvoríme identickú kópiu celého databázového stroja. Môžeme využiť prenesené súbory zo strany mastera.
9. Reštartujeme slave.

Po tom, čo to vykonáme, slave sa pokúsi spojiť s masterom a zachytiť všetky zmeny, ktoré od tej doby nastanú.
ĎALŠIE PARAMETRE SÚBORU MY.CNF. Vykonávanie samotnej replikácie môžeme ovplyvniť nastavením konkrétnych parametrov. Tie sa spravidla zapisujú do súboru my.cnf.
To by sme mali k replikácii všetko.
Naša vysoká škola databáz sa blíži k záveru. Ostáva nám prebrať už len niekoľko posledných kapitol. Povieme si niečo o vstavaných funkciách a pozrieme sa súhrne na najdôležitejšie funkcie systému MySQL.

Ale to už nabudúce.


Nechajte si posielať prehľad najdôležitejších správ emailom

Mohlo by Vás zaujímať

Ako na to

Ako zbaviť fotky hmly

08.12.2016 11:59

Hmla alebo dym sú často veľmi kreatívne nástroje. No všetkého veľa škodí. Fotka potom stráca kontrast a v podstate na nej nič nevidieť. Hmlu môžete neraz následnými úpravami odstrániť alebo zredukovať ...

Ako na to

Užitočné SW nástroje

08.12.2016 11:53

AllDup v4.0.3 Určenie: program na vyhľadávanie a odstraňovanie duplicitných súborov Vlastnosti: duplicitné súbory sa vyhľadávajú len na zvolených diskových jednotkách alebo len v rámci vybraných ...

Ako na to

Fotografovanie s bleskom

08.12.2016 11:47

Ak máte moderný fotoaparát so vstavaným alebo externým bleskom, zdá sa vám téma článku triviálna. Jednoducho nastavíte vhodný režim, vyberiete najlepšiu kompozíciu záberu, exponujete a o zvyšok sa už ...

Žiadne komentáre

Vyhľadávanie

Kyocera - prve-zariadenia-formatu-a4-s-vykonom-a3

Najnovšie videá