Azure Database for MySQL — funkcje wydajności serwera elastycznego
Można utworzyć elastyczne serwery usługi Azure Database for MySQL na podstawie jednej z trzech warstw usług: z możliwością serii, ogólnego przeznaczenia i Krytyczne dla działania firmy. Warstwy usług zapewniają rosnący poziom mocy obliczeniowej i rozmiaru magazynu, a także obsługiwaną liczbę maksymalnych połączeń i operacji we/wy na sekundę (IOPS). Jeden serwer elastyczny MySQL może hostować kilka baz danych. Możesz monitorować metryki wydajności serwera elastycznego MySQL, takie jak użycie procesora CPU i pamięci, wydajność operacji we/wy, metryki zapytań i nie tylko, aby podejmować świadome decyzje dotyczące pojemności.
Rozmiar obliczeniowy: pamięć RAM i rdzenie
Każda z trzech warstw usług zapewnia różne bazowe jednostki SKU maszyn wirtualnych. Warstwa Z możliwością rozszerzenia używa maszyn wirtualnych serii B, warstwa Ogólnego przeznaczenia używa maszyn wirtualnych serii D, a warstwa Krytyczne dla działania firmy używa maszyn wirtualnych serii E. Używana seria maszyn wirtualnych określa liczbę rdzeni wirtualnych i pamięci RAM dostępnych na serwerze.
Po utworzeniu serwera można zmienić warstwę obliczeniową, rozmiar obliczeniowy i rozmiar magazynu. Zmiana warstwy obliczeniowej lub rozmiaru obliczeniowego wymaga ponownego uruchomienia, które zwykle trwa od jednej do dwóch minut. Zmiana rozmiaru magazynu nie wymaga ponownego uruchomienia.
W przypadku obciążeń nieprodukcyjnych (programistycznych, przejściowych, testowych itp.) należy rozważyć użycie serwerów opartych na warstwie Z możliwością serii, która zapewnia ekonomiczne rozwiązanie dla obciążeń, które nie korzystają stale z pełnego procesora CPU. W okresach niskiego użycia serwery korzystające z maszyn wirtualnych serii B gromadzą środki na użycie procesora CPU, które mogą być używane w okresach wysokiego użycia do "zwiększenia" wydajności powyżej punktu odniesienia. Jeśli punkt odniesienia jest zbyt wysoki lub istnieje zbyt wiele wzrostów użycia, rozważ uaktualnienie do warstwy Ogólnego przeznaczenia lub Krytyczne dla działania firmy, aby uniknąć obniżenia wydajności.
Rozmiary obliczeń warstwy usługi
Każda z trzech warstw usług zapewnia różne poziomy mocy obliczeniowej. Warstwa z możliwością rozszerzenia może obsługiwać maksymalnie 20 rdzeni wirtualnych, a warstwa Ogólnego przeznaczenia może obsługiwać maksymalnie 64 rdzenie wirtualne, z obsługą maksymalnie 96 rdzeni wirtualnych, warstwa Krytyczne dla działania firmy zapewnia najwyższy poziom mocy obliczeniowej. Warstwa Krytyczne dla działania firmy zapewnia również maszyny wirtualne serii Ev5, które do 30% więcej QPS i 50% mniejsze opóźnienia niż maszyny wirtualne serii Ev4.
Operacje we/wy na sekundę: wstępnie aprowizowana a autoskalowanie
Liczba operacji odczytu i zapisu, które można wykonać na sekundę, jest określana jako liczba operacji we/wy magazynu (operacje we/wy na sekundę). Wyższe ustawienia operacji we/wy na sekundę zapewniają lepszą wydajność magazynu: większe jednoczesne operacje odczytu/zapisu powodują szybsze pobieranie danych, trwałość danych, aktualizacje indeksu i ogólną wydajność bazy danych. Jeśli ustawienia liczby operacji we/wy na sekundę są zbyt niskie, baza danych może napotkać opóźnienia przetwarzania i obniżoną wydajność. Jeśli jednak ustawienia liczby operacji we/wy na sekundę są zbyt wysokie, koszty mogą wzrosnąć bez realizacji jakichkolwiek ulepszeń wydajności.
Dzięki usłudze Azure Database for MySQL — serwer elastyczny możesz wstępnie aprowizować operacje we/wy na sekundę lub użyć funkcji IOPS automatycznego skalowania.
W przypadku wstępnie aprowizowania operacji we/wy przydzielisz określoną liczbę operacji we/wy na sekundę, aby zapewnić spójną i przewidywalną wydajność, co sprawdza się, jeśli obciążenie nie zbliża się do progu, w którym operacje we/wy stają się ograniczane. Mimo że zawsze można przydzielić dodatkowe operacje we/wy na sekundę w miarę wzrostu zapotrzebowania na obciążenia, wymaga to interwencji ręcznej.
Po włączeniu funkcji Automatycznego skalowania liczby operacji we/wy na sekundę operacje we/wy na sekundę skaluj na żądanie na podstawie aktywności obciążenia i płacisz na podstawie użycia. W miarę zwiększania się obciążenia serwer bezproblemowo skaluje wydajność operacji we/wy, umożliwiając wystąpieniu obsługę obciążeń skokowo bez płacenia za nieużywaną pojemność, gdy ruch jest niski.
W obu przypadkach liczba operacji we/wy na sekundę nie może przekroczyć maksymalnej liczby operacji we/wy na sekundę serwera. Aby uzyskać informacje na temat maksymalnej liczby operacji we/wy na sekundę według rozmiaru obliczeniowego, zobacz dokumentację obliczeniową i magazynową.
Repliki do odczytu
W miarę zwiększania ruchu bazy danych można skalować jej pojemność w poziomie lub "w poziomie" (liczba węzłów obliczeniowych) albo pionowo lub "w górę" (rozmiar węzłów obliczeniowych). Repliki do odczytu zapewniają skalowanie w poziomie.
Replika do odczytu to kopia bazy danych tylko do odczytu, która pozostaje zsynchronizowana przy użyciu binarnej replikacji dziennika (binlog) mySQL. W miarę zwiększania się aplikacji muszą skalować zasoby obliczeniowe i magazynowe (na przykład bazę danych). Skalowanie składników aplikacji jest uproszczone przez aprowizowanie nowych maszyn wirtualnych przy użyciu usługi Azure Kubernetes Service (AKS), zestawów skalowania maszyn wirtualnych i usługi App Service. W miarę zwiększania skali zasobów obliczeniowych i przechowywanych danych zwiększają one obciążenie bazy danych, co często stanowi wąskie gardło w architekturze aplikacji.
Użycie repliki do odczytu umożliwia przekierowanie operacji tylko do odczytu do pomocniczych baz danych, dzięki czemu serwer podstawowy obsługuje operacje odczytu/zapisu. Usługa Azure Database for MySQL udostępnia zarządzane repliki do odczytu. Serwer źródłowy można replikować do maksymalnie 10 replik. Może to pomóc w przypadkach użycia, takich jak raportowanie i analiza, które często wysyłają zapytania o duże ilości danych.
Używanie repliki do odczytu jest szczególnie przydatne, gdy z jednego powodu lub innych zapytań nie można używać indeksów. Może to być niepraktyczne, a nawet zakłócające dodawanie indeksów dla wszystkich wzorców zapytań, ponieważ nakłada dodatkowe obciążenie na serwerze (przetwarzanie, operacje we/wy dysku, magazyn, czas transakcji itp.). Jeśli magazyn danych jest niedostępny lub potrzebujesz danych, które są nowsze niż cykl odświeżania, użycie repliki do odczytu to doskonały sposób uruchamiania "dużych" zapytań bez zakłócania krytycznych operacji odczytu/zapisu.
Repliki do odczytu nie są natychmiast synchroniczne w taki sam sposób, jak konfiguracja wysokiej dostępności. Repliki do odczytu nie powodują opóźnienia transakcyjnego skojarzonego z rozwiązaniem wysokiej dostępności, ale może wystąpić niewielkie opóźnienie, ponieważ dane docierają do repliki z podstawowej bazy danych.