Amazon, no cóż. Koń jaki jest, każdy widzi. Pamięci na instancjach mało, zwykłe EBS’y są koszmarnie wolne, rejony padają co parę miesięcy (szczególnie mój ulubiony US East). Przesadzam, fakt, ale pracując z większą ilością instancji w Amazonie trudno nie narzekać od czasu do czasu. Faktem jest też to, że w pewnych sytuacjach Amazon błyszczy.

Przykład następujący. Klaster MySQL z dużymi (rzędu 700 GB- 1TB) bazami. Niektóre z tabel zajmują po paręset GB. Potrzebujemy wykonać kilka ALTERów na takie właśnie tabele. Dodanie indeksu w takim środowisku stanowi pewne wyzwanie – jeśli ALTER zajmie nam 12 godzin, to replikacja będzie miała także dwunastogodzinny lag. Z oczywistych względów nie jest to rozwiązanie do zastosowania w produkcji. Można to obejść przenosząc ruch na inne slave w klastrze, uruchomić ALTER, poczekać aż replikacja się załapie, przenieść ruch z powrotem, przy czym najpierw trzeba mieć wolne zasoby na przejęcie dodatkowego obciążenia na całe 12 godzin. Można próbować wykorzystać pt-online-schema-change bądź facebookowy odpowiednik, tyle że w tym wypadku modyfikacja tabeli będzie trwała nie 12 a przynajmniej 24h (często będzie to znacznie dłużej – jeśli slave zacznie lagować i pt-osc będzie czekał aż się replikacja ustatkuje). Do tego pt-online-schema-change ma swoje ograniczenia. Mogą pojawić się kłopoty jeśli np. tabela będzie zawierała klucze obce.
Kolejnym rozwiązaniem będzie dostawienie nowego serwera fizycznego, wykonanie kopii danych z MySQL, puszczenie ALTER, wykorzystanie tych danych do odtworzenia po kolei serwerów z klastra. Podstawowym problemem będzie tu czas. Czas potrzebny na dostawienie serwera fizycznego, czas potrzebny na przegranie 1TB przy pomocy xtrabackupu bądź innego narzędzia.

W przypadku Amazonu operacja jest miła i przyjemna. Robimy snapshot slave. Uruchamiamy kolejną instancję w oparciu o ten właśnie backup. Replikacja powinna się ładnie podłączyć do reszty klastra. Uruchamiamy nasz ALTER i czekamy dwanaście godzin plus czas potrzebny replikacji na nadrobienie zaległości. Wyłączamy MySQL. Robimy snapshot. Wykorzystujemy ten snapshot ze zmodyfikowaną tabelą do odbudowy pozostałych slave w klastrze. Jeśli mamy możliwość przeniesienia ruchu na inny serwer (w sensie że mamy zapas mocy na serwerach), to możemy to zrobić. Cała operacja sprowadza się do kilkunastu minut na wyłączenie instancji, podmontowanie świeżych EBS zawierających już zmodyfikowane danem uruchomienie instancji. Jeśli reszta serwerów w klastrze nie obsłuży nowego ruchu, tworzymy po prostu kolejny slave z nowymi danymi i przenosimy ruch na niego. Jedyną bardziej problematyczną operacją jest failover z aktywnego mastera na jeden ze slave (bo mastera też musimy chwilowo wyłączyć żeby podmienić dane).

Całość jest szybka, stosunkowo miła i przyjemna. Zysk czasowy jest znaczny, bo zrobienie snapshotu z 1TB to powinno być ok. kilkadziesiąt minut (zwykłe przegranie 1TB po sieci 1 Gbps to kilka godzin). Reszta operacji jest szybka – wyłączenie/odmontowanie EBS/zamontowanie EBS/włączenie instancji nie powinno zająć więcej niż 20 – 30 minut. Dodatkowym plusem będzie fakt, że w niektórych sytuacjach (jeśli wszystkie instancje w klastrze wykorzystują EBS’y z pIOPS), możemy znacznie przyspieszyć proces modyfikacji tabel stosując po prostu szybsze EBS albo większą instancję.

Jak widać, chmura jest elastyczna i to się czasem bardzo przydaje. Jasne, korzystając z chmury Amazonu musimy się liczyć z faktem, że instancje będą się restartować, EBS’y będą sprawiać problemy, strefy dostępności będą niedostępne, ale to, że możemy szybko i prosto modyfikować naszą infrastrukturę w zależności od naszych potrzeb, jest ogromną zaletą.