Migracja bazy danych do nowego centrum danych może być procesem obarczonym wysokim ryzykiem i czasochłonnym. Baza danych zawiera stan i może być znacznie trudniejsza do migracji w porównaniu z serwerami WWW, kolejkami lub serwerami pamięci podręcznej.
W tym poście na blogu przedstawimy kilka wskazówek dotyczących migracji danych od jednego dostawcy usług do drugiego. Proces jest nieco podobny do naszego poprzedniego postu na temat aktualizacji MySQL, ale istnieje kilka ważnych różnic.
Replikacja MySQL czy klaster Galera?
Przejście do innego usługodawcy (np. przejście z AWS do Rackspace lub z kolokowanych serwerów do chmury) bardzo często oznacza, że równolegle buduje się zupełnie nową infrastrukturę, synchronizuje ją ze starą, a następnie przechodzi na nią. Aby je połączyć i zsynchronizować, możesz skorzystać z replikacji MySQL.
Jeśli korzystasz z Galera Cluster, może być łatwiej przenieść węzły Galera do innego centrum danych. Należy jednak pamiętać, że cały klaster nadal musi być traktowany jako pojedyncza baza danych. Oznacza to, że Twoja witryna produkcyjna może ucierpieć z powodu dodatkowych opóźnień wprowadzonych podczas rozciągania Galera Cluster przez sieć WAN. Można zminimalizować wpływ, dostosowując ustawienia sieciowe zarówno w Galerze, jak iw systemie operacyjnym, ale wpływu nie można całkowicie wyeliminować. Możliwe jest również skonfigurowanie asynchronicznej replikacji MySQL między starym a nowym klastrem, jeśli wpływ opóźnień jest nie do zaakceptowania.
Konfigurowanie bezpiecznej łączności
Replikacja MySQL jest niezaszyfrowana i dlatego nie jest bezpieczna w użyciu przez sieć WAN. Istnieje wiele sposobów na zapewnienie bezpiecznego przesyłania Twoich danych. Należy zbadać, czy możliwe jest nawiązanie połączenia VPN między obecną infrastrukturą a nowym dostawcą usług. Większość dostawców (na przykład zarówno Rackspace, jak i AWS) zapewnia taką usługę - możesz podłączyć swoją „chmurną” część do istniejącego centrum danych za pośrednictwem wirtualnej sieci prywatnej.
Jeśli z jakiegoś powodu to rozwiązanie nie działa dla Ciebie (być może wymaga sprzętu, do którego nie masz dostępu), możesz użyć oprogramowania do zbudowania VPN – jednym z nich będzie OpenVPN. To narzędzie będzie działać dobrze, aby skonfigurować szyfrowane połączenia między centrami danych.
Jeśli OpenVPN nie jest opcją, istnieje więcej sposobów na zapewnienie, że replikacja będzie szyfrowana. Na przykład możesz użyć SSH do utworzenia tunelu między starymi i nowymi centrami danych i przekierować port 3306 z bieżącego urządzenia podrzędnego (lub głównego) MySQL do nowego węzła. Można to zrobić w bardzo prosty sposób, o ile masz połączenie SSH między hostami:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Na przykład:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Teraz możesz połączyć się ze zdalnym serwerem za pomocą 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Będzie działać podobnie dla replikacji, pamiętaj tylko, aby użyć 127.0.0.1 dla master_host i 3307 dla master_port
Na koniec możesz zaszyfrować swoją replikację za pomocą protokołu SSL. W poprzednim poście na blogu wyjaśniono, jak można to zrobić i jaki może to mieć wpływ na wydajność replikacji.
Jeśli zdecydowałeś się na użycie replikacji Galera w obu centrach danych, powyższe sugestie mają również zastosowanie w tym przypadku. Jeśli chodzi o SSL, wcześniej pisaliśmy na blogu o tym, jak szyfrować ruch replikacji Galera. Aby uzyskać pełniejsze rozwiązanie, możesz chcieć zaszyfrować wszystkie połączenia bazy danych z aplikacji klienckich i dowolnej infrastruktury zarządzania/monitorowania.
Konfigurowanie nowej infrastruktury
Po uzyskaniu łączności musisz zacząć budować nową infrastrukturę. W tym celu prawdopodobnie użyjesz xtrabackup lub mariabackup. Kuszące może być połączenie migracji z aktualizacją MySQL, w końcu w nowej lokalizacji konfigurujesz zupełnie nowe środowisko. Nie polecamy tego robić. Sama migracja do nowej infrastruktury jest na tyle znacząca, że połączenie jej z inną poważną zmianą zwiększa złożoność i ryzyko. Dotyczy to również innych rzeczy – chcesz podejść krok po kroku do zmian. Tylko zmieniając rzeczy pojedynczo, możesz zrozumieć skutki zmian i ich wpływ na obciążenie pracą – jeśli wprowadziłeś więcej niż jedną zmianę w danym czasie, nie możesz mieć pewności, która z nich jest odpowiedzialna za daną (nowe ) zachowanie, które zaobserwowałeś.
Gdy masz nową instancję MySQL działającą w nowym centrum danych, musisz ją podporządkować węzłowi w starym centrum danych — aby zapewnić, że dane w obu centrach danych pozostaną zsynchronizowane. Będzie to przydatne, gdy będziesz przygotowywać się do ostatniego przełączenia. To także dobry sposób na zapewnienie, że nowe środowisko poradzi sobie z obciążeniem zapisu.
Kolejnym krokiem będzie zbudowanie kompletnej infrastruktury scenicznej w nowej lokalizacji oraz wykonanie testów i benchmarków. Jest to bardzo ważny krok, którego nie należy pomijać – problem polega na tym, że jako administrator danych musisz zrozumieć przepustowość swojej infrastruktury. Kiedy zmieniasz dostawcę, rzeczy również się zmieniają. Nowy sprzęt/maszyny wirtualne są szybsze lub wolniejsze. Na instancję przypada mniej lub więcej pamięci. Musisz ponownie zrozumieć, w jaki sposób Twoje obciążenie będzie pasować do sprzętu, którego będziesz używać. W tym celu prawdopodobnie użyjesz Percona Playback lub pt-log-player, aby odtworzyć niektóre z rzeczywistych zapytań w systemie pomostowym. Będziesz chciał przetestować wydajność i upewnić się, że jest na poziomie, który jest dla Ciebie akceptowalny. Chcesz również wykonać wszystkie standardowe testy akceptacyjne, które uruchamiasz na swoich nowych wydaniach - tylko po to, aby potwierdzić, że wszystko jest gotowe i działa. Ogólnie rzecz biorąc, wszystkie aplikacje powinny być zbudowane w taki sposób, aby nie opierały się na konfiguracji sprzętowej i bieżącej konfiguracji. Ale coś mogło się przemknąć i Twoja aplikacja może zależeć od niektórych poprawek konfiguracji lub rozwiązań sprzętowych, których nie masz w nowym środowisku.
Wreszcie, gdy będziesz zadowolony ze swoich testów, będziesz chciał zbudować infrastrukturę gotową do produkcji. Po wykonaniu tej czynności możesz uruchomić kilka testów tylko do odczytu w celu ostatecznej weryfikacji. To byłby ostatni krok przed przełączeniem.
Przejście
Po wykonaniu wszystkich tych testów i po uznaniu infrastruktury za gotową do produkcji, ostatnim krokiem jest odcięcie ruchu ze starej infrastruktury.
Mówiąc globalnie, jest to złożony proces, ale kiedy patrzymy na warstwę bazy danych, jest to mniej więcej to samo, co standardowe przełączanie awaryjne — coś, co mogłeś robić wiele razy w przeszłości. Omówiliśmy to szczegółowo we wcześniejszym poście, w skrócie kroki to:zatrzymaj ruch, upewnij się, że jest zatrzymany, poczekaj, aż aplikacja zostanie przeniesiona do nowego centrum danych (rekordy DNS zmieniają się lub nie), wykonaj kilka testów dymu, aby upewnić się wszystko wygląda dobrze, uruchom transmisję na żywo, obserwuj uważnie przez chwilę.
To przełączenie będzie wymagało pewnego przestoju, jak widać. Problem polega na upewnieniu się, że mamy spójny stan w starej i nowej witrynie. Jeśli chcemy to zrobić bez przestojów, musielibyśmy skonfigurować replikację master-master. Powodem jest to, że gdy odświeżamy DNS i przenosimy sesje ze starej witryny do nowej, oba systemy będą używane w tym samym czasie - aż wszystkie sesje zostaną przekierowane do nowej witryny. W międzyczasie wszelkie zmiany w nowej witrynie muszą zostać odzwierciedlone w starej witrynie.
Korzystanie z Galera Cluster, jak opisano w tym poście na blogu, może być również sposobem na synchronizację danych między dwiema witrynami.
Zdajemy sobie sprawę, że jest to bardzo krótki opis procesu migracji danych. Mamy nadzieję, że wystarczy wskazać dobry kierunek i pomóc określić, jakich dodatkowych informacji należy szukać.
