Migrowanie lokalnego programu MySQL do usługi Azure Database for MySQL: optymalizacja
Optymalizacja baz danych MySQL po migracji ze środowisk lokalnych do usługi Azure Database for MySQL jest niezbędna do maksymalizacji wydajności i wydajności. W tym artykule omówiono kluczowe strategie i najlepsze rozwiązania dotyczące optymalizowania baz danych w środowisku platformy Azure. Możesz mieć pewność, że bazy danych działają w szczytowym potencjale, koncentrując się na wydajności zapytań, indeksowaniu, alokacji zasobów i dostrajaniu konfiguracji. Ten przewodnik zawiera szczegółowe informacje i techniki potrzebne do identyfikowania i rozwiązywania wąskich gardeł wydajności, używania zaawansowanych funkcji platformy Azure i uzyskiwania optymalnej wydajności bazy danych. Niezależnie od tego, czy chcesz zwiększyć czas odpowiedzi, zwiększyć skalowalność, czy zmniejszyć koszty operacyjne, ten artykuł zawiera wiedzę, aby zoptymalizować bazy danych MySQL na platformie Azure.
Wymagania wstępne
Migrowanie lokalnego programu MySQL do usługi Azure Database for MySQL: Post Migration Management
Monitorowanie wydajności sprzętu i zapytań
Oprócz dzienników inspekcji i aktywności wydajność serwera można również monitorować za pomocą metryk platformy Azure. Metryki platformy Azure są udostępniane z jednej minuty, a alerty można skonfigurować na ich podstawie. Aby uzyskać więcej informacji, zapoznaj się z tematem Monitorowanie w usłudze Azure Database for MySQL , aby uzyskać szczegółowe informacje na temat rodzaju metryk, które można monitorować.
Jak wspomniano wcześniej, metryki monitorowania, takie jak cpu_percent lub memory_percent, mogą być ważne podczas podejmowania decyzji o uaktualnieniu warstwy bazy danych. Stale wysokie wartości mogą wskazywać, że konieczne jest uaktualnienie warstwy.
Ponadto jeśli procesor cpu i pamięć nie wydają się być problemem, administratorzy mogą eksplorować opcje oparte na bazie danych, takie jak indeksowanie i modyfikacje zapytań pod kątem niskiej wydajności zapytań.
Aby znaleźć zapytania o niskiej wydajności, uruchom następujące polecenie:
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where Category == 'MySqlSlowLogs'
| project TimeGenerated, LogicalServerName\_s,
event\_class\_s, start\_time\_t , q uery\_time\_d,
sql\_text\_s| top 5 by query\_time\_d desc
Szczegółowe informacje o wydajności zapytań
Oprócz podstawowych aspektów monitorowania serwera platforma Azure udostępnia narzędzia do monitorowania wydajności zapytań aplikacji. Poprawianie lub ulepszanie zapytań może prowadzić do znacznego zwiększenia przepływności zapytań. Użyj narzędzia Szczegółowe informacje o wydajności zapytań, aby przeanalizować najdłużej działające zapytania i określić, czy istnieje możliwość buforowania tych elementów, jeśli są deterministyczne w określonym okresie, lub zmodyfikuj zapytania, aby zwiększyć wydajność.
slow\_query\_log
Można je ustawić tak, aby pokazywać wolne zapytania w plikach dziennika MySQL (wartość domyślna to WYŁĄCZONE). long\_query\_time
Parametr serwera może powiadamiać użytkowników o długich czasach zapytań (wartość domyślna to 10 sekund).
Uaktualnianie warstwy
Za pomocą witryny Azure Portal można skalować między elementami z General Purpose
i Memory Optimized
. W przypadku wybrania Basic
warstwy nie ma możliwości uaktualnienia warstwy do General Purpose
lub Memory Optimized
nowszej. Można jednak użyć innych technik do przeprowadzenia migracji/uaktualnienia do nowego wystąpienia usługi Azure Database for MySQL.
Przykładowy skrypt, który migruje z warstwy podstawowa do innej warstwy serwera, zapoznaj się z tematem Upgrade from Basic to General Purpose or Memory Optimized tiers in Azure Database for MySQL (Uaktualnianie z warstwy Podstawowa do warstwy Ogólnego przeznaczenia lub Zoptymalizowane pod kątem pamięci w usłudze Azure Database for MySQL).
Skalowanie serwera
W ramach warstwy można skalować rdzenie i pamięć do minimalnych i maksymalnych limitów dozwolonych w tej warstwie. Jeśli monitorowanie pokazuje ciągłe maksymalne wykorzystanie procesora CPU lub pamięci, wykonaj kroki skalowania w górę w celu spełnienia wymagań.
Przenoszenie regionów
Przeniesienie bazy danych do innego regionu platformy Azure zależy od podejścia i architektury. W zależności od podejścia może to spowodować przestoje systemu.
Zalecany proces jest taki sam jak użycie replik do odczytu na potrzeby trybu failover konserwacji. Jednak w porównaniu z metodą planowanej konserwacji wymienionej powyżej szybkość przejścia w tryb failover jest szybsza, gdy warstwa trybu failover została zaimplementowana w aplikacji. Aplikacja powinna być wyłączona tylko przez kilka chwil podczas procesu pracy w trybie failover repliki do odczytu. Więcej szczegółów znajduje się w sekcji Ciągłość działalności biznesowej i odzyskiwanie po awarii.
Scenariusz ii wojny światowej
Użytkownicy biznesowi i aplikacji WWI wyrazili wysoki poziom emocji co do możliwości skalowania bazy danych na żądanie. Zainteresowali się również użyciem szczegółowych informacji o wydajności zapytań, aby ustalić, czy należy rozwiązać problem z długotrwałą wydajnością zapytań.
Zdecydowali się na korzystanie z serwera repliki do odczytu w przypadku potencjalnych scenariuszy trybu failover lub tylko do odczytu.
Zespół ds. migracji, współpracując z inżynierami platformy Azure, skonfigurował zapytania KQL w celu monitorowania potencjalnych problemów z wydajnością serwera MySQL. Zapytania KQY zostały skonfigurowane z alertami w celu problemów z zdarzeniami e-mail dla bazy danych i zespołu konferencyjnego.
Wybrali na razie monitorowanie potencjalnych problemów i zaimplementowanie książek runbook usługi Azure Automation w późniejszym czasie, w razie potrzeby, w celu zwiększenia wydajności operacyjnej.
Lista kontrolna optymalizacji
Monitorowanie pod kątem wolnych zapytań.
Okresowo przeglądaj pulpit nawigacyjny szczegółowych informacji o wydajności.
Korzystanie z monitorowania w celu podejmowania decyzji dotyczących uaktualniania warstwy i skalowania.
Rozważ zmianę w zakresie przenoszenia regionów użytkowników lub aplikacji.