Jak ponownie zsynchronizować Master MySQL DB ze zmianami Slave DB, jeśli Master przejdzie w tryb offline?

MySQL Server 1 działa jako Master.
MySQL Server 2 działa jako Slave.

Obie bazy danych są w trybie „idealnej synchronizacji”. Jeśli Slave przejdzie w tryb offline, nie ma problemu, jeśli Master nadal jest w trybie online; wrócą do synchronizacji, gdy Slave będzie ponownie online.

Oprócz konfiguracji serwera przekierowałem połączenie (z kodem JSP) dla Slave DB, jeśli Master przejdzie w tryb offline (testowałem oczywiście z /etc/init.d/mysqld stop).

Kiedy Master wraca do trybu online, czy jest jakaś automatyczna metoda synchronizacji Master z aktualizacjami Slave?

Jednym dobrym sposobem na uzyskanie czegoś takiego jest skonfigurowanie replikacji master-master lub replikacji cyklicznej. Nie należy tego mylić z MultiMaster Replacement.

Konfiguracja replikacji cyklicznej jest naprawdę bardzo łatwa, jeśli masz skonfigurowaną replikację Master-Slave. Oto, co musisz zrobić, aby go skonfigurować.

W tym przykładzie założymy, że replikacja Master-Slave jest aktywna, ale wystąpi trochę przestoju (1-2 minuty):

Krok 1) Dodaj tę linię do /etc/my.cnf na Master.

log-slave-updates

Krok 2) Dodaj tę linię do /etc/my.cnf w Slave:

log-bin = mysql-bin (lub mieć to, co ma do tego master) log-slave-updates

OSTRZEŻENIE: Oto krótki moment przestoju !!!

Krok 3) W Slave ponownie uruchom usługę mysql

To aktywuje dzienniki binarne w Slave

Krok 4) Na Master, zatrzymaj mysql usługi

Krok 5) Użyj rsync, aby skopiować folder / var / lib / mysql Slave do Master.

OSTRZEŻENIE: Oto dłuższy moment przestoju !!!

Krok 6) W Slave, zatrzymaj mysql usługi

Krok 7) W Slave znajdź ostatni dziennik binarny

Krok 8) W Slave znajdź rozmiar pliku ostatniego dziennika binarnego

Krok 9) Użyj rsync, aby skopiować folder / var / lib / mysql Slave do Master. To powinna być szybsza kopia.

Krok 10) W Master, edytuj
wiersz 2 master.info z ostatnim dziennikiem binarnym Slave.
Wiersz 3 master.info z rozmiarem pliku ostatniego binarnego dziennika Slave.
Linia 4 master.info z adresem IP urządzenia slave.
Wiersz 5 to identyfikator użytkownika użytkownika replikacji (NIE DOTYKAJ)
Wiersz 6 to hasło użytkownika replikacji (NIE DOTYKAJ)

Krok 11) Usuń wszystkie dzienniki binarne i plik indeksu dziennika binarnego urządzenia nadrzędnego.

Krok 12) W Slave uruchom usługę mysql, odczekaj 15 sekund

Krok 13) Na komputerze głównym uruchom usługę mysql

Krok 14) Na urządzeniu Master uruchom STOP SLAVE; POKAŻ STATUS MASTERA;

Krok 15) W Slave uruchom CHANGE MASTER TO MASTER_HOST = 'IP of Slave', MASTER_USER = 'identyfikator użytkownika replikacji z Step10', MASTER_PASSWORD = 'hasło użytkownika replikacji z Step10', MASTER_LOG_FILE = 'log binarny z Step14', MASTER_LOG_POS = LogPos z kroku 14.

Krok 16) W Slave uruchom START SLAVE;

Krok 17) Na urządzeniu głównym uruchom START SLAVE;

Wykonałem kroki podobne do tego dla innego pytania StackExchange, na które odpowiedziałem .

Spróbuj !!!

Nie w przypadku replikacji asynchronicznej, którą oferuje MySQL. Właśnie trafiłeś w przysłowiowy gwóźdź, dlaczego „gotowa replika” MySQL (wcześniejsza niż 5.5) sama w sobie nie jest rozwiązaniem wysokiej dostępności. W przypadku wersji 5.5 z półsynchroniczną replikacją sytuacja trochę się poprawia (http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html), ale kosztem wolniejszego czasu transakcji, gdy jednostka główna czeka na ack od niewolnika.

Jeśli zaakceptowanie możliwości utraty danych w przypadku awarii urządzenia master nie jest opcją, powiedziałbym, że bardziej wyrafinowana jest konfiguracja niż proste urządzenie master / slave.

Replikacja Master to Master została uznana za większy problem niż korzyść dla wielu znanych osób MySQL (nawet sam MySQL AB nie zaleca go już jako rozwiązania wysokiej dostępności). Tak więc myślę, że użycie konfiguracji DRBD w celu zsynchronizowania aktywnego urządzenia nadrzędnego i pasywnego urządzenia podrzędnego za pomocą kopii na poziomie bloku jest tym, czego naprawdę potrzebujesz.

IMHO Po pierwsze, w konfiguracji innej niż master (master / slave), twój slave nigdy nie powinien przyjmować zapisów. Slave mój.cnf powinien zostać skonfigurowany, a serwer powinien zostać uruchomiony:

# Flag to not take writes from network
read-only

Następnie, aby rozwiązać problem zsynchronizowania mastera z zapisywalnym slave'em, który przypadkowo przyjmuje zapisy, musisz różnicować dane na obu hostach. Jeśli nie ma kolizji z kluczem, powinieneś wypromować swojego byłego hosta podrzędnego do opanowania i ponownie zobrazować swojego starego nadrzędnego jako hosta podrzędnego replikującego się z nowego nadrzędnego. (mogą tu wystąpić / prawdopodobnie występują problemy z danymi)

Wreszcie, jeśli ten scenariusz przestoju / przestoju jest nawet możliwy w przyszłości , poświęć trochę czasu, aby ustawić oba hosty jako multi-master (log-bin, identyfikator serwera, przesunięcia itp.). Pomoże to w pewnym stopniu ograniczyć awarie i przestoje.

Jeśli musisz uruchomić master / slave , przynajmniej zdobądź dodatkowe punkty za oddzielenie połączeń użytkownika do odczytu i zapisu w ACL i aplikacjach.