Konfigurowanie replikacji MySQL bez zatrzymywania kreatora. Co to jest replikacja w MySQL? Konfigurowanie replikacji za pomocą administratora mysql
Z Linuksowej Wiki
Konfigurowanie replikacji
Serwer główny
- mój.cnf na głównym serwerze:
[mysqld]# Identyfikator serwera. Musi być unikalny na każdym łączu serwerów (zarówno nadrzędnych, jak i podrzędnych). # Jest liczbą z zakresu od 1 do 4294967295 (2 ^32 -1 ) server-id = 1 # Ścieżka do logów binarnych, w których zapisywane są wszystkie zmiany w bazie danych serwera głównego. Powinno być wystarczająco dużo miejsca na te logi log-bin = /var/lib/mysql/mysql-bin # Ile dni przechowywać logi binarne na urządzeniu głównym. W pewnym sensie określa to również, jak bardzo Slave może pozostawać w tyle za Master # wygasa_logs_dni = 10 # Rozmiar pliku binlog (każdy pojedynczy plik) # max_binlog_size = 1024M # Włącz kompresję logów wysyłanych do Slave'a slave_compressed_protocol = 1 # Nazwa baza danych, dla której ma zostać wykonana replikacja. Jeśli potrzebujesz zreplikować kilka baz danych, powtórz opcję z żądaną nazwą bazy danych replikuj-do-db = testdb # Oprócz tej opcji jest więcej opcji „odwrotny wybór”- aby wykluczyć zaznaczenie baz danych #replicate-ignore-db=nazwa_bazy_danych # oraz opcje replikacji poszczególnych tabel (analogicznie - zaznacz jedną/kilkanaście ; wykluczyć jeden / kilka, a także definicję nazw za pomocą symboli wieloznacznych)# Ta opcja jest potrzebna w przypadku, gdy ten serwer główny jest serwerem podrzędnym w stosunku do innego - aby serwer podrzędny tego serwera głównego (podrzędny serwer główny głównego) również otrzymywał aktualizacje # Może być przydatny podczas replikacji serwera nadrzędnego z jednym serwerem podrzędnym # log -slave -aktualizacje
- Dajemy prawa serwerowi podrzędnemu do replikacji z tego. W tym celu w konsoli mysql wydajemy polecenie:
mysql> GRANT replikacji slave ON * .* TO "repluser" @"replhost" IDENTYFIKOWANY PRZEZ "replpass" ;
- repluser- nazwa użytkownika do połączenia. Użytkownik jest tworzony w momencie wykonania polecenia.
- replhost- Adres IP lub domena hosta serwera podrzędnego, który połączy się z tym serwerem głównym i zaimportuje z niego zmiany.
- ponowna przepustka- hasło połączenia
Restartujemy serwer, po czym możesz uruchomić polecenie w konsoli
mysql> POKAŻ STATUS GŁÓWNY;
który pokaże binarny plik dziennika, z którym aktualnie pracuje master, i bieżącą pozycję w dzienniku, a także bazy, które są replikowane.
Serwer podrzędny
- Dodaj niezbędne opcje w pliku config mój.cnf na serwerze podrzędnym:
[mysqld]# Identyfikator serwera dla tego pakietu serwerów — patrz opis powyżej server-id = 2 # Relay logs — logi pobrane z serwera głównego # Określ ścieżkę dla tych logów ; powinno być wystarczająco dużo miejsca do ich przechowywania.#dziennik przekaźnika= /var/lib/mysql/mysql-relay-bin#relay-log-index= /var/lib/mysql/mysql-relay-bin.index# Nazwa bazy danych do replikacji replikate-do-db = testdb # Włącz kompresję logów wysyłanych do Slave'a slave_compressed_protocol = 1
Uruchom ponownie serwer, aby zastosować zmiany
Rozpocznij replikację
Na wzorcu blokujemy tabele do zapisu, aby uzyskać całkowicie poprawny zrzut:
mysql> WYPRÓŻNIJ TABELE Z BLOKADĄ ODCZYTU; mysql> SET GLOBAL tylko do odczytu = WŁ.;
Łączymy zrzut z serwera. W niektórych miejscach zwykle piszą o tym, że konieczne jest sprawdzenie pozycji i nazwy dziennika na urządzeniu głównym - nie jest to konieczne i rozwiązuje je klucz --dane-główne dla mysqldump, który zapisze niezbędne informacje do samego zrzutu:
mysqldump --master-data -hmasterhost -umasteruser -pmasterpass masterdbname > dump.sql
Następnie uruchamiamy kreatora do pracy:
mysql> SET GLOBAL tylko do odczytu = WYŁ.;
(chociaż pojawia się myśl - czy naprawdę konieczne jest blokowanie bazy danych podczas zrzutu? Gdy tylko zrzut z --master-data zacznie się robić, nazwa dziennika i pozycja są do niego wrzucane, a tabele są automatycznie blokowane na czas pisanie - czyli wszystko jest takie samo, tylko w trybie automatycznym)
mysql -hslavehost -uslaveuser -pslavepass nazwa bazy danych podrzędnych< dump.sql
W tym przypadku slavedbname = masterdbname, chociaż jeśli chcesz, możesz zreplikować bazę danych pod inną nazwą.
Podaj adres serwera głównego do urządzenia podrzędnego:
mysql> ZMIEŃ MASTER NA MASTER_HOST = "masterip", MASTER_USER = "repluser", MASTER_PASSWORD = "replpass";
Gdzie mistrzowski- Adres IP lub domena serwera głównego oraz pozostałe opcje to te, które zostały określone powyżej podczas konfigurowania serwera głównego. Nazwa pliku dziennika i pozycja są pobierane ze zrzutu, ale w razie potrzeby można je określić ręcznie za pomocą opcji MASTER_LOG_FILE = "nazwa_logu", MASTER_LOG_POS = pozycja
Po tym poleceniu informacje o masterze są zapisywane w pliku główny.informacje w katalogu bazy danych serwera mysql. W razie potrzeby możesz określić te opcje w konfiguracji serwera podrzędnego:
master-host=masterip master-user=repluser master-password=replpass master-port=3306
Następnie uruchamiamy serwer podrzędny za pomocą konsoli mysql:
mysql> START SLAVE;
Teraz możesz sprawdzić status serwera podrzędnego za pomocą polecenia
mysql> POKAŻ STATUS PODRZĘDNY;
Z ciekawych informacji mogą być pola:
- Slave_IO_State: Oczekiwanie na wysłanie zdarzenia przez mastera, Slave_IO_Running: Tak I Slave_SQL_Running: Tak- wszystko gra :)
- Seconds_Behind_Master- jak daleko niewolnik jest za panem. W normalnym trybie powinno być 0, ale w prawdziwym lagu też może być 0 jeśli na masterze robi się dużo zmian, a kanał między masterem a slavem jest wąski i ten ostatni nie ma czasu na pobranie binlogs od mastera. W tym przypadku "0" jest poprawne, ale tylko dla tego, co udało się pobrać z logów.
I inne aktualne informacje, takie jak brak błędów, aktualna pozycja i nazwa dziennika serwera, dziennika podrzędnego itp.
Różnorodny
Istnieją 2 opcje dla mysqldump, aby zapisać nazwę dziennika i pozycję w pliku zrzutu: --dane-główne I --dump-slave. Drugi nie jest wszędzie:
[e-mail chroniony]:~# mysqldump --help | grep „dump-slave” [e-mail chroniony]:~# mysqldump --version mysqldump Ver 10.13 Distrib 5.1.61, dla portbld-freebsd8.2 (amd64)
Dump-slave[=wartość] Ta opcja jest podobna do opcji --master-data, z tą różnicą, że służy do zrzutu serwera podrzędnego replikacji w celu utworzenia pliku zrzutu, którego można użyć do skonfigurowania innego serwera jako podrzędnego z tym samym serwerem głównym jako zrzucony serwer. Powoduje, że dane wyjściowe zrzutu zawierają instrukcję CHANGE MASTER TO, która wskazuje współrzędne dziennika binarnego (nazwę i pozycję pliku) zrzuconego serwera podrzędnego (zamiast współrzędnych zrzuconego serwera, jak to robi opcja --master- opcja danych). Są to współrzędne serwera głównego, od których serwer podrzędny powinien rozpocząć replikację. Ta opcja została dodana w MySQL 5.5.3.
W związku z tym jedna opcja dotyczy klonowania niewolnika, a druga tworzenia niewolnika. Innymi słowy, dump-slave umożliwia utworzenie (za pomocą slave1) kolejnego slave1 w łańcuchu master-slave1-slave2 (pozycja w dzienniku i pliku dziennika względem dzienników głównych zostanie zapisana w zrzucie), master- data pozwala na utworzenie slave2 - pozycji/logu względem binlogów slave1.
Błędy replikacji
Podczas działania replikacji mogą wystąpić błędy - z dowolnego powodu, na przykład przy ręcznym wprowadzaniu danych na serwerze podrzędnym.
Opcje rozwiązania.
Dzień dobry wszystkim! Dziś w naszym artykule przyjrzymy się przykładom konfiguracji replikacji typu „master-slave”.
Trochę teorii
Dlaczego replikacja jest konieczna? Przede wszystkim jest to siatka bezpieczeństwa na wypadek awarii głównego serwera mysql, wtedy możesz przełączyć się na serwer podrzędny i kontynuować pracę. Po drugie, jest to okazja do zmniejszenia obciążenia głównego serwera Mysql, wykorzystania serwera master tylko do zapisu i wykonywania operacji odczytu na serwerze slave. Jak przebiega replikacja? Serwer nadrzędny zapisuje binlogi, w których wskazuje operacje, które są wykonywane na bazie danych (bazach danych) oraz zapamiętuje przesunięcie w logu od jego początku do aktualnego rekordu (pozycji). Serwer slave łączy się z masterem, porównuje wartości pozycji i odczytuje zmiany w logu zaczynając od własnej wartości pozycji a kończąc na wartości pozycji mastera. Stosuje zmiany (polecenia) do baz danych na serwerze podrzędnym.
Instalacja i konfiguracja Master
Zmień my.cnf na serwerze głównym:
Server-id = 1 - podaj id serwera log_bin = /var/log/mysql/mysql-bin.log - nazwa logu i ścieżka
Małe wyjaśnienie: domyślnie kreator zapisuje binlogi dla wszystkich baz danych, można to zmienić za pomocą „binlog-do-db”. Wartości będą zapisywane do logów podczas korzystania z określonej bazy danych, zmiany w innych bazach danych nie będą rejestrowane. Tutaj możesz również określić ile dni przechowywać logi, jaki jest ich maksymalny rozmiar (parametry expire_logs_days i max_binlog_size). Dodaj użytkownika do MySQL, na którego prawach zostanie przeprowadzona replikacja:
GRANT replikacji slave ON *.* TO server_username@ip_slave IDENTIFIED BY "password";
replikacja slave - uprawnienie umożliwiające użytkownikowi odczytywanie binlogów. ip_slave_server - ip serwera, z którego użytkownik będzie się łączył. Zrestartuj serwer mysql:
/etc/init.d/mysql restart
Sprawdzanie pracy kreatora:
pokaż status mistrza;
Powinieneś zobaczyć w nim nazwę i pozycję binlogu. Podczas wykonywania poleceń w bazie danych pozycja ulegnie zmianie.
Ustawienie niewolnika
Wprowadzamy zmiany w pliku my.cnf:
Server-id = 2 — identyfikator serwera podrzędnego musi różnić się od identyfikatora serwera głównego. relay-log = /var/lib/mysql/mysql-relay-bin - podobnie jak log binarny składa się z zestawu ponumerowanych plików zawierających zdarzenia opisujące zmiany w bazie danych. relay-log-index = /var/lib/mysql/mysql-relay-bin.index to plik indeksu zawierający nazwy wszystkich używanych plików dziennika przekaźnika. replikuj-do-db = Baza danych do replikacji.
Ważna uwaga! Organizując cross db (gdy używana jest jedna baza danych, a dane są aktualizowane w innej bazie danych) nie trzeba określać binlog-do-db w ustawieniach serwera głównego, binlog-and powinno być zapisywane dla wszystkich baz danych, a w ustawienia podrzędne, które należy zastąpić replikate-do -db, określ replikację-dziką-do-tabelę=nazwa_bazy_danych.%, gdzie nazwa_bazy_danych to nazwa zreplikowanej bazy danych. Zrestartuj serwer mysql:
/etc/init.d/mysql restart
Włącz replikację
USTAW GLOBALNY tylko do odczytu = WŁ.;
Patrzymy na stan master-a:
pokaż status mistrza;
Zapamiętujemy wartości File i Position (i lepiej je zapisać). W tej chwili wartość Pozycja nie powinna się zmieniać. Zrzucamy master za pomocą polecenia mysqldump:
mysqldump -uname -ppassword nazwa_głównej_bazy danych > baza danych zrzutu,
gdzie nazwa - nazwa użytkownika, hasło - hasło, db_master_name - nazwa bazy danych, dump_db - nazwa zrzutu. Po zakończeniu zrzutu zezwalamy na zapis do bazy danych:
USTAW GLOBALNY tylko do odczytu = WYŁ.;
Przenosimy zrzut do urządzenia podrzędnego i wdrażamy
mysql -uname -phasło nazwa_slave_db< dump_db
Konfigurowanie replikacji
ZMIEŃ MASTER NA MASTER_HOST = "ip mastera", MASTER_USER = "nazwa użytkownika", MASTER_PASSWORD = "hasło", MASTER_LOG_FILE = "nazwa dziennika", MASTER_LOG_POS = pozycja;
ip-master - ip serwera, na którym znajduje się master, user_name - nazwa użytkownika, którą utworzyliśmy na masterze, log name - wartość File na masterze, kiedy baza danych została zrzucona, position - wartość Position na masterze, kiedy baza danych został zrzucony. Uruchamiamy niewolnika:
uruchom niewolnika;
Sprawdzamy, jak przebiega replikacja: Na masterze: SHOW MASTER STATUS\G Na slave: SHOW SLAVE STATUS\G
Ustawienia zabezpieczeń na serwerze głównym
Opcja bind-address w /etc/mysql/my.cnf określa adres IP, na którym serwer mysql będzie nasłuchiwał podczas oczekiwania na połączenie. Zwykle ma wartość bind-address = 127.0.0.1. Ale po skonfigurowaniu serwera podrzędnego musimy zezwolić na połączenie z serwera podrzędnego i jednocześnie połączenia lokalne. Bind-address może zezwolić na połączenie tylko z jednego adresu IP lub ze wszystkich. Ponieważ musimy podać więcej niż jeden adres IP dla połączenia, komentujemy linię z adresem wiązania = 127.0.0.1. Teraz serwer mysql będzie akceptował połączenia ze wszystkich adresów IP, co jest bardzo niebezpieczne. iptables pomoże nam rozwiązać ten problem:
Iptables -I INPUT -p tcp -s ip_slave_server-a --dport 3306 -j ACCEPT - na początku zezwalamy na połączenie z adresu ip serwera slave iptables -I INPUT -p tcp --dport 3306 -j DROP - następnie odmawiamy połączenia wszystkim innym adresom IP.
Teraz będziemy mieć 2 serwery MySQL w trybie master-slave, co znacznie zwiększa niezawodność serwisu, a w przypadku niektórych serwisów Drupal pomaga zwiększyć szybkość pracy. W następnym artykule rozważymy przełączanie między trybami master i slave w przypadku awarii serwera głównego.
Replikacja to mechanizm synchronizacji zawartości wielu kopii obiektu. Proces ten odnosi się do kopiowania danych z jednego źródła do wielu innych i odwrotnie.
Oznaczenia:
- master - główny serwer, którego dane mają zostać zduplikowane;
- replika - naprawiony serwer przechowujący kopię danych mastera
Aby skonfigurować replikację w MySQL, należy postępować zgodnie z sekwencją działań opisaną poniżej, ale nie jest to dogmat i parametry mogą się zmieniać w zależności od okoliczności.
Na głównym serwerze edytuj plik my.cnf, dodaj następujące linie do sekcji mysqld:
server-id=log-bin=mysql-bin log-bin-index=mysql-bin.index log-error=mysql-bin.err relay-log=przekaźnik-bin przekaźnik-log-info-file=przekaźnik-bin. informacje przekaźnik-log-index = przekaźnik-bin.indeks wygasa_logs_days=7 binlog-do-db =
- - Unikalny identyfikator serwera MySQL, liczba z zakresu 2 (0-31)
- - nazwa bazy danych, o której informacja będzie zapisywana w logu binarnym, jeżeli baz danych jest kilka, to każda wymaga oddzielnej linii z parametrem binlog_do_db
Na urządzeniu podrzędnym edytuj plik my.cnf, dodaj następujące wiersze do sekcji mysqld:
server-id=master-host=master master-user=replikacja master-password=hasło master-port=3306 relay-log=relay-bin relay-log-info-file=relay-log.info relay-log-index= przekaźnik-log.index replikacja-do-db =
Na serwerze głównym dodaj użytkownika replikacji z uprawnieniami do replikacji danych:
GRAANT REPLICATION SLAVE ON *.* TO "replication"@"replica" IDENTYFIKOWANA PRZEZ "hasło"
Zablokujmy replikowanym bazom danych na głównym serwerze możliwość zmiany danych, programowo lub przy użyciu funkcjonalności MySQL:
[e-mail chroniony]> PŁUKANIE STOLI Z BLOKADĄ ODCZYTU; [e-mail chroniony]> USTAW GLOBALNY tylko do odczytu = WŁ.;
Polecenie odblokowania to:
[e-mail chroniony]> USTAW GLOBALNY tylko do odczytu = WYŁ.;
Zróbmy kopie zapasowe wszystkich baz danych na głównym serwerze (lub tych, które są nam potrzebne):
[e-mail chroniony]# tar -czf mysqldir.tar.gz /var/lib/mysql/
lub za pomocą narzędzia mysqldump:
[e-mail chroniony]# mysqldump -u root -p --lock-all-tables > dbdump.sql
Zatrzymajmy oba serwery (w niektórych przypadkach możesz się bez tego obejść):
[e-mail chroniony]# mysqlamdin -u root -p zamknięcie [e-mail chroniony]# 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ć takie same:
[e-mail chroniony]# cd /var/lib/mysql [e-mail chroniony]# tar -xzf mysqldir.tar.gz
lub mysql, nie było potrzeby zatrzymywania mysql na serwerze podrzędnym:
[e-mail chroniony]# mysql -u root -p< dbdump.sql
Uruchommy mysql na serwerze głównym (a następnie na serwerze podrzędnym, jeśli to konieczne):
[e-mail chroniony]# /etc/init.d/mysql start [e-mail chroniony]# /etc/init.d/mysql start
Sprawdźmy pracę serwerów master i slave:
[e-mail chroniony]> uruchom niewolnika; [e-mail chroniony]> POKAŻ STATUS SLAVE\G [e-mail chroniony]> POKAŻ STATUS GŁÓWNEGO\G
Na serwerze slave sprawdź logi w pliku master.info, powinny zawierać żądania zmiany danych w bazie danych. Więc ten plik binarny musi najpierw zostać przekonwertowany do formatu tekstowego:
[e-mail chroniony]# mysqlbinlog master.info > master_info.sql
Jeśli wystąpią błędy, możesz użyć poleceń:
[e-mail chroniony]> zatrzymaj niewolnika; [e-mail chroniony]> ZRESETUJ PODRZĘDNIK; [e-mail chroniony]> ZRESETUJ GŁÓWNEGO;
i powtórz wszystkie czynności zaczynając od zablokowania bazy danych.
Aby dodać serwery replikacji podczas dodawania, możesz użyć składni:
[e-mail chroniony]> POKAŻ STATUS SLAVE\G [e-mail chroniony]> POKAŻ STATUS GŁÓWNEGO\G [e-mail chroniony]> ZMIEŃ MASTER NA MASTER_HOST = "master", MASTER_USER = "replikacja", MASTER_PASSWORD = "hasło", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155; [e-mail chroniony]> URUCHOM NIEWOLNIKA;
Informacje ze statusów pokażą pozycję i nazwę bieżącego pliku dziennika.
W przypadku replikacji asynchronicznej aktualizacja jednej repliki jest propagowana do innych po pewnym czasie, a nie w tej samej transakcji. Zatem replikacja asynchroniczna wprowadza opóźnienie lub limit czasu, podczas którego poszczególne repliki mogą w rzeczywistości nie być identyczne. Ale ten typ replikacji ma też pozytywne strony: główny serwer nie musi martwić się o synchronizację danych, można zablokować bazę danych (np. kopia zapasowa) na maszynie podrzędnej, nie ma 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_(computer_engineering))
Korzystając z jakichkolwiek materiałów z serwisu, w całości lub w części, musisz wyraźnie wskazać link jako źródło.
Z replikacją serwerów MySQL zapoznałem się stosunkowo niedawno, a ponieważ robiłem różne eksperymenty z ustawieniami, spisałem, co zrobiłem. Gdy materiału było dużo, pojawił się pomysł napisania tego artykułu. Starałem się zebrać wskazówki i rozwiązania niektórych z najbardziej podstawowych problemów, jakie napotkałem. Po drodze udostępnię linki do dokumentacji i innych źródeł. Nie mogę udawać kompletnego, ale mam nadzieję, że artykuł będzie przydatny.
Małe wprowadzenie
Replikacja (z łac. replico - powtarzam) to replikacja zmian danych z głównego serwera bazy danych na jeden lub więcej serwerów zależnych. Główny serwer zostanie wywołany gospodarz i zależne repliki.Zmiany danych zachodzące w urządzeniu głównym są powtarzane w replikach (ale nie odwrotnie). Dlatego zapytania o zmianę danych (INSERT, UPDATE, DELETE itp.) są wykonywane tylko na masterze, natomiast zapytania o odczyt danych (inaczej 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 oraz praktycznie nie wpływa na działanie mastera.
Replikacja odbywa się za pomocą dzienników binarnych utrzymywanych na urządzeniu głównym. Zapisują wszystkie zapytania, które prowadzą (lub potencjalnie prowadzą) do zmian w bazie danych (zapytania nie są przechowywane jawnie, więc jeśli chcesz je zobaczyć, będziesz musiał użyć narzędzia mysqlbinlog). Binlogi są przenoszone do replik (binlog pobrany z mastera nazywa się „relay binlog”), a zapisane zapytania są wykonywane od określonej pozycji. Ważne jest, aby zrozumieć, że replikacja nie przenosi samych zmienionych danych, a jedynie żądania, które powodują zmiany.
Podczas replikacji zawartość bazy danych jest powielana na kilku serwerach. Dlaczego konieczne jest stosowanie duplikacji? Jest kilka powodów:
- wydajność i skalowalność. Jeden serwer może nie być w stanie obsłużyć obciążenia spowodowanego współbieżnymi odczytami i zapisami bazy danych. Korzyść z tworzenia replik będzie tym większa, im więcej odczytów przypada na zapis w systemie.
- tolerancja błędów. W przypadku awarii repliki wszystkie żądania odczytu mogą być bezpiecznie przekazane do mastera. W przypadku awarii mastera żądania zapisu mogą być przekazywane do repliki (po przywróceniu master może przejąć rolę repliki).
- Backup danych. Replikę można „spowolnić” na chwilę, aby wykonać mysqldump, ale master nie.
- leniwa ocena. Ciężkie i powolne zapytania SQL można uruchamiać na oddzielnej replice bez obawy o zakłócenia normalna operacja cały system.
Konfigurowanie replikacji
Załóżmy, że mamy już działającą bazę danych MySQL wypełnioną danymi i uruchomioną. I z jednego z powodów opisanych powyżej zamierzamy włączyć replikację na naszym serwerze. Nasze wstępne dane:- Adres IP mastera to 192.168.1.101, replika to 192.168.1.102.
- MySQL zainstalowany i skonfigurowany
- musisz skonfigurować replikację bazy danych testdb
- możemy zatrzymać kreatora na chwilę
- oczywiście mamy roota na obu komputerach
Ustawienia kreatora
Pamiętaj, aby w sekcji podać unikalny identyfikator serwera, ścieżkę do logów binarnych oraz nazwę bazy danych do replikacji:identyfikator-serwera = 1
log-bin = /var/lib/mysql/mysql-bin
replikuj-zrób-db=baza testowa
Upewnij się, że masz wystarczająco dużo miejsca na dysku dla dzienników binarnych.
Dodajmy użytkownika replikacji, na prawach którego będzie wykonywana replikacja. Wystarczy uprawnienie „podrzędny replikacji”:
[e-mail chroniony]> PRZYZNAJ replikację podrzędną ON „testdb”.* TO „replication”@ „192.168.1.102” IDENTYFIKOWANA PRZEZ „hasło”;
Uruchom ponownie MySQL, aby zmiany konfiguracji odniosły skutek:
[e-mail chroniony]# ponowne uruchomienie usługi mysqld
Jeśli wszystko poszło dobrze, polecenie „show master status” powinno pokazać coś takiego:
[e-mail chroniony]> POKAŻ STATUS GŁÓWNEGO\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
Podaj identyfikator serwera, nazwę bazy danych do replikacji i ścieżkę do binlogów przekazywania w sekcji konfiguracji, a następnie zrestartuj MySQL:identyfikator-serwera = 2
relay-log=/var/lib/mysql/mysql-relay-bin
przekaźnik-log-index = /var/lib/mysql/mysql-relay-bin.index
replikuj-zrób-db=baza testowa
[e-mail chroniony]# ponowne uruchomienie usługi mysqld
Przesyłanie danych
Tutaj będziemy musieli zablokować bazę danych do zapisu. Aby to zrobić, możesz albo zatrzymać uruchomione aplikacje, albo użyć flagi tylko do odczytu na urządzeniu głównym (uwaga: ta flaga nie dotyczy użytkowników z uprawnieniem SUPER). Jeśli mamy tabele MyISAM, zrobimy również „płukanie tabel”:[e-mail chroniony]> PŁUKANIE STOLI Z BLOKADĄ ODCZYTU;
[e-mail chroniony]> USTAW GLOBALNY tylko do odczytu = WŁ.;
Przyjrzyjmy się statusowi mastera poleceniem „show master status” i zapamiętajmy wartości File i Position (po pomyślnym zablokowaniu mastera nie powinny się zmieniać):
Plik: mysql-bin.000003
Pozycja: 98
Wykonujemy zrzut bazy danych, a po zakończeniu operacji usuwamy blokadę główną:
[e-mail chroniony]> USTAW GLOBALNY tylko do odczytu = WYŁ.;
Przenosimy zrzut do repliki i przywracamy z niej dane.
Na koniec uruchamiamy replikację komendami „change master to” i „start slave” i sprawdzamy, czy wszystko poszło dobrze:
[e-mail chroniony]> 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;
[e-mail chroniony]> uruchom niewolnika;
Pobieramy wartości MASTER_LOG_FILE i MASTER_LOG_POS z mastera.
Zobaczmy, jak przebiega replikacja z poleceniem „show slave status”:
[e-mail chroniony]> POKAŻ STATUS SLAVE\G
Slave_IO_State: Oczekiwanie na wysłanie zdarzenia przez mastera
Host_główny: 192.168.1.101
Główny_użytkownik: replikacja
Główny_port: 3306
Połącz_ponownie: 60
Master_Log_File: mysql-bin.000003
Odczyt_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
Replikuj_Ignoruj_DB:
Replikuj_do_tabeli:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Ostatni_błąd:
Pomiń_licznik: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Do_warunku: Brak
Do_Pliku_Dziennika:
Do_Log_Poz: 0
Master_SSL_Allowed: Nie
Master_SSL_CA_Plik:
Master_SSL_CA_Path:
Główny_certyfikat_SSL:
Główny_szyfr SSL:
Główny_klucz_SSL:
Seconds_Behind_Master: 5
Podkreśliłem teraz najciekawsze wartości. Po pomyślnym uruchomieniu replikacji ich wartości powinny być w przybliżeniu takie same jak na listingu (patrz opis polecenia "show slave status" w dokumentacji). Wartość Seconds_Behind_Master może być dowolną liczbą całkowitą.
Jeśli replikacja przebiegnie pomyślnie, replika podąży za masterem (numer logu w Master_Log_File oraz pozycja Exec_Master_Log_Pos wzrośnie). Idealnie czas za repliką od wzorca (Seconds_Behind_Master) powinien być równy zeru. Jeśli nie zmniejsza się lub nie rośnie, możliwe, że obciążenie repliki jest zbyt duże - po prostu nie ma czasu na powtórzenie zmian, które zachodzą na wzorcu.
Jeśli Slave_IO_State jest pusty, a Seconds_Behind_Master ma wartość NULL, replikacja nie została uruchomiona. Spójrz na dziennik MySQL, aby znaleźć przyczynę, napraw ją i ponownie rozpocznij replikację:
[e-mail chroniony]> uruchom niewolnika;
Dzięki tym prostym krokom otrzymujemy replikę, której dane są identyczne z danymi na masterze.
Nawiasem mówiąc, czas blokady wzorca to czas utworzenia zrzutu. Jeśli tworzenie zajmuje niedopuszczalnie dużo czasu, możesz spróbować tego:
- zablokuj pisanie do mastera z flagą tylko do odczytu, 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.
Dodawanie replik
Załóżmy, że mamy już działającą matrycę i replikę i musimy dodać do nich kolejną. Jest to nawet łatwiejsze niż dodanie pierwszej repliki do wzorca. I o wiele przyjemniej jest, że nie ma potrzeby zatrzymywania mistrza w tym celu.Najpierw ustawmy MySQL na drugiej replice i upewnijmy się, że wprowadziliśmy niezbędne parametry w configu:
identyfikator serwera = 3
replikuj-zrób-db=baza testowa
Teraz zatrzymaj replikację na pierwszej replice:
[e-mail chroniony]> zatrzymaj niewolnika;
Replika będzie nadal działać normalnie, ale zawarte na niej dane nie będą już aktualne. Przyjrzyjmy się statusowi i zapamiętajmy pozycję mastera, do którego dotarła replika przed zatrzymaniem replikacji:
[e-mail chroniony]> POKAŻ STATUS SLAVE\G
Będziemy potrzebować wartości Master_Log_File i Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155
Utwórz zrzut bazy danych i kontynuuj replikację na pierwszej replice:
[e-mail chroniony]> URUCHOM NIEWOLNIKA;
Odtwórzmy dane ze zrzutu na drugiej replice. Następnie włącz replikację:
[e-mail chroniony]> 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;
[e-mail chroniony]> URUCHOM NIEWOLNIKA;
Wartości MASTER_LOG_FILE i MASTER_LOG_POS to odpowiednio wartości Master_Log_File i Exec_Master_Log_Pos z wyniku polecenia show slave status na pierwszej replice.
Replikacja powinna rozpocząć się od miejsca, w którym zatrzymano pierwszą replikę (i odpowiednio utworzono zrzut). Tym samym będziemy mieli dwie repliki z identycznymi danymi.
Łączenie replik
Czasami dochodzi do takiej sytuacji: na masterze znajdują się dwie bazy danych, z których jedna jest replikowana na jednej replice, a druga na drugiej. Jak skonfigurować replikację dwóch baz danych na obu replikach bez zrzucania ich na mastera i bez jego wyłączania? Dość proste, używając polecenia „uruchom niewolnika do”.Mamy więc mastera z bazami danych testdb1 i testdb2, które są replikowane odpowiednio na replikach replika-1 i replika-2. Skonfigurujmy replikację obu baz danych na replice-1 bez zatrzymywania mastera.
Zatrzymaj replikację na replice-2 za pomocą polecenia i zapamiętaj pozycję mastera:
[e-mail chroniony]> ZATRZYMAJ NIEWOLNIKA;
[e-mail chroniony]> POKAŻ STATUS SLAVE\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231
Stwórzmy zrzut bazy danych testdb2 i wznówmy replikację (na tym skończyły się manipulacje z repliką-2). Zrzut zostanie przywrócony do repliki-1.
Sytuacja na replice-1 wygląda następująco: baza testdb1 znajduje się na jednej pozycji mastera i kontynuuje replikację, baza testdb2 została przywrócona ze zrzutu z innej pozycji. Synchronizujemy je.
Zatrzymaj replikację i zapamiętaj pozycję wzorca:
[e-mail chroniony]> ZATRZYMAJ NIEWOLNIKA;
[e-mail chroniony]> POKAŻ STATUS SLAVE\G
Exec_Master_Log_Pos: 501
Upewnij się, że w konfiguracji na replice-1 sekcja zawiera nazwę drugiej bazy danych:
replikuj-do-db=testdb2
Uruchom ponownie MySQL, aby zmiany w konfiguracji zaczęły obowiązywać. Nawiasem mówiąc, można po prostu zrestartować MySQL bez zatrzymywania replikacji - z logu dowiemy się, w którym miejscu replikacja główna się zatrzymała.
Teraz wykonajmy replikację z pozycji, w której replika-2 została zawieszona, do pozycji, w której właśnie zawiesiliśmy replikację:
[e-mail chroniony]> 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;
[e-mail chroniony]> uruchom slave'a 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 till, po czym obie nasze bazy będą odpowiadały tej samej pozycji wzorcowej (gdzie zatrzymaliśmy replikację na replice-1). Upewnijmy się co do tego:
[e-mail chroniony]> POKAŻ STATUS SLAVE\G
[e-mail chroniony]> URUCHOM NIEWOLNIKA;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501
Dodajmy nazwy obu baz danych do konfiguracji na replice-1 w sekcji:
replikuj-zrób-db=testdb1
replikuj-do-db=testdb2
Ważne: każda baza danych musi być wymieniona w osobnym wierszu.
Zrestartuj MySQL i kontynuuj replikację:
[e-mail chroniony]> 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ść ich bazy danych będzie identyczna. Możesz scalić bazę danych w replice-2 w podobny sposób lub przez wykonanie pełnego zrzutu repliki-1.
Mistrz roszady i replika
Może być konieczne przełączenie repliki w tryb master, na przykład w przypadku awarii mastera lub podczas wykonywania a prace techniczne. Aby włączyć taki przełącznik, musisz skonfigurować replikę jako master lub zrobić to pasywny mistrz.Włącz logowanie binarne (oprócz binlogów przekazywania) w konfiguracji w sekcji:
log-bin = /var/lib/mysql/mysql-bin
I dodaj użytkownika do replikacji:
[e-mail chroniony]> PRZYZNAJ replikację slave ON ’testdb’.* TO ’replication’@’192.168.1.101′ ZIDENTYFIKOWANA PRZEZ „hasło”;
Pasywny master replikuje się jak zwykła replika, ale tworzy też logi binarne – czyli od niego możemy rozpocząć replikację. Upewnijmy się o tym za pomocą polecenia „show master status”:
[e-mail chroniony]> POKAŻ STATUS GŁÓWNEGO\G
Plik: mysql-bin.000001
Pozycja: 61
Binlog_Do_DB:
Binlog_Ignore_DB:
Teraz, aby wprowadzić pasywnego mastera w tryb aktywny, musisz zatrzymać na nim replikację i włączyć replikację na poprzednim aktywnym masterze. Aby zapewnić, że dane nie zostaną utracone w momencie zmiany, aktywny mistrz musi mieć blokadę zapisu.
[e-mail chroniony]> PŁUCZ TABELE Z BLOKADĄ ODCZYTU
[e-mail chroniony]> USTAW GLOBALNY tylko do odczytu = WŁ.;
[e-mail chroniony]> ZATRZYMAJ NIEWOLNIKA;
[e-mail chroniony]> POKAŻ STATUS NARZĘDZIA;
Plik: mysql-bin.000001
Pozycja: 61
[e-mail chroniony]> 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;
[e-mail chroniony]> uruchom niewolnika;
To wszystko, więc zmieniliśmy aktywnego mistrza. Możesz usunąć blokadę z byłego mistrza.
Wniosek
Omówiliśmy trochę, jak skonfigurować replikację w MySQL i wykonać kilka podstawowych operacji. Niestety, następujące ważne pytania pozostały poza zakresem artykułu:
- eliminacja pojedynczych punktów awarii (SPF, Single Points of Failure). W przypadku korzystania z 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 zapewnić obsługę sytuacji awarii mastera i repliki. Jedno z istniejących narzędzi – MMM trzeba jednak sfinalizować plikiem.
- równoważenie obciążenia. W przypadku korzystania z wielu replik wygodne byłoby dla nas zastosowanie przejrzystego mechanizmu równoważenia, zwłaszcza jeśli wydajność replik nie jest taka sama. Pod Linuksem możliwe jest użycie standardowego rozwiązania - LVS.
- zmiana logiki aplikacji. W idealnym przypadku żądania odczytu danych powinny być wysyłane do replik, a zmiany do wzorca. Jednak ze względu na możliwe zaległości w replikach taki schemat jest często niewykonalny i konieczne jest zidentyfikowanie takich żądań odczytu, które wciąż muszą zostać wykonane na masterze.
Dziękuję za uwagę!
Replikacja danych MySQL pozwala na posiadanie dokładnej kopii bazy danych z jednego serwera - serwera głównego (serwer główny) na jednym lub kilku innych serwerach (serwer podrzędny). Domyślnie replikacja Mysql jest asynchroniczna.
Co oznacza, że serwer główny w żaden sposób nie kontroluje i nie wie, czy serwery podrzędne czytają plik dziennika i czy robią to poprawnie.
Istnieją również inne rodzaje synchronizacji, synchroniczne i półsynchroniczne, w których procesy te są kontrolowane.
W zależności od ustawień można replikować zarówno całe bazy danych, jak i poszczególne tabele bazy danych.
Do czego możesz użyć replikacji:
1. Równoważenie obciążenia między hostami w celu poprawy wydajności.
W takim schemacie węzeł nadrzędny będzie wykonywał operacje odczytu i zapisu, węzły które mają subskrypcję na węźle nadrzędnym będą stanowić bazę do odczytu, więc odciążymy serwer nadrzędny od operacji odczytu
2. Bezpieczeństwo danych i łatwość utrzymania, ponieważ węzeł podrzędny zawiera dane tylko do odczytu, wówczas zmiany danych na abonencie będą ograniczone, łatwość utrzymania - możliwość uruchamiania procesów obsługujących bazę bez przerywania pracy aplikacji
3. Dystrybucja danych na duże odległości. Możesz utworzyć kopię danych na dowolnym hoście, niezależnie od jego lokalizacji
MySQL obsługuje następujące metody replikacji:
Tradycyjna — metoda polega na replikacji zdarzeń z binarnego pliku dziennika mastera i wymaga plików dziennika. Pozycje między serwerami głównymi i podrzędnymi muszą być zsynchronizowane.
Metoda wykorzystująca globalne GTID (metoda transakcyjna)
MySQL obsługuje następujące rodzaje synchronizacji:
asynchroniczny (jednokierunkowa synchronizacja)
półsynchroniczny (częściowa kontrola abonentów)
synchroniczny (pełna kontrola abonentów)
Konfigurowanie replikacji bazy danych Mysql tradycyjną metodą
Zasada działania
Serwer główny zawiera kosz pliki dziennika rejestrujące wszystkie zmiany zachodzące w bazie danych mistrza, plik opisujący nazwy kosz plików, a także miejsce w dzienniku, w którym zapisano ostatnie dane podstawowe
Węzeł podrzędny otrzymuje dane od węzła nadrzędnego posiadającego informacje o nazwach kosz plików i pozycji w pliku dziennika.
Konfiguracja kreatora
mój.ini musi zawierać unikalny identyfikator - liczbę od 1 do 2 do potęgi 32 - 1, server-id.
Domyślnie server-id=0, co oznacza, że nie akceptuj subskrypcji z serwerów podrzędnych
log-bin=mysql-bin
identyfikator serwera=1
Te dwie linie wystarczą do uruchomienia
Uwaga: jeśli jednak używany jest InnoDB, dodatkowo zaleca się dodanie
innodb_flush_log_at_trx_commit=1
sync_binlog=1
I musisz sprawdzić, czy możliwość pracy z siecią nie jest wyłączona, parametr skip-networking nie jest ustawiony
Serwer podrzędny łączy się z serwerem głównym za pomocą nazwy użytkownika i hasła, więc najpierw tworzymy użytkownika na serwerze głównym
STWÓRZ UŻYTKOWNIKA [e-mail chroniony]%.mydomain.com ZIDENTYFIKOWANA PRZEZ hasło podrzędne;
NADANIE REPLIKACJI SLAVE NA *.* TO [e-mail chroniony]%.mojadomena.com;
Patrzymy na stan
POKAŻ STATUS MASTERA
Jeśli procedura tworzenia logów binarnych została już uruchomiona, to dla tabel InnoDB należy najpierw zablokować tabele w jednej z sesji
STOŁY WYPŁUKANE Z BLOKADĄ ODCZYTU;
Jeśli wyjdziesz z sesji, blokada stołu zostanie automatycznie zwolniona.
W innej sesji uzyskaj wartości nazwy kosz logo i pozycja
Obie wartości reprezentują współrzędne replikacji, przy których standby powinien rozpocząć odczyt z pliku we właściwej lokalizacji, aby rozpocząć replikację.
Następny krok zależy od tego, czy na serwerze podrzędnym znajdują się dane, dane z serwera nadrzędnego
Jeśli tak, to zostawiamy zamknięte stoły, tworzymy wysypisko(jest to zalecany sposób przy korzystaniu z InnoDB)
Możesz znaleźć typ bazy danych za pomocą polecenia
mysqlshow -u mysql_user -p -i nazwa-bazy-danych
Jeśli baza danych jest przechowywana w plikach binarnych, można je skopiować z serwera głównego na serwer podrzędny
Czyn wysypisko
mysqldump --all-databases --master-data dbdump.db
aby wybrać bazy mysqldump --databases --master-data dbdump.db
parametr danych podstawowych, dodawany automatycznie ZMIEŃ MISTRZA NA na węźle podrzędnym, jeśli parametr nie zostanie dodany, konieczne jest ręczne zablokowanie wszystkich tabel w sesji
Usuń blokadę
ODBLOKUJ TABELE;
Konfiguracja węzła podrzędnego A
Dodać do mój.ini server-id jest prywatny od mastera i od innych węzłów
identyfikator serwera=2
Utwórz subskrypcję
ZMIEŃ MISTRZA NA
MASTER_HOST=nazwa_głównego_hosta,
MASTER_USER=nazwa_użytkownika_replikacji,
MASTER_PASSWORD=hasło_replikacji,
MASTER_LOG_FILE=nazwa_pliku_rejestru_rejestru,
MASTER_LOG_POS=zarejestrowana_pozycja_logu;
Podczas konfigurowania replikacji z istniejącymi danymi przed rozpoczęciem replikacji należy przesłać migawkę z urządzenia nadrzędnego do urządzenia podrzędnego
Używamy mysqldump
1. Uruchom węzeł podrzędny za pomocą --skip-slave-start możliwość nieuruchamiania replikacji
2.Zaimportuj plik zrzutu
mysql fulldb.dump
3. Rozpocznij proces subskrypcji
START NIEWOLNIK;
Sprawdzanie stanu replikacji
POKAŻ STATUS SLAVE\G
Slave_IO_State: - aktualny stan urządzenia podrzędnego
Slave_IO_Running: - czy strumień danych jest odczytywany z mastera
Slave_SQL_Running: - czy działają zapytania sql, powinno być tak
Przykład Skonfigurujmy serwer główny (wiodący) - ip 11.11.11.10 V mój.ini
[
mysqld] log-bin=mysql-bin identyfikator-serwera=1
Utwórz użytkownika mysql -u root -p NADANIE REPLIKACJI SLAVE NA *.* TO [e-mail chroniony]% IDENTYFIKOWANE PRZEZ hasło; PRZYWILEJE PŁASKIE;
Następnie zablokuj wszystkie tabele w bazie danych STOŁY WYPŁUKANE Z BLOKADĄ ODCZYTU;
Patrzymy na stan POKAŻ STATUS GŁÓWNY;
Zapamiętujemy nazwę pliku i pozycję, użyjemy ich na serwerze Slave do subskrypcji
Na Slave B mój.ini
log-bin=mysql-bin identyfikator-serwera=2
Utwórz subskrypcję ZMIEŃ MASTER NA MASTER_HOST=11.11.11.10, MASTER_PORT=3306,
MASTER_USER=replika, MASTER_PASSWORD=hasło,
MASTER_LOG_FILE=serwer-mysql-bin.000002,
MASTER_LOG_POS=1151664, MASTER_CONNECT_RETRY=10;
START NIEWOLNIK;
Status replikacji POKAŻ STATUS SLAVE\G
