Sigurnost baza podataka - Multimaster replikacija i tajnost podataka

Izvor: SIS Wiki
Skoči na: orijentacija, traži

Sadržaj


Replikacija baza podataka

Replikacija baza podataka je kreiranje i održavanje višestrukih kopija iste baze. U većini implementacija replikacije baze podataka, jedan server baze podataka (engl. database server) održava glavnu (engl. master) kopiju baze, dok dodatni serveri održavaju kopije baze podataka, takozvane robove (engl. slave). U takvoj se arhitekturi sve što se treba zapisati u baze podataka šalje na master server, pa se replicira na slave servere, a čitanje se dijeli između svih servera; to rezultira povećanim performansama, budući da se dijeli teret. Replikacija baza podataka, također, može povećati dostupnost, budući da se slave serveri mogu konfigurirati da preuzmu master ulogu, ako prvotni master server postane nedostupan.

Tri su osnovna načina za izvođenje replikacije baze podataka:

  1. Replikacija snimkama: podaci se iz jednog servera baze podataka kopiraju u drugi ili u drugu bazu na istom serveru.
  2. Replikacija spajanjem: podaci iz dvije ili više baza podataka se kombiniraju u jednu bazu.
  3. Replikacija transakcijama: korisnici dobiju kompletne početne kopije baze, pa onda periodički dobijaju ažurirane podatke.

Multimaster replikacija

Multimaster (ili više-gospodarska, odnosno koja ima više gospodara) replikacija je usluga koja dozvoljava da podaci u većem broju baza podataka budu sinkronizirani. Ako se u sustavu s multimaster replikacijom u jednu bazu unese neki red, taj se red propagira svim drugim bazama unutar sustava. Analogno vrijedi za ažuriranje i brisanje podataka.

Da bi se uspostavila multimaster replikacija, konfiguracijom uključujemo baze podataka u "replikacijsku grupu", pri čemu je jedna baza iz grupe definirana kao "glavno mjesto definicije", a ostale kao "glavna mjesta". Razlika između ove dvije vrste mjesta je što se većina administratorskih komandi vezanih uz replikaciju moraju izvršiti na glavnom mjestu definicije.

Transakcije se u udaljene baze podataka propagiraju na dva načina: sinkrono i asinkrono. Sinkrona replikacija primjenjuje svaku transakciju na sva glavna mjesta u grupu odmah, dok asinkrona replikacija sprema sve transakcije koje se dogode na nekom mjestu u međuspremnik (engl. buffer) zvan "red odgođenih transakcija" (engl. deferred transaction queue) ili kraće deftran red, koji se periodički (recimo svake minute) prazni šaljući sve transakcije drugim mjestima.

Sustav za upravljanje bazama podataka Oracle je sinkronu replikaciju postigao koristeći funkcionalnost dvofaznog izvršavanja transakcije, kako bi se potvrdilo da su sve baze primjenile danu transakciju. Ako bilo koje od mjesta iz grupe nemože prihvatiti transakciju, tada nijedno mjesto u replikacijskoj grupi neće prihvatiti transakciju, što dovodi do neuspješnog izvršavanja transakcije. Za asinkronu replikaciju koriste proceduru pod nazivom schedule_push. Većina njihovih korisnika koji koriste multimaster replikaciju, radije izabiru asinkronu od sinkrone replikacije, zbog njenih mnogih prednosti.

Prije svega, asinkrona replikacija koristi puno manje mrežne propusnosti (engl. network bandwidth) i pruža bolje performanse nego sinkrona replikacija. Glavni razlog ovome je to što je efikasnije pohraniti nekoliko transakcija i onda ih propagirati kao grupu, nego propagirati svaku transakciju odvojeno. Važnost ove karakteristike se povećava s povećanjem udaljenosti između mjesta.

Također, sinkrone aplikacije imaju puno veći dodatak (engl. overhead), budući da svaka transakcija zahtijeva uspostavljanje nove veze prema svim mjestima iz grupe, dok asinkrona replikacija zahtijeva manje konekcija, budući da se transakcije propagiraju kao grupa.

Oracle 8.0 uveo je "paralelno propagiranje" s asinkronom replikacijom. Na ovaj se način propagira više od jedne transakcije u danom trenutku, što znatno povećava performanse replikacije. Paralelna propagacija se ne može primjeniti na sinkronu replikaciju budući da je stupanj paralelnosti propagacije definiran u proceduri schedule_push, koju sinkrona replikacija ne koristi.

Ipak, najveća prednost asinkrone replikacije je što pruža visoku dostupnost replikacijske grupe. To znači da ako jedno mjesto iz grupe prestane funkcionirati, druga će mjesta i dalje moći nastaviti raditi, dok će se transakcije gomilati u deftran redovima čekajući da nefunkcionalno mjesto ponovno postane dostupno.

S druge strane, sinkrona replikacija ne dozvoljava normalan rad ostalih mjesta, ako je jedno mjesto nedostupno. Razlog tomu je što je svaka transakcija mora odmah primjeniti na svim mjestima u replikacijskoj grupi, što naravno neće uspjeti za nedostupnu bazu. Zbog ovoga sinkrona replikacija pruža manje dostupnosti nego korištenje samo jedne baze.

Ipak, asinkrona replikacija ima i nedostatke: postoji mogućnost sukoba podataka, te ako se neko mjesto sruši, transakcije koje nisu propagirane mogu biti izgubljene.

U daljnjem tekstu su objašnjeni neki od težih problema kod multimaster replikacije, zajedno s nekim mogućim rješenjima.

Mogućnost sukoba u asinkronoj replikaciji

Zbog spremi-i-proslijedi prirode asinkrone replikacije, postoji mogućnost nekonzintentnih promjena podataka, koje smatramo sukobima. Tri su osnovne vrste sukoba:

Kako bi pokušao riješiti ovakve sukobe, Oracle ima "rukovatelje rezolucije sukoba" (engl. conflict resolution handlers), koji u većini slučajeva dobro rješavaju sukobe ažuriranja, ali ne rade dobro s sukobima jedinstvenosti, dok ih uopće nema za sukobe brisanja; rukovatelje je moguće i sam napisati.

Drugi način rješavanja sukoba je konfiguriranje aplikacije koja radi s bazama da piše samo u jednu bazu, dok sve ostale služe samo za čitanje. Na taj način ne može doći ni do jedne vrste sukoba. Ipak, treba omogućiti da aplikacija, u slučaju ispada baze u koju piše iz rada, nastavi daljnje zahtjeve slati na neku drugu bazu podataka.

Dakle, zaključujemo da ako planiramo koristiti asinkronu replikaciju, moramo dizajnirati aplikaciju sukladno tome, budući da asinkronu replikaciju nije jednostavno dodati kasnije.

Vrlo kratki intervali pražnjenja redova

Još jedan od problema asinkrone replikacije je postavljanje prekratkih intervala između pražnjenja redova, budući da to može iskoristiti velik broj resursa sustava. Pokretanje i zaustavljanje pražnjenja redova zahtijeva puno procesorskih ciklusa, pa je očito da će proces morati više raditi što je pražnjenje češće. Moguća je situacija u kojoj procesor nema dovoljno ciklusa dostupnih da bi započeo i završio pražnjenja u predviđenoj brzini, pa tako ni da bi zaista praznio redove odgođenih transakcija.

Rješenje ovakvog problema je ne pretjerivati kad se postavljaju intervali pražnjenja redova; intervali od 1 ili više minuta su sasvim u redu.

Alat za nadgledanje replikacijskog sustava

Kad replikacijska grupa koristi sinkronu replikaciju, sva mjesta u grupi moraju biti aktivna i ispravna kako bi se moglo ažurirati bilo koje mjesto, što uvelike smanjuje dostupnost replikacijske grupe. Mogući pristup sinkronoj replikaciji je napraviti automatizirani alat koji će periodično provjeravati status svih mjesta u replikacijskoj grupi. Ako alat odredi da je bilo koje mjesto nedostupno, pokušat će ga ponovno pokrenuti. Ako ne uspije, alat će dinamički ukloniti to mjesto iz replikacijske grupe, kako bi grupa mogla nastaviti funkcionirati.

Preporuka je da se ovakav alat pokreće s dva različita mjesta u grupi; jedno bi trebalo biti glavno mjesto definicije s kojeg se motre sva ostala mjesta, a s drugog mjesta se motri samo na glavno mjesto definicije. Kad alat s drugog mjesta otkrije kako se glavno mjesto definicije srušilo i ne može se ponovno pokrenuti, trebao bi dinamički realocirati glavno mjesto definicije na mjesto s kojeg se alat pokreće, a tek nakon toga briše prvotno glavno mjesto definicije iz grupe.

Budući da sinkrona replikacija ne sprema transakcije u deftran redove, nema načina za pratiti transakcije koje se pojavljuju na tim mjestima. Dakle, ako se mjesto na neko vrijeme ukloni iz sinkrone replikacijske grupe, pa ga želimo ponovno vratiti nazad u nju, potrebno je sve podatke u grupi ponovno učitati u to mjesto, odnosno, nije moguće učitati samo transakcije koje su se zbile nakon ispada mjesta iz grupe.

Također, da bi vratili mjesto u replikacijsku grupu, obavezno je suspendirati svu aktivnost nad cijelom grupom. Razumljivo je da povratak mjesta u replikacijsku grupu zahtijeva puno posla i dugo vrijeme ispada (engl. down time), zbog čega je preporučljivo planirati vrijeme ispada grupe.

Dodavanje novog mjesta u replikacijsku grupu

U sustavu za upravljanje bazama podataka Oracle postoji procedura add_master_database koja služi dodavanju mjesta u replikacijsku grupu. Jedan od parametara te procedure pruža odabir želimo li koristiti objekte (tablice, indekse i drugo) koji već postoje u novom mjestu ili želimo da se oni automatski kreiraju kao dio procesa dodavanja novog mjesta. Pomoću drugog parametra moguće je odabrati želimo li da sustav sam kopira podatke iz postojećih mjesta u novu bazu ili želimo koristiti podatke koji su već učitani u bazu. Kako ne bi došlo do pogreške, preporuča se prvo u novoj bazi kreirati sve objekte i popuniti tablice podacima, a tek onda dodavati mjesto u replikacijsku grupu. Ako radimo s drugom opcijom, potrebno je čekati duže vrijeme da se u novom mjestu kreira sve potrebno.

Korištenje više replikacijskih grupa

Moguće je kreirati više replikacijskih grupa unutar jedne baze podataka, te ih čak podijeliti u sinkrone i asinkrone grupe. Jedino je ograničenje da bilo koji objekt može pripadati samo jednoj grupi; na taj način particioniramo objekte između više grupa.

Razlog korištenja više grupa može biti u različitosti vremenske osjetljivosti podataka u baz (poput visoko osjetljivih cijena dionica i malo osjetljivih sportskih rezultata). Tada je korisno podatke s visokom osjetljivošću smjestiti u sinkronu grupu ili u asinkronu grupu s vrlo malim intervalom pražnjenja redova, a one s niskom osjetljivošću u asinkrone grupe s normalnim ili dužim intervalom pražnjenja redova. Ova podjela vodi smanjenju ukupnog korištenja mrežnog prometa, budući da samo dio podataka šaljemo često.

Drugi razlog za korištenje više grupa je ako relativno malena količina vrijednosti u bazi vrlo problematična s obzirom na podatkovne sukobe. Ukoliko se radi o većoj količini problematičnih vrijednosti, preporuča se korištenje samo jedne sinkrone replikacijske grupe.

Ipak, korištenje više replikacijskih grupa povećava kompleksnost baze i čini posao njenog administriranja još težim. Potrebno je paziti da se izbjegnu ovisnosti između replikacijskih grupa, odnosno, ne smije se dozvoliti da se vanjski ključevi prostiru kroz nekoliko grupa.

Problemi se mogu pojaviti ako se tablica roditelj nalazi u asinkronoj grupi sa dugim intervalom pražnjenja redova, a tablica dijete u grupi s kratkim intervalom pražnjenja redova ili u sinkronoj grupi. Ako jedna transakcija u lokalnoj bazi kreira roditelja, a zatim i dijete koje se referencira na tog roditelja, postoji mogućnost da će se dijete propagirati u ostale grupe prije roditelja, što bi dovelo do kršenja referencijalnog integriteta.

Čak i ako nema vanjskih ključeva koji se prostiru kroz nekoliko grupa, SQL izrazi koji pristupaju bazi ne bi trebali pristupati podacima koji se nalaze u različitim replikacijskim grupama. To zahtijeva čvrstu i trajnu koordinaciju između administratora baza podataka i razvojnih programera.

Za kraj vrijedi reći da je multimaster replikacija vrlo snažna i fleksibilna mogućnost, ali sa snagom i fleksibilnošću dolazi i kompleksnost.

Sinkrona replikacija u PostgreSQL-u 9.1

Uobičajena replikacija u PostgreSQL-u je asinkrona. Ako se primarni, tj. master, server sruši, tada se možda neke izvršene transakcije neće replicirati na ostale servere, što uzrokuje gubitak podataka.

Sinkrona replikacija nudi mogućnost potvrđivanja da su sve promjene koje je napravila transakcija prenesene na jedan sinkroni pričuvni server. Ovo proširuje standardnu razinu trajnosti koju nudi izvršavanje transakcije.

Kad se zahtjeva sinkrona replikacija, svako izvršavanje transakcije koja piše će čekati da stigne potvrda da je izvršenje zapisano u transakcijski dnevnik na disku od oba (primarnog i pričuvnog) servera. Jedini način na koji podaci mogu biti izgubljeni je ako oba servera padnu u isto vrijeme. Stoga ovo pruža puno višu razinu trajnosti, ako je sistemski administrator oprezan što se tiče smještanja i upravljanja serverima. Čekanje na potvrdu povećava korisničko povjerenje da se promjene neće izgubiti u slučaju pada sustava, ali i nužno povećava vrijeme odgovora. Minimalno vrijeme čekanja je vrijeme odziva (engl. roundtrip time) između primarnog i pričuvnog servera.

Transakcije koje samo čitaju i poništenja transakcija ne moraju čekati odgovor od pričuvnog servera, kao ni izvršenja podtransakcija. Dugotrajne akcije poput učitavanja podataka ili izgradnje indeksa ne trebaju čekati konačnu poruku potvrde (izvršenja). Sve akcije s dvofaznim izvršenjem trebaju čekati na potvrdu, uključujući pripremu i izvršenje.

Osnovne postavke

Jednom kad je replikacija podešena, podešavanje sinkrone replikacije zahtijeva samo jedan dodatan korak: synchronous_standby_names trebaju biti postavljeni kao nepraznu vrijednost. Također, synchronous_commit se mora uključiti, ali to većinom nije potrebno, jer je to uobičajena vrijednost. Ova konfiguracija će uzrokovati da svako pohranjivanje čeka potvrdu da je pričuva pohranila bilješku o izvršenju na dugotrajno spremište podataka, čak iako je za to potrebno puno vremena.

Nakon što je izvršenje pohranjeno na disku na primarnom serveru, WAL bilješka (WAL je kratica za write-ahead logging, tj. bilježenje za pisanje unaprijed) se šalje na pričuvni. Pričuvni šalje poruku odgovora svaki put kad se nova skupina WAL podataka zapiše na disk, osim ako je wal_receiver_status_interval postavljen na nulu na pričuvnom serveru. U slučaju gašenja servera, server se neće ugasiti dok sve WAL bilješke nisu prenesene na pričuvne servere.

Planiranje performansi

Sinkrona replikacija uobičajeno zahtijeva pažljivo isplanirane i postavljene pričuvne servere kako bi osigurali da će se aplikacija ponašati prihvatljivo. Čekanje ne koristi sistemske resurse, ali transakcijska zaključavanja nastavljaju držati dok se prijenos ne potvrdi. Neoprezna uporaba sinkrone replikacije će smanjiti performanse za aplikacije baze podatka, budući da je povećano vrijeme čekanja odgovora i količina sukoba.

PostgreSQL dozvoljava razvojnim programerima aplikacija specificiranje razine trajnosti potrebne za replikaciju. Ovo može biti specificirano za cjelokupni sustav ili za pojedine korisnike, konekcije ili transakcije.

Planiranje visoke dostupnosti

Izvršenja napravljena kad je synchronous_commit uključen će čekati dok pričuva ne odgovori. Ako se posljednji (ili jedini) pričuvni server sruši, odgovor nikad neće stići.

Najbolja solucija za izbjegavanje gubitka podataka je utvrđivanje da ne gubimo posljednji pričuvni server. Ovo se može postići imenovanjem više potencionalnih sinkronih servera koristeći synchronous_standby_names. Prvi imenovani pričuvni server će biti korišten kao sinkroni pričuvni, a ostali će preuzimati njegovu ulogu ako on padne.

Kad je pričuvni isprva vezan na primarni, neće biti odmah pravilno sinkroniziran, nego prvo ulazi u način rada dostizanja (engl. catchup mode). Jednom kad je kašnjenje između pričuvnog i primarnog servera dostiglo nulu, ulazimo u pravovremensku replikaciju. Pričuvni server postaje sinkroni pričuvni server tek kad je izvršio dostizanje.

Ako se primarni resetira dok izvršenja čekaju potvrde, te će se transakcije potpuno izvršiti jednom kad se primarna baza oporavi. Nema načina na koji bi mogli biti sigurni da su svi pričuvni primili sve WAL podatke za vrijeme rušenja primarnog. Neke transakcije se možda neće pokazati kao izvršene na pričuvnima, iako se pokazuju izvršenima na primarnom. PostgreSQL garantira da aplikacija neće dobiti eksplicitne potvrde uspješnih izvršenja transakcija dok nije sigurno da su pričuvni primili WAL podatke.

Aplikacija

Multimaster replikacija pomoću sustava Bucardo

Za aplikativni dio izrade projekta izabrao sam izraditi aplikaciju u sustavu Postgresql, sustavu otvorenog koda (engl. open source) za upravljanje objektno-relacijskim bazama podataka. Do verzije 9.1 PostgreSQL je podržavao samo asinkronu replikaciju, ali od nje podržava i sinkronu replikaciju. Problem je što ne podržava multimaster replikaciju. Stoga ću koristiti Bucardo sustav za asinkronu replikaciju koji omogućava multimaster replikaciju, objavljen pod BSD licencom. Bucardo ne podržava udruživanje konekcija, balansiranje tereta i particioniranje upita (engl. connection pooling, load balancing i query partitioning), ali ću tek vidjeti hoće li mi to stvarati probleme u radu.

Instalacija

Pomoću programa VirtualBox sam podigao dvije virtualne mašine i u njima podigao Ubuntu server. Zatim sam instalirao Bucardo, koji je sam instalirao potrebne pakete, a među njima i PostgreSQL 8.4 (Bucardo još nije konfiguriran za rad s verzijom 9.1).

Podesio sam PostgreSQL kako bi slušao lokalnog domaćina (engl. localhost), dodao lozinku za postgres korisnika i namjestio MD5 autentikaciju za njega. Pomoću sudo -u postgres createuser --superuser vatra sam kreirao korisnika s nazivom vatra, a zatim i bazu pomoću naredbe createdb vatra. Kreirao sam i dodatnu bazu, sis_bp, s kojom ću raditi na ovom projektu.

Restartirao sam PostgreSQL i zatim instalirao Bucardo jednostavnom naredbom sudo apt-get install bucardo, koja je odmah instalirala i ostale potrebne pakete. Zatim sam u željenom direktoriju pokrenuo naredbu sudo bucardo_ctl install kako bih kreirao Bucardo bazu podataka, prethodno u /var/run napravivši direktorij bucardo s ovlastima 770 i nakon objavljene greške promijenio zadanu lozinku bucardo-a. Ali tu je sve stalo, te nisam uspio dovršiti instalaciju.

Master-slave replikacija u PostgreSQL

Na dvije nove virtualne mašine podignuo sam ponovno Ubuntu server, OpenSSH i PostgreSQL 9.1, te započeo rad na uobičajenoj replikaciji.

Za početak je potrebno kreirati klaster bazi podataka (engl. database cluster). To je kolekcija bazi podataka kojom se upravlja pomoću jedne instance pokrenutog servera baze podataka.

Budući da zadani PostgreSQL korisnik (postgres) nema .bashrc, ni .bash_profile nakon što je PostgreSQL instaliran, potrebno ih je ručno kreirati. Početni direktorij za korisnika postgres je /var/lib/postgresql/, pa sam u njemu kreirao .bashrc sa samo jednom linijom: export PATH="/usr/lib/postgresql/9.1/bin:/usr/local/sbin:/usr/bin:/bin". U .bash_profile sam stavio dvije linije: export PGLIB=/usr/lib/pgsql i export PGDATA=/var/lib/pgsql/data. Tako sam odredio da će mi direktorij za podatke klastera biti /var/lib/pgsql/data.

Kreirao sam direktorij /var/lib/pgsql i dodijelio mu prava pomoću naredbe chown postgres /var/lib/pgsql/. Tada sam se prebacio na korisnika postgres i pokrenuo naredbu za inicijalizaciju klastera bazi podataka: initdb /var/lib/pgsql/data.

Sve ove prethodne korake je potrebno napraviti i na master i na slave serveru.

Za daljnje potrebe sam kreirao par ključeva na oba servera za postgres korisnika naredbom ssh-keygen -t rsa, pa poslao javni ključ na drugom serveru naredbom scp /var/lib/postgresql/.ssh/id_rsa.pub postgres@<IP servera kojem šaljem>:~/.ssh/authorized_keys, kako ne bih svaki puta morao upisivati lozinku za pristup tom serveru (potrebno je znati lozinku postgres korisnika ili ju postaviti kao root korisnik naredbom passwd postgres). Tako sam si olakšao idući korak: izradu početne kopije (engl. base backup) klastera bazi podataka. Budući da bi arhiviranje trebalo vršiti na lokaciju kojoj slave server može pristupiti čak i kada master nije u funkciji, bolje je čuvati arhivu na slave serveru ili na nekom drugom serveru od povjerenja, pa stoga na slave serveru, u postgres ulozi, kreiramo direktorij /var/lib/pgsql/archive.

Na master serveru u /var/lib/pgsql/data/postgresql.conf treba napraviti sljedeće izmjene:

Pojašnjenje komande za arhiviranje:

Ugasimo PostgreSQL oba servera naredbom /etc/init.d/postgresql stop kao root.

Na masteru, kao postgres korisnik u /var/lib/pgsql direktoriju, pokrenemo inicijalizirani klaster naredbom pg_ctl -D /var/lib/pgsql/data start. Nakon toga obavimo sigurnosnu pohranu (engl. backup) svih datoteka iz podatkovnog direktorija klastera sljedećim naredbama:

Kopiramo dobivenu tar datoteku na slave server naredbom scp pg_base_backup.tar postgres@192.168.1.111:/var/lib/pgsql, a zatim na slave serveru kao root korisnik napravimo:

Nakon toga još treba izbrisati postmaster.pid iz /var/lib/pgsql/data/.

Sada je potrebno napraviti dodatne izmjene u postgresql.conf i pg_hba.conf datotekama.

Izmjene u /var/lib/pgsql/data/postgresql.conf, na master serveru:

Izmjene u /var/lib/pgsql/data/pg_hba.conf, na master serveru:

Izmjene u /var/lib/pgsql/data/postgresql.conf, na slave serveru:

Dodati /var/lib/pgsql/data/recovery.conf, na slave server, sa sadržajem:

Sada možemo ponovno pokrenuti oba servera pomoću pg_ctl -D /var/lib/pgsql/data start.

Literatura

Replikacija u CouchDB

Izvršavanjem jednostavne naredbe apt-get install couchdb intaliran je CouchDB. Preko web browsera (izvan virtualnih mašina) pristupimo CouchDB-u na svakoj mašini upisom njene IP adrese s portom 5984. Dodamo li nakon toga još i /_utils, dobit čemo Futon, konzolu za administraciju baze putem web-a. Jedina potrebnu izmjenu obavljamo u odjelu Configuration, mjenjajući vrijednost bind_address polja u 0.0.0.0, kako bi CouchDB slušao sve IP adrese.

Sada je potrebno na obje mašine kreirati bazu podataka (i dalje putem Futon-a), koje ne moraju imati isto ime. Zatim na jednoj mašini u Replicator-u podesimo da se promjene repliciraju s lokalne baze na udaljenu, s time da pod udaljenu moramo upisati IP adresu druge vritualne mašine, njen port i nakon znaka / ime baze iz druge virtualne mašine (primjer: http://192.168.2.2:5984/baza_na_drugoj_masini). Opciju Continuous je preporučljivo uključiti jer ona uključuje kompleksan algoritam koji sam odlučuje kada je najbolje napraviti replikaciju na udaljenu bazu, stalno provjeravajući ima li promjena koje je potrebno replicirati. Klikom na gumb Replicate napravili smo master-slave replikaciju u CouchDB-u.

Ako želimo napraviti multimaster replikaciju na način da u svaku bazu možemo upisivati i replicirati te podatke na ostale baze, potrebno je isti postupak ponoviti na bazama koje su do sada bile slave; u našem slušaju to je baza_na_drugoj_masini. Dakle, u Replicator-u na drugoj mašini podesimo s koje lokalne baze i na koju udaljenu (na primjer: http://192.168.2.1:5984/baza_na_prvoj_mašini) se replicira. Uključimo opciju Continuous i kliknemo Replicate, tako dobivši multimaster replikaciju u dvije CouchDB baze podataka.

Korisnici i sigurnost

Replikacija u MySQL-u

Podigao sam nove virtualne mašine i na njih instalirao MySQL server, pa na obje kreirao novu bazu podataka imena replicate_me.

Na master serveru u /etc/mysql/my.cnf sam napravio određene izmjene:

Snimio sam datoteku, resetirao mysql i ponovno ušao u njega. Zatim sam izvršio naredbe:

Na slave serveru sam izmjenio postojeći /etc/mysql/my.cnf, dodavši:

I zatim u mysql-u napravio:

Sada je replikacija uspostavljena, i svaka tablica kreirana na masteru, kreira se i na slave-u.

O radu

Autor: Vatroslav

Tema registrirana: 21:59, 25. rujna 2011. (CEST)

Literatura

Dodatno štivo

Dobavljeno iz "https://security.foi.hr/wiki/index.php/Sigurnost_baza_podataka_-_Multimaster_replikacija_i_tajnost_podataka"
Osobni alati
Imenski prostori
Inačice
Radnje
Orijentacija
Traka s alatima