Czy chcesz zacząć korzystać z najpopularniejszej na świecie bazy danych typu open source i zastanawiasz się, jak skonfigurować hosting MySQL? Tak wielu domyślnie korzysta z Amazon RDS, gdy MySQL działa wyjątkowo dobrze w chmurze Azure. Chociaż Microsoft Azure oferuje rozwiązanie zarządzane, Azure Database, rozwiązanie to ma pewne poważne ograniczenia, o których należy wiedzieć przed migracją wdrożeń MySQL. W tym poście przedstawiamy najlepszy sposób hostowania MySQL na platformie Azure, w tym rozwiązania zarządzane, typy instancji, replikację o wysokiej dostępności, kopie zapasowe i typy dysków, które można wykorzystać do optymalizacji wydajności bazy danych w chmurze.
MySQL DBaaS a samozarządzający MySQL
Pierwszą rzeczą do rozważenia przy rozważaniu między samozarządzaniem a rozwiązaniem MySQL Database-as-a-Service (DBaaS) są dostępne zasoby wewnętrzne. Jeśli to czytasz, prawdopodobnie znasz już ogrom zadań operacyjnych związanych z utrzymaniem wdrożenia produkcyjnego, ale dla szybkiego podsumowania, jest to udostępnianie, wycofywanie, konfiguracje master-slave, kopie zapasowe, skalowanie, uaktualnienia, rotacje dzienników, łatanie systemu operacyjnego i monitorowanie, żeby wymienić tylko kilka.
Wewnętrzny ekspert MySQL lub zespół administratorów baz danych, w zależności od rozmiaru aplikacji, z pewnością poradzi sobie z nimi w Twojej organizacji, ale pojawia się pytanie, na czym chcesz skoncentrować wysiłki Twojego zespołu . Wiele osób decyduje się na przejście do bazy danych MySQL DBaaS, aby zautomatyzować te czasochłonne zadania, aby mogli bardziej skupić się na rozwoju i optymalizacji baz danych swoich aplikacji. Dobrym przykładem może być powolna analiza zapytań. Podczas gdy prawie każdy DBaaS oferuje narzędzie MySQL Slow Query Analyzer, które pomaga zidentyfikować problematyczne zapytania, zadanie to nadal wymaga ludzkich umiejętności i intuicji, aby określić, jak zoptymalizować te zapytania, co ma wpływ na wydajność ich aplikacji.
Niezależnie od tego, czy jesteś firmą typu start-up, czy firmą z fortuną 500, wiele organizacji decyduje się na wykorzystanie DBaaS do optymalizacji czasu swojego DBA, przy tych samych typach i rozmiarach również zdecydować się na trzymanie się wewnętrznego samozarządzania. W przypadku wielu przedsiębiorstw decyzja w dużej mierze sprowadza się do dostosowania i kontroli. Dlatego ostrzegamy przed domyślnym korzystaniem z Azure Database lub jej konkurenta AWS, Amazon RDS, ponieważ nie pozwalają one zachować dostępu superużytkownika MySQL, a nawet dostępu SSH do swoich maszyn. Ponadto możliwość dostosowania konfiguracji wdrożenia jest bardzo ograniczona, na przykład typy instancji, pamięć RAM, rozmiar dysku lub IOPS, których możesz użyć. Poniżej dowiesz się więcej o najlepszych typach instancji i dyskach, a także możesz zapoznać się z porównaniem dostawców MySQL, aby poznać zalety i ograniczenia czterech najlepszych zarządzanych rozwiązań MySQL, ScaleGrid, Compose, Azure Database i Amazon RDS.
Wdrożenie wysokiej dostępności
Jeśli wdrażasz w środowisku produkcyjnym, zawsze powinieneś skonfigurować MySQL jako wdrożenie typu master-slave. Wdrożenia autonomiczne to pojedynczy węzeł bez replikacji i tak naprawdę powinny być używane tylko w środowiskach programistycznych lub testowych. Dzięki wdrożeniom typu master-slave możesz skonfigurować wysoką dostępność, więc jeśli jeden z twoich węzłów ulegnie awarii, możesz przejść awaryjnie na urządzenie podrzędne z zerowym czasem przestoju. Jest to zazwyczaj skonfigurowane jako 3-węzłowy master-slave-slave lub 2+1 węzłów master-slave-quorum. Zaletą korzystania z kworum jest to, że jest to tańsza alternatywa, ale wadą jest to, że masz tylko 2 węzły przenoszące dane, ponieważ drugi działa jako węzeł kworum w celu określenia najlepszego przebiegu przełączania awaryjnego. Jeśli Twoja aplikacja może czytać z urządzenia podrzędnego, musisz wykonać skalowanie odczytu, aby zwracały te same dane z woluminu klastra z minimalnym opóźnieniem.
Najlepszy sposób na hostowanie MySQL w Azure CloudKliknij, aby tweetować
W przypadku korzystania z konfiguracji typu master-slave MySQL zalecamy skonfigurowanie replikacji półsynchronicznej, aby poprawić integralność danych dzięki redundancji danych. Gwarantuje to, że gdy zatwierdzenie zostanie pomyślnie zwrócone, dane będą znajdować się zarówno w urządzeniu nadrzędnym, jak i podrzędnym, więc w przypadku awarii centrum danych, urządzenie główne MySQL może przełączyć się w tryb podrzędny bez utraty danych. Możesz to zrobić za pomocą replikacji asynchronicznej lub półsynchronicznej i dowiedz się więcej na ten temat w naszym poście na blogu MySQL High Availability Explained – Part II.
Jak więc skonfigurować wysoką dostępność dla MySQL na Azure? Musimy dystrybuować nasze wystąpienia podrzędne w różnych strefach dostępności platformy Azure (AZ). Dlatego chcemy się upewnić, że wybieramy region platformy Azure, który ma co najmniej 3 AZ, umieszczając każdą instancję w innym AZ. Robimy to, ponieważ gwarancje dostępności dotyczą wszystkich AZ, więc jeśli jedna strefa ulegnie awarii, Twoja baza danych aplikacji będzie nadal mogła pozostać online przez pozostałe 2 AZ. Strefy dostępności są dość nowe na platformie Azure, więc jeśli pracujesz w regionie, który nie oferuje stref od A, możesz użyć zestawów dostępności. Są one nieco słabsze niż AZ, ale upewnij się, że jesteś wdrożony w różnych domenach i stojakach, aby chronić Cię przed potencjalną awarią. Istnieje również możliwość wdrożenia w różnych regionach, ale jest to bardziej skomplikowana konfiguracja, dlatego zalecamy skontaktowanie się z omówieniem przed wdrożeniem.
Sieci wirtualne Azure
Najlepszym sposobem ochrony bazy danych przed Internetem jest wdrożenie jej w prywatnej podsieci, aby upewnić się, że nie zostanie ujawniona. Platforma Azure ułatwia konfigurację dzięki wykorzystaniu sieci wirtualnej (VNET), którą można skonfigurować dla serwerów MySQL. Dzięki Azure VNET for MySQL możesz skonfigurować bezpieczną komunikację między serwerami, Internetem, a nawet lokalną siecią chmury prywatnej. Są one zazwyczaj skonfigurowane do komunikacji w jednej sieci, ale jeśli potrzebujesz połączyć więcej niż jeden region, możesz utworzyć wiele sieci wirtualnych do komunikacji przez Virtual Network Peering.
Dodatkowo możesz zarządzać kontrolą dostępu do MySQL za pomocą reguł Network Security Groups (NSG) bez konieczności zajmowania się białymi listami adresów IP. Nie jest to dostępne za pośrednictwem Azure Database for MySQL, ale zarówno sieć VNET, jak i NSG można skonfigurować za pomocą naszych planów MySQL Bring Your Own Cloud (BYOC) na platformie Azure, w których możesz hostować swoje klastry za pośrednictwem własnego konta w chmurze.
Typy instancji Azure
Kolejnym ważnym aspektem do rozważenia jest wydajność instancji MySQL w chmurze publicznej. Chmura Azure oferuje wiele typów instancji, których można używać do hostingu MySQL, w tym Es2 v3, Ds2, v2 i Ls4.
Zalecamy rozpoczęcie od typów instancji zoptymalizowanych pod kątem pamięci, ponieważ bazy danych wymagają dużej ilości pamięci RAM i szukają możliwie największej szybkości dysku, aby uzyskać najlepszą wydajność. Seria Es2 jest zazwyczaj dobrym punktem wyjścia dla większości aplikacji obciążeń MySQL. Stamtąd możesz przeprowadzić testy wydajności, aby sprawdzić, czy potrzebujesz więcej procesora. W takim przypadku zrównoważone typy instancji lub typy instancji intensywnie korzystających z procesora mogą lepiej służyć Twoim potrzebom MySQL, na przykład typy instancji Dv3. Twoje testy wydajności mogą również wykazać, że potrzebujesz więcej we/wy (wejścia/wyjścia), możesz przejść do typu instancji intensywnie korzystających z dysku.
Jeśli planujesz wykorzystywać platformę Azure jako dostawcę chmury MySQL przez następne 1-3 lata i utrzymywać dość spójne konfiguracje wdrażania, możesz również rozważyć wystąpienia zarezerwowane. Są to zasadniczo instancje przedpłacone, które pozwalają uzyskać znaczne oszczędności kosztów hostingu MySQL. Średnio możesz zaoszczędzić około 20% do 30% na instancjach zarezerwowanych na jeden rok i od 40% do 50% na instancjach zarezerwowanych na 3 lata.
Typy dysków Azure
Pierwszą decyzją, jaką należy podjąć, aby wybrać typ dysku Azure dla wdrożeń MySQL, jest wybór dysku zarządzanego lub dysku niezarządzanego. Dyski niezarządzane to starsze dyski, które oferuje platforma Azure, na których należy skonfigurować konto magazynu, zamapować dysk na konto magazynu oraz monitorować użycie i limity IOPS dla tego konta magazynu. Zdecydowanie zalecamy korzystanie z dysków zarządzanych, a jeśli nadal wdrażasz z dyskami niezarządzanymi, rozważ przejście na zarządzane.
Środowiska deweloperskie/testowe MySQL:dyski standardowe
Istnieje wiele typów dysków zarządzanych dostępnych za pośrednictwem platformy Azure, przy czym domyślnie są to dyski standardowe. Dyski standardowe mogą obsługiwać do 500 IOPS (operacje wejścia/wyjścia na sekundę) i są dobre do operacji programistycznych i testowych, ponieważ można je dynamicznie zmieniać, ale nie powinny być używane do wdrożeń produkcyjnych MySQL.
Wdrożenia produkcyjne MySQL:dyski Premium
W przypadku serwerów produkcyjnych MySQL zdecydowanie zalecamy korzystanie z dysków Premium platformy Azure. Istnieje wiele różnych dysków premium, z których możesz wybierać. Dla każdego dysku premium możesz wybrać najlepszy rozmiar, a każdy rozmiar jest dostarczany z różnymi aprowizowanymi IOPS, dzięki czemu możesz wybrać ten, który najlepiej odpowiada potrzebom Twojej aplikacji.
Wdrożenia produkcyjne MySQL:lokalny dysk SSD
Lokalne dyski SSD Azure to wydajna alternatywa dla dysków premium, zazwyczaj najlepiej nadająca się do dużych klastrów. Lokalne dyski SSD zapewniają znacznie wyższą wydajność we/wy i najlepszą przepustowość na platformie Azure. Mają jednak wadę, ponieważ są dyskami efemerycznymi, a nie trwałym magazynem, więc jeśli zatrzymasz instancję, dane znikną. Zalecamy serię Ls v2, która jest bardzo szybka, ale pamiętaj, że procesor jest naprawdę słaby, co może powodować wąskie gardła.
Kopie zapasowe MySQL na platformie Azure
Najlepszym sposobem tworzenia kopii zapasowych danych MySQL na platformie Azure jest korzystanie z migawek dysków zarządzanych. Migawka to wersja dysku przeznaczona tylko do odczytu do punktu w czasie. Te kopie zapasowe można czytać, kopiować lub usuwać, ale pamiętaj, że nie można ich modyfikować. Dobrym pomysłem jest wykonywanie pełnych kopii zapasowych, aby wszystkie bazy danych, użytkownicy i ustawienia zostały zapisane w instancji na wypadek, gdyby kiedykolwiek zajdzie potrzeba odzyskania bazy danych MySQL. Dobrym pomysłem jest również zaszyfrowanie migawek kopii zapasowych, aby kopia zapasowa mogła zostać przywrócona tylko na komputerze, na którym wykonano kopię zapasową.
Kopie zapasowe MySQL spowodują dodatkowe opłaty za przechowywanie danych Azure, chyba że korzystasz z kompleksowego rozwiązania MySQL na Azure, takiego jak nasze plany hostingu dedykowanego w ScaleGrid. Aby kontrolować koszty, warto zautomatyzować tworzenie kopii zapasowych za pomocą dostosowywanego harmonogramu, który pozwala skonfigurować częstotliwość tworzenia kopii zapasowych, maksymalną liczbę kopii zapasowych do zachowania oraz cel tworzenia kopii zapasowych. To oczywiście pomaga również zapewnić regularne tworzenie kopii zapasowych danych MySQL na wypadek utraty danych we wdrożeniu produkcyjnym, dzięki czemu można szybko odzyskać dane za pomocą ostatniej kopii zapasowej.
Jeśli masz pytania dotyczące najlepszego sposobu hostowania MySQL na Azure, zostaw nam komentarz poniżej lub skontaktuj się z nami pod adresem support@scalegrid. ja. Możesz także rozpocząć bezpłatny 30-dniowy okres próbny, aby poznać zalety korzystania z w pełni zarządzanej usługi MySQL w celu poprawy wydajności wdrożeń.
