Określanie potrzeb skalowania serwera usługi Azure Database for MySQL

Ukończone

Jeśli chodzi o ustalanie rozmiaru zasobów obliczeniowych, rozważ, czy istniejące i prognozowane użycie jest dobrze w ramach pojemności. Wymagane informacje można uzyskać, monitorując podstawowe metryki wydajności, takie jak użycie procesora CPU i pamięci RAM. Może być możliwe użycie dziennika wolnych zapytań w celu identyfikowania i optymalizowania słabo wykonywanych zapytań oraz rozwiązania problemu z wydajnością bez skalowania rozmiaru obliczeniowego. Należy również monitorować wydajność operacji we/wy, aby upewnić się, że odczyty i zapisy bazy danych nie są wąskim gardłem wydajności. Inną opcją efektywnego zwiększenia dostępnej pojemności w głównej bazie danych jest aprowizowania repliki do odczytu w celu przesunięcia obciążenia zapytań.

Monitorowanie metryk wydajności bazy danych

Witryna Azure Portal przedstawia dostęp do wielu metryk , których można użyć do monitorowania wydajności bazy danych. Na przykład można zwizualizować procent użycia procesora CPU przez serwer elastyczny.

Zrzut ekranu przedstawiający metryki przedstawiające wykorzystanie procesora CPU.

Ponieważ wykorzystanie procesora CPU zbliża się do 100%, wydajność bazy danych znacznie spada. W związku z tym, jeśli wykorzystanie procesora CPU na serwerze elastycznym jest stale powyżej 50%, rozważ zwiększenie rozmiaru obliczeniowego.

Metryki wydajności można wyświetlić w skoroszycie przeglądu monitorowania. Aby uzyskać dostęp do skoroszytu przeglądu, wykonaj następujące kroki:

  1. W portalu Azure, po lewej stronie, w sekcji Monitorowanie dla elastycznego serwera bazy danych MySQL na platformie Azure, wybierz pozycję Skoroszyty.

    Zrzut ekranu przedstawiający sekcję monitorowania zawierającą listę skoroszytów.

  2. Wybierz skoroszyt Przegląd . Zobaczysz wykresy przedstawiające połączenia, użycie procesora CPU i pamięci oraz inne metryki, jak pokazano na poniższym zrzucie ekranu.

    Zrzut ekranu przedstawiający skoroszyt przeglądu monitorowania.

Oprócz analizowania tych metryk można wyświetlić diagnostykę serwera w celu uzyskania wglądu w wydajność na panelu Dzienniki serwera elastycznego.

Zrzut ekranu panelu Dzienniki pokazującego selektor zapytań.

Oprócz tych metryk i dzienników można również monitorować dziennik powolnych zapytań, aby przechwytywać szczegółowe informacje o zapytaniach o długotrwałym działaniu. Te informacje mogą ujawniać istniejące wolne zapytania dotyczące optymalizacji i można skonfigurować alerty w celu natychmiastowego wykrywania przyszłych regresji wydajności zapytań w celu ograniczenia ryzyka.

Aby włączyć funkcję dziennika wolnych zapytań, na stronie skojarzonej z serwerem elastycznym wybierz pozycję Dzienniki serwera, a następnie zaznacz pola wyboru "Włącz" i "Dzienniki wolnych zapytań".

Zrzut ekranu przedstawiający stronę portalu Azure, aby włączyć dzienniki serwera zapytań wolnych.

Po włączeniu rejestrowania wolnych zapytań można wyświetlić szczegółowe informacje o wydajności zapytań przy użyciu analizy dzienników lub skoroszytów wizualizacji. Aby uzyskać dostęp do szczegółowych informacji o wydajności zapytań, wykonaj te same kroki co powyżej, ale wybierz pozycję Szczegółowe informacje o wydajności zapytań zamiast pozycji Przegląd.

Zobaczysz kilka wizualizacji, w tym pięć najdłuższych zapytań lub podsumowanie wolnych zapytań, jak pokazano na poniższym zrzucie ekranu.

Zrzut ekranu z pięciu najdłuższych zapytań i podsumowanie powolnych zapytań.

Dostrajanie parametrów wydajności serwera

Parametry serwera MySQL można skonfigurować pod kątem optymalizacji wydajności na podstawie monitorowania. Można na przykład zwiększyć wartość innodb_buffer_pool_size , aby zachować więcej danych tabeli w pamięci i zapisać odczyty na dysku. Możesz zwiększyć innodb_log_file_size wartość , aby zmniejszyć aktywność opróżniania punktu kontrolnego puli kosztem wolniejszego odzyskiwania po awarii.

Jeśli okaże się, że połączenia aplikacji są kolejkowane, a obciążenie serwera jest akceptowalne, możesz zwiększyć liczbę maksymalnych połączeń, aby umożliwić większą równoległość.

Aby zmodyfikować parametry serwera, przejdź do witryny Azure Portal dla serwera elastycznego MySQL i przejdź do sekcji Parametry serwera . Wprowadź nazwę parametru w pasku wyszukiwania lub przeglądaj przez Najlepsze lub Wszystkie obsługiwane parametry serwera.

Eksplorowanie i włączanie funkcji IOPS autoskalowania

Usługa Azure Database for MySQL ma dwa sposoby przydzielania pojemności we/wy dysku: wstępnie aprowizowane operacje we/wy a "automatycznie skalowane" operacje we/wy na sekundę.

Wstępnie przydzielone IOPS może być korzystniejsze, gdy obciążenie bazy danych jest przewidywalne i nie ma nagłych wzrostów. Serwer otrzymuje podstawową liczbę zapewnionych operacji we/wy na sekundę, i można przydzielić dodatkową liczbę operacji we/wy na sekundę (do maksymalnego rozmiaru obliczeniowego), przechodząc do sekcji Obliczenia + przechowywanie:

Zrzut ekranu przedstawiający panel ustawień umożliwiający dodanie dodatkowych wstępnie przydzielonych operacji we/wy na sekundę (IOPS).

Jeśli wystąpi skok, wydajność serwera może tymczasowo obniżyć się, jeśli operacje we/wy przekraczają przydzieloną wartość. Jednak pojemność i koszty są przewidywalne.

Funkcja automatycznego skalowania operacji we/wy na sekundę jest tworzona pod kątem nieprzewidywalnego, zmiennego lub rosnącego ruchu bazy danych. Po włączeniu tej funkcji operacje we/wy na sekundę są skalowane dynamicznie, więc ręczne dostosowanie nie jest wymagane do optymalizacji kosztów ani wydajności w miarę wahań przepływu pracy. W związku z tym użycie funkcji Automatycznego skalowania operacji we/wy na sekundę obsługuje nieprzewidywalne wzrosty obciążenia w sposób niewidoczny i płacisz tylko za zużyte operacje, a nie za nieużywaną pojemność.

W przypadku istniejącego serwera elastycznego MySQL możesz włączyć funkcję Autoscale IOPS w portalu Azure, wybierając pozycję Obliczenia i magazyn:

Zrzut ekranu przedstawiający opcje tworzenia dla automatycznego skalowania IOPS.

Uwaga

Podczas tworzenia serwera można również włączyć funkcję automatycznego skalowania operacji we/wy na sekundę.

Monitorowanie liczby operacji we/wy na sekundę

Monitorowanie operacji we/wy na sekundę pozwala określić, jak blisko wystąpienia jest maksymalna liczba operacji we/wy na sekundę, jeśli używasz wstępnie aprowizowanej liczby operacji we/wy na sekundę lub maksymalnego rozmiaru obliczeniowego, jeśli używasz funkcji operacji we/wy na sekundę autoskalowania.

Aby monitorować wydajność IOPS, przejdź do karty Metryki w sekcji Monitorowanie lub do karty Przegląd jeśli chcesz wyświetlić wydajność IOPS wraz z innymi typowymi metrykami.

Zrzut ekranu przedstawiający monitorowanie bloku przeglądu.

W WingTip Toys, ponieważ przewidujesz duży wzrost ruchu w nieprzewidywalnym czasie w miarę wdrażania kampanii marketingowej, chcesz uniknąć ryzyka braku możliwości obsługi zamówień przychodzących. Chcesz również uniknąć płacenia za maksymalną pojemność, jeśli jej nie potrzebujesz. Wybierz opcję użycia funkcji IOPS autoskalowania, a nie wstępnie aprowizowania operacji we/wy na sekundę, która wymaga ręcznego dodawania większej liczby operacji we/wy na sekundę zgodnie z potrzebami. Takie podejście równoważy efektywność kosztową dzięki skalowalności na żądanie.

Aprowizuj replikę do odczytu

Aprowizujesz repliki do odczytu w celu odciążania zapytań tylko do odczytu do oddzielnej bazy danych, co zmniejsza obciążenie głównej bazy danych aplikacji.

Aby aprowizować replikę do odczytu, w witrynie Azure Portal na stronie skojarzonej z serwerem elastycznym wybierz pozycję Replikacja, a następnie wybierz pozycję Dodaj replikę.

Zrzut ekranu przedstawiający przycisk dodaj replikę.

Po utworzeniu repliki do odczytu można skonfigurować nazwę serwera repliki oraz jej ustawienia obliczeniowe i magazynu. Nie można zmienić niektórych ustawień, takich jak uwierzytelnianie, które są dziedziczone z serwera podstawowego.

Zrzut ekranu przedstawiający dodawanie repliki.

W witrynie Wingtip Toys zespół ds. nauki o danych i narzędzia do raportowania mogą teraz wykonywać zapytania dotyczące serwera repliki do odczytu, zmniejszając obciążenie głównej bazy danych aplikacji i usuwając konieczność ograniczania analizy lub ograniczania zapytań poza godzinami pracy.