Z replikacją serwerów MySQL zapoznałem się stosunkowo niedawno i przeprowadzając różne eksperymenty z konfiguracją spisałem co u mnie się sprawdziło. Kiedy zebrałem już całkiem sporo materiału, zrodził się pomysł napisania tego artykułu. Próbowałem zebrać wskazówki i rozwiązania najbardziej podstawowych problemów, jakie napotkałem. Po drodze podam linki do dokumentacji i innych źródeł. Nie mogę udawać, że opisuję to w pełni, ale mam nadzieję, że artykuł będzie przydatny.

Krótkie wprowadzenie

Replikacja (z języka łacińskiego replika – powtarzam) to replikacja zmian danych z głównego serwera bazy danych na jeden lub więcej serwerów zależnych. Zadzwonimy do głównego serwera gospodarz i zależne - repliki.
Zmiany danych zachodzące na masterze powtarzają się na replikach (ale nie odwrotnie). Dlatego zapytania o zmianę danych (INSERT, UPDATE, DELETE itp.) są wykonywane tylko na masterze, natomiast zapytania o odczyt danych (innymi słowy SELECT) mogą być wykonywane zarówno na replikach, jak i na masterze. Proces replikacji na jednej z replik nie wpływa na działanie pozostałych replik i praktycznie nie wpływa na pracę repliki głównej.
Replikacja odbywa się przy użyciu logów binarnych przechowywanych na urządzeniu głównym. Przechowują wszystkie zapytania, które prowadzą (lub potencjalnie prowadzą) do zmian w bazie danych (zapytania nie są zapisywane jawnie, więc jeśli chcesz je przejrzeć, będziesz musiał skorzystać z narzędzia mysqlbinlog). Logi binarne są przesyłane do replik (binlog pobrany z urządzenia głównego nazywany jest „binlogiem przekaźnikowym”), a zapisane zapytania są wykonywane począwszy od określonej pozycji. Ważne jest, aby zrozumieć, że podczas replikacji nie są przesyłane same zmienione dane, ale jedynie żądania, które powodują zmiany.
Dzięki replikacji zawartość bazy danych jest powielana na kilku serwerach. Dlaczego konieczne jest uciekanie się do powielania? Istnieje kilka powodów:

wydajność i skalowalność. Jeden serwer może nie być w stanie obsłużyć obciążenia spowodowanego jednoczesnymi operacjami odczytu i zapisu w bazie danych. Korzyści z tworzenia replik będą tym większe, im więcej odczytów na zapis będziesz mieć w swoim systemie.
tolerancja błędów. W przypadku awarii repliki wszystkie żądania odczytu można bezpiecznie przesłać do repliki głównej. W przypadku awarii mastera żądania zapisu mogą zostać przekazane do repliki (po przywróceniu master może przejąć rolę repliki).
kopia zapasowa danych. Replikę można „spowolnić” na chwilę, aby wykonać mysqldump, ale replika główna nie może.
odroczone obliczenia. Ciężkie i powolne zapytania SQL można wykonywać na osobnej replice bez obawy o zakłócenia normalne działanie cały system.

Poza tym jest jeszcze kilku innych ciekawe możliwości. Ponieważ do replik nie są przesyłane same dane, ale zapytania powodujące ich zmianę, możemy zastosować różne struktury tabel na serwerze głównym i replikach. Różnić się może w szczególności rodzaj tabeli (silnik) lub zestaw indeksów. Przykładowo, aby przeprowadzić wyszukiwanie pełnotekstowe, możemy zastosować na replice typ tabeli MyISAM, mimo że master będzie korzystał z InnoDB.

Konfigurowanie replikacji

Załóżmy, że mamy działającą bazę danych Dane MySQL'a, już wypełnione danymi i uwzględnione w pracy. Z jednego z powodów opisanych powyżej umożliwimy replikację naszego serwera. Nasze wstępne dane:

Główny adres IP to 192.168.1.101, repliki to 192.168.1.102.
Zainstalowany i skonfigurowany MySQL
musisz skonfigurować replikację bazy danych testdb
możemy na chwilę zatrzymać kreatora
oczywiście mamy root na obu komputerach

Ustawienia kreatora

Pamiętaj o wskazaniu unikalnego ID serwera, ścieżki do logów binarnych oraz nazwy bazy danych do replikacji w sekcji:
identyfikator serwera = 1
log-bin = /var/lib/mysql/mysql-bin
replikuj-do-db = testdb
Upewnij się, że masz wystarczająco dużo miejsca na dysku dla dzienników binarnych.

Dodajmy użytkownika replikacji, w ramach którego będzie wykonywana replikacja. Przywilej „podrzędny replikacja” będzie wystarczający:
mysql@master> PRZYZNAJ replikację slave na "testdb".* TO "replication"@"192.168.1.102" IDENTYFIKOWANY PRZEZ "hasło";

Uruchom ponownie MySQL, aby zmiany w konfiguracji zaczęły obowiązywać:
root@master# usługa mysqld restart

Jeśli wszystko poszło dobrze, polecenie „pokaż status główny” powinno wyświetlić coś takiego:
mysql@master>POKAŻ STATUS GŁÓWNY\G
Plik: mysql-bin.000003
Pozycja: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Wartość pozycji powinna rosnąć w miarę wprowadzania zmian w bazie danych na urządzeniu głównym.

Ustawienia repliki

Podajmy identyfikator serwera, nazwę bazy danych do replikacji i ścieżkę do binlogów przekaźnika w sekcji konfiguracji, a następnie zrestartujmy MySQL:
identyfikator serwera = 2
przekaźnik-log = /var/lib/mysql/mysql-relay-bin
Relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replikuj-do-db = testdb

Uruchomienie usługi root@replica# mysqld

Przesyłanie danych

Tutaj będziemy musieli zablokować bazę danych do zapisu. W tym celu możesz albo zatrzymać aplikacje, albo użyć flagi read_only na urządzeniu głównym (uwaga: ta flaga nie ma wpływu na użytkowników z uprawnieniem SUPER). Jeśli mamy tabele MyISAM, „opróżnijmy” także tabele:
mysql@master> OPUSZAJ TABELE Z BLOKADĄ ODCZYTU;
mysql@master> USTAW GLOBALNY tylko do odczytu = WŁ.;

Zobaczmy stan mastera komendą „show master status” i zapamiętajmy wartości File i Position (po udanym zablokowaniu mastera nie powinny się one zmieniać):
Plik: mysql-bin.000003
Pozycja: 98

Zrzucamy bazę danych, a po zakończeniu operacji usuwamy blokadę mastera:
mysql@master> USTAW GLOBALNY tylko do odczytu = WYŁ;

Przenosimy zrzut do repliki i przywracamy z niej dane.
Na koniec rozpoczynamy replikację komendami „zmień master na” i „uruchom niewolnika” i sprawdzamy, czy wszystko poszło dobrze:
mysql@replica> ZMIEŃ MASTER NA MASTER_HOST = "192.168.1.101", MASTER_USER = "replikacja", MASTER_PASSWORD = "hasło", MASTER_LOG_FILE = "mysql-bin.000003", MASTER_LOG_POS = 98;
mysql@replica> uruchom urządzenie slave;
Pobieramy wartości MASTER_LOG_FILE i MASTER_LOG_POS od mastera.

Zobaczmy jak przebiega replikacja za pomocą polecenia „show slave status”:
mysql@replica> POKAŻ STATUS PODRZĘDU\G
Slave_IO_State: Oczekiwanie na wysłanie zdarzenia przez urządzenie master
Główny_Host: 192.168.1.101
Master_User: replikacja
Port_główny: 3306
Ponów_ponowną próbę: 60
Główny_plik_dziennika: mysql-bin.000003
Read_Master_Log_Pos: 98
Relay_Log_File: mysql-relay-bin.001152
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Tak
Slave_SQL_Running: Tak
Replicate_Do_DB: testdb, testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Ostatni_błąd:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Do_Warunku: Brak
Do_pliku_dziennika:
Do_Log_Pos: 0
Master_SSL_Allowed: Nie
Główny_SSL_CA_File:
Master_SSL_CA_Path:
Certyfikat Master_SSL_Cert:
Master_SSL_Cipher:
Klucz główny_SSL:
Sekundy_za_mistrzem: 5

Teraz podkreśliłem najciekawsze wartości. Jeżeli replikacja rozpocznie się pomyślnie, ich wartości powinny być w przybliżeniu takie same jak na aukcji (patrz opis komendy „show slave status” w dokumentacji). Wartość Seconds_Behind_Master może być dowolną liczbą całkowitą.
Jeśli replikacja przebiega normalnie, replika podąży za wzorcem (zwiększy się numer dziennika w Master_Log_File i pozycja Exec_Master_Log_Pos). W idealnym przypadku opóźnienie repliki od wzorca (Seconds_Behind_Master) powinno być równe zeru. Jeśli nie maleje lub nie rośnie, to możliwe, że obciążenie repliki jest zbyt duże – po prostu nie ma czasu na powtarzanie zmian zachodzących na wzorcu.
Jeśli Slave_IO_State jest pusty, a Seconds_Behind_Master ma wartość NULL, replikacja nie została uruchomiona. Zobacz dziennik MySQL, aby znaleźć przyczynę, wyeliminować ją i ponownie uruchomić replikację:
mysql@replica> uruchom urządzenie slave;

Dzięki tym prostym krokom otrzymamy replikę, której dane są identyczne z danymi na urządzeniu głównym.
Nawiasem mówiąc, moment zablokowania urządzenia głównego jest momentem utworzenia zrzutu. Jeśli tworzenie zajmuje niedopuszczalnie dużo czasu, możesz spróbować tego:

zablokuj zapis do mastera za pomocą flagi read_only, zapamiętaj pozycję i zatrzymaj MySQL.
następnie skopiuj pliki bazy danych do repliki i włącz master.
rozpocznij replikację w zwykły sposób.

Istnieje kilka sposobów na utworzenie repliki bez zatrzymywania wzorca, ale nie zawsze one działają.

Dodawanie replik

Załóżmy, że mamy już działającego wzorca i replikę i musimy dodać do nich jeszcze jednego. Jest to nawet łatwiejsze niż dodanie pierwszej repliki do repliki głównej. A o wiele ładniejsze jest to, że nie trzeba w tym celu powstrzymywać mistrza.
Najpierw skonfigurujmy MySQL na drugiej replice i upewnijmy się, że wprowadziliśmy niezbędne parametry do konfiguracji:
identyfikator serwera = 3
replikuj-do-db = testdb

Zatrzymajmy teraz replikację na pierwszej replice:
mysql@replica-1> zatrzymaj urządzenie slave;

Replika będzie nadal działać normalnie, ale dane na niej nie będą już aktualne. Przyjrzyjmy się statusowi i zapamiętajmy pozycję główną, jaką osiągnęła replika przed zatrzymaniem replikacji:
mysql@replica-1> POKAŻ STATUS PODRZĘDU\G

Wartościami, których potrzebujemy, będą Master_Log_File i Exec_Master_Log_Pos:
Główny_plik_dziennika: mysql-bin.000004
Exec_Master_Log_Pos: 155

Utwórzmy zrzut bazy danych i kontynuujmy replikację na pierwszej replice:
mysql@replica-1> URUCHOM SLAVE;

Przywróćmy dane ze zrzutu na drugiej replice. Następnie włącz replikację:
mysql@replica-2> ZMIEŃ MASTER NA MASTER_HOST = "192.168.1.101", MASTER_USER = "replikacja", MASTER_PASSWORD = "hasło", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155;
mysql@replica-2> URUCHOM SLAVE;

Wartości MASTER_LOG_FILE i MASTER_LOG_POS to odpowiednio wartości Master_Log_File i Exec_Master_Log_Pos, pochodzące z wyniku polecenia „show slave status” na pierwszej replice.
Replikacja musi rozpocząć się od miejsca, w którym została zatrzymana pierwsza replika (i odpowiednio utworzony zostaje zrzut). W ten sposób będziemy mieli dwie repliki z identycznymi danymi.

Łączenie replik

Czasami ma miejsce następująca sytuacja: na masterze znajdują się dwie bazy danych, jedna z nich jest replikowana na jednej replice, a druga na drugiej. Jak skonfigurować replikację dwóch baz danych na obu replikach bez zrzucania ich na bazę główną lub jej wyłączania? Po prostu za pomocą polecenia „uruchom niewolnika do”.
Mamy więc mastera z bazami danych testdb1 i testdb2, które są replikowane odpowiednio w replikach replika-1 i replika-2. Skonfigurujmy replikację obu baz danych do repliki-1 bez zatrzymywania mastera.
Zatrzymaj replikację na replice-2 za pomocą komendy i zapamiętaj pozycję mastera:
mysql@replica-2> ZATRZYMAJ PODRZĘDNY;
mysql@replica-2> POKAŻ STATUS PODRZĘDU\G
Główny_plik_dziennika: mysql-bin.000015
Exec_Master_Log_Pos: 231

Utwórzmy zrzut bazy danych testdb2 i wznówmy replikację (to kończy manipulację repliką-2). Przywrócimy zrzut do repliki-1.

Sytuacja w przypadku repliki 1 jest następująca: baza danych testdb1 znajduje się na jednej pozycji głównej i kontynuuje replikację, baza danych testdb2 została odtworzona ze zrzutu z innej pozycji. Zsynchronizujmy je.

Zatrzymajmy replikację i zapamiętajmy pozycję mistrza:
mysql@replica-1> ZATRZYMAJ PODRZĘDNY;
mysql@replica-1> POKAŻ STATUS PODRZĘDU\G
Exec_Master_Log_Pos: 501

Upewnijmy się, że w konfiguracji repliki-1 nazwa drugiej bazy danych jest podana w sekcji:
replikuj-do-db = testdb2

Zrestartujmy MySQL, aby zmiany w konfiguracji zaczęły obowiązywać. Swoją drogą moglibyśmy po prostu zrestartować MySQL bez zatrzymywania replikacji - z logu dowiemy się w którym miejscu w masterze replikacja się zatrzymała.

Teraz wykonajmy replikację od pozycji, w której replika-2 została wstrzymana, do pozycji, w której właśnie wstrzymaliśmy replikację:
mysql@replica-1> ZMIEŃ MASTER NA MASTER_HOST = "192.168.1.101", MASTER_USER = "replikacja", MASTER_PASSWORD = "hasło", MASTER_LOG_FILE = "mysql-bin.000015", MASTER_LOG_POS = 231;
mysql@replica-1> uruchom urządzenie slave do MASTER_LOG_FILE = "mysql-bin.000016 ", MASTER_LOG_POS = 501;

Replikacja zakończy się w momencie, gdy replika osiągnie określoną pozycję w sekcji Until, po czym obie nasze bazy danych będą odpowiadać tej samej pozycji wzorcowej (w której zatrzymaliśmy replikację na replice-1). Upewnijmy się co do tego:
mysql@replica-1> POKAŻ STATUS PODRZĘDU\G
mysql@replica-1> URUCHOM SLAVE;
Główny_plik_dziennika: mysql-bin.000016
Exec_Master_Log_Pos: 501

Dodajmy nazwy obu baz danych do konfiguracji repliki-1 w sekcji:
replikuj-do-db = testdb1
replikuj-do-db = testdb2

Ważne: każda baza danych musi być wymieniona w osobnej linii.
Uruchom ponownie MySQL i kontynuuj replikację:
mysql@replica-1> ZMIEŃ MASTER NA MASTER_HOST = "192.168.1.101", MASTER_USER = "replikacja", MASTER_PASSWORD = "hasło", MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;
Gdy replika-1 dogoni mistrza, zawartość jej bazy danych będzie identyczna. Możesz scalić bazę danych z repliką 2 w podobny sposób lub wykonując pełny zrzut repliki 1.

Mistrz zamku i replika

Może zaistnieć konieczność przełączenia repliki w tryb master np. w przypadku awarii mastera lub podczas wykonywania m.in prace techniczne. Aby taka zamiana była możliwa należy skonfigurować replikę jak master, lub ją wykonać pasywny mistrz.

Włączmy logowanie binarne (oprócz logów binarnych przekazujących) w konfiguracji w sekcji:
log-bin = /var/lib/mysql/mysql-bin

I dodaj użytkownika do replikacji:
mysql@master> PRZYZNAJ replikację slave na 'testdb'.* DO 'replikacji'@'192.168.1.101′ IDENTYFIKOWANY PRZEZ „hasło”;

Master pasywny realizuje replikację jak zwykła replika, ale dodatkowo tworzy logi binarne – czyli możemy od niego rozpocząć replikację. Sprawdźmy to za pomocą polecenia „show master status”:
mysql@replica> POKAŻ STATUS GŁÓWNY\G
Plik: mysql-bin.000001
Pozycja: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Teraz, aby przełączyć mastera pasywnego w tryb aktywny, należy zatrzymać na nim replikację i włączyć replikację na poprzednim masterze aktywnym. Aby mieć pewność, że dane nie zostaną utracone w momencie przełączania, aktywny mistrz musi być zablokowany przed zapisem.
mysql@master> Opróżnij tabele z blokadą odczytu
mysql@master> USTAW GLOBALNY tylko do odczytu = WŁ.;
mysql@replica> ZATRZYMAJ SLAVE;
mysql@replica> POKAŻ STATUS GŁÓWNY;
Plik: mysql-bin.000001
Pozycja: 61
mysql@master> ZMIEŃ MASTER NA MASTER_HOST = "192.168.1.102", MASTER_USER = "replikacja", MASTER_PASSWORD = "hasło", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 61;
mysql@master> uruchom urządzenie slave;
To wszystko, więc zmieniliśmy aktywnego mistrza. Można usunąć z były mistrz bloking.

Wniosek

Dowiedzieliśmy się trochę o konfigurowaniu replikacji w MySQL i wykonywaniu kilku podstawowych operacji. Niestety, następujące ważne pytania pozostają poza zakresem tego artykułu:

eliminacja pojedynczych punktów awarii (SPF, Single Points of Failure). Podczas używania pojedynczy serwer MySQL, jego awaria doprowadziła do awarii całego systemu. W przypadku korzystania z wielu serwerów awaria któregokolwiek z nich spowoduje awarię systemu, chyba że specjalnie się tym zajmiemy. Musimy przewidzieć możliwość poradzenia sobie z awarią wzorca i repliki. Jednym z istniejących narzędzi jest MMM, jednak wymaga on modyfikacji za pomocą pliku.
równoważenie obciążenia. W przypadku korzystania z wielu replik chcielibyśmy zastosować przejrzysty mechanizm równoważenia, zwłaszcza jeśli wydajność replik jest nierówna. Można używać pod Linuksem standardowe rozwiązanie—LVS.
zmiana logiki aplikacji. W idealnej sytuacji żądania odczytu danych powinny być wysyłane do replik, a żądania zmiany danych do mastera. Jednak ze względu na możliwe opóźnienia replik taki schemat jest często nieskuteczny i konieczne jest zidentyfikowanie takich żądań odczytu, które nadal wymagają wykonania na urządzeniu głównym.

Mam nadzieję poruszyć te kwestie w przyszłych artykułach.
Dziękuję za uwagę!

Replikacja to mechanizm synchronizacji zawartości wielu kopii obiektu. Proces ten polega na kopiowaniu danych z jednego źródła do wielu innych i odwrotnie.

Oznaczenia:

master - główny serwer, którego dane wymagają zduplikowania;
replika - naprawiony serwer przechowujący kopię danych podstawowych

Aby skonfigurować replikację w MySQL należy postępować zgodnie z sekwencją czynności opisaną poniżej, jednak nie jest to dogmat i parametry mogą się zmieniać w zależności od okoliczności.

Na głównym serwerze edytuj plik my.cnf i dodaj następujące wiersze do sekcji mysqld:

Identyfikator serwera = log-bin = mysql-bin log-bin-index = mysql-bin.index log-error = mysql-bin.err przekaźnik-log = przekaźnik-bin przekaźnik-log-info-plik = przekaźnik-bin. informacje o przekaźniku-log-index = przekaźnik-bin.index wygaśnięcie_logs_days=7 binlog-do-db =

- unikalny identyfikator Serwer MySQL, liczba z zakresu 2 (0-31)
- nazwa bazy danych, o której informacja zostanie zapisana w logu binarnym, jeśli jest kilka baz danych, to każda wymaga osobnej linii z parametrem binlog_do_db

Na urządzeniu podrzędnym edytuj plik my.cnf i dodaj następujące wiersze do sekcji mysqld:

Identyfikator serwera = główny-host = główny użytkownik główny = hasło główne replikacji = hasło port-główny = 3306 przekaźnik-log = pojemnik przekaźnikowy przekaźnik-log-info-plik = przekaźnik-log.info przekaźnik-log-indeks = przekaźnik-log.index replikacja-do-db =

Na serwerze głównym dodaj użytkownika replikacji z uprawnieniami do replikacji danych:

UDZIEL REPLIKACJI SLAVE ON *.* DO „replikacji”@„repliki” IDENTYFIKOWANEJ PRZEZ „hasło”

Zablokujmy replikowanym bazom danych na głównym serwerze możliwość zmiany danych programowo lub przy użyciu funkcjonalności MySQL:

Mysql@master> OPUSZAJ TABELE Z BLOKADĄ ODCZYTU; mysql@master> USTAW GLOBALNY tylko do odczytu = WŁ.;

Aby odblokować użyj polecenia:

Mysql@master> USTAW GLOBALNY tylko do odczytu = WYŁ;

Zróbmy kopie zapasowe wszystkich baz danych na serwerze głównym (lub tych, których potrzebujemy):

Root@master# tar -czf mysqldir.tar.gz /var/lib/mysql/

lub używając narzędzia mysqldump:

Root@master# mysqldump -u root -p --lock-all-tables > dbdump.sql

Zatrzymajmy oba serwery (w w niektórych przypadkach możesz się bez tego obejść):

Root@master# mysqlamdin -u root -p zamknięcie root@replica# mysqlamdin -u root -p zamknięcie

Przywróćmy zreplikowane bazy danych na serwerze podrzędnym, kopiując katalog. Przed rozpoczęciem replikacji bazy danych muszą być identyczne:

Root@replica# cd /var/lib/mysql root@replica# tar -xzf mysqldir.tar.gz

lub mysql, nie było potrzeby zatrzymywania mysql na serwerze podrzędnym:

Katalog główny@replika# mysql -u root -p< dbdump.sql

Uruchommy mysql na serwerze głównym (a następnie na serwerze podrzędnym, jeśli to konieczne):

Root@master# /etc/init.d/mysql start root@replica# /etc/init.d/mysql start

Sprawdźmy działanie serwerów master i slave:

Mysql@replica> uruchom urządzenie slave; mysql@replica> POKAŻ STATUS SLAVE\G mysql@master> POKAŻ STATUS MASTER\G

Na serwerze slave sprawdź logi w pliku master.info, powinien on zawierać żądania zmiany danych w bazie danych. Zatem ten plik binarny należy najpierw przekonwertować na format tekstowy:

Root@replica# mysqlbinlog master.info > master_info.sql

Jeśli wystąpią błędy, możesz użyć poleceń:

Mysql@replica> zatrzymaj urządzenie slave; mysql@replica> ZRESETUJ PODRZĘDNY; mysql@master> ZRESETUJ MASTER;

i powtórz wszystkie kroki zaczynając od zablokowania baz danych.

Aby dodać serwery replikacji na gorąco, możesz użyć następującej składni:

Mysql@replica> POKAŻ STATUS SLAVE\G mysql@master> POKAŻ STATUS MASTER\G mysql@replica-2> ZMIEŃ MASTER NA MASTER_HOST = "master", MASTER_USER ="replikacja", MASTER_PASSWORD = "hasło", MASTER_LOG_FILE ="mysql- bin.000004 ", MASTER_LOG_POS = 155; mysql@replica-2> URUCHOM SLAVE;

Informacje ze statusów pokażą pozycję i nazwę bieżący plik dziennik.

W przypadku replikacji asynchronicznej aktualizacja z jednej repliki jest propagowana do innych po pewnym czasie, a nie w tej samej transakcji. Zatem replikacja asynchroniczna wprowadza opóźnienie, czyli czas oczekiwania, podczas którego poszczególne repliki mogą nie być faktycznie identyczne. Ale ten typ replikacji ma również pozytywne strony: główny serwer nie musi się martwić o synchronizację danych, możesz zablokować bazę danych (na przykład w celu utworzenia kopia zapasowa) na maszynie podrzędnej, nie stanowi to problemu dla użytkowników.

Lista wykorzystanych źródeł

Habrahabr.ru - Podstawy replikacji w MySQL (http://habrahabr.ru/blogs/mysql/56702/)
Wikipedia (http://ru.wikipedia.org/wiki/Replication_(computing_technology))

Korzystając z jakichkolwiek materiałów z serwisu w całości lub w części, należy wyraźnie wskazać link jako źródło.

Termin replikacja odnosi się do mechanizmu synchronizacji wielu kopii danych, co zwiększa bezpieczeństwo informacji, odporność na awarie i wydajność systemu. Uderzającym przykładem jest replikacja bazy danych pomiędzy dwoma serwerami.

Replikacja MySQL typu Master-Slave

W terminologii master-slave, master jest głównym serwerem z bazą danych; zapisuje dane do bazy danych, ale odczyt jest rozdzielany pomiędzy master i slave w zależności od obciążenia systemu, co zwiększa odporność na awarie i wydajność. Dodatkowo dzięki takiemu podejściu kopia bazy danych jest zawsze pod ręką i można ją odtworzyć w przypadku awarii jednego z serwerów.

W jakich sytuacjach może być potrzebny serwer podrzędny? Przykładowo, gdy do bazy danych przychodzi do zapisania duża tablica danych, a serwer główny po prostu nie ma czasu na ich odczytanie i klient musi czekać na koniec zapisu, czego można uniknąć dzięki serwerowi podrzędnemu.

Możliwe są sytuacje, w których nastąpi awaria serwera master; w tym przypadku serwer slave przejmuje wszystkie funkcje mastera i działa samodzielnie do czasu jego przywrócenia. Klient najprawdopodobniej niczego nie zauważy, a na pewno nie będzie czekał godzinę, dwie, trzy, aż technik go naprawi.

Konfiguracja replikacji nie jest wcale trudna, ponieważ mechanizm jest wbudowany w MySQL od samego początku.

Konfiguracja na serwerze głównym

Zacznijmy od edycji pliku konfiguracyjnego my.cnf, który najczęściej znajduje się w /etc/mysql/my.cnf. Musisz znaleźć i odkomentować (usunąć #) lub napisać takie linie.

Adres powiązania = 0.0.0.0 identyfikator serwera = 1 log_bin = /var/log/mysql/mysql-bin.log

Ważny! Jeżeli adres powiązania został już zarejestrowany, należy go zmienić, w przeciwnym razie nawiązanie połączenia między serwerami nie będzie możliwe.

Zaraz po tym zrestartujemy bazę danych na serwerze.

/etc/init.d/mysql uruchom ponownie

Teraz musimy utworzyć użytkownika z uprawnieniami do replikacji naszej bazy danych; można to zrobić z poziomu roota w konsoli MySQL za pomocą polecenia

PRZYZNAJ REPLIKACJĘ SLAVE NA *.* „slave_user”@”%” IDENTYFIKOWANĄ PRZEZ „slave_password”; PRZYWILEJE FLUSH;

Gdzie zamiast „slave_user” i „slave_password” musisz wpisać login i hasło dla slave.

Spójrzmy teraz na dane podstawowe

POKAŻ STATUS GŁÓWNY;

Wartości kolumn Plik I Pozycja musisz pamiętać, zostaną one użyte podczas konfigurowania urządzenia podrzędnego i do tego teraz przechodzimy.

Konfiguracja na serwerze Slave

Pierwszym krokiem jest utworzenie bazy danych o tej samej nazwie, co ta, którą będziemy replikować. Jest to ważny krok i nie należy go zaniedbywać. Następnie przejdź do znanego nam już pliku konfiguracyjnego mój.cnf i napisz ustawienia.

Identyfikator serwera = 2 przekaźnik-log = /var/log/mysql/mysql-relay-bin.log bin-log = /var/log/mysql/mysql-bin.log

Ważny! W bin-log zapisana jest ścieżka do bin-log na serwerze Mester . Identyfikator serwera musi różnić się od identyfikatora głównego, wygodnie jest ustawić go na jeszcze 1.

ZMIEŃ MASTER NA MASTER_HOST="1.1.1.1", MASTER_USER="slave_user", MASTER_PASSWORD="slave_password", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 107; URUCHOM PODRZĘDNY;

Gdzie host to adres IP mastera, login i hasło odpowiadają tym, które utworzyliśmy na masterze, master_log_file i master_log_pos są wypełnione informacjami z ostatni element konfiguracji serwera głównego .

Od tego momentu wszystkie zmiany w bazie danych zostaną przeniesione z urządzenia master na urządzenie slave.

Sprawdzanie statusu replikacji

Oprócz polecenia SHOW MASTER STATUS;

Podobny istnieje dla slave'a SHOW SLAVE STATUS\G, który wyświetli tabelę z informacjami. Głównym sygnałem, że serwery się połączyły i działają poprawnie, jest obecność takich linii Replikacja

- technika stosowana w architekturze systemów pracujących pod obciążeniem, której efektem jest rozłożenie obciążenia podczas pracy z jedną bazą danych na kilka serwerów. Częściej stosowana jest replikacja MySQL MASTER SLAVE, ale stosowany jest także drugi typ replikacji – Master-Master.

Co to jest replikacja MySQL MASTER SLAVE i do czego służy? Replikacja polega na duplikowaniu danych na podrzędny serwer MySQL. Taka duplikacja jest wykonywana głównie w celu zapewnienia niezawodności. W przypadku awarii serwera Master jego funkcje zostaną przełączone na serwer Slave.

Replikację można również przeprowadzić w celu poprawy wydajności systemu, ale wydajność jest tutaj prawie zawsze sprawą drugorzędną.
Gdy aplikacja współpracuje z bazą danych, najczęstszymi operacjami są WYBIERAĆ- żądania odczytu danych, modyfikacji danych - żądania USUWAĆ, WSTAWIĆ, AKTUALIZACJA, ZMIENIAĆ Statystycznie zdarza się to znacznie rzadziej.

Aby zapobiec utracie danych w przypadku awarii jednego z serwerów, operacje zmiany informacji w tabelach są zawsze przetwarzane przez serwer Master. Zmiany są następnie replikowane do urządzenia Slave. Odczytu można dokonać z serwera pełniącego rolę Slave.
Dzięki temu można uzyskać wzrost wydajności i niezawodności.

Rozwiązanie jest popularne, ale nie zawsze sprawdza się, gdyż podczas replikacji mogą wystąpić opóźnienia - jeśli tak się stanie, trzeba będzie odczytać informację również z serwera Master.

Kierowanie żądań określonego typu do konkretnego serwera bazy danych jest w każdym przypadku realizowane na poziomie aplikacji.

Jeśli dokonasz podziału WYBIERZ zapytania i wszystkich innych osób na poziomie programu, wysyłając je do wymagany serwer Jeżeli jeden z nich ulegnie awarii, aplikacja obsługiwana przez infrastrukturę przestanie działać. Aby to zadziałało, musisz zapewnić bardziej złożony schemat i zarezerwować każdy z serwerów.

Replikacja ma na celu odporność na błędy, a nie skalowanie.

Replikacja MySQL MASTER SLAVE - konfiguracja na Debianie

Będziemy korzystać z dwóch serwerów o adresach:

Serwer główny 192.168.0.1
Serwer podrzędny 192.168.0.2

Do demonstracji wykorzystywane są VDS podłączone do sieci lokalnej.
Aby zawsze wiedzieć na jakim serwerze wykonujemy to czy tamto polecenie, dokonamy edycji plików /etc/hosts na obu serwerach

192.168.0.1 główny

192.168.0.2 podrzędny

Zamieńmy istniejące wartości w /etc/hostname odpowiednio na master i slave, aby zmiany odniosły skutek i zrestartuj serwer.

1. Dokonujemy ustawień na serwerze głównym.

root@master:/#

Edycja głównego plik konfiguracyjny serwer bazy danych

mcedit /etc/mysql/my.cnf

Wybierz identyfikator serwera - możesz podać dowolną liczbę, domyślnie jest to 1 - po prostu odkomentuj linię

identyfikator serwera = 1

Ustaw ścieżkę do dziennika binarnego - również określona domyślnie, odkomentuj ją

Ustaw nazwę bazy danych, którą będziemy replikować na inny serwer

binlog_do_db = db1

Uruchom ponownie Mysql, aby plik konfiguracyjny został ponownie odczytany i zmiany zaczęły obowiązywać:

/etc/init.d/mysql uruchom ponownie

2. Ustaw niezbędne uprawnienia użytkownika

Przejdź do konsoli serwera bazy danych:

Nadajemy użytkownikowi na serwerze slave niezbędne uprawnienia:

PRZYZNAJ REPLIKACJĘ PODRZĘDNĄ NA *.* „slave_user”@”%” IDENTYFIKOWANĄ PRZEZ „123”;

Blokowanie wszystkich tabel w bazie danych

STOLIKI PODTYNKOWE Z BLOKADĄ ODCZYTU;

Sprawdzanie statusu serwera Master:

3. Utwórz zrzut bazy danych na serwerze

Utwórz zrzut bazy danych:

mysqldump -u root -p db1 > db1.sql

Odblokuj tabele w konsoli mysql:

4. Prześlij zrzut bazy danych na serwer Slave

scp db1.sql [e-mail chroniony]:/dom

Dalsze działania wykonujemy na serwerze Slave

root@slave:/#

5. Tworzenie bazy danych

Ładowanie zrzutu:

mysql -u root -p db1< db1.sql

6. Wprowadź zmiany w pliku my.cnf

mcedit /etc/mysql/my.cnf

Identyfikator nadajemy zwiększając wartość ustawioną na serwerze Master

identyfikator serwera = 2

Ustaw ścieżkę do dziennika przekaźnika

przekaźnik-log = /var/log/mysql/mysql-relay-bin.log

oraz ścieżkę do dziennika bin na serwerze głównym

log_bin = /var/log/mysql/mysql-bin.log

Określ bazę

binlog_do_db = db1

Ponowne uruchomienie usługi

/etc/init.d/mysql uruchom ponownie

7. Skonfiguruj połączenie z serwerem głównym

ZMIEŃ MASTER NA MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;

Rozpoczynamy replikację na serwerze slave:

Możesz sprawdzić działanie replikacji na Slave za pomocą następującego żądania:

****************************** 1. rząd ******************** *******
Slave_IO_State: Oczekiwanie na wysłanie zdarzenia przez urządzenie master
Główny_Host: 192.168.0.1
Użytkownik_główny: użytkownik_podrzędny
Port_główny: 3306
Ponów_ponowną próbę: 60
Główny_plik_dziennika: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Tak
Slave_SQL_Running: Tak
Replikuj_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Ostatni_błąd:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 555
Do_Warunku: Brak
Do_pliku_dziennika:
Do_Log_Pos: 0
Master_SSL_Allowed: Nie
Główny_SSL_CA_File:
Master_SSL_CA_Path:
Certyfikat Master_SSL_Cert:
Master_SSL_Cipher:
Klucz główny_SSL:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: Nie
Last_IO_Errno: 0
Ostatni_IO_Błąd:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Identyfikator_głównego_serwera: 1
1 rząd w zestawie (0,00 s)

Ponieważ nie wystąpiły żadne błędy, możemy stwierdzić, że replikacja jest skonfigurowana poprawnie.

Jest dobre narzędzie skalowanie, ale główną wadą jest desynchronizacja kopiowania danych i opóźnienia, które mogą być krytyczne.

Można ich całkowicie uniknąć, stosując więcej nowoczesne rozwiązanie. Jest łatwy w konfiguracji, niezawodny i eliminuje potrzebę ręcznego kopiowania zrzutów bazy danych.

Krótkie wprowadzenie

wydajność i skalowalność. Jeden serwer może nie być w stanie obsłużyć obciążenia spowodowanego jednoczesnymi operacjami odczytu i zapisu w bazie danych. Korzyści z tworzenia replik będą tym większe, im więcej odczytów na zapis będziesz mieć w swoim systemie.
tolerancja błędów. W przypadku awarii repliki wszystkie żądania odczytu można bezpiecznie przesłać do repliki głównej. W przypadku awarii mastera żądania zapisu mogą zostać przekazane do repliki (po przywróceniu master może przejąć rolę repliki).
kopia zapasowa danych. Replikę można „spowolnić” na chwilę, aby wykonać mysqldump, ale replika główna nie może.
odroczone obliczenia. Ciężkie i powolne zapytania SQL można wykonywać na osobnej replice bez obawy, że zakłócą normalne działanie całego systemu.

Dodatkowo istnieje kilka innych ciekawych funkcji. Ponieważ do replik nie są przesyłane same dane, ale zapytania powodujące ich zmianę, możemy zastosować różne struktury tabel na serwerze głównym i replikach. Różnić się może w szczególności rodzaj tabeli (silnik) lub zestaw indeksów. Przykładowo, aby przeprowadzić wyszukiwanie pełnotekstowe, możemy zastosować na replice typ tabeli MyISAM, mimo że master będzie korzystał z InnoDB.

Konfigurowanie replikacji

Załóżmy, że mamy działającą bazę danych MySQL, już wypełnioną danymi i włączoną. Z jednego z powodów opisanych powyżej umożliwimy replikację naszego serwera. Nasze wstępne dane:

Główny adres IP to 192.168.1.101, repliki to 192.168.1.102.
Zainstalowany i skonfigurowany MySQL
musisz skonfigurować replikację bazy danych testdb
możemy na chwilę zatrzymać kreatora
oczywiście mamy root na obu komputerach

Ustawienia kreatora

Uruchom ponownie MySQL, aby zmiany w konfiguracji zaczęły obowiązywać:
root@master# usługa mysqld restart

Ustawienia repliki

Uruchomienie usługi root@replica# mysqld

Przesyłanie danych

Zobaczmy stan mastera komendą „show master status” i zapamiętajmy wartości File i Position (po udanym zablokowaniu mastera nie powinny się one zmieniać):
Plik: mysql-bin.000003
Pozycja: 98

Zrzucamy bazę danych, a po zakończeniu operacji usuwamy blokadę mastera:
mysql@master> USTAW GLOBALNY tylko do odczytu = WYŁ;

zablokuj zapis do mastera za pomocą flagi read_only, zapamiętaj pozycję i zatrzymaj MySQL.
następnie skopiuj pliki bazy danych do repliki i włącz master.
rozpocznij replikację w zwykły sposób.

Istnieje kilka sposobów na utworzenie repliki bez zatrzymywania wzorca, ale nie zawsze one działają.

Dodawanie replik

Zatrzymajmy teraz replikację na pierwszej replice:
mysql@replica-1> zatrzymaj urządzenie slave;

Wartościami, których potrzebujemy, będą Master_Log_File i Exec_Master_Log_Pos:
Główny_plik_dziennika: mysql-bin.000004
Exec_Master_Log_Pos: 155

Utwórzmy zrzut bazy danych i kontynuujmy replikację na pierwszej replice:
mysql@replica-1> URUCHOM SLAVE;

Łączenie replik

Utwórzmy zrzut bazy danych testdb2 i wznówmy replikację (to kończy manipulację repliką-2). Przywrócimy zrzut do repliki-1.

Zatrzymajmy replikację i zapamiętajmy pozycję mistrza:
mysql@replica-1> ZATRZYMAJ PODRZĘDNY;
mysql@replica-1> POKAŻ STATUS PODRZĘDU\G
Exec_Master_Log_Pos: 501

Upewnijmy się, że w konfiguracji repliki-1 nazwa drugiej bazy danych jest podana w sekcji:
replikuj-do-db = testdb2

Dodajmy nazwy obu baz danych do konfiguracji repliki-1 w sekcji:
replikuj-do-db = testdb1
replikuj-do-db = testdb2

Mistrz zamku i replika

Może zaistnieć konieczność przełączenia repliki w tryb master np. w przypadku awarii mastera lub w trakcie wykonywania przy niej prac technicznych. Aby taka zamiana była możliwa należy skonfigurować replikę jak master, lub ją wykonać pasywny mistrz.

Włączmy logowanie binarne (oprócz logów binarnych przekazujących) w konfiguracji w sekcji:
log-bin = /var/lib/mysql/mysql-bin

I dodaj użytkownika do replikacji:
mysql@master> PRZYZNAJ replikację slave na 'testdb'.* DO 'replikacji'@'192.168.1.101′ IDENTYFIKOWANY PRZEZ „hasło”;

Wniosek

Dowiedzieliśmy się trochę o konfigurowaniu replikacji w MySQL i wykonywaniu kilku podstawowych operacji. Niestety, następujące ważne pytania pozostają poza zakresem tego artykułu:

eliminacja pojedynczych punktów awarii (SPF, Single Points of Failure). W przypadku wykorzystania pojedynczego serwera MySQL jego awaria doprowadziła do awarii całego systemu. W przypadku korzystania z wielu serwerów awaria któregokolwiek z nich spowoduje awarię systemu, chyba że specjalnie się tym zajmiemy. Musimy przewidzieć możliwość poradzenia sobie z awarią wzorca i repliki. Jednym z istniejących narzędzi jest MMM, jednak wymaga on modyfikacji za pomocą pliku.
równoważenie obciążenia. W przypadku korzystania z wielu replik chcielibyśmy zastosować przejrzysty mechanizm równoważenia, zwłaszcza jeśli wydajność replik jest nierówna. Pod Linuksem można zastosować standardowe rozwiązanie - LVS.
zmiana logiki aplikacji. W idealnej sytuacji żądania odczytu danych powinny być wysyłane do replik, a żądania zmiany danych do mastera. Jednak ze względu na możliwe opóźnienia replik taki schemat jest często nieskuteczny i konieczne jest zidentyfikowanie takich żądań odczytu, które nadal wymagają wykonania na urządzeniu głównym.

Mam nadzieję poruszyć te kwestie w przyszłych artykułach.
Dziękuję za uwagę!

Materiały tematyczne: