Parametry serwera w usłudze Azure Database for MySQL

  • Artykuł

DOTYCZY: Azure Database for MySQL — pojedynczy serwer

Ważne

Pojedynczy serwer usługi Azure Database for MySQL znajduje się na ścieżce wycofania. Zdecydowanie zalecamy uaktualnienie do serwera elastycznego usługi Azure Database for MySQL. Aby uzyskać więcej informacji na temat migracji do serwera elastycznego usługi Azure Database for MySQL, zobacz Co się dzieje z usługą Azure Database for MySQL — pojedynczy serwer?

Ten artykuł zawiera zagadnienia i wskazówki dotyczące konfigurowania parametrów serwera w usłudze Azure Database for MySQL.

Co to są parametry serwera?

Aparat MySQL udostępnia wiele różnych zmiennych i parametrów serwera używanych do konfigurowania i dostrajania zachowania aparatu. Niektóre parametry można ustawiać dynamicznie w czasie wykonywania, podczas gdy inne są statyczne i wymagają ponownego uruchomienia serwera w celu zastosowania.

Usługa Azure Database for MySQL uwidacznia możliwość zmiany wartości różnych parametrów serwera MySQL przy użyciu witryny Azure Portal, interfejsu wiersza polecenia platformy Azure i programu PowerShell w celu dopasowania ich do potrzeb obciążenia.

Konfigurowalne parametry serwera

Lista obsługiwanych parametrów serwera stale rośnie. W witrynie Azure Portal użyj karty Parametry serwera, aby wyświetlić pełną listę i skonfigurować wartości parametrów serwera.

Zapoznaj się z poniższymi sekcjami, aby dowiedzieć się więcej na temat limitów kilku często aktualizowanych parametrów serwera. Limity są określane przez warstwę cenową i rdzenie wirtualne serwera.

Pule wątków

Program MySQL tradycyjnie przypisuje wątek dla każdego połączenia klienta. Wraz ze wzrostem liczby równoczesnych użytkowników występuje odpowiedni spadek wydajności. Wiele aktywnych wątków może znacząco wpływać na wydajność z powodu zwiększonego przełączania kontekstu, rywalizacji o wątki i nieprawidłowej lokalizacji pamięci podręcznych procesora CPU.

Pule wątków, funkcja po stronie serwera i różni się od buforowania połączeń, maksymalizuj wydajność, wprowadzając dynamiczną pulę wątków roboczych. Ta funkcja pozwala ograniczyć liczbę aktywnych wątków uruchomionych na serwerze i zminimalizować współczynnik zmian wątków. Pomaga to zapewnić, że wzrost liczby połączeń nie powoduje, że serwer zabraknie zasobów ani pamięci. Pule wątków są najbardziej wydajne w przypadku krótkich zapytań i obciążeń intensywnie korzystających z procesora CPU, takich jak obciążenia OLTP.

Aby uzyskać więcej informacji, zobacz Wprowadzenie do pul wątków w usłudze Azure Database for MySQL.

Uwaga

Pule wątków nie są obsługiwane w przypadku programu MySQL 5.6.

Konfigurowanie puli wątków

Aby włączyć pulę wątków, zaktualizuj thread_handling parametr serwera na pool-of-threads. Domyślnie ten parametr jest ustawiony na one-thread-per-connectionwartość , co oznacza, że program MySQL tworzy nowy wątek dla każdego nowego połączenia. Jest to parametr statyczny i wymaga ponownego uruchomienia serwera w celu zastosowania.

Można również skonfigurować maksymalną i minimalną liczbę wątków w puli, ustawiając następujące parametry serwera:

  • thread_pool_max_threads: Ta wartość ogranicza liczbę wątków w puli.
  • thread_pool_min_threads: Ta wartość określa liczbę wątków zarezerwowanych, nawet po zamknięciu połączeń.

Aby poprawić problemy z wydajnością krótkich zapytań w puli wątków, możesz włączyć wykonywanie wsadowe. Zamiast wracać do puli wątków natychmiast po uruchomieniu zapytania, wątki będą aktywne przez krótki czas, aby poczekać na następne zapytanie za pośrednictwem tego połączenia. Następnie wątek szybko uruchamia zapytanie, a po zakończeniu ten wątek czeka na następny. Ten proces będzie kontynuowany, dopóki całkowity czas spędzony nie przekroczy progu.

Zachowanie wykonywania wsadowego można określić przy użyciu następujących parametrów serwera:

  • thread_pool_batch_wait_timeout: Ta wartość określa czas oczekiwania wątku na przetworzenie innego zapytania.
  • thread_pool_batch_max_time: Ta wartość określa maksymalny czas, przez jaki wątek będzie powtarzał cykl wykonywania zapytań i czekał na następne zapytanie.

Ważne

Nie włączaj puli wątków w środowisku produkcyjnym, dopóki nie zostanie przetestowana.

log_bin_trust_function_creators

W usłudze Azure Database for MySQL dzienniki binarne są zawsze włączone ( log_bin parametr jest ustawiony na ONwartość ). Jeśli chcesz używać wyzwalaczy, zostanie wyświetlony błąd podobny do następującego: nie masz uprawnień ADMINISTRATORA i włączono rejestrowanie binarne (możesz użyć mniej bezpiecznej log_bin_trust_function_creators zmiennej).

Format rejestrowania binarnego jest zawsze wierszem, a wszystkie połączenia z serwerem zawsze używają rejestrowania binarnego opartego na wierszach. Rejestrowanie binarne oparte na wierszach pomaga zachować bezpieczeństwo, a rejestrowanie binarne nie może uszkodzić, dzięki czemu można bezpiecznie ustawić wartość log_bin_trust_function_creatorsTRUE.

innodb_buffer_pool_size

Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat tego parametru.

Serwery w magazynie ogólnego przeznaczenia w wersji 1 (obsługa do 4 TB)

Warstwa cenowa Rdzenie wirtualne Wartość domyślna (bajty) Minimalna wartość (bajty) Maksymalna wartość (bajty)
Podstawowy 1 872415232 134217728 872415232
Podstawowy 2 2684354560 134217728 2684354560
Ogólnego przeznaczenia 2 3758096384 134217728 3758096384
Ogólnego przeznaczenia 100 8053063680 134217728 8053063680
Ogólnego przeznaczenia 8 16106127360 134217728 16106127360
Ogólnego przeznaczenia 16 32749125632 134217728 32749125632
Ogólnego przeznaczenia 32 66035122176 134217728 66035122176
Ogólnego przeznaczenia 64 132070244352 134217728 132070244352
Optymalizacja pod kątem pamięci 2 7516192768 134217728 7516192768
Optymalizacja pod kątem pamięci 100 16106127360 134217728 16106127360
Optymalizacja pod kątem pamięci 8 32212254720 134217728 32212254720
Optymalizacja pod kątem pamięci 16 65498251264 134217728 65498251264
Optymalizacja pod kątem pamięci 32 132070244352 134217728 132070244352

Serwery w magazynie ogólnego przeznaczenia w wersji 2 (obsługa do 16 TB)

Warstwa cenowa Rdzenie wirtualne Wartość domyślna (bajty) Minimalna wartość (bajty) Maksymalna wartość (bajty)
Podstawowy 1 872415232 134217728 872415232
Podstawowy 2 2684354560 134217728 2684354560
Ogólnego przeznaczenia 2 7516192768 134217728 7516192768
Ogólnego przeznaczenia 100 16106127360 134217728 16106127360
Ogólnego przeznaczenia 8 32212254720 134217728 32212254720
Ogólnego przeznaczenia 16 65498251264 134217728 65498251264
Ogólnego przeznaczenia 32 132070244352 134217728 132070244352
Ogólnego przeznaczenia 64 264140488704 134217728 264140488704
Optymalizacja pod kątem pamięci 2 15032385536 134217728 15032385536
Optymalizacja pod kątem pamięci 100 32212254720 134217728 32212254720
Optymalizacja pod kątem pamięci 8 64424509440 134217728 64424509440
Optymalizacja pod kątem pamięci 16 130996502528 134217728 130996502528
Optymalizacja pod kątem pamięci 32 264140488704 134217728 264140488704

innodb_file_per_table

Program MySQL przechowuje tabelę InnoDB w różnych przestrzeniach tabel na podstawie konfiguracji podanej podczas tworzenia tabeli. Systemowa przestrzeń tabel to obszar przechowywania słownika InnoDB danych. Przestrzeń tabel dla pliku na tabelę zawiera dane i indeksy dla pojedynczej InnoDB tabeli i jest przechowywana w systemie plików we własnym pliku danych.

To zachowanie można kontrolować przy użyciu parametru innodb_file_per_table serwera. Ustawienie innodb_file_per_table przyczyn OFFInnoDB tworzenia tabel w systemowej przestrzeni tabel. InnoDB W przeciwnym razie tworzy tabele w przestrzeniach tabel dla plików na tabelę.

Uwaga

Można aktualizować innodb_file_per_table tylko w warstwach cenowych ogólnego przeznaczenia i zoptymalizowanych pod kątem pamięci w magazynie ogólnego przeznaczenia w wersji 2 i magazynu ogólnego przeznaczenia w wersji 1.

Usługa Azure Database for MySQL obsługuje 4 TB (co do wielkości) w jednym pliku danych w magazynie ogólnego przeznaczenia w wersji 2. Jeśli rozmiar bazy danych jest większy niż 4 TB, należy utworzyć tabelę w przestrzeni tabel innodb_file_per_table . Jeśli masz jeden rozmiar tabeli większy niż 4 TB, należy użyć tabeli partycji.

join_buffer_size

Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat tego parametru.

Warstwa cenowa Rdzenie wirtualne Wartość domyślna (bajty) Minimalna wartość (bajty) Maksymalna wartość (bajty)
Podstawowy 1 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Podstawowy 2 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Ogólnego przeznaczenia 2 262144 128 268435455
Ogólnego przeznaczenia 100 262144 128 536870912
Ogólnego przeznaczenia 8 262144 128 1073741824
Ogólnego przeznaczenia 16 262144 128 2147483648
Ogólnego przeznaczenia 32 262144 128 4294967295
Ogólnego przeznaczenia 64 262144 128 4294967295
Optymalizacja pod kątem pamięci 2 262144 128 536870912
Optymalizacja pod kątem pamięci 100 262144 128 1073741824
Optymalizacja pod kątem pamięci 8 262144 128 2147483648
Optymalizacja pod kątem pamięci 16 262144 128 4294967295
Optymalizacja pod kątem pamięci 32 262144 128 4294967295

max_connections

Warstwa cenowa Rdzenie wirtualne Wartość domyślna Minimalna wartość Wartość maksymalna
Podstawowy 1 50 10 50
Podstawowy 2 100 10 100
Ogólnego przeznaczenia 2 300 10 600
Ogólnego przeznaczenia 100 625 10 1250
Ogólnego przeznaczenia 8 1250 10 2500
Ogólnego przeznaczenia 16 2500 10 5000
Ogólnego przeznaczenia 32 5000 10 10 000
Ogólnego przeznaczenia 64 10 000 10 20000
Optymalizacja pod kątem pamięci 2 625 10 1250
Optymalizacja pod kątem pamięci 100 1250 10 2500
Optymalizacja pod kątem pamięci 8 2500 10 5000
Optymalizacja pod kątem pamięci 16 5000 10 10 000
Optymalizacja pod kątem pamięci 32 10 000 10 20000

Jeśli liczba połączeń przekroczy limit, może zostać wyświetlony błąd.

Napiwek

Aby efektywnie zarządzać połączeniami, warto użyć programu puli połączeń, takiego jak ProxySQL. Aby dowiedzieć się więcej na temat konfigurowania serwera ProxySQL, zobacz wpis w blogu Load balance read replicas using ProxySQL in Azure Database for MySQL (Równoważenie obciążenia replik do odczytu przy użyciu serwera ProxySQL w usłudze Azure Database for MySQL). Należy pamiętać, że serwer ProxySQL jest narzędziem społeczności typu open source. Jest ona obsługiwana przez firmę Microsoft na zasadzie najlepszych wysiłków.

max_heap_table_size

Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat tego parametru.

Warstwa cenowa Rdzenie wirtualne Wartość domyślna (bajty) Minimalna wartość (bajty) Maksymalna wartość (bajty)
Podstawowy 1 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Podstawowy 2 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Ogólnego przeznaczenia 2 16777216 16384 268435455
Ogólnego przeznaczenia 100 16777216 16384 536870912
Ogólnego przeznaczenia 8 16777216 16384 1073741824
Ogólnego przeznaczenia 16 16777216 16384 2147483648
Ogólnego przeznaczenia 32 16777216 16384 4294967295
Ogólnego przeznaczenia 64 16777216 16384 4294967295
Optymalizacja pod kątem pamięci 2 16777216 16384 536870912
Optymalizacja pod kątem pamięci 100 16777216 16384 1073741824
Optymalizacja pod kątem pamięci 8 16777216 16384 2147483648
Optymalizacja pod kątem pamięci 16 16777216 16384 4294967295
Optymalizacja pod kątem pamięci 32 16777216 16384 4294967295

query_cache_size

Pamięć podręczna zapytań jest domyślnie wyłączona. Aby włączyć pamięć podręczną zapytań, skonfiguruj query_cache_type parametr .

Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat tego parametru.

Uwaga

Pamięć podręczna zapytań jest przestarzała w wersji MySQL 5.7.20 i została usunięta w programie MySQL 8.0.

Warstwa cenowa Rdzenie wirtualne Wartość domyślna (bajty) Minimalna wartość (bajty) Wartość maksymalna
Podstawowy 1 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Podstawowy 2 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Ogólnego przeznaczenia 2 0 0 16777216
Ogólnego przeznaczenia 100 0 0 33554432
Ogólnego przeznaczenia 8 0 0 67108864
Ogólnego przeznaczenia 16 0 0 134217728
Ogólnego przeznaczenia 32 0 0 134217728
Ogólnego przeznaczenia 64 0 0 134217728
Optymalizacja pod kątem pamięci 2 0 0 33554432
Optymalizacja pod kątem pamięci 100 0 0 67108864
Optymalizacja pod kątem pamięci 8 0 0 134217728
Optymalizacja pod kątem pamięci 16 0 0 134217728
Optymalizacja pod kątem pamięci 32 0 0 134217728

lower_case_table_names

Parametr lower_case_table_name jest domyślnie ustawiony na 1 i można zaktualizować ten parametr w programach MySQL 5.6 i MySQL 5.7.

Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat tego parametru.

Uwaga

W programie MySQL 8.0 lower_case_table_name jest domyślnie ustawiona wartość 1 i nie można jej zmienić.

innodb_strict_mode

Jeśli wystąpi błąd podobny do Row size too large (> 8126), rozważ wyłączenie parametru innodb_strict_mode . Nie można modyfikować innodb_strict_mode globalnie na poziomie serwera. Jeśli rozmiar danych wierszy jest większy niż 8K, dane są obcinane bez powiadomienia o błędzie, co prowadzi do potencjalnej utraty danych. Dobrym pomysłem jest zmodyfikowanie schematu w celu dopasowania go do limitu rozmiaru strony.

Ten parametr można ustawić na poziomie sesji przy użyciu polecenia init_connect. Aby ustawić na innodb_strict_mode poziomie sesji, zapoznaj się z parametrem ustawienia, który nie ma na liście.

Uwaga

Jeśli masz serwer repliki do odczytu, ustawienie innodb_strict_mode na OFF poziomie sesji na serwerze źródłowym spowoduje przerwanie replikacji. Zalecamy przechowywanie parametru ustawionego na ON wartość , jeśli masz repliki do odczytu.

sort_buffer_size

Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat tego parametru.

Warstwa cenowa Rdzenie wirtualne Wartość domyślna (bajty) Minimalna wartość (bajty) Maksymalna wartość (bajty)
Podstawowy 1 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Podstawowy 2 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Ogólnego przeznaczenia 2 524288 32768 4194304
Ogólnego przeznaczenia 100 524288 32768 8388608
Ogólnego przeznaczenia 8 524288 32768 16777216
Ogólnego przeznaczenia 16 524288 32768 33554432
Ogólnego przeznaczenia 32 524288 32768 33554432
Ogólnego przeznaczenia 64 524288 32768 33554432
Optymalizacja pod kątem pamięci 2 524288 32768 8388608
Optymalizacja pod kątem pamięci 100 524288 32768 16777216
Optymalizacja pod kątem pamięci 8 524288 32768 33554432
Optymalizacja pod kątem pamięci 16 524288 32768 33554432
Optymalizacja pod kątem pamięci 32 524288 32768 33554432

tmp_table_size

Zapoznaj się z dokumentacją programu MySQL, aby dowiedzieć się więcej na temat tego parametru.

Warstwa cenowa Rdzenie wirtualne Wartość domyślna (bajty) Minimalna wartość (bajty) Maksymalna wartość (bajty)
Podstawowy 1 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Podstawowy 2 Nie można skonfigurować w warstwie Podstawowa Brak Brak
Ogólnego przeznaczenia 2 16777216 1024 67108864
Ogólnego przeznaczenia 100 16777216 1024 134217728
Ogólnego przeznaczenia 8 16777216 1024 268435456
Ogólnego przeznaczenia 16 16777216 1024 536870912
Ogólnego przeznaczenia 32 16777216 1024 1073741824
Ogólnego przeznaczenia 64 16777216 1024 1073741824
Optymalizacja pod kątem pamięci 2 16777216 1024 134217728
Optymalizacja pod kątem pamięci 100 16777216 1024 268435456
Optymalizacja pod kątem pamięci 8 16777216 1024 536870912
Optymalizacja pod kątem pamięci 16 16777216 1024 1073741824
Optymalizacja pod kątem pamięci 32 16777216 1024 1073741824

Rozgrzewka puli buforów InnoDB

Po ponownym uruchomieniu usługi Azure Database for MySQL strony danych, które znajdują się na dysku, są ładowane w miarę odpytania tabel. Prowadzi to do zwiększonego opóźnienia i wolniejszej wydajności pierwszego uruchomienia zapytań. W przypadku obciążeń, które są wrażliwe na opóźnienia, może się okazać, że ta niższa wydajność jest niedopuszczalna.

Możesz użyć InnoDB rozgrzewki puli buforów, aby skrócić okres rozgrzewki. Ten proces ponownie ładuje strony dysków, które znajdowały się w puli buforów przed ponownym uruchomieniem, zamiast czekać na operacje DML lub SELECT w celu uzyskania dostępu do odpowiednich wierszy. Aby uzyskać więcej informacji, zobacz Parametry serwera puli buforów InnoDB.

Jednak zwiększona wydajność jest kosztem dłuższego czasu uruchamiania serwera. Po włączeniu tego parametru oczekiwane jest zwiększenie czasu uruchamiania i ponownego uruchamiania serwera w zależności od liczby operacji we/wy na sekundę aprowizowanej na serwerze. Dobrym pomysłem jest przetestowanie i monitorowanie czasu ponownego uruchomienia, aby upewnić się, że wydajność uruchamiania lub ponownego uruchamiania jest akceptowalna, ponieważ serwer jest niedostępny w tym czasie. Nie używaj tego parametru, gdy liczba aprowizowanej liczby operacji we/wy na sekundę jest mniejsza niż 1000 operacji we/wy na sekundę (innymi słowy, gdy aprowizowana pamięć jest mniejsza niż 335 GB).

Aby zapisać stan puli buforów podczas zamykania serwera, ustaw parametr innodb_buffer_pool_dump_at_shutdown serwera na ONwartość . Podobnie ustaw parametr innodb_buffer_pool_load_at_startup serwera, aby ON przywrócić stan puli buforów podczas uruchamiania serwera. Wpływ uruchamiania lub ponownego uruchamiania można kontrolować, obniżając i dostrajając wartość parametru innodb_buffer_pool_dump_pctserwera . Domyślnie ten parametr ma wartość 25.

Uwaga

InnoDB Parametry rozgrzewania puli buforów 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 usługi Azure Database for MySQL.

time_zone

Podczas początkowego wdrażania serwer z uruchomioną usługą Azure Database for MySQL zawiera tabele systemów dla informacji o strefie czasowej, ale te tabele nie są wypełniane. Tabele można wypełnić, wywołując procedurę mysql.az_load_timezone składowaną z narzędzi takich jak wiersz polecenia MySQL lub MySQL Workbench. Aby uzyskać informacje na temat wywoływania procedur składowanych i ustawiania globalnych lub stref czasowych na poziomie sesji, zobacz Praca z parametrem strefy czasowej (Azure Portal) lub Praca z parametrem strefy czasowej (interfejs wiersza polecenia platformy Azure).

binlog_expire_logs_seconds

W usłudze Azure Database for MySQL ten parametr określa liczbę sekund oczekiwania usługi przed przeczyszczeniem pliku dziennika binarnego.

Dziennik binarny zawiera zdarzenia opisujące zmiany bazy danych, takie jak operacje tworzenia tabeli lub zmiany danych tabeli. Zawiera również zdarzenia dla instrukcji, które mogą potencjalnie wprowadzać zmiany. Dziennik binarny jest używany głównie do dwóch celów, replikacji i odzyskiwania danych.

Zazwyczaj dzienniki binarne są czyszczone, gdy tylko dojście jest wolne od usługi, kopii zapasowej lub zestawu replik. Jeśli istnieje wiele replik, dzienniki binarne czekają na najwolniejszą replikę, aby odczytać zmiany przed przeczyszczeniem. Jeśli chcesz, aby dzienniki binarne trwały dłużej, możesz skonfigurować parametr binlog_expire_logs_seconds. Jeśli ustawisz binlog_expire_logs_seconds0wartość , która jest wartością domyślną, zostanie ona przeczyszczona natychmiast po uwolnieniu dojścia do dziennika binarnego. Jeśli ustawisz wartość binlog_expire_logs_seconds większą niż 0, dziennik binarny będzie czyszczący tylko po upływie tego czasu.

W przypadku usługi Azure Database for MySQL funkcje zarządzane, takie jak tworzenie kopii zapasowych i czyszczenie replik do odczytu plików binarnych, są obsługiwane wewnętrznie. W przypadku replikowania danych z usługi Azure Database for MySQL należy ustawić ten parametr w podstawowym, aby uniknąć przeczyszczania dzienników binarnych przed odczytem repliki ze zmian z podstawowego. Jeśli ustawisz binlog_expire_logs_seconds wartość na wyższą, dzienniki binarne nie zostaną przeczyszczone wystarczająco szybko. Może to prowadzić do zwiększenia rozliczeń magazynu.

event_scheduler

W usłudze Azure Database for MySQL event_schedule parametr serwera zarządza tworzeniem, planowaniem i uruchamianiem zdarzeń, czyli zadaniami uruchamianymi zgodnie z harmonogramem i są uruchamiane przez specjalny wątek harmonogramu zdarzeń. event_scheduler Gdy parametr jest ustawiony na WŁ., wątek harmonogramu zdarzeń jest wyświetlany jako proces demona w danych wyjściowych SHOW PROCESSLIST. Zdarzenia można tworzyć i planować przy użyciu następującej składni SQL:

CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT ‘<comment>’
DO
<your statement>;

Uwaga

Aby uzyskać więcej informacji na temat tworzenia zdarzenia, zobacz dokumentację usługi MySQL Event Scheduler tutaj:

Konfigurowanie parametru serwera event_scheduler

Poniższy scenariusz ilustruje jeden ze sposobów użycia parametru event_scheduler w usłudze Azure Database for MySQL. Aby zademonstrować ten scenariusz, rozważmy następujący przykład: prosta tabela:

mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field     | Type        | Null | Key | Default | Extra          |
+-----------+-------------+------+-----+---------+----------------+
| id        | int(11)     | NO   | PRI | NULL    | auto_increment |
| CreatedAt | timestamp   | YES  |     | NULL    |                |
| CreatedBy | varchar(16) | YES  |     | NULL    |                |
+-----------+-------------+------+-----+---------+----------------+
3 rows in set (0.23 sec)

Aby skonfigurować event_scheduler parametr serwera w usłudze Azure Database for MySQL, wykonaj następujące kroki:

  1. W witrynie Azure Portal przejdź do serwera, a następnie w obszarze Ustawienia wybierz pozycję Parametry serwera.

  2. W bloku Parametry serwera wyszukaj ciąg event_scheduler, na liście rozwijanej WARTOŚĆ wybierz pozycję WŁĄCZONE, a następnie wybierz pozycję Zapisz.

    Uwaga

    Zmiana konfiguracji parametru serwera dynamicznego zostanie wdrożona bez ponownego uruchomienia.

  3. Następnie, aby utworzyć zdarzenie, połączyć się z serwerem MySQL i uruchomić następujące polecenie SQL:

    CREATE EVENT test_event_01
ON SCHEDULE EVERY 1 MINUTE
STARTS CURRENT_TIMESTAMP
ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR
COMMENT ‘Inserting record into the table tab1 with current timestamp’
DO
INSERT INTO tab1(id,createdAt,createdBy)
VALUES('',NOW(),CURRENT_USER());

  4. Aby wyświetlić szczegóły harmonogramu zdarzeń, uruchom następującą instrukcję SQL:

    SHOW EVENTS;

    Wyświetlane są następujące dane wyjściowe:

    mysql> show events;
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| Db  | Name          | Definer     | Time zone | Type      | Execute at | Interval value | Interval field | Starts              | Ends                | Status  | Originator | character_set_client | collation_connection | Database Collation |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
| db1 | test_event_01 | azureuser@% | SYSTEM    | RECURRING | NULL       | 1              | MINUTE         | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1               | latin1_swedish_ci    | latin1_swedish_ci  |
+-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+
1 row in set (0.23 sec)

  5. Po kilku minutach wykonaj zapytanie o wiersze z tabeli, aby rozpocząć wyświetlanie wierszy wstawionych co minutę zgodnie ze skonfigurowanym parametrem event_scheduler :

    mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
+----+---------------------+-------------+
4 rows in set (0.23 sec)

  6. Po godzinie uruchom instrukcję Select w tabeli, aby wyświetlić pełny wynik wartości wstawionych do tabeli co minutę przez godzinę, zgodnie z event_scheduler konfiguracją w naszym przypadku.

    mysql> select * from tab1;
+----+---------------------+-------------+
| id | CreatedAt           | CreatedBy   |
+----+---------------------+-------------+
|  1 | 2023-04-05 14:47:04 | azureuser@% |
|  2 | 2023-04-05 14:48:04 | azureuser@% |
|  3 | 2023-04-05 14:49:04 | azureuser@% |
|  4 | 2023-04-05 14:50:04 | azureuser@% |
|  5 | 2023-04-05 14:51:04 | azureuser@% |
|  6 | 2023-04-05 14:52:04 | azureuser@% |
..< 50 lines trimmed to compact output >..
| 56 | 2023-04-05 15:42:04 | azureuser@% |
| 57 | 2023-04-05 15:43:04 | azureuser@% |
| 58 | 2023-04-05 15:44:04 | azureuser@% |
| 59 | 2023-04-05 15:45:04 | azureuser@% |
| 60 | 2023-04-05 15:46:04 | azureuser@% |
| 61 | 2023-04-05 15:47:04 | azureuser@% |
+----+---------------------+-------------+
61 rows in set (0.23 sec)

Inne scenariusze

Zdarzenie można skonfigurować na podstawie wymagań konkretnego scenariusza. Poniżej przedstawiono kilka podobnych przykładów planowania instrukcji SQL do uruchamiania w różnych interwałach czasu.

Uruchom teraz instrukcję SQL i powtórz raz dziennie bez końca

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

Uruchamianie instrukcji SQL co godzinę bez końca

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

Uruchamianie instrukcji SQL codziennie bez końca

CREATE EVENT <event name>
ON SCHEDULE 
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;

Niekonfigurowalne parametry serwera

Następujące parametry serwera nie są konfigurowalne w usłudze:

Parametr Stała wartość
innodb_file_per_table w warstwie podstawowa WYŁ.
innodb_flush_log_at_trx_commit 1
sync_binlog 1
innodb_log_file_size 256 MB
innodb_log_files_in_group 2

Inne zmienne, które nie zostały wymienione tutaj, są ustawione na domyślne wartości MySQL. Zapoznaj się z dokumentacją programu MySQL dla wersji 8.0, 5.7 i 5.6.

Następne kroki