MySQL Master: Jak wykorzystać replikację i zarządzać danymi?

MySQL to jedno z najczęściej wybieranych narzędzi do zarządzania bazami danych na świecie. Jego wydajność, łatwość w obsłudze i wszechstronność sprawiają, że jest idealnym rozwiązaniem zarówno dla małych projektów, jak i dużych, rozbudowanych systemów. W tym artykule przyjrzymy się jednej z ważniejszych funkcji MySQL – replikacji master-slave, czyli konfiguracji, w której serwer główny (master) synchronizuje swoje dane z serwerami podrzędnymi (slave). Będziemy omawiać, jak skonfigurować MySQL Master, jakie korzyści płyną z jego używania oraz zaprezentujemy przykłady, które pomogą Ci w pełni zrozumieć ten proces.

Co to jest MySQL Master?

W kontekście MySQL, termin "Master" odnosi się do serwera bazodanowego, który jest odpowiedzialny za przechowywanie głównych danych oraz ich zapisy. Serwer ten jest "głównym" punktem w systemie replikacji, który przekazuje swoje dane do innych serwerów – określanych jako "Slave". Dzięki temu możliwe jest tworzenie kopii zapasowych, poprawa wydajności oraz łatwiejsze skalowanie aplikacji, ponieważ zapytania odczytujące mogą być rozkładane na różne serwery slave.

Replikacja w MySQL pozwala na tworzenie kopii danych z serwera master na wielu serwerach slave, które działają jako dodatkowe źródła do odczytu danych. Taki model jest szczególnie przydatny w systemach o dużej liczbie zapytań, gdzie obciążenie serwera master może być zbyt wysokie, a konieczność rozdzielania zapytań odczytujących – niezbędna. Dzięki replikacji MySQL zapewnia wysoką dostępność oraz niezawodność, a także umożliwia balansowanie obciążenia.

Dlaczego warto korzystać z MySQL Master?

Korzyści wynikające z zastosowania replikacji master-slave w MySQL są naprawdę imponujące. Oto kilka z nich:

• Wydajność: Replikacja pozwala na rozłożenie zapytań odczytujących na wiele serwerów slave, co znacznie zmniejsza obciążenie serwera master i poprawia wydajność całego systemu.
• Bezpieczeństwo: Tworzenie kopii zapasowych na serwerach slave zmniejsza ryzyko utraty danych. W przypadku awarii serwera master, można łatwo przełączyć na serwer slave jako nowy master.
• Skalowalność: System oparty na replikacji pozwala na łatwe zwiększanie liczby serwerów slave, co pozwala na lepsze zarządzanie rosnącym obciążeniem aplikacji.
• Wysoka dostępność: Dzięki replikacji MySQL, system może zapewniać ciągłość działania, nawet jeśli jeden z serwerów ulegnie awarii. Dodatkowo, w przypadku planowanych przerw serwisowych, można przełączyć serwer slave w tryb master, minimalizując czas przestoju.

Jak skonfigurować MySQL Master?

Przejdźmy teraz do konfiguracji serwera MySQL w trybie master. Cały proces składa się z kilku prostych kroków:

Krok 1: Konfiguracja serwera master

Aby serwer MySQL działał jako master, należy odpowiednio go skonfigurować. Pierwszym krokiem jest edytowanie pliku konfiguracyjnego MySQL – zazwyczaj jest to plik my.cnf lub my.ini, w zależności od systemu operacyjnego. Otwórz ten plik i dodaj lub zmodyfikuj następujące linie:

[mysqld]
server-id = 1
log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db = nazwa_bazy

Oto, co oznaczają te ustawienia:

• server-id: Unikalny identyfikator serwera w sieci replikacji. Każdy serwer musi mieć unikalny ID.
• log-bin: Określa lokalizację pliku dziennika binarnego, który zapisuje wszystkie zmiany w bazie danych.
• binlog-do-db: Określa, która baza danych ma być replikowana. Możesz wskazać kilka baz danych, jeśli chcesz je replikować.

Po dokonaniu tych zmian, zapisz plik konfiguracyjny i zrestartuj serwer MySQL:

sudo systemctl restart mysql

Krok 2: Użytkownik replikacji

W kolejnym kroku należy utworzyć użytkownika, który będzie miał uprawnienia do replikacji. Można to zrobić za pomocą poniższego zapytania:

CREATE USER 'replikacja'@'%' IDENTIFIED BY 'haslo';
GRANT REPLICATION SLAVE ON *.* TO 'replikacja'@'%';
FLUSH PRIVILEGES;

W tym przypadku użytkownik replikacja ma dostęp do wszystkich baz danych i uprawnienia niezbędne do replikacji. Użytkownik ten będzie używany przez serwer slave do łączenia się z serwerem master.

Krok 3: Uzyskanie informacji o masterze

Na serwerze master musimy teraz uzyskać informacje o bieżącej pozycji binarnego dziennika, aby serwery slave wiedziały, od jakiego punktu zaczynać replikację. Możemy to zrobić za pomocą następującego zapytania:

SHOW MASTER STATUS;

Otrzymamy coś takiego:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 12345678 | database1    |                  |
+------------------+----------+--------------+------------------+

Wartości File i Position są kluczowe, ponieważ wskazują, od jakiego punktu replikacja powinna zostać rozpoczęta na serwerze slave.

Krok 4: Konfiguracja serwera slave

Teraz przechodzimy do konfiguracji serwera slave. Na początku musimy edytować plik konfiguracyjny na serwerze slave i ustawić identyfikator serwera oraz wskazać, że będzie to serwer slave:

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log-bin = /var/log/mysql/mysql-bin.log
read-only = 1

Po zapisaniu zmian, musimy zrestartować serwer slave:

sudo systemctl restart mysql

Krok 5: Połączenie slave z masterem

Na końcu, łączymy serwer slave z masterem za pomocą poniższego zapytania:

CHANGE MASTER TO
    MASTER_HOST='adres_ip_mastera',
    MASTER_USER='replikacja',
    MASTER_PASSWORD='haslo',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=12345678;

Wartości MASTER_LOG_FILE i MASTER_LOG_POS muszą odpowiadać tym, które otrzymaliśmy w poprzednim kroku (z zapytania SHOW MASTER STATUS).

Na koniec uruchamiamy replikację na serwerze slave:

START SLAVE;

Sprawdzanie statusu replikacji

Aby upewnić się, że replikacja działa poprawnie, na serwerze slave wykonujemy zapytanie:

SHOW SLAVE STATUSG

Wynik powinien zawierać informacje o statusie replikacji. Jeśli wszystko jest skonfigurowane poprawnie, w polu Slave_IO_Running oraz Slave_SQL_Running powinny być wartości "Yes".