Replikacja bazy danych w MySQL

Replikację możemy wykorzystać do zrobienia kopii zapasowej lub jako serwer zapasowy, do którego nasza aplikacja podłączy się, gdy serwer główny w wyniku awarii lub zbyt dużego obciążenia przestanie działać. Konfiguracja replikacji jest prostą operacją i wymaga zmiany zaledwie kilku ustawień w pliku konfiguracyjnym serwera głównego (master) oraz serwera zapasowego (slave).

Serwer główny (master)

Edytujemy plik z ustawieniami MySQL-a.

Do sekcji mysqld dodajemy ID serwera, ścieżkę do pliku dziennika oraz nazwy baz, które chcemy replikować. Nazwy baz mogą zawierać przecinki, więc musza być wypisane w osobnych liniach, a nie w postaci listy rozdzielonej przecinkami.

Restartujemy MySQL-a.

Tworzymy użytkownika, który będzie wykorzystywany do

Sprawdzamy czy ustawienia replikacji są poprawne.

Zapytanie „SHOW MASTER STATUS” powinno wyświetlić nazwę pliku dziennika, pozycję oraz nazwy baz, które będą poddawane replikacji.

File Position Binlog_Do_DB Binlog_Ignore_DB
mysql-bin.000001 106 nazwa_bazy_1,nazwa_bazy_2  

Serwer zapasowy (slave)

Edytujemy plik z ustawieniami MySQL-a.

Do sekcji mysqld dodajemy ID serwera (musi być inny niż ten, który ustawiliśmy na serwerze głównym), adres serwera głównego, login i hasło wcześniej utworzonego użytkownika oraz nazwy baz. Nazwy baz również wpisujemy w osobnych liniach.

Restartujemy MySQL-a.

Po restarcie replikacja zostanie automatycznie uruchomiona, więc musimy ją zatrzymać.

Teraz należy przenieść bazy, które chcemy replikować z serwera głównego na zapasowy. Możemy to zrobić przy pomocy programu mysqldump.

Po wykonaniu kopii zapasowej na serwerze zapasowym należy określić parametry. Wykonujemy zapytanie „CHANGE MASTER TO” podając adres serwera, dane do logowania oraz nazwę pliku dziennika i pozycję. Dwie ostatnie informacje uzyskujemy po wykonaniu polecenia „SHOW MASTER STATUS” na serwerze głównym.

Uruchamiamy replikację na serwerze zapasowym.

Weryfikacja

Sprawdzamy czy replikacja działa poprawnie.

Wynikiem będzie tabela z informacjami o serwerze głównym, replikowanych bazach oraz pozycji w dzienniku. W kolumnie „SLAVE_IO_STATE” powinien znaleźć się komunikat „Waiting for master to send event” co oznacza, że serwer zapasowy oczekuje na dane z serwera głównego. „MASTER_LOG_FILE” to nazwa dziennika, a „READ_MASTER_LOG_POS” to pozycja w dzienniku. Pozycja powinna być taka sama jak wartość zwracane przez zapytanie „SHOW MASTER STATUS” wykonane na serwerze głównym.

Oprócz tego, możemy wyświetlić listę procesów na obu serwerach.

Na serwerze głównym, na liście procesów pojawi się wpis z informacją o oczekiwaniu na aktualizację dziennika,

a na serwerze zapasowym informacja o oczekiwaniu na dane z serwera głównego.

Działanie replikacji można sprawdzić również wykonując poniższe zapytanie.

W wyniku otrzymamy m.in. wpis o nazwie „Slave_running” i wartości „ON”.

Uwagi

Opcja skip-networking nie może zostać włączona na serwerze głównym, gdyż serwer (lub serwery) zapasowe nie będą mogły nawiązać połączenia.

Podobnie jak skip-networking, opcja bind-address musi zostać wyłączona lub zawierać adres, do którego będą łączyły się serwery zapasowe.

Podczas przenoszenia bazy należy zwrócić uwagę na użytkownika, który został zdefiniowany jako twórca procedur czy triggerów. Jeżeli na serwerze slave użytkownik nie istnieje, to możemy otrzymać komunikat o błędzie. Poniższy komunikat został wygenerowany w momencie, gdy baza próbowała zreplikować zapytanie INSERT wykonane na tabeli, na której zdefiniowane były triggery.

Problem można rozwiązać poprzez dodanie użytkownika o takiej samej nazwie, a następnie nadaniu mu odpowiednich uprawnień do bazy na serwerze zapasowym.

Replikację można wznowić wykonując poniższe zapytania.

MySQL wznowi replikację począwszy od zapytania, które spowodowało problem.

Dodaj komentarz

Twój adres email nie zostanie opublikowany.