Migrowanie lokalnego programu MySQL do usługi Azure Database for MySQL: plany bazowe wydajności

Ustanawianie punktów odniesienia wydajności ma kluczowe znaczenie w migrowaniu baz danych MySQL ze środowisk lokalnych do usługi Azure Database for MySQL. W tym artykule opisano znaczenie punktów odniesienia wydajności, zapewniając szczegółowy przewodnik dotyczący mierzenia i analizowania bieżącej wydajności bazy danych. Dzięki zrozumieniu istniejących metryk wydajności można ustawić realistyczne oczekiwania i zidentyfikować obszary poprawy podczas procesu migracji. Ten przewodnik zawiera wiedzę na temat tworzenia dokładnych punktów odniesienia wydajności, zapewnienia, że zmigrowane bazy danych spełniają lub przekraczają bieżące poziomy wydajności w środowisku platformy Azure. Niezależnie od tego, czy chcesz zoptymalizować wydajność zapytań, zwiększyć skalowalność, czy zapewnić spójne środowisko użytkownika, ten artykuł zawiera szczegółowe informacje potrzebne do osiągnięcia celów wydajności.

Wymagania wstępne

Migrowanie lokalnego programu MySQL do usługi Azure Database for MySQL: plany testów

Omówienie

Zrozumienie istniejącego obciążenia MySQL jest jednym z najlepszych inwestycji, które można wykonać w celu zapewnienia pomyślnej migracji. Doskonała wydajność systemu zależy od odpowiedniego sprzętu i doskonałego projektowania aplikacji. Elementy, takie jak procesor CPU, pamięć, dysk i sieć, muszą mieć rozmiar i odpowiednio skonfigurować pod kątem przewidywanego obciążenia. Sprzęt i konfiguracja są częścią równania wydajności systemu. Deweloper musi zrozumieć obciążenie zapytań bazy danych i najdroższe zapytania do wykonania. Skupienie się na najdroższych zapytaniach może znacząco wpłynąć na ogólne metryki wydajności.

Tworzenie planów bazowych wydajności zapytań jest niezbędne dla projektu migracji. Punkty odniesienia wydajności mogą służyć do weryfikowania konfiguracji strefy docelowej platformy Azure dla zmigrowanych obciążeń danych. Większość systemów działa 24/7 i ma różne szczytowe czasy ładowania. Ważne jest, aby przechwytywać szczytowe obciążenia dla punktu odniesienia. Metryki są przechwytywane kilka razy. W dalszej części dokumentu zapoznamy się z parametrami serwera źródłowego i sposobem, w jaki są one niezbędne do ogólnego obrazu punktu odniesienia wydajności. Parametry serwera nie powinny być pomijane podczas projektu migracji.

Narzędzia

Poniżej przedstawiono narzędzia służące do zbierania metryk serwera i informacji o obciążeniu bazy danych. Użyj przechwyconych metryk, aby określić odpowiednią warstwę usługi Azure Database for MySQL i skojarzone opcje skalowania.

• Telemetria mySQL Enterprise: to niefree, narzędzie enterprise edition może udostępniać posortowaną listę najdroższych zapytań, metryk serwera, operacji we/wy plików i informacji o topologii

• Percona Monitoring and Management (PMM) : najlepsze rozwiązanie do monitorowania bazy danych typu open source. Pomaga to zmniejszyć złożoność, zoptymalizować wydajność i poprawić bezpieczeństwo środowisk baz danych o znaczeniu krytycznym dla działania firmy, niezależnie od wdrożonej lokalizacji.

Parametry serwera

Domyślne konfiguracje serwera MySQL mogą nie obsługiwać odpowiednio obciążenia. W programie MySQL istnieje mnóstwo parametrów serwera, ale w większości przypadków zespół ds. migracji powinien skupić się na garstki. Następujące parametry powinny być oceniane w środowiskach źródłowych i docelowych. Nieprawidłowe konfiguracje mogą mieć wpływ na szybkość migracji. Ponownie sprawdzimy te parametry po wykonaniu kroków migracji.

• innodb_buffer_pool_size: Duża wartość zapewnia, że zasoby w pamięci są używane jako pierwsze przed użyciem operacji we/wy dysku. Typowe wartości wahają się od 80% do 90% dostępnej pamięci. Na przykład system z 8 GB pamięci powinien przydzielić 5–6 GB dla rozmiaru puli.

• innodb_log_file_size: Dzienniki ponownego tworzenia zapewniają szybkie, trwałe zapisy. Ta transakcyjna kopia zapasowa jest pomocna podczas awarii systemu. Począwszy od innodb_log_file_size = 512M (dając 1 GB dzienników redo) powinno dać dużo miejsca na zapisy. Aplikacje intensywnie korzystające z zapisu korzystające z programu MySQL 5.6 lub nowszego powinny zaczynać się od innodb_log_file_size = 4G.

• max_connections: ten parametr może pomóc złagodzić Too many connections błąd. Wartość domyślna to 151 połączeń. Użycie puli połączeń na poziomie aplikacji jest preferowane, ale konfiguracja połączenia serwera może również wymagać zwiększenia.

• innodb_file_per_table: to ustawienie informuje innoDB, czy powinno przechowywać dane i indeksy w udostępnionej przestrzeni tabel lub w oddzielnym pliku ibd dla każdej tabeli. Posiadanie pliku na tabelę umożliwia serwerowi odzyskanie miejsca, gdy tabele zostaną porzucone, obcięte lub ponownie utworzone. Bazy danych zawierające wiele tabel nie powinny używać tabeli na konfigurację pliku. Od wersji MySQL 5.6 wartość domyślna to WŁĄCZONE. Wcześniejsze wersje bazy danych powinny ustawić konfigurację na WŁ przed załadowaniem danych. To ustawienie dotyczy tylko nowo utworzonych tabel.

• innodb_flush_log_at_trx_commit: domyślne ustawienie jednego oznacza, że innoDB jest w pełni zgodna ze standardem ACID. Ta konfiguracja transakcji o niższym ryzyku może mieć znaczne obciążenie w systemach z powolnymi dyskami z powodu dodatkowych synchronizacji wymaganych do opróżnienia każdej zmiany do dzienników ponownego wykonania. Ustawienie parametru na 2 jest nieco mniej niezawodne, ponieważ zatwierdzone transakcje zostaną opróżnione do dzienników ponownego utworzenia tylko raz na sekundę. Ryzyko może być dopuszczalne w niektórych sytuacjach głównych i jest to dobra wartość dla repliki. Wartość 0 pozwala na lepszą wydajność systemu, ale serwer bazy danych jest porównany do utraty niektórych danych podczas awarii. Dolna linia polega na użyciu wartości 0 tylko dla repliki.

• innodb_flush_method: to ustawienie określa sposób opróżniania danych i dzienników na dysk. Należy używać O_DIRECT w przypadku obecności sprzętowego kontrolera RAID z chronioną baterią pamięci podręcznej zapisu. Użyj fdatasync (wartość domyślna) dla innych scenariuszy.

• innodb_log_buffer_size: to ustawienie jest rozmiarem buforu dla transakcji, które nie zostały jeszcze zatwierdzone. Wartość domyślna (1 MB) jest akceptowalna. Transakcje z dużymi polami obiektów blob/tekstu mogą szybko wypełnić bufor i wyzwolić dodatkowe obciążenie we/wy. Spójrz na zmienną Innodb_log_waits stanu i jeśli nie ma wartości 0, zwiększ wartość innodb_log_buffer_size.

• query_cache_size: Pamięć podręczna zapytań jest dobrze znanym wąskim gardłem, które można zobaczyć podczas umiarkowanej współbieżności. Wartość początkowa powinna być ustawiona na 0, aby wyłączyć pamięć podręczną, na przykład query_cache_size = 0. Jest to ustawienie domyślne w programie MySQL 5.6 lub nowszym.

• log_bin: to ustawienie umożliwia rejestrowanie binarne. Włączenie rejestrowania binarnego jest obowiązkowe, jeśli serwer ma działać jako wzorzec replikacji.

• server_id: to ustawienie jest unikatowe dla serwerów tożsamości w topologii replikacji.

• expire_logs_days: to ustawienie określa, ile dni dzienniki binarne będą automatycznie czyszczone.

• skip_name_resolve: użytkownik do rozpoznawania nazwy hosta klienta. Jeśli serwer DNS działa wolno, połączenie działa wolno. Podczas wyłączania rozpoznawania nazw instrukcje GRANT muszą używać tylko adresów IP. Aby użyć adresu IP, należy ponownie użyć wszystkich poprzednich instrukcji GRANT.

Uruchom następujące polecenie, aby wyeksportować parametry serwera do pliku w celu przejrzenia. Korzystając z prostego analizowania, dane wyjściowe mogą ponownie zastosować te same parametry serwera po migracji, jeśli jest to konieczne, na serwerze usługi Azure Database for MySQL. Dokumentacja konfigurowanie parametrów serwera w usłudze Azure Database for MySQL przy użyciu witryny Azure Portal.

mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt

Domyślne zainstalowane parametry serwera MySQL 5.5.60 można znaleźć w dodatku.

Przed rozpoczęciem migracji wyeksportuj ustawienia konfiguracji źródłowej bazy danych MySQL. Porównaj te wartości z ustawieniami wystąpienia strefy docelowej platformy Azure po migracji. Jeśli jakiekolwiek ustawienia zostały zmodyfikowane z domyślnego wystąpienia docelowej strefy docelowej platformy Azure, upewnij się, że są one ustawione z powrotem po migracji. Ponadto użytkownik migracji powinien sprawdzić, czy parametry serwera można ustawić przed migracją.

Aby uzyskać listę parametrów serwera, których nie można skonfigurować, zapoznaj się z tematem Niekonfigurowalne parametry serwera.

Ruch wychodzący i Ruch przychodzący

Parametry źródłowego i docelowego serwera MySQL muszą być modyfikowane dla każdego odpowiedniego narzędzia do migracji danych i ścieżki, aby obsługiwać najszybszy możliwy ruch wychodzący i przychodzący. W zależności od narzędzia parametry mogą być różne. Na przykład narzędzie, które wykonuje migrację równolegle, może wymagać większej liczby połączeń między źródłem a obiektem docelowym a narzędziem jednowątkowym.

Przejrzyj wszystkie parametry limitu czasu, które mogą mieć wpływ na zestawy danych. Są to:

• connect_timeout

• wait_timeout

Ponadto przejrzyj wszystkie parametry, które mają wpływ na maksimum:

• max_allowed_packet

Scenariusz ii wojny światowej

WWI przejrzyła obciążenie bazy danych konferencji i ustaliła, że ma niewielkie obciążenie. Mimo że serwer w warstwie Podstawowa będzie działać dla nich, nie chciał wykonać pracy później, aby przeprowadzić migrację do innej warstwy. Wdrażany serwer będzie ostatecznie hostował inne obciążenia danych MySQL, więc wybrali warstwę General Performance .

Podczas przeglądania bazy danych MySQL okazało się, że serwer MySQL 5.5 działa z domyślnymi parametrami serwera ustawionymi podczas początkowej instalacji.

Następny krok