Replikacja MySQL na oddzielnych geograficznie serwerach

Moja organizacja zastanawiała się, jak geograficznie rozmieścić nasze serwery, jednocześnie aktualizując kopie zapasowe i idealnie rozkładając obciążenie.

Pierwszą rzeczą, którą mam na myśli, jest Rails na MySQL. Szybkość zapisu nie jest zbyt wysoka (artykuły / komentarze pozostawiają mniej niż 1 na minutę, chociaż niektóre mają duże załączniki multimedialne).

Więc,

• czy replikacja MySQL działa dobrze w sieciach rozległych?
• Czy połączenie (lub serwer podrzędny) nie działa oznacza, że ​​wymagana jest ręczna interwencja (gdy dwa serwery będą mogły ponownie się ze sobą rozmawiać), czy odzyskiwanie jest automatyczne?
• Jeśli mistrz zniknie, co jest potrzebne, aby zmienić niewolnika w mistrza? Czy istnieją standardowe skrypty / narzędzia, które pomogą to zarządzać?
• Jakieś inne problemy itp?

Używamy replikacji w centrach danych w kilku krajach europejskich (więc nie są one na całym świecie od siebie, ale z pewnością nie są lokalne) i działa bez problemu.

Replikacja zostanie automatycznie uruchomiona ponownie, jeśli to możliwe. Jeśli występuje problem z zapytaniem (np. Baza danych jest obecna w systemie nadrzędnym, a nie podrzędnym, a zapytanie go używa), wówczas domyślnie będzie wymagała ręcznej korekty (ale można ustawić, aby ignorowała takie błędy). Jeśli bazy danych są dokładnymi kopiami lustrzanymi, nigdy nie powinno być konieczne ręczne restartowanie replikacji.

Jeśli masz dwa serwery, a master znika, to aby zmienić slave w „master”, po prostu zatrzymaj replikację i zmień kod (aby napisać do nowego „master”). Jeśli masz trzy lub więcej serwerów, a master znika, zatrzymaj replikację na slaveach, zmień je tak, aby korzystały z nowego mastera i zacznij od nowa. Jeśli nie są dokładnie zsynchronizowane (zależy od ilości przesyłanych danych, od tego, jak zajęte są serwery, jak dobre jest połączenie sieciowe itp.), Być może będziesz musiał wykonać więcej pracy. Sekcja replikacji dokumentacji MySQL opisuje to bardziej szczegółowo .

Sugeruję, aby upewnić się, że przeprowadzasz replikację przez SSL (tj. Ustaw użytkownika replikacji, aby wymagał połączenia SSL).

Replikacja zmieniła się dramatycznie w MySQL 5.1. W 5.0 zastosowano tylko replikację opartą na instrukcjach. Masz teraz możliwość wykonania replikacji opartej na wierszach lub replikacji mieszanej. Wpłynie to znacząco na sposób replikacji przez sieć WAN.

Jeśli masz możliwość: A) przejąć kontrolę nad IP (jeśli twoje serwery są geograficznie rozdzielone, nie jest to prawdopodobne) B) dokonaj zwinnych zmian DNS Możesz uniknąć modyfikacji kodu / konfiguracji aplikacji, aby zmienić wzorce. Używamy wewnętrznego DNS z krótkim buforowaniem i fałszywymi domenami .internal. Jeśli potrzebujemy zmienić masterdb.internal, aby być innym serwerem, zmiana zajmie 5 sekund.

W ramach jednego centrum danych wykorzystujemy przejęcie IP. Wszystkie serwery DB mają interfejsy wirtualne (eth0: 1, eth0: 2, eth0: 3), które nie są uruchamiane podczas uruchamiania. Jeśli jeden z niewolników musi przejąć kontrolę, po prostu eth0: 2 i to on jest panem. W tym scenariuszu eth0 to „jeśli”, którego używamy do wykonywania powłoki i tak dalej. Aplikacje łączą się na et0: 1, które nie zostaną aktywowane podczas rozruchu, jeśli mój skrypt wykryje, że IP jest zajęty. (wikipedia STONITH) Pozostałe są za przejęcie adresów IP mistrzów, których może być konieczne awaria.

Nie polecam przekraczania oceanów podczas korzystania z replikacji MySQL. Próbowałem kiedyś powtórzyć od mistrza w Europie, gdy niewolnik był w Teksasie. Replikacja wybuchała prawie codziennie, dopóki nie porzuciliśmy tego projektu. Oczywiście, że może działać, ale zwykle staje się bardziej kruchy, im większa jest odległość między panem a niewolnikiem.