Udostępnij za pomocą

Parametry serwera w usłudze Azure Database for MySQL — serwer elastyczny

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

Uwaga

Ten artykuł zawiera odwołania do terminu podrzędnego, którego firma Microsoft już nie używa. Po usunięciu terminu z oprogramowania usuniemy go z tego artykułu.

Co to są parametry serwera?

Aparat MySQL udostępnia wiele parametrów serwera (nazywanych również zmiennymi), których można użyć do konfigurowania i dostosowywania zachowania aparatu. Niektóre parametry można ustawiać dynamicznie podczas wykonywania. Inne są statyczne i wymagają ponownego uruchomienia serwera po ich ustawieniu.

W usłudze Azure Database for MySQL — serwer elastyczny można zmienić wartość różnych parametrów serwera MySQL przy użyciu polecenia Konfigurowanie parametrów serwera w usłudze Azure Database for MySQL — serwer elastyczny przy użyciu witryny Azure Portal i konfigurowanie parametrów serwera w usłudze Azure Database for MySQL — serwer elastyczny przy użyciu interfejsu wiersza polecenia platformy Azure w celu dopasowania do potrzeb obciążenia.

Konfigurowalne parametry serwera

Konfigurację serwera elastycznego usługi Azure Database for MySQL można zarządzać przy użyciu parametrów serwera. Parametry serwera są konfigurowane przy użyciu domyślnych i zalecanych wartości podczas tworzenia serwera. Okienko Parametry serwera w witrynie Azure Portal zawiera zarówno parametry modyfikowalne, jak i niemodyfikowalne. Parametry serwera niezmodyfikowalnego są niedostępne.

Lista obsługiwanych parametrów serwera stale rośnie. Za pomocą witryny Azure Portal można okresowo wyświetlać pełną listę parametrów serwera i konfigurować wartości.

Jeśli zmodyfikujesz parametr serwera statycznego przy użyciu portalu, musisz ponownie uruchomić serwer, aby zmiany zaczęły obowiązywać. Jeśli używasz skryptów automatyzacji (za pomocą narzędzi, takich jak szablony usługi Azure Resource Manager, program Terraform lub interfejs wiersza polecenia platformy Azure), skrypt powinien mieć aprowizację, aby ponownie uruchomić usługę, aby ustawienia zaczęły obowiązywać, nawet jeśli zmieniasz konfigurację w ramach środowiska tworzenia.

Jeśli chcesz zmodyfikować niemodyfikowalny parametr serwera dla środowiska, opublikuj pomysł za pośrednictwem opinii społeczności lub zagłosuj, jeśli opinia już istnieje (co może pomóc nam ustalić priorytety).

W poniższych sekcjach opisano limity często aktualizowanych parametrów serwera. Warstwa obliczeniowa i rozmiar (rdzenie wirtualne) serwera określają limity.

lower_case_table_names (nazwa tabel w niższej wielkości liter)

W przypadku programu MySQL w wersji 8.0 lub nowszej można skonfigurować tylko lower_case_table_names podczas inicjowania serwera. Dowiedz się więcej. lower_case_table_names Zmiana ustawienia po zainicjowaniu serwera jest zabroniona. Obsługiwane wartości dla programu MySQL w wersji 8.0 to 1 i 2 w usłudze Azure Database for MySQL — serwer elastyczny. Domyślna wartość to 1.

Te ustawienia można skonfigurować w portalu podczas tworzenia serwera, określając żądaną wartość w obszarze Parametry serwera na stronie Dodatkowa konfiguracja. W przypadku operacji przywracania lub tworzenia serwera repliki parametr zostanie automatycznie skopiowany z serwera źródłowego i nie można go zmienić.

Zrzut ekranu przedstawiający sposób konfigurowania parametru serwera dotyczącego małych liter w nazwach tabel podczas ich tworzenia.

W przypadku programu MySQL w wersji 5.7 wartość lower_case_table_names domyślna to 1 Azure Database for MySQL — serwer elastyczny. Chociaż możliwe jest zmianę obsługiwanej wartości na 2, przywracanie z 2 powrotem do 1 nie jest dozwolone. Aby uzyskać pomoc dotyczącą zmiany wartości domyślnej, utwórz bilet pomocy technicznej.

innodb_tmpdir

Użyjesz parametru innodb_tmpdir w usłudze Azure Database for MySQL — serwer elastyczny, aby zdefiniować katalog tymczasowych plików sortowania utworzonych podczas operacji online ALTER TABLE , które są kompilowane.

Wartość domyślna innodb_tmpdir to /mnt/temp. Ta lokalizacja odpowiada magazynowi tymczasowemu (SSD) i jest dostępna w gibibajtach (GiB) z każdym rozmiarem obliczeniowym serwera. Ta lokalizacja jest idealna w przypadku operacji, które nie wymagają dużej ilości miejsca.

Jeśli potrzebujesz więcej miejsca, możesz ustawić wartość innodb_tmpdir/app/work/tmpdir. To ustawienie korzysta z dostępnej pojemności magazynu na serwerze elastycznym usługi Azure Database for MySQL. To ustawienie może być przydatne w przypadku większych operacji wymagających większego magazynu tymczasowego.

Należy pamiętać, że użycie /app/work/tmpdir wyników jest wolniejsze w porównaniu z domyślną wartością magazynu tymczasowego (SSD)./mnt/temp Dokonaj wyboru na podstawie określonych wymagań dotyczących operacji.

Podane informacje innodb_tmpdir dotyczą parametrów innodb_temp_tablespaces_dir, tmpdir i slave_load_tmpdir gdzie:

  • Wartość /mnt/temp domyślna jest powszechna.
  • Alternatywny katalog /app/work/tmpdir jest dostępny do konfigurowania zwiększonego magazynu tymczasowego z kompromisem w wydajności na podstawie określonych wymagań operacyjnych.

log_bin_trust_function_creators

W usłudze Azure Database for MySQL — serwer elastyczny dzienniki binarne są zawsze włączone ( log_bin czyli ustawiono wartość ON). Parametr log_bin_trust_function_creators jest domyślnie ON ustawiony na serwery elastyczne.

Format rejestrowania binarnego to zawsze ROW, a połączenia z serwerem zawsze używają rejestrowania binarnego opartego na wierszach. W przypadku rejestrowania binarnego opartego na wierszach problemy z zabezpieczeniami nie istnieją, a rejestrowanie binarne nie może zostać przerwane, więc można bezpiecznie zezwolić na log_bin_trust_function_creators pozostanie jako ON.

Jeśli log_bin_trust_function_creators ustawiono wartość OFF i spróbujesz utworzyć wyzwalacze, mogą wystąpić błędy podobne do: "Nie masz uprawnień ADMINISTRATORA, a rejestrowanie binarne jest włączone (możesz użyć mniej bezpiecznej log_bin_trust_function_creators zmiennej)."

innodb_buffer_pool_size

Aby dowiedzieć się więcej o parametrze, zapoznaj się z dokumentacją innodb_buffer_pool_sizeprogramu MySQL.

Rozmiar pamięci fizycznej w poniższej tabeli przedstawia dostępną pamięć RAM (random-access memory), w gigabajtach (GB) na serwerze elastycznym usługi Azure Database for MySQL.

Rozmiar obliczeniowy Rdzenie wirtualne Rozmiar pamięci fizycznej (GB) Wartość domyślna (bajty) Minimalna wartość (bajty) Maksymalna wartość (bajty)
Możliwość serii
Standardowa_B1s 1 1 134217728 33554432 268435456
Standard_B1ms 1 2 536870912 134217728 1073741824
Standard_B2s 2 4 2147483648 134217728 2147483648
Standard_B2ms 2 8 4294967296 134217728 5 368 709 120
Standard_B4ms 4 16 12884901888 134217728 12884901888
Standard_B8ms 8 32 25769803776 134217728 25769803776
Standard_B12ms 12 48 51539607552 134217728 32212254720
Standard_B16ms 16 64 2147483648 134217728 51539607552
Standard_B20ms 20 80 64424509440 134217728 64424509440
Ogólnego przeznaczenia
Standard_D2ads_v5 2 8 4294967296 134217728 5 368 709 120
Standard_D2ds_v4 2 8 4294967296 134217728 5 368 709 120
Standard_D4ads_v5 4 16 12884901888 134217728 12884901888
Standard_D4ds_v4 4 16 12884901888 134217728 12884901888
Standard_D8ads_v5 8 32 25769803776 134217728 25769803776
Standard_D8ds_v4 8 32 25769803776 134217728 25769803776
Standard_D16ads_v5 16 64 51539607552 134217728 51539607552
Standard_D16ds_v4 16 64 51539607552 134217728 51539607552
Standard_D32ads_v5 32 128 103079215104 134217728 103079215104
Standard_D32ds_v4 32 128 103079215104 134217728 103079215104
Standard_D48ads_v5 48 192 154618822656 134217728 154618822656
Standard_D48ds_v4 48 192 154618822656 134217728 154618822656
Standard_D64ads_v5 64 256 206158430208 134217728 206158430208
Standard_D64ds_v4 64 256 206158430208 134217728 206158430208
Krytyczne dla działania firmy
Standard_E2ds_v4 2 16 12884901888 134217728 12884901888
Standard_E2ads_v5, Standard_E2ds_v5 2 16 12884901888 134217728 12884901888
Standard_E4ds_v4 4 32 25769803776 134217728 25769803776
Standard_E4ads_v5, Standard_E4ds_v5 4 32 25769803776 134217728 25769803776
Standard_E8ds_v4 8 64 51539607552 134217728 51539607552
Standard_E8ads_v5, Standard_E8ds_v5 8 64 51539607552 134217728 51539607552
Standard_E16ds_v4 16 128 103079215104 134217728 103079215104
Standard_E16ads_v5, Standard_E16ds_v5 16 128 103079215104 134217728 103079215104
Standard_E20ds_v4 20 160 128849018880 134217728 128849018880
Standard_E20ads_v5, Standard_E20ds_v5 20 160 128849018880 134217728 128849018880
Standard_E32ds_v4 32 256 206158430208 134217728 206158430208
Standard_E32ads_v5, Standard_E32ds_v5 32 256 206158430208 134217728 206158430208
Standard_E48ds_v4 48 384 309237645312 134217728 309237645312
Standard_E48ads_v5, Standard_E48ds_v5 48 384 309237645312 134217728 309237645312
Standard_E64ds_v4 64 504 405874409472 134217728 405874409472
Standard_E64ads_v5 , Standard_E64ds_v5 64 512 412316860416 134217728 412316860416
Standard_E80ids_v4 80 504 405874409472 134217728 405874409472
Standard_E96ds_v5 96 672 541165879296 134217728 541165879296

innodb_file_per_table

Baza danych MySQL przechowuje tabelę InnoDB w różnych przestrzeniach tabel na podstawie konfiguracji podanej podczas tworzenia tabeli. Systemowa przestrzeń tabel to obszar przechowywania słownika danych InnoDB. Przestrzeń tabel dla pliku na tabelę zawiera dane i indeksy dla pojedynczej tabeli InnoDB i są przechowywane w systemie plików we własnym pliku danych. Parametr serwera innodb_file_per_table kontroluje to zachowanie.

Ustawienie innodb_file_per_table powoduje, że OFF usługa InnoDB tworzy tabele w przestrzeni tabel systemowych. W przeciwnym razie usługa InnoDB tworzy tabele w przestrzeniach tabel dla plików na tabelę.

Usługa Azure Database for MySQL — serwer elastyczny obsługuje maksymalnie 8 terabajtów (TB) w jednym pliku danych. Jeśli rozmiar bazy danych jest większy niż 8 TB, należy utworzyć tabelę innodb_file_per_table w przestrzeni tabel. Jeśli masz jeden rozmiar tabeli większy niż 8 TB, należy użyć tabeli partycji.

innodb_log_file_size

Wartość innodb_log_file_size to rozmiar (w bajtach) każdego pliku dziennika w grupie dzienników. Łączny rozmiar plików dziennika (innodb_log_file_size innodb_log_files_in_group * ) nie może przekraczać maksymalnej wartości, która jest nieco mniejsza niż 512 GB.

Większy rozmiar pliku dziennika jest lepszy w przypadku wydajności, ale wadą jest to, że czas odzyskiwania po awarii jest wysoki. Należy zrównoważyć czas odzyskiwania dla rzadkiego zdarzenia awarii w porównaniu z maksymalizacją przepływności podczas szczytowych operacji. Większy rozmiar pliku dziennika może również spowodować wydłużenie czasu ponownego uruchamiania.

Można skonfigurować innodb_log_size do 256 megabajtów (MB), 512 MB, 1 GB lub 2 GB dla usługi Azure Database for MySQL — serwer elastyczny. Parametr jest statyczny i wymaga ponownego uruchomienia.

Uwaga

Jeśli parametr został zmieniony innodb_log_file_size z domyślnego, sprawdź, czy wartość parametru pozostaje na poziomie show global status like 'innodb_buffer_pool_pages_dirty' 30 sekund, aby uniknąć opóźnienia ponownego 0 uruchamiania.

max_connections (maksymalne_połączenia)

Rozmiar pamięci serwera określa wartość max_connections. Rozmiar pamięci fizycznej w poniższej tabeli reprezentuje dostępną pamięć RAM w gigabajtach na serwerze elastycznym usługi Azure Database for MySQL.

Rozmiar obliczeniowy Rdzenie wirtualne Rozmiar pamięci fizycznej (GB) Domyślna wartość Wartość minimalna Wartość maksymalna
Możliwość serii
Standardowa_B1s 1 1 85 10 171
Standard_B1ms 1 2 171 10 341
Standard_B2s 2 4 341 10 683
Standard_B2ms 2 4 683 10 1365
Standard_B4ms 4 16 1365 10 2731
Standard_B8ms 8 32 2731 10 5461
Standard_B12ms 12 48 4097 10 8193
Standard_B16ms 16 64 5461 10 10923
Standard_B20ms 20 80 6827 10 13653
Ogólnego przeznaczenia
Standard_D2ads_v5 2 8 683 10 1365
Standard_D2ds_v4 2 8 683 10 1365
Standard_D4ads_v5 4 16 1365 10 2731
Standard_D4ds_v4 4 16 1365 10 2731
Standard_D8ads_v5 8 32 2731 10 5461
Standard_D8ds_v4 8 32 2731 10 5461
Standard_D16ads_v5 16 64 5461 10 10923
Standard_D16ds_v4 16 64 5461 10 10923
Standard_D32ads_v5 32 128 10923 10 21845
Standard_D32ds_v4 32 128 10923 10 21845
Standard_D48ads_v5 48 192 16384 10 32768
Standard_D48ds_v4 48 192 16384 10 32768
Standard_D64ads_v5 64 256 21845 10 43691
Standard_D64ds_v4 64 256 21845 10 43691
Krytyczne dla działania firmy
Standard_E2ds_v4 2 16 1365 10 2731
Standard_E2ads_v5, Standard_E2ds_v5 2 16 1365 10 2731
Standard_E4ds_v4 4 32 2731 10 5461
Standard_E4ads_v5, Standard_E4ds_v5 4 32 2731 10 5461
Standard_E8ds_v4 8 64 5461 10 10923
Standard_E8ads_v5, Standard_E8ds_v5 8 64 5461 10 10923
Standard_E16ds_v4 16 128 10923 10 21845
Standard_E16ads_v5, Standard_E16ds_v5 16 128 10923 10 21845
Standard_E20ds_v4 20 160 13653 10 27306
Standard_E20ads_v5, Standard_E20ds_v5 20 160 13653 10 27306
Standard_E32ds_v4 32 256 21845 10 43691
Standard_E32ads_v5, Standard_E32ds_v5 32 256 21845 10 43691
Standard_E48ds_v4 48 384 32768 10 65536
Standard_E48ads_v5, Standard_E48ds_v5 48 384 32768 10 65536
Standard_E64ds_v4 64 504 43008 10 86016
Standard_E64ads_v5, Standard_E64ds_v5 64 512 43691 10 87383
Standard_E80ids_v4 80 504 43008 10 86016
Standard_E96ds_v5 96 672 50000 10 100000

W przypadku przekroczenia limitu połączeń może zostać wyświetlony następujący błąd: "BŁĄD 1040 (08004): Zbyt wiele połączeń".

Tworzenie nowych połączeń klienckich z bazą danych MySQL zajmuje trochę czasu. Po ustanowieniu tych połączeń zajmują zasoby bazy danych nawet wtedy, gdy są bezczynne. Większość aplikacji żąda wielu krótkotrwałych połączeń, co komplikuje tę sytuację. Wynikiem jest mniej zasobów dostępnych dla rzeczywistego obciążenia, co prowadzi do zmniejszenia wydajności.

Moduł puli połączeń, który zmniejsza bezczynne połączenia i ponownie używa istniejących połączeń, pomaga uniknąć tego problemu. Aby uzyskać najlepsze środowisko, zalecamy użycie modułu puli połączeń, takiego jak ProxySQL, do wydajnego zarządzania połączeniami. Aby dowiedzieć się więcej na temat konfigurowania serwera ProxySQL, zobacz ten wpis w blogu.

Uwaga

ProxySQL to narzędzie społeczności typu open source. Firma Microsoft wspiera ją na zasadzie najlepszych wysiłków. Aby uzyskać pomoc techniczną dotyczącą produkcji za pomocą autorytatywnych wskazówek, skontaktuj się z pomocą techniczną produktu ProxySQL.

innodb_strict_mode

Jeśli wystąpi błąd podobny do "Rozmiar wiersza jest zbyt duży (> 8126)," możesz wyłączyć innodb_strict_mode parametr serwera. Nie można zmodyfikować tego parametru globalnie na poziomie serwera, ponieważ jeśli rozmiar danych wierszy jest większy niż 8K, dane są obcięte bez błędu. To obcinanie może prowadzić do potencjalnej utraty danych. Zalecamy 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 uzyskać więcej informacji, zobacz Ustawianie niemodyfikowalnych parametrów serwera.

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.

strefa czasowa

Tabele stref czasowych można wypełnić najnowszymi informacjami o strefie czasowej, wywołując mysql.az_load_timezone procedurę składowaną z narzędzia takiego jak wiersz polecenia MySQL lub MySQL Workbench, a następnie ustawiając globalne strefy czasowe przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure. Strefy czasowe są ładowane automatycznie podczas tworzenia serwera, co eliminuje potrzebę ręcznego wykonania mysql.az_load_timezone procedury składowanej do załadowania ich.

innodb_temp_data_file_size_max

W przypadku serwera elastycznego usługi Azure Database for MySQL (tylko wersja 5.7) parametr innodb_temp_data_file_size_max definiuje maksymalny rozmiar plików danych tymczasowej przestrzeni tabel InnoDB w MB. Ustawienie wartości na 0 oznacza brak limitu, co pozwala na zwiększenie rozmiaru do pełnego rozmiaru magazynu. Każda wartość niezerowa poniżej 64 MB jest zaokrąglona do 64 MB, podczas gdy wartości powyżej 64 MB są stosowane zgodnie z określoną wartością. Jest to zmienna statyczna i wymaga ponownego uruchomienia serwera, aby zmiany zaczęły obowiązywać.

Uwaga

  • Uwaga: w programie MySQL 8.0 lub nowszym globalna tymczasowa przestrzeń tabel (ibtmp1) przechowuje tylko segmenty wycofywania dla zmian wprowadzonych w tabelach tymczasowych utworzonych przez użytkownika. W związku z tym ten parametr nie jest już istotny.

binlog_expire_logs_seconds

W usłudze Azure Database for MySQL — serwer binlog_expire_logs_seconds elastyczny parametr określa liczbę sekund oczekiwania usługi przed usunięciem pliku dziennika binarnego.

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

Zazwyczaj dzienniki binarne są usuwane, 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 ich usunięciem.

Jeśli chcesz utrwalać dzienniki binarne przez dłuższy czas, możesz skonfigurować binlog_expire_logs_seconds parametr . Jeśli binlog_expire_logs_seconds jest ustawiona wartość 0domyślna , dziennik binarny zostanie usunięty natychmiast po jego uwolnieniu. Jeśli wartość binlog_expire_logs_seconds jest większa niż 0, dziennik binarny zostanie usunięty po skonfigurowanej liczbie sekund.

Azure Database for MySQL — serwer elastyczny obsługuje funkcje zarządzane, takie jak tworzenie kopii zapasowej i usuwanie repliki odczytu plików binarnych, wewnętrznie. W przypadku replikowania danych wychodzących z usługi Azure Database for MySQL — serwer elastyczny należy ustawić ten parametr w podstawowej lokalizacji, aby uniknąć usuwania dzienników binarnych przed odczytem repliki ze zmian w podstawowej bazie danych. Jeśli ustawisz binlog_expire_logs_seconds wartość wyższą, dzienniki binarne nie zostaną wkrótce usunięte. To opóźnienie może prowadzić do wzrostu rozliczeń magazynu.

Ograniczenia

Po włączeniu funkcji przyspieszonych dzienników parametr serwera binlog_expire_logs_seconds jest całkowicie pomijany, a każda skonfigurowana wartość nie będzie już miała żadnego wpływu. Jeśli jednak funkcja przyspieszonych dzienników jest wyłączona, serwer po raz kolejny będzie stosować się do skonfigurowanej wartości binlog_expire_logs_seconds na potrzeby przechowywania dziennika binarnego. Dotyczy to również serwerów repliki.

harmonogram wydarzeń

W usłudze Azure Database for MySQL — serwer event_scheduler elastyczny parametr zarządza tworzeniem, planowaniem i uruchamianiem zdarzeń. Oznacza to, że parametr zarządza zadaniami uruchamianymi zgodnie z harmonogramem przez specjalny wątek harmonogramu zdarzeń MySQL. event_scheduler Gdy parametr jest ustawiony na ONwartość , wątek harmonogramu zdarzeń jest wyświetlany jako proces demona w danych wyjściowych polecenia SHOW PROCESSLIST.

W przypadku serwerów MySQL w wersji 5.7 parametr serwera jest automatycznie wyłączany po zainicjowaniu tworzenia kopii zapasowej, a event_scheduler. W programie MySQL w wersji 8.0 dla usługi Azure Database for MySQL — serwer elastyczny event_scheduler pozostaje nienaruszony podczas tworzenia kopii zapasowych. Aby zapewnić bezproblemowe operacje, zaleca się uaktualnienie serwerów MySQL 5.7 do wersji 8.0 przy użyciu uaktualnienia wersji głównej.

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>;

Aby uzyskać więcej informacji na temat tworzenia zdarzenia, zobacz następującą dokumentację dotyczącą harmonogramu zdarzeń w podręczniku dokumentacji programu MySQL:

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 — serwer elastyczny.

Aby zademonstrować ten scenariusz, rozważmy następujący przykład prostej tabeli:

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) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |

1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.

    > [!NOTE]
    > Deployment of the dynamic configuration change to the server parameter doesn't require a restart.

1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
    ```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());

    ```
1. To view the Event Scheduler details, run the following SQL statement:
    ```sql

    SHOW EVENTS;

    ```
    The following output appears:
    ```sql

    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) |
    | ``` |

1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:

    ```azurecli
    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) |
    | ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
    ```azurecli

    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) |
    | ``` |

#### Other scenarios

You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.

To run a SQL statement now and repeat one time per day with no end:

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

Aby uruchomić instrukcję SQL co godzinę bez końca:

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

Aby uruchomić instrukcję 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>;

Ograniczenia

W przypadku serwerów ze skonfigurowaną wysoką dostępnością w przypadku przejścia w tryb failover można event_scheduler ustawić parametr serwera na OFFwartość . Jeśli tak się stanie, po zakończeniu pracy w trybie failover skonfiguruj parametr , aby ustawić wartość na ON.

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table to parametr serwera w bazie danych MySQL, który określa nazwę tabeli zawierającej niestandardowe stopwords dla wyszukiwania pełnotekstowego w bazie danych InnoDB. Tabela musi znajdować się w tej samej bazie danych co tabela indeksowana pełnotekstowo, a jej pierwsza kolumna musi być typu VARCHAR. W usłudze Azure Database for MySQL — serwer elastyczny domyślne ustawienie sql_generate_invisible_primary_key=ON powoduje, że wszystkie tabele bez jawnego klucza podstawowego automatycznie zawierają niewidoczny klucz podstawowy. To zachowanie powoduje konflikt z wymaganiami programu innodb_ft_user_stopword_table, ponieważ niewidoczny klucz podstawowy staje się pierwszą kolumną tabeli, uniemożliwiając jej działanie zgodnie z oczekiwaniami podczas wyszukiwania pełnotekstowego. Aby rozwiązać ten problem, należy ustawić sql_generate_invisible_primary_key=OFF w tej samej sesji przed utworzeniem niestandardowej tabeli stopword. Na przykład:

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

Dzięki temu tabela stopword spełnia wymagania programu MySQL i umożliwia prawidłowe działanie niestandardowych stopwords.

Parametry serwera niezmodyfikowalne

Okienko Parametry serwera w witrynie Azure Portal zawiera zarówno modyfikowalne, jak i niemodyfikowalne parametry serwera. Parametry serwera niezmodyfikowalnego są niedostępne. Można skonfigurować niemodyfikowalny parametr serwera na poziomie sesji przy użyciu witryny init_connectAzure Portal lub interfejsu wiersza polecenia platformy Azure.

Zmienne systemowe usługi Azure mysql

nazwa_serwera_azure

Zmienna azure_server_name zawiera dokładną nazwę serwera wystąpienia usługi Azure Database for MySQL — serwer elastyczny. Ta zmienna jest przydatna, gdy aplikacje lub skrypty muszą programowo pobrać nazwę hosta serwera, z którą są połączone, bez polegania na konfiguracjach zewnętrznych i można je pobrać, uruchamiając następujące polecenie wewnątrz programu MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'azure_server_name';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| azure_server_name | myflex  |
+-------------------+---------+

Uwaga: Stale azure_server_name zwraca oryginalną nazwę serwera używaną do nawiązywania połączenia z usługą (np. myflex) dla serwera z włączoną wysoką dostępnością i wyłączoną wysoką dostępnością

nazwa_serwera_logicznego

Zmienna logical_server_name reprezentuje nazwę hosta wystąpienia, w którym działa usługa Azure Database for MySQL — serwer elastyczny. Ta zmienna jest przydatna do identyfikowania hosta, na którym jest obecnie uruchomiona usługa, co pomaga w rozwiązywaniu problemów i monitorowaniu trybu failover. Tę zmienną można pobrać, wykonując następujące polecenie w programie MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'logical_server_name';
+---------------------+--------------+
| Variable_name       | Value        |
+---------------------+--------------+
| logical_server_name | myflex	     |
+---------------------+--------------+

Uwaga: W przypadku serwera z włączoną wysoką dostępnością zmienna logical_server_name odzwierciedla nazwę hosta instancji działającej jako serwer podstawowy. W przypadku serwera, na którym jest wyłączona HA (wysoka dostępność), wartość logical_server_name jest taka sama jak zmienna azure_server_name, ponieważ istnieje tylko jedno wystąpienie.

Powiązana zawartość

  • Last updated on