Kada prvi slave server zapiše događaj binarnog dnevnika s master servera u svoj vlastiti binarni dnevnik, tada će događaj gotovo sigurno biti na različitoj poziciji u dnevniku nego na poziciji kod master servera tj., može biti u različitom dokumentu dnevnika ili na različitoj brojčanoj poziciji unutar datoteke dnevnika.

Ovo može otežati neke poslove kao što je npr. promjena slave servera u master server ili postavljanje slave serveru novog master servera.

(Treba paziti jesu li maknute sve opcije koje su postavljene na slave serveru samo za slave server, isto tako ako je degradiran master server jesu li mu maknute sve postavke master servera i dodane postavke slave servera.

Ipak, neki događaji dnevnika će biti izgubljeni trajno, što bi trebalo biti spriječeno s konfiguriranjem master servera sa sync_binlog.

Također ako želimo napraviti zamjenu uloga slave servera i master servera, tada je potrebno imati datoteke istog imena. (Potrebno je imati i korisnički račun na slave serveru ako želimo napraviti zamjenu uloga servera.)

Pronalaženje željene pozicije dnevnika Ako svaki slave server nije na istoj poziciji kao novi master server, bit će potrebno pronaći poziciju u novom binarnom dnevniku master servera koja odgovara zadnjem događaju kojeg je slave server replicirao, i koristiti tu poziciju za CHANGE MASTER TO.

Može se koristiti alat mysqlbinlog za otkrivanje zadnjeg upita kojeg je slave server izvršio i pronalaženje tog istog upita u novom binarnom dnevniku master servera.

III) Izabirati jedan slave server za novi master server i provjeriti je li potpuno zahvaćen replikacijom (tj. treba pustiti neka završi sve povezne dnevnike koje je dohvatio s master servera).

Postoje dva osnovna scenarija za zamjenu master servera s jednim od njegovih slave servera.

Prema tome potrebno je kreirati korisnički račun na master serveru i dati mu odgovarajuće privilegije, tako se U/I dretva može spojiti kao korisnik i čitati iz binarnog dnevnika master servera.

Vidimo slave server koji čeka događaj s master servera.

U/I dretva čeka na događaj master servera, što znači da je dohvatila sve binarne dnevnike master servera.

II) Pustiti neka svi slave serveri završe izvršavanje poveznih dnevnika koje su dohvatili sa starog master servera prije njegovog pada.

Oštećenja poveznih dnevnika na slave serveru Ako je binarni dnevnik master servera neoštećen, tada se koristiti naredba CHANGE MASTER TO za pokazivanje i ponovo dohvaćanje oštećenih poveznih dnevnika.

Proces obnove InnoDB mehanizma pohrane ispisuje koordinate binarnog dnevnika do točke gdje je završena obnova, to se može koristit za upućivanje slave servera na točku master servera.

Također omogućuje upućivanje slave servera na master servera bez zaustavljanja servera.

Uspostava replikacije na strani glavnog (master) servera

Slanje događaja replikacije na drugi server Opcija log_slave_updates dopušta korištenje slave servera kao master servera drugim slave serverima.

Također postoji i master ¬ master topologija u aktivno ¬ aktivnom načinu rada, koja je već spomenuta, gdje možemo zapisivati na oba master servera.

Ako disk starog master servera nije oštećen, i dalje se mogu obnoviti nedostajući događaji sa njegovog binarnog dnevnika s mysqlbinlog ili s dnevničkim serverom.

Kao što slika prikazuje, mi možemo biti sigurni da je server2 server replicirao sve događaje iz binarnog dnevnika master servera zato jer Master_Log_File i Read_Master_Log_Pos pokazuju zadnju poziciju servera server1.

Korištenje slave servera kao master servera U replikaciji gdje slave server nema uključenu opciju log_slave_updates, promjena na master serveru uzrokuje događaj koji se zapisuje u vlastiti binarni dnevnik.

Ova konfiguracija omogućuje propagiranje promjena s originalnog master servera na slave servere koji nisu direktno povezani na master server.

Tada se pronađe isti upit u binarnom dnevniku novog master servera, isto s mysqlbinlog alatom.

To će prikazati pomak u bajtovima od upita, i taj pomak se može koristiti u CHANGE MASTER TO naredbi prilikom postavljanja svakom slave serveru novog master servera.

Znači, replikacija se može ostvariti i s više master servera koji su međusobno povezani bez prisustva slave servera. Master serveri omogućuju održavanje baze podataka, a slave serveri repliciraju podatke s master servera i obično ne omogućuju nikakve promjene podataka.

Ipak ovo ne rješava sve probleme koje ćemo imati s dva master servera kod kojih se na oba zapisuju podaci.

Svaki zahtjevni posao s master servera se možda ponovo izvršava na svakom slave serveru.

Ako se može maknuti posao s master servera na slave server, samo jedan od slave servera će morati raditi posao.

Multimaster replikacija s korištenjem master ¬ master topologije U ovoj konfiguraciji, svaki od dva master servera sadrži vlastite podatke.