REPLIKACIJA BAZE PODATKOV V MYSQL · 2018-08-24 · The thesis deals with replication of a database in the MySQL database management system. Theoretical part presents the types of

Diplomsko delo univerzitetnega študija Organizacija in management informacijskih sistemov

REPLIKACIJA BAZE PODATKOV V MYSQL

Mentor: red. prof. dr. Robert Leskovar Kandidat: Tim Trojar Vidmar

Kranj, avgust, 2017

ZAHVALA Zahvaljujem se mentorju Robertu Leskovarju za pomoč pri izdelavi moje diplomske naloge.

POVZETEK V nalogi je obravnavana replikacija baze podatkov v sistemu za upravljanje z bazo podatkov MySQL. V teoretičnem delu so predstavljene vrste replikacij, principi delovanja, prednosti in pomanjkljivosti replikacij ter tipični problemi, ki jih rešuje replikacija. Eksperimentalni del naloge obsega opis konfiguracije več vrst replikacije. Replikacije smo izvedli z različnimi vmesniki (mysql, phpmyadmin in skripti v Pythonu). Preskusili smo tri vrste replikacije: glavni strežnik in en pomožni strežnik (master/slave replikacija), dva glavna strežnika (master/master replikacija) ter en glavni in trije pomožni strežniki, pri čemer v primeru izpada glavnega strežnika njegovo vlogo prevzame eden od pomožnih. Opisan je tudi mehanizem samodejnega spreminjanja vlog strežnikov (failover). Vsi preskusi so bili izvedeni v laboratorijskem okolju.

KLJUČNE BESEDE:

• Replikacija • MySQL • Podatkovna baza • Virtualni računalnik • Strežnik

ABSTRACT The thesis deals with replication of a database in the MySQL database management system. Theoretical part presents the types of replication, principles of operation, advantages and disadvantages of replication and typical problems solved by replication. The experimental part of the thesis describes how different types of replication can be configured. We created replication in two ways: object mode and phyton scripts. Three different types of replication are described: master-slave replication, master-master replication and one master and three slave servers replication. In case of master server failure, role of the master is assumed by one of the backups. A mechanism for automatically changing server roles (failover) is also described. All tests were carried out in a laboratory environment.

KEYWORDS:

• Replication • MySQL • Database • Virtual computer • Server

KAZALO 1 Uvod ....................................................................................... 1

2 Metodologija dela ....................................................................... 1

2.1 Definicija problema................................................................ 1

2.2 Opredelitev ciljev naloge ......................................................... 2

2.3 Predlagane metode in orodja .................................................... 2

3 Predstavitev mehanizma replikacije MySQL 5.6 .................................... 3

3.1 Replikacija baze podatkov ........................................................ 3

3.2 Sinhrona in asinhrona replikacija ................................................ 3

3.3 Konfiguracija replikacije v MySQL 5.6 .......................................... 3

3.3.1 Vzpostavitev replikacije v MySQL .......................................... 4

3.3.2 Različni formati replikacije ................................................. 5

3.4 Značilnosti replikacije v MySQL 5.6 ............................................. 5

3.5 Implementacija replikacije v MySQL 5.6 ....................................... 6

3.6 Uporabnost replikacije ............................................................ 6

3.6.1 Uporaba replikacije za varnostno kopijo .................................. 6

3.6.2 Uporaba replikacije z različnimi formati zapisov na glavnem in pomožnem strežniku MySQL 5.6 ....................................................... 6

3.6.3 Uporaba replikacije za »scale-out« ........................................ 7

3.6.4 Izboljševanje zmogljivosti replikacije ..................................... 7

4 Predstavitev strojne in programske opreme......................................... 9

4.1 Fizični računalnik .................................................................. 9

4.1.1 Strojna oprema ............................................................... 9

4.1.2 Programska oprema .......................................................... 9

4.2 Swqlab – virtualni stroj ........................................................... 10

4.2.1 Strojna oprema virtualnega računalnika ................................. 10

4.2.2 Programska oprema virtualnega računalnika ............................ 10

5 Baza podatkov spletne učilnice SWQLAB ............................................ 11

6 Načrt replikacije in testiranje ........................................................ 13

6.1 Začetne nastavitve in programi ................................................. 13

6.2 Vnos testnih podatkov in začetek replikacije ................................. 15

6.2.1 Replikacija dveh glavnih strežnikov ...................................... 15

6.3 Nastavitve replikacije master-master .......................................... 15

6.3.1 Konfiguracija glavnega strežnika 1 ........................................ 15

6.3.2 Konfiguracija glavnega strežnika 2 ........................................ 17

6.3.3 Zagon replikacije dveh glavnih strežnikov ............................... 18

6.4 Delovanje replikacije dveh glavnih strežnikov ............................... 19

6.5 Nastavitev replikacije z glavnim in pomožnim strežnikom ................. 19

6.5.1 Konfiguracija glavnega strežnika .......................................... 19

6.5.2 Konfiguracija pomožnega strežnika ....................................... 20

6.5.3 Zagon replikacije z glavnim in pomožnim strežnikom ................. 21

6.5.4 Delovanje replikacije z glavnim in pomožnim strežnikom ............. 21

6.5.5 Težave pri vzpostavitvi replikacije ....................................... 22

6.6 Uporaba mehanizma »failover« ................................................. 23

6.6.1 Osnovne nastavitve za mehanizem »failover« ........................... 23

7 Priprava virtualnega stroja ........................................................... 28

7.1 Arhitektura sistema virtualnih računalnikov .................................. 31

7.2 Migracija z MySQL workbenchom ............................................... 31

8 Različni eksperimenti z mehanizmom replikacije ................................. 36

8.1 Eksperiment 1: Replikacija z glavnim in pomožnim strežnikom ........... 36

8.2 Eksperiment 2: Replikacija z dvema glavnima strežnikoma ................ 38

8.3 Eksperiment 3: En glavni in trije pomožni strežniki ......................... 40

8.3.1 Vzpostavitev mehanizma failover ......................................... 43

9 Zaključki ................................................................................. 45

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo univerzitetnega študija

Tim Trojar Vidmar: Replikacija baze podatkov v MySQL stran 1

1 UVOD

V diplomskem delu bo obravnavan problem replikacije baze podatkov. Najpomembnejša elementa replikacije sta dva strežnika, ki ju v angleški terminologiji imenujemo »master« in »slave«. V nadaljevanju diplomske naloge bomo »master« imenovali glavni strežnik, »slave« pa pomožni ali sekundarni strežnik. Mehanizem replikacije nam omogoča, da podatke z enega MySQL strežnika, tega imenujemo glavni strežnik, repliciramo na drugi MySQL strežnik, ki ga imenujemo pomožni strežnik. Replikacija je po privzetih nastavitvah asinhrona, kar pomeni, da pomožni strežnik ne potrebuje konstantne povezave z glavnim strežnikom. Posodobitve se lahko zgodijo tudi ob začasnih ali prekinjenih povezavah. V uporabi največkrat zasledimo dve vrsti replikacijskih konfiguracij: replikacijo dveh glavnih strežnikov (»master-master« replication) in replikacijo glavni-pomožni strežnik (»master-slave« replication). Možno je tudi, da imamo več glavnih in/ali več pomožnih strežnikov. V tem diplomskem delu bo natančneje obravnavan princip replikacije z enim glavnim in enim pomožnim strežnikom, krajše pa bodo predstavljeni tudi ostali principi delovanja mehanizma replikacije. Replikacijski mehanizem lahko konfiguriramo na več različnih načinov, odvisno od posamezne situacije. Repliciramo lahko vse baze podatkov (sheme) ali le izbrane. Če želimo, lahko repliciramo tudi določene tabele v posamezni shemi. Z uvajanjem mehanizma replikacije izboljšamo uravnoteženo obremenjenost strežnikov, varnost podatkov, analitiko in razpršitev podatkovnih virov. Dobra lastnost replikacije je, da teče v ozadju in je popolnoma nevidna interaktivnim uporabnikom baze podatkov. Sama po sebi replikacija pomeni nekoliko večjo obremenitev strežnika, zato jo administratorji baz podatkov konfigurirajo tako, da interaktivne uporabnike čim manj moti. Podatki so na pomožnem strežniku skoraj takoj, ko se je sprememba naredila na glavnem strežniku. Kar se dogaja v ozadju, pozna le administrator. Njegova naloga je, da poskrbi za neprekinjeno in hitro delovanje ter seveda za varnost shranjenih podatkov.

2 METODOLOGIJA DELA

2.1 DEFINICIJA PROBLEMA

V diplomskem delu bomo obravnavali problem replikacije produkcijskega strežnika, na katerem deluje izobraževalni portal Moodle. Replikacija končnemu uporabniku zagotavlja neprekinjeno in hitro delovanje, vendar s samim mehanizmom nima nobene interakcije. Administratorjem baz podatkov pa vzpostavitev in uglasitev (tuning) replikacije predstavlja velik izziv. V primeru, da mehanizem replikacije ni vzpostavljen, lahko odpoved strežnika administratorjem povzroči velike težave. Takrat sistem ne deluje več in uporabniki ne morejo dostopati do podatkov. Lahko celo izgubijo pomembne podatke o poslovanju. V poslovnih sistemih, ki morajo delovati neprekinjeno, lahko nastane velika gospodarska škoda in izguba ugleda. V nalogi se bomo sicer osredotočili na laboratorijski strežnik Swqlab na Fakulteti za organizacijske vede, kjer izpad ne povzroči izgube prihodka, vpliva pa na ugled inštitucije.



2.2 OPREDELITEV CILJEV NALOGE

Cilji diplomske naloge so: • preštudirati literaturo o replikaciji, • preizkusiti vse vrste replikacije v testnem okolju: dva glavna strežnika,

glavni in pomožni strežnik, en glavni in več pomožnih strežnikov, • preskus vzpostavitve replikacije v objektnem načinu in s pythonskimi skripti, • preskus vzpostavitve mehanizma failover.

2.3 PREDLAGANE METODE IN ORODJA

V diplomski nalogi bodo uporabljene metode in tehnike programskega inženiringa, kot so konfiguriranje podatkovnih strežnikov, virtualizacija strežnikov in testiranje programske opreme. Uporabljena bodo naslednja orodja:

• Wampserver 3.0.4 • PhpMyAdmin 4.5.5.1 • Oracle Virtualbox 5.1.4 • MySQL 5.6 in 5.7.11 • Bitnami-moodle 3.1.1.



3 PREDSTAVITEV MEHANIZMA REPLIKACIJE MYSQL 5.6

3.1 REPLIKACIJA BAZE PODATKOV

Replikacija baze podatkov je ustvarjanje kopije baze podatkov na drugi lokaciji. To pomeni, da je baza podatkov dosegljiva na strežniku, ki je lahko geografsko na isti ali drugi lokaciji kot primarni strežnik. Pri replikaciji podatkovne baze kreiramo kopijo obstoječe baze s sinhroniziranimi podatki na obeh strežnikih. Sinhronizacija lahko poteka v realnem času ali pa z določenim časovnim zamikom. Intervali sinhronizacije so običajno podani v sekundah ali minutah. Časovni zamik je odvisen od količine spremenjenih podatkov in od konteksta uporabe. Glavni cilj replikacije je , da imamo podatkovno bazo dosegljivo na dveh različnih mestih. Replikacija omogoča, da se podatki iz ene baze podatkov (glavni strežnik), prepišejo na enega ali več pomožnih strežnikov. Replikacija je asinhrona, zato pomožni strežniki ne zahtevajo neprekinjene povezave z glavnim strežnikom. Posodobitve se lahko izvajajo med geografsko zelo oddaljenimi strežniki, z začasnimi prekinitvami in celo preko telefonskih linij. S konfiguracijo mehanizma replikacije lahko repliciramo vse baze podatkov (sheme), izbrane baze ali celo samo izbrano tabelo. V besedilu bosta pogosto uporabljena termina »glavni strežnik« in »pomožni strežnik«.

• Glavni strežnik vsebuje bazo podatkov, ki služi kot primarni vir podatkov za ostale baze. Strežnik sporoča spremembe drugim bazam podatkov.

• Pomožni strežnik uvozi spremembe podatkov z druge baze podatkov.

3.2 SINHRONA IN ASINHRONA REPLIKACIJA

Sistem za upravljanje z bazo podatkov MySQL podpira asinhrono replikacijo, kjer je eden izmed strežnikov določen kot glavni strežnik in eden ali več strežnikov določenih kot pomožni strežniki. V MySQL 5.6 je vgrajen vmesnik za semisinhrono replikacijo poleg vmesnika za asinhrono replikacijo. S semisinhrono replikacijo je storitev izvedena na glavnem strežniku, preden se izvede transakcija oziroma je vsaj eden izmed pomožnih strežnikov prejel dogodke za transakcijo.

3.3 KONFIGURACIJA REPLIKACIJE V MYSQL 5.6

Replikacija med strežniki MySQL temelji na mehanizmu binarnega dnevnika. Glavni strežnik MySQL (vir, kjer se dogajajo spremembe) zapisuje spremembe v tabele in v binarni dnevnik (binary log). Naloga pomožnih strežnikov je, da berejo zapise v binarnem dnevniku na glavnem strežniku ter izvedejo ustrezne spremembe v svojih tabelah. Ko je binarno beleženje omogočeno, se vsi ukazi zapisujejo v binarni dnevnik in vsak izmed pomožnih strežnikov kopira celotno vsebino binarnega dnevnika. Če ne želimo, da pomožni strežnik kopira vse ukaze v binarnem dnevniku, moramo to konfigurirati na pomožnem strežniku. Glavnega strežnika ne moremo konfigurirati tako, da bi v binarni log zapisoval le določene spremembe, ki jih je naredil na primarni bazi podatkov. Vsak pomožni strežnik ima podatke o lokaciji binarnih dnevnikov:



• ime datoteke binarnega dnevnika, • pozicijo znotraj binarnega dnevnika, ki določa točko sinhronizacije na

glavnem strežniku, kar pomeni, da je lahko z glavnim strežnikom povezanih več pomožnih strežnikov in izvajajo različne dele v binarnem dnevniku.

3.3.1 VZPOSTAVITEV REPLIKACIJE V MYSQL

• Konfiguracija glavnega strežnika Za vzpostavitev replikacije moramo najprej konfigurirati glavni strežnik. Najprej omogočimo binarno beleženje. V konfiguracijski datoteki MYSQL my.cnf (na operacijskih sistemih Linux) oz. my.ini (na operacijskih sistemih MS Windows) dodamo ukaz log-bin z navedbo poti in imena datoteke, ki jo bo baza uporabljala kot binarni dnevnik. Glavnemu strežniku določimo tudi unikatno identifikacijsko številko binarnega dnevnika. Običajno uporabimo število 1. Spremenjene nastavitve nato shranimo ter ponovno zaženemo strežnik.

• Konfiguracija pomožnega strežnika Vsakemu pomožnemu strežniku določimo unikatno identifikacijsko številko. Po navadi je prvi pomožni strežnik številčen z 2. Spremenjene nastavitve shranimo ter ponovno zaženemo strežnik.

• Kreiranje uporabnika za replikacijo Vsak pomožni strežnik se povezuje z glavnim strežnikom kot poseben uporabnik, ki mora imeti specifične privilegije. Uporabnika ustvarimo na glavnem strežniku, pomožni strežnik pa s tem uporabnikom dostopa do binarnega dnevnika na glavnem strežniku. Baza podatkov MYSQL ta privilegij imenuje »REPLICATION SLAVE«.

• Sinhronizacija podatkov Preden začnemo z replikacijo, moramo imeti identične podatke na glavnem in pomožnem strežniku. To pomeni, da moramo podatke z glavnega strežnika prenesti na pomožni strežnik. Prenos opravimo tako, da kreiramo trenutni posnetek (snapshot) baze, ki je na glavnem strežniku. Za trenutni posnetek baze uporabimo funkcijo v mysqldump ter tako prekopiramo vse podatke z glavnega strežnika na pomožnega.

• Zagon replikacije Za zagon replikacije moramo na pomožnem strežniku vpisati podatke o glavnem strežniku. Podatke lahko vpišemo preko ustreznega vmesnika: v terminalu, v PhpMyAdmin, MySQL Workbench, NAVICAT ali npr. dbForge Studio. V terminalu se prijavimo v bazo z ukazom MySQL –uroot –p, nato pa vpišemo podatke o glavnem strežniku:



CHANGE MASTER TO MASTER_HOST='IP GLAVNEGA strežnika', MASTER_USER='Uporabniško ime, ki smo ga ustvarili za replikacijo', MASTER_PASSWORD='Geslo, ki smo ga nastavili', MASTER_LOG_FILE=' binlog.xxxxxxx', MASTER_LOG_POS=xxx; Podatke za master_log_file in master_log_pos dobimo tako, da na glavnem strežniku izvedemo ukaz

show master status;. Replikacijo zaženemo z ukazom

start slave.

3.3.2 RAZLIČNI FORMATI REPLIKACIJE

Mehanizem replikacije deluje zato, ker se vsi dogodki, ki se zgodijo na glavnem strežniku, zapišejo v binarni dnevnik, ki jih pomožni strežnik prebere in procesira. Dogodki so v binarnem dnevniku zapisani v različnih formatih, odvisno od tipa dogodka, ki se je zgodil.

3.4 ZNAČILNOSTI REPLIKACIJE V MYSQL 5.6

• Uravnoteženje obremenitve (load balancing) Z razporeditvijo bremena lahko dosežemo boljšo odzivnost glavnega strežnika. Pogosto glavni strežnik obremenimo le z operacijami dodajanja, spreminjanja in brisanja (INSERT, UPDATE, DELETE), pomožne strežnike pa obremenimo z branjem (SELECT) in procesiranjem (npr. izvajanjem analitike). Posledica take politike je najpogosteje zelo hitro zapisovanje (na glavnem strežniku) in zelo hitro branje (na pomožnih strežnikih).

• Varnost podatkov Ko se na pomožnem strežniku zapisuje varnostna kopija, se mehanizem replikacije ustavi. Na ta način se preprečijo poškodbe na varnostni kopiji.

• Analitika Izvajanje analitike poteka hitreje, kadar se na pomožnem strežniku izvaja samo opcija branja. Sekundarni strežnik je primerno okolje za izvajanje analitike, ker lahko replikacijo kontroliramo na tak način, da se na tem strežniku izvaja le opcija branja.

• Distribucija podatkov na oddaljene lokacije Če imamo podružnico, ki za delo potrebuje kopijo primarne podatkovne baze, lahko uporabimo replikacijo. Z replikacijo lahko ustvarimo kopijo podatkov v podružnici. Pri tem ni pogoj stalna povezava z glavnim strežnikom.



3.5 IMPLEMENTACIJA REPLIKACIJE V MYSQL 5.6

Mehanizem replikacije temelji na tem, da glavni strežnik zapisuje vse spremembe v tabelah. Poleg tega vsako spremembo zapiše tudi v binarni dnevnik. Binarni dnevnik je zaporedje vseh sprememb, zato običajno poizvedbe (SELECT) niso zapisane v binarni dnevnik. Lahko pa se vpisujejo za sledenje dostopov uporabnikov. Vsak pomožni strežnik, ki je povezan z glavnim strežnikom, zahteva kopijo binarnega dnevnika. Gre za princip »pull«. Glavni strežnik ne potiska spremembe na sekundarni strežnik, ampak mu dovoljuje branje sprememb. V primeru, da imamo arhitekturo z več pomožnimi strežniki, je lahko vsak od njih v različnih stopnjah sinhronizacije z glavnim strežnikom. Pomožni strežnik lahko ustavi in začne proces replikacije, ne da bi vplival na druge pomožne strežnike.

3.6 UPORABNOST REPLIKACIJE

Replikacijo lahko uporabljamo v različnih okoljih ter za različne namene.

3.6.1 UPORABA REPLIKACIJE ZA VARNOSTNO KOPIJO

Če želimo uporabiti replikacijo za varnostno kopijo, moramo replicirati podatke z glavnega strežnika na pomožni strežnik ter nato varnostno kopirati podatke s pomožnega podatkovnega strežnika. Sekundarni strežnik lahko ustavimo, ne da bi to vplivalo na delovanje glavnega strežnika in zato lahko naredimo posnetek trenutnih podatkov. Izbira postopka za izdelavo varnostne kopije je odvisna od velikosti baze in od zahteve za povrnitev podatkov s pomožnega strežnika na glavni strežnik. V praksi se uporabljata dva pristopa za izdelavo varnostne kopije.

• Pri manjših bazah podatkov uporabimo program mysqldump. Mysqldump ustvari kopijo vseh podatkov z baze v formatu, ki je primeren za uvoz v drugo bazo. Priporočen način je ustavitev strežnika in zagon programa mysqldump.

• Za večje baze in primer, ko ne smemo ustaviti strežnikov, uporabimo kopiranje datotek (npr. s programom rsync).

3.6.2 UPORABA REPLIKACIJE Z RAZLIČNIMI FORMATI ZAPISOV NA GLAVNEM IN POMOŽNEM STREŽNIKU MYSQL 5.6

MYSQL omogoča različne formate zapisov (storage engine). To je komponenta programske opreme, ki jo sistem za upravljanje baz podatkov (angleško database management system ali DBMS) uporablja za kreiranje, branje, posodabljanje in brisanje podatkov iz baze. Najpogostejša formata zapisov sta novejši InnoDB in starejši MyISAM. Za proces replikacije ni pomemben format zapisa na glavnem strežniku in pomožnem strežniku. To nam omogoča, da pri replikacijskem procesu lahko uporabimo prednosti različnih tipov zapisov v različnih scenarijih replikacije. V



tipičnem scenariju uporabimo format InnoDB na glavnem strežniku zaradi boljšega upravljanja transakcij, na pomožnih strežnikih pa zaradi hitrejšega branja uporabimo format MyISAM. Angleški termin »scale-out« se nanaša na potencialno možnost paralelnega branja in procesiranja podatkov na pomožnih strežnikih. Različne formate zapisov učinkovito kontroliramo na več načinov.

• Če uporabljamo funkcijo mysqldump, lahko v »dump« datoteki z besedilom spremenimo format zapisa, ki je bil uporabljen v datoteki. Drugi način pa je, da onemogočimo formate zapisa, ki jih nočemo uporabiti na pomožnem strežniku, preden uporabimo funkcijo mysqldump. Če v konfiguracijsko datoteko my.cnf dodamo opcijo --skip-federated«, bo to onemogočilo zapise v formatu »FEDERATED engine«. MySQL v tem primeru uporabi format zapisa MyISAM.

• Če uporabljamo kopijo neobdelanih podatkov (binary backup) za pripravo

pomožnega strežnika, ne bomo mogli spremeniti prvotnega formata zapisa v tabeli. Zato bomo morali uporabiti ukaz ALTER TABLE. V primeru, da želimo format zapisa spremeniti, ko sekundarni strežnik že deluje, moramo najprej ustaviti pomožni strežnik ter nato uporabiti ukaz ALTER TABLE.

3.6.3 UPORABA REPLIKACIJE ZA »SCALE-OUT«

V tem primeru gre za porazdelitev nalog med strežniki. Replikacija po navadi deluje tako, da imamo en glavni strežnik ter več pomožnih strežnikov. Princip »scale-out« je najboljši v primeru, kjer imamo malo novih zapisov v bazi ter veliko branja in procesiranja podatkov. V to kategorijo spada večina spletnih strani. Replikacija nam v tem primeru omogoča, da procesiranje porazdelimo med več pomožnih strežnikov.

3.6.4 IZBOLJŠEVANJE ZMOGLJIVOSTI REPLIKACIJE

Več kot je pomožnih strežnikov povezanih z glavnim strežnikom, večja je njegova obremenitev. Vsak pomožni strežnik mora od glavnega pridobiti binarni dnevnik, da lahko začne z replikacijo. V primeru velikega števila povezanih pomožnih strežnikov z enim glavnim strežnikom je hitrost replikacije lahko neprimerna. Delovanje lahko izboljšamo tako, da ustvarimo drugačno replikacijsko arhitekturo. Glavni strežnik 1 replicira podatke na glavni strežnik 2, preostali pomožni strežniki pa se povežejo z glavnim strežnikom 2. Arhitektura tega načina replikacije je prikazana na sliki 1.



Da ustvarimo tako strukturo, moramo narediti naslednje konfiguracijske spremembe.

• Glavni strežnik 1 je primarni strežnik, kjer se dogajajo vse posodobitve in spremembe, zapisane v podatkovno bazo. Na tem strežniku mora biti omogočeno binarno beleženje.

• »Glavni strežnik 2« je pomožni strežnik »glavnega strežnika 1« in zagotavlja funkcionalnost replikacije. »Glavni strežnik 2« je edini strežnik, ki mu je dovoljena povezava z »Glavnim strežnikom 1«. »Glavni strežnik 2« ima prav tako omogočeno binarno beleženje, omogočena pa je tudi opcija »--log-slave-updates«. Opcija je vključena zato, da se podatki z binarnega dnevnika strežnika »glavni 1« zapišejo tudi v binarni dnevnik strežnika »glavni 2«. V tem primeru se podatki lahko replicirajo na vse tri pomožne strežnike.

Ta rešitev zmanjša obremenjenost primarnega glavnega strežnika in tako se izboljša celotno delovanje mehanizma replikacije.

Glavni strežnik 1 Glavni strežnik 2

Pomožni strežnik 3



Slika 1: Arhitektura replikacije z dvema glavnima in tremi pomožnimi strežniki



4 PREDSTAVITEV STROJNE IN PROGRAMSKE OPREME

Kot konkreten primer možne replikacije smo obravnavali izobraževalni portal Swqlab (https://swqlab.fov.um.si).

4.1 FIZIČNI RAČUNALNIK

4.1.1 STROJNA OPREMA

Karakteristike računalnika, ki ga uporabljamo za delovanje spletnega portala Swqlab so:

• Matična plošča Supermicro X8DTG-QF Ta matična plošča je narejena le za strežnike. Podpira 2 procesorja istega tipa, nanj lahko priključimo do 192 GB DDR3 1333/1066/800 MHz RDIMM pomnilnika ali 48 GB UDIMM pomnilnika. Proizvajalec: Supermicro

• Procesor Na strežniku sta dve procesorski enoti Intel(R) Xeon(R) CPU W5590 @ 3.33 GHz. Skupaj imata 8 jeder in 16 niti.

• Pomnilnik 24 GB pomnilnika tvori 6 pomnilniških enot Hyundai HMT151R7BFR4C-H9. Vsaka ima 4 GB pomnilnika.

• Trdi disk 1TB diskovnega prostora, ki je sestavljen iz 2 trdih diskov Segate ST3500320NS, vsak z velikostjo 500 GB.

4.1.2 PROGRAMSKA OPREMA

Na računalniku imamo naložen operacijski sistem Ubuntu 14.04. • Ubuntu je prosto dostopna distribucija Linuxa, ki temelji na distribuciji

Debian. Ubuntu je prvič izšel oktobra 2004, cilj ustvarjalcev tega operacijskega sistema je bil ponuditi sistem, ki temelji na Debianu in bi izhajal vsakih 6 mesecev ter za to posamezno verzijo nudil podporo naslednjih 18 mesecev.

Na strežniku je nameščen program za upravljanje virtualnih strojev Oracle VirtualBox – 5.0.4r102546.

• Virtualbox je odprtokodni program, ki ga je razvilo podjetje Oracle. Uporabljamo ga za to, da na računalniku lahko upravljamo virtualne stroje. Virtualni stroj lahko bazira na poljubnem operacijskem sistemu.

Na fizičnem računalniku je zagnan tudi videostrežnik BigBlueButton.

https://swqlab.fov.um.si/



To je odprtokodni strežnik, ki je bil razvit primarno za izobraževanje na daljavo.

4.2 SWQLAB – VIRTUALNI STROJ

4.2.1 STROJNA OPREMA VIRTUALNEGA RAČUNALNIKA

Virtualni računalnik upravljamo s programom Virtualbox, kjer lahko sami določimo količino pomnilnika, trdega diska in število procesorjev. Virtualni računalnik ima 4 GB pomnilnika, 30 GB trdega diska in 2 procesorja.

4.2.2 PROGRAMSKA OPREMA VIRTUALNEGA RAČUNALNIKA

Na virtualnem računalniku imamo naloženih več programov, ki so potrebni za delovanje izobraževalnega portala:

• Apache2 – spletni strežnik, • MySQL 5.5.32 – sistem za upravljanje baze podatkov, • PHP 5.4.17 – eden od najbolj razširjenih jezikov za razvoj in izvajanje

spletnih aplikacij, • Moodle 2.5.1 – programski paket za e-učenje.



5 BAZA PODATKOV SPLETNE UČILNICE SWQLAB

Ta baza vsebuje 331 različnih tabel. Za lažje razumevanje delovanja spletne učilnice bomo razložili, kateri podatki se zapisujejo v določene mape. Na sliki 2 je prikazan del tabel za aplikacijo Moodle.

Slika 2: Del tabel aplikacije Moodle za učni portal SWQLAB

Tabele na sliki 2 so urejene po padajočem številu zapisov. Največ zapisov je v tabeli mdl_log, ki predstavlja dnevnik dostopov in akcij v spletni učilnici Swqlab (1.2 milijona zapisov).



Tabele, ki si sledijo po številu vnosov, so: • mdl_assign_user_mapping - vsebuje podatke o nalogah uporabnikov, • mdl_grade_grades_history – vsebuje podatke o zgodovini ocen oddanih

nalog, • Mdl_assign_submision - vsebuje podatke o vseh do sedaj oddanih nalogah, • Mdl_assign_feedback_comments - vsebuje komentarje na oddane naloge, • Mdl_assign_feedback_file - zajema vse datoteke, ki so bile poslane kot

komentar na oddane naloge, • Mdl_bigbluebutton_log – dnevnik dogodkov, povezanih z uporabo

videokonferenčnega sistema. Na sliki 3 so prikazane tabele po padajoči velikosti.

Slika 3: Tabele po velikosti



6 NAČRT REPLIKACIJE IN TESTIRANJE

6.1 ZAČETNE NASTAVITVE IN PROGRAMI

Replikacijo bomo najprej izvedli na dveh virtualnih računalnikih. Eden bo služil kot glavni strežnik, eden pa kot pomožni strežnik. Za upravljanje virtualnih strojev bo uporabljen program Oracle Virtualbox. Za glavni in pomožni strežnik bomo uporabili že pripravljen virtualni stroj z nameščeno aplikacijo Moodle. S spletne strani uvozimo virtualni stroj in zaženemo program Virtualbox. Najprej uvozimo virtualni stroj v formatu ovf (open virtualization format), virtualnemu stroju določimo konfiguracijo navidezne strojne opreme in omrežja (velikost glavnega pomnilnika, število procesorjev, velikost grafičnega pomnilnika, mrežno kartico, način povezave v omrežje ipd.). Nato virtualni stroj zaženemo (slika 4).

Slika 4: Zagnan virtualni stroj

Na fizičnem računalniku poženemo spletni brskalnik in ga usmerimo na URL virtualnega računalnika. Po uspešni prijavi z uporabniškim imenom in geslom lahko uporabljamo Moodle (slika 5).



Slika 5: Primer ekrana aplikacije Moodle na virtualnem računalniku

Replikacijo bomo konfigurirali s programom PhpMyAdmin. Uporabljeni virtualni stroj ima iz varnostnih razlogov onemogočeno dostopanje do baze podatkov mysql. Spremenimo konfiguracijsko datoteko httpd-app.conf. Po prijavi v terminal virtualnega stroja uporabimo preprost urejevalnik nano:

sudo nano /opt/bitnami/apps/phpmyadmin/conf/httpd-app.conf

• Poiščemo vrstico, kjer piše: o Apache 2.2 Allow from 127.0.0.1 Namesto IP naslova 127.0.0.1

napišemo ALL. o Apache 2.4+ Require local Zapišemo REQUIRE ALL GRANTED.

• Ponovno zaženemo apache z ukazom

sudo /opt/bitnami//ctlscript.sh restart apache

• Osvežimo stran v spletnem brskalniku in zaženemo Phpmyadmin. Za prijavo uporabimo administratorski račun root na bazi podatkov.



6.2 VNOS TESTNIH PODATKOV IN ZAČETEK REPLIKACIJE

6.2.1 REPLIKACIJA DVEH GLAVNIH STREŽNIKOV

Pripravili smo dva virtualna stroja in ju v Virtualbox-u imenovali server1 z IP naslovom 192.168.2.127 in server2 z naslovom 192.168.2.33. Na server1 in 2 smo naložili testno bazo z imenom employees, ki smo jo pridobili na spletni strani: (https://launchpad.net/test-db/employees-db-1/1.0.6). V terminalu strežnika 1 smo vpisali ukaze:

• Za prenos stisnjene datoteke izvedemo ukaz:

wget https://launchpad.net/test-db/employees-db 1/1.0.6/+download/employees_db-full-1.0.6.tar.bz2

• Datoteko smo razširili z ukazom:

tar -xjf employees_db-full-1.0.6.tar.bz2 $ cd employees_db/

• Za uvoz baze employees smo izvedli ukaz:

mysql -u root -p -t < employees.sql Tudi v tem poskusu je bilo potrebno nastaviti parametre za delovanje PhpMyAdmin (glej poglavje 6.1). Drugi strežnik (server2) smo kreirali s kloniranjem prvega strežnika (server1). Na obeh strežnikih imamo pripravljeno bazo employees (slika 6).

Slika 6: Baza employees

6.3 NASTAVITVE REPLIKACIJE MASTER-MASTER

6.3.1 KONFIGURACIJA GLAVNEGA STREŽNIKA 1

Ko imamo baze podatkov na pravem mestu, lahko začnemo s postopkom replikacije. Najprej se bomo lotili replikacije z dvema glavnima strežnikoma. V tem primeru bo replikacija delovala tako, da bomo lahko tako na enem kot na drugem strežniku



zapisovali, urejali, posodabljali podatke v obeh bazah, bazi pa bosta sinhronizirani, zato se taka replikacija imenuje replikacija dveh glavnih strežnikov. Da pa nam bo replikacija delovala, moramo spremeniti nekaj nastavitev. Začnemo tako, da na strežniku 1 poiščemo datoteko my.cnf (če uporabljamo Wampserver ali XAMPP, se ta datoteka imenuje my.ini). Izvedemo ukaz v konzoli: sudo nano /opt/bitnami/mysql/my.cnf. Najprej poiščemo oddelek [mysqld], nato komentiramo vrstico, kjer piše bind-adress = 127.0.01 (pred to vrstico postavimo znak #, kar pomeni komentar). Nato pa v datoteko my.cnf v oddelku [mysqld] dodamo več vrstic:

• ID-strežnika: o server-id = 1

• Določimo baze, ki jih NE želimo replicirati: o binlog-ignore-db = mysql, test, bitnami_moodle o replicate-ignore-db = mysql, test, bitnami_moodle

• auto-increment-increment = 2 replicate-same-server-id = 0

• auto-increment-offset = 1

• Po koliko dneh sistem izbriše BINLOG datoteke: o expire_logs_days = 10

• Maksimalno velikost BINLOG-a: o max_binlog_size = 500M

• Kje v sistemu je locirana datoteka binlog: o log_bin = /opt/bitnami/mysql/data/binlog

Shranimo my.cnf (slika 7) ter ponovno zaženemo MySQL z ukazom:

sudo /opt/bitnami//ctlscript.sh restart mysql Nato ustvarimo novega uporabnika na strežniku 1 z ukazom:

CREATE USER 'repl'@'%' IDENTIFIED BY 'geslo' GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@'%' IDENTIFIE BY'geslo'; FLUSH PRIVILEGES;



Slika 7: Izgled my.cnf datoteke po konfiguraciji

Ko je uporabnik ustvarjen, mu dodamo še privilegij za dostop do želene baze:

GRANT USAGE, SELECT ON employees.* to repl; FLUSH PRIVILEGES;

V našem primeru je izbrana baza employees. To seveda lahko tudi zamenjamo z imenom druge baze. S tem smo zaključili konfiguriranje glavnega strežnika oziroma strežnika 1. Nadaljujemo konfiguracijo strežnika 2.

6.3.2 KONFIGURACIJA GLAVNEGA STREŽNIKA 2

Spremenimo datoteko /opt/bitnami/mysql/my.cnf. V oddelku [mysqld] komentiramo vrstico bind-adress = 127.0.01 (kot prvi znak napišemo #). Dodamo naslednje vrstice:.


• Določimo baze, ki jih NE želimo replicirati: o binlog-ignore-db = mysql, test, bitnami_moodle o replicate-ignore-db = mysql, test, bitnami_moodle

• auto-increment-increment = 2 • replicate-same-server-id = 0 • auto-increment-offset = 2 • Po koliko dneh sistem izbriše BINLOG datoteke:

o expire_logs_days = 10 • Maksimalno velikost BINLOG-a:

o max_binlog_size = 500M



• Kje v sistemu je locirana datoteka binlog: o log_bin = /opt/bitnami/mysql/data/binlog

Najpomembnejši spremembi glede na konfiguracijo prvega strežnika sta: server-id=2 in auto-increment=2. Ponovno zaženemo MySQL z ukazom:

sudo /opt/bitnami//ctlscript.sh restart mysql Nato kreiramo novega uporabnika baze podatkov:

CREATE USER 'repl'@'%' IDENTIFIED BY 'geslo' GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@'%' IDENTIFIED BY 'geslo'; FLUSH PRIVILEGES;

Uporabniku dodamo ustrezne pravice:

GRANT USAGE, SELECT ON employees.* to repl; FLUSH PRIVILEGIES;

Sledi zagon replikacije.

6.3.3 ZAGON REPLIKACIJE DVEH GLAVNIH STREŽNIKOV

Na strežniku 2 izvedemo ukaz:

CHANGE MASTER TO MASTER_HOST='192.168.2.127', MASTER_USER='repl', MASTER_PASSWORD='geslo';

Vpišemo IP naslov, na katerem se nahaja naš virtualni strežnik (strežnik 1), ter uporabniško ime in geslo, ki smo ju kreirali na virtualnem strežniku. Za zagon replikacije napišemo ukaz:

START SLAVE; Status delovanja pomožnega strežnika preverimo z ukazom:

SHOW SLAVE STATUS; Nato na strežniku 1 obrnemo replikacijo. Izvedemo naslednje ukaze:

CHANGE MASTER TO MASTER_HOST='192.168.2.33', MASTER_USER='repl',MASTER_PASSWORD='geslo', MASTER_LOG_FILE=' binlog.000001', MASTER_LOG_POS=120;



MASTER_LOG FILE in MASTER_LOG_POS dobimo tako, da na strežniku 2 vpišemo ukaz:

SHOW MASTER STATUS; Prepišemo podatka, ki nas zanimata. Za zagon replikacije na strežniku 1 izvedemo ukaz:

START SLAVE;

6.4 DELOVANJE REPLIKACIJE DVEH GLAVNIH STREŽNIKOV

Replikacija deluje tako, da imata strežnik 1 in strežnik 2 funkciji glavnega in pomožnega strežnika. To pomeni, da lahko na katerem koli od dveh strežnikov spreminjamo, dodajamo, urejamo podatke ali ustvarjamo nove tabele in se bodo le te replicirale na drugi strežnik. Prednost replikacije dveh glavnih strežnikov je predvsem v tem, da tudi v primeru, če eden izmed strežnikov preneha delovati, lahko normalno uporabljamo drugi glavni strežnik. V primeru, ko imamo replikacijo z glavnim in pomožnim strežnikom, nam pomožni zagotovi le bazo, ki je posodobljena do zadnje verzije, pri kateri je glavni strežnik deloval.

6.5 NASTAVITEV REPLIKACIJE Z GLAVNIM IN POMOŽNIM STREŽNIKOM

Za vzpostavitev replikacije z glavnim in pomožnim strežnikom smo ustvarili dva nova virtualna strežnika: server1, IP 192.168.2.154, in server2 , IP 192.168.2.250. Preizkus se bo nanašal na replikacijo testne baze employees.

6.5.1 KONFIGURACIJA GLAVNEGA STREŽNIKA

Začnemo tako, da na strežniku 1 popravimo datoteko my.cnf:

sudo nano /opt/bitnami/mysql/my.cnf

Najprej poiščemo oddelek [mysqld], nato vrstico, kjer piše bind-adress = 127.0.01, pred to vrstico postavimo znak #, kar pomeni komentar. Nato pa v datoteko my.cnf v oddelku [mysqld] dodamo še nekaj vrstic:

• ID-strežnika:

o server-id = 1 • Izberemo baze, ki jih NE želimo replicirati:

o binlog-ignore-db = mysql, test, bitnami_moodle o replicate-ignore-db = mysql, test, bitnami_moodle

• auto-increment-increment = 2 • replicate-same-server-id = 0 • auto-increment-offset = 1 • Po koliko dneh sistem izbriše BINLOG datoteke:

o expire_logs_days = 10



• Maksimalno velikost BINLOG-a: max_binlog_size = 500M

• Kje v sistemu je locirana binlog datoteka: o log_bin = /opt/bitnami/mysql/data/binlog

Po končani konfiguraciji shranimo našo my.cnf ter ponovno zaženemo MySQL z ukazom:

sudo /opt/bitnami//ctlscript.sh restart mysql Kreiramo uporabnika na strežniku 1:

CREATE USER 'repl'@'%' IDENTIFIED BY 'geslo'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@'%' IDENTIFIED BY 'geslo'; FLUSH PRIVILEGES;

Izvedemo ukaz

show master status;

Izpis je prikazan na sliki 8.

Slika 8: Rezultat ukaza show master status

Podatke za File in Position bomo rabili v naslednjem koraku, ko bomo konfigurirali pomožni strežnik.

6.5.2 KONFIGURACIJA POMOŽNEGA STREŽNIKA

V datoteko my.cnf dodamo v oddelku [mysqld] naslednje vrstice:


• Izberemo baze, ki jih NE želimo replicirati, in baze, ki jih želimo replicirati: o binlog-ignore-db = mysql, test, bitnami_moodle o binlog-do-db = employees

• Določiti moramo še direktorij, kjer se nahaja binarni dnevnik: o /opt/bitnami/mysql/data/binlog.

• Nato shranimo datoteko in zaženemo MySQL. Spremenili smo samo server-id, ostale nastavitve pa ostanejo enake kot na glavnem strežniku. Sedaj zaženemo replikacijo.



6.5.3 ZAGON REPLIKACIJE Z GLAVNIM IN POMOŽNIM STREŽNIKOM

Na pomožnem strežniku izvedemo ukaze:

CHANGE MASTER TO MASTER_HOST='192.168.2.154', MASTER_USER='repl', MASTER_PASSWORD='geslo', MASTER_LOG_FILE=' binlog.000003', MASTER_LOG_POS=154;

Master_host je IP naslov glavnega strežnika, Master_user, Master_password sta ime in geslo uporabnika, ki smo ga ustvarili na glavnem strežniku, Master_log_file, Master_log_position pa razberemo z glavnega strežnika, kar je v našem primeru vidno na sliki 8. Replikacijo zaženemo z ukazom start slave. Status delovanja replikacije preverimo z ukazom show slave status. Primer izpisa je prikazan na sliki 9.

Slika 9: Primer izpisa statusa replikacije z ukazom show slave status

6.5.4 DELOVANJE REPLIKACIJE Z GLAVNIM IN POMOŽNIM STREŽNIKOM

Za preverjanje delovanja sta na izpisu statusa (npr. na sliki 9) najpomembnejši vrednosti Slave_IO_Running in Slave_SQL_Running. Vrednost Slave_IO_State na sliki 9 kaže, da pomožni strežnik čaka na signal z glavnega strežnika. Spremembe na glavnem strežniku se prekopirajo na pomožni strežnik v datoteko relay_log.



Pri replikaciji glavnega na pomožni strežnik je potrebno poskrbeti, da se podatke spreminja izključno na glavnem strežniku. Spremembe na pomožnem strežniku se pri tej vrsti replikacije ne prenesejo na glavni strežnik.

6.5.5 TEŽAVE PRI VZPOSTAVITVI REPLIKACIJE

Požarni zid na strežniku Uporabljeni virtualni stroj (Bitnami Moodle) ima privzeto onemogočeno komunikacijo preko vrat 3306. Ta vrata pa privzeto uporablja mysql. Vrata 3306 odpremo za vse protokole (UDP, TCP) z ukazom:

Ufw allow 3306

Ufw je program (uncomplicated firewal), ki omogoča enostavno upravljanje požarnega zidu na operacijskem sistemu Linux, še posebej distribucij Debian in Ubuntu. Pravice za uporabnika, ki izvaja replikacijo Poleg pravic REPLICATION SLAVE in REPLICATION CLIENT mora imeti replikacijski uporabnik tudi pravici USAGE in SELECT. Ti dve pravici dodelimo uporabniku z ukazom:

grant usage,select on [ime_baze].* to [ime uporabnika, ki smo ga ustvarili];

Pot do binarnega dnevnika Uporabljeni virtualni stroj (Bitnami Moodle) je pri eksperimentiranju z različnimi variantami (pridobljenimi na spletu) izpisal opozorilo:

• Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

• Pravilna pot za uporabljeni virtualni stroj (Bitnami Moodle) je: o /opt/bitnami/mysql/data/binlog

Privzete nastavitve identifikacijske oznake strežnikov Uporabljeni virtualni stroj (Bitnami Moodle) ima v datoteki:

• /opt/bitnami/mysql/data/auto.cnf privzeto identifikacijsko oznako strežnika. Pri kloniranju virtualnega stroja mehanizem replikacije preveri ti oznaki. Ukaz show slave status izpiše:

• Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

Težavo rešimo z brisanjem /opt/bitnami/mysql/data/auto.cnf:



sudo rm /opt/bitnami/mysql/data/auto.cnf Po brisanju datoteke ponovno zaženemo MySQL z ukazom:

sudo /opt/bitnami/ctlscript.sh restart mysql

6.6 UPORABA MEHANIZMA »FAILOVER«

Mehanizem »failover« je namenjen zagotavljanju visoke razpoložljivosti podatkovnega vira. Princip delovanja »failover« predstavlja naslednji primer:

• Uporabimo dva fizična računalnika, na katerih bomo imeli vzpostavljene 3 virtualne računalnike z imeni S1, S2 in S3.

• S1 deluje kot glavni strežnik, S2 in S3 pa delujeta kot pomožna strežnika. • »Failover« omogoča, da pri odpovedi S1 njegovo nalogo brez posredovanja

operaterja prevzame eden od pomožnih strežnikov. • Ko odpravimo napako na S1, se vlogi S2 in S3 vrneta v prvotno stanje -

ponovno nastopata kot pomožna strežnika. • V uporabljenem virtualnem strežniku (Bitnami Moodle) najprej namestimo

mysql-utilites z ukazom:

sudo apt-get install mysql-utilites Po končani namestitvi ponovno zaženemo virtualni stroj. Slika 10 prikazuje arhitekturo replikacije za preskus mehanizma »failover«.

Slika 10: Arhitektura replikacije za preskus mehanizma »failover«

6.6.1 OSNOVNE NASTAVITVE ZA MEHANIZEM »FAILOVER«

Konfiguracijsko datoteko /opt/bitnami/mysql/my.cnf na S1 spremenimo tako, da dodamo :

• binlog-format=MIXED • log-bin • log-slave-updates=true • gtid-mode=on • enforce-gtid-consistency=true

S1 glavni strežnik

IP:192.168.2.154 Uporabniško ime: repl

Geslo: geslo

S3 pomožni strežnik IP:192.168.2.108

Uporabniško ime: repl Geslo: geslo

S2 pomožni strežnik IP:192.168.2.250

Uporabniško ime: repl Geslo: geslo



• master-info-repository=TABLE • relay-log-info-repository=TABLE • sync-master-info=1 • binlog-checksum=CRC32 • master-verify-checksum=1 • report-host=192.168.2.250 • report-host=192.168.2.180

Konfiguracijski datoteki /opt/bitnami/mysql/my.cnf na pomožnih strežnikih popravimo takole: S2, IP: 192.168.2.250

• binlog-format=MIXED • log-slave-updates=true • log-bin • gtid-mode=on • enforce-gtid-consistency=true • master-info-repository=TABLE • relay-log-info-repository=TABLE • sync-master-info=1 • slave-parallel-workers=2 • binlog-checksum=CRC32 • master-verify-checksum=1 • slave-sql-verify-checksum=1 • binlog-rows-query-log_events=1 • report-host=192.168.2.86

S3, IP: 192.168.2.180

• binlog-format=MIXED • log-slave-updates=true • log-bin • gtid-mode=on • enforce-gtid-consistency=true • master-info-repository=TABLE • relay-log-info-repository=TABLE • sync-master-info=1 • slave-parallel-workers=2 • binlog-checksum=CRC32 • master-verify-checksum=1 • slave-sql-verify-checksum=1 • binlog-rows-query-log_events=1 • report-host=192.168.2.86

Z ukazom preverimo, ali opcija GTID zares deluje (slika 11).

Slika 11: Pregled opcije GTID

GTID (global transaction identifier) je unikatna oznaka, kreirana za vsako transakcijo podatkov originalnega strežnika. Oznaka ni unikatna le na glavnem strežniku, temveč na vseh strežnikih, na katerih poteka replikacija. GTID je predstavljen kot par koordinat, ki so na sliki 11 razvidne pri parametru gtid_executed. Naslednji korak je kreiranje uporabnikov na vseh treh strežnikih. Ustvarili smo uporabnika:



• Uporabniško ime: repl • Geslo: geslo

Dodelili smo mu pravice REPLICATION SLAVE, REPLICATION CLIENT in USAGE na replicirani bazi employees. Replikacijo najprej zaženemo na S2 in S3. Na obeh vpišemo ukaze:

CHANGE MASTER TO MASTER_HOST = '192.168.2.154', MASTER_PORT = 3306, MASTER_USER = 'repl', MASTER_PASSWORD = 'geslo', MASTER_AUTO_POSITION = 1; Če imamo vključeno opcijo GTID, nastavimo ta parameter na 1 in bo le-ta avtomatsko repliciral spremembe.

Po izvedenem ukazu preverimo, če replikacija deluje. To storimo tako, da napišemo ukaz v konzolo Virtualbox-a, kjer lahko preverimo stanje našega glavnega strežnika ter dveh pomožnih strežnikov, ki sta z njim povezana. Na začetku smo imeli težave, saj ustvarjeni uporabnik »root« ni imel privilegijev, da bi se lahko povezal s katerim koli gostiteljem. Zato smo uporabniku »root« dodali privilegij:

grant all privileges on *.* to root@'%' identified by 'naše geslo'; flush privileges;

S tem smo rešili težavo. Replikacijo smo zagnali s Pythonskim skriptom:

$ mysqlrpladmin --master=root:[email protected]:3306 --slaves=root:[email protected]:3306, root:[email protected]:3306 health



Po izvedenem ukazu dobimo izpis: $ mysqlrpladmin --master= root:[email protected]:3306 --slaves=root:[email protected]:3306, root:[email protected]:3306 health # Checking privileges. # # Replication Topology Health: | +---------------+-------+---------+--------+------------+---------+ | host | port | role | state | gtid_mode | health | +---------------+-------+---------+--------+------------+---------+ |192.168.2.154 | 3306 | MASTER | UP | ON | OK | |192.168.2.250 | 3306 | SLAVE | UP | ON | OK |192.168.2.180 | 3306 | SLAVE | UP | ON | OK +---------------+-------+---------+--------+------------+---------+# ...done. Tukaj lahko vidimo, da glavni ter oba pomožna strežnika delujejo dobro. Nato smo nadaljevali z vzpostavitvijo mehanizma »failover«, a smo naleteli na težave. Mehanizem naj bi začel delovati, če vpišemo naslednji ukaz:

$ mysqlfailover --master=root:[email protected]:3306 --discover-slaves-login= root:bitnami --log=log.txt

Ko smo izvedli ukaz, se je izpisalo: MySQL Replication Failover Utility Failover Mode = auto Next Interval = Wed Aug 15 13:19:30 2012 Master Information ------------------ Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB Binlog.0000025 25 Replication Health Status +---------------+-------+---------+--------+------------+---------+ | host | port | role | state | gtid_mode | health | +---------------+-------+---------+--------+------------+---------+ |192.168.2.154 | 3306 | MASTER | UP | ON | OK | |192.168.2.250 | 3306 | SLAVE | UP | ON | OK |192.168.2.180 | 3306 | SLAVE | UP | ON | OK +---------------+-------+---------+--------+------------+---------+# Q-quit R-refresh H-health G-GTID Lists U-UUIDs Da sedaj preizkusimo mehanizem failover, moramo ugasniti MySQL storitev na glavnem strežniku ter pogledati, ali bo mehanizem sam enega od pomožnih strežnikov postavil kot glavni strežnik za toliko časa, dokler ne rešimo težave na primarnem strežniku. Ugasnili smo S1:

mysqladmin –uroot –p –h 192.168.2.154 shutdown Failover mehanizem naj bi potreboval okrog 15-30 sekund, da vzpostavi nov glavni strežnik, vendar se to v našem primeru ni zgodilo. Ko smo enkrat ugasnili storitev



MySQL na glavnem strežniku, se mehanizem »failover« iz neznanih razlogov ni zagnal. Tudi nov glavni strežnik ni bil vzpostavljen. Replikacija je sicer delovala naprej, saj so spremembe, ki so bile narejene na pomožnem strežniku, replicirale na glavni strežnik, ko smo ponovno zagnali storitev MySQL, in sicer z ukazom:

mysqladmin –uroot –p –h 192.168.2.154 start Zaradi nepopolnega delovanja storitve nismo uspeli konfiguracije testirati na produkcijskem strežniku Swqlab, saj tam procesi potekajo več časa in bi z nepravilnim delovanjem storitve morda izgubili določene podatke.



7 PRIPRAVA VIRTUALNEGA STROJA

Replikacijo v MySQL lahko izvedemo tudi s pomočjo MySQL Utilities. Začeti moramo s pripravo virtualnega stroja. Virtualni računalnik pripravimo v treh korakih:

• Na fizični računalnik prenesemo in namestimo Oracle Virtualbox. • Na fizični računalnik prenesemo Ubuntu 16.04.2 Server za 64-bitni procesor. • Kreiramo virtualni stroj in preverimo njegove lastnosti z ukazom:

o VBoxManage showvminfo Ubuntu16MysqlServer1. Prikazane so le najpomembnejše lastnosti:

Name: Ubuntu16MysqlServer1 Groups: / Guest OS: Ubuntu (64-bit) UUID: 5c9224b4-d189-41d2-829a-d014764d3d51 Memory size: 1024MB VRAM size: 16MB Number of CPUs:1 Effective Paravirt. Provider: KVM Monitor count: 1 3D Acceleration: off 2D Video Acceleration: off Storage Controller Name (1): SATA SATA (0, 0): /…./Ubuntu16MysqlServer1/Ubuntu16Mysql.vdi NIC 1: MAC: 080027C85AAA, Attachment: Bridged Interface 'enp4s0f1', Keyboard Device: PS/2 Keyboard Session name: GUI/Qt Video mode: 800x600x0 at 0,0 blank

Po končani namestitvi zaženemo virtualni stroj in pri namestitvi določimo uporabnika s sistemskimi privilegiji (v konkretnem primeru smo ga imenovali replika1) ter določimo geslo za uporabnika root v bazi podatkov. Ker je šlo izključno za demonstracijo, smo si dovolili v obeh primerih uporabnikov določiti geslo replika1. V produkcijskem režimu je nujno uporabiti bolj zapletena in različna gesla. Zaradi enostavnosti smo se odločili, da bomo replikacijo izvajali z uporabnikom root. V namestitvenem postopku smo zahtevali vključitev sklada LAMP (Linux-Apache-Mysql-PHP) in OpenSSH za oddaljeni dostop. Po namestitvi operacijskega sistema in baze podatkov izvedemo v virtualnem stroju naslednje ukaze:

• ifconfig S tem ukazom preverimo naslov IP virtualnega stroja. • sudo apt-get update & upgrade & dist-upgrade S tem izvedemo

posodobitve našega sistema. • sudo apt-get autoremoveS tem ukazom odstranimo vse nepotrebne

knjižice in jedra operacijskega sistema. • mysqladmin -uroot -p version Preverimo verzijo baze podatkov, v našem

primeru bomo uporabili verzijo 5.7.18 . • uname -a Preverimo verzijo jedra operacijskega sistema, v našem primeru

bomo uporabili verzijo 4.4.0-83 . • sudo apt-get install mysql-utilitiesNamestimo skupek programov za

enostavnejše upravljanje baze podatkov. • sudo ufw statusPreverimo status požarnega zida.



• sudo ufw enablePoženemo požarni zid ufw . • sudo ufw allow sshOmogočimo promet preko vrat 22 za oddaljene dostope. • sudo ufw allow mysqlOmogočimo promet preko vrat 3306 za oddaljene

dostope do baze podatkov. • sudo nano /etc/mysql/mysql.conf.d/mysqld.cnfKonfiguriramo delovanje

baze podatkov, spremembe so označene z rdečo pisavo in rumenim ozadjem. Vse nastavitve pišemo v polje [mysqld_safe].

[mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking bind-address = 0.0.0.0 key_buffer_size = 16M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 8 myisam-recover-options = BACKUP query_cache_limit = 1M query_cache_size = 16M server-id = 93 gtid-mode = ON enforce-gtid-consistency= ON log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M binlog_do_db = testna



• Naša naslednja naloga je, da omogočimo uporabniku root oddaljen dostop do baze podatkov. Preverimo privilegije:

o +-------------------------------------------------------------+

| Grants for root@% | +-------------------------------------------------------------+ | GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION | +-------------------------------------------------------------+

• Ugasnemo virtualni stroj in ga kloniramo. Paziti moramo, da vsakič

ponastavimo naslov MAC za virtualne stroje. • Vsak virtualni stroj zaženemo in:

o Ugotovimo naslov IP. o Spremenimo ime strežnika. V datoteki /etc/hostname smo uporabili

imena server1, server2, server3 in server4. o Spremenimo identifikacijske številke strežnikov v

/etc/mysql/mysql.conf.d/mysqld.cnf, tako da so te unikatne. o Spremenimo UUID v /var/lib/mysql/auto.cnf za server1, server2,

server3 in server4. [auto] server-uuid=7beedfae-5c9f-11e7-910f-080027c85aaa [auto] server-uuid=7beedfae-5c9f-11e7-910f-080027c85bbb [auto] server-uuid=7beedfae-5c9f-11e7-910f-080027c85ccc [auto] server-uuid=7beedfae-5c9f-11e7-910f-080027c85ddd

o Ponovno poženemo storitev mysql.service z ukazom sudo systemctl

restart mysql.service.



7.1 ARHITEKTURA SISTEMA VIRTUALNIH RAČUNALNIKOV

VIRTUALNI STROJI

server1 IP: 192.168.2.55

server2 IP: 192.168.2.87

server3 IP: 192.168.2.97

server4 IP: 192.168.2.104

VIRTUALBOX

7.2 MIGRACIJA Z MYSQL WORKBENCHOM

V prvem koraku moramo vzpostaviti povezavo s strežnikom in preveriti, ali povezava deluje.

Slika 13: Vzpostavitev povezave s strežnikom

Fizični računalnik

Slika 12: Arhitektura virtualnih računalnikov



Slika 14: Preverjanje povezave s strežnikom

Ko vzpostavimo povezavo s strežnikom, lahko začnemo z migracijo podatkov na vse štiri virtualne strežnike. Za migracijo podatkov s fizičnega računalnika na virtualne je potrebnih kar nekaj nastavitev.

• Izberemo izvorne podatke in ciljni sistem.

Slika 15: Migracija podatkov - izbira izvornih podatkov in ciljnega sistema



• Sledi pregled dosegljivosti strežnika.

Slika 16: Migracija podatkov - pregled dosegljivosti strežnika

• Nato izberemo izvorno shemo.

Slika 17: Izbira izvorne sheme

Na koncu izberemo še izvorne objekte (tabele) ter na ciljnem strežniku zahtevamo kreiranje nove sheme in migracija podatkov na virtualni strežnik se začne. Ko so podatki skopirani, dobimo še poročilo o opravljeni migraciji.



• Preverjanje dosegljivosti izvorne tabele.

Slika 18:Dosegljivost izvorne sheme

• Zahtevek za kreiranje nove tabele na ciljnem strežniku.

Slika 19: Zahteva za kreiranje nove tabele na ciljnem strežniku



• Kopiranje sheme in tabel na ciljni strežnik.

Slika 20: Kopiranje sheme in tabel na ciljni strežnik



8 RAZLIČNI EKSPERIMENTI Z MEHANIZMOM REPLIKACIJE

8.1 EKSPERIMENT 1: REPLIKACIJA Z GLAVNIM IN POMOŽNIM STREŽNIKOM

Vse nastavitve za delovanje replikacije imamo že urejene . Izbrali smo si glavni strežnik, strežnik1, katerega IP naslov se konča s številko 55. Naš pomožni strežnik pa ima IP naslov: 87. Replikacijo zaženemo z ukazom:

mysqlreplicate master=root:[email protected]:3306 --slave=root:[email protected]:3306 --rpl-user=root:replika1 -b

Replikacija deluje, naša naloga pa je, da to delovanje preverimo, kar naredimo v nekaj preprostih korakih. Najprej smo na strežniku 1 izbrali en vnos v tabeli, in sicer zaposlenega s številko 10001. To smo storili z ukazom:

SELECT * FROM employees where emp_no=10001;

Računalnik nam je dal izpis na spodnji sliki.

Slika 22: Rezultat poizvedbe, ki smo ga dobili z zgornjim ukazom na strežniku 1

Enak ukaz smo izvedli na strežniku 2 in dobili smo izpis, ki ga prikazuje spodnja slika.

Slika 23: Rezultat poizvedbe, ki smo ga dobili z zgornjim ukazom na strežniku 2

Slika 21: Zagnan mehanizem replikacije



Kot vidimo, so podatki na obeh slikah enaki. Naš naslednji korak bo, da spremenimo podatke na strežniku 1 ter nato na strežniku 2 pregledamo, ali replikacija deluje. Spremenili bomo datum zaposlitve zaposlenega, in sicer bomo datum postavili 2 dni pred tistim, ki je na zgornjih dveh slikah. To naredimo z ukazom:

UPDATE employees set hire_date = DATE_ADD(hire_date,INTERVAL -2 DAY) where emp_no=10001;

Rezultat, ki smo ga dobili, je na spodnji sliki.

Slika 24: Rezultat, ki smo ga dobili po izvedeni spremembi na strežniku 1

Če replikacija deluje pravilno, moramo na strežniku 2 dobiti enak izpis kot na strežniku 1. Da to preverimo, na strežniku 2 ponovno izvedemo ukaz:

SELECT * FROM employees where emp_no=10001; Rezultat tega ukaza je na spodnji sliki.

Slika 25: Rezultat, ki smo ga dobili po spremembi na strežniku 2

Rezultata sta enaka, kar pomeni, da replikacija deluje pravilno. Če želimo sedaj ustvariti mehanizem replikacije z dvema glavnima strežnikoma, moramo najprej ustaviti delovanje replikacije z glavnim in pomožnim strežnikom. Najprej moramo preveriti status replikacije, kar naredimo z ukazom:

show master status; Ko izvedemo ta ukaz, dobimo izpis (slika 26).



Slika 26: Rezultat po izvedbi ukaza "show master status"

Za zaustavitev replikacije moramo izvesti tri ukaze v pravilnem vrstnem redu, na strežniku 1 in strežniku 2. Ukazi so:

stop slave; reset slave; reset master;

Nato ponovno preverimo status replikacije, da vidimo, ali se je res ustavila. Rezultat ukaza je na sliki 27.

Slika 27: Stanje po zaustavitvi mehanizma replikacije

Vidimo, da se je replikacija res ustavila, ker je spet na začetni poziciji s številko 154.

8.2 EKSPERIMENT 2: REPLIKACIJA Z DVEMA GLAVNIMA STREŽNIKOMA

Da zaženemo replikacijo z dvema glavnima strežnikoma, moramo tako na strežniku 1 kot na strežniku 2 izvesti naslednji ukaz:

mysqlreplicate--master=root:[email protected]:3306 --slave=root:[email protected]:3306 --rpl-user=root:replika1 –b



Izveden ukaz na strežniku 1

Slika 28: Ukaz za zagon replikacije na strežniku 1

Izveden ukaz na strežniku 2

Slika 29: Ukaz za zagon replikacije na strežniku 2

Replikacija naj bi delovala, kar pa moramo preveriti. Ponovno bomo preverili en zapis in potem spremenili eno od vrednosti. Najprej pogledamo zapis na strežniku 2 z ukazom:

SELECT * FROM employees where emp_no=10001;

Rezultat poizvedbe imamo na spodnji sliki.

Slika 30: Rezultat poizvedbe na strežniku 2

Nato na strežniku 2 naredimo spremembo datuma. Datum, ki ima sedaj vrednost 1968-06-22, bomo povečali za 2. To naredimo z ukazom:

UPDATE employees set hire_date = DATE_ADD(hire_date,INTERVAL 2 DAY) where emp_no=10001;

Rezultat poizvedbe je na spodnji sliki.

Slika 31: Sprememba podatkov na strežniku 2

Kot lahko razberemo s slike, je rezultat za dva dni večji. Naša naslednja naloga je, da preverimo, ali se je sprememba naredila tudi na strežniku 1. Uporabimo ukaz:

SELECT * FROM employees where emp_no=10001; Rezlutat je na sliki 32.



Slika 32: Sprememba podatkov na strežniku 1

Ker imamo primer replikacije glavnih strežnikov, moramo za preskus delovanja narediti spremembo tudi na strežniku 1. Datum bomo ponovno spremenili za dva dni nazaj z ukazom:

UPDATE employees set hire_date = DATE_ADD(hire_date,INTERVAL -2 DAY) where emp_no=10001;

Ko smo izvedli ukaz, moramo na obeh strežnikih preveriti, ali so se podatki res spremenili. Na spodnjih slikah je rezultat poizvedbe.

Na strežniku 1

Slika 33: Rezultat spremembe na strežniku 1

Na strežniku 2

Slika 34: Rezultat spremembe na strežniku 2

Kot vidimo, sta rezultata enaka, kar pomeni, da naša replikacija deluje pravilno.

8.3 EKSPERIMENT 3: EN GLAVNI IN TRIJE POMOŽNI STREŽNIKI

Ker smo do sedaj že izvajali spremembe na strežniku 1 in strežniku 2, moramo najprej ponovno migrirati podatke na ta dva strežnika. Za pravilno delovanje replikacije moramo imeti izhodiščne podatke na vseh strežnikih enake. Po opravljeni migraciji podatkov lahko začnemo z vzpostavitvijo replikacije. Da preverimo, ali so podatki na vseh 4 strežnikih enaki, uporabimo ukaz:

SELECT*FROM employees; Ukaz nam je na vseh 4 strežnikih dal enak rezultat, vidimo ga na spodnji sliki.



Slika 35: Podatki, ki so enaki na vseh 4 strežnikih

Ko smo prepričani, da so podatki na vseh strežnikih enaki, lahko začnemo z zagonom replikacije. Za zagon moramo uporabiti ukaz:

mysqlreplicate--master=root:[email protected]:3306 --slave=root:[email protected]:3306 --rpl-user=root:replika1 –b

Če hočemo, da z enim glavnim strežnikom povežemo vse tri pomožne, moramo ukaz izvesti trikrat, le spremeniti moramo IP naslov slave strežnika. Izvedba ukaza je prikazana na spodnji sliki.



Naslednja naloga je, da spremenimo podatke in preverimo, ali so se te spremembe replicirale tudi na strežnik 2, strežnik 3, strežnik 4. Na strežniku 1 bomo spreminjali datum zaposlitve, in sicer ga bomo postavili dva dni nazaj. To storimo z ukazom:

UPDATE employees set hire_date = DATE_ADD(hire_date,INTERVAL 2 DAY) where emp_no=10001;

Da preverimo, ali je ukaz deloval, moramo preveriti podatke na vseh 4 strežnikih. To storimo z ukazom:

SELECT*FROM employees;

Rezultat ukaza je na sliki 37.

Slika 36: Zagon replikacije s tremi pomožnimi strežniki



Slika 37: Rezultat po izvedeni spremembi

Poizvedba nam je na vseh 4 strežnikih dala enak rezultat, kar pomeni, da naša replikacija deluje.

8.3.1 VZPOSTAVITEV MEHANIZMA FAILOVER

Predpogoj, da lahko vzpostavimo mehanizem failover, je delovanje replikacije, kjer imamo en glavni strežnik in več pomožnih. V prejšnjem poglavju smo uspešno vzpostavili replikacijo z enim glavnim in tremi pomožnimi strežniki. Glavni strežnik ima IP 192.168.2.55, pomožni pa 192.168.2.87, 192.168.2.97 in 192.168.2.104. Za zagon failover mehanizma moramo izvesti ukaz:


Rezultat izvedbe ukaza je na spodnji sliki.

Slika 38: Ukaz za zagon spremembe mehanizma failover

Po nekaj dnevih poizkušanja vzpostavitve mehanizma failover nismo prišli do rešitve, saj nam javi, da je naše uporabniško ime ali geslo napačno. Težava je v novosti, ki jo je uvedel MySQL v verziji 5.7. Ukaz




je pythonski skript. V verziji MySQL 5.7 so spremenili ime polja v tabeli in zato MySQL ne zazna našega gesla. V prejšnjih verzijah se je polje imenovalo »password«, v novi verziji pa se imenuje »authetication_string« in zato ukaz zazna, kot da imamo napačno geslo. Poskusili smo namestiti nov paket mysql-utilities verzija 1.6.5, vendar se pri namestitvi pojavi nekompatibilnost s paketom python-mysql.connector verzija 2.0.4-1. Zato namestitev ni bila mogoča. Preizkus samodejnega preklapljanja v primeru odpovedi glavnega strežnika je bil izveden, vendar zaradi omenjene nekompatibilnosti knjižnic ni uspel.



9 ZAKLJUČKI

Pri delu sem uporabljal različno literaturo in zbiral podatke iz več virov: knjig, spletnih strani in raznih blogov. S knjigami si nisem veliko pomagal, ker so podatki zastareli. Največ koristnih informacij sem pridobil na uradni spletni strani MySQLa. Tam sem dobil vse osnovne informacije o replikaciji in o tem, na kakšen način se jo da vzpostaviti. Za reševanje težav sem si največ pomagal z blogi, kot je StackOverflow. Na osnovi pridobljenega teoretičnega znanja sem začel s praktičnim delom vzpostavljanja mehanizma replikacije. Vzpostavil sem replikacijo dveh glavnih strežnikov, replikacijo z glavnim in pomožnim strežnikom in replikacijo z glavnim strežnikom in več pomožnimi strežniki. Sistem z dvema glavnima strežnikoma omogoča , da spremembe delamo na obeh strežnikih in se te replicirajo na drugega. Pri replikaciji z glavnim in pomožnim strežnikom lahko spremembe delamo le na glavnem strežniku in se te replicirajo na pomožnega. Replikacija z več pomožnimi strežniki pa pomeni, da spremembe delamo na glavnem strežniku, te pa se replicirajo na vse pomožne. Pri tej opciji lahko tudi v primeru odpovedi glavnega strežnika ročno vzpostavimo enega izmed pomožnih strežnikov kot glavnega in nadaljujemo delo na naši bazi. Mehanizem replikacije sem vzpostavljal z različnimi vmesniki. Replikacija s Phytonskimi skripti je bolj zapletena, vendar jo lahko hitro vpeljemo. V zadnjem delu diplomske naloge sem poskušal vzpostaviti tudi mehanizem failover. Mehanizem v primeru odpovedi glavnega strežnika avtomatsko enega izmed pomožnih strežnikov postavi za glavnega. Osnovni pogoj za delovanje tega mehanizma je, da imamo en glavni strežnik in več pomožnih. Pri vzpostavitvi smo naleteli na težave. V verzij MySQL 5.7 so spremenili ime polja v tabeli in zato MySQL ne zazna našega gesla. Težava naj bi bila rešena v verziji mysql-utilites 1.6.5, vendar se nam ob poskusu namestitve pojavi nekompatibilnost s paketom python-mysql.connector verzija 2.0.4-1. Zato namestitev ni bila mogoča. Skozi celotno diplomsko delo sem se naučil veliko novih dejstev o uporabi in vzpostavitvi mehanizma replikacije. Soočil in spoznal sem se s kar nekaj novimi tehnologijami in principi. Z izdelkom, oceno dela in rezultatom sem zadovoljen, čeprav nisem dosegel vseh na začetku zastavljenih ciljev.



VIRI IN LITERATURA

[ogledano 10.8.2016]. Dostopno na : https://sites.google.com/site/moodlepredstavitev/file-cabinet/zacetki-moodla

[ogledano 10.8.2016]. Dostopno na :https://www.phpmyadmin.net/

[ogledano 11.8.2016] Dostopno na: https://en.wikipedia.org/wiki/MySQL

[ogledano 11.8.2016] Dostopno na :http://mysqlserverteam.com/whats-new-in-mysql-5-7-generally-available/

[ogledano 12.8.2016] Dostopno na: https://en.wikipedia.org/wiki/Database_engine

[ogledano 12.8.2016] dostopno na http://dev.mysql.com/doc/refman/5.7/en/binary-log.html

[ogledano 15.8.2016] dostopno na: http://lewiscarr.co.uk/2013/07/moodle-mysql-replication-phpmyadmin/

[ogledano 18.8.2016] dostopno na: http://www.databasejournal.com/features/mysql/article.php/2248101/Referential-Integrity-in-MySQL.htm

[ogledano 15.8.2016] dostopno na: https://www.digitalocean.com/community/tutorials/how-to-set-up-mysql-master-master-replication

[ogledano 1.9.2016] dostopnp na: https://scriptingmysql.wordpress.com/2013/01/18/mysql-replication-with-global-transaction-identifiers-step-by-step-install-and-addition-of-slaves-part-one/Navodila za vzpostavitev replikacijo z uporabo GTID

Oracle:

Keep, Mat MySQL 5.6 Replication: New Resources for Database Scaling and HA. V: Oracle [online]. 2015, ogled [17.2.2016]. Dostopno na: https://blogs.oracle.com/MySQL/entry/mysql_5_6_replication_new1

Venkatesh, P. MySQL Replication and Scalability V: Oracle [online]. [ogledano 4. 2. 2016], dostopno na: http://www.oracle.com/technetwork/community/developer-day/mysql-replication-scalability-403030.pdf

Keep, Mat. MySQL 5.6 Replication Performance. V: Oracle [online] 2013, ogled [19. 2. 2016] Dostopno na: https://blogs.oracle.com/MySQL/entry/mysql_5_6_replication_performance

Keep, Mat. MySQL Development Milestone 5.6.2: Taking MySQL Replication to the Next Level. V: Oracle [online] 2011, ogled [19.2.2016] dostopno na:

https://sites.google.com/site/moodlepredstavitev/file-cabinet/zacetki-moodla

https://sites.google.com/site/moodlepredstavitev/file-cabinet/zacetki-moodla

https://www.phpmyadmin.net/

https://en.wikipedia.org/wiki/MySQL

http://mysqlserverteam.com/whats-new-in-mysql-5-7-generally-available/

http://mysqlserverteam.com/whats-new-in-mysql-5-7-generally-available/

https://en.wikipedia.org/wiki/Database_engine

http://dev.mysql.com/doc/refman/5.7/en/binary-log.html

http://lewiscarr.co.uk/2013/07/moodle-mysql-replication-phpmyadmin/

http://www.databasejournal.com/features/mysql/article.php/2248101/Referential-Integrity-in-MySQL.htm

http://www.databasejournal.com/features/mysql/article.php/2248101/Referential-Integrity-in-MySQL.htm

https://www.digitalocean.com/community/tutorials/how-to-set-up-mysql-master-master-replication

https://www.digitalocean.com/community/tutorials/how-to-set-up-mysql-master-master-replication

https://scriptingmysql.wordpress.com/2013/01/18/mysql-replication-with-global-transaction-identifiers-step-by-step-install-and-addition-of-slaves-part-one/Navodila



https://blogs.oracle.com/MySQL/entry/mysql_5_6_replication_new1

http://www.oracle.com/technetwork/community/developer-day/mysql-replication-scalability-403030.pdf

http://www.oracle.com/technetwork/community/developer-day/mysql-replication-scalability-403030.pdf

https://blogs.oracle.com/MySQL/entry/mysql_5_6_replication_performance



https://blogs.oracle.com/MySQL/entry/mysql_development_milestone_562_taking_mysql_replication_to_the_next_level

Ogledano [5. 5. 2017] dostopno na: https://severalnines.com/resources/tutorials/mysql-replication-high-availability-tutorial

MySQL

Ogledano [19. 2. 2016] dostopno na: https://dev.mysql.com/doc/refman/5.6/en/replication.html

Ogledano [19. 2. 2016] dostopno na: http://dev.mysql.com/doc/workbench/en/

Zmaga:

Ogledano [19. 2. 2016] dostopno na: http://www.zmaga.com/content.php?id Opisan postopek replikacijse sistema.

Ogledano [5. 5. 2017] dostopno na: http://www.clusterdb.com/mysql/replication-and-auto-failover-made-easy-with-mysql-utilities

DKUM

Hočevar, K. (2013), Zagotavljanje visoke razpoložljivosti v IT podjetju. Magistrsko delo, Kranj: Univerza v Mariboru, Fakulteta za organizacijske vede.

https://dk.um.si/Dokument.php?id=59174&lang=slv

Krebs, Z. (2008), Varnost podatkovne baze PostgreSQL. Diplomsko delo, Maribor: Univerza v Mariboru, Fakulteta za elektrotehniko, računalništvo in informatiko.


KNJIGE

Rensin, D. K., Fedorchek, M. A. (1996). SQL Server 6.5 Secrets, , John Wiley & Sons Inc Computers, Chicago IL

Ramakrishnan, R. (1997). Database management systems, William C Brown Pub Boston Massachusettes

Kruckenber, M., Pipes, J. (2005). Pro MySQL, Apress



https://dev.mysql.com/doc/refman/5.6/en/replication.html

http://dev.mysql.com/doc/workbench/en/

http://www.zmaga.com/content.php?id

http://www.clusterdb.com/mysql/replication-and-auto-failover-made-easy-with-mysql-utilities

http://www.clusterdb.com/mysql/replication-and-auto-failover-made-easy-with-mysql-utilities





KAZALO SLIK Slika 1: Arhitektura replikacije z dvema glavnima in tremi pomožnimi strežniki ... 8 Slika 2: Del tabel aplikacije Moodle za učni portal SWQLAB .......................... 11 Slika 3: Tabele po velikosti ................................................................. 12 Slika 4: Zagnan virtualni stroj.............................................................. 13 Slika 5: Primer ekrana aplikacije Moodle na virtualnem računalniku ................ 14 Slika 6: Baza employees .................................................................... 15 Slika 7: Izgled my.cnf datoteke po konfiguraciji ........................................ 17 Slika 8: Rezultat ukaza show master status .............................................. 20 Slika 9: Primer izpisa statusa replikacije z ukazom show slave status ............... 21 Slika 10: Arhitektura replikacije za preskus mehanizma »failover« .................. 23 Slika 11: Pregled opcije GTID .............................................................. 24 Slika 12: Arhitektura virtualnih računalnikov ............................................ 31 Slika 13: Vzpostavitev povezave s strežnikom ........................................... 31 Slika 14: Preverjanje povezave s strežnikom ............................................ 32 Slika 15: Migracija podatkov - izbira izvornih podatkov in ciljnega sistema ........ 32 Slika 16: Migracija podatkov - pregled dosegljivosti strežnika ........................ 33 Slika 17: Izbira izvorne sheme ............................................................. 33 Slika 18:Dosegljivost izvorne sheme ...................................................... 34 Slika 19: Zahteva za kreiranje nove tabele na ciljnem strežniku ..................... 34 Slika 20: Kopiranje sheme in tabel na ciljni strežnik ................................... 35 Slika 21: Zagnan mehanizem replikacije ................................................. 36 Slika 22: Rezultat poizvedbe, ki smo ga dobili z zgornjim ukazom na strežniku 1 . 36 Slika 23: Rezultat poizvedbe, ki smo ga dobili z zgornjim ukazom na strežniku 2 . 36 Slika 24: Rezultat, ki smo ga dobili po izvedeni spremembi na strežniku 1 ......... 37 Slika 25: Rezultat, ki smo ga dobili po spremembi na strežniku 2 .................... 37 Slika 26: Rezultat po izvedbi ukaza "show master status" ............................. 38 Slika 27: Stanje po zaustavitvi mehanizma replikacije................................. 38 Slika 28: Ukaz za zagon replikacije na strežniku 1...................................... 39 Slika 29: Ukaz za zagon replikacije na strežniku 2...................................... 39 Slika 30: Rezultat poizvedbe na strežniku 2 ............................................. 39 Slika 31: Sprememba podatkov na strežniku 2 .......................................... 39 Slika 32: Sprememba podatkov na strežniku 1 .......................................... 40 Slika 33: Rezultat spremembe na strežniku 1 ........................................... 40 Slika 34: Rezultat spremembe na strežniku 2 ........................................... 40 Slika 35: Podatki, ki so enaki na vseh 4 strežnikih ...................................... 41 Slika 36: Zagon replikacije s tremi pomožnimi strežniki ............................... 42 Slika 37: Rezultat po izvedeni spremembi ............................................... 43 Slika 38: Ukaz za zagon spremembe mehanizma failover.............................. 43

Documents

REPLIKACIJA BAZE PODATKOV V MYSQL · 2018-08-24 · The thesis deals with replication of a database in the MySQL database management system. Theoretical part presents the types of