Najlepsze rozwiązania dotyczące optymalnej wydajności usługi Azure Database for MySQL — serwer elastyczny

2024-12-18

Dowiedz się, jak uzyskać najlepszą wydajność podczas pracy z serwerem elastycznym usługi Azure Database for MySQL. W miarę dodawania nowych możliwości do platformy będziemy nadal udoskonalać nasze zalecenia w tej sekcji.

Bliskość fizyczna

Upewnij się, że aplikacja i baza danych są wdrażane w tym samym regionie. Szybkie sprawdzenie przed rozpoczęciem dowolnego przebiegu testu porównawczego wydajności polega na określeniu opóźnienia sieci między klientem a bazą danych przy użyciu prostego zapytania SELECT 1.

Gdy zasoby, takie jak aplikacja internetowa i skojarzona z nią baza danych, działają w różnych regionach, mogą wystąpić zwiększone opóźnienia w komunikacji między tymi zasobami. Innym możliwym skutkiem ubocznym posiadania aplikacji i bazy danych w oddzielnych regionach jest powiązanie z kosztami transferu danych wychodzących.

Aby zwiększyć wydajność i niezawodność aplikacji w ramach wdrożenia zoptymalizowanego pod kątem kosztów, zdecydowanie zaleca się, aby usługa aplikacji internetowej i zasób serwera elastycznego usługi Azure Database for MySQL znajdowały się w tym samym regionie i strefie dostępności. Ta kolokacja jest najlepsza w przypadku aplikacji, które są wrażliwe na opóźnienia, a także zapewnia najlepszą przepływność, ponieważ zasoby są ściśle sparowane.

Przyspieszona sieć

Użyj przyspieszonej sieci dla serwera aplikacji, jeśli używasz maszyny wirtualnej platformy Azure, platformy Azure Kubernetes lub usługi App Services. Przyspieszona sieć umożliwia wirtualizację we/wy pojedynczego katalogu głównego (SR-IOV) na maszynę wirtualną, co znacznie poprawia wydajność sieci. Ta ścieżka o wysokiej wydajności pomija hosta ze ścieżki danych, zmniejszając opóźnienia, zakłócenia i wykorzystanie procesora CPU do użycia z najbardziej wymagającymi obciążeniami sieciowymi w obsługiwanych typach maszyn wirtualnych.

Wydajność połączenia

Ustanawianie nowego połączenia jest zawsze kosztownym i czasochłonnym zadaniem. Gdy aplikacja żąda połączenia z bazą danych, określa priorytet alokacji istniejących bezczynnych połączeń bazy danych zamiast tworzenia nowego. Poniżej przedstawiono kilka opcji dobrych rozwiązań dotyczących połączeń:

ProxySQL: użyj serwera ProxySQL, który zapewnia wbudowane buforowanie połączeń i równoważenie obciążenia obciążenia do wielu replik do odczytu zgodnie z wymaganiami na żądanie z wszelkimi zmianami w kodzie aplikacji.
Serwer proxy danych Heimdall: alternatywnie możesz również użyć serwera proxy danych Heimdall, neutralnego dla dostawcy rozwiązania serwera proxy. Obsługuje buforowanie zapytań i podział odczytu/zapisu z wykrywaniem opóźnień replikacji. Możesz również zapoznać się z tym, jak przyspieszyć wydajność bazy danych MySQL za pomocą serwera proxy Heimdall.
Trwałe lub długotrwałe połączenie: jeśli aplikacja ma krótkie transakcje lub zapytania zwykle z czasem < wykonywania 5–10 ms, zastąp krótkie połączenia trwałymi połączeniami. Zamiana krótkich połączeń na połączenia trwałe wymaga tylko drobnych zmian w kodzie, ale ma ona duży wpływ na poprawę wydajności w wielu typowych scenariuszach aplikacji. Pamiętaj, aby ustawić limit czasu lub zamknąć połączenie po zakończeniu transakcji.
Replika: jeśli używasz repliki, użyj serwera ProxySQL , aby zrównoważyć obciążenie między serwerem podstawowym i serwerem repliki pomocniczej z możliwością odczytu. Dowiedz się , jak skonfigurować serwer ProxySQL.

Buforowanie połączeń

Buforowanie połączeń to mechanizm, który zarządza tworzeniem i alokacją połączeń bazy danych oraz chroni bazę danych przed wzrostami połączeń. Rozważ buforowanie połączeń, jeśli aplikacja otwiera wiele połączeń w stosunkowo krótkim czasie, a połączenia są krótkotrwałe. Te typy połączeń mogą wystąpić, na przykład o wielkości setek lub tysięcy na sekundę, a czas potrzebny na ustanowienie i zamknięcie połączeń jest znaczący w porównaniu z łącznym okresem istnienia połączenia.

Jeśli platforma deweloperska aplikacji nie obsługuje buforowania połączeń, zamiast tego użyj serwera proxy połączenia, takiego jak serwer proxy ProxySQL lub Heimdall, między aplikacją a serwerem bazy danych.

Obsługa skalowania połączeń

Typowym podejściem do skalowania aplikacji internetowych w celu spełnienia zmieniającego się zapotrzebowania jest dodawanie i usuwanie serwerów aplikacji. Każdy serwer aplikacji może używać puli połączeń z bazą danych. Takie podejście powoduje wzrost całkowitej liczby połączeń na serwerze bazy danych w odniesieniu do liczby serwerów aplikacji. Jeśli na przykład serwer bazy danych ma 10 serwerów aplikacji, a każdy z nich jest skonfigurowany dla 100 połączeń bazy danych, zapewni to 1000 połączeń z bazą danych. Jeśli obciążenie aplikacji jest skalowane z powodu większej aktywności użytkownika lub w godzinach szczytu, a dodatkowe 50 serwerów aplikacji zostanie dodanych, połączenia z bazą danych będą łącznie wynosić 6000. Zazwyczaj większość z tych połączeń będzie bezczynna po zduplikowanych przez serwery aplikacji. Ponieważ bezczynne połączenia zużywają zasoby (pamięć i procesor CPU), co może mieć wpływ na skalowalność bazy danych.

Dodatkowe potencjalne wyzwania obejmują obsługę całkowitej liczby połączeń z serwerem bazy danych. Jest to dyktowane przez liczbę serwerów aplikacji połączonych z serwerem bazy danych, z których każdy tworzy własny zestaw połączeń. W tych scenariuszach rozważ dostosowanie pul połączeń na serwerach aplikacji. Spróbuj zmniejszyć liczbę połączeń w każdej puli do dopuszczalnego minimum, aby upewnić się, że po stronie serwera bazy danych nie ma wężenia połączeń. Rozważmy to jako krótkoterminowy środek zaradczy, aby przeciwdziałać skutkom skalowania serwera aplikacji, a nie stałym rozwiązaniem w celu rozwiązania problemu wzrostu aplikacji.

W ramach długoterminowego rozwiązania należy wprowadzić serwer proxy połączenia, taki jak serwer proxy ProxySQL lub serwer proxy Heimdall, między serwerem bazy danych a serwerem aplikacji. Pomaga to, ponieważ serwer proxy będzie:

Ustanów połączenie z serwerem bazy danych z stałą liczbą połączeń.
Akceptowanie połączeń aplikacji i działanie jako bufor dla potencjalnych burz połączeń.

Serwery proxy mogą udostępniać inne funkcje, takie jak buforowanie zapytań, buforowanie połączeń, ponowne zapisywanie/routing zapytań i równoważenie obciążenia. Aby uzyskać jeszcze większą skalowalność, rozważ użycie wielu wystąpień serwera proxy.

Obsługa połączeń w celu zapewnienia odporności na uszkodzenia i szybszego odzyskiwania

Podczas projektowania aplikacji i środowiska pod kątem odporności na uszkodzenia i szybszego odzyskiwania należy wziąć pod uwagę, że w środowisku bazy danych prawdopodobnie wystąpią przerwy w połączeniu lub awarie sprzętu. Należy również pamiętać o konieczności wykonywania akcji operacyjnych, takich jak skalowanie rozmiarów wystąpień, stosowanie poprawek i ręczne przechodzenie w tryb failover.

Rozważmy na przykład scenariusz, w którym serwer bazy danych kończy tryb failover w ciągu minuty, ale aplikacja jest wyłączona przez kilka minut z powodu zbyt długiego czasu wygaśnięcia DNS po stronie aplikacji. W takich przypadkach po prostu zmniejszenie wartości czasu wygaśnięcia zapewni szybsze odzyskiwanie lub zintegrowanie serwera proxy połączenia między aplikacją a serwerem bazy danych może pomóc w obsłudze takich błędów.

Partycja

Gdy obciążenie produkcyjne używa bardzo dużych tabel, partycjonowanie to świetna metoda poprawy wydajności bazy danych i ułatwienia konserwacji. Partycjonowanie ułatwia zarządzanie dużymi tabelami. Takie podejście umożliwia efektywne dodawanie i usuwanie partycji w celu efektywnego zarządzania dużymi tabelami. Partycjonowanie może również pomóc w skalowaniu aparatu przez złagodzenie rywalizacji o strukturę wewnętrzną, taką jak wewnętrzne blokady na tabelę lub indeks (np. rozważ użycie btr_search_latch w usłudze InnoDB).

Dodając na przykład pięć partycji, zasadniczo dzielisz dużą tabelę z dużą aktywnością na pięć mniejszych, bardziej wydajnych tabel. Byłoby to pomocne przede wszystkim w przypadkach, w których główna operacja jest wyszukiwaniem kluczy podstawowych w tabeli, tak aby zapytania mogły korzystać z "oczyszczania partycji". Jednak partycjonowanie może również pomóc w zakresie skanowania tabel.

Chociaż partycjonowanie ma swoje zalety, ma również pewne ograniczenia, takie jak brak obsługi kluczy obcych w tabelach partycjonowanych, brak pamięci podręcznej zapytań itp. Pełną listę tych ograniczeń można znaleźć w podręczniku dokumentacji programu MySQL, zobacz rozdział Ograniczenia i ograniczenia dotyczące partycjonowania.

Segregowanie odczytów i zapisów

Większość aplikacji odczytuje przede wszystkim z bazy danych, a tylko niewielki procent interakcji obejmujących zapisy. Liczba aktywnych połączeń w podstawowej bazie danych obliczonej dla pul połączeń prawdopodobnie obejmuje ruch odczytu. Odciążanie jak największej liczby zapytań do replik do odczytu i oszczędzanie dostępu do podstawowego wystąpienia zapisywalnego zwiększa ilość ogólnej aktywności bazy danych wykonywanej przez serwery aplikacji bez zwiększania obciążenia podstawowej bazy danych. Jeśli nie uzyskujesz jeszcze dostępu do replik do odczytu co najmniej w przypadku dłuższych zapytań, takich jak raporty, rozważ natychmiastowe przeniesienie raportowania lub analizy do replik do odczytu.

Szersze użycie replik do odczytu może wymagać bardziej starannego rozważenia, ponieważ repliki nieco opóźniły się z powodu asynchronicznego charakteru replikacji. Znajdź jak najwięcej obszarów aplikacji, które mogą być obsługiwane z odczytami z replik z drobnymi zmianami kodu. Należy również zastosować tę metodę na wyższych poziomach dotyczących buforowania — obsługiwać więcej tylko do odczytu lub powoli zmieniać zawartość z dedykowanej warstwy buforowania, takiej jak usługa Azure Cache for Redis.

Skalowanie i fragmentowanie zapisu

W miarę upływu czasu aplikacje ewoluują i są dodawane nowe funkcje. Poza wygodą lub ogólną praktyką tabele są dodawane do podstawowej bazy danych. Aby obsługiwać rosnące obciążenia ruchu w bazie danych, zidentyfikuj obszary aplikacji, które można łatwo przenosić do oddzielnych baz danych i należy rozważyć dzielenie w poziomie lub dzielenie bazy danych w pionie.

Fragmentowanie w poziomie bazy danych działa przez utworzenie wielu kopii schematu aplikacji w oddzielnych bazach danych i rozdzielenie klientów i wszystkich skojarzonych danych na podstawie identyfikatora klienta, lokalizacji geograficznej lub innego atrybutu dla klienta lub dzierżawy. Działa to bardzo dobrze w przypadku aplikacji SaaS lub B2C, w których klienci indywidualni są małe, a obciążenie aplikacji wynika z zagregowanego użycia milionów klientów. Jednak trudniej jest korzystać z aplikacji B2B, w których klienci mają różne rozmiary, a indywidualni klienci mogą zdominować obciążenie ruchem dla określonego fragmentu.

Obciążenie podzielone w pionie przez funkcjonalne dzielenie bazy danych — przenoszenie oddzielnych domen aplikacji (lub mikrousług) do własnych baz danych. Spowoduje to rozłożenie obciążenia z podstawowej bazy danych na oddzielne bazy danych dla poszczególnych usług. Proste przykłady obejmują tabelę rejestrowania lub informacje o konfiguracji lokacji, które nie muszą znajdować się w tej samej bazie danych co mocno załadowana tabela zamówień. Bardziej skomplikowane przykłady obejmują przerywanie domen klientów i kont poza zamówieniami lub domenami realizacji. W niektórych przypadkach może to wymagać zmian w aplikacji, na przykład w celu zmodyfikowania kolejek zadań poczty e-mail lub zadań w tle, które mają być samodzielne i nie polegają na sprzężeniach z powrotem do klienta lub tabeli zamówień. Przeniesienie istniejących tabel i danych do nowej podstawowej bazy danych można wykonać za pomocą replik do odczytu usługi Azure Database for MySQL — serwer elastyczny oraz promować replikę i wskazywać części aplikacji na nowo utworzoną zapisywalną bazę danych. Nowo utworzona baza danych musi ograniczyć dostęp za pomocą pul połączeń, dostroić zapytania i rozłożyć obciążenie własnymi replikami, podobnie jak w przypadku oryginalnego podstawowego.

Konfiguracje importu danych

Wystąpienie można tymczasowo skalować do wyższego rozmiaru jednostki SKU przed rozpoczęciem operacji importowania danych, a następnie skalować je w dół po pomyślnym zaimportowaniu.
Dane można zaimportować z minimalnym przestojem przy użyciu migracji lokalnej bazy danych MySQL do usługi Azure Database for MySQL na potrzeby migracji w trybie online lub offline.

Rekomendacje dotyczące pamięci serwera elastycznego usługi Azure Database for MySQL

Najlepszym rozwiązaniem w zakresie wydajności serwera elastycznego usługi Azure Database for MySQL jest przydzielenie wystarczającej ilości pamięci RAM, aby zestaw roboczy znajdował się prawie całkowicie w pamięci.

Sprawdź, czy procent pamięci używany w osiągnięciu limitów przy użyciu metryk dla serwera elastycznego usługi Azure Database for MySQL.
Skonfiguruj alerty dotyczące takich liczb, aby upewnić się, że gdy serwer osiągnie limity, możesz wykonać monit o jego naprawienie. Na podstawie zdefiniowanych limitów sprawdź, czy skalowanie w górę jednostki SKU bazy danych — do wyższego rozmiaru obliczeniowego lub do lepszej warstwy cenowej, co skutkuje znaczącym wzrostem wydajności.
Skaluj w górę, aż liczby wydajności nie spadną dramatycznie po operacji skalowania. Aby uzyskać informacje na temat monitorowania metryk wystąpienia bazy danych, zobacz Azure Database for MySQL — elastyczne metryki bazy danych serwera.

Użyj rozgrzewki puli InnoDB

Po ponownym uruchomieniu wystąpienia serwera elastycznego usługi Azure Database for MySQL strony danych znajdujące się w magazynie są ładowane jako zapytania dotyczące tabel, co prowadzi do zwiększonego opóźnienia i wolniejszej wydajności podczas pierwszego wykonywania zapytań. Może to nie być akceptowalne w przypadku obciążeń wrażliwych na opóźnienia.

Użycie rozgrzewki puli InnoDB skraca okres rozgrzewki przez ponowne załadowanie stron dysku, które znajdowały się w puli przed ponownym uruchomieniem, a nie oczekiwaniem na operacje DML lub SELECT w celu uzyskania dostępu do odpowiednich wierszy.

Po ponownym uruchomieniu wystąpienia serwera elastycznego usługi Azure Database for MySQL można zmniejszyć okres rozgrzewki, co stanowi zaletę wydajności, konfigurując parametry serwera puli InnoDB. Usługa InnoDB zapisuje procent ostatnio używanych stron dla każdej puli podczas zamykania serwera i przywraca te strony podczas uruchamiania serwera.

Należy również pamiętać, że zwiększona wydajność jest kosztem dłuższego czasu uruchamiania serwera. Po włączeniu tego parametru oczekiwany jest czas uruchamiania i ponownego uruchamiania serwera w zależności od liczby operacji we/wy na sekundę aprowizowanej na serwerze.

Zalecamy testowanie i monitorowanie czasu ponownego uruchamiania, aby upewnić się, że wydajność uruchamiania/ponownego uruchamiania jest akceptowalna, ponieważ serwer jest niedostępny w tym czasie. Nie zaleca się używania tego parametru z mniejszą niż 1000 aprowizowaną operacją we/wy na sekundę (lub innymi słowy, gdy aprowizacja magazynu jest mniejsza niż 335 GB).

Aby zapisać stan puli podczas zamykania serwera, ustaw parametr innodb_buffer_pool_dump_at_shutdown serwera na ON. Podobnie ustaw parametr innodb_buffer_pool_load_at_startup serwera, aby ON przywrócić stan puli podczas uruchamiania serwera. Możesz kontrolować wpływ na czas uruchamiania/ponownego uruchamiania, obniżając i dostrajając wartość parametru innodb_buffer_pool_dump_pctserwera . Domyślnie ten parametr ma wartość 25.

Uwaga

Parametry rozgrzewania puli InnoDB są obsługiwane tylko w przypadku serwerów magazynu ogólnego przeznaczenia z maksymalnie 16 TB magazynu. Aby uzyskać więcej informacji, zobacz Opcje magazynu elastycznego serwera usługi Azure Database for MySQL.